Product Strategy with Hudson Rowland
January 4, 2021From day one, MichiganLabs has built our company around our clients. This month, Hudson Rowland, delivery practice lead, shares insights about what it’s like to be a MichiganLabs client.
Read moreI 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:
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 “// NON-NLS
”.
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:
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.
The 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.LONG
preset:
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, paddingRight
becomes 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.
From day one, MichiganLabs has built our company around our clients. This month, Hudson Rowland, delivery practice lead, shares insights about what it’s like to be a MichiganLabs client.
Read moreAt Michigan Software Labs, we don’t simply write code to satisfy requirements. We find ways to solve problems efficiently and effectively. Knowing that a well-structured application comes down to a set of techniques and patterns, I have been exploring design pattern theories and how they shape our thinking.
Read moreClutch is a B2B research, ratings, and reviews firm located in downtown Washington, D.C.. Clutch connects businesses with the best-fit agencies, software, and consultants they need to tackle business challenges together and with confidence. Clutch’s methodology compares business service providers and software in a specific market based on verified client reviews, services offered, work quality, and market presences.
Read more