>Yes, but, as far as I understand, the I18N code can only load one language 
>catalogue of the same type (for example koffice.po). So back to American 
>English is possible (as it serves as index) but it is not possible to use 
>another language, which would need 2 language catalogues at the same time or 
>a slow on-the-fly procedure: unloading the old translation catalogue, loading 
>the new one, translating the string, unloading the new catalogue, reloading 
>the old one.
>
Well, at the moment a KDE application already loads 3 catalogs:
* appname.po
* kdelibs.po
* kio.po
When a string needs to be resolved, the first one wins. If the string is 
found in appname.po, it is taken. If not, kdelibs.po is queried. If it 
is there, it is taken. If not, kio.po is queried. If it is not there 
either, English is taken.

Would it be so difficult to look in
* nds/appname.po
* de/appname.po
* nds/kdelibs.po
* de/kdelibs.po
* nds/kio.po
* de/kio.po
and this if and only if the user has decided to pick more than one 
language in kcontrol. Users who only pick "de" would be completely 
unaffected.

I think I will have a closer look at the code. I guess, it would be 
pretty simple to code. The main question is whether or not we as a team 
would agree to such a change.

Again: someone with only one language chosen in kcontrol would not be 
affected. For all the others it would be a great benefit.
Just to to http://i18n.kde.org/stats/gui/HEAD/toplist.php (sorted by 
completeness), and have a look at languages below 40.000 translated 
strings. Klick through to the individual files and you will see a lot of 
incomplete po-files. Then remember that in all those gaps English gets 
displayed, because the po-file is started and it is incomplete. Is that 
really what we want?

Kind regards,

Heiko