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/[email protected]>
_______________________________________________
rails-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/rails-dev
