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

List:       kde-i18n-doc
Subject:    Re: Language fall-back: proposal for a solution
From:       Heiko Evermann <Heiko.Evermann () gmx ! de>
Date:       2004-05-16 16:24:40
Message-ID: 40A795C8.3070006 () gmx ! de
[Download RAW message or body]

Hi Nicolas,

>I have the idea of using a catalogue list per language instead of a central 
>catalogue list.
>
Well, we already have a catalog list in KLocale. The question is how to 
fill the list.

>
>This is a few advantages:
>- you can search a translation language per language, so you always know which 
>language is currently used and you can apply special treatements specific to 
>that language (for example plurals.)
>
I did not quite understand that. What do You mean?
I think we should only have one language list in kcontrol and just 
evaulate that list.

>- it tries harder to find a string (for example a string would be in an 
>application and in kdelibs, translated fully in German but only in kdelibs 
>for Low Saxon, having one common catalogue list would return the German 
>translation, with a separate list, it would be the Low Saxon one.)
>
application.po should have precedence over kdelibs even across languages.
Your approach seems to propose that we should search all nds files 
first. I think this is not neccessary. If a string is in appname.po and 
in kdelibs.po and if nds does not translate it, I would not mind having 
the de translation. The whole approach has only one main purpose: to 
fill in the gaps that we currently have, so that non-English people can 
see non-English translations in the gaps of their favorite language.

>- a language is searched completely before trying the next one. This 
>especially keep time low for well translated languages, as most of the time 
>you would need to search in only one language.
>
In well-translated languages the whole problem does not exist. In that 
case it would not even make sense to pick more than one language in 
kcontrol. Remember: there the user does not pick which languages to 
install, but only which ones to display. In a well-translated language 
the second choice will not have any effect, as you always get strings in 
your favorite language.
Another reason why speed should not be the problem is that usually 
strings get looked up in dialog initialization etc. that is in 
interactive parts of the program. I think it would still be quick 
enough. It does not disturb a well-written program in computation 
intensive parts. In that case a program would not use i18n() inside a 
loop. e.g. kstars translates quite a lot of data, but it caches the 
translations anyway.

A valid point from one of your mails is handling of plural forms. I will 
have to look a bit closer at the code.

Kind regards,

Heiko Evermann

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