Moduleset Reorganization vs. L10N

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

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.

Cheers,

Claude
-- 
www.2xlibre.net