Tips for Designing and Building a Multilingual Website

Offering content in several languages can add many new layers of complexity to web design. Translating articles is only the first hurdle; structuring a multilingual website can be pretty difficult. To help you get it right, I’m going to offer up some tips, and share some of our experiences at Tuts+ for going multilingual.

1. Get Translated

The first tip isn’t really related to web design, but it’s important nevertheless. When you offer content in several languages, it’s best not to rely on translation software. Don’t get me wrong, tools such as Google Translate are easy to use and constantly improving, but the accuracy of the translated text varies (we’ve even fallen foul of this at Tuts+ on occasion!)

Initiatives such as the Google Translate Community continually refine how translations are made — Initiatives such as the Google Translate Community do refine how translations are made

For this reason it’s a good idea to get a human translator. Either opt for a paid service like Fliplingo, or (depending on your project) use community-driven translation platforms like Native. Humans have a better knowledge of local vocabulary and the subtle nuances of language. At the time of writing, automated software hasn’t reached that point.

At Tuts+ we have our readers to thank for translating our tutorials.

2. Presenting Language Options

A multilingual website is useless without the ability to change languages. Oftentimes you’ll find multilingual websites use a dropdown, placed top-right on the page (for left-to-right content the top left corner is more suitable). You might also find switchers in the footer (the approach that IBM.com choose). Whichever pattern you go for, make sure that the dropdown is easy to see and access.

At Tuts+ we use a select element within the post meta details, plus a list in the sidebar to make sure bases are covered:

If you opt to use a select element, the W3C recommend some helpful guidelines.

Flags

Flags are very often used to indicate a language. However, I agree with Gunnar Bittersmann, in that I’m not a big fan of using flags for language switchers. Consider the following reasons:

Flags represent countries, not languages.
A country can have more than one official language.
A language can be spoken in more than one country.
Visitors might not recognize a flag (because of the icon size) or they might be confused by similar flags.

For example:

httpswwwduolingocom — https://www.duolingo.com

Duolingo defend their use of the Brazilian flag because they teach Brazilian Portuguese. But their variant of Spanish is closer to Latin American Spanish than Castellano (traditional Spanish), so the use of flags here is inconsistent and confusing.

It’s best to refer to a language in its own language, for example ‘Deutsch’ instead of ‘German’. Ordering languages alphabetically will also help, so users can easily find the right version. Take a look at the sidebar of Wikipedia for inspiration.

Redirecting

Certain websites redirect users to the homepage when they switch languages. This can be confusing, because users then have to find the page again. To keep your visitors happy, wherever possible make sure that they’re presented with the same (translated) page when they switch languages.

Detecting Default Lanugage

Want to set a default language for first time visitors? It’s possible to detect the user’s language and automatically show the page in the user’s preferred language. However, don’t hide the other options, in case the user wants to switch.

Read more on Smashing Magazine: Should You Ask The User Or Their Browser?

3. Encoding and Fonts

Your content needs to be readable, so make sure the character encoding in the head of the page is set correctly:

1	<meta charset="utf-8">

From the W3C:

“A Unicode-based encoding such as UTF-8 can support many languages and can accommodate pages and forms in any mixture of those languages.”

Then consider the actual fonts: your web font needs to be compatible with all the languages you support, especially for non-Latin based languages. This means that the font used must contain all the characters and glyphs you commonly need. Some languages comprise hundreds of characters, making the font files themselves very heavy. Consider therefore refining the character groups that you include in the files.

There are several websites that offer non-Latin character based fonts, such as typebank.co.jp, and a quick Google search will help you find more alternatives.

httpswwwtypebankcojp — https://www.typebank.co.jp

There are other typographic considerations too. Don’t forget that certain languages are more “wordy” and therefore take up more space. A button ‘add to cart’ might be translated in Dutch to ‘aan winkelwagen toevoegen’. The English version consists of 11 characters, the Dutch version 25, taking up twice as much space. When space is scarce, you can try a different, less literal translation, or change the font size based on the language.

Other non-Latin fonts may need a different line-height, or character size, to your Latin default. Chinese characters, for example, are visually more complex than Latin characters, meaning they need to be large enough for clear distinction. These factors can vastly alter the appearance of the page, so bear them in mind.

4. Left to Right and Right to Left

Here’s something you may not be aware of: languages don’t have a direction, but the script they’re written in does. For example, Azeri (spoken by the people of Azerbaijan) can be written using Latin or Cyrillic scripts, in which case it’s written LTR (left to right). Alternatively it can be written in Arabic script, in which case it’s written RTL (right to left).

Most languages use scripts which are written and read from left to right, but where that’s not the case it’s helpful to mirror the layout of the whole web page. Yes, the entire layout. Text, images, navigation, sidebars, buttons, dropdowns, scroll bars … should all be mirrored.

Tom Maslen explains how the BBC team uses Sass to help them with bi-directional layouts:

For content, specify the direction of the text via the dir="rtl" attribute. This attribute is supported by all major browsers. Here’s an HTML example:

1	<body dir="rtl">

Or use CSS:

1	.content {
2	direction: rtl; /* Right to Left */
3	}

LTR Within RTL

One gotcha we encountered at Tuts+ was embedding inline code snippets within RTL text (such as in Arabic, Farsi and Hebrew translations). The text reads RTL, but the inline code must remain LTR. In this example, the inline code must always read html, body { width: 100%; }:

After the English original, you can see what happens to the inline code within the second example. Example 3 tries to override that by specifying:

1	.arabic code {
2	direction: ltr;
3	}

but, as you can see, it’s having little to no effect. This is where the unicode-bidi property comes in. Paired with the embed value, this helps us override the browser’s calculated direction for embedded elements. Example 4 demonstrates that this has worked:

1	.arabic code {
2	direction: ltr;
3	unicode-bidi: embed;
4	}

5. URL Structure

There are several ways to structure the URLs of multilingual websites. Each option has advantages and disadvantages.

ccTLD

A country code top-level domain (ccTLD) is linked to a specific country, such as .fr for France and .es for Spain.

ccTLDs are a clear signal for search engines that a website is targeting users in that country. The server location is irrelevant and it’s easy to separate websites. The biggest disadvantages are the availability of domains and the extra costs.

Subdomain + gTLD

Certain domain extensions are not tied to a country or region. The most popular is .com, but there are other frequently-used generic top-level domains, such as .net and .org.

These gTLDs can be used in combination with a subdomain, for example fr.website.com. It’s easy to set up and most search engines understand this type of geotargeting. However, users might not always recognize the language of the content based on the URL.

Subdirectory + gTLD

Subdirectories are subdomains’ counterpart. They are often used to structure content (for example website.com/blog or website.com/tshirts), but can also be used for geotargeting purposes. In this case we use website.com/fr to structure our URLs.

With this technique, everything can be hosted on the same server. Set-up is very easy and you can use Google Search Console to identify the different languages. One disadvantage is that users might not recognize the geotargeting from the URL alone (e.g. is webshop.com/de/ in German or not?)

URL parameters

Finally, there are URL parameters, for example website.com?country=it. URL parameters are not recommended, because they are difficult for search engines to interpret.

Personally, I like to use subdirectories in combination with a gTLD. Subdomains are mostly used to separate out content that is completely different. Because multilingual websites are basically translations of the same content (most of the time), subdirectories are an obvious solution.

You can use the language in the URL, for example:

website.com for the standard US version.
website.com/uk/ for the UK version.
website.com/es/ for Spanish-speaking visitors.

Or combine the language and location:

website.com/en-us/ for English speaking customers in the US.
website.com/en-uk/ for English speaking customers in the UK.
website.com/es-us/ for Spaning speaking customers in the US.

Duplicate Content

To prevent duplicate content issues, it’s best to identify a preferred version for each language/location. We can use a simple HTML link element for this, namely rel="alternate" hreflang="x". Multiple hreflang tags should be used on a page; one that references itself and a link to every alternative.

On a web page, that code might look like this:

1	<link rel="alternate" href="example.com" hreflang="en-uk" />
2	<link rel="alternate" href="example.com/us/" hreflang="en-us" />
3	<link rel="alternate" href="example.com/au/" hreflang="en-au" />

This code tells search engines that example.com is targeting English speakers in the UK. It also says that there are two variations of the same content, namely one for the US and one for Australia.

Other Considerations

When designing multilingual websites, there are several other things to consider, such as:

Dates

Not every country uses the same date format. Sometimes you’ll have to convert dates from the Gregorian calendar to, for example, the Persian calendar.

Ethical Concerns

Countries have differing ethical views. There’s a culture-specific nature of sexuality, humor, symbolism, etc. which is easily overlooked when translating a website. For example: in certain countries it’s perfectly acceptable to show a photo of a gay couple, while other countries might find this offensive.

Captchas

Are you using a captcha on your website? Make sure that it’s in the same language as the page content. As a UK visitor, it’s unlikely you’ll want to solve a Russian captcha.

Because they aren’t difficult enough already..

Phone Numbers

Help your visitors with phone numbers on your website by including the country code. You can find a list of all country codes on this page.

Go Forth and Translate!

There are many more considerations when preparing a website for complete internationalisation, but these pointers should have given you a good basis to work from. Let us know in the comments what other tips you have for multilingual web design, and sign up for the Tuts+ Translation Project newsletter if you’re interested in hearing what we’re up to!