po-file handling ("language fall-back")

[Heiko Evermann]

Hi everyone,

we have had a lively discussion about partially translated po-files in 
kde-i18n-doc:
http://lists.kde.org/?t=108457162100001&r=1&w=2 (problem)
http://lists.kde.org/?t=108465949100003&r=1&w=2 (proposal for a solution)

A short description of the problem:

1) a user can pick several languages (from the pool of installed 
languages) in kcontrol. He can also sort these languages according to 
his preferences.
2) when an application is started this gets evaluated in this way:
=> iterate over all picked translations
=> pick the first language that has appname.mo translated
=> in i18n(...)-calls use this mo-file to look for translations (ok, it 
is a bit more complicated: kio.mo and kdelibs.mo from the same language 
also get loaded)
=> if the string is not found here, use the English text.

This is a bad approach, when appname.mo is not translated completely, as 
this means that English texts appear, even though the user might not be 
familiar with English. As he might have given his second or even third 
choice of language in kcontrol, a user might expect these gaps to be 
filled with appname.po in his/her second/third choice language. But this 
does not happen. These mo-files will not be loaded at all.

There was some discussion, whether this is a bug that is worth being 
fixed, or whether this might even be the desired behaviour. Some people 
did not care much about it, because they are not affected. Others are 
affected. Some examples:

1) users of Low Saxon (Plattdeutsch), who will usually be familiar with 
German and might want to fill the gaps with German
2) users of Upper Sorbian, who might want to fill the gaps with German, 
Polish or Czech
3) users of Norwegian (they have two different standards: Nynorsk and 
Bookmaal), where filling the gaps with the other standard of Norwegian 
might be interesting.

I have already had a closer look at KLocale and KCatalogue. The basic 
functionality is already there. KLocale keeps a list of KCatalogue 
objects. (The usual case is having appname.mo, kdelibs.mo and kio.mo 
loaded.) When looking for a translation, the first catalogue that has 
the string translated, wins. (The evaluation is in QString 
KLocale::translate_priv).

My idea now is to put the changes into void KLocale::initCatalogue. Here 
we get a catalog as parameter in the form of a string (the catalog 
name). Instead of just looking up the filename in 
KLocale::catalogueFileName (KLocale::initCatalogue) I would like to 
iterate over all languages that the user has chosen, in the order of 
precedence as given by the user (available in KLocale::languageList) and 
load ALL catalogs of appname.mo, regardless of the language. Then the 
usual lookup would find the first translation and return it to the user. 
For users with only one selected language in kcontrol, there would be no 
change at all. All others would benefit from this, and I think the 
performance penalty might not be too high.

One problem that we already discussed is the plural handling, which 
might be different across languages. Currently, KLocale only remembers 
the plural type of the main language (the first that the application 
finds to be installed.) This could be solved by looking up the plural 
type for each catalog file and storing it in KCatalog.

KCatalog can be extended with additional member variables and 
non-virtual accessor methods without breaking binary compatibility, 
because it holds all its data in a private member class   
(KCataloguePrivate * d;) which is hidden to the outside world.

I would really like this problem to be solved. And some other proponents 
of smaller languages with a low percentage of translation done, think 
likewise.

Coolo on the other hand was very reluctant
(http://lists.kde.org/?l=kde-i18n-doc&m=108460936421489&w=2)
and even did not want this bug to appear in a wish list 
(http://lists.kde.org/?l=kde-i18n-doc&m=108461931125643&w=2)

So, how do we go on from here?

1) Would you agree that this is indeed a problem/bug and not the 
intended behaviour of KDE?
2) Would you agree that a change should be accepted when it is programmed?
3) Do you see futher problems with the outlined solution?
4) Would anyone from this list be willing to help program/test the solution?
5) Would this break binary compatibility within KDE3 or could it be 
integrated into KDE 3.3?

I am looking forward to your opinions and remarks.

Kind regards,

Heiko Evermann
(KDE Low Saxon translation team)