Traducción a Español de Open ERP

2010·07·04, ed. 2010·07·06, © Javier de Lorenzo-Cáceres

El sistema de traducción de Open ERP

Open ERP utiliza sistemas de traducción distintos para openerp-server y openerp-web. El sistema usado por openerp-web es el estándar gettext http://www.gnu.org/software/gettext/ mientras que en openerp-server se ha implementado un sistema propio que mantiene la modularidad y facilita diversas funciones que encontramos en el menú "Administración ‣ Traducciones". Para que los usuarios vean Open ERP en su navegador de Internet totalmente en español, hay que completar la traducción en ambos sistemas, porque openerp-server y openerp-web aportan, cada uno, una parte de la interfaz del usuario final.

Tanto en openerp-server como en openerp-web, los fuentes originales de la traducción de cada idioma residen en archivos .po, característicos del sistema gettext; pero mientras que openerp-web sigue el estándar que consiste en compilar el .po (generar un binario .mo a partir del .po), en openerp-server los distintos archivos .po se cargan en la tabla "ir_translation" de la base de datos de la compañía, generando un registro no por cada término, sino por cada ocurrencia. En el menú, "Términos de la Aplicación" muestra los registros de la tabla "ir_translation" donde se aprecia que sólo se cargan los que corresponden a aquellos módulos instalados en la compañía y sólo de aquellos idiomas para los que hemos usado el menú "Cargar una Traducción Oficial".

La primera dificultad que presenta la tarea de traducir un programa es la cantidad de trabajo, pero a la hora de acometerla es frecuente encontrarnos con algunas más; y Open ERP no es una excepción.

Respecto a la cantidad de trabajo, un programa suele contener del orden de miles de cadenas literales a traducir, por ejemplo, WebERP tiene 6.472. En el caso de Open ERP hay que ir sumando los distintos módulos:

• openerp-web, 376
• openerp-server, módulo base, 1.406
• openerp-server, módulo account, 1.104
• openerp-server, módulo mrp, 378
• openerp-server, módulo product, 321
• openerp-server, módulo purchase, 179
• openerp-server, módulo sale, 249
• openerp-server, módulo stock, 478
• etc.

Hay que tener en cuenta que en openerp-server, estos cuatro mil términos generan más de seis mil registros porque hay términos que se usan varias veces, algunos muchas, como los típicos Aceptar y Cancelar.

Si lo medimos en tiempo, por ejemplo la traducción completa de openerp-web podemos hacerla en unas pocas horas, 2 ó 3, suponiendo que ya conocemos el sistema gettext y los términos propios del programa. Pero para una traducción de calidad hay que tener en cuenta otros factores como el contexto y el espacio disponible donde se renderiza el término. Para lograrlo, debemos tener abierto el programa para poder decidir si debemos abreviar la cadena traducida para que ocupe menos espacio y comprobar si la traducción elegida concuerda con el significado que debería tener en el contexto en que es usada: no basta traducir las palabras (traducción literal), debemos traducir el significado y la cultura (traducción semántica). Esto requiere bastantes más horas de trabajo, especialmente si queremos que el trabajo que vamos realizando se vaya reflejando simultáneamente en la interfaz (actualizar el servidor).

gettext

El sistema gettext es un sistema estándar de internacionalización (i18n) de software. Básicamente, lo que hacemos es:

1. Actuar sobre las cadenas literales del código fuente que deben ser traducidas.
2. Generar una plantilla con las cadenas anteriores msgid: un archivo .pot (.po template)
3. Partiendo de la plantilla anterior, generar un archivo .po para cada idioma donde actualizar las cadenas traducidas msgstr.
4. Compilar el .po anterior, lo que genera un archivo .mo binario que será el usado por el sistema.

Excepto el archivo .mo, se trata de archivos de texto.

1. El código fuente

En el código fuente, ya sea C/C++, C#, Java, Perl, Python, PhP ó TCL, es decir, cualquiera que soporte el sistema gettext que por ser un estándar son casi todos, encerramos en _() las cadenas literales susceptibles de ser traducidas, por ejemplo, en una sentencia como

common.message("No record selected!")

hacemos

common.message(_("No record selected!"))

2. Generando la plantilla .pot a partir del código fuente

En la descarga de Open ERP se incluyen las plantillas .pot tanto de openerp-web como de los módulos de openerp-server, pero generar las nuestras y compararlas puede servirnos para detectar ciertos errores y actualizar la traducción.

Para generar la plantilla ejecutamos el generador de plantilla de gettext, xgettext, que localiza las cadenas en el código fuente y crea un archivo .pot con la plantilla. En la línea de comandos indicamos las rutas a los directorios donde se encuentran los fuentes, el nombre que queremos dar al archivo y otras opciones, por ejemplo:

xgettext --no-wrap -L python -o 'ruta/messages.pot'  /ruta1/directorio1/*py /ruta2/directorio2/*py 

Si hacemos la prueba con openerp-web, al generar el archivo encontramos un par de errores y varias advertencias. Los dos errores son fáciles de corregir, se trata de los fuentes about.mako y error_page.mako que provocan en xgettext el error "unterminated string literal"; para corregirlos editamos los ficheros, que se encuentran en el directorio controllers/templates. Concretamente about.mako es la página "Acerca de" que se nos presenta al hacer clic en "Acerca" en la parte superior derecha de la ventana de Open ERP. Si se fija, la mayoría de las instalaciones presentan varios párrafos de esta página en inglés independientemente del idioma seleccionado, porque el error para gettext está en el código fuente y no le es posible traducirlo. En cuanto a las advertencias, todas se refieren a lo mismo: "extension 'mako' is unknown; will try C", es decir, que gettext no conoce la extensión o tipo de archivo mako y como no sabe determinar en qué lenguaje de programación está escrito el archivo, lo trata como si fuera C. En Poedit podemos usar el menú Edición para configurar en Preferencias los Parsers y seleccionando el lenguaje Python podemos editarlo para añadir la extensión ".mako".

Al finalizar, el .pot generado contiene veinte y tantas cadenas menos que el original. Algunas genuinas, como Búsqueda Básica y Búsqueda Avanzada, hay que recuperarlas del .pot original.

La prueba de xgettext con openerp-server no es satisfactoria, apenas encuentra unas pocas decenas de cadenas y aunque lo hiciera no serviría ya que los archivos de openerp-server no siguen el estándar, requiriendo que se indique el módulo y el objeto, mientras que xgettext se limita a indicar el script y la línea.

3. Generando el archivo .po

El .po es similar a la plantilla POT. La diferencia es que la función de la plantilla es aportar las cadenas originales msgid mientras que los .po son archivos de traducción a un idioma determinado y por tanto tienen como objeto las cadenas msgstr, la traducción de las msgid. En consecuencia, las cabeceras son distintas, ya que en la cabecera de un .po se indica el locale (idioma, país y codificación de caracteres tanto del archivo .po como del código fuente), y algún dato del autor y del equipo de traducción.

Para trabajar en el .po podemos usar un buen editor de texto, Poedit o ambos. Normalmente ya existirá un .po de español, especialmente en el caso del español que se habla en tantos países, pero como el .po de openerp-web no se distribuye con la descarga, si está familiarizado con gettext no es mala opción generar uno propio y comenzar desde cero.

En Poedit podemos generar un archivo .po a partir del código fuente usando el menú "Archivo ‣ Nuevo Catálogo" o generar el .po a partir de una plantilla POT usando el menú "Archivo ‣ Generar un nuevo catálogo (.po) desde archivo POT". En el primer caso indicamos el locale y las rutas a los fuentes; en el segundo, en lugar de las rutas a los fuentes basta con la plantilla y a continuación usar el menú Catálogo para configurar los Ajustes del locale. En cualquier caso, para modificar la traducción de openerp-web es necesario disponer del .po porque es la única forma de generar un nuevo .mo binario, que es el único usado por openerp-web.

4. Compilando el archivo .po para generar el .mo

Esta operación la realiza el compilador de gettext, msgfmt. Podemos ejecutar msgfmt en un terminal o usar Poedit. En Poedit podemos establecer que al guardar los cambios de un archivo .po se cree un .mo usando el menú "Edición ‣ Preferencias" y seleccionando la primera casilla de la lengüeta Editor. Como en toda compilación, el texto fuente debe estar libre de errores que impidan que la misma llegue a buen término.

Trabajando en la traducción: editando los archivos .po

En los archivos .po de cualquier idioma de cualquier programa es frecuente encontrar cadenas literales aún por traducir, mal traducidas, con faltas tipográficas o de ortografía e incluso mal codificadas; y no sólo en los archivos de traducción sino en el código fuente original. Corregir un typo en el código fuente supone generar una nueva plantilla y corregir todos los archivos de traducción mientras que corregir nuestros archivos de español es mucho más sencillo. Para completar y mejorar la traducción podemos usar un buen editor de texto o Poedit, pero para comprobar la codificación es mejor usar un editor de texto.

¿Qué es un error de codificación?

En programas de menos calado que Open ERP es frecuente encontrar errores de codificación simples pero graves porque los traductores no tienen por qué tener conocimientos de codificación binaria, ni trabajar en equipo con quien los tiene. En Open ERP encontramos errores más sutiles, como uno que se repite entre los archivos es_ES.po y que tomamos de ejemplo: una ocurrencia la tenemos en la línea 1201 del archivo es_ES.po del módulo "base" que reproducimos en la siguiente cadena:

msgstr "Dejarlo vacío si no quiere que el usuario se pueda conectar en el sistema."

El error se encuentra entra las palabras "vacío" y "si", a la derecha del espacio que las separa. Es posible que no se note nada a simple vista o que se vea algo raro a la izquierda de la "s", pero el error está ahí. Si abre el archivo con gedit la cadena parece correcta pero si lo abre con vi, vim, Notepad o Notepad++ verá que justo antes de "si" hay un byte que es ilegal en UTF-8. Como gedit no renderiza caracteres ilegales, para descubrirlo en gedit hay que recorrer la cadena con las flechas del cursor y notar que hay que pulsar dos veces para pasar del espacio a la s. Otro efecto es que si hacemos una búsqueda como

"vacío si"

tal búsqueda no ofrece ningún resultado. En los navegadores ocurre algo parecido, algunos renderizan este tipo de bytes y otros no, y lo mismo pasa con otros programas. Puede usar su navegador para mostrar el código fuente de esta página y también puede copiar la cadena de esta página y pegarla en diversos editores de texto y/o un editor hexadecimal. Este error se repite 17 veces en el archivo es_ES.po del módulo base y unas pocas más en los módulos principales. También existía en el archivo misc.py de la carpeta tools donde ya ha sido corregido.

Ni son todos los que están ni están todos los que son

Lo que sobra

En Open ERP podemos encontrar que en los archivos de traducción se hayan incluido nombres de recursos como pueden ser nombres de archivos y código python que no debe ser traducido: esta clase de error se ha corregido recientemente en las plantillas y ahora es el turno de corregirlo en cada una de las traducciones. En general, se pueden eliminar muchas líneas que se habían incluido.

Lo que falta

Otra clase de error es el contrario, y consiste en que algunas cadenas que vemos en la interfaz sin traducir, cuando vamos a traducirlas, resulta que no están contempladas, faltan en los .po y hay que incluirlas para poder traducirlas. Como openerp-server no usa el estándar y la generación de la plantilla es más compleja, quizás podamos añadir estas cláusulas manualmente, considerando el lugar al que corresponde la cadena. Por ejemplo, en el formulario de una Orden de Compra (Pedido de compra), la primera lengüeta "Pedido de compra" muestra el campo "Address" independientemente del idioma seleccionado. Al no haberse incluido en el .po no es posible traducirlo; para poder hacerlo, primero hay que incluir la cadena entre los términos susceptibles de ser traducidos; y para ésto, lo que hay que tener en cuenta es que se trata del campo de dirección de empresa del formulario de orden de compra, es decir, purchase.order,partner_address_id, por tanto lo añadimos a la base de datos y al es_ES.po del módulo "purchase" de la forma siguiente:

#. module: purchase
#: field:purchase.order,partner_address_id:0
msgid "Address"
msgstr "Dirección"

Antes de hacerlo, es conveniente mirar la más reciente plantilla .pot del módulo y de paso comprobar si existe un número de cadenas nuevas considerable, para lo que podemos usar Poedit o "msgmerge" de gettext como vemos a continuación.

Actualizando las cadenas del archivo .po

Normalmente se usan dos formas de ir añadiendo las nuevas cadenas de las nuevas versiones de un programa, las que no existían y las que han cambiado: a partir del código fuente y a partir de una nueva plantilla POT. En Poedit podemos usar el menú "Catálogo" donde las dos primeras opciones son "Actualizar desde código fuente" y "Actualizar desde archivo POT".

Pero como openerp-server no sigue el estándar y como en el primer caso siempre podríamos realizar el paso intermedio de generar una nueva plantilla, en realidad ambos casos se reducen al segundo. También podemos usar "msgmerge" de gettext desde la línea de comandos como en el ejemplo siguiente:

msgmerge --no-wrap --update archivo.po archivo.pot

Tanto Poedit como msgmerge añaden las nuevas líneas, comentan las obsoletas y marcan como provisionales o dudosas "fuzzy" aquellas que no coinciden exactamente. Se pueden configurar ciertos automatismos de cara a la traducción pero, como en todos los traductores automáticos, podemos recordar aquella antigua frase de Google: los humanos lo hacemos mejor.

Apéndice

Trabajar sobre los ficheros .po es la única forma de mejorar una traducción de openerp-web mientras que en el caso de openerp-server tenemos más opciones. Para openerp-server y una sola compañía se puede usar el menú Administración del propio Open ERP. O podemos trabajar sobre ficheros CSV, exportando e importando, para poder guardar el trabajo y que sirva para actualizar varias compañías.

Trabajar sobre los ficheros .po tiene sólo dos pequeños inconvenientes: dominar gettext y actualizar el servidor. Lo primero lo podemos solventar muy bien usando Poedit; lo segundo consiste en actualizar tanto openerp-server como openerp-web.

Actualizar openerp-web con una nueva traducción consiste en actualizar un archivo .mo, teniendo en cuenta que openerp-web puede necesitar ser reiniciado.

Actualizar openerp-server con una nueva traducción que hemos trabajado en archivos .po consiste en actualizar los archivos .po y a continuación usar el menú "Cargar una Traducción Oficial".