February 13, 2019

How to Build a Multilingual Website? Here Are the First Steps [Complete Guide]

So you want to build a multilingual website in order to reach a larger number of customers. You may be tempted to think, “First things first. I’ll just prepare the English site and then translate it later.”

But that’s the wrong mindset. It’s a mistake that may cost you later on.

The first step of how to build a multilingual website is not to just create the English version. The first thing to do is to plan how you will localize your website into other languages after your English site is live.

So in this article we describe the most important first steps of localization for which you need to plan ahead before you start developing your English language site.

Since it’s a hefty 3,700 word article, we’ll list the main sections here so that you can click to the section you want to read first.

• Choose a Global Ready CMS
• Design Pages to Look Good in Other Languages
• Decide on Your URL Structure
• Decide How to Manage Your Translation Projects
• Decide What Level of Localization You Will Have on Your Site
• Other Details to Consider

Choose a Global Ready CMS

A CMS (Content Management System) is a system that allows people without web development expertise to manage a website. It allows them to write blogs, add images, edit text, add pages, delete pages, and so on—all without knowing HTML, CSS, PHP, SQL, or any of those other acronyms.

Some examples of common CMSs include WordPress, Joomla, Drupal, Magento, and Shopify

Your company will already have its own criteria that will determine what CMS to choose. If you plan to translate your website, here are a few more criteria to watch out for.

First, Is it able to support different languages? This includes both the aspect of character encoding as well as reversed language direction.

Character encoding is the system that renders characters on your computer screen. If you do not have the right encoding system, the characters will look like little boxes or maybe what my grade school teacher would call, “gobbledygook.”

A multilingual website should almost always be encoded in UTF-8 so that it will display not only in the English, but also French, Greek, Russian, Japanese, Arabic, and so on.

Regarding reversed language direction, some languages, such as Arabic and Hebrew, are written from right to left (RTL) rather than left to right (LTR). If your company is likely to serve customers in the Middle East, it’s vital that your CMS is able to make the switch from LTR to RTL.

Second, is the CMS able to handle multiple versions in different languages? You may decide to host different languages as separate websites altogether or you may decide to have them all hosted on the same domain. (More on that later.) So the question is, will your CMS be able to handle the configuration you choose?

Third, is the CMS able to integrate with your translation company’s translation management system (TMS)?

To ensure that it can, go ahead and speak to a few language service providers (LSP) to get their recommendation of what CMS would work best with their systems. You don’t necessarily need to sign a contract at this stage, but you can certainly get expert advice for free from translation project managers who have overseen numerous projects like yours before.

So in summary, before you start development of your English site, you need to choose a CMS that will support other languages, allow you to have the website structure that you choose, and integrate with your LSP’s tools.

IVANNOVATION is happy to provide website translation consulting for companies with questions about multilingual CMSs.

For more information about connecting a CMS and TMS, see the section below about managing translation projects.

Go back to top.

Design Pages to Look Good in Other Languages

You want your website to look great for every customer, but you may not be able to afford to take the time to redesign the website for every language.

That’s why considering localization is vital during the initial design stage.

There are a few things you should keep in mind when designing the English version to ensure having attractive foreign language versions later.

Text Direction

First, is text direction. As mentioned above, some languages (such as Arabic, Hebrew, Uyghur, Aramaic, Kurdish, Persian, Urdu, Azeri, and Maldivian) are known as RTL languages, written from the right to the left, whereas English and most other languages are known as LTR languages.

An English user experiences your page with the top left as the cornerstone. Think about it; every site you open has the most important information—the name of the company and logo—at the top left. When you open a Google Document, where is the name of the document? That’s right, the top left.

However, a Hebrew user will look on the top right corner of the page to find the most important information. Don’t let it be blank!

That means that your entire website should be flipped around backwards to accommodate RTL languages.

When your designers pitch their designs, keep in mind that they will be in reverse for some languages; ask yourself if they will still look good that way.

Also keep in mind that photographs also may need to be replaced so that they still look good on an RTL page. If the English version has a picture of a boy pointing to an object on one side of the page, in the Arabic version he may be pointing off into space.

Test the site with the RTL configuration early on using a pseudo-translation just to make sure that it works.

Language Line Length

Second, remember that different languages take up different amounts of space both horizontally and vertically. Design your webpage so that you can add or subtract the number of characters in each text string and it will still look good.

Two places that are especially prone to problems are buttons and text with icons.

Sometimes a button will have a short text like “Go.” But when the word is translated into a language with a longer word, the word will get cut off in the middle or the button may look awkwardly large.

Regarding icons, sometimes designers are tempted to put several icons across the screen with text below not realizing that when a longer language is substituted, the words will run into each other.

To learn more about the lengths of text in different languages, see our article called Varying Line Lengths of Different Languages vs User Interface [Infographic].

Words and Images

Third, if you include words on an image, they will need to be translated as well. But if the word is actually part of the image, it cannot be translated without replacing the entire image.

There are three ways to deal with words and images:

1) Have text in the image

• Pro: It’s easy to do on the English version.
• Con: It’s impossible to translate. You have to redo or Photoshop the image for every language. That takes time.

2)  Make the words as a text layer on the original Photoshop file, translate that layer, and export a version for each language

• Pro: This is a better solution since the underlying image can be recycled for each language.
• Con: You must deal with every image file to replace the text layer with a translated text layer. Nevertheless, this is better than having to replace an entire image.

3) Have the text as a text overlay built in the HTML

• Pro: From a localization perspective, this is the best solution since all of the HTML text is easily imported into the translation tools along with all of the other site’s text. Then it’s exported back to the website. There are no extra steps to the process.
• Con: It may be be more work initially and it may be less predictable how it will appear on the end user’s screen. Nevertheless, this is the most efficient solution from a localization perspective.

Our recommendation is:

• If it’s a picture with words that don’t communicate anything important to your customer, like perhaps words on a boy’s T-shirt, just leave it as it is and don’t translate it.
• If it has text in very specific locations, such as in a complicated diagram with labels and arrows, add the text in a layer over the image in the Photoshop file.
• If you have some simple text over an image that you want the customer to read, put the text in HTML.

Discuss this with your translation provider during the design stage so that you can save the most time over the long haul.

Go back to top.

Decide on Your URL Structure

Consider what the URL will look like for the various languages. There are four options that you can choose from. You can choose to organize the languages by subdomains, subdirectories, top level domains, or completely different domains.

Below are examples that show either the English version (EN) or Chinese Simplified version (CN) and have the language indication in red.

• A subdomain, eg: https://cn.getresponse.com/ vs https://getresponse.com
• A subdirectory, eg: https://www.bbc.com/zhongwen/simp vs. https://www.bbc.com or https://www.skype.com/zh-Hans/ vs https://www.skype.com
• A top level domain, eg: http://www.google.cn/ vs. http://www.google.com
• A completely different domain, eg: https://cfmotousa.com/ vs. http://www.cfmoto.com/

You may even decide to use different methods for different languages, but be aware that this mixed approach may be confusing to your customers.

Take GetResponse for example. If you were a Chinese user visiting Japan who opened https://www.getresponse.jp, you may the replace the “.jp” in the address bar with “.cn” to go to your own language. But unfortunately, http://getresponse.cn would send you to the wrong website.

All of the options above have different pros and cons from psychological, legal, and technical perspectives. These factors need to be carefully considered before choosing one scheme. It’s best to consider this question at the beginning of the site design process so that the URL structure fits in with the company’s overall strategy and design.

Besides, you don’t want someone to see your English site and then quickly buy up the domains they think you will want for the other languages in hopes of selling them to you later (which may have happened in the case of http://getresponse.cn/).

We’ll be publishing an article that treats the question of URL structure more fully in the near future. So if you want to be alerted when it comes out, sign up for our newsletter by requesting it on our contact us page.

Go back to top.

Decide How to Manage Your Translation Projects

In the old days you sent your text to your translation provider, they translated it, and then they sent the translated text back to you. Nowadays you can still do that, but there are also much more convenient workflows for website translation.

Three common workflows are the file transfer method, the CMS to TMS connection method, and the translation proxy method.

The File Transfer Method

The file transfer method is the old timey, time consuming method that you probably don’t want to have to use. For this method you send the text that you want to translate, usually in a CSV, Excel, or HTML file to your translation provider. The translation provider translates it and then emails the translations back to you.

Some companies may use this method if their website CMS cannot connect to the translation providers’ TMS software. But as mentioned in the section about choosing the right CMS, ability to connect to translation providers’ software should be a CMS selection criterion.

The file transfer method has a number of drawbacks.

• First, it’s manual, leading to hours of busywork.
• Second, if you can’t easily export and import your text from and into your CMS, you will have to copy and paste all of the text from your site into Word documents or Excel sheets by yourself. This involves a major risk of human error.
• Third, if the original site has any change, the content will once again need to be manually exported, sent to the LSP, translated, sent back, and uploaded to the site. Updating content can be a logistical nightmare.

If you can avoid it, the file transfer method is probably not the best for you.

CMS Integration

This is a connection between your CMS and your translation company’s translation management systems (TMS).

The CMS integration connects to the TMS via APIs. It provides an interface for content managers to select text and send it to the TMS for translation. When the content has been translated, the LSP can send it back through the same system.

But don’t think of an API as a magic wand. The fact that a system has an API doesn’t mean the two systems will actually work together well. The only way to be sure whether the system integrates seamlessly is by speaking with the people who have done CMS and TMS integrations before. Get their recommendations on the best systems.

IVANNOVATION partners with the WPML WordPress plugin to connect sites to our TMS. We have found that this results in a convenient translation workflow.

Translation proxy

Translation proxy is an interesting alternative. It has great strengths as well as some major limitations.

Basically the proxy server stands between your website and your foreign language users. It acts almost like an overlay over your website. If foreign language customers request their native tongue, the translation proxy will still show them your website, but with the English content switched out for the other language.

The translation proxy works by pulling the text from your source site into the proxy server. There the content can be translated and then served back to users.

It will also monitor for changes on your website and instantly send them to translators. A translation proxy’s UI allows the translators to edit the text directly in the context of the web page WYSIWYG style.

There are a few reasons that make translation proxy a powerful solution:

• First, it minimizes file transfer time. It’s fast. That’s great for companies that frequently update their sites.
• Second, it’s also great for companies that do not have a multilingual CMS since the language change is handled by the translation proxy rather than by the CMS.
• Finally, it’s great because the customer doesn’t need to deal with the IT burden of managing a multilingual site. From an IT perspective, this method is extremely easy.

Unfortunately the translation proxy method also has major limitations.

Since the users are looking at your original site with the source language replaced with target language, you can’t really serve up customized content for each region. Any change on your site gets propagated to your foreign language sites as well. The foreign language sites are like mirrors of your original site.

If you want flexibility to offer translated content on your site as well as original content, translation proxy may not be the method for you.

Since there are so many options, talk to LSPs early on in your website design process about the best way to connect your site to their systems. They will have the experience necessary to advise you on the most efficient method for your situation.

However, try to avoid letting an LSP sell you on a technology solution that will lock you into using only a single LSP.

Unless you have the power to tell your LSP that you will find another translation service, the company can give you poor service and high prices. They know there’s nothing you can do.

But, on the other hand, when the technologies you use allow you to switch to another LSP, you have much more negotiating power.

---

Get the Free Tool! Get your own copy of our Translation Project Q&A Spreadsheet Template to improve translation quality and efficiency.

---

Go back to top.

Decide What Level of Localization You Will Have on Your Site

Do you need to translate all of your content? Or do you just want a bare-bones foreign language website?

Do you want to use transcreation? Or translation? Do you want to use human translation? Or machine translation?

These are important questions because they will help you determine what kind of URL structure you will use as well as how to manage your translation workflow. (See previous sections.)

Some companies translate everything on their English site into another language.

But other companies decide that only some content should be translated. They may choose what to translate based on their traffic analytics or based on the company’s strategy for each market.

Beyond deciding what to translate, companies also need to decide how to translate. They may choose to translate, to transcreate, or use machine translation.

Many companies use a combination of all three types based on the type of content.

Here are the three options along an explanation and a typical use scenario:

Translation:

• Translation is when a linguist translates a message from one language to another, remaining as faithful as possible to the meaning of the original.
• Translation can be used for any kind of important customer-facing materials. The high quality of the language used will promote the company’s strong image.

Transcreation:

• Transcreation is when linguists adapt a message to communicate the same tone and intent as the original, but they may take liberty to not follow the original text exactly. A good illustration is when the name of the American movie “The Expendables” was named “The Team That Dares to Die” in Chinese.
• Transcreation is typically used for marketing materials. Perhaps the English version’s imagery or humor would be ineffective in a foreign culture, so they transcreate.

Machine translation:

• Machine translation is translation done by a computer system such as Google Translate.
• Sometimes companies have text that would be useful to the foreign customer, such as support documentation. However, because of the sheer volume of the content, translating with human translators would be cost prohibitive. That’s when they may use machine translation. It’s not an ideal solution because the language is awkward and inaccurate at times, but at least it’s better than having no foreign language resources at all.

Go back to top.

Other Details to Consider

Besides the major issues mentioned above, there are also many other important details about website localization that must be considered before even starting to develop the English language site.

Name Handling:

In some some languages, such as Japanese, the family name comes first and then the given name. The order of their “first” and “last” names are switched. If your website has forms for your customers to fill out, does it have the capability to render the names in the way a Japanese customer expects?

Dates:

The USA, the Philippines, and a couple other countries list dates as month-day-year (called middle-endian by geeks). However, most countries list dates as day-month-year (little-endian in geek-speak). But a few other countries—such as China, Korea, Japan, Iran, and others—list the date as year-month-day (called big-endian by, you guessed it, geeks).

You need to design your website from the start to be able to render the dates differently according to region. Otherwise, you will need to deal with the problem later on when you localize.

Photographs:

A woman lying on the beach in a bikini may evoke comfortable feelings of sun and relaxation in some regions, but it might get a different reaction from people of other regions such as Iran.

If you plan to have different photos for each language version, then fine, you can decide on photos when you translate. But if your translated websites will be mirrors of your English site, you will need to think about what is appropriate in each region when you develop your English site in the first place.

Colors:

White chrysanthemums may seem beautiful to an American, but it may look macabre for millions of Asians. Colors have different meanings in different cultures. Unless you want to adapt your site design for every region, decide what color scheme is most appropriate for all of your target regions when you develop your English site.

Icons:

Here’s a fact that you already know but may have never considered: mailboxes are different all around the world. If you have a mailbox icon on your site, not all users will know what it is. However, if you use an envelope icon, it should be clear to all.

Make sure that your icons and maybe even logos are not culture-specific.

Language Selector:

When you design the English version of the site, don’t forget that you will need to have a language selector somewhere in the page design. Think of this during the initial design stage so that it can be worked into the page in an aesthetically pleasing and user-friendly way.

Technical Issues:

There are a whole host of technical development issues that must be considered when developing the site in the first place. Examples include how to sort lists, how to code messages to the user based on variables, how the site will initially detect language, and so on.

It pays to review the technical literature about how to develop a localizable site before you start spending money on your new site.

An old but still relevant article on some of the technical issues is this article from Smashing Magazine. 

Save Time by Planning Ahead

In this article we have listed several factors that must be evaluated before the site development begins. Neglecting these issues could lead to your company having to redo parts of the site when it is time to localize. Or it could lead to extra work with every language you translate into. Or it could lead to a disorganized and confusing site design.

If you already have a site and you are thinking of how to localize the website into other languages, don’t panic. Use this article as a guide to prepare for what issues may come up as you prepare to go multilingual.

It always pays to think ahead, and with website design it especially pays to consider localization as early in the process as possible.

---

Was this information useful to you? Would it be useful for your contacts? Feel free to hit a social sharing button on the screen to share the love!

---

Darren Jansen, business development and content manager for IVANNOVATION, has a lifetime love for tech and languages. At IVANNOVATION he helps software developers get professional localization for their apps, software, and websites. On his time away from the office, he can be found hiking the Carolina wilderness or reading Chinese literature.