localize VSTO addin according to the language of the office product

5
votes

I'm developing a VSTO addin and want it to be localized according to the language version of the office product. In theory, that's how to do it:

int lcid = Application.LanguageSettings.get_LanguageID(Office.MsoAppLanguageID.msoLanguageIDUI);
System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo(lcid);

For this to work I need Application to be initialized, of course. So the earliest point where I can execute this code is in the Startup event handler. At this point, however, CreateRibbonExtensibilityObject() already has been called, so at least the title of my custom ribbon tab is going to be displayed in the Windows language, which might be different. In the ribbon class I have a handler for the onLoad event, where I store an instance of IRibbonUI for later use. I could hand over this instance to the addin class and let it call IRibbonUI.Invalidate() on it. But this seems to be a bit strange - creating a ribbon just to invalidate it a couple of microseconds later. So I wonder - and ask here - whether there is a more elegant way to localize the ribbon of a vsto addin according to the language version of the office product.

(I've seen this similar question, but the approach offered there by this answer looks even worse to me.)

1
.netlocalizationvsto
re: worse approach: You mean, of course the registry lookup, right? The answer suggesting use of CurrentUICulture makes sense to me. – Ishmaeel
@Ishmaeel Sure. That other answer is newer than my question. I've just edited that part to make it clear. My first attempt (see the question) and both that new answer and the accepted answer here set CurrentUICulture. They differ in where to take it from. – Matthias

1 Answers

9
votes

You can always override the CreateRibbonExtensibilityObject method or possibly override some of the other AddInBase methods (BeginInit, Initialize, etc.) to hook into the proper location in the AddIn load lifecycle.

I have overridden the CreateRibbonExtensibilityObject before to ensure that initialization code is run before the Ribbon is loaded. I have noticed that CreateRibbonExtensibilityObject and Startup events are triggered at random times. Sometimes Startup happens first - sometimes CreateRibbonExtensibilityObject fires first. I had to manually synchronize the two events to ensure any initialization code is executed prior to Ribbon creation. If CreateRibbonExtensibilityObject fires first - the Application object has not yet been created.

Try this approach in CreateRibbonExtensibility:

 Outlook.Application app = this.GetHostItem<Outlook.Application>(typeof(Outlook.Application), "Application");
 int lcid = app.LanguageSettings.get_LanguageID(Office.MsoAppLanguageID.msoLanguageIDUI);
 Thread.CurrentThread.CurrentUICulture = new CultureInfo(lcid);

This will retrieve a reference to the Application instance for you - regardless if it has been loaded in the Initialize yet.