by Michael S. Kaplan, published on 2006/11/30 10:32 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/11/30/1178347.aspx
Well, depends on how fast you can create it with the Microsoft Locale Builder!
But do be sure to let us know that work is proceeding. We're kind of tired of waiting, too!
(longer version here)
This post brought to you by ䷲ (U+4df2, a.k.a. HEXAGRAM FOR THE AROUSING THUNDER)
# Adam on 30 Nov 2006 10:58 AM:
But what LCID to give it? The biggest problem with working with languages that aren't defined under Windows is that there are so few LCIDs defined.
It's generally easier to reference languages/locales/etc... by rfc-3066 style identifiers (iso-3166/iso-639 pairs) as those lists are very complete and appear to be updated frequently.
Unfortunately, most Windows software (including some which I'm currently working on) uses LCIDs to identify languages. So, if I (or the users of the software I'm working on) need to work with a language that doesn't have an LCID, I need to make one up. Which is clearly going to cause trouble at some point down the line. :(
Do you know if MS have some plans to define LCIDs for languages they don't actually support? Just put them in a "reserved" category or something? Or are you only going to define LCIDs as they become supported?
# Michael S. Kaplan on 30 Nov 2006 11:01 AM:
Hi Adam,
Micrsosoft is moving away from LCIDs and towards the RFC names (using the update to 3066). LCIDs have their days numbered....
# ReallyEvilCanine on 30 Nov 2006 11:03 AM:
Lemme guess. There's as much a chance of this being back-ported to earlier systems as there is of back-ported Unicode support for Win3.11, right?
I'll definitely be giving this it a try. Maybe I can Tom Sawyer a few of my cow-orkers into doing the legwork so I can build special German locales like Platt and Bavarian.
Of course, as soon as customers get used to this availability they're going to demand it of us, too, and our I18N team is <i>still</i> fighting with Eng because there are <i>still</i> hard-coded strings in DLLs.
# Michael S. Kaplan on 30 Nov 2006 11:14 AM:
For managed applications, the support will actually work, all you need is for it to be a 2.0 app.
For unmanaged apps, the backport is highly unlikely. It took an amazing effort to get that support in, and there is no wayto mask that as a bug fix; it is new functionality, which is a hard sell for a service pack....
# Adam on 30 Nov 2006 12:50 PM:
LCIDs might have their days numbered, but that doesn't help me supporting the ad-hoc private ones in an unmanaged legacy app. :(
(But it's not your job to help me with mine, so ignore me, I'm just moaning :)
However, is there an official page somewhere that mentions the deprecation of LCIDs for .NET 2.0+? I could use the ammo to bolster my case for getting us to move towards rfc-3066 locale identifiers for future development. The old hats have been using LCIDs for years, are used to them, don't want to take the perf/bloat hit (ints are generally quicker and smaller as database keys than strings) of real names, are more numerous, and generally have more weight in discussions than me...
# Michael S. Kaplan on 30 Nov 2006 2:08 PM:
Well, the fact that custom cultures do not work with LCIDs is a pretty compelling issue.
I don't know about "official sites" beyond the fact that new features are only being put on the name-based Win32 NLS API functions and such, does that count?
# Charles Bocock on 4 Dec 2006 7:22 AM:
OK, so just to check. Can I use this to create an English version of Vista and finally get rid of "favorites"? :)
# Michael S. Kaplan on 4 Dec 2006 4:29 PM:
Um, huh? We're talking about adding a custom locale, which does nothing like this?