在我看来，我认为 Customization > Theme component 标签作为子类别会更合适。至少对我来说，比起标签，它们更容易找到。近年来，主题组件相比其 Customization > Plugin 对应物变得越来越重要（其中许多正被转换为主题组件以方便使用）。由于缺乏更好的术语，它们值得……“平等”对待。毕竟，它们非常流行，如今已成为 Discourse 不可或缺的一部分。
希望您能考虑这一点。我不是以英语为母语的人，因此为我表达不够清晰而致歉。
完全同意！目前这一切都有些混乱。
我建议考虑设立一个专门针对扩展的新类别，包含以下子类别：
- 主题
- 主题组件
- 插件
- 附加组件
然后，我将把现有的“损坏”子类别合并为标签。
您怎么看，@JammyDodger？
9 个赞
我觉得很好！我全力支持。
5 个赞
为了简化，我想知道是否可以更进一步，将类别标记为“自定义”，然后将这四个标记为标签是否更合适。
我确实同意，如今主题组件对大多数 Discourse 站点来说更有价值。
7 个赞
我认为这种表述会造成混淆。Admin->Customize（管理后台->自定义）仅适用于主题和主题组件。Customization > Theme 包含了所有可以通过该界面引入到站点的内容。
我们目前已经看到一些用户将主题放入 YML 文件中，并试图通过界面添加插件的 git 仓库，偶尔会出现问题。消除这种界限只会让这类错误更有可能发生。
插件确实需要保持其独立的类别，不是吗？
7 个赞
在我脑海里，主题组件和插件之间的区别已经变得模糊了。
我相信，任何能帮助大家更好地区分两者的举措，都将大有裨益。
这有点好笑。长期以来，WordPress 开发者一直在纠结该在哪里包含功能，并争论代码究竟应该属于“主题”还是“插件”。如今，这种争论几乎显得有些过时了，因为一切都变成了 JS 代码块。但由于与核心软件的关系，我们仍然需要确定代码应该放在“插件”还是“区块模式”中。
我从未在 Discourse 的插件中产生过这样的困惑，主要是因为多年来大家想出了一些非常棒的主题组件技巧。如果有人问我“插件”和“主题组件”有什么区别，我第一个念头会是：一个需要输入 URL 来安装，另一个则需要重建站点。
3 个赞
是的……我猜对于初学者来说，区别很明显，尤其是当你看到这样的主题时：
“我做了一个插件” 接着是 “我用主题组件做了完全相同的东西” 
4 个赞
而且它会是这样，因为区别在于如何安装某物。而不是目的。这就是开发者看待周围世界的方式 
3 个赞
我认为该插件是第一个
关于标签的说明：似乎比忘记选择分类更容易忘记标记主题。已经有一些未标记的主题了。
3 个赞
我非常愿意对分类和标签进行一次健康检查。 最近确实有一些不错的建议，提议对结构稍作调整，所以我会把这些意见汇总起来，看看最终结果如何。
我认为任何能让 Meta 对新用户或偶尔使用的用户更直观的事情，都只会是好事。
现在有了专职的社区管理员，这个问题应该会少一些。（
）我认为我一边整理一边组织应该能解决大部分问题。而且我们有不少 TL3 和 TL4 级别的用户，所以希望强化一致的模式能让其他人也更容易参与进来。
我仍然将其视为前端与后端的变更，但升级到 Ember 后，这对我的含义也变得模糊了。 似乎这让主题和主题组件能够实现比以前多得多的功能（如果你托管且没有便捷途径添加插件，这非常棒:+1:）。
我认为这对非开发人员来说是一个非常有用的区分。 红色代表 /admin/customize，黄色代表 app.yml。如果你是一名安装现有自定义内容的管理员，而不是想要创建新内容的开发人员，这大概就是你真正需要知道的全部了。
感谢你的建议 @Decorbuz 我会整理一些想法，看看我们能做些什么。
5 个赞
同样的问题，智能手机是电脑还是不是。界限不再那么清晰了。
这就是为什么每个论坛都必须做出逻辑选择来安排事物：要么根据想法或用途（用户体验和目标很重要），要么技术解决方案更重要（开发/代码基础思考）。
没有对错之分，只要用户能找到他们想要的东西就行。
嗯，偶尔也会有错误的解决方案。将健康的插件/主题/组件与损坏的组件混合在一起，以至于你必须找出正确的标签，这真是一个非常非常糟糕的主意 
而且，通常还有一个管理员经常犯的错误，如果我没记错的话，甚至连 Meta 的 tag-doc 或类似的警告都在说：分类不会产生内容，但空闲或流量低的分类只会让事情变得混乱。
3 个赞
现有的语言已经让初学者感到困惑，所以肯定需要做出改变。
2 个赞
缺乏清晰度并不一定意味着需要合并，尤其是按照上面 Justin 建议的名称进行合并时。我们同样可以为每个类别添加更清晰的说明，从而解决部分歧义问题。
Customization > Theme 和 Customization > Theme component 封装了可在运行时进行的预打包自定义设置。
Customization > Plugin 主题需要重新构建，并且只能由拥有 root 权限的用户执行。它们属于风险较高的更改，会影响站点的可用性。
6 个赞
我也这样认为。如果需要对后端（ruby代码）进行某些更改，无论是将某些内容存储在数据库中还是更改某些API行为，您很可能需要一个插件。
如果更改仅是UI，最好从主题组件开始，如果事情变得更复杂，并且最终需要后端更改，则稍后回退到插件。
我喜欢这个主意。它比带有不同标签的单个类别更复杂一些，但我喜欢在这些不同的自定义元素之间建立更强的界限。
主题可能仅关乎外观，而插件则需要访问机器上的操作系统才能安装。它们是非常不同的事物，合适的类别允许例如该类别中的第一个主题为新用户提供关于它们之间差异的上下文。如何安装、开发文档等。
5 个赞
我的愿望成真了！
虽然它不是一个子类别，但我对这个变化仍然非常满意。
3 个赞
这是它：
感谢 @Decorbuz 的建议
5 个赞
此主题在上次回复后 24 小时自动关闭。不再允许回复。