Jonathan Wilson suggested as a topic that I "Talk about the keyboard layout dlls (kbd*.dll), how they relate to MSKLC " and so I figured that might be a nice thing to spend a cycle or two on. Not just because its an interesting question, but also that people will be able to think of me as being responsive to entries in my Suggest a Topic link (assuming of course that people follow the rules in my Comment Policy link!).

Anyway, back to keyboard DLLs....

The relationship between MSKLC and these DLLs is pretty easy to describe... the former creates the latter. Well, the ones created by MSKLC are slightly cooler than the ones in the OS since they support Unicode names for the resource strings where the description and copyright are stored. Those DLLs basically contain the information that you synthesize in the user interface of MSKLC. One of those DLLs actually shows up in the i386 subdirectory of your setup package, and the reason that the name of the file you create may not be named kbd*.dll is that neither I nor anyone else at Microsoft wanted to limit you to a mere five letters to express your creative needs. :-)

The operating system files always use the 8.3 kbd*.dll naming convention, because on the whole Microsoft is unlikely to ever ship enough keyboards for that to cause a problem. Therefore, if you are using MSKLC you have the perfect opportunity to avoid overlapping existing keyboard DLLs that are shipped by Microsoft if you avoid the "kbd" prefix.

But what, in fact, are these DLLs?

Well, the full answer to that question can be a topic for another day, but.... 

For the NT-based platforms, a lot of information can be found in the Windows DDK (which also has samples), but its not in the most easy to read form. Basically, each of these DLLs created by MSKLC exports a function named KbdLayerDescriptor which returns a single big structure that has lots of data in it (the structure is defined in kbd.h). And that data is the very information that was defined in MSKLC, in an even less understandable form.

The DLLs themselves are written in C, but given how little they do in terms of code, that fact probably does not matter too much. :-)

For Windows 95, 98, and Me the format was actually very different and the DLLs were written in assembly language. But the principles are the same -- a bunch of data tables that the OS uses to figure out what the layout it.

Like I said, the full topic can be covered other days (along with some other functions that show up in a couple of these DLLs like KbdLayerMultiDescriptor, KbdLayerRealDllFile, KbdLayerRealDllFileNT4, and KbdNlsLayerDescriptor). Its definitely on my internal list of future topics, so stay tuned if you are interested....

Please note that this posting has nothing to do with IMEs whatsoever. I will deal with the myriad of issues relating to IMEs and their associated keyboards in a future posting, and all comments about IMEs may find themselves not being made public if this is fact is ignored in the comment! :-)

This post brought to you by "ચ" (U+0a9a, a.k.a. GUJARATI LETTER CA)

A little over two years ago, Microsoft Access had its tenth anniversary. As a part of that celebration, they asked people who have been involved in Access both inside and outside of Microsoft to come in and talk about some of their experiences, and they dubbed these people Access Heroes. I was asked to write such a story but the timing was such that by the time they had the prose from me, it was too late to get it in. I was a little bummed since I had told some people about it, but realized I could not really wait until the 15 year or the 20 year. I eventually just got over it.

Then recently someone had seen that Access Heroes site and they wondered why I was not there since I had used six versions of the product in various capacities both inside and outside of MS and act as the Technical VP for the Pacific Northwest Access Developer's Group. I told them the why, and they asked why it couldn't be posted here at this site now.

Having no good retort for that, I dug up the prose and now post it here for all to enjoy.

Its not the funniest of the "Access Heroes" posts (the add-in that developers put on Barbara Wilson's office that put up a message box when she it both mouse buttons wins my vote for that), and only a small part of it is even (jokingly) international, but it was fun to remember the bug reports discussed here one again.

These days, I write code in C, C++, and C#. But I still use Access to hold the half-gigabyte source data that we use for collation (there is no databse tool for ease of transportability between machines, working offline, and querying in the world, and not even Bill Vaughn will convince me otherwise!).

Enjoy!

Letting Off Steam During the Product Cycle

By Michael Kaplan, Software Design Engineer for Windows Globalization

When Jean Philippe asked me to think of the most interesting thing I could remember from my time working with Access, I had to give it a little bit of thought. After all, I had been working with Access for five versions and eight service packs, and I had been a member of the actual Access development team in charge of wizard development for over three and a half years. But in the end I decided it might be good to show a lighter side to the Access world. And that is the basis of my story.

At Microsoft, bugs are a serious business, as is the reporting and tracking of them. Of course, everyone needs to have a little bit of fun and blow off a little steam, right?

An excellent (non-MS Access) example of this was back in the beginning of 1995, in a now almost famous bug was entered into the Visual C++ bug database. In fact, you can probably find the text of the description of this bug with an easy search on the Internet. The title of the bug was:

"Build done" signal makes no sound

The report went something like this:

Visual C++ makes an audible signal when a build completes.  When no developer is in the room, this signal doesn't make a sound.  To reproduce:

1) Start a build.

2) Leave the room.

3) Note that the chime does not make a sound.

A program manager explained the difficulty in resolving this hilarious issue, with an oblique reference to Schrödinger’s Cat:

The problem is that while you're out of the room your build is neither finished nor unfinished.  It stays in a state of flux until you return and collapse the quantum uncertainty by observing it.

Perhaps we could link the build finished event to a cat in a box?

The funniest line was one of the last in the report:

I placed my machine in the forest at the edge of the campus. I started a 'rebuild all' and ran out of the forest towards my mailroom. My build normally takes 3 minutes. After 5 minutes I had not heard anything, so I returned to my machine. Unfortunately a tree had fallen on it.

My coolest bug along these lines was one that had to do with the fact that there was no assigned base address for the Microsoft Layer for Unicode (code named Godot). Since it wrapped several hundred APIs and called a bunch more, dynamic fixing of this at runtime from the shared base address that all binaries share could lead to minor performance problems. So it was both fun and functional to be able to put in the bug:

All your base are belong to Godot

Now when I was in the Office world, bugs were usually taken quite seriously. Still, at least once during each product release cycle there always seemed to be one of these “joke” bug reports that would appear. The products were released long ago and I personally think they are pretty awesome, so it looks like quality did not suffer from these brief moments of silliness. When I was asked if I had any stories to share, these bugs immediately came to mind. So, here are the ones that I know about from Access:

Access 2000 – Remember those buzzwords!

The bug title was simple; it read:

OfPERF: Cafeteria lines are moving too slowly

The prefix at the beginning of the title is self-explanatory: it was entered as an “Office performance” issue, which at the time of the Office 2000 release was a metric to which everyone in Office was paying attention. Everyone knew “performance” was a buzzword that concerned people on the team, which made it the perfect time for someone with a clever spirit to point out performance problems with the lines in the lunchroom cafeteria.

But it could not stop there -- there was one person who noted that they tried to reproduce the reported problem with lines in the cafeteria late in the afternoon and was unable to do so (someone else suggested looking during lunch time, instead, duh!). Since the development had not yet done the performance work for Data Pages, someone suggested that perhaps DAPs were involved? Another contributor decided to declare it “By Design” as part of an evil plot to keep people from going to the cafeteria, while others suggested that it would help if marketing could come with a spin to convince employees that it was a feature to help them get their work done when lines were too slow or to help them take a break when lines were slow enough to keep people away from their desks. In the end, it was marked by design, with a note that they could look into this issue for Office 19!

Now I did not directly participate in the bug (maybe I was too shy), but I did keep an eye on it to watch all of the contributions over the month that the bug was active. My favorite was the report of a GPF (General Peristalsis Fault). Glad I did not hit that bug myself.

Access 97 – In the forefront? Backwards compatibility!

Access 97 was an important release (aren’t they all?), and it was also the first release that really tried to integrate Access into Office. One of the big issues that everyone in Office was concerned about was backwards compatibility – how well does the code that worked in a prior version work in Access 97? It was the perfect setup for a joke bug report.

What was the bug? I could not recall the title of the bug report, but someone noticed that the one-pint milk cartons that were available for free in the kitchens had a different shape (formerly a short and fat variety, they were now tall and thin). Someone decided to immediately mark it as “By Design” since there was no actual change in the volume of milk, but others were taking backwards compatibility a lot more seriously – after all, who knew what kind of dependencies people might have on the older carton shape to fit into particular holders or corners? People could accidentally drop the cartons on their keyboards if they were not prepared for the changed shape, right? The crowd from User Assistance pointed out the myriad of issues with documenting the change and the localization team worried about the milk used by people in other cultures that might not prefer milk from cows. It was simply out of control!

Although I thought it was pretty funny at the time, I can’t recall what my favorite contribution to this joke bug report was. Though I remember that everyone was claiming that it wasn’t as good as the bug from the version before Access 97….

Access 95 – Pure, unadulterated fun in a bug report

Sometimes, blowing off steam does not involve trying to make the work you are doing relate to the joke you are trying to tell. And there is no better proof of this then the joke that was entered into the bug database for Access 95. But it was actually so funny that I admit to looking it over a few times over the years when I just wanted a good laugh.

The title of the bug was deceptively simple and went something like:

There is no Mountain Dew in the Building 25 Cafeteria

So simple, so elegant. And everyone got involved! Whether it was the brave (or maybe just feisty) soul who ported the bug over to the VBA bug database and brought it up as a possible cause for a performance degradation in a particular build, or the even braver soul over on the VBA team who carefully looked in the kitchen in their building and saw no shortage of Mountain Dew – so he had to mark the bug “Not Repro.” Of course, after the bug was ported back to the Access bug database with that resolution, it had to be re-activated since the bug named the place and the VBA developer did not follow the repro steps explicitly enough! Eventually they did get the problem resolved, and I think I remember that they even marked the bug “Fixed” at that point.

[Author’s note: the Access team is no longer in Building 25; perhaps in their new digs they were able to keep on top of the Mountain Dew situation? <grin>]

My favorite contribution was from the developer who had a miniature refrigerator in his office. He resolved the bug “Fixed” and let the person who reported the bug know that he had a “private build” with the fix in his office if it was needed. I wonder how many people took him up on that and robbed his personal stash of soft drinks!

There were a lot of other fun things that happened while I was doing stuff with Access. I remember...

• about the meeting that Mike Gunderloy discussed in his Heroes entry and where the external developers called the "Table by Data" functionality that had Access emulate Excel the "denormalization by datasheet" feature.
• everyone having late night discussions about the true identity of the Access 95 Northwind sample database's Nancy Davolio and how tongue tied I was when I saw her walking down the hall in Building 1.
• and treasure working for weeks with Miho Urabe (who was then then working in the Japanese subsidiary, and is now here in Redmond) to rewrite all of the Japanese changes for wizards to work for all languages instead of just Japanese.
• the times that Nicholas, Heath, and I would stringently follow the rules for being present at the core hours of 10 to 2 (to be available to answer questions when people had them) by being there from 10:00pm to 2am. Heck, the weirdest line in my disclaimer on this very blog was originally based on a story told to me by Heath during one of those late nights. 
• being an MVP for Access and for a time was even one if the insiders that Roger Jennings discussed in his Heroes piece.
• meeting the likes of Andy Baron, Mary Chipman, Sue Hogemeier, Paul Litwin, Ken Getz, Mike Gunderloy (Mike G.1), Mike Gilbert (Mike G.2), Brian Randell, Stephen Forte, Bram Laumans, Dénise Laumans née Bus, Keri Hardwick, Dev Ashish, Steve Lebans, Arvin Meyer, Michel Walsh, Rebecca Riordan, Peter Vogel, and many other incredible developers and incredible people.
• cool conversations with Debra Dove and Jen Perret about Jet replication, #3 on all the time list of under-appreciated technologies.
• writing articles and having dinners with the great folks from Access UE (User Education) like Tamra Myers and Lynn Shanklin (and almost writing a book entitled RTFM with help from David Shank!). 
• when I told Howie Dickerman how Access 97 needed to support partial replication and even wrote a lame wizard on my own to prove how even a minimal effort could produce something useful. "How much do you want for it?" he said -- and it was released to the web as soon as Access 97 shipped and put into the product in Access 2000.
• that Andrew Miller works with 96% efficiency (conservative estimate from team members) and at times I really wanted to modify that estimate -- upward.
• having Tony Poll tell me about how they wanted a conflict resolver written in VB but had an unfortunate problem with their VB resources. "What's the Problem?" I said. "We don't have any," said Tony....
• 'leaking' secrets like the hidden compile and decompile SysCmd calls to Dan Haught with permission from people on the Access team -- a fact that Dan probably did not realize at the time.
• sitting in the back of Kevin Collins Advisor talks where he would leak stuff like SHOWPLAN and ISAMStats. This would make Dan mad since he was told it could not be put in the Jet book and thus could never be talked about externally and would make Neil mad since Dan was right -- Kevin was not going to talk about any of that at all. 
• being given the permission to release many tools to the public based on my internal knowledge of Access and Jet.
• that Howie Dickerman taught me the secret to doing this sort of thing ("Michael," he said, "the secret is getting permission from someone with signing authority!").
• writing the VBA Page Fault Wizard in Access 95 to reproduce the bug that had long been plauging developers, with typical wizard language on the last page ("Would you like open this object in design mode, or open it in browse and cause a VBA page fault"). 
• wanting to put in a bug report against Access 97 after they fixed the VBA bug, on the grounds that backward compatibility (and the core functionality) of my wizard was broken (not to mention the joy of describing in a bug for the first time "Expect: GPF; Result: No GPF" !
• jim Sturms giving me the code for the internal (but unusable) "Form to DAP" wizard written by an intern for free. I had Julianne Lee write based on that code I was given (which was susequently released to the web for free).
• having the Access team offer to buy for $12,000 a little over 18 months later the TSI Form/Report to Data Access Page wizard. 

I treasure the memories of all of it, and was glad I got to work on, with, and for Access all of those years. But to me the funniest cross-discipline, cross-team, and sometimes even cross-division thing that would happen would be those joke bugs. They somehow put it all into focus. 

Not to mention that to this day when I am in the cafeteria in Building 25 I will check for Mountain Dew even though I do not drink it. You never know whether I might have to re-activate that bug....

Happy anniversary, Access!

Anthony Moore, a development lead on the BCL (Base Class Libraries) team of the .NET Framework, has written an excellent summary of many of the issues involved with the parsing and formatting of dates when you add time zones to the mix. The article also has a link there to an entry in the Date and Time FAQ, another excellent document with good info in it....

I myself stayed away from the issues surrounding time zones in a recent post about about Parse and ParseExact, mainly because I know a lot more about the Windows end of it than the .NET Framework's, and it is truly impossible for me to maintain the illusion of knowing everything if I do not stick to what I know. But if I know people like Anthony then maybe by extension I do know all about time zones in the .NET Framework?

Nah, I don't even buy that one. So I would not encourage you to. But there is a reason that BCLTeam blog is on the list of Blogs I Read, and if you do things with managed code then you might want to put it on yours....

This post brought to you by "Ǽ" (U+01fc a.k.a. LATIN CAPITAL LETTER AE WITH ACUTE)

Yes, I said it. IMEs (Input Method Editors) have it easy. And I will say that even though I have only ever built them myself from the samples in the Platform SDK or the ones already in Windows. Even though I have only ever really worked at building keyboards, which cover such a small fraction of characters compared to IMEs that it makes me look like the kid on the beach building sand castles compared to Buckingham Palace by comparison.

Kind of cheeky to make such a claim, huh?

Nevertheless, I will make it. Because I am not talking about the design or the development part of it (which has obviously just a much chance to be intuitve/useful or not as any other project involving user interface and user interaction). I am talking about from a data management and data usage standpoint. And the questions that the data can answer.

With an IME, an attempt to take the small number of keys found on the regular keyboard and map them to up to some subset of the entire set of CJK ideographs, Kana, Bopomofo, Hangul, and Jamo characters in Unicode. The basis of the mapping varies, depending on language and user preference. It could be based on pronunciation, on the code point number, on count of strokes, on radical. The user can then commit the choice and it will be entered into the application.

And here is where we get to the part that makes me (as the owner of collation support in Windows an the .NET Framework) jealous, that makes me say the IME folks have it easy.

Because if that first choice is not what the user was looking for, then they get a list of alternate candidates that meet the same criteria as that keystroke or set of keystrokes. The list can be ordered by some collected data that tells the IME which candidate is more likely to be the right choice.

Ameliorated are the problems I discussed a few days ago about ideographs that have more than one pronunciation, because they can all be there, an entry for each pronunication.

Mitigated are the problems I mentioned about pronunications that can apply to many different characters, because each additional character can show up in the candidate list.

And Gone is the need to answer the question of equality that is so central to the CompareString and LCMapString APIs, the CompareInfo and SortKey classes -- because the question is no longer "are they equal, my liege?" or "which is ordered first, sire?". Instead, it's "what's on the list, dude?"

And it just struck me that it feels like a much cooler question, if you ask me.

Of course I was immediately reminded by colleagues that this is only cooler when it is the question that one is wanting to ask. If Jessica needs an order for a list of strings or Wendy needs to answer the quesion of equality or Molly needs to build indexes for her database, then the question that the IME works so hard to answer is not nearly as cool.

I was also reminded of something else I know but sometimes forget (which is good, because the remembering part humbles me a bit -- there are many people who feel I need that!). A question's coolness cannot be judged solely by the ease or even the possibility of a good answer. Some of the coolest questions in the world do not have answers yet. Some have answers that seem much simpler or even dumber than the original questions. Some are brilliant even if the initial question seems at first glance to be dumb or trite.

So why am I jealous of the IME folks? Because getting a satisfactory answer to their question is a more tractable problem for Korean, Japanese, and Chinese (both Mandarin and Cantonese), when compared to the questions that the technologies I work on ask.

For me, a function that is smart enough to order multiple characters with the same pronunication is easy -- I just plug in the rules for whatever mechanism acts as the tie-breaker. However, the function to take a character with multiple possible pronunciations and choose the "right" one for a pronunication based sort is a lot harder. Under current art, one needs to add one's own pronunication data a-la-Ruby (or other annotation mechanism).

Perhaps surrounding text could provide the context, if it exists -- but what it is does not? Also, a machine being able to choose the "right" pronunication based on such context is really the first half of the machine translation problem -- to know how to treat the data, the machine must first be able to in some sense understand what is meant.

Are there answers? Well, not in Windows or the .NET Framework today. But there is an understanding of the desired functionality. There may even by thoughts about avenues of attempts at solution. One day.

But at the very least, I thought that this post might make a good quick introduction to the problem.

This post brought to you by "ฬ" (U+0e2c, a.k.a. THAI CHARACTER LO CHULA)

I was contacted by nik john, who asked me:

i'm a PhD student at the hebrew university in jerusalem. i'm working on social aspects of the internet in israel. right now i'm interested in the development of hebrew for the internet. i read your articles about unicode and was interested in whether you know anything about how hebrew developed for the internet in israel (the struggle between "visual" and "logical")? 

I would always suggest logical ordering, not visual. The visual encoding is in no way a natural way to communicate in the language and just represents an eagerness to have Hebrew on computers before technology supported the language. It essentially requires an author to write their own language backwards on a line-by-line basis... yuck!

A very good discussion about the issue and the pros and cons of (as well as some of the historical basis for) each can be found in this article.

This post brought to you by "ךּ" (U+fb3a, a.k.a. HEBREW LETTER FINAL KAF WITH DAGESH)
SURGEON GENERAL'S WARNING: U+fb3a is intended only for legacy transcoding. Modern implementations should use U+05da + U+05bc (HEBREW LETTER FINAL KAF + HEBREW POINT DAGESH OR MAPIQ).

If anyone ever looked at the Win32 API and tried to claim that the functions were implemented consistently, then odds are they are clinically insane. If you know what I mean.

So thats not what I am thinking about.

I am thinking about the little consistencies that one can find in families of APIs, such as

• Most of the NLS APIs take an LCID, all of which use the behavior of ConvertDefaultLocale on the LCID you pass in
• The registry APIs returning the error value so that 0 means success whereas it would mean failure for most other APIs.
• The "Ex" versions of keyboarding APIs take an HKL parameter, and their non-Ex counterparts use the current default
• The NLS APIs can take a buffer size for the in buffer or you can pass -1 to indicate it is null terminated
• Most of the GDI APIs return a BOOL
• Flags and the way they are named seem consistent within families in USER, GDI, KERNEL, NLS, etc., even though wildly different when compared between these families
• Buffer semantics are again generally consistent within families

This is something that I always personally found to be comforting -- like there were teams that had the institutional memory of the APIs they have and that when they add them they try to keep these little consistencies so that people who use them could have intelligent guesses as to behavior so if they understood some APIs they could end up understanding a lot of the rest.

But the other day I was talking to some colleagues who said that they never really grouped API behaviors this way, and they minimized the actual benefit to trying to maintain such a consistency.

So what do you think? Is there a benefit to the little consistencies? Do you believe they are even present? Or is that just me assuming patterns where there are none of any importance?

Also, a random note to answer a question posed by Jonathan Wilson in the "suggest a topic" post -- the LoadKeyboardLayoutEx API sort of follows the above pattern with "ex" versions of keyboard APIs but it also involves other stuff like windowstations. Its not documented because it does not really provide any usable functionality outside of the USER subsystem that one cannot get with existing APIs like LoadKeyboardLayout. But the USER subsystem does have to care about things like separate windowstations....

This post brought to you by "વ" (U+0ab5, a.k.a. GUJARATI LETTER VA)

Someone actually sent me email about this very topic. They looked at the list of blogs I have down under the "Blogs I Read" category and scratched their head at how random it appeared to be. He did at least have the grace to point out he had too much free time on his hands.

So, what makes up the "Blogs I Read" list? Its a simple concept... wait for it...

Its the blogs I read!

Yes, it is kind of random. But then so am I, folks. If you read n posts from this blog (where n is greater than zero), or conversed by email or in person then you'd see that the things that interest me are varied.

Of course that is not the full list of blogs I read, but thats why the list is not entitled "All of the Blogs I Read". Because randomizing the hit traffic on the blogs of my niece and my sister-out-law¹ by putting a link here is just not a way to get invited to family events, if you know what I mean.

Now the list also changes from time to time, and that is really not due to a grudge or an argument or anything. It is just the fact that this list IS blogs I read. I get pissed very time I am looking at some random blog list that someone has where half of the links are bogus or point to their old blog that they abandoned two years ago in favor of a new one. Do people have the list just to look good? And how do the dead or comatose links make them look?² If I take a link off then I am not looking at them as regularly as I was -- but that does not mean I am not still looking from time to time....

So, my guarantee: If it's on my list, then I look at it on a regular basis. If it's not, then I may or may not be looking at it. But if you are Meredith or Rachel or Jenny or Zach or others (you know who you are!) then you can assume I am looking at it and am trying to keep the twelve people (geeks) who look at my blog from randomly heading off to yours....

Some last points:

• the .NET Developers Association link is there is because I sometimes go to meetings and occasionally even speak there.
• the Pacific Northwest Access Developers Group link is there is that for reasons surpassing my understanding I am the Technical Vice President of the group.
• The Evil Overlord list link is just funny and cool and it makes for my kind of daily affirmation (e.g. #34. I will not turn into a snake. It never helps.).
• Other links are there because I find them useful or think someone else might.
• You will not be able to get me involved in a link exchange program. Ever. Stuff like link exchange solicitation emails just piss me off when I see them.
• Yes, it is true that "sorta" is not really a word; irregardless, I like it and will keep using it (and irregardless is a word, dammit).
• Anticipating another language maven style response -- dammit is also a word.

This post brought to you by "ᄴ" (U+1134, a.k.a. HANGUL CHOSEONG SIOS-SSANGSIOS)³

1 - My sister Meredith's husband's family are Meredith's in-laws (obviously). I asked Jenny (Meredith's sister-in-law) a while back what does that make us, and after some searching around we realized it made us asbsolutely nothing whatsoever. Were Jenny uncool, I would have left it at that. But she is so exceptionally cool, as is the rest of my sister's husband's family, that I refused to leave it there. I told them that they are my cool "out-law" family, and everyone seemed receptive to the kind motives behind the idea, no matter how twisted the idea may in fact be.

2 - When I have pointed out such links to "dead" or "comatose" blogs in the past, people sometimes claim that it was intentional since the old location links to the new one. However sometimes the "new" one has also been abandoned. I think these people just list their team members or friends or something. The two-year-old site is certainly not what they are reading today....

3 - Inspired by the television show Sesame Street, which used to suggest that each episode was sponsored by various letters and numbers. While the folks at CTW get the high profile sponsors like A-Z and 0-9, I will be looking to the rest of Unicode to sponsor my posts, from now on....

Collation fascinates me.

It has fascinated me for most of the last eight years, since the first time I saw Appendix D of the first edition of Developing International Software for Windows 95 and Window NT. Like most people, I knew that some languages had different letters but it had just never occurred to me that letters would ever be ordered differently.

What I find most fascinating is that by and large people understand the order well enough to make use of it to retrieve information or to recognize when it is out of order. Yet they usually cannot clearly articulate the rules even when they have a clear subconscious knowledge of it.

Like all good internationalization features, people really only notice them if they do not meet expectations. This is something else that I find fascinating because I have never felt like it was all about me, even if I am doing cool stuff. It is about the cool stuff.

There reason that languages have ordering is obvious -- people need to be able to find information. How else can they find words in a dictionary or names in a phone book, if there is not a deterministic ordering that they are expecting?

The principles used to create the orderings vary, depending on the language and to some extent the script. I will give some examples here....

• Some ideographic languages (such as Chinese and Japanese) use a stroke based ordering. This can either be a simple count of the total number of strokes used in the ideoraph or it can be a radical/stroke based ordering where the basic radicals all have a specific order and then all of the strokes outside of the radical are then counted. For any one ideograph there can be only one count although the number of strokes counted may vary depending on whether the unified ideograph is Hanja (Korean), Kanji (Japanese), or Han (Chinese). Since there are generally under 50 strokes on even the most complex ideographs yet there are at minimum tens of thouands of them, there are many duplicates for each count and thus there must be a seconary method describing how to break those ties. Examples of tie breaking methods include order in a National standard, order in Unicode, or the order in which the strokes are ordered according to ideal construction.
• Some ideographic languages (such as Chinese and Japanese and Korean) use a pronunciation based ordering. Like with the stroke based orderings there sill be many duplicates, but unlike the stroke based ordering a single ideograph can have multiple pronunciations. This problem is eased in some cases by the fact that a dictionary has a clear interest in placing a word in multiple positions if there are multiple pronunciations with different meanings and the order of the dictionary is based on pronunciation. Beyond that, computers generally solve the problem either by allowing the user to strore the pronunciation so they can easily find an entry later or by using the most poopular/common/generic pronunciation.
• Some languages base the ordering on an older language (upon which the current language was based). The greek Alpha (Α) Beta(Β) Gamma (Γ) Delta (Δ) compared to the Cyrllic A (А) Be (Б) V (В) Ghe (Г) De (Д) compared to the Hebrew Alef (א) Bet (בּ) Vet (ב) Gimel (ג) Daled (ד) compared to the Armenian Ayb (Ա) Ben (Բ) Gim (Գ) Da (Դ) compared to the Georgian An (ა) Ban (ბ) Gan (გ) Don (დ) obviously have some sort of shared heritage of ordering. At this point we just do it this way because they did it that way before, and any attempt to ask about the order will usully elicit a blank stare.
• Some languages which use the same letters as another change the ordering based on phonemic principles (thus in Lithuanian the letter Y sorts after the letter I, rather than nearer to the end of the alphabet.
• Some languages which use similar letters as another put the letters after the letters to which they are similar. Thus A Macron (Ā) comes after A in most languages that use it, as does A Ring (Å).
• Some languages consider those similar letters to nevertheless be entirely separate letters which are put at the end of the Alphabet. Thus in Swedish A Ring (Å) is a unique letter that comes after Z, rather than a variation of the letter A.
• Some languages use a regular, repeated order combining consonant and vowel sounds. Thus in Japanese the pattern A (あ) I (い) U (う) E (え) O (お) is repeated with successive "rows" of the alphabet like Ka (か) Ki (き) Ku (く) Ke (け) Ko (こ) and Ga (が) Gi (ぎ) Gu (ぐ) Ge (げ) Go (ご). When one asks a native speaker about the AIUEO order the same blank stare can often be seen.

Other languages simply stick additional letters at the end or next ones that look similar. They may use points of articulation, or phonemic values.

More often than not, people know neither the whys nor the wherefores. But they know the right order when they see it....

In future posts I'll look into some of the more interesting trends I have noticed in some of the languages of East Asia, Southeast Asia, and South Asia.

The dead key mechanism in keyboard layouts is rooted in European typewriters. One would type the accent character and the typewriter's head would not advance, then one would type the base character and it would. The term dead key refers to the fact that the position is not advanced after typing the diacritic mark.

So since people are used to this from typewriters, adding a similar mechanism to Windows should be easy, right?

Well, no.

After all, if you are used to Unicode then you know that one first types the base character and then the diacritic. If you are used to typewriters, you expect to see the diacritic. And in both cases you expect that what is finally produced is always made up of the constituent parts that were typed.

In keyboard layouts on Windows, none of these assumptions are true. Nothing is visible after typing the dead key. The layout defines what is to appear when the combination of the dead key and the base character is typed and there is no rule guiding what must appear.

This is a mechanism that is very easy and intuitive if you know about it, otherwise it is as confusing as hell.

Also, you can only have each pairing of keystrokes produce a single UTF-16 code point. I would not have believed it, but this limitation is one of the most common questions I am asked about (not #1 but definitly in the top five -- most often to do with user-created Polytonic Greek keyboards since there is no precomposed form in Unicode). This is not an MSKLC limitation, it is a core limitation in the keyboard layout architecture, as one can find in the kbd.h header file from the Windows DDK (available to all for a mere $199 plus s/h):

/***************************************************************************\
*
* Dead Key (diaresis) tables
*
* LATER #####: supplant by an NLS API that composes Diacritic+Base -> WCHAR
*
\***************************************************************************/
typedef struct {
    DWORD  dwBoth;  // diacritic & char
    WCHAR  wchComposed;
    USHORT uFlags;
} DEADKEY, *KBD_LONG_POINTER PDEADKEY;

There is only room for a single WCHAR for the precomposed character. Sorry! 

There is also a comment above the struct by someone who no longer works on keyboards (their name removed from above for obvious reasons!), and no NLS API was ever added for the sake of keyboards that would combine the two characters to create the dead key. Technically one already exists -- the FoldString API with the MAP_PRECOMPOSED flag. However, such an API could never be used at this point, since there has been many years of potential keyboard layouts shipped that allow one to attach to two unrelated characters a third unrelated character.

(I'll see about talking to someone about removing the comment!)

Now one thing that is possible in the Windows architecture is chaining dead keys together, so that a dead key plus a base character will then wait treat the combination as another dead key waiting for yet a third base character. One could then chain that as well, and so on -- adding more and more keystrokes to produce in the end a single code point. This feature is not currently supported by MSKLC since the demand for combinations of three or more keystrokes always involve multiple characters being produced -- one is simply not enough here for anyone who has ever asked....

On the whole, my earlier words about dead keys sum up the situation best:

This is a mechanism that is very easy and intuitive if you know about it, otherwise it is as confusing as hell.

Luckily there are many ways to produce input with keyboards that is much more intuitive to potential users. Lets leave dead keys for the people who are used to them.

Time to take a look at two very important datatypes, the LCID (locale identifier) and the HKL (the handle to an input method). They have several things in common, and more importantly several crucial differences. I'll let you decide which one is better....

First the LCID -- its defined in (among other places) winnt.h, as follows:

typedef DWORD LCID;

Being a DWORD means it is a 32-bit value. There is a great diagram of how the LCID is laid out in the winnt.h header file:

//
//  A locale ID is a 32 bit value which is the combination of a
//  language ID, a sort ID, and a reserved area.  The bits are
//  allocated as follows:
//
//       +-------------+---------+-------------------------+
//       |   Reserved  | Sort ID |      Language ID        |
//       +-------------+---------+-------------------------+
//        31         20 19     16 15                      0   bit
//

(The diagram was never updated to include the sort version information that now takes up some of that reserved space. But there are not yet any different sort versions so its probably not too important.)

Now the Language ID includes all of the information on language, region, and script. And LCIDs are taken as parameters in almost every single NLS function since they all need some locale-specific context, but almost all of them use the LANGID portion only.

Ok, now we'll look at the HKL. It is defined in (among other places) the wtypes.h header file:

typedef void *HKL;

On 32-bit platforms, a void pointer is the same size as a DWORD. But not all platforms are 32-bit (more on this in a moment).

There is no great diagram of how the HKL is laid out, but if there were it would something like this on 32bit platforms:

//
//  An HKL is a pointer which is the combination of a
//  language ID and device-specific information.  The bits are
//  allocated as follows:
//
//       +-----------------------+-------------------------+
//       |  Handle-specific info |      Language ID        |
//       +-----------------------+-------------------------+
//        31                   16 15                      0   bit
//

Obviously this is not a traditional sort of Windows handle value, since it has documented meaning (most handles have some meaning but it is seldom documented and the directions always say to treat them as opaque, unparseable values).

Now what happens when you run on a 64-bit platform? Well, nothing really. The extra 32 bits that the HKL now contains are not used. Seems like a waste, huh?

Well, not entirely. And in the long run I wish that LCIDs had been done the same way since one never knows how that data could have been used. Imagine if we had wanted the NLs functions to take the string "0409" or "0x0409" or maybe even "en-US" rather than the plain old number -- had this been a handle then it would be easy to set up a semantic where it would be a string pointer, but since it was not then it cannot be a string since there are 64-bit platforms.

Of course HKLs do not really have such a need, so for them it is just wasted space. But haven't we all been in the situation where a friend has something that they do not really need but that we probably could have found a use for? Thats definitely the case here -- they do have it and don't need it, we don't have it and do need it!

A little more information about HKLs -- they are not the same as keyboard layout identifiers (KLIDs). Though both contain a LANGID in the bottom WORD of the low DWORD, the top WORD of the low DWORD contains handle-specific info in one case and device-specific info in the other.

Also, there is no rule that the two LANGID values in the KLID and the HKL have to match. Since the "Add a keyboard layout" UI in Windows allows one to add a keyboard under an arbitrary language, the important distinction is that the KLID's LANGID is the intended language of the input method and the HKL's LANGID is the user-selected language of the input method. This feature can be put to use by putting (for example) one of the English (US) keyboards under the UK English language in order to give hints to Word about the language to use for spelling checks. And I'm sure you can imagine it being put to bad use by putting a keyboard under a language that has nothing to do with it and then watching programs like Word act very confused about how to use the language.

If I had to choose which I thought was more useful and scalable, I'd have to pick the HKL. But I guess the grass is always greener on the other side of the SDK....

I have been dealing with MS, this 800-pound gorilla, for over a decade. It started as a casual thing and it stayed with me like a virus. It insidiously became a bigger and bigger part of my life. Then, a few years ago, I got a purple badge and it became a fulltime issue that I could never get away from. I wake up every morning numb from dealing with this source of most of my frustrations and probably all of my pain. I can't remember the last time I wasn't dealing with it, and I'll probably have this monkey on my back for the rest of my life.

Now that I have your attention with that eye-catching headline and first paragraph whinefest....

No this is not a tell-all about a full-time Microsoft employee slamming his employer.

Because Microsoft is not the MS I am talking about.

I'm talking about Multiple Sclerosis. A disease I have been suffering from for the last 15 years, give or take (the purple badge is a UWMC badge, not a Microsoft CardKey).

So why talk about it now? Well...

I think the last few weeks watching The West Wing on NBC, with the first MS exacerbation on the show that was even close to real, made me realize going a bit more public may not be the worst thing. I mean, I doubt we'd elect someone with MS to be the president in real life, but it is still kind of hopeful. And just hours ago on the show, the President was told he had an 85% loss of function in the nerves to his legs (tested by somatosensory evoked potential, a test I have both gotten as a patient and given as a technician). Even as he is clearly having problems he is still fighting to say he is not. Something I do constantly, though not as cleverly, as Jed Bartlett does.

My excuse? Martin Sheen has better writers.

I was not quite as happy with CBS last night, where Judging Amy's Amy Madison Gray (well played by Amy Brenneman) presided over the case to decide whether a depressed woman with multiple sclerosis is well enough to care for her ten year old son (they decide she is not at the moment, but they will see her back in a few months to see if the medication changes the situation). I have not been there, but I know people who have. I just wonder how many people will be declared unfit mothers as a consequence.

In the meantime for me, lots of stuff is hard -- even easy things like typing (thank you Dragon Dictate!) and walking (thank you, Pride Mobility scooters!).

Now me saying all this is neither as impressive nor as cool as the same sort of announcement from the likes of Clive Burr, Annette Funicello, Teri Garr, Lena Horne, David Humm, Barbara Jordan, Jonathan Katz, David Lander, Roger MacDougall. Richard Pryor, Alan Osmond, Richard Radtke, Doug Robinson, Ronald Rogers, Dean Singleton, Cathy Weis, Paul Wellstone, or Montel Williams. And not only because I am not a drummer for Iron Maiden, a mouseketeer, an actress, a singer, a quarterback for the Raiders, the first African-American from the South to go to Congress, a comedian, Squiggy, a British playwright, an actor/comedian, an Osmond brother, a scientist/mathematician, a novelist, a concert pianist, a newspaper magnate, a dancer, a former Senator from Minnesota, or a talk-show host.

But I'll do what I can. :-)

So I'll probably post stuff on MS (Multiple Sclerosis) from time to time, in between all the posts on international issues related to MS (Microsoft). I promise to try to keep the "MS" puns to a minimum -- its bad enough dealing with two different crowds with entirely different ideas to what the letters MS mean without inflicting the issue on the people who put up with my rambles. That would be a tremendous MStake.

A few days ago, I pointed out that machine translation is not easy. I still believe in a lot of what I said there, but it turns out that I may have (unintentionally) palmed a card there. I think it may be worth exploring that exploring the issue a bit.

The simplified definition I made for pragmatics is good as far as it goes (though a predicted I made n linguists shudder, where n is greater than one). However, where I said

pragmatics refers to the implicit knowledge that the two people on opposite sides of a communication attempt have.

It would be better (more accurate) to say that

pragmatics refers to the knowledge outside the scope of the words being communicated by the one person and to the other.

It may seem like hair-splitting, but its not. Think of the words "Elissa went to the movie. She said it was terrible." If one only looks at the second sentence, then all of the content of the first sentence conveys knowledge outside of its scope. That knowledge, while outside the scope of the second sentence, obviously allows one to properly understand much more about its context. Pronouns in successive sentences that refer to knowledge contained in earlier sentences obviously provide a way for machine translation to understand more about the pragmatic content than that for which original definition allowed, right?

Going back to my childhood where Schoolhouse Rock first taught me about pronouns when Albert Andreas Armadillo (via the voice of Jack Sheldon) taught me that although I could say

Now I have a friend named Rufus Xavier Sasparilla,
and I could say that Rufus found a kangaroo
That followed Rufus home
And now that kangaroo belongs
To Rufus Xavier Sasparilla

that it was in fact much easier to say "HE found a kangaroo that followed HIM home and now IT is HIS". While it is true that "saying all those nouns over and over can really wear you down," it is obvious that without the context of knowing that HIM == Rufus Xavier Sasparilla, that abbreviated sentence runs into some problems in understanding. A machine translation engine that is smart enough to work out those issues will be significantly better than one that is not.

Similar examples of context exist beyond pronouns that can give benefits that are comparable or even superior to a simple semantic translation. Such issues may even be discoverable and determinable by algorithm. But here is where the problems come in, and where the original difficulties I talked about come back. Many of these issues are not so easily determined even by human readers (I recall my third grade teacher Mrs. Galan pointing out that sentences with too many pronouns could not be understood by her, let alone by anyone else!). The concept of machines that can properly discern all of these pragmatical issues is a bit beyond a lot of the current art/science in the field of machine translation.

Lets take another more interesting example, Jack Winter's How I Met My Wife, from the 23 July 1994 New Yorker:

It had been a rough day, so when I walked into the party I was very chalant, despite my efforts to appear gruntled and consolate.

I was furling my wieldy umbrella for the coat check when I saw her standing alone in a corner. She was a descript person, a woman in a state of total array. Her hair was kempt, her clothing shevelled, and she moved in a gainly way.

I wanted desperately to meet her, but I knew I'd have to make bones about it since I was travelling cognito. Beknownst to me, the hostess, whom I could see both hide and hair of, was very proper, so it would be skin off my nose if anything bad happened. And even though I had only swerving loyalty to her, my manners couldn't be peccable. Only toward and heard-of behavior would do.

Fortunately, the embarrassment that my maculate appearance might cause was evitable. There were two ways about it, but the chances that someone as flappable as I would be ept enough to become persona grata or a sung hero were slim. I was, after all, something to sneeze at, someone you could easily hold a candle to, someone who usually aroused bridled passion.

So I decided not to risk it. But then, all at once, for some apparent reason, she looked in my direction and smiled in a way that I could make heads and tails of.

I was plussed. It was concerting to see that she was communicado, and it nerved me that she was interested in a pareil like me, sight seen. Normally, I had a domitable spirit, but, being corrigible, I felt capacitated---as if this were something I was great shakes at---and forgot that I had succeeded in situations like this only a told number of times. So, after a terminable delay, I acted with mitigated gall and made my way through the ruly crowd with strong givings.

Nevertheless, since this was all new hat to me and I had no time to prepare a promptu speech, I was petuous. Wanting to make only called-for remarks, I started talking about the hors d'oeuvres, trying to abuse her of the notion that I was sipid, and perhaps even bunk a few myths about myself.

She responded well, and I was mayed that she considered me a savory character who was up to some good. She told me who she was. "What a perfect nomer," I said, advertently. The conversation became more and more choate, and we spoke at length to much avail. But I was defatigable, so I had to leave at a godly hour. I asked if she wanted to come with me. To my delight, she was committal. We left the party together and have been together ever since. I have given her my love, and she has requited it.

Why do we like this so much? Well, I do even if you don't. :-)

Its a fun trick taking 74 words/phrases with one connotation and using the uncommon but inverse form to mean the opposite. Almost anyone old enough to understand the words will understand what is happening here, and in this case the line between semantic and pragmatic is quite blurry since every bit of it is buried in the text (other than the 74 terms, of course). You can find that different linguists may disagree on what is semantic and what is pragmatic here.

But in any case, imagine what a machine translation of this story would look like -- would it truly be able to capture any of the real intent of the story that is so obvious to all of the human readers of it? Although never stated explicitly, the intent is as clear as a Seattle day isn't. And that is a pragmatic intent.

Interestingly, the ability to automate this pragmatic aspect of machine translation requires a science that is also beyond us at the moment -- artificial intelligence. But thats a topic for another day....

Although I got no public comments about it, seven different people contacted me privately (by email or via the "Contact" link) asking me what was the answer to Andrea's question about the Japanese (Unicode) sort.

(I'm not sure why no one asked in the public comments. I must be very intimidating or something)

Its not a very exciting answer, for what it's worth.

Its about the same as the answer about Korean (but the Yen sign U+00a5 is used instead of the Won sign, for obvious reasons). We also move the HORIZIONTAL BAR (U+2015) to sort by the KATAKANA-HIRAGANA PROLONGED SOUND MARK (U+30fc), for similarly unremarkable historical reasons. Otherwise the sort is identical to the default sort, a fact that makes it quite fundmentally useless for Japanese data.

I had this conversation a little over two years ago in the Netherlands on the end of the last day at a conference. It may not be word for word, though I actually think it comes pretty close (its not like I had a tape recorder). The cookies were Pepperidge Farm Mint Milanos, but I do not like mint (I love the non-mint varieties, I am not sure how I ended up with the ones I did - it might have been a mistake to mention I did not like them).

Oh, also the name of woman I talked to is not really Andrea; I just like the name and do not mind the nod to Jubal Harshaw....

Me: Andrea, would you like a cookie?

Andrea: Actually, I would like to know what the "Korean Unicode sort" is.

Me: I'd actually rather give you one of these cookies. They are really good. Plus its less embarrassing than the answer to your question.

Andrea: I know you hate mint, you said so yesterday at the luncheon. C'mon Michael!

(Short pause)

Andrea: Or is it Mike? Or maybe michka like your mails?

Me: Michael's best.

Andrea: Ok, no Russian bears. So tell me, why is the Korean Unicode sort embarrassing? I could not find it defined anywhere, except maybe I found a vague hint to the 'Unicode collation' setting that was used in SQL Server 7.0, which could be Korean. Is that it?

Me: No, that's not what it is. Though SQL Server does have a "Korean Unicode collation" of its own that matches the one that used to be on Windows.

Andrea: Grrr. You are infuriating, Michael. What is the Korean Unicode sort? The one that is in SQL Server, the one that used to be in Windows, the one that is still in the header files. What is it?

Me: Well, its almost the same sort as the one we use for English.

Andrea: Almost? How close is almost? Sounds like almost hitting a home run, but what kind? Was it an almost home run that was a strike out, or an almost home run that was a triple?

Me: Ouch! Well, if you put it that way, I guess you could say it's a strike out.

(I have an embarrassed smile at this point)

Me: We move one character.

Andrea: One character?

Me: One character.

Andrea: What character is it? Something insulting to a government? Did Microsoft upset the Korean premier or something?

Me: No, nothing like that. Its U+005c, the "REVERSE SOLIDUS". Also known as the backslash. Not insulting at all.

Andrea: One of us has to be missing something, Michael. Maybe you had better give me a cookie.

(She eats a cookie, and tries to hand the package back. I shake my head)

Andrea: So please, explain to me why the backslash has to be moved for Korea.

Me: Well, because for Korean, it is also the Won sign (₩).

Andrea: You said in your talk today that there is room for over a million characters in Unicode. There is no room for a dedicated Won?

Me: Oh, there is a dedicated Won Sign at U+20a9. Its just that in most Korean fonts a character that looks like a Won is put in the slot for U+005c, and since the characters look the same we try to make sure that they are treated as if they were the same.

Andrea: Ok, I see that. But why is it called the Korean Unicode sort. If its legacy then that would make it the Korean ANSI sort, right?

Me: Well, ANSI does not have Korean in it, and there is no Won.

Andrea: You know what I mean, Michael. Are you this exasperating when you talk with your girlfriend?

Me: Oh, I... I'm between girlfriends at the moment.

Andrea: I WONder why....

Me: Hey now!

(Andrea is wearing quite an impish grin at this point)

Andrea: Just kidding. But I was up too late last night and you already gave me the cookies. So I have no real need to flirt when I am teasing at this point.

Me: Hmmmm, no one ever used to have a need. Anyway, I know what you mean. It probably would have made more sense to tie it to the Korean standard, except thats encoding and not sorting. And they basically do put the won at 0x5c in their encoding standard, so MS is just trying to be consistent. It would have been really weird trying to tie to KSC-5601.

Andrea: I can definitely see that. So, what about the rest of the Hangul and Hanja and Jamo and whatnot that is used in by Koreans?

Me: Well, now you understand why it was probably removed from Windows -- because it does not really do much for Korean.

Andrea: But its still in SQL Server. They didn't get the memo?

Me: I know you think that I am a bigwig at Microsoft, but I'm not. I was offered a job there but I haven't even started yet. And I am definitely not "in the know" about what they do in SQL Server.

Andrea: No need to be shirty, dear. I understand. I apologize for thinking you were important.

(I grimace at this point)

Andrea: Ok, and I apologize for teasing you now. But back to the Korean thing.... do you have a guess?

Me: Oh, definitely. I just don't know if I am right.

Andrea: So what is the theory?

Me: My guess is that since there is a serious worry about backward compatibiliy and sort orders in SQL Server, and they can't really get rid of something as easily, even if it is useless. I guess they could have hacked it since its only different by one character, but they are a team that is astoundingly against hacks. Thats something I can respect.

Andrea: So can I. Probably worth a KB article, at least.

Me: Maybe. If PSS gets customers wondering where good old 0x00010412 went, I'll suggest it.

(She eats another cookie)

Andrea: Ok. I'm sorry to monopolize your time like this.

Me: No worries, the group is gone, the conference is mostly over. Hell, I'd probably be flying out tonight if there were a flight. You can come out with us tonight if you want. Well, that is if we are going anywhere.

Andrea: Actually, you can come out with us. My friends are more socially adept than yours.

Me: Probably true. And more than me, too.

Andrea: One more question and we can head back to what's left of the group.

Me: Ok. What's the question?

Andrea: Whats up with the Japanese (Unicode) sort?

Needless to say, the conversation devolved at that point. But Andrea did finish the cookies. I did go out with four of Andrea's friends that night and drank more than I should have. The flight home was harder with a hangover, and to be perfectly honest it was not until I sat down to try and remember the whole conversation earlier tonight that I remembered I was supposed to follow up with PSS.

Maybe the blog entry is good enough at this point? :-) 

Now that I am two months and 21 posts into this blog, I guess it may be time to explain why I am doing this, comments from colleagues nonwithstanding. :-)

Sometimes I have felt like I was answering the same question over and over again, whether internally at Microsoft or externally on the newsgroups. That feeling would often make me post less, or more accurately make me a little less likely to post an answer to a question. This is of course not entirely fair to the person asking....

So I started this blog. Now I can answer the question once and then use pointers to those answers.

As a bonus I get to pretend that I am clever and funny (which to whatever extent it is true here is not true in real life except accidentally). If you don't like (or don't care about) what I post one day, then you may like (or care about) what I post the next. Its like the Magic 8-Ball.

Now the rule I have set for myself is that preferably every day (or at worst every other day) I should have something to say. Obviously vacations do not apply here, but other than that, hospitalization, or outright committment, if I cannot think of something useful to say at least that often then I will probably retire it. Harsh, I know -- but I gotta be me.

By the way, this post does not count as one that I consider "something to say" since the blog is not about talking about myself. Its about talking about globalization, internationalization, localization, or other topics that deal with software/hardware for the world. And anything I run across along the way....