To deal with international versions of Visual Studio and other Microsoft products (such as Office) has always been tricky. I think to remember that many years ago some version of Excel went as far as localizing the VBA statements (or macro language before VBA, not sure now), so while in English you had:
For i = 1 to 100 ... Next
in Spanish you had:
Para i = 1 a 100 ... Siguiente
I suppose that was intended to get accountants into macros without forcing them to learn two languages: VBA and, hmmm, English. Of course the experiment didn’t work well and currently VBA is English-only.
Today things should be easy if two rules are followed:
- The user interface is localized, but the names of objects in the internals (ie: programming) should not be localized. So, classes should have a property such as “Caption” that is localized (in .NET the Caption property has been replaced by the Text property but it’s the same) and a property such as “Name” that should NOT be localized. Every programmer can understand the difference between “Name” and “Caption”, right?
- When locating an item in a collection, the English name should be used as index, never the localized name.
Alas, the reality is not so easy:
- The Office Commandbar class has the Name and NameLocal properties (and lacks a Caption property). You can learn searching the MSDN help (don’t expect the Intellisense help to tell the difference) that NameLocal actually means something like LocalizedName. The difference between “Name” and “NameLocal” is not so clear as between “Name” and “Caption”.
- Visual Studio command names are also localized (http://msdn.microsoft.com/en-us/library/aa290377(VS.71).aspx), supposedly because a programmer can type them in the Command window, I guess. But MS did it right and the Commands collection can be queried by English names even on localized Visual Studio versions
- Visual Studio output window panes (EnvDTE.OutputWindowPane) have a Name property, and guess what? The Name is localized, so in Spanish is “Generar” instead of “Build”. I know, I know, VS is so extensible that it uses Guids to identify things (as if fully qualified names were not enough) and therefore the EnvDTE.OutputWindowPane class has a Guid property too that you should use to locate a specific output window pane. My point is that the Name property of an EnvDTE.OutputWindowPane should be “Caption” and it would not cause havoc when an English developer receives a call from a German customer saying that the product doesn’t work with German Visual Studio because the developer thought that Name would not be localized. The last thing that I want to see is forcing developers to hardcode strings in their product with all the localized names that the product needs with its Korean, Chinese, Japanese, etc. strings…). Even the code generated by the add-in wizard of Visual Studio does the same as I explained in another article.
- With all that precedents, since you cannot be sure that your product will work with international Visual Studio versions, you have to test, but VS forces you to install the whole product in another language, rather than supplying downloadable localized resource DLLs to put in some folder (in VS.NET 2002/2003 you could get them from the CD of the international versions but in VS 2005 they are hidden in CAB files…)
So, my latest article explains how to get an output window pane by Guid without learning Chinese 😉
HOWTO: Get an OutputWindowPane to output some string from a Visual Studio add-in or macro
http://www.mztools.com/articles/2008/MZ2008023.aspx