Candidate Features to be implemented/tested in the both Data Model versions

[romulocintra]

List of issues that must be tested against both data Models. Please add comments to any relevant issue that should be considered as a Feature Candidate to be implemented and tested agains the candidate versions of data models.

Goals

• Test Models
• Prioritization of features
• Find use cases

Important :

• Any kind of features are accepted

Process

• Mention or Link issues as a comments
• If there is no issue that covers your needs, please open a new issue and add it here

[romulocintra]

@grhoten @stasm @mihnita @dminor @aphillips @romulocintra @echeran

[eemeli]

Dynamic References #130

Relevant example of this that I gave during the meeting: A message regarding one of a set of products (e.g. browsers) needs to be formatted. This can be made possible by having one resource with identifiers for each product, and their representation under different cases. For example, this is in Finnish:

chrome:
  nominative: Chrome
  genitive: Chromen
edge:
  nominative: Edge
  genitive: Edgen
firefox:
  nominative: Firefox
  genitive: Firefoxin
safari:
  nominative: Safari
  genitive: Safarin

With this message resource, a dynamic message reference using a path [browser, 'genitive'] could be used to select an appropriate form for use in a different message. browser here would be a variable passed in to the formatter at runtime, taking one of the values 'chrome' | 'edge' | 'firefox' | 'safari'.

[eemeli]

Plural Range Selectors #125

Depending on the locale, the pluralisation of a range of values depends on either the start or end value, both, or neither. This makes it an interesting data model test, as an implementation may require the range to be passed in as an externally defined tuple, or it may allow for the range start & end to be passed in as separate variables.

[eemeli]

The multi-selector messages of #119

That issue has (or links) to three complex real-world examples that in MF1 use internal selectors, but in MF2 can't. It would be good to show how each of these could be represented by each data model not just as a single message, but also as sets of messages; the latter form is effectively required for a use case that needs to maintain complete backwards compatibility with MF1 sources.

[eemeli]

Interaction with a custom list formatter #36

As detailed in the issue, at least Siri uses a list formatter that provides a wider set of options and transformation than e.g. the ICU ListFormatter. The point with this example wouldn't be to implement said formatter, but to show how the interface would look like, with multiple tweakable things.

This would also provide an opportunity to show a difference between the models' ability to complement an externally provided list with values defined within the data model.

[eemeli]

For the data model proposed by @zbraniecki and myself, I've added a test suite covering each of the four features listed above. This CI run shows all of those tests passing.

For the multi-selector messages, the data model is compiled from the original Fluent and MessageFormat 1 sources, as working with the up to 81 separate selector cases directly would be somewhat unwieldy. Internally, each message's internal selectors are here lifted to be external selectors, so this doesn't yet show how message references could be used for the same task.

Regarding the list formatter case, the test flattens multiple arguments into one list, and uses Intl.ListFormat for its formatting; therefore it requires at least Node.js 12 to pass.

[echeran]

List formatting with grammatical inflection on each list item #3

Example: "I gave gifts to {name1}, {name2}, and {name3}"

• In Romanian you need to use dative: "Le-am dat cadouri Mariei, Ilenei, si lui Petre."
  • dative("Maria") = "Mariei"; dative("Ileana") = "Ilenei"; dative("Petre") = "lui Petre"
  • "Le-am" for more than one person, "I-am" for one person
• In Tamil, you add and then inflect the word that represents the items as antecedents: "நான் மரியா இலெயானா பீட்டர் ஆகியோருக்குப் பரிசுகளைக் கொடுத்தேன்." (translit: "nāṉ mariyā ileyāṉā pīṭṭar ākiyōrukkup paricukaḷaik koṭuttēṉ.")
  • Notice that the ப் (p) phoneme is added to the end of the dative inflection ஆகியோருக்கு (ākiyōrukku) since it is a plosive consonant that begins the following word
  • Doubling the plosive phoneme can change the proper pronunciation (allophone) of next consonant
  • The word you add depends on whether the items are animate or inanimate
  • When the next word doesn't begin with a plosive, the initial phoneme is not "doubled" to the end of the dative. Ex: "I gave awards to {name1}, {name2}, and {name3}." -> "நான் மரியா இலெயானா பீட்டர் ஆகியோருக்கு விருதுகளைக் கொடுத்தேன்." (translit: "nāṉ mariyā ileyāṉā pīṭṭar ākiyōrukku virutukaḷaik koṭuttēṉ.")

[echeran]

Interpolating placeholder values with linguistic context #3

• Ex: "a {item}" -> "an apple" and "a car"
• Ex: Spanish: list conjunction word "y" changes to "e" when next word begins with "i"
• Ex: Spanish: list disjunction word "o" changes to "u" when next word begins with "o"
• Ex: Spanish: "I got new {item}" => "nueva" (f.s.) / "nuevo" (m.s.) / "nuevas" (f.p.) / "nuevos" (m.p.)

[echeran]

Full message fallback #45

Fall back to a default message pattern when part of the message fails to format, ex: the formatter for a placeholder lacks logic / data to format input.

Ex: Polish: "Hello {username}," needs vocative case for username. So the translated message pattern might be "Cześć {username,case:vocative},". But if runtime fails to format any part of that, then fall back to "Cześć {username,case:nominative},,".

[echeran]

Inflections #16

Your ${device} is on.

The linked issue describes some of the known considerations for "Your", "is", "on", and ${device} in various languages like Arabic, Hebrew, English, and French.

${number} ${item} were found.

The linked issue describes the need for plural selection based on ${number} for various languages, and the need for number formatting (ex: spell-out).

[echeran]

Pluggable formatters / Interface for formatters #22

Allow custom (user-defined) formatters to be used in a message. This would be best designed by defining an interface through which all formatter functions can participate.

[eemeli]

Regarding placeholder value interpolation and inflections, those could get solved by the local transformations of #160. As discussed there, the only requirement that this would impose on the data model is ensuring that metadata can be attached to nodes. Of course the syntax and runtime processing need to take it into account too.

[eemeli]

This list was discussed at yesterday's "MF extended" meeting. The following were selected as features to compare the proposed data models:

• Dynamic References Dynamic References #130
• Plural Range Selectors Support for plural selectors for a range of numbers #125
• The multi-selector messages of Collect all possible MessageFormat use cases #119
• Full message fallback Specify error fallbacking #45
• Pluggable formatters / Interface for formatters Support custom / pluggable "formatters" (beside Date/Time/Number ...) #22

Additionally, the Romanian dative case example of the second list formatter feature was selected. Discussion on the first list formatter feature was cut short without a final decision; the point of conflict is the ability to concatenate lists and literal values passed as separate formatter arguments.

The remaining items were not selected, as the sense was that while very important, they do not have a significant impact on the data model. More discussion on a possible solution for them is available in issue #160.

• Interpolating placeholder values with linguistic context Requirements - MF wishlist #3
• Inflections Support for inflections (cases) #16

[romulocintra]

Hi, @eemeli @mihnita @stasm I believe this issue can be closed. All proposed and selected features were tested and implemented by each Data Model.

I think may help is a Map of each selected feature and corresponding implementation for easy lookup in the future.