I suggest to manage LANG environtment variable with eselect.
Created attachment 259535 [details] locale.eselect based on libs/editor-variable.bash.in
Do you propose this as part of app-admin/eselect, or as a separate module in an own package (like app-admin/eselect-lang for example)? (In reply to comment #1) > Created an attachment (id=259535) [details] > locale.eselect Global scope code like this: LANG_LIST=$("${EROOT}/usr/bin/locale" --all-locales) must not be used in eselect modules. See eselect's developer-guide.txt for the reason why.
Created attachment 259544 [details] locale.eselect Removed global variables. I'd like to add this as part of app-admin/eselect because LANG environment variable is used by several packages, system-wide. FYI, debian has /etc/default/locale, fedora has /etc/profile.d/lang.sh.
(In reply to comment #3) > I'd like to add this as part of app-admin/eselect because LANG environment > variable is used by several packages, system-wide. What about system wide -nls, and LINGUAS="en". In this case the module will be added for nothing. I like the idea better of a seperate package.
There is a problem in FreeBSD: $ locale --all-locales locale: illegal option -- - Usage: locale [ -a | -m ] locale [ -ck ] name ... "locale -a" should be equivalent though, and I hope that it is portable. (In reply to comment #3) > FYI, debian has /etc/default/locale, fedora has /etc/profile.d/lang.sh. Do these files only contain LANG, or also the LC_* variables (like LC_CTYPE)? (In reply to comment #4) > What about system wide -nls, and LINGUAS="en". > In this case the module will be added for nothing. From a purist's point of view you're right. On the other hand, an unused 4 KB file is not really a problem, especially if it cuts down on a package. Does glibc with USE="-nls" install /usr/bin/locale?
Created attachment 259616 [details] locale.eselect changed from --all-locales to -a. clean up. (In reply to comment #5) > (In reply to comment #3) > > FYI, debian has /etc/default/locale, fedora has /etc/profile.d/lang.sh. > > Do these files only contain LANG, or also the LC_* variables (like LC_CTYPE)? debian: $ cat /etc/default/locale LANG="en_US.UTF-8" fedora: $ cat /etc/sysconfig/i18n LANG="ja_JP.UTF-8" SUPPORTED="ja_JP.UTF-8:ja_JP:ja" SYSFONT="latarcyrheb-sun16" sorry, /etc/profile.d/lang.sh is a script handling locale informations. (In reply to comment #5) > Does glibc with USE="-nls" install /usr/bin/locale? yes # USE="nls" emerge glibc > glibc_with_nls # emerge -C gettext # USE="-nls" emerge glibc > glibc_without_nls # diff -u glibc_with_nls glibc_without_nls --- glibc_with_nls 2011-01-12 19:38:05.436730002 +0900 +++ glibc_without_nls 2011-01-12 20:05:12.820730002 +0900 @@ -398,7 +398,6 @@ /usr/lib32/crt1.o /usr/lib32/libutil.a /usr/share/locale/locale.alias -/usr/share/locale/ja/LC_MESSAGES/libc.mo /usr/share/i18n/SUPPORTED /usr/share/i18n/locales/translit_font /usr/share/i18n/locales/nr_ZA Even if emerge glibc without USE="-nls".
I've added the module locally on my system and did some tests. It seems to work fine. Last questions (hopefully): - Is "free form" input really needed? locale -a should output all possible valid choices. (?) - I'm sceptical about the "update" action, which may set LANG to something that is not desired by the user, namely the first item output by locale -a. Can we omit the do_update() function? - OK if I update the header to GPL v2 or later (rather than v2 only)?
(In reply to comment #7) > - Is "free form" input really needed? locale -a should output all possible > valid choices. (?) yes. its needed. locale -a doesn't output formal locale name. it makes troubles with some systems, for exapmle Xlib. http://www.linuxfromscratch.org/lfs/view/6.7/chapter07/profile.html In several cases Xlib expects that the character map will be listed in uppercase notation with canonical dashes. For instance, "ISO-8859-1" rather than "iso88591". It is also possible to find an appropriate specification by removing the charmap part of the locale specification. This can be checked by running the locale charmap command in both locales. For example, one would have to change "de_DE.ISO-8859-15@euro" to "de_DE@euro" in order to get this locale recognized by Xlib. > - I'm sceptical about the "update" action, which may set LANG to something > that is not desired by the user, namely the first item output by locale -a. > Can we omit the do_update() function? It may be useful when you change /etc/locale.gen and execute /usr/sbin/locale-gen. But that's not to say that it's necessary. > - OK if I update the header to GPL v2 or later (rather than v2 only)? I don't care. I copied the header from /usr/portage/skel.ebuild.
Committed to SVN: <http://sources.gentoo.org/cgi-bin/viewvc.cgi/eselect?view=revision&revision=796> I've removed the "update" action for now, and did some cosmetic changes.
I made an honest mistake. I didn't check following document. http://www.gentoo.org/doc/en/utf-8.xml envfile should be renamed from 99locale to 02locale.
(In reply to comment #10) > envfile should be renamed from 99locale to 02locale. Fixed in r798.
The locale module is included with eselect-1.2.14. Thank you.
