Let’s look at Windows Forms localization for a minute. MSDN has a good section about Developing World Ready Applications, including how to get avoid globalization & localizability issues, how to get your code localizable, what tools are provided etc. I’m not trying to repeat what’s in there – if you haven’t read it yet, spend a day or two in there before you come back.
As MSDN states, there are two ways you can localize Windows Forms using the tools included in Visual Studio/.NET Framework SDK. What’s common for each is that you start by opening the form you want to localize in Visual Studio and set the Localizable property to True. After that, one method to localize the form is to simply set the language you want to localize into and start changing properties. The other way is to open the resx file for the form in winres.exe. (There’s a third way too – “pre-size” all dialogs so any language will fit, and then only allow the translators to translate text. This is a horrible idea though, don’t do this if you’re serious about delivering international software.)
What’s really important here is that, once you pick one way, you can’t easily switch to the other. The reason for this is that the resx schema used by Visual Studio for localized forms differs from the schema used in winres.
So which one do you pick? In my oh-so-personal opinion, winres is the way to go, for several reasons – ranging from how you might not want to spread your source code around, to how much harder loc kit maintenance becomes with higher file count & more complex setup, to the fact that Visual Studio costs money but winres is included in the .NET Framework SDK which anyone can download.
Whichever tool you chose though, remember that this is a case where you really want to make the right decision, and early. You don’t want to get stuck half-way trying to switch from one tool to another.
So, now you’ve picked one tool or the other. That’s it, you’re ready to go? Well…. your localizers can translate and resize dialog boxes, there are still a lot of things left to solve. Such as –
- How will you make sure that your application is localizable and that all globalization issues have been resolved? And how will the localizers communicate back any issues they come across?
- When do you start localization? Too soon, and you’ll waste resources translating stuff that’s still changing; too late, and you’re bound to encounter loads of localizability issues that you won’t have time to fix. Will all languages start at the same time, will everyone localize all features? Do you try to document and translate new terminology up front? Will help files be localized separately, and if so how do make sure they’re consistent with the software?
- How will the localizers translate other resources, such as error messages, bitmaps and icons? Translating resx files in notepad isn’t ideal.
- If you have more than one localizer per language, how will they manage glossaries and terminology? Getting consistency in style and terminology in a large project is a challenge (even for a single localizer).
- How will translations be recycled? Very few products come without repeated strings and there’s no reason to translate “Browse”, “Cancel” and “Click next to continue” more than once. Remember that Microsoft provides glossaries that you can use for reference.
- How can you and your localizers know when they’re done? You probably want a way to measure what’s left to translate and which dialogs are yet to be resized, but you also want to know what types of quality checks (linguistic and others) need to be performed, how they’ll be performed and how results will be tracked. If you don’t, you can accidentally release text bits that haven’t been translated or spellchecked. Embarrassing.
- How will localizers get context information from developers? If I don’t know how a string is used, I can’t know that I’m coming up with the right translation. Is “Display” a verb or a noun? Is “Second” number two, or is it a 60th of a minute? Is “Enabled” plural or singular? And once the meaning of a string is clarified, how is this communicated back to all languages?
- If localization starts while the product is still under development, how will the localizers’ work be merged when updated resources are made available? If you’re using a mix of in-house localization and outsourced work, how will you sort out file management?
- How will the localized products be built and tested, and how will builds be made available to the localizers?
…and more… None of these are easily answered, but hopefully I can give some tips in upcoming posts…