Repository navigation
reusing terms to create more complex terms #337
Description
When terms inside other terms, there is a limitation around passing variables down to other terms, but I'm not sure about the nature of such limitation. Here is an example:
-bar = { $n ->
[0] some
*[1] another
}
-foo = before { -bar(n: $x) } after
-foo is just an abstraction around -bar, delegating to it a piece of the message, but passing $x down to -bar is forbidden, with parsing error E0014: Expected literal.
Activity
zbraniecki commentedon Nov 5, 2021
@stasm - can you recall the rationale?
stasm commentedon Nov 10, 2021
I have a vague memory of wanting to forbid exactly this kind of use-cases. IIRC, my argument was that this increases the complexity, makes the translations harder to reason about, and is generally something that programmers like to do, because we like factoring things out in the name of DRY. Whereas Fluent was based around WET: write everything twice, because we assumed WET would easier for translators, translation memories, and machine translation systems.
When you're saying
-foois just an abstraction around-bar, it sounds like a red flag to me. Can you provide a more concrete example of what you're trying to achieve?dolezvo1 commentedon Dec 27, 2025
I would like to see something like this, and I was quite surprised you can't actually parameterise a term with a runtime value.
I think a good use case would be the reuse of pluralisation. For example if you have hundreds of messages like this, copy-pasting the pluralisation code would be unbearable, not to mention if you have inflected variants and whatnot: