So I'm improving Article display in Hometown.
-
So I'm improving Article display in Hometown.
@julian made this post:https://browser.pub/https://community.nodebb.org/post/105824
`content` and `summary` are ALMOST the same, so my software renders repeated content. I'd like to be able to say "if content and summary are the same, then default to one of them and exclude the other". Now the only difference seems to be a newline, so maybe I just trim whitespace but... thoughts? Is this good use of `summary` by nodebb in the first place?
-
@darius @julian @technical-discussion interestingly https://indieweb.org/post-type-discovery#Algorithm suggests that you check if the `name` is a prefix of `content`, and if it is, then it is a Note. perhaps similar logic can be used to check if `summary` is a prefix of `content` in some way?
i don't think this is particularly *wrong*, as generating summaries from excerpts of content is a common pattern in e.g. static site generators like Hugo. it is indeed duplicative, though!
-
I can't speak to whether using this field this way is good or not.
I would set some kind of threshold for a similarity metric (eg Levenshtein distance, maybe divided by string length) below which you only display one. Maybe that's too clever. But it would also catch cases where there was just some punctuation mark difference or something.
-
@darius @julian @technical-discussion one thing this suggests is that there is a semantic difference between "summary" in the sense of providing a short blurb that is additive to the content (kinda like a subheading!), vs "summary" in the sense of providing an excerpt to be used as a kind of preview (as in a list of articles)
-
trwnh@mastodon.social end of the day. I think it's up to each implementor as to how they wish to populate
summary.NodeBB takes the first few sentences adding up to but not exceeding 500 characters, and uses those. It does change the HTML because simple truncation would leave you with broken or unfinished tags.
That's probably why darius@friend.camp said they were almost the same.
-
@julian @darius Hugo does the same by default, taking the first ~70 characters to the nearest word boundary (or something like that).
i'm just pointing out that there might be some needed disambiguation with how `summary` is used, to account for this kind of "excerpt vs subtitle", "duplicative vs additive" usage.
-
darius@friend.camp but to answer your initial query, I feel that summary is always going to be subservient to content. It's either a truncation or derivative of content, so if you have the capabilities to parse content, just use that in its entirety and pass over
summary(Until T&S standardize CWs, but that's a different story)
-
@julian that makes sense. I should probably just not render `summary` for now if `content` is present and renderable. And I then render `name` as a title field
-
@darius @julian I vote for this - one or the other, never both.
IMO the
summaryis for index or thread views where the article is too long to display, and the author wants to make sure the part that gets displayed accurately reflects the content. If you're just gonna auto-truncate the content, better not to put asummaryat all. The client would do a better job. -
mat@friendica.exon.name you're right, and in the ideal case, NodeBB would not send summary either, as it is automatically generated.
Right now, we are in a situation where Mastodon will utilize summary for non-note objects, but ignore content. This is why we send both, currently.
When Mastodon updates their implementation to consume
preview, then we will update ours to no longer send summary.
