Mugo Web main content.

Multi-language sites in eZ Publish: requirements analysis

By: Peter Keung | September 28, 2015 | Business solutions, User experience, and Web solutions

eZ Publish has had multi-language features (also called "internationalization") built into its core for over a decade. If you're considering building a multi-language eZ Publish website from scratch or to add additional languages to a single-language eZ Publish site, there are many technical details to be aware of. However, before you begin, it's important to develop a list of requirements for how end users and editors will use the languages on the site.

Language sites and display rules

You will typically start by listing the languages you'd like to add. If you know your visitor base well, then you probably have a list of languages already. If you don't, you can use your favourite analytics tool(s) to discover the locations and preferred languages of your site visitors.

Supposing that your main site is in English, you might want to add a Spanish site and a Japanese site. Do you have enough content for full Spanish and Japanese sites? If not, will you be creating much smaller sites for the additional languages, or will you maintain the full site structure but "fall back" to English content when there is no translation?

The most common approach is to show the requested language if available and fall back only to a single language, often English. However, you might want to fall back to multiple languages or not fall back to any language at all. Or, you might have a single rule that applies to most of the site but some edge cases where you show all translations or mark some content as "always available" no matter what language it's in.

In defining your additional languages, also consider whether you need localized content in addition to translated content. This is where the term "internationalization" is more appropriate than simply "multi-language" or "multilingual". Are you appealing primarily to Spanish-speaking visitors from Europe, Spanish-speaking visitors from Latin America, or both? Or do you have even more specific targeting per country? Even if you decide that the content is the same for different language locations, you might need to format dates, times, currency values, addresses, and more according to the visitor's location.

Multi-language URLs

eZ Publish will, by default, generate translated URLs for the same piece of content based on the page titles:

Multi-language URLs

You can allow editors to be able to modify the URLs to make them different from the page title, and also remove accents for languages where you don't want accents in the URLs -- in some cases it is not preferable to have fully translated URLs.

You can serve your translated sites at different paths such as /es or /ja, or you can use different subdomains or completely different domains. Most organizations have specific SEO and technical considerations that influence this decision.

Language selection and detection

When a visitor first arrives at your site, the simplest use case is to show them the English website. Then there is a prominent language selector widget so they can switch languages.

Hootsuite in English
Hootsuite in Japanese

You can also force the user to select a language (and potentially a location) as the very first step.

To make a more educated guess on the user's language, you can check their browser language setting in order to pick a default site language. For sites that are very localized, you can look up the user's location using, for example, their IP address. Of course, if users log into the site, you can store their language and location settings so that you can always show them the most appropriate content no matter what device they're using.

Search engine optimization

One important goal when you create a multi-language site is to rank well with search engines. You want search engines to index language-specific content and show your translated results to users around the world. In order to ensure that your different translations of the same content have a positive effect on your site's rankings -- instead of hurting you with duplicate content issues -- you can carefully mark up your HTML with the "canonical" and "alternate" tags, as well as organize your translations in your sites' sitemap(s).

Search engines such as Google have good SEO documentation on internationalizing your site.

Translation and editorial workflows

In order to translate your site, perhaps the most important aspect is how you're going to produce all the internationalized content!

In eZ Publish, there are 3 main elements to internationalize: formatting the date, time, address, and other content; translating content in templates; and translating the editorial content. Both eZ Publish and Symfony have extensive functionality for defining locales and using the correct functions in your code and templates to display translated content. Mugo has also developed some additional helper tools for template string translations.

When it comes to the actual translation workflow, you need to consider who is going to translate your content. Do you have staff in-house or do you need to use a translation agency (or maybe even some crude machine translation)? If you need to use a translation agency, consider whether they are going to have direct access to eZ Publish, or whether you need to set up a batch import and export process. For those who are going to manage the content directly in eZ Publish, you can use its permissions system to limit the different create, edit, delete, and other actions by subtree and language. You can also set up editorial workflows in order for translated content to get the necessary approvals before going live. Lastly, some editorial teams can share a single eZ Publish Administration Interface, while others need fully separate and translated Administration Interfaces.


If you take the time to flesh out your site's multi-language requirements, you can better serve your end users and editors. As with any project, it often starts with asking the right questions about what you want the site to do, before diving into what the system can do and how to do it.