JTC1/SC22/WG14
N931
ISO/IEC JTC1/SC22/WG14 N931
2000-11-22
Title: report on SC22/WG20 - internationalization activities
Source: Keld Simonsen - liaison to WG20
WG20 is completing a number of its projects at this time.
The sorting standard IS 14651 is now completed and under publishing.
This standard covers a sorting template for all characters of IS 10646,
the big 32 bit character standard. This is done in a POSIX-like enhanced
locale notation, and it should be suited for use in C programs.
A new project has been approved to amend 14651 with new characters of 10646.
An amendment to the TR 10176 annex A has been approved and is under
publication. This is the annex that defines the characters to be used
inidentifiers, and the C99 standard is using the previous version of
this specification. The annex has been enhanced and aligned with Unicode
data, so that also Java now can comply to this specification.
The cultural conventions specification (POSIX locale and charmaps like)
TR 14652 is going out for DTR ballot in December 2000. It contains many
new features, especially to handle all of 10646, but it is backwards compatible
with the POSIX standard. It is designed to be capable of providing data for
all of the C99 locale items, including the newly introduced items.
It has a specification for all of C99 locale data covering the repertoire
of 10646 - so this could be a candidate for an enhanced C locale.
The cultural registry standard IS 15897 is being revised, to be able to
register some more machine parsable cultural specifications, and to be more flexible.
It is going out for CD registration ballot in the beginning of 2001.
This is the standard with which WG14 is registering the C locale.
The internationalization API 15435 is controversial. It had expired its
3 years development time in SC22, but has been extended for one year.
It was originally planned to be specified in a language independent way, with a
normative C binding, but recently WG20 has decided to recast it in a C thick
binding. WG14 has provided input to this standard, and the current draft
is in principle replicating all of the functionality of C99
internationalization apis. What is added is that it is thread safe, and
there are APIs to address all data that can be specified with the cultural
conventions specification, 14652, mentioned above. It also gives support to
10646, without binding it to 10646, in the style of C.
The US and Unicode say that there is no need for this standard, as it is
providing too little, is not tied to Unicode, and that all important
companies already have their cross-platform implementations - a standard
would only mess up the market.
Supporters say that there is a need for the smaller actors in the software
develloping market, that cannot afford to develop their cross-platform
internationalization solutions for themselves, and that good internationalization
support should be an integrated part of a programming language, viz. Java and C++.
I will as liaison to WG20 forward the next draft of the i18n API to WG14
for review and comment. WG20 would also like to know if WG14 find it useful,
and if WG14 would like to use some or all of it.
The existence of WG20 has been debated recently, with the convener of WG20
proposing to close down the working group in a paper to SC22. This position
is supported at least by the US and Japan. It seems though that there is
sufficient support by other national bodies - as manifested eg at the
latest SC22 plenary - for the group to continue its work.