Erland,
Thanks for your reply. I am wondering if there is any sample DB schema
available on the web. I would like to see an example that how several
related-tables also need to be localized. Any suggestion to re-arrange
those existing relationship? I am kinda new to localization problem,
please give me some hints.
"After some discussion, we decided to take the big step: the names were
moved out specific name tables. For instance the countries table
would get a subtable countrynames with the key (countrycode,
languageid).
For simplicity we did keep a name column in the main table, so we
can use that as a fall back if there is no name in the current language
in the name table."
Erland Sommarskog wrote:[color=blue]
> iceriver (hfung@hotmail.com) writes:[color=green]
> > I already have a web site running with SQL Server as a backend (in
> > english)For future growth, I would like to make it localized.[/color][/color]
Regarding[color=blue][color=green]
> > the database, I have come up with several approaches.
> >
> > 1) just simply add the column in those table which needs different
> > language.
> >
> > 2) add additional tables to do it.
> >
> > 3) create a new database to store different language's information
> >
> > As mentioned, my database have already been implemented, so the[/color][/color]
minimum[color=blue][color=green]
> > modification is preferred. Could you guys suggest me the best way[/color][/color]
to do[color=blue][color=green]
> > it?[/color]
>
> Adding multi-language support is a task with an impact. Without[/color]
knowing[color=blue]
> the nature of your database it is hard to give recommendations.
>
> In the system I work with, we once faced this problem. At that time,
> many our tables had two name columns, for instance countryname and
> countrynamefor, holding the Swedish and English name respectively. As
> we entered the Finnish market, we needed support for a third[/color]
language,[color=blue]
> since in Finland, both Swedish and Finnish are official languages.
>
> After some discussion, we decided to take the big step: the names[/color]
were[color=blue]
> moved out specific name tables. For instance the countries table
> would get a subtable countrynames with the key (countrycode,[/color]
languageid).[color=blue]
> For simplicity we did keep a name column in the main table, so we
> can use that as a fall back if there is no name in the current[/color]
language[color=blue]
> in the name table.
>
> Adding an extra column may be easy for the first language you[/color]
support,[color=blue]
> but if you add specific tables, you have the infrastructre built for
> your third, fourth language etc.
>[color=green]
> > Another thing, if I alter my existing database into UTF-8 now, will[/color][/color]
it[color=blue][color=green]
> > affect the original data (ie. English).[/color]
>
> There is no support for storing data in SQL Server as UTF-8. To store
> Unicode data, use UCS-2. (The same as UTF-16, but SQL 2000 does not
> support surrogates.) That is the nchar/nvarchar datatypes. Note that
> depending on which languages you plan to support, you can still make[/color]
it with[color=blue]
> char/varchar.
>
> --
> Erland Sommarskog, SQL Server MVP,
esquel@sommarskog.se
>
> Books Online for SQL Server SP3 at
>
http://www.microsoft.com/sql/techinf...2000/books.asp[/color]
