[seam-dev] Seam 3 Internationalization & Localization module ideas / thoughts

Pete Muir pmuir at redhat.com
Mon Feb 22 12:11:16 EST 2010


Ken, sounds like a great idea!

On 22 Feb 2010, at 13:35, Ken Finnigan wrote:

> Pete,
> 
> Thanks for the feedback.
> 
> In the design notes for the module on the wiki I have outlined some basic objectives.
> 
> I've also begun putting together some detailed notes on how it could be implemented as well. Would it be beneficial to commence development on parts of the module as a means of proving the theoretical design and prototyping more complex issues?  At various points I could then submit a patch to yourself and others of the completed work for review?
> 
> Ken
> 
> Sent from my iPhone
> 
> On 22 Feb 2010, at 11:20, Pete Muir <pmuir at redhat.com> wrote:
> 
>> 
>> On 17 Feb 2010, at 22:08, Ken Finnigan wrote:
>> 
>>> All,
>>> 
>>> I'm currently in the process of pulling together some thoughts and ideas
>>> as to what to include in the new i18n and l10n module within Seam 3.
>>> 
>>> Here are some initial ideas that have been put forward:
>>> 
>>>   - Remove all hard dependencies to JSF from within the module
>>>   - i18nable logging
>> 
>> Yes, also watch this space. There are some discussions about developing a i8ln logging library for JBoss AS which we can likely reuse.
>> 
>>>   - Pushing the default locale to JSF and other view layers based on
>>> the system locale
>> 
>> And make this configuration
>> 
>>>   - Modify the message interpolation mechanism to remove the use of
>>> #{} and be consistent with Java by using simply {}
>> 
>> Well, we should keep the ability to interpolate EL definitely. We should replace the use of #0 with {0} though.
>> 
>>>   - The ability for multiple view frameworks to co-exist with the
>>> appropriate messages being returned to the calling framework.  My
>>> initial thoughts on this are to convert the existing StatusMessages
>>> class into a conversational scoped bean which can be used by application
>>> code to create a message for display.  Then a view framework would
>>> create the mechanism to convert the StatusMessages content into messages
>>> appropriate to them.  With JSF this could be achieved by taking the
>>> existing FacesMessages class and injecting the StatusMessages instance
>>> (while retaining the extends) to retrieve the messages that are present
>>> and FacesMessages can be used by SeamPhaseListener as it is now.
>> 
>> I think the real challenge here is knowing which messages are for which framework.
>> 
>> Sounds good!
>> 
>> Pete




More information about the seam-dev mailing list