|
While the practice of web production has matured rapidly over the years, the practice of web globalization is still very much in its infancy.
Although nearly every American corporation now has a web presence, less than 15% offer more than one language. With so few examples to build upon, and few established standards, the web manager planning a multilingual site is often left with little direction and support.
Web site globalization is a complex process, and requires a significant investment of time and resources. More important, without clearly defined goals and proper planning, web globalization is easily stalled by a wide range of technical obstacles and linguistic embarrassments.
While there is no one easy solution, there are a number of "secrets" that may help you avoid some of the pitfalls of building a multilingual site. Web globalization is still very much a practice one "learns by doing".
It is our hope that the following tips, gathered from web managers who have already been there, will save you a lot of frustration and bring you closer to building a successful multilingual web site.
The most common mistake companies make when creating multilingual sites is trying to do too much too quickly.
Whether you want to add 10 pages in a dozen languages or 120 pages of one language, setting too ambitious a goal before fully understanding the many challenges involved is often a recipe for disaster.
One example: An e-commerce company wanted to add seven languages to its English site simultaneously
The company committed a substantial amount of money to creating a mirrored site in all target languages, only to discover that it had ignored the bandwidth limitations of each market. Users in several of the target countries could not easily download the graphics-rich web pages. The company was forced to rebuild customized sites geared towards each market, causing significant delays and cost overruns.
Build one language at at time
Instead of rolling out multiple languages at once, and risking problems in multiple countries, focus on one language at a time. The lessons you learn on managing the first language will save you time as you add languages.
Also, if you have a choice between beginning with a European or an Asian language, you may wish to begin with Europe. Asian languages, because they require "double-byte" character sets, present more significant technical and linguistic challenges.
Keep things simple
Attempting to add too much functionality too quickly can also lead to trouble. As a rule, companies who ease their way into web globalization are better positioned to fine-tune development as they discover what works and what doesn't work. Just as most web sites have evolved in stages, this same philosophy applies to globalization.
Develop "best practices"
Keep in mind that globalization will impact many parts of an organization. Engage all departments that are impacted by the addition of languages, such as customer service, fulfillment, finance. Create a process of feedback and refinement that all parties can benefit from. Once you do develop "best practices" for your site, adding languages becomes a manageable, scalable process.
Many organizations make it difficult for visitors to their English sites to find the multilingual equivalents.
There are a number of reasons for this. Every pixel of a web site represents valuable real estate. Providing users with a sign directing them to these multilingual sites (often called a "language gateway" or "locale gateway") cuts into this precious real estate.
Some organizations simply don't plan for language gateways. Other organizations feel it is not necessary. After all, if someone is already viewing the English version of the site, why would they need to get the Japanese version? On the web, however, people don't always use the "front door." If users can't quickly find a page (or word) that speaks their language, they will quickly move on.
Where's the front door?
With foreign sites in particular, this front door is ambiguous at best. For example, if you want to visit the Japanese Yahoo! site, you go to www.yahoo.co.jp. But if you want to visit the Japanese autobytel.com site, you go to www.autobytel-japan.com. There is simply no one standard to finding the foreign web site of an American company. Some companies register foreign domains, others do not.To make matters worse, companies sometimes fail to promote their sites in foreign markets. Advertising and search engine registration is just as important abroad as in the US, if not more so.
Assuming you do want to build a language gateway, the next question is one of selecting the correct system.
Opinions vary widely in this regard, though there are some general pros and cons to be aware of:
Avoid flags
While an array of Italian, Japanese, and French flags may seem like an easy (and colorful) solution, it often presents more problems than it solves. For example, how would you represent Spanish with one flag? And many flags could easily represent more than one language.
Use a "welcome" mat
If you're only working with a few languages, try using small GIF images of a translated word, such as "Welcome" or the name of the language itself. This is an excellent approach, but it doesn't scale well. Once you reach four languages you'll find the GIFs taking up more and more room on your site.
Let users "select" their language
A third option is to use a pull-down menu, as shown here:
Pull-down menus waste very little real estate, and they're easily scaled. The tradeoff is that the menu can only display one word until it is activated. What word should that be, and in what language? The other problem with this approach is that certain languages won't display without the correct fonts installed on the client browser.
On web sites, text is often embedded in graphics, in the form of navigation buttons, logos, banner ads. For example, here is an embedded image containing static text from ForeignExchange's web site:
Some sites embed text more frequently than others. Maintaining translated text in GIFs and JPEG files require more time and resources. This is particularly true for Asian languages, as these languages require localized versions of Photoshop and double-byte fonts.
By scaling back to a less graphics-intensive site, you accomplish two goals. You make the site load faster in the native country. You also make ongoing text management much easier.
If this means redesigning the site, the time you invest now may save you time maintaining your site.
When working with embedded text, you must also consider text expansion and contraction. English does not translate to other languages on a 1:1 ratio.
With European languages, the target text often expands by as much as 20%. Conversely, Asian target text often contracts. For example, when translating English to French, plan for a 15-20% expansion. This causes considerable problems, as shown in the following pictures:
When using embedded graphics, particularly with navigation bars, allot enough space so that the text can expand without impacting the overall design of the site.
A web site can be properly translated and still be confusing to the target market if it's not well "localized."
For example, if you translate your site into Spanish, who exactly are you trying to reach? Spaniards? Mexicans? American-based Latinos?
Localization entails tailoring the content to the specific requirements and needs of the local audience. Elements to consider include:
· currency · time and date formatting · measurements · writing style · color, image and photo selection
Translation is a complex process. Some words translate well into other languages, other words simply do not translate at all.
Brand names can be particularly troublesome. The Nova automobile is a classic example of a brand name not "traveling" well abroad. In Latin American, "nova" means "doesn't go." Americanisms and clichés also do not travel well. Examples include:
"time is on our side" · "down to the wire" · "throw caution to the wind" · "time is money"
Developing an international corporate style will save you and your translators a great deal of time and money. Not only will the copy be more consistent across languages, it will require fewer edits because many problematic issues will be avoided altogether. In general, an international style should:
· be clear and simple · when appropriate, make use of boilerplate terminology, brand names, and legal information that have been "pre-tested" for any translation/cultural problems · avoid humor · avoid analogies that don't make sense in other cultures
Before building a multilingual site, establish standards for file organization and naming. This will allow you to better manage files and images.
There is no one "best" methodology to follow; it really comes down to what works best for your organization, your web management tools, and platform. However, the following represents a fairly popular and dependable approach, particularly for organizations in the early stages of multilingual web management..
Directory names
Notice above how the language-specific pages are kept in separate directories. To manage the content (both images and HTML files), the directories are prefaced with a two-letter language code:·
ja = Japanese · fr = French · es = Spanish
This approach works well until you find yourself with Canadian French. In this case, to differentiate from European French, you simply add a two-letter country code to the prefix: "fr_CA." Organizations generally follow the naming codes established by ISO. Refer here for a complete list of country codes and language codes.
File names
Using this structure, file names can remain unchanged from their English counterparts. The danger, of course, is placing the French "about.html" in the English "about.html" directory. Some organization also impose the language preface on all file and graphic names (e.g., "fr_about.html", "ja_about.html").
As a general rule, file names for foreign web pages remain in English. This method allows you and your team to know exactly what page you're working with, even if you don't speak the language.
No matter what language you translate your site into, there is a significant number of people within the U.S. who may also want to view the site, including many people within your organization. Make sure you understand how these pages will display on English web browsers.
For languages such as Japanese, Chinese, Hebrew, and Arabic, you must have the proper fonts loaded (and possibly an enabled browser) to properly view these pages. For Western European languages, this shouldn't be a problem as English browsers share the same character set.
If you do not provide appropriate support, users (including your co-workers) may assume something is wrong with the web page, when there isn't. A nice solution is to craft a few "help" pages in English to guide users through the font downloading process. (For information on adapting English browsers for viewing Asian web sites, you can download ForeignExchange Translations' white paper, Asia and the Internet.)
Many companies localize their web sites while ignoring their email and phone support infrastructures.
It can be easy to forget that a web site speaks to the world. Occasionally, the world is going to talk back. Ideally, when a company commits to a foreign market, it commits fully - staffing up with people fluent in the appropriate languages to manage all aspects of customer service and marketing.
This includes email, phone, and web-based help. This also includes installing localized operating systems and email software for testing and communication.
Unfortunately, companies sometimes do not have the resources or foresight to commit to such an undertaking. Like most companies, they find themselves edging their way into foreign markets-localizing a web page or two, translating a few brochures. Then they find themselves reacting to customer service issues on a "crisis-by-crisis" basis.
The best way to help your organization avoid these growing pains is to plan and budget appropriately upfront. More important, be clear on your web site as to what types of support are provided and what types of support are not provided. This sort of information is not just helpful, but good business.
No matter how much you test your site, you won't know effective it is until you test it in its target locale. Some companies utilize their foreign offices to help with testing, but this is often not the best approach.
The safest approach is to use dedicated, independent testers who can view the site with various modems, browsers, and systems. ForeignExchange and a number of other web localization vendors can provide this service.
If you do outsource testing, you ensure quality and consistency in the verification process by providing a detailed test plan. This should be based on the English test plan but enhanced to account for issues specific to translation and foreign languages. An alternative approach is to make sure your vendor carefully outlines everything that is being tested, including download times.
Unicode is a "super" character set that allows for the representation of most of the world's languages. The Windows 2000 operating system uses Unicode, and most major software developers either currently support Unicode, or soon will. Current versions of Netscape Navigator as well as Internet Explorer support Unicode.
The only problem, of course, is that most of the world does not have the fonts to take full advantage of this encoding method. The Unicode standard is complex, but it is rapidly gathering popularity. If you plan on building a large, multilingual site, it's worth the time to consider Unicode, especially if your site is database driven. For more information, visit www.unicode.org.
We saved the most difficult part for last - all those pesky CGI, ASP, and other assorted scripts. They can cause real problems with a multilingual site if they contain hard-coded English text. For example, a Perl script used for form processing may be hard coded to respond to an error with an English response. Such details are often not easily discovered as scripts are often located in separate directories of the server (or on separate servers).
Never before has the "object oriented" approach to application design been more critical. Developers should to build scripts that pull text from resource files, based on the language needed. This way, there is no risk of a Japanese user being thanked in English after submitting an order.
There is a great deal of confusion among web managers facing multilingual issues, and for good reason. These issues are complicated and constantly changing.
It is our hope that you find these tips useful and that you pass them along to your colleagues. We also hope you share your secrets (and questions) with us @ webdesign@a2zglobal.com.
|
Articles
