Attribution de noms aux clés dans les fichiers de ressources

Question

Quelqu'un at-il des recommandations sur les noms de clés dans les fichiers de ressources? Par exemple, basez-vous le nom de votre clé sur le texte à localiser ou sur le contrôle qui utilise le texte?

Supposons que vous disposiez d'un bouton d'édition sur plusieurs écrans (un pour modifier un utilisateur, un pour modifier un groupe). Vous pouvez utiliser les clés suivantes:

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

ou

• editUser = Modifier l'utilisateur ...
• editGroup = Modifier le groupe ...

ou

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

Quel schéma préférez-vous et pourquoi?

Answer 1

Je préfixe mes littéraux par usecase ou 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 évitez les collisions:

EditStudent=Edit
EditClass=Edit
EditCourse=Edit Course

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

Je groupe également par entité:

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

Celles-ci peuvent apparaître en tant qu'en-têtes de tableaux avec les entités. Cela vous évite des cas tels que celui-ci:

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

Enfin, en fournissant un contexte dans les clés de propriété, vous pouvez vous protéger des traductions fausses. Par exemple, j’ai eu une fois:

no=no

qui était utilisé comme en-tête de tableau id (#) dans la cellule en haut à gauche, mais notre traducteur français l'a fait pour le français:

no=non

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

Le dernier (mais non le moindre) préfixage avec classname vous aidera lorsque vous souhaitez refactoriser / renommer les classes et mettre à jour rapidement ces clés de propriété sans avoir à consulter les modèles.

Answer 2

Nous nous basons sur la version anglaise du terme. Ex: EditUser C’est-à-dire qu’elle est facilement lisible par nos développeurs et peut être réutilisée à plusieurs endroits. Ce terme est obligatoire dans l’application.

Answer 3

Basez-le sur le texte anglais, mais préfixez la fenêtre / le dialogue / l’affiche contenant le mot ou la phrase. Au moins lorsque l'espace de présentation est limité, vous pouvez éviter de tomber dans le piège d'avoir exactement la même chaîne partout: cela vous empêche de raccourcir pour obtenir des présentations correctes, en particulier dans les langues polysyllabiques comme le finnois.

Bien sûr, vous devez toujours vous efforcer d’être cohérent dans la dénomination des noms. L'augmentation du nombre de chaînes augmentera également les coûts de traduction si vous effectuez cette opération dans le commerce.

Et n'ignorez pas le danger des homonymes. Fournir un contexte aide à prévenir cela. N'ayez pas peur de faire en sorte que le nom de la ressource soit plus long que le terme anglais actuel, cela peut considérablement aider les traducteurs.

Answer 4

+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 source de la ressource), 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.

Donc, un message comme:

  

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

serait documenté comme quelque chose comme:

  

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

Answer 5

Je pense qu’en premier lieu, vous devriez utiliser une sorte de fichier XML pour stocker ce type de données.

Quelque chose comme:

<? xml version = " 1.0 " codage = & "; utf-8 &"; autonome = " oui " ? >
< xml >
& nbsp; & nbsp; & nbsp; & nbsp; < bouton >
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < modifier & ;
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < utilisateur > *** Modifier l'utilisateur * < / user >
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < groupe > Modifier le groupe < / group > < br> & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; < / edit >
& nbsp; & nbsp; & nbsp; & nbsp; < / bouton >
< / xml > **

Et ensuite utilisez 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.