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

互助客棧： 消息  方针  技术  求助  条目探讨  其他 |  知识问答

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

公告欄

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

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

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

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

正在廣泛徵求意見的議題

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

維基專題與協作

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

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

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

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

已通过：

请等待部署，同时请移步后续的讨论。MilkyDefer 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:

1. 鲸类智力
2. 奧斯朋效應
3. 更新世野化
4. 新宿 尼亚加拉瀑布
5. 醫學藥學大學，河内國家大學
6. 詹姆士·赫伯恩
7. 宇都宫聪 -- 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? MilkyDefer 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选择。 --MilkyDefer 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批准制，如何实现尚未研究。猜测是新页面巡查积压、新用户多导致问题更明显。另外，强制该工具创建的页面不在条目空间，我觉得会挺好的，因为创建的页面肯定需要二次修订来保质量。--YFdyh000（留言） 2023年10月18日 (三) 10:53 (UTC)

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

不了解扩展是否有选项，全局JS能做到，自动检测和追加标题前缀。问题是发布流程怎么做，WP:AFC还是允许自行或请求移动，移动后的巡查。--YFdyh000（留言） 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来实现自动，高概率撞过滤器不太合适。--YFdyh000（留言） 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)

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

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

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

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

--MilkyDefer 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也可以，已知能限制和友好提示为什么不能用。--YFdyh000（留言） 2023年10月28日 (六) 03:19 (UTC)

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

---

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

後續工作

於Phabricator查看
編號T349959的工單

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

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

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

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

当前使用机器翻译的体验

我复现不了你所谓的尝试。我录制了影片来证明我的说法。--MilkyDefer 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的初步回應，大體方向依然是推薦調整發布閾值。我認為這個論點應該可以被反駁。 --MilkyDefer 2023年11月28日 (二) 12:30 (UTC)

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

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

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

大家還有什麼別的論點嗎？--MilkyDefer 2023年11月28日 (二) 12:38 (UTC)

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

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

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

我应该说得比较清楚了。--MilkyDefer 2023年11月28日 (二) 17:58 (UTC)

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

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

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

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

--桐生ここ★[讨论] 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%未修改的草稿被阻挡…………应该是合理的才对？--MilkyDefer 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? MilkyDefer 2023年12月9日 (六) 06:15 (UTC)

Sounds sensible. Since it has been stuck for nearly two months with no consensus, let's pass this proposal.@MilkyDefer -Lemonaka 2024年2月24日 (六) 05:23 (UTC)

已經向 wmf 詢問進展了。--SCP-0000（留言） 2024年2月24日 (六) 07:07 (UTC)

@SCP-2000 Got an idea, do you have their email addresses? Bit annoyed for such delay. -‎Lemonaka‎ 2024年3月1日 (五) 08:32 (UTC)

@Lemonaka: I sent an email on Saturday last week. I suppose they are working on other things at the moment and it is not an urgent request, so they haven't replied yet. If they haven't replied by next week, I may send another email to remind them.

You can find their email on their user page. This page also mention how to contact them (language team). Thanks.--SCP-0000（留言） 2024年3月1日 (五) 08:55 (UTC)

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

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

沒有主題的頁面如何評級

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

已通過：

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

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

---

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

@A2569875，附知。--MilkyDefer 2023年12月8日 (五) 09:03 (UTC)

• @MilkyDefer稍微研究了一下，跟本地系統完全不相容，根本不知道怎麼改。他的評級是純粹使用英文字母的，我們是中文，從他目前的模組架構，我看不出來哪邊可以插入本地的評級模式。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月9日 (六) 07:47 (UTC)

  @MilkyDefer既然您提議了，我請求您給出可以執行的方案或建議，謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月9日 (六) 07:49 (UTC)

  那就是我自己按照人家代码的思路重新实现一个类似的咯。上一次的ping模板改版姑且让我熟悉了一点Lua语言。--MilkyDefer 2023年12月9日 (六) 11:24 (UTC)

  原樣照辦英維的codebase要動的手術很大。不過我姑且給你實作了一個長得差不多的在對應沙盒裡面。--MilkyDefer 2023年12月9日 (六) 14:14 (UTC)

  • (：)回應：@MilkyDefer：可是我好像沒看到{{#assessment:}}語法。沒使用{{#assessment:}}的話也無法被系統和各類工具識別，那樣也無法解決我最初提出來的問題啊⋯⋯ -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月10日 (日) 05:09 (UTC)
  • (：)回應：@MilkyDefer：我把{{#assessment:}}加上去了，順便調整一下讓預設（模板預覽）不要顯示錯誤，你看一下這樣適不適當。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月10日 (日) 17:43 (UTC)

    你自己决断。如我前面所述，我的改动只是一个临时性的方案。迟早需要重新规划这一套系统的技术编排，届时现在的变动会被新架构完全覆盖掉。--MilkyDefer 2023年12月10日 (日) 18:22 (UTC)

    • (：)回應：@MilkyDefer：{{WikiProject banner shell}}目前獲WP:模板保護，即使是這個臨時方案也須獲社群共識才得以使用。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 00:05 (UTC)

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

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

• 目前(＋)支持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:Wiki​Project banner shell/​test​cases（評級模板的測試樣例只能放討論頁，不然會有錯誤訊息 囧rz……；首個測試樣例填了GA，所以這裡可以看到這表格最下面「評級」是「優良」，表示新模板有效）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月11日 (一) 12:15 (UTC)
  • 已逾一周無新意見，視為已有初步共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月20日 (三) 13:23 (UTC)
    • 一個小問題，見测试11，若是位於模板空間應修先顯示為模板級。且依據我於Talk:医学測試結果，似乎不符合預期。-- Willy1018（留言） 2023年12月21日 (四) 06:26 (UTC)
      • (？)疑問@Willy1018：Talk:医学測試結果哪邊不合預期？不是都正常顯示甲級嗎，下面也能展開|collapsed=yes預設不展開也正常啊。然後無法理解测试11明明已經指定了，為何要fallback to模板級？指定級別顯然優先於預設級別；未指定本來就該都沒有評級。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月21日 (四) 13:29 (UTC)

        底下：網際網路專題、維基百科專題、機器人學專題，應顯示為A級而不是未評。-- Willy1018（留言） 2023年12月22日 (五) 03:47 (UTC)

        如果本來就是這樣設計的，當我沒說吧。-- Willy1018（留言） 2023年12月22日 (五) 03:48 (UTC)

        @Willy1018：網際網路專題、維基百科專題、機器人學專題的模板又沒有要改版，既然他沒有要改版，那麼那些模板沒有輸入評級他是要怎麼知道評級成什麼？通靈嗎？而且模板參數因技術限制無法跨模板互通，所以也不可能把A級資訊傳遞進模板（實現如此傳遞需要mw:Extension:Variables，萌娘百科有，但中文維基沒有，且相關擴展不相容於目前版本的MediaWiki）。再來，你看User:MilkyDefer的原始提案「 新的模版可以单独给条目一个总体的品质评级[…]也可以搞自己的评级。」這代表各個專題的評級模板是自己搞自己的，每個專題的評級互相獨立並不相干，因此沒有輸入就該維持沒有輸入評級的狀態，本就不應該蹦出沒有輸入卻變成A級的這種狀況。再來「優先顯示模板級」問題肯定也是上方誤會導致的。既然你都說「如果本來就是這樣設計的，當我沒說吧。」了，那麼我就視為異議已排除，可以準備進行公示階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月22日 (五) 04:15 (UTC)

      • @Willy1018：跟您說明一下目前辦理狀況。已建立專門讀取通用評級資訊的模組Module:PJBSClass，目前我用電子遊戲專題測試，測試結果見Talk:皮卡丘的測試結果，在電子遊戲專題模板未輸入評級時，其有確實從外層的{{WikiProject banner shell/sandbox}}讀到|class=Start，你看這是不是你要的，如果是，則還須對Template:WPBannerMeta提編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 02:58 (UTC)

        感謝貢獻，目前已覆核已符合預期。-- Willy1018（留言） 2023年12月24日 (日) 05:17 (UTC)

        • (：)回應：@Willy1018：但要達成您所見到的效果需要第二階段的修改，跟{{WPBannerMeta}}配合。這樣的話，我就視為您對第二階段持(＋)支持態度囉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 08:12 (UTC)

          無異議。-- Willy1018（留言） 2023年12月25日 (一) 04:00 (UTC)

        • 那麼預計的修改方案以及其佈署連結在這了，如果沒有其他異議，就可以準備公示了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 07:55 (UTC)
• 此段落最後發言至今已逾七日，超過一周無新留言，且此前已形成初步共識，因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月1日 (一) 04:04 (UTC)
• 公示7日。公示內容見此-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月1日 (一) 04:04 (UTC)

---

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

---

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

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

第二階段：修改WPBannerMeta

已通過：

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

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

---

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

• 預計將會使用Module:PJBSClass來讀取{{WikiProject banner shell}}模板中的評級，並傳遞給{{WPBannerMeta}}注入進class參數。由於這需要第一階段先通過才有用，故先 擱置，等第一階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 05:15 (UTC)
• 第二階段相關討論Special:PermaLink/80224436#回復通告-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月25日 (一) 02:56 (UTC)

  已覆核，已符合預期，再次感謝您的貢獻。(搬運自Special:PermaLink/80233084)-- Willy1018（留言） 2023年12月25日 (一) 04:02 (UTC)

• 上面的共識是「可以單獨給條目一個總體的品質評級，各個WikiProject可以直接繼承這個quality assessment，也可以搞自己的評級。」，下方Wikipedia:互助客栈/其他#關於基礎條目的額外提議也有多個(＋)支持「對各種專題橫幅不再個別指定 class，而是統一置於{{WPBS}}」的聲音，為了實現上方共識「各個WikiProject可以直接繼承這個quality assessment」以及下方討論的「專題橫幅不再個別指定 class，而是統一置於{{WPBS}}」因此需要在{{WPBannerMeta}}置入讀取{{WPBS}}評級值的模板，以便讓專題橫幅能正確識別統一置於{{WPBS}}的評級，故本修改是必要的，目前已經佈署於電子遊戲專題和多面體專題，運作穩定。如無異議，將會進行公示，進行全面佈署。

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

• 呈上所述，再依據WP:7DAYS，若2024年1月10日 (三) 05:00 (UTC)前沒有其他異議，就視為達成共識，屆時將進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 11:30 (UTC)

  由於上方提案已佈署，因此本配套案亦須佈署，以便同步專題評級行為。編輯請求先放了Template_talk:WPBannerMeta#編輯請求_2024-01-08-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 04:58 (UTC)

相關議案

• 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)

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

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

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

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

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

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

  (～)補充：若這兩個編輯請求（Template_talk:WPBannerMeta#編輯請求_2024-01-08和Template_talk:WPBannerMeta/core#編輯請求_2023-12-28）核准了，記得通知我一聲，我需要在{{多面體專題}}、{{互联网专题}}、{{维基百科专题}}、{{WikiProject Robotics}}和{{WikiProject Portals}}取消佈署，避免重複佈署和{{WPBannerMeta}}及{{WPBannerMeta/core}}相衝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 15:55 (UTC)

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

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

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

---

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

---

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

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

第三階段：完善制度

已通過：

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

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

---

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

1. 若一條目沒有專題或不受任何專題管轄，則其通用評級可填寫任意有被{{WikiProject banner shell}}支援的級別，僅要該條目有達到該級別的標準或滿足該級別的條件，都可以評。
2. 若一條目僅有一個專題，其通用評級應與該專題所評的等級一致。
3. 若一條目有多個專題，通常由機器人自動依照規則4進行評級，但一旦出現爭議時則通用評級應以所有專題都有開設的級別為主。
   • 例如：若一條目有四個專題，而有一個專題沒有開設「丙級列表級」，那麼通用評級就不得填寫「丙級列表級」
4. 對於有多個專題的條目，通用評級應填寫最多專題評的那一等級。
   • 例如有一個條目有四個專題，其中三個專題都評為乙級，但有一個專題評為丙級，則通用評級應填寫乙級。
5. 若在規則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。--MilkyDefer 2024年1月14日 (日) 12:48 (UTC)

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

---

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

---

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

關於基礎條目的額外提議

已通過：

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

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

---

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

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

引入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。 --MilkyDefer 2024年1月14日 (日) 12:53 (UTC)

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

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

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

• @Kanashimi：Module:Vital_articles#L-216基本上就是英文維基的Code，我們已經簡單改enwiki的程式碼來用了，您似乎有所誤會，請自行對照Module:Vital_articles#L-216與en:Module:Banner_shell#L-90。而且您可以看到，本提案預計的作法已經把它下分到Module:Vital_articles去了，並不是像英文維基裡全部整坨塞WPBS模組，故不存在您所提的「可维护性和可读性低」的問題，因為已經分門別類處理了：WPBS處理WPBS的任務、Vital articles處理Vital articles的任務，故上述疑慮不存在，杞人憂天。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 13:14 (UTC)

  是的，所以我想應該不至於有折騰的問題。--Kanashimi（留言） 2024年1月14日 (日) 13:17 (UTC)

• 不同意「剝削這個已經很折磨人的Lua」一說。您似乎保守過頭了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 13:16 (UTC)
• @MilkyDefer：而且一個頁面最多只會放置一個{{WPBS}}或{{Vital article}}，代表該運算始終只會做一次，一個半秒內完成的運算只算一次，是要擔心甚麼效能問題？難道你想塞一萬個{{WPBS}}或{{Vital article}}在討論頁？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 13:20 (UTC)
  • 我們用實際數據來說話吧。Special:PermaLink/80500375這是隨便測試6620個條目進行基礎條目判別，並輸出{{Vital article}}字串。

    這6620個條目全部運算完畢在預覽模式下Lua的後台輸出為：

    • Lua 使用時間：6.375/10.000 秒
    • Lua 記憶體使用狀況：20,669,093/52,428,800位元組

    跑6620次花6.375秒，平均每次基礎條目判斷僅需花費0.00096299093秒，也就是0.96299093毫秒，連1毫秒都不到。記憶體用量則是20,669,093 / 6620 = 3122.2194864，平均每個基礎條目判段僅需3122位元組，3.1kB，而可用的記憶體有52MB那麼多，更不用說這運算只算一次。你總共只需要 0.96 ms、3.12 kB，這甚至比其他很多模組有效率了好嗎。

    一個1毫秒內完成的運算只算一次，是要擔心甚麼效能問題？我實在沒有辦法看出是要擔心哪門子的性能問題。既然一個基礎條目判段只需要不到1毫秒，那我認為你上面的「削这个已经很折磨人的Lua」完全是無稽之談，完全說不過去。Lua本身的目的就是要來降低維基代碼的開銷的，你隨便一個維基代碼解析都可能比我上面那個運算來的久。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 05:28 (UTC)

    • 已逾一周無新留言，因此根據WP:7DAYS，七日無進一步發言視為已達成初步共識；再依據WP:7DAYS「已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決。」上方意見自最後發言起已逾三日無其他回應，因此視為該意見已解決，故將「將{{Vital article}}併入{{WPBS}}的|vital=参数」視為已達成初步共識，預計將使用修改方案以及其佈署連結和測試樣例1、測試樣例2，以及(±)合併{{Vital article}}到{{WPBS}}，來達成這個初步共識。既然依據WP:7DAYS已達成初步共識，那麼將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 05:31 (UTC)

  • 公示7日，公示內容「將{{Vital article}}併入{{WPBS}}的|vital=参数」（同時執行方案①修改方案以及其佈署連結和方案②(±)合併{{基础条目横幅}}及{{Cba/discuss}}到{{WPBS}}（已由修改方案涵蓋）），另見此說明。（註：{{Vital article}}是重定向頁，亦會更改重定向目標）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月22日 (一) 05:31 (UTC)

基礎條目模板合併案公示

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

---

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

{{WikiProject Biography}}參數案

已通過：

公示通過，機器人將開始作業User:Cewbot/log/20200122/configuration。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:40 (UTC)

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

---

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

---

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

---

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

是否廢除{{WikiProject Biography}}原生的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數

待機器人User:Cewbot/log/20200122/configuration清理完所有{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數再開始討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:42 (UTC)

• 機器人User:Cewbot/log/20200122/configuration正在工作中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月20日 (二) 08:21 (UTC)
  • 可以開始討論了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月27日 (二) 06:48 (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)

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

---

「未來級」等級被正確識別（使用沙盒class mask避免被濾掉而實現的）

上方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)

---

• 請管理員依照這則留言佈署相關編輯，也就是編輯以下模板：
  • Module_talk:Class/data#編輯請求_2023-12-28
  • Template_talk:Class_mask/core#編輯請求_2023-12-25
  • Template_talk:Class_mask#編輯請求_2024-01-05
  • Template_talk:Class/colour#編輯請求_2024-01-05

  -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 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)

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

• Template_talk:Classicon#編輯請求_2024-01-16
• Template_talk:WPBannerMeta/core#編輯請求_2023-12-28
• Module_talk:Class/data#編輯請求_2023-12-28
• Template_talk:Class_mask/core#編輯請求_2023-12-25
• Template_talk:Class_mask#編輯請求_2024-01-05
• Template_talk:Class/colour#編輯請求_2024-01-05

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

---

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

---

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

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

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

評級缺失案辦理狀況

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

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

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

• 完成：在本次更新中，以下模板的評級資料已獲同步：
  • Template:评级
  • Module:Class/definition.json
  • Module:Class/data
  • Module:Class/icon
  • Module:Class/styles.css
  • Template:Class/colour
  • Template:Class mask
  • Template:Class mask/core
  • Template:Class mask/table
  • Template:Class mask/templatepage
  • Template:Articles by Quality
  • Template:Articles by Quality/total

  -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 08:55 (UTC)

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

已通過：

公示通過。分類改名涉頁面較多，會再進行公告；而Wikipedia:条目质量评级标准移動到Wikipedia:页面质量评级标准將會立即執行。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:18 (UTC)

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

---

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

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

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

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

沒有意見，但在專題頁面（WikiProject）中使用到的{{Articles by Quality and Importance}}模板應一併解決顯示異常之問題（前幾天似乎還有這問題，現在不知道），雖然這模板平常根本沒什麼人在意 囧rz……（所以沒解決可能也沒差吧？因為專題本來就沒什麼人在意了）--Z7504非常建議必要時多關注評選（留言） 2024年1月18日 (四) 14:26 (UTC)

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

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

• 已逾十日無新發言，根據WP:7DAYS一周無進一步發言視為社群「對以上『已有初步共識』的論述」沒有異議，因此將開始公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月5日 (一) 10:00 (UTC)
• 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月5日 (一) 10:00 (UTC)

  @A2569875：公示期滿，無人反對。Sanmosa _{起視四境　而秦兵又至矣} 2024年2月12日 (一) 13:39 (UTC)

  • 公示期雖滿，但考慮到這將會影響數萬頁面，因此執行前我會再公告此事一周，公告完後再開始執行。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:13 (UTC)

---

• 公示期已過，期內無合理異議，提案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:18 (UTC)

---

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

分類改名準備

雖Special:Diff/80961277已公示通過，但因涉及的頁面眾多，因此宜再進行全站公告。公告完後將進行兩個階段完成：

• 階段1：全保護頁面編輯請求：Template:WPBannerMeta/qualityscale和Template:Class

  由於該等分類都是以上被全保護的模板自動添加的，因此需要執行以上編輯請求。等編輯請求完成後，數萬個頁面緩存自動清理完畢後，分類將自動從「XX級條目」改歸為「XX級頁面」。

• 階段2：正式(►)移动分類頁面（可能是約階段1完成後再過一周）

  等緩存全部清完，再將「XX級條目」分類，逐個(►)移动到「XX級頁面」分類。

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

公告一周。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:31 (UTC)

• 已提出編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月25日 (日) 01:07 (UTC)
  • 編輯請求已由User:Shizhao執行。 等待系統清除緩存。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月27日 (二) 13:22 (UTC)

後續討論

关于 rater.js 脚本

前面的讨论貌似没有涉及到老版本的rater.js脚本（User:Chiefwei/rater aka en:User:Kephir/gadgets/rater）。貌似enwiki那边已经废弃了老版本的rater.js，并且由Evad37推出了新版的rater.js（en:User:Evad37/rater）。我再考虑将新版本引入并做本地化，不知道目前是否已经有类似的工作了？--Ceba_robot 才不是机器人！ 2024年2月16日 (五) 17:57 (UTC)

有見到Ericliu1912和YFdyh000兩版。--Cookai餅塊🍪_{（💬留言）} 2024年2月16日 (五) 18:17 (UTC)

妥了，看起来YFdyh000的目前跟上游已经同步，还是不要做重复工作比较好（--Ceba_robot 才不是机器人！ 2024年2月16日 (五) 18:24 (UTC)

• 目前仍有大量站內頁面連結至User:Chiefwei/rater，建議更新。--Temp3600（留言） 2024年3月3日 (日) 07:57 (UTC)

申報

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

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

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

Account compromised???? -Lemonaka 2024年2月5日 (一) 01:05 (UTC)

不，只是忘了備份密碼（除非這段時間真有人入侵了而我不知）。--捍粵者二（留言） 2024年2月14日 (三) 12:56 (UTC)

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

是，忘了備份。--捍粵者二（留言） 2024年2月14日 (三) 12:53 (UTC)

維基百科有所謂忘記密碼的處理措施。--姓哥名佬字吉拉（渴望長生天的祝福嗎？） 2024年2月22日 (四) 11:57 (UTC)

有绑定email可以找回密码。--桐生ここ★[讨论] 2024年2月22日 (四) 17:09 (UTC)

我是連電郵密碼都沒備份，全都儲在舊機。--捍粵者二（留言） 2024年2月24日 (六) 10:15 (UTC)

斜坡计划的安全补丁

先前讨论：1 2

简易流程图

很抱歉再次提出这个计划来打扰大家。针对先前讨论中各位比较关注的安全问题（政府可能留下门户的访问记录，可以与注册日志一一对应），在下最近想出一个解决办法：门户只发放临时账号，永久账号转发给IPBE授予系统处理。

大致思路是：用户在注册门户注册时，如果希望长期贡献，可以选择注册永久账号。提交申请后，门户提供一个临时账号用于编者即时编辑（可以限制使用时间，如一个月，或者根据ipbe授予的积压情况决定），同时将希望注册的用户名等信息发送给IPBE授予者。这样政府可能留下的访问记录只能对应到临时账号。可以在右侧查看此方案的简易流程图。

如果安全问题能够解决，我觉得应该不会有太大的阻碍，希望这次能够达到实行此计划的共识。谢谢各位。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月15日 (四) 11:39 (UTC)

没看懂。是自动发放一次性账号？怎么避免滥用。如何使门户可信。用户贡献归属等需求。注册日志时间问题，随机延迟不就行了，不过我觉得意义不大，因为访客数量有限、网络特征公开。--YFdyh000（留言） 2024年2月15日 (四) 16:37 (UTC)

如果門戶是維基媒體基金會的網站，不存在什麼可信不可信。用戶貢獻歸屬，新用戶會在意這個？別人只想編輯。滥用這個詞太抽象，不知道你指的是什麼，最好說明一下更具體的情況。--日期20220626（留言） 2024年2月15日 (四) 17:00 (UTC)

1. 不看好基金会为此系统投入和有效地得出成果。这还不如研发与优化开放代理与反破坏机制的关系，使通过代理的注册和编辑更可见和可控（Tag/每笔人机验证/反破坏更敏感/二次审核，等等），将有益全域。
2. 如果有用户声称自己用了门户但出事，是门户的问题（运维或网络特征），还是其他问题，如何解决信任危机。
3. 会的，并且牵扯到傀儡判定、条目主编者等问题。
4. 不太懂这样做对隐藏身份的意义，IP连接有日志，使用门户在特定时点做出收发（及对应流量特征）反而范围很小。
5. 创建临时账号非人工审查，LTA可以用完就扔，未见反破坏机制，人工审封IP不太可靠、会误伤。
6. 如果门户是为保障时间点隐私，就不宜支持即时提交编辑。

--YFdyh000（留言） 2024年2月15日 (四) 19:28 (UTC)

1. 「研发与优化开放代理与反破坏机制的关系」，基金會這方面有什麼動作嗎？沒有吧。談一個不存在的事情有什麼意思。我就是顧慮基金會的人可能會比較懶，不會特地去為了中維去開發這麼一個門戶。
2. 那你等有人真的用了門戶出事情再說，不要自己去憑空臆測。本來就有人因為翻墻上維基百科被抓[1]，說明翻墻上維基百科本身就有一定風險，也沒見基金會出來說要保護或者出面去介入。
3. 傀儡判定，之前討論說允許把本地IP提供給查核員，這個可以再討論一下。不過本身在不用翻墻的地區，傀儡就可以隨意創建賬號登入編輯。非大陸地區的LTA本身就會用完賬號就扔。你看影武者都有多少賬號了。這個門戶主要面對新用戶的，新用戶不會想到条目主编者這一層面。你10年前剛編輯的時候你會考慮這個？

--日期20220626（留言） 2024年2月16日 (五) 05:23 (UTC)

1. 从基金会的开发效率及意愿来说，我倾向不让基金会做这个。维基人做这个又有信任度问题。2. 提议中的临时账号就是为了所谓安全，如果无所谓，IPBE申请表单系统就足够了——维基人可以帮忙。3. 如果临时账号提交一份条目，注册账号编修，或者多个临时账号编写，DYKC主编、傀儡活动怎么算。注册时间隐藏，听上去需要提前注册储备一些临时账号。如果是先用后审，似乎没意义啊。--YFdyh000（留言） 2024年2月17日 (六) 05:11 (UTC)

3. 临时账号的用户名应该有特定规律，视作因为隐私问题而不公开披露sockpuppeteer的分身账号。临时账号的注册时间不隐藏，门户界面告知使用有安全风险。如果编辑不敏感的条目或者头铁的自然承担风险就是。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:34 (UTC)

补充，我的临时账号想法是IPBE申请系统自动/半自动创建所请求账号，限制有效时长和编辑次数，超出有警告与自动封禁/剥夺IPBE，配合过滤器自动封禁，之后人工审核和批准永久IPBE（类似WP:AFC）。这之前讲过。我的想法中IP验证并非必选项，甚至不考虑，但如何避免傀儡反复注册，暂时只想到人机验证；答题可选；网页版工作量证明也许会有帮助。--YFdyh000（留言） 2024年2月17日 (六) 05:22 (UTC)

这样甚至比现行IPBE还严格，要知道目前IPBE授予和自动授予没有太大的区别，如果我没搞错的话，如果填写正确且用户名不是明显破坏者的话都会给过。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:36 (UTC)

目前问题是处理时延太久，而我的提议为人机校验（及其他自动检测）后先发后审但限制编辑能力（次数和范围），是否永久批准仍是传统流程。--YFdyh000（留言） 2024年2月17日 (六) 05:48 (UTC)

誰會用這個門戶？當然是新用戶和一些圖謀開傀儡的被封的賬戶。如果這一門戶機制不影響查傀儡的話問題不大。--日期20220626（留言） 2024年2月16日 (五) 05:30 (UTC)

4. 永久账号给IPBEG发，和门户就没关系了，也无法通过门户来精准索敌 5. 同日期君。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:32 (UTC)

防滥用措施的可行方案已经写在用户页上，譬如设置管理员、封禁开放代理、同步封禁列表等手段。不清楚门户可信是什么意思，这个系统应该不会处理敏感信息，可以建议开发者开源。署名问题可以提前在注册页告知，临时账号事实上相当于IP用户，也没人关心IP用户或者IP masking的临时账户怎么署名啊。随机延迟可能有用户名撞名的问题，其实解决这个问题也行() ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:28 (UTC)

门户只是申请表单的话，我之前可能想错。临时账号统一命名、提前注册，永久账号等待审核，可能不需延迟。总感觉以IP为IPBE信任元素，很容易滥用，不过非开放代理似乎能达成相同目的。--YFdyh000（留言） 2024年2月17日 (六) 06:07 (UTC)

@魔琴、YFdyh000、日期20220626：請問考不考慮讓這討論改走RFC機制？Sanmosa _{起視四境　秦兵又至} 2024年2月16日 (五) 06:40 (UTC)

我無所謂。--日期20220626（留言） 2024年2月16日 (五) 06:42 (UTC)

太多想法未确定，为免含糊的支持/反对，目前倾向不要。--YFdyh000（留言） 2024年2月17日 (六) 05:12 (UTC)

IPBE授予員討論尚主要涉及權限方針修訂，這個初步概念應該VPO討論吧。--路西法人 2024年2月17日 (六) 06:19 (UTC)

前幾次討論都是在其他區；此案目前尚未涉及實際方針與指引修訂。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月17日 (六) 07:30 (UTC)

這樣的話，考慮到VPP這裏的長度問題已經比以前改善不少了，那就不一定要搬了。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年2月17日 (六) 08:50 (UTC)

已移动到VPO ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 09:36 (UTC)

认为应该在易于申请、保护隐私和反破坏中寻求平衡。这应该是一个排序题，而不是选择题。

应该如何给申请人分发临时账户，又该如何收回？我建议使用一个独立的表单，让用户提交要发送的代码和延时时长，以达到编辑目的。

这个提案不同于大部分讨论，是在商议软件需求。我们不能写一个复杂而模糊的需求难为开发人员，所以我们要把所有细节敲定了，再和开发人员提出。考虑到本地实际，这必然需要长久的讨论，因此提案人不必担心重复提出。

( π )题外话如若通过，可否将IPBE授予系统一并开发？--落花有意12138 2024年2月17日 (六) 15:51 (UTC)

临时账号我倾向一次性而不是回收再利用，避免贡献混淆。预先批量申请，通过时发放账号密码。延时注册是可选需求，如果IPBE永久授权依旧很费时、批次授予，可能无所谓。如果只是要验证IP，可以将验证模块站点独立出来，也不需要将申请表单放在上面，直接一个附令牌的网址访问、自动检查风险（建议搭配人机验证）、确认，原网页/邮件系统发放账号密码就可以了，这样验证站点只获得了令牌和访客IP信息。未理解“IPBE授予系统”，除了风险检查机制，授予系统是否只是一个表单管理系统。--YFdyh000（留言） 2024年2月17日 (六) 16:08 (UTC)

如果临时账户不收回为什么不直接把临时账户改名？

认为单设验证站点可行。--落花有意12138 2024年2月19日 (一) 11:34 (UTC)

用户更名的复杂度好像较高，比如可能涉及全域账户？最低复杂度就是立即创建+有条件IPBE吧。--YFdyh000（留言） 2024年2月19日 (一) 12:28 (UTC)

其實社群可自行開發，並非必須交由基金會開發（例如本站不少小工具就是由社群開發的），更何況基金會資源及人手有限，也不太可能幫助本站開發這規模的系統。謝謝。--SCP-0000（留言） 2024年2月17日 (六) 16:33 (UTC)

非常同意。但该计划意图以中国大陆用户IP地址为认证手段，且需要经常维护（反LTA），并从IPBE与NDA保密条款的近期讨论风向来看，我觉得较难有符合信任条件的维基人参与运维建设。--YFdyh000（留言） 2024年2月17日 (六) 16:51 (UTC)

“临时账户”和“永久账户”这个概念还是太新颖了。如果用类似IP Masking的机制的话，是不是需要基金会或者其他技术上的配合（IP Masking好像是准备预留一个用户名前缀）？另外始终无法解决庙的问题：放外面，域名地址维护成本（“游击战”对抗）和可用性维护难以维持，甚至可能扩大损害（更多地址被黑洞）；放里面，有信任风险。临时账户这个概念和现在IP用户机制类似，可能增加条目质量沟通成本。或者退而求其次：门户用于地址验证和提交邮箱地址（等联系方式）申请，然后管理员在门户管理后台审阅并代申请后回发（本来就有代创建账户，并通过邮箱回发的机制）；这样的可行性可以观望，虽然仍然有庙的问题。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 06:07 (UTC)

1. 不需要，设定统一的用户名前缀及过滤器避免外人注册即可。2. 如前所述，表单等放在需代理的页面，可以仅将IP与人机验证页面放在小型VPS上（及用容器快速部署）、结果回传主服务器，域名不清楚能否免费或直接用IP+证书，证书用免费的。3. 沟通成本，暂未考虑，其他匿名用户一样的。4. 只有地址验证需要门户，表单、管理等系统都可以独立设置。--YFdyh000（留言） 2024年2月18日 (日) 08:38 (UTC)

所以就是庙的问题：这样的门户注册机制真的要搞成打游击模式？或者简单来说，我非常不看好这样的计划。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 08:52 (UTC)

另外，“临时账号”这个机制我认为就是画蛇添足，可以考虑给这类申请的账户“永久化”并分发一个短期的LIPE（参照现行的不活跃机制的话，6个月为建议上限），同时可以增发一份提醒，可以通过“锻炼”编辑的方式，积累有助于判断申请用户编辑长期性的好感，临期时允许申请延长LIPE，可以进一步提升上限。这样可以减少引入更多不必要的技术性改动。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 08:59 (UTC)

在WMF站下搞什么东西都逃不过庙的问题，也许确实该考虑与第三方网站合作？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 14:02 (UTC)

WMF大概不會喜歡社群自己搞工具還將個資放第三方網站，最終出了什麼事也難以追責。--路西法人 2024年2月28日 (三) 14:54 (UTC)

en的en:Wikipedia:Unblock_Ticket_Request_System其实可以一定程度上充当这类账户申请和封锁接触申请的门户，甚至不同部署方式主要业务功能也可以面向不同（放里面，只保留账户申请登记和地址信息查验，不添加项目用户登录绑定来实现项目权限功能联动，就是一个简易的账户申请系统；放外面，加上项目用户登录实现权限功能联动，可以不保留账户申请登记，就是UTRS+），当然问题是，谁写或者引进改造这套系统。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 06:36 (UTC)

印象里英文那套系统未设计本地化支持，改造可能费时费力、对目前缺乏帮助——只是一个表单管理系统。--YFdyh000（留言） 2024年2月18日 (日) 08:40 (UTC)

UTRS可以参考想法，而不只是实现，实际上现在申请门户系统就是上面描述的类似设计思路。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月18日 (日) 08:59 (UTC)

引進做處理用途似乎可以？--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 17:52 (UTC)

還有OAuth還是有必要的。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 18:16 (UTC)

這裡還是副知一下@Bluedeck。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月19日 (一) 08:43 (UTC)

參考英維做法，VPO也是可以掛RFC的，既然也是要增加曝光度，不防也掛上RFC來嘗試讓更多人看到這個討論？不過RFC仍在早期運作，效果大概不大就是了。--路西法人 2024年2月26日 (一) 00:47 (UTC)

谢谢ping，确实是我很感兴趣的话题。Bluedeck 2024年3月3日 (日) 01:44 (UTC)

有人僞造特定兒少模特經歷作宣傳

提醒：以下全部外部連結都經中國大陸公安備案。

在王子逸#作品名录，89.105.216.240加入所謂王子逸編導，章子怡、杜卡妮、刘思慕、奥卡菲娜、陈法拉、赵淑珍、张梦儿、吴京、梁朝伟演出的中美合拍华语片（Special:diff/81360867）；43.229.54.130則加入所謂王子逸編導，章子怡、刘潇文、刘潆文、奥卡菲娜、赵淑珍演出的华语片《是妈妈是女儿》（Special:diff/76622913）。在英皇電影#電影製作及發行，43.239.67.227加入相似内容（Special:diff/76464207）；38.60.125.225將《是媽媽是女兒》—劉瀟文、劉瀠文改爲《小曉》—杜卡妮、劉思慕、陳法拉、吳京、梁朝偉、谷愛凌（Special:diff/80452154）；103.123.132.10加入所謂烏爾善執導，杜卡妮、武若茗、趙婉瑜、林品彤、楊紫瓊演出的《亞特蘭蒂斯：深海之旅》（Special:diff/81203173）。

以上有關資訊只見於同一bilibili用戶（bili_86837699730：[2][3]）。在此用戶衆多説法中，杜卡妮、刘潇文、刘潆文、武若茗、赵婉瑜等字眼經常成對出現：[4][5][6][7]），在其杜卡妮小档案宣稱杜卡妮的好友是「武若茗、赵婉瑜、徐书元、章孙游侑、周悦希、周悦含、安香怡、孟筠棠等」。其他來源則稱刘潇文、刘潆文是雙胞胎模特，據稱與杜卡妮都是兒少模特。不過有趣的是，當局官媒曾在2022年2月不止一次報道六年級學生杜卡妮檢驗核酸、當臨演捧鴿子，而同月203.95.195.145在中国人民大学附属中学加入「杜卡妮，中国女演员，北京冬奥会开幕式演员，2022级」（Special:diff/70260365），203.95.195.145要麽在其六年級時就預計杜升入中国人民大学附属中学而應屬其關聯人士，要麽是在胡説八道，但都與bili_86837699730在2023年6月發佈的杜卡妮小档案所稱「中学：北京实验学校（海淀）、北京101中学」不符。

在2020年亞洲沙灘運動會，154.207.66.65加入所謂常石磊作曲，杜卡妮、刘潇文、刘潆文演唱的亚洲沙滩运动会会歌《In Sanya》（Special:diff/69655574）；43.239.85.152改「杜卡妮、刘潇文、刘潆文演唱」為「杜卡妮、武若茗演唱」（Special:diff/73427801）。在第33届中国电影金鸡奖#表演节目，43.239.85.173加入刘潇文、刘潆文（Special:diff/62945470，對比[8]）。在卡酷少儿卫视#自制剧，43.239.67.226、43.229.54.130、43.239.85.166接連加入所謂杜卡妮、武若茗、赵婉瑜、田雨、热依扎、丁勇岱、王志飞、蔡文静、鲍起静、宋春丽、颜丙燕、谭凯、于毅等演出的《海岛》（Special:diff/75483696/77048044，對比[9][10]）。在葉鎮輝，38.60.125.225加入所謂李乃文、王雷、颜丙燕、周洁琼……杜卡妮、武若茗、赵婉瑜、周悦希、周悦含演出的《跨栏女将》（Special:diff/80452065，對比[11][12][13]）。在中国电视剧制作中心，38.60.125.225又加入《跨栏女将》（Special:diff/80451977）。

以上調查並未窮盡。建議將杜卡妮、刘潇文、刘潆文、武若茗等字詞加入過濾器。--— Gohan 2024年2月21日 (三) 04:40 (UTC)

上述有点复杂。意思是水晶球、缺少来源的宣传信息吗。In Sanya找不到来源，真实吗。《海岛》也找不到信息，B站中称（京）剧审字（2023）第038号，在2023年一到四季度的《国产电视剧发行许可证》目录中找不到，一季度[14]北京局批准不多，不太可能颁发038号并按文章所说日期上线，北京局最后批的是026号[15]。--YFdyh000（留言） 2024年2月21日 (三) 11:11 (UTC)

不止是水晶球，非憑空捏造即移花接木的摻假捏造。--— Gohan 2024年2月23日 (五) 04:26 (UTC)

Old news，Wikipedia:持续出没的破坏者/User:Kzl19910116。--路西法人 2024年2月23日 (五) 04:17 (UTC)

2020年的Special:diff/62945470未被查出。這個明目張膽的bilibili賬戶亦未提及，完全可以按圖索驥。--— Gohan 2024年2月23日 (五) 04:29 (UTC)

那就可資歸檔了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月25日 (日) 16:48 (UTC)

已被全域禁制的用户的用户主页可以加离世模板吗？

之前OA2021被封禁的游魂于今晨自杀离世，可以给他的用户页加那个离世模板吗？--本次为您服务的是魔女 2024年2月28日 (三) 07:31 (UTC)

ping一下管理员，然后说明一下来源，让管理员裁量处理？——Sakamotosan路过围观 | 避免做作，免敬 2024年2月28日 (三) 09:35 (UTC)

樓主或為是人生前好友，需要嗎？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 10:24 (UTC)

消息可靠？--在下荷花，请多指教（欢迎签到） 2024年2月28日 (三) 10:27 (UTC)

？您是否有更多证据来证实该表述？无意冒犯，只是这件事情实在是... 太突然了，并且影响很大。--BureibuNeko 2024年2月28日 (三) 10:36 (UTC)

是（--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 11:26 (UTC)

---

他去不去世不重要，他就算沒有去世也不能編輯你維，他去世了也不需要幫他立碑。請不要重開此討論，此討論明顯已準備踩WMF禁止編輯維基百科相關條款的邊界，謝謝。--SunAfterRain 2024年2月28日 (三) 11:41 (UTC)

正經而言，離世模板通常可授予對本站有卓著貢獻，並鞠躬盡瘁之維基人。全域禁制者多難保晚節，而不甚符合此等要求。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月28日 (三) 12:14 (UTC)

虽然但是{{death}}的doc无此规定……您指的应该是将ta加入WP:RIP吧，{{death}}我觉得真死了应该加。--忒有钱 凪のあすから 10th Anniversary（留言） 2024年2月28日 (三) 13:45 (UTC)

1.可能二者都有 2.我覺得您應該在讀一次Eric的發言 3.WP:RIP需要個人信息可能要問魔女（其為伴侶）下，還有家屬願不願意個人信息披露是問題（顯然不可能）。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 13:51 (UTC)

我觉得{{death}}真死了就可以加，哪怕是LTA（而且翻看ta的编辑其也显然不是LTA，被禁制前所作出的编辑是正向编辑），但像ta这样被禁制的人确实不应该加入WP:RIP。综上，我认为{{death}}应该挂（只要这不违反WMF有关基金会禁制的规定），但WP:RIP没有必要加。--忒有钱 凪のあすから 10th Anniversary（留言） 2024年2月28日 (三) 14:20 (UTC)

那就變成請求編輯了，要不問基金會CA？--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 14:28 (UTC)

但是OA21有沒有做什麽我難以評價（--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 14:39 (UTC)

游魂生前厌恶个人影响力，不会希望进什么RIP，而且按RIP的标准他也远远不算，所以和这个应该是完全没有关系，我只是问要不要加个death--本次为您服务的是魔女 2024年2月28日 (三) 16:48 (UTC)

我覺得您還是發郵件問下基金會CA如何？--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 16:54 (UTC)

我现在肯定是没有精力行文发这种邮件的……--本次为您服务的是魔女 2024年2月28日 (三) 22:48 (UTC)

(＊)提醒 ：「是（」為基於現有内容深表遺憾之義。請勿過度理解含義（尚未獲取更多訊息），息止安所、User:游魂。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 12:39 (UTC)

貼出現有信息[16] [17][18]--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 14:17 (UTC)

(！)抗议 何来的「此讨论明显已准备踩WMF禁止编辑维基百科相关条款的边界」，讨论放不放模板而已，何来的踩边界？踩了谁规定的边界？你规定的边界？--阿卡林阿卡林了 维基已死 2024年2月28日 (三) 14:06 (UTC)

不要激动嘛 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 14:41 (UTC)

附议，非常反对这种唯oa2021马首是瞻、见wmc就堵嘴的行为，完全不是正常的讨论流程。楼上说“不要激动”，我觉得这句话更适用在随便关讨论的人身上--—远方传来风笛（Talk） 2024年2月28日 (三) 15:18 (UTC)

那么请您去找WMF反映意见吧。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年2月29日 (四) 04:39 (UTC)

勸過他了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月28日 (三) 16:14 (UTC)

（编辑冲突）“此讨论明显已准备踩WMF禁止编辑维基百科相关条款的边界”，全域禁制条款只说被禁制人不得通过他人间接参与编辑，已经去世的人无法通过他人间接参与编辑（除非有遗嘱，不过这个讨论根本不像是这样子） ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 14:07 (UTC)

看起來是突然逝世，遺囑是沒有的（在這種情況下）。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 14:47 (UTC)

嗯……給國安工作？所以在基金會行動之前，傳出QQ群組裡面說要「將香港用戶組都（向國安處）舉報了吧。」這件事，其實是想要來真的？--KOKUYO（留言） 2024年2月28日 (三) 14:53 (UTC)

我突然想起幾年前好像還有一個傳聞，是遊魂和其他幾個人好像是在北京、南京還是哪裡，一起把一名維基百科用戶包圍起來威脅威脅。這個看到傳聞時也不知是真是假，畢竟正常維基人理應好好貢獻條目，不可能會跟著一群人當面威脅其他用戶吧。--KOKUYO（留言） 2024年2月28日 (三) 15:48 (UTC)

假的，我用游魂生前跟我说的话来说，国安只是个做生意的地方，能赚钱的事情国安才敢兴趣，橄榄只是去橄榄阻碍赚钱的反对者而已，当然，国安的赚钱和我们一般理解的也不那么一样，很阴暗--本次为您服务的是魔女 2024年2月28日 (三) 16:46 (UTC)

您是說哪一個是假的，是前面有人在QQ群組發言說「將香港使用者群組都（向國安處）舉報了吧。」這件事是假的，還是後面遊魂和其他維基人威脅某一位用戶這件事情是假的？--KOKUYO（留言） 2024年2月28日 (三) 16:51 (UTC)

游魂个人的政治立场和我有共鸣（不是说真的完全一样但是总之都可以算某三国杀身份），你觉得游魂能干出后面这种事吗？前面那个也是假的原因我已经解释过了--本次为您服务的是魔女 2024年2月28日 (三) 16:55 (UTC)

魔女君回复的是您说国安的问题把。香港国安举报事件游魂君应该没有参与其中，本质上就是WalterGrassroot君不知轻重地口嗨，事后还死不承认拉着一群人给他擦屁股。很难说像是要来真的一样。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 18:34 (UTC)

不過看起來為北京市國家安全局做線人屬實了。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月29日 (四) 03:27 (UTC)

这个不完全属实，游魂可能曾经某一时刻试过为北京国安做线人，但是双方最终并没能建立起互信和合作--本次为您服务的是魔女 2024年2月29日 (四) 09:50 (UTC)

他試過在哪一方面做綫人？維基社群嗎？--— Gohan 2024年2月29日 (四) 14:45 (UTC)

有過聯係的維基人（通過中國社交平臺或者留下信息者）都可能有風險。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年3月2日 (六) 06:07 (UTC)

啊，虽然但是所以你说的这个和当前的讨论有什么关系吗--SEX！ 2024年2月28日 (三) 16:52 (UTC)

模板裡面「讓我們永遠『緬懷』他/她」的意思，應該是讓大家一起懷念、追思一位有正面貢獻的人吧，那麼處理逝者的問題不就有必要性？還是您的意思是，假若用戶A曾在維基聚會後毆打他人、恐嚇勒索，只要用戶A有在維基百科寫了幾篇優良條目，維基百科社群就應該鼓勵大家緬懷他？--KOKUYO（留言） 2024年2月28日 (三) 17:19 (UTC)

又舉極端點的例子，例如某用戶在維基聚會上一時衝動強姦女童、鬥毆殺人，在事後自行了結生命，只要那人在維基百科有正常活躍，就可以說要給生命最起碼的尊重，所以在用戶頁上放上寫著「讓我們永遠『緬懷』他/她」的模板？--KOKUYO（留言） 2024年2月28日 (三) 17:28 (UTC)

谁提出谁举证。请您举出此人真的有做过线下暴力的证据；如无，请勿在此侮辱死者，谢谢。--—远方传来风笛（Talk） 2024年2月28日 (三) 17:34 (UTC)

之前不是有批錄音檔，裡面有某位同樣被基金會禁制的用戶向其他人說，自己先前找了遊魂還有另一人，在北京聚會結束後一起找上某位用戶威脅。還是您的意思是這並非線下暴力，屬於正常編輯行為的一部分？--KOKUYO（留言） 2024年2月28日 (三) 20:41 (UTC)

证据就是闫主席的讲话啊。闫主席给WMC小朋友宣扬他们可以用武力威胁让他们看不惯的中国维基人闭嘴，你不知道吗？闫主席说的游魂跟他一起去武力威胁人了。我后来为了谨慎起见还在站内问过他闫主席说的那件事是否属实，结果他说武力威胁人的事他做过，但不确定闫说的那件他做没做。你觉得正常然应该怎么做判断呢？ --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年2月29日 (四) 04:42 (UTC)

这我只能说到这么具体的事情，我好像隐约记得游魂讲过一些个中底细，但是我记不太确切了，本来提到这个具体的事情我可以再问问游魂，但现在这么说已经是一种地狱笑话了。--本次为您服务的是魔女 2024年2月29日 (四) 09:55 (UTC)

问题就在于他从来没有在站内或者其他公开场合说过他没做那种事，依据目前有的证据，只能认为他做过。不然的话我也猜不到WMC为什么会处理他。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 01:06 (UTC)

多大点事，把{{death}}内容改了，去掉缅怀改成“逝者安息”什么的多好。“让我们永远缅怀他/她”看起来也不是很中文。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 18:36 (UTC)

User:机械故障中使用的{{Deceased Wikipedian}}看上去足够中性，我觉得完全可以。--YFdyh000（留言） 2024年2月29日 (四) 01:04 (UTC)

(－)反对所有拿OA2021说事的人，我认为既然其生前在中文维基有活跃且有正常贡献（据我所知其促成了数个GA），就可以使用death模板。生死为大，请各位给予逝去的生命最起码的尊重。—远方传来风笛（Talk） 2024年2月28日 (三) 15:13 (UTC)

补一句：“他去不去世不重要”一类的言论令我感到不寒而栗。—远方传来风笛（Talk） 2024年2月28日 (三) 17:07 (UTC)

他去不去世对维基百科来说不重要。懂了吗？对你重要的话你去可以自己纪念。不要拿你自己的情感去绑架别人，至于你栗不栗也是你自己的事，而不是维基百科社群的事。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年2月29日 (四) 04:47 (UTC)

是个人肯定哪一天都要去世，但不是所有维基人去世的消息都能传到维基百科社群这里，就算传到这里来，除非消息源是第三方可靠来源（因为公信力摆在那里），否则从其他人那边传来的消息总是有人要去怀疑真实性的，因此，“去不去世不重要”的话也许说出来难听，但仍旧是合理存在的。--🔨（留言） 2024年2月29日 (四) 13:33 (UTC)

是，现在的消息是已经火化。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年3月2日 (六) 09:16 (UTC)

++ ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 15:20 (UTC)

扯一句，警方介入了。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 15:23 (UTC)

還有作爲OA21的事情可以考慮另起討論。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 15:25 (UTC)

介入原因可能是不涉及本站的刑事案件(非法销售药品)--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 15:32 (UTC)

看來不是（--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月29日 (四) 02:37 (UTC)

( ✓ )同意，人死为大。但是WP:RIP一般收录知名已故维基人，所以RIP我觉得没必要加。--忒有钱 凪のあすから 10th Anniversary（留言） 2024年2月28日 (三) 15:25 (UTC)

已經有人發死亡證明了[19]。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 15:28 (UTC)

具體連結：死亡證明書、派出所發出的情況説明。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年2月29日 (四) 15:16 (UTC)

死亡證明圖片適合做來源嘛？（現在的問題）--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 15:48 (UTC)

(＋)支持挂death模版但WP:RIP不收录。—-Aggie Dewadipper 2024年2月29日 (四) 23:22 (UTC)

全域禁制使用者在本站的使用者頁面一律只有一個{{WMF-legal banned user}}，不會有其他內容吧？ 紺野夢人 2024年2月28日 (三) 15:42 (UTC)

是，所以問題是進不進RIP了？--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 15:57 (UTC)

維基百科:已经去世的用户的當前版本說「本頁面主要記載有可靠來源查證的已故中文維基百科編輯人員」，不過該頁面並非方針或指引，要添加的話似乎不必過於拘泥。--紺野夢人 2024年2月28日 (三) 16:08 (UTC)

是，現在是來源問題--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 16:14 (UTC)

“可供查证”是前年加的（版本72307070），要求太苛刻了点，谁会去报导哪个维基人逝世了？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 18:38 (UTC)

不知道是否有人已经在问基金会了，个人认为加不加模板基金会说了算基金会同意加就加不同意就维持原样。--🔨（留言） 2024年2月28日 (三) 16:02 (UTC)

不過這樣成功是否會導致WP:MEMORIAL?--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 16:08 (UTC)

還是請進RIP好些...--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 16:10 (UTC)

初版：--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 16:24 (UTC)

@HualinXMN：算开盒了 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月28日 (三) 18:43 (UTC)

啊這--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月29日 (四) 02:03 (UTC)

已提請G10--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月29日 (四) 02:33 (UTC)

游魂自己都不喜欢自己有个人影响力，而且他也配不上进RIP--本次为您服务的是魔女 2024年2月28日 (三) 16:52 (UTC)

挂个{{death}}应该不至于吧。--沈澄心✉ 2024年2月28日 (三) 16:31 (UTC)

主要是本站第一次遇到這種情況...--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 16:37 (UTC)

所以说LTA去世的事也没发生过是吧？--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年2月29日 (四) 04:53 (UTC)

啊……我是说WP:MEMORIAL（--沈澄心✉ 2024年2月29日 (四) 05:16 (UTC)

???这个又不是条目空间，和WP:MEMORIAL有啥关系。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年2月29日 (四) 06:07 (UTC)

MEMORIAL第一节讲用户空间，第二节讲File空间，第三节说私人领域，怎么看怎么不像和条目空间有关的样子 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月29日 (四) 07:25 (UTC)

您抬杠也不是这么抬的。如果您平时就这么所谓“讨论”的话我觉得您可能不适合在维基百科讨论问题。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年2月29日 (四) 11:39 (UTC)

那四条，第一条说的是在自己的用户空间做宣传，但其人如果已经不在了，当然不能在他自己的用户空间做宣传；第二条说的是文件没错，但也不对题吧？有人说要放文件了吗？第三条是用户空间，但也不对题。第四条对题，说的可不就是条目空间吗？你是没有阅读能力还是故意来扰乱的？而且如果你参看英文维基百科，你会知道只有第四条才是真正的WP:MEMORIAL。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年2月29日 (四) 11:43 (UTC)

@魔琴：第四条不就有关了吗？--绍🌟煦·集思广益 2024年3月1日 (五) 00:14 (UTC)

然 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月1日 (五) 08:12 (UTC)

不认为需要基金会决定。消息确切就{{Deceased Wikipedian}}注记一下，就可以了吧。--YFdyh000（留言） 2024年2月29日 (四) 01:05 (UTC)

这个人已经不是Wikipedian了。所以不能用。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年2月29日 (四) 06:08 (UTC)

那么严谨的吗。有证据表明溯及过往的身份除名？而且那样，永久退出（退休）的维基人就不能称呼（曾）是维基人了吗。再以及，使模板改称“这位维基用户”，就不涉及维基人概念了。--YFdyh000（留言） 2024年2月29日 (四) 07:55 (UTC)

我也感覺把用詞改為「此用戶」即可規避問題。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年2月29日 (四) 08:00 (UTC)

这人已经不是维基人了。这是现在的事，和过往没关系。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年2月29日 (四) 11:40 (UTC)

WP:维基人里只说了维基人是为维基百科编写条目的人，好像没有说被永封了就会维基人间失格来着。你看他用户页分类都是“​被维基媒体基金会封禁的维基人”对吧--SEX！ 2024年2月29日 (四) 15:09 (UTC)

你居然妄图跟他讲道理……--—远方传来风笛（Talk） 2024年2月29日 (四) 17:29 (UTC)

又开始仗着愚蠢来进行人身攻击了。您也真是够恶心的。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 01:09 (UTC)

@Kiraclyne：既然游魂已经被Global banned了，那也就表明他已经无法为维基百科编写条目了，所以自然也就不是wikipedian了啊。--绍🌟煦·集思广益 2024年2月29日 (四) 23:34 (UTC)

他是被禁止为维基百科编写条目的人。当然就不是维基人了。他的用户存在、他过去的贡献存在，所以他曾经是维基人这件事是事实，没有争议。但OA2021以后他这个人就不再是维基人了。如果OA2021里被处理的人在OA2021被执行之前就去世了，还可以说这个人去世的时候仍然是维基人。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 01:08 (UTC)

“既然游魂已经被Global banned了，那也就表明他已经无法为维基百科编写条目了”照这么说死人也无法为维基百科编写条目，建议直接删除Deceased Wikipedian模板。按我的理解只要一个人为维基百科有过贡献做过编辑就可以称作维基人，在这方面强硬钻牛角尖没有意义。

“OA2021以后他这个人就不再是维基人了”是谁下的定义，维基皇帝吗？--SEX！ 2024年3月1日 (五) 02:57 (UTC)

游魂对维基百科社群的贡献是负的。当然了如果您愿意，您可以论述一下这人的贡献具体是啥。相信您并没真正考虑过这问题。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:01 (UTC)

我对您所谓“维基百科社群”的互联网边缘人小团体没有任何兴趣，我在前面也没有提到过狗气球君您那皇恩浩荡的社群，还请不要偷换概念。单对维基百科的条目而言，我甚至认为他最后一次在原味内裤条目的编辑说不定也能算是一个贡献。--SEX！ 2024年3月1日 (五) 20:34 (UTC)

死人当然和被Global banned（下文为表述方便简称GBN）的前维基人有区别，因为死人只是死人，和被GBN的人当然不是一个概念。所以当然不一定是同时被GBN的人。所以死人当然不能和被GBN的人等量齐观，懂了吗？--绍🌟煦·集思广益 2024年3月1日 (五) 03:09 (UTC)

你就说按你前面提的“已经无法为维基百科编写条目”的定义来讲，死人算不算维基人吧--SEX！ 2024年3月1日 (五) 20:21 (UTC)

同Kiraclyne。特定人或永封用户是负贡献恐怕是观点而非共识，如果有广泛共识（折毛等LTA）那么大概可以不理会以减少问题。--YFdyh000（留言） 2024年3月1日 (五) 03:17 (UTC)

你所谓的无共识不过是一堆人坚持说蠢话导致无法在表面上达成共识。游魂对社群的贡献是负的当然是有共识的。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 07:55 (UTC)

另外请你停止扰乱讨论。真的很恶心。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 07:56 (UTC)

而且我说，曾经为维基百科做过贡献的维基人和直到现在都还在为维基百科做贡献的维基人根本不是一个概念好吧。拿游魂举例，既然游魂曾经为维基百科做过贡献，但是后来直到现在因为被GBN所以不能为维基百科做贡献了，请问他还能叫维基人吗？你得是现在正在为维基百科做贡献编写条目才叫做维基人好吧，曾经为维基百科做过贡献但后来直到现在因故没有再为维基百科做过贡献的维基人只能叫做前维基人，而不能叫做维基人。--绍🌟煦·集思广益 2024年3月1日 (五) 03:23 (UTC)

前维基人不是维基人吗，没有很明确的定义，只是用户本身不能或不愿称自己维基人而已，别人按原样称呼他是不一样的概念。模板称“这位维基用户”就解决了您的问题。--YFdyh000（留言） 2024年3月1日 (五) 03:32 (UTC)

可是二者当然是不能等量齐观的啊，需要我在阐述一边我的观点吗？--绍🌟煦·集思广益 2024年3月1日 (五) 03:38 (UTC)

前维基人当然不是维基人。维基人可以编辑条目，前维基人不能。维基人具备的能力前维基人不具备。维基人所具有的属性前维基人也未必具备。你连这个问题都混淆的话，想必你做category的嵌套类关系一定是做不明白的。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 07:48 (UTC)

具体再举个例子吧。鸭子是鸟，鸟会吃东西，所以鸭子会吃东西。对于鸟的一般考量对鸭子都有效。鸭子是鸟，有的鸭子不会飞，所以鸟不都会飞。你觉得这理所应当，是因为这些信息都比较日常，不需要严谨地考虑啥问题。维基人可以编辑条目，而游魂这样的不可以。假设“一个人是维基人所以值得纪念”，而你发明出前维基人也是维基人这种错误的观点，就可以推断出前维基人也值得纪念了。而且退一步说，“一个人是维基人所以值得纪念”这个命题也是假的。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 07:52 (UTC)

基金会执行的禁令，即便是本站的用户在其用户页追加上WMF-legal banned user模板，毕竟这种情况现在是第一次遇到，还是应该问基金会先，我们不清楚他们的想法，搞不好基金会有自己的考量，不希望被全域封禁用户的用户页存在WMF-legal banned user之外的其他模板。如果他们不反对，那么就基本按照本站社群的共识执行就行，万一他们突然跳出来反对，搞不好这个用户页就是上黑锁了。针对这种特殊情况，谨慎行事没有任何问题。--🔨（留言） 2024年2月29日 (四) 12:45 (UTC)

m:WMFBAN已清楚表明這是一個office action，在沒有基金會的批准的情況下任何人也不可以在由User:WMFOffice所作出的全域鎖定用戶頁作出編輯。132.234.228.250（留言） 2024年2月29日 (四) 03:09 (UTC)

原则上，User:游魂的用户页并不是WMFOffice操作保护的，而是我们项目管理员基于OA2021的观点代为建立替换页和由于用户永封而页面同时封锁保护。而且OA的意义应该是限制被执行者在项目的交互行为。这次添加标识既没有解除页面保护、也没有解除用户封锁，不认为与OA违背。但考虑涉及到“与被执行者的交互行为”，所以还是让管理员斟酌处理。——Sakamotosan路过围观 | 避免做作，免敬 2024年2月29日 (四) 03:36 (UTC)

大体上同意cwek的看法。个人认为不如看看WMF的意见（个人可以帮助撰写邮件询问），如果WMF至少是不反对，或者此举证明未与有关规定冲突的话，个人认为安放一个{{Deceased Wikipedian}}模板，无论是作为作为事实性的标记还是对逝者基本的尊重是应该做的。--クオン·千の海を越えて·愛おしき欠片 2024年2月29日 (四) 09:16 (UTC)

要放的話，討論頁還適合一些。本來討論頁是沒有保護的，後來遭濫用才有。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月29日 (四) 11:51 (UTC)

如果非要放个模板不可的话，还是用户页更好。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 07:45 (UTC)

(＋)支持，只是标记用户去世而已，也不代表贡献或者纪念，且基金会也不反对。--Kethyga（留言） 2024年3月1日 (五) 09:28 (UTC)

有確切、可靠的消息證明遊魂的死訊嗎？Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年2月29日 (四) 07:23 (UTC)

(＋)支持：支持魔女。逝者安息。--LT1211_{(讨论|贡献)} 2024年2月29日 (四) 10:27 (UTC)

 默哀--喜歡聽林佳辰唱歌的Sinsyuan 2024年2月29日 (四) 10:49 (UTC)

我明天要去见他最后一面--

2024年2月29日 (四) 10:15 (UTC)

• (！)意見：此事应当有WMF参与讨论才行。建议社群先拟定一份与WMF的沟通邮件向其说明完整情况，并征询WMF的意见。Itcfangye（留言） 2024年2月29日 (四) 12:47 (UTC)

  其实有不少于三条要求联系的了。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月29日 (四) 13:10 (UTC)

  我发了一条邮件给ca，看看会不会回复吧。--在下荷花，请多指教（欢迎签到） 2024年2月29日 (四) 15:17 (UTC)

  WMF这次效率真高，点个赞。

“ Hello Hehua, Thank you for reaching out to the Foundation's Trust & Safety Team. We are sorry to hear of the situation and of 游魂's passing. Yes, you may add the template (指T:death等，本人注) to the user page alongside the banned user template. Best regards, John -- John Sullivan Trust and Safety team Wikimedia Foundation ”

--在下荷花，请多指教（欢迎签到） 2024年3月1日 (五) 00:12 (UTC)

已经被global banned的维基人已经不能再为维基百科做贡献编写条目了，所以他已经不是维基人了。为什么还要在他的用户页里添加去世模板呢？--绍🌟煦·集思广益 2024年3月1日 (五) 00:23 (UTC)

我只是转来了邮件原文，此外我觉得可以加，他可以是前维基人。--在下荷花，请多指教（欢迎签到） 2024年3月1日 (五) 00:25 (UTC)

但他现在已经不是了。--绍🌟煦·集思广益 2024年3月1日 (五) 00:26 (UTC)

以前曾是都可以。而且基金会已经表态同意的话，拿OA做借口就不太站得住脚。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月1日 (五) 00:30 (UTC)

这就是逻辑混乱了。当然还是可以因为OA2021不给他挂T:death。或者至少考虑另作模板。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 01:23 (UTC)

既然如此，那就没什么理由不加T:Death了。——Aggie Dewadipper 2024年3月1日 (五) 00:44 (UTC)

当然有理由不加啊。你是没有阅读能力吗？前面都有人论述了。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 01:14 (UTC)

我是真的很厌烦这些没有阅读能力的所谓维基人。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 01:16 (UTC)

张口就是愚蠢、没有阅读能力，还要我以及其他支持的人给出完整论述说明，我能给出什么论述说明？论述为什么他死了吗？请你漱漱口再来讨论。——Aggie Dewadipper 2024年3月1日 (五) 02:24 (UTC)

因为您确实没有展现出阅读能力来。您并没有资格和我讨论什么问题。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 02:36 (UTC)

还没有资格，到底是谁给你的自信让你觉得你高人一等的？——Aggie Dewadipper 2024年3月1日 (五) 02:39 (UTC)

因为您说胡话啊。明明前边不同的人给出了多个论述，您却睁眼瞎地说没理由不加T:Death。这说明您在这里根本没存心做什么讨论，当然就没资格啦。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:02 (UTC)

按基金会回复，按OA作为反对意见显然不合理。至于我是不是有心参与讨论，反正键盘在您手里，您怎么说都行。—-Aggie Dewadipper 2024年3月1日 (五) 03:19 (UTC)

所以说您看来是没有阅读能力。好几个人都说了，WMF不反对，不意味着本地社群不能以OA作为理由。这都读不懂吗？还是说没读就出来宣传自己看法了？--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 04:03 (UTC)

死去的用户挂T:Death怎么看也不是什么存在争议的问题，你要争议他到底算不算维基人的话他用户页分类都写明了“被维基媒体基金会封禁的维基人”，即他尽管被封禁也仍然是维基人。援引Kuon Haku的意见，不论是出于人道主义还是表明事实都应该挂T:Death，到底是你没有阅读能力还是你在装瞎？——Aggie Dewadipper 2024年3月1日 (五) 02:38 (UTC)

你怎么看都看不出来，所以才要看别人怎么说。懂了吗？社群达成共识靠的不是一群只知道宣传自己观点的人在那里奋其私智。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:04 (UTC)

我不喜欢死者为大这种话，但是你能不能不要因为和魂魂有不愉快的过往就在她死后一点底线都不要的来破坏维基社群的基本人文关怀共识？--

2024年3月2日 (六) 04:08 (UTC)

我認為{{death}}和{{Deceased Wikipedian}}的措辭都有可議之處，畢竟那個人已經被逐出維基社群，社群部分人對他做過的事也沒甚麼好印象，覺得他不值得紀念。我覺得比較理想的做法是不掛Death，同時（如果能夠確認死訊）修改Deceased Wikipedian模板，加入自訂參數，這樣既可以達到示亡的目的，又可以避免直接稱之為維基人，以及給人一種我們要去紀念他的印象，但具體怎樣做要視乎社群討論的結果。另外昨天看過，英文版和保加利亞文版會為被封禁用戶掛離世模板的（不過也有人和這裏部分人持同一立場，也就是身敗名裂的維基人即使死亡也應該遭到記錄抹煞），而德文、法文、西班牙文、印尼文版的做法是只紀念對維基百科有（顯著）貢獻的已故編輯。--春卷柯南－發前人所未知 ( 論功行賞 ) 2024年3月1日 (五) 01:12 (UTC)

这里的问题就是在用户页挂模板的目的是什么。

1. 是告诉大家这个维基人已经不可能为社群做贡献了？如果是这样，OA2021的对象就不应该挂这种模板。
2. 是纪念有一定贡献的维基人？如果是这样，那么此人对社群的贡献是负的，也不该挂。
3. 单纯因为一个自然人曾经是维基人，然后这个自然人死了，这个信息就需要在社群内公示？如果是这样，可以挂。
4. 其他还有啥情况？

--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 01:21 (UTC)

你看了基金会的回复？所以我也重复：OA作为不加纪念或提示模板的理由站不住脚，另外如果其他语区有允许这样的操作的话，可以参考。当然最终还是让管理员裁量，以上说法只是给一个允许的理由。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月1日 (五) 01:38 (UTC)

OA作为不加纪念或提示模板的理由当然是可以的。WMF只是说中维社群可以给挂。但挂不挂，为什么挂，为什么不挂，当然是中维社群的裁量。当然中维社群可以说这人是OA2021被处理的人所以不挂。劳烦您少说废话多动脑子。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 01:58 (UTC)

而且您也罢，其他支持挂模板的人也罢，就没有任何一个人给出一个完整论述说明为什么应该挂的。而你看看给出反对意见的人都有具体的理由。说白了你们又要和以往一样，想一人一票用人数来代替论述，用投票代替讨论而已。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 02:00 (UTC)

是否挂，我的意见是不置可否，但可以挂的理由，上面有人提过，我也转述过，至于挂不挂，我认为让管理员自己决定，但我不是管理员，挂不挂也不是我说了算。虽然整天说“投票不能代替讨论”，其本质就是希望通过讨论交换或表达意见并寻求全体一致或者大多数一一致，但投票不是也是一种意见表达方式？如果一堆人支持挂的，难道想翻桌推翻一致意见？——Sakamotosan路过围观 | 避免做作，免敬 2024年3月1日 (五) 02:12 (UTC)

>>虽然整天说“投票不能代替讨论”，其本质就是希望通过讨论交换或表达意见并寻求全体一致或者大多数一一致，但投票不是也是一种意见表达方式？

我不认同你的这个看法。一群人不是一定有可能有什么全体一致或者大多数一致的。因为并不是一些人聚在一起就意味着他们有共识基础。任何一个正经做事的环境都不是所有成员一人一票。难道公司的决策是员工一人一票决定的？难道课堂上老师和学生要一人一票决定什么是对的？理想中的你维，人人都有做事能力，人人都会论述，人人都讲道理，人人都想解决问题。但现实中的你维，很多人连读个条目都能死，整天除了宣传就是宣传，半步都不肯退，你觉得和这种人有任何达成一致的意义吗？当然要在适合的时候忽略他们的意见。”如果一堆人支持挂的”，你这个说法无非就是说用投票代替讨论，劣币驱逐良币，这种事WMC扰乱人事任免已经干过好几次了。算了吧。求你了。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 02:20 (UTC)

可以挂的理由我是真的一个都没看到。一句囫囵人话都没有。如果您愿意，劳烦您论述下吧。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 02:22 (UTC)

而且我再说句诛心的话吧，你的意见不是不置可否，而是支持挂模板，只不过你又不肯论述，又要当便宜正义人士，装作在讲道理的样子。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 02:25 (UTC)

嘴在你口，你觉得你是对的，这样会对你舒服一些的话，你喜欢就好。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月1日 (五) 03:00 (UTC)

你们呢。说正经事的时候从来都没建设性，批评下吧，就开始在这里装作受了委屈的样子。我也是很疑惑你们为什么赖在维基百科社群不走。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:05 (UTC)

你啊，以前也被其他编辑说说话毒辣。只是真想到，原来你的嘴巴就是这么臭。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月1日 (五) 03:33 (UTC)

“其他人也说你不好所以你不好”这种论证除了人身攻击没任何效果。没话说的话就闭嘴，闭嘴更有建设性。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:42 (UTC)

1. 赞成。2. 除非从古至今几乎无有价值贡献（比如七八成以上值得回退），或者LTA等因素消息存疑，否则至少曾经是维基人，站内无记录抹煞规则。3. 这种也可接受，但要信息真实且不滥发（有点困难），不要沦为讣告页。--YFdyh000（留言） 2024年3月1日 (五) 03:28 (UTC)

七八成也是个模糊的概念。除非是“显而易见的纯破坏用户”一刀切，不然总会有争议。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月1日 (五) 08:14 (UTC)

你维总有妄人非要胡乱发高见，当然是除了傻子都看得出来的事情，其他的都会“有争议”。如果看见“有争议”就不办事，你维那就只能成为垃圾堆了。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 12:13 (UTC)

分段1

既然上方已經引了WMF的回應，而WMF的取態是「不禁止、不反對」掛{{Death}}、{{Deceased Wikipedian}}等模板（我沒有理解錯的話），那這裏的問題就完全是中文維基百科的自由裁量了。

我看了一遍上方的討論，我認為以下幾個問題是值得討論的：

1. {{Death}}、{{Deceased Wikipedian}}等模板本身是否應被應用？［可就不同模板作分別的表述，可在不同的前提（如修改模板用辭）下有不同的立場］
2. 如{{Death}}、{{Deceased Wikipedian}}等模板本身應被應用，應用的條件（除死亡外）是甚麼？［比如身分、貢獻等特質；可就不同模板作分別的表述，可在不同的前提（如修改模板用辭）下有不同的立場，可認為無額外應用條件］
3. 如何衡量（一般情況而言）一個死者是否符合（除死亡外）{{Death}}、{{Deceased Wikipedian}}等模板的應用條件？

如果問題1的答案為否，那問題2、3就沒意義；如果問題2的答案為無額外應用條件，那問題3也沒意義。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年3月1日 (五) 03:04 (UTC)

所以你的问题是，不考虑这次的具体人物，而做一般论吗？我个人很不建议这样做。你不去考察具体情况怎么知道可以归纳出规则呢。你维人特别喜欢跳过归纳的步骤直接就口含天宪了。总不是要在这个具体问题上先不做讨论，然后绕过具体问题去想象一些规则出来，然后拿这些想象的规则来指导这次的实践吧。

当然了非要接着你的问题说的话我的看法是这样。

1. 我不反对纪念性示亡模板的存在
2. 纪念性示亡模板只能用于有一定贡献的维基人。OA2021这种情况就不行。LTA也不行。其他永封者可能要看封禁原因。已实际上退隐的维基人也不是不能用。
3. 不理解你的问题。

--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:20 (UTC)

（编辑冲突）走了就挂上去不就好了，是说维基人去世了社群还要给他盖棺定论，贡献大的尊称文武，负贡献的贬称幽厉吗？这次逝世的是被gban的用户，有些人觉得有理由搞damnatio memoriae，如果是没被gban的但是毁誉参半的呢？谁来决定要不要挂？还是别挂{{death}}了改成树碑立传，评说功过？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月1日 (五) 03:24 (UTC)

当然是负贡献的不要纪念啊。好几个人都说过了你是没看到吗？竖什么稻草人来扰乱讨论。看到你这种诡辩，要是不厌烦那才真是没人性了。如果您觉得您没在诡辩，就举证吧。看看前面谁说过你上边扯的这个淡。你不过就是仗着不想知道别人的看法，就要编造一些愚蠢的意见，然后批判这样愚蠢的意见以营造出你的发言有建设性的假象。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:34 (UTC)

可是挂这些模板也是有讲究的啊，既然都毁誉参半了那还挂这些模板有什么意义？维基百科的存在意义是什么？当然是一部供读者阅读和查阅资料的百科全书，所以身为一个维基人，你得是为维基百科做出过实质上的贡献才能挂death模板来纪念啊。--绍🌟煦·集思广益 2024年3月1日 (五) 03:33 (UTC)

“贡献”之所以重要，最后就要归结到维基百科是什么的问题。倒不是说必须给维基百科做很大贡献，才算是社群的有意义的成员，但如果一个人贡献是负的，我很难理解为啥他要被视作维基人这个群体的成员。有些所谓维基人要纪念这种人，不过是因为他们自己不读维基百科，所以不在乎具体的人到底在维基百科做了什么，把维基百科当成社交平台了。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:37 (UTC)

我是很欢迎有谁来讲讲游魂到底为啥值得中文维基百科社群纪念的。当然了如果说是没有认可的意义，只是示亡，那我的看法是不需要这种模板。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:45 (UTC)

没错，维基百科理论上谁都可以自由编辑，都是自由编辑维基百科的志愿者。所以只要你哪怕做出一些小小的贡献（比如修改某个条目的错误信息、为编写某一条目提出某些建设性的意见），都算是社群有意义的成员。--绍🌟煦·集思广益 2024年3月1日 (五) 03:49 (UTC)

话说到这里就很严肃了。因为在WMC淡出以前，他们是集团扰乱站务的。我的看法是一些WMC成员完全没贡献，因为条目写得很垃圾，基本完全在做宣传，浪费了很多社群的人力去修他们写的烂内容不说，他们还扰乱各类评审，让社群认可他们写的垃圾宣传内容。更不用提那些为了刷存在感而搞编辑松，结果让垃圾条目批量产生，侮辱编辑松的人了。而结党营私，分裂社群的事，啧。我知道有些人到今天也不觉得他们做错了啥。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:55 (UTC)

不读条目的“维基人”可能会疑惑，一个条目写得再烂总有能读的地方吧？那么总算是有点贡献吧？那么我倒是想问用已经变质的有毒害的做菜，这菜还能不能吃。不读条目，就不会知道垃圾条目为什么是垃圾条目。一个垃圾条目没有阅读价值，垃圾条目不是说有少许事实错误，或者观点偏颇，或者信息组织失当，而是根本就不配给正常读者读。很遗憾的是，有那么一些维基人就是无法理解什么叫作垃圾条目。我也很遗憾这样的维基人为什么还不滚。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 04:07 (UTC)

“毁誉参半”是有一半誉啊，究竟有无实质贡献（我不赞成“功过相抵”），中立的观点呢，“你根本不需要说他是邪恶的”，除了用户是“纯粹破坏”者。用户页并非百科全书的一部分，能用来协作和简单纪念。有争议那么模板称这位用户就好。--YFdyh000（留言） 2024年3月1日 (五) 03:43 (UTC)

不知道谁说的毁誉参半，看起来不是个很正经的人话。如果关于这个你有论述的话请展开。我对此人的看法是“毫无贡献，只有明确的伤害”。这人（当然不止他一个人啦）搞编辑松搞出一堆垃圾，我修都修吐了。如果你觉得此人有贡献我是很欢迎你讲讲有啥贡献的。哪怕是讲一般论，我也不认为有什么真正的毁誉参半的维基人。不然你举个例子？--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:47 (UTC)

中立的观点是条目空间的事。条目空间以外不适用。你这个论述不恰当。而且除了诡辩者以外也没人说要给哪个死去的维基人挂个邪恶模板吧？--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 03:50 (UTC)

@Sanmosa：这种问题就太过空泛了，不谈具体事例而只谈模板该怎么挂是不会得出有什么好的结果的。所以讨论这类问题也是没有意义的。--绍🌟煦·集思广益 2024年3月1日 (五) 03:29 (UTC)

@UjuiUjuMandan、Nishino Asuka：我本來確實是有意將具體事例從中剝離的，但現在我再想了一下，不剝離具體事例可能確實是比較好的approach，大家把我這三個問題當成延伸討論問題就可以（畢竟這裏可能有些人連{{Death}}、{{Deceased Wikipedian}}等模板的意義是甚麼都不清楚，我認為第1題和第2題至少能協助他們先找到一個概念，又或是協助我們先看到他們有甚麼錯誤的概念）。第3題主要是想問在{{Death}}、{{Deceased Wikipedian}}等模板存在應用條件的情況下，怎樣去判斷一個人是否滿足那些條件（比如「有一定貢獻的維基人」，這個「一定貢獻」要如何判斷？當然，我並不是要求必須有一個量值，但感覺有一些準則去協助社群就個案判斷某個死者是否進行了「一定貢獻」會比較好）。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年3月1日 (五) 05:38 (UTC)

我也回答一下自己問的問題好了：

1. 單就相關示亡模板現時的用詞來說，它們顯然是具紀念性質的，但個人認為調整{{Deceased Wikipedian}}的用詞，並使之成為僅示亡而不具紀念性質的模板或許是可行的，不過這依然需要另外的社群共識。
2. 我的想法和UjuiUjuMandan相近。
3. 具體來說，這可以用五大支柱來衡量：用戶加入到維基百科的內容品質如何？是百科內容嗎？（5P1）符合內容方針嗎？（5P1）內容中立客觀嗎？（5P2）內容沒有版權問題嗎？（5P3，特別提及這點是因為WG有嚴重的copyedit行徑，我不清楚游魂是否有差不多的毛病）用戶的表現足夠文明嗎？（5P4）有與其他用戶互相尊重對方嗎？（5P4）當然，衡量的標準也不一定限於五大支柱，但如果連基於五大支柱問的這些問題也存在「否」的答案，那我實在無法認可加入具紀念性質的示亡模板的做法。

以上。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年3月1日 (五) 05:58 (UTC)

关于你说的第三点，现实是问题根本不在你用什么规则来规范内容质量，而是太多维基人不去读条目，所以不会根据一个人所负责的条目的质量来评价一个人，那么当然就是根据存在感咯。比如WG这种垃圾制造机在一些WMC小朋友那边都能被叫做大佬，如果让那些小朋友背诵5P，有用吗？没用。因为他们仍然不会去读条目，所以他们就不知道哪些维基人的努力使得维基百科越来越好，而哪些人使得维基百科越来越烂。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 06:08 (UTC)

那就只能夠迫使他們學習如何根據一個人所負責的條目的質量來評價一個人了，畢竟他們本來就應該這樣做（至於學習不來的後果，大家不是已經見到了嗎）。然後單說游魂，單是塞爾維亞編輯松時跟WG的事情就已經能肯定他就是個公然踐踏5P4的用戶（為表文明，我這裏能夠用的用詞也就只剩下「用戶」了）。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年3月1日 (五) 06:15 (UTC)

没有任何办法能够使得一个本来就没兴趣读维基百科的人去“學習如何根據一個人所負責的條目的質量來評價一個人”。人家来维基百科的初心本来就是做宣传和刷存在感，你逼他们做正经维基人也太过分了吧？惟一的选择就是让他们滚。塞尔维亚编辑松可以说是一个很不错的垃圾人办垃圾事批量制造垃圾还妄图刷存在感的经典案例。而且非常遗憾地是，如果不是因为他们已经被OA2021处理掉了，在站内都基本不可能批评这件事：你开个话题讲这个事的话，至少会有10个WMC小将出来互助，捍卫他们制造垃圾的权利。而你维管理员又不可能有效地维持秩序，因为你维人事任免是一人一票的，也就意味着召集足够多的蠢货就可以控制社群了。OA2021打破了这个困局，但WMF并没有责任也无法扭转社群的风气，剩下的事要社群自己做。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 06:57 (UTC)

关于塞尔维亚编辑松，我有一个论断：WMC人里认真去读过那些条目的，一个都没有。他们心里都清楚搞这么个编辑松只是为了刷存在感，实现他们那个让WMC影响力越来越大的妄想。但是一个个的又不肯承认，还得说那些冠冕堂皇的话，装无辜，仿佛喂读者吃屎的不是他们一样。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 07:05 (UTC)

1. 调整death或者deceased都可，我觉得death不像中文，建议改为“遗憾的是，PAGENAME已经逝世，无法答复您的留言。逝者安息。”
2. 从目前的文本来看，death和deceased的侧重不同。death倾向于用户的状态，deceased倾向于标注用户页的状态。我认为deceased用在原有用户页的情况。其他情况不应作限制。
3. n/a

 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月1日 (五) 07:14 (UTC)

如果你实在是要搞一个这样的模板的话，我觉得这样措辞就差不多了。

“该账号的使用者已经离世。出于安保原因，该账号已被全域锁定。”--MilkyDefer 2024年3月1日 (五) 14:51 (UTC)

如果专设示亡模板，仅仅表示此维基人已经去世，我认为无必要。“无必要”也不是“不可”的意思，所以如果有人要用示亡模板，我也不会说用了就是错的，只不过需要注意示亡模板的措辞需要严谨，不要加入太多假设以致产生副作用。你维人很不擅长避免副作用，眉毛胡子一把抓。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 07:42 (UTC)

我是觉得考量到不是所有维基人的死亡都能为社群所知，单从别人口中传出的消息难免会被怀疑真实性，干脆就依据第三方可靠来源的报道来判断是否需要贴上用户死亡相关的模板算了，例如User:Ig2000这种，本来对一名用户对社群的贡献程度的评判就有很强的主观性，有的对社群贡献公认非常突出的用户在退出维基百科后低调生活，死了社群里也没人知道，而像游魂这样的被全域封锁的用户，离世之后社群要为其对本站的负面影响之因素大吵一架。与其为对社群影响正面与否而争论，不如借此机会大幅度限制以第三方可靠来源报道为准，更加接近于公正客观。--#Paris2024Countdown147Days 2024年3月1日 (五) 11:52 (UTC)

这个观点有点接近于条目空间的做法了。又有点像notability又有点像可供查证。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年3月1日 (五) 12:16 (UTC)

但对于那些死了都没人知道的用户来说毫无疑问是公平的，而且最大限度了降低了主观性。--#Paris2024Countdown147Days 2024年3月1日 (五) 12:20 (UTC)

我想很难辨别可靠报道和加入时机。且这样类似有则必加，而非必要（有人主动‘纪念’）时加，反而更像讣闻了，将使“维基人”讣闻惯例化？不需要公平的展示吧，用户可能原本低调，有来源就标注可能产生负面效应（错误报道；历史编辑评价）。--YFdyh000（留言） 2024年3月1日 (五) 16:38 (UTC)

维基人去世的情况目前来说很少见，而且除非你自己主动公开身份，或者你的身份遭到泄露，维基人本质上就是匿名的，“在互联网上，没有人知道你是一条狗”，试问下本站二十多年历史，众多已经退出维基百科的用户，有多少我们还能知道他/她的相关消息，说不定某个维基人前一天还活跃者，后一天突然被车撞死了（以防万一说下只要这个可能性不是零就不要质疑这种假设），都没人知道他在维基百科里面有帐号，他死掉的事情更不会为社群所知，本来我不想说这些东西的，但看你们有的人拿游魂君对于社群带来的负面影响说事，我就想干脆就设立一个更为公平的标准，觉得依据可靠来源作为标准不妥，那也可以针对那些停止编辑维基百科之后再无任何消息的用户，统一在他们停止编辑大约一百年（按吉尼斯世界纪录统计的人类最长寿命再减个十来岁计算）之后不管三七二十一都加上死亡相关模板。--#Paris2024Countdown146Days 2024年3月2日 (六) 11:20 (UTC)

版权释放公有领域（乱）--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年3月2日 (六) 11:32 (UTC)

不过负面影响实在难以另起讨论 囧rz……（悲）--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年3月2日 (六) 11:46 (UTC)

注册之日起第123年的1月1日吧 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月2日 (六) 11:35 (UTC)

没有必要且离题了，一百年后沧海桑田，共识也会变化。--YFdyh000（留言） 2024年3月2日 (六) 13:36 (UTC)

当然真正令所有人满意的方案肯定是不存在的，既然如此，那很显然游魂的这件事情要达成共识就难了，看到春卷柯南下面的话，我想可以合理推测部分被基金会全域封锁的维基人（比如W某），是不屑于别人为他将来哪一天去世去特地在他用户页去纪念的，说明肯定要设定标准，还是那种最大限度避免主观判断的标准，我已经说出了其中两个方向，觉得还有更好的也欢迎各位具体提出，具体方案肯定不可能完美但只要能尽可能让更多用户接受没什么不行的，如果这个不行那个也不行达不成共识的话，干脆以后先禁止在一切被永封或者被全域封锁的用户页面挂上任何除了标识该用户已被永久剥夺编辑权限模板以外的任何模板（为避免帐号被他人盗用等特殊原因而永封的除外），至少这次的问题就相当于套了一个合理的理由就这么解决了。--#Paris2024Countdown146Days 2024年3月3日 (日) 00:35 (UTC)

（编辑冲突）我對上面三條問題的意見是：

1. 應該。
2. 如果不修改措辭，至少還有兩個條件：一、他從未被驅逐出維基社群（也就是排除LTA和OA對象），二、他在維基百科做過值得稱道的事情（包括但不限於條目編寫、工具研發、站務改良等），甚至必須有良好的聲譽（如果你們真的要較真的話）。修改措辭（或加入自訂參數）後我認為是天空海闊任鳥飛的。
3. 承上，一比較好判斷，二我可以想到的因素包括他寫的條目、研發的工具、提出的措施是否帶來好的影響，以及他的行為操守紀錄。按此，假如有一天蘇州宇文宙武（但我覺得他現在視維基社群為殺父仇人，你們紀念他也是徒勞的）、劉嘉，甚至我不在了，社群又是否覺得我們值得被紀念呢？我覺得趁這機會劃定一個總體的原則會比較好。如果不修改措辭的話，這些就是應否掛的條件；反之就會成為應否使用自訂參數的條件。--春卷柯南－發前人所未知 ( 論功行賞 ) 2024年3月1日 (五) 18:22 (UTC)

我在这里复制一下之前在电报群的观点：如果大家觉得可以加死亡模板，但现有死亡模板的内容不适宜用于此案的话，可以考虑为其专门写一个death|banned或deceased|banned模板。Itcfangye（留言） 2024年3月1日 (五) 17:34 (UTC)

不反对，措辞其实直接只保留death第一句就行（“不幸的是，PAGENAME已经去世”），后面也许可以出于人道主义加一句“愿逝者安息”之类的。反正这些人无论死活都没办法答复提问，也不值得缅怀。—-Aggie Dewadipper 2024年3月1日 (五) 18:19 (UTC)

我觉得加{{Deceased Wikipedian}}就行。--1.164.152.60（留言） 2024年3月2日 (六) 08:01 (UTC)

• “纪念账号”这种东西么，很多平台都有的。如果“纪念”这词会让某些人认为有主观色彩，或是要论所谓“生前贡献”、“生前功过”区别对待，又或是因各种原因觉得对方不配“享有荣誉”，不如就将这种东西看作是“持有者已逝世的账号”（本质上也是如此不是么）。生者仅去为其标明某用户已逝世，用户页上标注“此用户已逝世，因此无法答复您的提问”。这句简短说明是不是很清晰明了，既能免得其他不明情况的在世的人前去打扰，又能符合某些人所谓“中立”的追求，还能免得纷争，替另一些人积一些口德。如果人文关怀在这里是种奢望，不如就务实一点。--安忆^Talk 2024年3月3日 (日) 13:22 (UTC)