UI problem with translation - fallbackLng not working

[nitram147]

I encountered this problem during usage of Chrome browser, Firefox works fine (reason mentioned below).

Browser is sending following Accept-Language request header "sk-SK;sk" (for comparison Firefox is only sending "sk").

i18n tries to fetch "sk-SK" and fail with the following error (because node backend return some default html instead of json - the locales/sk-SK/translation.json path don't exists):

Next it tries to use "sk" language and succeed. However the language swapping select stay with "EN" option selected:

So in case you want to swap your language to English, you have to select Slovak/Swedish language (swapping select pretends to be checked on "EN" option) and then select "EN" option. This can confuse users to think that there isn't English localization available.

[nitram147]

Fix should be fallbackLng setting. However: fallbackLng: { 'sk-SK': ['sk'], 'default': ['en'] }, does not seems to work. I tried to write it many different ways (based on documentation) even tried to hardcode "sk" as default fallback as in current case with "en" value, but it did not helped.

[nitram147]

This would be problem for many different languages, when there are multiple different ways how to express them in browser headers. Chrome seems to provide always multiple variation of language tag in it's header.

[nitram147]

Alternative solution (if we assume that the Chrome browser will always provide also shorter tag equivalent such as "sk") would be change the behaviour of language select menu to handle this case.

[bdkent]

@nitram147 I documented a potential solution in https://github.com/anon-real/sigma-usd/pull/37.

It uses a util method on i18n to extract the code from the language (ie, sk-SK => sk) which seems to be used internally when determining what JSON file to load. It feels a little questionable as it isn't documented anywhere but through digging into the code.

I wasn't sure how to really mimic setting the language to sk-SK, but after hardcoding i18n.changeLanguage('sk-SK'); into i18n.ts, it appeared to work as we would want.

I marked the PR as draft. Can you see if this solves the issue for you?