Internationalisation
Dominic Dunlop
peering into its dim light. But I'm not about to fight those individual
smoky flames. I'll just make these points:
1. While ``internationalization'' (abbreviated by the cognoscenti to the
cute, opaque and finger-wear saving ``i18n'' because it has 20
letters) is a nasty construction, it is an accepted term.
2. As well as being a nasty neologism, internationalization is a
misnomer: you can use the facilities it confers, even if your
market is confined entirely to -- say -- Lake Wobegon. It allows
you easily to have different sets of prompts and messages for
Catholic and Lutheran users. Or kids and their parents. It lets
you display and search for Swedish characters if you need to in
order to satisfy the needs of some of your users. It deals with
timezone issues when you want to catch that plane to Florida or
meet that flight from south-east Asia... (Barely resisted
temptation to cross-post to alt.wobegon...)
3. The international information technology standards community is rather
belatedly taking an interest in internationalization. For example,
ISO's working group on POSIX has established a ``Rapporteur Group on
Internationalization''. (And note that ISO spells the word with a
Z: the organization follows the guidelines of the Oxford English
Dictionary, widely ignored in Britain, which favour ``ize'' over
``ise'' in all but a few cases.)
4. I say ``belatedly'' because it has taken the standardizers a long
time to realise that their products should be of equal utility to
all users, independent of the language that they use to
communicate, or the means that they use to represent it. Efforts
to sort out just the lowest level of this problem -- that of
character sets -- have been continuing for years, and look set to
drag on for years more. By the time you get to computer languages,
you have, until very recently, pretty much been expected to be
speaking English. (POSIX is, for largely political reasons, is
treated as a computer language by ISO.)
5. To a first approximation, the internationalization work of two
organizations forms the basis of moves towards international
standards in the area of C and POSIX. These organizations are
X/Open and UniForum (formerly /usr/group). The published POSIX and
C standards (ANSI/IEEE Std.1003.:1988 and ANSI Std. X3.159-1989
respectively) currently embody fairly minimal internationalization
features. Future revisions will have more to say on the topic.
1003.2, the forthcoming shell and tools standard, has a great deal
to say on the issue. X3J16, the newly-formed C++ standards working
group, has internationalization among its fundamental requirements.
6. There's little literature on the topic. Here's what I know of:
- Volume 3 of the X/Open Portability Guide, issue 3 (XSI
Supplementary Definitions, Prentice Hall, 1989, ISBN
0-13-685830-3) defines X/Open's proposals. If you purchase a
system with the X/Open XPG3 brand, you should get an
implementation of this stuff. (Internationalization is
part of ``base'' brand requirements; you don't even need the more
comprehensive ``plus'' brand.) The problem with the XPG is that
it's a definition, not a user's guide: you have to figure out how
on earth to hang all that stuff together and make it work for
you.
- UniForum has published a white paper on internationalization. It
presents a good technical background to the topic, although it's
inclined to rush off into neat details at the slightest
provocation. For copies, contact UniForum at 2901 Tasman Drive,
#201, Santa Clara CA 95054, U.S.A., phone +1 408 986 8840, fax +1
408 986 1645 (sorry, no email address to hand). If there's a
UniForum affiliate in your country, they may have copies too.
(If the document IS NOT freely available, could somebody please
post a correction!) There's a fair degree of commonality between
UniForum and X/Open, particularly in the area of regular
expressions, where (simplifying somewhat) essentially the same
people were involved on behalf of both organizations.
Implementations of the remainder of the UniForum proposals are
not widely distributed or easy to get hold of.
- As part of the ISO POSIX watchdog work I do under the sponsorship
of EUUG and USENIX, I have written two articles concerned with
internationalization: ``Report on ISO/IEC JTC1/SC22/WG15
Rapporteur Group on Internationalization Meeting of 5th - 7th
March, 1990, Copenhagen, Denmark'', and ``International
Standardization -- An informal view of the formal structures as
they apply to POSIX internationalization''. Both appeared in
;login 15:3 (May/June 1990). They were also published in the EUUG
Newsletter (10:2 and 10:1 respectively -- summer and spring 1990).
And the report was posted to comp.std.unix on 14th March.
(Although I regret it's missing from my archive, so I can't quote
a reference.) But, if you can't put your hands on the documents
in those places, mail me and I'll send copies.
- A forthcoming book, Open Systems: A Business Strategy for the
Nineties, by Dr. Pamela Gray (McGraw Hill, late 1990) presents the
business case for internationalization, along with technical
background (written by yours truly).
7. A fundamental concept in internationalization is that it is part of
a two-step process. An application which is internationalized is
independent of any cultural bias. It's also useless. In order that
anybody can use it, a cultural bias of their choice has to be added.
This process is called localization. (The abbreviation ``l10n'' is
not widely used.) The benefit of the two-step approach is that the
first step needs only to be done once, and makes (or should make)
the method of carrying out the second step reasonably obvious. (I
know from experience that replacing with another bias the cultural
bias inherent in an uninternationalized application is a
debilitating and expensive process. Worse, it has to be repeated
essentially in full for each new bias (market) that is desired.)
8. The economics of the two-step approach merit some study, but I have
yet to see any analysis of the subject. It seems to me that the
cost of using internationalization features in an application,
followed by localizing to its first market, is likely to be higher
than that of hardwiring support for a single market. This is
particularly true now, when knowledge of the techniques is not
widespread, and programmers have to be retrained before they can
apply them. (Finding programmers able to take the mental step back
needed to identify those aspects of an application dependent on
cultural considerations is also likely to be a problem.) Only if
and when second and subsequent localizations are carried out does
the payback begin, both it terms of reduced conversion costs, and
(probably) in support costs which are relatively lower than those
for radically hacked versions of an initial non-internationalized
application.
9. A further attraction of the technology under development (it is too
early to describe it as mature, although it's approaching puberty)
is that it should allow non-programmers to perform the localization
step. Now and in the past, when adaptation of an application for a
new market has typically involved heavy-duty hacking, those best
qualified to describe the new culture -- natives educated in the
humanities, and not working for the original developer -- have
typically been barred from involvement both because they are not
programmers and because the original software author is either
unwilling to relinquish any element of control of the source code,
or because the licensing fee demanded for the source is greater than
can be recouped from the new target market. In theory then,
internationalization should make markets more open by reducing
economic and technical barriers to the movement of software between
cultures.
10. Too bad the concepts are not widely known or understood. But we're
working on it...
--
Dominic Dunlop