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?


  • 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.

  • 1
    in dev builds I suggest making the missing values obvious Oct 16, 2012 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, 2012 at 16:05

3 Answers 3


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)


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:


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.

  • 1
    +1 and to extend your UX-based objection to seeing com.smart... to a security perspective: you should never expose your back-end to your users.
    – msanford
    Oct 16, 2012 at 18:17
  • 1
    @msanford you're so right Oct 16, 2012 at 20:47

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.