Closed stevejalim closed 1 month ago
Update: tried it by redeclaring the mixed-case lang codes like this, to try avoid them being used in downcased form:
"LOCALE_TO_SMARTLING_LOCALE": {
"de": "de-DE",
"fr": "fr-FR",
"it": "it-IT",
"ja": "ja-JP",
"nl": "nl-NL",
"pl": "pl-PL",
"ru": "ru-RU",
# Spec out ALL the lang codes that we use so that we retain
# the approprate casing, rather than have them turned to es-es
"es-ES": "es-ES",
"zh-CN": "zh-CN",
"pt-BR": "pt-BR",
},
but it didn't work, alas. Onwards with the custom setting to disable the case-fettling behaviour
Fixed by #18
I just spotted reasonable behaviour in
wagtail-localize-smartling
that goes against what some projects (eg Bedrock and Kitusne at Mozilla) regarding language codes:Here we see some deliberate case correction of lang codes, to handle Django core preferring all lowercase and Smartling preferring mixed case.
As it happens, Bedrock and Kitsune also run on mixed case and we monkeypatch
django.util.translation.get_language
to do that, but the monkeypatch doesn't "work" for this situation because it's not usingget_language
at all.I think the default behaviour is certainly reasonable, but I'm wondering about a small change that makes the case correction optional, via an additional setting:
Note that this default case-fixup behaviour only happens for lang codes which are NOT defined in
LOCALE_TO_SMARTLING_LOCALE
, so an alternative approach / fix might just be to redeclare them there (eg:"zh-CN": "zh-CN"
), but this should be documented to avoid surprise.