[vdr] [ANNOUNCE] VDR developer version 1.5.7

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Sat Aug 18 23:10:56 CEST 2007


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 at euro" string.
>>
>> There must be some way how this is supposed to work. Even if my locale 
>> is set to de_DE at 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 at 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().

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 at euro/LC_MESSAGES/vdr.mo?
This decision clearly would have to be made at install time.

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

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 ;-)

Klaus



More information about the vdr mailing list