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 "[EMAIL PROTECTED]" string. >> >> There must be some way how this is supposed to work. Even if my locale >> is set to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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/[EMAIL PROTECTED]/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 _______________________________________________ vdr mailing list firstname.lastname@example.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr