Did a dynamic five language site (Japanese, Korean, Cantonese, Mandarin,
English) using access for prototyping and oracle for publishing. The
language code is simple, note that you can only specify one charset
per page:
<meta http-equiv='content-type' content='text/html;charset=#bnkCharSet#'>
If you're using explorer and don't have support for that locale it will
automatically try to download a font set for you, with Netscape you've
to manually install the fonts.
A list of common charsets can be found at:
http://www.w3.org/International/O-charset-list.html
The database and interacting with it via forms was a little more tricky.
After going through a few file formats we finally had the translators
use notepad to translate into the different languages because double-byte
and unicode characters were causing problems and losing certain characters
in insert and update statements. They would save the files as text or html
and we could simply copy paste them into the fields. Use the extended ascii
set. Oracle has some nifty language support I would check out
technet.oracle.com for more info, in access we used memo fields to store
the html and translated content. On an English machine all except the html
tags look garbled when you open the db but once you query it and throw it
into a page with the above meta tag, the browser interprets the content and
all's displayed fine. I have not tried this but I'm pretty sure if we had
a Chinese version of windows/access we would see Chinese characters in
access as well. Using ie goto ntt.co.jp and refuse to install the fonts or
chose western European from the encoding menu under view, that's what the
data looks like inside the field and this is what I'm referring to as
'garbled'. One problem was updating the db from a textarea. The admins for
the site were using English machines and were to be responsible for
maintaining the site, but we had localized the admin pages where the
database was to be updated using the charset code above so that when you
copied and pasted the (garbled) text in to the textareas you could see
the localized content and do some visual formatting if need be. Bad choice,
since the page was 'labeled' as Japanese when you inserted the textarea
content into the db it would come back out as Unicode. Lots of u1234, u2345
stuff. Changed the the charset back to English and all was fine for a while.
After a myriad of different problems in different languages similar to the
above I switched from textareas to a modified version of activEdit
(cfdev.com) to update the content. For some reason this dandy tag would
always update the db in English (I'm assuming because it uses windows
components), hence here's a solution for managing and translating localized
content with the least amount of headache.
-Setup acitvEdit instead of using textareas and specify the local charset
at the top of the page.
-Feed the panel formatted (tables, images, vs.) ENGLISH version of the
content. All the charsets that I used had English fonts embedded so this
was possible.
-Have the translators TYPE into the panel over the English instead of
sending you some unrecognizable file which you have to sift through.
This is actually the most difficult part and a huge pia, because you
have to put in an incredible amount of effort to get the translators
to use your admin panel rather than his/her copy of word 2.0. I'll
explain below. This method actually solves a major organizational
problem. How do you know where one sentence ends and the other starts
if you don't know Chinese? If you end up having to send out text only
to get translated at least make sure you leave breadcrumbs behind)
-Update the db from activEdit, and serve it back out from the frontend
making sure that you specify the charset.
Well that's basically it. Except for one minor problem... the translators.
I can't emphasize the importance of having them TYPE over the English
content. Worst case copy and paste from NOTEPAD sentence by sentence,
but don't let them know that upfront because more often than necessary
they ended up copying and pasting from word documents or other similar
fancy word processors. With activEdit that was a huge problem as word
retains a whole bunch of utterly useless data along with the content.
Weird div tags and incomprehensible font declarations really messes up
your visual formatting not to mention that it usually spurts out ie only
code. Export a localized document as html from word and you'll see what
I mean.
Did I mention that Arabic reads right to left? Think about it. ];-)
Hope that helps, good luck and please let me know if you're in need
of a telecommuter.
Benekli23:50P21I2001
<->Has anybody successfully built a multi-language dynamic website - where the
<->page data, etc, is kept within the database? How did you display the
<->languages on screen, in the database, etc..
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
