In this article, we would like to give you some help when it comes to multilingual websites with Full Site Editing.
The fact is that not all multilingual solutions are yet compatible with Full Site Editing. We have extensively tested two of the most popular providers – WPML & Polylang – especially in combination with Greyd.Suite. In the following, we would like to share our experiences, provide guidance and point out known issues.
Of course, we cannot provide a guarantee for third-party tools and cannot make any direct recommendations. However, we can say that we have opted for Polylang for our own full site editing websites and have had very good experiences with it – both functionally and in terms of usability.
WPML
WPML is so far the only major multilingual plugin that is officially fully compatible with the Site Editor and makes both template parts and patterns as well as entire templates translatable.
Since we have mainly worked with WPML ourselves in the past and also have a WPML integration with numerous optimizations in Greyd.Suite, WPML was our first choice.
Before we go into detail, let's summarize in advance: In principle, translating full site editing websites works with WPML. However, we found the translation process to be relatively complicated and confusing. Showstoppers for us were bugs that caused pages or parts of pages to be displayed in the wrong language.
You can find a general guide to translating full site editing pages with WPML here.
You should pay attention to the following details:
- With the Translation Manager, all parts of the corresponding asset (e.g. a template) must be translated. If there are synchronized patterns within this template, it can happen that you accidentally overwrite the pattern with the translated texts and thus have English texts on both language versions, for example.
- The Translation Manager repeatedly displays code snippets as texts for translation. As it is not possible to skip, it is best to simply copy the original "text" into the translation.
- As the entire translation is done in the Translation Manager, it is relatively complicated for a content editor to translate a whole page, as they have to translate template parts (header, footer), content, strings and, if applicable, page templates separately and in different places.
- It has happened to us time and again that an already translated page was suddenly displayed in the wrong language again in whole or in part for no apparent reason.
The above-mentioned bugs and usability issues ultimately led us to translate our websites with Polylang.
Polylang
Polylang is currently only partially compatible with the Site Editor. While patterns and template parts can be translated, templates themselves are not yet translatable. However, there is a simple workaround for this, which we will present in a moment.
Overall, we find the translation with Polylang to be very user-friendly. Unlike WPML, the translation works directly in the WordPress editor. This makes it very easy for the content editor to see where they are in the translation process.
The translation of template parts and patterns works in the same way as on pages.
You can find general instructions here.
If you would now like to translate templates, you can simply do the following: Place all the content of your template in template parts. The home template can then be structured like this, for example:
- Template part "Header"
- Template part "Home content"
- Template part "Footer"
Migrating existing pages from WPML to Polylang
If, like us, you have previously translated your pages with WPML and now want to switch to Polylang for full site editing, there is a converter plugin that works very well in our experience.
You can find general instructions in the plugin description.
We are happy to list a few minor issues that we noticed during the migration of our own pages:
- In a few cases, there was no link between the content, e.g. there was an English and German article, but the link between the two was missing. This also occurred with taxonomies. We have corrected this manually.
- When using taxonomies (categories or keywords), it was observed somewhat more frequently that some posts were assigned to the English taxonomy instead of the German one. In this case, we had to manually delete the taxonomy and add a new one.
- When using patterns, especially synchronized patterns, it happened that the English pattern was linked in the German post / template / template part, for example. If the list view only shows "Pattern" for the pattern and not the actual name of the pattern, this indicates an incorrect assignment. In this case, it helps to insert the pattern again and remove the old one so that the correct language is used for the pattern.
- For templates that contain dynamic tags, these can only be added in the original language. It is therefore advisable to complete the template part in the original version and only translate it once all dynamic tags are present. They cannot be adapted in the template part translation, as the assignment to the actual post is missing. The assignment is still present and the dynamic tags are also displayed correctly in the frontend.
- For links in the content, it should be checked whether the rewriting has taken place correctly, e.g. whether the /en/ is present in the subdirectory.
- Media files might be duplicated or multiplied by the number of languages.
Note: As this plugin, like the translation tools themselves, is third-party software, we cannot guarantee that the above-mentioned known issues are complete. We would also like to point out that the websites we converted were websites that already had some issues before their migration, which may well be the cause of the issues listed.
All in all, we were pleasantly surprised at how well the migration from WPML to Polylang worked.
Special case: Multi-domain multisite set-up with Polylang
Polylang works without problems on multisites. With some extra steps, it also works in a multi-domain set-up:
- Step one: Set up your multisite installation
Set up your installation in the network admin with the domain in its primary language.
- Step 2: Install Polylang and activate it on the installation that requires several domains.
- Step 3: Create a file with the name "sunrise.php".
- Step 4: Copy the code of this link into that file.
- Step 5: Go to your network admin to "websites" and hover over the domain to find out the ID of the installation to which the additional domain should link.
- Step 6: Create an entry for each additional domain with the domain and site ID like in the following example:
Domain: poly-multi2b.greydsuite.de
Site ID: 2
cybo_add_extra_domain( 'poly-multi2b.greydsuite.de‘,2 );
- Step 7: Add this row(s) now to your sunrise.php after the following code block:
// Configure your additional domains here. Some examples:
//cybo_add_extra_domain('additional-domain-1.com', 123 );
//cybo_add_extra_domain('additional-domain-2.com', 123 );
//cybo_add_extra_domain('other-blog-extra-domain.com', 555 );
cybo_add_extra_domain('poly-multi2b.greydsuite.de‘,2 );
- Step 8: Now upload the sunrise.php to your wp-content directory.
- Step 9: Open the wp-config.php in the root directory of your WordPress and add the following code before the row /* That's all, stop editing! Happy publishing. */ and save the file.
define('SUNRISE', 'on');
- Step 10: Now you can set up your languages on your installation under Polylang > Languages.
- Step 11: Assign each domain to its respective language under Polylang > Settings > URL Modifications
That`s it. With these little extra steps, you can even work with Polylang and FSE on a multi-domain multisite set-up!
We have prepared a sunrise.php file for you to use – you only need to edit the domains: Download it here.