Short date formats, as a general rule, are pretty consistent.

They always have a d or a dd. And not a ddd or a dddd.

Which is just another way of saying that we have 6 or 06, but never Sat or Saturday.

They always have an m or mm. And not an mmm or an mmmm.

Which is just another way of saying that we have 1 or 01, but never Jan or January.

And they always have a yy or yyyy.

But there is something else about rules that is important to remember.

There is always an exception that proves them!

Take Japanese, for example.

It's LOCALE_SDAYNAME* values have been consistent for quite some time:

As have its LOCALE_SABBREVDAYNAME* values:

And its LOCALE_SSHORTESTDAYNAME* values:

Savvy readers will note that the latter two sets are identical -- the abbreviated name is the shortest name, every day of the week.

And now we get to the formats.

The default LOCALE_SSHORTDATE for ja-JP is:

yyyy/MM/dd

And the full list including optional alternate formats is:

Wow! Formats five through seven of the 8 include the day name in parentheses!

And have had this for many versions of Windows!

You can see it in Regional and Language too, shown here for Windows 7 and Server 2008 R2:

Now it is easy to get unhappy about this break in the rules.

Even though it has been going on for more years than most of these people got their jobs!

Or, as we learned from prior blogs Sometimes MMM is MMMM, other times MMM is M! (aka Not all abbreviations are created equal) and The awkward insert of shortest day names..., relying in general rules in locale data is a bad idea.

A really, really, really, REALLY, REALLY bad idea.

Just as it was with abbreviated months and their use, so it is with abbreviated days.

Please just embrace the differences, and give people their preferences.

They'll be grateful in Japan.

And in the rest of the world.... :-)

When you use SMS/Text capabilities, you have 160 bytes per text.

This makes English the smallest language, and every other language a little bit bigger.

And it makes some a lotta bit bigger.

If you are using supplementary characters, you'll be a lotta bit biggest!

Thank goodness I have unlimited texting!

I decided to play around with this on my Nokia Lumia 920 running Windows Phone 8.

For this exercise, I spammed my good friend Lauren Witt with a few texts.

Text #1 was 160 ASCII digits.

You know,

0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789

In UTF-8, this is 160 bytes.

Text #2 was 30 emoticons.

You know,

😃😃😃😃😃😞😞😞😞😞😃😃😃😃😃😞😞😞😞😞😃😃😃😃😃😞😞😞😞😞

A stream of five U+1F603 characters followed by five U+1F61E characters, over and over.

In UTF-8, (30 * 4) or 120 bytes.

Notice how it had me at 60/70 characters there for my 120 bytes.

The actual UTF-8 (care of Mark Davis's site), is:

F0 9F 98 83 F0 9F 98 83 F0 9F 98 83 F0 9F 98 83 F0 9F 98 83 F0 9F 98 9E F0 9F 98 9E F0 9F 98 9E F0 9F 98 9E F0 9F 98 9E F0 9F 98 83 F0 9F 98 83 F0 9F 98 83 F0 9F 98 83 F0 9F 98 83 F0 9F 98 9E F0 9F 98 9E F0 9F 98 9E F0 9F 98 9E F0 9F 98 9E F0 9F 98 83 F0 9F 98 83 F0 9F 98 83 F0 9F 98 83 F0 9F 98 83 F0 9F 98 9E F0 9F 98 9E F0 9F 98 9E F0 9F 98 9E F0 9F 98 9E

But that's kinda besides the point.

Basically four bytes per character, which is how well-formed UTF-8 supplementary characters behave.

Then, my final spam.

Six ASCII digits followed by five emoticons.

So that is (6 + (5 * 4)) * 4 or 104 bytes.

You know,

012345😃😞😃😞😃012345😃😞😃😞😃012345😃😞😃😞😃012345😃😞😃😞😃

Notice how it had me at 64/70 characters.

The UTF-8 was:

30 31 32 33 34 35 F0 9F 98 83 F0 9F 98 9E F0 9F 98 83 F0 9F 98 9E F0 9F 98 83 30 31 32 33 34 35 F0 9F 98 83 F0 9F 98 9E F0 9F 98 83 F0 9F 98 9E F0 9F 98 83 30 31 32 33 34 35 F0 9F 98 83 F0 9F 98 9E F0 9F 98 83 F0 9F 98 9E F0 9F 98 83 30 31 32 33 34 35 F0 9F 98 83 F0 9F 98 9E F0 9F 98 83 F0 9F 98 9E F0 9F 98 83

which is obviously a little bit smaller.

But it still gave me weird limitation estimates, this time 64 characters out of 70.

So. Smaller, but bigger?

I think their logic is a little off here.

One last text.

150 ASCII digits, a space, and two emoticons.

You know, 

012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 😃😞

Now, like every other time, this text should fit under the 160 byte limit. The UTF-8 is 150 + 1 + (2 * 4) or 159 bytes, 1 byte short of the limit.

Let's see what the phone says:

Um, 155/201, taking three messages?

What the hell?

Someone has an algorithm bug to fix in the WP8 Messaging app, I think...

In the end, that last text was just one text, containing 159 bytes.

Yet the miscalculation was used and according to Lauren, the phone sent out three texts!

For the record, I'd be more forgiving if they were only off estimating when it was over the limit. There is no excuse to erroneously claim I'm over the limit when I'm not, and definitely no excuse to spam the error out into the world outside!

Note that similar repros can be constructed for actual languages using 2 bytes, 3 bytes, and/or 4 bytes for UTF-8 - all of them put the WP8 messaging app in "4 byte mode".

Not really an April Fools Day joke, though basic errors in arithmetic read that way to me!

(I originally found the problem in actual texts, not looking for bugs -- so be warned Ken if they try to Won't Fix the bug I'll have many real world examples for the reactivate!)

Either way, I'm glad I have unlimited texting -- if not, I would submit the bill to the Windows Phone team. :-)

And isn't it cool to see the font support? Segoe UI Symbol, I presume. Keyboard support for Emoji is also sublime....

Still loving my WP8 running Nokia Lumia 920.

If they gave me access to newer builds, I could selfhost/dogfood. WP would get the bug reports pre-ship, and NDAs would limit blogs about bugs - everybody would win! ;-)

In any case, I have new respect for the language based pain some languages have based on their arbitrary place in Unicode, something I've both spoken and written about before....

Special thanks to Lauren for putting up with my 6 spam texts and still being willing to go to the symphony with me this last weekend. Like all my friends, she puts up with a lot! :-)

The question, as usual, was simple:

We have a problem. We installed the Turkish Lira update, and since then we are seeing a question mark whenever we should be seeing the new Lira in our application.

It looks right in Regional and Language Options. And in Excel.

Did we miss a step here?

Well, it wasn't a "step" per se.

But it is updating the application to support Unicode, so (for example) if you call GetCurrencyFormatEx or GetCurrencyFormatW, you will get a properly formatted string with the currency.

Code page 1254 was registered with IANA on May 3, 1996 (ref).

And code pages cannot be changed - it has been a disaster the few times we tried.

I can think of four workarounds:

• Replace the application with one that supports Unicode;
• Fix the application to support Unicode for those strings;
• Change the currency symbol back manually in Regional and Language Options.

Not great, but this kind of change, this kind of progress requires up-to-date software.

Unicode software.

'Michael, how do I support GB 18030 ?!?'

This is a problem that has been played over email messages to me many times since 2005 (when GB18030 was first released).

Someone (in this case a developer named Carla) has been given the assignment to support the standard, due to plans to start shipping to China.

The name is easy. It starts with GB. GB stands for Guobiao (simplified Chinese: 国标; traditional Chinese: 國標; pinyin: Guóbiāo), Chinese for national standard.

You can see a bunch of them in the GB standards Wikipedia page.

There are many more than this, believe me.

Some of them are simply Chinese translations with no substantive changes of standards created elsewhere that China wants people using.

GB18030 is not one of those standards.

You can see a pretty good description of it in the Wikipedia article here. They cover many of the problems people found trying to work with it since 2005.

And there is now a formal process that allows China to review "GB18030 compliance".

This is important because officially, GB18030 is not defined as one that has to be completely followed -- only a subset is mandatory.

One does not have to assume that one must support every language Unicode does just because GB18030 maps to all of Unicode.

Because testing that is done centers on support of languages and scripts that are relevant, interesting, and/or important to China.

Currently, the tests principally focus on the way text is input, displayed, stored, sent, and retrieved for:

• Chinese Han
• Other Han like Kanji, Hanja, and HKSCS defined ideographs (less important, but still looked at)
• Tibetan
• Mongolian
• Yi
• Uyghur
• Phags Pa
• Tai Le
• New Tai Lue
• Lisu

and so on. Microsoft has font support for most of them (and for all of the required ones), and keyboard support for most of them as well.

Now one really important aspect of how standards work in China is how they refer to each other.

So for example Uyghur support and its bidirectional requirements don't have to be spelled out in detail in GB18030; it can point to another standard that includes the information.

There isn't always uniform effort to make sure standards written before GB18030 was born explicitly spell out what GB18030 support means for it.

But they are not shy about explaining how it all has to work.

Ken Whistler once famously explained how things would be okay after China locked in 1-to-1 mappings between GB18080 and Unicode:

Think of it as UTF-GBK.

Which kind of sums it up. :-)

Mostly, you just need two things to support it:

• Good support of Unicode, especially parts interesting/relevant/important to China, and
• Good conversion back and forth between GB18030 and Unicode.

And that's really it!

Now note that platform pieces do most of the work here; if you run on Windows (for example), you don't have to make every font and keyboard and rendering engine.

A lot of the time, we (and others) have you covered when you use our (or their) stuff.

You can just focus on the hardest part: make sure you are using it correctly!

Now for the rest -- the registration and such -- that's for the lawyers to jump on, not you....

The other day, in Microsoft Word: 15 -- Microsoft Windows: 0, I wrote about a case where everyone ignored Windows and did their own thing.

Generally speaking, what Word in particular did was useful to more people than it wasn't.

But over in the Suggestion Box, Ernst Tremel asked:

I made a Keyboard Layout „ETDeNWi8.dll“ for Devanagari-Input in Windows 8 Release Preview using Microsoft's Keyboard Layout Creator Version 1.4.

Dies file „ETDeNWi8.dll“ had been installed in

Windows\System32

like all the other Keyboard Layouts, too.

But I experienced different behaviour of this „ETDeNWi8.dll“ Keyboard Layout:

In Word XP on Windows 8 Release Preview, Libre
Office Writer on Windows 8 Release Preview, and
Wordpad on Windows 8 Release Preview

this „ETDeNWi8.dll“ Keyboard Layout

is working correctly as expected.

But in Word 2010 on Windows 8 Release Preview
this „ETDeNWi8.dll“ Keyboard Layout is NOT
working correctly as expected.

What may be the reason for this?

 Now we have a problem where Word 2010 is not properly supporting a keyboard, even though everyone else supports it!

Now Ernst didn't give any specifics about the problems he was hitting, which makes it pretty much impossible to diagnose what is going on here.

But, I will do a lazy psychic debug and wonder if my You're not the one out of sequence, and that's the Word blog.

And if turning off sequence checking will help.

But whether that's it or not, Word still lost the battle this time.

Score?

Microsoft Word: 15      Microsoft Windows: 15

It all started with an innocent question. the innocent questioner asked:

Can you point me to any enhancements we are building for Datetime
parsing (string + datetime format to a Datetime structure) for Modern
C++ apps in the next version of Windows?

thanks

Our questioner came armed with a dangerous thing: knowledge.

Knowledge of the rich history of datetime parsing and formatting in .NET, which was required to do this support on spec, as the heir apparent to COM/OLEAUT32 in the hearts and minds of developers.

And of an even richer history of datetime parsing and formatting in COM/OLEAUT32, the first brave knight to extend Win32 where even Win32 would not dare to go.

The Windows developers knew it was

The wrong thing to do™.

But did those Developer Division developers listen?

Yeah right.

There was a long history of each group preaching sermons that the other one would ignore.

It's an ironic and unfortunate fact that there is a specific subset of the population that really dislikes being told YOU'RE DOING IT WRONG™!

It is of course the people who are, in fact, doing it wrong!

The questioner's innocent question went down a few blind alleys, with people asking about the customer scenario requirements, etc.

Then, I lost patience with the blind alleys and answered the original question directly:

To answer the original question:

Can you point me to any enhancements we are building for Datetime
parsing (string + datetime format to a Datetime structure) for Modern
C++ apps in the next version of Windows?

AFAIK, there are no specific improvements from Windows 8.

Michael

This answered the original question and bombed the village of the innocent questioner's hopes.

But there was one more message to impart, which my colleague Eric readily strafed the survivors and bayoneted the wounded:

We do not support date or time parsing on purpose. Almost invariably, the legitimate scenarios around this
should be handled by date or time picker controls. The illegitimate scenarios abound and by not providing
this, we can better direct people to use a standard format that can then be unambiguously parsed.

It seems to me that if you have to convert the format using a regex, you already know the identities of the
components and you might as well just handle the rest of the parsing (I’m not sure that time_get will add
enough value for you. It does have limitations in the scope of the dates that it can parse (I think the upper
limit is 2030 right now, though they have a bug to extend that out).

I don't know about you.

But buried in those two paragraphs is easily the most polite

YOU'RE DOING IT WRONG™!

that I have ever had the pleasure of reading in my email inbox! :-)

Over in the Suggestion Box, Stuart asked:

Someone just posted this image on my Facebook: sphotos-b.xx.fbcdn.net/.../21765_3587733825712_796558586_n.jpg

My first reaction was to wonder if it's a real keyboard, and if so, for what country. My second reaction was: I bet I know someone who'd know how to find out!

I could probably google the answer to what keyboard that actually is, if any, but it seems like an interesting question in the abstract: given only a picture that shows a small fraction of the keyboard layout, is there some way to find out, either in the documentation or programmatically which keyboard it is?

The image in question:

Now in the past I have posted how the folks who create the actual hardware keyboards (in Microsoft Hardware) and the people who own the software layouts in Windows (me) are not in the same group.

And that we seldom communicate.

Now in most (perhaps all?) European layouts, the Euro was added to the AltGR+E keystroke combination.

And in Microsoft Word, sometimes they override us and insert it there.

And the Euro is quite visible in their Insert Symbol UI:

So it does not surprise me that things would be so prominent in the keyboard hardware. Probably most European keyboard hardware has this, today.

Because Microsoft Word trumps Microsoft Windows, in this case, at least.

In the hardware sold in Europe.

And in the hearts and minds of most users. :-)

Now I love Windows, but you know what Love means in Tennis.

It means Zero.

C'mon people! Word sits on top of Windows, so of course it often gets to win.

If your sister is sitting on her brother, she won that fight!

If there was ever a persistent force in my universe, it would have to be the Acolytes of Colemak.

No matter how many times they lose their Wikipedia page, and no matter how often I tell them that they will not be added to Windows as long as I own new keyboards, they keep popping back up.

They are Chumba Wumba incarnate (they get knocked down, but they get up again, and you're never gonna keep them down).

They are weeble wobbles personified (they wobble, but they don't fall down).

Just the other day, in an offtopic comment to Why aren't there any Cherokee keyboard layouts on Windows Phone 8?, asdf (presumably not his real name!) asked:

Hey Michael, is there any way to get the Colemak keyboard layout among the built-in layouts in the next Servive Packs for Windows and all future versions of windows (Or at least submit a feature request for it on Microsoft's internal bug database)?

What on earth does that have to do with Windows Phone 8?

And pardon me, but what the heck kind of genuine Colemak user is named asdf anyway? Wouldn't a genuine Colemak user be arst?

And yet, despite how often they articulate their desires, they aren't very good about rigorously going about that articulation.

Heck, their downloadable Windows version (available here) doesn't do what is (arguably) one of the most important defining feature of Colemak: it does not remap Caps Lock to Backspace!

I guess they never figured out how to make KBDUTOOL.EXE remap the CAPS LOCK key, did they? :-)

No OEM or IHV sells a keyboard that has its layout imprinted on its keys.

No national standard in any country for any language uses its layout - since it is unsuitable for every language.

And it lacks the punch of the Dvorak layout, which despite being more common is also readily trounced by QWERTY.

I don't know what will happen when Shai Coleman passes on from this mortal coil -- who will be its champion?

Like this bit from Pulp Fiction:

     "Do you know what they call a quarter pounder with cheese in Paris?"

     "They don't call it a quarter pounder with cheese?"

     "They have the metric system. they don't know what the *** a quarter pounder is."

 This change, something that McDonald's knew and Vincent Vega (John Travolta) learned while was in Europe but Jules Winnfield (Samuel L. Jackson didn't know is that if to give something to people that they don't understand, they won't be happy accepting it.

Maybe McDonald's came to France with their quarter pounder with cheese and found at the hard way that people didn't know what the f*** a quarter pounder was.

But they learned, either way. They learned....

kind of like Microsoft.

They have a bit of user interface about fonts in programs like WordPad:

 People who speak English generally understand that the B button makes text Bold, the I button italicizes, and the U button underlines. They can usually understand the crossed out abc button and the bigger A and smaller A buttons from context.

But what do people who don't speak English do?

As the title says, that people in Paris? 'They don't even know the f***ing word Bold, let alone what the B means!'

So in the country where they call it a royale with cheese, we go in a different direction:

As you can see, we put a G in there, for Gras, which is how one often says Bold when one is speaking French.

Now I am not 100% sure, but I think (and others agree with me) that these buttons might have bitmaps with the letters on them.

Such things are much more expensive to localize than plain text (they have to load the bitmaps from the .mui files which has to be loaded differently, and the localizer has to create images to use), but in this case I guess they decided it was worth it!

And you can see it many other languages. Do you know which languages these are?

Now localizers, once granted the power to understandably translate UI, can choose not to.

Like in this case:

Can you tell what language this is?

In another situation, they might have deemed it not worth the time -- in our Language Interface Packs.

Can you tell what languages these are from?

They may have locked these resources in Redmond to keep LIP costs down (these kinds of heavy duty localization engineering costs add up quickly!

I have a song running through my head right now - Istanbul (Not Constantinople), the original version recorded by The Four Lads:

 The lyrics are something like this:

Istanbul was Constantinople
Now it's Istanbul not Constantinople
Been a long time gone
Old Constantinople's still has Turkish delight
On a moonlight night

Every gal in Constantinople
Is a Miss-stanbul, not Constantinople
So if you've date in Constantinople
She'll be waiting in Istanbul

Even old New York was once New Amsterdam
Why they changed  it, I can't say
 People just liked it better that way?

[Chorus]
Take me back to Constantinople
No, you can't go back to Constantinople
Now it's Istanbul, not Constantinople
Why did Constantinople get the works?
That's nobody's business but the Turks'

Istanbul!!
Istanbul!!

Even old New York was once New Amsterdam
Why they changed it, I can't say
 People just liked it better that way?

[Chorus]

Istanbul!!

Like I said, it's running through my head now.

Maybe it's running through yours now, too!

You might be wondering why I gifted you so elegantly....

I'll tell you.

As of June 3rd, 2006, the State Union of Serbia and Montenegro, formerly known as the Federal Republic of Yugoslavia, decided to not be together anymore.

Gratuitous flag art for Serbia and Montenegro:

And Serbia:

And Montenegro:

But now even all these years later, with Windows 8 and Windows Server 2012, both the Language Pack and the Language Interface Pack go by the name in Microsoft products as:

 instead of the new locales created there for this noble purpose:

Although the Constitution of Montenegro recognizes a language known as Montenegrin, in an uncommon burst of sanity they decided to recognize that their actual language has always been Serbian

In the future that may change, but for now we'll leave it be.

So instead of Serbia and Montenegro, we have Serbia and Montenegro.

For now, the new locales exist, even though the LP and the LIP don't use them.

I pleaded, a little bit in Windows 7 and a lot in Windows 8, but no wanted to take the bait.

I really hope we'll make the change, soon.

One day!

But that song running through my head....

I'll add single quotes to make it easier to navigate:

'Serbia' and 'Montenegro' were 'Serbia and Montenegro'
Now it's 'Serbia' or 'Montenegro' not 'Serbia and Montenegro'
Been a long time gone
Old 'Serbia and Montenegro' still has Slavic delight
On a moonlight night

Every gal in 'Serbia and Montenegro'
Is in 'Serbia' or 'Montenegro', not 'Serbia and Montenegro'
So if you've date in 'Serbia and Montenegro'
She'll be waiting in 'Serbia'. Or 'Montenegro'

Even old New York was once New Amsterdam
Why they changed  it, I can't say
 People just liked it better that way?

[Chorus]
Take me back to 'Serbia and Montenegro'
No, you can't go back to 'Serbia and Montenegro'
Now it's 'Serbia' or 'Montenegro', not 'Serbia and Montenegro'
Why did 'Serbia and Montenegro' get the nod?
That's nobody's business but a Slav!

'Serbia'!!
'Montenegro'!!

Even old New York was once New Amsterdam
Why they changed it, I can't say
 People just liked it better that way?

[Chorus]

'Serbia' or 'Montenegro'!!

Kind of catchy, right? :-)

I've been wracking my brains trying to decide whether it's geopolitically offensive or not. Maybe I'll have warble it in the weekly WR PM meeting (aptly named 'the WRPMS meeting'!), and see what they think....

Or maybe I should try to convince my amazing and talented singer/songwriter friend Holly Figeuroa to do a cover of it some time? She's a much better singer than I am! :-)

My good friend Cathy Wissink sent me email the other day:

I assume you know about this, but if not:

 European Computer Manufacturers Association publishes ECMAScript Internationalization API Specification

In December 2012 the European Computer Manufacturers Association (ECMA) approved ECMA-402, which helps ECMAScript developers’  internationalization efforts by specifying  string comparison functions for sorting, number, and currency formatting. This new standard complements the ECMAScript language specification (ECMA-262), enabling programmers to sort strings directly within the browser, while supporting the user’s chosen language and culture.  ECMAScript is the standardized version of JavaScript.

 Mr. Nebojša Ćirić, chairman of the ECMAScript internationalization group, says that the “..main goals for this specification were to provide uniform and ubiquitous internationalization API for developers, to enable offline processing, and to reduce the download size for localization data.”

Previously,  similar functionality required server-based processing, and associated overhead.

The standard has been developed by Ecma Technical Committee 39, among whose committee members are  representatives from Microsoft,  Adobe, Google, IBM, and Mozilla.

 o   How to use: Download ECMA-402, ECMAScript Internationalization API Specification free of charge from the Ecma International website:

http://www.ecma-international.org/publications/standards/Ecma-402.htm

I had indeed heard of it. The JavaScript in question is the one Microsoft uses in both client and server scenarios.

Glad to hear Microsoft was involved, but I doubt we're going to see anyone updating the scripting libraries.

If they had just done it a few years ago, it would have all been possible...

Now I wouldn't want anyone's mid year review to be materially impacted by it, but I have to talk about how World-Ready I found my Nokia Lumia 920 running Windows Phone 8 to be....

Let me start by saying when Joe "JoeB" Belfiore and Terry Myerson talked about how Windows Phone 8 was based on a Windows 8 core, it wasn't just marketing.

it was the naked truth! :-)

The text rendering, the fonts, the locale support, everything is starting from a Windows 8 baseline.

Amazing!

Now I'll start with feature that lets you take a screenshot of whatever is happening on the phone?

Not a World-Readiness feature per se, but it makes the art easier!

I'll give it a

B+

The coolness of the feature itself is offset by the need to simultaneously hit the Windows button on the front and the power button on the left. Since both buttons have other actions taken when they are pressed, it was really hard to coordinate.

I'm hoping Microsoft and/or Nokia can improve this in future versions....

I took several dozen screenshots, but it took over 100 attempts to get them! :-(

Okay, now with that said, we'll start with the language+region user interface:

I was not in the West Bank or the Gaza Strip when I took that screenshot. :-)

Now I freely give the Regional format list a grade of

A+

Because even though it wasn't what I expected, I have to admit that my expectations were based on over 15 years of the bad user interface in Windows.

Which I have even been the development owner of at various points in the past.

Oops!

When a region has only one supported language, you don't need to spell it out, right? :-)

Now there are still some issues here.

Like the ease of changing between Amharic

and Cherokee

was offset by the fact the change required a phone reboot each time! :-(

That reboot on changing regional formats issue?

I give that a

B+

It would have been worse (since on Windows 8 like in all prior versions, the change was immediate), but the reboot was quicker than on Windows. :-)

The vertical support for Japanese

and Chinese (China, Taiwan, Hong Kong, Singapore, Macao)

All get an

A+

in my book.

Culturally appropriate vertical text is awesome!

Of course they did screw up Traditional Mongolian

by making it horizontal, which from a cultural perspective is practically a geopolitical issue.

So I give them a

D+

for their horizontal Traditional Mongolian.

But on the other hand we have the same bug in Windows, so I shouldn't be too bitter.

It's just that they were so much better in every other way!

Now the Phone User Interface Language List

is interesting, but there are almost certainly ways to extend it -- their supported language list is impressive.

But then, we get to the Keyboard List.

The full keyboard list has some surprises and some disapointments:

• Albanian
• Arabic (25 MB download)
• Azerbaijani - Latn
• Belarusian
• Bulgarian
• Catalan (21 MB download)
• Chinese Simplified 12 Key (57 MB download)
• Chinese Simplified Handwriting (57 MB download)
• Chinese Simplified QWERTY (57 MB download)
• Chinese Stroke (57 MB download)
• Chinese traditional BoPoMoFo (4 MB download)
• Chinese Traditional Cangjie (11 MB download)
• Chinese Traditional Handwriting (4 MB download)
• Crotian
• Czech (20 MB download)
• Danish (15 MB download)
• Dutch (Belgium (14 MB download)
• Dutch (Netherlands) (14 MB download)
• English (India) (19 MB download)
• English (United Kingdom) (18 MB download)
• Estonian
• Filipino
• Finnish (13 MB download)
• French (Canada) (21 MB download)
• French (France) (21 MB download)
• German (19 MB download)
• Greek (16 MB download)
• Hebrew (17 MB download)
• Hindi (Devanagari) (18 MB download)
• Hindi (Latin) (18 MB download)
• Hungarian (19 MB download)
• Indonesian (17 MB download)
• Italian (21 MB download)
• Japanese 12 Key (13 MB download)
• Japanese QWERTY (13 MB download)
• Kazakh
• Korean 12 Key Chunjiin (3 MB download)
• Korean 12 Key Naratgeul (3 MB download)
• Korean 12 Key SKY (3 MB download)
• Korean QWERTY (3 MB download)
• Latvian
• Lithuanian
• Macedonian
• Malay (3 MB download)
• Norwegian (15 MB download)
• Persian (19 MB download)
• Polish (17 MB download)
• Portuguese (Brazil) (25 MB download)
• Portugese (Portugal) (16 MB download)
• Romanian (21 MB download)
• Russian (21 MB download)
• Serbian - Latin
• Slovak (11 MB download)
• Slovenian
• Spanish (Mexico) (15 MB download)
• Spanish (Spain) (22 MB download)
• Swedish (18 MB download)
• Thai
• Turkish (23 MB download)
• Ukrainian
• Uzbek - Latin
• Vietnamese (21 dMB download)

Contrasted with the ~180 keyboards in Windows 8, with our stated goal of allowing you to type anything you can show, this small list is pretty disappointing.

I give it a

C+

which is a passing grade, and this is a huge improvement over prior versions, but if you're not going to be exhaustingly complete then you at least need to be easily extensible, and Windows Phone 8 is neither. :-(

This was the conclusion we came to earlier in the Why aren't there any Cherokee keyboard layouts on Windows Phone 8? blog.

However, when you take the whole package, Windows Phone 8 has a lot going for it, from a World-Readiness point of view.

And it is only going to keep getting better in the future.

So the official Sorting it all Out's Windows Phone 8 World-Readiness grade is

B+

And I'll be looking eagerly at what improvements come next! :-)

The thing about J. Alfred Prufrock and his love song is that he never got around to trying to disturb the universe.

Now I didn't want to be as prissy as he was.

So, after I blogged the blog in this Blog entitled Developing for a jailbroken Surface RT -- dare I disturb the universe?, some of you assumed I might have gotten fired.

If you aren't a Microsoft employee, that link may or may not work for you. Pretend it was scintillating, either way. :-)

I mean, no blogs all last week, right?

Thankfully, I was not fired.

It's just that, well, last week was pretty busy.

I had to write an internal World-Readiness wiki article about World-Readiness in the Console, talking about the PowerShell ISE in particular (you may not be able to see that link if you don't work for Microsoft, but if you can see it you can decide if I wasn't too blogy, which i apparently am sometimes.

And I had get ready to be talking about scripting with the PowerShell ISE at the monthly World-Readiness Champions meeting, only to have that presentation pushed to next month.

And I had to get my MYCI (Mid Year Check In) done a week early, since my manager had to cross the puddle for a W3C meeting.

Like i said, a busy week.

But I had time to catch up with my manager (the Senior Program Manager Lead) and talk to him about that Developing for a jailbroken Surface RT -- dare I disturb the universe? blog.

We talked about the issues and the hurdles and came up with a strategy.

Then I had a quick hallway converation with his manager (the Principal IPM Group Manager) and all went well.

And then I chatted with his manager (the Senior Director), and got all green lights.

Finally, before I contrived a way to run into his manager (the Corporate Vice President of Development), he came to tak to us and do a Q&A with the Windows International group.

And he gave the lazy nod of approval for the project!

Just to be sure the lazy nod of approval was genuine, I asked him privately after the Q&A (sometimes, Corporate Vice Presidents of Development have to be more encouraging in public than they are in private to not seem like jerks).

But the Corporate Vice President of Development confirmed the lazy nod. I shook his hand and said THANK YOU! and tried not to act like I had just scored a touchdown.

Even though I totally did!

So now I just need to revive the MSKLC project tree.

And build two binaries (SETUP.EXE and KBDMSI.DLL) with the ARM compiler/linker.

And pick up all the ARM cross compilers.

And remove IA64 support from MSKLC.

And maybe do some of the other bug fixes I mentioned in The evolving Story of Locale Support, part 4 (working beyond one's bugs, and the case for an MSKLC update).

And update the help file.

And then try to convince someone to test the thing!

And we may even have a conversation with someone from LCA or my manager's manager's manager's manager (that Corporate Vice President of Development) about in this one narrow case putting the special keys to avoid the need for a jailbreak to install a keyboard layout one creates, to install on a Surface RT.

Disturbing the universe sure makes one busy, doesn't it?

Guess I'd better go update those committments! :-)

One thing that is not on the table here is trying to get MSKLC itself on the Surface RT. This would only be for the layouts (otherwise the test burden would be explosively more complicated).

People who wanted to author the setup on their Surface RT will have to Remote Desktop to the other machine with MSKLC on it!

But even with that simpler task, it is pretty complicated, as the single x86 SETUP.EXE that picks the right platform-specific MSI would never work on ARM.

It will need its own bootstrapper SETUP.EXE to go with its MSI.

And KBDUTOOL.EXE (the one binary that did most of the cross-architecture work before) will have to be taught all about ARM.

This might take some time.

Plus I have my actual job to do -- this is sort of as close to a sanctioned 20% time idea as I'm ever likely to get! :-)

Stay tuned....

Back in December, Cheong00 asked in the Suggestion Box:

I just bought Nokia Lumia 920 and found that it doesn't have built-in Quick IME (also known as Simplified Changjei).

It's sad that the IME is not there because I'm used to it and it's been shipped with Traditional Chinese versions of Windows since the days of Win3.X. Do you know if I can get to somewhere.

If not, maybe you can point me to the tools needed to port an IME to WP8? I don't mind doing that in my free time if I have to. (The touch keyboard layout would be the same as "Cangjie Keyboard"... it would also be great if I can just reuse the layout and just replace the libary of key combinations)

Unfortunately, they did cut pretty heavy into the Windows 8 keyboard list when they decided what to enable in Windows Phone 8.

There are several other examples of this, such as the fact that neither Cherokee keyboard (Phonetic or Cherokee Nation) made it onto Windows Phone 8.

This is especially unfortunate since there is a United States (Cherokee) option in the regional settings, and they shipped what looks like fancy new Cherokee font on Windows Phone 8.

So why did they skip these?

I did change this other setting to get Cherokee months and days, at least!

The closest we get is all the Charmap apps in the App Store, but they are a pain to type with. ;-(

I'll send some mail and see if I can get some oversights corrected in a future release.

And I'll ask about the Quick IME, too!

This was going to be the month.

The month to break the six year streak.

The streak where every month at least one person sent me email about a particular issue.

And then, a few hours ago, Marcus messed that up.

His email in part read:

My code for dealing with the Japanese calendar has run into a .NET Framework bug. How do you successfully get the end date of the fourth era?

I have to assume that Marcus isn't Japanese, and has never been to Japan, has never loved Japan.

Such a person probably wouldn't ever have asked how to "successfully get the end date of the 4th era", since the answer involves an inquest after the demise of the Emperor of Japan.

This is knowledge that no one that I know of has, and that I certainly wouldn't want Microsoft to have any special insight about or into, even if they do maintain Microsoft HealthVault!

The answer to Marcus: fix your code, to allow for the Emperor of Japan to be alive!

And then I pointed him to some blogs from Shawn that talk about the issue (Japanese Calendars, How do I Test Support for Additional Eras? and Extending the Windows Japanese Calendar Era information), so he could test out his code after he fixed it.

Now I wouldn't usually feel very comfortable speaking on behalf an entire country.

But I'll make an exception in this case! :-)

Now for the record, I've spent some time on a machine with the entire list from Wikipedia's List of Japaese Era Names on it, and ran into no significant problems with them.

Converting to and from the lunar calendar isn't that hard, Shawn! :-)

I've actually talked to some people about this in the past, and a few years ago (during a health scare about the Emperor), the CTO of Microsoft Japan sent a woman he trusted from MSKK to Redmond to discuss the unthinkable, something no one who is from Japan and who loves Japan would really want to think about: what happens when there is a new Emperor? But she did the job remarkably well, and helped everyone understand the impact on our products. I won't call her out by name because she is modest, but she was somewhat unwillingly drafted into the army of "People Who Know Things No One Is Allowed to Know", and she performed the job beautifully.

I doubt I would have fared as well stepping outside of my own comfort zone, my own conventions....