Planet Pattern Language for Software Internationalisation

Planet supports development of internationalised systems. It guides on development process, high-level design, and detailed software design.

This paper, presented at Interact 2001, motivates and summarises the language.

_________________________________________________________________________________

Pattern 1. Export Schedule

Context:

You are beginning a project where users will come from a wide range of cultural backgrounds.

Problem:

Internationalisation is a resource-intensive exercise.

How can you allocate resources at a level befitting the needs of each culture, and at the same time ensure that no more attention than necessary is devoted to any particular culture?

Forces:

 

• You should know which cultures will use your software, otherwise you cannot provide features which meet their needs.
• It is often too expensive to produce for all audiences at the same time. Sometimes, a local version is prepared first and overseas users are considered later on, if at all.
• Introducing a new culture may not be a simple localisation procedure. The new culture may necessitate changes to the core product and this can be painful. As one example, different cultures use different rules for sorting words. An English-language implementation can sort using the “<” and “>” operators, but what if a culture with a different alphabet order is introduced? If the comparisons are scattered across the code, then a programmer will have the unenviable task of replacing each one with a generic comparison function.

Solution:

Produce a schedule which indicates when each target culture will be supported, and how important it is to support each target culture. Some cultures will not use the system until version 3.0 is released, but these cultures should still be considered when version 1.0 is developed. The Online Repository can be consulted to determine which factors vary across the supported cultures. The localisation phase can then address this variation.

In most businesses, interaction with the marketing department will be essential. When considering attractiveness of foreign markets, consider size and value of customer demand, competitive importance of the market, and availability of expertise [28].

At this stage, establish the importance each culture places on different aspects of software. For instance, an empirical study by Evers and Day [11] found that Indonesian subjects, compared with Chinese subjects, were more attracted towards usability than certain other qualities (It must be acknowledged that such studies represent a generalisation, since, in this case, there is much diversity within the Chinese and Indonesian cultures. The study nevertheless supports the argument that perceived importance of software attributes is culture-dependent.). Since you cannot maximise every quality, this kind of information will tell you which areas to focus on for a given culture. Empirical studies can obviously not be conducted for each culture, but there are certain cues which will enable a rough guess. To understand the importance a culture places on different software features:

• Consult stakeholders from each culture.
• Consider whether certain products have succeeded in their target markets due to a particular feature which their competitors lacked.
• Determine if change requests from a particular culture exhibit recurring themes.

Rationale:

Identification of cultures in advance is a prerequisite for a functional core and internationalisation framework which are flexible enough to make changes relatively straightforward.

Examples:

Searching for target markets, choosing how intensive the operation will be, and planning future expansion is a well-established international marketing practice [20].

Uren et al. [34] suggest that marketing staff should develop a list of target countries, even if translation is not immediately required. Luong et al. [22] suggest that developers need to decide between a full localisation and a partial localisation, and also consider whether to ship overseas simultaneously with the local release.

Resulting Context:

If your organisation has not already done so, start creating Culture Models. You may need to update existing Culture Models to reflect any new cultures being considered or to account for aspects of the cultures which are relevant to the new project. Once you have collected Culture Models into an Online Repository, you will be able to create a Multicultural System suitable for cultures mentioned in the schedule.

Note: For the remainder of this paper, the cultures mentioned in the Export Schedule are referred to as Target Cultures.

_________________________________________________________________________________

Pattern 2. Culture Model

Context:

You are working on software projects with Export Schedules identifying which cultures will use the system.

Problem:

The notions of usability and utility are culture-dependent. You have to understand the user before you can begin working towards these qualities.

How do you support development decisions which depend on information about specific cultures?

Forces:

 

• Extensive information may be required to support development decisions, necessitating potentially expensive research activity. This effort will have to be repeated on new projects involving the same cultures unless explicit attempts are made to reuse it.
• It is difficult — sometimes impossible — to reverse-engineer details about cultures just by looking at the resultant product. The Walkman has been successful in America largely due to the fact that people do not want to be disturbed by the outside world. but it was originally conceived by Sony’s co-founder to help listeners avoid disturbing others [26]. An American designer who simply observed a Walkman would probably not be able to predict its designers’ initial vision.
• Even if you can access process documentation such as meeting minutes, information about cultures will be scattered. This will be difficult to find specific information when it is needed during internationalisation and localisation.

Solution:

Construct models of cultures which are relevant to your projects. When you discover new information about a culture, add it to the culture model. To improve opportunities for reuse, these models can, and should, be held in common by the entire organisation, rather than pertaining to a specific project. They are an asset which is refined over time, just like a software library or an estimation technique.

The culture model can also include issues regarding the development process. Luong et al. [22] discuss the English-language ability of the quality assurance engineers they deal with in Japan. Another culture-dependent process is user testing; some cultures appear to be more reluctant than others to criticise a product [16].

Rationale:

Consistent culture models provide a central point for culture-specific details and also help developers compare and contrast cultures. If a developer notices that all of the cultures for a particular program use Latin characters, then the internationalisation phase need not consider the possibility of non-Latin character sets. Localisation will also be more efficient if similarities between cultures can be exploited.

Examples:

There are several well-known culture models in anthropological and marketing literature. In “Understanding Cultural Differences” [15], Hall and Hall explain several culture-dependent variables, e.g. the level of detail people desire when presented with information, attitudes to personal space, whether or not people like to perform tasks in parallel.

Luong et al. [22] provide details on localising for Asia. Numerous business texts describe the intricacies of doing business with, or creating products for, a particular country [18] or region [9].

Resulting Context:

Now that you’ve decided to create a culture model, you’ll need a way to structure it. A culture model can be conceptualised in different ways; an extremely simple form is just an arbitrarily-ordered collection of relevant documentation gathered from various projects. This pattern language focuses on one means of characterising a culture: the Vector Metamodel form.

_________________________________________________________________________________

Pattern 3. Vector Metamodel

Context:

You have decided to create some Culture Models.

Problem:

Culture models can be represented in different ways. The form you decide upon will determine who is capable of using the culture models, as well as the range of activities the models will support.

How do you represent all relevant information about each culture in a form which supports internationalisation processes?

Forces:

 

• A culture model should accurately reflect aspects of a culture which may impact on software requirements. It should facilitate the two internationalisation phases — internationalisation and localisation.
• To ensure that it is always up-to-date, a culture model should be easy for people to contribute to.
• Culture models need to be expressed so as to be easily-accessed and understood by people in diverse roles. This includes software engineers, human factors specialists, anthropologists, marketing staff, and users.
• It should be possible to compare and contrast culture models. A user of the repository should be able to quickly determine how cultures differ from each other, and also notice commonalities.

Solution:

Determine the dimensions of cultures that interest you, and characterise each Culture Model as a vector with a value for each dimension (or “factor”). A culture model is then a description with each dimension defined for that culture, e.g. if you decide the dimensions are language, timezone, and date format, then every culture model in the repository will have those dimensions defined (definitions can be left blank if it’s obvious or not yet known).

There are many potential sources for culture models. These include literature reviews, comments from local branches or consultants, results from requirements elicitation and user interviews, and observations of the system in action.

If desired, divide the dimensions into categories. For instance, Mahemoff and Johnston [23], following a suggestion by Yeo [36], discuss two broad categories — overt and covert factors. The former are obvious, tangible factors (e.g. date format), whereas the latter are ill-defined and potentially controversial. Overt factors can further be divided into several categories: time, language, writing, measures, formatting, and external systems (Table ??). Covert factors are composed of mental approach, perception, social rules, and usage context (Table ??). The overt factors could provide a valid starting point for your metamodel. The covert factors are more abstract and in need of refining before they are placed into a repository. For example, the Perception factor indicates icons should be chosen according to cultural understanding. Instead of including a broad “Perception” factor, it would be worthwhile storing a field for each major icon type you are likely to need. For instance, a “Mailbox Appearance” field if your software provides email. With all of these factors, you will need to filter them according to your organisation’s needs.

Rationale:

The simplicity of this approach makes it accessible to people working in various roles. The metamodel also has a close mapping to software concepts and is closely related to the Name-Value Pairs pattern [29]. A culture vector can be viewed as a data structure, with dimensions and cultural information forming key-value pairs. In some instances, this could be mapped directly into a class or a database table. At the very least, it shows that the classification scheme is well-understood by developers.

If cultures are classified according to the same dimensions, then it is also easy to see where they are alike and where they vary.

Is it overly simplistic to characterise a culture as merely a set of key-value pairs? This depends on how the model is used. While the approach does not lead to a highly cohesive view of a culture, it is certainly a practical way to enable people to use and update a model. Also, Hoft [17] discusses a number of metamodels, all resembling this pattern; each lists several factors by which cultures vary. They mainly vary in the ways they classify the factors, and the amount of attention paid to interaction among the factors.

To avoid oversimplification, the value for each field can be a discussion of options, e.g. for units of distance in America, imperial units are used in some contexts and metric units in other contexts.

Examples:

Del Galdo [10] presents several attributes of cultures. She divides them into categories, depending on how closely they relate to the user-interface. The factors include character sets, numeric formats, and currency formats (non-UI), as well as icons, colour, and screen text (UI). These factors could form an embryo for a metamodel by which to document a culture model. Hoft [17] discusses several well-known attempts to characterise a culture. Generally, these models are based on a number of dimensions, e.g. collectivism versus individualism, attitudes towards time.

POSIX has a standard way to define a locale, according to ordering of characters, output formats, message strings, etc [37]. Java’s Locale class and other libraries provide ways for a developer to identify a resource (WelcomeIcon), and then show how it relates to each supported locale (Hello.jpg, Bonjour.jpg). There is a similar framework available for C++ [21].

Resulting Context:

: You have a consistent structure for your culture models. As you gather culture models according to the vector metamodel, you’ll probably want a way to organise them together. To do this, establish a Online Repository based on a consistent Vector Metamodel.

_________________________________________________________________________________

Pattern 4. Online Repository

Context:

You have begun to maintain Culture Models according to the same Vector Metamodel (i.e. same factors for each culture).

Problem:

As you start accumulating Culture Models, you will realise the need to organise them together.

How can a collection of culture models be organised in a manner which is useful for software projects?

Forces:

 

• Organisation-wide Culture Models avoid duplication; it is feasible and desirable to transfer information learnt from one project into other projects.
• Information about cultures is often discovered in physically distant locations.
• If developers can’t access models quickly and easily, the information will be ignored.
• If developers can’t update models easily, the repository will lose accuracy over time.
• Cultures have relationships with one another. We should be able to capture associations, such as one group being a sub-culture of another group.
• It is useful to look up a specific Culture Model, but there are many other ways people might like to access information during the internationalisation process. Depending on the task at hand, developers may wish to explore the information in unanticipated ways, e.g. comparing two cultures, considering a single factor across numerous cultures.

Solution:

Create an online repository, accessible to the entire organisation. Compose it of Culture Models all based on the same Vector Metamodel.

The following guidelines make it easy to access information in the repository:

• Provide browsing facilities which present each culture and factor. Let the user select a factor (and show how each culture varies on it), a culture (and show all of its factors), or a combination of both.
• Provide facilities to search the Culture Models.
• Link from one model to another if it helps to demonstrate a point of similarity or difference.
• Link to the original artifacts if they are online, or identify sources if they are not.

The following guidelines make it easy to update the repository:

• Facilitate discussion among contributors, e.g. via a mailing list or on the repository system itself.
• Make one individual responsible for managing the overall repository. This role implies promoting the repository within the organisation and chasing results when it is known that valuable information has been attained but not entered.
• For each Culture Model, make one person responsible for maintaining it. Some Culture Models may be maintained by the repository manager, but an expert on the culture is a better candidate.

Large repositories can group Culture Models together, e.g. according to continent. This approach can follow the Composite pattern [13], e.g. a model of Europe contains its own information and also contains child models (France, Italy, etc.). When a user looks up a model, information about its ancestor models are also shown.

Rationale:

Like pattern languages, repositories of this nature help people reuse existing, tested, knowledge. Reuse of proven concepts involving human-computer interaction are particularly helpful, because people’s reactions can be difficult to predict. In the case of interaction with international systems, the case for reuse is even stronger, because more work is required to obtain original knowledge (e.g. travelling overseas, establishing partnerships with foreign consultants).

The concept of grouping cultures serves a couple of purposes. Firstly, it emphasises commonalities among similar cultures, more so than if both cultures had separate, identical, entries. Secondly, there is obviously a great practical benefit: it prevents the need to create and maintain duplicated entries.

Examples:

Fernandes [12] contains some tables showing factors versus culture. However, the text stops short of exhaustively listing this information. One table might show cultures A, B, and C, and a table on other factors might show A, D, and E.

Ito and Nakakoji have prototyped a system for retrieving culture-specific details [19].

The authors are currently undertaking a project to build a web-based repository. The intention is that developers and users from around the world will use and contribute to the database.

Resulting Context:

The repository enables developers to easily access a corpus of culture-specific information. You can use this information to specify a Multicultural System.

_________________________________________________________________________________

Pattern 5. Multicultural System

Context:

You have created an Export Schedule for a new product and it shows that a diverse cultural base must be catered for.

Problem:

How can you create software which is flexible enough to meet the needs of culturally-diverse users?

Forces:

 

• Your system needs to be general enough to accommodate the users’ needs and characteristics, which depend somewhat on culture.
• System features can take on one of several forms. For example, a text field may appear in English or French. For most features, it is not realistic to provide a single form which will satisfy every culture.
• The user is mainly interested in the form which relates most to their own culture, and it is therefore undesirable to provide more than one form simultaneously.
• A software development team is likely to impose its own cultural biases on the target system, best intentions notwithstanding.
• Users from different cultures may use the same software. Your software will become inaccessible to some users if you permanently fix each feature.
• Software should not stereotype the user as belonging to one particular culture. It should let the user tune settings to meet their own particular needs.

Solution:

Produce a single version of the software with each all instances of each culture-dependent feature present. Let the user set their preference for each feature.

The user can then mix cultures by choosing forms of features which have been created with different cultures in mind, e.g. an American can leave text in English, but select a European paper format.

Sometimes, it is impractical to provide all forms of all features. This may be due to space constraints, downloading times, or commercial considerations. In these cases, it is tempting to produce a separate version for each culture. However, a better solution is to keep the software flexible, so that users can add and remove the forms pertaining to a particular culture.

Examples:

Most major operating systems and applications provide versions tailored to specific cultures. Typically, the main difference is language. Other differences include measurement units and currency. Often, it is possible to add culture-specific extensions to the base system, e.g. help files in foreign languages and international fonts.

Unicode, supported in HTML 4.0, is a text format containing characters from every major alphabet in the world. This allows information pertaining to various cultures to be manipulated by the same application.

Resulting Context:

You will need to produce tailored features, specifically Flexible Functions, an Elastic User-Interface, and Targeted Elements. As you develop these features, you will need to develop Cultural Profiles to specify which features relate to each supported culture. Integrated Preferences will enable the user to specify both culture-specific and culture-neutral features.

_________________________________________________________________________________

Pattern 6. Flexible Function

Context:

You are producing a Multicultural System and an Online Repository has been established. You have begun to specify the user-interface according to Elastic User-Interface or you feel that it is more appropriate to specify functionality before the user-interface.

Problem:

A culture-sensitive user-interface may contribute to usability, but it is still possible that the software does not support the tasks users would like to perform, i.e. the functionality lacks utility. These tasks and the context in which they occur can be related to culture.

How do you ensure the software performs the functions that are meaningful and useful to people from different cultures?

Forces:

 

• Software is typically written with specific domains in mind, whether broad (e.g. a spreadsheet) or narrow (e.g. a code inspection tool).
• Domains — whether broad or narrow — are not homogeneous with respect to culture.
• Usability is also influenced by the user’s culture, and usability derives from more than just the user-interface. Flexible searching, for instance, cannot be achieved just by applying Elastic User-Interface.

Solution:

When you generate a new function, check if it is culture-specific, and if so, refine it to meet the needs of your target cultures.

Break the requirements phase into several smaller stages, where each stage consists of creating and/or refining a small set of related requirements. This way, you can progress incrementally, so that each stage can take into consideration the cultures mentioned in the Export Schedule. At each stage, consider the impact on the target cultures. Some cues which might suggest culture is an important factor include:

• a requirement depends upon legislation (a taxation rule).
• a requirement implies an organisational role (only certain people are authorised to shut down the assembly line).
• a requirement is based on a philosophical stance (a teacher can annotate text but a student cannot [27]).
• a requirement is underpinned by certain ethical values (an employee’s email may be reviewed by supervisors).

This process may generate new questions about cultures which the repository should be consulted to solve. If it cannot solve them, seek the most important answers by alternative means (e.g. interviews with domain experts) and update the repository. Once the answers to these questions are known, you will be in a better position to refine the requirements. Your initial idea for a requirement may form the basis of a suitable default (a Universal Default), but you may need to extend it to satisfy all target cultures.

Examples:

Time-keeping variations imply more than just differences in user-interfaces. Each supported calendar format requires functionality dedicated to handle standard operations (e.g. finding weekday from date, incrementing date). The situation becomes even more complex when differences in other areas, like timezones and work cycles, are considered.

Sometimes, a standard function is undesirable or not worth the effort. Japanese dates are stored according to the number of years of the present Emperor’s reign. Lotus learned that a feature allowing users to return the year back to zero was offensive, because it implied the Emperor’s mortality, and removed the feature [12]. Another Japanese example is the suggestion that Japanese users prefer planning ahead instead of trial-and-error [19]. There may be a case for scaling down the Undo function, or not implementing it at all, if a large proportion of users are Japanese.

Currency differences can lead to complicated functionality, especially when conversions are required. The introduction of the Euro is a familiar example. A more complicated example is the currency recorded for transactions. Some countries denominate imports in their own currencies, while other countries denominate imports in US dollars.

Nielsen discussed a French educational product which enables teachers to annotate poems [27]. He noted that in some countries, it would more appropriate to give students the same ability. The decision to include this kind of functionality rests on cultural values such as attitudes to learning and authority.

Resulting Context:

Iterate between this pattern and Elastic User-Interface until you are satisfied with functionality and user-interface structure. Establish a Universal Default for each function in case the user’s culture has not been specifically catered for.

_________________________________________________________________________________

Pattern 7. Elastic User-Interface

Context:

You are producing a Multicultural System and an Online Repository has been established. You have a solid understanding of general functionality after applying Flexible Function, or you feel that it is more appropriate to specify the user-interface before concentrating on functionality.

Problem:

The same functionality can be presented to the user in different ways.

How do you create a user-interface which can be used easily and effectively by all targeted cultures?

Forces:

 

• Different cultures use different schemes for representing information. Text direction, for example, can be left-to-right, top-to-bottom, right-to-left. Relative positioning of graphics and highlighting mechanisms also vary [31].
• Some cultures want more information, or different information, than others. Some cultures are more accustomed than others to inferring missing details [15]. Cultures may also vary in the nature of information required. The right feature cannot just be plugged in later on (e.g. a culture-specific icon or language-specific string).
• Human-human interaction varies considerably across cultures, and this can translate to style of human-computer dialogue, e.g. reactivity versus proactivity exhibited by participants.

Solution:

Design the overall structure for the user-interface flexibly, so that UI elements can subsequently be re-defined and rearranged without massive design changes.

The precise details about what information you are presenting, and how it is arranged will not become clear until the localisation phase. Therefore, develop an elastic user-interface so that the user-interface is not fixed during the internationalisation phase.

As with Flexible Function, break the user-interface specification process into several stages, so that you can plan each subsequent stage in the light of the cultures being targeted.

Two general guidelines apply:

• Consult the repository or use other means (e.g. user testing) to discover how elastic the user-interface structure must be. A culture’s writing direction can indicate the order in which material of a non-textual nature is also perceived. Also, text size will vary due to variations in alphabet, word lengths, grammar, and conventions. This will affect the space allocated for writing.
• Once the overall structure is present, you will have identified the UI elements. However, the precise details of UI elements depend on culture. Therefore, at this stage, identify which UI elements are culture-specific and leave them abstract, e.g. a button to delete a file could be called delete-file and its type simply declared as a button with a bitmap and a label. After this pattern has been applied, an artist performing localisation might create a cross for one culture and a skull-and-crossbones for another, with accompanying labels in the appropriate language.

Rationale:

Complicated changes to the user-interface, such as reversing order of elements, can necessitate widespread code changes if they are not designed for. Also, a common problem is the introduction of a language with text too large to fit in its usual location (e.g. a menu bar or dialogue box) [22]. This would be fairly trivial to prevent if it was known that the language was scheduled for introduction.

According to the Slinky meta-model [8], it is possible to split user-interface, human-computer dialogue, and functional core. Architectures based on Slinky should provide adequate support for developers who wish to create Elastic User-Interfaces. Coldewey’s “User Interface Software” pattern language also covers separation of user-interface and domain [6].

Examples:

Some programs enable text to be shown and inserted in right-to-left as well as left-to-right modes. Farsi support within the Vim text editor [35] lets users dynamically switch between orientations, and can simultaneously show one file in two different windows presented in separate orientations.

The initial website for some browsers depends on the region of the software.

The web supports various layouts. Horizontal orientation of layout (e.g. whether links are on left or right) is correlated with the orientation of text in the originating country [2]. It is worth noting, though, that an individual site generally does not provide more than one layout.

Resulting Context:

Iterate between this pattern and Flexible Function until you are satisfied with functionality and user-interface structure. You can design specific features according to Targeted Element. Establish a Universal Default for the UI structure in case the user’s culture has not been specifically catered for.

_________________________________________________________________________________

Pattern 8. Targeted Element

Context:

You have prepared an Elastic User-Interface.

Problem:

How can you create specific elements to plug into the user-interface framework?

Forces:

 

• The purpose, state, and workings of a user-interface element should be clear from its appearance.
• A user-interface element’s appearance can be misinterpreted if the user’s culture was not considered in designing it. An extreme case is when users are presented with foreign languages, but there are more subtle instances. The famous Macintosh trashcan looked like a postal box to Britons, causing great frustration when they tried to e-mail their work [32]!
• It is also possible for a feature to be correctly identified at a surface level, but still be completely inappropriate. Many applications use hand gestures to represent certain concepts, but some of these are offensive in some countries [12]. Similarly, a given colour can convey different moods, depending on the culture in question [30].

Solution:

For each abstract element contained in the Elastic User-Interface specification, provide an instantiation targeted to each culture in the Export Schedule.

The Online Repository can be consulted for guidance. If it proves insufficient, investigate further and remember to feed results back in to the repository for future use.

Many elements will have a common instantiation for an entire group of cultures. This is where the idea of composite cultures discussed in the Online Repository can be useful. For instance, a group of cultures called “English-language” can share the same text (of course, this would be a compromise because it is preferable to have “USA-English”, “Australian-English”, etc.). Such a grouping system would need to be many-to-many rather than strictly hierarchical, i.e. a country such as England might belong to several groups, e.g. “English-Language”, “Commonwealth”, “Great Britain”.

The Online Repository can help to identify features which are misleading or offensive. However, user testing is also essential since people from external cultures can overlook this kind of problem. In marketing, there are countless examples of brand-names and advertisements which were actually used, despite the fact that any lay-person could see the folly, such as products named after swear-words and products with unwanted functions (many examples are described by Meloan [25]).

Examples:

This pattern is exemplified by any software that supports different languages, address formats, units of measurement, currency, etc. Tools and libraries like Java’s MessageFormat class support the corresponding development process.

The culture-specific partners of the Yahoo! website are another example. They are organised in the same way as their parent, but contain information specialised to their culture, such as weather for certain cities and status of local stockmarkets.

Java’s MessageFormat class allows programmers to specify a culture-specific format without committing to precise data. An English format can be “subject-verb-object”, while a Japanese format can be “subject-object-verb”. Then, only a single statement identifying the subject, object, and verb, is required. This avoids having two print statements whenever a message is generated.

Resulting Context:

The system contains culture-specific elements, ready to be plugged in whenever a user of the appropriate culture requires them. Since it can be expensive to target every element to every culture, provide a Universal Default in case the user’s culture has not been specifically catered for.

_________________________________________________________________________________

Pattern 9. Universal Default

Context:

You have prepared functionality and the user-interface according to Flexible Function, Elastic User-Interface, and Targeted Element.

Problem:

Localisation is costly and requires substantial knowledge about target cultures. Providing many features for many cultures can lead to work in the order of m� n.

How do you optimise resources when there are many features (functions, user-interface arrangements, user-interface elements), each of which depends on a wide cross-cultural base?

Forces:

 

• Features should generally be tailored, because a single version of a feature is rarely adequate for all cultures. If the single version is targeted to one culture, other cultures may suffer; if the version is intended to be universal and not belong to any particular culture, it may be too general and suit no-one at all.
• Tailoring software features to a culture is an expensive, time-consuming activity. It may involve extensive research and requires local experts.
• It is not always feasible to tailor software for small cultures or to cultures that have unique needs that are difficult to implement.
• An Export Schedule cannot always correctly anticipate which cultures will use the software. People from unsupported cultures might move to targeted areas or download software from a website.

Solution:

For each culture-dependent feature in the target system, make a default which is universally meaningful. The aim is to reach a fallback setting in case nothing has been tailored for some cultures. This will never be as good as a tailored feature, but it is better than producing a default which does not consider the cultural issue at all (e.g. one which is only suitable for the developer’s culture).

The following guidelines will help when creating universal defaults:

• Provide text in the most familiar language among supported cultures.
• Endeavour to produce images which are easy to understand and free from cultural bias.
• Since not everyone will know the most familiar language, try to replace text, e.g. button labels, with meaningful images.
• The familiar language may still be non-native for many users. Avoid the use of jargon and concepts which would only be familiar to a subset of supported cultures.
• Avoid concepts which might offend some cultures.

For organisation-specific Online Repositories, it may be useful to include a “Universal” Culture Model in the Online Repository. This would contain organisation-wide defaults. Such a model would be less useful for a repository shared by the overall community.

Rationale:

In some ways, this pattern resembles the naïve approach to internationalisation which claims that we should simply provide universal features. The difference here is that the pattern is seen as a fallback to help reduce development effort, and is certainly not claimed to be ideal from the user’s point-of-view.

Examples:

Numerous websites provide versions in two languages: one in the native language and one in English. English is being used as the language which will reach the most people.

Some icons and metaphors from popular software paradigms are well-understood in different cultures. Web browsers often use left and right navigation arrows. Word-processors and painting programs use a blank page to represent a new document and scissors for cutting. Help is often represented by a question-mark.

Resulting Context:

There is now a default for each user-interface feature, to account for cases when the user’s culture has not been specifically catered for.

_________________________________________________________________________________

Pattern 10. Cultural Profile

Context:

You are designing a Multicultural System.

Problem:

How do you handle configuration of features which are culture-specific?

Forces:

 

• A Multicultural System has a lot of choices because each feature has several culture-specific variants, all of which exist in a single version. Configuring can be time-consuming for users.
• Most users want to begin working on a product right away, rather than exert effort configuring it. There is a probably a good reason why the user has just downloaded or purchased the product, and loaded it up for the first time.
• Users may not be capable of specifying the appropriate settings for some variables, even in their own country. Imagine asking a user to choose among grammatical rules for a grammar-checker!

Solution:

Provide a default profile for each target culture, a profile which specifies the value of each culture-dependent feature. As soon as the user specifies the culture, they can begin working right away, tweaking settings to their idiosyncratic preferences whenever desired.

An additional benefit is that users can dynamically switch between cultures. This may be of use when two people share the same application. It can also be useful to some users who work in different “culture modes”. Some people think in one language while they work, but think in their own language during recreation. The phenomenon of “code-switching”, i.e. alternating between languages, is common when someone has acquired technical skills in a foreign language [14]. Many people in multinational firms may work with software in English, but perform personal functions such as online banking and email in their native languages.

Examples:

The locale library in Linux defines several culture-related options, e.g. language, currency. However, instead of setting these individually, the user can simply set the LC_ALL variable, which ensures each setting is appropriate.

The Dell website [7] has different pages depending on country of origin. Various settings then relate to the country, e.g. support phone numbers, available purchase items.

Resulting Context:

A number of cultural profiles are available. Citizen ID provides a mechanism for the system to determine which profile to adopt.

_________________________________________________________________________________

Pattern 11. Citizen ID

Context:

You have an application with several Cultural Profiles.

Problem:

Versions must sometimes be released separately for each culture, for technical or commercial purposes. More flexibility can be offered if details for all cultures can be incorporated into the same version. However, not all settings can be active at once.

How can the program determine the appropriate settings for a given user?

Forces:

 

• In the absence of other knowledge, the settings are predominately driven by the user’s culture.
• The user’s culture does not normally vary during the same session, or even across sessions.
• Users do not care about the distinction between the present session and future sessions. This is merely a technical reality because of machines being switched off, and limitations of memory and other resources. All a user needs to know is that they interact with the same program at different points in time.
• Information which is well-known to the user and unlikely to change should be represented minimally within the user-interface, if at all.

Solution:

Determine the user’s culture on first use and ensure that this preference persists into the future. Select the Cultural Profile based on the user’s Citizen ID. Typically, the user selects their location from a menu of names or by clicking on a flag or map. The program may also obtain it from the operating system. Once the user has specified their preference, the choice does not have to be shown. It is sufficient to re-display the preference whenever the user starts the program, e.g. on the splash screen. This ensures they have not accidentally set the wrong culture or inherited someone else’s preferences. A similar effect can be achieved with websites using persistent cookies or redirecting to a localised subsite.

When a user specifies or re-specifies their culture, this has the effect of re-setting culture-specific settings.

It may be possible to obtain the user’s culture from the external environment — by querying the operating system or a related product. Use such data as a first guess and confirm with the user on first usage. For instance, if you present a menu of cultures, initially select the best guess.

There will need to be a mapping from each Citizen ID to a particular Cultural Profile. A one-to-one mapping is possible, but it will often not be practical. For example, Canada and USA might have the same Cultural Profile. The operating system might identify users by their country, but this will need to be mapped to the same Cultural Profile.

Examples:

Modern operating systems usually ask the user about their location upon installation. They can use this information to set defaults for timezones, character sets, and other information. Other programs can subsequently query this data to set their own defaults.

Websites often let the user click on a flag or some text to set their language preferences. Alvarez et al. [1] designed a bilingual website which only contains links to the other language from each language’s homepage. Since the user is not likely to change languages, this strategy optimises screen real estate.

Resulting Context:

The users culture is known to the system and will be used to set initial values for culture-specific features, i.e. Flexible Functions, aspects of the Elastic User-Interface, and Targeted Elements.

_________________________________________________________________________________

Pattern 12. Integrated Preferences

Context:

You have incorporated Citizen ID into the overall product.

Problem:

The Citizen ID pattern will inform your programmer about the user’s culture. It is tempting to pigeon-hole a user as a generic American, a generic Australian, etc., but users within the same culture actually vary widely.

How do you avoid stereotyping users?

Forces:

 

• A user thinks of herself as an American, an Australian, and so on; not as an “international user” [3]. This makes an “International Settings” dialogue a bad idea.
• A user’s culture is more than just his ethnic background. A person’s friends, hobbies, or workplace can also act as cultures. Culture is a fuzzy concept.
• There are many more reasons to provide flexible software aside from culture. The user’s tasks and context are also vital considerations.

Solution:

Integrate internationalisation-related preferences with general preferences. As discussed in Citizen ID, when the user sets their culture, this simply has the effect of setting internationalisation-related preferences to pre-defined defaults.

Examples:

Two culture-related settings in word-processors are font choice and paper size. Rather than placing these in an “International” dialogue, the designers typically position them among semantically-related items. Font choice is usually near font style (Bold etc.). Paper size is usually near layout options (margin, headers, etc.).

Resulting Context:

The program accounts for the user’s culture. At the same time, it does not use their culture to force restrictions. You can help the user tailor their preferences by creating Preference Groups.

_________________________________________________________________________________

Pattern 13. Preference Group

Context:

Your Integrated Preferences model identifies all features which vary by culture.

Problem:

Integrated Preferences may contain many variables, culture-dependent and culture-neutral. How do you structure the Integrated Preferences for presentation to the user?

Forces:

 

• Cultural Profile improves efficiency by providing a quick mechanism to set a whole sequence of preferences in one hit. But the user must still tailor Integrated Preferences to their own needs.
• There are often many features to customise. Each word to be displayed is a separate culture-dependent variable. Therefore, customisation can be time-consuming for users.

Solution:

Group related preferences, so that only one choice needs to be made by the user to set all of the preferences in the group to logically-related values. The typical example is a message group: the user sets the messages to “French”, and all of the individual messages are set to “French”.

In some respects, this is like Cultural Profile, which also maps one choice to a number of predefined preference values. However, this pattern relates to subsets of the preferences rather than the overall preference vector. Furthermore, the direct nature of the group is often culture-neutral. For instance, a setting of “I like Warm Colours” might lead to orange buttons, red menus, and yellow backgrounds. This is a choice relating to the user’s favourite colour scheme rather than the user’s culture. Of course, there is still an indirect relationship because certain cultures like certain colours. For this reason, it is useful for the Cultural Profile to contain pre-set Preference Groups. In this example, there will be a “ColourScheme” preference group object relating to warm colours, i.e. a ColourScheme object with the following settings: “Button=orange”, “Menu=red”, and “Background=yellow”. An alternative ColourScheme object might be a cool colour scheme. We can then decide on a default ColourScheme for each culture. For instance, we might reference the warm ColourScheme object as the ColourScheme in the Australian Cultural Profile. If we later decide Americans also like the warm colour scheme, we can refer to the same object in the American Cultural Profile. This is preferable to manually defining the colours for each widget type for two reasons: (a) there is less effort, since the colour scheme has already been defined; (b) the “ColourScheme” Preference Group contains semantic knowledge (i.e. American interfaces default to warm colours) which would not be conveyed if only the individual widget colours were defined.

Sometimes the user can reach inside the group and set individual variables. This might make sense in the colour example, e.g. the user might prefer a different button colour. This is still possible. Other times, the user would be unlikely to change variables inside a Preference Group. If the Preference Group represents translated text messages, the user would likely have no desire to tailor these.

Examples:

Any application enabling the user to specify natural language exemplifies this pattern. The GNU locale environment, for example, lets the user set a LC_MESSAGES variable which causes a number of strings to be translated in a particular language.

The example application, Critique, in Chapter ?? contains an “Evaluation Style” preference. This determines how a score is calculated and what data the user sees; the user only sees data which affects the score. There are two views and two score algorithms, leading to four possible combinations. However, a design decision was made to couple these preferences via the group mechanism, so that only two of the four combinations are possible.

Resulting Context:

The user can tailor their preferences faster. Developers can save effort by capitalising on the tendency for several cultures to prefer the same combination fo settings for some variables.

_________________________________________________________________________________

Pattern 14. Global Data Model

Context:

You have followed the high-level Planet patterns to arrive at a specification of functionality and user-interface for a Multicultural System.

Problem:

How do you structure your program?

Forces:

 

• You need to allow for many parameters to be altered after you release the program. Since you are allowing users to adopt their personal preferences (see Cultural Profile), the number of possibilities is virtually infinite.
• The user should be able to change preferences while the program is running. Their data should remain the same, even though it will be processed or rendered in different ways.
• When you create a new feature, you should be able to tailor to specific cultures in your own time, in accordance with your Export Schedule.
• Some parameters will affect the user-interface. It is undesirable for development of new user-interfaces to hinder development of core functionality.

Solution:

Encapsulate data required to support all cultures in a global data model, independent of the user-interface. The user-interface can observe the model and change itself or update the model when appropriate. The model, however, can be developed independent of the user-interface views. When you decide to store some extra data, you can gradually incorporate it into each of your culture-specific views. The model should encapsulate all data and operations on that data.

The format of the data should enable easy translation to localised formats, if necessary. It is usually okay to store data in the format of a well-supported culture, or the developer’s culture. A word-processor can store page width in inches and convert to centimetres when necessary (although some caution must taken to prevent problematic rounding errors).

If conversion is difficult, the information must be stored in an abstract format. With text messages, for example, it is messy for the entire message to be stored in English. A translator must then perform string comparisons to determine the appropriate local variant. If the English ever changes, all of the localised code must be updated. Instead, such information can be stored as message IDs.

Examples:

Critique uses the ArtModel class (Figure 1. It stores imageFile and ratings, two core objects which are necessary for all cultures.

---

Figure 1: Global Data Model example: The ArtModel in Critique contains core data which is relevant for all cultures.

---

In the Vim text editor [35], implemented in C, users can edit in more than one window. The buffer data structure stores data relating to the text being entered, independent of user interactions. Data stored includes: the text itself, pathname of corresponding file, “dirty” flag (i.e. whether the current text differs from the corresponding file).

Universal Natural Language [33] is an ambitious attempt by the United Nations University to provide “a digital metalanguage” for representing information in a language-independent way. Once it is completed, it would form an ideal format for storing messages in a locale-independent manner.

Large-scale e-commerce websites use a database to track their inventory and keep information about manufacturers, recommendations, and so on. This database is a Global Data Model which can be queried by localised websites.

Remarks:

This pattern, combined with Independent View, runs along the lines of the Model-View-Controller architectural style [24], which has been discussed previously in patterns literature [4, 6, 13]). In Planet, Model-View-Controller is not specifically advised; this would be unnecessarily constraining. The goal is to separate the presentation from the core data; whether MVC, PAC, or other architectural styles are used is a choice for the development team.

Resulting Context:

Your data is stored in a well-contained module and manipulated with culture-neutral methods. You now need to create a Preference Dictionary to determine how it will be viewed and manipulated.

_________________________________________________________________________________

Pattern 15. Preference Dictionary

Context:

You have created the Global Data Model.

Problem:

There are many preferences which can change, some culture-specific and others culture-neutral.

How do you keep track of the parameters which a user can change?

Forces:

 

• Culture Models will change as developers learn more and the actual cultures themselves undergo change. A preference may be culture-neutral one day and specific to culture the next day, or vice-versa. You should not be hindered by such transitions.
• The user can tailor preferences to their own preferences, so culture alone is an inadequate specification of the current “preferences”.
• You will be passing this information around between many modules. It should be as compact as possible.

Solution:

Encapsulate all of the user’s current preferences, whether culture-specific or not, in a single dictionary (i.e. key-value pairs) entity. Each parameter, whether or not culture-specific, has a defined key. The preference dictionary can be passed around and inspected whenever some code needs to perform a task which depends on the preferences.

The nature of preference values will vary widely. They may be a string representing some natural-language text, an image for a logo, or even a reference to a database table. Therefore, you will need to adopt a suitably flexible mechanism for your programming language.

Since some preferences may form a Preference Group, this may be a recursive class. For example, you may have a message preference dictionary inside a global preference dictionary. The message preference dictionary will contain numerous text strings (e.g. English words), but because the entire dictionary is stored as a single reference (“English Dictionary”), all of the strings inside it can be switched to a new language (e.g. to French words) simply by switching the reference to a new dictionary (“French Dictionary”).

Examples:

Java’s ResourceBundle class is used by Critique for all preferences. The PreferenceDialog sets the preferenceBundle object, and it is then sent to the ArtModel, which propagates it to the view. The preferenceBundle is a dictionary with five keys (Figure 2).

---

Keys for the prefererenceBundle dictionary: BackgroundColor FontFamily MessageBundle EvaluationBundle NumberFormat Figure 2: Preference Dictionary example: Critique’s preferenceBundle has key-value pairs for all user-changeable parameters, whether culture-specific or not.

---

In Java, the default values are also specified in the ResourceBundle. Thus, the main code for preferenceBundle is as follows (the structure from the ResourceBundle is adapted from the Java internationalisation tutorial [5]:

public Object[][] contents = {              { "BackgroundColor", new Color(200,200,255)},              { "FontFamily", new String("Courier")},              { "MessageBundle", new MessageBundle_en()},              { "EvaluationBundle", new EvaluationBundleEveryone()},              { "NumberFormat", NumberFormat.getInstance(new Locale("en","US"))}      };        public Object[][] getContents() {          return contents;      }

Note there is an EvaluationBundle and MessageBundle. These are nested ResourceBundles. The ResourceBundles are used in the following way ¹:

ResourceBundle preferenceBundle = ResourceBundle.                         getBundle("critique.PreferenceBundle",currentLocale);      Font frenchFont = preferenceBundle.getObject("FontFamily"),Font.BOLD,30));      ResourceBundle messageBundle = (ResourceBundle)                          preferenceBundle.getObject("MessageBundle");      String scoreMessage = (String) messageBundle.getObject("Score");

The Vim text editor [35] has dozens of options, including culture-related options such as right-left editing and alternative keymaps. From the user’s perspective, these are defined in the same context as all other options, and therefore follow the Integrated Preferences pattern. At the code level, the options are mixed with other options in a global options file:

#ifdef RIGHTLEFT      EXTERN int      p_ari;          /* 'allowrevins' */      EXTERN int      p_ri;           /* 'revins' */      #endif      #ifdef CMDLINE_INFO      EXTERN int      p_ru;           /* 'ruler' */      #endif

Resulting Context:

You have declared the parameters by which your software will vary. Now you need to define culture-specific information relating to the preferences with Best-Guess Locales. If your preferences vary according functionality performed, create Flexible Strategies. Complement your Global Data Model with Independent Views.

_________________________________________________________________________________

Pattern 16. Best-Guess Locale

Context:

You have a Preference Dictionary which identifies parameters by which your software will vary.

Problem:

Although the user can adjust preferences to their own settings, it is important to speed up the process with predefined Cultural Profiles.

How do you support Cultural Profiles?

Forces:

 

• When the user sets Cultural Profile, the software must somehow populate every parameter of the current Preference Dictionary.
• If you try to specify all adjustable parameters for all cultures, you can end up with a huge number of parameters which must be individually entered.
• If you try to specify all adjustable parameters for all cultures, localisation staff will often be duplicating work in their creation and maintenance efforts. If a group of cultures have many parameters in common, this information should not be lost.

Solution:

Create a “global culture” Preference Dictionary object which contains Universal Defaults. For each supported culture mentioned in your Export Schedule, create a Preference Dictionary object which overrides the global Preference Dictionary. The locale-specific vector is used as a Cultural Profile to simplify the user’s task of setting preferences. According to Cultural Profile, the user should be given the option of choosing a culture. This is implemented by setting the “current” Preference Dictionary to the particular Preference Dictionary belonging to the user’s desired culture. Parameters unspecified in the culture-specific vector revert to the global Preference Dictionary object.

The software will then be as specific as it needs to be. If some cultures do not care about background colour, simply leave it unspecified in their Preference Dictionary. The default background colour will be chosen, and a single change to that parameter will then propagate all cultures for which background colour needs no tailoring. For some parameters, it is fine if no culture-specific preferences are provided; these are culture-neutral preferences.

As mentioned in Online Repository cultures in the repository can be related to each other in a recursive manner. If desired, you can extend this concept to a hierarchical view of cultures, in which you progressively become more detailed. For instance, a French-Canadian user could use whatever French-Canadian preferences in the first instance, followed progressively by Canadian, then North American, then global. An alternative way to view this situation is to consider the algorithm for determining French-Canadian preferences: Begin by setting current preferences to global preferenceBundle. This preferenceBundle should define settings for each variable. Then, for all of the variables which are specified in the North American preferenceBundle, set the current preferences to these variables. Do the same for the Canadian preferenceBundle, then the French-Canadian preferenceBundle. The current preferences will therefore end up as specific to French-Candadian culture as possible.

Examples:

Critique supports French and English locales. The English preferenceBundle overrides the default MessageBundle and EvaluationBundle, while the French preferenceBundle overrides MessageBundle, EvaluationBundle, and also BackgroundColor for demonstration purposes:

public Object[][] contents = {              { "BackgroundColor", new Color(100,200,200)},              { "MessageBundle", new MessageBundle_fr()},              { "EvaluationBundle", new EvaluationBundleTeacher()},      };

---

Figure 3: Best-Guess Locale example: The French preferenceBundles overrides the global preferenceBundle. The resulting preferenceBundle is the default preferenceBundle for French users.

---

As explained in the examples for Preference Dictionary, the Vim editor [35] has culture-specific options integrated with other options. Vim also exemplifies Best-Guess Locale because users can start Vim in Hebrew mode or Farsi mode, which has the effect of defining certain options with the appropriate initial values. Below is the code which checks for the Hebrew command-line flag, ’-H’. It sets the current window’s rightleft (w_p_rl) flag and Hebrew Keyboard map (p_hkmap) flag to true.

case 'H': /* "-H" start in Hebrew mode: rl + hkmap set */  #ifdef RIGHTLEFT      curwin->w_p_rl = p_hkmap = TRUE;

Resulting Context:

The user can quickly set up preferences according to their own culture.

_________________________________________________________________________________

Pattern 17. Independent View

Context:

Your Preference Dictionary suggests different views will be provided to the user.

Problem:

The Global Data Model has no user-interface component.

How does the user view and modify the Global Data Model?

Forces:

 

• Your Global Data Model contains a lot of data. Cultures will want to see different layouts and orderings, as discussed in Elastic User-Interface.
• The default views for some cultures should hide data which is irrelevant or offensive.
• Sometimes, the user wants to see the same data according to two different views. This could occur if they are shifting their own “cultural mode” as they deal with different type of information (see Citizen ID), or if they are trying to determine how someone else sees the data.

Solution:

Create one or more views of the data model, and store the user’s preferred view within the Preference Dictionary. You will need a standard view interface, so that different views can be plugged into the user-interface in a standard way.

The different view classes can have different layouts and may hide some information if it is irrelevant or offensive to some cultures. Of course, this flexibly provides only some of the variation in the user-interface. A concrete view class is still parameterised according to other preferences. It needs to query the Preference Dictionary for Targeted Elements like messages, logos, and background colours.

Remarks:

With users from multiple cultures, it is desirable to can show two views of the same data at the same time. This is possible with an MVC approach, but may be more difficult in PAC and other styles.

Examples:

Critique uses the MMVC framework (Chapter ??) to separate the Global Data Model from its views. The ArtModel in Critique is a Global Data Model. ArtViewEveryone and ArtViewTeacher constitute independent views (Figure 4). The model broadcasts its changes to any registered listener, and the views register themselves as listeners.

ArtViewEveryone is the global default and also the English default, and shows details by all raters. ArtViewTeacher shows only the teacher’s view, and is the default French view. This is implementing by making the French preferenceBundle(preferenceBundle_fr) specify EvaluationBundleTeacher as the value for EvaluationBundle. EvaluationBundleTeacher, in turn, specifies ArtViewTeacher as the value for ArtView.

---

Figure 4: Independent View example: Critique’s ArtViewEveryone and ArtViewTeacher are both capable of rendering the ArtModel and the ArtModel does not depend on these classes.

---

As explained in Global Data Model, Vim [35] stores data separately from the user-interface. The main structure which does store the user-interface information is window, which most importantly stores a buffer of text (the data model). It also contains attributes which track its own height, the portion of the buffer being displayed, and the cursor position.

Resulting Context:

The user receives a tailored presentation and the Global Data Model is not coupled to any presentation code.

_________________________________________________________________________________

Pattern 18. Expression Template

Context:

An Independent View needs to output expressions which have culture-specific formats.

Problem:

How can you incorporate culture-specific formats into the Preference Dictionary?

Forces:

 

• Your software probably needs to output text, and in some cases, parse user-inputted text.
• Grammar varies widely, e.g. some cultures say “Subject Verb Object” and other cultures say “Subject Object Verb”. You cannot just write global code which does something like:
  

  print "$subject has sent you a message";

• Grammar is not the only reason why expressions vary by culture. There are many formatting concerns (Table ??): numbers, date/time, addresses, telephone numbers.
• You could treat the different expression formats as a situation where different code is required, and adopt Flexible Strategy for each expression. But this would lead to an explosion of classes in most applications, especially if you did this for every affected text message.

Solution:

Encapsulate each culture-specific expression in a template string. Store the template string in the culture’s Preference Dictionary. Expression templates enjoy native support in many languages, from Fortran’s FORMAT to C’s printf/scanf to Java’s Format. In most cases, it is possible to store the template string in a variable for later use.

Examples:

The number format is flexible in Critique (Figure 5), varying in number of decimal places. The NumberFormat is stored as an entry in the Preference Dictionary. This is not particularly relevant to culture, though the same mechanism could allow for culture-specific formats like “302.100,2” instead of the more common “302,100.2”. Formats for addresses and telephone could be handled in the same way.

---

Figure 5: Expression Template example: Critique’s NumberFormat is stored in the preferenceBundle. It determines how many decimal places are shown for the overall score, and the same mechanism could also be used to show culture-specific number formats as well as formats for phone numbers or addresses.

---

Mozilla is a web browser supporting international audiences ², implemented in C++. It contains a class which provides a common interface for date and time formats, nsIDateTimeFormat. A key method is FormatTime (which is virtual because it has OS-specific implementations):

NS_IMETHOD FormatTime(nsILocale* locale,           const nsDateFormatSelector dateFormatSelector,           const nsTimeFormatSelector timeFormatSelector,           const time_t  timetTime,           nsString& stringOut) = 0;

The implementations of this method use libraries which format time according to locale.

Resulting Context:

You have a mechanism for encapsulating a tailored format into a single object, which can be placed in the Preference Dictionary.

_________________________________________________________________________________

Pattern 19. Flexible Strategy

Context:

Your Preference Dictionary suggests the need for flexible functionality.

Problem:

How can you incorporate culture-specific functionality into the Preference Dictionary?

Forces:

 

• Your software needs Flexible Functions to deal with cultural variation (e.g. taxation rules, operator permissions).
• This type of variation often requires tailored code. Your Preference Dictionary can easily specify a string or an image, but how does it specify a piece of code?

Solution:

Create an abstract class which declares the interface for the algorithm, then create culture-specific implementations of this class.

Remarks:

This pattern is essentially Gamma et al.’s Strategy [13] pattern, re-stated in the context of Planet’s scope and related patterns.

In non-OO languages, it might be possible to store a pointer or reference to a culture-dependent function.

Examples:

In Critique, there is a Flexible Function: the score can be based on the teacher’s ratings or on everyone’s ratings. This is implemented as a Flexible Strategy. Scorer defines the interface for accessing the calculateScore method. The evaluationBundle stores a reference to the class that implements the desired scoring algorithm.

---

Figure 6: Flexible Strategy Example: Critique’s ScorerEveryone and ScorerTeacher allow the scoring strategy to be implemented a flexible manner, determined by the user’s needs.

---

Gamma et al. list several examples of Strategy, although these are for general usage rather than culture-specific.

Resulting Context:

You have a mechanism for encapsulating tailored code into a single object, which can be placed in the Preference Dictionary.

References

This work is licensed under a Creative Commons Attribution 3.0 Unported License.