Monday, January 28, 2008

Visual Studio for Internationalization and Localization

Every new platform, every not mature platform has common set of problems and one of this problems are probably will be Internationalization (I18N) and Localization support. For big part of development world it's not problem - if you are write solely for your country or you speak in English - and so you may be never think about it. But if you speak in different language and think of broader market for your product - or just want to create UI in the same terms as domain model - I18N is your headache.

So if you think that Visual Studio is mature product - you are wrong - every mature development product must know of Localization problems and give you full set of tools to do it.

Localize Forms

Ok, Visual Studio Forms Designer give your ability to localize forms - it's good enough.

Just

  1. Set Form's (or Control) Localizable property to True
  2. Choose your language in Language property
  3. And in the form's design view translate all that your need.

loc1

And that's all - good.

 

But designed controls are not all strings in UI interactions. When you show messages to user or create control dynamic you also need localize UI.

How? By extract strings to resource (the same as Form Designer do for forms).

For instance - all major java IDE has ability for this:

Eclipse:loc2

IntelliJ IDEA: http://www.jetbrains.com/idea/features/i18n_support.html

 

But not Visual Studio!

With visual studio you don't have way to externalize your string to resources without many manual work... to present day.

Now we have two very good add-ins for it.

Resource Refactoring Tool

Resource Refactoring Tool is a free add-in for Visual Studio that gives your ability to extract hard-coded strings to resource.

Select text, from context menu select Refactor->Extract to Resource (or use Ctrl-R, Ctrl-X shortcut):

RefactoringTool-Menu

Than select resource file where you want to extract and refactor parameters:

RefactoringTool-Window

So then you must copy your resource file to resource file for localization - for instance if you have Resources.resx you need to make copy with name Resources.ru.resx (where ru - is your language postfix - de, pl n etc.).

loc3

And then in Resources.ru.resx translate parameters to needed parameters.

 loc4

Good enough.

One problem is that when you extract string to resource and you already have localized version of that resource - you must manually create new variable in localized file. For example with IDEA you don't need to do this:

resource_bundle_editor

safedevelop's RGreatEx

loc6

Another tool for that is Commercial plugin for other great development tool - Resharper (plugin for VS) - RGreatEx (30 Euros per license).

Why You need to buy commercial tool (and moreover - plugin for plugin) instead using free? I can't answer clearly - if you use Resharper or something like IDEA and understand how it sometimes differs (in a good sense) from other tools - you must try it. The bad thing about that for today it don't support latest Resharper and Visual Studio 2008 - I expect to update this post when it will be released.

Tuesday, January 8, 2008

No more next big language?

Ola Bini, one of JRuby tam member brings us his vision of Future programming. He follows the idea of polyglot programming, that's not so far advocated by Martin Fowler. Good resume about it on InfoQ.

I agree with all of this, but there are some doubts about it on the blogosphere:

What difference with C? When you use pretty old Python or Ruby or Perl you can use C libraries.

I thought that this connection directed - no use Perl code by C programmers. And you know, Python, Ruby, Perl are very good languages with a lot of applications... but it have never been widely adopted by "enterprise".

Programmatically, Jython, JRuby, (and Hecl?:-) may even find it easier to interact on the same platform, but the humans writing the code will still push for consistency and the minimum set of common tools in order to aid the sharing and review of code. (David Welton)

imageYes, it's true - it's why I think a bit different from Ola. I think his approach not real from today life with all of that old baggage we have (both in systems and in humans minds).

I think that in multilanguage environment the role of good design will grow - from today's point of view, when I think about some new functionality which not heavily connected with current environment I can done it in various language (if I write for JVM or CLR) - and then use from the Core system (or stable layer in Ola's terms). And otherwise when system are modular you can just implement plugin that use core functionality in any language.

And I think it's not new - for CLR we already have some of functionality in VB (with C# as "Core language"). In our case firstly because some members be new for C# (or Java), but knew VB and can quickly catch tasks with .Net and it. And next time we prefer to use late-binding over reflection for some integration with outside environment. This way and thinking of future systems (as blocks that can be implemented in various languages) more real.