Re: Modulesets Reorganization

[Petr Kovar <pmkovar gnome org>]

Hi all!

Other GNOME translators have already commented on this proposal, but I
thought I'd share some of my views from the i18n/l10n point of view anyway.

Michael Terry <mike mterry name>, Wed, 2 Jun 2010 08:54:49 -0400:

> On 1 June 2010 19:37, Lucas Rocha <lucasr gnome org> wrote:
> > 3. We strongly believe that we should encourage a strong ecosystem of
> > apps around GNOME, and integrating all applications in the GNOME
> > Desktop moduleset is not the best way to achieve this.
> 
> As the maintainer of Déjà Dup, I approve of this move.  I feel Déjà
> Dup is a bit of a poster child for this change.

Please note that the said proposal would very likely affect the l10n
processes for many modules in a rather negative way. In particular, not
providing (or not being required to do so) the translators a possibility
for a sufficiently long string freeze period means that they aren't able and
motivated to work on completing the l10n task before the module release.

So I think, since i18n and l10n have long been core values for the GNOME
Project, that having a clear release schedule and string freeze period
shouldn't be just appreciated & encouraged from GNOME module maintainers,
but simply required in order to ensure that GNOME l10n in a variety of
languages is complete, consistent, and of reasonable quality.

Furthermore, GNOME maintainers should always enable translators from the
GNOME Translation Project (only) to work on module l10n using GTP in-house
infrastructure. Adhering to other l10n projects or infrastructures goes
against the fact that not other l10n project, but the GTP is and has been
responsible for how the GNOME software is localized.

The way how code development works is often confused with how l10n works,
but these processes are different. For a working l10n effort, it's often
quite more important to make use of centralized, normative infrastructure
for a set of software projects that are to be localized with standardized
team work flow, task planning, providing and sharing best practices, incl.
sufficient consistency in translation terminology, style, etc. This all can
be hardly accomplished when you have to deal with zillions of different
l10n platforms, teams, release schedules and so on.

In other words, working on GNOME translations should mean working within
one translation project, with one language team, on one platform.

So as I'm quite concerned over the future of the GNOME l10n efforts, it's my
hope that the reorganization proposal won't be approved in its current form.

Thanks,
Petr Kovar