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):
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 ... ].
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
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
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
[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.