Re: [seam-dev] Seam 3 Internationalization & Localization module ideas / thoughts
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> 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