Re: Stricter policy when including BIG modules

[Danilo Segan <danilo gnome org>]

Kjartan Maraas <kmaraas broadpark no> writes:
>
> 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. 

Indeed, but I'm not talking of statistics, I'm talking about
organizing work.  It seems most of you have missed that Evolution is
delayed until June, which means that this is exactly the case where
translators could have focused on getting higher quality translations
in other components, instead of working on Evolution.

Also, it's not very relevant if it's 80%, 90%, 100% or whatever:
those are simply randomly chosen milestones, and having a preset
milestone is often very important (that's what 6 month cycle is all
about, right? it could have been 7 months or 5 months, and it wouldn't
present any big difference).

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

Let me quote JP Rosevear here:
> Evolution Data Server 1.0 ships with GNOME 2.6 and Evolution 2.0 Ships
> in June.

This means that no, Evolution 2.0 will not be included there if the
deadline is early March.  Unless, of course, they ship from 1.5
series as well (I don't know Fedora policy for including unstable
software).

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

Yeah, but that's entirely different problem.  Here the problem is 
misguiding translators into doing something which could have waited.
And it consumes LOT of translators' time, so all the criteria you
mention (completeness, quality, linguistic correctness, etc) would be
better satisfied if this didn't happen.

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

Well, that's why it's essential to let them have as much time as
possible.  And in this concrete case, time was taken away from them.

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

Yeah, that would probably be a good approach to the problem, but it's
much more work, and doesn't have such immediate effect.  Actually, it
seems to me that this would require major architectural changes to
the statistics pages (i.e. process PO files, and disregard those
messages for which source reference points only at *.schema* files;
of course, we should keep another place where these would be shown).

Also, gconf key descriptions are translated because they end up in
the same PO file as well (apart from them being in the statistics
pages).  Even if you decide to skip them, when something changes,
you're unable to track if it affects the GConf key messages, or other
UI messages -- you'd have to go through all of them.  So in a way,
it's currently easier to translate them all, because you can track
the UI better.

Yet, this is not directly related to the issue here: by spending more
time on new/big modules (even if we remove the gconf key
descriptions, it would only mean constant scaling of work needed, but
the ratios would stay the same [i.e. Evolution would still be 20% of
the desktop]), you lose the time you could have spent on other stuff.

> I can see we need to fix something here, but I'm not sure that the
> problem you describe is the right one. :-)

Well, with your input, it seems there's a lot more to fix than just
one problem :).

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

That's not bad, but it's a chicken and egg problem: if you don't start
working on such huge modules, it probably means that you won't be
able to translate them in time.  So, you're in a way obliged to start
translating it, or you risk having a component completely untranslated.

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

Yes, of course, but the policy I mentioned would have so far never
excluded any module, except Evolution in 2.6 release cycle.  So I
don't think that it's too strict, and it won't have any negative
impact on the release process.  Surely, come 2.8 time, Evolution 2.2
will be more than ready, and there won't be any doubt.

So here it seems that Evolution was rushed into Gnome, and the
criteria I give is pretty objective one which might help solve one
particular problem.  I didn't claim for it to solve anything but it.

And the time between the final module list announcement and string
freeze time is 1 month.  I'm talking about applying this policy at
that time.  It meant that Evolution would be a candidate all the way
up to the decision, and only then it would be withdrawn because
nobody was certain that it would make it.

Cheers,
Danilo