po-file handling ("language fall-back")
Heiko.Evermann at gmx.de
Mon May 17 23:25:27 BST 2004
we have had a lively discussion about partially translated po-files in
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
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
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
Coolo on the other hand was very reluctant
and even did not want this bug to appear in a wish list
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.
(KDE Low Saxon translation team)
More information about the kde-core-devel