Allow all inline expressions as named arguments

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")}
}.

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.

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...

Very much in favor. Related: #325.

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 Dynamic message references #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.

Is there any news?

@spookylukey

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

I have yet another use case for this: Markup escape functions (Basically "back"porting markup functionality from Messageformat 2). Having something like that allows one to make rich messages and explainer snippets with some embedded things like an application generated code or a link from an open set (i.e. a database)

For example:

pair_code_html = Enter the code { HTML_TAG("code", "inner_text": $code_from_application) } to pair your device.
pair_help_html = Need help pairing? { HTML_TAG("a", href: $device_specific_help_link, inner_text: "Have a look at the manual for your device.") }

How I implemented it (yes this is a horrible hack on top of a horrible hack):

pair_code_html = Enter the code { HTML_TAG("code", "inner_text", $code_from_application) } to pair your device.
pair_help_html = Need help pairing? { HTML_TAG("a", "href", $device_specific_help_link, "inner_text", "Have a look at the manual for your device.") }

Should I open a separate issue for allowing this for functions? (The current ebnf grammer doesn't care where the named argument is used)

If this is a feature that is still wanted I'd be open to send a PR for fluent-rs.

I have had scenarios in the past where this would have been really convenient.

Navigation Menu

Repository navigation

Allow all inline expressions as named arguments #230

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow all inline expressions as named arguments #230

Description

Activity

erikroe commented on Aug 28, 2020

joepie91 commented on Dec 13, 2020

rkh commented on May 12, 2021

spookylukey commented on May 12, 2021

affkie commented on Jul 13, 2023

indeyets commented on Dec 8, 2023

slatian commented on May 24, 2026

slatian commented on May 24, 2026

JoyceBabu commented on Jun 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions