I'm using Umbraco 4.5.1 at the moment and stumbled upon this (for us) unwanted behavior:
In the BeginRequest event I'm changing the CurrentThread.CurrentCulture property by reading a 'culture' cookie. Then in the OnInit of the masterpage or a usercontrol the culture has been overwritten by Umbraco. Just took a look in the source and found out that in 'Default.aspx' the culture is overwritten if Domains are set (Domain - Culture combination):
Now for us this is unwanted behavior, there should be an extra check in the if statement for an appSetting or something like that (so you can disable this from the web.config).
Now I fixed it by creating our own Default.aspx, which inherits from "umbraco.UmbracoDefault" and add this code:
So the questions are: Why is Umbraco always overwriting the CurrentCulture, while in some situations this is unwanted? Why isn't there an appSetting which can disable this? And will there be an appSetting in the future for this?
This is by design and convention. It only overrides currentculture when a domain/language have been set on a node (to ensure that dictionary items and culture specific items are displayed correctly).
There isn't an appSetting for this as it's a convention and we don't believe in a ton of configuration options.
If you don't want this, just don't use the assign hostname/culture function. If you do use it, then use it as it has been designed; that the culture settings are updated based on the culture assigned to the node.
Thanks for your reply. Our 'issue' is that we are hosting two websites (which belong together) in a single Umbraco installation. The customer chose to be able to edit multilanguage properties via extra tabs on documents, so they explicitly didn't want 3 different versions per site (one for every language).
At the moment when adding a hostname, you are forced to specify a language. Isn't it a good idea to make this optional? If not set, don't adjust the current thread's culture?
Umbraco overriding System.Threading.Thread.CurrentThread.CurrentCulture
Hi Umbracians!
I'm using Umbraco 4.5.1 at the moment and stumbled upon this (for us) unwanted behavior:
In the BeginRequest event I'm changing the CurrentThread.CurrentCulture property by reading a 'culture' cookie.
Then in the OnInit of the masterpage or a usercontrol the culture has been overwritten by Umbraco.
Just took a look in the source and found out that in 'Default.aspx' the culture is overwritten if Domains are set (Domain - Culture combination):
Snippet
Now for us this is unwanted behavior, there should be an extra check in the if statement for an appSetting or something like that (so you can disable this from the web.config).
Now I fixed it by creating our own Default.aspx, which inherits from "umbraco.UmbracoDefault" and add this code:
Snippet
So the questions are:
Why is Umbraco always overwriting the CurrentCulture, while in some situations this is unwanted?
Why isn't there an appSetting which can disable this?
And will there be an appSetting in the future for this?
This is by design and convention. It only overrides currentculture when a domain/language have been set on a node (to ensure that dictionary items and culture specific items are displayed correctly).
There isn't an appSetting for this as it's a convention and we don't believe in a ton of configuration options.
If you don't want this, just don't use the assign hostname/culture function. If you do use it, then use it as it has been designed; that the culture settings are updated based on the culture assigned to the node.
@Niels
Thanks for your reply.
Our 'issue' is that we are hosting two websites (which belong together) in a single Umbraco installation. The customer chose to be able to edit multilanguage properties via extra tabs on documents, so they explicitly didn't want 3 different versions per site (one for every language).
At the moment when adding a hostname, you are forced to specify a language. Isn't it a good idea to make this optional? If not set, don't adjust the current thread's culture?
Definitely worth for a future release - post it as a CP feature request :)
Was just creating a CP ticket :-)
Thanks!
Thanks for the example code Stefan, just what I needed! :-)
No problem! :-)
Here is the workitem btw: http://umbraco.codeplex.com/workitem/28521
Oh good, voted, excellent solution!
Voted - we could use that to
is working on a reply...