Reputation: 3627
There is quite a lot of documentation and guides that describe how to set up message localization in Spring framework. All of these that I found consider only changing messages (texts) on the webpages, but not page URLs. I would like to have completely different URLs for each locale. For example, http://example.org/en/welcome
would be used in the English version, but http://example.org/de/willkommen
would be used in the German version.
I assume that I will not be able to use class annotations to route the pages. I prefer storing the path–controller mapping in a file and loading it at runtime.
Could you tell me at least how to not hav
Upvotes: 1
Views: 322
Reputation: 314
Websites implement localization in one of two ways. The first approach involves automatically detecting the user locale by examining HTTP request headers (Accept-Language header in particular) and localizing site content for the user locale (if supported).
Spring MVC uses this approach by default. It uses the HttpServletRequest.getLocale method to determine the client locale and then loads localized messages from message sources. Note that the getLocale method returns a single Locale object whereas the Accept-Language header passed by the client could contain multiple languages (for example, Accept-Language: en-US, en-GB, en). In such cases, the getLocale method returns the Locale for the first matching language (en-US in the example above).
Therefore, if you wish your Spring MVC application to automatically detect the client locale and serve localized content, simply declare a ResourceBundleMessageSource bean in the application context. No other configuration is required.
The second approach used by websites is to always display content in a default language first and then allowing the user to change the locale (using a dropdown or links in the site header or footer). In such cases, the users may choose locales that are not consistent with the Accept-Language header sent by their browser. For example, the Accept-Language header may contain fr-CH while the user may select de-DE as the locale.
It is in such scenarios that LocaleChangeInterceptor and SessionLocaleResolver are required to use the user selection instead of the request headers. These components can intercept the user choice and save it temporarily for the duration of the session to localize the site content correctly.
and if you want more info refer this: Spring Localization without passing language in query string
Upvotes: 2