Globalization and Localization of Office Solutions
Most aspects of globalizing and localizing Microsoft Office solutions are the same as you encounter when you create other kinds of solutions using Visual Studio. For more information, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_vsto2003_ta/html/VSTO_globalization.asp).. Globalization and localization information can also be found on the MSDN Web page Globalization and Localization Issues for Solutions Created with Microsoft Visual Studio Tools for the Microsoft Office System (
Localizing Document Text
The document, template, or workbook in your project probably includes static text, which must be localized separately from the assembly and other managed resources. A straightforward way to do this is to make a copy of the document and translate the text using Microsoft Office Word or Microsoft Office Excel. This process works even if you make no changes to the code, because any number of documents can target the same assembly. You must still make sure that any part of your code that interacts with the document text continues to match the language of the text, and that bookmarks, named ranges, and other display fields accommodate any reformatting of the Office document that was necessary to adjust for different grammar and text length. For document templates that contain relatively little text, you might want to consider storing the text in resource files, and then loading the text at run time.
In Excel, you can set a property of the worksheet to render text right to left. Host controls, or any control that has a
RightToLeft property, that are placed on the designer automatically match these settings at run time. Word does not have a document setting for bi-directional text (you just change your alignment of text), so the controls cannot be mapped to this setting. Instead, you must set the text alignment for each control. It is possible to write code to walk through all of the controls and force them to render text from right to left.
Your customization code typically shares the main UI thread of Word or Excel, so any changes you make to the thread culture affects everything else that is running on that thread; the change is not restricted to your customization. Therefore it is not recommended that you change culture programmatically.
Installing the Language Pack
If you have non-English settings for Windows, you can install the Visual Studio Tools for Office Language Pack to see Visual Studio Tools for Office runtime messages in the same language as Windows. If any end users run your solutions with non-English settings for Windows, they must have the language pack to see runtime messages in the same language as Windows. The Visual Studio Tools for Office Language Pack is available from the Microsoft Download Center (http://www.microsoft.com/downloads).
Regional Settings and Excel COM Calls
Whenever a managed client calls a method on a COM object and it needs to pass in culture-specific information, it does so using the(locale) that matches the current thread locale. The current thread locale is inherited from the user's regional settings by default. However, when you make a call into the Excel object model, Microsoft Visual Studio 2005 Tools for the Microsoft Office System passes in a culture-invariant locale identifier (LCID) automatically. You must format all data that has locale-sensitive formatting, such as dates and currency, using the English (United States) data format (locale identifier (LCID) 1033) before you pass it to Microsoft Office Excel or read the data from your Visual Studio Tools for Office project code. For more information, see .
This behavior is controlled by the Visual Studio Tools for Office attribute. You can change the behavior so that data is passed using the LCID of the current thread by setting ExcelLocale1033Attribute to false. You can then write your own code to handle the interaction between Excel and managed code. For more information, see .
Considerations for Storing Data
To ensure that your data is correctly interpreted and displayed, you should also consider that problems can occur when an application is storing data, including Excel worksheet formulas, in string literals (hard-coded) instead of in strongly-typed objects. You should use data that is formatted assuming a culture-invariant or English (United States) (the LCID value en-US) style.
Applications That Use String Literals
Possible values that might be hard-coded include date literals that are written in English (United States) format, and Excel worksheet formulas containing localized function names. Another possibility might be a hard-coded string that contains a number such as "1,000"; in some cultures, this is interpreted as one thousand, but in other cultures, it represents one point zero. Calculations and comparisons performed on the wrong format might result in incorrect data.
Excel interprets any strings in accordance with the LCID that is passed with the string. This can be a problem if the format of the string does not correspond to the LCID that is passed. Visual Studio Tools for Office uses the LCID 1033 (en-US) when passing all data. Excel displays the data according to the regional settings and Excel user interface language. Visual Basic for Applications (VBA) works this way; strings are formatted as en-US and VBA almost always passes 0 (language neutral) as the LCID. For example, the following VBA code displays a correctly-formatted value for May 12, 2004, in accordance with the current user locale setting:
'VBA Application.ActiveCell.Value2 = "05/12/04"
The same code, when used in a Visual Studio Tools for Office solution and passed to Excel through COM interop, produces the same results when the date is formatted in en-US style.
You should work with strongly-typed data instead of string literals whenever possible. For example, instead of storing a date in a string literal, store it as a, then convert it to a object for manipulation.
The following code example takes a date that a user enters into cell A5, stores it as a Double, then converts it to a DateTime object for display in cell A7. Cell A7 must be formatted to display a date.
Excel Worksheet Functions
Worksheet function names are translated internally for most language versions of Excel. However, due to potential language and COM interop issues it is strongly recommended that you use only English function names in your code.
Applications That Use External Data
Any code that opens or otherwise uses external data, such as files that include comma-separated values (CSV files) exported from a legacy system, might also be affected if such files are exported using any format besides en-US. Database access might not be affected because all values should be in binary format, unless the database stores dates as strings or performs operations that do not use binary format. Also, if you construct SQL queries using data from Excel, you might need to ensure they are in en-US format, depending on the function you use.