Re: Yet another I18N approach

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

#23473

mannyhan1968
Member

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,

Harald