Wikipedia:互助客栈/其他:修订间差异
第721行: | 第721行: | ||
{{Archive bottom}} |
{{Archive bottom}} |
||
: 正經而言,離世模板通常可授予對本站有卓著貢獻,並鞠躬盡瘁之維基人。全域禁制者多難保晚節,而不甚符合此等要求。—— '''[[使用者:Ericliu1912|Eric Liu]]'''<sub> -{創造}-は生命('''[[使用者討論:Ericliu1912|留言]]・[[使用者:Ericliu1912#訪客芳名錄|留名]]・[[維基百科:維基學生會|學生會]]''')</sub> 2024年2月28日 (三) 12:14 (UTC) |
: 正經而言,離世模板通常可授予對本站有卓著貢獻,並鞠躬盡瘁之維基人。全域禁制者多難保晚節,而不甚符合此等要求。—— '''[[使用者:Ericliu1912|Eric Liu]]'''<sub> -{創造}-は生命('''[[使用者討論:Ericliu1912|留言]]・[[使用者:Ericliu1912#訪客芳名錄|留名]]・[[維基百科:維基學生會|學生會]]''')</sub> 2024年2月28日 (三) 12:14 (UTC) |
||
:: 虽然但是{{tl|death}}的doc无此规定……您指的应该是将ta加入[[WP:RIP]]吧,{{tl|death}}我觉得真死了应该加。--[[User:忒有钱|忒有钱]] [[:ja:凪のあすから|凪のあすから 10th Anniversary]]([[User talk:忒有钱|留言]]) 2024年2月28日 (三) 13:45 (UTC) |
|||
: {{提醒}} :「是」為深表遺憾之義。請勿過度理解(尚未獲取更多信息),''[[息止安所]]''。--[[User: HualinXMN|''Hualin'']][[🎗️]][[东方天空璋 ~ Hidden Star in Four Seasons.|希望の星は青霄に昇る]] <sub>[[Commons:User:HualinXMN|Commons]]|[[User Talk: HualinXMN|''Talk'']]</sub> 2024年2月28日 (三) 12:39 (UTC) |
: {{提醒}} :「是」為深表遺憾之義。請勿過度理解(尚未獲取更多信息),''[[息止安所]]''。--[[User: HualinXMN|''Hualin'']][[🎗️]][[东方天空璋 ~ Hidden Star in Four Seasons.|希望の星は青霄に昇る]] <sub>[[Commons:User:HualinXMN|Commons]]|[[User Talk: HualinXMN|''Talk'']]</sub> 2024年2月28日 (三) 12:39 (UTC) |
2024年2月28日 (三) 13:45的版本
發表前請先搜索存档,參考舊討論中的内容可節省您的時間。 |
|
- [人事] Manchiu、UjuiUjuMandan、ASid、ATannedBurger获提名为管理员,AT获提名为监督员,欢迎踊跃参与提问和讨论。
- [公告] 互助客栈正在对于Unblock-zh.org试运行征求意见。
- [公告] 現時已改為只有延伸確認用戶可以使用內容翻譯將頁面釋出到主條目空間,如有疑問及意見,歡迎參與相關討論。
- [公告] 回饋請求系統正在試運作中,誠邀用户訂閱以接收討論通知。用户訂閱有興趣參與的討論議題後,机器人會自動在新討論發起時隨機抽取部分用户發消息通知。
- [公告] 修訂維基百科不是維基物種已經通過。
- [公告] 关于{{Death}}和{{Deceased Wikipedian}}文案调整的方案、修改模板:No source、電視條目播放資訊增加收錄準則及規範討論發起步驟正在公示,如有意見請儘快提出。
- [討論] 互助客栈方针区正在討論再擬議立國際關係命名常規為方針,請踴躍參與討論。
- [討論] 互助客栈技术区正在討論ToolsRedirect创建的繁簡重定向問題,請踴躍參與討論。
- [討論] 互助客栈其他区正在討論对新闻动态获选标准及ITNR规则的小修订及頁面評級與通用評級行政層面上的統合方案,請踴躍參與討論。
- [廣告] 第二十二次動員令現正徵求主題及主持人中,另舉辦時間公示至5月21日,歡迎踴躍參與!
存檔 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
# | 💭 話題 | 💬 | 👥 | 🙋 最新發言 | 🕒 (UTC+8) |
---|---|---|---|---|---|
1 | 沒有主題的頁面如何評級 | 185 | 11 | A2569875 | 2024-05-12 10:54 |
2 | 評級系統缺失問題 | 212 | 21 | A2569875 | 2024-05-12 10:55 |
3 | 管理人员申请预讨论 | 277 | 47 | SheltonMartin | 2024-05-16 13:25 |
4 | 對新用戶禁用內容翻譯工具(續) | 29 | 12 | SCP-2000 | 2024-04-24 11:51 |
5 | 关于IP封禁豁免权授予者的顶部图标 | 1 | 1 | Sanmosa | 2024-05-14 23:11 |
6 | 对ITN获选标准及ITNR的小修订 | 25 | 10 | Ericliu1912 | 2024-05-12 11:19 |
7 | Unblock-zh.org | 24 | 10 | LuciferianThomas | 2024-05-15 15:52 |
8 | 第二十二次動員令籌備討論 | 68 | 24 | Sanmosa | 2024-05-17 14:42 |
9 | 何時應該使用{{Dead Link}}模板? | 7 | 3 | GZWDer | 2024-05-08 20:02 |
10 | 照片著作權疑問 | 1 | 1 | Jimmy-bot | 2024-05-16 16:14 |
11 | 关于第三次非洲月 | 15 | 11 | 魔琴 | 2024-05-14 09:36 |
12 | 请求讨论,人少了不行,请大家都来说,直到让我意识到是我的理解不对为止。 | 2 | 2 | YFdyh000 | 2024-05-09 18:40 |
13 | 有關被永久封鎖的IP | 5 | 5 | Shizhao | 2024-05-11 10:51 |
14 | 針對kenny023見習編輯的處置提出質疑 | 8 | 5 | 暁月凛奈 | 2024-05-11 19:27 |
15 | 管理員選舉候選人ASid通告 | 6 | 4 | Manchiu | 2024-05-13 07:14 |
16 | 关于偽基百科一覽中文維基人页面 | 7 | 6 | Dnaimfz | 2024-05-17 13:39 |
發言更新圖例 |
---|
|
|
|
|
|
特殊狀態 |
已移動至其他頁面 或完成討論之議題 |
手動設定 |
當列表出現異常時, 請先檢查設定是否有誤 |
正在廣泛徵求意見的議題
以下討論需要社群廣泛關注:(重新整理)
維基專題與協作
Wikipedia talk:已经去世的用户 § 已被全域禁制的用户的用户主页可以加离世模板吗?
此討論正在公示7天;如有意見請儘快提出。 上述讨论中不少用户认为需要对现有的模板({{Death}}和{{Deceased Wikipedian}})的文案进行调整,鉴于该讨论已持续近一个月没有结论,我想先尝试推动一下确立模板文案的调整方案(假定文案必须调整): { |
|
對新用戶禁用內容翻譯工具
原标题为:Disable Content Translation from brand new users
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
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:
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)
- 這個嘛,上次提出要將新建頁面提昇到自確以上的提案最後以修改A5為G18做收,短期內應該不太可能發生,況且AFC草稿積壓也確實嚴重。--冥王歐西里斯(留言) 2023年10月18日 (三) 03:59 (UTC)
- 这东西嘛,鸡肋,老人有能力用wikicode从零直接起手,知道大部分格式方针规则,用沙盒(用户子页、草稿空间)打底后再转正,新手用这个工具问题不少。——Sakamotosan路过围观 | 避免做作,免敬 2023年10月17日 (二) 14:11 (UTC)
- 偶然遇过一些编辑使用这个工具进行翻译(也就是编辑会被标签为“内容翻译”),经常出现格式不合要求(例如:半角标点(包括逗号、结尾点句号、双引号、圆括号,甚至有些前面还有半角空格),作品名斜体,数字前后不必要的空格(例如日期、数量词前))、文句不顺畅的疑似机器翻译未修正、不和本地用语惯例(常见的“也可以看看”)的情况。最近我见过例子有(User:Orrt0000 )的火焰噴射戰車(偶然抽出看到)、機動防護火力車(提醒过,我可能修改过?),失敗不是一個選項(oldid=79396409),Three(oldid=79314028,之后有修葺,但还不足够(oldid=79323303))。这非常依赖新页面巡查的巡视、修葺和指导,但考虑到新页面巡查现在活跃强度……我甚至觉得有没必要将新建页面的级别也拉高一级。——Sakamotosan路过围观 | 避免做作,免敬 2023年10月17日 (二) 14:07 (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)
- @MilkyDefer Thanks for your comment.
一点简单的澄清。内容翻译工具和机器翻译是两回事。
- 内容翻译功能提供原文和你的译文草稿的两栏对照界面。
- 你的译文草稿可以从零开始手写,也可以让机器翻译顶上。
内容翻译功能 | 在内容翻译功能内使用机器翻译 | |
---|---|---|
英维 | 仅限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)
- 就是不知能否技術上強行實現「禁止直接發佈在條目空間」。--日期20220626(留言) 2023年10月18日 (三) 11:02 (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)
- 不太理解為何需要禁止直接發佈到條目空間(在已禁止機械翻譯功能的前提下)。再者,此舉便相令新手創建條目的阻礙增加(相比不透過內容翻譯),那倒不如直接禁止新手使用內容翻譯。另一方面,無論是禁用機械翻譯功能還是整個內容翻譯工具,至少指出為何需要這樣做,不然也難以說服 WMF 關掉它。謝謝。--SCP-0000(留言) 2023年10月19日 (四) 18:06 (UTC)
- 畢竟真的想使用機械翻譯的話,不用內容翻譯也可以達到。我是覺得禁止直接發佈到條目空間最好,而且有新用戶也不見得懂得如何從個人用戶頁移動到條目空間。等到他懂得如何移動了,說明他對維基的編輯有了一定的了解。--日期20220626(留言) 2023年10月18日 (三) 22:36 (UTC)
- 这玩意纯属垃圾,我之前用过,觉得手感真是莫名其妙,而且翻译出来的参考文献、配图之类的错误一大堆。暑假还想给它第二次机会,去用它翻译了美洲麻鳽,结果体验实在太差,直接丢用户空间开始手动翻译。而且直接引导新手翻译FA/GA简直是反人类,这些条目动辄数万字节,一般还有各式从句等翻译难度较高的英语语法。综上,我认为内容翻译应该被彻底扫入历史的垃圾堆。——Aggie Dewadipper 2023年10月19日 (四) 08:12 (UTC)
- 支持至少禁用新手使用該機械翻譯(若能限制到延確以上會更好),這翻譯出來的真的不是人讀的,而且還會出現一些不存在的模板跟不合格式手冊的內容出來。且就像前面所說,會使用這種工具的可能會翻譯完就不管條目情況了,無疑增加巡查跟刪除上的負擔。寧願先堆積在草稿慢慢消化。--WiToTalk 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)
- 要不要在其他地方也公示一下?要知道看互助客棧-其他板塊的人並不多,免得到時候有人突然來問機器翻譯怎麼沒法用了。--日期20220626(留言) 2023年10月21日 (六) 16:32 (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提出的問題,以及與受到影響的使用者之間的溝通事項。 --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)
- 并非如此,我试过可运作,新建和编辑段落时工具不会再提供机器翻译的选项与请求,请再试试。--YFdyh000(留言) 2023年10月29日 (日) 15:45 (UTC)
- 我直接跟你说吧,你那个所谓的js方案,这是技术上不可能的。理由是翻译工具的运作机理。在翻译界面中,你先点击新建段落翻译的按钮,然后系统默认提供了机器翻译的结果,之后你才有机会选择这一段是使用机器翻译还是其他的。也就是说,如果不在phab的层面限制住,你所谓的js限制只会发生在机器翻译已经被提供了的既成现实之后,所谓的限制将毫无意义。--MilkyDefer 2023年10月29日 (日) 03:00 (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的解決方案:
- 阻止使用者將翻譯的文章發布到主命名空間
- 機械翻譯設定為可選項
- 抬高原文保留百分比的限制(前提是此機制正常運作)
- --桐生ここ★[讨论] 2023年11月28日 (二) 13:08 (UTC)
- @桐生ここ: 正如個人下方留言指出「抬高原文保留百分比的限制」做法並不可行,不知您是否還同意僅「阻止發布到主命名空間」以及「機械翻譯設定為可選項」已屬足夠,還是有其他想法?謝謝。--SCP-0000(留言) 2023年12月6日 (三) 17:34 (UTC)
- 基本上同意「阻止發布到主命名空間」以及「機械翻譯設定為可選項」已屬足夠。阻止發布到主命名空間基本上可以挡掉只想按按钮就建立条目的新手,如果把翻译品质烂的草稿移动到条目,就是用户的问题不是功能的问题了。桐生ここ★[讨论] 2023年12月6日 (三) 17:55 (UTC)
- @桐生ここ: 正如個人下方留言指出「抬高原文保留百分比的限制」做法並不可行,不知您是否還同意僅「阻止發布到主命名空間」以及「機械翻譯設定為可選項」已屬足夠,還是有其他想法?謝謝。--SCP-0000(留言) 2023年12月6日 (三) 17:34 (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)
- ( ✓ )同意,以前常遇到這種狀況......--,這是β衰變和正電子發射,請無視其他能量釋放。 2023年12月10日 (日) 15:11 (UTC)
- 95%未修改的機器翻譯文就能發佈?是不是應該調到更低一些?--日期20220626(留言) 2023年11月28日 (二) 15:27 (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)
- 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)
- 好像沒什麼進展?—— 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)
- (?)疑問@暁月凛奈:比方說創建一個專用的、通用的評級模板,無專題,不使用{{WPBannerMeta}}元模板,內部只塞「本頁面獲評XX級」和Special:页面评级的解析器語法,然後沒有別的說明?-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月7日 (四) 09:48 (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)
- (:)回應:@Milkypine:WP:評級:「
- 模板、分類、甚至是檔案也是需要評級的項目,算上去真的跟異端沒兩樣。而掛上專題模板呈現的未評級狀態能算評級嗎。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:03 (UTC)
- 沒有到「
- 幾乎所有專題都是廢棄的,只是這個專題明面上寫了而已;稍微好一點的是只有一個人參加的「個人專題」,不過這種專題基本上也是三分鐘熱度。如果你只是為了評級,那就不用管專題是否活躍,直接把
- (:)回應PJ:條目質量評級「
- {{WikiProject Disambiguation}},这个?--Kethyga(留言) 2023年12月7日 (四) 12:47 (UTC)
- 僅供參考: enwiki之前也有相關討論,現在已由{{WPBS}}自動為這類型非條目賦予NA-、Redirect-級別的評級與重要度。請參見w:wn:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24。中文或許如Category:非条目级条目?--Kanashimi(留言) 2024年1月10日 (三) 06:05 (UTC)
Random Thought: 跟进英维的WikiProject banner shell改版
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
我倒是想起一个事儿。英维最近改版了{{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)
- 你自己决断。如我前面所述,我的改动只是一个临时性的方案。迟早需要重新规划这一套系统的技术编排,届时现在的变动会被新架构完全覆盖掉。--MilkyDefer 2023年12月10日 (日) 18:22 (UTC)
- (:)回應:@MilkyDefer:可是我好像沒看到
- @MilkyDefer既然您提議了,我請求您給出可以執行的方案或建議,謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月9日 (六) 07:49 (UTC)
- @MilkyDefer稍微研究了一下,跟本地系統完全不相容,根本不知道怎麼改。他的評級是純粹使用英文字母的,我們是中文,從他目前的模組架構,我看不出來哪邊可以插入本地的評級模式。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月9日 (六) 07:47 (UTC)
- 工程量挺大,就看誰願意改了。(幾年前可能我有興趣,現在我就精神上支持了)--洛普利寧 2023年12月8日 (五) 14:53 (UTC)
- 目前(+)支持User:MilkyDefer的臨時方案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月11日 (一) 00:17 (UTC)
- (?)疑問:@Milkypine、暁月凛奈:您們認為暫時先用MilkyDefer的臨時方案如何?暫且能解決目前問題,且朝模板的新版改進邁進中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月11日 (一) 00:24 (UTC)
- (+)支持設立通用評級,但最好展現一下沙盒效果,現在點進去看到的文件說明還是舊版本。 --窝法乙烷 儿法梦碎 2023年12月11日 (一) 11:16 (UTC)
- (:)回應:@Milkypine:可以參考測試樣例Template talk:WikiProject banner shell/testcases(評級模板的測試樣例只能放討論頁,不然會有錯誤訊息 囧rz……;首個測試樣例填了GA,所以這裡可以看到這表格最下面「評級」是「優良」,表示新模板有效)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月11日 (一) 12:15 (UTC)
- 已逾一周無新意見,視為已有初步共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月20日 (三) 13:23 (UTC)
- 一個小問題,見测试11,若是位於模板空間應修先顯示為模板級。且依據我於Talk:医学測試結果,似乎不符合預期。-- Willy1018(留言) 2023年12月21日 (四) 06:26 (UTC)
- (?)疑問@Willy1018:Talk:医学測試結果哪邊不合預期?不是都正常顯示甲級嗎,下面也能展開
|collapsed=yes
預設不展開也正常啊。然後無法理解测试11明明已經指定了,為何要fallback to模板級?指定級別顯然優先於預設級別;未指定本來就該都沒有評級。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月21日 (四) 13:29 (UTC)- 底下:網際網路專題、維基百科專題、機器人學專題,應顯示為A級而不是未評。-- Willy1018(留言) 2023年12月22日 (五) 03:47 (UTC)
- 如果本來就是這樣設計的,當我沒說吧。-- Willy1018(留言) 2023年12月22日 (五) 03:48 (UTC)
- @Willy1018:網際網路專題、維基百科專題、機器人學專題的模板又沒有要改版,既然他沒有要改版,那麼那些模板沒有輸入評級他是要怎麼知道評級成什麼?通靈嗎?而且模板參數因技術限制無法跨模板互通,所以也不可能把A級資訊傳遞進模板(實現如此傳遞需要mw:Extension:Variables,萌娘百科有,但中文維基沒有,且相關擴展不相容於目前版本的MediaWiki)。再來,你看User:MilkyDefer的原始提案「
新的模版可以单独给条目一个总体的品质评级[…]也可以搞自己的评级。
」這代表各個專題的評級模板是自己搞自己的,每個專題的評級互相獨立並不相干,因此沒有輸入就該維持沒有輸入評級的狀態,本就不應該蹦出沒有輸入卻變成A級的這種狀況。再來「優先顯示模板級」問題肯定也是上方誤會導致的。既然你都說「如果本來就是這樣設計的,當我沒說吧。
」了,那麼我就視為異議已排除,可以準備進行公示階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月22日 (五) 04:15 (UTC)
- @Willy1018:網際網路專題、維基百科專題、機器人學專題的模板又沒有要改版,既然他沒有要改版,那麼那些模板沒有輸入評級他是要怎麼知道評級成什麼?通靈嗎?而且模板參數因技術限制無法跨模板互通,所以也不可能把A級資訊傳遞進模板(實現如此傳遞需要mw:Extension:Variables,萌娘百科有,但中文維基沒有,且相關擴展不相容於目前版本的MediaWiki)。再來,你看User:MilkyDefer的原始提案「
- 如果本來就是這樣設計的,當我沒說吧。-- Willy1018(留言) 2023年12月22日 (五) 03:48 (UTC)
- 底下:網際網路專題、維基百科專題、機器人學專題,應顯示為A級而不是未評。-- Willy1018(留言) 2023年12月22日 (五) 03:47 (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)
- (:)回應:@Willy1018:但要達成您所見到的效果需要第二階段的修改,跟{{WPBannerMeta}}配合。這樣的話,我就視為您對第二階段持(+)支持態度囉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月24日 (日) 08:12 (UTC)
- 感謝貢獻,目前已覆核已符合預期。-- Willy1018(留言) 2023年12月24日 (日) 05:17 (UTC)
- (?)疑問@Willy1018:Talk:医学測試結果哪邊不合預期?不是都正常顯示甲級嗎,下面也能展開
- 一個小問題,見测试11,若是位於模板空間應修先顯示為模板級。且依據我於Talk:医学測試結果,似乎不符合預期。-- Willy1018(留言) 2023年12月21日 (四) 06:26 (UTC)
- (+)支持設立通用評級,但最好展現一下沙盒效果,現在點進去看到的文件說明還是舊版本。 --窝法乙烷 儿法梦碎 2023年12月11日 (一) 11:16 (UTC)
- 此段落最後發言至今已逾七日,超過一周無新留言,且此前已形成初步共識,因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月1日 (一) 04:04 (UTC)
- 公示7日。公示內容見此-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月1日 (一) 04:04 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 完成:已佈署Special:Diff/80410249。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 04:40 (UTC)
第二階段:修改WPBannerMeta
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
@Willy1018:提到了一個很有意義的問題。如果上方的變更套用了的話,只有「表面上」給了頁面通用評級,而實際上的通用評級在各個專題中並沒有達成「繼承評級」的效果。這是因為評級模板預設不會知道他外面包著{{WikiProject banner shell}}模板,因此,如果要讓每個評級模板都能讀到通用評級,需要再一個編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月24日 (日) 05:15 (UTC)
- 預計將會使用Module:PJBSClass來讀取{{WikiProject banner shell}}模板中的評級,並傳遞給{{WPBannerMeta}}注入進class參數。由於這需要第一階段先通過才有用,故先 擱置,等第一階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月24日 (日) 05:15 (UTC)
- 第二階段相關討論Special:PermaLink/80224436#回復通告-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月25日 (一) 02:56 (UTC)
- 已覆核,已符合預期,再次感謝您的貢獻。(搬運自Special:PermaLink/80233084)-- Willy1018(留言) 2023年12月25日 (一) 04:02 (UTC)
- 上面的共識是「
可以單獨給條目一個總體的品質評級,各個WikiProject可以直接繼承這個quality assessment,也可以搞自己的評級。
」,下方Wikipedia:互助客栈/其他#關於基礎條目的額外提議也有多個(+)支持「對各種專題橫幅不再個別指定 class,而是統一置於{{WPBS}}
」的聲音,為了實現上方共識「各個WikiProject可以直接繼承這個quality assessment」以及下方討論的「專題橫幅不再個別指定 class,而是統一置於{{WPBS}}」因此需要在{{WPBannerMeta}}置入讀取{{WPBS}}評級值的模板,以便讓專題橫幅能正確識別統一置於{{WPBS}}的評級,故本修改是必要的,目前已經佈署於電子遊戲專題和多面體專題,運作穩定。如無異議,將會進行公示,進行全面佈署。
- 預計的修改方案以及其佈署連結(記得填寫討論通過的diff和客棧PermaLink版本號)。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 05:00 (UTC)
相關議案
的配套修改-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 05:03 (UTC)
- 想諮詢一下@Kanashimi君相關修改是否有問題?—— Eric Liu 創造は生命(留言・留名・學生會) 2024年1月8日 (一) 05:53 (UTC)
- @Ericliu1912、Kanashimi:這主要是依據共識,讓專題橫幅能繼承{{PJBS}}輸入的評級值。我已經在{{多面體專題}}、{{電子遊戲專題}}測試過了,沒有問題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 06:00 (UTC)
- User:A2569875的努力有目共睹。只不過我原先料想的是直接改w:en:Module:WikiProject banner及w:en:Module:Banner shell,而宇帆-娜娜奇看起來很辛苦的重構了代碼,並且有些參數不太一樣,這樣我就不太好評論了。--Kanashimi(留言) 2024年1月8日 (一) 06:12 (UTC)
- @Ericliu1912、Kanashimi:那就用測試數據來說話吧。目前我是刻意讓{{多面體專題}}內部是調用Template:WPBannerMeta/sandbox/sandbox(同於Template:WPBannerMeta/sandbox,只是Template:WPBannerMeta/sandbox/sandbox裡面都塞/sandbox模板以便測試效果),效果完全符合預期,十分正常,見下列測試結果(只要是調用{{多面體專題}}的,基本上都等同於這個Patch):
- Talk:二十面體對稱的多面體列表:裡面輸入了列表級,Template:WPBannerMeta/sandbox確實讀到了列表級,沒有問題。
- 其他可參考Special:链入页面/Template:WPBannerMeta/sandbox/sandbox,基本上都沒有問題,我檢查一個禮拜了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 06:16 (UTC)
- Eric Liu 創造は生命(留言・留名・學生會) 2024年1月8日 (一) 12:18 (UTC)
- @Ericliu1912:若以Wikipedia:互助客栈/其他#Random_Thought:_跟进英维的WikiProject_banner_shell改版這一案來看的話(或者說只看這一案)的話,只有{{WPBannerMeta/core}}和{{WPBannerMeta}}要更新。其他案目前還在討論中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 12:23 (UTC)
- (~)補充:@Ericliu1912:參考這個留言Wikipedia:互助客栈/其他#MilkyDefer2023年12月9日(六)14:14(UTC),「
原樣照辦英維的codebase要動的手術很大。不過我姑且給你實作了一個長得差不多的在對應沙盒裡面。
」考慮到最大相容性和中文維基的特殊性(如繁簡問題),本地評級系統本來就跟英文維基不太相同。目前只能「按照人家代碼的思路重新實現一個類似的咯。
」(by User:MilkyDefer)此外,我也不想換掉現在中文維基熟悉的Style。目前您所看到的系統都是基於MilkyDefer的修改版再把enwiki對應功能實作出來。主要功能去年年底就完工了,經過了半個多月的測試,我相信技術上不會有太大的問題。且相關函數已於電子遊戲專題兩萬多條目進行測試,問題幾乎都解決了。技術上沒有問題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 12:58 (UTC)
- (~)補充:@Ericliu1912:參考這個留言Wikipedia:互助客栈/其他#MilkyDefer2023年12月9日(六)14:14(UTC),「
考慮到日後長期維護需求,我傾向請您以英文版本為基礎來更新相關模板。是否能夠確認有什麼模板需要更新(或在互助客棧列出之類)?不過在此過渡期間,若技術上沒有問題,是可以斟酌先批准既有之編輯請求。—— - @Ericliu1912:若以Wikipedia:互助客栈/其他#Random_Thought:_跟进英维的WikiProject_banner_shell改版這一案來看的話(或者說只看這一案)的話,只有{{WPBannerMeta/core}}和{{WPBannerMeta}}要更新。其他案目前還在討論中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 12:23 (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)
- (:)回應:既然你有在看,那我就更仔細地說明這兩個編輯請求(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)
- (不用一直提及我,我有在看)—— Eric Liu 創造は生命(留言・留名・學生會) 2024年1月8日 (一) 15:11 (UTC)
- @Ericliu1912:要改哪些模板我在客棧上其實都有列,主要在案《沒有主題的頁面如何評級》和案《評級系統缺失問題》的子章節裡。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 15:03 (UTC)
- @Ericliu1912、Kanashimi:那就用測試數據來說話吧。目前我是刻意讓{{多面體專題}}內部是調用Template:WPBannerMeta/sandbox/sandbox(同於Template:WPBannerMeta/sandbox,只是Template:WPBannerMeta/sandbox/sandbox裡面都塞/sandbox模板以便測試效果),效果完全符合預期,十分正常,見下列測試結果(只要是調用{{多面體專題}}的,基本上都等同於這個Patch):
- @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)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
第三階段:完善制度
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
在Template_talk:WPBannerMeta#編輯請求_2024-01-08中有人認為需要給通用評級訂一個「能填寫甚麼級別」的標準來避免爭議,因此立了草案Wikipedia:通用評級如下:
- 若一條目沒有專題或不受任何專題管轄,則其通用評級可填寫任意有被{{WikiProject banner shell}}支援的級別,僅要該條目有達到該級別的標準或滿足該級別的條件,都可以評。
- 若一條目僅有一個專題,其通用評級應與該專題所評的等級一致。
- 若一條目有多個專題,通常由機器人自動依照規則4進行評級,但一旦出現爭議時則通用評級應以所有專題都有開設的級別為主。
- 例如:若一條目有四個專題,而有一個專題沒有開設「丙級列表級」,那麼通用評級就不得填寫「丙級列表級」
- 對於有多個專題的條目,通用評級應填寫最多專題評的那一等級。
- 例如有一個條目有四個專題,其中三個專題都評為乙級,但有一個專題評為丙級,則通用評級應填寫乙級。
- 若在規則4的情況牴觸規則3,則應填寫與對應級別最接近的且滿足規則3的級別。
- 例如有一個條目有四個專題,其中三個專題都評為「丙級列表級」,但有一個專題評為「列表級」且這個專題不開設「丙級列表級」。依據規則3,最多專題評的級別是「丙級列表級」,但有一個專題不開設「丙級列表級」,則通用評級應填寫與「丙級列表級」最接近且位於該條目所有專題都有開設的級別,也就是「列表級」。
- 「最接近的級別」應該向下填寫,例如未啟用乙級的專題,通用級別遇到規則3判為乙級的情況時,則向下填寫為丙級。如果丙級也有專題未開設,就再向下填寫為初級。如遇到無法評級的情況,該通用評級模板就該留空。
提議將之升為指引,不曉得各位覺得如何?@Ma3r、Kanashimi、Z7504、桐生ここ:@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018:-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 09:44 (UTC)
- 實作上是否能讓那些沒開設大宗評級(數量最多專題)的在專題橫幅內設定好參數即可?這樣看起來就不會因為沒開設評級、被覆蓋而出問題。機器人很難判別每個專題開設的評級,因此條件3會讓讓機器人無法自動作業。
- 僅供參考,就enwiki來說,純粹只考慮數量最多的評級。採用特殊評級的專題橫幅有特殊分類,機器人處理時不會動到其評級。--Kanashimi(留言) 2024年1月14日 (日) 10:35 (UTC)
- @Kanashimi:技術上不能讀取評級模板的
|QUALITY_SCALE=
內容和/class子頁面嗎?如果|QUALITY_SCALE=
填subpage,讀取/class子頁面就能得知該專題哪些評級有啟用。例如{{多面體專題}}是|QUALITY_SCALE=subpage
,所以讀取Template:多面體專題/class原始碼即可得到哪些級別是yes、哪些級別是no。如果|QUALITY_SCALE=
填extended則是定義於{{Class mask/extended}}的級別。未填或standard就是只使用大宗評級。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 11:00 (UTC) - 如果改成「若一條目有多個專題,通常由機器人自動依照規則4進行評級,但一旦出現爭議時則通用評級應以所有專題都有開設的級別為主。」機器人會不會好辦一點?意為機器人填寫值優先,但如果是人工評級時,才須考慮是否所有專題都有開設,且是遇到爭議之時,這是為了解決「
但是如果有人說「根據Wikipedia:條目質量評級標準#非標準級別和一些專題評CL的慣例,這篇列表內容充分,儘管支援條目的專題都沒有設CL級別,但既然WPBS能評CL那我就評CL」呢?所以,這個評級的定位該怎麽看?您作出了如此複雜的功能,但如果因爲使用規則不完善而部署而引發爭議,相信這是您不願意見到的。
」所描述的爭議情境。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 11:06 (UTC)- @A2569875 現在cewbot採用的方式是選出最大宗的評級(數量最多的評級),填入{{WPBS}}並且移除所有相同的評級。所有不同的評級都保留不動。不曉得這樣的作業方式是否會產生問題?--Kanashimi(留言) 2024年1月14日 (日) 11:16 (UTC)
- @Kanashimi:技術上不能讀取評級模板的
- 我在疗养,您自己请便。由于这个事情的业务逻辑挺复杂的,我不会拦着你用什么样的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)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
關於基礎條目的額外提議
|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近期改版{{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)
- Eric Liu 創造は生命(留言・留名・學生會) 2024年1月3日 (三) 04:47 (UTC)
- 已遷移討論@Ma3r、Ericliu1912:(User:Kanashimi應該已經知道了)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 05:51 (UTC)
您可以將整個討論移到其他區( ——
- Eric Liu 創造は生命(留言・留名・學生會) 2024年1月3日 (三) 04:47 (UTC)
- 唉呀感謝提醒我沒注意到。看起來改版是已經有共識的結果了。我把建議移到那個討論串下好了,這邊可以關閉了。--Kanashimi(留言) 2024年1月2日 (二) 09:37 (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)
- 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)
- 目前的patch是對所有的專題橫幅全面保留
- enwiki採用這種方法的過程與部分考量可參考w:en:Template talk:WikiProject banner shell#Issue with assessments not applying to WikiProject Lists template,關乎Special:PageAssessments。就我最近的測試,有些模板如您所述
- 例如Talk:康威多面體裡面{{WPBS}}指定了
|class=stub
,但{{多面體專題}}指定了|class=start
蓋掉了{{WPBS}}的|class=stub
,因此被自動加入Category:使用自訂專題評級的條目分類。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 11:46 (UTC)
- (:)回應:@Kanashimi:Category:使用自訂專題評級的條目裡面的頁面就是「一個頁面的評級」滿足「不繼承」的狀況。Category:使用自訂專題評級的條目指的是「考慮一個已使用{{WPBS}}指定評級為X的條目,其有至少一個專題橫幅評級值為Y,或不為{{WPBS}}指定的X」,而考察w:en:Category:WikiProjects using a non-standard quality scale分類內都是「專題橫幅模板」本身,我猜它是指「允許『不繼承、非正規』評級的橫幅」,而不是條目評級的「個例」;而Category:使用自訂專題評級的條目是指「已經『不繼承、非正規』評級的頁面」的「個例」而非橫幅模板本身。我想你有所誤解,我希望是元模板都保留
建好後,發現好像跟你說的不是一個東西? - 或許我們該用Category:使用非正規質量評級的專題橫幅?至於您說的「一個頁面的評級」很抱歉我不太理解,是否能舉個例子呢?--Kanashimi(留言) 2024年1月3日 (三) 11:34 (UTC)
- Category:使用自訂專題評級的條目,我是指「一個頁面的評級」滿足「不繼承、非正規」的狀況,不是「專題橫幅自己」滿足「不繼承、非正規」的條件。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 09:41 (UTC)
- 是的,w:en:Category:WikiProjects using a non-standard quality scale包含您所提的這兩種非正規、不繼承的狀況。--Kanashimi(留言) 2024年1月3日 (三) 07:47 (UTC)
- 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)
那您的bot有考慮到{{
- (:)回應:@Kanashimi:我指的是可能會有專題有自己的標準,導致評級值與{{WPBS}}不同的情況(如可能有些專題的乙級比較嚴格,導致該專題只能評丙級,但WPBS是乙級,其他專題也是乙級),而非「非標準評級」(non-standard quality)的情況。雖然兩者都需要保留著各專題橫幅模板的評級class參數。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 07:26 (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}}還有待討論
我有不同意见。英维的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)
- 已逾一周無新留言,因此根據WP:7DAYS,七日無進一步發言視為已達成初步共識;再依據WP:7DAYS「
- 這6620個條目全部運算完畢在預覽模式下Lua的後台輸出為:
- 公示7日,公示內容「將{{Vital article}}併入{{WPBS}}的
|vital=
参数」(同時執行方案①修改方案以及其佈署連結和方案②(±)合併{{基础条目横幅}}及{{Cba/discuss}}到{{WPBS}}(已由修改方案涵蓋)),另見此說明。(註:{{Vital article}}是重定向頁,亦會更改重定向目標)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 05:31 (UTC)
- 我們用實際數據來說話吧。Special:PermaLink/80500375這是隨便測試6620個條目進行基礎條目判別,並輸出{{Vital article}}字串。
- @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)
- Module:Vital_articles都已經分成類似雜湊表查詢了,有甚麼折騰的問題?已經高效率優化了好嗎。理論上,此實現的記憶體開銷甚至有望低於英文維基,因為英文維基只分成27個表,而中文維基是36個表,代表中文維基每個表的項目數量更少,在類似散列函數計算之後,要讀取的JSON更小,表示記憶體用量更少,單個表項目更少表示查詢更快。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 13:12 (UTC)
- 若能簡單改enwiki的程式碼來用,或許不必擔心折騰的問題。另一方面假如只留UI功能的話,是否乾脆維持原來的{{Vital article}}就好?--Kanashimi(留言) 2024年1月14日 (日) 13:06 (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)
- @Z7504:這根本不是BUG,因為你如果沒有給WPBS模板輸入評級,它本來就不應該顯示任何評級,因為那代表「該條目沒有指定通用評級」,不顯示評級才是正常現象。再來是,所有維基媒體基金會旗下站點都沒有佈署能給跨模板傳遞資料的擴展,所以你輸入在專題模板的class當然無法被WBPS獲知,如果可以,那就是魔法或者見鬼了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 06:48 (UTC)
- 這根本不是需要修復的BUG。WPBS中
|class=
參數的填寫一開始就是設計要讓機器人自動維護的部分,讓模板自動處理此問題反而問題更多且不切實際,更適合由一個外部機器人进行监察和更新操作,因此該意見應視為對上方議案有所誤會所提出的意見,同時|class=
參數的填寫也與本案《將{{Vital article}}併入{{WPBS}}的|vital=
參數》毫無關聯,因此應無效,若三日內沒有異議或進一步回應,則視為該意見已解決。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 08:40 (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)
- 不需要保證,因為機器人會自動填寫
- 總之全部都是Module:PJBSClass/main的問題,不鑲嵌模板就無法判斷,但「條目內掛了模板所以可以判斷」,您如果那麼清楚的話,那就直接建模板阿。標準的自欺欺人,結果居然是沒動腦過的回覆,被潑冷水真的剛好而已。這樣如何保證裡面可以不用寫上比如
- 這裡就是一個活生生的例子(比如這筆和這筆),這點小bug麻煩也先改了吧,不然都還要強制輸入才能確保正常顯示,問題不大才對。--Z7504非常建議必要時多關注評選(留言) 2024年1月22日 (一) 06:30 (UTC)
- @Z7504:我直接針對你最初的問題回答「
是不是還要寫
」,是,所以需要手動填上。本案並不包含甲乙丙初級自動判斷,公示也不包含這個部分,若你希望有甲乙丙初級自動判斷請另提他案,因為不在本案處理範圍內。 此外,你也無須擔心「{{WPBS|class=xxx}}
才能讓其強制正常顯示?是不是還要寫
」問題,因為下方Kanashimi已經申請機器人了,您無需手動填寫,此意見可以結案了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月23日 (二) 01:44 (UTC){{WPBS|class=xxx}}
才能讓其強制正常顯示?
- 本公示不包含甲乙丙初級自動判斷,若三日後還在要求甲乙丙初級自動判斷將視為無效意見。若希望
|class=
沒輸入也能自動顯示甲乙丙初級請另外提案謝謝,不在本案有辦法處理的範圍內。「這點小bug麻煩也先改了吧,不然都還要強制輸入才能確保正常顯示,問題不大才對
」本案是處理基礎條目自動化,而不包含class有沒有輸入的問題,因此不在此案處理範圍內,請另提他案,謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月23日 (二) 02:02 (UTC)
- 還真的沒有,那應該誤會了。那這
- @Z7504:請問WikiProject banner shell模板哪來的
- @A2569875:我試過了,沒有什麼大問題,但建議WikiProject banner shell模板中的
- 見公示聲明。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月24日 (三) 03:38 (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)
- 還有一點我要聲明,並不是不願意修訂module:PJBSClass/main,而是module:PJBSClass/main本來就是設計成要配合Kanashimi所提議的機器人提案而設計的,那麼要做的事情顯然是讓機器人提案推行順利,而不是去浪費時間修改module:PJBSClass/main。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月23日 (二) 05:06 (UTC)
公示期已到,期內無合理異議,且公示期內的意見之意見提出者已妥協,因此提案公示通過,將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月29日 (一) 05:36 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
{{WikiProject Biography}}參數案
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 《將Vital_article併入WPBS的vital參數》案已進入公示,現就是否將{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數併入{{WPBS}}進行討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月24日 (三) 03:41 (UTC)
- c.f. Wikipedia:机器人/申请/Cewbot/29。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月24日 (三) 03:43 (UTC)
- 本討論開始於2024年1月2日 (二) 09:53 (UTC)(發起討論的留言見此),當中包含了支持的意見,至今已逾一個月,因此根據WP:1MONTH「
互助客棧中的提案僅在7日內無新留言時或已討論達30日後,方可在已取得共識的前提下公示。
」,且本段落已逾8日無新留言,已超過一周無新留言,因此根據WP:7DAYS,有人附議此案(全部支持
視為該附議包含本案),而往後將近一個月沒有反對意見,因此視為已有初步共識,根據WP:1MONTH和WP:7DAYS將進行公示。(若三日無人對以上論述有異議將開始執行)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月2日 (五) 09:57 (UTC)
公示到期,期內無合理異議,提案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 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)
評級系統缺失問題
- (原始標題為「將{{Classicon}}與{{Class/icon}}同步」配合公告欄調整標題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月5日 (五) 07:47 (UTC))
配合上方#Random_Thought: 跟进英维的WikiProject_banner_shell改版因此需要解決評級系統缺失問題,故提出以下議案-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月25日 (一) 09:49 (UTC)
- 預計辦理流程:
- 修正評級系統被不當過濾掉的評級值: 公示通過等待佈署……
- 讓評級系統Special:页面评级均能正確接收到評級值,以便讓{{WikiProject_banner_shell}}工作順利。
- 同步各模板/块的評級值: 公示通過等待佈署……
- 評級元模板調用了多個不同的評級值轉換模板,但各評級值轉換模板/块的評級值定義有所出入,將會影響{{WikiProject_banner_shell}}的運作,因此需要修正。
- 將{{Classicon}}與{{Class/icon}}同步: 公示通過等待佈署……
- 以上都完成後,目前評級系統的圖是在各評級定義模板/块不一致,且Style也不一致,為了與XTools也統一,故作出此提案。
- 修正評級系統被不當過濾掉的評級值: 公示通過等待佈署……
- 目前先做到這樣,統整整個評級系統並修正評級系統缺失問題。若未來還有需要調整的會在辦理過程提出,滾動式修正,歡迎發表意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月5日 (五) 08:06 (UTC)
第一階段:修正評級值不同步問題
議案1:將{{Classicon}}與{{Class/icon}}同步
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
我認為應將{{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)
- (:)回應:@Shizhao:有支持,顯示評級的最後一個調用是{{WPBannerMeta/qualityscale/mask}},而{{WPBannerMeta/qualityscale/mask|future}}→「未来」,但在要送入
- 似乎未來之类的评级并未被整个评级系统完全支持?--百無一用是書生 (☎) 2023年12月28日 (四) 02:24 (UTC)
- 可以,但前者{{Classicon}}被全保護,只有管理員才能進行編輯,需要提{{ep}}。-- Willy1018(留言) 2023年12月26日 (二) 04:56 (UTC)
- (?)疑問:@Willy1018:那要不要{{Classicon}}重定向到{{Class/icon}}?剛才已補充{{Classicon}}所有功能到{{Class/icon}}了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月26日 (二) 02:33 (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}}至少先同步圖示;至於以後怎麼維護可以再討論。而且您的提議「
例如採用
」也還沒有patch,先現實一點吧,不要紙上談兵,我只想趕快同步圖示,並讓Style一致,評級圖示是評級圖示,其他圖示是其他圖示;評級圖示就該有評級圖示自己的Style,(!)抗议亂七八糟的不一致Style圖示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月2日 (二) 10:29 (UTC){{Icon|image_class}}
- 也好。那就等這個討論結束再說吧。--Kanashimi(留言) 2024年1月2日 (二) 10:30 (UTC)
- @Kanashimi:問題2
{{Icon|image_class}}
會導致評級模板輸出的值無法直接輸入此模板。評級模板肯定是輸出字尾沒有「_class」的結果,你這樣搞還要多寫一個轉換器,不是更難維護?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月2日 (二) 10:33 (UTC)- 我嘗試在Module:Icon/data加上下面的項目,似乎可以用?
- --Kanashimi(留言) 2024年1月2日 (二) 11:00 (UTC)
image_class = { image = "Symbol file class.svg", tooltip = "媒體文件頁", },
- @Kanashimi:我這個議案只是想先動全保護模板{{Classicon}},至少先同步圖示,但您目前這樣介入會導致共識亂了,連同不都做不到了,會導致花費更多「跑流程」時間,我想先同步,也做好patch了,都準備好了被你弄沒了?我想先動全保護模板{{Classicon}}至少先同步圖示;至於以後怎麼維護可以再討論。而且您的提議「
- 或許我們可以擴展{{Icon}}使之涵蓋我們想要的範疇,例如採用
- @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)
- 我想採用不同模板來處理同一件事的問題是較不易維護。--Kanashimi(留言) 2024年1月2日 (二) 09:49 (UTC)
- 但我覺得要有專題專用模板。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月2日 (二) 09:33 (UTC)
- 這邊最近在處理基礎條目與{{WikiProject banner shell}}的圖示問題(Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版,暨將{{Vital_article}}併入{{WPBS}}),(&)建議直接採用{{Icon}}會更通用。--Kanashimi(留言) 2024年1月2日 (二) 09:18 (UTC)
- @桐生ここ:完全不建議模板實現。現時模板實現是使用
- 此段落最後發言至今已逾七日,超過一周無新留言,因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月9日 (二) 12:56 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月9日 (二) 12:56 (UTC)
- 請管理員編輯Template_talk:Classicon#編輯請求_2024-01-16。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月16日 (二) 13:19 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
議案2:修正評級系統被不當過濾掉的評級值
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
上方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)
- 請管理員編輯Template_talk:WPBannerMeta/core#編輯請求_2023-12-28。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月15日 (一) 14:45 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
議案3:同步各模板/块的評級值
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
目前有多個被全保護的評級模板/块的評級值(如有的有漏掉、有的圖案、顏色不一致)並不同步,因此提議同步各評級模板/块的評級值。不曉得各位有沒有異議或意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 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)
- (:)回應:@Z7504:其實我有私下找User:AT了,但他一直說影響範圍太大要先討論 囧rz…………。我當然也希望能直接改啊,不然WP:7DAYS獲共識再公示7天半個月就過去了……-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月1日 (一) 12:05 (UTC)
- 此段落最後發言至今已逾七日,超過一周無新留言,因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 14:36 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 14:36 (UTC)
- 請管理員依照這則留言佈署相關編輯,也就是編輯以下模板:
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
提案已通過請求佈署
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 全案公示通過,請管理員依據以下留言:
- 佈署相關編輯,也就是編輯以下模板:
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
評級缺失問題目前辦理狀況
截至2024年1月5日 (五) 17:08 (UTC)已提出三案討論,三案皆在等待初步共識,以便公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月5日 (五) 17:08 (UTC)
進度 | 討論中 | 初步共識 | 公示中 | 部署中 | 已完成 | 後續維運 |
---|---|---|---|---|---|---|
*通用評級設立 | 已獲共識 | 已通過 | 已完成 | 已完成 | 進行中 | |
*評級繼承機制 | 初步共識 | 公示通過 | 已完成 | 進行中 | ||
評級值同步 | 初步共識 | 公示通過 | 已完成 | 進行中 | ||
修正過度過濾評級值 | 初步共識 | 公示通過 | 已完成 | 進行中 | ||
評級圖示同步 | 初步共識 | 公示通過 | 已完成 | 進行中 | ||
註:標有「*」表示是其他相關提案。 |
- 完成:在本次更新中,以下模板的評級資料已獲同步:
第二階段:依據先前共識將不是條目命名空間的評級分類從「XX級條目」改為「XX級頁面」
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
根據先前共識,需要將不是條目命名空間的評級「XX級條目」的分類改為「XX級頁面」,但因技術限制未能將「XX級條目」的分類改為「XX級頁面」,因此本案已提出新的方案,依據頁面命名空間添加分類,以實現該共識。具體執行方案在Template:WPBannerMeta/qualityscale/sandbox。同時將Wikipedia:条目质量评级标准移動到Wikipedia:页面质量评级标准,不知道各位有沒有異議?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月17日 (三) 04:57 (UTC)
- 副知@Ma3r、Kanashimi、Z7504、桐生ここ:@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018:-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月17日 (三) 04:58 (UTC)
- 沒有異議,
就是不知道會不會出現突發狀況。 --窝法乙烷 儿法梦碎 2024年1月17日 (三) 11:35 (UTC)- 已在多面體專題進行測試,詳見Category:分类级多面体页面、Category:模板级多面体页面,目前測試整個多面體專題尚未出現問題。待本案正式通過之後才會正式(►)移动分類頁面。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月17日 (三) 11:39 (UTC)
- 沒有意見,但在專題頁面(WikiProject)中使用到的{{Articles by Quality and Importance}}模板應一併解決顯示異常之問題(前幾天似乎還有這問題,現在不知道),雖然這模板平常根本沒什麼人在意 囧rz……(所以沒解決可能也沒差吧?因為專題本來就沒什麼人在意了)--Z7504非常建議必要時多關注評選(留言) 2024年1月18日 (四) 14:26 (UTC)
- 首先,結尾為「XX重要度」的分類不會移動,不在本計畫內,而{{Articles by Quality and Importance}}是讀取結尾為「XX級XX重要度」的分類,故基本上本案不會影響{{Articles by Quality and Importance}}。再來,如果這個真的要處理,要本案通過後,分類全部清理好,分類全數移動完成後才能處理,不然現在處理數字都會變成0。故應是下一個階段要處理的(或者共識是暫不處理),不是此案此階段討論範圍。此外,如果是{{Articles by Quality}}的話,直接更新分類名稱即可。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月18日 (四) 16:02 (UTC)
- 已逾一周無新發言,根據WP:7DAYS七日無進一步發言視為已獲初步共識,如本聲明無人有異議,將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月26日 (五) 00:32 (UTC)
- 已逾十日無新發言,根據WP:7DAYS一周無進一步發言視為社群「對以上『已有初步共識』的論述」沒有異議,因此將開始公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月5日 (一) 10:00 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月5日 (一) 10:00 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
分類改名準備
雖Special:Diff/80961277已公示通過,但因涉及的頁面眾多,因此宜再進行全站公告。公告完後將進行兩個階段完成:
- 階段1:全保護頁面編輯請求:Template:WPBannerMeta/qualityscale和Template:Class
- 由於該等分類都是以上被全保護的模板自動添加的,因此需要執行以上編輯請求。等編輯請求完成後,數萬個頁面緩存自動清理完畢後,分類將自動從「XX級條目」改歸為「XX級頁面」。
- 階段2:正式(►)移动分類頁面(可能是約階段1完成後再過一周)
- 等緩存全部清完,再將「XX級條目」分類,逐個(►)移动到「XX級頁面」分類。
公告一周。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 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)
申報
我是捍粵者,不過入不到舊電腦,唯有暫時用分身 捍粵者二(留言) 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)
- Account compromised???? -Lemonaka 2024年2月5日 (一) 01:05 (UTC)
- 好,不過如果我主帳有被動活動(留言、回退等),我用分身不會收到通知/提醒,有無方法可將主帳的通知也傳給分帳?--捍粵者二(留言) 2024年1月31日 (三) 15: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)
- 有绑定email可以找回密码。--桐生ここ★[讨论] 2024年2月22日 (四) 17:09 (UTC)
- 維基百科有所謂忘記密碼的處理措施。--姓哥名佬字吉拉(渴望長生天的祝福嗎?) 2024年2月22日 (四) 11:57 (UTC)
- 是,忘了備份。--捍粵者二(留言) 2024年2月14日 (三) 12:53 (UTC)
斜坡计划的安全补丁
|
很抱歉再次提出这个计划来打扰大家。针对先前讨论中各位比较关注的安全问题(政府可能留下门户的访问记录,可以与注册日志一一对应),在下最近想出一个解决办法:门户只发放临时账号,永久账号转发给IPBE授予系统处理。
大致思路是:用户在注册门户注册时,如果希望长期贡献,可以选择注册永久账号。提交申请后,门户提供一个临时账号用于编者即时编辑(可以限制使用时间,如一个月,或者根据ipbe授予的积压情况决定),同时将希望注册的用户名等信息发送给IPBE授予者。这样政府可能留下的访问记录只能对应到临时账号。可以在右侧查看此方案的简易流程图。
如果安全问题能够解决,我觉得应该不会有太大的阻碍,希望这次能够达到实行此计划的共识。谢谢各位。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月15日 (四) 11:39 (UTC)
- 没看懂。是自动发放一次性账号?怎么避免滥用。如何使门户可信。用户贡献归属等需求。注册日志时间问题,随机延迟不就行了,不过我觉得意义不大,因为访客数量有限、网络特征公开。--YFdyh000(留言) 2024年2月15日 (四) 16:37 (UTC)
- 如果門戶是維基媒體基金會的網站,不存在什麼可信不可信。用戶貢獻歸屬,新用戶會在意這個?別人只想編輯。滥用這個詞太抽象,不知道你指的是什麼,最好說明一下更具體的情況。--日期20220626(留言) 2024年2月15日 (四) 17:00 (UTC)
- 不看好基金会为此系统投入和有效地得出成果。这还不如研发与优化开放代理与反破坏机制的关系,使通过代理的注册和编辑更可见和可控(Tag/每笔人机验证/反破坏更敏感/二次审核,等等),将有益全域。
- 如果有用户声称自己用了门户但出事,是门户的问题(运维或网络特征),还是其他问题,如何解决信任危机。
- 会的,并且牵扯到傀儡判定、条目主编者等问题。
- 不太懂这样做对隐藏身份的意义,IP连接有日志,使用门户在特定时点做出收发(及对应流量特征)反而范围很小。
- 创建临时账号非人工审查,LTA可以用完就扔,未见反破坏机制,人工审封IP不太可靠、会误伤。
- 如果门户是为保障时间点隐私,就不宜支持即时提交编辑。
- --YFdyh000(留言) 2024年2月15日 (四) 19:28 (UTC)
- 「研发与优化开放代理与反破坏机制的关系」,基金會這方面有什麼動作嗎?沒有吧。談一個不存在的事情有什麼意思。我就是顧慮基金會的人可能會比較懶,不會特地去為了中維去開發這麼一個門戶。
- 那你等有人真的用了門戶出事情再說,不要自己去憑空臆測。本來就有人因為翻墻上維基百科被抓[1],說明翻墻上維基百科本身就有一定風險,也沒見基金會出來說要保護或者出面去介入。
- 傀儡判定,之前討論說允許把本地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)
- 这样甚至比现行IPBE还严格,要知道目前IPBE授予和自动授予没有太大的区别,如果我没搞错的话,如果填写正确且用户名不是明显破坏者的话都会给过。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年2月17日 (六) 05:36 (UTC)
- 1. 从基金会的开发效率及意愿来说,我倾向不让基金会做这个。维基人做这个又有信任度问题。2. 提议中的临时账号就是为了所谓安全,如果无所谓,IPBE申请表单系统就足够了——维基人可以帮忙。3. 如果临时账号提交一份条目,注册账号编修,或者多个临时账号编写,DYKC主编、傀儡活动怎么算。注册时间隐藏,听上去需要提前注册储备一些临时账号。如果是先用后审,似乎没意义啊。--YFdyh000(留言) 2024年2月17日 (六) 05:11 (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)
- 如果門戶是維基媒體基金會的網站,不存在什麼可信不可信。用戶貢獻歸屬,新用戶會在意這個?別人只想編輯。滥用這個詞太抽象,不知道你指的是什麼,最好說明一下更具體的情況。--日期20220626(留言) 2024年2月15日 (四) 17:00 (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)
- 前幾次討論都是在其他區;此案目前尚未涉及實際方針與指引修訂。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年2月17日 (六) 07:30 (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)
- 临时账号我倾向一次性而不是回收再利用,避免贡献混淆。预先批量申请,通过时发放账号密码。延时注册是可选需求,如果IPBE永久授权依旧很费时、批次授予,可能无所谓。如果只是要验证IP,可以将验证模块站点独立出来,也不需要将申请表单放在上面,直接一个附令牌的网址访问、自动检查风险(建议搭配人机验证)、确认,原网页/邮件系统发放账号密码就可以了,这样验证站点只获得了令牌和访客IP信息。未理解“IPBE授予系统”,除了风险检查机制,授予系统是否只是一个表单管理系统。--YFdyh000(留言) 2024年2月17日 (六) 16:08 (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)
- 1. 不需要,设定统一的用户名前缀及过滤器避免外人注册即可。2. 如前所述,表单等放在需代理的页面,可以仅将IP与人机验证页面放在小型VPS上(及用容器快速部署)、结果回传主服务器,域名不清楚能否免费或直接用IP+证书,证书用免费的。3. 沟通成本,暂未考虑,其他匿名用户一样的。4. 只有地址验证需要门户,表单、管理等系统都可以独立设置。--YFdyh000(留言) 2024年2月18日 (日) 08:38 (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)
- 印象里英文那套系统未设计本地化支持,改造可能费时费力、对目前缺乏帮助——只是一个表单管理系统。--YFdyh000(留言) 2024年2月18日 (日) 08:40 (UTC)
- 這裡還是副知一下@Bluedeck。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年2月19日 (一) 08:43 (UTC)
- 參考英維做法,VPO也是可以掛RFC的,既然也是要增加曝光度,不防也掛上RFC來嘗試讓更多人看到這個討論?不過RFC仍在早期運作,效果大概不大就是了。--路西法人 2024年2月26日 (一) 00:47 (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)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 虽然但是{{death}}的doc无此规定……您指的应该是将ta加入WP:RIP吧,{{death}}我觉得真死了应该加。--忒有钱 凪のあすから 10th Anniversary(留言) 2024年2月28日 (三) 13:45 (UTC)