Just make it a user preference/zh

我们这些编者经常说「-{zh-hans:把它搞成个设置; zh-hant:只要做個使用者設定即可;}-」之类的. 本清单/企圖旨在总结这一想法的一些复杂性，给出其难处和益处.

难处
多余的设置都会：
 * 1) 提高（核心/扩展）代码的复杂度
 * 2) 提高出现 bug 的机率
 * 3) 增加要做的程序维护工作
 * 4) 成倍增加需要被测试的情况
 * 5) 使设置变得更复杂，让萌新找不到各种玩意儿
 * 6) 增加需要翻译的东西
 * 7) 增加已经要把人压垮的文档
 * 8) 给已经太大的用户选项数据库再加几行（）
 * 9) Adds to the quantity of things that need to be considered, when contemplating any additional new features in the same feature-set
 * 10) 让我们更难找到 bug
 * 11) 要避免缓存碎片化

所以，开发者、设计师、老板、啥啥啥都不太想把所有要求要有的设置加上！

益处
就算这样，我（们？）很爱设置. 我感觉火狐的选项，至少对于超级用户来说，刚刚好™！

以下是我之前在讨论：重新设计用户设置写的东西：



《选项颂/偏好赞/设置夜曲/配置呐喊》
我想让我们的Special:参数设置菜单分类得更好. 这样它就能成长，吸收一些编者永远需要用的微调与工具——也就是那些重峦叠翠的社区在过去20多年中不停地建造、创造、完善的东西. 这样新手不被压垮就能找到他们想要的东西，而新的高手能找到他们不知道自己想要的东西.

--

When I sign up for a new website, I immediately go to the settings menu to see: What things I can turn on, and what I might want to turn off (either now, or in the future). When I install a new program, operating system, or game, I immediately look through the Toolbar and the Preferences/Options menu. They tell me a lot about the software, e.g.:
 * Technical vocabulary (concepts, keywords, and groupings),
 * which settings the developers thought were "useful enough to include, but not crucial enough to set as default",
 * which options the specialized-power-users might need, that I might want to investigate or use once I become proficient with the basics.

--

This wiki endeavour, requires tools that are as complicated as Photoshop or Autocad, for many editors but not all. Newcomers often need something simple, as do casual-editors.

We need something like Photoshop for power-users, as well as something like MS Paint for the newcomers and casual editors.


 * (MS Paint is great! It's Welcoming, and easy to learn via experimenting, and easy to create simple (sometimes even complex) projects in!)
 * (Photoshop is great! A dense abundance of menus, and a profusion of tiny and detailed-metadata, for those who need it! For those who spend many hours every day, for many years, working hard within it.)

We want and need both ends of the spectrum, and a migration path for users to slowly learn about bits of the complexity without being overwhelmed.