Foto von Compagnons auf UnsplashThere are many reasons that you might want your website available in more than one language. Your company may cater to international clients. You may have offices in more than one country. Or you may want to widen your company’s reach, showing prospective clients that they needn’t speak your primary language in order to hire you.
Whatever the reason, offering your content in more languages is one of the most effective ways to do so. People buy from, partner with, and apply to organisations that they understand. An English version of your website reaches customers, partners, and applicants who would leave a homepage that is exclusively available in German.
Our own website proves the point. The website was originally available only in German and, consequently, we acquired clients mostly from Austria and Germany. A few years ago, we translated all of our content into English and the website is now available in both languages. As a result, we have been approached by prospective clients who would never have contacted us otherwise, and a few of them have indeed become clients.
Multilingual solutions
A second language is not a feature that you just switch on. It is a second body of content that someone has to write, translate, review and keep current. A German page updated last week next to an English page from two years ago does potentially more harm than no English page at all, as it suggests international visitors are an afterthought.
So if you make the decision that your website should be available in more than one language, be sure that you will be able to maintain all of this extra content. You might say that you could rely on automated translations or even artificial intelligence of some sort, but in our experience each language needs a human translator to at least correct and fix the translations.
In any event, once you’ve decided that you need to add more than one language to your website, there are a few different solutions. If you already use a content management system, you will most likely want to use something native to your chosen CMS. If you are starting a new website from scratch, you can pick the CMS that is going to create the fewest headaches.
In this article, I will discuss three content management systems and how they implement multilingual features. They are WordPress, ProcessWire, and, last but not least, Statamic. By the end of the article, you should have a good idea of the kind of options that are available.
Inelegant by design: multilingual support in WordPress
WordPress doesn’t support multiple languages out of the box. WordPress got started as simple blogging software. It stands to reason that a personal blog would be written in one language; translating your content yourself and maintaining it as well would simply be too much work. Over time, of course, WordPress has transformed into a large content management system used for more than simple blogs, but its core has remained remarkably stable.
For years now, the WordPress project has had multilingual support on its roadmap, but it has very clearly not been a top priority. Anyone familiar with the data structure of WordPress’s tables also knows that the team have a pretty daunting task ahead of them. The WooCommerce team, i.e. the developers responsible for WordPress’s premier shop plugin, eventually gave up wrestling with the system’s existing table structures and added entirely new tables to the database to solve the problems they faced when confronted with WordPress’s aging core.
In the meantime, plugins have emerged that add multilingual features to WordPress. The two largest are WPML (WordPress Multilingual) and Polylang.
A closer look at WPML and Polylang
WPML is the older and more comprehensive of the two. It is a commercial plugin, so you pay a yearly licence fee, but in return you get a complete toolkit: translation of posts, pages, menus, widgets and theme strings, a translation management dashboard for coordinating human translators, and optional connections to professional translation services. It also works well with WooCommerce through a dedicated add-on, which matters if you run a shop.
The downside of all this functionality is weight. WPML adds its own tables to the database and a fair amount of processing to every page load, and on larger sites you will notice it in the backend.
Polylang takes a leaner approach. The core plugin is free, and it links translations together using WordPress’s own taxonomy system rather than bolting on a separate structure, which keeps it closer to how WordPress already works.
For a typical company website with pages, posts and a menu or two, the free version is often all you need. Features such as translatable URL slugs, content duplication and WooCommerce support require the paid Pro version or separate add-ons, so the price gap between the two plugins narrows once your requirements grow.
Both plugins share a fundamental limitation, and it is one that stems from WordPress itself rather than from the plugins: every translation is stored as a separate post that is merely linked to the original. Your German and English “About us” pages are, as far as WordPress is concerned, two independent pages.
This works, but it means that shared elements such as images, custom fields or page builder layouts often have to be set up or synchronised for each language separately, and it is easy for the versions to drift apart. In our experience, both plugins do their job reliably, but neither can fully hide the fact that multilingual content was never part of WordPress’s original design.
Other WordPress solutions
Relatively recently, the Enfold theme, which can be used as the basis for a custom design for a WordPress website, released an update that folded multilingual support directly into the theme. If you rely on Enfold, this is a quick way to add more languages to your website without relying on third-party plugins. Enfold is a mature, well-maintained theme, so it offers a good alternative to relying on plugins.
Anyone who wants a more or less native WordPress solution has another option: you could make use of the CMS’s multisite feature. This allows you to host multiple sites from a single backend, sharing themes and plugins between them while keeping content separate. This is a workable solution if you want to create websites for different countries and languages where content drift is not an issue.
Simple and easy: multilingual support in ProcessWire
ProcessWire is a mature content management system that is of particular interest to more technically inclined users who don’t mind tinkering with the system. We wrote more about it in an earlier blog post. There are no ready-made themes for this CMS, so every website is built from scratch, but if you want a lean, custom website with excellent multilingual support, ProcessWire has you covered.
Our internal code snippet library runs on ProcessWire. Unlike WordPress, ProcessWire ships its language support with the core, in the form of a handful of modules that you simply activate. Once you’ve added your languages, you decide which fields should be translatable by giving them a multilingual field type. Those fields then gain a tab per language in the editor, so the German and English versions of a text sit side by side on the same page.
Page URLs get prefixes for each language, which you define when you add the language in the site’s settings. For example, English pages can have the prefix /en/ in the URL, and German ones get /de/. You can customize this as you see fit, and the default language typically has no prefix at all. ProcessWire doesn’t handle language switchers out of the box, but the documentation has examples you can easily slot into e.g. your main navigation or the footer.
This is where ProcessWire differs most from the WordPress plugins described above. A translated page is not a separate page linked to the original; it is one and the same page with content in several languages. Fields that don’t need translating, such as images, dates or references to other pages, are entered once and apply to every language. There is simply nothing to keep in sync, which removes one of the biggest sources of content drift.
ProcessWire also handles gaps sensibly. If a field is empty in one language, it falls back to the default language, so a missing translation shows the original text rather than a blank space. This is a feature, not a bug: a visitor sees a German paragraph on an otherwise English page instead of a hole in the layout. If you’d rather not show untranslated content at all, you can deactivate a page for individual languages. A page without an English translation is then simply not available in English, and it won’t turn up in navigation or search results for that language.
Flexible structures: multilingual support in Statamic
If good developer support, user-friendliness, speed and reliability are important to you, the best content management system to pick is Statamic. It is built on Laravel, one of the most popular PHP frameworks, which means developers can extend it with the same tools they already use for custom applications.
Statamic handles languages natively through its multisite feature. I should note that multisite is part of the Statamic Pro licence rather than the free version, but the licence is quite affordable, particularly compared with the time you would otherwise spend maintaining plugins.
Statamic’s multisite shouldn’t be confused with WordPress’s multisite solution. In WordPress, the sites in a network are largely independent of one another and their content has no real relationship. In a Statamic installation, the sites are much more tightly coupled. Each language is its own site with its own URL prefix, similar to ProcessWire, or even its own domain if you prefer. Every entry has a localisation for each language that remains linked to the original. The German version of a page knows it is a translation of the English one, and Statamic keeps track of that relationship for you.
What makes this work for teams is control at field level. When a new German localisation is created, it starts out synced to the English original: every field shows the original content until an editor changes it. Once a field has been edited, it is treated as a translation and no longer follows the original. Fields that must never differ between languages, such as a shop’s coordinates or a news item’s publication date, can be marked as non-localisable, which means they are entered once in the original and cannot be changed in the translations.
These settings live in the blueprints that define each content type, so a developer can set them up once and editors never have to think about them. You can also configure whether new entries automatically appear in every language or only once someone creates a translation, which is useful if not all of your content needs translating.
Permissions can be set per language, too. A German-language editor can be given access to the German site only, while an English copywriter works exclusively on the English one. For companies that work with external translators, this is a considerable advantage, as nobody can accidentally overwrite content in a language they aren’t responsible for.
In short, Statamic combines the structural separation of WordPress’s multisite feature with the tightly integrated, field-level approach of ProcessWire, and adds the kind of editorial controls that larger teams need.
Choosing the right setup for your multilingual website
There is no single best system for a multilingual website, only the one that best fits your content, your team and your plans.
If you already run a WordPress site with a manageable amount of content in two languages, there is little reason to switch. WPML or Polylang will do the job reliably, as long as you accept that every translation is a separate page and plan your workflow accordingly.
If you are starting from scratch and want a lean, custom website where each page holds all of its languages in one place, ProcessWire deserves a closer look. It suits teams who don’t mind a little technical work and who value a straightforward editing experience.
If you expect your website to grow, whether in languages, editors or complexity, Statamic offers the most room to manoeuvre. Field-level control, per-language permissions and a solid Laravel foundation make it particularly well suited to teams where several people, or external translators, share the work.
Whichever system you choose, the most important question isn’t a technical one: who looks after the second language once the site is live? And the third, and the fourth? Every language you add is another body of content that has to be written, reviewed and kept current. The right CMS can make that work much easier, but it can’t do it for you.
Planning a multilingual website, or adding a language to an existing one? Whether you need the right translation plugin for WordPress or a custom build on ProcessWire or Statamic, we’re happy to talk it through. Get in touch.
