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 deux mécanismes de localisation de fichiers spécifiques à des environnements locaux 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).
Lors de l'exécution, il est uniquement possible d'accéder au fichier le plus spécifique. Les chemins d'accès font l'objet d'une recherche dans le mécanisme IPluginDescriptor.find et Plugin.find. Par exemple, imaginez que l'environnement local par défaut soit en_CA et qu'un plug-in recherche le fichier about.properties comme suit :
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 : les fichiers plugin.properties et fragment.xml sont visiblement absents de la liste. Pour des raisons historiques, ces fichiers sont traités comme des regroupements de ressources Java et utilisent l'autre mécanisme.
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.
Comme expliqué précédemment, cette technique permet d'accéder aux fichiers plugin.properties et fragment.xml.