You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Referencing parameterized terms is legal syntax in Fluent 1.0:
-term = {$case ->
[lower] value
*[upper] Value
}
## All three messages format to the same value.hello1 = Hello, {-term}
hello2 = Hello, {-term()}
hello3 = Hello, {-term(case: "upper")}
Without parameters, the default variant is selected. Should the resolver also report an error / warning?
The text was updated successfully, but these errors were encountered:
In the case of multi-variant branding, I think it's OK for some variations to have sub-optimal term shapes. Think of an online shop system (or Firefox/Thunderbird).
I'd say that all three ways in the example are OK.
There is the scenario where you have hello4 = Hello, {-term(casa: "upper")}, and you'd like to know. I think the solutions for this lie in tooling/editing support, though, and not the runtime.
There are variations of the "tooling/editing" story that are "build time", remembering the elm impl, for example. But I look at that as a build time static analysis much more than a build time resolver.
Referencing parameterized terms is legal syntax in Fluent 1.0:
Without parameters, the default variant is selected. Should the resolver also report an error / warning?
The text was updated successfully, but these errors were encountered: