All you need to know about multilingual FSE websites

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 compatible with Full Site Editing. We have extensively tested three of the most popular providers – WPML, Polylang & Weglot – 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. We also know from various customers that they use Greyd.Suite in combination with Weglot very successfully.

Weglot

Weglot is fully compatible with Full Site Editing websites and is one of the easiest solutions to implement if you want to quickly make your site multilingual. This plugin does not require you to translate individual templates, template parts, or blocks within the Site Editor. Instead, the entire translation process is handled automatically.

This approach means you don’t need to worry about missing strings or whether new block-based features are covered, Weglot detects and translates all your content out of the box, including dynamic elements, menus, and even content coming from third-party plugins.

Translations are generated instantly using AI-powered machine translation from providers such as DeepL, Google, and Microsoft. On top of this, Weglot also offers its own AI Language Model feature, which helps refine translations further so they capture your brand’s tone and style. 

You then have full control to refine them directly in the Weglot dashboard, either manually or with the help of professional translators. This ensures a balance between speed and quality while drastically reducing the workload for content editors.

Get Started with Weglot

Adding Weglot to your WordPress FSE site is as simple as:

  1. Create a Weglot account
  2. Install the Weglot plugin on your WordPress site
  3. Choose your original and destination languages
  4. Paste your API key and go live

In just a few clicks, your Full Site Editing website is multilingual, SEO-friendly, and AI-translated, ready to connect with audiences worldwide.

In our tests, we found Weglot particularly convincing in terms of:

  • Ease of use: Adding Weglot to an FSE site takes just a few minutes. You simply create a Weglot account, connect it via API key, choose your languages, and your whole site is instantly available in multiple languages.
  • Translation management: Automatic translations (from DeepL, Google, and Microsoft) are available immediately. You can then refine them manually or work with professional translators, all within Weglot’s dashboard.
  • SEO benefits: Weglot automatically creates SEO-friendly language subdirectories or subdomains, adds hreflang tags, and translates metadata. This ensures your multilingual pages are indexed correctly and can rank in every target market.
  • AI-driven workflow: Combining instant machine translation with Weglot’s AI Language Model for faster, more natural results.
  • Maintenance-free workflow: Any changes made in the WordPress editor are reflected instantly across all language versions without manual intervention.

Conclusion: For anyone who wants to translate a Full Site Editing website quickly, reliably, and without dealing with template limitations or migration issues, Weglot is the most straightforward option. We also know from several Greyd.Suite customers that they use Weglot successfully in combination with Greyd.Suite FSE websites.

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 explain below.

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/patterns. The home template can then be structured like this, for example:

  • Template part “Header”
  • Pattern “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 1: Set up your installation in the network admin with the domain in its primary language.

Backend screenshot of a multisite
Backend screenshot showing a .de Polylang domain

Step 2: Install Polylang and activate it on the installation that requires several domains.

Step 3: Create a file with the name sunrise.php on your computer, it will be uploaded later. You can also directly create the file in the wp-content directory.

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.

Backend screenshot of a multisite set-up
Backend screenshot showing the installation ID

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
PHP
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:

PHP
// 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 if it’s not already there.

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.

PHP
define( 'SUNRISE', 'on' );

Step 10: Now you can set up your languages on your installation under Polylang > Languages.

Backens screenshot Polylang language set-up

Step 11: Assign each domain to its respective language under Polylang > Settings > URL Modifications

URL Modification Settings
Polylang URL Modification Settings
Screenshot

That’s it. With these little extra steps, you can even work with Polylang and FSE on a multi-domain multisite set-up!

WPML

WPML 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 issues 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 not use WPML for our website translations any more.