Los fragmentos son una manera práctica de empaquetar las traducciones en idioma nacional. Ahora veremos con mayor detalle la estructura de directorios que se emplea para instalar los archivos de traducción específicos del entorno local. Esta estructura es la que se utiliza con independencia de si los archivos traducidos se empaquetan en un fragmento o se entregan en el conector original.
Existen dos mecanismos para localizar los archivos específicos del entorno local en un conector.
Es importante comprender qué mecanismo se utiliza para acceder a un archivo dado que debe estar traducido, porque así sabrá qué nombre debe dar al archivo y dónde debe ponerlo en el sistema de archivos relativo al conector.
El núcleo de la plataforma define una estructura de directorios que emplea subdirectorios específicos del entorno local para los archivos que se distinguen por el entorno local. Los archivos traducidos se colocan en un directorio llamado nl situado bajo el conector. Por ejemplo, el siguiente árbol de instalación muestra un conector trivial (sin código) con las traducciones específicas del entorno local del correspondiente archivo about.properties. En el ejemplo, las diversas traducciones proceden de un fragmento de conector, en vez de estar en el propio conector. Esto es habitual cuando se envían las traducciones por separado del producto base, pero también es posible colocar el subdirectorio nl bajo el directorio del conector.
acmeweb/ eclipse/ plugins/ com.example.acme.acmewebsupport_1.0.0/ plugin.xml about.properties (entorno local por omisión) com.example.acme.fragmentofacmewebsupport_1.0.0/ fragment.xml (un fragmento de com.example.acme.acmewebsupport 1.0.0) nl/ fr/ about.properties (entorno local francés) CA/ about.properties (entorno local francés de Canadá) FR/ EURO/ about.properties (entorno local francés de Europa) en/ about.properties (entorno local inglés) CA/ about.properties (entorno local inglés de Canadá) US/ about.properties (entorno local inglés de EE. UU.) de/ about.properties (entorno local alemán)
Los archivos que deben traducirse no están en archivos JAR. Cada archivo debe tener exactamente el mismo nombre, pero hay que colocarlo en subdirectorios situados bajo el subdirectorio nl del directorio raíz del fragmento (o del conector).
En tiempo de ejecución solo se accede al archivo más específico. Se busca en las vías de acceso del archivo como parte del mecanismo de IPluginDescriptor.find y Plugin.find . Por ejemplo, supongamos que el entorno local por omisión es en_CA y que un conector busca el archivo about.properties de la siguiente manera:
somePlugin.find("$nl$/about.properties");
El método devolvería un URL que se correspondería con el archivo about.properties encontrado en primer lugar según este orden:
com.example.acme.acmewebsupport_1.0.0/nl/en/CA/about.properties com.example.acme.fragmentofacmewebsupport_1.0.0/nl/en/CA/about.properties ... <cualquier otro 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
Los conectores emplean este mecanismo para buscar los nombres de archivo por todos conocidos dentro de otros conectores. Esto incluye los siguientes nombres de archivo por todos conocidos:
Nota: se habrá dado cuenta de que los archivos plugin.properties y fragment.xml se han dejado fuera de esta lista. Por razones históricas, estos archivos se tratan como paquetes compuestos de recursos de propiedades Java y utilizan otro mecanismo.
Para los otros archivos se utiliza el manejo Java estándar de los paquetes compuestos de recursos de propiedades. Los archivos traducidos están en un archivo JAR, y cada archivo de propiedades tiene un nombre específico del entorno local, como "message_en_CA.properties". Los archivos están en subdirectorios específicos del paquete y pueden aparecer en el propio conector o en uno de sus fragmentos. Cada archivo de propiedades traducido puede ser parcial, porque la búsqueda de claves accede a una cadena bien definida de archivos de propiedades.
Como se ha indicado más arriba, esta es la técnica que se utiliza para acceder a los archivos plugin.properties y fragment.xml.