Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
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
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
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
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
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
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
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
#include
#include
+#include
#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
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
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
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
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
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
En/na Klaus Schmidinger ha escrit: > 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. freepascal bypasses gettext altogether by using an own implementation that reads mo files directly. Though it's in pascal, the implementation seems simple enough for a C++ wizard like you to replicate it with half the effort you'd need to workaround the issues we've seen so far. Here's the documentation of the class: http://community.freepascal.org:1/docs-html/fcl/gettext/tmofile.html and here's the implementation: http://svn.freepascal.org/svn/fpc/trunk/packages/fcl-base/src/inc/gettext.pp (just ignore the "Resourcestring translation procedures" that hooks into the native resourcestring mechanism of pascal). 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 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
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
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 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. 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 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
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().
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.
And if all programs must have their texts in /usr/share/locale/..., why
is there even a bindtextdomain() function?
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 ;-)
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 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
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
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.
--
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
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
___
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 wrote:
> On 08/18/07 12:28, Anssi Hannula wrote:
>> Klaus Schmidinger wrote:
>>> On 08/18/07 11:38, Anssi Hannula wrote:
Klaus Schmidinger wrote:
> On 08/18/07 10:32, Anssi Hannula wrote:
>> Klaus Schmidinger wrote:
>>> On 08/17/07 15:48, Anssi Hannula wrote:
...
show up as "deu,ger" etc, and do not work; text shows up in English
despite selecting them.
Maybe the locales that the user does not have installed on their
system
should be hidden?
>>> I thought that the language codes should always all be there,
>>> to allow selecting other preferred languages, even if there
>>> is no locale installed. But maybe I'm mistaken there.
>> Well, having those in the OSD language selection menu seems strange, if
>> only two of those actually work, and others do not show up correctly
>> ("deu,ger").
>>
>> But indeed, the Audio and EPG language selection menus seem to use the
>> same list. IMHO the Audio and EPG languages should use a separate list,
>> that contains all the language names in the currently selected OSD
>> language.
> That would mean that every *.po file would have to contain the name
> of every other language, and for every new language that's added, all
> other *.po files would have to be extended.
Then they will be extended, I don't see the problem here.
> Besides, if a user can't
> read a language name in the language's own writing, he/she probably
> won't understand that langauge, anyway ;-).
A good point. :)
However, most languages are currently shown as language codes, not in
the language's own writing.
>>> Where should that "language's own writing" come from, if not from
>>> a *.mo file for that language?
>> A custom table?
>> (If you do not want to start translating the language names to all
>> languages)
>>
>> Abusing setlocale() and gettext() to grab a language name from other
>> *.mo files seems wrong to me.
>>
>>> Please try disabling the code after
>>>
>>> // Prepare any known language codes for which there was no locale:
>>>
>>> in i18n.c and see whether that would do what you expect.
>> Yes, the languages that have no "locales-XX" package installed on my
>> system do not show up in the OSD language selection list anymore.
>>
>> However, I cannot select them as EPG nor Audio language either, which
>> should still be possible.
> Please try the attached patch.
> It changes the "Setup/OSD/Language" menu to only show the languages
> that actually have a locale. Any other language menus display language
> names if present, three letter language codes otherwise.
Seems to work. However, I don't like the fact that only few languages
are shown by their name, while others have only the language codes.
Before they were all shown by their name.
>>> The *.mo files for VDR's languages are all there - I don't know
>>> why setlocale()/gettext() doesn't deliver translations if the
>>> locale isn't "installed".
>>>
>>> VDR searches its locale directory for any locales that come with VDR,
>>> and calls setlocale() with them. If gettext() then doesn't return
>>> any translations, what do you suggest VDR should do?
>>>
>>> If you want to see all languages, maybe you just have to "install"
>>> all locales?
>> Unreasonable for just the language names. I suggest to use a table.
>
> That would mean that there is again something in VDR's core code that
> has to be maintained by various translators - I'm glad I got the i18n
> stuff out of the core code, and I wouldn't want to go back again.
I don't consider maintaining a single table for language names (either
native, or English with translations to all langs in .mo files) a problem.
> If you want to see all languages in their native wording, I guess
> that means you'll have to install all locales. Or, suggest a way
> to allow VDR to use setlocale/gettext without the need for the locales
> to actually be installed. VDR has all its text files available and
> only needs a way to have gettext() use them. This is currently done
> by calling setlocale() - maybe there's an other way?
I'm not aware of such a way.
--
Anssi Hannula
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
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
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 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 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
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
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.
--
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
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 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
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
On 8/17/07, Anssi Hannula <[EMAIL PROTECTED]> wrote:
> 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?
Yes please! :)
___
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 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
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
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 wrote: > - Added the "...or (at your option) any later version" phrase to the license > information of all plugins, and also the 'newplugin' script (suggested by > Ville Skyttä). Plugin authors may want to consider doing the same. Hm - are you sure that it is a good idea to accept a license if you did not have a chance to read it? That's like signing a contract without reading it... CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
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
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
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
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
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
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
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. 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
Hello, a hint on VDRs makefile: is there a "install-i18n" missing at the install target? Regards, Joachim. 2007/8/12, Klaus Schmidinger <[EMAIL PROTECTED]>: > VDR developer version 1.5.7 is now available [...] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Hi list, hi Klaus, Klaus Schmidinger wrote: > > The changes since version 1.5.6: > > - All logging now goes to LOG_ERR, because some systems split error, info and > debug messages into separate files, which repeatedly caused extra efforts to > find out when incomplete log excerpts were attached to problem reports in > the past. should this change be permanent, configurable or will it only apply for the developer releases? In my opinion, it is a benefit to redirect different log levels to different files for normal operation. In case of a bug, a commandline/setup option could select this behaviour to produce full logs. Just my 2 cent, -- Patrick Cernko | mailto:[EMAIL PROTECTED] | http://www.errror.org "Das Wort WINDOWS stammt aus einem alten Sioux-Dialekt und bedeutet: Weisser Mann starrt durch Glasscheibe auf Sanduhr." (anonym) signature.asc Description: OpenPGP digital signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Luca Olivetti ha escrit: > En/na Klaus Schmidinger ha escrit: > >> - The parameter OSDLanguage in 'setup.conf' is now a string and holds the >> locale >> code of the selected OSD language (e.g. en_US). If Setup.OSDLanguage is not >> set to a particular locale that is found in VDR's locale directory, the >> locale as defined in the system environment is used by default. > > My system locale is set as ca_ES: > > [EMAIL PROTECTED] vdr]$ locale > LANG=ca_ES.UTF-8 > LC_CTYPE=ca_ES.UTF-8 > LC_NUMERIC=ca_ES.UTF-8 > LC_TIME=ca_ES.UTF-8 > LC_COLLATE=ca_ES.UTF-8 > LC_MONETARY=ca_ES.UTF-8 > LC_MESSAGES=ca_ES.UTF-8 > LC_PAPER=ca_ES.UTF-8 > LC_NAME=ca_ES.UTF-8 > LC_ADDRESS=ca_ES.UTF-8 > LC_TELEPHONE=ca_ES.UTF-8 > LC_MEASUREMENT=ca_ES.UTF-8 > LC_IDENTIFICATION=ca_ES.UTF-8 > LC_ALL= > > If I leave OSDLanguage empty, the menus are in spanish. If I go to the > setup menu I can only select English and Spanish, all other languages > show the three letter code and are not selected. > If I select "Spanish" OSDLanguage is set to ca_ES and the menus are in > spanish. > > I set the LOCDIR in Make.config (to /home/vdr/vdr/locale, maybe is this > the problem?) and in that directory I have the ca_ES subdirectory (as > well as all other languages). > > In the log I see this: > vdr: [6184] VDR version 1.5.7 started > vdr: [6184] codeset is 'UTF-8' - known > vdr: [6184] found 21 locales in /home/vdr/vdr/locale > vdr: [6184] no locale for language code 'deu,ger' > vdr: [6184] no locale for language code 'slv,slo' > vdr: [6184] no locale for language code 'ita' > vdr: [6184] no locale for language code 'dut,nla,nld' > vdr: [6184] no locale for language code 'por' > vdr: [6184] no locale for language code 'fra,fre' > vdr: [6184] no locale for language code 'nor' > vdr: [6184] no locale for language code 'fin,smi' > vdr: [6184] no locale for language code 'pol' > vdr: [6184] no locale for language code 'ell,gre' > vdr: [6184] no locale for language code 'sve,swe' > vdr: [6184] no locale for language code 'rom,rum' > vdr: [6184] no locale for language code 'hun' > vdr: [6184] no locale for language code 'cat,cln' > vdr: [6184] no locale for language code 'rus' > vdr: [6184] no locale for language code 'hrv' > vdr: [6184] no locale for language code 'est' > vdr: [6184] no locale for language code 'dan' > vdr: [6184] no locale for language code 'cze,ces' > vdr: [6184] no locale for language code 'tur' 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. 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
VDR User schrieb: >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. :) > > Its the standard way of doing it. You can use tools/macros/settings for vi/emacs etc for translation, the handling should become easier with that and also non programmer can help to translate without touching the code. Also (correct me if i'm wrong) the translation is seperate and it can only be put in the languages you are using (at least thats my understanding of what localepurge is doing). In the end you are right - you will only get a translated vdr - but that is expected because its the target ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
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. -- Jaroslaw Swierczynski <[EMAIL PROTECTED]> www.archlinux.org | www.juvepoland.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
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
En/na Klaus Schmidinger ha escrit: > - The parameter OSDLanguage in 'setup.conf' is now a string and holds the > locale > code of the selected OSD language (e.g. en_US). If Setup.OSDLanguage is not > set to a particular locale that is found in VDR's locale directory, the > locale as defined in the system environment is used by default. My system locale is set as ca_ES: [EMAIL PROTECTED] vdr]$ locale LANG=ca_ES.UTF-8 LC_CTYPE=ca_ES.UTF-8 LC_NUMERIC=ca_ES.UTF-8 LC_TIME=ca_ES.UTF-8 LC_COLLATE=ca_ES.UTF-8 LC_MONETARY=ca_ES.UTF-8 LC_MESSAGES=ca_ES.UTF-8 LC_PAPER=ca_ES.UTF-8 LC_NAME=ca_ES.UTF-8 LC_ADDRESS=ca_ES.UTF-8 LC_TELEPHONE=ca_ES.UTF-8 LC_MEASUREMENT=ca_ES.UTF-8 LC_IDENTIFICATION=ca_ES.UTF-8 LC_ALL= If I leave OSDLanguage empty, the menus are in spanish. If I go to the setup menu I can only select English and Spanish, all other languages show the three letter code and are not selected. If I select "Spanish" OSDLanguage is set to ca_ES and the menus are in spanish. I set the LOCDIR in Make.config (to /home/vdr/vdr/locale, maybe is this the problem?) and in that directory I have the ca_ES subdirectory (as well as all other languages). In the log I see this: vdr: [6184] VDR version 1.5.7 started vdr: [6184] codeset is 'UTF-8' - known vdr: [6184] found 21 locales in /home/vdr/vdr/locale vdr: [6184] no locale for language code 'deu,ger' vdr: [6184] no locale for language code 'slv,slo' vdr: [6184] no locale for language code 'ita' vdr: [6184] no locale for language code 'dut,nla,nld' vdr: [6184] no locale for language code 'por' vdr: [6184] no locale for language code 'fra,fre' vdr: [6184] no locale for language code 'nor' vdr: [6184] no locale for language code 'fin,smi' vdr: [6184] no locale for language code 'pol' vdr: [6184] no locale for language code 'ell,gre' vdr: [6184] no locale for language code 'sve,swe' vdr: [6184] no locale for language code 'rom,rum' vdr: [6184] no locale for language code 'hun' vdr: [6184] no locale for language code 'cat,cln' vdr: [6184] no locale for language code 'rus' vdr: [6184] no locale for language code 'hrv' vdr: [6184] no locale for language code 'est' vdr: [6184] no locale for language code 'dan' vdr: [6184] no locale for language code 'cze,ces' vdr: [6184] no locale for language code 'tur' 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
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
