Database-level support is one aspect (AFAIK PostgreSQL UNICODE does
solve the issue). Another is multilingual data entry.
Here is my elaborations on this (in the past I've done preliminary
research for a project that never materialized ... so I never came up
with a full solution). I guess you should start by logically
splitting your data into "configuration" and "entered by user". I
don't think you can realistically serve the same piece of user-
entered data in multiple languages (who is going to translate it?).
However "configuration" data can be internationalized ... How? I have
a few ideas, but I don't have a coherent solution yet and would like
to hear other people's experiences.
Andrus
On Jun 23, 2005, at 10:26 AM, Gentry, Michael ((Contractor)) wrote:
> This is probably database dependent. For example, with PostgreSQL,
> you
> can have ASCII or UNICODE databases. When you create your DB, you
> need
> to initialize it to the one you want. If you use PostgreSQL, do a \l
> inside psql and see what the encoding is on your DB. If using another
> server, check to see if it supports it and how to set it up, etc.
>
>
> -----Original Message-----
> From: Kevin Menard [mailto:kmenar..ervprise.com]
> Sent: Thursday, June 23, 2005 9:29 AM
> To: cayenne-use..bjectstyle.org
> Subject: i18n
>
>
> Hey all,
>
> Sorry for the bit OT post, as this isn't particular to Cayenne.
> Basically, I have a website that I want to internationalize.
> Tapestry's i18n support has really made this easy for static pages.
> However, for content being pulled from the DB with Cayenne, I'm not
> sure what the best approach is. Could someone that's run into this
> before please enlighten me with a robust design? Everything I've
> come up with seems to be less than ideal.
>
> Thanks,
> Kevin
>
>
This archive was generated by hypermail 2.0.0 : Thu Jun 23 2005 - 10:51:28 EDT