Nine tricks for International Web Sites.
by Andrew Jones, Senior Project Manager, Rubric
Marketing wants an internationalized web site today. Sales wanted it yesterday. You just want to get it right the first time.
Global companies, and those aspiring to be, receive a lot of benefits from localizing their web sites. But if not done right a company can encounter technical problems, poor presentation, and even drive customers away if web pages render incorrectly. Let’s cover the top nine things you should worry about so you don’t have to worry about your sales and marketing teams stalking you in the corporate hallways.
#1 – Be sure about your target market
Every market has subtle nuances, and rarely does a single solution satisfy everyone. Take Portugal and Brazil. Officially, citizens of both countries speak Portuguese. But centuries of separation have caused each to develop different dialects (much as Americans speak something vaguely similar to English). If you sell into Brazil, yet localize using language and symbols for people in Portugal, you will drive away more customers as you attract.
#2 – Decide if you really need to translate your entire web site
Naturally, marketing and sales want the entire web site translated. But you know that this is costly and carries a recurring cost for every new web page and edit for years to come. So, you need to ask yourself, how important is translating your entire web site?
Often the answer is “not very”. Take Rubric’s own web site. We could have translated the entire site – after all, we do this for a living and could service ourselves cheaply and easily. But it was not necessary as our customers are primarily English speaking (at least as a second language) and are looking at our non-English pages more of a proof of capability than to get detailed information.
Ask yourself “do people in other countries really care about this?” for every section of your web. For example “do people in Germany want to read five year old press releases in our online archive?” If not, the added localization expense is money wasted.
The other way of asking the same question would be “could I use the money saved by not translating this section to create translations for even more languages?” Marketing, a group rarely impressed by anything, will be more impressed by having three additional languages available online than having five year old press releases in German.
Above all, ask yourself “how much of the content is replaced or revised frequently?” The more static the information, the less likely that it will be valuable to sales and marketing efforts, and the less likely you need to localize it.
#3 – Determine how frequently you add or changes pages
People often view web localization as a one-time event. But companies and their products are always changing. It is worth examining your change logs or content management system to see how frequently web pages change and estimate how often you will need to update your localized pages. This will lead to other decisions such as how to manage updates and how to externalize your content management system to your favorite localization vendor (which, naturally, would be Rubric).
#4 – Skip using flags for alternate pages and sites
Flags are powerful symbols. People closely identify themselves with their country’s flags. So misusing these symbols can lead to customer resentment.
One of our competitors (who we will leave nameless) uses separate British and American flags to lead people to the same web pages, which clearly used English spellings and language syntax. This gave American companies an immediate feeling that they were reviewing a far distant company, and one who made rash assumptions about Americans. Likewise, people in Austria and Switzerland will flinch when their national flag takes them to a strict German language page. Your sales and marketing folk don’t like it when you alienate their customers.
The lesson is that words are more flexible than flags, and immediately communicate what is in the target web pages, or at very least do not give a misleading impression.
#5 – Use language codes as a divider and differentiator
The Internet allows you to reach the right people in the right country, who are using the wrong language (ouch). Thankfully we have international standards to make this even more confusing.
There is a standard for abbreviating country codes (http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html) and another standard for abbreviating languages (http://www.w3.org/WAI/ER/IG/ert/iso639.htm). These can be used for creating folders/directories for storing localized content, and to advertise that you have localized content for a country or a language.
The question is which standard to use. The answer is comes from your marketing department. If your company sells in tight, geographic areas (for example, they have a lone sales office in Berlin), then use the country codes as doing so reinforces the message that “we have representation in your country”. If your products are sold on a broader scale, where a language may be used in several different countries, then use the language code. This communicates “we speak your language wherever you are”.
#6 – Use folders/directories and not file names
As we mentioned above, use baseline folders/directories for storing your localized content. For example, the Rubric web site defaults to English, and the default content appears in the “/en” directory. But if you click on the “Deutsch” link, then the content is presented from the “/de” directory.
The reason for doing this is twofold. First, it communicates to the world that you have a multi-lingual site, which tells your customers how big and important your company really is (even if it isn’t). Secondly, it simplifies content management. If you are localizing pages on a one-for-one basis, /jp/solutions.html should have the Japanese equivalent of the English /en/solutions.html. This makes handling updates and replacements a snap.
This scheme also helps make web site design a bit easier. Pages always reference other pages, and they most often do so by “indirect reference”. For example, a hyperlink in a web page on the same web site rarely, if ever, references www.YourDomain.com/good-stuff/next-page.html. It will more likely be represented as “../good-stuff/next-page.html”. This is a shortcut saying “go down one directory level, then look for a different directory called “good-stuff” and a page therein called “next-page”.
If you have generated English pages that use this relative referencing system (and most web designers prefer to do it this way), than the English pages can be localized and copied into an alternate language directory and work immediately without worrying about changing the hyperlinks (i.e., the source Japanese page will point to the target Japanese page, not the target English page). This reduces web development and rework time.
#7 – Plan for broken link fall-backs
Broken links do happen, especially when pages are in transition from one language to the next. What should you do if a German page references another German page that isn’t there?
Aside from automatic recover technology (which is beyond this discussion), you have basically three choices:
Take the viewer to the equivalent English page without warning them: This is the least desirable alternative because it makes your work and web site look incomplete. It also works on the assumption that the viewer may read English, and despite growing worldwide popularity of the language, it is far from universal.
Note that the link takes the reader to an English page: This is preferable as it warns the viewer in advance that their experience is about to change. We do this at the Rubric web site foreign language pages.
Remove the link: If you believe that either the following page has insufficient value, or if presenting an English page would be a determent to sales, then remove the link until such time as you have a localized version of the target page.
#8 – Test using a pseudo-translation before you start the real translation.
Ever cut a piece of wood and discover it is too short? Localized web sites are like that. You can start a localization effort and then discover you should have done some measurement work first.
The best way to prevent problems is to test for them, and the best way to test a web localization is to pseudo-test it first. Rubric does pseudo-translations for many of our clients web localization projects to test their web architecture. One of these clients immediately discovered two things: First, the entire site needed to be restructured as it could not support localized pages (ouch). Secondly, Rubric identified a technical workaround that allowed them to still meet their deployment schedule and postpone the complete overhaul.
The issue is managing your risk. Localizing a site is a big project, and once you commit, you are stuck with the expense of doing, and possibly redoing, the localization. Taking a moment to test your web site design assumptions using pseudo-translations is cheap insurance.
#9 – Use the right encoding.
For the uninitiated, “encoding” means how the web site’s content will be presented to the viewer. This controls many things including text flow, character sets, and more. Choose the wrong encoding scheme and your market materials will be only so much gibberish.
ANSI is the common North American encoding. ANSI extensions allow it to be used in most of Western Europe as well. But there are encodings for individual countries and languages, and there is a “universal” encoding scheme called UTF-8, which can conceivably handle most every language.
Alas, if it were only that simple.
The problem is that web browser users can define what national settings they work with. If your web site does not match the browser settings, you may encounter presentation problems. Using UTF-8 is a safe bet if you are unsure about what the likely browser nationality setting is, or if it is likely not set. Otherwise, you might opt to do what Rubric client Toshiba does and specify the most likely nationality setting for specific countries (they use Shift-JIS for their Japanese language site). Using a specific encoding will override the browser setting and – almost – guarantee the correct presentation.
Do it right or not at all
It is a big world, with lots of customers who have lots of money to spend on your products. And the web is the best and cheapest way to reach most of these people. But if you don’t watch out for these top ten web localization issues, you might do better not localizing content. After all, at least people know what they are getting when they surf to your English language site. If they see poorly rendered and presented local language content, they may be confused, offended, or simply driven away.
