From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 Description of problem: Polish output from tcsh in pl_PL.utf8 locale lacks Polish letters. Additionaly tcsh source rpm doesn't compile under .utf8 locales (which is most likely the root cause of the problem). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Set locale to pl_PL.utf8, start unicode on console 2. run: tcsh -h 3. check the output 4. set locale to pl_PL, stop unicode on console 5. run: tcsh -h 6. compare results 7. This will not work under X windows! Why? Well, someone already suggested in some other bug, that locales in X are handled differently Actual Results: Nieznana opcja: `-h' Uycie: tcsh [ -bcdefilmnqstvVxX ] [ argument ... ]. Expected Results: Nieznana opcja: `-h' U?ycie: tcsh [ -bcdefilmnqstvVxX ] [ argument ... ]. Additional info: in actual results &zabovedot; is not visible with unicode. Anyway - utf8 support seems to be rushed through the door. I can understand that some 3rd party utilities may not work with it as you mention in release notes but the fact that some packages in distribution only work correctly with unicode and some without it is unacceptable. I'm rolling back to 7.3 which is a pity as 8.0 has some nice features.
This is still the case with tcsh-6.12-5 in Fedora Core. The way tcsh is localized is that it always assumes a specific charset for every localization. As a result, when utf-8 is used, it just does not work. For example, under ru_RU.UTF-8 all tcsh messages are just empty! P.S. The only work-around I know for this is to erase /usr/share/locale/ru/LC_MESSAGES/tcsh (or at least rename it into /usr/share/locale/ru_RU.KOI8-R/LC_MESSAGES/tcsh). This way I get all the messages in English, which is still way better than not getting them at all.
Still there (tcsh-6.12-7 :-( ).
You really should complain at www.tcsh.org. Last release seems to from 2002, so it's now really a surprise UTF-8 doesn't work. May be translations should be left out since it seems they cause more problems than have advantages.
Re: comment #3. There are two sides to this bug. First, there are no localizations that would work under UTF-8 - this is obviously a tcsh bug. Second, the localization files that do work (just not under UTF-8) are packaged in a way that they get picked up under UTF-8 locales. The second one is a packaging bug, and not tcsh's fault (at least not directly).
triage->easyfix (packaging the locale files under correct directories in /usr/share/locale - see comment #1 - would make things a lot easier).
tcsh does not use gettext to internationalise the messages. It uses some older technique which apparently does not support utf-8 properly (??). The same issue exists with greek (LANG=el_GR.UTF-8). tcsh should be updated to use gettext. Talk to www.tcsh.org to help get this done. If you cannot write under a utf-8 locale with tcsh, please look at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89549 and get someone apply the patch.
Created attachment 101991 [details] Automatically convert message encoding The attached patch against tcsh-6.13.00: * reinstates use of the "$ codeset" extension so that gencat doesn't barf on a non-8-bit locale (like *.UTF-8 or POSIX) * embeds the catalog encoding information in the generated catalogs * automatically converts messages from catalog encoding to the LC_CTYPE-specified encoding. [Largest part of the patch is just the result of rerunning autoconf] With this patch the messages are output correctly in UTF-8 locales for me.
*** Bug 73627 has been marked as a duplicate of this bug. ***
Patch added to tcsh-6.13-1, which should show up in rawhide soon.