|
Software Localization
Translating software into multi-lingual versions
can be a cumbersome task. Often, developers will
turn to software publishers that specialize in
specific geographical regions to manage foreign
language versions of the software.
Keep in mind that if you have a foreign language
version, you must provide marketing materials,
web copy, and product support in the foreign language
in order for it to have a chance at success. As
a result, many MicroISVs find software localization
a daunting task. This usually means opportunity
and less competition.
Developers, on occasion, will recruit existing
multi-lingual customers to translate their software
into the customer's native language, either for
a flat fee, or percentage of the foreign language
version sales. The obvious downside for MicroISVs
who take this route for translations is "quality
control" -- it is difficult for a developer to
discern the quality of a translation if they do
not know the language themselves. If the agreement
is based on a fixed price, ongoing support for
the translated version may become a long-term
burden.
Because of these issues, many developers wishing
to localize their products will work with a publisher
that covers a specific region. The software publishers
will take a percentage of all sales of the localized
version. They may also handle support and packaging
for a specific region.
When you first begin your software development,
you should design the product with localization
in mind. In other words, localization should be
a component in the earliest of stages of software
design. The initial software architecture should
contain allowances and expandability, with the
expectation that the program will be translated
at some point. This will save enormous amounts
of time and energy when the decision is made to
translate the application.
Tips to keep in mind to prepare software for
localization and translation:
1. Separate INI Files
Use separate .ini files for all text strings to
make translation easier.
2. Unicode
Use development tools that support unicode characters.
If the development tools do not support unicode,
the localization process will be more complicated.
3. Space
Keep in mind that word lengths will vary across
languages. Leave room on all program buttons for
longer text strings. The buttons will need to
accommodate the translated text, which in many
cases will be larger.
4. Language & Sensitivity
Be sensitive to cultural differences and nuances.
Avoid colloquiums or idioms in help files and
web pages, as they may be difficult to translate.
Be aware of cultural differences, and avoid terms
that could be misconstrued or that translate poorly;
for this reason, it is often good to use a native
speaker for proofreading. Be sensitive to those
cultural differences and nuances. In many ways,
it makes sense to use a native speaker for localization
and sales management. Locals will have a better
understanding of cultural nuances that could impact
the viability of a specific product. A native
speaker will often catch cultural nuances which
could cause potential problems.
5. Date
Date formats vary across countries, so be sure
to include a setting for date formats, so that
the program's dates will be formatted properly
for all regions.
Additional Resources:
Quick
Tips for Localization of Software
Localization
Tips and Tricks
Related Articles:
Going Retail
How
to Recreate Customer Problems
How to Conduct
Effective Beta Testing
|