On 6/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>
>
> On 6/4/07, Danny Angus <[EMAIL PROTECTED]> wrote:
> > Robert wrote:
> >
> > > the IMAP protocol returns a lot of messages which must be
> appropriate
> > > for display on the client. ATM these messages are just hard-coded
> > > strings. it would probably be good to be able to reasonably easily
> > > localise them based on the user.
> > >
> > > opinions?
> >
> > I agree, I googled briefly for anything that might help us
> here and I
> > got this, dated June 2007, so fairly current! :-)
> >
> > "Internet Message Access Protocol Internationalization"
> > http://tools.ietf.org/html/draft-ietf-imapext-i18n-01
>
> great!
>
> (i bow to your superior google-foo)
>
> > ... but it fails to meet your requirement because it has the
> > translations on the server.
>
> sorry for misleading you: IMAP protocol specification means that
> localisation on the server is the only reasonable approach. so, i was
> thinking about doing just that.
>
> it probably makes sense to replace the message strings in the james
> IMAP API with a interface that supports i18n. should probably factor
> create into a factory. factory method should take a string key so that
> it's easy to use the java i18n mechanism. unless any knows of a good
> reasons to do otherwise, might as well use standard Locale. something
> like:
>
> http://svn.apache.org/repos/asf/james/server/sandbox/design-do
odles/i18n/DisplayText.png
> opinions?
Take a look at http://www.icu-project.org/index.html. ICU4J is widely used
as it tends to be 1 or 2 major versions in front of what a JDK offers while
offering a stable target when supporting multiple JDK's.
thanks for the link - that project hadn't made it above my radar :-)
I'm not clear how you intend to determine a useful locale for the reader of
the message from the server side.
i left that bit out :-)
How would the target locale be obtained?
for clients supporting
http://tools.ietf.org/html/draft-ietf-imapext-i18n-01 this will be
negotiated with the client
for clients that do not support this then it would perhaps be possible
to store preferred locale in the user repository
so, seems best to separate the locale determination from the
localisation. the preferred locale for the session could be stored as
a ImapSession attribute and then used when required.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
