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] mplayer does not work properly
Jakob Lenfers wrote: > Pasi Juppo schrieb: > >> [Video without sound] >> Video clips were using AC3. They have used to work fine so I downgraded >> to mplayer 1.0 pre 8 and now the audio gets passed through to the >> amplifier via FF card. > > I guess I've got a similar problem as you have: Sometimes I get only > video, sometimes only audio! (on the same files, I can't find out when > which happens.) > > But it all started after I upgraded accidently mplayer. :-( Does someone > has a .deb against debian stable of 1.0pre8 so I don't have to compile > it myself? This problem is solved now. Solution was this simple. Change mplayer.sh.conf AC3AOUT="-ac hwac3" to AC3AOUT="-ao mpegpes -ac hwac3". Br, Pasi ___ 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
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
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
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
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 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] vdr 1.4.7 woun't shutdown correctly
HI Udo! Am Sonntag, den 19.08.2007, 02:33 +0200 schrieb Udo Richter: > And since there's no special > timer at that time, all remaining fields are empty. O.K. that explain, that responses on syslog! Thanx for your help! Have a nice day! cu, BC ___ 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
[vdr] VDR-core's texts in plugin's .pot files
Hi, plugins can re-use VDR-core translations. With the old "i18n.c" method plugin authors just did not provide a plugin specific translation for these texts. With the new translation method identifying these text got harder for plugin translators. xgettext puts all texts into the .pot file - also the texts for which the VDR-core translation should be used. A translator now cannot see which texts he has to translate and which not. Can this be improved? One way of doing this would be to introduce a new macro similar to trNOOP( ). A plugin author would then tag the vdr-core texts with this new macro and xgettext would ignore these texts. What do you think? Regards, Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-core's texts in plugin's .pot files
I demand that Matthias Becker may or may not have written... > plugins can re-use VDR-core translations. With the old "i18n.c" method > plugin authors just did not provide a plugin specific translation for these > texts. > With the new translation method identifying these text got harder for > plugin translators. xgettext puts all texts into the .pot file - also the > texts for which the VDR-core translation should be used. A translator now > cannot see which texts he has to translate and which not. > Can this be improved? Each plugin has to handle its own translations and ensure that they're in its own translation domain. This means that its makefile has to run xgettext, generate .mo files and install them. Translation has to be done (for plugin-specific text) using dgettext() and dngettext() instead of gettext() and ngettext(). [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Travel less. Share transport more. PRODUCE LESS CARBON DIOXIDE. If at first you don't succeed, you're doing about average. ___ 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 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
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
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] VDR-core's texts in plugin's .pot files
2007/8/19, Darren Salt <[EMAIL PROTECTED]>: > Each plugin has to handle its own translations and ensure that they're in its > own translation domain. This means that its makefile has to run xgettext, > generate .mo files and install them. Translation has to be done (for > plugin-specific text) using dgettext() and dngettext() instead of gettext() > and ngettext(). I don't see. where this adresses the problem. Plugins use tr() to translate strings, like VDR. The handling of (d)gettext happens in core VDR. xgettext simply extracts all strings marked with tr(s) and trNOOP(s) regardless of s beeing a plugin translated string or a re-used string from VDR core. Regards, Joachim. ___ 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
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
[vdr] [ANNOUNCE] VDR developer version 1.5.8
VDR developer version 1.5.8 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.8.tar.bz2 A 'diff' against the previous developer version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.7-1.5.8.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 1.5.7: - Added missing install-i18n to the install target in the Makefile (reported by Joachim Wilke). - Fixed a faulty comment in Make.config.template (reported by Marco Schlüßler). - Improved i18n-to-gettext.pl (thanks to Matthias Schwarzott). - Moved the "all" target in plugin Makefiles before the "Implicit rules", so that a plain "make" will compile everything (suggested by Matthias Schwarzott). The "newplugin" script has been changed accordingly. Plugin authors may want to change their Makefiles, too. - Added DESTDIR and PREFIX handling to the Makefile (thanks to Matthias Schwarzott). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Added internationalization to the "skincurses" plugin (thanks to Rolf Ahrenberg). - Checking the string for NULL in I18nTranslate(). - Updated the French OSD texts (thanks to Bruno Roussel). - Some optimizations in cDvbDevice::SetChannelDevice() (thanks to Tobias Bratfisch). - Optimized cMenuEditChrItem::Set() (thanks to Tobias Bratfisch). - Optimized cNitFilter::Process() (thanks to Tobias Bratfisch). - Reduced the number of time(NULL) calls in vdr.c's main loop to a single call (thanks to Tobias Bratfisch). - Changed cBitmap::DrawText() to always draw the background unless ColorBg is clrTransparent (thanks to Christoph Haubrich). - The "Setup/OSD/Language" menu now only shows those languages that actually have a locale (suggested by Anssi Hannula). - Now using setenv() instead of setlocale() to set the language for gettext() (suggested by Anssi Hannula; thanks also to Ludwig Nussel for a hint on using _nl_msg_cat_cntr). - When scanning the locale directory, VDR now explicitly looks for a file named vdr.mo. Text files for plugins are now named "vdr-name.mo", when "name" is the name of the plugin. The "newplugin" script has been changed accordingly, and plugin authors should change their Makefiles, too. *When reporting problems, please don't reply to this message!* Create a new thread instead, using a descriptive subject! Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-core's texts in plugin's .pot files
On 08/19/07 14:58, Matthias Becker wrote: > Hi, > > plugins can re-use VDR-core translations. With the old "i18n.c" method > plugin authors just did not provide a plugin specific translation for > these texts. > With the new translation method identifying these text got harder for > plugin translators. xgettext puts all texts into the .pot file - also > the texts for which the VDR-core translation should be used. A > translator now cannot see which texts he has to translate and which > not. > > Can this be improved? > > One way of doing this would be to introduce a new macro similar to > trNOOP( ). A plugin author would then tag the vdr-core texts with this > new macro and xgettext would ignore these texts. > > What do you think? I'll look into this next weekend - this WE was a littly hectic with the locale problems... 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 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
[vdr] vdr-1.5.7-1.5.8.diff problems?
The diff fails on all po files, it's only me or does it happens to others? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] po2i18n - converter for plugin backwards compatibility
Hi Udo Am Samstag, 18. August 2007 wrote Udo Richter: > Hi list, > > I've uploaded a little perl script and instructions to convert from the > new gettext based po i18n files to the old i18n.c system of VDR 1.5.6 > and earlier. By using this script its easy to use the new po based i18n > system for translations, and still compile the plugins with full i18n > support all the way back to VDR 1.2.0. > > The script can either be used manually to generate the i18n.c file from > the po files and a template, or automatically as part of the build process. > > Get it here: > http://www.udo-richter.de/vdr/scripts.html#po2i18n > http://www.udo-richter.de/vdr/scripts.en.html#po2i18n > > I kind of enhanced your script to use the CPAN module Locale::PO for reading the .po/.pot files. Your implementation did not handle multi line msgids and msgstrs well. My change adds all strings in the plugins .pot file to the resulting i18n.c file, even when no translation exists for the string and it does not sort the msgids. I called it pot2i18n.pl to take into account that it reads the .pot file too. Usage is analogous to po2i18n.pl. You must specifiy the plugins .pot file as first argument. Feel free to use my changes for your next version if you like. Regards Dieter -- Dieter Hametnermailto: [EMAIL PROTECTED] live plugin developer http://live.vdr-developer.org pot2i18n.pl.bz2 Description: BZip2 compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
On 08/19/07 16:54, Luca Olivetti wrote: > The diff fails on all po files, it's only me or does it happens to others? You need to add '-p1' to the patch command. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
On Sunday 19 Aug 2007, Luca Olivetti wrote: > The diff fails on all po files, it's only me or does it happens to > others? The diff applies fine for me. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
En/na Klaus Schmidinger ha escrit: > On 08/19/07 16:54, Luca Olivetti wrote: >> The diff fails on all po files, it's only me or does it happens to others? > > You need to add '-p1' to the patch command. Yes, I know that, it doesn't prompt me for the filename, but it just FAILS to patch (and stores the rejects). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
On 08/19/07 17:12, Luca Olivetti wrote: > En/na Klaus Schmidinger ha escrit: >> On 08/19/07 16:54, Luca Olivetti wrote: >>> The diff fails on all po files, it's only me or does it happens to others? >> You need to add '-p1' to the patch command. > > Yes, I know that, it doesn't prompt me for the filename, but it just > FAILS to patch (and stores the rejects). I explicitly tried it with the original 1.5.7, and it went through just fine. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
En/na Luca Olivetti ha escrit: > En/na Klaus Schmidinger ha escrit: >> On 08/19/07 16:54, Luca Olivetti wrote: >>> The diff fails on all po files, it's only me or does it happens to others? >> You need to add '-p1' to the patch command. > > Yes, I know that, it doesn't prompt me for the filename, but it just > FAILS to patch (and stores the rejects). The strange thing is that the context of the rejected hunks seems fine in the original file?!? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
Luca Olivetti wrote: > The diff fails on all po files, it's only me or does it happens to others? po files are a pain for diff-patches because they have lists of source code line numbers in the comments. If you've applied any other patch to the VDR sources, and did a recompile, then all your po files will have lots of changed line numbers. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
En/na Klaus Schmidinger ha escrit: > On 08/19/07 17:12, Luca Olivetti wrote: >> En/na Klaus Schmidinger ha escrit: >>> On 08/19/07 16:54, Luca Olivetti wrote: The diff fails on all po files, it's only me or does it happens to others? >>> You need to add '-p1' to the patch command. >> Yes, I know that, it doesn't prompt me for the filename, but it just >> FAILS to patch (and stores the rejects). > > I explicitly tried it with the original 1.5.7, and it went through > just fine. you're right, I tried the patch from 1.5.6->1.5.7->1.5.7 (since the last tarball I used was 1.5.3) and it worked. Oh, well, I'll just copy over the files. 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: > 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] vdr-1.5.7-1.5.8.diff problems?
En/na Udo Richter ha escrit: > Luca Olivetti wrote: >> The diff fails on all po files, it's only me or does it happens to others? > > po files are a pain for diff-patches because they have lists of source > code line numbers in the comments. If you've applied any other patch to > the VDR sources, and did a recompile, then all your po files will have > lots of changed line numbers. Ah, ok, that's surely it. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-actuator-1.1.0 plugin
Hello, I'm releasing version 1.1.0 of the "actuator" plugin available at http://www.ventoso.org/luca/vdr/ This plugin controls a linear actuator (or an horizon to horizon one) through the parallel port with a simple circuit. The only change is the adaptation to the new translation method, so it only works with vdr 1.5.8 (not 1.5.7 since the name of the mo file has changed) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] locale names, patch for large localedirs
Hi!
Very nice to see gettext() working, for a while I thought it was going
to be a complete mess :)
IMHO, two simple things could still be done:
Attached is a simple patch that allows using VDR with large localedir
that contains more locales than I18N_MAX_LANGUAGES. AFAICS there is no
reason to stop searching unless I18N_MAX_LANGUAGES vdr locales were
actually found.
Also, it is a convention (all programs in my system follow it) that .po
files (and thus the locale directory name) be without the territory
name, i.e. fi instead of fi_FI. If there would be any additional
translations for some language, they would be named like fi_DE.
--
Anssi Hannula
Index: vdr-1.5.8/i18n.c
===
--- vdr-1.5.8/i18n.c
+++ vdr-1.5.8/i18n.c 2007-08-19 18:38:54.0 +0300
@@ -112,7 +112,7 @@
for (int i = 0; i < Locales.Size(); 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) {
+if (NumLocales < I18N_MAX_LANGUAGES) {
SetEnvLanguage(Locales[i]);
NumLocales++;
if (strstr(OldLocale, Locales[i]) == OldLocale)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] locale names, patch for large localedirs
On 08/19/07 17:56, Anssi Hannula wrote: > Hi! > > Very nice to see gettext() working, for a while I thought it was going > to be a complete mess :) > > IMHO, two simple things could still be done: > > Attached is a simple patch that allows using VDR with large localedir > that contains more locales than I18N_MAX_LANGUAGES. AFAICS there is no > reason to stop searching unless I18N_MAX_LANGUAGES vdr locales were > actually found. You're right about that. > Also, it is a convention (all programs in my system follow it) that .po > files (and thus the locale directory name) be without the territory > name, i.e. fi instead of fi_FI. If there would be any additional > translations for some language, they would be named like fi_DE. The source .po files will remain named as they are now. In an "install" target you can rename them to whatever you like. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.8
Klaus Schmidinger wrote: - When scanning the locale directory, VDR now explicitly looks for a file named vdr.mo. Text files for plugins are now named "vdr-name.mo", when "name" is the name of the plugin. The "newplugin" script has been changed accordingly, and plugin authors should change their Makefiles, too. Ouch, here we go again. Hopefully this is the last name change. The attached patch handles this in a way that is compatible with 1.5.7 and 1.5.8, and it should apply to most plugins that have been updated for 1.5.7 already, restoring i18n functionality for 1.5.8. Cheers, Udo Index: Makefile === --- Makefile(Revision 955) +++ Makefile(Arbeitskopie) @@ -88,6 +88,10 @@ I18Nmo= $(addsuffix .mo, $(foreach file, $(I18Npo), $(basename $(file I18Ndirs = $(notdir $(foreach file, $(I18Npo), $(basename $(file I18Npot = $(PODIR)/$(PLUGIN).pot +I18Nvdrmo = vdr-$(PLUGIN).mo +ifeq ($(strip $(APIVERSION)),1.5.7) + I18Nvdrmo = $(PLUGIN).mo +endif %.mo: %.po msgfmt -c -o $@ $< @@ -102,7 +106,7 @@ @mkdir -p $(LOCALEDIR) for i in $(I18Ndirs); do\ mkdir -p $(LOCALEDIR)/$$i/LC_MESSAGES;\ - cp $(PODIR)/$$i.mo $(LOCALEDIR)/$$i/LC_MESSAGES/$(PLUGIN).mo;\ + cp $(PODIR)/$$i.mo $(LOCALEDIR)/$$i/LC_MESSAGES/$(I18Nvdrmo);\ done ### Targets: ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
Udo Richter wrote: > Luca Olivetti wrote: >> The diff fails on all po files, it's only me or does it happens to others? > > po files are a pain for diff-patches because they have lists of source > code line numbers in the comments. If you've applied any other patch to > the VDR sources, and did a recompile, then all your po files will have > lots of changed line numbers. Maybe they should not be regenerated during compiling, but have a separate make target for that? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
On 08/19/07 18:07, Anssi Hannula wrote: > Udo Richter wrote: >> Luca Olivetti wrote: >>> The diff fails on all po files, it's only me or does it happens to others? >> po files are a pain for diff-patches because they have lists of source >> code line numbers in the comments. If you've applied any other patch to >> the VDR sources, and did a recompile, then all your po files will have >> lots of changed line numbers. > > Maybe they should not be regenerated during compiling, but have a > separate make target for that? Like this? i18n: $(I18Nmo) @mkdir -p $(LOCALEDIR) for i in $(I18Ndirs); do\ mkdir -p $(LOCALEDIR)/$$i/LC_MESSAGES;\ cp $(PODIR)/$$i.mo $(LOCALEDIR)/$$i/LC_MESSAGES/vdr.mo;\ done ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] po2i18n - converter for plugin backwards compatibility
Dieter Hametner wrote: > I kind of enhanced your script to use the CPAN module Locale::PO for reading > the .po/.pot files. Your implementation did not handle multi line msgids and > msgstrs well. Hmmm, ok, I don't have multi-line strings that need translation, but this is probably worth a fix. But I don't really want to depend on Locale::PO, as it is not very likely to be installed on systems out there. > My change adds all strings in the plugins .pot file to the resulting i18n.c > file, even when no translation exists for the string and it does not sort the > msgids. Since all po files get updated too all the time, reading the pot file is not really necessary. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
Klaus Schmidinger wrote: > On 08/19/07 18:07, Anssi Hannula wrote: >> Udo Richter wrote: >>> Luca Olivetti wrote: The diff fails on all po files, it's only me or does it happens to others? >>> po files are a pain for diff-patches because they have lists of source >>> code line numbers in the comments. If you've applied any other patch to >>> the VDR sources, and did a recompile, then all your po files will have >>> lots of changed line numbers. >> Maybe they should not be regenerated during compiling, but have a >> separate make target for that? > > Like this? > > i18n: $(I18Nmo) > @mkdir -p $(LOCALEDIR) > for i in $(I18Ndirs); do\ > mkdir -p $(LOCALEDIR)/$$i/LC_MESSAGES;\ > cp $(PODIR)/$$i.mo $(LOCALEDIR)/$$i/LC_MESSAGES/vdr.mo;\ > done > > ;-) Not really. I mean't a separate target for running "xgettext" and "msgmerge", as they are only needed to be run by developers, and cause patch conflicts as Udo noted. Only "msgfmt" and the copying of the files needs to be done when the user compiles VDR. I checked few other random projects, and they use a make target "update-po" for running xgettext and msgmerge, which is not done by default. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] po2i18n - converter for plugi n backwards compatibility
Hi
Am Sonntag, 19. August 2007 schrieb Udo Richter:
> Dieter Hametner wrote:
> > I kind of enhanced your script to use the CPAN module Locale::PO for
> > reading the .po/.pot files. Your implementation did not handle multi line
> > msgids and msgstrs well.
>
> Hmmm, ok, I don't have multi-line strings that need translation, but
> this is probably worth a fix.
> But I don't really want to depend on Locale::PO, as it is not very
> likely to be installed on systems out there.
I'm aware of that. Debian sid has also an outdated package for it
('liblocale-po-perl' version 0.15 where as in CPAN it is version 0.17).
Still I think building on others work is one of the spirits of open source :)
>
> > My change adds all strings in the plugins .pot file to the resulting
> > i18n.c file, even when no translation exists for the string and it does
> > not sort the msgids.
>
> Since all po files get updated too all the time, reading the pot file is
> not really necessary.
With the Locale::PO package I needed a file where I would know of, that all
possible strings appear because the single .po files don't get merged
together.
Regards
Dieter
--
Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de
live plugin developer http://live.vdr-developer.org
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Locales not working by default when running from source tree
Before one could just run "make" and after that you could just run ./vdr. However, now LOCDIR is set to $(PREFIX)/share/vdr/locale by default, which causes localisation to not work unless "make install-i18n" (or "make install" which runs it as well) is run, which copies the locale files to LOCDIR. However, almost exactly the opposite is the case with PLUGINLIBDIR, which by default is ./PLUGINS/lib so that it works inside the source-tree, but it is not so good if installed into /usr/local. AFAICS this is inconsistent. I think either VDR should work out-of-the-box (without modifying make variables) inside the source tree *or* out of the source tree. I.e. LOCDIR should be changed to "./locale" or PLUGINLIBDIR should be changed "$(PREFIX)/lib/vdr" or similar. Or make the i18n.c work with locales being either in LOCDIR or ./locale. It doesn't really matter to me, but for some other users the current state might be confusing. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-femon-1.2.1, vdr-rssreader-1.1.1, vdr-skinsoppalusikka-1.1.1
Hi again, new versions of femon, rssreader, and skinsoppalusikka plugins are now available with full support for vdr-1.5.8: http://www.saunalahti.fi/~rahrenbe/vdr/femon/ http://www.saunalahti.fi/~rahrenbe/vdr/rssreader/ http://www.saunalahti.fi/~rahrenbe/vdr/soppalusikka/ BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Diablo CAM and VDR 1.4.7: unknown session id: 0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I have a problem with my Diablo CAM Modul. When I try to open the CAM Menu, vdr say, it open the menu. After ~ 3 sec. nothing is open and I can press OK and the channel info are displayed. In the logfile I found this: Aug 19 18:06:22 vdr vdr: [13306] warning: CAM-Menü wird geöffnet... Aug 19 18:06:22 vdr vdr: [13622] too many different colors used in palette Aug 19 18:06:25 vdr vdr: [13306] ERROR: unknown session id: 0 Aug 19 18:06:25 vdr vdr: [13306] ERROR: can't create session for resource identifier: 00400041 Aug 19 18:06:26 vdr vdr: [13306] ERROR: unknown session id: 0 I searched in the sources and found where the messages was produced, but i dont know how i can debug this: i think, the first "unknown sessin id" message comes from bool cCiHandler::Process(int Slot) the "can't create session for resource identifier" is triggert in bool cCiHandler::OpenSession(int Length, const uint8_t *Data) and the last "unknown sessin id" message is (i think) from bool cCiHandler::CloseSession(uint16_t SessionId) Can someone help me? Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGyJFtryk5AcCKK8ERAm6GAKCFfqIe5RGwF82OoNCTRH93lD9F/ACgmd5r il8c4gh3OGS2z/fvzqJn4h8= =X2iF -END PGP SIGNATURE- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Locales not working by default when running from source tree
On 8/19/07, Anssi Hannula <[EMAIL PROTECTED]> wrote: > However, almost exactly the opposite is the case with PLUGINLIBDIR, > which by default is ./PLUGINS/lib so that it works inside the > source-tree, but it is not so good if installed into /usr/local. I've already seen this problem for people who install vdr. People seem to expect that vdr is installed to /usr/local/bin while plugins go to /usr/local/bin/PLUGINS/lib. The current Makefile puts: vdr to $(DESTDIR)$(BINDIR), plugins to $(DESTDIR)$(PLUGINLIBDIR), with DESTDIR empty by default. ok.. so vdr goes in /usr/local/bin, as expected.. but plugins go in ./PLUGINS/lib.. Again, the most common expected behavior that I see from users is that vdr be installed to $(BINDIR) and plugins installed to $(BINDIR)/$(PLUGINLIBDIR). vdr in /usr/local/bin, plugins in /usr/local/bin/PLUGINS/lib. Also, when cleaning plugins, shouldn't ALL copies be cleaned? Why would you clean plugins binaries from ./PLUGINS/lib but not from your install path is as well? In the previous example, /usr/local/bin/PLUGINS/lib.. It seems fitting & expected to: @-rm -f $(BINDIR)/$(PLUGINLIBDIR)/*.so.$(APIVERSION) Just my observations... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] R: [PATCH]: VDR & Multiple frontends (finished)
Hi, Klaus, any news about support for multiple frontends? What about integrating my patch in 1.5.x? Regards, Eddi > -Messaggio originale- > Da: eddi at depieri.net (Eddi) [mailto:eddi at depieri.net (Eddi)] > Inviato: 24 February 2007 12:48 > Oggetto: [PATCH]: [vdr] VDR & Multiple frontends (finished) > > The patch that enable multiple frontend with shared bus, should be > finished > and on my pc it seems to be stable enough. > > http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple- > frontend_v5 > .patch > > Now the patch don't switch frontend, is recording in progress. > > Best Regards, > > Eddi > > > > -Messaggio originale- > > Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto > di > > Eddi > > Inviato: sabato 10 febbraio 2007 11.17 > > A: 'VDR Mailing List' > > Oggetto: R: [PATCH]: [vdr] VDR & Multiple frontends, another try > > > > Hi, I've made another patch to vdr 1.4.5. > > > > Now I have used your suggestion, and the patch seems to be stable. > > > > http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple- > > frontend_v2 > > .patch > > > > At the moment I've tested it only with live view. > > > > Klaus, please look at this patch again and tell me what do you think. > > > > However I'm sure that what I'm done can be optimized. > > > > Best regards > > > > Eddi > > > > > > > > > -Messaggio originale- > > > Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto > > di > > > Eddi > > > Inviato: venerd? 9 febbraio 2007 14.28 > > > A: 'VDR Mailing List' > > > Oggetto: R: [PATCH]: [vdr] VDR & Multiple frontends > > > > > > Ok, I hope that what I have done, may describe the algorithm that I > > think > > > may be necessary to get multiple frontend working. > > > I know that the solution I choose are not the best and right, I'm not > a > > > c++ > > > programmer! > > > > > > The only solution I found to close all file descriptors and > > > /dev/dvb/adapter0/frontend0 was to add the close fd_frontend to the > dvb > > > device destructor. > > > > > > Eddi > > > > > > > -Messaggio originale- > > > > Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per > conto > > > di > > > > Klaus Schmidinger > > > > Inviato: venerd? 9 febbraio 2007 13.43 > > > > A: vdr@linuxtv.org > > > > Oggetto: Re: [PATCH]: [vdr] VDR & Multiple frontends > > > > > > > > Eddi wrote: > > > > > So what do you think should be the right way? > > > > > > > > I haven't decided yet how to do that. > > > > > > > > I just wanted to let you know that deleting the cDvbDevice > > > > is not the way to go - especially if you delete it from within > > > > one of its own member functions ;-) It's no wonder your patched > > > > version fails it you saw off the branch you're sitting on. > > > > > > > > Klaus > > > > > > > > >> -Messaggio originale- > > > > >> Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per > > > conto > > > > di > > > > >> Klaus Schmidinger > > > > >> Inviato: venerd? 9 febbraio 2007 8.27 > > > > >> A: vdr@linuxtv.org > > > > >> Oggetto: Re: R: [PATCH] R: R: [vdr] VDR & Multiple frontends > > > > >> > > > > >> Eddi wrote: > > > > >>> I need help > > > > >>> > > > > >>> This is why sometimes hangs after my patch... > > > > >>> > > > > >>> On ProvidesChannel I delete the cDvbDevice and i make it again. > > > > >> Deleting the cDvbDevice is definitely the wrong way to do this. > > > > >> > > > > >> Klaus > > > > > > > > ___ > > > > vdr mailing list > > > > vdr@linuxtv.org > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > > > > > > > ___ > > > vdr mailing list > > > vdr@linuxtv.org > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -- next part -- > A non-text attachment was scrubbed... > Name: vdr_1.4.5_eddi-multiple-frontend_v5.patch > Type: application/octet-stream > Size: 17338 bytes > Desc: not available > Url : > http://www.linuxtv.org/pipermail/vdr/attachments/20070224/3159743c/vdr_1.4 > .5_eddi-multiple-frontend_v5.obj > From Klaus.Schmidinger at cadsoft.de Sat Feb 24 14:03:33 2007 > From: Klaus.Schmidinger at cadsoft.de (Klaus Schmidinger) > Date: Sat Feb 24 14:04:32 2007 > Subject: [vdr] [ANNOUNCE] VDR maintenance patch 1.4.5-2 > Message-ID: <[EMAIL PROTECTED]> > > VDR maintenance patch 1.4.5-2 is now available at > > ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5-2.diff > > This is a 'diff' against version 1.4.5-1 (which is the official > version 1.4.5, patched with ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5- > 1.diff). > > > Small fixes to the officially released VDR versions will be first > made available as "maintenance patches" in the Developer directory, > so that they can be reviewed and tested before a new official > release is published. > > So please apply the above patch and report whether it works (or > if it causes any new problems). > > > This version is binary compatible to the
Re: [vdr] Locales not working by default when running from source tree
On 08/19/07 19:13, Anssi Hannula wrote: > Before one could just run "make" and after that you could just run > ./vdr. However, now LOCDIR is set to $(PREFIX)/share/vdr/locale by > default, which causes localisation to not work unless "make > install-i18n" (or "make install" which runs it as well) is run, which > copies the locale files to LOCDIR. > > However, almost exactly the opposite is the case with PLUGINLIBDIR, > which by default is ./PLUGINS/lib so that it works inside the > source-tree, but it is not so good if installed into /usr/local. > > AFAICS this is inconsistent. I think either VDR should work > out-of-the-box (without modifying make variables) inside the source tree > *or* out of the source tree. > > I.e. LOCDIR should be changed to "./locale" or PLUGINLIBDIR should be > changed "$(PREFIX)/lib/vdr" or similar. > > Or make the i18n.c work with locales being either in LOCDIR or ./locale. > > > It doesn't really matter to me, but for some other users the current > state might be confusing. You're right. When I started writing VDR, the idea was to have everything in one directory and also run it from there. No "install" or anything. Then came people who insisted in "installing" VDR, so the BINDIR etc. got in, which I didn't care about, because I just didn't do "make install". Later came the plugins, and that's when VDR actually needed to know where they are, so that's when PLUGINLIBDIR came in. I still didn't care about it, because the default was what I needed, namely ./PLUGINS. Now with gettext, VDR needed to know where the locale files are, so it can offer the user the list of supported languages. Somehow I made the mistake of making /usr/share/vdr/locale the default for this, not thinking about the confusion this apparently causes. (Actually /usr/share/vdr/locale should probably become /usr/share/locale with the latest changes in handling this stuff in version 1.5.8). Since I don't care the least bit about actually "installing" VDR, I should probably stay completely out of the "install" targets. Change them to whatever you like and agree on a common version here on the list (as a complete patch against the latest developer version). The only request I have is that it must be possible to unpack VDR into a directory and do make vdrto compile the vdr executable into this directory make i18n to build VDR's i18n files into ./locale make pluginsto compile all plugins under ./PLUGINS/src and have their *.so files end up in ./PLUGINS/lib, and also have their i18n files end up in ./locale make clean-plugins to clean up everything that 'make plugins' generated make clean to clean up everything that 'make vdr' or 'make i18n' created VDR must be runnable from within its source directory and must search for plugin files in ./PLUGINS/lib and for locale files in ./locale. If it is necessary to add something like LOCAL=1 to the make calls in order to achieve this, that's fine with me (this should, however, also be definable in Make.config - I don't want to have to add this every time I make VDR ;-). So you can make the default for PLUGINLIBDIR and LOCDIR point to whatever location you want (and good luck finding a consensus in these defaults ;-). If there shall be a way to remove what any "install" target has created, this shall be done in a "clean-install" or whatever target. I don't want 'make clean' to have anything to do with any "install" target. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] EnimgaNG Addon - anyone has a patch?
Hi, if i try to compile enigmaNG with VDR 1.5.8 i get the following errormessage: config.c: In member function 'const cFont* cEnigmaConfig::GetFont(int, const cFont*)': config.c:143: warning: format '%d' expects type 'int', but argument 6 has type 'char*' config.c:144: error: invalid conversion from 'char*' to 'int' config.c:144: error: initializing argument 4 of 'bool cGraphtftFont::Load(std::string, std::string, int, int, int, int)' make[1]: *** [config.o] Error 1 It's the CVS version checked out 2 minutes ago. Has anyone a running version for VDR 1.5.8? Best regards, Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] How to "reset" filesystem cache
Hi! I have system where there is "epgsearch" rule what records ALL news from tv-channels. Then I have crontab entry what deletes all news files what are older than 5 hours. When I go into list of "recorded" programs I can still see those deleted files (but of course length of program is unknown).. To get "reset" filesystem cache, I need to go (f.ex.) Plugins - xineliboutput - Audio and press there "Enter". Is there a way to do that "reset" for filesystem cache easier? -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to "reset" filesystem cache
On 8/19/07, JJussi <[EMAIL PROTECTED]> wrote: > Hi! > [..] > Is there a way to do that "reset" for filesystem cache easier? > Yes, cd YOUR_VIDEO_DIR touch .update 2004-06-19: Version 1.3.11 - The list of recordings is now kept statically in memory to avoid long delays when opening the "Recordings" menu. As a side effect, external modifications to the video directory are no longer immediately reflected in the "Recordings" menu. If a plugin manipulates the video directory in any way, it can call the function Recordings.TriggerUpdate() to trigger an update of the list of recordings. If some external tool manipulates the video directory, it can touch the file '.update' in the video directory to trigger an update of the list of recordings. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
