Nous avons un site web qui devrait être traduit en plusieurs langues. Une partie du libellé se trouve dans les fichiers de propriétés de message prêts à être traduits. Je veux maintenant ajouter le reste du texte dans ces fichiers.Quelle est la bonne façon de nommer les propriétés des messages dans i18n?
Quel est un bon moyen de nommer les blocs de texte? Nous avons pour la plupart des pages Web et certains éléments/modules se répètent sur certains sites.
Pour autant que je sache, il n'existe pas de "standard". Par conséquent, il est assez difficile de dire ce qui est correct et ce qui est une mauvaise façon de nommer les clés de ressources. Cependant, d'après mon expérience, je pourrais recommander cette façon:
property file name: <module>.properties
resource keys: <view or dialog>[.<sub-context>].<control-type>.<name>
Nous pouvons discuter si elle est une bonne façon de mettre toutes les chaînes d'un module dans un fichier de propriété - probablement, il pourrait être bon si les mises à jour ne pas arrive souvent et il n'y a pas autant de messages. Sinon, vous pourriez penser à un fichier par vue. En ce qui concerne la stratégie de nommage des clés: il est important pour le traducteur (ressemble à un film avec l'honorable gouverneur Arnold S. n'est-ce pas?) D'avoir un contexte. La traduction peut en dépendre, c'est-à-dire en polonais, que vous traduiriez un message différemment s'il s'agit d'une page/d'un dialogue/d'un titre quelconque et d'une manière totalement différente s'il s'agit d'un bouton.
Un exemple de cette ressource clé pourrait être:
preferences.password_area.label.username=User name
Il donne suffisamment d'indices pour le traducteur au sujet de ce qu'il est réellement, ce qui pourrait entraîner la traduction correcte ...
Gardez à l'esprit les principes DRY (https://en.wikipedia.org/wiki/Don't_repeat_yourself). Si une propriété est utilisée à plusieurs endroits et n'est pas susceptible de changer, considérez un nom de propriété comme 'common.button.submit = Save'. Par extension, envisagez de supprimer la duplication de l'interface utilisateur avec taglibs ou templates. –
je proposerais la convention ci-dessous
functionalcontext.subcontext.key
logicalcontext.subcontext.key
De cette façon, vous pouvez regrouper logiquement tous les messages communs dans un contexte super (id dans l'exemple ci-dessous). Il y a peu de choses qui ne sont spécifiques à aucun contexte fonctionnel (comme lastName etc) que vous pouvez regrouper dans un contexte logique.
order.id=Order Id
order.submission.submit=Submit Order
name.last=Last Name
Nous avons trouver avec la convention de nommage clé suivante (Java, btw) en utilisant la notation par points et cas de chameau:
étiquettes clés (étiquettes en page/formulaire/titres app, etc ... par exemple, des phrases non complètes, utilisé dans plusieurs emplacements UI):
Si l'étiquette représente un champ Java (par exemple, un champ de formulaire) et correspond à l'étiquette de formulaire: label.nameOfField
Else: label.sameAsValue
Exemples:
Touches de contenu:.
projectName.uiPath.messageOrContentType.n *
Où:
Exemples:
avantages/inconvénients:
+ clés d'étiquettes peuvent facilement être réutilisés; l'emplacement n'est pas pertinent.
+ Pour les clés de contenu qui ne sont pas réutilisées, la localisation de la page sur l'interface utilisateur sera simple et logique.
- Il se peut que les traducteurs ne comprennent pas clairement où résident les clés d'étiquette sur l'interface utilisateur. Cela peut être un non-problème pour les traducteurs qui ne naviguent pas dans les pages, mais qui peuvent poser problème aux développeurs.
- Si les clés de contenu doivent être utilisées dans plus d'un emplacement de l'interface utilisateur (ce qui est très probable), le choix du nom de clé n'aura aucun sens dans les autres emplacements.Dans notre cas, la gestion n'est pas concernée par une duplication de valeurs pour les zones de contenu, nous utiliserons donc des clés différentes (pour montrer l'emplacement sur l'interface utilisateur) dans ce cas.
Commentaires sur cette convention - en particulier des commentaires qui l'améliorer - serait très apprécié puisque nous sommes en train de réorganiser actuellement nos ensembles de ressources! :)
la méthode que j'ai personnellement utilisée et que j'ai aimé plus jusqu'à présent est l'utilisation de phrase à localisee comme la clé. Par exemple: (pls remplacer T avec la bonne syntaxe dependably sur la langue)
par exemple: impression (T (« Bonjour tout le monde »))
dans ce cas, T recherchera une clé « Bonjour tout le monde ". S'il n'est pas trouvé, la clé est renvoyée, sinon la valeur de la clé.
De cette façon, vous ne avez pas besoin de modifier le message (dans votre langue par défaut) au moins que vous avez besoin d'utiliser des paramètres .... Il m'a sauvé beaucoup de temps dev
Est-ce propriétés java ou .NET? –
Bonne question! Ce que vous avez décrit ci-dessus est un bon guide pour nommer les propriétés. Malheureusement, c'est aussi un domaine très subjectif. J'aimerais voir ce que le reste de la communauté suggère. –