by Michael S. Kaplan, published on 2012/01/13 09:31 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/01/13/10256391.aspx
The other day, I was forwarded a question by a colleague.
They wanted to know why the following cod was not letting them detect Bidi properly:
UINT ret = GetLocaleInfoEx(LOCALE_NAME_USER_DEFAULT, LOCALE_IREADINGLAYOUT, Layout, ARRAYSIZ(Layout));
if(ret && (Layout[0] != L'0')) {
// Treat the locale as Bidi: WARNING: THIS CODE IS WRONG!
}
Now this code is bad for several reasons.
First of all, let’s look at the doc topic for LOCALE_IREADINGLAYOUT:
Windows 7 and later: The reading layout for text. Possible values are defined in the following table.
Value | Meaning |
0 | Read from left to right, as for the English (United States) locale. |
1 | Read from right to left, as for Arabic locales. |
2 | Read vertically from top to bottom with columns to the right, and read from right to left, as for the Japanese (Japan) locale. |
3 | Read vertically from top to bottom with columns proceeding to the right, as for the Mongolian (Mongolian) locale. |
Now obviously code that assumes everything other than 0 is RTL is going to have problems.
But okay, that is an easy fix.
There is a deeper problem, one that is a bit more insidious….
Let’s start by looking at what locales fall into each category:
Value | Locales that have this value |
0 | English, Russian, Thai, etc. |
1 | Hebrew, Arabic, Persian, etc. |
2 | Japanese, Chinese, Korean |
3 | Mongolian |
Now in practice, vertical support in applications is such that the majority of text in Mongolian, Japanese, Chinese, and Korean should be treated as if it was in that first category slong with English. Therefore, returning 2 or 3 is a kind of unrealistic idealism, which ultimately makes the code even more flawed than previously thought!
There is more to the story beyond this one buglet, and I’ll be talking about this further, soon….
referenced by