|
A checklist of the most critical LANGUAGE & LOGISTICAL
considerations
Prepared by Yu-Jian-Yo Language Services, Ltd. of Victoria, B.C., Canada
The earlier in your product/documentation development cycle the
things below are considered and implemented, the more efficiently your future
localization project will proceed.
Be sure you have dealt with all applicable currency, tax, measurement and
sizing, postage/freight and legal (Ex: warranty) considerations. Make sure that
your product, images, and marketing materials are culturally-appropriate for
your target countries. Ask your localizer to arrange this research if you have
not done it yourself.
Gather together all your most current versions, documentation, and images plus
any previously-translated materials (digital format is best) and, if possible,
Translation Memories. Make these available to your localizer to ensure
consistency and cut cost.
Choose one person to be in charge of preparing materials for translation,
communicating with the localizer, and fielding questions between the localizer
and your engineers.
Technical and copy writers should write simply and unambiguously in short
sentences using the active ‘voice’. They should use terms consistently and
avoid: slang, acronyms, abbreviations, jargon, product comparisons with your
competitors (in some countries this is illegal), or any culturally-specific
references (Ex: some countries do not allow images of animals, various gestures,
or of various parts of the human body).
Use longer strings (whole phrase rather than one-word) to avoid incorrect
concatenation. This happens when different languages have conflicting
grammatical rules for combining words. Programmers unaware of these rules can
inadvertently create ungrammatical sentences, especially when combining one-word
strings. When creating a UI or an ASP page, where the same rules for combining
strings are used for all the languages, the strings should be long enough so
that changes in order can be accommodated. (Ex: put adjective+noun in English,
but noun+adjective in Spanish!)
Avoid using apostrophes, plural-‘s’, ampersand (&), exclamation marks (!), and
quotation marks (“”or ‘’) in strings.
Provide information in table and diagram format whenever possible.
Prepare a TERMINOLOGY (in list, spreadsheet, or database format). Include:
Glossary of terms that have specialized meaning in your
application
List of terms that must always be translated
consistently
List of terms, titles, names, etc. that you do NOT want
translated
Use UNICODE (usually utf-8) instead of ANSI encoding (and nvarchar instead of
varchar ) as much as possible in applications, but double-check that the
compiler you wish to use is Unicode-compliant. In some cases Unicode is not yet
feasible.
Space and orientation considerations for User Interface, Webpages, and other
multilingual documents: BE FLEXIBLE! Using double-byte languages such as Chinese
means that your usual character-length maximum in a database is cut in half.
Other languages (Ex: German, Russian, French) usually take up far more space
than English. Leave size and alignment flexibility in your design of buttons,
tables, and rows. (Ex: using Arabic in a multilingual document such as an ASP
page requires that you not hard-code any alignment to the left).
SEPARATE TEXT from your images as much as possible. Use language layers. Present
your localizer with the original layered image (such as layered .psd) originals
of any .jpg or .gif files which contain text. Use callouts and captions which
separate text from images.
SEPARATE TEXT from your programming code as much as possible. Even something you
think might be hard-coded such as a phone number would eventually have to be
separated if you want to translate into Arabic (we found this out the hard way,
of course…)
In general, DO NOT EMBED bitmaps, other images, or fonts. For example, in
FrameMaker, choose to link to a set of bitmaps in a “pix” folder instead of
embedding them. This could save you thousands of dollars in DTP (desktop
publishing) money later. In web applications, use style-sheets so that fonts can
easily be deleted and added to your application.
Use internationally-supported time, date, phone number, and address formats. The
way of expressing dates is very important in order to avoid ambiguity. In cases
in which you cannot use a particular date convention for each language, use this
one which is universally understood:
[19] [November] [2003] – names of the 12 months should be translated for each
language. Consider providing conversion of measurements (metric vs. older
system) and currency.
The way terms are sorted or ordered in a list or index varies from language to
language. Discuss this very important item with your localizer early in the
product-development process.
Ensure that users will be able to view, input, and cut/paste localized text
within your application.
Plan the organization of the resource and multilingual files with your localizer
to ensure simplicity, logic, and consistency. Centralizing all translatable text
into one or two resource files is best.
Consult your localizer about the best order in which to develop and translate
User Interface, screenshots, and the HELP and documentation files in order to
save time and money.
Budget for quality assurance and localized testing at each step of the
localization process.
Finally, make sure you have budgeted in enough time so that if unexpected
problems come up (and some bugs normally appear – that’s what makes this
business so interesting and challenging!), they can be solved in a timely yet
relatively stress-free manner.
We recommend that you refer to these books we have found most helpful:
A Practical Guide to Localization
by Bert Esselink (ISBN 1-58811-006-0)
Internationalization with Visual Basic by
Michael S. Kaplan (ISBN 0-672-31977-2)
Engineering Global E-Commerce Sites by
James Bean (ISBN 1-55860-892-3)
XML: Internationalization and Localization
by Yves Savourel (ISBN 81-7635-549-6)
Unicode: A Primer by Tony Graham (ISBN
0-77645-4625-2) |
