Re: GNOME 2.24: Worst release cycle I have been a part of [l10n/i18n]

Le dimanche 12 octobre 2008 à 14:12 -0400, Tristan Van Berkom a écrit :
> About translation teams in gnome, I dont know if were doing whats best, and
> I'm sure there is room for improvement on this front, let me share my pov being
> the CM of my own project, I have to manage branches and stuff when we
> make development spikes or stable releases - what is LOOKS like to me,
> is that we are WASTING the translations, I may be wrong, but this is how
> it usually goes:
> few weeks before freezes: were concentrating on bugfixes, and holding new
>                                       stuff back a bit, planning the
> next release
> freeze comes: we generally branch here, as a small team we need to move fast
>                      to get new features in --> at this point
> translators are translating the
>                      stable branch, and they are translating ALOT at this time.

Not true for most modules. I've no numbers here, but I think most
modules branch between 1-2 weeks before and after the *release*.

> release comes: more bug fixes, generally never any user visible changes in the
>                        stable branch at this point.
> Now, I asked the i18n team on more than one occasion, after release time, if I
> was expected to merge all the good work the translators are doing on the
> rotting old stale branch, into trunk (generally we backport some fixes to stable
> but never the other way around) - I dont want to sound rude but I never got a
> real answer, I got a "thanks for your consideration were working on
> it" something
> along those lines.

This is clearly the work of translation coordinators. AFAIC, whenever
I'm committing a translation in a branch, I'm syncing them with trunk if
it applies. I remember having to do it for at most 5-6 modules during
this release cycle. No big deal. Of course, the later you commit the
translations, the more you have to do this.

> Now, when it comes to someone packing a distro or preparing a flashy new
> "gnome release set", I can understand people liking that they can say its
> "100% translated", but personally, and I think from one maintainer to another,
> I could care less if its all translated on release date or not, we
> obviously dont
> have the resources for that final minute touch up so who are we trying to kid ?

I'm not sure to understand what you're saying here, but I can say that
the aim of every translation team is to have most of strings translated
for a release, because that's what eventually matters for users.

> I would be much happier having translators have a go, when they have time,
> and translate new useful strings in trunk - by the time release date would
> come around there would still be a freeze - and the remaining work to bring
> translations up to 100% would be astoundingly less (seeing as most of
> the work was done during the development cycle), I would guess that
> naturally the rest of the translations would get cleared up in the next
> minor release.

I think the current workflow is globally satisfactory, even if
improvements are possible. Among other things, I think it is important
that before the freeze, developers are free to add, remove, change
strings without caring at all for i18n. And if we ask translators to do
their work during this period they will probably waste much time.

> All that being said, I still write glade, at my own pace, and I'm
> not deterred by some occasional frustrations, only sometimes I wish
> we just had more hands on deck - hopefully something good can
> come from this thread ;-)

Personally I'm not waiting much from this thread. It's OK to remind
everybody of their respective duties. But the current process seems fine
to me and I'm sure most people, developers and translators, are already
doing their most to do a great job. Thanks to all!
As Leonardo said, when GNOME is going forward fast, translators sweat.
In this perspective, I can only hope that we'll continue to have hard
times as translators :-)  


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]