維基百科:機械人/申請/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)
批准測試運作（50次編輯） --百無一用是書生 (☎) 2021年2月20日 (六) 06:31 (UTC)
測試已完成- 測試範圍：所有條目列表前20頁（共100,000個條目），涵蓋各種類型的條目；
- 結果：第一次嘗試：185筆編輯、第二次嘗試：105筆編輯
- 發現的問題：該任務利用啟發式算法嘗試修正不正確的日期，其描述能力超過一般正則表達式（即：III型文法），可以比較好地應對各種不正確使用的情況，但如早前的申請所述，可能會導致一些意料之外的錯誤處理；經人工複查，測試編輯存在下列問題
- 修正後的日期格式一律為ISO格式，這可能不符合英文站MOSDATE指引關於日期格式應「先到先得」、「全條目統一」的要求；然而本站MOSDATE指引無此「先到先得」之要求，且本站絕大多數條目選用ISO格式的日期，更正為ISO格式導致條目格式統一的概率遠大於破壞條目格式統一的概率；過往討論和引用模板的提示亦傾向於使用ISO標準格式。考慮到兩站共識的差異，本次任務若批准，仍將維持修正目標為ISO標準格式，不考慮修改；
- 修正後可能會刪去一些不相關的字串，如Special:Diff/64406914，該等修改並無害處（因人工處理結果也是直接刪去這些字串），不考慮改進；
- 下列七個條目存在因出版物編號而導致的錯誤修正，已全數回退：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月22日 (一) 02:26 (UTC)
- 可以這樣理解。過去Liangent-bot採用正則表達式去匹配特定的錯誤模式（如匹配"yyyy/mm/dd"、"yyyy年0m月dd日"這兩種特定的錯誤格式，將其分別修正為"yyyy-mm-dd"和"yyyy年m月dd日"），假陽性率較低、但假陰性率較高；本人則是試圖讀入待修正的日期字串，去猜測其中數字的含義（比如，一個四位數後跟着一個「年」字，就猜測這是一個年份）從而提取出年月日參數，以標準格式輸出，理論上可能有較高的假陽性率（猜錯），但同時也能應對諸如這類事先難以預料的誤用。--Antigng（留言） 2021年2月21日 (日) 12:29 (UTC)
正式批准運作 --百無一用是書生 (☎) 2021年2月23日 (二) 03:03 (UTC)
