维基百科讨论:移动请求

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

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