[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
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
-------------- 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