by Michael S. Kaplan, published on 2006/12/17 18:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/12/17/1312699.aspx
There are some things about MSDN links that are weird, and hard to use, and maybe even a problem internationally, to boot.
Let me explain....
There are currently two main kinds of MSDN links. As an example I will use CurrentUICulture, to show you what I mean.
One kind of link looks like this if you look at MSDN's own search:
And then if you jump to that page, the page notices that you jumped to a content page without the surrounding frame and 'helpfully' redirects you to another link, which shows up in your address bar:
Now obviously there is a relationship here, you can even strip it out by deleting everything in between the two "library" refs as seen in bold below:
Ok, the second kind of link looks like the following:
http://msdn2.microsoft.com/en-us/library/system.globalization.cultureinfo.currentuiculture.aspx
This one seems a little more intuitive to type yourself if you had to, and it does not change in the address bar when you go to it. A definite improvement.
It even has the newer content! :-)
But both suffer from different problems in regard to localization support. To see what I mean, try stripping out the en-us in the URL of each:
http://msdn.microsoft.com/library/cpref/html/frlrfsystemglobalizationcultureinfoclasscurrentuiculturetopic.asp
http://msdn2.microsoft.com/library/system.globalization.cultureinfo.currentuiculture.aspx
The first link will give you a 404 since the page cannot be found. The old links are intrinsically English, I guess.
The second link will automatically move into a language specific link, depending on your HTTP_ACCEPT_LANGUAGE. Once again, the second link is an improvement. :-)
But this is far from perfect. Even ignoring the fact that not all of the pages marked with particular languages appear to be localized yet? :-)
Take a look at that MSDN search for CurrentUICulture. Well over half of the links that show up are to different language versions of that same msdn2 link, and the order is not in any way based on your browser's accept language settings.
That is a lot of wasted space.
Now contrast this with what MSDN Magazine is doing with language versions (pointed out here):
http://msdn.microsoft.com/msdnmag/issues/07/01/Unicode/default.aspx?loc=de
http://msdn.microsoft.com/msdnmag/issues/07/01/Unicode/default.aspx?loc=es
http://msdn.microsoft.com/msdnmag/issues/07/01/Unicode/default.aspx?loc=en
http://msdn.microsoft.com/msdnmag/issues/07/01/Unicode/default.aspx?loc=fr
and so on.
You see, here a search engine, without any extra work, will notce that there is an intrinsic one-ness about this link, and will not randomly ever find the wrong one or find all of them in some weird order.
Because even if they are all stored in different places in different parts of the tree, they are all connected in a unique way.
Now clearly MSDN's search can learn. And so can Google's (which currently also messes this up, by the way). And so can everyone else's.
But it is mildly arrogant for a content provider to expect the search engines to figure this out!
Search engines should not have to learn about MSDN's unique weird content strategy to know how to index it. The content should be put together in a way that allows searchengines to automatically show the best results, since the folks who provide MSDN content want people to find what they are looking for.
They probably won't be able to change MSDN content any time soon. Though I have high hopes for a future msdn3!
Sometimes you blame the search engine, sure. But for MSDN you can blame the content provider -- that is who is making search harder in this case....
This post brought to you by Τ (U+03a4, a.k.a.GREEK CAPITAL LETTER TAU)