Only top level locales are supported (e.g. zh), second level locales aren't even though they can differ greatly (e.g. zh_CH vs zh_TW vs zh_HK)

[fred2088]

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

at the present moment, only on "zh" languages file is support

while zh_CH / zh_TW / zh_HK both are using different wording and font file

would expand to support both at the same time ? only zh.zip works fine, but not zh_HK.zip or either zh.zip or zh_CN.zip works

Regards zh.zip zh_HK.zip zh_CN.zip

Describe alternatives you've considered

No response

Additional context

No response

[jneilliii]

The only translation that is natively integrated is German if I remember correctly. All other translations are provided by the community and available via https://www.transifex.com/octoprint/octoprint/ maybe you can find the translation you're after there.

[cp2004]

The translation packs are linked in this issue, this:

only zh.zip works fine, but not zh_HK.zip or either zh.zip or zh_CN.zip works

is true, at least I can reproduce it. Can't use ?l10n=zh_HK, so need to find out why that is, maybe there is a different method of specifying it.

[cp2004]

For zh_HK the correct specifier to use here is zh_Hant_HK, so http://IP ADDRESS/?l10n=zh_Hant_HK

For zh_CN it would be zh_Hans_HK.

[cp2004]

The settings UI in OctoPrint doesn't show zh_HK or zh_CN options in the configuration for default language.

[cp2004]

For zh_HK the correct specifier to use here is zh_Hant_HK, so http://IP ADDRESS/?l10n=zh_Hant_HK

For zh_CN it would be zh_Hans_HK.

I thought this worked, but now I don't seem to be able to do it again...

I'm tempted to say the problem is somewhere in Babel, but there are issues in OctoPrint as well. There's inconsistencies over whether the Locale class is used or a simple language string in some places, which is resulting in issues. I can get them to show up in the settings with a change in OctoPrint but can't easily get it to render using the zh_Hant_HK language ID for example.

[fred2088]

it seems only one zh pack can be set from user config (may be it only look at the first two digit of the locale code)

zh : Chinese zh_HK : Hong Kong zh_TW : Taiwan zh_MO : Macau zh_Hant : Traditional Chinese zh_Hans : Simplified Chinese zh_Hans_SG : Simplified Chinese - Singapore zh_CN : Simplified Chinese - China

poedit allow both zh_TW and zh_CN to be selected ... C:\Program Files (x86)\Poedit\GettextTools\share\locale
zh_TW/zh_CN

side issue , where to report message string is not available for other languages pack ? Thanks

[foosel]

So, after some first debugging, first of all OctoPrint defaulted to only using the language part in most cases internally, which explains the second level issue.

However, there is more. In the case of the zh_HK language pack specifically the corresponding locale gets parsed as zh_Hant_HK, but the files are in a zh_HK translation folder, so Babel can't find them and falls back to english. The only options to solve that I see right now are either monkey patching babel's translation lookup to try <language>_<script>_<territory>, and if that isn't found also try <language>_<territory>, but I'm not actually sure I can do that in a clean way. The other option is to make sure any translation folders on disk are normalized to the full Locale string representation by throwing them through Locale.parse first, as that would solve this automatically.

I'll have to think a bit on how best to go forward here. In any case I'll see that I fix the ignoring of the territory part (second level).

[foosel]

Ok, that should be fixed with 1.9.0.

• Language packs installed through the settings will now get canonicalized in case they were created without the canonical locale name
• All locales inside OctoPrint are canonicalized
• Request parameters and such get canonicalized, so you can request ?l10n=zh_hk but that will internally be turned into zh_hant_hk and babel will thus find it
• babel_* helper commands in setuptools have been adjusted to generated canonicalized locale identifiers in language packs and bundled translations

No monkeys were patched while doing all of this 😜

[fred2088]

Thanks for the great effort !!!