Oskar Johansson asked in a forum a Swedish community web site (http://www.pellesoft.se/communicate/forum/view.aspx?msgid=161248&forumid=134&sum=0) how we localize. The question was roughly:
What is the current translation model? Are all localizable strings in their own .h/.c files?
Rather than answering in the forum, I figured I’d respond here. I like Pellesoft very much and appreciate the feedback we get there, but since this is a general question, I figured it makes sense to write an answer in English & post it here.
In Windows localization, we hardly need to touch any compile-time files. We work almost exclusively with compiled files or files that don’t need compilation – INF files, XML files, HTML files etc. There are a few exceptions still, but the list of exceptions gets smaller for each new version.
Working with no-compile files brings a lot of benefit. It’s far easier to break the application if non-localizable stuff, such as code, is exposed to localization. Ideally, the localizer should only see things that can be localized, and all things that should be localized can be seen by the localizer.
When we localize a product, we use an internal localization tool that can scan binaries such as DLLs, MSIs, EXEs and extract all localizable data into a database. The tool supports almost all types of files we see – 32 or 64 bit; Win16, Win32 or managed; text and binaries. We then localize the product inside the tool.
At some time we hand off to get a localized build. The localization tool then takes our now translated databases and reverses the process to create localized binary (or text) files. That’s what goes into the build. One of the nifty features with our localization tool is that I can generate my own localized files whenever I feel like it. That means that even between builds – maybe when I’m bug fixing or wonder how a dialog is used at runtime – I can replace the file on my test machine with a version of it that I generated myself. This is a very handy technique to quickly check something.
Conceptually, this is very similar to how winres works. Only the tool we use covers more than just managed code, and more than just UI.
A few more questions were asked, I’ll try to answer them next week. If there’s anything around localization in general or who we localize Windows that you’d like me to talk about, please let me know.
This posting is provided “AS IS” with no warranties, and confers no rights.