Android Best Practices – String resources cheat sheet

Android runs on many devices in many regions. Any application should handle text 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.

#1 Name your strings with keys that resemble namespaces.

Languages are complex, so namespaces are necessary to bring context and break ambiguity.

<string name="login.environment">Environment</string>

#2 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>

#3 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>

#4 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());

#5 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.

#6 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>