$URL contains some minor errors: a) You don't have to use LC_ALL for UTF-8 usage; LC_CTYPE can do the trick as well. b) Section about kernel configuration could speak about possible usage of modules as well. c) I don't have to set LESSCHARSET on my system and LESS displays UTF-8 encoded files correctly even with only LC_CTYPE=cs_CZ.UTF-8 .
(In reply to comment #0) > a) You don't have to use LC_ALL for UTF-8 usage; LC_CTYPE can do the trick as > well. I think there was an issue with this as some packages weren't picking up the locale correctly? IIRC, SwifT was the one who addressed this in the doc, but I'm not able to find this in the cvs logs. > b) Section about kernel configuration could speak about possible usage of > modules as well. Modules for? > c) I don't have to set LESSCHARSET on my system and LESS displays UTF-8 > encoded files correctly even with only LC_CTYPE=cs_CZ.UTF-8 . Look up man less. If it works without, fine. LESSCHARSET just forces less to use the specified charset and we really don't lose 10GB of space by setting it you know ;) If you can send me a few utf-8 files, I'd be glad to check. As of now I guess LESSCHARSET stays...
(In reply to comment #1) > I think there was an issue with this as some packages weren't picking up the > locale correctly? IIRC, SwifT was the one who addressed this in the doc, but I'm > not able to find this in the cvs logs. I'll talk to him. > Modules for? For selecting NLS support in kernel, code listing 3.1. > Look up man less. If it works without, fine. LESSCHARSET just forces less to use > the specified charset and we really don't lose 10GB of space by setting it you > know ;) If you can send me a few utf-8 files, I'd be glad to check. As of now I > guess LESSCHARSET stays... Check files under gentoo/xml/htdocs/doc/cs/ :-). From `man less`: If neither LESSCHARSET nor LESSCHARDEF is set, but the string "UTF-8" is found in the LC_ALL, LC_TYPE or LANG environment variables, then the default character set is utf-8. If that string is not found, but your system supports the setlocale interface, less will use setlocale to determine the character set. setlocale is controlled by setting the LANG or LC_CTYPE environment variables.
(In reply to comment #2) > For selecting NLS support in kernel, code listing 3.1. Doesn't make any major difference IMHO :) > Check files under gentoo/xml/htdocs/doc/cs/ :-). Will do. > If neither LESSCHARSET nor LESSCHARDEF is set, but the string "UTF-8" is found > in the LC_ALL, LC_TYPE or LANG environment variables, then the default > character set is utf-8. Bug #91777
As fox2mike suggested, I've read bug 91777, but I think that the proposed fix is redundant. Original thread poster (http://forums.gentoo.org/viewtopic-p-2385415.html) used mallformed locale "de_DE.utf8" instead of correct one "de_DE.UTF-8". I've just checked on my system with cs_CZ locale and *both* utf-8 and UTF-8 are supported while utf8 is not.
Additional point: d) Code Listing 3.6 suggests re-emerging slang and ncurses. Portage supports the --newuse flag which is ideal for such purposes: `emerge --update --newuse sys-libs/ncurses sys-libs/slang` e) "If an application has support for both a Qt and GTK+2 GUI, the GTK+2 GUI will generally give better results with Unicode." - any reasons? :-] f) "To build fonts (including the Bitstream Vera set) with support for East Asian letters with X, make sure you have the <c>cjk</c> USE flag set. Many other applications utilise this flag, so it may be worthwhile to add it as a *permanent* USE flag." - IMHO "global" is better.
(In reply to comment #5) > d) Code Listing 3.6 suggests re-emerging slang and ncurses. Portage supports > the --newuse flag which is ideal for such purposes: > `emerge --update --newuse sys-libs/ncurses sys-libs/slang` I think neither of the two is required. Just plain emerge slang will a) pick up the new USE flag and b) install the latest > e) "If an application has support for both a Qt and GTK+2 GUI, the GTK+2 GUI > will generally give better results with Unicode." - any reasons? :-] Because they have better support? Ping slarti for more info, I'm cc'ing him on this bug btw.
(In reply to comment #6) > > `emerge --update --newuse sys-libs/ncurses sys-libs/slang` > > I think neither of the two is required. Just plain emerge slang will > > a) pick up the new USE flag and > b) install the latest Users don't have to re-emerge; it is required only if the USE flag changed.
(In reply to comment #7) > Users don't have to re-emerge; it is required only if the USE flag changed. That goes without saying. They wouldn't be reading the doc IMHO if they were utf-8 compliant :) and if they are to make a system utf-8 compliant, 99% of them would need to re-emerge.
(In reply to comment #8) > (In reply to comment #7) > > Users don't have to re-emerge; it is required only if the USE flag changed. > > That goes without saying. They wouldn't be reading the doc IMHO if they were > utf-8 compliant :) and if they are to make a system utf-8 compliant, 99% of them > would need to re-emerge. IMHO not - they are reading it just because they want to have it utf-8 compliant, and maybe they will find out that they are completed from 73%. Why to force them to do useless compilation?
On the LC_ALL subject: for one, it is easier to set it completely, other LC_'s who do benefit from it take it as well (I think LC_MESSAGES does) and others ignore it. Using specific categories is only usefull when you want to deviate from the default. In this case, we are setting the default. The re-emerge stuff is indeed formulated differently, I'll rewrite to use the more recommended method.
I've fixed the command to update slang/blabla. I left the "permanent" USE flag as-is, I don't think it causes confusion. I also left the GTK vs Qt as-is since GTK just has a better international community working on it afaik.
