[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:30:16
[Download RAW message or body]

==================BEGIN FORWARDED MESSAGE==================
>Date: Mon, 20 Nov 2000 17:02:43 -0500
>From: Andreas Pour <pour@mieterra.com>
>To: Thomas Diehl <thd@kde.org>
>Subject: Re: Tranlsation Website

Thomas Diehl wrote:
> 
> 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.

Of course any normal user posts would be "advisory" and would have to be
approved by one of the people with current CVS access (as you know
kde.com already has accounts built in so this would be easy to enforce).

As for being overwhelmed, I think that is a concern waiting for a
problem.  I don't think people will make too many translations, and if
it happens, one can deal with it then (e.g., requiring people to have an
account to make a suggestion and disabling suggestions from abusive
accounts -- or a language team head could filter suggestions by poster
or delete by poster).  There are ways of dealing with this problem if in
fact (which I highly doubt) it materializes.

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

Yes, I agree, and perhaps I forgot to mention that anyone but team heads
can only make suggestions.  Team heads can then look at the suggestions
and either approve, decline or edit the user request.  This system is
currently set up for user suggestions at apps.kde.com, and it works
quite well.  I find I am not at all overwhelmed by "spurious" user
suggestions -- in fact I wish I got more :-).

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

The system could easily be set up to permit a "modules" field to qualify
a string, and this string be associated with different modules.  So e.g.
"home" in Konqueror could be set to something different from "home"
somewhere else.  Of course the system is fully programmable so any kinds
of special cases can be taken into account.  But the advantage is that
in the great majority of cases there is no such "special" meaning and
the work of the translators is simplified.


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

Of course, but my judgment would be that having the possibility that
some contexts are wrong (e.g., home meaning directory instead of page)
is far less of a problem than not having any translations at all.  As I
deal a lot with 3rd party apps, I can assure you that most have *no*
translations, not even for the standard stuff like "File", "Open",
"Close", etc.  If there are special case words it would be fairly
straightforward to associate an "explanation" with a word, and the 3rd
party developer will be presented with the options and asked to choose
which one to use.

Again, the nice point is that we use php and this is fully
programmable.  I am willing to take the time to make a solid system
since this is important to get KDE international acceptance.

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

Whatever can be done in C++ (kbabel) can be done in php (website).  The
php can be tailored exactly to your needs as well.  I am not proposing
using a closed-source program -- this is something I would write and you
could obviously (and it would be nice :-) help.  If you don't know php,
but know c++, you will have no problems -- all the "overhead" stuff like
authentication and database access I have already programmed and is in
use.

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

Absolutely.  That is why I said the site would update from CVS every
night, that way it pulls in work done through CVS and CVS remains the
"primary" repository of all translations.  The web interface would be
just one way to contribute to CVS.

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

Please feel free to forward my initial mail, as well as this one, to the
kde-i18n mailing list.

Ciao,

Andreas Pour

http://www.kde.com/ :  Everything KDE
http://apps.kde.com/:  The Latest in KDE Applications


===================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]