
维基百科:互助客栈/方针
![]() |
發表前請先搜索存档,參考舊討論中的内容可節省您的時間。 |
![]() 存檔 |
---|
2003年 5月或以前 6 7 8 9 10 11 12 月 |
- [討論] 第十九次动员令筹备讨论现已开始,請踴躍參與討論。
- [調查] 互助客栈消息區正在就通用行为准则/2021咨询尋求更廣泛的社群意見,請踴躍參與討論。
- [調查] 互助客栈方針區正在就7DAYS規則的執行力度及限制模板著色尋求更廣泛的社群意見,請踴躍參與討論。
- [公告] 微調WP:DYKC投票须知行文及增訂偽名字空間的快速刪除方針已經通過。
- [公告] 專題空間相關捷徑與重定向的規範及請求在全域標題黑名單增加針對不當用戶名之規則正在進行公示,如有意見請盡快提出。
- [討論] 互助客栈方針區正在討論專題空間相關捷徑與重定向的規範、建立頁面命名一致性的通用(普遍性)規定、调整界面管理员方针、设立过滤器禁止将维基百科用作来源及订立编辑松相关规章制度,請踴躍參與討論。
- [討論] 互助客栈技術區正在討論修改CS1系列引文格式模板、以模組改寫Namespace pagename模板及引入Legobot机器人,請踴躍參與討論。
# | 話題 | 發言 | 參與 | 最新發言 | 最後更新(UTC+8) |
---|---|---|---|---|---|
1 | 專題命名空間 | 183 | 20 | 羊羊32521 | 2021-04-22 00:08 |
2 | 偽命名空間 | 222 | 18 | Sanmosa | 2021-04-21 11:28 |
3 | WP:捷徑指引草案修訂 | 23 | 4 | A2569875 | 2021-04-21 10:51 |
4 | 有關某年代相關分類命名統一事宜 | 46 | 14 | Sanmosa | 2021-04-21 16:59 |
5 | 請求第三方管理員參與評估和總結可靠來源討論 | 1 | 1 | 痛心疾首 | 2021-04-18 20:40 |
6 | 關於Wikipedia:命名常规 (音乐) | 79 | 16 | Milkypine | 2021-04-20 18:04 |
7 | (重提)Wikipedia:共识#提案討論及公示時間的執行力度 | 104 | 19 | 羊羊32521 | 2021-04-22 00:11 |
8 | 有關新增偽命名空間的提議 | 17 | 7 | Sanmosa | 2021-04-14 21:24 |
9 | 模板颜色相关规范 | 67 | 17 | Milkypine | 2021-04-20 15:01 |
10 | 调整界面管理员方针之“权限取得”一节 | 24 | 10 | Temp3600 | 2021-04-18 13:22 |
11 | 模板修訂建議 | 1 | 1 | Jimmy-bot | 2021-04-22 16:14 |
12 | 设计一个制度解决部分速删模板挂不上去的页面的删除问题 | 14 | 6 | Tranve | 2021-04-21 20:28 |
13 | 限縮{{电视节目的变迁}}模板使用範圍 | 8 | 8 | LuciferianThomas | 2021-04-22 14:53 |
14 | 通用行為準則/2021諮詢 | 1 | 1 | Yining Chen | 2021-04-16 22:31 |
15 | 设立过滤器禁止将维基百科用作来源 | 13 | 5 | Antigng | 2021-04-21 15:39 |
16 | 订立编辑松相关规章制度 | 43 | 15 | Yangwenbo99 | 2021-04-23 02:52 |
17 | 將「青島」、「中國青島」或「山東青島」改成「中華人民共和國山東省青島」是否有必要 | 30 | 13 | Sanmosa | 2021-04-20 12:44 |
18 | 訂立影片加入相關指引 | 17 | 8 | Antigng | 2021-04-22 13:51 |
19 | 在个人贡献之“翻译”页面添加数个机械翻译工具是否涉嫌鼓勵用戶违反方针指引? | 4 | 4 | Xiplus | 2021-04-22 17:15 |
發言更新圖例 |
---|
|
|
|
|
|
特殊狀態 |
已移動至其他頁面 或完成討論之議題 |
手動設定 |
當列表出現異常時, 請先檢查設定是否有誤 |
專題命名空間[编辑]
[編輯此導航模板]
|
捷徑指引草案的討論,源自於「偽命名空間」的討論,英語維基百科對於捷徑相關的規範及偽命名空間的設立已有成熟的執行方式。中文維基百科中的部分編輯者對於「格式手冊」、「長期破壞者」及「專題」這三個主題提出可升級成命名空間或以偽命名空間形式存在,並有正反兩方的陳述與看法。
目前較為接近共識的是「專題」提升為正式命名空間,反對者的論述已由支持者回應,且反方無進一步論述。然為求慎重,且將捷徑與命名空間等議題作系統性討論,將會執行階段修訂,以取得最大共識。
本討論的各階段分為:
專題提升為命名空間與否及其細節;格式手冊及長期破壞者是否成為命名空間或偽命名空間;- 偽命名空間規範寫入捷徑規範內(如前項通過)或是否允許偽命名空間(如前項不通過);
- 捷徑規範細部討論並決定是否成為指引。
各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)
說明稍微看了一下先前韓文維基的申請phab:T29651,其工程師處理的流程將近一個月,故認為應該還要一段時間才能完成布署,故暫時先撤下公告Special:Diff/63712969、Special:Diff/63713130,等到了Code Review階段時再放回。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月14日 (四) 06:18 (UTC)
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
- 直接將PJ:獨立為新WP:命名空間
(&)建議像日文維基那樣,專題直接變成一個 "真" 名字空間 ja:Help:名前空間#プロジェクト就不會有cwek說的 "假" 名字空間 的 混淆問題了。日維相關討論。 -- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年11月16日 (一) 06:06 (UTC)
- (=)中立,但此僅為其中一個被提議的偽命名空間提供了替代方案,那麼另外的LTA:和MOS:呢?--LuciferianThomas.留言 2020年11月16日 (一) 09:32 (UTC)
- 意思使用新建一個「專題」的空間,把Wikipedia:ACG專題移動到專題:ACG;然後把PJ作為「專題」名字空間的別名?--洛普利宁 2020年11月16日 (一) 16:01 (UTC)
- 从这个动议的内容上看应该是这个意思,开辟一个“WikiProject”空间,简称"PJ",中文为“专题”和“维基专题”--MilkyDefer,推迟,咕咕 2020年11月16日 (一) 16:11 (UTC)
- (+)支持 ——羊羊 (留言|贡献) 2020年11月19日 (四) 15:49 (UTC)
- 大致(+)支持(LTA和MOS可以單獨開成新的,即簡稱直接當本名,
格式手冊
當別名)-- Sunny00217 2020年11月22日 (日) 12:26 (UTC)
- 小總結
根據以上討論,目前共有兩個選項:
- 開放偽命名空間;
- 將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)
- 等等,PJ:和P(ortal):的区别我没太搞清。哪位可以解释一下?Zhuofan WuCien años de soledad 2020年11月29日 (日) 03:08 (UTC)
“ | 与专供维基编者使用的维基专题不同,维基主题是同时为编者及一般读者服务的。 | ” |
—— Portal:首页 |
- 羊羊 (留言|贡献) 2020年11月29日 (日) 04:11 (UTC) ——
- Wait,有bug。Project命名空間在中文維基百科等價於Wikipedia命名空間。SANMOSA SPQR 2020年11月29日 (日) 14:24 (UTC)
依照目前公示後討論情況,將會和下面的捷徑指引案併案討論,並採取分階段修訂。今天晚上會進行整合。臺灣杉在此發言 (會客室) 2020年12月6日 (日) 07:38 (UTC)
依據先前討論,專題命名空間的討論已接近達成共識之階段,目前問題包含:
- 英文命名部分,其一為Project並取消與Wikipedia空間連動,其二為以WikiProject命名;
- 部分使用者認為直接將PJ與Wikipedia連動即可。
請討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)
- 个人以为Project名字空间肯定不能变,否则可能会造成不少链接失效。因此名字空间应该命名为“WikiProject”,对应的中文名字空间应该命名为“维基专题”,以便于与“WikiProject”对应。——BlackShadowG(留言) 2020年12月11日 (五) 16:27 (UTC)
公示7天:理據:本議題先前公示並通過的討論已討論滿一個月,且自本討論上次有效發言羊羊32521留言2020年12月16日 (三) 15:08 (UTC)已逾一周,根據WP:7DAYS公示七天。如通過,屆時具體的做法可以參考phab:T26852 -- 來人啊,餵宮子吃布丁! ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年12月24日 (四) 08:47 (UTC)
- 專題這種東西本來就都沒有什麼用戶在關注了。所以什麼都不問,只問一個問題:請問這樣一來那些原本已經用於條目討論頁上的專題名稱會不會有影響?--Z7504非常建議必要時多關注評選(留言) 2020年12月31日 (四) 08:42 (UTC)
- 既然木已成舟,大家意見如此,我也沒法反對什麼,但是請提案者一定要做好配套措施,以免留給本地社群一堆爛攤子去收。—— Eric Liu 創造は生命(留言.留名.學生會) 2020年12月31日 (四) 11:32 (UTC)
- 自上周補充公示共識內容的發言 2020年12月26日 (六) 12:47 (UTC)後已公示逾一周,公示期內無合理異議,本議案通過。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 07:44 (UTC)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
專題空間設立流程與細節[编辑]
參考ja:Special:PermaLink/39099771#ウィキプロジェクト用名前空間の新設以及ja:Wikipedia:ウィキプロジェクト/名前空間の新設,本地的處理方式預計會分成5個階段進行:
向phab:提交申請設立專題空間;- 將專題頁與討論頁批次移動到專題空間(可能需WP:FLOOD);
- 修正指向專題的內部連結(可能需WP:FLOOD);
- 調整專題模板;
- 討論重新導向與捷徑的設立方式;
- 其他議題。
- 以上。以上流程不會立即執行,會在社群對流程沒有異議之後公示後執行。如有其他相關疑問可繼續在下方討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 07:44 (UTC)
第一階段:申請[编辑]
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
- 將會提供給phab:的細節如下:
名字空間 | 討論空間 | |
---|---|---|
內部名稱 (前綴) |
WikiProject: | WikiProject_talk: |
ID | 102 | 103 |
中文名稱 (介面名稱) |
維基專題 | 維基專題討論 |
別名 |
|
|
- 我觉得中文名称叫“专题”更简洁一点…… ——羊羊 (留言|贡献) 2021年1月3日 (日) 14:02 (UTC)
- 這個名稱是參考User:BlackShadowG的提議。@BlackShadowG:關於羊羊32521的意見,您有甚麼看法?-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 14:10 (UTC)
- (:)回應@羊羊32521:該名稱主要是介面顯示的名稱(如左上角顯示[維基專題][討論][不转换]_____[閱讀][編輯][歷史]☆[更多∇][TW∇][搜尋維基百科🔍]),而關於簡潔與否問題,由於有同步申請別名,因此亦可以透過輸入專題:XXX連結到專題頁,並不一定要寫全名維基專題:XXX(參考預計命名)。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 19:42 (UTC)
- (?)疑問@羊羊32521:您可以接受上面的解釋嗎?;@YFdyh000:那個中文名稱實際上是對應介面顯示名稱—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月5日 (二) 05:52 (UTC)
- @A2569875:
行 ——羊羊 (留言|贡献) 2021年1月5日 (二) 15:22 (UTC)
- @A2569875:
- (?)疑問@羊羊32521:您可以接受上面的解釋嗎?;@YFdyh000:那個中文名稱實際上是對應介面顯示名稱—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月5日 (二) 05:52 (UTC)
公示3日,如無異議就
转交phab:。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月6日 (三) 07:53 (UTC)
进行中……:已由User:Shizhao將之轉交Project Board:Site Configuration(參見討論Topic:W1avxa7f606do5k1),目前工單Task:T271612位於Tag:Wikimedia-site-requests中的Project Board:Config - to process,正待處理中。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月21日 (四) 07:47 (UTC)
- 經確認,根據維基百科後端代碼includes/Title.php中的
function getNamespaceKey
,其定義為:'nstab-' . lc($namespaceKey)
,因此介面文字無需由phab那邊指定,屆時僅要由介面管理員將 "MediaWiki:nstab-" + 小寫(命名空間英文名稱) 填入文字即可,即需要在以下頁面提出編輯請求MediaWiki:Nstab-wikiproject、MediaWiki:Nstab-wikiproject/zh、MediaWiki:Nstab-wikiproject/zh-hant、MediaWiki:Nstab-wikiproject/zh-tw、MediaWiki:Nstab-wikiproject/zh-hk、MediaWiki:Nstab-wikiproject/zh-mo、MediaWiki:Nstab-wikiproject/zh-hans、MediaWiki:Nstab-wikiproject/zh-cn、MediaWiki:Nstab-wikiproject/zh-sg、MediaWiki:Nstab-wikiproject/zh-my填入维基专题
或維基專題
即可。好像User:羊羊32521在phab那邊提醒的zh-MY漏打好像其實也不用補,因為技術人員也無法調整那個部分,只能由介面管理員記得建立MediaWiki:Nstab-wikiproject/zh-my即可。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月23日 (六) 02:34 (UTC)- @A2569875:MediaWiki:Conversion-ns102和MediaWiki:Conversion-ns103也需要補-- Sunny00217 2021年1月23日 (六) 05:34 (UTC)
完成已Commit程式碼到gerrit:657572(詳細資料)。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月26日 (二) 12:50 (UTC)
完成已提出編輯請求MediaWiki_talk:Nstab-wikiproject#編輯請求_2021-01-26,並補上User:Sunny00217提醒的MediaWiki:Conversion-ns102以及MediaWiki:Conversion-ns103等頁面。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月26日 (二) 13:55 (UTC)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
第一點五階段:內容事實修訂[编辑]
由於該命名空間設立完畢,已修正WP:命名空間新增該空間說明。如需補充歡迎討論。臺灣杉在此發言 (會客室) 2021年1月27日 (三) 13:40 (UTC)
- 您漏了WP:NS#缩写和别名。--LuciferianThomas.留言 2021年1月28日 (四) 08:08 (UTC)
- 請協助複查是否全部的相關說明頁都修復完畢。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月25日 (四) 05:49 (UTC)
第二階段:轉移至新名字空間[编辑]
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
名字空間設立完畢後,將會把所有列於Category:维基专题中的頁面及子頁面轉移至新名字空間,預計轉移的頁面及轉移之目標列於此頁User:A2569875/議案/專題空間設立/影響頁面(暫不包括重新導向),如有異議請盡快提出。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 19:26 (UTC)
- 以下彙整:
- User:A2569875/議案/專題空間設立/影響頁面
- 另請參考對應表(重新導向移動時若與對應表重複將不會進行移動)
- User:A2569875/議案/專題空間設立/影響重新導向
- User:A2569875/議案/專題空間設立/影響頁面
第二階段 之 公示狀態通告[编辑]
公示即日起至命名空間佈署完畢為止。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月6日 (三) 14:12 (UTC)
:稍微看了一下先前韓文維基的申請phab:T29651,其工程師處理的流程將近一個月,故認為應該還要一段時間才能完成布署,為了避免長時間占用公告欄,因此暫時先撤下公告Special:Diff/63712969,等到了Code Review階段時再繼續公示。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月14日 (四) 06:18 (UTC)擱置、暫停公示
- 測試結果見此[1],以PJ:多面體為例,目前未見系統性問題。預定將在公示結束時申請WP:FLOOD(或現在就去送審)並進行批量(►)移动。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月28日 (四) 07:21 (UTC)
第二階段 之 公示期討論[编辑]
- Wikipedia:专题應該被重命名成甚麼?WikiProject:首页嗎?-- Sunny00217 2021年1月27日 (三) 10:07 (UTC)
- 專題和專題委員會目前不在上述清單中,暫時不會移動。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月27日 (三) 10:27 (UTC)
- 我觉得可以在WP名字空间中留一个介绍专题的页面,专题委员会可以考虑更名为WikiProject:委员会,不过这都是后话了,先完成转移再讨论吧。——BlackShadowG(留言)维基百科20岁生日快乐! 2021年1月27日 (三) 12:56 (UTC)
- @BlackShadowG:這主意不錯。-- 2021年1月27日 (三) 16:48 (UTC)
- 我觉得可以在WP名字空间中留一个介绍专题的页面,专题委员会可以考虑更名为WikiProject:委员会,不过这都是后话了,先完成转移再讨论吧。——BlackShadowG(留言)维基百科20岁生日快乐! 2021年1月27日 (三) 12:56 (UTC)
那 - 專題和專題委員會目前不在上述清單中,暫時不會移動。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月27日 (三) 10:27 (UTC)
- 技术性
(-)反对,ns:103好像有点问题。[2],页眉显示名字空间侦测错误,不知道是什么情况 ——羊羊 (留言|贡献) 2021年1月28日 (四) 01:50 (UTC)- ns:102也有这个问题…… ——羊羊 (留言|贡献) 2021年1月28日 (四) 02:04 (UTC)
- 切换到非中文
en界面就不报错[3]--百無一用是書生 (☎) 2021年1月28日 (四) 03:53 (UTC)- 虽然有报错信息,但是创建页面没有问题:WikiProject:沙盒--百無一用是書生 (☎) 2021年1月28日 (四) 03:58 (UTC)
已修复 已经修复这个问题在Template:Namespace pagename--百無一用是書生 (☎) 2021年1月28日 (四) 04:10 (UTC)
- 虽然有报错信息,但是创建页面没有问题:WikiProject:沙盒--百無一用是書生 (☎) 2021年1月28日 (四) 03:58 (UTC)
- 切换到非中文
- ns:102也有这个问题…… ——羊羊 (留言|贡献) 2021年1月28日 (四) 02:04 (UTC)
- 已申請Wikipedia:机器用户/申请#專題名字空間頁面遷移作業,預計於公示結束後開始執行任務。(目前仍然照著日維的劇本在走,有前人經驗參考,我想應該會順利完成)-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月28日 (四) 07:40 (UTC)
- 題外話:完成所有討論後,應否為整個設立新命名空間及偽命名空間的討論設WT分頁並重新整理所有章節的討論?--LuciferianThomas.留言 2021年1月28日 (四) 08:14 (UTC)
- @LuciferianThomas:我把日維的ja:Wikipedia:ウィキプロジェクト/名前空間の新設直接搬來了,你看看行不。Wikipedia:专题/提升为命名空间-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月28日 (四) 09:29 (UTC)
- 我意思是說Talk Archive🌚--LuciferianThomas.留言 2021年1月28日 (四) 09:48 (UTC)
- @LuciferianThomas:我把日維的ja:Wikipedia:ウィキプロジェクト/名前空間の新設直接搬來了,你看看行不。Wikipedia:专题/提升为命名空间-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月28日 (四) 09:29 (UTC)
- 題外話:完成所有討論後,應否為整個設立新命名空間及偽命名空間的討論設WT分頁並重新整理所有章節的討論?--LuciferianThomas.留言 2021年1月28日 (四) 08:14 (UTC)
- 好奇的问一下,Wikipedia:电子游戏专题/条目指引和Wikipedia:钱币学专题/条目指引这两个同时是维基百科正式内容指引的页面会不会移动? --Milky·Defer 2021年1月28日 (四) 12:19 (UTC)
- 預計先全部移動,再另外處理其餘要移到他處的頁面。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月28日 (四) 12:32 (UTC)
- 或者您也可以直接編輯轉移表,透過加入註解符號(
//
或/* ... */
)來排除您認為不應轉移到專題空間的頁面,User:A2569875/議案/專題空間設立/轉移表、User:A2569875/議案/專題空間設立/重定向轉移表(上方列出用於公示的wikitable僅是視覺化呈現的方式,實際上仍然要用json輸入FLOOD程式)感謝。-- ナナチ果物プリン🐰🥭🍮(宇帆·s☎️<用户/span>·☘️) 2021年1月28日 (四) 13:23 (UTC)
- 或者您也可以直接編輯轉移表,透過加入註解符號(
- 預計先全部移動,再另外處理其餘要移到他處的頁面。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月28日 (四) 12:32 (UTC)
公示通過,即將開始移動-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 13:04 (UTC)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
- (註:以下討論涉及後續階段的探討,先不關閉)-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 13:04 (UTC)
- Just a suggestion,正式全面部署后能不能设置过滤器或者白名单,限制用户创建“WP:XX专题”或“WP:XX维基专题”的页面?--百战天虫(留言) 2021年1月28日 (四) 16:32 (UTC)
- (+)支持——BlackShadowG(留言)维基百科20岁生日快乐! 2021年1月29日 (五) 00:54 (UTC)
- 目前有一个技术问题,Template:Category handler无法处理WikiProject namespace,连带导致各个已经转移的专题无法被列入诸如Category:活跃维基专题这类活跃度分类。--BoyuZhang1998(留言) 2021年1月29日 (五) 10:06 (UTC)
- 专题指引更名
- (承上方已經封閉的討論)Wikipedia:电子游戏专题/条目指引和Wikipedia:钱币学专题/条目指引可以如Template:Wikipedia policies and guidelines所示,考慮移動到Wikipedia:电子游戏条目指引和Wikipedia:钱币学条目指引(一个类似的例子是ACG专题论述Wikipedia:日本動漫遊戲條目指導)。或者保守一点,简单删掉斜线,变成Wikipedia:电子游戏专题条目指引和Wikipedia:钱币学专题条目指引)。--洛普利宁 2021年1月30日 (六) 15:19 (UTC)
- (+)支持更名为Wikipedia:电子游戏条目指引和Wikipedia:钱币学条目指引,这比较符合WP:方针中规定的命名方式。——BlackShadowG(留言)维基百科20岁生日快乐! 2021年2月1日 (一) 02:02 (UTC)
- (+)支持,直接更名为「Wikipedia:xxxx条目指引」就好了,我觉得没必要带一个「专题」字样。如果其他专题也有未成正式指引的条目指导的话,我支持全部移动成「Wikipedia:xxxxx条目指导」,日后如果有提升为指引,再将「指导」改成「指引」。--Milky·Defer 2021年2月1日 (一) 03:05 (UTC)
- (+)傾向支持以上提议,提升专题指引的曝光度和参与度,使其更经考验。直接名为“指引”,挂特制参数的“专题指引”模板为好。--YFdyh000(留言) 2021年2月1日 (一) 04:25 (UTC)
- 7日内无新留言,根据WP:7DAYS,就Wikipedia:电子游戏专题/条目指引和Wikipedia:钱币学专题/条目指引更名为Wikipedia:电子游戏条目指引和Wikipedia:钱币学条目指引一案
公示7日。——BlackShadowG(留言)维基百科20岁生日快乐! 2021年2月10日 (三) 01:13 (UTC)
- @BlackShadowG:公示完毕了。--Milky·Defer >恭贺新春 2021年2月18日 (四) 15:03 (UTC)
- @MilkyDefer:目前所有方针指引均被移动保护,已提出移动请求,等待管理员处理。——BlackShadowG(留言)维基百科20岁生日快乐! 2021年2月18日 (四) 16:04 (UTC)
- @BlackShadowG:公示完毕了。--Milky·Defer >恭贺新春 2021年2月18日 (四) 15:03 (UTC)
- 第二階段:提議將WP:XX專題/YY指引以及PJ:XX專題/YY指引皆移動到WP:XXYY指引。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月18日 (四) 16:10 (UTC)
- 「維基專題:維基專題:XX」的頁面
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
- @A2569875:話說這種的需不需要考慮直接提請管理員批量刪除?-- Sunny00217 2021年2月1日 (一) 11:27 (UTC)
- (+)支持,此类重定向并无意义,看起来是移动时出现的失误?——BlackShadowG(留言)维基百科20岁生日快乐! 2021年2月3日 (三) 01:50 (UTC)
完成:Topic:W2qh255e9e7fx3x8,已由User:蟲蟲飛執行WP:CSD#R3(×)快速删除-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月5日 (五) 06:59 (UTC)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
第二點五階段:相關技術問題修正[编辑]
根據phab:T273763(設立專題空間後,連入頁面API於 pywikibot 出錯),此修正案導致部分機器人出錯。目前phab:T273763已解決,留此節討論其他相關技術出問題時的策略與解決方案。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月8日 (一) 17:54 (UTC)
- 前几天发现WikiProject:传统百科全书条目因为页面移动后造成大部分子页面出现错误,目前已经修复一部分--百無一用是書生 (☎) 2021年3月16日 (二) 02:37 (UTC)
第三階段:修正指向專題的內部連結[编辑]
各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 19:29 (UTC)
- 第三階段為修正指向專題的內部連結,主要要修正的是一些模板、模組等,純粹葉面的內部連結因為有保留重新導向故暫時還會有效,至於需不需要全部修正並刪除重新導向可以討論(日維當時保留大部分的重新導向至今)。已經修復的模板包括{{Namespace pagename}};目前已知待修復的模板有{{Category handler}}及{{Namespace detect}}。其餘將陸續補充。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 12:57 (UTC)
- @A2569875:想请问一下快捷方式如何规定?目前是专题都占用了一个WP快捷方式,以后是否都需要把WP快捷方式换成WPJ快捷方式?--LightyearsTalk#欢迎加入智能手机专题 2021年1月30日 (六) 10:02 (UTC)
- @30000lightyears:請見最初流程規劃「5.討論重新導向與捷徑的設立方式」,這是第五階段的討論重點。我認為先把現有頁面調整好再討論這方面比較好,否則整個會亂掉。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月30日 (六) 10:22 (UTC)
- 好,麻烦您在第五阶段开放时ping一下我,谢谢!--LightyearsTalk#欢迎加入智能手机专题 2021年1月30日 (六) 10:24 (UTC)
- @30000lightyears:請見最初流程規劃「5.討論重新導向與捷徑的設立方式」,這是第五階段的討論重點。我認為先把現有頁面調整好再討論這方面比較好,否則整個會亂掉。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月30日 (六) 10:22 (UTC)
- 是否需要修改所有的內部連結,可能需要與「是否需要刪除WP->PJ的重定向」一併討論。-- 五歲抬頭雪菲(☎️·☘️) 2021年3月24日 (三) 05:47 (UTC)
第四階段:調整專題模板[编辑]
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
- 部分專題模板需要調整才能正常,除了第三階段與連入頁面、分類相關的模板要調整外,其餘模板帶移動完成後再觀察情況,屆時將會補充需要辦理的事項。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 12:57 (UTC)
- 比如{{WPBannerMeta}}?——BlackShadowG(留言)维基百科20岁生日快乐! 2021年2月5日 (五) 02:02 (UTC)
- 是的@BlackShadowG:,除了{{WPBannerMeta}},其他已經修改好的模板有{{Namespace detect}}、{{Namespace pagename}}、{{Namespace detect showall}}、{{Main talk other}}、{{Category handler}},然後{{Main other}}管理員還沒處理。如有缺漏還需協助指出。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月5日 (五) 13:51 (UTC)
- {{WPBannerMeta}}好像还没修-- ——羊羊 (留言|贡献|古典音乐专题) 2021年2月6日 (六) 07:10 (UTC)
- 全保護......⋯⋯—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月6日 (六) 12:21 (UTC)
{{Main other}}
一直還沒修阿囧rz……-- Sunny00217 2021年2月10日 (三) 15:14 (UTC)
- (:)回應@羊羊32521:主模板已在2月10日由大貓修復,目前還有子模板410個待修,目 前 先 手 工 慢 慢 修,因為怕機器人會有例外;@Sunny00217: 也在今日稍早由大貓修復。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月12日 (五) 09:18 (UTC)
- 是的@BlackShadowG:,除了{{WPBannerMeta}},其他已經修改好的模板有{{Namespace detect}}、{{Namespace pagename}}、{{Namespace detect showall}}、{{Main talk other}}、{{Category handler}},然後{{Main other}}管理員還沒處理。如有缺漏還需協助指出。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月5日 (五) 13:51 (UTC)
等待管理员操作:除了Template:WikiProject Tree of Life、Template:WikiProject_Biography被全保護之外,已完成Template:WPBannerMeta相關模板(共410-2個)模板的修改(全數由人手工修改,少數由其他用戶修改已發出感謝。);另外Template:中國傳統聲音專題建立時就指向PJ:空間因此無須調整。剩餘部分等待Template_talk:WikiProject_Tree_of_Life#編輯請求 2021-02-14與Template_talk:WikiProject_Biography#編輯請求 2021-02-14被管理員接受後本討論就可以完成,屆時將進入下一階段的討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:07 (UTC)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
第五階段:討論重新導向與捷徑的設立方式[编辑]
各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 12:57 (UTC)
- 本案進入倒數第二個部分。現在將討論未來專題捷徑如何設立,以及原有捷徑的去留:
- 未來是否允許建立跨WP與PJ空間的捷徑?如果需要,是否需要進一步規範?
- 未來是否允許建立跨WP與PJ空間的非捷徑的重新導向?
- 舊有的跨WP與PJ空間的捷徑是否需要清除連入然後(×)删除?
- 請討論-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 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)
- 个人意见
- 为了避免混淆,将来应该一律禁止建立跨WP与PJ空间的捷径重定向。
- 目前存在的WP重定向到PJ的捷径应该全部转移到PJ,若无链入或很少链入,可考虑(×)删除;若数量过大,或者已经在讨论中被引用,则可考虑(○)保留以仅供历史参考。
- 同时,将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)
- 個人意見:
- 原則上不允許,但社羣就個別頁面的特殊情形可以例外特許。建議以修改R2規範處理。
- 不允許。如出現,應清除連入並刪除。
- 可行。清除連入可以請求bot(WP→PJ),刪除的話我覺得開一個list,然後轉AFD即可。
- 以上。SANMOSA SPQR 2021年2月17日 (三) 14:40 (UTC)
- Wikipedia:专题和Wikipedia:专题委员会等部分页面为何还没有移动到新的名字空间?还是这些页面不应该移动?--百無一用是書生 (☎) 2021年2月19日 (五) 02:46 (UTC)
- 個人認為跨WP->PJ沒差,但PJ->WP的不行-- Sunny00217 2021年2月21日 (日) 13:56 (UTC)
第五階段:小結[编辑]
總結以上討論意見:
- 禁止建立跨WP與PJ空間的捷徑重新導向。並清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向;同时,将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径,不再推荐使用以WP开头的捷径。→修改R2規範
- Wikipedia:專題和Wikipedia:專題委員會移動到PJ空間。→需探討是否留重定向
- 補:R2修改內容:
|
以上。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)
- (!)意見:“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)
- 另外我认为WP→PJ可能不适合速删,上方讨论有提到
- 查CSD历史,R2最初加入于Special:Diff/284065:
- @羊羊32521:(1)1是(條目命名空間)→(非條目命名空間),2是(非條目命名空間)→(條目命名空間),2不能刪。(2)完成。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)
“ | 若数量过大,或者已经在讨论中被引用,则可考虑(○)保留以仅供历史参考。 | ” |
——User:BlackShadowG |
第六階段:(暫不開放)[编辑]
各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:41 (UTC)
偽命名空間[编辑]
[編輯此導航模板]
|
本案討論格式手冊及長期破壞者提升問題。目前有三案:
- 格式手冊及長期破壞者提升為命名空間,英語名稱待定;
- 格式手冊及長期破壞者成為偽命名空間,縮寫為MOS及LTA;
- 維持現行方式。
請討論。臺灣杉在此發言 (會客室) 2020年12月25日 (五) 01:23 (UTC)
- (+)支持将格式手册和长期破坏者设立为伪名字空间,(-)傾向反對设立为名字空间,个人认为没有必要。--Yining Chen(留言|签名) 2020年12月26日 (六) 11:32 (UTC)
- (!)意見格式手冊(LTA:)及長期破壞者(MOS:)要升格成「真」命名空間可能比較困難,因為沒有別的維基百科分站、姊妹計畫、語言版本有啟用此設定,故技術細節無從參考,諸如Namespcae id(一個整數)也須討論,且還有數字id可能重複的問題。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年12月26日 (六) 12:59 (UTC)
- (+)支持成为伪命名空间。如果成为真·命名空间,我(+)傾向支持長期破壞者(LTA:),而不是格式手冊(MOS:) ——羊羊 (留言|贡献) 2020年12月26日 (六) 15:44 (UTC)
- 建議立為偽命名空間(方案2)。SANMOSA SPQR 2020年12月27日 (日) 07:32 (UTC)
- 支持提升為命名空間,因為會違反快速刪除方針的R2準則。 2020年12月28日 (一) 07:06 (UTC)
- 支持成為偽命名空間。命名空间涉及较多技术问题,未来如需求明显,可再议转换。--YFdyh000(留言) 2020年12月30日 (三) 13:01 (UTC)
- 如需要立為名字空間也並非不可,只是要決定其所使用的數字ID
- 0-99的命名空間ID要保留給維基媒體系統使用,故需要使用100以上的命名空間ID
- 下面整理許多語言版本維基百科的命名空間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)
- 如果要設立的話可能就120/121與122/123吧,或110/111、112/113與120/121、122/123選一組。如果要避免跟未來新功能重複,也可以使用150之後的數字比較保險。同時亦須留意擴展名字空間ID列表有沒有可能存在本地有機會引入的擴展。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月1日 (五) 08:07 (UTC)
- (~)補充剛才到gerrit.wikimedia.org看了一下,其列出的Recommended命名空間ID共有:
- 100 - Portal
- 102 - WikiProject
- 104 - Reference
- 114 - Translation
- (~)補充剛才到gerrit.wikimedia.org看了一下,其列出的Recommended命名空間ID共有:
- 如果要設立的話可能就120/121與122/123吧,或110/111、112/113與120/121、122/123選一組。如果要避免跟未來新功能重複,也可以使用150之後的數字比較保險。同時亦須留意擴展名字空間ID列表有沒有可能存在本地有機會引入的擴展。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月1日 (五) 08:07 (UTC)
- 以上補充。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 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)
- 小總結一下,包含#先前討論截至2021年1月1日 (五) 19:38 (UTC)之前,社群成員意見大致如下
- 支持MOS真:2 (空氣小貓 2020年12月28日 (一) 07:06 (UTC)、Sunny00217 2020年11月22日 (日) 12:26 (UTC))
- 反對MOS真:2 (Yining Chen 2020年12月26日 (六) 11:32 (UTC)、MilkyDefer 2020年12月31日 (四) 17:13 (UTC))
- 支持MOS偽:5 (LuciferianThomas 2020年12月31日 (四) 15:58 (UTC)、YFdyh000 2020年12月30日 (三) 13:01 (UTC)、SANMOSA 2020年12月27日 (日) 07:32 (UTC)、羊羊 2020年12月26日 (六) 15:44 (UTC)、Yining Chen 2020年12月26日 (六) 11:32 (UTC))
- 反對MOS偽:1 (cwek Wikipedia_talk:名字空间#開放偽命名空間作捷徑連結用)
- 支持LTA真:3 (空氣小貓 2020年12月28日 (一) 07:06 (UTC)、羊羊 2020年12月26日 (六) 15:44 (UTC)、Sunny00217 2020年11月22日 (日) 12:26 (UTC))
- 反對LTA真:1 (Yining Chen 2020年12月26日 (六) 11:32 (UTC))
- 支持LTA偽:5 (LuciferianThomas 2020年12月31日 (四) 15:58 (UTC)、YFdyh000 2020年12月30日 (三) 13:01 (UTC)、SANMOSA 2020年12月27日 (日) 07:32 (UTC)、羊羊 2020年12月26日 (六) 15:44 (UTC)、Yining Chen 2020年12月26日 (六) 11:32 (UTC))
- 反對LTA偽:1 (cwek Wikipedia_talk:名字空间#開放偽命名空間作捷徑連結用)
- (+)支持設立LTA偽命名空間,(+)傾向支持設立MOS偽命名空間,(-)反对設立任何命名空間。—— Eric Liu 創造は生命(留言.留名.學生會) 2021年1月2日 (六) 04:45 (UTC)
- 我想補充一個意見:我反對MOS及LTA設為真命名空間,僅支持MOS及LTA設為偽命名空間。SANMOSA SPQR 2021年1月2日 (六) 08:17 (UTC)
- 支持命名空間,反對偽命名空間。SmallTim(留言) 2021年1月5日 (二) 13:56 (UTC)
- 这整得跟投票一样,建议各位将(+)支持和(-)反对的理由写出来,逐一进行讨论,以此达到共识。毕竟投票不能代替讨论。 ——羊羊 (留言|贡献) 2021年1月5日 (二) 15:50 (UTC)
- 我建議直接排除成為真命名空間的可能性,這樣會產生維護問題。SANMOSA SPQR 2021年1月6日 (三) 06:10 (UTC)
- (?)疑問@Sanmosa:比方說哪方面的維護問題?數字ID跟擴展重複?(這個可以克服,頂多新擴展本站的Namespace id與其他語言版本或己妹計畫不同步而已);頁面內容維護?(我想不出甚麼樣的情況會不利於維護);跨語言連結?-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月6日 (三) 06:44 (UTC)
- (?)疑問:有多少此次提案涉及的LTA?--Yining Chen(留言|签名) 2021年1月7日 (四) 05:39 (UTC)
- 持续出没的破坏者/IP
- 持续出没的破坏者/TVB節目與廣東歌破壞者
- 持续出没的破坏者/User
- 持续出没的破坏者/User:123Aristotle
- 持续出没的破坏者/User:Adam Asrul
- 持续出没的破坏者/User:Albert20009
- 持续出没的破坏者/User:Allthingsgo
- 持续出没的破坏者/User:Andy5120
- 持续出没的破坏者/User:Awe123343
- 持续出没的破坏者/User:Cheungalex20010914
- 持续出没的破坏者/User:Chûng-koet
- 持续出没的破坏者/User:ColinPan1999
- 持续出没的破坏者/User:Copyangry7fcvc
- 持续出没的破坏者/User:Dragoon17cc
- 持续出没的破坏者/User:Everyinvain
- 持续出没的破坏者/User:Jessechi
- 持续出没的破坏者/User:LeonChow99
- 持续出没的破坏者/User:Lovehksingers
- 持续出没的破坏者/User:My Royal Young
- 持续出没的破坏者/User:Sidowpknbkhihj
- 持续出没的破坏者/User:Simon 1996
- 持续出没的破坏者/User:SiuMai
- 持续出没的破坏者/User:Tsiusing106
- 持续出没的破坏者/User:Wen Ng Ng
- 持续出没的破坏者/User:Why you are here
- 持续出没的破坏者/User:Xayahrainie43
- 持续出没的破坏者/User:Yuck
- 持续出没的破坏者/User:Πrate
- 持续出没的破坏者/User:ドラえ
- 持续出没的破坏者/User:使用
- 持续出没的破坏者/User:冏
- 持续出没的破坏者/User:千村狐免
- 持续出没的破坏者/User:坦帕灣光芒460
- 持续出没的破坏者/User:小麟
- 持续出没的破坏者/User:影武者
- 持续出没的破坏者/User:愛莎
- 持续出没的破坏者/User:祖祖祖
- 持续出没的破坏者/User:离心力青蛙
- 持续出没的破坏者/User:米記123
- 持续出没的破坏者/User:萬聖至尊
- 持续出没的破坏者/User:蘇俞安
- 持续出没的破坏者/User:雨琦的长颈鹿
- 持续出没的破坏者/User:韓導
- 持续出没的破坏者/User:黄冰楠
- 持续出没的破坏者/User:백돌
- 持续出没的破坏者/core
- 持续出没的破坏者/footer
- 持续出没的破坏者/header
- 持续出没的破坏者/原创研究破坏
- 持续出没的破坏者/台湾戏剧造假者
- 持续出没的破坏者/台湾铁路相关页面破坏
- 持续出没的破坏者/唱片公司破壞者
- 持续出没的破坏者/异体字转换破坏
- 持续出没的破坏者/数论和人瑞类条目破坏
- 持续出没的破坏者/日本相关条目破坏
- 持续出没的破坏者/深港地鐵破壞
- 持续出没的破坏者/紅字連結破壞
- 持续出没的破坏者/艺人条目破坏
- 持续出没的破坏者/親子節目破壞者
- 持续出没的破坏者/记录
- 持续出没的破坏者/记录/IP
- 持续出没的破坏者/记录/SpamBot
- 持续出没的破坏者/记录/User
- 持续出没的破坏者/记录/User:1abacada
- 持续出没的破坏者/记录/User:Acklbonboncat
- 持续出没的破坏者/记录/User:Amysze123
- 持续出没的破坏者/记录/User:Cwhsspgps
- 持续出没的破坏者/记录/User:Dsfsswec
- 持续出没的破坏者/记录/User:E123045413
- 持续出没的破坏者/记录/User:IHATEteletubbies!
- 持续出没的破坏者/记录/User:Janagewen
- 持续出没的破坏者/记录/User:Jumper3
- 持续出没的破坏者/记录/User:KO.2
- 持续出没的破坏者/记录/User:KellyMok
- 持续出没的破坏者/记录/User:Khaosmon
- 持续出没的破坏者/记录/User:Labstore
- 持续出没的破坏者/记录/User:Luke7956
- 持续出没的破坏者/记录/User:Makecat
- 持续出没的破坏者/记录/User:Mazoku
- 持续出没的破坏者/记录/User:Nonsense00
- 持续出没的破坏者/记录/User:RockLi
- 持续出没的破坏者/记录/User:Seedermaster
- 持续出没的破坏者/记录/User:Since soules
- 持续出没的破坏者/记录/User:Specialgood
- 持续出没的破坏者/记录/User:Tp61i6m42008
- 持续出没的破坏者/记录/User:Uyhji
- 持续出没的破坏者/记录/User:Wikinger
- 持续出没的破坏者/记录/User:Willy On Wheels
- 持续出没的破坏者/记录/User:Wong lowang
- 持续出没的破坏者/记录/User:Yaohua2000
- 持续出没的破坏者/记录/User:Zeuszc
- 持续出没的破坏者/记录/User:佛學
- 持续出没的破坏者/记录/User:兔子网
- 持续出没的破坏者/记录/User:十字军大屠杀
- 持续出没的破坏者/记录/User:南大就业与出国
- 持续出没的破坏者/记录/User:反神抄
- 持续出没的破坏者/记录/User:壮志满天涯
- 持续出没的破坏者/记录/User:壮志满天涯/en
- 持续出没的破坏者/记录/User:打倒中国
- 持续出没的破坏者/记录/User:权威专家们
- 持续出没的破坏者/记录/User:李煌老师
- 持续出没的破坏者/记录/User:林玟墨
- 持续出没的破坏者/记录/User:蕭抹布
- 持续出没的破坏者/记录/User:赵明毅
- 持续出没的破坏者/记录/User:逆襲的天邪鬼
- 持续出没的破坏者/记录/User:閻魔あい
- 持续出没的破坏者/记录/core
- 持续出没的破坏者/记录/“希斯潘诺”破坏
- 持续出没的破坏者/记录/中国铁路车次破坏
- 持续出没的破坏者/记录/代理IP机器人
- 持续出没的破坏者/记录/宣揚永久封禁支持台獨管理員破壞
- 持续出没的破坏者/记录/广州IP破坏
- 持续出没的破坏者/记录/朱明
- 持续出没的破坏者/记录/臺灣文學人物破壞者
- 持续出没的破坏者/记录/虚假学历破坏
- 持续出没的破坏者/记录/虚假英语条目
- 持续出没的破坏者/记录/衡阳IP破坏
- 持续出没的破坏者/记录/谥号破坏
- 持续出没的破坏者/记录/轨道交通破坏 (安徽省)
- 持续出没的破坏者/记录/轨道交通破坏 (广州市)
- 持续出没的破坏者/记录/韩语替换破坏
- 持续出没的破坏者/违法广告破坏
- 持续出没的破坏者/速删候选破坏者
- 持续出没的破坏者/重定向破坏者
- WP:Simon 1996(Wikipedia:持续出没的破坏者/Simon_1996)
- WP:ADAM、WP:AA(Wikipedia:持续出没的破坏者/User:Adam_Asrul)
- WP:ALEX、WP:CA0914(Wikipedia:持续出没的破坏者/User:Cheungalex20010914)
- WP:PXD、WP:PxdJulia、WP:CP1999、WP:CLP1999、WP:CLP、WP:ColinPan、WP:Colin Pan、WP:ColinPan1999(Wikipedia:持续出没的破坏者/User:ColinPan1999)
- WP:C7(Wikipedia:持续出没的破坏者/User:Copyangry7fcvc)
- WP:D17、WP:D17C、WP:DG17、WP:DG17C、WP:d17、WP:d17c、WP:dg17、WP:dg17c、WP:Dragoon17cc、WP:dragoon17cc、WP:D17CC、WP:d17cc、WP:龍17、WP:龍17C、WP:龍17c(Wikipedia:持续出没的破坏者/User:Dragoon17cc)
- WP:EIV(Wikipedia:持续出没的破坏者/User:Everyinvain)
- WP:JC、WP:Jessichi(Wikipedia:持续出没的破坏者/User:Jessechi)
- WP:LeonChow99、WP:LC99(Wikipedia:持续出没的破坏者/User:LeonChow99)
- WP:LHKS、WP:Lovehongkongsingers(Wikipedia:持续出没的破坏者/User:Lovehksingers)
- WP:MRY、WP:My Royal Young(Wikipedia:持续出没的破坏者/User:My_Royal_Young)
- WP:SM、WP:SiuMai、WP:燒賣(Wikipedia:持续出没的破坏者/User:SiuMai)
- WP:TS106、WP:2GFRIENDTWICE、WP:3GFRIENDSNSD(Wikipedia:持续出没的破坏者/User:Tsiusing106)
- WP:X43(Wikipedia:持续出没的破坏者/User:Xayahrainie43)
- WP:YUCK(Wikipedia:持续出没的破坏者/User:Yuck)
- WP:PIRATE、WP:百楽兎、WP:Prate(Wikipedia:持续出没的破坏者/User:Πrate)
- WP:ドラえ、WP:DORAE(Wikipedia:持续出没的破坏者/User:ドラえ)
- WP:JIONG、WP:冏(Wikipedia:持续出没的破坏者/User:冏)
- WP:坦帕灣光芒460、WP:坦帕湾、WP:TPWGM460、WP:TPW(Wikipedia:持续出没的破坏者/User:坦帕灣光芒460)
- WP:XL、WP:小麟(Wikipedia:持续出没的破坏者/User:小麟)
- WP:KAGE、WP:影武者(Wikipedia:持续出没的破坏者/User:影武者)
- WP:愛莎(Wikipedia:持续出没的破坏者/User:愛莎)
- WP:祖祖祖、WP:祖X3、WP:祖3、WP:祖³(Wikipedia:持续出没的破坏者/User:祖祖祖)
- WP:米記123、WP:MJ123(Wikipedia:持续出没的破坏者/User:米記123)
- WP:蘇俞安、WP:110.29、WP:SYA(Wikipedia:持续出没的破坏者/User:蘇俞安)
- WP:韓導(Wikipedia:持续出没的破坏者/User:韓導)
- WP:HBN、WP:黄冰楠、WP:冰楠(Wikipedia:持续出没的破坏者/User:黄冰楠)
- WP:BAEG、WP:BAEGDOL(Wikipedia:持续出没的破坏者/User:백돌)
- WP:破坏者使用、WP:SY(Wikipedia:持续出没的破坏者/User:使用)
- WP:小昌、WP:徐昌佑(Wikipedia:持续出没的破坏者/台湾戏剧造假者)
- WP:111.252、WP:Shi0978631898(Wikipedia:持续出没的破坏者/台湾铁路相关页面破坏)
- WP:114.27、WP:R1t5、WP:人瑞(Wikipedia:持续出没的破坏者/数论和人瑞类条目破坏)
- WP:一刀切、WP:1DQ(Wikipedia:持续出没的破坏者/紅字連結破壞)
- WP:42.61(Wikipedia:持续出没的破坏者/艺人条目破坏)
- WP:親子節目破壞者(Wikipedia:持续出没的破坏者/親子節目破壞者)
以上。--LuciferianThomas.留言 2021年1月8日 (五) 02:01 (UTC)
- 把LTA设置成名字空间的一个效果是可以设置所有页面为noindex(包括少数不使用LTA模板的子页),虽然社群要评估一下这么做的价值。--GZWDer(留言) 2021年1月10日 (日) 14:42 (UTC)
小结2[编辑]
标题添加: ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)
@A2569875、Taiwania 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)
- 山不轉路轉、路不轉人轉。大可以將所有判斷名字空間的模板在判斷前先匹配偽名字空間表再做進一步輸出,看不出有什麼問題,很多語言版本維基都有它自己的「本地特化」。 對於傾向支持偽名字空間(當然如可能我還是希望名字空間啦,但基金會那邊不一定會買單,你看編輯審核保護和Book:名字空間工單提那麼久還在「神秘的技術問題擱置」就知道有多難,何況其他語言版本沒有先例)對於傾向支持偽名字空間的立場者來說,當然會提出傾向於去符合對偽名字空間有利的方案去做提議。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月17日 (日) 14:38 (UTC)
- @A2569875:您應該明白我的重點不在這裡吧。-- 2021年1月17日 (日) 14:20 (UTC)
- 不認為以上問題是問題,模板模組加個if-else或switch case在本地特化的名字空間便是模板/模組不就好了,況且現在有不少的名字空間判斷都不是直接引用魔術字,是使用中介模板例如{{Namespace_detect}},在裡面補充if-else或switch case不就好了,先前討論早就提議了「建立允許不快速刪除的偽名字空間列表」,難道列表只能列在指引哩,不能寫在程式裡??;關於介面是同理,將是偽名字空間的頁面改掉顯示名稱不就得了?技術上到底是有甚麼障礙,我看不出,有障礙的分明是「你不想」吧,例如下方列舉的程式碼片段:
- 在模板裡面放if else不就好了。Module亦然。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月12日 (二) 18:07 (UTC)
(~)補充,你可以到諸如 [[MOS:001]] 的頁面,在瀏覽器Console模式下執行以下代碼,就可以看到介面顯示不再是「條目」。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月19日 (二) 07:20 (UTC)
var pseudoNS_list={
MOS:wgULS('格式手册','格式手冊'),
LTA:wgULS('持续出没的破坏者','持續出沒的破壞者'),
SC:wgULS('捷径','捷徑'),
/*這是DEMO,正式使用時請移除*/WIKIPEDIA:'Demo',
};
var ns=(function(test){return test.length>1?test[0]:''})(mw.config.get('wgPageName').replace(/[_\s]talk/i,'').replace(/talk:/i,'').split(':'));
var newregexp=function(test){return new RegExp(test.replace(/[-[\]{}()*+?.,\\^$|#\s]/g, "\\$&"),'ig')};
if(pseudoNS_list.hasOwnProperty(ns.toUpperCase())){
var nstab=$('.vector-menu-content-list>li').filter(function(){return this.id.match(/nstab/i);});
nstab.html(nstab.html().replace(newregexp(nstab.text()),pseudoNS_list[ns.toUpperCase()]));
}
- 或者
var newregexp=(test=>new RegExp(test.replace(/[-[\]{}()*+?.,\\^$|#\s]/g, "\\$&"),'ig'));
((ns_name,ns_tab,ns_list)=>ns_list.hasOwnProperty(ns_name)?ns_tab.html(ns_tab.html().replace(newregexp(ns_tab.text()),ns_list[ns_name])):null)(
(test=>test.length>1?test[0]:'')(mw.config.get('wgPageName').replace(/[_\s]talk/i,'').replace(/talk:/i,'').split(':')).toUpperCase(),
$('.vector-menu-content-list>li').filter(function(){return this.id.match(/nstab/i);}),
{
MOS:wgULS('格式手册','格式手冊'),
LTA:wgULS('持续出没的破坏者','持續出沒的破壞者'),
SC:wgULS('捷径','捷徑'),
/*這是DEMO,正式使用時請移除*/WIKIPEDIA:'Demo',
}
)
- 在偽命名空間部分,我是以「有需求」為前提,如果共識認為不需設立或不能設立,那就是維持原案,也就沒有需要修方針的問題。--臺灣杉在此發言 (會客室) 2021年1月13日 (三) 02:58 (UTC)
- 而以現時討論而言主流意見為將MOS和LTA設為偽命名空間。--LuciferianThomas.留言 2021年1月13日 (三) 05:16 (UTC)
- @LuciferianThomas:影響的範圍較大,即使有主流共識,目前討論的參與者人數並不能代表整個社群。 2021年1月17日 (日) 14:17 (UTC)
- 而以現時討論而言主流意見為將MOS和LTA設為偽命名空間。--LuciferianThomas.留言 2021年1月13日 (三) 05:16 (UTC)
- 个人认为,如果长期破坏者(LTA)有成为名字空间的潜力的话,应该此时直接升级成为名字空间。不然,如果之后再讨论升级为名字空间,所有带LTA:前缀的页面还要重新移动一遍。 ——羊羊 (留言|贡献) 2021年1月15日 (五) 12:04 (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年1月19日 (二) 05:21 (UTC)
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
- 大家普遍對於建立新名字空間「頁面不夠不足以獨立名字空間」、「獨立名字空間指引會分散兩地」.....、又不想占用其他名字空間,或不想看到介面顯示為「條目」....又有許多意見想解決名稱衝突問題......這也太困難(好似:又要馬兒肥、又要馬兒不吃草)。(&)建議乾脆定義一個「捷徑」名字空間「Shortcut:」好了。然後找一個簡短的文字當作名字空間別名,例如「Link」的「L」,然後捷徑變成「L:MOS:XX」、「L:LTA:XX」之類的,這樣既不會占用其他名字空間造成命名衝突,介面也不會顯示為「條目|條目討論」會顯示為「捷徑|捷徑討論」;也不必擔心頁面太少不足以獨立成名字空間:因為它整合了MOS、LTA等;也不會導致指引分散兩地;也不會佔用到其他名字空間;也不會有名稱衝突。(為了整合所有反對意見所產生的奇異提案。)-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月17日 (日) 09:29 (UTC)
- 剛才小研究一下英文維基的偽名字空間,真的有許多詭異的偽名字空間捷徑,除了MOS:外,例如「MP:」連接首頁上不同區域的章節捷徑。。。如果社群傾向不跟隨英文維基也是可以搞一個本地特色的名字空間。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月17日 (日) 10:29 (UTC)
- 但此會造成混亂,因為WP:VIP之類的捷徑卻不在捷徑空間,但也同時沒有理由改為L:WP:VIP。--LuciferianThomas.留言 2021年1月18日 (一) 02:08 (UTC)
- WP開頭的捷徑當然是留在WP空間;現在是要解決跨空間問題吧。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月18日 (一) 07:32 (UTC)
- (:)回應@LuciferianThomas:我想到辦法了,一樣是捷徑名字空間,然後將LTA與MOS都設定為這個名字空間的別名,這樣就能建立MOS:XX、LTA:XX也不會佔用到任何其他名字空間。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月19日 (二) 05:32 (UTC)
- 還有一個盲點,要說跨空間,老實那句,這命名空間的重定向也是跨命名空間,還是要修訂R2。--LuciferianThomas.留言 2021年1月19日 (二) 07:34 (UTC)
- @A2569875:撤回議案…?--LuciferianThomas.留言 2021年1月20日 (三) 00:20 (UTC)
- WP開頭的捷徑當然是留在WP空間;現在是要解決跨空間問題吧。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月18日 (一) 07:32 (UTC)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
小結3[编辑]
- 我的意見是,如果偽命名空間不會造成「系統性」的重大問題,就可以納入考量。例如佔用其他命名空間、習慣性等等問題,在我眼中看來不是重大系統問題,而且可以透過其他技術手段解決(如上所述)。--臺灣杉在此發言 (會客室) 2021年1月18日 (一) 10:16 (UTC)
- “顯示為‘條目|條目討論’”是指重定向页吗?我觉得重定向页显示条目没什么大问题() ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:07 (UTC)
- 見ナナチ上方的留言,當中有說明可在MediaWiki:Common.js加一段代碼讓偽命名空間不顯示「條目」。--LuciferianThomas.留言 2021年1月19日 (二) 07:50 (UTC)
- (:)回應@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空间[编辑]
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
经过上方的讨论,我认为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)
- 我覺得可以,但目前名字空間的申請正在排隊(需插入程式碼到\mediawiki-config\wmf-config\InitialiseSettings.php ,且如有頁面權限問題或要不要NOINDEX問題需要額外調整$wgNamespacesToBeSearchedDefault、$wgNamespaceRobotPolicies等其他數值,如需要對IP用戶和新用戶隱藏,可能還需要mw:Extension:Lockdown),因此,如需設立可能還需要等待數周。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月25日 (一) 06:29 (UTC)
- 本議案可能須分階段討論,要討論的項目有:
- 是否需要默認關閉LTA頁面的Special:搜索?(mw:Manual:$wgNamespacesToBeSearchedDefault設定)
- 是否需防止LTA頁面被機器人或網路爬蟲索引?(mw:Manual:$wgNamespaceRobotPolicies設定)
- 是否需設定LTA頁面的檢視權限?(例如,只有自動確認用戶、巡查員、回退員、管理員能檢視/訪問這些頁面,需引入mw:Extension:Lockdown)
- 根据之前的一些Task維基媒体不会启用mw:Extension:Lockdown。但是如果只是为了避免WP:BEANS而没有保密需求那么用CSS屏蔽掉内容显示即可。--GZWDer(留言) 2021年1月27日 (三) 11:58 (UTC)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
偽命名空間相關方針及WP:捷徑修正[编辑]
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
本討論已近一個月,得到的回饋有:
- 主流意見認為格式手冊及長期破壞者(持續出沒的破壞者)宜設立偽命名空間;
- 已有技術手段可分出偽命名空間與主命名空間的差異性;
- 設立偽命名空間無重大系統性問題,且部署容易,不牽涉到基金會層面之程式修改。
由此,偽命名空間將會在上段討論開始一個月後進行公示(也沒過幾天),而相關規範也將儘速修正或設立,下列針對快速刪除方針R2進行修正,及將WP:捷徑中的偽命名空間部分做為指引。下列為R2修正提案。
捷徑中偽命名空間的規範詳見這裡。
請討論。臺灣杉在此發言 (會客室) 2021年1月20日 (三) 06:53 (UTC)
- 同意提案。SANMOSA SPQR 2021年1月20日 (三) 08:10 (UTC)
- (+)贊成R2修正案,另就WP:捷徑,我看了一遍,似乎要整個重新整理過。--LuciferianThomas.留言 2021年1月20日 (三) 10:04 (UTC)
- (+)支持WP:CSD修正案與偽名字空間。我原本是支持名字空間的,但經歷了上述討論以及主持了專題名字空間的設立,我發現偽名字空間是有許多優點的。先看名字空間,名字空間是需要「安裝」的,本地獲得共識之後要等待工程師安裝,期間從數周到數月不等,且不具備可擴充性,即每新增一個名字空間都要請工程師協助,本地管理員、介面管理員、模組編輯員都無能為力,只有基金會工程師可以執行,「真名字空間」可擴充性不佳。我們來看看「偽名字空間」,它「免安裝」耶,隨加即用,涉及命名空間判斷的本地模板與模組本地的管理員、介面管理員、模組編輯員都能即時加入,也不必等待工程師安裝,「偽名字空間」可擴充性十分良好。假如今天社群需要一個新的捷徑前綴或字首,真名字空間需要等待工程師安裝,而偽名字空間公示通過後就能隨加即用,是多麼的方便,然而要實現此需要修正WP:CSD#R2,正如臺灣杉在此發言 (會客室)所言:「如果偽命名空間不會造成「系統性」的重大問題,就可以納入考量。」,參見#宇帆於2021年1月19日 (二) 07:16 (UTC)之發言,未見要修正WP:CSD#R2會出現什麼系統性問題,故此(+)支持WP:CSD修正案。以上-- 來人啊,餵宮子吃布丁! ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月21日 (四) 08:06 (UTC)
- 想向諸位確認一下@A2569875、Taiwania 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)
- 順序是上面的MOS、LTA先公示完畢,本案才會接著進行公示。於此期間兩邊同步討論。--臺灣杉在此發言 (會客室) 2021年1月22日 (五) 15:05 (UTC)
本討論超過一個月,且偽命名空間之相關技術問題已得到解決,且主流意見認為有設置必要,現就偽命名空間、R2及WP:捷徑內的偽命名空間規範 公示7日,2021年1月31日 (日) 02:51 (UTC) 結束。臺灣杉在此發言 (會客室) 2021年1月24日 (日) 02:51 (UTC)
- @Taiwania Justo、LuciferianThomas:啟用偽命名空間能解決什麼問題?我相信這是提案必須討論的重點,我需要有人能回答這個問題。如果沒辦法解決什麼問題,我認為維持現狀即可,也就是WP足矣。然而,就我查看整個討論,似乎都是討論命名空間真偽的可行性,只有幾個留言有提到這個問題。 2021年1月29日 (五) 04:57 (UTC)
- 看來你是沒有看到最初的討論,見本章節頂端討論導航最初的討論,已經是說明了偽命名空間的作用為讓捷徑意義更加清晰且減少可能構成重複的捷徑名稱的情況。現在不是解決問題的情況,而是優化社群討論和表達的問題了。--LuciferianThomas.留言 2021年1月29日 (五) 05:01 (UTC)
- 一直以來捷徑都沒有什麼規範,尤其是格式手冊、維基專題及LTA的頁面重定向,表達不清之餘容易造成混亂,偽命名空間就是讓這些項目的捷徑統一化,方便社群溝通。--LuciferianThomas.留言 2021年1月29日 (五) 05:04 (UTC)
- 例子:MOS:BOLD較WP:MOSBOLD簡潔,但連結至格式手冊的捷徑沒有規範導致格式混亂難以維護,有些有WP:MOS字首有些沒有;而LTA更甚,捷徑完全沒有要表達連結目標為LTA頁面的意思。相對於WP:LTA/HBN,使用偽命名空間概念的LTA:HBN更簡潔易明。在解決捷徑的問題的同時順便推動在其他維基項目運行暢順的偽命名空間比較合適。--LuciferianThomas.留言 2021年1月29日 (五) 05:13 (UTC)
- @LuciferianThomas:真是抱歉,我沒有一直關注這個提案,突然要找相關討論也找不到。既然如此,我沒意見了。-- 2021年1月29日 (五) 14:02 (UTC)
- 例子:MOS:BOLD較WP:MOSBOLD簡潔,但連結至格式手冊的捷徑沒有規範導致格式混亂難以維護,有些有WP:MOS字首有些沒有;而LTA更甚,捷徑完全沒有要表達連結目標為LTA頁面的意思。相對於WP:LTA/HBN,使用偽命名空間概念的LTA:HBN更簡潔易明。在解決捷徑的問題的同時順便推動在其他維基項目運行暢順的偽命名空間比較合適。--LuciferianThomas.留言 2021年1月29日 (五) 05:13 (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)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
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)
軟重定向[编辑]
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
原有的捷徑可否改為軟重定向並作出提示「此捷徑已移動至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)
- 不必更動,英語維基百科部分MOS也有用WP的捷徑。--臺灣杉在此發言 (會客室) 2021年1月31日 (日) 04:32 (UTC)
- 或是透過JS小工具提示功能,讓用戶在非討論頁面中點擊舊有連結時提示修改為新連結?--LuciferianThomas.留言 2021年1月31日 (日) 04:23 (UTC)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
技術問題處理[编辑]
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
命名空間偵測模板以及MediaWiki:Common.js(見此處)需要提編輯請求,以令偽命名空間生效。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月31日 (日) 05:30 (UTC)
- 小補充:偽命名空間捷徑可用{{捷徑重定向}}標記,已加入自動偵測偽命名空間顯示偽命名空間簡單說明。--LuciferianThomas.留言 2021年2月2日 (二) 05:55 (UTC)
- 另外@A2569875:已創建MOS:、MOS:MOS、MOS:手冊、MOS:格式手冊供你們測試各項技術問題。--LuciferianThomas.留言 2021年2月2日 (二) 05:59 (UTC)
- 根據Wikipedia:保護方針#需进行公示,即使偽命名空間已獲得社群共識,輕微影響外觀顯示的編輯仍需公示七日,因為未添加亦不會影響偽命名空間的運作。-- 2021年2月2日 (二) 06:29 (UTC)
- @LuciferianThomas。-- 2021年2月2日 (二) 06:34 (UTC)
- @LuciferianThomas、Pseudo Classes:還不能公示,因為討論仍在進行中MediaWiki_talk:Common.js#編輯請求_2021-01-31。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月2日 (二) 06:39 (UTC)
- 不影響運作,他可以使用個人JS頁面進行測試,只是這個意思。而提及重定向模板純粹因為這個章節叫做「技術問題處理」,沒有其他地方方便提及就在這裏說而已。--LuciferianThomas.留言 2021年2月2日 (二) 07:22 (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)
- @LuciferianThomas:依照您這個說法,難道模板編輯員和管理員對模板重大更新,都不用提交編輯請求?此外,半保護並不是只有防止破壞,其亦屬於高風險模板。-- 2021年2月2日 (二) 12:17 (UTC)
- 自動確認用戶編輯非編輯爭議的半保護頁面也要提出編輯請求是什麼說法?那麼怎麼不直接模板保護?--LuciferianThomas.留言 2021年2月2日 (二) 12:01 (UTC)
- 當初本議案一堆人以「介面會顯示[條目]」為由異議,後來是提出了「修改MediaWiki:Common.js解決問題」排除異議,而使得異議排除通過議案,那如果現在不設置不就變成「異議沒有排除」?反對這種花式推翻議案的作法。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月2日 (二) 12:01 (UTC)
- (已站外解釋,宇帆似乎誤解了我們上面說公示和編輯保護模板的事情。)另外想說此處之前對有關JS編碼的支持意見可視為對於「同意作出這樣更改」的意見嗎?--LuciferianThomas.留言 2021年2月2日 (二) 12:48 (UTC)
- 建立預設啟用/默認啟用的小工具來呈現偽名字空間介面
- 上述有些意見(含MediaWiki_talk:Common.js#編輯請求_2021-01-31的留言)認為小工具有利於維護;而U:AnYiLin已將代碼整改為可用於小工具的格式(這則留言)。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月2日 (二) 16:20 (UTC)
- 还有个小建议:当处于移动视图时,不必在minerva皮肤的页面标题(脚本里的tips_selector)处添加提示,因为在触控设备上没办法看到鼠标悬停才有的提示,反而被加了下划线,感觉不太美观。--安忆Talk 2021年2月2日 (二) 16:31 (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)
- @LuciferianThomas:修改介面?那不就又回到獨立成新的命名空間了嗎?(技術問題還少些)-- Sunny00217 2021年2月4日 (四) 08:47 (UTC)
- (~)補充:亦支持直接修改介面,這真的視乎最終選擇。--LuciferianThomas.留言 2021年2月3日 (三) 08:53 (UTC)
小工具執行結果 以頁面[[MOS:MOS]]為例 設定為繁體中文(以zh-tw為例) 設定為簡體中文(以zh-cn為例)
- 提供目前版本小工具運行結果圖,供公示參考用。右上角的連結為Wikipedia:偽名字空間用於說明,如有缺漏歡迎改善。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月3日 (三) 19:03 (UTC)
- @A2569875:等等等一下,這版在像是Mos:$1沒有大寫的也會執行耶,,,-- Sunny00217 2021年2月4日 (四) 08:45 (UTC)
- (:)回應@Sunny00217:那就不要toUpperCase()了。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月4日 (四) 08:51 (UTC)
- (※)注意:為免混淆WP:偽名字空間原有內容移動至WP:PNS+,並改為指向WP:捷徑#偽命名空間使其等價WP:偽命名空間的重定向。--LuciferianThomas.留言 2021年2月5日 (五) 06:21 (UTC)
- (?)疑問@LuciferianThomas:所以「
偽名字空間」(
[[WP:偽名字空間|偽名字空間]]
)要改成什麼?-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月5日 (五) 06:46 (UTC)- 維基百科:偽命名空間輔助說明(捷徑WP:PNS+)--LuciferianThomas.留言 2021年2月5日 (五) 08:10 (UTC)
- BTW在問號圖案後加個空格唄,貼著很醜…--LuciferianThomas.留言 2021年2月5日 (五) 08:13 (UTC)
完成:Special:Diff/64147054。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月6日 (六) 14:00 (UTC)
- @LuciferianThomas:還有其他疑問嗎?若沒有我就要公示囉?@AnYiLin:高風險模板/介面編輯請求的公示確定不必放公告欄嗎?-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月7日 (日) 04:07 (UTC)
- 支持啟動公示。--LuciferianThomas.留言 2021年2月7日 (日) 04:37 (UTC)
- 在此公示吧,这个修改只是配合伪名称空间的使用,后者已经公示过了。我刚刚也再次读了一遍保护方针,没理解错的话其只要求在对受保护的模板和模块进行一些更改时需要达成共识/进行公示。
- 此小工具会默认开启并在参数设置处隐藏,避免用户误操作关闭(达到和直接放进common.js同样的效果)。--安忆Talk 2021年2月7日 (日) 04:46 (UTC)
- (?)疑問@LuciferianThomas:所以「
公示7日:現交付公示,公示詳細資訊如下:
小工具原始碼 User:A2569875/pseudonamespace_UI.js(WP:CSD#O1)→MediaWiki:Gadget-pseudonamespace-UI.js
(公示完畢後會使用「移動不留重新導向」功能移動到MediaWiki:Gadget-空間)小工具執行結果 以頁面[[MOS:MOS]]為例 設定為繁體中文 設定為簡體中文
- 如期內無合理異議則全站套用此修改。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月8日 (一) 05:56 (UTC)
- 公示通過了,@A2569875、AnYiLin。--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)
- @LuciferianThomas:被User:Jon_(WMF)刪掉了Special:Diff/64319519....說甚麼有東西undefined,看半天沒看出原因,至少我這邊所有裝置測試都沒出問題。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月16日 (二) 06:40 (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)
提議設立快速刪除標準 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)
- @LuciferianThomas:名從主人,這就是有使用者擔憂會佔用主空間條目名的情況,也有像en:Gadget:Invention, Travel, & Adventure類似的情況。-- 2021年2月2日 (二) 06:04 (UTC)
- 未見命名常規有不能用全形冒號的規則。若以與事物本身名稱不同說違反常規,可按照其他命名技術限制做法,不加冒號或改用全形冒號,並以{{Wrongtitle}}標記即可。--LuciferianThomas.留言 2021年2月2日 (二) 05:52 (UTC)
- @LuciferianThomas:使用全形冒號,極有可能違反命名常規。-- 2021年2月2日 (二) 05:46 (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)
- 若果明顯屬於錯誤建立有關專題頁面的當然可以移動,這裡應該是指創建與該專題無關的頁面。--LuciferianThomas.留言 2021年2月2日 (二) 06:01 (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)
- 有啊,專題的條目指引有幾條跟隨專題搬過去了。列表有寫。也有疑似專題移了但分頁未移的
- 還有這種事?!-- Sunny00217 2021年2月3日 (三) 09:18 (UTC)
- 呃忘了有幾條MOS在PJ空間。--LuciferianThomas.留言 2021年2月3日 (三) 08:48 (UTC)
- 加了附加條件之後讓我覺得這個準則永遠不會被使用,無論是什麼內容都應該根據內容來移動到新名稱,若是破壞也可用現存的G3等刪除。--Xiplus#Talk 2021年2月3日 (三) 13:59 (UTC)
- 「快速刪除方針的應用有時並不限於快速刪除本身」如無異議將在適當的時間進行公示。-- 五歲抬頭雪菲(☎️·☘️) 2021年4月7日 (三) 06:24 (UTC)
公示7日-- 五歲抬頭雪菲(☎️·☘️) 2021年4月14日 (三) 03:34 (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)
- @羊羊32521、YFdyh000:看來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)
- (?)疑問:改这个是否可行?--安忆Talk 2021年3月3日 (三) 15:13 (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)
WP:捷徑指引草案修訂[编辑]
[編輯此導航模板]
|
說明[编辑]
捷徑指引草案的討論,源自於「偽命名空間」的討論,英語維基百科對於捷徑相關的規範及偽命名空間的設立已有成熟的執行方式。中文維基百科中的部分編輯者對於「格式手冊」、「長期破壞者」及「專題」這三個主題提出可升級成命名空間或以偽命名空間形式存在,並有正反兩方的陳述與看法。
目前較為接近共識的是「專題」提升為正式命名空間,反對者的論述已由支持者回應,且反方無進一步論述。然為求慎重,且將捷徑與命名空間等議題作系統性討論,將會執行階段修訂,以取得最大共識。
本討論的各階段分為:
專題提升為命名空間與否及其細節(phab:T271612);格式手冊及長期破壞者是否成為命名空間或偽命名空間;偽命名空間規範寫入捷徑規範內(如前項通過)或是否允許偽命名空間(如前項不通過);- 捷徑規範細部討論並決定是否成為指引。
各階段不得同時討論,前一項討論完結之後,才能進行下一段討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)
專題命名空間問題[编辑]
格式手冊及長期破壞者命名空間問題[编辑]
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
已移動至偽命名空間。臺灣杉在此發言 (會客室) 2021年2月1日 (一) 03:47 (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)
- (:)回應Wikipedia:互助客栈/方针#第五階段:討論重新導向與捷徑的設立方式討論已開始。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:51 (UTC)
有關某年代相關分類命名統一事宜[编辑]
最近Jarodalien對某年代相關分類進行了大規模的重新命名工作(將“XXXX年代”重新命名為“YY世紀YY年代”、將“建立”重新命名為“創立”),並聲稱其理由為“先到先得”,然而“先到先得”並不適用於非條目頁面。我曾就部分分類的擬議重新命名(移動請求)進行反對,然而被其無視,其不但無視反對意見照樣進行移動操作,更反過來誣指我取消重新命名的操作為“破壞”,更牽連到其他本與相關移動請求不相關的分類。在其進行大規模的重新命名工作後,我收到部分用戶反映其重新命名工作導致部分由模板自動產生的分類出錯,可見其大規模的重新命名工作輕率且窒礙模板維護,構成破壞。請管理員盡快回退其移動操作,並以一切可行的辦法阻止其繼續進行相關破壞性移動。SANMOSA 誓山海而長在,似日月而無休 2021年2月25日 (四) 10:54 (UTC)
- @AT。SANMOSA 誓山海而長在,似日月而無休 2021年2月25日 (四) 10:54 (UTC)
- @Iokseng。SANMOSA 誓山海而長在,似日月而無休 2021年2月25日 (四) 10:56 (UTC)
- 正在回退一部分他移動過的分類,但數量有點多,我移不完。SANMOSA 誓山海而長在,似日月而無休 2021年2月25日 (四) 12:16 (UTC)
- ?什么意思?是说只允许别的用户把本来是叫“XX世纪XX年代”的分类移动成“XXXX年代”,不允许反过来吗?就像Category:1910年代美国罪案本来是20世纪10年代美国罪案等等。既然先到先得不适用分类,那么为什么不能够移动?为什么“埃及定居地”不对只能移动到“埃及聚居地”,“非洲各国定居点”不行要移动到繁体的“非洲各國聚居地”?--7(留言) 2021年2月25日 (四) 12:48 (UTC)
- 根据民智,19世纪50年代可能会被误认为是1950年代,这类移动没有必要。不过有些词,比如建立出版物,成立音乐团体,创建教育机构,不说合不合适,至少是不是可以讨论讨论拿个统一的方案。->>Vocal&Guitar->>留言 2021年2月25日 (四) 13:11 (UTC)
- 如果有人觉得“19世纪50年代”是“1950年代”,这个人一定不懂汉语。懂汉语的人不需要考虑不懂汉语的人会有什么误解。--7(留言) 2021年2月25日 (四) 13:13 (UTC)
- 我有印象先前有類似的討論,當時的意見好像是“1950年代”這樣的表述比較省,不過我沒記得是哪年在哪的討論。既然音樂條目都開了命名討論,關於是否統一年代表示,再開一個討論又不會怎麼樣。 --無心*插柳*柳橙汁 2021年2月25日 (四) 14:48 (UTC)
- 這個討論是Wikipedia:命名常规/有关“20世纪80年代”的写法的问题。 紺野夢人 恭賀新春 2021年2月25日 (四) 16:25 (UTC)
- 我不同意「這個人一定不懂漢語」的論斷,一時看得較快看錯了所導致的誤認是非常正常的事情。就此例而言,這是前述情況最為經典的例子。SANMOSA 誓山海而長在,似日月而無休 2021年2月25日 (四) 15:42 (UTC)
- 这是认知不广泛的“常识”(就像公元1年到公元前1年之间有几年,不一定有过半数人答对),有更清楚且简洁表达的情况下不应该改成更模糊、更容易出错的。--YFdyh000(留言) 2021年2月25日 (四) 16:00 (UTC)
- 我有印象先前有類似的討論,當時的意見好像是“1950年代”這樣的表述比較省,不過我沒記得是哪年在哪的討論。既然音樂條目都開了命名討論,關於是否統一年代表示,再開一個討論又不會怎麼樣。 --無心*插柳*柳橙汁 2021年2月25日 (四) 14:48 (UTC)
- 如果有人觉得“19世纪50年代”是“1950年代”,这个人一定不懂汉语。懂汉语的人不需要考虑不懂汉语的人会有什么误解。--7(留言) 2021年2月25日 (四) 13:13 (UTC)
- @Jarodalien:無論如何,你進行的重新命名工作導致部分由模板自動產生的分類出錯這一點是無庸置疑的,我認為你應該將先前所建立和重新命名的分類(包括但不限於某年代相關分類,我認為其他相關分類很可能也有同樣情形)全部統一回模板自動產生的格式,否則這無庸置疑會嚴重影響模板維護工作。SANMOSA 誓山海而長在,似日月而無休 2021年2月25日 (四) 15:42 (UTC)
- 為免後患,我建議就各類頁面(包括但不限於分類頁)引入「命名一致性」的規定,以有效減少頁面命名上的紛爭,並便利維護。SANMOSA 誓山海而長在,似日月而無休 2021年2月25日 (四) 15:56 (UTC)
- 支持這個提議,而且可以把「年代分類」當作首要討論對象,未來可以擴及其他分類原則。我支持“1950年代”這個寫法,理由如下:
- 此次討論顯示“19世纪50年代”這個用法確實容易導致誤判。
- “1950年代”寫法較為簡潔。
- 分類與主條目名稱統一對讀者來說最為便利,按照年代列表目前所有年代主條目都是採取“1950年代”這個寫法。
- User:Sanmosa在上方已提及的分類維護問題。--迴廊彼端(留言) 2021年3月6日 (六) 03:10 (UTC)
- 支持這個提議,而且可以把「年代分類」當作首要討論對象,未來可以擴及其他分類原則。我支持“1950年代”這個寫法,理由如下:
- 認真?“19世纪50年代”相等於“1850年代”,“20世纪50年代”才相等於“1950年代”。-游蛇脫殼/克勞棣 2021年2月26日 (五) 14:16 (UTC)
- @Temp3600:想一下2000年是几世纪,称多少年代。以及Category:2000年代怎么整。--YFdyh000(留言) 2021年2月26日 (五) 14:20 (UTC)
- 似乎2000年是20世紀90年代(1991至2000年)的最後一年,以及2000年代(2000至2009年)的第一年⋯⋯像1世紀是1至100年,21世紀是2001年至2100年;而X世紀00年代是這個世紀的第一個十年。所以21世紀00年代是2001年至2010年,和2000年代嚴格來說還不是一個東西?PS:「21世紀00年代」和「21世紀10年代」怎麼讀?「二十一世紀零十年代」「二十一世紀一十年代」?--洛普利宁 2021年2月26日 (五) 15:10 (UTC)
- 这,尴尬了,我记成21世纪了
捂脸--YFdyh000(留言) 2021年2月26日 (五) 15:24 (UTC)
- 读作零零年代、一零年代,就像九零后、零零后。--YFdyh000(留言) 2021年2月26日 (五) 16:01 (UTC)
- ①“20世纪50年代”=“1950年代”=“1950年到1959年”,這應該比較沒有爭議;②但如您所舉例,遇到100的倍數就麻煩了;③「20世纪50年代」、「21世紀00年代」、「21世紀10年代」我會分別讀「二十世紀五零年代」、「二十一世紀零零年代」、「二十一世紀一零年代」,至於別人怎麼讀,我就不知道了。-游蛇脫殼/克勞棣 2021年2月26日 (五) 16:15 (UTC)
- 这,尴尬了,我记成21世纪了
- 似乎2000年是20世紀90年代(1991至2000年)的最後一年,以及2000年代(2000至2009年)的第一年⋯⋯像1世紀是1至100年,21世紀是2001年至2100年;而X世紀00年代是這個世紀的第一個十年。所以21世紀00年代是2001年至2010年,和2000年代嚴格來說還不是一個東西?PS:「21世紀00年代」和「21世紀10年代」怎麼讀?「二十一世紀零十年代」「二十一世紀一十年代」?--洛普利宁 2021年2月26日 (五) 15:10 (UTC)
- @@YFdyh000:說到年代的是,請教大家一個問題,最近我都不太用維基百科了,今天我在找資料時發現有條目裡面原有年代的部分被刪除了,查了查是有編輯者刪除了,可能他認為那是考古專家學者考據的年代,不是當時人寫下的年代,譬如,古埃及第三xxx王朝約西元前xxx年-西元前xxx年,所以編輯者把年代刪除在內容改成不知道,現在可以這樣嗎?><?我怕搞不清楚狀況所以問問。--User:浪子魚|愛偷懶的魚🐠※User talk:浪子魚|留言 2021年2月26日 (五) 16:43 (UTC) ──以上未簽名的留言由浪子魚(討論|貢獻)加入。
針對性決議[编辑]
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
- 我這裏的建議是:為便利分類維護,並避免由模板自動產生的分類出錯,當將所有以“YY世紀YY年代”格式命名的分類重新命名為“XXXX年代”格式、將所有以“創立”格式命名的分類重新命名為“建立”格式。頁面命名一致性的通用(普遍性)條文會稍後草擬,針對性的決議應該先通過。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 08:18 (UTC)
- 現公示以下針對性決議7日:將所有以「YY世紀YY年代」格式命名的分類重新命名為「XXXX年代」格式、將所有以「創立」格式命名的分類重新命名為「建立」格式。SANMOSA 江南好,風景舊曾諳 2021年3月22日 (一) 10:15 (UTC)
- (+)贊成--YFdyh000(留言) 2021年3月22日 (一) 11:06 (UTC)
- 前者同意,以便於維護,減少因格式之混雜不一所造成的分類維護困難;但後者則建議以既有母分類(諸如「各年建立的OOO」等,後續子分類一併以「建立的OOO」為原則)的命名格式為主,倘若尚無母分類者建議以「建立」為主要命名格式。--Steven |_-。) 2021年3月23日 (二) 14:52 (UTC)
- 兩者皆贊成,理由如下:
- XXXX年代部分-
- 以上討論顯示“19世纪50年代”這個用法容易誤判。
- “1950年代”寫法較為簡潔。
- 分類與主條目名稱統一對讀者來說最為便利,按照年代列表目前所有年代主條目都是採取“1950年代”這個寫法。
- User:Sanmosa在上方已提及的分類維護問題
- 建立部分-
- 以「創立」為名的分類數量明顯少於以「建立」為名的分類。--迴廊彼端(留言) 2021年3月23日 (二) 15:15 (UTC)
- XXXX年代部分-
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
頁面命名一致性的通用(普遍性)條文[编辑]
暫時不太想得到該怎樣寫。我可能要再看一看英文維基百科的對應規定,7日內應該能夠寫好。各位如果有其他的草案提議,也可以直接提。SANMOSA Σουέζ 2021年3月29日 (一) 11:35 (UTC)
- 暫時有這個條文草稿:
- 就條目命名(寫入Wikipedia:命名常规#技术要求或Wikipedia:命名常规#命名原则,寫入位置的不同會影響規則強度):
“ |
條目(包括列表條目,下同)的命名的格式(包括但不限於用詞)應與其他同類條目的命名的格式一致[註 1]。部分專題已經設置適用於該專題的子命名常規,並已在其中包含對該類條目的命名的格式的規範。其他條目的命名的格式由社群討論商定,並應立為子命名常規,否則應在《條目命名一致性決議》頁面予以記載。 |
” |
- 就分類頁面命名(寫入Wikipedia:分类名称#通则):
“ |
分類頁面的命名的格式(包括但不限於用詞)應與其他同類分類頁面的命名的格式一致[註 1]。分類頁面的命名的格式由社群討論商定,並在《分類頁面命名一致性決議》頁面予以記載。 |
” |
- 就其他非條目頁面命名(另開頁面):
“ |
非條目頁面的命名的格式(包括但不限於用詞)應與其他同類非條目頁面的命名的格式一致[註 1]。方針及指引頁面的命名的格式由《方針及指引》頁面的相關條文指定,而分類頁面的命名的格式則由《分類名稱》頁面的相關條文指定。其他非條目頁面的命名的格式由社群討論商定,並在《其他非條目頁面命名一致性決議》頁面予以記載。 |
” |
以上。@hat600、Milkypine、YFdyh000。SANMOSA Σουέζ 2021年4月19日 (一) 06:24 (UTC)
- 支持讓子命名常規處理該類條目的命名的格式的規範。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:05 (UTC)
請求第三方管理員參與評估和總結可靠來源討論[编辑]
關於Wikipedia:命名常规 (音乐)[编辑]
延續上次Wikipedia talk:命名常规#關於Wikipedia:命名常规#使用外文命名时的专门要求,請問音樂作品名稱是否能算是專有名詞?的討論,我寫了一篇Wikipedia:命名常规 (音乐)
希望各位可以給點意見,協助改善該命名常规無心*插柳*柳橙汁 2021年3月15日 (一) 06:12 (UTC)
。 --- 提示:阁下该次ping操作没有一个人会收到,因为您一次性同时ping了超过五十人。--Milky·Defer 2021年3月14日 (日) 20:08 (UTC)
- @MilkyDefer:(´_ゝ`)你沒提,我都忘了我人數超標了。 --無心*插柳*柳橙汁 2021年3月15日 (一) 06:13 (UTC)
- 我有ping到人嗎?無心*插柳*柳橙汁 2021年3月15日 (一) 14:05 (UTC) --
- (!)意見:1. 「夠格」一詞不夠正式。2. 關於「「『(歌曲)』:適用於所有歌曲,通常命名時優先使用」,請問是不是指像炎 (歌曲)這些「(歌曲)」跟「(單曲)」皆可的條目,「必須」還是「建議」以「(歌曲)」為消歧義呢?-hiJK910 七一七二一 2021年3月15日 (一) 14:18 (UTC)
我這個人最沒有主見了,關於「(單曲)」,我上次被百战天虫大說服後[5],覺得很有道理。當然,如果是像ARRIVAL OF EVERGLOW這種單曲專輯使用「(單曲)」,我就覺得還行。- 但就目前而言,都是歌曲不用「(歌曲)」而使用「(單曲)」到底是為什麼?我這邊問一下@Ryokie38:,當初建立½ (川本真琴單曲)使用單曲而不像1/2 (川本真琴の曲)使用歌曲的原因是什麼?。 --無心*插柳*柳橙汁 2021年3月15日 (一) 14:46 (UTC)
- 被Tag兩次啦(茶),基本上名稱方面沒有多大問題。順帶一提,自己也比較傾向於用「(人名歌曲)」或「(人名單曲輯)」或「(人名專輯)」三種來命名...好奇其他人的看法。-by 全速前進~~Yosoro!!~~的Tsuna Lu(留言) 2021年3月15日 (一) 16:07 (UTC)
- @Adsa562:我贊同人名的部分,直接使用人名可以避免以後移動的麻煩是好事,但如果是像胡薩維克 (歌曲)這種冷門的名稱或是像妮裳馬戲團 (歌曲)專門到極點的,不用加人名也沒問題。 --無心*插柳*柳橙汁 2021年3月15日 (一) 16:27 (UTC)
- 要跟en:Wikipedia:Naming conventions (music)連結吧,然後可以順便參考一下,像關於單曲/歌曲的問題,我覺得宜與英維一樣「儘量避免使用單曲」(If possible, avoid using other terms like "(single)", "(cassette)" or "(CD single)", etc.)--Austin Zhang(留言) 2021年3月15日 (一) 19:53 (UTC)
- 个人观点来说,保留单曲的程度是2<5=3<1=4,4有不止一首B面曲得到有效介绍,1则是在制作及商业成绩方面皆有充分介绍B面曲,3的介绍相比1单薄,但也算有效,5是仅有一句话的顺带提及,2则是完全没有来源,不过实际操作中,可以考虑对包含B面曲的或所有歌手自身称之为单曲(single)的条目以单曲消歧义,毕竟无论如何也要“名从主人”。
- 我這邊再給幾個增加樣本數,世界的盡頭 (單曲)、Yellow (木村KAELA單曲)、FACE (NU'EST單曲)、MAGIC (SHOW單曲)、崖上的波妞 (單曲)、Reflection (林原惠單曲)、口唇 (GLAY單曲)、髮夾 (單曲)。“名从主人”方面你說名稱那還有道理,但消歧义也如此就...(也不是不行啦,這在命名常规寫仔細一點)。 --無心*插柳*柳橙汁 2021年3月17日 (三) 23:56 (UTC)
- 主要是有D (BIGBANG单曲)、H (滨崎步单曲)这种无法以“歌曲”消歧义的条目存在,导致其他单曲类型条目如果以“歌曲”消歧义的话会产生问题,如果把Moments (濱崎步單曲)改成Moments (濱崎步歌曲)肯定会产生争议的吧。--无所事事/想要狗带 2021年3月18日 (四) 06:29 (UTC)
- D (BIGBANG单曲)、H (滨崎步单曲)這兩個使用單曲沒有問題(就像我前面提到的ARRIVAL OF EVERGLOW)。我引用星巴克女王大的說法來講就是「單曲是偏向介紹某張CD,而歌曲是偏向介紹某首歌曲,而我們寫的主要與歌曲內容有關,而不是介紹某張單曲CD。」 --無心*插柳*柳橙汁 2021年3月19日 (五) 01:19 (UTC)
- 为什么“我們寫的主要與歌曲內容有關,而不是介紹某張單曲CD”??我从来的看法是介绍某张单曲,及其中收录的歌曲。->>Vocal&Guitar->>留言 2021年3月25日 (四) 07:42 (UTC)
- D (BIGBANG单曲)、H (滨崎步单曲)這兩個使用單曲沒有問題(就像我前面提到的ARRIVAL OF EVERGLOW)。我引用星巴克女王大的說法來講就是「單曲是偏向介紹某張CD,而歌曲是偏向介紹某首歌曲,而我們寫的主要與歌曲內容有關,而不是介紹某張單曲CD。」 --無心*插柳*柳橙汁 2021年3月19日 (五) 01:19 (UTC)
- 主要是有D (BIGBANG单曲)、H (滨崎步单曲)这种无法以“歌曲”消歧义的条目存在,导致其他单曲类型条目如果以“歌曲”消歧义的话会产生问题,如果把Moments (濱崎步單曲)改成Moments (濱崎步歌曲)肯定会产生争议的吧。--无所事事/想要狗带 2021年3月18日 (四) 06:29 (UTC)
- 我這邊再給幾個增加樣本數,世界的盡頭 (單曲)、Yellow (木村KAELA單曲)、FACE (NU'EST單曲)、MAGIC (SHOW單曲)、崖上的波妞 (單曲)、Reflection (林原惠單曲)、口唇 (GLAY單曲)、髮夾 (單曲)。“名从主人”方面你說名稱那還有道理,但消歧义也如此就...(也不是不行啦,這在命名常规寫仔細一點)。 --無心*插柳*柳橙汁 2021年3月17日 (三) 23:56 (UTC)
- 个人观点来说,保留单曲的程度是2<5=3<1=4,4有不止一首B面曲得到有效介绍,1则是在制作及商业成绩方面皆有充分介绍B面曲,3的介绍相比1单薄,但也算有效,5是仅有一句话的顺带提及,2则是完全没有来源,不过实际操作中,可以考虑对包含B面曲的或所有歌手自身称之为单曲(single)的条目以单曲消歧义,毕竟无论如何也要“名从主人”。
- 单曲与歌曲是明显不同的概念,只要以单曲形式发行的作品,不论是一首歌几首歌,都应称为单曲。对于某些特殊的歌曲,比如我和你 (歌曲)之类,其制作背景不是以发行单曲为目的,或没有发行单曲,此时才合适用歌曲。->>Vocal&Guitar->>留言 2021年3月25日 (四) 07:42 (UTC)
- @Ohtashinichiro:當條目只是一首歌的時候,討論其格式根本沒有意義,你只會介紹一首歌,也只有這麼一首歌可以介紹,這種情況下沒有迫切需要「 (單曲)」做消歧义。再來討論「篩選條件」,我反對以「制作背景不是以发行单曲为目的」及「没有发行单曲」作優先處理。首先「制作背景不是以发行单曲为目的」要怎麼辨別,Say So一開始沒打算打單、Eyes on Me以遊戲主題曲為目的創作,但這兩首最後都打單了。唱片公司的舉動是否屬於制作背景以发行单曲为目的?
- 二來,現在這年頭,你沒有發行公司也能自己發歌。以Spotify為例,只要你加入Spotify的創作計畫,哪怕你沒有公司也能發歌。但單曲是Spotify的最低計量單位,創作者上傳的作品是否等於发行单曲?(例如PewDiePi的歌曲Congratulations (PewDiePie、Roomie和Boyinaband歌曲))。 --無心*插柳*柳橙汁 2021年3月25日 (四) 11:51 (UTC)
- 如果您只介绍歌曲的背景、词曲、意涵、影响,我觉得您使用歌曲没有问题。但您也会介绍这首歌作为单曲发行的信息比如日期地区形式唱片公司,以及作为单曲发行后的反应比如销量评价奖项,这些都属于单曲而不是歌曲的范围。至于您的举例都是完完全全的商业作品,商业作品当然都是以发行为目的且结果也都是已发行,我前面的表述可能会引起您的误解,也希望您可以研究一下您的举例和《我和你 (歌曲)》的区别在哪,能有一个合适的表述。另外spotify好像已经结束了自行发歌[6]。->>Vocal&Guitar->>留言 2021年3月26日 (五) 00:19 (UTC)
- @Ohtashinichiro:spotify结束自行发歌不等於整個計畫沒有發生過,對於以前參與計畫的歌該算?而Ohtashinichiro大你給出的這些條件,歌曲一樣可以使用,《家 (陳潔儀歌曲)》難道有出單曲他就活該倒楣只能是商业作品。我不能理解你一直提《我和你 (歌曲)》是想表達什麼,他們都是歌曲。不論有沒有出單曲、派台還是其他單曲形式,歌曲就是該用歌曲,沒有必要過度分類。 --無心*插柳*柳橙汁 2021年3月26日 (五) 04:20 (UTC)
- 单曲是“一碗饭”,歌曲是“碗里的饭”,您可能只想吃饭,我希望不要忽略这只碗。只是看起来您对这一点并不认同,那其他的讨论也没有意义了。->>Vocal&Guitar->>留言 2021年3月26日 (五) 05:01 (UTC)
- 如果您只介绍歌曲的背景、词曲、意涵、影响,我觉得您使用歌曲没有问题。但您也会介绍这首歌作为单曲发行的信息比如日期地区形式唱片公司,以及作为单曲发行后的反应比如销量评价奖项,这些都属于单曲而不是歌曲的范围。至于您的举例都是完完全全的商业作品,商业作品当然都是以发行为目的且结果也都是已发行,我前面的表述可能会引起您的误解,也希望您可以研究一下您的举例和《我和你 (歌曲)》的区别在哪,能有一个合适的表述。另外spotify好像已经结束了自行发歌[6]。->>Vocal&Guitar->>留言 2021年3月26日 (五) 00:19 (UTC)
Wikipedia:命名常规 (音乐)1.0更新報告[编辑]
無心*插柳*柳橙汁 2021年3月25日 (四) 05:33 (UTC)
感謝大家的意見回饋,自3/14以來,本指引更新下列內容,歡迎大家查閱。 --- 「古典音樂作品」敘述修正
- 「使用中文」內容增加
- 「外文規範」內容增加
- 「括號的使用」修改為「符號使用」,並增加「斜線」、「書名號」和「特殊符號」的說明與範例。
- 「消歧義」內容增加
- 「注釋」敘述修正
- 我本来就对“古典音乐作品”第一行“对序号是10(不含)以上的作品,‘号’字省略”有点疑虑,这样分类讨论,不利于条目名的统一性。[1]希望能交付社群讨论。另ping一下之前参与过相关讨论的@Foamposite、Iokseng、Anakharsis: ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月25日 (四) 06:05 (UTC)
- 我認為日文羅馬化可能需要詳細規定,例如shi或si到底要使用何者,《日語羅馬字》中有寫到三種羅馬化方式,看是要採用哪一種。 2021年3月25日 (四) 10:24 (UTC)
- @Milkypine:「對序號是10(不含)以上的作品,『號』字省略」是此類音樂作品的常用名稱的做法嗎?SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 09:57 (UTC)
- @Sanmosa:古典音樂的部分主要根據User:Anakharsis/沙盒#建立条目編寫,至於是否為此類音樂作品的常用名稱做法...這部分需要古典音樂的編輯來回答(技術上來講我會寫原聲帶但不等於我熟悉古典音樂)。 --無心*插柳*柳橙汁 2021年3月26日 (五) 12:41 (UTC)
- @Milkypine:我看了一下應該是對現行做法的總結。然而,我也看過了來源一下,似乎即使號碼大過10,加「號」字還是比較常見。我建議基於常用名稱的原則,將『序號使用阿拉伯數字,前面有「第」字;作曲家名字放在半角括號內,括號之前有一個半角空格。對序號是10(不含)以上的作品,「號」字省略』的規則改為『序號使用阿拉伯數字,前面有「第」字,後面有「號」字;作曲家名字放在半角括號內,括號之前有一個半角空格』。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 05:28 (UTC)
- 有關「號」的問題,綜觀慣常一般音樂會場刊的處理,通常都沒有特意加上「號」的,但本人自最初編寫蕭士達高維契交響曲時,經觀察和有前人提醒過名稱上要加上「號」,所以才不論第1還是第15都有加上「號」,且也覺得沒有問題,至於「超過10就不用加號」的說法,倒沒有聽過,不過User:Sanmosa建議不論序號,統一採用「第X號○○○ (某某)」的寫法,個人表示認同和支持。-Foamposite(留言) 2021年3月27日 (六) 07:40 (UTC)
- @Iokseng、Anakharsis:兩位的看法如何? --無心*插柳*柳橙汁 2021年3月28日 (日) 03:29 (UTC)
- 有關「號」的問題,綜觀慣常一般音樂會場刊的處理,通常都沒有特意加上「號」的,但本人自最初編寫蕭士達高維契交響曲時,經觀察和有前人提醒過名稱上要加上「號」,所以才不論第1還是第15都有加上「號」,且也覺得沒有問題,至於「超過10就不用加號」的說法,倒沒有聽過,不過User:Sanmosa建議不論序號,統一採用「第X號○○○ (某某)」的寫法,個人表示認同和支持。-Foamposite(留言) 2021年3月27日 (六) 07:40 (UTC)
- @Milkypine:我看了一下應該是對現行做法的總結。然而,我也看過了來源一下,似乎即使號碼大過10,加「號」字還是比較常見。我建議基於常用名稱的原則,將『序號使用阿拉伯數字,前面有「第」字;作曲家名字放在半角括號內,括號之前有一個半角空格。對序號是10(不含)以上的作品,「號」字省略』的規則改為『序號使用阿拉伯數字,前面有「第」字,後面有「號」字;作曲家名字放在半角括號內,括號之前有一個半角空格』。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 05:28 (UTC)
- @Sanmosa:古典音樂的部分主要根據User:Anakharsis/沙盒#建立条目編寫,至於是否為此類音樂作品的常用名稱做法...這部分需要古典音樂的編輯來回答(技術上來講我會寫原聲帶但不等於我熟悉古典音樂)。 --無心*插柳*柳橙汁 2021年3月26日 (五) 12:41 (UTC)
- 我不知道现在还可不可以为这个讨论作出贡献。我主要编辑古典音乐这方面,所以以下是我对于该方面的浅见:
- 1)我注意到大家关于“号”的讨论,我赞成“第”后面加“号”,不需要去管超过10什么的。我注意到很多的条目中超过10的也使用“号”,如:第11号钢琴奏鸣曲 (莫札特)、第12号交响曲 (肖斯塔科维奇)与第40号交响曲 (莫扎特)等。我不太懂为啥非要减少一个“号”。
- 2)哦,对了,維基百科:命名常規 (音樂)这里的降E大調弦樂五重奏(貝多芬作品)的括号好像用成了中文的()而非(),我觉得咱们可以着重的说一下我们的括号问题用的是英文的那种,我认为新手会喜欢犯这样的错误(比如我,哈哈哈哈)
- 3)关于调性的问题,我认为我们还应当注意对于音名和字母大小写的统一,如我们真的要写“降E大調弦樂五重奏 (贝多芬)”,我们需要着重指出到底是用“降E”还是“E♭ ”;亦或是“降e”还是“降E”。探讨这个问题很重要,因为在很多命名下面的条目内容出现不一致的情况,比如第3號交響曲 (貝多芬)中我们说“E♭大調第3號交響曲”,但是在第39號交響曲 (莫扎特)中,我们又说降E大調第39號交響曲。我的建议是我们应当使用“大写字母”以及“降”或“升”。
- 4)关于維基百科:命名常規 (音樂)这个地方的“如果該作品的名稱是獨一無二的,則作曲家名字也可以省略”,这个可能会有点争议,比如其中说到的大地之歌,这玩意儿可能指的是大地之歌 (电影)。我不是在这里杠呀,我是说类似这样的东西需要注意是否已经有不一样的体裁同样名字的东西已在维基百科中出现,比如查拉圖斯特拉如是說、库勒沃,咱们需要加上查拉圖斯特拉如是說 (史特勞斯)或库勒沃 (西贝柳斯);乃至于有些时候同属于音乐类的《传奇》,是西贝柳斯?还是维尼亚夫斯基?当然,我认为这个可以直接套用“作品在體裁內的序號+作品體裁+作...”的方式,只是需要稍加说明。我的建议是说明如果维基百科里已经有不同体裁但相同名字的条目则在新条目建立时的括号内加上作曲家名字,如果没有就无所谓了(自己看着办吧)。
- 5)注意到我们在古典音乐类编辑中有惯例但无有实质的关于“命名优先性”的规定(或者因为我是个新手没有注意到,哈~),我以我指的“优先性”举一个例子,我们是应该叫第6号交响曲 (柴可夫斯基)还是悲怆交响曲。我知道大家都很聪明,而且我个人感觉我们的惯例通常是用体裁加序號再加作曲家的方式,但是我认为需要在維基百科:命名常規 (音樂)对命名的优先性中做具体的说明,要不然!!!就会像某度那样出现憨憨的“悲怆交响曲”和“柴可夫斯基第六交响曲”那样的重复词条,我笑死了哈哈哈哈哈。
以上这些都是我的浅见,不知道能不能帮到大家~ --李新阳(留言) 2021年3月28日 (日) 06:29 (UTC)
- 暫時先回應第5項,要知道很多標題音樂,都不是作曲家原先加上的,因此除非如佛漢·威廉士那種開宗明義講過不喜歡使用作品序號的,就應該予以尊重,不然的話,應採用「第5號交響曲 (貝多芬)」而非採用「命運交響曲」,「第1號交響曲 (馬勒)」而非「巨人/泰坦交響曲」,頂多是使用重定向處理暱稱。--Foamposite(留言) 2021年4月2日 (五) 12:32 (UTC)
- 再回應第3項,正如我早前所講,如果是標題,那應使用「升C」、「降E」,因這不會涉及使用音樂符號模板的問題;至於內文中,如果是對應標題的,我會建議沿用「升C」、「降E」的寫法,但當牽涉到配器中的移調樂器(最常見,B♭單簧管),或者表示音樂中的音高時,個人就會覺得應該使用 {{music/xxx}} 的方式去表達。
- 至於第4點,我立時想到了早陣為拉赫曼尼諾夫的《死之島》開了條目,很明顯原來的畫作的名氣比起樂曲更大時,實在無法引用「獨一無二」的方式來處理,而音樂作品往往都是因其他著作、畫作而獲得靈感,這個概念無疑是限制了古典音樂作品能突破「獨一無二」的框架,除非好像《古雷之歌》,荀伯克選用了雅各生在世時未能完世的詩集內的作品,最終使音樂比原著更為人熟識,這樣的異例實在不多。
- 第1點早已表述,至於第2點也不過是技術錯失,修正一下便好了。--Foamposite(留言) 2021年4月2日 (五) 23:04 (UTC)
- 我理解羊羊说到的这个现象,不同地区对于曲目的命名确实存在差异。如中国爱乐乐团的曲目设置中,我们称“《古斯塔夫·马勒:第七交响曲》”,[2]而在国立台湾交响乐团的曲目设置中,我们称“《馬勒:D大調第一號交響曲》”。[3]当然这并不意味着大陆就一定不使用“号”,或台湾地区就一定使用“号”,比如国家大剧院就称呼“《贝多芬 C小调第五号交响曲,Op.67》”或[4]在“实践中”,维基百科古典音乐条目的命名中我们普遍使用“号”这个东西。虽然我个人觉得“号”不“号”的无可厚非,但我认为我们应当在维基百科中有一个统一的有共识的对于“号”的规定,我可能不会建议在这样的事情上按地区词处理,可能显得没有必要。(&)建議:我个人支持在命名时保留“号”这个东西,因为这似乎已经成了维基百科“没有特别规定的共识和实践”,且考虑到这个实践已经存在很长时间了,符合大家的写作习惯。我支持应当采用汉字表示具体的数字,如一、二等,而非使用阿拉伯数字。因为这个是对于大陆和台湾地区而言都通用的。--李新阳(留言) 2021年3月28日 (日) 18:35 (UTC)
- 对于李新阳其它几点内容:
- 见上。
- “(贝多芬作品)”不在条目名称里,这个括号只是解释说明作用,没什么关系[5]。但是个人觉得这一条有点问题,可能有不止一个作曲家的降E大调弦乐五重奏
序号不详、有争议或无可靠来源使用
,建议改成:调性优先,若无须消歧义,作曲家名字可以省略。 - 调性的问题。我认为应该用汉字“升”和“降”。至于字母大小写,我觉得争议出在小调上。英维古典音乐专题的Guidelines有说,大意是
D小调可以简写为d调,但不能写d小调这种缝合怪
。[6]然而我能看到的来源,(作品名还有行文)D小调和d小调都有,甚至感觉d小调更多。我觉得还是按中文习惯,大调大写,小调小写。 - 建议改成:如果该作品的名称是独一无二的,且无须消歧义,则作曲家名字也可以省略。
- 我觉得应该不是问题,第一条解决的就是通用情况。
- 以上。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 06:02 (UTC)
- 感谢羊羊对于关于大小调的叙述,我支持进行“大调大写,小调小写”的方式,合乎乐理,然后使用汉语表示升降号,以及新增关于“且无须消歧义”的条文。--李新阳(留言) 2021年3月29日 (一) 08:11 (UTC)
- 我自己反而是沒看過「小調小寫」的處理。SANMOSA Σουέζ 2021年3月29日 (一) 09:01 (UTC)
- 那這樣D小調不就需要...。 --Loving You Is A Losing Game 2021年3月29日 (一) 13:55 (UTC)
- 严格意义上来说,在乐理的学习和考试中以及大多数的实践中,都应当使用“大调大写,小调小写”的原则,这样合乎规范也严谨一些。您提到的D小調是一个很好的且应该进行改正的例子。--李新阳(留言) 2021年3月30日 (二) 05:36 (UTC)
- 我理解现在的许多音乐会,新闻或者乐评不强求或者不讲究这个,因为往往来说观众都更在意“大调”还是“小调”而非“大写”还是“小写”这样的“技术性问题”。我个人认为为了避免歧义,应当遵循“大调大写,小调小写”的原则。--李新阳(留言) 2021年3月30日 (二) 05:43 (UTC)
- 同意,我在音樂系學習時,按西方慣常命名時,大調用大寫,小調用小寫是不成名做法,這個和樂理和聲學有關,當然用在普及化的層面來說,大小寫的意義不大,對此我覺得在維基內可以因着便利性而不執行大小寫的做法,至於「降號」和「升號」,由於真正的寫法和「#」及「b」有別,涉及要用音樂符號模版,我傾向都是用文字表述為佳。--Foamposite(留言) 2021年4月2日 (五) 12:32 (UTC)
- (!)意見:命名中几乎遇不到小调大小写的情况,不属于命名常规讨论范畴,建议拆分为新讨论。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年3月31日 (三) 06:08 (UTC)
- 进行拆分的话倒是没有任何问题,我主要是看到了“降E大調弦樂五重奏”这个玩意儿,认为应当讨论一下大小写的问题。我现在发现了一个新东西,就是这个夜曲Op. 9 (蕭邦)以及前奏曲Op.28, No. 15 (蕭邦),我们可能需要引入一个新的话题,即Op和No的问题。我建议翻译出来比较好,要不然看这很别扭。--李新阳(留言) 2021年3月31日 (三) 06:59 (UTC)
- 夜曲 (肖邦第9号作品)?前奏曲 (肖邦第28号作品第15首)?太难看了……我觉得这些小问题还是不要讨论了吧,讨论是讨论不完的……你看看英维的音乐命名常规,古典音乐写了多长…… ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月1日 (四) 05:13 (UTC)
- 「命名中几乎遇不到小调大小写的情况」,我不清楚古典音樂們有多少,但對於小調,我想這部分可以一起處理,尤其是Template:Circle of fifths。
不過這麼一搞,條目裡面有出現小調我可能都要修改了OTZ--Loving You Is A Losing Game 2021年3月31日 (三) 14:28 (UTC)
- 进行拆分的话倒是没有任何问题,我主要是看到了“降E大調弦樂五重奏”这个玩意儿,认为应当讨论一下大小写的问题。我现在发现了一个新东西,就是这个夜曲Op. 9 (蕭邦)以及前奏曲Op.28, No. 15 (蕭邦),我们可能需要引入一个新的话题,即Op和No的问题。我建议翻译出来比较好,要不然看这很别扭。--李新阳(留言) 2021年3月31日 (三) 06:59 (UTC)
- 感谢羊羊对于关于大小调的叙述,我支持进行“大调大写,小调小写”的方式,合乎乐理,然后使用汉语表示升降号,以及新增关于“且无须消歧义”的条文。--李新阳(留言) 2021年3月29日 (一) 08:11 (UTC)
Wikipedia:命名常规 (音乐)2.0更新報告[编辑]
Loving You Is A Losing Game 2021年4月10日 (六) 07:04 (UTC)
感謝大家的意見回饋,這次根據上次1.0的討論修改古典音樂,並增加「 (單曲專輯)」的消歧義。歡迎大家查閱。 --- Loving You Is A Losing Game 2021年4月10日 (六) 07:06 (UTC) 由於人數眾多,這邊分開ping相關討論用戶。 --
- 括號一節舉的例子不是有全形字元(中文字)嗎?如果我沒理解錯誤的話,不應該是要用全形括號? 2021年4月10日 (六) 07:20 (UTC)
- @Pseudo Classes:你的意思是說「中文是全形字元」嗎?如果不是的話,習慣 (超快感)和姊姊 妳太美了 (Replay)這兩個例子都沒有全形字。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:26 (UTC)
- @Milkypine:是的,中文字理應也屬於全形字元,這樣寫會有歧義。 2021年4月10日 (六) 07:31 (UTC)
- 斜線一節也有這個問題。-- 2021年4月10日 (六) 07:34 (UTC)
- @Pseudo Classes:已修改為「全形符號」避免歧義。 --Loving You Is A Losing Game 2021年4月10日 (六) 08:01 (UTC)
- @Milkypine:感謝修正,另外我想請問關於斜線和括號有相關的共識嗎?不然我想再針對這個問題討論一次。 2021年4月10日 (六) 15:18 (UTC)
- @Pseudo Classes:姑且算吧,就算當初沒有共識,現在也可以有,我就不信我ping了快百位編輯沒人沒感覺。 --Loving You Is A Losing Game
- @Milkypine:了解,看了一下討論,這個作為共識應該沒問題。 2021年4月12日 (一) 02:42 (UTC)
- @Pseudo Classes:姑且算吧,就算當初沒有共識,現在也可以有,我就不信我ping了快百位編輯沒人沒感覺。 --Loving You Is A Losing Game
- @Milkypine:感謝修正,另外我想請問關於斜線和括號有相關的共識嗎?不然我想再針對這個問題討論一次。 2021年4月10日 (六) 15:18 (UTC)
- @Pseudo Classes:已修改為「全形符號」避免歧義。 --Loving You Is A Losing Game 2021年4月10日 (六) 08:01 (UTC)
- @Pseudo Classes:你的意思是說「中文是全形字元」嗎?如果不是的話,習慣 (超快感)和姊姊 妳太美了 (Replay)這兩個例子都沒有全形字。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:26 (UTC)
- 已查閱,感謝貢獻。--SickManWP歡迎參與♥️邊緣人小組的活動·✏簽到發表於 2021年4月10日 (六) 08:25 (UTC)
- 作出了一笔事实性编辑,另“大调大写,小调小写”的例子不妥(D大调、d小调),毕竟页面第一个字必须大写,建议改成
- 條目名稱須符合「大調大寫,小調小寫」,如“D大調”、“d小調”。
或是
- 條目名稱須符合「大調大寫,小調小寫」,如“D大調”、“d小調”。
以上。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月10日 (六) 15:33 (UTC)
- @羊羊32521:页面第一个字雖然必须大写,但d小調和iPhone一樣,都在其(樂理)領域屬於特定詞語,因此使用小血沒有問題。 --Loving You Is A Losing Game 2021年4月10日 (六) 16:50 (UTC)
Wikipedia:命名常规 (音乐)公示[编辑]
Wikipedia:命名常规 (音乐)公示。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:36 (UTC)
感謝大家的意見,現將- Loving You Is A Losing Game 2021年4月20日 (二) 07:39 (UTC) 由於人數眾多,這邊分開ping相關討論用戶。 --
- (?)疑問@Milkypine:看完整體草案,有疑惑的是「對於官方沒有給出羅馬化名稱的日文作品,根據平文式羅馬字羅馬化。」這條,特別指的是日本作品,那麼韓國作品有必要依照馬科恩-賴肖爾表記法將韓文轉換成羅馬字?若有的話,以「보라빛 밤」為例,是要以羅馬字呈現的英文「Pporappippam」為條目名稱,還是按照過去以編者翻譯先到先得、名從主人所相輔相成的WP:NAME規範,維持「紫光夜」的條目名稱?--🍫巧克力~✿ 2021年4月20日 (二) 07:46 (UTC)
- @卡達:方針有寫到「命名音樂條目時,優先使用最為通用的中文名稱命名。」,所以一定可以被命名為「紫光夜」。如果沒有中文名稱,則是對其外文依序進行處理(例如가시나因為有官方名稱所以使用「Gashina」)。基本上日韓語歌如果沒有英文歌名,一定都會有個中文名稱(例如24小時也不夠),這項提議也是針對「稀有狀況」做處理 --Loving You Is A Losing Game 2021年4月20日 (二) 10:04 (UTC)
参考資料
- ^ 英维古典音乐专题的Guidelines提到,
An article's title should be selected to best represent what readers of Wikipedia expect. This means, among other things, that titles should be consistent for each genre. For example, a reader who has already successfully found Mozart's 40th symphony under Symphony No. 40 (Mozart) will expect that Haydn's 103rd symphony should be found under Symphony No. 103 (Haydn).
- ^ 纪念古斯塔夫·马勒逝世110周年系列音乐会之二. [2021-03-28].
- ^ 【海神家族與馬勒巨人】簡文彬與國臺交將以音樂帶您感受作曲家與文學家筆下的深刻情感. [2021-03-28].
- ^ 贝多芬的第五号交响曲.
- ^ 理论上在正文出现的括号应该用全角,哈哈
- ^
Some reference works use a space-saving system where the words "major" and "minor" are omitted; a key in upper case refers to a major key, and one in lower case is a minor key. For example, "D" would mean D major, and "d" would mean D minor. Some editors confuse matters by adopting a part of this system but still spelling out the words "major" or "minor" – thus, "D major" vs. "d minor". This is inconsistent and is to be avoided.
——en:Wikipedia:WikiProject_Classical_music/Guidelines
(重提)Wikipedia:共识#提案討論及公示時間的執行力度[编辑]
最近客棧的提案實在是不勝Wikipedia:共识#提案討論及公示時間的困擾,但不太想盡廢,因此提一個修正案:
|
以上。SANMOSA 江南好,風景舊曾諳 2021年3月14日 (日) 15:31 (UTC)
- 主要影響:
- 不對提案進行實則性點評的支持意見不造成重算7日。
- 與提案本身無關的意見不造成重算7日。
- 將浮動的時間範圍「1個月」界定為固定的時間範圍「28日」。
- 容許公示在有必要時可長於7日。
- 以上。SANMOSA 江南好,風景舊曾諳 2021年3月14日 (日) 15:36 (UTC)
- (?)疑問:
- 原條文有「如果在互助客栈中被提出的提案」一句,在新條文要刪去嗎?
- 參閱Wikipedia:互助客栈/条目探讨#春晚及春晚 (消歧義),這種在Wikipedia:互助客栈/条目探讨的提案是否需要遵守WP:7DAYS?或是要將WP:7DAYS限定在Wikipedia:互助客栈/方针?--CaryCheng(留言) 2021年3月15日 (一) 02:41 (UTC)
- (?)疑問:這個提案改過很多次,而且30天和28天就差兩天,有必要改來改去嗎?而且一年就只有二月會有28天,大家都會以30天為一個月的概念,這種修改有甚麼意義呢?--蟲蟲飛♡♡→♡℃※留言 2021年3月15日 (一) 03:52 (UTC)
- (?)疑問:大致同意,而且也會看到這裡用雪球快速公示,好像也沒完全照規定走。但是這裡有些疑問要問一下,如何界定「已取得共識」、「合理異議」,「合理意見」?合理異議、意見會不會變成兩集團互斥對方不合理。只有一人提問,無人贊成、反對,算不算已取得共識,然後可以公示?這些提案人可以一併考慮,把規定寫更好一些。--2001:B042:1:A9ED:F58C:12D4:4C7B:B776(留言) 2021年3月15日 (一) 06:32 (UTC)
- (1)沒人抓的話其實是沒人會遵守這規定。(2)以前的人進行公示的時候都是説“現公示7日,無合理異議者即作通過”,跟以前的做法處理。(3)提案與現行辦法對於“只有一人提問,無人贊成、反對”的提案的態度是原則上可以公示,這當然會產生一些奇怪的現象(當然如果提案人能夠好好處理提問的話,我倒是覺得可以照樣公示通過),先前討論也談論過,但沒人管。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 07:54 (UTC)
- 回答的很完整。不縮小「無新留言」範圍,結果時間等太久,沒人抓大家就不走規定。不討論「已達成共識」定義,結果「一人提問,無人贊成、反對」,反而7日後就可以公示。這是不見得會有問題,但又有一些奇特的現象。--2001:B042:1:ABD5:F58C:12D4:4C7B:B776(留言) 2021年3月15日 (一) 08:27 (UTC)
- (1)沒人抓的話其實是沒人會遵守這規定。(2)以前的人進行公示的時候都是説“現公示7日,無合理異議者即作通過”,跟以前的做法處理。(3)提案與現行辦法對於“只有一人提問,無人贊成、反對”的提案的態度是原則上可以公示,這當然會產生一些奇怪的現象(當然如果提案人能夠好好處理提問的話,我倒是覺得可以照樣公示通過),先前討論也談論過,但沒人管。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 07:54 (UTC)
- (-)反对:重看了一下,註腳很有問題,而且只會增加爭議,應刪去。--蟲蟲飛♡♡→♡℃※留言 2021年3月15日 (一) 06:41 (UTC)
- 不同意。這是修訂提案的主要目的之一。之前的討論的主流意見都認同不應該使所有意見都能導致重算7日(我個人比較看重的是DrizzleD的意見)。我邀請一下之前參與過討論的@KirkLU、DrizzleD、BureibuNeko、UjuiUjuMandan、Fire-and-Ice來好了。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 07:49 (UTC)
- 不是说增加争议就不好。举个简单例子,根据中华人民共和国刑法,
故意杀人的,处死刑、无期徒刑或者十年以上有期徒刑;情节较轻的,处三年以上十年以下有期徒刑
,显然在不少案件中具体判罚轻重会有“争议”,但为什么不干脆故意杀人的都处死刑呢?因为不同的案件真的不一样,不能统一判罚。这里类似,单纯支持也好,给建议也好,反对也好,无关意见也好,对共识形成的作用完全不同,却都能导致重算7日,这就背离了WP:7DAYS帮助确认共识的初衷。--DrizzleD (按此给我留言) 2021年3月15日 (一) 09:41 (UTC)
- (+)支持:这四点都没什么问题。关于第一点,先前討論中已有不少论据,不再赘述(但愿)。简而言之,在没有其他意见的情况下,支持的人越多,提案越晚被公示,这是说不通的。--DrizzleD (按此给我留言) 2021年3月15日 (一) 09:46 (UTC)
- (?)異議:您誤解了WP:7DAYS的初衷,當時AT就是為了解決在討論不足的情況下,用戶火速公示,然後強行通過提案的問題。原先是要30天後才公示,後來才七天後沒有留言公示。七天算是合理時間,沒必要再縮短,否則又會回到以前火速公示,強行通過提案的問題,然後爭議不斷,問題多多。而且現在WP:7DAYS未見有甚麼問題,沒必要再放寛。--蟲蟲飛♡♡→♡℃※留言 2021年3月15日 (一) 13:12 (UTC)
- 不不不,是您误解了我的意思,我说它帮助确认共识,意思是它告诉我们什么时候算是确认了共识,不是说它帮助加速通过提案。然后:1.
七天算是合理时间,没必要再缩短
,我同意,但这个修正案完全没说要缩短七天这个时间,此说法和此修正案不相关。2.
又会回到以前火速公示,强行通过提案的问题
,当然不,留言支持者越多,说明通过提案越不强行,而不是相反。 3.而且现在WP:7DAYS未见有什么问题
,这个我现在不太活跃确实不太清楚,但Sanmosa似乎能够确认如此,@Sanmosa可以来说说。--DrizzleD (按此给我留言) 2021年3月15日 (一) 13:47 (UTC)- (3)現成的問題。SANMOSA 江南好,風景舊曾諳 2021年3月16日 (二) 05:53 (UTC)
- (※)注意:請看一下這個提案,有一大堆支持,也已經討論了一個月,還是有人反對,當時也有人催快點公示,也有朋友對說我要快公示,怕夜長夢多,會出現(-)反对,但提案的目的是要尋求共識,而不是快快通過,然後出現爭議,因此急於通過是不必要的,有共識的提案也不怕多放幾天。--蟲蟲飛♡♡→♡℃※留言 2021年3月16日 (二) 06:13 (UTC)
- 你對互助客棧討論的想法完全違背進行互助客棧討論應有的健康心態。SANMOSA 江南好,風景舊曾諳 2021年3月16日 (二) 06:58 (UTC)
- @蟲蟲飛:不吸烟也可能患肺癌,这不代表我们不用去倡导戒烟,关键是可能性。类似地,同样是暂时没有反对意见,一个有许多人支持的提案和一个没人理的提案,哪一个有潜在问题的可能性更大?这是不言自明的。
- 要解决所谓“已经讨论了一个月,还是有人反对”的问题,相关的方案是延长WP:7DAYS中7天或者是1个月的限制(当然可能会有一些别的问题),但这与本案无关。本案的要求是赞成或不相关的意见不影响时间(不管是7天还是什么其他时间)的重算。--DrizzleD (按此给我留言) 2021年3月17日 (三) 02:13 (UTC)
- 提案討論就不應存在不相關的意見,而且有時甚麼如何定義「不相關」也有爭議,因此我覺得AT現行版本較佳,沒必要改為一個具爭議性的版本。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 02:40 (UTC)
- 然而方針指引不能阻止任何用戶發表不相關的意見。SANMOSA 江南好,風景舊曾諳 2021年3月17日 (三) 05:43 (UTC)
- 如何定義「不相關」?誰去決定?雙方也可以互相指責對方的留言「不相關」,為甚麼要令提案增加不必要的爭議?AT現行版本是最好的,「七天沒留言」是客觀標準,沒有爭議空間。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:12 (UTC)
- (1)依據「共識應當考慮到所有正當合理的意見」此條方針來定義。(2)最極端的情況就找行政員,天仍然不會因此塌下來。(3)極端嚴格的「7天沒留言」是客觀標準沒錯,然而違反常識、慣性、正常討論生態和「共識應當考慮到所有正當合理的意見」此條方針。SANMOSA 江南好,風景舊曾諳 2021年3月17日 (三) 12:43 (UTC)
- 如何定義「不相關」?誰去決定?雙方也可以互相指責對方的留言「不相關」,為甚麼要令提案增加不必要的爭議?AT現行版本是最好的,「七天沒留言」是客觀標準,沒有爭議空間。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:12 (UTC)
- 然而方針指引不能阻止任何用戶發表不相關的意見。SANMOSA 江南好,風景舊曾諳 2021年3月17日 (三) 05:43 (UTC)
- 所以,這種提案還是,被改完的7days攔下吧?-- Sunny00217 2021年3月22日 (一) 16:25 (UTC)
- (※)注意:請看一下這個提案,有一大堆支持,也已經討論了一個月,還是有人反對,當時也有人催快點公示,也有朋友對說我要快公示,怕夜長夢多,會出現(-)反对,但提案的目的是要尋求共識,而不是快快通過,然後出現爭議,因此急於通過是不必要的,有共識的提案也不怕多放幾天。--蟲蟲飛♡♡→♡℃※留言 2021年3月16日 (二) 06:13 (UTC)
- @Sunny00217。SANMOSA 江南好,風景舊曾諳 2021年3月16日 (二) 05:56 (UTC)
- (3)現成的問題。SANMOSA 江南好,風景舊曾諳 2021年3月16日 (二) 05:53 (UTC)
- 不不不,是您误解了我的意思,我说它帮助确认共识,意思是它告诉我们什么时候算是确认了共识,不是说它帮助加速通过提案。然后:1.
- (?)異議:您誤解了WP:7DAYS的初衷,當時AT就是為了解決在討論不足的情況下,用戶火速公示,然後強行通過提案的問題。原先是要30天後才公示,後來才七天後沒有留言公示。七天算是合理時間,沒必要再縮短,否則又會回到以前火速公示,強行通過提案的問題,然後爭議不斷,問題多多。而且現在WP:7DAYS未見有甚麼問題,沒必要再放寛。--蟲蟲飛♡♡→♡℃※留言 2021年3月15日 (一) 13:12 (UTC)
- (-)反对:啥叫合理,啥叫不合理?誰有權判定?個中操作空間太大,不得不反對。芄蘭(留言) 2021年3月15日 (一) 13:22 (UTC)
- 啥叫曾在可靠来源中发表过的重要观点,啥叫不重要?谁有权判定?
- 啥叫恰当地改进或维护维基百科,啥叫不恰当?谁有权判定?
- 我们能收录可靠来源中的所有观点吗?我们能废除WP:5P5去墨守成规吗?不能。这种操作空间不是洪水猛兽,它是必要的,也是维基百科时时刻刻都在使用的东西。
- 当然,要是操作规范能写得更细、更准确,那更好,就像WP:WEIGHT较详细叙述了第一个问题。可假设还没人去写WP:WEIGHT的时候,我们订立原则的时候同样应该加上“重要”两个字,因为这就是应该的,而不是去害怕什么“操作空间”。--DrizzleD (按此给我留言) 2021年3月15日 (一) 14:14 (UTC)
- 提案人有邀请讨论,我稍微简单说一下自己的浅见:
- 类似于“最后一天有编辑补了个‘支持’,结果导致要重新计算公示前的无留言时间”的情况客观存在;
- 个人是支持上例的这种问题能够更灵活化的处理(毕竟,表达一下支持,甚或——更宽泛一点——由于方针通过、问题解决的喜悦在讨论串下面开了个适当的玩笑,都不是什么不合理的事情;让这种表达起到延长公示前时间的效果,并非方针的本意,也一定程度上压抑了这种合理表达的机会——毕竟既然赞成提案,谁也不希望自己表达的支持反而造成了拖延的反效果);
- 我能理解反对此种灵活化处理的编辑有种种疑虑,此种情况下不改变现有方针我觉得也是可以理解、认同;
- 但即使方针不变,只要翻看存档,就会发现此种灵活化处理在往例中比比皆是,在这些案例中大家某种程度上用一种“默示共识(或称沉默共识,或称通过不提出异议来支持)”的方式使得灵活化缩短时程得以实现;
- 也因此,如3,方针改不改在我看来也许真的问题不大(如果大家真的不期待太明确地以规则确认上述惯例,或至少有些编辑还对此存在很大疑虑,如3,我个人觉得也是能一定程度理解),只是希望即使不改方针,至少这种实践中自然而然的习惯不被刻意地挑战,只要大家觉得适当的情况,就可以稍微灵活一点。事实上,我觉得这也最大程度体现出维基的精神。
- 以上。--Kirk★ # 2021年3月15日 (一) 17:02 (UTC)
- 您是忽略了修訂版本中爭議性的問題,因為如何定義「不相關」有時也有很大爭議,否則之後提案又出現是否合法公示的問題,以前已經出現過很多次公示爭議,不應加一個具爭議性的註腳。我覺得AT現行版較佳,沒有修改的必要。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 02:45 (UTC)
- 不如此修訂的話,會對互助客棧的討論生態造成嚴重扭曲。SANMOSA 江南好,風景舊曾諳 2021年3月17日 (三) 05:43 (UTC)
- 没有对“不修改”、“現行版較佳”的观点表示反对。核心是认为可以没有明示规定但要尊重实操中的默契。(比如,规则上尽可以挑战Wikipedia:互助客栈/方针/存档/2021年3月#修订R3适用情形五的公示[毕竟严格意义上他远没有7天],但缺乏意义,只会把程序性修订也拖得冗长。于我个人而言,如果有挑战,我一定会尊重这种挑战,因为方针如此,效果也不过是拖到下个月再公示。但缺乏意义。)--Kirk★ # 2021年3月17日 (三) 13:36 (UTC)
- 整理一下這裡看到的一些東西喔。WP:CONLIMITED說方針與指引的重大修改一定要先充分討論,但是小修改可以直接編輯,然後寫編輯摘要,謹慎一些就到客棧開話題知會一下,沒人回退就定了,有人反對再走程序,不過現在不知道方針小修改還能不能這樣。所以現在這個WP:7DAYS好像就是要讓人在重大修改,需要經過公示的話,希望能放上一個月,7天沒新留言會不會是當時支持方的妥協,所以現在他們不想在縮小新留言範圍,因為精神上他們認為至少放一個月比較好。--2001:B042:1:A908:F58C:12D4:4C7B:B776(留言) 2021年3月18日 (四) 04:40 (UTC)
- 现在7days的实际执行情况也不是很好。一些提案会根据SNOW和IAR缩短公示时间,一些提案会在数日无新留言时直接进入公示(并加长公示时间)。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月18日 (四) 15:23 (UTC)
- 也是啦,這個可以在觀察,一個規定常常會被SNOW、IAR、無視,是可以檢討一下規定。以後大家真的覺得「至少放一個月的精神」真的太長的話,看看能不能不要管7天新留言,全部改成至少放14天又取得共識才能公示,然後公示至少要放7天。這樣的14+7規定也不比人事任免、榮譽票選短了,等於提案至少有放21天的知會、反對、討論時間了,然後難聚共識的大提案一定還會在更長。--2001:B042:1:A5B3:7CCD:E884:C570:5D6A(留言) 2021年3月19日 (五) 03:33 (UTC)
- IAR不能亂用,只有在現行規則阻礙您維護維基,才可以用,而且要準備受到社羣的質疑,提案多討論幾天,有利於收集更多意見,因此不適宜引用IAR。此外,不依7DAYS會引發很多爭議,之前就試過有提案因為公示沒有嚴格依從7days去進行,提前公示了,結果即使提案通過了多天,仍然引發了社羣對提案的有效性的質疑。--蟲蟲飛♡♡→♡℃※留言 2021年3月19日 (五) 06:35 (UTC)
- 這IAR連其他管理員自己也有用到,那次我就懶得抓7日了,結果就直接過了。SANMOSA 江南好,風景舊曾諳 2021年3月19日 (五) 09:28 (UTC)
- @蟲蟲飛:既然這都不能IAR了那IAR存在的意思是?然後濫用IAR的您也可以送一張反對票讓它重寫公示,真的能起爭議的還是能被7DAYS框住的。-- Sunny00217 2021年3月22日 (一) 16:32 (UTC)
- IAR是用於緊急情況,例如管理員失控,刪去首頁,其他管理員可以不用drv,直接還原;或者管理員失控狂封人,其他管理員可以直接解封及封了失控管理員等緊急情況。相反,如果可以任意用,方針指引也沒用,人人都可以引用IAR。--蟲蟲飛♡♡→♡℃※留言 2021年3月22日 (一) 22:33 (UTC)
- 从来没有说法说IAR只能用于
紧急情况
,只要忽略的是妨碍你恰当地改进或维护维基百科的规则就可以了。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:39 (UTC)
- 从来没有说法说IAR只能用于
- IAR是用於緊急情況,例如管理員失控,刪去首頁,其他管理員可以不用drv,直接還原;或者管理員失控狂封人,其他管理員可以直接解封及封了失控管理員等緊急情況。相反,如果可以任意用,方針指引也沒用,人人都可以引用IAR。--蟲蟲飛♡♡→♡℃※留言 2021年3月22日 (一) 22:33 (UTC)
- IAR不能亂用,只有在現行規則阻礙您維護維基,才可以用,而且要準備受到社羣的質疑,提案多討論幾天,有利於收集更多意見,因此不適宜引用IAR。此外,不依7DAYS會引發很多爭議,之前就試過有提案因為公示沒有嚴格依從7days去進行,提前公示了,結果即使提案通過了多天,仍然引發了社羣對提案的有效性的質疑。--蟲蟲飛♡♡→♡℃※留言 2021年3月19日 (五) 06:35 (UTC)
- (+)支持。——BlackShadowG(留言)维基百科20岁生日快乐! 2021年3月21日 (日) 01:27 (UTC)
- (-)反对:不看好新版条文,因为容易引发争议。--DavidHuai1999※Talk 2021年3月21日 (日) 05:41 (UTC)
調適案1[编辑]
|
|
我還是想做到一些東西,退而求其次一下好了。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 08:03 (UTC)
- 主要影響:
- 不對提案進行任何點評的支持或中立意見不造成重算7日。
- 與提案本身無關的意見不造成重算7日,而意見是否與提案有關根據《討論頁指引》的規定界定。
- 將浮動的時間範圍「1個月」界定為固定的時間範圍「28日」。(依舊)
- 容許公示在有必要時可長於7日。(依舊)
- 以上。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 08:09 (UTC)
- (-)反对:理由同上,我還是覺得AT現行版本較佳,而且提案不但沒有解決問題,而且註腳部分帶出更多的公示爭議。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 13:31 (UTC)
- 「不對提案進行任何點評的支持或中立意見」是很容易看出來的事情,多一句話就已經是「點評」了,非常明確,怎麼可能「帶出更多的公示爭議」?《討論頁指引》的規定也應該很清楚明白吧,難道說《討論頁指引》也是形同虛設的?將浮動的時間範圍界定為固定的時間範圍也是明確指引的處理。修訂容許公示時間可長於7日,但沒容許可短於7日,因此公示時間上也不可能產生爭議。綜以上,我完全不認同調適案1「帶出更多的公示爭議」。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 13:39 (UTC)
- 現在方針修改頻繁,AT版七天已經算是很合理的時間,頻繁的方針修訂中,讓社群有足夠時間去消化,及讓提案有足夠時間收集更多意見是必須的。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 13:47 (UTC)
- 頻繁的方針修訂正是因為社羣有迫切的需求,如果社羣不理解方針修訂的內容,理當向提案人發問(這樣做無論是在原始提案下,抑或在調適案1下,都仍然會造成重算7日),我不明白社羣怎麼在遇到看不明白的事情都不會發問。一味壓抑社羣的迫切需求對社羣而言並不健康,我僅是希望將equilibrium position稍稍推回到提案人一邊一些而已。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 14:07 (UTC)
- 像下方#交通關注度指引修訂這樣的方針修訂,我是不見得需要多長的時間來「消化」。需要較長的時間來「消化」可能是像下方#分案1這樣的方針修訂,那為何不像MINQI這樣去發問?這可能比自己自行「消化」提案內容來得更有效率,使自己更快清楚明白提案內容。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 14:11 (UTC)
- 您搞錯了兩者因果關係,正因為修訂頻繁,提案更不應急於公示,應該收集更多意見,而不是火速公示,強行通過,然後有些用戶來不及表達意見,結果爭議不斷。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 14:14 (UTC)
- 不,方針指引修訂頻繁是社羣的迫切需求的結果。現行條文只是在無視社羣實際存在的迫切需求,並將之強行壓抑。社羣的迫切需求是方針指引修訂頻繁的產出來源,應當做的是滿足需求,而非壓抑需求。再者,現實上方針指引修訂頻繁不可能等到所有人發表了意見才能處理,否則這就屬於遊戲共識形成程序的情形。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 10:36 (UTC)
- @Sanmosa:不能认可方针的快速频繁修订(及提案和公示)。方针应该是总结归纳长久的共识,仅在争议严重时依充分讨论规定妥协方案(如COVID-19命名)。将未成熟的方针及公示作为约束或指导后续编辑的手段是不正确的,WP:BURO:“不是盲目跟随默认的方针和程序。要避免编写过分冗长的指示。”。应更多以讨论确认意见、指引,而非编立方针来不必要的规约。设立规则来制止他人反而会有GAME之嫌。--YFdyh000(留言) 2021年3月27日 (六) 12:16 (UTC)
- 不,方針指引修訂頻繁是社羣的迫切需求的結果。現行條文只是在無視社羣實際存在的迫切需求,並將之強行壓抑。社羣的迫切需求是方針指引修訂頻繁的產出來源,應當做的是滿足需求,而非壓抑需求。再者,現實上方針指引修訂頻繁不可能等到所有人發表了意見才能處理,否則這就屬於遊戲共識形成程序的情形。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 10:36 (UTC)
- 您搞錯了兩者因果關係,正因為修訂頻繁,提案更不應急於公示,應該收集更多意見,而不是火速公示,強行通過,然後有些用戶來不及表達意見,結果爭議不斷。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 14:14 (UTC)
- 要说多少遍本提案和“七天”没有任何关系。实话说,您要是觉得时间短,延长到十天我也没意见,但“不对提案进行任何点评的支持或中立意见”能导致重算,究竟合理吗?--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:50 (UTC)
- 現在方針修改頻繁,AT版七天已經算是很合理的時間,頻繁的方針修訂中,讓社群有足夠時間去消化,及讓提案有足夠時間收集更多意見是必須的。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 13:47 (UTC)
- 「不對提案進行任何點評的支持或中立意見」是很容易看出來的事情,多一句話就已經是「點評」了,非常明確,怎麼可能「帶出更多的公示爭議」?《討論頁指引》的規定也應該很清楚明白吧,難道說《討論頁指引》也是形同虛設的?將浮動的時間範圍界定為固定的時間範圍也是明確指引的處理。修訂容許公示時間可長於7日,但沒容許可短於7日,因此公示時間上也不可能產生爭議。綜以上,我完全不認同調適案1「帶出更多的公示爭議」。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 13:39 (UTC)
- (-)反对:理由同上,我還是覺得AT現行版本較佳,而且提案不但沒有解決問題,而且註腳部分帶出更多的公示爭議。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 13:31 (UTC)
参考資料
- ^ 不對提案進行任何點評的支持或中立意見,以及與提案本身無關的意見,皆不視作此條文所指的「新留言」。
- 即额外把7日改成10日,这下新提案的讨论时间应该不会比旧的情况少了。“应该让社群有足够时间消化及表达意见,千万不要心急,有共识的提案就不用怕多放几天有(-)反对,而且急于通过,火速公示,然后争议不断,那通过的提案也不是反映共识”,那多几天总没问题吧。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:01 (UTC)
- 我還是覺得註腳部分有爭議,因為「有沒有點評」不同人都有可能有不同的解讀,而且客棧遇到激烈爭議時,這個註腳只會帶出更多爭議,而且本站社羣還沒有達到英維的客觀與理性,無視反對意見,指鹿為馬等奇怪的事常有,因此我還是(-)反对注腳部分。反而,Sanmosa想爭取28天,減兩天,這個我沒有異議。--蟲蟲飛♡♡→♡℃※留言 2021年3月28日 (日) 07:19 (UTC)
- 「不對提案進行任何點評的支持或中立意見不造成重算7日」這句話的意思我要解釋一下,就是只寫了「支持」、「中立」、「沒意見」、「不反對」之類的,我認為定義已經足夠明確。我不要求只有「實則性點評」才能導致重算7日已經是很大的讓步了。SANMOSA ······ 2021年3月28日 (日) 23:51 (UTC)
- 這是不必要,而且這是您的理解,實際的爭議時,不同人都可能有不同的解讀,我還是覺得AT現行版本較佳,即「七天沒有留言」就可以公示,完全沒有爭議。但您以不同名目去縮短公示期限,這是不必要,而且容易造成爭議。提案的公示一旦有爭議,提案的合法性就會受到質疑,過去是有先例的。--蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 05:05 (UTC)
- 您有所不知,客棧的提案不是收集支持或中立,而是看看有沒有(-)反对,因為提案放出來,七天完全沒有留言,已經可以公示,公示後,沒異議就通過,其他維基也是一樣,因此提案的反對意見比支持的意見重要。而且,「七天沒留言」在維基可視為默認共識,見WP:TALKDONTREVERT:「假如編者已停止在討論頁內回覆相關討論,便可以假定共識已經形成。」--蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 06:30 (UTC)
- 所以我希望最後的共識能確立該條條文以我上方的解讀為準。SANMOSA ······ 2021年3月29日 (一) 06:36 (UTC)
- 還是回到那個問題,甚麼叫“有建設性的意見”?標準誰定?爭議時互相指責對方的意見“無建設性”,結果把本來不應有的公示爭議,變得非常有爭議。蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 06:53 (UTC)
- 我請你重看我的調適案1,我的調適案1完全無提及過「有建設性的意見」,我不知道你是從哪裏看到的,還是你不小心看到了甚麼一般人看不到的東西。如果你是從我上面的留言看到的話,那我只能夠說你真的沒有一般人應有閱讀中文的能力,我說的是現行的條文讓人不願意留下附有其他建設性的提議的支持意見或中立意見,而不是直接阻止,具阻止性質的效果有時候並不需要直接言明的條文達到;至於這事情會產生的問題,那就是只有反對意見得以顯現,使實際的意見比例和表面上所看到的意見的比例不符。SANMOSA Σουέζ 2021年3月29日 (一) 10:00 (UTC)
- 請重看您於「2021年3月29日 (一) 06:36 (UTC)」的留言。而且「進行任何點評」也是換了不同的名目,性質也是一樣,這些都是不必要的,AT現行版本已經很清晰,沒有修改的必要。--蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 14:02 (UTC)
- 我請你重看我的調適案1,我的調適案1完全無提及過「有建設性的意見」,我不知道你是從哪裏看到的,還是你不小心看到了甚麼一般人看不到的東西。如果你是從我上面的留言看到的話,那我只能夠說你真的沒有一般人應有閱讀中文的能力,我說的是現行的條文讓人不願意留下附有其他建設性的提議的支持意見或中立意見,而不是直接阻止,具阻止性質的效果有時候並不需要直接言明的條文達到;至於這事情會產生的問題,那就是只有反對意見得以顯現,使實際的意見比例和表面上所看到的意見的比例不符。SANMOSA Σουέζ 2021年3月29日 (一) 10:00 (UTC)
- 「不對提案進行任何點評的支持或中立意見不造成重算7日」這句話的意思我要解釋一下,就是只寫了「支持」、「中立」、「沒意見」、「不反對」之類的,我認為定義已經足夠明確。我不要求只有「實則性點評」才能導致重算7日已經是很大的讓步了。SANMOSA ······ 2021年3月28日 (日) 23:51 (UTC)
- 即额外把7日改成10日,这下新提案的讨论时间应该不会比旧的情况少了。“应该让社群有足够时间消化及表达意见,千万不要心急,有共识的提案就不用怕多放几天有(-)反对,而且急于通过,火速公示,然后争议不断,那通过的提案也不是反映共识”,那多几天总没问题吧。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:01 (UTC)
- (-)反对,讚同蟲飛飛的意見。AT的版本已經很清晰。Walter Grassroot(留言) 2021年4月1日 (四) 01:34 (UTC)
- (-)反对:在此种情况下应依据常识进行判断,而不是拘泥于方针细节之中。--Yining Chen(留言|签名) 2021年4月4日 (日) 12:05 (UTC)
第一步[编辑]
看上去至少明确1个月为28天这一点没人有异议。--DrizzleD (按此给我留言) 2021年4月12日 (一) 09:52 (UTC)
- (-)反对,一個月應為30天,過往各個原定以月計算的資格(例如不活躍管理員、關注度等)都是以30天來換算改例,這個卻不是,執行上可能引起混淆。而上面對於28天的公平性解釋並不充份,上面的理據衹能說明大小月的日子不同而造成的不公平,但不足以說明28天是最公平(因為我也可以說31天可以讓人有較多時間討論,28天顯然損失了時間,為了補償小月的損失所以用31天、全部都要跨月才最公平)。事實上,衹要有一個明確的統一天數,跨月與否本身並不影響公平性。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2021年4月18日 (日) 11:41 (UTC)
- @Cdip150:現在是把不固定的“一個月”改寫成固定的日數,不可能“執行上可能引起混淆”,“28日”和“30日”很明顯是有分別的。現在的討論情況其實就是現行方針已經令客棧討論產生了冗長辯論的問題(這討論串就是活生生的例子),因此即使“跨月與否本身並不影響公平性”成立,也不可能訂立一個較長的日數(對,我的意思就是説30日已經過長,現行方針正在過分鼓吹“讓人有較多時間討論”,結果適得其反,這也是提出是次方針修訂的主因)。我本來的想法是直接縮短那個期限到比任何定義上的“一個月”更短。SANMOSA Σουέζ 2021年4月19日 (一) 01:02 (UTC)
- 不認為現在的冗長辯論的主因是多了這兩三天,提案要是具爭議的,無論定多少天都會有人拉下去,以現狀來推斷「30日已經過長」、「不可能訂立一個較長的日數」,我認為理據非常不充份。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2021年4月19日 (一) 02:03 (UTC)
- @Cdip150:建議你看看這規則通過以來的所有客棧討論,一個與討論主題不相關的留言直接導致公示延後非常常見。現行規則唯一的“作用”是在不必要地拖時間。SANMOSA Σουέζ 2021年4月19日 (一) 02:15 (UTC)
- 不認為現在的冗長辯論的主因是多了這兩三天,提案要是具爭議的,無論定多少天都會有人拉下去,以現狀來推斷「30日已經過長」、「不可能訂立一個較長的日數」,我認為理據非常不充份。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2021年4月19日 (一) 02:03 (UTC)
- @Cdip150:現在是把不固定的“一個月”改寫成固定的日數,不可能“執行上可能引起混淆”,“28日”和“30日”很明顯是有分別的。現在的討論情況其實就是現行方針已經令客棧討論產生了冗長辯論的問題(這討論串就是活生生的例子),因此即使“跨月與否本身並不影響公平性”成立,也不可能訂立一個較長的日數(對,我的意思就是説30日已經過長,現行方針正在過分鼓吹“讓人有較多時間討論”,結果適得其反,這也是提出是次方針修訂的主因)。我本來的想法是直接縮短那個期限到比任何定義上的“一個月”更短。SANMOSA Σουέζ 2021年4月19日 (一) 01:02 (UTC)
- (-)傾向反對,意見同Cdip150閣下。—— Eric Liu 創造は生命(留言.留名.學生會) 2021年4月19日 (一) 05:30 (UTC)
- Per Cdip ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 16:11 (UTC)
有關新增偽命名空間的提議[编辑]
現時MOS和LTA均為偽命名空間,其中MOS專門指向站內各已正式通過和未正式通過的格式手冊。我有一個想法是能不能為命名常規和關注度指引也設立專門的捷徑偽命名空間?SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 09:02 (UTC)
- @A2569875、Taiwania Justo、Yining Chen、羊羊32521、YFdyh000、@LuciferianThomas、Ericliu1912、MilkyDefer、Super Wang、Sunny00217。SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 09:08 (UTC)
- (+)支持。偽命名空間運行暢順,可選擇有需要的計劃空間內容增設偽命名空間。(&)建議命名常規使用「NC」字首、關注度使用「N」字首。另(&)建議增設共識(討論)捷徑「CON」,連結至各討論存檔(Talk、WT、PJT)或資訊頁(WP),如CON:COVID19指向COVID-19條目共識。--LuciferianThomas.留言 2021年3月24日 (三) 09:32 (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)
- 先跑题:MOS基本没用过,看到时我习惯改用WP前缀。LTA用过但没有独立空间所以搜索很不方便,期望未来设独立空间、增设访问限制。然后:我不清楚相关页面有多少,如果很少,可能用的人也不会很多?以及持久性不会好(几年后失效)。N有点短,NOTE我想到[{tl|TA}}和备注,命名常规为什么不是NAME:(但未来会不会冲突?)。关注度没想法,考虑到“关注度”定名本身都有质疑,我暂时想不到很好的。NT在中国大陆网络有贬义“脑瘫”,不赞成。--YFdyh000(留言) 2021年3月25日 (四) 12:14 (UTC)
- (-)反对,如果将编辑社群页面等因为与Wikipedia命名空间关联性不强而划分出的话,方针等与项目运营有关的的页面不应该划出Wikipedia空间,而且本身这部分已经能通过消歧义的方式处理,没坏别瞎修。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年3月26日 (五) 00:54 (UTC)
- 又想了一下,关注度用用NOTA:什么的太长,不是太有必要,WP:Nxxxx辨识度已经够,NT可行。仍支持NC。nc不是还有脑残的意思?( ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月8日 (四) 15:16 (UTC)
- Naming Conventions... 別想歪就好了啦。--LuciferianThomas.留言 2021年4月10日 (六) 23:10 (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)
- @LuciferianThomas:請記得也把存檔頁的內容刪除,以免之後存檔有重複內容。--Xiplus#Talk 2021年4月23日 (五) 01:40 (UTC)
公示7日,2021年4月30日 (五) 01:33 (UTC) 結束。--LuciferianThomas.留言 2021年4月23日 (五) 01:33 (UTC)
由於超過七日無新意見,
模板颜色相关规范[编辑]
想问一下关于模板的相关规范:现在的模板并没有任何关于颜色的规范。我个人希望模板的颜色本身不应被任何其他的配色所取代(模板不应被着色),尤其是没有达成任何Accessability相关要求的共识前,均不应当修改任何着色,否则将会可能影响读者正常阅读模板。--1233 (T / C) 2021年3月22日 (一) 13:19 (UTC)
- 可参见WCAG 2.1 AA。--痛心疾首 2021年3月22日 (一) 13:34 (UTC)
- Wikipedia:格式手冊/文字格式#颜色及内联图像算不算?SANMOSA 江南好,風景舊曾諳 2021年3月22日 (一) 13:52 (UTC)
- Wikipedia:格式手冊/文字格式#颜色及内联图像的確無法處理導航模板。 --無心*插柳*柳橙汁 2021年3月24日 (三) 03:31 (UTC)
- @痛心疾首、Milkypine、1233:已移動討論至方針區。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 09:01 (UTC)
- 擬修改如下:
|
|
以上。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 23:40 (UTC)
- 格式手冊僅適用於條目。關於模板的格式指引應該置於維基百科:分類、列表與導航模板。—— Eric Liu 創造は生命(留言.留名.學生會) 2021年3月27日 (六) 09:20 (UTC)
- 理論上可以在WP:分類、列表與導航模板直接套用Wikipedia:格式手冊/文字格式#颜色及内联图像的內容處理(會動用到onlyinclude參數,效果和模版編輯員方針有關行使權力的條文的效果一致),所以這反而不成問題。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 10:23 (UTC)
- @Ericliu1912。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 10:26 (UTC)
- 順便把footnote的連結改為WikiProject:鐵道/移除著色文字模板吧。--LuciferianThomas.留言 2021年3月28日 (日) 06:25 (UTC)
- 似乎应该是不在条目里用带特殊颜色的模板,而不是规定模板不得带颜色。所以建议“条目正文、表格及各类模板”→“条目正文、表格及条目中使用的各类模板”。--DrizzleD (按此给我留言) 2021年3月28日 (日) 08:04 (UTC)
- 如果我沒理解錯誤的話,是不是Infobox系列模板都不能自訂文字和背景的顏色? 2021年3月29日 (一) 04:28 (UTC)
- 就Accessability这个理由,完全支持禁止对模板、表格等上色。🌟🌟Talk 2021年3月29日 (一) 04:53 (UTC)
- (-)反对:信息框內的文字在某些情況下應允許使用不同的顏色,否則將無法很好地表意;導航模板同理,例如{{柑橘属}}和{{地質年代}}模板使用了不同的底色,但也只是起到輔助區分相關信息的作用,並不影響色盲色弱等特殊群體閱覽,取消這些底色後,非但不能照顧到少部分特殊群體(因為在色盲色弱看來,無論普通模板還是上色模板基本都是一片灰,並無本質上的區別),並且對於絕大部分正常讀者而言將是一大損失。讓絕大部分正常群體去遷就少部分特殊群體,屬於西方式政治正確(就好比硬說黑人和白人一樣聰明),英維的做法不可取。--蕭漫(留言) 2021年3月29日 (一) 12:51 (UTC)
- 同意需要有指引規範相關模板的著色。另外我處理的部分模板出現嚴重的"撞色"問題,才要求模板應暫時停止著色。這不是西方不西方的問題,而是此等問題已經燃燒至影響正常的閱讀體驗了。--1233 (T / C) 2021年3月29日 (一) 13:30 (UTC)
- 西不西方我是不清楚,但肯定是眼殘級別追夢 Do Re Mi。尤其是像Template:Weki_Meki,這邊上色的意義何在? --Loving You Is A Losing Game 2021年3月29日 (一) 15:21 (UTC)
- 不同意柑橘屬跟地質年代這兩個舉例,柑橘屬的顏色僅僅是階層式架構,以排版就足以區分,不需要再加上顏色;至於地質年代的顏色更是沒有意義,部分底色與文字顏色對比度不高,對正常人來說也是難以閱讀。--Xiplus#Talk 2021年4月3日 (六) 06:01 (UTC)
- (-)強烈反对:对地质和生物学相关等特殊模板有严重影响!1.减轻服务器负担这个理由就经不起推敲,难道现在的服务器机能还不如以前的服务器?2.另外照顾色盲色弱群体这个理由已经有人反驳了。U:Lab06 N 参与微软专题 2021年3月30日 (二) 13:57 (UTC)
- 既然已經了解提案禁止對Infobox等模板上色,那麼我(-)反对此提案,畢竟有些Infobox模板的顏色對辨別條目類型有很大的幫助,不能因為視覺障礙人士而選擇單一的格式,不過如果是限制背景顏色和文字顏色之間的對比度,這我能夠接受。 2021年4月1日 (四) 14:20 (UTC)
- 仔细想了想,倾向不赞同:
- (主要)现行方针能够确保色盲(弱)人士能够获取充分信息,根据现行方针要旨,只需避免“单独地使用背景颜色来表达某一含义”,同时避免“饱和度过高,或与文字对比度不足”,上述举措——
- 确保了色盲(弱)人士能够不依赖颜色获取足够信息,确保所有人阅读的文字是清晰的;
- 在此基础上,不对辅助性背景填色进行“一刀切”,能保障更多色觉正常的人士能借背景色获得获取信息上的便利。
- (次要)变更宜乎审慎行事,仅高速公路一类就有逾千条条目和大量模板受到影响,即便上述修改要实施,修正案也未能列出批量变动的页面范围和变动的具体方案。
- (主要)现行方针能够确保色盲(弱)人士能够获取充分信息,根据现行方针要旨,只需避免“单独地使用背景颜色来表达某一含义”,同时避免“饱和度过高,或与文字对比度不足”,上述举措——
- 以上。--Kirk # 2021年4月1日 (四) 14:33 (UTC)
- (-)反对,限制面太广,用户框、导航模板等都会受影响。可行的着色可以按常识判断。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月3日 (六) 04:56 (UTC)
- 拆分投票:
- (+)傾向支持在條目正文中禁用內聯圖像。
- (-)反对一刀切地禁止上色。限制使用過份複雜的上色可以理解,但一刀切的話就過猶不及了。📕📙📒📗📘📚📖 2021年4月3日 (六) 05:12 (UTC)
- 支持要求条目用导航模板使用预设配色。使用其他颜色可以,但应该给出理由;而且这个理由是领域内讨论出的统一的配色方案。像Template:Citrus为什么要上成黄色而不是其他颜色?是属级导航框的统一用黄色,纲级导航框又用另一种颜色;还是觉得这个颜色是柑橘的主题色(那孔雀呢);还是编辑没理由随便上的颜色?而且导航模板和信息框还不一样:条目可以放多个导航模板,随意上色的结果就是花花绿绿,不同颜色搭配起来很不美观。如果其他导航框用默认颜色,比较次要的那个导航模板又私自上色,那它会不会有抢镜头的嫌疑?总之,导航模板上色需要极其保守,找不到必须上色的理由就别上。--洛普利宁 2021年4月3日 (六) 16:13 (UTC)
- 支持樓上所述,另參考各語言維基百科也對上色趨於保守或嚴格規範。即便不全面禁止也需有個合理的規範,哪些領域的確有這需求,哪些領域又該嚴格禁止或者限定。不該完全置之不理任由問題累積未來才以影響範圍大而放棄討論制定規範。~立ち直り中ಇ 2021年4月5日 (一) 12:47 (UTC)
- 上色這種東西如果能夠靠自由心證或常識解決,那就不會有像追夢 Do Re Mi這樣的上色亂象。的確我不是地理條目相關編輯,但前面提到的{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}請問有哪個一定需要顏色?或者說這些顏色必須一定要有的理由為何?(當然也可以直接開民調調查有顏色大家會不會比較OK)。如果這些顏色有一定的存在理由,那就針對這點做改善(例如常用習慣等)。 --Loving You Is A Losing Game 2021年4月5日 (一) 13:11 (UTC)
- 意見頗為分歧,我建議就此進行投票,不知各位意下如何。SANMOSA Σουέζ 2021年4月10日 (六) 06:39 (UTC)
- 這不是投票就能解決的問題,一來是不能只因為視覺障礙人士而選擇單一的樣式,再者是影響範圍過大,投票並不能體現所有使用者的意見(匿名使用者不能投票,請留意維基百科並非專給註冊使用者閱讀)。如果您要發起民調,我沒意見,但是我反對發起投票。 2021年4月10日 (六) 07:05 (UTC)
- 然而現時的狀況確實對視障人士構成嚴重的歧視,我認為所有人現在最基本要知道的就是現時模板的着色情形已經嚴重影響到視障人士的閱讀體驗。投票的選項亦非只有兩種(至少我初步的計劃如是)。在陷入複雜討論的泥潭時,投票顯然是一種快速收集意見以凝聚共識的方法,不能單純因為「影響範圍過大」和「不能體現所有使用者的意見」而反對發起投票和變相剝削視障人士的合理閱讀體驗。SANMOSA Σουέζ 2021年4月11日 (日) 14:26 (UTC)
- @Sanmosa:「影響範圍過大」和「不能體現所有使用者的意見」已經不是您所指的單純問題了。您發起民調來蒐集意見我沒意見,但是要將投票結果作為共識執行,我不能接受。當然您要發起與否是您的自由,如果社群能夠接受結果,那我也沒話說,只是還請留意,我不能接受投票不代表我反對投票,也不代表我變相剝奪視覺障礙人士的合理閱讀體驗,這只是表達我的個人意見,而我的意見是對於此種議題,應該有比投票更能體現共識的方式。 2021年4月12日 (一) 02:31 (UTC)
- 然而現時的狀況確實對視障人士構成嚴重的歧視,我認為所有人現在最基本要知道的就是現時模板的着色情形已經嚴重影響到視障人士的閱讀體驗。投票的選項亦非只有兩種(至少我初步的計劃如是)。在陷入複雜討論的泥潭時,投票顯然是一種快速收集意見以凝聚共識的方法,不能單純因為「影響範圍過大」和「不能體現所有使用者的意見」而反對發起投票和變相剝削視障人士的合理閱讀體驗。SANMOSA Σουέζ 2021年4月11日 (日) 14:26 (UTC)
- 這不是投票就能解決的問題,一來是不能只因為視覺障礙人士而選擇單一的樣式,再者是影響範圍過大,投票並不能體現所有使用者的意見(匿名使用者不能投票,請留意維基百科並非專給註冊使用者閱讀)。如果您要發起民調,我沒意見,但是我反對發起投票。 2021年4月10日 (六) 07:05 (UTC)
- (-)反对Template:元素週期表會無法呈現,更不用說縮圖型導航的Template:NavPeriodicTable,此舉同時也導致了之前色弱友善元素週期表顏色配置Template talk:Isotope nav#同位素模板顏色更換全部白討論了,浪費了社群資源。 考量到需要區分元素本身特性,以下主題有許多層級需要區分
- 元素週期表(Template:元素週期表、Template:NavPeriodicTable)
- 元素穩定性表(Template talk:Isotope nav)
- 元素分區(Template:元素週期表_(正文)#範例)
- 要區分5種以上等級,禁用顏色根本強人所難,無法實行,或實行會導致元素週期表等相關條目無法準確製作示意圖表。-- 五歲抬頭雪菲(☎️·☘️) 2021年4月14日 (三) 19:05 (UTC)
- 同時也反對禁用內連圖像。{{缺字}}、或Unicode未收錄符號、特殊的語言(如克林貢語)和特殊數學符號(如en:Coxeter–Dynkin_diagram、{{CDD}}),全是內連圖像,禁用的話,全部都難以或無法描述條目了。特別是en:Coxeter–Dynkin_diagram,根本不可能用文字描述代表一個en:Coxeter–Dynkin_diagram,要求只能放在圖表將導致內文難以描述,必須在內文呈現符號再加以說明,這個如果禁的話,那我認為數學公式也該禁。仍然堅持,特殊數學符號是有必要跟文字一起使用的。-- 五歲抬頭雪菲(☎️·☘️) 2021年4月14日 (三) 19:32 (UTC)
變通提案[编辑]
以下是小弟的變通提案:
|
|
- 「一種顏色」的定義為一個RGB值。例:#FFFFFF和#FFFFFE視為兩種顏色。
- 「飽和度不能太高」定義為紅綠藍三原色中,任何一種原色數值低於EE。
小弟主要編輯體育相關條目,因此在這裏用個和體育相關的例子:編者在編輯某足球隊的球員名單(表格)時使用的標題背景/文字顏色組合,如果和該足球隊隊徽或主場隊服的配色相同,即視為能夠「幫助闡釋條目內容」。反之,如果編者用的是另一支球隊的隊徽或主場隊服的配色,則視為無助於闡釋條目內容,要麼重新上色,要麼改用預設顏色。舉例說明:加拿大國足的主場球衣(守門員除外)的主色調為紅色(#FF0000或更深),球衣字體為白色,而且紅色和白色之間的差距足夠大,因此加拿大國足的導航模板的標題可以染成紅色背景、白色文字。美國國足的主場球衣的主色調為藍色,因此如果把加拿大國足的導航模板的標題染成藍色背景、白色文字,則視為無助於闡釋條目內容。
以上。📕📙📒📗📘📚📖 2021年4月11日 (日) 03:13 (UTC)
- 暫時認為閣下的提案影響太多:各類模板應限制至條目導航及各類infobox。另建議禁止任何WCAG 2.0中兩種低於2.0的配色分別用於背景及正文。--1233 (T / C) 2021年4月14日 (三) 02:33 (UTC)
- 同一表格、導航模板或信息框模板只能使用一種邊界色、一種標題欄背景色、一種標題欄文字色,且總共不能超過三種顏色」。另外,能否解釋一下怎樣才算「WCAG 2.0中兩種低於2.0的配色」?📕📙📒📗📘📚📖 2021年4月14日 (三) 21:37 (UTC) 已修訂為「
- (-)反对只能使用三種顏色。Template:元素週期表會無法呈現,更不用說縮圖型導航的Template:NavPeriodicTable,此舉同時也導致了之前色弱友善元素週期表顏色配置Template talk:Isotope nav#同位素模板顏色更換全部白討論了,浪費了社群資源。 考量到需要區分元素本身特性,以下主題有許多層級需要區分
- 元素週期表(Template:元素週期表、Template:NavPeriodicTable)
- 元素穩定性表(Template talk:Isotope nav)
- 元素分區(Template:元素週期表_(正文)#範例)
- 要區分5種以上等級,禁用顏色根本強人所難,無法實行,或實行會導致元素週期表等相關條目無法準確製作示意圖表。-- 五歲抬頭雪菲(☎️·☘️) 2021年4月14日 (三) 19:05 (UTC)—- 五歲抬頭雪菲(☎️·☘️) 2021年4月15日 (四) 02:24 (UTC)
- 同時也反對禁用內連圖像。{{缺字}}、或Unicode未收錄符號、特殊的語言(如克林貢語)和特殊數學符號(如en:Coxeter–Dynkin_diagram、{{CDD}}),全是內連圖像,禁用的話,全部都難以或無法描述條目了。特別是en:Coxeter–Dynkin_diagram,根本不可能用文字描述代表一個en:Coxeter–Dynkin_diagram,要求只能放在圖表將導致內文難以描述,必須在內文呈現符號再加以說明,這個如果禁的話,那我認為數學公式也該禁。仍然堅持,特殊數學符號是有必要跟文字一起使用的。-- 五歲抬頭雪菲(☎️·☘️) 2021年4月15日 (四) 02:24 (UTC)
- 例1:小弟已經特地指定了一個「有正當理由,並且能在討論頁自證有理」的例外條件。閣下以上提到的元素週期表導航模板都屬於「正當理由」,因此不受「最多三種顏色」的限制。
- 例2:小弟也指定了例外條件。閣下提及的人造語言字母和數學符號都符合例外的條件,因此不受「禁用內連圖像」的限制。至於Unicode未收錄的符號當中哪些應該禁止,哪些應該允許,都可以慢慢討論。能不能請閣下舉例說明:哪些符號Unicode尚未收錄,卻又在某些條目中非用不可?📕📙📒📗📘📚📖 2021年4月15日 (四) 02:51 (UTC)
- 關於Unicode尚未收錄符號,需要與文字一同描述的就是特殊數學符號(如上方{{CDD}})、化學符號、其他科學表示符號,而所有{{缺字}}、特殊語言也是Unicode尚未收錄符號;Unicode尚未收錄的Emoji確實不必在條目正文中出現(甚至已收錄之Emoji都不該)
- 「編者有理由相信電腦無法正常解碼和顯示」不明確,可能會導致編輯戰,例如某個字原先未被已Unicode收錄,因此使用內連圖像,後來某天被Unicode收錄,然而剛收錄時未被廣泛的字體支援,也許在電腦上看可以正常顯示,然而在iPhone上看都成了豆腐塊,因此使用iPhone的用戶將看起來像豆腐塊的文字回退成內連圖像,而電腦版用戶又將內連圖像回退成在iPhone上看都成了豆腐塊的文字,因而導致編輯戰。例如前陣子剛發命名的幾個化學元素之中文字,在Unicode剛收錄鿫、鿬等字時,發生被改來改去的現象。
- CFOP#下兩層(F2L)中「設法在不破壞其他已完成部分,將一柱轉成
或
。」不使用內連圖像怎麼描述?「設法在不破壞其他已完成部分,將一柱轉成『清楚辨識到可見之兩個面的中心塊與下方塊是相同的顏色,同時,左側最右上方式底面的顏色、上方為左側面的顏色、右方與該面之中心塊同色且角塊右邊的邊塊顏色與左方的角塊同色且方向相同』或『清楚辨識到可減兩個面的中心塊與下方塊是相同的顏色,同時,左側最右上方式做側面中心塊的顏色、上方為右側面的顏色、右方與底面同色且不可見之面之右側面之角塊的頂部顏色與可見面之左側面之中心塊同色』。」這樣的可怕的文字來描述嗎;
- 那麼這種又要怎麼辦「當方塊變為時」({{模板樣式色塊圖}})→「當方塊變為『方塊下兩層已完成,且頂面顏色在頂面上呈
(不用圖片無法表達)形狀時,頂面靠近自己本身的地方是不可見面右側面之中心塊顏色,頂面右側前方(靠近不可見面)兩塊與可見之左側側面同色、頂面左側兩塊與可見之右側側面同色....』時」。(-)反对到時許多條目,不限於魔術方塊都要用可怕的東西描述,WP:太長不看,編者不會想看到一堆廢話,條目失去功能。
- 關於上述提到的
,類似的例子例如俄羅斯方塊,你描述
,文字描述用L型,可是他仍有非常多種變體
不使用內連圖像,怎麼準確表達?
- 關於上述提到的
- Unicode亦有無助於文字表達的字元,用起來跟
這樣的图像沒有兩樣,例如Unicode字符列表#特殊、Unicode幾何圖形列表、方塊元素、麻將字元、撲克牌字元(見章節扑克牌#歷史)...等
- 關於顏色,有的Unicode字元還會自帶顏色,例如Emoji。
- Unicode字符列表#盲文圖案:點字該不該禁?「未收錄點字」
- ※其他關於顏色或Unicode事項待補;會在找到時補充。
- 以上-- 五歲抬頭雪菲(☎️·☘️) 2021年4月15日 (四) 04:17 (UTC)
請閣下留意:
- 同時也反對禁用內連圖像。{{缺字}}、或Unicode未收錄符號、特殊的語言(如克林貢語)和特殊數學符號(如en:Coxeter–Dynkin_diagram、{{CDD}}),全是內連圖像,禁用的話,全部都難以或無法描述條目了。特別是en:Coxeter–Dynkin_diagram,根本不可能用文字描述代表一個en:Coxeter–Dynkin_diagram,要求只能放在圖表將導致內文難以描述,必須在內文呈現符號再加以說明,這個如果禁的話,那我認為數學公式也該禁。仍然堅持,特殊數學符號是有必要跟文字一起使用的。-- 五歲抬頭雪菲(☎️·☘️) 2021年4月15日 (四) 02:24 (UTC)
- (▲)同上。 2021年4月15日 (四) 11:27 (UTC)
- 魔方问题可以像英语维基百科那样用右侧图像,或者像论文那样
<gallery />
加“如图1”。一图胜千言,但没看出图像非要内联的理由。而且、
、
这三个内连例子真心一点都不大方,图片小小、看着眼晕;图片优势没发挥出来不说,还搞到正文稀稀拉拉的。至于Unicode字符列表这种,特殊字符独占单元格的环境,我认为不算内连。--洛普利宁 2021年4月15日 (四) 17:50 (UTC)
- 魔方问题可以像英语维基百科那样用右侧图像,或者像论文那样
- (▲)同上。 2021年4月15日 (四) 11:27 (UTC)
- 這樣就既不需要使用內聯圖像,也不需要單純依賴文字描述。📕📙📒📗📘📚📖 2021年4月15日 (四) 22:14 (UTC)
- 仍然堅持會有需要把文字和圖片放在一起的情況,摺紙的你們還沒回應,我將會繼續尋找,補充一個找了一整晚的
- en:PlayStation (console)#Marketing success:「The console was marketed with advertising slogans stylised as "LIVE IN Y
UR W
RLD. PL
Y IN
URS" and "U R NOT E" (red E).」
- en:Ayumi_Hamasaki#Footnotes(圖片在英文區,中文區暫時無法顯示,請自行前往英文維基查看):「This is the symbol: File:Ayumi Hamasaki A Logo.png. It is used either as a substitute for the letter a or to represent Hamasaki's name. The titles of six albums, Rainbow, A Best, A Ballads, A Best 2 -White-, A Best 2 -Black-, and A Complete use this symbol; the titles of these albums appearing as RFile:Ayumi Hamasaki A Logo.pngINBOW, File:Ayumi Hamasaki A Logo.png Best, File:Ayumi Hamasaki A Logo.png Ballads, File:Ayumi Hamasaki A Logo.png Best 2 -White-, File:Ayumi Hamasaki A Logo.png Best 2 -Black-, and File:Ayumi Hamasaki A Logo.png Complete.」
- en:Arabic_maqam#Ajnas:「Sikah (سيكاه) trichord, starting on E
.」
- 天文學臨時編號:「例如(1) 穀神星被賦予鐮刀的圖形(
)、(2) 智神星是菱形和一個十字(
)、(3) 婚神星起初是維納斯的鏡子之上加上一顆恆星 (
),稍後簡化成一顆星加在十字之上(
),還有(4) 灶神星是宗教祭壇上的火焰(
)」
- 彗星:「彗星的天文學符號是
,由一個小圓盤和三根如頭髮突起的短線段組成」
- 中華民國國語:「1932年教育部在「編定《國音常用字彙》特組會議」時決定,為了便利說明,添補一個注音符號「ㄭ」(
),作為「ㄓㄔㄕㄖㄗㄘㄙ」七個聲母單獨成音節時的省略韻母。另外有三個注音符號ㆭ(-ng)、ㆬ(-m)、
(-n),用作解釋聲隨韻母(ㄢ、ㄣ、ㄤ、ㄥ)時使用,
的字形是ㄋ多加一筆直豎,ㄤ解作ㄚ+ㆭ、ㄥ解成ㄜ+ㆭ、ㄢ為ㄚ+
、ㄣ為ㄜ+
;同理,複韻母ㄞ解為ㄚ+ㄧ、ㄠ為ㄚ+ㄨ。ㆭ、ㆬ、
絕少單獨使用,「嗯」常唸作「˙ㄣ」,也有人唸成「˙
」」
- en:PlayStation (console)#Marketing success:「The console was marketed with advertising slogans stylised as "LIVE IN Y
- (將會陸續補充)
- 仍然堅持會有需要把文字和圖片放在一起的情況,摺紙的你們還沒回應,我將會繼續尋找,補充一個找了一整晚的
- 以上-- 五歲抬頭雪菲(☎️·☘️) 2021年4月16日 (五) 05:23 (UTC)
- 這樣就既不需要使用內聯圖像,也不需要單純依賴文字描述。📕📙📒📗📘📚📖 2021年4月15日 (四) 22:14 (UTC)
- (~)補充另外,關於「」的描述,我認為應該要這樣「方塊下兩層已完成,且頂面顏色在頂面上呈
形狀時....」不然圖像還要引用旁邊另外圖像,真的很詭異。-- 五歲抬頭雪菲(☎️·☘️) 2021年4月16日 (五) 05:40 (UTC)
- CFOP#下兩層(F2L)可以改成如下形式:
「設法在不破壞其他已完成部分,將一柱轉成以下兩種形式之一(圖1.1和圖1.2):」
![]() |
![]() |
圖1.1 | 圖1.2 |
---|
- 另:@Lopullinen、1233:小弟新增了無正當理由禁止使用什錦字型或繪文字的條文,請回應。📕📙📒📗📘📚📖 2021年4月16日 (五) 06:19 (UTC)