Bug 128615 - Character set should ISO-2022-JP (Japanese) for ja_JP locale by default
Summary: Character set should ISO-2022-JP (Japanese) for ja_JP locale by default
Alias: None
Product: Fedora
Classification: Fedora
Component: xchat   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Reed
QA Contact:
Keywords: i18n
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-27 08:41 UTC by Nakai
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-27 18:10:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Nakai 2004-07-27 08:41:21 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.6) Gecko/20040510

Description of problem:
IRC charset must be ISO-2022-JP by default for Japanese locales.
(ja_JP.UTF-8, ja_JP.eucJP)
So when user run xchat in Japanese locales, it should set
character set as ISO-2022-JP (Japanese) by default.
Users don't want use a pico seconds of their time to select
the appropriate character set.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run xchat in Japanese locale.
2. Join Japanese IRC channel.
3. Scrambled.

Actual Results:  Scrambled by default.

Expected Results:  ISO-2022-JP by default.

Additional info:

Red Hat/Fedora must always be responsible which Japanese
codeset you are posting to the Internet.

Comment 2 Daniel Reed 2004-07-27 18:10:42 UTC
Unfortunately, the IRC protocol has no standard support for
internationalization. The protocol was not designed to support
explicit negotiation of character sets between users, by channel, or
by server/network, and it was not designed with a way to add such
support as an authoritative extension (however, see below).

Traditionally, all messages sent through IRC are assumed to be using a
modified form of US-ASCII (possibly refered to as the "ascii character
set" with "rfc1459 case mappings"), and it may be a feature that all
messages received by IRC clients are displayed in that character set
rather than their host session's character set (unless explicitly
reconfigured by the user).

An alternative, where the IRC client presumes that all incoming
messages are in the character set of its host session, does not sound
more reasonable than the traditional behaviour.

Another alternative may be available on servers that use the
non-standard 005 "extended version" numeric sent during connect. This
numeric exists on many major IRC servers and includes both "CHARSET"
and "CASEMAPPING" fields, which could be used to tell the client which
character set and case map to use by default (instead of US-ASCII and
the pseudo-Scandinavian "rfc1459" case map). This would be
per-network, however, as it would not be reasonable to have some
servers on a network advertize one character set and other servers
advertize a different one, so it would only make sense for
pure-Japanese IRC networks (it could not be used by a Japanese user
using the Red Hat IRC network, the EFnet IRC network, etc.).

The relevant documentation is RFC 1459 "Internet Relay Chat Protocol"
section 2.2 "Character codes", which specifically states that no
thought was given to character code specification in the protocol.

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