Tarde o temprano en el desarrollo de aplicaciones web nos enfrentamos a algún desarrollo que requiere internacionalizar la aplicación. El primer punto que creo que todos nos tenemos que preguntar a la hora de abordar una aplicación web es si el contenido tiene que ser multi-idioma o la aplicación será multi-idioma.
Si leemos rápido esa última frase puede parecer lo mismo… Si queremos hacer una aplicación multi-idioma simplemente significa que la interface de usuario tiene que estar disponible en más de un idioma, pero no por ello el contenido que se genere tiene que ser multi-idioma. Evidentemente si la aplicación tiene contenido multi-idioma estará acompañado de interface multi-idioma.
Esto hay que tener en cuenta a la hora de diseñar el modelo de datos para que se adapte a nuestras necesidades.
Este artículo está enfocado principalmente a crear una interface multi-idioma y sistemas de traducción por lo que no entraré en como realizar un modelo de datos para soportar contenido multi-idioma.
Podemos reinventar la rueda, que en algunos casos puede ser nuestra rueda preferida en la que nos sintamos cómodos o aplicar estándares para internacionalizar una aplicación web. Si desconocemos la existencia de estos estándares es muy probable que recurramos a la creación de un array asociativo por idioma, ya que realizar una función que nos encuentre la traducción no supondría una grán complicación. Lo malo, es que no siempre pensamos en la explotación de la aplicación y en que la persona que tenga que mantener las traducciones no tiene porqué tener conocimientos técnicos.
Si utilizamos aplicaciones open source es muy probable que nos encontremos el uso de GETTEXT. Este sistema de traducción utiliza ficheros .po y .mo. Los ficheros .po son los ficheros que contienen las traducciones en formato texto:
msgid “Texto original”
msgstr “Texto traducido”
Lo que me gustó es que para poder editar un fichero .po no lo tienes porque realizar con un editor de texto convencional, si no que existen editores multi-plataforma para este formato de ficheros, lo que el mantenimiento de traducciones se hace más práctico. El que me pareció de mayor utilidad a la hora de desarrollar fue gted, un plugin (más) que se integra en eclipse.
En mi opinión es más cómodo trabajar con “pestañas” que con ventanas, y estoy seguro que más de uno compartiréis conmigo esta misma opinión.
Teniendo en cuenta el inconveniente del mantenimiento conocí el formato estándar para traducción de documentos, XLIFF. Es un formato basado en XML que fue normalizado por la organización OASIS en el 2002.
Este formato para la internacionalización de documentos no es para utilizarlo exclusivamente en aplicaciones web, al igual que tampoco lo es el GETTEXT. En la especificación de la versión 1.2 podemos encontrarnos como tiene que ser la extructura de un fichero XLIFF.
<xliff version=’1.2′ xmlns=’urn:oasis:names:tc:xliff:document:1.2′>
<file original=’hello.txt’ source-language=’en’ target-language=’es’
datatype=’plaintext’>
<body>
<trans-unit id=’0′>
<source>Hello world</source>
<target>Hola Mundo</target>
</trans-unit>
</body>
</file>
</xliff>
Donde a parte de este sencillo ejemplo se pueden complementar con mucha más información según la especificación.
La ventaja que encontré al utilizar este sistema de internacionalización es que las empresas que ofrecen servicios de traducción soportan este formato, y al igual que en GETTEXT, XLIFF también tiene editores estándar y en muchos casos multi-plataforma para el mantenimiento de las traducciones.
A diferencia de GETTEXT, XLIFF trabaja sobre el mismo fichero, sin tener que crear una versión compilada. Esto es una ventaja para comprobar si falta alguna traducción y para poder agregar nuevas traducciones en la fase de desarrollo.
En la busca de editores para XLIFF me encontré que muchos de los que decian cumplir con el estándar realmente no lo hacían, como Open Languaje Tools, y otros estaban desactualizados en especificaciones “antiguas”. Open Source y multi-plataforma no encontré ningún editor actualizado, pero sí un editor de pago. Hearstome Translation Studio, un editor profesional para la internacionalización de documentos. Aunque podemos encontrarnos en la Red proyectos web interesantes como este editor en flash lo que nos permitiría dar acceso a las personas que tengan que realizar las traduciones en nuestras aplicaciones.
Escojamos el sistema que escojamos para internacionalizar nuestras aplicaciones, si estamos hablando de entornos Web, es interesante el utilizar un parser de nuestras plantillas/templates para el mantenimiento de la traducción de nuestra interface, de esta manera simplemente generaríamos el archivo origen donde cualquier persona pudiera traducir.
Tiendo en cuenta que has leído “todo el tocho” :-) ¿Como internacionalizas tus aplicaciones/páginas web?
Y para .Net cual es la solución existente?
@Arielo, para .NET puedes utilizar el formato XLIFF para generar tus ficheros de tracción, pero tendrás que generarte (si no existen) tus clases y para manejar las traducciones, la ventaja de utilizar el formato XLIFF es que podrás delegar las traducciones.