Introduce fallback language about app-localize-behavior HOT 4 OPEN

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 #120 (Feature Request: Fallback for language variants to it's superset).

from app-localize-behavior.

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

from app-localize-behavior.

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

from app-localize-behavior.

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

from app-localize-behavior.