Nothing Special   »   [go: up one dir, main page]

跳转到内容

Wikipedia:机器人/作业请求:修订间差异

维基百科,自由的百科全书
删除的内容 添加的内容
第263行: 第263行:
许多天主教相关的条目参考了gcatholic.com的资料,但该网站在几年前以及将域名更换为gcatholic.org,原域名现处于失效状态,这些链接[https://zh.wikipedia.org/w/index.php?search=insource%3A+gcatholic.com&title=Special%3A%E6%90%9C%E7%B4%A2&profile=advanced&fulltext=1&ns0=1}} 至少有300处之多],故请求机器人协助将条目中所有形如gcatholic.com/*的外链替换为gcatholic.org/*
许多天主教相关的条目参考了gcatholic.com的资料,但该网站在几年前以及将域名更换为gcatholic.org,原域名现处于失效状态,这些链接[https://zh.wikipedia.org/w/index.php?search=insource%3A+gcatholic.com&title=Special%3A%E6%90%9C%E7%B4%A2&profile=advanced&fulltext=1&ns0=1}} 至少有300处之多],故请求机器人协助将条目中所有形如gcatholic.com/*的外链替换为gcatholic.org/*


== 電影產地模板 ==
== 電影產地模板2 ==


同[[Wikipedia:机器人/作业请求/存档5#電影產地模板]],申請將使用{{tl|美國電影}}(669個)、{{tl|Film US}}(130個)、{{tl|FilmUS}}(18個)的條目修改成使用{{tl|美國電影產地}},因要將{{tl|美利堅合眾國電影}}請求移動至{{tl|美國電影}},謝謝。--[[User:寒吉|<span style="color:orange;">'''寒'''</span>]][[User talk:寒吉|<span style="color:orange;">'''吉'''</span>]] 2022年1月13日 (四) 10:12 (UTC)
同[[Wikipedia:机器人/作业请求/存档5#電影產地模板]],申請將使用{{tl|美國電影}}(669個)、{{tl|Film US}}(130個)、{{tl|FilmUS}}(18個)的條目修改成使用{{tl|美國電影產地}},因要將{{tl|美利堅合眾國電影}}請求移動至{{tl|美國電影}},謝謝。--[[User:寒吉|<span style="color:orange;">'''寒'''</span>]][[User talk:寒吉|<span style="color:orange;">'''吉'''</span>]] 2022年1月13日 (四) 10:12 (UTC)

2022年1月14日 (五) 10:29的版本

中文

本頁面用來請求機器人協助完成一些相對簡單而重複的作業,任何請求都必須符合機器人政策。想查看現有的機器人,請參見Wikipedia:机器人/列表

對於某個機器人的問題,請向其擁有者詢問。若發現機器人運作不良,請直接提醒該用戶,或至当前的破坏報告。

許多請求被拒絕的原因,可能是因為作業內容過於複雜,或是請求項目需要獲得社群共識

假設,如果您請求的機器人作業是把所有的條目討論頁加上一個专题标志模板以將其特定分類或子分類,請非常謹慎地檢查以確定其分類樹中沒有任何非目標的子分類:例如您可能沒留意到(在英文维基百科中)Category:第二次世界大战其實(曾经)是Category:泰國的子分類,但事實上機器人在修改後者時將會波及前者。因此,我們提出要求時應提供完整的分類清單,以供機器人作個別處理,而非提供一個大分類再讓機器人修改所有相關分類而因而陷入遞迴。以下是英語版維基的一個成功請求,以及一個不良請求(及其造成的爛攤子)。中文維基的爛攤子例子見此

关于专题,请参看维基百科:专题委员会/技术支持

流程

提出請求

  • 請求者必須說明作業的內容、範圍與理由。如果曾在他處討論,也請附上連結。
  • 在作業前可能會有用戶提問,視內容可能會被判斷為不適合機器人作業。
  • 提出請求建議先經過討論,可以利用BOTREQ記號模板。更動範圍過大或與現行方針指引有出入的修改應該先在互助客棧或相關專題討論。
  • 在作業完成的報告後,請確認作業內容是否符合預期,並在本頁面回報。

接受請求

  • 擁有機器人的用戶,請在進行作業前在本頁面表明接受請求,以免多个用戶同時作業而出現衝突。{{BOTREQ}}可以用來方便回應。
  • 任何相關疑問請在本頁面或適當討論場所提出。
  • 當機器人作業完成之後,請在本頁面回報,說明完成的內容,並在作業確認完成後存檔。

请求区

# 需求 進度 💬 👥 🙋 最新發言 🕒 (UTC+8) 🤖 最新機器人操作者 🕒 (UTC+8)
1 請求將Statute of Westminster 1931的所有其他譯名批量替換為《1931年西敏法規》 1 1 Mosowai 2022-10-10 12:30
2 請求替換連結 10 3 微肿头龙 2024-08-05 11:47 Kanashimi 2024-01-25 20:19
3 批量删除nav模板中的示亡号 完成 3 3 Hamish 2024-10-17 10:59
4 请求替换车站链接 4 2 Johnson.Xia 2024-05-26 10:52
5 替換內部連結 7 2 CaryCheng 2024-06-11 23:32
6 清理Special:PagesWithBadges 3 2 Shizhao 2024-08-31 19:47
7 清理(空格)年、(空格)月、(空格)日、(空格)人和1,000等西方数字格式 2 2 微肿头龙 2024-06-28 08:33
8 请求产生Wikipedia:資料庫報告/檔案描述頁 处理中…… 8 2 Hamish 2024-10-17 11:50
9 清理每日圖片冗餘參數 完成 4 2 Hamish 2024-10-17 09:49
10 批量创建重定向 1 1 Martinc021 2024-09-12 03:57
11 请求将目前链接到斯闊谷 (加利福尼亞州普萊瑟縣)的跨语言链接调整到奥林匹克谷 已關閉 2 2 HanTsî 2024-09-19 02:36
12 單獨轉換 3 2 HanTsî 2024-10-16 09:02
13 清理重复Wayback模板 3 2 YFdyh000 2024-09-22 09:02 YFdyh000 2024-09-22 09:02
14 清理至英文维基的图像链接 1 1 Kcx36 2024-10-04 21:35
15 请求批量替换{{Navbox subgroup}} 4 3 Dabao qian 2024-10-07 01:05
16 批量连结Template:共和制国家现任国家元首 完成 2 2 Hamish 2024-10-16 14:35
17 清理Category:引文格式1错误:日期 7 3 Wang31 2024-10-18 23:47 YFdyh000 2024-10-18 02:22
18 移动分类内页面 完成 2 2 Hamish 2024-10-16 13:41
19 在于姓人物条目添加转换模板 1 1 Kethyga 2024-10-17 12:30
20 关于维基媒体使用条款等全域政策文件被基金会从元维基移动至维基媒体基金会管理 Wiki 7 3 石汗颜 2024-10-28 10:32
21 请求在2024拉美月条目讨论页添加贡献模板 完成 2 2 Hamish 2024-10-26 16:51
22 請求批次移除下面分類內容 1 1 迴廊彼端 2024-10-26 22:19
23 请求长期作业:移除条目空间的Category:使用创建条目精灵建立的页面分类 处理中…… 2 2 Hamish 2024-10-28 18:08
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

一些小修正

  • 间隔号的不当使用:• => ·
  • 数学公式中微分算子的不当斜体:(\<math\>.*?)d([xyz].*?\<math\>) => \1\\mathrm{d}\2,以及\frac{d}{d[xyz]}这种也要修。当然不局限于xyz,细节再说吧。

其他的,想到再补充。AWB和bot其实都可以。 --砜中嘌呤的白磷萃取 打谱 2017年3月4日 (六) 14:55 (UTC)[回复]

@WhitePhosphorus 可以各舉例子嗎?謝謝--Gabriel Chi Hong Lee (找我算账) 2018年1月15日 (一) 09:27 (UTC)[回复]
  • 看了幾個頁面:微分算子達布積分三角換元法,大概有這些情形:
    1. <math>dx</math> → <math>\mathrm{d}x</math>
    2. <math>d\theta</math> → <math>\mathrm{d}\theta</math>
    3. <math>\frac{d}{dx}</math> → <math>\frac{\mathrm{d}}{\mathrm{d}x}</math>
    4. <math>d \over dx</math> → <math>\mathrm{d} \over \mathrm{d}x</math>
    5. <math>\frac{d^n y}{dx^n}</math> → <math>\frac{\mathrm{d}^n y}{\mathrm{d}x^n}</math>
-- tang891228 留言 2018年2月19日 (一) 17:29 (UTC)[回复]
@tang891228不對額,我學的數學沒聽過variable斜體的。我看的數學書中的dy/dx都是全斜體的。ꓢꓯꓠꓟꓳꓢꓮ 2020年1月27日 (一) 12:12 (UTC)[回复]
@WhitePhosphorus數學上variable才使用斜體的證據是?ꓢꓯꓠꓟꓳꓢꓮ 2020年1月27日 (一) 12:13 (UTC)[回复]

参考資料

  1. ^ Thompson, Ambler; Taylor, Barry M. Guide for the Use of the International System of Units (SI) — NIST Special Publication 811, 2008 Edition — Second Printing (PDF). Gaithersburg, MD, USA: NIST. March 2008: 35. 

自动化去除stub标记

我在VPP里面那个DYK标准的讨论中提到了一个较为可靠的机器字数统计方式,即只处理内容部分的第一级段落。按照这个条件,机器数起字数只会少(漏掉列表或者是隐藏的内容)、不会多,因此可以较为安全地判断可以移除的模板。按照伪代码形式,过程描述如下:

求字数:

  1. article 为输入条目名
  2. htmlarticle 对应 HTML 页面,即 "https://zh.wikipedia.org/wiki/" + article 下载的结果
  3. dom 为解析 HTML 所得的 DOM(文档结构)树
  4. paras 为在 dom 上执行 CSS 选择器 #mw-content-text > p(正文区域下每个直接下属的段落(不含标题、代码框等元素))的结果
  5. 对于 paras 中的每个元素 p,将其:
    1. 检索所有 sup.reference 引用标签,去除之
    2. 檢索所有 span:not(:lang(zh)) 的外文內容,去除之(應該可以免疫一些輕小說攻擊)
    3. 檢索所有 span.noprint 的不打印內容,將其一併去除。
    4. 如果正在處理第一個 p,則檢索第一個b粗体文字,將其去除(輕小說標題)
    5. 將現在數出内文长度记为 len(p.text)
      • 在 beautifulsoup 中,元素内文所对应的属性为 text
      • 在 JavaScript DOM API 中,元素内文对应的属性为 innerText
      • len 操作应当考虑 UTF-16 代理对拆分的情况。如果使用的语言为 JavaScript,应当使用 [...str].length(或使用Array.from)而非 str.length 计算长度。Java和C#也有类似的问题。
      • len 操作应对字符串执行 NFC 标准化,以便近似用户可见的“字符”数量。要完全近似“字符”数量,可以使用perl 6、python等语言的“字素群”(grapheme)处理功能。(中文用到这种东西的概率不高。)
      • 在处理 len 之前或许应该去除各种不可见字符,避免用户恶搞。(我好像把人类想得太坏了?)
  6. 返回所有 len(p.text) 之和

主程序:

  1. 对于Category:小作品的每一个条目 a
    1. 如果 a 的名字空间为 0,且 a 的字数大于标准的 1.25 倍
      1. sa 的源码
      2. s 里面的模板都看一遍
        1. 把所有属于Category:小作品模板的去掉(这一步建议预置列表,不要每次都找一遍)
      3. 提交编辑

感谢User:老陳提供灵感。——Artoria2e5 保持讨论完整直接{{ping}}我回复 2017年3月9日 (四) 15:56 (UTC)[回复]

这个去和User:Jimmy Xu说。--Antigng留言2017年3月9日 (四) 15:59 (UTC)[回复]
另,1-3没有必要,直接使用api就好。--Antigng留言2017年3月9日 (四) 16:11 (UTC)[回复]
API给出的text属性只是直接提供了mw-content-text的内容而已,p还是得再跑选择器。用那玩意还要重新组织东西喂进DOM做选择,不像直接取页面有一步到位的东西……——Artoria2e5 保持讨论完整直接{{ping}}我回复 2017年3月9日 (四) 16:20 (UTC)[回复]
我记得API有出纯文本的(我记错了?)。另外,我一向认为小作品不单单是字数问题,并不是超过了1个字符就一定不是小作品了--百無一用是書生 () 2018年9月12日 (三) 09:02 (UTC)[回复]
@Shizhao是,加?action=raw--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2021年2月28日 (日) 09:18 (UTC)[回复]

这个东西这么好,怎么2年没动静?--Key to Sky遠い空へ讨论贡献2020年7月6日 (一) 05:33 (UTC)[回复]

看起來Jimmy-bot有在幫忙清理分類:字數已超過3000位元組的小作品--Kanashimi留言2021年12月12日 (日) 04:29 (UTC)[回复]

自动为文档加入{{缺乏中文说明}}

目前有大量的模板文档和模块文档是英文的,但很多都没有挂上{{缺乏中文说明}}。——SolidBlock留言 2019年10月26日 (六) 23:42 (UTC)[回复]

模板文檔或模組文檔可能會出現使用其他語言的模板使用說明或模組使用說明(如法文日文)--林勇智 2019年10月27日 (日) 12:32 (UTC)[回复]
按理来说,这些文档也应该挂{{缺乏中文说明}}。--SolidBlock留言 2019年11月1日 (五) 11:03 (UTC)[回复]
讀起來不像中文的就掛{{缺乏中文说明}}--林勇智 2019年12月4日 (三) 12:10 (UTC)[回复]
有誰會中文信息处理的?讀起來不像中文的文檔就掛{{缺乏中文说明}}--林勇智 2019年12月4日 (三) 12:50 (UTC)[回复]
「讀起來像不像....」的判斷可能無法使用機器人自動判斷。分類器的分類例外問題無法排除。-- 娜娜奇🐰鮮果茶(宇帆·☎️·☘️2019年12月4日 (三) 12:50 (UTC)[回复]
不在CJKV区域的字符比例过高就挂模板,不用管日语和汉语的相同字形。--jingkaimori留言2020年4月7日 (二) 11:40 (UTC)[回复]
掛上去,不一定會有人去翻吧?
我認為沒有甚麼實質效益--死灰留言2021年9月19日 (日) 11:17 (UTC)[回复]

为使用Template:Information模板而非专用模板、以致被判定为无合理使用依据的非自由版权图像进行模板替换

相关讨论见Wikipedia:互助客栈/其他#关于图片合理使用依据清查此次清查被判定为无依据的合理使用图像中有较大一部分条目使用Template:Information模板而非专用模板、以致被判定为无合理使用依据。鉴于Template:InformationTemplate:Non-free use rationale 2的关键参数可以互通。因此提议:

| Portion = 圖片的使用是为了传达图像本身所含有的意义和信息,且避免让读者误解该图像所欲传达的原始意义和信息。 
| Minimality = 本图片的尺寸和分辨率既能确保图片品质以资辨识,又避免了不必要的过高分辨率。 
| Purpose = 见授权协议。
| Replaceability = 由于本图片几乎并没有相同的免费或自由版权来源。任何非衍生作品的替代图片将无法传达本图片原本的含意,可能会造成对于条目描述主题的误解。
| Commercial = 该使用不会取代原始版权媒介所具有的市场作用。

本提议所涉的文件均位于Category:没有合理使用依据的文件分类内,数量为至多1000个。 Jyxyl9批判一番 2020年1月23日 (四) 07:30 (UTC)[回复]

(+)支持不过如果合理使用档案被使用于超过一个条目,就为每个条目新建一个使用依据?廣九直通車留言2020年1月23日 (四) 12:22 (UTC)[回复]
嗯,如果技术上无法实现可以人工调整。毕竟这种情况比较少。Jyxyl9批判一番 2020年1月24日 (五) 09:43 (UTC)[回复]
这种情况并不少,有超过1400个非自由图片用于多个条目,请见列表。--Wcam留言2020年1月24日 (五) 22:46 (UTC)[回复]
你列出的是全zhwiki所有用于多个条目的非自由图片。而本次涉及的只是因清查而提删的一千条左右条目,相信符合此标准的数量不会很多。Jyxyl9批判一番 2020年1月28日 (二) 12:55 (UTC)[回复]
(+)支持。—— Eric Liu 留言留名學生會 2020年1月23日 (四) 16:25 (UTC)[回复]
倾向(-)反对WP:NFCC#10c规定合理使用依据必须与每一次使用确切相关,使用如此空泛含糊、放之四海而皆准的合理使用依据文字进行批量替换,虽可使图片免受快速删除,实则直接违反WP:NFCC#10c规定。不同类型的非自由档案,例如标志、封面海报、历史图片等,在条目中起到的作用不尽相同,其符合WP:NFCC10条标准的理由也不尽相同,有时需要结合具体的非自由档案和具体条目进行说明(例如File:Alan Kurdi lifeless body.jpg)。--Wcam留言2020年1月24日 (五) 23:04 (UTC)[回复]
(+)支持。整件事情就是有用戶大量提請F9(本來是沒問題的),但是由於速度太快、量太多,社群根本承受不了。除非管理員同意暫緩執行F9一段比較長的時間,否則這机器人作业请求必須執行Sanmosa 2020年1月26日 (日) 07:11 (UTC)[回复]
請參見Wikipedia:互助客栈/其他/存档/2020年3月#非自由圖片的使用理據及其處理Sanmosa 2020年1月26日 (日) 07:16 (UTC)[回复]
(+)支持。另请参见删除方针:“管理员应依照本方针执行删除和还原操作。删除决定不应轻易地做出,如果社群对一个页面是否应当删除存在争议,则该页面通常不应删除。我们应该尽量保留所有合乎百科全书目标的页面,删除应该是最后的选择。在把页面提交删除流程之前,请仔细考虑其他非删除的手段是否能改善页面。”大量提删一些因为错误使用{{Information}}导致理据出现瑕疵图片,严格意义上是严重违反方针的扰乱行为。--人类的悲欢并不相通,我只觉得他们吵闹 2020年1月26日 (日) 07:20 (UTC)[回复]
(+)支持:敝人實在不想一個個去做更正。--Qqkuro66541留言2020年1月26日 (日) 10:30 (UTC)[回复]
(!)意見:如果不希望一个个去更正,至少应根据图片类型做出一个粗略的细分,按类型替换,且部分专用合理使用依据模版本身已包含详细的依据文字。目前已有的专用合理使用依据模版和版权标签对应关系如下:
--Wcam留言2020年1月26日 (日) 13:45 (UTC)[回复]
@Wcam关于之前Wcam提出的的问题,也许可以在机器人暂时更正的同时再在档案描述页中加个临时分类(例如Category:需要复检使用用途的合理使用档案之类的),那也可以把需要人手复检的档案再检视一次?廣九直通車留言2020年1月27日 (一) 06:10 (UTC)[回复]
不反對。那些使用{{Non-free use rationale 2}}的,遲下加個{{logo}}或類似的模板就OK,也不是一定要用專用模板。ꓢꓯꓠꓟꓳꓢꓮ 2020年1月27日 (一) 11:49 (UTC)[回复]
授權協議的種類標誌跟海報應該不會放錯,可從模板分類下手,Category:標誌Category:合理使用海報。 --Qqkuro66541留言2020年1月27日 (一) 16:38 (UTC)[回复]
(+)傾向支持:若技术上能实现,个人支持。Jyxyl9批判一番 2020年1月28日 (二) 12:55 (UTC)[回复]

現時已經有千多個檔案被刪除了,是不是沒有人幫手做呢?--Wpcpey留言2020年11月10日 (二) 00:35 (UTC)[回复]

罗马尼亚乡份按县分类

是否可以帮助将分类:罗马尼亚乡份中的条目,按照分类:罗马尼亚县份分类:罗马尼亚行政区划进行分类呢?谢谢。--Aronlee90 Bashing Commies: A Good Cockroach is A Dead Cockroach. 2020年6月12日 (五) 12:25 (UTC)[回复]

@Aronlee90其實沒懂您意思。--Hamish 2020年6月12日 (五) 12:27 (UTC)[回复]
就是罗马尼亚乡份这个内含条目过多,按照罗马尼亚的行政区划,不同的乡隶属于不同的县,所以是否可以用机器人完成把所有乡按照隶属的县的方式进行分类?比如类似这个:分类:戈尔日县乡份。--Aronlee90 Bashing Commies: A Good Cockroach is A Dead Cockroach. 2020年6月12日 (五) 12:30 (UTC)[回复]
所以是要機器人從條目中提取屬於哪個縣,然後再進行分類,對嗎?--Hamish 2020年6月12日 (五) 12:35 (UTC)[回复]
对,比如刚才那个例子,已经有template:Covasna County,里面已经分类好了,按这个就可以,参见Category:羅馬尼亞行政區劃模板。每个乡的条目内应该也有所隶属的县。--Aronlee90 Bashing Commies: A Good Cockroach is A Dead Cockroach. 2020年6月12日 (五) 12:43 (UTC)[回复]
@Aronlee90您可以直接在縣模板加入縣分類資訊,這樣能省很多工。可參考模板:戈爾日縣, 薩馬里內什蒂鄉。 --Kanashimi留言2020年6月18日 (四) 14:01 (UTC)[回复]
非常感谢。--Aronlee90 Bashing Commies: A Good Cockroach is A Dead Cockroach. 2020年6月18日 (四) 14:29 (UTC)[回复]
@Aronlee90:此請求是否還有需要?-- Willy1018留言2020年9月14日 (一) 03:54 (UTC)[回复]
有的,您有什么好方法吗?--Aronlee90留言2020年9月14日 (一) 03:57 (UTC)[回复]
修改模板,例如將Template:Prahova County加入分類到羅馬尼亞普拉霍瓦縣,然後將所有聯入到此的模板含有Category:羅馬尼亞鄉份分類的於條目移除。-- Willy1018留言2020年9月14日 (一) 04:09 (UTC)[回复]

清理Template:Short description用法錯誤

Template:Short description僅在英文維基中使用,若內容與維基數據相同則移除,剩下以人工檢查,彙整至維基數據。 Willy1018(留言) 2020年6月22日 (一) 06:39 (UTC)[回复]

字词转换处理

批量转换音乐录影带为“音樂錄影帶”,已知简体版本会使得Module:CGroup/Music中的相关项无法正确转换。--百战天虫留言

把{{coord}}的信息转移到wikidata

大家好!我最近建立了不少北京通州的条目,并且放上了坐标。发现地图无法显示。原因是地图的数据来源是wikidata。请问能否帮忙把我创建的条目的坐标批量转移到wikidata,并且将条目原有模板的坐标删除(删除后,模板会自动使用wikidata的数据)。如果可以,也可以把所有条目都这样处理。--維基小霸王留言2020年12月16日 (三) 07:48 (UTC)[回复]

希望以機器人自動維護中國大陸行政區劃條目及相關數據

  1. 我偶爾會發現一些中國大陸行政區劃條目有錯誤,例如「Talk:永安坝水库#請問下面這兩個條目是否相同」,其問題出於中國大陸國家統計局數據更新,但維基這邊沒跟上。
  2. 又用模板語法產生的消歧義頁面也會出錯,例如梅岭镇條目,此條目中一個有連結一個沒有是我刻意作的對比,梅嶺鎮 (詔安縣)修復後因為連結正確可以正常顯示,梅嶺鎮 (南昌市)則因連結到重定向的維基數據頁面而出錯),想請問有沒有可能自動化維護,謝謝大家。--迴廊彼端留言2021年4月16日 (五) 15:06 (UTC)[回复]
這一系列當初是Liangent花費心力處理的。您可提交互助客棧以獲得更廣泛的可行性、實際運作機制是否要大幅改版的討論。 --Kanashimi留言2021年4月16日 (五) 22:00 (UTC)[回复]
@Kanashimi感謝您的回應,我先前有在技術客棧提起過,因為無人回應,我想說這是純粹技術問題就拿過來了。前者我不確定有沒有可能,但後者單純把維基數據重定向頁修正為直連應該是必要而且可行性高,要不是我之前有碰過相關模板,看到沒實際消歧義功用、又沒辦法直接調整的頁面還真的會傻眼,何況這類條目甚多(單單此頁面上級分類Category:三字中国镇名消歧义就有兩千多個,還有鄉名、二字、四字等等)根本無法以人力一一檢查,所以採用機器人處理恐怕是唯一有效解法。
又方便的話也希望@Liangent瞭解一下相關狀況,並處理Gerrit:667374,謝謝辛苦。--迴廊彼端留言2021年4月17日 (六) 14:13 (UTC)[回复]
這邊是覺得現在的運作機制不易維護。假如想方便修改,可能得改變運作機制。不過這傷筋動骨非常麻煩,也還沒想出什麼好的運作機制。--Kanashimi留言2021年4月17日 (六) 21:39 (UTC)[回复]
行政区划的变动往往需要人工判断,尤其是一些冷门的区划调整,根据现有资料难以开展机器人维护,建议驳回此案。不过我倒是建议可以开一个行政区划错误反馈的计划页面,以收集错误报告。—MintCandy♫ 欢迎参加浙江专题 台州专题 2021年4月18日 (日) 01:16 (UTC)[回复]
@MintCandy后面这个提议不错。--Hamish with w. 2021年4月25日 (日) 23:34 (UTC)[回复]
感謝各位回應,我本來是想說看有沒有什麼辦法自動定期取得中國大陸國家統計局那邊的數據(例如用網址檢查各地區代碼是否存在?),並即時更新,如果有技術困難就算了。不過也想請各位討論一下我的提案二,這種修復重定向的機器人之前已有,只是我不確定能不能做到跨維基計畫的層級。--迴廊彼端留言2021年4月26日 (一) 07:24 (UTC)[回复]
刚刚花了半个多小时,大概是摸透了这个模板的运作机制,自动定期取得数据是可行的,但是即时更新似乎有点不太行,因为如果存在变动,需要人工判断是不是同一个行政区划,毕竟官方那边只给你变动前后的数据,而不会给其对应之前的数据是哪个,如果要改,用机器人改,就只能光更新prc admin list那边的数据,而无法跟条目内做到更新,其本质上是一样的,就算能够自动检测引用了废弃区划代码的页面,亦是需要人工去做修改,而达不到自动更新的目的,除非国家那边能给出对应差异,或者有人能够坚持人工维护,不然这个提案基本不会成功。--Hamish with w. 2021年4月28日 (三) 00:27 (UTC)[回复]
@迴廊彼端另外您的第二条是指做这类更改吗?--Hamish with w. 2021年4月28日 (三) 00:32 (UTC)[回复]
@Hamish謝謝辛苦,雖說有這樣的限制,但對於使用大量模板建立的條目(例如永安坝街道)還是挺有助益的,建議至少可以透過機器人定時更新列出「引用廢棄代碼的頁面」清單,甚至可以進一步分省讓各省主題小組去處理。
第二部份確實是做類似的修改沒錯,不過 wikidata-original-name 參數我在想要不要動,因為 Wikidata 那邊規定標籤「不放主空間條目名稱中的消歧義括號」,帶括號的名稱未來可能仍須修改。--迴廊彼端留言2021年4月28日 (三) 01:38 (UTC)[回复]
@迴廊彼端第一个如果是要建立这种清单分类也可以,我可以尝试着做,而且应该也能做得出(我不鸽的话lol),第二个嘛,已经在做了,但是我只会修改wikidata这个参数,wikidata-original-name我的想法是目前先不动,之后再说。--Hamish with w. 2021年4月28日 (三) 01:43 (UTC)[回复]
@Hamish那真是太棒了,建議第一個清單可以採取類似User:Cewbot/需要修正的跨語言連結的格式不要用分類,不然分類一次只能看兩百個有點麻煩;第二項我與你想法相同,期待您的成果:)--迴廊彼端留言2021年4月28日 (三) 02:22 (UTC)[回复]
相關討論: 維基百科:互助客棧/條目探討#中国乡级行政区模板的严重问题! --Kanashimi留言2021年11月28日 (日) 07:36 (UTC)[回复]

添加{{lang}}模板

希望能在https://zh.wikipedia.org/wiki/Special:%E7%94%A8%E6%88%B7%E8%B4%A1%E7%8C%AE/Trymybestwikipedia 這些頁面中加入{{lang}}模板──以上未簽名的留言由Jonathan5566討論貢獻)於2021年5月9日 (日) 02:48‎加入。

请求自动为已上新闻动态的条目的讨论页添加{{ITNtalk}}模板

请问各位维基人,是否可以自动为上了新闻动态的条目的讨论页添加Template:ITNtalk{{ITNtalk}}模板。谢谢大家!——Zzhtju留言2021年5月16日 (日) 13:19 (UTC)[回复]

@Zzhtju 每一則新聞往往有多個連結,難以判斷應該是哪個文章該標上這個模版。有的時候甚至有兩個以上的文章需要標此模板,例如2021年11月8日。 --Kanashimi留言2021年11月28日 (日) 07:30 (UTC)[回复]
已经上新闻动态的条目,不是已经确定到底哪个或者哪些条目是主要新闻动态的条目了吗?就是加粗的那个。--Zzhtju留言2021年11月29日 (一) 11:31 (UTC)[回复]
看起來並不是所有申請都採用{{Itn}}... e.g., 維基百科:新聞動態候選/存檔/2018年10月 --Kanashimi留言2021年11月29日 (一) 11:54 (UTC)[回复]
能麻烦您解释一下吗,我没太看懂。--Zzhtju留言2021年11月29日 (一) 13:16 (UTC)[回复]
假如所有新聞動態申請都採用了相同的格式,那機器人就能很容易做出判斷。但假如採用的是複雜的格式,可能就涉及必須解析wikitext的問題。雖不是不可能,但這樣的機器人比較容易出錯,並且會複雜得多。--Kanashimi留言2021年11月29日 (一) 20:57 (UTC)[回复]
那请问为最通用相同的格式的添加也不太现实吗,另外请问一下2018年10月的存档格式好像也没有区别。--Zzhtju留言2021年11月30日 (二) 04:15 (UTC)[回复]

清理引用

MediaWiki_talk:Spam-blacklist,列表[1][2][3][4][5]。--安忆Talk 2021年8月8日 (日) 08:45 (UTC)[回复]

Wikipedia:命名常規#地名修改地名分類

除區劃條目自身以外,涵蓋某一行政區全境內情況的條目、模板、分類等,其命名均應採用區劃全稱,如「廣東省行政區劃」、「山東省經濟」、「Category:北京市建築物」等,而不應使用「廣東行政區劃」、「山東經濟」、「Category:北京建築物」等來命名。

希望用bot完成加上「省」、「市」後綴的工作。ghren🐦吱吱吱...🔊 2021年10月18日 (一) 08:58 (UTC)[回复]

撤回请求--ghren🐦吱吱吱...🔊 2021年11月6日 (六) 15:58 (UTC)[回复]
我反而希望这么改。--Johnson.Xia讨论·贡献·成就2021年11月20日 (六) 18:33 (UTC)[回复]
@Johnson.XiaWP:VPP互撕中,你去看看。--ghren🐦吱吱吱...🔊 2021年11月23日 (二) 05:36 (UTC)[回复]

模板升级

对于Template:Infobox Weather的旧模板已经升级为Template:Weather box,原先的Template:Infobox Weather语法和Template:Weather box有较小的语法差别,导致不能正常显示气候数据,受到影响的条目数量440个。 --🔨Yxh1433 2021年11月6日 (六) 07:19 (UTC)[回复]

请求修改Wikipedia:每日图片的模板

2014年以前的“每日图片”是这样的:

雷蒂亚铁路Ge 4/4 II列车雷蒂亚铁路Ge 4/4 II列车

雷蒂亚铁路是一家瑞士运输公司,拥有瑞士最大的私营铁路网络。该公司主要经营格劳宾登州的铁路线路,仅有几公里的铁路穿过州境抵达州的首府库尔。几乎整个网络是在格劳宾登州,只有一个站在意大利蒂拉诺。雷蒂亚铁路为许多主要的旅游中心服务,包括圣莫里茨达沃斯。其中一个线路贝尔尼纳铁路穿越贝尔尼纳山口到达意大利边境伦巴第大区蒂拉诺,与意大利铁路连结。2008年,雷蒂亚铁路在阿布拉/伯尔尼纳景观被联合国教科文组织列入世界遗产名单。雷蒂亚铁路有格劳宾登州政府持有51.3%股份,瑞士联邦持股43.1%,4.6%由私人持股,剩下1%有地方社区持股。图为雷蒂亚铁路Ge 4/4 II列车通过瑞士菲利苏尔和维森之间的维森高架桥。


参数为:

| Image = 图片.jpg

| Legend = 条目名

| Content = (一段简介)

后来改版为这样:


参数为:

| type = packed-hover (让简介“浮”在图片上)

| Image = 图片.jpg

| Content = (一段简介)

在此请求将使用上面那种格式的“每日图片”页面,改为使用下面这种格式。--Johnson.Xia讨论·贡献·成就2021年12月6日 (一) 18:59 (UTC)[回复]

修改連結

天水圍站 (西鐵線)天水圍站 (西鐵)天水圍站 (西鐵綫)的連結全部換成天水圍站 (屯馬綫)

元朗站 (西鐵線)元朗站 (西鐵)元朗站 (西鐵綫)元朗西鐵站的連結全部換成元朗站 (屯馬綫)

兆康站 (西鐵線)兆康站 (西鐵)兆康站 (西鐵綫)的連結全部換成兆康站 (屯馬綫)

屯門站 (西鐵線)屯門站 (西鐵)屯門站 (西鐵綫)屯門西鐵站西鐵綫屯門站西鐵線屯門站的連結全部換成屯門站 (屯馬綫)

謝謝!--Choi Chin Long 2021年12月26日 (日) 07:01 (UTC)[回复]

以上重定向基本上符合所有重定向保留條件,歷史重定向不刪除,已全數快速保留;保留的重定向無需修正。--路西法人 2021年12月27日 (一) 02:56 (UTC)[回复]

替换包含gcatholic.com的外链为gcatholic.org

许多天主教相关的条目参考了gcatholic.com的资料,但该网站在几年前以及将域名更换为gcatholic.org,原域名现处于失效状态,这些链接至少有300处之多,故请求机器人协助将条目中所有形如gcatholic.com/*的外链替换为gcatholic.org/*

電影產地模板2

Wikipedia:机器人/作业请求/存档5#電影產地模板,申請將使用{{美國電影}}(669個)、{{Film US}}(130個)、{{FilmUS}}(18個)的條目修改成使用{{美國電影產地}},因要將{{美利堅合眾國電影}}請求移動至{{美國電影}},謝謝。-- 2022年1月13日 (四) 10:12 (UTC)[回复]

  1. t:美國電影t:美國電影產地
  2. t:Film USt:美國電影產地
  3. t:FilmUSt:美國電影產地

--Kanashimi留言2022年1月14日 (五) 09:11 (UTC)[回复]