I had just got done explaining to yet another customer why the .NET Culture Architecture does not provide multilingual support, and I decided that I had had enough. With Whidbey and WinFX in the offing, now was the time to try to get this fixed.
So I up and emailed Chris Anderson, the Program Manager of the Avalon team. He was kind enough to forward my thoughts to Kathleen Carey, on the internationalization team. This shows a beyond the norm commitment to their customers. Kathleen gave me some helpful insights into their culture architecture and, hopefully, I gave them some food for thought. I thought this conversation of interest, especially in light of the recent posting of DateTime best practices. What follows is our email discussion.
Chris,
I have worked on architectures of two systems that required multilingual support. For both of these the .NET Culture pattern was inadequate. If you think of it, in the US, the Culture pattern will never work. Consider an ATM system. Suppose I wish to support the BIG THREE, English, French, Spanish for within the US market. The problem with Cultures is that there is no es-US or fr-US cultures. Therefore, from the perspective of these applications, the .NET Culture system is broken. Is there any thought of fixing this for Longhorn?
Kenneth Brubaker.
Kenneth,
You pinged me on Monday with the question:
"..."
I've CC'd one of our experts in internationalization (loc, glob, etc… )…
Are you perhaps in any of the beta/alpha programs for the CLR? (Do you have an NDA contract signed with MSFT? If so, who is the contact on the Microsoft side?)
Regardless of the answer, we can still chat a bit about this, but we will have to constrain some of the answers a tad ;-)
Thanks!
Chris,
'Fraid I'm not under any NDA. I would be happy just to hear that you "Got it solved." However, I wanted to be sure that the issue is well captured. At least for US firms, the .NET story leads them down the garden path. They say, Oh great, I use resx's and, when I need to, I can advertise that my app works in multiple languages.
I remember when I first encountered the problem during the Beta2 days, I argued, dutifully, for using culture ID's (e.g., en-US) grabbed from the UI culture for choosing the phrases. I am glad that I lost the argument. As I've architected other applications for US companies, I've seen this issue come up every time. I've worked lately with Financial Services companies. Usually when they speak of internationalization, they really mean multilingual. They're crestfallen every time I explain they have to create a custom solution for the problem.
Now, if .NET would allow custom cultures such as es-US for Puerto Rico, for example, then we'd have no problems, though I think it would throw the current architecture out of whack, since it doesn't appear to be extensible at the AppDomain level that we're speaking of here. I'm not sure what your model should be, but there is a problem here. I know it is mostly a CLR issue, but this issue most consciously impacts the UI.
- Summary:
- Multilingual != Localization
- There is a large need to support multilingual
- Perhaps, a need larger than for localization for US companies.
Thanks for your time,
Ken Brubaker
Hello Kenneth, and thanks for all the feedback !
Here’s some more information which might be helpful.
1) In the .NET model, you can have separate values for CurrentCulture and CurrentUICulture.
a. If the goal is to have 3 sets of resources for the US market, then one solution is to set CurrentCulture and CurrentUICulture separately.
i. CurrentCulture can be set to en-US, to get US-style formatting for dates and numbers.
ii. CurrentUICulture can be set to en, fr or es as appropriate (I’m assuming there’s a dialog or section in the UI where the customer picks a language.) For this approach, one would create resources tagged as en, fr and es.
b. Issue : using en-US for CurrentCulture will give you nicely formatted numbers and dates, such as $1,000.00 and 12/05/2003.
However, if you’re using the text form of dates (Thursday, December 5th, 2003), those will be returned in the language of your currentCulture unless you specify otherwise. You could get around this by customizing the DTFI (datetimeformatinfo) to use Spanish names. This will work for formatting dates, (such as creating dates for display to screen) but not for parsing.
2) There’s a sample on http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=a193b952-2e44-45ed-811d-c1fabf2f6e8a that shows creating a custom culture by overloading the CultureInfo class.
a. Issue : creating custom cultures by overloading works just fine within an appdomain.
b. However, if you’re passing a thread across app domains, you can’t just create the custom culture in the first app domain. Instead you’d create the custom culture in both the first and second app domains, to ensure all necessary info is still present if the first app domain is unloaded while the second app domain is still active.
3) In upcoming releases, we are looking at ways to make custom cultures simpler to define and easier to deploy.
I think you’ll like it. ;-)
Since there is a newer solution in the works, option 2 is really a temporary solution. I think you’re better off using option 1 for now.
Does this help ?
Also, I’d like to understand if there are other limits you see on .NET’s support for multilingual apps, as the current model is definitely meant to support multilingual apps ! For example, that’s why resources are in separate satellites by culture, and you can drop in a new satellite at any time, without having to rebuild your app. We do have some shipping multilingual apps, both websites and desktop, so I’m puzzled and worried. Are there other blocking issues you see ?
Many thanks for your help,
Kathleen Carey
Kathleen,
Thanks so much for such a quick and careful response.
Issue 1b is the reason it doesn't work, from my perspective. At least for financial services applications, dates are very relevant and often frequently used. I'm intrigued by the custom culture solution. However, I think it rather cumbersome if a Citibank, say, wants to support ten languages for their US ATM machines to create ten custom cultures. I'm glad to hear that richer support is being considered for multilingual in the future.
I can only hope the CLR team is considering the same for time zones. In a distributed environment, especially for Web Forms, an application needs to work with multiple time zones. I know that the issue is complex, but this concept is very hard to support with .NET 1.x.
...
Thanks again,
Ken Brubaker
Hello again,
Some answers (and more questions..;-), below
Thanks again for all the advice and feedback
Kathleen Carey
Kathleen,
Thanks so much for such a quick and careful response.
Issue 1b is the reason it doesn't work, from my perspective. At least for financial services applications, dates are very relevant and often frequently used.
KC: Yes, dates of transactions are very important ! Could you educate me a little more as to how dates are being used in these applications ? I’d like to understand the scenarios better, so I can see if there are any other alternatives available. (Obviously, I don’t want to know anything confidential, just want to get an idea of the design problems.)
KC: Is there a common date format used for storage in back-end databases, and then a conversion to “customer-friendly” display format for use on ATM screens or on printed receipts ? Would it be reasonable to use the InvariantCulture or en-US for date format in backend storage, and then to specify the display-culture as part of getting the date for display (say by a datetime.tostring (“es-MX”) ) ?
I'm intrigued by the custom culture solution. However, I think it rather cumbersome if a Citibank, say, wants to support ten languages for their US ATM machines to create ten custom cultures. I'm glad to hear that richer support is being considered for multilingual in the future.
KC: From the perspectives of the financial services apps, is the inconvenience in having to define a custom culture at all, or is the problem that the approach shown in the sample is too manual, too disconnected from the rest of our culture support ?
I can only hope the CLR team is considering the same for time zones. In a distributed environment, especially for Web Forms, an application needs to work with multiple time zones. I know that the issue is complex, but this concept is very hard to support with .NET 1.x.
KC: We’ve gotten some requests for improvements to TimeZone support. Can you tell me something about the scenarios you’d like to see improved ?
...
Many thanks,
KC
Kathleen,
Sorry for the delayed response. Here are my comments.
How are dates used?
I encourage my clients to use UTC dates everywhere except for presentation, where it should be put in the user's local time and displayed in the user's local format and user's language of choice. For normal smart client apps where the user speaks his locale's language, this is fine. However, for an ASP.NET scenario or a multilingual smart client, it is problematic. To make that advise succeed, a user's neutral language must be in a session-global variable and the application vendor has to make his own date-to-text translator. And what if we are reading text dated entered by the user? DateTime.Parse will not be able to handle it. This is because something like "es-MX" not only has Spanish words but also has Mexican date semantics. What is needed is US date semantics with Spanish words; thus: "es-US." Given that the US is the third largest Spanish-speaking country, it's not a big leap to believe that there is an interest in this. I can understand, however a desire to use only ISO culture names.
Is it inconvenient to define a custom culture?
The client is surprised that they have to go to so much effort to make their US-multilingual financial services application work.
TimeZone scenarios
The core problem here for financial services companies is that things like Close of Business Day is important at the facility where the user is located. If I'm creating a WebForms application for tellers, the TimeZone of the Web Server is unimportant, it's the time zone of the facility where they are working that matters. The web server needs to keep a different time zone for each user. There are also some B-to-C scenarios:
Use Case: Spanish-speaking banking user picks her time zone in Indianapolis, IN on an ASP.NET. The current date/time is displayed for reference.
Use Case: Husband of said Spanish-speaking is joint account holder, is a native of Newfoundland, CA and speaks French. They have a cottage in Newfoundland and are located there in the summer time. While there, he changes the time zone to that location.
Here we need "es-US" and Eastern Time, do not switch to daylight savings (Special time zone rules for Northern Indiana). Also we need "fr-US", because we need to stay on US banking calendar. However, Newfoundland uses a custom time zone. Desirable: a Microsoft.* class that exposes the time zones available to the Date and Time Properties Control Panel Applet. For one client, I developed a custom time zone class that used the list stored in the Win32 registry, only to find that it was a different and incomplete compared to the list used by the Applet. The base support would simply be providing a concrete TimeZone class.
Again, clients are surprised and chagrined when they find they can't support clients in multiple time zones.
Thanks again for your interest!
I think it would benefit your team to do some use case analysis on these issues.
Kenneth Brubaker
Thanks so much for all the feedback ! I’ll pass this information along to the relevant teams.
Thanks again
Kathleen Carey