跳至內容

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

維基百科:機器人/申請/存檔/2017年/覆核

新增連結
維基百科，自由的百科全書

不活躍機器人

Weyardbot

ChuispastonBot

IluvatarBot

Fajrbot

Ver-bot

JYBot

Thijs!bot

Synthebot

SieBot

TXiKiBoT

DragonBot

You may disable the bot for now. Thanks ! --Jacob.jose（留言） 2017年6月8日 (四) 03:32 (UTC)

PixelBot

MenoBot

Yes, you can remove the bot flag for inactivity. If I need it again in the future, then, I will reapply for it. --Meno25（留言） 2017年6月8日 (四) 10:42 (UTC)

Loveless

Now that interwikis are handled by wikidata, my bot doesn't require the flag anymore.
(thanks for warning me) Darkoneko（留言） 2017年6月10日 (六) 15:36 (UTC)

VolkovBot

Luckas-bot

LaaknorBot

Please remove rights. Not needed anymore after move of interwiki to wikidata. Laaknor（留言） 2017年6月10日 (六) 18:46 (UTC)

SilvonenBot

FiriBot

CarsracBot

Ginosbot

Ptbotgourou

Nallimbot

ArthurBot

GhalyBot

D'ohBot

Dinamik-bot

TjBot

EleferenBot

HRoestBot

TuHan-Bot

KamikazeBot

Ripchip Bot

WikitanvirBot

BendelacBOT

Minsbot

DarafshBot

ElphiBot

KLBot2

MahdiBot

SantoshBot

Addbot


ChessBOT

Kasymbot

DixonDBot

Robbot

@Wong128hk：操作者是User:Andre Engels啊。——傑里毛斯（留言） 2017年6月26日 (一) 05:10 (UTC)
情況無異，最後操作時間及已通知者均無變。--J.Wong 2017年6月26日 (一) 05:44 (UTC)

DEagleBot

CocuBot

SassoBot

ZéroBot

Idioma-bot

JAnDbot

You can de-flag bot. I have no further plan in zh.wiki with it. JAn Dudík（留言） 2017年6月26日 (一) 07:00 (UTC)

Swifty Bot

其他

Jimmy-abot 3

目前 Jimmy-abot 每日大量使用AS號碼和運營商在RIR的帳戶為基準封禁 IP 段，但其操作許可已經被撤銷。此情況屬於運行批准以外任務/未經許可運行機器人，請考慮作出處理。操作人已被通知。Dargaseat ‧ c ‧ s 2017年6月13日 (二) 17:34 (UTC)

封禁的區域段太廣了。沒有實質效益，這樣也防不住破壞者的破壞。有的想要有心想要作好的編輯卻被封禁的區段給擋住了，讓很多封禁區段的用戶都申請IP封禁豁免權，這不是好現象。--小躍（撈出記錄） 2017年6月17日 (六) 13:56 (UTC)
似乎封禁腳本已經停了？--百無一用是書生 (☎) 2017年6月19日 (一) 02:15 (UTC)
@Shizhao：似乎沒有，例如52.150.96.0/20。Dargaseat ‧ c ‧ s 2017年6月19日 (一) 04:00 (UTC)
昨天之後就沒有了--百無一用是書生 (☎) 2017年6月19日 (一) 05:36 (UTC)
@Shizhao： 又繼續了。Dargaseat ‧ c ‧ s 2017年6月30日 (五) 21:24 (UTC)
已通知用戶。--小躍（撈出記錄） 2017年7月1日 (六) 14:55 (UTC)
操作者收到通知後，Jimmy-abot已經停止施行封禁。本案完結。--J.Wong 2017年9月10日 (日) 14:05 (UTC)

Wcam-bot、Antigng-bot 18

JPEG質量參數

這兩個bot在JPEG處理上存在對於質量係數決定過低的問題。JPEG質量係數決定對於高頻細節的捨棄程度，較高的質量對於圖片的清晰程度非常重要。在像素較少時圖片特徵個個都是一兩像素的「高頻」部分，更不可以使用低（小於 90）的質量係數。

  • User:Wcam的Wcam-bot生成的JPG質量係數低者達75。建議檢查相關庫參數。似乎和復用了原始文件的質量有關？
  • User:Antigng的bot直接使用commons縮略圖，質量係數多在80左右。建議改為自己壓縮。在縮小時請儘量接近wcam所用的高質量算法，此外wcam-bot保留exif的行為值得模仿。@shizhao：主意餿了。

方針規定的像素數量已經夠低了，請不要再惡化質量了。原圖像中相對的高低頻取捨不能應用到縮小後的圖片。同理，Chroma subsampling 請設置為 4:4:4，即不捨去色彩分量。 ——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月12日 (日) 17:40 (UTC)

Wcam-bot僅僅依照指引修改尺寸，不會修改圖片的任何其他參數。對於非自由圖片，如何在像素有限的情況下提高圖片質量，是圖片上傳者和使用者的責任，不應該由機器人來做額外的決定。另外我不能同意「規定的像素數量已經夠低了」這一說法，首先WP:NFCC規定維基百科條目和其他地方都不會自動擁有使用非自由內容的資格。其次，非自由圖片是為條目服務的，因此其尺寸理應不得大於其在條目中的尺寸，而十萬像素往往高於這個尺寸。在這個前提下，糾結諸如JPG質量係數這類問題我認為沒有實際意義。--Wcam（留言） 2017年3月13日 (一) 02:57 (UTC)
@Wcam：重新讀我簽名之前倒數第一、二句。不要讓我把《數字圖像處理》拿出來跟你講JPEG。質量係數確實是容易忽視的細節，然而出現嚴重例子（File:Police_Force_use_Brick_attack_protesters_AP_20160209.jpg，對比[1]）之後就不該用「是細節」掩蓋了。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月13日 (一) 03:54 (UTC)
已修改JPG質量參數--Wcam（留言） 2017年3月13日 (一) 17:09 (UTC)
@Wcam：好的，謝謝。雖然我自己總是會說 100 太高……——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月13日 (一) 18:41 (UTC)
既然好像Jimmy又提起來了，我也再強調一遍「只用得到十萬」是瞎扯吧。任何合格的前端工程師都應該知道HTML、CSS的「px」只是一種1⁄96英寸（0.26公釐）的長度單位，和物理像素的關係隨著高分屏普及越來越少（要給Windows最常見的1.5x屏幕「夠用」的話，限制要乘上2.25；要給行動裝置和macOS機器夠用的話，那乘個9限制跟沒限制都快沒區別了）。限制像素最重要的一個目的是保證這東西沒有拿來製作盜版的價值，什麼「只能用到」都是在瞎貼金。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月14日 (二) 17:15 (UTC)
Mediawiki用的是VIPS，預設的Q值是75，反正要麼把libvips編譯進來，要麼直接命令行運行vipsthumbnail -s (大小) -f （輸出文件名）[Q:90] (輸入文件名)。--Antigng（留言） 2017年3月14日 (二) 09:55 (UTC)
@Antigng：如果閣下要認真做個將圖片縮小成圖片——而非用後即棄的縮略圖——的東西的話，請自己去抓一份imagemagick的convert做成png，然後餵進mozjpeg的cjpeg程序。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月14日 (二) 17:13 (UTC)
啊，其實vipsthumbnail這玩意還算靠譜。就是-s的時候注意一下長寬比（可以 -c），考慮 -p 個 nohalo/lbb 之類的玩玩。system或者spawn的時候別搞炸。沒別的意見了。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月14日 (二) 20:09 (UTC)
Mediawiki原來就是用的imagemagick，後來是因為效率和質量的問題換成了VIPS。--Antigng（留言） 2017年3月15日 (三) 00:02 (UTC)
因為質量原因我才會推薦兩步處理呀。效率我倒是不在意，你才多少編輯速度……（倒是有件事可以整一下，進程優先級調低一點的話，你用電腦做其他工作的時候可以舒服一點。）--Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月16日 (四) 13:26 (UTC)

任務延遲和例外處理

@Wong128hk、Temp3600：在Telegram上提到，英文維基對於縮小圖像的指引有「准許例外」和「考慮剪裁出重點細節部分，而非縮小全圖」兩點。現有的bot處理提供的「標記（Eagerbot）—縮圖（antigng, wcam）—刪除（jimmy-abot）」一條龍服務顯得有點太aggressive了。

  • @Wcam、Antigng：建議兩個縮圖bot在掛上標記模板後等待至少10天進行操作，並允許使用某種一致的模板標記設置例外。Bot在處理完成圖片後應該加入跟蹤分類，方便人類管理員檢查。
  • @Jimmy Xu：考慮到操作效率的問題，雖然有錯的可能是縮圖bot，但做檢查的大概得落到執行刪除的管理員身上。
    • 建議Jimmy-abot快速刪除舊版非自由版權文件時，排除處理最後版本是bot創建的文件。
    • 建議改為人類管理員檢查bot操作後決定是刪除舊版，還是回退到上一個版本（保留縮圖請求、指定應該裁剪，並加bot例外）。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月12日 (日) 19:56 (UTC)

只是有哪些要保持原圖風貌還是什麼的，以保持圖片不失真呢？我的機器人先暫停標記工作，等無異議再來繼續標記。--小躍（撈出記錄） 2017年3月13日 (一) 00:01 (UTC)

@Wcam-bot、Antigng-bot：請先暫停縮圖的工作，協商一下怎麼作會比較好。--小躍（撈出記錄） 2017年3月13日 (一) 00:08 (UTC)
@小躍：也不是說風貌（這個理由太不「合理使用」了XD），是要在解析度不超過限制的情況下，保證條目用得到的部分看得清。因此在直接縮圖之外，還有裁剪一解。另外感謝暫停。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月13日 (一) 02:42 (UTC)
就是要看解析度夠不夠。--小躍（撈出記錄） 2017年3月13日 (一) 02:44 (UTC)

@小躍：批量回退就不用了吧？還沒授權呢……——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月13日 (一) 03:15 (UTC)

在下怕他們又繼續縮圖。才會實施回退功能。--小躍（撈出記錄） 2017年3月13日 (一) 03:17 (UTC)
@小躍：心意領了，但是還沒授權呢！——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月13日 (一) 03:20 (UTC)
不好意思該維護模板是我的機器人在維護，在下有權利可以暫停任務。--小躍（撈出記錄） 2017年3月13日 (一) 03:23 (UTC)

首先，對非自由內容從嚴限制，符合維基百科「自由百科全書」的宗旨和維基媒體基金會的意願，目前的非自由圖片處理流程我認為並無不妥。其次，為了少數例外情況而對目前適用於全部非自由圖片的工作流程做出較大的改動，我認為實屬虛耗社群精力。然而J.Wong關於通知上傳者的建議我認為有可取之處。非自由內容在維基百科條目使用的資格要靠上傳者自己來爭取。--Wcam（留言） 2017年3月13日 (一) 03:46 (UTC)

目前的處理流程完全沒有人類介入控制，是為不妥之處。如有例外情況值得標記，就不能用「全部」一詞了。將刪除作為檢查步驟的原因在於人類手動縮圖速度緩慢，檢查簡單的對錯選項則快得多，這已是出於效率考量。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月13日 (一) 03:52 (UTC)
話不可說的這麼滿，我的機器人可以控制。--小躍（撈出記錄） 2017年3月13日 (一) 03:55 (UTC)
@小躍：你的bot是好同志不錯，但它掛上的模板只是說「圖片太大」，而沒有直接表示要直接整個縮小。如果下游的bot直接默認是「整個縮小」，又有管理bot自動刪除……——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月13日 (一) 03:58 (UTC)
都已經標記建議縮小的寬度了，閣下還有問題嗎？--小躍（撈出記錄） 2017年3月13日 (一) 04:01 (UTC)

@小躍：那就重新用一下之前的結論吧：問題不在標記、不在刪除，在於縮圖時默認「整個縮小」。然而考慮到人類手動縮圖速度緩慢，更適合做對錯題，應該換到刪除（管理員）步驟控制。就是說錯最小可能是你，所以也沒把你拉來覆核。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月13日 (一) 04:03 (UTC)

雖然縮小時解析度沒去動過，不過整體縮小後圖片容易失真。--小躍（撈出記錄） 2017年3月13日 (一) 04:08 (UTC)
就拿這圖說事好了，這大於十萬，你除了可以整張縮細之外，更可以裁去兩邊，突顯重點嘛。--J.Wong 2017年3月13日 (一) 04:55 (UTC)
這說得沒錯，但我認為圖片的上傳者和使用者有責任進行這些圖片編輯操作，使得圖片在按規定縮小後不會質量過於低下。任何用戶均可根據圖片來源信息獲取原始圖片進行必要的編輯（或在存廢覆核請求電郵原圖），機器人不應該也不可能為特定圖片做特殊的額外處理。--Wcam（留言） 2017年3月13日 (一) 14:59 (UTC)
（傳聲筒模式）@Temp3600：在Telegram提到，目前機器人處理的圖片不乏五、十年前的舊圖。（Artoria認為）從這點看來，指望原上傳者負責是不現實的事情。如果真的希望其他用戶（包括圖片使用者）看到之後順手修復，至少該加一個「由機器人縮小，不滿意者請自己上」的模板。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月14日 (二) 04:29 (UTC)

Liangent-bot 4

參見Wikipedia:機器人/申請/Liangent-bot/4，此機器人根據跨語言連結模板自動建立重定向出錯不在少數，甚至建立後自行提報刪除（繁簡混用），實在矛盾。另外跨語言連結模板填寫的正確性影響此機器人運行的正確性，我認為這需要重新審視。--A2093064#Talk 2017年6月15日 (四) 23:06 (UTC)

問題不在bot身上，而在於輸入的數據有問題（有句俗話叫做垃圾進，垃圾出）；而人寫出垃圾，就該去怪讓新人用 {{link-en}} 這種垃圾東西的人身上。這種先不存在（中文）再存在（外文）再給顯示文字的奇怪參數順序，一般人用了不出錯才怪。人這邊建議早日 {{tsl}} 報平安，bot 這邊偏向於駁回覆核。畢竟在 bot 編輯之前，正常人類看到的頁面也會發現連結目標不對，而 bot 只是固化了這個狀態而已。——Artoria2e5編 討論要完整，回覆請用ping。 2017年8月22日 (二) 17:24 (UTC)
@Artoria2e5：我不確定您是否沒能理解我的問題，這問題不管用link-en或是tsl都會發生，我當然知道模板填寫正確就沒這問題，可是問題就是存在錯誤，至於機器人的問題請順便看一下Wikipedia:互助客棧/其他/存檔/2017年8月#有關Liangent-bot根據跨語言連結自動建立重定向。--A2093064#Talk 2017年8月22日 (二) 23:32 (UTC)
垃圾進垃圾出，人類的錯沒有必要怪機器人。另外 link-xx 就是比 tsl 容易出現人類錯誤，當然就不該去用啊。——Artoria2e5編 討論要完整，回覆請用ping。 2017年8月23日 (三) 00:41 (UTC)
@Artoria2e5：例如連結到外文章節，這應該不能說是錯誤吧。--A2093064#Talk 2017年8月23日 (三) 00:48 (UTC)
我給那個模塊寫好EP了。連結外文章節的時候對不對，需要看用戶在中文這裡寫了啥。——Artoria2e5編 討論要完整，回覆請用ping。 2017年8月23日 (三) 01:09 (UTC)

Jimmy-bot 6

例子（請在各頁面中搜索「px」）： [2] [3] [4] [5] [6] [7] [8]

  • 是否應當修訂WP:FUC第9條，將命名空間的限制適當放寬，例如允許Draft和Template命名空間？
  • 即便現有方針不變，將連結命名為「??px」是否妥當？我認為，在以上各例中，還不如直接刪掉較為合適，尤其是第一例…

——Arnie97（留言） 2017年7月23日 (日) 09:33 (UTC)

Draft：移到條目再放圖不就好了？Template：是否真的有合理使用，WP:NFCC#8：「條目中的意義。只有當其呈現將有助於加深讀者對條目主題的理解，而其缺失將妨礙理解時，非自由內容才能被使用。」，缺少了這張圖是否有嚴重影響，另外，在模板使用將會使得大量在頁面使用，請注意要合理使用圖像，必須要圖像說明頁一一標明所使用的條目及使用理由。--A2093064#Talk 2017年7月23日 (日) 09:46 (UTC)
連結命名只是將檔名前直接加了個 : 變成普通連結所致，似乎也沒什麼不對的。支持考慮放寬 Draft，但是請轉 VPP。——Artoria2e5編 討論要完整，回覆請用ping。 2017年8月12日 (六) 18:22 (UTC)
取自「https://zh-two.iwiki.icu/w/index.php?title=Wikipedia:机器人/申请/存档/2017年/复核&oldid=83611885」