¿Alguien que sepa euskera, catalán, inglés u otro lenguaje y quiera echar una mano?

[roman]

¿Y habrá alguna posibilidad de que comentes aquí un poco acerca de esa herramienta y cómo se integra en una página web?, ¿un ejemplo? Me parece interesante y te lo agradecería bastante.

// Saludos

[dec]

Hola,

Bueno. La verdad es que no sé yo si se me dará bien tratar sobre GNU/GetText, puesto que es una herramienta que no conozco ni mucho menos en toda su amplitud. Es muy potente, eso sí, y muy utilizada para ayudar a la localización del Software.

GNU/GetText es una librería de programas, podríamos decir, escritos en el lenguaje C, muy popular y utilizada sobre todo por programadores que trabajan sobre el sistema operativo GNU/Linux. Está formada por diferentes programas que conforman una especie de "entorno" en el cual trabajar.

Explicar cada uno de los programas de GNU/GetText sobrepasa mis capacidades. Sólo diré que hay tutoriales por Internet que explican el uso de estos programas, a lo menos someramente, como para poder utilizarlos y sacarlos provecho. Por cierto, existen versiones de GNU/GetText para Windows.

Para lo que nos ocupa PHP cuenta con una extensión de nombre "gettext" que se encarga de dar la posibilidad de usar dicha librería desde este lenguaje de programación. Sin embargo, es preciso que PHP cuente con dicha extensión instalada y activada, y, por otro lado, el trabajo con esta extensión entraña ciertos problemas con determindas constantes en Windows, por ejemplo.

Un servidor reconoce que no ha sido capaz de usar sino temporalmente y a medias la extensión "gettext" para PHP sobre Windows. Desde luego es posible utilizarla, y existe algún que otro tutorial que explica cómo hacerlo. Este de tutorial de Aeoris.net está bastante majo, por ejemplo.

Empero, como he mencionado, el uso de la extensión "gettext" de PHP no resulta cómo, por decirlo así, o a lo menos no tanto como utilizar ciertas clases para PHP que escriben Danilo Egan y Nico Kaiser. Hablo del proyecto PHP-GetText. Estas clases son las que utilizo en Loturak para su localización. Proyectos de la taya de WordPress también hacen uso de PHP-GetText.

PHP-GetText se compone de tres archivos únicamente. Dos clases y una especie de "módulo" que contiene ciertas funciones útiles y se encarga de tratar con las clases mencionadas: uno tiene puede limitarse a tratar con dicho módulo, olvidándose de las clases que hay "por debajo". PHP-GetText se acompaña de ejemplos sencillos y efectivos.

¿Qué tiene de bueno PHP-GetText, además de que evita ciertos problemas que pueden darse al usar la extensión "gettext" para PHP? Pues, precisamente, que se trata de una librería de clases para PHP que hacen innecesaria la presencia de dicha extensión para PHP. Es, por decirlo así, una forma nativa de leer los archivos "de lenguaje" generados con la herramienta GNU/GetText.

Utilizar PHP-GetText es bastante sencillo. Voy a remitiros, eso sí, al código fuente de Loturak. Concretamente al archivo "lenguaje.php" y al archivo "lenguaje.class.php". El primero es el encargado de cambiar "al vuelo" el lenguaje de la aplicación. El segundo contiene una clase PHP que se autoinicializa y se encarga de inicializar PHP-GetText: veréis cómo todo esto resulta relativamente sencillo.

Vamos, si os parece, a echar un vistazo al contenido de "lenguaje.php":

Código PHP:

 if(isset($_POST['codigo']))
 {
   require('config.php');    
   $caducidad = time() + 3600000; // 1000 horas 
   setcookie(NOMBRE_COOKIE_LENGUAJE, 
    $_REQUEST['codigo'], $caducidad);
 
   // Para que el cambio sea inmediato
   $login->NoCacheHeaders();   
 }
 
 if(isset($_POST['url']))
   header("Location: {$_POST['url']}");
 else 
   header("Location: /loturak/compartidos");  
 die; 


Puede verse cómo nos limitamos a recibir el código del lenguaje que quiere cambiarse en la aplicación. Si recibimos dicho código lo guardamos en una "Cookie" en concreto y nomás nos limitamos a redirigir al usuario a una determinada URL de la aplicación.

Veamos ahora el archivo "lenguaje.class.php":

Código PHP:

 <?php
 
 function _e($cadena)
 {
   echo T_($cadena);       
   return; 
 }
 
 function _r($cadena)
 {
   return T_($cadena);   
 }
 
 require('login.class.php');
 require('bdatosex.class.php');
 
 class Lenguaje
 {
   function Inicializar()
   {
     require_once(DIR_GETT.'gettext.inc');  
 
     if(isset($_COOKIE[NOMBRE_COOKIE_LENGUAJE]))    
       $lenguaje = $_COOKIE[NOMBRE_COOKIE_LENGUAJE];
     else 
       $lenguaje = APP_LENGUAJE_POR_DEFECTO;
 
     $dominio = 'messages';
     T_setlocale(LC_MESSAGES, $lenguaje);
     T_bindtextdomain($dominio, LOCALE_DIR);
     T_bind_textdomain_codeset($dominio, 'UTF-8');
     T_textdomain($dominio); 
      
     $caducidad = time() + 3600000; // 1000 horas
     setcookie(NOMBRE_COOKIE_LENGUAJE, $lenguaje, $caducidad);
   }
   
   function Actual()
   {
     if(!isset($_COOKIE[NOMBRE_COOKIE_LENGUAJE])
      || $_COOKIE[NOMBRE_COOKIE_LENGUAJE] == '')
        return APP_LENGUAJE_POR_DEFECTO;
     else 
       return $_COOKIE[NOMBRE_COOKIE_LENGUAJE];  
   }
    
 } // class Lenguaje
 
 Lenguaje::Inicializar();

He quitado los comentarios al código fuente para que resultara acaso más legible aquí en los Foros.

Dicho archivo "lenguaje.class.php" es requerido por la aplicación siempre, al inicio de la misma, desde el archivo de configuración, para que de este modo la clase "Lenguaje" se inicialize, como puede verse.

El método "Inicializar" de la clase "Lenguaje" sirve para inicializar a su vez la librería "PHP-GetText", como puede verse, estableciendo el lenguaje a utilizar en función del código de lenguaje que hubiera guardado en la correspondiente "Cookie", si es posible, y, si aún no existe la "Cookie" de marras, estableciendo el lenguaje de la aplicación por defecto.

También en este archivo "lenguaje.class.php" contamos con las funciones auxiliares _r() y _e(). Incluyéndolas aquí nos aseguramos que estarán disponibles desde un principio desde cualquier punto de la aplicación. La "r" es de "return" y la "e" de "echo". Se llaman así además para abreviar el código fuente.

Dichas funciones es la única cosa con la que trabajaremos en la aplicación para conseguir que esta sea "localizable". ¿Un ejemplo? Cuando imprimimos una cadena podemos hacer algo así:

Código PHP:

 echo 'Hola, qué tal va eso'; 


O, podemos hacer algo así:

Código PHP:

 _e('Hola, qué tal va eso'); 


En el primer caso la cadena no será "localizable", pero, en el segundo, PHP-GetText se pondrá en marcha, leerá el archivo ".mo" (ver más abajo) correspondiente al lenguaje que esté utilizando la aplicación, localizará la cadena apropiada, y retornará la traducción, si es posible, si la encuentra, vaya.

Esto quiere decir que, en caso de no encontrarse una traducción apropiada, siempre se imprimirá la cadena "Hola, qué tal va eso", sin traducir, pero se imprimirá. Dicha cadena está en el idioma "por defecto" de la aplicación, en la que se esté programando, por ejemplo, en el caso de Loturak, en español.

Ahora vamos a volver a "GNU/GetText", pero, de la mano del programa PO Edit. Este programa es una especie de entorno visual para "GNU/GetText". Estas herramientas son "de consola", así que PO Edit las pone interfaz y echa una mano en su utilización. Una mano y hasta dos... porque PO Edit es una verdadera pasada.

Con PO Edit podemos generar "catálogos" de nuestra aplicación "localizada". Tantos "catálogos" como lenguajes tenga la aplicación. Uno de ellos será el "principal", y se corresponde con el lenguaje por defecto de la aplicación. Estos catálogos los crea PO Edit automáticamente, a partir del código fuente de las aplicaciones, que pueden estar escritas en varios lenguajes, entre ellos PHP.

PO Edit localizará las cadenas encerradas como parámetros de las funciones _r() y _e() (y aquellas que le indiquemos por nuestra cuenta) en todos los archivos con código fuente de la aplicación, localizará esas cadenas y conformará un catálogo con las mismas. PO Edit se encargará también de compilar dichos catálogos, conformándose los archivos con extensión ".mo", que son los que leerá luego "PHP-GetText".

PO Edit ayuda en la traducción de varios modos, como pueda ser indicando las cadenas que faltan por traducir, el porcentaje completado de la traducción, etc., etc. Puede "actualizar el catálogo", de manera que revisará el código fuente de la aplicación y cambiará las cadenas que hubieran podido actualizarse, eliminará las que ya no existan, añadirá las nuevas cadenas, si se dan, etc. Todo esto automáticamente, sin nuestra intervención, en cuestión de segundos.

Me parece que ya voy terminando... En fin, PHP-GetText y PO Edit nos hacen bastante sencilla la localización de aplicaciones escritas en PHP. Claro está que hay que trabajar en la traducción, o sea, PO Edit no traduce automáticamente (aunque es una característica que está pensada, lo cierto es que sería algo así como una traducción hecha por Google... algo nada recomendable, supongo). Es decir, se hace necesaria la colaboración de traductores, pero, lo que es la "localización" de la aplicación, la posibilidad, nos la brinda PHP-GetText y nos la sirve en bandeja PO Edit.

Por cierto. Para Delphi y C++ Builder existe DXGetText, que vendría a ser PHP-GetText para estos lenguajes de programación. Fuciona de manera muy similar a PHP y PHP-GetText. El único inconveniente que noté en su momento era cierta incompatibilidad con los acentos, con las tildes y otros caracteres del lenguaje espaÑol... parece que no se lleva del todo bien con la codificación UTF-8, pero, no sé bien si "el culpable" es DXGetText o el propio Delphi. Lo probé en su momento con Delphi 7.

Y, en fin, creo que esto es todo cuanto puedo decir, grosso modo, sobre el tema. Si hay alguna duda por aquí estaremos. Espero que sirviera de algo. Desde luego tenéis que probarlo, porque a buen seguro alucinaréis con "gettext" y con las herramientas de que he hablado someramente aquí.

PD. La adaptación de PHP-GetText en Loturak es particular, cuando llueve se moja, como las demás. O sea, es una de las formas de conseguir el objetivo perseguido, pero, ni digo que sea la única, ni la mejor, sino, simplemente, una de ellas. Remito de nuevo a los interesados al código fuente de Loturak (relacionado con esto que tratamos) y sobre todo a los ejemplos que acompañan a la propia librería PHP-GetText.

[roman]

Esto se ve muy bueno. Mañana lo leo con calma. Te lo agradezco.

// Saludos

[dec]

Hola,

Empezado por Román

Esto se ve muy bueno. Mañana lo leo con calma. Te lo agradezco.

No hay de qué Román. Lo que pasa es que creo que he sido demasiado... prolijo. En realidad el asunto es más sencillo de lo que puede parecer, sobre todo si no nos podemos a investigarlo todo sobre GNU/GetText,... porque son herramientas muy potentes, en mi opinión, entendiendo potencia como una gran cantidad de características a nuestra disposición, por ejemplo.

Creo que con los enlaces que he proporcionado, el poco de código fuente, alguna que otra idea y un poco de práctica en un par de pruebas que se hagan, quien todavía hiciera una Web con PHP sin "localizar" sería porque no quisiera. Y no es que crea que lo expliqué muy bien, sino que realmente resulta sencillo y hasta ameno utilizar todas estas herramientas. Y además los resultados son mejor que buenos.

[roman]

Empezado por dec

quien todavía hiciera una Web con PHP sin "localizar" sería porque no quisiera

Y sí... Vamos, no todo sitio web es o debe ser localizable (por cierto, qué término tan impreciso ¿no crees?), hay muchos sitios dirigidos a un público muy específico que no requiere más que un solo lenguaje.

// Saludos

[dec]

Hola,

Por supuesto Román. Y puede añadirse que hay sitios en los que la "localización" (coincido contigo, así, el término no me convence) puede acarrear efectos secundarios.

Por ejemplo, en Loturak puede darse un caso curioso ahora mismo. Supongamos que Egostar ya terminó de traducir Loturak al inglés (je, je, je, calma, tranquilidad, no hay prisa) y tenemos a Loturak en inglés y en español.

Llega un londinense y se registra y añade enlaces. Bueno. Es un ejemplo. El caso es que él añadirá las descripciones de los enlaces en inglés, y toda la interfaz de la aplicación la podrá ver en inglés.

Peeero... Loturak está abierta a usuarios que utilizen otros lenguajes, así que el nuestro amigo londinense, dentro de los enlaces "compartidos" de Loturak, podría encontrarse con enlaces cuya descripción estuviera en español, por ejemplo.

¿Qué podría hacerse? Pues a bote pronto se me ocurre que habría que indicar el lenguaje de un determinado enlace. Pero, ahora mismo Loturak no cuenta con esa posibilidad, así que...

En fin. Problemas que surgen de la "localización" de la aplicación. Así que, claro que sí, habrá veces que no sea necesaria esta, o que no tenga sentido, vamos.

En el caso de Loturak yo podría acaso justificar el asunto diciendo que, cuando el usuario está viendo sólo enlaces suyos y no del resto de usuarios, es de suponer que las descripciones de sus enlaces estén en el mismo lenguaje que la interfaz de la aplicación.

Recuérdese que Loturak permite compartir enlaces, pero, también guardarlos, y que los enlaces pueden ser públicos o privados y que a estos últimos no tienen acceso sino los propios usuarios dueños de dichos enlaces.

De todos modos reconozco que no pude evitar hacer a Loturak "localizable", o sea, tampoco pensé entonces en esto que he planteado aquí. Lo ví factible, era algo que quería hacer desde hacía tiempo, me puse a ello y al cabo me pareció que no estaba demás... y todavía me lo parece.

Por cierto, je, je, je,... no dejaré de decirlo: acabo ahora de "subir" la versión 0.7b de Loturak. Pueden verse algunas mejoras, como la posibilidad de "trabajar" con varios enlaces al mismo tiempo.

[[egostar]]

Empezado por Dec

Por ejemplo, en Loturak puede darse un caso curioso ahora mismo. Supongamos que Egostar ya terminó de traducir Loturak al inglés (je, je, je, calma, tranquilidad, no hay prisa) y tenemos a Loturak en inglés y en español.

En eso estoy Dec, "Quod promissum est, de iure debetur"

Saludos