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