On 08/19/07 12:43, Anssi Hannula wrote:
Anssi Hannula wrote:
Luca Olivetti wrote:
En/na Anssi Hannula ha escrit:
Note that KDE does provide the user a list of languages, but it does not use gettext, but instead uses its own glibc-derived implementation for translation, with file format being the same.
[...]
Isn't there perhaps a way to tell gettext *explicitly* which files to use, completely bypassing this whole broken setlocale stuff? In that case VDR could collect it's list of *.mo files and decide by itself which one to use.
I'm not aware of such a way.
I think that in your message there's the solution: do *not* use gettext but use an own implementation. Maybe borrowing kde implementation (which is already C++) it's easier than translating the pascal class I proposed before (or maybe not ;-).
Actually, it seems KDE 4 uses real gettext to do it, and uses the following code:
// Point Gettext to new language. setenv("LANGUAGE", language, 1); // Locale directories may differ for different languages of same
catalog. bindtextdomain(name, localeDir);
Maybe just using 'setenv("LANGUAGE", "de", 1);' will do what we want, without need for setlocale()? :)
I have to go now so I can't check that yet.
I tested anyway ;)
It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi will work even if there is no such locale at all.
I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which certainly is not a valid locale, and using LANGUAGE=testtest it was correctly used! :)
Looks good. However, after some tests it would appear as if only the very first setenv() call actually changes anything. Subsequent calls have no further effect, and gettext() always returns the language that was selected in the very first call to setenv().
Klaus