Building Multilingual Websites — A Case Study

This article reflects information as of 2020. For the latest details, please contact us.

Written by: Tomohiro Koizumi, Representative Director, tentus inc.

画像1

Originally, most of the requests came from global companies, but with inbound demand from overseas and outbound demand to send Japan-original content abroad, lately a truly wide range of companies are taking on multilingual sites.

Translation tools have been evolving, so multilingual sites aren't as difficult as they used to be — but there are still several points you need to be careful about.

This time, based on real cases, I'll introduce a few of those points to watch.

Running Production in English

For a certain manufacturer's global campaign, we built a site in six languages: Japanese, English, French, Spanish, Portuguese, and Chinese (simplified).

It was a multinational team — the planners were a US agency and a Japanese agency, the designer was a US design firm, the production coordinator was me (a Japanese person), and production was a Japanese production company. Holding telephone conferences at just past 7 a.m., right at the edge of US West Coast business hours, was truly grueling.

Incidentally, there were so many words I couldn't catch in those calls that I secretly resolved to enroll in RIZAP ENGLISH.

At first, English documents came down from the US design firm; we'd create a Japanese structure document based on them, get confirmation from the Japanese client, then, if there were no issues, translate it into English and toss it back to the US design firm — an extremely inefficient flow.

To break this inefficient flow, we decided to create all documents in English, turning a blind eye to the downside that clients and team members who weren't strong in English could no longer review them.

This eliminated inefficient rework, and because it enabled the English-centric translations that translation tools handle best — "English × Japanese," "English × French" and so on — we were able to compress production costs dramatically.

In this way, when producing a multilingual site with multilingual members, making English the central language creates very large benefits.

I'll cover the checking of translations later.

Multilingual Pitfalls Beyond Language

Creating a multilingual site isn't just about translating — you also need to consider the culture specific to each language.

Here are a few examples:

・For the Arab world, out of consideration for Islam, avoid depictions that expose women's skin.

・For mainland China, consider that images of people with missing limbs, such as para-athletes, may be subject to censorship.

・When assigning meaning to colors, consider that the impression a color gives differs greatly by culture. (From an accessibility standpoint, assigning meaning to color isn't a good idea to begin with, though.)

These are of course not all items you must address, but knowing them lets you avoid unnecessary friction when rolling out in each country, so they're worth having as knowledge.

For the global campaign mentioned earlier, we made it possible to serve different designs by IP; then, to start, we displayed without differentiation and prepared to swap content immediately if problems seemed likely to arise, controlling the risk.

Don't Demand Perfect Translation

This is a case from a cosmetics maker's site — during the orientation for a product-site renewal, I heard the number of target languages was 20-plus and nearly fell off my chair.

Thanks to the translation tools and reasonably priced translation companies mentioned earlier, the copy itself comes back easily when you translate from English into other languages. But to check the translations, you need directors well-versed in each language.

And it's not as if any Italian will do for Italian — phrasing differs between northern and southern Italy and shifts by generation, so if ten Italians review it, everyone gives scattered feedback based on their own subjectivity, and it gets very confusing.

For this reason, we basically create only 【English and Japanese】; for the other languages, we build the site itself and then ask 【a native speaker of that language】, including the client, to at least confirm there are no discrepancies in meaning — releasing with the awareness that the copy 【may have nuances that are off】.

We separate 【information that absolutely must not be wrong】 from 【nuance, where expression has latitude】, and after checking with that distinction, we split off the nuance portion for anything whose boundary is ambiguous. By making the nuance portion editable at any time if pointed out after release, we avoided the multilingual pitfalls.

Don't Forget GDPR

GDPR (the EU General Data Protection Regulation) is still handled inconsistently across companies, but simply put, its content is: "You absolutely must protect the personal data of people in the EU. If you don't, we'll hit you with staggering penalties."

This "people in the EU" is a tricky one: it of course applies to a Spaniard in Spain, but it does not apply to a Mexican American who speaks Spanish.

So the question arises of how to determine whether a person is in the EU — and at present, most companies handle it with one of two patterns: "judging by IP" or "presumptive judgment by language."

GDPR is very complex, so I'll compile it separately, but at the very least, please remember that when building a site using European languages, you need to be mindful of GDPR.

Finally

As you can see, building a multilingual site comes with all sorts of pitfalls.

Most of these can be avoided simply by knowing them as knowledge, so if you consult an experienced company when building a multilingual site, I think you'll be fine.