[fab] Correspondence from a wandering board member

[Paul W. Frields]

On Mon, 2006-08-07 at 06:35 -0700, Karsten Wade wrote:
> On Sun, 2006-08-06 at 23:13 -0400, Greg DeKoenigsberg wrote:
> 
> > . gettexts model of having English as the "master" language is a real
> > problem when the translators do not speak English, and shuts out
> > translations for a bunch of native languages where English was not the
> > language of the conquerors/colonists. In this case, the translators know
> > Spanish and Quecha, but not English, so they cannot make sense of the .po
> > file that has English phrases as the keys for the Quecha translations.
> 
> I've been wondering about the Lingua Franca problem, but mainly from a
> perspective of documentation, where the original (source) and target
> languages might have nothing to do with English.
> 
> I wonder if a short-term fix that only addresses the master language
> situation might help.  We could create a Web app in the translator's
> workspace that lets them pick a set of packages and have a POT file
> created from a different language.
> 
> Paul -- do you think this might work?

The concept seems sound to me, with the caveats you mention below:

> It would be very interesting.  We would have to chain the trust for
> editing.  That is, the Quecha team would use the Spanish translation as
> the master, so they would rely upon the quality of the English ->
> Spanish.  The Spanish team would have to be aware that they were now an
> upstream POT-file for another language, and have a process of how to
> respond.
> 
> Theoretically, we could have a trust model so that I know, when I see
> the Quecha translations as "all green", I know that i) the Spanish ->
> Quecha is QA'd and ready, and ii) that only occurs *after* the English
> -> Spanish is QA'd and ready.
> 
> Cascading changes would be a pain.  A typo fix in the original would
> have to trigger a notice to the Spanish and Quecha teams, with the
> latter waiting for the Spanish team to commit a new translation fix
> before proceeding.

Not really any more painful than the current setup, right?  At least,
the only pain is a potential delay, and not a breakage.  This seems to
me like a process that scales pretty well, since it's doubtful the chain
would get too long.


-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
       Fedora Project Board: http://fedoraproject.org/wiki/Board
    Fedora Docs Project:  http://fedoraproject.org/wiki/DocsProject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20060807/49f0a055/attachment.sig>