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

活跃的讨论内容
文章的删除

此頁面曾於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)

  • 确实。而且编辑记录都留着,实在要查也不担心记录丢失。--Tiger留言) 2017年10月15日 (日) 07:18 (UTC)
  • 其實翻歷史也很麻烦......存檔更好吧--PatrollerAAAA討論|留名) 2017年10月15日 (日) 07:34 (UTC)
    • 如果要翻查查询请求本身,确实翻查历史比较麻烦。可以谁会去查这个呢,既然Wikipedia:已删除内容查询/查询里面列出了所有查询记录,直接查这个更快更清楚嘛。Bluedeck 2017年10月15日 (日) 18:52 (UTC)
      • 不如存檔至查詢結果的討論頁吧。--M.Chan 2017年10月17日 (二) 02:48 (UTC)
        • 那豈不是更沒有用了:/ Bluedeck 2017年10月17日 (二) 02:50 (UTC)
          • 有時會說兩句:「話說回來這條目不應快速刪除呀。」我會好奇看看。--M.Chan 2017年10月17日 (二) 07:54 (UTC)
            • 那好吧,既然有一点用,那就存档好了。Bluedeck 2017年10月18日 (三) 17:54 (UTC)

標題编辑

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

谢谢,这个是旧系统沿用造成的问题,已经更新了。Bluedeck 2017年10月18日 (三) 17:55 (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:ARBluedeck 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)
  • 查詢已刪除的「其他用戶的User頁或其子頁面」是否需要限制?--Mewaqua留言) 2017年10月13日 (五) 02:47 (UTC)
    • (+)支持上面的意見。--【和平至上】💬📝 2017年10月13日 (五) 14:41 (UTC)
      • 个人认为等同对待,因为这是CC协议赋予的权利。不过可以理解用户不想被看自己的内容的情况,所以这个情况可以讨论。Bluedeck 2017年10月16日 (一) 07:31 (UTC)
  • (+)支持 Why not? : ) --It's gonna be awesome!Talk♬ 2017年10月16日 (一) 08:13 (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:已删除内容查询是否允许查询明显的人身攻击内容?编辑


如题。--E8×E8132) 2018年2月21日 (三) 04:01 (UTC)

  • 不允許。--安迪4討論|留名) 2018年2月21日 (三) 04:09 (UTC)
    • 现在有很多攻击其他用户的页面被查询后贴了出来。--E8×E8724) 2018年2月21日 (三) 04:17 (UTC)
      • @Bluedeck:請看一下你這次查詢的全部頁面,一堆屬於人身攻擊的,請求處理。--Zest 2018年2月21日 (三) 05:24 (UTC)
        • 我认为是可以的,之前也查询过类似“fuck”这样的页面。我在这里的标准同于RRD2一致,即“破坏、辱骂、人身攻击所造成的伤害能够通过单纯退回而消除则不需要RRD”,这种可以查询。个人认为“X是笨蛋”、“Y是狗屎”、“Z不得好死”均属于这类谩骂。另一方面,“X暗地勾结市长进行杀人活动”、“Y暗地里进行女厕所偷窥”、“Z的屁股上面有个痣”这种则需要RRD,而不能查询。请问这个标准是否合适?Bluedeck 2018年2月21日 (三) 09:05 (UTC)
          • 單純意見,此不屬任何方針指引,我反對提高任何沒意義、沒營養,單存發洩、謾罵的歷史能見度。--Zest 2018年2月21日 (三) 10:11 (UTC)
            • 这个页面的本意应该是把还有抢救价值的条目拖回来使作者能改进吧?不过好像找不到该页面相应的方针?--E8×E834) 2018年2月21日 (三) 13:00 (UTC)
              • 页面的另一个作用是使得社群得以观察一项删除决定合理与否,从这个角度看,我认为允许查询没营养的人身攻击内容对整个管理员操作的透明度有积极作用。Bluedeck 2018年2月22日 (四) 00:08 (UTC)

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

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

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

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

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

  • (+)支持O1只能由自己查询,除非是管理员需要某些证据(不过那也不用走AR了)。--Yangfl留言) 2018年9月12日 (三) 02:46 (UTC)
  • 诉诸常识。理论上所有提交的内容都依照知识共享协议发布了,隐私内容应该监督。但实际执行中,也应该尊重其他人的意愿,WP:礼仪。--YFdyh000留言) 2018年9月12日 (三) 11:08 (UTC)
  • 如果單純滿足好奇心就不要了。管理人員選舉、需要查案的情況例外。--Temp3600留言) 2018年9月12日 (三) 15:53 (UTC)
  • (-)反对,已经发布出来的内容不存在隐私这一说,G10或O1的页面不应有特例。->>Vocal&Guitar->>留言 2018年9月13日 (四) 00:28 (UTC)
    • 虽然这么说理论上没错,但随意查看别人已删除的内容实在不是得体的行为,而且也会给AR带来不好的影响。至于G10,不涉及用户页不在礼仪范围。--Yangfl留言) 2018年9月13日 (四) 01:17 (UTC)
  • (+)支持,只有用戶本人自己能看。Jane9306·TWICE❤·One In A Million ! 2018年9月13日 (四) 12:10 (UTC)
  • (!)意見 這種情況,就請管理員概括一下內容,不必列出全部歷史 116.192.198.9留言) 2018年9月13日 (四) 12:13 (UTC)
  • 反過來說,查詢已刪內容本身應該提出合理原因,例如要改善條目。因此,查閱用戶子頁面也應該有相對的合理原因才行。—AT 2018年9月13日 (四) 16:43 (UTC)
  • (?)不解那有沒有程式碼可以只讓查詢者看見?-- Sunny00217 2018年9月18日 (二) 14:47 (UTC)
    • 除非我采用特殊的手段,比如查询结果放在站外要求密码的地方,然后把密码发给查询者。如果放在站内,就是大家可见。Bluedeck 2018年9月19日 (三) 03:45 (UTC)
    • 可以用站内的邮件功能发给查询者,只要他绑了邮箱并且没关选项。--YFdyh000留言) 2018年9月20日 (四) 23:46 (UTC)
  • 简单说一下我自己的思路:目前的方针并没有阻止查询的进行,但是我们正在寻求一个新的共识,所以这是可以改变的。我一开始也是持着“已经发布出来的内容不存在隐私这一说”这个观点看的。我认为既然维基百科数据都是公开的,那么可以轻易建立站点收集O1内容。但是随着思考和经历的增加,尤其受到GDPR中“被遗忘权”这一点的启发,我的看法也在渐渐转变。我现在觉得应该在用户自己选择删除页面之后尊重他/她当时的考虑。如果想要看的话,应该问他本人的意见,或者有些重要的理由。这是我现在的想法,我说一下。Bluedeck 2018年9月19日 (三) 03:49 (UTC)
    • 1.用户页的所有权并不属于用户个人;2.个人信息应当寻求OS;3.被遗忘权有较大争议,尚未形成一定的规则。在现有方针下,用户可请求删除,他人也可去查询。我不反对阁下推动修改方针,但我个人会秉持反对的态度。->>Vocal&Guitar->>留言 2018年9月21日 (五) 12:45 (UTC)
  • (!)意見那是否可以加入非用戶本人不給資料?— Sunny00217 2018年9月19日 (三) 19:52‎ (UTC)
  • (!)意見可以把「獲得用戶同意」作為條件之一。——C933103(留言) 2018年9月20日 (四) 05:03 (UTC)
    • 这对于非私人内容可能过于严格和没有必要,用户可能无法联系到。--YFdyh000留言) 2018年9月20日 (四) 23:46 (UTC)
      • 連不到就不能查阿-- Sunny00217 2018年9月25日 (二) 14:02 (UTC)
  • 本站資源蓋應用於改善本站,既然已刪除內容查詢會使用本站資源,那重點就應該在申請是否能夠幫助本站改進。如只在滿足一己好奇,那無論是否用戶頁都應該拒絕相關申請。用戶申請時理應附上理據。只要秉持這個宗旨,亦不必去爭論要不要考慮「被遺忘權」。--J.Wong 2018年9月28日 (五) 17:22 (UTC)
    • 我觉得很多好奇应该是好奇为什么删除或者删除是否合理。这是一种有建设意义的好奇,可以查询。Bluedeck 2018年10月3日 (三) 18:07 (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)

已删除查询改为移动?编辑

既然这样,那好吧,我还是按照原样处理。Bluedeck 2018年10月13日 (六) 18:51 (UTC)

下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

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

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

(其实小的页面也可以直接恢复,移动到上述位置)

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

  • (?)疑問具体是要改什么方针指引?还是讨论而已?是否VPO比较恰当?--Cohaf留言) 2018年10月9日 (二) 01:56 (UTC)
  • @Bluedeck:本人相信伺服器管理人員應該會壓縮資料的…… - まっすろな未来 2018年10月9日 (二) 02:54 (UTC)
    • 回复cohaf:确实不是一个直接修改方针指引的讨论,不过会对删除方针构成一些影响,所以放在哪边都可以吧。回纯白未来:确实采用gzip压缩,但是我认为压缩设置为32kb回溯窗口(具体不知道),应该不会特别有效的压缩50kb的页面。Bluedeck 2018年10月9日 (二) 03:47 (UTC)
  • 前几天在#wikimedia-tech上问过,WMF wiki配置了外部存储text表里只有指针,数据库本身不存历史版本。-Mys_721tx留言) 2018年10月9日 (二) 06:42 (UTC)
    • 所以大家的结论是继续复制text嘛 >< Bluedeck 2018年10月9日 (二) 17:45 (UTC)
  • 虽然“不要担心性能”,但所有版本另复制一份,感觉确实不太好,对执行人和系统的编辑数也有注水。但是,如果是直接移动,不是与存废复核流程差不多了吗,当查询的页面要复核/复原时怎么处理。--YFdyh000留言) 2018年10月9日 (二) 23:21 (UTC)
  • 如果操作流程是:创建条目A,删除条目A,复原并不留重定向移动至“AR/查询A”。那么此后,管理员再次查看条目A的已删除版本时将不会看到之前被删除的版本,因为这些版本现在在“AR/查询A”。如果确实时如此操作,那么最终结果对于其他站务还是有一定影响的。--Tiger留言) 2018年10月10日 (三) 01:21 (UTC)
    • 管理员会看到移动记录里面有移动到了AR/查询/A的记载的,应该没有导致紊乱的危险。Bluedeck 2018年10月10日 (三) 05:14 (UTC)
  • 小心被搜尋引擎看到。--Temp3600留言) 2018年10月10日 (三) 06:24 (UTC)
  • (-)反对:若是在条目A又新建新內容呢?(機率造成歷史資料不一)-- Sunny00217 --邀請你一同關注歷史上的今天 2018年10月12日 (五) 13:13 (UTC)
  • (-)反对:如果有多於一人重複查閱同一頁面的話,會造成不便。Sæn請多多關注香港西九龍站條目同行評審 2018年10月13日 (六) 07:49 (UTC)

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
回到项目页面“已删除内容查询”。