跳转到内容

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

维基百科:机器人/申请/存档/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”