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