Localization anyone?


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!

This posting is provided “AS IS” with no warranties, and confers no rights.


Comments (7)
  1. kazamachi says:

    Yes. I desire the localization.

    I live in Japanese. Many people understand Japanese. But difficuly for their understood english. And I’m working the localization from English to Japanese. But… SR.CS is InvaliantCulture only. Is this bug? or design?

  2. Tom says:

    Yes I believe this is a bug. You can either update the Resources.cs files to return CurrentUICulture, or update the SR.Strings files, changing

    #! culture_info = Resources.CultureInfo

    to

    #! culture_info = CultureInfo.CurrentUICulture

  3. Tom says:

    Sorry just realized that my second suggestion is really only useful if you have the StringResourceTool which we still haven’t released (we are going to do this, but it needs some work and we’re a bit resource constrained at the moment). So the first suggestion is probably the easiest one.

  4. Luis Gizirian says:

    I’ve already posted a thread on this I18N on GotDotNet.

    I think that there are many things that can be extended by the community of developers. I know that the open source model (through different licences) has been successful for many kind of projects for many different platforms, even MS has already made an approach on this (I think is a project related to MSI but honestly I don’t remember). The real thing is that every project that takes this path, has to have a strong project management planning and people, which you can provide with no problems I think.

    Maybe rethinking the code-contribution mechanics of the EntLib’s project is what we really need.

    So, I’m preety goin’ off-topic here, but as you comment, there are and there will be many more issues like I18N, L10N and Language implementation that will have to get done somehow.

    Thanks.

  5. I am working now in a large enterprise project that is going to make use of Enterprise Library. I am allready "tweaking" EntLib to fit the project needs (Adding digital signature to config files)

    I also thought about localized it and then I read your post. 🙂

    So I’ll do it and i’ll appriciate the help.

    Ido

  6. I am working now in a large enterprise project that is going to make use of Enterprise Library. I am allready "tweaking" EntLib to fit the project needs (Adding digital signature to config files) I also thought about localized it and then I read your post. 🙂 So I’ll do it and i’ll appriciate the help.

    Ido

  7. Peter Mounce says:

    Luis – what is the open source approach? I have looked at using gettext with C#/.NET support (0.14.1) but am having trouble compiling the GNU.Gettext .NET library under cygwin, and the documentation for "Woe32" is a bit lacking when it comes to trouble-shooting.

    This is a pity, since it seems like that, combined with poedit (poedit.org) for translating the strings and compiling those to dlls, is quite an elegant and translator-friendly solution. I’ve _seen_ it working on other projects, but not .NET ones…

Comments are closed.

Skip to main content