Re: Using two translation workflows for one module

[Dimitris Glezos <dimitris glezos com>]

On Tue, Feb 23, 2010 at 8:15 PM, Petr Kovar <pmkovar gnome org> wrote:
> [...]
> Moreover, there's no way translators or translation teams on
> Tx.net can communicate with each other, as the Tx.net translation team
> approach is based on a per-project basis. That's quite unfortunate in my
> opinion. Translators and different projects translation teams need to share
> knowledge, guidelines, terminology, best practices, etc.
>
> I hope though that the above can be changed in the future and that Tx.net
> will be more like Damned Lies in this regard.

Yes, this is something that will be supported in the future. It makes
total sense: a software project might want to outsource all its
translation user management to another project.

But I'd classify this as "project X wants to trust project Y for its
translation user management" rather than "collaboration" etc. The
bottom line is that sharing and everything happens on mailing lists,
not the tools themselves (for now). I hope we can reach a point where
the tools will allow a much better collaboration, sharing data,
translation memories, etc.

> but having like
> zillions of different translation teams on one l10n platform isn't aiming to
> accomplish these important goals.

Indeed, but it'd be fair to notice that neither will one translation
team on a zillion L10n platforms.

I'll proceed to give some food for thought, 'cause I've been thinking
about these bits for a few years now, both as a L10n engineer, as a
Fedora Board member, and a project maintainer myself.

The biggest Q we need to ask ourselves here is the following: how much
does GNOME Translation Project want to insist on being considered the
"upstream" for some projects? How is GTP more upstream to Solang than
eg. Freedesktop, Fedora or Ubuntu? How much are we willing to tip the
scale towards "tightly controlled translation quality" against
"cross-project collaboration"?

Relaxing this constraint (We are Upstream. We control things) will
definitely have some short-term effect on quality. It always happens
when you open up things and choose Freedom over Control. You open your
door and invite more people. You get more opinions and contributions.
But consider this: it could have a positive effect on quantity, and,
if we really believe the core open-source mantra of "more eyes = more
easy to catch bugs", it could even IMPROVE quality. Good tools and
circles of trust can maintain quality.

This argument came up with system-config-printer on Fedora.
Considering Fedora the upstream for this project doesn't make any
sense because translators from a bunch of other communities (including
Ubuntu) want to contribute. Insisting too much would lead to a
Cathedral (Subversion-like) translation effort. On the other hand,
pushing the power to the developer himself being the Upstream (no
matter where he's hosted) leads to a Bazaar (Git-like) approach. I'm
the developer of Transifex, right? I'd so much love if the GNOME
translators could contribute to the translations of Tx itself, and the
same for the Fedora and Moblin folks. It'd be a pity if every single
of these communities was putting a requirement for their involvement
the classic "Our way or the high way".

Insisting too much on upstream makes websites like Github (purely
Bazaar) seem like they'll never work. But they do. Amazingly well.

I know I put too much depth here, but I think some perspective on the
topic might do good.

-d


-- 
Dimitris Glezos

Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/