## Preparar para Utilizar un ResourceBundle

#### Identificar los Objetos Específicos de la Localidad

Si la aplicación tiene un interface de usuario, contendrá muchos objetos específicos de la localidad. Deberíamos empezar leyendo el código y buscándo objetos que varien con la localidad. La lista podría incluir objetos ejemplarizados de las siguientes clases:

- String
- Component
- Graphics
- Image
- Color
- AudioClip

Observarás que está lista no contiene objetos que representen números, fechas, horas o monedas. El formato de esos objetos varía con la localidad pero no así los propios objetos. Por ejemplo, se formatea un objeto Date de acuerdo a la localidad, pero se sigue utilizando el mismo objeto Date sin importar la localidad. En vez de aislar estos objetos en un ResourceBundle, se deben formatear con clases especiales de formateo sensible a la localidad. Veremos como hacer esto en Formateo de Fechas y Horas.

En general, los objetos almacenados en un ResourceBundle están predefinidos y se venden con el producto. Estos objetos no se modifican mientras el programa se está ejecutando. Por ejemplo, se debería almacenar le etiqueta de un Menu en un ResourceBundle porque es específico de la localidad, y no cambia durante la sesión del programa. Sin embargo, no se deberían aislar en un ResourceBundle los objetos String introducidos por el usuario final en un TextField. Los datos de este estilo podrían variar de día a día. Son específicos de la sesión del programa, no de la localidad en que se está ejecutando el programa.

Normalmente, la mayoría de los objetos que se necesita aislar en un ResourceBundle son objetos String. Sin embargo, no todos los objetos String son específicos de la Localidad. Por ejemplo, si un String es un elemento de protocolo utilizado en un proceso de inter-comunicación, no necesita ser localizado porque el usuario final nunca lo verá. La decisión de cuando localizar algunos objetos String no siempre está clara. Los ficheros LOG son un buen ejemplo. Si un fichero Log es escrito por un programa y leído por otro, ambos programas están utilzando el fichero Log como un buffer de comunicación. Supongamos que el usuario final chequea ocasionalmente el contenido de este fichero. ¿Debería estar localizado este fichero Log? Por otro lado, si el fichero es raramente chequeado por los usuarios finales, el coste de la tradución podría no merecer la pena. La decisión de localizar este fichero Log depende de un número de factores: diseño del programa, fácilidad de utilización, coste de la tradución y soportabilidad.

#### Organizar Objetos ResourceBundle

Puedes organizar tus objetos ResourceBundle cargando cada uno de ellos en una categoría diferente de objetos. Por ejemplo, podríamos querer cargar todos las etiquetas de Button dentro de un ResourceBundle llamada ButtonLabelsBundle. Cargar los objetos relacionados en diferentes objetos ResourceBundle tiene varias ventajas:

- El código es fácil de leer y de mantener.
- Recuperar un objeto del ResourceBundle es más rápido si este contiene un pequeño número de objetos.
- Los Traductores encontrarán más sencillo el trabajar con ficheros de propiedades más pequeños.

La mayoría de los datos específicos de la localidad consisten en objetos String. Si estos objetos necesitan ser traducidos, se almacenan en un objeto ResourceBundle que está constituido por ficheros de propiedades. Si se utilizan ficheros de propiedades, los taductores pueden añadir soporte para idiomas adicionales creando nuevos ficheros de propiedades.

Ozito