Les fragments offre un mode pratique de mise en forme pour les traductions. Observez de plus près la structure de répertoires utilisée pour installer des fichiers de traduction spécifique à l'environnement local. Cette structure est employée que les fichiers traduits se trouvent dans un fragment ou soient au contraire placés dans le plug-in d'origine.
Il existe trois mécanismes pour rechercher des fichiers spécifiques à des paramètres régionaux dans un plug-in.
Vous devez absolument comprendre le mécanisme utilisé pour accéder à un fichier devant être traduit. Vous saurez ainsi comment nommer ce fichier et où le placer dans le système de fichiers relatif au plug-in.
Il définit une structure de répertoires employant des sous-répertoires spécifiques à l'environnement local pour des fichiers dont les paramètres sont différents. Les fichiers traduits sont par exemple placés dans le répertoire nl, sous le plug-in. L'arborescence d'installation ci-après illustre un plug-in simple (sans code) avec des traductions par environnement local de son fichier about.properties. Les diverses traductions semblent provenir d'un fragment de plug-in, et non du plug-in même. Tel est le cas pour l'envoi séparé de traductions à partir de la base, mais vous pouvez également placer le sous-répertoire nl directement sous le plug-in.
acmeweb/ eclipse/ plugins/ com.example.acme.acmewebsupport_1.0.0/ plugin.xml about.properties (environnement local par défaut) com.example.acme.fragmentofacmewebsupport_1.0.0/ fragment.xml (un fragment de com.example.acme.acmewebsupport 1.0.0) nl/ fr/ about.properties (Français) CA/ about.properties (Français [Canada]) FR/ EURO/ about.properties (Euros [France]) en/ about.properties (Anglais) CA/ about.properties (Anglais [Canada]) US/ about.properties (Anglais [EU]) de/ about.properties (Allemand)
Les fichiers à traduire ne figurent pas dans des fichiers JAR. Chaque fichier doit porter exactement le même nom mais se trouver dans des sous-répertoires figurant sous celui nommé nl, à la racine du fragment (ou du plug-in).
Seul le fichier le plus spécifique est accessible lors de l'exécution. Les chemins d'accès au fichier sont recherchés dans le cadre des mécanismes Platform.find, IPluginDescriptor.findetPlugin.find. Par exemple, imaginez que les paramètres régionaux soient en_CA et qu'un plug-in recherche about.properties de la manière suivante :
somePlugin.find("$nl$/about.properties");
La méthode renvoie une URL correspondant à la première occurrence de about.properties par rapport à l'ordre suivant :
com.example.acme.acmewebsupport_1.0.0/nl/en/CA/about.properties com.example.acme.fragmentofacmewebsupport_1.0.0/nl/en/CA/about.properties ... <tout autre fragment> com.example.acme.acmewebsupport_1.0.0/nl/en/about.properties com.example.acme.fragmentofacmewebsupport_1.0.0/nl/en/about.properties ... com.example.acme.acmewebsupport_1.0.0/about.properties com.example.acme.fragmentofacmewebsupport_1.0.0/about.properties
Ce mécanisme est utilisé par des plug-ins pour rechercher des noms de fichiers dans d'autres plug-in. Ces fichiers sont entre autres :
(Remarque : plugin.properties et fragment.properties sont visiblement absents de cette liste. Ils sont traités d'une manière légèrement différente de ce qui est décrit ci-dessous.)
La gestion standard Java des regroupements de ressources de propriétés est utilisée pour d'autres fichiers. Les fichiers traduits figurent dans un fichier JAR spécifique, chaque fichier de propriétés possédant un nom spécifique à l'environnement local, tel que "message_en_CA.properties". Les fichiers se trouvent dans des sous-répertoires spécifiques au package et peuvent apparaître dans le plug-in même ou dans l'un des ses fragments. Chaque fichier de propriétés traduit peut être partiel vu que la recherche de clés accède à une chaîne définie de fichiers de propriétés.
Le format des fragments NL a évolué légèrement depuis la version 2.1.
Auparavant, tous les fichiers de conversion (y compris plugin.properties) étaient fournis dans un fichier jar.
Cela n'était pas cohérent car le fichier plugin.properties se trouvait à la racine du plug-in.
Pour adapter le fragment NL au nouveau modèle, supprimez les fichiers de conversion plugin.properties du fichier jar et placez-les à la racine du fragment comme enfants du fichier fragment.xml.
Par exemple, le nouveau format du fragment NL d'org.eclipse.ui.workbench est le suivant :
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar