Discussion :

[_Mac_]

Bonsoir,

J'ai un plug-in pour lequel j'ai développé des vues et des classes qui ne fonctionnent que sous Windows. J'ai donc placé ce code spécifique Windows dans un fragment. Par ailleurs, j'ai un fragment pour traduire mon plug-in.

Jusqu'ici tout va bien.

Sauf que j'ai des vues dans ce fragment, des vues que je voudrais traduire. Comment je fais-je ? Dois-je déclarer un Bundle-Localization spécial pour mon fragment que je vais traduire dans un autre fragment ou le fragment qui me sert déjà à traduire mon plug-in ?

Toute idée est la bienvenue.

[Gueritarish]

Salut,

Alors, tout dépend de la façon dont tu récupères tes chaînes de caractères (j'imagine que tu utilises un ResourceBundle ou la classe NLS d'Eclipse), mais généralement, il te suffit d'avoir tes fichiers properties bien "nommé" pour que tout soit fait automatiquement...
Si ton fichier properties s'appelle: messages.properties, il te suffit d'avoir des fichiers messages_en.properties, messages_de.properties qui sont récupéré par rapport à la locale du système...

Voilà, à+
Gueritarish

[_Mac_]

Je passe par une classe fille de NLS générée par Eclipse. Je suis d'accord qu'il faut mettre les _xx qui vont bien. La question c'est que si je veux traduire des entrées du fichier fragment.xml dans plusieurs fragments, avec le paramétrage par défaut je vais me retrouver avec plusieurs fichiers bundle.properties (ou fragment.properties) : un dans chaque projet de fragment. Dans ce cas, j'imagine qu'il y aura un conflit : comment Eclipse/OSGI saura quel fichier utiliser dans quel cas ? J'imagine donc qu'il y a une bonne pratique pour gérer ce cas : laquelle ?

[Gueritarish]

Ok, je vois le problème.
Alors, il te faut savoir que les fragments et plug-ins sont "rassemblés" lors de l'exécution. Donc, si tu as 2 fichiers avec le même nom, tu ne peux pas vraiment savoir lequel des 2 aura précédence sur l'autre. Par contre, tu peux donner une "priorité"en ajoutant la locale. Si tu as un plug-in qui définit un fichier de propriété: "bundle.properties" et que tu veux surcharger une clé dans ton fragment, il te suffit de créer un fichier "bundle_en.properties":

test.key = Test

test.key = Test Fragment

A voir si cette "règle" peut s'étendre lorsqu'on précise plus finement la locale (Ex: si on utilise en_EN, ou fr_CA, ...).
J'espère avoir répondu à ta question

Voilà, à+
Gueritarish

[_Mac_]

Pas tout à fait mais c'est pas grave. Je suis parti plutôt sur l'optique de faire un plug-in à part et pas un fragment. Du coup, j'ai d'autres problèmes. Je vais voir ce que je vais faire. Si jamais je reviens au fragment, je crois que j'indiquerais dans Bundle-Localization un nom de bundle spécifique à mon fragment.

[Gueritarish]

En fait, j'ai un peu de mal à cerner le problème, désolé
Est-ce que tes fragments vont chacun définir une partie de l'internationalisation des vues (sans se chevaucher) ou est-ce que certains vont redéfinir des clés déjà définis dans d'autres?
Si t'es dans le premier cas, il n'y aura pas de problème (à priori).
Si t'es dans le deuxième, je vois pas ce que ça t'apporte
Si t'es dans un troisième cas, je veux bien un schéma

[_Mac_]

J'ai un plug-in pour lequel j'ai développé des vues et des classes qui ne fonctionnent que sous Windows. J'ai donc placé ce code spécifique Windows dans un fragment. Par ailleurs, j'ai un fragment pour traduire mon plug-in.

Mon problème est la façon de gérer les traductions pour mon premier fragment spécifique Windows : nouveau fragment ? intégrer mes traductions dans mon fragment de traduction ? Autre ?

[Gueritarish]

A priori, à moins que tes vues ne soient spécifiques qu'à Windows (i.e. sans équivalent dans les autres OS), tu devrais intégrer leurs localisations dans ton fragment de traduction...