[vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

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