MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] UBL, localization (customization)
[brs@itst.dk:]
| Some quick items on the ubl/localization customization
| subject. Jon had some concerns that the word localization should
| not be used, in the following document from the W3C
| http://www.w3.org/International/questions/qa-i18n the term
| localization is defined:
Yeah, I know. I worked with the W3C I18N people for a while and I
know what they were trying to say.
"Localization" is universally used in the software industry to
refer to the process of making interfaces of an existing product
understandable to people in different countries. It is strongly
differentiated from the functional code itself, which generally
doesn't change. To put it another way, if a change involves UI
programmers, that's localization; if it involves database or logic
programmers, it's not. This distinction is critical in actual
software production, because localization is carried out by teams
far removed from the people who create the functional code and
generally occurs after the original product is already shipping.
Often the team responsible for creating the localized version of a
product is also the one that creates the documentation for that
locale. But they are NOT changing the product itself.
It's probably easier to remember this distinction for people who
were in the software industry when internationalization and
localization became engineering requirements back in the 1980s.
The process of separating out the language-dependent components
(embedded error messages, for example) from running code and
putting those components into translatable resource files -- the
process of internationalization -- was very painful, very
expensive, and not easily forgotten. It took a while for the
process of actually translating the resource files -- the process
of localization -- to become a known part of the production cycle
with its own unique workflow and personnel requirements.
To sum up: If what we're talking about is how to make English UBL
tags understandable to non-English-speaking people in Denmark (all
three of them), that's localization. If what we're talking about
is modifying the data model to suit Danish business practices,
that's not localization. If a team in France were to create a
French user interface to the Danish data model, that would be
localization.
(Having just written this, I see that it's all nicely summed up at
http://en.wikipedia.org/wiki/Internationalization .)
We do need to agree on a term (not "localization," because that
one is already taken) to describe what we're doing when we create
a version of UBL for a place like Denmark. I've been using
"customization," but I'm open to suggestions. Maybe "developing
national profiles"?
Jon
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]