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 _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n