Allow all inline expressions as named arguments

[stasm]

This was originally filed as #188 concerning VariantExpressions which was since removed from the Fluent Syntax. However, the same problem remains in named arguments to call expressions.

Given a term defined as follows:

-thing = { $count ->
    *[one] thing
    [other] things
}

Should we allow this?

you-own = You have { $count ->
    *[one] a {-thing(count: $count)}
    [other] {-thing(count: $count)}
}.

Right now, only NumberLiterals and StringLiterals can be passed as named arguments, so the work around is to pass the names of requested variants explicitly:

you-own = You have { $count ->
    *[one] a {-thing(count: "one"}
    [other] {-thing(count: "other")}
}.

Or:

you-own = You have { $count ->
    *[one] a {-thing(count: 1}
    [other] {-thing(count: "other")}
}.

[erikroe]

Hello! Just asking about if there's any progress of deciding this feature. When I started using Fluent lately this is a feature I dearly started to miss. I have a good bunch of always same sounding messages I like to manage centralized by a term, and then just pass the missing bits into by variables from the application.

[joepie91]

I've also run into this same issue; IMO it's definitely necessary. Without the ability to 'pass through' variables into terms, it's not possible to abstract out a chunk of text logic like the way you might abstract some code out into a function, which severely limits the usefulness of terms.

I was really surprised to find that this isn't supported...

[rkh]

Very much in favor. Related: #325.

[spookylukey]

Some of the use cases above sound like exactly the kind of thing we should be avoiding if messages are to be properly translatable:

• Unnecessary logic in messages makes life harder for translators, for one thing, and can give them a starting point that is very unhelpful depending on the target language.
• It also sounds like some people want to use the feature to build up phrases uses concatenation of chunks of text, some of which are coming from the application layer. In general this may work in one language but will produce poor results in other languages (due to needing things like agreement of case/gender etc.). Another proposal to look at for this use case is #80 .

If those in favour of the feature could provide fuller examples I think it would help - all the examples I can think of I would consider to be counter-arguments.

We also need to consider that "all inline expressions" is a large broadening. If only certain types of expressions are needed, we should not broaden to all expression types. As an implementer of multiple implementations, I want to note that the current restrictions on named arguments have some big upsides in terms of simplicity, particularly for implementations like mine that function as a compiler, since all arguments to the term are fully known at compile time.

[ekeew]

Is there any news?

[indeyets]

some people want to use the feature to build up phrases uses concatenation of chunks of text, some of which are coming from the application layer. In general this may work in one language but will produce poor results in other languages

@spookylukey my use-case is actually exactly the opposite of this. right now, we have to do multi-step translation and pass results of one terms to another terms from the application level and it leaves space for making it wrong.

Ability to build complex phrases based on flags which are passed from application would let us have a "black box" and let localization professionals to handle all of this in fluent's domain