What I asked me since a long time: If I DO use the MSLU, is CString then Unicode enabled?

I.e. if I enable MSLU for my project, do the CString functions all use MSLU functions only? Or should I use my own string class to be safe?

Your blog doesn't work well in firefox - the comments disappear when you mouseover. Any chance of updating your style?

Sure -- they do not give us many choices, and I do not run FireFox. But I'll try changing and you can let me know if it worked. :)

I always use '6 jun 2004' format in code, be it sql,c# and when ever possible enforce this thru ui controls.
I seen systems require the user to set his/her date format in regional settings becuase the original programers couldn't cope with database asuming mmddyy where the local tradition is ddmmyy [shudder]

Recently, I had an xml file that had a date in it.
I don't know what the name of the date format was.

I would have liked to be able to pass a format string and the date string to get a date.

I've run into this all of the time. My solution is to use MMM/d/yyyy as the forced date format at all times, because it appears to be the only format that the .net framework won't screw up if the region changes (i.e. Canada versus the US, Japan versus the US etc.)

My biggest problem now is getting a nice UTC date /time stored and actually get it to come back at the right time even with day light's savings shifts. The only way I have been able to do this is to have a separate date field and an int for the number of minutes from Midnight and make everything relative to Jan 1st 1900 which shouldn't change. Otherwise we end up with head aches.

I really really really wish there was a format that .net would parse with time zone info on it. (i.e. that used by POP3 mail servers)

2004/01/06 1:00 -0500 should be parsed and it should parse correctly and consistantly. Currently .net will throw an error trying to parse that, which is ironic because it's the standard for POP3.

That in EVERY format and semantic should always translate to:

January 6th 2004 1:00 AM in EST (or CDT)

Given this information we can then handle appointments that are not time zone centric and act accordingly even if two offices sharing data are in two different time zones using two different regional settings.

I hear that SQL Server 2005 is going to handle Time zone information finally, now I wish .net did string date parsing correctly with it. (asside from it would save me a lot of frustration with Email messages...)

Oh and a tip for everyone because I think I get asked this more often than anything else. When writting inserts and updates to SQL Server or any other database server, always use yyyy-MM-dd HH:mm:ss as your format that you pass the date string because it will always be recognized by the SQL Server correctly, unlike every other format that just formats it however it feels like and often just fails entirely, especially with MM/dd/yy or dd/MM/yy (yes, both of these should be abolished... we need one world wide standard!)

Thanks for the anecdote...

Hi Kaplan,

You didn't mention the database normalization in first para :)
In relational database design, the process of organizing data to minimize redundancy. Normalization usually involves dividing a database into two or more tables and defining relationships between the tables.

Yes, that is an excellent point! That would be yet another usage (and one that I dealt with with in my former, pre-Microsoft life).

But I limited myself to meanings that I have been exposed to since I came to Microsoft, and none of them brought that one up.

Plus, I figured it did not really help the point of the article much since database normalization is ever further from the dictionary definitions. :-)

I just wanted to let you know that I'm totally digging your posts. Keep it up.

http://www.hanselman.com/blog/SearchView.aspx?q=internationalization

Always good to know people are having fun... after eight years at Microsoft (six as a vendor, two as a full-time employee) I could probably have a post a day for some time. :-)

Very interesting. Yesterday I was trying to explain why upper/lowercasing operations are a bad idea and better avoided whenever possible. Now I can add Georgian to the list of reasons, along with Turkish dotted I's :)

ushimitsudoki.com : the blog » Machine Translation is not easy

Good translation is not easy (whether done by a machine or a human being).

Something that can be done to make it easier is reducing the complexity of the language itself. This is feasible with something like manuals, it is possible to write reasonably good manuals using a limited subset of the language (e.g., limited set of verb tenses, simple sentence constructs only, no ambiguous words) and make it easier, for machine translators, for human translators, and for foreigners who read the original version of the manual.

It would be great to see the grammar checker in Microsoft Word extended with a new writing style called "easy to understand", and maybe then it will be possible to create a machine translator that can handle the text that passes the check.

Very good point, although it assumes one is looking at the problem as a closed one where one has control over the language of the source material being translated....

Since its not specifically something I am working on (it just interests me a lot!), I usually tend to look at the problem as an open one -- how good can we make it with any arbitrary text to translate.

Plus I am worried about the impact on a software product if such an effort were successful....