[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    RE: Tranlsation Website
From:       Tinkl_Lukás <Lukas.Tinkl () merlin ! cz>
Date:       2000-11-21 8:14:25
[Download RAW message or body]

OK, I dare comment because I think Andreas is wrong in many points there..

> Hi,
> 
> I'm attaching a mail by Andreas Pour on how he thinks
> we could improve the GUI translation process. I will also
> forward the follow-up mails that came of this so far.
> 
> Please cc all replies to Andreas since he is probably not
> subscribed to this list.
> 
> Regards,
> 
> Thomas
> 
> ==================BEGIN FORWARDED MESSAGE==================
> >Date: Sat, 18 Nov 2000 12:57:29 -0500
> >From: Andreas Pour <pour@mieterra.com>
> >To: Thomas Diehl <thd@kde.org>
> >Subject: Tranlsation Website
> 
> Hi, Thomas,
> 
> I have an idea for improving the translation process and getting more
> people involved.  I outline the idea here, I hate to be brief but I
> don't have very much time today but wanted to get this out there:
> 
>   (1)  script updates daily from CVS and inserts all 
> "original" message
> strings and their translations in a database (HTTP-accessible);
>   (2)  anyone can look up missing translations in the db and enter
> translations;

Imagine what mess would people insert in this public (?) database....

>   (3)  only kde translation team members can "approve" a translation;

Ah, OK

>   (4)  at the end of each day .po files are automatically 
> generated from
> the database and changes are added to CVS.
> 
> Advantages:
>   (1)  anyone can translate strings -- no need to have CVS, 
> other tools,
> kbabel, etc. or to spend a long time -- someone sees a string 
> they don't
> like and in 2 minutes can have a translation made

The problem here is that (at least in our team) every app has its maintainer
who's responsible for the quality of translations and who must verify there
are no mistakes, spelling errors or doubled keyboard accelerators.

>   (2)  no module limitation -- strings are not tranlated on a module
> level but on a global level so changes in translations effect all
> modules, reducing repetition

Completely wrong here (although a nice idea :-). Not every language is as
simple as English, and this has been IMHO discussed here a thousand times
before. 
E.g.: when translating word like "Save": in Slavic languages this turns out
to as many as three different words in different contexts...

>   (3)  authors of other apps can make use of this very 
> easily, since we
> can add a mechanism for an app writer to select all the 
> strings he uses
> in his app and generate the .po files automatically (i.e., helps 3-rd
> party KDE developers make use of the translations that have 
> already been
> done).

See above, you cannot merge *anything* automatically between apps.

>   (4)  many data-mining abilities due to the fact that data is in a
> database.  For example, want to know which programs all use the string
> "Connect"?  Very easy.  Want to see how many translations are missing
> for each message?  Very easy.

That would be useful indeed...

> 
> 
> Disadvantages:
>    ??
> 
> I am willing to set something like this up if there is interest.

Sure -- but let's discuss it here first.

Regards,
Lukas Tinkl [lukas@kde.org]
Czech KDE team

[prev in list] [next in list] [prev in thread] [next in thread]