Antes hay que aclarar que por internacionalizado entiendo no sólo lo meramente localizado, es decir, lo que tiene una correspondiente versión, digamos, en castellano; por ejemplo, las mismas plantillas con su correspondiente castellano en lugar del inglés, directamente introducido en el código (hard-coded). No, me refiero a que las propias plantillas estén construidas para que permitan su localización en cualquier lengua. En el caso concreto de PHP o lenguajes semejantes, esto significa que toda manipulación de cadenas haga uso de funciones específicas para su localización posterior a cualquier idioma.
La distribución internacional de wordpress está internacionalizada, en el sentido indicado, en su parte nuclear. También está internacionalizado el tema classic, y existen distribuciones locales que, supongo ---no he visto el código---, internacionalizan algunos otros temas.
El problema está en que no son demasiados los temas para wordpress que estén completamente internacionalizados, y vuelvo a suponer ---realmente no lo he comprobado--- que lo mismo podría decirse de muchos otros sistemas similares de blog, cms, etc.
Los responsables de la situación no son los programadores del sistema propiamente dicho. Sin embargo, documentar y recomendar el uso de funciones de internacionalización no es suficiente para que los desarrolladores de los temas, ya sea por pereza o por falta de conocimiento, decidan presentar su proyecto sin internacionalizar. Lo cual constituye, naturalmente, una ocasión perdida para dar auténtica difusión a su trabajo, que, por otro lado, puede ser excelente; y, en general, una ocasión perdida para el mundo del SL.
El usuario se encuentra, entonces, ante varias posibilidades:
- Descubrir un tema internacionalizado y descargar la versión localizada o crearla él mismo con las herramientas que convengan (gettext o cualquier otra más moderna). [La mejor opción para él, pero puede que no haya un tema que le satisfaga y que permita esta posibilidad.]
- Traducir a pelo las fuentes; es decir, localizar a lo bestia fichero a fichero. [La peor alternativa, porque da una solución parcial y perpetúa el problema.]
- Recodificar las fuentes para que incluyan las funciones de internacionalización. [La mejor para la comunidad, pero requiere tiempo y conocimientos.]
Todo esto me lleva a la siguiente reflexión. Es imprescindible, particularmente en entornos de SL, donde programadores poco experimentados y dispersos hacen continuas contribuciones, que se extienda y se fortalezca la conciencia de este problema, la importancia de la internacionalización del software. El software es para todos, aunque hable inglés en su fondo último. Los lenguajes de programación disponen de medios para hacer esto con relativa facilidad, pero falta la conciencia de todos los que colaboran. Un colaborador de SL debería, por otra parte, estar especialmente predispuesto para este esfuerzo: al fin y al cabo, la libertad exige eliminar las barreras de todo tipo que la amenazan, y una de ellas puede ser la de la lengua.
Por cierto, y dicho sea de paso, lo mismo vale mutatis mutandis para el asunto, aún más complejo, de la accesibilidad, del que algún día tendría que hablar.
Para terminar, creo que son éstos, accesibilidad e internacionalización, dos de los aspectos que mayor esfuerzo deberían convocar. Una solución suficientemente completa a los problemas a ellos asociados es una condición imprescindible para que nuestro software alcance su definitiva madurez.
