[BUU] Error 500 on accessing /products page

[filipefurtad0]

Description

Users can't access the /products page.

This seems to affect UK instance only (so far?)

Expected Behavior

The products page should render and display the products list.

Actual Behaviour

Users are getting an error 500.

Steps to Reproduce

1. Login as a hub admin.
2. Visit the products page
3. See an error 500

Animated Gif/Screenshot

Workaround

Disable admin_v3 feature toggle.

Severity

bug-s2: a non-critical feature is broken, no workaround

Your Environment

• Version used: v4.6.1
• Browser name and version: all
• Operating System and version (desktop or mobile): all

Possible Fix

[filipefurtad0]

Thanks for pointing out the Bugsnag error @BethanOFN:
https://app.bugsnag.com/yaycode/openfoodnetwork-uk/errors/66cd6ced04655b44a9df35c6?filters[event.since]=30d&filters[error.status]=open&pivot_tab=event

It looks like the error points to this PR? #12740

Edit: this is related to locales, see discussion here. Thanks @chahmedejaz for investigating!

Also mentioned here.

[filipefurtad0]

Bumping to S1 as it seems to affect all UK users, and rolling back BUU is not an great workaround.

[filipefurtad0]

The issue is easily reproducible in staging-UK, a heads-up to @openfoodfoundation/testers we'll need to use this server to test the PR fixing it. (PS: feel free to ping if you need early testing on your upcoming PR @chahmedejaz.)

[filipefurtad0]

Together with @chahmedejaz, we've manually edited the .yml files on the server, and restarted puma service, which temporarily fixed the issue.

However I think it's a good idea to leave this issue open as any deployment will probably undo these changes and break the page again. So we'll need to decide whether we go for this solution or fix it via Transifex.

[mkllnk]

A pull request would fix this only to the next release when we pull translations from Transifex again. We need to fix this in Transifex because that's our source of truth.

Looking at the history of the files, I'm trying to work out what went wrong:

• en_AU is not affected. We never translate anything and just rely on en.yml as fallback. So Transifex didn't apply any automation and the fallback is correct.
• fr contains the French translation with the correct variable. So the translation process works.
• en_FR uses total in one and count in other. It looks like a copy&paste error.
• en_GB uses total in both. I guess that the old string was copied.

Looking at the Transifex interface, there's no way to edit the variable. You can only copy it from source or use a suggestion. So unfortunately, Transifex must have suggested the wrong version. Starting the translation for en_AU from scratch, it has several suggestions. The first one is correct but the other ones are wrong. It may also be that our previous renaming of the key confused the Transifex AI.

How do we prevent this in the future? Translators need to be more careful with suggestions. If something like this happens again, I would also raise it with Transifex. They should ensure that the translation contains only variables from the original string.

[mkllnk]

The changes have now been done in Transifex and master. This problem should be solved.