Work out why manually submitted translation .po file contents are being overridden still by Wagtail defaults

[StephenAbbott]

In March, work was done to make the contents of the Open Ownership .po files show particular translations across our translated pages on openownership.org.

However these changes are still not showing up on the live site which is defaulting to the Wagtail presets.

Here is the last comment from the pull request checking in the previous work: https://github.com/openownership/openownership.org-wagtail/pull/310#issuecomment-1454674180

This ticket is for us to troubleshoot and revisit this issue in the hope of making the contents of own translation files show up

[philgyford]

@StephenAbbott To clarify this – is it solely that the Language drop-down button is displaying in the local language ("Langue", "Idioma", etc), when it should always read "Language"? Or was that just one example of several things not working?

[StephenAbbott]

@philgyford Not just the language drop-down (apologies for referring to that comment rather than having the time to flesh this out.

Here is the closed pull request for the changes to .po files that I made: https://github.com/openownership/openownership.org-wagtail/pull/310

And here are the intended changes: https://github.com/openownership/openownership.org-wagtail/pull/310/files

My hope was that the updated .po files would override the Wagtail defaults as we want to do things like use "Français" rather than "French" across every language version of the website.

The .po file should have overridden the translated texts used for site-wide top navbar, language buttons and some other site furniture.

For languages where we have translated a few resources but don't offer many resources in that language, we want the site-wide top navbar to still be in English so people don't expect that the whole website should be translated into the language they are viewing it in.

Please let me know if this helps clear things up

[StephenAbbott]

PS: The translated .po files aren't showing up on staging - https://openownership.hactar.work/fr/publications/aspects-a-prendre-en-compte-relativement-a-elaboration-de-bases-de-donnees-relationnelles-pour-les-informations-sur-la-propriete-effective/ - or on the live site https://www.openownership.org/fr/publications/aspects-a-prendre-en-compte-relativement-a-elaboration-de-bases-de-donnees-relationnelles-pour-les-informations-sur-la-propriete-effective/

[philgyford]

I've looked into this a little, and while I don't have an answer, just wanted to note down where I am or I'll forget:

• Some/most of the problem is, I think, strings that are set via Wagtail Admin, which are then translated on the site, but we don't want them to be. e.g. "Search" is specified as the title of a navbar link in Navigation Settings.
• In config/settings/base.py we have a TRANS_STRINGS list, specifying words that aren't, or might not be, used in templates or code, but could be input via Wagtail. Putting them here means that they'll be picked up as strings that need translations, just like all the marked strings in templates and code.
• "Search" is in TRANS_STRINGS.
• So, "Search" in the menu bar gets translated to "Buscar" when viewing /es/. If I change the nav link text to "Searcher" in Wagtail then it remains as "Searcher" on the page, as expected, because there's no translation for that word.

• But, the locale/es/LC_MESSAGES/django.po file specifies that "Search" should remain as "Search":

  : config/settings/base.py:519 modules/settings/models/site_settings.py:34

  : templates/errors/404.jinja:10

  msgid "Search" msgstr "Search"

  So why is it being translated to "Buscar"?

• Because Django also has some default translations for common website terms, and I assume it's these words that it is "helpfully" translating.
• Here's a StackOverflow post with a couple of solutions for overriding Django's translations (although I'm not 100% sure why our translations wouldn't already override Django's).

[philgyford]

On my dev site I've tried out this solution – making a second set of .po translation files, for overriding the stubborn terms, and that works (although I can't explain why).

But you're right, @StephenAbbott, that the translations on the staging and live sets don't seem to mirror the translations in the current files, which is making debugging this even harder.

@drcongo, can we check that compilemessages has been run on both staging and live sites?

[philgyford]

compilemessages has been run on both live and staging and their navbars look the same as each other in the languages I tried. For some reason my dev site, on the staging branch, was slightly different to them. I've no idea.

I've implemented that change above – added a second set of translation files in app/local_extra/ solely for adding the stubborn words that Django wants to "helpfully" translated into the local language, but we want to remain in English. I've added "Home" and "Search" to them (except for de which already has "Start" for "Home", which I assume is desired).

I don't know why this is needed but I'm out of other ideas, and it seems to work.

[StephenAbbott]

Thanks @philgyford. Well done for digging right in and finding a potential solution. Once this is on staging, I can do some testing

[StephenAbbott]

Signed off ✅