If you talk to a man in a language he understands, that goes to his head. If you talk to him in his language, that goes to his heart. Nelson Mandela
Every technical writer knows the single-sourcing method that emerged more than 30 years ago. It increases the reuse of existing written content instead of rewriting information. There are six key benefits of single-sourcing:
- uniformity,
- fewer repetitions,
- flexible output,
- better traceability,
- publishing costs reduction,
- ease of maintenance.
We already wrote about the versioning of technical documents with single-sourcing. Great approach! But what if a company aims at global growth? It needs localization of products and services as a matter of strategy.
Tips for Perfect Localization of Single-Sourced Content
It’s crucial to ensure that you can deliver content for multiple languages without losing the efficiency that single-sourcing enables. That’s a challenging task for sure but not impossible. Lucky for you, we gathered the tips to avoid downfalls when you localize your single-sourced content and make the process flawless.
Tip #1. Make the content easy to translate.
Source-language content should be adequately prepared for localization to be successful. We already described the role of a tech writer in the localization process.
You should keep in mind localization from the beginning and not in the middle of the whole process. Because even if you don’t need the localization, for now, things may change in the future. And it will be a lot more challenging to localize your documentation after establishing your single-source authoring environment; if not to say you may have to rewrite the whole thing. Ask yourself whether you’re doing a Sisyphean toil without considering localization from the early stage. The main idea is: always write with localization in mind. Start global and then adapt for each market. What does this mean in the context of single-source authoring?
For example, a variable use: there is a language that adds prefixes to words that shows how it relates to other parts of the sentence, then you need to choose how to add your prefix wisely. This is probably a standard for this language. In the table, there are some examples of how your translation would appear. The language applied is fictional used only to explain the principle.
Variables should be written and translated consistently across the whole project. And with every language, things get more complicated: each word may get inflected according to its immediate linguistic context. Obviously, in large projects, this generates innumerable problems. Here’s how to avoid such difficulties:
- Create the content where the possible need for inflection is brought to the minimum.
- Keep things simple.
- Write short, clear sentences.
- Don’t use idioms.
- Avoid the use of phrases that are not understood universally.
- Limit dependent clauses.
- One thought per sentence helps translators and increases translation memory matches.
- Use lists.
- Separate content from presentation, turn to CSS instead of grammar to make things stand out.
Tip #2. Mind the translation quality.
The translation process for the single-source content is different. Translators often get fragmented pieces of content, possibly without context. This is how the single-source authoring methodology works. For example, the authors make lists of UI strings in variable files to appear uniformly throughout the content. You need to make sure that they’re translated consistently as well.
- Localization includes the use of Translation Memory (TM) to reuse content consistently. Using a translation memory tool is a start, but the most efficient way is to translate the UI strings and then integrate this with the translation memory tool when translating the main content. This will pan out if you are working with a translator who understands the relationship between the UI strings and the broader set of content.
- Use a qualified native speaker for each language. Such a speaker should understand your domain and know how to work with the latest translation technology. So don’t use “cheaper” translators for this type of content: crowd-sourcing, half-professionals, newcomers, or the cheapest translation services out there. With single-source content, you need people who understand how single-source authoring works and have experience dealing with it.
Tip #3. Start doing the testing early.
With any single-source toolset you are using, several elements are worth testing to minimize issues on the threshold of a delivery deadline. Before testing, ensure that you understand how your documentation file structure will handle localization – comprehend and imagine the schemes involved with having 20+ target languages or local market variants. Is your toolset organized for this, and how do the relationships between master files and variants or targets work?
A person responsible for localization can take a sample of your content files and automatically replace your English with characters deliberately designed to simulate the impact of translating into languages that might affect your layouts, such as French, Turkish, Chinese, Hebrew, or Russian. This needs to be done in order to identify non-localizable strings.
Сheck with a sample “package” of your files that the CAT analysis tool would find all of your translatable text, including any that might be hidden in layers, graphics, videos; with single-sourcing, depending on your toolset, it can be trickier to ensure you have prepared the set of files for translation, and not missed anything.
Tip #4. Analyze the results.
This stage is common to all types of projects. And I’m sure you’re all aware of that, but the message merits repetition. So, review again the conclusions made in the course of the work. Analyze translators’ questions and concerns to identify possible improvements to workflows, processes, and source documentation. Such surveys can have a significant impact on your work in the future. Make sure that impact is positive. Keep track of all the work you’ve done and maintain records of how you conducted your analysis. That way, you won’t make similar errors.
Conclusion
Localization is a significant step in documentation when your organization expands into international markets. Content can be selected and published in a range of versions, which gives flexibility and considerable cost savings by combining single-sourcing with localization. Single-sourcing gives technical writers the ability to write once, translate, and create multiple outputs for as many languages as needed. By implementing the tips in this article, you can maximize the benefits of the localization process. If you use concise and simple language, arrange design changes, and utilize the correct translation glossary, your final product should come out as planned.
Good luck with your technical writing!
ClickHelp Team
Author, host and deliver documentation across platforms and devices
