Nombrar claves en las mejores prácticas de archivos de recursos

Question

¿Alguien tiene alguna recomendación sobre el nombramiento de claves en los archivos de recursos? Por ejemplo, ¿basa el nombre de su clave en el texto que necesita ser localizado o en el control que usa el texto?

Supongamos que tiene un botón de edición en varias pantallas (una para editar un usuario, otra para editar un grupo). Usted podría utilizar las siguientes teclas:

• editUserButton.label = Editar usuario ...
• editGroupButton.label = Editar grupo ...

o

• editUser = Editar Usuario ...
• editarGrupo = Editar grupo ...

o

• user.edit = Editar usuario ...
• group.edit = Editar grupo ...

Qué esquema Qué prefieres y por qué?

Answer 1

Prefijo mis literales por usecase o action classname. por ejemplo:

PlaceOrder.invalidId=Invalid id for order {0} 
PlaceOrder.success=Your order {0} was successful 
PlaceOrder.fail.visa=Your visa was ... 
PlaceOrder.fail.communications=We could not... 
PlaceOrder.submit=Buy now 

Login=Login 
Login.fail=Your credentials did not... 
Login.alread=You are already logged in

esta manera se evita colisiones:

EditStudent=Edit 
EditClass=Edit 
EditCourse=Edit Course

... y también se puede encontrar lo que necesita más fácil.

Otro grupo de manera que es de entidad:

Person.id=# 
Person.name=First name 
Person.surname=Surname

Estos pueden aparecer como encabezados en tablas con las entidades. Esto le ahorra en casos como este:

Person.id=# 
Class.id=# 
Course.id=Course Id

Por último, proporcionando contexto en las claves de propiedad que puede ahorrarse de traducciones falsas. Por ejemplo, una vez que tuve:

no=no

que estaba siendo utilizado como un encabezado de ID (#) en la mesa de la celda superior izquierda, pero nuestro traductor francés hizo esto para el francés:

no=non

... él pensó que era la palabra "no" (negativa de sí). :)

El último (pero no menos importante) prefijo con nombre de clase lo ayudará cuando desee refactorizar/cambiar el nombre de las clases y actualizar rápidamente estas claves de propiedad sin tener que mirar las plantillas.

Answer 2

Creo que, en primer lugar, debe usar algún tipo de archivo XML para almacenar ese tipo de datos.

algo como:?

< xml version = "1.0" encoding = autónomo "UTF-8" = "yes"? >
< botón xml >
        < >
                < edición >
                        < usuario > *** Editar usuario * </usuario >
                        < grupo > Editar grupo </grupo >
                </editar >
        </botón >
</xml > **

Y a continuación, utilizar una clase de "traducir" para obtener (y establecer/guardar) el texto.

Algo así como:

myTranslateClass.load ('translate.xml');
myTranslateClass.get ('botón', 'editar', 'usuario');

Ese es un ejemplo simple.

Answer 3

Lo basamos en la versión en inglés del término. Ej: EditUser Eso fue fácil de leer por nuestros desarrolladores y se puede reutilizar en varias ubicaciones, ese término es obligatorio en toda la aplicación.

Answer 4

Base en el texto en inglés, pero el prefijo con la ventana/diálogo/qué tiene usted en el que aparece la palabra o frase. Al menos cuando el espacio de diseño es limitado, es posible que desee evitar caer en la trampa de tener exactamente la misma cadena en todas partes: esto le impide abreviar para obtener diseños decentes, especialmente en lenguajes polisilábicos como el finlandés.

Por supuesto, todavía debe esforzarse por ser coherente al nombrar cosas. Aumentar el número de cadenas también aumentará los costos de traducción si está haciendo esto comercialmente.

Y no ignore el peligro de homónimos. Proporcionar contexto ayuda a prevenir eso. No tenga miedo de que el nombre del recurso sea más extenso que el término en inglés real, esto puede ayudar a los traductores de manera sustancial.

Answer 5

+1 para la respuesta de @ cherouvim, pero siempre se trata de documentación.

Documente cada valor (utilizando el mecanismo de comentario compatible con el formato del archivo fuente del recurso), incluido el tipo de datos de cada parámetro si la cadena es formatable. Por ejemplo, el editor VS para el formato .resx expone un campo de comentario que lo hace muy fácil.

Así que un mensaje como:

que no puede programar la tarea {0} antes {1}.

se deberán documentar como algo parecido a:

mensaje de error registrados, {0}: nombre del trabajo, {1} de fecha/hora en formato ISO 8601.