Globalization and Localization of web sites

Many companies that sell products or services internationally are finding themselves in a familiar dilemma, should their web presence be global or local?

While a global site is easy to control and maintain and can ensure consistency in branding and content quality, it can not address local culture, interests and variation.

I’ve come across an interesting view on the site of the Localization Industry Standards Association www.lisa.org

They see Globalization as a process with 2 parts

• Internationalization which is the process for defining applications and sites to work in every market
• Localization which is the adaptation of the International framework to local needs and

And the process as:

I agree that the best approach in most cases is to plan for the site and application to work anywhere and then build in enough flexibility for local control and adjustments.

The challenge in this approach is that defining international requirements and anticipating all local variations is very expensive and time consuming. So what should a company that is expanding internationally do? Here are a few questions and guidelines to consider:

• Scope of localization: how are you products or services different around the world? Is it exactly the same product (jewelry tableware for example) or does a local audience may have preferences that will impact selection and availability of products (fashion and cosmetics). If the products need to meet local regulations, standards or laws (220V or 110V for consumer electronics, Material Safety or FDA approvals for Chemicals and Drugs) or if products include attributes like language that will make them market specific (Books and CD’s). In each case, a single catalog for all products will provide the easiest way to maintain master product data but sites level of granularity may be determined by the variance in offering. It may be truly global, regional, country or language specific.
• Centralized or Distributed management. Who will maintain content, details, specs etc. in local languages? Do you assume that a product is not released until all languages have been updated? Do you allow a default language to remain until a local language become available? Is this the responsibility of a central translation group of does it goes downstream to the local group to translate? (If you are thinking about machine translation, don’t. This technology is still not ready for prime time and will drive off disappointed customers)
• How local should you go? to create a true sense of local site and service, certain adjustments may be needed to the site so it does not look like the translated version of the global template. Does the site has local news and events? Is there editorial content from local sources? Are reviews and communities local? Does the interface adapt to local language without cutting words or providing headers in English? Are local conventions like time format, date format, calendar, currency, address, name formats etc. are specific or generic?
• Build from scratch or retrofit? While substantial amounts have been invested in current web and e-commerce infrastructure, allowing for globalization and localization is not an easy retrofit and in many cases it will be faster and cheaper in the long term to build a technology foundation that is designed to support these issues. Technology issues to consider:
  • Separation of content from the display. There should be no text or images in pages and no parameters in queries. Many CMS systems support localization and handle pages this way by default but custom build CMS systems rarely do.
  • Support for UTF-8: databases and management tools as well as search engines must support UTF-8
  • Caching and Performance: a system must be designed with advanced caching to avoid extensive load on the database for rendering local editions
  • Support for variable length and right to left interfaces. Different languages have very different word length and even orientation. How will interfaces that were designed for exact size look?

While these are not simple questions to answer and resolve, creating a global experience with local flavors and details can substantially impact the ability of a company to succeed internationally.

The way we navigate, Search vs. URL

We had an interesting team discussion regarding the relative importance of the homepage vs. content pages in driving traffic to the site. It opened up a few great questions:

1. How do people navigate? Do they type the URL or use the search to find a site, not bothering with the URL.
2. For a professional organization offering 20 – 30 different services, is it realistic to drive people to one page (the home page) and have them find the appropriate content from there or should we reverse the paradigm and try to get them to specific content pages and then allow them to navigate up and explore the rest?

 

URL vs. Search

When you look for a site, do you type the full URL of the site (www and all) or do you just type the main terms and look through the search results?

 

My answer will be “It depends”. Short, simple URLs I type, while more complex ones I don’t bother.

Two interesting recent articles talk about a worldwide shift to search based navigation:

In Japan, ads are starting to use search terms instead of full URL. As the article title says: URL’s are totally out.

Josh, at ReadWriteWeb wrote this week that The URL Is Dead, Long Live Search detailing a similar shift in advertising and use of the web by users.

 

Flipping the tree

If search is increasingly the preferred mode of navigation, where users land on the site will depends on the keyword used and whether they were placed correctly on the content pages or put solely on the home page. Which one is better?

We think that relevancy is the key. While it may be good for branding to have users always go to the homepage, the specific content they were searching for, resides at the leaf and directing traffic to the leaves was the goal of the home page to begin with.

Each leaf needs to behave as a landing page providing sufficient branding and clear navigation that will allow users to continue and explore up the tree.

 

Image credit: http://www.fisherkids.net/photo.htm

Building the web 2.0 corporate website

Welcome to the revolution.

We are in the Midst of redoing our website Edgewater.com and take advantage of the opportunity to examine recent trends and technologies and their impact on corporate website development. We’ll post some insights and share our thought process leading to the new site.

We have decided to build a new thing: a web 2.0 centric corporate site. Built upon the attitudes of web 2.0 and using some of the best practices, if not necessarily the flashiest interfaces.
We also decided to take a web 2.0 development approach as well. It means not spending months in requirement definition trying to envision future needs of our users. Instead we will take an iterative approach and release the site item by item as they are defined and implemented.

Yes we know the Agile movement had that down over 10 years ago but rarely externally transparent through each of the iterations. We intend to release each of the iterations. Put it out there and go back and improve one step at a time.
Our steps are basically:

1. Set a clear strategy and common frame of reference for how we see web 2.0
2. Select a collaborative platform (In our case, Sharepoint 2007 we had previously used for our Intranet)
3. Migrate the site as is
4. Start improving.

• Design
• Templates
• Content
• Keywords
• Rich media
• Collaboration
• Discussions
• Search
• Etc..

We hope this approach create a live and lively site that grows based on ever changing needs and priorities and is a perpetual work in progress.

We want it to be a center of our online presence but by no means the only online presence.

We hope it becomes a blueprint for the next generation of sites and their transformation for dynamic brochure-ware they currently are to true collaborative communities.
Let us know what you think of our progress.