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.
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
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.
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
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 -
Klaus Schmidinger