Template talk: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)