Iwan Davies wrote:
On Thu, 17 Nov 2005 02:19:30 +0100, in gmane.linux.vdr you wrote:
Thiemo Gehrke wrote:
But on the other hand I do not see the need of having different namespaces (domains) for every plugin.
To avoid collisions. A string may be differently translated in different contexts. Within one plugin, this can be avoided. But with different plugins, its surely fun to watch two plugin writers arguing about the 'right' translation. ;)
You could still get collisions within a single plugin, unless you use unique string IDs (assuming this is how gettext works?). If the plugin i18n rules specify that the string ID has to contain the name of the plugin (e.g. FEMON_MENU_SETUP_BGROUND_TRANSP = "Background transparency") then inter-plugin string ID collisions can be avoided completely.
Sharing strings even within a plugin is /a bad idea/ - you never know where the string might be reused next time, and the translator may need to inflect, conjugate or decline the term differently in each context. If you're worried translators having to translate the same term twice, how about persuading translators to use translation memory (such as OmegaT, see http://www.omegat.org/ - doesn't handle PO natively, but can AIUI a filter is available). This gives the translator the freedom to decide whether to translate the string in the same way twice or whether to change his translation on the basis of the context.
I also think it's good not to mix the strings, both among vdr main module / plugins, or languages. I think gettext allows multiple domains in one file, but I think multiple languages is impossible whithout degrading the use of gettext just as a storage.
When it comes to preloading language support and that delaying VDR's start-up times, how about allowing the user to select which languages he wants to compile in? A compile flag UILANGS=/path/to/list_of_ui_langs would mean that each user could, if they wanted to, define their own list of languages to compile in. For example, I only speak English, German and French, so my list_of_ui_langs would contain: en de fr
Given most reseller versions are for specific markets (with tailored channels.conf, etc.) this would allow resellers to tailor their packages too.
Sure, this should be build options.
Lucian