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, de_DE@euro 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.
Klaus