Wikipedia:互助客栈/其他：修订间差异

以互动方式浏览历史

←上一版本下一版本→

删除的内容添加的内容

可视化wikitext

行内

2024年1月20日 (六) 13:14的版本

快捷方式

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

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

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

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

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

公告欄

[投票] 2024年5月管理人员申请投票正在进行中，参见投票列表，歡迎踴躍參與。
[投票] 2024年5月关于仲裁委员会的调查问卷正在进行中，参见投票頁面，歡迎踴躍參與。
[公告] 互助客栈正在对于Unblock-zh.org的各项细节征求意见。
[公告] 再擬設立文化遺產關注度指引、將地理特徵關注度指引中有關道路的部分改為在交通關注度指引中列出及修改RFA流程相關規定已經通過。
[公告] 再擬設立國際關係命名常規為方針正在公示，如有意見請儘快提出。
[討論] 目前有涉及禁止在互助客棧條目探討區發起部分類型討論的重大政策提案仍在討論。為確保您的意見及權益獲得充分反映，請踴躍參與規範討論發起步驟討論。
[討論] 有用戶正就重修破壞方針徵求社群意見，請踴躍參與討論。
[討論] 互助客栈方针区正在討論電視條目播放信息增加收錄準則，請踴躍參與討論。
[討論] 互助客栈技术区正在討論更改未登入用戶的預設字體大小及增加外觀選單及ToolsRedirect创建的繁簡重定向問題，請踴躍參與討論。
[討論] 互助客栈其他区正在討論頁面評級與通用評級行政層面上的統合方案及將法輪功及臺灣政治訂為高風險主題，請踴躍參與討論。
[廣告] 第二十二次動員令將於7月6日至9月8日間舉行，現正在提議、協調主題及募集主持人，歡迎踴躍參與！
[廣告] 維基百科非洲月現正舉行，直至6月30日完結，歡迎踴躍參與！

[協作] 现有124个页面需维基化，281个条目需清理，11个移动请求正在讨论。

存檔

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	沒有主題的頁面如何評級	190	12	Ericliu1912	2024-06-03 10:32
2	評級系統缺失問題	213	21	A2569875	2024-06-01 18:55
3	管理人员申请预讨论	55	18	Wong128hk	2024-06-02 10:45
4	對新用戶禁用內容翻譯工具（續）	32	13	SCP-2000	2024-05-24 00:31
5	Unblock-zh.org	47	14	LuciferianThomas	2024-06-05 10:22
6	第二十二次動員令籌備討論	1	1	T45614631	2024-06-05 11:07
7	2024年非洲月籌備討論	29	12	Alankang	2024-06-01 09:08
8	設立法輪功為高風險主題	44	14	Wetrace	2024-06-04 21:07
9	是不是建立一个披露过滤器细节的规范比较好	5	4	Bluedeck	2024-06-01 17:56
10	关于「Save to」和「Moved to」	9	7	Ericliu1912	2024-06-05 12:35
11	介绍 iOS 建议编辑：增强维基百科的移动贡献	1	1	ARamadan-WMF	2024-05-29 15:45
12	將「1945年後臺灣政治」訂為高風險主題	22	11	Sinsyuan	2024-06-04 15:27

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

正在廣泛徵求意見的議題

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

維基專題與協作

目前此主題無正在討論的議題

强烈建议使用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)[回复]

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

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

原标题为：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)[回复]

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

沒有主題的頁面如何評級

本主題或以下段落文字，在討論結束後應存檔至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

@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)[回复]

第三階段：完善制度

在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)[回复]

關於基礎條目的額外提議

似乎已有共識，跟隨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)[回复]

藍桌圖書館預覽插件

剛剛給藍桌圖書館（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月15日 (一) 04:28 (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)[回复]

關於結構化討論的未來

本主題或以下段落文字，移動自Wikipedia:互助客栈/消息。

大家好，

您可能已經知道，維基媒體基金會致力於改變 IP 編輯的處理方式：: IP 編輯：增強隱私和緩解濫用情況。未註冊的臨時編輯者帳戶將是一種新型的用戶帳戶。這需要改變我們用來貢獻維基工作的功能的方式。

這項工作涉及所有功能，並提出了一些挑戰。結構化討論（英文簡稱為 SD 或Flow）的案例就是其中之一。此擴充功能在一些維基專案中使用，包括您所屬的維基專案。 Flow 是一款複雜而且從未完全完成的軟體，不太適合 MediaWiki 架構，並且會產生大量技術錯誤。

我們考慮了幾種合適 SD 的選項：完全應用；或是臨時帳戶可以回應但不能建立新對話的部分調整。所有這些選項都需要花費大量的時間和精力才能獲得短期的利益。此外，維基媒體基金會的長期計劃是從維基專案中刪除 SD——主要是出於維護成本的考量。因此，我們傾向於避免將 SD 應用於臨時帳戶。

我們利用臨時帳戶工作的機會向您的社群詢問 SD 的未來。

討論工具是 SD 的替代品。這是所有維基專案的預設討論系統。這允許任何人開始、回覆或訂閱對話。這為基於維基專案文字的對話提供視覺體驗，並涵蓋結構化討論提供的絕大多數功能。

本次對話的目的是回答您有關結構化討論存檔的問題。

這個想法是分兩個階段進行：

使用 SD 的討論頁面被存檔為子頁面。這會被經典的討論頁面取代。這樣，當我們繼續步驟 2 時，最活躍的頁面就已經準備好了。
SD 將從維基專案中刪除。現有頁面（包括存檔頁面）將轉換為尚未定義的格式。

有些使用者在其個人討論頁面上使用結構化討論'

在您的維基專案中，任何使用者都可以將結構化討論作為 Beta 功能開啟。此選項很快就會被刪除。

我們希望達成協議，涵蓋您的問題和評論，其中刪除結構化討論將適用於所有使用者。目標是在將基於結構化討論的頁面從維基專案中刪除之前對其進行存檔。

如果您在您的討論頁面上使用結構化討論，我們鼓勵您考慮切換到討論頁面的預設格式。您可以透過取消選取 Beta 功能中的選項來完成此操作。

對於開啟了結構化討論但不再編輯的用戶，轉換將在稍後完成（連同所有剩餘頁面），但日期尚未確定。

我們對您的期望

定於 12 月 20 日討論結束時分享您的答案：

歸檔結構化討論的原因是否明確？
上面概述的歸檔和卸載結構化討論的兩個步驟是否清晰？
如果是這樣，歸檔頁面以進行卸載的合理時間範圍是多少？目前，我們這邊未有計劃卸載（即使提到了 2024 年第二季），因為我們正在等待這些在多個維基專案上進行的對話結束。
您認為，當我們繼續卸載結構化討論時，目前使用 SD 的頁面應該轉換為什麼格式？

如果您需要澄清，歡迎您向我提出任何問題！我已經訂閱了這個部分，我會盡力盡快回答（主要以英語回答）。

Trizek (WMF)（留言） 2023年12月11日 (一) 18:17 (UTC)[回复]

可否贴出英文原文，以便社群成员自行翻译？--Tiger（留言） 2023年12月12日 (二) 00:13 (UTC)[回复]

@Tigerzeng：英文原文見此。--SCP-0000（留言） 2023年12月12日 (二) 00:56 (UTC)[回复]

Let me know if the translated text has problems. It is important for us to provide qualitative texts when we use a translation service. --Trizek (WMF)（留言） 2023年12月12日 (二) 13:24 (UTC)[回复]

Hello, There are several mistakes in the text, for example:

"提出了一些挑戰" it should be "帶來了一些挑戰"
"短期的利益" it should be "短期的益處"
"我們希望達成協議，涵蓋您的問題和評論" "這會被經典的討論頁面取代" "這為基於維基專案文字的對話提供視覺體驗" Translations are unclear.

I think the main reason why there are mistakes was because used machine translation but forgot to revise some of the words. Anyway, thank you for your translation and efforts. cc translator @Venuslui：--SCP-0000（留言） 2024年1月14日 (日) 16:13 (UTC)[回复]

We used a human translator. I will share your feedback with them for improvements. Thank you! :) --Trizek (WMF)（留言） 2024年1月18日 (四) 15:31 (UTC)[回复]

副知曾參與過往相關討論的編者。 --SCP-0000（留言） 2023年12月12日 (二) 02:54 (UTC)[回复]

(zh)卸载Flow后很多Topic链接和Diff/PermaLink是不是就全坏了？不能把矢山留下来但是把Flow页面全部锁定掉么？
(en)After Flow is uninstalled, would lots of Topic links, Diffs and PermaLinks be broken? Can't we just keep the legacy code and lock all the Flow pages? ——魔琴 [ 留言贡献新手2023计划 ] 2023年12月12日 (二) 10:17 (UTC)[回复]

不，留着Flow对我等机器人使用者来说才是最头疼的问题。Flow（Topic:）是唯一一个没有对应Topic talk:的namespace，这会破坏很多代码正常工作的假设。

The Topic namespace is the only namespace (not counting Special and Media) that does not have an associated namespace ("Topic talk"). This exact fact breaks many premises for bots to work properly.--Milky Defer 2023年12月12日 (二) 11:04 (UTC)[回复]

@魔琴 We can't keep the legacy code: it would be too much work to maintain it. We have to convert all contents. As I wrote below, our goal is to discuss on what could be broken, and how to prevent it. --Trizek (WMF)（留言） 2023年12月12日 (二) 13:49 (UTC)[回复]

(zh)明白。但是我还是担心有关Flow页面的引用。也许有人引用过Flow的差异或者历史版本，像这样，Flow卸载之后可能没法正确使用。
(en)Understood. But I'm still worrying about citations to Flow pages. Maybe someone have linked to diffs or revisions of Flow pages, like this. These links may not be able to function after Flow is uninstalled. ——魔琴 [ 留言贡献新手2023计划 ] 2023年12月12日 (二) 14:05 (UTC)[回复]

I noted your example, as it is a good illustration of your needs. But for now, I can't tell you if it will be possible to keep these diff links. I understand that it is better to keep them, but if not possible, what would be the acceptable solution? --Trizek (WMF)（留言） 2023年12月12日 (二) 14:34 (UTC)[回复]

可以设立普通的Topic命名空间，将现有的Flow页面内容转换为wikitext放在对应的Topic命名空间。

例如Wikipedia:知识问答/存档/结构式讨论这个Flow页面变成这样的wikitext：

然后把现在的Flow类型的Topic:Ukfy2x40lfuzy9x1等页面转换成wikitext放在Topic命名空间。--桐生ここ★[讨论] 2023年12月12日 (二) 16:11 (UTC)[回复]

举例

原始Flow页面：

Wikipedia talk:Flow tests

原始Topic页面：

转换后Flow页面：

User:测试用户/Wikipedia talk:Flow tests

转换后Topic页面：

--桐生ここ★[讨论] 2023年12月12日 (二) 16:40 (UTC)[回复]

没必要保留一个死去的名字空间--百無一用是書生 (☎) 2023年12月14日 (四) 02:59 (UTC)[回复]

赞成没有必要保留，可以在删除/移动日志里写内容转移到了哪里--及时雨 ^留言 2023年12月16日 (六) 05:22 (UTC)[回复]

如果要用命名空間保留不如佔一個NS4的子頁面（Wikipedia:FlowArcive/Topic:xxx）或一個特殊頁面（Special:FlowArcive/Topic:xxx）之類的，不然依然有Topic talk這種問題--Sun After Rain 2023年12月16日 (六) 06:40 (UTC)[回复]

@Trizek (WMF)：After the conversion, is there a script to automatically convert the links that become invalid? Or will there be a transitional special page (e.g. Special:FlowRedirect/Topic:XXXXX#XXXXX)/namespace redirect launched?--Sun After Rain 2023年12月12日 (二) 12:01 (UTC)[回复]

Thank you for your responses.

We are open to your ideas on how the Topic: contents should be transformed. We could have provided technical solutions and ask you to use them. Instead, we look for your ideas and your needs.

Keeping a way to keep topics's URLs was highlighted by other communities I consulted. It is a clear need. How we will address this need is a second step.

Another question we are curious about is: how should we treat talk pages that have +1,000 topics? Should we keep everything on one page ? Should we split by years, or months? Should Topics be a sub-page ?

Trizek (WMF)（留言） 2023年12月12日 (二) 13:30 (UTC)[回复]

My proposed solution to that would be keeping everything on the same page, merge topics into the transformed talk page it once lived in. Splitting them should be a responsibility of us, not the script.--Milky Defer 2023年12月12日 (二) 15:21 (UTC)[回复]

If everyone's each message (and edit message) will become a single revision, I think it is necessary to split the archive directly according to certain conditions (maybe the split condition allowed by mw:Manual:Pywikibot/archivebot.py?), otherwise if it is just a snapshot, just save it on the same page and leave it to the community to handle.--Sun After Rain 2023年12月12日 (二) 15:58 (UTC)[回复]

就命名來說，我倒是認為可以保留各該討論原本的亂碼標題（至於其命名空間或母頁面前綴另說），這樣即使無法直接轉型成正常討論頁，也能方便後人間接追蹤連結。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年12月14日 (四) 05:00 (UTC)[回复]

Thank you everyone for your responses. I noted all your suggestions. Trizek (WMF)（留言） 2023年12月15日 (五) 17:07 (UTC)[回复]

我希望Trizek提出方案的第一步尽快被执行，并且应该从技术上禁止编辑这些存档。另外我认为应该通知所有已经开启flow的用户停止使用。

关于第二步，我希望转化为wikitext页面，因为这似乎是最好的选择。--落花有意12138 2023年12月16日 (六) 11:32 (UTC)[回复]

Telling other community members can be done by your community right now. Or we will take care of it before converting all pages to wikitext. --Trizek (WMF)（留言） 2023年12月22日 (五) 10:04 (UTC)[回复]

認同應以 MMS 通知目前正使用 flow 的用戶。如果等到「before converting all pages to wikitext」才通知，社群未必可充分討論及表達意見。謝謝。--SCP-0000（留言） 2023年12月30日 (六) 06:50 (UTC)[回复]

既然要删了Flow，是不是该更新Wikipedia:結構式討論了？--Txkk（留言） 2023年12月22日 (五) 02:12 (UTC)[回复]

反倒想問，大家覺得有哪些FLOW是認為必須保留下來？--J.Wong 2023年12月30日 (六) 05:32 (UTC)[回复]

依照基金會目前的計劃以及 Flow 的各種技術問題，理論上保留 Flow 這個功能是不可行，也不是一個恰當的選擇。

至於趁這次的更動來順便決定哪些目前使用 Flow 討論頁的存廢，個人暫時沒有意見就是了。謝謝。--SCP-0000（留言） 2023年12月30日 (六) 07:40 (UTC)[回复]

That's correct: the Flow system will be removed, and no page using it will be kept. Existing contents will be converted to wikitext, later. For now, users are invited to move their talk page or any community page using Flow to a sub-page. --Trizek (WMF)（留言） 2024年1月8日 (一) 15:06 (UTC)[回复]

我在页顶加了废弃告示。--碟之舞📀💿 2024年1月2日 (二) 09:38 (UTC)[回复]

@Txkk：我更新了一下（我是1.164.141.84·Firedoge2024·PandaFiredoge·意面混凝土·Firedoge2023·HUAJIDOGE·RTX 3090·Blbj ）--118.167.67.225（留言） 2024年1月7日 (日) 15:19 (UTC)[回复]

WP:RFC/RFA2024相關問題

本主題全部或部分段落文字，已移動至Wikipedia talk:請求評論/2024年管理人員制度改革。执行人：Jimmy-bot（留言） 2024年1月19日 (五) 16:14 (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年1月16日 (二) 13:23 (UTC)的辦理狀況。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 17:08 (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)[回复]

後續討論

通知全站用户弃用Flow

根据讨论，基金会希望逐步弃用Flow（又称结构化讨论，SD）。我提案通知仍在使用Flow的用户存档其讨论页。

我筛选的开启flow的用户讨论页--落花有意12138 2024年1月1日 (一) 02:11 (UTC)[回复]

支持（表上看到了好多奇奇怪怪的账号）--及时雨 ^留言 2024年1月2日 (二) 14:07 (UTC)[回复]

支持，理由見之前討論。--SCP-0000（留言） 2024年1月2日 (二) 16:41 (UTC)[回复]

是不是應該提及具體停用日程？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月3日 (三) 13:03 (UTC)[回复]

現階段基金會未有提及具體時間表以及具體計劃。

而正如個人在 TG 群所言，通知目的既讓社群得知 Flow 的停用計劃，亦讓社群趁是次討論發表意見，以免過去 Vector 2022 缺乏本地社群意見之部署情況再次發生。謝謝。--SCP-0000（留言） 2024年1月3日 (三) 15:05 (UTC)[回复]

那通知本身應聚焦於該制度「將停用」之事實，並鼓勵參與討論。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月3日 (三) 15:07 (UTC)[回复]

支持。--桐生ここ★[讨论] 2024年1月3日 (三) 14:50 (UTC)[回复]

支持棄用Flow。San mo sa _{Romeo and Qubilai} 2024年1月4日 (四) 08:09 (UTC)[回复]

支持，退Flow保平安。--紺野夢人 2024年1月4日 (四) 13:40 (UTC)[回复]

@Sanmosa、Yumeto：此處是討論通知與否，而非討論 Flow 的未來，建議參與上方討論。謝謝。--SCP-0000（留言） 2024年1月4日 (四) 15:15 (UTC)[回复]

支持通知，使用Flow的人應該要有知情權。San mo sa _{Romeo and Qubilai} 2024年1月4日 (四) 15:20 (UTC)[回复]

但我這裡看到了5540行，不是5520行耶quarry:query/79325

囧rz……。題外話，還有八個沒有被標記成存檔的非ns3頁面，分別是User:Bluedeck/etc/sandbox/box1505821308170、

User:Bluedeck/etc/sandbox/box1512957074239、User:Shizhao/删除百科、Wikipedia:台灣生命大百科審查專頁/審查討論頁、Wikipedia:中国大陆维基人用户组/维基爱中国2019/讨论、Wikipedia talk:臺灣教育專案/臺大物理系服務學習二_(107-1)、Wikipedia talk:Flow_tests、Wikipedia talk:結構式討論。--Sun After Rain 2024年1月5日 (五) 05:37 (UTC)[回复]

我是直接把页面名中带斜杠（/）的都去除了，看起来您的处理方法更合适一点。

这些页面中，前几个user空间的应与该用户讨论，空的页面阁下已经提删，Wikipedia:台湾生命大百科审查专页/审查讨论页、Wikipedia talk:Flow_tests、Wikipedia talk:结构式讨论应该存档。--落花有意12138 2024年1月7日 (日) 03:08 (UTC)[回复]

消息内容草案

提案内容：

由于缺乏维护和兼容问题，维基媒体基金会和社群有意弃用结构式讨论（又称Flow），现在使用结构式讨论的讨论页未来将转换成Wikitext（维基文本）。因为您的讨论页启用了结构式讨论，所以向您递送此消息。我们邀请您参与相关讨论，并建议您先行考虑关闭此功能。如有问题，亦可至互助客栈求助区留言。

以上——落花有意12138 2024年1月7日 (日) 04:11 (UTC)[回复]

@落花有意12138：我稍微润色了一下，请复查。--碟之舞📀💿 2024年1月8日 (一) 09:07 (UTC)[回复]

(＋)支持。同時依照 WMF 的回覆增加了「現時使用Flow的討論頁未來將轉換成Wikitext。」這句補充說明。謝謝。--SCP-0000（留言） 2024年1月9日 (二) 04:32 (UTC)[回复]

另副知參與此討論的編者，如果沒有異議的話，過幾天可以通知全站了。謝謝。--SCP-0000（留言） 2024年1月9日 (二) 04:32 (UTC)[回复]

再微調用詞。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年1月9日 (二) 04:46 (UTC)[回复]

几日无反对意见，认为提案已经通过。

请有massmessage权限的人员（包括管理员和大量信息发送者）向[4]所列页面发送如下消息：

由于缺乏维护和兼容问题，维基媒体基金会和社群有意'''弃用'''[[Wikipedia:結構式討論|结构式讨论]]（又称Flow），现在使用结构式讨论的讨论页未来将转换成Wikitext（维基文本）。因为您的讨论页启用了结构式讨论，所以向您递送此消息。我们邀请您参与[[Wikipedia:互助客栈/其他#關於結構化討論的未來|相关讨论]]，并建议您先行考虑[[Special:参数设置#mw-prefsection-betafeatures|关闭此功能]]。如有问题，亦可至[[Wikipedia:互助客栈/求助|互助客栈求助区]]留言。

——落花有意12138 2024年1月13日 (六) 16:06 (UTC)[回复]

製作成這樣User:ASid/結構式討論棄用通告及發送名單User:ASid/結構式討論棄用通告/SList，發送名單改成這種格式是因為我有詢問過Stang君這樣會比較好處理，另外我有修正發送名單當中一些是存檔頁的，改為指向使用者正在使用的討論頁。@落花有意12138：您看一下這樣行不行。--~~S i d~~ 2024年1月13日 (六) 18:12 (UTC)[回复]

只需通知現時使用 Flow 的用戶即可，所以有些僅在存檔頁使用 Flow 的用戶就不需要通知了。--SCP-0000（留言） 2024年1月13日 (六) 18:36 (UTC)[回复]

@SCP-2000：收，已經修正。--~~S i d~~ 2024年1月14日 (日) 09:58 (UTC)[回复]

请问已关闭并存档的 Flow 用户讨论页是否也能够自动转换？（User talk:David Xuang/存档/Flow）我有意将 Flow 存档中的讨论与现时讨论页上的话题一同整理存档。--DvXg 📬 2024年1月16日 (二) 16:29 (UTC)[回复]

通知一下各位，通告已經發送了。--~~S i d~~ 2024年1月17日 (三) 15:34 (UTC)[回复]

后续讨论

大家好。参数设置中的“测试功能”版中，当“自动启用大部分测试功能”启用时，“讨论工具”是默认开启的。我本人习惯开启“自动启用大部分测试功能”，目前我已手动禁用。--Heavysnowjakarta（留言） 2024年1月17日 (三) 12:25 (UTC)[回复]

才发现上面还有“关于结构化讨论的未来”一章。如果我不应该放在这里，我深感抱歉。--Heavysnowjakarta（留言） 2024年1月17日 (三) 12:28 (UTC)[回复]

文件上传向导中应该单独添加上传自由文件的按钮

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

如题，在维基百科自由版权的内容应该传到共享资源，而只有非自由的内容才应该上传到本站。而目前文件上传向导中只有在本站上传的按钮，可能会误导新手。

私以为应采纳英维的设计，用两个按钮分别列出自由文件和非自由文件的上传途径，这样对新手更友好。--碟之舞📀💿 2024年1月7日 (日) 13:07 (UTC)[回复]

模板编辑员可以编辑。--GZWDer（留言） 2024年1月7日 (日) 13:27 (UTC)[回复]

那个得改js吧--百無一用是書生 (☎) 2024年1月7日 (日) 13:44 (UTC)[回复]

我没搞错的话，似乎不要。--碟之舞📀💿 2024年1月7日 (日) 14:23 (UTC)[回复]

(＋)支持：這樣能避免讓使用者誤解。--喜歡聽林佳辰唱歌的Sinsyuan 2024年1月7日 (日) 14:17 (UTC)[回复]

支持，共享资源的只是个简单的跳转按钮，不用改js--及时雨 ^留言 2024年1月7日 (日) 22:39 (UTC)[回复]

根据意见并参照英文版进行了修改，请看是否合适--百無一用是書生 (☎) 2024年1月8日 (一) 07:59 (UTC)[回复]

@Shizhao：C区链接可以指定语言吗（比如Special:MyLanguage）？--碟之舞📀💿 2024年1月8日 (一) 08:32 (UTC)[回复]

用户可以在C区自行设定语言--百無一用是書生 (☎) 2024年1月8日 (一) 13:15 (UTC)[回复]

欢迎来到文件上传向导！您可以在此页面将图片或其他媒体文件上传至维基百科。点击下面的链接，向导会指引您完成一份调查，提示您为每个文件提供相应的著作权和来源信息。

上傳以前，请确保您已經了解什麼是著作權、文件使用方针以及非自由内容使用准则。违反上述版权规定的图片将可能被删除。

这段文字因为下方现在有两个按钮所以需要作调整，我的建议如下（顺便优化一下翻译腔）：

欢迎来到文件上传向导！您可以在此页面将图片或其他媒体文件上传至维基百科。请根据您欲上传的文件的著作权和来源信息，选择相应的选项并继续。

上傳之前，请确保您已經了解什麼是著作權、文件使用方针以及非自由内容使用准则。违反上述版权规定的图片可能会被删除。谢谢您的贡献！

--碟之舞📀💿 2024年1月8日 (一) 08:40 (UTC)[回复]

另外想问一下向导中“第三步：提供来源和著作权信息”中仍然有“这是一件自由的著作权作品”，请问是否需要更新？--碟之舞📀💿 2024年1月8日 (一) 09:10 (UTC)[回复]

一个是自由授权的作品也可以有充分的理由不上传到c区而仅上传至本地。我不希望这次改版把这个情况忽略。--Milky Defer 2024年1月9日 (二) 12:28 (UTC)[回复]

(－)傾向反對，这会导致部分不熟悉图片版权的新用户误将非自由图片当作自由图片上传至共享资源（本地时常可见将「公开可见」的图片当作「公有领域」来上传的用户），而共享资源日常上传数量巨大，本地用户巡查困难。「只有非自由的内容才应该上传到本站」这个说法也是错误的。自由文件应通过上传向导中第三步「这是一件自由的著作权作品」上传，本地核查授权无误后可再转移至共享资源。另可参见Wikipedia_talk:上传/存档1#提議將上傳頁面中上傳至維基共享中加入警告標示和Wikipedia_talk:上传/存档1#在本地禁用“跨维基上传”功能。--Wcam（留言） 2024年1月9日 (二) 18:34 (UTC)[回复]

@Wcam：了解，但是英维也有同样的模板，为什么他们的上传页面是现在这个设计？--碟之舞📀💿 2024年1月10日 (三) 02:03 (UTC)[回复]

我不知道这个问题的答案，猜测原因可能与英文维基和共享资源使用英语的社群人力较为充足有关，而中文维基社群有自身的具体情况，不宜盲目照搬英文维基的做法。--Wcam（留言） 2024年1月10日 (三) 03:38 (UTC)[回复]

以及，自由图片需要保留在本地的情况对新手来说是否常见？因为本提案主要是想优化新手体验。--碟之舞📀💿 2024年1月10日 (三) 02:09 (UTC)[回复]

不太明白这个问题。本地图片迁移至共享资源后，一般会保留相同文件名（或建立重定向），对于图片使用而言，与其他本地图片没有区别，不知道你说的「优化新手体验」具体指什么？自由图片如上传至本地，会对新手体验有何不便或不利影响？--Wcam（留言） 2024年1月10日 (三) 03:40 (UTC)[回复]

优化新手体验指的是改善他们在上传文件时候的体验。在维基百科上传文件有两个渠道——本站和共享资源。先前的设计没法让新用户简洁明了地明白这两个渠道的区别（表单很复杂）。而根据我的理解，自由版权的文件除了少数因为特殊原因（如用户签名、在美国和原始地区不同时为自由版权的情况）需要保留在本地之外，其他的最终都应该传到共享资源去。所以干脆一步到位，让该去C区的内容直接去C区，也能让新用户明白这两个渠道的区别。

如果要解决“不熟悉图片著作权的新用户误将非自由图片当作自由图片上传至共享资源”问题的话，我认为可以在页面中增加足够的警告措施。例如列出常见误解；上传之前要求新用户答题，全答对才继续等。

以上是我的理解，如果有不对的地方请告诉我。--碟之舞📀💿 2024年1月10日 (三) 04:15 (UTC)[回复]

大体上明白你的意思了。知道如何上传的用户大多已经会直接去C区上传，通常上传至本地的自由图片数量不是很多，本地社群目前足以应付。--Wcam（留言） 2024年1月10日 (三) 06:15 (UTC)[回复]

可以把自由版权按钮变小一点，放在下面？然后写一句"如果您不确定是否自由版权，请不要选择这一选项"。--及时雨 ^留言 2024年1月10日 (三) 02:10 (UTC)[回复]

刚刚看了一下日维的设计可能更符合本站的需求。他们是将自由图片和非自由图片分为两个区域，而自由图片区域又分为传C区（并且标注为推荐方法）和传本站两个子区域。--碟之舞📀💿 2024年1月10日 (三) 04:16 (UTC)[回复]

ja不支持合理使用，所以本地上传不接受非自由版本的文件，优先使用符合版权自由的文件，也就是C区；现在保留下来的本地文件主要是符合日本公有领域但不符合美国的公有领域的，和受美日版权法保护的户外艺术作品，所以本地文件数量实际不多，可以看其上传导向页面下面的说明（ja:Wikipedia:ファイルのアップロード）。人家C区占主，是因为本来就不支持本地上传的因素更多，全力力撑C区。如果我们那些新鱼有这么高的版权素质的话，或者可以考虑下。

——Sakamotosan路过围观 | 避免做作，免敬 2024年1月10日 (三) 06:47 (UTC)[回复]

ja的排版分左右，左是C区，两个分别是上传向导和旧式上传表单；右是本地，一个纯表单没预填充，另一个是预填充了版权标示模板的。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月10日 (三) 06:54 (UTC)[回复]

好像当初不显示C区的上传按钮，就是有些新手会乱将不符合版权要求的图片优先上传到C区，最终还要这边的巡查去那边提报处理（你看，还要最终让C区的再处理一遍，多花一个人来换灯泡）。所以简单结论是干脆不显示，新手老老实实先放这里，有神奇的Wcam等去对付这些傻子（狗头），老手自然会区分哪些可以直接上传C区，怎样做搬运（有lab工具），去哪上传。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月10日 (三) 06:35 (UTC)[回复]

我认为这次修订是提案者缺乏对过往问题的认识的鲁莽的ENWIKISAID跟随行为。所以我认为需要暂时撤回该次修订，需要说明清楚如何避免过往问题可能出现的情况，例如如何解决新手实际上不理解著作权而导致会将非版权自由文件当成版权自由的文件上传到C区（不要高估用户）。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月10日 (三) 07:08 (UTC)[回复]

Wikipedia_talk:上传/存档1#提議更改「上傳檔案」頁面的排版。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月10日 (三) 07:08 (UTC)[回复]

类似明显直接地区分C区和本地上传的，就是我们上一版的指南式导航：Wikipedia:上传/old，如果只是一般困惑的话，用这个基本够用了。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月10日 (三) 07:14 (UTC)[回复]

题外话，啥时候能支持拖拽上传啊？--百無一用是書生 (☎) 2024年1月15日 (一) 02:02 (UTC)[回复]

两边项目API支持隐匿上传（过程是第一次上传暂存时设置stash=1，返回filekey；第二次确认时不用附带文件而附带之前的filekey。第一次上传的imageinfo.url会返回在[[Special:上传藏匿/file/<filekey>]]的文件路径）。如果文件要送去C区的话，可能有点麻烦，要么重新触发上传（需要保存上传时的file的input元素来获得文件路径），要么用URL上传（但URL域名是我们项目，要看C区配置有没接收，因为图片默认允许域名应该是upload.wikimedia.org）。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月19日 (五) 01:06 (UTC)[回复]

维基媒体基金会愿景的中文翻译

转自TranslateWiki中文讨论区。有译者认为维基媒体基金会的愿景现时的翻译存在问题，需要修改。为由于此翻译意义重大，需要尽可能保持稳定，必须广泛征求社群意见后再修改。

原文为：

Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.

现时译文为：

想象一下这样的世界：在这个世界中，人人都能在知识的海洋中自由分享。这就是我们的决心。

有译者认为存在这些问题：

原文中不存在“知识的海洋”一词，不妥当；
knowledge翻译为“智慧”可能更好（我个人反对此建议）；
commitment的翻译不准确（先前为“承诺”，后来改为“决心”）。

以上。现征求社群意见。请勿在达成共识前先行修改元维基页面。--碟之舞📀💿 2024年1月11日 (四) 09:09 (UTC)[回复]

完了，为什么当年翻译得这么有诗意的？

囧rz……“can freely share in the sum of all knowledge”对应了“能在知识的海洋中自由分享”。能用约定俗成来解释吗？——Sakamotosan路过围观 | 避免做作，免敬 2024年1月11日 (四) 09:43 (UTC)[回复]

meta那边中文是“direction=next&oldid=5442816”（2013年4月29日），然后类似的本地出现类似句子的Wikipedia:參與貢獻对应“diff=next&oldid=26172630”（2013年4月14日）。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月11日 (四) 09:43 (UTC)[回复]

“commitment”是牛津词典的释义有：

[countable, uncountable] a promise to do something or to behave in a particular way; a promise to support somebody/something; the fact of committing yourself（承诺做某事或以特定方式行事；支持某人/某事的承诺；自己做出承诺的事实）
[uncountable] the desire to work hard and give your energy and time to a job or an activity （努力工作并将精力和时间投入到工作或活动中的愿望）
[countable, usually plural] a thing that you have promised or agreed to do, or that you have to do （你已经承诺或同意做的事情，或者你必须做的事情）
[countable, uncountable] a promise to pay for something, especially regularly; a promise to use resources in order to achieve something （承诺为某事付款，尤其是定期付款；承诺使用资源来实现某事）

很难说语感变化，“决心”（坚定不移的意志）的毅力感好像比“承诺”（应承允诺）强？——Sakamotosan路过围观 | 避免做作，免敬 2024年1月11日 (四) 09:53 (UTC)[回复]

原始句式可能出自老大哥的描述？en:Wikipedia:Prime objective。——Sakamotosan路过围观 | 避免做作，免敬 2024年1月11日 (四) 10:03 (UTC)[回复]

现有翻译符合中文特点无需修改，保留。Python6345（留言） 2024年1月18日 (四) 01:23 (UTC)[回复]

居然有人吐糟「知識的海洋」……突然想起了「比更大還更大」換成「豈止於大」此事。從這一例子可見，有時過份貼近原文在中文會弄出不少笑話。「豈止於大」再直譯成英文也不比「比更大還更大」這句接近原文，亦不能直譯出原文，但哪句較好？。--S叔 2024年1月19日 (五) 11:38 (UTC)[回复]

希望新加坡朋友拍个照

我看到了一张空中拍摄的新加坡旧最高法院和旧政府大厦的照片，拍摄于2011年，如今时过境迁，同一个地方发生了很大的变化，不知道有没有大神再拍个照片。我在这里也发送了请求。-- ⚞︎★⚟︎ 2024年1月15日 (一) 18:00 (UTC)[回复]

@Great Brightstar：這兩張舊最高法院的照片或許適合 1 2 ？--SCP-0000（留言） 2024年1月17日 (三) 14:32 (UTC)[回复]

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

在被迫度过了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)[回复]

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

将赌博列为高风险主题

赌博类内容历来属于垃圾链接重灾区（莊荷、香港丁組足球聯賽隊伍、以色列足球協會）。近日多个用户在足球条目中散布赌球网站链接。请求将广义的赌博定为高风险主题以准许管理员进行与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)[回复]

@@ 第1,100行： / 第1,100行： @@
 ::::::::那個，不好意思冒昧一提，僅提出[[WP:共識]]來說，在這裡提出討論，就是想要得出共識，對吧？而且共識們看來似乎已經有了。所以如果，現在看起來雖不滿意但結果還不錯（閣下還是在這裡也還是可以參與編輯維基百科），誠心建議閣下見好就收不要繼續想要膠帶了，一事歸一事，閣下先前的問題算是解決了也可以這麼說的對吧，過去就過去了，緊抓著過去是沒有辦法到新的未來的。想到前面有幾個糾結過頭的範例，結果都換來永封，這裡就不提了。
 ::::::::另外，如果閣下目前不太明白大家跟您解釋的，把看到的文字消化後重新轉寫出來是什麼呢，要不要先暫停寫條目呢，這麼多的條目可以讀，或許可以看出個分別來，也或許有沒被發現的複製貼上的內容，被您找出來，順便維護清理也是造福社群。等到開悟的那天再來把這些條目重新寫回來，我想也是佳話一樁。--[[User:Mafalda4144|Mafalda4144]]（[[User talk:Mafalda4144|留言]]） 2024年1月18日 (四) 16:14 (UTC)
+:::::::::好的。--[[User:Zheng Zhou|Zheng Zhou]]（[[User talk:Zheng Zhou|留言]]） 2024年1月20日 (六) 13:14 (UTC)
 ::不能认同“對維基百科關於版權的嚴謹性不存在認知”这么大的帽子扣下来，本人的观点，还请阅读[https://zh.wikipedia.org/w/index.php?title=Wikipedia%3A%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%88%2F%E5%85%B6%E4%BB%96&diff=80516158&oldid=80515979 此论述]。“方針從來沒有要求警告必須由管理員發出才算警告，甚至連發出警告也只是「應」，只是建議，而不是要求（「必須」），以此論管理員濫權更是無稽之談”与我对指引的理解有相当大的差异，“应”或“应当”从来都是强制性规定，“只是建议”难道不应该是“可以”吗？正如指引所述，“'''不顧警告'''，多次張貼版權材料的貢獻者'''可以'''由任何管理員加以封禁，以阻止問題進一步產生。如果你懷疑某篇條目侵犯著作權，你'''至少應該'''將問題提交到條目的討論頁。其他人'''可以'''繼續對情形進行檢查，並在需要時採取行動。你所能提供的最有幫助的內容，是你所認為可能是該文字出處的URL鏈接或其他相關引用。”--[[User:Zheng Zhou|Zheng Zhou]]（[[User talk:Zheng Zhou|留言]]） 2024年1月16日 (二) 10:01 (UTC)
 :::{{tq|「應」或「應當」從來都是強制性規定}}一說只證明了閣下的中文不好，{{unping|UjuiUjuMandan}}所寫的[[WP:应不应该]]論述完全足夠說明「應」不是強制性的要求這一點。「內容不能變」不等於內容不構成「抄襲」，因為「內容嚴謹不能變」所以你就可以將大半句複製上去完全就是扭曲規則、強詞奪理。--'''[[U:LuciferianThomas|<span style=color:#b00>路</span>]][[UT:LuciferianThomas|<span style=color:#b00>西</span>]][[Special:用户贡献/LuciferianThomas|<span style=color:#b00>法</span>]][[路西法主義|<span style=color:#b00>人</span>]]''' 2024年1月16日 (二) 10:10 (UTC)