Traduciendo WordPress, sus plantillas y extensiones, con el plugin Codestyling Localization

Hace algunos días, el Prrofesor Potâchov comentaba en Twitter (lo siento, Néstor, pero no he encontrado la referencia exacta a tu gorjeo) cuán dura es la vida del traductor de temas o plantillas de WordPress. La afirmación de Néstor es indiscutible, y de hecho no sólo afecta a WordPress o a otros miembros de su familia, como WPMU, bbPress o BuddyPress, sino, en mayor o menor medida, a todos los gestores de contenidos con los que he tenido ocasión de trabajar: b2evolution, Drupal, FlatPress, Joomla!, Moodle, MyDMS, OTRS, etc. Incluso aunque los programadores de estas aplicaciones hagan bien su trabajo y la comunidad de usuarios de cada ámbito lingüístico, en este caso el español, proporcione versiones solventes al poco de publicarse las aplicaciones, abundan las traducciones incompletas, los calcos y falsos amigos, los errores clamorosos, las faltas de ortografía o puntuación, las incongruencias e inconsistencias, etc. Que el problema es arduo y va mucho más allá de las sutilezas para expertos o fundamentalistas de la corrección lingüística lo demuestra el excelente artículo de nv1962, en On the ever annoying issue of English-centric date formatting in default WordPress themes, que a pesar de su título en inglés está relacionado con los desafíos que la traducción de esta aplicación plantea a la comunidad hispanohablante.

Todavía menos satisfactorio es el panorama si prestamos atención a lo que podríamos llamar los márgenes de las aplicaciones, es decir, el conjunto de temas o plantillas, de plugins y extensiones que crece frondoso en torno a los programas de más éxito (en el caso de WordPress, unos y otros se cuentan por miles). A pesar de que las aplicaciones suelen tener normas muy claras para la “internacionalización” y “localización” de plantillas y extensiones (más adelante explicaré estos conceptos), y a pesar también de que se valen de sistemas perfectamente capaces y probados (véase, para el caso de WordPress, los artículos Installing WordPress in Your Language, I18n for WordPress Developers, y Translating WordPress), esas normas se incumplen sistemáticamente, con el resultado esperable de un gran porcentaje de sitios web (en el caso que nos ocupa, blogs) practicantes muy a su pesar de una especie de mezcolanza idiomática que supone para lectores y visitantes no sólo una funcionalidad disminuida, sino sobre todo una falta de respeto.

Los dos últimos episodios relacionados con la traducción de WordPress y demás miembros de su familia en los que me he visto envuelto han sido, en primer lugar, la traducción de la versión 2.5 del tema Tarski, que hace pocos días anuncié en el foro de esta plantilla (por cierto, Tarski es uno de los temas mejor programados desde el punto de vista de la traducción, lo cual permite que sus versiones a otras lenguas sean casi impecables); y en segundo lugar, el hilo de los foros de WPMU Dev Premium que abrí hace algo más de una semana, acerca de determinados problemas planteados por la traducción del tema Corporate para BuddyPress. De este segundo caso, que todavía no he podido resolver a plena satisfacción, al menos he obtenido una enseñanza muy provechosa que aprendí de Ovidiu, uno de los usuarios que acudieron en mi ayuda: la existencia del plugin Codestyling Localization, una extensión de enorme utilidad para quienes se enfrentan cotidianamente a la tarea de traducir WordPress o WPMU, sus extensiones y sus plantillas, y por supuesto para quienes deseen mejorar, o adecuar a sus propios propósitos, las traducciones de terceros.

El plugin Codestyling Localization activa en el blog donde se instala una herramienta de traducción cuyo funcionamiento resultará bastante fácil de entender para quienes ya se han bregado en estas lides, pues es muy parecido a PoEdit, probablemente la utilidad más conocida en este ámbito. Tras ser activado, el plugin crea una entrada en el menú Herramientas, titulada Localización, desde la que se accede a todos los elementos traducibles del blog, es decir, no sólo la propia aplicación, sino también las plantillas y los plugins que han sido codificados para que permitan la traducción mediante las funciones de Gettext, es decir, mediante ficheros .PO/.MO. Codestyling Localization ofrece algunas funcionalidades muy interesantes:

• Creación automática de ficheros .PO (un fichero .PO es un catálogo que contiene, en formato de texto plano, las cadenas de texto originales y sus equivalencias en otra lengua), a partir de los ficheros PHP de la aplicación, el tema o el plugin; por supuesto, esto sólo es posible si aquéllos han sido correctamente programados. El propio plugin genera todos los datos de la cabecera del fichero .PO, identifica los juegos de caracteres (por defecto, UFT-8) y las palabras clave y proporciona la información necesaria para controlar adecuadamente las formas plurales en la lengua de la traducción. Se pueden crear todos los ficheros de lenguas que el usuario necesite, y el plugin genera sus nombres de acuerdo con las convenciones necesarias para que la traducción funcione correctamente en la lengua que se haya determinado.
• Edición de ficheros .PO ya existentes. A veces, dependiendo de la configuración del servidor y de los permisos de los ficheros, hay que modificar éstos para que los ficheros sean editables; aunque esta acción se puede realizar desde el propio interfaz del plugin, hay ocasiones en que se requiere llevarla a cabo mediante una conexión FTP. También puede ser necesario reescanear los ficheros de la aplicación para permitir que el plugin pueda realizar su labor.
• Creación de ficheros .MO (los ficheros, ya compilados en código máquina, que son leídos por el servidor), para lo cual sólo es necesario pulsar sobre el botón correspondiente, una vez completada la traducción del fichero .PO.
• Revisión de los ficheros .PO. Cuando se actualiza una aplicación, una plantilla o un plugin, normalmente suele ser necesario reeditar el fichero .PO, a fin de incluir las nuevas cadenas de texto y descartar las obsoletas. El plugin Codestyling Localization simplifica mucho esta tarea, pues en cualquier momento se pueden reescanear los archivos PHP fuente, y reelaborar el fichero .PO correspondiente.

El interfaz de edición de los ficheros de traducción no planteará ningún problema a quienes ya están acostumbrados a trabajar con utilidades como PoEdit. Se pueden aplicar búsquedas, con operadores muy potentes, tanto a las cadenas originales como a las traducciones, y además existe la posibilidad de traducir las cadenas de texto mediante el API de Google, cuyos resultados no son infalibles ni mucho menos, pero vienen muy bien cuando cuesta encontrar la equivalencia lingüística o se tienen dudas sobre un término. Por último, la traducción se ve facilitada por la función contextual, que permite relacionar cada cadena de texto con su archivo fuente, y por tanto identificar los contextos de uso de las cadenas de texto traducibles en el código PHP original.

Quienes hayan utilizado PoEdit y se manejen bien con este programa o con alguno de sus equivalentes se preguntarán cuáles son las ventajas de traducir online, mediante el plugin Codestyling Localization. A mi modo de ver, esta extensión tiene algunas ventajas indiscutibles sobre la traducción en local:

• Permite generar ficheros .PO con todos los elementos necesarios para crear traducciones impecables. Detalles como el nombre del fichero .PO, los juegos de caracteres o las claves para las formas plurales constituyen un quebradero de cabeza para la mayoría de los usuarios, que ya no tendrán que preocuparse de estas decisiones, pues el plugin las toma de forma automática, basándose en la configuración lingüística del blog y en las características sintácticas de la lengua elegida para la traducción.
• Es un sistema mucho más eficiente, pues permite comprobar los cambios que se llevan a cabo en la traducción de manera casi inmediata, así como actualizar las traducciones cuando se producen cambios de versiones. No hace falta tener a mano en el ordenador donde se está trabajando los ficheros fuente de la aplicación, de la plantilla o de los plugins, porque la edición y publicación de los ficheros de idioma se realiza en línea, esto es, directamente en el servidor. En la práctica, esta circunstancia implica que en el mismo momento que el administrador de un blog localiza un error de traducción, o una cadena no traducida, lo puede corregir y mejorar con muy poco esfuerzo. En blogs multilingües, o en plataformas de blogs que utilizan diversas lenguas (recordemos que el plugin funciona perfectamente en WordPress MU), esta característica ofrece un claro valor añadido, aunque a cambio obliga, o bien a disponer de un usuario administrador que domine varias lenguas, o bien a permitir que los distintos usuarios traductores tengan acceso a las funciones del plugin, lo cual puede suponer ciertos problemas a la hora de administrar la aplicación y garantizar su seguridad.
• Puede identificar y separar las cadenas de texto correspondientes al text domain propio de la aplicación, la plantilla o el plugin (un text domain es algo así como el identificador unívoco de una plantilla o extensión), de aquellas que no han sido identificadas con dicho text domain (a veces los programadores son descuidados, o se olvidan de lo obvio, o recurren, como todo el mundo, al “copia-y-pega”). Esta característica resulta de gran utilidad ante traducciones que carecen, total o parcialmente, de su text domain o cuyo text domain coincide con otro ya existente, circunstancias ambas que producen resultados lingüísticos inesperados y a menudo muy irritantes (porque el sufrido usuario ignora la razón de que determinadas cadenas de texto no aparezcan en su propia lengua o, peor aún, que ofrezcan un resultado distinto al que ha propuesto en su traducción). Evidentemente, el plugin no puede rehacer las fuentes en PHP para incluir el text domain, pero identifica perfectamente los ficheros y las líneas en que se produce este fallo, con lo cual la ingrata tarea de corregir unos y otras se ve muy facilitada. Una vez añadido el text domain a los archivos PHP (proceso que se puede automatizar mediante editores que incorporar funciones de búsqueda y sustitución en bloque, como Notepad++), la regeneración del fichero .PO, su traducción y conversión en fichero de código máquina .MO se convierte en un juego de niños.

A pesar de sus muchas virtudes, el plugin Codestyling Localization tiene ciertas limitaciones relacionadas con el soporte de idiomas, los directorios definidos para las versiones idiomáticas y la dificultad de detectar el text domain, todas ellas superables mediante diversos trucos (véase el epígrafe “Plugin Limits”, en la página de esta extensión). Además, existe una dificultad insuperable no sólo para este plugin, sino para cualquier otra utilidad de traducción: si la plantilla o extensión no han sido “internacionalizadas”, es decir, preparadas para ser traducidas, sólo cabrá recorrer minuciosamente los archivos PHP para sustituir las cadenas originales en inglés por las de la lengua del usuario. Naturalmente, esta alternativa tiene un inconveniente muy serio, y es que una pieza de software traducida “a mano” sólo puede presentar cadenas de texto en el idioma al que se ha sido vertido el código original.

Por otra parte, hay muchas plantillas y plugins que producen traducciones inexactas o incompletas (es decir, cuyo grado de “internacionalización” es parcial), porque olvidan aspectos como las fórmulas de fecha y hora, porque no preparan para su traducción todos los elementos que tienen representación textual, porque consideran que todas las lenguas siguen el mismo orden de palabras que el inglés, etc. (sobre algunas de estas cuestiones,y en relación con el tema Tarski, hace algún tiempo que escribí un artículo en este blog; animo a los interesados en abordar seriamente las complejidades de la internacionalización a que lean dos artículos interesantísimos de Urban Giraffe, Translating WordPress Plugins & Themes y Localizing WordPress Themes and Plugins). En una situación como cualquiera de las que acabo de citar, la mejor herramienta de traducción producirá resultados mediocres, que únicamente pueden mejorarse con trucos más o menos certeros, o rehaciendo el código incorrecto, para lo cual se requiere que el usuario tenga conocimientos de programación en PHP. No es una tarea excesivamente difícil para un programador con experiencia, pero es muy posible que el esfuerzo no merezca la pena.

Se me dirá que bastante hacen los programadores en ofrecer sus creaciones al público gratis et amore, pero esto no es siempre cierto, pues de hecho existen buenos temas y plugins, perfectamente preparados para la traducción y del todo gratuitos, y en cambio productos de pago cuyo grado de traducibilidad es manifiestamente mejorable. Ya sé que citar nombres es peliagudo y que las comparaciones son odiosas, pero entre los primeros se encuentran excelentes plantillas, como la tantas veces citada Tarski, y entre los segundos el famoso Farms 100 big ones theme pack, de WPMU Dev Premium, que en tantas plataformas de blogs se utiliza, no siempre con resultados idóneos.

Desde mi punto de vista de usuario que invierte mucho tiempo y esfuerzo en tareas de traducción (decía Potâchov en la citada e inencontrable intervención en Twitter que él ha debido de traducir unos treinta temas; hace tiempo que yo he dejado de contar los que he traducido, a veces sólo para comprobar, con el cabreo consiguiente, que no me servían, o que era incapaz de resolver sus fallos de internacionalización), creo que los responsables de la gestión de WordPress, y en particular la de los repositorios oficiales de temas y plugins, deberían prestar una atención mucho más precisa y consciente a este asunto. Quizás sea demasiado drástico considerar una adecuada internacionalización como una condición sine qua non para albergar oficialmente las plantillas y extensiones (además, la comprobación exhaustiva de esta característica implicaría un equipo humano de considerables dimensiones), pero la política de gestión de proyectos tan ampliamente usados en todo el mundo, y más cuando afectan al ámbito educativo, debería ir en tal sentido.