Jim,
You're correct in your assumption. Localization of database data is almost
always done with either (A) different tables for different languages or (B)
different databases for different languages. I've seen both approaches.
Approach A seems to be the one that causes the least amount of headaches,
although it's not much more fun.
If you're dealing with data that changes a LOT, this is going to be a nightmare
for you. If, however, you're dealing with almost purely static content or stuff
that changes very infrequently, I imagine it won't be too bad.
Another approach is to develop some sort of translation web service that works
similarly to Babblefish. For all I know Babblefish may already provide a web
service. There's probably a handful of other, lesser-known fee-based web
services that do the same thing. They essentially give you a "best guess"
translation. Not a perfect solution, but it might work if your requirements
allow this.
-Shane
-----Original Message-----
From: jim_garrett@xxxxxxxx
Sent: Oct 18, 2004 12:11 PM
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
|