One simple approach to this problem is to add a "language" field in each model which identifies the language used for each record. This seems to be the approach used by django-pluggable-model-i18n.
Another approach is to use Python metaclasses to identify fields for translation, as used by django-translate and django-transmeta.
There are several other projects but many of them seem abandoned or lower quality. Django-transmeta always seemed the most interesting to me.
Edit: muhuk just wrote an excellent article today reviewing different translation projects: http://www.muhuk.com/2010/01/dynamic-translation-apps-for-django/
The decision to use 1st January 1753 (1753-01-01) as the minimum date value for a datetime in SQL Server goes back to its Sybase origins.
The significance of the date itself though can be attributed to this man.
Philip Stanhope, 4th Earl of Chesterfield. Who steered the Calendar (New Style) Act 1750 through the British Parliament. This legislated for the adoption of the Gregorian calendar for Britain and its then colonies.
There were some missing days (internet archive link) in the British calendar in 1752 when the adjustment was finally made from the Julian calendar. September 3, 1752 to September 13, 1752 were lost.
Kalen Delaney explained the choice this way
So, with 12 days lost, how can you
compute dates? For example, how can
you compute the number of days between
October 12, 1492, and July 4, 1776? Do
you include those missing 12 days? To
avoid having to solve this problem,
the original Sybase SQL Server
developers decided not to allow dates
before 1753. You can store earlier
dates by using character fields, but
you can't use any datetime functions
with the earlier dates that you store
in character fields.
The choice of 1753 does seem somewhat anglocentric however as many catholic countries in Europe had been using the calendar for 170 years before the British implementation (originally delayed due to opposition by the church). Conversely many countries did not reform their calendars until much later, 1918 in Russia. Indeed the October Revolution of 1917 started on 7 November under the Gregorian calendar.
Both datetime and the new datetime2 datatype mentioned in Joe's answer do not attempt to account for these local differences and simply use the Gregorian Calendar.
So with the greater range of datetime2
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)
Returns
Sep 8 1752 12:00AM
One final point with the datetime2 data type is that it uses the proleptic Gregorian calendar projected backwards to well before it was actually invented so is of limited use in dealing with historic dates.
This contrasts with other Software implementations such as the Java Gregorian Calendar class which defaults to following the Julian Calendar for dates until October 4, 1582 then jumping to October 15, 1582 in the new Gregorian calendar. It correctly handles the Julian model of leap year before that date and the Gregorian model after that date. The cutover date may be changed by the caller by calling setGregorianChange().
A fairly entertaining article discussing some more peculiarities with the adoption of the calendar can be found here.
Best Answer
UPDATE:
As of March 2012, 99translations has been discontinued. Another similar service I've found is www.getlocalization.com/
ORIGINAL MESSAGE:
You could use something like 99translations.com. Open a project there and ask your community to help with translation. For example this is how the guys at smartgwt did it