Hi,
wheras using winforms & CSLA 3.8 I never had probs with getting the correct culture (as long as users have set their OS-culture set the right way, of course ;-)), I run out of ideas with SL & CSLA 4.
Where is the right place to set UI-culture, so it's transfered to the server and back to the client to show validation messages in the correct language?
Thanks for answers & help
Volker
You should be able to set this on the current thread in SL, ex:
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("FR");
Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("FR");
And these will be transferred to server at set on the serverside thread when you use the DataPortal.
Hi Jonny,
thanks for your answer.
Unfortunatly exactly that doesn't work;-( (as other approaches like params in aspx/html don't)
Thread.CurrentThread.CurrentCulture = New CultureInfo("de-DE") Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture
Any other hints?
Volker
Hi,
after some testing it looks as if it's a problem with accessing the resources, since the culture seems to be set correctly...
Any ideas?
Volker
Hi,
both, SL-clientside and serverside thread carry the correct culture/UI-culture. But unfortunatly CSLA seems to fall back to the default language resource which is english and ignores the culture setting
So, what are the prerequisites for CSLA for accessing the correct language resource? Even the SL-sample behaves this way
Thanks for any help!
Volker
Hi, Do you mean the messages from CSLA itself?
Then, it's probably missing the de\Csla.resources.dll
As far as I remember it's not included in the binaries, you have to build the solution yourself to get it.
HTH
Stefan
Hi Stefan,
indeed it's about the messages created by CSLA itself, validation, for example.
Does this mean to re-compile CSLA by myself?
Thx for answering
Volker
Yes, it does mean to build CSLA from the source by yourself.
It's no big deal. But I also don't understand, why they are not already included.
Stefan
Jonny generally knows a lot more about this than I do.
But when you build Csla.dll for Silverlight it does create the satellite assemblies with the localized resources you'd expect. So I don't see why you would have to build Csla.dll yourself, because those assemblies should be there as part of our installer.
I don't know if they come with the nuget package - that could be different I suppose.
I also don't know if those satellite assemblies are automatically included in your xap file, or if you need to take extra steps to have them added when you build your application. This is where Jonny probably knows a lot more than me.
Hi,
Been digging into this a bit myself and there is 2 important points here:
1. In your SL app you must edit the project file to include the supported languages:
<SupportedCultures>no,de</SupportedCultures> (Here Norwegian and Deutch - Default language is implicit).
This is to required to add the satellite resource files to <application>.xap file.
Unfortunately - Microsoft has not provide any means to edit this in the Project Properties.
2. To change language you must set Culture property on the generated resource code.
Example (Strings is a resource file) :
listBox1.Items.Clear(); listBox1.Items.Add(string.Format("Language:{0}", Strings.Language)); Strings.Culture = new CultureInfo("nb-NO"); listBox1.Items.Add(string.Format("Language:{0}", Strings.Language)); Strings.Culture = new CultureInfo("de-DE"); listBox1.Items.Add(string.Format("Language:{0}", Strings.Language));
generates the following output:
Language:Default
Language:Norsk
Language:Deutsch
or write your own "resource" code that uses Thread.CurrentThread.CurrentUICulture to lookup resources.
The default generated code is like this:
private static global::System.Globalization.CultureInfo resourceCulture; /// <summary> /// Overrides the current thread's CurrentUICulture property for all /// resource lookups using this strongly typed resource class. /// </summary> [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Advanced)] internal static global::System.Globalization.CultureInfo Culture { get { return resourceCulture; } set { resourceCulture = value; } } /// <summary> /// Looks up a localized string similar to Default. /// </summary> internal static string Language { get { return ResourceManager.GetString("Language", resourceCulture); } }
Hi Jonny,
well the project-file of my SL app already contains <SupportedCultures>de</SupportedCultures> and adding 'no' indeed results in a no-Folder AND de-folder beeing added to my xap-file. The de-folder contains a bunch of dll's which, as far as I can see contain german messages (esp. System.ComponentModel.DataAnnotations.resources.dll) So far, so good, this works as expected (but unfortunatly doesn't lead to localized messages).
As I'm not used to work with resource files, since my apps didn't need localization, I didn't get the sense of your second point without digging deeper...
(Should <SupportedCultures> reside in other project-files, too?)
Setting Culture/UI-Culture at applications startup definitly doesnt result in accessing those ...resources.dlls
Thanks
Volker
Hi Volker,
Just to make sure I understand your problem:
You're using CommonRules and want localized messages when rules are broken?
Are you using "BusinessRules.AddRule(...some common rule....)" in method AddBusinessRules or DataAnnotations attributes?
Is there in folder de\ the assembly Csla.resources.dll (on the tier/s where rules are used)?
If you're using ValidationAttribute, this http://stackoverflow.com/questions/1481376/asp-net-mvc-validationattribute-and-localized-errormessage might be helpful. I've not been using the attributes yet.
Stefan
Hi Stefan,
sorry for the late response, but business...
"You're using CommonRules and want localized messages when rules are broken?" <-exactly
"Are you using "BusinessRules.AddRule" <- yes and "or DataAnnotations attributes" <- no
This seems to be the point:
"Is there in folder de\ the assembly Csla.resources.dll (on the tier/s where rules are used)?" It resides in the SL and the NET part of the libs, in the SL-application, too, but is missing in the xap-File, where the folder is present, but not the csla.resources.dll inside.
I'll check that and give feedback if copying the file helps...
Thanks.
Volker
With Wpf projects (non SL) I copied the files in a directory structure like this:
Libraries\Csla.dll
Libraries\de\Csla.resources.dll
Source\SomeProject\
From SomeProject I reference the Csla.dll assembly (using browse...) and when built the de\Csla.resources.dll is automatically copied to a bin\Debug folder, and to any output folders of projects referencing SomeProject.
But I don't know, whether this works with SL and xap files, too.
Copyright (c) Marimer LLC