Gutentag! After a longer-than-planned hiatus, our series on multilingual websites continues.
In the first post on multilingual web design, we reviewed the questions you should be asking before getting started. In this installment we’ll share some of the technical and layout quirks that translating your site can present.
One of the first steps of how to plan a website is the information architecture. This is true whether the site is in one language or many. You create a sitemap, then lay out your templates in the wireframe process. This is the first place you might run into trouble.
Your wireframes will have defined spaces for navigation, calls-to-action, forms, headers, imagery, etc. However, the length of the words in those spaces will vary across languages.
For instance, an email signup field might have a “Sign Up” button to submit. But in French, it translates to “Inscrivez-Vous” – twice as long.
Likewise, German and Nordic languages tend to combine phrases into longer single words, like fahrvergnügen (the joy of driving) and steinbuhler (really awesome guy). Because there are no spaces in these words, they won’t wrap at the end of a line and can cause layout issues. It can also cramp your navigation if you have links arranged horizontally.
The solution to these issues is to consider the translations while designing the site or accept that there may be differences in the site between languages. You might reduce the size of navigation text in the CSS or remove an item altogether to make it fit.
Another consideration is if all of your languages will be reading from left to right. In most cases this will be true, but if you’re translating into Arabic or some Asian languages, your site will need to mirror itself to be correct. While this is a programming and CSS challenge unto itself, you can save yourself some grief by making your site symmetrical.
The look of your website – colors, font choices, image style – is in theory separate from technical considerations. When building a multilingual site, you will need to keep a few limitations in mind, as well as be sensitive to cultural differences.
This is especially true when choosing a font. Until recently web designers were limited to a handful of web-safe fonts. With the emergence of services like TypeKit and Google Fonts that is no longer true.
Keep in mind there is no guarantee these more stylish fonts will have all the characters you need when switching to another language, especially languages not using the Latin alphabet. Likewise, CSS transformations on headings such as Small Caps or Proper Case look great in English but don’t have the same meaning in other languages.
You should keep your text styles simple to avoid an inadvertent problem in other languages.
Image selection and motif is another area where additional time may be spent. A collection of images may be perfect for an American audience, but overseas they may not resonate with your audience. Be sure to allocate time and budget for additional imagery if your selections for the first language are not universal.
Once you have the issues involving layout and design resolved, there are still landmines you may run into. Often these will be specific to your site, but there are a few recurring ones we’ve run into.
The most common place to have an unexpected issue is in forms or other user input. It’s easy to forget that error messages need to be translated and that input might follow a different form across languages.
For instance, if you limit your ZIP code field to 5 characters or require a certain phone number format, users in other countries will be unable to submit because theirs follow different conventions. Likewise, dynamically generated error messages may not follow the same sentence structure and will need to be retranslated entirely.
A recent issue we’ve run into is the different use of decimal points across cultures. Americans use a period to distinguish between the integer and decimal parts of a number (e.g. 3.14) while the French use a comma (e.g. 3,14).
Characters used for thousands separators have similar disparities (e.g. 3,000 vs. 3’000 vs 3 000). If users are entering numbers on your site, such as quantity or size, you’ll have to account for these differences in user interaction.
All of these examples were experienced during real projects at Orbit. Each project brought new challenges and we aren’t naive enough to think we’ve seen them all.
You’ll discover new ones as you build a multilingual site and you should plan in your timeline and budget for unexpected snags. If you have some stories, please share them in the comments.
Editor’s note: This post and all posts in this series were co-authored by Barrett Lombardo, Technical Director at Orbit.