| Message ID | 46C6B921.4080007@cadsoft.de |
|---|---|
| State | New |
| Headers |
Received: from raven.cadsoft.de ([217.7.101.211]) by www.linuxtv.org with esmtp (Exim 4.63) (envelope-from <Klaus.Schmidinger@cadsoft.de>) id 1IMKQx-0004Ek-PG for vdr@linuxtv.org; Sat, 18 Aug 2007 11:17:27 +0200 Received: from [192.168.100.10] (hawk.cadsoft.de [192.168.100.10]) by raven.cadsoft.de (8.13.3/8.13.3) with ESMTP id l7I9HL6x001882 for <vdr@linuxtv.org>; Sat, 18 Aug 2007 11:17:21 +0200 Message-ID: <46C6B921.4080007@cadsoft.de> Date: Sat, 18 Aug 2007 11:17:21 +0200 From: Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> Organization: CadSoft Computer GmbH User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: vdr@linuxtv.org References: <46BEFDEB.4020603@cadsoft.de> <46C5A734.9080705@gmail.com> <46C5C55F.7030705@cadsoft.de> <46C6AE88.7020003@gmail.com> In-Reply-To: <46C6AE88.7020003@gmail.com> Content-Type: multipart/mixed; boundary="------------030001030901080506050000" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (raven.cadsoft.de [192.168.1.1]); Sat, 18 Aug 2007 11:17:22 +0200 (CEST) Subject: Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7 X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Sat, 18 Aug 2007 09:17:27 -0000 Status: O X-Status: X-Keywords: X-UID: 13761 |
Commit Message
Klaus Schmidinger
Aug. 18, 2007, 9:17 a.m. UTC
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. 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 ;-). >> 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. Klaus
Comments
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. >>> 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.
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? >>>> 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? Klaus
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.
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
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.
On Samstag, 18. August 2007, Klaus Schmidinger wrote: > 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. the debian package iso-codes contains all ISO 639 language codes with translations, so you could use those. The muggle plugin uses this to display the language of the audio file in the vdr OSD language. You should use at least version iso-codes 0.47-2 (Aug 2005), older versions were missing german translations for most european languages. from muggle, vdr_actions.c: dgettext("iso_639",item->value().c_str()) where the 2nd arg is the english language name AFAIR
Wolfgang Rohdewald wrote: > On Samstag, 18. August 2007, Klaus Schmidinger wrote: >> 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. > > the debian package iso-codes contains all ISO 639 language codes > with translations, so you could use those. And an URL: http://pkg-isocodes.alioth.debian.org/ > The muggle plugin uses this to display the language of the audio file in > the vdr OSD language. > > You should use at least version iso-codes 0.47-2 (Aug 2005), older > versions were missing german translations for most european languages. > > from muggle, vdr_actions.c: > > dgettext("iso_639",item->value().c_str()) > > where the 2nd arg is the english language name AFAIR Seems like a good solution to me.
--- i18n.h 2007/08/10 13:53:57 1.21 +++ i18n.h 2007/08/18 09:10:39 @@ -36,9 +36,16 @@ void I18nSetLanguage(int Language); ///< Sets the current language index to Language. If Language is outside ///< the range of available languages, nothing happens. +int I18nNumLanguagesWithLocale(void); + ///< Returns the number of entries in the list returned by I18nLanguages() + ///< that actually have a locale. const cStringList *I18nLanguages(void); ///< Returns the list of available languages. Values returned by ///< I18nCurrentLanguage() are indexes into this list. + ///< Only the first I18nNumLanguagesWithLocale() entries in this list + ///< have an actual locale installed. The rest are just dummy entries + ///< to allow having three letter language codes for other languages + ///< that have no actual locale on this system. const char *I18nTranslate(const char *s, const char *Plugin = NULL) __attribute_format_arg__(1); ///< Translates the given string (with optional Plugin context) into ///< the current language. If no translation is available, the original --- i18n.c 2007/08/17 12:31:17 1.310 +++ i18n.c 2007/08/18 09:08:45 @@ -67,6 +67,7 @@ static cStringList LanguageNames; static cStringList LanguageCodes; +static int NumLocales = 1; static int CurrentLanguage = 0; static bool ContainsCode(const char *Codes, const char *Code) @@ -105,6 +106,7 @@ for (int i = 0; i < Locales.Size(); i++) { if (i < I18N_MAX_LANGUAGES - 1) { if (setlocale(LC_MESSAGES, Locales[i])) { + NumLocales++; if (strstr(OldLocale, Locales[i]) == OldLocale) MatchFull = LanguageLocales.Size(); else if (strncmp(OldLocale, Locales[i], 2) == 0) @@ -177,6 +181,11 @@ } } +int I18nNumLanguagesWithLocale(void) +{ + return NumLocales; +} + const cStringList *I18nLanguages(void) { return &LanguageNames; --- menu.c 2007/08/12 10:44:35 1.459 +++ menu.c 2007/08/18 09:03:05 @@ -2205,7 +2205,7 @@ useSmallFontTexts[2] = tr("always"); Clear(); SetSection(tr("OSD")); - Add(new cMenuEditStraItem(tr("Setup.OSD$Language"), &osdLanguageIndex, I18nLanguages()->Size(), &I18nLanguages()->At(0))); + Add(new cMenuEditStraItem(tr("Setup.OSD$Language"), &osdLanguageIndex, I18nNumLanguagesWithLocale(), &I18nLanguages()->At(0))); Add(new cMenuEditStraItem(tr("Setup.OSD$Skin"), &skinIndex, numSkins, skinDescriptions)); if (themes.NumThemes()) Add(new cMenuEditStraItem(tr("Setup.OSD$Theme"), &themeIndex, themes.NumThemes(), themes.Descriptions()));