New Royal Academy of Dance Website – Multi-Country Content Management (Part 5)

A major aspect of the Royal Academy of Dance website is that localised versions of content needs to be made available for multiple countries and regions. In some cases, this content is written in different languages.

We therefore needed to come up with a solution to make it easy to manage this content; allowing it to be customised & tailored depending on the country/region/language, whilst also ensuring the solution was implemented in accordance with SEO recommendations – by aiming to avoid significant amounts of duplicate content on the site for example. It was also important for users to be able to easily access content applicable to their location.

In total, we identified no fewer than 18 potential built-in, 3rd-party and/or custom solutions for managing content in multiple countries or languages upon a WordPress website. After eliminating solutions that clearly appeared to be unsuitable, we then carried out an initial investigation of the 7 remaining solutions, followed by a more comprehensive review of the 4 options that looked most promising, including tests of the relevant functionality provided by each solution.

Multisite vs Multilingual Solutions

The previous website used WordPress Multisite to manage content available for each location – essentially there was a completely separate sub-site associated with each country, which was managed mostly independently from the other sub-sites. This approach did have some advantages, but also some challenges and limitations:

Pros of Using WP Multisite for Localised Content

• Multisite capabilities are provided by WordPress out-of-the-box, so therefore do not directly require the usage of 3^rd party and/or custom solution(s) for basic usage of this functionality.
• WP Multisite can provide the ultimate level of flexibility, because almost every aspect of each sub-site can be managed mostly independently from the other sub-sites – even a completely different website theme, a different selection of installed plugins, and/or a different website configuration.
• Despite this additional flexibility, each site is still nevertheless able to take advantage of a shared underlying codebase, as well as the ability to access data and content from other sub-sites if needed – thus assisting with maintainability.
• Each sub-site generally feels relatively self-contained – both for website visitors and for site administrators.
• Admin users can easily be set up with different levels of access to each individual sub-site if required.
• It is possible to reduce, mitigate against and/or avoid some of the downsides of using WP Multisite mentioned below, by utilising a dedicated 3rd-party multilingual plugin solution to support use-cases specifically involving multiple languages and/or countries.

Cons of Using WP Multisite for Localised Content

• Activating WordPress’s multisite capabilities results in a much more complex set-up behind the scenes (both regarding the underlying code and the associated database structure), as well making it more challenging to manage each individual site via the site admin area. This in turn potentially increases the risk of unexpected website bugs.
• Duplicating an entire sub-site (e.g. including all website content & media files) can require a significant amount of server resources behind the scenes.
• Multisite set-ups can potentially result in performance & site loading speed issues in some scenarios, if not approached carefully.
• The usage of WordPress Multisite to build websites is much lower than the usage of WordPress as a whole. Therefore the vendors of 3rd-party plugins are less likely to support WP Multisite well, or test their functionality extensively upon WP Multisite.
• Alternative multilingual solutions still provide the ability to adjust the appearance, layout and content of individual page(s) for a specific country and/or language, and to set up pages for specific countries – so using WP Multisite may be an over-the-top solution.
• Using a multilingual solution instead of a multisite set-up potentially provides more centralised control over branding & overall appearance of each sub-site.
• Due to the underlying way in which WP Multisite works, it can be harder for an individual sub-site to automatically retrieve and/or sync data to or from other sub-sites. While it is not impossible to achieve, this does help to explain why there are fewer existing solutions that are able to do this seamlessly and reliably.
• Using a combined multisite & multilingual solution does not fully resolve all these downsides – and also may not address every use-case.
• Or if a combined multisite & multilingual solution is not used, a plethora of 3^rd-party plugins may be needed to provide similar functionality, which can increase complexity and impact site reliability.

Although in theory WP Multisite can provide many benefits, we found that the additional flexibility that this approach offers was rarely actually utilised in practice upon the previous RAD website – and it often seemed to cause more issues than it solved. We therefore looked into alternative multilingual solutions to achieve similar aims.

Multilingual WordPress Solution Comparison Table

The solutions we explored in depth included WPML, Polylang Pro, and MultilingualPress.

We prepared the following comparison table to illustrate the characteristics of each solution; as well as a summary of the main pros & cons. A 5-star rating meant that we believed the solution has extensive built-in and/or easily implemented capabilities in the relevant area, whereas a 1-star rating meant that we believed the solution had virtually no capabilities in that area and thus a lot of custom implementation work would be needed to overcome this. For comparison purposes, we also included our star-rating for a standard WP Multisite installation (as described in the section above).

	WPML	Polylang Pro	Multilingual-Press	WP Multisite
Support for Required Features:
Ability to create a separate version of a page that is tailored to a specific country and/or language	★★★★	★★★★★	★★★★★	★★★
Ability to create a page that is only available for certain country(s) / language(s) (and not for others)	★★★★	★★★★★	★★★★★	★★★★★
Support for translating/localising content within WP’s Custom Post Types & Taxonomies	★★★★★	★★★★★	★★★★★	★★★
Ability to add & manage translations for text embedded within the site theme, plugins, and other ‘boilerplate’ text.	★★★★	★★★★	★★	★★
Ability to adjust site navigation menus separately for each country/language if needed	★★★★	★★★★★	★★★★★	★★★★★
Ability to send page content & other translatable text to a 3rd party service for automatic machine translation	★★★★	★★★	★★★	★★
Ability to review pending automated translations, and only publish them on the site after they have been approved	★★★★	★★	★★	★★
Support for the WordPress Block Editor, including site-wide configuration (e.g. header & footer) & synced patterns	★★★	★★★★	★★★	★★★★★
A built-in block/control allowing users to switch language/country on the front-end, taking them to the equivalent page (where available).	★★★★★	★★★★	★★★★	★
Geolocation capabilities and/or remembering the user’s chosen language	★★★	★★★	★★★	★★
Access controls to allow local offices to only add/update content for their own country / language	★★★	★★★	★★★★	★★★★
Ability to clone/sync the content of a page for each country / language when a page gets added	★★★★	★★★★	★★★★	★★
Ability to clone/sync the content of a page for each country / language when a page gets updated	★★★★	★★★	★★★★	★★
Ability to automatically clone existing pages, menus etc whenever a new country / language gets created	★★★★	★★	★★★★	★★
Automatically send notifications to local offices whenever new content updates/translations are available to review/approve	★★★★	★★	★★	★★
Supports usage of top-level domains for each country / language	★★★★★	★★★★★	★★★★★	★★★★★
Supports usage of subdomains for each country / language	★★★★★	★★★★★	★★★★★	★★★★★
Supports usage of subdirectories for each country / language	★★★★	★★★★★	★★★★★	★★★★★
SEO capabilities – e.g. hreflang tags, ability to manage page meta-tags for each country / language, ability to customise URL paths for each country / language, etc	★★★★	★★★★	★★★★	★★★
Other Characteristics:
Speed & performance	★★	★★★★★	★★★★	★★★★
Follows standard WordPress conventions	★★	★★★★	★★★★	★★★★★
Lower upfront development & implementation time	★★★★	★★★	★★★	★★
Less ongoing support & maintenance needed	★★★	★★★★	★★★	★★★
Compatibility with other common WP plugins	★★★★	★★★★	★★★★	★★★★
Ease of usage	★★	★★★★	★★	★★★
API to interact with localisation capabilities programmatically	★★★★	★★★★	★★★	★★★★★
Good developer & end-user documentation	★★★★	★★★★	★★★	★★★★★

WPML Pros & Cons

Pros of WPML

• Very widely used.
• Extremely comprehensive functionality, which (in theory) fulfilled the majority of the identified site requirements out-of-the-box.
• Built-in support & integrations for commonly used 3^rd party WP plugins.
• Built-in functionality to automatically send content for automated machine translations, which can then be reviewed & approved by a human prior to publication.
• The ‘Translation Editor’ keeps track of progress and previously translated text from elsewhere on the site, reducing the amount of effort to add new translations.
• The plugin also provides the ability to optionally translate content using the built-in WP Block Editor instead, providing more flexibility to customise page layout & appearance on a country-by-country basis where needed. It is possible to choose to use the ‘Translations Editor’ or the ‘Block Editor’ translations feature on either a site-wide or page-by-page basis.
• The plugin provides bulk translation capabilities, which may be useful e.g. when adding new countries or languages.
• Built-in support for restricting user access to add/edit pages in certain languages only.
• Provides the ability to send email notifications when translations need to be added/updated and/or have been completed.

Cons of WPML

• The plugin is quite complex and unwieldy to use, with various UI & functional inconsistencies depending on the translation methods used. This is at least partly due to the wide range of built-in features; but is also partly because the plugin has evolved significantly over the years, so has quite a bit of legacy ‘baggage’.
• A number of bugs and quirks were identified during testing on a vanilla WP installation. This raised some significant concerns about how robust the plugin would be on a site of this size.
• Tight integration with a cloud-based service provided by WPML – this means that there is a single point of failure; it also reduced our ability to make functionality customisations; and means that ongoing additional costs for services such as automated machine translations may be higher.
• It was unlikely that we would be able to make any fundamental adjustments to the way in which the plugin functions to meet the specific needs of this website – so the vast majority of its built-in capabilities would need to be used ‘as-is’, even in cases where this may be sub-optimal.
• The plugin does not follow standard WordPress conventions very closely – so there is a heavy reliance upon the plugin’s vendor to maintain comprehensive ongoing support for the WordPress core functionality & major 3^rd-party plugins.
• Potential speed & performance issues upon larger websites.
• The built-in ‘Translations Editor’ does not provide any way to preview how the translations will look on the front-end until after the translation is fully complete. It also does not provide the ability to customise or tailor any of the page block settings and/or layouts for a specific country/language.
• By contrast, the optional Block Editor translations functionality does provide these capabilities, but this approach removes the ability to remember previous translations or keep track of translation progress – and it also does not appear to work correctly in all scenarios.
• Overall the WP Block Editor – although supported – seems to be treated as a “second class citizen” by this plugin, even though it is now the default method of managing WordPress sites – and is used heavily on this site. Undoubtedly this aspect may improve over time, but it is unclear exactly when – or if – this will happen.

The Bottom Line

‘On paper’ at least, the WPML plugin ticked many boxes, because it already includes built-in functionality that covered the vast majority of the requirements that were identified for this website. However, in practice during our hand-on testing, we were far less impressed – one might describe the plugin as “the jack of all trades, but the master of none”…

For these reasons, as well as due the size of the new RAD website and the number of people who will potentially need to interact with it in various ways (thus making the consequences more serious if issues arise), we were hesitant to recommend using this plugin for this site.

Polylang Pros & Cons

Pros of Polylang

• Very widely used.
• Straightforward and intuitive UI for adding & updating translations, as well as managing the multi-language/country set-up, etc.
• The plugin is robust and stable, with no bugs or technical issues encountered during our testing on a vanilla WP installation.
• Follows standard WP conventions closely, using a custom WP taxonomy linked to a separate page/post per language/country. This means that there is a lower risk of future compatibility issues and website performance/loading speed issues.
• Because the plugin focuses on providing a solid foundation rather than attempting to solve every use-case, it provides more flexibility to tailor the functionality as needed.
• Rich ecosystem of additional 3^rd-party plugins that integrate with & extend this plugin and provide further multi-lingual/multi-country capabilities.
• Good support for the new WP Block Editor.
• Comprehensive developer and end-user documentation & API.

Cons of Polylang

• The functionality provided by the plugin itself is less fully-featured than WPML, so a combination of additional 3^rd-party plugins and/or custom development work is sometimes needed to fill any identified gaps.
• The built-in support for the WP Block Editor appears to have been added relatively recently. Although it does seem robust(and indeed we felt that the Block Editor support provided by this plugin was superior to the implementation within all the other alternative solutions we tested), it is possible that it may continue to evolve in the future.
• The ‘sub-sites’ for each individual country/language cannot be customised to quite the same extent as a WP Multisite solution. See the section above about WP Multisite for further details.
• The ‘All Languages’ view within the pages admin area may be a little confusing to people who are unfamiliar with the way that the plugin works.

The Bottom Line

Overall we were very impressed by this plugin. Although it does not attempt to implement every possible feature under the sun; its ease of use (both from an end-user perspective and a developer’s perspective), the high level of robustness, and the rich ecosystem of other 3^rd-party plugins that are designed to integrate with and extend its functionality meant that we were confident that this would be a suitable solution for this website, and that it provided a strong foundation that would ultimately meet that RAD’s current & future needs.

MultilingualPress Pros & Cons

Pros of MultilingualPress

• Used for various large multi-lingual & multi-country websites; and endorsed by some influential members of the WP developer community.
• Unlike the other multilingual plugins we reviewed in-depth, this one is built upon the WP Multisite solution. Therefore in theory at least, it can take advantage of all of the advantages of using WP Multisite functionality (e.g. ultimate flexibility over the set-up of each sub-site etc), while avoiding some of the more significant drawbacks.
• Unlike WP Multisite on its own, a clear link between each country/language-specific version of a page is stored. This makes it possible for hreflang tags to work correctly on the front-end (assisting with SEO & reducing the risk of search engines detecting duplicate content issues), as well as making it easier to manage each version of the page in the admin area, and allowing the content of page translations to be optionally replaced if the source page content gets updated.
• The plugin includes built-in functionality to automatically replicate an existing site (including all site content, navigation menus etc) within the current WP multisite installation, which can be useful when adding new sub-sites for countries and/or languages.
• An add-on plugin is available from a separate vendor, providing the ability to also send page content to automatic machine translation service(s) (subject to additional ongoing costs).

Cons of MultilingualPress

• This plugin does not address all of the downsides associated with using WP Multisite (e.g. increased complexity), as described previously.
• The plugin has a rather confusing and non-intuitive user interface for managing the connections between each translated version of a page, as well as the relationships between each sub-site within the overall multisite installation. This makes the functionality harder to work with.
• A major ‘showstopper’ bug caused most of the plugin’s functionality associated with the WP Block Editor not to work at all, preventing us from fully testing this part of the functionality. Although it is possible that this was a temporary issue, it was nevertheless a major concern that such an obvious bug that affects the default configuration of a standard vanilla installation of the current version of WordPress had not been resolved by its vendor at the time. This in turn raised some doubts about how well tested and supported the plugin is.
• No real built-in functionality was provided to manage translatable strings – e.g. ‘boilerplate’ UI text embedded within the frontend site theme. This seems like a surprising omission when comparing the feature-sets of other multilingual plugins.
• The annual price of this plugin for the number of countries/languages that were needed on this site was far higher than the cost of other similar multilingual plugins, and indeed is unusually high for most commercial WP plugins. It is debatable whether this significant price disparity is justified, based on the relatively limited set of features that the plugin provides.

The Bottom Line

Based on our testing, we were unconvinced that the plugin truly addresses all of the potential challenges associated with multisite solutions, and we found it fairly difficult to use in practice. A major showstopper bug prevented us from fully testing all of its functionality – which in turn raised some doubts about how well it is currently being maintained. Moreover, the plugin’s annual cost is much higher than any of the competing solutions that we encountered with similar functionality.

SEO vs User Experience vs Content Management

Overall, based on the above analysis, Polylang was the clear winner – although it did not have the widest out-of-the-box feature-set; its reliability, extensibility and ease of use more than made up for this.

However there was another key factor to consider: The need to balance SEO requirements against the ease of content management, as well as the impact that this may have upon the user experience of frontend visitors:

SEO

We carefully reviewed Google’s guidelines for multi-regional sites, to see how the chosen solution could impact the ability of search engines to index this website. In summary:

• Usage of different URLs for each language version of a page.
• Avoiding the usage of automatically redirects from one version of a page to another, e.g. based on the detected country or language.
• Usage of hyperlinks to other language versions of a page where available.
• Using hreflang tags to identify alternate versions of a page.
• Providing a ‘catch-all’ URL for geographically unspecified version of a language – e.g. falling back to the UK version of a page for English-language content.

Content Management

In an ideal world, it would be best if every country-specific page on the entire website was adjusted to tailor the content to the relevant country/language – thus providing the best user experience, as well as more unique and targeted content for search engines. In practice though, due to the amount of content upon the website, this would require a huge amount of effort.

An alternative approach could be to duplicate less important pages for each country/language exactly, with no modifications to the content at all. This can still result in a significant ongoing maintenance overhead however, due to the need to keep each version of the same page in sync with each other. In our experience, there is also a risk that search engines may flag pages with exactly the same content as duplicates – even in cases where hreflang tags have been implemented correctly – which can negatively impact search engine visibility and/or send users to the ‘wrong’ version of a page.

User Experience

To overcome the above content management challenges, one option could be to leave all pages that are not tailored to a specific country untranslated, and instead direct users to a ‘global’ English-language version of a page. However this in turn causes potential user-experience issues, because if they then subsequently visit another page on the site that is tailored to their country/language, they are then shown the ‘wrong’ version of the page.

Since Google discourages using geolocation to directly redirect users to the ‘correct’ version of the page, it is challenging to work around these user experience issues, while also keeping the website content easy to manage, and simultaneously avoiding the risk of duplicate content issues.

Our Solutions

Ultimately we implemented a solution to try to reconcile these seemingly contradictory goals:

• A different URL is used for each country/language version of a page.
• By default, users are not automatically redirected from one version of the site to another based on their browser language and/or their IP address.
• For English-language content, the default version of a page is normally the UK version – this is used as the ‘catch-all’ URL for geographically unspecified English speakers. [N.B. There may be certain exceptions to this rule, e.g. if the relevant page is only available to US users.]
• Pages intended e.g. for US visitors can include links (e.g. within navigation menus etc) to the main catch-all URLs of other pages in cases where the relevant content is not available for that country/language. This avoids the need to create exact duplicates of every applicable page upon the website, helping to avoid SEO and future content management challenges.
• If a user visits a page and the website detects that another version of that page is available for their country/language, a prominent message bar is displayed at the top of the page. Because this is displayed as a banner rather than a pop-up, users can still continue to view the content on that page without taking further action if desired, and search engines can still crawl the page content successfully.
• Users can select an alternative country/language if desired, or if the website did not detect this correctly.
• If the user then clicks on the ‘Continue’ button, the website remembers their chosen preference.
• After this point, if the user visits a page for a different country/language and the content is also available for their chosen country/language, a prominent pop-up is displayed, which provides a link to access their preferred version of the page. This pop-up can be dismissed, so it is still possible for users (and search engines) to access the content of the page they are currently visiting.
• Links are also provided to access other versions of the page (where available) via the main navigation menu, and via a dropdown in the footer.

For the country/region detection functionality, we used the excellent GeoIP2 PHP API library from MaxMind to build some custom website functionality that integrated with Polylang. A lot of the functionality for the notification message & popup banner was implemented using AJAX and custom JavaScript code, to reduce the risk of server-side caching issues, and to make it easy for the banner/popup content to be dynamically translated into the chosen language, regardless of the language being used on the current page.

Find out more in the final part to our technical series: Implementing the Find a Dance Teacher Functionality »