Reply To: I18n approach: Language in URL

Splash Forums Rewrite Users I18n approach: Language in URL Reply To: I18n approach: Language in URL



Hi Christian,

thank you very much for your response.


You are absolutely right. Adding the f:param and everything works. Sometimes the obvious is before us and we can´t see it 😉 Thank you.

Nonetheless this will result in lots of work and even more duplicate code if I have to add f:param to every h:link. I wonder if there is a centralized programmtic approach:

a) Normally I would use a servlet filter to enrich the request parameters via “lang”. But FacesContext is not available in a filter.

b) Of course, I can build my own JSF custom component that extends h:link and already includes f:param “lang”. Maybe this is the best approach.

c) Any other ideas?


The reason why I am using “FacesContext.getCurrentInstance().getViewRoot().getLocale().getLanguage()” is because API says “it returns the language of the Locale used in localizing the response being created for this view”. That´s exactly what I want.

Sadly, if I am doing

return cb.addRule(Join.path("/{lang}" + path).to(to).withInboundCorrection()).where("lang").bindsTo("facesContext.viewRoot.locale.language")).after(PhaseId.RESTORE_VIEW));

it results in the following exception:

javax.el.PropertyNotWritableException: The class 'java.util.Locale' does not have a writable property 'language'.
	at javax.el.BeanELResolver.setValue(

That´s why I wrapped the call into “CurrentViewLanguage”. setLanguage() must be there and is read-only. So, yes, it´s weird, but a working solution without side effects ….. Hmm, maybe I should leave the method body empty. Good point, thx.


Greetings from Munich

  • This reply was modified 5 years, 4 months ago by  zebhed.