It’s a byproduct of a workaround we had to do, and is on our list of annoyances to fix some day.
What happens is that we need to make sure the currently selected locale is in the drop down list so it can be the selected item (i.e. the item you see when you haven’t clicked on the drop down yet.) When you start the client, if you didn’t change the locale at the log in screen, the current locale is the locale reported by the JVM. Once you’ve made a change with the language selector (or via scripting), the current locale will be one from the locales you’ve defined in the translations. Since the list of locales retrieved by the language selector includes the current locale, nothing extra gets added.
Currently, your work around would be to set the locale with scripting when the client opens. The good news is that while I was typing this explanation, I figured out a fix for the problem and it should be able to get into 7.7.4.
Has this been fixed in 7.7.4 ?
I am making a project on a french computer. The project will have 2 languages English and slovak. I however still have a “français” option in my language selector. And it dissapears as well when I select a language.
To solve the bug above, I don't want “Language selector adds variants that duplicate existing languages.”
Show the default language to Traditional Chinese in clients.
As the picture below, I have three languages.
I use the system.util.getLocale() to get the actual locale name when I change selection on language selector, the result are 'zh__#Hant' , 'en', 'ja'.
To avoid the component bug, I tried to use system.util.setLocale to set the locale to 'zh__#Hant' , 'en', 'ja' , that works perfectly on 'en', 'ja' and fixed the issue, but doesn't work on 'zh__#Hant', I got an error says it's an invalid format.
I believe I used a wrong locale number for Traditional Chinese, I tried'zh','zh-TW', the result are bad, anybody knows the correct locale corresponds to 'zh__#Hant'?
I'm a beginner of igntion and still not pretty sure what will happen after system.util.setLocale() execution, does this only work on language change? I am concerned about some potential changes, such as time zones, etc, that's not what I want.
Hmm... looks like we could have implemented getLocale() a bit better (having it return the language tag instead of the toString() of the Locale). I'll make a ticket to improve how we handle it when you try to use that result to set a Locale.
I'm afraid I don't know enough about the various forms of Chinese to give you a definitive answer, but the supported Locales and their language tags can be found here. It would seem that zh-TW should have worked, but since it didn't I'm not sure where to go from here.