Unfortunately, translation seems to be often regarded as an ancillary task or as an afterthought during production/development, and this is particularly true in case of software and (even more so) game localization, given all its peculiarities and additional constraints compared to “plain” translation (although one might rightly argue there’s nothing “plain” about translation anyway…).
This approach may cause a host of issues, delays, need for changes, rework or forced sub-optimal choices and workarounds when it finally comes to the translation/localization of contents for your products or services. You can imagine how negatively any of the above could impact either your time-to-market and/or translation quality, which in turn will negatively impact on your company and products image on foreign markets.
More than once I’ve found myself struggling with a translation task because localization (aka “l10n”) or internationalization (aka “i18n”) were not taken into due account during the design and development stage of a product…
So, here’s a few tips from a translator’s perspective in order to help you avoid common issues and pitfalls and get a better end-result:
- Context!!!Context is key. This might sound cliché, but, as a translator, I can assure you it is not, and what’s more, it can make a big difference in terms of translation quality and even plain correctness. Imagine having to translate an apparently very simple and straightforward string, such as “Your friend has received a %s”. Just 5 words and a placeholder. What could go wrong, right? The answer is: a lot. Italian, like other fusional languages (including the “traditional” quartet of FIGS) uses grammatical agreement much more than English, so, in the example above, I would need to know whether the “friend” is male or female and “your” plural or singular in order to translate that part correctly, and same goes for the indefinite article before the placeholder %s. Another very simple example: a string with a single word, “clear”. That can happen quite frequently in localization, but how would you translate that without any context? How to choose one out of its possible meanings? Obviously, often meaning can be inferred by the general topic of the text and “surrounding” segments, but ideally, in case of doubt I would need to raise a query to make sure… So, in short, context is extremely important to get a translation right, and sadly, it is often lacking. It is always highly recommended to provide as much context as possible about the material to be translated, including both details about the text itself (e.g. ID strings, notes, comments, screenshots, test builds, etc.) and a project brief or localization kit that details more general aspects, such as info about your company, project, style, tone, target audience, etc.
- Translation timing and workflowDeciding whether you want to translate/localize your content during development, as it is created, or after, when it’s more or less ready and finalized, will unsurprisingly have quite a big impact on your translation efforts and their results. Some companies want to be able to launch their product on several markets at the same time (“simultaneous shipping”, or “simship”), so they start localizing their content as they create it instead of waiting for it to be ready, proofread, checked, finalized and approved before sending it for translation. While “simship” might sound good in theory and when considered from a business perspective, it obviously presents a number of issues that will negatively impact all the tasks that depend on having final, polished, cohesive and well defined content to work on, with translation being right there at the top.
- Project size and completion timeThe first consideration is pretty obvious: like all good things, translation too requires time, care and attention, so rushing it is never a good idea. And please believe me if I say an independent translator doesn’t enjoy spending more time than necessary on any given task, especially if and when being paid by the word. A translator can handle around 2,500 words per day, on average (although the real figure depends on a number of factors). In case of a medium or large sized project, (i.e. 100,000+ words), it could be split among several translators, but this would imply additional issues, such as differences in style, a much greater chance of term inconsistencies, plus an increased overhead due to the additional coordination and harmonization tasks (which are not trivial).
- Careful use of variables, placeholders and text splittingAnother “critical” aspect I’ve noticed more than once throughout the years is a rather “liberal” usage of placeholders/variables without a proper definition (or any definition at all…), so much so that it often becomes impossible to translate a string without asking what the placeholder(s) in it mean(s), thing which obviously reflects into additional time being spent on both sides on clearing such doubts. Additionally, I’ve already mentioned above all the issues such an approach might create in terms of grammar. Likewise, and linked to the placeholders issue, in several cases I’ve seen sentences broken into pieces, then translated separately, in the hope that those “pieces” could then be reassembled at will, like building blocks. Unfortunately however languages don’t work like that, as every language has a different grammar and syntax, so a similar approach is only bound to cause infinite (and likely critical) issues when it comes to localization, and should therefore be avoided at all costs during design/production.
Here’s an example of what might happen if you try to split your source text into too many “pieces”, solely based on English grammar and syntax On the upper part, you can see an example of mismatch in person-verb agreement in Italian, which would make the segmentation of the English source really problematic. In the lower part there’s a slightly modified version of something I really encountered in a localization project, and there’s basically no “solution” to it, unless you know exactly how those bits are going to be used and where (thing which would basically defeat the purpose…). At any rate, please don’t do that…
