模板討論: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參數

下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

原標題為:提議廢除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. 刪除一個別名,只需將別名標記為不可引用。
我先說明一下為何我提議廢除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)[回覆]
  • 要知道當初沒機械人的年代是由管理員親自決定哪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)[回覆]
其實既然用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日 (四) 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的地位


User:Sanmosa似乎沒有新意見了?—— Eric Liu留言留名學生會 2019年7月28日 (日) 06:08 (UTC)[回覆]


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

DYKC type參數的處置

下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

我建議以後可以不強制提名人填寫type,並容許任何人更改type而不影響hash(但禁止清空)。 DC17GAC 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和小工具設定;二、允許清空會導致編輯戰,有人認為不需要的同時也會有人認為需要。 DC17GAC FLC 2019年8月6日 (二) 04:32 (UTC)[回覆]
一、小工具可直接通知作者修改為現有的選填現狀,template本身沒有提示錯誤所以不用改(注意「沒有填寫類型」並非錯誤訊息)。二、由於實務的觀察上無人在意type,而事實上清空也是修改的其中一種,既然修改也未見到有任何編輯戰時,清空也未見得有嚴重的編輯戰可能,即使將來發生,現有的編輯戰方針已可足以應對。其實如果依照 閣下邏輯,那其實也會發生有人認為是A類的的同時也會有人認為是B類而發生的編輯戰,但實際上至今沒有發生過此種編輯戰,故清空會造成嚴重編輯戰的推論,實務的角度來看並不成立。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月6日 (二) 05:30 (UTC)[回覆]
清空和一般修改是兩回事:一般修改之下type仍存在,清空之下type就會沒掉,有與無的分別很大。DYKC頁按編輯戰方針處理,要麽封人(或WP:BAN),要麽全保護;管理員通常都是採取後者,但後者不能用,前者也不是隨便就能用的。另外,「沒有填寫類型」雖非錯誤訊息,但也很礙眼,去掉會更好。 DC17GAC FLC 2019年8月8日 (四) 00:49 (UTC)[回覆]
如果可以預期被清空的某個type與當前展示的不會造成嚴重的類型衝突,事實上有與沒有type的分別不大,別忘記type是管理上的需要,有沒有分別要看管理上預期執行的效果而定,而不是一刀切說清空就一定有分別。就算真的有用戶因此發生編輯戰,由於type是管理上的需要,管理員絕對可以到時指定某個type是否要填和怎樣填,而出於管理需要而作出的編輯通常是不應回退的,否則會被視為妨礙管理員工作,故此不用保護不用封禁便可解決,要是之後還要執意把管理員的管理動作回退的話根本是自找封禁。「沒有填寫類型」的確可有可無,要移除的話我沒有意見。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月8日 (四) 01:29 (UTC)[回覆]
還有一個問題是:你這樣做會留下破壞的缺口。我估計如果按你的方法,有人會惡意把所有type清空,你可能不需要依賴type,但其他管理員可能需要;你還是需要顧及其他管理員的。 DC17GAC FLC 2019年8月8日 (四) 07:58 (UTC)[回覆]
惡意清空這交給WP:VIP就行,而且是否惡意清空管理員通常都能看得出來,不需要特別一刀禁止。如果有管理員對某個type要怎樣填有不同意見,管理員之間協調便可,多年來的經驗告訴我們:管理員之間在type上的協調沒有出過大問題、沒有發生過編輯戰或車輪戰。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月8日 (四) 08:06 (UTC)[回覆]
我不是想說「看不看得出來」,而是想說「惡意清空type的後續麻煩」;你未必能成功revert惡意清空,如何回復原狀是一個問題。雖然是可以de facto禁止,但寫出來總比不寫好,你總也要考慮其他管理員對同一條文的解讀會有不同。 DC17FLN 2019年8月9日 (五) 01:53 (UTC)[回覆]
要這樣理解的話,那就算禁止也是徒然,因為惡意破壞者才不會理會規則是甚麼,一樣照樣會惡意清空,一樣會有後續的麻煩。這樣的禁止其實無助解決惡意的問題。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月9日 (五) 02:00 (UTC)[回覆]
User:Cdip150其實可以設置過濾器阻擋(順便擋掉把type全改成同一個的edit)。 DC17GAN FLN 2019年8月10日 (六) 08:37 (UTC)[回覆]
唉……您真的想得美,如果過濾器是行的話,我應該一早設置了阻止清空question參數的過濾器啦~,事實上早期是有想過設置這樣的過濾器,可惜最終行不通。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月10日 (六) 17:31 (UTC)[回覆]
有沒有相關討論連結? DC17GAN FLN 2019年8月11日 (日) 04:26 (UTC)[回覆]
沒有討論連結,因為都是幕後測試,而試驗結果並不理想——很容易有錯判且太難解決,而且考慮到如果破壞者惡意胡亂添加提名(過濾器現在也無法判斷新增的提名內容是否正當),一般用戶也無法立即回退(因為回退的一刻也是在清空各個參數)。所以如果今天有人清空question,還是要手動地見一個退一個。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月11日 (日) 13:27 (UTC)[回覆]

不如先回到這個問題:「容許任何人更改type而不影響hash」技術上做到嗎? DC17GAN FLN 2019年8月10日 (六) 08:37 (UTC)[回覆]

現在本身已經是這樣做:一是規則本身並未禁止type的任何更改(包括清空);二是無論怎樣改type甚至改為無,hash都是不會變的;所以「容許任何人更改type而不影響hash」其實一直都在實行中。如果提案沒有帶來任何實質改變,而以現在的規則已經能夠維持日常運作的話,實在不想再動DYKC的規則,這裏我還是希望保持最少量的規則。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月10日 (六) 17:31 (UTC)[回覆]
如果情況是這樣的話,現在要做的就是更改template和小工具設定了。有沒有人知道小工具是誰寫的? DC17GAN FLN 2019年8月11日 (日) 04:26 (UTC)[回覆]
User:SanmosaUser:Cdip150小工具是我寫的。我當時是參考的 DYKC 頁面的編輯提示,裏面說 type 參數是必填。既然現在文檔之間都不太統一,我想等等看有沒有其他意見,到這個串討論差不多該存檔的時候再說。 --碸中嘌呤的白磷萃取 打譜 2019年8月11日 (日) 11:32 (UTC)[回覆]
所以我說那個提名指示是錯的,已改正,另{{DYKEntry}}已不再顯示無類型。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月11日 (日) 13:27 (UTC)[回覆]

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

提議禁止廢除DYKC討論中使用type這個單詞參數

下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

提議禁止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)[回覆]