La herramienta GNU Gettext es bien conocida en el "entorno Linux", porque es la responsable, nada más y nada menos, de la localización de las aplicaciones, de que estas puedan mostrarse en diferentes idiomas.

Hay muchos "sabores" de GNU Gettext. Para Delphi existe DXGettext, y para PHP existe PHP gettext.

En realidad PHP cuenta con una extensión que trabaja directamente con GNU Gettext (si no me equivoco), pero, este último programa que enlazo puede trabajar emulando dicha herramienta, es decir, sin necesidad de que PHP cuente con la extensión de marras. Algo muy útil, sobre todo si no controlas las extensiones que tienes disponibles.

Pero, a lo que iba. Hace tiempo me surgió la necesidad de conocer cuántos lenguajes disponibles tenía una determinada aplicación. Es decir, quise crear una especie de algoritmo que recorriera un determinado directorio, buscando archivos ".mo", o tal vez ".po" (".mo" sin compilar aún), "parseando" la información contenida en dichos archivos.

De este modo no habría que crear una especie de "Array" para que la aplicación supiera cuántos lenguajes tenía disponibles, para permitir cambiar al usuario el lenguaje que quisiera, por ejemplo, pero, en su momento lo dejé de lado y opté por el "Array", entre otras cosas, porque no me gustó la idea de cargar los archivos ".po", ".mo", me pareció un "gasto" demasiado caro.

Pues bien. Ahora tengo la misma necesidad... y me he vuelto a plantear una posible solución, y acabo de encontrar algo que no conocía y que parece funcionar y que puede ayudar bastante a la hora de conseguir el objetivo, sin necesidad de cargar todos los archivos disponibles.

El asunto es bastante sencillo. Cuando trabajamos con PHP gettext, por ejemplo, lo hacemos de este modo: 

$msg = _r('Cadena localizada');

En definitiva, a la función auxiliar "_r()" se le pasa la cadena que queremos localizar, de modo que, si es posible, se retornará la cadena localizada en el lenguaje previamente establecido, y, de no ser posible, se retornará la cadena original. Ahora bien, echando un vistazo a un archivo ".po" me encuentro con esto: 

msgid ""
msgstr "Project-Id-Version: n"
"POT-Creation-Date: 2007-08-02 18:17n"
"PO-Revision-Date: 2007-10-04 19:05+0100n"
"Last-Translator: decn"
"MIME-Version: 1.0n"
"Content-Type: text/plain; charset=utf-8n"
"Content-Transfer-Encoding: 8bitn"
"X-Generator: dxgettext 1.2.1n"
"Language-Team: n"

¿Y eso qué significa? Pues bien. "msgid" es el identificador para una determinada cadena, justamente, la siguiente "msgtr". ¿Y qué identificador tiene el "msgid" que ves más arriba? Exacto. Ninguno. Es una cadena vacía. ¿Y qué retorna esa cadena vacía? Justo... la información del archivo ".po"... su fecha de revisión, traductor, lenguaje... lo que estaba buscando.

Es decir, que en GNU Gettext pensaron que no sería mala idea obtener información de los archivos ".po" y ".mo", y decidieron hacerlo de ese modo, parece ser. De este modo cuando se pase una cadena vacía para ser localizada..., es decir, siguiendo con el ejemplo en PHP: 

$msg = _r('');

Lo que obtendremos es la información del archivo ".mo" correspondiente al lenguaje en uso. ¿Curioso, no? A mí puede venirme muy bien en el intento de obtener los lenguajes disponibles de en una aplicación, sin embargo, creo que pueden ponerse algunas pegas.

Gracias a este "descubrimiento" (debe venir en algún manual, estoy seguro), desde luego, no me plantearía parsear un archivo ".mo" para obtener su información. Lo que haría sería localizar una cadena vacía, para obtener dicha información, como se ha visto arriba. ¿Pero qué ocurre con los otros archivos?

Porque no se trata de obtener la información del archivo ".mo" en uso... sino de todos los archivos ".po"... Y entonces me encuentro con el primer problema: la carga de todos los archivos ".po" para conseguir el objetivo. Sólo que ahora podría delegar la carga de los archivos a GNU Gettext, DXGettext, PHP Gettext.

Podría limitarme a recorrer un directorio en busca de archivos ".mo", e ir haciendo de cada uno de ellos el lenguaje "establecido", para en ese momento recoger la información del archivo ".mo" de turno. Si bien esto todavía podría costar más "trabajo".

Ya no cargaría yo los archivos, pero sí tendría que hacerlo Gettext, y a esto se sumaría el hecho de establecer en un bucle el lenguaje de la aplicación... varias veces en muy poco tiempo... algo que sin duda tiene que costarle un trabajo al sistema.

Así que no sé. Después de mi descubrimiento, resulta que sigo con las mismas dudas o acaso más que antes. Tener que cargar un número indefinido (aunque no muy grande) de archivos, que pueden tener un tamaño considerable (unos cientos de KB), para averiguar el número de lenguajes disponibles... no sé.

Por otro lado se busca una solución para automatizar dicha tarea. Porque usar un "Array" equivaldría a que cada vez que se añadiese un lenguaje a la aplicación, habría que añadirlo al propio "Array". Se trataría de evitar esto, de que el asunto se hiciera automáticamente. Pero hay que considerar a qué precio.

Al escribir esto se me ocurre otra posible solución, y termino, porque no quiero resultar pesado. Se trataría de preparar un "Array" con los lenguajes a los que potencialmente se va a traducir la aplicación. Si se trata de establecer un lenguaje no disponible, no ocurrirá nada. Simplemente, se utilizará el lenguaje "por defecto".

Lo único malo de esto último es que tendríamos un listado de lenguajes disponibles... que en realidad no están disponibles, pero, conseguiríamos no tener que tocar la aplicación en cierto tiempo, y evitarnos el posible "gasto" en que incurriríamos si tratáramos de automatizar la tarea de averiguar cuántos y cuáles lenguajes hay verdaderamente disponibles.