Re: GNOME Advisory Board Member Interviews

[Vincent Untz <vuntz gnome org>]

Hi,

Le jeudi 13 août 2009, à 20:47 +0200, Claude Paroz a écrit :
> Le mercredi 12 août 2009 à 22:19 -0600, Stormy Peters a écrit :
> <snip>
> > Collaboration among advisory board members: Now that we have a sys
> > admin team in place would like to find ways that we can collaborate
> > better. Mentioned an article by J5 that talked about that RH, Novell
> > and others are less involved because of the maintenance burden.They
> > spend time on money on things like translations. No process to get
> > them upstream and so they do it all over again next year.
> > 
> > Ideas for collaborating between advisory board members:
> > 1. Translations.
> <snip>
> 
> Hi Stormy,
> Thanks for this interesting report. I was a little surprised by the part
> about translation. Where are those translators ? Our i18n process is
> completely open, so I don't understand why they do not contribute
> upstream in the first place.
> Would be great to have more details about this issue.

I guess it's a bit similar to what happened in the past, with the Sun
documentation team working on GNOME docs, but always a few cycles late
compared to upstream. So it was really hard to make this work useful for
upstream.

Based on what I know (ie, what is done for Novell), the issue is
not really with the i18n process we have upstream. Let me give an
example based on SLED 11. I would guess it's the same for other
downstreams. First, here's some background:

 + SLED 11 was released at the end of March 2009, and is using GNOME
   2.24.x (mostly 2.24.1, I believe). For reference, GNOME 2.24.0 was
   released in September 2008, 2.24.1 was released in October, etc.

 + I would guess there's a goal to have SLED 11 correctly translated in
   various languages (let's say 20, but it's a random number).

 + it probably happens that for SLED 11 SP1, or for some later date, new
   languages must be supported. AFAIK, this would still be for GNOME
   2.24.

 + translations are about the UI and the documentation. From an UI point
   of view, it's mostly some GNOME upstream modules (sometimes with
   strings coming from patches), and some distribution-specific tools.
   Same for documentation, I guess.

 + Novell needs to get translators to work on the distribution-specific
   tools anyway. And sometimes, the upstream translation for GNOME is
   not complete with big visible holes, so the translators also make
   sure the desktop is translated.

Now, there are several issues in the process that is being used when it
comes to GNOME:

 + this downstream translation work is made too late for upstream to be
   useful for the branch. Here, a translation of 2.24 that is made
   available in March 2009 has no use for the 2.24 branch.
   (but yes, it can still be useful for 2.26 in case upstream didn't
    move)

 + some work that is being done is obviously duplicating work that has
   been done upstream. Eg, a string not translated in 2.24 could be
   translated in 2.26. This is not a problem for upstream, but this
   costs time and/or money for downstream.
   (there are technical solutions to minimize this, though)

 + the people doing this translation work are not community people. They
   do not know how to work with the community, and it's unclear whether
   it's possible to directly "force" them to do that.
   (possible solution: indirectly force them, via the tools that are
    used)

 + pushing all those translations upstream is hard. You might remember
   some big mistake in the past where downstream gnome-main-menu
   translations were committed. This is obviously wrong. The
   translations have to be made available to upstream in an easy way, so
   that upstream can take what's useful in them. But they shouldn't be
   forced, for sure.

So for GNOME, the most interesting thing is probably the last item since
we have no control on what branch downstream will use, and on who will
translate stuff downstream. But asking downstream to provide what
can help us improve our translations upstream is (I think) a reasonable
request. But it has to be provided in a useful way, I guess.

Coming back to the original comment from the advisory board, I would
think that what would be useful is to know how distributors can make
sure that the late work that is being done downstream can be made
available to upstream in an easy & usable way, so that what's
interesting is taken upstream (which means that this is work that won't
need to be done again downstream in the future). And unfortunately, just
saying "downstream translators should just push their changes upstream"
is not a good answer (see above: it might not always be possible to make
those translators work upstream).

In more concrete words, we could just make downstream po files available
to upstream, but I doubt this would be useful as is. IMHO, what is
really needed is providing translations for strings that are still not
translated in the current stable/development branches, and showing the
changes that have been done if strings were already translated. And all
this in a way that is convenient for upstream.

(fwiw, inside Novell, we're trying to find solutions to all this, and we
do have ideas, but it takes time to fix things; a bit frustrating, if
you ask me ;-))

I hope that this helps understand the issue a bit. And sorry for the
long mail :-)

Vincent

-- 
Les gens heureux ne sont pas pressés.