¿Cómo organizar los recursos de cadena de localización?

Estamos desarrollando una aplicación grande, que consta de muchos paquetes pequeños. Cada paquete tiene su propio conjunto de archivos de recursos para la localización.

¿Cuál es el mejor enfoque para organizar y nombrar las cadenas de localización?

Aquí están mis pensamientos hasta ahora:

Manejo de duplicados

El mismo texto (por ejemplo, "Código postal") puede aparecer varias veces dentro de un paquete dado. El instinto de programación (DRY) me dice que cree un único recurso de cadena compartido por todas las ocurrencias .

Por otra parte, un traductor puede elegir una traducción larga ("Postleitzahl") en algunos lugares y una más corta ("PLZ") en lugares con menos espacio. O podemos decidir agregar dos puntos a algunas ocurrencias ("Código postal:"), pero no a otras. O podemos requerir una capitalización diferente ("código postal") en algunos lugares. Todos estos argumentos apuntan a crear un recurso por uso, incluso si sus contenidos son idénticos .

Nombrar

Si buscamos eliminar duplicados, tiene sentido nombrar los recursos por contenido , tal vez insinuando el tipo de uso a través del prefijo. Entonces podemos tener labelOK= "OK" , messageFileTooLarge= "El archivo excede el tamaño máximo de archivo". , y labelZipCode= "Código postal" .

Nombrar por contenido tiene la ventaja de manejar los argumentos de formato de forma natural: el recurso messageFileHas_0_MBWhileMaximumIs_1_MBclaramente toma dos argumentos de formato, el tamaño real del archivo y el tamaño máximo del archivo.

Sin embargo, si permitimos duplicados, nombrar solo por contenido no tiene sentido. Para obtener nombres de recursos únicos, de alguna manera debemos incluir el lugar de uso en el nombre del recurso. Eso funciona para los controles gráficos, aunque los identificadores tienden a ser un poco largos: fileSelectionConfirmationButtonText= "OK" , customerDetailsTableColumnZipCode= "Código postal" . Sin embargo, para archivos de código no visual, se vuelve más difícil. ¿Cómo nombra un uso específico de una cadena si no sabe dónde se mostrará eventualmente? ¿Por archivo de código y nombre de función? Parece bastante torpe y frágil para mí.

En general, me inclino por permitir duplicados, pero estoy luchando por encontrar un esquema de nomenclatura consistente que lo respalde.

Editar: esta pregunta tiene dos aspectos: cómo organizar los recursos (DRY vs. duplicados) y cómo nombrarlos . Hasta ahora, las respuestas se han concentrado en el primer aspecto. Agradecería algunos comentarios sobre convenciones de nomenclatura!

Aceptaría la duplicación siempre que no pueda estar absolutamente seguro de que el significado es exactamente el mismo en todos los casos en que se utiliza una cadena determinada.

Incluso si dos etiquetas siempre contienen la misma cadena en inglés (o su lengua materna), no serán necesariamente las mismas en todos los idiomas. Aceptar la duplicación puede darle a usted (o más bien a los traductores) la flexibilidad necesaria para manejar tales situaciones.

Como ejemplo: considere una etiqueta "Condición", que, según el contexto, podría traducirse a "Zustand" o "Bedingung" en alemán (entre muchas otras traducciones posibles).

Acepta algunos duplicados.

Puede evitar algunas traducciones múltiples creando controles adicionales. Por ejemplo , ay CancelButtonuna OKButtonque ya contiene su texto, y ahora Cancelar / Abreviar OK / OK solo deben traducirse una vez. Pero ese es casi un caso especial.

Así lo manejamos en mi empresa:

Convención de nomenclatura: nombramos las etiquetas con el prefijo de su clase / sección / formulario / etc. Por ejemplo loadFile_loadButton, loadFile_fileNameLabel, loadFile_cancelson todas las etiquetas que pertenecen a un diálogo Cargar archivo. Aunque esta convención de nomenclatura subrayada no es la más común, la favorecemos sobre las convenciones más estándar porque mejora la legibilidad y la "agrupabilidad": observe lo fácil que es ver a qué elemento pertenecen las etiquetas y qué representa cada etiqueta, en comparación con las etiquetas llamado loadFileLoadButton, loadFileNameLabely loadFileCancel. Puede pensar que la diferencia no es tan grande, pero cuando tiene miles de etiquetas, el efecto compuesto lo vale.

Comentarios de encabezado: además de prefijar los nombres de las etiquetas, también agregamos comentarios de "encabezados" a los archivos de recursos para definir claramente los grupos de etiquetas. De esta manera, alguien que quiera modificar o agregar etiquetas específicas relacionadas con una clase / sección / formulario / etc. particular puede encontrar todas las etiquetas relacionadas con ese elemento en particular en un solo lugar, debajo de un encabezado, y puede proceder a agregar o modificar etiquetas fácilmente sabiendo que no romperán las traducciones de ningún otro elemento (en mi humilde opinión, este también es un punto muy fuerte sobre por qué necesita permitir la duplicación).

Los duplicados "justificados" son deseables: como se mencionó anteriormente, estas prácticas conducirán definitivamente a etiquetas duplicadas, pero no vemos ningún problema con eso (más información sobre cómo manejar esto en Herramientas del oficio).

Como otros han señalado, una etiqueta en un idioma se puede traducir de dos o más formas diferentes en otros idiomas, según los contextos que se presenten. Si "unifica" las etiquetas, el traductor tendrá dificultades para encontrar una sola etiqueta que se adapte a todos los contextos donde se encuentra. Entonces, tal como lo vemos, permitir duplicados "justificados" ayuda a mejorar la calidad de la localización, siempre que no se refieran a lo mismo en el mismo contexto (este es el significado de "justificado").

Herramientas del oficio: para ser lo más efectivo posible al hacer sus traducciones, puede crear su propia herramienta que busque etiquetas similares que existan en sus paquetes, y ofrecer sus traducciones como valores predeterminados para nuevas etiquetas, o incluso puede use servicios existentes como este , que proporcionan herramientas como la que acabo de mencionar, lo que facilita la traducción de nuevas etiquetas (aún más si se repiten varias veces, ya que la herramienta le ofrecerá varias opciones de traducción por defecto para las nuevas etiquetas )

En resumen: la duplicación justificada y tener etiquetas agrupadas de manera contextual realmente ayuda a los traductores a hacer su trabajo. A lo grande. Piénselo bien: tener contexto ayuda mucho al traductor a seleccionar la traducción adecuada. Y permitir duplicados "justificados" elimina el conflicto de tener que seleccionar una traducción que se ajuste mal a algunos contextos (pero de todos modos es el mejor ajuste general).

¡Espero que esto ayude!

Cuando hice esto en el pasado, seguimos la ruta del archivo de recursos que contiene oraciones completas. Si la misma oración exacta se usara repetidamente excelente, pero si solo fueran palabras individuales dentro de una oración, esas palabras se duplicarían.

Estábamos atados a un marco donde el archivo de recursos solo contenía una lista de frases en inglés seguidas de la traducción (con algunos datos de indexación al final para una búsqueda rápida).

Para mensajes o botones de datos pequeños, como un nombre de campo de "Código postal" o un botón de "Aceptar", almacenaría la cadena "Código postal" seguida de la traducción y la usaría siempre que se requiriera esa cadena completa. Pero (a menos que separemos manualmente una cadena) no la usaría para el "Código postal" que aparece en una oración.

Usando su ejemplo de código postal, si intenta traducirlo por sí mismo y reemplazarlo en todas las oraciones que lo usan, obtendrá una traducción muy, muy mala.

Por ejemplo, "El código postal debe ingresarse" podría necesitar traducir el equivalente literal de "El código postal ingresado debe estar" en otro idioma. Si corta una oración, no obtiene esa inversión de palabras requerida en otro idioma.

Es por eso que algunas traducciones mal hechas al inglés se ven tan ridículas, la persona que lo hace solo tradujo las palabras individuales, no toda la oración.

Siempre nos pareció mejor traducir las oraciones en su conjunto, sin separarlas. Teníamos marcadores de posición para los datos que debían insertarse (por ejemplo, "El número de pieza @ 1 es redundante") y el traductor podía mover el marcador de posición a la posición que deseaban para una buena traducción.

Sin embargo, descubrimos que permitir lugares que usaban exactamente la misma oración, o la misma solicitud de datos o la misma etiqueta de botón, etc., estaban bien para compartir traducciones. Eso nunca surgió como un problema y ahorró tiempo / costo para el traductor.

Tu pensamiento sobre nombrar es bueno.

Objetivos

• Defina una etiqueta común (es decir, nombre de variable) para texto localizado.
• La etiqueta debe ser "tamaño de la mente". Eso es ... tan breve como práctico sin ser ambiguo.
• Las etiquetas deben seguir un formato consistente para maximizar la previsibilidad y el recuerdo.

Implementación

• Reduzca la carga cognitiva con el uso constante de abreviaturas bien conocidas (es decir, msg = mensaje, lbl = etiqueta, btn = botón, ...)
• Las herramientas presentan variables / etiquetas en listas alfabéticas, por lo que la búsqueda humana es mejor cuando las etiquetas relacionadas se agrupan. Haga los nombres jerárquicos del más general al más específico. (es decir, msgFileMissing, msgFileSaved, msgFileDeleted).
• El inglés es un idioma ordenado por verbos y sustantivos. Muchos (¿la mayoría?) Otros idiomas son sustantivo-verbo. El verbo sustantivo funciona mejor para la agrupación jerárquica.