|
SIGDOC Newsletter
September 2006
:: Volume 7, Number 3
Features
"The World is not English" by Rob Pierce
The World is not English
By Rob Pierce
robertp@us.ibm.com
I recently read the book, The World is Flat, by Thomas
Friedman. It was recommended by leaders in the company I work for and
so I valued their advice and viewed it as an opportunity for a bit of
what is sometimes termed “professional development.”
The book is interesting and relevant to today’s business environment,
especially if you work for a company that does business in more than
one country, or has employees in more the one country. In fact it has
relevance even if you work for, shop at, or know of a company that sells
something in more than just one place or has employees in more than one
place. Connectivity and availability of information and managing change
and complexity in new ways are some of the areas the book sheds light
on for today’s business world.
In the book, Friedman describes the rapidly changing faces of economic
concepts such as international business, business process, competition,
changing workplace environments, distributed teams, customer demands
and insights, and rapid change.
As I was reading the book, I was in the midst of working on documentation
for a product release that was to be the first version to be localized,
that is, made available in several other languages besides English. The
intent was to provide language-specific versions of our product for operating
systems with displays in other languages. And of course, the product
offering would include the documentation in the localized language as
well.
As I worked on my English version of what was to be a role-based Help
system, I imagined users of this Help system reading their Chinese, Korean,
French, Spanish, Brazilian Portuguese, Japanese, and German versions,
as well as performing the use cases on user interfaces that were localized
to their native languages as well.
Would their version of the product and the Help be as usable, or more
usable, than the English version for them? It would be interesting to
gather customer feedback from the different locales.
Providing Help in several different languages created a number of new
requirements for ensuring successful delivery of the product and its
technical content for each language. The change brought an increase in
complexity for all members of the development organization.
Specific areas considered are described next. Much detail could be
added to the aspects of supporting multiple languages of a Help system
or product
listed in this article, and there are several others in addition to
the ones listed here.
- Determining what is translated and what is not translated.
For example, do you translate the product name or keep it in English?
Similarly, in
the Help, do you translated the product name and if not, then how
do you manage references to it in titles? In figures, do you translate
the
text in them? Do you leave the figures with English text? It might
depend on whether that same English is translated in the product or
stays in
English. For example, the underlying programming code in the product
remains in English, so if the figure has text that represents that
underlying code, then it would not be translated. In API documentation,
a class
name would not be translated, so any figure illustrating the class
would not be translated, nor would any code examples. However, a comment
in
a code example might be translated.
- Testing. Testing the translated versions of the Help adds yet another
level of complexity. Rather than needing to test one Help system
in English, several other versions of the Help system must be reviewed, preferably
at the same user-competency level as the English version. Just as
for
testing code, it would be optimal for each translated Help system
version to undergo unit testing, system testing, and other types of testing such
as performance testing. For example, does each version of the Help
have
the correct links? Are the figures labeled correctly and have appropriate
figure headings? Are the cross references translated correctly? And
at the simplest level, does the product contain the Help in the correct
language?
- Filenaming. In order for them to work correctly, each translation
of the Help system should contain the same collection of filenames
as
the English version. Maintaining multiple versions of Help systems all containing
the same names for all files adds yet another level of complexity.
Naming
the directories with language-specific meaning, using conditionalization
or some other strategy is needed to eliminate simple mistakes such
as delivering Spanish Help with the Japanese product.
- Using attributes in the
text, files, and directories to conditionalize content and ensure proper
inclusion of appropriate content for delivery
is one method for managing the complexity. This strategy would be
similar to how some organizations provide support for multiple versions for different
operating systems or platforms.
- Working with translators requires
that information developers take on additional responsibilities since
they are the ones most familiar
with the English version.
- Versioning is an aspect of working with technical content
if you work on deliverables that are updated or newly created for a
given product
release or deadline. Most companies and professionals use a file
system, database, asset, or configuration management system to maintain multiple
versions of the source files that comprise and are used to generate
the
deliverables. For example, you may have 400 xml topic files stored
in an asset management system that stores versions of the files for the
current development as well as all previous releases. You may also
use conditionalization in some of those files to help ensure that content
relevant for only one release is not included in some other release.
With this same file structure now being supported for, say, eight languages,
the same information now applies to all eight versions. It is important
to note that you still only work on – do content or structural
work - the files in one language. For the other languages, you send the
English files out to be translated, and may be sent a return package
that contains the translated versions which are then used to generate
output for that language. Thus, there should only be versions of text
in the translated languages that were sent to the translators.
Additional details include:
- Translation requirements – drop dates or dates the files
must be delivered and returned to and from the translation centers,
returns – what
to drop and what to get returned
- How to package it and how to deliver
it – and do you ship translated
versions on the same dates as the English version? Will testing require
additional time? Can the dates slip for translated versions or must
they all ship on the same date?
- Different part numbers, for different
language versions? How will the different versions be made available?
- How do you determine what in the user interfaces is translated and
what is not? Will the field sizes for given English strings be sized
appropriately for all translated versions? Will you provide screen
captures in your Help and if so, will you provide – and how will
you provide them? – language-specific versions of the screen
captures for all languages? Who and what tool will manage the development
and maintenance
of figures for each language?
- How will defined text objects or string
such as company or product names and book titles be handled for translation?
Will these strings
be translated?
These are just some of the many details to consider. In the flattening of the world perspective, with significant competition
coming from locations where English is not the primary language, it
is interesting to imagine the original sources of new products and documentation
being not English and imagining, say, a Chinese product being localized
to English. This is currently not a common scenario, since the product
would probably first be created in English, but it is easy enough to
imagine localization to English versions in the future.
In the flat world, perhaps all versions would be available to all audiences,
from the Web, with content being updated as needed, and the updates going
to all language versions of the Help. The translation of updates from
a source language to other languages will always be the critical requirement
and the costs of managing the additional overhead will have to be weighed
with the benefits – the actual ones and perceived ones – in
order to justify it.
back to top
|
