For any global application, supporting multiple languages is not just a feature—it's a necessity. In the Android ecosystem, managing these languages is handled through the concept of Locales. But what exactly defines a locale, and how does Android determine which one to use?
Understanding Locales vs. Languages
It is common to confuse a "language" with a "locale," but in Android development, they are distinct concepts:
- Language: A general identifier for a language (e.g., en for English, fr for French).
- Locale: A combination of a language and a specific region or country (e.g., en_US for English (United States) or en_GB for English (United Kingdom)).
The locale determines not only the text translation but also how numbers, dates, currencies, and even the direction of the layout (LTR vs. RTL) are displayed.
How Android Determines the Current Locale
Android uses the system settings provided by the user to determine the primary locale. This information is stored within the Configuration object of the application's resources.
1. The Single Locale Approach (Legacy)
In older versions of Android, the system relied on a single default locale. You could access it using:
Locale currentLocale = Locale.getDefault();2. The Locale List (Modern Android)
Starting from Android 7.0 (API level 24), Android introduced support for multiple locales. A user can select a list of preferred languages in the system settings. If your app doesn't support the user's first choice, the system will automatically fall back to the next language in their list.
To access this list, you use the LocaleList class:
LocaleList locales = Configuration.getLocales(); Locale primaryLocale = locales.get(0);Implementing Localization in Your App
To support the "list of supported languages," you don't need to manually check every possible language. Instead, you follow the standard Android resource directory pattern:
- res/values/strings.xml — Default (fallback) strings.
- res/values-en/strings.xml — English strings.
- res/values-fr/strings.xml — French strings.
- res/values-zh-rCN/strings.xml — Chinese (China) strings.
When the user changes their system language, Android triggers a configuration change. If you haven't handled this, your Activity might be recreated, which is actually the standard and preferred way to apply new string resources.
Common Pitfalls and Best Practices
- Don't Hardcode Locales: Avoid using Locale("en") directly in your logic. Always rely on the system's Configuration to ensure your app respects the user's settings.
- Handle RTL (Right-to-Left): If you support locales like Arabic (ar) or Hebrew (he), ensure your layouts use start and end instead of left and right.
- Testing Fallbacks: Always test what happens when a user selects a language that your app does not support. Does it correctly fall back to your default language?
While there isn't a single "static list" of supported languages (as it depends on what you, the developer, provide in your res folder), Android provides a robust framework via Locale and LocaleList to manage internationalization. By following the resource-based approach, you ensure your app feels native to users all over the world.