I've been out of the office and all over the country of late, up to Redmond 3 times this month and as far from Portland as Raleigh, North Carolina.  Consequently, I've not blogged.  However, I did get an "A" in Physics/Calculus, so thanks for asking. ;)  Turns out my graduation is June 6th, so looks like it will interfere with TechEd.   I'll probably give my presentation and immediately jump on a plane to make it to commencement in time.  (For those of you who don't know, I've managed to squeeze my undergrad into the last eleven years.  Currently I'm Chief Architect at Corillian Corporation, but on Tues, Thurs and Friday nights, I'm just a snot-nosed tyro trying to get through my Physics exams on electromagnetism.  Ah, my life.)

Also, lately I've been up to my ears in ASP.NET, today working on Internationalizing multi-lingual ASP.NET web sites in a performance way, while still using the .NET Resource Manager. 

In the process, I've collected these links on Globalization/Internationalization:

• Globalization & Localization Best Practices for Windows 2000 Compliant Software
• The Best Localization Directory - Dozens of great links and software
• Microsoft Global Development Portal
• Authoring HTML for Middle-Eastern Content
• Bidirectional Layout in the HTML 4.0 Spec (ÇåáÇ æ ÓåáÇ ãä ÇáÔÑ Þ Çáà æ ÓØ.)
• Microsoft Localization (Globalization) Toolkit - For Developing Localized ASP.NET Applications (Database Driven)
  I started by looking at this unsupported Microsoft tool with great interest.  It will sure teach you lots about how ASP.NET render controls.  It uses a database and reflection, overriding PreRender and Render and replacing keys with localized text.  It is very CPU intensive, but this can be mitigated by judicious use of the Output Cache directive.  However, for my sites, this isn't possible since each page is rendered specifically for each user.  I'm instead using a base class "LocalizedPage" with an optional virtual function "ApplyCulture" and some utilities to allow the user to localized controls.  Since pages are designed in the "local" language, only the 10% of (for example) Spanish users would cause increased CPU on a 90% English site.  More on this in the future...