Introduce fallback language

[toshovski]

Description

In bigger applications the translations into different languages takes time and the translation is not always 100% complete. For this reason I would like to propose a fallbackLanguage attribute. This will fallback to the default language.

Expected outcome

Let say I have two variables:

'en': {
    'translated': "english",
    'not_translated': 'hello'
},
'fr': {
    'translated':"français"
}

1. variable is translated in both languages
   When I try to use the fr language for translated it will return the french version of it
2. variable is not translated
   When I try to use the fr language for not_translated it wil check the en dictionary i there's no translation will fallback into the english one.

Actual outcome

fr will return empty string

Live Demo

I already did an implementation of this feature: https://github.com/toshovski/app-localize-behavior

Do you still accept feature requests for polymer 1.x and 2.x elements?

Steps to reproduce

Browsers Affected

• [ x] Chrome
• [ x] Firefox
• [ x] Safari 9
• [ x] Safari 8
• [ x] Safari 7
• [ x] Edge
• [ x] IE 11
• [ x] IE 10

[TrebuhD]

A fallback language is really an essential thing to have. I'm hoping this PR will get merged soon!

[toshovski]

@TrebuhD thank you for the review. I fixed the issues. You can take a look at my fork. I already merged it to master and added another feature for multi level structured translations.

[TrebuhD]

@toshovski Thanks! I've actually been using your fork in my project, and because of that I managed to find some more issues :) - check out my recent commits here.

[NoLdman]

There is already a (sort-of) fallback mechanism in app-localize-behavior: it's called useKeyIfMissing.

I think the biggest misconception in app-localize-behavior (and intl-messageformat) is, that you have to use abstract key values. You can use natural language instead (incl. special chars). e.g:

{
  "fr": {
    "Bonjour le monde!": "Bonjour le monde!"
  },
  "en": {
    "l'œuf": "egg",
    "Bonjour le monde!": "Hello world!"
  }
}

So if you declare language="fr" as your output-language, the egg would still be output as "l'œuf".

Limitations (...in my opinion good ones)

Complex formats won't be output, if the translation is missing. And why this is good, here some examples:

• Date "1/2/2018": for an Australian ("en-AU") this would be the "1st of February", for an American ("en") but the "2nd of January".
• Number "1.125": for an American ("en") this would be "1 and 1/8", for a German this would be "one-thousand-one-hundred-twenty-five".

Better approaches

1. Output a console.warn(), if a translation is missing, so they can be found fast.
2. If you've got a language variant (e.g. Canadian French), but also ship to other languages (e.g. conventional French, German, ...) and don't want re-translate all fr-CA phrases that are the same in France, please see Feature Request: Fallback for language variants to it's superset #120 (Feature Request: Fallback for language variants to it's superset).