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

List:       kde-i18n-doc
Subject:    Fwd: Re: Tranlsation Website
From:       "Thomas Diehl" <thd () kde ! org>
Date:       2000-11-21 4:29:16
[Download RAW message or body]

==================BEGIN FORWARDED MESSAGE==================
>From: "Thomas Diehl" <thd@kde.org>
>To: "Andreas Pour" <pour@mieterra.com>
>Date: Mon, 20 Nov 2000 20:11:40 +0100
>Subject: Re: Tranlsation Website


Hi Andreas,

Thank you very much for your suggestion which I would like to forward
to the translators list at kde-i18n-doc if you don't mind. Personally,
I'm not sure, however, if I would adopt your model for the German team
(see below). But maybe other team coordinators would. And Stephan Kulow
sounded very positive, too, when I asked him about your proposal.

On Sat, 18 Nov 2000 12:57:29 -0500, Andreas Pour wrote:

>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

Disadvantage is almost the same -- I'm not sure that I would like
"anyone" to translate the programs and wade through lots of
inconsistent stuff afterwards in order to approve or (more likely)
disapprove the suggested translations. For beginning translation teams
it could be great to get rough translations the way you suggest. But if
the translation is somewhat advanced the main work is about consistency
and context checking. This is something that can't be done by anyone in
5 minutes. We are getting the best results if we have maintainers for
certain packages who know what they are doing and a clear system of
proofreading.

>  (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

Again I'm not sure if this is a good thing. For instance, we have 4 or
5 different German words for the simple string "home" (depending on
whether it means "begin of a line" or "home directory" or "home page"
or something else). I sure wouldn't want to have too much "automation" 
in such a difficult area.

>  (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).

Sounds good. But could again bump into the former problem that there is
not just one single translation for a given word. Like I said: most of
the translation procedure is about context (and consistency).

>  (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.

Great. -- But can probably be also achieved in the planned database
features for KBabel. Personally, I would prefer the latter since it is
tailored exactly to our needs.

>Disadvantages:
>   ??

In addition to the above, we would also need an offline solution (like
KBabel). Not everybody can afford to be online all the time.

Thanks again for your suggestion. I really think we should discuss this
in a bigger circle.

Best regards,

Thomas



--- 
KDE translation: http://i18n.kde.org/
Deutsche KDE-Uebersetzung: http://i18n.kde.org/teams/de/























===================END FORWARDED MESSAGE===================

--- 
KDE translation: http://i18n.kde.org/
Deutsche KDE-Uebersetzung: http://i18n.kde.org/teams/de/

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