How localization engineers could help translators

When you translate software strings from English into another language, you sometimes wish you had more information available.

Often localization engineers, the people who prepare strings for translation, work for a software company that then outsources the translation to an agency. The localization engineer in company A talks with a project manager in agency B, who, in turn, deals with various freelancers (or even single-language vendors). The chain of intermediaries can quickly get too long. Answers to questions sent up the chain take forever, and suggestions or remarks by translators are lost on their way to the client.

Localization engineers usually have great technical skills. However, since they don’t translate themselves, they sometimes don't know what would help translators and what would hinder them.

Localization engineers (and project managers) could help translators improve the quality of the localized software by a few simple actions:

• Provide an easy way for translators to send their queries and remarks;
• Provide explanations and definitions;
• Indicate how much space is available for each translated string;
• Provide a glossary of required and forbidden terminology;
• Give translators the whole translation memory (not only an extract): a complete translation memory allows translators to perform context searches, and helps ensure translation is consistent;
• Provide screenshots, or make resources available to see the strings in context;
• Do not provide the strings in alphabetical order (as I often see): that may look more orderly, but also deprives translators of much needed context.

This is just a partial list: a few thoughts that came to mind while working on a badly organized project, a few weeks ago.

An interesting new blog on localization: Localization Best Practices

David Ashton works for SDL, but his new blog, Localization Best Practices, is an independent effort.

David's blog looks and feels professional, and has already published several interesting posts. In particular, I found "How healthy is your localization partner’s supply-chain?" should be required reading for most buyers of translation services, and "The case for and against direct update of TM’s by translators" should be pondered by the clients and MLVs that are all too ready to unleash a scrum of translators all on the same project and on the same memory:

Translators are only human and errors are introduced by human translators every day… that's why we have Quality Assurance processes in the first place! Auto-propagating translations pre-QA carries a tremendous risk

Many translation blogs start with tentative steps, unsure of where they are going, only to find their feet with practice and time. David, on the other hand, hit the ground running.

Why this love affair with Notepad?

I'm doing an on-site linguistic QA of some complex software. This is often frustrating: programs that don't work, crash, get disconnected. These annoyances come with the job: you wouldn't QA software already in perfect shape (during linguistic testing, we often discover many functional bugs).

One thing that particularly exasperates me, however, is the program supplied for accessing some of the reference material. The references are a set of tab-delimited files. We search in these files when we find a problem in the localized interface: inconsistent translation, mistranslation, etc. Unfortunately, the tool used by this (major) translation company is Notepad: with it, we are supposed to search within the files, identify all the relevant strings, and copy them to a bug-tracking database. To search multiple files, we would open several different instances of Notepad, one for each file. To identify multiple strings or substrings, in Notepad there is no other way but to search, find the first occurrence of a string, and search again, until we get to the end of the file.

Searching in Notepad

Notepad is not suitable for this: more specialized tools are much better. I would suggest Funduc's Search & Replace or ApSic's XBench: they allow searching on all files at once, display all the hits at the same time (in a more legible way), and permit more sophisticated searches, with regular expressions (Search & Replace) or with the "Power Search" feature of XBench. (In fact, with the test lead permission I at once installed XBench and started working with it).

Searching in S&R and in XBench

In many QA projects, editing is part of the job. Again, Notepad is often the program provided: using a text editor ensures that no extraneous elements are surreptitiously added to the text file (as would happen easily, with a word processor such as MS Word). The disadvantage is that Notepad offers no good search functions, no syntax highlighting, no code folding, and so on.

Editing html code in Notepad

Even if the translation company doesn't want to provide Ultra Edit or other high-end text editors (because of the cost involved, or the steeper learning curve), there are many excellent free text editors. For such tasks, for example, I use Notepad++.

Editing html code in Notepad++

(The search examples above are all performed on Microsoft glossary files; the html code is from our own web site. By double-clicking on the images you should be able to see a more detailed version of them)

Localizable resources

Dr.Dobbs has a fairly interesting article on the use of page resources for the localization of web sites.

Page resources are literals stored in an application-specific assembly and bound to a culture identifier.

Fairly technical, but of interest for those of us who translate, localize or build multilingual web sites.

Things to pay attention to when localizing a web site

(From BtoBOnline.com)

According to this article, "localizing your Web site for international users requires more than hurdling a few language barriers".

The article describes many things to be considered and difficulties to be overcome for those who plan to have an international version of their web site.

While it concentrates on issues other than translation, I think this could be very useful to translators who are asked to quote for the localization of a web site: it gives us other factors to mention to our prospect, from planning for non-broadband connections to getting a local URL for the international site.

Website Localization

ISEdb.com published a couple of days ago a very interesting and detailed article ("Translating Web Sites Considerations for Multilingual Online Businesses") on what to consider when deciding whether and how to translate a business web site.

There are a few things I disagree with, for instance

"If at all possible, if your company employs local salespeople or marketing staff in that country then you might consider having them write or translate the copy on the web site—they know the product and any important selling points and local “slang” that is important to include."

Local salespeople or marketing staff should certainly be more knowledgeable about the products they are selling, and possibly may be more up to date with their industry's jargon than us mere translators... but they are not translators, and I have seen time and again that translations done by non-professionals very quickly run into serious problems.

Much better is when translations are entrusted to qualified professional translators, and the in country technical and marketing staff freely support the translation team(s), answering their questions and checking the draft translations.

But other than that, the article is very informative, and could be a valuable resource when advising a customer what to do when localizing a web site.
(Hat tip: iSpeak blog)

Tags: localization

Global Content Management

EContent published a few days ago an interesting article on Global Content Management. Among the highlights of the articles are sound suggestions such as

First and foremost, you must learn to write for translation, which means to write simply, clearly and, above all, to write for reuse.

There are also links to useful sites; for instance after suggesting the above, it links to the home page for Simplified Technical English, where one should be able to find help and guidelines for clear writing.

The article continues with more useful information on translation software (both TM and MT), XML, and other related products.

Although the article is clearly not aimed at translators, but at the users of translation, localization, and allied services, it should also be of interest to most translators.