Sniff your web
Before you publish any web content in a fancy character set, be sure to sniff your web. No, it shouldn't smell. Sniff for your web server's HTTP response header.The problemIf there is a clash between the HTTP header and the character set of the page you are publishing, most browsers will try to render the page according to the HTTP header. The result can be gibberish.
Here for example is a Japanese page, encoded in UTF-8, being delivered by a server that claims it is encoded in ISO-8859-1, the encoding for standard Western European languages. Not a pretty site!
We were hoping to see something like this. What happened?BackgroundWhen a browser renders a web page, it needs to know what character set the page is encoded in. There are three ways it can find out:- Read the META tag in the header of the file,
- study the text on the page and guess, or
- read the web server's HTTP response header.
Before going any further, let's be clear: the file header mentioned in method 1 is the stuff between the <HEAD> and </HEAD> tag at the beginning of an HTML file. The HTTP response header of method 3 is the data that the server sends to your browser before it begins to send the HTML file. You can't see it without the aid of a web sniffer.Method 3 is the least widely known and the most powerful. It's the gotcha method. The <META> tag of the first method is the most popular, with good reason, because it allows you to specify (and change) your encoding from one file to the next. Here is the meta tag for UTF-8:<meta http-equiv="Content-Type" content="text/html;charset=utf-8">I copied this tag from the header of the Japanese page above. Unfortunately, its server was singing a different tune.Web sniffing
Here's where web sniffing comes in. Got to http://www.web-sniffer.net, enter the URL of the website you are sniffing, and look at the results...
The culprit is in the last line: "charset=ISO-8859-1". That's a direct conflict with the UTF-8 encoding that we actually intended. SolutionShould you run down the hall to tell your webmaster to change the HTTP header to your new encoding? No! To do so would render your pages correctly while breaking those of everyone else.If your webmaster is extremely kind and patient (possibly True) and has a lot of extra time (definitely False), you could ask him or her to set a special encoding for your folders. But why bother. The easier and better practice is not to specify any charset at all in the HTTP header. It should say simply "text/html", so that the encoding of each page can vary according to the capricho of its author.
Ditch the RFP, and other translation outsourcing tips
A lot of people who need to buy a website translation have never bought one before. If you fall in this category, read this posting. It includes advice that can make you a tougher and more informed buyer, written by someone (me) who has written or reviewed more than 1,600 translation proposals over the last few years.- Insist on an itemized quote. Ask each potential vendor to itemize and price every service that they will deliver. You should be satisfied that you really understand what your are buying, and what factors affect each line item. For example, some services are priced according to the word count while others vary according to the technology that your website uses.
- Understand the word count. The basic variable in a website translation proposal is, or should be, the word count. It takes time to translate words carefully. One way or the other, you're going to have to pay for that time. But you shouldn't have to pay as much to translate repeated strings of text -- a very common characteristic of websites. In a transparently written proposal, both the raw word count and the corrected word count after subtracting some portion of the repetitions will be clearly displayed.
Once you understand the word count, insist that if the word count of your project varies between the bidding and production phases, that the final price vary proportionately, either up or down.
- Negotiate your maintenance agreement up front. Maintaining a multilingual website can cost more than translating it in the first place. If you plan to maintain your site for the long haul, be sure to discuss the options and negotiate the price up front while you still have the negotiating leverage. A common pricing strategy (to use a euphemism for "trick"), is to buy your account by under bidding on the initial project, then ratcheting up the fees later when you are locked in.
- Don't get locked in. Speaking of which, you should be aware of two fundamental ways that a translation service provider can gain leverage as your incumbent. Both strategies are not adversarial tricks. On the contrary, when used with your interests in mind, they can be beneficial to you.
The first power factor in the client-incumbent relationship is translation memory (TM), a software technology that sophisticated translators use to remember and reuse everything that they translated for you. If your website contains a lot of repeated descriptions of similar products and such, then with time, your incumbent translator will gain a pricing advantage over all other competitors, making it prohibitively expensive for you to change. If the pricing advantage is passed on to you, then fine, but if it is used to increase your vendor's profit margin and tactical pricing ability, then you lose. The solution? I'll discuss it in a separate posting.
The second power factor is any kind of multilingual content management software that the vendor sells and installs on your server. These systems are also known as global management systems, GMS. Granted, certain sections of most websites can benefit from structured, multilingual content management. But not all of the content on all websites, and not if the license costs all of the money in the world. The downside to these systems, in addition to their cost and complexity, is the leverage that they give to the system vendor.
- Ask for the name of, and interview, your project manager. Your most contact at the vendor is the project manager that they assign to your account. If you are being sold by an account representative, respect the work that he or she is doing for you during the selling process, but ask to speak to the project manager. The P.M. will take the reins, build your project team, set the calendar, handle your inevitable change order requests, manage the quality control process and all the file transfers. If you like the qualifications, profile, experience and personality of the designated project manager, you will be in good hands.
- Ask for the names, resumes and work locations of your linguists. Most translation vendors justifiably make a lot of noise about using native, professional linguists who are resident in the target language country. They may also claim to use more than just a single translator, and thusly to differentiate themselves as an agency from a less expensive freelance translator.
Linguists are the heart and quality of the service that you are purchasing. So it makes sense to have the vendors show you the résumés of your linguists. They should also be able show that your documents have been edited, reviewed or proofread by someone in addition to the original translator -- if that is what they claim to do.
- Compare apples to apples. Price and service comparisons for a complex solution have to be compared with care. A website translation can range greatly in completeness, or lack of it. At one extreme are the agencies that simply translate a Word document for you and leave it to you to paste the translation into your HTML code, database or whatever. At the other extreme are agencies (like mine) that offer a lot of very helpful consulting during the planning phase, work on a turnkey basis with native assets and do a conscientious and systematic job of quality control. The price for a complete service can be higher while the true cost to you is significantly lower.
- Ditch the RFP. Last but not least, if you are about to write a Request for Proposal (RFP), think the better of it. Did you know that less than 10% of all RFPs for website translations result in actual projects? The very fact that someone in your organization is asking for an RFP should be a warning to you that the project is going to be studied and tabled, forever. Save yourself the trouble. If you are forced to write an RFP, let me know; I could be persuaded to blog about what every RFP should and should not contain.
ClearType reduces eye fatigue
Ten years ago, in the epoch of flickering 640 x 480 screens, conscientious proofreaders would print out their texts and work on paper. Errors that were invisible on the screen seemed to jump out from the page. But printing involved an extra step. It was tempting to be lazy.Now, screens have improved. Most people review text on the screen directly to save time and benefit from improved tools for spell checking, revision tracking, glossaries and so on. But eye fatigue is still a factor, and may have suddenly worsened thanks to flat LCD screens, which sharpen the edges around each pixel and render type with a choppier look than did the old CRT screens.To solve all that, Microsoft has released a great little tool especially useful for flat screens, the ClearType Tuner. According to the download page: "This PowerToy lets you use ClearType technology to make it easier to read text on your screen, and installs in the Control Panel for easy access." (Windows XP only.)Give it a try. The result is frankly luxurious, a whole lot easier on the eyes. You'll feel like you paid an extra couple of hundred bucks for your display.
Here's an example with ClearType on the left and standard type on the right.
