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
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.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. - Updated the Estonian OSD texts (thanks to Arthur Konovalov). - Fixed a problem with characters >0x7F in the modified version of skipspace() (thanks to Marco Schlüßler). - Fixed a bug I introduced when simplifying the original patch for detecting Premiere NVOD channel links (crash reported by Malte Schröder). - 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. - The three letter language codes and their aliases are stored in i18n.c, and each translation file only contains one of them to link that language name to the code. - The 'newplugin' script has been extended to generate the Makefile section for i18n support. - 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. - The list of tracks given in cStatus::SetAudioTrack() is now NULL terminated, so that plugins can actually use all the strings in the list, not just the one pointed to by Index (thanks to Alexander Rieger). - Fixed handling kLeft in the calls to cStatus::MsgOsdTextItem() (thanks to Alexander Rieger). - 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. - Fixed the link to the GPL2 at http://www.gnu.org in vdr.c (thanks to Ville Skyttä). - cBitmap::SetXpm() now checks whether the given Xpm pointer is not NULL, to avoid a crash with files that only contain "/* XPM */" (suggested by Andreas Mair). - Added a debug error message to cReceiver::~cReceiver() in case it is still attached to a device (thanks to Reinhard Nissl).
Have fun!
Klaus
On 8/12/07, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de 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.
On 8/12/07, Stone syphyr@gmail.com wrote:
Thanks Klaus. Since i18n.c has changed in this new version of vdr, a few common patches I have been using have broke.
- jumpplay-0.9.diff
- liemikuutio-1.13.diff
- 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. :)
2007/8/12, VDR User user.vdr@gmail.com:
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.
On 08/12/07 18:47, Jaroslaw Swierczynski wrote:
2007/8/12, VDR User user.vdr@gmail.com:
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
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. ;-)
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 User schrieb:
On 8/12/07, Stone syphyr@gmail.com wrote:
Thanks Klaus. Since i18n.c has changed in this new version of vdr, a few common patches I have been using have broke.
- jumpplay-0.9.diff
- liemikuutio-1.13.diff
- 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 ;)
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:
[vdr@vdr 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
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:
[vdr@vdr 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
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
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
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
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
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
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
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,
On 08/12/07 19:47, Patrick Cernko wrote:
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.
Ever so often I received error reports with log excerpts attached, and only after lengthy discussions it turned out that the log wasn't complete. Important information was written to other files, that were not attached to the message. That's why I decided to write all log messages into one place.
You can still control how much to log via the -l option.
Klaus
Hello,
a hint on VDRs makefile: is there a "install-i18n" missing at the install target?
Regards, Joachim.
2007/8/12, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:
VDR developer version 1.5.7 is now available [...]
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?
On 8/17/07, Anssi Hannula anssi.hannula@gmail.com 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! :)
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
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.
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
Klaus Schmidinger wrote:
On 08/18/07 10:32, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/17/07 15:48, Anssi Hannula wrote:
... show up as "deu,ger" etc, and do not work; text shows up in English despite selecting them.
Maybe the locales that the user does not have installed on their system should be hidden?
I thought that the language codes should always all be there, to allow selecting other preferred languages, even if there is no locale installed. But maybe I'm mistaken there.
Well, having those in the OSD language selection menu seems strange, if only two of those actually work, and others do not show up correctly ("deu,ger").
But indeed, the Audio and EPG language selection menus seem to use the same list. IMHO the Audio and EPG languages should use a separate list, that contains all the language names in the currently selected OSD language.
That would mean that every *.po file would have to contain the name of every other language, and for every new language that's added, all other *.po files would have to be extended.
Then they will be extended, I don't see the problem here.
Besides, if a user can't read a language name in the language's own writing, he/she probably won't understand that langauge, anyway ;-).
A good point. :) However, most languages are currently shown as language codes, not in the language's own writing.
Please try disabling the code after
// Prepare any known language codes for which there was no locale:
in i18n.c and see whether that would do what you expect.
Yes, the languages that have no "locales-XX" package installed on my system do not show up in the OSD language selection list anymore.
However, I cannot select them as EPG nor Audio language either, which should still be possible.
Please try the attached patch. It changes the "Setup/OSD/Language" menu to only show the languages that actually have a locale. Any other language menus display language names if present, three letter language codes otherwise.
Seems to work. However, I don't like the fact that only few languages are shown by their name, while others have only the language codes. Before they were all shown by their name.
On 08/18/07 11:38, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/18/07 10:32, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/17/07 15:48, Anssi Hannula wrote:
... show up as "deu,ger" etc, and do not work; text shows up in English despite selecting them.
Maybe the locales that the user does not have installed on their system should be hidden?
I thought that the language codes should always all be there, to allow selecting other preferred languages, even if there is no locale installed. But maybe I'm mistaken there.
Well, having those in the OSD language selection menu seems strange, if only two of those actually work, and others do not show up correctly ("deu,ger").
But indeed, the Audio and EPG language selection menus seem to use the same list. IMHO the Audio and EPG languages should use a separate list, that contains all the language names in the currently selected OSD language.
That would mean that every *.po file would have to contain the name of every other language, and for every new language that's added, all other *.po files would have to be extended.
Then they will be extended, I don't see the problem here.
Besides, if a user can't read a language name in the language's own writing, he/she probably won't understand that langauge, anyway ;-).
A good point. :) However, most languages are currently shown as language codes, not in the language's own writing.
Where should that "language's own writing" come from, if not from a *.mo file for that language?
Please try disabling the code after
// Prepare any known language codes for which there was no locale:
in i18n.c and see whether that would do what you expect.
Yes, the languages that have no "locales-XX" package installed on my system do not show up in the OSD language selection list anymore.
However, I cannot select them as EPG nor Audio language either, which should still be possible.
Please try the attached patch. It changes the "Setup/OSD/Language" menu to only show the languages that actually have a locale. Any other language menus display language names if present, three letter language codes otherwise.
Seems to work. However, I don't like the fact that only few languages are shown by their name, while others have only the language codes. Before they were all shown by their name.
The *.mo files for VDR's languages are all there - I don't know why setlocale()/gettext() doesn't deliver translations if the locale isn't "installed".
VDR searches its locale directory for any locales that come with VDR, and calls setlocale() with them. If gettext() then doesn't return any translations, what do you suggest VDR should do?
If you want to see all languages, maybe you just have to "install" all locales?
Klaus
Klaus Schmidinger wrote:
On 08/18/07 11:38, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/18/07 10:32, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/17/07 15:48, Anssi Hannula wrote:
... show up as "deu,ger" etc, and do not work; text shows up in English despite selecting them.
Maybe the locales that the user does not have installed on their system should be hidden?
I thought that the language codes should always all be there, to allow selecting other preferred languages, even if there is no locale installed. But maybe I'm mistaken there.
Well, having those in the OSD language selection menu seems strange, if only two of those actually work, and others do not show up correctly ("deu,ger").
But indeed, the Audio and EPG language selection menus seem to use the same list. IMHO the Audio and EPG languages should use a separate list, that contains all the language names in the currently selected OSD language.
That would mean that every *.po file would have to contain the name of every other language, and for every new language that's added, all other *.po files would have to be extended.
Then they will be extended, I don't see the problem here.
Besides, if a user can't read a language name in the language's own writing, he/she probably won't understand that langauge, anyway ;-).
A good point. :) However, most languages are currently shown as language codes, not in the language's own writing.
Where should that "language's own writing" come from, if not from a *.mo file for that language?
A custom table? (If you do not want to start translating the language names to all languages)
Abusing setlocale() and gettext() to grab a language name from other *.mo files seems wrong to me.
Please try disabling the code after
// Prepare any known language codes for which there was no locale:
in i18n.c and see whether that would do what you expect.
Yes, the languages that have no "locales-XX" package installed on my system do not show up in the OSD language selection list anymore.
However, I cannot select them as EPG nor Audio language either, which should still be possible.
Please try the attached patch. It changes the "Setup/OSD/Language" menu to only show the languages that actually have a locale. Any other language menus display language names if present, three letter language codes otherwise.
Seems to work. However, I don't like the fact that only few languages are shown by their name, while others have only the language codes. Before they were all shown by their name.
The *.mo files for VDR's languages are all there - I don't know why setlocale()/gettext() doesn't deliver translations if the locale isn't "installed".
VDR searches its locale directory for any locales that come with VDR, and calls setlocale() with them. If gettext() then doesn't return any translations, what do you suggest VDR should do?
If you want to see all languages, maybe you just have to "install" all locales?
Unreasonable for just the language names. I suggest to use a table.
On 08/18/07 12:28, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/18/07 11:38, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/18/07 10:32, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/17/07 15:48, Anssi Hannula wrote: > ... > show up as "deu,ger" etc, and do not work; text shows up in English > despite selecting them. > > Maybe the locales that the user does not have installed on their system > should be hidden? I thought that the language codes should always all be there, to allow selecting other preferred languages, even if there is no locale installed. But maybe I'm mistaken there.
Well, having those in the OSD language selection menu seems strange, if only two of those actually work, and others do not show up correctly ("deu,ger").
But indeed, the Audio and EPG language selection menus seem to use the same list. IMHO the Audio and EPG languages should use a separate list, that contains all the language names in the currently selected OSD language.
That would mean that every *.po file would have to contain the name of every other language, and for every new language that's added, all other *.po files would have to be extended.
Then they will be extended, I don't see the problem here.
Besides, if a user can't read a language name in the language's own writing, he/she probably won't understand that langauge, anyway ;-).
A good point. :) However, most languages are currently shown as language codes, not in the language's own writing.
Where should that "language's own writing" come from, if not from a *.mo file for that language?
A custom table? (If you do not want to start translating the language names to all languages)
Abusing setlocale() and gettext() to grab a language name from other *.mo files seems wrong to me.
Please try disabling the code after
// Prepare any known language codes for which there was no locale:
in i18n.c and see whether that would do what you expect.
Yes, the languages that have no "locales-XX" package installed on my system do not show up in the OSD language selection list anymore.
However, I cannot select them as EPG nor Audio language either, which should still be possible.
Please try the attached patch. It changes the "Setup/OSD/Language" menu to only show the languages that actually have a locale. Any other language menus display language names if present, three letter language codes otherwise.
Seems to work. However, I don't like the fact that only few languages are shown by their name, while others have only the language codes. Before they were all shown by their name.
The *.mo files for VDR's languages are all there - I don't know why setlocale()/gettext() doesn't deliver translations if the locale isn't "installed".
VDR searches its locale directory for any locales that come with VDR, and calls setlocale() with them. If gettext() then doesn't return any translations, what do you suggest VDR should do?
If you want to see all languages, maybe you just have to "install" all locales?
Unreasonable for just the language names. I suggest to use a table.
That would mean that there is again something in VDR's core code that has to be maintained by various translators - I'm glad I got the i18n stuff out of the core code, and I wouldn't want to go back again.
If you want to see all languages in their native wording, I guess that means you'll have to install all locales. Or, suggest a way to allow VDR to use setlocale/gettext without the need for the locales to actually be installed. VDR has all its text files available and only needs a way to have gettext() use them. This is currently done by calling setlocale() - maybe there's an other way?
Klaus
Klaus Schmidinger wrote:
On 08/18/07 12:28, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/18/07 11:38, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/18/07 10:32, Anssi Hannula wrote:
Klaus Schmidinger wrote: > On 08/17/07 15:48, Anssi Hannula wrote: >> ... >> show up as "deu,ger" etc, and do not work; text shows up in English >> despite selecting them. >> >> Maybe the locales that the user does not have installed on their system >> should be hidden? > I thought that the language codes should always all be there, > to allow selecting other preferred languages, even if there > is no locale installed. But maybe I'm mistaken there. Well, having those in the OSD language selection menu seems strange, if only two of those actually work, and others do not show up correctly ("deu,ger").
But indeed, the Audio and EPG language selection menus seem to use the same list. IMHO the Audio and EPG languages should use a separate list, that contains all the language names in the currently selected OSD language.
That would mean that every *.po file would have to contain the name of every other language, and for every new language that's added, all other *.po files would have to be extended.
Then they will be extended, I don't see the problem here.
Besides, if a user can't read a language name in the language's own writing, he/she probably won't understand that langauge, anyway ;-).
A good point. :) However, most languages are currently shown as language codes, not in the language's own writing.
Where should that "language's own writing" come from, if not from a *.mo file for that language?
A custom table? (If you do not want to start translating the language names to all languages)
Abusing setlocale() and gettext() to grab a language name from other *.mo files seems wrong to me.
> Please try disabling the code after > > // Prepare any known language codes for which there was no locale: > > in i18n.c and see whether that would do what you expect. Yes, the languages that have no "locales-XX" package installed on my system do not show up in the OSD language selection list anymore.
However, I cannot select them as EPG nor Audio language either, which should still be possible.
Please try the attached patch. It changes the "Setup/OSD/Language" menu to only show the languages that actually have a locale. Any other language menus display language names if present, three letter language codes otherwise.
Seems to work. However, I don't like the fact that only few languages are shown by their name, while others have only the language codes. Before they were all shown by their name.
The *.mo files for VDR's languages are all there - I don't know why setlocale()/gettext() doesn't deliver translations if the locale isn't "installed".
VDR searches its locale directory for any locales that come with VDR, and calls setlocale() with them. If gettext() then doesn't return any translations, what do you suggest VDR should do?
If you want to see all languages, maybe you just have to "install" all locales?
Unreasonable for just the language names. I suggest to use a table.
That would mean that there is again something in VDR's core code that has to be maintained by various translators - I'm glad I got the i18n stuff out of the core code, and I wouldn't want to go back again.
I don't consider maintaining a single table for language names (either native, or English with translations to all langs in .mo files) a problem.
If you want to see all languages in their native wording, I guess that means you'll have to install all locales. Or, suggest a way to allow VDR to use setlocale/gettext without the need for the locales to actually be installed. VDR has all its text files available and only needs a way to have gettext() use them. This is currently done by calling setlocale() - maybe there's an other way?
I'm not aware of such a way.
On Samstag, 18. August 2007, Klaus Schmidinger wrote:
That would mean that every *.po file would have to contain the name of every other language, and for every new language that's added, all other *.po files would have to be extended.
the debian package iso-codes contains all ISO 639 language codes with translations, so you could use those.
The muggle plugin uses this to display the language of the audio file in the vdr OSD language.
You should use at least version iso-codes 0.47-2 (Aug 2005), older versions were missing german translations for most european languages.
from muggle, vdr_actions.c:
dgettext("iso_639",item->value().c_str())
where the 2nd arg is the english language name AFAIR
Wolfgang Rohdewald wrote:
On Samstag, 18. August 2007, Klaus Schmidinger wrote:
That would mean that every *.po file would have to contain the name of every other language, and for every new language that's added, all other *.po files would have to be extended.
the debian package iso-codes contains all ISO 639 language codes with translations, so you could use those.
And an URL: http://pkg-isocodes.alioth.debian.org/
The muggle plugin uses this to display the language of the audio file in the vdr OSD language.
You should use at least version iso-codes 0.47-2 (Aug 2005), older versions were missing german translations for most european languages.
from muggle, vdr_actions.c:
dgettext("iso_639",item->value().c_str())
where the 2nd arg is the english language name AFAIR
Seems like a good solution to me.
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 LANG=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL=
#>locale -a C de_DE@euro de_DE.iso885915@euro 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)... de_DE.ISO-8859-15@euro... done de_DE.ISO-8859-1... done Generation complete.
#>locale -a C de_DE de_DE@euro de_DE.iso88591 de_DE.iso885915@euro 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
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 LANG=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL= #>locale -a C de_DE@euro de_DE.iso885915@euro POSIXThis 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)... de_DE.ISO-8859-15@euro... done de_DE.ISO-8859-1... done Generation complete. #>locale -a C de_DE de_DE@euro de_DE.iso88591 de_DE.iso885915@euro 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
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 "de_DE@euro" string.
There must be some way how this is supposed to work. Even if my locale is set to de_DE@euro 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 de_DE@euro down to de_DE and de.
Cheers,
Udo
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 "de_DE@euro" string.
There must be some way how this is supposed to work. Even if my locale is set to de_DE@euro 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 de_DE@euro 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.
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 "de_DE@euro" string.
There must be some way how this is supposed to work. Even if my locale is set to de_DE@euro 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 de_DE@euro 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/de_DE@euro/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
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 "de_DE@euro" string.
There must be some way how this is supposed to work. Even if my locale is set to de_DE@euro 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 de_DE@euro 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 de_DE@euro and de_DE.iso885915@euro 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/de_DE@euro/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 de[_territory][.codeset][@modifier].
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).
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, de_DE@euro 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
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, de_DE@euro 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.
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, de_DE@euro 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
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, de_DE@euro 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.
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 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 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 samecatalog. 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! :)
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 samecatalog. 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
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
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
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 samecatalog. 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
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
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
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
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
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:10000/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
-
Anssi Hannula -
Darren Salt -
Jaroslaw Swierczynski -
Joachim Wilke -
Klaus Schmidinger -
Luca Olivetti -
Ludwig Nussel -
Oliver Endriss -
Patrick Cernko -
Steffen Barszus -
Stone -
Udo Richter -
VDR User -
Wolfgang Rohdewald