From isaak@csac.zko.dec.com Thu Aug 19 07:12:18 1993 Received: from crl.dec.com by dkuug.dk with SMTP id AA04641 (5.65c8/IDA-1.4.4j for ); Thu, 19 Aug 1993 17:45:34 +0200 Received: by crl.dec.com; id AA26496; Thu, 19 Aug 93 11:10:31 -0400 Received: by csac.zko.dec.com (5.65/fma-100391/BobG-15-Feb-93);id AA02931; Thu, 19 Aug 1993 11:12:18 -0400 Date: Thu, 19 Aug 1993 11:12:18 -0400 From: isaak@csac.zko.dec.com (Jim Isaak-respond via isaak@decvax.dec.com) Message-Id: <9308191512.AA02931@csac.zko.dec.com> To: sc22wg15@dkuug.dk Subject: I18n part 3/7 X-Charset: ASCII X-Char-Esc: 29 Return-Path: codjig::abyss::SATO_TAKAYUKI_K/HP8900_HQ////////HPMEXT1/TAKAYUKI#b#K#b#SATO#o#HP8900#o#HQ@opnmail2.corp.hp.com Received: by csac.zko.dec.com (5.65/fma-100391/BobG-15-Feb-93); id AA23248; Wed, 18 Aug 1993 20:29:40 -0400 Date: Wed, 18 Aug 1993 20:29:39 -0400 From: codjig::abyss::SATO_TAKAYUKI_K/HP8900_HQ////////HPMEXT1/TAKAYUKI#b#K#b#SATO#o#HP8900#o#HQ@opnmail2.corp.hp.com To: isaak@decvax.dec.com Subject: WD3A(3/7) ....................................................................... This is part 3 of 7 of Working Draft ver.3A (WD3A(3/7)) of the "Framework, requirements and models for internationalization 5. Models of internationalization Today, there exist different, inconsistent and/or incompatible internationalized implementations of information systems. A given implementation may be appropriate for a given user, but all solutions are not necessarily useful for those who are outside that particular environment. In other words, each internationalization method has some merit, and it is not possible to select one, and only one, solution which meets all of the requirements of every user and application. While these different solutions may all have good reasons for existing, the goal of internationalization is to minimize diversity and unify the different approaches as much as possible. So, these useful but different solutions carry with them the risk of inadequate solutions for a target application. It is very difficult to select the right solution from functional specifications. Furthermore, it is necessary to understand the relationships between different models in order to select the correct internationalization solution. More importantly, standard providers need to understand differences between models in such a way that the standard specifies the most adequate internationalization functionalities, and/or selects functionalities under the uniformity requirement. It is therefore very important that the standardization body be organized in such a way as to take into account each of the different approaches/models for internationalization. This section describes the different internationalization models. As is the case with internationalization itself, it is very difficult to explain the models themselves from a single of view. Therefore, this technical report describes the models from three aspects as follows: - Surface Functionality Models - Application Models - Architecture Models The Surface Functionality Models present a conceptual positioning of internationalization within information technology, and describe all possible requirement combinations from the surface of information systems (which drives different models). The Application Models group internationalization solutions (mostly still functionality viewed from the surface). The Architectual Models present a model of the structure(s) of computer systems to accommodate internationalization requirements. This section also describes historical differences in incorporating i nternationalization requirements into information systems. This historical classification may provide readers of this document with a bird's eye view of existing solutions. 5.1 The Functional aspect Models of Internationalization At the beginning stages of planning the conceptual model for internationalization, we need to consider the several kinds of independent aspects of information processing systems. The following aspects are important for internationalization: - Coded character set independence - Language independence - Culture independence Following aspects are being expressed by internationalization experts: - Implementation Approach Differences - Culture & Custom and Language Coverage degree differences - Necessary Cultural Elements Differences - System Development/Maintenance process Differences - Multilingual and Multicultural Environment In most cases, the requirements for the above "Differences" are independent of each other. Thus many combinations of each "Differences" are possible. 5.1.1 Ternary Tree for Surface Functionality Models of Internationalization Consolidation of all the discussions concerning internationalization has led to the ternary tree model shown as Figure 4 for the conceptualization and aspects of the surface functionality requirements of internationalization. Note that most classifications and explanations can be done on the basis of the three-dimensional or three-axis world. ---- Following ASCII picture is for flat file version, Hard copy version has cubic picutures ---------------- Functionalities of information technology -+ | +-----------<-------------<----------------+ | | | +---- Generic functionality aspect +------------+---- Social aspect +---- Cultural aspect ---------+ | +----------<---------------<----------------+ | | +---- Application-oriented culture +-->---+---- Organization-oriented culture +---- Region-oriented culture (internationalization)--+ | +-----------<-----------<------------<-----------------------+ | | +--- Implementation approaches ----------------> to more detail +---->--+--- System structure and Maintenance approach-> to more detail +--- Support Degree (of elements)------------+ | +-------------<-----------<-------------<------------+ | | +--- Cultural & Custom elements +----->---------+--- Target cultures ----------------> to more detail +--- Scripts Figure 4 Ternaly Tree for Surface Functionality Model 5.1.1.1 Cultural aspect (and Generic functionality/Social aspect) The functionalities of information technologies can be divided into three categories as described in Figure 5: Functionality of information technology-----+ | +-----------<-------------<----------------+ | | +---- Generic functionality aspect +------------+---- Social aspect +---- Cultural aspect ---------> Figure 5 Functionality cubic model of information technology 1) "Generic functionalities", 2) "Social-oriented functionalities" and, 3) "Cultural-oriented functionalities" Functionalities of any information systems in use in practice can be categolized as aboves disregading the provider(s) of the system(s) inteded to do so or not. The generic-type functionality is a basic and common functionality that provides the primary contribution to users. Generic functionalities on their own cannot operate with maximum efficiency onece systems installed for real life use. They need to work as part of a whole with functionalities such as security and maintenance, which are social-type functionalities. But in order to achieve "user friendliness" to let people use the system, a third categoly of independent functionality needs to be recognized, that is, functionalities which are cultural in nature. Internationalization is mostly dealing with a part of cultural aspect functionalities. 5.1.1.2 Region-Oriented culture (and Application/Organization-oriented culture) There are several kinds of categories that can be considered within the cultural aspect. Among them, Application, Organization and Region-oriented cultures are the most important categories. (Figure 6) Cultural aspect ---------+ | +----------<---------------<----------------+ | | +---- Application-oriented culture +-->---+---- Organization-oriented culture +---- Region-oriented culture (internationalization)--> Figure 6 Cultural aspect cubic model Each application field needs to have optimized the efficiency of the user interface for maximum usability in that target field. For example, generic graphic software cannot satisfy the mechanical drawing application user even if its base technologies are the same or similar. This fact demonstrates the need for customization for applications oriented to aculture. Normally, the adaptation of software to specific application fields is accomplished by designing a software for the application field, and/or achieved through customization of generic functions on the part of each customer. The application field is not the only catalyst for customization. Even if the application field is the same, each organization (such as military, manufacturing companies and trade firms) also has its own customs and terms. In order to achieve user friendliness in each organization, it is necessary to adapt to those organizational differences. Historically, the work necessitated by this type of adaptation has been done by in-house software specialists within each organization. The geographical culture environment involved also needs to be taken into consideration. Computer systems need to adapt to these types of cultural requirements in order to maximize user friendliness in each geographical area. If the user encounters elements indicating geographical references that are not his/her own, it is clear that the product has not been internationalized and does not meet his/her needs. On the other hand, for information system provider(s), those geographical cultural dependant functions are so natural for the provider(s), the provider (s) concern on other geographical cultures are far less than that for other categoly of caltures. (and thus, provider did hard code the culture). Special attention should be taken in account to support the geographical culture to make the system usable internationally. For our purposes, internationalization will be considered to be the provision of a service that accommodates regional/country/geographical cultural differences. This technical report deals with this aspect of product adaptation only~ and will not address application/organization-oriented culture adaptation. 5.1.1.3 Degree of coverage (and implementation approach, Cultural Elements ) Supports for region-oriented culture (internationalization) involves three separate aspects: 1) differences in implementation approaches, 2) System structure and Maintenance approaches, and, 3) the degree of support for internationalization elements as shown in Figure 7. Different requirements for each aspect leads to differentinternationalization models. Region-oriented culture (internationalization)--+ | +-----------<-----------<------------<-----------------------+ | | +--- Implementation approaches +---->--+--- System structure and Maitenance approaches +--- Support Degree (for cultural elements) ---------> Figure 7 Region oriented culture cubic model Even if surface functionalities for users are the same, there are a variety of ways to provide the functionalities for real use. The internal differences may harbor potential problems for the future. Implementation differences are not only the result of the involvement of different developers, but are also due to historical reasons (starting from local customization as explained before). It started as the modification of hard-coded cultural dependency, and now, the internationalization/localization model is recommended. The differences in implementation approaches is therefore discussed in the hist orical differences section. Similer to the implementation approach difference, there is a difference for the system structure to support international requirements. Most of the cases, the requirements can be organized into layered structure, then, necessary change of the data contents in one of the layer for the requirements can fullfil the needs. But one can invent one's original layered structure freely. In additon to that, if the fact that system provider belongs only one culture, and never in multiple cultures, maintenance of localized system by original system provider should be another concern. The maintenability (and also re-localizability) of the ststem is highly depends on the structure of the system. The detailed discussion of the structure of the system is described in different section. Even if implementation approaches to, system structure for and support mechanisms for cultural elements are the same or similar, the requirements for the degree of support for cultural elements differ. The result may be a totally different definition of internationalization. 5.1.1.4 Target Culture, Script and Cultural elements. Support Degree -------------------------+ | +-------------<-----------<-------------<------------+ | | +--- Cultural & Custom elements +----->---------+--- Target cultures +--- Scripts Figure 8 Support Degree cubic model The degree of support for each internationalization elements is a key to differences between internationalization models, as well as to the implementation approaches and system structures described earlier. The degree of support has three independent aspects: the degree of support for cultural and custom elements, target cultures and scripts as shown Figure 8. Even if the target culture for internationalization is the same, support requirements for scripts might differ from user to user. Details of the degree of support are described in a separate sub-section. 5.2 Three-dimensional aspects of degree of support requirements The three aspects of the degree of support described in section 5.1.1.4 are used to make up the three-dimensional picture of internationalization requirements. A cube illustrating the three aspects provides a tool useful for explaining different internationalization models up to the present day. (In surface functionality models) 5.2.1 Scripts aspect As described in section 4, different scripts is one of the key differences between cultures. At one time, there was an assumption that each language had its own script to provide its expression. This is not necessarily so - in many languages, several languages are sharing one script. In the modern world, cross-cultural communication is on the rise and as a result, multiple scripts are sometimes necessary to represent an idea even in one language. The existence of multiple scripts forms an integral part of internationalization, and it is not sufficient to simply list them (see section 5.1.1.3), "How many scripts need to be supported ?". This is one important difference determining different models for internationalization. 5.2.2 Cultural element aspect In addition to the question of different scripts, there are many cultural elements that must be supported in order to achieve optimum user friendliness. Each of these cultural variables plays a role when developing an internationalization model. "Which cultural elements are to be supported?" is another aspect of the degree of support question. 5.2.3 Target culture aspect Once the necessary scripts and cultural elements are defined, then the question becomes "To which cultures do these apply?". Even if selected scripts and cultural elements are identical, these behave differently according to the culture in question. Therefore, it is necessary to define the target culture(s) as independent from script and cultural elements selected. 5.2.3.1 Country and Culture "Once the country name is defined, the necessary script and cultural elements are automatically defined". This old-fashioned model is no longer valid. Multiple cultures and languages can co-exist within one country. Thus, identifying the culture(s) is far more important than identifying the country. and this principle is also to be applied to "language". "Even the language name is defined, it is NOT necessary to mean that script and cultural elements are automatically defined". However, some countries (and languages) have (and will have), national "defacto"behavior standards for script and cultural elements. In this case, the country name would still be an important parameter. Note: the separation of the scripts and cultural elements from countries and/or languages is one of the key message of this technical report. 5.2.3.2 Mono- and Multi-culture The discussion provided in section 5.2.3.1 gives an idea of monoculture requirements and multiple culture requirements. Some requirements would apply to a single culture which would fall under the category of monocultural requirements, and some may request a solution for multiple cultures, which is to be called a multicultural solution. Discussions relating to questions of mono- (or bi-) lingual solutions vs. multilingual solutions used to deal with scripts and target cultures at the same time. This technical report, however, is making a clear distinction betweenthese two elements. Multilingual requirements can be separated into mono-culture/multiscript and multi-culture/multi-script multi-culture/mono-script solutions under this heading. 5.2.3.3 Global uniformity Multiple solution requirements for the same cultural element invites the opposite idea of "global uniformity". >From a target culture point of view, this "global uniformity" is to be classified as one of many target cultures (which is using international standards). 5.2.3.4 Cross-cultural friendliness In a sense, the "Cross-cultural friendliness" concept is one special kind of the "Global uniformity" concept, and so this is also categorized as one of the target cultures. 5.2.4 Three-dimensional definition of internationalization models. By using the support degree cube, it is possible to explain most internationalization models. On one axis of the cube, all kinds of scripts are to be plotted, and the 2nd axis is to be used for plotting cultural elements and the 3rd for plotting target cultures including the "Global uniformity" and "Cross-cultural friendliness" principles. Thus, a traditional monolingual model can be defined as one with a selected culture, script and necessary cultural elements. Therefore, the internationalization of monolingualism can be defined as "High mobility of moving cross-sections" of selected scripts and target cultures, And multilingualism can be defined as a plane or sub-cube within the cube. For example, if several scripts are needed for some cultures, the model can be defined on the cube by picking necessary scripts, that of the culture, and cultural elements which make one plane within the cube. If multiple cultures are necessary, the target cultures, scripts and cultural elements would make small sub-cubes within the cube. 5.2.5 Implementation history --- To be filled in later --- 5.3 Physical application models The surface functionality model covers almost all possible requirement combinations for internationalization. However, because it also tries to cover a wide range of requirements, it may be easier for the reader to have a separate section explaining the typical internationalization requirements. This section is the "reader friendly explanation of typical internationalization models". In order to organize the services in support of typical models of internationalization, five typical application models will be defined. - Culture specific - Mono-lingual - Dual-script - Consecutive multilingual - Concurrent multilingual When dealing with an application which can migrate to one of these models, it will provide a range of services to assist in the internationalization of the application. Note that this is not a classification of all applications. Culture specific Assume that the first target market is a market in which some functionalities are not necessarily embedded into the original application, functionalities which are actually missing but are required by another cultural environment, and functionalities which inherently have to do with one or more particular culture. These are some of the factors that result in reinvented/redundant type implementations when adapting to other cultural requirements, and with some work the application can be evolved to eliminate them. Other types of cultural dependencies might be grammar checks for a specific language or software which translates one language into another. An application which has inherent cultural dependencies is called culture- specific. It would not make sense to localize a culture-specific application to a different culture. Instead, one would provide a different application with perhaps an analogous functionality. Mono-lingual Some applications are inherently monolingual, they can only process text data consisting of a single language. However, the generic applicability of the application might make it desirable to localize it to process data across a wide number of languages. Dual-script Sometimes there might be a bilingual need, for example to process ASCII and Catalan simultaneously. For historical reasons, many users want applications, and by extension, platforms to support ASCII and one other arbitrary language. These bilingual applications and platforms are usually implemented by combining the local language's character repertoire with an appropriate subset of coded character set. This creates, from an electronic information processing perspective, a new and potentially more complex language to process. Bilingual applications are therefore simply a special case of monolingual applications from an architectural perspective, but occasionally it is useful to discuss them separately. Consecutive multi-lingual When implementation of an application treats two or more languages separately and switches between them as it processes its data, this implementation is said to be consecutively multilingual. To facilite its visualization, think of the data as being separate blocks of text, with each block being only in one language. For example, these applications could use the "setlocale()" function specified by ISO 9899 (C Language) and ISO 9945 (POSIX) to switch between language processing facilities. In a consecutive multilingual application, an operation such as collation could operate on a list of strings within a block of text in only one language. Concurrent multi-lingual Concurrently multilingual applications process data which inherently contain several languages. These data could be intertwined to arbitrary complexity, and they typically require the use of a compound document data structure. The fullest extent of our internationalization vision would have operations such as collation operating on lists of multilingual strings, but the result of such operations are not well defined today. Specific applications can fall loosely into one of these categories either because of some inherent functionality reason, or for historical implementation reasons. An example of the former might be an application whose essence is to process a particular data structure which is not easily changed to deal with more than one language at a time. Of course any program which deals, explicitly or implicitly, with either the structure of a language or with a particular coded character set will tend to be culture-specific, and considerable re-designing effort may be necessary in order to attempt to rectify this. ------end of WD3A(3/7)--------