维基百科讨论:移動請求

移动请求的计划和排版都不太成熟

请问不知大家（特别是管理员们）看到这一个请求计划页有否觉得十分不成熟呢？排版、留言、意见和投票的安排均十分杂乱；况且已经解决的个案是否应该列入存档中？不知管理员们能否就这几项问题作出一点小改革呢？谢谢。--dbslikacheung 09:58 2007年3月5日 (UTC)

移动

有没有哪位能界定一下“Wikipedia:重复条目”、“Category:需要合并的条目”和“Wikipedia:移动请求”三个页面的分工有甚么不同？

事缘当我动手合并河南郡、三川郡、迦帕多家教父、加帕多家教父时，却被退回了。

查上述两对条目实为积压已久的“Category:需要合并的条目”，前者（三川郡及河南尹）的合并，更是已在“Wikipedia:重复条目”页面经过长足的讨论而达到共识后才进行的。三川郡及河南尹的合并于2009年1月25日08:54被某用户退回，而该用户的再前一项改动则发生于2009年1月25日08:53，足见该用户在进行退回前，对该两条目的合并的前因后果，不可能有超过一分钟的阅读时间去理解。再查该退回合并的用户的其他“用户贡献”，发现该用户实素有盲目退回的习惯。

然而，当我检举该用户的盲回退回时，又被劝喻说“条目不能手动移动，要由管理员处理。”

我见“Category:需要合并的条目”页面只是挂上“本页面是一个积压的工作，需要老练的用户关注”，并没有说非由管理员处理不可。

结果，要做的没人做，大量积压，去做的被人退回，退回者自己又不做。

如果我每次对前两个页面的条目进行合并，都必须被退回且必须送交“Wikipedia:移动请求”页面处理的话，那么干脆只保留“Wikipedia:移动请求”好了，前两个页面要来干嘛？--210.6.97.145 2009年2月7日 (六) 06:11 (UTC)

移动请求和重复条目是完全不同的，移动请求是只有一个条目及内容，当无法移动到新名称时，才需要到移动请求提出；此外，现在也会处理被以剪下贴上移动的条目的编辑历史。由于某些情况下的移动只有管理员可以处理，因此移动请求必须由管理员处理。重复条目则是同时存有两个先后建立的条目，但最后被发现其实是可以合并为一个，因此想将两个的内容合并，并将其中一个改为重定向页；这种工作其实就不需要管理员的权限就可以进行，只是问题常常在于要如何决定将哪个条目改为重定向页？重复条目的处理最难的就是在于如何取得合并的共识。－Alberth2-汪汪 2009年2月7日 (六) 06:35 (UTC)

谢谢回覆，那么，套用到河南郡、三川郡、迦帕多家教父、加帕多家教父这几个案例时，应该如何处理才对？我确实是在“Category:需要合并的条目”找到的，也确实被退回了，而该退回动作也被肯定了，是不是又该交由“Wikipedia:移动请求”处理？--210.6.97.145 2009年2月7日 (六) 07:42 (UTC)

有时候可能只是误会，或许其他人没注意到该页面已经有合并的讨论及共识，这时候建议可以直接去回退者的对话页提出说明、沟通，应该有助于解决争议。另外，也建议在合并同时善用编辑摘要，让他人知道为何自己要做此修改。因为这些动作并不是在进行条目的移动，因此也不需要到移动请求提出。—Alberth2-汪汪 2009年2月7日 (六) 07:52 (UTC)

想问一下，直接手动重定向岂不是让被Ａ条目的原编辑历史停止了？原编辑者的功夫岂不是白费？这种情况不是不应该手动重定向而是由管理员移动再合并编辑历史吗？--91.142.12.62 (留言) 2009年2月7日 (六) 07:58 (UTC)

可以参考Wikipedia:合并和移动页面#如何合并页面，在合并两页面时，编辑历史的合并并非是必须的；目前的作法是认为有此需求的话，可以在合并完成后再至移动请求提出，但提出前此两条目必须先将内容整合完成，才能方便管理员进行编辑历史的合并。不过个人并不建议所有合并的条目都将编辑历史合并，因为会产生让编辑历史混乱的问题，可以参考我在Wikipedia:互助客栈/方针#重复条目之编辑历史是否须合并？提出的讨论，如果有任何建议方式也欢迎一起提出。—Alberth2-汪汪 2009年2月7日 (六) 08:19 (UTC)

Wikipedia:重复条目/存档/2008年中为什么还有未解决便存档的请求？

遇到内容雷同的两个条目究竟是不是应当到Wikipedia:重复条目提出？我发现我在那里提出的请求，结果无非是（一）没有管理员搭理便被存档；（二）被IP用户或管理员手动合并页面，而且这种手动合并的行为似乎也被其他管理员们所默许。于是，遇到铝热剂和铝热法两个应当合并的条目后，我将铝热剂手动合并到铝热法，并在将 Talk:铝热剂 转移至 Talk:铝热法 后，将其提交快速删除。然而该提删页却被管理员挂上了hangon模板，并被提到了Wikipedia:移动请求，要求“合并编辑历史”，致使两者编辑历史混在一起，甚至出现了我将“铝热法”重定向到“铝热法”的记录，我的编辑被回退，并被恢复，最后的页面历史成了这样。难道管理员认为这样互相交错、混乱不堪的编辑历史才是正确的？铝热剂 只有一个主要贡献用户，其内容也大多与 铝热法 相同，手动合并时编辑摘要中已有记录，如果想要看合并前的页面历史，完全可以去相应的页面历史页中看，两者互不影响，然而合并后页面历史中只有页面移动的记录，并没有合并的记录，管理员们却非要使编辑历史变得凌乱，让看页面编辑历史的人一头雾水。如此双重标准，实在令人费解。—Choij (留言) 2009年2月7日 (六) 09:37 (UTC)

你提出的疑问可以分两点来说明：

• 其实Wikipedia:重复条目并不是要由管理员来处理的工作，因为这项工作并不需要管理员的权限，是任何人都可以处理的；而重复条目的合并，确实也就是“手动”将两条目的内容集中在一个上，再将另一个改为重定向。至于未被处理就被存档，你举的例子那就是我的疏忽了......。
• 完成合并后，是否需要将原本的两条目编辑历史跟着合并，这目前尚未有一致的共识，个人也是与你一样认为一般状况下不要合并比较好，因为会让编辑历史交错，难以阅读（可以参考上方“重复条目之编辑历史是否须合并？”一节之讨论）；但是还是有许多人认为为了保留两条目所有贡献者的纪录，应该合并。所以才会有人提出将两编辑历史合并的请求，并获得其他管理员的认同并执行。这个议题确实需要更多人一起讨论，寻找一个两全的解决方案。

—Alberth2-汪汪 2009年2月7日 (六) 13:43 (UTC)

管理员的移动特权

如果有个用户，希望把欧洲封建制度移动到封建制度，那么当然先尝试页面上的[移动]功能。但如果封建制度页面已经存在而无法移动，那么该怎么做呢？

1. 一般用户：到移动请求提出讨论→理据成立→管理员删除封建制度页面→移动完成
2. User:Gzdavidwong：管理员删除封建制度页面→移动完成（当然还要故意在重定向页打错字，使普通用户无法回退移动）

根据快速删除的标准，管理员删除页面以完成移动，是要经移动请求的讨论的。Gzdavidwong未经讨论就删除页面，是否属管理员的职权范围以内呢？请资深维基人和管理员明示。--Nthgd 2009年4月24日 (五) 15:09 (UTC)

关于这次回退移动的操作有待社群讨论，但顺便说一句请两位注意避免移动战—Ben.MQ 2009年4月24日 (五) 15:39 (UTC)

当然除了该有问题的管理员外，我相信绝大部分管理员都是乐意跟社群沟通的，所以在这页提出讨论就是我避免移动战的方法。--Nthgd 2009年4月24日 (五) 15:46 (UTC)

移动请求的页面我觉得主要的目的还是申请。不管是否是要删页面的移动，按理说都是应该是先讨论出共识确定无争议之后才能移。而因为这种情况，虽然有了共识，但没有管理员权限无法移动，才要提请移动请求。（这是技术上的问题）所以重点不是是否提到移动请求，而是移动之前是否有先获得共识（或者确定原有的移动违反方针，所以回退原本的移动），这是我对目前处理方式的看法解读，所以我觉得如果已有共识，或确定原有的移动不符合方针，管理员不经移动请求直接作删除移动本身是没错的（不应多此一举），但如果是没有先取得共识或确定名称及之前的移动不符方针，就作移动就是违反移动条目的原则这是不正确的。（这不管是管理员或一般人都一样）--ffaarr (talk) 2009年4月25日 (六) 02:08 (UTC)

我也认同只要有共识确实不需要多此一举浪费时间；而无法直接移动的页面，更是需要先取得共识。此外，如果真的是故意使一般用户无法移动，这确实是很不妥的行为。—Alberth2-汪汪 2009年4月25日 (六) 11:36 (UTC)

还是我来解释几句吧。首先我早就已经在Nthgd的用户也给出解释了，不过本人并不愿意大家就一些无谓事情花太多吵来吵去。第一，我觉得在大多数情况下，管理员删除页面以便移动并不算什么特权，而我这次也没有滥用任何特权。因为我翻查历史记录，是发现那个页面其实就是在早先没有经过共识讨论而被一个用户移动的，再将原页面进行消歧义，要回退这个移动，也就必须先删除页面——所以这个操作并不违反规则；当然，如果大家认为应该谨慎进行的话，我会接受建议。第二，在移动页面之后对原来标题进行编辑以使其他用户难以移动，这更不是什么权限，也没有违反哪条规则，只不过我也的确意识到这个动作对于作为管理员的本人来说实在欠妥，为此对困扰大家感到抱歉。本人以后移动页面会谨记小心—瓜皮仔＠Canton 2009年4月25日 (六) 13:29 (UTC)

你终于也来了解释，这是好事。我实际上针对的，只是你故意编辑重定向页这个行为，因为你真的可以使普通用户无法移动，要去移动请求提出；换句话说，如果我用同样方法使重定向页无法再移动，你则会用管理员权限可把它删掉再移。虽没滥权，也算用了特权。无论如何，现在事过境迁，也再没讨论的必要。--Nthgd 2009年4月25日 (六) 16:21 (UTC)

提议修改Wikipedia:移动请求之讨论方式

目前移动请求提出后的讨论几乎都是集中在Wikipedia:移动请求上进行，但是有时候会有些用户只在该条目之讨论页上发表意见，这会造成讨论分散，并可能会让讨论不容易产生共识。因此个人建议修改目前之讨论方式，改为提出移动请求后之相关讨论，都限定在该条目之讨论页进行，也就是提出请求者只需要在Wikipedia:移动请求列出请求及理由，并在条目之讨论页上发起讨论及挂上相关模版，其他用户的意见想法，通通都应该限定在条目之讨论页上进行，管理员只需要依照被列在Wikipedia:移动请求上的条目列表及时间定期去各条目之讨论页确认共识来处理移动请求即可。其实这也才是最初Wikipedia:移动请求设立时所规划的讨论方式。—Alberth2-汪汪 2009年5月3日 (日) 06:37 (UTC)

• (＋)支持，并应修改{{move}}模板以加入操作提示—Altt311 (留言) 2009年5月3日 (日) 06:44 (UTC)
• (＋)支持，移动请求只是提出请求地方，条目的其他的问题都应在讨论页解决。--Advisory 2009年5月3日 (日) 15:40 (UTC)
• (＋)支持—Tlrmq (留言) 2009年5月4日 (一) 06:46 (UTC)

我倒是认为在条目对话页上讨论该条目的移动问题是很恰当的，并没有不妥。Wikipedia:移动请求最初是为了解决有被编辑过的重定向页存在，而造成普通用户无法完成移动，才在这个Wikipedia:移动请求提出，请管理员帮忙移动。现在的问题是，Wikipedia:移动请求应当处理的请求范围是什么？只是普通用户无法完成移动的请求？还是包括了产生争议的移动？还是所有的移动都要经过讨论和请求？或许我们应该先把这个问题搞清楚。—百无一用是书生 (☎) 2009年5月4日 (一) 12:50 (UTC)

起初设立移动请求页面的原意是要在有关条目的讨论页中进行讨论[1]，后来不知什么的原因[2][3]，用户都纷纷走到移动请求立页面中进行讨论。 Shinjiman ⇔ ♨ 2009年5月4日 (一) 13:09 (UTC)

• (＋)支持--Withclear (留言) 2009年5月8日 (五) 11:50 (UTC)

如果没有反对意见的话，我预定在5/11（星期一）开始在Wikipedia:移动请求上开始宣导及进行于条目讨论页进行讨论的方式。—Alberth2-汪汪 2009年5月9日 (六) 16:26 (UTC)

已把现在讨论通通都搬到条目之讨论页，也修改了Wikipedia:移动请求之架构，同时也修改了{{move}}之说明，有任何问题欢迎踊跃反应......。－Alberth2-汪汪 2009年5月11日 (一) 02:24 (UTC)

Wikipedia移动请求的功能

目前在Wikipedia:移动请求的实际运作中，大致有以下几种功能：

1. 处理一般用户无法完成的移动。
2. 希望更多人前来关切某项移动建议之讨论。（例如现在讨论正热烈的“葛利斯 vs 格利泽”）
3. 并非一般用户无法完成之移动，但是怕自己移动会引起非议，故希望由管理员代为动手。（目前的请求中也有类似的状况）
4. 纯粹提出移动建议，但不知道可以在讨论页提出讨论，以为所有移动都必须到Wikipedia:移动请求提出。
5. 自己不会执行移动，希望别人帮忙移动。
6. 请求合并页面编辑。请求合并页面之编辑历史。

第1点的功能当然是必须的，至于2~3点我觉得也OK，只要有共识，要管理员代劳也不是不行，而且现在可以在移动后执行一个月的移动保护，这也有助于确保共识并避免继续产生争议。但是，我就是觉得2~3点有日渐增加的趋势，进而产生了第4, 5两种状况，也造成原条目之讨论页几乎失去了作用，所以我才会提议“限定所有讨论都到条目讨论页进行”，当然提出者也必须先在讨论页里发起提议，等到讨论出结果，再来Wikipedia:移动请求通报管理员依照共识处理即可，这也可以让一切讨论恢复到正确的地方。

而以上1, 2, 3点我是觉得都需要共识，或是一周的无异议才可以移动，4, 5点在落实讨论方式后会消失；置于第6点，看看要不要另外设个Wikipedia:合并编辑历史（或是Wikipedia:修复剪贴移动）专门处理，不过这点的需求数量并不多，或许没有必要另外开页面处理。－Alberth2-汪汪 2009年5月5日 (二) 02:37 (UTC)

个人认为第一条本来是因为技术原因用户无法完成移动，因此才需要管理员帮忙移动。所以这个不应该和共识有关。如果这个需要共识的话，那么所有的移动都要有共识了。—百无一用是书生 (☎) 2009年5月6日 (三) 14:35 (UTC)

原则上我认同书生的看法。是我想太多了，总是把1, 2 ,3点给混在一起思考了.....。如果依这样的概念，剩下的功能就可以简单的分成两大类，1.处理一般用户无法进行之移动、2.保护产生共识后的移动。—Alberth2-汪汪 2009年5月6日 (三) 16:20 (UTC)

想到一个可能会有的问题，对于一般用户无法进行之移动所提出的移动请求，应该还是需要附上理由吧，管理员还是需要判断此理由是否合理再决定是否移动，但是一样的理由可能有的管理员可以接受，有的管理员不能接受，这样就会变的比较麻烦了。—Alberth2-汪汪 2009年5月6日 (三) 16:31 (UTC)

另外，关于合并，目前很多合并请求其实是在投票删除页面进行的，或许可以把Wikipedia:移动请求改成wikipedia:移动与合并请求，在删除投票那里讨论合并，常常有些人误认为就是删除。—百无一用是书生 (☎) 2009年5月7日 (四) 14:12 (UTC)

啊，我前面有地方写错了，目前常在移动请求出现的应该是“请求合并页面之编辑历史”才对（这功能其实我一直存有些不同看法），我倒是认为一般的合并请求应该在Wikipedia:重复条目提出较为适合，这可以作为提示大家目前有哪些条目被建议合并，有兴趣的人就可以去帮忙进行合并的工作，目前确实也已经固定有几位用户会过去帮忙这方面的工作。但我认为Wikipedia:重复条目应改名为Wikipedia:合并请求，并且与Wikipedia:移动请求继续维持分开处理会较为适合。－Alberth2-汪汪 2009年5月8日 (五) 01:23 (UTC)

同意书生，合并也在移动页面提出比较好，性质上也相似，在删页提出总是常会被误会为删除，多半合并后其中一方都会成为重定向，甚少会删。--五月病中的小琛儿 ^{探病去 病历表} 2009年5月16日 (六) 17:03 (UTC)

但是合并页面并不需要管理员的权限，需要的则是对该条目主题的熟悉程度，也因此合并请求很容易被长期积压（最近我才清理出了数百组被挂上合并请求的条目），而移动请求则是经常需要使用到管理员的权限，因此我还是认为两者应该分开处理。－Alberth2-汪汪 2009年5月17日 (日) 15:54 (UTC)

页面合并需要合并修订历史，这是必须管理员才可以做到的--百无一用是书生 (☎) 2009年5月18日 (一) 03:43 (UTC)

提议在Wikipedia:移动请求容许提出分类移动

相对于条目移动，分类移动比较少，但分类移动算是在移动中比较麻烦的一种。人手的话会非常耗时费力，机器人虽然比较方便，但机器人身分需要确认，也不是很快能完成。因此我认为可以容许在Wikipedia:移动请求，流程和一般条目请求移动一样，有共识后才利用机器人移动。如果需要机器人执行共识的话，我愿意以我的机器人帐号来完成这个移动工作。所以就把这个忽发奇想提出来，讨论一下可行性。—Altt311 (留言) 2009年6月24日 (三) 07:43 (UTC)

只要达成共识，利用机器人来完成分类移动的工作确实可以让大家轻松许多。—Alberth2-汪汪 2009年6月24日 (三) 12:34 (UTC)

(＋)支持，但需要给出明确的限制条件，比如说分类只包含10个（这个数可以再讨论）以下的条目的话就不应提出请求。--William915（与我讨论） 2009年6月25日 (四) 09:01 (UTC)

(＋)支持分类应与条目一样可供移动。—LUFC~~Marching on Together 2009年6月25日 (四) 09:40 (UTC)

bot移动……我先写个[[Category:Some {{{foo|Category}}}]]看你检查不检查得出来……--Liangent (留言) 2009年6月26日 (五) 11:06 (UTC)

如果有明确的移动目标的话，就应该没问题吧（上面那个作为移动目标应该会被反对吧）—Altt311 (留言) 2009年6月27日 (六) 11:01 (UTC)

如果用户请求把[[Category:Some Category]]移动到[[Category:Another Category]]，而[[Category:Some Category]]中的一些条目是由[[Category:Some {{{foo|Category}}}]]加入的，可能bot就处理不了了--Liangent (留言) 2009年6月27日 (六) 16:52 (UTC)

这个……印象中没有尝试过……但我移动分类一般都为分类加引号，不知能不能这样避免您说的事发生—Altt311 (留言) 2009年6月28日 (日) 14:38 (UTC)

(＋)支持。——苏州宇文宙武之太阳殿 ♨迎仙宫 ★尚书省 2009年6月27日 (六) 00:33 (UTC)

(＋)支持有用。窗帘布(议会厅) 2009年6月28日 (日) 08:08 (UTC)

(＋)支持：终于有人提议了，这功能很有利于整理分类，不然靠人工移动实在是太费力了。—David Jackson(留言) 2009年6月29日 (一) 05:09 (UTC)

(！)意见 在技术上，目前的分类页面是未能使用‘移动’功能将其移动，亦不能保留原先的编辑历史。 Shinjiman ⇔ ♨ 2009年7月7日 (二) 04:59 (UTC)

是这样没错……这提议也主要是为了方便没有bot的用户能协助整理分类。（现在的条目分类需要整理）—Altt311 (留言) 2009年7月7日 (二) 05:22 (UTC)

commons:MediaWiki:Gadget-Cat-a-lot.js--Liangent (留言) 2009年7月9日 (四) 20:53 (UTC)

这个也可以啦（我在Commons也用得很高兴），只是害怕被用作破坏而已。—Altt311 (留言) 2009年7月24日 (五) 21:52 (UTC)

(＋)支持，但是分类只包含10个以下就不能移动不妥当，分类的命名一直比较乱，根本上也要建立一个方针来指导。—Fantasticfears（留言+ | 记录） 2009年7月15日 (三) 06:12 (UTC)

(＋)支持，一直很奇怪为甚么分类无法移动。YunHuBuXi 2009年7月18日 (六) 11:45 (UTC)

(！)意見：不晓得分类移动是否已经成为Wikipedia:移动请求的正式原则了?!—David Jackson(留言) 2009年9月8日 (二) 07:11 (UTC)

避免移动破坏

上面已经讨论了这个问题，我在阐述一下并且希望有人做些什么，发现维基百科有一个bug，一个人将一个页面移动到一个错误名字空间中，然后在正确的名字空间上重定向，那么想修复这一破坏的人将不得不提出移动申请，费时费力。例如文件编辑器比较这个条目。cuthead (留言) 2009年12月20日 (日) 14:13 (UTC)

• （討論）Avira AntiVir- → Avira AntiVir：

請求原因，因為小紅傘這個中文名稱是吉瑞科技的片面錯誤翻譯，故用英文 Avira AntiVir 名稱為正確。— Ogame846-通境 (留言) 2010年1月6日 (三) 18:10 (UTC)

改革移動請求

問題

現時有WP:RM處理移動請求，提出者會在WP:移動請求/當前加入請求內容，但往往不在條目的討論頁加入{{Move}}模板，使關注該條目的用戶未必能察覺有關移動請求，可能未能及時參與討論。另外，修改條目名稱，理應在其討論頁討論，不過，現時集中在WP:移動請求/當前討論，情況並不理想。

建議

移動請求必須在條目的討論頁提出，即在討論頁加入{{Move}}模板，該討論頁會因此而自動加入到Category:已請求的移動；同時，將此Category頁面嵌入到WP:RM，這樣便會列出全部有移動請求的條目，一目了然，方便處理請求，同時可停用WP:移動請求/當前，讓條目名稱的討論回歸到各討論頁進行。

不知大家有何意見。--Gakmo (留言) 2011年11月5日 (六) 18:58 (UTC)

如此甚好，還可以學一下刪除請求，將「到原作者對話頁通知」列入重要步驟。--Reke (留言) 2011年11月6日 (日) 01:31 (UTC)

• 讓條目名稱的討論回歸到各討論頁進行，这样也可能造成主编者以外的人不知情。乌拉跨氪 2011年11月6日 (日) 01:43 (UTC)

不如索性參考Wikipedia:頁面存廢討論制度。如要移動條目，需要在條目頂部掛上一個「提請移動模板」，並集中在「Wikipedia:頁面移動討論」中討論。七天後如有共識，便可進行移動。不過，與頁面存廢討論不同的地方，就是討論結束後需要將討論內容搬到條目討論頁中存檔。這個方案可以同時解決Gakmo提出的問題及乌拉提出的疑慮。--沙田友 (留言) 2011年11月6日 (日) 04:43 (UTC)

挺好的，(＋)支持。乌拉跨氪 2011年11月6日 (日) 04:45 (UTC)

支持。--达师 － 198 － 336 2011年11月6日 (日) 05:21 (UTC)

請(※)注意,WP:RM一早已要求提出者在條目對話頁加入模板。--Gakmo (留言) 2011年11月6日 (日) 07:36 (UTC)

召唤鸡米许……--达师 － 198 － 336 2011年11月6日 (日) 12:52 (UTC)

但是移动请求处理的是普通用户无法移动的页面，以及移动后产生争议或希望进行充分讨论再移动的页面，而不是所有的移动都需要请求。之所以有请求，就是因为有争议或用户权限不允许才需要请求，这就像存废讨论请求也是因为一般用户权限不能删除才会有这个请求一样--百無一用是書生 (☎) 2011年11月7日 (一) 02:03 (UTC)

沙田友的建議與現行機制的理想情況分別不大（分別只是在頁面名稱和放置模板的是對話頁而非條目本頁）。希望我們可以學習英文維基，提出者只要在對話頁掛上模板，機械人便自動將請求集中到某一頁面上，即WP:RM。--Gakmo (留言) 2011年11月7日 (一) 02:12 (UTC)

我建議將模板放在條目頂部的原因（做法如提刪模板），是中文維基編者絕大多數情況下都不會刻意到討論頁瀏覽，所以模板掛在討論頁的作用不大，一樣會出現「關注該條目的用戶未必能察覺有關移動請求」。--沙田友 (留言) 2011年11月7日 (一) 02:20 (UTC)

掛在哪裡我個人沒有太大意見，只希望引入機械人，使掛模板成為提出有爭議的移動請求的唯一渠道（如同英語維基）。--Gakmo (留言) 2011年11月7日 (一) 02:31 (UTC)

新移动请求的步骤初稿

因應互助客棧的討論，建議修改移动请求的步骤如下：

---

移动请求的步骤

步驟一：在應改名的條目頂部加入下面代碼以提出請求：

{{move|新名稱}}

或

如未能確定新名稱，請使用

{{move}}

步驟二：進入該條目的討論頁，點擊頁面近頂部的模板中的「点此發起新議題」按鈕，然後輸入移動的理由並發起討論。

---

以上--Gakmo（留言） 2012年4月17日 (二) 11:37 (UTC)

在條目的討論頁加入请求模板后会自动将该请求加到Wikipedia:移動請求/當前‎‎嗎— PurpleHyacinth 2012年4月18日 (三) 01:11 (UTC)

只要加入{{move}}模板的頁面，該頁都會加入到分類:已請求的移動，故現時正在互動客棧方針版討論，建議Wikipedia:移動請求直接匯入分類:已請求的移動，以代替現時的「移動請求/當前」。--Gakmo（留言） 2012年4月18日 (三) 01:33 (UTC)

如果实行的话，为了防止其他人再在原页面加入请求内容，建议全保护Wikipedia talk:移動請求和Wikipedia talk:移動請求/當前。— PurpleHyacinth 2012年4月26日 (四) 08:35 (UTC)

謝謝意見。其實可以加入{{Historical}}模板，因頁面陳舊而作出保護未必符合保护方針。--Gakmo（留言） 2012年4月26日 (四) 09:27 (UTC)

基本上只要模板中不再有連結連到Wikipedia talk:移動請求，會去使用那邊的人應該就會大幅減少。--Alberth2 汪汪 2012年4月26日 (四) 10:17 (UTC)

同意Alberth2的意见。— PurpleHyacinth 2012年4月27日 (五) 00:46 (UTC)

理順移動請求流程

現時用戶申請移動條目（要管理員幫忙和有爭議移動），可在维基百科:移動請求/當前提出，但用戶往往不在相關條目的討論頁發起討論，使關注該條目的用戶無法得知（因為他們未必會關注维基百科:移動請求）。為使用戶在頁面發起移動討論，建議取消维基百科:移動請求/當前頁面，而讓维基百科:移動請求直接匯入Category:已請求的移動，即用戶要在條目討論頁加入{{move}}（便可成為已請求的移動類別之一）。這樣，關注該條目的用戶可得知有人想移動，從而提出意見，而管理人員亦可在维基百科:移動請求一目了然，協助移動。--Gakmo（留言） 2012年4月12日 (四) 14:50 (UTC)

• 支持！這是Wikipedia:移動請求的老問題了，過去我曾經短暫的讓所有的討論都在條目討論頁上進行，但一沒有持續關注，又恢復呈現在這狀況了！--Alberth2 汪汪 2012年4月12日 (四) 15:00 (UTC)
• (＋)支持阁下的提案。我觉得会出现这个情况是因为条目讨论页的讨论很冷清，移动请求的页面看下去比较热，所以就直接放移动请求了。--Lakokat 2012年4月13日 (五) 02:15 (UTC)

可以参考关注度提报的方法--百無一用是書生 (☎) 2012年4月13日 (五) 02:33 (UTC)

兩者的原則是一樣的，都是在條目/條目討論頁那裡加模版以引起關注。--Gakmo（留言） 2012年4月13日 (五) 10:32 (UTC)

討論頁未必有人留意到的，應參照提刪模板般放在條目頂部。--Hargau（留言） 2012年4月16日 (一) 14:49 (UTC)

可以，請就新模板的草稿提意見--Gakmo（留言） 2012年4月17日 (二) 06:34 (UTC)

好像很久之前我已提議過可以參考現行提刪條目的方式更改，當然參考關注度提報的方法也可以，最重要將模板放在條目頂部，使編者更容易知道條目正被請求移動。--沙田友（留言） 2012年4月19日 (四) 14:44 (UTC)

放在條目上方確實會比放在討論業容易被注意到。--Alberth2 汪汪 2012年4月21日 (六) 12:37 (UTC)

模版改名討論期間 無法正常顯示 Template:入圍

因進行了建議改名：「Template:Sho」→「Template:入圍」的討論，造成目前無法正常顯示。不知道如何修正討論改名期間也可維持正常顯示? Zenk0113（留言） 2017年12月2日 (六) 04:35 (UTC) --Zenk0113（留言） 2017年12月2日 (六) 04:35 (UTC)

• 已被修好了，表格必須要一行之首才有效果。--米莉婭諾朵卡 2017年12月2日 (六) 06:32 (UTC)

感謝指導 Zenk0113（留言） 2017年12月2日 (六) 11:27 (UTC)

@Xiplus：這個技術性問題的異常才想說留存相關頁面討論維基百科討論:移動請求。 方便日後模版移動又產生一樣的問題時，方便好找解決方案? 這個不是條目問題，是技術問題。應該歸移動討論的頁面比較適當吧? BTW，維基百科討論:移動請求我也有注意到這個討論頁堆了一堆不是移動規範相關的討論(純建議改名章節)，請問這是否可以直接刪除呢? 還是移動相關頁面再刪?Zenk0113（留言） 2017年12月2日 (六) 16:39 (UTC)

@Zenk0113：我想了想同意您的想法，只存檔至移動請求。另移動請求討論頁的純建議改名章節我已存檔至他處。--Xiplus←A2093064 2017年12月3日 (日) 00:12 (UTC)

謝了Zenk0113（留言） 2017年12月3日 (日) 04:24 (UTC)

WP:共识與WP:移動請求協調等

由於有人認爲在頁面及其討論頁發起的移動請求，在被轉入互助客棧後屬於提案，按Wikipedia:共识#互助客栈的公示／免除公示程序及公告等步驟處理，不適用Wikipedia:移動請求：“一般來說，移动請求將在提出請求七天後依據其討論頁之討論結果處理”，因此提出以下問題：

• 1. 被轉入客棧的移動請求經逾七日討論並達成共識，可否據此共識移動？應否遵循客棧提案的公示／免除公示及公告等步驟？

如以上問題一否一應，衍生以下問題：

• 2. 被轉入客棧的移動請求經逾七日討論並達成共識，處理此請求的管理人員是否有權不經公示／免除公示及公告等步驟，據此共識直接移動？
• 3. 經客棧逾七日討論、達成共識但未經公示／免除公示等步驟的移動請求，經機器人自動存檔轉出客棧後，可否免於客棧提案通過程序，據移動共識直接移動？
• 4. 經客棧逾七日討論、達成共識但未經公示／免除公示等步驟的移動請求，經請求者、管理人員或其他人手動存檔轉出客棧後，三者分別可否免於客棧提案通過程序，據移動共識直接移動？
• 5. 若不轉移移動請求的討論，僅在客棧設置鏈接以導向相關移動請求的討論，其他情形不變，第1、2問答案為何？會否改變？

無關移動請求，亦有客棧提案通過相關問題：

• 6. “提案”為何？
• 7. 如在客棧中有條目等頁面編輯提議，提議者或其他人可否在此提議停留在客棧期間，不經公示／免除公示等步驟，實施與此提議一致或近似的編輯？如否，此提議自動或手動存檔轉出客棧後，又可否如此為之？
• 8. 如在客棧中有條目等頁面編輯提議經多日討論後達成共識，提議者或其他人可否在此提議停留在客棧期間，不經公示／免除公示等步驟，實施與此提議一致或近似的編輯？如否，此提議自動或手動存檔轉出客棧後，又可否如此為之？
• 9. 如在客棧中有求助性請求，可否不經公示／免除公示等步驟，滿足其請求？如否，達成共識後，又可否如此為之？

此外，Wikipedia:共识#互助客栈有極重大漏洞：

• 10. 只規定客棧提案的公示通過、免去公示通過、微小修訂通過的條件；未規定無定語或狀語的“通過”本身的條件，或前述三者是客棧提案通過的唯三管道。即法理上任何人可不經公示／免除公示／微小修訂規定在客棧宣佈通過任何提案，包括方針指引修訂。（也許有人説確實如此，以上問題全部白問了；或許也有人説前者説法游戲維基規則，該方針實質上暗示“若要通過，理應公示，除非例外”。）

--Gohan 2023年1月20日 (五) 09:03 (UTC)

這是為什麼我在一個月前提出修訂WP:共識，涉及共識的必須明確表達意見，當進入公示程序時，管理員需插手確認有沒有問題，這樣的做法可以解決上述問題。--唔好阻住我愛國（留言） 2023年1月20日 (五) 17:16 (UTC)

先決問題是上述請求需不需要公示，此前又有多大比例確實公示。--Gohan 2023年1月21日 (六) 01:40 (UTC)