by Michael S. Kaplan, published on 2012/05/04 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/05/04/10300975.aspx
You might be tired ot me blogging about Digit Substitution.
I mean, it has been a rather commonly covered topic, over the years.
The entire issue can often be thought of as a pitched battle between competing forces.
One of the fundamental forces pushing us away from it is the one embodied by the moves of Internet Explorer that I described in Suddenly, in a bit more time than a blink of an eye, "standards support" becomes "less i18n support".
This is the move to be more conformant to standards.
And standards don't capture this notion.
It is also embodied in blogs like "Digit substitution is maybe a tolerable hack for displaying UI, but it’s definitely bad if you’re creating content."
You know, where people who work in the area and have some say over some of the overall direction of the product will go on the record with how problematic and "off the reservation" the feature often is.
Intererestingly, when it comes to Arabic, one of the opposing forces that is in favor of Digit Substitution is me.
Because, as I was reminded just yesterday, we have a bunch of customers who don't give a fig for international standards.
And they couldn't care less about whether the support of "Context" type Digit Substitution has implementation limitations in our UI.
They still want it, in pretty much half of the Arabic language locales.
When we pointed out many of the limitations and asked whether they would prefer either the "None" aka "never substitute" or "National" aka "always substitute" settings.
Across the board, the answer was:
It should be contextual as it is more convenient if digits come in the same script the context is. So, it should be contextual.
I realized something, in that moment.
Our concerns about showing different kinds of digits on the same screen, on the "limits of the GDI notion of Context"?
Not so important.
This isn't about us!
It's about them, and their content -- their expectations.
Suddenly, as long as developers have that same view, The evolving Story of Locale Support, part 22: Digit Substitution 2.0 is starting to look even more impressive.
And me?
I serve at the pleasure of the customer.... :-)
Random832 on 4 May 2012 9:08 AM:
> They still want it, in pretty much half of the Arabic language locales.
Are you sure what they _want_ isn't simply to see and type their own digits by whatever means, and the rest is simply the implementation of this want that you think is easiest for Microsoft to deliver? Why not instead make parsing functions digit-type-agnostic (or at least accept both ASCII and one specific per-locale type, if that's too much work), and allow output functions to localize to the real unicode codepoints of the different sets of digits?
Michael S. Kaplan on 4 May 2012 1:30 PM:
The core team considers it by design that parsing does not act that way, and that is not a feature really being requested here....
Random832 on 7 May 2012 8:02 AM:
" that is not a feature really being requested here...."
That's my point - anything requested is requested in terms of _visible_ behavior. Digit substitution means they can type digits, they'll be ASCII in data but [sometimes] show up as native digits, and will be accepted by parse functions. A different route would have been to have the keyboard have real Arabic digits, and everything else works with those code points. Both lead to broadly the same user-visible behavior, and digit substitution isn't obviously better than the other way
Michael S. Kaplan on 7 May 2012 9:48 AM:
You do have to factor in the backcompat issue, and the fact that we never change keyboards....
Random832 on 9 May 2012 7:25 AM:
Right, but there is a difference between "this is the right thing" and "this is the best we can do given these policies and the calls we've made in past versions", and it sounded like you were stating the former, and overstating that users 'want' something that is in fact an implementation detail.
Michael S. Kaplan on 9 May 2012 8:13 AM:
Actually, I was contrasting what some of our developers 'wanted' based on what they thought people might want, versus what users generally, actually expected and if they thought about it 'wanted'.
Users don't know what they want until they see it, most of the time....
:-)