The third article of the MZ-Tools Articles Series of this year is about testing add-ins in localized (international) versions of Visual Studio. It happens that most developers of the world are either native “English” or use English versions of Visual Studio and/or Windows, and therefore are not 100% aware of localizations that happen in the products. For example, many applications (even from Microsoft) hardcode “Application Data” rather than using the localized version of that folder that Windows uses. See for example this bug in Visual Studio:
Visual Studio hardcodes “Application Data” folder in the list of folders for .AddIn files
which causes that setups of add-ins that call the Windows API that returns the actual (localized) name of that folder (the correct thing) actually fail to be recognized as add-ins in non-English versions of Windows, because VS won’t search for .AddIn files in the localized version of the folder (the VS 2008 SDK has an add-in with this problem, for example).
I am Spanish and in my case I use a mix of Spanish/English applications. For example, on same computers I have Windows and Office in Spanish while Visual Studio is in English. Taking into account that Office now offers Visual Studio Tools for Applications (VSTA) and Visual Studio Tools for Office (VSTO) I see issues caused by those mixes sometimes.
I posted a rant about localization issues in Visual Studio long time ago here:
MZ-Tools Articles Series: HOWTO: Get an OutputWindowPane to output some string from a Visual Studio add-in or macro
and this new article explains how to get multiple localized versions of Visual Studio on the same machine and which areas of an add-in should be tested:
HOWTO: Testing add-ins in localized versions of Visual Studio