Bug 88605 - msgs/mess.* do not work in some charsets instead of its own
Summary: msgs/mess.* do not work in some charsets instead of its own
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: man   
(Show other bugs)
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-11 11:09 UTC by Andy Shevchenko
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version: 1.5m2-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-19 17:02:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for drop the described problem (6.31 KB, patch)
2003-04-11 11:10 UTC, Andy Shevchenko
no flags Details | Diff

Description Andy Shevchenko 2003-04-11 11:09:19 UTC
Description of problem:
msgs/mess.* do not work in some charsets instead of its own.

Version-Release number of selected component (if applicable):
man-1.5k-6
RH9

How reproducible:
man gggg
in ru_RU.UTF-8 (but man.spec must be rewritten for include
mess.ru into package)


Additional info:
See attached patch and
man.spec %build section will be included next lines (e.g.,for russian)
/usr/bin/iconv msgs/mess.ru > msgs/mess.ru.utf
mv -f msgs/mess.ru.utf msgs/mess.ru

Comment 1 Andy Shevchenko 2003-04-11 11:10:48 UTC
Created attachment 91072 [details]
patch for drop the described problem

Comment 2 Eido Inoue 2003-08-20 19:46:54 UTC
does the patch leave strings that have chars in the A1 to FE range (but ARE NOT
ISO-8859-x... but rather multibyte sequences) untouched?

What about multibyte sequences that use characters from 80 to 9F (GB18030,
Shift-JIS)?

What about 7-bit multibyte ISO-2022? (ISO-2022-JP, which is ascii with escape
sequences)

Comment 3 Eido Inoue 2004-02-19 17:02:41 UTC
this is fixed in man-1.5m2, which normalizes everything to UTF-8.


Note You need to log in before you can comment on or make changes to this bug.