Re: Moduleset Reorganization -- Take two



Le jeudi 07 octobre 2010 à 08:30 -0400, Michael Terry a écrit :
> On 7 October 2010 07:57, Johannes Schmid <jhs jsschmid de> wrote:
> > What about Launchpad? I think if we want to integrate which other hosting
> > possibilities we definitely need a working i18n-solution with Transiflex
> > and Launchpad before accepting applications from there. Probably something
> > the sysadmin-team and the i18n-team should focus on in this cycle.
> 
> For Launchpad applications (such as mine, Deja Dup), I proposed three
> ways we could smooth the way for GNOME/LP interaction last time this
> came up:
> 
> 1) Having an approved GNOME coding team (~gnome-team?) that the
> maintainer sets to own the trunk.  This way, documenters and
> GNOME-approved coders can directly commit.  It would be best if being
> added to that team was automatic.  Then have some documentation that
> says, "for this app, here is the trunk".
> 
> 2) Having the maintainer set the approved translation team to
> '~gnome-translation-project' and having some documentation for
> translators that this particular app lives in launchpad.  With
> Launchpad Translations, they wouldn't need direct access to trunk, but
> it wouldn't hurt if they chose to edit directly instead of the web
> interface.  Existing translation teams should be encouraged to join
> that team (or automatically added), as it seems a little sparse right
> now: https://translations.launchpad.net/+groups/gnome-translation-project
> 
> 3) For the documentation team, a similar situation.  Again, this would
> need some documentation that says, 'for this app, edit docs in this
> trunk'.  Then they could directly commit.
I can't really speak for translators, as I only contributed a few
strings in GNOME (but I also translate software in Ubuntu, so I know
Launchpad too). But I think we're going to open Pandora's box if we
allow applications to be translated using different systems. There will
be the « core applications », that are hosted on git.gnome.org and get
good quality translations as now, and other peripheral applications that
will quite possibly get less attention because tracking their status and
learning their translation systems will be a pain.

The best solution IMHO would be to import PO files for all applications,
and integrate them into Damned Lies. Else, we're taking the risk of
losing consistency, and « moduleset » won't mean anything in the end.

Of course, I'd like to hear what « real » translators think of this
change.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]