Content found in this wiki may not reflect official Church information. See Terms of Use for more information.
Resources (Internationalization best practices)
Principle: Well-managed resources decrease the cost and increase the quality of the localized product.
Resource isolation
Best Practice: Isolate all UI information from the executable code.
<Overview to be written>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: IBM, Java Tutorials
Translation v. localization
Best Practice: Distinguish between translate-only and localizable content.
Translation is rewriting in one language what was originally written in another. Localization brings additional cultural aspects into the picture. For example, a first step beyond translation into localization might be to convert distances from miles to kilometers or using a picture of the reader's local temple rather than the author's local temple. Or, one might substitute a locally appropriate expression instead of just translating the one used by the author -- like "killing two birds with one stone," or "bib overalls." Direct translation of these expressions might not mean anything to the reader. An extreme case of localization might completely replace a US-specific story with a Ghana-specific story that makes the same point.
Some of our content should be translated only -- like scriptures and General Conference talks. Some of our content might be more effective when more fully localized. Indicating if something should be translated or localized -- in the resource file -- provides translators with clearer sense of what's expected or possible.
It is important to recognize that indicating which resources to translate and which to localize is only part of the solution. The tools and products must also be designed to accommodate such a distinction. That topic is covered under the Design section of these internationalization best practices.
Roles, responsibilities, and examples:
- Author/creator (individual or organization): Identify which content should be translated-only and which could be localized. Indicate that distinction in the resource files.
- BA/IxD: Understand if this distinction will be made, and if so, which content is to be translated and which is to be localized. Ensure that is accounted for in product requirements and design.
- Developer: Ensure that the product is able to treat translatable v. localizable content appropriately in all languages (not all languages and locales may want to treat this content in the same way).
- Tester: Ensure that requirements are met.
Links:
Pseudo localization
Best Practice: Pseudo-localize your product early.
Pseudo localization is a great way to test the internationalization of your product long before it is actually localized. It is a process of replacing localizable strings, data and other resources with pseudo-localized -- or international looking/behaving -- strings, data and other resources.
Roles, responsibilities, and examples:
- BA/IxD: Use pseudo-localized data and expansion metrics when designing the product.
- Developer: Create a pseudo-locale and pseudo-language. Set up a build for that pseudo-locale/language. Populate that build environment with pseudo-localized versions of your resource files, data, and other resources (like pictures, CSS files, templates, etc.). Build the pseudo-localized product.
- Tester: Test the functionality and look/feel of the pseudo-localized product per documented best practices.
Links:
File formats
Best Practice: Use file formats that TRL can accept.
<Overview to be written>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: Microsoft
Concatenation
Best Practice: Avoid string concatenation.
<Overview to be written>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: Microsoft
Variables and placeholders
Best Practice: When variables or placeholders are necessary, provide context, unique names, and allow flexible ordering.
<Overview to be written>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: Microsoft, Java Tutorials
Sentences and strings
Best Practice: Don't break sentences into multiple strings.
<Overview to be written>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: Microsoft
Presentation controls
Best Practice: Make style sheets or other presentation controls available to TRL to provide visual context.
<Overview to be written>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: IBM
Change management
Best Practice: Clearly identify changes; avoid minor changes that affect translation already done.
<Overview to be written>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: IBM
Resource/UI map
Best Practice: Provide translators with a mapping between resources and UI entities.
<Overview to be written>
Roles, responsibilities, and examples:
- BA/IxD: <to be written>
- Developer: <to be written>
- Tester: <to be written>
Links: IBM
Writing
Best Practice: Write for an international audience and send it to CUR Editing.
Writing for an international audience starts with the basic principles of good writing. If it's not well written in the first place, all readers (including translators) will be impacted. But the greater the gap between the writer and the reader, the greater the risk of misunderstanding. A person in the office next door, with whom you've worked for years, may find your writing perfectly understandable, but someone who works in a different domain, in a different part of the world may not find it as easy to follow.
Most translators at the Church speak English as a second or third language, and it is likely they learned British English rather than American English. Church translators are asked to translate content from many domains, like doctrine, Church policy, medicine, agriculture, fleet management, technology, facilities maintenance, history, legal, and education. Writing without an international audience in mind can result in 1.) delays as translators spend time trying to understand the English text and asking questions across world time zones, 2.) a bad translation, or 3.) both.
Roles, responsibilities, and examples:
- Any role that writes: Follow IBM's guidelines on Writing for an international audience. This is excellent material on writing in general, but especially if your writing will need to be translated into other languages. It covers grammar, terminology, style, punctuation and packaging. Good writing will improve the speed and accuracy of translation. Here are a few examples:
- Ambiguous pronouns usually present challenges for translators. They cause confusion. In the previous sentence, what does the word they refer to -- pronouns or translators? It's best to ensure pronouns are not ambiguous.
- Acronyms and abbreviations can be a problem for translators. The translator may not understand the abbreviation or acronym. These items may not mean anything in the target language. A translation of the abbreviation or acronym may not be possible or make sense. Not all languages allow abbreviations. Arabic is such a language. In addition, if abbreviations or acronyms are used to shorten an English string to make it "fit," the combination of text expansion and the possibility that the abbreviation or acronym will need to be spelled out (literally) or explained almost guarantees that the translated string will NOT fit.
- Colloquialisms and jargon are difficult to translate. Terms like "bib overalls" have no meaning or equivalent in other parts of the world forcing a translator to do some research, come up with some way to express the intent of the author, and hope that diverting the flow of the message with their explanation doesn't impact the reader's understanding of the core message. A translator has similar trouble with jargon. For example, if a translator doesn't recognize "boot sector" as a technical term (which he/she might need to research), the resulting translation might refer to a portion of a car's trunk.
- Using "(s)" to make a term be either singular or plural. This construct just doesn't work in most languages because changing from singular to plural often involves more than just adding an "s" or "(e)s" to a noun. Articles, adjectives, and verbs may also need to change.
- Editor/tester: Ensure that the writer followed IBM's guidelines.
Links: IBM