Bonjour! This is the first in a series of articles to share the lessons we’ve learned about multilingual web design. It’s common to think you need your site translated to address users in multiple languages. But exactly what that looks like covers a wide range of options.
The first issue – and subject of today’s post – are the questions you should be asking internally before embarking on a multilingual web design project. It’s an expensive and time-consuming undertaking and you want to be sure you’re choosing the right solution.
Translating vs. Localizing:
1. How are our organization and marketing efforts structured?
2. Do we market differently by region or country?
3. What percentage of our audience does not speak English?
4. Are we speaking to different audiences within the United States or is this a global effort?
5. Does our business operate under the same brand worldwide?
6. Do our products and services vary by language or country?
This set of questions addresses one basic question; do I translate or localize my site? The deciding factor is if you’re speaking the same message to all audiences or crafting it to the culture and audience reading it.
In many cases, you’re translating the bulk of your content but adding or removing based on local laws or culture. For instance, your site may require a page of SEC disclosures that wouldn’t apply in Europe. Or you finally have a home for that David Hasselhoff testimonial because, you know, Germans love David Hasselhoff.
Where you are on that spectrum can influence if you’re building one site and translating it or building several sites that are separately managed. That’s a bigger question, and we’ll address it in a later post.
Managing Content:
7. What are our content management expectations?
8. Do we need to translate all of our content or just some of it?
9. What about time-related content such as news?
10. Will one group be handling all the content management or is it on a regional/language basis?
11. Is any of the content shared or language-agnostic?
12. How often will we change the content after going live?
If you build a multilingual site, you’re going to need to manage it going forward. One trap to look out for is anything time-related. If part of your site involves a news or calendar section, maintaining that in several languages over time can turn into an expensive proposition. Unless you have fluent speakers in house, you would have to engage a translation company every time a news article or event is posted. Often clients choose to keep these sections as English only.
But that doesn’t address editing content that is more or less static. If the homepage messaging needs to change, then presumably that needs to be updated in every language. If that gets to be a common occurrence, the translations of those pages can quickly become out of date. A workflow process needs to be established that keeps track of what has changed, who has changed it, and if the translations are now out of date.
The content management system should have a mechanism for managing that, but some internal workflow will also need to be established. What that looks like will depend on whether one central team is managing the website or if it’s distributed by language. Having a dedicated team reduces the risk of inconsistent messaging across languages, but if they don’t speak all the languages they’re managing other embarrassments may arise.
Finally, some of your content may not need to be translated. If products or locations are the same in all languages, there is no need to spend the effort or introduce the overhead of managing several copies of them.
Next Steps
Answering these questions will get you thinking about how far you need to go to meet your business goals. It will at least give the team building the site some information to make an informed recommendation on which path you should pursue. There are other challenges and traps to avoid, such as design implications, which we’ll address in the next post.
Did we leave any questions out? Let us know in the comments below.
Editor’s Note: This post and the following posts in this series were co-authored by Ben Steinbuhler, Project Manager at Orbit.
