Fixes PR lib/39662, shortcomings in LC_{MONETARY,NUMERIC,TIME,MESSAGES} db format.
ok'ed by core and releng.
(thanks for agc@, snj@ and i'm sorry for long time patience).
[libc]
- localeio.[ch] and lc*.[ch] in src/lib/libc/locale was replaced by
new locale-db implementation using citrus_db backend,
see src/lib/libc/citrus/citrus_lc_*.[ch].
- add citrus_bcs_strtou?l.c. don't use strtou?l locale implementation
internally, because they're locale-aware function.
- add some stubs for multi-locale issue, see {current,global}_locale.c.
- remove some obsolete file, setrunelocale.c, ___runetype_mb.c.
- remove __savectype() from ctypeio.[ch].
[tools]
- mklocale(1): add new option ``-t'' that generates new style
LC_{MONETARY,NUMERIC,TIME,MESSAGES} locale-db format.
- chrtbl(1): added ctypeio.[ch] for __savectype().
[locale-db]
- added en_US.US-ASCII locale.
- removed some shareable locale definition file:
en_US.US-ASCII -> en_US.ISO8859-1, en_US.UTF-8
zh_CN.eucCN -> zh_CN.GB18030
and more...see src/share/locale/*/Makefile.
- remove obsoleted locale sr_YU, added new locale sr_ME, sr_RS.
- change locale name ja_JP.ISO2022-JP* -> ja_JP.ISO-2022-JP*
for X11's locale.alias file alignments.
- fix regression test, wrong wcs?width(3), NAN/INF usage.
i tested release-build following arch:
i386, amd64, hpc{mips,arm,sh}, sparc64, vax.
citrus_lc_*.[ch] also can read old-plain-text style locale-db.
so that backward compatibility is keeped, but lc*.[ch] can't read
new citrus_db'ed locale-db and localeio.c never check sanity,
so forward compatibility is broken ;-<
old mklocale(1) doesn't know -t option, so you have to rebuild toolchain.
2009-01-02 03:20:18 +03:00
|
|
|
# $NetBSD: sr_ME.ISO8859-2.src,v 1.1 2009/01/02 00:20:21 tnozaki Exp $
|
2008-05-17 07:57:50 +04:00
|
|
|
#
|
|
|
|
# Serbian Language Message Locale for
|
|
|
|
#
|
|
|
|
# WARNING: Empty lines and/or blank spaces may be essential.
|
|
|
|
#
|
|
|
|
# From: $FreeBSD: src/share/msgdef/sr_YU.ISO8859-2.src,v 1.1 2002/10/19 13:04:04 ache Exp $
|
|
|
|
#
|
|
|
|
# Acceptable Affrimative Response Expression (yesexpr)
|
|
|
|
# NOTE: This must be a valid Extended Regular Expression.
|
|
|
|
^[dDyY].*
|
|
|
|
# Acceptable Negative Response Expression (noexpr)
|
|
|
|
# NOTE: This must be a valid Extended Regular Expression.
|
|
|
|
^[nN].*
|
|
|
|
#
|
|
|
|
# NOTE: The following were removed from the relevant standards:
|
|
|
|
# The Open Group Base Specifications Issue 6 (XPG6) and
|
|
|
|
# IEEE Std 1003.1, 2004 Edition (POSIX).
|
|
|
|
# The current NetBSD implementation still requires a value or blank line.
|
|
|
|
#
|
|
|
|
# Acceptable Affrimative Response (yesstr)
|
|
|
|
|
|
|
|
# Acceptable Negative Response (nostr)
|
|
|
|
|
|
|
|
# EOF
|