by Michael S. Kaplan, published on 2008/02/22 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/02/22/7847522.aspx
Let me start by saying that I think the subsidiary model for software companies like Microsoft is a very powerful one.
It is a way to make sure that a group of people who are most interested in the success of a market are on the ground in that market and in a portion to understand what people there want and then asking for it of the core team, with appropriate information about the relative importance of the issues involved and (most importantly) a serious triaging effort on the relevant importance of different requests within that market.
Further to that end, it is people in the subsidiaries who become the most natural "owners" of features that are specific to their market -- from Czech support being owned by the Czech subsidiary to IME support being owned by the various East Asian subsidiaries and so on. Who else would be the best people to provide information and resources and such for locale data, keyboard/input method information, sorting details, market requirements, and other features? It really does make sense and some very powerful and compelling products are produced this way that work and work well in those markets.
And since their success is quite literally tied in very real ways (i.e. financial ways) to the success of the company within their market, they are working within their own best interests to do their job well. In almost every case they are very interested and passionate about their market and their language anyway, but having the financial incentives are obviously never going to make people work less hard. :-)
But (and you knew that was oming, right?) there are some drawbacks to the subsidiary model, some gaps that it is not as effective at filling.
I was thinking about this the other day when (via the Contact link), Marti asked:
Hi Michael,
I'm not sure if I'm asking to the right person, but I haven't found anyone more specialized than you about this subject all over the net. The question is not strictly programmatic but the solution may involve some step in that direction.
I use Windows XP Pro with a Spanish keyboard, which looks exactly like:
http://www.rockwood.k12.mo.us/Lafayette/Reed/images/spanish-keyboard_l.jpg
I also type in Japanese, and for that purpose I installed Microsoft IME Standard 2002 ver. 8.1. The problem I have is that when I switch to Japanese, then all the punctuation and arithmetic symbols are in a different location, just like a Japanese or US keyboard layout. I don't want to get used to this layout because I don't plan to use a real japanese keyboard. What I want is to use IME with a Spanish keyboard layout.
What I've done so far:
a) I've tried to install the Spanish layout under Japanese input language, but this way I cannot use IME and Spanish layout at the same time. Pointless.
b) Dirty job: I've used MSKLC to create a Spanish keyboard layout and I assigned it Japanese language under Properties. I installed it and then I changed the following registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\00000411\ "Layout File"= (name of my DLL)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\E0010411\ "Layout File"= (name of my DLL)
Now, when I switch to IME I have the Spanish layout enabled, but the dead keys (`,´, ^, ¨) are still not working, they just output the symbol twice (``,´´,¨¨,^^). Is it possible to have it all or is not possible to have accents in Direct Input mode? Is there a cleaner way to do this instead of that Registry hack?
On the other hand, I would like to translate the Right Control key to some specific key only present in Japanese keyboards. Which is the cleanest way to remap keyboard scan codes? I've read about the "Scancode Map" registry value, and it seems very attractive but again it looks like a hack (with pros and cons). Can the same thing be achieved via the keyboard layout DLL?
Thanks for your attention,
Martí
Now IMEs in Windows have never worked particularly hard to support the scenario of inputting an East Asian language using the keyboard of another language beyond the one they picked -- in fact some would argue that it has become harder and harder each version to see such support happen -- think about the extreme measures you used to have to go through (as described here) which then were later broken anyway (as described here). And notice the extreme efforts Marti is going to. Now none of it is supported (or indeed supportable), so it is not surprising that there are problems trying to enable it.
I'll start by telling Marti that there is no real solution to the problem -- this is not their scenario so no solution was envisioned or provided. What used to work only worked by accident, not by design. and further, MSKLC will not work for mapping the right control key to other functionality, and affecting ScanCode map is really the only way to support that sort of thing. Dead keys with the IME are a huge challenge given what the IME is doing to the input -- you really have to switch the input language to be not hooked up to the IME, to get that done.
But let's move beyond the Japanese case for a moment, and not only because I am not being of very much help there. :-)
Instead let's think about reversible transliteration in Korean (attainable through solutions like KORDA) that I mentioned in Is it Hangul? or Hangeul? or Han'gŭl? or what?, and the fact that Microsoft does nothing of the kind in its products today. But within Korea the thought of nit just using the native language? Why would someone even bother, right?
Closer to the point, consider the Yi "IME" in Vista, which by every report I have heard works great for people who know Chinese but not as well for native speakers of the language (not entirely surprising since the data that shapes the IME was done by the same team that does the IME work, as did a non-trivial amount of the testing (which led to more than one misunderstanding when language issues like like this one came up -- causing problems in both the original IME work and the later testing of it and of the font!). Of course the principal push for Yi support comes from the government in China as a part of GB18030 compliance, and the support in Vista is more than good enough from that point of view.
The strong feelings of native language speakers within India versus experts outside of it is an issues I have talked about a great deal in the past and plan to talk about more in the future, and it again underscores the same kind of issue. To which I'll add that providing only the INSCRIPT keyboards and ISCII code pages as provided by the Government of India appears to show a certain specific degree of disinterest in needs of the many languages in country, if not outright disdain -- like someone else's agenda being pushed, however indirectly.
And there are countless other examples, really.
In every case, the problem is that the nominal "owner" of the feature, its future direction, and its ultimate destiny is in the hands of a group of people who only are allowed to directly benefit for in-market successes, and any feature that would work well for a language but not for its main market is not one that the subsidiary has within their charter or mandate to support, and often outside of their abilities to do the research on to determine other solutions to the problem which may well work better outside a market.
Now obviously this is a sensible decision when it comes to choosing where you will get the most people supported, and the out-of-country solutions would almost certainly be unacceptable in-country.
And this means that changing the current model would incredibly stupid and would not serve the majority of customers or potential customers.
But at the same time, there is a clear need to supplement the current model -- to make it a reasonable and sensible idea for the subsidiary contacts to directly benefit from the out-of-market features that support their language, as well as making available to them the right materials and research to make the job easier and more possible.
So that it makes sense for the Korean subsidiary to be directly concerned with the use of Korean outside of Korea, for the Japanese subsidiary to aware of the problems of supporting their IME when non-Japanese keyboards are used and interested in getting solutions built into the IME, and so on.
And then of course for the separate issues in India and China a bigger push to go beyond the central government and into the needs of specific languages in country, beyond what the country looks for (which in many cases is npt enough). Some work happens here, but really not nearly enough is ending up in product.
Sorry Marti about taking your question and focusing on a much larger problem that, while being the source of the problem with the Japanese IME you reported, quickly moved beyond it an into whole different areas. But there really aren't good answers for the original question, and I figured the time seemed ripe to be on a soapbox about the bigger issues that put us there....
This post brought to you by ^ (U+005e, aka CIRCUMFLEX ACCENT)
John Cowan on 22 Feb 2008 1:33 PM:
"Having the financial incentives are obviously never going to make people work less hard."
You'd think so, but that actually turns out to be false. See the 1987 Boston Globe article reprinted at http://www.gnu.org/philosophy/motivation.html (I know, I know, but don't shoot it because of the messenger -- the author knows what he's talking about, is not beholden to the FSF, and cites studies, if a tad informally.) People actually work harder and more creatively when they are not given extrinsic rewards.
Michael S. Kaplan on 22 Feb 2008 2:33 PM:
Fair enough, though when they have a job and there are items that are not a part of their job, they are less likely to work on the things that are not even listed as a part of their job. In the framework of where people are getting paid and what I suggest is out of scope in today's world, making it part of the job and rewarding them for how well they do at it (using the same way they are rewarded now) is not an awful idea.
The current situation simply gives them no reward if they work hard in one area and lots if they work in another. I don't believe that you will get people consistently in all locales working on the unpaid part in any useful, consistent kind of way....
Martí Mesquida on 25 Feb 2008 12:32 PM:
Thanks, Michael, for your very educative answer. We all would like to be treated like this even when something is not possible. I'm happy with the current workaround as long as I don't need to remember where the dash, period, colon, etc. are located in a US/Japanese keyboard. I'll just switch input language for the accents.
But I don't give up at the keyboard remap question, not yet. I was looking at the guts of MSKLC and I saw that it's a frontend for a compact Microsoft C++ compiler setup. Is it possible to instruct MSKLC to NOT delete the C/H/RC/DEF source code that it's compiled to produce the layout DLL? Would be great to use MSKLC to do the bulk work and then be able to introduce some custom fixes in the source code before compiling. In the meantime I was able to get those source files by hacking around my TEMP directory and now I see that my remap can be achieved by a simple edit in aE0VscToVk array.
By the way, this blog has been very instructive to learn that leyboard layout DLLs are very passive, basically data-driven and not code-driven. Then, it's up to the software layer that makes use of it to properly interpret the data structure it returns... Now I understand why the keyboard behaves different under IME, regardless of using the same DLL in both scenarios.
