您只在最近启用线程且客户端尚未在该更改后刷新过的频道中看到此问题吗？还是在线程启用后已经刷新过一次的情况下也看到？
我认为我们不久前也遇到过类似的问题并已修复。
也许它又出现了？如果您现在更新到最新版本的 tests-passed，是否仍然看到该问题？
2 个赞
我们所有的聊天频道最近都已启用。
我不确定用户何时或如何刷新了他们的浏览器。是否应该在安装了更新或管理员更改了系统参数时强制系统进行完全刷新？
我不知道您的用户，但我知道我们拥有的用户，要求他们刷新可能会导致他们询问这是否是某种食物。
现在将安装到最新版本，并要求我的测试用户观察。感谢您的回复。
4 个赞
您好！我真的很喜欢回复评论后立即生成新帖子的功能 
我建议假设新评论是对紧接其前评论的回复。这是对话中最常见的情况。人们通常会使用“回复”来指代对话中已经出现的评论，但当他们想回复紧接其前评论时，他们不会使用它。从一个人开始输入此情况的那一刻起，我将假定他们想要回复紧接其前评论并生成一个帖子（即使出现新评论，此功能也能正常工作，因此用户不必删除并重写）。因此，当人们开始输入时，上方会显示“回复（…）”，如果他们不想这样做，可以点击旁边的“x”。我认为这将简化流程并有助于保持频道整洁。
4 个赞
将聊天消息导出到 CSV 文件
很高兴看到其他人认真对待聊天并加以保存。现在我们可以获得聊天记录的 CSV 文件，这真是太棒了。如果此任务可以作为管理员设置自动处理，那就更好了。不过，这仍然是向前迈出的一步。
“聊天”的推动力和框架一直认为它是短暂的，不值得永久存储。也许它被视为一种绕过将“闲聊”纳入数据库的负担的方式？无论最初的动机是什么，显然人们希望保存聊天记录，并且正在采取措施允许管理员这样做。
我对进展感到非常满意，并期待它能得到完整的保存。
4 个赞
我先说一下，对于任何使用聊天式沟通的人来说，这有点显而易见——聊天是高度主观的，如果你只选择一个选项，那么找到“正确”的解决方案几乎是不可能的。
我倾向于将聊天线程分为两类：子空间和内联。
遵循子空间格式的平台会在有人回复消息时创建“口袋”，所有回复都保存在这个口袋里，除非有人点击进入，否则是看不到的。人们通常从 Slack 中熟悉这种方式，这也是我如何归类 Discourse 的聊天功能内置的解决方案。
内联回复将所有响应保留在主聊天线程中，并通过链接/锚点指向前文。对此有两种变体——带或不带引用的文本。带引用文本的例子是 Discord（它使用摘录而不是完整的引用）或 Apple 设备上的 Messages。Discord 在切换到当前格式之前曾有过无引用的内联回复。无引用内联回复的另一个例子是 Stack Exchange / Stack Overflow 上的聊天功能。
两者都是有效的，它们都有各自的用途，并且它们各自“解决”了对方造成的问题。
- 我发现子空间口袋……
- + 可以很好地包含一个横向的思路，或者允许深入探讨一个话题，而不会分散主要讨论的注意力。
- + 使这些支线保持整洁且易于遵循，但
- - 口袋很容易被错过，特别是当回复是在聊天已经转向其他话题很久之后创建的。
- - 更重要的是确保你通知了任何需要看到分支的人。
- 内联聊天则相反……
- - 因为一切都是内联的，所以很容易因为跑题而破坏聊天。
- - 同时跟踪多个讨论线可能会令人困惑。
- + 因为一切都是内联的，所以你不会错过子空间里发生的任何事情。
- + 用户不必费心去确保回复能通知到特定的人。
作为多年的 Slack 和 Discord 用户，我认为“正确”的解决方案可能是没有开发者想听到的——两者都要有。我发现对我来说，最大的决定因素是：
- 参与聊天的人数或活跃度如何。
- 如果我只和一个人聊天，或者活动不多，我想要的只是内联回复。即使有 2-3 个人，我也不需要子空间。我无法告诉你多少次我因为 Slack 的私信在两个人之间使用子空间而感到恼火。
- 如果我身处一个有很多参与者并且消息快速发送的空间，那么跟踪内联对话会变得更加困难，特别是当人们随意使用回复功能时。
- 我想/需要看到多少东西。
- 如果我在 Slack 频道中扮演支持角色，子空间可以使频道变得整洁，让我可以快速浏览。
- 如果我身处一个错过埋在线程中的任何内容都会很糟糕的空间，我更喜欢内联回复。害怕错过（FOMO）是真实的，朋友们！
- 线程的“深度”有多深。
- 倾向于在一个问题后有几十甚至上百个回复的频道应该使用子空间。
- 倾向于每个消息只有很少回复的频道通常内联效果更好。
- 我是谁/我习惯了什么。
- 我认识一个人，他创建了一个 Slack 脚本来删除子空间，因为他非常不喜欢它们。
- 我认识一些人，他们坚决要求他们的团队在 Slack 频道中每次都使用子空间线程，并且在没有使用时会有点生气。
这一切都说明，没有一种万能的（甚至是最适合大多数情况的）解决方案。我特意去寻找这个元帖子，因为我在另一个 Discourse 实例上进行了一对一聊天，并惊讶地看到了线程的选择，我真希望我能避免使用线程。
如果您想考虑提供这两种选项，这里有一些想法：
- 考虑一个用户设置，允许用户全局或按聊天选择他们偏好的样式。
- 考虑聊天空间的参与用户数量、消息频率和平均回复深度，以“自动”确定使用哪种形式——例如，使用内联，直到链中的回复达到某个数字，或者用户指示“将回复转换为线程”。
- 考虑“我正在创建对昨天/上周某事的新的回复线程”的情况，以及是否应该指示回复（或允许响应者像 Slack 那样内联发布回复）。
我认为你们现在拥有的已经很好了，但我很希望看到 Discourse 在这个功能的发展过程中考虑模糊这两种不同方法之间的界限。
7 个赞
非常感谢您深思熟虑且富有建设性的想法。
我们非常理解您的想法，并且我们至少已经多次考虑过您提出的绝大多数观点。我相当有信心，随着聊天功能的不断成熟并被更多用户采纳，这个问题将在不久的将来得到解决。
8 个赞
我认为，通过显示所有帖子的内嵌摘录（直到某个限制）可以很好地解决这个问题。因此，如果评论很少，它们都可以阅读，如果评论很多，一些将内嵌显示，这已经可以一目了然地快速了解对话（如果用户感兴趣，可以进入子空间）。
3 个赞
IMO，这也适用于论坛主题。我希望在列表的顶层看到第一个和最近的评论/回复的片段，以便于浏览。我构建并试验过一个类似的系统，通过持续关注最近的几条回复更新，就可以同时监控多个线程。（注意：这是对上面的帖子的回复，该帖子已合并到下面的独立帖子中）
我假设主题和线程在某个时候将成为相同的基本系统。这主要是用户体验/呈现方式的区别，对吧？否则，我们将不得不为两者重复许多相同的功能和能力。
1 个赞
我们目前没有计划将话题引入主题。这是一个纯聊天功能。
关于引入主题回复的现有讨论很多，如果您想在其中一个继续对话，可以吗？
我的意思是，带有主题的聊天与带有主题的论坛没有太大区别。随着新功能被引入 Discourse，我们自然会希望将其中许多功能应用于论坛帖子和聊天帖子，如果它们在底层是技术上相同的核心系统，这将更简单。
1 个赞
我也赞成融合，我认为这是长期来看最稳健的方法，通过认识到功能抽象的相同之处并以此来统一它们。例如，我曾提议将标签视为一种“元类别”。
1 个赞
帖子已拆分为新主题：无法回复聊天消息以创建主题
