自定义Spring Boot启动器:如何将i18n消息提供给MessageSource?

Les*_*ood 9 java spring internationalization spring-boot

我正在编写一个自定义的Spring Boot启动程序,其他开发人员将放入他们的应用程序,这个启动程序包含开箱即用的控制器和UI屏幕.

这些UI屏幕是国际化的,i18n键/值在包文件中:com/foo/wherever/i18n.properties.

我想确保在启动时加载我的启动器时,这些i18n.properties在应用程序中MessageSource自动可用,以便我的UI页面工作(通过普通的Spring Controller + ViewResolver + View实现呈现),而app开发人员不必指定这个归档自己.

换句话说,他们应该能够将我的启动器添加到他们的运行时类路径中,并且一切"正常工作"而无需配置任何东西.

现在,我发现应用程序开发人员可以创建自己的src/main/resources/messages.properties文件手动配置其他消息文件application.properties:

spring.messages.basename = messages, com.foo.wherever.i18n
Run Code Online (Sandbox Code Playgroud)

这将有效.

但是,这需要以下两个方面:

  1. 他们必须手动配置spring.messages.basename属性 - 它不是自动的.和
  2. 它们必须messages.properties在其应用程序类路径中拥有自己的文件.如果messages.properties文件不存在,spring.messages.basename甚至不起作用.即使他们不关心i18n,这仍然是必需的 - 不可取.

我想我可以将我的i18n.properties文件移动到启动器.jar中的类路径:/messages.properties文件中,但这似乎不是一个好的解决方案:如果app dev有自己的messages.properties文件只有一个它们将被读取,导致消息值丢失.

看起来好像春天启动MessageSourceAutoConfiguration应该有一个概念CompositeMessageSource是在一个或多个迭代MessageSource实例可用(并且Order在Spring的ApplicationContext ED)和所使用的DispatcherServlet的.这将允许任何启动器仅通过MessageSource在其自动配置中声明a来为可用消息做出贡献

有可能做我的要求吗?应用程序开发人员最"亲切"的解决方案是什么?

ana*_*ocs 17

我通过以下方式设置它.我目前只支持en_US,但它设置为使用国际化(i18n)处理任意数量的语言.

在此处查看代码

在这里查看代码要点:github gist上的代码

添加消息源和默认区域设置Bean

将这些bean添加到Application.java中以设置默认语言环境并配置消息道具的位置

消息源和默认语言环境


创建消息服务

服务将从会话中获取默认区域设置,然后从道具中获取消息文本

设置消息svc


使用Controller中的消息服务

注入消息svc然后传入id以从props文件中获取值

在控制器中使用svc


在语言环境中添加message.properties文件

转到/资源:

  • 创建语言环境文件夹
  • 创建一个名为messages_en_US.properties的文件

消息道具


阅读更多

您可以在此处查看有关此主题的更完整的文章: Spring Boot Internationalization i18n using Message Properties


看看守则

在这里查看代码要点:github gist上的代码

  • 发表回答很好,但代码应该是可复制的.可以从发布的链接复制它. (3认同)
  • 这个答案没有解决这个问题 - 问题是关于如何在Spring引导启动器*中实现国际化,而不强迫用户在本地应用程序中定义这些概念. (2认同)

sod*_*dik 2

也许这是一个遥远的事情,但你可以尝试使用BeanFactoryPostProcessor

思路如下:

  1. 将“messageSource”bean 从应用程序上下文中取出。请注意,如果开发人员想要使用自己的实现并且不使用 Spring Boot 自动配置,则它可能但不一定是 Spring Boot 的。

  2. 将其替换为您自己的实现,尝试解析“您的密钥”,并将其余部分委托给原始消息源。或者反之亦然,如果您希望开发人员可以覆盖您的翻译(如果原始消息源不会抛出未知键的异常,则可能会出现问题)。

但可能有更好的方法来做到这一点。