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

13

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 determinado. El instinto de programación (DRY) me dice que cree un solo recurso de cadena compartido por todas las apariciones .

De nuevo, un traductor puede querer elegir una traducción larga ("Postleitzahl") en algunos lugares y una más corta ("PLZ") en lugares con menos espacio. O podemos decidir agregarle dos puntos a algunas apariciones ("Código postal:"), pero no a otras. O podemos requerir una mayúscula diferente ("código postal") en algunos lugares. Todos estos argumentos apuntan a crear un recurso por uso, incluso si su contenido es idéntico .

Naming

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

La denominación por contenido tiene la ventaja de manejar los argumentos de formato de forma natural: el recurso messageFileHas_0_MBWhileMaximumIs_1_MB toma claramente dos argumentos de formato, el tamaño real del archivo y el tamaño máximo del archivo.

Sin embargo, si permitimos duplicados, la nomenclatura por contenido solo 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 con los controles gráficos, aunque los identificadores tienden a ser un poco largos: fileSelectionConfirmationButtonText = "OK" , customerDetailsTableColumnZipCode = "Código postal" . Sin embargo, para los archivos de código no visual, se hace más difícil. ¿Cómo nombra un uso específico de una cadena si no sabe dónde se mostrará finalmente? ¿Por archivo de código y nombre de función? Me parece bastante torpe y quebradizo.

En general, me inclino por permitir duplicados, pero estoy luchando para encontrar un esquema de nombres coherente que admita esto.

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

    
pregunta Daniel Wolf 02.08.2016 - 10:15

5 respuestas

8

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).

    
respondido por el Hulk 02.08.2016 - 14:20
2

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.

    
respondido por el Bernhard Hiller 02.08.2016 - 13:45
2

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!

    
respondido por el carlossierra 11.08.2016 - 05:38
1

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.

    
respondido por el RosieC 02.08.2016 - 11:34
0

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.
respondido por el DocSalvager 05.08.2016 - 04:47

Lea otras preguntas en las etiquetas