[vdr] [ANNOUNCE] VDR developer version 1.5.7

Klaus Schmidinger 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 
>>> 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

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...
Name: vdr-1.5.7-i18nsetenv.diff
Type: text/x-patch
Size: 1704 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20070819/1f2ef7ed/attachment-0001.bin 

More information about the vdr mailing list