[vdr] i18n done with gettext (was: i18n.c sorted)
lucianm at users.sourceforge.net
Wed Nov 16 17:42:14 CET 2005
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
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
>> 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.
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.
More information about the vdr