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.