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(a)sorstech.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev