Deliverable: Localization

The CSLA framework gets the textual content for any message it needs to issue from a resource file. Rocky wrote the original English language resource file, and then the user community has contributed translations into other languages. Currently there are resource files for seventeen additional languages.

To demonstrate this capability I have forced the framework to output an exception message by intentionally violating one of it's rules.

So that we can see what is going on, I have a form which displays the user's culture in the right hand side of the form's status bar. This was done by the following line of code in a form's constructor:

                statusBarPanel2.Text = Thread.CurrentThread.CurrentCulture.DisplayName;

Now, here is the line of code that causes the intentional error.

                        _customer.Orders[0].Delete();

This is will cause a runtime error because my Order BO has been set-up as a “child” object. It cannot be directly deleted. It must be deleted via it's collection object.

The line of code results in the exception to the left. The status bar panel in the right corner shows that I have my PC set-up within an English speaking region.

The exception has been generated by the framework itself. The exception's text (“Can not directly” ... etc) has been obtained from the English language resource file that is relevant to my culture.

Now let us see how this error would be experienced by a German speaking user. We can simulate this by changing the PC's regional setting via Window's Control Panel's “Regional and Language Options” applet.

If we rerun the same unaltered, uncompiled application. We now see that the exception's message has been presented with German text.

Hopefully our application will not be causing the CSLA framework to issue many exceptions, but the mechanism that Rocky has given us can be utilised so that we can also internationalise our own strings. The implementation is sophisticated, as the user's culture is passed into the data portal for each call. I have not tried it, but I am assuming that this means that a remote App Server can service clients of differing cultures, and communicate with each in their own language.