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-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-devel-list
