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
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
