The Layout and Navigation Challenges of Partial Localization

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 a bunch of language-specific versions of your content, so you build custom template sets for each version which take into account not only language, but for browsing patterns, cultural norms and customs, and subtle references to the national flower.

And, of course, when the visitor enters the Konami code, you start a 320Kbps audio stream of their national anthem which plays softly in the background.

[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 a large share of localized websites were never planned that way when they were originally built.

What usually happens is that a website gets built in the default language of the visitor base for which it’s designed to serve (which is usually always the same as the predominant language of the organization behind it), then, sometime well into the future, the organization decides to add a second, third, or fifteenth language to support new business requirements.

But what often happens in these cases is that the entire site doesn’t get localized. The organization approaches these new “localization target” visitors as provisional, perhaps in an attempt to prove a new line of business while minimizing their expense. In other cases, some of the content doesn’t apply to other audiences. And I’ve 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, fundamental problem: how do you effectively render a website in 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 anglocentrism for a moment). And in this hypothetical scenario, we want to partially localize into French. Let’s assume that only 30% of the total content on the site is to be localized into French.

The core question becomes: what do we do about content that we don’t localize? More specifically, what do we do about missing navigational or layout elements that result from content we don’t localize?

Our two options are:

1. Simply remove the non-localized content
2. Present non-localized content in the default language (English, in our example)

Both present challenges.

The first option seems like a direct solution, but with 70% 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 sub-optimal 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.

Blank areas of your page layout with no information, especially in places where design cues would lead visitors to expect navigation, will look awkward and broken. The site could conceivably be re-arranged to deal with these gaps and display a more cohesive layout with limited localized content, but there’s a blurry line when you cross over into something which might really constitute another site entirely. Additionally, the templating complication might be considerable with large portions of the front-end markup becoming conditional.

In our example having only 30% of the site localized into French, it’s worth considering a separate site or completely separate set of templates designed around the idea of 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 the 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 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 highly monolingual. For example, the average native Chinese visitor wouldn’t understand English and 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.

In other cases, visitors might be assumed to speak your default language. Most residents of the countries of Scandinavian are fluent in English in addition to their native language, so having 30% of the content in Swedish and the other 70% in English doesn’t present a problem.

There are no generalizations around this topic. Every situation has to be evaluated in the context of:

1. The percentage of content that will be localized
2. The navigational prominence of non-localized content
3. The expectation of your localization target visitor to be even slightly familiar with your default language
4. Your tolerance for site layout and navigational alteration to adapt to missing content

To return to our original point: this is a problem usually caused from localization after the fact.

Clearly, this point is key: if you can plan layout and design for partial localization at the beginning of your website project, do so. In examining your site design, you should be able to account for missing content and plan language-aware layouts and navigation to adapt and compensate.

Does this sound familiar? It might, because with this, we’re essentially expanding the definition of “responsive design” to encompass language. More specifically, we’re responsively reacting the presence or absence of content itself.

This increasingly reminds me 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-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.