With pressure mounting on more and more brands to grow via international expansion, the demand for and importance of localized websites continues to grow. Countless hours of work will go into the planning, implementation, and localization of content for each language- or region-specific website — there’s simply no getting around that. And when it comes to localizing your website with WordPress there are really only two viable solutions. Importantly, those approaches for localization in WordPress are fundamentally different.
This article will walk through features and advantages for both WordPress localization options, and give you a basic framework to evaluate which solution is best for your company or your client.
WordPress Multilingual Plugin (WPML) is by far the most popular and widely supported project for a multi-language-specific solution. It’s a WordPress plugin that offers a lot of powerful features including:
WordPress multi-site is what it sounds like. It’s a WordPress instance that allows for multiple sites on a single web app.
The fundamental difference between WPML and Multi-site is that WPML is a content-swapping solution. What this means is that the look-and-feel of the site does not change across languages. Meaning the layout of your English, Spanish, German, or any other site would all look the same, other than the content itself.
While WPML will allow for the main body of content to be different with unique imagery and HTML, the foundational elements of a theme will all be the same.
With the WordPress multi-site solution, you are not constrained in the same way. Every language-specific site can be unique, because it’s not drawing from the same style or code as some original or master version. In the extreme, you could have a completely different theme for each language.
Using multi-site and don’t want the slideshow on the homepage for English site to show up in Spain? Nix it. Want to use a different forms plugin that is more geared towards the specific language? Easy.
You start to see that while there’s potentially more overhead with WordPress Multi-site, there is a lot more flexibility.
Part experience, part exaggeration, here are some scenarios that illustrate the different conditions which would influence your decision to use a plugin or multiple sites, and the reasoning.
Your client is an international food brand. They have 5 WordPress sites in different languages. Globally they have teams supporting each site with content, but would like to bring all of their sites together in a single managed environment.
All themes were developed solely for that region with little to no consideration for localization. Each region has distinct needs for branding. Additionally, the catalog of products is different to account for differing tastes by region. Finally, one of the 5 sites is an acquired company running autonomously from the main corporation.
Multi-site is a stronger option in this case.
The core of this scenario focuses on infrastructure and server environment over content and workflow. It assumes that all sites need to be in the same place but remain different entities. Another assumption is that each site brings with it a support staff. Copy writers and developers working on their themes and content in their language with little to no need for translation.
This scenario outlines a large client with enough resources and talent to staff multiple teams in multiple regions. This process could be burdensome for a smaller content team. Effectively this is managing 5 different sites in 5 different languages.
Is multi-site right for me? TLDR; bulleted list edition:
A little something extra
If you have copy writers or admins working across localized sites where they are not comfortable with the default language… as of WP 4.7 users are able to select the language for the admin dashboard when editing their profile.
Your client brings to you a WordPress site made up of solely English content. The client has just started doing business in France and now needs a French version of their site. All of the content and functionality will be the same. They have a small staff and will be contracting translators. There is a guy in accounting who took French in high school and might be able to review the translated content.
Without question, translation management plugins like WPML or Polylang are the right approach for this type of project.
The scenario assumes the client has a single site. Aside from a few adjustments the content will be localized clones based off the original English version. Your client has little to no staff that can assist with the actual localization and will likely rely on a translation services to (hopefully) fully localize content they will enter themselves.
Again, WPML or Polylang create localized versions of posts or pages in WordPress that are linked together. This is the big difference between tackling translation with multi-site vs. plugins.
In this example we assume that the blog post ‘Top 10 trapeze cats in the world and where to buy them’ is exactly the same as the blog post ‘Les 10 meilleurs trapèzes au monde et où les acheter’. In the earlier multi-site example only the US based audience would care about trapeze cats while the French site might not even have a blog.
Are plugins right for me? TLDR; bulleted list edition:
Your client is an international company with three corporate sites. This client would like to bring all three of their WordPress sites together into a single network. Each site is built using the same theme and generally the same plugins. Every site needs to have its contents available in English, Spanish, and Japanese. Oh and their drone-delivered-muffin-startup site needs to be in German as well. (I’ve named it “Mufflr”)
I wanted to throw this last scenario in to illustrate that the two approaches are not mutually exclusive.
In this case your client has three distinct sites and would benefit from multi-site features in WordPress. Additionally each site will consist of localized copies of the origin language’s content and will not be unique in regards to branding. Each site can have a different language set if need be, so that extra German translation for Mufflr is just an additional set of content, and not a new site.
As far as scale and effort, this project will be somewhere in the middle. It will likely come down to one central team large enough to manage the three sites in their various languages.
Still heavy, but as light as possible
In this case having a true separate site for each language (multi-site by itself) causes the network to grow exponentially, and unnecessarily. Here plugin and multi-site meet in the middle.
Why would I need both WordPress Multi-site and WPML? TLDR;
While we won’t get into incredible detail about all the SEO considerations surrounding multi-lingual sites, we’ll touch on a few we deem most important. Warning: this section goes into deeper technical guidance, and may not be suitable for small children or non-technical marketers.
As an alternative, we’ve written more about international SEO strategy in previous posts, and will release an international SEO ebook later this year.
Enough stalling: let’s get nerdy.
There are three tags that should be defined on all localization installs. These tags tell search engines and browsers what language they should expect on the page. And if applicable, what other language(s) this piece of content has been translated into, as well as the corresponding URL.
The main opening html tag should define what language the page is in using the
In WordPress, this will automatically populate via the main settings:
Additionally, we want to define the content-language meta tag inside the
head of the page:
In the above example, the page has defined English as its language.
Next, we want to define a link rel alternate tag for every language-version of this piece of content.
In this example the page also has versions in Spanish (es) and German (de). Each of those pages would further need to define these link rel alternate tags, as well as properly defining their HTML lang and meta content-lang tags as explained above. (Everybody got that?)
The meta content-language and link rel alternate tags are included in the functionality of WPML. It’s one of those nice features that you don’t have to worry about. In a multi-site setup, however, it’ll have to be addressed.
The solution for handling this will more than likely be custom. Something like tapping into a hook of a multi-site relationship plugin or perhaps writing functionality based on Advanced Custom Fields (ACF).
The Portent dev team recently implemented a solution utilizing ACF across a multi-site localization setup, and I can vouch for the effectiveness of this approach. We’ll walk through some of the technical setup and benefits here in hopes that others can use this to make handling localized sites a little more efficient.
In this scenario, we created an ACF field for each alternate language, representing that language’s hreflang URL. So, for example, if we have 3 total localizations in English, Spanish, and German, the English site has 2 ACF fields that represent the Spanish and German hreflang URLs respectively. On the Spanish for example, there are 2 ACF fields that represent the English and German hreflang URLs, and vice versa.
Extremely useful if your client or your business needs to be able to scale up to other languages without a lot of future hands-on developer or SEO practitioner help.
The logic is built out using the following rules:
Our general recommendation here is sub-directory as it’s our belief that there is more link authority from quality content, housed under a singular domain. We’ve also written about the pros and cons of subdomains as far back as 2010. With few exceptions, we consistently encourage our clients to work within a single domain, whether that is for blogs, shops, or localizations.
For more great depth on SEO considerations on multi-lingual sites, you can also check out this article by Search Engine Land.
WordPress offers some solid localization solutions when it’s time to expand internationally. We’ve outlined two that we feel are currently the strongest options, and a few reasons we’d pick one over the other. In the end, much of this still comes down to available resources from initial development to ongoing content support.
As always, we’d love to hear from you in the comments if you’ve tried either of these solutions and want to build on or refine anything we’ve shared.
The post How to Build International Websites With WordPress appeared first on Portent.