We provide translation and localization support for our products. Mostly, our developers incorporate the localized text into the product code. But, occasionally we too get to handle projects. At the start of this year, we remotely assisted our colleagues to localize one such project. In this post, I take cues from that project to discuss about the key points that can help us improve our efficiency and the effectiveness of the localized content.
For each release, we create a documentation plan: We write about what we will document. We break our goals into parts, so that we can concurrently map our internal progress. But, the plan mostly applies to the standard product documentation. Since we only occasionally assist in localization, we have not had any documentation plan for our localization efforts, until now.
Based on my observations from the occasional localization projects, I can add the following referential checkpoints to my doc plan for such projects to help estimate and divide the time for the underlying tasks:
- Approval and verification processes for deliverables: We follow a three-stage approval process. And, we can increase/decrease either the number of approvers or the stages of approval based on the nature, need of our work. For example, a document may have three approvers, but still require only two approvals for finalization. Knowing such processes will help you create backwards plans that fit your water-tight schedules.
- Delivery modes: We can create touch points for our readers. These touch points can include website, CHM, manuals, SharePoint repositories, DVDs, PDFs, tooltips, and video tutorials. We can deliver our messages through module-based documents and web pages, task-based videos, and SharePoint links – or, maybe all of that! That’s because, organizations are pushing their content to their customers. And, you may have to synchronize your product documentation with the marketing collaterals. It is critical to know the requirements beforehand. The earlier we know the more time we have to plan the documentation.
- Plan assumptions and estimations: It is important to account for the unforeseen scenarios. For example, the absence/introduction of new tools and technologies, change of information architecture/roles of teammates/ scope and complexity of the project, resignation/introduction of teammates, postponement of the deadline of the project, introduction of a competing product, and other internal and external challenges: These unforeseen scenarios should be accounted (taken into consideration), while creating the localization-related documentation plans. One of my clients had to delay the project release date by as much as three months because of the then prevailing political state of the country. It was an external, uncontrollable factor, and we could do nothing but wait.
For our localization project this year, we asked our local representatives to help us correctly translate and localize. We considered the geographic and demographic information to help build product profiles. To make the content clearer (or hyper localized, in our case), we incorporated business cases according to the business categories of our customers. This helped in improving the comprehensibility of the documentation. For example, for a customer in the food industry, we provided real-life examples about food ingredients, preservation boilerplates, and shelf life-based inventory management.
As far as localization is concerned, it is not the information, but its presentation that matters. We reduced our localization efforts by tweaking the UI. We incorporated language-specific tooltips and context-specific pop-up help texts. But, all tech writers do not get to tweak UIs to localize. That’s because, a lot of technical writers work as freelance consultants. So, they don’t get the privileges of making changes in the product. In fact, most of them do not even get the product when they write about it. And, then the only way they can write is to tell how the product should behave, rather than how the product actually behaves.
During my stint as a freelance writer, I handled a couple of localization projects for my clients. Now, because I could not modify the UI – and include tooltips and context-specific pop-up help texts – I interlinked the information in the user manuals with relevant information on the client’s websites. I consulted my client’s marketing team (and, occasionally, the developers) to establish links in the documentation. This helped maintain consistency in not just one document, but across all marketing and product collaterals. My point is: I looked at both the big picture and its details.
Company-specific, original (or, at least, purchased) graphics
This is an addition to the previous point. Generally, it helps to have a unified communication strategy. And, it does leave a positive, consistent impression when you/your client’s communication looks well-connected. But, to create any such effort, only linking content is not enough.
Readers scan through pages. They mentally extract conclusions based on the keywords they read and process, while scanning through the pages. But, because graphics greatly affect this scanning and processing, it is correct to say that readers don’t read, but experience your content. Also, readers remember graphics relatively much easier than they remember your content.
When they reach from, for example, point A to point B, they may not remember what they read, but they will most likely remember the graphics they saw while navigating. So, we have to use visual cues and triggers to help direct the readers’ attention correctly. For our project, we took the help from our marketing department: We purchased images and photographs for our documents. And, we placed similar pictures on our website for consistency.
Graphics and pictures, as I’ve learned, help create the right experience. Besides, the color theme, font setting and size, placement of keywords, average sentence length, and adaptability of the content are equally important in getting the right messages across. But, it is important that the localized (and at times, translated) content conveys the intended messages correctly.
Back in the start of the year, we did not have any such checklist when we remotely assisted in the localization project. But, our internal discussions have helped us get a list of crisp points. Now, we know what to consider. And, I hope to see a better efficiency in my efforts for the upcoming localization projects, if any. What’s your opinion? Is there any point that you can add to this list?