Jim,
I just realized I forgot to provide you any details on how I've setup my
database. The application is a document repository that has files stored on
the file system and the metadata in the database. Until now this has been a
purely English application. Each file (called a Resource by the application)
can be classified against multiple lists of criteria, including type, industry,
zone, product, analyst and competitor. Each of these is contained in the
database in a separate table.
To internationalize this, I added a language field to each table. The language
field is a char type of length 2 and it simply stores the ISO language code
(e.g. en, es, it, de, pt, ja). Queries call
getRequest().getLocale().getLanguage() (through helper methods, of course) and
return only results that match the user's preferred language (either as set in
their browser or in a preference setting in the application).
Here is an abbreviated table scheme for the Resource:
ID (primary key)
Title
Description
Keywords
Language
The tables for type, industry, zone, etc. look like this:
ID (primary key)
MapId (I'll explain this in a minute)
Name
Language
To map the relation between the industry and the Resource, I have another table:
ResourceID (foreign key)
IndustryID (foreign key)
In order to avoid having a table for each language, I added the MapId field to
the industry table. The MapId field simply contains the corresponding ID value
for the original language value.
For example, assume Industry started with the following English data:
ID MapId Name Language
1 1 Aerospace en
2 2 Automotive en
3 3 Electronics en
Then when I add a new language (say Spanish), I would add three new rows as
follows:
ID MapId Name Language
4 1 Aeroespacial es
5 2 Automotor es
6 3 Electrónica es
Where the MapId corresponds to the ID of the original language value (i.e.
since Aerospace has an ID of 1, the Spanish translation of Aerospace has a
MapID of 1).
Then in my queries where I used to use the ID field, I know use the MapID
field, which ensures that if I'm dealing with a Spanish Resource, I will see
the Spanish industries. This ensures that when making a mapping between the
ResourceID and the IndustryID I'm still using the primary key, so my
constraints are still intact. Perhaps a better solution (from a database
standpoint) would be to make the primary key of the Industry table be an
aggregate key composed of the ID and the language. But I like to keep my
primary keys simple (for better or for worse).
Thus far, this model has been working pretty well (though I'm not in production
yet, as there is other development still underway).
Eric
-----Original Message-----
From: jim_garrett@xxxxxxxx [mailto:jim_garrett@xxxxxxxx]
Sent: Monday, October 18, 2004 15:12
To: users@xxxxxxxxxx
Subject: [cinjug-users] Localization and I18N
I have a question I was hoping someone has done before and can provide some
guidance. I have a customer who wants to be able to display data fields and
their values in the correct language when using a web interface. I am very
familiar with how to localize the text fields, but the actual data, that comes
from the database, is a completely different animal. I would assume a
different table must exist for each language to be displayed; and I assume a
person would have to translate the text manually that is stored in the table.
Has anyone encountered this type of requirements before? If so how did you
solve this problem.
thanks in advance
Jim Garrett
---------
You may unsubscribe from this mailing list
by sending a blank email addressed to: users-unsubscribe@xxxxxxxxxx
--
Find additional help by sending a blank email
addressed to:
users-help@xxxxxxxxxx
|