El sistema multi – idioma de Earwyn / WoD
En la mayoría de aplicaciones, incluidas las basadas en entorno web, los detalles pueden complicar mucho el desarrollo / implementación de un proyecto. Cuanto más refinados están, más dificultades o trabas van apareciendo. E incluso algunas de ellas, se tornan insalvables. El sistema multi – idioma de Earwyn, que da soporte a Win or Defeat, es capaz de manejar un número ilimitado de idiomas conviviendo en el mismo servidor (o en diferentes, si se necesita), haciendo uso de base de datos, ficheros php, ficheros de texto…, pero para llegar a la versión actual, hubo que resolver varios problemas y optar por algunas soluciones a ellos.
La parte más básica del sistema que permite el multi – idioma no supuso mucha complicación. El sistema de plantillas reconoce tags asociados a literales, definidos en ficheros .php, donde a través de variables se declaran la traducción para ese idioma. Es decir…
- Existe un fichero .php por cada idioma, llamado con el esquema cod.php, donde cod es el código de idioma. Earwyn sabe qué fichero cargar según el idioma marcado por el usuario, haciendo un include de él.
$GLOBALS["TXT_MY_TEXT"]=”Este es mi texto, definido en sp.php”;
- En la plantilla .html escribimos algo como:
….<body>¡txt_my_text!</body>…
- Y cuando la plantilla se carga, el framework sustituye el tag marcado entre exclamaciones por su texto equivalente, definido en el fichero de idioma incluido.
….<body>Este es mi texto, definido en sp.php</body>…
Todos los literales presentes en las plantillas, se traducen con este procedimiento. Pero un juego de idiomas también afecta a otros elementos, como literales más largos, mensajes y avisos del sistema, campos de la base de datos…. En muchas páginas, es corriente ver un formulario, en español, menos las opciones de un select, por ejemplo de países. Ese listado se genera a partir de leer una tabla, en la que se escribe el valor del campo en un idioma. Y no queda del todo bien leer todo en español menos ciertas partes. Para evitar este problema nuestra opción fue implementar un sistema de ficheros de texto asociado a los campos identificadores (id, campo clave), que tradujese en consecuencia. Es decir…
- La tabla de países tiene un campo id, un número entero, único para cada registro.
- Existe una carpeta, que a su vez contiene subcarpetas, donde según la naturaleza del dato se guardan los ficheros de texto asociados. En el caso de países, la carpeta es countries.
- En esa carpeta existen tantos ficheros como países haya en la base de datos, nombrados como id.txt, donde id es el valor del campo id en la tabla. (1.txt, 2.txt, 3.txt…)
- A través de Earwyn, cuando leemos la tabla y, por tanto, el id, leemos el fichero asociado, sacando el valor traducido para ese campo.
Para la traducción de entidades de la base de datos, usamos este método, siendo aplicable también a otros elementos. Cuando necesitamos un nuevo tipo de mensaje o entidad a traducir, creamos la carpeta con los ficheros de texto y usando las funciones del framework somos capaces de tener cualquier contenido en multi – idioma. Sin embargo, para el informe del resultado de un partido, estamos refinando más aún el proceso, al tratarse de algo especial, que contaremos más adelante.
En cuanto al proceso de inclusión de un nuevo idioma, es muy cómodo; basta traducir esos ficheros e indicarlo en la configuración del sitio.
Artículos recientes relacionados:
- Encarando un verano muy intenso
- Crystal Reversi, ya disponible en la AppStore
- Postmortem: Tinted Turns (iPhone)
- Independizando Somflee
- Cerrando un proyecto: Tinted Turns
17 December 08 at 12:19
Información Bitacoras.com…
Si lo deseas, puedes hacer click para valorar este post en Bitacoras.com. Gracias….
18 December 08 at 12:31
creo que no es la manera más acertada de hacerlo, al menos para un juego xD
¿qué ocurre cuando el texto a traducir contiene otros parámetros, por ejemplo numéricos?
18 December 08 at 13:13
Hum… a qué te refieres con numéricos?
18 December 08 at 16:28
Existen numerosas maneras de hacerlo, pero mientras no sea guardandolo en tablas (que tiene un rendimiento penoso). Yo personalmente en el proyecto en el que estamos metidos tenemos más de un .php para un mismo idioma por el mero hecho de no cargar mucho texto que no se usaría en una sección.
Una preguntilla, cómo recordáis el idioma seleccionado por el usuario? Lo hacéis en la base de datos? O através de cookie?
18 December 08 at 16:59
Sí, por supuesto, guardar esa información en tablas no es una buena opción.
El idioma se guarda en una cookie si el usuario no está logeado; si lo está, en su perfil puede seleccionar el idioma que quiere tener (puesto que los mensajes privados automáticos, correos del sistema y demás también están en multi – idioma y con una cookie no tienes manera de saber qué idioma tiene un usuario determinado siendo admin)
Lo que sí hacemos es apoyarlo también en la cookie, para no estar comprobando todo el rato qué idioma tiene el usuario cuando este está logeado. 
20 December 08 at 22:14
No uses cookies SiPoX para guardar esa info. Si lo haces al menos comprueba todas las posibles vulnerabilidades, recuerda que si tienes un include de un archivo que varia segun la cookie, te la pueden meter doblada modificando el archivo a incluir.
21 December 08 at 02:14
Me refería a traducciones que alteran su orden según el idioma y contienen datos “volubles” entre si.
“Yens y los 5 fallos de seguridad.”
Yo como comenta Yens, lo hago todo desde archivos php y cargo solamente las zonas que necesito.
Aunque si organizas bien las traducciones en la base de datos tampoco es que sea mucha carga, siempre y cuando no hagas una consulta por cada trozo de texto a traducir.
Lo de donde guardar el idioma ya es cosa de cada uno.
Lo referente a la seguridad idem, la norma principal debería ser “cualquier dato que venga del usuario-cliente debe ser siempre comprobado”
22 December 08 at 10:44
Hum….
@AdriMG. Actualmente es una cookie, pero no habría problema en guardar ese dato temporal en una sesión, pues eso forma parte del framework, y con tocar sólo esa parte bastaría. De todas formas, no es un dato sensible, pues cambiarlo dará como resultado traducir a otro idioma… teniendo el mismo efecto que indicándolo en el perfil. Para los datos sensibles, el uso de cookies está prohibido xD!
@Demiurgo, el sistema soporta tanto bbcode como como una serie de tags propios, haciendo posible que en las traducciones pueda haber información dinámica. Así, los ficheros funcionarían como una especie de plantilla, en la que se basaría el sistema para componer la frase con la información generada donde haga falta. Por ejemplo,
¡Hola %user_inv%! Me gustaría disputar un partido amistoso con tu clan %clan_inv%. Desde la ficha de partido, [match]%id_match%[/match], puedes aceptar o rechazar la solicitud. ¡Espero que te animes!
En cuanto a la seguridad, en eso andamos también, en comprobar todos los posibles accesos no controlados a las operaciones y datos…
Ardua tarea…
22 December 08 at 10:46
Ahms, el tema de cargar ficheros de idioma por partes… me gusta… haciendo una pequeña modificación al framework… también podría soportarlo e incluirlos de forma automática…
Gracias por la idea! 
30 April 09 at 09:32
[...] Somflee hemos adaptado nuestro sistema inicial para resolver esta paradoja. Por un lado, los usuarios indican el idioma de la aplicación y, por [...]