[disclaimer]


This is a personal blog. The opinions expressed here represent my own and not those of any of my employers or customers.

Except if stated otherwise, all the code shared is reusable under a MIT/X11 licence. If a picture is missing a copyright notice, it's probably because I'm owning it.

Friday, November 6, 2009

Multiple branches and translations

Fellow Package Maintainers,

How are you dealing with this ?

I guess f-spot is not the only project maintaining multiple parallel branches, a STABLE one, from which the releases and bugfix releases are created, and a master, open for business, new stuffs, and experimentations.

When we need to correct something on the STABLE branch, we push a new commit over there, then merge the STABLE back to master so it gets the same fixes. That works fine.

But it gets harder with translation commits. Most of the (awesome) translators (well, all except of one) translates the master and commits right there. Then, when it's time to release, I either ignore those translations (and that's seriously annoying for translators who pushed soem work in the .po), or I blindly backport (cherry-pick) the translations back to the STABLE branch and hope that no strings was removed in master's code. Then I merge the STABLE back to master. Both solutions are seriously suboptimal. Really.

I know how this problem is "solved" in most of the GNOME projects by putting deadlines and code freezes, and string freezes, but I guess we're not the only project around with this kind of issue.

The ideal workflow would be to have the translators (hey guys) aware of the STABLE branch, make them translate that branch, have them merge it back to master, and then, optionally, translate the missing/changed strings and commit that to master. I said ideal, cause I'm NOT gonna ask any translator to understand and follow this, be able to maually merge if something goes wrong, etc...

Translators (did I say thanks for your job lately) are already doing an ant job, most of them with no tools but a text editor, and we can't really add any pain to the process.

So, what are you doing in that case. How could we improve the process ?

Comments are open.

4 comments:

  1. I am the coordinator of the Bulgarian Gnome translation project. On receiving a new translation I always commit on stable and master in GNOME git. Plus we have an internal svn where we keep copies of all the translations — (stable and master).
    With the sometimes huge diffrerence between the branches, I am not aware of any automatic means of solving this.
    Kind regards:
    al_shopov

    ReplyDelete
  2. Hi Stéphane,
    You should announce your stable branch to gnome-i18n and ask translator
    to commit on it (the branch will be tracked prioritarily by
    l10n.gnome.org). And when you're working in master again, just tell
    gnome-i18n about the change. Coordinators generally know the process of
    merging from a branch to trunk.

    À+

    Claude

    ReplyDelete
  3. Heh, if you were using Launchpad, translators could work only on a single version (usually stable), and translations would propagate to all versions where they are for exactly the same English string.

    It happens real-time, so there's no opportunity for duplicate work other than work that happens externally, but that's not a solvable problem :)

    FWIW, this feature was designed precisely to solve observed problem in GNOME. I hope we will be able to make GNOME (and f-spot) benefit from this feature.

    ReplyDelete
  4. You need to fix up your page at
    http://l10n.gnome.org/module/f-spot/

    It's messy; you contact gnome-i18n for this.

    ReplyDelete