维基百科:互助客栈 (全部)

本页使用了标题或全文手工转换
维基百科，自由的百科全书
快捷方式

本页互助客栈 (全部)是供以方便浏览所有讨论而特别设置。如果您想要新增讨论内容，请在互助客栈中选择最合适的版面。

按此刷新页面。

  欢迎光临互助客栈！  
   
  互助客栈是维基人议事相助之处，用以讨论消息、方针、技术以及编辑、求助等议题。
发表议题之前请搜索先前文章，遵守指导及礼仪。任何与维基百科无关的问题，请前往知识问答。

消息
方针
技术
求助
条目探讨
其他
讨论维基相关新闻与消息 讨论方针与草案 解决或报告技术疑难 解决在维基百科中所遇疑难 条目、模板、主题相关探讨 未符任何分区之议题
发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视

查看全部讨论

帮助目录 · 提出疑问 · wikitext基础 · 常见问题 · 常见错误 · 布告板 · 了解术语 · 即时协助 · 规则简述 · 使用指南

If you don't use Chinese, and want to contact Chinese Wikipedia, please leave your message here.
我想要…… 请前往……
如何有效并安全地访问维基百科的方法 如何访问维基百科
与繁简处理有关的问题 字词转换
协助或寻求条目的改善意见 同行评审
对某些特定来源的讨论 可靠来源布告栏
寻找参考文献 文献传递
参与即时讨论或通过电子邮件进行讨论 “即时讨论”或者“邮件列表”

消息

未知用户在求闻百科发布阐释“中国价值观基础上的客观观点”的文章

今天下午，有用户在求闻百科发布文章《何谓“中国价值观基础上的客观观点”？简谈维基式“中立”的虚伪》。作者在修订历史中被移除了用户名，在页面中署名为与“求闻”谐音的“邱文”。

求闻百科的五条基本原则中，有四条与维基百科的五大支柱大同小异，唯将“维基百科采用中立观点”替换为“求闻百科采用中国价值观基础上的客观观点”。--CuSO4 · 龙年大吉 2024年4月24日 (三) 12:38 (UTC)[回复]

求闻百科3年内100%倒闭。--Dnaimfz（留言） 2024年4月25日 (四) 16:56 (UTC)[回复]
Wikipedia:文明，谢谢。--Gongxiang01（留言） 2024年5月10日 (五) 16:23 (UTC)[回复]
请管理员注意，这个gongxiang01因为持续破坏、大打编辑战、伪造他人签名、多次辱骂、滥用傀儡、诉诸法律威胁，已经被多个wiki和论坛永久封禁。请管理员不要相信他说的任何话。--Dnaimfz（留言） 2024年5月10日 (五) 17:29 (UTC)[回复]
@Gongxiang01、Dnaimfz：中维不会因为其他网站的什么事就对某个用户怎样，只是用户自己要遵守中维的方针。( π )题外话：Google了一下用户名，发现了一群人在Note.ms上活动，感觉无法形容…… 难道是小学生？桐生ここ★[讨论] 2024年5月11日 (六) 02:36 (UTC)[回复]
相关资料：
--Dnaimfz（留言） 2024年5月11日 (六) 03:45 (UTC)[回复]
虽然其他网站的违规行为和zhwp无关，但一个人同时被数个毫不相干的网站封禁绝对是不正常的--Dnaimfz（留言） 2024年5月11日 (六) 03:51 (UTC)[回复]
全都是别人恶意封禁我的。而且除Fandom、Miraheze外的所有人与我无关（不是一个人）。Fandom的Backrooms Wiki因为打广告被封禁，Darkrooms wiki是发了一个违规的文章封禁，但是锑星百科就是随便封我的，还丑化贡献。Miraheze是因为英语太差被封了。Fandom太腐败了。--Gongxiang01（留言） 2024年5月11日 (六) 09:41 (UTC)[回复]
此处的Note.ms是什么意思？--YFdyh000（留言） 2024年5月11日 (六) 02:50 (UTC)[回复]
@YFdyh000：一个文本分享平台，你发的内容可以被别人修改。因为网站的开发者太懒，一直没给网站加上只读模式和密码的功能，所以被一群键政cosplay爱好者给占领了--Dnaimfz（留言） 2024年5月11日 (六) 03:27 (UTC)[回复]
无规则的在线网络记事本。--Gongxiang01（留言） 2024年5月11日 (六) 09:41 (UTC)[回复]
附上note.ms站长的帖子，https://www.v2ex.com/t/314777
--Dnaimfz（留言） 2024年5月11日 (六) 03:55 (UTC)[回复]
您好，我是一个维基百科的新用户，这些违规行为我都没进行。--Gongxiang01（留言） 2024年5月11日 (六) 09:50 (UTC)[回复]
要看有没盈利方式（无论是卖会员、广告，烧线，还是靠收捐助）。对于求闻，只能是大路朝天，尊重祝福吧。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月26日 (五) 01:07 (UTC)[回复]
你们这句话我记住了，三年后我会提醒你们的。嗯。--MilkyDefer 2024年4月26日 (五) 02:36 (UTC)[回复]
我无保证年限的观点，只是给了维持运营的经费来源推测。二哈二哈毕竟纯属人各有志的事。基金会能执大义旗去收捐款（还有商业服务）；求闻能不能做成百度那样（或者萌百？），或者大概靠的是爱？——Sakamotosan路过围观 | 避免做作，免敬 2024年4月26日 (五) 03:36 (UTC)[回复]
如果做成百度那样，和倒闭也没啥区别了--Dnaimfz（留言） 2024年4月26日 (五) 04:44 (UTC)[回复]
顺便一提，百度百科手机app将在6月底下线。--Dnaimfz（留言） 2024年4月26日 (五) 04:46 (UTC)[回复]
如果同样是站在中国立场价值观，百度百科比求闻要好的多，词条多，更新快，参与的人多，这三点中维都有些自愧不如。—-日期20220626（留言） 2024年5月13日 (一) 22:32 (UTC)[回复]
但是……代价是什么呢--Dnaimfz（留言） 2024年5月14日 (二) 04:28 (UTC)[回复]
若求闻百科的用户重视“中国价值观”的话，建议先好好检视求闻百科的中国条目的恶作剧，从武当山、庄子、锺离权、王玄甫、孔融、谢玄、骆宾王、王重阳、方国珍、李贽、周煌等等，到今天为止都有含有Wikipedia:持续出没的破坏者/User:Qqqyyy恶作剧内容。--Outlookxp（留言） 2024年4月29日 (一) 12:09 (UTC)[回复]
注：此处原有文字，因为违反讨论页指引，已由YFdyh000（留言）于2024年4月29日 (一) 15:56 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。[回复]
--Dnaimfz（留言） 2024年4月29日 (一) 12:55 (UTC)[回复]
这个话题是不是不太适合放在消息区？--Dnaimfz（留言） 2024年4月29日 (一) 13:08 (UTC)[回复]

你能去改日文维基，就已经算是很了不起了。维基正在系统性地封禁VPN等代理使用的IP地址，也就是说，你翻过墙后可以用所有网站，维基也能用，但有很大概率，你还没开始编辑，你就会被提示你的IP被禁止编辑了。换言之，你还没等着去这个“可以自由发表观点的平台”发表你的观点，你的嘴就被堵上了。

什么倒打一耙，不去骂墙反而骂维基，没见过这么不要脸的

维基另一种对欧美保守派的打压方法跟中国大陆的用户的办法有几分相似，即抬高编辑门槛。具体而言，对中国大陆的用户则是封禁代理IP地址，而对年龄普遍更大的保守派则是“wikitext”等编辑代码，维基软件的各种“弯路”也更难让年长者适应。这些都是直接在最开始就“劝退”潜在用户的方式，直接从源头处“解决遇到问题的人”。

阴谋论。

既然基金会里这么多号人马都跟美国政治绑上了关系，基金会做一些反映美国外交政策，针对跟美国外交关系不好的国家，那也是情理之中。

唉，美团

除了“九·一三”本身之外，基金会在2021年8月祭出的“NDA新规”限制中国大陆、伊朗等地的用户获取高级管理权限

鬼知道这些国家的管理员会不会突然像承德程序员一样被抓，然后有着管理员权限的账号落到铁拳手里，来打击别的维基用户--Dnaimfz（留言） 2024年4月29日 (一) 13:26 (UTC)[回复]
闫至今仍将维基百科当作“自由”发表某种观点的平台，同他多年前的中文维基高地论一样，而不是共构百科全书之地，即使被封禁了也毫无反省，还在用“你的嘴被堵上了”，以为其他人与他想法相同。--Akishima Yuka（留言） 2024年5月12日 (日) 14:27 (UTC)[回复]
胡编乱造、谎言惑众或许不合表面上的“中国价值观”，却是鼓吹的“中国价值观”的干将及其主使的实际所为。所以，求闻百科保留恶作剧条目也是江河行地、殊途同归、知行合一、无可厚非，再自然不过。— Gohan 2024年5月1日 (三) 04:17 (UTC)[回复]
就是这样--Dnaimfz（留言） 2024年5月6日 (一) 13:50 (UTC)[回复]
最后放个图，呵呵（当然这图和求闻没关系，是百度）https://i.imgur.com/2XFsUIK.png --Dnaimfz（留言） 2024年4月29日 (一) 13:35 (UTC)[回复]
您的图片链接无效。--YFdyh000（留言） 2024年4月29日 (一) 15:56 (UTC)[回复]
能打开呀，i.imgur.com/2XFsUIK.png--Dnaimfz（留言） 2024年4月30日 (二) 04:20 (UTC)[回复]
https://imgur.com/a/AeDcItn
这个呢？--Dnaimfz（留言） 2024年4月30日 (二) 05:01 (UTC)[回复]
AeDcItn能打开，2XFsUIK我被跳转到404页面。--YFdyh000（留言） 2024年5月11日 (六) 02:50 (UTC)[回复]
“回复”链接无法用于回复此留言。要回复，请点击“编辑源代码”使用完整页面编辑器。怎么回事？--Dnaimfz（留言） 2024年5月11日 (六) 03:29 (UTC)[回复]
那就不用管它--Dnaimfz（留言） 2024年5月11日 (六) 03:28 (UTC)[回复]
看了这篇文章，感觉下一段话值得注意。

再说欧美，欧美国家内部也有左右之分，而英文维基则屡屡被欧美立场偏右、偏保守派的媒体攻击“不中立”。如特斯拉的CEO马斯克就对维基上自己的传记条目感到极其不满。2023年9月，当他跟立场同样偏右的以色列总理内塔尼亚胡见面时，两人一起调侃自己的条目被立场偏左、偏自由派的维基编者给写得不堪卒读。英国《每日电讯报》评论员曾引用维基百科创始人之一的拉里·桑格（Larry Sanger）的话，形容英文维基上奥巴马的条目“甜蜜亲昵”（honeyed）、“没有丑闻”（scandal-free），而特朗普的条目则“尖酸刻薄”（peppery）。换言之，外文母语者（甚至维基创始人）自己都不认为外文维基百科是“中立”的。佐藤们和桑格们只能徒劳地喊上一喊。

这段话对巴勒斯坦人的屠夫内塔尼亚胡大加赞赏，并指控维基百科中对其罪行的客观揭露是左翼宣传，不知道的还以为内塔尼亚胡对巴勒斯坦人很友好呢。我从来都没有见过有中共支持者为以色列政府在巴勒斯坦暴行洗白的，据我所知，持这种立场的多数是曹科长这类右翼自由派。另外求闻百科在这篇文章中还只举了美英右翼对维基百科不中立批评的例子，而没有举欧盟右翼对维基百科不中立批评的例子，试图营造“美英右翼就能代表西方右翼”的虚像，这也是右翼自由派的老技俩了，毕竟与美英左翼和右翼差不多反华不同，欧盟左翼是有亲华倾向的，比如不屈法国的创始人梅朗雄批评佩洛西窜访台湾，现德国总理的德国社会民主党员朔尔茨支持重启中欧全面投资协定，德国左翼党议会副领袖塞维姆·达代伦批评现任欧盟委员会主席的德国基民盟党员乌尔苏拉·冯德莱恩呼吁欧盟采取政策挑战中国，莎拉·瓦根克内希特联盟领袖莎拉·瓦根克内希特称赞中国经济和产业政策，右翼自由主义者喜欢在对中共支持者的宣传中只举美国右翼的例子，不举欧洲右翼的例子，只是希望采取诱饵和开关策略，以并不相对美英左翼更加反华的美英右翼作为“诱饵”，以相对欧盟左翼更加反华的欧盟右翼作为“开关”，吸引中共支持者走向反华立场罢了。所以说，求闻百科大概率只是像这样的右翼自由派扛着红旗反红旗的工具罢了。--Zupspim（留言） 2024年5月6日 (一) 13:14 (UTC)[回复]
查了一下，那个techyan压根不像他自称的那么“爱党爱国”，呵呵了--Dnaimfz（留言） 2024年5月6日 (一) 13:35 (UTC)[回复]
充斥极端民族主义的文宣。单是“中国价值观基础上的客观观点”这个名字在逻辑上已经有问题了，他们掩盖逻辑问题的方式就是宣扬极端民族主义。Sanmosa 全方贫工之联合 2024年5月12日 (日) 02:14 (UTC)[回复]
不是民族主义，是粉红主义。他们信什么主义，取决于上面让他们信什么主义。--Dnaimfz（留言） 2024年5月12日 (日) 02:24 (UTC)[回复]
行，极端狂热崇拜。Sanmosa 全方贫工之联合 2024年5月13日 (一) 13:47 (UTC)[回复]
这流氓文风一望知就是User:Techyan的手笔，总是拿一些边缘个例来论证，令人捧腹，其中的大部分猜测和阴谋论我觉得闫自己都不相信。--Akishima Yuka（留言） 2024年5月12日 (日) 14:09 (UTC)[回复]
顺便一提，求蚊百科其实是闫恩铭的个人站点，从一堆所谓“文件”到“社论”都是Techyan所写，后面还自欺欺人地移除了所有相关页面的修订版本，但是他的文风是一眼就能看出的。--Akishima Yuka（留言） 2024年5月12日 (日) 14:13 (UTC)[回复]
使用爱企查、企查查和天眼查可以查到，求闻百科的母公司“无锡共笔全书网络有限责任公司注册资本为20万元，最大股东为李尔特（领英，底下志愿者经历里写了维基百科），最终受益人为闫恩铭（即Techyan），下面还有三人持股，求闻百科的“裁决委员会”页面显示该网站有五名最高权限持有者，可以推断出就是五名公司股东。
更多企业信息需要付费查看，更多求闻页面需要登录查看。
另外，这帮人又整了个“许可百科”，这是要往Fandom发展的节奏吗？--Dnaimfz（留言） 2024年5月12日 (日) 16:00 (UTC)[回复]

CopyPatrol已支持中文维基百科的侵权检查

在这里,说明文档：m:CopyPatrol。这是抄袭检测服务商Turnitin与维基百科合作的一个项目--百無一用是書生 (☎) 2024年5月5日 (日) 11:30 (UTC)[回复]

好奇他们用什么中文来源训练侵权侦测？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月5日 (日) 16:20 (UTC)[回复]
训练？这不是大语言模型。--YFdyh000（留言） 2024年5月5日 (日) 19:27 (UTC)[回复]
啊我指的是用以比较的资料来源（ —— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月15日 (三) 14:15 (UTC)[回复]
互联网爬虫和文献数据库，爬虫当然是全网。关于具体抓取到哪些网站、频次，应该属于他们的内部信息。--YFdyh000（留言） 2024年5月15日 (三) 14:21 (UTC)[回复]

This Month in GLAM: April 2024



Headlines
Read this edition in full • Single-page

To assist with preparing the newsletter, please visit the newsroom. Past editions may be viewed here.

Wikidata weekly summary #627

Here's your quick overview of what has been happening around Wikidata over the last week.
This is the Wikidata summary of the week before 2024-05-13.
Please help Translate.

Discussions

Press, articles, blog posts, videos

Tool of the week

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

This Month in Education: April 2024

本月教育

第13卷 • 第4期 • 2024年4月

本期头条

报名参加语言社群会议（5月31日 16:00 UTC举行）

大家好，

下一场语言社群会议将于几周后举行，日期与时间是5月31日 16:00 UTC。如果您有兴趣，可以在此wiki页面报名。

这是由参与者驱动的会议，我们在会议中分享与各项专案相关的语言更新，共同探讨与各语言版本维基相关的技术问题，并集思广益寻找可能的解决方案。例如，在上次会议中，讨论主题包括机器翻译服务（MinT）及其目前支援的语言和模型、Kiwix团队的在地化工作，以及孟加拉语维基文库使用的档案数值排序所面临的技术挑战。

关于分享您所在的专案相关的技术更新，您有什么想法？您希望在会议期间讨论什么问题？您是否需要从英语到其他语言的口译支援？请传送电邮至ssethi(__AT__)wikimedia.org与我联系，并新增议程项目至此文件中。

我们期待您的参与！


MediaWiki message delivery 2024年5月14日 (二) 21:22 (UTC)[回复]

The Signpost: 16 May 2024

News, reports and features from the English Wikipedia's newspaper
Read this Signpost in full · Single-page · Unsubscribe · Global message delivery 2024年5月16日 (四) 11:00 (UTC)


方针

提议提高条目评选投票资格门槛

本主题全部或部分段落文字，已移动至Wikipedia_talk:新条目推荐/候选。执行人：Sanmosa 全方贫工之联合 2024年5月14日 (二) 11:00 (UTC)。[回复]

再拟议立国际关系命名常规为方针

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:命名常规 (国际关系)。

有鉴于前次讨论中提及的所有合理异议已获解决，这里再一次重新提议将国际关系命名常规立为方针。Sanmosa Szégyen a futás, de hasznos 2024年4月20日 (六) 02:20 (UTC)[回复]

这里对于（部分）可能会被认定为未获解决，但个人认为不甚合理的异议进行回应：
  • 捍粤者在被永久封锁前多度发表中华极端主义言行，在前次讨论中已有一次且因而被警告，前次讨论中的其他用户亦普遍不认可其见解，因此基于社群的主流意向不接纳其意见。
  • 有关页面分类排序的部分，由于提案只是为中文维基百科现行的排列习惯进行归纳，因此“排序毫无章法”一说并非实情。再者，将既有的排列习惯成文化并不会干扰现有的条目命名习惯，这算不上什么“向前冲”，而这也与WT:共识#共识建立的递进步骤的提议会干扰社群成员参与讨论的习惯有本质上的不同。
  • “一堆难以下咽的文字”之说需要额外的客观举证，否则无异于单纯的谩骂。“能使用最简称呼就使用最简称呼”有机会违背易于识别的要求，比如该意见举出的“爱爱关系”例子虽然语义上确实仅可能指爱沙尼亚与爱尔兰两国之间的关系，但一般读者不太可能在第一时间判断到“爱爱关系”一词中提到的两个国家名称的缩写分别指爱沙尼亚与爱尔兰。
以上。Sanmosa Szégyen a futás, de hasznos 2024年4月20日 (六) 02:41 (UTC)[回复]
(＋)支持。--CaryCheng（留言） 2024年4月20日 (六) 14:46 (UTC)[回复]
(＋)支持：我一向反对国际关系条目名用“单字简称式”。--Tp0910（留言） 2024年4月20日 (六) 20:41 (UTC)[回复]
不知何时能进到“深水区”，例如中英关系、中美关系，目前部分已更改，例如中日关系→中国—日本关系、中俄关系→中华人民共和国—俄罗斯联邦关系。另外在Wikipedia:命名常规#易于识别中提到：“条目标题应该易于识别，尤其是对于条目主题有一定认识者应该能够识别条目主题为何。”对于国际关系有一定认识者都应该能够识别了，更何况对于没有一定认识者，所以才更不能用“单字简称式”。--Tp0910（留言） 2024年4月20日 (六) 22:29 (UTC)[回复]
但是传统的这几个国家（英、美、德、日、俄…）确实单字常用，如果检索Google Scholar的话，scholar:中英关系有相当数量的结果，还有日语维基百科也用的ja:日英関系，如此限制单字使用可能违反Wikipedia:命名常规#使用常用名称，可能也原创研究，真的会有人写书命名《中国—日本关系史》吗，可能除了中文维基百科之外很少有人用。--Kethyga（留言） 2024年4月20日 (六) 23:48 (UTC)[回复]
所以有个Wikipedia:命名常规 (国际关系) #特殊情况。但对于已经更名的条目而言，又存在着不一致了。或许双边关系史的命名可以例外。--Tp0910（留言） 2024年4月21日 (日) 02:42 (UTC)[回复]
双边关系同样，不只是历史。个人反对已经有可靠来源、且常用的情况下去原创。即使对于美日关系美国国务院都直接用美日外交关系大事记（日维用ja:日米関系）。本来单字也是中文（汉字文化圈）的习惯。类似的甲午中日战争中文会有人说甲午中国—日本战争吗？--Kethyga（留言） 2024年4月21日 (日) 11:51 (UTC)[回复]
实体与实体之间的关系是全面的、广泛的，与纯粹的历史还是有所不同，所以我说“或许双边关系史的命名可以例外”，例如甲午战争、国共内战……，当然不会傻到改为甲午中国—日本战争、中国国民党—中国共产党内战，而且这些也不是目前命名常规 (国际关系)中所明确定义的实体（地方、国家、多国集团、国际组织）。日美关系于日前已改为日本—美国关系。--Tp0910（留言） 2024年4月21日 (日) 13:01 (UTC)[回复]
@Kethyga：我们可以规定仅在此类条目之标题命名上使用此种格式，但内文大可照用简称，其余衍生条目亦不必更易，我认为这并不妨碍全局。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月21日 (日) 14:33 (UTC)[回复]
@Ericliu1912：还是想提一下我这里提议定为方针的是命名常规，命名常规本即不管束内文用词。Sanmosa Szégyen a futás, de hasznos 2024年4月21日 (日) 23:51 (UTC)[回复]
那得取决于您维当“条目标题”是啥玩意，想带出啥作用。《中国大百科全书》要求“XX，又称YY”的时候，不要用“YY”作主语的。我想是百科全书出于词典，有不宜更改描述主题的习惯；或者规范性的问题。不过我想这种情况不包括简称。另外，如Kethyga上边所说的，“中国—日本关系”既不见使用，那您维“中国—日本关系，简称中日关系”这种表达方式就是错的，根本不存在这样的全称。--Ghren🐦🕛 2024年4月27日 (六) 16:00 (UTC)[回复]
这样会背离命名一致性的要求，子命名常规本来就是为（在专题下）达致命名一致性而设的。Sanmosa Szégyen a futás, de hasznos 2024年4月21日 (日) 23:55 (UTC)[回复]
一致性弱于Wikipedia:命名常规#使用常用名称。个人反对在已有常用词的情况下原创和使用不常用的规定。真有中文读者看不懂中日关系指的是什么，“可识别性及避免产生歧义”哪里有问题，台湾学者蒋永敬《近百年中日关系论文集》，个人检索台湾的华艺学术“中日关系”1700多条，“中国日本关系”4条，可以说“中日关系”绝对常用，“中国日本关系”几乎没人用。
此外，个人想提醒下之前订立的Wikipedia:格式手册/朝鲜半岛用语（必然会涉及到条目命名问题），其中新加坡、马来西亚不用或少用“朝鲜”、-“南韩”， Sanmosa基于港台常用"南韩"将韩国改为南韩，不知道是否违反Wikipedia:避免地域中心，本来“南韩”就已经是基于地域中心的用词，虽然可能是地区常用词。
不要制定一个没人用的规则，回来还得修复。--Kethyga（留言） 2024年4月22日 (一) 09:12 (UTC)[回复]
@Kethyga：（1）然而子命名常规在执行上优先性高于母命名常规，而且“子命名常规本来就是为（在专题下）达致命名一致性而设的”这点依然成立。（2）上一个指控（注意我的用词是“指控”而非“提出忧虑”）地区词地域中心的人是钉钉，社群当时已经驳斥过不只一次了，我想我应该用不着在这里重新抄送当时的驳斥。Sanmosa Szégyen a futás, de hasznos 2024年4月22日 (一) 23:54 (UTC)[回复]
子命名优先的前提是该规定合理，维基百科还有Wikipedia:非原创研究要求，使用实际不用或很少使用的名称显然不合理，个人简单看了中英几个方针还没有哪些方针命名明显去违反常用名称原则的。本来使用常用名称，如果读者（不管什么程度的）去搜索能找到很多结果，现在很少的结果，是说中文世界对于该项议题没有研究吗？
朝韩的命名问题即使是现实世界的地域中心，依然是基于地域中心的，可能和编辑无关，另外还没解决新加坡、马来西亚的问题。--Kethyga（留言） 2024年4月23日 (二) 05:56 (UTC)[回复]
依我看，钉钉所提出来的问题和Kethyga提出来的问题完全是两回事。可能您需要重新看一看他的留言。--Ghren🐦🕑 2024年4月23日 (二) 06:10 (UTC)[回复]
就算如此，这个问题也与国际关系命名常规无关，这顶多只能算是转换组设置的问题，这问题已经在走RFC流程了，如果继续在这里讨论这个问题的话就属于FORUMSHOPPING了。Sanmosa Szégyen a futás, de hasznos 2024年4月23日 (二) 15:01 (UTC)[回复]
问一下朝鲜半岛南北关系这一标题根据草案要求应该怎么修改？--东风（留言） 2024年4月26日 (五) 06:05 (UTC)[回复]
当成一般的两国关系条目来命名，毕竟两国都相互承认对方的存在了。假如不考虑“命名先后顺序按照中文常用语序确定”的条件的话，一个是“Korea, North”，一个是“Korea, South”，我预期的写法是“朝鲜民主主义人民共和国—大韩民国关系”。如果把“命名先后顺序按照中文常用语序确定”也纳入考量，那“朝鲜民主主义人民共和国—大韩民国关系”或“大韩民国—朝鲜民主主义人民共和国关系”都是可能的选项。不过，我也不是没考虑把朝鲜半岛南北关系也纳入例外，这点我认为并非不能讨论。Sanmosa Szégyen a futás, de hasznos 2024年4月26日 (五) 08:22 (UTC)[回复]
不同意如此改。朝鲜半岛情势有其历史及政治因素。若有德国、越南类似条目同理。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月28日 (日) 08:38 (UTC)[回复]
那我也把它纳入例外就是了，这点我倒是持开放意见的。Sanmosa 全方贫工之联合 2024年4月30日 (二) 03:07 (UTC)[回复]
一定有比用英文字母更好的排序方法 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年4月25日 (四) 04:20 (UTC)[回复]
@魔琴：考虑到现时的排序习惯就是以英文字母为准，个人认为英文字母已经足够好，而且国际关系命名常规影响的条目众多，如果其规定与现时的排序习惯不相同，将对中文维基百科的条目维护造成重大负担。再者，既然你声称“一定有比用英文字母更好的排序方法”，那请你提出具体的排序方法。Sanmosa Szégyen a futás, de hasznos 2024年4月25日 (四) 07:03 (UTC)[回复]
个人更倾向于按ISO 3166或者衍生方案排，毕竟3166就能解决绝大部分政区的排序问题。不过如果推行不了的话建议在手册用“暂遵从英文……”留以后再议（等到双边关系全部建立完了就不需要议了）。反正规定直接写按其他语言排序总是感觉怪怪的，偷偷摸摸的好[开玩笑的]。本来想问土耳其是按Turkey还是Türkiye，不过好像没差，就没必要费心思担心这个了。开脑洞的话，各地中文名不一样其实也可以排的，有差异的按照最前面就好了：譬如象牙海岸和科特迪瓦，按拼音/注音排都是科特迪瓦靠前，就按科特迪瓦排，我觉得是没问题的。当然，如果拼音/注音不行还可以用Unicode、康熙甚至说文（逐渐离谱），但是都太麻烦了，不实用 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年4月25日 (四) 19:49 (UTC)[回复]
反对从ISO，会构成对台湾的歧视，这我上次已经提过了。不倾向于写成“暂遵从英文……”，中文维基百科的永久暂行办法已经够多了。Sanmosa Szégyen a futás, de hasznos 2024年4月26日 (五) 05:44 (UTC)[回复]
台湾有自己的代码啊，倒不如说歧视其他的科索沃、索马里兰之属（不过至少科索沃可以用RS-KM）。再说了这类情况特殊处理也不是维基百科的问题啊。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年4月30日 (二) 07:05 (UTC)[回复]
@魔琴：这本来确实不是维基百科的问题，但要真跟了ISO的话，那就真成维基百科的问题了。Sanmosa 全方贫工之联合 2024年5月1日 (三) 13:59 (UTC)[回复]
用ISO排序，台湾一样是排到“T”的地方啊。表面上照搬根本不会有什么问题。--Ghren🐦🕒 2024年5月12日 (日) 07:52 (UTC)[回复]
我担心的是一旦在这里引入了ISO，那其他地方势必也会要求同样引入ISO，这里ISO没构成对台湾的歧视不代表在其他地方ISO同样不会构成对台湾的歧视，因此我不能开这个头。ISO就是个Pandora's box。Sanmosa 全方贫工之联合 2024年5月12日 (日) 14:19 (UTC)[回复]
(＋)倾向支持。◯澳关系、中◯关系之流名称根本不符合通用的命名常规的防止歧义、易于识别两大原则，早应更正，仅仅在常用一个原则上胜出并不符合命名常规文意。本案算是在国际关系上加以明确。至于“无特定中文常用语序”情形的排序，英文字母最为简便；若为免所谓“英文”中心，可考虑页面ID为奇数则顺序、偶数则倒序，或者相反；事件条目国际反应章节亦可采用此法。--— Gohan 2024年4月26日 (五) 03:50 (UTC)[回复]
可能还需考虑中文六地用字差别，不过出于减少链入成本的因素，我还是倾向支持对一些绝对不会产生歧义的简称，允许使用简称，或者靠创建重定向的方式减少链入成本。--重庆轨交18（留言） 2024年5月16日 (四) 23:33 (UTC)[回复]
提案并不禁止，甚至某程度上鼓励建立重新导向。Sanmosa 人人皆王 2024年5月17日 (五) 06:24 (UTC)[回复]
我也反对一刀切禁用单字标题，如上所说大国关系一般单字压倒性比全名更常用-某人✉ 2024年4月26日 (五) 09:45 (UTC)[回复]
我的草案也好像没有一刀切禁用单字标题吧？Sanmosa 全方贫工之联合 2024年4月26日 (五) 10:19 (UTC)[回复]
“实体名不得使用单字简称，以提高可识别性及避免产生歧义。”还有下面不也说现行的只是临时措施，在未来也应该逐步废除？还是我理解错了？--某人✉ 2024年4月26日 (五) 22:28 (UTC)[回复]
“特殊情况”的规定可以override“基本原则”的规定。“特殊情况”的规定虽然属于临时措施，但未来具体应该如何逐步废除还需要另外的社群共识，至少我看不到短期内废除“特殊情况”的规定的可能性。Sanmosa 全方贫工之联合 2024年4月30日 (二) 03:10 (UTC)[回复]
既然已经有人将中日关系移动到了中国—日本关系，就说明这条限制性“临时”规则会误用。使用一字线（“—”）属于外语中心主义的译名。类似的话，是否可以将彭定康改为克里斯·帕滕（Chris Patten）--Kethyga（留言） 2024年4月30日 (二) 03:30 (UTC)[回复]
@Kethyga：这不属于误用，草案本质上就是discourage单字标题的，“特殊情况”只是不要求使用单字简称的条目名必须全部改用非单字简称。不赞同“外语中心主义”的论调，我已经提过了“提案只是为中文维基百科现行的排列习惯进行归纳”，连接词或符号到底该用什么在现阶段讨论并不适合，这样只会妨碍共识形成的进程。彭定康的情况不同，外交关系与人物不是同一回事，而且“彭定康”属于当时香港的官方译名，有名从主人规则背书，然而外交关系作为“称不上有‘拥有者’的情事”，被名从主人规则所认为不能适用名从主人规则。Sanmosa 全方贫工之联合 2024年5月1日 (三) 13:58 (UTC)[回复]
按您的标准，类似的条目日俄战争会变成日本—俄国战争，英日同盟会变成英国—日本同盟，然而Anglo-Japanese Alliance在香港教育局推荐的英汉词汇和中国大陆百科全书都是也是英日同盟、[2]。既然你认为名从主人，那首尔政权也不应该按照地区词改用“南韩”，也不清楚为什么一个坚持使用常用名称，而另外一个却要限制使用常用名称。此外您限制使用常用名称，还有原创研究之嫌。--Kethyga（留言） 2024年5月1日 (三) 15:02 (UTC)[回复]
外交关系与战争、外交同盟不完全是同一回事，我认为不能称之为“类似的条目”，而且就算这真能算“类似的条目”，我的草案目前规范的只有外交关系条目，你这里如此外延曲解了我的草案，故而是不适当的。Sanmosa 全方贫工之联合 2024年5月1日 (三) 16:04 (UTC)[回复]
Wikipedia:维基百科不是什么#维基百科不是发表创新意念的地方，“发表原创或初级研究 ，例如提出新理论及解法、原创意念、自创定义或词语等。”--Kethyga（留言） 2024年5月2日 (四) 00:40 (UTC)[回复]
我倒是认为你这种不适当的外延才是真正的原创研究。Sanmosa 全方贫工之联合 2024年5月2日 (四) 09:21 (UTC)[回复]
涉及到维基方针就不正面回答。
您自己说的“使用‘国际关系’一名是考虑到日后社群有可能会打算为其他国际关系专题下的条目的命名作规范”，当然是类似条目和合理的扩展。--Kethyga（留言） 2024年5月3日 (五) 11:49 (UTC)[回复]
我下方有提过我调整了草案用词了，就现时的草案用词而言，你说的并不成立。Sanmosa 全方贫工之联合 2024年5月3日 (五) 13:40 (UTC)[回复]
目前讨论中存在的分歧还比较多，比如部分单字关系实际上更为常用、南北（东西）朝鲜/德国/越南此类命名问题、排序问题，还有我自己认为的草案内容举例问题，如草案中的中国—俄罗斯关系实际上为重定向，不宜作为前边论述给出的条目例子，还有后续提到的多个红链应该以本地现有的条目为例，如果没有，可能的理由是这种标题事实上在本站非常不适用。还有一个比较简单的问题就是文中提到的“国家与地方关系”以及“两地方关系”是否适用于标题“国际”一词，如果仅取狭义的“国”与“国”之意，草案标题可能需要改成“双边”之类。因此，在讨论达成比较圆满的共识之前，暂不支持轻易公示及通过。--东风（留言） 2024年5月1日 (三) 17:10 (UTC)[回复]
@Easterlies：
  1. 国际关系命名常规主要是想要确立命名一致性，并确保条目名称符合防止歧义与易于识别的要求，而且现存大部分的外交关系条目都使用“XX—YY关系”的格式，我这里也只是把中文维基百科现行的排列习惯归纳起来而已。
  2. 你说的“举例问题”我不认为是问题，红色连结的出现也有可能意味着到现在还没有人建立该条目，或是该等类型的条目本身不宜建立，然而我没看到社群有达成过任何类似后者的共识（就国际关系专题层面而言）。至于中国—俄罗斯关系的情形，我认为现状是不适合的。
  3. 使用“国际关系”一名是考虑到日后社群有可能会打算为其他国际关系专题下的条目的命名作规范，这时候新规范可以直接写入WP:命名常规 (国际关系)而无须另立页面。
Sanmosa 全方贫工之联合 2024年5月2日 (四) 09:35 (UTC)[回复]
方针指引命名可以写“国际关系”（取国际关系专题之意），但实务上涉及条目多是双边关系条目（也包含非国家之地区或国际组织间关系），所以内文用“双边关系”较为清晰，也可省去计较国家地区地位的多余麻烦。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月2日 (四) 12:31 (UTC)[回复]
内文用字调整了，然而“省去计较国家地区地位的多余麻烦”却不见得。比如“任何情况下均不当使用‘<国名／国号乙>—<地方（特定时期）甲>关系’的格式命名条目”这条条文就限制了国家与地方关系条目的命名中，地方必须置前。Sanmosa 全方贫工之联合 2024年5月2日 (四) 13:27 (UTC)[回复]
目前的草案有对中国大陆—香港关系作规定吗。--东风（留言） 2024年5月5日 (日) 02:58 (UTC)[回复]
@Easterlies：由“两地方关系条目命名”章节规范，而且现时的命名是符合该拟议规范的，倒也不用更动条目名称了。Sanmosa 全方贫工之联合 2024年5月7日 (二) 00:38 (UTC)[回复]

修订删除方针明确允许删除没有来源30日以上的条目

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:删除方针。

修改WP:DP#REASON当前的7：

现行条文

彻底尝试后仍无法由可靠来源查证的条目，尤其是不符合任何关注度指引（《通用关注度指引》或者其它专题关注度指引），且已经挂相应模板30天的条目

提议条文

所有版本均没有可靠来源查证的条目，尤其是不符合任何关注度指引（《通用关注度指引》或者其它专题关注度指引），或已经挂相应模板30天的条目。

删除方针中的“务必先考虑改善页面”和“彻底尝试后”在实践中导致了某些页面“现在没有来源，但是仅仅因为可能有来源”而保留。其指导的行为导致了读者得到不可靠的信息，影响了维基百科的质量。

现在的cat:缺少可靠来源的条目和cat:缺少来源的条目的统计数和约为4.5万，足以证明可供查证方针并没有得到完全的执行。--落花有意12138 2024年4月20日 (六) 14:52 (UTC)[回复]

虽然这能增加存废提出和倒逼质量提升，但这与过往实践有很大不同。“或已经”似乎意味着没有来源的条目能直接提删。怀疑社群无力妥善处理众多条目，同时，有来源但不够或不准的条目也有很多，只删除无任何来源的条目可能留下漏洞，且某些可能明显有来源。对于“不可靠的信息”而未做查证，倾向更显著和充分的标注。--YFdyh000（留言） 2024年4月20日 (六) 23:17 (UTC)[回复]
@YFdyh000：“无力妥善处理”可以通过有序的逐步删除得到处理，后面指出的其他问题确实是对可供查证的违反。但是两者均不是本提案的讨论范围，这里讨论的是“完全没有来源的条目该不该删”--落花有意12138 2024年4月27日 (六) 14:12 (UTC)[回复]
你不想着去找来源，只想着删，就是无序，很多地方都指出先尝试改进，实在是找不到来源再去提删。--日期20220626（留言） 2024年4月27日 (六) 14:15 (UTC)[回复]
意见：标识++，清理+，直接移除-，直接存废--。如果提案是大量标识无来源内容供之后清理和预告移除，我可能会中立，但计划需有序逐步。目前不应删除整个条目，只因没人查证而非无法查证，删除是使内容不再可用（无法查证、贡献灭失）；草稿的自动过期删除相似，我就不太赞成。--YFdyh000（留言） 2024年4月27日 (六) 14:30 (UTC)[回复]
“且”改“或”意味着只要挂著模板，就算实际上已经不再需要挂模板也依旧需要提删，我不认可。Sanmosa Szégyen a futás, de hasznos 2024年4月22日 (一) 01:31 (UTC)[回复]
这种情况显然应该移除模板而不是提删，如有这种情况发生，应该提示这位用户注意常识和本维基的目标，而不是方针的问题。而且实际上不应删除的会在存废讨论被保留。--落花有意12138 2024年4月27日 (六) 14:17 (UTC)[回复]
"彻底尝试后仍无法由可靠来源查证的条目"和“尤其是不符合任何关注度指引，且已经挂相应模板30天的条目”才是两类不同的条目，这样改法会过度扩大删除范围，甚至还会波及部分老旧且本来就没有脚注来源的条目，即使这些条目并没有标注。还是认为没来源的情况，挂标识作为留意，而不是做删除派。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月23日 (二) 01:14 (UTC)[回复]
对，原本方针讲的是提删无关注度条目，现在被落花有意扩大成提删无来源条目。--日期20220626（留言） 2024年4月23日 (二) 03:38 (UTC)[回复]
如果认为没有关注度应该提删，我不反对，可以另开一条，而不是原来那样的and关系。关注度和可供查证是两个方针，应该一并遵守。--落花有意12138 2024年4月27日 (六) 14:39 (UTC)[回复]
如果是条目内部有文字没有来源，可以删除，但不是一定要删除，整个条目也是如此，不应该让没有来源的条目强制删除。--日期20220626（留言） 2024年4月27日 (六) 15:08 (UTC)[回复]
原本的方针挺好的，不必修改。有来源也不代表什么，理论上可以学折毛，乱塞来源；维基百科本身就是不可靠信息，加不加来源都不改变这个性质；删除方针第二段明确写有“我们应该尽量保留所有合乎百科全书目标的页面，删除应该是最后的选择”，提案与这句话精神不符，应该尝试去找来源，而不是想着去提删，实在找不到来源可以挂关注度模板，而且中维要是一堆条目缺失，也让中维失去存在的意义。--日期20220626（留言） 2024年4月23日 (二) 03:21 (UTC)[回复]
@日期20220626：
前面的发言是针对有来源的条目质量如何，不是本讨论的范围。
既然已经挂模板30天了，说明大概率没有人愿意找来源，上面提到的积压数也是一个侧面证据。既然如此，我们需要讨论的就是无来源的条目是放在原处更好还是删除更好。我的意见是删除更好。
如果您仍然认为这些条目有改善的空间，那么我认为转草稿也可以。--落花有意12138 2024年4月27日 (六) 14:29 (UTC)[回复]
“我们应该尽量保留所有合乎百科全书目标的页面，删除应该是最后的选择。”可供查证是方针之一，“删除更好”是倾向之一，但目前不是一直挂着POV、BLP就应该清除内容以免违背。
除非有作业小组和流程持续，并且这些草稿不会自动过期，不然转草稿肯定不是正确选择。维护模板更显著能做到类似草稿的目的，或者新设“伪草稿”。--YFdyh000（留言） 2024年4月27日 (六) 14:41 (UTC)[回复]
@YFdyh000：现在似乎存在一种假设，就是没有来源的内容似乎是什么天然的奇石一样，不需要积极改进也能很好看。但是事实上这些内容是泥沙和金沙的混合物，辨别哪些是金子的成本并不少于重新制造金子。并且对于读者，他们不能被期望能够做那些连“维基百科编者”都很难做成的事情。我认为，维基百科不应该提供掺着沙子的粥，因为网络上已经不缺少这种信息来源了。--落花有意12138 2024年4月30日 (二) 11:32 (UTC)[回复]
有来源的也是泥沙和金沙的混合物，所以表面上的有来源才真的是看上去很好看而已。--日期20220626（留言） 2024年4月30日 (二) 12:56 (UTC)[回复]
提一点，有些书籍会循环引证维基百科内容，如果无来源内容被删除，不利查证，重新编写时可能错误引用。所以我倾向尽量少的删除历史——甚至哪些条目、内容涉及伪造而被移除，也难以查证了，无人整理。维基百科不应，但理论上，作为不可靠来源它永远在“提供掺着沙子的粥”，真正经过评审与讨论的内容才比较可靠。--YFdyh000（留言） 2024年4月30日 (二) 14:04 (UTC)[回复]
不需要兼容错误的使用方法，特别是已经提醒的情况：无论是引用本页还是维护模板，都是很明显的通知。
不能达到完美，但是可以趋近。移除这些没有来源的内容可以改善整体的质量。
@日期20220626：我们在讨论是否应该提删无来源条目，和有来源的条目的质量无关。如果您认为这一问题的确急切，请您另开讨论。--落花有意12138 2024年5月1日 (三) 07:32 (UTC)[回复]
因为既然你提到泥沙和金沙的混合物，那我就觉得由于维基百科声称自己是不可靠来源，那其实有来源和没来源，并没有差多少。--日期20220626（留言） 2024年5月1日 (三) 07:44 (UTC)[回复]
这个言论不论动机（或许基于维基百科不墨守成规），已经直接挑战WP:五大支柱的维基百科是一部百科全书。也将直接影响维基百科采用中立观点的运作。--Rastinition（留言） 2024年5月1日 (三) 07:57 (UTC)[回复]
没来源的条目，读起来可以像是个百科全书的条目，也可以写的很中立，有来源也能写的不中立，所以单纯因为无来源就要将条目删除就不应该。--日期20220626（留言） 2024年5月1日 (三) 08:01 (UTC)[回复]
条目删除只是其中一个主题，但不能因为其中一个主题而尝试让网站本身只有样子像是个百科全书。
(＊)'提醒'看起来像是不代表本质是，我只进行这个回馈，其他文字不提供进一步的回馈--Rastinition（留言） 2024年5月1日 (三) 08:05 (UTC)[回复]
如果自己努力找，却找不到来源，可以走关注度流程。--日期20220626（留言） 2024年5月1日 (三) 08:02 (UTC)[回复]
@日期20220626
1.我已经多次提醒您这与本讨论无关了。这个条目加了来源，只要掌握了正确的方法，显然是对它的质量有益的，不能因噎废食。我们的讨论是关于“加来源”以前的条目，之后的与此次讨论无关。这次回复后如需再讨论，请另开讨论。
2.所谓“因为维基百科是不可靠信息，所以加来源的和不加的条目并没有差多少”是错误的观点
首先，所谓“维基百科是不可靠信息”正是可靠来源指引的内容。将该方针的内容解释为与其精神相悖的含义，显然违反了法的精神。
第次，在编写维基百科或严肃调查时，因为（所有）维基的内容是志愿者维护，因此不能作为事实的参照，而应该追回到该内容所依靠的来源中，自行核查来源。在这些情况下，对事实的需求很高，因此说维基百科是不可靠的，也就是在说维基百科并不总是真的（即“存在内容为假）”。
相对地，对于维基百科的读者，这句话并总不是真的。对于非严肃调查目的者，他们的事实需求并不那么高，而维基百科中确实存在真实的信息，因此它在一定程度上有参考价值。所以这里说它是不可靠的，是在说“不存在内容为真”，即“所有内容为假”，是片面的。
3.“没来源的条目也可以写的很中立”，这里偏离了讨论重点。无来源的条目的主要问题是违反可供查证方针，而不是同级的中立的观点方针。
4.论证“无来源内容不代表一定是质量差”应该举出无来源条目质量好的例子，而不应该举有来源条目质量差的例子。“存在a非P1，P2”和“存在a P1，非P2”并不等价。--落花有意12138 2024年5月2日 (四) 16:35 (UTC)[回复]
而且无来源内容不代表一定是质量差，有来源内容也可以写的像广告，或者就像折毛创作的条目，卡申银矿倒是都有来源，到头来还不是被发现只是恶作剧。--日期20220626（留言） 2024年5月1日 (三) 07:57 (UTC)[回复]
转草稿就导致条目看不到了，中维少了很多有价值的内容，不能这样做。--日期20220626（留言） 2024年4月27日 (六) 15:04 (UTC)[回复]
增加查看难度可能就是目的之一，逼迫阅读者推动改进。目前的维护模板过于司空见惯了，不在意条目品质的人直接忽略。{{or}}的着色也是这个目的。至少比彻底删除好。转草稿问题是移动日志不适合一般读者，条目合并麻烦，以及部分内容达标时的处理。--YFdyh000（留言） 2024年4月27日 (六) 15:10 (UTC)[回复]
现在某些用户，几乎将草稿空间当成“万能灵药”（aka：垃圾桶，或者不会被看到的地方），甚至搞不好放到草稿空间，期待别人去改善（然后自己拍拍屁股走人），等待无人改善后，又以“废弃草稿”为由，合理地拿去提删，而且由于关注的编辑有限，可能很容易通过删除。搞不好，扩大删除理由，就是方便了这种只会指手画脚然后将问题抛出后自己不想认真地改善的编辑。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月1日 (三) 12:50 (UTC)[回复]
废弃草稿会被机器人提交到速删。--日期20220626（留言） 2024年5月1日 (三) 12:52 (UTC)[回复]
我有个想法，对于长期无来源或明显不足的，使维护模板更显著一些，如更大横幅，黄色警告标志（黄底，而非当前{{无来源}}较温和的橘红色）等，以督促解决和提高警惕。甚至整个条目加底纹。至少，这比删除要温和一些。如果time参数控制让人担心，可以用单独模板或参数控制。--YFdyh000（留言） 2024年4月23日 (二) 06:42 (UTC)[回复]
好主意。--落花有意12138 2024年4月27日 (六) 14:21 (UTC)[回复]
很多基础常识条目没有来源，不代表它是虚假不可靠的或者应该删除。比如加仑。--桐生ここ★[讨论] 2024年4月24日 (三) 15:15 (UTC)[回复]
针对被回复文字，如果是文字中提到的页面类型，跨维基通常可能具有页面且对应页面中有记述来源（对应页面具有从跨维基页面扩充来源的可能），仅提供上述文字回馈。具体执行或修改不提供其他意见。--Rastinition（留言） 2024年4月27日 (六) 14:18 (UTC)[回复]
(＋)赞成在维基百科上转了一圈，发现这种基础条目几乎都没参考资料--Dnaimfz（留言） 2024年5月5日 (日) 10:51 (UTC)[回复]
建立的时候比较早。--日期20220626（留言） 2024年5月5日 (日) 10:54 (UTC)[回复]
有些东西就没法找参考资料，但是又不能不写--Dnaimfz（留言） 2024年5月5日 (日) 10:59 (UTC)[回复]
基础条目应该不存在找不到参考资料一说。--日期20220626（留言） 2024年5月5日 (日) 11:01 (UTC)[回复]
基础条目人人都明白，所以都没什么人看，没人看自然就没人编辑，进而没人找参考来源--Dnaimfz（留言） 2024年5月5日 (日) 11:04 (UTC)[回复]
另外一个不能忽视的问题就是维基百科在中国大陆被墙，因此一些只有中国大陆编者才可能有动机编写的条目无法被编写--Dnaimfz（留言） 2024年5月5日 (日) 11:06 (UTC)[回复]
一方面如此，另一方面，其他地区的编辑呢？这些基础条目部分是古早时期创建并且可能篇幅有限，之后就鲜有后续维护，不应该寄希望于有外语条目“链接”而不用去自己亲手改善。所以一直以来不将“没来源”作为提删要求。或者有些编辑非常热衷于提出一些不必要的理由去提删。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月5日 (日) 12:16 (UTC)[回复]
(＋)赞成--Dnaimfz（留言） 2024年5月5日 (日) 14:11 (UTC)[回复]
是WP:TRUE？除了懒得写“常识”，其他的要担心原创性，“没法找参考资料”如果是不存在就麻烦了。--YFdyh000（留言） 2024年5月5日 (日) 15:46 (UTC)[回复]
主要考虑到的是不少老旧条目（例如偶然找到：炉），既没有脚注参考或者列出参考，也没有挂没来源参考的条目。这类条目是否足够严重到影响中立性巴拉巴拉的高大上的支柱？有没考虑过这类还没有留意到的条目的丢失会对本项目的重大影响？（我想，某些人大概只是方针机器人，没有考虑吧？）方针很重要，但我们还有IAR，我认为不应该将没来源视为必须删除的必要条件，甚至多花些精神去整理这些条目（无论是自己找来源实现本地“原创”，还是翻译补充），都比在这里花口水去论述自己对方针的遵守的伟光正，更加实际。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月1日 (三) 12:44 (UTC)[回复]
因为在我的文字下方，简单提供对炉的回馈(呼应原本 2024年4月27日 (六) 14:18 (UTC)文字的回馈内文)
  1. en:Fire_pot
  2. ja:炉
  3. sv:Fyrfat
  4. fa:آتشدان
  • 除了回馈外的个人心得，只有zh的页面没有来源，状态比较尴尬
--Rastinition（留言） 2024年5月1日 (三) 12:57 (UTC)[回复]
所以像这类基础性条目，会选择彰显自己的伟光正，直接拉去提删（然后拍拍屁股走人，毕竟按照方针，肯定不合规而删除）？还是花时间去补充修复？还是标记上“没来源”，条目保住了，但的确存在问题，谁爱修谁去弄？而且这可能只是冰山一角？——Sakamotosan路过围观 | 避免做作，免敬 2024年5月1日 (三) 13:12 (UTC)[回复]
@Cwek (※)注意我没有对删除程序是否进行做出任何表态，你在我没有表态是否需要提删的话题上臆测我的想法并尝试产生我的观点并质问，我很讨厌这种行为。--Rastinition（留言） 2024年5月1日 (三) 13:15 (UTC)[回复]
需要留意的是，是你主动回复我这段单独提出的问题，我并没有回应你上一段的发言，也没期望你会主动回应我这一段的发言。只是对于为了维护支柱而对条目删除这个提议这么正向的言论，是不是针对不介意这个条目损失的问题，为了方针的伟大。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月1日 (三) 13:19 (UTC)[回复]
@Cwek如果我没误会你意思，你希望我提方针，我仅这一次提出我的观点(出自方针)，这个提案本身如果认真探讨，是否满足WP:DP#REASON的第6项存疑（个人观点是几乎不能满足第6项）。要我阐述我的看法，我的看法是，这个提案容易无效且价值低落。--Rastinition（留言） 2024年5月1日 (三) 13:24 (UTC)[回复]
肯定不满足，这里举了很多例子，都是很知名的事物，来源一搜一大把。--日期20220626（留言） 2024年5月1日 (三) 13:30 (UTC)[回复]
如果你认为我针对那些“拿方针当删除的令箭”，但你实际没这个观点的话，那这部分说得不是你，不做出头鸟。但如果存在有这种想法的编辑的话，我提醒一下，这可能不是你看到的那么少有问题的。花嘴皮容易还是改条目实际，自己想清楚。针对Rastinition的“这个提案容易无效且价值低落”，我的看法是：你说得对。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月1日 (三) 13:34 (UTC)[回复]
一部分找到的例子（之后会抽量陆续补充）：美国特勤局、流体动力学、压缩机。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月1日 (三) 13:15 (UTC)[回复]
@Cwek我不知道为什么你想提删这些页面，如果你希望提删这些页面，没有任何一个满足WP:DP#REASON的第6项--Rastinition（留言） 2024年5月1日 (三) 13:29 (UTC)[回复]
我没说过提删，但如果根据提案的观念，可能能引用这个理由去“符合提删的”不只是已经挂了没参考的那些。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月1日 (三) 13:34 (UTC)[回复]
(＋)支持--August0422（留言） 2024年5月9日 (四) 10:22 (UTC)[回复]

提议英维指引en: MOS:TVINTL经本地化后引入中维维基百科:格式手册/电视

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:格式手册/电视。

目前，英维en: MOS:TVINTL有限制维基百科应收集怎样的播放资讯，但中维没有相关限制，导致各电视节目（包括剧集及日本动漫）均记录了世界各地每一地区的播放资讯或重播资讯，本人认为条目内记录每一地区的播放资讯或重播资讯是非常冗长而没经筛选，更甚有条目的播放资讯比例占整个条目一半或更多，有机会违反WP:SOAP及WP:NOTTVGUIDE。对此，引入en: MOS:TVINTL也许可解决问题。
en: MOS:TVINTL： Broadcast
This subsection should cover broadcast and release information about the series or season. This can include: the original network or streaming service of release in the country of production (e.g. the British network for a British series such as Doctor Who); a change in network throughout the run, such as with Futurama; start and end dates; and discussion of technical data such as picture and audio format, accompanied by critical commentary. Days or timeslots are not inherently notable, but if covering a series that switches these during its run, it may be helpful to note them for each season. If episodes are released all at once on a streaming service, it may be more appropriate to title this section "Release" rather than "Broadcast". Any syndication deals can also be noted.

As Wikipedia is not a television guide, do not include an indiscriminate list of every network that carried a series outside the country of production. Editors are encouraged instead to add noteworthy foreign broadcasts, if reliably sourced. These can include: broadcasts in primarily English-speaking nations such as the United States, Canada, United Kingdom, Australia and New Zealand; special cases such as an American series airing its finale first in France; or a mass international distribution deal, such as Netflix acquiring the international rights for Riverdale and Designated Survivor. If reliable sources exist for English broadcasts in other countries, a talk page discussion should decide whether these are notable.

可以这样本地化：

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外播放系列的每个播放平台。 相反，如果来源可靠，鼓励编辑新增值得注意的非生产地区的广播或串流资讯。 这些可能包括：在中国、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的广播或串流资料；其余地区除了特殊情况外，包括如相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议，否则不应被记录。

下列资料不应记录：

  • 播放时间（不包括播放日期）
  • 电视重播资讯
  • 电视延后播放资讯（只记录该地区最先出现的资讯）
  • 马拉松式播放资讯（例如在一天内连续播放5集电视节目）
  • 节目原产地区外，不是以中文提供字幕或配音的播放平台
  • 相关串流平台官网、其他可靠来源均没有记录相关节目的准确播放地区且相关播放平台设置了IP限制 (特别注意：Disney+、Netflix、Amazon Prime Video、TVB Anywhere、Viu OTT)
  • 如相关节目于中文地区有“代理发行”资讯，则只可记录可在该播放平台清淅辨认相关代理资料的网络播放平台。(特别注意：日本电视动漫)

由于此条文适用于所有曾于电视广播的节目，故在此提案。部分字眼可改，只求尽快通过。--唔好阻住我爱国（留言） 2024年4月22日 (一) 07:16 (UTC)[回复]

个人感觉：“值得注意的”是重点，但不十分明确。短期内或频繁的重播可能琐碎，得到有效来源介绍的则可考虑。“除了特殊情况外”后面的语句可能仍需润色，不好懂。“播放时间”如果有来源我觉得可以，但可能很多是查证不足。“下列资料不应记录”第三条及之后的含义和用法我不太明白，或许应补充例子。建议邀请活跃编者，可预期存在反对声音，另外它是指引，强制力在短期内可能不会很高，只能作为理由依据。--YFdyh000（留言） 2024年4月22日 (一) 07:56 (UTC)[回复]
  • “值得注意的”段落可以extend，但应如何extend则交由社群决定。
  • “频繁的重播”当然是琐碎，难道要准确收录何时重播？
  • “播放时间”见下方解答
  • “第三条及之后的含义和用法”，不是电视节目条目编辑者不明白是正常的。
最后那点，请参阅在Wikipedia talk:格式手册/日本动漫游戏 § 提议将WP:MOSACG跨媒体部分提升为指引的讨论。--唔好阻住我爱国（留言） 2024年4月22日 (一) 09:26 (UTC)[回复]
那之前疫情的时候部分作品由于制作原因推迟播出，算不算电视延后播放信息？而且这一段(如相关节目于中文地区有“代理发行”信息，则只可记录可在该播放平台清淅辨认相关代理资料的网络播放平台。(特别注意：日本电视动漫))应该要加上特摄作品的信息。(有部分特摄作品也会标注其代理信息)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 07:58 (UTC)[回复]
第一点：想法是只记录该集数最先出现的播放平台，例如“A节目在B平台的播放时间是0900，在C平台的播放时间是0930，在D平台的播放时间是1200…”，这样写实在太冗长及无谓。想法是“A节目于B、C、D平台上架。”
第二点括号内的是我个人想法，当然是不会加入条文之中。--唔好阻住我爱国（留言） 2024年4月22日 (一) 09:04 (UTC)[回复]
第一个的话这个不反对(反正超级战队系列特摄作品条话一般都是按散文方式写在哪一个平台上架不大受会受影响，但是假面骑士和奥特曼系列的话有可能会受到影响删内容。)第二点的话就是说所有电视类条目都得遵守该规范吗？--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 11:22 (UTC)[回复]
总之曾在电视广播的节目条目也适用。--唔好阻住我爱国（留言） 2024年4月23日 (二) 06:04 (UTC)[回复]
依MOS:CHINA，修改为“这些可能包括：在中国大陆、台湾、”。--CaryCheng（留言） 2024年4月22日 (一) 18:21 (UTC)[回复]
下一版本会更正。--唔好阻住我爱国（留言） 2024年4月23日 (二) 06:03 (UTC)[回复]

版本2

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外播放系列的每个播放平台。 相反，如果来源可靠，鼓励编辑者新增值得注意的非生产地区的广播或串流资讯。这些可能包括：在中国大陆、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的广播或串流资料；相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议。

下列资料不应被记录：
  • 播放时间（不包括播放日期）
  • 电视重播资讯
  • 马拉松式播放资讯（例如在一天内连续播放5集电视节目）
  • 节目原产地区外，不是以中文提供字幕或配音的播放平台

下列资料必须曾被播放平台官网或第三方可靠来源记载方能保留：
  • 夸地区网络播放平台上架影片的准确上架地区 (特别注意：Disney+、Netflix、Amazon Prime Video、TVB Anywhere、Viu OTT)
  • 如相关节目于中文地区有“代理发行”资讯，则只可记录可在该播放平台清淅辨认相关代理资料及相关代理公告了的网络播放平台。(特别注意：日本电视动漫、 特摄作品等)
--唔好阻住我爱国（留言） 2024年4月25日 (四) 05:07 (UTC)[回复]
另ping @PexEric、@BlackShadowG、@Cdip150、@U:Skiate--唔好阻住我爱国（留言） 2024年4月25日 (四) 05:12 (UTC)[回复]
“下列资料不应记录”之后的内容，不是英维既有的内容，不少看起来过于一刀切，个人认为相关条文有些不合实际操作：
第一条，日本动画作品的时刻表通常使用三十小时制，不记录“播放时间”，只记录日期很容易出错
第二条的实际操作预计会删除很多内容，需要更多人参与讨论，以减少潜在的编辑冲突，以还珠格格#电视节目的变迁举例，要删掉“复播”的内容。一些记录特定电台的播放节目模板，如{{中视八点档}}《还珠格格》几轮重播都有记录，这些又如何处理。
第三条个人认为有记录必要，一来是平台发布方式的不同，如Netflix是一次性全部发布的，二来中国大陆节目播放是有政策限制的，2014年之前是“一剧四星”，之后是“一剧两星”（[3]）
可靠来源才加入内容，这应该是一般的内容要求。“下列资料必须曾被播放平台官网或第三方可靠来源记载方能保留”的描述十分累赘，完全可以合并成一句话概括：“节目的播放平台及网络电视的节目可观看地区都需要列明来源”。
PS：错字“夸地区”。--Nostalgiacn（留言） 2024年4月25日 (四) 08:49 (UTC)[回复]
1. 编辑者有责任将日本30小时制转换至中文地区的24小时制，这样可提高条目可读性。（注：近期日本动画条目已停止记录30小时制播放时间表，仅列出24小时制首播及完结日期。）
2. 不记录重播资讯，只记录首播资讯是英维要求。节目模板可以保留。
3. 可以删除，反正第二条有相同功用。
4. 下一版本会更正，并放在首段。
整个句子可能是“节目的播放平台及网络电视的节目可观看地区都需要列明来源，否则其他编辑者有权移除未能辨认可观看地区的播放平台及网络电视播放资讯。 因应地区IP而调整播放内容的网络播放平台连结、需要登入方能阅读播放清单的网络播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。”--唔好阻住我爱国（留言） 2024年4月25日 (四) 10:24 (UTC)[回复]
(＋)支持。--CaryCheng（留言） 2024年4月25日 (四) 16:00 (UTC)[回复]
对于日本动画的话，电视播放途径会有一手来源（官方本身有类似onAir的来源），可以考虑保留时间。网站播放途径不确定其发布时间是不是确定的，可以不保留。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月26日 (五) 01:10 (UTC)[回复]
整顿完TV后就该整顿TV anime，电视联播网也不知道是什么…英维已有部分条目采用电视联播网归纳全日本电视台，与中维日剧条目差不多处理方法。
况且播放时间能证明什么？
时段可以，但准确时间万万不可。试想想，如果上一节目时段因为紧急直播10分钟而导致此节目延迟10分钟结束节目，编辑者通常在条目解释为何延迟播放此节目，唯解释普遍没有来源且与节目条目无关，备注长度砧比节目介绍，香港电视条目正深受其害。--唔好阻住我爱国（留言） 2024年4月26日 (五) 03:25 (UTC)[回复]
往常处理也是不考虑临时的延时、改期情况，如果需要的话，是有来源引述时在动画节目章节内导言中提及。时间的话，需要多精确？onair来源中来精确到“23:00”的话，就按照这个时间描述则可。电视联播网现在ja都不提及的，电视播放渠道只需要按照来源说明哪个电视台播放基本足够。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月26日 (五) 06:02 (UTC)[回复]
  • 这里该处理整体电视条目，而非单指日本电视动画…
  • “临时的延时、改期情况”在日本条目实属少见，唯香港条目是普遍。
  • “23:00”时段即可，免得又说因为xxx事而延误xx分钟播放。
--唔好阻住我爱国（留言） 2024年4月26日 (五) 06:13 (UTC)[回复]

版本3

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外播放系列的每一个广播或串流资讯。 相反，如果来源可靠，鼓励编辑者新增值得注意的非生产地区的广播或串流资讯。这些可能包括：在中国大陆、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的广播或串流资讯；相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议。节目的播放平台及网络电视的节目可观看地区都需要列明来源及符合可供查证原则，否则其他编辑者有权移除未能辨认可观看地区的播放平台及网络电视播放资讯。 因应地区IP而调整播放内容的网络播放平台连结、需要登入方能阅读播放清单的网络播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。

下列资料不应被记录：
  • 准确播放时间（不包括播放日期及播放时段）
  • 电视节目即日延误播放资讯（包括为何延误播放及延误时间）
  • 电视节目重播资讯
  • 节目原产地区外，不是以中文提供字幕或配音的播放平台

--唔好阻住我爱国（留言） 2024年4月26日 (五) 06:21 (UTC)[回复]

那包含在特定节目内的应不应该记录准确播放时间？(例如目前在翡翠台播出的小书痴以及东电在某些时段冠其他名称的动画)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月26日 (五) 07:13 (UTC)[回复]
准确播间是类似香港TVB晚上八点档爱回家，电视节目时间表写20:00播放至20:30结束，但实际播放时间是20:03-20:27。
故写播放时间时只需提及“此节目逢星期一至六晚上八时正首播。”--唔好阻住我爱国（留言） 2024年4月26日 (五) 07:43 (UTC)[回复]
与原有时段严重不符的特殊偶发延误资讯应可记录，例如延误半小时以上。亦即经常延误的节目不宜记录，例如习近平时代的央视新闻联播其后的电视剧等节目；据称胡锦涛时代的央视新闻联播延误极少，由此导致的节目延误应容许记录。--— Gohan 2024年4月27日 (六) 02:09 (UTC)[回复]
如何符合列明来源及符合可供查证原则？
请提供相关记录的例子，谢谢！--唔好阻住我爱国（留言） 2024年4月27日 (六) 06:06 (UTC)[回复]
与本问题无关（即不应因部分内容无来源而全面禁止以至牵连有来源的内容）。但有例子：フジテレビは地震発生时……映画‘ヲタクに恋は难しい’を放送……报道特番に切り替わり、深夜1时25分ごろに続きの放送が再开された。その后、2时间15分押しで深夜1时35分から‘さんまのお笑い向上委员会’……--— Gohan 2024年4月27日 (六) 09:33 (UTC)[回复]
只限于临时的节目时间改动，有来源（例如报道）的情况就可以作为描述文段提及。至于其原有的周期性播放时间点，也按照已有来源参照描述则可。例如[4]这种，每个播放电视台的周期播放时间是可以引述来源上描述的，如果当时的播放时间有偏差（例如上面提及的《爱回家》的时间）或者突然的变动，有来源提及就描述，没就不管。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月28日 (日) 02:06 (UTC)[回复]
建议第2点改为：
  • 推迟不足30分钟或并非偶发的延误播放之资讯
再者，一个节目若在渗透率二成的卫星电视或收费有线电视频道首播，而后在渗透率九成的地面电视频道重播，后者应容许记载。故建议第3点改为：
  • 重播资讯，除非传播媒介不同而使该重播频道渗透率倍增于此前任一已播出频道
此外，“相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯”文法不通，难以理解，应予修改；“在生产地区以外播放系列的每一个广播或串流资讯”中，“系列”显然是机械翻译，亦应修改。
另外，建议条文可能致使编者以为跨国播出只能在“播出国家／地区”栏目列出原产国或中维六地（例如以为GEM TV ASIA的此列法违规）而令所示播出范围小于实际，需要澄清；“广播”一词有歧义，在部分地方仅意味大气电波播出，亦需更改。--— Gohan 2024年4月28日 (日) 07:48 (UTC)[回复]
  • 第一点(＋)支持，下一版本会更正。
  • 第二点有点麻烦，毕竟以“渗透率”作标准有争议。
  • 第三点是英维要求，应如何改善？
  • 第四点(＋)支持，下一版本会更正。
  • GEM TV ASIA是采用内嵌字幕，除了香港是嵌入中文外，其余东南亚地区是嵌入英文，故列出东南亚地区其实是不符合最后一点原则。
  • 英维是采用“广播”，中维可用“播放”，下一版本统一至“播放”。
--唔好阻住我爱国（留言） 2024年4月28日 (日) 08:43 (UTC)[回复]
更正一点:GEM TV ASIA实际使用的是DVBSUB形式的隐藏式字幕并非是内嵌字幕。(部分运营商会将外挂式字幕转为内嵌式字幕)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月28日 (日) 08:47 (UTC)[回复]
“等主要中文地区”--唔好阻住我爱国（留言） 2024年4月28日 (日) 08:58 (UTC)[回复]
同一频道同一时间播出何必作出区隔？省去几个字国名？如此致使读者以为GEM TV ASIA在此时段香港才播出此节目，在其他地方不然。因此主张在任一地方满足条件即可；同样，在任一地方属于首播即可，而不应刻意遗漏同一频道同一时间播出同一节目而非首播的地方。--— Gohan 2024年4月28日 (日) 08:58 (UTC)[回复]
这是英维“English licensee”所主张的。在英维，同一频道列A地区不列B地区是常见。--唔好阻住我爱国（留言） 2024年4月28日 (日) 09:33 (UTC)[回复]
查无相似主张。英维的Release章节并不规定：若一个电视频道同时向英语、非英语国家播出同一节目，只能列出英语国家；或一个电视频道同时向多地播出同一节目，只能列出提供英文字幕的国家或地区。一个电视频道同时向多地播出同一节目应视为单一行为，不宜片面陈述，正如可标识跨国流媒体“全球”播出。--— Gohan 2024年4月29日 (一) 06:34 (UTC)[回复]
当然是查无主张啦，因为这仅是实际操作。
个人是反对“全球”一词，世界上没有任何一个媒体可以全球通行，以 “全球”作结表示该名编辑者没有进行资料搜集、原创研究、发放错误讯息。--唔好阻住我爱国（留言） 2024年4月29日 (一) 12:59 (UTC)[回复]
若在该串流媒体的任何任务区可看，“全球”无可厚非；或许只需一个自订或变态的“ 全世界”模板作解释或tooltip。--— Gohan 2024年4月30日 (二) 08:22 (UTC)[回复]
服务地区（Service Area）--唔好阻住我爱国（留言） 2024年5月1日 (三) 02:50 (UTC)[回复]
按照您的说法那b站本身也不能作为可靠来源。(B站本身限制海外地区浏览中国大陆的影视内容只能通过B站以及代理商社交媒体查询。)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年5月1日 (三) 08:42 (UTC)[回复]
外维是直接禁止引用播放清单（不论英维还是其他维），但我的条文中却只要求该播放清单全球任何一地均可阅覧及能清楚辨认属地即可。
bilibili应该是不受影响，而YouTube, Netflix, Disney+, Viu OTT,爱奇艺等全球性平台才是影响较大。--唔好阻住我爱国（留言） 2024年5月1日 (三) 08:56 (UTC)[回复]
虽然因为确实没有主张，但是确实是有这么做的(在WP:共识中有提到在维基百科，共识是一种典型但往往含蓄无形的过程。所有没有异议或不被其他编者回退的编辑，均可假定其具备共识。)类似于J2更名为TVB Plus英语社群这边鉴于该频道只是更名并增加财经节目并不符合独立关注度所以没有跟现在中维一样建立新条目而是将条目进行移动。(要是真按照英语的共识那高清翡翠台、J5应该要合并到无线财经 体育 资讯台并删除大量琐碎细节内容。以及按照命名常规将无线财经 体育 资讯台更名为更常用的无线财经体育资讯台)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月30日 (二) 06:49 (UTC)[回复]
虽然二位都未明指“主张”是什么，但是在下意会有关主张后随机搜寻思绪中首先浮现的电视节目，竟就足以驳倒“确实是有这么做的”：英维“如懿传”条目国际播出章节列出：Star Chinese Channel在Hong Kong and Southeast Asia播出、三个越南电视台播出三次越南语配音的版本，无论如何设想都不符合“若一个电视频道同时向英语、非英语国家播出同一节目，只能列出英语国家；或一个电视频道同时向多地播出同一节目，只能列出提供英文字幕的国家或地区”或“不应记录”“节目原产地区外，不是以中（英）文提供字幕或配音的播放平台”。此外，毫不认同有关英维J2的评论，离题不赘。--— Gohan 2024年4月30日 (二) 08:21 (UTC)[回复]
然而相关方针指的是原生英文的节目。例如瑞克与莫蒂、汪汪队立大功这两个条目都是以散文的形式标注具体提供的配音版本以及配音版本的播出频道。(实际就是要求跟英文一样尽量使用散文和信息框的形式，而不是纯信息框。)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月30日 (二) 11:35 (UTC)[回复]
日后希望您在提出有关方针或指引的说法，请明示依据或直接引述。至少en:Wikipedia:Manual of Style/Television查无有关“原生英文的节目”的条文，否则请指明；版本3至今所有人的提案中亦无“原生中文的节目”一说，您提出“原生英文”所为何故？不免怀疑您在2024年4月28日 (日) 08:58 (UTC)下属的一串讨论中的近两次留言已离题，也难以猜测“确实是有这么做的”（2024年4月30日 (二) 06:49 (UTC)）到底是指怎么做？--— Gohan 2024年5月1日 (三) 03:54 (UTC)[回复]
看了一下，确实没有直接写明禁止非英语但是提到英语系国家优先。(对应段落en:MOS:TVINTLAs Wikipedia is not a television guide, do not include an indiscriminate list of every network that carried a series outside the country of production. Editors are encouraged instead to add noteworthy foreign broadcasts, if reliably sourced.These can include: broadcasts in primarily English-speaking nations such as the United States, Canada, United Kingdom, Australia and New Zealand)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年5月1日 (三) 06:43 (UTC)[回复]
要是真在某特定区域播出，直接写对应的地区就行(例如无职转生在东南亚地区曾在ANIMAX播出就直接写东盟就行了。)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月28日 (日) 10:37 (UTC)[回复]
你要说“东盟”或“东南亚”的话，请证明此动画可在泰国以Animax观看。--唔好阻住我爱国（留言） 2024年4月28日 (日) 14:41 (UTC)[回复]
该频道本身在泰国已经于2017年停播，但是部分节目仍可在TrueID以点播的形式提供。类似于ANIPLUS在香港的情况。(而且在无职转生的英语条目中对于该台播出的地区描述用的是模糊的东南亚地区而并未精准到国家)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月29日 (一) 00:05 (UTC)[回复]
如无渗透率作标准，而全面禁止重播资讯，则会导致一个电视节目若在几乎没人会看（例如渗透率低于百分之一、收视率低于万分之一）的频道首播，在最多人收看（渗透率九成八）的频道第二次播出，而后者不得记述，违背情理。--— Gohan 2024年4月29日 (一) 06:36 (UTC)[回复]
真要按渗透率台湾的无线五台(台视、中视、华视、民视以及公视)与第四台(有线电视)的基本频道渗透率相当(台湾的无线五台在第四台是必传频道)那怎么算呢？(香港这种被TVB和政府垄断而不能自由收视的地方真是令人悲哀。)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月29日 (一) 07:08 (UTC)[回复]
渗透率相当，显然不符合我所提议的条文中的豁免条件：“除非传播媒介不同而使该重播频道渗透率倍增于此前任一已播出频道”。--— Gohan 2024年4月29日 (一) 11:51 (UTC)[回复]
若要用渗透率作标准，则大大提高编辑难道或引起编辑争议。
“我认为A媒体渗透高些，B很少人看。”
“我认为B媒体渗透高些，A没有人看。”--唔好阻住我爱国（留言） 2024年4月29日 (一) 13:02 (UTC)[回复]
相较收视率或其他数字，渗透率稳定、透明、标准一致，最为可取。若无更佳标准、不取渗透率，可以改为禁止“同一收视方式或受众更狭窄的收视方式的频道重播之资讯”；若仍有争议，恐怕只能改成禁止“同一频道重播资讯”；以免“一个电视节目若在几乎没人会看（例如渗透率低于百分之一、收视率低于万分之一）的频道首播，在最多人收看（渗透率九成八）的频道第二次播出，而后者不得记述”。此外，或许需要括注“（惟特有中文名称可标注相应电视台或频道）”。--— Gohan 2024年4月30日 (二) 08:26 (UTC)[回复]
这个世界有基于广告的“电视覆盖率(TV Overlay Rate)”。--唔好阻住我爱国（留言） 2024年5月1日 (三) 02:36 (UTC)[回复]
依据目前资料理解，在任何框定区域内，A频道与B频道的渗透率的比率、A频道与B频道的覆盖率的比率，是一致的（因为A频道与B频道的渗透率的分母一致，A频道与B频道的覆盖率的分母亦一致；A频道的渗透率、覆盖率的分子一致、B频道的渗透率、覆盖率的分子亦一致）。所以渗透率、覆盖率孰优孰劣，在我的提议条文（“渗透率倍增”）中没有差异。--— Gohan 2024年5月1日 (三) 03:53 (UTC)[回复]
他愿不愿意愿意到相关地区收看是他个人决定，总之这个台在该版权地区是有提供服务。
以日本为例，TVer的覆盖范围与ABEMA一致，可观看人数达124,090,000人。
TVU福岛覆盖全福岛县，可观看人数达 1,817,228人
TBS电视台覆盖整个关东广域圈，可观看人数达43,191,414人--唔好阻住我爱国（留言） 2024年5月1日 (三) 02:49 (UTC)[回复]
“渗透／覆盖不到”即循此种方式无法观看，外乎意愿。--— Gohan 2024年5月1日 (三) 03:53 (UTC)[回复]
我想探讨一下“范围”，以上面的全球和东盟为例，难道要为了几个没有营业国家/地区而特地列出实际有播出的国家/地区吗？这对串流节目、大型赛事可是一大麻烦（例如欧洲歌唱大赛特地把俄罗斯以外的欧洲国家写出来）。 --窝法乙烷 儿法梦碎 2024年5月1日 (三) 03:46 (UTC)[回复]
至少英语社群相关方面都是直接写模糊的地区而不是写对应国家。--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年5月1日 (三) 03:51 (UTC)[回复]

版本4

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外的播放资讯。 相反，如果来源可靠，鼓励编辑者新增值得注意的非生产地区的播放资讯。这些可能包括：在中国大陆、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的播放资讯；相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议。节目的播放平台可观看地区都需要列明来源及符合可供查证原则，否则其他编辑者有权因可能违反著作权法为由移除未能辨认可观看地区的整组播放资讯。因应地区IP而调整播放内容的网络播放平台连结、需要登入方能阅读播放清单的网络播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。

下列资料不应被记录：
  • 准确播放时间。（不包括播放日期及播放时段）
  • 推迟不足30分钟或并非偶发的延误播放之资讯。
  • 电视节目重播资讯（在该节目授权区域内的相关播放平台覆盖比率/可观看人数较首播平台的覆盖比率/可观看人数高一倍或更多除外。）
  • 节目原产地区外，不是以中文提供字幕或配音的播放平台。

--唔好阻住我爱国（留言） 2024年5月1日 (三) 05:08 (UTC)[回复]

你的文本内容越来越累赘，有些内容不妨说得再直白一点，修改一下部分描述：“维基百科不是电视指南，请勿不分青红皂白地列出原产地之外的播放资讯。编辑者在有来源可靠的情况下，在条目中记录值得注意的非原产地的播放资讯，如中国大陆、台湾、香港、澳门、马来西亚、新加坡等中文使用地区的首播资讯，还有原生中文节目在还非中文使用地区的首播资讯，或者大规模的国际播放资讯。节目的播放平台及网络电视的节目可观看地区都需要列明来源，网络电视节目连结不合适作为来源，因地区限制访问，部分编者无法查核，来源是否可靠请通过讨论协商。”

英维原文可没有“否则其他编辑者有权因可能违反著作权法为由移除未能辨认可观看地区的整组播放资讯。因应地区IP而调整播放内容的网络播放平台连结、需要登入方能阅读播放清单的网络播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。”这段，而是建议讨论来源是否可靠，因为条目使用可靠来源本身就是“内容指引”，需要的是讨论来源是否可靠（WP:RSP）。--Nostalgiacn（留言） 2024年5月1日 (三) 15:55 (UTC)[回复]

第一段不反对，第二段仅重申Category:电视外部资源模板相关连结只是外部链接，并非来源。更什有编辑者直接扔了Netflix连结出来，当开启连结时发现是Error。
因应地区IP而调整播放内容的网络播放平台连结、需要登入方能阅读播放清单的网络播放平台连结—> 重新解䆁WP:可供查证及WP:外部链接方针。--唔好阻住我爱国（留言） 2024年5月1日 (三) 18:13 (UTC)[回复]
而如直接使用WP:RSP，bilibili及Youtube已经不给使用了。--唔好阻住我爱国（留言） 2024年5月1日 (三) 18:15 (UTC)[回复]
WP:RSP描述是，官方内容作为一手资料可靠，也符合可供查证的自身说明（WP:ABOUTSELF）。bilibili及Youtube也适用，不过结合“网络电视节目连结不合适作为来源”的描述。更建议使用官方在官网、社交平台、或bilibili及Youtube上预告节目播放的日期动态/公告。--Nostalgiacn（留言） 2024年5月4日 (六) 01:22 (UTC)[回复]


现行条文

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外的播放资讯。 相反，如果来源可靠，鼓励编辑者新增值得注意的非生产地区的播放资讯。这些可能包括：在中国大陆、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的播放资讯；相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议。节目的播放平台可观看地区都需要列明来源及符合可供查证原则，否则其他编辑者有权因可能违反著作权法为由移除未能辨认可观看地区的整组播放资讯。因应地区IP而调整播放内容的网络播放平台连结、需要登入方能阅读播放清单的网络播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。

提议条文

维基百科不是电视指南，请勿不分青红皂白地列出原产地之外的播放资讯。编辑者在有来源可靠的情况下，在条目中记录值得注意的非原产地的播放资讯，如中国大陆、台湾、香港、澳门、马来西亚、新加坡等中文使用地区的首播资讯；原生中文节目在非中文使用地区的首播资讯；或大规模的国际播放资讯。节目的播放平台及网络电视的节目可观看地区都需要列明来源，网络电视节目连结不合适作为来源，因地区限制访问，部分编者无法查核。关于个别播放平台节目连结是否可被直接引用，请在本指引讨论页讨论协商或评选，唯讨论重点应放在著作权法及可供查证原则。

曾经有编辑者把盗版连结放入播放平台区域，故希望借此指引提醒编辑者著作权法的重要性。--唔好阻住我爱国（留言） 2024年5月1日 (三) 18:34 (UTC)[回复]

上方讨论太长未看全，就该版本的疑问（如已有结论，希望加脚注）：原产地之内的播放信息似乎被暗示可“不分青红皂白地列出”。原产地的准确定义，范围，联合制作、外包、仅外销等。很多字句应修饰，如“在有来源可靠的情况下”等，由于非定稿我暂时不全部列出。“网络电视节目链接不合适作为来源”听上去有点奇怪，有点像某个来源非公开可用（需登录/部分地区/线下来源）就不适合作来源，可能意思需改善，比如不能访问现象本身、无法存档的网页内容，不适合作来源。--YFdyh000（留言） 2024年5月1日 (三) 19:36 (UTC)[回复]
@YFdyh000:
欢迎任何具建设性的修饰句子。--唔好阻住我爱国（留言） 2024年5月2日 (四) 11:07 (UTC)[回复]
改为“原产地的首播资讯”就行，上面《还珠格格》就是限制播放资讯在“首播”。
YFdyh000提到的情况，我想起了近期一个例子《食草老龙被冠以恶龙之名》，日本轻小说，由中国大陆澜映画制作的动画版在bilibili上首播（2022年7月），2023年1月才在日本电视台播出（[5]）（[6]）。这种涉及跨国版权的节目，“原产地”算中国大陆，还是日本。
早年中港、港台合拍剧也不少，不过都属于“中文使用地区的”，所以反而没有这些记录争议。--Nostalgiacn（留言） 2024年5月4日 (六) 01:35 (UTC)[回复]

版本5

希望这是最终版

标题：播放资讯

维基百科不是电视指南，请勿不分青红皂白地列出电视节目的所有播放资讯。编辑者在附上可靠来源的情况下，可在条目中记录值得注意的播放资讯，如节目原产地的首播资讯；中国大陆、台湾、香港、澳门、马来西亚、新加坡等中文使用地区的首播资讯；原生中文节目在非中文使用地区的首播资讯；或大规模的国际播放资讯。节目的OTT播放平台及网络电视的节目可观看地区均需列明来源，网络电视节目播放连结不合适作为来源，因地区限制访问，部分编者无法查核。关于能否引用特定OTT播放平台的连结，可在本指引的讨论页商议，重点为著作权法和可供查证原则。

下列资料即使附上来源也不应被记录：

  • 准确播放时间。（不包括播放日期及播放时段）
  • 推迟不足30分钟或并非偶发的延误播放之资讯。
  • 电视节目重播资讯。（在该节目授权区域内的相关播放平台可观看人数较首播平台的可观看人数高一倍或更多除外。）
  • 不是以中文提供字幕或配音的播放平台。（节目原产地区播放平台或以中文制作的节目除外。）

--唔好阻住我爱国（留言） 2024年5月8日 (三) 08:26 (UTC)[回复]

“网络电视节目播放链接不合适作为来源，因地区限制访问，部分编者无法查核。”语序希望优化；地区性或可能失效的视频的网络播放源，有时是有用的，作为某些信息的一手来源，{{Cite AV media}}，但提供者唯一且无法存档的确实不宜用。“网络电视节目播放链接”被运用时如何区分，我担心存在理解差异。
“个别”是“特定（某个）”吗。“直接引用”，所以有间接引用吗。建议可在、协商或评选、唯应，感觉语意重复。“关于能否引用特定播放平台的链接，可在本指引的讨论页商议，重点为著作权和可供查证原则”。
“准确播放时间”指的是实际播出时点、时长吗，是否与下一条有重复。
“非偶发的延误播放之信息”指什么，已宣布的推迟播放不宜记录？--YFdyh000（留言） 2024年5月8日 (三) 08:51 (UTC)[回复]
  • 对不起，不能使用“视频”字眼，因实际应用场合不同，放在繁体字地区，意思截然不同。
  • 网络电视是IPTV,网络播放平台是OTT。
  • “关于能否引用特定播放平台的连结，可在本指引的讨论页商议，重点为著作权和可供查证原则”，这个可以。
  • 没有重复。
  • 意指不应收录恒常延误播放资讯。如果每一集也记录为什么延迟播放，那么与电视指南有什么分别？
--唔好阻住我爱国（留言） 2024年5月8日 (三) 10:31 (UTC)[回复]
@YFdyh000、@Nostalgiacn、@Milkypine、@Cwek、@CaryCheng、@甜甜圈真好吃、@神秘悟饭:
如没有特别大的问题，3日后将按照版本5进行公示。--唔好阻住我爱国（留言） 2024年5月10日 (五) 09:55 (UTC)[回复]
我发现有些概念有待厘清，网络电视目前英维对应是Streaming television，IPTV也可以翻译做“网络电视”。搞清楚条目内容和概念，可以更准确描述内容。Streaming television在描述上包括IPTV和OTT等情况。--Nostalgiacn（留言） 2024年5月10日 (五) 10:54 (UTC)[回复]
沿用中文解释及例子，因为这里是中文维基百科。中文社群均认为OTT是类似Netflix, Disney+，甚至有播放平台以OTT自居，如myTV SUPER。更什台湾有OTT协会，大部分台湾网络播放平台也加入了。--唔好阻住我爱国（留言） 2024年5月11日 (六) 00:33 (UTC)[回复]
换句话说，除非有人重新整理该两个条目至英维内容，否则再改也没有意思。但是在中文社群而言，英维对OTT的理解是错误的。--唔好阻住我爱国（留言） 2024年5月11日 (六) 00:47 (UTC)[回复]
(＋)支持。--CaryCheng（留言） 2024年5月10日 (五) 15:36 (UTC)[回复]
——
3日内无反对声音，现就版本5进行公示，公示7日至5月20日星期一止。--唔好阻住我爱国（留言） 2024年5月13日 (一) 03:25 (UTC)[回复]
(＋)支持版本5。 --窝法乙烷 儿法梦碎 2024年5月16日 (四) 14:33 (UTC)[回复]
无奈只能(－)反对，仅仅“因地区限制访问，部分编者无法查核”就不能作为来源的话，未免过严。举例说：西游记 (无线1996年电视剧)，那个年代TVB还没有网站，这样的规定岂不是不能引用首播前的广告（广告里有说明首播日期）作为来源？（那个广告只在香港播出，理论上只有香港地区才能看到）［当然有人在FB上传了那个广告而可能非法地突破了地区限制，故也因此将来可能随时会被移除］--街燈電箱150號 开箱维修 抄表 检验证明 2024年5月17日 (五) 18:24 (UTC)[回复]
  • 我有合理怀疑阁下并没有仔细阅读清楚条文，仅意气用事。
  • 请望淸楚“因地区限制访问，部分编者无法查核”是针对那些媒介。
    • 针对那些媒介提及的例子，请问阁下可否拿出连结？
  • 既然阁下不打算改可供查证，不看得出对阁下提及的例子有任何影响，因条文建议编辑者依靠可供查证为个别媒体进行协商。
  • **条文并无要求传统电视内容提供来源**
  • FB已被可靠来源方针定为不可靠（不是我改的）
--唔好阻住我爱国（留言） 2024年5月18日 (六) 04:01 (UTC)[回复]
@Cdip150--唔好阻住我爱国（留言） 2024年5月18日 (六) 04:07 (UTC)[回复]

提议：允许使用开放代理编辑WP:RFR，并在WP:RFR中加入“注册账号申请”

本主题全部或部分段落文字，已移动至Wikipedia talk:权限申请。执行人：Sanmosa 全方贫工之联合 2024年5月14日 (二) 11:01 (UTC)。[回复]

提议：对WP:日常计算做小修改

本主题全部或部分段落文字，已移动至WT:非原创研究。执行人：Sanmosa 全方贫工之联合 2024年5月14日 (二) 15:49 (UTC)。[回复]

提议对中国大陆的文物保护单位设立关注度豁免

本主题全部或部分段落文字，已移动至WT:关注度 (文化遗产)。执行人：Sanmosa 全方贫工之联合 2024年5月14日 (二) 15:01 (UTC)。[回复]

附带有限追踪检查的无IP的IPBE

由于现在IPBE申请积压严重，而且新增的授予员并没有加快解决积压，因此提出新的IPBE授予员类型，希望各位提出意见。

主要内容：这种IPBEG收到的申请不包含IP信息，因而不需要签订协议。为了反破坏，授权者应该检查新账户的编辑，直到用户做出足够多多笔有贡献性的编辑，期间如有破坏则提报。

这降低了要求，并且只需要检查用户名是否合规，应该能加快处理速度。

可能的问题和回答：

  • 破坏者可以积攒账户以供未来破坏：由于这种账户要有多笔好编辑，而破坏易于识别，所以利大于弊。并且现在的方法也没有解决这些问题
  • 可能“抢注”用户名，占用用户名存量：如果新账户数量和名称异常可以明显察觉
  • 要追踪的用户太多：可以通过RSS订阅集中检查

感谢桐生ここ和其他用户提供的灵感。--落花有意12138 2024年5月11日 (六) 12:37 (UTC)[回复]

你要先跟IPBE授予标准过低的人说，不是我们不想处理，还有授权者应该检查新账号的编辑这不切实际，申请人太多检查不过来，且这相当于给人背书，不会有人想做这种吃力不讨好的事，有的话我觉得很棒，一旦有人破坏却没有被检查到，授权者就准备被一些人骂了，说为什么没有检查到。
至于会有人问说为什么有人会骂，这是因为中维社群很难满足。
我提出建议有人反对，也没人打算解决，放着烂比较快。加油 (--~~Sid~~ 2024年5月11日 (六) 13:05 (UTC)[回复]
我问一个问题，您作为IPBEG，遇到IPBE申请者提供的IP是Range block，而不是Blocked Proxy，申请者用户名看起来正常，您是授权还是不授权？怎么判断出是误伤还是破坏者本人？
为什么当前的IPBEG授权后一旦有人破坏却没有被检查到，授权者为什么不会被一些人骂，说为什么没有检查到？--桐生ここ★[讨论] 2024年5月11日 (六) 15:18 (UTC)[回复]
Range block不在IPBEG的处理范围，只有Blocked Proxy我们才能处理。
1-1.通常使用者名称看起来正常，也没发现什么异常就会授权。
1-2.我们只能从申请者申请的用户名及IP看异常，用户名除了特征明显以外是无法看出什么，IP就没什么可判断异常的地方。
2.因为现有方针没有要求我们要检查新账号编辑，所以不会有这种问题。--~~Sid~~ 2024年5月11日 (六) 16:32 (UTC)[回复]
换个说法吧，一个代理IP上有已知破坏者，现在有人用这个IP申请IPBE，授权就有可能会给破坏者授权，但是没办法，即便有IP你也无法知道是不是破坏者。
所以能看到IP并没有增加对是否为破坏者的判断。--桐生ここ★[讨论] 2024年5月11日 (六) 17:04 (UTC)[回复]
我提过这个好几次。由于人工检查的滞后性和精力消耗，有必要搭配机器人等机制限制行为，不然破坏者等授予者下线再用不就绕过了。--YFdyh000（留言） 2024年5月11日 (六) 13:10 (UTC)[回复]
这给我一个新的思路，就是“考察版IPBE权限组”，利用AF限制“考察版IPBE”建立条目的权利，他们只能先发草稿然后送AFC，至于编辑条目，即使达到自动确认用户也不能编辑半保护内容，除非达到延伸确认或获得正式版IPBE权限。另外所有“考察版IPBE”编辑会被AF加标签以便追踪。--桐生ここ★[讨论] 2024年5月11日 (六) 15:23 (UTC)[回复]
说句实在话与其用这种治标不治本的方式，为什么不恢复CU让CU来查，不要说什么有人泄漏CU数据，所以不该恢复，那反之过往有管理员滥用傀儡，要不要把管理员全部废掉阿...
这样子的检查不仅消耗社群已经所剩无几的人力，还很没有效率。
我不是在指这个提案不好也不是要反对，只是无法理解为什么有治本的方法不用，要用一个治标还耗时耗力的方法。--~~Sid~~ 2024年5月11日 (六) 13:17 (UTC)[回复]
当前IPBEG的机制不能让人满意，因为实质上没有解决问题，反而让一些本该有权处理的管理员无法处理。
由于Unblock-zh.org的建立，该网站设计的申请流程似乎有不提供IP地址的选项，因此同意成立这种特殊IPBEG用户组。--桐生ここ★[讨论] 2024年5月11日 (六) 15:11 (UTC)[回复]
unblock-zh 网站设计应该符合使用需求，也就是说如果IPBE的申请要求查验IP，那么网站可以醒目的提示“要申请IPBE必须提交IP”。（这个意见已经出现在了讨论区）Bluedeck 2024年5月17日 (五) 09:01 (UTC)[回复]
“新增的授予员并没有加快解决积压”，所以料想可以解决问题的制度实际上（还）没有解决问题？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月11日 (六) 18:41 (UTC)[回复]
目前，申请申请iPBE授权后发现是破坏者的个案多吗？-千村狐兔（留言） 2024年5月12日 (日) 11:52 (UTC)[回复]
给人背书可能不太合理。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月12日 (日) 14:18 (UTC)[回复]

关于国籍的原创研究

近日发现WP:CS4D内对于国籍的标记有所规范，然而发现当中有不合法律，原创研究的地方。中国很长时期对于国籍的法律编定都不上心，据站内中国国籍条目：

  • 1909年，清政府颁布《大清国籍条例》
  • 1912年，北洋政府制定了《国籍法》
  • 1980年，中华人民共和国颁布了《中华人民共和国国籍法》
  • MOS:NATIONALITY称1912年（不含）前（未内渡的台湾（含澎湖）人则为住民去就决定日前）的大清臣民，其为大清臣民期间的国籍应表述为“清朝”。然而，“住民去就决定日”，即1895年时，清朝根本没有国籍法，怎何能标示其所谓“国籍”？
  • 1949年后，1980年前，中国缺乏正式的国籍法规（请参考 Shao, Dan. Chinese by Definition: Nationality Law, Jus Sanguinis, and State Succession, 1909–1980. Twentieth-Century China. 2009, 35 (1): 4–28. S2CID 201771890. doi:10.1353/tcc.0.0019. ，第五页）。MOS:NATIONALITY称1949年以后的中华人民共和国公民，如其在中国大陆设有户籍，其为中华人民共和国公民期间的国籍应表述为“中华人民共和国”，没有国籍法规之下，将国籍硬说成“中华人民共和国”是否合适？设有户籍则推定他有国籍这种做法又不知道是否合适？
  • 此外，如金毓黻。中华民国根本不承认满洲国，资讯框写1932年退出中华民国国籍，1936年重新加入中华民国国籍的说法，到底有没有资料支持？

--Ghren🐦🕘 2024年5月12日 (日) 13:04 (UTC)[回复]

没有国籍法=没有国籍 吗，值得探究“国籍”的含义、该填什么。按资料，用宪法规定国籍最早见于法国1791年宪法，用单行法规定国籍最早见于1842年普鲁士（德国）国籍法。瑞士国籍法始于1952年，丹尼尔·伯努利的国籍（Nationality）瑞士为错误信息？“1901年取得瑞士国籍”于 物理学小词典[M]. 1987。“1923年，黑塞加入瑞士籍。”，英文条目“In 1923, Hesse was granted Swiss citizenship.”，而有些文章会写成瑞士国籍。--YFdyh000（留言） 2024年5月12日 (日) 13:54 (UTC)[回复]
同问，无国籍法即无国籍之说显然不合常理。Sanmosa 全方贫工之联合 2024年5月12日 (日) 14:11 (UTC)[回复]
(＋)支持U:YFdyh000的论点。国籍是现代概念，而在介绍国籍法出现前的古代人物时，依WP:常识即可认定其国籍。--CaryCheng（留言） 2024年5月12日 (日) 16:14 (UTC)[回复]
英文nationality有两层含义，一层是the official right to belong to a particular country、一层是a group of people of the same race, religion, traditions, etc.。当我们说伯努利是瑞士数学家、古腾堡是德国印刷学者，用的是nationality后者的含义。在中文中“国籍”是这样定义的：“一个人属于某一个国家的国民或公民的法律资格”（《辞海》），没有法律定义自然没有所谓的“国籍”，没有nationality的第二种含义。您可以说李善兰是清朝数学家，但不能说他是大清帝国籍的数学家。不能这样硬套上去的。--Ghren🐦🕛 2024年5月12日 (日) 16:59 (UTC)[回复]
没有为国籍这一概念立法时，就不存在“official right”概念了吗。依旧有法律和现实意义上的国籍身份和权利义务，只是未成文或者以其他形式体现。[7]。当然，谨慎运用减少问题是应当的。另外，金毓黻条目那种，我会怀疑原创研究。--YFdyh000（留言） 2024年5月12日 (日) 17:17 (UTC)[回复]
我会认为“中华人民共和国”适用于虽没有为国籍这一概念立法，但有“official right”的说法，算作有国籍或者合适。但再拉前到清朝立国籍法前的年代，实在有欠谨慎。--Ghren🐦🕐 2024年5月12日 (日) 17:27 (UTC)[回复]
另，马丁·路德现时标注的国籍是“萨克森选侯国”。国籍形成在民族国家之后的事，为其标注国籍是否不正当？--Ghren🐦🕙 2024年5月12日 (日) 14:50 (UTC)[回复]
民族国家产生之后一个人也不一定拥有国籍吧？
要没有来源不如不标国籍，而且国籍是一个人属于一个国家国民的法律资格，国籍法出现之前何来国籍之说呢？--newerdrawn（留言） 2024年5月12日 (日) 15:46 (UTC)[回复]
可以参考UNHCR对1954年《关于无国籍人地位的公约》的阐述[8]，【该定义中提及的“法律”应当宽泛理解为不仅包括立法，还包括部级法令、条例、命令、判例法（在有先例的国家），并在适当时包括习惯做法】，“包括习惯做法”。所以，正式设立国籍法前，在世俗意义上，仍可能认为和称之为国籍？比如获得了当地户籍、居住权之类的？--YFdyh000（留言） 2024年5月12日 (日) 16:08 (UTC)[回复]
所以您认为“萨克森选侯国”是合适的国籍？还是应该是“德国”？--Ghren🐦🕐 2024年5月12日 (日) 17:01 (UTC)[回复]
应该明确规定禁止擅自为近代以前历史人物添加国籍，这是对资讯框nationality参数的滥用。至于“中共”国籍的例子，我就觉得有点吹毛求疵，无论如何要说彼时中国大陆居民处于无国籍状态是不合情理的。但其实多数人物没有添加nationality参数的必要吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月12日 (日) 17:02 (UTC)[回复]
我承认有点吹毛求疪，但这是有实际问题的。像是朝鲜战争间来台的大陆的“反共义士”的国籍、国军与解放军间的驾机叛逃事件等等的国籍问题等等。中华民国当时不承认大陆国籍，自然不存在“反共义士”的“中华民国”国籍被取消的问题。实务上，我认为搞不清楚就不要填为妙，就用“效忠”字段绕过他就好嘛。--Ghren🐦🕐 2024年5月12日 (日) 17:23 (UTC)[回复]
真要较真的话，那些人应该一直都是中国人（华籍），只是政府承认转换问题，与国籍本来无涉。但这其实是政治问题，我认为本站编者不应该为自己凭空制造麻烦。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月13日 (一) 08:48 (UTC)[回复]
或者没有可靠来源提出该人的国籍，就不应当在条目中或信息框中注明国籍？--百無一用是書生 (☎) 2024年5月13日 (一) 02:53 (UTC)[回复]
应该慎重考虑引进，尤其近年来原创研究现象一直很严重。试想某人生于美国、居于美国、死于美国，那推想其国籍为美国也是很正常的事情，但资讯框这样记载有什么意义？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月13日 (一) 08:48 (UTC)[回复]
生于美国、居于美国、死于美国，还真的未必就是美国国籍....--百無一用是書生 (☎) 2024年5月13日 (一) 09:01 (UTC)[回复]
对呀！所以原创研究是不对的。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月13日 (一) 17:04 (UTC)[回复]
又顺带一提，像钱锺书这种标示国籍，在国籍里硬塞朝代变迁有什么意义呢？--Ghren🐦🕐 2024年5月12日 (日) 17:49 (UTC)[回复]

关于跨行政区域的实体，是否应该使用多个分类

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:页面分类。

注意到@User:Yumeto阁下的这笔编辑→Special:Diff/80624989，长城作为跨越中国半数的省级行政区的实体，我觉得更合理的做法应该是直接挂《分类:中国世界遗产》，而不是每个省的分类都挂一遍，这样就太多了，也不符合WP:CAT#几点重要的共识里的意思：一个条目可以归属于几个分类，但是归属过多的分类会失去其重心。

来问问社群的看法，如果没什么不同意见的话，希望可以作为共识纳入WP:CAT#几点重要的共识，也可以方便其他条目在遇到同样问题时有个指引好操作。--——— 红渡厨（留言・贡献） 2024年5月13日 (一) 09:18 (UTC)[回复]

基本赞同。但想了解Yumeto此举的理由。--YFdyh000（留言） 2024年5月13日 (一) 09:54 (UTC)[回复]
联合国宪章应该挂各国条约分类还是只挂条约母分类？我觉得这种分类原则可能要按个案判断。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月13日 (一) 11:22 (UTC)[回复]
阁下可能没看清楚标题，我说的是实体，不是条约。--——— 红渡厨（留言・贡献） 2024年5月13日 (一) 11:50 (UTC)[回复]
E是在用条约条目（如联合国禁止酷刑公约）与“×国条约”分类类比，并非无关。--绀野梦人 2024年5月13日 (一) 12:42 (UTC)[回复]
《联合国禁止酷刑公约》下面这些密密麻麻的分类给我头都看大了。。。。。--——— 红渡厨（留言・贡献） 2024年5月13日 (一) 12:45 (UTC)[回复]
基本赞同User:红渡厨君，不过依此逻辑，台湾大部分县（市）道等级以上的公路也应该都要改了，例如台17线，其Category:台中市省道、Category:彰化县省道、Category:云林县省道.....、Category:屏东县省道等分类全部都应该删掉，我认为这作法有待商榷。-游蛇脱壳/克劳棣 2024年5月13日 (一) 11:25 (UTC)[回复]
那就删掉嘛。--——— 红渡厨（留言・贡献） 2024年5月13日 (一) 11:51 (UTC)[回复]
@红渡厨：删掉！？可是为什么同样都是经过高雄市的省道，全线在高雄市境内的台25线、台28线、台29线可以分在Category:高雄市省道，跨县市的台17线却不能分在这个分类中呢？有合情合理的解释吗？-游蛇脱壳/克劳棣 2024年5月14日 (二) 17:00 (UTC)[回复]
同时涉及多个政区的条目同时归入相应分类并无不妥，如青函隧道同时涉及青森县今别町与北海道知内町，AT就将条目同时归入了相应分类（特殊:差异/43748836）。这样的归类方式在本站拥有丰富实践，又如珠穆朗玛峰、湄公河等。本次提及的“长城”条目同时归入多个“×省级行政区世界遗产”分类难谓不妥。--绀野梦人 2024年5月13日 (一) 12:36 (UTC)[回复]
可是理由呢？阁下仅仅只是因为有人这样做就依葫芦画瓢？您并未给出这样做的合理理由。--——— 红渡厨（留言・贡献） 2024年5月13日 (一) 12:43 (UTC)[回复]
严格来说，这只是分类原则问题，不涉及事实问题。因为长城确实是某些省市的世界遗产，同时当然也可以归类为中国整体的世界遗产，两者皆有理。社群只是要抉择哪一种分类方式较适合本地整理、追踪及维护条目。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月14日 (二) 15:00 (UTC)[回复]
这里牵涉到分类断层的问题，联合国禁止酷刑公约确实有很多分类，不过如果都移除也会造成分类断层，我也实在想不到更好的方法可以平衡两者。长城的话，由于其由多个部分组成，那就在各个相对部分添加地区分类，主条目也就不用加了。另一方面，像台17线这种无法划分的话则沿用，不然都往母分类塞的话也会造成分类过于拥肿的问题。--AT 2024年5月13日 (一) 13:04 (UTC)[回复]
世界遗产的长城涉及17个省级行政区（[9]），本站单独条目覆盖不了，从分类断层来说还是需要回归到整体的条目。--绀野梦人 2024年5月13日 (一) 13:18 (UTC)[回复]
如果长城的各部分仍然不足以细分的话，那当然沿用。--AT 2024年5月13日 (一) 13:30 (UTC)[回复]

必须防止滥用“防滥用过滤器”

我现在按捺住怒气好好的请问各位有权在防滥用过滤器加东西的各位。请问有什么方针可以防止滥用这个过滤器？要加东西前有商议过吗？有测试过吗？有累积被误判的文字作为测试资料吗？有定时巡察修正吗？加错了东西有人给予提醒吗？封锁范围太大有检讨过吗？修正之后有公布被修掉的敏感词以防后来又被不明事理的ＸＸＸ加回去吗？啊？

还是正如我所想，爱加就加，加了不管。有人反应就来来回回你一言我一语表示自己没错，单纯你唔注册你唔好彩？把人的热情磨掉再来慨叹人手不够吗？把人磨出怒气讲话不客气再来封杀吗？有权力加东西的人就这样把成本转嫁给别人吗？啊？

上次在反应的过程中，道理讲不过就偷加CAPTCHA玩人。这次就看又要讲出什么道理，又要中途加什么东西玩人。--2603:8000:500:FB00:19E0:922D:68FA:F58（留言） 2024年5月16日 (四) 01:52 (UTC)[回复]

从日志来看，你触发的是Special:滥用过滤器/229，应该是你加入“顶尖”这两个字触发了。--世界解放者（留言） 2024年5月16日 (四) 02:12 (UTC)[回复]
如有任何对防滥用过滤器的任何问题，请至维基百科:防滥用过滤器/错误报告反应。--唔好阻住我爱国（留言） 2024年5月16日 (四) 02:13 (UTC)[回复]
他已经去反映了。--世界解放者（留言） 2024年5月16日 (四) 02:17 (UTC)[回复]
这个过滤器229真是令人好气又好笑，果然是被滥用了。说滥加的人是不明事理的ＸＸＸ果然没说错。不但不明事理，而且是顶尖的不明事理。硬要限制？那我说你是一流的无敌的没人比得上的不明事理，是不明事理中的首选、头号、头牌、王牌、天王、教主。是天字第一号的不明事理，是天下无双地上独有的不明事理。我就是要告诉滥加的人，这种限制除了逼人发脾气外，有多么无意义。
所以之前的问题仍然成立：
＊加敏感词之前有没有经过商议？有没有经过测试？还是爱加就加？行使这种滥杀无辜的权力后再来扮可怜说其实没什么权力？
＊加了之后是否定期审议？还是就长长久久的放在那里等人一头撞上去？
＊终于良心发现拿掉不合理的限制后，是否保留被误杀的篇章作为以后的测试资料？还是就算了，反正下次再滥加？
究竟标准在哪里？你要嘛把我上面的形容词，以及我漏掉的，全加进去。要嘛拿掉这莫明其妙不明事理的滥用。因为现在很明白了，是“防滥用过滤器”被滥用了。而且看来打算要用到滥。
不过，比较可能的是，要嘛，讲出个歪理来看看；要嘛，装死。反正爱加就加，其奈我何。生气你自生气，好官我自为之。--2603:8000:500:FB00:19E0:922D:68FA:F58（留言） 2024年5月16日 (四) 05:40 (UTC)[回复]
然后CAPTCHA并不是什么偷加的，本来就是自动确认使用者才不会出现。--冥王欧西里斯（留言） 2024年5月16日 (四) 08:14 (UTC)[回复]
过滤器229并非阻止原因，该过滤器只有标记的动作。阻止2603编辑的是一个私有过滤器。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月16日 (四) 12:12 (UTC)[回复]
见[10] ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月16日 (四) 12:13 (UTC)[回复]
在条目中加入的词被有权的人不喜欢，叫滥用。那在“防滥用过滤器”中滥权滥加，是不是滥用？是不是也要防滥用？
要说不是滥用，那在“防滥用过滤器”中增减敏感词，有没有方针？有的话，合不合理？有没有遵守？没有的话，要不要立方针或指引？凭个人喜好滥加，是不是滥权？过滤器居然还有私有的。说偷加，就本来没有。还硬要说本来怎样怎样，当别人今天才来受气的吗？
有这种爱加就加的大权，就再也不要装可怜说没有什么权力，太令人反感了。人被机械式过滤玩弄的耐性是有限的。做人差不多一点，好好检讨一下现有的敏感词，不要没事把平常人逼成破坏者再来抱怨。--2603:8000:500:FB00:DC0B:D5AF:D934:304B（留言） 2024年5月16日 (四) 23:21 (UTC)[回复]
不是229，是隐藏过滤器201导致的编辑不成功。这个过滤器的增添删简确实没有任何公开正式讨论的过程，因为本质上是隐藏的。而且确实是一个规则内容很长很长的过滤器，至少有几百到一千条规则，一眼看不出来具体触犯了哪个部分。总的而言他过滤的是加入“畜生、吊你老母”这样的词汇，其近期的记录表明这个过滤器还是相当有价值并且误报率并不高（我翻查了15个最近过滤结果，基本全都是简单的纯破坏行为，比如将张某人改为吊某人）。ps 我看到最近有一名管理员Xiplus去除了一条规则，这个规则写的太不严谨导致误判了“黑人警察”这个词，我确定就是这个规则导致的编辑失败。现在这个问题已经获得改正了。我将您之前未能加入的文字暂存在这里，以利您继续编辑，我通过测试功能确认这些文字现在可以直接加入。Bluedeck 2024年5月17日 (五) 08:32 (UTC)[回复]
这种隐藏过滤器之所以隐藏，其理论是，如果公开，那么在大家都知道具体规则了，就可以更有效的绕过去。感觉有点黑箱政治的意思，但是同时也有实用上的理由。Bluedeck 2024年5月17日 (五) 08:52 (UTC)[回复]
黑箱政治是问题，但黑箱到连内部的人都没弄清楚是黑箱中的哪一条出问题，那这问题可真大了。你看前面有多少人指出了错的过滤器？意思是任由少数知情人藏下去的话，大部分人都会搞不清楚情况，然后这个问题会一直持续下去（因为修错地方了嘛），你觉得这可以继续下去？都不用有个方针？
加东西前要求测试这不过分吧？加这条不严谨导致误判的规则时有没有测试？用什么测试？自己滚出来讲！
测试材料也是现成的，就典范条目。摘几条典范条目滤一滤，如果撞上了，要么典范条目有问题，要么这劳什子过滤器新加进去的东西有问题，看要怎么修。如果说得出测试了几十条典范条目都没出问题，那我服气。不去计较是否有人刻意钻漏洞，“黑人警察”这种词不拿剧情或时事相关条目测试，专拿不可能碰撞的条目测试之类的。但现在拿得出来吗？还是那句话，滥权滥加滥杀无辜！
所以说，要测试！不但要有现成的测试数据库（典范条目），像这样新撞上的文字也要留着当测试资料，防止以后又来一次！
而这劳什子过滤器的真正目的也要讨论一下，是拿来挡人，还是拿来挡文字？拿来挡人显然用错工具，虽然我了解是为什么会这样用，但我很不高兴在回应的讯息中暗示我可能是破坏者。每多暗示一次，就多增我一分成为真正破坏者的意图。如果是用来挡字词，那不是该列出来让大家别去碰吗？上面示范过怎么绕过去了。把挡文字的工具拿来挡人，然后为了不让想挡的人绕过去所以要神秘兮兮，荒谬嘛这是。因为现有的铁锤不好用，你拿螺丝起子的柄当榔头敲钉子，为了好敲而禁止在柄上缠胶带防止手滑，这说得过去吗这？
我建议在下次有人撞上这种诡雷前，拿这劳什子过滤器把典范条目滤一滤，看看上面说的设测试数据库是否合理，也测测看过滤器的劳什子规则中藏了多少污纳了多少垢！有人喜欢自设诡雷炸掉别人编写条目的热情，让被炸到发脾气的人在此和一堆人内耗，我可一点都不喜欢。更好笑的是，这么多人诚心诚意的想解决问题，却都不得其法，就只因设诡雷的人的自以为是！
方针！测试！--2603:8000:500:FB00:44A6:A5DD:7D90:E64F（留言） 2024年5月17日 (五) 22:31 (UTC)[回复]
Calm down, we are fixing these filters by writing better regex. If you wanna help, why don't you register an account to give us some advice?
GT:冷静下来，我们正在通过编写更好的正则表达式来修复这些过滤器。 如果您想提供帮助，为什么不注册一个帐户来给我们一些建议呢？ -Lemonaka 2024年5月17日 (五) 11:59 (UTC)[回复]
You want to encourage people to register? make the Wikipedia so attractive to editors that outsider doesn't want to miss it, not to make it so inconvenience to force others join in, OK?
想鼓励大家注册？那就让维基百科对编辑者具吸引力，令人不想错过。不是刻意造成不便来逼人加入，好吗？--2603:8000:500:FB00:44A6:A5DD:7D90:E64F（留言） 2024年5月17日 (五) 21:51 (UTC)[回复]

提议外部链接指引WP:ELNO同时编入WP:可供查证。

WP:ELNO

除非是关于条目主题的官方网站，否则应该要避免：

1.透过不实讯息或无根据之研究误导读者的网站，除非（在有限的情况下）该条目是关于该网站所表达的观点。 含有恶意软件、恶意脚本、木马，或任何违反佛罗里达州（维基百科的服务器位置）的法律的内容。

2.主要为推广或宣传某网站的连结，包括网上请愿。 主要为贩卖物品或服务的网页[注 1]，或是有大量广告的网页。例如，手机条目里就不该有外部链接是连到贩卖、推销手机产品或服务的网页。

3.需要注册或付费才能观赏内容的网站链接，除非是相关的官方网站。注意此规则并不适用于为条目参考来源的网站。参看这里。

4.大部分读者不易进入之网站链接，例如需要特定浏览器、或者在特定区域才能浏览的网站。

5.连结到某个档案，而该档案须要启动外部程式或插件（如Flash或Java）才能浏览；除非该条目与此档案格式有关。

6.连结到诸搜索引擎或RSS讯息来源等服务的搜寻结果。

7.社群网络服务的网址（如MySpace、Facebook）、聊天室、论坛／讨论区、微博（如Twitter、Plurk）、Usenet新闻组或邮件列表。

8.网志、个人网站及绝大部分的支持者（歌迷、影迷等）网站，除非是由公证的有关方面所维护。要注意的是，公认的有关方面的条件是很严谨的。最起码要达到维基百科对人物的关注度要求的标准。

9.开放式的Wiki网站；除非是已经长期稳定地运作，且有可观数量编者的网站。拷贝维基百科的网站也不该被连结。

10.仅间接与条目主题相关的连结。涉及各样主题的网站链接通常不该放在一个只讲述特定主题的条目之中。同样地，一个只涉及某特定主题的网站链接通常也不该放入一个涉及大范围主题的条目之中。如果，某网站的某一章节、某一部分、或某一档案是专注于该条目的主题时，在符合本指引其他要求下，可直接放置该章节或档案的连结。

11.制造商、供应商或客户的连结清单。

12.已经用维基工具连结的网站。例如，使用ISBN 1234567890的方式来代替连结到网络书店上的某一本书。

13.一个稳定性或可用性不高，或者有此可能的网站。譬如说，连结到一个临时的网站或网址、快取内容等等。

14.含有联盟行销、推荐行销、或上网者行为追踪的连结。如果来源本身是有用的，请使用无追踪功能的连结。

15.维基百科的导航模板或诸如消歧义、重定向、分类等导航页的外部链接。

16.只是在条目里提及的组织的网站链接，除非符合〈应该要连结的网址〉或〈可考虑连结的网址〉。

17.外部链接列表为条目唯一的内容。也避免在条目中除了末尾〈外部链接〉以外的章节，陈列外部链接。

在此指引的第一句清楚说明此指引不适用于参考连结，唯本人认为部分句子也与WP:可供查证精神相等，看看如何融入WP:可供查证方针内。--唔好阻住我爱国（留言） 2024年5月17日 (五) 03:02 (UTC)[回复]

“唯本人认为部分句子也与WP:可供查证精神相等”←需要解释。另注意ELNO不代表就一定不适合作为参考来源，一个连结是否符合WP:可供查证应以WP:可靠来源来评估，并非以是否属于ELNO来评估。--街燈電箱150號 开箱维修 抄表 检验证明 2024年5月17日 (五) 12:39 (UTC)[回复]
你不能只提出很含糊的“精神相等”，然后不提出具体问题、方案。--Ghren🐦🕘 2024年5月17日 (五) 13:45 (UTC)[回复]
冷静点，刚才我也未有时间说明…个人认为当中三条可以引人，包括：
———
3.需要注册或付费才能观赏内容的网站链接，除非是相关的官方网站。
4.大部分读者不易进入之网站链接，例如需要特定浏览器、或者在特定区域才能浏览的网站。
5.连结到某个档案，而该档案须要启动外部程式或插件（如Flash或Java）才能浏览；除非该条目与此档案格式有关。
———
@Cdip150、@Ghren:
1.请问现时有没有任何方针或指引可以拦截上述网站？可靠来源及可供查证方针会不会限制“需要注册、付费、特定浏览器、或特定区域”才能阅读网站？
2. 其实此条文倡议是呼应上方MOS:TVINTL提案。有编辑者认为“需要注册、付费、特定浏览器、或特定区域”不利存档机构人对网站存档，而且仅限一少部分人才可查证，列出这些连结与可供查证原则相违背，故提案。
所以建议条文是：
——--唔好阻住我爱国（留言） 2024年5月17日 (五) 16:10 (UTC)[回复]
现行条文

添加或恢复内容的编辑者应承担举证的责任。所有引言以及任何被质疑或可能被质疑的内容均应使用内嵌引用来提供可靠、公开的来源。[1]引用的来源须明确支持条目中出现的信息。[2]来源须以清晰而准确的方式列出，以使读者能够找到支持被质疑内容之原始材料。编者应完整引用来源，尽可能多地提供出版物信息，在引用书籍时应注明至章节。[3]

提议条文

添加或恢复内容的编辑者应承担举证的责任。所有引言以及任何被质疑或可能被质疑的内容均应使用内嵌引用来提供可靠、公开的来源。[4][5]引用的来源须明确支持条目中出现的信息。[6]来源须以清晰而准确的方式列出，以使读者能够找到支持被质疑内容之原始材料。编者应完整引用来源，尽可能多地提供出版物信息，在引用书籍时应注明至章节。[7]

———
就此，建议新增下列句子：由于需要注册、付费、特定浏览器、特定区域、启动外部程式或插件的网站不利读者查证条目中出现的信息，故编辑者不应引用这些网站。--唔好阻住我爱国（留言） 2024年5月17日 (五) 16:24 (UTC)[回复]
请参考Wikipedia:可靠来源#在线与非在线的材料的部分，然后您可以类比一下线下出版物和您所列的“不利读者查证条目”的来源。出版物是需要钱购买的（付费来源）；就算是借阅，也是有指定图书馆的（地区限制），也是需要注册图书证的（注册）。知识本来就不应该是免费的。对于付费墙或者注册，您维的{{Cite}}模版甚至已经有“url-access”参数来说明来源的性质了，既是您维制度内充许的东西，“拦截上述网站”自然无从说起。您所加的“需要注册、付费、特定区域、启动外部程式或插件的网站”（我不清楚什么情况需要特定浏览器）根本不利于实际编辑，也无损于来源的可靠性。而且请您在条文没有大变动的时候，不要大量抄录方针内容，谢谢。--Ghren🐦🕐 2024年5月17日 (五) 17:00 (UTC)[回复]
  • 你所说的是第二、三手来源，而我想说的是初级来源。
  • “需要注册、付费、特定区域、启动外部程式或插件的网站”针对第一手来源，又算不算“公开发布”？
  • 一个设立重重关卡的初级来源（直指一般网站而非学术网站），又如何达至可供查证？
--唔好阻住我爱国（留言） 2024年5月18日 (六) 06:12 (UTC)[回复]
--Ghren🐦🕑 2024年5月18日 (六) 06:38 (UTC)[回复]
承上意见，很多线上的学术论文与标准化文件也是需要注册或付费才能观赏的（例如电机工程师学会的线上文献），您这么一搞很多可靠的线上文献都会遭殃。请注意少部分人才可查证并不意味完全不可查证，是故无从谈起与可供查证原则相违背。如果在上面TVINTL定了这种规则的话，那边我只能反对了。--街燈電箱150號 开箱维修 抄表 检验证明 2024年5月17日 (五) 17:12 (UTC)[回复]
部分需要注册或付费才能观赏的来源能透过网络存档查阅。 --窝法乙烷 儿法梦碎 2024年5月18日 (六) 04:41 (UTC)[回复]
这个是知道的，而以CDN进行地区限制访问的网站正正窒碍了资讯传递。同一个网站，在A地区传播A资讯，在B地区传播B资讯，当我认为B资讯是有用的，想在维基引用，但由于A地区人因看不到B资讯，A地区人会因无法证实“同一个网站”有提供B资讯，甚至乎B地区人不知道其他地区的“同一个网站”是否也存在B资讯，故回退。
  • 按照上方各位大大认为，这个例子不应回退，对吗？
--唔好阻住我爱国（留言） 2024年5月18日 (六) 06:23 (UTC)[回复]
那注明这个网页的资讯在不同地区会有不同的结果，然后注明你是在哪个地区下浏览就好了啊。--Ghren🐦🕑 2024年5月18日 (六) 06:41 (UTC)[回复]
1.哪个cite 模版有这个设计？
2. 甚至乎B地区人不知道其他地区的“同一个网站”是否也存在B资讯—>意指B地区人认为全世界均有B资讯。“ 这个网页的资讯在不同地区会有不同的结果”为无从判断。--唔好阻住我爱国（留言） 2024年5月18日 (六) 07:35 (UTC)[回复]
参照Netflix小影片想列出播放准确播放地区，按照阁下的见解，实际上是中了原创研究的陷阱。--唔好阻住我爱国（留言） 2024年5月18日 (六) 07:47 (UTC)[回复]

参考资料

  1. ^ 在维基百科中，当内容要求被直接证实时，现有惯例是在内嵌引用中提供支持内容的参考文献。这样能最为直接地核实条目内容与参考文献是否一致。其他已有的惯例如果亦能清楚且准确地解释条目中的断言，则同样可以接受，但内嵌引用依然是此种目的下的最佳方式。详情请参考维基百科:列明来源。
  2. ^ 不同人之间有时会对所给来源是否能完全支持条目内容产生争议。此时可直接引用来源原文以及被要求的其他细节信息，来说明来源真实可靠。
  3. ^ 注明章节时不要求注明至页码，因为一些畅销书会再版，刊物会出合订本，页码可能有变。页数亦可注，因为在章节页数大时可加注页码以方便查证。
  4. ^ 在维基百科中，当内容要求被直接证实时，现有惯例是在内嵌引用中提供支持内容的参考文献。这样能最为直接地核实条目内容与参考文献是否一致。其他已有的惯例如果亦能清楚且准确地解释条目中的断言，则同样可以接受，但内嵌引用依然是此种目的下的最佳方式。详情请参考维基百科:列明来源。
  5. ^ 由于需要注册、付费、特定浏览器、特定区域、启动外部程式或插件的网站不利读者查证条目中出现的信息，故编辑者不应引用这些网站。
  6. ^ 不同人之间有时会对所给来源是否能完全支持条目内容产生争议。此时可直接引用来源原文以及被要求的其他细节信息，来说明来源真实可靠。
  7. ^ 注明章节时不要求注明至页码，因为一些畅销书会再版，刊物会出合订本，页码可能有变。页数亦可注，因为在章节页数大时可加注页码以方便查证。

技术

Template:Weather box

本主题或以下段落文字，在讨论结束后应存档至Template talk:Weather box。

天气模板Template:Weather box，可以添加参数|width=auto以自动适应条目，但是在有信息框的条目中添加该参数并不总是会自适应，比如韦斯卡 (78803227)会在气候模板上方出现大段空白（可能也是信息框/Infobox的原因）。--Kethyga（留言） 2023年9月5日 (二) 10:03 (UTC)[回复]

自带{{clr}}效果？如果没有，表格在小屏幕宽度下不会放不下吗。--YFdyh000（留言） 2023年9月9日 (六) 04:14 (UTC)[回复]
手机网页和App看了下，应该都要左右滑动。--Kethyga（留言） 2023年9月9日 (六) 08:20 (UTC)[回复]
应该又是V22皮肤的css更新所致，换成2010版皮肤看是正常的。--萧漫（留言） 2023年10月10日 (二) 02:44 (UTC)[回复]
似乎现在显示效果正常了？--Kcx36（留言） 2023年11月15日 (三) 10:39 (UTC)[回复]
目前已 无法重现。 Willy1018（留言） 2023年11月19日 (日) 02:50 (UTC)-- Willy1018（留言） 2023年11月30日 (四) 03:21 (UTC)[回复]
在条目韦斯卡中，未登录和Timeless Skin下目前均无法自适应页面宽度。--Kethyga（留言） 2023年11月27日 (一) 04:11 (UTC)[回复]
我的显示效果。--Kcx36（留言） 2023年11月27日 (一) 04:50 (UTC)[回复]
发现新版皮肤/外观在未登录状态下的右下角有一个切换“全屏宽度”和“有限宽度”的按钮，如果选择“全屏宽度”的话就不会被信息框/Infobox遮挡，但是Weatherbox/天气框仍未填满空间。另外在条目洛帕中，Timeless Skin下可以正常自适应页宽。--Kethyga（留言） 2023年11月28日 (二) 01:55 (UTC)[回复]
@Kethyga：英文维基百科也有这种情形吗？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月29日 (一) 17:28 (UTC)[回复]
@Ericliu1912 en:Wikipedia:Sandbox (1220692034) 在英维的效果，个人认为无问题，右侧的信息框一般不会遮挡天气框。--Kethyga（留言） 2024年4月25日 (四) 09:52 (UTC)[回复]
@Kethyga：若直接复制来本地，是否可行？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月25日 (四) 15:28 (UTC)[回复]
得先测试看看了，不知道差异大不大，另外也不知道是否只是 Weather box 的问题。--Kethyga（留言） 2024年4月26日 (五) 01:30 (UTC)[回复]
本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

MobileFrontend侧边栏故障

[11] Log in（登录）、Settings（设置）、Donate（资助）、About Wikipedia（关于Wikipedia（随维基媒体计划名称而变））、Disclaimers（免责声明）均无法被点击，也无法对其长按弹出浏览器菜单，全站（所有语言、所有维基媒体计划）均发生该问题。--Txkk（留言） 2023年11月29日 (三) 03:05 (UTC)[回复]

在firefox下未能复现，可点击，可弹出浏览器菜单。但是侧边栏各项一点击或弹出浏览器菜单时（点击鼠标左键或右键时），侧边栏就会迅速缩回，虽然点击的链接打开没问题（选择使用弹出的浏览器菜单中的功能也没问题），但是用户体验比较糟糕。从前端角度看，很可能算是个bug--百無一用是書生 (☎) 2023年11月29日 (三) 03:20 (UTC)[回复]
似乎现在mediawiki更新后，这个问题（或类似问题）已不存在了？--百無一用是書生 (☎) 2023年12月15日 (五) 11:56 (UTC)[回复]
还在。--Txkk（留言） 2023年12月15日 (五) 21:21 (UTC)[回复]

有没有人去Phabricator报告问题？--Txkk（留言） 2023年12月25日 (一) 06:46 (UTC)[回复]

我现在是只有关于和免责声明点击后侧边栏缩回，页面不跳转--百無一用是書生 (☎) 2023年12月25日 (一) 07:47 (UTC)[回复]
本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

引文模板不应该报错全部的零宽空格

本主题或以下段落文字，在讨论结束后应存档至Module talk:Citation/CS1/Utilities。

Cat:引文格式1错误：不可见字符现在只要有U+200B就会报错，实际上有些零宽字符是合理且必要的，比如emoji和孟加拉文使用其连接字符。

建议将其改为维护而不是错误。--落花有意12138 2023年12月16日 (六) 12:44 (UTC)[回复]

en:Module:Citation/CS1/Configuration有为特定文字或Emoji添加例外。--Cookai饼块🍪（💬留言） 2023年12月24日 (日) 10:10 (UTC)[回复]
等等，Module:Citation/CS1/Configuration也有indic_script，但Module:Citation/CS1没有把它排除。--Cookai饼块🍪（💬留言） 2023年12月24日 (日) 10:19 (UTC)[回复]
请问此问题有办法解决吗？《乱世勇者》的97号来源出现此情况，但不知道该如何解决。--H2226（留言） 2024年1月7日 (日) 10:11 (UTC)[回复]
要改的是Module:Citation/CS1/Utilities的has_invisible_chars，en的has_invisible_chars在en:Module:Citation/CS1，看有没有高人要来修。--Cookai饼块🍪（💬留言） 2024年4月24日 (三) 04:58 (UTC)[回复]
本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

“阅读无障碍”功能和本站小工具兼容问题以及字号选择

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:Vector 2022。

于Phabricator查看
编号T358119的工单
状态：已解决

测试功能中Vector 2022的“阅读无障碍”功能之前和本站大字体小工具存在兼容性问题，目前主要问题已经修正，但是存在若干遗留问题。

该测试功能有三个挡位，“小”对应14px，“标准”对应16px，“大”对应20px，并无本站目前使用的15px。本来该功能是有望让小工具在Vector 2022下直接退役的，但由于缺少15px所以目前不行。

目前个人认为有以下解决方案，请社群评估：

  1. 维持现状（大字体小工具将“小”修改为15px，其他不变）。
  2. 让大字体小工具在打开“阅读无障碍”时直接失效，之后在正式部署“阅读无障碍”时调整为默认启用16px，小工具退役。注意会导致默认字号改变。
  3. （新增）让基金会加上15px的挡位，正式部署时默认启用，小工具退役。

以上。--碟之舞📀💿 2024年2月23日 (五) 02:13 (UTC)[回复]

我个人会倾向2。--冥王欧西里斯（留言） 2024年2月23日 (五) 03:56 (UTC)[回复]
@S8321414：刚刚加了个3，提醒一下。--碟之舞📀💿 2024年2月23日 (五) 13:36 (UTC)[回复]
有看到，但我个人还是倾向2，但不排斥3。--冥王欧西里斯（留言） 2024年2月23日 (五) 13:59 (UTC)[回复]
阅读方面14px和15px我感觉都行，但排版变化明显。顺便一提，Timeless皮肤下是15.2px。16px感觉较大，但部分用户和繁体用户可能偏爱。--YFdyh000（留言） 2024年2月23日 (五) 14:02 (UTC)[回复]
依据“阅读无障碍”功能的文档“Small is the current default”，而本站预设启用“大字体”小工具及实际上本站预设字体为 15px 而非 14px，故“小”选项应由现时的 14px 增加至 15px，或是增加 15px 的选项及成为预设选择。至于“大字体”小工具，当“阅读无障碍”功能仍在测试阶段时应改为不覆盖该功能字体设定，待该功能正式部署后才仅在 Vector 2022 暂停使用。谢谢。--SCP-0000（留言） 2024年2月23日 (五) 15:22 (UTC)[回复]
另外，没坏就不要修，除非有明确共识或证据支持其他字体大小比现时预设的 15px 更佳。--SCP-0000（留言） 2024年2月23日 (五) 15:30 (UTC)[回复]
“小”选项由现时的 14px 增加至大字体的 15px，大家不觉得这让很多人难以理解吗？小变成了大，但却还是叫做小。。。
总的来说，15px是中文网页（可能也包括日文网页）最常见的字体大小（可认为是最优），但是随着近几年显示技术和网页技术的变化，是否15px还是最优可能需要再探讨。另外，偶数大小（14、16）从网页设计上来说更方便计算和取整，可以避免一些页面排版和渲染方面意外的发生。所以最后还是要权衡利弊，是保守原来的不变，还是拥抱新变化，还是只要最优大小，还是虽然不是最优但能够更灵活？--百無一用是書生 (☎) 2024年2月26日 (一) 02:27 (UTC)[回复]
更新：Jon (WMF)表示可以针对不同语言调整预设值大小。--碟之舞📀💿 2024年2月24日 (六) 02:21 (UTC)[回复]
那正好，基于最小修改原则，新版外观预设字体大小应该就设定为原本者。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月25日 (日) 16:52 (UTC)[回复]
@SGrabarczuk (WMF): BTW, I have read the analysis of the community prototype testing and I found that the analysis mixed up the data from communities using Latin and CJK characters. Since Latin and CJK is quite different (FYR the comparison by Google), perhaps re-analysis and only focus on the data from communities using CJK character (Chinese, Japanese, and Korean Wikipedia) if possible? Thanks.--SCP-0000（留言） 2024年2月28日 (三) 05:39 (UTC)[回复]
Hey @SCP-2000, that's interesting, thank you for pointing this out! Our designer broke down that data by different scripts. So he must have taken this into consideration. But as I can see, this breakdown didn't make it to the wiki page. I'll ask him.--SGrabarczuk (WMF)（留言） 2024年3月6日 (三) 16:22 (UTC)[回复]
@SGrabarczuk (WMF): Hello, any update of this matter? Thanks.--SCP-0000（留言） 2024年3月24日 (日) 17:23 (UTC)[回复]
Hello @SCP-2000, I'm happy to share that I do have an update :D
Ultimately, it will be possible for local users (specifically, admins, if I'm not mistaken) to change the settings (only by increasing the values) for the entire wiki. This will be possible via the Community configuration tool. It was originally built for newbies and mentors, but it's gonna be connected with other features as well.
In the meantime though, our team will be happy to make those changes for you.
However, if I'm not mistaken, it will not be necessary since our proposed new default ("Standard", 16px) is a bit larger than the current default on this wiki (15px). Am I forgetting about something?
What do you think about all this? Thanks!--SGrabarczuk (WMF)（留言） 2024年3月29日 (五) 22:37 (UTC)[回复]
@SGrabarczuk (WMF): Hello, thanks for your information:)
We are currently in a discussion about which font size (i.e. 14, 15 or 16px) is better. That was why I asked if there is any data from communities using CJK characters, so that help us make a better decision. Anyway, we'll let you know if we reach the consensus.--SCP-0000（留言） 2024年3月30日 (六) 12:31 (UTC)[回复]

@Diskdance、S8321414、YFdyh000、Shizhao、Ericliu1912： 考虑到现时未见有广泛共识同意更改预设字体大小，个人认为较佳的做法是维持现况（即 15px）。而 WMF 愿意依据社群意见更改字体大小，故个人建议将 Vector 2022 未来的预设“标准”选项（ “our proposed new default ("Standard", 16px)”）改为本站现时的 15px。至于“大字体”小工具，当“阅读无障碍”功能仍在测试阶段时改为不覆盖该功能字体设定，待该功能正式部署后才仅在 Vector 2022 暂停使用。不如各位意下如何？谢谢。--SCP-0000（留言） 2024年3月30日 (六) 12:59 (UTC)[回复]

个人支持SCP所述做法。但是需要考虑是否要相应调整“大”选项的字号。--碟之舞📀💿 2024年3月30日 (六) 13:13 (UTC)[回复]
所以现在是变成要把“标准”改为15px而非把“小”改为15px？我个人仍是比较倾向让这三个选项维持原本的14、16、20px，让小工具在Vector 2022失效，但也不反对将“标准”改为15px就是（是说原本选15px究竟是什么原因？）。--冥王欧西里斯（留言） 2024年3月30日 (六) 13:27 (UTC)[回复]
“所以现在是变成要把“标准”改为15px而非把“小”改为15px？”是的，这是基于维持现况的考量。而“标准”未来将成为预设选择。
“我个人仍是比较倾向让这三个选项维持原本的14、16、20px，让小工具在Vector 2022失效”或许能否详细说明理由？谢谢。--SCP-0000（留言） 2024年3月30日 (六) 13:33 (UTC)[回复]
主要是现在用“阅读无障碍”的“标准”也没遇到什么排版上的问题，另外没那么重要的应该是跨站点的一致性，至于“大字体”小工具在“阅读无障碍”功能预设开启后（在Vector 2022）就不需要了。--冥王欧西里斯（留言） 2024年3月30日 (六) 13:44 (UTC)[回复]
理解。大字体那句是不小心引用的（）。至于跨站点的一致性，这确实是合理的担忧，不过只要本站愿意作出改动，个人认为其他使用中文的 wikis 也会跟进改动。至于中文以外的 wikis，正如您所说其实不太重要。谢谢。--SCP-0000（留言） 2024年3月30日 (六) 14:02 (UTC)[回复]
现在中文站点的字号设定并不完全相同，所以我反而不觉得其他中文站点会跟进本站改“标准”为15px就是XD，毕竟改了反而也是跟原先的排版不同。--冥王欧西里斯（留言） 2024年3月30日 (六) 23:26 (UTC)[回复]
原本选15px是因为当时中文网页字体大小的最佳实践是15px--百無一用是書生 (☎) 2024年3月31日 (日) 12:09 (UTC)[回复]
那就是看现在的最佳实践是不是还是15px了。--冥王欧西里斯（留言） 2024年3月31日 (日) 12:14 (UTC)[回复]
啊，“最佳实践”我在这里是有点反讽的意思的....意思就是别人都这么做，所以这么做，效果上是不是“最佳”则未必，但成本上肯定是“最佳”的--百無一用是書生 (☎) 2024年4月8日 (一) 03:21 (UTC)[回复]
既然此讨论已过一个月多，而本提案已过七天且无合理异议，故现公示七天，如无合理异议即视达成共识及通过。谢谢。--SCP-0000（留言） 2024年4月7日 (日) 16:01 (UTC)[回复]
  • 根本就不是这问题，是这个基金会本身的问题。强迫人换成Vector 2022的皮肤外观不说，还要登入使用者的账号才能选择，跟字体大小可能没什么影响了，字体大小也不是决定条目质量的主要因素，而且一堆多余空白就影响阅读品质。再说，为何不自己用缩放功能调整字体大小就好？真的懒成这样吗？--Z7504非常建议必要时多关注评选（留言） 2024年4月18日 (四) 14:10 (UTC)[回复]
    良好的网站设计不应要求使用者透过缩放功能来调整字体大小，而字体大小确实会影响读者的阅读品质（参见相关研究）。至于预设选项及空白的问题，与本讨论无关，个人便不评论。谢谢。--SCP-0000（留言） 2024年4月18日 (四) 16:13 (UTC)[回复]
    字体大小的确是会影响读者的阅读品质，但哪些读者是真的会管您维基百科要是14px还是15px的大小啊？讲这个几px大小也不是维基百科所有的读者都能一目了然。基金会也没有要发明这个功能啊？为啥不给维基百科本身阅读时能自己决定字体大小的功能建议比较快？电脑有缩放字体功能，手机也有缩放萤幕大小的功能，那字体显示的大小当然是取决自己要不要去决定而已。（独裁）基金会做为一个维基百科全书网页始祖之一，却连这点功能都办不到，那和其他网络百科全书基本差不多功能而已，就（独裁）社群的维基百科功能性而言，没有比较突出。与其讨论字体选择性功能，真的建议直接看看这个（独裁）基金会的意愿吧，（独裁）社群光只在互助客栈这讨论半天是没有屁用的。--Z7504非常建议必要时多关注评选（留言） 2024年4月18日 (四) 17:04 (UTC)[回复]
    相信做过网站开发和应用系统设计工作的，绝不会说出这种不专业的话--百無一用是書生 (☎) 2024年4月19日 (五) 03:29 (UTC)[回复]
既然没有合理且与本提案相关的异议，视为达成共识及通过。个人稍后将建立相关工单。谢谢。--SCP-0000（留言） 2024年4月19日 (五) 07:35 (UTC)[回复]
已建立 phab:T362995。
@SGrabarczuk (WMF)： Hello, we agree that change the "Standard" font size from 16 to 15px in Chinese Wikipedia. More information in this phab ticket. Thanks.--SCP-0000（留言） 2024年4月19日 (五) 16:09 (UTC)[回复]
所以此话题现在可告一段落了？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月10日 (五) 19:58 (UTC)[回复]
我认为没问题。--碟之舞📀💿 2024年5月11日 (六) 01:15 (UTC)[回复]

关于使用 ToolsRedirect 创建的繁简重定向

本主题或以下段落文字，在讨论结束后应存档至MediaWiki talk:Gadget-ToolsRedirect.js、Category talk:有蓝链却未移除内部链接助手模板的页面、Category talk:简繁重定向、Template talk:简繁重定向。

使用ToolsRedirect自动创建的繁简重定向，会被该工具错误地标记为别名重定向，参见：Special:Diff/82229793、Special:Diff/82063339、Special:Diff/82063322、Special:Diff/82034218、Special:Diff/82003931……烦请界管尽快修复此bug，防止挂有错误标记的繁简重定向不断增加。

由于大量编者均习惯以ToolsRedirect快速创建重定向，因此需要修正的繁简重定向恐怕已不可胜数，能否让机器人批量处理使用该工具创建的繁简重定向，将页面中的{{別名重定向}}替换为{{簡繁重定向}}？@Kanashimi--萧漫（留言） 2024年4月12日 (五) 08:22 (UTC)[回复]

一个疑问，这些简繁重定向是必要还是不太必要的。是解决可视化编辑器问题的吗。--YFdyh000（留言） 2024年4月12日 (五) 19:47 (UTC)[回复]
个人感觉别名（包括地区用词、外文名）有必要，繁简必要性不大，条目和模板中可以正常跳转，只是编辑摘要（或者还有什么地方）会显示红链。--Kethyga（留言） 2024年4月13日 (六) 00:22 (UTC)[回复]
若不涉及一简对多繁或异体字问题，繁简重定向应该是不必要的。--萧漫（留言） 2024年4月13日 (六) 01:04 (UTC)[回复]
User:YFdyh000、User:Kethyga、User:萧漫：对我来说，简繁重定向最重要的功能是克服服务器缓存过多、直接逼User:Cewbot清掉被系统忽略、遗忘的伪蓝连，例如我做完Special:PermaLink/82174815不久，机器人就帮我做了这笔清理，不这样做的话，机器人不会清到这些条目机器人很难清到这些条目。英文维基百科那边也是这样，大家可以留意里面有一条“{{ill|Hundred Flowers Award for Best Writing|zh|大众电影百花奖最佳编剧|lt=Best Writing}}”被标示为“The corresponding foreign language page does not exist.”，但中文百科其实有大众电影百花奖最佳编剧条目，只是繁简不同而已，如果有简繁重定向页就不会跳出这个错误。--回廊彼端（留言） 2024年4月14日 (日) 14:19 (UTC)[回复]
伪蓝链是什么效果。Database reports可能该机器人不支持简繁机制，不了解有无别的方案。是否要建简繁重定向似乎多次讨论过，有无结论忘记了。--YFdyh000（留言） 2024年4月14日 (日) 14:54 (UTC)[回复]
User:YFdyh000：伪蓝连只有两种可能，一个是应该功成身退的跨语言链接，另一个是编者写的不正确或与未来建立条目名称不同、导致机器人清不掉的连结，两种最好都不要存在。--回廊彼端（留言） 2024年4月15日 (一) 14:16 (UTC)[回复]
我还没发现本地User:Cewbot/需要修正的跨语言链接中因为繁简而受影响的情形。如果确实有的话，应该可以考虑重新设计机器人。倒是除此之外，繁简重定向确实没有什么作用。--PexEric 💬|📝 2024年5月2日 (四) 09:35 (UTC)[回复]
可能需要修改MediaWiki:Gadget-ToolsRedirect.js的识别方案吧，另外还有非繁简识别成繁简重定向的，比如82561648--Kethyga（留言） 2024年5月10日 (五) 03:13 (UTC)[回复]
本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

InternetArchiveBot故障？

本主题或以下段落文字，在讨论结束后应存档至User talk:InternetArchiveBot。

于Phabricator查看
编号T364136的工单
状态：已解决

这两天突然发现User:InternetArchiveBot无法识别{{Cite web}}、{{Cite news}}等系列模板中已添加的存档，而是直接在模板外添加了{{Wayback}}，导致大量引用来源出现重复的存档链接（如：[12]）；即使Cite系列模板没有存档链接，也不会填进去（如：[13]）。我已在P站提单，暂未得到回复；但刚刚发现机器人在其他站点的工作是正常的（如西语维基百科、英语维基百科）……想请教是否会与本地的一些配置有关？以及我认为有必要将这两天机器人做的编辑全数回退……--Tim Wu（留言） 2024年5月4日 (六) 17:55 (UTC)[回复]

问题持续中，现在还是重复添加{{Wayback}}。InternetArchiveBot的条目修改量也不少，在解决问题之前，能否先禁止这个bot的在zhwiki的运行。--Nostalgiacn（留言） 2024年5月6日 (一) 03:04 (UTC)[回复]
不反对暂时禁止。--Tim Wu（留言） 2024年5月6日 (一) 03:14 (UTC)[回复]
不确定是bug还是只是参数识别问题，因为用iabot界面编辑存档的话，参数名为“archive-date”和“archive-url”，可能是原来的模板参数对不上而无法处理？——Sakamotosan路过围观 | 避免做作，免敬 2024年5月6日 (一) 07:26 (UTC)[回复]
现在有没有横杠都识别不出来。--Tim Wu（留言） 2024年5月6日 (一) 07:31 (UTC)[回复]
像这个更改Special:Diff/82526887，{{Cite web}}的参数就是archive-url和archive-date，但bot还是在模板外加的{{Wayback}}。--𝓧𝓩𝓣𝓓𝓮𝓪𝓷 𝕋𝕒𝕝𝕜  2024年5月6日 (一) 10:05 (UTC)[回复]
刚试了用iabot界面编辑存档，出现了同样问题。连带之前没有存档的也是以{{Wayback}}存档。--S叔 2024年5月6日 (一) 12:48 (UTC)[回复]
虽然但是我觉得应该联系机器人维护者@Cyberpower678、Harej而不是去phab开工单……我觉得该问题是机器人本身的问题与mw没啥关系，机器人也不是基金会人员所有的。--忒有钱 🌊塩水あります🐳（留言） 2024年5月9日 (四) 19:24 (UTC)[回复]
工单也加了Cyberpower678。但如果直接去对方用户讨论页提醒一下，或者先咨询一下是不是出了一些问题，应该会更好。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月10日 (五) 00:23 (UTC)[回复]
是在机器人元维基问题回报页反馈无果后才提单的，虽然两处直到现在都没有更新，很失望。--Tim Wu（留言） 2024年5月10日 (五) 03:37 (UTC)[回复]
建议修复前先禁用吧。另外IABOT工具也是在{{cite}}模板之外添加的存档，不论archive-url是否已经填写。--Kethyga（留言） 2024年5月10日 (五) 03:32 (UTC)[回复]
另外，还有IABotManagementConsole的也是，见 Special:Diff/81922170/82595494、标签：IABotManagementConsole最近更改。--Kethyga（留言） 2024年5月11日 (六) 01:18 (UTC)[回复]
有必要按照Wikipedia:忽略所有规则立刻禁用该机器人，避免受影响范围扩大--Dnaimfz（留言） 2024年5月14日 (二) 12:10 (UTC)[回复]
此机器人的自动作业已停止，但这期间仍有用户通过 IABotManagementConsole 添加存档。--Tim Wu（留言） 2024年5月14日 (二) 13:07 (UTC)[回复]

字词转换问题

本主题或以下段落文字，在讨论结束后应存档至Talk:玛莉·雷诺特。

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

玛莉·雷诺特条目中，所有的“毕业”都会在繁体转换为东野圭吾的小说“毕业 雪月花杀人游戏”。--SingBow（留言） 2024年5月10日 (五) 01:00 (UTC)[回复]

看起来修复了。Template:CGroup/文学对应项没配置好。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月10日 (五) 03:36 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

字词转换问题

本主题或以下段落文字，在讨论结束后应存档至Talk:弊家伙！史太林死咗。

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

斯大林死了没？条目中，赫鲁晓夫的名字“尼基塔”会在繁体转换为电影“霹雳煞”--SingBow（留言） 2024年5月10日 (五) 01:03 (UTC)[回复]

@SingBow 是Module:CGroup/Movie的问题，“La Femme Nikita', 'zh-tw:霹雳煞;zh-cn:尼基塔;zh-hk:堕落花;”，该转换项需要修改，“尼基塔”是常用人名。另外错误字词转换在Wikipedia:字词转换/修复请求。--Kethyga（留言） 2024年5月10日 (五) 03:42 (UTC)[回复]
解决了，电影名组过转，Kethyga在条目上加了一个固定转义。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月10日 (五) 03:42 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

请问技术上如何修正：台湾繁体中文用 “进位” 代替 “进制” 的自动转换？

本技术问题，已张贴于条目【进位制】的讨论区，因修订该条目时，查询其公共转换组
（IT、Electronics、Science），其模板内容并查无强制“进制”字词转换处理，为何会自动转换成“进位”？怎么解决？谢谢！

贴文如下：

进制（carry system）与进位（carry）并不等义！见：乐词网【进位】，但不知道什么原因，维基中文会自动转换！（包括其他条目，例如“十進制”，台湾繁体中文非要显示“十進位”不可）请协助并指导修订技术，谢谢！--Yyfroy（留言） 2024年5月10日 (五) 08:39 (UTC)[回复]

@Yyfroy 在全局转换表中，该转换使得"进制"在中文维基项目上zh-tw都会转换成“進位”。确实过度转换的话，可以提报到Wikipedia:字词转换/修复请求，不过处理速度会就比较久。--Kethyga（留言） 2024年5月10日 (五) 08:59 (UTC)[回复]
谢谢！原来如此！还有这种网站（https://phabricator.wikimedia.org/ ）！Yyfroy（留言） 2024年5月10日 (五) 09:44 (UTC)[回复]
可以看一下Wikipedia:字词转换的说明和流程。--Kethyga（留言） 2024年5月10日 (五) 11:03 (UTC)[回复]
@A2569875 麻烦确认一下，是否应该取消全局转换。--Kethyga（留言） 2024年5月10日 (五) 11:18 (UTC)[回复]

优先体验深色模式（行动版网站、已登入使用者）

大家好，如同去年11月的公告所述，维基媒体基金会网页团队正在开发深色模式（或称夜间模式）。我们现在已为所有维基专案的行动版进阶模式已登入使用者发布了该功能，以进行测试。请别担心，新功能不会造成破坏！（请参阅下文的“已知局限”部分）。在向更广泛的受众发布该功能之前，与您合作对我们来说非常重要。我们优先推出的目标是：

  • 展示我们的早期成果。您越早参与，您的意见就越能在最终版本得到体现
  • 取得有关标记错误、问题和请求的协助
  • 与技术编者合作，调整各种模板和小工具以支援深色模式

请参见专案页面和常见问题页面了解关于此专案基础知识的更多资讯。

初始版本的已知局限

  • 目前，深色模式仅适用于已启用行动版进阶模式的已登入使用者，作为可选功能。
  • 小工具最初可能无法在深色模式下正常工作，并可能需要更新。
  • 我们的首要目标是让深色模式能在条目上使用。特殊页面、讨论页面和其他命名空间尚未针对深色模式更新。我们暂时在一些页面禁用了深色模式。

我们希望您（广大社群）做的是：

如果您有任何疑问——欢迎您向我们提出！此外，请适时考虑将维基媒体专案的深色模式相容性建议的连结加入解释如何在程式码中定义颜色的页面。该相容性建议页面将很快被标记为可翻译页面。我们想强调的是，这些建议可能会不断变化。因此，我们不建议在本地维基专案建立该相容性建议的副本。在某些时候，副本可能会与原始版本有所差异。

我们希望您（模板编者、界面管理员、技术编者）做的是：

当大多数错误得到解决后，我们将能够为桌面和移动设备两方的读者提供深色模式。为了实现这一目标，我们需要与您一起合作共同回报和解决问题。

  1. 若要启用深色模式，请使用行动版网站并前往选单的设定部分，选择启用进阶模式（若尚未启用）。然后，将色彩设为深色。（稍后，我们将使该设定自动使用装置主题）。
  2. 接着，前往不同的条目寻找问题：
    • 如果您发现模板有问题但不知道如何修复它
      1. 前往建议页面寻找相关范例
      2. 如果没有相关范例可用或对修复方法有疑问，联络我们
    • 如果你想为多个模板在深色模式下除错
      1. 请前往https://night-mode-checker.wmcloud.org/找出需要修复的模板。该工具会标示出阅读量最高的100篇条目。
      2. 前往建议页面寻找相关范例
      3. 如果没有相关范例可用或对修复方法有疑问，联络我们
    • 如果您想找出前100篇条目以外的问题
      1. 安装WCAG色彩对比浏览器扩充功能（Chrome、Firefox）并造访一些条目。用它来找出问题
      2. 前往建议页面寻找相关范例
      3. 如果没有相关范例可用或对修复方法有疑问，联络我们
    • 如果您有与模板无关的深色模式错误报告
      1. 将您看到的画面截图下来
      2. 联络我们。如果可以，请注明您的浏览器版本和操作系统版本

谢谢您。我们期待您的意见和评论！--SGrabarczuk (WMF)（留言） 2024年5月10日 (五) 14:42 (UTC)[回复]

北平市、重庆市 (中华民国)等民国大陆时期直辖市条目地图定位偏差问题

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Irralpaca（留言） 2024年5月10日 (五) 23:51 (UTC)。[回复]

互助客栈
北平市

互助客栈
重庆市

Template:Lang 模板语言代码检查

本主题或以下段落文字，在讨论结束后应存档至Template talk:Lang。

目前语言标示模板{{Lang}}，未对语言代码参数进行检查，填写任何值都不无提示，见Wikipedia:沙盒 (82616832)，英维则会检查语言代码（包括ISO 639和IETF语言标签），见en:Wikipedia:Sandbox (1223490529)--Kethyga（留言） 2024年5月12日 (日) 14:11 (UTC)[回复]

纠正一下说法， 目前的Template:Lang会提示jp/jap（日语）、gr（希腊语）、kp（朝韩语）、po（波兰语）、sp（西班牙语）、cz（捷克语）、kz（哈萨克语）、dk（丹麦语）的错误语言代码，但是其他的无提示，比如输入一个不存在的拉丁语代码，{{lang|latin|latin}}。--Kethyga（留言） 2024年5月15日 (三) 06:50 (UTC)[回复]

:在巴拉耶沃、佐兰·金吉奇，语言标签"sr-Latn"未识别成塞尔维亚语。（lang|sr-Latn临时通过Template:ISO 639 name sr-Latn识别塞尔维亚语）Template:Kmr中的km-Latn未识别成高棉语--Kethyga（留言） 2024年5月13日 (一) 01:26 (UTC)[回复]

在维克托·阿斯塔菲耶夫 (76094597)，lang中语言代码填入了不存在的“tu”，只会加入Category:含有非中文内容的条目，但并未提示编辑哪里出现错误。--Kethyga（留言） 2024年5月14日 (二) 01:50 (UTC)[回复]
{{lang}}对于语言代码的检查似乎是通过ISO 639语言代码系列模板检测的，但是{{lang-xx}}系列模板是通过Module:Lang/data模块进行检测的，使得目前需要同时维护Module:Lang/data和ISO 639语言代码系列模板。ISO 639语言代码系列模板可以作为特殊语言的补充，但是维护两份有些多余了。--Kethyga（留言） 2024年5月15日 (三) 05:15 (UTC)[回复]
另外，Category:语言标示模板分类下的各种模板也是多余，既然都需要记忆语言代码，只用{{Language icon}}或{{in lang}}就可以。--Kethyga（留言） 2024年5月15日 (三) 05:20 (UTC)[回复]
另外，ISO 639 name或{{lang}}只识别或生成小写的latn，比如在山口站 (萨哈林州)中生成的源码<span lang="ru-latn">Pereval</span>，W3C好像是要求“Latn”，[14]。--Kethyga（留言） 2024年5月15日 (三) 05:47 (UTC)[回复]
需要改善的地方，模板{{lang}}可以增加鼠标悬停语种提示功能，有时不需要明确表示“XX语：”。--Kethyga（留言） 2024年5月17日 (五) 02:29 (UTC)[回复]

MarkRights.js的修改：自动获取用户组、显示全域用户组

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:在编辑记录中标示使用者权限。

此前的讨论的后续。根据meta的版本做了js和css，移除了对其它维基的支持。后续新增用户组时仅需增加相应的css，用户可以自行覆盖预设颜色和文字，或在css没更新前自定义文字。不过自动获取的用户组以群组名称字母顺序排列，或许不合部分用户期望。测试了一下运作正常，大家觉得如何？——暁月凛奈 (留言) 2024年5月12日 (日) 16:36 (UTC)[回复]

ping一下印象里相关的用户@Shizhao、Ericliu1912、Xiplus、WhitePhosphorus。——暁月凛奈 (留言) 2024年5月13日 (一) 11:10 (UTC)[回复]

闽越地图

请问互助客栈的有成员能否抽空时间帮忙做一张闽越国地图呢？是像这样子样式的：File:Nanyue.svg地图。这是可以用的对照原图：File:闽越地图.png。文件名的话就可以直接写作File:Minyue.svg就可以了。如果可以帮忙的话那就非常感谢阁下！--桜花雪・为了侬家各侬其闽越共民族 2024年5月13日 (一) 07:26 (UTC)[回复]

讨论页重定向问题

我希望创建WT:NOT并重定向至WT:维基百科不是什么以修复编辑摘要中的红链，但是从预览没有正确重定向。我在我的用户页创建了测试页，发现讨论页无法通过这种方法正确重定向，请求帮助。--Python6345（留言） 2024年5月13日 (一) 16:06 (UTC)[回复]

您的测试页的重定向语法有误。#REDIRECT [[WT:维基百科不是什么]]--YFdyh000（留言） 2024年5月13日 (一) 16:23 (UTC)[回复]

2024年第20期技术新闻

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

最近更改

  • 维基文库有一个特殊页面，会列出没有扫描件的作品页面列表。现在您可以使用新的魔术字__EXPECTWITHOUTSCANS__使该列表排除特定页面（例如，作品的版本列表或译文）。 [15]
  • 现在，如果您在用户参数设置启用“在不重新加载页面的情况下显示预览”，模板页面功能“预览使用本模板的页面”也无需重新加载页面。 [16]
  • Kartographer地图现在可以通过alt=属性指定替代文本。其用法与图像和图库语法中的alt=属性相同。此功能的例外是维基导游等维基站点，这些站点的微型地图是交互式的。 [17]
  • “新的编辑审核过滤器”功能的旧导览已被移除。该导览创建于2017年，旨在向拥有旧账号的用户展示界面的变化，现在大多数目标用户已得知这一点。 [18]

本周更改

  • MediaWiki的新版本将于5月14日部署至测试维基及MediaWiki.org，于5月15日部署至非维基百科wiki及部分维基百科，并于5月16日部署至所有站点（参见日程表）。 [19][20]
  • Special:搜索结果页面现在使用CSS flex属性而非表格，以进一步落实无障碍。如果您有用于调整搜索结果的小工具或脚本，请更新该脚本以处理新的HTML结构。 [21]

未来更改

  • 在Vector 2022皮肤中，首页将会以全屏宽度显示（如同特殊页面）。此举的目标是确保每行容纳的字符数足够多。这与即将发生的Vector 2022排版设计更改有关。了解更多。 [22]
  • pagelinks数据库表的两个字段（pl_namespace和pl_title）即将被删除。使用者必须改用linktarget表格的两个字段（lt_namespace和lt_title）。在现有的SQL查询中：
    1. 将ON语句中的JOIN pagelinks替换为JOIN linktarget，将pl_替换为lt_
    2. 在其下方添加JOIN pagelinks ON lt_id = pl_target_id

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2024年5月13日 (一) 23:57 (UTC)[回复]

关于部分日本城镇页面出现的Authority control模板

因有编辑员说我在日本城镇页面产生难以理解(对方说法)的authority源代码，而稍早我已回复他说:根据我调到的纪录，上述日本城镇出现的源代码可能为cewbot先前的编辑导致，如https://zh.wikipedia.org/w/index.php?title=%E4%B8%80%E6%88%B6%E7%94%BA&diff=prev&oldid=36585938

https://zh.wikipedia.org/w/index.php?title=%E8%97%A4%E9%87%8C%E7%94%BA&diff=prev&oldid=36585364。

因此想请问大家是否知道，为什么机器人管理员会附上那串源代码?又是否应将其删除?谢谢--雪雨73（留言） 2024年5月15日 (三) 05:38 (UTC)[回复]

目前未见页面异常，你们是看到模板故障了？--YFdyh000（留言） 2024年5月15日 (三) 06:02 (UTC)[回复]
@YFdyh000主要是rastinition说authority control是无法理解的编码
@Kethyga因为我不确定这是模板还是源代码的问题，只好以模板问题的叙述形容。至于您提供的角柱我会用用看，感谢您。--雪雨73（留言） 2024年5月15日 (三) 06:26 (UTC)[回复]
@雪雨73 在你的讨论页，关于藤里町条目，似乎Rastinition并未说是{{Authority control}}模板的问题，问题可能是加入了章节“参考文献”（== 參考文獻 ==），但是未在该章节加入"<references />"或“{{reflist}}”（使用说明，见Help:脚注），导致引用的内容都出现在“{{秋田縣}}{{Authority control}}”下方。至于本来存在的{{Authority control}}建议维持不动。--Kethyga（留言） 2024年5月15日 (三) 06:11 (UTC)[回复]
@Rastinition 问题我已向两位编辑员了解，会在接下来进行修改，因为先前编辑是用视觉化编辑，因此并无察觉--雪雨73（留言） 2024年5月15日 (三) 06:28 (UTC)[回复]
先弄清对方在讲什么。--YFdyh000（留言） 2024年5月15日 (三) 06:38 (UTC)[回复]
@YFdyh000好的，现在我有了解对方提出的问题了，正在修改，不好意思麻烦您回复，感谢。--雪雨73（留言） 2024年5月15日 (三) 06:41 (UTC)[回复]
@YFdyh000因为rastinition是说: 除了我主动干涉的一户町，因为你罐头处理的页面多有类似问题，抽检藤里町页面源代码后给予提问，请你回答你在页面产生下列源代码的意图是什么，如果你经过这个提问意识到你的问题成因，请自行修== 参考文献 =={{秋田縣}}{{Authority control}}
我一时也看不懂只好上来询问(⊙_⊙;)，现在懂了。--雪雨73（留言） 2024年5月15日 (三) 06:52 (UTC)[回复]
然后考虑到有管理员可能会认为我在刷编辑次数，我有在最新的编辑注解理由，希望巡视使用者贡献的人能看到。--雪雨73（留言） 2024年5月15日 (三) 06:54 (UTC)[回复]

Category:包含规范控制信息的维基百科条目

本主题或以下段落文字，在讨论结束后应存档至Module talk:Authority control。

Category:包含规范控制信息的维基百科条目，该分类英维对应en:Category:Articles with authority control information，即Category:包含规范控制信息的条目，减少“维基百科”4个字，对于规范控制信息较多的条目能节省一些空间，且感觉这几个字有些多余。即将Module:Authority control/config#L-14语句cat = '包含%s标识符的维基百科条目',中的“维基百科”4个字删除。不过有170个分类需要移动。@Shizhao：--Kethyga（留言） 2024年5月15日 (三) 07:23 (UTC)[回复]

因为最早就是Category:包含规范控制信息的维基百科条目，之前修Module:Authority control的时候就继续沿用了。不改就是因为要移动170个分类....实在不想耗费这个精力，要是有其他人愿意处理，乐见其成！--百無一用是書生 (☎) 2024年5月15日 (三) 08:06 (UTC)[回复]
faultwithidcat = '包含错误规范控制信息的维基百科条目 (%s)',也是沿用的以前的命名方式，甚至为此还改了Module:Authority control中的相关代码，原因也是嫌麻烦，不想移动上百个分类...--百無一用是書生 (☎) 2024年5月15日 (三) 08:09 (UTC)[回复]
@Ericliu1912 好像是有Massmove用来批量移动？--Kethyga（留言） 2024年5月15日 (三) 08:22 (UTC)[回复]
如果没收益，我也倾向不动若干页面……如果要省字数，“条目包含规范控制信息”怎么样，不确定命名统一性等情况。--YFdyh000（留言） 2024年5月15日 (三) 08:40 (UTC)[回复]
英维可能是在2021年集中移动的，见en:Template talk:Authority control (Remove_"Wikipedia"_from_"Wikipedia_articles_with_EMU_identifiers"-type_categories?)。
“条目包含规范控制信息”，没觉得更好，倾向原表达方式。--Kethyga（留言） 2024年5月15日 (三) 10:24 (UTC)[回复]
确实，没有找到“条目包含”前例，“条目有”1例，“条目使用”2例，“的条目”则很多。--YFdyh000（留言） 2024年5月15日 (三) 10:39 (UTC)[回复]
更好的的表述可能是“含有规范控制信息的条目”--百無一用是書生 (☎) 2024年5月15日 (三) 12:11 (UTC)[回复]

限制页面宽度功能失效了？

--Dnaimfz（留言） 2024年5月16日 (四) 06:10 (UTC)[回复]

上面技术新闻有写。——暁月凛奈 (留言) 2024年5月16日 (四) 06:55 (UTC)[回复]

Template:Infobox building

本主题或以下段落文字，在讨论结束后应存档至Template talk:Infobox building。

模板{{Infobox building}}的native_name_lang参数问题，如果native_name_lang参数未填写的话，会默认其语言代码为"{{{native_name_lang}}}"，而不是像{{Infobox settlement}}一样将其忽略，见布兰城堡信息框。另外布兰城堡中使用{{native_name_list}}模板的话，其中后缀语言在简体状态下显示繁体，但是native_name_list模板在马焦雷湖条目中简体环境下正常显示简体语言名称。--Kethyga（留言） 2024年5月17日 (五) 04:48 (UTC)[回复]

Sports results里跨语言链接的显示问题

本主题或以下段落文字，在讨论结束后应存档至Module talk:Sports results。

今天在修改2024年中国足球甲级联赛的时候发现Module:Sports results里的球队名字如果用跨语言链接模板比如{{link-en}}，就会把表格顶部球队名的悬浮提示框里的外文条目名字变成顶部的那个名字。

比如像这个表格：

主队 ＼ 客队 		队1（英语：队1） 队2（英语：队2） 队3（英语：队3）
队伍1（英语：Team 1） — 1–0 2–0
第二只队伍（英语：Team 2） 3–0 — 4–0
队伍3（英语：Team 3） 5–0 6–0 —
最后更新：unknown。资料来源：[来源请求]
蓝色：主队取胜；黄色：战平；红色：客队取胜。
对于{{le|第一只队伍|Team 1|队伍1}}，表格顶部的跨语言链接的鼠标悬浮提示框里写的就成了

条目“第一只队伍”尚未创建，可参考英语维基百科的对应页面：队1。

但像最左侧的一列显示的正常的的跨语言链接应该是显示

条目“第一只队伍”尚未创建，可参考英语维基百科的对应页面：Team 1。

使用{{ilh}}系列和{{tsl}}都会有一样的问题，不过外文链接都还是正常的。不知道这个是有意设计的还是在替换球队名字的时候也把外文维基百科的链接名字也替换了。--𝓧𝓩𝓣𝓓𝓮𝓪𝓷 𝕋𝕒𝕝𝕜  2024年5月17日 (五) 08:31 (UTC)[回复]

求助

重要度与质量评级的交叉筛选

本主题全部或部分段落文字，已移动至Template talk:WikiProject Maths。执行人：Jimmy-bot（留言） 2024年5月17日 (五) 16:14 (UTC)。[回复]

想要为学校创建一个维基百科词条，总是不能通过审核，请问哪位大神有经验啊？

想要为学校创建一个维基百科词条，总是不能通过审核，请问哪位大神有经验啊？我的微信号是：chongchongAI3，谢谢！--Zhixuan.Gong（留言） 2024年5月3日 (五) 15:51 (UTC)[回复]

请说条目名，别人方便看原因。--YFdyh000（留言） 2024年5月3日 (五) 15:54 (UTC)[回复]
我想问一句，请问维基百科有审核吗？另外，维基百科中的主命名空间的页面叫做“条目”而不是“词条”，谢谢。--Gongxiang01（留言） 2024年5月11日 (六) 09:53 (UTC)[回复]
如果途径WP:AFC是有的。WP:词条。--YFdyh000（留言） 2024年5月11日 (六) 09:57 (UTC)[回复]
没看到你的编辑历史，页面是被删除了？--桐生ここ★[讨论] 2024年5月11日 (六) 11:48 (UTC)[回复]
编辑次数1。可能在别的账号下，或者被拦截。--YFdyh000（留言） 2024年5月11日 (六) 11:52 (UTC)[回复]

使用Template:EstcatCountry建立公元前年数分类出现错误

本主题全部或部分段落文字，已移动至Template talk:EstcatCountry。执行人：Jimmy-bot（留言） 2024年5月18日 (六) 08:14 (UTC)。[回复]

这理由：公开在中国的录音是否违反了美国法律，从而违反了在世人物，合理吗？另外，想请教下有必要再次请求傀儡调查

本主题全部或部分段落文字，已移动至Talk:陈牧驰。执行人：Jimmy-bot（留言） 2024年5月18日 (六) 08:14 (UTC)。[回复]

请求协助上传档案 2024-05-06 08:05

本主题或以下段落文字，在讨论结束后应存档至Talk:四分卫乐团。

我想要上传的图片来源是<https://media.zenfs.com/ko/mirrormedia.mg/2aa617912cb01c39224b0efd9a02c010>，想要使用在四分卫的<资讯框>。 --刘子易（留言） 2024年5月6日 (一) 08:05 (UTC)[回复]

驳回 驳回，非自由图片，且不符合理使用要求。--伞木 霙留言 2024年5月12日 (日) 03:18 (UTC)[回复]

请求协助上传档案 2024-05-06 11:00

本主题或以下段落文字，在讨论结束后应存档至Talk:魏德圣。

我想要上传的图片来源是<https://www.epochtimes.com/b5/17/4/17/n9046287.htm>，想要使用在魏德圣导演的<个人照上>。 --Heart630412（留言） 2024年5月6日 (一) 11:00 (UTC)[回复]

驳回 驳回，非自由图片，且不符合理使用要求。--伞木 霙留言 2024年5月12日 (日) 03:18 (UTC)[回复]

请求协助上传档案 2024-05-06 12:32

本主题或以下段落文字，在讨论结束后应存档至Talk:鼠头鸭脖事件。

我想要上传的图片来源是<https://cbu01.alicdn.com/img/ibank/O1CN01hd6MQX1tDaxxwob4w_!!3859715868-0-cib.jpg>，想要使用在鼠头鸭脖事件的<后续段落>。 --IFIF1727（留言） 2024年5月6日 (一) 12:32 (UTC)[回复]

驳回 驳回，图片来源、版权状态不明。--伞木 霙留言 2024年5月12日 (日) 03:18 (UTC)[回复]

页面破坏问题

本主题或以下段落文字，在讨论结束后应存档至Talk:歌手2024。

歌手2024之IP使用者220.138.126.224之编辑是否属于页面破坏呢？是否应申请页面临时保护？--Tifffanyyy（留言） 2024年5月8日 (三) 09:28 (UTC)[回复]

Wikipedia:请求保护页面有人请求过。原创研究。“排名预测”我无语。--YFdyh000（留言） 2024年5月8日 (三) 09:49 (UTC)[回复]
原来有人请求过了！那现在这样是只能等管理员的结果吗？还是我应该再去撤销呢，感觉会引发编辑战耶。（不过好像已经是了）Tifffanyyy（留言） 2024年5月8日 (三) 10:28 (UTC)[回复]
也可送WP:VIP等布告板催处理？--YFdyh000（留言） 2024年5月8日 (三) 10:36 (UTC)[回复]
以前没有举报过人，我来研究看看！Tifffanyyy（留言） 2024年5月8日 (三) 10:53 (UTC)[回复]
阁下您好，IP使用者220.138.126.192似乎是IP使用者220.138.126.224更换IP后，重复于歌手2024进行原创研究与无可靠来源之编辑，如此有何解？（目前针对IP使用者220.138.126.224之举报以及对歌手2024之申请页面保护尚无回应。）Tifffanyyy（留言） 2024年5月9日 (四) 02:30 (UTC)[回复]

关于WP:页面分类

本主题或以下段落文字，在讨论结束后应存档至Talk:抖音。

请教各位编者，抖音被划入分类:被俄罗斯封锁的网站和分类:美国网络审查这两个涉及他国法律权力的分类，是否违反维基百科关于页面分类的中立方针？（“分类条目时一定要注意Wikipedia:中立的观点。除非显而易见而且没有争议（例如张国荣一定是香港人），不然不要对条目归类。请您宁可先到分类的讨论页提出问题，也不要贸然分类。”）即使美国对TikTok实施网络审查被字节跳动认定其违反美国宪法，请问这样分类是否合规？--■■■■（留言） 2024年5月8日 (三) 10:59 (UTC)[回复]

“被字节跳动认定其违反美国宪法”应该不影响“美国网络审查”这个分类，只要美国确实做出审查要求且引发关注。“被俄罗斯封锁的网站”疑似不当，因为目前是TikTok主动因法律原因暂停服务。网站主动对特定地区暂停服务是常见的，包括OpenAI、雅虎、领英等。--YFdyh000（留言） 2024年5月8日 (三) 12:26 (UTC)[回复]

请求协助上传档案 2024-05-08 13:24

本主题或以下段落文字，在讨论结束后应存档至Talk:天城莎莉。

我想要上传的图片来源是<https://twitter.com/sally_amaki/status/1786382524434047430/photo/1>，想要使用在天城莎莉的<个人照片(因应本人想跟换照片)>。 --Angelagain（留言） 2024年5月8日 (三) 13:24 (UTC)[回复]

驳回 驳回，非自由图片，且不符合理使用要求。--伞木 霙留言 2024年5月12日 (日) 03:18 (UTC)[回复]
我更换了另一张维基共享的图片。不过这张是新用户うえし在2024年5月7日上传的，也是他唯一一张图片，上传后在日维条目使用。时机有点微妙。
题外话，原本的照片真的拍得很差。--Nostalgiacn（留言） 2024年5月12日 (日) 09:31 (UTC)[回复]

Libera.Chat IRC 无法使用

我在使用IRC时，发现有错误：

Closing Link: [我的IP地址] (SASL authentication to a NickServ account with a verified email address is required to connect from your current network. Please see https://libera.chat/guides/sasl for configuration assistance.)

这是怎么回事啊？能不能换成freenode啊？--Gongxiang01（留言） 2024年5月8日 (三) 15:15 (UTC)[回复]

你的IP段被限制匿名发言了（猜测因为有人发垃圾信息）。需要先在Libera Chat注册账户登录后才能发言。可以参考它给的帮助链接。--碟之舞📀💿 2024年5月8日 (三) 15:57 (UTC)[回复]
我都没法进入聊天室我怎么能注册啊？NickServ我有个freenode的账号注册了。--Gongxiang01（留言） 2024年5月8日 (三) 17:44 (UTC)[回复]
换ip注册。--Miyakoo（留言） 2024年5月8日 (三) 18:16 (UTC)[回复]
换IP直接不显示了，一直加载卡住了。--Gongxiang01（留言） 2024年5月10日 (五) 16:52 (UTC)[回复]
唯有只能换其他 IP，或者关掉 VPN 直连 IRC（基于隐私理由不建议）。再不然使用 Telegram 或者 Discord。谢谢。--SCP-0000（留言） 2024年5月10日 (五) 17:14 (UTC)[回复]
可以注册后再用VPN。--桐生ここ★[讨论] 2024年5月10日 (五) 21:58 (UTC)[回复]
以前是用这个，后来Freenode被篡夺了所有权，所以Freenode原来的员工建立Libera Chat，不建议继续使用Freenode，因为该现在它的实际控制者的行为令人费解，他称Freenode是“朝鲜帝国”的数字领土。--桐生ここ★[讨论] 2024年5月9日 (四) 11:38 (UTC)[回复]

使用模板{{模板:血清素受體調節劑}}碰到问题

本主题或以下段落文字，在讨论结束后应存档至Template talk:血清素受体调节剂。

在沙盒中显示的讯息是#invoke:navbox，不晓得是什么问题。谢谢。--ThomasYehYeh（留言） 2024年5月9日 (四) 01:03 (UTC)[回复]

隐藏分类：​引用模板后大小超过限制的页面。该模板的绿链过多导致的。--YFdyh000（留言） 2024年5月9日 (四) 01:23 (UTC)[回复]
使用单个模板不会出现错误，但阁下的沙盒里同时出现了上述模板和{{肾上腺素受体调节剂}}。这俩模板都超多绿链接，全部展开到一个页面后就会出错。不用在意，等绿链接慢慢都转成蓝链接后就会好了。--微肿头龙（留言） 2024年5月9日 (四) 07:47 (UTC)[回复]
收到，谢谢。我觉得有关药物的模板中的许多确实是有超多的绿色连结。将来有人改进，或许问题就能解决吧。--ThomasYehYeh（留言） 2024年5月11日 (六) 09:50 (UTC)[回复]

请求协助上传档案 2024-05-10 00:59

本主题或以下段落文字，在讨论结束后应存档至Talk:时代巡回演唱会。

我想要上传的图片来源是[25]，想要使用在时代巡回演唱会的<资讯框>中。--99.209.12.195（留言） 2024年5月10日 (五) 00:59 (UTC)[回复]

驳回 驳回，无效的来源链接。--伞木 霙留言 2024年5月12日 (日) 03:18 (UTC)[回复]

请求协助上传档案 2024-05-10 02:04

本主题或以下段落文字，在讨论结束后应存档至Talk:澳门旅游大学。

我想要上传的图片来源是<从某个网址下载，https://www.utm.edu.mo/about-utm/general-information>，想要使用在[[26]]的<资讯框内的logo>。 --UTM Public relations（留言） 2024年5月10日 (五) 02:04 (UTC)[回复]

图片网址应为:https://www.utm.edu.mo/images/default-source/default-album/utm-horizontal-vertical-logos_full-color-version-02.tmb-thumb200.png?sfvrsn=bdd5c3f5_1
谢谢!--UTM Public relations（留言） 2024年5月10日 (五) 02:06 (UTC)[回复]
驳回 驳回，已有更高质量矢量图。--伞木 霙留言 2024年5月12日 (日) 03:18 (UTC)[回复]

请求协助上传档案 2024-05-11 13:49

本主题或以下段落文字，在讨论结束后应存档至Talk:沈斌。

我想要上传的图片来源是<https://saltandlighttv.org/chinese/wp-content/uploads/2023/04/%E6%B2%88%E6%96%8C%E4%B8%BB%E6%95%99%E7%9A%84%E7%89%A7%E5%BE%BD-735x1000.jpeg>，想要使用替换沈斌的<牧徽>。 --Ttcath（留言） 2024年5月11日 (六) 13:49 (UTC)[回复]

驳回 驳回，已有更高质量矢量图。--伞木 霙留言 2024年5月12日 (日) 03:18 (UTC)[回复]

无法编辑页面

我想要建立一个新条目，但收到了以下的警示

本页已被禁止建立和编辑，只有管理员可以取消此建立限制。因为标题“User:Twylaaa/悬壶医院”和本地或全域黑名单 .*[医醫]院.* <autoconfirmed>配合。这通常是为了防止破坏性的编辑。

该如何处理?--Twylaaa（留言） 2024年5月12日 (日) 15:17 (UTC)[回复]

您可以先用其他标题创建该草稿。--YFdyh000（留言） 2024年5月12日 (日) 15:36 (UTC)[回复]

权威控制模板没有显示

我想给靖康稗史条目加上权威控制的项目，可是模板不显示。大概摸索到是要在Wikidata添加项目，而不是编辑条目本身，可是真的只能在站外一个一个搜寻有没有相关项目吗？因为我试着用中英文搜几个数据库都找不到，究竟有没有比较便利的办法，让权威控制这个模板可以出现啊。——George6VI（留言） 2024年5月13日 (一) 01:47 (UTC)[回复]

没有就是没有....--百無一用是書生 (☎) 2024年5月13日 (一) 02:55 (UTC)[回复]
这东西只能人工添加啊，而且如果没有人建立权威记录，你当然就查不到了。--世界解放者（留言） 2024年5月16日 (四) 02:58 (UTC)[回复]
{{Authority control}}通常在人名上用得比较多，作品上比较少，且靖康稗史相对也比较偏的话题，即使在权威控制这一条目上也只有一个标识符。--Kethyga（留言） 2024年5月16日 (四) 03:40 (UTC)[回复]

请问正在等待审核的草稿

请问正在等待审核的草稿，有能加速审核完成的办法吗 https://zh.wikipedia.org/wiki/Category:%E6%AD%A3%E5%9C%A8%E7%AD%89%E5%BE%85%E5%AF%A9%E6%A0%B8%E7%9A%84%E8%8D%89%E7%A8%BF User:Taskonmywe/谢智博 https://zh.wikipedia.org/wiki/User:Taskonmywe/%E8%AC%9D%E6%99%BA%E5%8D%9A 这篇，能帮忙先审核吗，谢谢--Taskonmywe（留言） 2024年5月13日 (一) 03:57 (UTC)[回复]

闽越地图

请问互助客栈的有成员能否抽空时间帮忙做一张闽越国地图呢？是像这样子样式的：File:Nanyue.svg地图。这是可以用的对照原图：File:闽越地图.png。文件名的话就可以直接写作File:Minyue.svg就可以了。如果可以帮忙的话那就非常感谢阁下！--桜花雪・为了侬家各侬其闽越共民族 2024年5月13日 (一) 07:25 (UTC)[回复]

维基百科图书馆的登陆凭证

前几天本人刚拿到维基百科图书馆查阅书籍的授权，结果昨日在检索图书时突然显示无法确认我的登陆凭证，向遇到过相似之情况的编辑求助。--Yankees from Canada（留言） 2024年5月13日 (一) 14:57 (UTC)[回复]

以前能正常使用，近几日尝试时也是搜索会遇到“我们无法验证您的登录凭证”。--YFdyh000（留言） 2024年5月13日 (一) 15:00 (UTC)[回复]
所以说是不是要向EBSCO那边反馈一下啊 ﾍ(;´Д｀ﾍ)，不然的话图书馆用起来还是挺受限的。--Yankees from Canada（留言） 2024年5月13日 (一) 15:05 (UTC)[回复]

请问有没有相关文献可以查到郑经时期明郑在台湾的最大势力范围地图

想画一张明郑最大势力范围图，苦于没有合适的底图可以参照。--Perinbaba（留言） 2024年5月15日 (三) 02:11 (UTC)[回复]

合并页面

根据维基百科:页面存废讨论/记录/2024/04/28，九二共识 (中华人民共和国)已获得共识并入九二共识，可是我不知道要怎么合并。前者篇幅较长，我也不敢直接清空。还请有经验的编者帮助。--微肿头龙（留言） 2024年5月15日 (三) 02:36 (UTC)[回复]

请求协助上传档案 2024-05-15 10:09

我想要上传的图片来源是<从某个网址下载，https://www.sppm.tsinghua.edu.cn/info/1198/7489.htm / >，想要使用在Chen Ling（如果条目还不存在，请先建立条目再请求上传文件）的<Infobox person段的image部分>。 --MaxinekimSim（留言） 2024年5月15日 (三) 10:09 (UTC)[回复]

未完成：条目不存在。--伞木 霙留言 2024年5月17日 (五) 05:27 (UTC)[回复]

请求协助上传档案 2024-05-16 06:52

我想要上传的图片来源是<https://lh5.googleusercontent.com/mTXD662CknLLgeBEQt_-XHIcGwQmlR4sLj9MUaIXVpolE62mxZU6LVDclHs_pAPQKqVcfmbxwo58MnZzNhpRdhlkSlxjW1zdy0XAnR51bzQt3RIBgU6ptOcc69H2yQBnjQ=w1280>，想要使用在谢昌卫的<Infobox officeholder/图像>。 --Zhu19970313（留言） 2024年5月16日 (四) 06:52 (UTC)[回复]

未完成：条目不存在。--伞木 霙留言 2024年5月17日 (五) 05:27 (UTC)[回复]

请求协助上传档案 2024-05-17 02:59

本主题或以下段落文字，在讨论结束后应存档至Talk:伊春西站。

我想要上传的图片来源是<由中国政府部门公布的在建铁路站场示意图https://img2.imgtp.com/2024/05/17/Mszq9bNM.jpg>，想要使用在伊春西站的示意图中添加>。 --Liujitong（留言） 2024年5月17日 (五) 02:59 (UTC)[回复]

未完成：不属于自由文件，且作者、来源不明。--伞木 霙留言 2024年5月17日 (五) 05:27 (UTC)[回复]

请求协助上传档案 2024-05-17 04:46

本主题或以下段落文字，在讨论结束后应存档至Talk:中国联合航空。

我想要上传的图片来源是[27]，想要使用替换中国联合航空的资讯框中所使用的图片（原信息框中的中国联合航空标识已经于2024年1月17日停用并替换为图片来源中新标识）。--2001:1970:57A3:D100:0:0:0:D4D7（留言） 2024年5月17日 (五) 04:46 (UTC)[回复]

补充：由于我刚刚发现不知道是什么故障，图片来源的链接如果直接点击会错误显示该图片的png版本，因此各位大神在下载该矢量图标识前可能需要先复制链接然后单独在一个新标签页打开才可以正常获取到该图片的矢量图版本，谢谢。--2001:1970:57A3:D100:0:0:0:D4D7（留言） 2024年5月17日 (五) 04:50 (UTC)[回复]
完成：已处理。--伞木 霙留言 2024年5月17日 (五) 05:27 (UTC)[回复]

编辑文件信息时报错

我无法编辑中文维基百科本地的文件信息，每次提交编辑时都会报错：
无法获取Parsoid HTML：No downgrade possible from schema version 0.0.0 to 2.8.0.--YuCheinSYQ留言 2024年5月18日 (六) 02:07 (UTC)[回复]


条目探讨

其他

没有主题的页面如何评级

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:通用评级。

已解决：
因Wikipedia:通用评级已通过，故没有主题的页面已可透过通用评级来进行评级，故此问题已解决-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月5日 (二) 09:31 (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)[回复]
模板、分类、甚至是档案也是需要评级的项目，算上去真的跟异端没两样。而挂上专题模板呈现的未评级状态能算评级吗。 --窝法乙烷 儿法梦碎 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)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

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

本主题或以下段落文字，在讨论结束后应存档至Template talk:WikiProject banner shell、Template talk:WPBannerMeta。

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

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

@A2569875，附知。--MilkyDefer 2023年12月8日 (五) 09:03 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第一阶段：修改WikiProject banner shell

已修改：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
工程量挺大，就看谁愿意改了。（几年前可能我有兴趣，现在我就精神上支持了）--洛普利宁 2023年12月8日 (五) 14:53 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第二阶段：修改WPBannerMeta

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

@Willy1018：提到了一个很有意义的问题。如果上方的变更套用了的话，只有“表面上”给了页面通用评级，而实际上的通用评级在各个专题中并没有达成“继承评级”的效果。这是因为评级模板预设不会知道他外面包着{{WikiProject banner shell}}模板，因此，如果要让每个评级模板都能读到通用评级，需要再一个编辑请求。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月24日 (日) 05:15 (UTC)[回复]

预计的修改方案以及其布署连结（记得填写讨论通过的diff和客栈PermaLink版本号）。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月3日 (三) 05:00 (UTC)[回复]

本主题或以下段落文字移动自Template_talk:WPBannerMeta#编辑请求_2024-01-08（固定链接），新留言请置于框外。执行人：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月9日 (二) 13:21 (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)[回复]
@Kanashimi：考虑到日后长期维护需求，我倾向请您以英文版本为基础来更新相关模板。是否能够确认有什么模板需要更新（或在互助客栈列出之类）？不过在此过渡期间，若技术上没有问题，是可以斟酌先批准既有之编辑请求。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月8日 (一) 12:18 (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)[回复]
@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)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第三阶段：完善制度

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

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

公示已逾七日，公示期已过，期内无合理异议，因此提案通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月29日 (一) 03:28 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

临时动议：关于基础条目的额外提议

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:基础条目。

已通过：
基础条目并入{{WPBS}}已经通过；{{WikiProject Biography}}参数还在讨论中。先行布署已通过的《将{{Vital article}}并入{{WPBS}}的|vital=参数》案。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
  • 似乎已有共识，跟随enwiki改版之后会由机器人自动完成：对各种专题横幅不再个别指定 class，而是统一置于{{WPBS}}。
  • 跟随enwiki改版之后会由机器人自动完成：将{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数皆改以{{WPBS}}处理，
  • 跟随enwiki改版之后会由机器人自动完成：将{{Vital article}}并入{{WPBS}}

这边最近在帮忙enwiki自动化这过程。这边将申请自动更新Wikipedia:基础条目所有子页面的图示（这部分最近测试中，已趋稳定。），以及定期维护{{WPBS}}（将各种专题横幅并入{{WPBS}}并维护 'class', 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'等相关参数）。不知大家对此是否有建议？ --Kanashimi（留言） 2024年1月2日 (二) 09:53 (UTC)[回复]

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

引入enwiki近期{{WPBS}}之改版，暨将{{Vital article}}并入{{WPBS}}

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

这边最近在帮忙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)[回复]
是的，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)[回复]
  • 整理一下目前共识：
    • {{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)[回复]
基础条目模板合并案公示

见公示声明。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月24日 (三) 03:38 (UTC)[回复]
  • 还真的没有，那应该误会了。那这BOTTOM TEXT参数到底是从哪里来的？该废除的参数还是应该尽早废除。基本上只剩下一个(？)疑问：是不是还要写{{WPBS|class=xxx}}才能让其强制正常显示？--Z7504非常建议必要时多关注评选（留言） 2024年1月22日 (一) 06:05 (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)[回复]

已提出机器人作业申请，欢迎提供建议，谢谢。 --Kanashimi（留言） 2024年1月23日 (二) 01:38 (UTC)[回复]

公示期已到，期内无合理异议，且公示期内的意见之意见提出者已妥协，因此提案公示通过，将进行布署。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
{{WikiProject Biography}}参数案

本主题或以下段落文字，在讨论结束后应存档至Template talk:WikiProject Biography。

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

公示到期，期内无合理异议，提案通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:40 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
是否废除{{WikiProject Biography}}原生的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数

无共识：
没有共识，择日再议，结以待续。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月19日 (五) 06:32 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

待机器人User:Cewbot/log/20200122/configuration清理完所有{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数再开始讨论。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:42 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
Category:缺少listas变量的传记专题页面改由{{WPBS}}加入

本主题或以下段落文字，在讨论结束后应存档至Category talk:缺少listas变量的传记专题页面。

Category:缺少listas变量的传记专题页面方案二

评级系统缺失问题

（原始标题为“将{{Classicon}}与{{Class/icon}}同步”配合公告栏调整标题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月5日 (五) 07:47 (UTC)）[回复]

配合上方#Random_Thought: 跟进英维的WikiProject_banner_shell改版因此需要解决评级系统缺失问题，故提出以下议案-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)[回复]

第一阶段：修正评级值不同步问题

议案1：将{{Classicon}}与{{Class/icon}}同步

本主题或以下段落文字，在讨论结束后应存档至Template talk: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)[回复]
支持合并。不过纯模板实现也不错。--桐生ここ★[讨论] 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)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

议案2：修正评级系统被不当过滤掉的评级值

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

“未来级”等级被正确识别（使用沙盒class mask避免被滤掉而实现的），见此[1]。

上方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)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

议案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)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

提案已通过请求布署

已布署：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
布署相关编辑，也就是编辑以下模板：
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月16日 (二) 13:23 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

评级缺失问题目前办理状况

截至2024年1月5日 (五) 17:08 (UTC)已提出三案讨论，三案皆在等待初步共识，以便公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]

评级缺失案办理状况
进度 讨论中 初步共识 公示中 部署中 已完成 后续维运
*通用评级设立 已获共识 已通过 已完成 已完成 进行中
*评级继承机制 初步共识 公示通过 已完成 进行中
评级值同步 初步共识 公示通过 已完成 进行中
修正过度过滤评级值 初步共识 公示通过 已完成 进行中
评级图示同步 初步共识 公示通过 已完成 进行中
完善评级系统规范 讨论中 等待中
注：标有“*”表示是其他相关提案。
以上为截至2024年2月2日 (五) 09:45 (UTC)的办理状况。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]
2024年2月2日 (五) 09:45 (UTC)更新-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月2日 (五) 09:45 (UTC)[回复]
2024年4月6日 (六) 08:29 (UTC)更新-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月6日 (六) 08:29 (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)[回复]

没有异议，就是不知道会不会出现突发状况。 --窝法乙烷 儿法梦碎 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)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

分类改名准备

已完成：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

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

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第三阶段：Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:页面质量评级标准。

本案最初的初衷就是完成此共识Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引，来完成WP:QUALITY_升为指引一事，来正式解决“评级系统缺失问题”（指引/规范未立也算是本系统的一种“缺失”）。等上方都完成，此处将继续。声明：当这些“缺失”都解决后，本人将不再碰评级系统这块了，这烫手山竽真是消磨人的精神。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 04:40 (UTC)[回复]

可能我上面没说清楚，让你以为我是反对分类改名的，更不是什么越给我搞复杂，好啊WP:QUALITY永远升不了指引都你害的，不能有问题不让说是不是。总之是以下几点：
  1. 页面重新命名为Wikipedia:条目质量评级标准：因为评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别（WP:QUALITY就是这么写的），那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。除非你打算搞什么甲级模板级，那不是更复杂。此外还存在Wikipedia:条目重要度评级标准，那是否要改成Wikipedia:页面重要度评级标准，总之得有一个要改
  2. 目前Wikipedia:条目重要度评级标准和Wikipedia:页面质量评级标准是正交的，所以有Category:分类级低重要度宗教条目这种东西的存在，那是不是得命名成Category:分类级低重要度宗教页面。既然分类级不属于标准评级，因此也不必设置重要度，引入更多复杂性，这类页面统统扔去Category:不适用重要度条目去（或者说Category:不适用重要度页面）。
  3. {{Grading scheme}}修改，因为Wikipedia:页面质量评级标准调用了，这个就是作为WP:指引用词统一的问题
--Kunjinkao（留言） 2024年3月8日 (五) 05:20 (UTC)[回复]
  1. 无论是前次讨论还是本次讨论，都没有提到重要度，因此认为重要度的那个论述怎么样，并不碍于WP:QUALITY升为指引一事。
  2. 此修改技术成本过大，且认为这样修改与否并不碍于WP:QUALITY升为指引一事。由于目前架构问题，该修改技术上的复杂性，不建议做此修改。除非有人能提出具体的patch ，否则我不支持也不相信此修改能够被实际执行。（当然，如果有人做patch 就另当别论）-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回复]
  3. 如果没有人有异议，你可以自行修改。
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回复]
关于第一点，重要度只是顺带提及，核心是评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别，那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。--Kunjinkao（留言） 2024年3月8日 (五) 06:26 (UTC)[回复]
Wikipedia_talk:页面质量评级标准#c-Cdip150-2016-03-14T04:31:00.000Z-Liaon98-2016-03-14T02:44:00.000Z。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 06:47 (UTC)[回复]

第二阶段正式完成后的第三阶段讨论

已完成当时的共识Wikipedia_talk:页面质量评级标准#总结“将不是条目命名空间的评级分类从XX级条目改为XX级页面”，因此将安排Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引重新公示。重Ping当时参与讨论的人：@Liaon98、JyunWaan、Lssrn：@Cdip150、Temp3600、Peacearth：。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月19日 (二) 10:49 (UTC)[回复]
  • 当时的讨论是专题各自评级，而现在的情况是多了通用评级（WPBS）。所以时过境迁，WP:QUALITY要重新讨论了。我之前没有参与讨论，现在有不少想法：
    1. WPBS评级是专题评级的容器，还是一套有自己标准的独立评级？现行做法属于前者：WPBS评级继承专题的评级，且受各专题各方面的干涉，因此评级原则看似“随意”。

      一篇列表WPBS获评List级而非CL级，是因为它确实没到CL级。另一篇列表获评List级而非CL级，只是因为某个参评专题不设CL级。第三篇列表和第二篇品质相似却成功获评CL级，原因竟是不设CL级的专题没有“染指”该列表。

      所以我的看法是，通用评级就该如WPBS模板所言，确实地“依照页面品质评定标准”来独立评定，而不是在各专题评级间谋求公约数。可以参考专题评级，但把专题评级当爸爸就不对了😂
    2. 承上，如果我们确定WP:ASSESS本位而非专题评级本位，那就要讨论条目的WPBS该设立哪些级别？英维的PIQA是只支持FA、A、GA、B、C、Start、Stub、FL、List、Unassessed几个经典的“标准级别”。而我们的WPBS是大杂烩：既包括BL、CL这种品质向评级，也包括Future这种非品质向评级。所以WPBS评级所支持的“标准等级”该设哪些？
      • BL、CL等品质向等级有两条出路。一是如同英维，只收录广为人知的传统评级，不收录BL、CL这种额外等级；个别专题想启用就在自己的横幅上评。二是将BL、CL升格为通用评级，全体专题横幅亦自动启用BL和CL；如果个别专题自己讨论后坚持不用BL，那可以用掩码把BL改成List或B。
      • 对于Future级，一篇未来级条目可以很烂（Stub），也可以比较充实（C），那Future这个等级就没有实现“评价页面质量”的作用。我能想到的用途是在话题中，用未来级作为宽限条目的标记，暂时不影响认定。但这个等级的确不够“通用”，或者说和条目所用的品质评级不是一个维度。
      • 对于A级条目。英维的A级在军事史专题存活（且活得很好），但其他专题都是死的。因此英维多次讨论A级的出路，比如从PIQA里开除把A级之类。但你维是真的所有专题都不评A级；所以，把这个只有理论价值的等级从通用评级中灭了挺好。
      • 上面的想法也会影响小工具的设定：包括对标准评级的契合，对各专题自定等级的支援，对非条目评级的简化（非条目空间一般人手评级无效）。
    3. 下文有提到“消歧义级条目/页面”。如果按照命名空间来理解，那就有一个问题：重定向在各个空间都有，那到底是叫“重定向级条目”还是“重定向级页面”？（或者两个都要，但这徒增烦恼）另一方面从实用性上看，专题统计“条目数”都是排除Disambig级的，那消歧义占据条目空间就成了bug而非feature。这次从“条目”移到“页面”更像是正名，但是后缀分家无论是技术实现上还是命名统一性上，带来的麻烦都不少。考虑将后缀统一为“页”，比如品质评级这边的“乙级条目页”“丙级列表页”“模板页”，重要度那边也可以叫“高重要度页”“未知重要度页”，这样观后缀就知道是页面评级体系在整活。
    我明白很多内容都不在讨论范围内，但我认为之前讨论本身就是系统性不足。比如把非条目品质评级改为“XX级页面”，那为何条目品质评级和非条目重要度分类不动？是改条目和重要度分类真的弊大于利，还是单纯没有讨论过而已？作为这套系统创始者，英文版的非条目还用articles的，个中原因是否值得参考？--For Each element In group Next（留言） 2024年3月19日 (二) 16:05 (UTC)[回复]
    @For Each element In group Next：老实说我真的不懂你们这些这时候再来提意见是用什么心态再看事情的，这个提案已经放超过三个月了，又不是放一个星期就说要公示，硬是等提案要准备收尾才来提意见是怎么回事？！我可以当成你是打算扰乱干扰提案通过吗？！--SunAfterRain 2024年3月19日 (二) 16:40 (UTC)[回复]
    我几年前的主业之一就是评级理论。Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引6年前甚至6个月前，我都会像推动MOS:FICT那样，亲自提出修改意见和方案（如WP:QUALITY第二段不符合新形式），让WP:QUALITY成为更优质的指引。但现在评级方面，我认为和这个装睡的社群去合作没有什么意义。所以我的做法就是不发言，看着这个社群未来到底走向哪里。出于对当初理想的怀念，我写下了这些明者自明的意见，但也仅此而已了。通过提案无非就是页面多个“指引”的标签；您看我用户页，就该知道我对这种“社群众评标签”有没有兴趣了。--For Each element In group Next（留言） 2024年3月20日 (三) 16:36 (UTC)[回复]
    @For Each element In group Next：我不管你到底对这个议题有没有兴趣，反正你现在的意思是上方内容纯粹是发牢骚你没有要干扰这个提案？！--SunAfterRain 2024年3月20日 (三) 17:12 (UTC)[回复]
    还没有细看，但我对洛普利宁君遭到这样的对待感到很悲哀。--Temp3600（留言） 2024年3月20日 (三) 17:43 (UTC)[回复]
    在有用的讨论串下面离题吵架实在无奈，但似乎VP环境已经如此。
    WP:CON明确指出"共识应采纳多数人的意见，并和重要少数的意见作出适当妥协。"、"共识在维基百科是持续不断的过程"，对于方针修改，更再次明示"共识最终将根据支持和反对该议题的论点质量所决定"。方针中没有任何字眼要求讨论应"收尾"，反而暗示了讨论本身是可以无限延长，以不断修改共识更贴合实况的。所谓扰乱更是莫名其妙。
    回到讨论本身，如果有足以反驳洛普利宁君的理据，直接提出来就可以。如果反驳不了，甚至根本没有考虑到这一讨论角度，那显然就说明"之前讨论本身就是系统性不足"，提案一方存有思考盲点，应该进一步讨论下去。
    回到这个提案。我与八年前一样，支持将WP:ASSESS建立为指引。然而，洛普利宁的问题必须先得到回答:维基百科:通用评级与维基百科:页面质量评级标准之间有潜在矛盾。通用评级到底是独立的评级系统，还是专题评级的平均分?我对这两者没有特别的见解，但WP:ASSESS应该清楚指明这一上下级关系。
    如果不幸某页面只有一个专题，而这个专题将页面评为"未来级"等奇怪级别，通用评级是否跟随?
    请赐教。--Temp3600（留言） 2024年3月21日 (四) 19:45 (UTC)[回复]
    @Temp3600：那我倒觉得您来主持好了，包含修改模板模组的部分，反正您看起来很闲可以泡在客栈陪大家一直耗。--SunAfterRain 2024年3月22日 (五) 01:35 (UTC)[回复]
    • 折腾了三个月，我已经没有修改评级模组的心力了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月22日 (五) 01:52 (UTC)[回复]
    • Special:PermaLink/81985508#第三阶段：完善制度这里有说，一切以维基百科:页面质量评级标准为主，当专题评完后，维基百科:通用评级再取各专题WP:ASSESS的公约数，不认为有矛盾。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月22日 (五) 02:00 (UTC)[回复]
      • @A2569875：如果方针是FA级，指引是GA级，那现行WP:QUALITY+维基百科:通用评级大概只有C的水平，还需要很多工作完善：
        • WP:QUALITY说“评级主要由专题进行……”。那WPBS评级人是作为什么身份评的？社群成员，还是专题成员？现在WPBS开展一段时间了，相信大部分人的评级逻辑是直接对WPBS评级（而不是专门针对各个专题）。这就和“评级主要由专题进行……”矛盾。
        • 有了WPBS后，就有了“社群心目中的评级”，这个评级就是WPBS的评级。这样，大部分专题出于信任社群/懒得评级，而继承了通用评级。对于旧页面，现在的做法很好——假定WPBS评级为各专题评级的公约数。不过这个做法并非必然，我们也可以取各专题的最高值/最低值，只要社群愿意信赖专题。例如英维只有WP:MILHIST真正地在评A，而其他专题是评GA或者B，此时一个做法是取A，而非众数或向下取GA/B。
        • 但是下面的问题理论上和执行上都很成问题。例如维基百科:通用评级第5点要求“例如未启用乙级的专题，通用级别遇到规则3判为乙级的情况时，则向下填写为丙级……”。
          • 首先，很难判定专题是否启用某个级别。机器人运行者好像都说过做不到这个事情，就更不用说人工评级了。
          • 其次，如果B级是标准评级，且多数专题都评B级，那这个条目在社群心目中就是B级。我们不应该迁就特例独行的专题，否则公认的B级条目评C，那B和C还有什么可比性？应该是说，不设B级的专题应该自己收拾自己的摊子，例如专题评级继承B而表示为unassessed，或者用掩码改成C。
          • 第三，现在的BL是标准评级吗？如果不是标准评级，那应该呈现在社群通用的WPBS上吗？如果呈现在WPBS上，多数编者没见过BL，他们看得懂吗？如果你认为大家能看懂，且乐见对列表细致评级，那不如将BL升格为标准评级？如果升格为标准评级，就应该预设对所有专题的class mask启用BL，否则又回到上一点专题“特立独行”的老路。
        • 只有一个专题评Future，那WPBS技术上当然可以评Future（且只能评Future）。但上面BL甚至D级都是品质导向级别，那Future和他们并列（而不是attention之类的flag）是什么用意？还有，如果两个专题一个是CL，另一个是Future，而且两者都未设对方的级别，那WPBS到底听谁的？
        • 上述问题可以不断打补丁解决（维基百科:通用评级就是打补丁的成果），但这并非良方。大道至简，最实际的方法是：编者以社群成员的身份，以WP:QUALITY的标准评级中的选项为依据，针对WPBS评级。专题评级理论上和WPBS独立，但实践上的评级方式是信任社群评级。然后，我们讨论WPBS具体该支援哪些级别——对于条目，我建议支援传统级别，或传统级别+BL/CL/(SL?)；而Future、Merge不属于品质评估，而A级又极不活跃常常被人误解，这两类可以考虑从通用级别中除去。至于要修改的地方，无非就是修订WP:QUALITY、WPBS支援代码、class/mask预设启用代码，就像您说的，要改很简单。
        • 您可能看不懂我的留言，也可能看懂了但没有观点。建议您和有实际开设特殊级别的专题联络，看看他们的意见。我可以写出蓝本，但我不想干涉这件事情，也不想在这个物是人非的地方留言。
      • @SunAfterRain：我可以当成你是打算扰乱干扰提案通过吗？！。当然可以！您怎么想是您的权利。--For Each element In group Next（留言） 2024年3月22日 (五) 16:26 (UTC)[回复]
        你以为你维的评级模组是Module:Namespace/data这种随手改一改就好的是吧，改一次的成本有多高您可以自己改看看，不是什么看起来很简单改一改就好--SunAfterRain 2024年3月23日 (六) 03:13 (UTC)[回复]
        我2015年到2016年大幅更改过WPBM相关子模组，比如引入bchecklist。而且如果WPBM不能满足我的需要，我也有能力手写模板。我固然不是A2569875那样的技术专家，但我也知道那些内容属于微调，哪些内容属于重炼。（那时候您似乎还没注册，如果您问一下八九年前一些关注评级的老用户，您大概会知道我都干过什么）
        上面的问题我早在两个月前就A2569875君交流过。当时他表示现在只讨论技术问题，具体制度问题可以后议。我的意见不是技术问题——等真正的技术修改部署后，对WPBS屏蔽某些等级就OK——所以的确可以后议。A2569875当时态度很激烈，我不想影响他的心情，而且他应该是没有看懂我的意见，所以我就没有继续争论下去。另一方面如果我做主导人，和议案有关的问题无论在发哪里讨论，我都会接受；而A2569875的思路就是a讨论页不谈b问题（我不知道这是不是今日你维的讨论规矩）。我们俩电波对不上，我也不想在客栈留言，所以就直接走了。现在的论题正是“第三阶段（WP:QUALITY_升为指引）讨论”，既然是讨论（而不是走形式直接通过）那我充分陈述我对WP:QUALITY的看法很合理吧？而且讨论3月19日开始，我也没有拖到26日要结案的时候发。
        就我看来，应该一开始就讨论WP:QUALITY评级这个哲学问题，讨论好方向之后再开始技术修改。而且有了修改体系背书，A2569875的技术修改也能一路绿灯，不用喊“折腾了三个月，我已经没有修改评级模组的心力了”。不过中维人少，评级哲学上确实没几个人能想到这么深；就像技术方面没A2569875，其他人也推不了这个提案。最后我认为本站应该以理服人，而不是靠方针指引或没讨论深度的“共识”堵嘴：能指出问题的内容标上指引也是根基不牢，有道理的论述没有标签也应该令人尊敬。--For Each element In group Next（留言） 2024年3月23日 (六) 05:29 (UTC)[回复]
        别为你不参与讨论找借口，电波对不上不代表就可以事后再来批判，你说以理服人光是你用这个理由我就觉得你服不了人了
        另外你觉得你的意见不是技术问题但事实就是改动不小的技术问题，光是要改动一个分类就要牵涉到多少模板模组了--SunAfterRain 2024年3月23日 (六) 05:49 (UTC)[回复]
        您的考虑方向我很赞同。不过如果例子举成“改动一个模板就会牵涉多少分类的移动”，那会更有说服力 --For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回复]
        你到底在举什么...--SunAfterRain 2024年3月23日 (六) 07:28 (UTC)[回复]
    首先感谢宇凡君的努力，您辛苦了。顺便说一点离题得罪人的话：
  • 目前的问题如要解决，通用评级指引势必重写。问题只是要怎样重写而已。说白了，洛普利宁是反对通用评级的“由下而上”逻辑，再深挖下去，涉及专题组与社群整体之间的互动问题，对应现实生活中的中央－地方政府间，集权－分权的冲突。这样展开就显然太复杂了，我只是希望指出为什么洛普利宁会认为这个指引写得不好。
    回到维基。尽管从宪法的观点出发，确立各子组织间的权力分立应是建立规则的第一步，但考虑到中文维基并不怎么关注这一问题，我就建议维持现状好了，省得麻烦。反正即使是下而上，要修改专题评级，直接一起修改所有专题的评级就可以（显然这就一次侵犯了数个专题的自主权，但上面说了，中维人这方面的理解力有限）。下而上的（理论上）优势当然是“各专题组可以按各自所擅长的领域，共同对跨领域的条目进行评级，会比WPBS只用一个评级员来得准确”。实际上嘛，就是懒得改。
    “WPBS评级人是作为什么身份评的”：从下而上的观点而言，没有专题组的条目评级，算是社群托管了该条目，留待专题组前来接收，等价于联合国托管理事会。最终还是需要专题组的专家前来正式评级。
    "标准评级":基于减少修改范围（懒）的因素，建议只容许使用“标准级别”来评级。也就是说，暂时放弃将BL／CL加入WPBS，待更多专题启用这些评级，更为人所熟悉后，再来讨论。future等评级则不容许更新到WPBS上去，机器人应视这些条目为“没有评级”，由人类前来处理。
    最后，感谢@For Each element In group Next：前来，指出这些要点供大家讨论。说实话我本来也不想发言的，打了这些东西花了我一个多小时。也希望你能与我一起坚持到这项修改完结。
    以上。--Temp3600（留言） 2024年3月23日 (六) 03:33 (UTC)[回复]
    如果硬要扯开这个话题，我反倒支持废掉所有专辑的质量评级全部统一处理，因为你维专题参与人数实在少到除了几个大专题之外没有办法给出一个真的符合自己专题的评级标准，而且去查大专题的评级标准实际上也与通用标准没有差异，那这样给各专题评质量有什么意义？--SunAfterRain 2024年3月23日 (六) 05:54 (UTC)[回复]
    （以上没有要废掉重要度评级）--SunAfterRain 2024年3月23日 (六) 05:56 (UTC)[回复]
    如果完全废除专题评级，将权力上移给WPBS，那就算不谈这种集权行为是否影响了专题组的自治，也需要将目前已经由专题组评级的条目改为WPBS格式，并处理评级不一致的问题。我是不太看好能搞定啦。--Temp3600（留言） 2024年3月23日 (六) 07:10 (UTC)[回复]
    @Temp3600：感谢您的解释！虽然讨论很不愉快，但至少讨论者都能理解我要引出的思考点了。现在我的任务大功告成了--For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回复]
    喂喂，不准跑掉（ --Temp3600（留言） 2024年3月23日 (六) 07:14 (UTC)[回复]
    所以你知道为什么我说他明显有意扰乱了吧（摊手--SunAfterRain 2024年3月23日 (六) 07:26 (UTC)[回复]

随意的分段

  • 另外回应SAR的是，技术人员与行政官僚本身就是两项不同的工作，互相批评在我看来并无意义。nerd的下场，可以参考为什么苹果公司会赶走乔布斯。--Temp3600（留言） 2024年3月23日 (六) 03:37 (UTC)[回复]
    • (：)回应：@Temp3600：最初的提案是Wikipedia:互助客栈/其他#没有主题的页面如何评级。起因是我遇到有条目不属于任何专题，所以如果要评级，会有困难。（所以，我的动机很简单，我本来就只是在写条目，遇到了一个问题，我来客栈讨论解方，结果折腾了三个月，途中不乏某些维基人精神攻击，提案看起来快搁浅，精力消磨没了，写条目的动力也没了。在本案开始之前，我一个月写十几个条目，本案开始之后，三个月我只写了两个条目。）。关于该问题由MilkyDefer给出的解决方案是修改{{WPBS}}，于是开始讨论共识并执行，以及其配套的《评级系统缺失案》甚至还因技术需要跑了几趟phab(如phab:T360012)。因为最原始的目的《没有主题的页面如何评级》，代表其讨论页会放置空{{WPBS}}，也就是没有任何专题的{{WPBS}}，所以当然要能支援填写所有评级级别，包括但不限于非标准级别（为此，我还特地翻过所有专题、所有维基百科上出现过的评级级别，统整出所有专题定义的所有级别，大概40几个）。而当{{WPBS}}如果开始填入复数个专题，{{WPBS}}如果又要限制能填写的级别，程式逻辑势必变得复杂，所以我的解决方案是不改程式（你知道的，改全保护的程式不是那么简单），改立WP:通用评级指引制约，如可能也把评级系统的不同步级缺失补齐，其实目的也就只是《没有主题的页面如何评级》而已。而只是恰好Kanashimi要跑评级机器人，所以我索性再修改一下程式，跑客栈共识+公示流程，虽中间与Z7504发生争议（其实消耗了我非常多精神）但最后都通过了，而“去match Kanashimi机器人”这部分其实已经超出我原本想编写的程式内容了。后续所有技术案都通过了（过程中洛普利宁在客栈中不发一语）所以程式码当然不会包含他所期望的部分啊。维基百科是志工性质，不强迫任何人参与，既然我已经写好我想写的程式，那我为何还要在最后“可能”可以收尾的时候，帮“洛普利宁的理想”写程式？程式技术不难，但全保护和繁杂的评级系统，加上客栈不时出现精神攻击，说实在我的精力已经耗尽。我提供的任何一段程式码都没有拿到任何薪水，纯粹就是最初我想做、我想解决某些问题，但像现在这样节外生枝是否生得太夸张了？-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月23日 (六) 04:13 (UTC)[回复]
    我想，在洛普利宁的心中，他在最初就已经您解决了你的问题：维基百科有一个万能专题{{WikiProject Article assessment}}，你只要将没有专题的条目通通添加到这个专题下就可以，问题立刻解决，不需要碰WPBS。我也认为这是最简单的方法。只需要跑一次机器人，把所有没有专题的条目全部加入WikiProject Article assessment，就可以了。
    顺便一说，我自己也试过帮助条目找专题，但即便有新rater的协助，仍然很难。最大的问题是，我不知道有那些专题存在，又不知道他们的简写。如果宇凡你能改良rater，让程式可以搜寻，甚至推介专题给我来选择，会很有帮助。比如有一个英国足球队条目，但还没有专题，但分类已经写了这是英国条目，rater能不能够提示我加入英国专题（或者别的什么专题？）。
    如果不行，可以考虑一个简单一点的修改方案：当条目没有专题时，rater预设添加WikiProject Article assessment，就可以照常评级了。
    但现在WPBS已经生出来了，总不能走回头路。但这个也不容易，一会儿再写。--Temp3600（留言） 2024年3月23日 (六) 04:47 (UTC)[回复]
    @Temp3600：这完全不是什么两种不同工作的问题，有意见之前重写模组时一起纳入考量重写就好，那时候提出我想娜娜奇也会尽可能配合的，但洛普利宁同学是喔我支持改写，人家写完都开始运行了再来抱怨。不要跟我说什么滚动式修正，他提出的意见很显然不是因为模组上线才出现的。--SunAfterRain 2024年3月23日 (六) 05:38 (UTC)[回复]
    然后回到“Template_talk:WPBannerMeta#编辑请求_2024-01-08”。洛普利宁的批评是对的：宇帆在这次重构中，只考虑了技术层面上如何实行WPBS的改版，忽略了行政上的架构问题：所谓通用评级，由于每个条目只能有一个，客观上就有压倒原来专题评级的意味。于是这就进一步产生了通用评级与专题评级的冲突，新建立的WPBS机关在权责上如何与原来的专题委员会划分的问题。现在那些WPBS有没有CL级，未来级的问题，本质上都是没有完成项目定义就急于进入开发阶段，结果现在开发成果不完全符合要求，但是要再更改，工作量又很大，于是卡住了。
    所以现在还是要回到那个编辑请求，解决掉1月时的问题。然后由于技术负债，问题要尽量靠行政程序解决。这就是目前的工作。
    宇凡那时的观点，也不能说错，毕竟维基百科也没有技术可以阻止你发侵权垃圾内容对不对，但是我们有行政手段，有制度可以将侵权内容透过删除页面功能处理掉。我估计这边最后也会采用相同的方向，WPBS模版支持很多参数，但在指引中，会指明只有部分参数才可以合法使用，如果用了其他值，即使能够正常显示评级，其他人也可以回退，警告这一套。--Temp3600（留言） 2024年3月23日 (六) 08:43 (UTC)[回复]
    • @Temp3600：问题就出在于，最早MilkyDefer的起草就有未来级、CL级等等，然后我还Ping了洛普利宁问他这样可不可以，但他完全没有任何答复，到头来还是只有一句“精神上支持”，我怎么知道问题在哪，直到一月开发完成才开始说这里不对、那里不对，这样我是要怎么搞。反而User:Willy1018事先指出了具体问题，我得以依照他的问题在开发阶段先行解决，并让User:Willy1018说出了“感谢贡献，目前已复核已符合预期。”。完成后才再修改成本比较高，一开始又不讲清楚，说完“精神上支持”然后跑掉，然后现在争议后要叫我扛责任。我这样消磨掉的精神状况可能需要去放维基假期了-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月23日 (六) 09:00 (UTC)[回复]
      A2569875：首先向您道歉，我没有及时回复您的提醒，在1月份的讨论中，我也没有坚持将意见表达清楚，因为我认为您将来会用掩蔽代码的方式处理WPBS评级。我也知道了为何SunAfterRain君会将我提报到破坏区。其次感谢您完成了迄今所有的技术工作。我的意见是针对政策层面，亦即评级体系如何开展。我不参与客栈讨论，亦不会干涉指引讨论的工作；因为很多等级都是我带起来的，我这次只提出我的想法，希望让社群自行讨论如何评级等级。如果讨论结果是敲定启用或不启用某些等级而需要修改模组，而您疲于修改模组，我可以参与技术工作吗？最后就像Temp3600君所言，在下确实有责任。--For Each element In group Next（留言） 2024年3月23日 (六) 09:40 (UTC)[回复]
    (＋)支持User:Temp3600提的：不当使用WPBS参数时，其他人也可以回退，警告这一套。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月23日 (六) 09:11 (UTC)[回复]
  • 如果能够masking掉WPBS旳等级，待日后成熟等再开启，那自然是最好；不行的话，单改指引也算是解决了问题。--Temp3600（留言） 2024年3月24日 (日) 03:25 (UTC)[回复]
  • 另外拖@MilkyDefer：出来，future grade 条目要直接沿用还是怎样处理(pia!) --Temp3600（留言） 2024年3月24日 (日) 03:33 (UTC)[回复]
    什么叫沿用？事实上我连现在future grade的使用情况都不是很清楚，可否说明一下背景信息？--MilkyDefer 2024年3月24日 (日) 03:55 (UTC)[回复]
    @MilkyDefer：例如en:Talk:Texas_State_Highway_32按你的构想，是什么评级。背景资料....按我很初步的认识，英文WPBS的条目评级系统只容许BCStub等标准评级，但专题组可以按各自需要将条目评为future级等特殊等级。这与目前WP:QUALITY中建议的评级方案并不一致。--Temp3600（留言） 2024年3月24日 (日) 04:05 (UTC)[回复]
    有什么……不一致吗？Future Class列在非标准等级下，并且写有“部分专题还会启用附加等级。”看上去挺一致的欸。--MilkyDefer 2024年3月24日 (日) 04:36 (UTC)[回复]
    咦我写错了...en:Talk:Texas_State_Highway_32如果按维基百科:通用评级，它下面只有一个future-class的专题评级，那么就不能评为stub.在我看来这是问题。--Temp3600（留言） 2024年3月24日 (日) 05:01 (UTC)[回复]
    en:Template:WikiProject U.S. Roads列在en:Category:WikiProjects using a non-standard quality scale，因此此篇文章的评级没问题。我觉得WPBS的评级主要是条目整体评价，在zhwiki实施起来基本上也是这个目的。只不过 zhwiki评级似乎比较复杂，所以允许各专题自订标准，每个专题模板都算non-standard quality scale。这部分实施起来，其精神与enwiki也相同。--Kanashimi（留言） 2024年3月24日 (日) 05:12 (UTC)[回复]
    按英文版的评级方式是没有问题，但来到中维，维基百科:通用评级并不是英维的对等翻译。于是就有了"若一条目仅有一个专题，其通用评级应与该专题所评的等级一致。"这样的条款，影响到WPBS专注在内容评级的工作。顺带一说，这一点也和LP为什么建议全面转用英维制度，将内容评级由专题组上提到社群的精神一致。不过这样就涉及更复杂的改动，恐怕还是免了。--Temp3600（留言） 2024年3月24日 (日) 05:30 (UTC)[回复]
    我个人觉得这一条仅限于单一专题模板采用标准评级的情况下才有效。但假如所有专题模板都属于 non-standard quality scale，则不如废掉。--Kanashimi（留言） 2024年3月24日 (日) 05:49 (UTC)[回复]
    • @Temp3600：我觉得像Future、Current（某主题是否是新闻事件或未来事件完全取决于专题领域，例如某主题在A领域可能是一件大新闻，所以评Future，但另一个领域关它屁事所以评甲乙丙丁初之一）Merge、Need（这种通常都是向特定专题请求重定向扩充为条目的标记，无关专题就标通用评级的重定向级 重定向级吧）这些“聚焦于特定专题”的级别就让相关的专题沿用吧，然后从通用评级的标准评级撤下变成非标准评级，我想问题应该就解决了。修订的部分，我想等到下面确立哪些要设为标准评级之后，再将通用评级指引加上“只能用标准评级”之类的规范应该就能从行政手段解决了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月26日 (二) 17:36 (UTC)[回复]
  • 另另外我约略看了一下英维，看来它们已经将各专题评级整合起来，会个条目只有一个评级。这是你提出由上而下的背曔原因吗?@For Each element In group Next：--Temp3600（留言） 2024年3月24日 (日) 03:38 (UTC)[回复]
    我也认为WPBS是社群基于标准（WP:QUALITY）对条目做出的评价。当然，社群也允许专题依照自己的标准对条目做出评价，并标记在讨论页上。某种意义上，社群评级和专题评级是“人格独立”的，这里的“上”和“下”更像依赖的上下游，而不是官大一级的上下层。然后既然专题评级是独立的，那专题就可以选择各种策略：
    • 社群人多力量大，自行评级太繁杂，WPBS填啥我填啥。（看起来就像评级被废了，但其实是选择和WPBS的做法一样）如果对专题成员评级不服，要么以社群成员身份找社群吵，要么推动专题退群。这就是英维绝大部分专题的策略。
    • 预设继承社群评级，但也可以自行覆盖社群评级。这就是我们现在的状态。
    • 不继承WPBS的评级，只要自己的class不填就是未评级。英维的退群专题（比如有BL的WP:MILHIST、没A的WP:VG）都是这个策略。不排除有些专题是想自己搞；但也有专题是只开除掉A级，其他等级想继承社群，但因为英维技术不支持策略2而被迫退的。
    像SunAfterRain说的，绝大多数专题用策略1就够，而且理论上标准相同的专题应该评同样的等级。个别专题有特殊的评级标准，那就采用策略2。真有专题完全不想社群插手，那就上策略3。策略1那就是纯粹的自上而下了。此外，对上游的WPBS规定好标准等级后，将非标准等级映射到标准等级（假设规定BL->List、D->Start、Current->Unassessed），也可以让机器人参考策略2和3的专题填WPBS。
    自下而上主要还是一堆奇葩等级，逻辑上没法搞。刻度尺测量物体长度，得到的结果应该是稳定的；一次测3 cm、一次测5 cm，就说明测量错了。但如果两次测量都操作无误，那你用的大概不是尺子 WPBS本来评CL，因为来了个不支持CL的专题就改评List，两次评级都没有错，这就说明该制度不适合衡量条目品质。如果将奇葩等级改成WPBS标准评级，或者拒绝参考非标准等级，那这个制度就可行；但这基本就又成了上面的问题。--For Each element In group Next（留言） 2024年3月24日 (日) 16:21 (UTC)[回复]
    • 我觉得改动WPBS最少的可能是将所有“条目品质性”（甲乙丙丁初等）和“非条目类别性”（Disambig、SIA、Template等）的级别全部设为标准评级（含少数专题另设的Bplus和D、以及很少专题用的A级等[有专题用A级，如台风之类的专题。]），“性质性”（Future、Current等）的级别全部设为非标准评级。这些“与条目品质无关”的评级就让专题自己评，不影响WPBS，就不会出现要在CL级或Future级取舍的状况了。然后各自专题不要的，自己去mask（到时全站公告一下，想接受的专题就接受，不想接受的专题就自行写mask，这样写mask的责任就不会在此次修改上）。技术上成本最小。 只不过以上作法因会将AL、BL、CL、SL也列入标准级别，代表List级别可能会变成没有任何页面会被评成List级，看是要废除List级还是保留List级在代码里，不想跟进的专题自己mask。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月25日 (一) 04:43 (UTC)[回复]
    • 然后主题专题自设的Complete、Substantial、Basic、Incomplete因WPBS预设在非条目命名空间时会因“Namespace优先”而评成“主题级”，所以我想应该也问题不大。如需在WPBS中禁掉，可可以将Module:PJBSClass#L-53的一堆if陈述式注解掉。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月25日 (一) 04:57 (UTC)[回复]
      您说的也是可行方案。目前启用BL、CL的专题，List基本都是当和Start对等的级别来理解；如果都接受List级=初级列表，而不用新建等级，那留着List级也OK。唯一担心的是A级，倒不是有没有人用的问题。A级是高于GA的，英维也是A级评级比GA评级规格高：GA可以随便一个外行评，A级专题内部出三个专家评，FA是包括专题专家在内的社群集体评，所以有FA>A>GA的逻辑链。但是我们的FAC/GAN和英维评级模式完全是两码事，到头会不会还是社群认GA不认A？--For Each element In group Next（留言） 2024年3月25日 (一) 14:33 (UTC)[回复]
  • 先多谢各位，意见都很有见地。希望在上方再拆一个小标题。A级与GA的问题是老大难了，我想这次还是先不处理为好。A级虽然很少用，但一直都算是标准评级，现在一下子移除不太好。List级对等于初级列表长远是好主意，但要标记清楚，因为许多旧列表是list级。所以现在list级代表初级或以上的列表。或许长远要建立start list?—Temp3600（留言） 2024年3月25日 (一) 23:35 (UTC)[回复]

D级与B+级等标准讨论

接上文宇帆君列出的等级。新级别是要写文档的，所以下列意见供参考：

  • D级目前看来只有宇帆君活跃的多面体在用，其条目是介于C和Start之间。讲真，流行文化领域，因为关注粉丝向这种扣分内容，D级还是很好用的。
    • 比如明星条目，内容上已经有C级该有的内容，但因为很多内容都以粉丝介绍口吻出现，需要大量清理和改写；这时评Start太可惜，就可以评D级。这基本就像多面体专题说的，“内容上可能达到C级水准，但其他方面有严重缺陷”。或者说，写条目的人擅长事实性内容，但不了解这里的格式手册，写出的东西很随意不像百科。
    • 另一方面，虚构作品条目也强调要写反响等现实世界内容。一般来说，编者不写现实世界内容，就表示他不熟悉格式手册，所以条目格式、行文等方面也不会太好。这种条目又要清理又要扩充，就可以给Start。但也有从英维FA翻译一半的，条目序言完整、作品介绍也很规范，但该到制作历史和评价，他又他不翻译了。这种只用扩充不用清理的，也可以从Start抬升为D。
    • 可以看到，流行文化领域这个D级主要还是可以彰显“内容杂乱/格式差”。但科学等领域大概没有“粉丝内容”，所以这个D级通常会怎么用？
    • 另外有了D，是不是未来有可能对等增加DL？
  • B+只有英维数学专题有用过，而且现在删了；本地没有专题实装过，只在一些理论研究中提到，所以还是要想想标准怎么订。
    • 之前B+的评级标准是“条目高于B级标准”，再把B级标准抄了一遍，这就比较不良定义。GA和B的区别主要在GA还要求中立性稳定性，且文笔和格式的要求高于B。如果要搞B+，那标准大概就是“不要求中立性和稳定性，但其他方面同GA标准”？PS：B6提到的WP:JARGON和地区词在GA标准里没有体现，所以B在某些方面还高于GA；不过现在的英维已经把JARGON要求增补到GA标准里了。
    • 之前有提过增设优良列表（GL）。GL和FL的主要区别可以理解为GL不管红（绿）链，且序言不用太优美；这个境界就有点像B+和GA了。不过，FL和GL应该是要有本质差异的——类似WP:GVF的comperhensive和board coverage。例如对于游戏系列，FA应该像死忠那样列出小众改编作品，而GA可以只列出重要作品。（但是很多领域列表是不是没有这种问题？）
  • 小小作品更像是一个临时状态，和未评级一样是不该长期存在的。而且小小作品只是长度短，问题还没有广告、侵权等小作品更严重，所以整体统计上把小小作品拆出来的意义是？从维护追踪角度考虑，WP:PETSCAN或者Shizhao的专题机器人通告应该都很好用了。--For Each element In group Next（留言） 2024年3月26日 (二) 15:50 (UTC)[回复]
  • （有感而发）除了本子节开始的争议外，以上讨论与研究其实都满有意义和价值的，如果能提前在去年十二月，也就是我当初Ping了洛普利宁时，他就发表了这些意见，并开展了我们现在所讨论的东西，那我觉得WPBS应该会更完美。不过现在说这些都是后话了。另，跟大家说声抱歉，我当时一心只想着如何把MilkyDefer起草的临时方案开发成正式方案、如何pass所有testcases 和解决讨论页上各种问题回报（1、2等），一切考量都以技术为优先（我当时优先级最高的考量是：程式怎么写更省效能，于是出现了mw.loadData("Module:PJBSClass/page")用于让该功能在整个页面解析的过程只会跑一次，而不会每次调用通用评级时都跑以节省效能），却忽略了行政上的执行问题，而导致了今次的争议，我感到十分抱歉。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月27日 (三) 01:30 (UTC)[回复]

B+我之前写过论述。鉴于中维的GAN机制（时间短、需求票数多，且评审者普遍社会惰性），B+当GAN预审还是很有生态位的。但是在务实上，等GAN评审素质普遍超过这个乙级评级，B+才会有得玩 耸肩

我想B+（Bplus）的标准可以用WP:WIABCA的大纲来套用WP:WIAGA：

这样B级评审时也顺手按GA（B+）提意见。--For Each element In group Next（留言） 2024年3月28日 (四) 14:20 (UTC)[回复]

WPBS级别列表

目前{{WPBS}}能接受输入的级别大部分都是phab:T360012向P站登记的级别以级在案《第一阶段：修正评级值不同步问题》时所有评级Data模板统一同步更新的评级值列举如下（共50个。此外由于表格过长，已折叠。请单击[显示]以展开表格）：

能够由{{WPBS}}程式自动评级的级别（详情）
典范 特色列表 特色图片 优良 小作品 列表 同类索引
消歧义 重定向 沙盒 模板 模块 分类 文件
草稿 主题 专题 用户 使用说明 界面 非条目

以下建议供行政组参考：

  • 标准品质级别（可填写在WPBS）：
    典范级 典范级[FA]、特色列表级 特色列表级[FL]、特色图片级 特色图片级[FM]、甲级 甲级[A]、甲级列表级 甲级列表级[AL]、优良级 优良级[GA]、乙上级 乙上级[B+]、乙级 乙级[B]、乙级列表级 乙级列表级[BL]、丙级 丙级[C]、丙级列表级 丙级列表级[CL]、丁级 丁级[D]、初级 初级[Start]、列表级 列表级[List]（暂时作为初级 初级列表使用）、小作品级 小作品级[Stub]、小列表级 小列表级[SL]、小小作品级 小小作品级[Substub]、无级别 无级[No]
  • 标准类别级别（可填写在WPBS）：
    消歧义级 消歧义级[Disambig]、同类索引级 同类索引级[SIA]、重定向级 重定向级[Redirect]、沙盒级 沙盒级[Sandbox]、模板级 模板级[Template]、模块级 模块级[Module]、分类级 分类级[Category]、文件级 文件级[File]、草稿级 草稿级[Draft]、主题级 主题级[Portal]、专题级 专题级[Project]、用户级 用户级[User]、使用说明级 使用说明级[Help]、使用说明级 界面级[interface]、非条目级 非条目级[NA]（如TimedText:空间）
  • 非标准类别级别（不应该填写在WPBS）：
    图书级 图书级[Book]（曾有共识引入，但因技术原因部署无限期推迟）、音频级 音频级[Audio]（只有少数专题将File级做细分，WPBS应都填入File级）、图像级[Image]（(▲)同上）、非页面级 非页面级[NAPage]（只用于特殊专题）
  • 非标准品质级别（不应该填写在WPBS）：
    优良列表级 优良列表级[GL]（讨论尚无结果）、特色图片 特色主题[FPO]（未通过设立）、完成级 完成级[Complete]、充实级 充实级[Substantial]、简单级 简单级[Basic]（完成、充实、简单仅用于PJ:主题）
  • 非标准级别（不应该填写在WPBS）：
    未来级 未来级[Future]、动态级 动态级[Current]、合并级 合并级[Merge]、请求级 请求级[Needed]、搁置级 搁置级[Deferred]、
  • 技术性级别（不应该填写在WPBS）：
    委员会级 委员会级[council]（仅做图示用途，不应手动输入此级）、 错误级[Error]（出错时会自动加入，不应手动输入此级）、未评级 未评级[Unassessed]（无提供时自动产生，不应手动输入此级）、未知级 未知级[Unknown]（无法正确识别的情况，应修正之，而不应手动输入此级）
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月6日 (六) 03:43 (UTC)[回复]
感谢总结。我有一些疑问：
  • Substub作为标准品质，似乎比较增加维护负担？会创建小小作品的基本都是新手，他们不懂得在讨论页挂{{WPBS}}填|class=substub。维护人员也都在条目页标记{{substub}}，然后打捞人员再从Category:小小作品追踪，这就基本就没人会管讨论页。而且就算有专题模板，如果利用讨论页的分类来维护，就要从讨论页跳转到主页面，也是比较低效的。（MilkyDeferBot可以根据讨论页横幅和条目页{{substub}}自动生成页面列表，这样也没必要用讨论页评级）此外如果substub是被人手填了，那就还要经常盯着条目，看评级是否过时。所以依靠评级模板来维护substub，感觉有种打捞一分钟，评级三十秒，性价比相当低。所以，WPBS层面统合到stub是否好些？
  • 正规条目都应该有品质评级，尚未评估品质的条目是Unassessed，条目空间的Disambig等特殊页面也考虑进去了。看英维也没no这个级别，所以无级别的条目会是怎样的？
--For Each element In group Next（留言） 2024年4月6日 (六) 05:20 (UTC)[回复]

等级标准小结

洛普利宁在上文提到的“PJBS之PJBSClass.getClassByPage()”自动评级（小勘误：自动评级实由PJBSClass/main.getClassAuto()和PJBSClass.getAutoClass()共同完成，前者以页面状态和挂有模板判断、后者只看Namespace），这些评级会根据页面挂的模板、子页面名称、页面状况和所在命名空间等进行自动评级。这些评级分为两类：不可被|class=参数复写的评级以级可被|class=参数复写的评级。
这些级别有：
  • 不可被|class=参数复写的评级：重定向级 重定向级、特色图片级 特色图片级（注：|class=有值时会强制被改为File级）、模板级 模板级、模块级 模块级、分类级 分类级、文件级 文件级、草稿级 草稿级、主题级 主题级、专题级 专题级、用户级 用户级、使用说明级 使用说明级、使用说明级 界面级、非条目级 非条目级
  • 可被|class=参数复写的评级：典范级 典范级、特色列表级 特色列表级、优良级 优良级、小作品级 小作品级、沙盒级 沙盒级、列表级 列表级、同类索引级 同类索引级、消歧义级 消歧义级
上文提到，目前不在WP:QUALITY中的级别都需要补上文档，因此我起了以下草稿供参考：
（注：如果有需要修改可以直接编辑本表格，无须经过我的同意(不被视为修改他人留言)）
（注2：下表只列出目前未出现于WP:QUALITY的级别）
（注3：由于表格过长，已折叠。请单击[显示]以展开表格）
预计种类分成三类：标准级别（描述条目品质）、标准类别（描述页面种类）、非标准级别（专题自定的东西）
@Temp3600：您看看这些资讯对行政组作业有没有帮助？（请单击[显示]以展开表格）-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月5日 (五) 10:48 (UTC)[回复]
感谢宇帆君的总结。我大胆做了一些调整，说明如下：
  • Bplus之于GA类似A之于FA。A级的标准和文档页指出要走比较正规评审，类似这种，而不能像评B、C那样随手改|class=。所以Bplus的要求中我也提了要做评审；不过这也就是这么一说，大家肯定还是会随手改的😂。另外A级开始才算专业，GA只能叫接近专业（我上面说的，英维A级需要专家来评审，而GA不需要），所以调整了一下措辞。
  • D级还是可能有格式问题的，基本上B级才算比较遵循格式手册，连C级可能都差一点，而且爱好者内容广义上也算格式问题。其他方面调整了一下语言，大体是说条目内容方面有含量，但其他方面比较差。
--For Each element In group Next（留言） 2024年4月5日 (五) 13:54 (UTC)[回复]

页面评级与通用评级指引调整

    • 非常感谢娜娜奇。但我因为现实原因(pia!)暂时不能积极参与讨论。我预计会于19-21日的周末发言，这段时间麻烦诸位了。--Temp3600（留言） 2024年4月12日 (五) 11:29 (UTC)[回复]
      • 约略看过没有问题。在格式上有一点想法: 每个类别还是找一个例子，当参考。另外，会否用Template:Guideline section，只将标准评级立为指引会较好?如果专题组日后创立新评级供内部使用，便无须经VP共识修改评级表，而可自行加入。不过倒过来，如果自行加入评级会弄坏模版，那么还是经VP讨论，协调好再修改较好。这方面我不清楚，请给意见。--Temp3600（留言） 2024年4月12日 (五) 11:58 (UTC)[回复]
        • @Temp3600：届时，如果确定该等级都标准化的话，仅需要将{{Class_mask/core}}中，目前还没标准化的级别做“开放”即可（不必改程式，只要改类似config(设置)的东东），而专题自建级别已有相应功能，无须动到核心模板，范例见{{WikiProject_Example}}，因此完全无需更动本次系列模板/模组或任何程式码的核心，故自行加入评级不至于会弄坏模版。常见的专题非标准评级我觉得可以在WP:QUALITY提，在章节标题标注“本段不是指引”应该就可以了，就不必走VP共识了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月12日 (五) 15:49 (UTC)[回复]
          • 先抱歉晚了许多上来...生活艰难QQ。
          • 如果如此，那么标准级别一节立为指引就可以，并在非标准级别一节清楚列明专题可以如何自行加入新评级(好像在模版说明里已经写好?那么就只需要提供连结)。--Temp3600（留言） 2024年5月5日 (日) 07:27 (UTC)[回复]

对于Wikipedia:页面质量评级标准（以及Wikipedia:通用评级）还有一些逻辑上的考量：

  • 英文版的页面en:Wikipedia:Content assessment翻译过来是内容评级。其内涵理论上包括评级流程、评级标准等多个部分。而中文版的标题是“页面质量评级标准”，一只介绍标准本身，二又强调品质评级。而当前页面是从古早期英维版翻译过来，现在两边都改了很多，这就很微妙了。所以页面是否要改名“Wikipedia:页面评级”？
  • 如果从标题强调质量评级来看，页面似乎应该将“标准质量评级”（≈条目）和“标准类别级别”（≈非条目）分设为两个大节。说约等于是因为特色图片属于非条目但又要评估品质，而同类索引（SIA）是自动评级但理论上属于条目。
    • 对于条目品质评级部分，是否需要流程图辅助说明？（比如写入指引页，或放在论述页给个连接）
  • 如何表述“通用评级”与“专题评级”的关系？从目前的讨论来看，可能还需要一个页面（可能是Wikipedia:页面评级）厘清：
    • 社群和专题都可以各自独立地对页面评级。评级结果登记于条目讨论页顶部。
    • 通用评级由社群编者评估，对社群负责。本页刊载的等级标准为通用标准，即适用于WPBS的通用评级。
    • 专题评级由专题自行解释，但因为专题评级一般直接继承通用评级，所以也还是这套标准。部分专题可能自选启用或关闭级别，也可能重新诠释通用级别，这些内容具体在专题评级页刊载。

我希望听听其他编者的意见，所以暂时不会积极回复。--For Each element In group Next（留言） 2024年4月14日 (日) 15:17 (UTC)[回复]

  • en:Wikipedia:Content assessment 有较多的内容，我认为这是因为他们是这个制度的来源地，所以有关于制度的历史流变等可以写。中维目前只是引入的制度，还没有社群的经验，因此没有这部分的本地经验可以立为指引，而只能写一些硬规定。我认为这暂时不是问题，如日后成熟，自然可以再将这些段落引进，指引名字也可以更改。“页面质量评级标准”就暂时只写标准，待评级流程成熟后，就可以加入这一部分的指引。
同意将“标准质量评级”与“标准类别级别”分立为两个三级标题。这是一项不涉及本质的结构修改，不难。
流程图最好有，但要有人来画...

“通用评级”与“专题评级”的关系:这是我最早就想改写的部分。既然“通用评级”只可填标准评级而专题评级可以填其他自订评级，那么维基百科:通用评级就需要至少修改"若一条目仅有一个专题，其通用评级应与该专题所评的等级一致。"，最好是重新理顺这一部分的逻辑。

整理目前的讨论，建议"机器人会根据该页面最多专题评等的评级等级作为通用评级"继续保留，但机器人应检查这会否导致WPBS被评为非正式级别，如发生这种情况，那么机器人则跳过该条目(可以考虑加入"需要手动进行WPBS评级"的分类)，留待人类前来。
同意"社群和专题都可以各自独立地对页面评级"的基本策略。这样就解决了list级的问题。即使专题的评级只有list级，WPBS仍可以手动评为更准确的CL/BL等细分级别。由机器人自动评的list级也与这个逻辑没有冲突。
长远的最终方向是，WPBS作为条目的内容评级，专题评级则为某一方面提供额外的资讯，类似tag.但这个需要将目前的评级逻辑反过来，我猜一两年也无法完成，就写在这而已。--Temp3600（留言） 2024年5月5日 (日) 08:10 (UTC)[回复]

修订案

维基百科:通用评级
  • 解决“通用评级”与“专题评级”的关系。断开两者的上下级关系。
  • 通用评级只限填写标准评级。
  • 介绍一些其他功能，例如专题可以自行加入评级，不过这些不属于WPBS的范围，将它们指示到其他页面去。
维基百科:页面质量评级标准
  • 对应通用评级的改动，明确两者间的关系。即: QUALITY负责规定那些级别属于标准评级，及提供评级的参考。也提供其他非标准级别的介绍。通用评级指引则负责通用评级的流程，由社群负责，为条目的质量提供评级，而专题级模版级等请不要来找WPBS.
  • 结构调整，将“标准质量评级”与“标准类别级别”分立为两个三级标题。
T: Grading scheme
  • 为所有标准类别补上例子。

后续讨论

关于 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)[回复]
我也跟进借鉴了，至少现在用哪一个版本都不会落后。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年3月4日 (一) 11:51 (UTC)[回复]

管理人员申请预讨论

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:申请成为管理人员。

依方针，

一名具有自动确认用户权限的用户可以于每年的3月23日或9月23日前一周内在Wikipedia:互助客栈/其他发起管理人员申请预讨论，此后的提名流程即在该讨论下进行。

——WP:RFA

现开启此讨论。--人间百态,独尊变态(讨论) 2024年3月19日 (二) 14:01 (UTC)[回复]

应WT:ARBCOM#问卷讨论，提请在本次管理人员申请期间同步进行全站问卷调查处理ArbCom的细节。--路西法人 2024年3月19日 (二) 14:41 (UTC)[回复]
如果依“现在维护维基百科的表现”来看，最适合哪些维基人被提名“管理员”？--Sinsyuan✍️🌏🚀 2024年3月19日 (二) 15:42 (UTC)[回复]
显然问卷用语不能由个人决定，所以大概应该提前磋商（或披露草案），并经社群讨论同意后再付诸表决。来得及吗？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年3月19日 (二) 19:06 (UTC)[回复]
就这样看，目前剩余Wikipedia_talk:仲裁委员会#管理人员解任一讨论争议仍然比较大，就直接用这个问题即可。--路西法人 2024年3月20日 (三) 02:58 (UTC)[回复]
所以其他事项是否就留待（普通）讨论决定即可？另外因此一问题比较复杂，可鼓励大家在投票时一并发表意见。而或许还可以在选项旁附上一两句解释。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年3月20日 (三) 09:12 (UTC)[回复]
应考虑直接给留言箱填意见，而不要直接给多项选择。我要看论据不是数字。--路西法人 2024年3月20日 (三) 10:25 (UTC)[回复]
不反对只填意见，不过可能得先看届时在问卷上的问题怎么描述。--冥王欧西里斯（留言） 2024年3月20日 (三) 12:18 (UTC)[回复]
如果只是希望给意见，那还不如改成通告，直接请大家去讨论页留言互动，而不是事后再个别整理几条留言。甚至另外寄发使用者讨论页通知也行。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年3月21日 (四) 18:05 (UTC)[回复]
在MMS通知选举的同时加一句该议题正在征求广泛意见？--路西法人 2024年3月22日 (五) 10:42 (UTC)[回复]
行。另外我们应该可以开始准备通知了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年3月22日 (五) 17:28 (UTC)[回复]
但好像没有人当候选人？--某人✉ 2024年3月23日 (六) 03:39 (UTC)[回复]
@AINH I'd like to nominate @LuciferianThomas @Manchiu and @Sanmosa for sysop if possible. -Lemonaka 2024年3月23日 (六) 04:36 (UTC)[回复]
容我婉拒提名。Sanmosa Gloire d'Yser 2024年3月23日 (六) 05:18 (UTC)[回复]
容我婉拒提名。用户页上已明确指明我无意担任中文维基百科管理员。--路西法人 2024年3月23日 (六) 10:19 (UTC)[回复]
感谢信任。但我是OA2021的除权用户。需征取社群意见。--千村狐兔（留言）──此条未正确附上签名时间的留言于2024年3月26日 (二) 06:17 (UTC)加入。[回复]
不反对，但可能还得问问基金会的T&S团队，之前Stang选Wikidata的管理员时也有问过，不过T&S那边看起来并无反对意见就是了。--冥王欧西里斯（留言） 2024年3月30日 (六) 23:22 (UTC)[回复]
既然Wikidata那边已经有Stang的先例的话，那我觉得这倒无妨。此外，根据WP:2021年基金会针对中文维基百科的行动/维基媒体基金会声明#第一次问答的说明，WMF“不反对本地社区可以决定公平地重新选举”。Sanmosa Gloire d'Yser 2024年3月31日 (日) 15:38 (UTC)[回复]
@Coddlebean意下如何？Python6345（留言） 2024年3月24日 (日) 10:17 (UTC)[回复]
该使用者最近的封锁期于2023年10月11日 (三) 08:10 (UTC)结束，不符合建议资格。--Cookai饼块🍪（💬留言） 2024年3月24日 (日) 10:42 (UTC)[回复]
我想提名 @UjuiUjuMandan。--0xDeadbeef (留言) 2024年3月30日 (六) 14:13 (UTC)[回复]
接受提名。虽然我对你维社群的现状的看法是不大可能让我当管理员，但如果你维真的有幸让我当管理员，我也很为你维开心。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年3月31日 (日) 04:45 (UTC)[回复]
上面有人觉得我提名这一举动令人诧异，同时也有编者指出我没有提供提名原因。个人在站内观察过，未见UUM有哪些做法存在不当。（如有，请发给我UUM真实存在人身攻击行为的diff链接，则我会撤回这个提名）一方面我能理解社群能够愿意UUM当管理员的可能性很低，但另一方面，我认为UUM很多时候以特定语气回复的原因是在这样一个来源于en:peanut gallery的言论占多数且沉闷的大环境中，无法指望别人能够和你就事论事，所以只能使用较重的语言。我倒认为直接把拖把丢给他还能让他消停点。--0xDeadbeef (留言) 2024年3月31日 (日) 11:15 (UTC)[回复]
在编辑摘要说别人是文盲（Special:Diff/71752907/71752907），因为这个原因被管理员封禁后继续辱骂管理员（[30]），说别人是牲口（Special:Diff/81777683/81778221、[31]），在个人讨论页依然认为文明方针不重要（User talk:UjuiUjuMandan#文明方针），这已经不是你所谓的特定语气、较重语气的问题，而且就算有人不能就事论事，难道他就能开口骂人？更何况对方未必没有就事论事。--日期20220626（留言） 2024年3月31日 (日) 11:44 (UTC)[回复]
前两个是两年前的，最近应该好了很多。关于PaintWoodSt的讨论页面，是有人提出UUM给折毛提支持票而不关注举折毛这个例子的论证意义究竟是什么。关于存废讨论，我是觉得说别人主观不主观也不是一个就事论事的行为。个人讨论页中，我也没看出来哪里体现了认为文明方针不重要这一说法。这几点也没体现出UUM当管理员为什么就不合适。你也指出我用户界面的金字塔，那请你把我给出回应的部分在金字塔对号入座一下。我个人觉得，我们应该在于“UUM是否适合当管理员”就事论事。所以你如果认为“管理员在任何情况下都不应该骂人”，那我没什么可说，而如果你不这样想，那你是不是该给出一个比“UUM没素质”更有力的论点呢？--0xDeadbeef (留言) 2024年3月31日 (日) 12:10 (UTC)[回复]
虽然是两年前，那他有改善吗？还不是张口闭口说别人是牲口。
他说条目对读者没用，这句话当然是很主观，维基百科:存废讨论应避免的理由#维基百科是百科全书已经明确说到“有用”是应该避免的理由，那“没用”当然也是，而且假如这都不是就事论事，请问什么才叫就事论事？
Bluedeck跟UUM说，UUM的这些发言是明确违反方针的。UUM的回答是，对这类人，是没有必要客气的，那他的意思是，对于他认为的不好的人，说违反方针的话是没问题的。
“UUM是否适合当管理员”，我不是说了，他因为长期违反文明，所以不适合当管理员，而且既然方针明确说不能做出类似骂人的不文明行为，那管理员带头违反文明方针到处骂人，不就是违规了吗？我再举个例子，方针规定所有人不能滥用傀儡，那管理员去开傀儡，带头破坏方针，这合适吗？--日期20220626（留言） 2024年3月31日 (日) 12:31 (UTC)[回复]
你可以认为我不适合当管理员，那是你的自由。就像我有自由认为你不适合当维基人一样。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年3月31日 (日) 14:59 (UTC)[回复]
那么，我觉得你在这里的发言也很主观。--0xDeadbeef (留言) 2024年4月1日 (一) 02:55 (UTC)[回复]
这里是条目存废讨论吗？--日期20220626（留言） 2024年4月1日 (一) 03:06 (UTC)[回复]
请不要顾左右而言他。所谓客观只是一个空话。实际上维基百科，在客栈上的讨论，在存废讨论都是主观讨论。客观是不存在的。--0xDeadbeef (留言) 2024年4月1日 (一) 03:23 (UTC)[回复]
我已经在上面说过，有用或没用在存废讨论时候应该是避免的，有页面已经明确提及，如果你不认同Wikipedia:存废讨论应避免的理由那是你的事咯。--日期20220626（留言） 2024年4月1日 (一) 04:04 (UTC)[回复]
请问柳漫是不是文盲。请回答。你这个货正是因为不读条目才总是在具体问题上表现得像个没有人类智识的牲口。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月1日 (一) 02:53 (UTC)[回复]
你这是在攻击别人是文盲。--日期20220626（留言） 2024年4月1日 (一) 03:07 (UTC)[回复]
有理有据的陈述不是ad hominem。--0xDeadbeef (留言) 2024年4月1日 (一) 03:24 (UTC)[回复]
有理有据，所以就可以随意攻击别人是文盲？--日期20220626（留言） 2024年4月1日 (一) 04:06 (UTC)[回复]
你看到上面这句话了吗：

“没有人类智识的牲口”

--桐生ここ★[讨论] 2024年4月1日 (一) 05:32 (UTC)[回复]
看到了。UUM与日期的冲突之外，我仍然相信UUM是net positive。--0xDeadbeef (留言) 2024年4月1日 (一) 08:02 (UTC)[回复]
随便你咯，这是你的自由。--日期20220626（留言） 2024年4月1日 (一) 08:19 (UTC)[回复]
并且如果看细节的话实际上是说表现得像个。这和直接骂别人牲口还是有区别的。--0xDeadbeef (留言) 2024年4月1日 (一) 08:28 (UTC)[回复]
“表现得像个”，我怎么没看出来？他也没说“表现得像个”，而且直接说“别人表现的像个牲口”和说别人是“牲口”，听起来也没什么太大的差别。--日期20220626（留言） 2024年4月1日 (一) 08:33 (UTC)[回复]
当然Dewadipper直接说UUM是牲口也不对，不过这不能拿来证明UUM可以说别人是牲口。--日期20220626（留言） 2024年4月1日 (一) 08:34 (UTC)[回复]
原来不论多脏的话前面加上个“表现得像个”就可以脱罪。我很难理解这其中的逻辑。--被数学杀死了的鸢尾イチハツ 2024年5月3日 (五) 09:13 (UTC)[回复]
@鸢尾イチハツ：你好，请问我哪里为UUM骂人脱罪了？--0xDeadbeef (留言) 2024年5月3日 (五) 10:26 (UTC)[回复]
所以说你根本没能力和我讨论问题。你知道不知道柳漫是怎么编辑条目的？请回答知道还是不知道。如果你觉得你知道，请你说一下你认为柳漫是怎么编辑条目的。你维并不是人人都仗着无知胡说八道。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月2日 (二) 15:38 (UTC)[回复]
Luciferian这招解决了一个长年问题，就是维基上能不能匿名发言，以在敏感问题上收集到最真实的观点，又不用担心带来麻烦。就算这次用不着，日后也可以多多考虑。--Temp3600（留言） 2024年3月23日 (六) 03:43 (UTC)[回复]
建议以后在管理员选举时顺便举行用安全投票的“匿名征求意见”。--桐生ここ★[讨论] 2024年3月23日 (六) 11:23 (UTC)[回复]
我觉得是挺好的点子，说不定可以试试看?--Temp3600（留言） 2024年3月24日 (日) 05:38 (UTC)[回复]
本期提名时间为为4月1日00:00—4月8日00:00（UTC）。有意愿自荐的朋友可以准备一下；希望提名他人的建议先征求其意见。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月23日 (六) 09:25 (UTC)[回复]
@AT、Peacearth：想问两位是否愿意重选监督员？--桐生ここ★[讨论] 2024年3月23日 (六) 11:26 (UTC)[回复]
首先，我有一个单纯的问题，据我所知当选门槛已经降至75%，然而Wikipedia:监督仍然写“而支持者占其中总得票数至少八成才可通过”，这是否有误？--AT 2024年3月24日 (日) 04:25 (UTC)[回复]
“支持占八成”和“得至少二十五票支持”皆为《WP:RFA》旧门槛，已作事实修订。--Cookai饼块🍪（💬留言） 2024年3月24日 (日) 05:18 (UTC)[回复]
RFC是请求评论耶...--SunAfterRain 2024年3月24日 (日) 14:17 (UTC)[回复]
…改了。--Cookai饼块🍪（💬留言） 2024年3月24日 (日) 14:28 (UTC)[回复]
25票支持是m:OS的要求，已由GZWDer修正。--Cookai饼块🍪（💬留言） 2024年4月1日 (一) 03:11 (UTC)[回复]
@桐生ここ：感谢通知。最近很忙，所以大概没空。-Peacearth（留言） 2024年3月26日 (二) 00:49 (UTC)[回复]
@Xiplus：想问您有意愿参选监督员吗？--桐生ここ★[讨论] 2024年4月3日 (三) 07:22 (UTC)[回复]
抱歉没有。--Xiplus#Talk 2024年4月3日 (三) 13:07 (UTC)[回复]
@日期20220626：我想做一个有趣的事，看看你和UUM的选举结果，不知道你是否愿意参选管理员？--桐生ここ★[讨论] 2024年4月2日 (二) 13:50 (UTC)[回复]
如果你想选的话我可以和你一起选，如果你不想选的话我就不去凑热闹了。--日期20220626（留言） 2024年4月2日 (二) 14:06 (UTC)[回复]
所以我有点搞不懂，一样在客栈预提名还是用RFC的形式在别处预提名？--SunAfterRain 2024年3月24日 (日) 14:15 (UTC)[回复]
我觉得既然以往都是客栈，似乎不必RFC，用RFC不如建立专页处理每年的选举。--桐生ここ★[讨论] 2024年3月24日 (日) 16:49 (UTC)[回复]
依据往年经验，预讨论长度没有冗长到需要建立独立页面。实际上申请正式开始后，都在各该申请者子页面进行，也不会妨碍到客栈。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年3月26日 (二) 13:30 (UTC)[回复]
个人认为所有有意愿参与的站友皆可参与（或许包括上方已婉拒的站友），这可能也是在经过各种事件和调整后的最佳结果。如果我的整体参与模式还过得去（笑），这次个人自荐参与这唯一一次。--Kriz Ju（留言） 2024年3月30日 (六) 10:26 (UTC)[回复]
请问有人去phab站开工单吗？如果没有记错，预讨论的设计的目的是为了更好预备投票工作才是。你们是打算又“边提名，边预备”吗？--Ghren🐦🕐 2024年3月31日 (日) 05:53 (UTC)[回复]
打扰大家聊天，想请问要到哪边看候选人。--Tofugamay（留言） 2024年4月1日 (一) 11:01 (UTC)[回复]
没人？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年4月2日 (二) 05:37 (UTC)[回复]
虽然我不能投票，但想问，是1人只有1票，只能选1人吗？谢谢。--Tofugamay（留言） 2024年4月3日 (三) 06:39 (UTC)[回复]
候选人会在提名流程后产生，每位候选人都是独立的选举，只有支持、反对、中立三个选项。--Cookai饼块🍪（💬留言） 2024年4月3日 (三) 06:58 (UTC)[回复]
没理解错误的话，例如下面3位候选人，每人每位都可以表达立场，对吧。谢谢。--Tofugamay（留言） 2024年4月3日 (三) 07:37 (UTC)[回复]
插句话如果各位不介意多位候选人的话可以把我提名为管理员候选人，至于原因呢就是想在有空时多帮点忙，尽管我的活跃度越来越低，我知道一定会有人拿活跃度投反对票，至于为什么还是选择要选，是因为未来我可能会乔不出来应对RFA的问题了，毕竟RFA问题满消耗精神的。我可以保证的是我不会太过于不活跃，接不接受就看各位了，谢谢。--~~Sid~~ 2024年4月3日 (三) 16:23 (UTC)[回复]
@Kriz Ju君也有意参选的样子。--Tofugamay（留言） 2024年4月3日 (三) 16:40 (UTC)[回复]
题外话，管理员所扮演的角色实质为何，以及管理员究竟是否“应谦恭尔雅”，又或“应尔雅”至何种程度，抑或是应抱持何种其他适切态度，确实是个重大争议命题。甚而，也历经长期讨论。我个人的看法是：对于前者，如果应该谦恭尔雅，那么以后管理员就必须全面对社群以礼相待；如果似乎不需要到这种程度，以便保持适当的言论空间，那么相关文字经社群共识因应实务需求作修订较佳。对于管理员所扮演的实质角色，个人无甚意见。如果管理员只是个单纯“行权或是执行共识者”，那么管理员可能就更需要在某些时候避嫌为佳；如果管理员确实“因拥有管理员的身份和权限”而具备相当程度的社群或言论影响力，那么对于社群共识的形成有相当影响空间。然而，管理员是否因此就不得参与讨论呢？此种观点也似乎不甚合理（先声明，个人并非刻意对此咬文嚼字或有何挑骨头之类的用意）。
而按现今标准来看，个人的认知是自己于公于私，皆非周到有礼或对于站务参与如何熟稔或足堪表率的用户，散乱鸟烂之事也常有，且实质上对于站务能力以及近期至往后的活跃度需求恐怕不足。其实敝人自荐本来只是想借此看看是否有更多站友投入参与其中，并非颇具强烈意愿（笑）。事实上，个人恐怕着实不那么适合，也不太想因为此类投入而使原有活动或初衷过于复杂，因此我乐意辞谢。
个人还是觉得，愿意热衷参与站务并活跃其中的用户，还是个相当重要的条件的，如果往后益发淡泊社群事务，如此状态争任管理员个人也不是太有动力且颇具争议；为此，还是请其他有心有能的站友多考虑看看是否参选。不论是否和敝人曾有所交流、交集、切磋、交锋、摩擦甚或支持个人与否的站友，个人皆十分感谢。由于其他考量，力有未逮，还是向诸位站友说声辞谢，感谢各位。--Kriz Ju（留言） 2024年4月3日 (三) 17:21 (UTC)[回复]
你这就不对了。我和你说说英维对管理员的说法吧：越不愿意当管理员的，越适合当管理员。根据你这一段话，如你想参选，我会提名。--0xDeadbeef (留言) 2024年4月4日 (四) 04:32 (UTC)[回复]
我觉得思考蛮多的，支持提名+1，Sid也支持提名，以上不确定有没有违反规定。--Tofugamay（留言） 2024年4月4日 (四) 05:29 (UTC)[回复]
因为最近注意到特定账号或"组群"的活动与干涉投票结果有关，投票期间或结束后可能会为此提出其他意见或动议，细节项目不提及(抽检部分相关IP活动的页面后猜测或许有一些特殊可能，但没有证据或证据薄弱)--Rastinition（留言） 2024年5月5日 (日) 23:31 (UTC)[回复]

提名区

提名期为4月1日 00:00—4月8日 00:00，请提名人在下方分节提名。管理人员被提名者或自荐者须得到7位具人事任免投票资格之使用者联署支持，管理员被提名者或自荐者还须回答三个基本问题。因在提名期外做出的提名无效，0xDeadbeef和Lemonaka若维持提名，也请在下方重新提名。--Cookai饼块🍪（💬留言） 2024年4月2日 (二) 11:22 (UTC)[回复]

请参考往例正式提名。--Cookai饼块🍪（💬留言） 2024年4月2日 (二) 11:32 (UTC)[回复]
根据WT:申请成为管理人员/存档9#废止七人预提名制度的共识，被提名人不需要联署可直接获取选举资格。--0xDeadbeef (留言) 2024年4月2日 (二) 13:43 (UTC)[回复]
确实有这印象，但下方更复杂的修订案因其他问题没通过。--Cookai饼块🍪（💬留言） 2024年4月2日 (二) 14:39 (UTC)[回复]
没通过的原因与是否需要保持联署制度无关。--0xDeadbeef (留言) 2024年4月2日 (二) 14:41 (UTC)[回复]
我就是个意思…--Cookai饼块🍪（💬留言） 2024年4月2日 (二) 14:50 (UTC)[回复]
那七人连署是不是该先修掉。--Cookai饼块🍪（💬留言） 2024年4月2日 (二) 14:41 (UTC)[回复]
留著作为实名支持区也没什么问题。--桐生ここ★[讨论] 2024年4月2日 (二) 15:47 (UTC)[回复]
指引已修。--Cookai饼块🍪（💬留言） 2024年4月2日 (二) 15:50 (UTC)[回复]
被提名者若接受，也请在下方明确表达接受提名（包括先前已接受的UjuiUjuMandan），并回答三个基本问题（管理员的部分）。--Cookai饼块🍪（💬留言） 2024年4月2日 (二) 16:24 (UTC)[回复]
4月8日 00:00已过，邀请行政员@Shizhao、Wong128hk确认提名资格。谢谢。--Cookai饼块🍪（💬留言） 2024年4月8日 (一) 05:55 (UTC)[回复]

Manchiu（管理员）

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

维持提名@Manchiu -Lemonaka 2024年4月2日 (二) 11:29 (UTC)[回复]

三个问题的回答

本主题全部或部分段落文字，已移动至Wikipedia:申请成为管理员/Manchiu/第3次。执行人：铁胶壹名 2024年4月14日 (日) 07:57 (UTC)。[回复]

联署区
根据2023年11月讨论共识，被提名人无需再获七人联署才能被成功提名。用户仍可在下方留言实名联署支持被提名人。--路西法人 2024年4月3日 (三) 01:41 (UTC)[回复]
  1. (＋)联署，Manchiu对中维反破坏贡献良多，私认为其能善用权限。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月2日 (二) 11:55 (UTC)[回复]
  2. (＋)联署 明显地。---Lemonaka 2024年4月2日 (二) 18:05 (UTC)[回复]
  3. (＋)联署 加油----老衲（留言） 2024年4月3日 (三) 01:36 (UTC)[回复]
  4. (＋)联署+1--铁胶壹名 2024年4月3日 (三) 01:39 (UTC)[回复]
  5. (＋)联署，Manchiu君对中维反破坏贡献有目共睹，个人每天都能看得到，衷心希望其能够复职，相信他会成为一位合格称职的管理员。--Kenny023（留言） 2024年4月3日 (三) 12:05 (UTC)[回复]
  6. (＋)联署 --Heihaheihaha麻瓜了……（留言） 2024年4月3日 (三) 12:45 (UTC)[回复]
  7. (＋)联署。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月4日 (四) 09:38 (UTC)[回复]
  8. (＋)联署--Benho7599 | Talk 2024年4月4日 (四) 16:26 (UTC)[回复]
  9. (＋)联署OA并不碍于他不能当管理员的条件。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️）──此条未正确附上签名时间的留言于2024年4月5日 (五) 00:26 (UTC)加入。[回复]
  10. (＋)联署。桐生ここ★[讨论] 2024年4月5日 (五) 05:47 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

UjuiUjuMandan（管理员）

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

维持提名@UjuiUjuMandan。--0xDeadbeef (留言) 2024年4月2日 (二) 11:31 (UTC)[回复]

请注意我只能提名无法联署。因为我不符合人事任免投票资格。--0xDeadbeef (留言) 2024年4月2日 (二) 12:37 (UTC)[回复]
管理员提名区什么时候成为了随意阴阳怪气被提名编者的地方了？--0xDeadbeef (留言) 2024年4月3日 (三) 04:21 (UTC)[回复]
所以说你可能不了解中维社群的情况。阴阳怪气是有传统的。有些人不知道为什么就是不正经讨论，就要阴阳怪气。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 04:28 (UTC)[回复]
插个话。为求谨慎，UjuiUjuMandan若接受提名，请您在这一串重新表明。--Cookai饼块🍪（💬留言） 2024年4月3日 (三) 04:39 (UTC)[回复]
我可不是那种说过话装作没说，希望别人不记得的货。我说我接受提名，不是开玩笑，不是恶心人，不是满地打滚。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 11:30 (UTC)[回复]
  • 除自荐外，提名使用者为管理人员前均必须获得该使用者的明确同意。
  • 提名期限为4月1日 00:00—4月8日 00:00或10月1日 00:00—10月8日 00:00。任何在此时间段外做出的提名均无效。
  • 通过使用者讨论页或其他方式通知被提名人。一项提名必须由被提名人在提名页或预讨论串下回复并同意，方为有效。
因此之前那个只能说是征求你的意见，而不是提名你，你的回复也只是表达同意，而不是正式接受提名。Cookai1205是出于程序上的严谨请你正式接受提名，而不是认为你在开玩笑。--桐生ここ★[讨论] 2024年4月3日 (三) 11:55 (UTC)[回复]
了解。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 13:55 (UTC)[回复]
三个问题的回答

本主题全部或部分段落文字，已移动至Wikipedia:申请成为管理员/UjuiUjuMandan。执行人：铁胶壹名 2024年4月14日 (日) 07:57 (UTC)。[回复]

联署区
根据2023年11月讨论共识，被提名人无需再获七人联署才能被成功提名。用户仍可在下方留言实名联署支持被提名人。--路西法人 2024年4月3日 (三) 01:43 (UTC)[回复]
  1. (＋)联署，被指导过许多参与维基所需的技能。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月2日 (二) 12:23 (UTC)[回复]
  2. (＋)联署，优秀的条目编写能力，积极处理站务。--铁胶壹名 2024年4月2日 (二) 14:49 (UTC)[回复]
  3. (＋)联署，该用户温柔和蔼，待人谦卑，文明有礼，善待新手，从不在站内或站外辱骂他人是牲口，我认为该用户符合管理员标准。Interaccoonale（留言） 2024年4月2日 (二) 16:12 (UTC)[回复]
    WP:GAME，WP:POINT。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 04:23 (UTC)[回复]
    @Interaccoonale 请重新更改原因以表明支持当选，否则当废票处理。铁胶壹名 2024年4月3日 (三) 04:47 (UTC)[回复]
    我支持UUM参选啊，有什么问题吗？--Interaccoonale（留言） 2024年4月3日 (三) 04:49 (UTC)[回复]
    @Interaccoonale 那么你好歹换个认真点的原因吧，现在原因只是在阴阳怪气，丝毫看不到支持的立场。请重新更改原因以表明支持当选，谢谢合作。铁胶壹名 2024年4月3日 (三) 04:52 (UTC)[回复]
    所以你这就是显然的诡辩了。请您停止扰乱。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 05:26 (UTC)[回复]
    上面那句话当然是讽刺，但是我讽刺你和我支持你参选并不矛盾。我支持你参选管理员，并且我一定会给你投赞成票。这有什么问题吗？谁规定的我讽刺你我就不能支持你？
    1. 你曾经说过你骂人是因为中维社群无法有效地处理所谓的“牲口”，所以你只能骂人把“牲口”骂走（不是原话，凭记忆复述的，如果有不准确的地方请指正），那么我很好奇如果你有了可以直接封禁“牲口”的权限之后会怎么处理，能否比现有的管理员处理得更好，以及你是否还会骂人。而你在站内条目空间的观点和行为我其实是部分认可的。
    2. 我和你没有在站内因为条目编辑问题产生过冲突，你当选站内管理员对我没有影响。
    3. 我确实怀有一种看热闹的心态，想看看你当选管理员之后中维社群究竟会发生什么。
    这三个理由可以吗？--Interaccoonale（留言） 2024年4月3日 (三) 05:58 (UTC)[回复]
    现在的三个理由看起来合理，但显然也不能否定你前面的扰乱。你现在停止扰乱了很好，希望你坚持。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 06:44 (UTC)[回复]
    我讽刺你和我支持你参选并不矛盾，这两件事完全是可以同时发生的。为什么我一边讽刺你一边支持你参选就是在扰乱？--Interaccoonale（留言） 2024年4月3日 (三) 08:06 (UTC)[回复]
    ……诡辩成这样我还能说啥呢？你为什么还赖在中文维基百科？--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 11:31 (UTC)[回复]
    为了看你当管理员之后会发生什么啊。--Interaccoonale（留言） 2024年4月3日 (三) 11:52 (UTC)[回复]
    如果你是这种心态最好还是不要投票。要么不参与，要参与就尽量为自己做的事负责。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月4日 (四) 05:26 (UTC)[回复]
  4. (＋)联署，是人虽偶有不文明行为，但每次批评都有理有据且能清楚指出对方不足，在站外的言行举止亦无可挑剔，相信能胜任管理员一职。—-Aggie Dewadipper 2024年4月2日 (二) 16:26 (UTC)[回复]
    @Dewadipper 请重新更改原因以表明支持当选，否则当废票处理。铁胶壹名 2024年4月3日 (三) 04:47 (UTC)[回复]
    凭什么？我对人有自己的判断，就凭我和他吵过架你就觉得我在讽刺？少来ABF。——Aggie Dewadipper 2024年4月3日 (三) 04:57 (UTC)[回复]
    我觉得这个是ABF了。字面上真的没有任何明显看起来是讽刺的内容。和interacoonale、松照庵的情形不同。哪怕他们将来一定会改票，今时今日的ABF、妄加判断就是妄加判断。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 05:27 (UTC)[回复]
    洗澡的时候突然发现还有个问题，人家候选人自己都没意见，你跑来给我划票了？你是UUM的摄政还是代理？—-Aggie Dewadipper 2024年4月3日 (三) 05:33 (UTC)[回复]
    你这样还是在人身攻击。他既然不是我的走狗，当然他做事是出于他的独立判断。他认为你的做法是扰乱，是他的判断。你不认同他的判断，我也不认同他的判断，但你把他说成是我的傀儡，那可就是诽谤中伤了。你该改改你诽谤中伤的臭毛病了。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 06:37 (UTC)[回复]
    我又没说他是你的傀儡，我只是在说人家越俎代庖了，你怎么读出这层意思的？—-Aggie Dewadipper 2024年4月3日 (三) 06:47 (UTC)[回复]
    ……你是真的连这种常识都没有还是怎样，他是有独立人格的人，他认为别人在扰乱是他的事，怎么就越俎代庖了？--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 11:33 (UTC)[回复]
  5. (＋)联署，此人举止优雅，处事公正且从不令人失望，说话大方得体，态度值得敬佩，是作为中文维基百科管理员不可多得的人才。相信在他的帮助下，中维社群的未来定能更加美好。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月2日 (二) 16:38 (UTC)[回复]
    @SickManWP 请重新更改原因以表明支持当选，否则当废票处理。铁胶壹名 2024年4月3日 (三) 04:48 (UTC)[回复]
    兄台，这整个章节甚至都不是一个投票，想问如何作废？--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月3日 (三) 04:51 (UTC)[回复]
    同上。不要ABF。维基病夫说这种废话是他惯常的行为模式。不要ABF认为他在说反话，他也许是真的表达支持。尽管将来他非常可能改票。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 05:28 (UTC)[回复]
  6. (＋)联署 kyrieleis. -Lemonaka 2024年4月2日 (二) 23:33 (UTC)[回复]
    Kyrie eleison?--（☎）dt 2024年4月3日 (三) 00:45 (UTC)[回复]
    Aka may god mercy us. -Lemonaka 2024年4月3日 (三) 01:03 (UTC)[回复]
    Fear none of those things which thou shalt suffer: behold, the devil shall cast some of you into prison, that ye may be tried; and ye shall have tribulation ten days: be thou faithful unto death, and I will give thee a crown of life. --revelation 2：10
    你将要受的苦你不用怕。 魔鬼要把你们中间几个人下在监里，叫你们被试炼，你们必受患难十日。你务要至死忠心，我就赐给你那生命的冠冕。——启 2：10 -Lemonaka 2024年4月4日 (四) 01:56 (UTC)[回复]
    劳烦给社群一点基本的尊重。社群的所有流程都是为了做事而征求意见、做决定、执行用的。如果您发言不是为了对具体事务的讨论做贡献，您的发言就不适当。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月4日 (四) 04:34 (UTC)[回复]
    求主宽恕。
    Helped by chatGPT
    我希望你选举成功，但希望你能更文明地对待社群管理的试炼，管理也是对我们社群本身的试炼。 -Lemonaka 2024年4月4日 (四) 11:49 (UTC)[回复]
    如果您坚持要说一些显然不是给社群里多数人听的话，请您换个场合。停止扰乱，多谢。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月4日 (四) 14:18 (UTC)[回复]
  7. (＋)联署，相信能提高中维条目品质，能够有效遏止写劣质条目的人。—Sean0115 2024年4月3日 (三) 00:09 (UTC)[回复]
  8. (＋)联署 草莽臣松照庵顿首顿首，死罪死罪。昔汉运式微，黄魏代兴；唐数行终，汴梁继轨。前代之故，或有鉴于胜朝；徂曩之迹，庶能昭于今日。长白UUM，禀资超跋，音声中听。玉音所至，遍及牲畜；群奸丑类，靡不闭嘴。位极功成，已侔伯卓；烛炬星罗，源休称瑞。草莽臣松照庵昧死言，伏惟Shizhao肇基景命，历迈一纪；贤圣迭兴，久逾十载。黔黎未闻大命，万机不可久旷。闻之尚未，进止何从；事机长旷，奚正典刑？UUM才等尧舜，迹比梁朱，闳谋巨猷，发无暇日；缘督由任，豁然离解。纶音溥化，人兽同膺。臣等今所仰望，诚非一日之功；维基当下所有，的是石穿之渐。草莽臣身在三维，无从陪列盛典，卞庆之怀，延颈罔极。谨上劝进表，草莽臣松照庵顿首顿首，死罪死罪。----老衲（留言） 2024年4月3日 (三) 01:27 (UTC)[回复]
    如果你这种不干正事的毛病不改，我只能建议你尽早离开维基百科。你是觉得社群已经弱智到看不出你在做人身攻击吗？--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 04:20 (UTC)[回复]
    我也不能不教而诛，所以还是教吧，尽管很多人是不会学的。
    1. 文体方面，即使古文水平不大好的读者大概也能猜出来是在劝进。
    2. 长白UUM：我并不是出身长白山或者其他名为（或者别称为）长白的地方的人，也从未如此自称。纯是此人的创作。那么他为什么要如此创作还加粗呢？我能想到的唯一解释只能是他在做人身攻击，试图联系一些无关因素来扰乱讨论，毕竟我是满族专题的参与者嘛。
    3. 位极功成：当然没有什么位极这种事。中维理论上讲大家都是平等的。特别是在讨论问题的时候，没该有什么仗着自己不懂就唯别人马首是瞻这种事。每个人都应该带着自己的脑子，长自己的眼睛，用自己的嘴说自己的话。然而很可惜的，中维确实有一些人，不去用自己的独立人格，用自己的声誉和荣誉去担保，做独立思考，用自己的语言论述，偏偏就要仗着无知、怠惰而对自己不知道的事情妄加评断，让做正事的人都没法做正事。我真的希望这样的人都有点自尊，站起来说话。
    4. Shizhao肇基景命：他又怎么了？他在你维也不过是个普通的成员。至少我和他讨论问题的时候，和他意见不同的就有很多次了，也没见他不和我讨论问题或者我不和他讨论问题，也从没见他胡乱给我面子或者我给他面子，都是有问题说问题，有观点说观点，能怎么解决问题怎么解决问题。你如果真的看不惯Shizhao，你大可以自己写个论述，说他哪里不好。你写得出吗？我想不能。你根本没用自己脑子想过Shizhao到底有什么问题，不过人云亦云。
    5. 死罪死罪：死罪可免，你离开维基百科如何？ --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 04:38 (UTC)[回复]
      说的太对了！感恩！此外，长白是清代满族自我称籍贯时候，雅称的一种。长白某某，意思就是来自于满洲。这其实是非常雅致的一个地名。所以您应该高兴。--老衲（留言） 2024年4月3日 (三) 04:46 (UTC)[回复]
      所以说你可以停止犯贱了吗？--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 05:25 (UTC)[回复]
      好的，现在，立刻，马上！--老衲（留言） 2024年4月3日 (三) 05:27 (UTC)[回复]
      不该不教而诛，所以这里我再说一下为什么松照庵前面在犯贱。如果我们以古文的文体来要求，这里就有个基本常识问题：自称是谦恭的，而称呼人只要不是要攻击对方，是要尊敬的。比如古人自称名，而称他人的字，就是这类习惯。假设大清国有汉文不错的旗人写文章自称长白某某，是合适的。但你要说别人，不能直接照搬自称，要看那个自称有多得体，多准确。更何况，原本我就和松照庵没什么友情，他厌恶我，我厌恶他，他厚颜无耻假惺惺地套近乎，以为我不会扇他一个耳光，那我也只好该做什么做什么，对他这种无耻行为直接扇耳光咯。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月4日 (四) 06:07 (UTC)[回复]
      中维社群长期以来特别纵容这种阴阳怪气、皮里阳秋、指桑骂槐的行为。这是因为有不少维基人本身就足够的缺乏常识或者缺乏道德。很长一段时间在中维，有人被冒犯了说句粗话就会被警告被封禁，但是满地打滚嬉皮笑脸撒谎诡辩诽谤中伤，却不会被谴责，更不会被封禁。这种行为不牲口，什么行为牲口？这种社群不牲口，什么社群牲口？一点尊严都不要吗。最近中维社群在这方面逐渐有所好转，希望能够越来越好。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月4日 (四) 06:10 (UTC)[回复]
    下一个WMLO、Longway22。--桐生ここ★[讨论] 2024年4月3日 (三) 04:26 (UTC)[回复]
    这是在说谁？--0xDeadbeef (留言) 2024年4月3日 (三) 04:32 (UTC)[回复]
    User talk:维基百科最忠诚的反对者#又想起一辈古人来了。--桐生ここ★[讨论] 2024年4月3日 (三) 04:45 (UTC)[回复]
    您不要悲观，我已经过了WMLO的年纪了。搞不懂那些了。----老衲（留言） 2024年4月3日 (三) 04:59 (UTC)[回复]
    说起来WMLO为此还GAME了个劣质条目。真的很烦。你们这些人不瞎的话能看出这玩意儿写得多垃圾吗？如果实在能力不够，看不出哪里差，我可以教你们，但你们会学吗？ --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 15:29 (UTC)[回复]
  9. (＋)联署，有看过一些他的论述，挺有道理的，支持开启投票。桐生ここ★[讨论] 2024年4月5日 (五) 05:50 (UTC)[回复]

注：因为某些票数纯属WP:GAME、WP:POINT，加上联署已废除，不影响结果，已用删除线划去。--此条未正确签名的留言由阿南之人（讨论｜贡献）于2024年4月3日 (三) 04:40 (UTC)加入。[回复]

@阿南之人：您起码签个名吧--（☎）dt 2024年4月3日 (三) 07:13 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

AT（监督员）

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

提名User:AT为监督员，在现任管理人员中AT算是比较活跃的。尽管上次以1%微差落选，我认为AT还是足够可信成为监督员。--追风（留言） 2024年4月2日 (二) 13:48 (UTC)[回复]

另根据本留言，本提名不设联署区。追风（留言） 2024年4月2日 (二) 13:48 (UTC)[回复]
附议，(＋)联署。--桐生ここ★[讨论] 2024年4月2日 (二) 13:52 (UTC)[回复]
+1。铁胶壹名 2024年4月3日 (三) 02:08 (UTC)[回复]
我和AT在一些具体问题上是有分歧的，但正因为有分歧所以我觉得可以信任。--此条未正确签名的留言由UjuiUjuMandan（讨论｜贡献）于2024年4月3日 (三) 15:30 (UTC)加入。[回复]
+1，另外楼上那位是UUM吧？--（☎）dt 2024年4月3日 (三) 21:11 (UTC)[回复]
(＋)联署虽说不需要联署（上面也都不用联署，但大家也还不是照样联署？）以表达(＋)支持。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月5日 (五) 00:25 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

ASid（管理员）

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

提名User:ASid为管理员。本人认可其担任管理员的能力，惟前三次选举皆因票数不足落选。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月4日 (四) 09:57 (UTC)[回复]

接受提名，感谢信任。--~~Sid~~ 2024年4月4日 (四) 09:59 (UTC)[回复]
(＋)联署。--桐生ここ★[讨论] 2024年4月4日 (四) 16:45 (UTC)[回复]
(＋)联署。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月5日 (五) 00:22 (UTC)[回复]
(＋)联署，信任ASid。--Benho7599 | Talk 2024年4月5日 (五) 01:50 (UTC)[回复]
(＋)联署--冥王欧西里斯（留言） 2024年4月5日 (五) 05:00 (UTC)[回复]
三个问题的回答

本主题全部或部分段落文字，已移动至Wikipedia:申请成为管理员/ASid/第4次。执行人：铁胶壹名 2024年4月14日 (日) 07:57 (UTC)。[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

ATannedBurger（管理员）

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

提名User:ATannedBurger为管理员，已经在站外征得其同意。--🎋竹生🎍 2024年4月5日 (五) 00:36 (UTC)[回复]

(＋)联署。--桐生ここ★[讨论] 2024年4月5日 (五) 05:43 (UTC)[回复]
能有效沟通的就是好管理员。支持。0xDeadbeef (留言) 2024年4月5日 (五) 10:18 (UTC)[回复]
三个问题的回答

本主题全部或部分段落文字，已移动至Wikipedia:申请成为管理员/ATannedBurger/第2次。执行人：铁胶壹名 2024年4月14日 (日) 07:57 (UTC)。[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

SickManWP（管理员）

未完成：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

提名User:SickManWP为管理员，已经在站外征得其同意。--🎋竹生🎍 2024年4月5日 (五) 00:36 (UTC)[回复]

(＋)联署。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月5日 (五) 02:14 (UTC)[回复]
(＋)联署--Benho7599 | Talk 2024年4月5日 (五) 02:50 (UTC)[回复]
(＋)联署。--桐生ここ★[讨论] 2024年4月5日 (五) 05:44 (UTC)[回复]
(＋)联署：这个使用者在站内贡献巨大 非常优秀 能适任维基百科管理员--Liao_509 ☄️Fighting！签名🖋 2024年4月5日 (五) 08:43 (UTC)[回复]

本人经过几天的思考，很遗憾告诉大家我将会退出本次的管理员选举，原因如下：

  1. 经查询医生的意见，本人目前的健康状况（实际病因不便公开）无法长时间参与站务。
  2. 本人预料我的日常生活将十分繁忙，希望争取更多时间在学业和工作上。
  3. 本人相比起担任管理员，更希望花时间在中维完成美国地方条目的建设。

综上所述，再一次为辜负以上诸位对我的期望而道歉。本人将会继续支持ASid君、ATannedBurger君在本届竞选管理员。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月10日 (三) 17:16 (UTC)[回复]

三个问题的回答
  1. 您期望帮忙怎么样的管理事务？请先阅读管理员的介绍页面。
    我计划协助处理中文维基百科的傀儡行为，并将积极的傀儡调查结案，适当地对违反傀儡方针的用户进行封锁。例如Dxy5案从发现到处理便拖了四个月之久。若我能成为管理员，私以为可以快速处理同类案件，并作出适当的处理。此外也计划对一些长期扰乱条目评选，或对明显条目问题履劝不改的用户进行禁制。
  2. 在所有您在维基百科撰写的条目或作过的贡献中，有没有让您觉得特别喜欢的部分？有的话，为什么？
    我喜欢部分维基人之间能协作编写条目，因为百科全书的初衷就是将知识无私奉献给所有人。不同的维基人能表达意见，将条目的描述字眼令大众更易明白，彼此提出良言或指正，是我最乐意从中维社群中看到的局面。
  3. 你有没有在过去遇到任何有关编辑方面的冲突，或者是你认为其他用户造成你的压力？您如何处理这件事，以及未来遇到时您会怎么处理？
    总括而言，我在中维的这些年并没有与用户产生严重的冲突。如果我被卷入争执，我会细心以普通用户的姿态去聆听他的观点，再理性使用方针驳斥，说明其编辑的不当。如果情况严重，我会交给其他用户处理，以避嫌。我从不用我的主观立场去强加于用户身上，因为情绪会使人丧失判断能力。

以上，如有疑问会在提问期为大家详细解答。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月5日 (五) 16:22 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

结果

由于不须联署，已将所有提名区结果字段整并至此，到时一齐确认即可。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月4日 (四) 09:38 (UTC)[回复]

不同申请案不是该分别确认吗？又跟须不须连署有什么关系？--Cookai饼块🍪（💬留言） 2024年4月5日 (五) 05:04 (UTC)[回复]
不需要确认联署是否通过，只需要确认参选基本资格即可。--桐生ここ★[讨论] 2024年4月5日 (五) 05:56 (UTC)[回复]
没连署只是少了一项条件须要确认，我不觉得集中结果栏行政员有比较好办事。--Cookai饼块🍪（💬留言） 2024年4月5日 (五) 06:07 (UTC)[回复]
只需要写一则留言，到时候子页面还可以直接用一张表格列出。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月7日 (日) 09:00 (UTC)[回复]

经过初步检查，@Manchiu，@UjuiUjuMandan，@ASid，@ATannedBurger，@SickManWP，未发现上述用户不符合管理员申请资格；@AT已签署ANPDP协议，且符合其他监督员申请资格。请其他行政员复核--百無一用是書生 (☎) 2024年4月9日 (二) 13:14 (UTC)[回复]

更新：SickManWP退出选举。--Cookai饼块🍪（💬留言） 2024年4月10日 (三) 17:39 (UTC)[回复]
提醒一下：管理员申请资格只是建议，并非强制要求，而且目前没有联署要求，因此理论上任何注册用户都可参选管理员--百無一用是書生 (☎) 2024年4月11日 (四) 09:00 (UTC)[回复]
@Wong128hk、Jimmy Xu、Kegns、Wing、Ffaarr--Sinsyuan✍️🌏🚀 2024年4月11日 (四) 09:29 (UTC)[回复]
@Sinsyuan 你基本上ping了个寂寞，那几个都是不活跃的……铁胶壹名 2024年4月11日 (四) 09:33 (UTC)[回复]
啊？除了Shizhao以外其他行政员都不活跃！？可是Shizhao要其他行政员复核呢！--Sinsyuan✍️🌏🚀 2024年4月11日 (四) 10:32 (UTC)[回复]
@Sinsyuan现在在互联群邀请Wong128hk中 铁胶壹名 2024年4月11日 (四) 10:34 (UTC)[回复]
经查，书生君所决无误。上列诸位均符合资格参选。--J.Wong 2024年4月14日 (日) 04:09 (UTC)[回复]

工单准备

于Phabricator查看
编号T361902的工单

这里有一点需要注意的内容。首先，根据Wikipedia:征求意见/2024年管理人员制度改革#议案2B：处理合并选举规则不清晰问题，新投票界面应包含类似“管理人员选举无当选限额，各候选人分开计票，支持票不限于一票”的指引。其次需要考虑到Wikipedia:征求意见/2024年管理人员制度改革#议案2A：合并选举存废中所讨论的可否拆分。同时，根据上方讨论关于WT:ARBCOM#问卷的说法，同时包含关于仲裁委员会的调查问卷（不是选择，而是填文字回答）：

管理人员解任在多大程度由仲裁委员会处理？

  • 甲、仲裁委员会按调查事实及方针指引，直接作出除权决定。
  • 乙、由仲裁委员会调查事实并发布管理人员操守报告，确认存在违规事实后，才转交社群决议除权。
  • 丙、仲裁委员会完全不参与管理人员解任。

欢迎讨论。0xDeadbeef (留言) 2024年4月3日 (三) 12:42 (UTC)[回复]

请问这个是指提交给仲裁委员会的案件，还是所有RFDA案件？--桐生ここ★[讨论] 2024年4月3日 (三) 14:48 (UTC)[回复]
路西法人的意见是所有RFDA经过ARBCOM，我的意见是RFDA和ARBCOM不互相影响。这个问题或许也可以添到工单上。--0xDeadbeef (留言) 2024年4月4日 (四) 00:52 (UTC)[回复]
赞同你的意见“RFDA和ARBCOM不互相影响”，支持添加到工单上。--桐生ここ★[讨论] 2024年4月4日 (四) 03:44 (UTC)[回复]
这需要另行草拟问题。我觉得此问题本身可以先加上定语，只涵盖由仲裁委员会经手处理者（也就是原本社群提出者另议），以避免混淆。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月4日 (四) 09:35 (UTC)[回复]
可附上相关讨论连结。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月4日 (四) 09:35 (UTC)[回复]
我还是比较同意上方说Eric Liu说如果只是希望给意见，那还不如改成通告，直接请大家去讨论页留言互动，而不是事后再个别整理几条留言。的说法。这样附上留言的方式不便于详细展开讨论。--Ghren🐦🕐 2024年4月4日 (四) 17:24 (UTC)[回复]
如是者，我不清楚你们这个问卷调查是是不是要匿名征求意见。如果答案为是，可考虑加入工单；如是答案为否，我建议在管理员选举的说明中提及+MMS即可。--春卷柯南－发前人所未知 ( 论功行赏 ) 2024年4月4日 (四) 22:35 (UTC)[回复]
据说是匿名征求意见--0xDeadbeef (留言) 2024年4月5日 (五) 01:37 (UTC)[回复]
Why not both？匿名收集意见方便整合各方观点，也撇除了发言者身份的观感，方便往后只针对观点讨论；MMS内引导亦可即时邀请更多用户参与相关讨论。--路西法人 2024年4月5日 (五) 01:42 (UTC)[回复]
我想即使是在一般的页面讨论，也应该要做到“整合各方观点”和“对事不对人”这两件事吧。匿名收集意见不是完全对以上两点没有帮助，只是作用很少而已。--Ghren🐦🕒 2024年4月5日 (五) 07:13 (UTC)[回复]
不试试怎么知道有没有帮助呢？what's the worst that can happen？没有人提意见？没有有价值的意见？那又怎样。结果出来整合一下大家的意见，再公开讨论也还好吧。--0xDeadbeef (留言) 2024年4月5日 (五) 10:26 (UTC)[回复]
根据phab:T358067的时间轴，此次管理人员选举的投票时间只能够在5月初开始。我们有可能需要更新一下投票时间。--1233 （T / C） 2024年4月9日 (二) 06:51 (UTC)[回复]
依据现行指引，获得正式提名之时，必须立即置申请子页面，且一定要在四月二十八日前完成安全投票筹备。显然此规定无法实现，弹性过低，事后大概需要一并检讨。至于是次申请的处理方法，我认为可以经全体被提名者同意（或至少予以知会），请行政员宣告因现行规定窒碍难行，延后讨论期及投票期。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 12:33 (UTC)[回复]
副知@Manchiu、UjuiUjuMandan、ASid、ATannedBurger、SickManWP。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 12:34 (UTC)[回复]
本人已于昨晚宣布退选，故私以为不用为本人建立RFA子页面。我认为现时可以为四位候选人建立RFA子页面，这样就能提早进入发问环节，争取更多时间让社群了解候选人的观点及立场。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月11日 (四) 12:38 (UTC)[回复]
支持先进入提问期。--桐生ここ★[讨论] 2024年4月11日 (四) 16:10 (UTC)[回复]
但提早进入，也提早结束，我认为申请应反映社群最新共识变动，所以越迟开始越好。无论如何，在大家还没商定期限以前，都不应该径行开始。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 16:28 (UTC)[回复]
个人认为可延长提问期以增加关注度。理论上当前条文为在被提名者经行政员确认获得正式提名之时起二周内，任何使用者都可以发表意见，包含提问及讨论等，不过考量到此条自2006年以来就已设立，个人认为此根据自由意志的二周提问期限（若不是因自由意志所设立，我也很有兴趣知道为什么不是）已无法实际符合当前RFA的状况，包括因SecurePoll所导致的各种选举过程延宕的情况。
个人会希望提问期可从设立RfA子页面开始至投票前一到二周结束，而之所以留空一到两周的目的是作为缓冲并希望候选人能回答完所有问题。嘛，当然，这个提案很有可能会导致候选人需要答题的数量变多，但可透过其他措施如限制问题数量至一人三问或其他方式来进行改善。--（☎）dt 管理员竞选中 2024年4月14日 (日) 07:41 (UTC)[回复]
（及@AT）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 16:28 (UTC)[回复]
再副知其他行政员@Ffaarr、Jimmy Xu、Kegns、Shizhao、Wing、Wong128hk。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 18:56 (UTC)[回复]
@Ericliu1912：已知悉。辛苦。-千村狐兔（留言） 2024年4月11日 (四) 15:09 (UTC)[回复]
感谢告知，辛苦了谢谢。--~~Sid~~ 2024年4月11日 (四) 15:43 (UTC)[回复]
@Ericliu1912 @Shizhao @ATannedBurger 距离五月不足两周了，本人认为应该开始讨论期（最好是4月21日），直到投票准备就绪为止。铁胶壹名 2024年4月18日 (四) 08:36 (UTC)[回复]
@Manchiu @UjuiUjuMandan @AT @ASid @ATannedBurger 行政员已完成申请资格复核，现已建立对应的选举页面（Manchiu、UjuiUjuMandan、AT、ASid、ATannedBurger），唯根据上面的讨论，提问时间尚未开始。铁胶壹名 2024年4月14日 (日) 07:11 (UTC)[回复]
辛苦了--（☎）dt 管理员竞选中 2024年4月14日 (日) 07:16 (UTC)[回复]
今天已经是4月23日（UTC+8），各候选人的RFA界面也都已经完成设立，本讨论自一周前已无更新内容。若按照工单中所述，4月26日直接进入投票期，是否意味着提问时间将与投票期重合？还是说社群有其他关于提问期及投票期之决议？--SheltonMartin留言|签名 2024年4月23日 (二) 02:03 (UTC)[回复]
@阿南之人 @SheltonMartin 根据phab:T358067，U4C的投票目前为第一优先级（由4月26日到5月9日），考虑到讨论期一般开启七天，如开启太长时间的话会给参选的人带来不必要的压力，则最早讨论期应由5月3日开启，在中维选举在U4C选举之后立即开始的情况下。--0xDeadbeef (留言) 2024年4月23日 (二) 12:23 (UTC)[回复]
（而U4C的投票还要点票这个事情，我建议先等U4C的投票点票结束再考虑什么时候开启讨论。）--0xDeadbeef (留言) 2024年4月23日 (二) 12:26 (UTC)[回复]
1. 请社群讨论，是否有必要在揭示板或其他地方对讨论期及投票期的时间节点作出更清晰的说明？
2. 先前有编辑提出延长讨论期的动议，社群是否考虑付诸讨论？
3. 建议明确后续管理人员任免投票的时间节点（如在某月第某周开启），对中维的大部分用户而言，U4C的投票能有多大限度影响中维的管理人员任免存疑，而且似乎也没有看到各语言维基需避开U4C或类似选举的规定或先例。
以上。--SheltonMartin留言|签名 2024年4月24日 (三) 00:27 (UTC)[回复]
U4C的投票能有多大限度影响中维的管理人员任免存疑 - votewiki在U4C投票期间是英文，而一般中维投票时会改为中文。你要觉得大家能看着英文投票就没事。
别的语言维基又不用SecurePoll。--0xDeadbeef (留言) 2024年4月24日 (三) 08:17 (UTC)[回复]
@Manchiu、UjuiUjuMandan、ASid、ATannedBurger：不然设五月一日至十四日为正式讨论期，十五日至二十八日为投票期？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月24日 (三) 07:57 (UTC)[回复]
可--（☎）dt 管理员竞选中 2024年4月24日 (三) 08:02 (UTC)[回复]
OK。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月24日 (三) 08:39 (UTC)[回复]
checkY已更新选举页面。铁胶壹名 2024年4月24日 (三) 09:43 (UTC)[回复]
好。辛苦诸位。-千村狐兔（留言） 2024年4月24日 (三) 23:30 (UTC)[回复]
@Manchiu @UjuiUjuMandan @ASid @AT @ATannedBurger 今天讨论+提问时间正式开始。请各用户和候选人做出准备。L'Internationale, Sera le genre humain! 2024年5月1日 (三) 03:32 (UTC)[回复]
@Manchiu、UjuiUjuMandan、ASid、ATannedBurger：考虑到设立选举的准备尚未完成（投票者列表相关 query 仍在执行，且 T&S 仍未回复），个人建议投票期由5/15延迟至两周后，即5/29举行？副知候选人。谢谢。--SCP-0000（留言） 2024年5月13日 (一) 15:32 (UTC)[回复]
那么提问环节是相应延长？已有候选人表示提问压力甚大…-千村狐兔（留言） 2024年5月14日 (二) 09:45 (UTC)[回复]
本人认为停止提问，但可以继续在意见区讨论。L'Internationale, Sera le genre humain! ✏️ 2024年5月14日 (二) 09:51 (UTC)[回复]
提问环节的长度是有规定的，我认为不宜延长。同意上面的见解。Sanmosa 全方贫工之联合 2024年5月14日 (二) 09:54 (UTC)[回复]
无论如何，感谢@SCP-2000：SCP-2000君辛劳。-千村狐兔（留言） 2024年5月15日 (三) 02:31 (UTC)[回复]
既然社群无异议，现暂定5/29 - 6/12举行，谢谢。--SCP-0000（留言） 2024年5月15日 (三) 06:06 (UTC)[回复]
提问，若5/29 T&S仍未回复，投票期是否会继续延长？--SheltonMartin留言|签名 2024年5月16日 (四) 05:25 (UTC)[回复]
@Manchiu、UjuiUjuMandan、ASid、ATannedBurger、Wong128hk、Jimmy Xu： T&S 回复称可在 5/29 - 6/12 期间举行选举。另外，由于运动宪章批准投票于 6/25 开始，技术上行政员不能作出延长选举一周的做法。副如候选人及监督员。谢谢。--SCP-0000（留言） 2024年5月18日 (六) 01:56 (UTC)[回复]
知悉，辛苦！－千村狐兔（留言） 2024年5月18日 (六) 02:25 (UTC)[回复]

对新用户禁用内容翻译工具（续）

于Phabricator查看
编号T349959的工单

原讨论存档见此：Wikipedia:互助客栈/其他/存档/2024年3月#对Phabricator的回应

以下为Pginer-WMF的最新回应：

Perfect. I think we can plan to introduce these changes. We plan to introduce these in iterations.

  1. Limit publishing into the main namespace to "extended confirmed users" only.
  2. Get input from the community on the effects, for the community to decide whether to make the restriction more/less strict.
  3. Make machine translation non-default.

In this way we can have a better understanding on the effect of each of the changes and how to adjust them.

简单而言，他们将作出以下更改：仅允许延伸确认用户将翻译发布到主命名空间，并愿意之后依社群意见将限制调整成更严格 / 宽松；以及机械翻译设为非预设选项。

@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、MilkyDefer、Dewadipper、Stang： 考虑到他们的提议与过去讨论的共识（即禁止翻译发布到主命名空间及机翻设为非预设）相近，如果一周后没有任何异议，即视为社群同意他们的提议。副知所有曾参与讨论的编者。谢谢。--SCP-0000（留言） 2024年3月23日 (六) 13:27 (UTC)[回复]

没问题。--日期20220626（留言） 2024年3月23日 (六) 13:33 (UTC)[回复]
应该可以。--冥王欧西里斯（留言） 2024年3月23日 (六) 14:20 (UTC)[回复]
挺好，我收到了邮件但都忘了这事了。--MilkyDefer 2024年3月23日 (六) 15:01 (UTC)[回复]
好。 -‎Lemonaka 2024年3月23日 (六) 16:56 (UTC)[回复]
非常好。——Aggie Dewadipper 2024年3月23日 (六) 19:55 (UTC)[回复]
他们愿意退让是可以就此参考他们的意见啦--SunAfterRain 2024年3月24日 (日) 14:16 (UTC)[回复]
赞同。--桐生ここ★[讨论] 2024年3月24日 (日) 16:51 (UTC)[回复]

既然已有多人同意此变更，且正如上方提到他们的提议与过去的共识相近，故依照 WP:SNOW 视社群同意他们的提议，并已在 phab 反映社群的意愿。谢谢。--SCP-0000（留言） 2024年3月24日 (日) 14:29 (UTC)[回复]

不反对如此配置。但扒了三个有使用内容翻译工具的直出主条目空间的成品（中国的动物福利和权利、自由意志民主党人、杰克逊·欣克尔 ），我还是觉得禁用了可能更好。 囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2024年3月25日 (一) 08:15 (UTC)[回复]
目前方案通过后第一个条目不会直接输出到主空间，因为作者的编辑数量还达不到延伸用户的级别。所以至少挡掉三分之一了，不错了。--日期20220626（留言） 2024年3月25日 (一) 08:20 (UTC)[回复]
如果可以，不知能否帮忙整理使用内容翻译而有问题的条目？这样方便与基金会沟通时，有相关例子可供他们参考及研究。谢谢。--SCP-0000（留言） 2024年3月25日 (一) 16:44 (UTC)[回复]
感觉被G13的多少都是内容翻译的条目。。。—-Aggie Dewadipper 2024年3月25日 (一) 18:39 (UTC)[回复]
偶尔也有非内容翻译的条目被挂G13。--日期20220626（留言） 2024年3月25日 (一) 22:26 (UTC)[回复]
@SCP-2000：用RTRC找主条目空间、新建页面（因为原生最近更改不方便找新建页面）、标签为“内容翻译”、“内容翻译2”的，应该会存在不少。例如找到一篇乔安娜·斯丁格蕾（oldid=82028905）。好像最近多了一批没用户页的新用户在用这个系统来翻译，而且首次格式质量都存在或多或少同类问题（包括斜体、数字间空格、参考注脚之间空格或者参考复制的一些格式暴露（<cite>这种）、缺少参考列表，部分还有格式紊乱、模板丢失）虽然这些问题是新页面巡查员应该去做的事……——Sakamotosan路过围观 | 避免做作，免敬 2024年3月26日 (二) 02:15 (UTC)[回复]
根据提案，新用户已经无法通过内容翻译直接在主空间生成条目。--日期20220626（留言） 2024年3月26日 (二) 03:31 (UTC)[回复]
只是提供收集说服来源的方法。当然希望拉高下限能挡住一部分借助该系统粗制滥造的低质量翻译条目。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月26日 (二) 13:15 (UTC)[回复]
另外，感觉User:New user message不会对不是以本项目注册的新用户发自动欢迎的（例如找到的User:赛博崔会遇见电子铝黄瓜吗、User:Art4cn），有可能导致新用户缺乏对格式规则的了解。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月26日 (二) 02:26 (UTC)[回复]
这个改配置即可，可以在其建立本地账号时发送。个人认为至少其有一个编辑在发送会好些？（改配置噩梦）--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年3月30日 (六) 22:34 (UTC)[回复]
What the hell is that? -Lemonaka 2024年3月30日 (六) 01:21 (UTC)[回复]
In general, Content translation will redirect users to their chosen language of wiki, even if they use it on zhwiki. So I don't think it's the content translation's fault, but I have no idea how they can do that :)--SCP-0000（留言） 2024年3月30日 (六) 07:45 (UTC)[回复]

内容翻译现已缩紧

（注：复制自WP:互助客栈/消息#内容翻译现已缩紧，原由User:MilkyDefer发布。）

自4月10日（三）起，只有拥有延伸确认权限的使用者可以使用内容翻译功能将页面发布到主条目空间。这次调整是因应近期多发的粗滥翻译问题所做出的。延伸确认权限自动授予注册满90天且编辑满500次的编者，以及管理员。

请巡查员和所有编者留意这次更改后，翻译条目的品质是否有改善。其结果会决定是否采取下一阶段的措施：将“从原文开始”设定为默认翻译选项。

@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、Dewadipper、HualinXMN、SunAfterRain、S8321414： 副知所有曾参与讨论的编者。谢谢。--SCP-0000（留言） 2024年4月11日 (四) 17:11 (UTC)[回复]

phab:T349959#9711650，疑似未生效。--碟之舞📀💿 2024年4月14日 (日) 07:50 (UTC)[回复]
不过好像数量并不多。--日期20220626（留言） 2024年4月14日 (日) 07:58 (UTC)[回复]
原因也大致抓到了，Special:PermanentLink/82270024#L-111应该能当临时补丁--SunAfterRain 2024年4月14日 (日) 14:35 (UTC)[回复]
并没有生效：Special:用户贡献/EitanVel。上面的patch有管理员review下么？--Tim Wu（留言） 2024年4月19日 (五) 01:36 (UTC)[回复]
@SunAfterRain Not applied till now, Special:Contributions/Hueydome88E92 -Lemonaka 2024年4月21日 (日) 10:52 (UTC)[回复]
@Lemonaka：phab:T349959#9734223 patch backports in today. 虽然我是不知道他们说的移植后仍然有问题是什么意思，毕竟我刚才看的结果确实有正确拦截到了...--SunAfterRain 2024年4月23日 (二) 12:39 (UTC)[回复]
确实还没有修正，如火腿黄油三明治。--SCP-0000（留言） 2024年4月24日 (三) 03:51 (UTC)[回复]

本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

关于IP封禁豁免权授予者的顶部图标

本主题全部或部分段落文字，已移动至WT:IP封锁豁免权授予者。执行人：Sanmosa 全方贫工之联合 2024年5月14日 (二) 15:11 (UTC)。[回复]

对ITN获选标准及ITNR的小修订

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:新闻动态候选、Wikipedia talk:新闻动态/重复发生的项目。

此前的相关讨论：

最近Wikipedia:新闻动态候选出了一些问题：

第一，在社群讨论没有得出支持刊登的情况，管理员自行刊登内容，如Wikipedia:新闻动态候选/存档/2024年3月#亚伦·布什内尔自焚事件；

第二，部分内容在刊登之前没有收到反对意见，刊出之后被质疑关注度或重大性不够，如Wikipedia:新闻动态候选/存档/2024年4月#习马二会；

第三，涉及中国载人航天工程的条目近期在提名时多被社群以不具备突破性为由反对，见Wikipedia:新闻动态候选/存档/2022年6月#神舟十四号、Wikipedia:新闻动态候选/存档/2023年6月#神舟十六号、Wikipedia:新闻动态候选/存档/2023年10月#神舟十七号和Wikipedia:新闻动态候选#神舟十八号。

针对以上的第一条及第二条问题，提案对现行的ITN获选标准作出如下修订：

现行条文
  • 管理员在每次更新栏目时，应当查看新闻动态候选区内所有提案。管理员认为提案符合新闻动态候选标准的，应予采纳；不符合候选标准的，应由管理员陈述意见后退回重审。有二名及以上维基人提出反对意见的，亦应当退回重审。
提议条文
  • 管理员在每次更新栏目时，应当查看新闻动态候选区内所有提案。管理员认为提案符合新闻动态候选标准，或支持刊登的意见占大多数的，应予采纳；不符合候选标准的，应由管理员陈述意见后退回重审。有二名及以上维基人提出反对意见的，亦应当退回重审。
  • 对于刊登之后出现反对意见提案，管理员应暂时移除相关内容，直至社群得到支持刊登的共识。对于没有得到绝对结论的提案，需要有二名及以上的管理员进行商讨，以最终决定是否刊登。
  • 提案新闻内容涉及需要地区词转换的用字，提案人需要先自行处理。

针对以上的第三条问题，提案对现行的WP:ITNR作出如下修订：

现行条文
  • 载人轨道航天器的发射升空；一个国家首次成功完成自主发展的轨道发射；发射空间站或其主要组成部分；航天器抵达月球或更远的目的地；重大航天任务失败
提议条文
  • 每款载人轨道航天器首次发射升空；每款载人轨道航天器与特定空间站首次成功对接；一个国家首次成功完成自主发展的轨道发射；发射空间站或其主要组成部分；航天器抵达月球或更远的目的地；重大航天任务失败

正如WP:NOTNEWS所说，维基百科不是新闻报道。新闻动态候选和Portal:新闻动态设立的初衷也不是为了提供新闻报道，“是为了鼓励增订或更新相关的条目，而不是用作新闻报道”。由此可见，社群应该从百科性的角度来提报及衡量新闻动态条目，一些不具备百科性的条目能不提报就不提报，能不刊登就尽量不刊登，毕竟“维基百科不是新闻报道”。所以，新闻动态的标准也尽量严谨。上述的修改意见只不过是抛砖引玉，欢迎社群在此提案的基础上踊跃讨论。--Jeffchu2014（留言） 2024年4月28日 (日) 17:08 (UTC)[回复]

修改第二项讨论连结，刚才点击不到。另外第三条问题也有讨论过，连结在此：有关WP:ITNR中科学探索与发现标准修订--Cmsth11126a02 (留言) 2024年4月28日 (日) 17:30 (UTC)[回复]
门槛最好全部订为两位维基人。一位意见还说不准。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月28日 (日) 22:41 (UTC)[回复]
要避免出现傀儡行为和偏见，可能要考量一下新注册用户和IP用户。--Kethyga（留言） 2024年4月29日 (一) 00:19 (UTC)[回复]
可是Wikipedia:新闻动态候选/存档/2023年6月#神舟十六号占多数，结果刊登，神州十七和神州十八反对的也是同一批人，应该说是部分编辑反对，不能代表“社群”。--Kethyga（留言） 2024年4月29日 (一) 00:30 (UTC)[回复]
神舟十六他们的理由都是“符合WP:ITNR”，但在神舟十七和神舟十八已经解释WP:ITNR不强制管理员刊登也不能超过基本候选资格中‘新闻内容应该同时具备“重大性”与“百科性”’。所以神舟十七起不刊登正是修改“符合WP:ITNR就必须刊登”的错误共识。--Cmsth11126a02 (留言) 2024年4月29日 (一) 04:01 (UTC)[回复]
怎样轻易判断“具有重大技术突破意义”？以神舟十八号为例，“全员1980年或以后出生”算不？零件更新换代算不？缩短发射整备流程算不？新闻提报是26日，而之前提到的都是之后才更新进去，这是不是也在“鼓励增订或更新相关的条目”？这个标准判断含糊，操作性可能有限。但同意ITNR只是给管理员快速确定的建议，而非必须上的标准。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月29日 (一) 00:56 (UTC)[回复]
具体来说是载人飞船本身，或者飞船所执行的飞行任务有一定的技术突破，比如首次实现宇航员舱外活动的神舟七号任务，以及与天宫一号进行无人及有人交汇对接的神舟十一号，就算重大的技术突破。--Jeffchu2014（留言） 2024年4月29日 (一) 10:48 (UTC)[回复]
@cwek、Jeffchu2014：我在此建议用我上次建议：
现行条文
  • 载人轨道航天器的发射升空；一个国家首次成功完成自主发展的轨道发射；发射空间站或其主要组成部分；航天器抵达月球或更远的目的地；重大航天任务失败
提议条文
  • 每款载人轨道航天器首次发射升空；每款载人轨道航天器与特定空间站首次成功对接；一个国家首次成功完成自主发展的轨道发射；发射空间站或其主要组成部分；航天器抵达月球或更远的目的地；重大航天任务失败
“每款载人轨道航天器与特定空间站首次成功对接”意思就是载人轨道航天器A与空间站a首次成功对接为一个组合，然后不符ITNR但有技术突破的用一般ITN程序（像神舟七号），以免ITNR变强制刊登令。--Cmsth11126a02 (留言) 2024年4月30日 (二) 07:54 (UTC)[回复]
好的。--Jeffchu2014（留言） 2024年5月1日 (三) 03:54 (UTC)[回复]
我认为即使支持刊登的意见占大多数，但如果非常不符合新闻动态候选标准，管理员应该可以酌情考量，所以在我看来“或支持刊登的意见占大多数的”这句话纯属多余。
“需要有二名及以上的管理员进行商讨，以最终决定是否刊登。”我不知道实作的话如何商讨？有没有足够的管理员来商讨？目前维护ITN的主要就是两个管理员，个别还有一两个管理员偶尔更新一下，所以在人力刚刚够满足“需要有二名及以上的管理员”这个条件时，很容易造成不满足“二名及以上的管理员”的条件，比如包括偶尔更新的管理员在内，一旦其中有一两个一段时间不上wiki或不关注ITN，那么就被卡死在这个条件上了--百無一用是書生 (☎) 2024年4月29日 (一) 04:05 (UTC)[回复]
那是管理员的问题，不是ITN的问题。中维60个管理员（人数还在不断增长中），找不出两个能维护ITN的，那建议集体辞职。--SheltonMartin留言|签名 2024年4月29日 (一) 05:56 (UTC)[回复]
实际操作总是要考虑现实问题啊（现在只剩60个管理员了吗？！）--百無一用是書生 (☎) 2024年4月29日 (一) 07:26 (UTC)[回复]
？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月29日 (一) 08:11 (UTC)[回复]
定期让社群感受一下管理员的活跃程度。--AT 2024年4月29日 (一) 09:17 (UTC)[回复]
管理员活跃程度算是还行，但专门活跃ITN的，那就不一定了，除非能随机做一些管理员专门来ITN给大家评评理，而且人家愿意的话。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月29日 (一) 09:33 (UTC)[回复]
也不一定是由管理员来负责最终的评判，可以参考GA和FA的做法，任何人都可以来划票。不过ITN采用的是共识制，GA和FA是投票制，到时候可以任命几位活跃于ITN的编者来做这个工作（自己提名的条目除外，需要避嫌）。--Jeffchu2014（留言） 2024年4月29日 (一) 10:53 (UTC)[回复]
虽然目前主要是我跟Shizhao在处理，但至少还有三、四位管理员也偶尔会经手新闻动态，所以人手并不是到非常贫乏。不过当然还是希望有多一点管理员能参与！—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月1日 (三) 04:19 (UTC)[回复]
其实草案中这“二名以上管理员”或可改为“二名以上或至少一位非当事管理员”？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月12日 (日) 03:19 (UTC)[回复]
话说是不是应该要求新闻动态（包含最近逝世）提出者先自行处理好地区词才能刊登啊？不想每次都帮忙善后欸。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月30日 (二) 19:22 (UTC)[回复]
已加入。--Jeffchu2014（留言） 2024年5月1日 (三) 03:58 (UTC)[回复]
我暂时的看法是，加入了上述限制会导致相关新闻事项事实上不符合且无法达到“重复发生的项目”这一基本要求。如果要根据“具有重大技术突破意义”来判断的话，适合的做法是直接删掉这一ITNR项，当作普通提名来进行讨论。--东风（留言） 2024年5月1日 (三) 06:28 (UTC)[回复]
“具有重大技术突破意义”已经改成Cmsth11126a02的版本。--Jeffchu2014（留言） 2024年5月2日 (四) 19:31 (UTC)[回复]
赞成ITNR修订，不赞成ITN获选标准修订。“管理员认为提案符合新闻动态候选标准，或支持刊登的意见占大多数的，应予采纳；”会致使新闻动态沦为人数游戏，架空重大性、百科性／品质、充足资讯／更新等行之已久的标准。建议改为：“若有比例不低的合理意见证明提案或其主条目不符合新闻动态标准，不予刊登，如有可能改善至符合新闻动态标准，则延后决定；如无前述情形，且多数意见支持刊登，应予刊登。”其余条文可跟进调整。此外，“对于刊登之后出现反对意见提案，管理员应暂时移除相关内容，直至社群得到支持刊登的共识”或许使得刊登前后的反对意见太不等价，一条不合理的反对意见太过重要。--— Gohan 2024年5月4日 (六) 01:01 (UTC)[回复]
我支持您的“若有⋯⋯刊登。”建议，后面我建议“对于刊登之后出现反对意见提案，管理员应将此等意见与刊登的全部意见一并考虑，按共识是否改变而决定是否移除相关内容”。--Cmsth11126a02 (留言) 按照伟大光荣正确的傅崐萁总召，国民党的正确名称是大陆国民党！ 2024年5月4日 (六) 04:44 (UTC)[回复]

Unblock-zh.org

Unblock-zh.org网站的样子

很久以前讨论过的一个项目，也就是unblock-zh的网站版，我最近给他做出来了，如果对测试版软件感兴趣的话，请去 https://unblock-zh.org 这里去看看。（注意测试版软件，你的用户最后很可能被删掉！）

附带一个教学视频 https://www.youtube.com/watch?v=IImfyNnRB4M

目前站外用户申请账户的方式是Wikipedia:账号请求发送邮件，其实也没有太不方便。但是这个途径我觉得还是更直观一点，比邮件列表好用一点，尤其是管理员处理的时候。我的想法是网站可以和邮件列表并存，或者以后达成互联。欢迎提出意见。Bluedeck 2024年4月29日 (一) 04:05 (UTC)[回复]

PS. 已经收到tigerzeng的意见，允许用户自定义提供的IP地址字段，以解决部分代理的问题。Bluedeck 2024年4月29日 (一) 04:22 (UTC)[回复]
超 英 赶 美 —— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月29日 (一) 08:09 (UTC)[回复]
我最期待的画面出现了。--AT 2024年4月29日 (一) 09:14 (UTC)[回复]
好吧，终于把这个弄出来了——是蓝桌弄的？那就不出奇了。👍 赞——Sakamotosan路过围观 | 避免做作，免敬 2024年4月29日 (一) 09:29 (UTC)[回复]
非常好UX。至于是否方便了用户，我好奇能否在合理的范围内收集一些统计数据作对比，这样最有说服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)[回复]
另外这个工具让我想到了我很久之前做的维基媒体服务器连通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)[回复]
非常好软件。
不必要的功能建议：1.通过遍历封禁日志的摘要有无对应模板，显示是否是ip封禁。2.通过接口调用在界面一键创建账户（和授予ipbe？）
另外问一下数据托管在哪里？将来投入使用的话需要作为存档使用，所以数据需要备份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)[回复]
一键创建账户/授予PIBE的话，有两种途径。第一，管理员通过oAuth授权unblock-zh.org，通过管理员账户操作，然后从本地日志看来，操作者是管理员。第二种途径是，成立一个机器人账户，比如名叫 unblock-helper-abot，并且赋予机器人管理权限，然后通过机器人操作，并在摘要里说明是根据哪个管理员的指令操作的。让我来决定的话，我倾向于使用第二种方式，因为我希望尽量不要向第三方授权我自己的账户，但是第一种方式的日志更加清晰。请问一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)[回复]
使用OAuth可以只需要简单的身份识别获得权限，用于确认是不是登录系统的对应是wiki的哪个用户。然后代理操纵的机器人可以标记操作人员的wiki用户名（通过前面获得的信息）。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:33 (UTC)[回复]
如果不改变单管理员授权模式，我倾向于第一种，这样和原先的工作模式保持一致，便于查询。
mw:OAuth/For_Developers称应用做的操作会有标签。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)[回复]
在这里没有看到可以使用oauth给用户添加组别的选项，那么也是说IPBE的授予只能透过abot进行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)[回复]
的确只能这样。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月2日 (四) 03:40 (UTC)[回复]
咱好像记着这种权限似乎不需要特别勾上某个选项就默认拥有，您要不尝试一下？ Stang★ 2024年5月8日 (三) 01:14 (UTC)[回复]
真的假的，在授权的时候不声明却可以操作改变用户组这么重要的操作？如果是真的那也是个bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)[回复]
用API能查IP有没本地封或者全域封，好像不是必要。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:26 (UTC)[回复]
👍 赞👍 赞👍 赞 牛逼--Dnaimfz（留言） 2024年5月11日 (六) 04:04 (UTC)[回复]

试运行

在过去的几周里，我增加了最后的一些的功能，分别是1）按日期搜索排列工单；2）邮件回复模板；3）管理员删除工单、删除消息界面；4）用户改名功能。我想知道大家觉得还缺少哪些网站本身的功能（邮件服务器、机器人授予IPBE除外）。如果感觉差不多了，那么可以进行试运行。试运行期间，再对可能发现的新的功能需求进行补充。试运行的提议正在进行公告。如果通过，将会将网站首页文字改为试运行，并暂时移除一些只具有展示效果的链接，然后在用户无法注册的提示页面加入网站的链接，这些操作大概最多需要一天就能完成。在试运行决议通过前，如果对网站有任何问题，欢迎在此讨论。Bluedeck 2024年5月13日 (一) 23:30 (UTC)[回复]

功能方面，个人认为管理员不应该有删除工单的能力，这个应该由维护者来做，比如遇到spam/扰乱性工单就打上相应的标签，若干天后自动删除；可不可以出个statistics大概写一下某月某人处理了多少工单之类的；反spam方面怎么样，你觉得需要加个recaptcha吗；模板建议是放到Github或者类似公开的地方，需要改的人发pr；可以考虑加一个link/merge功能么，比如一个用户就一个问题发了多个ticket，这个时候可以把它们关联起来；感觉可以把login改的小一点，或者让非管理人员意识到不需要登录就可以发ticket。
另外就是建议放到toolforge或者cloud VPS上。顺便问个问题，你觉得这个系统需要承担unblock-zh最原始的封禁申诉职能吗 Stang★ 2024年5月14日 (二) 01:47 (UTC)[回复]
  • 谢谢提议！简短回应：
  • 删除工单就是为了应对扰乱才设计的功能。删除之后可以恢复或检视。（UI需要另外添加）工单的永久保留或删除问题在下面讨论。
  • 反spam：UTRS目前是阻止同一个IP地址多次发送工单。但是我的方案不记录IP地址，无法阻止。我可以考虑一下记录ip地址的hash，并由此进行rate limit。我个人完全不喜欢captcha，除非不得已，我可能会考虑上captcha。在此之前我会尽量用其他手段处理spam问题。我有一些asymmetric proof of work的方法能防止自动化的spam。如果有人无聊到要手工spam，那么唯有记录IP并进行区段查封这一个办法。（但是这样一来，不就把本身的目的给击败了？？）
  • 邮件模板：我不会放在github，毕竟不是每个管理员都会开PR，我简单的开一个用户页面存储目前的模板，谁想添加，给我留个言即可。邮件模板都是非常简单的纯文字模板。当然，如果你喜欢用gh，那么在前端的repo里有一个文件，你也可以直接PR这个文件。
  • link/merge：race condition太多，最多做成stack overflow/github issues那样，“标记为#109的duplicate。关闭”这种解决方案。
  • login改小：我肯定会让新用户看到不login就能发工单，这是一个重要的因素。
  • statistics：这个我一定会做，因为这会让处理工单变得很有趣，我的设想是做一个leaderboard，能够激发人们对于处理工单的无限潜能，哈哈哈哈。
  • Hosting：toolforge不能满足我的要求，CloudVPS不熟悉。将来打算支持图片上传，需要一个能挂载S3的环境，另外多区域host允许你把服务器托管在东京/首尔/LA。目前，服务器托管在Vultr的新泽西区上面。
  • 这个网站做成网站的形式，是为了新用户方便的注册+IPBE（也就是unblock-zh-ipbe的功能）。处理被长期封禁的用户在邮件列表中50-100封邮件那么长的申诉，并不是网站初衷。如果有人就是要在网站上申诉，管理员也选择在网站上处理，那我不会站出来阻止，但是如果网站上出现了对维基百科历史有一定意义的讨论内容，我觉得有应当抄送一份到邮件列表。
Bluedeck 2024年5月14日 (二) 04:12 (UTC)[回复]

另外还有两个别的需要讨论的问题：

  1. 工单是否永久保存？永久保存是目前的默认，而且邮件列表也是永久保存的。但是我觉得比如挂上“处理结束”标记90/180天之后永久删除相关信息这个是更安全的做法，想征求一下大家的意见。
  2. 开源：从一开始我就设想开源。这个项目有4个repo，其中3个可以在最近开源。一个需要我检查一下有没有API Key之类的物品遗落在代码中，然后才能开源。请期待。
  3. 共同参与：如果您想共同参与开发，或者参与对服务器的运维，欢迎在这里提出来。Bluedeck 2024年5月14日 (二) 04:49 (UTC)[回复]
感谢贡献，整体非常完善。如有需要可以协助维护。--Borschts™ 欢迎外带一碗罗宋汤 2024年5月14日 (二) 13:32 (UTC)[回复]
存档应保留，只是可以限制普通使用者存取。另外，也应考虑先行在站内撰写说明页面，或补充现有方针与指引不足，以便利用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月14日 (二) 15:05 (UTC)[回复]
注意到两点可以改善：
  • 无法创建账号者不应提供“我不想提供邮箱”的选项，创建账号时需填写对方电邮地址才能安全发送临时密码。如果不想提供邮箱则难以协助创建账号。
  • 需要添加提示文字，若不提供IP地址则申请有可能不获受理（始终审批IPBE时需要验证用户是否使用proxy）。
--路西法人 2024年5月15日 (三) 07:52 (UTC)[回复]

第二十二次动员令筹备讨论

原标题为：今年没有动员令？

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:动员令/第二十二次动员令。

如题。都快五月了，看来暂停一年--Dragoon17cc（留言） 2024年4月29日 (一) 22:08 (UTC)[回复]

？？？有这么早准备？--在下荷花，请多指教（欢迎签到） 2024年4月30日 (二) 01:14 (UTC)[回复]
去年还真的是三月底时就有人在问要不要举办了，不过当时一路讨论到5月中旬才有近一步筹备，尚不算多晚。另这时间感觉也适合问WP:非洲月今年有没有要办？--WiTo🐤💬 2024年4月30日 (二) 12:59 (UTC)[回复]
我去，中文维基人集体失忆了 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年4月30日 (二) 15:03 (UTC)[回复]
可以开始筹备了吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月30日 (二) 19:24 (UTC)[回复]
为了避免像去年那么赶，还是先把可能有需要讨论的资讯留在这好了：
  • 举办时间：若要沿用旧制，即“7月第二个星期六”至“9月第二个星期日”，则今年时间会是7月13日至9月8日，共57天，较去年（64天）少一周。
  • 另去年也有讨论但没后续的内容——是否需要将常常被纳入小动员令主题内的“亟需撰写”或“缺少来源”改为额外加成的方式，以让给其他更需要的主题？但就如当时所言，加分方式已经颇复杂，且“缺少来源”的计分并非一般计分方式可能有需要额外调整。—WiTo🐤💬 2024年5月1日 (三) 00:52 (UTC)[回复]
历史上，到了5月就差不多是时候筹备动员令了。但由于社群对于这回事越来越懈怠，我感觉今年不办还是可以的。先问想不想办，再问怎样办。如果决定要办，我建议把历年来动员令的规则合编为成文规则，这样以后社群就不用为了日期、计分等问题争论一番（但这估计会是一个大工程，明年才能用上）。另外就是处理常规问题，包括WiTo君提到“亟需撰写”、“缺少来源”加成悬而未决问题。--春卷柯南－发前人所未知 ( 论功行赏 ) 2024年5月1日 (三) 19:53 (UTC)[回复]
推到和亚洲月同期举办都不迟。--🎋竹生🎍 2024年5月2日 (四) 09:09 (UTC)[回复]
那就太迟了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月2日 (四) 12:32 (UTC)[回复]
姑且先简易架好WP:DC22的页面了，再看这边要讨论到什么程度再移过去讨论其他细节。--WiTo🐤💬 2024年5月2日 (四) 13:59 (UTC)[回复]

主题

本次我推荐哲学类及非虚构书籍类条目，两者都太冷门。--S叔 2024年5月1日 (三) 17:09 (UTC)[回复]
可以推荐色情类条目吗☺--日期20220626（留言） 2024年5月2日 (四) 02:20 (UTC)[回复]
可以的，但我相信会被电子游戏专题的エロ游戏专门编者镇压（若本人心血来潮参与的话那本人也算其中一分子）--S叔 2024年5月2日 (四) 02:35 (UTC)[回复]
哲学类不会有人写的。和DC19届“文学”类是一样的——中维很缺这个，但是您维没活跃编者写这个。倒不如将名额拿出来给其他范畴的。--Ghren🐦🕚 2024年5月4日 (六) 15:27 (UTC)[回复]
不然可以举办大中小混合动员令--August0422（留言） 2024年5月5日 (日) 08:37 (UTC)[回复]
兹推荐以艺人为主题，毕竟该主题之GA、FA甚至DYK皆非常少--August0422（留言） 2024年5月5日 (日) 08:41 (UTC)[回复]
{{law}}模板也有许多绿色连结，中维极缺法律类型之条目--August0422（留言） 2024年5月5日 (日) 08:42 (UTC)[回复]
哲学类个人认为似乎是一个过于专业的内容，受众或许过于狭窄，并不会有太多维基人编辑这些条目；
而非虚构书籍类条目很可能存在寻找参考资料的问题，或许在编辑上会提供一些阻力。--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月7日 (二) 15:44 (UTC)[回复]
哲学类我同意你的说法。不过证明非虚构书籍有关注度常用的门槛就是找两篇或以上独立可靠及以它为主题的书评，这比较简单。依序按访谈或著作前言写背景，按书评内容或自行写出书籍内容，再按书评写评价部分。--S叔 2024年5月8日 (三) 02:38 (UTC)[回复]
谢谢您的科普，本人对非虚构书籍的了解确实不深，但是由于本人并不非常喜欢阅读，或许无法在这类型中给出有意义且中立的看法，不过依然不胜感激！--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月9日 (四) 15:20 (UTC)[回复]
{{law}}模板也有許多綠色連結，中維極缺法律類型之條目--August.0422 2024年5月9日 (四) 10:44 (UTC)[回复]
若今年的非洲月直接告吹，那我想建议直接把这个范围放进中动员令的部分。另外个人感觉生物技术/医学相关条目貌似也较少。—WiTo🐤💬 2024年5月2日 (四) 01:30 (UTC)[回复]
鄙人推荐饮食和中国文化遗产作为本次动员令的主题，前者是因为少有新条目产出，后者则是由于近期除了几个文物保护单位FL外已很久没有高质量（GA、FA）的条目产出。--人间百态,独尊变态(讨论) 2024年5月2日 (四) 14:44 (UTC)[回复]
文化遗产不一定要限定在中国吧？毕竟有些国家的世界文化遗产都没条目，条目的空缺更严重。——BlackShadowG Slava Ukraini! 2024年5月3日 (五) 02:52 (UTC)[回复]
也不是不可以。--人间百态,独尊变态(讨论) 2024年5月3日 (五) 03:06 (UTC)[回复]
推荐“原创类”，可以改善动员令期间出现大量品质不佳翻译条目的问题。另外推荐生理学。—Y. Sean 2024年5月3日 (五) 03:05 (UTC)[回复]
冒昧地问一下，什么意思叫做“原创类”。我不是很理解这个主题的意思。--微肿头龙（留言） 2024年5月4日 (六) 14:30 (UTC)[回复]
“原创类”应该是指主编自行寻找参考资料，撰写的条目，不是从其他语文版本翻译来的条目--Wolfch (留言) 2024年5月4日 (六) 15:30 (UTC)[回复]
支持原创类，原创类应该分数加倍，因为自行搜集资料比翻译多出很多时间--Dragoon17cc（留言） 2024年5月12日 (日) 22:35 (UTC)[回复]
推荐交通类及交通设施条目，中文地区的交通类条目内容“非常丰富”，当中包括九巴条目的车牌资料，单凭一位编辑者处理根本没有可能完全清理及维持超过一千条条目品质；港铁相关条目也被公众质疑中维有意图淡化附来源的重要新闻事件。在非中文地区条目，绝大部分小型车站大多也只有一至二段，希望可以借此清理条目或补充内容。--唔好阻住我爱国（留言） 2024年5月6日 (一) 13:10 (UTC)[回复]
(＋)支持，此外还建议将地铁条目也加入考虑范围内，但是这些条目似乎本身的可查证性有一些问题……--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月6日 (一) 15:49 (UTC)[回复]
推荐家居和生活用品类的条目，对百科的重要性不言而喻，可是一直因为太常见而被忽视[1]，质量普遍十分差，没有注脚参考或者列出参考[2]，例如麻绳、鲍鱼刷、地暖系统、篮子、竹签、肥皂盒、棉袄等等只有不到两百字，缺少例如筷托（英语：Chopstick rest）、纸板盒（英语：Carton）、油炸锅（英语：Deep fryer）等条目，希望可以借此引起重视，改善扩充内容。--User:What7what8🏠 2024年5月7日 (二) 18:52 (UTC)[回复]
哲学（和心理学）不是不行，就怕曲高和寡。反对生医、法律，这里有多少用户具备足够的专业知识去写这些条目（而不是胡搞蛮缠）呢？艺人和交通过于热门，是否有必要预留主题名额呢？毕竟过往设立部分主题的目的是为了充实中文版缺乏的内容。另外可以考虑把主题范围扩阔一些，例如艺人归并到流行文化、日用品归并到应用科学或工业等。上面Y. Sean君提到鼓励原创的问题，令我想起十年前刘嘉和胡水果等用户的论争，我的个人论述有传送门，当时我就大致表达了自己的立场（今年好像我也在别的地方讲过，但忘了在那儿也懒得查）。最后，我去年提过把所有专项主题废除，改为自然科学、应用科学、社会科学、文史地哲四大主题，这可能跟上面提到的“大中小混合动员令”类似（但不肯定），而且又可以省略长篇累牍的讨论和免除自肥嫌疑，但这样做会动许多人的蛋糕（包括自己的），最后没什么声浪，无疾而终，反正社群接受才算。--春卷柯南－发前人所未知 ( 论功行赏 ) 2024年5月7日 (二) 20:23 (UTC)[回复]
这种大项目的合并还要一并动到计分方式之类的，如果没人主导修改的话今年恐怕是来不及修改（我个人没那方面的知识就没办法了），可能得等结束要成文化时再一并处理吧。不过我个人觉得可以试试，反正要调整完才知道有没有用。剩下主题的反对与否可以等投票期再决定，照前年时程大概会募集到六月中旬左右。--WiTo🐤💬 2024年5月8日 (三) 03:34 (UTC)[回复]

我归纳一下上面提到的一些条目类别：

  • 哲学类
  • 非虚构书籍
  • 色情
  • 流行文化（含艺人）
  • 法律
  • 非洲
  • 生物技术
  • 医学
  • 饮食
  • 文化遗产
  • 非翻译
  • 交通（含交通设施）
  • 应用科学（家居及生活用品）

此外，我不反对春卷柯南的四大主题方案，但是（如果采用的话）四大主题的计分方式可能需要另外商定，比如同属非翻译条目、待撰条目等是否可以额外计分。Sanmosa 全方贫工之联合 2024年5月12日 (日) 02:21 (UTC)[回复]

我的初步想法是让社群商定自然科学、应用科学、社会科学、文史地哲四大主题中哪些主题是社群现阶段较为侧重的，将那些较为侧重的大主题定为中动员令，其他大主题定为大动员令，但条目如果同属待撰条目，可以升格动员令级别，即由中动员令升格为小动员令，或由大动员令升格为中动员令。这样应该不会动到具体的计分方式。Sanmosa 全方贫工之联合 2024年5月12日 (日) 02:28 (UTC)[回复]
大致来看(＋)支持，不过我对待撰条目的态度倾向于简单做加分处理（比如×1.5或者×2），升格动员令级别看起来有点怪，毕竟这条目不是真的和某个中/小动员令主题挂钩。另所谓“原创”主题应该有明显定义，是要全文原创，还是只需要大部分就行？——Aggie Dewadipper 2024年5月15日 (三) 18:20 (UTC)[回复]
（我还是倾向于把“原创”称为“非翻译”）我认为只要能合理判断条目的核心内容并非翻译就能算成非翻译条目，虽然我并不支持非翻译条目额外加分的做法。技术上（以{{DC21/art}}为准）你说的那种“简单做加分处理”跟我说的升格动员令级别的具体操作是一样的，见下：
现时中、小动员令的计分方式相当于按大动员令的计分方式计分后直接乘以2或3，把type参数里填的数字换掉就行，甚至你填4也不会出现技术错误（上面我也特别演示了这部分）。至于乘以小数的技术可行性见下：
“升格动员令级别”这个说法可能不算太好，但我跟你想的东西大致上是一样的。我个人倾向于×2，顺道把小动员令的分数加成改为大动员令的4倍（这点我之前也有提议过）。Sanmosa 全方贫工之联合 2024年5月16日 (四) 00:26 (UTC)[回复]
@Dewadipper。Sanmosa 全方贫工之联合 2024年5月16日 (四) 00:27 (UTC)[回复]
感谢说明，那我对您的提议没什么异议了，(＋)支持。——Aggie Dewadipper 2024年5月16日 (四) 02:27 (UTC)[回复]
@春卷柯南、T45614631。Sanmosa 全方贫工之联合 2024年5月14日 (二) 09:08 (UTC)[回复]
我个人没意见，看社群共识（或主持人想法），而目前提议的主题多是人文类的主题就是了。--WiTo🐤💬 2024年5月14日 (二) 09:25 (UTC)[回复]
你这样说的话，我可能得争取当上主持人了。Sanmosa 全方贫工之联合 2024年5月14日 (二) 11:06 (UTC)[回复]
本人还要提议二战类--August0422 2024年5月16日 (四) 10:19 (UTC)[回复]
基于对语言学和文化多样性的关心，提议语言（学）类和民族类。我还想提议“中国大陆互联网”主题，因为很多此类内容虽影响范围仅限于中国大陆一地，但影响人数众多，堪称具备了相当的影响力；而且相关条目整体质量令人十分遗憾。--CuSO4 · 龙年大吉 2024年5月16日 (四) 21:08 (UTC)[回复]
如果采用春卷柯南的四大主题方案的话，所有较小的主题实际上都会被四大主题包含。Sanmosa 人人皆王 2024年5月17日 (五) 06:40 (UTC)[回复]

主持人

（占位）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月3日 (五) 13:56 (UTC)[回复]

以下参照DC20、21的时间、规则、提议调整：
主持人资格：
在提名期开始之前（2024年5月17日 (五) 00:00 (UTC)）取得延伸确认用户资格，在提名期开始之前一年没有受到封禁（不合理封禁除外）。
提名规则：
  • 可以自荐或以他荐方式提名，他荐者仍须取得被提名者本人在提名时间结束前（2024年5月31日 (五) 00:00 (UTC)）的明确同意，否则视为拒绝该提名。
  • 每条自荐、提名、谢绝被提名告知或其他相关言论后必须签名，否则视为无效。
时程：
提名期：2024年5月17日 (五) 00:00 (UTC)起至2024年5月31日 (五) 00:00 (UTC)止。
冷静期：2024年5月31日 (五) 00:00 (UTC)起至2024年6月5日 (三) 00:00 (UTC)止。
投票期：2024年6月5日 (三) 00:00 (UTC)起至2024年6月12日 (三) 00:00 (UTC)止。
投票资格：
  • 投票者应在投票开始之前成为延伸确认用户，且未有一年内被禁止编辑站务页面（不合理封禁除外）的纪录。每人只可投票一次，但可在选举期内改票，改票次数不限。候选人不可以给自己投票。
  • 当选主持人的支持票应超过其总票数的2/3，且支持票数超过反对票数至少8票。
  • 每位候选人可以提供一份约100字的自述供投票人参考。
  • 在日后建立的表格中投票。可以投支持、中立、反对票。支持票，请用〇表示；反对票，请用×表示；中立票，请用=表示。也可以把其中一格留空，不给某候选人投票（不计入总票数）。
  • 废票请以红色标示。

以上调整仅有时间部分及DC20筹备纪录中所说“过去一年内被禁止编辑站务页面的用户不得参选或投票”，如果确定没问题想在稍晚后就开始公示该时程。但主持人跑路问题可能需要社群共识，去年如玖宸阁下所说的“可以请主持人们自行讨论决定是否给予跑路主持人军师头衔”的提议我个人觉得还挺好的。—WiTo🐤💬 2024年5月6日 (一) 03:55 (UTC)[回复]

现就该时程及规则（不含跑路处理一事） 公示7日，2024年5月14日 (二) 03:57 (UTC) 结束。—WiTo🐤💬 2024年5月7日 (二) 03:58 (UTC)[回复]
公示已通过。不过提名是要在这里提还是要改到讨论页内啊？--WiTo🐤💬 2024年5月14日 (二) 05:13 (UTC)[回复]
怎说呢。我承认上届我参与比较少，原因是脚本太难用了。经常就是我审完一个条目，然后不知道哪处的参数填错，又或者没编辑到哪一个页面，结果要全部回退由其他人处理。结果就不太敢审条目了。如果可以简化一下程序，相信参与主持人意愿也会比较高。去年好像没有“自行讨论是否给予跑路主持人军师头衔”的过程，结果好像是自己颁给自己来着的。考虑到自己参与工作比较少，我没有给自己的用户页加“军师”的头衔就是了。--Ghren🐦🕓 2024年5月16日 (四) 09:00 (UTC)[回复]

自荐与提名区

没有人自荐或提名他人吗？那我就自荐了。Sanmosa 人人皆王 2024年5月17日 (五) 06:42 (UTC)[回复]

规则

（占位）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月3日 (五) 13:56 (UTC)[回复]

我想问一下，DC条目需要至少3500字节的规则是谁在何时定的？Sanmosa 全方贫工之联合 2024年5月16日 (四) 00:30 (UTC)[回复]
新条目字节限制是随时间增加的，大概自DC4起有2000字节限制、DC9变成3000字节，最后一次应该是在DC12经由投票决定变成3500字节的（当时总结该次投票的是小跃阁下）。--WiTo🐤💬 2024年5月16日 (四) 03:13 (UTC)[回复]
考虑到DYK的要求是3000字节，我建议把DC条目的最低要求revert回3000字节。（另一方面，对于只有六个人参与的投票到底能不能达到任何有效的结论，我存在很大的疑问）Sanmosa 全方贫工之联合 2024年5月16日 (四) 04:44 (UTC)[回复]

其他

（占位）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月3日 (五) 13:56 (UTC)[回复]

举办时间部分，我个人想提议使用与之前数次动员令相仿的举办时间，即7月13日至9月15日，共64天。（有稍微查了一下，至少自DC12起都是63~65天左右的长度，DC16当时也有类似问题而最后决议多一周，惟当时惯例是7月第一个星期六起至9月第一个星期日结束）之后如要像春卷柯南阁下所说要将之后的动员令合编为成文规则的话，也会比较有传承性，就是“7月第二个星期六”起至“9月第二个或第三个星期日”结束，补至约64天上下的长度。--WiTo🐤💬 2024年5月4日 (六) 04:34 (UTC)[回复]
以往选择这个日期，大多都是因为这是学生的暑假，有利维基人工作吧。把日期向9月后推似乎就不太达到这个目标？--HW（讨论 贡献） 2024年5月5日 (日) 15:50 (UTC)[回复]
@Waihorace：挪回之前的7月第一个星期六也可考虑。过往（DC18）延后到第二周似乎是因受到疫情影响后延，并一路维持至DC21，现在可能是个合适的时机，将其提回原本的时间？但这样筹备可能得快一点了。
还望其他人能提出看法，目前大概是这几个选项可考虑：
  • 7月6日至9月8日，共64天
  • 7月13日至9月8日，共57天
  • 7月13日至9月15日，共64天
--WiTo🐤💬 2024年5月6日 (一) 03:06 (UTC)[回复]
非常抱歉本人并没有参与过动员令的相关讨论，毕竟也没有加入维基多久，如果有些地方存在冒犯请各位见谅
本人认为7.6-9.8是一个相对更好的选项，正如HW所说，这个时间更大地覆盖了暑假时间。不过似乎这几个时间在宏观上没有太大区别（微观上可能存在个人在某段时间内有事？），感觉也很难有一些合理的论据来讨论，干脆今年就将日期选一个定下来（也是各位正在做的事？）
我也不知道发生了什么，似乎我写的剩下的内容没发布出去……只能来编辑下源代码，但绝没有改变各位的留言，当然，签名日期是删了重签的
个人根绝，因为宏观上区别不大，所以似乎投票等等方式都没啥用，本人也没啥想法，只是提供一点点思考，还请各位多多包涵！——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月6日 (一) 16:08 (UTC)[回复]
(！)意见：WP:DC17也是7月6日00:00（UTC）至9月8日23:59（UTC），也是65日。个人认为只要是9月第二个星期日结束便可以。即是今年的DC为7月第一个星期六开始，明年可以回复至7月第二个星期六开始。--132.234.229.20（留言） 2024年5月7日 (二) 04:27 (UTC)[回复]
支持IP的提议 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月7日 (二) 07:41 (UTC)[回复]
(！)意见这样可能会导致每年都需要对时间做一次重复的讨论甚至是争辩。个人认为相比于直接确定时间带来的一些固化所产生的后果，每年一次的讨论看起来更加不必要。--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月7日 (二) 15:41 (UTC)[回复]
相对于客栈煮的其他话题，每年讨论一次动员令日期花费的时间实在是微不足道 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月14日 (二) 01:38 (UTC)[回复]
那确实是如此，不过之后如果要固定化的话也比较省事。--WiTo🐤💬 2024年5月14日 (二) 02:59 (UTC)[回复]
就讨论方向看来有共识，所以就以“7月6日至9月8日，共64天”一案 公示7日，2024年5月21日 (二) 05:19 (UTC) 结束。--WiTo🐤💬 2024年5月14日 (二) 05:19 (UTC)[回复]
应该确实有共识
唯一就是希望能够将这个时间通过社群讨论的方式确定下来，以免往后再出现此类浪费时间的无意义讨论。不过本人并不熟悉相关流程，请问是否有什么办法将其固定呢？--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月15日 (三) 12:47 (UTC)[回复]

何时应该使用{{Dead Link}}模板？

本主题或以下段落文字，在讨论结束后应存档至Talk:嘉义市先期交通转运中心。

如题，最近遇到了一个例子是观光署的一个网站taiwan-askme.tw（慎入），原网址仍然可用，但是会被重定向到色情网站。这时候敝人感觉应该直接移除，但又好像符合{{Dead link}}在条目中保留的标准，不知如何是好？--Y. Sean 2024年5月2日 (四) 12:15 (UTC)[回复]

建议这样改，存档页面作为url。不过，这个来源是否足够有用？--YFdyh000（留言） 2024年5月2日 (四) 12:59 (UTC)[回复]
借问站的官方网站，既然是官方网站可以保留吧。--Y. Sean 2024年5月2日 (四) 13:10 (UTC)[回复]
我是说其中哪些内容使它要作为不可替代的来源的，没有更好的吗。--YFdyh000（留言） 2024年5月2日 (四) 13:14 (UTC)[回复]
内容的话没有用到，只有最后放了外部链接。--Y. Sean 2024年5月2日 (四) 13:22 (UTC)[回复]
没有用到的来源可以删掉。不需要作为外部链接吧，仅仅一个过时页面。--YFdyh000（留言） 2024年5月2日 (四) 13:26 (UTC)[回复]
CS1系列模板有个专门的参数：url-status=usurped。--GZWDer（留言） 2024年5月8日 (三) 12:02 (UTC)[回复]

关于第三次非洲月

去年非洲月在6月举行，取得了不少条目贡献，本人有意在今年同期继续举办非洲月，不知各位意向如何？

另Ping去年的主持人和活跃参与者@A Chinese ID@Tokisaki Kurumi@Newbamboo@Allervous@Alankang@Oscar0123@Baomi@BrianBYBYBY@AOrdinaryEditor@桃花影落飞神剑@T45614631@Nostalgiacn，如有打扰非常抱歉。——Aggie Dewadipper 2024年5月4日 (六) 22:04 (UTC)[回复]

(＋)支持虽然我很好奇为什么今年也会是6月而不是5月。--Allervous初音ミクのセーラー服 2024年5月4日 (六) 22:07 (UTC)[回复]
同上，我也想问。不过整体上是支持办的（虽然个人今年六月较忙恐生不出完整条目）。--WiTo🐤💬 2024年5月5日 (日) 00:42 (UTC)[回复]
(＋)支持在哪个月都好--苞米(☎)💴 2024年5月5日 (日) 00:45 (UTC)[回复]
(＋)支持，但可惜今年各方面压力都比较大，在下确已经抽不出时间来参加了；深感抱歉。--  2024年5月5日 (日) 15:45 (UTC)[回复]
(＋)支持，预祝成功。----FradonStar|八闽风云 2024年5月7日 (二) 00:56 (UTC)[回复]

：目前来看似乎没有反对意见，那暂定非洲月于6月1日0:00至6月30日23:59（UTC）举行，考虑到时间较为紧迫就先擅自在底下开始主持人招募了。话说在6月举办应该是没人想起来 囧rz……。——Aggie Dewadipper 2024年5月6日 (一) 06:34 (UTC)[回复]

今年就算了，不过来年或可考虑合并动员令与非洲月，集中有限的编辑量能。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月12日 (日) 02:56 (UTC)[回复]

主持人招募

烦请有意担任本年非洲月主持人者在下方留言示意。招募期暂定于5月20日 00:00 (UTC)结束。——Aggie Dewadipper 2024年5月6日 (一) 06:34 (UTC)[回复]

来了。今年比较没有空写条目，但打杂，帮忙看条目还是可以的--A.K. 留言※签名 2024年5月6日 (一) 07:17 (UTC)[回复]
以及，我本人也有意主持此次活动。——Aggie Dewadipper 2024年5月7日 (二) 00:59 (UTC)[回复]
我，今年我暑假不用做事--August0422（留言） 2024年5月7日 (二) 08:29 (UTC)[回复]
阁下之前参加过非洲月吗...--人间百态,独尊变态(讨论) 2024年5月12日 (日) 08:11 (UTC)[回复]
这位阁下（的账号）今年年初才开始编辑，是一定没有的。--WiTo🐤💬 2024年5月12日 (日) 08:48 (UTC)[回复]
6月中旬过后大概有时间，争取一下 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月14日 (二) 01:36 (UTC)[回复]
行，我也兼一下非洲月主持人吧，毕竟当初办非洲月就是我提议的，另一方面我有当亚洲月主持人的经验。Sanmosa 人人皆王 2024年5月17日 (五) 15:06 (UTC)[回复]

请求讨论，人少了不行，请大家都来说，直到让我意识到是我的理解不对为止。

关于两个分类，寒吉的回退我不认可，以下是链接。 https://zh.wikipedia.org/w/index.php?title=Category:%E7%B6%9C%E5%90%88%E9%81%8B%E5%8B%95%E6%9C%83%E7%83%8F%E5%85%8B%E8%98%AD%E4%BB%A3%E8%A1%A8%E5%9C%98&action=history https://zh.wikipedia.org/w/index.php?title=Category:%E7%83%8F%E5%85%8B%E8%98%AD%E5%90%84%E5%B7%9E%E4%BA%BA%E7%89%A9&action=history --Caiptony（留言） 2024年5月9日 (四) 10:34 (UTC)[回复]

@Caiptony：Special:Diff/82575429，因为已在“乌克兰体育组织”。“依一级行政区划分的人物”有“依一级行政区而作的分类”父分类。Wikipedia:页面分类#几点重要的共识第二条，虽然说的是条目。建议寒吉写上回退理由。--YFdyh000（留言） 2024年5月9日 (四) 10:40 (UTC)[回复]

有关被永久封锁的IP

WP:COLLATERAL指出在绝大部分的情况下不应不限期封锁IP地址，但是现在仍有部分IP地址被永久封锁。即使是proxy也仅封锁2年，但是仍有其他IP被永久封锁。由于IP地址可能会变动，故我请求管理员们对有关IP的封锁期限作出复检。--165.86.81.101（留言） 2024年5月10日 (五) 09:06 (UTC)[回复]

除了基金会那几个外似乎都有些太久了。——暁月凛奈 (留言) 2024年5月10日 (五) 09:47 (UTC)[回复]
同意。--桐生ここ★[讨论] 2024年5月10日 (五) 12:20 (UTC)[回复]
8.214.0.175本身还有一个全域的proxy段封（理由是这是阿里云的地址段），可能是确凿的持久proxy（？）；240a:61:1a1:d001:4c46:fcff:fe11:e245是散发广告，但是ipv6封/128意义不大吧，起手/64吧；37.229.253.133的理由是长期跨维基破坏。除了第一个还有全域搭配的，其他或者先保持一年的时间，到时有变动在看？——Sakamotosan路过围观 | 避免做作，免敬 2024年5月11日 (六) 00:27 (UTC)[回复]
已解除除wikimedia IP之外的封禁--百無一用是書生 (☎) 2024年5月11日 (六) 02:51 (UTC)[回复]

针对kenny023见习编辑的处置提出质疑

https://zh.wikipedia.org/wiki/User_talk:Kenny023

https://zh.wikipedia.org/w/index.php?title=%E8%8F%8A%E9%99%BD%E7%94%BA&diff=prev&oldid=82391341

https://zh.wikipedia.org/w/index.php?title=%E8%87%BA%E7%81%A3&diff=82456497&oldid=82454650

https://zh.wikipedia.org/w/index.php?title=User_talk%3AMafalda4144&diff=prev&oldid=82307148

如以上案例，kenny管理员有多次无缘退回他人编辑的纪录，其中也有以不当外合并段落为由退回的情况发生，然该情况并无违反任何规则，且先前经询问user:AT还有台湾维基社群脸书页面的管理员(我不确定它的账号)确无违反编辑规则，是该管理员过度解读。该管理员的用户讨论页面上也有数位认为他不当退回的编辑员，详情请见它的讨论页面。因此请求版上各位讨论kenny023是否有达到解任的标准。

--雪雨73（留言） 2024年5月11日 (六) 10:50 (UTC)[回复]

Kenny023不是管理员--Sinsyuan✍️🌏🚀 2024年5月11日 (六) 10:55 (UTC)[回复]
首先，Kenny不是管理员：再者，比起在客栈突然蹦出一句话就完了，好好阐述事情的经过及你的论点，对解决争议比较有效。--Y. Sean 2024年5月11日 (六) 10:56 (UTC)[回复]
@Sinsyuan@Y. Sean抱歉两位，因为网络问题，所以我也不知道为什么第一次没发成功--140.122.53.116（留言） 2024年5月11日 (六) 11:05 (UTC)[回复]
这个ip是我，因为网络突然故障只好切换--雪雨73（留言） 2024年5月11日 (六) 11:07 (UTC)[回复]
既然不是管理员就没什么好解任了（维基荣誉不能接任）。不过要提报到不当行为是你的自由。--Y. Sean 2024年5月11日 (六) 11:17 (UTC)[回复]
@Y. Sean了解，我会把这里的讨论砍掉，然后重新放上不当行为那边--雪雨73（留言） 2024年5月11日 (六) 11:21 (UTC)[回复]
您想表述的大概是回退员用户组？——暁月凛奈 (留言) 2024年5月11日 (六) 11:27 (UTC)[回复]

管理员选举候选人ASid通告

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:申请成为管理员/ASid/第4次。

我是此次管理员选举候选人ASid，很抱歉告诉大家一件事，原本RFA就让我压力很大，大家的提问让我的压力又更上一层楼（此处没有任何责怪之意），后续各位的提问我不保证我一定可以回答（大家仍可以继续提问题，我没有要拦著大家提问题的意思，即便我无法回答我还是会看），希望大家见谅，谢谢。

在原本的选举页我有在问题区的最底下放上留言，但我觉得我仍有必要来客栈给社群一个正式的通知，最后真的很抱歉，我的状况真的非常不好，这才出此下策，希望大家可以原谅我。--~~Sid~~ 2024年5月12日 (日) 03:13 (UTC)[回复]

请您保重。管理员申请提问负担向来是太大了！—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月12日 (日) 03:17 (UTC)[回复]
加油！我早就说过提问时间不要太长，结果没人理我。--0xDeadbeef (留言) 2024年5月12日 (日) 12:44 (UTC)[回复]
好像是我没读好方针。貌似一直以来提问期都是两周。所以我其实没说过提问期太长。--0xDeadbeef (留言) 2024年5月12日 (日) 13:02 (UTC)[回复]
此前引进安全投票时推动投票期与讨论期分离（不延长过久），相信是有点帮助。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月12日 (日) 17:12 (UTC)[回复]
加油啊。好好休息减轻压力。-千村狐兔（留言） 2024年5月12日 (日) 23:14 (UTC)[回复]

关于伪基百科一览中文维基人页面

同 Ericliu1912，该站只会视相关行为属招募真人傀儡，无助解决问题。再者，WP:DENY，公开讨论仅会增加该页面的关注度，亦对当事人可能造成二次伤害。考虑到此讨论无法解决问题且反而有害，故关闭之。另已移除相关连结。谢谢。--SCP-0000（留言） 2024年5月16日 (四) 18:06 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

伪基百科对于维基用户的诽谤已经不是一天的了。今天我把这个条目提出了去留投票。如果当中有用户觉得此页面具有侮辱性，请到该站注册用户并表达自己的意见（他们一定会考虑你们的意见）。L'Internationale, Sera le genre humain! ✏️ 2024年5月16日 (四) 13:34 (UTC)[回复]

附知以下用户：@Easterlies、MINQI、UjuiUjuMandan、Johnson.Xia、Cwek、Ohtashinichiro、日期20220626、葉又嘉、Lily135、LuciferianThomas、Hat600、Mys_721tx、Lanwi1、乌拉跨氪、Jimmy Xu、淺藍雪、AT、Shizhao、SCP-2000、范、Bagida520、SIridiuM28、MCC214、太刻薄、这个那、Softyu、Owennson、SickManWP、1F616EMO、GlenHelvetica、吳安昌、DarkWizardCody，你们都牵涉在此页面中，请考虑在此采取行动。L'Internationale, Sera le genre humain! ✏️ 2024年5月16日 (四) 13:48 (UTC)[回复]
你这样难道不等于在招募真人傀儡吗？除非你明确表达这只是当事人去表达意见，不是要干涉伪基内政。另外“一览中文维基人”其实复制自“中文维基人一览”，两篇条目都一样糟糕。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月16日 (四) 14:01 (UTC)[回复]
我没有伪基百科账号，所以我不会参与那个去留讨论页面。实在看不清有要去管的必要，个人认为强行去留言只会促成史翠珊效应，不仅删除页面不成，反而令伪基的用户更新那个页面更频繁，助长了所谓的诽谤行为。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年5月16日 (四) 15:41 (UTC)[回复]
某LTA在那边还张贴大量用户隐私。－千村狐兔（留言） 2024年5月16日 (四) 15:44 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

其实伪基百科就是用来发泄情绪的--Dnaimfz（留言） 2024年5月17日 (五) 05:39 (UTC)[回复]

取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”