Udo Richter wrote: > Lucian Muresan wrote: >> 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. >> 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. > > All in all, this is worth some thoughts. And maybe its a good idea to > let this cook as a patch until the 1.5 cycle starts. I might start something tonight. > Some early thoughts about this: > > Migrating VDR core to gettext seems to be possible in an acceptable > effort. Where should these language files be stored? /usr/share/locale > or in the VDR conf folders? Well, this is a question I was about to ask opinions, too. In the first phase, until I have something up and running, It wouldn't bother me much, but I'd welcome an argumentation on this one, too. > One thing that is critical is the integration of plugins: VDR plugins > use their own plugin tr() namespace, based on the PLUGIN_NAME_I18N set > in the Makefile. To make things worse, i18n will fall back to the VDR > namespace if nothing was found in the plugin namespace, giving plugins > access to all VDR strings. It is possible to keep both concepts for a while. > How does this translate into gettext? Does each plugin use its own > textdomain(), and if, how does the domain switching happen? I think so, every plugin should have it's own domain (therefore, po -> mo file). The switching would be done in the tr() macro (it's underlying function) when invoked with the plugin name argument like it is now invoking actually the same I18nTranslate, which is only looking up the current Phrases eiter in VDR 'domain', or in the plugin's: #ifdef PLUGIN_NAME_I18N #define tr(s) I18nTranslate(s, PLUGIN_NAME_I18N) #else #define tr(s) I18nTranslate(s) #endif If the translations are to be cached in memory, they would be read once at startup of VDR and each plugin, and a dynamically allocated Phrases[] array would be filled with their contents, thus having the possibility of keeping most of the functions in the i18n.c (including I18nTranslate) almost as they are now. > Will plugins based on the old i18n.c concept continue to work, or do > they have to migrate to gettext? Will a converted plugin work under a > non-gettext VDR version too? If both concepts ar kept for a while, then I think it should be even possible that a converted plugin works on a non-gettext VDR, but only if the plugin itself kept the original concept too. > For the existing plugins, we imho need a smooth upgrade path, preferably > some scripting-fu that turns i18n.c into .po files. Maybe this is also > an option for compatibility: For backwards compatibility, some script > turns .po files to old-style i18n.c files. Well, even that should be possible, but I wonder if that's not effort in the wrong direction if we would really push the new gettext "way". Lucian
