|
| |
GoldenSeal- A Small Business Software
It is a integrated accounting software estimating software and business management software for windows and macintosh computers. It is complete business management software and does different things like accounting, cost estimation, project management and ...
Importance Of INTERNET
SENSE OF EMPOWERMENT Shorts for inter network. A set of computer networks that may be dissimilar and are joined together by means of gateways that handle data transfer and conversion of messages from the sending networks’ protocols to those of the ...
Provisioning/User Management System Upgrades: Part Two – Building Awareness And Building Approval
Somewhere in the world is a person who wants to see their provisioning/user management systems get a sorely needed upgrade. But they seem to be getting nowhere. The technical requirements are unarticulated. Key decisionmakers in the company are not aware ...
|
|
|
|
| |
available,which can operate in multiple languages. In this article we
examine what’s involved in developing such software. And it’s not as
difficult as you might imagine.
If you develop software to sell, then perhaps there might be market beyond
the shores of the USA. Have you considered making multiple language versions
of your software available? Perhaps you’ve given it a fleeting thought but
dismissed the idea as too expensive or too difficult. Take away the jargon
and buzzwords, not to mention the expectation that it is difficult; and
many software products can relatively simply be produced for different
language speakers. Especially so if the developers have followed reasonable
development standards.
And lets face it, the extra revenue and customer base can be very very
lucrative.Nor should you under estimate the number of people in the USA
who don’t have English as their first language. Another benefit of providing
your software product in multiple languages is that it also gives an
impression that your company is far larger than it is. When I see a web
site or software product available in multiple languages I tend to assume
that the company must be large.
So let’s take a look at the process and examine what’s involved. We
concentrate in this article on taking an existing software product and
making it available in multiple languages. The ideas presented here are
general and assume a relatively simple product, but the concepts and
approach are the same for even a sophisticated application.
First rule: to keep things simple. There are many different languages
being used around the world and you have a wide choice. In English
we read sentences written left-to-right and from the top, down the
page or screen. This isn’t the case for all languages. We also use an
alphabet (script) referred to as Latin, and in technical speak it uses
single byte characters. So it’s a good idea to restrict your first multiple
language projects to languages that also share these characteristics
with English.
The list is extensive and includes; Spanish, German, Italian,
Portuguese, French, Dutch among others. Even restricting your project
to these languages widens your market by about 1 billion people. Eastern
Europe uses a script called Cyrillic (Russian) which is very similar to
Latin and prices for translation into Eastern European languages tend to
be very competitive. Asian and Middle Eastern languages offer some
unique challenges but they are manageable. But early in the process,
you need to decide exactly what languages you want your software
to be available in.
There are a variety of methods to developing multiple language versions of
software. One approach favoured is to separate out all of the text presented
to the user into a file or database table. This text must include everything
that a user will see when using the software. It includes screen display
text, printed report text, constants, prompt, error and warning
messages, and help displays. Your product will likely include a user guide,
version notes and licence agreement, and of course these also need to
be included in the localization project.
The file or database table where all the text will exist has to be
accessible by the programs and so some sort of simple key process
and update function must be developed. Again, keep it simple. We’ve
found that having a simple key system based on screen or report name
and then a unique text item number works fine for most applications.
For large a application you may need several text files, perhaps based on
text type. You’re probably thinking that the application’s performance will
be reduced due to the extra input/output needed to access all the text.
There will be some reduction but in practice it is minimal. And there are
some benefits to compensate. For instance if screen text needs to be
altered then no program change needs be made to effect the change.
Our file containing all of the text is then used as the basis of our
language translation. There are all manner of options to organise
the translation including translation agencies, freelance translators,
computer based translation, even co-workers, friends and family
might be able to help. At the end of the day most computer
applications actually have quite simple text. But before you do
have the translations performed review all the text for grammar,
spelling and ambiguities. The clearer the language used in the
application then the more likely the translation will be accurate.
A word of warning. Professional translators
tend to be highly
educated, and sometimes their resulting work will require the
reader/user to hold at least a Masters degree to understand it.
Always specify that you need the translation to have an equal
reader level as the original English.
Some translators and agencies might be positive to providing their service
for free. There are numerous examples of shareware and freeware
software where professional translators have been generous. Mozilla
is a good example of such a co-operative effort.
The object of the project is to develop multi-lingual software in which
the end result will consist of our executable files linked to our table(s)
of text. The specific text file shipped with the product will be in the
language of the user’s choice. An alternative option is to store each
translation in a specific language file and when the user installs the
software they specify their language preference. Thus the routine
that reads the text records needs to identify the language needed
and isolate itself to that language.
And of course you need to test the resulting language versions. This is
best performed by speakers of the specific languages you’ve decided
to implement. Testing under language versions of the operating system
might also be worthwhile.
Character constants are a special case. For example, the software might
need to determine that a particular key has been pressed from a selection.
Assume the menu selection includes Open, Save, Find, Copy and Paste.
The routine in the program might look something like:
switch (myInputString[0])
{
case ‘Open’;
DoOpen ();
break;
case ‘Save’;
DoSave ();
break;
case ‘Find’;
DoSearch ();
break;
case ‘Copy’;
DoCopy ();
break;
case ‘Paste’;
DoPaste ();
break;
}
The code above is efficient and concise, but it is difficult to translate.
The various constants (Open, Save, Find, Close, and Paste) have to
be replaced with data items that have been loaded with the equivalent
constants from the specific language file being used by the user.
What are the potential pitfalls? A common problem is that the space required
by text on screens or reports differs between languages. For example the
phrase ‘enter name and address’ is 22 characters. In German the equivalent
phrase would be ‘Geben Sie ihr Name und Adresse ein’ which is 34
characters. We’re often faced with the problem that the translated language
requires more screen and report space than the equivalent English. So test
carefully that truncation doesn’t occur. And consider the cosmetic appeal
of the resulting screen or report.
There are some legal aspects that you need to research. Obviously every
country makes its own laws. In Germany, for example, there are quite
restrictive laws that disallow anyone to make claims that a product is
better than another company’s product. Not to forget that the United
States also has export laws. Encryption algorithms are an obvious example.
So do a little research, and if you are using a translation agency then ask
for advice.
Copy protection, upgrades, error reporting are all issues that will
broaden if you want to sell software offshore. You also need to take
account that date format, paper sizes, currency symbols, sort order
and addresses might differ, and lets not forget that the majority of the
world uses the metric system for weights and measurement.
The translations don’t have to perfect. In saying this I am not suggesting
you lower your standards. But most people appreciate that you have taken
the trouble to translate the text, and will overlook the odd mistake. And
let’s be realistic, the English used in your software will likely have the
odd typo anyway.
Organising a marketing agreement with a local distributor can also provide
a useful resource not only for the product’s language development, but in
ongoing product promotion and support.
Microsoft provides an extensive resource available on their web site.
There are several very helpful news groups that you can subscribe to
and a number of books are devoted to the topic of software localization.
I hope this has given you something to think about.
About the Author
Copyright © 2002 Grant McNamara, All Rights Reserved. This article
may be freely distributed and published. If you wish to publish the
article, out of courtesy, please email me and advise the url.
Author Information: Grant McNamara
web site: http://www.translateme.co.nz
Email: grant.mcnamara@translateme.co.nz
Grant McNamara is a consultant specializing multilingual software
development and Internet support.
|
|
|
|
|
|
|
