ResourceBundleThemeSource and LocaleChangeInterceptor

[memento]

Hello specialists,

I have a problem using Spring MVC ResourceBundleThemeSource and the LocaleChangeInterceptor.

I configured theme support and locale support in my servlet context the following way:

<bean
    id="themeSource"
    class="org.springframework.ui.context.support.ResourceBundleThemeSource"
    p:basenamePrefix="theme."
  /> 
  
  <bean
    id="themeResolver"
    class="org.springframework.web.servlet.theme.SessionThemeResolver"
    p:defaultThemeName="cool"
  />
  
  <bean
    id="themeChangeInterceptor"
    class="org.springframework.web.servlet.theme.ThemeChangeInterceptor"
    p:paramName="theme"
  />
  
  <bean
    id="localeResolver"
    class="org.springframework.web.servlet.i18n.SessionLocaleResolver"
  />

  <bean
    id="localeChangeInterceptor"
    class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor"
    p:paramName="locale"
  />

  <bean
    class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
    <property name="interceptors">
      <list>        
        <ref bean="localeChangeInterceptor" />
        <ref bean="themeChangeInterceptor" />
      </list>
    </property>
  </bean>

I defined two properties files containing the localized "cool"-theme properties:
cool.properties
cool_de.properties

Use-case:
Calling URL in browser with parameter "locale=en" that forwards web request to an annotated controller.

Actual behavior:
HTML rendered the German theme properties (cool_de.properties).

Expected behavior:
HTML rendered the default theme properties (cool.properties).


I think, that there is maybe a problem with the cache used by the ThemeSource but I am not sure about this.

Does one of you have a similar setup and got this one running?

[Marten Deinum]

And why would the theme change if you change the language?! Locale and Theme are 2 different things.

[memento]

Hello Marten,

maybe my previous post was not that clear. Sorry.

I do not want to switch the theme! Just the "i18n" of the current theme should switch.

The Spring documentation in "13.7.2. Defining themes" says:

Note that the ResourceBundleThemeSource uses the standard Java resource bundle loading mechanism, allowing for full internationalization of themes. For instance, we could have a /WEB-INF/classes/cool_nl.properties that references a special background image, e.g. with Dutch text on it.

In my case I have a German localization of the theme "cool_de.properties" (instead of a Dutch one in your example).
I expected that when switching the locale via LocaleChangeInterceptor the corresponding theme localization should be used (as it is with the standard resource messages). If no such localized theme properties file is found, the default one should be used.

The file cool_en.properties does not exist in my case, so "cool.properties" should be taken as fall-back for all other locales then "de".

This is where the problem arise, because the German "cool_de.properties" is always taken as the fallback, not the "cool.properties".

[Marten Deinum]

Then again why do you expect the theming infrastructure to change the language!!! Your configuration contains the theming configuration and a half backed I18N configuration. They both are configured in almost the same way BUT they use different infrastructure beans and solve a different problem.

Theming
- ResouceBundleThemeSource
- ThemeChangeInterceptor
- ThemeResolver

I18N (or messaging!!!)
- ResourceBundleMessageSource
- LocaleChangeInterceptor
- LocaleResolver

So again a ThemeSource is only for THEMING not I18N, messages are resolved by configuring a MessageSource (which is quite clearly explained in the I18N section of the reference guide).

[memento]

Marten,

thank you again for your reply.

At first the rest of my "half backed I18N configuration".

<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource"
      p:basename="/WEB-INF/i18n/messages"
      p:fallbackToSystemLocale="false"
      p:defaultEncoding="UTF-8"/>

Now I'm confused:

...a ThemeSource is only for THEMING not I18N...

vs.

Note that the ResourceBundleThemeSource uses the standard Java resource bundle loading mechanism, allowing for full internationalization of themes. For instance, we could have a /WEB-INF/classes/cool_nl.properties that references a special background image, e.g. with Dutch text on it.

What I simply want to switch is the background image for another language but the same theme. This is not an i18n message resource issue, because the background-image decision depends on the theme selected. As the Spring reference says this should be possible (2nd quote).

Is it possible to switch the i18n of a theme during runtime?
If yes, how could this be triggered (if changing the locale via an URL parameter will not work)?
If no, the sentence from the Spring reference should be clarified.
http://static.springsource.org/sprin...olver-defining

Thanks in advance,
Martin.

[Marten Deinum]

THe text in the reference guide is completly clear imho. You just need to read the whole sentence.

a /WEB-INF/classes/cool_nl.properties that references a special background image, e.g. with Dutch text on it.

So it just references a different image.

In your url you are using "locale=en" which is tied to the LocaleChangeInterceptor NOT the ThemeChangeInterceptor. If you want to switch the theme use "theme=en" or whatever language you want to change to.

[memento]

Thanks Marten,

now I'm on your side.
As you said there is no connection between locale and theme.

I misinterpreted that point

...the ResourceBundleThemeSource uses the standard Java resource bundle loading mechanism...

by assuming that there is sth. like a fall-back behavior for fetching the "locale-matching message bundle" for themes:

• theme_de_DE.properties
• theme_de.properties
• theme.properties

What solved my issue was to define specific i18n theme properties files and call them additionally when doing a locale switch via parameter:
cool_de.properties
cool_en.properties

/myapp/page?locale=de&theme=cool_de
/myapp/page?locale=en&theme=cool_en
/myapp/page?locale=fr&theme=cool_en (use English theme as fallback for not supported languages)

To add a completely new theme I have to add two i18n properties files, like:
supercool_de.properties
supercool_en.properties

In conclusion: I would be a cool feature to connect both Interceptors and support fall-back behavior of themes if a specific i18n version does not exist.

Thank you Marten for this excellent support!
Best regards from Stuttgart, Germany,
Martin.

[edwin.chiu]

Thanks Marten,

now I'm on your side.
As you said there is no connection between locale and theme.

I misinterpreted that point

by assuming that there is sth. like a fall-back behavior for fetching the "locale-matching message bundle" for themes:

• theme_de_DE.properties
• theme_de.properties
• theme.properties

What solved my issue was to define specific i18n theme properties files and call them additionally when doing a locale switch via parameter:
cool_de.properties
cool_en.properties

/myapp/page?locale=de&theme=cool_de
/myapp/page?locale=en&theme=cool_en
/myapp/page?locale=fr&theme=cool_en (use English theme as fallback for not supported languages)

To add a completely new theme I have to add two i18n properties files, like:
supercool_de.properties
supercool_en.properties

In conclusion: I would be a cool feature to connect both Interceptors and support fall-back behavior of themes if a specific i18n version does not exist.

Thank you Marten for this excellent support!
Best regards from Stuttgart, Germany,
Martin.

Hi Martin,

Have you resolved your issue? I have a similar scenario. Can you share your implementation or setting here?

Thanks
Edwin