Placeholders behaviour in case of no value for the key #1900
-
Hey! looking at
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 |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
About placeholder behavior defaults, there 2 cases: Case 2. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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
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 |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
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 behavi…