Placeholders behaviour in case of no value for the key

[npeltier]

Hey! looking at

  it('Gracefully falls back', async () => {
    const text = await replaceKey('this-wont-work', config);
    expect(text).to.equal('this wont work');
});

i understand that placeholders are currently designed to display the key if there is no value.

i have a use case where placeholder value would need to be overriden to empty in some cases. For that i could use another behaviour which is to display nothing when live (keeping same behaviour for preview though), but i first need to understand if i will break something that way.

Another if we need to keep that behaviour is to have a special placeholder value 'EMPTY' or something that displays nothing, then authors that want for a given key to display nothing can do key-i-want-empty: EMPTY

[3ch023]

i have a use case where placeholder value would need to be overriden to empty in some cases.
could you describe use case in more details, please?

About placeholder behavior defaults, there 2 cases:
Case 1.
placeholders.json has no 'sample-key' at all.
In this case we can continue showing 'sample-key'.

Case 2.
placeholders.json has 'sample-key' with empty value.
In this case, I think we can show an empty value since it was explicitly specified by the Author. But I don't understand why someone needs a placeholder resolving to empty.

[npeltier]

right, it's case 2. here and (edited recently 😬 ) as written in original post, there is an override of the placeholder value for certain regions, where we need no text. For now authors use   which creates unwanted spacing

[auniverseaway]

There will be a little bit of a tangent, but I'll get to the original question...

---

A note on placeholder misuse:

Case 2 sounds like misuse of placeholders. At least a use case we are unaware of. We're already seeing mis/overuse of placeholders for less than ideal use cases. Full arbitrary words are being put into placeholders: things like, "Special offers" which really should be treated as vanilla text.

There's been poor communication with GWP about the reasons placeholders should be used. I think because placeholders were essentially free (no visible performance implication) for Dexter bad habits were formed and we didn't police when to not use placeholders. Now we're seeing these behaviors in Milo and there now is a performance impact.

The GWP I've talked to have said, "We use placeholders because it's better for localization" which is not accurate. Managing two documents for a string of text is worse than managing one document. Especially when you consider translation memory and transcreation. There's loc benefits if it's a developer driven string (aria labels), but that's not a GWP area.

Really, placeholders should only be used for strings we think may be changed in the future or are changed often. Beta product names is a good use case. We don't know what, "Project XYZ" will end up being called. We know changing Word docs is expensive, so a placeholder is a good use here. Using it for arbitrary strings based on the whims of a content creator is less ideal.

---

I see a challenge in that ideally we would have a third column that says, "fallback behavior" or something along those lines. But to know the behavior would mean the key would have to exist. In Case 2, I think this works... you have the key, you don't actually want it to "fallback" but you want the value to be empty. For case 2, I don't even think you need the 3rd column.

I haven't looked at the code, but I would probably do a check for '' instead of nullish. If there is a key, but the value is empty, use empty. This is different than if there is no key at all because the Excel hasn't been translated, yet.

[npeltier]

thanks, i'll try with what you say.

About usage of placeholders going on on the tangent :p of defining what ideally should be a placeholder, to me it's a string that

1. is used a lot
2. needs consistency

i remember you raising that point on product names in another discussion. Here it's vat text, that is the same across a whole geo, that is "placed" at the same place for everyone, so it feels to me like a good candidate for it

[geri-w]

@npeltier @auniverseaway @3ch023 actually I think it's preferable that we don't have the fallback of displaying the content in a key that does not have corresponding placeholder content created in the placeholder.xlsx doc.

I noted this in the Milo Community Slack channel: https://adobedotcom.slack.com/archives/C03B0BUA75E/p1712203844453899 and @honstar brought this GitHub conversation to my attention. So adding my comment here.

I think it is preferable that any key that does not have actual corresponding placeholder content should display nothing. Otherwise we have the risk of incorrect content appearing if a Placeholder entry is inadvertently deleted or if an incorrect key is entered in the first place.

[npeltier]

hey @geri-w actual behaviour has been in place for some time now. Can you make this follow proper feature request process, so product manager(s) can find potential defensors of the other fallback behaviour?