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. 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? 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. How does this translate into gettext? Does each plugin use its own textdomain(), and if, how does the domain switching happen? 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? 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. Cheers, Udo
