Internationalisation

[Dominic Dunlop]

Ho hum.  Been vaguely following this thread, basking in its heat and
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