I'm here Helen!

There's two ways to approach this -- let's assume your "key" to identify a
piece of text is Chapter.

create table book_text (
chapter_id integer not null primary key,
english character(30),
french character(50) character set latin1,
japanese character(50) character set sjis, ... )

Note: Languages added / dropped by changing columns. Application code to
access table may need change
each time a language is added / dropped. Note that column widths must vary
to allow for growth in
text for a translation.

Alternate:

create table book_text (
chapter_id integer not null,
language_id integer not null,
text character (50) character set unicode_fss, /*
Alternate 2b: character set none */
primary key (chapter_id, language_id));

(With appropriate tables to track language_id & chapter_id & FK references)

InterBase will automatically transliterate from your application character
set to the storage character set.
OR
If you use character set none, InterBase simply stores & fetches what you
give it - it does not try to change
byte values between different applications. eg: you have to manage text
transliteration.

I like the 2nd approach better. That's how the translation database for
InterBase messages & error text is
set up. (Didn't know there was a database of InterBase translations??? Yet
another project that was setup
in engineering and never was funded for hiring translators. When I left we
had about 75% of a Japanese
translation & 50% each of French & German in the database - Many messages
from the 3.x & 4.x timeframe, and
no new 5.x or 6.x messages having any translations.).

Dave

-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Wednesday, March 29, 2000 4:00 AM
To: ibdi@onelist.com
Subject: [IBDI] Character sets - for the IBDH database


From: Helen Borrie <helebor@...>

Help All!

I'm storing all of the stuff for the IBDH in an SQL Server database....

JUST KIDDING!

...in an IB database. All was sweet until it hit me like a rock that I
need to store text of different character sets in the one database, nay,
within the same tables. The database is structured on the OpenDoc XML tree
- at the top level is the SET (name BookSET) beneath which is BOOK - one
row for each language.

We go down levels, storing DIVISION, PART, CHAPTER and several different
kinds of components, with several language-specific text columns along the
way.

Is there a magic wand solution for this, other than storing the
language-specific content in lookup tables in separate databases? I hope
so...

(Boy, this is a challenge!)

Dave Schnepper, are you out there?

Helen
http://www.interbase2000.org
___________________________________________________
"Ask not what your free, open-source database can do for you,
but what you can do for your free, open-source database."
(J.F.K.)

------------------------------------------------------------------------
LOW RATE, NO WAIT!
Get a NextCard Visa, in 30 seconds! Get rates
as low as 2.9% Intro or 9.9% Fixed APR and no hidden fees.
Learn more at:
http://click.egroups.com/1/937/3/_/679568/_/954331012/
------------------------------------------------------------------------

Community email addresses:
Post message: IBDI@onelist.com
Subscribe: IBDI-subscribe@onelist.com
Unsubscribe: IBDI-unsubscribe@onelist.com
List owner: IBDI-owner@onelist.com

Shortcut URL to this page:
http://www.onelist.com/community/IBDI