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

Can Terms reference variables passed to the parent Message? #272

Open
stasm opened this issue Jun 7, 2019 · 6 comments
Open

Can Terms reference variables passed to the parent Message? #272

stasm opened this issue Jun 7, 2019 · 6 comments
Labels

Comments

@stasm
Copy link
Contributor

stasm commented Jun 7, 2019

-wrong-user = (Not {$userName}? Click here.)
hello = Hello, {$userName}! {-wrong-user}

Or should we require that each variable be passed explicitly as a parameter? Related to #230.

-wrong-user = (Not {$userName}? Click here.)
hello = Hello, {$userName}! {-wrong-user(userName: $userName)}
@stasm stasm added the resolver label Jun 7, 2019
@eemeli
Copy link
Member

eemeli commented Jun 9, 2019

I asked a related issue about this earlier in the fluent.js repo, as I wasn't certain to start with if it was a spec or implementation issue: projectfluent/fluent.js#372.

My preference would be for variable's default values to be fetched from the parent message scope, rather than just assumed empty. That would probably be the least surprising thing to happen, from the point of view of a translator who's adding their first parameterised term.

@stasm
Copy link
Contributor Author

stasm commented Jun 13, 2019

Falling back to the calling message's scope might lead to unexpected naming conflicts when a term with a $foo parameter is used in a new message which also expects a $foo variable from the developer. This would make terms less portable; every reference would need to be verified against the list of variables passed to the message referencing the term. This is particularly dangerous given that this list may change overtime without any involvement from the localizer, for instance when the developer starts passing new/more variables to bundle.format.

@eemeli
Copy link
Member

eemeli commented Jun 13, 2019

Is that sufficient reason to settle the answer to this issue's question as "no" then?

@Pike
Copy link
Contributor

Pike commented Jun 27, 2019

I think terms should be isolated from the message. That's giving more power to localizers, in particular in scenarios where we want to have language-specific terms. Examples here would be terms that depend on the platform just for a single language, like in Japanese.

I also think that most of the time, needing external variables in a term is probably a sign that you don't want a term, but translation memory. We're WET, after all ;-)

@stasm
Copy link
Contributor Author

stasm commented Jul 3, 2019

Is that sufficient reason to settle the answer to this issue's question as "no" then?

I think so, yes!

I'm leaving this open until I have a few tests in the reference implementation which verify the intended behavior.

@caridy
Copy link

caridy commented Nov 24, 2021

Certainly I favor the explicit variable. Passing variables from the message to the term seems to be a recurrent topic, and IMO should be resolved. I understand that for selection, pluralization, and such passing the corresponding value as literal is sufficient for the terms to be useful, but for things as the example described here, or for any number/datetime formatting, passing the variable from the message to the term in an explicit way (including renaming of it) is certainly useful.

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

No branches or pull requests

4 participants