GNOME.org
 

Re: GNOME Moduleset Reorganization vs. L10N

Þ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.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]