There may be a more elegant way to do this localization in the database, but I just store the different-language data values in tables like this:
WIDGETS
widgetid
widgetname nvarchar (default English)
WIDGETSLOCAL
widgetid foreign key references WIDGETS(widgetid)
language_code
widgetname nvarchar
unique composite index on (widgetid, language_code)
And then I either create separate views (e.g. view_WIDGETS_enus, view_WIDGETS_ruru) or use the language code in the WHERE-clause, or pass the user's language code to a stored-procedure. Our databases are not properly "localized" in the strict sense of the word; we just have several different translations available based on the primary native languages of our user-base, which happen to be English, Spanish, and French.
For dates, we always use the US-format but with the month abbreviated: 15 MAR 2010 rather than switching between dd/mm/yyyyy and mm/dd/yyyy formats. Our database does not contain any money columns so we don't encounter decimal or currency formatting issues.