Klaus Schmidinger wrote: > 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*? As said multiple times before, the other programs *do not use* setlocale() to switch languages nor list languages, but rely on environment variables. That is why they do not need to do anything, and thus have not faced this problem. Note that KDE does provide the user a list of languages, but it does not use gettext, but instead uses its own glibc-derived implementation for translation, with file format being the same. > 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 think the reverse would be more useful here, i.e. not smart enough to try "de_DE" when "de" is called for. > 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. Yes. > 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. I'm not aware of such a way. -- Anssi Hannula _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
