Monday, November 13, 2006

Localisation gone bad in C#

I'm doing maintenance on a huge C# application that was developed for a swedish customer. A while ago it was decided that the application should be sold outside Sweden, and therefore it had to be localised in english, romanian, chinese, etc. The application consists of roughly 200 controls/panels and forms. It was a huge task to translate everything, and from what I now can see MS Visual Studio 2005 did not help very much (as I'm maintaining it right now).

Apparently one new thing in VS, is that you can localise each and every control/form in the designer. That is nice when you have a few forms and controls that do not use the same words all the time. The developer creates a form, changes the language property and inserts all the translated texts. It is very easy to change a word in swedish to english, and it is all GUI based. But what happens if you have 200 controls/forms that share many texts? I have not figured out how to do that in VS2005 and GUI elements.

Developers are lazy (and they should be), so they will use the easiest way out. In this case it meant that nobody cared that the same words were used in many forms. Sometimes, people missed a label here and there. And for me maintaining it, it isn't nice.

I demand these things out of a localisation framework
  • One file for each language. - VS2005 brings you one file for each language and GUI control. In the project it means 1,000 new XML files to handle. That is not good.
  • One method call to get the texts for a language. - Yes, .NET helps partly with this (I will blog another rant about this later)
  • Ability to change locale during runtime. - Yes, it is possible in .NET.
I need the following tools:
  • Tool to find duplicates so they can be erased, and defined in one place. (Think OO but with languages) - VS2005 does not help you at all.
  • Tool to spell check localisation files. Apparently there is no such tool out there. - I have not seen anything in VS2005.
  • Tool to show missing translations for a language. - Nope, the company had to build their own software to extract missing translations and merging.
So what I got was to "translate" around 200 "missing" translation in an XML file, out of them there were 50 "OK", 5 "Cancel", 10 "Index", 15 "Close", etc. I can sure tell you that it could have been very tedious, but I built a very simple tool that would go through the file, so I didn't have to bother with copying/pasting. But once again, I have to develop tools to do stuff that the IDE should have helped me with.

Side note:
They discovered a side effect of adding new languages to the project files, for every new language you had to add 200 files, this made the project bigger and bigger. Now it takes eons to compile, and one of the core developers came up with the idea to remove all localisation files from the project files. When that was done, the time to compile was drastically cut which was good. Unfortunately we we're in integration testing and could not test any of the localisation bug fixes (D'oh).

So what did they end up with when using Visual Studio and .NET?
  • Duplicated texts all over the resource files.
  • 200 new files for each language
  • Compilation time sky rocketed (I will bring stats for this later this week)
  • Developed their own tools to handle the resource files (RESX) which require maintenance, etc.
  • Forms that were not properly translated, which wasn't found out until the system test phase (or even later).
  • And lets not forget the need to update the size of every button/label to cater for romanian texts. That is also tedious and really unnecessary work.
What is the proper way to do localisation in .NET and Visual Studio? What did they do wrong? What is the easier way out?

18 comments:

Ryan Baker said...

It's hard to say for sure without seeing the code, but I'd be suspicious of the 200 form count. A number this large strongly suggests a problem in the design.

This possibility is reinforced a bit by the knowledge that there were no standard OK/Cancel/Index buttons. If there were you could have localized the text at the control level, which I think is "probably" the general solution to most of your problems, combined with some refactoring of the forms themselves to generalize them better.

Of course, I know very little about your application. There could be something really unique to your application that requires all of those forms, but from my perspective it just doesn't feel right.

Anonymous said...

One file for each language. - VS2005 brings you one file for each language and GUI control. In the project it means 1,000 new XML files to handle. That is not good.

Read up and use satellite assemblies. Then you can have as few or as many files per language as you want.

One method call to get the texts for a language. - Yes, .NET helps partly with this (I will blog another rant about this later)

I'm interested in hearing what you'll find to rant about ResourceManager? Since you merely create an instance of it, passing the name of the resource file to the constructor and it handles picking the appropriate language resource based on the locale.

# Tool to spell check localisation files. Apparently there is no such tool out there. - I have not seen anything in VS2005.
# Tool to show missing translations for a language. - Nope, the company had to build their own software to extract missing translations and merging.


There are loads of after market tools to do this. Try googling for Passolo.

# Duplicated texts all over the resource files.
# 200 new files for each language
# Compilation time sky rocketed (I will bring stats for this later this week)
# Developed their own tools to handle the resource files (RESX) which require maintenance, etc.
# Forms that were not properly translated, which wasn't found out until the system test phase (or even later).
# And lets not forget the need to update the size of every button/label to cater for romanian texts. That is also tedious and really unnecessary work.


All of the above are down to bad design decisions. The last comment about resizing for romanian could've been easily done with:
Autosize = true;
AutoSizeMode = System.Windows.Forms.AutoSizeMode.GrowAndShrink;

on each control, (It's in the layout section of the properties for each control)

ReallyEvilCanine said...

It sounds like you were trying to be too clever and coded yourself into a hole. Why aren't you using common dialogs? The language they use is determined by the OS language. You should be able to index your texts and pull them from a flat CSV or columnar translation text file.

redsolo said...

This system has been under development/release/maintenance for at least 4-5 (?) years, and they have migrated from VS, VS2003 to VS2005. That could be one cause. Refactoring is definetly needed, but WinForms haven't helped these guys out when it comes to localisation.


@ryan - They do have design problems but I don't think that 200 controls are too many for this system, since many of them are quite small and fits the system. It is "only" 100 Forms. I would rahter have more and smaller controls than bigger forms. But creating controls for OkButtons, IndexButtons shouldnt be necessary, that would really bloat this project.


@anon - Sat.asseblies, sure but how are those used from within the IDE GUI designer view? MS promotes that changing words should be done in the GUI designer. But I dont see how that is done.

Tools, thanks didnt know about that one. But shouldn't VS2005 help me instead of relying on third party companies? VS2005 is supposed to be the god-send-IDE.

AutoSize - that is .NET 2.0. This project was developed before it, and they have not updated every GUI control yet, they had other problems due to the 2005 migration. But what happens if you have a label after an autosizing button? Doesnt the button grow wider and will then be drawn on top of the label, which means that the developer has to re-arrange everything.

I don't think that 200 new resource files for each language is a design problem, because it is a fact if you have 200 controls. It is very easy to blame bad design, but good tools help developers make good design.


@ReallyEvilCanine Yes they have coded into a hornet nest, that is why i labeled my blog "gone bad". Because that is what happened, they did not try to wreck anything, it just went sour. It is more an observation that it can go very bad when localising applications in Forms. But the common dialogs are good for displaying a text, not displaying complex forms with OK/Cancel buttons and other database connections.

Graeme Bradbury said...

VS2005 doesn't say that all localization should be done via the Designer in the IDE. It's merely offered one way of doing it. It's not a great solution either, as you've pointed out.

VS2005 is not the be all and end all IDE, In much the same way as people use nAnt or MSBuild when doing build servers. When localizing applications, it's often best to go with either a custom in house solution for when your localization needs are relatively unique, or with a third party solution. Due to how specialized the knowledge is to do localization you may find that a single copy of the 3rd party solution will cost more than a single copy of the IDE you use.

The point is localization is very very difficult to do properly, and relying on wizards to do it for you will give you a working solution. However to get a solution that works and is extensible and maintainable and caters for whatever else you need, may not be possible with the wizards and hence may requires design time effort.

For example you mention that a number of controls are commonly used controls such as ok and cancel buttons etc. It would be worth creating an in house component library that contains ok button and cancel button as actual controls. These can be written to be usable from the designer and can, in effect, be pre-localized.

I like VS2005, it is a good IDE, and the time/effort saving features are great, as long as the only solution it provides is the same as the solution that fits all your needs. It is this caveat that needs to be acknowledged when using any tool. Alot of tools, and VS2005 is one, have to be used in very prescribed ways, and those ways can lead to people only seeing those solutions that the tools make obvious, or cater for, rather than the solutions that are possible.

If you have a look for a talk by Charles Petzold on "Does Visual Studio Rot the Mind", it's far more eloquent on the subject than i could be.

This comment has rambled on a bit so I'll leave it at that.

The Dot Net Preacher said...
This comment has been removed by the author.
The Dot Net Preacher said...

See here for a decent tutorial on localisation/localization in C#.

Cheers!

localization company said...

From the point of view of a localization company there is no problem with localization of 200 xml files even if 30 % of them are identical. Translation tool will translate them automaticaly.

generic viagra said...

haha that hard but good luck, well you already have luck doing that job, something similar happends to me last year, when a guy from a company watch me working with my laptop on muy company and the guy was looking what I was doing, I saw him but I keap working I didn't mind in a fex minutes the guy came to me a give me he's card and I call him a few days later, now I'm earning 15 thousand dollars working with he's company.
Thanks

www.muebles-en-torrejon-de-ardoz.com said...

Thanks so much for your post, pretty useful information.

best shop for your said...

The writer is totally fair, and there is no question.

hcg said...

Many thanks for the exciting blog posting! I really enjoyed reading it, you are a brilliant writer. I actually added your blog to my favorites and will look forward for more updates. Great Job, Keep it up.. :)

site said...

Very helpful piece of writing, much thanks for the article.

Anonymous said...

Localization in VS is a bad idea. Separate source code from transactional project is the way to go.:)
http://tbs-apps.com/lsacreator/

Ripon said...

Great post and really helpful information.

Agen Sbobet said...

Thank you for sharing to us.there are many person searching about that now they will find enough resources by your post.I would like to join your blog anyway so please continue sharing with us. Ibcbet.com Online Sbobet.com Online

Sbobet Asia said...

Its a great pleasure reading your post.Its full of information I am looking for and I love to post a comment that "The content of your post is awesome Great work. Judi Bola Online

Anonymous said...

Localization of SpellChecker in C#.NET