Isolating Locale-Specific Data

Preparing to Use a ResourceBundle

Identifying the Locale-specific Objects

If your application has a user interface, it contains many locale-specific objects. To get started, you should go through your source code and look for objects that vary with Locale. Your list may include the objects instantiated from the following classes:

• String
• Component
• Graphics
• Image
• Color
• AudioClip

You'll notice that this list doesn't contain objects representing numbers, dates, times, or currencies. The format of these objects varies with Locale, but the objects themselves do not. For example, you format a Date according to Locale, but you use the same Date object regardless of Locale. Instead of isolating these objects in a ResourceBundle, you format them with special locale-sensitive formatting classes. You'll learn how to do this in the Dates and Times section of the Formatting lesson.

In general, the objects stored in a ResourceBundle are pre-defined and ship with the product. These objects are not modified while the program is running. For instance, you should store a Menu label in a ResourceBundle because it is locale-specific, and will not change during the program session. However, you should not isolate in a ResourceBundle a String object entered by the end-user in a TextField. Data such as this String may vary from day to day. It is specific to the program session, not to the Locale in which the program runs.

Usually, most of the objects you need to isolate in a ResourceBundle are String objects. However, not all String objects are locale-specific. For example, if a String is a protocol element used by inter-process communication, it doesn't need to be localized because the end-users never see it. The decision whether to localize some String objects is not always clear. Log files are a good example. If a log file is written by one program and read by another, then both programs are using the log file as a buffer for communication. Suppose end-users occasionally check the contents of this log file. Shouldn't the log file be localized? On the other hand, if the log file is rarely checked by end-users the cost of translation may not be worthwhile. Your decision to localize this log file depends on a number of factors: program design, ease of use, cost of translation, and supportablity.

Organizing ResourceBundle Objects

You can organinze your ResourceBundle objects by loading each one of them with a different category of objects. For example, you might want to load all of your Button labels into a ResourceBundle called ButtonLabelsBundle. Loading the related objects into different ResourceBundle objects offers several advantages:

• Your code is easier to read and maintain.
• Retrieving an object from a ResourceBundle is faster if the ResourceBundle contains a small number of objects.
• Translators will find it easier to work with smaller properties files.

Most locale-specific data consists of String objects. If your String objects need to be translated, store them in a ResourceBundle object that is backed by properties files. If you use properties files, translators can add support for additional languages by creating new properties files. Your localizers won't have to call you up and ask you to create more classes every time a new Locale requires support.

Isolating Locale-Specific Data