Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Anssi Hannula]

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, [EMAIL PROTECTED] 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.

-- 
Anssi Hannula

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [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, [EMAIL PROTECTED] 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.

From everything I've read in this (unfortunately badly subjected) thread
I can only come to one conclusion: setlocale/gettext is *broken*!

I can't believe that every program would have to fiddle around with
all these different directory localtions and stuff. As much as I like Linux,
but I hate the fact that every distribution has its files somewhere
else. Couldn't there for once be a *standard*?

And why isn't setlocale() smart enough to try de when the program
requests de_DE and there is no de_DE lcoale? It would be the reasonable
thing to do, wouldn't it?

I was hoping to make things simpler and easier when going to gettext,
but now it looks like I've traded one nightmare for another.

Isn't there perhaps a way to tell gettext *explicitly* which files
to use, completely bypassing this whole broken setlocale stuff?
In that case VDR could collect it's list of *.mo files and decide
by itself which one to use.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Anssi Hannula]

Klaus Schmidinger wrote:
 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, [EMAIL PROTECTED] 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.
 
 From everything I've read in this (unfortunately badly subjected) thread
 I can only come to one conclusion: setlocale/gettext is *broken*!
 
 I can't believe that every program would have to fiddle around with
 all these different directory localtions and stuff. As much as I like Linux,
 but I hate the fact that every distribution has its files somewhere
 else. Couldn't there for once be a *standard*?

As said multiple times before, the other programs *do not use* 
setlocale() to switch languages nor list languages, but rely on 
environment variables. That is why they do not need to do anything, and 
thus have not faced this problem.

Note that KDE does provide the user a list of languages, but it does not 
use gettext, but instead uses its own glibc-derived implementation for 
translation, with file format being the same.

 And why isn't setlocale() smart enough to try de when the program
 requests de_DE and there is no de_DE lcoale? It would be the reasonable
 thing to do, wouldn't it?

I think the reverse would be more useful here, i.e. not smart enough to 
try de_DE when de is called for.

 I was hoping to make things simpler and easier when going to gettext,
 but now it looks like I've traded one nightmare for another.

Yes.

 Isn't there perhaps a way to tell gettext *explicitly* which files
 to use, completely bypassing this whole broken setlocale stuff?
 In that case VDR could collect it's list of *.mo files and decide
 by itself which one to use.

I'm not aware of such a way.

-- 
Anssi Hannula

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Luca Olivetti]

En/na Anssi Hannula ha escrit:

 Note that KDE does provide the user a list of languages, but it does not 
 use gettext, but instead uses its own glibc-derived implementation for 
 translation, with file format being the same.
[...]
 Isn't there perhaps a way to tell gettext *explicitly* which files
 to use, completely bypassing this whole broken setlocale stuff?
 In that case VDR could collect it's list of *.mo files and decide
 by itself which one to use.
 
 I'm not aware of such a way.

I think that in your message there's the solution: do *not* use gettext 
but use an own implementation. Maybe borrowing kde implementation (which 
is already C++) it's easier than translating the pascal class I proposed 
before (or maybe not ;-).

Bye
-- 
Luca


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Anssi Hannula]

Luca Olivetti wrote:
 En/na Anssi Hannula ha escrit:
 
 Note that KDE does provide the user a list of languages, but it does not 
 use gettext, but instead uses its own glibc-derived implementation for 
 translation, with file format being the same.
 [...]
 Isn't there perhaps a way to tell gettext *explicitly* which files
 to use, completely bypassing this whole broken setlocale stuff?
 In that case VDR could collect it's list of *.mo files and decide
 by itself which one to use.
 I'm not aware of such a way.
 
 I think that in your message there's the solution: do *not* use gettext 
 but use an own implementation. Maybe borrowing kde implementation (which 
 is already C++) it's easier than translating the pascal class I proposed 
 before (or maybe not ;-).

Actually, it seems KDE 4 uses real gettext to do it, and uses the 
following code:

 // Point Gettext to new language.
 setenv(LANGUAGE, language, 1);

 // Locale directories may differ for different languages of same 
catalog.
 bindtextdomain(name, localeDir);


Maybe just using 'setenv(LANGUAGE, de, 1);' will do what we want, 
without need for setlocale()? :)

I have to go now so I can't check that yet.

-- 
Anssi Hannula

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Anssi Hannula]

Anssi Hannula wrote:
 Luca Olivetti wrote:
 En/na Anssi Hannula ha escrit:

 Note that KDE does provide the user a list of languages, but it does not 
 use gettext, but instead uses its own glibc-derived implementation for 
 translation, with file format being the same.
 [...]
 Isn't there perhaps a way to tell gettext *explicitly* which files
 to use, completely bypassing this whole broken setlocale stuff?
 In that case VDR could collect it's list of *.mo files and decide
 by itself which one to use.
 I'm not aware of such a way.
 I think that in your message there's the solution: do *not* use gettext 
 but use an own implementation. Maybe borrowing kde implementation (which 
 is already C++) it's easier than translating the pascal class I proposed 
 before (or maybe not ;-).
 
 Actually, it seems KDE 4 uses real gettext to do it, and uses the 
 following code:
 
  // Point Gettext to new language.
  setenv(LANGUAGE, language, 1);
 
  // Locale directories may differ for different languages of same 
 catalog.
  bindtextdomain(name, localeDir);
 
 
 Maybe just using 'setenv(LANGUAGE, de, 1);' will do what we want, 
 without need for setlocale()? :)
 
 I have to go now so I can't check that yet.

I tested anyway ;)

It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi 
will work even if there is no such locale at all.

I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which 
certainly is not a valid locale, and using LANGUAGE=testtest it was 
correctly used! :)

-- 
Anssi Hannula

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/19/07 12:43, Anssi Hannula wrote:
 Anssi Hannula wrote:
 Luca Olivetti wrote:
 En/na Anssi Hannula ha escrit:

 Note that KDE does provide the user a list of languages, but it does not 
 use gettext, but instead uses its own glibc-derived implementation for 
 translation, with file format being the same.
 [...]
 Isn't there perhaps a way to tell gettext *explicitly* which files
 to use, completely bypassing this whole broken setlocale stuff?
 In that case VDR could collect it's list of *.mo files and decide
 by itself which one to use.
 I'm not aware of such a way.
 I think that in your message there's the solution: do *not* use gettext 
 but use an own implementation. Maybe borrowing kde implementation (which 
 is already C++) it's easier than translating the pascal class I proposed 
 before (or maybe not ;-).
 Actually, it seems KDE 4 uses real gettext to do it, and uses the 
 following code:

  // Point Gettext to new language.
  setenv(LANGUAGE, language, 1);

  // Locale directories may differ for different languages of same 
 catalog.
  bindtextdomain(name, localeDir);


 Maybe just using 'setenv(LANGUAGE, de, 1);' will do what we want, 
 without need for setlocale()? :)

 I have to go now so I can't check that yet.
 
 I tested anyway ;)
 
 It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi 
 will work even if there is no such locale at all.
 
 I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which 
 certainly is not a valid locale, and using LANGUAGE=testtest it was 
 correctly used! :)

Looks good. However, after some tests it would appear as if only the
very first setenv() call actually changes anything. Subsequent calls
have no further effect, and gettext() always returns the language
that was selected in the very first call to setenv().

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Luca Olivetti]

En/na Klaus Schmidinger ha escrit:


 It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi 
 will work even if there is no such locale at all.

 I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which 
 certainly is not a valid locale, and using LANGUAGE=testtest it was 
 correctly used! :)
 
 Looks good. However, after some tests it would appear as if only the
 very first setenv() call actually changes anything. Subsequent calls
 have no further effect, and gettext() always returns the language
 that was selected in the very first call to setenv().

Did you try calling bindtextdomain again after calling setenv?

Bye
-- 
Luca


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/19/07 14:57, Klaus Schmidinger wrote:
 On 08/19/07 12:43, Anssi Hannula wrote:
 Anssi Hannula wrote:
 Luca Olivetti wrote:
 En/na Anssi Hannula ha escrit:

 Note that KDE does provide the user a list of languages, but it does not 
 use gettext, but instead uses its own glibc-derived implementation for 
 translation, with file format being the same.
 [...]
 Isn't there perhaps a way to tell gettext *explicitly* which files
 to use, completely bypassing this whole broken setlocale stuff?
 In that case VDR could collect it's list of *.mo files and decide
 by itself which one to use.
 I'm not aware of such a way.
 I think that in your message there's the solution: do *not* use gettext 
 but use an own implementation. Maybe borrowing kde implementation (which 
 is already C++) it's easier than translating the pascal class I proposed 
 before (or maybe not ;-).
 Actually, it seems KDE 4 uses real gettext to do it, and uses the 
 following code:

  // Point Gettext to new language.
  setenv(LANGUAGE, language, 1);

  // Locale directories may differ for different languages of same 
 catalog.
  bindtextdomain(name, localeDir);


 Maybe just using 'setenv(LANGUAGE, de, 1);' will do what we want, 
 without need for setlocale()? :)

 I have to go now so I can't check that yet.
 I tested anyway ;)

 It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi 
 will work even if there is no such locale at all.

 I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which 
 certainly is not a valid locale, and using LANGUAGE=testtest it was 
 correctly used! :)
 
 Looks good. However, after some tests it would appear as if only the
 very first setenv() call actually changes anything. Subsequent calls
 have no further effect, and gettext() always returns the language
 that was selected in the very first call to setenv().

Apparently it is necessary to do a textdomain(vdr) call after the
setenv(). The bindtextdomain() call doesn't have any noticeable effect
here.

Please test the attached patch. It scans the LOCDIR directory as before,
but checks for the existence of a vdr.mo file and then uses setenv()
instead of setlocale().

This should work for VDR itself. For plugins I need to do more work.
But first let's see whether others can confirm that this works for VDR.

Klaus
--- i18n.c	2007/08/12 12:15:29	1.308
+++ i18n.c	2007/08/19 13:20:52
@@ -23,6 +23,7 @@
 #include ctype.h
 #include libintl.h
 #include locale.h
+#include unistd.h
 #include tools.h
 
 // TRANSLATORS: The name of the language, as written natively
@@ -101,9 +103,13 @@
   if (Locales.Size()  0) {
  dsyslog(found %d locales in %s, Locales.Size(), I18nLocaleDir);
  char *OldLocale = strdup(setlocale(LC_MESSAGES, NULL));
+ setlocale(LC_MESSAGES, );
  for (int i = 0; i  Locales.Size(); i++) {
- if (i  I18N_MAX_LANGUAGES - 1) {
-if (setlocale(LC_MESSAGES, Locales[i])) {
+ cString FileName = cString::sprintf(%s/%s/LC_MESSAGES/vdr.mo, I18nLocaleDir, Locales[i]);
+ if (access(FileName, F_OK) == 0) { // found a locale with VDR texts
+if (i  I18N_MAX_LANGUAGES - 1) {
+   setenv(LANGUAGE, Locales[i], 1);
+   textdomain(vdr);
if (strstr(OldLocale, Locales[i]) == OldLocale)
   CurrentLanguage = LanguageLocales.Size();
LanguageLocales.Append(strdup(Locales[i]));
@@ -117,11 +123,13 @@
}
LanguageCodes.Append(strdup(Code));
}
+else {
+   esyslog(ERROR: too many locales - increase I18N_MAX_LANGUAGES!);
+   break;
+   }
 }
- else
-esyslog(ERROR: too many locales - increase I18N_MAX_LANGUAGES!);
  }
- setlocale(LC_MESSAGES, OldLocale);
+ setenv(LANGUAGE, LanguageLocales[CurrentLanguage], 1);
  free(OldLocale);
  }
   // Prepare any known language codes for which there was no locale:
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/19/07 15:40, Luca Olivetti wrote:
 En/na Klaus Schmidinger ha escrit:
 
 It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi 
 will work even if there is no such locale at all.

 I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which 
 certainly is not a valid locale, and using LANGUAGE=testtest it was 
 correctly used! :)
 Looks good. However, after some tests it would appear as if only the
 very first setenv() call actually changes anything. Subsequent calls
 have no further effect, and gettext() always returns the language
 that was selected in the very first call to setenv().
 
 Did you try calling bindtextdomain again after calling setenv?

I did call it after setenv() (as suggested in Anssi's posting).

See my other posting from a few minutes ago with a patch.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Ludwig Nussel]

Klaus Schmidinger wrote:
 On 08/19/07 12:43, Anssi Hannula wrote:
  Anssi Hannula wrote:
  It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi 
  will work even if there is no such locale at all.
  
  I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which 
  certainly is not a valid locale, and using LANGUAGE=testtest it was 
  correctly used! :)
 
 Looks good. However, after some tests it would appear as if only the
 very first setenv() call actually changes anything. Subsequent calls
 have no further effect, and gettext() always returns the language
 that was selected in the very first call to setenv().

The gettext info page says:

 But there is one little hook.  The code for gcc-2.7.0 and up
 provides some optimization.  This optimization normally prevents
 the calling of the `dcgettext' function as long as no new catalog
 is loaded.  But if `dcgettext' is not called the program also
 cannot find the `LANGUAGE' variable be changed (*note Optimized 
 gettext::).  A solution for this is very easy.  Include the
 following code in the language switching function.

/* Change language.  */
setenv (LANGUAGE, fr, 1);

/* Make change known.  */
{
  extern int  _nl_msg_cat_cntr;
  ++_nl_msg_cat_cntr;
}

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/19/07 15:45, Ludwig Nussel wrote:
 Klaus Schmidinger wrote:
 On 08/19/07 12:43, Anssi Hannula wrote:
 Anssi Hannula wrote:
 It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi 
 will work even if there is no such locale at all.

 I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which 
 certainly is not a valid locale, and using LANGUAGE=testtest it was 
 correctly used! :)
 Looks good. However, after some tests it would appear as if only the
 very first setenv() call actually changes anything. Subsequent calls
 have no further effect, and gettext() always returns the language
 that was selected in the very first call to setenv().
 
 The gettext info page says:
 
  But there is one little hook.  The code for gcc-2.7.0 and up
  provides some optimization.  This optimization normally prevents
  the calling of the `dcgettext' function as long as no new catalog
  is loaded.  But if `dcgettext' is not called the program also
  cannot find the `LANGUAGE' variable be changed (*note Optimized 
  gettext::).  A solution for this is very easy.  Include the
  following code in the language switching function.
 
 /* Change language.  */
 setenv (LANGUAGE, fr, 1);
 
 /* Make change known.  */
 {
   extern int  _nl_msg_cat_cntr;
   ++_nl_msg_cat_cntr;
 }

Great! This works well!

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Luca Olivetti]

En/na Klaus Schmidinger ha escrit:

 Please test the attached patch. It scans the LOCDIR directory as before,
 but checks for the existence of a vdr.mo file and then uses setenv()
 instead of setlocale().
 
 This should work for VDR itself. For plugins I need to do more work.
 But first let's see whether others can confirm that this works for VDR.

With this patch it shows all the language names, but then it ignores the 
selection (i.e. the osd is always in the system selected locale), 
regardless if the selected language has a locale installed or not.

Bye
-- 
Luca


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/19/07 16:23, Luca Olivetti wrote:
 En/na Klaus Schmidinger ha escrit:
 
 Please test the attached patch. It scans the LOCDIR directory as before,
 but checks for the existence of a vdr.mo file and then uses setenv()
 instead of setlocale().

 This should work for VDR itself. For plugins I need to do more work.
 But first let's see whether others can confirm that this works for VDR.
 
 With this patch it shows all the language names, but then it ignores the 
 selection (i.e. the osd is always in the system selected locale), 
 regardless if the selected language has a locale installed or not.

Strange, worked fine here - even if I rename the locale directory
from de_DE to xyz.

Please try version 1.5.8, which I have just uploaded.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Luca Olivetti]

En/na Klaus Schmidinger ha escrit:

 Please try version 1.5.8, which I have just uploaded.

yes, 1.5.8 works.

Bye
-- 
Luca


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Anssi Hannula]

Klaus Schmidinger wrote:
 On 08/17/07 15:48, Anssi Hannula wrote:
 Klaus Schmidinger wrote:
 - Internationalization is now done with 'gettext' (following a suggestion by
   Lucian Muresan). Plugin authors may want to use the Perl script
   'i18n-to-gettext.pl' to convert their internationalized texts to the 
 gettext
   format (see the instructions inside that script file). The function
   cPlugin::RegisterI18n() is still present for compatibility, but doesn't
   have any more functionality. So plugins that don't convert their texts to
   the gettext format will only present English texts.
   See PLUGINS.html, section Internationalization, for instructions on how
   to make strings in arrays translatable.
   See README.i18n for information on how to create new or maintain existing
   translations.
 I have only Finnish locales installed (locale -a), so only the 
 selections suomi and English work from the plugin menu. The rest 
 
 What plugin menu?

OSD language selection in the setup menu ;)

 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.

 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.

-- 
Anssi Hannula


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

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
--- 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()));
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Anssi Hannula]

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.

-- 
Anssi Hannula

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Udo Richter]

Klaus Schmidinger wrote:
 - Internationalization is now done with 'gettext' (following a suggestion by
   Lucian Muresan). 


To add another report, I had some trouble to pick anything but English 
at first. After some fiddling and trying the various hints, here's what 
was missing for me:

 #locale
 [EMAIL PROTECTED]
 LC_CTYPE=[EMAIL PROTECTED]
 LC_NUMERIC=[EMAIL PROTECTED]
 LC_TIME=[EMAIL PROTECTED]
 LC_COLLATE=[EMAIL PROTECTED]
 LC_MONETARY=[EMAIL PROTECTED]
 LC_MESSAGES=[EMAIL PROTECTED]
 LC_PAPER=[EMAIL PROTECTED]
 LC_NAME=[EMAIL PROTECTED]
 LC_ADDRESS=[EMAIL PROTECTED]
 LC_TELEPHONE=[EMAIL PROTECTED]
 LC_MEASUREMENT=[EMAIL PROTECTED]
 LC_IDENTIFICATION=[EMAIL PROTECTED]
 LC_ALL=

 #locale -a
 C
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 POSIX

This is pretty much old debian default. After that, I've added another 
de_DE variant:

 #sudo dpkg-reconfigure locales
 Generating locales (this might take a while)...
   [EMAIL PROTECTED] done
   de_DE.ISO-8859-1... done
 Generation complete.

 #locale -a
 C
 de_DE
 [EMAIL PROTECTED]
 de_DE.iso88591
 [EMAIL PROTECTED]
 deutsch
 german
 POSIX

... and now it works. Is there a way to make VDR less picky about what 
de_DE language variant is installed?


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

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@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/18/07 12:29, Udo Richter wrote:
 Klaus Schmidinger wrote:
 - Internationalization is now done with 'gettext' (following a suggestion by
   Lucian Muresan). 
 
 
 To add another report, I had some trouble to pick anything but English 
 at first. After some fiddling and trying the various hints, here's what 
 was missing for me:
 
  #locale
  [EMAIL PROTECTED]
  LC_CTYPE=[EMAIL PROTECTED]
  LC_NUMERIC=[EMAIL PROTECTED]
  LC_TIME=[EMAIL PROTECTED]
  LC_COLLATE=[EMAIL PROTECTED]
  LC_MONETARY=[EMAIL PROTECTED]
  LC_MESSAGES=[EMAIL PROTECTED]
  LC_PAPER=[EMAIL PROTECTED]
  LC_NAME=[EMAIL PROTECTED]
  LC_ADDRESS=[EMAIL PROTECTED]
  LC_TELEPHONE=[EMAIL PROTECTED]
  LC_MEASUREMENT=[EMAIL PROTECTED]
  LC_IDENTIFICATION=[EMAIL PROTECTED]
  LC_ALL=
 
  #locale -a
  C
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  POSIX
 
 This is pretty much old debian default. After that, I've added another 
 de_DE variant:
 
  #sudo dpkg-reconfigure locales
  Generating locales (this might take a while)...
[EMAIL PROTECTED] done
de_DE.ISO-8859-1... done
  Generation complete.
 
  #locale -a
  C
  de_DE
  [EMAIL PROTECTED]
  de_DE.iso88591
  [EMAIL PROTECTED]
  deutsch
  german
  POSIX
 
 ... and now it works. Is there a way to make VDR less picky about what 
 de_DE language variant is installed?

Are you sure it's VDR who is picky? Isn't setlocale a little dumb here?

Please try the patch I have posted yesterday under improving 
i18n-to-gettext.pl
(vdr-1.5.7-i18n-matchlocale.diff)?

BTW: everything works fine here under SUSE 10.2.

Klaus


Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Udo Richter]

Klaus Schmidinger wrote:
 On 08/18/07 12:29, Udo Richter wrote:
 To add another report, I had some trouble to pick anything but English 
 at first. After some fiddling and trying the various hints, here's what 
 was missing for me:

  [...]

 ... and now it works. Is there a way to make VDR less picky about what 
 de_DE language variant is installed?
 
 Are you sure it's VDR who is picky? Isn't setlocale a little dumb here?

In the end, this isn't really important. What matters is that you have 
to explain lots of users that they need to reconfigure their OS language 
from german to german in order to pick german as language manually 
inside VDR.

 Please try the patch I have posted yesterday under improving 
 i18n-to-gettext.pl
 (vdr-1.5.7-i18n-matchlocale.diff)?

Seems to make no difference. Probably because setlocale only accepts the 
full [EMAIL PROTECTED] string.

There must be some way how this is supposed to work. Even if my locale 
is set to [EMAIL PROTECTED] and there's no pure de_DE in locale -a, almost all 
distribution' locales are in /usr/share/locale/de/, and they work. There 
must be some mapping from [EMAIL PROTECTED] down to de_DE and de.


Cheers,

Udo


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Anssi Hannula]

Udo Richter wrote:
 Klaus Schmidinger wrote:
 On 08/18/07 12:29, Udo Richter wrote:
 To add another report, I had some trouble to pick anything but English 
 at first. After some fiddling and trying the various hints, here's what 
 was missing for me:

  [...]

 ... and now it works. Is there a way to make VDR less picky about what 
 de_DE language variant is installed?
 Are you sure it's VDR who is picky? Isn't setlocale a little dumb here?
 
 In the end, this isn't really important. What matters is that you have 
 to explain lots of users that they need to reconfigure their OS language 
 from german to german in order to pick german as language manually 
 inside VDR.
 
 Please try the patch I have posted yesterday under improving 
 i18n-to-gettext.pl
 (vdr-1.5.7-i18n-matchlocale.diff)?
 
 Seems to make no difference. Probably because setlocale only accepts the 
 full [EMAIL PROTECTED] string.
 
 There must be some way how this is supposed to work. Even if my locale 
 is set to [EMAIL PROTECTED] and there's no pure de_DE in locale -a, almost 
 all 
 distribution' locales are in /usr/share/locale/de/, and they work. There 
 must be some mapping from [EMAIL PROTECTED] down to de_DE and de.

Yes, but the other applications are not listing locales nor using 
setlocale to change locale to those during runtime, which is the problem 
here. If there was another app that does it, it could be interesting to 
see how it manages that. I don't know other way than to use the locale 
-a way, i.e. traverse /usr/share/locale and parse locale.alias.

-- 
Anssi Hannula

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Anssi Hannula]

Klaus Schmidinger wrote:
 On 08/18/07 21:46, Anssi Hannula wrote:
 Udo Richter wrote:
 Klaus Schmidinger wrote:
 On 08/18/07 12:29, Udo Richter wrote:
 To add another report, I had some trouble to pick anything but English 
 at first. After some fiddling and trying the various hints, here's what 
 was missing for me:

  [...]

 ... and now it works. Is there a way to make VDR less picky about what 
 de_DE language variant is installed?
 Are you sure it's VDR who is picky? Isn't setlocale a little dumb here?
 In the end, this isn't really important. What matters is that you have 
 to explain lots of users that they need to reconfigure their OS language 
 from german to german in order to pick german as language manually 
 inside VDR.

 Please try the patch I have posted yesterday under improving 
 i18n-to-gettext.pl
 (vdr-1.5.7-i18n-matchlocale.diff)?
 Seems to make no difference. Probably because setlocale only accepts the 
 full [EMAIL PROTECTED] string.

 There must be some way how this is supposed to work. Even if my locale 
 is set to [EMAIL PROTECTED] and there's no pure de_DE in locale -a, almost 
 all 
 distribution' locales are in /usr/share/locale/de/, and they work. There 
 must be some mapping from [EMAIL PROTECTED] down to de_DE and de.
 Yes, but the other applications are not listing locales nor using 
 setlocale to change locale to those during runtime, which is the problem 
 here. If there was another app that does it, it could be interesting to 
 see how it manages that. I don't know other way than to use the locale 
 -a way, i.e. traverse /usr/share/locale and parse locale.alias.
 
 Maybe I should have stayed with the old tI18nPhrase method. At least
 that worked everywhere out of the box...
 
 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.
 
 Copying the *.mo files into /usr/share/locale/... could be done.
 VDR would then have to loop through all directories in /usr/share/locale
 and test each one for the presence of a vdr.mo file, as in
 
 /usr/share/locale/de/LC_MESSAGES/vdr.mo
 
 and use the directory name it finds (de in this case) as the value
 in its call to setlocale().

Unfortunately the de might not be a valid locale for setlocale(), as 
in Udo's case; only [EMAIL PROTECTED] and [EMAIL PROTECTED] are, even if the 
files from /de/ are used. I think the valid locales can be identified by 
having a LC_IDENTIFICATION file in the locale directory, containing the 
locale identification data (printed by locale -a -v), or if they are 
contained in /usr/share/locale.alias.

Note that apparently Matthias Schwarzott's system (other thread) has the 
LC_IDENTIFICATION file in /usr/lib/locale instead of /usr/share/locale.

 The only problem I see is: how to find out what directories to copy
 VDR's *.mo files into? For example, VDR's German text file is named
 ./locale/de_DE/LC_MESSAGES/vdr.mo, but should it go into
 /usr/share/locale/de_DE/LC_MESSAGES/vdr.mo or
 /usr/share/locale/de/LC_MESSAGES/vdr.mo or even
 /usr/share/locale/[EMAIL PROTECTED]/LC_MESSAGES/vdr.mo?
 This decision clearly would have to be made at install time.

/de/, as with other programs. If there will be additional 
territory-specific de translations of VDR, they will go to de_XX. The 
translations from /de/ are always used when locale is 
[EMAIL PROTECTED]

 And if all programs must have their texts in /usr/share/locale/..., why
 is there even a bindtextdomain() function?

So that the locales can be installed into another directory/prefix, like 
inside the source tree.

 So, to sum things up: I might go along with copying VDR's *.mo files
 into /usr/share/locale/... (and prefix the plugin files with vdr- or
 something alike), if somebody can come up with a Makefile install-i18n 
 target
 that copies VDR's files from $(LOCALEDIR) to the proper places under
 /usr/share/locale/...
 
 Oh, and of course the whole thing must still work locally in ./locale ;-)

Well, changing the locale directory does not really change this issue at 
all.

I guess the easiest and most compatible thing to do now would be to 
traverse /usr/share/locale dir and if $LOCDIR/xx/LC_MESSAGES/vdr.mo 
exists, try the names of all existing /usr/share/locale/xx*/ directories 
as parameter for setlocale(). ($LOCDIR being the VDR localedir, be that 
/usr/share/locale, /usr/share/vdr/locale, /home/anssi/vdr-1.5.7/locale, 
or whatever).

-- 
Anssi Hannula

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Anssi Hannula]

Klaus Schmidinger wrote:
 - Internationalization is now done with 'gettext' (following a suggestion by
   Lucian Muresan). Plugin authors may want to use the Perl script
   'i18n-to-gettext.pl' to convert their internationalized texts to the gettext
   format (see the instructions inside that script file). The function
   cPlugin::RegisterI18n() is still present for compatibility, but doesn't
   have any more functionality. So plugins that don't convert their texts to
   the gettext format will only present English texts.
   See PLUGINS.html, section Internationalization, for instructions on how
   to make strings in arrays translatable.
   See README.i18n for information on how to create new or maintain existing
   translations.

I have only Finnish locales installed (locale -a), so only the 
selections suomi and English work from the plugin menu. The rest 
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?

-- 
Anssi Hannula


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/17/07 15:48, Anssi Hannula wrote:
 Klaus Schmidinger wrote:
 - Internationalization is now done with 'gettext' (following a suggestion by
   Lucian Muresan). Plugin authors may want to use the Perl script
   'i18n-to-gettext.pl' to convert their internationalized texts to the 
 gettext
   format (see the instructions inside that script file). The function
   cPlugin::RegisterI18n() is still present for compatibility, but doesn't
   have any more functionality. So plugins that don't convert their texts to
   the gettext format will only present English texts.
   See PLUGINS.html, section Internationalization, for instructions on how
   to make strings in arrays translatable.
   See README.i18n for information on how to create new or maintain existing
   translations.
 
 I have only Finnish locales installed (locale -a), so only the 
 selections suomi and English work from the plugin menu. The rest 

What plugin menu?

 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.

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.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Darren Salt]

I demand that Klaus Schmidinger may or may not have written...

[snip]
 (I wonder when one of our neighbo(u)rs will write a colo(u)rful en_UK
 version ;-).

Somehow, I doubt that most Ukrainians would want that. ;-)

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output *more* particulate pollutants.  BUFFER AGAINST GLOBAL WARMING.

If some people didn't tell you, you'd never know that they'd been on holiday.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/13/07 17:06, Darren Salt wrote:
 I demand that Klaus Schmidinger may or may not have written...
 
 [snip]
 (I wonder when one of our neighbo(u)rs will write a colo(u)rful en_UK
 version ;-).
 
 Somehow, I doubt that most Ukrainians would want that. ;-)

Ooops - I meant en_GB, of course ;-)

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Stone]

On 8/12/07, Klaus Schmidinger [EMAIL PROTECTED] wrote:

 VDR developer version 1.5.7 is now available at

ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.7.tar.bz2

 A 'diff' against the previous developer version is available at

ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.6-1.5.7.diff



Thanks Klaus.  Since i18n.c has changed in this new version of vdr, a few
common patches I have been using have broke.

1) jumpplay-0.9.diff
2) liemikuutio-1.13.diff
3) timercmd-0.1.diff (comes from epgsearch)

Can someone explain to me the proper way to fix these rejects with i18n.c?

Groeten.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[VDR User]

On 8/12/07, Stone [EMAIL PROTECTED] wrote:
 Thanks Klaus.  Since i18n.c has changed in this new version of vdr, a few
 common patches I have been using have broke.

 1) jumpplay-0.9.diff
 2) liemikuutio-1.13.diff
 3) timercmd-0.1.diff (comes from epgsearch)

 Can someone explain to me the proper way to fix these rejects with i18n.c?

I assume you'd just remove the i18n stuff from the patch, apply it,
then generate a *.pot file for vdr and edit it with the language
translations (from the instructions in README.i18n).

What I'm wondering is what real benefit this method has over the old
one?  Just seems like adding more steps and in the end its just the
same result/no benefit.  I'm sure someone will correct me on that
though.  :)

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/12/07 22:01, Luca Olivetti wrote:
 En/na Luca Olivetti ha escrit:
 
 it appears that, even if the setlocale call succeeds, gettext doesn't 
 find the correct translation for LanguageCode (it always returns esl, 
 very strange since ca_ES is the first one tried).
 If I leave just the ca_ES directory, LanguageCode is untranslated.
 
 Well, it seems that if the LANGUAGE variable is set, the second argument 
 to setlocale is ignored, and since I had LANGUAGE=ca:es_ES:es it looked 
 in ca (which doesn't exist) and then es_ES (found) and stopped there.

So what exactly doesn this mean?
Should something be changed in VDR, or do you just not set the
LANGUAGE variable?

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/12/07 18:47, Jaroslaw Swierczynski wrote:
 2007/8/12, VDR User [EMAIL PROTECTED]:
 What I'm wondering is what real benefit this method has over the old
 one?  Just seems like adding more steps and in the end its just the
 same result/no benefit.  I'm sure someone will correct me on that
 though.  :)
 
 Just take a look at a .po file and you will understand. I'm sure
 maintaing the old language file was a nightmare for Klaus.

Well, it was, at times.
Especially when I received new updates from several translators,
often even beased on different versions.

Now maintainers can concentrate on their language file(s)
and send them to me independent of all other languages.

It's also way simpler to add a new translation (I wonder when
one of our neighbo(u)rs will write a colo(u)rful en_UK version ;-).

Klaus


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Luca Olivetti]

En/na Klaus Schmidinger ha escrit:
 On 08/12/07 22:01, Luca Olivetti wrote:
 En/na Luca Olivetti ha escrit:

 it appears that, even if the setlocale call succeeds, gettext doesn't 
 find the correct translation for LanguageCode (it always returns esl, 
 very strange since ca_ES is the first one tried).
 If I leave just the ca_ES directory, LanguageCode is untranslated.
 Well, it seems that if the LANGUAGE variable is set, the second argument 
 to setlocale is ignored, and since I had LANGUAGE=ca:es_ES:es it looked 
 in ca (which doesn't exist) and then es_ES (found) and stopped there.
 
 So what exactly doesn this mean?

that the man page of setlocale is incorrect ;-)

 Should something be changed in VDR, or do you just not set the
 LANGUAGE variable?

I'm just unsetting LANGUAGE before launching vdr. Maybe someone else 
will be bitten by this problem and he'll have to unset LANGUAGE too.

Bye
-- 
Luca

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Klaus Schmidinger]

On 08/12/07 22:35, Luca Olivetti wrote:
 En/na Klaus Schmidinger ha escrit:
 On 08/12/07 22:01, Luca Olivetti wrote:
 En/na Luca Olivetti ha escrit:

 it appears that, even if the setlocale call succeeds, gettext doesn't 
 find the correct translation for LanguageCode (it always returns esl, 
 very strange since ca_ES is the first one tried).
 If I leave just the ca_ES directory, LanguageCode is untranslated.
 Well, it seems that if the LANGUAGE variable is set, the second argument 
 to setlocale is ignored, and since I had LANGUAGE=ca:es_ES:es it looked 
 in ca (which doesn't exist) and then es_ES (found) and stopped there.
 So what exactly doesn this mean?
 
 that the man page of setlocale is incorrect ;-)
 
 Should something be changed in VDR, or do you just not set the
 LANGUAGE variable?
 
 I'm just unsetting LANGUAGE before launching vdr. Maybe someone else 
 will be bitten by this problem and he'll have to unset LANGUAGE too.

Wouldn't that be problem for other applications, too?
Could VDR do something to make this work better?

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7

[Luca Olivetti]

En/na Klaus Schmidinger ha escrit:

 I'm just unsetting LANGUAGE before launching vdr. Maybe someone else 
 will be bitten by this problem and he'll have to unset LANGUAGE too.
 
 Wouldn't that be problem for other applications, too?
 Could VDR do something to make this work better?

I don't know, I think most applications just use the locale environment 
variables and don't allow switching language at runtime.
Maybe it's just my version of glibc that's flawed, or my settings for 
LANGUAGE.

Bye
-- 
Luca


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr