在最新的更新后，Discourse 突然发送邮件，邮件前缀是：
“Someone replied to a topic you are Watching.”（有人回复了您正在关注的主题。）
我的所有用户都在强烈抱怨，而且没有用户更改任何邮件设置。
所有人都说这非常烦人。
那么，发生了什么？我们如何才能关闭它并恢复到正常的纯文本行为？ 我认为这个改动没有做好，而且开发者甚至没有注意到它，因为“watching”中的 W 用了大写，这是不必要的。
我认为让 Andrew 社区成员感到恼火的根源是 %{header_instructions}。
该令牌会扩展成一大段样板文字（“请勿回复……”、链接、说明等），并且它会出现在许多通知模板的邮件正文的最顶部。对于有经验的用户来说，它会主导整个信息，读起来像是唠叨而不是帮助。
目前没有全站范围的设置可以禁用或移动它。要删除它，管理员必须在“管理”→“邮件”→“模板”下单独编辑每个邮件模板。
在当前的 latest-release（我使用的是 latest-release +17）上，应该可以通过一个 Rails 脚本来集中解决这个问题，针对那些已经有数据库覆盖的模板，例如，从正文开头出现的 %{header_instructions} 中删除它。这部分很简单，使用了 EmailTemplate 模型。
将同样的更改应用于所有默认模板（包括那些尚无覆盖的模板）将需要通过内部查找 API 拉取默认模板正文，从而创建覆盖。这是可行的，但这取决于 Discourse 的内部机制，并且在广泛推荐之前需要维护者进行审查/验证。
因此，根本问题不仅仅是 %{header_instructions} 的内容，而是它实际上是全局的样板文字，却没有管理员级别的开关，删除或移动它需要逐个模板进行手动操作或使用不受支持的脚本。
@Ethsim2 谢谢，这真的很棒。但为什么会突然改变呢？我不是阅读或查找更改日志的专家。
@Andro 是的——这是一个完全合理的问题。
之所以说是“突然”出现，是因为 %{header_instructions} 不是您本地更改的内容：它是 Discourse 注入到许多通知邮件中的一个核心提供的块。如果核心更改了措辞或包含它的时机，即使没有触动任何管理员设置，每个人也会立即注意到。
我不想在没有具体提交引用的情况下过度断言，但最可能的原因是核心最近更改了 %{header_instructions} 展开为的默认文本（例如，添加了“有人回复了您正在关注的主题。”这一行），或者更改了该块包含在邮件正文中的时机，针对的是“正在关注的主题”通知。
如何确认来源：
- 在“管理”→“邮件”→“邮件设置”→“模板”中，查看您的用户收到的通知模板（正在关注/已跟踪/已回复/已提及）。
- 如果正文以
%{header_instructions}开头，那就是新的前置文本的来源。 - 删除它，或将其移到
%{message}/%{context}（甚至%{reply_instructions}）的下方，将恢复到以前的“纯文本”行为。
不幸的是，目前没有一个站点范围的开关可以控制此项。每个受影响的模板都必须单独调整，这就是为什么当核心行为发生变化时，这会显得很突然且难以控制。
如果您使用的是托管的 Discourse，实际的解决方法是只编辑您的用户实际收到的那少数几个模板，而不是全部。
1 个赞
这些预览是在几天前添加的
3 个赞
那么，仅仅从模板中移除 %{email_preview} 就能解决这个问题吗？
1 个赞
“Watching”一词在指代特定的 Discourse 功能时通常会大写。
我总是在关注有趣的主题出现。但我正在“Watching”某些主题以获取任何新回复。
2 个赞
然后是跟踪等，如主题通知状态下拉菜单中所示。
说实话，我不会想到这一点。我明白了，但这在某种程度上有点不寻常。
1 个赞
谢谢，这有道理。
因此，在这种情况下，Andro 看到的突然变化来自于最近添加的 %{email_preview}（PR #36657），这解释了为什么它会在一夜之间出现而没有任何管理员更改。
从管理员的角度来看，痛点无论如何都相似：它是注入到邮件正文顶部的核心内容，目前没有全站开关可以禁用或重新定位它。今天的唯一解决方法是编辑受影响的邮件模板并删除或移动 %{email_preview}（就像 %{header_instructions} 一样）。
特别是对于托管客户而言，这就是为什么这感觉很突然的原因——默认设置已更改，但没有受支持的全局控件。
预览字符串也可以被覆盖——你可以搜索特定的字符串或 .preview，然后按 Ctrl-F 搜索 user_notifications 来找到它们。
根据提交信息：
对于 HTML 电子邮件，此预览文本将使用
display: none隐藏，以防止它出现在电子邮件正文中。对于纯文本版本的电子邮件，它将出现在电子邮件正文中。
此消息出现在哪些用户那里？它不应该出现。
在我的邮件客户端中，我在源代码中看到：
<div> class="email-preview" style="display:none"> <p>Someone sent you a PM.</p> </div>
并且它在 Thunderbird 和 Gmail（网页版）中都是隐藏的。
2 个赞
供参考，这是新的预览文本在 Outlook for iOS 上向我显示的方式——它不仅仅是一个收件箱片段；它成为与邮件相关联的第一个可见行，这也是用户做出反应的原因。
![Outlook for iOS 邮件截图，显示“有人回复了您的帖子。”醒目地出现在邮件内容上方，可以看到 FW/[PM] 前缀](https://d11a6trkgmumsb.cloudfront.net/original/4X/9/1/f/91f715903dc7d1007a38043b45ed779ae5c6fe6d.jpeg)
这似乎与最近添加的 %{email_preview} 一致：即使它旨在作为 HTML 邮件的隐藏预标题文本，但在实践中，用户（至少在某些客户端/投递路径中）非常容易看到它，这就解释了突然出现的抱怨。
这可能是故意的，因为它将电子邮件的原因呈现在消息预览中。我猜如果没有它，消息预览通常没有用处？
这很有道理，我同意拥有一些有意义的预览文本通常是有用的。
用户似乎正在反应的问题（至少在 Outlook for iOS 和类似客户端中）是，此预览文本不仅影响收件箱摘要——它在视觉上被当作消息正文的一部分，出现在实际内容之前。在实践中，这感觉是重复和嘈杂的，而不是有帮助的。
当前的措辞也存在一些矛盾：从隐私和截图分享的角度来看，匿名措辞（“有人回复了……”）是有帮助的，但在日常使用中，它不如发件人感知的预览信息丰富，因为用户主要想知道谁回复了以及是否需要关注。
因此，问题不在于预览文本是否应该存在，而在于当前相当僵化的实现是否会损害某些客户端或投递路径上的阅读体验。一种客户端敏感的方法，或者一种支持的重新定位或禁用它的方式，可能会解决大部分抱怨，同时不会失去改进预览的好处。
1 个赞