Make content warnings part of the default section #305
Conversation
electron-app/src/server/submission/parser/section-parsers/description.parser.ts
Show resolved
Hide resolved
| @@ -7,6 +7,7 @@ export interface DefaultOptions { | |||
| tags: TagData; | |||
| description: DescriptionData; | |||
| rating?: SubmissionRating | string; | |||
| spoilerText?: string; | |||
There was a problem hiding this comment.
I think this idea is fine. Though I see a lot of undefined checks for the existence of the overwrite field.
I think in this case, it might be better to create this as a object type similar to tags or description (i.e. TagData, DescriptionData) where we have an object that contains the override flag. This will avoid having to create optional and specifically named prop checks and keep things standardized across all websites.
There was a problem hiding this comment.
The checks are required anyway, due to backward compatibility with existing submissions that will be in the old state. So wrapping it up in some kind of spoilerTextData field wouldn't let us get rid of the spoilerText field, meaning we'd keep lugging around that inert field forever. Having a useless field and writing extra code for the questionable gain of being able to name fields weirdly seemed like a worse tradeoff to me than just adding to what's there.
There was a problem hiding this comment.
Fair enough I guess.
Will test this after the next version is out and merge if no issues.
Because I'm getting tired of repeating it for a bunch of sites.
The content warning will automatically be applied to Itaku, Mastodon,
Misskey, Pixelfed and Pleroma. They can also overwrite the default via
toggle switch, similar to how it works for descriptions. Probably mostly
necessary for Itaku with its dinky 30 character limit.
The content warning can be included into the description using the {cw}
shortcut. This is mostly useful for sites like Bluesky and Telegram,
which support spoilers, but don't have a dedicated content warning
field.
Backward compatibility with existing posts should be preserved: if the
overwrite option is undefined, it will be guessed by the presence of a
non-empty content warning text.
This also now consistently presents the field as "content warning" to
the user, rather than revealing the internal "spoiler text" name. I've
seen confused users on Mastodon thinking that PostyBirb didn't support
content warnings because of the misnomer.
askmeaboutlo0m
force-pushed
the
default-content-warnings
branch
from
9a20b41 to
c096b06
Compare
Because I'm getting tired of repeating it for a bunch of sites.
The content warning will automatically be applied to Itaku, Mastodon, Misskey, Pixelfed and Pleroma. They can also overwrite the default via toggle switch, similar to how it works for descriptions. Probably mostly necessary for Itaku with its dinky 30 character limit.
The content warning can be included into the description using the {cw} shortcut. This is mostly useful for sites like Bluesky and Telegram, which support spoilers, but don't have a dedicated content warning field.
Backward compatibility with existing posts should be preserved: if the overwrite option is undefined, it will be guessed by the presence of a non-empty content warning text.
This also now consistently presents the field as "content warning" to the user, rather than revealing the internal "spoiler text" name. I've seen confused users on Mastodon thinking that PostyBirb didn't support content warnings because of the misnomer.