Eric,
You have touched upon something I hadn't yet considered, and that is correctly
displaying the text no matter what language is was entered. I know this is
also something I will have to do.
My question stemmed from the data being translated into multiple languages and
how this is accomplished. It looks like a different table must be created for
every translation. This brings up an interesting challenge in the creation of
the data, and its update/storage into the database.
Thanks for your reply. The information you conveyed is definitely good stuff.
Jim Garrett
>
> From: "Broyles, Eric" <ebroyles@xxxxxxx>
> Date: 2004/10/18 Mon PM 03:42:58 EDT
> To: <users@xxxxxxxxxx>
> Subject: RE: [cinjug-users] Localization and I18N
>
> Jim,
>
> I am working on a project right now with this same requirement. I'm
> tackling this issue as we speak (and have been for nearly a week now).
> My application requires that users can input data in any language and
> then that data is stored in the database and must be displayed
> (correctly) on a web page. I've made some progress, but this has proven
> to be a greater challenge than I expected. I don't have a full solution
> yet, but here's what I've done thus far.
>
> Set the charset to UTF-8 on the web page using the
> ServletResponse.setContentType() method. Somehow you have to get the
> data into the database in UTF-8 encoded format. I am using SQL Server
> 2000 as the database, which supports Unicode data internally, however it
> uses UCS-2/UTF-16 encoding. I have found that if I use a regular column
> type (i.e. not the special Unicode type) in the database, and enter the
> data from a web form encoded in UTF-8, it will usually display
> correctly. I've encountered some problems with Simplified and
> Traditional Chinese, but I have had success with Spanish, Thai, Korean,
> and Japanese.
>
> The key when processing the form is to take the text value from the web
> form and call getBytes("utf-8") on it to get a byte array encoded in
> UTF-8. Then create a new String from the resulting byte array and save
> that string to the database. Then when displaying the string from the
> database to the web, make sure the page encoding is set to UTF-8 (as
> mentioned above).
>
> Calling getBytes("utf-8") on the form value seems odd given that the
> page encoding is set to UTF-8. This is the step I wasn't doing until
> today because it just didn't seem right. But sure enough, it seems to
> work. Maybe it has something to do with Java storing Strings internally
> in Unicode.
>
> I hope my rambling proves useful to you. If I learn anything more, I'll
> pass it along. I'd appreciate any bits of knowledge you pick up along
> the way as well. :)
>
> Thanks,
> 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
>
>
> ---------
> 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
>
>
|