Re: [ANNOUNCE] VDR developer version 1.5.7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Klaus Schmidinger wrote:
> On 08/18/07 21:46, Anssi Hannula wrote:
>> Udo Richter wrote:
>>> Klaus Schmidinger wrote:
>>>> On 08/18/07 12:29, Udo Richter wrote:
>>>>> To add another report, I had some trouble to pick anything but English 
>>>>> at first. After some fiddling and trying the various hints, here's what 
>>>>> was missing for me:
>>>>>
>>>>>  [...]
>>>>>
>>>>> ... and now it works. Is there a way to make VDR less picky about what 
>>>>> de_DE language variant is installed?
>>>> Are you sure it's VDR who is picky? Isn't setlocale a little "dumb" here?
>>> In the end, this isn't really important. What matters is that you have 
>>> to explain lots of users that they need to reconfigure their OS language 
>>> from german to german in order to pick german as language manually 
>>> inside VDR.
>>>
>>>> Please try the patch I have posted yesterday under "improving i18n-to-gettext.pl"
>>>> (vdr-1.5.7-i18n-matchlocale.diff)?
>>> Seems to make no difference. Probably because setlocale only accepts the 
>>> full "de_DE@euro" string.
>>>
>>> There must be some way how this is supposed to work. Even if my locale 
>>> is set to de_DE@euro and there's no pure de_DE in locale -a, almost all 
>>> distribution' locales are in /usr/share/locale/de/, and they work. There 
>>> must be some mapping from de_DE@euro down to de_DE and de.
>> Yes, but the other applications are not listing locales nor using 
>> setlocale to change locale to those during runtime, which is the problem 
>> here. If there was another app that does it, it could be interesting to 
>> see how it manages that. I don't know other way than to use the "locale 
>> -a" way, i.e. traverse /usr/share/locale and parse locale.alias.
> 
> Maybe I should have stayed with the old tI18nPhrase method. At least
> that worked everywhere out of the box...
> 
> VDR's locale files are named like "de_DE" (language_COUNTRY).
> There's no "@euro" or other stuff added to the names. VDR needs to
> know which files it actually has at its disposal, in order to
> present to the user a list of all available languages. It makes
> no sense to present a language that in the end isn't available.
> 
> Copying the *.mo files into /usr/share/locale/... could be done.
> VDR would then have to loop through all directories in /usr/share/locale
> and test each one for the presence of a "vdr.mo" file, as in
> 
> /usr/share/locale/de/LC_MESSAGES/vdr.mo
> 
> and use the directory name it finds ("de" in this case) as the value
> in its call to setlocale().

Unfortunately the "de" might not be a valid locale for setlocale(), as 
in Udo's case; only de_DE@euro and de_DE.iso885915@euro are, even if the 
files from /de/ are used. I think the valid locales can be identified by 
having a LC_IDENTIFICATION file in the locale directory, containing the 
locale identification data (printed by "locale -a -v"), or if they are 
contained in /usr/share/locale.alias.

Note that apparently Matthias Schwarzott's system (other thread) has the 
LC_IDENTIFICATION file in /usr/lib/locale instead of /usr/share/locale.

> The only problem I see is: how to find out what directories to copy
> VDR's *.mo files into? For example, VDR's German text file is named
> "./locale/de_DE/LC_MESSAGES/vdr.mo", but should it go into
> /usr/share/locale/de_DE/LC_MESSAGES/vdr.mo or
> /usr/share/locale/de/LC_MESSAGES/vdr.mo or even
> /usr/share/locale/de_DE@euro/LC_MESSAGES/vdr.mo?
> This decision clearly would have to be made at install time.

/de/, as with other programs. If there will be additional 
territory-specific de translations of VDR, they will go to de_XX. The 
translations from /de/ are always used when locale is 
de[_territory][.codeset][@modifier].

> And if all programs must have their texts in /usr/share/locale/..., why
> is there even a bindtextdomain() function?

So that the locales can be installed into another directory/prefix, like 
inside the source tree.

> So, to sum things up: I might go along with copying VDR's *.mo files
> into /usr/share/locale/... (and prefix the plugin files with "vdr-" or
> something alike), if somebody can come up with a Makefile "install-i18n" target
> that copies VDR's files from $(LOCALEDIR) to the proper places under
> /usr/share/locale/...
 >
> Oh, and of course the whole thing must still work locally in ./locale ;-)

Well, changing the locale directory does not really change this issue at 
all.

I guess the easiest and most compatible thing to do now would be to 
traverse /usr/share/locale dir and if $LOCDIR/xx/LC_MESSAGES/vdr.mo 
exists, try the names of all existing /usr/share/locale/xx*/ directories 
as parameter for setlocale(). ($LOCDIR being the VDR localedir, be that 
/usr/share/locale, /usr/share/vdr/locale, /home/anssi/vdr-1.5.7/locale, 
or whatever).

-- 
Anssi Hannula

_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux