維基百科討論:命名空間/2021年設立新命名空間及偽命名空間

由Jimmy-bot在話題第三次推動設立LTA命名空間上作出的最新留言:2 年前

導航模板

編輯

本章節用於展示各章節重複的內容。

[編輯此導航模板]


開放偽命名空間作捷徑連結用

編輯

本討論與捷徑方針草案合併,進行分階段修訂臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:30 (UTC)回覆

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

希望在此重提2018年12月就容許MOS:偽命名空間豁免速刪跨命名空間重新導向條目的討論。

在此先對於「偽命名空間」稍作解釋:

命名空間Pseudo-namespaces)是指實際上在主命名空間中建立特定開首,指向特定在命名空間頁面的重新導向條目。英語維基百科有多個偽命名空間(en:WP:PNS),包括MOS:(重新導向至en:Wikipedia:Manual_of_Style,對應中文維基百科的Wikipedia:格式手冊)以及在中文維基百科為正式命名空間別名的CAT:H:P:T:;而日語維基百科則將此歸類在捷徑項目內(ja:WP:SC),而並非命名空間的捷徑包括LTA:(重新導向至ja:Wikipedia:進行中の荒らし行為/長期/,對應中文維基百科的Wikipedia:持續出沒的破壞者)。

為分頁面較多的維基百科命名空間項目,例如長期破壞者格式手冊。開放偽命名空間容許捷徑連結的表達更為簡單清晰。舉一例子,相較起來,LTA:HBN比起WP:HBN更能夠表達此連結至一個長期破壞者的頁面而不是維基百科的方針、指引、論述等。使用LTA:HBN而非WP:LTA/HBN則是讓捷徑維持簡潔,保留現有WP:HBN的簡明命名。最重要的是可以少輸入幾個字元又能清晰表達其為LTA或MOS項目的頁面

希望大家積極參與討論。Taiwania JustoSanmosaMilkyDefer--LuciferianThomas留言 2020年11月15日 (日) 05:13 (UTC)回覆

如同上次,我支持提案。這可以有助建立較簡潔的系列性頁面捷徑。SANMOSA SPQR 2020年11月15日 (日) 06:30 (UTC)回覆
(+)支持,具有統一、簡潔、一目了然三大優點。MilkyDefer推遲咕咕 2020年11月15日 (日) 07:31 (UTC)回覆
補充一下,我個人認為還有能減少命名衝突的好處存在。舉個例子,現在有WP:X43,指向的是一位長期破壞者。如果某一天蹦出了另一個長期破壞者比如Xblablabla11什麼的,為這位建立一個WP:X11就會出現問題,因為X11有其特殊含義,容易引起誤解,日後如果真有必要設立「在X11系統下瀏覽編輯維基百科」的論述或者指南的話,還有可能引起命名衝突。命名為LTA:X11就不會有這樣的問題了.--MilkyDefer推遲咕咕 2020年11月15日 (日) 07:38 (UTC)回覆

建議加一個PJ:維基專題使用。 ——羊羊 (留言|貢獻) 2020年11月15日 (日) 10:41 (UTC)回覆

同意。如此提案將增為LTA:MOS:PJ:三項。個人認為若整體議案獲足夠人數支持且有人對個別提議的偽命名空間有意見或異議則再分項投票。--LuciferianThomas留言 2020年11月15日 (日) 11:06 (UTC)回覆
建議從三個角度考察:1)必要性:需被替代的原名稱是否過長;2)復用性:單一頁面是否在討論中被頻繁引用(調用);3) 新名稱是否已經是比較慣用的簡稱,以便於記憶和被廣泛使用。--Kirk★ 0#0 2020年11月15日 (日) 15:11 (UTC)回覆
就必要性方面,開放偽命名空間讓討論表達更清晰(一目了然是LTA、MOS還是PJ等等,讓WP:的定義縮窄。就復用性請補充,我不太明白。就第三點,捷徑連結後半部一般保留慣用的簡寫,不會有難以記憶和不廣泛地使用的問題。個人認為若獲得通過,暫時保留現有捷徑,若機器人徵測變更中包含舊連結的話就讓機器人訊息提醒此功能啟用。--LuciferianThomas留言 2020年11月15日 (日) 22:11 (UTC)回覆

在此附加提案,於「縮寫與別名」段落下新增內容:

現行條文

新增加

提議條文

偽命名空間

維基百科中,除了常規命名空間與其別名,以及虛擬命名空間外,還有數種用作捷徑的前綴,指向最常引用的維基百科頁面。這些前綴統稱為偽命名空間,包含:

偽命名空間不被Wiki軟體所承認,純粹由社群進行客製。偽命名空間的標題實際上屬於主命名空間,在技術上Wiki軟體也是這樣看待:這些標題對大小寫敏感,且只會在主命名空間的搜尋結果中出現。別名會被視為真實的命名空間,因此可以代替其代表的命名空間進行頁面搜尋;但「偽命名空間:頁面名稱」的格式會視為主命名空間,而不屬於其他任一種命名空間。

其他要增加的偽命名空間請隨時補上。臺灣杉在此發言 (會客室) 2020年11月15日 (日) 15:12 (UTC)回覆

我覺得有一些問題:
  1. 主命名空間也是命名空間,「會視為主命名空間,而不屬於任一個命名空間」好像有點奇怪;
  2. 建議多加一句此類重新導向豁免於CSD R2速刪條件。
以上。若內容有其他問題其實可直譯en:WP:PNS。--LuciferianThomas留言 2020年11月15日 (日) 22:02 (UTC)回覆
已改為「其他任一種命名空間」。我還沒加豁免速刪是因為正在翻譯WP:捷徑,當中已納入該規則。翻譯完成後會提出來列為指引。臺灣杉在此發言 (會客室) 2020年11月16日 (一) 00:05 (UTC)回覆
(-)反對,en垃圾吧這是。容易和主空間混淆,還不用雙前綴,像「WP:MOS:xxx」,這樣依然是歸於WP命名空間(WP用於維基專案內的相關頁面),也能對應MOS命名空間的意義。——Sakamotosan路過圍觀杯弓蛇影| 避免做作,免敬 2020年11月16日 (一) 02:03 (UTC)回覆
上述內容純粹是技術說明,在一般讀者使用上毫無差別。另請參閱本討論首段內容瞭解原因。--臺灣杉在此發言 (會客室) 2020年11月16日 (一) 03:38 (UTC)回覆
開放偽命名空間的意義正是方便減省輸入的內容(WP:MOS:XXXWP:MOS/XXX明顯比MOS:XXX累贅),又能夠清晰表達捷徑的目標。WP代表的維基專案過於廣泛,全數使用WP:MOS:XXXWP:LTA:XXXWP:PJ:XXX就會顯得累贅,MOS:XXXLTA:XXXPJ:XXX更清晰又簡單。--LuciferianThomas留言 2020年11月16日 (一) 03:59 (UTC)回覆
BTW如果是垃圾就不會在多個維基項目中都會有偽命名空間啦。--LuciferianThomas留言 2020年11月16日 (一) 12:23 (UTC)回覆
就像為了避免佔用條目空間,維基百科首頁從首頁遷移到Wikipedia:首頁那樣,我不希望條目空間出現指向其他空間的重新導向。其他Wikipedia的維基百科首頁也在條目空間,那偽命名空間只是破罐子破摔罷了;中文維基條目空間本來就很乾淨,我認為不應引入「偽命名空間」這種概念。WP:ENWIKISAID這麼長辨識起來沒有難度,我認為「WP:MOS/XXX」或「WP:MOSXXX」並沒有太大問題。要麼就將MOS做實為實體空間,我不希望MOS:LIST頁面左上角顯示「條目」。--洛普利寧 2020年11月16日 (一) 15:39 (UTC)回覆
在英文維基百科搜尋MOS:CITE為例,在條目命名空間的搜尋結果中沒有以MOS:開頭的搜尋結果,在Wikipedia命名空間才會看得到結果。從技術上來看,這是一個指向專案空間的重新導向,因此你點擊這樣的連結,最終看到的頁面,左上角也不會是「條目」二字。最後,這一次討論開啟的緣由,歸根結底是我發現格式手冊頁面的捷徑之樣式不統一,容易引起辨識困難。--MilkyDefer推遲咕咕 2020年11月16日 (一) 16:24 (UTC)回覆
WP:CSD#R2指出條目空間的非條目重新導向一律刪除。我覺得中文維基這點做得非常好,條目空間就專心放條目(和消歧義),不要涉及站務頁面。中文維基沒有「偽命名空間」本來就是好事,沒必要學英文維基MOS:和日文維基LTA:。格式手冊以Wikipedia:格式手冊/縮寫為例,WP:MOSABBRWP:MOS/ABBR,以及沒有歧異時的WP:ABBR都OK。捷徑搞屬性辨識講真意義不大,畢竟這東西要點開才有意義。像WP:HBN看過的人會有印象,沒看過的人就算給寫成LTA:HBN,一樣不知道他是誰啊⋯⋯PS:英文維基人編寫條目時常拿MOS辯論;但中文維基沒有MOS文化,格式手冊和其他方針指引沒差,不不必學英文版特別拔高。(相較而言,中文維基各命名常規的使用率也不低,但我覺得沒必要開個N:或者NC:的前綴。)--洛普利寧 2020年11月16日 (一) 16:53 (UTC)回覆
WP:HBN改成LTA:HBN不會讓人知道他是誰,但就達到最重要的功能:讓別人知道HBN是指一個LTA。--LuciferianThomas留言 2020年11月16日 (一) 23:15 (UTC)回覆
「首頁」的例子,在我看來只是個特例。英語維基百科的作法是移到Main Page,Wikipedia:Main Page也指向Main Page,但有沒有人吵這個跨命名空間重新導向有問題?顯然沒有。從讀者角度來看,偽命名空間「捷徑」的設立,除了利於使用以外,是否會造成讀者的困擾?以及雖然在技術而言,偽命名空間「捷徑」屬於跨命名空間重新導向,但實際上是否造成編輯上的困擾?在我看來好像也沒有影響。在這裡強調的是「捷徑」,而非一般重新導向;一般非條目空間與條目空間的跨重新導向的確會有困擾,但捷徑應可看做例外。--臺灣杉在此發言 (會客室) 2020年11月21日 (六) 10:40 (UTC)回覆
占用主命名空間的可能是有的,例如有部小說叫做Re:從零開始的異世界生活,搞不好哪天會有什麼MOS:勇者轉生異世界LTA:拉蒂亞日記之類的神奇小說要建條目怎麼辦-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年11月16日 (一) 17:33 (UTC)回覆
不影響,佔用的都只能是捷徑(重新導向)而不是指整個格式手冊移至MOS,與內容不太可能回重複(機會極低)。--LuciferianThomas留言 2020年11月16日 (一) 23:08 (UTC)回覆
「內容不太可能回重複」,那麼用WP:也應該沒有問題。而且如果真有歧義簡稱可以另外擬定一個沒有歧義的。因此反對提案。--GZWDer留言2020年11月17日 (二) 23:02 (UTC)回覆
提案的原意是讓偽命名空間表達捷徑的用途。另外,現在說的只是豁免偽命名空間的CSD R2,條目空間內容的部分即便有MOS:或LTA:為開首的條目名稱不影響(因為並非重新導向,不受R2影響;而條目空間重新導向到條目空間更沒有問題。使用WP:這個空間本身就帶有歧義,因為維基百科命名空間過於廣泛,請審視全然使用WP:的缺點以及開放偽命名空間解決有關缺點的效果。--LuciferianThomas留言 2020年11月18日 (三) 10:12 (UTC)回覆
的確有可能占用主命名空間,如可能有小說叫LTA:HBN。但是也有可能有小說叫WP:HBN(而且可能性一樣小)。真的遇到這種情況再想辦法也不遲。附(+)支持提案。 ——羊羊 (留言|貢獻) 2020年11月19日 (四) 15:41 (UTC)回覆

本修正案先暫時凍結,因為WP:捷徑翻譯完成,會另開段落討論將之訂為指引。臺灣杉在此發言 (會客室) 2020年11月18日 (三) 13:26 (UTC)回覆

動議:直接將PJ:獨立為新WP:命名空間

編輯

(&)建議像日文維基那樣,專題直接變成一個 "真" 命名空間 ja:Help:名前空間#プロジェクト就不會有cwek說的 "假" 命名空間 的 混淆問題了。日維相關討論。 -- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️

(=)中立,但此僅為其中一個被提議的偽命名空間提供了替代方案,那麼另外的LTA:MOS:呢?--LuciferianThomas留言 2020年11月16日 (一) 09:32 (UTC)回覆
一個一個來。肯定會有方法的。pj是有多個維基實行過,且效果不錯,可行性較高,也不會混淆。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年11月16日 (一) 13:10 (UTC)回覆
好的。(+)傾向支持吧,始終我不太清除其他維基項目對此的執行,不過覺得與維基空間的內容有點距離,可以自己分離了。--LuciferianThomas留言 2020年11月16日 (一) 15:19 (UTC)回覆
LTA和MOS感覺不足以達到獨立命名空間門檻,且其他語言維基也沒先例,故不提案。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年11月16日 (一) 15:32 (UTC)回覆
意思使用新建一個「專題」的空間,把Wikipedia:ACG專題移動到專題:ACG;然後把PJ作為「專題」命名空間的別名?--洛普利寧 2020年11月16日 (一) 16:01 (UTC)回覆
從這個動議的內容上看應該是這個意思,開闢一個「WikiProject」空間,簡稱"PJ",中文為「專題」和「維基專題」--MilkyDefer推遲咕咕 2020年11月16日 (一) 16:11 (UTC)回覆
大概就類似User:青子守歌使用者頁面裡面的ja:利用者:青子守歌/frwpのウィキプロジェクト名前空間と參考文獻名前空間。 日文維基佈署很久,沒甚麼太大的問題。且專題:ACGWikipedia:ACG專題淺顯多了,並也允許PJ:ACG這樣的連結方式。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年11月16日 (一) 17:24 (UTC)回覆

小總結

編輯

根據以上討論,目前共有兩個選項:

  1. 開放偽命名空間;
  2. 將PJ納入命名空間並作為別名,MOS、LTA再行討論。

偽命名空間看起來是3人反對,5人左右支持,僅能算過半支持,但也未達到絕對多數,且目前還沒看到反對方出來針對正方回應進行進一步論述。而部分支持偽命名空間的使用者也不反對後者的提案。

所以目前的共識傾向為將PJ(專題)獨立成為新的命名空間,偽命名空間將繼續討論。因本討論最後一次發言起過5日,公示期延長為9日。因此現在起   公示9日,2020年12月6日 (日) 03:26 (UTC) 結束臺灣杉在此發言 (會客室) 2020年11月27日 (五) 03:26 (UTC)回覆

至於遺留下來的問題,將會由下方討論繼續進行。臺灣杉在此發言 (會客室) 2020年11月27日 (五) 03:37 (UTC)回覆
反對將專題獨立為(偽)命名空間。眾所皆知維基專題在本地一直發展不起來,除部分專題有實質工作外,多數專題基本上就只有評級的作用而已。連專題發展蓬勃的英文維基百科都沒有將專題獨立為(偽)命名空間了,本地大概更沒需要。另外,我從沒見過哪位編者用PJ代指維基專題的,多半直接用專題簡稱。現在這樣子感覺像是為獨立而獨立,硬是找一個英文縮寫當作別名。反倒是LTA,我覺得可以獨立為偽命名空間。—— Eric Liu 創造は生命(留言留名學生會 2020年11月27日 (五) 04:19 (UTC)回覆
不是偽,是「真」。「專題:數學」顯然比「維基百科:數學專題」更簡潔。 見日語維基和法語維基。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年11月27日 (五) 08:05 (UTC)回覆
等等,PJ:和P(ortal):的區別我沒太搞清。哪位可以解釋一下?Zhuofan WuCien años de soledad 2020年11月29日 (日) 03:08 (UTC)回覆
ZhuofanWu ——羊羊 (留言|貢獻) 2020年11月29日 (日) 04:11 (UTC)回覆
一個是Portal,一個是Project。--臺灣杉在此發言 (會客室) 2020年11月29日 (日) 08:31 (UTC)回覆
如果要細節的話:Portal(主題)有點類似各知識領域的主頁,展示該領域重要或優良的條目之用;Project(專題)則是說明該領域知識的編輯建議與規則,以及該領域社群的討論場所。臺灣杉在此發言 (會客室) 2020年11月29日 (日) 10:07 (UTC)回覆
Wait,有bug。Project命名空間在中文維基百科等價於Wikipedia命名空間。SANMOSA SPQR 2020年11月29日 (日) 14:24 (UTC)回覆
不成問題,見日維相關討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年11月29日 (日) 14:28 (UTC)回覆
那倒不如直接設PJ命名空間在中文維基百科等價於Wikipedia命名空間(如同WP命名空間),反正各專題現時皆在Wikipedia命名空間下,這樣會較能保持一致性,也不會衍生Project的指代問題。SANMOSA SPQR 2020年11月29日 (日) 14:33 (UTC)回覆
那這樣起不到「減少命名衝突」的效果…… ——羊羊 (留言|貢獻) 2020年11月30日 (一) 22:06 (UTC)回覆
@Sanmosa:見下-- Sunny00217  2020年12月2日 (三) 14:25 (UTC)回覆
我在這裡作出過的留言可供參考。--MilkyDefer推遲咕咕 2020年11月29日 (日) 16:16 (UTC)回覆

依照目前公示後討論情況,將會和下面的捷徑指引案併案討論,並採取分階段修訂。今天晚上會進行整合。臺灣杉在此發言 (會客室) 2020年12月6日 (日) 07:38 (UTC)回覆


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

WP:捷徑訂為指引

編輯

本討論與偽命名空間等捷徑提案合併討論,進行分階段修訂臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:32 (UTC)回覆

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

本候選指引原始起因為該討論,因此加速從英語維基百科翻譯該指引並於今日完成,現交付討論並檢視翻譯問題或進行修正。

有關「偽命名空間」部份,由於尚在討論並因應快速刪除方針,因此僅描述英語維基百科的使用方式,並提及增加偽命名空間應先討論,如無共識就會符合快速刪除標準。以上。臺灣杉在此發言 (會客室) 2020年11月18日 (三) 13:31 (UTC)回覆

(?)疑問:現在出現了甚麼問題?如果沒問題,就沒必要訂立規則去規限。--蟲蟲飛♡♡→♡℃留言 2020年11月18日 (三) 13:42 (UTC)回覆
@蟲蟲飛:你沒看到上面有關偽命名空間的討論?這就是現在浮現的問題啊,臺灣杉都直接開宗明義説了啊。SANMOSA SPQR 2020年11月18日 (三) 14:03 (UTC)回覆
請見上方討論,以及Wikipedia talk:捷徑#建議將現行指引WP:捷徑改為資訊頁的討論。不只偽命名空間的問題,其他如捷徑命名、更動捷徑等方式,會有潛在的風險,有必要進行規範。目前沒問題,不代表以後沒問題,事前預防總比事後處理好。--臺灣杉在此發言 (會客室) 2020年11月18日 (三) 14:10 (UTC)回覆
有正式指引總是比沒有好,指引不只是單純的規限,還可以作為編者的指南。—— Eric Liu 創造は生命(留言留名學生會 2020年11月18日 (三) 14:21 (UTC)回覆
(※)注意:WP:捷徑是適用於英維的指引,指引規定只以英文字母為捷徑,中維有很多中文捷徑,但指引完全沒有提及,如果一定要訂立,請大幅修改,以適應中維的情況。而且現在我沒看到有甚麼捷徑「潛在的風險」,或者先在提案論述一下,這樣才可以讓社羣瞭解提案。--蟲蟲飛♡♡→♡℃留言 2020年11月18日 (三) 14:24 (UTC)回覆
以下說明:
  1. 有關中文捷徑的部份,面向包含繁簡問題、字數問題及意義問題,繁簡還好解決,遵循現有轉換機制就好;字數問題可以討論;意義問題可以規範捷徑命名不能偏離目標頁面主題太多。
  2. 至於潛在風險,如該候選指引當中提及的WP:N,廣泛指的是關注度,如果有人將該捷徑改到其他頁面(例如移動至WP:註釋等等等),就會造成大量引用該捷徑的頁面連至錯誤的內容。這是最極端的狀況,但我說的大致是這個意思。其他如偽命名空間等,上面討論已經提及。
可能又有人會說,不是現有方針可以處理這些事情?不過指引可作為方針的補充說明,有規範說明可以減少這類編輯或討論所造成的紛擾,才是最大價值。--臺灣杉在此發言 (會客室) 2020年11月18日 (三) 14:50 (UTC)回覆
似要仔細考察翻譯後的文本,解決一系列程序性問題才能生效,僅舉兩例、僅僅是舉例,文本中涉及的程序疑點還有很多:
  1. 文本中提到「未經討論而建立這類偽命名空間符合R2」,但這其實和R2所規定的「由條目的命名空間重新導向至非條目命名空間,將使用者頁面移出條目命名空間時遺留的重新導向,或者從草稿命名空間指向非草稿命名空間的重新導向」矛盾,屬於超範圍適用,應考慮是否一併修改R2(而且英維的R2不具有參考意義,因為英維明定了R2是applies to redirects (apart from shortcuts));
  2. 文中提到不按所規定格式的捷徑「通常會遭到刪除」,可被解為逕行刪除,是否考慮要求這類刪除走提刪路線(事實上,拋開程序性問題,進入實質問題,WP:R#DELETE、WP:封 這樣的捷徑是否真的要按格式走,是否規定格式能夠進一步考量已有習慣而不僅僅直接移植規則)。
其次,解決上述兩個具體疑問不重要,重要的是。規則是對社群通行習慣慣例的總結和確認,在捷徑這個問題上尤其如此,事實上英文社群的捷徑規則也是如此產生的。對於翻譯移植的規則,則要從以下角度考慮:
  1. 規則中涉及的一些程序能否與中維的操作程序對接,有哪些規則(比如R2)、通行習慣(比如已有的部分捷徑)是牴觸的,何者更優而要修改哪一方;
  2. 在英維已經形成默契而不會被提出疑問的內容是否在中維有同樣的默契。
綜上,現有文本直接生效可能尚不成熟。--Kirk★ 0#0 2020年11月18日 (三) 15:41 (UTC)回覆
我也認為現有文本的確有要修正之處,不過由於中文維基百科的捷徑生態也不是很熟悉(說真的,誰會對哪一個領域熟悉的很?)。因此,我想就該翻譯文本分段來讓大家集思廣益,看要如何修會比較好。--臺灣杉在此發言 (會客室) 2020年11月19日 (四) 10:04 (UTC)回覆
另一種途徑是純粹在本地社群累積起來,(您翻譯辛苦)翻譯有很多優勢(比如,如果要擬定一個大篇幅的方針,靠翻譯就不太用花時間擬大量闡述),但如果選擇本地積累也有理由,以下僅舉兩例:
  1. 捷徑整體而言目前沒有出現胡亂編制、編制上有爭議或者有其他重大問題的情況,僅僅是偽命名空間一部被提出討論了,從緊迫性上來說,一個個問題零碎投入時間會比對整個草案的每個問題一次性投入時間,在動用社群的精力上來得經濟;
  2. 現在客棧前面有章節討論偽命名空間的問題,本章節的草案也覆蓋了偽命名空間的問題,按習慣來說集中在前面先開始的章節討論為好,上面有結論了再以形成的共識為基礎決定草案的這部分如何修改;同時討論也可以,但是其一要考慮好如何處理有人僅在一處表達觀點的問題,其二要考慮好在第一個問題沒有解決的基礎上萬一兩邊討論的文本最後發現了矛盾要如何處理(哪邊的結論能override另一邊)。--Kirk★ 0#0 2020年11月19日 (四) 14:13 (UTC)回覆
其實該討論就是由偽命名空間提案引起的,我也有參與,有結論我也會在這裡更新。--臺灣杉在此發言 (會客室) 2020年11月20日 (五) 01:07 (UTC)回覆

分段討論一:引言

編輯
現行條文

捷徑是一種特殊的重新導向頁面,提供了指向某個維基百科管理頁面或其章節的維基連結縮寫,通常用於維基百科命名空間或使用說明命名空間。這些捷徑的縮寫為全大寫字母,常用於社群頁面或討論頁作為參照,但不應用於條目頁面本身。如果某個頁面或章節有一個以上的捷徑,將會顯示在頁面或章節頂端右側,或其頂端資訊框右側標有捷徑的方框中。

提議條文

捷徑是一種特殊的重新導向頁面,提供了指向某個維基百科管理頁面或其章節的維基連結縮寫,通常用於維基百科命名空間或使用說明命名空間。這些捷徑的縮寫為全大寫字母或簡短的中文字,常用於社群頁面或討論頁作為參照,但不應用於條目頁面本身。如果某個頁面或章節有一個以上的捷徑,將會顯示在頁面或章節頂端右側,或其頂端資訊框右側標有捷徑的方框中。

此段因應中文維基百科有採用中文捷徑,新增該內容。臺灣杉在此發言 (會客室) 2020年11月19日 (四) 10:08 (UTC)回覆

分段討論二:快速參考、如何使用維基百科捷徑

編輯

這一段主要是捷徑使用方法及快速參考資料,我認為應該算軟體操作事實或單純資訊展現,應該可以全數保留。臺灣杉在此發言 (會客室) 2020年11月19日 (四) 10:11 (UTC)回覆

分段討論三:可讀性

編輯
現行條文

要避免這些問題,最好的實務作法是選擇常見的英文單字建立捷徑,這樣比較容易辨識與記憶。另外一種好的實踐方式,就是要留意一般讀者的程度,在使用艱澀的捷徑時,使用有意義的術語。例如,管道連結[[WP:SHC|捷徑]]可以讓讀者容易理解將要連去的頁面主題;如果只使用[[WP:SHC]]縮寫,對於不熟悉其術語的人而言就會無法理解。

提議條文

要避免這些問題,最好的實務作法是選擇常見的英文單字或簡短且容易記憶的中文字建立捷徑,這樣比較容易辨識與記憶。另外一種好的實踐方式,就是要留意一般讀者的程度,在使用艱澀的捷徑時,使用有意義的術語。例如,管道連結[[WP:SHC|捷徑]]可以讓讀者容易理解將要連去的頁面主題;如果只使用[[WP:SHC]]縮寫,對於不熟悉其術語的人而言就會無法理解。

這裡同樣增加中文捷徑的可行性。不過現在問題是要多少個中文字以內才算是捷徑?可能需要思考。臺灣杉在此發言 (會客室) 2020年11月19日 (四) 10:14 (UTC)回覆

比標題短?SANMOSA SPQR 2020年11月23日 (一) 08:20 (UTC)回覆

分段討論四:加入捷徑連結方塊

編輯

這一段主要討論捷徑方塊的使用方法,內容也屬於資訊性質,應該可以保留。臺灣杉在此發言 (會客室) 2020年11月19日 (四) 10:17 (UTC)回覆

分段討論五:捷徑的命名

編輯

這一段可能是爭議比較大的段落之一。依據目前中文維基百科的生態,「前綴:後綴」格式應該沒有人有異議;不過後綴的格式就上述提到的,包含「全大寫字母」及「簡短中文字」。再者子頁面或子段落的命名格式也包含「主捷徑/子捷徑」、「主捷徑#子捷徑」及「主捷徑子捷徑連用」。目前要討論的重點包含:

  1. 是否要限縮命名格式至與英語維基百科同步?或是就現有中文維基百科的捷徑用法列舉並認定為既有規範,以後如有新的格式再討論?
  2. 中文捷徑字數是否要限制?如果字數太多,我認為就不叫捷徑了。

後面部份則是說明,在命名捷徑前先查閱是否已有慣用用法,以免產生歧異。這個我認為可以保留。臺灣杉在此發言 (會客室) 2020年11月19日 (四) 10:25 (UTC)回覆

分段討論六:前綴列表

編輯

第一個是命名空間別名,主要分為系統已經存在或經社群討論向基金會申請新增前綴後的列表,我認為算既定事實。

第二個則是偽命名空間。這裡會和R2有關係,主要是因為我曾經就建立「MOS:」捷徑,結果就被R2快速刪除,因此在現有快速刪除機制來說,這類偽命名空間被認為是主命名空間(條目)頁面連結至非主命名空間(非條目)頁面,符合R2。這裡只反映出既定事實,那這個部份是否要做文字修正,或是要修改R2的說明,這裡我沒有意見。臺灣杉在此發言 (會客室) 2020年11月19日 (四) 10:30 (UTC)回覆

建議把此段先凍結,應該還沒有共識搞偽命名空間-- Sunny00217  2020年11月22日 (日) 12:27 (UTC)回覆
這段會等前面偽命名空間討論內容有結果,會自動更新。--臺灣杉在此發言 (會客室) 2020年11月23日 (一) 10:37 (UTC)回覆
(閣下把它凍結了然後說等它的結果)-- Sunny00217  2020年11月25日 (三) 12:19 (UTC)回覆
我是凍結了,但凍結了以後還有人在討論。等七日沒有更新的討論,前面的偽命名空間討論會有一個小型總結與調查。--臺灣杉在此發言 (會客室) 2020年11月26日 (四) 10:36 (UTC)回覆

分段討論七:如何建立捷徑

編輯

這個也是操作資訊,而且分類重新導向也修正為分類重新導向模板,符合中文維基百科的慣用操作。臺灣杉在此發言 (會客室) 2020年11月19日 (四) 10:32 (UTC)回覆

此節講述分類捷徑?— ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年12月4日 (五) 06:37 (UTC)回覆
不只講捷徑分類,也講如何建立捷徑。臺灣杉在此發言 (會客室) 2020年12月4日 (五) 07:28 (UTC)回覆

分段討論八:變更捷徑、限制

編輯

變更捷徑應先查閱是否有搜尋用途或廣泛引用用途,才能進行變更。之前我曾經也改過這類捷徑,也會稍微查一下是否有其他用途,其他人我是不知道,但我認為這個習慣應該要建立起來。

至於限制段落,屬於既定事實,應可保留。臺灣杉在此發言 (會客室) 2020年11月19日 (四) 10:36 (UTC)回覆


本討論將會和上面的討論整合,並進行分階段修訂。臺灣杉在此發言 (會客室) 2020年12月6日 (日) 07:40 (UTC)回覆


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

捷徑空間提案2

編輯

導航模板請參閱此

設立捷徑專用命名空間無法有效解決WP:捷徑指引草案修訂核心問題,但提出的Shortcut:命名空間本身並無問題。由於WP:命名空間通常只用於通往Wikipedia:命名空間的重新導向,此命名空間可成爲通往任何地方的重新導向。但同時應該先解決CSD R2問題

在此PING捷徑空間提案的討論者A2569875LuciferianThomas--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2021年1月20日 (三) 09:33 (UTC)回覆

我對開啟此命名空間有以下疑問:
  1. 開設作用是什麼?是給重新導向至哪裡用?
  2. 使用者使用捷徑空間有何限制?
以上。--LuciferianThomas留言 2021年1月22日 (五) 08:10 (UTC)回覆
@LuciferianThomas
  1. 開設作用之一是把SIGN指向USERPAGE的部分壓縮,已經建立沙盒,因技術問題,請進入edit介面檢視。
  2. 假如w.wiki連結可以加到SIGN來成爲USERNAME連結,此問題應該可以用w.wiki解決。
以上。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2021年1月23日 (六) 00:05 (UTC)回覆
如何限制連結霸王的出現?--LuciferianThomas留言 2021年1月23日 (六) 03:24 (UTC)回覆
w.wiki ? 非本站連結無法重新導向,不要說 w.wiki 了,連重新導向到en:都做不到(你可以建立頁面,但重新導向不會自動跳轉,是無效的,只能軟重新導向。順帶一提指向Special空間的也只能軟重新導向。)這是技術限制。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月23日 (六) 03:25 (UTC)回覆
在此解答問題:
  1. @LuciferianThomas:連結霸王問題:啥是連結霸王?
  2. @A2569875:本站連結無法重新導向問題:我的意思是在WP:SIGN裏用[https://w.wiki/vZz]代替[[User:VeryLongUserNameFooBarHelloWorld]]
  3. @A2569875:形式問題:「捷徑:名稱」
--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2021年1月24日 (日) 08:07 (UTC)回覆
連結霸王就是說一個人霸佔大量連結空間。--LuciferianThomas留言 2021年1月24日 (日) 08:43 (UTC)回覆

List:

編輯

明顯只有IP支持提案,雪球關閉-- Sunny00217  2021年2月11日 (四) 15:40 (UTC)回覆

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


看來是直接複製#捷徑空間提案2。--LuciferianThomas留言 2021年2月9日 (二) 13:36 (UTC)回覆

導航模板請參閱此

WP:投票/列表命名空間--58.152.140.58留言2021年2月9日 (二) 12:09 (UTC)回覆

(-)強烈反對,見本人上頁之留言。--LuciferianThomas留言 2021年2月9日 (二) 12:20 (UTC)回覆
IP使用者挺有意思的,不知道是誰的傀儡(嗎?)。不打算肯定地否定,但這樣改變大動干戈、大概率得不償失,看不到必要性。--YFdyh000留言2021年2月9日 (二) 12:30 (UTC)回覆
名含「列表」的條目大約1.85萬條(另加「名單」875條),非不可行,條目空間總計117萬頁面呢,某些機器人也會建立上萬頁面。但是,為何要改呢,相關方針、模板、習慣等也全要改,且英語等主流wiki也還沒有這樣做。--YFdyh000留言2021年2月9日 (二) 12:45 (UTC)回覆
這是要來做什麼的?只放個框框在這裡也沒說要做什麼…--安憶Talk 2021年2月9日 (二) 12:49 (UTC)回覆
看IP留言連結的頁面。--LuciferianThomas留言 2021年2月9日 (二) 12:51 (UTC)回覆
原因
  1. (一)過多「列表」的主空間頁面,需分類,(二)主空間不太適合列表。
  2. 基本上(二)不行,(一)雖然可以用Category:列表,但不太明顯
  3. 會引起新手不方便問題(中等重要),但可以把「ABC列表」#Redirect到「List:ABC」
  4. 優點是不會有列表囤積主空間,缺點是無法引新手編輯
  5. 可以解決列表在主空間過多,但不可不在維基百科的間題
  6. 已有例子:lt:Vikipedija:Sąrašai(立陶宛文維基)
  7. 可和「維基百科:特色列表評選」合作,並設立列表的標準。

--58.152.140.58留言2021年2月9日 (二) 13:19 (UTC)回覆

  • 1是什麼?2是什麼?3是什麼?沒頭沒尾的,誰知道你在說什麼?—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月9日 (二) 13:26 (UTC)回覆
  • (:)回應
    1. 請定義何謂「過多列表的主空間頁面」。沒有人理解這個沒頭沒尾的描述。
    2. 「基本上(二)不行」,甚麼東西不行? 為什麼不行? Category:列表的甚麼東西明顯? 請定義何謂「不太明顯」。沒有人理解這個沒頭沒尾的描述。
    3. 為什麼需要,根本多此一舉,畫蛇添足。
    4. 哪有囤積主空間? 請具體舉例; 無法引新手編輯 為何無法,試證明。
    5. 不可不在維基百科的間題是甚麼東西? 那甚麼東西可在維基百科?
    6. 請避免是立陶宛文維基說的!類的論述,謝謝。如果您喜歡其他專案的做法,就請您做些功課,調查一下其他專案這麼做的來龍去脈。如果您認為該做法確實適合中文維基,就請您在討論中具體闡述,此做法為何適合中文維基。只要您的理由能服人,社群自然會接受這一做法。
    7. 甚麼合作? 特色列表本來就是要針對列表的評選。
  • 以上-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月9日 (二) 13:48 (UTC)回覆
原因
  1. 目前有過多在主空間的列表,而不太適合主空間,並必須為維基百科補充。
  2. 本問題無法在現有框架解決
  3. 雖然會引起新手不方便問題(中等重要),但可以把「ABC列表」#Redirect到「List:ABC」
  4. 今後將不會有列表囤積主空間,缺點是新手不知道如何編輯
  5. 可以解決列表在主空間過多,但不可不在維基百科的間題
  6. 已有例子:lt:Vikipedija:Sąrašai(立陶宛文維基)
  7. 能為「維基百科:特色列表評選」設立列表的獨立標準。
──以上未簽名的留言由119.237.10.81討論貢獻)加入。
  • (:)回應
    1. 為什麼列表不太適合主空間? 請你證明。
    2. 甚麼問題無法用現有框架解決? 甚麼也沒說想矇混或去? 主空間並沒有裝不下列表這種問題。
    3. 你根本沒說「ABC列表」#Redirect到「List:ABC」是在幹嘛,請不要當複讀機
    4. 一樣,請證明為何列表不應該放在主空間? 放在主空間造成了甚麼問題? 在我看來完全沒有問題,全部都是閣下在作夢。
    5. 列表在主空間哪有過多? 你根本還在避重就輕!
    6. 請避免是立陶宛文維基說的!類的論述,謝謝。如果您喜歡其他專案的做法,就請您做些功課,調查一下其他專案這麼做的來龍去脈。如果您認為該做法確實適合中文維基,就請您在討論中具體闡述,此做法為何適合中文維基。只要您的理由能服人,社群自然會接受這一做法。 請避免是立陶宛文維基說的!類的論述,謝謝。如果您喜歡其他專案的做法,就請您做些功課,調查一下其他專案這麼做的來龍去脈。如果您認為該做法確實適合中文維基,就請您在討論中具體闡述,此做法為何適合中文維基。只要您的理由能服人,社群自然會接受這一做法。 請避免是立陶宛文維基說的!類的論述,謝謝。如果您喜歡其他專案的做法,就請您做些功課,調查一下其他專案這麼做的來龍去脈。如果您認為該做法確實適合中文維基,就請您在討論中具體闡述,此做法為何適合中文維基。只要您的理由能服人,社群自然會接受這一做法。 很重要所以說3遍。
    7. 的獨立標準早就有了,設甚麼鬼?
    以上-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月10日 (三) 11:23 (UTC)回覆
    (※)注意未見解決,仍然避重就輕。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月10日 (三) 14:10 (UTC)回覆
  • (:)回應
    1. 為什麼列表不太適合主空間? 請你證明。
    2. 甚麼問題無法用現有框架解決? 甚麼也沒說想矇混或去? 主空間並沒有裝不下列表這種問題。
    3. 你根本沒說「ABC列表」#Redirect到「List:ABC」是在幹嘛,請不要當複讀機
    4. 一樣,請證明為何列表不應該放在主空間? 放在主空間造成了甚麼問題? 在我看來完全沒有問題,全部都是閣下在作夢。
    5. 列表在主空間哪有過多? 你根本還在避重就輕!列表在主空間哪有過多? 你根本還在避重就輕!列表在主空間哪有過多? 你根本還在避重就輕!列表在主空間哪有過多? 你根本還在避重就輕!列表在主空間哪有過多? 你根本還在避重就輕!列表在主空間哪有過多? 你根本還在避重就輕!列表在主空間哪有過多? 你根本還在避重就輕!列表在主空間哪有過多? 你根本還在避重就輕!列表在主空間哪有過多? 你根本還在避重就輕!
    6. 請避免是立陶宛文維基說的!類的論述,謝謝。如果您喜歡其他專案的做法,就請您做些功課,調查一下其他專案這麼做的來龍去脈。如果您認為該做法確實適合中文維基,就請您在討論中具體闡述,此做法為何適合中文維基。只要您的理由能服人,社群自然會接受這一做法。 請避免是立陶宛文維基說的!類的論述,謝謝。如果您喜歡其他專案的做法,就請您做些功課,調查一下其他專案這麼做的來龍去脈。如果您認為該做法確實適合中文維基,就請您在討論中具體闡述,此做法為何適合中文維基。只要您的理由能服人,社群自然會接受這一做法。 請避免是立陶宛文維基說的!類的論述,謝謝。如果您喜歡其他專案的做法,就請您做些功課,調查一下其他專案這麼做的來龍去脈。如果您認為該做法確實適合中文維基,就請您在討論中具體闡述,此做法為何適合中文維基。只要您的理由能服人,社群自然會接受這一做法。 很重要所以說3遍。
    7. 的獨立標準早就有了,設甚麼鬼?
    以上-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月10日 (三) 14:10 (UTC)回覆
以下再次複製在原頁面本人提出的反對意見完整內容。
(-)強烈反對:提案存在根本性問題,如下:
  1. 「主空間過多列表內容需分類」:已存在分類空間作出分類,要做分類不應該以設立新命名空間處理;
  2. 提案人以維基專題空間作為例子,將維基專題分離於計畫/維基百科空間是因為實際上維基專題並不完全符合計畫空間的用途:「提供了有關維基百科的內容資訊,包括維基百科自身的資訊、方針、指引、論述,以及維基人的討論空間『互助客棧』、知識問答等」,與該空間連結度明顯相對較低,故分離該空間並有太多反對意見;相對列表與主空間的內容存在高度關聯性,分離有礙使用者瀏覽維基百科;
  3. 中文維基百科有成千上萬的列表條目,在設立此空間時需要做出極大規模的移動操作,高度擾亂日常運作;相對設立維基專題空間時移動的內容與大部分的運作無關,一般只有較資深維基使用者才會涉足維基專題,移動操作不會影響日常運作;
  4. 移動如此大量的條目後會出現極大量移動重新導向,這些重新導向都是跨空間重新導向,現有方針指引配套不支持偽命名空間捷徑以外的跨空間重新導向,且在維護上會出現極大問題;
  5. 大部分維基使用者都較少鑽研技術細節,不會知道有這個命名空間的存在,開設新列表條目時很自然會在主空間建立條目,透過技術方式阻擋有關編輯容易造成新使用者困擾,變相不鼓勵使用者建立,影響中維發展;
    • 分離專題空間可考慮開設專題的使用者一般比較資深,熟悉中維環境,且比較關注社群變化,對於建立新專題不會有太大問題;但分離列表空間影響的是廣大使用者群,不難想像需要如此多的使用者適應新環境是有多困難。
閣下作為IP使用者,可對於設立此命名空間做出的貢獻極度有限,我難以接受閣下不負責任地提出此提案並要求做出如此大影響的操作,卻可以完全置身事外,要其他使用者幫你收拾處理。綜合以上,提案存在大量根本性問題,弊明顯大於利,故(-)強烈反對此提案。LuciferianThomas留言 2021年2月8日 (一) 11:10 (UTC)回覆
--LuciferianThomas留言 2021年2月9日 (二) 13:35 (UTC)回覆

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

後續

編輯

該IP使用者(119.237.10.81)在互助客棧中提出以下建議

  1. 沒有共識的論述改用Help:
  2. 加入Humor:命名空間(別名:幽默、餵雞百科)用於幽默:WP:)
  3. 更名:
    1. 主題:→專題首頁:
    2. 維基專題:→專題計畫頁:
    3. WikiProject:→PortalProject:

由於洗版被回退、封鎖。 ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年4月24日 (六) 15:00 (UTC)回覆

專題命名空間(第一至二階段)

編輯
已佈署:
大部分核心項目皆已佈署,其餘細小部分分開討論。-- 五歲抬☎️·☘️2021年5月6日 (四) 03:54 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

導航模板請參閱此

捷徑指引草案的討論,源自於「偽命名空間」的討論,英語維基百科對於捷徑相關的規範及偽命名空間的設立已有成熟的執行方式。中文維基百科中的部分編輯者對於「格式手冊」、「長期破壞者」及「專題」這三個主題提出可升級成命名空間或以偽命名空間形式存在,並有正反兩方的陳述與看法。

目前較為接近共識的是「專題」提升為正式命名空間,反對者的論述已由支持者回應,且反方無進一步論述。然為求慎重,且將捷徑與命名空間等議題作系統性討論,將會執行階段修訂,以取得最大共識。

本討論的各階段分為:

  1. 專題提升為命名空間與否及其細節
  2. 格式手冊及長期破壞者是否成為命名空間或偽命名空間
  3. 偽命名空間規範寫入捷徑規範內(如前項通過)或是否允許偽命名空間(如前項不通過)
  4. 捷徑規範細部討論並決定是否成為指引。

各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)回覆

專題命名空間通過,剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (UTC)回覆
目前的後續討論須等phab:T271612佈署完畢後才能繼續進行。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月12日 (二) 13:08 (UTC)回覆

大部分核心項目皆已佈署,其餘細小部分分開討論。本結關閉,結以待續,以便存檔。如要開新的討論,請開新的二級標題。-- 五歲抬☎️·☘️2021年5月6日 (四) 03:54 (UTC)回覆


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

已通過:
  公示7日無合理異議,本議案通過。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月3日 (日) 07:44 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

直接將PJ:獨立為新WP:命名空間

(&)建議像日文維基那樣,專題直接變成一個 "真" 命名空間 ja:Help:名前空間#プロジェクト就不會有cwek說的 "假" 命名空間 的 混淆問題了。日維相關討論。 -- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年11月16日 (一) 06:06 (UTC)回覆

依據先前討論,專題命名空間的討論已接近達成共識之階段,目前問題包含:

  1. 英文命名部分,其一為Project並取消與Wikipedia空間連動,其二為以WikiProject命名;
  2. 部分使用者認為直接將PJ與Wikipedia連動即可。

請討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)回覆

  • 個人以為Project命名空間肯定不能變,否則可能會造成不少連結失效。因此命名空間應該命名為「WikiProject」,對應的中文命名空間應該命名為「維基專題」,以便於與「WikiProject」對應。——BlackShadowG留言2020年12月11日 (五) 16:27 (UTC)回覆
    • 我認為中文叫做「專題」並無不妥,也無衝突。將「WikiProject:」作為程式系統前綴;「專題」、「維基專題」、「PJ」作為別名。其他中文別名也可以之後再議再補。並依照法維和日維和其他姐妹專案的統一定義,定為{{ns:102}}(目前顯示為「WikiProject」,空白是因為本地尚未實裝)。— ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年12月11日 (五) 18:16 (UTC)回覆
確定英文名稱不會衝突就可以,中文名稱應該沒問題。SANMOSA SPQR 2020年12月12日 (六) 03:34 (UTC)回覆
支持命名為WikiProject/專題 ——羊羊 (留言|貢獻) 2020年12月16日 (三) 15:08 (UTC)回覆


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

專題空間設立流程與細節

編輯
已佈署:
大部分核心項目皆已佈署,其餘細小部分分開討論。-- 五歲抬☎️·☘️2021年5月6日 (四) 03:54 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

參考ja:Special:PermaLink/39099771#ウィキプロジェクト用名前空間の新設以及ja:Wikipedia:ウィキプロジェクト/名前空間の新設,本地的處理方式預計會分成5個階段進行:

  1. phab:提交申請設立專題空間;(已佈署)
  2. 將專題頁與討論頁批次移動到專題空間(可能需WP:FLOOD);(已完成)
  3. 修正指向專題的內部連結(可能需WP:FLOOD);(併入第五階段執行)
  4. 調整專題模板;(已調整)
  5. 討論重新導向與捷徑的設立方式;
  6. 其他議題。
以上。以上流程不會立即執行,會在社群對流程沒有異議之後公示後執行。如有其他相關疑問可繼續在下方討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月3日 (日) 07:44 (UTC)回覆

大部分核心項目皆已佈署,其餘細小部分分開討論。本結關閉,結以待續,以便存檔。如要開新的討論,請開新的二級標題。-- 五歲抬☎️·☘️2021年5月6日 (四) 03:54 (UTC)回覆


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

第一階段:申請

編輯
已通過:
已通過公示,亦完成布署(前端 by User:AnYiLin後端 by User:A2569875),專題命名空間已於中文維基百科生效,將立即進行下一階段討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月27日 (三) 04:06 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

  • 將會提供給phab:的細節如下:
命名空間 討論空間
內部名稱
(前綴)
WikiProject: WikiProject_talk:
ID 102 103
中文名稱
(介面名稱)
維基專題 維基專題討論
別名
  • 專題
  • 专题
  • 維基專題
  • 维基专题
  • PJ
  • WPJ
  • 專題討論
  • 专题讨论
  • 專題對話
  • 专题对话
  • 維基專題討論
  • 维基专题讨论
  • 維基專題對話
  • 维基专题对话
  • PJT
  • WPJT
-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月3日 (日) 09:41 (UTC)回覆
  轉交phab:T271612。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月9日 (六) 08:16 (UTC)回覆

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

第一點五階段:內容事實修訂

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

由於該命名空間設立完畢,已修正WP:命名空間新增該空間說明。如需補充歡迎討論。臺灣杉在此發言 (會客室) 2021年1月27日 (三) 13:40 (UTC)回覆

您漏了WP:NS#縮寫和別名。--LuciferianThomas留言 2021年1月28日 (四) 08:08 (UTC)回覆
完成。--臺灣杉在此發言 (會客室) 2021年1月29日 (五) 13:37 (UTC)回覆
請協助複查是否全部的相關說明頁都修復完畢。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月25日 (四) 05:49 (UTC)回覆

已修訂-- 五歲抬☎️·☘️2021年5月6日 (四) 02:53 (UTC)回覆


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

第二階段:轉移至新命名空間

編輯
已通過:
公示從2021年1月6日起至2021年1月14日暫停再從2021年1月26日起至1月29日共11天,期內所有異議的論述已由支持者回應,且反方無進一步論述,故無合理異議,議案通過。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月29日 (五) 13:04 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

命名空間設立完畢後,將會把所有列於Category:維基專題中的頁面及子頁面轉移至新命名空間,預計轉移的頁面及轉移之目標列於此頁Wikipedia:專題/提升為命名空間/影響頁面(暫不包括重新導向),如有異議請盡快提出。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月3日 (日) 19:26 (UTC)回覆

第二階段 之 公示狀態通告

編輯

第二階段 之 公示期討論

編輯

  公示通過,即將開始移動-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月29日 (五) 13:04 (UTC)回覆


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


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


已完成更名-- 五歲抬☎️·☘️2021年5月6日 (四) 03:49 (UTC)回覆


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
專題指引更名:第二階段
結以待續:
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
「維基專題:維基專題:XX」的頁面
已處理:
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。



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

專題命名空間(第二點五至四階段)

編輯


導航模板請參閱此。導言請參閱此

第二點五階段:相關技術問題修正

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

根據phab:T273763(設立專題空間後,連結至此的頁面API於 pywikibot 出錯),此修正案導致部分機器人出錯。目前phab:T273763已解決,留此節討論其他相關技術出問題時的策略與解決方案。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月8日 (一) 17:54 (UTC)回覆

前幾天發現WikiProject:傳統百科全書條目因為頁面移動後造成大部分子頁面出現錯誤,目前已經修復一部分--百無一用是書生 () 2021年3月16日 (二) 02:37 (UTC)回覆
(?)疑問@Shizhao:還有多少部分需要修正,有沒有例子,或列表?-- 五歲抬☎️·☘️2021年5月6日 (四) 02:51 (UTC)回覆
WikiProject:傳統百科全書條目下的所有json子頁面--百無一用是書生 () 2021年5月6日 (四) 03:33 (UTC)回覆
JSON不支援重新導向,所以所有連入都需要進行修正。--Xiplus#Talk 2021年5月6日 (四) 03:45 (UTC)回覆
能否提供需要修正的頁面總表?-- 五歲抬☎️·☘️2021年5月13日 (四) 04:29 (UTC)回覆

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

第三階段:修正指向專題的內部連結

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

各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月3日 (日) 19:29 (UTC)回覆


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

第四階段:調整專題模板

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


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

其他事項

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

※註:第二點五階段還有東西在詢問。-- 五歲抬☎️·☘️2021年5月6日 (四) 02:58 (UTC)回覆

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

偽命名空間(階段一:設立前)

編輯
已佈署:
大部分核心項目皆已佈署,其餘細小部分分開討論。-- 五歲抬☎️·☘️2021年5月6日 (四) 04:14 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

導航模板請參閱此


大部分核心項目皆已佈署,其餘細小部分分開討論。本結關閉,結以待續,以便存檔。如要開新的討論,請開新的二級標題。-- 五歲抬☎️·☘️2021年5月6日 (四) 04:14 (UTC)回覆


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

本案討論格式手冊及長期破壞者提升問題。目前有三案:

  • 格式手冊及長期破壞者提升為命名空間,英語名稱待定;
  • 格式手冊及長期破壞者成為偽命名空間,縮寫為MOS及LTA;
  • 維持現行方式。

請討論。臺灣杉在此發言 (會客室) 2020年12月25日 (五) 01:23 (UTC)回覆

建議立為偽命名空間(方案2)。SANMOSA SPQR 2020年12月27日 (日) 07:32 (UTC)回覆
支持提升為命名空間,因為會違反快速刪除方針的R2準則。 2020年12月28日 (一) 07:06 (UTC)回覆
如果是偽命名空間通過,就會在下一階段修訂快速刪除、捷徑以及命名空間規範。--臺灣杉在此發言 (會客室) 2020年12月28日 (一) 09:53 (UTC)回覆
支持成為偽命名空間。命名空間涉及較多技術問題,未來如需求明顯,可再議轉換。--YFdyh000留言2020年12月30日 (三) 13:01 (UTC)回覆
如需要立為命名空間也並非不可,只是要決定其所使用的數字ID
  • 0-99的命名空間ID要保留給維基媒體系統使用,故需要使用100以上的命名空間ID
    下面整理許多語言版本維基百科的命名空間ID使用(主空間是偶數,討論空間是奇數)
命名空間 命名空間ID
/
討論頁ID
維基百科
各語言版本
使用狀況(未窮舉)
本地使用狀況 備註
主題: 100/101 全部語言版本維基百科皆有啟用 參考此處整理 本地已使用 Help:主題
專題: 102/103 中文及加泰蘭文世界文法文韓文奧克西坦文日文 本地已使用 Wikipedia:專題
附件: 104/105 西班牙文 未使用 類似中文維基辭典的附錄
列表: 104/105 立陶宛文維基 未使用 WP:列表
文獻: 104/105 法文奧克西坦文 未使用 參考User:青子守歌的整理
仲裁: 106/107 俄羅斯文 未使用 (本地未通過相應指引)
WP:仲裁委員會
圖書: 108/109 超過25個語言版本使用。 本地通過的共識為 :
繁簡轉換系統處理完畢後引入,然而P站仍在努力中,因此還是有機會使用此數值
Help:圖書
110/111 未使用
草稿: 118/119 超過25個語言版本使用。 本地已使用 WP:草稿
以上補充。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2020年12月31日 (四) 09:52 (UTC)回覆
(+)支持為設立偽命名空間,對設為真命名空間(#)有保留。--LuciferianThomas留言 2020年12月31日 (四) 15:58 (UTC)回覆
我對成立真命名空間(#)有保留,尤其是格式手冊。對格式手冊而言,因為格式手冊同時也是指引,對它成立真命名空間將意味著指引分散兩地。 --Milky·Defer 2020年12月31日 (四) 17:13 (UTC)回覆

小結1

編輯

標題添加: ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:21 (UTC)回覆

我想補充一個意見:我反對MOS及LTA設為真命名空間,僅支持MOS及LTA設為偽命名空間。SANMOSA SPQR 2021年1月2日 (六) 08:17 (UTC)回覆
支持命名空間,反對偽命名空間。SmallTim留言2021年1月5日 (二) 13:56 (UTC)回覆
(?)疑問@SmallTim:有鑑於WP:投票不能代替討論,能否請您補充一下反對偽命名空間的理由,以便彙整、推進討論?感激不盡。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月5日 (二) 18:25 (UTC)回覆
這整得跟投票一樣,建議各位將(+)支持(-)反對的理由寫出來,逐一進行討論,以此達到共識。畢竟投票不能代替討論。 ——羊羊 (留言|貢獻) 2021年1月5日 (二) 15:50 (UTC)回覆
我建議直接排除成為真命名空間的可能性,這樣會產生維護問題。SANMOSA SPQR 2021年1月6日 (三) 06:10 (UTC)回覆
方針指引宜集中於同一命名空間。SANMOSA SPQR 2021年1月6日 (三) 06:45 (UTC)回覆
(!)意見SanmosaLTA不是方針、指引、態度指引、草案、提議、論述、專題、主題、存檔、書籍、條目、分類、介面...都不是。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月6日 (三) 06:48 (UTC)回覆
那你當我的建議僅適用於MOS。SANMOSA SPQR 2021年1月6日 (三) 06:51 (UTC)回覆
(?)疑問:有多少此次提案涉及的LTA?--Yining Chen留言|簽名2021年1月7日 (四) 05:39 (UTC)回覆

以上。--LuciferianThomas留言 2021年1月8日 (五) 02:01 (UTC)回覆

把LTA設定成命名空間的一個效果是可以設定所有頁面為noindex(包括少數不使用LTA模板的子頁),雖然社群要評估一下這麼做的價值。--GZWDer留言2021年1月10日 (日) 14:42 (UTC)回覆

小結2

編輯

標題添加: ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:21 (UTC)回覆

@A2569875Taiwania Justo:其實我覺得上方的總結可能會導致共識的混淆。

表達意見使用者 格式手冊(MOS) 長期破壞者(LTA) 備註
升格命名空間 設偽命名空間
允許R2例外
升格命名空間 設偽命名空間
允許R2例外
Yining Chen 傾向反對 支持 傾向反對 支持
羊羊32521 反對 支持 傾向支持 支持 LTA傾向,意見優先取
Sanmosa 反對 支持 支持
Pseudo Classes 支持 反對 支持 反對 以違反CSD R2為由反對議案是否WP:CCC
YFdyh000 支持 支持
LuciferianThomas 有保留 支持 有保留 支持
Ericliu1912 反對 傾向支持 反對 支持
MilkyDefer 有保留 支持 有保留 支持 早前討論
Super Wang 可開可不開 支持 早前討論
Cwek 反對 反對 早前討論
Lopullinen 傾向反對 傾向反對 早前討論
Sunny00217 支持 支持 早前討論
總計 2 : 4 : 2 7 : 3 : 1 3 : 2 : 3 8 : 3 : 0

此總結方式會否更加清晰?--LuciferianThomas留言 2021年1月12日 (二) 02:06 (UTC)回覆

澄清一下,因為現行方針尚未針對此議題修正,實不宜直接設立偽命名空間,我認為修正方針應要在此議題之前完成。道理就像UBER進入到某市場一樣,應在其進入市場前設立相應法規,避免無法與計程車公平競爭、司機有無載客資格和違法現行法規等問題。-- 2021年1月12日 (二) 17:45 (UTC)回覆
此外,反對偽命名空間的理由是,MOS和LTA既為縮寫,儘管名義上是偽命名空間,但是實際上仍屬於條目命名空間,這樣子與其內容衝突非常奇怪,更何況現存有許多辨識命名空間的模板,身為重度模板使用者,我不希望辨識偽命名空間時,輸出的結果為「條目」。-- 2021年1月12日 (二) 17:57 (UTC)回覆
  • 在模板裡面放if else不就好了。Module亦然。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月12日 (二) 18:07 (UTC)回覆
    @A2569875:您應該明白我的重點不在這裡吧。-- 2021年1月17日 (日) 14:20 (UTC)回覆
    • 山不轉路轉、路不轉人轉。大可以將所有判斷命名空間的模板在判斷前先匹配偽命名空間表再做進一步輸出,看不出有什麼問題,很多語言版本維基都有它自己的「本地特化」。 對於傾向支持偽命名空間(當然如可能我還是希望命名空間啦,但基金會那邊不一定會買單,你看編輯審核保護和Book:命名空間工單提那麼久還在「神秘的技術問題擱置」就知道有多難,何況其他語言版本沒有先例)對於傾向支持偽命名空間的立場者來說,當然會提出傾向於去符合對偽命名空間有利的方案去做提議。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月17日 (日) 14:38 (UTC)回覆
      偽命名空間只是一個重新導向頁面,模板所處的頁面還是在專案空間上,當然不會輸出「條目」,就像這個連結User:羊羊32521/S/VP點進去不會造成Wikipedia:互助客棧變成「使用者頁面」一樣。 ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:14 (UTC)回覆
  • 不認為以上問題是問題,模板模組加個if-else或switch case在本地特化的命名空間便是模板/模組不就好了,況且現在有不少的命名空間判斷都不是直接引用魔術字,是使用中介模板例如{{Namespace_detect}},在裡面補充if-else或switch case不就好了,先前討論早就提議了「建立允許不快速刪除的偽命名空間列表」,難道列表只能列在指引哩,不能寫在程式裡??;關於介面是同理,將是偽命名空間的頁面改掉顯示名稱不就得了?技術上到底是有甚麼障礙,我看不出,有障礙的分明是「你不想」吧,例如下方列舉的程式碼片段:
以上。再來,快速刪除方針,請參閱WP:CCC。 未見系統性問題,謝謝。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月19日 (二) 07:14 (UTC)回覆
在偽命名空間部分,我是以「有需求」為前提,如果共識認為不需設立或不能設立,那就是維持原案,也就沒有需要修方針的問題。--臺灣杉在此發言 (會客室) 2021年1月13日 (三) 02:58 (UTC)回覆
而以現時討論而言主流意見為將MOS和LTA設為偽命名空間。--LuciferianThomas留言 2021年1月13日 (三) 05:16 (UTC)回覆
@LuciferianThomas:影響的範圍較大,即使有主流共識,目前討論的參與者人數並不能代表整個社群。 2021年1月17日 (日) 14:17 (UTC)回覆
能有多大?,不就條目命名空間裡多幾個幾乎不會發生命名衝突的捷徑而已?怎麼講的好像設立下去維基伺服器會炸掉一樣。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月17日 (日) 14:43 (UTC)回覆
關於主流意見的共識,我認為引用WP:7DAYS並無不妥,你不可能直接讓幾千人一起討論,你這樣說乾脆舉辦維基社群公投算了,BUT:WP:投票不能代替討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月17日 (日) 14:45 (UTC)回覆
個人認為,如果長期破壞者(LTA)有成為命名空間的潛力的話,應該此時直接升級成為命名空間。不然,如果之後再討論升級為命名空間,所有帶LTA:前綴的頁面還要重新移動一遍。 ——羊羊 (留言|貢獻) 2021年1月15日 (五) 12:04 (UTC)回覆
感覺LTA頁面及命名空間有違WP:RBI。如果設立命名空間的同時增設頁面檢視權限(回退員及以上),我會考慮支持。--YFdyh000留言2021年1月15日 (五) 12:28 (UTC)回覆
但似乎普遍意見並不贊同LTA升格真命名空間,即使有潛力但卻缺乏社群共識,也難以行事。--LuciferianThomas留言 2021年1月15日 (五) 17:40 (UTC)回覆

(-)反對設立MOS和LTA命名空間,這與技術問題無關,而是目前MOS和LTA頁面的數量和讀者關注的程度遠遠達不到需要設立新命名空間的地步。LTA頁面的數量充其量也就一百個左右,MOS頁面的數量更是少得可憐,才十幾個,遠遠沒有達到維基專題那樣的2000多個頁面。同時,LTA只有熟悉CU等站務的編者會去查閱,MOS查閱的人數更少,這些也完全比不上熟悉某些特定領域的編者和讀者都會關注的維基專題。因此,我反對設立以上兩個命名空間,對設立偽命名空間表示(=)中立。——BlackShadowG留言維基百科20周年慶即將到來 2021年1月15日 (五) 13:41 (UTC)回覆

LTA數量可能少,但shortcut還是蠻多的。而且LTA數量也會增多-- ——羊羊 (留言|貢獻) 2021年1月16日 (六) 12:55 (UTC)回覆
偽命名空間只是for捷徑連結而已,原本的頁面不會被移動。--LuciferianThomas留言 2021年1月16日 (六) 13:12 (UTC)回覆
  • (+)支持偽命名空間。我原本是支持命名空間的,但經歷了上述討論以及主持了專題命名空間的設立,我發現偽命名空間是有許多優點的。先看命名空間,命名空間是需要「安裝」的,本地獲得共識之後要等待工程師安裝,期間從數周到數月不等,且不具備可擴充性,即每新增一個命名空間都要請工程師協助,本地管理員、介面管理員、模組編輯員都無能為力,只有基金會工程師可以執行,「真命名空間」可擴充性不佳。我們來看看「偽命名空間」,它「免安裝」耶,隨加即用,涉及命名空間判斷的本地模板與模組本地的管理員、介面管理員、模組編輯員都能即時加入,也不必等待工程師安裝,「偽命名空間」可擴充性十分良好。假如今天社群需要一個新的捷徑前綴或字首,真命名空間需要等待工程師安裝,而偽命名空間公示通過後就能隨加即用,是多麼的方便。正如臺灣杉在此發言 (會客室)所言:「如果偽命名空間不會造成「系統性」的重大問題,就可以納入考量。」且許多問題如模板輸出都可以透過技術手段解決,參見#宇帆於2021年1月19日 (二) 07:14 (UTC)之發言。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月19日 (二) 07:16 (UTC)回覆

已通過並設立-- 五歲抬☎️·☘️2021年5月6日 (四) 03:00 (UTC)回覆


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

捷徑空間提案

編輯

標題添加: ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:21 (UTC)回覆

否決:
設立捷徑專用命名空間無法有效解決本案核心問題。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月20日 (三) 07:14 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。


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

小結3

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

 
使用者自訂的Common.js測試有關代碼的結果。測試於[[MOS:001]]
(:)回應@LuciferianThomas:已測試相關代碼(程式碼片段)在Common.js中的行為,Special:Diff/63843386,以[[MOS:001]]為例,效果見圖File:Pseudo-Namespace MOS UI Test in Chinese Wikipedia.png。如偽命名空間通過設立可以考慮請求介面管理員添加相關代碼於MediaWiki:Common.js。副知@羊羊32521:重新導向頁面顯示條目已有可行解決辦法。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月21日 (四) 08:32 (UTC)回覆
  • 其實照這個思路,如果怕偽命名空間占用條目命名空間,又怕(對於MOS:)指引分散,可以設立MOS:命名空間,然後MOS:下的頁面重新導向到Wikipedia空間的格式手冊里 ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:21 (UTC)回覆
    這不太符合邏輯吧,同時存在「格式手冊」命名空間和專案(維基百科)命名空間的格式手冊。額外設立一個「格式手冊」或「長期破壞者」命名空間但只作重新導向用,好像沒什麼意義。--LuciferianThomas留言 2021年1月19日 (二) 07:48 (UTC)回覆

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


再提捷徑空間提案

編輯

嘗試推動LTA空間

編輯
結以待續,請發起新議案。--LuciferianThomas留言 2021年1月31日 (日) 23:09 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

經過上方的討論,我認為LTA更適宜作為真·命名空間。好處是(上方有人提到)可以設定所有頁面為NOINDEX,增設頁面檢視權限(體現WP:RBI,而且有天邪鬼這種……)。

此外,LTA與Project空間聯繫性不大,沒有維護問題。而且,如果設偽命名空間之後再討論升級為命名空間,所有帶LTA:前綴的頁面還要重新移動一遍。(mw:Help:Namespace)

至於LTA頁面數量少……我是不知道設立命名空間還有頁面數量門檻啊……  囧rz…… ——羊羊 (留言|貢獻) 2021年1月23日 (六) 05:20 (UTC)回覆

如果使用者不可檢視的命名空間不會顯示在Special:搜尋,我想命名空間多不是個大問題。贊成「LTA與Project空間聯繫性不大」。不認為二次移動是個大問題,社群可以先用偽命名空間看看效果。--YFdyh000留言2021年1月23日 (六) 12:25 (UTC)回覆

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

偽命名空間相關方針及WP:捷徑修正

編輯
通過:
Taiwania JustoPseudo ClassesSanmosaA2569875GZWDer公示七日結束,共識期間唯一異議排除,公示獲得通過,有關條文。即日起MOS、LTA偽命名空間獲得CSD R2例外,上述命名空間作為格式手冊和長期破壞者頁面的正規連結。--LuciferianThomas留言 2021年1月31日 (日) 03:11 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

本討論已近一個月,得到的回饋有:

  1. 主流意見認為格式手冊及長期破壞者(持續出沒的破壞者)宜設立偽命名空間;
  2. 已有技術手段可分出偽命名空間與主命名空間的差異性;
  3. 設立偽命名空間無重大系統性問題,且部署容易,不牽涉到基金會層面之程式修改。

由此,偽命名空間將會在上段討論開始一個月後進行公示(也沒過幾天),而相關規範也將儘速修正或設立,下列針對快速刪除方針R2進行修正,及將WP:捷徑中的偽命名空間部分做為指引。下列為R2修正提案。

現行條文

R2. 跨命名空間重新導向

由條目的命名空間重新導向至非條目命名空間,將使用者頁面移出條目命名空間時遺留的重新導向,或者從草稿命名空間指向非草稿命名空間的重新導向。(有時新加入的維基人偶爾會在主條目空間誤建使用者頁面。使用「移動」頁面工具將使用者頁面移回使用者名稱字空間會保留頁面歷史,在刪除遺留的重新導向頁前,考慮保留一到兩天;草稿重新導向速刪前,請確保草稿已經完成其作用,並且草稿的歷史已經合適地移動到相應的正式頁面。)
提議條文

R2. 跨命名空間重新導向

由條目的命名空間重新導向至非條目命名空間,將使用者頁面移出條目命名空間時遺留的重新導向,或者從草稿命名空間指向非草稿命名空間的重新導向。經社群同意設立的偽命名空間屬於本規則之例外。注意:有時新加入的維基人偶爾會在主條目空間誤建使用者頁面。使用「移動」頁面工具將使用者頁面移回使用者名稱字空間會保留頁面歷史,在刪除遺留的重新導向頁前,考慮保留一到兩天;草稿重新導向速刪前,請確保草稿已經完成其作用,並且草稿的歷史已經合適地移動到相應的正式頁面。

捷徑中偽命名空間的規範詳見這裡

請討論。臺灣杉在此發言 (會客室) 2021年1月20日 (三) 06:53 (UTC)回覆

同意提案。SANMOSA SPQR 2021年1月20日 (三) 08:10 (UTC)回覆
(+)贊成R2修正案,另就WP:捷徑,我看了一遍,似乎要整個重新整理過。--LuciferianThomas留言 2021年1月20日 (三) 10:04 (UTC)回覆
捷徑修正細節是最後一項討論內容,目前先以偽命名空間為討論對象。也歡迎對捷徑規範作重新整理。--臺灣杉在此發言 (會客室) 2021年1月20日 (三) 12:19 (UTC)回覆
(+)支持WP:CSD修正案與偽命名空間。我原本是支持命名空間的,但經歷了上述討論以及主持了專題命名空間的設立,我發現偽命名空間是有許多優點的。先看命名空間,命名空間是需要「安裝」的,本地獲得共識之後要等待工程師安裝,期間從數周到數月不等,且不具備可擴充性,即每新增一個命名空間都要請工程師協助,本地管理員、介面管理員、模組編輯員都無能為力,只有基金會工程師可以執行,「真命名空間」可擴充性不佳。我們來看看「偽命名空間」,它「免安裝」耶,隨加即用,涉及命名空間判斷的本地模板與模組本地的管理員、介面管理員、模組編輯員都能即時加入,也不必等待工程師安裝,「偽命名空間」可擴充性十分良好。假如今天社群需要一個新的捷徑前綴或字首,真命名空間需要等待工程師安裝,而偽命名空間公示通過後就能隨加即用,是多麼的方便,然而要實現此需要修正WP:CSD#R2,正如臺灣杉在此發言 (會客室)所言:「如果偽命名空間不會造成「系統性」的重大問題,就可以納入考量。」,參見#宇帆於2021年1月19日 (二) 07:16 (UTC)之發言,未見要修正WP:CSD#R2會出現什麼系統性問題,故此(+)支持WP:CSD修正案。以上-- 來人啊,餵宮子吃布丁! ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月21日 (四) 08:06 (UTC)回覆
想向諸位確認一下@A2569875Taiwania Justo:此案中已經說明偽命名空間的實施,意即此案通過則偽命名空間同步通過?--LuciferianThomas留言 2021年1月22日 (五) 11:32 (UTC)回覆
順序是上面的MOS、LTA先公示完畢,本案才會接著進行公示。於此期間兩邊同步討論。--臺灣杉在此發言 (會客室) 2021年1月22日 (五) 15:05 (UTC)回覆
我認為兩案必然掛鉤,建議若公示偽命名空間則同步公示R2修訂,沒有分部處理的必要。--LuciferianThomas留言 2021年1月22日 (五) 22:06 (UTC)回覆
@Taiwania Justo:兩者應當一同公示並通過,否則會有合法性問題。SANMOSA SPQR 2021年1月23日 (六) 08:55 (UTC)回覆
借問:現在討論似乎已經算超過一個月了(這提案承接上次討論,已經很久了),而已經達到基本社群共識(共識不強求全然同意,但可採取主流意見),理論上可以7DAYS?--LuciferianThomas留言 2021年1月23日 (六) 09:25 (UTC)回覆
那就現在公示吧。--臺灣杉在此發言 (會客室) 2021年1月24日 (日) 02:47 (UTC)回覆

本討論超過一個月,且偽命名空間之相關技術問題已得到解決,且主流意見認為有設定必要,現就偽命名空間、R2及WP:捷徑內的偽命名空間規範   公示7日,2021年1月31日 (日) 02:51 (UTC) 結束臺灣杉在此發言 (會客室) 2021年1月24日 (日) 02:51 (UTC)回覆

@Taiwania JustoLuciferianThomas:啟用偽命名空間能解決什麼問題?我相信這是提案必須討論的重點,我需要有人能回答這個問題。如果沒辦法解決什麼問題,我認為維持現狀即可,也就是WP足矣。然而,就我檢視整個討論,似乎都是討論命名空間真偽的可行性,只有幾個留言有提到這個問題。 2021年1月29日 (五) 04:57 (UTC)回覆
看來你是沒有看到最初的討論,見本章節頂端討論導航最初的討論,已經是說明了偽命名空間的作用為讓捷徑意義更加清晰且減少可能構成重複的捷徑名稱的情況。現在不是解決問題的情況,而是優化社群討論和表達的問題了。--LuciferianThomas留言 2021年1月29日 (五) 05:01 (UTC)回覆
一直以來捷徑都沒有什麼規範,尤其是格式手冊、維基專題及LTA的頁面重新導向,表達不清之餘容易造成混亂,偽命名空間就是讓這些項目的捷徑統一化,方便社群溝通。--LuciferianThomas留言 2021年1月29日 (五) 05:04 (UTC)回覆
例子:MOS:BOLDWP:MOSBOLD簡潔,但連結至格式手冊的捷徑沒有規範導致格式混亂難以維護,有些有WP:MOS字首有些沒有;而LTA更甚,捷徑完全沒有要表達連結目標為LTA頁面的意思。相對於WP:LTA/HBN,使用偽命名空間概念的LTA:HBN更簡潔易明。在解決捷徑的問題的同時順便推動在其他維基項目運行暢順的偽命名空間比較合適。--LuciferianThomas留言 2021年1月29日 (五) 05:13 (UTC)回覆
@LuciferianThomas:真是抱歉,我沒有一直關注這個提案,突然要找相關討論也找不到。既然如此,我沒意見了。-- 2021年1月29日 (五) 14:02 (UTC)回覆

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

偽命名空間(階段二:佈署)

編輯
已佈署:
大部分核心項目皆已佈署,其餘細小部分分開討論。-- 五歲抬☎️·☘️2021年5月6日 (四) 04:15 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

導航模板請參閱此

本案討論格式手冊及長期破壞者提升問題。目前有三案:

  • 格式手冊及長期破壞者提升為命名空間,英語名稱待定;
  • 格式手冊及長期破壞者成為偽命名空間,縮寫為MOS及LTA;
  • 維持現行方式。

請討論。臺灣杉在此發言 (會客室) 2020年12月25日 (五) 01:23 (UTC)回覆


大部分核心項目皆已佈署,其餘細小部分分開討論。本結關閉,結以待續,以便存檔。如要開新的討論,請開新的二級標題。-- 五歲抬☎️·☘️2021年5月6日 (四) 04:15 (UTC)回覆


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

進一步討論

編輯

自動提刪R2

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

現時主命名空間的R2好像有機器人自動提速刪?是否要請BOT主修正,或暫時透過過濾器阻止機器人速刪?--LuciferianThomas留言 2021年1月31日 (日) 03:11 (UTC)回覆

@Jimmy Xu。--臺灣杉在此發言 (會客室) 2021年1月31日 (日) 04:31 (UTC)回覆
Special:Diff/64056831-- Sunny00217  2021年2月1日 (一) 11:53 (UTC)回覆
已更新。--Jimmy Xu 2021年2月1日 (一) 14:07 (UTC)回覆

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

軟重新導向

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

原有的捷徑可否改為軟重新導向並作出提示「此捷徑已移動至XXX,請直接使用新捷徑」?--LuciferianThomas留言 2021年1月31日 (日) 03:11 (UTC)回覆

(-)反對,原有重新導向應保留,沒必要軟重新導向。-- 2021年1月31日 (日) 03:56 (UTC)回覆
或是透過JS小工具提示功能,讓使用者在非討論頁面中點擊舊有連結時提示修改為新連結?--LuciferianThomas留言 2021年1月31日 (日) 04:23 (UTC)回覆
不必更動,英語維基百科部分MOS也有用WP的捷徑。--臺灣杉在此發言 (會客室) 2021年1月31日 (日) 04:32 (UTC)回覆
好的,那麼就捨棄軟重新導向,只重新議論MOS的捷徑名稱。--LuciferianThomas留言 2021年1月31日 (日) 04:52 (UTC)回覆

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

技術問題處理

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

命名空間偵測模板以及MediaWiki:Common.js見此處)需要提編輯請求,以令偽命名空間生效。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月31日 (日) 05:30 (UTC)回覆

小補充:偽命名空間捷徑可用{{捷徑重新導向}}標記,已加入自動偵測偽命名空間顯示偽命名空間簡單說明。--LuciferianThomas留言 2021年2月2日 (二) 05:55 (UTC)回覆
另外@A2569875:已建立[[MOS:]]、MOS:MOSMOS:手冊MOS:格式手冊供你們測試各項技術問題。--LuciferianThomas留言 2021年2月2日 (二) 05:59 (UTC)回覆
根據Wikipedia:保護方針#需進行公示,即使偽命名空間已獲得社群共識,輕微影響外觀顯示的編輯仍需公示七日,因為未添加亦不會影響偽命名空間的運作。-- 2021年2月2日 (二) 06:29 (UTC)回覆
@LuciferianThomas。-- 2021年2月2日 (二) 06:34 (UTC)回覆
@LuciferianThomasPseudo Classes:還不能公示,因為討論仍在進行中MediaWiki_talk:Common.js#編輯請求_2021-01-31。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月2日 (二) 06:39 (UTC)回覆
不影響運作,他可以使用個人JS頁面進行測試,只是這個意思。而提及重新導向模板純粹因為這個章節叫做「技術問題處理」,沒有其他地方方便提及就在這裏說而已。--LuciferianThomas留言 2021年2月2日 (二) 07:22 (UTC)回覆
(:)回應由於U:YFdyh000提到的誤導問題,故反對使用個人使用者小工具模式,因為誤導問題就是在於不知此事的人,知道的人啟用小工具又有什麼卵用?故強烈建議全站套用。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月2日 (二) 10:50 (UTC)回覆
@A2569875:可以考慮作為預設啟用的小工具,這樣也方便維護。--安憶Talk 2021年2月2日 (二) 12:35 (UTC)回覆
@Pseudo Classes:閣下錯引方針了,該章節位於「使用和處理編輯請求」章節底下,指明是管理員和模板編輯員在處理編輯請求的情況下才需要經過討論及七日公示。該模板僅為半保護防止破壞,而非模板保護。--LuciferianThomas留言 2021年2月2日 (二) 11:47 (UTC)回覆
@LuciferianThomas:首句「在受保護的頁面上編輯時,應當特別小心,並於共識和任何相關的指導方針相一致」,只要是受保護的頁面均受此限制。-- 2021年2月2日 (二) 11:54 (UTC)回覆
該章節也提到:「一些會輕微影響使用方式和外觀顯示的編輯,需在提交編輯請求後等待七天,無爭議方可進行修改」,您沒有提出編輯請求即自行變更,可視為繞過程序。-- 2021年2月2日 (二) 11:58 (UTC)回覆
自動確認使用者編輯非編輯爭議的半保護頁面也要提出編輯請求是什麼說法?那麼怎麼不直接模板保護?--LuciferianThomas留言 2021年2月2日 (二) 12:01 (UTC)回覆
@LuciferianThomas:依照您這個說法,難道模板編輯員和管理員對模板重大更新,都不用提交編輯請求?此外,半保護並不是只有防止破壞,其亦屬於高風險模板。-- 2021年2月2日 (二) 12:17 (UTC)回覆
已處理,見本人討論頁。--LuciferianThomas留言 2021年2月2日 (二) 12:45 (UTC)回覆
建立預設啟用/預設啟用的小工具來呈現偽命名空間介面
還有個小建議:當處於移動視圖時,不必在minerva外觀的頁面標題(腳本里的tips_selector)處添加提示,因為在觸控設備上沒辦法看到滑鼠懸停才有的提示,反而被加了下劃線,感覺不太美觀。--安憶Talk 2021年2月2日 (二) 16:31 (UTC)回覆
(:)回應@AnYiLinUser:A2569875/pseudonamespace_UI.js已修改。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月2日 (二) 19:48 (UTC)回覆
感覺用'ontouchstart' in document.documentElement來判斷更合適。--安憶Talk 2021年2月3日 (三) 08:59 (UTC)回覆
 完成AnYiLinSpecial:Diff/64090030,已加入代碼。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月3日 (三) 09:33 (UTC)回覆
(+)支持預設啟用小工具,在使用上與修改介面理應無異;亦方便維護,當通過新偽命名空間時可快速增添設定。--LuciferianThomas留言 2021年2月3日 (三) 08:47 (UTC)回覆
(~)補充:亦支持直接修改介面,這真的視乎最終選擇。--LuciferianThomas留言 2021年2月3日 (三) 08:53 (UTC)回覆
@LuciferianThomas:修改介面?那不就又回到獨立成新的命名空間了嗎?(技術問題還少些)-- Sunny00217  2021年2月4日 (四) 08:47 (UTC)回覆
…你是真的沒有跟上整個討論對吧…所謂「修改介面」是修改顯示介面,僅表示顯示介面時捷徑頁不是直接顯示頁面為「條目」而已,實際上不影響任何其他方面。--LuciferianThomas留言 2021年2月4日 (四) 08:52 (UTC)回覆
小工具執行結果
以頁面[[MOS:MOS]]為例
   
設定為繁體中文(以zh-tw為例) 設定為簡體中文(以zh-cn為例)
提供目前版本小工具運行結果圖,供公示參考用。右上角的連結為Wikipedia:偽命名空間用於說明,如有缺漏歡迎改善。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月3日 (三) 19:03 (UTC)回覆
@A2569875:等等等一下,這版在像是Mos:$1沒有大寫的也會執行耶,,,-- Sunny00217  2021年2月4日 (四) 08:45 (UTC)回覆
(※)注意:為免混淆WP:偽命名空間原有內容移動至WP:PNS+,並改為指向WP:捷徑#偽命名空間使其等價WP:偽命名空間的重新導向。--LuciferianThomas留言 2021年2月5日 (五) 06:21 (UTC)回覆
  •   公示7日:現交付公示,公示詳細資訊如下:
小工具原始碼
User:A2569875/pseudonamespace_UI.jsWP:CSD#O1)→MediaWiki:Gadget-pseudonamespace-UI.js
(公示完畢後會使用「移動不留重新導向」功能移動到MediaWiki:Gadget-空間)
小工具執行結果
以頁面[[MOS:MOS]]為例
   
設定為繁體中文 設定為簡體中文
如期內無合理異議則全站套用此修改。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月8日 (一) 05:56 (UTC)回覆
公示通過了,@A2569875AnYiLin。--LuciferianThomas留言 2021年2月15日 (一) 06:49 (UTC)回覆
@LuciferianThomas:被User:Jon_(WMF)刪掉了Special:Diff/64319519....說甚麼有東西undefined,看半天沒看出原因,至少我這邊所有裝置測試都沒出問題。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月16日 (二) 06:40 (UTC)回覆
看起來是startsWith()問題,部分瀏覽器不支援。--LuciferianThomas留言 2021年2月16日 (二) 09:10 (UTC)回覆
安億君幫您為不支援的平台補了function的定義了。--LuciferianThomas留言 2021年2月16日 (二) 09:12 (UTC)回覆

 完成:已通過並佈署。-- 五歲抬☎️·☘️2021年3月24日 (三) 05:50 (UTC)回覆

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

提議設立快速刪除標準 O8

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

現行條文

(無)

提議條文

O8. 在偽命名空間中建立的非重新導向頁面。

偽命名空間僅能用於重新導向。如可以移動到合適的名稱,請將頁面移動到合適的名稱,否則請使用此款快速刪除。若頁面明顯是一個條目,則不適用此款快速刪除。
  • 使用模板{{d|O8}}。

根據上述討論,偽命名空間應僅能是重新導向頁。位於偽命名空間中的非重新導向頁應可被快速刪除。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月1日 (一) 09:53 (UTC)回覆

(+)支持,若有條目真的需要以偽命名空間佔用條目前綴,使用全形冒號而非半形冒號以辨別即可,此可避免之前有使用者擔憂會佔用主空間條目名的情況。另外,我本來是在想可以把這條同時套用於不當使用偽命名空間重新導向至其他頁面,但想起有個別屬於格式手冊的論述其實不在Wikipedia:格式手冊/前綴(WP:SAL),所以暫時作罷。--LuciferianThomas留言 2021年2月1日 (一) 11:12 (UTC)回覆
@LuciferianThomas:使用全形冒號,極有可能違反命名常規。-- 2021年2月2日 (二) 05:46 (UTC)回覆
未見命名常規有不能用全形冒號的規則。若以與事物本身名稱不同說違反常規,可按照其他命名技術限制做法,不加冒號或改用全形冒號,並以{{Wrongtitle}}標記即可。--LuciferianThomas留言 2021年2月2日 (二) 05:52 (UTC)回覆
@LuciferianThomas:名從主人,這就是有使用者擔憂會佔用主空間條目名的情況,也有像en:Gadget:Invention, Travel, & Adventure類似的情況。-- 2021年2月2日 (二) 06:04 (UTC)回覆
可直接按照該情況處理,若通過則當作技術限制即可。用{{DISPLAYTITLE}}修正亦可。--LuciferianThomas留言 2021年2月2日 (二) 06:21 (UTC)回覆
這理論上可以出現在任何命名空間的情況,故按照命名空間一般處理方式即可。--LuciferianThomas留言 2021年2月2日 (二) 06:24 (UTC)回覆
很抱歉,{{DISPLAYTITLE}}需使用全名,少一個冒號就不會變更顯示。-- 2021年2月2日 (二) 06:33 (UTC)回覆
(+)支持。--忒有錢🌊塩水あります🐳留言2021年2月1日 (一) 15:20 (UTC)回覆
為何不是移動到合適的名稱?例如在LTA:誤建LTA頁面應該移動到WP空間後,讓原先頁面成為重新導向之類的。--Xiplus#Talk 2021年2月2日 (二) 05:53 (UTC)回覆
若果明顯屬於錯誤建立有關專題頁面的當然可以移動,這裡應該是指建立與該專題無關的頁面。--LuciferianThomas留言 2021年2月2日 (二) 06:01 (UTC)回覆
那就要寫清楚,避免被提快速刪除後,管理員未注意直接刪除。-- 2021年2月2日 (二) 06:07 (UTC)回覆
(!)意見:偽命名空間的設立理應是用作指向比較複雜的Wikipedia命名空間項目,不應用以指向其他無關條目,或許可以增加刪除「非指向維基百科命名空間的重新導向」條款?理論上偽命名空間屬於WP空間的延伸,不應該出現指向WP以外的偽命名空間,其他命名空間有自己的命名空間別稱,不會使用偽命名空間捷徑。未來倘若通過將部分項目升格命名空間,但該項目本身有偽命名空間捷徑,該等捷徑理應全數自動納入新命名空間而不會保留於主命名空間,不會影響此規則。--LuciferianThomas留言 2021年2月2日 (二) 06:12 (UTC)回覆
呃忘了有幾條MOS在PJ空間。--LuciferianThomas留言 2021年2月3日 (三) 08:48 (UTC)回覆
還有這種事?!-- Sunny00217  2021年2月3日 (三) 09:18 (UTC)回覆
有啊,專題的條目指引有幾條跟隨專題搬過去了。列表有寫。也有疑似專題移了但分頁未移的餘孽,但遲早都要搬過去吧。--LuciferianThomas留言 2021年2月3日 (三) 11:10 (UTC)回覆
§ 第二階段:轉移至新命名空間在討論這類MOS的更名,很快就能解決。——BlackShadowG留言維基百科20歲生日快樂! 2021年2月4日 (四) 11:18 (UTC)回覆
加了附加條件之後讓我覺得這個準則永遠不會被使用,無論是什麼內容都應該根據內容來移動到新名稱,若是破壞也可用現存的G3等刪除。--Xiplus#Talk 2021年2月3日 (三) 13:59 (UTC)回覆
至少這也能成為移動操作的依據。快速刪除方針的應用有時並不限於快速刪除本身。SANMOSA SPQR 2021年2月17日 (三) 15:06 (UTC)回覆
Module:Template:Delete/data模組的對應修改見User:Sanmosa/O8模組SANMOSA Σουέζ 2021年4月17日 (六) 04:32 (UTC)回覆

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

將LTA空間設定為noindex

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

認為LTA空間應設定為noindex 避免搜尋引擎索引。 具體的作法可建立專用於標記偽命名空間的模板,在模板內用{{Namespace_detect}}判斷是否為LTA空間,加入noindex 魔術字。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月3日 (三) 13:43 (UTC)回覆

條目空間中無法使用noindex魔術字。--Xiplus#Talk 2021年2月3日 (三) 13:54 (UTC)回覆
@Xiplus:意思說部分維護模板的設定是設定辛酸的?!-- Sunny00217  2021年2月3日 (三) 14:54 (UTC)回覆
@羊羊32521YFdyh000:看來LTA還是需要升格為獨立的命名空間,才不會被其他命名空間的設定檔左右。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月3日 (三) 18:57 (UTC)回覆
開新討論吧。--LuciferianThomas留言 2021年2月3日 (三) 22:29 (UTC)回覆
連過去的是WP,可以將該頁NOINDEX吧,那麼相關捷徑就會有同樣效果?--臺灣杉在此發言 (會客室) 2021年2月4日 (四) 08:39 (UTC)回覆
其實Google搜尋似乎沒看到這些頁面,或許重新導向本來就被忽略?--LuciferianThomas留言 2021年2月5日 (五) 01:52 (UTC)回覆
Bing找得到但直接顯示目標頁面內容。--LuciferianThomas留言 2021年2月5日 (五) 01:55 (UTC)回覆
所以還需要noindex嗎 ——羊羊 (留言|貢獻|維貓報|古典音樂專題) 2021年2月18日 (四) 03:02 (UTC)回覆
需要是獨立的命名空間才能設定noindex—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月18日 (四) 10:12 (UTC)回覆
@羊羊32521:我認為如果可以設定的話會更佳,但可能命名空間化會比較方便。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年3月3日 (三) 05:20 (UTC)回覆
那我周末再提一下 ——羊羊 (留言|貢獻|維貓報|古典音樂專題) 2021年3月3日 (三) 15:00 (UTC)回覆
(?)疑問改這個是否可行?--安憶Talk 2021年3月3日 (三) 15:13 (UTC)回覆
仍支持命名空間案,我只是覺得提升命名空間案一直被人以奇怪的理由關掉很可惜。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年3月3日 (三) 15:21 (UTC)回覆
那就搬新段重開吧,抱歉太亂了。--LuciferianThomas留言 2021年3月6日 (六) 06:51 (UTC)回覆
也沒有亂吧,個段落應該分開檢視吧,怎麼會不能放在兩個結束之議案的中間呢?-- 五歲抬☎️·☘️2021年3月10日 (三) 06:00 (UTC)回覆
從語法看可以。--YFdyh000留言2021年3月3日 (三) 15:22 (UTC)回覆
以往phab有修改此部分的先例嗎?-- 五歲抬☎️·☘️2021年3月17日 (三) 06:42 (UTC)回覆
如果沒有的話,我認為很難實行。-- 五歲抬☎️·☘️2021年3月31日 (三) 06:51 (UTC)回覆
實測上Google應沒有對重新導向進行索引(例如搜尋"LTA:蘇俞安"找不到該重新導向或是目標頁面),所以我們應沒必要再對其標記NOINDEX。--Xiplus#Talk 2021年3月31日 (三) 08:55 (UTC)回覆
Google搜尋重新導向時會顯示目標頁的內容,即會有一行「(重新導向自)」,請見[4],但是不影響偽命名空間。-- 2021年4月5日 (一) 07:29 (UTC)回覆
google:detache出現了一個到https://en.wikipedia.org/?title=Detach%C3%A9&redirect=no的搜尋結果。 ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年4月11日 (日) 14:31 (UTC)回覆
這個不像是主動收錄的網址,而且有設定canonical,理應不會收錄這個重新導向。--Xiplus#Talk 2021年4月14日 (三) 05:32 (UTC)回覆
本提案已經另開。-- 五歲抬☎️·☘️2021年4月28日 (三) 04:17 (UTC)回覆

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

有關新增偽命名空間的提議

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

現時MOS和LTA均為偽命名空間,其中MOS專門指向站內各已正式通過和未正式通過的格式手冊。我有一個想法是能不能為命名常規和關注度指引也設立專門的捷徑偽命名空間?SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 09:02 (UTC)回覆

@A2569875Taiwania JustoYining Chen羊羊32521YFdyh000@LuciferianThomasEricliu1912MilkyDeferSuper WangSunny00217SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 09:08 (UTC)回覆
(+)支持。偽命名空間運行暢順,可選擇有需要的專案空間內容增設偽命名空間。(&)建議命名常規使用「NC」字首、關注度使用「N」字首。另(&)建議增設共識(討論)捷徑「CON」,連結至各討論存檔(Talk、WT、PJT)或資訊頁(WP),如CON:COVID19指向COVID-19條目共識。--LuciferianThomas留言 2021年3月24日 (三) 09:32 (UTC)回覆
NC和N可行。CON可行,但建議另外討論,因為CON可以重新導向到的目標有太多類頁面。SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 10:00 (UTC)回覆
支持N和NC,對CON保留意見 ——羊羊 (留言|貢獻|維貓報|古典音樂專題) 2021年3月25日 (四) 06:07 (UTC)回覆
N的話會不會短了點?之前MOS和LTA的時候因為是三個字母,跟正式條目命名撞車的可能性小所以沒有問題。這一個N我個人有點拿不準。此外我覺得CON可能還不是時候。在我的認知中,單獨討論出共識單獨成頁的也就只有COVID-19這一個了,至少應當等類似的頁面數量足夠多了再提出會比較好。如果有我不知道的類似頁面儘管告訴我。 --Milky·Defer 2021年3月25日 (四) 07:36 (UTC)回覆
檢查過,現時沒有條目空間的頁面是「N:」開首的。如果真的不放心的話,NT和NOTE也可以(但不能NOT)。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 07:44 (UTC)回覆
@sanmosa: 維基新聞的前綴就是「n:」,煩請查詢Special:跨wiki。--痛心疾首 2021年4月2日 (五) 15:43 (UTC)回覆
啊,忘了。SANMOSA Σουέζ 2021年4月3日 (六) 00:12 (UTC)回覆
先跑題:MOS基本沒用過,看到時我習慣改用WP前綴。LTA用過但沒有獨立空間所以搜尋很不方便,期望未來設獨立空間、增設訪問限制。然後:我不清楚相關頁面有多少,如果很少,可能用的人也不會很多?以及持久性不會好(幾年後失效)。N有點短,NOTE我想到[{tl|TA}}和備註,命名常規為什麼不是NAME:(但未來會不會衝突?)。關注度沒想法,考慮到「關注度」定名本身都有質疑,我暫時想不到很好的。NT在中國大陸網絡有貶義「腦癱」,不贊成。--YFdyh000留言2021年3月25日 (四) 12:14 (UTC)回覆
@YFdyh000:「NAME:」應該不會衝突吧,也不不失是一個好提議。「NT:」你當我真的NT了吧(在香港「NT」指新界,不過以地名開首還是有些怪)。「NOTA:」不知如何,有種葡文風,但字源仍是「Notability」,衝突的機會也低。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 13:01 (UTC)回覆
(-)反對,如果將編輯社群頁面等因為與Wikipedia命名空間關聯性不強而劃分出的話,方針等與專案運營有關的的頁面不應該劃出Wikipedia空間,而且本身這部分已經能通過消歧義的方式處理,沒壞別瞎修。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年3月26日 (五) 00:54 (UTC)回覆
@cwek:偽命名空間僅用於設定重新導向頁面(這是指引指明的),完全沒有你所說的「(將導向目標)劃出Wikipedia空間」那回事。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 01:00 (UTC)回覆
偽命名空間作用並非直接劃出內容,而是作捷徑之用:#偽命名空間WP:PNSWP:PNS+。因為似乎對於提案內容有所誤解,反對的事也並非現在實際正在討論之議案,故難以算作有效反對意見。--LuciferianThomas留言 2021年3月28日 (日) 06:23 (UTC)回覆

初步定案

編輯

建議為命名常規和關注度指引設立專門的捷徑偽命名空間,其中命名常規的專門捷徑偽命名空間為「NC:」,而關注度指引的專門捷徑偽命名空間則為「NT:」。SANMOSA Σουέζ 2021年4月14日 (三) 13:24 (UTC)回覆

(打撈)--LuciferianThomas留言 2021年4月23日 (五) 01:31 (UTC)回覆
@LuciferianThomas:請記得也把存檔頁的內容刪除,以免之後存檔有重複內容。--Xiplus#Talk 2021年4月23日 (五) 01:40 (UTC)回覆
好滴--LuciferianThomas留言 2021年4月23日 (五) 01:58 (UTC)回覆
Sanmosa由於超過七日無新意見,  公示7日,2021年4月30日 (五) 01:33 (UTC) 結束。--LuciferianThomas留言 2021年4月23日 (五) 01:33 (UTC)回覆
若有條目也叫NC,會不會對沖呢? 2021年4月27日 (二) 09:07 (UTC)回覆
NC不是命名空間,NC加冒號「NC:」才是命名空間。-- 五歲抬☎️·☘️2021年4月28日 (三) 04:14 (UTC)回覆

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

後續處理

編輯
@AnYiLin:能處理一下剩餘的ER嗎,還有幾個尚未完成:

以上。--LuciferianThomas留言 2021年5月12日 (三) 00:24 (UTC)回覆

抱歉,編輯:僅允許管理員。--安憶Talk 2021年5月12日 (三) 04:29 (UTC)回覆
@XiplusSANMOSA Σουέζ 2021年5月12日 (三) 06:28 (UTC)回覆
@Tigerzeng:能協助處理嗎?--路西法人留言 2021年5月18日 (二) 11:47 (UTC)回覆

偽命名空間(階段三:設立後續)

編輯


[編輯此導航模板]

本案討論格式手冊及長期破壞者提升問題。目前有三案:

  • 格式手冊及長期破壞者提升為命名空間,英語名稱待定;
  • 格式手冊及長期破壞者成為偽命名空間,縮寫為MOS及LTA;
  • 維持現行方式。

請討論。臺灣杉在此發言 (會客室) 2020年12月25日 (五) 01:23 (UTC)回覆

進一步討論

編輯

MOS捷徑名稱

編輯

LTA空間的捷徑大部分都可以快速移動,但格式手冊的捷徑很多不同格式,在此希望各位一同組成完整的新捷徑列表。--LuciferianThomas留言 2021年1月31日 (日) 03:11 (UTC)回覆

WP:NS2021/MOSSC,已列出部分格式手冊可用捷徑,請檢查,並協助補充。--LuciferianThomas留言 2021年2月1日 (一) 08:48 (UTC)回覆
已完成,請協助檢查。--LuciferianThomas留言 2021年2月3日 (三) 04:35 (UTC)回覆
(?)疑問@LuciferianThomas:這些頁面大部分都還是紅色連結,是需要建立的意思嗎?-- 五歲抬☎️·☘️2021年5月20日 (四) 13:38 (UTC)回覆
確實需要建立,暫時還沒有動力去處理XD--路西法人留言 2021年5月20日 (四) 13:40 (UTC)回覆
(?)疑問@LuciferianThomas:你近期有要處理嗎?這個討論快要被存檔囉。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2021年6月5日 (六) 09:03 (UTC)回覆

自動半保護偽命名空間

編輯

我很難說有多少人會去破壞MOS捷徑,但倒是LTA捷徑有可能會被破壞。建議可自動半保護(建立、編輯、移動)主命名空間「MOS:」、「LTA:」字首的條目空間。--LuciferianThomas留言 2021年1月31日 (日) 08:28 (UTC)回覆

不應做出預見性保護。--Xiplus#Talk 2021年2月2日 (二) 10:26 (UTC)回覆
若捷徑指向的條目因為破壞被保護,有需要跟隨進行保護嗎?--LuciferianThomas留言 2021年2月2日 (二) 12:06 (UTC)回覆
不需要吧,有這樣的案例嗎?--Xiplus#Talk 2021年2月2日 (二) 12:30 (UTC)回覆
案例我不清楚,但我倒是覺得需要,尤其本來有某些LTA有破壞自己LTA頁的傾向,可算是高風險。--LuciferianThomas留言 2021年2月2日 (二) 12:59 (UTC)回覆
有破壞事實就能保護,不需預先保護。--Xiplus#Talk 2021年2月2日 (二) 13:04 (UTC)回覆
建議用濫用過濾器阻止非自動確認使用者編輯,配以相關警告。--YFdyh000留言2021年2月2日 (二) 13:07 (UTC)回覆
同Xiplus,不認為有必要預先保護。這類捷徑與MediaWiki空間不同,被破壞並沒有很大的影響,及時回退即可。過濾器標記沒意見,反對阻止。--Tiger留言2021年5月20日 (四) 07:13 (UTC)回覆
(:)回應:@Tigerzeng:請看清楚公示內容與以公告張貼內容「設立濫用過濾器標記偽命名空間的編輯動作」我哪時提到了「預先保護」??頂多就只是加上YFdyh000提到的配以相關警告。--。-- 五歲抬☎️·☘️2021年5月20日 (四) 07:21 (UTC)回覆
此小案沒有一個很明顯的初步共識,公示的內容也是您一人提議,無其他人附和。從前至後跨越時間也非常長,其他人很可能仍持有自己的意見而未及回應。在此情況下,我認為有需要對此章節出現過的意見進行評論,如果上面說得不夠清楚,下面我再重新表明:1.反對保護(LuciferianThomas提議)2.反對過濾器阻止(YFdyh000 提議)3.對過濾器標記無意見(A2569875 提議)。--Tiger留言2021年5月20日 (四) 07:31 (UTC)回覆
有鑑於本次公示過於倉促,因此暫緩公示。-- 五歲抬☎️·☘️2021年5月20日 (四) 07:41 (UTC)回覆
由於各方意見交集不夠明顯,因此重Ping參與命名空間案之討論的使用者,以便凝聚共識:@Sanmosa羊羊32521LuciferianThomasYFdyh000XiplusTigerzeng:。-- 五歲抬☎️·☘️2021年5月20日 (四) 07:45 (UTC)回覆
1. 根據保護方針禁止預見性保護規定,反對保護。 2. 因完全可用標題黑名單進行保護,故反對以過濾器阻止方式進行保護。--Xiplus#Talk 2021年5月20日 (四) 07:54 (UTC)回覆
@Xiplus:見上「設立濫用過濾器標記偽命名空間的編輯動作(我的提議),並配以相關警告(YFdyh000提議的一部份)」-- 五歲抬☎️·☘️2021年5月20日 (四) 08:01 (UTC)回覆
警告內容為何?--Xiplus#Talk 2021年5月20日 (四) 08:12 (UTC)回覆
如果沒人想寫,用通用的「破壞」警告或許也行。如果多名維基人認為這是預見性保護、有礙貢獻,用僅標記或者僅警告不阻止我也沒意見,後續再根據觸發記錄適當調整(不重新徵求共識,看誤觸率就可以)。因為標題黑名單靈活度較低,如果過濾器沒有明顯劣勢,我更傾向過濾器,可基於編輯次數、破壞趨勢等作調整,或者僅警告不阻止。--YFdyh000留言2021年5月20日 (四) 10:19 (UTC)回覆
那麼可以等有破壞再來討論應如何應對破壞。--Xiplus#Talk 2021年5月20日 (四) 10:46 (UTC)回覆
如果擔心不能及時發現破壞,用一個無動作的過濾器監視相關編輯應該可行。這樣檢查過濾器日誌就可以集中檢視偽命名空間上的編輯,再根據其中破壞性編輯的狀況來應對。--Tiger留言2021年5月21日 (五) 01:30 (UTC)回覆
使用這種方式上有篩選、標記使用者狀態、顯示標籤等更多功能,又不用浪費執行緩慢的過濾器,只需要開個機器人定時更新即可。--Xiplus#Talk 2021年5月21日 (五) 02:05 (UTC)回覆
@XiplusWikipedia:重新導向#重新導向保護:「沒有理由對該重新導向進行編輯」是對重新導向予以長期保護的理由。SANMOSA Σουέζ 2021年5月21日 (五) 09:48 (UTC)回覆
@Sanmosa:該段為指引,若跟保護方針的不應做出預見性保護牴觸時,應以方針為準,故不應保護。--Xiplus#Talk 2021年5月21日 (五) 10:07 (UTC)回覆
@Xiplus:那我理論上可以把那個章節單獨升為方針,或者直接在保護方針説明Wikipedia:重新導向#重新導向保護指明的情況例外也可。當然,另一個辦法是到了LTA空間的任何一個重新導向被破壞了,整個LTA空間(連坐)保護,我覺得這不算是「預見性保護」了,那就不用動到方針指引。SANMOSA Σουέζ 2021年5月21日 (五) 10:12 (UTC)回覆
@Sanmosa:當然可以,但我還是問豁免預見性保護的理由是啥。被破壞當然能保護,這是現有保護方針就能處理的,而我也在2月的留言就已指出,根本沒必要在此討論要不要保護。--Xiplus#Talk 2021年5月21日 (五) 10:16 (UTC)回覆
@Xiplus:(前)我只是提出一個可能性而已,社群成員如果真的要這樣正式作提議的話,他們自然有他們的理由。(後)那就有勞密切關注破壞情況了。SANMOSA Σουέζ 2021年5月21日 (五) 10:22 (UTC)回覆
(?)疑問所以目前此案要採取什麼方案呢?-- 五歲抬☎️·☘️2021年5月28日 (五) 15:04 (UTC)回覆
僅監視的方案就可以了,具體做法就可以很靈活了,用Xiplus說的鏈出變更也可以。其實如果能自行編程,也可以自行追蹤相關編輯,亦可將追蹤結果存入自己的使用者頁面,以便其他使用者檢視(而無需申請機器人,頻率不太高的話)。--Tiger留言2021年5月29日 (六) 02:26 (UTC)回覆

已結案的議題

編輯
已結案:
將已結案的討論分出來存檔。-- 五歲抬☎️·☘️2021年5月6日 (四) 04:06 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

自動提刪R2
軟重新導向
技術問題處理
提議設立快速刪除標準 O8
將LTA空間設定為noindex
再次推動破壞者(LTA)成為命名空間

以上討論大部分已通過,故標記已結案。-- 五歲抬☎️·☘️2021年5月6日 (四) 04:06 (UTC)回覆


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
※註:上面有幾個子議題正在準備公示。-- 五歲抬☎️·☘️2021年5月6日 (四) 03:57 (UTC)回覆

WP:捷徑指引草案修訂

編輯


[編輯此導航模板]

說明

編輯

捷徑指引草案的討論,源自於「偽命名空間」的討論,英語維基百科對於捷徑相關的規範及偽命名空間的設立已有成熟的執行方式。中文維基百科中的部分編輯者對於「格式手冊」、「長期破壞者」及「專題」這三個主題提出可升級成命名空間或以偽命名空間形式存在,並有正反兩方的陳述與看法。

目前較為接近共識的是「專題」提升為正式命名空間,反對者的論述已由支持者回應,且反方無進一步論述。然為求慎重,且將捷徑與命名空間等議題作系統性討論,將會執行階段修訂,以取得最大共識。

本討論的各階段分為:

  1. 專題提升為命名空間與否及其細節phab:T271612);
  2. 格式手冊及長期破壞者是否成為命名空間或偽命名空間
  3. 偽命名空間規範寫入捷徑規範內(如前項通過)或是否允許偽命名空間(如前項不通過)
  4. 捷徑規範細部討論並決定是否成為指引。

各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)回覆

專題命名空間通過,剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (UTC)回覆
偽命名空間和專題空間都設立了。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年3月3日 (三) 05:21 (UTC)回覆

專題命名空間問題

編輯

格式手冊及長期破壞者命名空間問題

編輯
已通過:
已通過,並完成主要設定。-- 五歲抬☎️·☘️2021年3月24日 (三) 05:55 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

已移動至偽命名空間臺灣杉在此發言 (會客室) 2021年2月1日 (一) 03:47 (UTC)回覆


 完成:設定完畢,有問題請在此提出。-- 五歲抬☎️·☘️2021年3月24日 (三) 05:55 (UTC)回覆

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

機器人亂存檔問題

編輯

捷徑細部修訂

編輯

本案進入倒數第二個部分,捷徑細節修訂。目前偽命名空間部分已成為指引,其餘部分仍須修訂。

在上次討論當中,有提及中文捷徑等相關問題,歡迎進一步討論。臺灣杉在此發言 (會客室) 2021年1月31日 (日) 07:42 (UTC)回覆

首段建議附加維基專題空間,他們會稍後設立捷徑。--LuciferianThomas留言 2021年2月6日 (六) 04:03 (UTC)回覆
(:)回應Wikipedia:互助客棧/方針#第五階段:討論重新導向與捷徑的設立方式討論已開始。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月14日 (日) 09:51 (UTC)回覆
@Taiwania Justo?--LuciferianThomas留言 2021年2月21日 (日) 00:13 (UTC)回覆
目前在忙著RFC以及其他現實生活事務,且目前還有殘餘議案等待處理,待完全告一段落後再行整理該案。--臺灣杉在此發言 (會客室) 2021年2月21日 (日) 03:46 (UTC)回覆
不急,因為#第五階段:討論重新導向與捷徑的設立方式也還在討論。-- 五歲抬☎️·☘️2021年3月17日 (三) 06:43 (UTC)回覆
上述第五階段將會在適當的時機公示。-- 五歲抬☎️·☘️2021年3月31日 (三) 06:50 (UTC)回覆
上述第五階段曾於2021年4月14日 (三) 03:45 (UTC) 進入公示階段。-- 五歲抬☎️·☘️2021年5月4日 (二) 06:46 (UTC)回覆
  說明由於目前有些其他意見,第五階段公示暫停。-- 五歲抬☎️·☘️2021年5月13日 (四) 04:33 (UTC)回覆
上方第五階段已恢復公示-- 五歲抬☎️·☘️2021年5月20日 (四) 06:22 (UTC)回覆
上方第五階段已公示通過-- 五歲抬☎️·☘️2021年5月27日 (四) 09:36 (UTC)回覆
  說明上方第五階段已進行到技術階段Wikipedia:機器使用者/申請#User:LuciferianBot,偽命名空間亦同(半保護案視為無共識或否決),因此方針修訂的部分皆已完成。本討論可繼續進行了。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2021年6月10日 (四) 11:43 (UTC)回覆
(?)疑問@Taiwania Justo:上述殘餘議案之處理已接近尾聲,請問閣下近期有空整理此案嗎?-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2021年6月2日 (三) 14:51 (UTC)回覆
正在整理中。--臺灣杉在此發言 (會客室) 2021年6月4日 (五) 04:37 (UTC)回覆

捷徑指引修正

編輯

依據前次討論所收集的意見,已在「捷徑的命名」段修改成可在字尾使用中文簡寫。然而其中文字上限多少字仍沒有規定,請討論。臺灣杉在此發言 (會客室) 2021年6月25日 (五) 05:23 (UTC)回覆

以上。 ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年6月30日 (三) 05:51 (UTC)回覆
(+)不反對,所以WP:貴賓室WP:VIP)可以咯  --路西法人留言 2021年7月7日 (三) 13:59 (UTC)回覆
這兩種都可以,不過我認為字數硬上限還是要存在,主要理由就是捷徑太多字是否還能稱作捷徑?不無疑問。--臺灣杉在此發言 (會客室) 2021年7月9日 (五) 11:43 (UTC)回覆
@Taiwania Justo:如果定死字數硬上限可能會被指責是「拍腦袋想出來的」  囧rz……-- ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年7月25日 (日) 14:43 (UTC)回覆
那首先現存最長的捷徑有多少個字?(中文、英文、中英混雜分開處理)然後我們再根據現時的情況立標準就好。順帶一提:我請求把WP:貴賓室恢復了[錨點失效],但還是想請各位到那邊發表一下意見。SANMOSA Σουέζ 2021年8月3日 (二) 07:26 (UTC)回覆
英文倒還好,本來英文的捷徑都是字首縮寫,敲幾個英文字母就可以。中文比較麻煩。--臺灣杉在此發言 (會客室) 2021年8月15日 (日) 11:10 (UTC)回覆
個人認為不需要有硬性限制,以常識判斷是否有作為捷徑的價值即可。—— Eric Liu 創造は生命(留言留名學生會 2021年8月15日 (日) 14:00 (UTC)回覆
「捷徑儘量不能有成為新的專案頁的潛力」其實也沒差吧,任何維基人都可以把重新導向頁改為獨立頁面。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2021年7月16日 (五) 15:18 (UTC)回覆
但是這樣還要改連入-- ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年7月20日 (二) 07:49 (UTC)回覆
(+)支持-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2021年8月2日 (一) 15:25 (UTC)回覆
加個「建議加入{{Shortcut description}}({{Shcd}})以解釋英文捷徑的意義(尤其為縮寫的就更需要)。--路西法人留言 2021年8月4日 (三) 03:03 (UTC)回覆
機器人再等一下! 快討論好了!!-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2021年9月2日 (四) 16:35 (UTC)回覆

依照先前討論,將不會強制規定捷徑字數上限,並依照本段討論進行修正。臺灣杉在此發言 (會客室) 2021年8月25日 (三) 13:56 (UTC)回覆

專題命名空間(第五至六階段)

編輯


[編輯此導航模板]

導航模板請參閱此。導言請參閱此

第五階段:討論重新導向與捷徑的設立方式

編輯

各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年1月29日 (五) 12:57 (UTC)回覆

本案進入倒數第二個部分。現在將討論未來專題捷徑如何設立,以及原有捷徑的去留:
  • 未來是否允許建立跨WP與PJ空間的捷徑?如果需要,是否需要進一步規範?
  • 未來是否允許建立跨WP與PJ空間的非捷徑的重新導向?
  • 舊有的跨WP與PJ空間的捷徑是否需要清除連入然後(×)刪除
cc.@30000lightyearsTaiwania JustoLuciferianThomas羊羊32521BlackShadowG
請討論-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月14日 (日) 09:41 (UTC)回覆
  • 我認為PJ空間的捷徑統一規範為WPJ/PJ:XXX,將現有WP重新導向全部轉到PJ去。比如WikiProject:智慧型手機WP:SMARTPHONE直接轉移到WPJ:SMARTPHONE。--LightyearsTalk·Sign#訂閱維貓報喵! 2021年2月14日 (日) 11:15 (UTC)回覆
  • 個人意見
    1. 為了避免混淆,將來應該一律禁止建立跨WP與PJ空間的捷徑重新導向。
    2. 目前存在的WP重新導向到PJ的捷徑應該全部轉移到PJ,若無連入或很少連入,可考慮(×)刪除;若數量過大,或者已經在討論中被引用,則可考慮(○)保留以僅供歷史參考。
    3. 同時,將PJ命名空間中所有{{shortcut}}中的捷徑一律改為以「PJ」開頭的捷徑,不再推薦使用以WP開頭的捷徑。

——BlackShadowG留言維基百科20歲生日快樂! 2021年2月14日 (日) 12:57 (UTC)回覆

同上,不然就沒必要偽命名空間了。 2021年2月14日 (日) 13:49 (UTC)回覆
我覺得從PJ空間捷徑連出沒什麼問題,WP空間也有捷徑連至Help。PJ分拆了就不要再從WP連過去了,舊的就隨它吧。--LuciferianThomas留言 2021年2月14日 (日) 14:09 (UTC)回覆
舊的捷徑如要批量刪除的話可能要請求管理員開刪除機器人...-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月14日 (日) 14:11 (UTC)回覆
所以把PJ空間的{{shortcut}}全部更新,提醒將來的編者不要再用WP連結到PJ的捷徑就行了。那些沒有連入的WP捷徑刪了也無妨。——BlackShadowG留言維基百科20歲生日快樂! 2021年2月16日 (二) 02:05 (UTC)回覆
個人意見:
  1. 原則上不允許,但社羣就個別頁面的特殊情形可以例外授權。建議以修改R2規範處理。
  2. 不允許。如出現,應清除連入並刪除。
  3. 可行。清除連入可以請求bot(WP→PJ),刪除的話我覺得開一個list,然後轉AFD即可。
以上。SANMOSA SPQR 2021年2月17日 (三) 14:40 (UTC)回覆
既然(我認為)未來不允許建立跨WP與PJ空間的非捷徑重新導向,而且非條目命名空間的非捷徑重新導向本來就使用率低下,如果真的有人意外建立了,都不會有多少連入,清除連入也不是甚麽困難的事,而且還能避免未來的誤用。SANMOSA Σουέζ 2021年3月31日 (三) 07:43 (UTC)回覆
Wikipedia:專題Wikipedia:專題委員會等部分頁面為何還沒有移動到新的命名空間?還是這些頁面不應該移動?--百無一用是書生 () 2021年2月19日 (五) 02:46 (UTC)回覆
先前討論有提到將專題介紹留在WP空間。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月19日 (五) 17:12 (UTC)回覆
專題委員會並非專題介紹,Wikipedia:專題似乎也稱不上是介紹,更像是WikiProject:首頁的作用--百無一用是書生 () 2021年3月1日 (一) 02:54 (UTC)回覆
個人認為跨WP->PJ沒差,但PJ->WP的不行-- Sunny00217  2021年2月21日 (日) 13:56 (UTC)回覆

第五階段:小結

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

總結以上討論意見:

  1. 禁止建立跨WP與PJ空間的捷徑重新導向。並清理連結至此的頁面後刪除現有跨WP與PJ空間的捷徑重新導向;同時,將PJ命名空間中所有{{shortcut}}中的捷徑一律改為以「PJ」開頭的捷徑,不再推薦使用以WP開頭的捷徑。→修改R2規範
  2. Wikipedia:專題Wikipedia:專題委員會移動到PJ空間。→需探討是否留重新導向
以上-- 五歲抬☎️·☘️2021年4月7日 (三) 06:22 (UTC)回覆
補:R2修改內容:
現行條文

R2. 跨命名空間重新導向

由條目的命名空間重新導向至非條目命名空間,將使用者頁面移出條目命名空間時遺留的重新導向,或者從草稿命名空間指向非草稿命名空間的重新導向。經社群同意設立的偽命名空間屬於本規則之例外。注意:有時新加入的維基人偶爾會在主條目空間誤建使用者頁面。使用「移動」頁面工具將使用者頁面移回使用者名稱字空間會保留頁面歷史,在刪除遺留的重新導向頁前,考慮保留一到兩天;草稿重新導向速刪前,請確保草稿已經完成其作用,並且草稿的歷史已經合適地移動到相應的正式頁面。
  • 使用模板{{d|R2}}或{{d|interwk}}。
提議條文

R2. 跨命名空間重新導向

包括以下幾種類型:
  1. 從條目命名空間指向非條目命名空間的重新導向(包括將使用者頁面從條目命名空間移動至使用者頁面命名空間時遺留的重新導向);
  2. 從草稿命名空間指向非草稿命名空間的重新導向;
  3. 從計畫命名空間(Wikipedia)指向維基專題命名空間(WikiProject)的重新導向;及
  4. 從維基專題命名空間(WikiProject)指向計畫命名空間(Wikipedia)的重新導向。
經社群同意設立的偽命名空間屬於本規則之例外。
注意:有時新加入的維基人偶爾會在主條目空間誤建使用者頁面。使用「移動」頁面工具將使用者頁面移回使用者名稱字空間會保留頁面歷史,在刪除遺留的重新導向頁前,考慮保留一到兩天;草稿重新導向速刪前,請確保草稿已經完成其作用,並且草稿的歷史已經合適地移動到相應的正式頁面。
  • 使用模板{{d|R2}}或{{d|interwk}}。

以上。SANMOSA Σουέζ 2021年4月17日 (六) 04:12 (UTC)回覆

Module:Template:Delete/data模組的對應修改見User:Sanmosa/R2模組SANMOSA Σουέζ 2021年4月17日 (六) 04:24 (UTC)回覆
現時有3502個WP->WPJ的重新導向,33個WPJ->WP的重新導向。--Xiplus#Talk 2021年4月17日 (六) 05:07 (UTC)回覆
上面的結論有指明「清理連結至此的頁面後刪除現有跨WP與PJ空間的捷徑重新導向」,所以應該需要bot,再不然發通知邀請社群協力清理也可。SANMOSA Σουέζ 2021年4月17日 (六) 11:00 (UTC)回覆
(!)意見:「2. 將使用者頁面移出條目命名空間時遺留的重新導向」真包含於「1. 由條目命名空間指向非條目命名空間的重新導向」,可以刪去。另外那個看起來怪怪的,建議刪去。 ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年4月20日 (二) 04:57 (UTC)回覆
@羊羊32521:(1)1是(條目命名空間)→(非條目命名空間),2是(非條目命名空間)→(條目命名空間),2不能刪。(2)完成。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)回覆
查CSD歷史,R2最初加入於Special:Diff/284065通過將使用者頁面移出條目命名空間而建立的重訂向。 (有時新的維基人偶爾會在主條目空間建立使用者頁面。使用「移動」頁面工具將使用者頁面移入使用者名稱字空間會保留頁面的歷史,考慮在刪除作為移動結果的重新導向頁面前,保留一到兩天。) 所以是說:①在主命名空間建立使用者頁面;②將該使用者頁面移動到使用者名稱字空間(留重新導向);③快速刪除重新導向頁面。故2亦是「(條目命名空間)→(非條目命名空間)」。 ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年4月21日 (三) 15:55 (UTC)回覆
閣下這一改意思都變了 ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年4月21日 (三) 15:59 (UTC)回覆
@Sanmosa-- ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年4月24日 (六) 14:39 (UTC)回覆
另外我認為WP→PJ可能不適合速刪,上方討論有提到
或者先開機器人把歷史遺留問題解決掉  ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年4月21日 (三) 16:08 (UTC)回覆
容許我再多等待三日,上面的提案會稍為調整。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)回覆
@羊羊32521:有道理。已再調整。7日後我再重行公示。SANMOSA Σουέζ 2021年4月25日 (日) 08:19 (UTC)回覆
針對「WP→PJ可能不適合速刪」一點,我也曾經表示需要bot處理,但我認為人手逐個處理亦非不可,情況如同enwiki曾經有過的X1,分別僅在於這變成永久措施,並禁止日後同類重新導向的建立。SANMOSA Σουέζ 2021年4月25日 (日) 08:25 (UTC)回覆
@Xiplus:請求WP->WPJ的重新導向及WPJ->WP的重新導向的具體清單。另見上。SANMOSA Σουέζ 2021年4月30日 (五) 06:00 (UTC)回覆
@Sanmosa列表於此,另您想讓我注意什麼?--Xiplus#Talk 2021年4月30日 (五) 06:10 (UTC)回覆
@Xiplus:關於我對速刪WP->WPJ的重新導向的意見。當然我仍然希望有bot能協助清理連入(初步構思:[[WP:AA]]→[[WPJ:BB|WP:AA]]、[[WP:AA|自定義文字]]→[[WPJ:BB|自定義文字]])。SANMOSA Σουέζ 2021年4月30日 (五) 06:15 (UTC)回覆
看起來無問題,不過我個人是覺得有大量連入的重新導向就不應刪除,這樣也不需要去修正。--Xiplus#Talk 2021年4月30日 (五) 11:43 (UTC)回覆
注意編輯摘要里也可能引用捷徑(雖然專題頁的引用量可能不會很大)。(▲)同上有大量連入的重新導向不應刪除-- ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年5月1日 (六) 05:49 (UTC)回覆
此類提案應該不太可能涉及「有大量連入的重新導向」,如有,請另表列出。SANMOSA Σουέζ 2021年5月1日 (六) 07:57 (UTC)回覆
應該是沒有-- ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年5月1日 (六) 09:19 (UTC)回覆
178萬6641個頁面需要更新,占全部頁面27%,我認為修復重新導向是不明智的。--Xiplus#Talk 2021年5月1日 (六) 10:01 (UTC)回覆
(:)回應有些是模板連入造成的,修改模板就可能可以大幅減少。—- 五歲抬☎️·☘️2021年5月1日 (六) 12:31 (UTC)回覆
我本來也是以為是模板連入造成,但再次檢查後,其實不然,可靠地估計需編輯的頁面至少在156萬以上。--Xiplus#Talk 2021年5月1日 (六) 12:44 (UTC)回覆
@Xiplus:我要求就每個捷徑分別排查連入數,並分別區分模板連入和非模板連入。我不相信大部分此類捷徑都能產生逾100萬的連入。SANMOSA Σουέζ 2021年5月4日 (二) 05:36 (UTC)回覆
沒辦法透過查詢連入來知道是否透過模板產生的連入,自己用搜尋功能比較準。--Xiplus#Talk 2021年5月4日 (二) 07:52 (UTC)回覆
@Xiplus:那能不能就每個捷徑分別給出連入數?我仍然覺得此類捷徑不可能每一個都能產生逾100萬的連入。SANMOSA Σουέζ 2021年5月6日 (四) 01:50 (UTC)回覆
Special:PermaLink/65497881。--Xiplus#Talk 2021年5月6日 (四) 02:13 (UTC)回覆
剛才用正規表達式insource:/\[\[:?WP:MEA\|?/精準匹配結果也至少是130萬 截圖 因為正則會跑很久[1],但相信這只是特定專題這樣而已,大部分的專題連入應該都很少,有的專題甚至無連入。-- 五歲抬☎️·☘️2021年5月4日 (二) 06:14 (UTC)回覆
保留這個吧,這個是{{Welcome}}/{{Welcomeip}}的連結之一,當然非常常見。提議加個豁免條款,截至通過日,除本身多於一萬直接連入的常用捷徑豁免快速刪除外其他都機器人修正唄。--LuciferianThomas留言 2021年5月4日 (二) 07:17 (UTC)回覆
這應該要保留,不僅是大量連入,還會導致修改大量使用者的討論頁 ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年5月4日 (二) 10:56 (UTC)回覆
我維持我的提案(快速刪除從Wikipedia指向WikiProject的重新導向,並由bot協助清理連入),但可以容許WP:專題/首頁的缺失條目WP:MEA這兩個例外(只有這兩個產生了逾150萬的連入,其餘都少於10萬,而且大部分估計是模板連入,即使假設全部為非模板連入也不會構成太大的工作量),但也就只有這兩個能例外,而且也不便明文規定,因此會走Liangent G15的路綫,只在模組進行限制。@A2569875XiplusSANMOSA Σουέζ 2021年5月6日 (四) 09:27 (UTC)回覆
Module:Template:Delete/data模組的對應修改見User:Sanmosa/R2模組,已在2021年5月6日 (四) 09:33 (UTC)更新。有勞Xiplus檢查對應修改的代碼是否正常。SANMOSA Σουέζ 2021年5月6日 (四) 09:33 (UTC)回覆

重行公示7日。SANMOSA Σουέζ 2021年5月14日 (五) 13:12 (UTC)回覆


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
@羊羊32521LuciferianThomas:不知道能不能找到人寫bot。不然我們也可以先根據之前就每個WP=>WPJ的捷徑分別的連入數排查出來的結果手動進行「先消除連入、後提R2」的工作,但可能會涉及模板連結跟EPWPJ=>WP的捷徑應該比較容易處理,可以不用bot。SANMOSA Σουέζ 2021年5月22日 (六) 02:46 (UTC)回覆
我可能可以寫,但沒時間跑Bot (這一看就知道要跑很久)。 所以到時如果真沒人寫,我可以提供代碼,然後再請有時間的維基人幫忙跑bot。-- 五歲抬☎️·☘️2021年5月22日 (六) 03:03 (UTC)回覆
最近現實發生一些狀況,暫無法開發Bot。@Sanmosa:,User:LuciferianThomas好像有意願接手?Wikipedia:機器使用者/申請#User:LuciferianBot。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鮮果茶☕](☎️·☘️2021年6月10日 (四) 11:41 (UTC)回覆
已留意。我支持他這樣做。SANMOSA Σουέζ 2021年6月10日 (四) 14:15 (UTC)回覆
@A2569875:可能可以先寫代碼。我已經處理好所有WPJ=>WP的捷徑了,至於WP=>WPJ的捷徑我打算先手動處理連入數少的那些,讓它們先走快速刪除程序。(話説bot是怎樣跑的,我不太清楚相關事宜,所以想學一下,之後或許能幫到一些忙)SANMOSA Σουέζ 2021年5月25日 (二) 02:22 (UTC)回覆
Special:PermaLink/65497881更新為Special:PermaLink/65827060SANMOSA Σουέζ 2021年5月28日 (五) 07:04 (UTC)回覆
Draft:WP-WPJ重新導向連入數量。--Xiplus#Talk 2021年6月1日 (二) 13:31 (UTC)回覆
@Xiplus:完全沒有0連入的數據?SANMOSA Σουέζ 2021年6月1日 (二) 14:56 (UTC)回覆
是,此列表是讓你們清理連入的,所以應該沒必要列出?--Xiplus#Talk 2021年6月2日 (三) 01:55 (UTC)回覆
有必要列出,清理完連入還要R2速刪,0連入的重新導向的處理工作最少(但有時候檢查連入時還是會發現還有一些連入和引用)。SANMOSA Σουέζ 2021年6月2日 (三) 15:04 (UTC)回覆
@Xiplus:實測過一下,在Module:Template:Delete/data下,只有在WP:MEA掛R2才能顯示警告字句,WP:專題/首頁的缺失條目顯示不到,不知道是怎麽一回事。SANMOSA Σουέζ 2021年6月1日 (二) 13:26 (UTC)回覆
沒看到編輯紀錄,你怎麼測的?--Xiplus#Talk 2021年6月2日 (三) 02:30 (UTC)回覆
@Xiplus:頁面預覽功能。現在沒事了,我查了一下Mediawiki,發現我不應該用rootText,而應該用text。SANMOSA Σουέζ 2021年6月2日 (三) 15:00 (UTC)回覆
@XiplusA2569875:話説WPBannerMeta的模板應該有隱藏的「Wikipedia:」開首專題連結,不知道是怎麽一回事,有空要fix一下。SANMOSA Σουέζ 2021年6月10日 (四) 14:15 (UTC)回覆

參考資料

  1. ^ 圖床連結站內存檔)。此正則會匹配連結到WP:MEA的內部連結或管道|連結。※註:由於/:?/有爾會導致搜尋功能錯誤,因此以/:*/替代;由於/\|?/有爾會導致搜尋功能錯誤,因此以/[\|\]]/替代。

第六階段:其他議題討論

編輯

各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️2021年2月14日 (日) 09:41 (UTC)回覆

  • 以下暫時備註
  1. 方針或指引修訂(一點五階段已修改部分,如有未盡之事宜請在此提出)
    Wikipedia:互助客棧/方針#第一點五階段:內容事實修訂
    Wikipedia:互助客棧/方針/存檔/2021年5月#修訂CSD#G14
  2. 專題主頁與專題委員會存放處
  3. WP空間中的專題介紹、Help的專題說明
  4. 專題指引存放處
  5. 未調整好的模板或模組
  6. 這幾個月的使用反饋
  7. 其他未盡之事項
-- 五歲抬☎️·☘️2021年5月8日 (六) 19:25 (UTC)回覆

第三次推動設立LTA命名空間

編輯

由於今年LTA模仿犯泛濫,對本站站務造成困擾,我希望重提設立LTA命名空間,並通過引入擴充功能功能(mw:Extension:Lockdown)設定頁面檢視權限。

前期討論
  1. 部分使用者認為不設定檢視權限就沒必要設定命名空間,有使用者認為即使不設定檢視權限也有必要設定命名空間。
  2. 有使用者認為,限縮檢視權限不利於反破壞人員之養成、判定LTA,甚至淪為社群鬥爭工具。
設立流程
  1. 社群討論決定設立LTA空間。
  2. mw:Writing an extension for deployment#Preparing for deployment的流程,同時社群討論空間的細節。
  3. 擴充功能功能可以啟用後,通過phab:設立LTA空間,並設定檢視權限。同時進行後續處理(如將LTA部分特徵頁面留在Wikipedia空間)。

以上,希望社群討論。 ——魔琴 [ 已經告假 留言 貢獻 ] 2021年12月31日 (五) 15:51 (UTC)回覆

檢視權限設定為回退員只能看,還是其他使用者群組(巡查可能需要以掛板)為佳?問題就是LTA空間的內容一外漏影響就是永久的,很容易在網上流傳開去,需要再三考慮下。--Ghren🐦🕑 2021年12月31日 (五) 18:25 (UTC)回覆
還不如把LTA頁面移動到另一個wiki裡面。--GZWDer留言2022年1月1日 (六) 06:21 (UTC)回覆
這樣說我覺得一些不宜公開討論的反破壞訊息可以全數移動到一個獨立的站點(Miraheze也好、wikimedia下的也好,都可以)--路西法人 2022年1月1日 (六) 11:16 (UTC)回覆
巡退、延伸確認、管。限縮得太緊的弊端已述。至於「LTA空間的內容一外漏影響就是永久的」,回退員也不一定可信啊……限縮主要是為了防模仿犯、反愉快犯,也防止LTA頁面成為破壞者聯絡場所。-- ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月2日 (日) 05:23 (UTC)回覆
不好意思,討論過長沒找到「弊端已述」。延確能否信任也是一個問題,但可以後議。--Ghren🐦🕙 2022年1月2日 (日) 14:42 (UTC)回覆
@Ghrenghren:「不利於反破壞人員之養成、判定LTA,甚至淪為社群鬥爭工具」,完整版見Wikipedia:互助客棧/方針/存檔/2021年8月#再次推動破壞者(LTA)成為命名空間中Kriz的留言。 ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月2日 (日) 15:06 (UTC)回覆
請先確定Lockdown能夠確實引入,以免浪費大家時間來討論。--Xiplus#Talk 2022年1月3日 (一) 05:30 (UTC)回覆
走引入流程可能需要社群共識:Your deployment tracking bug should point to on-wiki community consensus (and/or community support/desire) for having the extension installed on a particular wiki, if applicable. 所以這就是第一步「社群討論決定設立LTA空間」,Ghren的提問其實是下一階段的內容。 ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月3日 (一) 05:42 (UTC)回覆
這不就無窮迴圈了嗎?對LTA空間是否設立存在疑慮是因為不知道能否使用Lockdown擴充功能;若要知道能否使用Lockdown擴充功能,必須達成共識成立LTA空間;若要達成共識成立LTA空間,需要知道可以使用Lockdown擴充功能。這就是永遠的死局了。 --Milky·Defer 2022年1月3日 (一) 07:36 (UTC)回覆
所以我提議的流程是先達成啟用的共識,如果可以啟用再設定空間。 ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月3日 (一) 07:41 (UTC)回覆
我覺得這是個死局。假如不能Lockdown其實沒什麼意義。姑且可以先支持,但假如Lockdown用不了就當時再移回去吧。--Ghren🐦🕓 2022年1月3日 (一) 08:42 (UTC)回覆
所以唯一支持建立獨立的命名空間的理據是使用Lockdown嗎?那麼我不反對將設立命名空間跟引入Lockdown綁定討論,部署Lockdown跟新命名空間應同時進行,若最終Lockdown無法引入,建立命名空間直接作廢。--Xiplus#Talk 2022年1月3日 (一) 11:15 (UTC)回覆
我的意思就是這個(不知道是不是表述不清楚),擴充功能功能可以啟用,通過phab:設立LTA空間。 ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月3日 (一) 12:10 (UTC)回覆
  • (!)意見:敝人路經此地,竊以為若暫且不論站友前述的專業技術工程,斗膽對所謂的LTA之存在和相關頁面表達個人看法。
先說結論,個人主張不限制閱覽權限,但進一步提高收錄門檻;若往後真限制閱覽權限,延伸確認以上權限之使用者可觀看。
首先,個人反對輕易增生所謂的LTA頁面。每每只因有無聊的反社會人士來搞破壞一段時間,社群就替他們「立傳」,竊以為未必具那麼大的迫切或必要性;個人認為大量建立LTA專屬頁面除了可能輕易幫那些破壞者樹立「戰績里程碑」之外,長久而言提供他們繼續追求「戰功和名望」之誘因,也替他們在維基世界和時間長河中留下「個人(可能值得紀念或回味)的歷史印記和足跡」,甚至恐成為有心人輕易反向濫用該頁面或散布特定資訊之良機。某些編輯行為究竟是否屬破壞,個人認為反破壞編者可自行依站內規範和經驗判斷;在破壞者「升級」成為LTA前,多數時候熱心使用者維護關注的目標以「條目」為主,應即可有效實踐反破壞之本意(若真有需要查緝傀儡帳號另當別論)。
其次,此類LTA頁面之使用方式分為編寫和閱覽兩個面向。就閱覽而言,個人仍認為應開放資訊供所有有心使用者閱覽揀用,原因如過往所述。然而就編寫而言,站內熱心站友常在發現有破壞者符合收錄門檻後,便熱心記錄描寫其特徵和行為,並建立相關頁面公示於眾;有時LTA的相關資訊情報甚為模糊,僅稍具輪廓雛形而已,又或是過多細節導致實難真正辨識,甚至套用於其他編者身上亦看似輕易符合,故個人認為可能需要進一步研擬限制措施。
因此,在概念上,個人主張採「無無虛無」(中二....)之策略,亦即「回退、封鎖、不理會」之最大化延伸,盡可能削減破壞者戮力追求之名望、成就、意義、價值、榮譽感、存在感、個人風格等可供追求之心理反饋,故在記載上應提高登載收錄和訊息傳播門檻。
具體措施上,就登載收錄而言,個人建議維基百科:持續出沒的破壞者之情報頁面建立門檻為「持續破壞3個月以上,且編者提供之相關情報資訊經客棧討論公示通過」,方移置公開收錄於VIP室頁首。尤其對於有心藉由模仿或造謠等方式進行擾亂之破壞者而言,若經由少數人收集或判讀訊息、未經過濾便輕易建立可供收錄展示之「專屬頁面」、成為「維基館藏」,甚而因部分熱心關注者可能的誤判造成負面效果,竊以為實屬不妥。
就訊息傳播而言,敝人主張可考慮進一步將所有LTA按編號代碼予以編管,於「Wikipedia:持續出沒的破壞者/<使用者名稱>」建立情報頁面時改採流水號編碼,並以編碼建立相關重新導向,以其編碼公示於VIP室,而原帳號名稱則記述於情報內文和資訊框,編碼方式和規律以可無限延伸、不具意義為基本概念,舉例如下:
1. 盡可能不依特定緣由或規律編號(如出現和破壞之時間、順序、編輯類型等規律或事由),於鄰近的號碼順序內,隨機進行編號。
2. 將英文字母和數字結合,持續延伸,列舉流水號樣式如下:
可無限延伸,若真有需要的一天(笑)。個人意見,供參。--Kriz Ju留言2022年1月6日 (四) 02:24 (UTC)回覆
我覺得,封閉LTA檢視權限可能可以規避「沖戰績」的想法,畢竟自己看不到。至於閱覽面向,我覺得給延伸確認就可以了。 ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月6日 (四) 04:31 (UTC)回覆
別用流水帳,即使要DENY也不至於這樣,這樣太難記誰是誰了。--路西法人 2022年1月11日 (二) 04:51 (UTC)回覆
  • (!)意見:敝人的用意就是要構成一種「雙向限制」的效果,不只限制LTA對外傳播個人「功績」,同時也提高社群對於相關訊息的資訊傳遞和討論門檻,甚至有時有心人正是藉此方式散布各種擾亂訊息。在此敝人斗膽挑戰一個概念:為何我們要記得或認識他們呢?「努力」破壞的人被社群「銘記在心、永恆流傳」,還可以成為被「登載史冊、正式收錄」的對象,反倒對社群有貢獻的善意使用者隨著逐漸淡出或離去,經過幾年後,又有多少人或新進使用者認識或記得他們曾經的貢獻呢?
這麼說起來,是否破壞者破壞一陣之後,即可名留青史?善意的貢獻使用者還不見得可以輕易留名,就證明自己的「存在感」而言,當今的社群機制是否反倒在鼓勵破壞者留名呢?
我們努力記住那些破壞者,卻放任社群遺忘曾經致力為社群貢獻的無名英雄,敢問這是什麼荒謬的現象或制度呢?
進一步而言,隨著時間過去,流水號越往後排越顯冗贅,而對於未來的LTA而言,他們公示於眾、留給世人的,就是這些他們自己也無法掌握、任人取名的「編號」,而不是他們要讓大家認識、甚至充滿個人風格、帶有個人色彩的「帳戶大名」。
竊以為就實務而言,既然提高資訊傳播門檻,加上若往後只有部分使用者具備閱覽權限,這表示只有真正願意投入研究的使用者,才能更熟悉這些訊息,亦即「反破壞」的相關資訊會進一步更接近為「帶有某種技術色彩」的站務,而不是只有「不會寫條目、不務正業」的使用者才會去玩的不入流把戲。
真正願意研究的人,肯定一段時間後就能辨識,尤其對於曝光率較高的那幾位遠古先生,不成大問題(比如有在投資的人就會了解,一段時間後對於投資標的代碼就可以如數家珍),甚至還可以提高使用者參與度和投入時間(事實上點進去頁面看一下即可,也不用硬記);而無法辨識或閱覽資訊的人,是否願意投入反破壞行列,就看個人選擇了。--Kriz Ju留言2022年1月12日 (三) 11:22 (UTC)回覆
這樣只會造成反破壞工作更難進行。有名稱的作用是要可以立刻配出誰是誰,變成流水帳基本上沒人能辨識是哪一個破壞者。「事實上點進去頁面看一下即可,也不用硬記」但給出連結都成問題,怎樣點進去?辨識破壞者是必要的,我近期接觸大量LTA更感受到這一點,不然也不會提出改進破壞者辨認的SPI。--路西法人 2022年1月13日 (四) 09:53 (UTC)回覆
不知道是不是應該回復在這兒。這個擴充功能提供的限制非常雞肋,您只需要在其他命名空間建立一個指向私有的LTA命名空間頁面的重新導向,再在另一個頁面中嵌入前述重新導向,即可瀏覽內容。--——ほしみ 2022年1月17日 (一) 15:59 (UTC)回覆
註:調整 $wgNonincludableNamespaces 無法控制其他命名空間指向LTA命名空間的重新導向之嵌入。--——ほしみ 2022年1月17日 (一) 16:04 (UTC)回覆
啊這,您有去mw:Extension talk:Lockdown提過嗎( ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月17日 (一) 16:14 (UTC)回覆
您可以自行測試後去提一下,我這邊測試的結果是即使是master也沒解決這個問題。這個問題就寫在mw:Security_issues_with_authorization_extensions內,看Inclusion/transclusion一欄右側評論欄的意思是部分解決了,那重新導向嵌入可能沒解決吧。只能說,這個擴充功能限制的read權限目前並不能阻止破壞者完全不能閱讀。--——ほしみ 2022年1月17日 (一) 16:37 (UTC)回覆
重新導向問題可能可以通過AF解決? ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月18日 (二) 03:58 (UTC)回覆
AF沒用的,單頁面內預覽就行了,甚至不需要建立頁面。
例如Sandbox頁面:
#重定向 [[LTA:Sandbox]]
{{:Sandbox}}
——ほしみ 2022年1月18日 (二) 04:29 (UTC)回覆
Ghrenghren在站外提到可以「在所有LTApage 上加上個空白的onlyinclude」。 ——魔琴 [ 留言 貢獻 ] 2022年1月19日 (三) 15:42 (UTC)回覆
已確認,已報告。--Xiplus#Talk 2022年1月17日 (一) 16:36 (UTC)回覆
另外,一般使用者仍然可以在近期變更、最新頁面、使用者貢獻等特殊頁面看到私有命名空間內每一筆編輯的摘要,包括建立頁面時自動生成的摘要。--——ほしみ 2022年1月17日 (一) 16:45 (UTC)回覆

上述討論中LTA收錄門檻的討論與本案無關,將分拆討論。距離Kriz君在我的討論頁表示支持已過去七日,現擬出決議並   交付公示,為期7日,2022年1月24日 (一) 04:19 (UTC) 結束

本社群達成共識:

一、本站將設立臨時代號為「LTA」的命名空間,用於儲存長期破壞的資訊以反破壞,其它細節待議。

二、本站將申請部署mw:Extension:Lockdown以限制LTA命名空間的閱覽權限。

三、LTA命名空間僅應在mw:Extension:Lockdown可以部署後設立。

 ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月17日 (一) 04:19 (UTC)回覆

最好不要再像修訂巡查那樣擱淺。—— Eric Liu 創造は生命(留言留名學生會 2022年1月17日 (一) 07:27 (UTC)回覆
上面的說的在理,我們還要搞嗎  囧rz……--Ghren🐦🕗 2022年1月18日 (二) 00:10 (UTC)回覆
唉,又是一次浪費社群時間的討論。—— Eric Liu 創造は生命(留言留名學生會 2022年1月18日 (二) 00:33 (UTC)回覆
單獨設立空間本缺乏意義,但本案提及限制閱覽權限的問題,其論述有說服力,故支持本案。但
  1. 本案之二仍需明確,具有閱覽權限的使用者範圍,該範圍不易太窄。有使用者提出以延伸確認為界,考慮到反破壞一般至少是具備一定經驗的使用者,我認為是適宜的。
  2. 若能著手明確本案之二、三技術上是否確實可行,則更為穩妥。
以上。--Kirk # 2022年1月18日 (二) 04:15 (UTC)回覆
現在討論這個大概真是浪費社群時間……但是考慮到 IP masking, 我希望LTA空間對且僅對(未來)有權限檢視IP位址的使用者開放,而延伸確認肯定不是這種使用者群組。 ——魔琴 [ 留言 貢獻 ] 2022年1月18日 (二) 10:41 (UTC)回覆

撤下公示。 ——魔琴 [ 留言 貢獻 ] 2022年1月19日 (三) 12:17 (UTC)回覆

(對本討論串整體的意見)在過去的反破壞工作中,我有九成把握可以說,能查閱私有過濾器者(回退員、管理員)中有人向外洩漏私有過濾器內容。所以不要對「限制閱讀權限對保密有好處」抱有任何希望。謹此提醒參與本討論的編者。至於防模仿、愉快犯的作用幾何,我對此基本沒有實感。--Tiger留言2022年1月19日 (三) 13:21 (UTC)回覆
我有一個限制閱讀權限的另一個理由:IP masking 實施之後,普通使用者群組不能直接檢視未登入使用者的IP,而有權限檢視的使用者也不能向無權限的使用者提供這個資訊,而反破壞中IP也是很重要的,只能放在私密的命名空間里了(即使保密性存疑)。 ——魔琴 [ 留言 貢獻 ] 2022年1月19日 (三) 13:58 (UTC)回覆
這不是只有本地會遇到,而是所有wiki都會遇到,沒有必要本地硬想出方法(尤其還是個爛方法),參考其他wiki的作法也是可以的。--Xiplus#Talk 2022年1月26日 (三) 06:58 (UTC)回覆
至於能查閱私有過濾器者(回退員、管理員)中有人向外洩漏私有過濾器內容,嗯,看起來不是什麼新聞。 ——魔琴 [ 留言 貢獻 ] 2022年1月19日 (三) 16:02 (UTC)回覆

設立新維基

編輯

GZWDer在phab提出了相關task後,User:Martin Urbanec表示,因為MediaWiki的閱讀限制很可能被繞過,「幾乎可以肯定Lockdown不會在任何維基媒體維基安裝」。他建議可以參考義大利語維基百科申請建立的https://sysop-it.wikipedia.org,可能更適合本站的需求。

GZWDer於是提出了Create zhltawiki 的task作為替代。有兩種方案:一是傳統私密維基,不連接SUL,符合要求的使用者可以通過一個Toolfridge工具自動建立帳號;一是Miraheze式的私密維基,連接SUL列入「member」使用者群組的使用者有權限檢視私密內容。

User:Majavah表示CentralAuth並不支持Miraheze式方案。

現交付社群討論是否建立LTA維基,以及其具體實現方式。 ——魔琴 [ 留言 貢獻 ] 2022年1月21日 (五) 16:10 (UTC)回覆

建議CentralAuth,但由BOT進行在主站有相應權限的使用者的權限同步,把read給一個額外的使用者群組。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2022年1月21日 (五) 22:23 (UTC)回覆
IP masking 實施之後,LTA WIKI(或Lockdown,但不可行)成為了憲制性必須存在的實體,故(+)支持。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2022年1月21日 (五) 22:31 (UTC)回覆
我覺得沒什麼必要。Tigerzeng閣下說的也挺明白了。—— Eric Liu 創造は生命(留言留名學生會 2022年1月22日 (六) 02:08 (UTC)回覆
(✓&)有條件同意:建立一個新維基就設立的通用一點,延伸確認使用者維基,所有延伸確認使用者可見,或站務維基(行政員、管理員、巡查員、回退員、經申請可檢視者)。桐生ここ[討論] 2022年1月22日 (六) 02:40 (UTC)回覆
我覺得可以(站務維基),而且我突然想到,編輯sysop-it的都是sysop,那麼編輯zh-lta的就都是      ——魔琴 [ 留言 貢獻 ] 2022年1月22日 (六) 15:53 (UTC)回覆
(+)有條件支持:私以為除非對檢視者進行嚴格限制(如wiki檢視權應使用類似於巡查回退的申請方法),否則LTAWiki的設立並無太大意義。—Regards, BureibuNeko 2022年1月22日 (六) 06:15 (UTC)回覆
既然有管理員內鬼,這條路恐怕不通。--Temp3600留言2022年1月22日 (六) 09:04 (UTC)回覆
說起來,還有防濫用過濾器這條路可以硬塞LTA資訊的,不過有可能影響過濾器效率(--1233 T / C 2022年1月23日 (日) 03:27 (UTC)回覆
(+)支持,但是可訪問使用者的選擇可能需要在延展使用者的基礎上增加一些特殊的限制,如規定最低Wikipedia命名空間編輯數。--Yining Chen留言|簽名頁2022年1月23日 (日) 14:05 (UTC)回覆
沒意見。--三萬光年 GBAW 2022年1月25日 (二) 12:04 (UTC)回覆
(+)傾向支持,只要訪問限制得當,就沒有問題。--在下荷花請多指教歡迎簽到2022年1月26日 (三) 04:09 (UTC)回覆
應該先確定持權條件再來設立新維基,另外反對任何能夠自動獲權的門檻制,應採用申請制,不然洩漏內容的話不僅隱藏內容無用,反而將資料保存在獨立的wiki上,徒增麻煩而已。--Xiplus#Talk 2022年1月26日 (三) 06:56 (UTC)回覆
(+)支持,但(-)傾向反對CentralAuth的方案,我支持xiplus的申請制,並且我認為該wiki不應該搭建在wikipedia.org空間,而是自行在Toolforge上搭建,帳號系統與基金會的CentralAuth完全分開。--忒有錢🌊塩水あります🐳留言2022年2月3日 (四) 18:41 (UTC)回覆
(~)補充:關於申請制,我認為應設立如下門檻:
  1. 關於閱讀權限,我認為至少是延伸確認使用者才可申請;
  2. 關於編輯權限,我認為必須是傀儡調查助理、使用者查核員(若有本地查核權)/監管員(若無本地查核權)、管理員、行政員、監督員才可申請。
以上。--忒有錢🌊塩水あります🐳留言2022年2月19日 (六) 13:50 (UTC)回覆
wikipedia.org空間、Toolforge、CentralAuth其實是三件不相干的事情...沒有因果關係。--Xiplus#Talk 2022年2月19日 (六) 14:40 (UTC)回覆
(+)有條件支持:支持提案,但認同Xiplus君所言應優先決定持權條件再設立。另外能不能不要叫「LTA維基」  囧rz……--路西法人 2022年2月9日 (三) 07:24 (UTC)回覆
看起來就「設立」本身有了初步共識,可以進一步往下進行討論。順便一提關於IP masking方面的事項似乎現在處於停滯狀態(原計劃是在1月17日給出一個方案的),是否需要在此方面等待一下?如果那邊有了推進(比如那邊似乎是說要成立一個新的使用者群組可以看部分masked的IP),可以參考那邊的組的門檻。 Stang 2022年2月16日 (三) 20:25 (UTC)回覆
返回專案頁面「命名空间/2021年设立新命名空间及伪命名空间」。