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

[Kenneth Nielsen]

Hello my fellow GNOME enthusiasts

Ok so knowing that there is a tendency towards "Too Long Didn't Read",
if you think this looks to long, just skip to "A set of interesting
stats".

Now that the GNOME 2.24 release is well delivered, I though it was
time for a little evaluation. I am a translator, and as such I often
get exposed to the problems that are included, in trying to get a
bunch of hired people and volunteers working well together on a single
project. Some of these problem arise from communication problems
between the different groups and their lack of knowledge about how the
other group works, and they sometimes end up giving one or the other
group extra work. All of this is not uncommon, but this release left
an impression on me as being one of the worst ones I have had the
"pleasure" of working on. Lets recap!

gdm: I know that this particular problem has much more far reaching
implications than just translation, but let me emphasize how it looked
from the point of translators. Remembering last releases trouble with
gdm i decided to go proactive and on August 4 (right after module and
feature freeze, and release minus 1month20days) i wrote an email
asking which version we would be shipping. There is a total string
difference of 665 strings in between say version gnome-2-20 and trunk,
so it does have some effect on out workload. I was told that it was
pending a release team decision and that we would be informed within
two weeks. The next I heard of it was a mail on Sep. 22 (release minus
2days !!!!!) telling us that gdm trunk would be used. Thanks a lot.

libgweather: On August 4 (release minus 1month20 days)we were informed
of a major update in libgweather-locations. This update was so large
that it decreased all teams translation stats by about 5-6%. Obviously
the change had required a lot a work, and so could have been partially
committed earlier to give us some more time. But what is significantly
worse is, that in the following discussion on the gnome-i18n list
several incorrections in the string selection rule was identified
which can only lead me to the conclusion that the state of completion
this work is in, does not at all warrant the effort we were asked to
put in it. So thanks to libgweather-locations we, the Danish
translation team, were on Sep 25 able to proudly present[1] that fact
that we had gotten gnome 2.24 translated up to a whooping 96%, no no
not 100% as in the last two releases but 96%, nice! I am by way the
still working on it, where on occasion my left pinky cramps up from
all the "f C-j y tab" sequences in emacs.

evolution: Ok so this is not a problem that is limited to evolution,
it is just that much more visible here because it is such a big
module. In evolution this time there was an update of 368 strings, the
problem is that while going through it, I realized that a very large
part of these strings I had to update, was due to a change from ' or
" to " (I know there were at least 35 of the latter kind, the
first one is a little harder to grep for). This means, that if the
relevant devs had a some point taken ~15 minutes to discuss string
conventions, this update could have been avoided all together,
nice!!. What makes it all a little more funny is that I still saw some
' and "s left which means, that I can only assume that I will be
at it again next time. IF this is a general tendency, that means that
10% of the strings we have to update (that's about 4-600 strings) only
needs update because someone didn't bother making a convention, and
therefore essentially pi**** all over our efforts.


A set of interesting stats.
===========================

This is a list of modules, which the GNOME status page has told us on
the gnome-i18n list, that there has been made changes to AFTER string
freeze on Sep. 1 and until release. (I already sorted the ones out we
were told were false alarms).

eog 21. sep.
gtk+ 19. sep.
hamster-applet 17. sep.
cheese 15. sep.
tomboy 15. sep.
glib 15. sep.
hamster-applet 15. sep.
anjuta 15. sep.
hamster-applet 15. sep.
gnome-utils 8. sep.
mousetweaks 6. sep.
anjuta 4. sep.
gnome-session 4. sep.
deskbar-applet 3. sep.

Now I count 14 changes in there and _11_ individual modules. Surely
there is some amount of false alarms, and some legitimate freeze
breaks (i.e. the ones that are due to bugs that have been reported
very late in the release schedule). But there is also a fair amount of

"Ohh are we in string freeze"

"Don't worry, these strings will not be seen by anyone ;)"

"Calm down, this is not _technically_ a string freeze break, because
we just forgot to mark them for translation/add the file in
potfiles.in"

and

"Ehh, I have had this patch laying around for a couple of months now,
which fixes this really ugly thing, I really like to have it in and I
just forgot to commit it, would that be OK?"

's in there. Ok let my say this once so clearly that even a 10 year
old should be able to under stand it. IT DOES NOT MATTER FOR
TRANSLATORS whether it is technically a string freeze or not, new
strings means that we will have to update the module once more, and
really there are better things to spend our time on. Not knowing about
the freezes and old patches!  Come on, you are asked to stay of of the
strings for 20 freaking days each release, how difficult can that be!


All right so in short.

Get a grip everyone!!!!

or this is going to stop being funny, in fact, if it hadn't been for
good company and large amounts of red wine during this translation
update, this release wouldn't have been.

Kenneth Nielsen

[1]http://www.dansk-gruppen.dk/
_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Claudio Saavedra-5]

El dom, 12-10-2008 a las 14:08 +0200, Kenneth Nielsen escribió:
> Hello my fellow GNOME enthusiasts

> [...]

> A set of interesting stats.
> ===========================
>
> This is a list of modules, which the GNOME status page has told us on
> the gnome-i18n list, that there has been made changes to AFTER string
> freeze on Sep. 1 and until release. (I already sorted the ones out we
> were told were false alarms).
>
> eog 21. sep.
> gtk+ 19. sep.
> hamster-applet 17. sep.
> cheese 15. sep.
> tomboy 15. sep.
> glib 15. sep.
> hamster-applet 15. sep.
> anjuta 15. sep.
> hamster-applet 15. sep.
> gnome-utils 8. sep.
> mousetweaks 6. sep.
> anjuta 4. sep.
> gnome-session 4. sep.
> deskbar-applet 3. sep.
>
> Now I count 14 changes in there and _11_ individual modules.

I would like to point out that probably all of those changes were
approved by the i18n team, as requested by our procedures. If you
consider some of those breaks to be unjustified, then you could have
expressed your opinion during the freeze break requests evaluation. As a
translator, I am sure your opinion would be well considered before the
approvals were given.

> 's in there. Ok let my say this once so clearly that even a 10 year
> old should be able to under stand it. IT DOES NOT MATTER FOR
> TRANSLATORS whether it is technically a string freeze or not, new
> strings means that we will have to update the module once more, and
> really there are better things to spend our time on. Not knowing about
> the freezes and old patches!  Come on, you are asked to stay of of the
> strings for 20 freaking days each release, how difficult can that be!
>

How difficult can it be? Well, far from ideal, for sure. Translators
work is hard, I know that, and I respect it enourmosly. Seriously. But
let's not trivialize the fact that it's also hard for us to handle
issues smoothly during the development cycles. Just as volunteer
translators, volunteer developers also have a life and sometimes you
can't get your hands on the issues in the most appropriate moment. Life
sucks, but believe me that we all make our best effort to make it suck
as less as possible.

Claudio

--
Claudio Saavedra <csaavedra@...>

_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Kenneth Nielsen]

2008/10/12 Claudio Saavedra <csaavedra@...>:

> El dom, 12-10-2008 a las 14:08 +0200, Kenneth Nielsen escribió:
>> Hello my fellow GNOME enthusiasts
>
>> [...]
>
>> A set of interesting stats.
>> ===========================
>>
>> This is a list of modules, which the GNOME status page has told us on
>> the gnome-i18n list, that there has been made changes to AFTER string
>> freeze on Sep. 1 and until release. (I already sorted the ones out we
>> were told were false alarms).
>>
>> eog 21. sep.
>> gtk+ 19. sep.
>> hamster-applet 17. sep.
>> cheese 15. sep.
>> tomboy 15. sep.
>> glib 15. sep.
>> hamster-applet 15. sep.
>> anjuta 15. sep.
>> hamster-applet 15. sep.
>> gnome-utils 8. sep.
>> mousetweaks 6. sep.
>> anjuta 4. sep.
>> gnome-session 4. sep.
>> deskbar-applet 3. sep.
>>
>> Now I count 14 changes in there and _11_ individual modules.
>
> I would like to point out that probably all of those changes were
> approved by the i18n team, as requested by our procedures. If you
> consider some of those breaks to be unjustified, then you could have
> expressed your opinion during the freeze break requests evaluation. As a
> translator, I am sure your opinion would be well considered before the
> approvals were given.

Yes, either they were approved or they are in the category of
"technically not a string freeze break" which does not require
approval. Another thing is that, for the changes that does require
approval (like the patch for an old or new bug being submitted), yes,
I could have objected. However if it is a patch for a new major bug,
then it should be approved without a hickup no matter if it introduces
new strings or not. , most of the time, I do not feel knowledgeable
enough the matter to make the objection, et the very least not without
having to research the matter in which case it causes extra work no
matter what.

A separate matter is: Why do we always have to be the ones that say
no? With any luck I might be a parent one day, so I really don't want
to have to get into that habit to early. I suppose one of the thing I
asking for, is a little more project (project as in module not GNOME
as a whole) leader responsibility as well, since probably some of
these thing should have been rejected already at that level, before
even reaching us. If you want an example of this, you can read the
thread from the gnome-i18n list from Sep 16 about a string addition to
glade3. I'm not sure whether it really ended up actually adding
strings, but it was clear enough that not many thoughts had been given
to the rest of the group from them.

>> 's in there. Ok let my say this once so clearly that even a 10 year
>> old should be able to under stand it. IT DOES NOT MATTER FOR
>> TRANSLATORS whether it is technically a string freeze or not, new
>> strings means that we will have to update the module once more, and
>> really there are better things to spend our time on. Not knowing about
>> the freezes and old patches!  Come on, you are asked to stay of of the
>> strings for 20 freaking days each release, how difficult can that be!
>>
>
> How difficult can it be? Well, far from ideal, for sure. Translators
> work is hard, I know that, and I respect it enourmosly. Seriously. But
> let's not trivialize the fact that it's also hard for us to handle
> issues smoothly during the development cycles. Just as volunteer
> translators, volunteer developers also have a life and sometimes you
> can't get your hands on the issues in the most appropriate moment. Life
> sucks, but believe me that we all make our best effort to make it suck
> as less as possible.
>
> Claudio

I understand the predicament of the volunteer, especially when it
comes to time. But being a volunteer does not mean that you can ignore
your responsibilities once you are commited. Being a volunteer means
that you decide whether you perform the task or not, not that you can
decide to perform it any way or style you want to.

By the way I understand that a lot of developers, volunteers as paid,
are working as hard as they can to keep it all running as smooth as
possible, the only thing I'm saying is that this release felt worse
than usual, to a degree where it really stopped being funny to
contribute. That is a dangerous situation because that is where you
start to loose contributers. Not me off course, this is not that kind
of mail of all, besides I'm also in it for the ideology more than just
for the fun. But new contributers don't have to be exposed to that
much before they call quits and find something else, now being asked
to translated some thousands names of weather stations, a list that
they (if they follow the gnome-i18n list) might expect are far from
done being changed, might just be one of those things that could scare
them of.

Regards Kenneth Nielsen
_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Johannes Schmid-4]

Hi!

> A set of interesting stats.
> ===========================
>
> This is a list of modules, which the GNOME status page has told us on
> the gnome-i18n list, that there has been made changes to AFTER string
> freeze on Sep. 1 and until release. (I already sorted the ones out we
> were told were false alarms).
>
> eog 21. sep.
> gtk+ 19. sep.
> hamster-applet 17. sep.
> cheese 15. sep.
> tomboy 15. sep.
> glib 15. sep.
> hamster-applet 15. sep.
> anjuta 15. sep.
> hamster-applet 15. sep.
> gnome-utils 8. sep.
> mousetweaks 6. sep.
> anjuta 4. sep.
> gnome-session 4. sep.
> deskbar-applet 3. sep.

I have no stats about that but I feel that there were quite a few
changes due to the fact that translators filed bugs against
strings/untranslatable strings. I could argue now that they should have
done is earlier - but of course they don't do that before string freeze
usually so these things simply come up late in the cycle.

What was really bad in this cycle IMHO was, that lot's of developers did
NOT ask for string freeze breaks but just committed. That really
shouldn't happen in the future as anybody can read in the
MaintainersCorner how to handle these freezes. Same is for sending
announcements when "not technical string freeze" breaks happen. It makes
the work of the i18n team much easier when we know why damned-lies tells
us there have been changes if we get such announcements.

In addition what happened to gdm and glade3 (gnome-2-22 was used there)
should really not happen again. The release team has to make such
decisions early and maintainers have to announce when they will not
release from trunk for a new branch. This really sucked this cycle I
think the release-team failed here.

Regards,
Johannes


_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Tristan Van Berkom]

On Sun, Oct 12, 2008 at 1:07 PM, Kenneth Nielsen <k.nielsen81@...> wrote:
[...]

> A separate matter is: Why do we always have to be the ones that say
> no? With any luck I might be a parent one day, so I really don't want
> to have to get into that habit to early. I suppose one of the thing I
> asking for, is a little more project (project as in module not GNOME
> as a whole) leader responsibility as well, since probably some of
> these thing should have been rejected already at that level, before
> even reaching us. If you want an example of this, you can read the
> thread from the gnome-i18n list from Sep 16 about a string addition to
> glade3. I'm not sure whether it really ended up actually adding
> strings, but it was clear enough that not many thoughts had been given
> to the rest of the group from them.

Dont worry, I'm not taking offense, I read your previous post and
wanted to share my feelings already ;-)

In this release cycle I've been a little less than communicative, and
for that I apologize, I've been feeling my own brand of disgust, and thats
completely my own fault.

If its any consolation, I did send a call for aid email to d-d-l some
months ago, stating that there was no way we could be ready for
this release unless someone were to step in (it was kind of a heads up)
but I should have sent an official email to i18n/release-team.

[...]
> I understand the predicament of the volunteer, especially when it
> comes to time. But being a volunteer does not mean that you can ignore
> your responsibilities once you are commited. Being a volunteer means
> that you decide whether you perform the task or not, not that you can
> decide to perform it any way or style you want to.

From that statement I can make an educated guess that you are
severely underestimating our lack of resources.

Lets take a look at the particular life a solo flying maintainer in
gnome, myself.

I worked alot on glade, and that is an understatement - I've brought it to its
first release - I saw it through the creation of the devtools suite
and advocated
the new suite, on top of working on glade, I tried my damndest to help get
gtkbuilder on the road for gtk+, since development roads in libglade were
pretty much closed.

This year was the dawn of 2008 and gtkbuilder was finally ready, and everyone's
stuck using a conversion script for glade files - when it comes to
free software,
any maintainer will tell you that people are far quicker to criticize
shortcommings
than to contribute patches - this is the brand of disgust /we/ have to
live with.

Now I'm not pulling stats out of svn, but some estimations that may startle are
that glade code base, on average in the last few years is probably made up of:
80% me
15% Juan Pablo Ugarte
5% Vincent Geddes, chpe and others
.... and Im not even kidding, I actually consider that a generous estimation.

This year we had an exceptional volunteer soc student that submitted many
anjuta related patches - some of which were even remotely relavent to the
gtkbuilder centric release I have no choice but to make (I'm over emphasizing
here, so you get my drift..).

Now, that was venting, but I think productive, I learned a few things
from hearing
you vent so I thought you should here my side, and now for something completely
different:

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.

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.

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 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.

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 ;-)

Cheers,
                           -Tristan
_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Jorge González González]

El dom, 12-10-2008 a las 19:55 +0200, Johannes Schmid escribió:

> Hi!
>
> > A set of interesting stats.
> > ===========================
> >
> > This is a list of modules, which the GNOME status page has told us on
> > the gnome-i18n list, that there has been made changes to AFTER string
> > freeze on Sep. 1 and until release. (I already sorted the ones out we
> > were told were false alarms).
> >
> > eog 21. sep.
> > gtk+ 19. sep.
> > hamster-applet 17. sep.
> > cheese 15. sep.
> > tomboy 15. sep.
> > glib 15. sep.
> > hamster-applet 15. sep.
> > anjuta 15. sep.
> > hamster-applet 15. sep.
> > gnome-utils 8. sep.
> > mousetweaks 6. sep.
> > anjuta 4. sep.
> > gnome-session 4. sep.
> > deskbar-applet 3. sep.
>
> I have no stats about that but I feel that there were quite a few
> changes due to the fact that translators filed bugs against
> strings/untranslatable strings. I could argue now that they should have
> done is earlier - but of course they don't do that before string freeze
> usually so these things simply come up late in the cycle.

I don't think that our work, as translators, is to review translatable or not strings. This should be done by developers, not translators, we already have thousands of modules to translate and people to coordinate.

Cheers.
--
Jorge González González <aloriel@...>
Weblog: http://aloriel.no-ip.org
Fotolog: http://www.flickr.com/photos/aloriel

_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Leonardo F. Fontenelle]

I agree that translating GNOME 2.24 was harder than usual, but that is a
consequence of overall improvements in GNOME. The large number of new
messages in libgweather-locations, for instance, is a collateral effect
of an enhanced internationalization feature. I really want Brazilian
cities, for instance, to be available in the locations list. As Claudio
Saavedra said, the development cycles have been hard to developers as
well. Remember that GVFS almost didn't get FTP support in time for GNOME
2.22!

I believe Glade was worst than GDM in this development cycle, from the
translators' point of view. We only discovered *by accident* we should
be translating branch gnome-2-22, when a string change was made after
the string freeze. The GDM version, in contrast, was informed in the
last minute just because the developers and the release team didn't know
it, too, until that moment.

I agree a quoting style would be desirable, even if I don't have the
time to do that outside the scope of my translation team's work.

--
Leonardo Fontenelle
http://leonardof.org

_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Jorge González González]

Hi,

I agree on mostly everything Kenneth said, plus I would, again, mention
the documentation, Some modules didn't branch the documentation, still.

Besides some developers take a while, quite a lot though, to reply to
the bugs we open asking for some feedback to translate strings, for us,
many of the strings *are* *not* obvious, therefore we really need this
context. I'm not saying all the modules should have the great and
extensive comments Orca has, but it would be very nice if developers
cared a bit more about translations, just think that many people
wouldn't use software if it wasn't translated.

My 2 cents.

Cheers.
--
Jorge González González <aloriel@...>
Weblog: http://aloriel.no-ip.org
Fotolog: http://www.flickr.com/photos/aloriel

_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Andre Klapper]

Am Sonntag, den 12.10.2008, 20:17 +0200 schrieb Jorge González González:
> I don't think that our work, as translators, is to review translatable
> or not strings. This should be done by developers, not translators, we
> already have thousands of modules to translate and people to
> coordinate.

OK, let's close Bugzilla completely if developers should find all bugs
themselves. I just wonder if there will be time left to write code.

I've written this a lot of times:
I especially expect trunk users, and those very few translation teams
with much manpower (translating trunk way before string freeze starts)
to report such issues *before* string freeze takes place. Then there
will be less string freeze breaks too.

andre
--
 mailto:ak-47@... | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Claude Paroz-2]

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 :-)  

Claude

_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Tristan Van Berkom]

On Sun, Oct 12, 2008 at 3:12 PM, Claude Paroz <claude@...> wrote:
[...]

>> 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.
>

What Im trying to say, is that me, with a few hands to help out
can try to make a release on a given date; I even think we do pretty well
in contrast with corporations I've worked for - but there will always be
remaining unforseen bugs and tidying up to be done after the release,
bottom line: if we barely have the resources to dish out a marginally
complete release in 6 months - how can we expect translators to
reach 100% in 20 days ?

Then again, from my point of view gnome translations have always
been a mysterious process - so if its comfortable for translators
and release team then thats great.

[...]
> 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 :-)

Very positive point :D

Best regards,
            -Tristan
_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Jorge González González]

El dom, 12-10-2008 a las 21:07 +0200, Andre Klapper escribió:

> Am Sonntag, den 12.10.2008, 20:17 +0200 schrieb Jorge González González:
> > I don't think that our work, as translators, is to review translatable
> > or not strings. This should be done by developers, not translators, we
> > already have thousands of modules to translate and people to
> > coordinate.
>
> OK, let's close Bugzilla completely if developers should find all bugs
> themselves. I just wonder if there will be time left to write code.
>
> I've written this a lot of times:
> I especially expect trunk users, and those very few translation teams
> with much manpower (translating trunk way before string freeze starts)
> to report such issues *before* string freeze takes place. Then there
> will be less string freeze breaks too.

I'm not saying to close Bugzilla completely, I'm saying we, translators,
don't have time to build every single module and report bugs; we all
have works, studies and a life, can you imagine how many time would I
need to build and check every single string of the hundreds of modules I
translate? I guess you do. But yes, perhaps those users using the trunk
version are greatest manpower and bug reporters, but again, it would be
so much for us.

>
> andre
--
Jorge González González <aloriel@...>
Weblog: http://aloriel.no-ip.org
Fotolog: http://www.flickr.com/photos/aloriel

_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[Kenneth Nielsen]

Hey all

Ok, so a lot of feedback, which was really what I had hoped to get from this thread, and a few answers, but no goals higher than that ;)

In general: My main concern was to raise awareness of the fact that this one was worse than usual. I have now gotten a few good answers as to why. From what people are telling me in this thread it is because GNOME went though some large infrastructure changes, ok, that is something I can understand and then I wont mind the extra work. But then, if we are headed for another one of those anytime soon, then a simple heads up would nice (Now I certainly don't hope that there was one and that I missed it). A small email of warning and motivation, "We are making big changes. It's is going to mean extra work for you. Let's pull through !!" would be nice.

Now to answer some people:

Tristan:

> A separate matter is: Why do we always have to be the ones that say
> no? With any luck I might be a parent one day, so I really don't want
> to have to get into that habit to early. I suppose one of the thing I
> asking for, is a little more project (project as in module not GNOME
> as a whole) leader responsibility as well, since probably some of
> these thing should have been rejected already at that level, before
> even reaching us. If you want an example of this, you can read the
> thread from the gnome-i18n list from Sep 16 about a string addition to
> glade3. I'm not sure whether it really ended up actually adding
> strings, but it was clear enough that not many thoughts had been given
> to the rest of the group from them.

Dont worry, I'm not taking offense, I read your previous post and
wanted to share my feelings already ;-)

In this release cycle I've been a little less than communicative, and
for that I apologize, I've been feeling my own brand of disgust, and thats
completely my own fault.

If its any consolation, I did send a call for aid email to d-d-l some
months ago, stating that there was no way we could be ready for
this release unless someone were to step in (it was kind of a heads up)
but I should have sent an official email to i18n/release-team.

Well I only saw the one thread I linked to, so I hope you can understand how I would perceive it that way. I did gather form you wording in those email that probably something else was going on, but I had no other information and it didn't really seem like the time to ask. It is sad that communication didn't work because, at least in my point of view, we would be better off releasing some modules with a lower frequency than to push developers.

[...]
> I understand the predicament of the volunteer, especially when it
> comes to time. But being a volunteer does not mean that you can ignore
> your responsibilities once you are commited. Being a volunteer means
> that you decide whether you perform the task or not, not that you can
> decide to perform it any way or style you want to.

From that statement I can make an educated guess that you are
severely underestimating our lack of resources.

Lets take a look at the particular life a solo flying maintainer in
gnome, myself.

Whoahh. I certainly wasn't talking about solo maintainers, and if GNOME in general is written only by those then I'm way off. I was talking about the way that existing team leaders (or solo maintainers) shepherd new contributers. In this case, if someone like you DO take in new contributers, then you are responsible for making them understand (and control) that they should adhere to the policies and work flows of both yours and the main project. If you don't have the resources for that, then don't take them in, because then they are likely to do more harm than good. What I was referring to was the fear we sometimes have of teaching new people the rules, because we fear that the trouble of learning them might scare them away.

Now, that was venting, but I think productive, I learned a few things
from hearing
you vent so I thought you should here my side, and now for something completely
different:

Maybe we should have group sessions in IRC? #frustrated-anonemous *G*

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.

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.

Well it as damned shame that you didn't get an answer. You generally don't need to worry about that. If we commit to a branch we merge the new translations into trunk as well (or at least we should be, at least I certainly am)

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 ?

No well but we actually do have the resources (At least some quite a few of the teams do) and we really want to have it fully translated. You see the thing is that our users generally dont need to see more than a single english string in a central place in order to jugde it is being a shitty translation. Completion is very important for the quality evaluation.

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)

Yes but translating outside of freeze also always means more waste, since strings are in motion. When we have the resources for it, we do it, but not in general.

Leonardo:

I agree that translating GNOME 2.24 was harder than usual, but that is a
consequence of overall improvements in GNOME. The large number of new
messages in libgweather-locations, for instance, is a collateral effect
of an enhanced internationalization feature. I really want Brazilian
cities, for instance, to be available in the locations list.

Yeah ok, but still, wasn't it at all possible to commit some of those changes on the fly in stead of dumping it all at once 1 month and 20 days before release.

Claude:

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.

Agreed on all accounts

Best regards Kenneth Nielsen

_______________________________________________
gnome-i18n mailing list
gnome-i18n@...
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[F Wolff-2]

On So, 2008-10-12 at 14:08 +0200, Kenneth Nielsen wrote:
> Hello my fellow GNOME enthusiasts
>
> Ok so knowing that there is a tendency towards "Too Long Didn't Read",
> if you think this looks to long, just skip to "A set of interesting
> stats".

....

Hall