UX principles for multilanguage websites?

Question

Different websites--even the largest and most popular-- take different approaches to localization, and I suspect that not all are very user friendly. By looking at examples online and reading articles, as well as some questions on this forum (like this one Bilingual website usability or this one Language of language names in the language selector?)

Now I have my best understanding of the principles, which I suspect is not the best. Let me know any improvements.

For a large brand with a presence in multiple countries:

• each country has an independent website. Country code TLDs for most countries, .com for the US.
• if the user goes to a country code TLD, they go directly to the website for that site. If the user goes to the generic .com, then their location is determined from their IP address, and they go to the site for their location--.com for the US or no match, a country code TLD for the country they are in. Some locations may be mapped to neighboring countries, where appropriate, if they do not have their own website.
• if the country has multiple languages that are commonly spoken, then language negotiation is used to read the user's language preference from the browser settings. A default language is set for each country, in case language negotiation fails to find a matching language.
• a flag icon, with the name of the country in the currently selected language, appears with other navigation links near the top of the website. The flag indicates the country the website is targeted for and the name indicates the language; clicking it lets the user select which country's website they wish to see. The country name shows in the current language.
• countries with multiple languages appear multiple times in the list, each one showing the same flag
• each item shows a country name and language name (for example, "US - English") in the language itself. Items are sorted in Unicode order to allow for consistent sorting across languages.
• if the user manually selects a locale, their preference is saved in their account (if logged in to an account) or as a cookie (if not logged in)
• each page has a content identifier--most likely a URL path on the .com site (although not all of these identifiers will exist as true URLs). When the user changes national websites, a match is attempted to be found for the content identifier, moving up one level of the path at a time until a match is made. For example, suppose the user is on a page of a Japan site talking about an upcoming special event in Tokyo. Let's say the content identifier is /news/events/tokyo/groundbreaking-ceremony. The user switches to the website for Turkey, which has no page with a /news/events/tokyo/groundbreaking-ceremony content identifier. It moves a level up; no page is found with a /news/events/tokyo content identifier. It moves a level up; a page is found with a /news/events content identifier (the actual URL, of course, would be quite different and in Turkish). The user would land on a page talking about upcoming company events relevant to Turkey. Since there is no exact match for the page they were looking at, it tries to find something as close as possible without just dumping them on the home page.
• for multi-language national websites, the language is set as a subdomain. The Switzerland localized website for French-speakers would be something like fr.mycompany.ch, while the German-speaking version would be de.mycompany.ch.
• each national website may have wildly different content and design, related to what the company is doing or selling in that country or how they wish to portray themselves, but every page is translated into every supported language for that country.
• when the user changes languages on the same national website, they go to the same URL, but with the other subdomain, loading the same page in the newly selected language.
• each website/language appropriately sets the lang attribute

That's the best I can think of to allow complete marketing freedom in each geographic market, while trying to keep things as simple for the user as possible. IMHO, the switcher should be obvious and easy to find, but take little space in the design. The only case where I think the approach I outlined in detail above would falter is if someone was residing in (or interested in) a particular country, but spoke a language not commonly found in that country. A German visitor could see the national website for Germany in German, or the Mexican website in Spanish, but could not see the Mexican website in German. Since each website would be so different, it would not be economical to translate the national website into a language not very commonly spoken in that country.

Note: I realize flags should not be used for language, only for countries. However, when dealing with the combination of country and language, I think it's easier to show multiple flag/country/language items rather than make the user go through multiple steps, such as first selecting a country and then selecting a language.

Now we move on to simpler websites: websites where the content is the same, but we are only worried about languages, not locations. Many popular information websites would not want to try to create completely different content for each country; they simply want to offer their content translated in multiple languages to engage a larger readership, regardless of location. Here are my thoughts on that situation.

• language negotiation is used to read the user's language preference from the browser. That language is selected, or the default language is used if no match is made
• for purposes of SEO and clarity, use subdomains (not subfolders) for languages.
• instead of location-focused symbols like flags or a globe, the Language Icon (http://www.languageicon.org/) is shown with other navigation near the top of the page, along with the name of the current language (displayed in the current language). This shows what is currently selected and makes it clear that the user can click that to change the language.
• when the list of languages appears, each language name is shown in its own language, sorted by Unicode order
• when a RTL language is used, sidebars should be displayed on the opposite side, the "direction" attribute of text blocks should be changed, and horizontal menus should be aligned in the opposite direction. (On a technical note, I suspect this would be best accomplished by setting a rtl or ltr class on the body element, based on the language, and then writing two versions of relevant CSS rules.)
• if the user manually selects a different language, this preference is saved to their account (if logged in) or as a cookie (if not logged in)
• any internal link the user follows takes them to that URL in the currently selected language. If they change languages, they access the same page, but using the subdomain for the new language
• the only comments displayed on a blog post are those made on the same language version of the site. You don't see all the comments, but you see the comments that are (presumably) in the same language as the content.
• each website/language appropriately sets the lang attribute

What about heavily crowdsourced websites, like Wikipedia? That would be a less common situation, but the crux there is that the website is basically the same across languages, but not every page is translated to every language. I think the Wikipedia approach would be the best here; show the list of available languages in the sidebar. This list will be longer for some articles and shorter for others.

I tried to read and research what I could and look at existing websites, but that provided me with more conflict and fewer solid best practices than I hoped, so most of this is based on whatever sounds to me like it makes the most sense at the moment. I'm sure it's not perfect; I have many doubts. For example, I don't know if it's better to have a small language selector at the top of the site, or to have a list of available languages spelled out at the bottom... I could go on and on. In any case, please let me know your thoughts--which of these best practices would you correct, and why? I want to learn the best approach from a UX perspective.

Answer 1

I think the question that you ask provides a scope to more details than just the interaction for localization. I am reading it to mean things you have to consider in your design if it is going to be viewed or used by people from different parts of the world. In which case it is quite a difficult question to answer because there are many design components to consider:

• Information Architecture: Compare the way content is presented in Eastern (e.g. Japan, Korea, Taiwan) versus Western (e.g. US, UK, Germany) websites, both in terms of density, structure and layout. Example of a discussion in a blog from a marketing perspective.
• Visual Aesthetics: Compare the use of colours, fonts, symbols, images, etc. Webdesign depot has a post talking about colour and cultural considerations.
• Content Strategy: Compare proportion and distribution of content (e.g. advertisement, call-to-action, information, messaging, instructions, help). Example talking about Japanese websites specifically.

And in each design component there are many considerations as well, such as the nature of the language, the cultural context with icons, symbols and colours, how values are presented in forms, etc. I think the complexity is such that people rarely consider developing a website that can cater for all these differences. Unless it is a multi-international company or business that does not have an overly complex structure or content.

Not only do you have to consider each country individually, you also have to then compare the similarities and differences between the countries that you are supporting. There are trade-offs between keeping a consistent look & feel and how user friendly it will be for the different users.

I suggest also looking at design showcases from the Smashing Magazine website that features a number of different countries, but you'll have to do the comparisons yourself.

The best example of a similar discussion for Name form fields used in a web page that addresses these types of concerns is an article by W3C.org on Personal Names.

Answer 2

Interesting question and thank you for asking. I've been screenshooting some sites that implement the localization functionality and in terms of User Experience, I believe that the best approach is the one of GoDaddy's

Take into account that the sites I've analysed are mostly e-commerce sites and I noticed that the whole site localization resides on the Currency Selector.

GoDaddy goes a little bit further by setting the locale subdomain URL without asking (don't ask me about the technology being used), but is happens even though I have my cookies off:

Other E-commerce sites, mostly clothing and the ones who have international shipping available, would prompt you for setting language and again, currency preferences.

I analyzed the most popular Localization Wordpress Plugin options and it offers a wide variety of positioning for the widget inside a page. The footer and the right toolbar seem the best positions for me because they don't interfere with the design, one interesting option is that you can upload your own flag or country icons, I would like to experiment with this languageicon you provided to see if it is widely accepted yet.

Google and search engines in general provide another approach as of localization where the results are listed according to your browser language preferences and your current location too.

I hope I complemented your research with this information.

Answer 3

You have quite the comprehensive list of good ideas. Some of these may be 'best practices', others depend on the context:

• Using flags can paint yourself in a corner. Many companies, for a number of different reasons but mostly due to limited resources versus marginal value-add, will treat different countries as a single market as they expand (e.g. Benelux, UK/Ireland, US/Canada, Australia/NZ, Middle East).
• Setting a locale by default makes sense in a web app or social media site like Facebook; in most others however I would recommend delivering content consistently based on the URL.
• RTL design applies on all sites large and small.
• Using subdomains for language is perhaps better but it's not always an available solution. To me, using a domain.com/lang/... is still acceptable, and Google seems to agree.
• Showing language-specific comments may or may not be a good idea, depending on your audience and use case. When I booked my hotel in Greece last year, I was happy that booking.com showed me comments in different languages that I could Google-translate and get an approximate understanding of their feedback.

Other ideas, such as the language icon, I think are still in the conceptual phase -- a nice idea but not yet common enough to be instantly recognizable.

Some of your other ideas strike me more as technological solutioning than UXD. For instance, keeping URIs the same between sites make your backtracking algorithm simpler, but for user purposes (and SEO) it would make sense to have URIs in Japanese and Turkish for each audience. Remember that URIs are meant to be assets for the user to find what they're looking for, not just meaningless addresses for computers.

Ditto for your solution in IP-based handling of the .com. In far too many cases, the US site for an American company will have more detailed and timely information than those of satellite markets. Sometimes the localized content is just poor quality, poorly translated, overly translated (they use official the dictionary words when everyone in the given industry uses English lingo and jargon), or missing (only sales brochures when you want troubleshooting information). It's important to allow users from elsewhere to be able to access the US site if they decide they need or want it.

For some great ideas on the language selector aspect, consider The Art of the Global Gateway by John Yunker. He provides some elegant solutions for global websites, the most basic of which is an indicator of your user's current context or locale with a dropdown. Again, I think this depends on context. The common approach to bilingual websites in Canada is the opposite; in the top-right corner it will have a link to the corresponding content in the other official language (so on an English page it will say "Français" and vice versa).

Ultimately, I would advise against hard and fast "principles" for UX. What's important is to know your content, your audience, and the solutions that best meet those requirements. Having a list like yours of different solutions and ideas helps us identify the best for our situation.