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?