维基百科

维基百科讨论:已删除内容查询

（重定向自Wikipedia talk:条目找回）
Jimmy-bot在话题“WP:AR積壓”中的最新留言：2年前
了解更多有关此页面的信息

本頁面曾於2014年1月25日被送交存廢討論，讨论结果為保留。

服务名称

最新留言：在7年前发布3条留言2人参与讨论

当初使用查询而非请求，主要的考虑是更加亲民。现在这个名字已经使用了多年，将名字套用到公开页面上，令老用户熟悉。Bluedeck 2017年9月20日 (三) 15:42 (UTC)回复

感觉请求对机制阐述更明确，查询像是人机自动服务。“已删内容查询请求”？--YFdyh000（留言） 2017年9月28日 (四) 23:22 (UTC)回复
嘛，我老觉得请求给人一种成功希望不大的感觉，而这个几乎一定会成功（一般只有碰到侵权才会查不到），所以就没叫做请求。Bluedeck 拉斯維加斯槍擊案 2017年10月10日 (二) 07:23 (UTC)回复

是否存檔已刪查詢請求的段落

最新留言：在7年前发布8条留言4人参与讨论

是否像一般WP页面那样，存档每个查询请求的段落？还是像原来一样，段落用后不存档直接删除，仅存档查询得到的结果？（不论如何，查询结果一定是存档的）

出现这个问题的原因是，AR中的请求基本没有什么讨论，所以存档讨论像是一种浪费。而且之前不存档运行的也挺好。所以我觉得可以不存档留言。虽然存档也没有坏处。Bluedeck 2017年10月12日 (四) 21:02 (UTC)回复

標題

最新留言：在7年前发布2条留言2人参与讨论

標題應該使用條目名稱，而不是「已删除内容查询」。--M.Chan 2017年10月17日 (二) 07:57 (UTC)回复

谢谢，这个是旧系统沿用造成的问题，已经更新了。Bluedeck 2017年10月18日 (三) 17:55 (UTC)回复

已删除内容查询公开化

最新留言：在6年前发布38条留言16人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2017年11月6日 (一) 08:42 (UTC)。回复

已删除内容作为一个公开服务是我从一开始就有的设想。WP:AR是最开始创建的页面。但是当时社区没有同意我在那边运作，所以我把这个服务放在自己的用户页进行。那么现在这个功能已经越来越完善，并有着多项的配套设施，不知道大家的想法改变了没有。

  • 关于已删查询公开化，主要的问题是这样的。
    1. 已删查询本身不适合作为一个大量常用的功能提供。维基百科的数据结构是自增id表，因此查询时所有数据都复制了两份，效率很低。也许服务器处理期间我们不需要考虑，但是大量查询的磁碟成本是显著的。因此已删查询还是劣于页面恢复，只能作为临时解决方案。
    2. 已删查询模糊删除和不删除的界限。当然这就是已删查询的作用所在。那么这样究竟好不好，就是另一个问题。
    3. 误操作（忘记flood）容易冲刷最近更改。我在查询的时候曾多次冲刷RC，白磷肯定深有体会。
    4. 懒惰的 Bluedeck 至今还在采用 sync XHR 作为插件通信机制，导致管理员端插件在查询时会冻住查询用的tab。
  • 公开化对已删查询的好处
    1. 提高知名度，使更多人知道和使用。
    2. 目前已经提供任何管理员都能使用的管理员端查询工具。
    3. 用户用的已删除查询插件可以经过非常简单的修改就转而po到公开已删查询页面上。
    4. 虽然目前和可预见的将来，Bluedeck 能够轻易处理所有请求，但是将这项服务转变为不依赖某一个管理员的活跃度的服务总是一件好事。

那么就是这样，请问大家怎么看。Bluedeck 2017年9月18日 (一) 13:46 (UTC)回复

現有的存廢覆核請求已提供最後版本索取功能，是否有必要另闢頁面處理是項請求？——Aotfs2013 留於 2017年9月18日 (一) 14:17 (UTC)回复

跟已删查询相比那个功能和DRV的程序混杂在一起，又不能提供完整历史，也没有插件之类的，并不是一个质量的服务。因此，我的想法是，DRV专心DRV，已删查询服务转到AR，让专业的来。Bluedeck 2017年9月18日 (一) 16:06 (UTC)回复
同意。DRV的重心，在於判斷AFD有否流程上的失誤、或有新的重要證據出現，以致AFD結果需重新考慮。這和AR的目的顯然不一致。"已删查询模糊删除和不删除的界限"的問題不難解決-規定NOINDEX、查詢後一段可以CSD就可以解決。--Temp3600（留言） 2017年9月18日 (一) 18:50 (UTC)回复
其实我觉得弄个Deletionpedia放着更好--百無一用是書生 (☎) 2017年9月19日 (二) 02:11 (UTC)回复
  • 条目被删除不等于全无所用，找回被删页面不但可作为改善条目的基础，也具有研究用途，可了解条目先前被删除的原因，有助于方针指引的修订与执行。目前DRV只发送源码，无法查阅条目的编辑历史及过往编辑版本，而且英文版提供刪除頁面查閱服务未见出现乱子，在本地提供有助监察使用情况，站外服务则难以本地控制，实无依赖站外服务之必要。--Thomas.Lu（留言） 2017年9月19日 (二) 03:52 (UTC)回复
中文版的Deletionpedia好像见过两个，但好像之后像是雷声大，雨声小。——路过围观的Sakamotosan 2017年9月19日 (二) 04:02 (UTC)回复
其一[1] 不過已經沒更新了，如果要搞一個刪除wiki則除了侵權和人身攻擊不收其它都收。--Zest 2017年9月19日 (二) 07:42 (UTC)回复
labs上可以放一个？--百無一用是書生 (☎) 2017年9月19日 (二) 09:33 (UTC)回复
(＋)支持，因關注度刪掉連最後版本都無法看見，深受其害。--owennson（聊天室、獎座櫃） 2017年9月19日 (二) 11:43 (UTC)回复
我心目中的理想情况是将已删查询wikitext和查询时间点parse出来的HTML存到独立的服务器去，目的是可以设定一个有效期限（比如180日），这样就可以放心的大量查询，而不用考虑磁碟问题。Bluedeck 2017年9月19日 (二) 11:51 (UTC)回复
[2]wiki已经初步架好，有人感兴趣吗？--百無一用是書生 (☎) 2017年9月20日 (三) 14:10 (UTC)回复
站外查询储存需要储存html而不是wikitext，所以维基系统反而不适合储存维基查询结果。这个原因是，wikitext会实时展开模版，所以要么在本地维基查询然后实时展开本地模版；要么储存查询请求当时渲染好的HTML，呈现时直接呈现成品HTML。不过如果不在乎这个问题，shizhao的deletepedia是更优的选项。Bluedeck 2017年9月20日 (三) 15:27 (UTC)回复
deletewiki是个不错的想法。之前我就有想过把所有挂上CSD、进入AFD的条目自动转存到外部的维基上。单纯存储维基代码，即使无法正常显示模板，但也方便大致了解条目内容以及再利用这些文字。--Tiger（留言） 2017年9月20日 (三) 15:47 (UTC)回复
问题不止这些吧，例如收录规则：是自动收录还是手工提交收录，收录标准是什么（除侵权和G11以外？）；管理规则：谁能当管理员；编辑规则：开不开放普通编辑。即使是单纯收录解释后的页面，也需要先考虑如何制定这些东西。——路过围观的Sakamotosan 2017年9月21日 (四) 01:02 (UTC)回复
根据我对其他几个Deletionpedia的初步观察，都是自动收录为主，手工为辅，存档性质的。收录标准大致是除了侵权、人身攻击和涉及隐私之外被删除的页面（有些似乎只是收条目），另外也允许其他人提删已收录页面（因为侵权、人身攻击和隐私，也可能包括作者或条目相关利益方的诉求，毕竟介绍自家的东西放在Deletionpedia算不上好）。大部分Deletionpedia是不开放编辑的（可以向管理者请求账号和权限），少数开放编辑，毕竟只是存档，编辑也就是一些修复性工作。另外，toollabs理论上不允许架设的mediawiki搞开放编辑。要做的话，学习他人经验很重要--百無一用是書生 (☎) 2017年9月21日 (四) 02:18 (UTC)回复

余试用之，自觉该功能甚佳。自己还是新手的时候，犯了一些错误，导致条目被因为关注度和无来源提删掉。现在看来，错误极为幼稚。有时候这种功能就是一种警示，给后来者看看这个页面是因为什么删掉了，以提供重建时的借鉴。(＋)支持。--雲間守望 · 留言💬 2017年9月29日 (五) 15:00 (UTC)回复

似乎在公示前收不到更多意见了，那么公示14日，如果没有人反对，则着手修缮和开放WP:AR。Bluedeck 2017年9月25日 (一) 18:13 (UTC)回复

几天测试下来，wmflabs的性能实在太差，导入个页面就超时的一塌糊涂。如果要架个wiki存档，看来还是要另找地方才行，或者弄个基金会的Cloud VPS可能会好点--百無一用是書生 (☎) 2017年9月28日 (四) 07:10 (UTC)回复
如果有非管理员以非公开的方式存储了被删条目，是否可以协助处理“已删内容查询”请求？--Tiger（留言） 2017年9月29日 (五) 23:24 (UTC)回复
当然可以，这个服务的目的就是搭建一个不正式、非常容易操作和使用的沟通平台，任何人的帮助都是欢迎的。甚至user:bluedecklibrary中存储的内容也可以用于这个目的。Bluedeck 2017年10月1日 (日) 03:24 (UTC)回复
公示期间还剩7日。Bluedeck 2017年10月2日 (一) 22:52 (UTC)回复
公示期间还剩2日。Bluedeck 拉斯維加斯槍擊案 2017年10月7日 (六) 20:14 (UTC)回复

  WP:AR已經重新開放，新請求在彼處受理。接下來的一個月裡，介面將稍做改動，user talk:bluedeck 的已刪除內容查詢將逐漸關閉，插件所po請求也會轉而投遞至WP:AR，DRV等其他頁面的措辭也會相應修改。謝謝大家的討論。Bluedeck 拉斯維加斯槍擊案 2017年10月10日 (二) 02:00 (UTC)回复

WP:RFUD似乎重定向到Wikipedia:存廢覆核請求會比較好？--A2093064#Talk 2017年10月10日 (二) 07:11 (UTC)回复
似乎是的 Bluedeck 拉斯維加斯槍擊案 2017年10月11日 (三) 23:10 (UTC)回复
哦，不是的，RFUD之所以重定向给AR，是因为英维就是如此做的。Bluedeck 2017年10月12日 (四) 16:41 (UTC)回复
這是因為英文版的RFUD有恢復頁面的功能（例如英文維基速刪G13的恢復，在中文版可以想成請求恢復被CSD O1或G10刪除的頁面），但在中文維基這應該到WP:DRV進行，現在WP:AR應該是沒有接受恢復頁面請求。--A2093064#Talk 2017年10月13日 (五) 04:35 (UTC)回复
英文RFUD：Please note that this page is NOT for challenging the outcome of deletion discussions or to address the pending deletion of any page。所以RFUD和AR的作用是一样的，只不过RFUD把页面直接放到草稿，而不使用插件整个页面复制一遍（其实是更好的做法）。在实际处理AR的时候，AR也曾直接恢复草稿页面。Bluedeck 2017年10月18日 (三) 17:52 (UTC)回复
  • 看过WP:AR有个疑问：已删除的内容仍然需要署名吗？在AR可否仅提供最后版本？是否必须像Bluedeck先前在自己的讨论页提供的信息一样，给出编辑时分、用户、页面大小、版本号、编辑摘要？--Tiger（留言） 2017年10月10日 (二) 12:27 (UTC)回复
如果使用蓝桌插件，那么就自动生成这个包含完整信息的列表。手动操作过于繁琐，不可能把整个历史存档起来，因此，推荐使用该插件（第四个）。然而，如果不想使用插件，执行查询的管理员想给出某个特定版本当然可以。比如，可能某个页面所有版本的差别都不大，而且主要作用是重写条目的话，那就只贴出内容最丰富的版本就好。如果用户进一步要求，再给出更多版本。Bluedeck 拉斯維加斯槍擊案 2017年10月11日 (三) 23:07 (UTC)回复
所有被删除内容直接通过Data Services查询数据库就好了:
MariaDB [zhwiki_p]> SELECT ar_id,ar_title,ar_user,ar_timestamp from archive where ar_title = "研鼎崧圖";
+---------+--------------+---------+----------------+
| ar_id   | ar_title     | ar_user | ar_timestamp   |
+---------+--------------+---------+----------------+
| 2984638 | 研鼎崧圖     | 2208492 | 20151225073237 |
| 2984639 | 研鼎崧圖     |  687728 | 20151225105745 |
| 2984640 | 研鼎崧圖     |   90660 | 20171019094401 |
| 2984641 | 研鼎崧圖     |   90660 | 20171019094558 |
+---------+--------------+---------+----------------+
4 rows in set (1.32 sec)

--百無一用是書生 (☎) 2017年10月27日 (五) 02:18 (UTC)回复

Wikipedia:已删除内容查询是否允许查询明显的人身攻击内容？

最新留言：在6年前发布9条留言5人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2018年3月4日 (日) 00:42 (UTC)。回复


如题。--E8×E8（132） 2018年2月21日 (三) 04:01 (UTC)回复

「無爭議頁面直接復原」節

最新留言：在6年前发布2条留言2人参与讨论

請加入有关O7的附註。Sænmōsà中動員令：為西雅圖橋梁列表消綠 2018年7月13日 (五) 12:19 (UTC)回复

谢谢建议，长期以来没看到，现在已经完成了。Bluedeck 2018年9月26日 (三) 17:36 (UTC)回复

查询用户自己删除的内容是否合适呢？

最新留言：在6年前发布24条留言12人参与讨论

本主題或以下段落文字，移動自WP:VPP。执行者：B dash（留言） 2018年10月16日 (二) 13:20 (UTC)。回复

是否可以查询Wikipedia:已删除内容查询#User:DGideas/oops类似这种呢？如果用户有不再想让大家看到的内容，我们是否应该让用户有权拒绝将这个内容公之于众呢？我觉得这不是应该由我一个人决定的问题。我征求一下社区的意见。Bluedeck 2018年9月11日 (二) 21:27 (UTC)回复

那么就这个讨论而言，得出结论是需要用户本人同意，或者有些重要的理由（比如内容是有价值的条目等）可以查询作为结果，这样可以吗？Bluedeck 2018年10月1日 (一) 22:43 (UTC)回复

其实管理员认可就可以，私下查询也没人知道不是吗。--YFdyh000（留言） 2018年10月4日 (四) 03:36 (UTC)回复
因为不想让这件事情就按照执行的管理员的心情来办，因此才希望弄个清楚的。如果这样的话私下查询应该也遵守这样的规则了。Bluedeck 2018年10月5日 (五) 15:49 (UTC)回复
( ✓ )同意-- Sunny00217 2018年10月8日 (一) 13:11 (UTC)回复

已删除查询改为移动？

最新留言：在6年前发布15条留言11人参与讨论

本主題或以下段落文字，移動自WP:VPP。执行者：B dash（留言） 2018年10月22日 (一) 07:51 (UTC)。回复

既然这样，那好吧，我还是按照原样处理。Bluedeck 2018年10月13日 (六) 18:51 (UTC)回复
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

对于大的页面，这个功能占用数十MB磁盘。举一个最近遇到的比较极端的例子，一个页面500+版本，每个版本50+kb，查询一次约消耗25MB磁碟。加上数据库结构文件可能比25MB还大一点。

小的页面没什么问题，但是我想当遇到100个以上版本的已删除，能不能直接恢复到WP:已删除内容查询/查询中去，不用特别的复制一份呢？反正效果其实不差。

（其实小的页面也可以直接恢复，移动到上述位置）

虽然说不要在意性能，但是既然效果完全一样，那么是否可以通过这个方法节约一点磁盘呢？之前曾有人跟我说过这样的话删除不是跟没删一样了吗。但是英文版就是这样，有想要的会恢复。而且目前的查询和恢复也相差无几了。Bluedeck 2018年10月8日 (一) 23:52 (UTC)回复

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

WP:AR的积压

最新留言：在3年前发布10条留言6人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2021年8月2日 (一) 08:14 (UTC)。回复

WP:AR里有约20个请求的积压. 有管理员会去处理吗  囧rz…… --Yining Chen（留言|签名） 2021年7月19日 (一) 12:50 (UTC)回复

有個可行的方案，就是把Brror（對話頁 | 用户貢獻）閣下送到rfa，不知道您接受嗎？--Papayatrash｛留言｝ 2021年7月19日 (一) 12:59 (UTC)回复
这个似乎非管理员也能做？可以考虑成立一个组织（类似WP:485）去做这个事情。不知道可不可行。--Lightyears GBAW 2021年7月19日 (一) 13:44 (UTC)回复
有些页面可以通过蓝桌图书馆等方式查询，但有些查不到，需要管理员；Brror阁下应该是能查的都查了。我建议有一定经验的维基人提AR请求时，先在蓝桌图书馆、已删百科等地方查询，查不到再提报；并在提报时标注“请管理员查询”或直接写一个sysop。至于RFA，要看Brror阁下是否接受。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月20日 (二) 01:54 (UTC)回复
@30000lightyears：問題是現在能查看歷史的人必須有反刪除undelete權限，該權限基本上不太可能下放的（除非有非常合理的原因給基金會願意做個權限如顯示已刪除的歷史viewdeleted）-- Sunny00217  2021年7月21日 (三) 11:42 (UTC)回复
正在询问Brror（對話頁 | 用户貢獻）。--Yining Chen（留言|签名） 2021年7月22日 (四) 03:42 (UTC)回复
用户已接受。--Lightyears GBAW 2021年7月22日 (四) 05:30 (UTC)回复
@Yining Chen：Brror君已经接受提名，您可以提名了。--Lightyears GBAW 2021年7月22日 (四) 05:34 (UTC)回复
  已完成。--Yining Chen（留言|签名） 2021年7月23日 (五) 02:04 (UTC)回复

收緊AR使用限制

最新留言：在2年前发布34条留言11人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/其他/存档/2021年11月。执行者：Eric Liu 創造は生命（留言．留名．學生會） 2021年12月26日 (日) 23:25 (UTC)。回复

明顯不具百科性或是明顯屬於擾亂性內容的不應該被查詢。現行條文不會查詢被修訂版本刪除的內容，嚴格來說其實已經涵蓋。AR本意應該是讓想重新編輯的人找到原本內容，好使其不用從零開始。如果相關內容明顯不具百科性或是明顯屬於擾亂性內容我不認為查詢這些內容有益於建設百科全書。副抄最常處理AR的U:Jonathan5566參與討論-某人✉ 2021年10月16日 (六) 02:09 (UTC)回复

部分AR无需管理员操作，对它们加以限制意义不大。--安忆Talk 2021年10月16日 (六) 02:26 (UTC)回复
多次違反限制就封鎖AR頁編輯不就行了？無需管理員操作不是因此就完全不設限的理由-某人✉ 2021年10月16日 (六) 02:32 (UTC)回复
反對提案。一來查詢明顯不具百科性或明顯屬於擾亂性的內容可能是出於研究LTA行為的目的，二來一般用戶通常不太可能得知自己查詢的內容是屬於明顯不具百科性或明顯屬於擾亂性的內容的情形。就後者而言，我認為提案本身就是在假定惡意。Sanmosa WÖRK 2021年10月16日 (六) 03:40 (UTC)回复
@Sanmosa：那麼我舉個更明確的例子，真有疑慮的話可以放寬為「如有合理理由可以豁免」(例如研究lta行為)-某人✉ 2021年10月16日 (六) 03:57 (UTC)回复

完全重寫header

現行條文

操作幫助：請直接點「提交新请求」，過程簡單，處理迅速。对于绝大多数条目，不需要理由，想看即可查询。处理完成后会通知您查看。

无争议页面直接复原：如果您是自己O1或者G10删除了您自己的页面，我们将不查询而直接恢复这个页面（除非您特别要求仅查询）。类似的，仅因为无人编辑的草稿（O7）和无人使用的模板等页面也将直接被恢复。

注意：

  1. 除上述情况外，本條目找回計劃不能用於直接恢復條目，而是找回頁面的历史版本，以避免您沒保存的工作付諸東流。頁面被刪除都有一定的原因，故此找回的內容也許不適合直接放回被刪除前的地方去——請在這麼做之前將內容修改得符合我們的各項方針。如果您需要對刪除本身進行複核，請前往存廢覆核請求。
  2. 如果你要查询的页面是别人O1的，请向请求删除的那个人索要，而不是在这里提出查询。
  3. 如果你要查询的是模板，请给出理由，否则查询请求会被拒绝。

使用限制：根據維基百科基本原則，侵權文本不能找回，被刪除修訂版本的页面也不能。但是對於侵權頁面，我们可以幫您找回侵權來源和历史版本列表。您可以從侵權來源處下載相應文本。

提議條文

操作幫助：請點「提交新请求」並且填寫查詢原因。請注意不填寫理由將會被直接拒絕。

使用限制：

  1. 如尋求恢復自己O1或者G10刪除了的頁面，或是沒有人編輯而O7的草稿，請移玉步至存廢覆核請求，此處僅處理頁面歷史查詢。
    • 但如果你要查询的页面是别人O1的，请向请求删除的那个人索要，而不是在这里或存廢覆核請求提出查询。
  2. 此處不能查詢被刪除修訂版本的頁面。
  3. 此處不能查詢侵權頁面，但我们可以幫您找回侵權來源。您可以從侵權來源處下載相應文本。
  4. 如無合理理由，此處不能查詢G1，G3或G12的內容。如你認為相關刪除不合理請移玉步至存廢覆核請求。

注意：

本計劃不能用於直接恢復條目，而是找回頁面的历史版本，以避免您沒保存的工作付諸東流。頁面被刪除都有一定的原因，故此找回的內容也許不適合直接放回被刪除前的地方去。請在這麼做之前將內容修改得符合我們的各項方針。如果您需要對刪除本身進行複核，請前往存廢覆核請求。

Tldr幾個主要修改：

  1. 明文規範申請應有合理理由。Xiplus提到基於法律原因已刪內容僅允許管理員可以瀏覽。繞過這個限制必須檢查有關請求是否合理。
  2. 明文規範無爭議頁面還原應前往存廢覆核請求，這種頁面應還原整個頁面歷史。由於AR非管理員亦可處理，這種請求應前往DRV。
  3. 規範G3或G12內容如無合理理由不可查詢，見上討論。
另外，我不反對O7等轉至存廢覆核處理，但請不要超前部屬。--拒食木瓜卄 2021年10月16日 (六) 11:59 (UTC)回复
一案兩提我直接關掉一處我不認為有問題-某人✉ 2021年10月16日 (六) 12:09 (UTC)回复
@AINH：雖然說我沒expect具體提案會轉介G10、O1與O7到DRV，但我認可這樣改。有次我在AR請求恢復自己的子頁面，過了好幾天都沒人處理，結果我放到DRV後才有人在DRV看到並處理了，因此就效率而言轉介G10、O1與O7到DRV是好事。不過有一點想提的是“除非您特別要求僅查詢”這部分，我認為提議條文“使用限制”第一條可增加用戶特別要求僅查詢經G10、O1與O7刪除的頁面的情形，這時候除非查詢的對象是他人的用戶頁（或子頁面），否則一概以查詢一般頁面的程序處理。Sanmosa WÖRK 2021年10月18日 (一) 13:44 (UTC)回复
不太明白你的建議是什麼-某人✉ 2021年10月18日 (一) 22:42 (UTC)回复
@AINH：“如果您是自己O1或者G10删除了您自己的页面，或是沒有人編輯而O7的草稿，我们将不查询而直接恢复页面。但這些類別請移玉步至存廢覆核請求，此處不受理。”改為“如尋求恢復自己O1或者G10删除了的页面，或是沒有人編輯而O7的草稿，請移玉步至存廢覆核請求，此處僅處理頁面歷史查詢。”Sanmosa WÖRK 2021年10月20日 (三) 01:50 (UTC)回复
  • 未見明顯反對，開始公示. CC@AnYiLin、Sanmosa、Jonathan5566：-某人✉ 2021年10月21日 (四) 00:31 (UTC)回复
    • 我来明显(－)反对一下哈。为了说明我的观点，我先提出一个问题，没有理由拒绝查询是吧，那假如说有三个人来查询三个“明显扰乱页面”，分别给出的理由是1）“想看”，2）想亲自确认内容是否符合删除标准，3）可能会有有用的内容但是我看不见所以想查询。请问这三个理由中有哪些是有效理由呢？如果有无效的理由，为什么无效？Bluedeck 2021年10月21日 (四) 05:44 (UTC)回复
      @Bluedeck：一無效，與編輯維基百科無關。二應算為有效。三應該更詳盡地問其查看內容是否有用的目的是什麼，如果他的目的是重寫條目應算為有效，但處理人提供前應先看內容是否有用，如果全文胡言亂語應拒絕並寫明內容無用。而且「沒有理由拒絕查詢」不是我提的，這是U:Xiplus說的。那麼你的反對原因是什麼？-某人✉ 2021年10月21日 (四) 05:52 (UTC)回复
      這個問題無法回答，判斷是否接受查詢還要考慮已刪內容的性質，靈活採取不一樣的處理措施，例如G12內容無法在維基上提供複本，但必要時可以考慮私下郵件提供。視不同的情況可以採取不同的措施：完全拒絕 - 透露內容性質 - 私下提供內容 - 提供最新版本內容 - 提供特定數個重要版本內容 - 提供完整版本內容 - 直接恢復完整頁面。--Xiplus#Talk 2021年10月21日 (四) 06:03 (UTC)回复
    未見對於"一般用戶通常不太可能得知自己查詢的內容是屬於明顯不具百科性或明顯屬於擾亂性的內容的情形。就後者而言，我認為提案本身就是在假定惡意。"的有效回答。--拒食木瓜卄 2021年10月21日 (四) 07:32 (UTC)回复
    條文已經沒用「明顯不具百科性或明顯屬於擾亂性」之類的主觀判斷，已經收窄至「G1，G3或G12」的明確標準-某人✉ 2021年10月21日 (四) 07:38 (UTC)回复
我不喜歡上面的提案內容。--Xiplus#Talk 2021年10月22日 (五) 03:01 (UTC)回复
現行條文

略

提議條文

操作幫助：請點「提交新请求」並且填寫合理的查詢原因，管理員會根據查詢原因決定是否接受查詢。

使用限制：

  1. 本計劃不能用於直接還原頁面，而是找回頁面的历史版本，以避免您沒保存的工作付諸東流。頁面被刪除都有一定的原因，故此找回的內容也許不適合直接放回被刪除前的地方去。請在這麼做之前將內容修改得符合我們的各項方針。
  2. 如果您想要還原頁面的完整歷史（包括但不限於認為相關刪除不合理、想要恢復您自己提刪的O1和G10或被O7刪除的草稿），請前往存廢覆核請求。
  3. 如果查詢的相關內容將再次符合刪除準則（包括但不限於侵權頁面、已被版本刪除、多數的G3和G12頁面），管理員將不會在站內提供相關內容。
    根據您的查詢理由，如有必要，管理員可能會以郵件私下提供、透露內容性質但不提供實際內容、拒絕請求等方式處理。
    侵權頁面可能會以提供侵權來源方式處理。
--Xiplus#Talk 2021年10月22日 (五) 03:02 (UTC)回复
(＋)傾向支持看起来不错。--SD hehua（会客室/欢迎签到） 2021年10月22日 (五) 10:10 (UTC)回复
我主要是因為看到「轉介G10、O1與O7到DRV」才有特別希望同意的理由，只要提案做到「轉介G10、O1與O7到DRV」我都支持。Sanmosa WÖRK 2021年10月22日 (五) 10:14 (UTC)回复
剛做了微調。--Xiplus#Talk 2021年10月26日 (二) 01:44 (UTC)回复

讨论

  吐槽：不能因为AR积压就收紧使用AR的范围啊 --Yining Chen（留言|签名） 2021年11月4日 (四) 13:04 (UTC)回复

WP:AR積壓

最新留言：在2年前发布5条留言5人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2022年3月2日 (三) 16:14 (UTC)。回复

如題，Wikipedia:已删除内容查询，希望有人出來處理--John123521（留言-貢獻） 2022年2月14日 (一) 10:11 (UTC)回复

如果有需求可以去申請的回退員看過濾器日誌，會比較實用。其他積壓需要管理員處理，但看起來無望。--拒食木瓜 2022年2月20日 (日) 03:00 (UTC)回复
被Xiplus清了。--Ghren🐦🕓 2022年2月20日 (日) 08:22 (UTC)回复
希望更多管理員能投入到此類事務上面來。—— Eric Liu 創造は生命（留言．留名．學生會） 2022年2月20日 (日) 11:36 (UTC)回复
添加话题
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:已删除内容查询&oldid=70422227”
返回到项目页面“已删除内容查询”。