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