Writing For Users Of All Languages When Developing Your Software
This is
written to help software developers why it is important to create user
interface that is understandable, consistent, easily translated and
repeatable. Usability is vital! The user
of your product must understand the commands, words and phrases within your
software. Phrases like “holder info file processor ship to” may seem
understandable to the programmer, but the user will have a difficult time
knowing what the content is about.
Your user
interface (UI) needs to be written for the user. Who are your users: are they
tech savvy, engineers, laymen, or students? Do they have specific programming
knowledge? Are they Mr. /Ms. Average Joe, whose comprehension is in simply
written statements, without jargon, acronyms and multi-meaning terms? Example: Fill,
Load, Touch, Mouse, Screen….
Who is using your product?
What will they be doing
with it?
What do they need to
understand?
What is their reading
comprehension level?
Are they Non-English
speakers?
Writing User Interface That Your End User Understands
Most programmers write for programming; it is
not understood by the end user and often lost in translation. Process to
developing good content:
1. Software developer writes code
2. Technical writer collaborates with developer and
rewrites the UI for the end user.
The
user interface should be written by a technical writer. Some companies in the
interest of time and budgetary restraints forego the technical writer and the
programmer writes both the code and user interface. This actually creates
delays in translation and confusion amongst all users. The written code needs
to be translated to Plain English by a technical writer and then translated for
non-English speaking users. To do this efficiently and well style guides need
to be created and Plain English rules need to be established. Eliminating the
technical writer can often create confusing instructions and commands resulting
in hard to use devices and software. Add the dimension of other languages to
this and you now have communication issues in multiple languages.
I highly recommend investing in creating good user
interface at the beginning. You will save money
I highly recommend investing in creating good user
interface at the beginning. You will save money and time in the long run. Most
importantly, your product information will be understood, used correctly and
enjoyed.
As everyone knows, if you cannot understand
commands and instructions you become frustrated. Your image will suffer, your
sales will suffer and your fantastic product will not be utilized by the masses.
From OpenOffice.org
User Interface Text Style Guide, Elizabeth Matthis author:
“Mark”
Versus “Select”
“Select”
is used to refer to the selection of objects/items, for example, paragraphs or
characters which are then deleted, moved, copied, given a new font, etc. It is
also used when selecting options from list/combo box drop-down lists and for
radio buttons.
To
discuss the use of check boxes, use the verbs “mark” and “unmark” or the
adjectives “marked” and “unmarked”. Writing “mark” is also in the interest of
using internationally accepted English, because it side-steps the usage of
“tick” versus “check”. “Tick” is unacceptable in US English, whereas “check” is
sometimes considered incorrect in UK English, where “tick” is more common. In
the past, other words like “select”, “check”, and “activate” were used
inconsistently alongside “mark”. Our goal is to avoid using different words to
refer to the same function.
(http://www.openoffice.org/specs/collaterals/guides/text-style-guide.html#Localization)
Use existing terminology. This becomes an issue when new
developers come on board and do not use established terms.
Create Glossaries and Style guides. These steps will help the technical writers and
translators maintain consistent messages using
established styles and terminology.
Once you decide what terms to use, is the statement clear?
Is the term used for multiple functions?
Creating UI In English While Keeping
Other Languages In Mind.
Use Variables and keep Variables consistent; do not create
new Variables when there are current ones you can use.
Do not leave text phrases open-ended.
Do not separate a command into separate resource strings.
Translators are not developers; they do not always recognize
Variables and may think they are typos. Your Variables must be consistent and
noted in your style guide. At times, it is difficult for a translator to
recognize Variables… where they start and end, what symbol is part of the Variable
-- remember your translators are not developers or native to the English
language.
Do not end sentences in prepositions. They must be accompanied
by a noun, for example:
Send file to (incorrect) Send
file (Correct)
Folder to
folder
Recipient to
recipient
Symbols:
If you feel you must use symbols, make sure they are
recognized internationally. A translator may be able to recognize commonly used
symbols like # in American English, but it is hard to know the context. It is best to use words when you write.
Space:
Know your spacing limitations when writing UI . Many
languages are longer than English, some as much as three times as long. When you are writing your string,
know your spacing limitations and the adjustments that will need to be made for
other languages.
Spacing:
Do not add additional space before or after text. For
example, using a carriage return instead of automatic formatting creates a
separation in your sentence. It will
cause errors in the translator’database, making it difficult to understand and
translate your text. The formatting issues will create delays in translation,
if not errors, due to not understanding the original meaning.
Dates/Time
Do not hardcode dates/times/measurements. Allow the
option for your user to choose his/her regional choices.
The Following is from Microsoft Windows User Interface Text:
Globalization and localization
Globalization
means to create documents or products that are usable in any country, region,
or culture. Localization means to adapt documents or products for use in a
locale other than the country/region of origin. Consider globalization and
localization when writing UI text. Your program may be translated into other
languages and used in cultures very different from your own.
·
For controls with variable contents (such
as list views and tree views), choose a
width appropriate for the longest valid data.
·
Include space enough in the UI
surface for an additional 30 percent (up to 200 percent for shorter
text) for any text (but not numbers) that will be localized. Translation from
one language to another often changes line length of text.
·
Don't compose strings from substrings at
run time. Instead, use complete sentences so that there is no ambiguity for the
translator.
·
Don't use a subordinate control,
the values it contains, or its units label to create a sentence or phrase. Such a design is not localizable
because sentence structure varies with language.
Incorrect:
Correct:
In the incorrect example, the text box is
placed inside the check box label.
·
Don't make only part of a sentence a link,
because when translated, that text might not remain together. Link text should
therefore form a complete sentence by itself.
o Exception: Glossary links can be inserted
inline, as part of a sentence.
As you develop
your software, keep in mind your end users will likely be non-English speakers
in other regions around the world. Ninety-five
percent of consumers are located outside of the United States Writing
with them in mind will create content ready to be sold around the world.
Reference:
Learn more about All Clear Translations.
Call us at 866-489-9109
More about the author and All Clear Translations:
Linda
Richardson is president of All Clear Translations. All Clear
Translations is located in Western Pennsylvania and was established in 2010. Their
main clients are manufacturers, software developers and marketing agencies. All
Clear Translations assists with translations, telephone interpreting and
voice-overs in many languages.
