Language dependent resources

Language dependent resources (think: Text strings, but it applies to other data as well) are handled very simply and independently of anything you have to program. It goes like this: all of the strings that your program is going to reference are defined in a strings.xml file. Each entry in this file consists of an element that defines the string's name, and value that defines the actual string.

From a program standpoint, you don't directly access the string value. Instead, you work with a reference to that string. To support multiple languages, you define a sub-directory in your /res directory that reflects the language selection, and then maintain a separate strings.xml file in THAT directory using the SAME string name. It's probably a good idea to have /res/values/strings.xml defined for your defaults. Then, to localize, add /res/values-es if you want to support Spanish (for instance). The extensions on that directory are based on whichever language you elect to support. The extension go further down into specific regions. For example, /res/values-en-rGB references English, Great Britain (to prevent heavy weeping over "center" vs. "centre", and "trunk" vs. "boot", I guess.)

If you had the following defined in your /res/values/strings.xml file:

<string name="WaterStr">Water</string>

...and you wanted to display the equivalent for Spanish users, you would define the following in /res/values-es/strings.xml:

<string name="WaterStr">Agua</string>

The one area I'm not entirely certain about is whether the file name needs to be the same. If I have multiple files defined, couldn't I just combine them into a single file rather than creating multiples in each directory for each language? I don't think the aapt tool cares how things are defined -- just that they are and are located in the correct sub-directory.

Further, I'm guessing if you don't have something defined in a language specific file, it will simply default to whatever value is given in /res/values. In the example above, if I failed to define the Spanish version of WaterStr, the default WaterStr would simply be used.

Next chapter in the AWAD book deals with Exploring User Interface Screen Elements. Finally getting to some good stuff. Wahoo.