Fragmentos são uma maneira conveniente de compactar traduções do idioma nacional. Vamos olhar mais detalhadamente a estrutura de diretórios utilizada para instalação dos arquivos de tradução específicos do locale. Essa estrutura de diretórios é utilizada independente dos arquivos traduzidos serem compactados em um fragmento ou enviados no plug-in original.
Existem dois mecanismos para localização de arquivos específicos do locale em um plug-in.
É importante entender o mecanismo utilizado para acessar um determinado arquivo que deve ser traduzido, para que você saiba que nome dar a ele e onde colocá-lo no sistema de arquivos relativo ao plug-in.
O núcleo da plataforma define uma estrutura de diretórios que utiliza subdiretórios específicos do locale para arquivos que diferem por locale. Os arquivos traduzidos são colocados em um diretório chamado nl no plug-in. Por exemplo, a árvore de instalação a seguir mostra um plug-in (sem código) trivial com traduções específicas do locale de seu arquivo about.properties. As várias traduções são mostradas como vindas de um fragmento de plug-in, em vez do próprio plug-in. Isso é comum para o envio de traduções separadamente da base, mas também seria possível colocar o subdiretório nl no próprio plug-in.
acmeweb/ eclipse/ plugins/ com.example.acme.acmewebsupport_1.0.0/ plugin.xml about.properties (locale padrão) com.example.acme.fragmentofacmewebsupport_1.0.0/ fragment.xml (um fragmento de com.example.acme.acmewebsupport 1.0.0) nl/ fr/ about.properties (locale francês) CA/ about.properties (locale francês canadense) FR/ EURO/ about.properties (euros franceses da França) en/ about.properties (locale inglês) CA/ about.properties (locale inglês canadense) US/ about.properties (locale inglês americano) de/ about.properties (locale alemão)
Os arquivos a serem traduzidos não estão contidos em arquivos JAR. Cada arquivo deve ter exatamente o mesmo nome de arquivo, mas estar localizado em subdiretórios sob o subdiretório nl na raiz do fragmento (ou do plug-in).
Apenas o arquivo mais específico é acessado no tempo de execução. Os caminhos de arquivos são pesquisados como parte do mecanismo IPluginDescriptor.find e Plugin.find . Por exemplo, suponha que o locale padrão seja en_CA e um plug-in procure about.properties como a seguir:
somePlugin.find("$nl$/about.properties");
O método retornará uma URL correspondente ao primeiro local que about.properties for encontrado de acordo com a seguinte ordem:
com.example.acme.acmewebsupport_1.0.0/nl/en/CA/about.properties com.example.acme.fragmentofacmewebsupport_1.0.0/nl/en/CA/about.properties ... <qualquer outro fragmento> 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
Esse mecanismo é utilizado por plug-ins para procurar nomes de arquivos reconhecidos dentro de outros plug-ins. Isso inclui os seguintes nomes de arquivos reconhecidos:
(Nota: Os arquivos plugin.properties e fragment.xml estão visivelmente ausentes dessa lista. Por motivos históricos, eles são tratados como pacotes de recursos de propriedades Java e utilizam o outro mecanismo.)
O tratamento Java padrão de pacotes de recursos de propriedades é utilizado para outros arquivos. Os arquivos traduzidos estão contidos em um arquivo JAR, sendo que cada arquivo de propriedades tem um nome específico do locale, como "message_en_CA.properties". Os arquivos estão em subdiretórios específicos do pacote e podem aparecer no próprio plug-in ou em um de seus fragmentos. Cada arquivo de propriedades traduzido pode ser parcial, uma vez que a pesquisa das chaves acessa uma cadeia bem definida de arquivos de propriedades.
Conforme observado acima, plugin.properties e fragment.xml são acessados com esta técnica.