Re: Yet another I18N approach

Splash Forums PrettyFaces Users Yet another I18N approach Re: Yet another I18N approach



Hi Christian,

thanks for your feedback, I’m glad to hear I wasn’t totally off the mark :-)

I rather like your idea with the pseudo-parameter, whatever the exact syntax might be, hopefully allowing for EL expressions.

Actually, I was using properties files in this quick proof-of-concept only, in a production system, I would store the text resources in a database and use a MessageBean to look up a resource, e.g. #{msg.lookup(lang, key)}, which can be simplified to #{msg[key]} if the MessageBean implements the Map interface and injects the LocaleBean to obtain the required language code.

So there’d have to be a way to set key in the EL expression from a path parameter defined in the Rewrite rule.

Your example mainly addresses the inbound direction. Actually, I was struggling with the outbound direction most of the time.

More precisely, I tried to use out-of-the-box Join rules with suitable conditions, but none of these attempts would work, apparently because Join rules are always birectional, whereas in my case

/en/Search --> /search.jsf with Locale.ENGLISH

/de/Suche --> /search.jsf with Locale.GERMAN

the mapping is not invertible, at least not without the additional Locale context information.

It seems a Join.path("/foo").to("/bar") rule always generates an unconditional outbound mapping of /bar to /foo, so in my scenario, the second rule would never catch, i.e. /search.jsf was always mapped to /en/Search in the outbound case.

That’s why I ended up with separate rules per direction and programmatic login in perform() methods.

It would be very helpful to have some kind of DSL shortcut for this scenario.

Best regards,