+44 118 324 5555
Our specialism is in developing multi-lingual websites - not only with great designs, but with powerful multilingual management features.
Building a 5-page site in two languages is of course simple; but how about a 50-page site, with interactive features, downloads and other features in English, German and Chinese, all optimised for search engines...? That takes a little more thought.
Read our guide for best practice in multilingual website design.
More and more organisations are seeing the need to make their site multi-lingual, or in some way made internationalised ("i18n").
It may be needed because there's a need to address a market that has more than one language (such as in Canada or Switzerland), but the most common need is to address international audiences.
Designing a multi-lingual site involves more considerations than a single-language site.
There can be unexpected real estate problems; for example, you might design your menu navigation with brief English words in mind, but when translated into other languages, such as French or German, find that the translated versions are much longer. Where a CMS lets authors simply enter content and navigation button names as they wish, you may find that the design breaks when long navigation buttons start to appear on the page.
The only way around this is to plan carefully when the site is designed. If you get the design right in the first place, translating the site will be much easier.
There may be cultural considerations. In some countries, design has to be more bold and bright, while in others it may be under-stated. So the use of graphics is of particular consideration, and your head office designer may need to take input from overseas colleagues in order to get the localisation right.
Multi-lingual sites usually have some mechanism to allow visitors to choose their locale. There may be a "splash panel" that appears to a user when first arriving at the site, with a list of languages, or perhaps language/country in combination.
There's a temptation to fill such a panel with flags. The designer mocks something up with lots of colourful flags and it looks brilliant. But is it right for all of those countries?
Take English for a start. If your English-speaking audience is primarily the USA, the stars and stripes may work well. Similar for a UK audience, the Union Jack works fine. But if your English-speaking audience includes Ireland, Australia, Jamaica, South Africa... it gets a little more complicated, and you risk alienating users in those countries.
Then take a language like Arabic. It doesn't have a flag at all. (If pushed, an Arabic speaker may consider that the green of the Saudi flag might look best... but that's not really the point.)
Getting on to Portuguese and Spanish, the flags of those countries may look fine for Europeans, but a little out-moded to the Spanish speakers of Latin America (who outnumber them!).
Using flags is generally best when you're allowing selection of a language and country combination. If you only let a user select language, only use flags if the list of languages you're actually using suits it.
There are ways of auto-selecting both language and country. A popular way to select language is to detect this from the visitor's web browser, the language in which he surfs.
When arriving at a site for the first time, a website can detect this, and set the language accordingly, after which an automatic redirection is performed, to the site's home page in that language.
Country selection can be done automatically too, but by IP address. This is called a GeoIP lookup, through which the server can tell which country the user's IP address is in. However, this isn't always accurate, not least because a user may simply be travelling when he visits your site.
There are also search engine considerations: Google likes to see "shareable URLs", by which they mean that any particular website URL should appear identically to all users, irrespective of their settings or location.
So be careful with automatic language or country setting; it may eliminate one visitor click, but can give you less-seen problems in other areas.
Once you've got your site designed, implemented on a decent CMS, and running, you'll want to get some content into the site.
The way we find this most commonly happens is for content to be written first in the "head office" language - which in our experience is mostly English - and once in place it needs to be translated.
Proper translation is easier said than done. We've all seen the highly impressive-looking Google translation... but remember, it's just machine translation, for the purpose of being understood. It isn't yet capable of writing powerful marketing blurb, or following your corporate brand guidelines!
So you'll want a human translator. Your CMS should have two key features in this respect: it should allow a page to be edited directly within the website by an authorised in-house translator; and it should also allow pages to be exported and sent to a remote translator.
The latter is important: if you can't export a page and have an off-line translator work on it, you may need to grant unauthorised people access to your site's editing system, which is not a good idea. Furthermore, it's stacking up problems for the future, when there are subsequent edits to pages.
A great tool for translation work is Google Translator Toolkit. Once you upload a web page, you'll see two panels, the left one for the source language, the right one for the target, or new language. The tool breaks up your page, sentence by sentence for editing. Google can be set to perform a machine translation to get you started, but many translators choose to turn this off. Once it's uploaded, you can Share the page to your translator, who'll be invited to come to the same interface in his own time, work on the page, and save his changes, until it's complete. After that, download the new page and re-import it into your site. With the right CMS, this process is very easy.
While some CMSs just handle the translation of regular web pages, some fail to properly handle translation of things like downloads. Imagine, as say a Mandarin speaker, reading a well-translated site in your own language, but when he comes to download your white paper, he finds it's only available in English. So consider whether you want to put the effort in to translate everything, but in any case make sure you've got a site that can cope with that.
Look out for graphics where text is flattened into the image. That is usually bad practice anyway, and even worse when it comes to a multilingual site: if you want to use the same image for multiple languages, it's better to have HTML text on or beside the image.
One of the most common pitfalls is to not consider the words and phrases tucked between regular page content or within special functionality.
For example, forms and error messages often get overlooked for translation, with the result that when an interested visitor tries to use a contact form, he no longer sees it localised, but only in your site's main language. Worse still, the field labels may be translated into his language, but not the error messages like "Sorry, please tell us your name".
Likewise, other functionality can be hard to use on a site not properly translated, such as search functions, shopping carts, extranet systems and other things.
To overcome this, make sure your CMS has a means of handling translations for such phrases.
There are several approaches to formatting URLs. A common approach is to use a different TLD (top level domain) for the site, so for example you may acquire example.com for and English site and example.de for the equivalent one in German. Technically this works fine, but can be impractical as it depends on purchasing a set of domain names.
A subdomain can be used, so that a site http://www.example.com could for example have a German translation at http://de.example.com. This is much more practical, even allowing different physical server locations.
The language code can be contained inside the URL so as to look like a subdirectory, such as example.com/en/ or example.com/de/.
A further possibility is including a URL parameter, such as example.com/home,de.
To show search engines how all of the pages relate to each other - which is a translation of which - ensure that your CMS generates a "hreflang" tag in its meta data. This will list both the current page's URL and the URLs and language codes of all of its translations.
Copyright © 1997-2016 Tribal Ltd.