[opensuse-packaging] %find_lang now removes unsupported locales
Hi, I made up my mind how to track supported locales and instead of adding more and more /usr/share/locale directories as upstream projects come up with them, I went and made %find_lang remove unsupported languages (and I will remove a lot of them after 11.4). The check that removes the language will output how many strings are removed, so we can check how many strings new languages bring and I would require 10.000 strings (for comparision, yast modules contain ~20.000 strings). Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 14 Jan 2011, Stephan Kulow wrote:
I made up my mind how to track supported locales and instead of adding more and more /usr/share/locale directories as upstream projects come up with them, I went and made %find_lang remove unsupported languages (and I will remove a lot of them after 11.4).
Would it be possible to inlcude a parameter to stop the removal, in case of expessive need for the additional laguages? Maybe along the lines: %find_lang +xy_XY to add the language xy_XY ? I ask this to make it easier in the future to add a language even befor it becomes offically supported, on for special edge cases. Thanks for listening. Cheers, Yamaban out -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Freitag, 14. Januar 2011 schrieb Yamaban:
On Fri, 14 Jan 2011, Stephan Kulow wrote:
I made up my mind how to track supported locales and instead of adding more and more /usr/share/locale directories as upstream projects come up with them, I went and made %find_lang remove unsupported languages (and I will remove a lot of them after 11.4).
Would it be possible to inlcude a parameter to stop the removal, in case of expessive need for the additional laguages? Maybe along the lines: %find_lang +xy_XY to add the language xy_XY ?
I ask this to make it easier in the future to add a language even befor it becomes offically supported, on for special edge cases.
A parameter would make it impossible to use for backport projects, but if you want to, you can add a check for an environment variable. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Stephan Kulow wrote:
The check that removes the language will output how many strings are removed, so we can check how many strings new languages bring and I would require 10.000 strings (for comparision, yast modules contain ~20.000 strings).
Well, for translation for dialects, 10000 would be far too much. It may make sense even if a single string exists there. Here is an example of useful use of that: http://ftp.suse.com/pub/people/sbrabec/i18n-demo/gettextdemo-0.1.tar.bz2 Translation for ln_CO is provided and translation for ln is provided as well => It's deliberate and OK. It would be nice to generate glibc locale for all locales that are enabled for translation. And it would be good to force to fail packages that try to install translations to de_DE fr_FR etc. (especially when the don't provide de, fr). People work-around current %find_lang approach by adding %dir. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Freitag, 14. Januar 2011 schrieb Stanislav Brabec:
Stephan Kulow wrote:
The check that removes the language will output how many strings are removed, so we can check how many strings new languages bring and I would require 10.000 strings (for comparision, yast modules contain ~20.000 strings).
Well, for translation for dialects, 10000 would be far too much. It may make sense even if a single string exists there. Here is an example of useful use of that: http://ftp.suse.com/pub/people/sbrabec/i18n-demo/gettextdemo-0.1.tar.bz2
Translation for ln_CO is provided and translation for ln is provided as well => It's deliberate and OK. You most definitely right here. I'm talking about languages not dialects.
It would be nice to generate glibc locale for all locales that are enabled for translation.
And it would be good to force to fail packages that try to install translations to de_DE fr_FR etc. (especially when the don't provide de, fr). People work-around current %find_lang approach by adding %dir.
rpmlint already checks supported locales. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/1/14 Stephan Kulow <coolo@suse.de>:
Am Freitag, 14. Januar 2011 schrieb Stanislav Brabec:
Stephan Kulow wrote:
The check that removes the language will output how many strings are removed, so we can check how many strings new languages bring and I would require 10.000 strings (for comparision, yast modules contain ~20.000 strings).
Well, for translation for dialects, 10000 would be far too much. It may make sense even if a single string exists there. Here is an example of useful use of that: http://ftp.suse.com/pub/people/sbrabec/i18n-demo/gettextdemo-0.1.tar.bz2
Translation for ln_CO is provided and translation for ln is provided as well => It's deliberate and OK. You most definitely right here. I'm talking about languages not dialects.
It would be nice to generate glibc locale for all locales that are enabled for translation.
And it would be good to force to fail packages that try to install translations to de_DE fr_FR etc. (especially when the don't provide de, fr). People work-around current %find_lang approach by adding %dir.
rpmlint already checks supported locales.
Any good packager oriented documentation about all this? Or should I read the full gettext manual? The list at https://build.opensuse.org/package/view_file?project=Base:System&package=filesystem&file=languages is confusing. There are both "de" and "de_DE", also "es" and "es_ES"; but no "ca_ES" even if there is "ca". Now I have a package that wants to install "ca_AD", "ca_ES", "ca_FR" and "ca_IT"... but no "ca". What should I do? There is a bug to report upstream here? The four ca_*.po files are identical... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le lundi 21 février 2011, à 02:29 +0100, Cristian Morales Vega a écrit :
2011/1/14 Stephan Kulow <coolo@suse.de>:
rpmlint already checks supported locales.
Any good packager oriented documentation about all this? Or should I read the full gettext manual?
I guess it depends what you need to be documented :-) Is it "what is a valid locale" (see intro at [1]), "what is a supported locale" (this depends on the distro, see rpmlint check for openSUSE), or something else? [1] http://en.wikipedia.org/wiki/Locale
The list at https://build.opensuse.org/package/view_file?project=Base:System&package=filesystem&file=languages is confusing. There are both "de" and "de_DE", also "es" and "es_ES"; but no "ca_ES" even if there is "ca".
Now I have a package that wants to install "ca_AD", "ca_ES", "ca_FR" and "ca_IT"... but no "ca". What should I do? There is a bug to report upstream here? The four ca_*.po files are identical...
If the four files are identical, then it's certainly suboptimal to have those four territory-specific locales instead of having a somple ca locale. If a user is using the ca_ES locale, the system will first look for ca_ES translations and then, if ca_ES doesn't exist for this specific gettext package, it will look for ca translations. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (5)
-
Cristian Morales Vega -
Stanislav Brabec -
Stephan Kulow -
Vincent Untz -
Yamaban