by Michael S. Kaplan, published on 2012/01/24 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/01/24/10259941.aspx
Previous blogs from this series:
This series has been largely discussing a particular "meta-issue".
The fact that as our model for locale support is indeed evolving. And much more quickly than usual.
Some of the blogs in this series capture the "missing links", which can be invaluable since not everything can be deduced from a finished product.
Part of it is the new keyboards that can support languages for which no locales currently exist, as described in part 2.
And part of it is in the new list of languages that sits under those new keyboards and supports way more than our locale list can perhaps ever reach, as described in part 15.
Exciting times, aren't they? :-)
Well, let's add one of those new keyboards.
Like the one for the New Tai Lue script/Xishuangbanna Dai language:
Even cooler -- how quickly I typed ᦎᦷᦑᦺᦜᦺᧈ ᦉᦲᧇᦉᦸᧂᧅᧃᦓᦈ with the Windows 8 soft keyboard. :-)
Admittedly I built the original keyboard layout it was based on -- your mileage may vary....
If you have the Developer Preview you can see how we are improving here already in supporting finding new language names via some of those script names!
It's on our Language List now, and everything!
This is awesome!
But then we ran into a problem when we tried to search for some New Tai Lue script/Xishuangbanna Dai language text in an XPS file we just created.
Because we were using that New Tai Lue keyboard, the one that the "WinLangDB" list put under the code of khb, for the Lü macrolanguage.
The search ends up failing since functions like FindNLSStringEx can only handle supported locales by NLS rules, not WinLangDB rules. This is no problem in Notepad which users the default user locale, but a big problem for anyone that tries to be more clever than that.
In a way, its surprising in s way that it wasn't found earlier. I guess there aren't too many things using the clever way -- we should maybe have more of them!
Obviously this is a small mis-step in the bold move forward to support things that we don't fully support, and we'll have to figure out what to do here.
In fact, people are looking at this right now. Since NLS supports all of the underlying characters in the default table, there are lots of possible solutions (note that if nothing were done then you couldn't even search for English text since an "invalid" locale name makes the NLS functions fail!).
I mean, since we lack the resources at this point to add a Xishuangbanna Dai locale. :-)
Of course this is much bigger than New Tai Lue -- the WinLangDB list supports such a huge subset of valid ISO-639-3 codes that doing nothing would hurt even more than just this one case!
But truthfully I'm not worried here -- 15+ steps forward and one step back in the pre-release has plenty of time to be changed to 16+ steps forward in the actual release.
Alternately, if they don't fix it then it will make a great KB article, maybe. :-)
And either way, I'm proud to be a part of those step in our evolving Story of Locale Support....
Simon Buchan on 24 Jan 2012 2:30 PM:
WinLangDB only has hits for the "IS THIS SCARY DLL BAD? No." sites, this post, and a scraped copy of this post. But by the way you talk about it, I'm guessing it's sitting beside or on-top of NLS? (at least in terms of layers, rather than directly depending) - otherwise NLS could pull the data from it right?
Also, Chrome, even on dev channel, still fails to (even partially, like GDI) render your fancier characters, which sucks. I wonder if it's because they are astral? Or it just needs explicit font fallback rules?
go to newer or older post, or back to index or month or day