Fragmenter er en enkel måte å pakke oversettelser i. La oss se nærmere på katalogstrukturen som brukes ved installering av språkspesifikke oversettelsesfiler. Katalogstrukturen brukes uavhengig av om de oversatte filene pakkes i et fragment eller leveres i den opprinnelige plugin-modulen.
Det finnes tre mekanismer for lokalisering av språkspesifikke filer i en plugin-modul.
Det er viktig å vite hvilke mekanismer som brukes for å få tilgang til en bestemt fil som skal oversettes slik at du vet hva du skal kalle filen og hvor den skal plasseres i filsystemet relativt til plugin-modulen.
Plattformkjernen definerer en katalogstruktur som bruker språkspesifikke underkataloger for filer med ulike språkmiljø. Oversatte filer plasseres i katalogen nl, under plugin-modulen. For eksempel viser følgende installeringstre en enkel (ingen kode) plugin-modul med språkspesifikke oversettelser av filen about.properties. De ulike oversettelsene vises som de kommer fra et plugin-fragment, og ikke selve plugin-modulen. Dette er vanlig når det leveres oversettelser separat fra basen, men du bør også legge underkatalogen nl under selve plugin-modulen.
acmeweb/ eclipse/ plugins/ com.example.acme.acmewebsupport_1.0.0/ plugin.xml about.properties (default locale) com.example.acme.fragmentofacmewebsupport_1.0.0/ fragment.xml (a fragment of com.example.acme.acmewebsupport 1.0.0) nl/ fr/ about.properties (French locale) CA/ about.properties (French Canadian locale) FR/ EURO/ about.properties (French France Euros) en/ about.properties (English locale) CA/ about.properties (English Canadian locale) US/ about.properties (English US locale) de/ about.properties (German locale)
Filene som skal oversettes, ligger ikke i JAR-filer. Hver fil skal ha nøyaktig samme filnavn, men plasseres i underkataloger under nl i roten for fragmentet (eller plugin-modulen).
Det er bare de mest spesifikke filene som har tilgang ved kjøretid. Filbanene søkes som en del av mekanismen Platform.find, IPluginDescriptor.find og Plugin.find. Tenk deg for eksempel at standard språkmiljø er no_NO og at en plugin-modul søker etter about.properties på følgende måte:
somePlugin.find("$nl$/about.properties");
Metoden returnerer en URL som samsvarer med den første plassen about.properties blir funnet, med følgende rekkefølge:
com.example.acme.acmewebsupport_1.0.0/nl/en/CA/about.properties com.example.acme.fragmentofacmewebsupport_1.0.0/nl/en/CA/about.properties ... <any other fragments> 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
Denne mekanismen brukes av plugin-moduler for å søke etter kjente filnavn i andre plugin-moduler. Dette gjelder følgende kjente filnavn:
(Merk: Verken plugin.properties eller fragment.properties finnes på listen. De håndteres på en litt annen måte, som beskrevet nedenfor.)
Standard Java-håndtering av egenskapressursbunter brukes for andre filer. Oversatte filer ligger i en JAR-fil der hver egenskapsfil har et språkspesifikt navn, for eksempel "message_en_CA.properties". Filene er i underkataloger som er spesifikke for pakkene, og kan vises i selve plugin-modulen eller i ett av fragmentene. Hver egenskapsfil som er oversatt, kan være ufullstendig siden søking etter nøkler gir tilgang til en veldefinert kjede av egenskapsfiler.
Utformingen av NL-fragmenter har utviklet seg noe siden 2.1. Tidligere fulgte alle oversettelsesfilene (også plugin.properties) med i en jar. Dette var inkonsekvent siden filen plugin.properties ble oppgitt i plugin-modulens rot.
Hvis du vil tilpasse NL-fragmentet til den nye modellen, fjerner du oversettelsesfilene
for plugin.properties fra jar og plasserer dem ved roten av fragmentet, som søsken for fragment.xml.
Den nye utformingen av NL-fragmentet for org.eclipse.ui.workbench ser for eksempel slik ut:
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar