I'll try to be as brief a possible.
Probably best to explain firstly that the area I work in is more
focused on web internationalization rather than software
internationalization. I'm interested in how client software and web
services interact with more standard systems components such as input
and font rendering technologies. And how out put meets accessibility
and internationalization best practice. I.e.. hoe useful and usable it
is for the end user trying to search and access information or
resources in a language other than English. Essentially to
successfully type, display and search online catalogues.
For a definition of internationalization, I tend to use the W3C
Internationalization WGs definition:
Internationalization typically entails:
1. Designing and developing in a way that removes barriers to
localization or international deployment. This includes such things as
enabling the use of Unicode, or ensuring the proper handling of legacy
character encodings where appropriate, taking care over the
concatenation of strings, avoiding dependence in code of
user-interface string values, etc.
2. Providing support for features that may not be used until
localization occurs. For example, adding markup in your DTD to support
bidirectional text, or for identifying language. Or adding to CSS
support for vertical text or other non-Latin typographic features.
3. Enabling code to support local, regional, language, or
culturally related preferences. Typically this involves incorporating
predefined localization data and features derived from existing
libraries or user preferences. Examples include date and time formats,
local calendars, number formats and numeral systems, sorting and
presentation of lists, handling of personal names and forms of
address, etc.
4. Separating localizable elements from source code or content,
such that localized alternatives can be loaded or selected based on
the user's international preferences as needed.
You need to separate internationalization issues into 3 components.
1) The MARC standard. Not too much to say here, other than there needs
to be an awareness that with the new proposals its now unclear what
the primary character set for MARC is. The second issue to keep in
mind is that the MARC model doesn't fit into defined Unicode
Normalization forms.This has implications for web based output and
processing in third party applications outside of library systems.
2) Issues relating to client applications (although some of this is OS
dependant) involves Unicode normalization issues, bidirectional
algorithm support, support for including appropriate handling of bidi
embedding levels, font linking technologies, input from OS and third
party IMEs and input mechanisms, font rendering technologies used by
clients. Within a Windows environment, whether the applications have
been written using a Windows 95 internationalization paradigm or a
Windows 2000/XP internationalization paradigm. There is a fundamental
difference in how applications are written/design and the range of
languages they can practically support.
What version of the Unicode standard they support is also an issue,
since there can be important differences between certain versions,
i.e. Myanmar in Unicode 4.1/5.0 as distinct from the PDAM4 proposals
for Myanmar.
3) Web internationalization would include language tagging (also a WAI
priority level 1 checkpoint), abstracting presentation and structure
to allowing appropriate styling by language. For instance being able
to display romanized titles, etc using an appropriate OpenType, AAT or
Graphite font to handle combining diacritics. Bidi markup. Typographic
considerations in
I'd also add normalization of content in web pages (and search
mechanisms) to meet W3C recommendations, transliteration and
transcoding features for web services. Conversion of language tags
used in MARC records to appropriate tags in HTML and XML documents.
From the point of view of the web, MARC-8 is never used to display
data to an end user through a web interface, the encoding needs to be
converted. On the web the only practical encoding to convert MARC-8
data is UTF-8.
On 13/09/06, Joan Aliprand <[log in to unmask]> wrote:
> Andrew:
>
> You've used "internationalized" and "internationalization" in a couple of
> postings. Could you explain your interpretation of these terms in a bit more
> detail, in particular, their application in a library context?
>
> Thanks -- Joan Aliprand
>
--
Andrew Cunningham
Language IT support
Dinka Language Institute
Australia
http://home.vicnet.net.au/~andrewc/
http://home.vicnet.net.au/~agamlong/dlia/
http://www.openroad.net.au/languages/african/dinka/
|