 |
|||||
 |
|||||
 |
WELCOME TO THE RUBRIC NEWSLETTERWelcome to the final 2004 edition of Rubric's newsletter, providing business and technical insights into your localization processes. As always, we encourage you to forward this newsletter to anyone interested in localization topics. If you are receiving this newsletter from a friend, feel free to subscribe to our newsletter and receive your copy as soon as it is published.In This Issue:
|
|
|
||
|
|
RUBRIC NEWS: Recent news about Rubric and our customers.
BUSINESS—Start Before Localizing: The one best secret to minimizing your localization cost while maximizing your customer's satisfaction may not be in localizations, but in your source text. We'll show you how it works and how big the payoff can be. TECHNICAL—Nine Tricks for International Web Sites: Nine simple tactics can make your multi-lingual web site work right the first time, and avoid draining your maintenance budget down the road. |
|
||
|
RUBRIC NEWS
START BEFORE LOCALIZINGby Ian Henderson, CEO, Rubric | |
|||
|
There are hundreds, if not thousands, of ways to reduce your localization costs. We know because Rubric advises our customers about every savings tactic we discover. But there is one tactic you can take before calling Rubric that will greatly reduce your localization costs.
And it is in your hands right now—your original source text. SimplificationMost text in software, documents, or on web sites is fairly well written providing it is read only by people who speak the same language as the writer (and for the balance of this article, we will assume English as the source language in examples). This "readability" factor exists because regional and language-specific syntax, synonyms, and other constructs are common to both the writer and the reader. |
|
| ||
|
Not so with translated materials. Each word must be translated, and nuances require the translator to interpret the intent of the writer and the meaning of the passage. The more text and the more variation, the more work there is for the translator. The big secret is very simple: rewrite your source text. The very first thing you should do is to revise your source text to make it as simple and consistent as possible. When revising, look for the following opportunities: Revise flowery copy: Writers love to write, and often use 1,000 words when one would do. Revising not only reduces your total word count and the cost of subsequent translations, it makes the text more understandable by using simpler statements. Look for and remove variations: If there is more than one term or phrase describing the same thing, pick the best and replace the rest.
Unintended benefitsGranted, the cost benefits of simplification are enough to justify revising your source materials before localization, but there are side benefits that make it an even better tactic.Simplified for local users: Simplifying your English makes life better for your English-speaking customers. Not only have you reduced all the words they have to read, you have made your products more consistent and simpler to use. Improved understanding: Your customers, tech support staff, and sales teams benefit as well since they all now use the same words and phrases to describe your products and what they do. Redeploy budget: Money saved in reduced text (lower localization costs, lower printing charges, etc.) can be used elsewhere to improve products or just add to the bottom line. A real life example One of Rubric's customers came to us with a user interface (UI) localization project. With all tools, screens and online help text, their total word count was in excess of 150,000 words. Not a huge project for Rubric, but one that caught our attention for other reasons. We immediately noticed that the English source text was at times verbose, bordering on poetic. Key terms describing product functions were expressed four different ways. And there was a lot of redundant text that did little to expand their customers' understanding. We advised this client to allow Rubric to rewrite the English source before it was localized into four languages. At first the client demurred, but when we showed them examples of some of the offending text, they relented. The rewrites went quickly in the hands of our expert translators, making the text more readily understood by the translators who would perform the final localizations. The end result was a svelte UI file with a mere 96,000 words, or a 36% reduction in source text. Think about what you pay per word for translations, multiply that by 54,000, then multiply again by four target languages. The number you just calculated was our client's first-edition savings for their product, a savings that has repeated several times as new revisions have been released. Simpler is better Your first step should be to review any text you may need to localize in the near future. Scan it to see if anything seems wordy, redundant or if terms and phrases are not uniform throughout. If you get through a tenth of the text and begin to have doubts, it is time to simplify. |
|
|||
|
NINE TRICKS FOR INTERNATIONAL WEB SITESby 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 localization is 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 as many 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 editorial change 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 as 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 (whom we will leave nameless) uses separate British and American flags to lead people to the same web pages, which clearly use 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 the 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 an ISO standard for abbreviating country codes and another different standard for abbreviating language names. 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 should come 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 to reinforce the message that "we have representation in your country." If your products are sold on a broader scale, where one 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 to 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), then 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 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 detriment 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 was cut 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 our clients immediately discovered two things after pseudo-translating their site: 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's browser. 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 (no jokes about marketing gibberish necessary here). 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 want their browsers to use. 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 nine 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, and simply driven away. |
|
|||
 | |||||
