您已经可以通过 CSS 来实现这一点：
// 隐藏侧边栏的标签部分
div.sidebar-section-wrapper.sidebar-section-tags {
display: none;
}
5 个赞
我认为理论是，如果有人有账户，他们已经知道社区是关于什么的了。
7 个赞
此主题下的帖子很多，因此如果我重复了之前说过的内容，敬请谅解……
关于新的通知结构，我有几点意见：
- 之前有人建议删除“全部”部分。我强烈反对。如果我必须浏览几个子部分才能看到所有通知，那将是巨大的倒退。
- 我也反对将“全部”部分按通知类型排序/分组的建议。子部分已经存在于此目的……“全部”部分应始终按最近顺序显示。
- 与此相关的是，我认为如果您先阅读了较新的通知，那么在您阅读通知后，“全部”部分中的通知会重新排序？我在这里收到的通知不够频繁，无法仔细检查，但我认为昨天我看到的就是这样。这似乎意味着最高优先级的排序标准是未读，但我仍然不知道我是否喜欢这样。我觉得“全部”部分应该始终按最近顺序排序。也许对于收到大量通知的人来说，“未读”部分会更有意义。
- 我对子部分的排序没有强烈偏好（我收到的通知不多，不需要使用它们），但我确实觉得将引用放在“其他”部分有点奇怪。也许只有我这么认为，但我认为引用与回复是相同的。（提及也几乎等同于回复。）如果有人引用我，99%的情况下他们是在回复我，但默认的 Discourse 设置会在引用了同一用户的回复时将其删除。考虑到该设置，将引用视为“其他”感觉很奇怪。
- 我认为通过合并回复、引用和提及来简化部分会很有益。不确定这是否适用于所有社区，但如果它们被分组，我更有可能使用该子部分。
- 我会做一个排序更改。书签本身并不是通知（当它们只是列出时，就像现在一样），所以我认为它不属于其他通知。因此，我想将该部分移到个人资料部分下方，如果需要，只需单独处理书签通知。或者，我想将书签、私信和个人资料图标放在前面（在“全部”通知之后），然后显示 hr，然后显示通知过滤器。这将模仿旧版本中的显示方式，过滤器只是最后添加的功能。
- 通知子部分列表应可滚动。在手机上回复此内容时，我无法看到整个菜单，除非完全隐藏编辑器。应该进行更改，以便如果我上下滑动手指，菜单会滑动。
6 个赞
我的第一印象是，我有点不知所措和困惑。主页突然变得_非常_繁忙。我的大脑花了几分钟才理解这个想法——哦，它实际上是同一个汉堡菜单，只是默认展开了，移到了左边，并增加了更多功能。
所以我想我能习惯它。
我确实觉得这个设计有点刺眼——大小不一，而且全大写的标题与主要设计形成强烈对比，而配色方案似乎_不足以_突出它。但所有这些都可以解决。
我的网站默认使用“分类和最新”视图作为主页，我相当喜欢——但这与侧边栏菜单有些_冗余_。我必须弄清楚如何调和这一点。
10 个赞
我赞成这个提议。它能做到两件事：简化令人困惑的界面，并使监视/跟踪类别和标签的想法更容易被发现。在 Fedora Discussion 上，我正试图让人们接受将标签[1] 视为传统邮件列表的替代品。这实际上是一个相当不错的映射，但人们习惯于在社交媒体或传统论坛[2] 中使用标签的方式来思考它。我认为在这里添加这个功能会有很大帮助。
作为奖励，这使得“跟踪”对于标签和类别真正有意义。[3]。
6 个赞
也许我们可以合并这三者，但作为起点，我认为将引用包含在回复子菜单中有意义。
5 个赞
最初，事情就是这样运作的——你需要跟踪或监视事物才能将它们添加到你的侧边栏。
我们发现有几种情况，人们希望从侧边栏轻松访问某些事物，但不希望收到所有额外的通知。这导致人们要么收到更多的通知干扰——要么——选择不将他们喜欢的东西放在侧边栏中。
所以，我们决定将它们解耦。
但我认为我们现在处于设计的中间状态。
我喜欢不必跟踪事物就可以将它们放在侧边栏中，但我同意，如果我确实跟踪了事物，那么将它们放在侧边栏中可能是合理的。我认为我们将来可能会朝着这个方向做出改变。
5 个赞
是否考虑过在总括性的顶级菜单项中使用“COMMUNITY”以外的词语？我对这个词的使用有点敏感，我知道这有点像“风车大战”和“自行车棚绘画”，但……我认为最好使用其他词。如果那个部分是“community”，为什么_messages_不是“community”？而且，这里有一个_命名_为 Community 的类别，那就更奇怪了。然后_Docs_和_FAQ_是“community”？
也许是 SITE MENU？或者，将_Everything_、_Tracked_和_My Posts_拆分为 TOPICS，然后将其余部分放在 NAVIGATION 或……其他什么地方？
5 个赞
但是“跟踪”不会触发通知，对吧？它只是显示未读或已读。事实上，正如我刚才尝试的那样，这种分离导致了一种行为，我认为这会让人们感到惊讶：如果你将一个类别添加到侧边栏，而该类别没有被监视或跟踪，它就会显示为空——就像你正在跟踪但实际上已经全部看完的内容一样。
我可能遗漏了某种我没有想到的使用方法，但这难道不是主要令人困惑吗？甚至没有指示哪个是哪个。
另外一个完全不同的问题：我希望有主题选项可以将“5 个未读”更改为仅显示数字（用圆圈或其他方式样式化）。因为在我看来，这可能也是导致我感到信息过载的原因之一。更少的文字可能有助于改善这种情况。
4 个赞
另一种风格需要一个主题组件，但文本更改可以通过自定义字符串来完成，在以下位置将“%{count} something”替换为“%{count}”：
js.sidebar.unread_count.one
js.sidebar.unread_count.other
js.sidebar.new_count.one
js.sidebar.new_count.other
在执行此操作时区分未读和新消息可能是一个好主意。
另外，在测试此功能时，我注意到我需要打开“消息收件箱”部分才能看到我有未读或新消息——如果在“收件箱”行上有一些指示会更好。
5 个赞
我们曾经尝试过，但总体上并不受欢迎，因为人们会混淆新帖子和未读帖子数字的变化。我们可能会重新考虑，但决定等到我们可以进行一些关于新帖子和未读帖子合并的实验，以便仅数字本身具有意义。
是的，我们也在考虑如何将其他部分的内容合并到部分标题中。因此，消息本身也可能有一个指示器。
5 个赞
哦，说到标题：我发现社区旁边的：heavy_plus_sign：会开启一条新消息，这让我非常困惑。
5 个赞
这是一个很好的观点，之前那个部分被称为“主题”（正如你建议的那样），那时更直观。我们放弃了那个想法，因为我们开始有了太多的不同部分，所以我们将管理/组/用户/等合并到了新命名的“社区”部分。
5 个赞
这真的很棒。它看起来干净，感觉“诱人”——我启用了它，并且不会再回到旧的汉堡菜单了。
我看到了很多建议和评论，但说实话，我真的很喜欢它。
我相信它会随着时间的推移而得到完善，但对于每个运行 Discourse 实例的人来说，尤其是像我这样自托管（和管理）的用户来说，我们刚刚获得了一个全新的菜单，否则这需要花费真金白银。
真是太棒了。
9 个赞
用户也这么想吗？因为……论坛毕竟是为用户准备的，而不是为管理员准备的，无论是否自托管 
4 个赞
抱歉引用我自己，但我一直在思考这个问题。这确实会是一个改进。
或者，它可以保持原样（也许窄一点），但一直显示在屏幕上，直到你点击一个“X”按钮，就像聊天窗口一样。
2 个赞
如果你点击汉堡包按钮（承认有点不直观），它就会完美消失。抱歉，不知道为什么我的屏幕录制是黄色/橙色的！
我希望有一个选项，可以默认将其最小化（也可以设置每个用户的默认值）。
2 个赞
谢谢，但我认为我们在这里沟通有误。我知道侧边栏以及点击汉堡包按钮时它会消失（我认为我在这里建议侧边栏应默认隐藏，以便用户可以凭直觉理解汉堡包操作而不会感到意外）。在上面的帖子中，我的意思是通知窗格/菜单不应在你点击其链接之一后立即消失——理想情况下，它应该是一个右侧边栏
2 个赞
哎呀——你说得对！我好像没怎么仔细看 
。
我不太同意。一直显示这么多东西会显得很杂乱。而且如果我想让内容打开更长时间，只需双击任何一个图标，它就会显示在主容器中。
2 个赞