🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: bit.software.international
Article #394

Widening the scope of i18n

#394
From: Bowyer Jeff
Date: Thu, 12 Aug 1993 11:14
79 lines
4952 bytes
I have been watching this discussion for several weeks now, and I
feel that I would like to try to expand it somewhat.

My company is involved in remarketing educational software from
England to other EC countries, particularly The Netherlands and
Flemish-speaking Belgium.
Apart from the purely translational problems, converting packages
from English to Dutch, we have observed the following difficulties:

1.   MENUS.
We cannot rely on _technical_ translators to be able to
convert the meaning of a single word (or, occasionally, phrase) that
appears in an English menu or dialogue box, to an appropriate word in
another language.
For example, the equivalents of LOAD and FILE in Germanic languages are
not necessarily appropriate to the action that has to be performed.
Fortunately, in our circumstance, I was able to contact Microsoft NL
to ask what the Dutch version of Windows displayed as menu items, and
was then able to write my User Manuals correctly (I believe :-). It would
be helpful if originators of generic software were to publish interface
definitions for their products in all languages that they support, so that
those of us who wish to make use of that software as a basis for our own
applications, but are reluctant or unable to purchase multiple copies of
the base software, can have a reference to the interface being used in
the target country. Of course, that doesn't help in the case where the same
package is being sold with different language interfaces in one country.

2.   ICONS.
I have noticed that, for example, American software uses
a question mark (?) for information, whereas Europeans would be more
familiar with the use of an Italic i to find help. Although this is
a trivial example, perhaps people from different cultures respond
differently to graphic images, especially reduced to iconic form.
As an incidental example, the Moslem equivalent to the Red Cross symbol
is a Red Crescent. Other examples may lurk unbeknown to developers
in foreign countries.
Therfore, if your software is to be adapted for use in a country
that has a different cultural ethos, you must pay attention to any hidden
symbolism that your program uses.

3.   ATTITUDE.
In a previous project, I was forcibly made aware of
the difference in motivation between (even :-)) European cultures. A
system originally designed for use by English operatives was
deemed inappropriate for use by Italian operatives, doing exactly the
same task. This was because the English users took a relaxed view of
the system, and were prepared to allow the system to take whatever
action was necessary, while the Italian operators felt that they
needed to be directly involved in the decision-making process.
A similar situation occurs in the UK, when systems have been converted
for use in medical environments (e.g. hospitals): on some equipment,
a RED symbol indicates a life-threatening emergency, and staff are
trained to respond to this. If your software makes inappropriate use
of colour to illustrate non-critical messages, it may soon become
ignored.

Without trying to be partisan in these problems, I think that we
should try to understand the wider problems of I18N, and perhaps
agree that some of them are intractible, thus leading to a potential
market for _local_ solutions, rather than a domination of one
particular ethos. Ideally, software producers should be able to devise
a description of the aims of their software which transcends cultural
differences, and enables _local_ software convertors to be able to
_translate_ (in the fullest sense) software in a way that would
encourage their customers to believe that it had been produced for them
alone. Certainly, the aim of my company is to produce software for
_the home market_, whichever _home_ this might be.

I hope that this _tirade_ contributes positively to the discussion.

Anthony.


Anthony St.John                      |     aos@eurotech.demon.co.uk
Europhile Technology Consultants Ltd |     Tel. (+44)-908-690880
494 Midsummer Bvd, Milton Keynes     |     Fax. (+44)-908-670013
GB - MK9 2EA, England                |
_____________________________________________________________________________
Technical Details
Message-ID: <24d8n8$lm6@rhino.cis.vutbr.cz>
Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news.univie.ac.at!alijku11!aci.cvut.cz!rhino.cis.vutbr.cz!rhino.cis.vutbr.cz!not-for-mail

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 110cdc,1b63e6794021b0f4,start
X-Google-Attributes: gid110cdc,public
X-Google-ArrivalTime: 1993-08-12 23:15:28 PST
Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news.univie.ac.at!alijku11!aci.cvut.cz!rhino.cis.vutbr.cz!rhino.cis.vutbr.cz!not-for-mail
From: jbowyer@rhino.cis.vutbr.cz (Bowyer Jeff)
Newsgroups: bit.software.international
Subject: Widening the scope of i18n
Date: 12 Aug 1993 13:14:48 +0200
Organization: Technical University of Brno, Czech Republic
Lines: 80
Approved: insoft-l-moderator@cis.vutbr.cz
Message-ID: <24d8n8$lm6@rhino.cis.vutbr.cz>
X-Newsreader: TIN [version 1.2 PL1]