internationalization - plugin - loco translate

¿Cómo maneja el proceso de traducción de cadenas? (11)

En Java, la internacionalización se logra moviendo los hilos a los paquetes de recursos ... el proceso de traducción es largo y arduo, pero al menos está separado del proceso de producción del software, liberando paquetes de servicio, etc. Una cosa que ayuda es tener un sistema de CI que reempaca todo en cualquier momento que se realicen cambios. Podemos probar y eliminar una nueva versión en cuestión de minutos, ya sea un cambio de código, un nuevo paquete de idioma o ambos.

Estoy trabajando en un proyecto de software que debe traducirse a 30 idiomas. Esto significa que cambiar cualquier cadena incurre en un costo relativamente alto. Además, la traducción no ocurre de la noche a la mañana, porque el paquete de traducción debe ser trabajado por diferentes traductores, por lo que esto puede llevar un tiempo.

Agregar nuevas características es engorroso de alguna manera. Podemos pensar todas las cadenas que serán necesarias antes de que realmente codifiquemos la interfaz de usuario, pero a veces todavía tenemos que agregar nuevas cadenas debido a correcciones de errores o debido a un descuido.

Entonces la pregunta es, ¿cómo manejas todo este proceso? ¿Algún consejo sobre cómo aliviar el impacto de la traducción en el proyecto de software? ¿Cómo gobernar las cadenas, en lugar de tener las cadenas que lo rigen?

EDITAR: Estamos utilizando Java y todas las cadenas se internacionalizan utilizando los paquetes de recursos, por lo que el problema no es la internacionalización per-se, sino la gestión de las cadenas.

La solución que obtuvimos hasta ahora es tener una pequeña aplicación en Excel que lee todos los archivos de propiedades y luego muestra una matriz con todas las traducciones (idiomas como encabezados, claves como filas). Es bastante evidente lo que falta entonces. Esto se envía a los traductores. Cuando vuelve, la hoja se puede procesar para generar los mismos paquetes de propiedades nuevamente. Hasta ahora, ha aliviado un poco el dolor, pero me pregunto qué más hay alrededor.

Los proyectos localizados en los que he trabajado tenían fechas de "congelación de cadenas". Después de este tiempo, la única forma en que se permitía cambiar las cadenas era con el permiso de un miembro muy antiguo del equipo de gestión del proyecto.

No es exactamente una solución perfecta, pero sí nos permitió poner defectos con respecto a cadenas en espera hasta la próxima versión con una razón válida. Una vez que se ha producido el congelamiento de la cadena, también tiene una razón válida para negar la incorporación de nuevas características al proyecto en las decisiones de ''improviso''. Y tener el permiso de arriba significaba que los mandos intermedios no tendrían poder para cambiar las especificaciones en su :)

No solo utilizamos una base de datos en lugar de los archivos de recursos (nunca he entendido por qué las personas usan algo así, lo que es difícil de manejar, cuando tenemos tan buenas herramientas para tratar con las bases de datos), sino que también evitamos la necesidad de etiquetar las cosas en la aplicación (olvidarse de etiquetar los controles con los números en los formularios VB6 siempre fue un problema) usando el reflejo para identificar los controles para la traducción. Luego usamos un archivo XML que traduce los controles a las ID de frase de la base de datos del diccionario.

Aunque el archivo de mapeo tenía que ser administrado, aún podía ser administrado independientemente del proceso de compilación, y la traducción de la aplicación era realmente posible para los usuarios finales que tenían derechos en la base de datos.

Si está disponible, use una base de datos para esto. Cada cadena obtiene una identificación, y hay una tabla para cada idioma, o una tabla para todos con el idioma en una columna (dependiendo de cómo se accede al sitio, el rendimiento dicta que es mejor). Esto permite actualizaciones de traductores sin intentar administrar archivos de códigos y detalles de control de versiones. Además, es casi trivial ejecutar informes sobre lo que no se traduce, y realizar un seguimiento de lo que fue una autotranslación (motor) frente a una traducción humana real.

Si no hay una base de datos, a continuación, pego cada idioma en un archivo por separado para que se reduzcan los problemas de control de versiones. Pero la estructura es básicamente la misma: cada cadena tiene una identificación.

-Adán

Para empezar, usaría cadenas predeterminadas en caso de que falte una traducción. Por ejemplo, el valor en inglés o español. En segundo lugar, es posible que desee considerar una aplicación web o algo similar para que lo usen sus traductores. Esto requiere algunos recursos por adelantado, pero al menos no necesitará enviar archivos y será obvio para los traductores qué cadenas son nuevas, etc.

Hay una serie de problemas importantes que deben tenerse en cuenta al internacionalizar una aplicación.

No todas las cadenas se crean por igual . Dependiendo del idioma, la duración de una oración puede cambiar significativamente. En algunos idiomas, puede ser la mitad de largo y en otros puede ser el triple de largo. Asegúrese de diseñar sus widgets GUI con espacio suficiente para manejar cadenas que son más grandes que sus cadenas en inglés.
Los traductores generalmente no son programadores . No espere que los traductores puedan leer y mantener los formatos de archivo correctos para los archivos de recursos. Debe configurar un mecanismo donde pueda transformar los datos traducidos de ida y vuelta a sus archivos de recursos a partir de algo así como una hoja de cálculo. Una posibilidad es usar filtros XSL con Open Office, para que pueda guardar en los archivos de recursos directamente en una aplicación de hoja de cálculo. Además, es posible que los traductores o las empresas de servicios de traducción ya tengan sus propias bases de datos, por lo que es bueno preguntar qué usan y escribir algunas herramientas para automatizar.
Necesitará anexar datos a cadenas , no pretenda que nunca tendrá que hacerlo o siempre podrá colocar la cadena al final. Asegúrese de tener una configuración de formateador de cadena para reemplazar marcadores de posición en cadenas. Además, asegúrese de documentar cuáles son los valores típicos que serán reemplazados por los traductores. Recuerde, el orden de los marcadores de posición puede cambiar en diferentes idiomas.
Nombre sus variables de cadena i8n algo que refleje su significado . ¿Realmente desea buscar números en un archivo de recursos para averiguar cuál es el contenido de una cadena dada? Los desarrolladores dependen de poder leer el resultado de la cadena en el código para la eficiencia mucho más de lo que a menudo se dan cuenta.
No tengas miedo a la generación de código . En mi proyecto actual, he escrito un pequeño programa Java llamado por ant que analiza todas las claves del archivo de recursos de idioma predeterminado (maestro) y luego asigna la clave a una constante definida en mi clase de localización. Vea abajo. Las líneas entre los // ---- comentarios se generan automáticamente. Ejecuto el generador cada vez que agrego una cadena.

public final class l7d { ...normal junk

/** * Reference to the localized strings resource bundle. */ public static final ResourceBundle l7dBundle = ResourceBundle.getBundle(BUNDLE_PATH);



//---- start l7d fields ----/
public static final String ERROR_AuthenticationException;
public static final String ERROR_cannot_find_algorithm;
public static final String ERROR_invalid_context;
...many more
//---- end l7d fields ----/
static {

    //---- start setting l7d fields ----/
    ERROR_AuthenticationException = l7dBundle.getString("ERROR_AuthenticationException");
    ERROR_cannot_find_algorithm = l7dBundle.getString("ERROR_cannot_find_algorithm");
    ERROR_invalid_context = l7dBundle.getString("ERROR_invalid_context");
    ...many more
    //---- end setting l7d fields ----/
}

El enfoque anterior ofrece algunos beneficios.

Dado que su clave de cadena ahora se define como un campo, su IDE debería ser compatible con la finalización del código. Esto te ahorrará mucho tipo. Es realmente frustrante buscar cada nombre clave y corregir errores tipográficos cada vez que desee imprimir una cadena.
Alguien por favor corrígeme si estoy equivocado. Al cargar todas las cadenas en la memoria en la instanciación estática (como en el ejemplo) se obtendrá un tiempo de carga más rápido a costa de un uso de memoria adicional. He descubierto que la cantidad adicional de memoria utilizada es insignificante y vale la pena compensarla.

Este libro de google - gestión de archivos de recursos da algunos buenos consejos

Puede utilizar el software Resource File Management para realizar un seguimiento de las cadenas que han cambiado y controlar el flujo de trabajo para que se traduzcan; de lo contrario, terminará en un caos de congelaciones y control de versiones autoritario

Algunas herramientas que hacen este tipo de cosas, ninguna conexión y no las he usado, solo estoy investigando

http://www.sisulizer.com/

http://www.translationzone.com/es/products/

Puse un objetivo de archivo que encuentra todos los archivos .properties y los coloca en un archivo zip para enviar a los traductores. Ofrecí enviarles solo diffs, pero por alguna razón quieren el conjunto completo de archivos cada vez. Creo que tienen su propio sistema para rastrear solo las diferencias, porque nos cobran en función de cuántas cadenas han cambiado de una vez a la siguiente. Cuando recibo su devolución, difuto manualmente todos sus archivos con la entrega anterior para ver si algo inesperado ha cambiado, una vez que todas las cadenas PT_BR (portugués de Brasil) cambiaron, y resultó que habían usado un PT_PT (Portugués Portugués) ) traductor para ese lote a pesar del orden para PT_BR.

Pootle es una aplicación web que permite administrar el proceso de traducción a través de la web.

No estoy seguro de la plataforma en la que se está internacionalizando. He escrito una respuesta antes sobre la mejor forma de encontrar una aplicación. Consulte ¿Qué necesito saber para globalizar una aplicación asp.net?

Dicho eso, gestionar las traducciones es difícil. El problema es que usará la misma pieza de texto en varias páginas. Sin embargo, su marco de trabajo no puede admitir solo tener ese texto en un archivo (los archivos de recursos en asp.net, por ejemplo, lo alientan a tener un archivo de recursos por idioma).

La forma en que encontramos trabajar con cosas fue tener un repositorio central de bases de datos de traducciones. Creamos una pequeña aplicación .NET para importar traducciones de archivos de recursos en esa base de datos y para exportar traducciones de esa base de datos a archivos de recursos. Por lo tanto, hay un paso adicional en el proceso de compilación para compilar los archivos de recursos.

El otro problema que tendrá es pasar las traducciones a su proveedor de traducción y viceversa. Hay varias maneras de hacerlo: vea si su proveedor de traducción está dispuesto a aceptar archivos XML y devolver archivos XML formateados correctamente. Esta es, realmente, una de las mejores maneras, ya que le permite automatizar su importación y exportación de archivos de traducción. Otra alternativa, si su proveedor lo permite, es crear un sitio web para permitirles editar las traducciones.

Al final, su respuesta para las traducciones será la misma para cualquier otro proceso que requiera repetición y trabajo manual. Automatice, automatice, automatice. Automatice todo lo que pueda. Copiar y pegar no es tu amigo en este escenario.