More realistic test env for translations

[mkllnk]

What? Why?

Most production servers don't use the source locale en. Even if the default language is English, they use a local variant like en_AU or en_GB to customise some of the translations.

However the environment is configured, the app should always fallback to en if no other translation is available.

I was hoping to cover a recent bug with this change:

• Several missing translations since release v4.4.41 #12429

Unfortunately, the missing translation wasn't covered by any spec and this didn't help. But it may prevent other bugs in the future. Fallback translations are now used in tests and dev.

What should we test?

• Production and staging servers define their own locale.
• But it doesn't hurt to deploy this and follow steps in Several missing translations since release v4.4.41 #12429.

Release notes

Changelog Category (reviewers may add a label for the release notes):

• User facing changes
• API changes (V0, V1, DFC or Webhook)
• Technical changes only
• Feature toggled

The title of the pull request will be included in the release notes.

Dependencies

Documentation updates

[dacook]

I was expecting this to be a no-brainer, but it raised some questions.

What do you think of just setting it in .env.test?

I'm not even sure about that though, and wondered if we can test the fallback another way. Maybe create a test.yml locale file and make that the default for .env.test. It just needs one key to test the translation, then we can test any other key for the fallback.

[dacook]

As this affects all environments, I had a think:

• It shouldn't matter for servers, they would all have config to override this.
• It shouldn't affect devs much, because any new translation keys can still be added in en.yml, and the fallback will work. But what if they're confused and add new translations to en_AU?
• Apparently it didn't affect specs. I would have thought some differences would pop up. Maybe they would in the future.

It seems strange that en_AU is the default instead of en. I can imagine someone changing it back again just because it looks wrong.

🤔 If en_AU is the default for dev/test, then en.yml is sort of redundant. Of course it still functions as the fallback, and is the source of truth for Transifex.

[mkllnk]

If en_AU is the default for dev/test, then en.yml is sort of redundant.

en_AU is still a production locale which is edited in Transifex while en.yml is the one locale changed by devs.

We could introduce a test locale which would be a bit more robust. At the moment, the Australian team could change something that breaks specs. It would be less realistic though. 🤔

Okay, what do you think about this proposal:

• en_AU in .env.development, it's more realistic and we got other Australian data like default country and currency already.
• en_TEST in .env.test.

[dacook]

That sounds good 👍

I guess en_TEST may be empty to begin with, until we add a specific test for it.

[filipefurtad0]

So, just to make sure I understood this correctly: the use-case here for specs is to have the empty file, so we can select it for a give system spec, and assert that no error is there, which demonstrates the fall-back to en.yml works correctly.

I guess en_TEST may be empty to begin with, until we add a specific test for it.

As for this, having valid keys and translations would be useful to test that the default selection works correctly in the test environment.

So, if I get this right, we could add two new test scenarios to translations 👍

[mkllnk]

Yes, you got that right. It would be good to also test that the current locale is actually used and not just the fallback. 😉

[dacook]

Cool, thanks!

[rioug]

Great !

[filipefurtad0]

Hey @mkllnk ,

I've staged the PR and could verify that despite the missing translation files, #12429 remains fixed. For example, for the key
remaining_in_stock: "Only %{quantity} left" (missing in en_AU.yml), correctly falls back to en, and triggers no error:

For admin.order_cycles.status.open:

Looks good to me. Merging!