For organizations having global presence, to be successful in the foreign market one has to often depend on the documentation which is localized and properly rendered or translated. But localization and translation process can be tedious, costly and time consuming. Unable to keep up with the localization expenses, organizations often limit them or forgo them altogether.
With prior planning, localization expenses can be reduced substantially. However, this requires more than obtaining the best deal from the localization vendor. A lot of thinking goes in during the time of content creation or technical writing. Experience has shown that below mentioned 10 steps can cut your localization expenses by 50% or more without affecting the content’s effectiveness.
Top ten ways to save on Localization Expenses
Screenshots are an efficient way to correspond the user interface and working of an application. This is the reason why screenshots are widely used in documents at every level. But screenshots do not prove to be effective during translation and localization. This problem occurs because of following reasons:
All screenshots are taken again for the localized product. The software needs to be set up with metadata, database etc. – once for every screenshot and for every language. This is very tedious, costly and time consuming.
Very often, the task of making new screenshots goes to the QA group, who may not be skilled to make and analyze screenshots in a foreign language.
There is another case which is just as bad. Many a time’s small organizations decide to translate the document but not the actual software. So you end up with the main document in the translated language and screenshots in English. This can be reduced with minimum or no screenshots.
Translation costs are calculated on word count or the number of words – this one is very clear. This has to be planned much earlier – it is much simpler to write compact material than to cut on words during localization. And fewer words also make the document easier to understand and translate. This effect becomes many folds by the number of documents, number of languages and the number of future revisions.
Graphics can be a great tool for communication if done rightly. Graphics do not have to be translated, they being a universal language. But if graphics include text then it becomes a difficult task, as the text labels used in the graphics needs to be translated and localized separately. For this reason one should avoid the use of text with graphics.
If the text has to be linked with the graphics, make it separately and present in a block. Now the text can be translated as part of the main document.
Same goes for applying callouts to screenshots. Callouts are good for highlighting, but each callout has to be done for every different language – a costly proposition.
There are many reasons:
The writers may not be able to understand slang and translate it.
There may not be exact words or phrases to explain the correct meaning of the slang.
The slang may not have the required context in the local language.
Finally translating slang is a costly affair. It becomes very cumbersome and time consuming and thus becomes expensive.
The same goes for any political or religious reference.
It is always a good practice to do text expansion at the time of translating to some other language rather than trying to fit into the confined space. For e.g. While translating to German 25% of text expansion happens.
A Word List helps understand a product or application and the terminology used. Lesser number of mistakes will be there when understanding becomes higher. A Word List should also maintain what is not to be translated and acronyms.
Using repetitive language reduces the cost of translation as the same content is repeated it has to be translated only once. For e.g. if you say “Press a button” do not use “Push a button” next time as it creates confusion and translation becomes expensive.
Use of XML in the technical document has attracted attention of late. Usage of XML can save on translation and localization tremendously.
For e.g. XML contains metadata – i.e. data about the document and its individual elements. During translation metadata can be added to tell which element is not to be translated. Also in new releases metadata can be used to tag the updated data which has to be translated and not the complete document.
This is a very good practice for technical documentation, but it becomes even more important for the documents which need to be translated. For example where the word “consider” would fit in, do not use “take into consideration”.
We mentioned this as the very first point. But this is the most important one so it is worth a reminder.
