Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reusing terms to create more complex terms #337

Open
caridy opened this issue Nov 5, 2021 · 2 comments
Open

reusing terms to create more complex terms #337

caridy opened this issue Nov 5, 2021 · 2 comments

Comments

@caridy
Copy link

caridy commented Nov 5, 2021

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.

cc @gonzalocordero

@zbraniecki
Copy link
Collaborator

@stasm - can you recall the rationale?

@stasm
Copy link
Contributor

stasm commented 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 -foo is 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants