Feature 'A' + Feature 'B' = Bug 'C' ? (aka Localization in MSDN: content vs. samples)

by Michael S. Kaplan, published on 2008/01/08 10:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/01/08/6998407.aspx


From the recently pre-recorded blogs collection...

Over in the microsoft.public.dotnet.internationalization newsgroup, Norman Diamond posted (in his unique way that all who know it treasure!):

What do you call it when your version of Visual Studio promises not to support its own language, promises not to support most other countries' languages, and promises only 7-bit clean ASCII?  Although such an environment is very useful when coding device drivers and maybe some other specialized projects, I have to wonder about the general case.  Should we call this deinternationalization?  D20N for short?

First, an example which isn't 7-bit clean, which supports 3 foreign languages but not Japanese:
http://msdn2.microsoft.com/ja-jp/library/y99d1cd3(VS.80).aspx
* 10.  F5 キーを押すか、または [デバッグ] メニューの [開始] を
*       クリックします。
*       オペレーティング システムの UI 言語に応じて、英語、フランス語、
*       またはドイツ語のあいさつがダイアログ ボックスに表示されます。
(Press the F5 key or click the "Debug" menu "Start" entry.  Depending on the operating system's UI language, an English, French, or German greeting will be displayed in the dialog box.)

Next, how to really restrict developers to a single foreign language:
http://msdn2.microsoft.com/ja-jp/library/7k989cfy(VS.80).aspx
*  バイナリ エディタを使用すると、.resx ファイルを含むリソース ファイル
*  を、16 進形式または ASCII 形式のバイナリ レベルで編集できます。
(If you use the binary editor, you can edit resource files including .resx files in hexadecimal or ASCII.)
Fortunately Visual Studio 2005 didn't obey this one.  It displayed resources in either Shift-JIS or Unicode, I'm not sure which.

Now, I'm really glad that Visual Studio 2005 supports its own language. This beats some Win32 APIs.  But MSDN's promises of D20N started out looking pretty discouraging.

What we are seeing here in the first part is a combination of two different efforts that have ended up combining in a rather unfortunate and embarrassing way.

The first effort is the one to provide better globalization/localization information and samples for developers.This is obviously a very good thing that I am sure everybody who reads here would like to see more of whenever possible.

In this case the Windows Forms Programming Walkthrough: Localizing Windows Forms provides a WinForms sample that supports English, German, and French. It would be hard for me not to be excited about content like that making it out into the world....

The second effort is the one to provide localized versions of the content in MSDN into many different languages, which I think I have mentioned before. Now this too is a very good thing that I know many people would like to see more of, seeing pages like the above one in Japanese, Korean, Traditional Chinese, Simplified Chinese. French, German, Italian, Brazilian Portuguese, Spanish, and so on.

Now you can see where the problem comes in -- the localizers of the content are nor modifying the underlying samples, thus every language MSDN is localized into that does not have the list of translations match the list of app localizations will have these cases of "how can you say that support a language when your samples don't support it, even when localized into that languge....

But is the answer to

Or is the status quo where these efforts being done by entirely different teams at entirely different points of the cycle are not seeing their efforts in general and their language lists in particular synchronized, due to the extreme complexity involved with maintaining such a synchronization as samples are added and as localizations are added?

Personally that is what I would suggest, although perhaps including some text to explain the apparent limitations could be worth considering.

I'll talk about the second part of Norman's posting another day....

 

This post brought to you by(U+30c3, aka KATAKANA LETTER SMALL TU)


no comments

go to newer or older post, or back to index or month or day