Shares
Use arrow keys to navigate

Everyone is talking about globalization and how to reap its benefits. And they are right—entering a foreign market with care and awareness of local needs and customs can explode your business. But launch a half-assed localized site without sufficient preparation and it could hurt you more than it helps.

I run LinguaLift, an online language school, and I’ve consulted small businesses on how to best approach new markets. Below, I cover both high-level considerations, as well the more technical aspects of localization.

How to translate your site

The first thought that pops into most people’s heads when they think about localization (abbreviated as l10n) and internationalization (i18n), is language. Although good localization must also consider technology, law and culture, and not all countries speaking the same language are alike, a good translation of your online presence is important.

If your are serious about your internationalization plans, hire a native speaker in-house, or look for a long-term contractor on Upwork, and learn at least the basics of the language yourself. A few months of study are enough to notice obvious mistakes and roughly assess the competence of your writers.

Hiring a native speaker dedicated to the project and learning some of the language is crucial because localization is about much more than just literal translation. It is about the understanding of cultural differences, appreciation of local humour, and knowledge of conventions in typography and design, among many others.

Whenever we decide to launch a new language course at LinguaLift, we start by spending a few weeks in the country where the language is spoken, taking lessons ourself, and consuming hours of music, books and movies to appreciate the local culture. This makes it much easier to select qualified authors for the course, and understand the nuances of how a particular language can be taught best.

Similarly, when I consult small businesses on localization and expansion into new markets, I recommend at least some of the management team to take a trip to their country of choice, learn some of the language, talk to locals, read about the country’s history, and imbibe the maximum about the local culture. If you are serious about penetrating a market, the small expense will pay ten fold.

Alternatively, get an online translation instead. It can be tempting to just throw a Google Translate extension on your website, but the results are almost guaranteed to be lacklustre and may scare away more users than you will attract. Again, if you acquire even a basic understanding of the language, you’ll quickly realize how misleading automated site translation can be.

A better alternative is Gengo, an online crowdfunded translation service which seamlessly connects you with human translators around the world, at a very reasonable price of $0.05-$0.12 per word. They even provide an API, so you can automatically get new content, comments and reviews translated as they are published on your site. This gets expensive over time, but should be a no-brainer if your revenues depend on localized content.

Better yet, make use of a specialized service for web and mobile interface translation such as OneSky. It can be tricky to translate a site word by word, without actually using it, and OneSky make the process seamless and reliably by showing screenshots within its translation interface. You can start here for the UI, then switching to the cheaper Gengo for actual content within the page.

Whatever approach you choose, I strongly recommend you to focus on a handful of languages and markets, and spend the time and money necessary to get them right, rather than try to cover the entire globe. Analyze your usage, sales and customer support data, choose two or three regions to target, and stick to them until there’s noticeable traction.

Technical considerations

Technical considerations

Link structure

A constant issue around localization is the choice of the right site structure. Here are just some of the common options:

  • Including both languages on the same page
  • Translating the page slugs (www.example.com/uber-uns, www.example.com/a-propos)
  • Buying separate TLDs (top-level domains) for each region (www.example.de, www.example.fr)
  • Separating the site by subdomain (de.example.com/about-us, de.example.com/about-us)
  • Prepending pages with the language code (www.example.com/de/about-us, www.example.com/fr/about-us)

The first choice is commonly made by beginner bloggers and webadmins because it requires little to no technical setup and is reminiscent of translation on real world packaging.

Scandinavian-cereal

This comes with a range of problems, however, from bad SEO (search engine optimization), through cultural mishaps, to bad maintainability. Google selects the most relevant pages for top results, and a German description of Cinderella is of little help to someone who searched for “Cenicienta” in Spanish. You may also want to change illustrations to accommodate local laws and customs, offer payment in different currencies, or remove certain posts and products altogether in some of the regions.

A common alternative among first time publishers is to simply create new pages with slugs (page links) translated into different languages. This is straightforward at first, but comes an absolute mess to maintain when you run into accent encoding issues, foreign alphabets, or false friends & homonyms.

The third option, buying a separate domain for each region, is recommended if you have a physical presence in the respective countries. It will boost your ranking on local versions of Google, but it comes with its own challenges. Buying separate domains can get expensive, with some regional extensions costing hundreds of dollars per year. You can also get bogged down in legal paperwork, and you’ll of course have to promote each site separately.

A slightly simpler alternative to the above is to put each site on it’s own subdomain. This removes the need to buy and administer separate domains, but can still be technically challenging to maintain, and it doesn’t resolve the need to market several independent websites. Note that Google treats subdomains as distinct web properties, so domain authority won’t be shared across the localized versions.

Finally, probably the most common and robust approach is to keep the slugs in English, but prepend them with a language code, so the English _/about-us_ becomes _/de/about-us_ for German, and _/fr/about-us_ for French. This is fairly straightforward to set up with a good CMS (content management system) and provides flexibility needed to avoid many of the problems mentioned above.

Whichever option you choose (each has its place, depending on your site’s needs and limitations!), adapting a site to other markets comes with many challenges, and I recommend working with a professional developer with prior experience in localization. You can also read more about the topic in the excellent International Search Engine Optimization checklist at Moz, and watch their 5 Dos and Don’ts of International SEO Whiteboard Friday:

Redirect or suggest?

Related to site structure is the question of redirects. Should you push visitors to localized versions of the site based on their location? Should you block access from other countries entirely?

This has been an ongoing discussion, and the consensus among usability experts is to suggest your users to switch to their country’s language, but make it an option, and notify them of the option unobtrusively in the header.

After all, location detection can be unreliable, more and more internet users choose to browse through a VPN (virtual private network) because of privacy concerns, and tourists visiting a foreign country don’t always speak the local language.

If you your industry imposes DRMs and draconian licensing agreements, you might have to be more strict about who can access localized websites, but in all other cases, we recommend just a small notification informing visitors that they can view the site in another language.

Flags and language icons

In addition to informing visitors of localizations, you should also provide a clear switch between versions, in case they change their mind, or want to compare content in different languages. This is where one of the biggest discussions in internationalization circles comes in: icons.

Historically, websites have used country flags to identify each language when space is limited in navigation, but this is frowned upon today, and for a good reason. After all, some languages are spoken in multiple countries (e.g. English), some countries have several official languages (e.g. Switzerland), and some languages aren’t used in any country (e.g. Esperanto).

Under pressure from consumers, governments and interest groups major companies that can afford such micro-localization have moved to long lists of language-country pairs, with separate sites for Switzerland (FR), Switzerland (DE) and Switzerland (IT), for example.

Apple-language-selector

Language selector on Apple.com

But even this leaves a problem: What icon do you use to reference the list?

This remains an unresolved question, and although several designers and organizations have tried to propose a universal language icon, the controversial icon of the globe remains to be the most widely used and recognizable. Just make sure to show the right side in each country!

Furthermore, remember to double each language in the list in native script. There’s nothing more confusing than looking for English in a language selector entirely translated to Chinese or Czech.

Language-selector-mockup

Mockup from “Language of language names in the language selector” on Stack Exchange.

This is only a taste of the exciting, polarized discussions around internationalization, and there are many more, from the placement of Israel under Europe or Middle East, through the name of Macedonia and Taiwan, to domain names in language-specific scripts and alphabets.

You can read more on the topic on the aptly named Flags are not languages website, and in the How to graphically represent a language thread on Stack Exchange.

Legal concerns

Doing business in another country means that the laws of that country will be applicable for any business you do. For example, if you are a US company selling a product to a French consumer on a French-localised website, then you will have to be compliant with French and European consumer law. This could mean offering additional warranties, cooling off periods, and support.

It’s naive to assume that your current privacy policy, terms of service and returns policy can just be sent to a translator and uploaded as they are. You should seek specialised legal advice for each territory that you are trading in, and customise your business to suit. Pebble watches, for example, offer a two year warranty in the UK compared to a one year warranty in the rest of the world, due to the stricter consumer protection laws that the UK enjoys.

Remember, you are not tempting foreign customers to your website, you are bringing your website into another country, and just as you’d adapt to the local customs as a guest, your business must also do the same.

Localizing your site is a big undertaking, well beyond just sending the content to your neighbourhood translation agency. You should think carefully about the markets you want to approach, and whether it makes sense to do it right now. When you decide to go ahead, I hope that the tips above will help you do it with the commitment that international expansion requires.

Use arrow keys to navigate

Shares

Posted by Philip Seifi

Philip Seifi is the Co-Founder of LinguaLift, an online language school where learners enjoy the flexibility of a self-taught curriculum with the guidance of helpful study coaches. Read his complete language learning guide to get a head start.

Related Content

Leave a reply

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