[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-15 22:15:36
Message-ID: 40A69688.7060403 () gmx ! de
[Download RAW message or body]

Hi Nicolas

>>Well, at the moment a KDE application already loads 3 catalogs:
>>* appname.po
>>* kdelibs.po
>>* kio.po
>>    
>>
>
>No, you seem to have misunderstood me.
>
>You load neither 2 appname.po, nor 2 kdelibs.po nor 2 kio.po
>
OK, let's go into the details (sorry for mixing up po-files and mo-files)
KLocale::initCatalogue
loads kdelibs.mo and kio.mo with these two lines
<code>
  // always include kdelibs's mo files
  d->catalogues.append( KCatalogue( SYSTEM_MESSAGES ) );
  d->catalogues.append( KCatalogue( "kio" ) );
</code>

So internally the KLocale-object holds more than one mo-file. It always 
holds appname.mo, kdelibs.mo and kio.mo. When starting to translate 
programs, I quickly found out that not all messages are in appname.mo. I 
then searched through the po-files, where the msgstrs were and learned 
about kdelibs.mo and kio.mo.

A program can even add more catalogues via 
KLocale::insertCatalogue(...), and quite a number of programs do that.

So we have: you load appname.po, kdelibs.po and kio.po.

Internally a nice method called KLocale::catalogueFileName is used to 
search for the mo-file in question with
<code>
  QString path = QString::fromLatin1("%1/LC_MESSAGES/%2.mo")
    .arg( language )
    .arg( catalog.name() );
</code>

This method is called with the standard language, that can be reached 
via the "language()"-function. But KLocale also knows about a list of 
languages that the user knows about in the variable
"  QStringList languageList;".

What I want to do is change the implemenation of 
KLocale::insertCatalogue. Instead of only instantiating one 
KCatalog-object with the default language, I want to instantiate one 
KCatalog-object for every language in the language list, in the order of 
preference given by the user. This would load files where %1 in
("%1/LC_MESSAGES/%2.mo") is filled with nds, de, ... (iterate through 
all languages), so that all the mo-files for the selected languages get 
loaded. (This would not be all 70+ translations, but only those that the 
user selected in kcontrol.)

Let's have a look at the evaluation: How is a string actually translated:

i18n( string) is a global function defined in KLocale as a call to 
KLocale::translate(), which in turn calls KLocale::translate_priv(...)

Here we iterate through all loaded message catalogs and leave with the 
first translation that we find. So appname.mo can overrule kdelibs.po, 
if the same string is found in both. My idea is that if we have 
different appname.mo-files loaded for all languages that the user cares 
about, we would return the translation from the first language that 
translates the string, which would be exactly what I would like to see. 
And I do not seem to be the only one. Eduard Werner (Upper Sorbian) is 
having the same problem: partially translated files and users who are 
not neccessarily fluent in English.

So far I have not coded and tried this, but I would like to. Unless, of 
course, Coolo would explicitly say that we will not have this in KDE, so 
that I would not be able to check this in. Then I would save the effort 
for something else.

I think that the approach described here has good potential to work, so 
we should give it a try. Of course only in head and not in the KDE 
3.2-branch. But I would really like to see this problem solved.

Opinions?

Kind regards,

Heiko Evermann
(Low Saxon translation team)

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