跳转到内容

英文维基 | 中文维基 | 日文维基 | 草榴社区

维基百科:机器人/申请/存档/2021年/获批的申请

维基百科,自由的百科全书

This is an archive page. For new bot request, please to go Wikipedia:机器人/申请 and follow the instructions there.

该页面会全保护,故需要管理员机器人。其他管理员可以在设定页面排除特定模板以免被全保护。请参阅该页面的历史来查看范例编辑。--Xiplus#Talk 2021年2月1日 (一) 12:13 (UTC)
批准测试运作,看一下测试效果如何?--百無一用是書生 () 2021年2月1日 (一) 12:50 (UTC)
测试已完成,因为MediaWiki模板更动没那么频繁,所以我做了一个模拟的测试,首先在MW空间内加入了模板{{沙盒}},机器人就将该模板加入了连锁保护页,然后我将其加入排除规则机器人就将其移除,希望这样的测试足够。--Xiplus#Talk 2021年2月4日 (四) 13:17 (UTC)

 正式批准运作 --百無一用是書生 () 2021年2月7日 (日) 12:31 (UTC)

目前Category:非中文重定向被大量天文学临时编号重定向占据,难以维护。本人按照\d{4} [A-Z]{1,2}\d*过滤出这些重定向列于User:Steven_Sun/List_test2中,部分特殊编号列于User:Steven_Sun/List_test3中。此项作业将这些重定向由Category:非中文重定向移动至Category:天文学临时编号重定向(尚未建立)。执行命令为:python pwb.py category -file:filename -to:天文学临时编号重定向 --Steven Sun留言2021年2月7日 (日) 10:56 (UTC)
方案不可行。这些重定向中的Category:非中文重定向是通过模板{{非中文重定向}}引入的。--Antigng留言2021年2月7日 (日) 11:49 (UTC)
那是否可以用{{Redirect template}}建立一个可自动归类的模板,再使用mw:Manual:Pywikibot/replace.py将{{非中文重定向}}替换为新建立的模板?如:python pwb.py replace -file:filename "{{非中文重定向}}" "{{天文学临时编号重定向}}"--Steven Sun留言2021年2月7日 (日) 12:19 (UTC)
有可能可行。但是最好在编辑之前检查重定向目标是否确实为天体条目,以进一步降低错误的可能性。--Antigng留言2021年2月8日 (一) 03:44 (UTC)
初步检查了一遍,应该没有非天体条目的重定向。--Steven Sun留言2021年2月9日 (二) 09:07 (UTC)
批准测试运作(100次编辑)--Antigng留言2021年2月9日 (二) 09:43 (UTC)
测试完成,未发现错误。--Steven Sun留言2021年2月10日 (三) 14:47 (UTC)
请行政员看一下还有没有问题,似乎可以批准授权。@ShizhaoStangWong128hkManchiuKegnsATAlexander Misel--Antigng留言2021年2月11日 (四) 02:40 (UTC)
完成--千村狐兔留言2021年2月11日 (四) 16:17 (UTC)
撤销许可。--Xiplus#Talk 2022年10月11日 (二) 09:29 (UTC)
  • 状态 已批准
  • 操作者:Xiplus#Talk
  • 提请时间:2021年2月2日 (二) 01:49 (UTC)
  • 自动化程度:全自动
  • 程式语言Pywikibot
  • 用途:展开讨论页面中章节标题内的模板
  • 原始码连结:Github
  • 编辑时段及频率:每天数次
  • 受影响页面:设定页控制
  • 遵守机器人规范否,由设定页控制
  • 已有机器人权限:
许多人会在章节标题内使用模板,但是这将导致编辑章节时自动产生的编辑摘要中的章节标题连结无法连结到该章节(范例),故设计此机器人来展开章节标题内的模板,展开模板后,编辑该章节产生的编辑摘要即可连结到该章节。范例编辑 1 2 3。--Xiplus#Talk 2021年2月2日 (二) 01:50 (UTC)
章节标题使用{{CHN}}等国家、国旗模板的怎么办,展开将导致无法统一更新(如南/北朝鲜命名之事)。对章节标题中违规使用的<ref>内的模板是否处理良好。--YFdyh000留言2021年2月7日 (日) 11:04 (UTC)
@YFdyh000:本工作仅处理极少数的讨论页面,即互助客栈。--Xiplus#Talk 2021年2月7日 (日) 11:12 (UTC)

快速批准运作 --百無一用是書生 () 2021年2月20日 (六) 07:04 (UTC)

批准测试运作(50次编辑) --百無一用是書生 () 2021年2月20日 (六) 06:31 (UTC)
  • 测试已完成
  • 测试范围:所有条目列表前20页(共100,000个条目),涵盖各种类型的条目;
  • 结果:第一次尝试:185笔编辑、第二次尝试:105笔编辑
  • 发现的问题:该任务利用启发式算法尝试修正不正确的日期,其描述能力超过一般正则表达式(即:III型文法),可以比较好地应对各种不正确使用的情况,但如早前的申请所述,可能会导致一些意料之外的错误处理;经人工复查,测试编辑存在下列问题
      1. 修正后的日期格式一律为ISO格式,这可能不符合英文站MOSDATE指引关于日期格式应“先到先得”、“全条目统一”的要求;然而本站MOSDATE指引无此“先到先得”之要求,且本站绝大多数条目选用ISO格式的日期,更正为ISO格式导致条目格式统一的概率远大于破坏条目格式统一的概率;过往讨论和引用模板的提示亦倾向于使用ISO标准格式。考虑到两站共识的差异,本次任务若批准,仍将维持修正目标为ISO标准格式,不考虑修改;
      2. 修正后可能会删去一些不相关的字串,如Special:Diff/64406914,该等修改并无害处(因人工处理结果也是直接删去这些字串),不考虑改进;
      3. 下列七个条目存在因出版物编号而导致的错误修正,已全数回退:7次回退
  • 补救方式:在修正不合规范的日期串之前,强制排除具有出版物编号意味的字符(版、卷、期、印、刷、稿、编、第):若待处理日期串含有上列任何一个字符,则直接跳过不送入上述启发式算法处理;
  • 修正结果:工作范围与第一次尝试相同的第二次尝试没有导致类似的错误编辑
  • 结论:本次测试分两个阶段,工作范围是条目列表前100,000条,涵盖各种类型的条目中各种类型的日期错误,经修正后可认为连续编辑270次无明显错误,按此比例推算,全部处理完产生的错误编辑总数不超过25笔。日后会加强人工抽查,若发现其它意料之外的错误模式会及时修正。望予以批准。--Antigng留言2021年2月20日 (六) 17:53 (UTC)
    其实就是选择宁可漏掉也不出错,还是宁肯出错也不漏掉。我认为,正则似乎更不容易出错,但可能漏掉?你的算法似乎会出错,但不会漏掉?不知道我的理解对不对?--百無一用是書生 () 2021年2月21日 (日) 11:58 (UTC)
    • 可以这样理解。过去Liangent-bot采用正则表达式去匹配特定的错误模式(如匹配"yyyy/mm/dd"、"yyyy年0m月dd日"这两种特定的错误格式,将其分别修正为"yyyy-mm-dd"和"yyyy年m月dd日"),假阳性率较低、但假阴性率较高;本人则是试图读入待修正的日期字串,去猜测其中数字的含义(比如,一个四位数后跟着一个“年”字,就猜测这是一个年份)从而提取出年月日参数,以标准格式输出,理论上可能有较高的假阳性率(猜错),但同时也能应对诸如这类事先难以预料的误用。--Antigng留言2021年2月21日 (日) 12:29 (UTC)
      我总觉得在需要修改的时候,我会选择宁可漏掉也不出错--百無一用是書生 () 2021年2月22日 (一) 02:26 (UTC)
      上面分析的是理论情况。实际上无论选择何种策略都要保证尽可能低的假阳性率和假阴性率,根据测试结果将事先没有考虑到的意外情形纳入考量。例如,采取第一种策略的时候,需根据测试结果补充冷门的错误日期格式,以降低假阴性率。采取第二种策略的时候,需根据测试结果排除意料之外的假阳性案例。
      具体就这个任务而言,按上述补救方法排除特定字符以后在整个主名字空间空运行产生的所有待修正的日期字串如该页面所示,共1.6万条。经人工检查未发现明显的错误修正,因而可以认为其在处理存量任务上是不会因为确保不漏掉而导致出错的。至于增量方面,早期获批的Wikipedia:机器人/申请/Antigng-bot/30也使用完全相同的算法处理格式错误的日期字串,近若干月的正式运行结果经人工检查后亦无明显错误处理,故可以认为增量任务导致意料之外的错误模式的可能性很小。何况这类错误即使发生,也很容易通过定期的人工抽查而排除。--Antigng留言2021年2月22日 (一) 13:44 (UTC)
 正式批准运作 --百無一用是書生 () 2021年2月23日 (二) 03:03 (UTC)
无限期部分封锁应该不能视为已封锁;另外有必要移除Uw-username吗?这似乎会移除他人的留言,而且这应该是错误使用了模板。--Xiplus#Talk 2021年3月4日 (四) 07:01 (UTC)
@Xiplus会加入对封锁状态的检测;如果不移除模板的话,不排除会有用户手动加入并且错误使用模板,不如将uw-username的引用直接改为不带分类的文字?--Hamish 2021年3月5日 (五) 13:21 (UTC)
后者没问题,就这么做吧。--Xiplus#Talk 2021年3月5日 (五) 13:35 (UTC)
@Xiplus那就这样吧。--Hamish 2021年3月5日 (五) 14:16 (UTC)
我建议替换成 {{subst:uw-username|category=}} 比较好。--Xiplus#Talk 2021年3月5日 (五) 14:38 (UTC)
@Xiplus好主意。--Hamish 2021年3月5日 (五) 15:08 (UTC)
批准测试运作分类内全数处理。--Xiplus#Talk 2021年3月5日 (五) 15:18 (UTC)
@Xiplus测试编辑已完成,烦请复核。--Hamish 2021年3月5日 (五) 21:16 (UTC)
@Hamish代为调整状态,并移动对应章节,若有误请修正。 Willy1018留言2021年3月6日 (六) 04:30 (UTC)
 正式批准运作,编辑摘要记得改成人类可读的中文。--Xiplus#Talk 2021年3月6日 (六) 06:19 (UTC)

本申请将取代Wikipedia:机器人/申请/A2093064-bot/22的工作,除了减少编辑量,模组化资料还可用在其他地方等好处。--Xiplus#Talk 2021年3月7日 (日) 02:55 (UTC)

快速批准运作 --百無一用是書生 () 2021年3月8日 (一) 07:59 (UTC)

已经写好了脚本User:Non-robot/sameimage.py,用来列出与commons同名的文件,测试页面见User:Sz-iwbot/sameimages,正式批准后会用User:Non-robot运行并保存在Wikipedia:资料库报告/与维基共享资源同名的文件。为提高维护可见度,故此用不需要bot权限的User:Non-robot运行--百無一用是書生 () 2021年2月20日 (六) 06:48 (UTC)

目前列表比较长,难以人为维护,请问能否进一步分类,比如将文件根据本地的自由/非自由版权状态分成两类,和/或运行相应的算法比较两边的图片是否一致或相似?--Antigng留言2021年2月20日 (六) 11:24 (UTC)
这个只是用来比较同名的文件,以便不会因为本地存在同名文件而无法使用c区的图片。比较图片是否一样或相似不是我这个任务考虑的范围。(是否相似的算法难度太大,我技术不够也做不到)。至于进一步分类,我认为没有必要,毕竟这个列表的目的是为了防止同名,版权状态不是要考虑的--百無一用是書生 () 2021年2月20日 (六) 11:33 (UTC)
而且,如果维护得当的话,这个列表只会越来越短--百無一用是書生 () 2021年2月20日 (六) 11:35 (UTC)
@Antigng:确实在维护的情况下该列表应只有少量项目,且供人进一步处理有其意义,拟批准,是否有其他意见?--Xiplus#Talk 2021年3月18日 (四) 11:18 (UTC)
@xiplus无意见。--Antigng留言2021年3月18日 (四) 14:42 (UTC)
 正式批准运作。--Xiplus#Talk 2021年3月18日 (四) 14:48 (UTC)
  • 状态 撤销许可
  • 操作者:海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月20日 (六) 14:20 (UTC)
  • 提请时间:2021年3月20日 (六) 14:21 (UTC)
  • 自动化程度:有监督的半自动
  • 程式语言AWB
  • 用途:通过AWB将位列于分类:未评级辽宁条目中的条目予以标记并评级,并通过AWB将未分类到“分类:未评级辽宁条目”(不包括已评级的)的辽宁条目进行分类。
  • 原始码连结:
  • 编辑时段及频率:1分钟11-20条(利用AWB测试时确认。)
  • 受影响页面:所有未评级的讨论页(辽宁专题),且在可预见的未来内均定期使用本机器人执行本任务,并自动评级一些小条目。
  • 遵守机器人规范无关
  • 已有机器人权限:

以下是上次申请的讨论

另外,本机器人目前没有AWB权限,将会在允许测试的时候申请AWB。--··自·由·的 2021年1月29日 (五) 04:41 (UTC)

以上是上次申请的讨论


  • 请求重启:我主账号申请机械用户,挂了请求协助模板,一个月没人处理。然后又考虑到在可预见的未来内定期使用本机器人,因此我希望得到这个机器人的授权。(有人和我吐槽我直接上AWB太洗版了)以上。--海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月20日 (六) 14:20 (UTC)
  • 接IRC讨论,批准该机器人测试运作,要求:
    1. 于用户子页列出所有待评级条目以及拟评级别;
    2. 示范性编辑25次。

--Antigng留言2021年3月20日 (六) 14:57 (UTC)

完成。测试已完成。所有待评级页面(本次任务)皆已列于CAT:辽宁行政区划小作品,不符合小作品页面已于人工检测时移除,请复核。--Mikasa-bot留言2021年3月21日 (日) 01:03 (UTC)
当获得授权后,我将会开始处理列于此CAT中的页面。现时任务已经结束。--Mikasa-bot留言2021年3月21日 (日) 01:07 (UTC)
注:排除 韩州

金州 (辽宁) 莲花镇 (开原市) 科尔沁左翼前旗 炮台街道 ‎ 李石街道 望海寺街道 ‎ 对桩石街道 ‎

海の向こうは敌だ!|欢迎订阅维猫报! 2021年3月21日 (日) 01:43 (UTC)

--Antigng留言2021年3月30日 (二) 07:20 (UTC)

(~)补充:相关讨论已存档至Module_talk:Citation/CS1#修改CS1系列引文格式模板Module_talk:Citation/CS1#关于引文模组未知参数的清理方式。-Peacearth留言2021年5月8日 (六) 14:53 (UTC)
如果出现“urlstatus参数值实质等同于"live",且deadurl参数实质等同于"yes"或"y"或"true"”或“urlstatus参数值实质等同于"dead" 且deadurl参数实质等同于"no"”的矛盾情况,或者是其他重复参数之矛盾情形,是否考虑处理?-Peacearth留言2021年5月8日 (六) 14:53 (UTC)
@和平奮鬥救地球,暂不处理,因为导致矛盾的情形很多:可以是用户不小心填错,也可能是IABot抽风。机器人没法判断是哪种情况,需要人工检查。若将来发现其他可靠的错误模式(例如,IABot处理的某一批页面都是错的)再考虑另案处理。--Antigng留言2021年5月10日 (一) 03:21 (UTC)
了解。 批准测试运作(100次编辑)。-Peacearth留言2021年5月13日 (四) 19:49 (UTC)
测试已完成,经人工检查没有发现错误。--Antigng留言2021年5月14日 (五) 03:42 (UTC)
经复查无误, 正式批准运作。-Peacearth留言2021年5月14日 (五) 19:17 (UTC)

--Kanashimi留言2021年3月18日 (四) 09:43 (UTC)

@Kanashimi,有两个(?)疑问
  1. 这里这里分别直接搜索Special:前缀索引/Mediawiki:Conversiontable/Category:公共转换组模板下面的所有页面,并认为其均是合法的转换组页面涵盖了主空间的转换规则。然而前者之下尚有MediaWiki:Conversiontable/zh-hans/ns8等非主空间的转换规则;后者亦有可能导致将来有用户建立了一个草稿(如Module:CGroup/Physics/draftModule:CGroup/Physics/sandbox),其中的转换规则也会被机器人认为是现行的转换规则。不知道这会不会导致过度清理?
  2. 关于内文中转换规则的清理,是否会导致其它转换错误的出现?例如“X-{关于Y的转换规则}-”被清理成“XY”,但实际上“XY”会匹配某一条错误转换的规则,前面的重复转换乃有意为之,以避免错误转换的出现。尤其是考虑到阁下将来有意加入全局转换表的情况下,如何避免此类问题的发生?--Antigng留言2021年4月9日 (五) 02:15 (UTC)
  1. 清理转换规则时,只会转换有确实引用到的规则。例如当明确引用{{NoteTA|G1=Physics/draft}}才会清理Module:CGroup/Physics/draft中有的规则。也因此不会清理Special:前缀索引/Mediawiki:Conversiontable/下面的规则。
  2. 感谢提醒。这是一个选词的问题。我们可以选用一个不会被转换的组合。这边已修改原始码,检测与前一段、后一段文字合起来时,会不会被转换。有合适的才做转换,否则放弃转换。 --Kanashimi留言2021年4月9日 (五) 04:57 (UTC)
感谢释疑和修正。 批准测试运作(100次编辑),应尽可能涵盖目前准备处理的三类情形。--Antigng留言2021年4月9日 (五) 16:00 (UTC)
都快跑一半的文章了,看起来可能没有1000篇。 --Kanashimi留言2021年4月10日 (六) 00:44 (UTC)
@Kanashimi该条转换规则去除之后片名无法正常转换。--Antigng留言2021年4月10日 (六) 16:48 (UTC)
感谢帮忙检查。之前没注意到单向转换规则的正规化问题。现在程式码已经修正,经测试会跳过这种情况不删除。--Kanashimi留言2021年4月11日 (日) 01:47 (UTC)
有一个小疑问,如果页面内定义的转换规则和公共转换组的规则不一样的情况,机器人会怎么处理。比如杜拜里转换规则在简体部分定义了zh-hans:杜拜;zh-cn:迪拜,但在Module:CGroup/地名里简体部分是zh-cn:迪拜;zh-sg:杜拜。这种显示效果应该是一样的,不知道机器人会不会清理。--𝓧𝓩𝓣𝓓𝓮𝓪𝓷𝕋𝕒𝕝𝕜2021年4月24日 (六) 20:32 (UTC)
只会消除正规化后完全相同的转换规则。因此就本例来说不会被更动。--Kanashimi留言2021年4月24日 (六) 21:29 (UTC)
明白了,感谢解答 --𝓧𝓩𝓣𝓓𝓮𝓪𝓷𝕋𝕒𝕝𝕜2021年4月25日 (日) 01:31 (UTC)
@Antigng先跑两礼拜人工检核如何? --Kanashimi留言2021年6月15日 (二) 10:38 (UTC)
很抱歉没注意到,之前测试完后就一直常规执行中。不过看了一下并没有什么问题,也没有人反应有错误。看起来应该是没太大问题。 --Kanashimi留言2021年6月30日 (三) 12:06 (UTC)
编辑摘要中注明的规则是从条目中移除的吗?可以注明是与哪张转换表重复的吗?--Xiplus#Talk 2021年8月19日 (四) 00:55 (UTC)
完成 see “Wikipedia:沙盒”修订间的差异 用连结的方式会造成摘要太长,修改两三笔就看不到了。因此只登记公共转换组名称。--Kanashimi留言2021年8月19日 (四) 01:38 (UTC)
我是觉得应该不需要把移除的转换语法写在编辑摘要,转换语法相当的长,或许可以直接写“参数X存在于Y”(Y=转换组名称)。--Xiplus#Talk 2021年8月19日 (四) 15:09 (UTC)
修改了一下 存在於轉換組 ${source}: ${rule}。有的时候会有很多条转换规则,不显示转换规则可能让人理不清头绪。还是附加在编辑摘要的好。--Kanashimi留言2021年8月19日 (四) 21:57 (UTC)
 正式批准运作。--Xiplus#Talk 2021年8月20日 (五) 01:23 (UTC)

--Kanashimi留言2021年4月5日 (一) 21:32 (UTC)

@Kanashimi所以最终清理哪些“未知参数”呢。烦请指明源代码链接。--YFdyh000留言2021年4月6日 (二) 03:18 (UTC)
现在准备先清理 df。程式正在写。 --Kanashimi留言2021年4月6日 (二) 03:19 (UTC)
程式写完了。--Kanashimi留言2021年4月11日 (日) 06:39 (UTC)
批准测试运作(100次编辑)--Antigng留言2021年4月12日 (一) 02:05 (UTC)
程式多次修改过,之前有问题的都回退了。现在的版本会先检查所有日期参数,判断日期格式是否正确。若有错误日期格式,尝试修正之。仍无法改正,则不清除 df参数。
由于要删除df参数必须判别日期格式,因此顺便修正可读得懂,但是格式错误的日期。
现在的版本测试结果,麻烦请从这一笔开始寻找"正规化日期格式、清理引文模组未知参数":
2021年4月12日 (一) 20:20 差异 历史  −4‎  小 Cg语言
想问问是否也能顺便删除掉doi-access这个参数?或者依照先前的讨论准备修改模组了?--Kanashimi留言2021年4月12日 (一) 12:36 (UTC)
@Kanashimi
  1. 请勿修正不会引起CS1模块报错的日期参数,该种修正没有共识且为另一名BAG所反对
  2. doi-access参数与df参数有所不同,其包含了本站条目所需的有用信息,应通过修改模块使之发挥作用,而非删除;
  3. 该测试仅批准您清理df参数而非修正日期格式;请勿于测试过程中添加早前讨论所未提及的功能。

--Antigng留言2021年4月12日 (一) 13:20 (UTC)

谢谢您的说明。这边已经注解掉会修改df以外其他日期格式的部分。
现在会先检查所有日期参数,判断日期格式是否正确。可判别日期,才清除 df参数。--Kanashimi留言2021年4月12日 (一) 20:44 (UTC)
@Xiplus在要修改df参数的前提下,顺便修改日期参数为ISO 8601格式,这样如何? --Kanashimi留言2021年4月13日 (二) 08:37 (UTC)
抽了几笔编辑来看,若不修就会出错的修改当然是没有问题。--Xiplus#Talk 2021年4月13日 (二) 08:46 (UTC)
这样的效果等于是开了AWB General fix。出于其它用户的抵触,仍然建议将这种修改限于:1. 需要同时删除df的模板(而非页面);2. 应跳过“yyyy年mm月dd日”这种格式的参数保持原样。--Antigng留言2021年4月13日 (二) 10:34 (UTC)
英文格式本地是兼容的吗?不过当初反对的部分仅有“yyyy年mm月dd日”和“yyyy-mm-dd”转换,不涉及这部分我认为就没问题。--Xiplus#Talk 2021年4月13日 (二) 10:43 (UTC)
@Xiplus本地兼容几乎全部的英文格式,见Module:Citation/CS1/Date_validation#L-329。纯粹英文格式并不会导致CS1模板报错。--Antigng留言2021年4月13日 (二) 10:49 (UTC)
批准测试运作(100次编辑),按修改后的代码重新测试编辑100次。--Antigng留言2021年4月13日 (二) 10:40 (UTC)
是的,这边的意思就是将此类日期修正当作一种 AWB General fix。--Kanashimi留言2021年4月13日 (二) 11:29 (UTC)
测试完成。烦请从
2021年4月13日 (二) 19:48 差异 历史  −8‎  小 2006年东帝汶危机
开始搜寻正规化日期格式、清理引文模组未知参数。--Kanashimi留言2021年4月13日 (二) 11:58 (UTC)
@Kanashimi,以下日期修正不正确:123。--Antigng留言2021年4月13日 (二) 12:40 (UTC)
感谢帮忙侦错。前两者已对应或者改为无法判别。至于第三个例子,经查w:en:Hey Violet,已经改成与机器人相同的日期了,因此这边的编辑是正确的。 --Kanashimi留言2021年4月13日 (二) 13:15 (UTC)
@Kanashimi,诸如 "10 12, 2018"这样的日期既可能是dmy格式,也可能是mdy格式;机器人不会查证来源不知道是哪个,这次对也可能只是侥幸猜对罢了。--Antigng留言2021年4月13日 (二) 14:33 (UTC)
...您说的有道理。其实从w:en:Hey Violet的{{Use mdy dates}}标示可以知道格式。无论如何,这边已将所有类似的格式改为无法判别。 --Kanashimi留言2021年4月13日 (二) 21:57 (UTC)
@Antigng先跑两礼拜人工检核如何? --Kanashimi留言2021年6月15日 (二) 10:39 (UTC)
全程人工监视检测过一遍,有错误的编辑都已经修正过程式了。Category:含有未知参数的引用的页面从3K+减少到2151。烦请再检查看看是否有问题,谢谢。--Kanashimi留言2021年6月25日 (五) 23:34 (UTC)
抽样来看没啥问题,您还需要测试吗?--Xiplus#Talk 2021年8月19日 (四) 01:01 (UTC)
谢谢关注。不用做测试了。通过的话,未来会观察几周,有问题会直接修改。--Kanashimi留言2021年8月19日 (四) 01:07 (UTC)
@Xiplus 刚刚完整跑了一次。有问题的页面都会像土卫六一样直接跳过,让人工来处理。您可复核看看。--Kanashimi留言2021年8月20日 (五) 23:04 (UTC)
@Antigng:拟批准,您还有什么想问的吗?--Xiplus#Talk 2021年8月21日 (六) 10:35 (UTC)
 正式批准运作。--Xiplus#Talk 2021年8月29日 (日) 11:42 (UTC)
旧讨论
  1. Wikipedia:互助客栈/方针/存档/2021年10月#专题命名空间(第五至六阶段)Draft:WP-WPJ重新导向连入数量(除“专题/首页的缺失条目”和“MEA”豁免)
  2. Wikipedia:互助客栈/方针#国籍栏使用模板后续处理:约3000多笔
申请人︰路西法人留言 2021年6月9日 (三) 10:23 (UTC)
@LuciferianThomas潜在的国籍参数还有nationality,而且要替换的还有{{CHN-1949}}(重新导向到同一模板)。你至少要调整一下bot的参数。SANMOSA Σουέζ 2021年6月10日 (四) 11:56 (UTC)
就编辑时段及频率而言,我建议你给出它理论上最高的运行频率(例如1分钟内最多可以处理多少个条目)。SANMOSA Σουέζ 2021年6月10日 (四) 11:58 (UTC)
done--路西法人留言 2021年6月10日 (四) 12:03 (UTC)
那我支持这bot的工作。SANMOSA Σουέζ 2021年6月10日 (四) 14:11 (UTC)
这不应该去Wikipedia:机器人/申请吗?--百無一用是書生 () 2021年6月18日 (五) 13:36 (UTC)
真的看不出来两版的分别--路西法人留言 2021年6月20日 (日) 07:49 (UTC)
@LuciferianThomas,按上述第二条清理规则,请问赵丹冰心张国立页面会被清理成什么?--Antigng留言2021年6月21日 (一) 17:36 (UTC)
赵丹张国立页面都是{{CHN}}→{{PRC}};冰心页面应无变更(不符合RegExp规则,国籍栏没有{{CHN}}或{{CHN-1949}})。--路西法人留言 2021年6月22日 (二) 02:04 (UTC)
@LuciferianThomas OK。现在我有这样一个测试页面,请阁下以主账号,并使用AWB工具尝试清理一下。--Antigng留言2021年6月22日 (二) 02:44 (UTC)
批准测试运作(50次编辑),请阁下以主账户按修改后的第二条规则作出50笔编辑。--Antigng留言2021年6月22日 (二) 02:59 (UTC)
完成50笔测试编辑。--路西法人留言 2021年6月22日 (二) 03:10 (UTC)
第二项任务是利用成熟的工具半自动批量代换国籍参数下的国籍模板,该任务已有社群共识潜在的反对者也已知情。经检查,测试编辑无误。此外,该任务为半自动作业,若有测试未能涵盖的少数例外情形,亦能以人工方式检出并加以排除。故拟予以批准。请行政员复查,若无误可授权。同时提醒申请者尽到人工检查和确认的义务。--Antigng留言2021年6月22日 (二) 12:19 (UTC)
 正式批准运作AT 2021年6月28日 (一) 13:56 (UTC)
(?)疑问第一项任务目前状态?怎么还没审就“待存档”?-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️2021年7月5日 (一) 14:24 (UTC)
(?)疑问x2—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️2021年7月19日 (一) 12:38 (UTC)
不相干的任务不应该一起申请。--Xiplus#Talk 2021年8月29日 (日) 11:45 (UTC)
两项任务无关,请重开页面提出第一项任务。--Jimmy Xu 2021年8月29日 (日) 18:32 (UTC)
@Antigng关于第二项任务,可否容许我延伸至将国籍栏不符合MOS:NATL使用的:
完成后我再顺便将现为重定向的{{CHN-HKG}}和{{CHN-MAC}}改回旧有版本?(当时为了方便,Sanmosa君直接改了为重定向)--路西法人留言 2021年7月25日 (日) 02:19 (UTC)

使用{{AFC botreview}},(手动)测试效果请见User:LuciferianThomas/AFC测试2。--路西法人留言 2021年7月7日 (三) 09:59 (UTC)

征询Antigng意见后,按照WP:BOTPOL“除此之外,机械人如只在其拥有者的用户空间进行编辑,亦毋需申请机械人权限”进行自动化测试,以供相关人员参考。--路西法人留言 2021年7月7日 (三) 12:15 (UTC)
测试页面:User:LuciferianThomas/AFC测试2,草稿提交者有启用Flow则机械人自动转往User talk:LuciferianThomas/AFC测试2。--路西法人留言 2021年7月9日 (五) 05:56 (UTC)

批准测试运作(50次编辑) --百無一用是書生 () 2021年8月4日 (三) 07:06 (UTC)

@Shizhao五十次全自动测试编辑完成,复查无误。--路西法人留言 2021年8月7日 (六) 01:46 (UTC)
突然想到一个问题需要确认一下,有bot权限的账号在他人用户对话页上发表的内容,用户会收到留言通知的吧?--百無一用是書生 () 2021年8月9日 (一) 03:04 (UTC)
应该是。Cewbot也有。--路西法人留言 2021年8月9日 (一) 03:10 (UTC)
Cewbot哪个任务是会给用户留言的?翻了一下没找到--百無一用是書生 () 2021年8月10日 (二) 03:15 (UTC)
提醒关注度过期。--路西法人留言 2021年8月10日 (二) 10:22 (UTC)
使用小修改就不会有通知,因此要根据是否通知的需求设定是否小修改。--Xiplus#Talk 2021年8月19日 (四) 01:04 (UTC)
个人认为既然为“自动审核结果”,有通知引起新手注意是好的。--路西法人留言 2021年8月19日 (四) 02:54 (UTC)
 正式批准运作,在用户对话页留言时请避免标记为小修改。--Jimmy Xu 2021年8月29日 (日) 18:18 (UTC)
透过解析Category:已批准机械人作业申请中所有页面的内容来产生,其中已批准操作取自用途参数的第一行。范例。--Xiplus#Talk 2021年8月20日 (五) 01:46 (UTC)
快速批准运作,请自行更新Wikipedia:机器人/列表。--Jimmy Xu 2021年8月29日 (日) 18:38 (UTC)
  • 状态 已批准
  • 操作者: Jimmy Xu
  • 提请时间: 2016年8月16日 (二) 13:23 (UTC)
  • 程式语言
  • 用途:移除有多个链入页面之条目的{{orphan}}标记。
  • 编辑时段及频率:
  • 受影响页面:
  • 遵守机器人规范
  • 已有机器人权限:
链入不计非条目、消歧义和重定向。--Jimmy Xu 2016年8月16日 (二) 13:23 (UTC)

页面要由机器人执行删除,必须符合以下条件:

  1. 页面位于使用者命名空间(不含使用者讨论命名空间)
  2. 删除标记符合正规表达式 {{\s*(Delete|Db-reason|D|Deletebecause|Db|速删|速刪|Speedy|SD|快删|快刪|CSD|QD)\s*\|\s*(O1|G10)\s*}}
    防止嵌入引用产生、临时测试或其他特殊需求(同时删除子页面的请求),都交由人类处理。
  3. 加入删除标记的人必须与用户页所属用户名相同(透过检查历史编辑差异完成) 由#6取代
  4. 页面不能从其他地方移动过来。
    由于无法检查透过“移动目标”来检查移动日志,仅能透过页面历史的编辑摘要检查,但这不是稳妥的方式。
    所以将检查页面建立日志是否存在相同名称的页面(透过pageid确保属于当前页面而非已删页面),这表示页面最初就是建立在用户页上。
    虽然将页面移动到其他地方又移动回来仍会判定为可以删除,但因为页面最初就建立在用户页内,我认为应该没问题。
  5. 等待10分钟后才删除。
  6. 用户页仅有一名编辑者(特定机器人排除)

--Xiplus#Talk 2021年10月12日 (二) 04:23 (UTC)

是否还应该检查页面是否只有用户自己编辑?如果多人编辑似乎不应该O1?--百無一用是書生 () 2021年10月12日 (二) 05:51 (UTC)
就快速删除方针而言并没有这项规定,您可以说明“哪种性质的多人编辑页面”可能需要额外的人工判断吗?--Xiplus#Talk 2021年10月12日 (二) 07:00 (UTC)
例如那种用户子页面做留言本、签到簿之类用的,或者共笔用的等等。有别人的贡献在里头,只因为是自己的用户也就能删除,看起来不妥?--百無一用是書生 () 2021年10月13日 (三) 12:23 (UTC)
就方针而言可以删除,不然试问您作为管理员看到这类请求会如何处理?--Xiplus#Talk 2021年10月13日 (三) 12:37 (UTC)
如果是有别人进行实质性内容修改的,我会拒绝删除--百無一用是書生 () 2021年10月14日 (四) 12:19 (UTC)
先暂时加上这条限制了,抽查判断对于处理量应该不会有太大影响。--Xiplus#Talk 2021年10月14日 (四) 12:57 (UTC)

批准测试运作(50次编辑) --百無一用是書生 () 2021年10月15日 (五) 07:23 (UTC)

已在上方补上原始码连结。--Xiplus#Talk 2021年10月16日 (六) 11:45 (UTC)
 正式批准运作 ,代码看来没什么问题。(一看代码第一行就知道是python大佬了 :D)--百無一用是書生 () 2021年10月16日 (六) 12:26 (UTC)
  • 状态 已批准
  • 操作者:百無一用是書生 ()
  • 提请时间:2021年10月9日 (六) 09:42 (UTC)
  • 自动化程度:全自动
  • 程式语言基于pywikibot开发
  • 用途:条目状态通告
    Wikipedia:Article alerts的不完整复刻版,不同于英文版的每日更新,本bot为实时更新
  • 原始码连结:[2]
  • 编辑时段及频率:约0-10次/天/页
  • 受影响页面:挂有{{ArticleAlertbot}}模板的页面(以及可能少数几个功能性用途的页面),短期内不会超过100个页面,中长期应该不会超过500个页面(英文版目前有1600多个页面)
  • 遵守机器人规范
  • 已有机器人权限:不需要bot权限

为提高编辑可见性,故不需要bot权限 --百無一用是書生 () 2021年10月9日 (六) 09:42 (UTC)

好几年前开发过一个同样的bot,后来因为脚本不够健壮,且技术变化较多而不能正常运行(python和pywikibot版本升级,mw API改变等)。现在连代码都丢了。。。重新写了一个新的--百無一用是書生 () 2021年10月9日 (六) 09:47 (UTC)

手工更新的demo页面:User:Shizhao/test2/1User:Alertlivebot/人物(页面中肉眼可见的bug已经修复了)--百無一用是書生 () 2021年10月11日 (一) 11:37 (UTC)
@BAG成员@AntigngPeacearthWhitePhosphorusKanashimiXiplus召唤一下....--百無一用是書生 () 2021年10月16日 (六) 13:01 (UTC)
受影响页面应该是专题的数量?或许可以限缩在Category:活跃维基专题66个(或再加上Category:半活跃维基专题117个)。这个任务是定时执行还是实时更新(意思是每个操作都会造成机器人1笔编辑)?--Xiplus#Talk 2021年10月16日 (六) 13:14 (UTC)
这个是要某个专题自己决定是否启用条目状态通告,通过用户手工在专题页面加入{{ArticleAlertbotSubscription}}模板,然后由该专题的用户手工建立一个通告专用的子页面并在该子页面挂上{{ArticleAlertbot}}模板(在某个页面直接挂上{{ArticleAlertbot}}也可以,但不推荐),bot只会编辑这个挂上了{{ArticleAlertbot}}的子页面。如果专题不想用条目状态通告,不走上述流程就可以,如果启用了条目状态通告又想关掉,删除页面上的{{ArticleAlertbot}}模板就可以。实际受影响页面其实就是Category:用于专题的条目通告下的挂有{{ArticleAlertbot}}模板的页面。
这个任务是走的EventStreams接口,实时更新。英文版的那个bot是每日更新一次。可以参考我目前手工更新的传记专题通告的演示页面。bot从12日开始运行(只是没有把结果自动post到wiki上),已经运行了5天了,包括了Category:用于专题的条目通告下的所有状态通告页面(这是以前老bot用的分类,现在这个bot承袭了过去的流程),其中传记专题的状态通告是最频繁的,也不过每天不超过10次更新(也就是等于每天不超过10次编辑)。Category:用于专题的条目通告下的其他状态通告页面,大约四分之一每天最多2-3次更新,剩下大部分几天才有一次更新。这样算下来,bot每天对所有通告页面的总编辑次数最多也就是20-30次左右
另外,这是之前已经运行过一阵的任务,后来停掉了,Category:用于专题的条目通告分类下的页面就是当时的产物,现在是重开这个任务。可以见Wikipedia:专题委员会/技术支持#条目状态通告--百無一用是書生 () 2021年10月16日 (六) 13:59 (UTC)

再度召唤,目前绝大部分提醒类型都已经弄好了,需要真正跑起来发现未知问题了--百無一用是書生 () 2021年10月19日 (二) 11:35 (UTC)

我已在用户空间子页面开始了测试,见Special:用户贡献/Alertlivebot--百無一用是書生 () 2021年10月21日 (四) 02:43 (UTC)
在现有Category:用于专题的条目通告且位于WikiProject:空间(目前有24个) 批准测试运作(30日)。--Xiplus#Talk 2021年10月22日 (五) 03:10 (UTC)
感谢!另外,用户空间下的(我的和bot的)页面为了方便调试,我还是需要接着更新--百無一用是書生 () 2021年10月22日 (五) 07:04 (UTC)
那就纳入吧,反正用户空间本来就不受规范。--Xiplus#Talk 2021年10月22日 (五) 10:57 (UTC)
这里是开发日志:User:Alertlivebot/beta--百無一用是書生 () 2021年10月27日 (三) 06:27 (UTC)
 正式批准运作。--Xiplus#Talk 2021年11月24日 (三) 04:30 (UTC)
感谢!--百無一用是書生 () 2021年11月24日 (三) 05:55 (UTC)
  • 状态 已批准
  • 操作者:Xiplus#Talk
  • 提请时间:2020年1月10日 (五) 06:52 (UTC)
  • 自动化程度:全自动
  • 程式语言Pywikibot
  • 用途:根据用户名自动封禁特定傀儡
  • 原始码连结:
  • 编辑时段及频率:跟进使用者建立日志
  • 受影响页面:
  • 遵守机器人规范无关
  • 已有机器人权限:

根据用户名自动封禁特定傀儡。--Xiplus#Talk 2020年1月10日 (五) 06:52 (UTC)

是有AF之外更可靠的heuristic么?--Jimmy Xu 2020年1月21日 (二) 05:12 (UTC)
因为AF不可靠,有时会无法阻止帐号建立,另外AF封锁似乎没有启用自动封锁(因为是针对IP封锁)。--Xiplus#Talk 2020年1月21日 (二) 05:21 (UTC)
不知现在还会不会是SUL进来的账户就挡不住了。--Jimmy Xu 2020年1月22日 (三) 01:52 (UTC)
批准测试运作(50次编辑)。--Jimmy Xu 2020年1月22日 (三) 01:52 (UTC)
meta那边AF是能够自动封禁账户的啊?--百無一用是書生 () 2020年4月3日 (五) 09:19 (UTC)
本地也可以自动封禁,但总会发现有拦不到的问题,也不清楚问题到底在哪。--Xiplus#Talk 2020年4月3日 (五) 09:21 (UTC)
批准延长测试运作(60日),已过一段长时间,如还有运作必要还请再测试一下。--Jimmy Xu 2021年8月29日 (日) 18:15 (UTC)
测试已完成,已过2个月,机器人持续运作中,用户名黑名单基本上是我自己看到较严重的傀儡就会加入,当然也可以受理其他管理员的私下请求。--Xiplus#Talk 2021年11月16日 (二) 06:18 (UTC)
 正式批准运作。--Jimmy Xu 2021年12月7日 (二) 20:28 (UTC)