Tips for Localizing Android ApplicationsFebruary 9, 2016
Tips for Localizing Android Applications
I am not multilingual (since programming languages don’t count). Initially, localizing Android apps was difficult for me because I lacked experience with other languages, but I’ve learned a few simple tricks that help avoid common pitfalls:
- ALWAYS use string resources for ANY text you show to the user.
- Explicitly specify a locale when using date/time formatters.
- Pay attention to the Right-to-Left layout linter warnings in Android Studio
I’ve found that following these rules adds almost no time to the development process, especially when your IDE is properly configured to help you remember to follow them.
Every Android tutorial that I’ve seen touches on string resources at some point, so most Android developers are aware of them and use them on a regular basis. By default, Android Studio will warn you about using hard-coded strings in your layout files.
Thats great, but what about when you set the text of a UI element from your code? I recommend turning on the “Hard Coded Strings” inspection since it is not enabled by default. Open the Android Studio settings (Cmd + ,) and go to “Editor > Inspections > Internationalization Issues” to enable it. With this inspection enabled, you will be warned when you use a string literal in your code.
There are a lot of valid reasons to use hard-coded strings outside the UI, so you may also want to enable the “Ignore literals assigned to constants” option and the “Ignore lines containing this comment” option. Then, if you use a hard-coded string in a place that is not shown on the UI, you can silence the warning by adding a comment “
Android Studio also has a nice feature that hides the verbose code for using string resources and shows the string that the resource points to instead. Go to “Editor > General > Code Folding” in settings and make sure that “Android string resources” is checked. Once enabled, Android Studio will automatically fold your string resources.
I learned this one the hard way. In converting an app that was English only to support Spanish, I discovered that I was saving dates to a database without specifying the format of the date string. When using
SimpleDateFormat, if a locale is not given, the current locale of the system will be used. If I switched the language on my phone to Spanish, the data in the database was not readable because the app was now expecting the dates to be in Spanish.
The Android documentation of the
Locale class has a short warning that describes when it is appropriate to use the default locale. Basically:
- Use the default locale when the date/time info is going to be shown to the user.
- Don’t use the default locale when the date/time info is supposed to be interpreted by your code.
Android Studio can check for this too. Go to “Editor > Inspections > Internationalization issues” in settings and enable “Instantiating a SimpleDateFormat without a Locale”.
If you do intend to use the default locale, say so explicitly in your code by using
Locale.getDefault() as the locale.
Another mistake that I’ve been guilty of is assuming that the arrangement of the date elements in a date format will be the same for all languages. In English, we might format today’s date as “February 9, 2016”, but in Spanish it should be “9 de febrero de 2016”. The
SimpleDateFormat class can’t account for these differences, so the
DateFormat class should be used instead.
DateFormat class provides several presets for common date formats that adjust properly for the given locale. For example, the dates above can be correctly formatted using the
DateFormat df = DateFormat.getDateInstance(DateFormat.LONG, Locale.getDefault()); String date = df.format(new Date()); // "February 9, 2016" in English, "9 de febrero de 2016" in Spanish
Android 4.2 Jelly Bean (API 17) introduced native support for right-to-left languages (such as Arabic). Basically, this means you should use “end” instead of “right” and “start” instead of “left” when defining attributes like padding or margin. For example,
paddingEnd. If you need to support Android versions below API 17, you would just use both left/right and start/end together since the older versions of Android ignore start/end.
Android Studio will warn you if you make a layout that might not look correct when the device is in RTL mode.
Make sure you enable “Using left/right instead of start/end attributes” in “Editor > Inspections > Android Lint” (default is enabled). Most times, the start/end attributes will have the same values as left/right, so it’s very easy to add them as you create the layouts. Adding support for RTL after the fact will take much more time, so I always fix RTL warnings even if there are no current plans for RTL language support.
To test how your layout looks with a RTL language, you can force RTL mode without changing the device language by enabling “Force RTL layout direction” in “Developer Options > Drawing” in the device settings.
Stay in the loop with our latest content!
Select the topics you’re interested to receive our new relevant content in your inbox. Don’t worry, we won’t spam you.
Quickly Prototyping a Ktor HTTP APIAugust 18, 2022
Whether it’s needing a quick REST API for a personal project, or quickly prototyping a mockup for a client, I like to look for web server frameworks that help me get up and running with minimal configuration and are easy to use. I recently converted a personal project’s API from an Express web server to a Ktor web server and it felt like a breeze. I’ll share below an example of what I found and how easy it is to get a Ktor server up and running.Read more
Finding Connectedness During COVIDFebruary 17, 2021
When the world was turned upside down last March, our team was well set up for the technical side of what we do, but figuring out how to make us feel connected over a long stretch of remote work presented a new obstacle.Read more