Nommage des clés dans les fichiers de ressources Meilleure pratique

Question

Est-ce que quelqu'un a des recommandations sur la façon de nommer les clés dans les fichiers de ressources? Par exemple, basez-vous le nom de votre clé sur le texte qui doit être localisé ou sur le contrôle qui utilise le texte?

Disons que vous avez un bouton d'édition dans plusieurs écrans (un pour éditer un utilisateur, un pour éditer un groupe). Vous pouvez utiliser les touches suivantes:

• editUserButton.label = Modifier l'utilisateur ...
• editGroupButton.label = Modifier le groupe ...

ou

• editUser = Modifier Utilisateur ...
• editGroup = Modifier le groupe ...

ou

• user.edit = Modifier l'utilisateur ...
• group.edit = Modifier le groupe ...

Quel système préférez-vous et pourquoi?

Answer 1

Je préfixe mes littéraux par usecase ou par nom de classe d'action. par exemple:

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

De cette façon, vous éviter les collisions:

EditStudent=Edit 
EditClass=Edit 
EditCourse=Edit Course

... et peut également trouver ce dont vous avez besoin plus facile.

Un autre groupe I est par voie entité:

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

Ceux-ci peuvent apparaître comme les en-têtes sur les tables avec les entités. Il vous permet d'économiser dans les cas de ce type:

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

Enfin, en fournissant le contexte dans les clés de propriété, vous pouvez vous sauver de fausses traductions. Par exemple, j'ai eu:

no=no

qui était utilisé comme identifiant (#) en-tête de table sur la cellule supérieure gauche, mais notre traducteur français a fait pour le français:

no=non

... il pensait que c'était le mot "non" (négatif de oui). :)

Le dernier (mais pas le moindre) préfixe avec nom de classe vous aidera lorsque vous voulez refactoriser/renommer des classes et mettre à jour rapidement ces clés de propriétés sans avoir à regarder les modèles.

Answer 2

Je pense que vous devez d'abord utiliser un certain type de fichiers XML pour stocker ce type de données.

Quelque chose comme:

< xml version = "1.0" encoding = "utf-8" autonome = "yes"? >
< xml >
        < bouton >
                < modifier >
                        < utilisateur > *** Modifier l'utilisateur * </utilisateur >
                        < groupe > Modifier groupe </groupe >
                </modifier >
        </bouton >
</xml > **

Et puis utiliser un "traduire" classe pour obtenir (et définir/enregistrer) le texte.

Quelque chose comme:

myTranslateClass.load ('translate.xml');
myTranslateClass.get ('bouton', 'modifier', 'utilisateur');

C'est un exemple simple.

Answer 3

Nous nous basons sur la version anglaise du terme. Ex: EditUser Ce était il est facilement lisible par nos développeurs et peut être réutilisé dans plusieurs endroits ce terme est requis dans toute l'application.

Answer 4

Basez-le sur le texte anglais, mais préfixe avec la fenêtre/dialogue/qu'avez-vous dans lequel le mot ou la phrase apparaît. Au moins, lorsque l'espace réservé est limité, vous pouvez éviter de tomber dans le piège d'avoir exactement la même chaîne partout: cela vous empêche d'abréger pour obtenir des mises en page décentes, en particulier dans les langues polysyllabiques comme le finnois.

Bien sûr, vous devriez toujours vous efforcer d'être cohérent dans l'attribution de noms. Augmenter le nombre de chaînes augmentera également les coûts de traduction si vous le faites commercialement.

Et n'ignorez pas le danger des homonymes. Fournir un contexte aide à prévenir cela. N'ayez pas peur de rendre le nom de la ressource plus long que le terme anglais, cela peut aider les traducteurs de manière substantielle.

Answer 5

+1 pour la réponse de @ cherouvim, mais cela revient toujours à la documentation.

Documentez chaque valeur (en utilisant le mécanisme de commentaire pris en charge par le format de fichier de la source de ressources), y compris le type de données de chaque paramètre si la chaîne est formatable. Par exemple, l'éditeur VS pour le format .resx expose un champ de commentaire qui le rend très facile.

Ainsi, un message comme:

Impossible de planifier le {0} emploi avant {1}.

serait documenté quelque chose comme:

message d'erreur enregistré, {0}: nom du travail, {1} date/heure au format ISO 8601.