June, 2012

Today's riff will be on the page titled Locale IDs Assigned by Microsoft.

This page, largely produced some time after XP and Server 2003 shipped, by an unknown person or people, has everything.

EVERYTHING.

Like one Sorbian, rather than the two we have in Windows now, using the LCID we call Upper Sorbian:

or a bunch of other locales we've changed the name of for various reasons:

or one I doubt we'll ever have (even if a professor convinced someone to add an LCID years ago!):

There is even one with the wrong LCID! 

And a lot more French locales than we've ever shipped:

And a bunch of locales that are likely worth considering some day:

 And there are ones we might even be able to add now:

 And ones we still can't add yet:

 There's even one with [to some] somewhat offensive parathetical text that actually have nine locales now:

You get the point.

This list is insane! It's really the best example of why we should never have lists! :-)

There are times when I can blog rather indirectly, obliquely, and/or theoretically.

Even though some real problem may have originally inspired it -- perhaps an issue that is being discussed with a not-yet-shipped product.

This is kind of cool since people involved with the problem will see the blog inspired by it, and it can help them frame their arguments.

For example, Four cases where I don't like ResolveLocaleName (and you shouldn't either!) was brought up in a meeting where people discussed how to possibly fix that problem.

These "collaborations" are often "conspiracies" in the legal sense, where you have multiple people working on issues without always being aware of each other or their efforts (kind of a Law & Order reference to the 1991 episode The Torrents of Greed -- the right hand doesn't have to know what left hand is doing for then to be part of a conspiracy, whether to commit a crime or to solve an technical problem!

Another example would be When you have just one model, the easiest place to fall short is when something's missing..., where I talked about the complications involved with determining whether a positive number might be 3 versus +3 or even 3+, due to problems in the model that we've never managed to fully sort out.

Then the other day, the following anonymous blog was received by me, from someone who has seen some more direct consequences to the problem, in both shipping product and not yet shipped product:

LOCALE_IPOSSIGNPOSN and LOCALE_SPOSITIVESIGN allow a locale to specify how positive numbers are decorated. They can specify a string and a position. But nobody actually uses it. And sometimes people who try discover that it looks awful because some locale data (such as es-US and el) say “I want a plus sign in front of all positive numbers”, but when you actually put a plus sign in front, people complain “Hey, why are all these plus signs in front of all my positive numbers?”

“Right here, you said that you wanted plus signs in front of all your positive numbers.”

“Yeah, sure, but I didn’t expect you listen to me!”

It’s made more confusing because LOCALE_INEGSIGNPOSN says “Formatting index for the negative sign in currency values”
But LOCALE_IPOSSIGNPOSN says “Formatting index for positive values.” (Note: Not restricted to currency.)

// Although LOCALE_IPOSSIGNPOSN or LOCALE_SPOSITIVESIGN are documented to produce the proper positive format and
// some locales (es-US, el) specify that they want a + (LOCALE_SPOSITIVESIGN) in front of all positive numbers (LOCALE_IPOSSIGNPOSN),
// this request is ignored by .NET and most Win32 apps. So we ignore it too.

Just about now, there are unrelated conversations about whether/how to get code that took the data at its word when maybe it shouldn't have trusted the data quite so much.

Kind of interesting how the conspiracy unfolds! :-)

Sometimes people want to hear my voice really bad.

It isn't very often, but it happens. I swear.

I thought I'd mention some planned speaking events in the future, just in case you are one of those people.

In reverse order:

October 24th @ 15:10 in Santa Clara, California, USA

36th Internationalization and Unicode Conference

Building the Phonetic Keyboard for Cherokee

It has been over a decade since any keyboard layout on Windows has raised the roof on what a keyboard can do, but with heavy use of the long-existing and free but never before used feature of chained dead keys, the single most complicated layout ever created for Windows was created, in a specific answer to a customer request ignored on every other platform. This feature opens the door to many other novel and interesting keyboard layouts that future versions may well find themselves taking advantage of!

October 24th @ 09:00 in Santa Clara, California, USA

36th Internationalization and Unicode Conference

Show Me The Money!

It has always been a rule at Microsoft that locale data is not changed for prior versions or in service packs for the current version. And like all rules, there is one major exception: currency values! I'll be taking you on an exciting journey of the many updates for the Euro, the Indian Rupee, the Turkish Lira, and other times that Microsoft has shown its customers the money....

September 20th somewhere near San Jose, California, USA

A Webcast for IMUG about something related to Windows 8 internationalization/World-Readiness

I'll provide more details when I have some!

August 6th in Brisbane, Queensland, Australia

2nd MyLanguage Conference (MyLanguage: Connecting, Collaborating, Creating)

I will be doing one of the International Keynotes at this conference, and I'll provide more details when they do (it's rude to scoop a conference you are speaking at!)

The rest of the time I'll be somewhere; if you see me you can say hi and hear whatever I say when I'm accosted randomly on the street.

I'm told that too can be entertaining.

I'm currently in search of an original version of the "you have one chance when you meet me and want to say something about the iBOT so you should make sure it's really clever" response.

If you really want to impress me, be ready with something fabulous.Or something cool. :-)

The other day, Jean-François Colson asked over on The Unicode List:

Hello

At http://store.artlebedev.com/electronics/optimus-popularis/ I see a
price in rubles, 31,500 р, where the currency is written р (Cyrillic r).
But that р is displayed as a capital Р (Cyrillic R) with stroke.
I’ve never been in Russia. That’s why I have a few questions:
Is that symbol is in everyday use?
Is it common?
Is it new?
Why doesn’t Unicode support it yet?

Thanks for the answers.

JF

Regular readers might recall this website.

Remember the Optimus Prime keyboard? :-)

Anyway, it takes more than someone trying to sell a new standard, right? :-)

Jukka K. Korpela helped make this point and more:

2012-06-02 22:01, Michael Everson wrote:

> On 2 Jun 2012, at 19:49, Jean-François Colson wrote:
>
>> At http://store.artlebedev.com/electronics/optimus-popularis/ I see a price in
rubles, 31,500 р, where the currency is written р (Cyrillic r).
>> But that р is displayed as a capital Р (Cyrillic R) with stroke.
>> I’ve never been in Russia. That’s why I have a few questions:
>> Is that symbol is in everyday use?
>
> We don't know.

The symbol seems to have its proponents, and the page cited belongs to
one of the eager proponents of the “Lebedev–Tarbeyev symbol”

>> Why doesn’t Unicode support it yet?
>
> Because I haven't written a proposal for it because so far it does not appear that
any of the banking authorities or the Russian Finance Ministry supports it.

The constitution of Russia gives the right to approve a graphic symbol
for the ruble to the Central Bank of Russia. So far, the bank has not
exercised this right.

The page http://www.artlebedev.com/mandership/159/ may give a different
impression. It also has some images depicting actual use.

I guess they just never thought of the possibility of submitting a
proposal on adding the symbol to Unicode. Such a proposal would create
an interesting situation, especially if it were accompanied with
substantial demonstration of actual use.


Yucca

It could indeed lead to an even weirder situation where some people with their own agenda submit a proposal which ends up eventually making it into Unicode -- only later on, people who feel (correctly or incorrectly) that their opinions on the matter were not consulted or even recognized.

One could argue this happened for Khmer.

And Tamil.

And Bengali.

And Assamese.

And so on....

Perhaps we should not be so quick to take the new non-sanctioned, nonofficial currency symbol that the government isn't even asking for yet. :-)

The other day, Question Boy asked me via email:

Mr. Kaplan, I normally would never contact you directly in this unsolicited manner, and I completely understand if you do not have the time or inclination to assist me since this is outside of the standard forum premise, but I have been trying to get some help on a specific issue relating to creating a progress meter for MS Access. I basically had resigned myself to believe it was not possible when Doug Steele mentioned that he thought he remembered you might have a technique to do so. If you are interested in helping out, please take a look at the thread or reply to this e-mail and I will post back any solution you provide so others may benefit as well. I thank you most sincerely for your time and apologize once more for disturbing your in this manner. Sincerely, QuestionBoy

Let me start by saying that I probably don't have a good answer. But with that said....

This one takes me back.

The year was 1998.

I was going through a phase in my life where I was mostly writing C and C++ code.

But I still knew Visual Basic (VB 6.0 at the time) was pretty powerful, and I would get annoyed by people who would talk down to it.

I had just put the TSI Synchronizer out there, mainly because I was naive enough to think Jet Red replication was not going to be left for dead a few years later (they decided to invest in Data Access Pages and ADPs instead; I wonder how that worked out? <grin>).

Anyway, I had just hooked up the event support for replica creation in the TSI Synchronizer, and I was bored so I added some hidden methods in there:

• CompactDatabase
• RepairDatabase
• ExecuteDdlSql

 to go along with the non-hidden MakeReplica method.

They each have Begin, Progress, End, and Fail events.

Perfect for setting up one's own progress meters, or allowing graceful cancels, or whatever.

I got permission to do this from someone the Access team (as with the rest of the TSI Synchronizer, though they did ask what exactly these other methods had to do with replication. I admitted that they had nothing to do with replication, and agreed to mark them hidden.

I think 12 people noticed them over the years.

The CompactDatabase and RepairDatabase methods made their way into other tools, leaving just ExecuteDdlSql as the odd man out.

It is very badly named since it can be used by any query that returns no rows, which does apply to some DML queries and doesn't apply to all DDL queries.

It's just that I didn't have time to build other data objects, and my brief experiments with reusing DAO and ADO objects convinced me that was never gonna happen.

If you look at Question Boy's ask, this won't help him since we wants something that directly integrates with an Access form's behavior -- this solution is much more for a heavy duty DoCmd.RunSQL call.

Breaking into what is going on internally what Access is doing with it's Jet session is a much bigger deal, it involves code somewhat like the TSI ImpExp Spec Tool (2000/2002) and the way it can redirect what Access is looking at, combined with the TSI Synchronizer's events.

I've done it myself (once), for a client that Microsoft referred me to and gave me permission to give them the source files (which have a lot of internal Jet/Access knowledge in them). It was a fairly lucrative consulting job at the time, probably the biggest Access contract I'd had in a while. They were under NDAs too about the internal stuff, but it worked out well.

Anyway, the utilities were able to handle anything other than Jet 3.5 and Jet 4.0 (which is all I had permission to do this for, so even though it would be easy to create a new version for the new Jet replacement that Access uses, it could also get me in a lot of trouble....

So, if you find yourself wanting to have this type of functionality and were peeved that Access could do it but you couldn't and you are using Jet 3.5 or Jet 4.0, then take a look. :-)

I know it won't help Question Boy's specific issue (one probably better managed by

• quicker small resultset queries, or
• disconnected forms where you do all the work so you can build your own status bar, or 
• upgrading to smarter clients who will notice the built-in status bar

though each of those can be quite complicated....

Yesterday in Court stomps on NetFlix's disability argument (aka It Is The Best Of Times...), I talked about a great precedent that win or lose seems poised to impact how we look at the the Americans with Disabilities Act in the future.

Despite these steps that give me hope, I have to admit that we aren't fully there yet.

I mean, there are the problems I had renewing my driver's license that I described in It seems that discrimination is the official policy at the WA Dept. of Licensing.

And then more recently there were my problems in New Mexico I described in Albuquerque is not so accessible to the likes of me....

More recently, Claudia and I had a wonderful visit to Cherokee, NC to visit the Eastern Band of Cherokee Indians, which actually went very well, though getting from a "civilized" airport to the Reservation did require the help of a Microsoft VP's talented Executive Assistant, a bunch of money, and a lot of travel time.

Though for the record let me say that after I was on the Reservation, Cherokee Transit was able to get me to every place we wanted to go, no matter how high into the hills and no matter how many switchbacks -- and it was just $1 a trip. And incredibly friendly people, too!

Next time I'm there, I will outsmart them though, and buy an unlimited monthly pass. They deserve to be compensated for how much easier they made my time in Cherokee, NC. :-)

I'll likely talk more about the EBCI trip in a future blog, beyond the transit system; it was a truly amazing time!

Okay, so perhaps this blog today might almost have ended on a high note.

Except for one or two things.

Like the fact that the upcoming Seattle Punk Rock Flea Market at the Belltown Underground Events Center isn't wheelchair accessible.

Bummer. :-(

And then it gets worse.

My girlfriend has a small surgery set up for next week -- nothing dire and no overnight hospitalization is required. But they do need a responsible person to drop her off and pick her up. To take care of her.

Claudia asked me if I'd do it and I said yes, she put my name down, and no one from the surgeon to any of his staff or schedulers said a negative word about it.

Until they called her the other day to tell her that she had to have another "responsible party".

Due to some kind of "liability issue" for which they can name no legal basis, a non-handicapped person is the only kind of person who can be entrusted for this job.

An issue that never came up until weeks after we were there.

Apparently, even if she and I were married, this discriminatory would still apply.

Grrrrrr.

I'm annoyed.

Claudia is even more annoyed.

Sure, we've lined up our "Shabbas Goy" to meet their silly requirement, but I'm the one she trusts.

If not for the fact that neither one of us wants to distract the surgeon or anyone in his office, we'd probably have a lawyer contact them and insist on the legal basis for this policy. And then sue them for the right to be the one there after they were unable to provide an adequate legal basis.

But alas, there's no upside to fighting them on this.

Once again, I'm a second class citizen, unable to do things that a responsible adult is allowed to do.

And we both get the reminder that as a country have a long way to go before the promise of the ADA's protections will apply to major life activities like this one.

People who know me know that I am not the biggest fan of the ADA -- the Americans with Disabilities Act.

Not because I think it goes too far, mind you.

But because its language has been so thematically restrictive that it is so commonly co-opted to describe limits on how far one has to go to support accessibility.

Although applied broadly by lawmakers, it is applied narrowly by all the people who would rather avoid the extra effort.

it is the inspiration behind the NOT MEDICALLY NECESSARY language created by lawyers for letters signed by doctors who work for insurance companies, like I hinted at previously here.

An analogous narrow reading of the ADA was probably behind NetFlix's lame position about the need to provide captioning for their content -- the argument that the ADA applies only to physical places and therefore could not apply to website-only businesses like Netflix’s “Watch Instantly” streaming service.

They probably wouldn't be moved by arguments like this one:

However, there was at least one person in a position to correct the company's narrow reading of the Americans with Disabilities Act.

A Federal judge. :-)

As the National Association of the Deaf posting titled Landmark Precedent in NAD vs. Netflix indicates:

Judge Ponsor denied defendant Netflix’s Motion for Judgment on the Pleadings seeking dismissal of the case.  The District Court of Massachusetts is the first court in the country to hold that the Americans with Disabilities Act (“ADA”) applies to website-only businesses. The underlying lawsuit alleges that Netflix violates the ADA by failing to provide closed captioning on most of its “Watch Instantly” programming streamed on the Internet, thereby denying equal access to the deaf and hard of hearing community.

Netflix argued that the ADA applies only to physical places and therefore could not apply to website-only businesses like Netflix’s “Watch Instantly” streaming service. Judge Ponsor denied the motion, stating that it would be “irrational to conclude” that: “places of public accommodation are limited to actual physical structures…In a society in which business is increasingly conducted online, excluding businesses that sell services through the Internet from the ADA would run afoul of the purposes of the ADA and would severely frustrate Congress’s intent that individuals with disabilities fully enjoy the goods, services, privileges and advantages, available indiscriminately to other members of the general public.” Moreover, Judge Ponsor stated that the fact that the ADA “does not include web-based services as a specific example of a public accommodation is irrelevant” since such web-based services did not exist when the ADA was passed in 1990 and because “the legislative history of the ADA makes clear that Congress intended the ADA to adapt to changes in technology.”

It's funny how so many court cases go in this direction -- and how many updates to the law have.

So the legislature routinely takes an open view.

And the judiciary often ends up taking this view as well.

It is mostly the people in the big companies who look at the ADA as costs to be avoided whenever there may be a legal justification to do so who want to block this progress.

It almost makes me sad that I used a simple appeal to get my own iBOT when Premera Blue Cross originally denied it (as I described here), and then in the reconsideration made it clear that it was not a policy change.

Even though such a change might have knocked over this flimsy legal manuever and replaced it with something better.

Perhaps if I had fought for broader recognition of the inherent flaws in the "NOT MEDICALLY NECESSARILY" approach, I could have had a landmark precedent of my own!

Now I did say it almost makes me sad -- because had I pursued such a case, then I probably would never have gotten my iBot, even if I won the case.

A tremendous moral victory, to be sure. But I'm not that moral, you know?

Or maybe I'm too lazy to go that route. I'm much more the stuff of winning small battles and enjoying the spoils than of fighting big battles and bringing society forward. :-)

Thankfully, there are organizations like the National Association of the Deaf that take the wider view than I.

Between the legislation Congress has already started on during the last few years regarding online captions and precedents like this ruling, people are being forced to start treating more people like people.

Kind of The Best Of Times....

To be continued, tomorrow!

The separator.

Whether it is something you think of as LOCALE_SLIST:

Character(s) used to separate list items, for example, a comma is used in many locales. The maximum number of characters allowed for this string is four, including a terminating null character.

or System.Globalizaton.TextInfo.ListSeparator:

Gets or sets the string that separates items in a list.

the principle is the same.

Now theory is fine and dandy.

Like all that "The maximum number of characters allowed for this string is four, including a terminating null character" nonsense.

The limit info? That's pretty much just for users. Oh, and also in pseudo where it is two characters long -- as mentioned in Seeing double? You're not drunk; you're just running pseudo! (aka Announcement: Pseudo Day!).

I also previously mentioned ListSeparator in 'Managing' [List] Separator Anxiety., but that was just to point out an unrelated bug.

But then there is the problem many people have noticed for years, and which someone asked me yesterday:

Why does the CultureInfo.CurrentCulture.TextInfo.ListSeparator property return ","?  I would expect it to return ", "  (I.e. comma and whitespace).  When composing lists in the English language comma is by convention always followed by whitespace.

For example "Planes, Trains and Automobiles" rather than "Planes,Trains and Automobiles", even outlook’s grammar checker complains

Now it may be true that Word doesn't like it, but Excel tends to choke any time these "usually single character" locale properties are more than one character.

So I guess you could say we didn't think of it until after it would break Excel!

Not to mention other rules -- like whether a comma goes before the "and", after the penultimate item!

Regular readers likely know how much I'd like to stick it Word for its "helpful" text shortcuts that break so many keyboards layouts and remain the single most common customer complaint about MSKLC.

Can one thwack people from one's own company's paid products just because it is such a common source of problems for one's free ones? Would that be an SBC violation, or an HR issue? :-)

But can we really hurt Excel just because it is one of the main clients of the LOCALE_SLIST, even if its usage handcuffs us from making the locale data more useful? :Probably not.

Though if it were up to me, I'd make both Word and Excel to better here.

I'd make them fix their bugs. :-)

You may have noticed Windows locales cart around a lot of languages.

I talked about this a bit in What's up with the language names? and Regarding the overthinking and underimplementing of names.

We have, for example, all of the following:

Now let's ignore all the random problems that came up in those two blogs.

Let's say you need to show a list of languages, display names, or languages+regions

Which one should you use to get the names:

• the English name?
• the Native name? 
• the Localized name?

Each has specific advantages and disadvantages, depending on the goals one has putting such a list into a user interface.

The English names are a nice way to make sure that many people can read it, up to and including your own testers, even without specific knowledge.

The Localized names are a nice way to make sure everyone knows the language version they have can read everything in their own language, which we have a good faith basis to believe is true.

Note that this is the precise method that has been used in the main list in Regional Options and its later offshoot Regional and Language Options in every single version of Windows that has ever been produced/shipped since 1993.

The Native Names are a nice way to make sure people who are being steered to their own language while being kind of steered away from other languages you don't know, since those are much more likely to be useless to you.

Note that this the logic underpinning the If you can't read it, don't switch to it! concept that Windows has used in MUI from Windows 2000 until Windows 7/Windows Server 2008.

There is one other difference between these three choices that can and will affect their ultimate usefulness for you:

The English Names are largely done by the NLS team (even when occasionally nudged in cases like Bangla/Bengali, Persian/Farsi, Uyghur/Uighur, and other such cases), and the ultimate arbiter of what goes in is a very small group of people, especially when it comes to the general style and form and capitalization and such.

Similarly, the Localized names are usually done by a single localizer who again can show consistency in such things.

The odd one out here is the Native Names, since each one is most often provided by a different person, one per language - sometimes based on preferences or standards requirements or grammatical rules in each language!

Thus, one can see the results of many different preferences in places like the way Windows before Windows 8 could be looking at one capitalized Português and one uncapitalized português in the same list (right next to each other!) as well as seeing different capitalization preference using the same script:

Or the new Windows 8 Add Languages dialog, which apparently alphabetizes by the English name even though the Native Name is so prominently displayed, with such differences:

I ultimately feel that such user interfaces that do not either hide or at least de-emphasize the Native Names are potentially distracting and unattractive for these differences.

So, if someone reports this to me in a bug, I explain it is BY DESIGN for the data itself.

However, there is a bug in the UI itself.

Whether showing off the extensive language list.

Or showing off the fine typography across scripts.

Or whether just plain showing off.... :-)

Sorry for the short break there.

I was trapped under something heavy, and unable to reach the laptop!

I am still trapped, but the laptop is here now and plugged in. So I should be able to hold out as long as the Crunchberries and Limonata do (those silly folk who have questioned my eating habits in the past now know how useful my eating regimen is!).

Anyway, hello everyone!

In honor of yesterday's

Father's Day

festivities!

I thought I'd share a small

localizability

giggle. :-)

It's either already fixed now or it's about to, but there was a scosh of

over-localization

done while

localizing

from

en-US

to

en-GB

in an online help screen:

 Like I said, the programme's help is probably fixed now, but it's worth a giggle or two, right? :-)

Now I'm not British, but I've never called my father

DAD

by the diminutive

POP

though I recognize both of them. Not sure how a typical Brit would feel....

But anyway, enjoy!

And before I forget...

Happy Father's Day, POPDAD!

In response to chcp can't do everything from March 2006, PierreMic asked over six years later:

Is it true that one can't add SimSun as a TrueType command box font on a Windows 7 Ultimate box unless the OS default locale is already Chinese!?

What is a *good* reason for this limitation?

Yes, it is true that the console limits its font selection based on the default system locale.

Since the console is based on the default OEM system codepage, it wouldn't make much sense to let another font outside the system codepage be selected.

This actually is a limitation that no one seems terribly interested in fixing, since changing the way the console works in such a huge way is an implicit promise that the console is still supported.

Which is something no one wants, since the backcompat bar is so high!

In the end, it is better left as legacy. PowerShell is the future for the console (note that the PowerShell ISE doesn't limit font selection this way!).

Over in the Suggestion Box, metathinker asked:

In the Wikipedia page on the classic Mongolian script), it briefly mentions some problems with using Mongolian on computers.

Among these, it links to Microsoft KB article 929763, which details "some problems" with the OpenType layout data for Vista's new font Mongolian Baiti, which (in the KB's own words!) "makes the font almost unusable in Windows Vista."

I sense a bit of a story there. Perhaps someday you will be ready to tell it, Michael?

I'm not sure there's truly a "story" here, but I can tell what I know of it. :-)

The version of the font that shipped in original RTM version of Vista did indeed have the issue:

The OpenType Layout data of the Mongolian Baiti font is used to display traditional Mongolian text. The OpenType Layout data affects various contextual glyph   transformations. This issue occurs because of some problems in the OpenType Layout data in the Mongolian Baiti font file.

However, as the KB article indicates, this weas fixed in version 5.01 of the font.

That version was shipped an update for Vista, an update that was rolled up into SP1.

And that update also shipped with Windows Server 2008.

Windows 7 and Windows Server 2008 R2 also both shipped with this update.

So, yes there is a bug here - one that shipped over half a decade ago.

And quickly fixed, as well.

And it stayed fixed in subsequent releases.

The real bug (IMHO) is in a Wikipedia article that focuses that far n the past as proof that Unicode's encoding of Mongolian is buggy. I thought Wikipedia was supposed to not provide bias against Unicode, Microsoft, or Firefox without substantive information about the problem, a problem of which even the most recent version of the issuses sectin of the page appears to be guilty?

Perhaps Wikipedia could fix that bug, and help describe the actual issues! :-)

 GB 18030 is an important standard in the People's Republic of China.

Important because not complying with the provisions in it when you ship a version of your software means you can't ship the software in China....

Now the latest provisions usually refer to minority language support, like support of Tai Le.

Or New Tai Leu.

Or Mongolian.

Or Tibetan.

Or Yi.

Or Uighur.

And when they come up with requirements of those languages, they don't do it in a vacuum -- they talk to experts of those languages so that when they say what it means to support a language they are able to do with specific details.

In the case of Uighur, one of the issues communicated was that some of the characters in the Arabic Presentation Forms A block in Unicode that were not in the font had to be supported:

Now maybe you wonder why this is important.

Perhaps some implementations don't do the shaoing correctly.

Perhaps some of the tests they do have to succeed even if no shaping is done at all.

I'm not sure, exactly.

But we can certainly do this -- the harder part with the shaping and the Unicode support is there, so a few compatibility characters? That's easy.

In fact, it's done, even though you can't see it just yet for all the characters. It will be there soon enough.

We want to do right by the language.

And the script.

And China....

The SHIFTLOCK attribute of MSKLC is an interesting feature.

You can see it in the UI right here, second CheckBox from the bottom:

In MSKLC's help file, it is documented on the Properties Dialog information page whatsetting it does:

CapsLock turned off when Shift is depressed - Selecting this option imitates traditional typewriter behavior where depressing the SHIFT key turns off CAPS LOCK if it is active, something many users are accustomed to.

Now I remember an old typewriter when I was growing up that used to do this.

And on my Osborne 1, as I mentioned here.

So I understood the idea, even though I hadn't seen such a keyboard in years and years.

I even thought I knew of a couple of keyboard layouts that used this feature:

I mean, say what you want about the Thai Kedmanee and Thai Pattachote keyboards.

But the ones that have the names with (non-Shiftlock) appended to their names clearly imply that the first two are of the ShiftLock variety, right? :-)

Anyway, from time to time I have gotten complaints that the attribute doesn't work for them.

In looking into the matter, I discovered a couple of things.

First of all, the Thai Kedmanee and Thai Pattachote keyboards do not enable ShiftLock.

Not a lie technically, though probably kind of a bug of sort since calling one (non-Shiftlock) implies that the other is....

The actual difference between them is slightly different -- the CAPSLOCK relationship is defined between the BASE state and the SHIFT state, so that CAPS LOCK actually does something! The SHIFT key undoes the CAPSLOCK while it is pressed, but it does not unset the CAPSLOCK key press. Just like kbdus and other keyboards.

So, close but not the same, exactly.

Because of this fact, I'm not tempted to add the SHIFTLOCK attribute to the first two keyboards, but maybe the name should be changed for the other two.

Any thoughts on what a better suffix might be? :-)

Okay, in any case, that's our bug. It's been there for a while, and the difference between what ShiftLock does and what those two keyboards do is sufficiently abstruse that I wouldn't be surprised if no one else ever noticed it.

Second of all, people who click that ShiftLock CheckBox who complain it doesn't work haven't actually clicked the caps = shift CheckBox  on any key.

Well....

How can you expect CAPSLOCK to do anything that might involve ShiftLock functionality if you never asked CAPS LOCK to do anything?!?

Now in retrospect, this would have made a great validation rule in MSKLC, to detect when you ask for a feature that you never bother to use.

But the fact that it doesn't do that can't keep this from being caused by the keyboard author; most validation rules are just as "obvious" and any rule we missed is not MSKLC's fault.

The whole ShiftLock feature falls in that list of things like dead keys and SGCAPS and ALTGR that if you (a) don't expect it, and (b) don't understand it, you are sure to be unhappy with the results....

Previous blogs from this series:

• part 23 (Tamazight? Outta sight!)
• part 22 (Digit Substitution 2.0)
• part 21 (The Windows 8 Hijripalooza extraordinaire!)
• part 20 (Yes, it's Bangla. Not Bengali!)
• part 19 (In honor of International Mother Language Day...)
• part 18 (Two scripts that share ten digits can be trouble)
• part 17 (Today I feel like translating you more than before)
• part 16 (We can't scale to a Xishuangbanna Dai locale, but…)
• part 15 (Fixing our listings up in Windows 8!)
• part 14 (Tifinagh, Tamazight, and Berber? Oh my!)
• part 13 (Divvying up locales, yet again!)
• part 12 (Logic dictates that we keep a sense of proportion about the RATIO)
• part 11 (What language is that keyboard for?)
• part 10 (Perhaps it is best to think of it as unintelligent design?
• part 9 (Nastaleeq vs. Nastaliq? Either way, Windows 8 has got it!
• part 8 ([Finally] taking care of some [more] languages in Pakistan
• part 7 (That would be a 'call and a raise' for Hawaiian)
• part 6 (Behind the Cherokee Phonetic layout in Windows 8)
• part 5 (...until the decision was made to not refuse to add it)
• part 4 (working beyond one's bugs, and the case for an MSKLC update)
• part 3 (working beyond one's bugs, the setup)
• part 2 (raising the roof on keyboards)
• part 1 (Some people don't want to double-d's)
• part 0 (The introduction)

Now that we are at the Windows 8 Release Preview, you might figure there are no surprises left on the locale front.

On Friday, April 25, 2008, I wrote I Adar you! Hell, I Double Adar you!, talking about the Hebrew calendar.

And about the leap year support ion the Hebrew calendar.

And about the month of Adar (אדר), which has a cloned version of itself during those leap years.

And about the various and sundry bugs in pretty much every version we ever shipped of Windows, the .,NET Framework, and Outlook surrounding the way Adar (אדר) is supported.

But something quite interesting happened in Windows 8.

We got the Windows.Globalization Namespace!

One of the very cool developers working on it sent me an email.

On April 14th, 2012, actually.

Or perhaps I should say כ״ב בְּנִיסָן תשע״ב, instead. Since we're talking about the Hebrew calendar and all. :-)

Anyway, Eric asked me how I felt about the Windows.Globalization Hebrew calendar returning

during regular years, and

during leap years.

Needless to say, I was quite pleased!

Suddenly, the "Modern", "Metro" Windows 8 had fixed one of our oldest longest standing calendar bugs...

I Double Adar you to not be excited thinking about Windows 8 calendar support!