Understand the differences between traditional and proxy-based website translation by reviewing our hypothetical case study which focuses on comparing two key considerations.
Subscribe to our blog
Website translation can be a daunting process if it is not planned well no matter which method (traditional or proxy) is chosen. While proxy technology has been on the market for a little while now, we still get quite a few questions: Which is better, traditional vs proxy website translation? How do you tell which is right for your company? What are the pros and cons of each option?
To better understand the differences between traditional and proxy-based website translation we thought we’d take a look at a hypothetical case study. There are two main factors to consider: 1. Internationalization/extraction and 2. Publishing updates.
For the purposes of this comparison, we will use Acme.com, a made-up "marketing" website. Acme.com is currently using a Drupal content management system (CMS). While this is a real website (created for examples like this) and real content management system, the scenario we’re discussing is entirely made up – for your learning pleasure.
(And if you’re scratching your head in puzzlement as to what I mean by website proxy technology, I humbly point you in the direction of this free downloadable ebook – all about translation proxy.)
Traditional vs proxy website translation: internationalization & extraction
In the localization biz, internationalization is the practice of making a website ready for translation. Preparing how the content will be served and stored and finding all the strings and sentences in the code so they can be extracted. This phase of website localization is often the most expensive.
Let’s take the Drupal CMS for example. It’s pretty well set up for localization at the base level. However, for full localization, translation modules must be added and configured to extend the system’s functionality. In addition, because each Drupal site has its own specific theme, this needs to be localized also. This means digging into the code of the theme to make sure every interface string and sentence is extracted and accounted for. If there are specific functions that were developed in-house these also need to be made ready, i.e. internationalized. When all of this is complete all the strings can be extracted into a file for translation. And that’s all before translations can begin. Sounds labor intensive right? Because it is.
Traditionally all this work needs to be carried out by a developer close to the project code. It’s time-consuming and factoring IT contract rates, very expensive. The extraction phase can last between one to six months, depending on the site complexity.
With a proxy there are zero lines of code and typically no more than an hour or two work for your IT team on a standard setup. And a localized site can be launched in under a week (excluding the translation time). This results in substantial time and cost savings of over 70 percent, not to mention the opportunity cost of your development team working on other features.
Traditional vs proxy website translation: publishing updates
With all of the content found (during internationalization and extraction) and with a structure established on the website to enable publishing new translations, the next step then is handling updates.
Using the traditional method, a project manager opens a dashboard and selects the articles or content that he or she wants translated. They then export them to a translatable file type. In addition to these files, there may be other areas of the site or theme which are not automatically included, so they would have to be pulled out manually into a file as well.
Once these are packaged in a zip file they are sent to the translation team. Here they are translated and then returned to the client in the same zip file. The project manager then imports the files into his (or her) system and goes through a publishing process for each of the articles. If a test or staging site is included this is even more complicated. Translators are invited to review the site once translations are published to make sure that the translations fit into the design. If not, they have to be exported and translated again. When you multiply this process by several languages every time new content is published you can see how it becomes a full-time salaried position. Or at least a large portion of a marketing manager’s time.
Using the proxy method, the site is set to be scanned or “crawled” at a preset interval weekly or monthly. Any new content is automatically discovered. The site manager is contacted and asked if they are interested in going ahead with the new content translation (most are thrilled for this reminder!). Content is then translated and reviewed in its final layout to avoid broken design and style issues. It is then published directly to the site.
If we compare the amount of time the site manager has to spend in the publishing workflow in the traditional vs proxy website translation method, it is substantial. Often amounting to a full salaried position if not the bulk of a manager’s time. Again, in most cases over 70 percent savings in time and cost.
And the winner is?
While we understand there are many valid reasons for translating a website using the traditional method, in many cases, we feel that a proxy, like SiteSync, takes the cake.
We’d be happy to chat more about the benefits and bummers of traditional vs proxy website translation. What do you think? Have more questions?
About the author
Robert O’Shaughnessy is a Solutions Architect at AMPLEXOR with an extensive background in web development, marketing and translation. Robert’s goal is to help clients arrive at the most cost effective and streamlined solution by leveraging AMPLEXOR’s expansive technology and services portfolio.