[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [ubl] UBL, localization (customization)
> Maybe "developing national profiles"? imo profile is a very good term; it is also common in several countries, e.g. the national implementations of EANCOM, which is the globally most important EDIFACT subset with ~100000 user, are called EANCOM profiles. I.e. I'd expect that the term 'National UBL profile' or so would be easy to understand michael dill -----Ursprüngliche Nachricht----- Von: jon.bosak@sun.com [mailto:jon.bosak@sun.com] Gesendet: Donnerstag, 8. Dezember 2005 19:31 An: ubl@lists.oasis-open.org Betreff: 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]