On 08/19/07 14:57, Klaus Schmidinger wrote:
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().
Apparently it is necessary to do a textdomain("vdr") call after the setenv(). The bindtextdomain() call doesn't have any noticeable effect here.
Please test the attached patch. It scans the LOCDIR directory as before, but checks for the existence of a vdr.mo file and then uses setenv() instead of setlocale().
This should work for VDR itself. For plugins I need to do more work. But first let's see whether others can confirm that this works for VDR.
Klaus