by Michael S. Kaplan, published on 2011/02/12 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/02/12/10128490.aspx
The truism that explaining a joke allows you to get though it doesn't give you the funny has a lot of truth to it.
In this case, if you didn't watch M*A*S*H you may have trouble discerning what is behind the riddle of the title of this blog.
It involved an episode where Margaret "Hot-Lips" Hoolihan, while drunk, reveals:
I probably shouldn't be telling you this, but Frank Burns is a lipless wonder.
And as with all jokes that must be explained, the people who now get it don't think it is very funny.
You can think of the issue as an extension of ELKs aren't roaming where the servers are from over five years ago.
Because although it is true that ELKs -- the infrastructure data added to XP to support the creation of LIPs -- was [mostly] added to Windows Server 2003 (I gave the full list in Why Bengali keyboards can't be found on XP 64 bit), the truth is that all of this ELK insertion work into what essentially represented the server code base, cool as it was, did represent a specific type of ELK, one not found in nature.
A LIP-less ELK.
We don't release LIPs for Windows server products.
We get questions on this all the time, questions like this one:
Good morning all,
My customer has the following question about a language pack for Windows server 2008 R2 that does not appear on the list of supported language pack in the technet link below. Is this list authoritative or is there another way I can find this language pack for them. Any assistance would be greatly appreciated.
I am having no luck finding an o.s. language pack for Windows Server 2008 R2 Hindi language. Am I overlooking something?
I also looked out here and it doesn’t look like there is one for Window Server 2008 R2 operating system: http://technet.microsoft.com/en-us/library/dd744369(WS.10).aspx
Regards
This person got a quick answer, even if it was not the answer being sought:
WS08R2 didn’t release a LP in Hindi.
Here are the languages we did release LPs for:
http://www.microsoft.com/downloads/details.aspx?FamilyId=03831393-eef7-48a5-a69f-0ce72b883df2&displaylang=en
English, German, Japanese, French, Spanish, Chinese Simplified, Chinese Traditional, Korean, Portuguese (Brazil), Russian, Portuguese (Portugal), Dutch, Swedish, Polish, Turkish, Czech, Hungarian, Arabic, Danish, Norwegian, Finnish, Hebrew, Greek, Thai, Ukrainian, Romanian, Slovakian, Slovenian, Croatian, Serbian Latin, Bulgarian, Lithuanian, Latvian, Estonian
Now the answer was slightly off target since it was about Language Packs, not LIPs. But as we know everyone makes that mistake (for more info on that issue, see When terminology affects satisfaction and Out of touch? No, just out of scope...), so I won't dwell on that part, so much. But the truth is that for those LP languages, server resources are translated.
Of course, the truth is that from a customer standpoint, this separate treatment of client and server is one that is seldom fathomed. It appears to be arbitrary and pointless, especially in a world where there are people who tend to use the server product as their client.
At one time, the standard developer desktop for Office developers was indeed Windows Server 2003, a fact that at one point got in the way of the ability of Office to work with ELKs and try out LIPs. I have no idea if an updated policy like this still exists over in Office, but either way it serves to underscore the fact that this is a real phenomenon, even inside Microsoft. And one that can affect job productivity, no less!
Now there are many problems with the notion of a LIP on a server.
First of all, a principle behind LIPs of "translating the most visible UI" fails in interesting ways since many visible UI pieces that are server-specific aren't translated.
And then there is the scenario.
If you don't accept the "server as client" scenario's premise, then it is quite easy to consider the principle of making computers more available to people who don't speak one of the major languages we handle fully (like English or German or Japanese) to be way out of scope for the server family of products.
But maybe it is an incorrect assessment to deny the premise.
i mean, I often run the server as a client because I don't tend to go for the fancy client features like Aero and glass and UI transitions, and those features are off by default in server. So it takes less time to get the machine in the state I want it if I start from sever.
I don't know for sure but that probably biases me on the issue. Does anyone else have n opinion about the "running the server as a client" scenario?
Alex Cohn on 13 Feb 2011 10:53 AM:
doesn't the server cost significantly more? Anyway, the typical "server as client" scenario is using terminal services. Correct me if I am missing something, but enjoying a LIP in a rremote session is impossible, too.
Cheong on 13 Feb 2011 5:58 PM:
But if you're buying MSDN subscription like me, you'll want to have server version installed on your development machine all time.
Not only it starts faster, it allows you to develop on the platform it'll be used on, and it makes Hyper-V readily available to your finger too.
I'd believe it's common practice for small size ISVs.
Jeremy Drake on 15 Feb 2011 1:32 PM:
I used to run Server 2003 x64 as a development machine. Back then, for x64, my only Windows choice was between Server 2003 or XP x64, and *nobody* bothered with XP x64 (I remember reading an article that compared it to Windows ME as a dead-end OS). At least with Server 2003, I found the only things that didn't work were things I didn't care about, anyway.
But now I'm at a different job, where the development environment is VS2005 on XP. And I have a feeling that it will stay that way until 2014, when they have to either upgrade or lose OS security updates...
ANA on 21 Jun 2011 12:29 PM:
Hello I read your post on a web page name upall.org very careful with this site
because steals original content from web pages
greetings