Account services

Multilingual browsing, navigation and language issues

Page layout and languages

Web pages are mainly based on two main information areas: navigation and content. See following page layout example.

layout with header and left navigation

1: Navigation area
2: Content area

Websites may have several different page layouts. In any case we can always identify these two main areas. Other common page layouts are:

layout with header and left navigation

Now that we are aware of the above main information areas (navigation and content), we can go further and look into the issues when we implement a multilingual website.

Navigation is very important for a website. It helps visitor to browse the website and find the appropriate content.

Many websites provide content in different languages and navigation only in one language. The problem with this approach is that if the visitor doesn’t know the navigation language, he/she will not be able to use the website at all. This is the approach used by EEA before May 2004. The navigation was then provided only in English, forcing people without English knowledge to leave the EEA website and creating difficulties for people with low English knowledge.

Some other multilingual websites do also provide different languages in the same webpage. This can create confusion and irritation among many visitors, especially if the languages do not meet the visitor’s expectation.

The following user scenarios will present some problems that arise during a multilingual website visit.

User scenario 1

User knows only Language B. User goes to a webpage find navigation in A and content in B.

Results: User can read content but cannot navigate further on the website. User will leave website.

User scenario 2

User knows only Language A and B. User goes to a webpage find navigation in A and content in C.

Results: User cannot read page content, but he/she can navigate to another page. If after a couple of attempts the content is not in the language A or B, the user will leave the website.

The above presented user scenarios are examples of many possible scenarios. In reality we will encounter many different users with their own language knowledge and computer experience, therefore the visitor’s experience will vary.

In the following section we will present some best practices on how to satisfy the visitors of a multilingual website.

How to satisfy visitors (user experiences)

As we have seen in the previous sections, in a website navigation and content may use different languages. This happens when a website offers navigation in a one language while content (normally in the form of documents) is in several languages. This approach is still very common among many European websites, maybe because of its simplicity in implementation. However having navigation and content in different languages may create several problems to many visitors.

In a website highest user satisfaction is achieved when the navigational language is identical to the content language, meets user expectations and the user understands the language used.

Best practice:

Do not mix languages on a webpage. More specific: the language used in navigation area must be equal to the language used in the content area.

Don’t switch language without warning

Paolo understands Italian and Spanish fluently, since he lives in Italy but originally comes from Spain. He is in Italy at the university where he is studying a course about environment. He finds a public computer at the university and after a Google search on “Segnali ambientali” he arrives to the EEA press release page about the report “Environmental signals 2004”.

The press release is in Italian and presents the new report “Segnali ambientali 2004” to the visitors. Paolo finds the content interesting so he continues reading. At the end of the press release he finds a link to the report itself. He wants to know more about the report, he clicks on the link and suddenly the page is in English. Paolo who unfortunately doesn’t know English very well gets confused and doesn’t understand why the page is not in Italian. He gets frustrated and goes back to Google for a new search.

What’s the problem? We assume people can understand English. We switch language without asking first the visitor what he/she really prefers.

Best practice:

Do not suddenly change language during a visitor session on a website. Avoid the assumption that ”all people understand English”.

If language switch is needed, then notify the visitor of the available language options and let him/her make a choice.

Avoid language switch a la Google

Today’s web browser technique allows setting up language preferences in the web browser. It means that a user could set up language preferences in the web browser as follows:

screen dump of setting the browsers language preferences

French (1st preferred)
Spanish (2nd preferred)

A multilingual website system could then use the above settings to automatically deliver the most preferred language to a visitor. If a page in such language is not available the second preferred language is delivered. When no match is found the default language (normally the source language) will be displayed.

Other techniques use the visitor’s IP-address to guess in which country the visitor is and accordingly guess the language to deliver.

These techniques are used in various ways by many popular websites. Among them we find the famous search engine: Google. Many people wonder why when visiting they get redirected to a google site in another language, they may not understand. For example if you are in France for vacation and you visit you will end-up with google in French, even if you don’t want the French site. Today people travel more and more in Europe and website developers should not assume people surf Internet only from their home. Google is an example of how unreliable IP-based language guessing is. On top of that they redirect the user to a different domain, which add to the confusion.

Best practice:

Do not automatically ”guess” a new visitor’s preferred language by for example ”visitor’s IP-address” or ”previous visits set-up (cookies)”.

Use ”web browser language negotiation”, but allow the visitor to explicitly tell the preferred language on all webpages. Keep the user’s preferred language for the entire website visit or until the visitor explicitly changes language.

Do not annoy visitors

One of the solutions for the missing translation dilemma is to create an intermediary page where the user may select one of the available languages (strategy 2). This page should be used only in a few cases otherwise the visitor will feel bothered.

Consider the following scenario.

Maurizio who likes to make pasta in the evening uses to visit where he finds many interesting recipes. Unfortunately the website maintainer is a private person in Italy who run the site only as a hobby. Therefore he cannot have the recipes in many languages due to lack of budget. Maurizio knows Danish and English very well while Italian is still at a basic level. When Maurizio finds a recipes he clicks on the link. If the recipe is not available in English the website will show the visitor a “Select language”-page. The problem here is that every time Maurizio finds an interesting recipe, he has to choose the preffered language. This is annoying.

Best practice:

Do not bother the visitor with too many ”Please select language”. This should be done preferably only once for each visit session.

When content is not available in the visitor’s preferred language warn the user before he clicks on the link that it will be in a different language.

Do not try to create an illusion of having a lot of content if it’s not in the visitor’s preferred language.

In exceptional cases some language cross linking is needed (ex references, links to external websites). Keep these exceptions to a minimum. Make it clear that the page will be in another language, see example:
See report 2004 (English)

Address the need of polyglots

Today a large part of the population knows more than one language. The majority of this group knows two languages and the rest even more. We will call these people polyglots.

When polyglots search for information on the web, they may do it in several languages. Even if this target group knows more than one language, they still prefer one of them. If they do not find the information they need in the preferred language they will probably switch to the second preferred language.

Best practice:

Always provide a simple way to switch language on every page of a multilingual website.

Make the translations available to Google

Google and other search engines will periodically scour your website and add your content to their indexes. They will come in with no language preferences, so what to do when you have content available in more than one language? If you deliver content according to the webbrowser preferences, your system will fall back to the default here and Google will never know you have translations. The alternative is to show the default, and then provide a way to select the alternatives. But, if you use cookies or inaccessible javascript to change the language preference Google will ignore your select-box. The only way you can make Google happy is to have the language as part of the URL.

Best practice:

Make it possible to have the language choice as part of the URL—either as part of the path or the query string.

Now when the different translations of a document have unique URLs, Google can distinguish between them and present them as search results. The user can jump to them, bookmark them and email them around without some magic happening that switches to an unexpected language.

How do you tell Google and other search engines the URLs they have to follow to get the translated content? W3C recommends using the <link> tag in the header of the other translations, like this:

  <link rel="alternate" href="/da/news.html"  hreflang="da"  title="Danish" />

We have tried it, but only the Ask Jeeves/Teoma and LookSmart webcrawlers follow those. However, certain webbrowsers, such as elinks, understands these links, and makes them part of their navigation system. But since Google doesn't notice them the only alternative is to put the links inside the body of another webpage. But not inside a <form>. The webcrawlers don't understand forms. At most they invoke them without any selection made or variables set.