editor's note: The English version of this document was translated by Warner Losh (imp @ freebsd.org).
To create for the existing BSD series of PC-UNIX
(FreeBSD,NetBSD,OpenBSD,BSD/OS) the following things:
For now, our goal is the same level of functionality as
- Locale/iconv implementation to conform to ISO C/SUSV2
- Non-GPL gettext and POSIX NLS catalog implementation
- It is a goal to develop system standard
multi-script encoding by internationalization of file
- Design and implement multi-script framework.
- For now, a separate library from libc is used.
- One can add new locale and encoding without
recompiling system libraries by dynamic
linking. localedef(1) does this as well.
- The following items are supported
- ISO 2022 series
- 8bit plain (for efficiency, separate
from ISO 2022)
- EUC (for efficiency, separate
from ISO 2022)
- SJIS, GB, KOI8
- System standard for multi-script encoding
- The requirements for encoding is described
as being only that "The encoding must be
32-bit". In other words, any kind of
encoding is acceptable so long as it can fit
into 4 bytes. On the other hand,
design contraints of the class "Encoding must
be ISO 2022" or "Encoding must be UCS4" are
- Possibly the implementation of mulit-scritp
framework is done with this layer. Maybe, in
this case, the API to take charset
information is built for cune_t (cuneiform
type). wchar_t would become an alias for
- Full support of all assocaited functions of
ISO/IEC-C 9899:1990/Amendment 1:1995
- POSIX/SUSV2 conformance
- Support of locale description handle:
In normal ISO C locale, only one locale can
exist per process. By creating local
description handle, even though it is
inconvenence in a lot of cases, multiple
locales can exist in the same process.
ISO C locale(process locale) uses
build-in locale description handle and is
implemented by some form of wrapper function.
Internationalization message catalog
- POSIX standard catalog function (cat*)
- gettext function
iconv/extension conversion API
System standard multi-script encoding
- There's a good chance that something based
on ISO 2022 will be adapoted.
- Development will fundamentally be for
Fixed Width Compound Text and File System
Safe Compound Text.
The license is still ambiguous at this point, but it
will be either a BSD Style License or use perl's
model. In addition, "the license must allow for
BSD/MIT/(L)GPL uses of the code". This allows the
possibility that it will be picked up by X or glib.
However, it is only a "possibility". To be honest,
so far there is not schedule to do port to glibc
strictly. The X Consortium may be interested in
iconv for its X-TT or Unicode support.
A person offering code for this project must agree
to it being distributed with this license
condition. In addition, copyright of this project
is added to the source code. Of course the original
copyright is left in place as well.
- JIS X 3010-1996 Programming language C
(ISO/IEC-C 9899:1990/Amendment 1:1995)
- JIS X 3030-1994 POSIX part 1
- JIS X 0202-1998 Structure of character code and
- JIS X 0211-1994 Control feature for coded character set
- JIS X 0221-1995 UCS
- Unix(R) System
Download the Single Unix Specification Version 2 from
- Unicode Consortium
(which is an incomplte locale). The model of
implementaion for locale/encoding is well liked.
The latter can be obtained in Japanese from the xjman
- xc/lib/X11 lc*.c, Xlc*.h
- X11R6.4's xc/doc/CTEXT
Japanese edition can also be obtained from the xjman
- RFC 1468 (ISO-2022-JP)
- RFC 1554 (ISO-2022-JP-2)
- RFC 2279 (UTF8)
Asian-Language Support in the Solaris Operating Environment
Unicode Support in the Solaris 7 Operating Environment
The Japanese mailing list is automatically administered
Specically, please only talk only about this
implementation and how to solve the problems rather than
asking basic questions like "How do I use this locale?"
or "What is libc and why aren't you part of it?"
The topic under discussion can be difficult to
understand. It is not intended for newbies or those
that don't understand the basics. Please do not post
newbie questions to the list. No "squid" posts, please.
- Support of implementation work of a locale system
conforming to ISO-C
- Discussions about a framework of a new system
since current system is inadequate
- Discussions about implementation of multi-script process
To subscribe to the list, send mail to bsd-locale-ja-ctl@hauN.org
subscribe Akari KAMIGISHI
in the body.
Your subscription request will be authenticated.
The address of mailing list is
bsd-locale-ja@hauN.org. Do not send subscribe mail to
this addres. Instead use the control address
bsd-locale-ja-ctl. If you did not subscribed, your mail
would be rejected from the mailing list.
FML is currently used in addition to above.