Android String resources management
01 June, 2020
Android runs on many devices in many regions. Any application should handle texts and numbers in ways appropriate to the locales where the app is used.
Using a Localization management platform to manage the String resources brings many benefits:
- Automate. New strings can be put to your codebase automatically (#FailFast)
- Collaborate. Allows many people to work on your translation project (translators, product team, etc.)
- Statistics. So you don’t miss what is important
Bringing many people to work on such a platform might end up bringing a messy strings.xml
resource file. As an Android developer, you should act as a gatekeeper. With all good intentions, I’ve listed 6 simple rules for a successful team working regarding to any Localization management process.
Use namespace
Languages are complex, so namespaces are necessary to bring context and break ambiguity. Name your strings with keys that resemble namespaces. This is also very convenient for auto-completion.
<string name="login.environment">Environment</string>
Think Features
Since most Android developers recommend packaging an app by feature, I suggest to name your localization key after your feature.
<string name="login.signup">Sign up</string>
Don’t be afraid of repeating a value for two or more keys.
Because you never know when your product team will ask to change a value for a specific feature.
<string name="login.signup">Sign up</string>
<string name="splash.signup">Sign up with Gmail</string>
Don’t write string values in all uppercase.
This must be handle in your layouts (or programatically).
<TextView
...
android:textAllCaps="true"/>
OR
textView.setText(text.toUpperCase());
No HTML tags
strings.xml
is not your design. Even if Android supports natively <b>
, <u>
and <i>
tags, try to force your designer to come up with a better solution. If your app supports many localisations, think about your translators, do you really need them to manage HTML?
Use plurals
Make sure you Localization management platform can handle plurals. This is a must-have in term of cleanliness.
Be careful, plurals don’t accept namespace notation. That’s why we should consider them as specific key.
This lack of coherence is actually helpful because it will always remind you to correctly provide your quantity parameter(s).
<plurals name="plural_post_reviews_rating">
<item quantity="zero">(%d reviews)</item>
<item quantity="one">(%d review)</item>
<item quantity="other">(%d reviews)</item>
</plurals>