Markus Hahn wrote:
Am Mittwoch, 16. November 2005 14:57 schrieb Klaus Schmidinger:
Udo Richter wrote:
Hmmm. Imho the order of the languages is the same for VDR's i18n.c and for all the plugins, so shouldn't this break the i18n's of *all* plugins? Or do I miss something?
Thats seems to be a real problem. but most oft the plugins are real bad translated. Could be a chance to force the maintainers to do something. It doesn`t make a lot of work.
If Klaus said he plans to implement language files in a later version, why breaking things now only to brake them later again?
Beside the new i18n.c (vdr-1.3.36), I fetched wordlists out of i18n.c and rest of the sources. (piped through sort). There are some diffrences.
This sorting thing can also be done, guess what, with "xgettext -ktr *.c -s -o vdr.po" and then I'll have a gettext template file (and when using gettext for example, the sorting doesn't matter too much anymore, but of course it can be done, like in the above example, editing language files can be done with PO-editors). I was silent in this matter since the original thread which caused this discussion, and animated by actually Thiemo's idea about language files I gave the whole matter a thought and even played a bit with the code. So, I already have a rough concept of quickly turning i18n.h and i18n.c into using gettext (which is available in glibc anyway, and is most commonly used in the linux world) for external language files. It can be done with minimal code changes in the rest of the program, as the "tr" macro can be used further on, and only some things in the functions implemented in i18n.c require some changes. If someone says reading translations from external files is slow on every call to "tr", this can also be solved by reading their whole contents into memory, only it would be dynamical (not bound to a hard-coded number of UI languages, as theese can be added bthen by distributors or even users whithout having to compile the program). And the whole stuff is really easily extendable to plugins, as their maintainers now can entirely throw away their i18n files and just let the xgettext utility parse their sources for "tr"-enclosed strings to be translated and generate po-files in which again, the translated strings can be entered by non-programmers too. And the same technique can be applied even to commands.conf and reccmds.conf with some littel helper function in VDR, which would first generate a template file out of the command.conf files, as their command labels themselves are not enclosed by the "tr" macro (that, if the syntax remains the same). But, this also can be left optional to distributors/packagers, VDR would only look for some languagefiles if they're available at the expected location, according to the configured language, if the#re not there, everything remains as before. And this won't be the same as in my latest patch, having the commands actually in multiple files.
regards movimax
You're of course absolutely right here. I should have thought of this, too.
On long term, its probably best to move i18n out of the c source and into editable language definition files that can be loaded on runtime. (I think thats what Klaus meant with 'language files'.)
Yes, that's what I meant. But let's do this in version 1.5.x.
Klaus
That beeing said, Klaus & everyone, what would you think about letting me give it a try? I think and I hope I'll be able to provide a patch in few days, with all existing translations migrated to the new aproach and adapted makefiles (maybe until this weekend, depending on spare time), in the meantime we could discuss the concept, maybe I'll have questioons for few details (maybe there are issues other than spare time or priorities which made you plan this for 1.5.x). Well, in the end we'll see if it's good or not, but we might have the chance to workout the breakage in this i18n matter only once and already now (as I said, I think I'll be able to do it myself, so it's up to me to find the time, and I'll promise I'll yell or let it be if I happen to get stuck, you won't have to wait for this if you already plan a feature-freeze for releasing 1.4, I only think we could give it a shot, it might turn out good enough for having it merged). But please tell me if there is ablsolutely no interest for this now.
Lucian