Can't use boolean options on number formatting

[ranisalt]

I currently have the following rule:

period = {$season ->
    [spring] Vår {NUMBER($year, useGrouping: false)}
   *[autumn] Höst {NUMBER($year, useGrouping: false)}
}

As per the docs.

However, this just doesn't work, the rule does not apply and displays the untranslated fallback. It looks like the functions don't support boolean values, every other parameter that is a string or number works. If I pass useGrouping: 0 it works, which reinforces that.

[zbraniecki]

Yup. Our syntax doesn't support booleans - https://github.com/projectfluent/fluent/blob/master/spec/fluent.ebnf#L75

@stasm, @Pike - do you remember how we wanted to workaround it for those cases? Was it supposed to be num->bool, or string->bool ("false" -> false) ?

@eemeli - FYI in context of MF2.0 planning :)

[ranisalt]

Our syntax doesn't support booleans

I'm new here so sorry if the question is stupid, but couldn't a BooleanLiteral ::= "false" | "true" expression be used I don't think it would be ambiguous in that case.

[Pike]

IIRC, the core problem with "logical" types is that once they're there, you have to figure out what to do with them. That's affecting boolean, but also null and undefined (IIRC, there's a fluent issue on those).

If those logical types were fluent values, they'd need a humane-localized-readable representation. Which is probably not great, or at least a can of worms.

Now, for NamedArgument, we could introduce a BooleanLiteral as Ranieri suggests, but then there's the question what's the path of least surprises throughout all places in Fluent that have literals.

As for the options for NUMBER, I think we had a lot of energy put into the fields and if they're exposed, and if so if to programmers or localizers or both. I don't remember thinking much about the value space of them.