Internationalizing a Web Site, Part 1
April 13, 2001

by James Mendelsohn

With the growth of Internet markets in such places as Western Europe, Japan, China, and Russia, the ability to internationalize a site is either already vital for developers or soon to be so. How, then, to adjust a site to the differences in languages, cultures, and currencies -- to name just a few issues? What technical challenges are involved?

The answers to these questions break down into two categories:

Part 1:

• Globalization - alternately referred to as internationalizing a site, includes:
  • Identifying and establishing code, content, and design elements on the site that should be the same, regardless of the language or country.
  • Eliminating unnecessary, culturally-specific content.
  • Minimizing costs by reducing the amount of localizing necessary.

• Localization - involves creating local versions of Web pages that customize language, content, and appearance for a specific country or culture.

The checklists that follow are divided into these two categories but also address general issues for deploying an internationalized site. They are meant to help you decide how best to globalize and localize, both technically and logistically.

Part 1: Globalization

Management
Internationalizing involves coordinating technical and non-technical work -- from research on individual countries and hiring of translation services -- to Web design.

• Determine who will be responsible for the project.
• Identify who will oversee each foreign language/country version of the site. Will local sites be managed centrally or locally?
• Will you have robust local input for each country's version of the site? Is there a dedicated staff for localization?
• Can localizing begin early in the process of developing the original site, which may be cost-effective?

Needs Analysis
To determine what kind of internationalizing is appropriate, it may help to consider:

• What needs do you have or anticipate outside your home country?
  • Is the site acquiring users or business partners outside its original country?
  • Do you already have operations in other countries (and therefore have existing resources for localization)?
  • Where are the important regions of the world for your business?
  • What are the technologies and ease of access your users have outside the host country of the site? (See the next section for elaboration on this question.)

Local Capabilities that Affect Site Content and Design
As you create a site, it helps to consider what technology users will have.

• What kinds of modems, bandwidth, and computers are users likely to have?
• What are their Internet costs likely to be?
• Consider that for most of the world:
  • 14.4 modems are at present the standard.
  • Local phone service is expensive and charged according to time used.
  • Computers outside the United States may be old and slow.
• Given these limitations, site developers should consider how to reduce the demands placed upon users' technology, including:
  • Minimizing the number of images and decorative graphic details
  • Avoiding embedding text in GIF or JPEG files
  • Eliminating or reducing other site elements that would place unnecessary burdens on the capacities of the users' technology

Site Design and Content
Globalizing the site design requires both anticipating problems with translation and browsers as well as reducing the need to alter the design for each localized version of a Web page.

• Is the page design of the source site, from which local versions are created, effectively globalized like a template -- able to be used in all versions as much as possible?
• Do the site design and layout anticipate truncation problems -- that translation from English to foreign languages typically increases text length 30 percent or more, which may shorten words in the interface? Does that anticipation include adjusting for the effects on the following?
  • Key individual words, especially dialogue boxes: The number of characters allowed for a button marked "go" is potentially inadequate for, say, French, where five characters ("allez") may be required.
  • Tables: It may be wise not to lock in table widths because long words will distort the layout.
• Will the design place significant demand on browsers? For example, if the site runs on Windows 2000, will the site design rely on frames, which places greater demand, or will it be frameless, in which case all script will be server-side Active Server Pages (ASPs)?
• Have you considered using static HTML for pages or text that do not change (or don't change often)?
• Have you avoided hard-coding in English (or whatever the originating language is), including functions such as:
  • Character typing?
  • Sorting?
  • String mapping?
• Have error messages and other composite strings been hard-coded, or are they globalized -- able to be translated separately to accommodate all languages?
• Does the site support searching? If yes, is this function globalized or hard-coded?

Avoiding Translation Processing and Other Localization Problems

• Can the site be designed to separate what needs translation from those parts of the site, especially scripting, that translators should not address?
  • This may minimize the technical expertise translators will need to have and reduce expenses.
• Can the site be configured to identify and separate language-dependent strings from code?
• Have you internationalized the site's programs, so that the code needs minimal (if any) modification, and translatable information is contained in separate files to be passed to the translator? That might include:
  • Placing translatable strings into separate files, having the code retrieve those strings as needed, and including your Web page title, description, metatags, and keywords in the translatable text files.
  • Making variable formatting language-independent, so that currencies, taxes, dates, times, message-call functions, and numbers conform to the local language or country.
  • Making sorting, searching, and all other processing language-independent.
  • Using static HTML pages whenever possible and avoiding ASP, JSP technology, or HTML with scripting (to make it easier to distinguish what needs localizing from what is functional and should not be altered).
• Are scripts retrieved from resource files according to the language needed, which may avoid problems associated with scripts that are hard-coded in the original language?
• Have you globalized all items that may have been hard-coded for the host country language -- including not only dates, time, currencies, taxes, and numbers -- but content format for the following?
  • Addresses (See the expanded checklist for e-commerce issues)
  • Font names and sizes
• To ease the changing of fonts globally, have you considered using cascading style sheets (CSS)?
• Have you established a style guide for the design of fonts and layout with non-Western characters?

More on Dates and Time

• Does the site localize the last-modified specifications for time and date? (Otherwise, a change on a U.S. page will appear a day old in Asia.)
• Has the site localized its format for date and time?
  • While Americans write the date in numbers by a month-day-year order, Europeans write day-month-year.
  • Some sites post dates using a combination of words and numbers that achieve a kind of generic compromise, such as "14-Jan-2001."

Front-End Design Issues for E-Commerce

Small decision points at the front end may make a big difference in users' abilities to navigate a site, especially where bandwidth is narrow and speed is slow. In e-commerce, you may want to consider the following.

Measurements

• How should the local site describe weight or size dimensions -- in English or metric standards?
• To do so, will it submit dimensional differences to a back-end database for translation?
• Alternately, will the site provide these differences without that load, such as a pop-up window that gives weight or size in both standards?

Currency and Transactions

• How will transactions occur? Are they able to be localized to the payment style of the country, including not simply credit cards but the following?
  • Debit cards
  • Bank-to-bank wire transfers
  • International money orders
• How will the site ensure the security of those transactions and authenticate users?
• Will the site provide an exchange-rate calculator, with which users can judge the costs in their native currencies?
• Will it subscribe to a service to provide current exchange rates on the site?
• Will the site calculate exchange rates at the time of transaction (rather than the date and time the merchant posts it)?

Address Information

• Is the space for inputting address information large enough to meet the potential expansion of translating from English to non-English characters?
• Does the address space allow for different kinds of information required for an individual country, including:
  • All numeric or combination numeric and letter postal codes?
  • Regions or provinces rather than states?
• Does it account for a different order of data required for that country?
• Does the site provide a template that accommodates variations in information and space and ensures complete address information?
• In general, does the design of the address space take into account the adequate text length for each of the following fields?
  • Country
  • City
  • State/province/region, either as one field label or as one of three labels that the user can select
  • Street/road/post-office-box lines (to accommodate street, building addresses, internal office addresses, and lengthy military addresses)
  • Postal/zip code
  • Telephone number
• Does the address page provide the ability to reject addresses if you cannot deliver to them (such as general post-office addresses)?
• Does the page validate each required field and strip non-numerical characters (parentheses, periods, or dashes) from the phone field as well?
• Does it also provide the following?
  • Selective ability not to validate a field where a country has nothing like it (For example, Hong Kong has no postal code while postal codes may be required for validation in most other countries.)
  • Ability for fields to be:
    • Masked (which forces a particular order)
    • Manipulated before sending the database the address information
    • Ordered differently