Fwd: GNOME Moduleset Reorganization vs. L10N

[Kenneth Nielsen <k nielsen81 gmail com>]

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 <sveinki nett is>
Date: 2010/10/12
Subject: Re: GNOME Moduleset Reorganization vs. L10N
To:
Cc: gnome-devel-list gnome org, GNOME i18n list <gnome-i18n gnome org>


Þann þri 12.okt 2010 12:25, skrifaði Kenneth Nielsen:
>
> 2010/10/10 Andre Klapper<ak-47 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-i18n gnome org
http://mail.gnome.org/mailman/listinfo/gnome-i18n