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 tres 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 utiliza subdirectorios específicos de entorno nacional para los archivos cuyo entorno nacional es diferente. Los archivos traducidos se colocan en un directorio denominado nl del conector. Por ejemplo, el árbol de instalación que figura a continuación muestra un conector trivial (sin código) con traducciones específicas de entorno nacional de su archivo about.properties. Las diversas traducciones aparecen como procedentes de un fragmento de conector, en lugar del propio conector. Este es un método habitual para suministrar traducciones independientemente de la base, pero también puede situar el subdirectorio nl bajo el propio 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 (fragmento de com.example.acme.acmewebsupport 1.0.0) nl/ fr/ about.properties (entorno local francés) CA/ about.properties (entorno local francés canadiense) FR/ EURO/ about.properties (francés de Francia con euros) en/ about.properties (entorno local inglés) CA/ about.properties (entorno local inglés canadiense) US/ about.properties (entorno local inglés de EE.UU.) de/ about.properties (entorno local alemán)
Los archivos que deben traducirse no se encuentran 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 de archivo como parte del mecanismo de Platform.find, IPluginDescriptor.findyPlugin.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: los archivos plugin.properties y fragment.properties se han dejado fuera de esta lista. Se tratan de un modo ligeramente diferente, que se describe más adelante).
El manejo estándar de java con respecto a los paquetes compuestos de recursos de propiedades se utiliza para otros archivos. Los archivos traducidos se encuentran en un archivo JAR, y cada uno de los archivos de propiedades tiene un nombre específico de entorno local, como por ejemplo "message_en_CA.properties". Los archivos se encuentran en subdirectorios específicos de paquete y pueden aparecer en el propio conector o en uno de sus fragmentos. Cada uno de los archivos de propiedades traducidos puede ser parcial, ya que la búsqueda de claves accede a una cadena de archivos de propiedades bien definida.
El formato de los fragmentos de NL ha evolucionado ligeramente con respecto a la versión
2.1.
Anteriormente, todos los archivos de traducción (incluido plugin.properties) se suministraban en un archivo jar.
Esto era incoherente, ya que el archivo plugin.properties se suministraba en el directorio raíz del conector.
Para adaptar el fragmento de NL al modelo nuevo, elimine los archivos de traducción
plugin.properties del jar y colóquelos en el directorio raíz del fragmento como hermanos de
fragment.xml.
Por ejemplo, el formato nuevo del fragmento de NL de org.eclipse.ui.workbench es el siguiente:
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar