Klaus Schmidinger wrote:
> On 08/18/07 12:28, Anssi Hannula wrote:
>> Klaus Schmidinger wrote:
>>> On 08/18/07 11:38, Anssi Hannula wrote:
>>>> Klaus Schmidinger wrote:
>>>>> On 08/18/07 10:32, Anssi Hannula wrote:
>>>>>> Klaus Schmidinger wrote:
>>>>>>> On 08/17/07 15:48, Anssi Hannula wrote:
>>>>>>>> ...
>>>>>>>> show up as "deu,ger" etc, and do not work; text shows up in English
>>>>>>>> despite selecting them.
>>>>>>>>
>>>>>>>> Maybe the locales that the user does not have installed on their system
>>>>>>>> should be hidden?
>>>>>>> I thought that the language codes should always all be there,
>>>>>>> to allow selecting other preferred languages, even if there
>>>>>>> is no locale installed. But maybe I'm mistaken there.
>>>>>> Well, having those in the OSD language selection menu seems strange, if
>>>>>> only two of those actually work, and others do not show up correctly
>>>>>> ("deu,ger").
>>>>>>
>>>>>> But indeed, the Audio and EPG language selection menus seem to use the
>>>>>> same list. IMHO the Audio and EPG languages should use a separate list,
>>>>>> that contains all the language names in the currently selected OSD language.
>>>>> That would mean that every *.po file would have to contain the name
>>>>> of every other language, and for every new language that's added, all
>>>>> other *.po files would have to be extended.
>>>> Then they will be extended, I don't see the problem here.
>>>>
>>>> > Besides, if a user can't
>>>>> read a language name in the language's own writing, he/she probably
>>>>> won't understand that langauge, anyway ;-).
>>>> A good point. :)
>>>> However, most languages are currently shown as language codes, not in
>>>> the language's own writing.
>>> Where should that "language's own writing" come from, if not from
>>> a *.mo file for that language?
>> A custom table?
>> (If you do not want to start translating the language names to all
>> languages)
>>
>> Abusing setlocale() and gettext() to grab a language name from other
>> *.mo files seems wrong to me.
>>
>>>>>>> Please try disabling the code after
>>>>>>>
>>>>>>> // Prepare any known language codes for which there was no locale:
>>>>>>>
>>>>>>> in i18n.c and see whether that would do what you expect.
>>>>>> Yes, the languages that have no "locales-XX" package installed on my
>>>>>> system do not show up in the OSD language selection list anymore.
>>>>>>
>>>>>> However, I cannot select them as EPG nor Audio language either, which
>>>>>> should still be possible.
>>>>> Please try the attached patch.
>>>>> It changes the "Setup/OSD/Language" menu to only show the languages
>>>>> that actually have a locale. Any other language menus display language
>>>>> names if present, three letter language codes otherwise.
>>>> Seems to work. However, I don't like the fact that only few languages
>>>> are shown by their name, while others have only the language codes.
>>>> Before they were all shown by their name.
>>> The *.mo files for VDR's languages are all there - I don't know
>>> why setlocale()/gettext() doesn't deliver translations if the
>>> locale isn't "installed".
>>>
>>> VDR searches its locale directory for any locales that come with VDR,
>>> and calls setlocale() with them. If gettext() then doesn't return
>>> any translations, what do you suggest VDR should do?
>>>
>>> If you want to see all languages, maybe you just have to "install"
>>> all locales?
>> Unreasonable for just the language names. I suggest to use a table.
>
> That would mean that there is again something in VDR's core code that
> has to be maintained by various translators - I'm glad I got the i18n
> stuff out of the core code, and I wouldn't want to go back again.
I don't consider maintaining a single table for language names (either
native, or English with translations to all langs in .mo files) a problem.
> If you want to see all languages in their native wording, I guess
> that means you'll have to install all locales. Or, suggest a way
> to allow VDR to use setlocale/gettext without the need for the locales
> to actually be installed. VDR has all its text files available and
> only needs a way to have gettext() use them. This is currently done
> by calling setlocale() - maybe there's an other way?
I'm not aware of such a way.
--
Anssi Hannula
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
