Why the '/language' key switches CurrentCulture instead of CurrentUICulture?

[Anonymous]

Revit 2017.1.1

My external application (add-in) has two localizations: English (by default) and Russian. I saw that my external application (add-in) on the some computers uses wrong localization. One of that computers has the "clear" Revit without installed custom add-ins.

If I launch the revit.exe application with the /language RUS key then at this case Revit UI is Russian, but my add-in for own UI uses the default localization (i.e. "en") instead of "ru".

I extract the localized resources through the ResourcesManager class using in my code. It is the "native" way of working with resources in .NET. I know that ResourcesManager chooses the localized variant of resources on the base of Thread.CurrentThread.CurrentUICulture value.

Therefore I assumed that this value for any reason isn't "ru" or "ru-RU", despite value of the /language RUS key. I have checked the assumption and saw that I was right (look my code below):  Thread.CurrentThread.CurrentUICulture property uses "en" instead of "ru". Also I see that Thread.CurrentThread.CurrentCulture uses "ru-RU" instead of "en".

Why does the /language key switch the localization not of that thread which is responsible for the user interface (UI)? Is it bug?

Result IExternalApplication.OnStartup(UIControlledApplication application) {
	...
	// I use the `/language RUS` key for revit.exe
	// But I see that my add-in user the 'default' localization
	// instead of 'ru'. Hm...
	// Ok,I will check the CurrentCulture and CurrentUICulture 
	// values...
	//
	// Oops... Localization was changed by the `/language RUS` 
	// key, but not for that thread which shall to have this 
	// change! Why???
	CultureInfo n = Thread.CurrentThread.CurrentCulture; // ru-RU
	CultureInfo m = Thread.CurrentThread.CurrentUICulture; // en

	// I can fix this problem myself:
	// The CurrentUICulture switching fixes the problem, but 
	// why such problem occurs in Revit?
	CultureInfo k = new CultureInfo("ru");
	Thread.CurrentThread.CurrentUICulture = k;
	
	// Now my add-in uses right localization. 
	...
}

[Anonymous]

> Why does the /language key switch the localization not of that thread which is responsible for the user interface (UI)? Is it bug?

I correct my question: Why the /language key doesn't switch the `Thread.CurrentThread.CurrentUICulture`  which is responsible for the user interface (UI)? Is it bug?

[Anonymous]

Today I found that this problem exists in Revit 2017.1.1, but this problem is absent in Revit 2017. Therefore it is possible that this bug will appear in Revit 2018.

For demonstration of this problem I created the project and published it here. For fix this bug in Revit 2017.1.1 it is possible to use such class:

public sealed class UICultureSwitcher : IDisposable {

    CultureInfo previous;
    
    public UICultureSwitcher() {

        CultureInfo culture = new CultureInfo(Thread
            .CurrentThread.CurrentCulture.Name);

        previous = Thread.CurrentThread.CurrentUICulture;
        Thread.CurrentThread.CurrentUICulture = culture;
    }

    void IDisposable.Dispose() {
        Thread.CurrentThread.CurrentUICulture = previous;
    }
}

So, if to place code of methods of each external command and external application into the `using` block with this class member initializing then the problem will be fixed. My monologue is ended.

[Anonymous · Accepted solution]

Expanded info and patch of this bug is here.

[jeremytammik]

Dear Andrey,

Thank you very much for your report, in-depth research, professional workaround and all the documentation you provided both here and on your blog.

I like your blog post very much. I have not seen any public samples demonstrating proper multi-language resource handling before, so I would love to share your documentation and samples on The Building Coder as well, if that is ok for you.

Would you like to point out the single most relevant and exciting post of all? Then I can start by translating, editing and publishing that. If people like it and say so, or if you think there are other important nuggets in there that you would like to make available, we can look at adding more later.

What do you think?

Returning to the issue at hand:

I logged the issue REVIT-107819 [the '/language' key switches CurrentCulture and not CurrentUICulture -- 12610584] with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.

This issue is important to me. What can I do to help?

This issue needs to be assessed by our engineering team, and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:

• Impact on your application and/or your development.
• The number of users affected.
• The potential revenue impact to you.
• The potential revenue impact to Autodesk.
• Realistic timescale over which a fix would help you.
• In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

This information is extremely important. Our engineering team have limited resources, and so must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.

Best regards,

Jeremy

[Anonymous]

Hi Jeremy,

Ok, I created the RevitMultiLanguageAddInExample simple example and published it on GitHub here. I hope my code will be clear for you. Write me into this topic if you will have any problem with it.

Best regards,

Andrey

[jeremytammik]

Dear Andrey,

Thank you for your very nice sample.

I love your two sample commands. They are beautiful with the flowers  🙂

I compiled and debugged, starting up the sample with the settings stored in the Visual Studio project, i.e., the command line flag /language RUS.

I saw some Cyrillic in the Revit open screen, so it apparently had some effect. Most of the UI is still in English though. Almost all, in fact.

Also, the two sample commands appear in English.

Is that expected?

RevitPatches.PatchCultures is called in OnStartup, so I would have expected the sample commands to appear in Russian, since the command line flag /language RUS has been set.

Did I misunderstand its use?

Or is my system set up differently than yours?

Can you clarify, please?

Thank you!

Update: 

In OnStartup, my application.ControlledApplication.Language equals English_USA.

Therefore, obviously the English sample command resources are used.

How can I switch that to RUS? 

Should I expect the command line switch to achieve that?

Update 2:

I can set a breakpoint in PatchCultures and manually force LanguageType.Russian.

Then the sample commands appear in Russian. 

Update 3:

The obj/Debug folder in the GitHub repo contains some unneeded stuff that should be removed.

Actually, the entire folder should be removed, shouldn't it?

And added to .gitignore?

Cheers,

Jeremy

[Anonymous]

Hi Jeremy,

I created that example yesterday late at night.

This morning I made video which shows the easiest way of creation and editing of the resource files. You can look at it here:

https://www.youtube.com/edit?video_id=DKCm3p9Gp9M&feature=em-upload_owner

When you use /language RUS key the UI of my add-in, its tooltip, expanded tooltip, and help file (when you press F1) are to be russian.

When you use /language ENU key the UI of my add-in, its tooltip, expanded tooltip, and help file (when you press F1) are to be english.

The same for the TaskDialog content.

That example I did at home. Now I am in office. I will download and check it here...

[jeremytammik]

When I run your sample from the Visual Studio debugger specifying /language RUS, the content is still in English, and the application.ControlledApplication.Language equals English_USA.

Apparently, on my system, the /language flag does not affect application.ControlledApplication.Language in the expected manner.

[Anonymous]

Hm... Jeremy, I wrote the video how does it work on my computer: https://www.youtube.com/watch?v=f1IBVgP7T1I&feature=youtu.be

Oops... On video I forgot to press my buttons... But The text of my TaslDialog is localized too. If you want, I can re-record video and show it.

What Revit version do you use?

[Anonymous]

Attached zip-file contains the screens of Revit versions of machines where I tested this example. All works fine for them.

Also, if I disable my patch applying in the OnStartup method then in Revit 2017.2 it works fine without my patch too(!!!). I can't check it myself right now but it was checked by one of users which has this Revit version.

[Anonymous]

Hi Jeremy,

> In OnStartup, my application.ControlledApplication.Language equals English_USA.
> Therefore, obviously the English sample command resources are used.
> How can I switch that to RUS?

I don't know. I think that you can't do it.

> Should I expect the command line switch to achieve that?

Yes, of course.

> The obj/Debug folder in the GitHub repo contains some unneeded stuff that should be removed.
> Actually, the entire folder should be removed, shouldn't it?
>And added to .gitignore?

Yes, you are right. I will do it later. Also I will add the `readme.md` file.

[jeremytammik]

Dear Andrey,

I heard back from the development team about the issue REVIT-107819 [the '/language' key switches CurrentCulture and not CurrentUICulture -- 12610584] that I raised for you.

They closed this issue saying 'works as expected', and explain:

The CurrentUICulture should be implemented and maintained by the add-in. I checked several add-ins, and they set the CurrentUICulture for the code. So the customer should also set their own culture settings as they please.

Cheers,

Jeremy

[Anonymous]

Dear Jeremy,

> They closed this issue saying 'works as expected', and explain:
> The CurrentUICulture should be implemented and maintained by the add-in.

Revit 2017.1.1 has this problem, but Revit 2017.2 hasn't one. Which of them has 'works as expected'? If one of them 'works as expected' then the second of them 'works as non expected'. Am I right? It seems that the person who answered you just didn't want to investigate this problem...

> The CurrentUICulture should be implemented and maintained by the add-in.

This is disgusting decision... Who will be able to guarantee that uncontrolled switching of this property won't create problems for other applications which don't expect such behavior? The value of this property shall correspond to value of the '/language' key.

Ok, I understood the reply of ADN.  

Thank you.

Best regards,
Andrey

[jeremytammik]

Dear Andrey,

Thank you for your input.

You are right, of course.

Maybe the development team is also  🙂

Anyway, I added your note to the development team on the issue REVIT-107819 [the '/language' key switches CurrentCulture and not CurrentUICulture -- 12610584].

They are always under a lot of pressure, have a lot to do, and investigate only as far as they absolutely must.

Cheers,

Jeremy