Website Localization with Translation Proxy
Balázs Benedek, Easyling’s co-founder and COO, clarifies the basic concepts of translation proxy technology and covers other topics including dynamic product catalogs, CSS overriding, the bleed-through phenomenon, content multiplier parameters, workflow automation for the new content and translating content beyond the login sessions.
The reason why the traditional way of website translation is so cumbersome is that the sites are not static HTML files any more, but generated dynamically from bits stored in databases and CMSs (Joomla, Drupal, WordPress, etc.). This setup makes the extraction of content rather problematic and labor-intensive for the clients. Already the first step – giving a quick word count – is problematic for dynamically built websites. The proxy makes this a lot easier since it works like a crawler, automatically scans pages while it is also capable of excluding unnecessary content from the word count. This is why defining the scope of the translation project is crucial. The crawling also provides a repetition count, which can be as high as 60%, or even 90% for e-commerce websites.
While Easyling can be used as a real-time, in-context tool for translating, we realize that many translators prefer to work in their favorite CAT tools; therefore the content can be exported as an XLIFF file. Even for these translators, Easyling’s preview feature can be very helpful for contextual error detection, handling text expansion, proofreading or submitting the translation to the client for approval. Tracking the changes is aided by the auto change detection feature that enables an automated update process: it notifies the translator who can offer the client to translate the modified content.
In summary, the greatest promise of using a translation-proxy based solution is the ability to get an up-and-running translated website very fast. No additional translated website version is created because the proxy works as a layer: it removes the original text from the website and inserts the translated text from the translation memory on the fly. Easyling also provides a white-labeled version of its solution to LSPs.
Digging Deeper into the Tech Background
2. Login protection Translation proxy can also work for sites that require user authentication for accessing their content (entering username and password). In summary, the proxy solution uses the cookie that stores the login information and thus can crawl all the relevant pages. The translation proxy only uses the cookie for a specific user and session, ensuring that no security breach takes place.
3. Product catalogs and e-commerce These are usually very large projects with a huge reward, but also some great challenges. The checkout process is usually handled by a third party system, and once the payment is processed, the user is redirected to the original domain. In these cases, the cooperation of the client is necessary. The other issue is the handling of the different currencies. Usually, the user sees an estimated amount based on a currency rate while browsing, but at the end the amount is charged in the original currency.
4. Bleed through The issue of bleeding through is one the greatest challenges. Since there is a live connection between the original pages and the translated site, when the original site is modified, the modification “bleeds through”, and shows up in the source language on the translated website. There are several ways to cope with bleeding through – these are temporary patches to bridge the period until the actual human translation is ready. The default solution is to use the existing translation memory with the fuzzy matches, or, use machine translation. There is also a freeze function to display the last known fully translated page. Though outdated, the page is at least fully translated, and can be updated when the human translation is ready.
5. Page modifiers The use of page modifiers can be important at the correct delivery of the translation. For example, if the translation is longer than the original (e.g., from English to German), then the translation won’t fit into the original layout. In this case, the translator has two options: shorten the translated text as much as possible, or, use CSS or JS page modifiers to decrease the font size.
6. Search issues Since the translated content does not exist at the original location, the search solution of the original site will not work either. The easiest but least satisfactory workaround is to machine-translate the search term, locate the content at the original site, and then provide the translated section. For better results, use an external search engine, preferably Google Custom Search Engine, which comes with a fully customizable layout and design.
7. Publishing in subdomain It is also possible to publish the translated content under the domain as a subfolder, but it requires some involvement from the client. If the client’s server uses a load balancer/reverse proxy such as nginx, it is possible to map the translated pages provided by the proxy under a subdomain, so the heavy lifting is done by the translation proxy, while nginx can forward all the requests to these language subfolders. Then the translated content appears in the subfolder instead of a subdomain.
8. Content connectors Proxy is a great tool for content extraction, but at the end of the day some clients want to see the content in their content management system in an editable way, e.g., being able to control the translation directly from their CMS. Unfortunately, putting back the content into the original CMS is even more difficult than extracting it from there. We do not offer direct content connectors at this point; however, we are experimenting with different approaches. Right now we offer a WordPress plugin, which is a content delivery service. Users can’t edit the blog post in the original environment, but the plugin serves the translated pages from the client’s original web server.