Localizing Single-Source Content: 3 Tips to Avoid Problems

Single-sourcing has been long-established as one of the core principles of modern technical and user documentation: create and manage your content in a database and make it easy to publish and distribute multiple variants and formats. It’s a brilliant approach: enabling consistency, improving time to market, simplifying change management and increasing productivity. And the more products, content and documents you have, the more powerful it gets.

But what happens when single-sourcing meets content localization? How do you ensure you can deliver for multiple language markets without losing the efficiency that single-sourcing enables?

To put it mildly, it can be a nightmare. The linguistic concerns of translation are joined by new ones, related to file organisation. Grammar differences between languages make using variables a lot more complicated. Using conditions stops being that simple as well. Basically, there are quite a few traps to be aware of. How do you avoid them? Here are some tips for content localization.

Best practices for single-source content management

Make the content easy to translate

For any successful localization process, well-prepared source-language content is the key. This means that you need to start thinking about localization from the very beginning, not in the middle of the whole process.

At the earliest stage possible, well before establishing your single-source authoring environment, you need to ask yourself the obvious question: will my content ever need localization? “No” is hardly ever the answer, because even if it doesn’t need it now, it wouldn’t be wise to assume it will never need it in the future.

The takeaway is simple: always write with localization in mind. Just as we recommend for e-learning localization: start global and then adapt for each market. What does this mean in the context of single-source authoring?

For example, variable use. Let’s say you’re using the Madcap Flare toolset, translating English documentation to German, and you’re using variables for each manufacturing part name, to make sure they’re written and translated consistently across the whole project. If each variable is a single phrase, this should work fine both in English and in German – their grammars are similar enough. But consider Polish. Or Hungarian. Whereas there are only three grammatical cases in modern English and four in German, Polish has seven of them and Hungarian boasts… twenty nine (or, according to others, lacks a case system altogether). This means that a simple variable saying <Car 20> in English may get translated properly to German, Polish and Hungarian when occurring on its own, but turn into gibberish when appearing in sentences like “with <Car 20>”, “to <Car 20>” or “under <Car 20>”.

In short, with every language things get more complicated: each word may get inflected according to its immediate linguistic context. In a large project, this may generate innumerable problems.

How to avoid them? Create the content in a way that brings the possible need for inflection to the minimum. Keep things simple. Write clear sentences. Use lists. Separate content from presentation. Turn to CSS instead of grammar to make things stand out.

These and many other practices are what technical writing is all about. This is a field of its own, and people (like us) spend their lives studying and practicing it. But the simplest takeaway in the context of content localization is: to keep problems at bay, have your single-source content well written.

Don’t compromise on translation quality

Now, what does the translation process for single-source content localization look like? It’s different. Translators don’t simply get Word or Excel files and meet impossible deadlines. In fact, they often need to get fragmented pieces of content, possibly bereft of context, and then they meet impossible deadlines.

This situation is a by-product of the single-source authoring methodology itself. For example, the authors keep long lists of UI strings in variable files, so that they’re sure they appear consistently throughout the content. How do you make sure that they’re translated consistently as well? Using a translation memory tool is a start, but the most efficient way is to translate the UI strings (in their variables files) first, and integrate this with the translation memory tool when you translate the main content. But this only works if you are using a translator who understands the relationship between the UI strings and the wider set of content.

For each language, use a qualified native speaker who understands your domain and knows how to work with the latest translation technology. So avoid the temptation to use ‘cheaper’ translators for this type of content: crowdsourcing, half-professionals, 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.

Test early

Depending on the single-source toolset you are using, there will a number of elements that are worth testing to help minimise difficulties in the run-up to a delivery deadline. These tests are sometimes ones you can either do using the guidelines or previewing features built into your tool, or work with your localization partner. Before you test anything, make sure you have understood how your overall documentation file structure will handle localization – understand and imagine the scenarios that might be involved with having 20+ target languages or local market variants. How does your toolset organise for this, and how do the relationships between master files and variants or targets work?

Two testing techniques that can be particularly useful are:

• Pseudo translation — your localization partner can take a sample of your content project files and automatically replace your English with characters deliberately designed to simulate the impact of translating into languages that might put pressure on your layouts, such as German, Russian, Chinese, Hebrew or Arabic.
• Source capturing — the localization partner can check with a sample ‘bundle’ or ‘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.

Single-source content localization done right

Single-sourcing is a tried and tested methodology bringing clear benefits. Still, localizing large amounts of content is always a challenge, and it’s no different in case of single-source content. Big and bold localization projects need more thought put into them. The best ways to make sure everything goes smoothly are good writing, quality translation and early testing. If you take care of these key aspects, everything else should be on your side.

Have you dealt with single-source content localization recently? Or maybe you are facing other localization challenges? Give us a shout here.