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

[Asgeir Frimannsson]

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