Re: Using two translation workflows for one module


To be clear, I don't think there has ever been an official rule that
modules on have to be translated in damned-lies. This rule
is just there for official GNOME modules.

Nontheless, this has never been a problem because usually modules get
imported in a very early stage without having any translation and people
start translating it naturally with damned-lies (as it appears there
mostly automatically). Or modules get in because they become official
part of GNOME (see above).

Now, to my point: If we start as GNOME Translation Project to allow any
of the modules to be translated elsewhere we will end up
in a mess of different translation platform with makes it very difficult
to keep good quality up!

> The reason I personally like (not just any instance of
> Tx) is that it provides a common platform for developers and
> translators to meet. Not every program is a GNOME program (whatever
> that means). So it is difficult for those programs to leverage the
> quality of Translators just need to sign up to
> and from there on they can contribute to almost any
> project for which they have been authorized (either by the language
> team or the developer of the project). Right now can not push
> to because Tx does not have an account, but that is
> different thing.

As a note, developers shouldn't ever decide on translation or who
submits a good translation. They just don't know (even for their mother
tongue) what the goals and rules of the local translation team are. So,
this is the first problem in this concept.

And as a last note: We do your care about the translation platform as
developer at all? It shouldn't be your job.


Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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