Reputation: 77
I am working on one web app project which supports multiple languages.
I am using Spring framework. Spring has option to support multiple language by adding the following beans in dispatcher servlet.
<bean id="localeResolver"
class="org.springframework.web.servlet.i18n.SessionLocaleResolver">
<property name="defaultLocale" value="en" />
</bean>
<mvc:interceptors>
<mvc:interceptor>
<mvc:mapping path="/**" />
<bean class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor">
<property name="paramName" value="language" />
</bean>
</mvc:interceptor>
</mvc:interceptors>
<!-- Register the messages.properties -->
<bean id="messageSource"
class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
<property name="basename" value="classpath:messages" />
<property name="defaultEncoding" value="UTF-8" />
</bean>
The localization works only if I pass language parameter in every URL.
Is there any option to set locale based on the client's browser language?
Upvotes: 2
Views: 5732
Reputation: 20135
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.
See my sample application that demonstrates this approach. Use a browser extension such as Postman for Chrome to manipulate the value of the Accept-Language
header. The sample supports English, French, German and Spanish so passing en-US
, fr-FR
, de-DE
and es-ES
will show localized messages in each of these languages respectively.
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.
Upvotes: 6