(SQL Server 2000, SP2)

Hello, all!

My company is in the process of internationalizing our products, including
the tables in the SQL Server database. Basically, we'll switch to UNICODE
for all the affected string fields. Obviously, there are a number of stored
procedure, trigger, and VIEW implications therein.

However, we want to accommodate multiple concurrent languages. That is, we
want to support many languages simultaneously whereas before we just
supported a single language (US-English).

I've got a few ideas about how we might approach this, but none of them are
overwhelming favorites. I was hoping that there might be some suggested
best-practices in this area, or some useful online (or otherwise) references
that talk about converting a database to support internationalization.

Thanks for any help you can provide! :-)

Report this post to a moderator

John,

Here's one place to look:
http://msdn.microsoft.com/library/d...lfeaturesinsqls
erver2000.asp

Also, note that to be *really* nationalized, you have to consider the collation the data is
stored in. If there are only people from one country using each install, then the customers can
quite simply select the desired collation. It is more difficult if people from different
countries will use the same data. Essentially, you would need to add COLLATE to the queries to
get the query to be processed with the end-users collation instead of the collation that the
data is stored in.

--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=...ublic.sqlserver


"John Peterson" <johnp@azstarnet.com> wrote in message news:#saQpCibCHA.1652@tkmsftngp09...
> (SQL Server 2000, SP2)
>
> Hello, all!
>
> My company is in the process of internationalizing our products, including
> the tables in the SQL Server database. Basically, we'll switch to UNICODE
> for all the affected string fields. Obviously, there are a number of stored
> procedure, trigger, and VIEW implications therein.
>
> However, we want to accommodate multiple concurrent languages. That is, we
> want to support many languages simultaneously whereas before we just
> supported a single language (US-English).
>
> I've got a few ideas about how we might approach this, but none of them are
> overwhelming favorites. I was hoping that there might be some suggested
> best-practices in this area, or some useful online (or otherwise) references
> that talk about converting a database to support internationalization.
>
> Thanks for any help you can provide! :-)
>
>

Report this post to a moderator

Thanks, Tibor!

I haven't really started my research on this yet, so this should help point
me in the right direction. :-)

Out of curiosity, is there kind of a default collation that can be used, and
then some other identifier (perhaps a field value) that can be leveraged to
indicate what language the data is in? Or, must the collation "match" the
language?

Thanks again!


"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@cornerstone.se>
wrote in message news:Ou8EcjibCHA.1764@tkmsftngp12...
> John,
>
> Here's one place to look:
>
http://msdn.microsoft.com/library/d...-us/dnsql2k/htm
l/ intlfeaturesinsqls

> erver2000.asp
>
> Also, note that to be *really* nationalized, you have to consider the
collation the data is
> stored in. If there are only people from one country using each install,
then the customers can
> quite simply select the desired collation. It is more difficult if people
from different
> countries will use the same data. Essentially, you would need to add
COLLATE to the queries to
> get the query to be processed with the end-users collation instead of the
collation that the
> data is stored in.
>
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
>
>
> "John Peterson" <johnp@azstarnet.com> wrote in message
news:#saQpCibCHA.1652@tkmsftngp09...
> > (SQL Server 2000, SP2)
> >
> > Hello, all!
> >
> > My company is in the process of internationalizing our products,
including
> > the tables in the SQL Server database. Basically, we'll switch to
UNICODE
> > for all the affected string fields. Obviously, there are a number of
stored
> > procedure, trigger, and VIEW implications therein.
> >
> > However, we want to accommodate multiple concurrent languages. That is,
we
> > want to support many languages simultaneously whereas before we just
> > supported a single language (US-English).
> >
> > I've got a few ideas about how we might approach this, but none of them
are
> > overwhelming favorites. I was hoping that there might be some suggested
> > best-practices in this area, or some useful online (or otherwise)
references
> > that talk about converting a database to support internationalization.
> >
> > Thanks for any help you can provide! :-)
> >
> >
>
>

Report this post to a moderator

You're welcome, John :-)


> Out of curiosity, is there kind of a default collation that can be used, and
> then some other identifier (perhaps a field value) that can be leveraged to
> indicate what language the data is in? Or, must the collation "match" the
> language?

I'm afraid that I don't follow you here. That might mean that the answer is "no" or that I'm
particularly dense today :-). If you post back with more details or with other words I might
understand more what you are looking for...

--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=...ublic.sqlserver


"John Peterson" <johnp@azstarnet.com> wrote in message news:u8lCXlibCHA.2220@tkmsftngp10...
> Thanks, Tibor!
>
> I haven't really started my research on this yet, so this should help point
> me in the right direction. :-)
>
> Out of curiosity, is there kind of a default collation that can be used, and
> then some other identifier (perhaps a field value) that can be leveraged to
> indicate what language the data is in? Or, must the collation "match" the
> language?
>
> Thanks again!
>
>
> "Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@cornerstone.se>
> wrote in message news:Ou8EcjibCHA.1764@tkmsftngp12...
> > John,
> >
> > Here's one place to look:
> >
> http://msdn.microsoft.com/library/d...-us/dnsql2k/htm
> l/ intlfeaturesinsqls
> > erver2000.asp
> >
> > Also, note that to be *really* nationalized, you have to consider the
> collation the data is
> > stored in. If there are only people from one country using each install,
> then the customers can
> > quite simply select the desired collation. It is more difficult if people
> from different
> > countries will use the same data. Essentially, you would need to add
> COLLATE to the queries to
> > get the query to be processed with the end-users collation instead of the
> collation that the
> > data is stored in.
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > Archive at:
> http://groups.google.com/groups?oi=...ublic.sqlserver
> >
> >
> > "John Peterson" <johnp@azstarnet.com> wrote in message
> news:#saQpCibCHA.1652@tkmsftngp09...
> > > (SQL Server 2000, SP2)
> > >
> > > Hello, all!
> > >
> > > My company is in the process of internationalizing our products,
> including
> > > the tables in the SQL Server database. Basically, we'll switch to
> UNICODE
> > > for all the affected string fields. Obviously, there are a number of
> stored
> > > procedure, trigger, and VIEW implications therein.
> > >
> > > However, we want to accommodate multiple concurrent languages. That is,
> we

> > > want to support many languages simultaneously whereas before we just
> > > supported a single language (US-English).
> > >
> > > I've got a few ideas about how we might approach this, but none of them
> are
> > > overwhelming favorites. I was hoping that there might be some suggested
> > > best-practices in this area, or some useful online (or otherwise)
> references
> > > that talk about converting a database to support internationalization.
> > >
> > > Thanks for any help you can provide! :-)
> > >
> > >
> >
> >
>
>

Report this post to a moderator