Introduction
As soon as a website is designed, it is essential to ask yourself whether it will be multilingual or whether, on the contrary, its content will be published only in one language. In any case, the main language of the Internet is English. As a web designer, you will often be reminded, to start by creating the site in English. For developers, this is even more the norm. All code is written in English, especially comments, even more so if it is to be published. Writing in another language only makes sense if the site remains in a community restricted to one language region. Even the sites of tourist offices, or restaurants, are often written in English, then translated.
Multisite or single site
A multisite is a type of WordPress installation that allows you to control several sites from a single administration console. This allows you to modify the settings of WordPress on all sites at the same time and to keep a certain consistency. For example, you can create several sites, whose owner is not necessarily the administrator, like a company where each department is independent. The administrator takes care of the WordPress updates and the installation of plugins, which allows to keep a certain coherence of the whole. Another advantage of the multisite is necessarily its hosting. There is only one main domain, and as many sub-domains as there are sites hosted on the domain.
Example of mutisites
Subdomains can be used to create a multilingual site, for example :
- https://fr.fuyens.ch for French.
- https://en.fuyens.ch for English.
They would both be subdomains of fuyens.ch, with its independent WordPress installation.
Example of a single site
The single site, to quote a counter-example, will host only one installation of WordPress, but share several sub-folders. To use the example above, a multilingual single site would have as its domain name :
- https://fuyens.ch/fr for French.
- https://fuyens.ch/en for English.
This is where the difference lies. And again, it is not necessary to specify the folder for the main language.
For clarity and hierarchy of the different pages, it is recommended to display the language folder in the URL of a single-site page.
So, multisite or single site ? A personal opinion would be to create a single site, except in cases where there are many languages to manage (3 or more) and these sites are managed by different people or departments.
Fuyens.ch is a single site.
The various plugins
The question that all designers ask themselves is, of course, the choice of plugin, because, in fact, a plugin must be installed to translate a site. Unless you choose the option of creating a multisite that each manager will translate manually, it is almost essential to go through this option.
The different plugins on the market all offer approximately the same possibilities. As soon as you want to make the navigation interface clear and intuitive, the plugin will not be free. All plugins offer a free version, but it remains limited. With Elementor, the translation plugin falls into the category of pro versions to be purchased. You should think about it as soon as you want to create a multilingual site.
To realize this site, 4 plugins have been tested. Here is an overview with their advantages and disadvantages. This is of course a personal opinion.
| Advantages | Disadvantages | |
|---|---|---|
| WeGlot Pro | ACF and custom type compatible Automatic translation Multisite compatible | $99 / year Limited to 10000 words Limited to one additional language for this price plan No import / export in this price plan |
| Polylang Pro | ACF and custom type compatible Offers a library of PHP functions Slugs and URL translation Only one plugin, two with Elementor No extension in the database Export of theme translations | $99 / year Each post or template is dubbed in the second language Does not use an independent console for translation ACF option pages are not supported Uses a third party plugin for Elementor templates |
| WPML Pro | $29 / year for the basic version $79 / year for the full version Custom type compatible ACF compatible only in the $79 version Slugs and URL translation Uses an intuitive translation console One post for all languages | Many plugins to install Import and export of posts using a third party plugin Database extension No export of theme translations without additional plugin |
| TranslatePress Pro | $79 / year ACF and custom type compatible Uses an intuitive translation console Slugs and URL translation Export of theme translations One post for all languages | Database extension The translation is in the database No export of posts possible Automatic translation only available in the plan $139 / year |
Analysis and plugin’s choice
At the time of the decision to use a product, rather than another, the analysis conducted in this sense has taken into account (the) :
- Price
- Complexity of the installation
- The complexity of use
- The translation of the theme and not only the posts
- Compatibility with Elementor, ACF and custom types
Price
Concerning the price, two pro versions have been tested (Polylang and WPML). The $29 version is to be excluded very quickly, because it is too limited. WeGlot Pro is the first product on the list to be dropped for obvious price reasons. It is especially limited to 10000 words, which is a real psychological barrier.
Installation complexity
For the complexity of the installation, WPML doesn’t score many points. It installs no less than 5 plugins to provide the basic services. Polylang uses only one plugin, but is not compatible with Elementor templates in its basic version. TranslatePress installs only one plugin. On this point, TranslatePress is really the best product.
Use complexity
For use, WPML and TranslatePress both use a very intuitive console that allows you to translate a post directly from the WordPress console. Polylang, on the other hand, requires you to create a copy of the post in the foreign language, which is not necessarily a disadvantage, but rather a guarantee that you want to separate the different objects in the different languages, for greater clarity. WPML and TranslatePress modify the database to include the text of the translations, which Polylang does not do. It uses the basic architecture to store the posts in the different languages. On this point, Polylang scores a point.
Theme translation
The translation of the theme, that is, all the text that constitutes the site is normally written in a translation file external to the posts. It must also be exportable. The standard uses files with a “.po” or “.pot” extension. TranslatePress uses functions to translate the theme, but without the possibility to export the file. WPML allows to translate the theme, but is not compatible with this standard, or at least not in the native version. Polylang offers the standard translation functions and has integrated it in its plugin in the form of a console where all the text of the theme is listed. Moreover, the text is compatible with the “.po” standard and is exportable. This point being relatively important, Polylang remains the best product for this task.
Compatibility with Elementor, ACF and custom type
Polylang is not natively compatible with Elementor. It requires a third party plugin “Polylang connect for Elementor”.
The remaining three products in the selection are all compatible with Elementor. WPML and TranslatePress, which translate the text of any content, also allow the translation of Elementor templates. On this point, it is clear that Polylang was not developed for Elementor, which makes it unusable. His choice was discarded at first, before discovering an external plugin called “Polylang connect for Elementor“, created by David Decker. This plugin, allows to connect Polylang to Elementor and to translate the models. Without this plugin, Polylang simply becomes unusable with Elementor. As far as ACF and custom types are concerned, all three products integrate them very well.
Final choice
For the realization of this site, the choice fell on Polylang. Once the incompatibility with Elementor is removed, it has a huge advantage over other plugins, its library of “pll” functions.
It is very difficult to select the best translation product in the end. All of them have some strong points. Polylang is not the cheapest plugin, but the one with the easiest installation, i.e. two plugins for use with Elementor. TranslatePress is better (only one plugin), but it modifies the structure of the database, which is not a good guarantee of reliability and stability, when you know that WordPress updates its product very regularly. The possibility to translate the theme AND to export the content is really an asset in favor of Polylang. Just imagine for a moment that you want to translate the site into a foreign language. You hire an external person to do the work. You export the theme as a “.po” file and the translator gives you a copy that you can import. The same with the posts.You can export them as “XML” files, translate them, and then import them back. Moreover, as a developer, Polylang offers a real library of functions. This allows you to translate, for example, off-topic content, such as e-mails sent to visitors. This post will go into more detail about these functions called “pll”.
Polylang settings
Once the analysis of the plugin is done and it is installed, it remains to browse its various settings.
URL changes
Below, the recommendations and options retained on fuyens.ch.
- The language is determined by the directory name in the permalinks.
- Uncheck the “Hide language information in default language URL” option.
- Remove “/language/” in permalinks.
- Uncheck “Home page URL contains language code instead of page name or ID”.
In a single-site installation, it is recommended to use different folder names for each language.
In the same way, it is better to display the language folder, even for the default one. The “language” folder has no use here. Moreover, it is written “langage” in French.
Finally, for more clarity, displaying the name of the home page is not a luxury.
Detect the browser language
Although this feature does not work with all browsers, it is enabled by default.
Media
Polylang does not allow to link two different images on a post written in two languages. This would be very convenient.
- The recommendation is for “Automatically duplicate media in any language when a new file is uploaded”.
Even if you don’t use the translation of captions and other image names, they will be available in both languages. Unchecking this option does not allow, for example, to link an attachment to a post written in both languages.
Types de publication personnalisés et taxonomies
Here, you just have to check everything. Polylang supports ACF fields and custom types with this feature.
Synchronization
Here too, you have to check everything. Polylang will synchronize all the fields of a post written in one language. And if the site uses custom fields, it is possible to ignore them in the ACF settings for each field.
Sharing and translation of slugs
These two options are activated by default in the pro version. They allow you to use the same slugs in the name of a page while modifying its description. For example, the slug of the home page will be “home”, but its real name in French will be “page d’accueil” and in English “homepage”.
Creation of a language
Under the language tab, you can add one or more languages and select the default language. There are three different settings for the language in WordPress.
- The main language of the site (Settings – General). This setting allows you to change the main settings according to the country.
- The main language of the user (Users). This setting allows you to choose the display language of the WordPress administration console for a user. This means that it is quite possible to create multiple users, each displaying the WordPress console in their own language.
- The theme’s display language. (Languages – Languages). This Polylang setting allows you to choose the default display language for posts and other messages. At first glance, it should always be “English”, but it will also display in English all plugins that offer translation, such as Elementor.
Creation of a post
Once the post is written, it’s time to translate it. Polylang does not offer a translation console like WPML or TranslatePress, which can translate the post directly. Polylang creates a copy of the post in the other language. This may seem, at first, a bit archaic and complex, but it has the merit of presenting a very clear structure. Each page, post, template will have its own duplicate. Moreover, as mentioned above, it is possible to export a post as an “XML” file. This makes it possible for a third party to translate it, without giving him access to the WordPress administration console.
A small flag will display that the post is translated, which is very clear. Polylang will create a copy of the post and assign it another language. From this new post, all that is left to do is to translate paragraph by paragraph the content into the other language. It is possible to use automatic or semi-manual translators, like the famous “DeepL”.
Synchronization with ACF
Polylang will automatically translate and synchronize all ACF fields, which is not necessarily a good idea. A text field written in English will not be the same in French and vice versa. Fortunately, there is a way to ignore these fields during synchronization. To do this, open the ACF field and select “Ignore” in the options.
The language selector
Polylang displays by default a flag to select a content in a language. This small flag is available under the “Appearance – Menus” tab. Polylang does not use any other way to display its language selector. It is very simple and intuitive.
Below, the settings, as they are set up on Fuyens.ch.
The parameter that hides languages without translation will remove the flag if the post has not been translated.
It is possible to change the appearance of the flag icon with CSS. The object is called “li.lang-item”. It is nothing but a bullet list tag (li) and the “img” or “a” tag to change the flag or the accompanying text respectively.
/* Polylang country flag */
li.lang-item {
display: flex!important;
align-items: center!important;
}
li.lang-item a {
justify-content: left!important;
}
li.lang-item img {
width: 20px!important;
height: 16px!important;
}URL translation
To push the elegance to the smallest corners, it is possible to translate the URLs according to the language displayed.
For example, translate the URL
- https://www.fuyens.ch/fr/informatique/impression-dun-pdf/
with
- https://www.fuyens.ch/en/it/printing-a-pdf/
The language folder will be translated automatically. No need to translate “fr” by “en”.
The same goes for the name of the post. This one is different for each post.
It remains to translate the word “informatique” by “it” and to do this, we will use the “pll” functions provided by Polylang. In this example the filter “pll_the_language_link” allows to modify the translation link published by the language change. Associated with the “pll_translate_string” function, which allows to translate a word or an expression in another language and the PHP function “str_replace”, which allows to replace a word or an expression by another one, it is possible to translate the URLs.
The code is as follows :
// On language switch, translate the URL
function pll_translate_url($url, $slug) {
if (function_exists('pll_translate_string')) {
// Translate Search Slugs
$url = str_replace(array('informatique','it'), pll_translate_string('it', $slug), $url);
}
return $url;
}
add_filter('pll_the_language_link', 'pll_translate_url',10,2);The possibilities are endless. Documentation is available online.
- To find the references to the functions, have a look at
“https://polylang.wordpress.com/documentation/documentation-for-developers/functions-reference/”.
- To find the references to the filters, go to
“https://polylang.wordpress.com/documentation/documentation-for-developers/filter-reference/”.
The final word
Choosing a translation plugin is a difficult choice. You have to consider the pros and cons of each. For this site, the arguments in favor of Polylang were largely the “pll” library, but also the ability to translate SQL queries on the database that are widely used in the search engine. Polylang does not extend the database with new tables. It does not write the translation strings to the database either, but uses the standard “.po” files, which allow to extract them at any time, to modify them with an editor like “PoEdit”, and to import them back into another website.
It is also possible, thanks to the “pll” functions, to translate electronic messages sent to visitors of the site. This is the subject of the next post “Multilingual messages with Polylang”.
