enero 2007


Ya nos han vendido tanto las virtudes de XML que sale sobrando que yo diga algo aquí. Ahora, con AJAX, todo el mundo tendrá bien en cuenta que la X del final es por XML, aunque sean más las razones para evitar XML que usarlo pues cuando la estructura de la información a enviar lo requiere, muchos preferirán usar JSON. Pocos serán los memoriosos que recordarán LISP, la mayoría no lo recordará porque jamás lo habrá usado, sin embargo, ˇcómo lo extraño!

(más…)

Las normas DIN (Deutsche Industrie Norm: norma de la industria alemana) dicen un poco del carácter alemán: lo abarcan todo.

La norma conque estamos probablemente más familiarizados sea la que estipula el tamaño de los papeles, en particular el DIN A4. Las medidas de una hoja A4 parecen un poco tomadas de los pelos: 297 * 210 milímetros. Podrían haber establecido algo más simple, no?

(más…)

Cansado de lidiar con el armado de instrucciones de SQL con argumentos variables, se me ocurrió hacer una función para manejarlo. Originalmente se llamaba ArmaSql, estaba en Visual Basic, lo que me tocaba en ese momento y funcionaba sobre MS-SQL. La versión más reciente está en PHP y funciona sobre MySql y como la puse en algún foro en inglés por ahí, se llama BuildSql(). Con muy pocos cambios se puede adaptar a cualquier otra base de datos, pero no me ha tocado hacerlo.

(más…)

Una pregunta frecuente es cómo evitar que cuando un usuario a hecho una operación que modifica la base de datos, se pueda evitar que esta operación se repita si el usuario, inseguro de su resultado, pide un refresco de la página o, después de haber navegado a otros lugares, pase accidentalmente por esta página al retroceder. (más…)

Una posibilidad para la traducción de textos de las aplicaciones es el uso de bases de datos. Hay aplicaciones que lo hacen así, una que me viene a la mente es SAP, aunque no se si aún lo hacen. Con los ejemplos ya mostrados, creo que no es necesario que lo cubra. Basta una o más tablas con campos que correspondan al texto original, el código de idioma y la traducción. Vale la pena notar que el programa xgettext puede ser usado para extraer los textos de los fuentes para luego, mediante un script propio, dependiendo de la estructura de tablas adoptada, se cargue la base de datos. (más…)

Una razón para llamar a este proceso localización y no simplemente traducción es que hay muchas otras cosas que dependen del idioma, por ejemplo, el formato de las fechas o el signo monetario. (más…)

  1. Conceptos
  2. Recomendaciones
  3. Función setlocale() y afines
  4. Usando constantes
  5. Usando variables
  6. Usando arrays
  7. Usando gettext
  8. Usando PHP-gettext
  9. Bases de datos

Dados los problemas de uso de la biblioteca de funciones gettext() incorporadas dentro mismo de PHP mencionadas en el artículo anterior, mi sugerencia es usar PHP-gettext, un paquete que usan muchas aplicaciones, incluso WordPress, en que corre este blog. No sólo su uso es más simple sino que tiene un README donde explica rápidamente su uso, dispone de ejemplos e incluye un archivo para hacer una emulación completa de la funcionalidad de la biblioteca gettext(), aunque vistos los problemas comentados, lo que menos puedo recomendar es usar una emulación que los reproduce hasta el último dolor de cabeza. (más…)

La función gettext() es la forma semi-oficial de manejar una localización y está muy bien integrado en los entornos del tipo Unix, lo cual es bueno y malo. Un grave problema es que depende del soporte de idioma que esté instalado en el servidor, lo cual puede hacer que una aplicación que funciona perfectamente en un servidor, no funcione en otro. Por otra parte, para su inicialización requiere una serie de llamadas a funciones que parecen un tanto caprichosas y que están pensadas más desde el punto de vista organizativo del servidor Unix que de la aplicación. Otros entornos, como Windows, esto puede representar un problema, por ejemplo, si se desarrolla en un ordenador Windows para usar en un servidor con Linux.

(más…)

Usar arrays es apenas un poco mejor que usar variables. Al menos no se ocupa mucho de la tabla de símbolos del intérprete y difícilmente se pueda crear un conflicto de nombres. Se puede incluir una instrucción global con el nombre del único array de traducciones en cada función que vaya a emitir una cadena localizada, en lugar de tener que mencionar cada posible variable de traducción individualmente. Es más lento que usar las variables directamente y su expansión dentro de cadenas encerradas en comillas dobles o cadenas ‘heredoc’ va a requerir encerrar la expresión entre llaves para evitar la ambigüedad de que el intérprete no pueda determinar dónde termina la expresión:

echo "debe usarse así: ${textos['aceptar']}, y no: $textos['aceptar']";

(más…)

Página siguiente »