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.
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.