On 08/19/07 10:46, Anssi Hannula wrote:
> Udo Richter wrote:
>> Klaus Schmidinger wrote:
>>> 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.
>> I guess the working way would be to parse (or build) the list of locale 
>> -a, as they are definitely the present locales, and then check which one 
>> of them matches a VDR translation file. In my case, [EMAIL PROTECTED] uses 
>> the 
>> existing translation de_DE as fallback, and would be a valid selection.
>> Such a solution still has obstacles, like multiple possible locales for 
>> one real translation, and things like 'C' locale for English.
> Well, AFAIK it doesn't matter which one of the multiple possible locales 
> you select, it won't affect the translation, so this is not a problem :)
> And for the C locale, I don't see the problem. Actually, 
> I18N_DEFAULT_LOCALE should be "C", as "en_US" is invalid in many 
> systems. Dunno if "en_US" causes problems somewhere, but it might.
> AFAICS the solutions to the current problems would be:
> (1) Put all VDR translation *.mo files in $LOCDIR/xx/LC_MESSAGES, where 
> xx is the language code without territory et al. LOCDIR can be whatever, 
> /usr/share/locale, ~/vdr/locale etc.
> (2) Check all the directories in $LOCDIR for vdr.mo.
> (3) (a)       Build a list of possible system locales by listing the system
>       locale dir (could be /usr/share/locale, /usr/lib/locale,
>       /usr/lib64/locale, depending on system; note that
>       /usr/share/locale may still contain the translations and they
>       are used even if it is not the system localedir).
> or  (b) Build a list of system locales by running "locale -a".
> or  (c) Hardcode a list of locale names to be tried.
> (4) Of the listed locales, select one that matches xx*, with xx being 
> the language code of the VDR translation. If (3a) or (3c) was used, we 
> need to test if they really work, as not all subdirs in those dirs are 
> valid locales.
> (5) Use iso-codes as pointed out by Wolfgang for the language name 
> translations.
> I also sent a message to gettext developers about the issue.

>From everything I've read in this (unfortunately badly subjected) thread
I can only come to one conclusion: setlocale/gettext is *broken*!

I can't believe that every program would have to fiddle around with
all these different directory localtions and stuff. As much as I like Linux,
but I hate the fact that every distribution has its files somewhere
else. Couldn't there for once be a *standard*?

And why isn't setlocale() smart enough to try "de" when the program
requests "de_DE" and there is no "de_DE" lcoale? It would be the reasonable
thing to do, wouldn't it?

I was hoping to make things simpler and easier when going to gettext,
but now it looks like I've traded one nightmare for another.

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.


vdr mailing list

Reply via email to