我将最后一次尝试“无标题”的建议，然后就此打住：我认为这一部分不应该像其他部分那样呈现，因为它本质上是不同的。其他部分是逻辑分区，基本上将相同的东西归类。这一部分是一个大杂烩。所以，“无标题”在概念上是最好的。/结束尝试
好的，这一点我将更坚决地争取。虽然我用幽默的方式表达了，但我真心、非常认真地认为，将菜单顶部的难以归类的项目标记为“社区”是有严重危害的。
它贬低和滥用了一个已经被滥用了很多的词，但对我来说，这个词意味着重要的东西——对我来说，它是我人生工作中一个重要的组成部分（我知道，_戏剧化了，但我很认真）。社区意味着**人，而且不仅仅是任何随机的人，而是有共同兴趣的人**。这非常非常重要。
当听到“社区”用来描述营销群体（如果有什么的话）而不是真正的社区时，我可以翻白眼。当人们将社区的概念与“我们有一个论坛供人们发帖”混淆时，我可以试着温和地纠正。或者，当开源项目中的某人谈论“社区”是指_用户群_时，我们可以就哪些用户子集构成真正的社区，以及开发者（或公司支持者）_是否_是该社区的一部分进行一次_好的_对话。
但这种情况比上述任何一种都糟糕——它故意使用“社区”来表示没有任何意义。“其他”或“杂项”似乎更糟，因为它们直截了当地表示“我们不知道该叫什么”，而如果你眯着眼睛看“社区”，你可以将其溶解为某种程度上涵盖了：
- 所有帖子 [1]
- 我发布的帖子 [2]
- 群组（用于访问控制？默认值？什么都没有？取决于网站！[3]
- 所有用户列表 [4]
- 徽章 [5]
- 周年纪念和生日 [6]
- 文档 [7]
- 关于 [8]
- FAQ [9]
但讨论类别、聊天频道、标签_却不包括在内？
我认为“其他”和“杂项”之类的建议_似乎_是错误的，因为它们太直白了。将这样的东西放在顶部似乎不好。“社区”则可以绕过这种反应，因为你把它当作什么意思都不重要。请不要这样做。
此外，你现在已经消耗了这个标签，以至于它不能用于其他任何地方。我能看到这里有三种主要情况：
- 如前所述，许多网站将_整个论坛_称为“社区”。我认为这是一个错误 [10]，但至少是可以理解的：_整个论坛_都是为了让社区互动。但现在，你已经将标签应用于一个奇怪的子集。
- 对于其他网站，一个_不同的_子集可能才真正适合称为社区。例如，存在开发者和社区分裂的情况。（这非常普遍！）或者，你可能想将社区相关主题作为一个类别。或者，你可能有一个关于_不同本地社区_的论坛。正如我在上面提到的，我可以轻松地想到一些构建 Discourse 论坛的方法，其中_群组_就是社区。或者标签！但现在，同样，标签已经被占用了——充其量，我会有令人困惑的重复。
- 该论坛可能是_更大_的社区的一部分。该链接应该“向上”指向任何它所代表的东西。
当然，这些网站可以更改文本以供自己使用，但 1）它们现在与 Discourse 的其他宇宙不一致，2）这实际上是将问题推给了其他人。
你要求“一个明显更好的选择”。我认为这是一个不公平的标准。或者更确切地说，我认为_任何_不具有破坏性的东西都跨过了这个标准。我仍然非常相信第一个想法 [11]，但我说过我不再争论了。所以，让我提供一些我认为有建设性的替代方案：
……如果必须的话，可以随意使用任何一个的同义词。我认为它们都“明显更好”。
如果你坚持要在这种设计中使用某个标题标签，但_似乎没有一个词_合适，那可能表明存在第三种可能性——存在根本性的概念问题，而设计需要更大的重新思考。
但无论你选择什么：请，请，不要像现在这样。
"一切"如果你属于_论坛=社区_阵营，是有道理的。请不要硬编码。对于像 Fedora 这样的社区，“社区一切”应该远不止 Discourse 帖子。我可能会期望它指向项目组织结构图或类似的东西。 ↩︎
我是一个社区吗？ ↩︎
可能相关——但也许在某些情况下，群组应该是“社区” ↩︎
好的。是人！另一个也可以是“社区”——顺便说一句：在我的网站上，我已经将其更改为“用户”。这是因为虽然“用户”从_Discourse 开发者的角度来看_是完全有意义的——网站上的所有账户都代表_Discourse 用户_——但对于任何_关于产品_的网站，“用户”应该是_产品的用户_，而这可能根本不是所有 Discourse 账户！ ↩︎
我想不出这个与社区有关的理由 ↩︎
好吧，当然——人们有这些 ↩︎
非常错误 ↩︎
只有在“论坛=社区”的概念下才是正确的 ↩︎
与关于相同，但更奇怪 ↩︎
不是因为过于较真而错误——而是因为这_错失了潜在的可能性_ ↩︎
这个部分概念上不应该有标题 ↩︎
如前所述，如果可编辑效果最好 ↩︎
或 Miscellaneous 或 Misc ↩︎