维基百科:机器人/申请/Antigng-bot/30/2

Antigng-bot 30

狀態： 已批准
操作者：Antigng（留言）
提請時間：2020年11月6日 (五) 04:24 (UTC)
自動化程度：自动
程式語言：C
用途：接Wikipedia:机器人/申请/Antigng-bot/30，进一步清理引用模板中格式不正确的date参数
討論內容連結：Wikipedia:机器人/申请/Antigng-bot/30
原始碼連結：Special:Diff/54652261/64065023
編輯時段及頻率：约1小时一次
受影響頁面：6529 （存量）
遵守機器人規範：不相关
已有機器人權限：是
依照Wikipedia:机器人/申请/Antigng-bot/30中的规则进一步清理引用模板中的date参数。清理的条件完全覆盖前一项任务中的条件（即：模板未损坏，参数未重复，根据Module:Citation/CS1/Date_validation中的正则表达式生成状态机判定参数是否引起引用模板报错，如会报错尝试解析（格式不正确的）参数，要求清出的结果里年月日齐全且合法，没有issue参数等，详见先前的讨论），并在此基础上要求引用模板不含year、month、day等和日期有关的合法参数或已废弃的非法参数。
本系列任务的最终目标是完全取代Wikipedia:机器人/申请/Liangent-bot/16。年月日不齐全、或者含有year、month、day等参数的复杂情形，留待后续任务处理。--Antigng（留言） 2020年11月6日 (五) 04:24 (UTC)[回复]
编辑示例。--Antigng（留言） 2020年11月6日 (五) 04:24 (UTC)[回复]
空运行报告：在整个主名字空间发现6529个可编辑页面，其中24个不在分类Category:引文格式1错误：日期之中。经查，除前一项任务的遗留之外，剩余假阳性一是不使用CS1的小众引用模板；二是重复定义的ref标签；三是母模板不存在或指定参数不存在，见此。其中二和三没有危害，一涉及到模板{{cite court}}的使用，部分条目中使用该模板填写民国纪年法，会被自动清理为标准格式，如Special:Diff/62703478。请问这种用法是否合适？在执行清理时是否有必要加以排除？Antigng（留言） 2020年11月6日 (五) 07:16 (UTC)[回复]
{{cite court}}最好进一步讨论一下。暂时不处理如何？--百無一用是書生 (☎) 2021年2月20日 (六) 07:28 (UTC)[回复]
- 好的。--Antigng（留言） 2021年2月20日 (六) 12:56 (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)[回复]