This guest post comes from Deane Barker of Blend Interactive. Deane is a fellow content management geek and longtime friend. I don’t know of anyone who is more insightful or passionate about the nuances of content management process and technology.
In this post, Deane talks through a topic that we run into all the time at Lionbridge: partial website localization. I mentioned this challenge at the Global Marketing Symposium but Deane does it far greater justice.
To localize a website, you plan for it from the ground up. You always know well in advance that you’re going to someday create 37 language-specific versions of your content. So you build custom template sets for each version, which take into account not only language but browsing patterns, cultural norms and customs, and subtle references to the national flower.
The icing on the cake, of course, is a 320kbps audio stream of the visitor’s national anthem that plays softly in the background when they enter the Konami code.
[Record scratch sound effect]
Shockingly, it never actually happens this way.
In reality, the localization of a website is often an afterthought. Perhaps that’s pejorative, but I’d wager that a large share of localized websites were never planned that way when they were originally built.
What develops instead is a website built in the default language of the visitor base it’s designed to serve (which is usually the same as the website owner’s predominant language). Then, well into the future, the website owner or organization decides to add a second, third, or fifteenth language to support new business requirements.
But what often transpires in these cases is that companies neglect to localize the entire site. Some organizations approach these new “localization target” visitors as provisional, perhaps in an attempt to prove a new line of business while minimizing their expenses. In other cases, some of the website’s content doesn’t apply to certain audiences. We’ve even worked on a few projects where the local government mandated localization for specific content, and the organization was translating the bare minimum required by law.
Partial localization leads to a very basic but fundamental problem: How do you effectively render a website on which a significant chunk of the total content might not be in the visitor’s language?
We’ll assume for a moment that a complete version of the site exists in a “default” language: English (if you’ll indulge the ethnocentrism). In this hypothetical scenario, we want to partially localize the content—say, 30 percent of the total—into French.
The core question becomes: What do we do about the content we don’t localize? More specifically, what happens with missing navigational or layout elements that result from non-localized content?
Our two options are to:
- Simply remove the non-localized content
- Present non-localized content in the default language (English, in our example)
Both possibilities present challenges.
The first seems like a direct solution, but, with 70 percent of the site missing, how will our site react? What will happen to the browsing experience?
Visitors might have problems navigating to certain sections. In more extreme cases involving suboptimal front-end markup, the framework and layout of our site might collapse or degrade in ways that impact usage or even basic legibility.
Of course, not all navigation is created equal. Sites usually have global navigation (About, Contact Us, Products) accessible from every page, and subsections might have localized navigation specific to their areas. “Localization gaps” in global navigation are clearly problematic, while gaps in subsections and other corners of the website are less likely to impact all users.
Areas of your page layout containing no information—especially those where design cues would lead visitors to expect navigation—will look awkward and broken. The site could be rearranged to deal with these gaps and display a more cohesive layout with limited localized content, but there’s a blurry line between this and creating something that constitutes another site entirely. Additionally, templating complications might be considerable as large portions of the front-end markup become conditional.
In the case of localizing only 30 percent of the site into French, consider dedicating a separate site or completely separate set of templates to limited available content. This site design could be built to adapt to this subset of content, since usability and IA patterns might be entirely thrown off.
Our second option is to “fallback” to the default language for content that isn’t localized. In this situation, content available in French would be displayed as such, and other content would be displayed in English. This preserves the navigational integrity of the site, as all navigation options are guaranteed to exist in one of the two languages.
(More complicated is a scenario where some content is in English only, some in French only, and some in both—meaning there is no default. Envision a Venn diagram of the two languages, and try to design a site and navigation architecture around that. No page can be guaranteed to exist for any single language.)
Judging your visitor’s perception of the fallback strategy is nuanced to your particular visitor base, but it depends highly on their grasp of your default language. Some cultures are monolingual. For example, the average native Chinese visitor wouldn’t understand English and would thus have no use for the non-localized content. Navigational integrity might be preserved, but the user is no better off and might even feel alienated.
On the other hand, visitors might speak your default language. Most residents of the Scandinavian region are fluent in English in addition to their native language, so having 30 percent of the content in Swedish and the other 70 percent in English doesn’t present a problem.
There are no generalizations around this topic. Every situation has to be evaluated by:
- The percentage of content to be localized
- The navigational prominence of non-localized content
- Whether your localization target visitor is expected to be familiar with your default language
- How your site’s layout and navigation will adapt to missing content
To return to our original point: This problem usually arises from localization after the fact.
A key takeaway here is that if you can plan layout and design for partial localization at the beginning of your website project, do so. In assessing your site design, you should be able to account for missing content and plan language-aware layouts and navigation to compensate.
This may sound like a familiar concept because we’re essentially expanding the definition of “responsive design” to encompass language, or rather responding to the presence or absence of content itself.
This increasingly reminds me of Chaos Monkey, the system Netflix uses to test its network redundancy.
>Chaos Monkey is a service which identifies groups of systems and randomly terminates one of the systems in a group.
Could your layout survive a language translation-driven Chaos Monkey “attack”? If someone decided the Products page no longer needed to exist in French, how would your navigation and front-end markup survive that “outage”? (If the answer is “not at all,” then, by all means, implement security at the page level to lock translations so they can’t be deleted.)
The traditional parameter of responsive design has been window size and orientation. But with some planning and forethought, we can and should enlarge that definition to account for partial localization, Chaos Monkey-like content loss, and the complexities and edge cases that result.