Documents menu

Cultural Questionnaire: Result

By Krista Lagus
30 Jannuary 1995

A few months ago, I posted a questionnaire about cultural issues to this groups. 15 people contributed, and partly based on insight gained from those answers the following article was produced, to be a part of the Glossasoft project deliverables.

To get more info on the project which deals with software localisation and internationalisation, see the URL

<http://www.vtt.fi/tte/glossasoft/glossasoft.html>

At some point we may publish some of the results also there. Currently, there are no actual results there yet, just general info.

Thank you for the interest,

Krista Lagus, VTT E-mail Krista.Lagus@vtt.fi

CULTURAL DIFFERENCES AND LOCALISATION

There is an unlimited number of potential traps for a localiser when cultural issues are considered. The more diverse the set of cultures the software is expected to be used in, the more analysis and comparative work is needed. An attempt to provide an analysis which would aim at any kind of completeness is beoynd the scope of this presentation.

In the following, a couple of examples of culturally dependent issues related to software development are presented. The peculiarities of colours and icons are discussed, and some examples are presented on the variety of interpretation that may exist in regards to them.

1. COLOURS

Many of the interpretation of colours are common across cultures and nationalities. However, there may be a lot of local variation due to the local traditions and environment of the culture.

Some of the aspects that partially define what a colour may signify, are listed below. These should be considered when localising a product into a specific culture:

• skin colour of people,
• colours of the national flag, and
• colours that political parties or movements have chosen as their sign.

While using colours in specialised applications such as for maps, there may be local conventions for representing something. As an example, in European geological maps for petroleum reserves the color symbolising oil is red, and for gas it is green. In the USA it is the reverse.

2. ICONS

When designing an icon (or using colours), there are two dangers: that the main message, the denotation of the icon may not be understood or is understood wrong, or that some connotation, 'side meaning' of the icon is insulting or in some other way inappropriate.

In a software, icons usually refer to an operation. Since software operations are rather abstract, they cannot be pictured directly. Therefore, icons in software often refer to some every-day task or depict an object that is associated with the operation. Also, icons may use some metaphors present in the language that connect an image with an operation. A software localiser must become aware of what referrals are based on metaphors or local habits.

2.1. NOT INSULTING THE USER

Below some sensitive areas of life or specific types of icons that could be avoided are presented . With these there is somewhat a danger of insulting someone:

• Signs of political parties, religious signs.
• Finger signs. There are a lot of offensive finger signs, and these vary somewhat according to culture. For example, in Australia, holding up the middle and index fingers, outside of hand towards the looker is a very offensive sign. An anecdote: On his trip to the Australia, Bill Clinton used the victory sign (the same, but outside of hand towards himself), without realising that the people behind him saw the offensive sign. Pretty soon he quit using the sign.
• Which race, colour, ethnic background or gender do the people you are picturing, represent. In some areas race is the hot issue, in others the gender etc.
• Clothing and visible parts of the body: Showing bare shoulders or knees in the Muslim countries, or downside of the foot in some Asian countries is not a good idea. Beware of exxaggerated sex characteristics, even if clothed.

2.2. GETTING YOUR MESSAGE UNDERSTOOD

When you want to signify an operation, you need to find out what kind of mental images are associated with that operation in the culture you are localising for. An example is given in the following. In some wide-spread American programs announcing for newly arrived mail, there is a figure of a post box with a flag. When mail arrives, the icon changes colour and the flag goes up. However, in many other cultures there are no post boxes where mail arrives. Instead, it may be dropped through a hole in your door, or you may have to collect it from the post office, and therefore many find the post box sign counterintuitive. Some alternative signs could be:

• Sign of a letter. This is rather internationally intuitive, since letters appear in most places. However, it may depend on the locale which side of the letter is more intuitively recognised.
• A postman handing a letter. This is intuitive, where the role of a postman delivering the mail is important, but not where you collect your mail by yourself from a post office.
• A pigeon with a letter in its peak. This may be intuitive and considered as charming in some locales, but definitely not all.
• A letter being dropped by a hand into a prototype of the local mail box.

For the "please wait" sign, or "operation in progress" there may alternatives like:

• An hour glass. Since this is an ancient symbol of "time flowing", it may be widely known. But again, since hour glass is not used in almost anywhere in actual life, it may be totally unintuitive in some cultures.
• A watch. Consider, whether the digital or analog version should be used. The insides of a watch (wheels turning etc) might also be possible.
• A percentage sign telling how much of the operation has been completed.
• A person running, doing gymnastics, or climbing a mountain might also work in some areas.
• The different phases of the moon changing. This might be preferred in some Arab or Muslim countries.

3. CONCLUSIONS

In general, the rich cultural variation is a challenge for the software internationalisation and localisation task especially when multimedia systems are considered. For the software developer the requirement of knowing all the local features is not feasible. It is more important to be aware of the categories of software components and issues which are subject to change.