Server Culture is Overridden with request ClientCulture

Server Culture is Overridden with request ClientCulture

Old forum URL:

ronnymgm posted on Friday, October 24, 2014

Hi there, 

Currently running version Csla 4.5.501 and some weeks ago a new customer from Germany reported an issue with number conversions.

We are running in a deployment scenario where the application server is a location and connected to enterprise databases and ERP systems.  It is a requirement that all these pieces "talk" the same culture, "de-de" (German) for instance.

But clients applications (win forms, workstations or browsers) can be (and are free to) running in any culture. English commonly.

We would like to understand why the Csla in methods SetThreadContext() insist in syncing the client request culture into the actual running thread culture. Even when the thread is on the other side of the data-portal (This overrides IIS settings in the application server). ?

Thread.CurrentThread.CurrentCulture = request.CurrentCulture;

Thread.CurrentThread.CurrentUICulture = request.CurrentUICulture;

And also if there is a visible risk removing those synchronization and let each part use its own culture configuration?

So far we haven't found inconvenient but any concern or comment is appreciated.



ajj3085 replied on Monday, October 27, 2014

I think there are a number of reasons for this.  Data entered as a string (such as a decimal or a date) would fail to parse correctly if the client is running en-US and thus entered 10/30/2014 but the server was using de-DE to parse. 

Also server side business rules may also have translations (via use of MessageDelegate) to allow the rule error message to be delivered to the client in the language they have selected.  I would expect if your application is running under en-US that I see all my error messages in American English; however if the server forces de-DE, the error messages would come back in German, not very helpful for an American that doesn't read the language.  This would also affect Csla error messages which have been translated as well.

I don't believe there are any other issues that you'd need to consider; if you are passing number / date data in strings (which is common, as some UI controls have issues with empty dates or if you want to allow things such as typing T as shorthand for Today), but it depends on how your application handles the data. 

ronnymgm replied on Monday, October 27, 2014

Thanks for your feedback Andy.

Yes Decimals and Dates are our major concerns. and actually the original cause of the problem.

But we try to always load Client UI data into the business object typed properties and the serialization-de-serialization process performed by the DataPortal (WCF) is managing types correctly. Even when they are in different Cultures. So far.

On the other hand.. talking about resources is not a real problem, we are not using resources embedded in the assemblies for final user display. We let the client application resolves the appropriated resources based on Broken rules name or ID only.

I think we are on the right way. Just don't want to let some scenario out of the equation.




JonnyBee replied on Monday, October 27, 2014

In addition to resources you may also have server tasks/commands that f.ex.



where you want to have the client culture set on the server process to get correct language. 

For broken rules - sometimes you want to have the actual value included in the error message and that will be hard to resolve with a message id or based on the broken rule name. 

So I take it you are not using any of the builtin CSLA rules (or messages) in your application. 

Inside the framework we want the code tp perform consistently on both client and server and in background threads. Imagine a client selecting german in the application and running english OS. You set the client culture on the current (UI) thread (and in .NET 4.5 you may also set the default on the AppDomain) but the background threads running on the client will use the OS default unless you have some mechanism to pass it on to the background thread. You could very well have have a mix of some data access code on an async dataportal running on the client (RunLocalAttribute) or running on the server. And both should behave in the same way and preferrable keep the cultures from the UI thread. 

And it is not just and the CurrentCulture/CurrentUICulture. This also includes the ApplicationContext (LocalContext/ClientContext/GlobalContext) that may be stored in either HttpContext (WebApp), a static instance (Xaml application) or a NamedSlot on the current thread. So CSLA use the same mechanism to transfer the ApplicationContext to background threads - whether it is in a WinForms or Web application or on the client side or server side. Remember - you loose the HttpContext when running Tasks or executing code in background threads in a web application too.

ronnymgm replied on Monday, October 27, 2014


Thanks. Great scenarios.

*generate reports or documents - ( don't have at the moment but need to keep an eye on them ).
*send mail/text message - ( in place but right now is using User Profile Preferences not Thread Culture ).

Your are correct about Csla resources and messages all of them handled by application and never re-throw as is.

Last point is more Interesting and complex. 

Yes we do create background threads in the client side and yes we do Sync the thread cultures, identity ,etc. Exactly to avoid the Client UI / OS Mix..

But I'm not sure of doing the right thing with the  RunLocal decorated dataportal methods...i didn't see that coming.. Great catch.!!

Maybe I can trust the ExecutionLocation Flag because the main idea is to intercept and avoid client-to-server culture synchronization only. To avoid UI Client Culture Data pass to the ERP System that only understand German.  

Thanks again. 

ajj3085 replied on Tuesday, October 28, 2014

So do your BOs expose numbers / date via string properties?  If so, you may want to consider creating private companion properties, and when the string value is changed create rule to parse the value (using the current culture) to the real decimal or date value and use that to send to the ERP / database.  That way all the parsing is done at the client and respects their culture settings; if you allow en-US, I'd expect your app to allow me to enter 1,200.50 or 10/31/2014, were the German would be (I think) 1.200,50 or 31/10/2014.   

ronnymgm replied on Tuesday, October 28, 2014

No, no the opposite:

"we try to always load Client UI data into the business object typed properties and the serialization-de-serialization process performed by the DataPortal (WCF) is managing types correctly. Even when they are in different Cultures."




Copyright (c) Marimer LLC