Believe in
the BSD Power!
*BSD I18N Framework Implementation Project
(Citrus Project)
C omprehensive
I 18N framework
T owards
R espectable
S ystems


editor's note: The English version of this document was translated by Warner Losh (imp @ freebsd.org). Thanks, Warner!


To create for the existing BSD series of PC-UNIX (FreeBSD,NetBSD,OpenBSD,BSD/OS) the following things:
  1. Locale/iconv implementation to conform to ISO C/SUSV2
  2. Non-GPL gettext and POSIX NLS catalog implementation
  3. It is a goal to develop system standard multi-script encoding by internationalization of file name
  4. Design and implement multi-script framework.
For now, our goal is the same level of functionality as Solaris7 supports.


Design/Implementation Policy


  • 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
    • Unicode
    • Others
  • 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 not acceptible.
  • 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 cune_t.

locale mechanism

  • 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
    (ISO/IEC 9945-1)
  • JIS X 0202-1998 Structure of character code and expanding scheme
    (ISO/IEC 2022:1994)
  • JIS X 0211-1994 Control feature for coded character set
    (ISO/IEC 6429:1992)
  • JIS X 0221-1995 UCS
    (ISO/IEC 10646-1:1993)
  • Unix(R) System
    Download the Single Unix Specification Version 2 from here.
  • Unicode Consortium
  • X11R6.4
    • xc/lib/X11 lc*.c, Xlc*.h
    • xc/doc/specs/i18n
    (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 project.
  • X11R6.4's xc/doc/CTEXT Japanese edition can also be obtained from the xjman project.
  • RFC 1468 (ISO-2022-JP)
  • RFC 1554 (ISO-2022-JP-2)
  • RFC 2279 (UTF8)
  • I18N Handbook
  • Asian-Language Support in the Solaris Operating Environment Unicode Support in the Solaris 7 Operating Environment

Mailing List

The Japanese mailing list is automatically administered here.

ML Purpose,

  1. Support of implementation work of a locale system conforming to ISO-C
  2. Discussions about a framework of a new system since current system is inadequate
  3. Discussions about implementation of multi-script process
are acceptable. 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.

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.