Hi,
I'd like to propose a patch for further i18n of VDR, namely in the commands.conf and reccmds.conf files. Even if any user can customize these files to his whishes (and language), I think that it is more consistent from the VDR user interface point of view if the commands defined there also change their language on the OSD, according to the OSD language setting. All that the user has to do, is to provide, additionally to the "normal" files commands.conf and reccmds.conf, the version(s) in the language(s) he want's to use as commands.conf.xyz and reccmds.conf.xyz, where ".xyz" is the 3-characters language code defined in VDR's i18n.c:
// The 3-letter names of the language... { "eng,dos", "deu,ger", "slv,slo", "ita", "dut,nla,nld", "por", "fra,fre", "nor", "fin,smi", "pol", "esl,spa", "ell,gre", "sve,swe", "rom,rum", "hun", "cat,cln", "rus", "hrv", "est", "dan", },
Important notes: - There is *no problem* if VDR does not find such translated command files at startup or at OSD language switching on the fly, it will always fall back to the default and if those are missing, as you already know, it's not a big deal either, so the behaviour doesn't change (except that there is a syslog message if such a customized file hasn't been found, just to inform users who are reading the logs, that *they could have* multiple command file versions according to configured OSD language, for english setups it#s absolutely silent as before); - this will only work with the *first* name for languages where multiple 3-letter names are defined; - As english is all over in VDR's source code specially treated, this makes no exception here, so it's indeed treated specially: english files need *no* such 3-letter extension, and are *only* loaded in their default form.
Have phun, Lucian
diff -Naur vdr-1.3.36_orig/config.c vdr-1.3.36/config.c --- vdr-1.3.36_orig/config.c 2005-09-09 17:08:59.000000000 +0200 +++ vdr-1.3.36/config.c 2005-11-14 13:19:45.010000000 +0100 @@ -16,6 +16,8 @@ #include "plugin.h" #include "recording.h"
+const char *ConfigDirectory = NULL; + // IMPORTANT NOTE: in the 'sscanf()' calls there is a blank after the '%d' // format characters in order to allow any number of blanks after a numeric // value! @@ -535,3 +537,31 @@ } return false; } + +bool LoadCommandsI18n(cCommands & cmds, const char *FileName, bool AllowComments, bool MustExist) +{ + bool bRet = true; + bool bLoadDefault = (Setup.OSDLanguage == 0); + if (!bLoadDefault) { + // attempt to load a translated file + char LangCode[4]; + strncpy(LangCode, I18nLanguageCode(Setup.OSDLanguage), 3); + LangCode[3] = '\0'; + char *FullPath = NULL; + asprintf(&FullPath, "%s/%s.%s", ConfigDirectory && *ConfigDirectory ? ConfigDirectory : ".", FileName, LangCode); + + if (!cmds.Load((FullPath), AllowComments, true)) { // require to exist, just to be able to log + // fallback + bLoadDefault = true; + esyslog("Failed to load translated '%s.%s' for language %d (%s)", FileName, LangCode, Setup.OSDLanguage, I18nLanguages()[Setup.OSDLanguage]); + esyslog("Falling back to default '%s' (if any)", FileName); + } + free(FullPath); + } + if (bLoadDefault) { + // let's do it the normal way + bRet = cmds.Load(AddDirectory(ConfigDirectory, FileName), AllowComments, MustExist); + } + // return status only for the default commands file + return bRet; +} diff -Naur vdr-1.3.36_orig/config.h vdr-1.3.36/config.h --- vdr-1.3.36_orig/config.h 2005-11-04 16:55:05.000000000 +0100 +++ vdr-1.3.36/config.h 2005-11-14 13:16:13.170000000 +0100 @@ -34,6 +34,8 @@ #define MaxSkinName 16 #define MaxThemeName 16
+extern const char *ConfigDirectory; + class cCommand : public cListObject { private: char *title; @@ -265,4 +267,6 @@
extern cSetup Setup;
+bool LoadCommandsI18n(cCommands & cmds, const char *FileName = NULL, bool AllowComments = false, bool MustExist = false); + #endif //__CONFIG_H diff -Naur vdr-1.3.36_orig/menu.c vdr-1.3.36/menu.c --- vdr-1.3.36_orig/menu.c 2005-11-05 18:29:22.000000000 +0100 +++ vdr-1.3.36/menu.c 2005-11-14 13:21:47.450000000 +0100 @@ -1910,6 +1910,10 @@ Setup.OSDLanguage = data.OSDLanguage; cFont::SetCode(I18nCharSets()[Setup.OSDLanguage]);
+ // try to load translated command files if available, otherwise fallback to defaults + LoadCommandsI18n(Commands, "commands.conf", true); + LoadCommandsI18n(RecordingCommands, "reccmds.conf", true); + cSkin *Skin = Skins.Get(skinIndex); if (Skin) { char *d = themes.NumThemes() ? strdup(themes.Descriptions()[themeIndex]) : NULL; diff -Naur vdr-1.3.36_orig/vdr.c vdr-1.3.36/vdr.c --- vdr-1.3.36_orig/vdr.c 2005-11-04 14:48:39.000000000 +0100 +++ vdr-1.3.36/vdr.c 2005-11-14 13:21:32.700000000 +0100 @@ -109,7 +109,6 @@
int SVDRPport = DEFAULTSVDRPPORT; const char *AudioCommand = NULL; - const char *ConfigDirectory = NULL; const char *EpgDataFileName = DEFAULTEPGDATAFILENAME; bool DisplayHelp = false; bool DisplayVersion = false; @@ -420,8 +419,9 @@ Diseqcs.Load(AddDirectory(ConfigDirectory, "diseqc.conf"), true, Setup.DiSEqC) && Channels.Load(AddDirectory(ConfigDirectory, "channels.conf"), false, true) && Timers.Load(AddDirectory(ConfigDirectory, "timers.conf")) && - Commands.Load(AddDirectory(ConfigDirectory, "commands.conf"), true) && - RecordingCommands.Load(AddDirectory(ConfigDirectory, "reccmds.conf"), true) && + // try to load translated command files if available, otherwise fallback to defaults + LoadCommandsI18n(Commands, "commands.conf", true) && + LoadCommandsI18n(RecordingCommands, "reccmds.conf", true) && SVDRPhosts.Load(AddDirectory(ConfigDirectory, "svdrphosts.conf"), true) && CaDefinitions.Load(AddDirectory(ConfigDirectory, "ca.conf"), true) && Keys.Load(AddDirectory(ConfigDirectory, "remote.conf")) &&
Lucian Muresan wrote:
Hi,
I'd like to propose a patch for further i18n of VDR, namely in the commands.conf and reccmds.conf files. Even if any user can customize these files to his whishes (and language), I think that it is more consistent from the VDR user interface point of view if the commands defined there also change their language on the OSD, according to the OSD language setting...
The commands files are typically written by the specific users themselves, so I would assume they write these in _their_ language and that's it.
I don't think that this feature is necessary, it only makes things needlessly complex, because then you would have to maintain numerous copies of your commands files, and any changes you make would have to be done in several files instead of a single place.
Klaus
Am Montag, 14. November 2005 17:24 schrieb Klaus Schmidinger:
Lucian Muresan wrote:
Hi,
I'd like to propose a patch for further i18n of VDR, namely in the commands.conf and reccmds.conf files. Even if any user can customize these files to his whishes (and language), I think that it is more consistent from the VDR user interface point of view if the commands defined there also change their language on the OSD, according to the OSD language setting...
The commands files are typically written by the specific users themselves, so I would assume they write these in _their_ language and that's it.
I don't agree. In many cases these files are written by a distribution maintainer, so it is neccessary to have everything in vdr translated. But maintaining 20 files that all have the same functionality will be a pain...
regards, Thiemo
Klaus Schmidinger wrote:
Lucian Muresan wrote:
Hi,
I'd like to propose a patch for further i18n of VDR, namely in the commands.conf and reccmds.conf files. Even if any user can customize these files to his whishes (and language), I think that it is more consistent from the VDR user interface point of view if the commands defined there also change their language on the OSD, according to the OSD language setting...
The commands files are typically written by the specific users themselves, so I would assume they write these in _their_ language and that's it.
I don't think that this feature is necessary, it only makes things needlessly complex, because then you would have to maintain numerous copies of your commands files, and any changes you make would have to be done in several files instead of a single place.
Taking out the syslog stuff from the patch would really keep everything transparent to users who don't use to switch OSD languages, they can continue to use the normal commands.conf and reccmds.conf for the language _they_ wish and never change the OSD language setting if they don't need or want to, so they really do not have to maintain numerous copies of those files, just their (either with, or without the 3-letter language name, as the one without is used anyway as a fallback).
But some users do switch from time to time the OSD language , that was the whole point, not to bother users who don't want to change their habits, having them write and maintain multiple files, but only providing the posibility for those who need it. Those even wouldn't have to maintain 17 languages, maybe only one or very few.
For example, I have to switch them mainly because VDR lacks UTF-8 support, not because I wouldn't come along with english or german OSD, I do not need the OSD in romanian for anything else than having displayed EPG information (and names derived from it in recordings, DVD archives) in the correct character encoding.
And I am also curious what's so complex about that patch, it only extends the i18n scheme (you're doing in fact the same too, try to translate the standard english string into the specified language if available, if not, leave it as it is but also log that "no translation found" message) to the user-supplied commands files. Maybe the patch is not perfect, but it's small enough to be reviewed and evaluated by anyone, and it can also be completely silenced if no logging is wished. I tried to do it as minimal invasive as possible, and those different languages files would really remain the user's business to maintain, I don't think somebody would want to have all 17-20 possible languages.
Lucian
Am Montag, 14. November 2005 14:22 schrieb Lucian Muresan:
I'd like to propose a patch for further i18n of VDR, namely in the commands.conf and reccmds.conf files. Even if any user can customize
That was something that was missing in vdr. Thanks.
All that the user has to do, is to provide, additionally to the "normal" files commands.conf and reccmds.conf, the version(s) in the language(s) he want's to use as commands.conf.xyz and reccmds.conf.xyz, where ".xyz" is the 3-characters language code defined in VDR's i18n.c:
Although this is really easy to install for a user, it will be hard for an admin/distributor to keep these files in sync. As of vdr currently supporting up to 20 languages, one would have to edit up to 20 files just for a minor change (even if it just affects the command line itself). Wouldn't it be cleaner just to have _one_ config file and one for the translations?
regards, Thiemo
rollercoaster@reel-multimedia.com wrote:
Am Montag, 14. November 2005 14:22 schrieb Lucian Muresan:
I'd like to propose a patch for further i18n of VDR, namely in the commands.conf and reccmds.conf files. Even if any user can customize
That was something that was missing in vdr. Thanks.
Well, according to Klaus' answer, apparently not...
All that the user has to do, is to provide, additionally to the "normal" files commands.conf and reccmds.conf, the version(s) in the language(s) he want's to use as commands.conf.xyz and reccmds.conf.xyz, where ".xyz" is the 3-characters language code defined in VDR's i18n.c:
Although this is really easy to install for a user, it will be hard for an admin/distributor to keep these files in sync. As of vdr currently supporting up to 20 languages, one would have to edit up to 20 files just for a minor change (even if it just affects the command line itself). Wouldn't it be cleaner just to have _one_ config file and one for the translations?
Well, for distributors, yo're right, I didn't think of those. But these files where meant to be user-configurable anyway, I think, so users wouldn't need to update that many files. Anyway, what does the distributor do about inconsistent/incomplete translations in VDR's own i18n.c file, as with adding new features it'S impossible to have all translators update all strings, and no one delays a release just because of that. On the other hand, a different approach, to have the translations separated from the commands would have been better, but more complicated to achieve (parsing of the files must then be rewritten for theese two files, and I was trying to keep it as simple as possible)...
Lucian
Am Montag, 14. November 2005 18:06 schrieb Lucian Muresan:
That was something that was missing in vdr. Thanks.
Well, according to Klaus' answer, apparently not...
Well, seems that Klaus and I have different views on this. :)
Well, for distributors, yo're right, I didn't think of those. But these files where meant to be user-configurable anyway, I think, so users wouldn't need to update that many files.
Ok, but an end-user usually won't use different languages in his vdr-box, so in this case Klaus would be right... ok, no rule without exceptions, otherwise you would not have written this patch, but i will keep this aside for now.
Anyway, what does the distributor do about inconsistent/incomplete translations in VDR's own i18n.c file, as with adding new features it'S impossible to have all translators update all strings, and no one delays a release just because of that.
you're right, that's really a problem. but at some point you will have to start a translation, maybe if you come to a first beta or so, even if the translation will alway behind the current development.
What concerns me more, is how to let the translators do the translation of vdr and all these plugins (currently 25 in our distribution). It will be quite unhandy to send them 26 file to be translated and syncing them after translation, so i already think of merging them for easier handling. But after that it will be harder to care for updates...
Seems like it's time for some concept. If anyone has got ideas... btw: I also like the concept like in kde (i.e.) of having installable language files.
thiemo
rollercoaster@reel-multimedia.com wrote:
Am Montag, 14. November 2005 18:06 schrieb Lucian Muresan:
That was something that was missing in vdr. Thanks.
Well, according to Klaus' answer, apparently not...
Well, seems that Klaus and I have different views on this. :)
Well, for distributors, yo're right, I didn't think of those. But these files where meant to be user-configurable anyway, I think, so users wouldn't need to update that many files.
Ok, but an end-user usually won't use different languages in his vdr-box, so
^^^^^^ Yes, I'd emphasize ^^^^^^.
in this case Klaus would be right... ok, no rule without exceptions, otherwise you would not have written this patch, but i will keep this aside for now.
Yes, I'm one of those who occasionaly change languages from the OSD Setup Menu. If I'm allowed to joke, others, ther could be an option to make that entry unavailable after they set their language once, and never change it again ;-). So, joke aside, if changing the whole OSD language is possible on-the-fly, like on most of modern consumer electronics products (and VDR too emulates and even outperforms a consumer electronics family, STBs) like even digital cameras or DVD players or what else, it appears to me only consistent if all OSD pages *can* change (the must not, other equipment may also have user-configurable menu entries and leve that to the user). But if there is a way to achieve something due to the open architecture, and that something is achieved *whithout* changing the default (previous) behaviour like in the case of this patch, I don't see any serious reasons beeing against it. This patch is not meant to burden the main developer, as it introduces some *optional* extension. The original functionality didn't burden him either (I didnt find any commands.conf or reccmds.conf in vanilla VDR source distribution), so it's a feature which the Klaus intentionally left beeing the user's problem. Now I'm asking again, if the patches only gives a new possibility, but doesn't *force* anyone to use it, what's the problem?
Anyway, what does the distributor do about inconsistent/incomplete translations in VDR's own i18n.c file, as with adding new features it'S impossible to have all translators update all strings, and no one delays a release just because of that.
you're right, that's really a problem. but at some point you will have to start a translation, maybe if you come to a first beta or so, even if the translation will alway behind the current development.
What concerns me more, is how to let the translators do the translation of vdr and all these plugins (currently 25 in our distribution). It will be quite unhandy to send them 26 file to be translated and syncing them after translation, so i already think of merging them for easier handling. But after that it will be harder to care for updates...
I can believe you that this is hard to maintain for a distributor. But hey, I just hacked something which makes it possible, now you want all your work done, too ;-). Now I looked better at your email address, so you're packaging this for the ReelBox, so VDR is even helping you making money :-). Is it actually available?
Seems like it's time for some concept. If anyone has got ideas... btw: I also like the concept like in kde (i.e.) of having installable language files.
Overdue, and I agree with you that this should be solved more elegant (something like gettext comes to mind), but there are other problems needing concept, too, and only Klaus decides what's important to *him*. Sorry, but that's the way it looks like, I only dare to remind of UTF-8 (he doesn't need different languages, or other encodings than ISO-8859-1[5], etc.), NPTL just to name 2 of them, but this has all been discussed and it makes little sense, I think.
Lucian
Am Montag, 14. November 2005 19:34 schrieb Lucian Muresan:
rollercoaster@reel-multimedia.com wrote:
What concerns me more, is how to let the translators do the translation of vdr and all these plugins (currently 25 in our distribution). It will be quite unhandy to send them 26 file to be translated and syncing them after translation, so i already think of merging them for easier handling. But after that it will be harder to care for updates...
I can believe you that this is hard to maintain for a distributor. But hey, I just hacked something which makes it possible, now you want all your work done, too ;-).
No, i don't want anyone to do it this for us, I was just thinking loud. This has to be done at sooner or later, so if it's not there *we* will do it. So i was asking if anyone has ideas or suggestions:
Seems like it's time for some concept. If anyone has got ideas... btw: I also like the concept like in kde (i.e.) of having installable language files.
maybe it was unwise to do this question in this thread (as it does not concern your patch directly). But why not discuss this issue here on this list *before* starting work?
regards, Thiemo
rollercoaster@reel-multimedia.com wrote:
Am Montag, 14. November 2005 19:34 schrieb Lucian Muresan:
rollercoaster@reel-multimedia.com wrote:
What concerns me more, is how to let the translators do the translation of vdr and all these plugins (currently 25 in our distribution). It will be quite unhandy to send them 26 file to be translated and syncing them after translation, so i already think of merging them for easier handling. But after that it will be harder to care for updates...
I can believe you that this is hard to maintain for a distributor. But hey, I just hacked something which makes it possible, now you want all your work done, too ;-).
No, i don't want anyone to do it this for us, I was just thinking loud. This has to be done at sooner or later, so if it's not there *we* will do it. So i was asking if anyone has ideas or suggestions:
Seems like it's time for some concept. If anyone has got ideas... btw: I also like the concept like in kde (i.e.) of having installable language files.
maybe it was unwise to do this question in this thread (as it does not concern your patch directly). But why not discuss this issue here on this list *before* starting work?
regards, Thiemo
Just for the record: I'm not going to implement language files in version 1.4, but maybe will do so in version 1.5.x.
Klaus
Hello there, I also made some thoughts about the i18n problem. If we add some other languages e.g. it would blow the i18n.c up anyway. At First we should sort a little the languages for central Europe, nordic, latin and eastern languages:
{ "English", "Deutsch", "Français", "Italiano", "Català", "Español", "Português", "Dansk", "Nederlands", "Norsk", "Svenska", "suomi", // Finnish (this is not a typo - it's really lowercase!) "Eesti", "Polski", "Slovenski", "Magyar", // Ungarisch "Hrvatski", //Kroatisch "Românã", "ÅëëçíéêÜ", // Greek "ÀãááÚØÙ", // Russian },
and name it as i18n_euro, so we could add an i18n_asia.c or so. maybe a little perl script /vim rec could do this sort.
regards movimax
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr