robert burrell donkin ha scritto:
> 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-doodles/i18n/DisplayText.png
>
>
> opinions?
I would have probably chose a different pattern:
LocalizationFactory
- createLocalizationService(locale:Locale)
|
creates
|
V
LocalizationService
- getMessage(key:String)
This way you can place the LocalizationService in session and avoid
generating new objects for each string to be localized.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
