Multilingual WordPress with Multisite

There’s a common notion that running a web site in multiple languages is one of the things WordPress isn’t particularly good at by default. Is that still the case? Certainly creating and curating any multilingual web site is a task far from trivial. But besides the inevitable effort of the actual translation of content, multilingual WordPress really isn’t wizardry. WordPress does offer built-in support for content in multiple languages … well, like… almost.

Polyglotism from a European perspective

Other than great parts of North American population, European people communicate in somewhat between 24 and (roughly estimated) 100 languages and idioms. In many places like i.e. the Netherlands and most parts of Scandinavia English is very well understood and spoken in general. Other larger countries like France, Spain or Germany seem to lack default support for the English language on a wider basis, so to speak.

As a consequence, multilingual web site content is a must for many businesses across Europe reaching out to users and customers in their own country as well as across national borders.

Actually, the blog you’re reading right now is a very good example. We could have chosen to publish only in English since our products and content obviously targets WordPress users all around the world; but then we were likely to miss out on a large number of users from our own country who just don’t read in English so well. Publishing bilingual content is the only way for us to make sure we reach readers and potential customers from our local community as well as internationally.


Why a new translation plugin?

When we set out to create a translation plugin for WordPress in 2011, there already were solutions available, of course. So were we going to reinvent the wheel? Not at all, as our aim was to solve common problems the existing plugins at the time were pretty much all dealing with and still are in some cases.

Among those were an increasing complexity in cases of inconsistent behaviours that had to be fixed individually, creating an overhead of maintenance and compatibility problems. For example: If your plugins tweaks user-defined permalink settings and/or standard URLs, there’s a good chance for another plugin coming along at some point that has its own ideas of what to do with a URL in WordPress. Compatibility fix up the road, maintenance and support efforts bound to increase. The longer a plugin like this exists, the more complex it tends to become. We wanted something light and easy.

  • No extra queries
  • Language sites should use a common code base, yet be independently configurable with different widgets, plugins and even themes.
  • Implementing SEO should be a breeze in all languages.
Multilingual Press: Site/language relationships
Multilingual Press: Site/language relationships

Multilingual panel at WordCamp Europe 2013

WordCamp Europe 2013, hosted in the beautiful city of Leiden (Netherlands), offered a perfect opportunity to present a wrap-up of the most popular plugin solutions for multilingual WordPress out there. As no less than three plugin authors had been accepted as speakers, the organisers had appropriately framed the presentations into a moderated panel with Q&A. Multilingual WordPress solutions presented were:

  • WPML, a very popular WordPress plugin and interface for translation services
  • Babble, a rather new plugin focussed on meeting VIP hosting standards
  • Multilingual Press, our own solution based upon the default WordPress Multisite feature

WordCamp Europe 2013 As multilingual WordPress is such a complex field there certainly isn’t anything like the one correct way of doing it. All of the three solutions presented during the panel certainly are valid approaches, each tackling the same issues from a different angle.

We’re very honored having been given the chance to present our approach at the panel and we’d like to thank everybody—organisers, audience and panelists—again for their attention, participation and inspiration. Although we’d love to present a full review of the panel here, we feel like one and a half hour of complex session content and Q&A would probably go far beyond the constraints of a blog post.

In order to learn about WPML and Babble we recommend you watch their very informative presentations once they have been published on (we’ll update this post as soon as they’re available). In this article we’ll continue to wrap up our own solution for you and provide some extra context.

Planning multi-language content

When it comes to publishing web content in multiple languages there are at least two major topics you want to spend some deliberate thinking on before making a decision for any particular technical solution.

  • What needs to be translated?
    Usually, a multilingual website or blog would want to provide a fully localized experience for the user. We’re talking not only post and page content in multiple languages, but also image descriptions, taxonomies, custom fields and custom post types, text strings printed by themes and plugins, and last, but not least, URLs aka permalinks.
  • How is translation going to happen?
    There are multilingual sites curated by a single person (hats off if that’s you!), and there are those translated by teams of authors or via professional services on a per-post basis. Single author sites obviously can rely on a less complex solution i.e. in regards of user rights than sites with a team of translating authors.
Multilingual Press: Choose site language
Multilingual Press: Choose site language

Multiple sites for multiple languages

Whatever new solution you want to create for and with WordPress, it is always a good idea to take a thorough look at what the software can do already in order to avoid redundancy.

Back in 2011 it was us who had taken that thorough look. It turned out we were to experience somewhat of a surprise! At a professional scale, it is very easy to think of multilingual web content as multiple single language sites within a network. Voilá, there’s a default WordPress feature for that: Multisite.

Setting up each language as a single site in a WordPress Multisite network seems to eliminate a whole bunch of challenges at once:

  • URLs just fit. Permalinks are created in a subdir or subdomain scheme. Your choice.
  • Default WordPress features are already translated via default language files.
  • Themes and plugins use their regular language files based upon the locale of the site.
  • No overhead caused by duplication of any fields: maintaining a language stays as hassle-free as maintaining any single WordPress site.
  • Default WordPress user management, extendible on a network and/or per-site basis.
  • Common code base: core, themes and plugins can be updated in one place for all sites/languages.
  • Extendibility: most third-party plugins will work just as good or bad as they would on any WordPress site; no extra compatibility issues to expect because of the multilingual context. At the same time you can activate or deactivate any plugin on a per-language (=per-site) basis—superb for language-related functionality like converting special characters for URLs.
Multilingual Press: Post Edit Screen
Multilingual Press: Post Edit Screen

Multilingual Press for Multisite networks

Obviously, a Multisite approach for a network of multilingual sites could use a couple of extra features:

  • Per-post connection: you want to be able to connect translated content in the frontend, i.e. via language links.
  • Redirecting users in the front-end depending on the language set in their browsers.
  • Common content editor: authors might want to write and translate content on the same edit screen instead of having to navigate to another site within the network first.
  • Editors can pick their favourite back-end language independently of a site’s front-end language.
  • Cloning: starting a new language site by cloning a complete other language can save you a whole lot of time.
  • Nice to have: a dashboard widget showing posts that need translation.

So here’s the basic workflow of Multilingual Press. Most of it is default WordPress, we’ve highlighted those steps where an actual feature of our plugin provides extra functionality:

  1. Create a WordPress Multisite Network. Think of the main site as your default language.
  2. Create any number of language sites within the network.
  3. Plugin feature: interconnect those sites so they “know” of each other as available languages.
    Create any post, page, taxonomy or custom post type content in your main language.
  4. Plugin feature: mark that particular post or page as translated and save it as a draft for another author; or start translating it right away on the same edit screen.
    Publish your default language content.
  5. Plugin feature: publish your translated content whenever it is ready. Or don’t if translation doesn’t make sense for whatever reason.

Multilingual WordPress in a nutshell

Again, there is no such thing as one way of doing it right. Reducing overhead in code and workflows from the very beginning of conception surely will help to provide an enjoyable user experience later on. Building a solution that utilizes WordPress core features wherever possible is our approach to that principle.

Why wait? You can download and use Multilingual Press Free from the plugin directory. Or purchase a Multilingual Press Pro license here at MarketPress if you’d like to have access to extra features and to our dedicated support helpdesk.

In any case, we’d love to hear your feedback! What are your experiences with Multilingual WordPress?

Post Sharing

Author Avatar

Caspar has contributed to customer happiness at MarketPress. When he’s not providing plugin and theme support, he can be found at WordCamps and other community events.

Also Interesting

MultilingualPress PRO Setup - Multilingual Blogs & Projects with WordPress

by Michael Firnkes

The implementation of future-proof and performant multilingual projects is easy with the plugins MultilingualPress Pro and MultilingualPress. We will show ...

Read more

Our Own Experience: WordCamp Europe 2014 - Sofia in Review

by Caspar Hübinger

888 visitors from 52 countries met up at the WordCamp Europe 2014 in Sofia, Bulgaria – a vibrant melting pot of cultures and languages. For three days, w ...

Read more

WordPress Multisite Installation: A blog network in just a few steps

by Michael Firnkes

Multisite is one of the most powerful WordPress tools. It allows you to manage multiple blogs centrally, or to implement multilingual projects. The setup i ...

Read more

Interviews with Caspar Hübinger (@glueckpress) at WordCamp Paris 2014

by Manuel Schmutte

Within the last days we showed some Interviews Caspar did with visitors of the WordCamp Paris. But today we switched the roles: Our allrounder in the Marke ...

Read more



  1. #2

    Thanks for that article! It’s very useful to get a basic understanding of what the plugin does, and what functionalities are handled by the core.

    Now I would love to hear more about the difference in the approaches, since each of those triumvirate of plugins are “tackling the same issues from a different angle”. For instance, since Babble is also using core multisite functionality, what is it doing differently than Multilingual Press?

    Sure, I can just download and test them – but a real test means “setting up a multisite instance with content in multisite languages”, so it’s a very time-consuming undertaking. Luis Godinho has written an interesting report after his testing of WPML, qTranslate, Polylang, Stella, Xili-language “and probably some others”, and concludes “It was a really hard process” (and opted for Stella). I don’t know if Multilingual Press and Babble were part of his testing ground.

    Also, there’s one thing nobody ever mentions: WP multilanguage plugins have a track record of becoming abandonware, leaving their users in a bad situation. Take this time machine and meet Polyglot, the most popular multilanguage solution back in 2008 – it has been shelved since. Other casualties are Language Switcher, Gengo, xLanguage, ZdMultiLang

    So, when will someone write that vendor-neutral, technically detailed, in-depth and opiniated multilanguage plugin shootout that everyone is waiting for, please ? 🙂

  2. #3

    Manuel, thanks for your comment. First of all, having seen Simon’s presentation at WordCamp Europe I do believe both Babble and Multilingual Press can provide an in most regards equally solid foundation for multilingual WordPress sites. Both are build upon core functionality – Babble using a Custom Post Type (if I’m not mistaken) for translations, and Multilingual Press leveraging the flexibility of a multisite installation.

    As mentioned in my post above, Multilingual Press has been developed with a focus on keeping it as close to WordPress core as possible. The same seems to be true for Babble, as it says in their Readme file:

    The plugin was built with an aversion to both additional database tables, additional columns or column changes and a desire to keep additional queries to a minimum.

    So the main difference of the two approaches (aside from UI) may well be the environment each solution has been developed for. As Simon described during his talk in Leiden, from the very beginning they needed Babble to meet the requirements of a VIP account. A requirement like that sort of narrows your set of choices as you’re bound to measure each and every decision against it. (Which I personally think can be a very fruitful process and improve the quality of the end result.)

    Multilingual Press didn’t have to meet the requirements of any particular environment, yet we wanted to create a most solid and future-proof solution from a user perspective. I think while Babble might be a little quicker to be set up, Multilingual Press might have a distinct advantage in sustainability, so to speak: when you decide to turn it of, your content is still there. All of it.

    a real test means “setting up a multisite instance with content in multisite languages”, so it’s a very time-consuming undertaking

    That’s a valid point you’re making. We might consider that for the future and put together a package of test content for Multilingual Press for interested users to just import and play with.

  3. #4

    Very interesting post!

    I also agree there’s no such thing as only one right way of doing it. I appreciated the three presentations at #wceu as I didn’t know Babble and Multilingual Press in depth.

    Both are interesting ways of approach but what I like the most is that both stick to WordPress core features, which in my personal opinion is the right way to go.

    Also interesting the comment about the abandonware. I feel the same about some of the plugins I’ve been using in the past which is very bad! This is why it’s SO important to select plugins that stick to the core.

  4. #7

    If you’re interested in a tool to easily translate WordPress sites, have a look at the online localization platform It’s even got a plug-in you can use with it to integrate its API to your WordPress so that you save more time with the file management process. You can find it here:

  5. #8

    @Selena You’re bringing up a rather common misconception regarding translating files and translating content. There is a very important distinction to be made, so let’s clarify:

    Translating files
    Tools like Poedit (which you can use for free) or (which looks also nice) let you translate text strings in your files. Whenever you see something like

    in a PHP file of a theme or plugin, that’s where you need those tools. Read more about localizing WordPress in the Codex.

    Translating content
    Your content, however, is not stored in files. It is stored in database tables. Tools like the ones mentioned above are useless there. Translating content requires a solution that reads your posts from the database and stores your translations right there. That’s what Multilingual Press does.

    It might be worth mentioning, though, that a fully translated WordPress site needs both, translated files and translated content. So you will want to get yourself familiar with tools like Poedit or plugins like Codestyling Localization as well.

  6. #9

    Hi Caspar,
    I’m very interested to know if/how MP supports (or plans to support, or not) a professional translation process. Specifically – an export of the content (say to XLIFF files), which will then be translated by professional translators (that I select and handle myself), and finally imported back into WP.
    As far as I can find, there’s only one WP plugin that supports that, and it’s not yours… 🙂
    Is this something you’re planning to implement?

  7. #10

    Hi Leon, very good question. At this time, our priority is completing Multilingual Press’s ability to connect all possible types of core features in different languages. APIs for third-party tools are not anything we envision for the near future to focus on.
    WPML—the plugin you’re pointing to, I suppose? ;)— does an excellent job providing those features. Personally, I’d always send users who need a third-party interface and don’t want to invest in a custom solution their way, even though I’d always recommend using Multilingual Press (obviously) regarding performance, future compatibility and general architecture.

  8. #11

    Wow, great post! Thanks for sharing some useful multilingual WordPress tips 🙂

  9. #13

    Hey Caspar,

    thanks a lot for your interesting post.
    I want to use the Multilingual Press, too.
    Therefore I enabled the wordpress multisite function.
    I created a new site using sub-directories. Everything works fine, BUT:
    The changes I have made for my first site’s theme Pinzolo mainly in the css do not show up. Changes i have made in the footer.php do show up. In the super-user admin I have enabled the theme networkwide.

    Do you have an idea what went wrong?

    Thanks a lot


  10. #14

    Hi Caspar,
    if I post articles via XML-RPC currently – how will it work with Multilingual WordPress? Will it be posted for one – the standard – language of the blog? Thanks for clarification 😉

  11. #17

    Hi Caspar,

    First let me know that having read your article and having discovered both multisite / multilingual convinced me to finally stop using WPML.
    (Which is really a nightmare at each theme/plugin update, with a bunch of issues related to media duplication and load time issue.)

    I’ve now activated a multisite on a test environment and I’m doing some tests, before to do it on my live site; but in the meanwhile I’d like to ask you an opinion about SEO.

    On the multisite installation, since it’s old, I’m forced to use subdirectories instead of subfolders; I’m fine with this, since the original and the translated blog will be different in services offered and media used, but at the same time this mean also that sitemaps will be separated, and that under a search engine POV there will be no connection between the two sites.

    Is this correct?

    Is there a way to inform search engines that the content belongs to the same site, in order to increase site authority, quantity of content, etc?

    Thanks for your time,


  12. #18

    Great effort dude keep it up thanks for sharing

4 pingbacks

  1. Managing multilanguage WordPress sites —
  2. Every Day A Post of WordPress Tipps and Tricks until Christmas! | WPress4.ME
  3. Every Day A Post of WordPress Tips and Tricks until Christmas! | WPress4.ME
  4. WordCamp Europe 2013 | Ulrich Pogson

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">