This is the final installment in our 4-part series exploring the various details and aspects of the software localization process. This week we look at some considerations for the documentation process, which begins once software translation is complete. No matter how user-friendly your software is, it will almost always need some explanation for your users. Depending on its complexity, this could be anything from a two page “Getting Started” guide to hundreds of pages of in-depth documentation explaining the ins and outs of each feature. If you have translated software, it’s likely that you’ll want translated versions of the documentation as well so that your users can make the most of your product.
Choosing What to Translate
Just as when translating your software, it’s a good idea to think about what needs to be translated before you start the process. We see a lot of documentation with additional sections added on as the software evolves. While this does keep the user up-to-date on the latest features, it also usually results in documentation that’s far longer than it needs to be. For example, if you’ve had your English software up and running for twenty years, and are now adding localized versions, chances are you don’t need to translate that section on floppy disk installs.
Besides culling out-of-date information, it’s also useful to look for parts of your documentation that could be condensed or simplified for an international audience. If you don’t expect an immediate wide adoption of your software abroad, you might consider creating Quick Reference Guides to get your international users started, and wait to translate longer documentation files until the international version takes off.
. . . and When to Translate It
There’s a reason why this blog is the last one in the series on software localization: documentation should be the very last step of your software localization project. Good documentation refers back to the software and tends to be full of UI references and screenshots. So it only makes sense to wait until the translations of your program are set before moving onto the next step.
If we’ve already translated your software, that means that all of the UI strings are in our translation memory. That means that when the documentation says, for example, “Click on the Settings tab,” we already have the translation for the word “Settings” and can make the two translations consistent with each other. If there are screenshots in the documentation, we can also reference those to make sure the instructions are just as clear in the translation as in the original.
. . . and How to Manage It.
Any major changes to your software will likely result in updates to your documentation as new features are added and functionality changes. In Part 1 we talked about the best way to manage software updates. The best way to update your documentation is similar in nature—if only certain parts of it change, then only certain parts need to be updated, and everything else can remain unchanged. This is one area where topic-based authoring really shines. There are lots of different tools out there for content management and topic-based authoring, with two common ones being Flare and DITA.
Topic-based authoring tools are based on the concept of creating modular content that can be interchanged easily. These self-contained topics also make updates easier. If your documentation is built from topic components, you only have to send the changed topics to translation and can reuse everything else. A content management-based approach can also focus on making content that’s reusable, and writing less context-dependent content that can be used for a number of different topics. This feature is great for translation, since we use translation memory tools that “remember” previous translations and suggest them for reuse in the future—which lowers costs and speed up turnaround.
The Key to Software Localization Success
There are a lot of parts to the software localization process, from identifying your initial needs, planning out the process, and getting everything ready to launch. The key to each of these steps is the clear and thorough communication of your needs and specifications. Every software project is different—once we know what’s different about yours we can find a way to make it a success.