Liste de liens :
Liste de liens :
Cette page définit notamment de la façon de créer les symboles d'externalisation des chaînes de TXM.
Externaliser les messages consiste à séparer les messages dans 3 lieux :
L'outil d'externalisation d'Eclipse propose directement des symboles pour les chaînes en utilisant le nom de la classe dont on externalise les chaînes et un numéro de chaîne (externalisée ou pas).
Par exemple : ProgressionPreferencePage_3
Pour faciliter la tâche des traducteurs, nous avons :
La fusion des doublons a rendu les clés moins liées aux packages Java.
TODO : existe-t-il déjà quelque part des recommandations à ce sujet ?
TODO : lister les différents cas de figures pour en déduire la convention de nommage ? ex :
Propositions SJ, messages.properties, notamment basées sur les sources d'Eclipse/SWT et sur d'autres recherches :
Les chaînes étant maintenant localisées dans chaque plugin, les préfixes avec nom de la classe ne semblent plus utiles. Le nom de la classe de Messages elle-même étant suffisamment parlant, ex. :
0) arrêter de concaténer des chaînes directement dans Java mais toujours utiliser NLS.bind() et ajouter les arguments directement dans les .properties : {0} {1} etc. Cela évite le split de chaînes intraduisibles, le codage en dur et les annotations NON-NLS.
1) “destination/type”
2) “localisation/emplacement”
TBD, peut-être :
3) la fin de la clé est la phrase en anglais, sans majuscule au début et prenant ensuite une majuscule à chaque mot. Code beaucoup plus clair + plus de précisions pour les traducteurs, etc., ex :
4) Propositions/exemples complets :
SJ : Pour plus de facilité, je propose de regrouper les fichiers Messages.java et les .properties dans un package nommé 'messages'. Je propose également de renommer le fichier Messages.java en y ajoutant en préfixe un identifiant du plugin. Voici ce que ça donnerait par exemple pour le plugin org.txm.tbx.chartsengine :
Le renommage du fichier Messages.java par un nom plus explicite facilite l'accès aux messages car un même plugin peut utiliser la classe Messages.java de plusieurs autres plugins liés, ce qui prête à confusion.
Le BUNDLE_NAME généré par la fonction 'Externalize Strings' d'Eclipse est codé en dur en fonction du package dans lequel se trouve la classe Messages.java au moment de l'externalisation. Pour simplifier le refactoring on peut remplacer :
public class ChartsEngineMessages extends NLS { private static final String BUNDLE_NAME = "org.txm.tbx.chartsengine.base.messages"; //$NON-NLS-1$ ... }
par :
public class ChartsEngineMessages extends NLS { private static final String BUNDLE_NAME = ChartsEngineMessages.class.getPackage().getName() + ".messages"; //$NON-NLS-1$ ... }
Le BUNDLE_NAME est alors généré dynamiquement en fonction du package réel de la classe.
Si la Toolbox et la RCP s'orientent vers un découpage du code en plugins il faudrait réfléchir aux bénéfices et aux inconvénients liés à la décentralisation des fichiers des chaînes vers chaque plugin. Ci-dessous première réflexion :
Pros
Cons
D'après le tuto et d'autres recherches, les préconisations seraient d'avoir :
TODO : voir la fonction Internationalize d'Eclipse qui entre autres permet de créer directement un ou plusieurs projets fragment à partir d'un plugin et d'une liste de locales spécifiée.
Après test de la fonction, elle crée donc un fragment par langue additionnelle ou un seul fragment pour toutes les langues. Elle crée également directement les bundle_xx.properties et les messages_xx.properties dans le ou les fragments en fonction de chaque locale spécifiée lors de son exécution.
System.out.print(NLS.bind(Messages.WritingCoocMatrixInGraphmlFileDDotP0, file)); working(); System.out.println(Messages.FileCreated); -> Writing cooc matrix in GRAPHML file: {0}... File created.
Règles d'harmonisation terminologique dans les messages FR et EN et pour la traduction entre ces deux langues.
FR
EN
Conventions valables pour les chaines de widget et pour les messages de console (sauf cas particuliers mentionnés).
txm
)381 rcp.messages.TXMUI.commandParameter.name File fichier 382 rcp.messages.TXMUI.commandParameter.name.1 Script script etc.