Re: ANON: Translations, Software, and Value of Resource Files

[Tom Brophy <tom -at- TCRAFT -dot- COM>]

Hi,

> [snip] One of our developers located some software that
> can go through the VB code, extract all screen labels (text) and
> put them in a file you can send to your translation agency.
>
> I'm sure there are many such label extraction/exchange programs. I got
> a bit suspicious when he started crowing about it costing only $150.
> My observation is that many development tools cost quite a bit
> more than that. He claimed he had tested it and it worked just
> fine.

I believe the product was VB Language Manager (VBLM) from WhippleWare. I used a version of the product some time ago, and while my memory of it is hazy, I do recall that it gave you a fair degree of control over what strings it extracted. The price of a development tool doesn't necessarily reflect its level of suitability to the task for which it was designed.

> We extracted the labels from our client applications, sent
> the language files to a translation agency, and got them back
> on schedule. When our developers tried to use the label exchange
> to put the French labels in, the software wouldn't compile. On
> examination they determined  that WhippleWare (the extraction
> program) extracted elements it should not, such as function names,
> arguments, and so on. On further examination they determined
> that it missed about 20% of all labels it should have extracted.

The level of freedom a developer has in how s/he can implement a feature in a given programming language means that you will always need some human involvement in the process of analysing what needs to be localized. As I recall, VBLM does allow you to mark strings which it has extracted as being non-translatable. To expect that VBLM will read your project and correctly identify just the localizable strings without some input from your engineers is unrealistic.

> It will now take four developers three weeks each to fix the 
> software so it can compile and have all the correct labels in 
> French. This does not include rush service from our agency to 
> translate the remaining 20% of the labels we didn't catch in 
> the automated extraction.

How large is the application? I have engineered several localized VB applications, but I have never seen an application which would require 12 man weeks to engineer!

> We have determined that for future releases we will put all labels
> in a resource file. 
[snip]
> If you are in a project where the software needs to be translated, 
> I recommend putting all the labels in a resource file rather than 
> relying on a label extraction/exchange application.

The resource file (.RC) format supported by VB is not complete. It does not support menu resources, for example. You can get around this by creating application menus dynamically at runtime from stringtable entries, but it will require substantial code changes.

A better solution is to hand off your VB project to a localization vendor with inhouse engineering expertise. Such vendors will typically have their own tools to extract the localizable strings from the project and should be able to fix any over/under-translation issues that arise. The engineers will be able to provide context information to the translators if they can see how a string is used, which allows the translators to provide the best translation.

Cheers,
Tom

// Tom Brophy,                                  Email: tom -at- tcraft -dot- com
// Translation Craft, 19A Main Street, Blackrock, Co. Dublin, Ireland
// Phone:+353 1 2836336;  Mobile:+353 86 8295856;  Fax:+353 1 2783572


 From ??? -at- ??? Sun Jan 00 00:00:00 0000