james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: i18n
Date Tue, 05 Jun 2007 20:00:28 GMT
On 6/5/07, Stefano Bagnara <apache@bago.org> wrote:
> robert burrell donkin ha scritto:
> > On 6/4/07, Danny Angus <danny@apache.org> wrote:
> >> Robert wrote:

<snip>

> >> ... 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-doodles/i18n/DisplayText.png
> >
> >
> > opinions?
>
> I would have probably chose a different pattern:
>
> LocalizationFactory
> - createLocalizationService(locale:Locale)
>      |
>   creates
>      |
>      V
> LocalizationService
> - getMessage(key:String)

i started off with the design too but this means using weakly typed calls

> This way you can place the LocalizationService in session and avoid
> generating new objects for each string to be localized.

IMHO it's a classic trade-off: i prefer strongly typed APIs and am
willing to worry about pooling objects when necessary later

> Btw I'm not a big fan of localization of internet protocols: I never
> found an HTTP server returning "404 Non trovato" instead of "404 not
> found" ;-)
>
> I think that l8n is really a low priority for our imap server
> (compliance, stability, compatibility, performance, extensibility are
> some of high priorities), but if you like to work on this and you find a
> clean way to handle l8n then this is welcome anyway.

it is not a direct priority but IMHO a clean, clear API enables the
rest to be achieve more efficiently

sometimes thinking about issues such as i18n can give insights into
elegant ways to solve other design dilemmas

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message