Одно небольшое замечание к @BalusC отличное решение.Если у нас есть <f:viewAction>
, который выполняет некоторый метод в компоненте поддержки.Языковой стандарт, доступный из вызова к FacesContext.getCurrentInstance().getViewRoot().getLocale()
внутри этого метода, будет языковым стандартом, установленным браузером пользователя или языковым стандартом приложения по умолчанию, а не тем языковым стандартом, который установлен для сессионного компонента по выбору пользователя (конечно, они могут совпадать, если языковой стандарт браузера равен той языковой стандартпользователь выбран).
Я могу быть исправлен, потому что, возможно, я что-то не так сделал при реализации решения, предоставляемого @ BalusC.
EDIT. После игры с JSF lifecycle это поведение с локалью не связано с <f:viewAction>
, потому что такое же поведение также с @PostContruct
.<f:view locale="#{localeBean.locale}">
в запросе (после выбора пользователем локали) выполняется в фазе ответа рендеринга.Методы <f:viewAction>
и @PostContruct
выполняются на этапе вызова приложения.Вот почему логика, которая выполняется в этом методе, не имеет доступа к выбранной пользователем локали.
Решение, которое мы используем, когда нам нужна правильная локаль, заключается в том, чтобы внедрить (CDI) localeBean
в другой компонент поддержки, содержащий <f:viewAction>
и @PostContruct
методов, а затем установите языковой стандарт с UIViewRoot#setLocale()
из localeBean
в начале этих методов.