Are updated translations backported from a module's main branch?

Take GNOME Shell’s main branch, for example, where I recently fixed up some odd translations and submitted it to the main branch on l10n. Would the updated translations be automatically backported to previous releases, would someone have to manually backport them (read: copy & paste), or would nothing happen?

They need to be manually backported, i.e. the translation on the old branch needs to be done in a Vertimus workflow just like the main translation was. Module Statistics: gnome-shell

1 Like

Is it usually worth the effort for distros with reasonably up-to-date packages like Fedora?

I guess it’s up to your language’s translation team, and how impactful those changes are. There isn’t a rule about it

1 Like

Sorry to sorta hijack/necro this thread, but was under the assumption that only the latest version of GNOME (aka the one currently in development, unstable) would receive updates to translations. While it is possible to submit translations to stable and oldstable, I thought l10n updates in these branches would never get to the end user. Is this not the case?
The GNOME Release Calendar makes it seem that stable and oldstable are only receiving bugfixes and performance improvements:

Reminder: old bug fixes and performance improvements are allowed for stable branches. No feature, string, UI, or API/ABI changes are allowed without a corresponding freeze exception approval.

Let’s look at the current cycle for a concrete example. 47 is stable and 48 is the development version.

This page tells us that the upcoming stable releases are 46.9 and 47.4, with 48.beta coming as well.

If you translate a GNOME module today, you should first do so on the branch that is attached to the GNOME 47 set on Damned Lies, if it isn’t at 100% yet. Most likely gnome-47. That work should make it into 47.4. At the time the coordinator (or committer) commits it from Damned Lies, they should be offered a checkbox to cherry-pick to the development branch, i.e. apply the changes there as well. It may not bring the development branch to 100% if new strings were added in the meantime, but it will ensure the work is not done twice, and it might actually lead to 100%. That’s why Damned Lies is still showing 47 and not 48 yet.

As for 46, it’s still open on Damned Lies, but that’s mostly to be able to fix mistakes there. Please don’t set reaching 100% there as a goal. It would be a waste of time.

The “bug fixes and performance improvements” reminder is targeted at developers. If translations land in the repo on these branches, they will of course be included.

2 Likes

Thank you, this cleared up a big misconception on my part - point releases do in fact update the translations. TIL!

1 Like