[openstreetmap/openstreetmap-website] Add translation migration health check (PR #6836)

[Andy Allan]

gravitystorm left a comment (openstreetmap/openstreetmap-website#6836)

There will always be a short gap before the translation keys are updated. This happens both when adding new translation keys and also when renaming existing ones. It's not ideal, but it's only a short delay of a few days at most. Unless we completely change our workflows I think this is unavoidable, and we should just accept the tradeoffs involved.

We offer a deploy-from-master-at-any-time release process. This has several advantages, including minimising the time between merging a PR and it showing up on the website, and being able to add emergency fixes at any time. If we move to a situation where we can't always deploy the latest master - e.g. if we block deployments while we are waiting on translation key updates - then we will need to have point releases on branches, for emergencies at least, if not more. This adds a lot of complexity, and complexity for sysadmins during emergencies is not good. We would also need to communicate this with other deployments, that they should watch out for any hotfix branches etc - again adding complexity. Or we would have to move to versioned releases, but this slows down new features dramatically.

For the translations, they currently go through a multi-stage cycle where we:

* add or rename a translation (by merging a PR)
* wait for translatewiki to import the new keys (I don't know when or how often this happens)
* wait for translatewiki to export the new keys (roughly twice per week at the moment, most Mondays and Thursdays)

If we merge a PR, and then we need to wait for steps 2 and 3 to happen before deployment, what happens if we merge another PR just before step 3 completes? Are we still blocked? If we merge PRs frequently, like one every 2-3 days, then we could be blocked without a release for weeks at a time, since the translation keys would never be 100% up to date with the stream of PRs.

We could consider having a "preview-i18n" branch, where we merge PRs with any i18n changes, and then wait for translatewiki to update the keys, and then after that merge the PR to master. But this doesn't work for renames, where translatewiki would effectively remove the old keys on master before we've merged the preview PR. We'd be back to having to block master until the translation keys and code are back in sync, so this wouldn't really solve anything.

I can't see a way forward that preserves both benefits of the deploy-from-master-at-any-time approach while preventing the occasional translation-key glitches. To avoid any situation where there are unsynchronised translation keys, we would need to move to release branches, work with translatewiki on being able to translate the pre-releases in parallel to actual releases, and so on. I don't think it's worth the effort.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/6836#issuecomment-3952578302
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/pull/6836/c3952578302 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20260224/8e65a10c/attachment.htm>