[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
my opinions about localeio:
1. please don't install LC_* those codeset is not supported by
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:
or use different namespace(as Solaris does) for plain-text db, like:
if we change file format, simply change version sufix:
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:
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
but /usr/share/locale/en_US.UTF8/* stuffs, as far as i know from
# localedef(1) is quite a beast from ``spec then code'' outer space.
# please read my past tech-userlevel's post:
very truly yours.
Takehiko NOZAKI <tnozaki%NetBSD.org@localhost>
Main Index |
Thread Index |