2010/10/12 Kenneth Nielsen <k.nielse...@gmail.com>: 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 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. Regards Kenneth > Thanks, > andre _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list