Localización de Ruby: i18n, g18n, gettext, padrino... ¿cuál es la diferencia?

localization internationalization

Question

Al ser algo nuevo en Ruby, estoy explorando bibliotecas existentes para hacer lo que normalmente haría en otros lenguajes de scripting, y estoy un poco perplejo por las bibliotecas de localización que podrían estar disponibles para algo creado sobre Sinatra / Sequel (Rails / AR siendo un poco demasiado a mi gusto).

Ahora, me encontré con una pareja (i18n, r18n, GetText) a través de esta página wiki , y aparentemente hay una biblioteca adicional utilizada en Padrino (basada en la cosa i18n de Rails?); y al parecer mucho más.

Excepto por lo obvio (es decir, archivos GetText mo / po style vs yml), estoy algo confundido en cuanto a cómo estas opciones podrían ser diferentes. El wiki no señala mucho al respecto, excepto que dice que existen; No como son diferentes.

Sumado a esta confusión, está el hecho de que esencialmente cada pieza de documentación parece cubrir uno solo de ellos (y generalmente en un contexto RoR). Además, estas opciones no parecen totalmente incompatibles entre sí en una inspección más cercana, en el sentido de que, si entendí esto correctamente, pueden comprender los archivos de cada uno en gran medida.

¿Alguien aquí podría dar una explicación / descripción rápida y precisa de estas bibliotecas, y describir la diferencia entre ellas? Algunos consejos sobre el rendimiento también serían bienvenidos, si está al tanto de alguno (además de los de los documentos fast_gettext, lo cual no tiene sentido considerando mi falta de comprensión de la diferencia entre estas opciones).

Answer 1

I18n es una corriente principal.

R18n es una alternativa con algunas características adicionales (traducciones de modelos, sintaxis de azúcar) y alguna diferencia en ideología y arquitectura (extensibilidad flexible por filtros potentes).

G18n necesita agregar modelos de transición a I18n.

Padrino no es una biblioteca i18n, es solo el marco de trabajo de Sinatra con I18n incorporado.

Gettext es una concepción antigua de IMHO con un formato muy feo y un problema con la pluralización. De todos modos, no es popular en la comunidad Ruby.

Answer 2

La respuesta de Andrey me indicó que regresara a los documentos R18n , que básicamente lo dividen en una sola línea:

R18n utiliza el formato YAML jerárquico y no centrado en el inglés para las traducciones de forma predeterminada.

Encontré este slideshare de Andrey. Está en ruso, pero ahora tiene mucho más sentido (diapositivas 7 a 9, en particular, diferencias claras entre i18n y r18n):

http://www.slideshare.net/iskin/r18n

Answer 3

Puedo ver cómo esta situación es confusa sin saber algo de la historia de las bibliotecas i18n / l10n en Ruby. Probablemente debería escribir algunas palabras sobre eso, pero por ahora intentaré dar una visión general desde mi perspectiva:

Gettext es obviamente el jugador más antiguo en este juego y hereda fortalezas y debilidades de su ascendencia que se está inventando para un mundo dominado por C. Tiene la mayoría de las funciones que uno necesita, viene con algunas herramientas de soporte que otros carecen (como los editores de archivos de escritorio po) y es ampliamente aceptado en el llamado mundo empresarial.

Gettext como tal define una API y hay básicamente dos bibliotecas que lo implementan en el mundo de Ruby, los paquetes tradicionales de Ruby Gettext de Masao Mutoh y la gema fast_gettext de Michael Grosser .

Ruby Gettext es bastante potente y ofrece una gran cantidad de características que puede o no necesitar. La gema fast_gettext, por otro lado, se centra en la velocidad bruta y se implementa como una biblioteca de Ruby de estilo de código moderna y brillante que es fácilmente hackeable y el autor es una persona muy inteligente y de apoyo. De los dos, personalmente recomendaría velozmente get_gettext.

La gema I18n es el resultado del esfuerzo conjunto de varias soluciones Ruby i18n / l10n que existían hace algunos años y que todos se esforzaron por reemplazar a Gettext por varias razones en ese momento. La API I18n resultante cubre básicamente los requisitos y casos de uso de todas las soluciones i18n / l10n involucradas en ese momento, incluida la API de Gettext. Por lo tanto, la API de Ruby I18n de hoy es un superconjunto de la API de Gettext de principios de los 90.

Hoy en día, la gema I18n es la solución oficial que se envía con Ruby on Rails , pero también es probablemente la más popular en el mundo de Ruby en general.

La gema I18n también hace que sea muy fácil extender el conjunto de características y agregar cosas como el almacenamiento en caché, otros mecanismos de almacenamiento (como los archivos Gettext po, las tablas de bases de datos, los almacenes de valores clave, los valores predeterminados de almacenamiento a los archivos simples de Ruby y YAML), etc. una serie de módulos para eso (pero los módulos externos o personalizados se pueden diseñar, probar e integrar fácilmente).

Hay archivos de traducción para más de 70 idiomas (locales) para cadenas utilizadas por Ruby on Rails (que también son útiles en otros proyectos) mantenidas por la comunidad.

No puedo decir mucho sobre R18n excepto que se inventó justo después de que I18n alcanzara su primer lanzamiento y, por lo que recuerdo, se originó en la comunidad Merb. Parece ser bastante fuerte en el mundo ruso de rubíes, pero podría estar equivocado con todas estas afirmaciones.

Por lo tanto, a menos que tenga una buena razón para elegir cualquier otra solución, le recomendaría encarecidamente el uso de I18n.

Entonces, por otro lado, eso no significa nada porque he estado liderando este proyecto más o menos desde que se inventó.

Espero que esto ayude.

[EDIT] añadido enlaces a varias referencias

Answer 4

Primero:
Como escribió Svenfuchs, I18n es un marco que proporciona módulos para muchos enfoques de traducción e internacionalización.
''gettext'' es solo uno de los muchos módulos.

Así que realmente no hay duda de usar I18n .

La configuración predeterminada de una aplicación de Rails es usar I18n con el backend de YAML y entiendo parte de su pregunta para comparar ese backend con otros.

En mi humilde opinión, hay dos diferencias principales entre los enfoques basados ​​en gettext y YAML :

• soporte del ciclo de vida
• jerarquía

gettext

Una idea de gettext es que traducir una aplicación no es un evento singular, sino un proceso de ciclo de vida.
Está construido para soportar este ciclo en vivo.

gettext está diseñado para utilizar el inglés simple como las claves para las traducciones. Entonces, la idea es escribir la aplicación en inglés y marcar todo el texto que se va a traducir, normalmente envolviéndolo con _() .
Como resultado, el código fuente de la aplicación se puede leer fácilmente en inglés.

Luego, un programa escanea todo el código fuente y extrae los textos para traducir y construye un repositorio (el archivo .pot ) de estos textos.

En el siguiente paso, y aquí viene el ciclo en vivo , el repositorio se fusiona con las traducciones existentes (archivos .po , uno para cada idioma de destino) y se marcan los elementos nuevos o modificados.

Los editores maduros apoyan a los traductores al centrarse en los elementos nuevos y modificados. Además, los diccionarios específicos del proyecto pueden admitir traducciones automáticas parciales.

gettext es plano , lo que significa que cada frase clave se traduce exactamente una vez en los archivos de traducción. No hay jerarquía. Pero hay contexto. En los archivos de traducción, se enumeran todas las posiciones del código fuente de una frase clave. Un editor con acceso al código fuente puede mostrar la fuente junto con la traducción (y algunos lo hacen).

Finalmente, los archivos .po se traducen a formularios de acceso rápido legibles por máquina (pueden ser .mo , el estándar clásico, una base de datos o json o ...)

YAML

YAML y la otra parte es jerárquica, por lo que es fácil tener variaciones de traducciones en diferentes contextos.
I18n utiliza esta estructura para admitir scopes y utiliza la ruta del archivo actual como ámbito cuando se usan claves que comienzan con un punto.
No hay información, donde se usa una clave en el proyecto (bueno, a menos que sea de ámbito automático, pero la clave se puede usar en otros lugares explícitamente).
No hay información, si hay algún cambio.
A menos que su IDE lo apoye, el desarrollador tiene que encontrar el lugar correcto para colocar una clave en el YAML y buscar el uso puede ser engorroso. Mucho más se dice en las otras respuestas.

I18n

Intencionalmente dije YAML y no I18n , porque I18n es un marco para la internacionalización (no solo traducción), y YAML es solo un backend posible.
El soporte plural en I18n difiere del soporte plural de getilla gettext. No tengo experiencia en cómo cooperan.

Ejemplos

Obtener texto con parámetros posicionales:

sprintf(
_(''Do you really want to delete tour %1$s_%2$s? Only empty tours can be deleted!''),
tag, idx)

las traducciones son archivos de texto, pero los editores de PO proporcionan GUI:

#: js/addDelRow.js:15
msgid "" "Do you really want to delete tour %1$s_%2$s? Only empty tours can be deleted!" 
msgstr "" "Wollen sie die Spalte %1$s_%2$s wirklich löschen? Nur leere Spalten können "
"gelöscht werden."

YAML con parámetros:

Fuente

<%= t(''.checked_at'', ts: l(checked_at), user: full_name) %>

traducción
desde

en:
  hotels:
    form:
      checked_at: „set to checked by %{user} on %{ts}“

a

de:
  hotels:
    form:
      checked_at: "geprüft gesetzt am %{ts} von %{user}“

Conclusión

Para empezar, YAML es mucho más fácil, especialmente si cuenta con el soporte de un IDE.
Vanilla RAILS lo tiene incorporado.
El no es idioma nativo . La primera traducción puede ser cualquier idioma. Con proyectos en crecimiento y múltiples idiomas, mis archivos YAML tienden a repetirse (la misma traducción dispersa en toda la jerarquía) y rastrear los cambios y, por lo tanto, las nuevas traducciones son engorrosas.

gettext necesita una cadena de herramientas adicional y, por lo tanto, una configuración más difícil.
Es compatible con todo el ciclo de vida de la traducción continua de aplicaciones en desarrollo.
Se basa en el código fuente en inglés.

Usualmente uso las mejores partes de ambos, utilizando YAML para la internacionalización (número y formato de fecha, ¿quizás nombres de modelo?) Y gettext para la traducción.