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

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 determinada cadena.

Incluso si dos etiquetas siempre contienen la misma cadena en inglés (o en su idioma nativo), no necesariamente serán 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.

Puedes evitar algunas traducciones múltiples creando controles adicionales. P.ej. un CancelButton y un OKButton que ya contienen su texto, y ahora Cancelar / Abbrechen OK / OK deben traducirse solo una vez. Pero eso es casi un caso especial.

Esta es la forma en que lo manejamos en mi empresa:

convención de nomenclatura: Nombramos etiquetas prefijándolos con su clase / sección / forma / etc. Por ejemplo, loadFile_loadButton , loadFile_fileNameLabel , loadFile_cancel son 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 más que las convenciones 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. nombrados loadFileLoadButton , loadFileNameLabel y loadFileCancel . Puede pensar que la diferencia no es tan grande, pero cuando tiene miles de etiquetas, el efecto compuesto vale la pena.

Comentarios de encabezado: Además de prefijar los nombres de etiquetas, también agregamos comentarios de "encabezado" a los archivos de recursos para definir claramente las agrupaciones de etiquetas. De esta manera, alguien que desee modificar o agregar etiquetas específicas relacionadas con una clase / sección / formulario / etc en particular puede encontrar todas las etiquetas relacionadas con ese elemento en particular en un solo lugar, bajo un encabezado, y puede proceder fácilmente a agregar o modificar etiquetas fácilmente. sabiendo que no interrumpirán las traducciones de ningún otro elemento (en mi humilde opinión, esto también es un punto muy importante sobre por qué es necesario 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 sobre cómo manejar esto en Herramientas del comercio).

Como han señalado otros, una etiqueta en un idioma puede traducirse de dos o más formas diferentes en otros idiomas, según los contextos que se presenten. Si "unifica" las etiquetas, al traductor le será muy difícil encontrar una única 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 y cuando 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 realizar sus traducciones, puede crear su propia herramienta que busca etiquetas similares que existen en sus paquetes, y ofrecer sus traducciones como valores predeterminados para nuevas etiquetas, o incluso puede utilizar servicios existentes como < a href="https://www.getlocalization.com"> this , que proporciona herramientas como la que acabo de mencionar, lo que simplifica la traducción de nuevas etiquetas (incluso más si se repiten varias veces, ya que la herramienta le ofrecerá varias opciones de traducción por defecto para las nuevas etiquetas).

Resumiéndolo: La duplicación justificada y el hecho de tener etiquetas agrupadas de manera contextual realmente ayuda a los traductores a hacer su trabajo. Gran tiempo Solo piénselo: tener un contexto hace mucho para ayudar al traductor a seleccionar la traducción adecuada. Y permitir duplicados "justificados" elimina el conflicto de tener que seleccionar una traducción que se adapte mal a algunos contextos (pero de todos modos es el mejor ajuste global).

Espero que esto ayude!

Cuando hice esto en el pasado, recorrimos la ruta del archivo de recursos que contiene oraciones completas. Si la misma oración exacta se usara repetidamente, pero si fueran solo 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 por la traducción (con algunos datos de indexación al final para una búsqueda rápida).

Para indicaciones o botones de datos pequeños, como un nombre de campo de "Código postal" o un botón de "Aceptar", almacenará la cadena "Código postal" seguida de la traducción y la usará donde sea necesaria esa cadena completa . Pero (a menos que rompamos una cadena manualmente) no lo utilizaríamos para el "Código postal" que aparece en una oración.

Utilizando el ejemplo de su código postal, si intenta traducirlo por su cuenta y lo reemplaza en todas las oraciones que lo utilizan, obtendrá una traducción 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 la 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 las hizo acaba de traducir las palabras individuales, no la oración completa.

Siempre hemos encontrado que lo mejor es traducir oraciones en conjunto, sin dividirlas. Tuvimos marcadores de posición para los datos que se necesitaban insertar (por ejemplo, "Número de pieza @ 1 es redundante") y el traductor podría mover el marcador de posición al lugar que deseaban para una buena traducción.

Sin embargo, encontramos que permitir el uso de sitios que usaban exactamente la misma oración, la misma solicitud de datos o la misma etiqueta de botón, etc., era correcto compartir las 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 el texto localizado.
• La etiqueta debe ser "de tamaño mental". Eso es ... tan breve como práctico y sin ambigüedades.
• Las etiquetas deben seguir un formato coherente para maximizar la previsibilidad y el recuerdo.

Implementación

• Reduzca la carga cognitiva con el uso consistente de abreviaturas 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 de lo más general a lo más específico. (es decir, msgFileMissing, msgFileSaved, msgFileDeleted).
• Inglés es un lenguaje ordenado de verbo-sustantivo. Muchos (¿la mayoría?) Otras lenguas son sustantivo-verbo. Noun-verb funciona mejor para la agrupación jerárquica.