Re: Stricter policy when including BIG modules (was Re: Evolution 2.0 and GNOME 2.6)
- From: Kjartan Maraas <kmaraas broadpark no>
- To: Danilo Segan <danilo gnome org>
- Cc: Murray Cumming <murrayc murrayc com>, JP Rosevear <jpr ximian com>, "desktop-devel-list gnome org" <desktop-devel-list gnome org>
- Subject: Re: Stricter policy when including BIG modules (was Re: Evolution 2.0 and GNOME 2.6)
- Date: Sun, 01 Feb 2004 12:25:15 +0100
lør, 31.01.2004 kl. 20.50 +0100, skrev Danilo Segan:
> Hi Murray,
>
> Murray Cumming <murrayc murrayc com> writes:
>
> > GNOME's quality control means that there is always a risk that a module
> > might be punted or reverted to a previous version.
>
> Of course. But I mentioned that special care should be taken with
> such modules like Evolution: it's a huge program itself, it has over
> 3900 messages to translate.
I think we need to take a step back here and look at the big picture.
We've already established in another thread here that most if not all
major distros ship evolution. It will be in the next fedora release
which has a translation deadline in about a month's time so I don't
think it's that big a problem personally (speaking as a translator
here).
I think we're in danger of becoming slaves of the statistics in some
sense. I know I hate seeing those 99.xx% things just as much as everyone
else but even so I hate translating huge gconf key descriptions just as
much so I can live with not having complete translations for all
modules.
> What I'm arguing for is not to let it slip into the regular release
> cycle if it's not on par with the rest of Gnome.
>
> >
> > The translations are not lost. People will still get a lot of benefit
> > from them, and it will help greatly with GNOME 2.8. It's a shame if
> > people's only GNOME 2.6 translators credits would be for Evolution, but
> > I hope that people are translating evolution because they want to use it
> > in their language rather than to see their name in a list.
> >
>
> You missed my point. Gnome 2.6 is coming in early March. That means
> around one month for translators to complete it. That means that
> Evolution translation could have waited until after Gnome 2.6 was
> released. And it also means that many translators could have
> actually gone closer to getting Gnome 2.6 translated, if they didn't
> spend their time on Evolution NOW. So, it's a waste of work in a way
> (not to mention that this means that Evolution won't be following
> string freezes, and that there will be *real* waste, because messages
> will change before actual release as well).
>
I see that Fedora Core 2 has a translation deadline for early March too,
and that probably means that new releases of packages won't go in either
(only critical bugs fixed after that point) and I wonder how/if this
affects Evolution 2.0 being included there?
> Evolution has been postponed for 3 months, it was not merely removed
> from the release. In those 3 months, only ones who will benefit from
> these translations are testers and early accepters -- a minority.
>
If it goes into Fedora Core 2 I think the work will be worth it because
of the amount of users installing that.
[SNIP]
> Gnome is also using a list of supported languages for marketing
> (read the thread a while back about KDE having better support for
> more languages -- now here's the culprit, I say).
>
> That's why I repeat: this has a negative impact on Gnome community as
> a whole.
And we need to discuss the criteria for being supported in greater
detail I think. The current threshold is more or less a result of
Christian, Carlos and me having a chat on IRC about what would be a
sensible percentage for being named "supported", which clearly doesn't
take completeness, quality, linguistic correctness etc into account. So
I think that if we really use "number of supported languages" as a
marketing point we need to define a set of stricter rules to ensure that
we don't ship a lot of translations that were rushed in just to make it
into the list of supported languages.
I haven't really thought about how we could make this happen though
since in most cases the teams themselves are the only ones who can say
something about the quality of the translations :-)
> >> So, what I ask for here: establish a policy that any significant
> >> module (in terms of work for other Gnome subprojects, such as
> >> documentation, UI review, translation, etc.) must guarantee not to
> >> withdraw once final module list is announced.
> >
> > No way. We must have quality control. For instance, Totem+gstreamer
> > wasn't ready so it wasn't in GNOME 2.4, and that' good.
>
> Yeah, and go back to my point you quote: "significant module (in
> terms of work...". You can even add Totem now to Gnome 2.6 and nobody
> would complain that loud: it's a consisted of 333 messages. And now go
> back and read Evolution count: 3900+ (with E-D-S, gtkhtml, gal, close
> to 5k). I want to say that Evolution being in and out is not same as
> doing it with Totem.
>
Do we have any numbers on how many of the strings in the platform and
desktop releases consist of gconf key descriptions? I think it would be
even better if we separated those out and spent the time on strings that
people actually see most of the time. The only reason the gconf key
descriptions are a focus area now is because they end up in the
translation statistics IMO. Would it be possible to do this within the
current framework? I know that some of the gconf keys may well be more
important than others (localisation settings in the panel clock comes to
mind), but most of them are never seen by a normal user.
> In simple words: for such influential modules such as Evolution, be
> more strict and careful when adding it to the core (that was the
> intent of my proposal, not to bind ourselves on unready modules --
> when there's such a penalty, one tends to be more careful about
> choices, I would say).
I agree there is a problem here but I think that sometimes situations
like this come up. Could we really have done this differently? The
Evolution team really thought they would make it when they made the
decision to propose it for inclusion, but now they see that they need
more time. The release team had to rely on what the module team said and
included it based on that feedback.
I can see we need to fix something here, but I'm not sure that the
problem you describe is the right one. :-)
<warning sticker>"Be careful with spending too much time on huge modules
that are new to the desktop as they might get punted before the final
release if they don't meet the deadlines!"</warning sticker>
I'm not trying to make less of the translator issue here, as you know I
do translate this desktop myself and I know how much work is involved in
completing a translation.
Cheers
Kjartan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]