Re: Moduleset Reorganization vs. L10N

[Kenneth Nielsen <k nielsen81 gmail com>]

2010/10/12 Claude Paroz <claude 2xlibre net>:
> Sorry, I was away for some days and wasn't able to give my opinion
> sooner.
>
> First of all, I'd like to support that using the GNOME infrastructure is
> invaluable for translators. It is not rare for us to commit in modules,
> (POTFILES.in, translator comments, other i18n fixes...) and having only
> one bugzilla to cope with is also very nice. We should continue to
> encourage developers to use it, but I wonder how we could do this
> concretely...
>
> Returning to basics, I think that to be a "GNOME-blessed" module at
> i18n level, the criteria should be that the module is translated through
> established GNOME translation teams, regardless the tool used. It's not
> that GNOME teams are the best one, but as others have recently reminded
> us, it's a matter of consistency and QA. I hope that the
> release team support this view.
>
> Another important point for me is that for any module, only one
> translation workflow is chosen. That means that different modules might
> choose different workflows, even if I consider this suboptimal at a
> team-management level. I can elaborate on this if needed.
>
> Now that leaves us with essentially two ways forward:
>
> a) each module can choose its preferred tool/workflow and the module
> owner has to assure that 'commit-like' access is reserved to GNOME teams
> coordinators. A variant of this would be that a subset of tools are
> blessed by the GTP, to prevent tool proliferation, which would become
> unmanageable by coordinators.
> + free choice for maintainers
> + does not require any change to current translation tools
> - duplicated team management
> - multiple workflows to be familiar with
> - hard to detect string freezes
>
> b) we enforce a GNOME stats/translation tool, and we make the necessary
> steps so as it supports distributed development. For example, that could
> mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where
> translations are committed by GNOME teams, and the modules have to merge
> regularly this branch into main repositories (at least before each
> release).
> ++ single location for translators
> - enforcing a special workflow for maintainers
> - risk that maintainers omit to merge i18n branch
>
> My preference is for b) as it is easier for translators: only one
> workflow has to be handled.

Mine too. If we can get developers to agree and we can agree that it
is a fair demand then that is definitely the way we want to go.

> IMHO, the question about the GNOME main translation stats tool
> (Damned-Lies or Transifex or whatnot) is secondary, and should be
> addressed after we've defined where we want to go.

Agreed.

\Kenneth