維基百科討論:移動請求

移動請求的計劃和排版都不太成熟

請問不知大家（特別是管理員們）看到這一個請求計劃頁有否覺得十分不成熟呢？排版、留言、意見和投票的安排均十分雜亂；況且已經解決的個案是否應該列入存檔中？不知管理員們能否就這幾項問題作出一點小改革呢？謝謝。--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)