Support the ICU MessageFormat for translation messages

[sissbruecker]

trafficstars

Describe your motivation

As part of providing a unified Vaadin framework, translation messages are going to be shared between all environments: Vaadin backends in general, Flow views and Hilla views. Likewise, the format (or syntax) that these messages use should ideally be the same, so that translators don't have to make a distinction between which environment individual messages are going to be used in, and which format / syntax that environment supports. That means we need compatible message format implementations in both the backend (Java) and the client (Javascript).

[!NOTE] The message format syntax defines how to achieve things like basic parameter replacement, formatting numbers and dates, or pluralization.

For introducing an I18n solution in Hilla, we've decided to support messages in the ICU MessageFormat (see https://github.com/vaadin/hilla/issues/2105). ICU is an industry standard that is commonly used in other I18n related tools and libraries, and translators are likely to be familiar with it. There are also implementations of that standard in multiple languages, specifically Java and Javascript.

Furthermore, the Hilla I18n implementation is going to use named parameters (Total cost: {price}) instead of numbered parameters (Total cost: {0}). Named parameters are in general considered more useful as they provide better context to translators.

Long term, we should add support for the ICU MessageFormat, as well as named parameters, to Flow, so that developers can start to use the same format for all translation messages, regardless whether they are used in Flow views, Hilla views or just in the backend in general.

Describe the solution you'd like

We should provide an I18nProvider implementation that supports formatting messages in the ICU format, probably based on ICU4J, which is the reference implementation of ICU for Java.

Two options have been discussed so far:

1. Change the DefaultI18nProvider to use ICU4J. The ICU4J implementation of MessageFormat promises to be backwards-compatible with java.text.MessageFormat, which is what DefaultI18nProvider uses currently. We should properly test if that promise holds true, and if so, the implementation could be replaced without a breaking change.
2. Introduce a separate I18nProvider implementation that is based on ICU4J. Initially developers have the option to configure that provider with the respective property if they want compatibility of message formats between different environments. Later on we can change the default in a new major, while keeping the option to switch back to the JDK based MessageFormat implementation.

In order to support named parameters, we should add respective API that allows passing a map instance with key/value pairs. That might be doable as an overload to the existing getTranslation method, in both I18nProvider and Component.

Additional context

ICU MessageFormat reference:

• Formatting Messages | ICU Documentation
• Format Guide - messageformat
• A complete guide to ICU message format & syntax with examples - Lokalise Blog

(Could not find an exact specification, the above are references from individual tools implementing the spec)