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

Pete Muir pmuir at redhat.com
Wed Apr 7 05:45:33 EDT 2010


This is an interesting idea!

On 16 Mar 2010, at 05:31, Asgeir Frimannsson wrote:

> Hi all,
> 
> A slightly late reply, but my 5 cents:
> 
> It would be really nice if Seam 3 could support some sort of type-safety in the messages format, rather than having to manually maintain a java .properties template. 
> 
> GWT is a great example of how this could be done [1], where an interface extending Messages can be annotated with all the relevant information, including default source-language values. An quick example:
> 
> @DefaultLocale("en_US")
> @Generate(format = "com.google.gwt.i18n.rebind.format.PropertiesFormat")
> public interface MyMessages extends Messages {
> 
>   @DefaultMessage("{0} users online")
>   @PluralText({"one", "One user online"})
>   @PluralText({"none", "No users online"})
>   @Description("Title of the minimized users panel")
>   String nUsersOnline(@PluralCount int numUsers);
> 
>   @DefaultMessage("I can ommit @Optional items here")
>   String anExampleUsingOptional(@Optional int n);
> 
>   @DefaultMessage("However here I would get an exception as n is not @Optional")
>   String aFailingExample(int n);
> }
> 
> The source-language properties file can then simply be generated from this type-safe and refactor-friendly model, and there is no need to manually maintain a properties file. At runtime, the target-language MyMessages.properties file would be used if available, and it would fallback to using @DefaultMessage values otherwise.
> 
> cheers,
> asgeir
> 
> [1] http://code.google.com/webtoolkit/doc/latest/DevGuideI18n.html
> 
> 
> ----- "Ken Finnigan" <ken.finnigan at sorstech.com> 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
>>     - Pushing the default locale to JSF and other view layers based
>> on 
>> the system locale
>>     - Modify the message interpolation mechanism to remove the use of
>> 
>> #{} and be consistent with Java by using simply {}
>>     - 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.
>> 
>> Any comments on the above are most welcome, as well as any thoughts 
>> about what else would be useful to have within this module.
>> 
>> Regards
>> Ken
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev




More information about the seam-dev mailing list