LISTSERV mailing list manager LISTSERV 16.0

Help for UNICODE-MARC Archives


UNICODE-MARC Archives

UNICODE-MARC Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

UNICODE-MARC Home

UNICODE-MARC Home

UNICODE-MARC  September 2006

UNICODE-MARC September 2006

Subject:

Re: Character Repertoire Expansion TIme? (2)

From:

Andrew Cunningham <[log in to unmask]>

Reply-To:

UNICODE-MARC Discussion List <[log in to unmask]>

Date:

Wed, 13 Sep 2006 13:41:48 +1000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (99 lines)

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/

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

April 2018
February 2016
September 2013
March 2013
September 2008
December 2007
October 2007
September 2007
August 2007
July 2007
June 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager