Support resolving messages with named arguments in MessageSource (java.util.Map)

[ooraini]

Overview

The MessageSource interface only supports positional arguments in messages. Alternative implementation with Map style argument have to create a parallel interface and implementation classes to support named arguments. Most i18n libraries I worked with in other ecosystem(non-Java) support named arguments. Unicode's new Message Format 2.0 doesn't event support positional arguments.

Proposal

Add additional methods to support named arguments in messages. The default implementation should throw UnsupportedOperationException. The documentation for MessageSource should indicate that an implementation could support either/both positional/named argument messages. Implementations will throw UnsupportedOperationException if they don't support it.

Additionally, offer a path to extend the existing MessageSource implementations with named argument support.

(Idea) Introduce an additional interface NamedMessageSoruce and make MessageSoruce extend it. All existing concrete classes should offer a way of delegating to NamedMessageSoruce. That way, you can support both positional(through the existing implementation) and named through delegation. Boot can later offer support for wiring such object.

Imaginary code:

@Bean
NamedMessageSoruceFactory namdMessageSoruceFactory() { 
  // custom impl here
}

// boot autowires NamedMessageSoruce into its MessageSource implementation to delegate the new methods

// application code
messageSoruce.getMessage("my_message", Map.of("date", ...), Locale.EN);

// messages.properties
my_message={$date :styel=short}

[ooraini]

Alternative implementation: Introduce MessageSourceFormatter with getMessage methods that uses Map argument. Duplicate the same methods in MessageSource without implementing MessageSourceFormatter. Introduce MessageSourceFormatterAware. Change concrete implementations of MessageSource to implement MessageSourceFormatterAware and delegate the new methods of MessageSource to MessageSourceFormatter.

interface MessageSourceFormatter {
  String getMessage(String code, Map<String, Object> args, Locale locale);
  String format(String patter, Map<String, Object> args);
}

interface MessageSource {
    // existing methods
    String getMessage(String code, Map<String, Object> args, Locale locale);
}

interface MessageSourceFormatterAware {
  setMessageSourceFormatter(...) {...}
}

abstract class AbstractMessageSource ... implements MessageSourceFormatterAware {
  setMessageSourceFormatter(...) {...}
  String getMessage(String code, Map<String, Object> args, Locale locale) { 
    // delegate 
  }
}

That way, applications can register a bean of type MessageSourceFormatter and everything will work.

[ooraini]

My solution is a little premature. It introduces a lot of API surface for little benefit. Also Spring's implementations are coupled to j.t.MessageFormat and it will be a non-trivial change. Right now I went with this approach:

Map<Object, String> args = Map.of();
String pattern = messageSource.getMessage("welcome", null, Locale.ENGLISH);
String message = mf2.format(pattern, args, Locale.ENGLISH);

Since Spring's implementations of MessageResource don't apply j.f.MessageFormat with no arg messages(at least by default). Essentially, I'm using MessageSource for message resolution without formatting.

MessageSource combine two concepts in its design(appropriately):

• Message Resolution
• Message Formating

..which make sense. You usually want to do them together!

I foresee the following solution:

• Introduce LocalizingMessageFormatter which boils to (String pattern, Locale locale, Object arg) -> String.
• Redefine MessageSource with something along the lines implementations are encouraged to use an instance of LocalizingMessageFormatter to perform message formatting(Composition)
• add new method to MessageSource: String getMessage(String code, Object arg, Locale locale)

I'm not sure if it's a worthy pursuit. Please feel free to close this if you don't think it's worthwhile.

[ghillert]

Is this possibly related / a duplicate of #20519?

[ghillert]

Hibernate Validator has support for this since version 5 (2014). See the reference documentation chapter 4.1.2. Interpolation with message expressions