For applications need internationalization, they normally have Graphical User Interfaces, i.e. the Brief Demo Application , it's easy to provide a widget for the user to select a Locale for his preferred language. And further the user-select Locale can be used as a specifier to retrieve localized metadata, then display those localized infomation onto the GUI.
But modern software applications normally consist of multiple components, and tends to reuse plenty of libraries from third parties. The fact comes that in most cases, most of the functionalities and logics are in the lower-level components or libraries those don't ask the end users directly for a Locale.
There are several ways for these lower-level code to be Locale sensitive:
Use the running JVM's Default Locale .
This solution adds bad smell to internationalizable components/libraries, especially for code that run at server side. It requires to call Locale.setDefault(Locale l) to change the preferred Locale for an end user, which is undesirable for server applications, and even for a client application, this could lead to inconsistency with many legacy Java components those one-time initialized relying on the Default Locale at JVM startup.
Don't remember a Locale, ask a Locale argument for every interfacing method that should be Locale sensitive.
This solution has negative impact on overall performance (bigger call-stack size, more time to invoke/return), and add burden for application programmers that to write extra code to obtain the preferred Locale and pass it on.
Remember a Locale locally, and provide
setLocale(Locale l);
or simular methods for the application to set it.
This solution won't be correct at server side unless the local Locale is maintained as a per user session bias. Any worse, it introduces new complexity for applications to maintain consistency of preferred Locale across mutiple components/libraries.
Set a ThreadLocal Locale across all level of Java code. An application just set the context Locale before invoking other components/libraries. So implemented components/libraries just honor this context Locale to produce correct Locale sensitive result.
This solution is natively supported by Meta Facility, all components/libraries based on Meta Facility always make metadata inquiries by MetaBundle methods without the Locale argument to enable this solution. And applications based on Meta Facility just invoke MetaBundle.setContextLocale(Locale l) once before calling all such components/libraries to be gracefully Locale sensitive.
When writing multi-layered applications, a best way to pass the preferred Locale through layer boundaries is to set it in context.
Monolayered applications, or occasional metadata inquiries with Locale preference in hand will want to just pass the preferred Locale as an argument to MetaBundle methods.
