维基百科:互助客栈/其他

快捷方式

本页讨论與維基百科有關的话题，但不包括新闻、方针、技术、求助、條目或繁简处理。

如果您需要就具体条目应当如何编辑才符合中立性原則寻求社区共识，请前往條目探討留言。
請在主題欄简明扼要地寫出問題主旨，不要使用如「新問題」等無意義的文字。
請勿公開姓名、地理位置、電話、Email地址等联系資料。我們通常只在此頁回應，並不利用Email或電話等私下回應。
無關維基百科專案的問題，請往知識問答相關頁面询問。

請注重礼仪、遵守方針與指引，一般問題請至互助客棧其他區或知识问答提出，留言后请务必签名（点击）。

發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

5月1日之后没有新回應的议题會移动至相应的讨论页或存档。跳至本頁的：目錄 · 底端

公告欄

[人事] Manchiu、UjuiUjuMandan、ASid、ATannedBurger获提名为管理员，AT获提名为监督员，欢迎踊跃参与提问和讨论。
[公告] 現時已改為只有延伸確認用戶可以使用內容翻譯將頁面釋出到主條目空間，如有疑問及意見，歡迎參與相關討論。
[公告] 回饋請求系統正在試運作中，誠邀用户訂閱以接收討論通知。用户訂閱有興趣參與的討論議題後，机器人會自動在新討論發起時隨機抽取部分用户發消息通知。
[公告] 修訂維基百科不是維基物種及IP封禁豁免权授予者的顶部图标已經通過。
[公告] 規範討論發起步驟正在公示，如有意見請儘快提出。
[討論] 互助客栈方针区正在討論電視條目播放資訊增加收錄準則及再擬議立國際關係命名常規為方針，請踴躍參與討論。
[討論] 互助客栈技术区正在討論ToolsRedirect创建的繁簡重定向問題，請踴躍參與討論。
[討論] 互助客栈其他区正在討論对新闻动态获选标准及ITNR规则的小修订及頁面評級與通用評級行政層面上的統合方案，請踴躍參與討論。
[廣告] 第二十二次動員令現正徵求主題及決定舉辦時間。另主持人選舉時程及規則公示至5月14日止，歡迎踴躍參與！

[協作] 现有125个页面需维基化，272个条目需清理，9个移动请求正在讨论。
[獎勵] 現有1名用户獲提名维基奖励，欢迎投票。

存檔

2003年	6月以前						7	8	9	10	11	12	月
2004年	1	2	3	4	5	6	7	8	9	10	11	12	月
2005年	1	2	3	4	5	6	7	8	9	10	11	12	月
2006年	1	2	3	4	5	6	7	8	9	10	11	12	月
2007年	1	2	3	4	5	6	7	8	9	10	11	12	月
2008年	1	2	3	4	5	6	7	8	9	10	11	12	月
2009年	1	2	3	4	5	6	7	8	9	10	11	12	月
2010年	1	2	3	4	5	6	7	8	9	10	11	12	月
2011年	1	2	3	4	5	6	7	8	9	10	11	12	月
2012年	1	2	3	4	5	6	7	8	9	10	11	12	月
2013年	1	2	3	4	5	6	7	8	9	10	11	12	月
2014年	1	2	3	4	5	6	7	8	9	10	11	12	月
2015年	1	2	3	4	5	6	7	8	9	10	11	12	月
2016年	1	2	3	4	5	6	7	8	9	10	11	12	月
2017年	1	2	3	4	5	6	7	8	9	10	11	12	月
2018年	1	2	3	4	5	6	7	8	9	10	11	12	月
2019年	1	2	3	4	5	6	7	8	9	10	11	12	月
2020年	1	2	3	4	5	6	7	8	9	10	11	12	月
2021年	1	2	3	4	5	6	7	8	9	10	11	12	月
2022年	1	2	3	4	5	6	7	8	9	10	11	12	月
2023年	1	2	3	4	5	6	7	8	9	10	11	12	月
2024年	1	2	3	4	5	6	7	8	9	10	11	12	月

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	沒有主題的頁面如何評級	184	11	A2569875	2024-05-04 15:27
2	評級系統缺失問題	211	21	Temp3600	2024-05-05 16:28
3	管理人员申请预讨论	270	46	Rastinition	2024-05-06 07:31
4	對新用戶禁用內容翻譯工具（續）	29	12	SCP-2000	2024-04-24 11:51
5	关于IP封禁豁免权授予者的顶部图标	18	4	人间百态	2024-05-06 22:17
6	对ITN获选标准及ITNR的小修订	24	10	Cmsth11126a02	2024-05-04 12:44
7	Unblock-zh.org	15	7	Stang	2024-05-08 09:14
8	原創研究	5	3	Nostalgiacn	2024-05-02 00:55
9	第二十二次動員令籌備討論	45	21	Ghrkya	2024-05-09 23:20
10	何時應該使用{{Dead Link}}模板？	7	3	GZWDer	2024-05-08 20:02
11	照片著作權疑問	6	3	世界解放者	2024-05-06 10:40
12	关于第三次非洲月	11	8	August0422	2024-05-07 16:29
13	请求讨论，人少了不行，请大家都来说，直到让我意识到是我的理解不对为止。	2	2	YFdyh000	2024-05-09 18:40
14	有關被永久封鎖的IP	4	4	Cwek	2024-05-11 08:27

發言更新圖例
最近一小時內
最近一日內
一週內
一個月內
逾一個月
特殊狀態
已移動至其他頁面或完成討論之議題
手動設定
當列表出現異常時，請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下討論需要社群廣泛關注：（重新整理）

維基專題與協作

Wikipedia talk:已经去世的用户 § 已被全域禁制的用户的用户主页可以加离世模板吗？

上述讨论中不少用户认为需要对现有的模板（{{Death}}和{{Deceased Wikipedian}}）的文案进行调整，鉴于该讨论已持续近一个月没有结论，我想先尝试推动一下确立模板文案的调整方案（假定文案必须调整）： {

强烈建议使用WP:RELIST流程

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:删除程序、Wikipedia talk:删除方针、Wikipedia talk:頁面存廢討論。

公示通过--百無一用是書生 (☎) 2023年1月24日 (二) 07:31 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

目前存废积压严重，积压的讨论中，约有一半最终都因缺乏讨论而无共识关闭。因此强烈建议采用{{relist}}方式，一方面促进讨论，一方面解决积压问题。鉴于我们与英文版的不同之处，我建议：

采用{{relist}}制度，存废討論已超過五週的提案，如果仍然缺乏共识，可以重新提交到最新一天的存废讨论页面继续讨论（与现有流程接轨）
同一个讨论最多可以重新提交三次，若三次后仍无共识，则以无共识结案（事不过三）
每次重新提交时，在原讨论处关闭讨论并说明已重新提交讨论到新的页面，若有讨论内容，则将所有讨论内容移动到新的讨论处。在新讨论的最下方挂上{{relist}}模板
希望能够得到WP:TW的支持

此外，鉴于存废积压当中另有相当一部分讨论是已有共识，但不好处理的，例如合并、迁移到其他计划、分类页面需要清空分类才能删除、模板需要清除嵌入才好删除等，建议使用{{follow-up}}进行标记，处理完成后就可以结案。这个也希望能够得到WP:TW的支持 --百無一用是書生 (☎) 2023年1月4日 (三) 08:12 (UTC)[回复]

{{follow-up}}的问题，我已经写了一个User:Shizhao/follow-up.js，勉强能用--百無一用是書生 (☎) 2023年1月4日 (三) 14:04 (UTC)[回复]

想問一下如果重新列出討論，那原先討論的結果是什麼？在條目討論頁該怎麼表述？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年1月4日 (三) 15:24 (UTC)[回复]

没有结果。使用relist的是没有关闭，但长期无共识的讨论，将其重新列出以获得社群的更多关注。已经关闭的讨论无法relist。--BlackShadowG Slava Ukraini! 2023年1月5日 (四) 01:35 (UTC)[回复]

我不理解。按照Shizhao的描述，重新列出討論實際上相當於結束舊討論。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年1月5日 (四) 08:13 (UTC)[回复]

原先的讨论并未结束，只是换到一个新地方继续讨论--百無一用是書生 (☎) 2023年1月6日 (五) 02:37 (UTC)[回复]

会有这种错觉，可能是因为我们不是一个条目存废讨论开一个页面的方式造成的--百無一用是書生 (☎) 2023年1月6日 (五) 02:38 (UTC)[回复]

技术上能做到吗？英维是一个条目存废讨论开一个页面，并把每个独立的条目存废页面嵌入到各天的讨论页面中；中维这边是每个条目的存废讨论直接在当天的页面开章节讨论。在中维如果用relist，把原先的讨论从原来的天数移动到最新的天数，可能导致反复移动而造成编辑历史不完整。我认为在此之前，我们似乎需要先把存废讨论改为每个条目开启独立的讨论页面。--BlackShadowG Slava Ukraini! 2023年1月5日 (四) 01:32 (UTC)[回复]

@BlackShadowG：技術上是可以做到，不必移動任何討論，例如只要使用語法{{#lsth:Wikipedia:頁面存廢討論/記錄/2023/01/11|[[:1910年逝世人物列表]]}}：

1910年逝世人物列表

本討論已經结束，以上页面已保留。请不要对这个存档做任何编辑。

(±)合併到1910年。沒有必要再獨立出一個頁面來敘述

提交的維基人及時間：LarryChou0129（留言） 2023年1月11日 (三) 02:45 (UTC)[回复]

(○)保留：那其他年份逝世人物的條目也要合併到相對應的年份條目？下同。Sammypan（留言） 2023年1月12日 (四) 11:02 (UTC)[回复]

保留。--百無一用是書生 (☎) 2023年2月8日 (三) 02:15 (UTC)[回复]

※註：可能因為某些原因（見討論）部分內容丟失。以上內容已透過{{subst:}}進行還原並固定內容。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年11月21日 (二) 12:27 (UTC)[回复]

或語法{{Include|Wikipedia:頁面存廢討論/記錄/2023/01/11#[[:美食王國]]}}：

美食王國

本討論已經结束，以上页面已刪除。请不要对这个存档做任何编辑。

(×)删除理據：來源跟條目內文對不上。來源根本看不到「美食王國」這個詞是翁佳音跟曹明宗所提出的根據。而且美食王國一詞是否只會用在臺灣上面也有爭議。

提交的維基人及時間：祥龍（留言） 2023年1月11日 (三) 03:36 (UTC)[回复]

(～)補充：關於條目內的英文「Kingdom of Taiwanese Food」，我試著用Google搜尋，結果只找到這個條目頁面，懷疑有原創研究的嫌疑。--祥龍（留言） 2023年1月11日 (三) 03:43 (UTC)[回复]

(×)删除：原創研究。--冥王歐西里斯（留言） 2023年1月11日 (三) 03:50 (UTC)[回复]

删除。--百無一用是書生 (☎) 2023年1月18日 (三) 01:35 (UTC)[回复]

※註：可能因為某些原因（見討論）部分內容丟失。以上內容已透過{{subst:}}進行還原並固定內容。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年11月21日 (二) 12:27 (UTC)[回复]

都能有類似效果。後者按下編輯紐還會直接跳轉到該天的存廢頁。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月11日 (三) 03:55 (UTC)[回复]

不過，可以預見如此作法可能會導致存廢頁的原始碼變得很混亂，所以還是則存廢用獨立一頁為佳。不過我認為再還沒換成一個存廢獨立一頁之前可以先用{{Include}}過渡一下。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月11日 (三) 04:08 (UTC)[回复]
章节标题像“30天后仍掛有{{notability}}模板的條目”这样的，上面说的两种办法都无效--百無一用是書生 (☎) 2023年1月12日 (四) 07:39 (UTC)[回复]
(：)回應@Shizhao：這樣的章節不會需要{{relist}}吧。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月12日 (四) 07:52 (UTC)[回复]
实践上，很可能会用到--百無一用是書生 (☎) 2023年1月12日 (四) 08:03 (UTC)[回复]
@Shizhao：這種章節通常是羅列多則存廢用的章節；而{{relist}}通常只適用於單一一則條目的存廢，所以我想這類章節標題應該不會需要用到。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月13日 (五) 04:58 (UTC)[回复]

重新提交能起到什麼作用呢，不是很理解。follow-up這個模板倒是支持，但建議必定要填寫共識是什麼。--Ghren 🐦🕘 2023年1月5日 (四) 01:37 (UTC)[回复]

@Ghren：因为越新的存废讨论更容易获得关注，重新提交预期可以进一步继续讨论达成共识以结案，而减少无共识结案的问题，同时减少积压问题。
@BlackShadowG 一个条目存废讨论开一个页面当然是最好，但是工作量比较大，相关的工具都要跟着变才行（当然，不理会那些辅助工具直接改变也不是不行，只是可能会初期的时候提交和处理会不太方便）。如果不改变成一个条目存废讨论开一个页面的方式，的确存在编辑历史不完整的问题（还存在许多其他不方便的问题）。这样的话我有两个方案，一个是在目前的存废流程下先尽快启用relist（积压太严重了），单独页面问题之后再说；二是先启用单独页面，再启用relist，不会造成编辑历史不完整

--百無一用是書生 (☎) 2023年1月5日 (四) 02:27 (UTC)[回复]

我的观点是，为了优先解决积压问题，我可以暂时忍受编辑历史不完整的问题--百無一用是書生 (☎) 2023年1月5日 (四) 02:41 (UTC)[回复]

我也支持先尽快启用relist处理大量积压，不过要长期实行的话，启用单独页面的措施也需要尽快提上日程。--BlackShadowG Slava Ukraini! 2023年1月5日 (四) 03:41 (UTC)[回复]

一般長期沒有討論的案件，單純的關注度不足佔大多數，要證明沒有關注度很難，要證明有關注度很簡單，所以沒有關注度的話，其實一般都不會有留言，畢竟「我認為這個條目沒有關注度」並不代表「這個條目真的沒有關注度」。而且一般要合併的條目都是管理員掛上{{Merge}}模板，之後待人處理。然後那些已經吵了很久的討論，不停{{relist}}也不會有結果。--Ghren 🐦🕚 2023年1月5日 (四) 03:04 (UTC)[回复]

relist主要并不是为了处理那些吵了很久的討論，吵了很久都没共识基本上就是无共识结案。relist主要是为了让没人关注的讨论更容易获得关注，沒有關注度的条目也是需要共识结案的，relist的目的正是增加进一步讨论达成共识的可能性。--BlackShadowG Slava Ukraini! 2023年1月5日 (四) 03:48 (UTC)[回复]

依過去的習慣，沈默那就是弱共識，這些頁面一樣可以刪除。如果認為這不妥的話，更應該引入的其實是en:Wikipedia:Proposed deletion的方式，沒人討論就當是PROD掉就好啊。掛上Relist之後有多少效果呢，近這幾天也有很多案件沒有人討論不是嘛，為什麼會認為新案件沒有人討論，將舊案翻抄會有人討論呢？--Ghren 🐦🕓 2023年1月5日 (四) 08:59 (UTC)[回复]

enwiki施行relist已经10几年了，看起来行之有效值得借鉴，也能解决中文版目前面临的一些问题，那何乐而不为呢？--百無一用是書生 (☎) 2023年1月6日 (五) 02:36 (UTC)[回复]

此外还有一点，就是变相延长了共识难以达成情况下的讨论时间，如果按照我上面的建议流程，最长可以有15周时间讨论且有最多3次机会出现在用户关注最多的当天存废讨论页面上。

另外关于弱共识，的确以前我没人讨论可能也就删了，但是这对管理员的知识广度和认知能力的要求太高了，很容易删错页面；而且有些没人讨论的可能管理员还需要查证一番才能做出判断，非常花时间，也容易造成独断专行问题（毕竟无人讨论自己调研决定去留，容易失误，知识的宇宙太广袤了，不是一个人的人力所能及）。弱共识在处理存废讨论上，我认为除非是非常明显的提删理由，否则最好还是再稍微强一点比较好，方便管理员可以直接根据讨论来判断去留，而不用自己去调查研究一番，管理员也不是一天有25小时的怪物--百無一用是書生 (☎) 2023年1月6日 (五) 02:57 (UTC)[回复]

個人同意這點。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年1月8日 (日) 21:15 (UTC)[回复]

討論延長根本無助生成共識啊。一般來說，刪除討論有實際討論的一般都只是頭幾天，過幾天之後就不會有討論了。中維參與存廢討論的人本身就不多。一般留下來的案件都是些公說公有理，婆說婆有理的案件，又或者在關注度邊緣的案件。要證明沒有關注度畢竟很難；要證明有關注度畢竟很簡單。就像是這些案件，條目內沒有關注度來源，那就刪掉啊。一般的維基人根本很難查證這些條目有沒有當地的紙本來源，就算有線上來源，根本就看不懂。反而證明這些條目有關注度很簡單啊，只需要將參考文獻寫上去就行了。要證明沒有黑天鵝很難，但是要證明有黑天鵝很簡單啊，所以舉證本來就應該在保留方啊。除非有很多人熟悉這個主題，又或者有比較專業的編者，否則根本上很難證明完全沒有關注度。在這樣的情況，我覺得直接刪掉沒有什麼大問題。

英維可以將Relist制度行之有效的原因主要是英維的人數比較多，學術平較高、對方針指引的熟悉度也夠。中維沒有這個底子。討論法語譯名的時候，就只有兩個長篇大論幾萬個KB；討論四字神名的時候，一個歷史學、宗教學或神學的人都沒來，由9月底到1月，一個實際意見都沒。這是我的印象。然後其實當日的存廢討論閱讀量也不是很高，也就百來次左右。--Ghren 🐦🕕 2023年1月10日 (二) 10:51 (UTC)[回复]

條目內沒有關注度來源不能成为删除的理由啊--百無一用是書生 (☎) 2023年1月10日 (二) 12:10 (UTC)[回复]

是啊。但是這是沒有冲突的啊。證明沒有關注度畢竟很難，證明有關注度很簡單啊。--Ghren 🐦🕚 2023年1月11日 (三) 03:44 (UTC)[回复]

英文版w:WP:RFD是每天一个页面，但是也有relist过程。--GZWDer（留言） 2023年1月6日 (五) 04:50 (UTC)[回复]

這邊提一個爛建議：提刪的時候把所有編輯過該頁面的已註冊使用者在提刪頁面或是討論頁全部ping一遍。--122.100.88.32（留言） 2023年1月6日 (五) 15:12 (UTC)[回复]

不妥，会造成骚扰，也许是潜在拉票（编辑者没有提出存废）。较合理方案是用户主动订阅此类通知，机器人通知曾在条目进行足量扩充（较难判断）或一段时间内有过编辑的用户。热衷关注存废的用户，通常已监视页面或存废讨论。--YF dyh000（留言） 2023年1月6日 (五) 16:42 (UTC)[回复]

@YFdyh000：我認為不構成騷擾，編輯過該條目的，顯然對該條目有興趣，興趣至少比只看條目不編輯的使用者高一點。 -- Shyangs（留言） 2023年1月9日 (一) 08:34 (UTC)[回复]

将条目加入关注列表的用户可以考虑，另外如果允许 ping，还得允许不接受 ping。--Kethyga（留言） 2023年1月10日 (二) 10:59 (UTC)[回复]

离题了。此外即使是目前，提删者也可以自行手动查看编辑历史，向条目的主要编者发通知。没有必要做强制的规定。--BlackShadowG Slava Ukraini! 2023年1月8日 (日) 12:42 (UTC)[回复]

已经写了一个relist脚本在测试wiki上[1]，虽然有一些毛病，倒也堪堪能用。--百無一用是書生 (☎) 2023年1月12日 (四) 07:42 (UTC)[回复]

对WP:RELIST做了一下修订，期望能够把这部分提升为指引：

--百無一用是書生 (☎) 2023年1月12日 (四) 08:03 (UTC)[回复]

即使有所顾虑，也至少希望能够试用一段时间看看效果--百無一用是書生 (☎) 2023年1月12日 (四) 08:14 (UTC)[回复]

我不認為這有什麼用，但是不反對您們試試看。但是不認為重新提交三次有什麼實際作用，重新提交一次就夠了。而且我想假如討論真的能夠持續五周的話，重新提交也沒有意思。--Ghren 🐦🕕 2023年1月12日 (四) 10:50 (UTC)[回复]

既然如此，建议2月1日之后开始试行如何？--百無一用是書生 (☎) 2023年1月17日 (二) 06:14 (UTC)[回复]

(＋)支持試行，好的壞的都是在實際運作後才出現的。--Mafalda4144（留言） 2023年1月17日 (二) 13:45 (UTC)[回复]

似乎不用等这么久吧。--BlackShadowG Slava Ukraini! 2023年1月18日 (三) 11:50 (UTC)[回复]

看来大家认为至少可以尝试。特此公告5日，如无其他的合理反对意见，公告结束后将实行。另，开始实行时，因积压较多，建议每天不要重新提交太多积压的存废讨论，每天少于10条为宜？逐渐过渡到正常状态--百無一用是書生 (☎) 2023年1月19日 (四) 02:17 (UTC)[回复]

两种可能的排版方案，供参考。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年1月23日 (一) 11:02 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

WP:RELIST的内容已更新，相应模板和流程暂时参照英文版w:WP:RFD模式实施--百無一用是書生 (☎) 2023年1月24日 (二) 07:28 (UTC)[回复]

本案未在方针区提案且公示不足七天，且共识为试行而非定为正式指引，不宜挂指引模板。本人依据IAR，改挂临时设计的{{Guideline d'essai}}模板。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年1月24日 (二) 08:22 (UTC)[回复]

目前RELIST已經試行一段時間，看起來跟普通提刪沒什麼差別（畢竟看上去就是在最新的日期添加一條新提刪），也跟普通提刪穿插在一起，而普通提刪會通知條目創建者，那麼(？)疑問@Shizhao：RELIST是不是也應通知創建者呢？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月2日 (四) 04:41 (UTC)[回复]

这不是结束之前的讨论后再次提交删除，只是之前讨论的延续，之前通知过了没必要再通知了吧？--百無一用是書生 (☎) 2023年2月3日 (五) 03:58 (UTC)[回复]

@Shizhao：由于加入了新的讨论结果，可能需要更新Module:Old vfd multi（当前例子可见Talk:大四喜 (足球)）。--东风（留言） 2023年2月4日 (六) 06:40 (UTC)[回复]

这看起来是Cewbot的问题？--百無一用是書生 (☎) 2023年2月4日 (六) 12:33 (UTC)[回复]

@Kanashimi：能否协助看一下，感谢。--东风（留言） 2023年2月8日 (三) 10:41 (UTC)[回复]

改了模組:Old vfd multi--Kanashimi（留言） 2023年2月8日 (三) 14:00 (UTC)[回复]

重新提交是之前的讨论还在继续，不应该用Module:Old vfd multi吧？--百無一用是書生 (☎) 2023年2月9日 (四) 03:46 (UTC)[回复]

好像是這麼回事。改了。--Kanashimi（留言） 2023年2月9日 (四) 05:50 (UTC)[回复]

試行檢討

@Shizhao：WP:RELIST自通過試行至今已逾一周，盤點第一周的WP:RELIST成功達成共識的狀況（截至2023年2月6日 (一) 10:52 (UTC)）：[回复]

1/24共提交10筆，成功關閉討論的有4筆；

1/25共提交10筆，成功關閉討論的有2筆；

1/26共提交11筆，成功關閉討論的有0筆；

1/27共提交10筆，成功關閉討論的有0筆；

1/28共提交10筆，成功關閉討論的有5筆；

1/29共提交10筆，成功關閉討論的有2筆；

1/30共提交10筆，成功關閉討論的有0筆；

1/31共提交10筆，成功關閉討論的有1筆；

統計期間共有共有81筆WP:RELIST，成功關閉討論的僅有14筆，成功達成共識率17%，約兩成，這流程是否真的有幫助還有待觀察討論。建議再觀察一陣子才決定是否提升為正式指引。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月6日 (一) 10:52 (UTC)[回复]
- 我認為共識達成率至少要到五成才有提升為正式指引的意義。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月6日 (一) 10:59 (UTC)[回复]
  管理员无能为什么要怪制度？--。->>Vocal&Guitar->>_留言 2023年2月7日 (二) 04:35 (UTC)[回复]
  至少还达成了两成啊，另外，达不成共识和管理员有什么关系？
  
  其他数据的话，目前积压数量减少了大约2/5（relist实行开始511个积压讨论，今天最新的一次数据是322，历史最低288），积压天数减少了约70%（从112天减少到了33天，历史最低32天）--百無一用是書生 (☎) 2023年2月7日 (二) 09:02 (UTC)[回复]
  另外，在我看来，WP:RELIST首要解决的是积压问题，其次是减少无共识保留的问题。之前积压的存废讨论会有约一半左右以无共识结案，现在成功關閉的14筆討論可都不是以无共识结案的，但其实真实的无共识结案率还需要等到relist三次后的最终结案才能看出来。您说的“成功達成共識率17%”，在我眼中是无共识保留减少率17%--百無一用是書生 (☎) 2023年2月8日 (三) 02:48 (UTC)[回复]
  原则上放在舊的頁面積壓，還是新的頁面積壓，還一樣都是積壓啊。--Ghren 🐦🕒 2023年2月8日 (三) 07:10 (UTC)[回复]
  
  另外，成功達成共識率似乎没有算上待处理的？例如1/29提交的10筆中最终有共识但须待处理的就有5个（即7个达成共识，其中2个成功关闭，5个达成共识但仍待处理）。也就是说成功關閉討論的数量和成功達成共識的数量是不等的--百無一用是書生 (☎) 2023年2月8日 (三) 14:09 (UTC)[回复]
  这样算下来達成共識率约是34%--百無一用是書生 (☎) 2023年2月8日 (三) 14:22 (UTC)[回复]
  
  用python画了个统计图[2], 时间为从今年元旦开始一直到现在--百無一用是書生 (☎) 2023年2月9日 (四) 09:46 (UTC)[回复]
  
  我不是說流程沒用，而是希望流程能有更高的用途。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月16日 (四) 05:24 (UTC)[回复]
@Shizhao：WP:RELIST自通過試行至今已逾一個月，上次盤點第一周的WP:RELIST成功達成共識的狀況，現在盤點第二周的WP:RELIST成功達成共識的狀況（截至2023年2月24日 (五) 14:21 (UTC)）：[回复]

1/31共提交10筆，成功獲得共識的有10筆 (其中2筆於二度重新提交時獲得共識)；

2/1共提交11筆，成功獲得共識的有9筆 (其中2筆於二度重新提交時獲得共識)；

2/2共提交10筆，成功獲得共識的有8筆 (其中3筆於二度重新提交時獲得共識)；

2/3共提交9筆，成功獲得共識的有3筆 (其中0筆於二度重新提交時獲得共識)；

2/4共提交12筆，成功獲得共識的有7筆 (其中1筆於二度重新提交時獲得共識)；

2/5共提交10筆，成功獲得共識的有5筆 (其中0筆於二度重新提交時獲得共識)；

2/6共提交10筆，成功獲得共識的有9筆 (其中0筆於二度重新提交時獲得共識)；

2/7共提交10筆，成功獲得共識的有4筆 (其中0筆於二度重新提交時獲得共識)；

統計期間共有共有82筆WP:RELIST，成功關閉討論的僅有55筆，成功達成共識率67%，約七成，明顯可以看出，這個流程是有效的，故(＋)支持WP:RELIST升格為正式指引。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月24日 (五) 14:21 (UTC)[回复]
若立为指引，是不是应该并入Wikipedia:删除方针#存废讨论一节？WP:删除程序只是论述，中间插一段指引段落有点怪。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年2月24日 (五) 17:15 (UTC)[回复]
就我观察，实行relist以来，还未有一笔讨论因无共识保留而关闭（另一个观察是，一个月以来，进入积压的讨论中有持续超过两周的讨论最多也不超过5笔，因此我认为“持續五周”的条件基本上没有意义）--百無一用是書生 (☎) 2023年2月25日 (六) 12:26 (UTC)[回复]

在我看来，Relist實際上根本無法促進共識，像Wikipedia:頁面存廢討論/記錄/2023/02/01#Template:值得列印的重定向、Wikipedia:頁面存廢討論/記錄/2023/02/02#瘋狂過山車，這些Relist了以後，沒有人提出新理由然後就刪除的內容很多。這和管理員獨斷刪掉是沒有分別的。實際上，Relist之後有新理據協助管理員決定刪除與否的刪除提案感覺不是很多。--Ghren 🐦🕘 2023年2月25日 (六) 13:05 (UTC)[回复]

非管理员能执行重新提交吗？--东风（留言） 2023年3月4日 (六) 09:33 (UTC)[回复]

所以試行結果如何？是否要繼續試行或正式上路？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年4月4日 (二) 11:06 (UTC)[回复]

不建議正式上路。--Ghren 🐦🕐 2023年4月4日 (二) 17:29 (UTC)[回复]

這一看就知道討論完全沒有意義，甚至不必參與討論，真可憐。居然連不建議正式上路都出現了，可見這個獨裁社群就是喜歡沒事找事做，最後到頭來一場空。Wikipedia:頁面存廢討論、Wikipedia:檔案存廢討論顯然都快要成所謂的廢棄物處理場了，但沒有這個廢棄物處理場也不行。--Z7504非常建議必要時多關注評選（留言） 2023年4月4日 (二) 17:55 (UTC)[回复]

@Shizhao。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年5月1日 (一) 15:18 (UTC)[回复]

@Shizhao？如果沒有肯定結論，應該考慮停止試行，避免造成所謂「無限試行」的情況。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年5月12日 (五) 09:26 (UTC)[回复]

结论是存废积压情况要比此前大大减轻，现在基本上除了待处理的讨论，积压不会超过2天（再勤快一些可以做到基本无积压），无共识保留的情况也比此前大大缓解，以前积压的讨论大约有将近一半最后会无共识保留，现在只是偶尔会有无共识保留。如果停止目前做法，就又回到以前一大堆积压，最后一半都无共识保留的状态。当然，如果社群认为积压无所谓，无共识保留也无所谓；或者宁可积压，也不要用relist的方式解决积压问题，那我也无话可说--百無一用是書生 (☎) 2023年5月12日 (五) 12:01 (UTC)[回复]

重新贴一次到目前为止的统计图[3]--百無一用是書生 (☎) 2023年5月12日 (五) 12:07 (UTC)[回复]

所以這代表什麼？首先您這個算法計算的只是計算在Wikipedia:頁面存廢討論/積壓討論中顯示的頁面，積壓的條目只是都relist到存廢討論去了。所以數字上看上很亮麗，實際上根本只是通過重新定義「積壓」這一個概念來解決問題。

二者，「無共識保留的情況也比此前大大緩解」的原因是什麼？是討論增加了，增長了共識的形成？如果是，討論增加了多少？討論度增加是relist的功效，還是單純是因為討論出現在一個比較多人瀏覽的頁面？如果只是單純因為出現一個比較多人瀏覽的頁面，我相信有很多其他更合適的方法啊。我又看了一下，發現這三四個月來，存廢討論估計有八成是Shizhao閣下您結案的，有多少的案件，是討論自己已經形成大致的共識，而不是您個人的「獨斷」參與其中，而引致無共識的情形得到緩解？而且，這樣的「試行」很容易形成Shizhao期待relist有用，而您的行為實現了這個預言。這是自證預言。

三者，積壓重來都不是問題，在您維的站務中存廢討論本身就不是重要度很優先的。--Ghren 🐦🕐 2023年5月12日 (五) 17:24 (UTC)[回复]

relist的作用就是增加讨论的可见度，如果有其他更好的办法，请不吝赐教。毕竟目前的这种办法在enwiki也实行了很多年了，看起来卓有成效。无共识缓解的情况当然是明显因为讨论增加了--百無一用是書生 (☎) 2023年5月13日 (六) 08:27 (UTC)[回复]

就算是這樣，假設成效真的只是形成書生認為的結果，不是真的成效（這讓我想到N射線實驗）就算是這樣，就算正式上路也不會造成危害啊，然後積壓天數也確實能夠減少。既然無害，又有點（數據上的）效果，那何嘗不能正式上路？英文維基不是也實行多年了？試行期間也沒啥問題啊，又不是爆炸了要立刻停機？未見有什麼不能正式上路的理由。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年5月21日 (日) 07:43 (UTC)[回复]

強烈要求停止試行，時昭老爹都把一些明顯沒有異議的東西重複提交了四五次了，能不能快點自己處理，不要等著別人浪費時間投刪除票，管理員自己不會判斷嗎？--🎋竹生🎍 2023年5月31日 (三) 04:32 (UTC)[回复]

除非能雪球，不然执行管理员不应避嫌吗？没有表态为什么就代表没有异议。如果管理员自己有意见，就自己投票、其他管理员处理。--YF dyh000（留言） 2023年5月31日 (三) 09:04 (UTC)[回复]

問題是你維關注度提刪的風氣一向都是應刪除的不會有什麼人特別去投刪除票，有價值保留的才會有人去提保留證據。結果就造成現在這裏無限relist-某人 ✉ 2023年6月21日 (三) 17:12 (UTC)[回复]

那说明没有明显的删除意向与共识，继续无共识保留吧。总不能弄些机器人留言投石问路^{[開玩笑的]}--YF dyh000（留言） 2023年6月21日 (三) 17:16 (UTC)[回复]

我認為在重新提交存廢討論數次（具體次數可以討論）後應可預設以無共識保留。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年6月26日 (一) 13:00 (UTC)[回复]

近期看到关闭讨论的判定和结论仍有自由裁量的部分，以及对避嫌、结案理由等要求可能存在不足和模糊之处。期望尽快得出相关共识，但个人不会提出议案。--YF dyh000（留言） 2023年6月26日 (一) 17:41 (UTC)[回复]

显而易见，证明有关注度容易，证明无关注度难。证明有关注度找到个关注度来源就行；证明无关注度则需要尽可能把所有可能有用的来源都搜索过一遍，还是没有关注度来源，才能下结论。--BlackShadowG Slava Ukraini! 2023年8月9日 (三) 14:16 (UTC)[回复]

感觉不必也不是尽可能，只要有共识认为无改善和保留价值就可以了。--YF dyh000（留言） 2023年8月9日 (三) 16:49 (UTC)[回复]

回過頭看之前的討論，還是太想駁一駁上面的論點了。這哪裏需要「避嫌」了？WP:避嫌對刪除的要求僅限於「管理員不得刪除自己提議刪除或者投票刪除的頁面」，請問這妨礙處理AFD的管理員什麽了？--🎋竹生🎍 2023年12月17日 (日) 12:17 (UTC)[回复]

其实是不是可以把RELIST时间和正常结案时间错开试试，比如RELIST改成一个月之类的，现在7天一到就RELIST，RELIST之后又要等7天，我不觉得以现在的人手有几个管理员能天天守着存废讨论，这只会造成上面说的书生一个人反复RELIST。--淺藍雪^❉ 2023年8月16日 (三) 06:58 (UTC)[回复]

@AINH、YFdyh000：話說我才發現一開始Shizhao君的提案就有提到「同一個討論最多可以重新提交三次，若三次後仍無共識，則以無共識結案」了啊。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年9月16日 (六) 13:46 (UTC)[回复]

（副知@Shizhao）—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年9月16日 (六) 19:27 (UTC)[回复]

relist我操作没有超过3次的（可能会有一两个例外）--百無一用是書生 (☎) 2023年9月17日 (日) 06:38 (UTC)[回复]

有些“无共识”结案的其实根本就不是无共识，或者即使没讨论按现行标准也是很明显的删除或保留，如果只有一两个管理员RELIST，而且还是7天一到马上RELIST，说实话还不如积压着算了。淺藍雪^❉ 2023年9月20日 (三) 07:28 (UTC)[回复]

配合#设立「邀请讨论」及「管理员处理决定公示」机制是否就可以解决「按现行标准也是很明显的删除或保留」的问题，RELIST之后还是无人讨论，管理员就可以随机邀请别人参与讨论。若还是没人参与或者无共识，管理员就可以作出裁量并公示，如果社群没有一致反对管理员的裁量结果，管理员就可以执行删除或保留。--桐生ここ★[讨论] 2023年9月20日 (三) 07:39 (UTC)[回复]

我感觉问题本质不光是参与人数不足，活跃管理员太少也是原因，更何况RELIST制度本身也有缺陷，拉长RELIST时间（或者根本没有RELIST）可以让更多管理员有机会处理，之前没有RELIST的时候还有几个其他的管理员来看看，现在7天立刻RELIST，基本就只剩下书生了。依靠一个人运行的体系我不觉得能够长久且不出问题。--淺藍雪^❉ 2023年9月20日 (三) 07:52 (UTC)[回复]

我不太明白，RELIST并不会阻止管理员处理啊。我不认为其他管理员极少参与和RELIST有什么关系，在我看来，RELIST其实更方便了管理员的处理工作（为什么RELIST会减少管理员处理的机会呢？我实在想不明白）。还有，“有些“无共识”结案的其实根本就不是无共识，或者即使没讨论按现行标准也是很明显的删除或保留，”能否举几个例子？我翻了半天也找不到你说的情况。此外，还存在两个两难问题：有些人认为积压没什么问题；另有些人认为积压是大问题。有些人认为每个VFD都应该充分讨论出共识才能结案；有些人认为“很明显”的就直接保留或删除就好了（但“很明显”似乎太主观了，每个人的“很明显”可能都不一样）--百無一用是書生 (☎) 2023年9月21日 (四) 03:17 (UTC)[回复]

第一点：这个只要翻现在每天的存废记录和没有启用RELIST之前的存废记录我感觉十分明显，比如今年9月和去年9月的记录。从我的角度来看是因为大部分人不愿意每天守着存废讨论（无论是因为情感上还是时间上）。从情感上，我只从我的角度讲，七天一到马上RELIST从某种程度上把存废讨论变成了一个每日要紧盯着的工作，不是很舒服，我也没有那个时间和兴趣，而且谁知道我去看的时候是不是已经被RELIST了。已经RELIST的又不让处理，如果有个我知道该怎么处理的，还得等七天抢在被RELIST之前处理，我更没那个耐心再等七天。别的管理员也许有其他想法，但现实是不RELIST的时候，总会有其他管理员去看的，虽然可能是抽时间。

第二点：“有些“无共识”结案的”是我没说清楚，我有两个意思，(1，假设，如果，按“同一个讨论最多可以重新提交三次，若三次后仍无共识，则以无共识结案”，将可能导致RELIST的里面一些条目被“无共识”结案。比如Wikipedia:頁面存廢討論/記錄/2023/09/20#成都市医疗机构列表（假设重新提交满三次后，讨论仍没有结束，这时候是放着积压吗？还是无共识结案？而且这个其实是还在讨论中，只是提删日期到了七天，不是最后一次讨论到了七天，这直接RELIST岂不是相当于浪费了一次。），有些RELIST可能是没必要的。(2, 举个实际的例子，Wikipedia:頁面存廢討論/記錄/2023/09/09#天牛科的属，至少这个从我一个经常写生物学条目的人来看，很明显就是把这个条目删了，内容拆到各个亚科里面就是了，分类一直以来都是这么操作的，如果是单独建立“天牛科的属”（i.e.天牛科的分类），那需要有别的东西，比如分支图和不同学者的分类办法，现在这个条目根本就只是单纯点列、可以分类取代而已。而且从这个存废的已有讨论来看，发表意见的都是这个意思，我不明白为什么这个要无共识结案。再比如这个下面的針灸著作列表，这内容虽然有几句话和一个来源，但实际上根本言之无物，本质上是个纯粹点列，要我判断的话是删，根本不需要RELIST。结案之后我记得是6个月不能以同样理由提删，这种放6个月，说实话我很难受。当然你可以不同意我在这个第二点里表达的意见，认为这只是不同管理员之间判断的差异（正如“两难”问题里指出的），但如果你认为我第一点说的在理的话，第二点问题存在本身（或者说你和我的分歧存在本身）就是源于没有足够的其他管理员去看存废了，而至少我和去年9月的那些人之前是会去看的。当然也可以说，这些我不同意的存废也可以丢到复核，但说实话如果不是我为了回答这个问题去看，我不会知道关注到这些，而且复核本身关注度更低，谁知道解决不解决得了。

第二点的关键没有哪个管理员能一个人明确判断所有条目，即便是有社群投票，仍然可能会出现““天牛科的属”是无共识”或者别的什么不合适的判断，这个按以前可以留下来给别的人判断的。

解决办法我之前也提到了，就不赘述。至于两难问题，积压我并不在意，就不予置评了。讨论充分不充分，需要不需要充分，我觉得这个交给不同管理员判断就行了，不可能让所有人满意，本来就人手不够，想要每个条目都讨论充分根本不可能。--淺藍雪^❉ 2023年9月21日 (四) 12:43 (UTC)[回复]

“天牛科的属”在我看来只能无共识处理。的确共识是要拆成多个亞科條目（此部分有共识），但问题是没人建立这些亞科條目，也没人说应该建立哪些亞科條目（此部分无共识），因此只能无共识结案。哪怕有人说应该拆成a、b、c、d亚科，那都可以不用无共识结案了。其他问题我有时间再回--百無一用是書生 (☎) 2023年9月22日 (五) 09:57 (UTC)[回复]

另外，从未有过已经RELIST的不让处理这么个规定--百無一用是書生 (☎) 2023年9月22日 (五) 09:58 (UTC)[回复]

我会有这个想法是因为Special:diff/76622681之前我处理RELIST的时候不止一个人说“已違反存废讨论中的存廢討論應該持續至少七日”、“不符合最起碼的程序正義”云云，除了这个应该还有一个但是我想不起来了。因为虽然我也不觉得RELIST就不能处理，实际上由于RELIST导致对应讨论又处于一个新的“七天”周期里，这个想法的出现本身我能够理解。如果不是的话，可能需要方针哪里澄清一下。--淺藍雪^❉ 2023年9月22日 (五) 14:59 (UTC)[回复]

WP:刪除：「若頁面在存廢討論中有共識地保留……否則不應在6個月內以相同的理由重新提刪該頁面」，無共識結案不受六個月限制，已重新提交。--🎋竹生🎍 2023年12月18日 (一) 13:56 (UTC)[回复]

另一個問題是因為重新提交了，技術上就不算在「積壓討論」裡頭，於是導致這些實際上積壓的討論與新提出的討論全部混雜在一起，說實話看著也有點疲勞。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年9月22日 (五) 11:28 (UTC)[回复]

如果确实RELIST不算正常存废讨论按七天重新计算、可以自由处理的话，其实我的大部分意见也就不存在了（除了“成都市医疗机构列表”例子里重新计算RELIST时间点这个），但实际上确实很容易引起误解。--淺藍雪^❉ 2023年9月22日 (五) 15:13 (UTC)[回复]

主要是那些重新提交的討論，我到底是要再預設等一週，還是既然已經超過一週了，能結案就趕快結案？實際上是很混亂的，沒辦法像以前那樣看幾天以前的存廢討論就直接處理。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年9月23日 (六) 14:37 (UTC)[回复]

是的，我就是这个意思。--淺藍雪^❉ 2023年9月23日 (六) 14:48 (UTC)[回复]

又話說，Old vfd multi模板能不能支援重新提交討論格式了？例如桑德戴爾的存廢討論結果應該是「2023年9月11日送交存廢討論」，「（9月19日）討論結果為保留」，而不是像現在這樣分開。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年10月2日 (一) 06:15 (UTC)[回复]

是分开加的模板源码，应该不能吧。relist为结果的，感觉不加、不显示Old vfd multi模板就可以了。--YF dyh000（留言） 2023年10月2日 (一) 06:30 (UTC)[回复]

問題是這討論的時間應當收錄第一次提交討論的日期，討論連結及結果則是應該引用最後一次提交的情況。而目前模板似乎不支援此功能。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年10月2日 (一) 09:02 (UTC)[回复]

“第一次提交讨论的日期”应有但似乎意义不大了，那个日期的页面下没有效内容了，源码中保留但不显示可以吗。对于检查编辑历史，挺麻烦的，但relist本身也做了割裂。--YF dyh000（留言） 2023年10月2日 (一) 09:07 (UTC)[回复]

在處理完這種技術問題以前，恐怕都不能脫離「試行」階段。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年10月11日 (三) 06:46 (UTC)[回复]

若討論中提到的某些問題長期不能解決，我認為應當終止「試行」此制度。不能放任所謂「永久試行」的亂象出現。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年11月13日 (一) 02:45 (UTC)[回复]

那就麻煩Shizhao君對沒人反對且提刪理由成立的被提刪條目直接刪除而非反復重新提交（另外就所謂避嫌問題，我剛剛已經在上面回應了）。--🎋竹生🎍 2023年12月17日 (日) 12:20 (UTC)[回复]

“提刪理由成立”是个看起来简单但实际非常复杂的事情，常常就是你认为提刪理由成立，他认为提刪理由不成立。你所说的“沒人反對且提刪理由成立”很有可能演变成为了删而删--百無一用是書生 (☎) 2023年12月18日 (一) 03:42 (UTC)[回复]

{{follow-up}}最好不要直接subst，可以修改一下模板，待处理的操作可以加一下不同的分类，例如Category:需要合併的條目, Category:转移到其它维基计划候选的分类，然后加一个done=yes的参数去掉分类（类似editprotected?）及时雨 ^留言 2023年12月7日 (四) 04:46 (UTC)[回复]

两个参数：

done=yes, 只加入类似Category:已处理的存废讨论共识的分类，不加入下面的任何分类
action=merge（在done=no时，加入Category:已被允許合併的頁面）, wikiversity (加入Category:移动到维基学院候选）等等

也许分类可以改别的，不然条目和存废讨论页面共存有点奇怪。不知道是否有人觉得大致想法可行？--及时雨 ^留言 2023年12月16日 (六) 05:40 (UTC)[回复]

重新提交行不通原因有二：存廢討論本身參與人數不足（源自社群習慣認同時默認而非參與）、執行過於複雜（存廢討論目前按日而非按頁提報衍生大量技術問題）。目前重新提交制度跟原先擺爛其實差異不大，只是不斷滾存到新的存廢頁面，沒有解決任何問題。討論參與人數不足，解決方法離不開管理員按僅有意見結案（就算只有提案人一條意見，只要不是明顯不符合方針的刪除請求，擺兩週無人參與也予以執行）。--路西法人 2023年12月17日 (日) 12:52 (UTC)[回复]

在我看来，relist还是促进了讨论和共识的形成，也明显减少了积压。而且作为管理员来使用relist，非常舒适，流程化很好，效率很高。如果不用relist的话，我觉得就又会回到以前那种积压状态（没了relist，我对处理积压问题也就大大缺乏兴致了，毕竟在操作上麻烦了很多，会占用更多时间）。另外，我也建议其他管理员也多多试一下relist，感受一下它的利弊（有时站在旁边看可能未必会感同身受）--百無一用是書生 (☎) 2023年12月18日 (一) 03:48 (UTC)[回复]

不過重新提交好像還存在些微的技術問題？另外，目前比較熟練的還是您，萬一您改天比較不活躍時，該怎麼辦？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月29日 (一) 17:08 (UTC)[回复]

有人用就行啊--百無一用是書生 (☎) 2024年1月30日 (二) 02:04 (UTC)[回复]

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到試行結果出爐。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

對新用戶禁用內容翻譯工具

原标题为：Disable Content Translation from brand new users

已通过：

请等待部署，同时请移步后续的讨论。Milky Defer 2023年10月28日 (六) 15:08 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

Morning,

Patrolled around some new pages and played with translation tools for a while, I believed nearly all contents introduced by Content Translation from new users are generally horrible machine translation, some of them are even in bad faith. I suggest disabling this feature from newcomers and limit it only for wikipedia:EXTENDEDCONFIRMED. Here are some examples:

鲸类智力
奧斯朋效應
更新世野化
新宿尼亚加拉瀑布
醫學藥學大學，河内國家大學
詹姆士·赫伯恩
宇都宫聪 -- bad faith translation (attack page)

P.S. I'd checked them one by one, by putting them in Content Translation tool using different translation engines again.--Lemonaka（留言） 2023年10月17日 (二) 12:31 (UTC)[回复]

@Ericliu1912 Lemonaka（留言） 2023年10月17日 (二) 12:32 (UTC)[回复]

幫當事人翻譯一下：

他實際巡查條目並上手試驗內容翻譯工具，認為幾乎所有新手使用該工具所產出的作品品質都很惡劣，到能直接以G13準則快速刪除的地步，甚至可能有惡意誤譯者。他認為應該對新手預設禁用內容翻譯工具，只允許達到延伸確認使用者資格的編者使用。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年10月17日 (二) 12:36 (UTC)[回复]

是我錯覺還是以上文字也是機翻出來的

--Iridium(IX) 2023年10月17日 (二) 13:50 (UTC)[回复]

十分同意，至少可以減少一下巡查員的壓力，但個人認為自動確認已經夠了。--Hoben7599—論 | 支持立場新聞 2023年10月17日 (二) 13:55 (UTC)[回复]

他说得对。——Sakamotosan路过围观 | 避免做作，免敬 2023年10月17日 (二) 13:49 (UTC)[回复]

偶然遇过一些编辑使用这个工具进行翻译（也就是编辑会被标签为“内容翻译”），经常出现格式不合要求（例如：半角标点（包括逗号、结尾点句号、双引号、圆括号，甚至有些前面还有半角空格），作品名斜体，数字前后不必要的空格（例如日期、数量词前））、文句不顺畅的疑似机器翻译未修正、不和本地用语惯例（常见的“也可以看看”）的情况。最近我见过例子有（User:Orrt0000 ）的火焰噴射戰車（偶然抽出看到）、機動防護火力車（提醒过，我可能修改过？），失敗不是一個選項（oldid=79396409），Three（oldid=79314028，之后有修葺，但还不足够（oldid=79323303））。这非常依赖新页面巡查的巡视、修葺和指导，但考虑到新页面巡查现在活跃强度……我甚至觉得有没必要将新建页面的级别也拉高一级

。——Sakamotosan路过围观 | 避免做作，免敬 2023年10月17日 (二) 14:07 (UTC)[回复]

這個嘛，上次提出要將新建頁面提昇到自確以上的提案最後以修改A5為G18做收，短期內應該不太可能發生，況且AFC草稿積壓也確實嚴重。--冥王歐西里斯（留言） 2023年10月18日 (三) 03:59 (UTC)[回复]

AFC草稿積壓嚴重的話，那新建頁面還是維持不變，允許任何人新建條目，不然就沒多少新條目了。其實一眼看出就要刪除的條目刪的還是挺快的。--日期20220626（留言） 2023年10月18日 (三) 04:15 (UTC)[回复]

这东西嘛，鸡肋，老人有能力用wikicode从零直接起手，知道大部分格式方针规则，用沙盒（用户子页、草稿空间）打底后再转正，新手用这个工具问题不少。——Sakamotosan路过围观 | 避免做作，免敬 2023年10月17日 (二) 14:11 (UTC)[回复]

自动确认就足以了，不需要到延伸确认，都延伸确认了可能就不需要用了。--桐生ここ★[讨论] 2023年10月17日 (二) 15:18 (UTC)[回复]

@Lemonaka: I wish to hear your personal stance. It is acceptable if we restrict the use of translation providers to extended-confirmed users, but leave the standard translate interface accessible for everyone? That essentially means that inexperienced users are forced to translate fron scratch using the standard translation interface (that are also featured in Crowdin, Transifex, etc.), while experienced users have additional access to machine translation providers as a starting point? Milky Defer 2023年10月17日 (二) 16:03 (UTC)[回复]

@MilkyDefer Thanks for your comment.
Oh, that's from my experience on English project. Content Translation interface is strictly limited to extended confirmed user there. But even they are not allowed to use translation providers, meaning machine translation providers are totally disabled.
However, maybe we need some adjustments for Chinese Wikipedia, where I'm not familiar with rules and policies.
TLDR: On the English Wikipedia this tool is limited to extended confirmed editors, and the machine translation component is disabled for all users. Lemonaka（留言） 2023年10月17日 (二) 16:15 (UTC)[回复]

一点简单的澄清。内容翻译工具和机器翻译是两回事。

内容翻译功能提供原文和你的译文草稿的两栏对照界面。
你的译文草稿可以从零开始手写，也可以让机器翻译顶上。

	内容翻译功能	在内容翻译功能内使用机器翻译
英维	仅限EC、管理员	完全禁用
德维	所有人	完全禁用
日维	所有人	完全禁用
其他大wiki	所有人	所有人
中维现状	所有人	所有人
你想要的中维	？	？

仔细看了一下可用的配置，内容翻译功能可以依照权限启用，机器翻译就只有true/false选择。 --Milky Defer 2023年10月17日 (二) 16:38 (UTC)[回复]

AC, EC and sysop only for the first blank per above discussion, no obvious consensus for the second blank. Just from my perspective, it should be disable. Lemonaka（留言） 2023年10月17日 (二) 16:53 (UTC)[回复]

zh: 反正我是在全域停用了CX并且用global.css屏蔽了所有与之相关的element，谁爱用用去。中维的话，至少机翻功能不应该给新手吧？那就没啥好说的咯。

en: Well, I disabled CX globally and used global.css to block every element associated with it. Whoever like to use it, go ahead. As for zhwiki, I guess at least machine translation tools shouldn't be provided to the new users? Then that left us with few choices. ——魔琴 [ 留言贡献新手2023计划 ] 2023年10月17日 (二) 17:08 (UTC)[回复]

不知道能否跟开发者提要求，让机器翻译可以根据权限启用。

个人认为内容翻译对于新手友好，应该对所有人启用；机器翻译应该需要权限，但不一定就要禁用。

一般来说中文维基百科需要翻译其他语言的维基百科，而English Wikipedia不需要翻译，因为一般都是英文翻译到其他语言。--桐生ここ★[讨论] 2023年10月17日 (二) 18:29 (UTC)[回复]

(＋)支持 ——魔琴 [ 留言贡献新手2023计划 ] 2023年10月18日 (三) 02:01 (UTC)[回复]

建議將內容翻譯改為至少自確才能開啟（延確也不反對），至於機器翻譯如果目前只能開或關的話，那麼建議先關掉這個功能。--冥王歐西里斯（留言） 2023年10月18日 (三) 04:02 (UTC)[回复]

我觉得禁用机器翻译没啥问题，至少我留意到的两个问题（文段不顺、惯用词）可能是机器翻译导致的。至于标点和格式，是来自机器翻译还是内容翻译系统不适配的问题不确定，里面这些问题的根本实际是来源于“是英文文法的语法”，这种基础问题连内容翻译都没有解决，这样将新手的下限拉得太低了。——Sakamotosan路过围观 | 避免做作，免敬 2023年10月18日 (三) 00:14 (UTC)[回复]

内容翻译提升到自确暂时没意见。机器翻译关掉我会反对（虽然我最近不怎么翻译了），如果是技术手段来限制使用则可以，比如编辑次数<500时禁用，或者类似WP:AWB批准制，如何实现尚未研究。猜测是新页面巡查积压、新用户多导致问题更明显。另外，强制该工具创建的页面不在条目空间，我觉得会挺好的，因为创建的页面肯定需要二次修订来保质量。--YF dyh000（留言） 2023年10月18日 (三) 10:53 (UTC)[回复]

就是不知能否技術上強行實現「禁止直接發佈在條目空間」。--日期20220626（留言） 2023年10月18日 (三) 11:02 (UTC)[回复]

不了解扩展是否有选项，全局JS能做到，自动检测和追加标题前缀。问题是发布流程怎么做，WP:AFC还是允许自行或请求移动，移动后的巡查。--YF dyh000（留言） 2023年10月18日 (三) 11:20 (UTC)[回复]

Definitely and a no-brainer yes, but you need to write an AF for specific tags or edit summary. Lemonaka（留言） 2023年10月18日 (三) 13:14 (UTC)[回复]

過濾器可以做到。--桐生ここ★[讨论] 2023年10月18日 (三) 17:35 (UTC)[回复]

不确定内容翻译页面是否能显示过滤器的警告文本，能则还可以，否则体验糟糕。建议配一个全局JS来实现自动，高概率撞过滤器不太合适。--YF dyh000（留言） 2023年10月18日 (三) 17:42 (UTC)[回复]

既然是機械翻譯品質欠佳，以及機械翻譯衍生的格式不當等的問題，關掉機械翻譯功能即可。如果關掉機械翻譯後，新用戶透過內容翻譯發表的條目，相比其他不使用此工具翻譯的條目，存在更多問題以及被刪除和掛模板的比率更高，那到時可考慮禁止新用戶使用。謝謝。--SCP-0000（留言） 2023年10月18日 (三) 16:46 (UTC)[回复]

畢竟真的想使用機械翻譯的話，不用內容翻譯也可以達到。我是覺得禁止直接發佈到條目空間最好，而且有新用戶也不見得懂得如何從個人用戶頁移動到條目空間。等到他懂得如何移動了，說明他對維基的編輯有了一定的了解。--日期20220626（留言） 2023年10月18日 (三) 22:36 (UTC)[回复]

不太理解為何需要禁止直接發佈到條目空間（在已禁止機械翻譯功能的前提下）。再者，此舉便相令新手創建條目的阻礙增加（相比不透過內容翻譯），那倒不如直接禁止新手使用內容翻譯。另一方面，無論是禁用機械翻譯功能還是整個內容翻譯工具，至少指出為何需要這樣做，不然也難以說服 WMF 關掉它。謝謝。--SCP-0000（留言） 2023年10月19日 (四) 18:06 (UTC)[回复]

因为新手提交后可能很快就不管了，外人介入和处理都会很麻烦（如编辑冲突、提存废不友善），等新手自己摸索完善草稿再提交会更好。而且这工具提交的源代码常有大大小小的不足，哪怕老手操作，也需要二次编辑源码来整好，完成前其他人看到的版本可能是不成熟未完工的。--YF dyh000（留言） 2023年10月19日 (四) 22:25 (UTC)[回复]

这玩意纯属垃圾，我之前用过，觉得手感真是莫名其妙，而且翻译出来的参考文献、配图之类的错误一大堆。暑假还想给它第二次机会，去用它翻译了美洲麻鳽，结果体验实在太差，直接丢用户空间开始手动翻译。而且直接引导新手翻译FA/GA简直是反人类，这些条目动辄数万字节，一般还有各式从句等翻译难度较高的英语语法。综上，我认为内容翻译应该被彻底扫入历史的垃圾堆。——Aggie Dewa dipper 2023年10月19日 (四) 08:12 (UTC)[回复]

支持至少禁用新手使用該機械翻譯（若能限制到延確以上會更好），這翻譯出來的真的不是人讀的，而且還會出現一些不存在的模板跟不合格式手冊的內容出來。且就像前面所說，會使用這種工具的可能會翻譯完就不管條目情況了，無疑增加巡查跟刪除上的負擔。寧願先堆積在草稿慢慢消化。--WiTo^Talk 2023年10月20日 (五) 09:10 (UTC)[回复]

@魔琴 @MilkyDefer @Ericliu1912, so who's going to create a phab ticket? Lemonaka（留言） 2023年10月21日 (六) 14:52 (UTC)[回复]

We might need to put the consensus onto the bulletin board first. That is the procedure.--Milky Defer 2023年10月21日 (六) 14:59 (UTC)[回复]

參加討論的人全數同意關閉（或者至少限制）內容翻譯工具內建的機器翻譯功能。在此

公示7日：

如果phabricator認為將內建的機器翻譯功能依照權限限制在技術上是可以實現的，則優先將該功能限制在EC及以上使用者才能使用；
如果上述限制在技術上不能實現，則完全關閉該功能。

--Milky Defer 2023年10月21日 (六) 15:02 (UTC)[回复]

之前部署过一个按权限来限制publish的patch，实际情况是这个功能是不起作用的，而且Language Team并不是很喜欢进行如此的限制。 Stang^★ 2023年10月21日 (六) 16:14 (UTC)[回复]

那么，先在p站问一下？ ——魔琴 [ 留言贡献新手2023计划 ] 2023年10月21日 (六) 16:53 (UTC)[回复]

或者先请求一下zhwiki的数据，辅助更好的决策。-- ——魔琴 [ 留言贡献新手2023计划 ] 2023年10月21日 (六) 17:00 (UTC)[回复]

過往也有受理相似請求 1 2 3，並非完全拒絕之。只是社群需要清晰說明為何需要這樣做，附上相關例子及數據（如可能），而非僅是「我覺得/不覺得」。謝謝。--SCP-0000（留言） 2023年10月21日 (六) 20:18 (UTC)[回复]

要不要在其他地方也公示一下？要知道看互助客棧-其他板塊的人並不多，免得到時候有人突然來問機器翻譯怎麼沒法用了。--日期20220626（留言） 2023年10月21日 (六) 16:32 (UTC)[回复]

放上公告了。--Hoben7599—論 | 支持立場新聞 2023年10月21日 (六) 17:04 (UTC)[回复]

赞同此公示。--桐生ここ★[讨论] 2023年10月22日 (日) 14:32 (UTC)[回复]

我补充意见。如果phabricator拒绝了部署按用户组限制，但本地有能力JS实现限制，依情况和后续共识实施，而非phab部署/完全关闭的二选一。如果得出共识和界管配合，不phab也可以，已知能限制和友好提示为什么不能用。--YF dyh000（留言） 2023年10月28日 (六) 03:19 (UTC)[回复]

我的意见是，其一：很容易绕过去，有时候甚至网络连接不是很好就能绕过去了（比如在查明自动登出问题起因之前的临时规避措施）；其二：增加网页加载的难度。--Milky Defer 2023年10月28日 (六) 06:00 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

後續工作

於Phabricator查看
編號T349959的工單

這個章節用來探討後續的工作，包括回應Phabricator提出的問題，以及與受到影響的使用者之間的溝通事項。 --Milky Defer 2023年10月28日 (六) 15:12 (UTC)[回复]

(：)回應接上方讨论与表明立场。如果在MediaWiki:Common.js或全局小工具里，不会很容易绕过（以及检测完全可加强。目前未出现持续对抗风险），也不会增加网页负担。考虑过技术性绕过与传播，但这对阻止一般新用户已足够，适合灵活部署，而技术性滥用有更多做法和挑战，如AI翻译。以及，或许能用JS和滥用过滤器做出相关标记。(＊)提醒上方Hoben7599、桐生等认为自确足够，而冥王欧西里斯认为自确也可，所以请注意符合共识，phab请求的描述在我看来不完全准确。--YF dyh000（留言） 2023年10月28日 (六) 17:56 (UTC)[回复]

我直接跟你说吧，你那个所谓的js方案，这是技术上不可能的。理由是翻译工具的运作机理。在翻译界面中，你先点击新建段落翻译的按钮，然后系统默认提供了机器翻译的结果，之后你才有机会选择这一段是使用机器翻译还是其他的。也就是说，如果不在phab的层面限制住，你所谓的js限制只会发生在机器翻译已经被提供了的既成现实之后，所谓的限制将毫无意义。--Milky Defer 2023年10月29日 (日) 03:00 (UTC)[回复]

并非如此，我试过可运作，新建和编辑段落时工具不会再提供机器翻译的选项与请求，请再试试。--YF dyh000（留言） 2023年10月29日 (日) 15:45 (UTC)[回复]

当前使用机器翻译的体验

我复现不了你所谓的尝试。我录制了影片来证明我的说法。--Milky Defer 2023年10月30日 (一) 05:34 (UTC)[回复]

對Phabricator的回應

以下是Pginer-WMF的回應。

As a reference, in the last 3 months on Chinese Wikipedia: 27% of the translations were published by users with an edit count below 100, and 73% by users with an edit count of 100 or more.
Currently, we could limit the access for publishing into the main namespace. However, machine translation cannot be restricted to specific groups.
Disabling machine translation to all users will impact negatively those making a good use of the tool. Even if the limit system is not perfect for Chinese, it may be preferred to increase the translation limits. That is, having machine translation with the requirement to modify it heavily (even if it requires rewriting some parts that were already correct, rather than having always to start from scratch.
An immediate measure we can take in the direction of reducing access to machine translation could be to: make machine translation as optional, and increase the translation limits.

作為參考，在過去的3個月中文維基百科發布的翻譯文章當中，27%的文章由編輯次數少於100次的使用者發布，73%的文章由編輯次數至少為100次的編者發布。
目前，我們可以做的事情是阻止使用者將翻譯的文章發布到主命名空間。但是，無法將機械翻譯功能限定為特定用戶組才能使用。
為所有使用者關閉機械翻譯會對正當使用該工具的使用者產生不利影響。就算對於中文，（原文保留百分比）限制系統並不完美，我依然建議抬高（原文保留百分比）限制。換句話說，保留機械翻譯，但是要求翻譯者做出極大量的修改。有的時候機械翻譯的內容是正確的，該要求依然要求他們重新撰寫本就是正確的內容，但是總比從原文開始要好。
如果要限制機械翻譯的使用，我們當前立刻能採取的措施是將機械翻譯設定為可選項，然後抬高原文保留百分比的限制。

@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、SCP-2000、Dewadipper、Stang：以上是Phabricator的初步回應，大體方向依然是推薦調整發布閾值。我認為這個論點應該可以被反駁。 --Milky Defer 2023年11月28日 (二) 12:30 (UTC)[回复]

從邏輯上的思路來講，Pginer的核心論點是限制機械翻譯弊大於利。主要理由是R1：「會對善意的使用者帶去不便」。R1這個理由蘊含的基礎是A1：「中文維基百科有數量可觀的會正確使用機器翻譯的使用者」。用於佐證A1成立的證據是E1：「有73%的翻譯由編輯數量達到100次的編者做出」。

因此，我初步的想法是證明，C2：「達到100次編輯與他們懂得如何正確使用機械翻譯無關」，為此需要大家確認，Q2：「大於100次編輯、且在使用機械翻譯功能的編者的人數，是否也佔了總使用者人數的7成？」，以及Q3：「達到100次編輯的編者做出的機械翻譯當中，是否大部分的翻譯作品的品質令人滿意？」

另外，針對抬高發布閾值的建議，我個人是認為站不住腳的，因為就算我把所有文字都改了個遍，系統依然提示我由99%的文字雷同。這個閾值機制在中維基本徹底是壞掉的。

大家還有什麼別的論點嗎？--Milky Defer 2023年11月28日 (二) 12:38 (UTC)[回复]

可選項+阻止使用者將翻譯的文章發布到主命名空間+調整發布閾值能不能同時實現？還有可選項的話是什麼意思，是默認不開啟，要用戶手動開啟？--日期20220626（留言） 2023年11月28日 (二) 12:39 (UTC)[回复]

咨询得到的“可选”的解释：

现状：点击要翻译的段落后，在右侧的译文一栏中显示了使用Google翻译后的段落，并提供一个下拉菜单供你选择换成别的翻译源，或者拷贝原文，或者从空段落开始。
变成可选后：点击要翻译的段落后，在右侧的译文一栏中显示了拷贝后的原文，并提供一个下拉菜单供你选择换成机器翻译的结果，或者从空段落开始。

我应该说得比较清楚了。--Milky Defer 2023年11月28日 (二) 17:58 (UTC)[回复]

順便讓下面那個問卷調查的發起人@Hanxuan Sun知道一下這件事。--Milky Defer 2023年11月28日 (二) 12:41 (UTC)[回复]

如果禁掉機器翻譯的話，對於修改內鏈不方便，複製原文模式下內鏈是[[中文|xxx]]，xxx對應的是英文原文。--日期20220626（留言） 2023年11月28日 (二) 12:46 (UTC)[回复]

基本上同意Pginer的解決方案：

阻止使用者將翻譯的文章發布到主命名空間
機械翻譯設定為可選項
抬高原文保留百分比的限制（前提是此機制正常運作）

--桐生ここ★[讨论] 2023年11月28日 (二) 13:08 (UTC)[回复]

@桐生ここ：正如個人下方留言指出「抬高原文保留百分比的限制」做法並不可行，不知您是否還同意僅「阻止發布到主命名空間」以及「機械翻譯設定為可選項」已屬足夠，還是有其他想法？謝謝。--SCP-0000（留言） 2023年12月6日 (三) 17:34 (UTC)[回复]

基本上同意「阻止發布到主命名空間」以及「機械翻譯設定為可選項」已屬足夠。阻止發布到主命名空間基本上可以挡掉只想按按钮就建立条目的新手，如果把翻译品质烂的草稿移动到条目，就是用户的问题不是功能的问题了。桐生ここ★[讨论] 2023年12月6日 (三) 17:55 (UTC)[回复]

現在本站的閾值已是 95%。翻查 2020 年時的工單，曾有未修改百分比達 93% 之草稿（fyi 當時客棧相關討論）被當時閾值為 70% 的系統阻擋。考慮到相關限制之演算法未有任何改進，個人認為現時再出現類近誤判的機率並不低。謝謝。--SCP-0000（留言） 2023年11月28日 (二) 14:03 (UTC)[回复]

就是说，你能不能把话说清楚一点。我没读懂。

当时的设定是未修订内容高于70%会被阻挡。所以曾有93%未修改的草稿被阻挡…………应该是合理的才对？--Milky Defer 2023年11月28日 (二) 14:52 (UTC)[回复]

大腦一時不清醒，不好意思（

Anyway，個人的意思是：如果依照 Pginer 的方案，由現在的 95% 未修改內容閾值調低至 90% 或更低，可能出現類似過往 93% 未修改且「翻譯質素正常」的草稿被阻擋之誤判問題。

當然，或許有人考慮調至 93% 便可解決問題，然而其實只差了 2% ，無論是防誤判或防機翻而言作用也不大。謝謝。--SCP-0000（留言） 2023年11月28日 (二) 15:21 (UTC)[回复]

95%未修改的機器翻譯文就能發佈？是不是應該調到更低一些？--日期20220626（留言） 2023年11月28日 (二) 15:27 (UTC)[回复]

調低就可能出現誤判。以前曾調至 70% ，但後來因誤判（就是上方留言提到的誤判）而改回了。--SCP-0000（留言） 2023年11月28日 (二) 15:33 (UTC)[回复]

有时候译出来和机翻的差不多也是正常的，应该。我记得我之前有被拦过。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年11月29日 (三) 00:07 (UTC)[回复]

( ✓ )同意，以前常遇到這種狀況......--

{\ce {Be + He->B+ +e- +H- +e+}}

，這是β衰變和正電子發射，請無視其他能量釋放。 2023年12月10日 (日) 15:11 (UTC)[回复]

@MilkyDefer Three points.

Disabling machine translation to all users will impact negatively those making a good use of the tool

Nearly all translations from new users, even some established users are terrible, without revised, and useless for this project, even in draft space.

That is, having machine translation with the requirement to modify it heavily

Per discussion above, the risk of false positive is high. I've tested with the tool for a while, the problem is after you click something for machine translation, even then you remove that paragraph, the tool will sometimes refer it as a 100% similarity, what the hell is that?

make machine translation as optional

Optional? Optional equals encouragement, if it is so convenient for new users to publish an article.
My opinion is always the same, completely disable or completely enable, and if WMF refuses to completely disable this tool, I will support completely leaving it alone. Lemonaka（留言） 2023年11月28日 (二) 21:24 (UTC)[回复]

機器翻譯的文字本來就要核對原文修改以及按照漢語的習慣改寫。--日期20220626（留言） 2023年11月29日 (三) 00:11 (UTC)[回复]

可選已經是給使用機器翻譯增加阻礙，另外可以禁止將內容翻譯生成的條目發佈到條目主空間。增加阻礙已經可以篩掉一批人了。沒必要一刀切。--日期20220626（留言） 2023年11月29日 (三) 00:15 (UTC)[回复]

如果基金會工作人員的論點是這樣，那麼我覺得也可以按他講的限制讓使用機器翻譯的使用者不能直接發佈到條目空間（但我還是更傾向完全停用機器翻譯功能就是，如果不能限制成特定使用者群組才能使用的話）。--冥王歐西里斯（留言） 2023年11月30日 (四) 08:28 (UTC)[回复]

@Lemonaka： Looks like there is an overwhelming support to WMF's alternate proposal. There is undoubtfully a concensus that the machine translation problem is terrible and pervasive and we need to action, but there is not enough concensus to go so far as to the very opposite. If my memory serves right, every wiki either "uses machine translation as default and allows publishing articles directly to main namespace", or "completely disallows machine translation at all". Such middle-ground is unprecedented, and there is no data to support some of your claims or speculations such as "optional equals encouragement". I believe it is worth a try, and if the situation does not get any better, you will have more powerful and persuasive evidence to support your idea. Does that sound acceptable to you? Milky Defer 2023年12月9日 (六) 06:15 (UTC)[回复]

好像沒什麼進展？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月29日 (一) 17:06 (UTC)[回复]

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到部署完成。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

沒有主題的頁面如何評級

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:通用評級。

像是包、比 (消歧義)、值 (消歧義)這種，內容並不屬於任何專題管轄的頁面，要如何評級？有沒有辦法「無專題評級」？不然在統計工具上面，這些未評級的頁面都無法正常顯示頁面種類。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 08:59 (UTC)[回复]

主题更多是用来评判重要度而非写作水准的吧，或许可以考虑一个通用评级，比如实际上并不应该被划到单一专题内的消歧义页。——暁月凛奈 (留言) 2023年12月7日 (四) 09:34 (UTC)[回复]

(？)疑問@暁月凛奈：比方說創建一個專用的、通用的評級模板，無專題，不使用{{WPBannerMeta}}元模板，內部只塞「本頁面獲評XX級」和Special:页面评级的解析器語法，然後沒有別的說明？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 09:48 (UTC)[回复]

我基本没有参与评级相关，我不太明白为什么条目质量一定要和专题挂钩。举个例子的话，页面李的六个链接五个是姓氏，一个是植物，被划到生物还是人文都显然不合适，而且消歧义页本来也不算做条目。或许也可以设计成，“本页面尚未划分到具体专题，欢迎协助标记”，然后消歧义页等页面用参数取消这一句。——暁月凛奈 (留言) 2023年12月7日 (四) 11:51 (UTC)[回复]

{{WikiProject Article assessment}}可托管没有专题支援的条目

--洛普利寧 2023年12月7日 (四) 11:58 (UTC)[回复]

(：)回應PJ:條目質量評級「這個維基專題已經廢棄。」。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 12:18 (UTC)[回复]

幾乎所有專題都是廢棄的，只是這個專題明面上寫了而已；稍微好一點的是只有一個人參加的「個人專題」，不過這種專題基本上也是三分鐘熱度。如果你只是為了評級，那就不用管專題是否活躍，直接把{{WikiProject Article assessment}}往討論頁上貼就可以。以中維的實力來說，條目沒有專題評級才應該是正常的，有評級的反而屬於異端

--洛普利寧 2023年12月7日 (四) 12:41 (UTC)[回复]

沒有到「異端」那麼慘吧，根據WP:評級：「截至2022年，英文維基百科已經有超過700萬條目被評級。很多其他語言版本也開始使用評級系統。中文維基百科約有38萬條目接受評級。」現在中文維基約有100萬條目，100萬中的38萬，三成多，這樣平均三個條目就有一個條目有評級啊。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 13:10 (UTC)[回复]

模板、分類、甚至是檔案也是需要評級的項目，算上去真的跟異端沒兩樣。而掛上專題模板呈現的未評級狀態能算評級嗎。 --窝法乙烷儿法梦碎 2023年12月7日 (四) 14:03 (UTC)[回复]

(：)回應：@Milkypine：WP:評級：「約有38萬條目」，中文維基百科條目數也才100萬啊。哪有「異端」？我還異端兒勒。另WP:評級#統計，所有掛有評級模板條目討論頁有562,943頁，未填寫評級的「未評級狀態」之條目討論頁有182,858頁，562,943 − 182,858 = 380,085。所以被評級的「條目」是38萬無誤，100萬分之38萬 = 38%。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 14:33 (UTC)[回复]

@A2569875：先定義何謂異端，如果數字多就不算異端，那麼日本和中國市場可以除名異端狀態了。 --窝法乙烷儿法梦碎 2023年12月7日 (四) 14:54 (UTC)[回复]

更不用38%是數字少的一方，對中維其餘62%條目來講，這38%就是異端。 --窝法乙烷儿法梦碎 2023年12月7日 (四) 14:59 (UTC)[回复]

{{WikiProject Disambiguation}}，这个？--Kethyga（留言） 2023年12月7日 (四) 12:47 (UTC)[回复]

這個連專題主頁都不存在

囧rz……-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 13:02 (UTC)[回复]

这个模板没有评级参数，而且doc页写明不要仅为放置该模板而新建讨论页。--Kcx36（留言） 2023年12月8日 (五) 03:38 (UTC)[回复]

僅供參考: enwiki之前也有相關討論，現在已由{{WPBS}}自動為這類型非條目賦予NA-、Redirect-級別的評級與重要度。請參見w:wn:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24。中文或許如Category:非条目级条目?--Kanashimi（留言） 2024年1月10日 (三) 06:05 (UTC)[回复]

你會錯意了，我的意思是級別已經確定，但沒有專題的情況。而非沒有級別需要自動評成NA-、Redirect-的情況。你不要告訴我程式可以「自動判斷專題」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月10日 (三) 06:12 (UTC)[回复]

Random Thought: 跟进英维的WikiProject banner shell改版

本主題或以下段落文字，在討論結束後應存檔至Template talk:WikiProject banner shell、Template talk:WPBannerMeta。

已通過：

公示通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 04:19 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

我倒是想起一个事儿。英维最近改版了{{WikiProject banner shell}}模版（新样式在这里），新的模版可以单独给条目一个总体的品质评级，各个WikiProject可以直接继承这个quality assessment，也可以搞自己的评级。你看是不是能实现你的没有管辖之WikiProject依然可以有评级的愿望？ --Milky Defer 2023年12月7日 (四) 14:59 (UTC)[回复]

@A2569875，附知。--Milky Defer 2023年12月8日 (五) 09:03 (UTC)[回复]

@MilkyDefer稍微研究了一下，跟本地系統完全不相容，根本不知道怎麼改。他的評級是純粹使用英文字母的，我們是中文，從他目前的模組架構，我看不出來哪邊可以插入本地的評級模式。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月9日 (六) 07:47 (UTC)[回复]
@MilkyDefer既然您提議了，我請求您給出可以執行的方案或建議，謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月9日 (六) 07:49 (UTC)[回复]
那就是我自己按照人家代码的思路重新实现一个类似的咯。上一次的ping模板改版姑且让我熟悉了一点Lua语言。--Milky Defer 2023年12月9日 (六) 11:24 (UTC)[回复]
原樣照辦英維的codebase要動的手術很大。不過我姑且給你實作了一個長得差不多的在對應沙盒裡面。--Milky Defer 2023年12月9日 (六) 14:14 (UTC)[回复]
(：)回應：@MilkyDefer：可是我好像沒看到{{#assessment:}}語法。沒使用{{#assessment:}}的話也無法被系統和各類工具識別，那樣也無法解決我最初提出來的問題啊⋯⋯ -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月10日 (日) 05:09 (UTC)[回复]

(：)回應：@MilkyDefer：我把{{#assessment:}}加上去了，順便調整一下讓預設（模板預覽）不要顯示錯誤，你看一下這樣適不適當。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月10日 (日) 17:43 (UTC)[回复]
你自己决断。如我前面所述，我的改动只是一个临时性的方案。迟早需要重新规划这一套系统的技术编排，届时现在的变动会被新架构完全覆盖掉。--Milky Defer 2023年12月10日 (日) 18:22 (UTC)[回复]
(：)回應：@MilkyDefer：{{WikiProject banner shell}}目前獲WP:模板保護，即使是這個臨時方案也須獲社群共識才得以使用。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 00:05 (UTC)[回复]

工程量挺大，就看誰願意改了。（幾年前可能我有興趣，現在我就精神上支持了）--洛普利寧 2023年12月8日 (五) 14:53 (UTC)[回复]

(：)回應：@Lopullinen：目前，Milky Defer弄了個臨時方案，您看一下適不適合暫時先這樣用。（真的要整改也得先看臨時方案成效如何；模板被模板保護，即使臨時方案也要有共識才能用）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️）

目前(＋)支持User:MilkyDefer的臨時方案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 00:17 (UTC)[回复]
(？)疑問：@Milkypine、暁月凛奈：您們認為暫時先用MilkyDefer的臨時方案如何？暫且能解決目前問題，且朝模板的新版改進邁進中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 00:24 (UTC)[回复]
- (＋)支持設立通用評級，但最好展現一下沙盒效果，現在點進去看到的文件說明還是舊版本。 --窝法乙烷儿法梦碎 2023年12月11日 (一) 11:16 (UTC)[回复]
  - (：)回應：@Milkypine：可以參考測試樣例Template talk:WikiProject banner shell/testcases（評級模板的測試樣例只能放討論頁，不然會有錯誤訊息 囧rz……；首個測試樣例填了GA，所以這裡可以看到這表格最下面「評級」是「優良」，表示新模板有效）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 12:15 (UTC)[回复]
- 已逾一周無新意見，視為已有初步共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月20日 (三) 13:23 (UTC)[回复]
  - 一個小問題，見测试11，若是位於模板空間應修先顯示為模板級。且依據我於Talk:医学測試結果，似乎不符合預期。-- Willy1018（留言） 2023年12月21日 (四) 06:26 (UTC)[回复]
    - (？)疑問@Willy1018：Talk:医学測試結果哪邊不合預期？不是都正常顯示甲級嗎，下面也能展開|collapsed=yes預設不展開也正常啊。然後無法理解测试11明明已經指定了，為何要fallback to模板級？指定級別顯然優先於預設級別；未指定本來就該都沒有評級。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月21日 (四) 13:29 (UTC)[回复]
      底下：網際網路專題、維基百科專題、機器人學專題，應顯示為A級而不是未評。-- Willy1018（留言） 2023年12月22日 (五) 03:47 (UTC)[回复]
      如果本來就是這樣設計的，當我沒說吧。-- Willy1018（留言） 2023年12月22日 (五) 03:48 (UTC)[回复]
      @Willy1018：網際網路專題、維基百科專題、機器人學專題的模板又沒有要改版，既然他沒有要改版，那麼那些模板沒有輸入評級他是要怎麼知道評級成什麼？通靈嗎？而且模板參數因技術限制無法跨模板互通，所以也不可能把A級資訊傳遞進模板（實現如此傳遞需要mw:Extension:Variables，萌娘百科有，但中文維基沒有，且相關擴展不相容於目前版本的MediaWiki）。再來，你看User:MilkyDefer的原始提案「新的模版可以单独给条目一个总体的品质评级[…]也可以搞自己的评级。」這代表各個專題的評級模板是自己搞自己的，每個專題的評級互相獨立並不相干，因此沒有輸入就該維持沒有輸入評級的狀態，本就不應該蹦出沒有輸入卻變成A級的這種狀況。再來「優先顯示模板級」問題肯定也是上方誤會導致的。既然你都說「如果本來就是這樣設計的，當我沒說吧。」了，那麼我就視為異議已排除，可以準備進行公示階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月22日 (五) 04:15 (UTC)[回复]
    - @Willy1018：跟您說明一下目前辦理狀況。已建立專門讀取通用評級資訊的模組Module:PJBSClass，目前我用電子遊戲專題測試，測試結果見Talk:皮卡丘的測試結果，在電子遊戲專題模板未輸入評級時，其有確實從外層的{{WikiProject banner shell/sandbox}}讀到|class=Start，你看這是不是你要的，如果是，則還須對Template:WPBannerMeta提編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 02:58 (UTC)[回复]
      感謝貢獻，目前已覆核已符合預期。-- Willy1018（留言） 2023年12月24日 (日) 05:17 (UTC)[回复]
      (：)回應：@Willy1018：但要達成您所見到的效果需要第二階段的修改，跟{{WPBannerMeta}}配合。這樣的話，我就視為您對第二階段持(＋)支持態度囉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 08:12 (UTC)[回复]
      無異議。-- Willy1018（留言） 2023年12月25日 (一) 04:00 (UTC)[回复]
      - 那麼預計的修改方案以及其佈署連結在這了，如果沒有其他異議，就可以準備公示了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 07:55 (UTC)[回复]
此段落最後發言至今已逾七日，超過一周無新留言，且此前已形成初步共識，因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月1日 (一) 04:04 (UTC)[回复]
公示7日。公示內容見此-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月1日 (一) 04:04 (UTC)[回复]

公示期已過，期內無合理異議，提案通過，將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 04:19 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

完成：已佈署Special:Diff/80410249。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 04:40 (UTC)[回复]

第二階段：修改WPBannerMeta

已通過：

公示通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月24日 (三) 13:28 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

@Willy1018：提到了一個很有意義的問題。如果上方的變更套用了的話，只有「表面上」給了頁面通用評級，而實際上的通用評級在各個專題中並沒有達成「繼承評級」的效果。這是因為評級模板預設不會知道他外面包著{{WikiProject banner shell}}模板，因此，如果要讓每個評級模板都能讀到通用評級，需要再一個編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 05:15 (UTC)[回复]

預計將會使用Module:PJBSClass來讀取{{WikiProject banner shell}}模板中的評級，並傳遞給{{WPBannerMeta}}注入進class參數。由於這需要第一階段先通過才有用，故先擱置，等第一階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 05:15 (UTC)[回复]
第二階段相關討論Special:PermaLink/80224436#回復通告-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月25日 (一) 02:56 (UTC)[回复]
已覆核，已符合預期，再次感謝您的貢獻。(搬運自Special:PermaLink/80233084)-- Willy1018（留言） 2023年12月25日 (一) 04:02 (UTC)[回复]
上面的共識是「可以單獨給條目一個總體的品質評級，各個WikiProject可以直接繼承這個quality assessment，也可以搞自己的評級。」，下方Wikipedia:互助客栈/其他#關於基礎條目的額外提議也有多個(＋)支持「對各種專題橫幅不再個別指定 class，而是統一置於{{WPBS}}」的聲音，為了實現上方共識「各個WikiProject可以直接繼承這個quality assessment」以及下方討論的「專題橫幅不再個別指定 class，而是統一置於{{WPBS}}」因此需要在{{WPBannerMeta}}置入讀取{{WPBS}}評級值的模板，以便讓專題橫幅能正確識別統一置於{{WPBS}}的評級，故本修改是必要的，目前已經佈署於電子遊戲專題和多面體專題，運作穩定。如無異議，將會進行公示，進行全面佈署。

預計的修改方案以及其佈署連結（記得填寫討論通過的diff和客棧PermaLink版本號）。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 05:00 (UTC)[回复]

呈上所述，再依據WP:7DAYS，若2024年1月10日 (三) 05:00 (UTC)前沒有其他異議，就視為達成共識，屆時將進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 11:30 (UTC)[回复]
由於上方提案已佈署，因此本配套案亦須佈署，以便同步專題評級行為。編輯請求先放了Template_talk:WPBannerMeta#編輯請求_2024-01-08-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 04:58 (UTC)[回复]

本主題或以下段落文字移动自Template_talk:WPBannerMeta#編輯請求_2024-01-08（固定鏈接），新留言请置于框外。执行人：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 13:21 (UTC)[回复]

相關議案

Wikipedia:互助客栈/其他#Random_Thought:_跟进英维的WikiProject_banner_shell改版

的配套修改-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 05:03 (UTC)[回复]

想諮詢一下@Kanashimi君相關修改是否有問題？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月8日 (一) 05:53 (UTC)[回复]

@Ericliu1912、Kanashimi：這主要是依據共識，讓專題橫幅能繼承{{PJBS}}輸入的評級值。我已經在{{多面體專題}}、{{電子遊戲專題}}測試過了，沒有問題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 06:00 (UTC)[回复]

User:A2569875的努力有目共睹。只不過我原先料想的是直接改w:en:Module:WikiProject banner及w:en:Module:Banner shell，而宇帆-娜娜奇看起來很辛苦的重構了代碼，並且有些參數不太一樣，這樣我就不太好評論了。--Kanashimi（留言） 2024年1月8日 (一) 06:12 (UTC)[回复]

@Ericliu1912、Kanashimi：那就用測試數據來說話吧。目前我是刻意讓{{多面體專題}}內部是調用Template:WPBannerMeta/sandbox/sandbox（同於Template:WPBannerMeta/sandbox，只是Template:WPBannerMeta/sandbox/sandbox裡面都塞/sandbox模板以便測試效果），效果完全符合預期，十分正常，見下列測試結果（只要是調用{{多面體專題}}的，基本上都等同於這個Patch）：
- Talk:二十面體對稱的多面體列表：裡面輸入了列表級，Template:WPBannerMeta/sandbox確實讀到了列表級，沒有問題。
- 其他可參考Special:链入页面/Template:WPBannerMeta/sandbox/sandbox，基本上都沒有問題，我檢查一個禮拜了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 06:16 (UTC)[回复]

考慮到日後長期維護需求，我傾向請您以英文版本為基礎來更新相關模板。是否能夠確認有什麼模板需要更新（或在互助客棧列出之類）？不過在此過渡期間，若技術上沒有問題，是可以斟酌先批准既有之編輯請求。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月8日 (一) 12:18 (UTC)[回复]

@Ericliu1912：若以Wikipedia:互助客栈/其他#Random_Thought:_跟进英维的WikiProject_banner_shell改版這一案來看的話（或者說只看這一案）的話，只有{{WPBannerMeta/core}}和{{WPBannerMeta}}要更新。其他案目前還在討論中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 12:23 (UTC)[回复]
- (～)補充：@Ericliu1912：參考這個留言Wikipedia:互助客栈/其他#MilkyDefer2023年12月9日(六)14:14(UTC)，「原樣照辦英維的codebase要動的手術很大。不過我姑且給你實作了一個長得差不多的在對應沙盒裡面。」考慮到最大相容性和中文維基的特殊性（如繁簡問題），本地評級系統本來就跟英文維基不太相同。目前只能「按照人家代碼的思路重新實現一個類似的咯。」（by User:MilkyDefer）此外，我也不想換掉現在中文維基熟悉的Style。目前您所看到的系統都是基於MilkyDefer的修改版再把enwiki對應功能實作出來。主要功能去年年底就完工了，經過了半個多月的測試，我相信技術上不會有太大的問題。且相關函數已於電子遊戲專題兩萬多條目進行測試，問題幾乎都解決了。技術上沒有問題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 12:58 (UTC)[回复]

這兩個（Template_talk:WPBannerMeta#編輯請求_2024-01-08、Template_talk:WPBannerMeta/core#編輯請求_2023-12-28）屬於案《Random Thought: 跟进英维的WikiProject_banner_shell改版》可以先進行；剩下的屬於另一案（Module_talk:Class/data#編輯請求_2023-12-28、Template_talk:Class_mask#編輯請求_2024-01-05、Template_talk:Class_mask/core#編輯請求_2023-12-25、Template_talk:Class/colour#編輯請求_2024-01-05）屬於案《同步各模板/块的評級值》目前正在公示，所以暫時還不用。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 14:59 (UTC)[回复]

@Ericliu1912：要改哪些模板我在客棧上其實都有列，主要在案《沒有主題的頁面如何評級》和案《評級系統缺失問題》的子章節裡。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 15:03 (UTC)[回复]

（不用一直提及我，我有在看）—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月8日 (一) 15:11 (UTC)[回复]

(：)回應：既然你有在看，那我就更仔細地說明這兩個編輯請求（Template_talk:WPBannerMeta#編輯請求_2024-01-08、Template_talk:WPBannerMeta/core#編輯請求_2023-12-28）技術上沒有問題、無疑慮的理由。這兩個編輯請求加起來的編輯內容等價於我上個月在{{WikiProject Video games}}做出的這筆編輯Special:Diff/80221014。用的模組和函數完全相同，只是僅限於電子遊戲專題，而這兩個編輯請求加起來的編輯內容就等於佈署到所有專題。電子遊戲專題之所有不用編輯兩個模板是因為{{WikiProject Video games}}不使用元模板，也沒有/core，因此編輯一個頁面就能達到效果，而所有專題共用的元模板有使用元模板/core，因此需要編輯兩個模板（主模板和/core模板）才能生效。電子遊戲專題共有兩萬多個條目，這功能佈署到電子遊戲專題至今已半個多月，未見什麼大問題，代表已經在兩萬個條目測試沒問題（稍早也測試了{{多面體專題}}，500+條目；實際上還佈署到了{{互联网专题}}、{{维基百科专题}}和{{WikiProject Robotics}}上以便讓User:Willy1018已覆核效果符合預期；更進一步的技術測試則在{{WikiProject_Sandbox}}及{{WikiProject Portals}}完成，均未發現任何問題；為了避免影響到Patch，測試是由{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}完成，測試方式是直接先暫時將對應模板改用{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}以觀察佈署後的效果），我這半個月也實際複查數百個條目，沒發現任何問題，代表這兩萬多個條目的測試是成功的，因此認為本開發已趨於穩定，是時候可以佈署到所有專題了。以上，故認為技術上沒有問題，可以佈署Template_talk:WPBannerMeta#編輯請求_2024-01-08和Template_talk:WPBannerMeta/core#編輯請求_2023-12-28。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 15:46 (UTC)[回复]
(～)補充：若這兩個編輯請求（Template_talk:WPBannerMeta#編輯請求_2024-01-08和Template_talk:WPBannerMeta/core#編輯請求_2023-12-28）核准了，記得通知我一聲，我需要在{{多面體專題}}、{{互联网专题}}、{{维基百科专题}}、{{WikiProject Robotics}}和{{WikiProject Portals}}取消佈署，避免重複佈署和{{WPBannerMeta}}及{{WPBannerMeta/core}}相衝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 15:55 (UTC)[回复]

@Ericliu1912、Kanashimi：另外參見此發言，User:Willy1018已覆核效果符合預期，認為修改沒有問題。測試也都充分了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 06:31 (UTC)[回复]

@Ericliu1912：另外如果要接受編輯請求的話，也把Template_talk:WPBannerMeta/core#編輯請求_2023-12-28也接受吧，兩者是互相配套的（{{WPBannerMeta}}與{{WPBannerMeta/core}}高度相依）。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 06:33 (UTC)[回复]

相關討論移動到此供參考。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 13:22 (UTC)[回复]
本議案旨在「讓專題橫幅能從{{PJBS}}繼承評級值」是否佈署到所有專題。目前已暫時透過沙盒模板測試性地佈署到電子遊戲專題、多面體專題、網際網路專題、維基百科專題、主題專題、沙盒專題。如無異議的話，將會就「是否佈署於所有專題」進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 13:54 (UTC)[回复]
目前沒有合理異議，因此仍照原定計畫若2024年1月10日 (三) 05:00 (UTC)之前沒有其他異議就視為已獲共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 17:48 (UTC)[回复]
依據此以及WP:7DAYS，時間已逾2024年1月10日 (三) 05:00 (UTC)，且本篇討論始於2023年12月7日已逾一個月，依據WP:1MONTH，因此視為已達成共識，準備開始公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月10日 (三) 05:37 (UTC)[回复]
公示7日，公示說明。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月10日 (三) 05:37 (UTC)[回复]
由於相依性，公示延長至《Wikipedia:互助客栈/其他#提案已通過請求佈署》佈署的三日後。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 15:36 (UTC)[回复]
《Wikipedia:互助客栈/其他#提案已通過請求佈署》佈署已逾時三日；公示期內位於Template_talk:WPBannerMeta#編輯請求_2024-01-08的合理意見可以透過下方議案《通用評級規範》來解決，且該議案已獲初步共識並進入公示階段（詳見此說明），故可以預見該問題將被解決，故此案應可通過；但為了謹慎起見，公示再延三日，若三日內沒有合理異議則視本案為通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月21日 (日) 13:05 (UTC)[回复]
- 說明：因公示期因各種原因一延再延，故屆時公示到期時，本公示將長達14日之久，因此認為本公示已十分充分，並在公告欄上公告半個月了，故沒有不通過的理由。根據上述說明，公示期預定在2024年1月24日 (三) 13:05 (UTC) （東八區時間晚上9點零五分）結束。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 02:33 (UTC)[回复]

公示到期，期內無合理異議，提案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月24日 (三) 13:28 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

完成：已由User:AT佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月25日 (四) 10:01 (UTC)[回复]

第三階段：完善制度

已通過：

公示通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月29日 (一) 03:28 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

在Template_talk:WPBannerMeta#編輯請求_2024-01-08中有人認為需要給通用評級訂一個「能填寫甚麼級別」的標準來避免爭議，因此立了草案Wikipedia:通用評級如下：

若一條目沒有專題或不受任何專題管轄，則其通用評級可填寫任意有被{{WikiProject banner shell}}支援的級別，僅要該條目有達到該級別的標準或滿足該級別的條件，都可以評。

若一條目僅有一個專題，其通用評級應與該專題所評的等級一致。

若一條目有多個專題，通常由機器人自動依照規則4進行評級，但一旦出現爭議時則通用評級應以所有專題都有開設的級別為主。
例如：若一條目有四個專題，而有一個專題沒有開設「丙級列表級」，那麼通用評級就不得填寫「丙級列表級」

對於有多個專題的條目，通用評級應填寫最多專題評的那一等級。
例如有一個條目有四個專題，其中三個專題都評為乙級，但有一個專題評為丙級，則通用評級應填寫乙級。

若在規則4的情況牴觸規則3，則應填寫與對應級別最接近的且滿足規則3的級別。
例如有一個條目有四個專題，其中三個專題都評為「丙級列表級」，但有一個專題評為「列表級」且這個專題不開設「丙級列表級」。依據規則3，最多專題評的級別是「丙級列表級」，但有一個專題不開設「丙級列表級」，則通用評級應填寫與「丙級列表級」最接近且位於該條目所有專題都有開設的級別，也就是「列表級」。

「最接近的級別」應該向下填寫，例如未啟用乙級的專題，通用級別遇到規則3判為乙級的情況時，則向下填寫為丙級。如果丙級也有專題未開設，就再向下填寫為初級。如遇到無法評級的情況，該通用評級模板就該留空。

提議將之升為指引，不曉得各位覺得如何？@Ma3r、Kanashimi、Z7504、桐生ここ：@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 09:44 (UTC)[回复]

實作上是否能讓那些沒開設大宗評級（數量最多專題）的在專題橫幅內設定好參數即可？這樣看起來就不會因為沒開設評級、被覆蓋而出問題。機器人很難判別每個專題開設的評級，因此條件3會讓讓機器人無法自動作業。

僅供參考，就enwiki來說，純粹只考慮數量最多的評級。採用特殊評級的專題橫幅有特殊分類，機器人處理時不會動到其評級。--Kanashimi（留言） 2024年1月14日 (日) 10:35 (UTC)[回复]

@Kanashimi：技術上不能讀取評級模板的|QUALITY_SCALE=內容和/class子頁面嗎？如果|QUALITY_SCALE=填subpage，讀取/class子頁面就能得知該專題哪些評級有啟用。例如{{多面體專題}}是|QUALITY_SCALE=subpage，所以讀取Template:多面體專題/class原始碼即可得到哪些級別是yes、哪些級別是no。如果|QUALITY_SCALE=填extended則是定義於{{Class mask/extended}}的級別。未填或standard就是只使用大宗評級。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 11:00 (UTC)[回复]

如果改成「若一條目有多個專題，通常由機器人自動依照規則4進行評級，但一旦出現爭議時則通用評級應以所有專題都有開設的級別為主。」機器人會不會好辦一點？意為機器人填寫值優先，但如果是人工評級時，才須考慮是否所有專題都有開設，且是遇到爭議之時，這是為了解決「但是如果有人說「根據Wikipedia:條目質量評級標準#非標準級別和一些專題評CL的慣例，這篇列表內容充分，儘管支援條目的專題都沒有設CL級別，但既然WPBS能評CL那我就評CL」呢？所以，這個評級的定位該怎麽看？您作出了如此複雜的功能，但如果因爲使用規則不完善而部署而引發爭議，相信這是您不願意見到的。」所描述的爭議情境。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 11:06 (UTC)[回复]

@A2569875 現在cewbot採用的方式是選出最大宗的評級（數量最多的評級），填入{{WPBS}}並且移除所有相同的評級。所有不同的評級都保留不動。不曉得這樣的作業方式是否會產生問題？--Kanashimi（留言） 2024年1月14日 (日) 11:16 (UTC)[回复]

@Kanashimi：上面的情境說的是人為評級時可能出現的爭議；如果是機器人評級，我相信應該沒什麼爭議。所以應該不會有問題。該規則僅為了處理人為評級發生的爭議，理應不影響機器人運作。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 11:20 (UTC)[回复]

既然如此那我作為機器人操作者沒有什麼意見。當{{WPBS}}已經指定class，機器人不會動到{{WPBS}}的class。--Kanashimi（留言） 2024年1月14日 (日) 11:28 (UTC)[回复]

我在疗养，您自己请便。由于这个事情的业务逻辑挺复杂的，我不会拦着你用什么样的Lua。--Milky Defer 2024年1月14日 (日) 12:48 (UTC)[回复]

已逾一周沒有任何發言，根據WP:7DAYS，七日無新留言視為已達成初步共識，因此將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月21日 (日) 12:54 (UTC)[回复]
公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月21日 (日) 12:54 (UTC)[回复]

公示已逾七日，公示期已過，期內無合理異議，因此提案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月29日 (一) 03:28 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

關於基礎條目的額外提議

已通過：

基礎條目併入{{WPBS}}已經通過；{{WikiProject Biography}}參數還在討論中。先行佈署已通過的《將{{Vital article}}併入{{WPBS}}的|vital=參數》案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

似乎已有共識，跟隨enwiki改版之後會由機器人自動完成：對各種專題橫幅不再個別指定 class，而是統一置於{{WPBS}}。
跟隨enwiki改版之後會由機器人自動完成：將{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數皆改以{{WPBS}}處理，
跟隨enwiki改版之後會由機器人自動完成：將{{Vital article}}併入{{WPBS}}

這邊最近在幫忙enwiki自動化這過程。這邊將申請自動更新Wikipedia:基礎條目所有子頁面的圖示（這部分最近測試中，已趨穩定。），以及定期維護{{WPBS}}（將各種專題橫幅併入{{WPBS}}並維護 'class', 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'等相關參數）。不知大家對此是否有建議？ --Kanashimi（留言） 2024年1月2日 (二) 09:53 (UTC)[回复]

本主題或以下段落文字移动自Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版，暨將{{Vital_article}}併入{{WPBS}}（固定鏈接），新留言请置于框外。执行人：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 05:20 (UTC)[回复]

引入enwiki近期{{WPBS}}之改版，暨將{{Vital article}}併入{{WPBS}}

enwiki近期改版{{WikiProject banner shell}}，

對各種專題橫幅不再個別指定 class，而是統一置於{{WPBS}}。
將{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數皆改以{{WPBS}}處理，
將{{Vital article}}併入{{WPBS}}

這邊最近在幫忙enwiki自動化這過程，並且將定期維護。想請教大家對上幾種改變的贊否。

另這邊將申請自動更新Wikipedia:基礎條目的圖示（這部分最近測試中，已趨穩定。），以及維護{{WPBS}}（將各種專題橫幅併入{{WPBS}}）。不知大家對此是否有建議？

副知User:Ma3r、User:Ericliu1912--Kanashimi（留言） 2024年1月2日 (二) 06:11 (UTC)[回复]

其實個人早已注意到相關更新，只是苦於自身技術實力不足而未能協助，樂見在充分確保相容性的情況下跟進。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月2日 (二) 06:21 (UTC)[回复]

(＋)支持全部。--Ma3r（铁塔） 2024年1月2日 (二) 06:25 (UTC)[回复]

@Kanashimi：可是這個即將公示通過了耶Wikipedia:互助客栈/其他#Random_Thought:_跟进英维的WikiProject_banner_shell改版。這個預計會先上架，這邊去年年底弄了從{{WPBS}}讀取評級到專題橫幅的模組Module:PJBSClass，你是要讓我做白工嗎？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 09:30 (UTC)[回复]
唉呀感謝提醒我沒注意到。看起來改版是已經有共識的結果了。我把建議移到那個討論串下好了，這邊可以關閉了。--Kanashimi（留言） 2024年1月2日 (二) 09:37 (UTC)[回复]
@Kanashimi：您可以將整個討論移到其他區（ —— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月3日 (三) 04:47 (UTC)[回复]
已遷移討論@Ma3r、Ericliu1912：（User:Kanashimi應該已經知道了）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 05:51 (UTC)[回复]

(：)回應：但上面的共識是「可以單獨給條目一個總體的品質評級，各個WikiProject可以直接繼承這個quality assessment，也可以搞自己的評級。」，代表雖然評級統一放在{{WPBS}}，但仍然要允許個別專題能用自己的標準來搞自訂評級，所以應保留各專題橫幅的評級參數與功能。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 04:57 (UTC)[回复]

是的，enwiki採w:en:Category:WikiProjects using a non-standard quality scale表示自訂評級的專題，bot亦已考慮此問題，在User:Cewbot/log/20200122/configuration有此項。待zhwiki完成部署，填好User:Cewbot/log/20200122/configuration便可apply。--Kanashimi（留言） 2024年1月3日 (三) 07:08 (UTC)[回复]

(：)回應：@Kanashimi：我指的是可能會有專題有自己的標準，導致評級值與{{WPBS}}不同的情況（如可能有些專題的乙級比較嚴格，導致該專題只能評丙級，但WPBS是乙級，其他專題也是乙級），而非「非標準評級」（non-standard quality）的情況。雖然兩者都需要保留著各專題橫幅模板的評級class參數。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 07:26 (UTC)[回复]
是的，w:en:Category:WikiProjects using a non-standard quality scale包含您所提的這兩種非正規、不繼承的狀況。--Kanashimi（留言） 2024年1月3日 (三) 07:47 (UTC)[回复]
- @Kanashimi：建好後，發現好像跟你說的不是一個東西？Category:使用自訂專題評級的條目，我是指「一個頁面的評級」滿足「不繼承、非正規」的狀況，不是「專題橫幅自己」滿足「不繼承、非正規」的條件。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 09:41 (UTC)[回复]
  或許我們該用Category:使用非正規質量評級的專題橫幅？至於您說的「一個頁面的評級」很抱歉我不太理解，是否能舉個例子呢？--Kanashimi（留言） 2024年1月3日 (三) 11:34 (UTC)[回复]
  (：)回應：@Kanashimi：Category:使用自訂專題評級的條目裡面的頁面就是「一個頁面的評級」滿足「不繼承」的狀況。Category:使用自訂專題評級的條目指的是「考慮一個已使用{{WPBS}}指定評級為X的條目，其有至少一個專題橫幅評級值為Y，或不為{{WPBS}}指定的X」，而考察w:en:Category:WikiProjects using a non-standard quality scale分類內都是「專題橫幅模板」本身，我猜它是指「允許『不繼承、非正規』評級的橫幅」，而不是條目評級的「個例」；而Category:使用自訂專題評級的條目是指「已經『不繼承、非正規』評級的頁面」的「個例」而非橫幅模板本身。我想你有所誤解，我希望是元模板都保留|class=參數，讓專題自己決定要怎麼送值，然後預社會繼承，這樣的話我們就不需要Category:使用非正規質量評級的專題橫幅分類。也就是說，本地的狀況宜以條目個例來看，而非以專題為單位來看。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 11:43 (UTC)[回复]
  假如我沒有理解錯，您的意思是就您看來，zhwiki採用因地制宜的條目追蹤Category會比較好，因此您建議的是Category:使用自訂專題評級的條目而非Category:使用非正規質量評級的專題橫幅？--Kanashimi（留言） 2024年1月3日 (三) 11:49 (UTC)[回复]
  
  另外這兩個追蹤的標的不同，一個是專題橫幅，一個是條目，我建議先取消d:Q122718872的連結。--Kanashimi（留言） 2024年1月3日 (三) 11:52 (UTC)[回复]
  d:Specail:Diff/2044308721已取消。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 11:56 (UTC)[回复]
  
  (：)回應：@Kanashimi：是的，根據我的觀察，我認為中文維基環境宜用Category:使用自訂專題評級的條目（因為人手較少，很多專題都是不活躍或單人專題，因此中維的關注點以條目居多，故追蹤分類追蹤條目很符合邏輯），且Patch已寫好，已使用少量條目測試，目前運作正常，預計會先跟上面的patch一起佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 11:54 (UTC)[回复]
  enwiki採用這種方法的過程與部分考量可參考w:en:Template talk:WikiProject banner shell#Issue with assessments not applying to WikiProject Lists template，關乎Special:PageAssessments。就我最近的測試，有些模板如您所述有些專題的乙級比較嚴格，導致該專題只能評丙級，但WPBS是乙級，其他專題也是乙級，更有像w:en:Template:WikiProject Military history模板本身有額外採用class參數的代碼，這些模板本來就該與採用一般正規評級的模板分開。因此我會建議保留Category:使用非正規質量評級的專題橫幅這部分的功能，輔以Category:使用自訂專題評級的條目的patch。--Kanashimi（留言） 2024年1月3日 (三) 12:06 (UTC)[回复]
  目前的patch是對所有的專題橫幅全面保留|class=參數，只是設定未輸入時會從WPBS讀取評級值，也就是預設繼承，也就是說，所有專題橫幅模板都可以繼承或覆蓋，因為是所有的橫幅都可以覆蓋，所以Category:使用非正規質量評級的專題橫幅對於「不繼承評級」沒有意義。共識也有說要在最大相容的情況下佈署，所以我主張要盡可能保留原本的功能，即每個專題橫幅模板都能自訂評級，這是原本的情況，新共識是保留原本情況額外加上可以繼承評級的功能，且符合共識的patch也就緒了，您的意思看起來好像要取消專題橫幅預設都可以獨立評級、不繼承評級，我(－)反对如此作法，我主張應對所有專題(○)保留可覆蓋評級的功能，就像你程式的類別成員函數預設都是可以繼承或複寫Override的啊，怎麼會有預設是不准Override的情況？因此我反對預設關閉橫幅不繼承評級之功能，反正現在的patch已經是預設繼承WPBS之評級的情況，對專題橫幅元模板保留「允許不繼承評級」功能無傷大雅。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月4日 (四) 04:20 (UTC)[回复]
  我了解您的意思了。enwiki現在也是預設繼承，允許Override但會被列入w:en:Category:Articles with conflicting quality ratings。那邊的想法似乎是除非退出，否則應採用同一評級。我建議還是保留專題橫幅退出的餘地，畢竟有些專題橫幅就是比較特別。
  
  就現在的機器人實作方法，zhwiki應該不會有問題。專題橫幅模板的質量評級若與{{WPBS}}相同，將會被移到{{WPBS}}。若與{{WPBS}}不同則會保留。--Kanashimi（留言） 2024年1月4日 (四) 06:05 (UTC)[回复]
  我是覺得以本地的環境而言，不需要區分專題登不登出，能給專題設定自訂class mask來處理非標準評級就足夠了，且本地對於某評級值是否標準不標準似乎沒什麼在意，所以特設分類大可不必。對於繼承的部分，我認為各專題保持相同設定，都可以選擇繼承或Override即可，追蹤分類的話就追蹤有Override的條目個例即可。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月4日 (四) 08:56 (UTC)[回复]
  本子縮進段落已逾三日未有新的回應，因此根據WP:7DAYS「自該回應起計的3日後無進一步再回應，應視為該意見已解決」，此段結合上面其他意見達成的共識為「中文維基的專題橫幅元模板不區分登出或不登出，即專題橫幅元模板全數保留|class=參數，但預設會自動繼承{{PJBS}}中記錄的評級值，各專題或評級者可以自行決定要繼承{{PJBS}}值還是覆蓋，因此不為專題橫幅設置追蹤分類，而是追蹤條目」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月7日 (日) 10:13 (UTC)[回复]
  
  例如Talk:康威多面體裡面{{WPBS}}指定了|class=stub，但{{多面體專題}}指定了|class=start蓋掉了{{WPBS}}的|class=stub，因此被自動加入Category:使用自訂專題評級的條目分類。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 11:46 (UTC)[回复]
@Kanashimi：那您的bot有考慮到{{WPBS}}能自動判斷評級的情況嗎？此時，{{WPBS}}不會有輸入任何|class=參數，也不必輸入|class=，因為它是自動判定，例如Talk:2J（請看此版本的原始碼）。甚至還能傳遞給內層專題橫幅讓專題橫幅繼承這個「沒有輸入」的評級級別，例如Talk:二側錐五角柱（請看此版本原始碼）和Talk:五複合半刻面立方體（請看此版本原始碼），bot有考慮到這種{{WPBS}}未輸入|class=參數，但能產生結果的狀況嗎？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 10:21 (UTC)[回复]
機器人基本上不會動這種類型的 {{WPBS}}。另外依照MSGJ在w:en:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24的說法，“We have changed the logic so it is impossible to rate a non-article with an article quality rating.”，也就是這類型的問題會由Module:Banner shell處理。--Kanashimi（留言） 2024年1月3日 (三) 11:44 (UTC)[回复]

整理一下目前共識：
- {{PJBS}}設立通用評級，可以統一管理同一條目的所有專題評級（已公示通過）
- 確保最大相容性的前提下跟進英文維基的相關功能
- 專題橫幅看各專題意願，評級可以選擇統一放置於{{PJBS}}也可以自行輸入
- 未輸入評級的專題橫幅以繼承載於{{PJBS}}的評級值為主，會優先採用載於{{PJBS}}的評級值
- 如頁面能自動判斷評級則無論輸入什麼評級，都要以自動判斷的評級為優先（原始來自這則留言，後續有在上方簡單討論）；另有設置參數能複寫此設定。
- 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'已併入{{PJBS}}，但是否廢除{{WikiProject Biography}}內的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'還有待討論
- {{WPBS}}已經加入{{Vital article}}的所有參數，但是否要用{{WPBS}}取代{{Vital article}}還有待討論

以上-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 18:08 (UTC)[回复]

我有不同意见。英维的WPBannerMeta模组有很长一大坨代码都是在处理这个Vital Article的事情；具体来说，他们把校验这个Vital Article是不是真的Vital Article什么的逻辑全部写进去了。这一坨东西让可维护性和可读性（有可能还有效率）遭到了重大影响。我认为这更适合由一个外部机器人维护，而不是剥削这个已经很折磨人的Lua。 --Milky Defer 2024年1月14日 (日) 12:53 (UTC)[回复]

我的建议方案是，|vital=参数可以存在，但是只有UI作用，由一个外部的机器人进行监察和更新操作。--Milky Defer 2024年1月14日 (日) 12:55 (UTC)[回复]

若能簡單改enwiki的程式碼來用，或許不必擔心折騰的問題。另一方面假如只留UI功能的話，是否乾脆維持原來的{{Vital article}}就好?--Kanashimi（留言） 2024年1月14日 (日) 13:06 (UTC)[回复]

Module:Vital_articles都已經分成類似雜湊表查詢了，有甚麼折騰的問題？已經高效率優化了好嗎。理論上，此實現的記憶體開銷甚至有望低於英文維基，因為英文維基只分成27個表，而中文維基是36個表，代表中文維基每個表的項目數量更少，在類似散列函數計算之後，要讀取的JSON更小，表示記憶體用量更少，單個表項目更少表示查詢更快。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 13:12 (UTC)[回复]

@Kanashimi：Module:Vital_articles#L-216基本上就是英文維基的Code，我們已經簡單改enwiki的程式碼來用了，您似乎有所誤會，請自行對照Module:Vital_articles#L-216與en:Module:Banner_shell#L-90。而且您可以看到，本提案預計的作法已經把它下分到Module:Vital_articles去了，並不是像英文維基裡全部整坨塞WPBS模組，故不存在您所提的「可维护性和可读性低」的問題，因為已經分門別類處理了：WPBS處理WPBS的任務、Vital articles處理Vital articles的任務，故上述疑慮不存在，杞人憂天。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 13:14 (UTC)[回复]
是的，所以我想應該不至於有折騰的問題。--Kanashimi（留言） 2024年1月14日 (日) 13:17 (UTC)[回复]
不同意「剝削這個已經很折磨人的Lua」一說。您似乎保守過頭了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 13:16 (UTC)[回复]
@MilkyDefer：而且一個頁面最多只會放置一個{{WPBS}}或{{Vital article}}，代表該運算始終只會做一次，一個半秒內完成的運算只算一次，是要擔心甚麼效能問題？難道你想塞一萬個{{WPBS}}或{{Vital article}}在討論頁？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 13:20 (UTC)[回复]
- 我們用實際數據來說話吧。Special:PermaLink/80500375這是隨便測試6620個條目進行基礎條目判別，並輸出{{Vital article}}字串。
  這6620個條目全部運算完畢在預覽模式下Lua的後台輸出為：
  - Lua 使用時間：6.375/10.000 秒
  - Lua 記憶體使用狀況：20,669,093/52,428,800位元組
  跑6620次花6.375秒，平均每次基礎條目判斷僅需花費0.00096299093秒，也就是0.96299093毫秒，連1毫秒都不到。記憶體用量則是20,669,093 / 6620 = 3122.2194864，平均每個基礎條目判段僅需3122位元組，3.1kB，而可用的記憶體有52MB那麼多，更不用說這運算只算一次。你總共只需要 0.96 ms、3.12 kB，這甚至比其他很多模組有效率了好嗎。
  一個1毫秒內完成的運算只算一次，是要擔心甚麼效能問題？我實在沒有辦法看出是要擔心哪門子的性能問題。既然一個基礎條目判段只需要不到1毫秒，那我認為你上面的「削这个已经很折磨人的Lua」完全是無稽之談，完全說不過去。Lua本身的目的就是要來降低維基代碼的開銷的，你隨便一個維基代碼解析都可能比我上面那個運算來的久。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 05:28 (UTC)[回复]
  - 已逾一周無新留言，因此根據WP:7DAYS，七日無進一步發言視為已達成初步共識；再依據WP:7DAYS「已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決。」上方意見自最後發言起已逾三日無其他回應，因此視為該意見已解決，故將「將{{Vital article}}併入{{WPBS}}的|vital=参数」視為已達成初步共識，預計將使用修改方案以及其佈署連結和測試樣例1、測試樣例2，以及(±)合併{{Vital article}}到{{WPBS}}，來達成這個初步共識。既然依據WP:7DAYS已達成初步共識，那麼將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 05:31 (UTC)[回复]
- 公示7日，公示內容「將{{Vital article}}併入{{WPBS}}的|vital=参数」（同時執行方案①修改方案以及其佈署連結和方案②(±)合併{{基础条目横幅}}及{{Cba/discuss}}到{{WPBS}}（已由修改方案涵蓋）），另見此說明。（註：{{Vital article}}是重定向頁，亦會更改重定向目標）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 05:31 (UTC)[回复]

基礎條目模板合併案公示

見公示聲明。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月24日 (三) 03:38 (UTC)[回复]

@A2569875：我試過了，沒有什麼大問題，但建議WikiProject banner shell模板中的BOTTOM TEXT參數可以自動廢除了，不然如果還有發現這個參數的專題模板還要備註也真夠麻煩的。--Z7504非常建議必要時多關注評選（留言） 2024年1月22日 (一) 05:38 (UTC)[回复]

@Z7504：請問WikiProject banner shell模板哪來的BOTTOM TEXT？你是不是弄錯了？WikiProject banner shell的原始碼內根本沒有你你提及的那種內容。你是否搞錯了什麼，還是誤會了什麼？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 05:44 (UTC)[回复]

還真的沒有，那應該誤會了。那這BOTTOM TEXT參數到底是從哪裡來的？該廢除的參數還是應該盡早廢除。基本上只剩下一個(？)疑問：是不是還要寫{{WPBS|class=xxx}}才能讓其強制正常顯示？--Z7504非常建議必要時多關注評選（留言） 2024年1月22日 (一) 06:05 (UTC)[回复]

@Z7504：顯示什麼？你是不是又誤會了？本次公示是針對基礎條目的參數，請問跟class到底有什麼關聯？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 06:12 (UTC)[回复]

這裡就是一個活生生的例子（比如這筆和這筆），這點小bug麻煩也先改了吧，不然都還要強制輸入才能確保正常顯示，問題不大才對。--Z7504非常建議必要時多關注評選（留言） 2024年1月22日 (一) 06:30 (UTC)[回复]
- @Z7504：這根本不是BUG，因為你如果沒有給WPBS模板輸入評級，它本來就不應該顯示任何評級，因為那代表「該條目沒有指定通用評級」，不顯示評級才是正常現象。再來是，所有維基媒體基金會旗下站點都沒有佈署能給跨模板傳遞資料的擴展，所以你輸入在專題模板的class當然無法被WBPS獲知，如果可以，那就是魔法或者見鬼了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 06:48 (UTC)[回复]
  - 還有class處理的部分根本不在本案本次公示的處理及討論範圍內，強烈抗議強迫併案處理或企圖搞案外案的要求。然後還有上面說明的WPBS沒有辦法直接獲取輸入在專題模板的評級值。關於你的疑慮，等本案通過後User:Kanashimi會用機器人自動將專題模板的評級參數補給WPBS模板，故您也不需要手動給WPBS手動給評級。故您所提到的東西不予修復，因為屆時他會被Kanashimi的機器人自動處理。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 06:58 (UTC)[回复]
- @Z7504 我稍後會申請將數量最多之評級填入{{WPBS}}的任務，基本效果就如同您上面所列的編輯。不曉得這是不是能解決您的問題呢？--Kanashimi（留言） 2024年1月22日 (一) 06:57 (UTC)[回复]
這根本不是需要修復的BUG。WPBS中|class=參數的填寫一開始就是設計要讓機器人自動維護的部分，讓模板自動處理此問題反而問題更多且不切實際，更適合由一個外部機器人进行监察和更新操作，因此該意見應視為對上方議案有所誤會所提出的意見，同時|class=參數的填寫也與本案《將{{Vital article}}併入{{WPBS}}的|vital=參數》毫無關聯，因此應無效，若三日內沒有異議或進一步回應，則視為該意見已解決。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 08:40 (UTC)[回复]
- 如果你硬是要說他是「BUG」我只能說你誤會大了，你邏輯搞反了。是專題橫幅模板去讀取WPBS的評級參數，而不是WPBS去讀取專題模板的評級參數，故WPBS沒有輸入就是沒有，所以沒輸入沒顯示WPBS乃正常現象，並不是BUG。說BUG代表你不理解它的邏輯，甚至是弄反了它的邏輯。至於你希望WPBS能正常顯示評級這一訴求，如果本案順利通過，機器人順利啟動，該問題自然會被解決。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 15:49 (UTC)[回复]

總之全部都是Module:PJBSClass/main的問題，不鑲嵌模板就無法判斷，但「條目內掛了模板所以可以判斷」，您如果那麼清楚的話，那就直接建模板阿。標準的自欺欺人，結果居然是沒動腦過的回覆，被潑冷水真的剛好而已。這樣如何保證裡面可以不用寫上比如|class=xxx的參數，變成{{WPBS|collapsed=yes||class=xxx還能讓它正常顯示？--Z7504非常建議必要時多關注評選（留言） 2024年1月22日 (一) 23:21 (UTC)[回复]
- 不需要保證，因為機器人會自動填寫{{WPBS|collapsed=yes||class=xxx，保證的話等於和機器人搶工作，與本案背道而馳，因為該設計就是要給機器人維護的空間，如果沒有正面回答此陳述將視為無效。沒填寫|class=顯示不一樣，反而還有能分辨機器人是否填過的功能，豈不是更好？另，(！)抗议沒考量讀者體驗就亂講的提案，評級是面向編者的資訊，(－)強烈反对把評級寫在條目裡，故我認為目前的方案已是最適合的方案；另，在此警告，在此案討論|class=參數已離題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 01:24 (UTC)[回复]

@Z7504：我直接針對你最初的問題回答「是不是還要寫{{WPBS|class=xxx}}才能讓其強制正常顯示？」，是，所以需要手動填上。本案並不包含甲乙丙初級自動判斷，公示也不包含這個部分，若你希望有甲乙丙初級自動判斷請另提他案，因為不在本案處理範圍內。此外，你也無須擔心「是不是還要寫{{WPBS|class=xxx}}才能讓其強制正常顯示？」問題，因為下方Kanashimi已經申請機器人了，您無需手動填寫，此意見可以結案了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 01:44 (UTC)[回复]

本公示不包含甲乙丙初級自動判斷，若三日後還在要求甲乙丙初級自動判斷將視為無效意見。若希望|class=沒輸入也能自動顯示甲乙丙初級請另外提案謝謝，不在本案有辦法處理的範圍內。「這點小bug麻煩也先改了吧，不然都還要強制輸入才能確保正常顯示，問題不大才對」本案是處理基礎條目自動化，而不包含class有沒有輸入的問題，因此不在此案處理範圍內，請另提他案，謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 02:02 (UTC)[回复]

如果繼續提與本案無關的東西將視為擾亂（class參數與本案無關，本案是處理基礎條目自動化的），屆時將進行提報。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 03:20 (UTC)[回复]

(※)注意一案歸一案，沒有什麼「順便幫改」這種事。故「這點小bug麻煩也先改了吧，不然都還要強制輸入才能確保正常顯示，問題不大才對」試圖強迫該案納入不在該案範圍之言論，就是擾亂。如有需求，請另外提案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 03:38 (UTC)[回复]
- 如果三日內，沒有人對「該意見與本案無關」有異議，則視為該意見與本案無關，不影響本公示的通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 03:44 (UTC)[回复]

已提出機器人作業申請，歡迎提供建議，謝謝。 --Kanashimi（留言） 2024年1月23日 (二) 01:38 (UTC)[回复]

您直接宣布通過就好了，不必再等三天，因為您全部都解釋完畢了，拒絕再溝通。另外有關Kanashimi所提議的機器人提案，沒有意見。如此的溝通是不可能會有共識的，別浪費時間了。您如果這麼愛寫新的條目，麻煩自己繼續寫條目就好，不要打擾了。因為維基百科的條目已經足夠多了，如果不想寫新的其實也沒差。因為設立A article、B article、C article、Start article、Stub article...這些模板也會有人有意見，但「不鑲嵌模板就無法判斷，掛了模板所以可以判斷」，怪誰啊？上面也講了您既然自己都知道是Module:PJBSClass/main影響的，但不去考慮修訂Module:PJBSClass/main，那麼就有設立這個機器人的必要。--Z7504非常建議必要時多關注評選（留言） 2024年1月23日 (二) 04:36 (UTC)[回复]
- 但問題是，如果該機器人要能運作，本提案要先通過才行。所以既然你如上說法，我就視為你不反對本提案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 04:43 (UTC)[回复]
  - 行，您可以直接通過了吧。--Z7504非常建議必要時多關注評選（留言） 2024年1月23日 (二) 04:44 (UTC)[回复]
還有一點我要聲明，並不是不願意修訂module:PJBSClass/main，而是module:PJBSClass/main本來就是設計成要配合Kanashimi所提議的機器人提案而設計的，那麼要做的事情顯然是讓機器人提案推行順利，而不是去浪費時間修改module:PJBSClass/main。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 05:06 (UTC)[回复]

公示期已到，期內無合理異議，且公示期內的意見之意見提出者已妥協，因此提案公示通過，將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

{{WikiProject Biography}}參數案

《將Vital_article併入WPBS的vital參數》案已進入公示，現就是否將{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數併入{{WPBS}}進行討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月24日 (三) 03:41 (UTC)[回复]
- c.f. Wikipedia:机器人/申请/Cewbot/29。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月24日 (三) 03:43 (UTC)[回复]
本討論開始於2024年1月2日 (二) 09:53 (UTC)（發起討論的留言見此），當中包含了支持的意見，至今已逾一個月，因此根據WP:1MONTH「互助客棧中的提案僅在7日內無新留言時或已討論達30日後，方可在已取得共識的前提下公示。」，且本段落已逾8日無新留言，已超過一周無新留言，因此根據WP:7DAYS，有人附議此案（全部支持視為該附議包含本案），而往後將近一個月沒有反對意見，因此視為已有初步共識，根據WP:1MONTH和WP:7DAYS將進行公示。（若三日無人對以上論述有異議將開始執行）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月2日 (五) 09:57 (UTC)[回复]

藍桌圖書館預覽插件

剛剛給藍桌圖書館（Bluedeck Library）寫了一個預覽插件。

blib-preview.js（原碼）

有興趣的人可以去試用看看。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 09:51 (UTC)[回复]

藍桌圖書館預設會將模板和分類转义成原始碼狀態來呈現，這樣閱讀上就會很困難，因此暫且做了一個能在閱覽藍桌圖書館時以接近條目原樣的方式檢閱藍桌圖書館條目。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 09:51 (UTC)[回复]

插件的效果如下圖所示：左圖是有安裝藍桌圖書館預覽插件的樣式；右圖是藍桌圖書館預設的樣式。（例子為圖書館:Astro_AEC）

歡迎大家試用與指點。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 09:51 (UTC)[回复]

技術點評

歡迎大家指點。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 09:51 (UTC)[回复]

最后加一句mw.hook('wikipage.content').fire($('#mw-content-text'));。--安忆 ^Talk 2023年12月12日 (二) 12:44 (UTC)[回复]

本主題或以下段落文字，已存檔副本至MediaWiki_talk:Gadget-SpecialWikitext.js。執行人：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月14日 (四) 10:03 (UTC)[回复]

(？)疑問：@AnYiLin：所謂的「最後」是指哪個位置呢？是最後一行？還是拿到API解析完wikitext的HTML加入的當下？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月12日 (二) 12:48 (UTC)[回复]

内容被填充进页面之后，以解决当前不能折叠模板的问题。--安忆 ^Talk 2023年12月12日 (二) 12:50 (UTC)[回复]

(？)疑問：@AnYiLin：那麼這樣的話，類似作法的MediaWiki:Gadget-SpecialWikitext.js是否也須mw.hook('wikipage.content').fire($('#mw-content-text'));？不然來自API的HTML摺疊應該都會故障-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月12日 (二) 13:51 (UTC)[回复]
应该不用，你这个脚本直接把mw-content-text清空了，SpecialWikitext.js只是添加节点。--安忆 ^Talk 2023年12月12日 (二) 13:56 (UTC)[回复]
但你确信来自API的HTML里需要折叠的话，可以mw.hook('wikipage.content').fire(对应的jQuery节点)。--安忆 ^Talk 2023年12月12日 (二) 13:57 (UTC)[回复]
是。@AnYiLin：所以我想問的是，假設有人在MediaWiki:Gadget-SpecialWikitext.js用了需要折疊的語法，會失效嗎？如果會，MediaWiki:Gadget-SpecialWikitext.js在来自API的HTML是否需要再次執行mw.hook('wikipage.content').fire()？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月12日 (二) 14:01 (UTC)[回复]
要的，将最终插入页面的jQuery对象作为fire的传参。--安忆 ^Talk 2023年12月12日 (二) 14:04 (UTC)[回复]

第一行可以直接$(async () => { ... })；第二行意义不明；第八、一百零七行，既然都用jQuery了，可以用$("

").attr(...).append(...)构造元素，直观且容易维护；第十七、一百三十七行可以使用mw.util.getUrl；第四十行的page_name_lower应该不会存在空白字符；第四十六、四十七行的({})[0]是个非常罕见又奇怪的用法，可以直接不赋值或显式赋值undefined；第四十九、六十五行，++i和i++的行为不同，一般用i++；第八十三行的$notice_loading已经是JQuery对象了，不需要再包装；第一百二十四行可以直接用$mw_content_text.html("")；从九十九行开始不知道为什么变成了Promise链，mw.Api和$.getScript也可以await，异常可以用try {} catch {}处理；一些jQuery查询可被复用，比如刚刚提到的mw.hook就可以传递第一百一十一行的$mw_content_text，因为被另行保存的jQuery查询只是对象引用。--安忆 ^Talk 2023年12月12日 (二) 13:16 (UTC)[回复]

格式上可以本地用Prettier处理下，或是在线版。感觉你是写C的。--安忆 ^Talk 2023年12月12日 (二) 13:28 (UTC)[回复]

(：)回應：@AnYiLin：「从九十九行开始不知道为什么变成了Promise链」，前半有部分是複製藍桌的程式碼，他用await居多，後半主要我加的，我之前比較慣用Promise链。我寫C++習慣用++i，聽以前教授講這樣編譯完少一個取值動作跑比較快，所以我好多年來都寫++i。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月12日 (二) 13:55 (UTC)[回复]

不是习惯的问题，是它们的行为不同。Promise链会异步出去，后者i的值不同。--安忆 ^Talk 2023年12月12日 (二) 13:59 (UTC)[回复]

(：)回應：@AnYiLin：這是我在十分鐘內完成的超高速開發（第一版十分鐘內搞出，後面就只是修BUG），當然都是複製現有程式碼，前半有取自藍桌的，後半从九十九行开始用Promise链是因為為了快速完成，直接複製了之前MediaWiki:Gadget-SpecialWikitext.js裡面的代碼隨插即用零成本無須思考無須開發高速完成。所以才是現在你看到的樣子。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月12日 (二) 14:20 (UTC)[回复]

(：)回應：@AnYiLin：據我所知，無論i的值為何，在for回圈內他恆為第一次0、第二次1、第三次...直到最後一次，每次遞增一，在for(;;)中動作對後方{}幾乎沒有影響。故不認為++i和i++會對回圈演算法造成任何影響。另我所指的++i比i++更有效率網上也有類似討論-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月12日 (二) 14:04 (UTC)[回复]

我说“++i和i++的行为不同，一般用i++”，你当然可以不用。现代JS用for (const element of array) {}。--安忆 ^Talk 2023年12月12日 (二) 14:08 (UTC)[回复]

(：)回應我最習慣/常用的程式語言確實是C++。（其實我之前的維基百科機器人都是用C++寫的，如User:A2569875-bot/Code/CleanFrenchCommune.cpp，只是最近發現JavaScript比較方便些而已w）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月12日 (二) 14:13 (UTC)[回复]

(：)回應：@AnYiLin：

「最后加一句mw.hook('wikipage.content').fire($('#mw-content-text'));」
已加入。Special:Diff/80090859
「第一行可以直接$(async () => { ... })」
已修改。Special:Diff/80116942
「第二行意义不明」
已移除。Special:Diff/80117018
「第八、一百零七行，既然都用jQuery了，可以用$("
").attr(...).append(...)构造元素，直观且容易维护」
已修改成$("
").attr(...).append(...)。Special:Diff/80116942
「第十七、一百三十七行可以使用mw.util.getUrl」
已改用mw.util.getUrl。Special:Diff/80117018
「第四十行的page_name_lower应该不会存在空白字符」
已刪除.trim()。Special:Diff/80117185
「第四十六、四十七行的({})[0]是个非常罕见又奇怪的用法，可以直接不赋值或显式赋值undefined」
已改為不赋值，讓預設為undefined。Special:Diff/80117018
「第四十九、六十五行，++i和i++的行为不同，一般用i++」
這點很抱歉，因為我寫C++都這樣用，突然要我改，我覺得很怪。所以很抱歉。
「第八十三行的$notice_loading已经是JQuery对象了，不需要再包装」
已移除包裝。Special:Diff/80117018
「第一百二十四行可以直接用$mw_content_text.html("")」
已改為$mw_content_text.html("")。Special:Diff/80117185
「从九十九行开始不知道为什么变成了Promise链，mw.Api和$.getScript也可以await，异常可以用try {} catch {}处理」
已改成await。Special:Diff/80117185、Special:Diff/80117310
「一些jQuery查询可被复用，比如刚刚提到的mw.hook就可以传递第一百一十一行的$mw_content_text，因为被另行保存的jQuery查询只是对象引用。」
已复用

以上，十分感謝您的反饋。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月15日 (五) 01:09 (UTC)[回复]

使用反饋

歡迎大家試用並給予反饋。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 09:51 (UTC)[回复]

目前有看到幾個人試用不曉得有沒有什麼可以反饋的？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月30日 (六) 02:02 (UTC)[回复]
- 是否都運作良好？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月24日 (三) 13:45 (UTC)[回复]

其他討論

最讓我意外的是，收到的都不是「使用上的反饋」而是「對程式碼寫法的點評」😅 囧rz……。我自己是有使用啦Special:Diff/80073676，順便連藍桌圖書館快線和藍桌圖書館獲取源碼工具也裝了-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月14日 (四) 12:31 (UTC)[回复]
使用反馈不就在那摆着呢，“模板的展开/折叠功能失效”么。怎么改也贴出来了。
要是别人指出怎么改又丁点儿不改，就别说“欢迎大家指点”了，免得别人花时间无偿review却只是被一笔带过成“对代码写法的点评”。明明复杂度那么低，结果一搭眼连逻辑上都有问题，这要放ESLint里随便开点儿常用规则没个百八十errors都跑不了。--安忆 ^Talk 2023年12月14日 (四) 15:32 (UTC)[回复]
- 這就是時間上的問題。我精神上是以「能用」為導向，如果功能正常，且日常生活忙碌，就很難有時間把相應內容做更改，畢竟如果功能正常，您上面的意見就類似於「代碼優化」讓程式變得「更好」。例如您說的「從九十九行開始不知道為什麼變成了Promise鏈」我日常生活繁忙，不一定有時間研究如何將之改成「非Promise鏈」寫法，有些寫法是既然運作上正常，然後日常生活又繁忙，那我就不一定會有閒暇時間把您所指出的善意提醒一一修正，因為大部分代碼「不修改」「似乎」也能「正常工作」。我當然很感謝您所指出的那些意見，但是因為功能正常的話，要一一改動也挺費時的，再加上我一旦改動了，您所指出的行號就會全部跑掉，這樣對照上也會十分麻煩，所以，我精神上感謝您的提點，但是實務上我可能沒那麼多精力去把它一一修改。再次感謝您所提供的意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月14日 (四) 16:09 (UTC)[回复]
  看来功能正常是指直观层面的“模板的展开/折叠功能失效”是很正常的预期现象，既然这么正常，你还把它写出来放在“已知BUG”做什么。
  
  你都以“能用”为导向了，还在这儿谈什么使用反馈、欢迎指点。看到了问题就没精力、费时间、能用就行，殊不知别人也在花时间给你，行号和大体改法都给了对吧。你这样子我也不再费口舌提逻辑层面的东西了，浪费时间换你的精神感谢怕是没大用。
  
  你就当我单纯告诉过你怎么解决你所谓的“已知BUG”算了。--安忆 ^Talk 2023年12月14日 (四) 16:59 (UTC)[回复]
  承您貴言，我都盡可能對於您提出的每個修改意見都進行修改了Special:Diff/80116793/80117185。很抱歉，浪費了您寶貴的時間。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月15日 (五) 00:54 (UTC)[回复]
  很抱歉，之前我的行為讓你失望了。也感謝你願意提供技術反馈。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月22日 (五) 10:41 (UTC)[回复]

評級系統缺失問題

（原始標題為「將{{Classicon}}與{{Class/icon}}同步」配合公告欄調整標題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 07:47 (UTC)）[回复]

配合上方#Random_Thought: 跟进英维的WikiProject_banner_shell改版因此需要解決評級系統缺失問題，故提出以下議案-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)[回复]

預計辦理流程：
1. 修正評級系統被不當過濾掉的評級值： 公示通過等待佈署……
  讓評級系統Special:页面评级均能正確接收到評級值，以便讓{{WikiProject_banner_shell}}工作順利。
2. 同步各模板/块的評級值： 公示通過等待佈署……
  評級元模板調用了多個不同的評級值轉換模板，但各評級值轉換模板/块的評級值定義有所出入，將會影響{{WikiProject_banner_shell}}的運作，因此需要修正。
3. 將{{Classicon}}與{{Class/icon}}同步： 公示通過等待佈署……
  以上都完成後，目前評級系統的圖是在各評級定義模板/块不一致，且Style也不一致，為了與XTools也統一，故作出此提案。
目前先做到這樣，統整整個評級系統並修正評級系統缺失問題。若未來還有需要調整的會在辦理過程提出，滾動式修正，歡迎發表意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 08:06 (UTC)[回复]

第一階段：修正評級值不同步問題

議案1：將{{Classicon}}與{{Class/icon}}同步

已通過：

公示通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:14 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

我認為應將{{Classicon}}與{{Class/icon}}同步。{{Class/icon}}提供了比{{Classicon}}更多種級別的圖示，如請求、未來、動態等評級的圖示，{{Classicon}}都沒有。而若{{Classicon}}與{{Class/icon}}合併的話，則等同於{{Classicon}}改成Module模式，需要社群共識，故發起討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)[回复]

(＋)支持合併，後者（{{Class/icon}}）目前只有在154頁上使用。-- Willy1018（留言） 2023年12月26日 (二) 01:33 (UTC)[回复]

(？)疑問：@Willy1018：那要不要{{Classicon}}重定向到{{Class/icon}}？剛才已補充{{Classicon}}所有功能到{{Class/icon}}了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月26日 (二) 02:33 (UTC)[回复]

可以，但前者{{Classicon}}被全保護，只有管理員才能進行編輯，需要提{{ep}}。-- Willy1018（留言） 2023年12月26日 (二) 04:56 (UTC)[回复]

似乎未來之类的评级并未被整个评级系统完全支持？--百無一用是書生 (☎) 2023年12月28日 (四) 02:24 (UTC)[回复]

(：)回應：@Shizhao：有支持，顯示評級的最後一個調用是{{WPBannerMeta/qualityscale/mask}}，而{{WPBannerMeta/qualityscale/mask|future}}→「未来」，但在要送入{{#assessment:}}的{{Class_mask}}需要設|future=yes才有，不然會被濾掉。而要送入{{#assessment:}}的{{Class_mask}}直接寫死無法設定參數，故建議將要送入{{#assessment:}}的mask改用{{WPBannerMeta/qualityscale/mask}}，這樣才能正確支援。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月28日 (四) 02:50 (UTC)[回复]

@Shizhao：已提出編輯請求，Template_talk:WPBannerMeta/core#編輯請求_2023-12-28，處理完畢後未來之类的评级就能被支持了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月28日 (四) 04:11 (UTC)[回复]

(＋)支持，沒特別的意見--Z7504非常建議必要時多關注評選（留言） 2023年12月28日 (四) 14:13 (UTC)[回复]

支持合并。不过纯模板实现也不错。--桐生ここ★[讨论] 2023年12月28日 (四) 21:48 (UTC)[回复]

@桐生ここ：完全不建議模板實現。現時模板實現是使用{{#switch:}}，您忘了2020年初{{#switch:}}爆炸事件Special:PermaLink/58036835#A_technical_issue_with_articles_of_French_communes導致中維崩潰的事件了嗎。{{#switch:}}的開銷要高於模組實現，所以建議使用模組實現，安全又有效率。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月29日 (五) 00:06 (UTC)[回复]

這邊最近在處理基礎條目與{{WikiProject banner shell}}的圖示問題（Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版，暨將{{Vital_article}}併入{{WPBS}}），(＆)建議直接採用{{Icon}}會更通用。--Kanashimi（留言） 2024年1月2日 (二) 09:18 (UTC)[回复]

但我覺得要有專題專用模板。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 09:33 (UTC)[回复]

我想採用不同模板來處理同一件事的問題是較不易維護。--Kanashimi（留言） 2024年1月2日 (二) 09:49 (UTC)[回复]

@Kanashimi：問題是目前{{Icon}}並未完整涵蓋Class/icon現有內容。改用{{Icon}}將會導致部分圖是消失，或發生變化。我認為專題圖示應該要統一的Style，但例如{{Icon|image}}

和{{Class/icon|image}}

就不一致，而且{{Icon|image}}

與以下圖示比較{{Class/icon|image}}

、{{Class/icon|A}}

、{{Class/icon|B}}

、{{Class/icon|C}}

明顯Style嚴重變調，故(－)反对。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 10:13 (UTC)[回复]

或許我們可以擴展{{Icon}}使之涵蓋我們想要的範疇，例如採用{{Icon|image_class}}？--Kanashimi（留言） 2024年1月2日 (二) 10:20 (UTC)[回复]

@Kanashimi：我這個議案只是想先動全保護模板{{Classicon}}，至少先同步圖示，但您目前這樣介入會導致共識亂了，連同不都做不到了，會導致花費更多「跑流程」時間，我想先同步，也做好patch了，都準備好了被你弄沒了？我想先動全保護模板{{Classicon}}至少先同步圖示；至於以後怎麼維護可以再討論。而且您的提議「例如採用{{Icon|image_class}}」也還沒有patch，先現實一點吧，不要紙上談兵，我只想趕快同步圖示，並讓Style一致，評級圖示是評級圖示，其他圖示是其他圖示；評級圖示就該有評級圖示自己的Style，(！)抗议亂七八糟的不一致Style圖示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 10:29 (UTC)[回复]

也好。那就等這個討論結束再說吧。--Kanashimi（留言） 2024年1月2日 (二) 10:30 (UTC)[回复]

@Kanashimi：問題2{{Icon|image_class}}會導致評級模板輸出的值無法直接輸入此模板。評級模板肯定是輸出字尾沒有「_class」的結果，你這樣搞還要多寫一個轉換器，不是更難維護？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 10:33 (UTC)[回复]
我嘗試在Module:Icon/data加上下面的項目，似乎可以用？
```
	image_class = {
		image = "Symbol file class.svg",
		tooltip = "媒體文件頁",
	},
```
--Kanashimi（留言） 2024年1月2日 (二) 11:00 (UTC)[回复]
- @Kanashimi：您誤會了。我說評級模板「不會」輸出字尾有「_class」的結果，既然字尾沒有「_class」，那你又要怎麼從專題模板的輸出指到『image_class』？？？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 11:02 (UTC)[回复]
  如您前面所述，我想這些問題先等這次的合併作業完成之後再說吧。別弄亂了主線。--Kanashimi（留言） 2024年1月2日 (二) 11:10 (UTC)[回复]

此段落最後發言至今已逾七日，超過一周無新留言，因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 12:56 (UTC)[回复]
公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 12:56 (UTC)[回复]

公示期已過，期內無合理異議，提案通過，將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:14 (UTC)[回复]

請管理員編輯Template_talk:Classicon#編輯請求_2024-01-16。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:19 (UTC)[回复]

已由User:AT完成佈署-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:49 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

議案2：修正評級系統被不當過濾掉的評級值

已通過：

公示通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:41 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

上方User:Shizhao提到「未來級」等評級級別無法被完整支持問題，是因為送入評級系統的評級值被不當過濾掉了，即使專題上層已啟用該等評級，但最終還是會被「未繼承上層參數的{{class mask}}」過濾掉，這樣的話就算專題啟用了該等評級也沒有用，都被濾掉了，根本裝飾，白啟用了，因此提議將送入評級系統的評級值改為{{WPBannerMeta/qualityscale/mask}}模板，見編輯請求Template_talk:WPBannerMeta/core#編輯請求_2023-12-28，修改前後的比較Special:PermaLink/80307466，可以看到原有的版本評級值大部分都被濾掉了，建議換成提議的Patch，以讓「未來級」等評級級別能真正被支持。同時，我也確認值接送未來級能正確被工具識別，見右圖，連圖示都有，代表評級系統是支援此輸出的，能正確地被讀取並識別。

因此提出本動議。不曉得各位有沒有異議或意見。Ping參與過相關討論的人@桐生ここ、Z7504、Shizhao、Willy1018：，上方參與過評級討論的也Ping一下@暁月凛奈、Lopullinen、Milkypine、MilkyDefer：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月31日 (日) 08:29 (UTC)[回复]

支持。( π )题外话：台湾之星的标识现在还没改。--桐生ここ★[讨论] 2023年12月31日 (日) 10:36 (UTC)[回复]

資慈，我覺得行。 --窝法乙烷儿法梦碎 2024年1月1日 (一) 14:38 (UTC)[回复]

此段落最後發言至今已逾七日，超過一周無新留言，因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 2024年1月8日 (一) 14:39 (UTC)[回复]
公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 14:39 (UTC)[回复]

公示期已過，期內無合理異議，提案通過，將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:41 (UTC)[回复]

請管理員編輯Template_talk:WPBannerMeta/core#編輯請求_2023-12-28。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:45 (UTC)[回复]

已由User:AT完成佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:49 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

議案3：同步各模板/块的評級值

已通過：

公示通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:40 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

目前有多個被全保護的評級模板/块的評級值（如有的有漏掉、有的圖案、顏色不一致）並不同步，因此提議同步各評級模板/块的評級值。不曉得各位有沒有異議或意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月31日 (日) 10:30 (UTC)[回复]

(～)補充相應的編輯請求Module_talk:Class/data#編輯請求_2023-12-28、Template_talk:Class_mask/core#編輯請求_2023-12-25和Template_talk:Class_mask#編輯請求_2024-01-05（和2023-12-25是配套的），顏色的部分：Template_talk:Class/colour#編輯請求_2024-01-05。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月31日 (日) 10:31 (UTC)[回复]

支持。--桐生ここ★[讨论] 2024年1月1日 (一) 09:03 (UTC)[回复]

就先改看看，讓其他用戶實際去測試這樣才準，而不是每天一直喊支持。不然只是一直放沙盒而不去實際更改的話，完全不知道到底能不能測試。雖然維基百科終於有認知要將其功能「進步」，但也不應每日這樣「無止盡的討論而沒有作為」才是。因此，這個討論就不用再多說什麼了。--Z7504非常建議必要時多關注評選（留言） 2024年1月1日 (一) 11:52 (UTC)[回复]

(：)回應：@Z7504：其實我有私下找User:AT了，但他一直說影響範圍太大要先討論

囧rz…………。我當然也希望能直接改啊，不然WP:7DAYS獲共識再公示7天半個月就過去了……-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月1日 (一) 12:05 (UTC)[回复]

還想說中文維基百科不是長期以來都對專題這個東西愛理不理的，這不就是專題模板在用的相關評級嗎？為什麼不直接修改讓其他人測試呢？建議AT直接幫忙修改吧。因為如果要叫維基百科廢除已經存在多年的專題，顯然是不可能的，更沒有討論是否要廢除專題的必要。--Z7504非常建議必要時多關注評選（留言） 2024年1月1日 (一) 13:45 (UTC)[回复]

此段落最後發言至今已逾七日，超過一周無新留言，因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 14:36 (UTC)[回复]
公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 14:36 (UTC)[回复]

公示期已過，期內無合理異議，提案通過，將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:40 (UTC)[回复]

請管理員依照這則留言佈署相關編輯，也就是編輯以下模板：
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:44 (UTC)[回复]

已由User:AT完成佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:49 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

提案已通過請求佈署

已佈署：

已由User:AT完成佈署-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:44 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

全案公示通過，請管理員依據以下留言：
#A2569875_2024年1月16日(二)13:19(UTC)

#A2569875_2024年1月15日(一)14:45(UTC)

#A2569875_2024年1月15日(一)14:44(UTC)

佈署相關編輯，也就是編輯以下模板：

-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:23 (UTC)[回复]

已由User:AT完成佈署-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:44 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

評級缺失問題目前辦理狀況

截至2024年1月5日 (五) 17:08 (UTC)已提出三案討論，三案皆在等待初步共識，以便公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]

評級缺失案辦理狀況
進度	討論中	公示中	部署中	已完成	後續維運
*通用評級設立	已獲共識	已通過	已完成	已完成	進行中
*評級繼承機制	初步共識	公示通過	已完成		進行中
評級值同步	初步共識	公示通過	已完成		進行中
修正過度過濾評級值	初步共識	公示通過	已完成		進行中
評級圖示同步	初步共識	公示通過	已完成		進行中
註：標有「*」表示是其他相關提案。

以上為截至2024年2月2日 (五) 09:45 (UTC)的辦理狀況。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]

2024年2月2日 (五) 09:45 (UTC)更新-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月2日 (五) 09:45 (UTC)[回复]

完成：在本次更新中，以下模板的評級資料已獲同步：
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 08:55 (UTC)[回复]

第二階段：依據先前共識將不是條目命名空間的評級分類從「XX級條目」改為「XX級頁面」

根據先前共識，需要將不是條目命名空間的評級「XX級條目」的分類改為「XX級頁面」，但因技術限制未能將「XX級條目」的分類改為「XX級頁面」，因此本案已提出新的方案，依據頁面命名空間添加分類，以實現該共識。具體執行方案在Template:WPBannerMeta/qualityscale/sandbox。同時將Wikipedia:条目质量评级标准移動到Wikipedia:页面质量评级标准，不知道各位有沒有異議？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:57 (UTC)[回复]

副知@Ma3r、Kanashimi、Z7504、桐生ここ：@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:58 (UTC)[回复]

沒有異議，~~就是不知道會不會出現突發狀況~~。 --窝法乙烷儿法梦碎 2024年1月17日 (三) 11:35 (UTC)[回复]

已在多面體專題進行測試，詳見Category:分类级多面体页面、Category:模板级多面体页面，目前測試整個多面體專題尚未出現問題。待本案正式通過之後才會正式(►)移动分類頁面。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 11:39 (UTC)[回复]

沒有意見，但在專題頁面（WikiProject）中使用到的{{Articles by Quality and Importance}}模板應一併解決顯示異常之問題（前幾天似乎還有這問題，現在不知道），雖然這模板平常根本沒什麼人在意

囧rz……（所以沒解決可能也沒差吧？因為專題本來就沒什麼人在意了）--Z7504非常建議必要時多關注評選（留言） 2024年1月18日 (四) 14:26 (UTC)[回复]

首先，結尾為「XX重要度」的分類不會移動，不在本計畫內，而{{Articles by Quality and Importance}}是讀取結尾為「XX級XX重要度」的分類，故基本上本案不會影響{{Articles by Quality and Importance}}。再來，如果這個真的要處理，要本案通過後，分類全部清理好，分類全數移動完成後才能處理，不然現在處理數字都會變成0。故應是下一個階段要處理的（或者共識是暫不處理），不是此案此階段討論範圍。此外，如果是{{Articles by Quality}}的話，直接更新分類名稱即可。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月18日 (四) 16:02 (UTC)[回复]

已逾一周無新發言，根據WP:7DAYS七日無進一步發言視為已獲初步共識，如本聲明無人有異議，將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月26日 (五) 00:32 (UTC)[回复]

後續討論

用户 Mys 721tx 不适合担任管理员

已有共識：

special:diff/80601514、special:diff/80605120--Kenny023（留言） 2024年1月24日 (三) 06:02 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

在被迫度过了2周维基假期后，准备发起用户Mys_721tx的管理员解任投票，根据指引先在互助客棧討論。整起事件起因本人于以下4个条目中作出的编辑：

用户Ohtashinichiro对本人于上述四个条目的编辑和回退行为，以“創建侵權條目，濫用回退”的名义对本人的巡查员、回退员权限提出申請解除權限，Mys_721tx错误地核准了相关申请，并留言 “取消兩項權限，封禁兩周，半年內不得申請。”

本人认为除权、封禁的做法有失公平，理据如下：

洪山菜薹条目中所谓 “侵权” 内容非本人所加，本人所做的编辑工作在于为被认为侵权的内容添加了引用来源、并对部分语句进行了维基化的转写；Ohtashinichiro将整个页面标记为侵权时，标注的侵权来源为百度知道的链接，但受到质疑后又在本人的讨论页指出了1994年出版《洪山文史第7輯》为条目中雷同文字的来源。由此可见，Ohtashinichiro要麼是提起版權驗證時還沒有考證到1994年的書籍、要麼是明明考證到了1994年的書籍但是故意不在討論頁留言與其他編輯交流，对于“自己认知中含有侵权内容”的条目一概直接全文贴上版权验证，事实上由于我被Mys_721tx封禁，亦无法至版权验证页面留言，导致洪山菜薹条目现已被删除，而不是按照指引“如果存在未侵權的舊有版本，你應該將頁面恢復到那個版本”；
紅燒木琴魚与黃陂三鮮条目为本人创建，由于维基百科不允许原创研究，自然需要引用外部链接中的内容，本人已对语句进行维基化转写、并按照标准格式添加了引用来源；
徽菜条目许多章节为空，且存在“最有代表性的”这种无法考证的、主观的观点，本人扩充了内容为空的章节，内容皆进行了维基百化转写、标注了引用来源，并对“最”等说法进行了中立化修饰；

本人于上述四个条目中的编辑行为，没有侵犯著作权，Ohtashinichiro没有认真阅读相关条目、就直接将页面提起版权验证的行为妨碍了读者对相关页面的浏览权益，亦不尊重本人和其它用户的编辑贡献，因此使用回退员权限回退了其相关破坏行为。Ohtashinichiro违反相关指引在先，没有“如果你懷疑某篇條目侵犯著作權，你至少應該將問題提交到條目的討論頁。其他人可以繼續對情形進行檢查，並在需要時採取行動。你所能提供的最有幫助的內容，是你所認為可能是該文字出處的URL鏈接或其他相關引用”，反而对本人提起巡查员、回退员解除权限，Mys_721tx错误核准了相关申请，并留言“取消兩項權限，封禁兩周，半年內不得申請”，属于滥用管理员权力。

关于版权验证与页面删除：社群应严格限制将整个页面标记为侵权验证，尤其是在内容已经转写、并注明了来源的情况下。维基百科不允许原创研究，因此所有内容均须有来源，而特定类型的条目必然存在与来源表述近似的情况。以我经常编辑的饮食类条目为例，许多不常见的老菜来源单一、不可能做到“只有重新以自己的語言總結原文思想才不屬於抄襲”，因为原文可能没有“思想”，而是对原材料、配料、烹饪方法及其成菜应当具备的形态进行了准确描述或规定，如本人“以自己的语言总结”则可以轻易造成传播错误的信息、而“僅僅作小規模的改動”又被视为侵权，那么我能否因此推断，所有鲜为人知的、但是确实存在的菜品条目，都没有存在于维基百科的意义和可能？

关于回退：以徽菜条目为例，本人的回退是将“其最有代表性的萊肴有”回退为“其中有代表性的萊肴有”，而Ohtashinichiro则是将“其中有代表性的萊肴有”回退为“其最有代表性的萊肴有”，Ohtashinichiro有何依据可以证明目前条目中所列出的菜肴就是“最”有代表性的？Ohtashinichiro和Mys_721tx一个共同的问题是一叶障目，对他人的编辑根本不仔细阅读、亦不沟通交流，就直接回退、提出申請解除權限、除权、封禁，试问本案例中，是谁在滥用回退权限？

综上：

本人认为，对维基百科来说，管理应当是手段、而不是目的，本次在“侵犯著作权”情况未明、缺乏讨论的情况下，Mys_721tx未有警告，直接对我的账号进行除权、封禁，已经属于管理员滥权。具体来说，已达到解任條件中的：

不合理的封禁用戶~~或者以封禁相威脅~~。

此外，从上月其它用户对其发起的解任投票讨论页、其它用户过去6个月内于其讨论页的若干留言亦可看出其已：

一再发生的、严重违反社群共识及礼仪。

Mys_721tx缺乏对其它维基百科编辑的最基本善意，擅长曲解指引、忽视必要流程、恶意推定、滥用权力，把“管理”本身当成了目的而不是手段，自挂“維基侵權拯救者”标签，实则严重危害条目及其内容的扩展，与维基百科“讓讀者在使用中獲益”、“全面收集世界上所有的知識”的目标背道而驰，已显然不适合继续担任维基百科管理员。--Zheng Zhou（留言） 2024年1月16日 (二) 07:53 (UTC)[回复]

@Zheng Zhou：解任方針規定溝通無效的情況下才可以發起，請論證為何溝通無效。--Sun After Rain 2024年1月16日 (二) 08:14 (UTC)[回复]

您好，可参见我与Mys 721tx的沟通，在包括但不限于：部分文字雷同的条目应当讨论改写还是删除，较为依赖来源、不适宜或无法完全重写的话条目还有无存在价值，什么程度的转写仍构成“抄袭”，何为“逃避責任”，何为“惡意推定”，不经警告就直接除权、封禁是否涉及滥权等问题上，基本理念有很大差异，继续沟通已无意义。--Zheng Zhou（留言） 2024年1月16日 (二) 08:20 (UTC)[回复]

Mys 721tx的确狠人，也缺乏足够的提醒。但就案例中问题，提案者也不占理，因为相关内容经过提案者和第三方核查后，是存在大量内容高度相同的，提案者作为相对资深的前新页面巡查与回退人员，居然没意识到这些问题，并且诉诸情感来反驳，我不认为作为条目巡查是合适的行为。你可以跟2023年北京地铁追尾事故的对比，至少大量来源的大段原文中只抽部分描述（之后对过还是不太好，又再改写过，令其更不像来源原文），这样可以避免与原文来源相似。但显然提案者没做这点，和确实复查来源侵权问题。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月16日 (二) 09:13 (UTC)[回复]

如果有原管理员权限的或者愿意按照WP:HISTORY去申请复原查看的话，可以看看原始记录，只能说类同侵权太明显了。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月16日 (二) 09:15 (UTC)[回复]

不能赞同，我的论述中也已经提到了，条目与条目不一样、其背后的知识本身的性质也决定了“改写”能到什么程度而不算错误信息。以徽菜条目中的“中和汤”章节举例，这是一道知名度较低、但是有严格菜谱规定形制和制作方法的菜肴，来源/菜谱写为“首先要选上好的白豆腐，精心切成米粒大小的豆腐块”，我转写成了“將白豆腐切成米粒大小的豆腐塊”，如果这样还要算雷同的话，那么请问怎样转写才能做到“只有重新以自己的語言總結原文思想才不屬於抄襲”呢？其它几个章节、还有另外被删除的三个条目其实都是同理，我可以改写成“將豆腐切成豆腐塊”（如果这样就不算雷同/抄袭了的话），但是缺乏“米粒大小”的形制要求和“白豆腐”的食材要求，严格意义上来说这就不能叫“中和汤”了，那么请问我是应该写错误、不准确的信息，还是说因为无法做到“只有重新以自己的語言總結原文思想才不屬於抄襲”因此就干脆不编辑了、这些条目没有存在的价值和可能了呢？--Zheng Zhou（留言） 2024年1月16日 (二) 09:36 (UTC)[回复]

另外，我不知道“狠人”是褒义还是贬义，但是“也缺乏足夠的提醒”是可以轻轻一笔带过的，身为管理员，行使管理员的权限就必须要遵守相关指引，不可能只有权力、不履行义务，滥用了权力，就应该被追责，是个不利于维基百科发展的“狠人”，那就不适合继续担任管理员，应当解任。--Zheng Zhou（留言） 2024年1月16日 (二) 09:39 (UTC)[回复]

Zheng Zhou的指控完全反證為何Mys_721tx對其之封鎖和除權決定確實正確。

經向管理員詢問獲取洪山菜薹條目的編輯歷史，條目原始版本（2012年）為重新導向，實質僅有閣下曾在該條目添加內容（2017年及2023年），其餘用戶的編輯全數為移除內容或分類調整之類的小編輯。既所有添加的內容都是您所寫，那自然洪山菜薹條目中所謂「侵權」內容非本人所加一說純屬撒謊或閣下不記得您自己2017年添加了內容。
書籍版權需在筆者死後70年才進入公有領域，1994年出版的書籍顯然不可能版權公開。不論是抄襲了百度知道還是抄襲了1994年的書籍都確實構成侵權。
刪除上述條目的管理員並非Mys_721tx，將「如果存在未侵權的舊有版本，你應該將頁面恢復到那個版本」的說法拿來指控Mys_721tx完全是亂來。
經複查紅燒木琴魚及黃陂三鮮二條目刪除前最後版本及徽菜被回退的版本，Zheng Zhou稱做過「對語句進行維基化轉寫、並按照標準格式添加了引用來源」，但隨手查都找到多個20-30字的完ju子整句與原始的文字來源一模，或僅有小規模刪減，即寫的人顯然不是他，乃確實屬於侵權文字。Wikipedia:版权常见问题解答 § 我想转载的內容都是常识啊！明確指明「僅僅作小規模的改動不算是用自己的文字，您應當重寫」。即Mys_721tx的執行是基於社群長久以來的做法而非「出於自己的立場、觀點或想法」。
Zheng Zh多次聲稱「不應嚴格對待摘抄某些範疇內容」（如這類內容，轉寫時就不太敢對文字做出大幅改動，要是傳遞了錯誤信息豈不是危害更大？這類內容有特定的文化意義，在「摘抄」的尺度評判方面是否可以較一般條目相對沒有必要那麼嚴格？、這類內容，轉寫時就不太敢對文字做出大幅改動，要是傳遞了錯誤信息豈不是危害更大？這類內容有特定的文化意義，在「摘抄」的尺度評判方面是否可以較一般條目相對沒有必要那麼嚴格？），全無方針指引依據，侵權就是侵權，不存在例外情況，整個食譜的寫法完全抄錄而僅作刪減按社群規定就是侵權，不存在「例外」一說。以此論管理員侵權實屬捏造規則。
既以上所證明內容確實屬於侵權，封鎖方針亦將「持續侵犯版權」列明為管理員可以實施封鎖的情況，那麼封鎖自然不可能符合「不合理」（因其理是有效），此絕不能作為提出除權之合理理據。
Ohtashinichiro提侵權刪除的通告訊息本已有多次警告的作用，管理員在他人多次警告下封鎖合情合理，不存在Zheng Zhou所聲稱「管理員在未有警告的情況下封鎖」。方針從來沒有要求警告必須由管理員發出才算警告，甚至連發出警告也只是「應」，只是建議，而不是要求（「必須」），以此論管理員濫權更是無稽之談。

Zheng Zhou完全對維基百科關於版權的嚴謹性不存在認知，反而來指控管理員濫權權限，鐵妥屬於輕率指控的不文明行為，應對此解任請求予以立即關閉。--路西法人 2024年1月16日 (二) 09:40 (UTC)[回复]

經補充詢問，洪山菜薹乃是複製、分拆自其他條目，就WP:AGF他不知道原內容存在侵權；但剪貼移動本來也是侵權舉動（就算原內容沒侵權，也是侵犯維基百科本身自己的版權協議），所以侵權事實依然存在。--路西法人 2024年1月16日 (二) 09:49 (UTC)[回复]

你就不能AGF一下假定「剪切移动是侵权」不是符合一般人直觉认知的么？你想想你在电脑上编辑文档，要移动、拆分内容的时候是怎么操作的？--Milky Defer 2024年1月16日 (二) 09:54 (UTC)[回复]

我論證的是Mys_721tx沒錯，而不是他錯沒錯。--路西法人 2024年1月16日 (二) 09:55 (UTC)[回复]

請必須謹記，好心做壞事仍然屬於擾亂行為。不論提案人原意是改善維基百科、保護特定資訊，但確確實實就是侵犯了版權，也違反了維基百科的規則，因而被除權和封鎖。然而提案人完全不審視自己的問題、不先考慮對方封鎖的理據為何和如何判定，就逕自以其個人的錯誤標準斷定自己做的是正確，反去指控他人濫權、濫提除權。先去ABF別人的不值得我AGF。--路西法人 2024年1月16日 (二) 10:01 (UTC)[回复]

不加注明的剪贴移动、翻译条目确实是侵权，如果觉得无所谓，属于闯红灯行为。--YF dyh000（留言） 2024年1月17日 (三) 06:04 (UTC)[回复]

1. “不加注明的剪贴移动”言过其实了，红烧木琴鱼与黄陂三鲜条目中均已标注了准确来源，洪山菜薹条目中标注了来源、但我确实没有查证到94年出版的书籍为第一手来源，添加的来源为第二手来源，但是无论是哪个条目都不存在“剪贴移动”的情况，社群中部分编辑认为我的改写不够彻底，但本人已经多次论述了转写到什么程度不算抄袭的问题，至今未见回应；2. 没看出来“翻譯條目”跟本次事件中的几个条目有什么关系。--Zheng Zhou（留言） 2024年1月18日 (四) 02:48 (UTC)[回复]

社群已經多次反駁了你的論述，說過了你的撰寫程度顯然仍然構成侵權，所謂「未見回應」僅是閣下充耳不聞。--路西法人 2024年1月18日 (四) 02:55 (UTC)[回复]

本人知道社群中已有多位编辑反驳了我的论述，但是在本人看来目前出现的反驳均属于对立（Contradiction），即“因为你的撰寫程度顯然仍然構成侵權，所以你的撰寫程度顯然仍然構成侵權”，未能直接回应我论述中的关键点：我编写的条目中，还要怎样转写才能不算抄袭/雷同？这个“度”我还真不明白究竟是谁在掌握，如果维基百科有一个工具能直接告诉我雷同度达到了多少百分比、算作抄袭，我觉得也是合理的。但是既然没有一个客观明确的百分比数作为判断标准，那么讨论沟通是否就是获知这个“度”在哪里、如何优化条目质量的合适方式了？我的另一个问题，即“菜品类，無法做到只有重新以自己的語言總結原文思想才不屬於抄襲的條目是否沒有存在的價值和可能了”是个可以用“是”和“否”回答的问题，我好像确实没有看到“是”和“否”的回答。因为如果社群的共识是“是”，即“此类条目没有存在的可能和价值”，那我可能也就没什么可说的了。--Zheng Zhou（留言） 2024年1月18日 (四) 08:48 (UTC)[回复]

那個，不好意思冒昧一提，僅提出WP:共識來說，在這裡提出討論，就是想要得出共識，對吧？而且共識們看來似乎已經有了。所以如果，現在看起來雖不滿意但結果還不錯（閣下還是在這裡也還是可以參與編輯維基百科），誠心建議閣下見好就收不要繼續想要膠帶了，一事歸一事，閣下先前的問題算是解決了也可以這麼說的對吧，過去就過去了，緊抓著過去是沒有辦法到新的未來的。想到前面有幾個糾結過頭的範例，結果都換來永封，這裡就不提了。

另外，如果閣下目前不太明白大家跟您解釋的，把看到的文字消化後重新轉寫出來是什麼呢，要不要先暫停寫條目呢，這麼多的條目可以讀，或許可以看出個分別來，也或許有沒被發現的複製貼上的內容，被您找出來，順便維護清理也是造福社群。等到開悟的那天再來把這些條目重新寫回來，我想也是佳話一樁。--Mafalda4144（留言） 2024年1月18日 (四) 16:14 (UTC)[回复]

好的。--Zheng Zhou（留言） 2024年1月20日 (六) 13:14 (UTC)[回复]

Zheng Zhou閣下請不要沮喪（拍拍您），往好的方向看可以繼續養成（？）帳號累積經驗值，不用冒成為LTA的風險還是很好的（注意問題發言>w<）--Mafalda4144（留言） 2024年1月20日 (六) 13:48 (UTC)[回复]

不能认同“對維基百科關於版權的嚴謹性不存在認知”这么大的帽子扣下来，本人的观点，还请阅读此论述。“方針從來沒有要求警告必須由管理員發出才算警告，甚至連發出警告也只是「應」，只是建議，而不是要求（「必須」），以此論管理員濫權更是無稽之談”与我对指引的理解有相当大的差异，“应”或“应当”从来都是强制性规定，“只是建议”难道不应该是“可以”吗？正如指引所述，“不顧警告，多次張貼版權材料的貢獻者可以由任何管理員加以封禁，以阻止問題進一步產生。如果你懷疑某篇條目侵犯著作權，你至少應該將問題提交到條目的討論頁。其他人可以繼續對情形進行檢查，並在需要時採取行動。你所能提供的最有幫助的內容，是你所認為可能是該文字出處的URL鏈接或其他相關引用。”--Zheng Zhou（留言） 2024年1月16日 (二) 10:01 (UTC)[回复]

「應」或「應當」從來都是強制性規定一說只證明了閣下的中文不好，UjuiUjuMandan所寫的WP:应不应该論述完全足夠說明「應」不是強制性的要求這一點。「內容不能變」不等於內容不構成「抄襲」，因為「內容嚴謹不能變」所以你就可以將大半句複製上去完全就是扭曲規則、強詞奪理。--路西法人 2024年1月16日 (二) 10:10 (UTC)[回复]

承上，侵犯版權是「不可以」，是不論什麼原因都不可以；警告用戶是「應該」但非「必須」，況且如我上面所說方針未曾有要求管理員本人警告用戶，封鎖方針內所有關於警告的論述完全沒有提及過「管理員」三字，即「管理員應該警告用戶」是不存在於維基百科方針內的憑空規定。--路西法人 2024年1月16日 (二) 10:13 (UTC)[回复]

UjuiUjuMandan所寫的WP:应不应该論述，只是闡述方針與指引用詞建議的論述，不是維基百科的核心方針或指引，僅代表部分編者關於社羣規範或維基百科的觀點，尚未得到充分共識。我的中文应该还是过关的，毕竟“应”和“应当”表达强制性规定、“可以”表示授权性规定，这是不争的事实，就连WP:应不应该论述中都写有“如果一個條件是「必須」滿足的，而一筆編輯不滿足該要求，那麼這一筆編輯應該被回退，或者用更好的內容覆蓋”，在此处咬文嚼字岂不是变相说WP:应不应该自相矛盾？我不认为我有“扭曲規則、強詞奪理”，相反“將大半句複製上去”的指控是如此不明确，我还是以徽菜條目中的「中和湯」章節舉例，這是一道知名度較低、但是有嚴格菜譜規定形制和製作方法的菜餚，來源/菜譜寫為「首先要選上好的白豆腐，精心切成米粒大小的豆腐塊」，我轉寫成了「將白豆腐切成米粒大小的豆腐塊」，如果這樣還要算雷同的話，那麼請問怎樣轉寫才能做到「只有重新以自己的語言總結原文思想才不屬於抄襲」呢？其它幾個章節、還有另外被刪除的三個條目其實都是同理，我可以改寫成「將豆腐切成豆腐塊」（如果這樣就不算雷同/抄襲了的話），但是缺乏「米粒大小」的形制要求和「白豆腐」的食材要求，嚴格意義上來說這就不能叫「中和湯」了，那麼請問我是應該寫錯誤、不準確的信息，還是說因為無法做到「只有重新以自己的語言總結原文思想才不屬於抄襲」因此就乾脆不編輯了、這些條目沒有存在的價值和可能了呢？--Zheng Zhou（留言） 2024年1月16日 (二) 10:36 (UTC)[回复]

( π )题外话，“应”与“应当”在法律用语中确实从来都是强制性要求，与“必须”具有相同的含义，只是“必须”听起来语气更加强烈。Zheng Zhou阁下的说法没有问题。只是如果某人不遵守某个“应”或“应当”的要求时，如果规范没有规定相关的处罚和责任（罚则），这只说明相关规范的实行力存在问题，但丝毫不影响其强制性要求的性质。WP:应不应该是没有取得共识的个人论述，更何况里面说的是“应该”而不是“应当”。

民国《著作权法》第64条第1项：依第四十四条至第四十七条、第四十八条之一至第五十条、第五十二条、第五十三条、第五十五条、第五十七条、第五十八条、第六十条至第六十三条规定利用他人著作者，应明示其出处。→难道明示出处只是推荐你这么做？

《中华人民共和国著作权法》第14条第2款：合作作品的著作权由合作作者通过协商一致行使；不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让、许可他人专有使用、出质以外的其他权利，但是所得收益应当合理分配给所有合作作者。→难道我可以不分配？法律只是推荐我分配？--Teetrition（留言） 2024年1月16日 (二) 10:49 (UTC)[回复]

WP:規則只是原則，法律是原則嗎？這裡是維基百科還是法院？原則是「溝通很重要」，而沒說過「管理員必須警告才能封鎖」，不存在的規則更不可能是原則。--路西法人 2024年1月16日 (二) 10:53 (UTC)[回复]

我建議你們還是別討論「應」「須」表達什麼意思的問題。無論是法律上的「應」「可」用法，還是UUM的用法，都不是您維實務用法。實務上「應」和「須」在你維用法很亂。解決不了事情好嗎。--Ghren 🐦🕖 2024年1月16日 (二) 11:18 (UTC)[回复]

此外，我不认为「管理員應該警告用戶」是不存在於維基百科方針內的憑空規定，而是对试图做出积极贡献的编者之最基本的尊重。维基百科的内容想要扩展、又不允许原创研究，编写的过程中肯定伴随着各种各样的“维基化转写”，而什么样的题材、怎样转写构成“雷同”和“抄袭”，不是哪个用户、哪个管理员直接就可以决定的，而是应当充分讨论，讨论、改写、标准引用来源、页面侵权验证、封禁反复添加侵权内容的用户这些都是手段，写出高质量、内容有价值的条目才是目的，我提出 Mys 721tx 不適合擔任管理員，不光是指责他违反了方针指引，更重要的是他的行事、作风体现出他混淆手段和目的。--Zheng Zhou（留言） 2024年1月16日 (二) 10:43 (UTC)[回复]

客觀判斷有文句完全重複就顯然構成侵權，顯然不是需要討論的，更何況已經多個用戶跟你說確實構成侵權，只是閣下堅持拒絕接受。社群歷久以來的侵權侵犯版權的內容更毫無疑問是低質量、會損害維基百科法律利益的內容。--路西法人 2024年1月16日 (二) 11:00 (UTC)[回复]

阁下先前还说原則是「溝通很重要」，现在又说客觀判斷有文句完全重複就顯然構成侵權，顯然不是需要討論的，我实在是看不懂根据阁下的观点沟通讨论到底重要还是不重要。确实截至目前我仍“堅持拒絕接受”对我侵权的指控，但是我欢迎在此话题上继续讨论，无论是我在上述四个条目中的编辑是否构成侵权的话题，还是Mys 721tx是否适合继续担任管理员的话题，我觉得都很值得讨论。我之所以对我被封禁感到不平，正是因为剥夺了我表达观点的权利。--Zheng Zhou（留言） 2024年1月16日 (二) 11:23 (UTC)[回复]

「溝通很重要」，但很多事情都是不需要溝通的。破壞、侵權等既定俗成且有明確標準的判斷顯然是按照標準判斷。溝通是用於不能明確判斷的情況，侵權客觀標準（不是以自己的文字編寫，拿了別人寫的內容，就算改了一些些都顯然仍然是別人寫的內容，這個叫做侵權）已能判定。閣下自己「堅持拒絕接受」指控，所以您就永遠是對的，別人就永遠是錯的，不論多少個人跟您說您這是侵權能仍是堅拒接受，這個何從叫做溝通。--路西法人 2024年1月16日 (二) 11:27 (UTC)[回复]

回退权的使用，由于原条目已经删除了，无法看出是使用了系统的回退权还是工具便利的类回退，不好评价；作为巡查员，对于老旧内容（洪山菜薹）不去复查侵权问题，不妥，但用AGF可以解释，但新条目，明显来源侵权显示编辑时间早于条目创建时间，内容仅仅是做了少许排版编辑，实际上整篇内容几乎是照壶画瓢的，很难不被认为作为巡查员的基本意识是否不适；如果提报全页面侵权的话，提报页可以讨论，如果认为没问题，可以直接草稿页重新编写，或者能明确的肯定不属于严重的全页面侵权的话，可以拿出明确的理由（例如侵权来源量与整页被提报量）来回应，再以此做善意的操作。如果无视侵权提报，又明确的理由直接回退提报，还这样诉诸情感的话，可能难以说服众人吧。当然，我说Mys_721tx确实狠人，以至于这种情况最好给个3级+4级标准的罐头警告再动手可能更好，也就是多点几次鼠标而已，如果侵权提报也算是一种警告的话，那就当我没说过。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月16日 (二) 11:52 (UTC)[回复]

我覺得可以算是，而且能被提報這麼多次也是。--Sun After Rain 2024年1月16日 (二) 13:35 (UTC)[回复]

节选编辑历史：

洪山菜薹：
(差异) 2023-12-31T15:42:21 . . Zheng Zhou（讨论 | 贡献 | 封禁）小 5,865字节（回退Ohtashinichiro（对话）的编辑，改回Zheng Zhou的最后一个版本）标签：回退已被回退消歧义链接

(差异) 2023-12-30T10:38:30 . . Ohtashinichiro（讨论 | 贡献 | 封禁） 344字节（本页面疑似侵犯著作权）标签：TW 替换已被回退移除或更換文件
紅燒木琴魚：
(差异) 2024-01-01T14:00:55 . . Zheng Zhou（讨论 | 贡献 | 封禁）小 1,347字节（回退Ohtashinichiro（对话）的编辑：先搞清楚版权验证的前提条件）标签：回退已被回退

(差异) 2024-01-01T00:20:56 . . Ohtashinichiro（讨论 | 贡献 | 封禁） 390字节（本页面疑似侵犯著作权）标签：TW 已被回退
黃陂三鮮：
(差异) 2024-01-01T14:00:35 . . Zheng Zhou（讨论 | 贡献 | 封禁）小 2,464字节（回退Ohtashinichiro（对话）的编辑：先搞清楚版权验证的前提条件）标签：回退已被回退

(差异) 2024-01-01T00:17:20 . . Ohtashinichiro（讨论 | 贡献 | 封禁） 326字节（本页面疑似侵犯著作权）标签：TW 替换已被回退

-Mys_721tx（留言） 2024年1月16日 (二) 17:22 (UTC)[回复]

被提报之后应该先跟提报人讨论，而不是直接用回退权。即使直接使用撤销功能，也不至于会被除回退员。--桐生ここ★[讨论] 2024年1月18日 (四) 15:50 (UTC)[回复]

我很好奇U:Zheng Zhou为什么还没封禁。这人很明显不是来干正事的。你不可能教会一个不想干正事的人任何正经东西。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年1月16日 (二) 15:25 (UTC)[回复]
何为“正事”？何为“正经东西”？我表达了我的观点，阁下这条留言在反驳金字塔中属于哪一层次呢？--Zheng Zhou（留言） 2024年1月16日 (二) 15:46 (UTC)[回复]
如果Zheng Zhou閣下在上面的前輩們跟您解釋了這麼得多，還是覺得都是別人的錯，這樣下去也很難溝通只是各自表述。另外一點小意見，一直糾結別人應該怎麼樣只是糾結而已，或許換個角度反問自己可以怎麼樣。--Mafalda4144（留言） 2024年1月16日 (二) 17:20 (UTC)[回复]
我没有“覺得都是別人的錯”，如果我有行为或言论不当的地方，当然欢迎指出。我倒是没有觉得我在“糾結別人應該怎麼樣”，因为从我的角度来看滥权确实是存在的，既然影响到了我的权益，论述我的观点也无可厚非吧？在我看来，截至目前本话题下出现的绝大多数论点不存在“各自表述”的问题，比如洪山菜薹条目中的侵权内容是不是我添加的，这就是个事实问题、很容易可以查证（虽然由于条目已被删除现在管理员以外的用户也看不到了），如果确如LuciferianThomas所说是我2017年添加，那我可以承认，无论是他总结的“純屬撒謊或閣下不記得您自己2017年添加了內容”，是我添加的就是我添加的，这事实的部分没问题。但是，关于“应”表示的是强制还是授权，这就不是一个纠结不纠结的问题了，直接决定了本次事件中Mys_721tx有无滥权行为，也决定了方针给了管理员用户多大无监督使用权力的自由度。LuciferianThomas以前辈的姿态引用WP:應不應該的论述，但是他/她明显应该是知道WP:應不應該“只是闡述方針與指引用詞建議的論述，不是維基百科的核心方針或指引，僅代表部分編者關於社羣規範或維基百科的觀點，尚未得到充分共識”的吧？如果我是新手，可能就被吓唬住了。随后WP:應不應該的作者UjuiUjuMandan又写了一条不明不白的留言，诉诸人身的“论述”凭什么要我接受呢？如果讨论问题就是靠引用方针的话，我也可以引用方针，维基百科五大支柱之一就是不墨守成規：

“維基百科制定有方針與指引，但並非板上釘釘不可更改，其內容和解釋可以逐漸發展完善。方針與指引所蘊含的原則和精神比字面措辭更為重要，並且有時為了改善維基百科允許例外的出現。請您大膽但不要輕率地去編輯、移動或修改條目，也不要苦惱無意所犯的過失，因為頁面的每次更改都會被保存，因此所有錯誤都能被輕易的改正。”

忽略所有規則是經社群商議並採納的方针，我做好了被質疑的准备，并在需要說明時提出了我的解釋，也来到了互助客棧討論，如果我的论述有与事实不符、或不合逻辑的地方，我自然会接受，但是只是一味要求我闭嘴，我是不接受的。--Zheng Zhou（留言） 2024年1月17日 (三) 02:07 (UTC)[回复]
洪山菜薹我大致确认从原来重定向页，在2017年由Zheng Zhou添加内容，到2023年再进一步补充调整的内容大致一致，而且从2017年添加的内容已经存在侵权问题，但Zheng Zhou没有尽能力确认到内容存在明显的原版复制侵权或者避免请侵权的改写，姑且从AGF考虑到没心之失；紅燒木琴魚、黃陂三鮮为最近创建，侵权来源显示的编辑时间明显早于条目创建时间，已复核过内容几乎一致（仅部分排版微调）的复制侵权，而且作为巡查员没有尽到能力和职责去核实或者改写内容；基于前因而不合理的回退行为（虽然并不涉及系统级回退的回退权限使用）。讨论页上删除侵权提报提醒，可能暗示其轻视其他用户的提醒。所以Mys_721tx可能基于此直接上重手的考虑。但我也认为这样的做法也太激进了，至少上一份L3以上的罐头通告（或者手工打造的提醒）作为封禁前的提醒更好。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月17日 (三) 02:28 (UTC)[回复]

我可以告訴您，根據經驗法則，「應」絕對不可能是強制性的，要舉例隔壁LTA的封鎖隨便找一個看都是，請不要玩文字遊戲。當然非常歡迎您要求修訂方針來明確用詞。--Sun After Rain 2024年1月18日 (四) 05:29 (UTC)[回复]
从AGF的角度，假定他不知道这所谓「经验法则」我不认为有啥问题就是。他又没太多「经验」。--Ghren 🐦🕐 2024年1月18日 (四) 05:47 (UTC)[回复]

从中维的惯例来说，不是强制性的。从现实世界的常识来说，是强制性的。--桐生ここ★[讨论] 2024年1月18日 (四) 15:45 (UTC)[回复]

@Zheng Zhou：参考User:AT/給認為自己是受害者的人--Allervous 初音ミクのセーラー服 2024年1月18日 (四) 14:31 (UTC)[回复]
“紅燒木琴魚与黃陂三鮮条目为本人创建，由于维基百科不允许原创研究，自然需要引用外部链接中的内容，本人已对语句进行维基化转写、并按照标准格式添加了引用来源；”这段话都看不出这人该封禁吗？他以不学为理由支撑自己的无术。该问的不问，不该讲的乱讲。这都不封禁留着过年吗？ --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年1月18日 (四) 06:38 (UTC)[回复]
@UjuiUjuMandan 阁下如果提不出任何有价值的反驳，其实还是不要留言了比较好。阁下应当庆幸自己不是管理员，因为“以封禁相威脅”已达到管理员的解任条件。--Zheng Zhou（留言） 2024年1月18日 (四) 08:28 (UTC)[回复]
没跟你说话。请停止扰乱。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年1月18日 (四) 09:00 (UTC)[回复]
Just a reminder, 維基百科最忠誠的反對者（讨论 | 貢獻） -‎Lemonaka‎ 2024年1月19日 (五) 07:03 (UTC)[回复]
( π )题外话 @LuciferianThomas @UjuiUjuMandan

牛肉炒豆丝 Original Research.

豆米漿從石磨里流出來後，架大鐵鍋燒灶，火旺後舀一瓢漿在鍋里，向四周抹開去、攤勻，蓋上鍋蓋兩分鐘後，一張豆絲麵皮就熟了。雙手揭起，放在米篩上，置涼後，切絲，豆絲就做好了。現代經過創新加工工藝，豆絲已經可以全年加工。

干煸藕絲 Unreferenced, notability issues.
武汉长江航运中心 Suspected copyvio.
鸡冠餃 Original Research

詩中的油餃，也許指的就是雞冠餃。雞冠餃的餡料不固定，但一般以少量肉末和蔥為主，也有加入粉絲的做法。傳統雞冠餃的麵團使用老面發酵而不使用酵母。

-‎Lemonaka‎ 2024年1月19日 (五) 07:21 (UTC)[回复]

鸡冠饺那段看起来是原创研究，已删除。另外，退一步说即使是有来源这么说，也不应该采纳。这种靠古诗来附会食物起源的做法本身就很混账。正常的维基人不能仗着不读书就拿混账来源来敷衍读者。另外条目所引用唯一的来源是内容农场来源。当然了我没兴趣向这位不干正事的“维基人”解释什么是内容农场。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年1月19日 (五) 09:40 (UTC)[回复]

牛肉炒豆丝条目质量显然有问题，不过你所引用的那段到底对不对还要看是否符合事实。如果仅是没有来源可以核实的话，那就违背Wikipedia:可供查證，而不是Wikipedia:非原创研究。条目内容写得差很多时候都不需要诉诸非原创研究，写得差就是写得差。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年1月19日 (五) 09:42 (UTC)[回复]

建议提报人去维基教科书完善b:食谱，但请注意Wikipedia:Close paraphrasing（英语：Wikipedia:Close paraphrasing）的问题，用自己的话概括--及时雨 ^留言 2024年1月19日 (五) 10:52 (UTC)[回复]

我認為提請人應該要留意維基百科是百科全書這點。San mo sa _{Miyamoto Miyoko} 2024年1月20日 (六) 14:26 (UTC)[回复]

我认为即使提醒了也没用。他又不是最近两年才来维基百科的。如果他能够意识到条目唯一的用处是给人读，他几年前就该知道了。他现在这个样子，条目写得非常烂，但是在WP空间又能仗着不读条目而口若悬河，我不相信他是个能被拯救的维基人。早封禁早好。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年1月22日 (一) 03:10 (UTC)[回复]

那個、這是@Zheng Zhou閣下先前的回應Special:Diff/80573557，如果沒誤解的話，這是否能當作是有共識而能關閉討論呢？--Mafalda4144（留言） 2024年1月22日 (一) 08:11 (UTC)[回复]

虽然我不认为他会有充分的改善，但至少关闭这个话题也是好的。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年1月22日 (一) 15:15 (UTC)[回复]

经本人讨论页与互助客栈的讨论与沟通，我陈述下我的看法：1. 我仍然认为 Mys 721tx 不適合擔任管理員，但这仅仅是我的“看法”而已，如果社群没有形成“Mys 721tx 不適合擔任管理員”的共识，我会遵守方针、不会于 Mys 721tx 上次解任投票满6个月后发起解任投票（至于我仍然认为 Mys 721tx 不適合擔任管理員的原因，属题外话，与本次提报列举的原因既有重合的部分、也有不重合的部分，在此不展开了）；2. 讨论过程中，部分编辑向我发送了许多我参与编辑维基百科11年以来没有阅读过的论述，让我很有收获，虽然我仍然认为核心问题即「以何种程度之自己的語言重新總結原文思想才不屬於抄襲」缺乏可以量化的标准、不甚理想，但我可以承认本次因被提报侵权而遭到删除的几个条目未达到可以被保留的质量，其被删除的结果我接受，我希望我能在未来按照社群可以接受的方式重写；3. 我会要求修訂方針來明確“可以”与“应当”用詞，因为这直接决定了我本次被封禁是否属于不合理封禁，且如前述讨论，当前方针用词在中文维基百科的「經驗法則」与現實世界的常識不符，我虽仍不认为我先前的编辑行为达到了需要被无警告除权封禁的程度、但也不再认为 Mys 721tx 本次对我除权封禁的操作属于管理员滥权；4. 不吐不快：本话题中我与多位编辑发生过争辩，我尊重并感谢他们向我表述他们的观点，如我语气不好、观点偏激，我向您致以诚挚歉意。但是，唯独 UjuiUjuMandan 的言行让我感到严重不适，在此之前我无论在维基百科还是在现实生活中都从未被说过“條目寫得非常爛”、“不學無術”、“不干正事”、“混賬”、“不讀書”，而他的WP:應不應該论述中却甚至存在如果一個條件是「必須」滿足的，而一筆編輯不滿足該要求，那麼這一筆編輯應該（？）被回退，或者用更好的內容覆蓋这样明显不合逻辑的表述（他的时间很宝贵，也“沒興趣向（我）這位不干正事的‘維基人’解釋什麼是內容農場”，但是一个写出的论述把“应”、“应该”、“应当”全部混用，又搞出用“应该”去定义“必须”这种羅素悖論的人，倒真是挺能“口若懸河”的）。--Zheng Zhou（留言） 2024年1月22日 (一) 16:49 (UTC)[回复]

@Zheng Zhou閣下，再次打擾，雖然我在這裡的資歷說來才兩年多也就是說才兩歲多（等等），這段時間有些衝突，多少都有學習到受教了，某些時候某些話看來真的很苦三觀倒地打滾，但我現在也可以體會到，大家應該都是覺得這些話是可以說出來的，才會送出，畢竟在這裡，任何一個字都會留下記錄的對吧，所以呢，不要往心裡去，看完了就放下吧，我要AD泰勒·斯威夫特的半自傳半紀錄片的電影《美國小姐》，中間提到她消失一整年以及重新解構自己的歷程，如果您有興趣可以來去看看，或許能給您一些不一樣的找到力量前進的動力。--Mafalda4144（留言） 2024年1月23日 (二) 03:27 (UTC)[回复]

好的。--Zheng Zhou（留言） 2024年1月23日 (二) 03:32 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

将赌博列为高风险主题

赌博类内容历来属于垃圾链接重灾区（莊荷、香港丁組足球聯賽隊伍、以色列足球協會）。近日多个用户在足球条目中散布赌球网站链接。请求将广义的赌博定为高风险主题以准许管理员进行与WP:CTOP/SEO和WP:CTOP/CRYPTO类似措施。--Mys_721tx（留言） 2024年1月20日 (六) 07:46 (UTC)[回复]

(＋)支持：近期本人亦回退了不少赌博主题相关的破坏。—さき　せかいSaki Sekai（讨论｜贡献） 2024年1月20日 (六) 08:42 (UTC)[回复]

需要多廣義？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月20日 (六) 13:10 (UTC)[回复]

感覺他說的話的意思應該是包含被用於（涉及金錢的）賭博的競猜對象。比如賭球會涉及球賽，該球賽與參與該球賽的隊伍都包含在內。San mo sa _{Miyamoto Miyoko} 2024年1月20日 (六) 14:23 (UTC)[回复]

是的。--Mys_721tx（留言） 2024年1月20日 (六) 19:26 (UTC)[回复]

总统竞猜赌庄……--Milky Defer 2024年1月21日 (日) 03:50 (UTC)[回复]

如果连着几个月不断加入垃圾链接的话应当没有问题。--Mys_721tx（留言） 2024年1月21日 (日) 04:07 (UTC)[回复]

擔心範圍太廣，反而難以兼顧。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月21日 (日) 06:04 (UTC)[回复]

也太廣義了。「香港丁組足球聯賽」都已經停辦了，還能有人拿出來開賭盤的嗎？--Ghren 🐦🕒 2024年1月21日 (日) 07:11 (UTC)[回复]

spammer按照关键词匹配的时候（Special:Contributions/Brothererror）不会管是否停办。--Mys_721tx（留言） 2024年1月21日 (日) 07:26 (UTC)[回复]

範圍太廣，難以執行。這種已停辦的項目也看不出持續散布垃圾連結的風險。--Ghren 🐦🕓 2024年1月21日 (日) 09:02 (UTC)[回复]

(＋)支持确实挺多破坏的。 --Winzekter986（留言） 2024年1月22日 (一) 10:42 (UTC)[回复]

(＆)建議要保護跟賭博有關的條目那得保護到啥時候···不如反向追查破壞者，而且這批次的破壞好像也沒達到編輯戰的程度--Mylittleairpod（留言） 2024年1月24日 (三) 06:35 (UTC)[回复]

(＋)傾向支持，符合高风险主题的定义，“在中文维基百科遭受较本站其他部分更频密的扰乱性编辑（尤为破坏及编辑战）”。在赌博类条目（赌球、赌场）上常年不时有人插入垃圾链接，比如賭場 (Special:Diff/78742086/79811671)--Kethyga（留言） 2024年1月26日 (五) 00:45 (UTC)[回复]

(＋)支持網絡賭博條目最近一次編輯中，似乎也被加入了垃圾鏈。--Zheng Zhou（留言） 2024年1月28日 (日) 19:07 (UTC)[回复]

第一百四十万条目

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:宣告。

目前Special:统计显示条目数为1400003，在Special:最新页面中倒推，可能是贝内德托·维尼亚或者彼得·普羅德羅姆或者德巴利酵母菌科，但由于移动日志中天理拉面也在北京时间22点38分发生移动，请管理员考证一下真正的第一百四十万篇条目是哪一个--Forza Ferrari --Tifosi 2024年1月21日 (日) 14:44 (UTC) 据初步考证，这段时间内没有发生条目删除，按照oldid排序依次为[回复]

第1400007条 [4]
第1400006条 [5]
第1400005条 [6]
第1400004条 [7]
第1400003条 [8]
第1400002条 [9]
第1400001条 [10]
第1400000条 [11]
第1399999条 [12]
第1399998条 [13]
以上，请管理员复查Forza Ferrari --Tifosi 2024年1月21日 (日) 15:01 (UTC)[回复]
附知相关条目创建者@高晶：@№.N ：@RecoveryRing：--Forza Ferrari --Tifosi 2024年1月21日 (日) 15:03 (UTC)[回复]
大概和我没关系。就发布了一个草稿，不至于卡这么准吧……--Adya Talk 2024年1月21日 (日) 23:15 (UTC)[回复]

不用這麼麻煩吧，是要每十萬條目都做一個宣告才甘願？況且完全沒聽到有人討論要用第140萬條目的特別標誌，怎麼不等到比如第200萬條目再講這個？「宣告」完全就不是讀者會在乎的東西，維基百科真的沒有進步，純粹的還活在「條目寫給自己爽的」時代。也不先問看看「過去30天的頁面瀏覽量」連4位數都不到的東西（1月22日瀏覽量580；1月23日瀏覽量656），是寫給誰看？只有聽過100萬條目專頁，其餘的完全沒聽過，真的建議等200萬再講吧，那時都不知道還在不在了，可能都不在維基百科了。還有，因為維基百科的條目已經足夠多了，如果不想寫新的其實也沒差。如果不是時事新聞夠多，關注度足夠的話，中文維基百科也不可能往200萬邁進，麻煩以後別還繼續活在「條目寫給自己爽的」時代了。--Z7504非常建議必要時多關注評選（留言） 2024年1月22日 (一) 06:34 (UTC)[回复]
英文维基百科都六百多万了，甚至很多典范条目都没有中文翻译，所以提升空间还是很大的--Forza Ferrari --Tifosi 2024年1月25日 (四) 01:59 (UTC)[回复]
en是en，再說en的條目也不是每一樣都真的適合翻譯過來zh，這裡可以參考已經退休的管理員Antigng之論述。還有翻譯過來zh就有中文譯名不一的問題，但en就沒有所謂中文譯名不一這問題。如果真的想進步，重申一次別繼續活在「條目寫給自己爽的」時代了。怎麼不先問問協作計劃和每週翻譯這兩大「蚊子館」？這已經證明維基百科的條目已經足夠多了，不想寫新的條目是真的沒差。--Z7504非常建議必要時多關注評選（留言） 2024年1月25日 (四) 03:47 (UTC)[回复]

界面文字错别字

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:联络我们/捐赠者。

Wikipedia_talk:联络我们/捐赠者里面的链接“如果您希望向维基百科捐款，请造访这里。”[14]的界面文字写的是

占米·威爾士維基百科創始人

说离谱吧，其实也没那么离谱，占米--Forza Ferrari --Tifosi 2024年1月22日 (一) 03:15 (UTC)[回复]

单纯人名的不同翻译罢了，吉米詹米占米任你叫。--Milky Defer 2024年1月22日 (一) 03:28 (UTC)[回复]

应该可以该，donate.wikimedia.org的网页内容，zh-hant的是占米·威爾士，zh-hans的是吉米·威尔士，不存在zh-cn、zh-tw、zh-hk…。Wikipedia:联络我们/捐赠者可以考虑根据用户的中文变体跳转，目前的使用的zh只是跳转到zh-hant对应的网页，按照中文变体跳转，简体用户可以跳转到简体的页面。--Kethyga（留言） 2024年1月22日 (一) 04:35 (UTC)[回复]

(＋)支持。WP:联络我们/捐赠者里的链接确实应该根据简繁指向不同uselang。--PexEric 💬|📝 2024年1月22日 (一) 14:41 (UTC)[回复]

另说明下，维基百科左侧边栏的“资助维基百科”在zh-cn变体下点击会直接跳转到zh-hans文本下。--Kethyga（留言） 2024年1月23日 (二) 13:41 (UTC)[回复]

已解决，存档吧--Forza Ferrari --Tifosi 2024年1月22日 (一) 04:49 (UTC)[回复]

我更好奇原始介面位置在哪裡？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月24日 (三) 05:58 (UTC)[回复]

见 Template:Appeal/default--Kethyga（留言） 2024年1月24日 (三) 11:29 (UTC)[回复]

提议修改过滤器233的警告内容

过滤器233的警告当前如下所示。

警告：您的编辑行为已被自动过滤器认为具有潜在的危害而被禁止。根据Wikipedia:投票/跨语言链接的處理方式形成的共识，不应在条目中以跨语言链接“[[:語言代碼:條目名稱|顯示內容]]”（如[[:en:Article Name|條目名稱]]）等方式，直接将内容连結至其他语言维基百科。

在非过度内链的情况下，对于不为中文用户熟知的外来词汇，编辑可以使用跨语言链接模板{{ilh}}和{{tsl}}标注外语维基的对应条目。两个模板使用方式为{{link-en|條目名稱|Article Name|顯示文字}}和{{tsl|en|Article Name|條目名稱|顯示文字}}，其中“en”表示英语，可以换为其它语言代码；而顯示文字為選用參數，不填會顯示條目名稱；條目名稱也是選用參數，不填則使用Article Name。该模板允许用户通过小工具自定义跨语言链接的表示方式。同时，编辑还可以选择在红色链接后面用括号直接附注原文——即“條目名稱（Article Name）”——来避开跨语言链接。

如果您认为這個報告有誤，请向我们报告此错误。祝編安！

这有几个问题。首先，不要写「具有潜在的危害」，这真的没什么特别的危害。之后，第二段的说明文字太长了会被tldr的。最后，这个警告只有原始码模式下的操作方式，对于可视化编辑没有任何可操作性。新人不论是用内容翻译还是开始编辑都是首选可视化，这个提示除了折磨新手，没有任何帮助。

这是我提议的版本。

警告：您的编辑行为已被自动过滤器阻止。您的编辑中含有一处或多处形如「[[:en:Foo|Foo]]」的内容，而社群同意不应当使用这种方式填写从中文维基百科直接将内容连結至其他语言维基百科的跨语言链接。

您可以使用模版{{ilh}}或{{tsl}}标注外语维基的对应条目，即将编辑中所有的「[[:語言代碼:目標條目|顯示文字]]」文字样式修改为「{{link-語言代碼|中文條目名稱|對應語言版本條目名稱|顯示文字（選填）}}」或「{{tsl|語言代碼|對應語言版本條目名稱|中文條目名稱|顯示文字（選填）}}」。如果您使用了可视化编辑器，您可以直接取消该跨语言链接，或者使用红色链接并在后面用括号直接附注原文的方式——「中文條目名稱（原文名稱）」——作为替代。

如果您认为這個報告有誤，请向我们报告此错误。

--Milky Defer 2024年1月22日 (一) 07:10 (UTC)[回复]

(＋)贊成--YF dyh000（留言） 2024年1月22日 (一) 11:00 (UTC)[回复]

這都多久了，居然還沒進步啊......怎麼還活在:en:這個系列......維基百科如果不想進步只想擺爛的話，還倒不如不要討論的好。--Z7504非常建議必要時多關注評選（留言） 2024年1月22日 (一) 11:47 (UTC)[回复]

我懷疑您根本沒讀過提案人說了什麼。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月23日 (二) 08:36 (UTC)[回复]

維基百科如果不想進步就不想進步，不要在那逞強，這真的不是一個管理員該說出的話。誰還在跟您:en:，不是老早就在用{{link-en}}或{{lang-en}}了嗎？這種發神經的討論，不討論真的也罷。再說了，用{{link-en}}或{{lang-en}}編輯的用戶，是完全不可能用到這個過濾器的。--Z7504非常建議必要時多關注評選（留言） 2024年1月24日 (三) 14:34 (UTC)[回复]

中文维基百科被抨击对新手极其排斥肯定有你一份功劳。--Milky Defer 2024年1月25日 (四) 12:12 (UTC)[回复]

您真的看懂了吗？这是提示误用:en:新手的过滤器，而不是提示老手的过滤器。--桐生ここ★[讨论] 2024年1月25日 (四) 13:22 (UTC)[回复]

誰管你們看不看得懂，老早在用link或lang的東西就沒有跟你們廢話之必要。中文維基百科被抨擊只是活該剛好而已，因為中文維基百科對新手就一點都不友善（還說什麼不要傷害新手），討論這個究竟有何屁用？--Z7504非常建議必要時多關注評選（留言） 2024年1月25日 (四) 14:26 (UTC)[回复]

现在肯定还有没清理掉的跨维基语言链接，新手可能会在复制粘贴的时候触发过滤器，可能会在条目中看见这种过时的写法然后运用到其它条目。跨语言用:en:是默认的做法，在其他维基比如Fandom上的维基也会用到，维基百科有特殊要求应该告知。 ——魔琴 [ 留言贡献新手2023计划 ] 2024年1月25日 (四) 14:32 (UTC)[回复]

為什麼一個Interwiki需要被你罵成這樣啊。（題外話，ilh系列模板其實也是Interwiki的包裝層）--Sun After Rain 2024年1月30日 (二) 02:24 (UTC)[回复]

保留{{ilh}}和{{tsl}}两套的说明。（严格来说先有ilh，再有tls，tls是ilh的套皮）——Sakamotosan路过围观 | 避免做作，免敬 2024年1月23日 (二) 03:32 (UTC)[回复]

調整修訂草案內容。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月23日 (二) 08:33 (UTC)[回复]

(＋)贊成。--桐生ここ★[讨论] 2024年1月25日 (四) 13:20 (UTC)[回复]

是否只要沒參考資料就可以馬上移除?

Mafalda4144大量使用WP:V為理由，刪去一切沒有參考資料的內容：

special:diff/80518803：但事實上沿著上面的S31、S32、S33連到維基學院可知S34、S35確實有通往第二殯儀館
special:diff/80537118：內容提及輔大於1925年在北京建校，2025是百年校慶，應用常理可推斷
special:diff/80587860：把內容丟到google方可輕易查證[15]
special:diff/80551180：把內容丟到google方可輕易查證[16]
special:diff/80587840：搞到變成編輯戰，但把內容丟到google方可輕易查證[17]
special:diff/80575831、special:diff/80575877：沒附來源，請管理員不要糾結，叫他去處理其它版務。但是File:Concourse_of_THSR_Taichung_Station_01.jpg可知台鐵絕非只能是台鐵局之簡稱
special:diff/80401451：先以WP:V為由移除，但是但點入蓬萊島雜誌案，就可發現大量來源，之後special:diff/80589284發現補上來源後，再以「新聞農場內容」為由刪除，個人認為這筆爭議最大

誠然，編輯者應承擔舉證的責任，但有時編輯者疏忽而沒附上參考資料，但是參考資料又一google，就可查證時，是否只要沒參考資料就可以馬上移除?

況且WP:V裡提及「在删除前应给予加入此内容的编者充足的时间来补充来源，否则可能导致他们的不满。如果想要求为一句无来源的陈述补充来源，可以考虑将其移动至讨论页，或用{{来源请求}}将文字标出，或选用{{缺乏来源}}、{{改善来源}}等模板挂於条目中。同时亦可使用“”格式将文字变成读者不可见的注释，并於讨论页中说明，以便他人了解您的编辑。」Mafalda4144基本上都沒給人時間處理，直接刪除，是否太過激進？--2001:B011:8007:1C65:5925:2FFF:8F66:54F6（留言） 2024年1月23日 (二) 03:35 (UTC)[回复]

為什麼不登入編輯呢？--Mafalda4144（留言） 2024年1月23日 (二) 03:45 (UTC)[回复]

為什麼要登入編輯呢？--2001:B011:8007:1C65:5925:2FFF:8F66:54F6（留言） 2024年1月23日 (二) 03:50 (UTC)[回复]

IP閣下有看到WP:BURDEN裡吉米·威爾斯先生說的話嗎？這些都是常理推斷，但就是沒附上來源。

就EMU800的狀況下，我在自己的討論頁有回應了Special:Diff/80604609，第一時間我也有去找來源，事實上就是沒有，一開始就是鐵道迷自己目擊到然後急著更新，身為資深編輯自己不處理反而站在認同IP的行為，這我實在無法認同。

然後東海大學的那個，和人家學校的校史到底有什麼關係？--Mafalda4144（留言） 2024年1月23日 (二) 03:51 (UTC)[回复]

喔第一個公車那個，這樣太地域中心了吧。舉證是參與編輯者的責任，要編輯又不附上來源是哪招？把這段話放上來了就好好的附上來源很難嗎？不要便宜行事。那既然閣下都能找到來源，為什麼一開始都不附上呢？

( π )题外话我也可以不回應，很多編輯不把IP當活人的，我現在也經常覺得IP編輯是誰沒登入這樣。--Mafalda4144（留言） 2024年1月23日 (二) 04:03 (UTC)[回复]

如同我上面附的，很多都能輕而易舉的找到資料，如果你沒時間，那是不是可以依你最愛的WP:V先掛個模版之類的，畢竟以上幾乎沒損及在世人物或團體的聲譽。公車的你以WP:V為由刪除，而非地域中心，東海大學是以「新聞農場內容」為由刪除，跟現在的說法也不同，我認為在大篇幅移除內容的情況下，應要謹慎說明，這會引起爭議。再者東海大學也可考慮按國立臺灣大學#相關事件的寫法，設立新的章節。然後公車又不是我編的，我當然沒辦法一開始就附上。--2001:B011:8007:1C65:5925:2FFF:8F66:54F6（留言） 2024年1月23日 (二) 04:14 (UTC)[回复]

插一句，我们有称呼一些网站为内容农场并有所针对，但有“新闻农场内容”并有所针对的说法？或者说Wikipedia:可靠来源/常见有争议来源列表有针对雅虎新闻这种新闻汇聚平台有负面的评价？如果非要评价的话，这个来源定位和百家号等内容供稿平台类似，如果其稿来源是已知的传统报道媒体来源的话，应该以其原始来源作为判断点？——Sakamotosan路过围观 | 避免做作，免敬 2024年1月23日 (二) 08:55 (UTC)[回复]

針對Cwek的回饋，(！)意見使用對應內容應該註明原始出處，沒有註明原始出處或將原始出處註明成內容農場等單位，這樣的來源寧願沒有。

針對發文topic的標題，摘錄自WP:生者傳記的模板文字必須遵守維基百科生者傳記方針。缺乏來源或來源不可靠的負面內容必須立即移除。--Rastinition（留言） 2024年1月23日 (二) 09:57 (UTC)[回复]

看来你理解错了，我的意思是我们有“新闻农场内容”的说法，并且有针对这种问题的处理？对于像雅虎新闻这类新闻汇聚平台，日常使用有大量使用（Special:链接搜索?target=https%3A%2F%2Ftw.news.yahoo.com）作为替代更原始的来源（可能采编自原始来源，来源有见过中天新聞網、Newtalk新聞、路透社等）（虽然翻阅过，雅虎新闻也有部分自己原生的原始新闻），这样的看法是不是可以类比有传统新闻媒体认证的类发布平台（像百家号、微信公众号等类似的）的判断意见，或者可以等价于其传统新闻媒体的原始来源？——Sakamotosan路过围观 | 避免做作，免敬 2024年1月23日 (二) 10:15 (UTC)[回复]

(！)意見大致理解現在不提及或主要文字提及對象不是內容農場--Rastinition（留言） 2024年1月23日 (二) 10:31 (UTC)[回复]

主要是针对（special:diff/80589284）的看法，来源看上去没问题，但用“新闻农场内容”来搪塞是不是有问题？——Sakamotosan路过围观 | 避免做作，免敬 2024年1月23日 (二) 11:55 (UTC)[回复]

这个有保留的，（special:diff/80537118），如果创校时间已知的话，是可以计算出不同周年庆祝的时间的，就像1+1=2的算式还需要脚注证明就是滥用规则。但考虑到创校时间相关条目没有明确的脚注彰显，而且有点水晶球了，所以持保留意见。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月23日 (二) 11:58 (UTC)[回复]

我判斷我會離題所以不額外展開，只留下一個水晶球相關思想實驗的( π )题外话，假設創校時間已知，是否有可能有人員會嘗試敘述在X年紀錄X+10n+7年是Y校的P週年，X+5n+2年是K校的U週年紀念--Rastinition（留言） 2024年1月23日 (二) 12:07 (UTC)[回复]

@Cwek閣下，我之前本來有想要提出討論，建議社群應該禁用如Yahoo，MSN，台灣好新聞等大量轉貼新聞的平台來源，舉例如台灣的PTT平台，已經禁止發表新聞的文章，直接引用非原始新聞來源，這些平台為了廣告流量，大量轉載各地新聞，造成搜尋頭幾項都是他們，真正原始報導的新聞社來源會被擠到很後面，題外話直接貼Yahoo轉貼的新聞網址，沒有發現都落落長嗎，舉證的責任之下，不是應該要找出真正的原始報導嗎？順帶一提，這些新聞農場，收集過來新聞後就不會去管原始報導有沒有勘誤的地方了。--Mafalda4144（留言） 2024年1月23日 (二) 13:05 (UTC)[回复]

从搜寻效率来说倾向不禁用Yahoo等部分聚合来源，另外有时原始报道会难以找到或失效，我觉得总比没有来源强，至少有材料来评估来源内容和可靠性，类似给纸质来源提供线上转载。被转载的新闻媒体的报道，倾向算个及格分，原始出处的可靠性有疑问除外，但应给出具体理由。--YF dyh000（留言） 2024年1月23日 (二) 14:19 (UTC)[回复]

同意YFdyh000，有些新聞在Yahoo、MSN等平台上活得比較久。--迴廊彼端（留言） 2024年1月23日 (二) 14:40 (UTC)[回复]

個人讚同迴廊彼端君的看法，舉個例子輔仁大學序言裡佐證「是臺灣及華語圈唯一直屬教廷教育部的天主教大學」，目前唯一能在網路搜尋到的來源只有Yahoo平台，原始的中央社來源已經找不到了。--Kenny023（留言） 2024年1月23日 (二) 15:40 (UTC)[回复]

PTT只有八卦版禁止，別造謠，而且PTT是分享情報（文章）的平台，又不是百科全書。這討論串所提到的Yahoo來源（Newtalk上的文章）是記者劉福全在Newtalk發的政治新聞，新聞農場的依據在哪？還是就跟我之前說的一樣，「不只抗拒紙本來源，來源內容只要他不喜歡就不該使用，來源標題如果他不喜歡也不能使用」。如Cwek所言，Yahoo也有自產的新聞，如[18]。立場新聞、香港01、法廣、明報等等網站的文章來源都很長，來源網址很長所以呢？是想表達什麼？--寒吉（留言） 2024年1月23日 (二) 15:04 (UTC)[回复]

請就事論事。回到東海大學的內容，明顯和校史沒有關係，就算有來源移除也是合理的，硬要放進校史內是何故？

另外關於Yahoo或MSN平台轉了新聞，如果發現了是轉新聞，不是應該要盡量去找出原始來源呢？而不是沒有再確認就直接用轉新聞的平台內容。--Mafalda4144（留言） 2024年1月23日 (二) 15:11 (UTC)[回复]

你一開始先說沒來源，補上來源，又說是「農場新聞」，被質疑後才改說是「和校史沒有關係」。你不斷改理由，根本是避重就輕。和校史有沒有關係(事實上蓬萊島就是指東海被黨國把持，後來導致多人入獄，真的沒關?)，該不該刪，不是你一人決定的，你可以另開個討論，而不是隨意塘塞，找藉口刪除。--2001:B011:8007:3EEC:59A9:7585:D705:16D0（留言） 2024年1月24日 (三) 02:21 (UTC)[回复]

輔大的條目你可以用其他理由移除，但也不該用未見來源刪除，你長期濫用WP:V，根本把WP:V當作護身符--2001:B011:8007:3EEC:59A9:7585:D705:16D0（留言） 2024年1月24日 (三) 02:27 (UTC)[回复]

這位未登入的IP，我已經說了，以後編輯摘要會好好寫。也請您記得，提供來源是編輯的責任，以後記得附上來源，謝謝您。--Mafalda4144（留言） 2024年1月24日 (三) 12:50 (UTC)[回复]

( π )题外话@寒吉君，請您不要繼續發表和我無關的評論，您對我有什麼偏見感想，請您去別的地方說，您自己無視某些迷的無來源編輯行為，也請您正視，謝謝。--Mafalda4144（留言） 2024年1月23日 (二) 15:15 (UTC)[回复]

上面那個回覆我根本沒有發表無關評論，看來是我說出實話才讓你急跳腳吧，你根本沒想要正面回答Newtalk那篇是新聞農場的依據在哪。你在80589284又不是說與校史無關，現在改口要幹嘛，就是要叫你解釋新聞農場在哪。Cwek說「用「新聞農場內容」來搪塞是不是有問題」，YFdyh000說「原始出處的可靠性有疑問除外，但應給出具體理由」，所以你的理由在哪？不要只會選擇性回答。

維基百科並沒禁止使用新聞轉發平台，不要自行幻想。

呵呵，有編輯計畫、時程的人無法處理其他人的無來源編輯原來能叫做無視喔，而我看無視的人是你吧，那時討論串給你多少來源，結果你根本不理會，還發一篇造謠的討論串，你是不是沒有羞恥心？臉皮是不是很厚？--寒吉（留言） 2024年1月23日 (二) 15:33 (UTC)[回复]

( π )题外话寒吉君，您和Mafalda4144君的意見分歧，在討論中就事論事，希望您們不要有互相人身攻擊的言辭，謝謝您。--Kenny023（留言） 2024年1月23日 (二) 15:58 (UTC)[回复]

@寒吉閣下請您停止人身攻擊。

我有回答了，說不清楚嗎那就再說一次。新頭殼的來源確實是包裹在yahoo新聞的來源，yahoo新聞是收集新聞的新聞農場，即使維基百科沒有禁用，我也會盡量避免使用，一定會去找出原始來源，這已經是題外話，之後要討論再說。回到蓬萊島雜誌的這個內容，就算他今天是找新頭殼的來源，明顯和東海大學的校史沒有關係，WP:SYN情況下合理可以移除，我沒有寫清楚編輯摘要確實是我不好，以後會注意。

( π )题外话這些個使用者持續在籃球相關條目進行無來源的編輯，但您一點也沒有想要提醒他們，這些條目您目前為止都持續巡查，現在也還是讓他們持續這樣的行為，不是嗎？那請問您您都找得到來源，為什麼不補上？--Mafalda4144（留言） 2024年1月23日 (二) 16:00 (UTC)[回复]

我已經讓Basketball top5這網站在中維列為黑名單，Basketball top5才叫新聞農場好嗎，yahoo新聞不是新聞農場，你對新聞農場是不是理解有問題。

欲加之罪，何患無辭。首先，我老早就提醒過，我還提醒、教過他不要張貼有版權的文字、模板如何替換引用等等，但他聽不進去，根本不是我的問題。「這些條目」是哪些，甚至是我「巡查」什麼，而且我沒有擁有條目，哪來的「讓」。我找得到來源，為什麼我要補上，列來源也是需要花費成本時間的，而且列來源也不是隨便在沒來源段落尾巴丟下來源就跑，還要比對條目內文與來源內文有沒有吻合，該來源是不是真的能佐證欲佐證的條目內文，你又沒有這習慣（1、2）當然不會覺得列來源需要花費成本時間，而且找來源也要花時間，像79752245我找給你看的來源[19]我就花半個小時從Wayback Machine裡找。最後我就講一次，佳峰是個抄襲仔，他不會改寫句子，他寫進中維的文字是用抄的，然後他沒附上來源，結果你卻說那些文字沒有來源，是無來源所以要刪除，你看的出來你的邏輯哪裡有問題嗎？喔對，還有WP:SYN根本不是這樣亂套用。--寒吉（留言） 2024年1月23日 (二) 17:05 (UTC)[回复]

雅虎新聞大多數只是聚集、轉載其他新聞媒體文章，來源可靠度以原始來源為準即可。若雅虎本身自己也有寫新聞，那麼他們的新聞則獨立按照可靠來源標準評定是否適合使用即可。--路西法人 2024年1月24日 (三) 06:05 (UTC)[回复]

提議設立優良列表評選

提議設立優良列表評選，理由是列表目前必須達到WP:特色內容級別才能參與評選，但要撰寫WP:特色內容所需要花費的時間與精力遠高於優良內容，許多維基人——包括我——都未能有如此多的時間翻找資料、編修出WP:特色內容，而列表又沒有優良內容標準，導致列表的編寫必須一次達到WP:特色內容級別，難度頗高。那麼這些不管是能力還不太夠或者時間上不允許的維基人，編寫的列表不就被拒於評選之門外了？我認為這並不是很妥當。為了讓這些不管是能力還不太夠或者時間上不允許的維基人編寫的列表條目也有機會成為優秀內容，因此提議設立優良列表評選，有以下方案：

建立一個新的評選流程，名為優良列表評選。
使用現有優良條目評選流程，允許WP:獨立列表提名WP:優良條目評選，若評選通過後，將其標記並評級為「優良列表」級，與「優良條目」區隔。

技術上，維基數據也支援「優良列表」級的標記d:Q51759403，先前評級系統整合與同步一案也支援了「優良列表」級的評級，因此技術上完全沒有問題。現就需在制度上尋求共識。

以我個人認為的「優良列表」候選——正多面體列表——來看：

文筆還未能達到WP:特色內容；
序言不夠引人入勝；
部分內容現階段無法或難以提供關於該項目的有用和適當資料的註釋，只能列圖；
視覺吸引力仍嫌不足。

因此還未能達WP:特色內容中的特色列表標準，但若是依照優良條目來看，其其實已經滿足精心編寫的、可供查證且無原創研究的、涵蓋面廣的（基本已列完大部分項目）、中立的、穩定、有大量圖片， 符合优良条目标准，但礙於它是WP:獨立列表，無法參與優良條目評選，但短期內又未能達到特色列表標準，因此認為，還需要一個優良列表評級來讓一些沒法花那麼多時間寫特色內容的編者能讓列表參與優特評選。目前有擬了一個優良列表的暫訂標準User:A2569875/提案/優良列表

以上，不曉得各位怎麼看？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 09:44 (UTC)[回复]

感覺@Lopullinen君會有點興趣。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月24日 (三) 05:45 (UTC)[回复]

(＋)傾向支持：個人感覺通過設立優良列表可以鼓勵編者增添圖片，註釋和提高列表質量。但需要更多考證，是否符合該標準的列表是否已經達到一定數目，所以有必要爲了該類型的列表專門立一個標準。--Mylittleairpod（留言） 2024年1月24日 (三) 06:21 (UTC)[回复]

不是反對，但這和協作計畫或者每週翻譯有什麼差別嗎？最後有很高的機率就是「再設一個蚊子館」而已。還有，首頁的顯示、票數門檻、存檔這些也該考慮進去吧？以首頁顯示的代碼來說，那就應該寫成：{{#ifeq:{{GoodContentType|{{{timecorrection|}}}}}|1|优良列表|优良条目}}才是，因為要叫首頁一天同時顯示兩樣，在中文維基百科是很難辦到的。另該提案因為是A2569875所提，以上敘述講完不再另外表態，拒絕再溝通。--Z7504非常建議必要時多關注評選（留言） 2024年1月24日 (三) 15:45 (UTC)[回复]
- 本質跟協作計畫或者每週翻譯完全不同，這個是為了要能讓列表也能優良級，而不必費時費力搞到特色內容而設的，不是每個人都有時間精力搞WP:特色內容。首頁顯示可以仿照特色列表與典範條目輪展的模式。既然是優良內容，那票數和存檔就跟優良條目一致就好，六票算通過，存檔仿照優良條目模式。至於蚊子館，如果使用此方案顯然不會產生「蚊子館」，而且還能回答上述大部分的問題。 -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月25日 (四) 09:52 (UTC)[回复]
  - 因現行FL的存檔是和FA的存檔一樣合併在這，那麼GL（如果沒有理解錯的話）的存檔是和GA一樣合併在這才對。至於投票模板也很簡單，FP的都可以製作出來了，沒理由GL的做不出來，當然沒有反對的必要。能不能大力推動才是問題，而不是整天只是在喊支持。協作計畫或者每週翻譯當初就是因為大力推動，最終鳥獸散的給人感覺不繼續使用也沒差（典範使用者頁面評選也是一個例子），維基百科別再犯這種沒意義的投票了。忘記說了，{{进行中的内容评选}}到時候請記得順便改，因為這提案最後一定會通過。--Z7504非常建議必要時多關注評選（留言） 2024年1月25日 (四) 14:21 (UTC)[回复]

（叉題一下）我覺得計劃本來就不是非得一直持續的東西，若參與的人力已經不足，就停吧，只要說明清楚，對維基百科其實影響不大。像Wikipedia:條目質量提升計劃/基礎條目提升計劃及Wikipedia:條目質量提升計劃/基礎條目攻堅戰都閒置了，不過計劃成果是在中文維基百科裡的，那就好了。

回到優良列表，娜娜奇提議時有提兩個評選方案，目前在評級系統和首頁顯示部份，都不是太大的問題。我比較好奇的是，有多少維基人會因為有優良列表而想要擴充或改良列表？至少現在先表態一下吧（目前的表態不代表未來一定可以參與，但假如目前都沒什麼人表態，就真的不太建議繼續往下進行了）。--114.45.208.181（留言） 2024年1月26日 (五) 15:54 (UTC)[回复]

我就是想讓正多面體列表變成優特條目，但我實在沒有時間和精力搞特色內容（你維自己說不要為了維基而耽誤生活的，不是我說的），無奈之下，只能想辦法提案讓正多面體列表也能評優良內容，不然按照現行指引正多面體列表是WP:獨立列表禁止提報優良內容，害我這個沒啥時間搞特色內容的人無法讓正多面體列表有個對等的評級，我也不能擅自給他標上「優良列表」我很無奈你知道嗎？如果這個不給推，我請求正多面體列表也能優特內容的替代方案，或者破例直接讓我評GA，否則我要(！)抗议樓上的意見，抗議樓上企圖害正多面體列表被「禁止評選」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月26日 (五) 16:18 (UTC)[回复]
(～)補充還有，我相信優良列表絕對會有人寫的，尤其是WP:動員令期間。優良列表案如果通過，高概率會變成動員令的得分項目之一；動員令是得分制的，這意味著許多編者會以高分為目標；以往列表編寫成超過「達標條目」的下一個門檻是「特色內容」，非常費時，而動員令又有限時，所以肯定會有編者願意寫門檻較低（雖分數較低）的優良列表，多寫幾條優良列表來獲得分數。屆時，肯定會出不少優良列表。所以就算現在沒有維基人會因為有優良列表而想要擴充或改良列表，不代表WP:動員令期間就沒有，而且我認為WP:動員令期間會有不少，非動員令期間只是淡季而已。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月27日 (六) 00:10 (UTC)[回复]

中維特色列表門檻已經算低了（看看獲獎列表、各國總理甚至是星體列表），除非在中維遇到專門領域的高手，不然大多優良沒意外都能變成特色（看看折毛事件）。而且，閣下怎麼會覺得優良列表實施後該列表能順利當選？ --窝法乙烷儿法梦碎 2024年1月27日 (六) 09:45 (UTC)[回复]

其他語種的維基百科對「優良列表評選」的規範如何？San mo sa _{Miyamoto Miyoko} 2024年1月31日 (三) 02:21 (UTC)[回复]

可以参考一下葡萄牙語維基百科和西班牙語維基百科对優良列表評選的规范。这里以葡萄牙語維基百科的规范作例：

1.文筆。它具有專業的寫作水準。
2.序言。它有一個能确切介紹主題並定義範圍和納入標準的序言。
3.全面性。它相对全面涵蓋了定義的範圍，提供至少所有主要項目。它不一定要详尽地论述主题。
4.結構。它很容易地為讀者導航和包含於不同條目中，有幫助的章節標題和表格分類設施。
5.風格。它符合格式手冊及其補充頁面。
6.視覺吸引力。它合適地使用文本佈局、格式化、表格和顏色；並在不影响理解的情况下可以使用紅色連結。
7.穩定性。它不受正在進行的編輯戰影響，其內容每天都沒有明顯的變化。
（此翻译借助DeepL机器翻译和人工润色，若有错译漏译情况请指出）

将此规范与本站的特色列表標準比较，我们可以轻易的看出：在序言上優良列表仅需达到准确的标准而对文笔没有要求；在全面性上優良列表无需详尽地论述论述主题，但仍需提供至少所有主要項目；在视觉吸引力上優良列表放宽了对紅色連結的要求。由此我们可以得出優良列表可以放低对文笔、内容全面性和红链的要求，但在其他方面上应该与特色列表持平。--人间百态,独尊变态 (讨论) 2024年1月31日 (三) 06:21 (UTC)[回复]

感覺葡語維基百科給的要求是合理的，但如果真要引入的話，我建議WP:特色列表標準的要求3B（即“在長度和/或主題中，它滿足獨立列表的所有要求；不違反內容分歧指引，不會大量複製另一篇條目的材料，且不能合理地列入相關條目的一部分”）同樣引入至優良列表。San mo sa _{Miyamoto Miyoko} 2024年2月1日 (四) 01:52 (UTC)[回复]

(＋)支持Sanmosa的意见。——Aggie Dewa dipper 2024年2月1日 (四) 03:32 (UTC)[回复]

提請連署要求維基媒體基金會再次採取法律程序提告長期擾亂者影武者

長期擾亂者影武者常年使用攻擊性語調對維基百科人進行攻擊，十幾年前，維基媒體基金會採取法律程序提告影武者，使影武者被處以緩刑；但他似乎沒有記取教訓，仍持續在維基百科上亂搞！這一個月來非常嚴重！建立數個帶攻擊性名稱的帳號(例一例二)，這對維基百科的形象造成了打擊！如果不提告，那麼我認為他很有可能繼續在這裡人身攻擊，繼續破壞中文維基百科的形象！這幾年活動編者的人數已經有感地下降了，我認為不太能再讓搗亂者繼續惡搞！

提請人：天蓬大元帥-會客 歡迎參與機器翻譯的維護 2024年1月24日 (三) 13:31 (UTC)[回复]

樂見其成。但成效存疑。估計他與社群常在。恐怕又有人會被他當成網絡特務了（笑）千村狐兔（留言） 2024年1月24日 (三) 13:48 (UTC)[回复]

雖然(＋)支持，但meta監管員能不能調閱KAGE的IP紀錄？--喜歡聽林佳辰唱歌的Sinsyuan 2024年1月24日 (三) 13:53 (UTC)[回复]

調閱 IP 及將相關資訊交給警局的工作是由基金會負責的，而非監管員。謝謝。--SCP-0000（留言） 2024年1月24日 (三) 16:59 (UTC)[回复]

两位例子本人才有提告的权利吧，上次是因为严重的人身威胁到编者，社群和基金会才有必要采取法律行动。而这些例子，受害人本人为知名人物，律师肯定请得起都没有任何行动，社群和基金会是否有必要代为提告？--桐生ここ★[讨论] 2024年1月24日 (三) 16:44 (UTC)[回复]

另外再说，GNSN也破坏原神相关和建立攻击性条目，社群或基金会是否有必要代米哈游提告？--桐生ここ★[讨论] 2024年1月24日 (三) 16:48 (UTC)[回复]

++，上次是因为恐吓社群成员去提告，这次我们去越俎代庖也不好看，破坏维基百科好像也没写进什么法律中。不过这个傀儡真的没违反选罢法吗，这应该不是告诉乃论的罪吧。 ——魔琴 [ 留言贡献新手2023计划 ] 2024年1月25日 (四) 02:05 (UTC)[回复]

如果未恐吓社群成员，我们无需提告。Python6345（留言） 2024年1月25日 (四) 05:41 (UTC)[回复]

如有人身威脅之情況，依此說明聯絡基金會即可。如有需要，基金會自然會聯絡當地執法部門，而無需聯署要求基金會採取法律行動。謝謝。--SCP-0000（留言） 2024年1月25日 (四) 06:52 (UTC)[回复]

@林天蓬、Manchiu、Sinsyuan、SCP-2000、桐生ここ、魔琴、Python6345：向基金会举报用户的方法不是连署，而是向ca@wikimedia.org发送邮件（链接里面有具体邮件要求）。预计处理时间是四周。--GZWDer（留言） 2024年1月28日 (日) 15:43 (UTC)[回复]

上述討論乃請求基金會對該 lta 採取法律行動，而非請求對其進行全域禁制，儘管個人不反對對其禁制（但作用有限）。而涉及人身威脅之情況，個人上方已提及。謝謝。--SCP-0000（留言） 2024年1月29日 (一) 04:27 (UTC)[回复]

Zheng Zhou

Zheng Zhou（讨论 | 貢獻） submitting copyvio pages since 2017-08-27 02:54(UTC) on 建设大道.
Their comments on Special:固定链接/80634460#c-Zheng_Zhou-20240125072800-Lemonaka-20240125063200 is also very aggressive. We need your help for checking their contributions. -‎Lemonaka‎ 2024年1月25日 (四) 09:22 (UTC)[回复]

事件已经基本过去了，不要翻旧账警告，“#2024年1月”章节上。如果全篇有问题，可以按照Wikipedia:頁面存廢討論/疑似侵權提报处理，可以确定他过往的确没有注意到条目的内容相近与侵权性问题。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月25日 (四) 10:12 (UTC)[回复]

他写了那么多垃圾条目，为什么不能逐一警告？难道他看起来像是知道错了的样子吗？ --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年1月25日 (四) 13:28 (UTC)[回复]

「垃圾條目」也太過分了吧... 前幾年寫的有些條目現在看起來確實有問題，警告本身沒問題，有錯我改。我在討論頁跟他說的意思，是讓他不要不斷發出封禁的威脅，尤其是不要因為最近的事去翻舊賬然後來威脅，他的雙重標準也不是我憑空捏造的吧？我還是那句話，我們有時間在這裡不斷爭辯這些，有這時間改善那些條目恐怕都足矣了。當然了，如果閣下諸位無意改善條目，單純就是想要我噤聲的話，那我無話可說。--Zheng Zhou（留言） 2024年1月25日 (四) 16:49 (UTC)[回复]

好吧，我看了看棕櫚心等幾個條目中的修改，確實中肯，我多學習學習。--Zheng Zhou（留言） 2024年1月25日 (四) 17:13 (UTC)[回复]

申報

我是捍粵者，不過入不到舊電腦，唯有暫時用分身　　捍粵者二（留言） 2024年1月31日 (三) 11:38 (UTC)[回复]

@捍粵者二：已幫您在分身用戶頁申報。--Cmsth11126a02 (留言) 2024年1月31日 (三) 15:45 (UTC)[回复]

好，不過如果我主帳有被動活動（留言、回退等），我用分身不會收到通知／提醒，有無方法可將主帳的通知也傳給分帳？--捍粵者二（留言） 2024年1月31日 (三) 15:56 (UTC)[回复]

您忘記帳號密碼了？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年2月1日 (四) 17:36 (UTC)[回复]

本站移动版首页一直缺少顶部横幅

好像一直没看到有人提出来，就提一下。

其他几乎所有站点的移动版在顶部都有维基百科的横幅（“维基百科，自由的百科全书”和“本站共有XXX篇条目”等等），唯独本站只有桌面版有此横幅。我认为首页作为本站门面，需要有这样一个横幅。

可以参考别站的设计。我认为设计最好的是俄语维基百科，横幅和顶栏融为一体，观感很不错。

现征求社群意见。--碟之舞📀💿 2024年2月2日 (五) 03:38 (UTC)[回复]

将条目中的HTTP外部链接替换为HTTPS外部链接是不可以被接受的吗？

如题。最近在几个任天堂相关的条目当中出现了这样的编辑争端。对了，甚至还有个广域封锁Special:滥用日志/5021702。

事情跟一个IP使用者相关，被认为有KAGE的嫌疑。不过(1)KAGE没有遭受Global Ban，没有无条件回退其所有编辑以落实GBAN的要求；(2)一般的BAN方针虽然有提到任何人可以无摘要地回退所有绕过封锁的编辑，但是也有需注意并非所有由被封禁用户绕过封禁作出的编辑都需要被回退，一些明显有益的编辑例如修正错字及回退明显破坏的编辑等可被保留的说明。

所以，回到标题的问题。把非加密链接更改为有加密链接，算不算是有益的编辑？--Milky Defer 2024年2月3日 (六) 05:59 (UTC)[回复]

我的立场是在注重网络连接安全性的大环境下，这种编辑对读者的个人资料安全是有益的。--Milky Defer 2024年2月3日 (六) 06:00 (UTC)[回复]

有益的。未看出需要回退。增减无效空行等刷编辑数，也不是需要回退的。--YF dyh000（留言） 2024年2月3日 (六) 06:12 (UTC)[回复]

单纯就题目而言，并不是所有的http链接都可以被替换为https链接，因为不是所有的网站都支持加密协议。--安忆 ^Talk 2024年2月3日 (六) 07:01 (UTC)[回复]