You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Edit] I've changed the following proposal to be as simple as possible
[README.md] "The first translation that's registered will be used as the fallback."
This may sounds quite pragmatic first, but in the end this approach has really severe problems:
It's NOT possible for an app NOT to use a fallback language - at least not without doing some odd things like registerTranslation({ $code: '$$fake-fallback-lang$$', $name: '', $dir: 'ltr' }). In many apps, the supported languages are well-known and the document element's lang attribute will always be set properly by the app itself, so if a translation is NOT given, you do not want a "fallback", but an error message as this is just a bug which has to be fixed before the app will be published.
Function registerTranslation is a violation of the "principle of least surprise". Normally, nobody would guess that a function called registerTranslation will also set the fallback language implicitly on certain conditions.
Function registerTranslation is a violation of the "single-responsibility principle", it should only "register translations" and nothing else.
The whole approach is quite invasive and its behavior sometimes hard to predict: Every file, every module, every library that uses registerTranslation may intentionally or unintentionally set the fallback language, like for example shoelace is doing it:
[Shoelace doc] "Shoelace uses English as a fallback to provide a better experience than rendering nothing or throwing an error."
Possible solution:
Just use attribute data-fallback-lang on the <html ...> element to configure the fallback language (for example: <html lang="it" data-fallback-lang="fr">).
Something like this may work (not tested yet): Show diff
Default fallback language should be en (like already done for shoelace), to make the components show English texts as fallback by default. <html lang="it-CH" data-fallback-lang="fr"> will set a different fallback language. <html lang="it-CH" data-fallback-lang="none"> will not use any fallback language at all.
The text was updated successfully, but these errors were encountered:
[Edit] I've changed the following proposal to be as simple as possible
This may sounds quite pragmatic first, but in the end this approach has really severe problems:
It's NOT possible for an app NOT to use a fallback language - at least not without doing some odd things like
registerTranslation({ $code: '$$fake-fallback-lang$$', $name: '', $dir: 'ltr' }). In many apps, the supported languages are well-known and the document element'slangattribute will always be set properly by the app itself, so if a translation is NOT given, you do not want a "fallback", but an error message as this is just a bug which has to be fixed before the app will be published.Function
registerTranslationis a violation of the "principle of least surprise". Normally, nobody would guess that a function calledregisterTranslationwill also set the fallback language implicitly on certain conditions.Function
registerTranslationis a violation of the "single-responsibility principle", it should only "register translations" and nothing else.The whole approach is quite invasive and its behavior sometimes hard to predict: Every file, every module, every library that uses
registerTranslationmay intentionally or unintentionally set the fallback language, like for exampleshoelaceis doing it:Possible solution:
Just use attribute
data-fallback-langon the<html ...>element to configure the fallback language (for example:<html lang="it" data-fallback-lang="fr">).Something like this may work (not tested yet): Show diff
Default fallback language should be
en(like already done forshoelace), to make the components show English texts as fallback by default.<html lang="it-CH" data-fallback-lang="fr">will set a different fallback language.<html lang="it-CH" data-fallback-lang="none">will not use any fallback language at all.The text was updated successfully, but these errors were encountered: