[vdr] [ANNOUNCE] VDR developer version 1.5.7
Klaus.Schmidinger at cadsoft.de
Sun Aug 19 15:41:44 CEST 2007
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
>>> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1704 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20070819/1f2ef7ed/attachment-0001.bin
More information about the vdr