Support for language code mismatches between Wagtail and Smartling

[stevejalim]

The README note the lang code must match perfectly with the lang codes that Wagtail is expecting (e.g. fr vs fr-FR).

For most languages in our own use-case, I don't think that'll be a problem, but there will surely be lang codes in Smartling that don't match the code used in a site.

If we had to, say, map ro-RO to ro, is there an obvious place to monkey-patch that in, or does it require doing deep, deep down?

If it helps, we have a pattern in Bedrock and SUMO where we monkey-patch django's translation.get_langauge to "normalize" it from all-lower-case to into mixed case (which is what we need) - you can sort of see it here https://github.com/mozilla/bedrock/blob/main/bedrock/base/middleware.py#L136).

I'm wondering if that kind of approach would let us fixup, say "ro-RO" <-> "ro" as needed.

But that approach, of course, depends on middleware running, which wouldn't happen if it was an enqueued task, for instance.

[zerolab]

This was one area Ben and I went back and forth and didn't reach a good consensus. I wonder if the approach would be to make it configurable and allow passing a callable (a la django-debug-toolbar's SHOW_TOOLBAR_CALLBACK)

This way the implementer has full freedom and we don't have to worry about things like middleware or whether certain functions exist or not?

[stevejalim]

Yes, please - that'd be my personal ideal, and generally better for configurability. We only monkey-patch in Bedrock where we really have to, and if we can avoid it, great!

[zerolab]

@stevejalim opened #6 Needs a few more tests, but worth having a look to check if you're happy with its shape