Estas en: Home > Problema

Entradas etiquetadas con Problema

#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.

Subversion: */props/tempfile.tmp. No se puede hallar la ruta especificada

1

A veces las cosas fallan, sin más. Como en este caso, por alguna extraña razón Subversión no podía hallar la ruta especificada. Reviso la ruta y la carpeta no existe. Solución sencilla:

Creas la carpeta props y dentro de ella con el bloc de notas (si hablo de Windows, si estas en otro SO y te da este error (que lo dudo, sobre todo si es GNU/Linux) te dejo que elijas editor de texto xD) creas el archivo tempfile.tmp en blanco sin que tenga ni siquiera un espacio en blanco, le das a “Guardar como…” y en el deplegable elije “Todos los archivos” de esa forma podrás escribir la extensión del archivo y que no te lo guarde como txt.

Solo tienes que volver a realizar el commit y listo.

CentOS y VirtualBox

2

Esta mañana me he levantado con ganas de enrear xD. Tenía varias cositas que solucionar. Una de ellas era instalar los drivers de mi tarjeta gráfica Nvidia GeForce 220 en Debian Lenny, pero por desgracia no lo he conseguido (habrá que intentarlo otro día). Así que, viendo mi fracaso con Debian he probado suerte con CentOS, ya que me interesa hacer pruebas con el SO del VPS donde tengo alojado el blog, y así conocerlo mejor.

La instalación fue muy sencilla la verdad, pero cuando reinicié la máquina virtual, ésta se colgaba. Viendo los logs me encontré lo siguiente:

Console: VM runtime error: fatal=true , errorID=PAEmode message=”The guest is trying to switch to the PAE mode which is currently disabled by default in VirtualBox. PAE support can be enabled using the VM settings (General/Advanced)”

Si sigues las indicaciones que te da, es decir activar el soporte de PAE en la pestaña General/Avanzado de la máquina virtual, te puedes volver loco, ya que, esa opción no está ahí. La solución la encontré en los foros de VirtualBox y paso a explicarla:

Dentro de la configuración de la máquina virtual tienes que ir a la sección “Sistema” y abrir la pestaña “Procesador”, ahí podrás habilitar “PAE/NX”.

PD: También he leido que CentOS necesita 384MB de memoría para funcionar ya que parece que da algún error al arrancar “Anaconda”, su instalador, yo no he sufrido este error, pero por si acaso…

Pasar un proyecto symfony de un servidor a otro (a capón xD)

6

Sí, soy un poco bestia para algunas cosas jejeje; en este caso tuve que pasar el proyecto con el que estaba trabajando en el portatil al ordenador de sobremesa. En el portatil tengo instalada una versión de WAMP y en el sobremesa AppServ así que cuando pasé la carpeta del proyecto con un copy&paste y fui a ejecutarlo al navegador, obviamente no funcionaba, exactamente daba este error:

Warning: sfAutoload::require(C:/wamp/www/sf_sandbox/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/database/sfDoctrineDatabase.class.php) [sfautoload.require]: failed to open stream: No such file or directory in F:\AppServ\www\sf_sandbox\lib\vendor\symfony\lib\autoload\sfAutoload.class.php on line 188

Fatal error: sfAutoload::require() [function.require]: Failed opening required ‘C:/wamp/www/sf_sandbox/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/database/sfDoctrineDatabase.class.php’ (include_path=’.;F:\AppServ\php5\pear’) in F:\AppServ\www\sf_sandbox\lib\vendor\symfony\lib\autoload\sfAutoload.class.php on line 188

Continue reading “Pasar un proyecto symfony de un servidor a otro (a capón xD)” »

Opera, Adsense y un procesador de doble nucleo al 50%

0

Para mí, el navegador Opera es uno de los mejores navegadores que existen en la actualidad rápido en ejecutarse, rápido en cargar páginas, y más o menos como los demás con la memoria, y sobre todo sigue los estándares.

Pero desde hace un tiempo no podía acceder a la página de adsense, sin razón aparente, así que con el tiempo me olvidé de ella, y entraba por Chrome o Firefox. Hasta hace unos días que actualicé el navegador a la versión 10.53 con la que, pasado un tiempo navegando, el procesador se ponía al 50% de su capacidad a causa de Opera; aun sin pestañas abiertas.

Déspues de pasarme un par de días comiendome la cabeza por el tema, descubro que el fallo está en que han deshabilitado por defecto el protocolo de seguridad TLS 1.1, así que accediento a:

Configuración/Opciones/Avanzado/Seguridad/Protocolos de seguridad

Y ahí activais el protocolo TLS1.1 y pulsais aceptar, podeis cerrar y volver a abrir, pero creo que el procesador volverá al 2-10% para Opera (dependiendo de lo que esteis haciendo).

Y sí, ya he vuelto a reabrir Adsense con Opera con este cambio. XD

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