When swimming in a sea of CONTEXT, applications can drown (and there is no lifeguard)

by Michael S. Kaplan, published on 2008/10/02, original URI: http://blogs.msdn.com/b/michkap/archive/2008/10/02/8971896.aspx


Now I have talked about the good, the bad, the ugly, the pretty, the ins, and the outs of digit substitution many times over the past few years:

There are others, but get the point.

Interestingly, none of them covered the issue that I found in my inbox yesterday morning at 5:05 AM (in fairness the email was from someone in India so it was actually more like after 5:00 PM there!).

The mail went something like this:

I’m a dev facing an internationalization issue in our application.  On asking around, I gathered that you might be the person who can help – and hence this mail.

In “intl.cpl” we have a setting called “Use Native Digits”.  It can take 3 different values – “context”, “none” and “national”.  Do you know of any way to change this setting from within an application without affecting all the other applications running in the system?

A call like the one below does change the setting but the effect is global:

SetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_IDIGITSUBSTITUTION, L"2");

Why do we want to set “Use Native Digits” to “national”?  Well, because if the value is “context”, edit boxes end up mixing Arabic and English numerals based on what’s been entered previously – an effect we do not want.

Thanks & Regards,

Now this is an issue that hasn't really come up before.

I mean not really.

The way that when we talk about digit substitution being set the context (which is defined in the documentation as "The shape depends on the previous text in the same output"), what isn't really discussed is one important factoid:

The context border is at the level of a single control.

In a single application with several controls on it, this may or may not make sense.

If they each do separate things, then perhaps they will make sense if they are different.

Take the dialog in Regional Options date customization for a second:

  

Now the first one is with an Arabic UI language, and the second with an English one.

Both have the default Arabic - Saudi Arabia locale and you can see how the various controls do very different things throughout, given the Context setting here.

Perhaps since each example is self contained and meant to show differences, this is okay (though some find even this confusing).

But imagine the kind of UI being reported here, where all of the controls are together, almost like a grid of them. Having their behavior change based on content would be like watching different boxes in an Excel spreadsheet show different behavior. Ugly!

Unfortunately there is no place to define a different behavior here, other than some more low level ways you can get to if you call the Uniscribe functions directly and change the dfcigit substitution settings there.

But certainly less than ideal -- you lose a lot more features than you gain if you go that route.

This an area that could really use some actual solutions -- and help from the folks in NLS and GDI and Uniscribe, probably. Though this is just one more item in a long list of things that needs to be fixed in digit substitution, so it is hard to say when/if people will get to it.... :-(


This blog brought to you by # (aka U+0023, aka NUMBER SIGN)


comments not archived

referenced by

2010/11/12 Suddenly, in a bit more time than a blink of an eye, "standards support" becomes "less i18n support"

go to newer or older post, or back to index or month or day