Internationalisation – part 1

Introduction

While I was in China recently I was struck by a lack of English (and Latin characters in general). This then raised an interesting question – why is CruiseControl.Net English only? I know some of the contributors are from non-English countries and every now and then I see e-mails from countries that use a non-Latin character set. This got me to thinking what can be done to make CruiseControl.Net more international?

Breaking Down the Puzzle

To start with, I decided the easiest approach to adding internationalisation (or internationalization depending on whether you use ’s’ or ‘z’) would be to break down CruiseControl.Net into its different components and investigate each part. A quick look at the solution for CruiseControl.Net shows the following projects (with their interactions):

CruiseControl.Net Projects

Basically this shows on the right the actual applications, and then the projects they depend on, all the way back to Remote (this is used in every project except Objection).

So, rather than try for a big bang approach I’ve decided to break up CruiseControl.Net into the following areas and do one at a time:

• Server: Console, Service and Code
• CCTray: CCTray and CCTrayLib
• Web: WebDashboard and Objection

Since Remote is a core project I will modify this before anything else.

The Approach

Each area will need a slightly different approach, but the basic approach is to remove all hard-coded user-interface strings and replace them with values from a resource file. Then it is a simple matter to add in new language resource files to display localised content.

As such I’m mainly looking at changing the output from CruiseControl.Net to allow multiple languages. While this is a major part of internationalisation I know it is not the only part. There are also issues like date and numeric formats, upper/lower casing and deciding exactly which culture to display (plus what to do if the desired culture is not available).

Additionally I’m going to add a couple of extra limitations:

• A CruiseControl.Net instance will only be for one culture (e.g. any CruiseControl.Net instance will only have one language – it won’t be able to handle multiple languages for one installation).
• Configuration will still be in English. I know this is a biggie, but I have no idea how to even start handling multiple languages for the configuration (especially with Exortech.NetReflector in the picture). Perhaps someone else would like to handle this issue

This will probably be a slow process of migrating all the hard-coded strings to resource-based strings, plus of course continuing to maintain the language resources in the future. But it will open up CruiseControl.Net to more people in the future.

More to come…