WordPress by default is NOT multilingual. You can set up your language when installing it, but that just localizes your site to a language so translating WordPress in more languages is not something as straightforward as publishing a post.
Because of this, adding multilingual functionality can be done through a translation plugin, setting up a WordPress Multisite or using machine translation.
In this post we’ll go through finding what’s currently possible, what problems you can encounter, talk about machine translations and show you how you can simplify everything by just taking a different approach that combines the best of both worlds: machine translation and manual translations combined. Sometimes both are needed to translate WordPress in more languages.
Here’s a breakdown of what we’ll go through:
- A WordPress plugin for translations
- Human Translations
- Automatic and Semi-Automatic Translations
- WordPress Multisite where a subsite represents a language
- Using a 3’rd party for your translations
- TranslatePress Beta
- The Future of TranslatePress
Unless you’re a real language geek like these guys, setting up WordPress in more languages can be anything between a slight annoyance to a real problem that can stop your project half way.
There are also different reasons why you need to translate WordPress in more languages:
- The website you’re working on is in a country that uses multiple languages like Canada or Switzerland.
- You want to make a German version of your US tour guides for your European tourists.
- Or just want to reach a wider audience or expand/sell in other parts of the world.
WordPress in more languages can be anything between a slight annoyance to a real problem that can stop your project half way
Whatever the reason, WordPress doesn’t offer a simple solution for multilingual sites, each solution having its share of pros and cons.
A WordPress Plugin for Translations
The most common way of translating WordPress in more languages is to install a plugin for automatic or human translations.
This plugin, can be used for free to insert the Google Language Translation tool into your WordPress widget area.
It’s main advantage is that it’s free and has a minimal setup. You don’t have to pay for a translator or even for Google Translate API as the Google Website Translate is a free tool and you can include it in any website even without a plugin.
There is a paid version available with support for better URL’s, metadata translation and the possibility to edit the translations. All good and accessible pricing wise, unfortunately, it’s a Software as a Service, meaning if you stop paying you’ll also lose your translations.
A free plugin that allows automatic translations with the possibility to correct it with human translation where needed.
It was a good attempt, unfortunately, the project seems dead or in deep sleep mode. The plugin hasn’t been updated in over 3 years and while there are support questions often, there are no answers what so ever.
Combining automatic with human translations, it’s a good solution that’s under active development. However, while it is a WordPress plugin, it’s actually a Software as a Service, and while free for small websites (under 2000 words) it also means the translations are not stored locally but on their own servers.
While Weglot is really a better alternative to GTranslate out of the box (the possibility to translate the strings yourself), the 2000 words limit is just to small for anything useful except really small sites (this article alone has 2100+ words).
And since the plugin is more of a wrapper around the Weglot software as a service business (you can enable Weglot on Joomla, Shopify, and basically any website in the world), it lacks behind with where it comes to WordPress specific functionality like slug translations.
If you followed so far, you might have thought, well, it’s not that bad! Sure, there are some cons to each solution, but surely once we go into the Human Translations plugins, things are going to get better right? RIGHT?
Well, to translate WordPress in more languages, you have to translate WordPress. Not a post, not a page, but WordPress. This means:
- content added by plugins, like form labels
- content added by themes, like dates for posts, archive pages, etc.
- custom fields added by various plugins
- shortcodes (or better yet, the content shortcodes output)
- PageBuilders ruin everything with the content inside a post or page being transformed into a tag soup representing both design and content together.
Surely once we go into the Human Translations plugins, things are going to get better right? RIGHT!?
Based on the now-defunct qTranslate plugin this plugin stores all language alternatives in the same post. This means some plugins or themes just won’t work with it, and while you can get it working, there is limited support when things don’t work and that’s more the norm than the exception.
It’s a very popular plugin, however, it’s limited in its reach and the developers are aware of it and try to communicate this as best as possible: “…most convenient for bilingual or few-lingual sites, for example, owners of which perform the translation of content on their own”. So make sure it’s right for you as well.
Free WordPress translation plugins are not always the best choice. A professional project always requires support and updates as well as detailed solutions for even the most obscure issues that appear from time to time.
WPML is a premium plugin and one of the most popular that currently exists in the WordPress ecosystem as far as multi language websites go.
It has an extensive API that 3’rd party plugins and themes can add support for, allowing you to translate everything from options saved in the database to serialized data, to page builder content and WooCommerce products.
This means the translations will always be stored in your database (so you own them) and it’s complex enough for an experienced developer to be able to translate any WordPress site if he or she wants to.
The disadvantage is that it’s complex enough even for an experienced developer to be able to translate any WordPress site if he or she wants to.
If you have a few technical experience to how WordPress works in the backend, your success might vary. And while the WPML team is actively improving the plugin, it’s still a complicated piece of software and depending on your project, more of a developer tool than a simple translation tool.
This is simply because translating your WordPress site in this way really is translating WordPress in it’s entirety, something it was not designed from the get-go, so issues are bound to happen and are complicated to understand.
WordPress Multisite allows you to create multiple sites using the same install of WordPress. Users can be shared (so an administrator can manage all sites), but the content is different for each site.
This can easily allow you to create one website for each of your site’s language. It’s a native core WordPress functionality, free and can even assign different users to create the content for each language.
- extremely useful for true multilingual websites with different content in different sites. You could have different products, pages or structures for your Spanish site than for your French one.
- native support for subdomains, directories or even completely different domains like sitename.ru, sitename.de, etc with Domain Mapping
- A lot more difficult to configure and manage
- each change in the main site needs to also be replicated on the sub-sites, including theme changes, plugin setup, etc.
- some plugins won’t work properly on a multisite install
- managing translation content lacks entirely. You need to go to each site, find the content you want to translate and … write it again, or copy-paste from a window to another?
While there are plugins that make using WordPress Multisite easier to digest, with support for language switcher and linking original posts and their translations together, it’s still hard to recommend Multisite for translating WordPress in more languages. It’s true that you can turn WordPress multilingual without a plugin, but is that really that helpful?
Using a 3’rd party for your translations
Similar to the automatic translation SAAS (Software as a Service) product, there are services for translating any website, not just a WordPress site.
Bablic is such a service, and while easy to use (that is once you get used to it, since it’s nowhere similar to the WordPress UI), it doesn’t create an actual alternative translated version of your website, and while they are advertising SEO friendliness, you don’t own your translations and the moment you stop paying the monthly fee you’re left with your original site language only.
If I was to recommend services like Bablic to someone, it would be to users that are not technical and just want to reach a larger audience regardless of price.
It’s quite complicated. Since WordPress was never designed from the ground up to support multiple languages, each solution comes with its own disadvantages.
And while there are solutions that will work just fine, it’s hard to come with a definitive recommendation.
Democratize Multilingual WordPress – TranslatePress
Wouldn’t it be great to be able to translate your WordPress site with a user interface that wasn’t an afterthought and the functionality looks like it was part of the core?
Where it works out of the box without having to add support to various plugins or themes?
Where the translation is stored locally, on your WordPress site, not on someone’s else server.
That’s why we decided to start our own mission to Democratize Multilingual WordPress.
WordPress in more languages
These are big words for a big project that had to tick a lot of boxes:
- GPL plugin and self-hosted.
- A free version that will allow you to translate all your WordPress site in a second language without limits (like the number of words, themes/plugins compatibility etc. ).
- Translate what you see (including image translation), in an intuitive UI similar to the Customizer. No more messing about with weird and out of context interfaces.
- Full Integration with Google Translate API for initial translation, while the content is still served from the local database once translated once.
- Really fast and cache-able by all WordPress caching plugins.
- SEO friendly, with support for title, slug, metadata and social graphs translations.
- Designed from the ground up to take into account all of WordPress weird quirks and features like slugs, menus, custom post types, Page Builders or Shops.
- Bring proper translation management tools for site owners, developers, agencies, and translators combined.
- Create full multilingual websites without the hassle or cost of available tools.
While these seem like simple to-do’s, they are hard to get right. So we made a 3 step plan and got to work. Today, we’re launching Step 1, with 2 and 3 coming in the next 12 months.
We’re here for the long run and are quite aware that just one feature doesn’t make it work.
Step 1 (Update: This step has been completed)
Create a core plugin that can:
- Translate everything from an interface identical to the WordPress Customizer.
- Full Integration with Google Translate API. Just enter an API key and you’re good to go.
- SEO friendly
- Support for custom post types, page builder, and shops
This is where we’re at 8 months later. You can try TranslatePress for free or check out the demo!
Step 2 (Update: This step has been completed)
Extend what we already have, with future TranslatePress PRO add-ons:
- An SEO Pack Add-on – to make it full SEO friendly and translate alt tags, categories, and social media open graphs tags
- A Multiple Languages Add-on- to add as many languages as you need for your international projects.
- Limit the need to utilize the automatic translation and allow translating strings that are hidden in the database or codebase of other plugins and themes bringing TranslatePress closer to a full multilingual tool.
Step 3 (Update: This step is currently in progress)
A full multilingual tool where you can translate everything without having to be technical:
- Create content in a particular language only.
- Create language specific menus (this is now possible using the Navigation Based on Language add-on)
- Bring tools for site-owner (translation status), developers (clear documentation and powerful API for detecting the user language), agencies (various access levels for their users), translators (access to just the translation interface for selected users).
We’re here to stay
Translating WordPress in more languages doesn’t have to be a project blocker. When proper thought goes into designing a product that’s sympathetic to where WordPress is going and how complex the ecosystem has become in the past years we can have our cake and eat it too.
That’s why we need your help:
- Try out TranslatePress
- Let us know what’s your challenge with Multilingual WordPress
- Discuss within your WordPress community the issues with setting up WordPress in more languages
And while it took the combined effort of our entire team from Cozmoslabs 8 months to get to this point, thanks to your support and feedback to go we’ll manage to go through Steps 2 and 3.
Here’s to fun journey ahead!
4 thoughts on “WordPress in More Languages – Getting Started”
Awesome works from you guys. Quick question, isn’t the translation done from the customizer or you built your own customizer-esque interface for the translation?
I think it’s the latter from what you described but the screenshot makes me want to confirm.
Great work once again and good luck with TranslatePress.
Yes, it’s just a clone of the Customizer interface. Mainly because we wanted a bit more control over the code-base.
Hello guys and thanks for the awesome plugin!
I just have 2 quick questions.
1st it seems that when I go to editing mode for the translation I can see it changing on my website. However if I decide to enter my site (not in edit mode) nothing has been translated even tho in edit mode it’s translated. Do you have any ideas why this is happening?
2nd when I visit my website and click on lets say French it changes the site url to /fr, however if I decide to click English it still stays on /fr.
Please open a ticket on our website so we can look at these issues: https://translatepress.com/support/