Globalize an existing Windows Forms application?

Question

I have an existing winforms application developed using VS 2005 and .net framework 2.0.

Now we need to globalize this application. The two locales are German and Japanese.

I know we can use form's localize property to create localized form resources and can have other resource files for strings used in message boxes, exceptions etc..

I want to know the best approach to globalize an existing application, should I set the localize property on each form or is there some tool which will extract the the label names and control names..what considerations to be taken for date formats, currency, etc.

Also we have used some composite strings in some places in code to concat the message strings, how these can be localized?

We will be migrating the application to VS 2008 and .net framework 3.5 before starting globalization activity.

Answer 1

I've only worked with LTR languages, and I haven't touched Japanese. With that in mind, here are some of my best practices off the top of my head:

• Put all language-specific programmatic strings and string fragments into a .resx file (I like to use one .resx file per dialog box), then call on the strings using the auto-generated classes and properties. There shouldn't be any language-specific strings remaining in your code (which means almost no strings in your code, period). A good pattern is to put formatting strings into the .resx as well, since the syntax of a language varies.
• Set the Localizable property to True on all your forms and make language-specific changes on there directly (use the Language property).
• Design your forms so that anything that displays language-specific strings will have extra space where needed (note: German is longer than English). IMO, forms should not have to be completely rearranged for a basic change in language -- it may have to be done with a language like Japanese, though.
• For controls such as labels that need their text dynamically set, set the text on the form so that you know it's only a marker. I use "##" for this, which really stands out. Avoid setting the text to a "sample" of the dynamic text, because you'll never remember which controls get set dynamically by just looking at the form.

Answer 2

It is better to set the localization property on each form -- that will extract not only the strings, but also the geometry of the various components, into the base .resx file. With the nominated languages, it is quite unlikely that the original sizes of the components will be a good fit for the translation.

It is generally not recommended to compose strings out of fragments because they in general will not map into the same pattern of fragments in a different language. Use of formatted strings (String.Format) to drop in values, yes, but anything that relies on the grammar and sentence order of the original language is unlikely to fit.

Answer 3

If you want the community to localize for you use an external XML file. Look at http://www.codeplex.com/url2jpeg, this open source project is localized this way and uses Reflection for automatic form localization.

For string simply use hidden label.

Answer 4

If you're using Visual Source Safe as your source control (hopefully you're not), whatever you do, do not add Japanese text inside your source code itself. Although Visual Studio can handle unicode source files, VSS does not handle them well.

I worked on an application that translated itself into Japanese, and the inclusion of Japanese within the source code itself (for calls to a MessageBox-like function) corrupted the files, and because VSS is diff-based, the files were corrupted all the way back to the original checked-in versions. This corruption took the form of most of the code files being turned into Japanese character-based gibberish, and occurred because VSS shifted portions of the unicode-based CS files (which used two bytes per character) off by one byte.

Fixing these files required a great deal of manual work, with my boss peering over my shoulder and screaming about how doomed we were, so just don't do this.

Also, here are a couple of other StackOverflow questions on this topic:

Best way to implement multi-language/globalization in large .NET project

Best practice to make a multi language application in C#/WinForms?

Personally, I prefer a simpler method. Create a list in Excel or something of every piece of English text in the application that you need to translate (control Text properties, strings to use in MessageBox functions etc.) and send the spreadsheets to your translators. In your application, call a method in the Load event of each of your forms that iterates through all the controls on the form and changes their Text properties to the translated values. Replace all calls to MessageBox with calls to an intermediate function that translates the text to be displayed, and then calls MessageBox with the translated text.

Using the built-in globalization methods is a lot of work, because you have to manually create each globalized form and then manually replace all the text with the translations, and this task pretty much requires the programmer to be fluent. The method I mention is done programatically, and doesn't require the programmer to be fluent in the translated languages.