by Michael S. Kaplan, published on 2012/02/03 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/02/03/10263576.aspx
There are several LCTYPE values suitable for use by GetLocaleInfo and GetLocaleInfoEx that act as abbreviations.
Like the seven LOCALE_SABBREVDAYNAME* values representing the days, which are documented as:
Native abbreviated name for [Day]. The maximum number of characters allowed for this string is 80, including a terminating null character.
Or like the twelve LOCALE_SABBREVMONTHNAME* values representing the months, which are documented as:
Native abbreviated name for [Month]. The maximum number of characters allowed for this string is 80, including a terminating null character.
And there are helpful doc topics like Day, Month, Year, and Era Format Pictures that say things like:
| d | Day of the month as digits without leading zeros for single-digit days. |
| dd | Day of the month as digits with leading zeros for single-digit days. |
| ddd | Abbreviated day of the week as specified by a LOCALE_SABBREVDAYNAME*value, for example, "Mon" in English (United States). |
| dddd | Day of the week as specified by a LOCALE_SDAYNAME* value. |
| M | Month as digits without leading zeros for single-digit months. |
| MM | Month as digits with leading zeros for single-digit months. |
| MMM | Abbreviated month as specified by a LOCALE_SABBREVMONTHNAME* value, for example, "Nov" in English (United States). |
| MMMM | Month as specified by a LOCALE_SMONTHNAME* value, for example, "November" for English (United States), and "Noviembre" for Spanish (Spain). |
Very helpful, right? :-)
Well, they might have done a few abbreviated other language examples, but I suppose we can guess what they might be. No harm, no foul....
Any developer can wrap their head around these examples and this information.
Go for it, developers!
Oh, wait -- before I forget, there are some problems with going forward with this knowledege here.
Like the not insignificant number of locales that don't have abbreviated names that are any different than the regular month names.
So (for example) many locales will have a LOCALE_SABBREVDAYNAME5 that is identical to LOCALE_SDAYNAME5, a LOCALE_SABBREVMONTHNAME10 that is identical to LOCALE_SMONTHNAME10. And so on.
They don't want to mention that? Seems like oit ought to be in there somewhere....
It may certainly put a cat among the pigeons for some unususpecting developers!
Oh yeah, and it gets worse.
Like let's look at the Japanese abbreviated month names:
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
| 12 |
Um, wait.
Isn't that what M (Month as digits without leading zeros for single-digit months) is supposed to be for? That's just unexpected.
We do not' document that either -- even though we've been doing it for years!
And there are other strange examples, too. Perhaps you have a favorite?
There is of course what we do for zh-CN abbreviated and full month names:
| 1月 | 一月 |
| 2月 | 二月 |
| 3月 | 三月 |
| 4月 | 四月 |
| 5月 | 五月 |
| 6月 | 六月 |
| 7月 | 七月 |
| 8月 | 八月 |
| 9月 | 九月 |
| 10月 | 十月 |
| 11月 | 十一月 |
| 12月 | 十二月 |
Just keep in mind in that 月 is "month" and you are pretty much reading Chinese now, right? :-)
Now I'm not saying it's wrong -- it is right, but it is odd if you are not Chinese to think of the difference here as being abbreviated versus full month names.
Remember what we have for the Japanese abbreviated month names? We have the same thing for Korean -- oh, and also Czech and Slovak, too!
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
| 12 |
I am fully prepared to assume that this different approach might be expected in East Asia.
But that it might also be in Slovakia and the Czech Republic too? That's new information!
It is hardly my first intuitive guess that those are the expected abbreviations for these Czech and Slovak month names, right?
| leden | január |
| únor | február |
| březen | marec |
| duben | apríl |
| květen | máj |
| červen | jún |
| červenec | júl |
| srpen | august |
| září | september |
| říjen | október |
| listopad | november |
| prosinec | december |
Now all I know is that if I am a developer I have a somewhat foggy notion of what MMM means.
Any developer or designer trying to create a calendar might.
But for many locales, it clearly ought to be documented in some conceptual topic that I should be ready to assume that MMM might be MMMM. Or even M!
Jan Kučera on 3 Feb 2012 7:35 AM:
(reposting)
Hi Michael, yes, except the first typo (should be 'leden') these are the full month names here and in Slovakia as well.
There are no official abbreviated names in Czech (although I have seen some attempts on translations from English). You can either try to take the first syllable, which yields strange results (with ú·nor, zá·ří, ří·jen at the very least) as I am aware of only two specific abbreviations ending with vowels (one of which is accuted). The more common attempt is to just take three letters (čvc for červenec) but this yields the horrible úno|r. This seams to be more feasible with the Slovak words (at least you can have 3 letters and always end with a consonant) but I have some doubts they would like it.
No, this just does not work. Your guess seems to be correct to me. :)
Michael S. Kaplan on 3 Feb 2012 8:25 AM:
Exactly! But at the very least we need to not lead developers down the wrong path. Not everyone reads my Blog. :-)
Alex Cohn on 5 Feb 2012 10:03 AM:
Which only proves again (cf. your previous post about "today") that localization of a calendar application (or even widget) goes far beyond applying another locale. There should actually be a lot of culture-dependent logic, even if it does not go beyond the Gregorian calendar.
Alex Cohn on 5 Feb 2012 10:05 AM:
BTW, ddd for Hebrew are also cool: א, ב, ג...
referenced by