Reducing Documentation Translation Costs
Igor Vassiliev, former Senior Localization Project Manager at Adobe, offers advice. |
I first started working in localization in 1993. At that time I was mostly involved in production and QA, went through a number of companies and title changes, and finally spent the last 6 years managing localization projects for one of the major software companies in the Silicon Valley.
A lot of things have changed since my first localization job. It’s one of the most fast-paced and dynamically changing industries today. As soon as one gets used to doing things a certain way, here comes a new technology that completely changes the work flow, procedures, and one’s job description! I went through such changes at least twice in the last three years. Sometimes it’s fun, and advantages are obvious, while other times it’s a major learning curve made worse when the technology in question hasn’t been sufficiently tested and cleared of bugs.
All of these changes influence the price tags on localization projects. Obviously, there are two sides to every project: the clients and the vendors. Clients are trying to reduce the localization costs, while the vendors generally don’t mind marking them up when possible. I have to admit, however, that lately, as translation companies merge and take over their competitors, this trend is going down. Large translation companies are much more interested in continuous business than in a short-term profit, and I have been able to negotiate significant reduction in price of the localization of documentation even when I couldn’t argue with the quote.
Introduction and universal spread of translation memories has been one of the major factors in reducing localization costs. But every new technology comes at a price. When the World Server was adopted by our company a couple of years back for localization of documentation for a major release we found ourselves in a world of trouble. The system was very buggy and needed some serious customization. Nobody could have possibly anticipated problems with importing and exporting files, graphics falling out, problems with generating PDFs and Help builds, broken activation links, or some J-specific issues like character corruption, duplicated index entries, template bugs, problems creating the review on the Document Review Server, or problems caused by the structural update of documentation, which were, for obvious reasons, not included in the original quote, and in the end caused major increases in the projects’ costs. As the system was getting modified, these charges went down significantly. Besides, for the next project, they were somewhat expected and included in the original estimate.
Another unexpected price booster is the sim-ship model, when multiple localized versions are supposed to be released simultaneously with the English application. The trickiest part here is to get the product team to freeze certain features by certain dates. If they fail to do so it will have a ripple effect on the rest of production and localization. We discovered that the only way to achieve the sim-ship was to schedule multiple documentation handoffs: the first one contained legacy materials, and the rest scheduled based on the completion of the features.
The problem with such model was the fact that the product team’s engineers never stopped working on the application, even after certain features were frozen. They would release the features with critical bugs fixed to editorial and production, but later go back and fix some minor bugs. Unfortunately, most of such “non-critical” fixes were affecting documentation, and a lot of chapters had to be handed off to vendors 3, 4, sometimes 5 times. The funny thing about such multiple handoffs is that vendors have to review everything but ICE matches every time they implement the changes, and reviews are not free. Thus we ended up paying for vendors’ reviewing basically the same content many times over. Not to mention the extra time spent on implementing all these changes times the number of languages! Quite frankly, I am still very much in doubt about the business sense behind this model… It seems to work a little better with smaller, 4-5-language projects, but these extra costs are still inevitable, albeit less noticeable.
If I were to summarize my experiences and offer a few tips to a localization project manager, I would say the following:
1. Maintain good personal and professional relationships based on trust and respect with your vendors. It’s amazing how much can be sometimes achieved with a nice friendly chat over the phone!
2. Always make sure that the vendor’s original quote contains all possible charges, and vendors do not add any unauthorized tasks to it later in the project.
3. If you have multiple vendors, review their quotes side-by-side to verify that they only differ in rates, and question any deviation from their original quotes. Vendor project managers do make mistakes and usually appreciate it when you correct them.
4. Make sure that translation memories you provide to the vendors are the most current ones; the more they can leverage the more you save in translation costs.
5. If you are using the sim-ship model (seems like everybody is switching to it these days!), negotiate with the product team freeze dates for the features, and educate them about the problems and extra costs caused by any modifications to the “frozen” features. If it saves you one extra handoff and one extra review cycle, you are already saving your company some serious money.
6. Sometimes editorial and production folks find mistakes in documentation. In a rush to complete the files and push them out to localization they sometimes miss things. Do not try to re-deploy the affected files right away, but rather include them in the next scheduled handoff. There is always a chance that more problems will be discovered and fixed in this content in the meantime.
7. As an afterthought, I would like to throw in a suggestion to instruct the vendors to not review 100% matches more than once. They are quite extensive, and the costs of multiple reviews of such content can really add up. Granted, there is a certain risk involved in such a decision, but in my mind it’s easily outweighed by the resulting cost savings.