How to Plan and Cost an International Writing Project
Concurrent Design=To Profits on Time 381-2690 <sweezey -at- RAGMOP -dot- ENET -dot- DEC -dot- COM>
Mon, 1 Nov 1993 12:43:48 EST
Date: November 01, 1993
To: US2RMC::"TECHWR-L -at- VM1 -dot- ucc -dot- okstate -dot- edu"
From: Marcia Sweezey
Digital Equipment Corporation
Usability Design Group
110 Spit Brook Road
Nashua, NH 03062
Re: Scoping an international writing job
Att: Chris Jacobs
Mary Beth Raven forwarded to me your request of October 29 in which
you ask for for pointers on how to scope an international writing
effort. I initiated and led a comprehensive internationalization
program for the worldwide Digital information community and have some
thoughts to share with you based on my experiences and writing. I also
have some information for you about a book that may be of help.
First, as you can imagine, before you can cost this job (time and
money), you need to define, specifically, what you will deliver by way
of internationalization . ("I18n" is our shorthand for
"internationalization: I'll use it from now on).
ASK YOURSELF THE BIG QUESTIONS
Along with asking yourself the usual questions about user, client and
project goals and milestones, now ask your I18n questions as well. Let
me do a fast walk-through of some typical questions and where they
- Who are my end users? What languages do they use on a regular
basis? What are the high-priority needs of these users? How
will I find out? What assumptions do I need to test about how
these users learn? Should I use examples? If so, technical
examples or "every day" examples? If "every day," what IS
"every day" for this audience?
- What can I do by design to meet the high-priority needs of the
users? For example, if fast time to productivity is a need,
should I plan to leave technical terms in English and provide a
glossary? Would it be better to translate the terms? Translate the
- If gaining fast and permanent knowledge is a goal, should I use
redundancy as a way to aid learning?
Planned redundancy can be a good thing. However, you'll want to
consider local cultural norms. For example:
In Japan, space is at a premium. So, small documents are
often appreciated. Some European nationals reported being somewhat
insulted by redundancy. Redundancy can increase the cost (time and money)
of translations. Near-redundancy -- stating the same thing in a
slightly different way merely for the sake of variety -- can drive high the
cost of translation or productivity while translators or users
seek to find the non-existent subtle differences in the meaning.
In I18n, you need to consider some trade-offs.
- Will this work be translated or used in English?
- If it will not be translated, what must I do to make this work
easy to access and use by people who use English as a second
- If it will be translated, who are the translators and what
are their levels of experience with translating technical
documentation? With translating text in graphics? Is the authoring
tool you plan to use an issue for translation? Can a relationship
be established with the translators (or localization managers)
during the design stage of this project? (If so, all the better.
What we fix by design saves considerable time and money on the
re-working of implementations.)
START WITH A PLAN: THEN MOVE ON TO DEFINE TACTICS
You should create an I18n strategy and plan, as you would for any
information set. Your strategy should cover I18n goals, design
issues, tools strategy, "into translation" processes and milestones,
and address the capabilities of your business partners in localization
If you are managing or otherwise involved in localization, try to
include the localization plan in the I18n plan. For example, identify
who will manage localization; what is included; how translations will be
done; by whom: how translations and other changes will be tested for
quality before being delivered to users and by whom; clarify roles and
responsibilities; get quotes on localization costs.
Whether or not the work will be translated, you have a host of I18n
tactics from which to select to meet your I18n plan. Note that I18n
may be even more important when a work will NOT be translated. If
the users speak and read English as a second language and do not
benefit from the intervention of a translator, the English you
deliver needs to be very clear and "by the book" indeed.
A POSSIBLE REFERENCE FOR YOU and SOME IDEAS ABOUT TACTICS
In our book, Developing International User Information, (Jones,
Kennelly, Mueller, Sweezey, Thomas and Velez), we describe how to
internationalize an information product. You might consider using this
book as a guide I18n planning and for selecting the I18n tactics that
best fit the needs of your clients, users, and project.
For example, you may want to plan ahead to avoid using a telegraphic
writing style. An example we give in the book looks like this:
Original Text Does this Mean:
Set to lock at next level Set this to the lock, which is
at the next level? or
Set this so that it locks at the
next level? or
This is set so that it locks at
the next level?
People using English as a first language may have problems with this
type of writing, let alone translators and others who use English as a
second language. (Obviously, too, writing "this" instead of "this
something" is another problem.)
Sometimes we take handy shortcuts in English that are fine for those
of us who understand the convention. However, these shortcuts can
increase the cost of translation and, worse, prevent users from
understanding our messages. Some examples we provide in the book are
Instead of: Use:
File(s) File or files
Help/error message Help messages or error messages, or both
If you have not heard this next I18n tactics 101 times, you will! It
is: don't use examples that only Americans [or name your native place
and culture] can understand. You may be surprised to learn that many
companies still use baseball examples and American politics in their
Here's another idea for you: employ native speakers to do the actual
translations. Use other native speakers or persons very fluent in the
second language to check the translations. Don't use people who have
studied the target language but who have not lived (if you will) the
target language to create the original translation.
WHAT THE BOOK COVERS
Here is the high-level outline of Developing International User
Information. I will help you understand the various I18n categories
you should evaluate:
What is international user information?
Digital's international product model
Planning for Localization
Designing International User Information
Writing International User Information
Illustrating international user information
Developing international voice communication products
Developing international training materials
Packaging international user information
Preparing for translation
Digital's character sets and keyboard standards
Local data formats
Language-specific collating sequences
HOW TO ORDER THE BOOK
Call 1-800-DIGITAL (1-800-344-4825)
or FAX 1-800-234-2298
Title: Developing International User Information
Order No: EY-H894E-DP
Digital employees should call DTN 264-6660 after 5 M.
A companion book is Developing International Software, ISBN
Chris, I expect to be updating Developing International User
Information to add information about the business reasons for creating
international products. While I am not at liberty to give you the
specifics here, I will tell you that we reduced the translation budget
for information by about 25% over two years using
internationalization. We also know how to achieve shipment of local
language product variants according to need, and including
simultaneous shipment of languages.
NOT IN THE BOOK YET: I developed a list of about 14 I18n tactics that
tend to give the best pay-back in terms savings. All of the tactics
are quality (usability) related. Some happen to save money and get
local language products to market faster, more than others.
Again, I cannot give you the table right now, but here are a couple of
(1) Always provide a good glossary of technical and new terms for
use by translators or by end users, or by both
(2) If the work will be translated, be sure to allow room for text
expansion, especially in graphics
(3) If the work is to be translated or updated by someone other than
the original writing team, try to ensure that the tools you are
using are helping the effort, or at least not hindering it.
As you can see, Chris, you can assign a time estimate to each I18n
tactic you decide to follow for your project. For example, you can
estimate how long it will take you to develop an appropriate glossary.
If you are going to make yourself available to localization managers
to answer questions about or add to the glossary, build in time for
that deliverable, too.
Do not confuse "internationalization" with "localization."
Localization is one part of internationalization. It involves
changing the base product, including the language, to meet the needs
of the target audience of audiences. Internationalization involves
designing, creating, and delivering a product to end users or into
translation that is easy to use, easy to translate, or both.
Internationalization and localization require different skills sets.
Your job is to internationalize the product. Your job may also
involve acting as a content expert and consultant to localization
You do not say if you will be managing a localization effort, but if
you are, that work involves yet another set of skills. For example,
you should understand how to select a translation agency.
Good luck, and have fun! If your work is to be translated, ask to see
some examples of the translation. It is quite a thrill to see! If
you can arrange to get feedback from the users, do that, too. Then
consider sharing what you learn with others, perhaps through this
forum. The needs of user and thus the requirements of I18n are
always changing. To keep up, we need to share information about
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Search our Technical Writing Archives & Magazine