Hannah Brady is a project manager at Welocalize, based in the UK office. She has spent a number of years in the localization industry, working with clients with high volumes of technical documentation. In this blog, Hannah focuses on high level documentation and looks at how to best prepare technical communications for localization.
Documentation is critical for creating and selling a global product. Technical documents, in particular, are important for end users to understand how a complex product works and how to operate it safely and effectively. A clear, concise and well-written document also helps sales teams to promote the product and increase sales. The translation of technical documentation must also bear these qualities in order to compete in the global market.
In my years as a project manager (PM) at Welocalize, I have seen technical documents in many shapes and formats. These range from instruction sheets, datasheets and specifications created with Microsoft Office tools such as Word, Excel, PowerPoint and Publisher, to more complex user guides, operator manuals and drawings authored in more sophisticated software like FrameMaker, InDesign, MadCap Flare and AutoCAD. There is a lot more to localizing a document than simply forwarding it to the translator and review teams. It takes time and effort to put together a technical document in its native format and it takes similar effort to prepare a document for translation, separating it into its different components.
There are different approaches and methodologies involved when dealing and preparing the different documents and file formats. As a PM, it is my job to ensure the scope is assessed. This means examining the native files in detail to see what should be translated, which tool should be used for translation, and ultimately how much it will cost. As many other PMs will agree, it is essential that all materials are available and potential pitfalls are covered right at the start of the project life cycle. This is especially critical as there is little margin for error given the need to provide specialist target content under time pressure. In addition, missed text and graphics discovered late in the workflow can be disastrous, resulting in missed shipments and launch deadlines. At Welocalize, we have a pool of dedicated experts who assess all components of technical documentation and can advise on the best approach.
Tips for how best to develop and prepare source documentation:
- Write content clearly and with a global audience in mind. It goes without saying that a poorly written document can make or break a successful product. If a translator has trouble understanding the message behind the source material, there is every chance that it will not be rendered correctly. Even worse, serious misunderstandings can occur which will have a disastrous effect on the reputation of a product and indeed the business responsible for it. Ensure that your document is written clearly and neutral and is free of colloquial registers that may be misunderstood.
- Make room for language (literally). Translated text is often around 20% longer than English, needing extra space to fit into the document. It is recommended to design your document with this factor in mind, positioning graphics and text boxes to allow enough white space is available to accommodate longer text. It may be necessary to reduce the font size at DTP (desktop publishing) stage to fit text, so it is also worth considering how many points you can allow size to be reduced and provide instructions to the PM.
- Provide all materials needed for the document in an organized structure. To ensure that accurate quotes can be issued quickly, it is essential to provide all native files used to create the source document, which should be editable. This includes graphics used in the document. Instructions or guidelines on how to process certain files are also invaluable for planning a project and final QA (quality assurance)review before delivery. By ensuring everything is available right at the start, it allows the necessary questions to be asked at the beginning of the project cycle and avoids delays halfway through due to queries.
- Avoid embedding text in graphics. CAT (computer-assisted translation) tools can only pick up editable text for translation. Our recommendation is to avoid inserting text in non-editable graphics and visuals. A good alternative would be to consider using captions instead. However, if your company design does not allow this, our evaluation team is on-hand to keep an eagle eye out for graphics and advise on how they should be handled. By ensuring all files are editable, significantly reduces the risk of errors and resulting delays and extra costs. To read more on text expansion, see blog Seven Golden Rules for Optimizing Graphics in Technical Communications.
- Use hard returns and spacing with caution. We often see hard returns used in technical documents, many times in the middle of sentences, to ensure the text fits into the design of a document. While inserting such breaks is an easy way to design the layout of the source text, split segments can cause problems for the translator. It also increases translation costs unnecessarily. For example, if a sentence translated in an old manual is split by a break in an update of the document (even though the text itself is exactly the same), this results in a loss of exact TM (translation memory) matching and discounts.
Translation of technical documents requires careful consideration and planning from all sides involved in the process. Following these best practice guidelines will help ensure your documents are translated accurately, on time and that costs are kept to a minimum.
In April, Hannah wrote a blog, Welocalize’s Guide to Localization in the Global Manufacturing Sector which looked at how technical documentation, which is common in the manufacturing sector, must be accurate and comply with standards, directives and regulations imposed by authorities of the target local market.
Based in the UK, Hannah Brady works in the Welocalize UK office.