Hi Sveinn I made the mistake of sending it to the gnome-devel-list instead of as it should have been, the desktop-devel-list, so I'll forward your email.
---------- Forwarded message ---------- From: Sveinn í Felli <svei...@nett.is> Date: 2010/10/12 Subject: Re: GNOME Moduleset Reorganization vs. L10N To: Cc: gnome-devel-l...@gnome.org, GNOME i18n list <gnome-i...@gnome.org> Þann þri 12.okt 2010 12:25, skrifaði Kenneth Nielsen: > > 2010/10/10 Andre Klapper<ak...@gmx.net>: >> >> Hi, >> >> in >> http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00060.html >> the release-team announced its proposal for a reorganisation of the >> current modulesets. >> >> As the release-team aims at a more decentralized approach for modules >> that are not part of the GNOME core there are open questions with regard >> to translation workflows. >> >> It would be very welcome to have some discussion about the future role >> of l10n.gnome.org with regard to translatable modules NOT hosting code >> on git.gnome.org and/or prefering different infrastructure (e.g. >> Transifex or Launchpad), and what this means for workflows of >> translators and integration with l10n.gnome.org. >> >> Anybody up? > > Definitely! > >> Worst case would be a decision without much/enough input >> from L10N and bad blood afterwards, and that's something to avoid. > > Absolutely, let get some discussion going. In my optics the purposes > we have to keep in mind are: > > 1) Control. We have to have control over the translations, to make > sure that uninformed volunteers don't mess up the quality with > grammatical errors of inconsistencies. > 2) Easy access to work. It has to be easy for translators to get their > hands on the po-files > 3) Implementable workflow. It has to be possible and easy to implement > a good translation-proofreading-(discussion)-integration workflow. > 4) Integration of translations up-stream. Should be automatic. > > The most visible available options are: > > A) Translation-only repository copy in git.gnome. > B) Launchpad > C) Transifex > > Evaluating how they measure up to our feature requests, it is probably > easiest to start with number 2. Any of these solutions allow easy > access to translations in them selves. So the main concern is how much > we can allow them to become scattered. Using only (A) would results in > a status quo in the view of translators. Considering also using (B) or > (C), or possibly both, it should be possible to implement a solutions > with links in damned lies, thus in effect still maintaining the > illusion of a one-point-access to GNOME translations. > > Now lets look at control (which is absolutely priority alpha). (A) is > status quo so fine. Launchpad and Transifex (B and C) are a little > more difficult. Per default they will allow anyone access to the > translations, which is no good. However, as far as i understand it > should be possible to implement the kind of control that we would like > to have on both platforms, though the implementation would differ for > the two platforms. > Launchpad makes it possible to restrict access to module translations > to a particular group of people (say gnome-translators, which can then > again be partitioned into language groups). So then the only thing we > would have to do, is to make a gnome-translators group and require > module authors to restrict access to this group. > In Transifex you would make a metaproject, containing all the modules > that we want control over and then make language specific translations > groups for the metaproject. > Both of these solutions are _possible_ but do require extra > administrative work, so implementing this we probably want to do this > for (ideally none, but realistically) only one external tool and > absolutely no more than two. > > Implementable workflow (3). (A) again is status quo, not much to say > about that. Transifex (C) (afaik*) workflow revolves around > downloading po-files and working with those. So this means that we can > work with that in the same way we do now (same translation tools, same > e-mail-lists for proofreading and so on). Launchpad (B) is a bit more > of a ticklish subject. Launchpad also allows for downloading po-files > which result in the same features as above. But the "main" workflow > revolves around a web-interface which has some special > characteristics, you have a large translation memory which is a > benefit, you also have proofreading functionality but now in another > workflow than usual and one that does not allow for direct feedback to > contributors. Feedback functionality in the webinterface is planned > though. > > Finally integration upstream. This only ever becomes a problem if we > translate stuff in a place that is not the projects primary source of > translations. Since in both (A), (B) and (C) they _would_ be the > primary source of translations this is not a problem. > > So what do you think. There are several open questions above. How many > if any external tools. Which ones. How well can they be used etc. > Please chime in. > > Regards Kenneth > > * My knowledge of Transifex is limited I use most of the translation interfaces regularly (Gnome D-L is the only one with real problems pushing translations). I'm even a bit fond of the translationproject robot ;-) Please use Transifex rather than Launchpad. If set up like for Fedora it's quite productive and without a steep learning curve. Can be heavily moderated, with file-locks and other stuff. Don't know if lang-group coordinators can prioritize certain translations, but then such matters can be discussed on mailinglists. Web-translation can be enabled or not for individual files. LP is getting better, but it's a pain searching for a particular phrase or downloading all po/pots for a certain language. Not mature. Don't forget the KDE-way; great stats, not tremendously difficult to set up svn+ssh. But then, KDE is probably going the git-way soon. Just some thoughts, Sveinn í Felli > >> I guess it is prefered to respond to the thread on desktop-devel-list >> mailing list and CC gnome-i18n@ to not have two separate threads on the >> same topic and to create better understanding/awareness on both sides >> (developers and translators) for issues. > > Done. _______________________________________________ gnome-i18n mailing list gnome-i...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list