Re: localeio

["Takehiko NOZAKI" <takehiko.nozaki%gmail.com@localhost>]

hi, all.

my opinions about localeio:

1. please don't install LC_* those codeset is not supported by
iconv_open(3) yet,
such as ISCII-DEV(LC_CTYPE that i maintain keep this rule).

2. LC_MESSAGES locale-db, /usr/share/locale/*/LC_MESSAGES may
conflicts with some gettext(3)'s mo messages catalog.
they're frequentry stored as /usr/share/locale/*/LC_MESSAGES/*.mo .

# in many case, GNU configure set bindtextdonain(3)'s 2nd argument to
# "/usr/share/locale" by default when using -DLOCALEDIR macro.

AFAIK, glibc2 uses /usr/share/locale/*/LC_MESSAGES/SYS_LC_MESSAGES
for LC_MESSAGES locale-db.

# in the past, they had been directly used gettext(3) mo catalog for
# libc's LC_MESSAGES locale-db, /usr/share/locale/*/LC_MESSAGES/libc.mo.

don't forget we already have own BSDL libintl implementation in base.
i believe it is reasonable that /usr/share/locale/*/LC_MESSAGES is S_IFDIR.

3. LC_TIME locale-db still lacks ERA, ERA_D_FMT, ERA_D_T_FMT ERA_T_FMT
langinfo stuffs(and LC_MONETARY locale-db doesn't have CRNCYSTR too).

thus, sooner or later we have to change file format of
LC_TIME, LC_MONETARY locale-db, aim to support such langinfo stuffs.
# as for me(=with ja_JP.* locale), ERA stuff is the very very familiar one.

at this point, no magic, no version controlled locale-db format
is not good idea.

# file format has a big influence on backward binary compatibility.
# we can't easily change file format even if we have to do.

to introduce flexibility, i think it's better to use key-value pair db format.
src/lib/libc/citrus/citrus_db*.[ch] stuff may good for this purpose.
# easy to use as match as plain-text, i believe.

files under /usr/share should be MI,
because these can be shared among different MACHINE_ARCH by NFS etc.
of course db file generated by citrus_db*[c.h] is MI.

# FreeBSD's LC_CTYPE/LC_COLLATE is installed in /usr/share,
# but their format was MD, they don't use intNN_t/uintNN_t stuff and
# pay no attension to byteorder(3)... thus, they shed blood
# at the FreeBSD 6.0-Release, see more:
# http://www.freebsd.org/releases/6.0R/relnotes-i386.html#USERLAND

or use different namespace(as Solaris does) for plain-text db, like:

    /usr/share/locale/LC_TIME/localedb.1

if we change file format, simply change version sufix:

    /usr/share/locale/LC_TIME/localedb.2

old/new ABI keeps very happy(except LC_CTYPE...but it has magic).

4. as for localedef(1), we might have to keep charmap's symbol-name in
LC_* locale-db, because localedef(1) require "copy" instruction such as:

    LC_MONETARY
    copy "en_US.UTF-8"
    END LC_MONETARY

SUSv3 spec is very ambigious about ``where do we *copy* from information?''
if this means:
``copy from /usr/share/locale/en_US.UTF-8/* that compliled by localedef(1)''
 we have to restore from (multi)byte-sequence in plain-text db to
charmap's symbol-name, it is *impossible*(yes i know LC_CTYPE too).

it seems that glibc2 people interprets this ambigiousness that
``let's install localedef src file in /usr/share/i18n/localedef, and
copy from it, yeah!''
but i suspect that this is a result of the compromise.

Solaris, they don't copy information from
/usr/lib/localedef/src/en_US.UTF-8/*.src
but /usr/share/locale/en_US.UTF8/* stuffs, as far as i know from
truss(1)'s output.

# localedef(1) is quite a beast from ``spec then code'' outer space.
# please read my past tech-userlevel's post:
# http://marc.info/?l=netbsd-tech-userlevel&m=120422584723718&w=2

very truly yours.
--
Takehiko NOZAKI <tnozaki%NetBSD.org@localhost>