by Michael S. Kaplan, published on 2011/12/30 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/12/30/10251957.aspx
Once upon a time, Windows had two kinds of day names.
There were the actual day names, which could be queried via the LOCALE_DAYNAME* constants, and eventually the DateTimeFormatInfo.DayNames Property.
And there were the abbreviated day names, which could be queried via the LOCALE_SABBREVDAYNAME* constants, and eventually the DateTimeFormatInfo.AbbreviatedDayNames Property.
The second group was in theory more suited to calendars and such, where space could be quite constrained.
Now when I say abbreviated day names, I should have put it differently.
And called them "abbreviated" day names, instead.
Or perhaps <air quotes>abbreviated<air quotes>, if you know what I mean!
Because for many locales, the informants giving us data just shrugged and responded simply:
We don't abbreviate these!
Not such a great story for mythical calendars, mind you, but their principal argument drowned out the theoretical scenario quite handily.
After all, we weren't in the localizable calendar business back then!
We did have a MonthCal common control. And a DTPicker common control. But their built-in calendar "grid" pieces were not localized (and incidentally only supported Gregorian) -- a long drawn out point of contention, as I mentioned in WinForms DateTimePicker and MonthCalendar do not support culture settings.
It made abbreviated names pretty freaking theoretical!
Until Vista, that is.
That is when we saw the updates described in my blog New in Windows Vista: updates to clock and calendar.
Underneath those changes, we realized that the LOCALE_SABBREVDAYNAME* constants simply would not do. And there was no algorithmically way to reliably create them
Thus were born the LOCALE_SSHORTESTDAYNAME* Constants, and of course the DateTimeFormatInfo.ShortestDayNames Property.
But before finally settling on those names, it is important to point out the original name.
From an evidentiary standpoint, the defense lawyer might object by claiming this would be circumstantial but A.D.A. Ben Stone would say "goes to state of mind".
The judge would agree.
Way too much Law & Order in my past, obviously -- but the idea of Ben Stone trying my Law & Order: World-Readiness Unit is too seductive to ignore!
We called them:
LOCALE_SONELETTERDAYNAME*
initially, and
LOCALE_STWOLETTERDAYNAME*
when data started coing in that was often two letters and people started complaining on technical and suability grounds about the name. We even ntertained
LOCALE_SUPERSHORTDAYNAME*
at one point!
And when the request for data went out to all of our subsidiary program mangers, we gave the name prominent placement so our intent would be obvious.
But sometimes they would simply copy and paste the full day names, saying
We don't abbreviate these!
And our answer was unambiguous and unchanging, in the manner of "tough love":
Look, we've wanted the MonthCal to be localizable/localized for years now, and we are doing that. But in order for it to succeed, we need very very short day names.
You are welcome to ignore the directive, but in that case we are going to truncate the names for you.
Consider this data request to be your chance to decide how things will be truncated!
For some locales they realized how dangerous that would be. Like Hebrew, with day names of like יום ראשון and יום שני and so on, where truncation would make them look the same, they realized the risk of trying to call our bluff!
Some of them continued to push back, insisting that the needed two letters or maybe even three in select cases, e.g. for Hungarian:
H K Sze Cs P Szo V
and we shrugged and said fine, though on occasion they may find themselves truncated. But we knew that if they were calendars that even the truncations would be okay in such cases, since no user would ever expect calendars to re-order their day names!
When you get down to it, in a calendar grid, no English speaking user will find a top row of:
S M T W T F S / M T W T F S S
vs.
Su Mo Tu We Th Fr Sa / Mo Tu We Th Fr Sa Su
to be completely incomprehensible, unless they don't know what a calendar even is!
A lot of this has been previously discussed, in blogs like {recycled joke here} It could have been called LOCALE_SSINGLESERVINGDAYNAME*, but the focus was on how we were trying to "tame" the language experts and informants, all of whom we needed to provide data. And also how we lost a little bit of the mission and the scenario ourselves until we realized some of the requests we were getting just were not reasonable....
However, since that time in the days of Longhorn when we wrote the code or Vista when we shipped it, people have been using and enjoying the LOCALE_SSHORTESTDAYNAME* Constants, and of course the DateTimeFormatInfo.ShortestDayNames Property, and a new phenomenon has cropped up many times.
Someone will insist on the need to have these LOCALE_SSHORTESTDAYNAME*/ShortestDayNames values to never be more than two characters, or occasionally even one character (even though almost none of them are one character by now!).
We have to adopt a "talk to the hand" attitude here -- and tell them that the LOCALE_SSHORTESTDAYNAME*/ShortestDayNames are as short as they can reasonably across every language.
And that they are just going to make sure that they design their feature with that reality in mind.
We don't call them the AlmostButNotQuiteShortestDayNames for a very very good reason -- because they are not!
Luckily, we point out just as we did with the informants/experts, though on occasion they may find themselves truncated, we know that if they were calendars that even the truncations would be okay in such cases, since no user would ever expect calendars to re-order their day names!
There are some [as of yet unconfirmed] reports of a few ShortestDayNames that are actually incorrect -- if there are such then those would be definitely considered bugs. But that issue would be completely unrelated....
Aaron.E on 30 Dec 2011 8:29 AM:
I've always preferred the McCoy/Carmichael era myself.
Michael S. Kaplan on 30 Dec 2011 8:35 AM:
Well, beyond my crush on Jill H. that I would never act on (which McCoy did), I always felt like more of a Ben Stone myself, anyway. :-)
Simon Buchan on 30 Dec 2011 6:07 PM:
So OS API naming conventions are against "intended use" naming, like LOCALE_SCALANDERCOLUMNNAME, for example?
Michael S. Kaplan on 30 Dec 2011 6:15 PM:
Well, we aren't exactly oozing with consistency when it comes to Win32 API guidelines....
referenced by
2012/02/08 The awkward insert of shortest day names...