Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fallback locale other than the system locale in AbstractResourceBasedMessageSource #23977

Closed
sonOfRa opened this issue Nov 11, 2019 · 5 comments
Closed
Assignees
Milestone

Comments

@sonOfRa
Copy link

@sonOfRa sonOfRa commented Nov 11, 2019

It's already possible to fallback to the System Locale in, for example ResourceBundleMessageSource. In my current case, I don't want to fall back to the system locale, but I want to fallback to the same Default Locale that the rest of our system uses.

import org.springframework.context.MessageSource;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.support.MessageSourceAccessor;
import org.springframework.web.servlet.LocaleResolver;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
import org.springframework.web.servlet.i18n.SessionLocaleResolver;

import java.util.Locale;

@Configuration
public class ResourceConfig implements WebMvcConfigurer {

    private static final Locale DEFAULT_LOCALE = Locale.GERMAN;

    @Bean
    public LocaleResolver localeResolver() {
        SessionLocaleResolver slr = new SessionLocaleResolver();
        slr.setDefaultLocale(DEFAULT_LOCALE);
        return slr;
    }

    @Bean
    public MessageSourceAccessor messageSourceAccessor(MessageSource messageSource) {
        return new MessageSourceAccessor(messageSource, DEFAULT_LOCALE);
    }
}

I already attempted this through the MessageSourceAccessor Bean above, but that only seems to configure the default locale when invoking getMessage(...) without specifying an explicit locale manually.

So the behaviour I would expect is, that if I have message files messages_{en,de}.properties, and then a call like messageSourceAccessor.getMessage("message.key", Locale.FRENCH) would return the german string configured for message.key in messages_de.properties

@sonOfRa

This comment has been minimized.

Copy link
Author

@sonOfRa sonOfRa commented Nov 11, 2019

There's a workaround presented in this stackoverflow question: https://stackoverflow.com/questions/49561374/spring-messagesource-fallback-to-explicit-locale.

It kind of works, but I would expect the possibility of a static fallback locale to be working out of the box, instead of requiring a hacky workaround that has to use Exceptions for control flow.

@philwebb philwebb transferred this issue from spring-projects/spring-boot Nov 11, 2019
@philwebb

This comment has been minimized.

Copy link
Member

@philwebb philwebb commented Nov 11, 2019

It looks like we'd need some changes in Spring Framework to support this in Spring Boot. I've transferred the issue for that team to consider.

@rstoyanchev

This comment has been minimized.

Copy link
Contributor

@rstoyanchev rstoyanchev commented Nov 13, 2019

So we need setDefaultLocale(Locale) in AbstractResourceBasedMessageSource as an alternative to the setFallbackToSystemLocale. Does that seem right @jhoeller?

@rstoyanchev

This comment has been minimized.

Copy link
Contributor

@rstoyanchev rstoyanchev commented Nov 13, 2019

Tentatively scheduled for 5.2.2 as it seems straight forward enough.

@rstoyanchev rstoyanchev changed the title Provide a fallback locale other than the system locale Fallback locale other than the system locale in AbstractResourceBundleMessageSource Nov 13, 2019
@jhoeller jhoeller changed the title Fallback locale other than the system locale in AbstractResourceBundleMessageSource Fallback locale other than the system locale in AbstractResourceBasedMessageSource Nov 13, 2019
@jhoeller jhoeller self-assigned this Nov 13, 2019
@jhoeller

This comment has been minimized.

Copy link
Contributor

@jhoeller jhoeller commented Nov 13, 2019

Indeed, I've introduced a setDefaultLocale(Locale) method along those lines, and a ´getDefaultLocale()` delegate which resolves either such a locally specified Locale or (dynamically) the system Locale, preserving the previous behavior.

@jhoeller jhoeller closed this in f61d728 Nov 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.