louisrosenfeld.com logotype

Home > Bloug Archive

Apr 12, 2004: Information Architecture By Locale

As part of my crash course in IA globalization, I recently read John Yunker's excellent "Beyond Borders: Web Globalization Strategies". It's a very useful introduction to the intersection of globalization and web design. Unfortunately, Yunker dances around the IA pool but never jumps in. He does address content management, which is certainly relevant to IA, and discusses gateways, which are as relevant to IA as a naked mud wrestling match between Rick Wurman and Ed Tufte. Even then, the discussion is tantalizingly light, and so far I haven't found any other books that take on globalized IA--if I'm missing some, please comment below. And if someone's itching to write a book on globalized IA, now's the time: Livia Labate and Peter van Dijck, are you listening?

One important point that Yunker makes is concept of locale. Locales are the intersection of geography and language, and may have little to do with national borders. For example, Quebec, the part of Canada that speaks French, counts as a locale. Japan, which is essentially monolingual and the only place where Japanese is a major language, is also a locale. Latin America, sans Brazil, could be treated as a locale, although some might wish to break it into separate locales due to the variation is Spanish spoken in Latin American nations.

Locales are quite useful to information architects grappling with globalization. They constitute something of a high-level building block that can be classified, sorted and shifted around underneath a site's initial gateway page. While locales depend on geography and language, they free us from the mindset of designing for specific languages or regions. So when your Senior VP asks whether the gateway should be classified by country or language, you can smarmily answer "neither: by locale instead".

Naturally, locales aren't perfect. One must also consider other factors when developing those building blocks, like pesky national borders and character sets. For example, although they speak essentially the same language and just a decade or so ago were part of the same country, Serbia and Croatia are by no means the same locale (if I asserted otherwise, I might be assassinated). And even if their uncomfortable proximity was, well, more comfortable, they use different character sets (Cyrillic and Latin respectively), and for that reason alone should be treated as separate locales.

Perhaps an even more interesting consideration is the relationship between locales and company's existing definitions of markets. This is where things start getting really tricky. Corporations might define markets as countries, locales, large regions (e.g., "the South Asian market"), linguistic regions ("the Spanish-speaking market"), or, egads, all of the above concurrently. Beyond the fact that there is usually no one-to-one relationship between markets and locales, oddly-defined markets may also be quite ingrained into corporate thinking. So information architects now have to find a way to match or meld two different types of building blocks--locales and corporately-defined markets.

This is really just one of globalized information architecture's challenges--once we handle the top-down problem of determining the right building blocks to link to from a gateway, we have lots more to work out once the user reaches the area of the web site intended for him. Here's where bottom-up IA and search come in.

I hope to ramble on those topics some time down the road; in the meantime, if you want more on globalized IA, check the wonderful reader comments attached to my last posting on the topic.

email this entry

Comment: Livia Labate (Apr 12, 2004)

That definition of locales is great because the first assumption people make when confronted with a l10n project is that national borders will help limit the boundaries of who the users really are. It's part of our need to classify things in the nicest looking boxes we can find. We should cut that out.

I used to be upset when Amazon would offer me (through 'Your Recommendations') all sort of electronic gadgets knowing they aren't allowed to ship those things to Brazil. Last month I was in the US; guess what was the first thing I did? I bought a digital camera from Amazon; it had been sitting in my wish list for months. If they had limited their locales to national borders I wouldn't have been persuaded by them all through these months.

As for the notion of locales depending on geography and language, I prefer to say they depend on culture and language. Geography (which is too easy to mistake for national borders) plays a very small part on the whole thing (though you would think otherwise if you list all websites with locales represented by maps and, worse, flags).

But the trickiest thing about working with locales is the potential to offend your audience just by taking them for granted, as your examples show. And since there is no book on IA and i18n/l10n, let's go crazy...

For a while now I have been thinking about how to properly address locales at the start of a project. Locales define an audience niche with specific characteristics and needs - should then locales be treated as any other user group?

At first I thought yes, because after all, a user group has particularities which should be explored regardless of its complexity. Then I though no, because dealing with locales implicates the use of non-core skills from a 'standard' UX team (if there is such a thing), so they are unique.

I decided to settled for a yes and no answer. But would like to be challenged on these assumptions.

The YES from a 'technical' perspective, as locales will have unique needs in regards to structure, language, content and tasks. You can't addressed their true needs from the start unless you see them clearly as one of the user groups you will deal with (even if the localized versions of what you're building are not to be built simultaneously) [1].

And a deep and very sonorous NO from a managerial point of view, because of its project management and staffing implications (for example, your user research and usability testing should probably be conducted by local specialists). And this is because of the first reasons -- in-depth culture and language knowledge are not skills we commonly require from IAs and other UX professionals [2].

So perhaps the answer is to not treat locales separately but to remember that they need additional research and careful/specialized attention because we take a lot of cultural and linguistic implications of our designs for granted (even with the best of intentions). We know there is no such a thing as separate but equal, however, we cannot presuppose locales attributes, they are *very* special user groups.

And here's an article I always send out to people when I get that puzzled look every time culture and language issues come into the IA mix.

'Are you Cultured?'
Aaron Marcus, March 2003, New Architect Magazine

What I love the most about this article apart from how succinctly it summarizes big localization issues, is that it is classified under "Strategy" on the site. Right where it belongs, which is rare. Seeing i18n and l10n as strategic aspects of Enterprise IA comes before all this locale talk, but I'll leave that to a future posting...

[1] You can't expect to have several localized versions of something unless you start out with that premise. If you decide to think about this after your "original" is done, all you will be doing is building something else from scratch. A massive waste of resources, specially time.

[2] I wonder what role this perspective would play in IA education. I would love to know what Victor Lombardi has to say about that. Victor?

Comment: Todd Levy (Apr 13, 2004)

Here's a great article related to localization...

*Translation is not enough*
*Considerations for global Internet development*

As I mentioned to Lou, I've been handing it out to people for years -- whenever someone mentions a "simple" internationalization project I run off a few copies :)


Comment: Samantha Bailey (Apr 16, 2004)

The book I've been using lately is:
A Practical Guide to Localization (Language International World Directory)
by Bert Esselink


It's worth checking out.

Add a Comment:



URL (optional, but must include http://)

Required: Name, email, and comment.
Want to mention a linked URL? Include http:// before the address.
Want to include bold or italics? Sorry; just use *asterisks* instead.

DAYENU ); } else { // so comments are closed on this entry... print(<<< I_SAID_DAYENU
Comments are now closed for this entry.

Comment spam has forced me to close comment functionality for older entries. However, if you have something vital to add concerning this entry (or its associated comments), please email your sage insights to me (lou [at] louisrosenfeld dot com). I'll make sure your comments are added to the conversation. Sorry for the inconvenience.