Alistair pinpoints how and where to define your user-facing strings.
You've probably already read about the messages.properties file. It allows you to define any strings you wish to present to an end-user.
messages.properties:
To retrieve one of these strings in code you first need to get a MessageSource. This is provided via spring dependency injection.
Constructor injection:
@Service // Or some other `Component` annotation
class SomeService( private val messageSource: MessageSource )
Property injection:
@Autowired
private lateinit var messageSource: MessageSource
Then you can call getMessage:
messageSource.getMessage("title.example", null, LocaleContextHolder.getLocale())
args can be provided for string replacement. For example:
messageSource.getMessage("message.hello", arrayOf("Joe Bloggs"), LocaleContextHolder.getLocale())
Notice above, we pass LocaleContextHolder.getLocale() as a Locale to the getMessage call. This tells the MessageSource which language to provide.
LocaleContextHolder provides the current Locale that spring is aware of. This is a powerful mechanism. We don't need to add any custom code to our RestController's or otherwise to determine Locale. Callers can set the locale as a request header and spring will make that available.
To provide other language strings we add a new messages file, messages_fr.properties:
To learn more, check out this guide.
When modularizing your application you may run into trouble. By default the messages.properties files from each module will conflict with each other. Only one set of messages will be available.
To avoid this, all your messages files need to have different names. A good convention to follow is to use your module name. For example: messages-application.properties, messages-application_fr.properties, messages-library.properties, messages-library_fr.properties.
Now we need to expose these to the MessageSource. By default, only files named message.properties will be found.
In your application.properties file add:
spring.messages.basename=messages-application,messages-library
Notice we do not include the language extension or the file extension here.
That's it. You can now provide strings in each of your different modules.
Search over 400 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!
We develop intelligent mobile apps for iPhone & Android that deliver for you.
Want to connect? You can find us on Instagram, Facebook, X (formerly Twitter) and LinkedIn.
Here’s our privacy policy.
Here’s our Accessibility statement.
Copyright © 2024 Brightec Limited. All rights reserved.
