Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 30469
Summary: | Non-ASCII characters not displayed correctly | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Miloslav Trmac <mitr> |
Component: | initscripts | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED DUPLICATE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | joakim.lemstrom, rvokal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-10-30 00:18:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Miloslav Trmac
2001-03-03 15:24:51 UTC
Still the same, even more visible in UTF-8. Install in cs_CZ (possibly get complete translation from elvis.redhat.com), and shutdown the system. The shutdown messages show two bad characters instead of accented characters, UNTIL portmapper (in my case), which includes /etc/profile.d/lang.sh. Why can't /etc/profile.d/lang.sh simply be included in /etc/rc.d/rc ? The same in 8.0 final. I have a similar problem to recognize non-ASCII chars in portuguese. I've bin using RedHat since 6.0 and I do allways map some vfat drives. Now, for the 1st time, those vfat drives, has well has other things where I've used non-ASCII characters (for instance Kwrite texts) do show a square replacing 2 chars: the non-ASCII one and the next. I've installed RH8 using english, as I always do, and choose pt as a second language. I mainly use KDE. One of the side effects is that directories with non-ASCII chars are locked and cannot be accessed either from the konqueror or from the command line. I have a similar problem to recognize non-ASCII chars in portuguese. I've bin using RedHat since 6.0 and I do allways map some vfat drives. Now, for the 1st time, those vfat drives, has well has other things where I've used non-ASCII characters (for instance Kwrite texts) do show a square replacing 2 chars: the non-ASCII one and the next. I've installed RH8 using english, as I always do, and choose pt as a second language. I mainly use KDE. One of the side effects is that directories with non-ASCII chars are locked and cannot be accessed either from the konqueror or from the command line. l3cc: that is a separate problem, you probably need to change iocharset= settings in /etc/fstab to "utf8" instead of whatever you are currently using. Assuming bug #74701 gets fixed, the translated messages will be used from the start of /etc/rc.sysinit, so the console initialization should be done really early. I have a similar problem using spanish. It seems that some applications such as redhat-config-packages fail claiming about invalid UTF-8 chars. Using konqueror as browser I noticed one more problem. When displaying web pages some of the non-ascii characters are not displayed while others are. The difference beetwen them is the font that is being displayed as in some font packages there where characters missing. Opening the same pages with mozilla result in perfect behaviour because the font used is different. There is the same problem with gvim too,while vim works perfect running in a <c>konsole</c>. It seems not to be a problem with characters missing. In the problem explained above with konqueror, when clicking on "view page source" the fonts are displayed in Kwrite badly as in the navigator. However, if you delete the wrong character in Kwrite you can write the right one with no problem. |