Perhaps not evil, but certainly getting hella snarky

by Michael S. Kaplan, published on 2010/11/23 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/11/23/10095182.aspx

On a note that is wry but unrelated to the rest of the content of today, I will note that traffic to my blog is much heavier on the weekend than during the week. The patterns suggest a lot of the things I may talk about some other day, though for now I'll leave you all with one thought on this: my blog may be interesting to many of you, but it is not important to most of you. I am okay with this, and feel that less traffic would allow me to feel less guilty about typos and such. So if you want to stop reading you should not feel guilty about leaving. :-)

On a second note, people seem to be interested in my social life (such as it is). I will say someone and I just broke up (well, technically I was dumped) but we hadn't really been dating all that long so classifying it as a breakup may be more charitable to the relationship (such as it was) than it deserved. Technically the cause of said relationship's termination is a geopolitically insensitive statement that may be worthy of its own blog though someone else would have to write it. I'll just say for the record that there are people of Nordic descent who take the subject of Ragnarök very seriously, and that it should not be joked about. I have decided she is right, though the realization came too late to save the situation. She did like my prior blog On Thokks who don't give a Frigg, under the mistletoe, for what it's worth.

So everyone who cares about internationalization really hates how lame JScript/JavaScript/ECMAScript is in regard to the whole internationalization/globalization/locaslizability space.

Microsoft, which has been burned before for taking such frustrations and using them extend their own support, decided not to go that route. They did add support to VBScript that mirrored much of what was in VB/VBA in that regard, which led to the reasonable conclusion of its users that JScript's ultimate globalization hero: VBScript was really true.

This does make one tremendous freaking albatross to hang on poor JScript. An albatross that is largely unsustainable given the entire ecosystem of potential browser choices that a user has (since VBScript was available on pretty much none of the others while some form of ECMAScript was available one pretty much all of them.

Better than nothing? Sure. But only in the sense that 35 years in prison is better than 50 years there.

It's open source, it's jQuery, it is Microsoft trying to provide solutions that everyone can use.

And many of us at the most recent Internationalization and Unicode conference were interested to see Nebojša Ciric and Jungshik Shin (both of Google) presented in Making JavaScript Multilingual their submission to try to update ECMAScript to better support globalization -- with what is best thought of as an ICU port to JavaScript given the syntactical similarities between them.

Now jQuery is in use by (the last time I heard) something like 30% of the sites using JavaScript (I just looked at Wikipedia and their article cites"31% of 10,000 most visited websites"). Anyway, I see a lot of juice behind jQuery.

Here we go again, some might think. I mean, look at some of the typical examples in this space where Microsoft does one thing and the industry does something else:

But I was in a few of the key decision-making meetings for some of them and I can unequivocally state that there was no conspiracy to make Microsoft do its own thing as a matter of policy. In the case of both collation and locales, the people who eventually created alternate standards even approached Microsoft to share its data and participate in creating a wider standard; in both cases we declined to share data explicitly though we did provide expertise in both the creation and the maintenance of the standards behind them.

Looking at the two different approaches to solutions on the ECMAScript problem here for a moment:

MICROSOFT: By providing an Open Source jQuery implementation, this can clearly be thought of (for simplification purposes) as a reversal of prior "let's keep it to ourselves because it is a strategic advantage to not share our IP (Intellectual Property)" type approaches. The syntax was (in my opinion, and the opinion of a few less-biased people I asked) driven much more by jQuery than by any Microsoft-specific language or platform. As far as I know (from both my own personal knowledge as someone often brought into globalization discussions at Microsoft and from talking to several of the others involved with the project) it was created from a "purer" place in terms of motivations, noting the history of nearly perpetual lack of interest in updating the standard for this issue and the desire to finally get something out there for people to use.

Microsoft's motives are not always as pure and I have been quick to point out when they weren't, so I will admit some pride at being "one of the good guys" this time.

GOOGLE: I don't have a particular bias against an ICU frame of mind, but I don't use it myself -- I don't ship ICU and I work for a company that doesn't ship it either. And I know that on several occasions I have been asked whether and/or when that would change: both officially and unofficially, both directly and indirectly. Adding something with a syntax so similar to ICU to an open, widely adopted standard that is essentially the one that all browsers follow will be an interesting way to see (depending on your point of view) either how arrogantly stubborn Microsoft would be at not shipping ICU by being willing to re-implement the same functionality or how annoyingly manipulative Google and others would be at trying to shoehorn ICU onto Windows.

Or most likely both -- since the net effect of the move into ECMAScript will indeed give ample opportunity to showcase some of the qualities most negative about all of the people involved.

I have talked to several of the Google developers involved and I doubt this was their motivation. But an old quote comes to mind "The gun may fancy itself the surgeon's scalpel, but the assassin must know the task."

Now despite the fact that this is yet another of those "Google vs. Microsoft" things, the coverage will probably stay here, since as I have often mentioned no one cares about internationalization.

I could try and jump on the implied intent to pervert Open Standards that is there in whatever decision was made that allowed them to proceed here -- I mean standards should be a shield, not a sword. Or, if that was not the intent and this was just some engineers not realizing the consequences of their actions then I could just ask Google to grow the hell up before sitting at the big kids table, like standards -- or better engage the people they have in their company to watch the people involved.

But even saying that one paragraph, I'm exhausted and I realize why I hate the TechCrunches of the world -- I lack the energy to be that kind of blogger just to increase my hit count. And I have no interest in the fight here, really.

No matter what happens in the future versions of Chrome, of Internet Explorer, of ECMAScript, whether you think Microsoft was a monopolist (or still is one!), whether you think Google is now evil (a mortal sin) or merely snarky (a venal one).....

In this particular instance, Microsoft was the one the one doing good here, not Google.

It looked like ICU for JS to me, too. Which was sort of surprising…

FWIW, There are other not-ICU implementations which consume CLDR data, including dojo (which is written in Javascript). ICU does have a mode (a special locale) where it builds some formatters based on underlying Windows calls rather than ICU formatting.

It may be a discussion, ultimately, about the data and how it is sourced, updated, etc as much as where the API comes from or looks like.

Well, the ECMAScript proposal moved a bit, and some people from Microsoft (and others) are involved.

Hopefully the final result will not look so ICU-like. Although doing some research for another project, it really looks like all internationalization APIs are very similar. Looked at ICU, Mac OS, Windows, .NET, Java, POSIX (and except for POSIX they are quite similar style).

The idea that you can create a formatter with a locale, then use it again and again is a good one (most common use case would be spreadsheets, where thousands of cells use one locale, or sorting a list, where you can have thousand of comparison operations using the same collator).

Hopefully we will see some JavaScript guys getting involved. I know that in our project the initial proposal was very C-like, and great feedback from the scripting guys helped a lot to shape the final APIs.