Translating a website out of context can be a top reason for bad linguistic results. A translator can’t see the big picture, which could very well alter the phrases he/she chooses. Potentially ambiguous or “anonymous” strings require translator instructions or guidance. Also, the text might just look bad: text can expand depending on the language and no longer fit in dialog boxes and images.
There are a number of in-context website translation tools on the market (some embedded within a CMS, some not), where a translator works directly with the web content, as it would be seen by the end audience. The translators will see their translation populate the web site (which is somehow connected to this tool) automatically. This all helps the linguist to better understand the context and make sure that translated content fits within the layout of your website.
Well, that would be nice.
The problem with built-in translation tools is that they don’t have the features of standard industry CAT tools – Translation Memory for example – which make use of past translations and which drive consistency. Consistency is especially important when you have multiple translators and if you have any kind of brand – look and feel – that is important to your product and that you want to preserve. (Where is this NOT the case?)
Another major problem is that this in-context view doesn’t prevent any functional bugs that are related to how the content displays. So, let’s put that in-context tool aside and look at other options.
How Is It Done Now?
A typical localization process for web might look like this:
Where in this process do you ensure that the website will “work” linguistically? And take advantage of assets like Translation Memory and Glossary? You can adapt your process and get great results without the addition of another tool. There are three big additions to the 1-2-3 process above.
It Doesn’t Have to Be This Way
How can you do it better, and avoid introducing some tools that may or may not work? You would:
- Take internationalization preventative measures. You can do pseudo-localization to see whether translated text works in a website, how translation “breaks” a website’s formatting or messes with its look and feel. This will identify things that need additional attention from the web developer.
- Give translators good instructions (string length information means they won’t exceed the length that can fit in a box). Provide them with branding references and access to the English website, whether live or via a staging server.
- Do linguistic testing, post build via:
- A staging server – ideal
- Emulator or simulators – sometimes
- Screen shots – not perfect but it can help
An additional huge benefit of post-build linguistic testing is that you can catch functional bugs: system or configuration errors, links that break, pages that don’t display, images that don’t show up, misalignment, non-working functions (like upload file, reply by email to posts). But also note that any WYSIWIG translator tool is a linguistic tool, not a functional tool.
Note that while I am mainly talking about the appropriateness of translation, it may also be valuable to consider formal functional testing, especially for very complex and dynamic websites. This is done by a tester, not a linguist. There may be some UI/functional issues where linguistic testers might not feel comfortable with this work or may not know how to work within some bug tracking systems. In this situation, test cases, which will map the website and the work to be done by a tester, may be required.
So now your process – solving the problem of linguistic errors occurring as a result of translating out of context – looks like this.
You can also add automation to extract your text (connector brokering communication between your CMS and a TMS), but you don’t need to incur that expense to get good results. The benefits of those tools are strongest for large enterprises with a lot of content.
Does it take more time? In preparation and preventative measures, yes. But there are fewer linguistic fixes at the end because you’ve followed a solid, methodical process. You don’t need any tool to do this; you just need to add a few steps.