Postings are provided as is with no warranties, and confer no rights. Opinions expressed here are my own delusions; my employers at best shake their heads and sigh, at worst repudiate the content with extreme prejudice, whenever it manages to appear on their radar.
This blog is unsuitable for overly sensitive persons with low self-esteem and/or no sense of humour. Proceed at your own risk. Use as directed. Do not spray directly into eyes. Caution: filling may be hot. Do not give to children under 60 years of age. Not labeled for individual sale. Do not read 'natas teews ym' backwards. Objects in mirror are closer than they appear. Chew before swallowing. Do not bend, fold, spindle or mutilate. Do not take orally unless directed by a physician. Remove baby before folding stroller. Not for use on unexplained calf pain.
A nice FLAIR (FLuid Attenuated Inversion Recovery) view from the not-too-distant past. Every abnormality you can see on this scan (and there is more than one!) is asymptomatic at present. Alongside is a picture of me walking the walls at Fremont Studios, a sign of a damaged brain.
You may have been asleep all day yesterday after some party.
Or maybe you were in bed, sick from the flu.
Either way, my point is you might have missed the news mentioned all over and covered in the Building Windows 8 blog: Delivering the Windows 8 Release Preview.
The Release Preview is available in 14 languages:
I cribbed the list from the Windows 8 Release Preview: Frequently asked questions, which also had a little more info about the languages:
The Windows 8 Release Preview Setup program will automatically detect your current language selection. If you don't have one of these languages selected, you can choose the language you want to download.
Good info!
Now as in the Developer Preview and the Consumer Preview before, you may see some blogs from me here covering exciting new features now available to you in the Release Preview.
Feel free to ask me here if you try the Release Preview and have a question about some feature you just noticed.
There are a lot of things I'm pretty excited about, and I can't wait to talk about them here!
The other day in the blog, Jan Kučera (friend/colleague/regular reader/aspiring Tamil expert) commented about Have you started looking at the Windows 8 Release Preview yet? in part:
But one of the bigger surprises is that the new default font for Tamil uses an old variant of the script (AI/AA ligatures), is this intentional?
Now let me take a moment to say that Jan is someone I owe a beer and a meal and a copy of Windows 7 and 8 and whatever else I can think of for not being able as much time as I wanted to when i was in India a few years ago, which I feel really bad about.
I think he's forgiven me (I hope so!), but let me take a moment to apologize -- sorry, Jan!
Ok, now with that said, he has a point.
The original Latha font does not have the more traditional orthography sometimes referred to as the "Elephant Trunk" orthography, while the new Nirmala UI does in the Release Preview, as this text in WordPad indicates:
The pseudo-localiazed title bars in these screen shots are because I'm running Cherokee Windows 8 which hasn't yet handed off those strings!
And this new Nirmala UI font is not the default font in the RichEdit used by WordPad in the Windows 8 Release Preview.
Because as I typed the text above, WordPad was making it always use Latha for the Tamil text.
I had to explicitly change the font to Nirmala UI, in fact!
So, I copied/pasted the text into Notepad, you can see the default font behavior when neither font is picked explicitly:
Wow, it has been changed to Nirmala UI.
And now we have Elephant Trunks!
Now Unicode has long ago rectified limitations and problems in their Tamil Block Description.
With the help of INFITT (including me!), Unicode has updated the text in Chapter 6 to make it clear this is the older traditional orthography:
I guess Nirmala UI decided to move away from the "modern Tamil orthography" here!
Kind of ironic given how often people talk about the new Metro user interface in Windows 8 as Modern, at least! :-)
At this point, I've pinged the owners for a comment.
Personally I find it potentially a little troubling.
Since although there are minimal truncation risks to UI via the horizontal differences given the taller vertical aspect of some of these letters, there are high reflow change risks given the narrower horizontal aspects of these letters.
So the next version of Word might have to make a different decision in the way it links Tamil text when the font does not have the text.
But it is definitely a noticeable change in the Windows 8 Release Preview, as Jan noticed!
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:
LOCALE_SLOCALIZEDDISPLAYNAME(aka LOCALE_SLANGUAGE)
LOCALE_SLOCALIZEDLANGUAGENAME(aka LOCALE_SLANGDISPLAYNAME)
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:
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.... :-)
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:
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
though each of those can be quite complicated....
Previous blogs from this series:
Now that we are at the Windows 8 Release Preview, you might figure there are no surprises left on the locale front.
And no one would blame you for thinking this; it is an entirely reasonable supposition!
But looking back to zn earlier part of the series -- part 14 -- you may know where we are going here...
Behold tzm-Tfng-MA!
a.k.a. Central Atlas Tamazight (Tifinagh, Morocco):
And now, we have a ballgame!
Try it out, let me know what you think....
New locale, new script, new keyboards -- new everything! Not even running on my "pseudo-enhanced-pre-Cherokee" view can dampen my positive feelings here -- that's Tamazight using the Tifinagh script!
I think this is pretty exciting, don't you? :-)
I've talked about pseudo-localization a few times before.
Often when I have screenshots of Windows they contain either pseudo-localized of pseudo-enhanced text.
I thought I'd take a moment to explain how pseudo works.
And why so many people run with it on their selfhost machines.
And most importantly, why there are a few senior developers and testers who are serious selfhosters but who don't run it unless they absolutely have to....
Technically, you can put me in that category; while I often selfhost pseudo-mirrored, I avoid regular pseudo (unless it's pseudo-enhanced!)....
The main principle behind pseudo-localization is to localize absolutely everything that can be localized via an automated method.
In this way, anyone can easily notice when text can't be localized due to it not being properly exposed to localization.
And also, if there were supposed to be restrictions on how text was localized to avoid breaking code -- for example with font face names -- that saw the restrictions not properly set, that could be detected as well.
Good engineering, through and through.
So why would some senior developers and testers prefer to not run on pseudo-localized builds?
Well....
Let's look at how the character substitution works.
There are several different tables like this one below that show how to map A-Z and a-z to different lookalike (and look similar enough to be read!) characters:
Now most of these mappings are fine and dandy.
Seriously.
But in some cases, the mapping will change the Unicode General_Category or other key ways that platforms, applications, components, or algorithms use to interact with text.
Perhaps it will changed how it is ordered or collated.
Or how it breaks on words or lines.
Or whether text is to be ignored.
Or not ignored!
If you are a developer or tester and you want to focus your time and effort on valid bugs and not on noise due to bugs in pseudo, then having mappings like
y --> ¥
or
A --> ∆
C --> €
L --> ₤
E --> ∑
O --> Ω
L --> £
a --> ª
c --> ¢
or any of the others can ber challenging....
Because it can be a challenge to be happy when the code you write or the code you test has to deal with that sort of thing....
so I don't blame people who would rather selfhost on pseudo-mirrored builds.
Or true localized builds.
Some of those mappings can be a bit too clever to be smart, if you know what I mean!
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!).
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!
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!
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.
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.
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....
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! :-)
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
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 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. :-)
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! :-)