Estas en: Home > utf-8

Entradas etiquetadas con utf-8

#symfony, I18N, UTF-8 y Dreamweaver

0

Supongo que ya sabrás de lo que voy a hablar, sí, codificación de caracteres y el jodío de Dreamweaver. Te cuento:

Estoy haciendo algunas pruebas con Symfony y su sistema de internacionalización ( I18N ), y para ello he hecho que el charset que muestre la plantilla sea utf-8 (además de las tablas de la BD y las conexiones desde y hacía la BD), lo curioso es que cuando he ido a verlo en el navegador el resultado me aparecía con chinos (unos cuadrados (aunque pueden ser otros símbolos) que sustituyen a las letras con tilde), total que me he tirado todo el día dándole vueltas al tema, y el problema lo tenía en Dreamweaver que, por defecto, guarda los archivos en “Europeo occidental” y no en utf-8.

Te explico todo lo que he modificado en el proyecto de Symfony, por si te pasa algo parecido puedas comparar. Con esta configuración que te voy a mostrar el sistema de internacionalización de Symfony funciona al 100%:

Antes de nada te informo que esto está pensado para Symfony 1.4, versiones superiores o inferiores pueden necesitar una configuración distinta. Cuando hablo de Dreamweaver me refiero a la versión CS3, aunque muy probablemente algo parecido haya en versiones superiores.

settings.yml

Doy por hecho que ya has creado el proyecto, al menos una aplicación y un módulo con el que hacer pruebas. Nos vamos al archivo settings.yml de la app y añadimos:

 

  1. all:
  2. .settings:
  3.  
  4. # Indicamos la cultura por defecto
  5. # Aquí poned la que os interese
  6. default_culture: es_ES
  7.  
  8. # Indicamos la codificación de caracteres
  9. charset: utf-8
  10.  
  11. # Esto lo dejo a tu elección
  12. # Puedes escribir esta línea para que el helper I18N esté
  13. # en todas las plantillas de forma global
  14. # Lo bueno de usar esta opción es que puedes añadir
  15. # más helpers:
  16. # standard_helpers: [I18N,text, etc]
  17. standard_helpers: [I18N]
  18.  
  19. # O puedes escribir esta otra línea, pero
  20. # en cada una de las plantillas tendrás que incluir
  21. # al prinicipio <?php use_helper('I18N') ?>
  22. # la decisión es tuya
  23. i18n: true

 

routing.yml

Modificamos este archivo para indicar el módulo que se mostrará como página de inicio (homepage):

 

  1. # Esto es lo que está por defecto
  2. homepage:
  3. url: /
  4. param: { module: default, action: index }
  5.  
  6. # Lo único que cambio es el nombre del módulo, que en mi caso es 'login'
  7. homepage:
  8. url: /
  9. param: { module: login, action: index }

 

 

view.yml

Este archivo creo que no hacia falta modificarlo para la internacionalización, pero por si acaso:

  1. metas:
  2. language: es

 

indexSuccess.php del módulo

Añadimos el texto que vamos a probar:

  1. // No voy a poner todo el código que tengo en mi plantilla
  2. // así que pongo solo un ejemplo
  3.  
  4. <?php echo __('Hola Mundo!') ?>
  5.  
  6. // Esto te mostrará el texto en español

Bien, como le hemos dado el valor “es_ES” a “default_culture“, Symfony no mostrará ninguna traducción sino el valor que le hemos indicado en la plantilla. Para hacer una prueba en condiciones vamos a modificar la cultura de un usuario a “en_EN“, esto mantendrá la cultura de todo el proyecto como “es_ES“.

 

actions.class.php del módulo

En la acción Index escribimos lo siguiente:

  1. class loginActions extends sfActions
  2. {
  3. /**
  4. * Executes index action
  5. *
  6. * @param sfRequest $request A request object
  7. */
  8. public function executeIndex(sfWebRequest $request)
  9. {
  10.  
  11. // Esta línea cambiará la cultura SÓLO para el usuario
  12. $this -> getUser() -> setCulture('en_EN');
  13.  
  14. return sfView::SUCCESS;
  15. }
  16. }

Obviamente nos falta crear el archivo que le indicará a Symfony el texto que debe utilizar para su sustitución. A ello voy:

 

english.en.xml

Este archivo se guarda en la carpeta “i18n” de la app, aunque también puedes crear la carpeta dentro del módulo y guardar el archivo allí. Este archivo tiene un formato especial que se debe mantener:

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <xliff version="1.0">
  3. <file orginal="global" source-language="en_EN" datatype="plaintext">
  4. <body>
  5. <trans-unit id="1">
  6. <source>Hola Mundo!</source>
  7. <target>Hello World!</target>
  8. </trans-unit>
  9. <trans-unit id="2">
  10. <source>soy un texto</source>
  11. <target>I'm a text</target>
  12. </trans-unit>
  13. <trans-unit id="3">
  14. <source>Adiós</source>
  15. <target>Bye</target>
  16. </trans-unit>
  17. </body>
  18. </file>
  19. </xliff>

Cosas importantes respecto de este archivo:

  • Le puedes poner cualquier nombre pero debe acabar en *.culture.xml, por ejemplo: login.en.xml, registro.en.xml, administracion.fr.xml, comentario.it.xml.
  • También se puede poner la cultura completa, es decir, en vez de solo *.en.xml puedes nombrarlo como *.en_EN.xml.
  • El parámetro “source-language” siempre debe indicar la cultura que se va a traducir, en este caso es el ingles (en_EN).
  • Cada texto a traducir está dentro de la etiqueta <trans-unit>, que tiene el atributo id, pues bien, cada frase a traducir debe aumentar el id ( 1,2,3,4,5….500 etc)
  • No es necesario que todas las frases estén en un solo archivo, puede haber varios archivos con textos diferentes, por ejemplo, para el menú, la cabecera, el pie de página, etc.,. Importante: aunque sean archivos para idiomas diferentes el nombre del archivo siempre debe ser el mismo, variando, eso sí, la cultura.

Una vez guardado el archivo volvemos al indexSuccess.php y lo modificamos para que quede tal que así;

  1. // No voy a poner todo el código que tengo en mi plantilla
  2. // así que pongo solo un ejemplo
  3.  
  4. <?php echo __('Hola Mundo!', null, 'login') ?>
  5.  
  6. // Ahora mostrará el texto que corresponda con la cultura del usuario
  7. // Además lo buscará en un archivo concreto en este caso login.en.xml

Y así se internacionaliza un proyecto Symfony. Ahora el problemita de Dreamweaver:

El bicho, (por llamarlo de alguna manera) tiene una opción para abrir archivos que no indiquen su codificación. Normalmente está en “Europeo occidental” y debería estar en “Unicode (utf-8)“. Para cambiarlo accedemos al menú “Edición -> Preferencias…” y en “Nuevo documento” busca un desplegable que ponga “Codificación pred.“; ahí elige “Unicode (utf-8)“, activa la casilla que dice “Utilizar al abarir archivos existentes que no indiquen su codificación” y en el desplegable de abajo (Formulario de normas Unicode) selecciona “C (descomposición de compatibilidad seguida de composición canónica)“. Pulsa aceptar y prueba el en navegador.

Tal vez tengas que limpiar la cache de Symfony para ello solo tienes que escribir en la consola (que debe apuntar a la carpeta donde tienes el proyecto) symfony cc o php symfony cc.

Si sigue fallando, abre el archivo indexSuccess.php del módulo con el bloc de notas, y sin modificar nada, vete a Archivo -> Guardar como… , ahí podrás elegir la codificación, en nuestro caso, utf-8, y para evitar que se guarde como un archivo .txt elige “Todos los archivos” y así se guardará en php. Vuelve a limpiar la caché y vuelve a probar, ahora sí te debería funcionar bien.

Google sitemap y PHP

0

Acabo de terminar de programar, testear y poner en servicio un pequeño script en php, que me permitire generar un archivo xml para que el robot de google lo procese, y así, indexar las páginas de una web mucho más rápido.

No lo utilizo en el blog, por la sencilla razón de que tengo un plugin que lo realiza automáticamente:http://wordpress.org/extend/plugins/google-sitemap-generator/. Este script sirve para webs o bien hechas desde cero sin cms de ningún tipo, o bien para cms modificados que requieran un sitemap especial.

Continue reading “Google sitemap y PHP” »

PHP: eregi_replace() y UTF-8 (Problema y solución)

0

Esto creando una nueva web, y como ya deberíais saber, los desarrolladores de PHP decidieron que la versión 6 funcionaría, por defecto, con el charset utf-8. Los que esteis ya implementando estos cambios en vuestros proyectos, conocereis los quebraderos de cabeza que dan tanto mySQL como PHP sino están bien configurados (uno de ellos lo comente hace un tiempo aquí).

Pues bien, hoy me he topado con otro, que me ha tenido todo el día dandome cabezazos contra la mesa, hasta que por fin he descubierto que leches pasaba.
Continue reading “PHP: eregi_replace() y UTF-8 (Problema y solución)” »

Ir arriba