Continuando la discusión sobre las ventajas de Fluent sobre el gettext habitual, publico la posición oficial de los creadores de Fluent en la traducción.
Gettext es un sistema de localización profundamente arraigado en el proyecto GNU y sus soluciones arquitectónicas asociadas.
El proyecto Fluent considera que gettext es un buen ejemplo de un ecosistema completo de bibliotecas y herramientas independientes de plataforma de bajo nivel para administrar el ciclo completo de lanzamiento del producto con archivos de localización en un formato legible. Al mismo tiempo, el paradigma Fluent nos lleva a otras soluciones arquitectónicas en aspectos importantes de localización, que, a su vez, conducen a API y ciclos de vida completamente diferentes.
En otras palabras, gettext es un gran proyecto, pero no compartimos sus puntos de vista sobre el enfoque de localización.
Estas son las principales diferencias entre gettext y Fluent:
Arreglo
La diferencia más importante entre gettext y Fluent es el identificador del mensaje. Gettext decidió utilizar la cadena de origen (generalmente en inglés) como identificador. Esta elección parece simple, pero luego impone muchas restricciones.
En primer lugar, con este enfoque, cualquier cambio en la línea original invalida todas las traducciones asociadas. Esto aumenta seriamente la carga en los desarrolladores, forzándolos a nunca cambiar los mensajes originales, ya que esto requerirá actualizar todas las traducciones.
En segundo lugar, complica la introducción de varios mensajes con el mismo texto en el idioma de origen, que deben traducirse de diferentes maneras. Por ejemplo, el texto para el botón "Abrir" y para la marca "Abrir" se puede traducir de diferentes maneras, ya que el primer texto es un comando y el segundo es una descripción. Gettext tiene una línea de contexto
msgctxt opcional para distinguir entre líneas con el mismo segmento de origen. Este enfoque asigna la responsabilidad de reconocer tales situaciones a los desarrolladores, lo que contradice el principio de separación de intereses.
Fluido no recomienda reutilizar textos precisamente por esta razón. Separar el texto fuente de otras traducciones también es importante para nuestra capacidad de ingresar mensajes compuestos (que contienen múltiples líneas para una unidad de traducción, adjunta a un widget de interfaz de usuario) y para enlaces de mensajes basados en identificadores.
Fluent establece un "acuerdo" entre desarrolladores y localizadores. El desarrollador ingresa un identificador único y un conjunto de variables (número de mensajes no leídos, nombre de usuario, etc.), y el localizador, usando la sintaxis Fluent, decide cómo construir el texto del mensaje para este identificador.
El desarrollador no debe preocuparse por la implementación detallada de las traducciones de dichos mensajes. Todo lo que un desarrollador necesita es obtener una sola línea de texto adecuada para un lugar específico en la interfaz de usuario para solicitar una cadena por un identificador específico.
Opciones de mensaje
Gettext admite un pequeño conjunto de funciones para la internacionalización, en particular para los plurales. Pero dicha sintaxis plural es un caso especial, además de la sintaxis estándar de gettext, y es difícil de escalar para otros casos que requieren variabilidad.
Fluent admite el concepto básico de variación de cadena, que puede usarse con selectores. Por lo general, la regla plural será un selector de este tipo, pero dependiendo de las características gramaticales del idioma, puede haber otros, como el género, la declinación o incluso el entorno, por ejemplo, la hora del día o el sistema operativo. La sintaxis fluida permite a los localizadores considerar todas estas características y crear texto que coincida exactamente con la situación.
Argumentos externos
Gettext no admite argumentos externos. En otras palabras, no puede especificar el formato de los parámetros: números, fechas. Para formatear parámetros en gettext, se recomienda devolver una cadena, que se pasará a
printf o ejecutará
String.prototype.replace en la cadena resultante.
En Fluent, el soporte para argumentos externos es el núcleo de la sintaxis. Los argumentos externos no solo se interpolan, sino que también se usan como parámetros para el selector, y también se pueden transferir a funciones integradas. Esto permite a los localizadores crear textos mucho más precisos para casos específicos. Además de eso, Fluent coloca marcadores
FSI / PDI alrededor de los objetos para proteger el aislamiento de directividad en texto bidireccional, y prohíbe cualquier manipulación de cadenas de hojas, reduciendo la carga sobre los desarrolladores.
Aislamiento de responsabilidad
Además, la forma en que gettext maneja reglas plurales requiere que el diseñador del sistema elija si el mensaje será un mensaje multivariante o una sola línea. Desde el punto de vista de Fluent, el desarrollador no debe lidiar con tales problemas. En muchos casos, cuando una opción es suficiente en inglés, en otros idiomas necesita agregar variantes con plurales.
Fluido supone que el desarrollador no debe tener un conocimiento lingüístico similar al desarrollar software con muchas configuraciones regionales, y cada idioma debe tener una cierta libertad de acción durante la localización.
Como resultado, Fluent almacena cada traducción por separado, sin "filtrar" los requisitos de un idioma a otros, y mantiene todas las traducciones "opacas" para un desarrollador que no necesita preocuparse por las funciones que los localizadores pueden necesitar para una línea determinada.
Cancelación de una transferencia.
En el ciclo de desarrollo, hay tres situaciones en las que la traducción se "cancela" (deja de ser válida) en relación con el original:
- Cambio menor: no afecta la traducción (puntuación correcta, errores tipográficos).
- Cambio medio: afecta el diseño del mensaje, pero no cancela la corrección de la traducción asociada (por ejemplo, Mostrar todos los marcadores -> Mostrar el Administrador de marcadores ).
- Cambio significativo: el nuevo significado de la oración ( Haga clic para guardar -> Haga clic para abrir ).
Por razones arquitectónicas, gettext combina los tres niveles en un solo estado llamado
fuzzy . Cualquier cambio en la línea de origen (al menos completo, al menos insignificante) conduce a la cancelación de las traducciones.
En Fluent, el uso de identificadores únicos le permite mantener dos de estos niveles separados del tercero: cuando realiza
pequeños cambios en el texto fuente de una línea y cuando guarda el identificador, las traducciones siguen siendo válidas. Por otro lado, si el desarrollador cambia el identificador, todas las traducciones se cancelan y será necesario actualizarlas.
Creemos que una solución arquitectónica de este tipo es más beneficiosa para la mayoría de los ciclos de lanzamiento, aunque reconocemos que para los cambios de nivel
medio , el desarrollador tendrá que elegir entre guardar o cambiar el identificador (es decir, entre un cambio
menor y un cambio
significativo ).
También estamos considerando la idea de la
versión del mensaje para que el desarrollador pueda marcar el mensaje como
actualizado sin invalidar por completo su contenido. Este estado le permitirá mantener la traducción válida en función del punto en que la versión anterior de la traducción sigue siendo mejor que la cadena no traducida, y al mismo tiempo permitirá que las herramientas notifiquen al localizador sobre la necesidad de actualizar la traducción.
Formato de datos
Gettext utiliza tres formatos de archivo: * .po, * .pot y * .mo. Esto afecta la implementación de gettext en el ciclo de producción al agregar pasos como extraer y compilar mensajes.
Fluent utiliza un único formato de archivo * .ftl, que simplifica la implementación y no requiere pasos adicionales que puedan generar discrepancias en los datos.
Soporte Unicode
Gettext se puede codificar en UTF-8. En general, aquí es donde termina el soporte Unicode. Utiliza su propio conjunto de datos para plurales, no sabe cómo formatear fechas y números, no ayuda a trabajar con textos bidireccionales.
Fluent utiliza ampliamente las bibliotecas estandarizadas y los algoritmos CLDR, ICU y ECMA402, combinando perfectamente la localización y la internacionalización.
Conclusión
Creemos que la API y la sintaxis Fluent representan una mejora significativa sobre gettext, y le recomendamos que los use para software internacional.
Más sobre fluidez