Having recently made the move from Australia to the United States, I’m acutely aware that the world is not all the same. Even though people here speak the same language (kind of :-), there are lots of little differences in things like culture, spelling, measurement systems, and the ability to easily buy Vegemite and passionfruit. And of course, there are all sorts of places that have many, many more differences.
So given that the world is a big and diverse place, it’s no surprise that software from one country isn’t quite right in another. That’s where internationalization (also known as I18N, as it’s an I, 18 more letters, and an N) and localization (L10N for the same reason) come in. These two concepts are distinct, but complimentary. I18N is all about designing software in such a way that it will be possible to make it work well in different regions and cultures, and involves techniques such as externalizing strings, and respecting users’ settings for things like date formats and sort orders. L10N is the process of taking a piece of (hopefully internationalized) software and customizing it for a particular culture – most importantly this involves translating any text in the UI and documentation.
These days, I18N and L10N are quite rightly an integral part of almost every Microsoft product. However the patterns & practices team isn’t a product group (we build guidance) and we have nowhere near the resources of a product group (our group is about 25 people. I can assure you that Windows, Office and even Zoo Tycoon have a lot more). The fact that we are not a product group is really a good thing for a lot of reasons – for example it allows us to produce new deliverables in months instead of years. However it does mean that we can’t always do everything that we want to do – and for the moment at least, that includes localization. This doesn’t mean that we don’t understand the importance of it, and a testament to this is the fact that, starting with Enterprise Library, we have gone through the internationalization process so that at least it is possible to localize our deliverables with minimal effort.
Now here’s where I need your help. (And yes I notice the irony of writing about this topic in English when most of the people who will be most interested don’t speak English – but unfortunately it’s all I know unless you count my mediocre German. If you’re in the target audience and have made it this far, feel free to translate the blog posting to your own language 🙂
First – I’m interested in finding out whether anyone would be willing to invest the time into localizing Enterprise Library for your own culture. If anyone would like to do this, we would try to offer as much support as we can, for example supplying the original documentation files, promoting the localized version, and putting your name in lights. And of course, there’s the satisfaction of knowing you’ve done your bit to make the world a better place!
Second – even if you’re not in a position to put up your hand to do the hard yakka, I’d like to hear your perspective on what good localization would look like for a deliverable like Enterprise Library. To start with, would you even be willing to use a localized version that came out of the community? And what would be the minimal amount of localization to be valuable? The documentation and tool UI is pretty obvious. But what about the code comments? Property names and enum values in the configuration tool? Variable names in the source code?
While I’m on the topic, there’s actually a very strong parallel between the localization discussion and our support for multiple .NET languages, in particular Visual Basic .NET. Now I’m actually a VB guy from long back (I still remember how excited I was by VB 1.0!) and just like we’d love to support more human languages, we’d love to support more computer langagues too – but again we have limited resources and we need to work out how to get the most impact. While we could have converted all the source code to VB (in addition to the QuickStarts and sample code which we already do in both C# and VB), it would have come at a cost – for example Enterprise Library may have had 5 blocks and not 7. During the planning for Enterprise Library I spoke to quite a few developers (some VB, some C#, probably not many Prolog) and most people opted for the more blocks in one language option. We can discuss this decision some other time (I know not everyone agrees with it), but for now I’d like to ask the same questions I asked about localization. Does anyone want to put their hand up to port the blocks to VB (or Prolog) if we give you a bit of support? And would you be willing to use a version that someone else in the community ported?
Note that all of this is just an idea at this stage – we don’t know if it’s the right approach or what it will take to be successful. So let me know what you think!