惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

L
LangChain Blog
J
Java Code Geeks
P
Proofpoint News Feed
Recent Announcements
Recent Announcements
罗磊的独立博客
H
Hackread – Cybersecurity News, Data Breaches, AI and More
博客园_首页
Hugging Face - Blog
Hugging Face - Blog
MongoDB | Blog
MongoDB | Blog
人人都是产品经理
人人都是产品经理
博客园 - 【当耐特】
雷峰网
雷峰网
D
DataBreaches.Net
B
Blog RSS Feed
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 聂微东
V
Visual Studio Blog
Apple Machine Learning Research
Apple Machine Learning Research
N
Netflix TechBlog - Medium
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Martin Fowler
Martin Fowler
有赞技术团队
有赞技术团队
Blog — PlanetScale
Blog — PlanetScale
Engineering at Meta
Engineering at Meta

山月

在VS Code配置Obsidian風格Markdown編輯環境 – 山月 在Windows通过LM Studio使用Zotero MCP – 山月 禁用WordPress中Jetpack的AI助手按钮 – 山月 WordPress/MCP Adapter安装与维护指南 – 山月 WordPress服务器权限与所有权配置详解 – 山月 在Windows上為GnuCash啟用線上報價 (Finance::Quote) – 山月 Gitea Docker /var/empty 权限问题除错总结 – 山月 Bookwyrm由0.7.5升级至Production(e217a17)完整过程及疑难解答 – 山月 用正则表达式修改ruby标签 – 山月 为WordPress Syndication Links插件添加新的站点与图标的实现方法 – 山月 进入不断重启的Docker容器的命令行之方法 – 山月 自建Bookwyrm无法查询远端用户?——开启数据库扩展 – 山月 BookWyrm无法增添书本、作者、阅读进度……?——解决数据库自增序列问题 – 山月 俾Docker容器中的应用访问宿主机上的数据库服务 – 山月 QNAP NAS使用者注意!千万莫对MariaDB做这件事…… – 山月 解决Wikibase手动导入数据后无法新建实体之问题 – 山月 辰年再訪神保町 – 山月 PHP-FPM站点池配置调优以解决WordPress过度占用系统资源之问题 – 山月 如果Linux软件包常规升级失败——以python3-update-manager为例 – 山月 解决站点526报错:SSL证书配置错误 – 山月 風挾着陽光來 – 山月 和A.N.R.GHG插件说bye-bye – 山月 WordPress页面链接末尾出现“?swcfpc=1”后缀,是怎么回事? – 山月 安装、维护Monica PRM的一些笔记 – 山月 清理服务器空间的着手点 – 山月 关于Joplin Server文件上传大小上限 – 山月 如何优化PHP文件上传大小:完整指南 – 山月 WordPress站点部分地出现“严重错误”的一些可能的解法 – 山月 批量更改WordPress媒体URL – 山月 自托管WordPress编辑文章出现问题的排查法 – 山月
一種美觀的由Hubzilla分享RSS資訊的方法 – 山月
2021-11-15 · via 山月

Hubzilla、Friendica的富文本鮮爲其他支持相關協議的社交媒體所支持。在這種背景下,由Hubzilla及其類似產品分享資訊流上的RSS/Atom內容時,由於不能使用常規的轉發、評論等互動形式,而只能引述,稍不注意分享的排版格式,發佈出來的內容恐便不美觀矣。

在引述RSS/Atom內容時,編輯器會默認把引述的原文內容以一端短代碼的形式寘於文本框最上端。如果一言不發,只想分享原文則已;徑直換行,在其下方分享感言的話,在點下「Share」鍵後,編輯器會自動地將引述的RSS/Atom內容短代碼print爲RSS/Atom內容摘要(動輒兩百字左右),甚至是原文全文(字數恐以千計)。在Hubzilla及其類似產品,由於引述原文被加以「share」標籤,視覺輸出上姑且會與用戶自己寫下的感想有所區別;但在不支持這類富文本的平臺(如Mastodon)上,無論是引述的原文,還是用戶自己真正想欲表達的感想,都是以同樣的格式、字號、顏色,被無情地依次臚列出,粗掃一眼看不出彼此分別,會令讀者產生「哪些是你複製的大段文字,哪些是你真正的感想」之疑惑。

若將引述的部分寘於最前端,而引述原文又過長(如數千字),則讀者需要劃拉半天纔可找到用戶所欲表達的內容。沒耐心者可能會直接將該內容(item)劃走,看別的東西去。

有些社交平臺、網站沒有設置長文折疊的話,這種長段內容還會爲讀者帶來困擾。

比較推薦的分享內容之排版、做法爲:

  1. 先說明自己「讀/看了什麼文章,講的是⋯⋯」
  2. 談自己覺得值得注意的地方,或者其他感想。
  3. 換個行,註一句「以下爲原文/摘要」,或者其他能夠起到分隔作用、令讀者明白引述內容要由下方開始的字符。
  4. 黏貼引述內容的代碼。

發布以後,可以看到引述內容實際被print out的樣子。一般來說print的順序是,有可讀取的原文摘要(兩百字許)則只print摘要,沒摘要纔大段大段貼出原文。如果自我評估原文過長了,再點擊編輯(受惠於Hubzilla極其類似產品可多次編輯內容〈item〉的特性;其實Mastodon也有類似改進被提交審閱了,期待推廣的那天),這時會發現引述內容的短代碼已經改頭換面,變爲由「share」標籤包裹的大長文了。摘出覺得重要的部分,不重要的刪之則已——除非認爲全文都有被archive下來的價值。再付保存。

需要注意的是,有些實例會拒否用戶做出的第二次及更多修改。如果會對引文過長無法在這些實例彌補有負罪感的話,可以一開始就不利用編輯器自己生成的引述內容短代碼,而是主動用引號或大於號標出事先複製好、想要分享給讀者的選段。最後附上原文鏈接。

本文僅談個人感受與建議,信耶否耶,全聽諸公高論。如果有更好的做法,或者有自己更習慣的做法,也歡迎交流。