跳转到内容

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

页面内容不支持其他语言。
本页使用了标题或全文手工转换
维基百科，自由的百科全书

本页面曾于2014年1月25日被送交存废讨论，讨论结果为保留。

服务名称

[编辑]

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

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

是否存档已删查询请求的段落

[编辑]

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

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

标题

[编辑]

标题应该使用条目名称，而不是“已删除内容查询”。--M.Chan 2017年10月17日 (二) 07:57 (UTC)[回复]

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

已删除内容查询公开化

[编辑]

本主题或以下段落文字，移动自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:已删除内容查询是否允许查询明显的人身攻击内容？

[编辑]

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


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

“无争议页面直接复原”节

[编辑]

请加入有关O7的附注。Sænmōsà中动员令：为西雅图桥梁列表消绿 2018年7月13日 (五) 12:19 (UTC)[回复]

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

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

[编辑]

本主题或以下段落文字，移动自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)[回复]

已删除查询改为移动？

[编辑]

本主题或以下段落文字，移动自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的积压

[编辑]

本主题或以下段落文字，移动自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使用限制

[编辑]

本主题或以下段落文字，移动自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积压

[编辑]

本主题或以下段落文字，移动自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”