funcionamiento de i18n en xHarbour

Uno de los temas de los que ultimamente hablo con mucha gente es del i18n de xHarbour, de lo bueno y de lo malo que tiene y de cómo intentar dar soporte de internacionalización en Harbour o en C3. Ya hice un primer post sobre el tema, pero recapitulamos, pues creo que el personal está perdido.

La manera de acometer la i18n en xHarbour es utilizar la llamada a la función i18n() para las cadenas que queramos traducir que pasaremos como parámetro. Una vez hecho esto generamos una lista de cadenas que se guardan en un fichero con extensión .hil Para ello llamamos al compilador con el parámetro -j, algo así como:

\xharbour\bin\harbour colossus.prg  -jes_ES.hil -i\fwh24\include;\xharbour\include -n</p>

Con esto lo que hace el compilador es localizar todas las cadenas que están como parámetros de la función i18n() en el archivo fuente colossus.prg y las mete ordenadas en el fichero es_ES.hil. Esto lo hacemos para todos los fuentes de nuestra aplicación, con la particularidad de que el proceso es acumulativo, es decir que las cadenas del fuente se acumulan al archivo .hil. Por eso se aconseja borrar cada vez el fichero .hil y generarlo por completo.

Una vez tenemos el fichero .hil lo traduciremos al idioma que queramos usando la utilidad hbdict que se encuentra en \xharbour\utils\hbdict y al que pasamos como parámetros los archivos de entrada – que hemos generado previamente – y el de salida que guardará la traducción hecha y que el programa genera si no existe. Con este programa traducimos una a una las cadenas que se encuentran en el fichero .hil y lo guardamos en un fichero con extensión .hit. Desde dentro de nuestro programa lo único que haremos es decir en que idioma queremos que se muestren las cadenas con las siguientes instrucciones:

HB_I18NSetLanguage( "en_US" )
REQUEST HB_LANG_EN
HB_LANGSELECT('EN')</p>

Si no decimos nada el programa mostrará las cadenas tal como aparecen en las llamadas a la función i18n(). El fichero .hil no se incluye nunca en la distribución, ya que se trata de un archivo de trabajo que sirve como guia para realizar la traducción con el hbdict. Sólo incluiremos en nuestra distribucíón el archivo .hit del idioma en que queramos que esté nuestro programa.

Ventajas de este método:

  • Que está todo hecho y funciona bien, salvo algo que comentaré más adelante.
  • Si añades una cadena nueva al fuente, regeneras el archivo .hil y llamas a hbdict, este acopla el .hil nuevo al .hit viejo y unicamente tienes que traducir la cadena nueva. De alguna manera hbdict tiene memoria. No se cómo lo hace pero lo hace.
  • Los ficheros .hit se cargan internamente en arrays de manera que la ejecución del programa no se ralentiza. Además tiene un formato de texto bastante extraño y está a salvo de que nadie meta las narices ahí.

Problema: que al ser hbdict un programa en modo texto usa páginas de códigos con lo que si usas acentos abiertos y cedillas no hace bien la traducción. Esto me está pasando con la traducción de Colossus a catalán, y por eso estoy haciendo un programa en Windows similar. De momento bilingüa tiene esta pinta y cuando lo termine será una contribución a xHarbour y el código estará disponible.

La menera amanuense de hacer esto es meter las cadenas en un DBF con tantos campos como idiomas y cade vez que tengas que traducir algo tirar del fichero. El problema que veo es que tienes otro DBF en tu aplicación, seguramente esto será más lento que el sistema de xHarbour y que estás más expuesto a que te toquen la traducción con cualquier herramienta que abra DBF. Recordar que con el método xHarbour el .hil nunca se distribuye, por lo que no se puede usar hbdict para tocar a mano una traducción ya hecha.

¿ Opiniones ?

2 comentarios en «funcionamiento de i18n en xHarbour»

  1. Bones,

    Personalmente este metodo no lo he probado y no creo q lo haga, por la sencilla razon q estoy acostumbrado a mi manera y me va muy bien. Yo uso la manera ‘amanuense’ q tu llamas y a comentar:
    Todos los literales se guardan en una Dbf con una clave de idioma, identificador de texto, tipo de literal. A partir de aqui y contestando a tu exposicion, tienes razon de q pueden borrar el fichero o modificar datos con cualquier herramienta q abra DBF, pero es q tambien pueden borrar o modificar una tabla de datos, q casi es peor, no ?. A no ser q lo tengas en un C/S como ADS y nadie le puede meter mano, si en cambio con el otro sistema q siempre es vulnerable a q lo puedan borrar.
    Es un sistema q a medida q vas programando los diferentes modulos vas actualizando la tabla. Con el tipo de literal yo le indico si es solo un texto, o si ademas quiero q me lo ponga automaticamente en una Mensaje de Info, Alert, YesNo, …
    La velocidad -> Ni lo notas. Ademas a tener en cuenta q los textos siempre estan fuera del exe ocupando menos memoria, ahora q hoy en dia esto tampoco influye mucho.

    En fin, son sistemas parecidos, pero como ya estoy acostumbrado al mio, de momento me quedo con este.

    Un saludo.
    C.

Los comentarios están cerrados.