by Michael S. Kaplan, published on 2008/08/04, original URI: http://blogs.msdn.com/b/michkap/archive/2008/08/04/8823327.aspx
People who are regular followers of my words may recall my recent blogs Somehow I just get a Visual of the Logical Song (as sung by Supertramp) and So logical that even Mr. Spock (and my fiancée?) would approve.
Those blogs were actually in response to some efforts of folks to get a handle on the lack of intuitiveness of the user interface there.
Obviously the current behavior has been around for a long time, and it is solidly grounded in the way that Microsoft implements UAX#9: Unicode Bidirectional Algorithm -- which is important here not just because it helps to determine how text is displayed in these controls in Regional and Language Options, but it is also behind how these controls will behave when text is typed into them and when the cursor moves around in them as well.
The bottom line is that text which starts off and ends up with entirely LTR text or entirely RTL text will have specific behavior when you hit the HOME key and the END key.
If this behavior were mysteriously changed in just these controls, people would have serious trouble using them!
Thus, looking at another tab in Regional and Language Options "Customize" dialog, in a control starting with strong LTR or strong RTL text, hitting the HOME key will place the cursor in a very clear place:
just as will hitting the END key:
Once and for all this bit of reality can settle the current behavior.
However, and here is where I am not going to gloat just because it just so happens that I was right, there is still a problem here.
The generic question of whether this behavior is correct or not still exists.
The fact remains that it can be confusing.
Because an unflawed design should ideally be able to produce intuitive results -- the fact that there is something non-intuitive here suggests that might be important to take a step back and try to determine if it is the design that has a conceptual flaw, or just the way in which it is implemented.
Do let's take that step back.
The current behavior is the expected design of the LTR text in the control. And that text is made up of tokens that are hard-coded for software developers calling GetDateFormat, GetDateFormatEx, GetTimeFormat, and GetTimeFormatEx. These tokens can't change their directionality or this would break the way that developers use them.
Or can they?
Maybe you have seen the blog I wrote back in February 2006 Some localized Regional and Language Options tags, where I showed how many different localized versions of Windows actually do localize those format tags in the user interface, and the UI properly converts the localized tags to the hard-coded ones that the function expects.
Remember that scene near the end of the Wizard of Oz when the balloon has taken off and Dorothy is so sad because she has no idea how she'll get home?
You know, the bit where we get the whole educational; spiel:
Tin Man: What have you learned, Dorothy?
Dorothy: Well, I - I think that it - that it wasn't enough just to want to see Uncle Henry and Auntie Em. And that it's that - if I ever go looking for my heart's desire again, I won't look any further than my own backyard, because if it isn't there, I never really lost it to begin with. Is that right?
The localizers have had the power to "fix" this issue all along!
Now of course looking at Hebrew, Arabic, Urdu, Farsi, or Pashto, the RTL languages into which Windows has been fully or partially localized to date, none of the tags have ever been localized.
For localization, the issue is more than just clicking one heels together three times and saying "there's no place like my native language". There are, for example, issues to consider in the localization -- like if you use
י
(U+05d9, aka HEBREW LETTER YOD) for one of the tags in Hebrew, you run into problems if you have to double it up since both
ײ
(U+05f2, aka HEBREW LIGATURE YIDDISH DOUBLE YOD) or just two plain old YODs will look like something that might offend people to use in such a context since in Hebrew it is one of the names of God that are considered holy enough that they should only be used in a holy context such as a prayerbook. While it is arguably the most mundane of those holy names, it is nevertheless one of them, and thus would be problematic.
Anyway, such issues would have to be figured out and decided upon, and people would have to test things out and see if the new behavior confuses fewer people than the old behavior has (with the explanatory key defined right there in Regional and Language Options, I am definitely more in favor if the intuitive behavior than people being wed to d/m/y/t and such, unless they did find it to be confusing).
Perhaps me suggesting all this is my own way of being gracious in victory (to the extent that being right is a victory; many spouses (spice?) will tell you that when one is right it is important to apologize immediately!).
But to be honest, that is all just stuff that occurs to me in retrospect. Mentally, I took it all through the process I described above, a process that is no less than one would hopefully desire (if not expect) of a good specification that as describing the intended behavior. :-)
This blog brought to you by ײ (U+05f2, aka HEBREW LIGATURE YIDDISH DOUBLE YOD)
referenced by