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 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
