Hi,
plugins can re-use VDR-core translations. With the old "i18n.c" method plugin authors just did not provide a plugin specific translation for these texts. With the new translation method identifying these text got harder for plugin translators. xgettext puts all texts into the .pot file - also the texts for which the VDR-core translation should be used. A translator now cannot see which texts he has to translate and which not.
Can this be improved?
One way of doing this would be to introduce a new macro similar to trNOOP( ). A plugin author would then tag the vdr-core texts with this new macro and xgettext would ignore these texts.
What do you think?
Regards, Matthias
I demand that Matthias Becker may or may not have written...
plugins can re-use VDR-core translations. With the old "i18n.c" method plugin authors just did not provide a plugin specific translation for these texts.
With the new translation method identifying these text got harder for plugin translators. xgettext puts all texts into the .pot file - also the texts for which the VDR-core translation should be used. A translator now cannot see which texts he has to translate and which not.
Can this be improved?
Each plugin has to handle its own translations and ensure that they're in its own translation domain. This means that its makefile has to run xgettext, generate .mo files and install them. Translation has to be done (for plugin-specific text) using dgettext() and dngettext() instead of gettext() and ngettext().
[snip]
2007/8/19, Darren Salt linux@youmustbejoking.demon.co.uk:
Each plugin has to handle its own translations and ensure that they're in its own translation domain. This means that its makefile has to run xgettext, generate .mo files and install them. Translation has to be done (for plugin-specific text) using dgettext() and dngettext() instead of gettext() and ngettext().
I don't see. where this adresses the problem. Plugins use tr() to translate strings, like VDR. The handling of (d)gettext happens in core VDR.
xgettext simply extracts all strings marked with tr(s) and trNOOP(s) regardless of s beeing a plugin translated string or a re-used string from VDR core.
Regards, Joachim.
On 08/19/07 14:58, Matthias Becker wrote:
Hi,
plugins can re-use VDR-core translations. With the old "i18n.c" method plugin authors just did not provide a plugin specific translation for these texts. With the new translation method identifying these text got harder for plugin translators. xgettext puts all texts into the .pot file - also the texts for which the VDR-core translation should be used. A translator now cannot see which texts he has to translate and which not.
Can this be improved?
One way of doing this would be to introduce a new macro similar to trNOOP( ). A plugin author would then tag the vdr-core texts with this new macro and xgettext would ignore these texts.
What do you think?
I'll look into this next weekend - this WE was a littly hectic with the locale problems...
Klaus
On 08/19/07 14:58, Matthias Becker wrote:
Hi,
plugins can re-use VDR-core translations. With the old "i18n.c" method plugin authors just did not provide a plugin specific translation for these texts. With the new translation method identifying these text got harder for plugin translators. xgettext puts all texts into the .pot file - also the texts for which the VDR-core translation should be used. A translator now cannot see which texts he has to translate and which not.
Can this be improved?
One way of doing this would be to introduce a new macro similar to trNOOP( ). A plugin author would then tag the vdr-core texts with this new macro and xgettext would ignore these texts.
What do you think?
You're certainly right.
How about this:
--- i18n.h 2007/08/19 14:07:17 1.23 +++ i18n.h 2007/08/24 13:33:50 @@ -80,6 +80,7 @@
#ifdef PLUGIN_NAME_I18N #define tr(s) I18nTranslate(s, "vdr-" PLUGIN_NAME_I18N) +#define trVDR(s) I18nTranslate(s) // to use a text that's in the VDR core's translation file #else #define tr(s) I18nTranslate(s) #endif
Klaus
On 08/24/07 15:35, Klaus Schmidinger wrote:
On 08/19/07 14:58, Matthias Becker wrote:
... One way of doing this would be to introduce a new macro similar to trNOOP( ). A plugin author would then tag the vdr-core texts with this new macro and xgettext would ignore these texts.
What do you think?
You're certainly right.
How about this:
--- i18n.h 2007/08/19 14:07:17 1.23 +++ i18n.h 2007/08/24 13:33:50 @@ -80,6 +80,7 @@
#ifdef PLUGIN_NAME_I18N #define tr(s) I18nTranslate(s, "vdr-" PLUGIN_NAME_I18N) +#define trVDR(s) I18nTranslate(s) // to use a text that's in the VDR core's translation file #else #define tr(s) I18nTranslate(s) #endif
One more thing: this also reduces I18nTranslate() to
const char *I18nTranslate(const char *s, const char *Plugin) { if (s && CurrentLanguage) { const char *t = Plugin ? dgettext(Plugin, s) : gettext(s); if (t != s) return t; } return SkipContext(s); }
Klaus
On 08/24/07 16:00, Klaus Schmidinger wrote:
... One more thing: this also reduces I18nTranslate() to
const char *I18nTranslate(const char *s, const char *Plugin) { if (s && CurrentLanguage) { const char *t = Plugin ? dgettext(Plugin, s) : gettext(s); if (t != s) return t; } return SkipContext(s); }
Well, actually
const char *I18nTranslate(const char *s, const char *Plugin) { if (!s) return s; if (CurrentLanguage) { const char *t = Plugin ? dgettext(Plugin, s) : gettext(s); if (t != s) return t; } return SkipContext(s); }
Guess I was a little too enthusiastic when minimizing this code ,-)
Klaus
-
Darren Salt -
Joachim Wilke -
Klaus Schmidinger -
Matthias Becker