Placeable vs Placeholder vs ?

[zbraniecki]

In https://github.com/unicode-org/icu4x/issues/128 Elango suggested naming what Fluent calls Placeable a Placeholder.

I prefer Placeable but as an ESL, my preference may be coming out of lack of contextual understanding of English.

Placeholder for me is a temporary value that is meant to be replaced with an actual value later. For example Your X has arrived can name X as a placeholder.

In Fluent Placeables play much more powerful role than just an X in a sentence. They store expressions, and those can be more complex than just an X.

For example: Your { DATETIME($now) } has arrived, Hello { CAPITALIZE($productName) } and even:

All of { GENDER($user.gender) ->
    [masculine] his
    [feminine] her
  *[other] their
} friends

I know that Unicode (and Mihai) recommend us to avoid variant selectors mid-pattern, and I generally agree with that sentiment. I prefer:

{ GENDER($user.gender) ->
    [masculine] All of his friends
    [feminine] All of her friends
  *[other] All of their friends
}

but the value of the the placeable is that it can support both, and we're not locking ourselves in an approach on the AST level (we may lock ourselves on the syntax level, or on the linter level).

Thinking of Pattern as a list of text elements and expressions works really well for Fluent AST and I think of the term Placeable a part of that pattern that stores expressions. I think Placeholder name is more narrow.

I'm 0.6 on Apache Voting Scale on that.

[echeran]

Don't get me wrong, it's not a linguistic critique ("Lunchable" is a brand name, after all, FWIW), but rather, it's more that I don't see enough of a difference to warrant a new name.

Okapi's placeholder holds onto a tiny bit more data than being just a named holder-of-place. There's no reason why it couldn't hold onto a little more data which tells us which type of special formatting that we should apply to its value, and I would still call it a placeholder.

I also agree that having nested switch/case blocks is an anti-pattern, and furthermore, it causes limitations on ICU MessageFormat pattern syntax expressivity. (IIRC, "anti-pattern" for translators.)

Anyways, if there's some scenario or functionality of the Fluent Placeable that is uniquely possible, then I could be convinced otherwise. For now, I'm more of a 0.8 or 0.9 on the Apache scale.

[zbraniecki]

it's more that I don't see enough of a difference to warrant a new name.

Whether the name is new, depends on what you're familiar with. There's a good selection of localization APIs and papers which use the term placeable.

Anyways, if there's some scenario or functionality of the Fluent Placeable that is uniquely possible, then I could be convinced otherwise.

It's just a name. I don't suspect we'll find a technical reason to use one or the other.

I'm curious about the opinions of others on the name. Maybe there's a yet another one we could settle on :)

[zbraniecki]

@stasm thoughts on the name? So far we have @echeran with 0.8-0.9 in favor of placeholder and me with 0.5 in favor of placeable, so if we don't get more opinions soon, I'll switch my AST proposal to placeholder.

[stasm]

Thanks for the ping. This is anecdotal, but I think I've heard placeholder more often in the MFWG than placeable. Treat me as a 0.1, though. More importantly, if the goal of this repo is to rapid prototype of a subset of MessageFormat 2.0 WG ideation, it really doesn't matter. All this code will likely be archived :)

[mihnita]

I think allowing for full expressions in a placeholder / placeable is one of the things that makes Fluent flexible, but also very hard to handle in localization tools. Gives you too much rope to shot yourself in the foot (mixing metaphors here :-)

If we reduce the scope of these place* thing to be "replaced at runtime, controlled by flags", then is matches not only what MessageFormat does, but also printf (think "...%-2.3d..."). And HTML: "......" and some javascript will later replace that span with a real date of birth.

I think of placeholder as a marker that "keeps the place of something that will be replaced at runtime" It does not matter how simple / complex is that replacement process.

If I use "...{expiration, date, ::dMMMy}..." is a placeable, and "...{expiration}..." is a placeholder? Because the first one really is complicated. It is a call on a "date" kind of method taking as parameters the locale, the skeleton, and the "expiration" value.

Or is it not complex, because it is not an expression? Then "...{DATE(expiration, "dMMMy") }..." this is expression? It is the same thing, I've only changed the syntax a bit. The conceptual "thing" there didn't change: is something that will be replaced at runtime.

---

In general the l10n industry uses "placeholder": http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html http://docs.oasis-open.org/xliff/xliff-core/v2.1/xliff-core-v2.1.html

---

I am also not a native English speaker. But for me placeable is "the thing that can be placed" https://www.collinsdictionary.com/us/dictionary/english/placeable