[vdr] localedir, plugin text domain names
I believe distribution packagers of VDR (at least myself) will want to
install the VDR locale files into the standard directory under
/usr/share/locale/, where all other locale files are.
However, as that directory may contain lots of other locales that do not
have translation for VDR (or possibly only for some plugin of VDR, which
applies to a custom localedir as well), those show up in the OSD
Language selection menu as LanguageName$English.
Also, it could also be possible that the I18N_MAX_LANGUAGES = 256
constant could be too small for some systems. I guess it could be
modified to limit only the locales that have VDR translation, not the
total locale count in the system.
+void I18nRegister(const char *Plugin)
+{
+ bindtextdomain(Plugin, I18nLocaleDir);
+}
[...]
+ if (Plugin)
+t = dgettext(Plugin, s);
Maybe it would be better to use something like vdr-PLUGIN or
vdr-plugin-PLUGIN?
If the translations are installed into /usr/share/locale, the files of
VDR plugins could conflict with other programs that have the same name,
if the plugin translation files are not prefixed by anything.
--
Anssi Hannula
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] localedir, plugin text domain names
On 08/18/07 11:11, Anssi Hannula wrote:
I believe distribution packagers of VDR (at least myself) will want to
install the VDR locale files into the standard directory under
/usr/share/locale/, where all other locale files are.
However, as that directory may contain lots of other locales that do not
have translation for VDR (or possibly only for some plugin of VDR, which
applies to a custom localedir as well), those show up in the OSD
Language selection menu as LanguageName$English.
Also, it could also be possible that the I18N_MAX_LANGUAGES = 256
constant could be too small for some systems. I guess it could be
modified to limit only the locales that have VDR translation, not the
total locale count in the system.
+void I18nRegister(const char *Plugin)
+{
+ bindtextdomain(Plugin, I18nLocaleDir);
+}
[...]
+ if (Plugin)
+t = dgettext(Plugin, s);
Maybe it would be better to use something like vdr-PLUGIN or
vdr-plugin-PLUGIN?
If the translations are installed into /usr/share/locale, the files of
VDR plugins could conflict with other programs that have the same name,
if the plugin translation files are not prefixed by anything.
Why do you want to make things overly complicated?
Can't we just keep it simple?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] localedir, plugin text domain names
Klaus Schmidinger wrote:
On 08/18/07 11:11, Anssi Hannula wrote:
I believe distribution packagers of VDR (at least myself) will want to
install the VDR locale files into the standard directory under
/usr/share/locale/, where all other locale files are.
However, as that directory may contain lots of other locales that do not
have translation for VDR (or possibly only for some plugin of VDR, which
applies to a custom localedir as well), those show up in the OSD
Language selection menu as LanguageName$English.
Also, it could also be possible that the I18N_MAX_LANGUAGES = 256
constant could be too small for some systems. I guess it could be
modified to limit only the locales that have VDR translation, not the
total locale count in the system.
+void I18nRegister(const char *Plugin)
+{
+ bindtextdomain(Plugin, I18nLocaleDir);
+}
[...]
+ if (Plugin)
+t = dgettext(Plugin, s);
Maybe it would be better to use something like vdr-PLUGIN or
vdr-plugin-PLUGIN?
If the translations are installed into /usr/share/locale, the files of
VDR plugins could conflict with other programs that have the same name,
if the plugin translation files are not prefixed by anything.
Why do you want to make things overly complicated?
Can't we just keep it simple?
Keeping it simple would be dropping the language selection completely
and using environment, as other applications do. But I guess you do not
want do that.
But you mean, use a specific directory for VDR locales, like
/usr/share/vdr/locale?
If you do not wish to use the standard location, fine with me. However,
the LanguageName$English problem still applies, if there is some
directory in the VDR localedir that does not have a VDR translation, but
e.g. only for some plugin.
--
Anssi Hannula
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] localedir, plugin text domain names
On 08/18/07 11:29, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/18/07 11:11, Anssi Hannula wrote:
I believe distribution packagers of VDR (at least myself) will want to
install the VDR locale files into the standard directory under
/usr/share/locale/, where all other locale files are.
However, as that directory may contain lots of other locales that do not
have translation for VDR (or possibly only for some plugin of VDR, which
applies to a custom localedir as well), those show up in the OSD
Language selection menu as LanguageName$English.
Also, it could also be possible that the I18N_MAX_LANGUAGES = 256
constant could be too small for some systems. I guess it could be
modified to limit only the locales that have VDR translation, not the
total locale count in the system.
+void I18nRegister(const char *Plugin)
+{
+ bindtextdomain(Plugin, I18nLocaleDir);
+}
[...]
+ if (Plugin)
+t = dgettext(Plugin, s);
Maybe it would be better to use something like vdr-PLUGIN or
vdr-plugin-PLUGIN?
If the translations are installed into /usr/share/locale, the files of
VDR plugins could conflict with other programs that have the same name,
if the plugin translation files are not prefixed by anything.
Why do you want to make things overly complicated?
Can't we just keep it simple?
Keeping it simple would be dropping the language selection completely
and using environment, as other applications do. But I guess you do not
want do that.
VDR allows selecting the OSD language at runtime, so the setting of
the environment is only the default.
But you mean, use a specific directory for VDR locales, like
/usr/share/vdr/locale?
That's how it works at the moment.
If you do not wish to use the standard location, fine with me. However,
the LanguageName$English problem still applies, if there is some
directory in the VDR localedir that does not have a VDR translation, but
e.g. only for some plugin.
What sense does it make to have a translation for a plugin, but
not for VDR itself?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] localedir, plugin text domain names
Klaus Schmidinger wrote:
On 08/18/07 11:29, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/18/07 11:11, Anssi Hannula wrote:
I believe distribution packagers of VDR (at least myself) will want to
install the VDR locale files into the standard directory under
/usr/share/locale/, where all other locale files are.
However, as that directory may contain lots of other locales that do not
have translation for VDR (or possibly only for some plugin of VDR, which
applies to a custom localedir as well), those show up in the OSD
Language selection menu as LanguageName$English.
Also, it could also be possible that the I18N_MAX_LANGUAGES = 256
constant could be too small for some systems. I guess it could be
modified to limit only the locales that have VDR translation, not the
total locale count in the system.
+void I18nRegister(const char *Plugin)
+{
+ bindtextdomain(Plugin, I18nLocaleDir);
+}
[...]
+ if (Plugin)
+t = dgettext(Plugin, s);
Maybe it would be better to use something like vdr-PLUGIN or
vdr-plugin-PLUGIN?
If the translations are installed into /usr/share/locale, the files of
VDR plugins could conflict with other programs that have the same name,
if the plugin translation files are not prefixed by anything.
Why do you want to make things overly complicated?
Can't we just keep it simple?
Keeping it simple would be dropping the language selection completely
and using environment, as other applications do. But I guess you do not
want do that.
VDR allows selecting the OSD language at runtime, so the setting of
the environment is only the default.
But you mean, use a specific directory for VDR locales, like
/usr/share/vdr/locale?
That's how it works at the moment.
If you do not wish to use the standard location, fine with me. However,
the LanguageName$English problem still applies, if there is some
directory in the VDR localedir that does not have a VDR translation, but
e.g. only for some plugin.
What sense does it make to have a translation for a plugin, but
not for VDR itself?
Very little. I guess we could live with that being impossible.
--
Anssi Hannula
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
