January, 2013

Previous parts in the series:

• part 1: Working Together on Gadugi
• part 2: Let's talk about the keyboards!

Over on the Micriosoft Language Portal Blog, colleague Palle Petersen mentioned on December 21st Windows 8 now available in Cherokee:

Windows 8 became available in Cherokee this week. In the making for over 3 years, the Cherokee Language Interface Pack for Windows 8 was built in collaboration with the Cherokee Nation Language Team. The work also involved creating a completely new font for Windows 8, Gadugi, a Cherokee word which roughly translates to “working together".
 
The release is part of the Microsoft Local Language Program, which will eventually bring 109 languages to Windows 8.
 
Head over to the Local Language Program site to see a list of the languages available for Windows and Office, and what's coming to Windows 8 and Office 2013.

No offense to Palle, but he did skip an important detail or two.... :-)

You can see hints in Cherokee Is First Native American Language On Windows 8:

TAHLEQUAH, Oklahoma -
Cherokee is the first Native American language fully integrated into the new Windows 8 operating system, a fact that will be celebrated Wednesday at Sequoyah Schools in Tahlequah.

More than 20 years ago Microsoft employee Tracy Monteith, a Cherokee from North Carolina, asked the company to include his native language in the computer's core operating system. It wasn't until 2010 that Cherokee Nation language technologists met with Monteith and others at Microsoft to get the project off the ground.

A team of translators was assembled, ranging from tribal employees, speakers in the community and even Cherokee college students.

Lois Leach, a 56-year-old clerk in the Cherokee Nation roads department, logged more than 100 volunteer hours over the past year translating computer terms that did not exist when the Cherokee language was developed.

"You don't look at yourself really doing anything that huge until you see it come together," Leach said. "It's amazing to think our work will be shared all over the world."

Wednesday morning, Cherokee Nation Principal Chief Bill John Baker and Microsoft officials will be on hand at the school for an event recognizing the accomplishment.

That story skipped a detail or two as well. :-)

The main thing both stories missed was that at the heart of this project was the first step of two of the three federally recognized Cherokee groups -- Cherokee Nation and the Eastern Band of Cherokee Indians -- that were long sundered across a Trail of Tears that few outside those two communities will ever fully be able to understand the depth of, yet came back together (just as in the promise of the Gadugi font's name in "coming together") to help in the process of translating and more importantly localizing Windows 8 to Cherokee.

The original sundering between the two groups, the one that had to fight to survive as it was forced out and the one that fought to stay in its ancestral land remained important, as a part of the grand mythology weaved into both communities. Yet it became so important for them to come together after over 180 years apart so they could tell an even larger story.

A story of the children of these two communities connecting via Skype, and as two groups of elders saw were able to reach out and communicate and understand each other.

They aren't just coming together -- they were together all along, and they are together now.

And as would have been said by Tsali (ᏣᎵ), They are Cherokee!

I thought I'd blather about the console for a bit.

There are three basic kinds of console applications:

1. Most console applications emit data that is read later, usually in other tools;
2. Many other console applications emit data that is generally used right in the console;
3. A few console applications are interactive with the user.

Some people who spend most of their time with the latter two categories might argue about my wording's claim of common usages, and there are tools that span categories (e.g. using PING's results in a log file), but overall I believe this categorization holds true.

Now let's add internationalization and world readiness to the mix.

For the first category, where the end result is primarily for some other app, WR is easy to do and fully support any characters, whether off code page or supplementary or combining or complex.

Everything can just work.

In the latter two categories, and when the first category initially displays in the console, the WR story is pretty bleak.

Even if you are building completely Unicode console apps and are using TrueType fonts, the best you can hope for when you are off code page or supplementary or combining or complex is square boxes -- otherwise all you get is usually lots of corrupted display and question marks.

This is especialy true in PowerShell, where for then most part it doesn't have to be!

Well, it does have to be for legacy CSRSS/cmd based PowerShell, where these limitations are baked into the architecture.

But the Integrated Scripting Environment (ISE), can support it all, whether off code page or supplementary or combining or complex.

The ISE can even do amazing things with those few proud legacy Unicode console applications I mentioned earlier.

Remember WriteLineRight.exe?

Here it is, in the legacy console with raster fonts:

Even Unicode can't do much with raster fonts!

Let's try with Consolas:

Much better!

But let's try it in the ISE:

Oops, I forgot they stupidly picked Lucida Console as their default font!

Let's go to Tools|Options... and fix that:

That's better!

We don't even have to run WriteLineRight.exe again:

Just one settings change away from magic!

And now my challenge to you PowerShell developers, and you legacy console developers....

Strut your stuff in the ISE, and see what happens.

No offense, but I'm guessing you.aren't quite World Ready yet.... :-)

Our group moved to Building 86 while I was out breaking my hip late last year.

This was not a good move.

So here sits my immediate list of reasons for why I think this....

Reason #10: I think they actually fired us!

I think we were actually fired late last year.

Some Exec said "Those localizers? Let's 86 'em all!"

The vendor given the task (who himself saw his contract being cut short by that same Exec) decided to strategically misunderstand the Exec.

And he moved us to Building 86, instead.

Now, in the true spirit of Office Space, due to a glitch in the payroll system, we are all stil being paid.

However, I fully expect them to "fix the glitch" at some point....

 Reason #09: Wheelchair vans won't pick up from the 86 North Entrance!

This is of course the only entrance to the building with lving, breathing receptionists.

Now it is true that some of the larger Connect vehicles can't fit there comfortably.

But the 50*, 63*, and 64* vehicles whose fewer than 10 of the 300 vehicles that make up the ADA approved method of wheelchair vehicles can all fit there comfortably.

This is not the fault of the drivers, who clearly know their vehicles.

It is, however, the fault of the dispatchers, who clearly do not.

The dispatchers require that pickup happen at the 86 West Entrance, which has its own problems that I'll discuss shortly.

Reason #08: Wheelchair vans won't drop off to the 86 North Entrance, either!

For similarly misguided reasons, those Connect dispatchers won't allow ADA approved wheelchair vehicles to drop off there, either.

This issue is slightly offset by the drivers, who as I said know what their vehicles can do.

I guess the Connect dispatchers need a refresher course!

Reason #07: The 86 North Entrance has no ADA aproved entry method!

There are no buttons to facilitate entry to or exit from the reception area.

Similarly, there are no buttons to facilitate entry to or exit from the building proper.

The door is not uncomfortably heavy (unlike other Safeco buildings like 85!) but it is incredibly awkward to navigate when you are in a wheelchair.

Especially if you are carrying something, like a lunch tray!

During working hours, the receptionist can help by either holding the door open that I hand them, or coming out from the desk and holding the door open.

On the bright side, they can at least do that easily enough -- unlike other Safeco buildings like 85!

Reason #06: The 2nd floor of the 86 North Entrance has no live attendant and no ADA-approved entry/exit method!

So, you come into 86 via the North Entrance, say hi to the receptionists, and take the elevator to the 2nd floor.

Perhaps you are going to the cafeteria.

Or perhaps you are coming from the 86 cafeteria with your lunch to take back into your office.

Once agan, the door is not uncomfortably heavy (unlike other Safeco buildings like 85!) but it is incredibly awkward to navigate when you are in a wheelchair.

Especially if you are carrying something, like a lunch tray!

And this time, you have no receptionist to help you. :-(

You are left on your own to navigate the door.

Reason #05: The 86 East Entrance has no live attendant and no ADA appoved entry/exit method!

Now there are ADA-approved buttons to get into and out of the building.

However, there are no such buttons to get into or out of the building proper!

Clearly, somene wants to make it hard to get to my office on the 1st floor of Building 86!

Reason #04: The 86 West Entrance has no live attendant and no ADA approved entry/exit method!

To complete the set, this entrance does indeed have ADA-approved buttons to get into and out of the building.

However, there are no such buttons to get into or out of the building proper!

During working hours, there are usually people there to help, almost more often than any other case thus far.

But as the only door the Connect dispatchers will allow ADA-approved wheelchair shuttles to drop of to or pick up from, the lack is a srious ssue.

Made even more serious because...

 Reason #03: The door between the 86 cafeteria and the 2nd floor of 86 has no ADA appoved entry/exit method!

So, you make it into Building 86 and you are home free, right?

Well, almost.

You are now in the 86 cafeteria.

There is one more door, between the 86 cafeteria and the working portion of Building 86 lacking a live attendant.

Reasonable for such an "internal" door.

Not so reasonable is the lack of an ADA-approved entry or exit method into or out of the working portion of 86.

Especially for the only door approved by Connect dispatchers!

 Reason #02: The previous tenants of 86 should have had to forward their security deposit on leaving (to us!)

The previous tenants of the portion of 86 we moved into must have really enjoyed their time there.

Because they left us with a building that looked like the morning after a huge frat party to move into.

It is not just the security de\posit we earned, but their next year's morale budget should be redirected to our 86 beautifiion needs!

Reason #01: There are no window offices in Building 86!

After being at Microsoft for more than ten years and three pror failed attempts, I finally have enough seniority to have a window office.

Enter the cynic's dream, Building 86: the one without any window offices!

This must have been the building Safeco sent the peolple they didn't like very much....

Our boss, a Senior Director who I believe is a Partner, has nothing more than a view to a window!

What's up with that?

And finally, bonus Reason #00: Buildings 84-86 are not properly handled by Connect!

By established Connect rules and procedures, shuttles dispatched to the Safeco buildings always enter from the North and exit to the South.

Unfortunately, from the point of view of both handicapped people and the ADA-approved shuttles that convey them, this is simply wrong.

Wrong.

WRONG.

It forces the hadicapped to cross the thruway to shelters not properly equipped to handle them.

And it forces ADA-approved wheelchair vans to use lifts with insufficient space.

The fix would be easy: require ADA-approved shuttles traveling to/from buildings 84, 85, and/or 86 to enter from the south, and exit to the north!

Of course, this flies iun the face of established Connect rules and procedures. And thus cannot happen.

It may be fun in idle moments to tell people I will quit the first time these inaccessible doors cause me to spill a food tray.

And it may be amusing to fantasize about the ADA lawsuit involving terrible working conditions and the constructive ternination they engender.

The costs are not trivial: the estimated cost to retrofit ADA accessibility on Building 24 was $150,000 more than five years ago. While fixing the five doors in 86 may qualify them for a volume discount, it can still cost them upwards of 3/4 of a million dollars to fix.

It may be cheaper for Microsoft to settle the lawsuits! :-)

But in truth I like my job, and while they may not think me worth $750,000 to fix Building 86 to be more accessible to me, they may think we worth the ~$600 to move me to a more accessible building like 26 or 9 or the Commons or anywhere else....

Okay, a long hiatus after surgery, I'm going to ease back into blogging. Thank you to all who have wished me well.

Those who wished me ill can take solace in the fact that they weren't completely unsuccessful. :-)

I will be talking about the injury and the hospital and the nursing home and the accessibility issues I now face as a fulltime gimp at home, at my girlfriend's place, and at work on other days, in other blogs in the future.

For today, I thought I'd cover a question from my email Inbox....

The question I was asked was:

I was using a program that was describing time durations like the ones returned by GetDurationFormat. But for longer time periods, it was describing months and years, and I couldn't get GetDurationFormat to do that. What's the secret, what am I missing?

Upon further questioning, he admitted that the program was μTorrent.

I decided not to ask what he was trying to (perhaps illegally!) download.

Or whether it was porn.

Or what porn might take weeks or months to download.

I had in mind reproing it and getting a screenshot, I explained.

He gave me the name of the file and right after I took the screenshot:

I deleted the file and uninstalled μTorrent. :-)

But it proved his point -- although I couldn't get a screenshot of it (it jumped to days too quickly and I didn't want to keep it downloading any longer than I needed to for the art. Bad enough it was on a work machine!), I did see it saying weeks for a few moments, and I could extrapolate based on the customer report to me that it was probably doing that.

I am reasonably certain that they aren't using GetDurationFormatEx or its LCID favoring cousin.

Because we never defined any other symbols to use for longer time periods.

They must be rolling their own.

Building on it by taking our function and parsing the results to extend them feels very painful and risky....

But it got me thinking about a few other things.

First of all, some people have way too much free time and free hard drive space!

Second of all, adding these might be a good idea, though it multiplies the risk of grammatical mistakes that even the current function could show with custom format strings that use words (I have seen programs that use it this way).

Third of all, the function only taking a SYSTEMTIME in lpDuration or the 100-nanosecond values in ullDuration is rather awkward. Why not the option of two SYSTEMTIME values as real datetime values to get the duration between? There are lots of usage scenarios where the function would be quite useful but either of the options we give would be quite awkward if not unreasonable. Why make them do so much extra work?

When you get down to it, a duration that is very long becomes awkward very quickly.

Like the title says, it's not how long it is, it's how you describe it when it's long!

I'll suggest something to the NLS folks (well, I'll make sure they see this blog!).

It's good to be back.