On 6/5/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin ha scritto:
> On 6/4/07, Danny Angus <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to