1

In software that has multiple languages available, inevitably there are times where some text is not available in a particular locale. What is the best way to handle this situation?

Consider:

  • Some software uses the native language as keys (eg, "Welcome to Product x!") while some use arbitrary keys (eg, "MAIN_PAGE_INTRO_HEADER")
  • Is the handling different depending on if the software is commercial or open-source?

I realize the ideal is that you have 100% coverage on text translations, but that's not what I am asking for here. Sometime time pressures or lack of resources (especially with open source) mean you release without 100% coverage. Even if you think you have 100% coverage, there is always the possibility that you don't or somehow an old language file gets dropped in or one of hundreds of other things goes wrong. My question is about what should happen when it does.

gregmac
  • 410
  • 2
  • 9
  • 1
    in dev builds I suggest making the missing values obvious – ratchet freak Oct 16 '12 at 15:56
  • @ratchetfreak Agreed, and in my case I have a build that updates i18n files and also reports on how many strings are missing for each. However, it doesn't address what to do when the count > 0. – gregmac Oct 16 '12 at 16:05

3 Answers3

1

Speaking from own experience, we substitute missing i18n properties with the property taken from the language that will be recognized by the most amount of users in the demographic, which in our case is English.

Using the English translation will make more sense than using some i18n identifier, which in our case could look like:

com.smarttrust.m2m.ui.admin.administration.view.CustomerRetryInheritedViewDescriptor.inheritedSlowRetryInterval.title

This would not look good in any interface.

This would of course still be a problem and the best approach is to try and keep all i18n files up to date.

AndroidHustle
  • 16,241
  • 2
  • 53
  • 80
1

you could fall back to a default i18n file that you guarantee is complete

in dev testing you can make each value "!"+key+"!" (maybe truncated) so you see immediately where one is missing

in releases you can fill the default with a language the user can be assumed to understand (english comes to mind)

ratchet freak
  • 276
  • 2
  • 6
0

I agree with the others, that showing a fallback language is the way to go. Don't show the i18n keys, except to developers or your translators.

One thing I've added in the past though is that when you do fall back (to English in my case) the English becomes a button or link which takes you directly to an interface where you can provide the translation. As soon as the translation is entered the system starts to use it. This is easy on the web, not so simple with a desktop app, but still possible.

I did this because it made it easier to explain the context of each phrase to the translators. I wouldn't suggest you do this with your end users unless you have a very strong relationship with them. You probably wouldn't want translations to become instantly active either, but more of a "suggest a translation" feature.

This works really well in dev testing though. I was working with non-technical translators, who I didn't want to have to edit i18n files directly (especially as the other language was Arabic, which is RTL, and that makes editing a mixed file quite tricky). So instead I provided a simple interface for them.

Peter Bagnall
  • 1,044
  • 7
  • 11