Closed stevejalim closed 2 months ago
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?
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!
@stevejalim opened #6 Needs a few more tests, but worth having a look to check if you're happy with its shape
The README note the lang code must match perfectly with the lang codes that Wagtail is expecting (e.g.
fr
vsfr-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
toro
, 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.