Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL

Chapter 12. Localization > Defining localized resources - Pg. 289

Defining localized resources 289 These two lines instruct Lift to log a warning when a translation key isn't present. In this instance, the function just logs an error, but it could just as easily execute any code you require. You have now seen how to configure Lift with a dynamic locale, and you've also had an introduction to how you can implement localized resources from both tem- plates and code. With this in mind, it's time to go through the various options avail- able for loading localized content from resource bundles. The next three sections deal with these options and show you how to implement each option in turn. The first option you'll be looking at is Lift's XML -based resource bundles. 12.2 Defining localized resources Web applications present a rather different localization problem compared to desk- top applications. The traditional Java view on localization is that you have a single per- locale bundle that contains all your application resources, and for desktop builds this often makes sense. But with web applications, this can become a little unwieldy, as it's not uncommon for web applications to have a moderately complex structure with lots of nested folders and pages and even page fragments. Suddenly, the Java approach of using a single properties bundle can become rather restrictive. Although Lift can still support the traditional Java resource bundles (covered in section 12.2.2), Lift avoids their shortcomings and provides a richer method of local- ization through UTF -8 XML resource files. 12.2.1 Using XML resources XML resource bundles can be located in a variety of places, but they primarily allow you to split the localized content up into logical sections: different bundles for each page or a more traditional global bundle for all pages. For example, assuming that the page URL is /some/thing, Lift will attempt to look for resources based upon S.locale with the following search path in your WAR file: 1 2 3 4 5 6 webapp/some/_resources_thing webapp/templates-hidden/some/_resources_thing webapp/some/resources-hidden/_resources_thing webapp/_resources webapp/templates-hidden/_resources webapp/resources-hidden/_resources As you can see, there are quite a number of places Lift will search for resources. The great thing here is that the first three locations provide you with page-specific resource bundles, and the last three provide global locations for common elements. Now that you know where resources can be placed, consider the following listing, which shows an example of the Lift resource XML .