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 <m...@mterry.name>, Wed, 2 Jun 2010 08:54:49 -0400: > On 1 June 2010 19:37, Lucas Rocha <luc...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list