Conversion between Django-side language codes and Smartling side language codes is opinionated, but needs to be flexible

[stevejalim]

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 using get_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:

WAGTAIL_LOCALIZE_SMARTLING = {
   ...,
   "STANDARDIZE_LANGUAGE_CODES": True # default - if set to False the lang codes' case will not be changed at all
}

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.

[stevejalim]

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

[zerolab]

Fixed by #18