Automatic selection of formatter by argument type

[zbraniecki]

Fluent implicitly formats arguments in three situations:

• Numbers in placeables are formatted using NumberFormatter
• Dates in placeables are formatted using DateFormatter
• Numbers in selector are formatted using PluralRules

The result is that the following are roughly equivalent:

key = { PLURAL($emailCount) ->
    [one] You have one email
  *[other] You have { NUMBER($emailCount) } emails
key2 = Today is { DATETIME($date) }

and

key = { $emailCount ->
    [one] You have one email
  *[other] You have { $emailCount } emails
key2 = Today is { $date }

The localizer can still decide to use the explicit formatter if they want to pass parameters:

key2 = Today is { DATETIME($date, month: "long") }

but in most cases, the implicit formatting does the job.

[mihnita]

ICU is (I think) more consistent:

• ...{foo}... => same as Fluent, type determined by the type of the parameter
• ...{foo, type}... => mostly there for C/C++ where you don't know the type at runtimes, but also for things like long interpreted as a date (epoch time)
  For example ...{exp, date}...
• ...{foo, type, formatting_info}... => the formatting_info is flexible. For dates it can be a predefined value (for example LONG), a full pattern (bad i18n), or a skeleton

I think we should support all 3 variants.

[nbouvrette]

ICU is (I think) more consistent

I agree, and one aspect that I don't think we have a thread on is the simplicity of the syntax. While I love how powerful Fluent I think it might be one level too complex to hand off directly to linguists as raw syntax. If we go that route, then we know we will have a hard dependency on TMSes and other tools which will make adoption much harder.

Also, I think we should be careful about formatting_info inside the syntax as some extra data might be more relevant dynamically (see the thread on currency).

I think it would be good to define which types we want to support, their predefined formats and which "options" they can support as extra dynamic metadata. These predefined values should always be defined for each type, and give enough flexibility to meet all needs around a given type.

The goal of supporting types should be to have a "one-stop-shop" syntax. I don't feel today we can say this for dates or currencies yet.

[stasm]

I would like to take note of some of the benefits of the explicit notation. They have been mentioned at various times as we were working on Fluent. While we ultimately decided to allow implicit formatting, I still think there are merits to the explicit approach.

key1 = {PLURAL($emailCount) ->
    [one] You have one email
   *[other] You have {NUMBER($emailCount)} emails
}
key2 = Today is {DATETIME($now)}

• The variables used above are self-documenting wrt. their type.
  • This helps understand how the variable is used in the context of the surrounding phrase.
  • Static analysis tools can verify if arguments passed from code are of required types.
  • CAT tools can show examples values for each defined variable type.
  • These use-cases can also be catered to with semantic comments, see Semantic Comments #53.
• The consistency helps discoverability, and makes the syntax easier to learn and work with.
  • In Fluent, this is reinforced by the fact that formatter names are uppercase, making them easy to spot and also similar to Excel functions.
• There are benefits for use-cases when the localization is optimized by "compiling" it to functions to be run at runtime, especially in strongly-typed languages.

[aphillips]

I retitled this to be a little more clear (I hope). The phrase "certain positions" seemed to have something to do with e.g. argument order. @zbraniecki please fix the title if you don't agree with my recharacterization.

[aphillips]

I mistakenly marked this as resolve candidate thinking this was addressed by requiring annotation for selectors, but of course that leaves placeholder defaulting...

This is actually an important issue and we need to resolve how annotation-less placeholders decide what formatter to employ (even if it is to say that it is implementation dependent)