¿Qué tiene de bueno gettext para archivos de idioma?

Question

En todas partes en SO cuando se trata de hacer una aplicación multilingüe en PHP, todos dicen que gettext es la mejor manera de hacerlo. Solo quiero saber por qué.

¿Qué hace que este método a continuación sea menos eficiente que usar gettext?

<?PHP
//Have seperate language files for each language I add, this would be english file
function lang($phrase){
    static $lang = array(
        'NO_PHOTO' => 'No photo\'s available',
        'NEW_MEMBER' => 'This user is new'
    );
    return $lang[$phrase];
}
//Then in application where there is text from the site and not from users I would do something like this
echo lang('NO_PHOTO');  // No photo's available would show here
?>

Answer 1

Algo bueno con gettext es que es una especie de estándar de facto: es utilizado por muchas aplicaciones, en muchos idiomas, lo que significa que muchas personas trabajan con él.

Otra cosa buena (tal vez una consecuencia, o una causa, o ambas, en realidad) es que varias herramientas, como Poedit por ejemplo, existe para editar archivos gettext: no tiene que pasar por un código fuente PHP (o lo que sea) . Y esto es muy importante:

• significa que personas no técnicas pueden editar archivos de localización de gettext
  • tal vez esto no te parezca importante ahora,
  • pero si está trabajando en una gran aplicación de código abierto, será importante si tiene éxito y muchas personas la necesitan en su propio idioma.
• significa que no corren el riesgo de romper la aplicación (piense " error de análisis " debido a una falta de coincidencia entre comillas, por ejemplo ;-))

Answer 2

Hay algunos inconvenientes en su " implementación " ;.

• A diferencia de gettext se implementa en php . ;-)
• Mantiene toda la traducción en la memoria sin importar si la usas o no
• Lo que es peor, crea una instancia de toda la matriz de datos cada vez que necesita una línea (lleva un tiempo y bastante memoria en PHP)
• No puede manejar formas plurales para muchos idiomas
• El código, usando esta traducción es difícil de leer
• El código, al usar esta traducción no tiene respaldo incrustado para usar en caso de ausencia de traducción.

Básicamente, su implementación se usa ampliamente en muchos proyectos que se mueren por reclamar su apoyo a la internacionalización y su invención altamente innovadora de la rueda, pero no les importa un poco el resultado y no saben lo bueno de lo malo.

Answer 3

Es la misma respuesta que para todas las preguntas que se ven así:

  

¿Qué es mejor con [muy probado   y solución ampliamente utilizada]   que con [mi novato engreído   implementación]?

• Ha estado aquí durante mucho tiempo, lo creas o no, si un desarrollador experimentado trabajó en él, lo usó y lo alabó, probablemente sea por una razón.
• Es un estándar, por lo que incluso si su solución fuera mejor, el precio a pagar por romperla puede no valer la pena.
• Puede hacer 1000 más que su implementación porque está desarrollado con un alcance global en mente, mientras que su idea solo tiene como objetivo resolver su problema.

No estoy criticando, todos lo hicimos, tratando de convencernos de que somos inteligentes y otros somos programadores excesivos. Esa es parte del camino para aprender. Realmente hago eso continuamente, reinventando la rueda o presumiendo con mis amigos / colegas sobre algún código de KISS que pirateé. Con el tiempo, terminas haciéndolo cada vez menos, y supongo que dejas de hacerlo el día en que realmente merecerías hacerlo :-)

Answer 4

La ventaja de gettext, en comparación con otras soluciones como la suya, las tablas de cadenas Java o los recursos de Windows, es que hace que el código fuente sea más legible.

Compare esto:

printf(_("No photo available (error %d)."), err);

con esto:

printf(i18n(NO_PHOTO), err);
// or some variant of the same thing

En el primer caso, puede ver el mensaje allí mismo en el código y sabe exactamente lo que hace. En el último caso, solo verá una constante simbólica y tendrá que buscar el texto exacto y los especificadores de formato.