What do you call someone who speaks three languages?To be fair on Americans, even most of us multilingual Europeans tend to be biased when it comes to internationalization, tacitly assuming that text is written left-to-right and can be sorted from A to Z.
Trilingual.
What do you call someone who speaks two languages?
Bilingual.
What do you call someone who speaks one language?
American.
Most Java developers are familiar with resource bundles backed by properties files. The basics can be found in the Internationalization Trail of the Java Tutorial. Multilingual Java applications often come with a set of properties files, e.g.
- MyApp_de_AT.properties
- MyApp_de.properties
- MyApp_es.properties
- MyApp.properties
However, you may be surprised in this case to end up with a German string even when you requested a resource for an English locale.
Assume nothing is a sound principle for robust software development, and you should not assume that English is the default or fallback language. In fact, the fallback for resources from an unsupported locale is the system default locale, which is based on the host environment.
See the documentation for ResourceBundle.getBundle() and Locale.getDefault() for more details.
So when the default locale of your system is de_DE and you request a resource for locale en_US, the lookup order for the properties files is
- MyApp_en_US.properties
- MyApp_en.properties
- MyApp_de_DE.properties
- MyApp_de.properties
- MyApp.properties
There are two solutions:
- As a user, set your default locale to en when launching the application.
- As a developer, make sure to provide a properties file for locale en (which may be empty).
The preferred solution is the second one, of course. Even when MyApp_en.properties is empty, it will be picked up as entry point for resource lookup. If a given key cannot be found in this file, the parent file MyApp.properties will be used as fallback, which is just the desired behaviour.
