You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Doug Hauge <do...@lithium.com> on 2007/08/17 20:53:54 UTC
T5: Tapestry message localization, java.util.Formatter vs. java.text.MessageFormat
Is there some reason Tapestry chose to use 'java.util.Formatter' style
formatting as opposed to 'java.text.MessageFormat' style? The latter
seems preferable for localization, primarily because it has the 'choice'
format type. We would like to use the 'java.text.MessageFormat' style
for our application, and are considering providing our own
implementation of the 'MessageFormatter' service, but the question
becomes how to use this formatting for only our messages. We have
considered decorating the 'ComponentMessagesSource' service, but this
would then apply to all component messages, including those for core
components, which have some text properties that use
'java.util.Formatter' style formatting. We could override these messages
as described in
http://wiki.apache.org/tapestry/Tapestry5HowToOverrideTheDefaultErrorMes
sageBanner, but that seems a bit brittle.
Does anyone else have any need to use 'java.text.MessageFormat' style
formatting, or are we the only ones? Do the solutions mentioned above
sound reasonable?
Thanks,
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Tapestry message localization, java.util.Formatter vs.
java.text.MessageFormat
Posted by jeffrey ai <jf...@gmail.com>.
One choice is to provide your own message binding by contribute a binding
source in your AppModule.java like below.
You could use any formatter you want in there.
---
public void contributeBindingSource( MappedConfiguration<String,
BindingFactory> configuration )
{
configuration.add( "mymsg", new MyMessageBindingFactoryImpl() );
}
---
Cheers,
Jeffrey Ai
Doug Hauge wrote:
>
> Is there some reason Tapestry chose to use 'java.util.Formatter' style
> formatting as opposed to 'java.text.MessageFormat' style? The latter
> seems preferable for localization, primarily because it has the 'choice'
> format type. We would like to use the 'java.text.MessageFormat' style
> for our application, and are considering providing our own
> implementation of the 'MessageFormatter' service, but the question
> becomes how to use this formatting for only our messages. We have
> considered decorating the 'ComponentMessagesSource' service, but this
> would then apply to all component messages, including those for core
> components, which have some text properties that use
> 'java.util.Formatter' style formatting. We could override these messages
> as described in
> http://wiki.apache.org/tapestry/Tapestry5HowToOverrideTheDefaultErrorMes
> sageBanner, but that seems a bit brittle.
>
> Does anyone else have any need to use 'java.text.MessageFormat' style
> formatting, or are we the only ones? Do the solutions mentioned above
> sound reasonable?
>
> Thanks,
> Doug
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/T5%3A-Tapestry-message-localization%2C-java.util.Formatter-vs.-java.text.MessageFormat-tf4287513.html#a14154551
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Tapestry message localization, java.util.Formatter vs. java.text.MessageFormat
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
Or you could create a new message binding prefix that uses
java.text.MessageFormat.
-Filip
Davor Hrg skrev:
> I've been playing with mesage catalog,
> I want to make an implementation that
> will load translations from database, and
> also creating components to allow adding
> translations while application is working
> (this made my life easier on projects where users,
> made translations on the fly while testing the app).
>
> ...
> ...
>
> however, relevant to your question, I've looked at the source,
> tapestry has it's own interface for formatter, so you can
> - decorate the service.
> - provide your own formatters,
> - look for escape chars to decide which formatter to use,
> - delegate to default impl where possible
> this way both implementations can live side by side.
>
> Davor Hrg
>
> On Aug 17, 2007 7:53 PM, Doug Hauge <do...@lithium.com> wrote:
>
>> Is there some reason Tapestry chose to use 'java.util.Formatter' style
>> formatting as opposed to 'java.text.MessageFormat' style? The latter
>> seems preferable for localization, primarily because it has the 'choice'
>> format type. We would like to use the 'java.text.MessageFormat' style
>> for our application, and are considering providing our own
>> implementation of the 'MessageFormatter' service, but the question
>> becomes how to use this formatting for only our messages. We have
>> considered decorating the 'ComponentMessagesSource' service, but this
>> would then apply to all component messages, including those for core
>> components, which have some text properties that use
>> 'java.util.Formatter' style formatting. We could override these messages
>> as described in
>> http://wiki.apache.org/tapestry/Tapestry5HowToOverrideTheDefaultErrorMes
>> sageBanner, but that seems a bit brittle.
>>
>> Does anyone else have any need to use 'java.text.MessageFormat' style
>> formatting, or are we the only ones? Do the solutions mentioned above
>> sound reasonable?
>>
>> Thanks,
>> Doug
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Tapestry message localization, java.util.Formatter vs. java.text.MessageFormat
Posted by Davor Hrg <hr...@gmail.com>.
I've been playing with mesage catalog,
I want to make an implementation that
will load translations from database, and
also creating components to allow adding
translations while application is working
(this made my life easier on projects where users,
made translations on the fly while testing the app).
...
...
however, relevant to your question, I've looked at the source,
tapestry has it's own interface for formatter, so you can
- decorate the service.
- provide your own formatters,
- look for escape chars to decide which formatter to use,
- delegate to default impl where possible
this way both implementations can live side by side.
Davor Hrg
On Aug 17, 2007 7:53 PM, Doug Hauge <do...@lithium.com> wrote:
> Is there some reason Tapestry chose to use 'java.util.Formatter' style
> formatting as opposed to 'java.text.MessageFormat' style? The latter
> seems preferable for localization, primarily because it has the 'choice'
> format type. We would like to use the 'java.text.MessageFormat' style
> for our application, and are considering providing our own
> implementation of the 'MessageFormatter' service, but the question
> becomes how to use this formatting for only our messages. We have
> considered decorating the 'ComponentMessagesSource' service, but this
> would then apply to all component messages, including those for core
> components, which have some text properties that use
> 'java.util.Formatter' style formatting. We could override these messages
> as described in
> http://wiki.apache.org/tapestry/Tapestry5HowToOverrideTheDefaultErrorMes
> sageBanner, but that seems a bit brittle.
>
> Does anyone else have any need to use 'java.text.MessageFormat' style
> formatting, or are we the only ones? Do the solutions mentioned above
> sound reasonable?
>
> Thanks,
> Doug
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>