¿Cuál es la forma correcta de nombrar las propiedades del mensaje en i18n?

Question

Tenemos un sitio web que debe traducirse a diferentes idiomas. Algunas de las palabras están en los archivos de propiedades del mensaje listos para la traducción. Ahora quiero agregar el resto del texto en estos archivos.

¿Cuál es una buena manera de nombrar los bloques de texto?

<view>.<type>.<name> 

Principalmente tenemos páginas web y algunos de los elementos/módulos se repiten en algunos sitios.

Answer 1

Por lo que sé, no existe un "estándar". Por lo tanto, es bastante difícil determinar qué es lo correcto y cuál es la forma incorrecta de nombrar las claves de recursos. Sin embargo, basado en mi experiencia, que podría recomendar esta manera:

property file name: <module>.properties 
resource keys: <view or dialog>[.<sub-context>].<control-type>.<name> 

Podemos discutir si se trata de manera adecuada para poner cada cuerdas de un módulo en uno archivos de propiedades - probablemente podría ser correcta si no lo hace actualizaciones sucede a menudo y no hay tantos mensajes. De lo contrario, podría pensar en un archivo por vista.

En cuanto a la estrategia clave de nomenclatura: es importante que el traductor (suena como película con honorable gobernador Arnold S. no es así?) Que tienen un contexto. De hecho, la traducción puede depender de ella, es decir, en polaco, usted traduciría un mensaje de una manera diferente si es una página/diálogo/cualquier título y de una manera totalmente diferente si se trata de texto en un botón.

Un ejemplo de tales recursos clave podría ser:

preferences.password_area.label.username=User name 

Se da suficientes pistas para el traductor acerca de lo que realmente es, lo que podría resultar en la traducción correcta ...

Answer 2

Yo propondría el siguiente convención

functionalcontext.subcontext.key 
logicalcontext.subcontext.key 

esta manera se puede agrupar lógicamente todos los mensajes comunes en un contexto super (id en el ejemplo a continuación). Hay algunas cosas que no son específicas de ningún contexto funcional (como lastName, etc.) que puede agrupar en contexto lógico.

order.id=Order Id 
order.submission.submit=Submit Order 
name.last=Last Name 

Answer 3

se nos ha ocurrido con la siguiente convención de nomenclatura clave (Java, por cierto) usando la notación de punto y el caso de camellos:

teclas de etiquetas (títulos formar etiquetas, página/forma/de aplicaciones, etc ... es decir, no frases completas, que se utiliza en múltiples ubicaciones de interfaz de usuario):

Si la etiqueta representa un campo Java (es decir, un campo de formulario) y coincide con la etiqueta forma: label.nameOfField
Else: label.sameAsValue

Ejemplos:

• label.firstName = Nombre
• label.lastName = Apellido
• label.app licationTitle = Título de la aplicación
• label.editADocument = editar un documento

claves de contenido:.

projectName.uiPath.messageOrContentType.n *

Dónde:

• projectName es el nombre corto del proyecto (o un nombre derivado del paquete de Java)
• uiPath es la ruta de navegación de interfaz de usuario con el contenido clave
• messageOrContentType (por ejemplo, añadido, suprimido, actualizada, información, advertencia, error, título, contenido, etc.) debe ser añadido basado en el tipo de contenido. Mensajes de ejemplo: (1) La página ha sido actualizada. (2) Hubo un error al procesar su solicitud.
• n. * maneja los siguientes casos: cuando hay varias áreas de contenido en una sola página (por ejemplo, cuando el contenido está separado por una imagen, etc.), cuando el contenido está en varios párrafos o cuando el contenido está una lista ordenada (no) - se debe agregar un identificador numérico. Ejemplo: ... content.1, ... content.2
  
  Cuando hay varias áreas de contenido de una página y una o más necesidad de ser roto más arriba (basado en el ejemplo HTML anterior), un identificador numérico secundario se puede anexar a la clave. Ejemplo: ... content.1.1, ... content.1.2

Ejemplos:

• training.mySetup.myInfo.content.1 = esta es la primera frase del contenido 1. Esta es la segunda oración del contenido 1. Este contenido estará rodeado por etiquetas de párrafo.
• training.mySetup.myInfo.content.2 = Esta es la primera oración del contenido 2. Esta es la segunda oración del contenido 2. Este contenido también estará rodeado por etiquetas de párrafo.
• training.mySetup.myInfo.title = Mi información
• training.mySetup.myInfo.updated = Su información personal ha sido actualizada.

ventajas/desventajas:

---

teclas

+ etiqueta puede ser fácilmente reutilizados; la ubicación es irrelevante.
+ Para las claves de contenido que no se reutilizan, la ubicación de la página en la interfaz de usuario será simple y lógica.

- Puede no ser claro para los traductores que las claves de etiqueta residen en la interfaz de usuario. Esto puede no ser un problema para los traductores que no navegan por las páginas, pero puede ser un problema para los desarrolladores.
- Si las claves de contenido se deben usar en más de una ubicación en la UI (lo cual es muy probable), la elección del nombre de la clave no tendrá sentido en la (s) otra (s) ubicación (es).En nuestro caso, la administración no se preocupa por una duplicación de valores para las áreas de contenido, por lo que usaremos diferentes claves (para demostrar la ubicación en la interfaz de usuario) en este caso.

---

Comentarios sobre esta convención - especialmente retroalimentación que mejorarlo - sería muy apreciada ya que estamos renovando actualmente nuestros paquetes de recursos! :)

Answer 4

el método que he usado personalmente y que me ha gustado más hasta ahora es usar la frase para localizar como la clave. Por ejemplo: (por favor reemplace T con la sintaxis correcta de forma fiable en el idioma)

por ejemplo: de impresión (T ("Hola mundo"))

en este caso T buscará una clave "Hola mundo ". Si no se encuentra, se devuelve la clave, de lo contrario, el valor de la clave.

De esta manera, no es necesario para editar el mensaje (en su idioma predeterminado) al menos eso es necesario utilizar parámetros .... Me salvó un montón de tiempo dev