Lessons learned from building Multi-Lingual sites
Here are a few thoughts on site design when building a multilingual website.
MENUS SHOULD HAVE FULL TRANSLATIONS
To keep your site looking good in all available languages make sure the menus are fully translated. This not only means you stay true to the design specification but it also avoids mixed language menus if you are using fallback languages for the content. Mixed language menus, particularly when there are many options, are ugly!
IMPLEMENT REL="ALTERNATE" AND "CANONICAL" WHEN YOU BUILD THE LANGUAGE MENU
Experience tells us that when building a multilingual website it’s a good idea to use rel="alternate" and rel="canonical" correctly in the html. This way your site can be optimally spidered and indexed by external search engines.
When using a web framework, dynamic content has to be generated on the fly, which means having to generate a list of URLs that represent the current page in alternative languages as well as the default URL of the page in the current language. It's a little work that needs to be done by the developer and really should be built as a helper function so it can be reused for the different pages of the website.
This also has the advantage of being useful for the language menu. This menu, usually found in the header of the page, is used to select your language and again it requires the same list of URLs as the alternate and canonical settings.
REMEMBER TO FILTER SITE-WIDE SEARCHES
This may seem obvious, but it is worth mentioning. If a Japanese user is viewing a Japanese version of a website and uses the site’s search facility, the results should be in Japanese. This means only searching the Japanese content in the database. If this is not done then there is a risk of returning confusing search results and harming the user experience.
There may be some cases when it is important to have an advanced search in all languages, but this is almost certainly not going to be the default situation. If a user understands another language they can also navigate in that part of the site and have easy access to those results. Thinking about this before the site is built is important as it informs decisions relating to the design of the database tables for the site’s content.
DO TRANSLATIONS IN TWO PHASES
Developers, translators and site administrators all have to work together to build a new site, but what is the most efficient flow of information when it comes to content? At the beginning of any project, the client will ideally provide the developer with a content specification. This specification should briefly inform the developer what the content parts should be and hopefully this will match the website design. Further into the development process a test site will be ready to take some real content.
At this stage the administrator can provide a skeleton set of content, which will cover the main sections of the site in the default language. Translations of this skeleton content should also be provided at this stage but they need not be complete, since they are just token representations in the various languages. Equally, at this stage translations for some of the interface should be provided. This first phase of translations offers the following benefits:
- It provides enough content for the developers to finish and test the site.
- The administrator can have a set of translated content ready because it is only a small set.
- General errors in the translations and their format can be resolved here.
- It helps the administrator prepare for the second translation phase.
The second phase of translation can then be done when the site has been completed. The bulk of this content may already have been prepared by the site administrator.
DEFAULT CONTENT LANGUAGE AND LANGUAGE SPECIFIC FALLBACK
It is important to know what to do if an article or text is unavailable in a particular language. We find that clients normally want their website to behave differently when showing content for different language versions. Using a default content language and a language-specific fallback is a good way to configure this.
The language-specific fallback defines what language to use as content if it does not exist in any particular language. This can be set for each language of the website, but doesn’t have to be. The default content language would be used when language-specific fallback is not defined for the language of the current page. These settings can also be set to 'no language' so the content of a page will be in one language only. In this way the general behaviour of the site can be defined with the default content language. For example you may want Traditional Chinese content to fall back to Simplified Chinese, but all other languages to fall back to English.
LANGUAGE AND CONTENT-SPECIFIC FALLBACK IMAGES
Coracle’s content management system, as used for multilingual sites, has the option to upload or use images specific to the content. This content will also have translations. A common question is, should the translated content share the same image? We believe that the answer is, not always, but by default, yes.
Another consideration here is that we do not want to upload the same image multiple times for the various translations.
The solution is to have an optional database field that can define which equivalent translation's image to use as a fallback. This method allows specific images to be used for translated content, but can also find images if the person creating the content has chosen not to specify one. Because this is at the level of the database records it will work together with the content fallbacks as described above. Warning! When implementing this, be careful to catch recursive image fallback redirections – e.g. the user may have made an image in French content point to the English content and the English image point to the French one.
Considering the look and feel of the final website, you may find with a variable amount of content that there are white spaces or badly aligned elements on the page. An example would be a page with four blocks of content arranged in a square shape or a carousel that takes at least five items. If there isn't enough content the page will look odd. A good idea is to create a simple table in your database for this use. This will most likely consist of snippets of text with links to other parts of the website, but could easily be quotes or information to catch a user’s attention. This is a general type of content that is used to fill spaces often found in dynamic multilingual sites, but is a great opportunity to drive interest in other parts of your site. This would also work with the fallback languages, but filler content should really exist in all available languages. This can have the added benefit of making your site more fully translated than it might otherwise be and can ease the pain of adding new languages to existing sites.
A LANGUAGE ALIAS FUNCTION
User monitoring tests show that users sometimes change language by changing the code in the URL. It is therefore useful to have a list of aliases that each language can use and a function that will convert the language code in the URL to a language code used by the page content. This is not only useful to the user, but it means that you can redirect locals and create completely translated URLs.
Do you have any other tips to share? Would you like to talk about how a multi-lingual site might help your business? We're ready to talk!