我不这么认为
很可能如此，但如果是那样，那也是很久以前发生的事情，我记不太清了。
但这似乎是最合理的解释。
1 个赞
也许你更改了对 News and Events > Forum summaries 的跟踪设置？它默认是静音的，而且看起来静音类别的描述不会显示 
3 个赞
啊，确实，它被静音了。@Moin 你观察得很敏锐。我想那它可以变成灰色，这样看起来就不会奇怪了。
3 个赞
[quote=“Moin, 帖子：68，主题：396306”]
看起来静音的分类不会显示描述。[/quote]
这似乎很奇怪。会有理由显示分类却不显示其描述吗？还是这很可能是一个疏忽？
在使用新的分类体系一段时间后，我必须说，我并不喜欢它。新的组织方式并没有让我特别烦恼，但我还是更喜欢旧的方式。
在阅读了 Do users properly use categories? - #6 by Bas 和 Do users properly use categories? - #9 by noahl Discourse 论坛多年之后，我仍然认为更少的分类可能更有益，也更不容易让人困惑。
我更喜欢那些没有（或只有少量）子分类的组织方式。
当我们创建新主题时，这并不会真的造成什么摩擦，但我觉得很奇怪：我们可以在某些父分类（例如 Support）中创建主题，而在其他分类（例如 Contribute）中却必须使用子分类。
在帖子中链接分类或在搜索时自动补全分类，可能会生成非常长的字符串：
Community Building > Data & reporting, Documentation > Migrating to Discourse, News and Events > Forum summaries 等等。
特别是在移动设备上创建新主题时，基本上无法显示完整的分类路径。甚至连父分类也会被截断：
当然，新的组织方式并不是这里唯一的問題（参见 Creating/Editing a post on mobile: let's discuss the 2026 Discourse experience
我在搜索页面上特意使用了一个非常长的分类，但我甚至看不到我正在寻找的关键词，因为分类字符串占用了所有空间。
总的来说，我觉得像 #category:sub-category 这样的长字符串很难阅读。
而且在“分类”侧边栏部分：
我们有表情符号、图标和双色项目符号，这让我非常想起那些口香糖：
可能这里还有一些正在进行的工作，特别是关于只使用图标而不再使用表情符号，但即便如此，图标和双色项目符号的混合（有时看起来像单一颜色，例如 Contribute > Feature）仍然显得杂乱。
我理解当各个事项被归类到各自专属的空间时，这样确实更便于搜索精确信息。
我赞赏大家为改善用户和管理员体验而进行的协作努力，但到目前为止，我并未被这些最近的更改所说服。
5 个赞
有一件事让我感到有点沮丧，那就是我不再能通过输入 #bug 来链接到 #contribute:bug。这是因为其父分类阻碍了这一功能。
我通常不使用自动补全弹窗，更倾向于手动输入全部内容（更何况自动补全需要几秒钟才会显示）。因此，当 Bug/UX/Feature 位于父分类下时，我必须先回忆父分类的名称，然后才能输入。
5 个赞
我几乎找不到任何内容，无论什么问题，我最终都会去 ask.discourse.org 提问，哪怕是关于如何配置某个插件，或者查找我知道存在的文档。有时候，用 Google 搜索可能更明智。
想找 LDAP 插件？输入“ldap #plugin”却找不到它。它到底在哪里？是 #self-hosting/discourse-ldap-auth 吗？——Google 倒是能搜到。它实际上位于 Support > Self-hosting 分类下，并带有 discourse-ldap-auth 标签。所以，你必须猜测某个插件是否属于 #plugin 分类？什么时候一个插件不算插件？
说真的，每当我需要查找某些内容时，我最终都会直接去 ask.discourse.org。
我不确定我是否太在意把新帖子放在哪个分类里。我通常把一切都放在 Support 分类下，除非我觉得它和系统管理有关，那时我会尝试把它放到 Support > Self-hosting 分类中。
2 个赞
关于此问题的这个开放型用户体验请求或许可以再次提上日程：
能否让子类别的内联链接更简洁？ - 贡献 / 用户体验
3 个赞