Top 5 technologies to translate a WordPress website

A guest post by GTranslate’s creator. Edvard has been in the website translation industry since 2008.

Every website owner understands the importance of global presence. An important step every website owner must take is to make a step forward to be a part of the global market by translating their content.

Today we are going to discuss all the available technologies on the market to choose from and find out pros & cons of each solution. We are not going to discuss how the website content is going to be translated, whether it is an automatic translation or the content is being translated professionally or written from the scratch for each target language market. All these technologies have a potential to use all or mixed approach, but the main focus is to learn about the techniques used by each technology and learn about advantages and possible pitfalls of each of them. I presume that the reader has some basic understanding of how websites work and general knowledge about what is HTML, CSS, JavaScript, what is a web server and what are server side programming languages like PHP.

The ideas discussed in this post do not necessarily presume that your website is built using WordPress and you run on PHP. It can be built on top of any platform using any programming language. The examples will point attention to WordPress as a popular platform for building websites.

Here are the main technologies available around to make your website multilingual, we will discuss them in detail:

Built-in solutions
Multi-site solutions
Third party translation plugins
JavaScript based cloud solutions
Translation proxy solutions

#1 Built-in solutions

If your website is based on a CMS like Joomla, then you may choose the built-in multilingual solution developed and supported by the CMS authors and there is no need to install a third party extension for that task. This approach is very good in terms of performance and usually takes into account optimizations towards multilingual projects and considers many specific design optimizations towards localization task. However, you will need to make sure that all your third party extensions and templates are developed by following the CMS specific guides and are compatible with the platform’s built-in multilingual feature. The last is not always true and you will have a hard time finding a place to change some text which is not translated and this is not always going to be through an admin panel and may require you to modify some files, which is going to become a pain, because of the future updates.

Read more about the 8 steps to make Joomla website multilingual using the built in multilingual feature.

#2 Multi-site solutions

Of course you may consider building a separate website for each language, this is the most flexible solution around. WordPress has a nice multi-site feature, which allows you to have the multiple websites which share the same files, but the information is stored in different databases. Overall I would say that this is a good approach, but maintaining multiple websites is a hard and time consuming task.

#3 Third party translation plugins

This is a very broad category and we are going to discuss some different approaches here, it is very similar to having a built-in solution, but it is not implemented by the CMS authors, but a third party developers. Usually is not as performant as the built-in solutions, since it requires additional software installation on the server and may have the same compatibility issues with the web server and with other third party plugins or modules.

This plugins or extensions usually use one of the following approaches when making a website multilingual:

Research all the platform features and build some interface integrated into the platform’s admin panel allowing content creators to add different language version of each content and also translate all the text labels used on the website.

This is a mammoth task and I have never met a solution which can be considered as 100% complete, there is always something which is not possible to translate with it and it has to be modified to get there. Even if you get there, you are pretty much stuck and cannot do unsupervised plugin updates to not revert your modifications.

Introduce some content creation syntax, which doesn’t require introduction of a new interface.

For example you write the content like this: {en}English here{/en}{es}Español aqui{/es}{ru}Русский здесь{/ru} and later right before the website content is rendered this plugin filters out the extra content leaving the right language content which should be displayed.

This is a very nice approach which I consider to be a shortcut and a hacky way to get there without too much stress. I remember building one myself for Joomla platform and there are similar solutions for WordPress as well. However, this approach has some drawbacks:

Usually some interface form fields are limited in length and you easily hit the length limits, specifically it is a problem with post titles.
Sometimes form fields do not allow specific characters and you cannot simply have the syntax placed there.
Sometimes the syntax characters you use are being encoded and it causes a mess.
You may easily do mistakes related to the syntax when modifying huge contents and your website will become messed.
The program which parses the specific syntax can easily hit the web server memory limits when the content is huge or the number of languages are many.
Also, you cannot simply uninstall the plugin and get rid of all the extra content you have added, you need to use some cleaner plugins, which are not always available and not always work perfectly.

Inject a JavaScript library into the page content which is sent to the visitor which will then be executed on the browser to find all texts, replace them with the translated ones and finally display.

It is a good approach overall and requires less resources from your server and has no server requirements from your side. Usually this solutions offer a nice in-context editors and translation process becomes a breeze, since you do not have to go into the back-end interface to find the right place to modify something and also out of the web page context.

However, adding a JavaScript library may cause conflicts with other JavaScript libraries and create infinite loops of event listeners firing one after another changing content like crazy. Most common issues are conflicts with sliders and countdown timers.

Things get really tricky when you switch from left-to-right to right-to-left language. It also increases the content size sent to the visitor, since now you have to send the original content plus the translations. It also adds additional stress on the visitor computer, which slows down the page load and rendering time a lot, especially on mobile phones which have less CPU power compared to desktop computers. This reduces overall SEO score, because nowadays the speed is very important if you want to rank high.

Moreover, not all crawlers and bots execute JavaScript code when they crawl your website. Back in 2008 when I was starting, non of the major search engines were executing JavaScript code, so the content added by it was simply not visible to search engines and your website did not rank for all multilingual keywords, you could also be hit by duplicate content penalties because of that. Executing JavaScript generated content was started from 2014 by Google and now almost all major search engines support that, but it is still considered as a bad approach, not all bots execute JavaScript when crawling your website. For the reasons mentioned above there are pre-render (server side rendering) services for websites around to solve this drawback.

Also, for the same reason, Accelerated Mobile Pages (AMP) will not be translated, since JavaScript is disabled for them. It is also a hard task to have a separate physical URL for each language page using this approach only, so SEO suffers a lot overall with this approach.

Parse the HTML content right before the output, replace the texts with the translated ones and then send the translated HTML to the visitor.

This is a great approach overall and GTranslate was offering this approach till 2016, before fully migrating to the cloud translation proxy solution we now offer.

There is no technology which has no drawbacks, so here we go:

This approach is a resource intensive task which runs on your web server unlike the JavaScript solution discussed earlier, which runs on visitor’s computer. It consumes a lot of server’s CPU power as well as memory for HTML parsing task.
If you are on a shared hosting you can easily hit the CPU execution time limits as well as memory limits if the HTML size is big enough.
If you have major HTML errors, you may end up having broken layout issues after page translation, but it is a nice way of discovering and fixing HTML errors on your website.
Since it runs server side, it does not execute JavaScript code inside HTML, which may contain some labels and even content, so they are not being translated and have to be dealt separately, so if your website content is generated entirely from JavaScript, it becomes invisible to the HTML parser.

Mixed version of the previous approaches.

You may check this article for best translation plugins for WordPress.

#4 JavaScript based cloud solutions

This is very similar to the JavaScript solution discussed previously, so if you have skipped it, please read it as you move forward.

The main difference is that the library itself and the translations are stored not on your server, but on the cloud provider’s network and usually they load faster compared to loading from your own server.

To make your website multilingual using this approach you just have to copy paste some code into your pages and that is it. But again, JavaScript based solutions do not offer clear separation of translated pages based on page URL, they have problems with bots which do not support JavaScript, Accelerated Mobile Pages are not supported.

Overall it is very hard to get it right in terms of SEO. GTranslate offers this approach for websites free of charge.

#5 Translation proxy solutions

This is very similar to the HTML parsing approach discussed earlier, so if you have skipped it, please read it before you move forward.

The main difference is that the parsing of HTML to find texts and replace them with the appropriate translations happens in the cloud without consuming any resources from your server. It is like having a translated mirror website which you do not have to maintain.

This is a universal solution which works on a network level without any server requirements, software installation on your server and even JavaScript can be disabled browser side and still your pages can be translated.

Since you do not have to install any software on your server you do not have to worry about the security issues third party software can cause to your infrastructure. This is critical for government websites and other industries where security is essential. Also, you do not have to update anything every time there is a new version available, all happens on the cloud, seamlessly.

The translations are stored in the cloud and delivered to the visitors upon request of the translated page. What happens under the hood is very similar to how people speaking different languages communicate with each other through an interpreter.

So when the visitor requests for a translated page the request is being forwarded to your main website by the translation proxy and when your main website responds, the response gets translated before it reaches the visitor. Technically this adds some overhead, but it is measured in milliseconds, since the translation proxy servers unlike your hosting servers are optimized to do one task, which is to parse the HTML, replace the texts with the translated versions and pass forward.

There are 2 main types of translation proxies. One is based on a streaming approach and other is doing buffering. The streaming approach is comparably faster, since it parses and translates the HTML content chunk by chunk and sends the results when available, more like the synchronous interpretation happens.

The other one needs the full page content before it starts parsing and translating, similar to how professional translators translate books. With the streaming approach it is harder to do a good translation and control how the process goes, since there can be cases when the end of the HTML can affect how you translate the beginning and when the chunk is already sent, you cannot reverse it to make changes. It eliminates the possibility of changing large HTML blocks all at once which is required when doing localization.

On the other hand buffering approach offers all the localization features, however since it needs the content in advance it can be comparably slower than the streaming approach, but the overall difference is miserable, since average HTML size is under 100 KB and when using buffering parser database translation lookups can be made with one request in bulk, while in streaming case there is a need to do multiple translation lookups, which eliminates the advantages, so that the speed is compensated.

Comparison table of different approaches side by side

	Built-in	Multi-site	3rd party	JS cloud	Translation Proxy
Ease of starting	👷‍♂️	👷‍♂️👷‍♂️👷‍♂️	🤷‍♂️	🐣	🐥
Ease of running	👷‍♂️👷‍♂️	👷‍♂️👷‍♂️👷‍♂️👷‍♂️	🤷‍♂️	🐥	🐥
Time to translate	🐌	🐌	🤷‍♂️	🚀	🚀
SEO	👍	👍	👍*	👎	👍
AMP support	✅	✅	🤷‍♂️	❎	✅
Running costs	🆓	🆓	🆓/💲*	💲/mo	💲/mo
Server requirements	🙅‍♂️	🙅‍♂️	🤏	🙅‍♂️	🙅‍♂️
Performance	🚀	🚀	🤷‍♂️	🚗	⚡

👍* – usually good when not using JS based solution, 💲* – usually one time fee to purchase, payments for future updates can add up costs, 🤷‍♂️ – depends on the solution

Conclusion

Time has proven that the future of website translation solutions is connected with cloud solutions discussed in #5 and #6 and mixing them together is the ultimate choice.

Other solutions are platform specific, limited to one programming language and can run on limited number of web servers. It is common that websites and their content migrate from platform to platform multiple times over a decade, for example many website owners have started on a static or self coded website, then migrated it to Joomla or Drupal, then switched to WordPress with WooCommerce and now many are switching to Shopify.

Make sure that the technology you use for your multilingual content is able to follow you through years.

If you are a website owner, please feel free to mention your website in the comments section and tell which multilingual technology you use and why.

If you are a multilingual solution vendor and you are reading this, please feel free to mention your solution name in the comments section and tell under which category your solution falls and feel free to share your thoughts.