by Michael S. Kaplan, published on 2011/11/28 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/11/28/10242018.aspx
Leo's question was, like many of the questions I cover here, pretty interesting:
Hello,
I’m writing UI automation for ***REDACTED***, and dev UI displays number in native Arabic digits for ar-SA. Hence, I was trying to convert my test integers into Arabic digit strings so I can do string comparison. However, this code below doesn’t seem to work. Anybody knows what’s the proper way to do this in C#? Thanks.
CultureInfo info = new CultureInfo(CultureInfo.CurrentCulture.LCID);
info.NumberFormat.DigitSubstitution = DigitShapes.NativeNational;
int num = 3;
Log.TraceInfo("Name: " + info.Name); // this outputs Name: ar-SA
Log.TraceInfo("NUMBER: " + string.Format(info, "{0:d}", num));
// this outputs NUMBER: 3
Now there are a few different problems here.
First of all, as I initially mentioned more than six years ago in Is Whidbey's international support finished?, these properties involving digit substitution (NumberFormatInfo.NativeDigits and NumberFormatInfo.DigitSubstitution) and the DigitShapes enumeration all are data-only properties not hooked up to the behavior of the cultures they are nominally connected to.
And second of all, even now over six years later, there had been no move to change that, to add support for digit substitution.
I don't want to ignore the related third of all, which is that even if you ask the question of the CurrentCulture, which is directly connected to the current user default locale in Windows and picks up every other customization for data formats, it does not give you the current user override values. So you can't even use this information provided by .Net to get the data being used.
Thankfully, none of this matters.
Because Digit Substitution as a feature is a font level switch which does not change the underlying numbers themselves.
Therefore even if these other problems did not apply, the fact is that the code, which looks at the numbers themselves, is giving accurate answers, returning actual ASCII digit values.
And beyond that the only way to retrieve the actual digits based on shape would probably involve OCR technology.
All of this underscores a tangential point not often discussed -- that the underlying technology in screen readers never gives any indication that digit substitution has been applied -- so if you're blind we don't even act like we're substituting anything.
And thus the title of today's blog, and the irony thereof....
I can't even imagine how we'd do this any other way, really. Can you?
Joshua on 28 Nov 2011 9:13 AM:
Now if the guy was in a pipeline stack you'd have a serious problem.
Alex Cohn on 5 Dec 2011 10:00 AM:
You can probably avoid OCR to perform these tests: choose the same background and fonts for the ground truth, use a screen grabber and compare the bitmaps.