I18N: Missing translations for audits

[fbatschi]

We've determined around 110 messages, which are available in en-US.json but have not been translated for the different locales yet (see attachment). We are unsure what's the best way to complete these translations. We can supply translations for locale de, but not for the other 47.

What is the best process here? Should we provide a PR for one locale?
Should this be handled as a bug or a feature?

missing.txt

[patrickhulce]

Thanks for volunteering @fbatschi! Translations are periodically pulled in from Google translators every few weeks or so, so no action should be needed on your part. This just means that the locales will be a bit behind the latest version sometimes.

cc @exterkamp I wonder what rules we should establish for a release to ensure all strings made it through the roundtrip, maybe we add a publish-time step to check for this if we want to make a stronger guarantee?

[exterkamp]

@fbatschi thanks for calling this out ❤️ Love it when people get involved in i18n!

Background

So, we are in a bit of flux with translation at the moment. We have landed/are landing a few PRs #9092 #9105 that are large scale category level translations. As well as smaller PRs recently #8857 #9127 that have had new translations in them. These PRs, as you noticed, add the strings to en-US but not to any other langs.

Additionally, we have been working on a large scale refactor to our i18n pipeline #9114. This allows us to make large scale changes to links (e.g. #9385 and #9084) for free, whereas before it was a painful process behind the scenes.

Situation Today

Unfortunately, all these new translations are stuck behind #9114 because we want to have these new translations & the large scale placeholder translations done in 1 round trip instead of multiple. Therefore there has been a recent lag in translations. But stay tuned! Those translations are coming soon.

Double unfortunately, we cannot accept direct changes to our i18n files other than en-US via UIString changes. This has to do with how we translate internally. We can however, accept specific changes to specific messages on a message-by-message basis. If you have a correction (e.g. de says "Lighthouse is warming down" instead of "Lighthouse is warming up") then open an issue to call that out. But be warned, our answer to corrections may be unsatisfying because all we can do is ask translators to take another look at it, but we won't override their decisions if they decide to keep it as is.

TODO(me): make a template for reporting i18n corrections.

Guarantees

@patrickhulce I don't think we should make a translation guarantee. It has always been best effort, and we have little control over how long translations can take once they have been passed off. I could see us making a major release guarantee, i.e. every new audit in a major release should be translated. But past that, I think it should be seen as best effort. It would be nice if there was some per-message tagging system to indicate its status 😮

[brendankenny]

I wonder what rules we should establish for a release to ensure all strings made it through the roundtrip, maybe we add a publish-time step to check for this if we want to make a stronger guarantee?

one that wouldn't freak out @exterkamp too much would be adding a tc roll to the release checklist :)

With #9114 landed and then the major sections in the system (after PWA in #9105), we should get a much smoother pipeline of translations, getting closer to the several-week cadence since we'll only have a few strings added/modified at a time. Most of the time those will probably already be landed by release time, but adding it to the checklist means we wouldn't miss a single modified string or whatever in a release.

I could see us making a major release guarantee, i.e. every new audit in a major release should be translated

for major releases, agreed, we could have some cutoff date that everyone knows that past that no new strings should be added (barring emergency changes we'll just have to live with untranslated for a while, etc)

[exterkamp]

Now that #9577 has landed, and #9105 is being translated is this resolved?

[brendankenny]

Now that #9577 has landed, and #9105 is being translated is this resolved?

definitely. Anything else should be (or can be) captured in #7238