Wordcount Woes - Part 3

How about those engineers who are certain that all of the strings have been externalized from the code?

I don't know about you, but I stopped believing them a long time ago.

Pseudo-translating the code is the definitive way of showing them the strings they've missed. It requires a bit of time and, frankly, some cooperation from the very engineers you're about to embarrass, but it's the sure way to find strings still embedded in code.

Many engineers overlook the installer, also. There is usually a script or value-pair file with custom strings, and it's easy to forget to externalize strings to the file. It's also easy to specify the wrong encoding for the file, such that all of the custom strings show up corrupted in the installer. We see that a lot with InstallShield projects.

Mind you, I'm never out to get the engineers - I need them too dearly - but they sometimes get to believing their own stuff and thinking that internationalization (I18n) is kaltes Kaffee, or yesterday's news. It is yesterday's news, but that doesn't mean it's unimportant.

Where do you find strings that engineers overlook?

Note: I've posted less frequently of late because I'm between projects (and setting up another blog). Once L1on activity resumes with a couple of clients, I'll have more war stories again.

Wordcount Woes - Part 2

If you're working client-side, how many words have you paid for that translators didn't even need to touch?

I posted a couple of weeks ago on translatable words that vendors may miss in analyzing files. Alert reader arithmandar commented that slide decks can be even worse, if there is a lot of verbiage on the master slide that does not get easily captured (although Trados finds these words, according to him/her). Flash is another story altogether, and arithmandar's recommendation is that a Flash engineer should probably perform the analysis.

The other side of the coin is also unpleasant, but for the other party: Clients can hand off vast expanses of words that nobody will translate, artificially inflating the wordcount and estimate.

• Code samples - If your documentation contains examples of code used in your product (e.g., in an API reference), there is no point in having that included in the wordcount, because nobody translates code.
  
• XML/HTML/DITA/Doxygen tags - I hope your vendor is parsing these files to ignore text (especially href text) in the tags. Otherwise, not only will you get back pages that won't work worth a darn, but you'll also be charged for the words.
  
• Legal language - Some companies want their license agreements, trademark/copyright statements, and other legal pages left untranslated. (Usually these are American companies.)
  
• Directives - Certain directives and warnings apply to certain countries only. The documentation for computer monitors and medical devices often contains a few pages of such directives, which appear in the language of the country requiring them. There is usually set language for these directives, so free translation is not appreciated; have your colleagues in Compliance obtain the language for you, paste it in yourself, and point it out to your vendor.
  

Mind you, there are costs associated with finding and removing all of these words: Do you want to spend time extracting the words? Do you want to hire somebody to find and extract them? Will your savings offset those costs?

If the words to be ignored add up to enough money - as they often do for a couple of our clients - pull them all into a text file and send them to your vendor with instructions to align them against themselves for all languages in the translation memory database. That way, when the vendor analyzes your files, the untranslatable words will fall out at 100% matches.

Do you have ideas on how to handle such text?