模板讨论:DYKEntry

模板的Type参数很诡异

其实模板代码中根本就没有type参数，可是文档中又有，很是诡异！而且也不知道type里面要填写些什么，没有说明，让人一筹莫展。———— Sumtec（赞美 骂街 讨论 察看贡献） 2010年12月6日 (一) 06:11 (UTC)

WP:DYKC回应格式错误

WP:DYKC使用的{{DYKEntry}}如果侦测到时间大于7天或{{{result}}}参数不为空的话，会自动跑出一个折叠的框，但如果回应的格式错误的话，框可能会框错地方。目前投票须知的地方有提到：投票者请使用**号，大家投票是都用**号没错，不过回应就有人会用::号，正常来讲同一篇DYKC的讨论下面每条讨论皆需要以*开头，如*:才是::的替代方式，这样才不会让系统框错地方，也不会有人的投票前面会有两个点造成不美观了。希望可以把这个东西写在投票须知中。tntchn ^{對話 · 貢獻} 2013年2月8日 (五) 17:56 (UTC)

有格式强迫症就动手改改吧。很多人不是不会，而是不在乎。--Kuailong™ 2013年2月12日 (二) 15:21 (UTC)

DYK提报时编辑注解的调整

现在的注解是这样的：

==== ==== {{ subst:#invoke:Template:DYKEntry|normalize | article = | question = | image = | type = | author = | nominator = {{subst:REVISIONUSER}} | timestamp = {{subst:#time:U}} }}

诸位看到这里似乎觉得没毛病，但我想指出一个现象，虽然不多，我认为仍有必要指出，举例：

==== ==== {{ DYKEntry | nominator = 和平奮鬥救地球 | image = | question = '''[[李屑清|哪一位清末民初著名實業家]]'''是香港電影事業家[[李祖永]]之父，父子二人曾共同捐建[[復旦公學]]圖書館？ | timestamp = 1473385734 | author = Ghgg56 | type = Biography | article = 李屑清 | hash = 1f8ae42c1b05c9ef0af810c6f6abbe330a75007c | result = }}

这里参数上主要的差异就是|nominator，而目前编辑注解里没这个项目，我认为有必要添加上并写好参数说明。虽然很多时候不会有这种情况，我觉得还是有必要的。如果用不到的话其实不填这个参数就行。-- 晴空·和岩 讨论页·反互煮·协作计划 2016年9月10日 (六) 12:40 (UTC)

nominator英文意思是提名者，也就是说就是提出申请的人，一来记录提出人，第二，可能，用于判定提出人和推荐条目主编是不是同一人？这个值应该是根据编辑记录自动生成记录的。可以说明，但不用手填。——路过围观的Sakamotosan 2016年9月13日 (二) 00:58 (UTC)

这个以前是放{{UpdatedDYKNom}}的，现在启用Flow了不更新user talk了，这个参数也基本没用了……Liangent（留言） 2016年9月15日 (四) 00:27 (UTC)

1、现在还有人使用这个参数 2、同一人就只填写 | author =参数即可-- 晴空·和岩 讨论页·反互煮·协作计划·中秋佳节 2016年9月15日 (四) 04:37 (UTC)

但机器人完全会忽略这个参数。Liangent（留言） 2016年9月19日 (一) 04:05 (UTC)

模板本身还在使用，用来判断提名者和主要编者是不是一样的，用来判断自荐还是他荐？——路过围观的Sakamotosan 2016年9月19日 (一) 04:21 (UTC)

我认为是用来判断“自荐还是他荐”的用途-- 晴空·和岩 讨论页·反互煮·协作计划 2016年9月22日 (四) 10:51 (UTC)

DYKC的type参数

撤回提案；我提另一个。산모사 ^DC17_{GAC FLC} 2019年8月5日 (一) 13:45 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

---

原标题为：提议废除DYKC的type参数

如题。Σανμοσα 2019年6月24日 (一) 09:36 (UTC)

理由？另外，上面我说“不再倚赖type”的方法只是在研究阶段，连可行性都还不确定，现在提废除根本言之尚早。--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月24日 (一) 09:53 (UTC)

同上。另外我还能够想出一个反例，不过八字没有一撇，先不提了。--春卷柯南编辑数突破二万 ( 论功行赏·刻石留名 ) 2019年6月24日 (一) 10:49 (UTC)

• 不支持。无论如何把判断条目类别的逻辑全部硬编码到程序里不是好事情。设置参数的目的是为了合理控制上首页的条目的多样性。但是什么叫做“合理“并不是一成不变的。想象一下，如果某种类型X的条目平时不多见，但是偶尔由于活动突然涌现了一批X类型条目，那么临时限制一下X的流量是合理的；但是如果维基上突然出现一批X爱好者，每天贡献一半的DYKC提名，那么我们别无选择，只能将X细分。与其纠结“type参数该不该有这种问题”，还不如维护一个列表，告诉新手老手“type参数应该怎么填”。为了解决这个问题，只需要写一个单独的模块就够了，这个模块可以被DYKC提名页面的提示模板使用，以提示编者参数该填什么；也可以被DYKC提名模板使用，如果type参数不填或不合规范，则自动报错，不给显示内容；还可以产生信息供bot初始化，每次更新DYK前动态加载一次。同时如果DYKC的提名情况发生了变化也可以及时调整模块内容，而不必依赖bot操作者。--Antigng（留言） 2019年6月24日 (一) 19:55 (UTC)
• 对于DYKC说明页和提名模板，这个模块的逻辑是很简单的，只需要告诉它们哪些参数能用就是了。但是对于bot来说情况就有点复杂了。想象一下当参数调整以后，bot并不知道当前DYK模板上的条目的类型在新参数下会被描述成什么，就可能出问题。一个解决方案是，将模块中的合法type参数实现为树，从根节点出发，逐步向下分类，每个节点包含一个或多个参数(别)名，并对每个参数名明确标识可以引用与不可以引用。这样:

1. 合并多个参数时，只需要将新的合并以后的参数设置为老参数所在节点的父节点，再将老参数标记为不可引用；
2. 拆分一个参数时，只需要为老参数所在节点设置子节点，并将所有老参数标记为不可引用；
3. 新增一个参数别名，只需要增加一个别名即可；
4. 删除一个别名，只需将别名标记为不可引用。

• 于是bot只需要检查别名对应的节点到根节点的路径是否重合即可判断两个提名的条目参数是否重复。--Antigng（留言） 2019年6月24日 (一) 20:16 (UTC)
• 然后可以再考虑复杂一点的情况，如果bot崩溃了，怎么知道当前DYK模板上的条目属于什么类型。一种解决方法是，强制DYKEntry模板加type参数，合法参数的列表仍然从模块取得。--Antigng（留言） 2019年6月24日 (一) 22:05 (UTC)

我先说明一下为何我提议废除DYKC的type参数：

1. type参数的规范化没有共识，使使用type参数维持多样性的可行性降低（@Antigng：之前有过类近“维护一个列表，告诉新手老手‘type参数应该怎么填’”的讨论，但无疾而终，你可以问一问Cdip150为什么）；
2. 使用type参数维持多样性未成为明文规定（@Antigng：之前也有过设使用type参数维持多样性为明文规定的讨论，但也是无疾而终，你可以问一问Cdip150为什么）；
3. 1导致胡乱填写type参数的问题也没有对应规范，使使用type参数维持多样性的可行性再进一步降低；

综上，type参数只对bot有用，却对人无用，甚至为人带来“type参数应该填什么”的困扰，所以我认为在1和2的前提下，type参数应该废除。Σανμοσα 2019年6月25日 (二) 00:22 (UTC)

如果真的要保留type参数的话，type参数的规范化和将使用type参数维持多样性定为明文规定缺一不可。Σανμοσα 2019年6月25日 (二) 00:25 (UTC)

• 问题1、2、3一次性解决的方案就是利用技术手段限制错填的可能性。如果填错，就不给你显示任何东西，连问题都不显示，或者更极端一点，显示加粗加红的报错文字，我看谁还会填错。一个很明显的例子是，站内没闭合的noinclude模板比includeonly模板多多了，为啥？includeonly不闭合下边的内容全显示不出来，难看得要死，noinclude模板不闭连个警告都没。人是靠不住的，能用技术手段限制死的东西就要用技术手段限制住。于此同时，加大提报DYKC小工具的宣传力度，逐步引导新手老手采用半自动工具提报，既方便又安全。--Antigng（留言） 2019年6月25日 (二) 00:29 (UTC)
  • User:Antigng但之前的讨论中有人明确反对用这样的手段（以至任何手段）限制，所以最终未能够实行。我真的不是不想做，而是没有共识基础让我做，所以现在我们要做的就是取得这方面的共识。Σανμοσα 2019年6月25日 (二) 00:32 (UTC)
    • 不想做无非是不方便呗。半自动工具做好了，难道不比手动提报方便？想想现在还有几个用户手动提CSD，AFD的。--Antigng（留言） 2019年6月25日 (二) 00:34 (UTC)
• 要知道当初没机器人的年代是由管理员亲自决定哪2个条目不适宜同时上架，严格来说，分类的责任应该是管理员而不是编者，后来设立的type，当初也只是给管理员在非常必要的时候才用，而不是给编者的要求（又或者说type的使用性质其实和hash和result那些一样，是管理用途）。仅仅为了管理上的方便，要求编者连管理员负责做的事情也要做，就算您有一个表给编者选，其实也是变相把这种责任转嫁编者，本身我就已经不见得合理，所以“强制DYKEntry模板加type参数”是我极反对的事情，因为这是在把责任推卸。--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月25日 (二) 01:50 (UTC)
  • 在古早的年代没规则，DYKC的甄选到上架一系列流程全靠管理员完成，现在又是社群投票又是bot自动处理，难道是管理员推卸责任么？说到底，作为一个志愿者维护的协作计划，强行追究起责任来没什么意义。用“半自动工具的便捷”换“提报时加分类的举手之劳”，难道还不够么？--Antigng（留言） 2019年6月25日 (二) 02:11 (UTC)
    • 您提到的那些是社群在要求权利，而不是管理层主动下卸，条目内容必定是由社群中的人士写的，所以社群要求投票甄选条目内容也要由社群自己负责，此乃正常不过的事；但是type我不见得也有这种特质。要求人家做对某事之前，请先想想人家本身有没有责任或义务去做某事，如果人家没有这责任或义务，您不能阻止他做错。--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月25日 (二) 02:26 (UTC)
      • 2007年以前也没有引用模板，用户写条目加个裸网址就OK了，现在怎么建议条目作者使用cite模板，还不建议使用裸网址呢？作为一个就是想写条目，不管来源的美观程度的用户，他又有什么义务扩充裸链接呢？作为协作计划，自动分担责任才是正常不过的事情，过分强调义务可不是。--Antigng（留言） 2019年6月25日 (二) 02:39 (UTC)
        • 不同意这个比喻，一直以来编者本身是有义务避免裸连接，造模板的主要目的是为了方便他们避免，不是为了管理员省去责任。--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月25日 (二) 04:22 (UTC)
          • 但我参考了之前的讨论，也有为数不少的用户同意规范化type，那就意味着他们愿意把这个义务转移到他们自己身上，那我看不到理由要阻止规范化。这可以说是我们普通用户在减轻管理员负担上的一个苦心。Σανμοσα 2019年6月26日 (三) 10:19 (UTC)
          • 又或许这样说：我认为Cdip150反对规范化的原因是他非常热爱管理员的工作，对此我表示非常理解。Σανμοσα 2019年6月26日 (三) 10:26 (UTC)

其实既然用bot维护，那么type这个功能，为什么不能用专题来替代呢？根据条目所属专题的不同来区分条目类型是否会比较方便？（一个条目属于多个专题的话，所属专题相同的越少，则条目类型差异越大）毕竟type比较随意，而专题则相当固定。--百無一用是書生 (☎) 2019年6月25日 (二) 02:31 (UTC)

Shizhao的方案正正就是我在考虑中的其中一个办法。--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月25日 (二) 02:35 (UTC)

专题似乎更麻烦：要求提名的用户给条目讨论页及时挂上专题评级模板。而且专题模板可以挂（很）多个，对bot制作者带来的麻烦大概也更大。--Antigng（留言） 2019年6月25日 (二) 02:39 (UTC)

又想省事，又想规范，这本身就矛盾啊。--百無一用是書生 (☎) 2019年6月25日 (二) 03:43 (UTC)

其实省事只限用户参考type来选择评选哪些条目和管理员如何排定上首页的次序，规范才是我的主要目的。Σανμοσα 2019年6月26日 (三) 10:13 (UTC)

为什么要把type变得更复杂呢。我觉得现在的type就可行，当然type规范化也很好，如果规范化还允许别名的话，是麻烦一些。另外我也不觉得type只是给机器人看的，人也可以看的。--1=0，欢迎加入WP:维基百科维护专题 2019年6月25日 (二) 02:38 (UTC)

规范化的一个好处是把分类存档的问题也解决了。过去Liangent-bot工作的时候只能把条目存进“未分类”里。--Antigng（留言） 2019年6月25日 (二) 02:42 (UTC)

当上到{{DYK}}时，type是不可见的，所以人是不可以看的。而且就算给您规范type，如果某条目仍同时符合了多个type，那一样还是为编者带来烦恼。这之所以我想找type的替代品，因为这根本还是在劳烦编者，纵使劳烦程度可能不严重亦不太想看到。在我而言，对编者要求做的事情越少越好。--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月25日 (二) 02:56 (UTC)

上边的有一条建议是把type加进{{dyk}}模板里。如果愿意的话也可以让参数变得可见。显示效果例如：该类型对应的特色icon+分类名+冒号+问题。--Antigng（留言） 2019年6月25日 (二) 02:49 (UTC)

读者浏览首页时才不会想理首页上的条目是什么类！--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月25日 (二) 03:07 (UTC)

哈哈哈哈，我也这么想，不过我想的是评选的时候能看出是什么类就可以了。--1=0，欢迎加入WP:维基百科维护专题 2019年6月25日 (二) 03:12 (UTC)

评选时候看出什么类其实对评选来说没有意义，至少不可能看到不对的分类就投反对票吧。--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月25日 (二) 03:17 (UTC)

有一定的参考价值吧。不一定是影响投票。--1=0，欢迎加入WP:维基百科维护专题 2019年6月25日 (二) 03:24 (UTC)

不过如果不影响投票，实在不知道对评选有何参考价值。--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月25日 (二) 03:33 (UTC)

其实某程度上会影响投票，用户可以透过分类决定是否参与某些条目的评选，这样可以避免妄论用户不熟悉的题目（如果用户自己认为属于妄论的话）。Σανμοσα 2019年6月26日 (三) 10:06 (UTC)

其实我认为在首页加上分类也不是不可行，作用也是让读者选择他们想看的条目的类型，也不是所有读者也不想理会的。Σανμοσα 2019年6月26日 (三) 10:13 (UTC)

还有，我认为规范化分类填写后，可能需要订立一些特殊的填写规则，例如所有单一人士的条目全部必须设定为“传记／人物”分类。Σανμοσα 2019年6月26日 (三) 10:16 (UTC)

管理员看到两个同类的条目，管理员自己把两个type写成一样的字，便可以了，何必搞规范那么复杂？所以不支持。--Opky9407（留言） 2019年6月26日 (三) 11:56 (UTC)

理论上，管理员不应随意更改type，因为提名DYK的用户填写的type可能有特殊用意，这样会引发编辑战（我可能明白为何阁下经常和其他人发生冲突了）。另外，管理员也没有责任更改type。Σανμοσα 2019年6月27日 (四) 10:22 (UTC)

两天没看，讨论串就长了那么多。我没看完，只是想回应一下：

1. 之前提到的反例说的是这个，上面一堆重复type，下面一堆重复type。以前刘嘉经常撰写飓风条目的时候，我认识的某些朋友曾经抱怨过首页展示的内容比较单一，甚至创作了一首歪歌来调侃一下。FA/GA/FL每天只展示一篇，而且要是等到DYK没有飓风条目才上去，估计就要等很久了，不切实际。由此可见type参数的用处。
2. DYK的type参数没错是不可见的，也不影响投票——我不熟悉很多领域，不过看到严重的翻译错误，我才不会管这条目是什么类别的呢。它最大的影响是条目的展示顺序。
3. Shizhao方案有一个盲肠，一个条目是可以归入多个专题的。例如这个，最后是划入文物，国际关系，浙江，还是日本呢？更别说不同用户挂portal模板的习惯不一样，比如我挂portal模板一般是按照各地图书馆的分类惯例，学科前、地域后，但是某些用户的做法是相反的。
4. 要一般用户记住分类法则较为繁琐。之前曾经有个别用户未经咨询自行规范，不过可能会有人认为（至少我是这样看）他是把自己的个人意志强加于社群。例如他把所有传记类条目划入biography类，但是我和街灯都不是这样想（我之前手动更新的做法是：biography类不可重复，如果同一个时段要遇到另一篇不是biography类别的传记条目，只要传主从事的领域和已有的biography类条目的传主不一样，照样更新。）。然而到互助客栈提到这话题的时候，街灯可能会认为这并不是强制要求，只是锦上添花，不需要规范。因此规范type参数这个话题，到最后总是不了了之。--春卷柯南编辑数突破二万 ( 论功行赏·刻石留名 ) 2019年6月26日 (三) 14:40 (UTC)

• • 我提出的这个方案，多类型的条目可以通过比对类型的相同度来判断条目类型上的差异。也就是说，所属专题相同的越多，类型越相近。这个方案可能比较会影响到的地方其实是分类归档这一块。--百無一用是書生 (☎) 2019年6月27日 (四) 02:07 (UTC)
  • User:春卷柯南我的计划是首先在社群达成规范的共识，然后我制作一个规范让社群看看是否适合（可以审议时修改）。Σανμοσα 2019年6月27日 (四) 10:25 (UTC)
• 或许这样说：现在这个讨论可能就是管理员和普通用户之间抢工作来做，两边都是工作狂（笑），然后又有些管理员和普通用户打算因而顺理成章把于其而言过重的负担抛给对方。我认为如果要达致规范的共识的话，工作狂类型的普通用户和不希望有太重的负担的管理员占多数会是最好的状态。Σανμοσα 2019年6月27日 (四) 10:31 (UTC)
• 综合在这里(：)回应：首先要明白一个道理：我很穷没有钱，您捐钱给我，是否等于我必须接受您的钱？如果人家都说了不需要帮忙分担义务的话，再好的苦心也是多余。“管理员也没有责任更改type”是错误的说法，别忘记type是管理员自己搞出来的东西，自然就产生打理type的责任，所以管理员有责任决定是否需要作出修改（即俗语所谓“自己造了只锅出来，拆这个锅也应该要自己摆平”）。另一方面，与春卷柯南的第2点意见类似，投票者本身就应该要阅了条目才决定是否投票，而不是看类型，条目内容不是所有东西都需要投票者事先对该范畴熟悉的（例如有否列明来源、是否侵权等基本要求），看类决定是否参与某些条目的评选本身就是不该有的投票态度，type的作用本身就不应该影响投票和阅读的取态，{{Dyk}}之所以在展示条目时保持了一定程度上的神秘感，其实就是希望读者无论对某类有没有兴趣都可以看一下条目。而且，我还未看到大家填type时有过什么特殊用意，从实务上多年的观察，各位参选DYK的人无非都只是抱着一种态度：“我能以我想要的问题和图片把条目放到上首页，就行了”，实际根本不会很想理type是什么。我甚至忧虑定立规范会是帮倒忙：首先可以预估得到在type的管理上多了一重掣肘，弹性变少（至少春卷提到的处理方法会变得可行性极低）；二来是type还不会直接影响评审结果的时候，强迫提名者一定要正确使用type可能会让提名者生厌，甚至可能影响提名他人的意欲。--街燈電箱150號 开箱维修 抄表 检验证明 2019年6月27日 (四) 21:07 (UTC)

那我只能支持废除type，这次我不会让步。Σανμοσα 2019年6月30日 (日) 13:59 (UTC)

说到这里，我和您已有一个共同的方向——type迟早也应该要放弃。不过，在未有替代方案出炉前，管理员暂时仍需要倚赖type来控制。还有请懂得分一下庄闲：type是管理员自行创制和负责打理的事情，是故管理员要怎样用type和什么时候不用type，理应由管理员自行决定，除非证实管理员打理type时影响到大家写条目和评审，否则让不让步其实还未轮到一般用户来说。--街燈電箱150號 开箱维修 抄表 检验证明 2019年7月3日 (三) 09:58 (UTC)

type的地位

前期讨论

我认为对于如何看待type的地位，要取决于站内的需要。我认为可以由以下几个问题评估结论：

1. DYK的存档是否有按条目性质分类的必要？
2. 用户是否时常有对于填写type的烦恼？
3. DYK条目上首页除了受type影响外，还受什么因素影响（例如主编）？
4. 外文维基百科的DYK制度是否（曾）有类近设置？如无，则中文维基百科当初设置的原因为何？如有已废除者，则废除的原因为何？

以上。산모사 ^DC17 2019年7月11日 (四) 06:23 (UTC)

• 我个人对于1和2的答案分别是否定和肯定的。对于3的答案，我认为还会受主编和通过时间影响。산모사 ^DC17 2019年7月11日 (四) 06:25 (UTC)
  • 这串讨论概念上就有问题，准确的应该是取决于管理员的需要。关于分类存档，FA和GA赋予了条目地位并须靠条目质量维持，但DYK没有任何地位赋予（这之所以一个条目可以多次DYK），所以DYK分类存档其实多余，更新程序早已放弃不管。type是有烦恼，但别忘记本质上是管理员用，您们填type只是协助性质，不是责任性质，有烦恼其实大可以选择不填不协助，交回管理员自己决定是否填和怎么填（所以小工具和提名说明设它为“必填”，其实并不正确）；而DYK条目除了资格和质素外根本不应受任何其他影响，实务上多年的观察，参选DYK的人只会在意条目能否上首页，却不会在意条目何时上首页；条目评审时，正如上面所说，是阅了条目才决定投票，不应因主编是谁而投票；是故讨论type有否带来烦恼和上首页受何影响，根本没有意义。其他外语没有机械式做法，自然也没有type的设置，即使有同类避免的做法，也是管理员亲自人手选择哪2个条目分开上（也就是Cloudcolors时期的做法）。--街燈電箱150號 开箱维修 抄表 检验证明 2019年7月11日 (四) 07:47 (UTC)
    • User:Cdip150阁下看来不明白为何我会提出这些问题：首先，阁下完全只从管理员角度，而不从提名条目的用户的角度去想（提名条目的用户其实也是type参数功能的用家，如果你是香港的管治者，香港的大规模游行示威应该还是会爆发），而且更忽视了技术问题（下面我会提及）；其次，据我观察，现时不会有≥2条同一人主编的条目同时上首页DYKC，这样是为了突显type在决定条目上首页的时间具有可替代性。阁下也完全未理解小工具的一些背景和现时模板的设定：理论上，提名模板必须填写type，否则会显示错误字样（当然，如果有共识废除的话，可以把这个字样删去）；管理员无视现实可是非常危险。산모사 ^DC17_{FLC GAC} 2019年7月17日 (三) 10:00 (UTC)
      • 都说了这是管理员自设来方便自己的东西，提名人从来就没有使用的责任和义务，自然就是只从管理员角度来考虑（所以提名者根本不是用家；另外，香港是把义务加诸市民，但我这里是避免把义务加诸提名者，所以您这个比喻完全是相反来说）。还有　阁下根本未了解DYKEntry模板的理念：“没有填写类型”其实只是为了文法上较好看罢了，实际上它不是一种技术错误，故不是您口中所谓的“错误字样”，事实上如果管理员预视得到不填type也不会导致2个同类条目上首页的时候，的确是可以不填type的。其实讨论到这里，阁下已经朝了替代的方向来思考（因为阁下间接地提议以author代替type，纵然我认为这是因人设事而不太认同此方法，而且不同人可以写同一类条目），是故与其探讨type占了什么地位，不如思考可能的替代方案可能还要实际。（最后澄清：机器人是不会因为author是谁而改变顺序的，“不会有≥2条同一人主编的条目同时上首页”的现象只是碰巧而已）--街燈電箱150號 开箱维修 抄表 检验证明 2019年7月17日 (三) 13:43 (UTC)
        • 这并不能改变type的存留影响提名DYK的用户的事实（因为他们不再能选择填写type）。提名DYK的用户既受影响，则如果其他用户很喜欢填type而反对废除type，你仍不能因所谓的“这是管理员自设来方便自己的东西”而强行废除type。我希望各位先前参与讨论的用户能对此分段作回应。산모사 ^DC17_{FLC GAC} 2019年7月19日 (五) 08:51 (UTC)
        • 而且，你在上面的言论也显示了你自相矛盾：之前我说我提出的提案是为了帮忙卸下管理员的责任，你当时谓不许，现在你却来拿走普通用户de facto的责任（请注意：社群绝大部分用户都认为自己有责任填写type，共识可以凌驾一个管理员的个人判断）。산모사 ^DC17_{FLC GAC} 2019年7月19日 (五) 08:57 (UTC)
          • 都已经说过type的存在是不影响评审亦不影响条目内容，加上上面已经说了从观察上并未见有提名者在意过何时上首页，所以提名者根本没有受影响，故type的存在只能考虑管理上是否有需要。您要明白：“喜欢”是一回事，“达到效果”是一回事，如果有方法可以不用type都能达到效果，那么个人喜好根本不可能是考虑因素。还有de facto实际是“社群绝大部分用户都认为自己最好填type帮管理员一把”才对，才不是“社群绝大部分用户都认为自己有责任填写type”。--街燈電箱150號 开箱维修 抄表 检验证明 2019年7月19日 (五) 09:27 (UTC)
• @春卷柯南、Antigng、Shizhao、Alexander Misel、Opky9407：我想知道五位的意见。산모사 ^DC17_{FLC GAC} 2019年7月19日 (五) 09:00 (UTC)
• 我对这四条问题的回答是：

1. 如果有机器人辅助，type参数对于分类存档或许有帮助，但是不一定准确，因为没有规范。就算没有，分类存档的工作也可以人手完成。（利益申报：我将来打算把整个DYK分类存档砍掉重练。）
2. 我从来没有听过。
3. 影响DYK条目展示顺序的因素除了type参数，还包括：一、提名顺序（仅限已通过条目），二、{{问题不当}}／{{不合要求}}（后一个比较好做，因为有量化标准，前一个则需要跟主编协商，有时候主编或者插嘴的人态度恶劣，会把事情弄得复杂。），三、提删程序／关注度程序。DYK模板大部分参数（包括author/nominator）对展示顺序没有影响。
4. 印象中除了中文维基百科，其他版本多数都没有这样做。要知道，中文版DYK很多制度都是只此一家（使用问题而非陈述，DYK模板的自动处理程序等等），其他版本大部分都不需要这么多模板来走完整个程序，而且到最后展示顺序很多时候是由管理员确定的。英文版没有这个限制，不过有一条惯例：同时展示多篇美国条目／人物传记条目是没有问题的，不过在这个情况下，同类条目不可以超过4篇（一次共展示8篇）。--春卷柯南编辑数突破二万 ( 论功行赏·刻石留名 ) 2019年7月19日 (五) 09:41 (UTC)

• 我的回答是：

1. 新推荐分类存档是不必要的。新推荐与优良典范不同，优良和典范条目在当选后，质量仍要长期维持，维持不到便需要被复查重审，所以需要做分类方便各种范畴进行复查。但是新推荐是短暂性的，条目在当选后不会因为质量变差了而被复查重审，所以看不到新条目推荐有分类的需要。
2. 我也从来没有听过有烦恼，即便有烦恼不懂填，我也认为管理员代填便行了，况且管理员也已经说了实际上不会有参选人很想理type，管理员代填应该是不会引起参选人不满的，至少没见过这样做发生了很严重的编辑战。
3. {{问题不当}}／{{不合要求}}／提删程序／关注度程序要靠讨论解决，而不需要靠讨论的因素，除了type外应该没有其它的。
4. 英文版看起来是管理员凭自己的常识来避免同类条目超过4篇，不需要参选人的帮助，其他的语言我没深入了解。中文版呢，其实只要管理员协调得好，实在没有必要设立规范限制普通用户一定要选对的type，毕竟在道义上，管理员应该主动为大家服务，如果管理员主动想到比type更好的方法，完全不用参选人操心，相信大家也会支持。--Opky9407（留言） 2019年7月19日 (五) 13:06 (UTC)

---

User:Sanmosa似乎没有新意见了？—— Eric Liu_{（留言．留名．学生会）} 2019年7月28日 (日) 06:08 (UTC)

• Anyway，我看到现况是有利于废除type的，所以现时研究的是废除type后要如何产生hash。산모사 ^DC17_FLC 2019年7月28日 (日) 06:16 (UTC)
  • 我有一个提议是back to classic，以条目名直接产生hash。산모사 ^DC17_FLC 2019年7月28日 (日) 06:16 (UTC)
  • @春卷柯南、Cdip150、Alexander Misel、Opky9407。산모사 ^DC17_FLC 2019年7月28日 (日) 06:19 (UTC)
    • 用条目名来产生hash一直有在做。但是，首先要了解hash是些什么——因为“如果两个杂凑值是不相同的（根据同一函数），那么这两个杂凑值的原始输入也是不相同的”之特性，是故原始输入的字元不同，所产生的hash都会不同；“条目名直接产生hash”，即意味着原始输入是条目名，但条目名一定都是不同的，所以出来的hash都会不同，故此，以hash来判定哪2个条目分开上架，于hash的理论而言是技术不能实现的事。我的计划是在现有的dyktool批核工具中加入次序调节的功能，我认为这个可行性较大，至于如何调节，我想应该交由精通技术的人员去想。--街燈電箱150號 开箱维修 抄表 检验证明 2019年7月28日 (日) 08:30 (UTC)
  • 我还有一个方法是：不再理会那些条目是那些类型，直接按时间次序上首页。산모사 ^DC17_FLC 2019年7月29日 (一) 03:02 (UTC)
    • 还是上次的观念：不要想得两极、非黑即白（“要么就完全不煮，要么就煮到全熟”），尽量展示不同类型最好是做，但这不代表要做到最好、管得太严。--街燈電箱150號 开箱维修 抄表 检验证明 2019年7月29日 (一) 03:32 (UTC)

---

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

DYKC type参数的处置

所有后续处理完成。산모사 ^DC17_{GAN FLN} 2019年8月11日 (日) 14:32 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

---

我建议以后可以不强制提名人填写type，并容许任何人更改type而不影响hash（但禁止清空）。산모사 ^DC17_{GAC FLC} 2019年8月5日 (一) 13:47 (UTC)

其实，从来都没有强制过提名人一定要填type（见Wikipedia:管理员/管理员的一天#批核条目：“type = 条目类型（选填……）”，以及Template:DYKEntry#用法也指出type仅为建议），是个别用户不明就里把提名小工具和提名指示擅自设为必填罢了。另外，也从来没有禁止过type的更改。所以这个提案基本上没有改变现状。但禁止清空是无谓的，因为如果预视到某个条目可以不需要type时，为何不能清？而且就算有人清空了，如果管理员认为有需要时，也大可以自行补回，别忘记type是管理员负责控制的事宜。--街燈電箱150號 开箱维修 抄表 检验证明 2019年8月5日 (一) 15:17 (UTC)

User:Cdip150一、我的意思是要更改template和小工具设定；二、允许清空会导致编辑战，有人认为不需要的同时也会有人认为需要。산모사 ^DC17_{GAC FLC} 2019年8月6日 (二) 04:32 (UTC)

一、小工具可直接通知作者修改为现有的选填现状，template本身没有提示错误所以不用改（注意“没有填写类型”并非错误讯息）。二、由于实务的观察上无人在意type，而事实上清空也是修改的其中一种，既然修改也未见到有任何编辑战时，清空也未见得有严重的编辑战可能，即使将来发生，现有的编辑战方针已可足以应对。其实如果依照　阁下逻辑，那其实也会发生有人认为是A类的的同时也会有人认为是B类而发生的编辑战，但实际上至今没有发生过此种编辑战，故清空会造成严重编辑战的推论，实务的角度来看并不成立。--街燈電箱150號 开箱维修 抄表 检验证明 2019年8月6日 (二) 05:30 (UTC)

清空和一般修改是两回事：一般修改之下type仍存在，清空之下type就会没掉，有与无的分别很大。DYKC页按编辑战方针处理，要么封人（或WP:BAN），要么全保护；管理员通常都是采取后者，但后者不能用，前者也不是随便就能用的。另外，“没有填写类型”虽非错误讯息，但也很碍眼，去掉会更好。산모사 ^DC17_{GAC FLC} 2019年8月8日 (四) 00:49 (UTC)

如果可以预期被清空的某个type与当前展示的不会造成严重的类型冲突，事实上有与没有type的分别不大，别忘记type是管理上的需要，有没有分别要看管理上预期执行的效果而定，而不是一刀切说清空就一定有分别。就算真的有用户因此发生编辑战，由于type是管理上的需要，管理员绝对可以到时指定某个type是否要填和怎样填，而出于管理需要而作出的编辑通常是不应回退的，否则会被视为妨碍管理员工作，故此不用保护不用封禁便可解决，要是之后还要执意把管理员的管理动作回退的话根本是自找封禁。“没有填写类型”的确可有可无，要移除的话我没有意见。--街燈電箱150號 开箱维修 抄表 检验证明 2019年8月8日 (四) 01:29 (UTC)

还有一个问题是：你这样做会留下破坏的缺口。我估计如果按你的方法，有人会恶意把所有type清空，你可能不需要依赖type，但其他管理员可能需要；你还是需要顾及其他管理员的。산모사 ^DC17_{GAC FLC} 2019年8月8日 (四) 07:58 (UTC)

恶意清空这交给WP:VIP就行，而且是否恶意清空管理员通常都能看得出来，不需要特别一刀禁止。如果有管理员对某个type要怎样填有不同意见，管理员之间协调便可，多年来的经验告诉我们：管理员之间在type上的协调没有出过大问题、没有发生过编辑战或车轮战。--街燈電箱150號 开箱维修 抄表 检验证明 2019年8月8日 (四) 08:06 (UTC)

我不是想说“看不看得出来”，而是想说“恶意清空type的后续麻烦”；你未必能成功revert恶意清空，如何回复原状是一个问题。虽然是可以de facto禁止，但写出来总比不写好，你总也要考虑其他管理员对同一条文的解读会有不同。산모사 ^DC17_FLN 2019年8月9日 (五) 01:53 (UTC)

要这样理解的话，那就算禁止也是徒然，因为恶意破坏者才不会理会规则是什么，一样照样会恶意清空，一样会有后续的麻烦。这样的禁止其实无助解决恶意的问题。--街燈電箱150號 开箱维修 抄表 检验证明 2019年8月9日 (五) 02:00 (UTC)

User:Cdip150其实可以设置过滤器阻挡（顺便挡掉把type全改成同一个的edit）。산모사 ^DC17_{GAN FLN} 2019年8月10日 (六) 08:37 (UTC)

唉……您真的想得美，如果过滤器是行的话，我应该一早设置了阻止清空question参数的过滤器啦～，事实上早期是有想过设置这样的过滤器，可惜最终行不通。--街燈電箱150號 开箱维修 抄表 检验证明 2019年8月10日 (六) 17:31 (UTC)

有没有相关讨论连结？산모사 ^DC17_{GAN FLN} 2019年8月11日 (日) 04:26 (UTC)

没有讨论连结，因为都是幕后测试，而试验结果并不理想——很容易有错判且太难解决，而且考虑到如果破坏者恶意胡乱添加提名（过滤器现在也无法判断新增的提名内容是否正当），一般用户也无法立即回退（因为回退的一刻也是在清空各个参数）。所以如果今天有人清空question，还是要手动地见一个退一个。--街燈電箱150號 开箱维修 抄表 检验证明 2019年8月11日 (日) 13:27 (UTC)

不如先回到这个问题：“容许任何人更改type而不影响hash”技术上做到吗？산모사 ^DC17_{GAN FLN} 2019年8月10日 (六) 08:37 (UTC)

现在本身已经是这样做：一是规则本身并未禁止type的任何更改（包括清空）；二是无论怎样改type甚至改为无，hash都是不会变的；所以“容许任何人更改type而不影响hash”其实一直都在实行中。如果提案没有带来任何实质改变，而以现在的规则已经能够维持日常运作的话，实在不想再动DYKC的规则，这里我还是希望保持最少量的规则。--街燈電箱150號 开箱维修 抄表 检验证明 2019年8月10日 (六) 17:31 (UTC)

如果情况是这样的话，现在要做的就是更改template和小工具设定了。有没有人知道小工具是谁写的？산모사 ^DC17_{GAN FLN} 2019年8月11日 (日) 04:26 (UTC)

User:Sanmosa和User:Cdip150小工具是我写的。我当时是参考的 DYKC 页面的编辑提示，里面说 type 参数是必填。既然现在文档之间都不太统一，我想等等看有没有其他意见，到这个串讨论差不多该存档的时候再说。 --砜中嘌呤的白磷_{萃取 打谱} 2019年8月11日 (日) 11:32 (UTC)

所以我说那个提名指示是错的，已改正，另{{DYKEntry}}已不再显示无类型。--街燈電箱150號 开箱维修 抄表 检验证明 2019年8月11日 (日) 13:27 (UTC)

---

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

提议禁止废除DYKC讨论中使用type这个单词参数

改由Wikidata辅助。-- 娜娜奇🐰枫香花茶☕（宇帆·☎️·☘️） 2020年5月20日 (三) 18:52 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

---

提议禁止DYKC讨论中使用type这个单词，包括但不限于参数需要用到type的模板或者与type相关的举例，如“type =”以及任何能够被\s*type\s*=.*\n匹配到的任何字串（如：_{{{問題不當}}，您的type=應改為blabla...--~~~~}；或者是_{{{支持}}，....(評論)....{{某模板|type=XXX|....}}...--~~~~}等）

考虑如下问题[1]导致首页爆炸（参见截图），

由于模板中使用了type=参数，导致点票机器人匹配到位于讨论中的type=导致首页爆炸。

若无法修复，应当禁止除了提名模板本身外的任何type单词

• 为什么？因为考量如下情境：编者认为type不当，要求更改type=，然后后方论述使用display:none隐藏了部分文字，</span>于下一行封闭，因此这则dyk上首页后，type会变成该用户言论，假设中间有|符号，display:none将会取代下一个问题，并使首页大量内容被display:none隐藏

因此若User:Cdip150未能修复此问题则应当禁止在DYKC讨论中提到或使用type单词。否则无法避免首页再次爆炸或出错。-- 娜娜奇🐰鲜果茶☕（宇帆·☎️·☘️） 2020年3月24日 (二) 09:02 (UTC)

(－)反对，机械程序出现缺陷不应由社群承担，我稍后会尝试修复这个错误。而且如果做这样的禁止，岂不是连“question =”等其他几个都全部不许出现？显然这种禁止是斩脚趾避沙虫，不足为取。而因为机器程序而造成的错误，本人郑重向社群致歉。--街燈電箱150號 开箱维修 抄表 检验证明 2020年3月24日 (二) 09:12 (UTC)

(！)意见这个想法是稍早之前在WP:TG上提出的，如果问题不易修复，就只能往另一个方向思考。如果易修复，那么修复完毕就结案了。-- 娜娜奇🐰鲜果茶☕（宇帆·☎️·☘️） 2020年3月24日 (二) 09:29 (UTC)

 已修复，@A2569875：请参考该移出及移入结果。--街燈電箱150號 开箱维修 抄表 检验证明 2020年3月25日 (三) 15:14 (UTC)

说起这个type的作用，不知道能否用wikidata中的性质属性d:Property:P31来自动区分条目的类型？--百無一用是書生 (☎) 2020年3月25日 (三) 17:10 (UTC)

有些新条目可能没有wikidata项目或没有添加P31。——路过围观的Sakamotosan | 避免做作，免敬 2020年3月26日 (四) 00:55 (UTC)

P31可以选择的项目范围有点大，可能变成每个项目因为P31都全不同而没区别，实际上只是P31给予的定性不同？——路过围观的Sakamotosan | 避免做作，免敬 2020年3月26日 (四) 00:57 (UTC)

乱搞放在哪里，用什么办法都可以乱搞。--百無一用是書生 (☎) 2020年3月26日 (四) 06:59 (UTC)

(：)回应@Shizhao：应该是说，P31在Wikidata没有统一指引，例如以多面体而言，有的归类为多面体、有的归类为多胞形有的归类为凸多面体，例外状况十分多。-- 娜娜奇🐰鲜果茶☕（宇帆·☎️·☘️） 2020年3月26日 (四) 07:14 (UTC)

但现在人工输入type参数，不是也一样没有任何限制？--百無一用是書生 (☎) 2020年3月27日 (五) 07:28 (UTC)

写了一个模块:Page2qid（wikidata模块居然不支持从标题获取QID功能么？还是我没找到？）配合Module:WikidataIB实现了我的想法，随便找了几个正在DYK的条目试验一下：

• 阿卜杜尔·穆伊斯 --> 人类
• 天皇机关说 -->
• 意大利战列舰列表 --> 维基媒体列表条目， 战列舰
• 次北固山下 --> 诗歌， 文学作品

稍微修改一下DYK提名模板就能实现。剩下的只需要dyk更新脚本改代码，进行条目类型的判断，避免同类型条目连续上首页。同时也可以废弃type参数了。此外，还可以促进wikidata的编辑--百無一用是書生 (☎) 2020年3月27日 (五) 09:50 (UTC)

早就有了{{WikidataEntity}}，还是高风险模板。您的可以AFD了。-- 我就烂 2020年3月27日 (五) 10:26 (UTC)

废除type参数我记得是个常年提案，经常有人提议改革/废除这个参数，只不过这应该是第一次因技术原因而提议的废除。虽说我觉得因为这个原因而废除type参数，是种因噎废食的行为，不过从另一个角度看似乎有些道理。大家不妨参考一下以下几个提案：[2][3][4][5]。—Rowingbohe♬ （讨论·签名·台州专题） 2020年3月27日 (五) 14:40 (UTC)

欢迎大家前往dyk_update.lua参考我去年写的DYK存档逻辑。--1=0，欢迎加入WP:维基百科维护专题 2020年3月29日 (日) 03:04 (UTC)

我的提议的初衷其实就是不用用户自己去填写了，省一点事是一点事--百無一用是書生 (☎) 2020年3月30日 (一) 02:36 (UTC)

另外，我的这个提议并不是完全废除，而是用另一种自动的方式来替代用户的手工输入，只是解放用户双手的一种办法。从内容本质上而言，替代办法只是比手工输入在准确性上略强（但理想状况的话，应该是比手工输入要规范很多）。而且我也不觉得type参数的影响真的非常大--百無一用是書生 (☎) 2020年3月31日 (二) 09:27 (UTC)

建议

建议修改{{DYKEntry}}，替换如下语句：

{{subst:#if:{{{type|}}}|，属于{{{type}}}类}}

为：

{{subst:#if:{{{type|}}}|，属于<code>{{{type}}}</code>类|{{subst:#if:{{WikidataEntity|{{{article|}}}}}|，{{#invoke:WikidataIB |getLabel|P31}}属于<code>{{#invoke:WikidataIB |getValue |P31 |fwd=ALL |osd=no|linked=no |noicon=yes |qid={{WikidataEntity|{{{article|}}}}}|sep="</code>、<code>"}}</code>}}}}

示例（未填type参数）： 意大利战列舰列表 --> ，性质属于维基媒体列表条目、战列舰

作为未填写type参数时的补充。不知这样是否可行？--百無一用是書生 (☎) 2020年4月1日 (三) 02:56 (UTC)

---

如果没有其他意见，我将稍后更新{{DYKEntry}}模板--百無一用是書生 (☎) 2020年4月6日 (一) 12:10 (UTC)

不需要，这可由机械程序每小时auto hashing时顺便在type中把以上语法进行subst即可，不用改模板。--街燈電箱150號 熄灯致哀 2020年4月7日 (二) 02:03 (UTC)

@Cdip150：，好的--百無一用是書生 (☎) 2020年4月7日 (二) 02:53 (UTC)

@Cdip150：似乎还未看到部署？--百無一用是書生 (☎) 2020年4月9日 (四) 07:35 (UTC)

@Shizhao：已部署，但看到很多条目只得“维基媒体项目页面”一类，似乎很多条目的元数据都未配置妥当…… --街燈電箱150號 熄灯致哀 2020年4月13日 (一) 05:53 (UTC)

按理说，如果某个条目没有wikidata数据，正常应该不显示任何东西才对，不应该显示“维基媒体项目页面”--百無一用是書生 (☎) 2020年4月13日 (一) 08:23 (UTC)

以条目艾格理为例，还没有建立wikidata，那么{{safesubst:#invoke:WikidataIB |getValue |P31 |fwd=ALL |osd=no|linked=no |noicon=yes |qid={{safesubst:WikidataEntity|艾格理}}|sep="、"}}出来的结果是“维基媒体项目页面”。--街燈電箱150號 开箱维修 抄表 检验证明 2020年4月13日 (一) 11:12 (UTC)

User:Shizhao qid为空会有例外：“{{safesubst:#invoke:WikidataIB |getValue |P31 |fwd=ALL |osd=no|linked=no |noicon=yes|sep="、"}}”→维基媒体项目页面--140.121.197.81（留言） 2020年4月13日 (一) 11:17 (UTC)

嗯，似乎缺少了一个判断：{{subst:#if:{{WikidataEntity|艾格理}}|，{{#invoke:WikidataIB |getLabel|P31}}属于<code>{{#invoke:WikidataIB |getValue |P31 |fwd=ALL |osd=no|linked=no |noicon=yes |qid={{WikidataEntity|艾格理}}|sep="</code>、<code>"}}</code>}} -->

这样就对了（就是我前面给出的代码）--百無一用是書生 (☎) 2020年4月13日 (一) 12:14 (UTC)

其实无论空白和“维基媒体项目页面”实际出来的效果都是一样的——分不了类，还是要用手。假若大部分条目的wikidata都不完善，部署了这个其实也起不了几多作用。--街燈電箱150號 开箱维修 抄表 检验证明 2020年4月14日 (二) 03:25 (UTC)

其实我提出的建议是把这个作为未填type时的补充。。。而且也可以鼓励用户编辑wikidata（至少比填对条目无用的type强）--百無一用是書生 (☎) 2020年4月14日 (二) 08:00 (UTC)

(？)疑问@Cdip150：书生的提议如何？-- 娜娜奇🐰枫香花茶☕（宇帆·☎️·☘️） 2020年4月22日 (三) 13:33 (UTC)

(？)疑问目前状态?-- 娜娜奇🐰枫香花茶☕（宇帆·☎️·☘️） 2020年5月1日 (五) 11:35 (UTC)

“未填type时的补充”已实现，但由于Wikidata那边对于P31的用法并不规则，各类型的译文他们甚至还未做齐，所以现阶段还不要对P31带来的帮助抱太大期望。--街燈電箱150號 开箱维修 抄表 检验证明 2020年5月2日 (六) 05:43 (UTC)

好的，了解了。-- 娜娜奇🐰枫香花茶☕（宇帆·☎️·☘️） 2020年5月12日 (二) 06:04 (UTC)

---

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

T: DYKEntry

T: DYKEntry 的 type 参数是怎么一回事？为什么会要求英文？为什么会要求“属culture类”这样的说明？是为了让机器人展示不同种类的新条目吗？谢谢！ — XComhghall talk 2021年9月4日 (六) 00:28 (UTC)

是的，不过这个可以由管理员机器人填的，您可以把它留空，机器人会自动补上。--街燈電箱150號 开箱维修 抄表 检验证明 2021年9月4日 (六) 01:51 (UTC)