Someone on StackOverflow brought up an interesting use case. Imagine a Java class used to create a JSON response body and one of the String fields contains a message to be localized:

class MyResponse {
  String messageKey;
}

A Spring MVC controller method could now of course use a MessageSourceAccessor to replace that value against a MessageSource and replace it in the model object. However, I wondered whether an annotation, that just declares "This is a field to be localized" could be used and some Jackson integration could be deployed that automatically translates the value during rendering. I.e. the domain object could look like this and that would remove the need for the controller manually triggering the translation.

class MyResponse {
  @JsonLocalized String messageKey;
}

I have a prototypical implementation over here which probably could be extended to also support properties of type MessageSourceResolvable.

I briefly discussed with @wilkinsona whether something like this should rather live in Boot, but as nothing really ties this to Boot and there's already precedent in Spring Framework to allow customization of rendering of form objects with @DateTimeFormat we thought it might be a good fit for Framework. Of course one could also argue, that currently, Framework itself doesn't have any opinion regarding the Jackson setup while Boot already ships customizations and SPI to ease the implementation of serializers etc. I am entirely open for suggestions regarding that.

Comment From: sdeleuze

After a team discussion, we agreed that's a useful use case but we prefer to decline integrating such feature in Spring Framework for various reasons: - Turning a key into a localized value is significantly more opinionated than @DateTimeFormat and almost changes the nature of the field. - People may expect different behaviors : getting the translation from resource bundles but also from databases, which could involve some caching, or keeping the message key and put the translation in another property. - Maybe could be a Jackson custom module that would be customized at Boot or user level rather than something that should live in Framework (we only integrate existing popular Jackson modules, we don't ship our own).

As a result, we decided to decline this issue. Maybe worth to publish as a standalone Jackson module (if it does not exist yet) and see if it gains traction for a clearly define set of use cases.

Comment From: odrotbohm

For reference, there already is something like that in usable form here. Instead of an annotation, it's type-based, with a neat API to also capture message arguments etc. I just doubt it'll get significant traction as it's not very discoverable for one and people likely shy away from using an extra dependency a single person authored for such rudimentary functionality.

I can't quite follow the second bullet point as MessageSource is the API to hide message resolution behind? I.e. applications can already tweak the resolution behavior with abstractions already in place.

Comment From: sdeleuze

I can't quite follow the second bullet point as MessageSource is the API to hide message resolution behind? I.e. applications can already tweak the resolution behavior with abstractions already in place.

Indeed MessageSource is flexible enough, my point was more about this feature likely to require frequently customization / custom implementation.