Open toshovski opened 6 years ago
A fallback language is really an essential thing to have. I'm hoping this PR will get merged soon!
@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.
@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.
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"
.
Complex formats won't be output, if the translation is missing. And why this is good, here some examples:
console.warn()
, if a translation is missing, so they can be found fast.
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:
fr
language fortranslated
it will return the french version of itfr
language fornot_translated
it wil check the en dictionary i there's no translation will fallback into the english one.Actual outcome
fr
will return empty stringLive 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