Wikipedia:互助客栈/方针：修订间差异

以互动方式浏览历史

←上一版本下一版本→

删除的内容添加的内容

可视化wikitext

行内

2021年4月21日 (三) 03:38的版本

快捷方式

此頁面探討维基百科的方針與指引。

有關繁简处理的议题，请前往字词转换讨论页留言。
有關条目本身內容的議題，请前往条目探讨區留言。
由於互助客棧討論踴躍，經常遭遇載入及儲存過慢等困難，建議先於對應政策的计划頁面發起討論，並徵求廣泛意見（↓查閱相關議題）；若無人加入討論，或本來涉及較少具體修訂內容者，則亦可直接在此提案。

請注重礼仪、遵守方針與指引，一般問題請至互助客棧其他區或知识问答提出，留言后请务必签名（点击）。

發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

議題最後回應時間為1月3日之前（正在公示者除外）或者該議題已經標記為結束達三日，則該議題會存檔至相關討論頁或存檔頁。討論存檔至相關討論頁後，相關討論標題則會於一日後存檔。跳至本頁的：目錄 · 底端

公告欄

[公告] 「关注度」更名为「收录标准」、《字词转换处理》指引事实性修订、实装Automoderator工具、更新管理员布告板排版、明確香港街道名為譯名可靠來源的一種、規範中文維基百科內「貨物駅」與「貨物ターミナル駅」兩詞的譯法及電子遊戲與日本動漫條目命名的標點符號使用規定已經通過。
[公告] 修订申请成为管理人员方针、被不限期封禁用户不应默认复审移除IP封禁豁免权限、修订过滤器警告信息、調整現行用戶頁指引條文規定的定義及将每日提示内容同步到首页提示版块展示正在公示，如有意見請儘快提出。
[討論] 互助客栈方针区正在討論是否將格式手冊移動到MOS命名空間下、重提為可供查證方針與可靠來源指引調整有關用戶生成內容的規定、关于条目命名常规中纳入中立性的考虑及提議將所有子命名常規與命名常規提案頁面的名稱格式一概改為子頁面的名稱格式，請踴躍參與討論。
[討論] 互助客栈其他区正在討論Automoderator配置、2025新年徽标及是否应关闭中文维基百科以抗议基金会举措，請踴躍參與討論。
[討論] 互助客棧試行案討論區正在討論討論遞進機制試行案-檢討意見分享，請踴躍參與討論。

[協作] 现有138个页面需维基化，418个条目需清理，37个移动请求正在讨论。
[獎勵] 現有1名用户獲提名维基奖励，欢迎投票。

存檔

2003年至2010年
2003年	5月以前					6	7	8	9	10	11	12	月
2004年	1	2	3	4	5	6	7	8	9	10	11	12	月
2005年	1	2	3	4	5	6	7	8	9	10	11	12	月
2006年	1	2	3	4	5	6	7	8	9	10	11	12	月
2007年	1	2	3	4	5	6	7	8	9	10	11	12	月
2008年	1	2	3	4	5	6	7	8	9	10	11	12	月
2009年	1	2	3	4	5	6	7	8	9	10	11	12	月
2010年	1	2	3	4	5	6	7	8	9	10	11	12	月

2011年至2020年
2011年	1	2	3	4	5	6	7	8	9	10	11	12	月
2012年	1	2	3	4	5	6	7	8	9	10	11	12	月
2013年	1	2	3	4	5	6	7	8	9	10	11	12	月
2014年	1	2	3	4	5	6	7	8	9	10	11	12	月
2015年	1	2	3	4	5	6	7	8	9	10	11	12	月
2016年	1	2	3	4	5	6	7	8	9	10	11	12	月
2017年	1	2	3	4	5	6	7	8	9	10	11	12	月
2018年	1	2	3	4	5	6	7	8	9	10	11	12	月
2019年	1	2	3	4	5	6	7	8	9	10	11	12	月
2020年	1	2	3	4	5	6	7	8	9	10	11	12	月

2021年	1	2	3	4	5	6	7	8	9	10	11	12	月
2022年	1	2	3	4	5	6	7	8	9	10	11	12	月
2023年	1	2	3	4	5	6	7	8	9	10	11	12	月
2024年	1	2	3	4	5	6	7	8	9	10	11	12	月
2025年	1	2	3	4	5	6	7	8	9	10	11	12	月

早於10（未完成）或3（已完成）日的討論將會由存檔。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	將WP:格式手冊所有方針與論述移動到MOS命名空間，並將MOS命名空間更名為「格式手冊」	71	12	A2569875	2025-01-07 19:31
2	提議維基百科:抄襲併入維基百科:不要包含原始資料的副本	63	10	Sanmosa	2025-01-07 07:57
3	提議DYK/GA/FA引入cooldown time(或譯冷靜時間)	197	13	Hotaru Natsumi	2025-01-03 14:18
4	WP:SW	1	1	Jimmy-bot	2025-01-13 00:14
5	重提為可供查證方針與可靠來源指引調整有關用戶生成內容的規定	50	10	Sanmosa	2025-01-12 21:57
6	可否在標題置入繁體地區詞的簡體字／簡體地區詞的繁體字？	55	6	神秘悟饭	2025-01-12 18:30
7	現行用戶頁指引條文規定的定義問題	19	3	Sanmosa	2025-01-07 08:50
8	緊急修正快速刪除O1款	9	3	自由雨日	2025-01-04 17:25
9	WP:RELIST	30	13	Hotaru Natsumi	2025-01-10 01:42
10	提議將WP:關注度改名	295	59	S8321414	2025-01-13 07:38
11	移动时不留重定向、大面积红链与批量清理链入	9	5	Hotaru Natsumi	2025-01-03 16:33
12	“无有效合理固定收录标准”是不是删除导航模板的充分理由？	1	1	Sanmosa	2025-01-03 19:47
13	提議廢除{{深夜動畫}}模板	12	6	Cwek	2025-01-09 11:26
14	关于条目命名常规中纳入中立性的考虑	16	7	Cwek	2025-01-09 11:18
15	将MOS:AWW成为中文维基百科的正式指引	12	8	PexEric	2025-01-11 17:27
16	源代码中空格的规范以及相关编辑行为的定性	10	7	Kcx36	2025-01-09 21:05
17	有關修改濫用過濾器權限的提案	93	17	Tigerzeng	2025-01-12 23:28
18	关于WP:文明	15	5	Ericliu1912	2025-01-11 02:07
19	全站禁制條文增補	8	4	人间百态	2025-01-11 20:13
20	WP:A1措辭問題	28	4	自由雨日	2025-01-13 03:23
21	提議將所有子命名常規與命名常規提案頁面的名稱格式一概改為子頁面的名稱格式	19	6	Sanmosa	2025-01-13 07:58
22	请求规范信息框标题处旗帜使用	2	2	YFdyh000	2025-01-13 00:25

發言更新圖例
最近一小時內
最近一日內
一週內
一個月內
逾一個月
特殊狀態
已移動至其他頁面或完成討論之議題
手動設定
當列表出現異常時，請先檢查設定是否有誤

正在廣泛徵求意見的議題

您可在回饋請求系統訂閱以收取特定主題相關討論通知。

議題清單

以下討論需要社群廣泛關注：（重新整理）維基百科格式與命名

Wikipedia talk:條目命名一致性決議 § 有關日本內閣條目的命名問題

現時，各國家／地區（非國家之獨立或高度自治政治實體）內閣條目的命名格式一般為“第X次某某某內閣”，如第二次蘇貞昌內閣（臺灣）、第二次約翰遜內閣（英國）、第四次默克爾內閣（德國）等，由此可見“第X次某某某內閣”是各國家／地區（非國家之獨立或高度自治政治實體）內閣條目的通用命名格式，而且也符合中文的使用慣例。然而，日本內閣條目的命名在2022年10月6日被TKsdik8900由“第X次某某某內閣”批量移動至“第X屆某某某內閣”，我認為這種表達方式不合中文的使用慣例（尤其是他把“第X次改組”也改成“第X屆改組”的舉動完全有悖於中文文法），而且在內閣條目的命名一般通用“第X次某某某內閣”的格式的情況下，此舉也有悖於條目命名一致性的要求。因此，我認為中文維基百科現有的日本內閣條目的命名應該批量移回或移至“第X次某某某內閣”格式的名稱，此外條目名稱帶“第X屆改組”字樣者亦應改回“第X次改組”。San mo sa _新朝雅政 2024年12月4日 (三) 14:09 (UTC)

Talk:天安门广场 § “位置与面积”章节显示大片空白

如图--Tjw123hh（留言） 2025年1月6日 (一) 16:57 (UTC)

維基百科方針與指引

Wikipedia talk:互助客栈 § 有關互助客棧方針版的長度壓力問題

此前，互助客棧方針版的長度一度逾60萬位元組，在我搬運了若干已結束或stale了的討論後才降到40多萬，然而這個長度還是比起其他互助客棧的版塊來得長（互助客棧其他版的長度現在是20多萬位元組，條目探討版是10多萬，消息、技術與求助版不超過10萬），而且在頁面載入與編輯上也產生了一些問題（我在電腦嘗試載入或編輯頁面的話，頁面完全載入所需的時間顯著地延長了）。有鑒於此前曾有討論提議以WP:徵求意見機制取代互助客棧方針版的機能，我認為現在是合適的時機來提出這件事情。San mo sa _新朝雅政 2024年10月23日 (三) 00:30 (UTC)

Wikipedia talk:保護方針 § 對於全保護的一些建議

對《破·地獄》現在的全保護有感，覺得需對管理員提出一點意見。我對全保護的觀感，始於2023年3月《中年好聲音》，在播映期間因部分延伸確認用戶發生編輯戰而全保護3個月之久，過長的全保護漠視了其他沒有參與編輯戰用戶的權利，且當時交戰雙方在對方的個人討論頁進行指責，卻沒有人試圖在條目討論頁發起討論，連事後其他人追溯到底發生過什麼事都有困難。這次破·地獄全保護的時長合理，但一般人根本難以注意有討論存在於Wikipedia:互助客栈/条目探讨#電影條目過度收錄問題，希望管理員也能多做一點促進討論。就此，我建議如下：

全保護後如未有人發起討論，管理員可在條目討論頁發起，通知有關用戶。
如管理員得知已有人發起相關討論，但並非在條目討論頁，管理員可在條目討論頁留下連結。
保護模板可否進化一下，能加入相關討論連結？--Factrecordor（留言） 2024年11月24日 (日) 12:33 (UTC)

Wikipedia talk:维基百科不是什么 § 出版書籍、雜誌是否為WP:NOT

如題所述，請教以下情況甚麼時候屬WP:NOT及判定依據?

A)條目收錄自行出版之書籍或論文(有一手來源、但沒有二手、三手來源)；
B)條目收錄自行出版之書籍或論文(有二手、三手來源)；
C)條目收錄~~非自行出版~~之雜誌，雜誌內容包括照片、採訪(有一手來源、沒有二手、三手來源)；
D)條目收錄~~非自行出版~~之雜誌，雜誌內容包括照片、採訪(有二手、三手來源)；
E)條目收錄~~非自行出版~~之雜誌，雜誌內容包括照片，但沒有採訪(有一手來源、沒有二手、三手來源)；
F)條目收錄非自行出版之雜誌，雜誌內容包括照片，但沒有採訪(有二手、三手來源)；--Abcet10（留言） 2024年12月4日 (三) 14:31 (UTC)

Wikipedia talk:用戶框 § 应根据WP:用戶頁对WP:用戶框进行修订

从范围上来看，用户框是用户页的子集。用户框的内容也应受到WP:UPNOT的限制。想起这一点是因为近日又有新用户（Carl66066）连续建立多个在我看来并不合适的用户框。以该用户此前的用户页为例：

视觉效果十分糟糕：颜色搭配不当，背景颜色和文字颜色接近，文本框宽度参差不一；
反复宣告自己的观点：使用大量文本详细描述自己的观点，而这些观点基本上与维基媒体运动及社群协作毫无关联；
名称不明确：模板名称与文本内容不相符，或存在歧义。

由于类似的编辑者以往也存在，我认为有必要按照WP:UP修订WP:UBX，把Template:Subcat guideline-en从WP:UBX移掉，对目前的用户框进行整理，将文本内容过于注重表达个人意见的改为中性的陈述或简单的宣告，无可救药的模板批量送存废。——暁月凛奈 (留言) 2024年12月4日 (三) 15:19 (UTC)

(＋)支持。另外除了根据中维的《WP:用户页》修订之外，也可以根据目前英维的en:WP:Userboxes修订？因为似乎中维的版本有些落后了…… ——自由雨日🌧️❄️ 2024年12月4日 (三) 15:27 (UTC)

Wikipedia talk:收錄標準/音樂 § 重新讨论NT:MUSIC

各位编辑，在下长期以来在浏览编辑维基百科的过程中，发现存在大量的近似爱好者内容，这些作品大多以单曲、演唱会和部分音乐综艺节目为主，通常无法证明其关注度，内文更是不重要的内容堆砌。但是，这些条目又往往能绕过当前NT:MUSIC的相关论述，使编者很难在存废问题或其他条目编辑问题上达成共识。依在下所见，当前的NT:MUSIC至少存在以下问题：

在关于来源的问题上，现今条文是他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及，但是根据中国大陆当前现状，由于充斥大量的内容农场和宣传内容，使许多看似可靠来源实则存在潜在的不中立现象，如自己按门铃自己听中的中国网来源（《歌手·当打之年》今晚终极奇袭周深首秀未发布新曲）之类，在下看不到任何属于可靠来源的证据。
在关于音乐作品的内容中，维基百科:商业排行与认证是部分维基编者编辑部分单曲条目的重要依靠，但是中国大陆的音乐榜单要么是平台的自嗨、要么是粉丝的刷榜，毫无公信力可言。如被部分编辑推崇的腾讯音乐由你榜，就曾被举报过开通年会员可大大提高用户打榜（主要包括播放、收藏、下载、分析、点赞歌曲等）权重（1），并且该榜单仅限腾讯拥有版权的音乐，此类排行榜获得什么周榜月榜第几名、有多少可信度自有公论，其他类似网易、酷狗等等推出的野鸡榜单更是不用再浪费时间。
另外，在相当多内容的条目中存在大量毫无意义的内容，几乎要把维基百科变成Fandom。如“天外来物”世界巡回演唱会中什么“衢州新闻媒体中心在抖音官方账号上发布了视频，表达了对薛之谦的感谢”、自己按门铃自己听中类似“周深在演唱的時候，身穿一件珍珠裝飾的牛仔夾克，搭配黑色T恤和牛仔褲亮相”的表述，在下看不出放在条目内的必要。
现存的NT:MUSIC中没有关于演唱会关注度的表述。

综上所述，现存的NT:MUSIC及其他相关页面均为论述或指引，并且部分表述相当模糊，大量的条目游走在关注度的边缘，因此在下建议社群对上述内容进行重新讨论并争取达成共识并升格为方针。由于刚刚提起讨论，在下暂不提出新的方案内容，待社群讨论后再进行总结。--SheltonMartin留言|签名 2024年12月11日 (三) 01:22 (UTC)

Wikipedia talk:消歧义 § 没有目标条目的独立消歧义页

参见Wikipedia:消歧义，一般独立消歧义页，应该列出存在和消歧义名相同的目标项目的链接，例如“XXX”为名，则存在“XXX (AAA)”、“XXX (BBB)”的列项和目标链接，但@Sdf：创建了若干不属于这种情况的独立消歧义页，主要是虚构作品内姓名相同的角色名（秋山美月、三千院帝），这些角色至少暂时不太可能创建符合关注度的独立条目，是否视为类似全红链的独立消歧义页不保留？——Sakamotosan路过围观 | 避免做作，免敬 2024年12月12日 (四) 12:28 (UTC)

反对删除，参见w:MOS:DABMENTION。英文版有类似的：w:Maggie Anderson (disambiguation)--GZWDer（留言） 2024年12月12日 (四) 12:49 (UTC)

Wikipedia talk:申请解除权限 § 被不限期封禁用户不应默认复审移除IP封禁豁免权限

此討論正在公示7天；如有意見請儘快提出。

Wikipedia:申请解除权限在议的多项提议和既往“判例”表明，永封用户经由“已封禁或除权用户复审”快速剥夺IPBE权限。然，本站用户对IPBE权限的使用多是因为GFW封锁下被迫使用代理编辑，为正常编辑所必须之权限，在用户尚未被移除编辑其讨论页权限前移除其IPBE权限在实践上剥夺了被封禁用户编辑其讨论页进行初步申诉的能力，显然是越俎代庖。此外，依据Wikipedia:IP封禁豁免#移除權限一节，被封禁用户虽可能已不被社群信任，但亦不太可能滥用其权限（IPBE），被完全封禁的用户的权限也会因为不活动而自动移除，并无主动快速移除其IPBE权限的必要性。综上所述，提议：

現行條文

提議條文

出于保留受GFW影响的用户在被封禁后使用其讨论页进行申诉的能力，对于拥有IPBE权限的无限期封禁用户，在无证据证明该用户可能滥用其IPBE权限的情况下，不应在其被不限期禁止编辑其讨论页前主动移除其IPBE权限。

此提议需要熟悉反破坏工作（如傀儡调查）的社群成员讨论，另ping之前在布告板参与讨论的@自由雨日、Ericliu1912、Allervous、Manchiu、阿南之人。--HeihaHeihaHa-戒慎恐惧……（留言） 2024年12月13日 (五) 13:40 (UTC)

Wikipedia talk:管理员布告板/其他不当行为 § 控制複雜ANM案例

提議對WP:ANM過長的案例進行分子頁討論，現在部分案件是長的，目的是WP:ANM作爲目錄，有連接到每一個子頁面，這樣頁面分離會好一些。 -Lemonaka 2024年12月20日 (五) 00:46 (UTC)

Wikipedia talk:维基百科不是什么 § 修改WP:SOAP

所謂維基百科不是宣傳工具，應適用於所有命名空間，假使今天一個帳號到處投放支持蔡英文，反對國民黨之類的話語，投樣100個帳號，有52個支持，那今天就合理的在52個使用者討論頁上宣傳，因此建議

現行條文

維基百科拒絕宣傳。維基百科不是演講台、論壇、宣傳工具、廣告場所或者展覽平台。此項適用於使用者名稱、條目、分類、檔案、討論頁、模板及使用者頁面。因此，請勿於維基百科：

提議條文

維基百科拒絕宣傳。維基百科不是演講台、論壇、宣傳工具、廣告場所或者展覽平台。此項適用於所有命名空間。因此，請勿於維基百科：

這樣可以有效避免宣傳，惟其需待社群討論，祝編安。-- A0_{(討論·簽名)} 2024年12月22日 (日) 01:48 (UTC)

Wikipedia talk:道路特殊收錄限制列表 § 建議更名：「Wikipedia:道路特殊收錄限制列表」→「Wikipedia:收錄標準/交通/道路特殊收錄限制列表」

既然都是交通收錄標準的子集了，我覺得放在子頁面比較合理吧？--Sun After Rain 2025年1月12日 (日) 06:08 (UTC)

維基百科提議

Wikipedia:互助客栈/其他 § 在本地啟用安全投票及electionadmin权限

（我很抱歉用英语写作。请随意翻译此消息。）

Hello! My name is Joe Sutherland and I'm on the Trust and Safety team at the Wikimedia Foundation. In the past, your community has shown interest in holding elections with SecurePoll — perhaps you already have through votewiki. We are now looking into making this available to local communities to run elections themselves. This will require the "electionadmin" right to be enabled on your project, which is a right that allows access to sensitive information.

As such, it is likely that you will need to run a Request for Comment (or similar process) to ascertain consensus for the implementation of this feature. To help guide such a discussion, we've put together a Meta-Wiki page with more information about what enabling the right will mean for your community.

If your community does discuss and decides to move forward with this, T&S would like to support you — please let us know via email ( ca@wikimedia.org ) if and when consensus is reached. Thank you!--JSutherland (WMF)（留言） 2024年10月17日 (四) 20:07 (UTC)

Wikipedia:互助客栈/其他 § 重启Automoderator部署讨论

於Phabricator查看
編號T367306的工單

十余月前，该讨论向社群引介了自动化反破坏Automoderator工具，然其因热度不足而无疾而终。因此，我谨引用原留言：

大家好，我的名字是Sam Walton，是管理员工具（Moderator Tools）团队的产品经理。我们正在开发一个名为Automoderator的项目，该项目让社群能够根据社群自定义的规则自动回退破坏性编辑。我们正在寻求对我们项目的意见，并有一些问题需要巡查员和管理员的参与，以帮助我们更好地理解。除了项目主页面上的概述和问题之外，我们还有两个子页面提供更具体的资讯：
如果您想研究Automoderator的准确率，并查看它在不同编辑上的表现，我们设置了一个测试流程。您可以帮助我们找到新的模式，并在Automoderator部署之前将其纳入考虑范围（译注：例如怎样改善误判问题、使用什么程度的准确率（cution levels）比较好）。评估计划是用来确定Automoderator是否实现目标且不会产生负面影响的计划初稿。如果您对我们收集的数据或制定的指标有任何想法，那么您可以在这里分享！
如果您对Automoderator有任何疑问，或者您的社群是否想要使用这个工具，请告诉我！
— User:Samwalton9_(WMF)

还请社群评估该工具部署之可能性及价值为荷。——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月18日 (三) 19:45 (UTC)

專題命名空間

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间（錯誤：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向頁面）。

[編輯此導航模板] 設立新命名空間及偽命名空間無共識：2018年12月的先前討論全案結以待續：第一輪討論 - 開放偽命名空間作捷徑連結用結以待續：設立LTA、MOS、PJ三個偽命名空間結以待續：升格維基專題為命名空間結以待續：修正命名空間資訊頁面結以待續：將「Wikipedia:捷徑」訂為方針完結：第二輪討論完成部署：設立專題命名空間相關討論及任務已通過：討論升格維基專題為命名空間任務完成：向Phabricator申請部署維基專題命名空間已合併：在Gerrit提交所需修正編碼任務完成：在Phabricator請求合併編碼完成：事實性修訂「Wikipedia:命名空間」以包含新的維基專題命名空間完成，待檢查：將專案命名空間下的維基專題移動至維基專題命名空間專題移動列表專題重定向移動列表已完成：修正指向專題的內部連結機器人任務已完成：調整專題模板已通過：討論捷徑的設立方式已通過：其他議題討論完結：設立偽命名空間相關討論已通過：討論設立LTA及MOS偽命名空間供捷徑使用已否決：設立捷徑空間供LTA/MOS捷徑使用已否決：設立捷徑空間作其他用途結以待續：升格LTA為命名空間完結：後續討論處理事項完成：修改機械人操作不提刪偽命名空間捷徑無結論：格式手冊新捷徑名稱討論 MOS捷徑列表已否決：舊捷徑改為軟重定向完成：設置預設啟用小工具已否決：自動半保護偽命名空間條目已通過：提議設立新快速刪除標準完結：第三輪討論已否決：捷徑命名空間已完成：捷徑指引草案修訂已通過：增設更多偽命名空間（一）已通過但未實行：第三次推动设立LTA命名空间

本主題全部或部分段落文字，轉移自Wikipedia:互助客栈/方针#WP:捷徑指引草案修訂。执行人：臺灣杉在此發言 (會客室)。標記人：_{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:44 (UTC)。[回复]

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

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

本討論的各階段分為：

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

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

專題命名空間通過，剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (UTC)[回复]

目前的後續討論須等phab:T271612佈署完畢後才能繼續進行。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月12日 (二) 13:08 (UTC)[回复]

說明稍微看了一下先前韓文維基的申請phab:T29651，其工程師處理的流程將近一個月，故認為應該還要一段時間才能完成布署，故暫時先撤下公告Special:Diff/63712969、Special:Diff/63713130，等到了Code Review階段時再放回。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:18 (UTC)[回复]
- 完成：程式碼已Commit到gerrit:657572，並已佈署，恢復原有公示，基於原有時間再延長3天。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月26日 (二) 20:03 (UTC)[回复]
- (補)：更新，WP:偽命名空間已通過。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月17日 (三) 06:41 (UTC)[回复]

已通過：

已

公示7日無合理異議，本議案通過。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 07:44 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

先前討論

(＝)中立，但此僅為其中一個被提議的偽命名空間提供了替代方案，那麼另外的LTA:和MOS:呢？--LuciferianThomas．留言 2020年11月16日 (一) 09:32 (UTC)[回复]

一個一個來。肯定會有方法的。pj是有多個維基實行過，且效果不錯，可行性較高，也不會混淆。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月16日 (一) 13:10 (UTC)[回复]

好的。(＋)傾向支持吧，始終我不太清除其他維基項目對此的執行，不過覺得與維基空間的內容有點距離，可以自己分離了。--LuciferianThomas．留言 2020年11月16日 (一) 15:19 (UTC)[回复]

LTA和MOS感覺不足以達到獨立名字空間門檻，且其他語言維基也沒先例，故不提案。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月16日 (一) 15:32 (UTC)[回复]

意思使用新建一個「專題」的空間，把Wikipedia:ACG專題移動到專題:ACG；然後把PJ作為「專題」名字空間的別名？--洛普利宁 2020年11月16日 (一) 16:01 (UTC)[回复]

从这个动议的内容上看应该是这个意思，开辟一个“WikiProject”空间，简称"PJ"，中文为“专题”和“维基专题”--MilkyDefer，推迟，咕咕 2020年11月16日 (一) 16:11 (UTC)[回复]

大概就類似User:青子守歌用戶頁裡面的ja:利用者:青子守歌/frwpのウィキプロジェクト名前空間と参考文献名前空間。日文維基佈署很久，沒甚麼太大的問題。且專題:ACG比Wikipedia:ACG專題淺顯多了，並也允許PJ:ACG這樣的連結方式。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月16日 (一) 17:24 (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)[回复]

不是偽，是「真」。「專題:數學」顯然比「維基百科:數學專題」更簡潔。見日語維基和法語維基。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月27日 (五) 08:05 (UTC)[回复]

等等，PJ:和P(ortal):的区别我没太搞清。哪位可以解释一下？Zhuofan Wu^{Cien años de soledad} 2020年11月29日 (日) 03:08 (UTC)[回复]

“

与专供维基编者使用的维基专题不同，维基主题是同时为编者及一般读者服务的。

”

—— Portal:首页

——羊羊 (留言|贡献) 2020年11月29日 (日) 04:11 (UTC)[回复]

一個是Portal，一個是Project。--臺灣杉在此發言 (會客室) 2020年11月29日 (日) 08:31 (UTC)[回复]

如果要細節的話：Portal（主題）有點類似各知識領域的主頁，展示該領域重要或優良的條目之用；Project（專題）則是說明該領域知識的編輯建議與規則，以及該領域社群的討論場所。臺灣杉在此發言 (會客室) 2020年11月29日 (日) 10:07 (UTC)[回复]

Wait，有bug。Project命名空間在中文維基百科等價於Wikipedia命名空間。SAN MO SA _SPQR 2020年11月29日 (日) 14:24 (UTC)[回复]

不成問題，見日維相關討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月29日 (日) 14:28 (UTC)[回复]

那倒不如直接設PJ命名空間在中文維基百科等價於Wikipedia命名空間（如同WP命名空間），反正各專題現時皆在Wikipedia命名空間下，這樣會較能保持一致性，也不會衍生Project的指代問題。SAN MO SA _SPQR 2020年11月29日 (日) 14:33 (UTC)[回复]

那这样起不到“减少命名冲突”的效果…… ——羊羊 (留言|贡献) 2020年11月30日 (一) 22:06 (UTC)[回复]

@Sanmosa：見下-- Sunny00217 2020年12月2日 (三) 14:25 (UTC)[回复]

我在这里作出过的留言可供参考。--MilkyDefer，推迟，咕咕 2020年11月29日 (日) 16:16 (UTC)[回复]

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

(？)疑問@Taiwania Justo：所以有沒有要建專題空間？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月9日 (三) 13:56 (UTC)[回复]
還在整理中，不過順序是這樣：先調查LTA、MOS和PJ是否升格為正式空間，第二層是偽命名空間，第三層是捷徑修訂。--臺灣杉在此發言 (會客室) 2020年12月9日 (三) 14:57 (UTC)[回复]
@Taiwania Justo：仍然建議從專題（PJ）空間開始會比較容易。畢竟日維和法維等維基有專題:名字空間，代表我們可以參考他們的建置過程及申請方式；然而LTA:和MOS:目前似乎沒看到有其他語言維基百科或姊妹計畫有此「真」名字空間設定，代表建置過程及申請方式全部都是要由我們本地自己建，難度會比較高。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月9日 (三) 17:07 (UTC)[回复]

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

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

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

个人以为Project名字空间肯定不能变，否则可能会造成不少链接失效。因此名字空间应该命名为“WikiProject”，对应的中文名字空间应该命名为“维基专题”，以便于与“WikiProject”对应。——BlackShadowG（留言） 2020年12月11日 (五) 16:27 (UTC)[回复]
- 我認為中文叫做「專題」並無不妥，也無衝突。將「WikiProject:」作為程式系統前綴；「專題」、「維基專題」、「PJ」作為別名。其他中文別名也可以之後再議再補。並依照法維和日維和其他姐妹計劃的統一定義，定為{{ns:102}}(目前顯示為「WikiProject」，空白是因為本地尚未實裝）。— ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月11日 (五) 18:16 (UTC)[回复]

確定英文名稱不會衝突就可以，中文名稱應該沒問題。SAN MO SA _SPQR 2020年12月12日 (六) 03:34 (UTC)[回复]

支持命名为WikiProject/专题 ——羊羊 (留言|贡献) 2020年12月16日 (三) 15:08 (UTC)[回复]

若自羊羊32521留言2020年12月16日 (三) 15:08 (UTC)的一周後未有新意見可以先公示這個部分。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月22日 (二) 07:55 (UTC)[回复]

公示7天：理據：本議題先前公示並通過的討論已討論滿一個月，且自本討論上次有效發言羊羊32521留言2020年12月16日 (三) 15:08 (UTC)已逾一周，根據WP:7DAYS公示七天。如通過，屆時具體的做法可以參考phab:T26852 -- _{來人啊，餵宮子吃布丁！} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月24日 (四) 08:47 (UTC)[回复]
- 公示什么？ ——羊羊 (留言|贡献) 2020年12月26日 (六) 10:21 (UTC)[回复]
  - @羊羊32521：將專題升為名字空間啊（公告欄上有）主要是細節，程式名稱定為WikiProject、然後「專題」、維基專題、PJ作為別名，並且參考phab:T26852將Namespace id 設為102討論頁以此類推（WikiProject_talk;103;專題討論,維基專題討論）。其餘請參考先前討論、發布公示的留言以及公布欄，另補充一個2018年在WP:TG上討論出的草案。— ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月26日 (六) 12:47 (UTC)[回复]
專題這種東西本來就都沒有什麼用戶在關注了。所以什麼都不問，只問一個問題：請問這樣一來那些原本已經用於條目討論頁上的專題名稱會不會有影響？--Z7504非常建議必要時多關注評選（留言） 2020年12月31日 (四) 08:42 (UTC)[回复]
- @Z7504：例如WP:ACG专题會變成專題:ACG（_{現在先不要改哦，會違反快速刪除方針準則}）。以此類推。此外本議題先前公示已經通過了，這次是細節公示。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月31日 (四) 09:43 (UTC)[回复]
既然木已成舟，大家意見如此，我也沒法反對什麼，但是請提案者一定要做好配套措施，以免留給本地社群一堆爛攤子去收。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2020年12月31日 (四) 11:32 (UTC)[回复]
- 參考日文維基當時做法，預計會分階段完成設立，不會留爛攤子。但需要一些時間來執行。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月1日 (五) 19:19 (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)[回复]

專題空間已於本地生效，準備進行頁面移轉。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 04:10 (UTC)[回复]

第一階段：申請

已通過：

已通過公示，亦完成布署（前端 by User:AnYiLin、後端 by User:A2569875），專題名字空間已於中文維基百科生效，將立即進行下一階段討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 04:06 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

於Phabricator查看
編號T271612的工單
狀態：已解決

將會提供給phab:的細節如下：

	名字空間	討論空間
內部名稱 (前綴)	WikiProject:	WikiProject_talk:
ID	102	103
中文名稱 (介面名稱)	維基專題	維基專題討論
別名	專題专题維基專題维基专题 PJ WPJ	專題討論专题讨论專題對話专题对话維基專題討論维基专题讨论維基專題對話维基专题对话 PJT WPJT

-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 09:41 (UTC)[回复]

我觉得中文名称叫“专题”更简洁一点…… ——羊羊 (留言|贡献) 2021年1月3日 (日) 14:02 (UTC)[回复]
- 這個名稱是參考User:BlackShadowG的提議。@BlackShadowG：關於羊羊32521的意見，您有甚麼看法？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 14:10 (UTC)[回复]
  - 在我看来，名字空间的中英文应该对应，这样可以避免误解。如果中文名称定为“专题:”那英文名称应该对应为“Project:“才对，然而“Project:”早已被用为“Wikipedia:“的别名了。——BlackShadowG（留言）维基百科20周年庆即将到来 2021年1月4日 (一) 14:43 (UTC)[回复]
    - @BlackShadowG：不认为需要严格对应。对应“专题”是“Topic”才对，“Project”是项目/工程/专案/方案。--YFdyh000（留言） 2021年1月4日 (一) 14:47 (UTC)[回复]
      - 該中文名稱僅是「介面顯示名稱」其如何設定並不會影響運作。但仍需要決定一個顯示名稱以讓介面管理員設定。若無法做出決定可能要像日文維基一樣開個名稱投票，然而由於WP:投票不能代替討論，因此不建議這麼做。當然，這不影響命名空間的申請與設定，因為Phab那邊只管內部名稱，而內部名稱「WikiProject:」已公示通過；介面名稱可以取得共識後再由WP:介面管理員於本地設置。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月4日 (一) 15:15 (UTC)[回复]
  建议名字空间内部名用英文，以免出现繁简问题。--GZWDer（留言） 2021年1月3日 (日) 16:18 (UTC)[回复]
  - (：)回應@GZWDer：參見上表，內部名稱（前綴）在最初的公示時（去年11月）就已經決定定義為英文「WikiProject」了。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 16:23 (UTC)[回复]
- (：)回應@羊羊32521：該名稱主要是介面顯示的名稱（如左上角顯示[維基專題][討論][不转换]_____[閱讀][編輯][歷史]☆[更多∇][TW∇][搜尋維基百科🔍]），而關於簡潔與否問題，由於有同步申請別名，因此亦可以透過輸入專題:XXX連結到專題頁，並不一定要寫全名維基專題:XXX（參考預計命名）。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 19:42 (UTC)[回复]
  - (？)疑問@羊羊32521：您可以接受上面的解釋嗎？；@YFdyh000：那個中文名稱實際上是對應介面顯示名稱—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月5日 (二) 05:52 (UTC)[回复]
    - @A2569875：Y行 ——羊羊 (留言|贡献) 2021年1月5日 (二) 15:22 (UTC)[回复]
      - 不解，這種東西為什麼需要用什麼「申請」？不是都通過了？那這樣公示是什麼意思？--Z7504非常建議必要時多關注評選（留言） 2021年1月6日 (三) 02:27 (UTC)[回复]
        @Z7504：要去phab:提申請，才會有工程師建立啊。舉個例子：台北市政府通過建造某條捷運，請問還沒向工程單位申請建造捷運路線，捷運路線就會自己冒出來嗎？從天上掉下來？怎麼可能。這邊主要是技術細節討論，完成後向技術分站提工單，通過是指社群共識通過，不意味著工程師理解具體要怎麼執行社群共識，現在就是要討論怎麼讓工程師理解具體怎麼操作，就這樣。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️）
        您有沒有看到關於上方具體要給工程師設定技術細節的部分還在討論，現在就是要處理程式碼具體技術上設定的部分。我想一氣呵成，不想變成有缺漏還要補提多張工單浪費時間，現在的討論正是這個目的。且技術細節討論只有公示通過後討論才有意義，如前次公示沒有通過，討論技術上程式設定也是白費功夫紙上談兵。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 05:37 (UTC)[回复]
        理解，不過phab這個不怎麼在看，就不贅述了。--Z7504非常建議必要時多關注評選（留言） 2021年1月6日 (三) 06:39 (UTC)[回复]
公示3日，如無異議就转交phab:。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 07:53 (UTC)[回复]

转交phab:T271612。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月9日 (六) 08:16 (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)[回复]
- @Sunny00217：不急，等到佈署後再補充也不遲，現在code還沒review，我只是先貼上備忘。另外，感謝補充。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月23日 (六) 05:40 (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)[回复]
  - 完成編輯請求已由User:AnYiLin受理。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 04:06 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

您漏了WP:NS#缩写和别名。--LuciferianThomas．留言 2021年1月28日 (四) 08:08 (UTC)[回复]

完成。--臺灣杉在此發言 (會客室) 2021年1月29日 (五) 13:37 (UTC)[回复]

請協助複查是否全部的相關說明頁都修復完畢。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月25日 (四) 05:49 (UTC)[回复]

第二階段：轉移至新名字空間

已通過：

公示從2021年1月6日起至2021年1月14日暫停再從2021年1月26日起至1月29日共11天，期內所有異議的論述已由支持者回應，且反方無進一步論述，故無合理異議，議案通過。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 13:04 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

以下彙整：
- User:A2569875/議案/專題空間設立/影響頁面
  另請參考對應表（重新導向移動時若與對應表重複將不會進行移動）
- User:A2569875/議案/專題空間設立/影響重新導向
-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月4日 (一) 09:28 (UTC)[回复]

第二階段之公示狀態通告

公示即日起至命名空間佈署完畢為止。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 14:12 (UTC)[回复]
- 說明如公示通過，預計使用以下腳本：User:A2569875/議案/專題空間設立/轉移腳本.js，並申請WP:FLOOD-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 14:14 (UTC)[回复]
  - (～)補充：該Code的功能是，若一個頁面有低於100個連入頁面，則不保留重定向，連結問題將於下一階段用Flood修復（如高過100個會修不完。。。），其餘保留重新導向。移動重新導向時，全數皆會保留重新導向。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 06:56 (UTC)[回复]
擱置、暫停公示：稍微看了一下先前韓文維基的申請phab:T29651，其工程師處理的流程將近一個月，故認為應該還要一段時間才能完成布署，為了避免長時間占用公告欄，因此暫時先撤下公告Special:Diff/63712969，等到了Code Review階段時再繼續公示。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:18 (UTC)[回复]
- 程式碼已Commit到gerrit:657572（詳細資料），恢復公示，並延長3天，到2021年1月29日 (五) 12:56 (UTC)為止。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月26日 (二) 12:56 (UTC)[回复]
測試結果見此[1]，以PJ:多面體為例，目前未見系統性問題。預定將在公示結束時申請WP:FLOOD（或現在就去送審）並進行批量(►)移动。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 07:21 (UTC)[回复]

第二階段之公示期討論

看來需要移動了 @A2569875、羊羊32521、BlackShadowG、YFdyh000、GZWDer、Z7504、AnYiLin那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)[回复]

技术性~~(－)反对~~，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)[回复]
  还是有问题，Special:diff/63966864, 显示WikiProject talk非讨论页 ——羊羊 (留言|贡献) 2021年1月28日 (四) 04:16 (UTC)[回复]
  Done，已在Template:存檔至/core新增該討論空間。--臺灣杉在此發言 (會客室) 2021年1月28日 (四) 04:27 (UTC)[回复]
  感谢，已划票 ——羊羊 (留言|贡献|古典音乐专题) 2021年1月28日 (四) 04:30 (UTC)[回复]
  - 視為本反對意見已排除。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 07:22 (UTC)[回复]
    - 我已经划票了Topic:W2cr3gexeunjmjce ——羊羊 (留言|贡献|古典音乐专题) 2021年1月28日 (四) 10:18 (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)[回复]
好奇的问一下，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月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)[回复]
- 那麼提請全保護模板編輯請求不就解決了。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 10:15 (UTC)[回复]
  - 完成@BoyuZhang1998：編輯請求已由U:KirkLU處理，問題將在維基媒體系統緩存清除完畢後解決，請靜待維基媒體系統清除緩存。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月31日 (日) 11:38 (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)[回复]
- (＋)傾向支持以上提议，提升专题指引的曝光度和参与度，使其更经考验。直接名为“指引”，挂特制参数的“专题指引”模板为好。--YF dyh000（留言） 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)[回复]
第二階段：提議將WP:XX專題/YY指引以及PJ:XX專題/YY指引皆移動到WP:XXYY指引。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月18日 (四) 16:10 (UTC)[回复]

「維基專題:維基專題:XX」的頁面

已處理：

已由蟲蟲飛快速刪除-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月5日 (五) 06:55 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

@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)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

於Phabricator查看
編號T273763的工單
狀態：已解決

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

(～)補充，如移動完成的頁面有遇到任何技術問題，歡迎於此回報。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月8日 (一) 18:16 (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快捷方式？--Lightyears_{Talk#欢迎加入智能手机专题} 2021年1月30日 (六) 10:02 (UTC)[回复]
- @30000lightyears：請見最初流程規劃「5.討論重新導向與捷徑的設立方式」，這是第五階段的討論重點。我認為先把現有頁面調整好再討論這方面比較好，否則整個會亂掉。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月30日 (六) 10:22 (UTC)[回复]
  好，麻烦您在第五阶段开放时ping一下我，谢谢！--Lightyears_{Talk#欢迎加入智能手机专题} 2021年1月30日 (六) 10:24 (UTC)[回复]
是否需要修改所有的內部連結，可能需要與「是否需要刪除WP->PJ的重定向」一併討論。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:47 (UTC)[回复]

第四階段：調整專題模板

已完成：

已修改完大多數相關模板。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:33 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

部分專題模板需要調整才能正常，除了第三階段與連入頁面、分類相關的模板要調整外，其餘模板帶移動完成後再觀察情況，屆時將會補充需要辦理的事項。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 12:57 (UTC)[回复]
- (～)補充亦有部分關於專題模板整改的討論於PJT:ACG#遷移至WikiProject名字空間展開。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 12:58 (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：{{Main other}} （編輯討論說明信息鏈入歷史）也在今日稍早由大貓修復。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月12日 (五) 09:18 (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)[回复]
- 完成：已由U:AT完成修改。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:32 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

本案進入倒數第二個部分。現在將討論未來專題捷徑如何設立，以及原有捷徑的去留：

未來是否允許建立跨WP與PJ空間的捷徑？如果需要，是否需要進一步規範?
未來是否允許建立跨WP與PJ空間的非捷徑的重新導向？
舊有的跨WP與PJ空間的捷徑是否需要清除連入然後(×)删除？

cc.@30000lightyears、Taiwania Justo、LuciferianThomas、羊羊32521、BlackShadowG：

請討論-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:41 (UTC)[回复]

我认为PJ空间的捷径统一规范为WPJ/PJ:XXX，将现有WP重定向全部转到PJ去。比如WikiProject:智能手机的WP:SMARTPHONE直接转移到WPJ:SMARTPHONE。--Lightyears_{Talk·Sign#订阅维猫报喵！} 2021年2月14日 (日) 11:15 (UTC)[回复]
个人意见
1. 为了避免混淆，将来应该一律禁止建立跨WP与PJ空间的捷径重定向。
2. 目前存在的WP重定向到PJ的捷径应该全部转移到PJ，若无链入或很少链入，可考虑(×)删除；若数量过大，或者已经在讨论中被引用，则可考虑(○)保留以仅供历史参考。
3. 同时，将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径，不再推荐使用以WP开头的捷径。

——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月14日 (日) 12:57 (UTC)[回复]

同上，不然就沒必要偽命名空間了。空氣小貓（留言） 2021年2月14日 (日) 13:49 (UTC)[回复]

我覺得從PJ空間捷徑連出沒什麼問題，WP空間也有捷徑連至Help。PJ分拆了就不要再從WP連過去了，舊的就隨它吧。--LuciferianThomas．留言 2021年2月14日 (日) 14:09 (UTC)[回复]

舊的捷徑如要批量刪除的話可能要請求管理員開刪除機器人...-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 14:11 (UTC)[回复]

所以把PJ空间的{{shortcut}}全部更新，提醒将来的编者不要再用WP链接到PJ的捷径就行了。那些没有链入的WP捷径删了也无妨。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月16日 (二) 02:05 (UTC)[回复]

個人意見：

原則上不允許，但社羣就個別頁面的特殊情形可以例外特許。建議以修改R2規範處理。
不允許。如出現，應清除連入並刪除。
可行。清除連入可以請求bot（WP→PJ），刪除的話我覺得開一個list，然後轉AFD即可。

以上。SAN MO SA _SPQR 2021年2月17日 (三) 14:40 (UTC)[回复]

(？)疑問@Sanmosa：您認為需要清除連入嗎？-- 五歲抬頭雪菲（☎️·☘️） 2021年3月31日 (三) 06:53 (UTC)[回复]

既然（我認為）未來不允許建立跨WP與PJ空間的非捷徑重新導向，而且非條目命名空間的非捷徑重新導向本來就使用率低下，如果真的有人意外建立了，都不會有多少連入，清除連入也不是甚麽困難的事，而且還能避免未來的誤用。SAN MO SA _Σουέζ 2021年3月31日 (三) 07:43 (UTC)[回复]

Wikipedia:专题和Wikipedia:专题委员会等部分页面为何还没有移动到新的名字空间？还是这些页面不应该移动？--百無一用是書生 (☎) 2021年2月19日 (五) 02:46 (UTC)[回复]

先前討論有提到將專題介紹留在WP空間。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月19日 (五) 17:12 (UTC)[回复]

专题委员会并非专题介绍，Wikipedia:专题似乎也称不上是介绍，更像是WikiProject:首页的作用--百無一用是書生 (☎) 2021年3月1日 (一) 02:54 (UTC)[回复]

(？)疑問所以您建議將WP:专题(►)移动到PJ:首页嗎？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月1日 (一) 08:09 (UTC)[回复]
我认为应该这样，WP:专题可以不需要，或者另外重写，作为对专题的介绍页面--百無一用是書生 (☎) 2021年3月1日 (一) 11:46 (UTC)[回复]
(？)疑問那麼您對專題委員會的存放位置有何建議？—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:17 (UTC)[回复]
(？)疑問@Shizhao：？-- 五歲抬頭雪菲（☎️·☘️） 2021年3月10日 (三) 06:01 (UTC)[回复]
專題委員會应该是从属于专题的啊，我觉得按道理来说应该在WikiProject下面--百無一用是書生 (☎) 2021年3月10日 (三) 07:19 (UTC)[回复]

個人認為跨WP->PJ沒差，但PJ->WP的不行-- Sunny00217 2021年2月21日 (日) 13:56 (UTC)[回复]

第五階段：小結

總結以上討論意見：

禁止建立跨WP與PJ空間的捷徑重新導向。並清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向；同时，将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径，不再推荐使用以WP开头的捷径。→修改R2規範
Wikipedia:專題和Wikipedia:專題委員會移動到PJ空間。→需探討是否留重定向

以上-- 五歲抬頭雪菲（☎️·☘️） 2021年4月7日 (三) 06:22 (UTC)[回复]

公示7日-- 五歲抬頭雪菲（☎️·☘️） 2021年4月14日 (三) 03:35 (UTC)[回复]
R2具體修改內容呢？--Xiplus#Talk 2021年4月14日 (三) 05:31 (UTC)[回复]

補：R2修改內容：

現行條文

R2. 跨名字空间的重定向。

由条目的名字空间重定向至非條目名字空间，将用户页移出条目名字空间時遺留的重定向，或者从草稿名字空间指向非草稿名字空间的重定向。經社群同意設立的偽命名空間屬於本規則之例外。注意：有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遺留的重定向頁前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。

使用模板{{d|R2}}或{{d|interwk}}。

提議條文

R2. 跨名字空间的重定向。

包括以下幾種類型：

从条目名字空间指向非條目名字空间的重定向；
从用户页名字空间移動至条目名字空间時遺留的重定向；
从草稿名字空间指向非草稿名字空间的重定向；
從計畫命名空間（Wikipedia）指向維基專題命名空間（WikiProject）的重定向；及
從維基專題命名空間（WikiProject）指向計畫命名空間（Wikipedia）的重定向。

經社群同意設立的偽命名空間屬於本規則之例外。

注意：有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遺留的重定向頁前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。

使用模板{{d|R2}}或{{d|interwk}}。

以上。SAN MO SA _Σουέζ 2021年4月17日 (六) 04:12 (UTC)[回复]

Module:Template:Delete/data模組的對應修改見User:Sanmosa/R2模組。SAN MO SA _Σουέζ 2021年4月17日 (六) 04:24 (UTC)[回复]

現時有3502個WP->WPJ的重新導向，33個WPJ->WP的重新導向。--Xiplus#Talk 2021年4月17日 (六) 05:07 (UTC)[回复]

上面的結論有指明「清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向」，所以應該需要bot，再不然發通知邀請社群協力清理也可。SAN MO SA _Σουέζ 2021年4月17日 (六) 11:00 (UTC)[回复]

(！)意見：“2. 将用户页移出条目名字空间时遗留的重定向”真包含于“1. 由条目的名字空间指向非條目名字空间的重定向”，可以删去。另外那个的看起来怪怪的，建议删去。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月20日 (二) 04:57 (UTC)[回复]

@羊羊32521：（1）1是（條目命名空間）→（非條目命名空間），2是（非條目命名空間）→（條目命名空間），2不能刪。（2）完成。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:38 (UTC)[回复]

容許我再多等待三日，上面的提案會稍為調整。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:38 (UTC)[回复]

第六階段：(暫不開放)

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

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到部署完成。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

偽命名空間

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间（錯誤：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向頁面）。

[編輯此導航模板] 設立新命名空間及偽命名空間無共識：2018年12月的先前討論全案結以待續：第一輪討論 - 開放偽命名空間作捷徑連結用結以待續：設立LTA、MOS、PJ三個偽命名空間結以待續：升格維基專題為命名空間結以待續：修正命名空間資訊頁面結以待續：將「Wikipedia:捷徑」訂為方針完結：第二輪討論完成部署：設立專題命名空間相關討論及任務已通過：討論升格維基專題為命名空間任務完成：向Phabricator申請部署維基專題命名空間已合併：在Gerrit提交所需修正編碼任務完成：在Phabricator請求合併編碼完成：事實性修訂「Wikipedia:命名空間」以包含新的維基專題命名空間完成，待檢查：將專案命名空間下的維基專題移動至維基專題命名空間專題移動列表專題重定向移動列表已完成：修正指向專題的內部連結機器人任務已完成：調整專題模板已通過：討論捷徑的設立方式已通過：其他議題討論完結：設立偽命名空間相關討論已通過：討論設立LTA及MOS偽命名空間供捷徑使用已否決：設立捷徑空間供LTA/MOS捷徑使用已否決：設立捷徑空間作其他用途結以待續：升格LTA為命名空間完結：後續討論處理事項完成：修改機械人操作不提刪偽命名空間捷徑無結論：格式手冊新捷徑名稱討論 MOS捷徑列表已否決：舊捷徑改為軟重定向完成：設置預設啟用小工具已否決：自動半保護偽命名空間條目已通過：提議設立新快速刪除標準完結：第三輪討論已否決：捷徑命名空間已完成：捷徑指引草案修訂已通過：增設更多偽命名空間（一）已通過但未實行：第三次推动设立LTA命名空间

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

格式手冊及長期破壞者提升為命名空間，英語名稱待定；
格式手冊及長期破壞者成為偽命名空間，縮寫為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）。SAN MO SA _SPQR 2020年12月27日 (日) 07:32 (UTC)[回复]

支持提升為命名空間，因為會違反快速刪除方針的R2準則。空氣小貓（留言） 2020年12月28日 (一) 07:06 (UTC)[回复]

如果是偽命名空間通過，就會在下一階段修訂快速刪除、捷徑以及命名空間規範。--臺灣杉在此發言 (會客室) 2020年12月28日 (一) 09:53 (UTC)[回复]

支持成為偽命名空間。命名空间涉及较多技术问题，未来如需求明显，可再议转换。--YF dyh000（留言） 2020年12月30日 (三) 13:01 (UTC)[回复]

如需要立為名字空間也並非不可，只是要決定其所使用的數字ID

0-99的命名空間ID要保留給維基媒體系統使用，故需要使用100以上的命名空間ID
下面整理許多語言版本維基百科的命名空間ID使用(主空間是偶數，討論空間是奇數)

命名空間	命名空間ID / 討論頁ID	維基百科各語言版本使用狀況(未窮舉)	本地使用狀況	備註
主題:	100/101	全部語言版本維基百科皆有啟用（參考此處整理）	本地已使用	Help:主题
專題:	102/103	中文及加泰蘭文、世界文、法文、韓文、奧克西坦文、日文等	本地已使用	Wikipedia:专题
附件:	104/105	西班牙文等	未使用	類似中文維基辭典的附錄
列表:	104/105	僅立陶宛文維基	未使用	WP:列表
文獻:	104/105	法文、奧克西坦文等	未使用	參考User:青子守歌的整理
仲裁:	106/107	俄羅斯文等	未使用	(本地未通過相應指引) WP:仲裁委員會
圖書:	108/109	超過25個語言版本使用。	本地通過的共識為 : 繁簡轉換系統處理完畢後引入，然而P站仍在努力中，因此還是有機會使用此數值	Help:圖書
	110/111	未使用
草稿:	118/119	超過25個語言版本使用。	本地已使用	WP:草稿

以上補充。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月31日 (四) 09:52 (UTC)[回复]

如果要設立的話可能就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
以上補充。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月21日 (四) 10:19 (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:名字空间#開放偽命名空間作捷徑連結用})
大部分人皆認為可以設立偽名字空間，少數人認為可以成立真名字空間，亦有人認為礙於方針需升格為名字空間，然而部分人對是否升格為真名字空間有所保留。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月1日 (五) 19:38 (UTC)[回复]
- @Taiwania Justo：目前這樣的討論模式不易解讀共識，看是不是要根據LTA/MOS/真/偽逐條討論，或直接開投票？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月1日 (五) 19:41 (UTC)[回复]
  其實可以看出來大部分是偽命名空間為多數，還不至於動到投票的地步。--臺灣杉在此發言 (會客室) 2021年1月2日 (六) 02:35 (UTC)[回复]
(＋)支持設立LTA偽命名空間，(＋)傾向支持設立MOS偽命名空間，(－)反对設立任何命名空間。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年1月2日 (六) 04:45 (UTC)[回复]
- 如果主流意見都是偽名字空間，就得修方針指引了；萬一方針指引沒過，有配套嗎？—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月2日 (六) 05:04 (UTC)[回复]
  頂多就是維持現狀，直到通過為止。不過在修改時，R2增加的例外條款必須納入社群的共識在裡面，不至於不通過。--臺灣杉在此發言 (會客室) 2021年1月2日 (六) 07:32 (UTC)[回复]
  基本上在這裏支持設立偽命名空間的都理應明白偽命名空間就是R2例外的意思吧…？--LuciferianThomas．留言 2021年1月4日 (一) 01:54 (UTC)[回复]

我想補充一個意見：我反對MOS及LTA設為真命名空間，僅支持MOS及LTA設為偽命名空間。SAN MO SA _SPQR 2021年1月2日 (六) 08:17 (UTC)[回复]

支持命名空間，反對偽命名空間。SmallTim（留言） 2021年1月5日 (二) 13:56 (UTC)[回复]

(？)疑問@SmallTim：有鑑於WP:投票不能代替討論，能否請您補充一下反對偽命名空間的理由，以便彙整、推進討論？感激不盡。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月5日 (二) 18:25 (UTC)[回复]

这整得跟投票一样，建议各位将(＋)支持和(－)反对的理由写出来，逐一进行讨论，以此达到共识。毕竟投票不能代替讨论。 ——羊羊 (留言|贡献) 2021年1月5日 (二) 15:50 (UTC)[回复]

我建議直接排除成為真命名空間的可能性，這樣會產生維護問題。SAN MO SA _SPQR 2021年1月6日 (三) 06:10 (UTC)[回复]

(？)疑問@Sanmosa：比方說哪方面的維護問題？數字ID跟擴展重複？（這個可以克服，頂多新擴展本站的Namespace id與其他語言版本或己妹計畫不同步而已）；頁面內容維護？（我想不出甚麼樣的情況會不利於維護）；跨語言連結？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 06:44 (UTC)[回复]

方針指引宜集中於同一命名空間。SAN MO SA _SPQR 2021年1月6日 (三) 06:45 (UTC)[回复]

(！)意見LTA不是方針、指引、態度指引、草案、提議、論述、專題、主題、存檔、書籍、條目、分類、介面...都不是。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 06:48 (UTC)[回复]

那你當我的建議僅適用於MOS。SAN MO SA _SPQR 2021年1月6日 (三) 06:51 (UTC)[回复]

綜上所述，@Taiwania Justo：由於本質不同，建議LTA與MOS分項討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 07:11 (UTC)[回复]
這樣好了，MOS大多數意見都是偽命名空間，可以開啟第三階段修訂方針部分，然後LTA獨立出來繼續討論，如何？--臺灣杉在此發言 (會客室) 2021年1月6日 (三) 10:04 (UTC)[回复]

(？)疑問：有多少此次提案涉及的LTA？--Yining Chen（留言|签名） 2021年1月7日 (四) 05:39 (UTC)[回复]

所有LTA的子頁面如下：

所有指向LTA頁面的捷徑如下：（設立偽命名空間需要將以下捷徑移至LTA:XXX）

以上。--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)[回复]
不認為以上問題是問題，模板模組加個if-else或switch case在本地特化的名字空間便是模板/模組不就好了，況且現在有不少的名字空間判斷都不是直接引用魔術字，是使用中介模板例如{{Namespace_detect}}，在裡面補充if-else或switch case不就好了，先前討論早就提議了「建立允許不快速刪除的偽名字空間列表」，難道列表只能列在指引哩，不能寫在程式裡？？；關於介面是同理，將是偽名字空間的頁面改掉顯示名稱不就得了？技術上到底是有甚麼障礙，我看不出，有障礙的分明是「你不想」吧，例如下方列舉的程式碼片段：

在MediaWiki:Common.js加入程式碼片段不就能正常顯示了

(～)補充，你可以到諸如 [[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',
	}
)

以上。再來，快速刪除方針，請參閱WP:CCC。未見系統性問題，謝謝。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 07:14 (UTC)[回复]

在偽命名空間部分，我是以「有需求」為前提，如果共識認為不需設立或不能設立，那就是維持原案，也就沒有需要修方針的問題。--臺灣杉在此發言 (會客室) 2021年1月13日 (三) 02:58 (UTC)[回复]

而以現時討論而言主流意見為將MOS和LTA設為偽命名空間。--LuciferianThomas．留言 2021年1月13日 (三) 05:16 (UTC)[回复]

@LuciferianThomas：影響的範圍較大，即使有主流共識，目前討論的參與者人數並不能代表整個社群。空氣小貓（留言） 2021年1月17日 (日) 14:17 (UTC)[回复]

能有多大？，不就條目名字空間裡多幾個幾乎不會發生命名衝突的捷徑而已？怎麼講的好像設立下去維基伺服器會炸掉一樣。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月17日 (日) 14:43 (UTC)[回复]

關於主流意見的共識，我認為引用WP:7DAYS並無不妥，你不可能直接讓幾千人一起討論，你這樣說乾脆舉辦維基社群公投算了，BUT:WP:投票不能代替討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月17日 (日) 14:45 (UTC)[回复]

个人认为，如果长期破坏者（LTA）有成为名字空间的潜力的话，应该此时直接升级成为名字空间。不然，如果之后再讨论升级为名字空间，所有带LTA:前缀的页面还要重新移动一遍。 ——羊羊 (留言|贡献) 2021年1月15日 (五) 12:04 (UTC)[回复]

感觉LTA页面及名字空间有违WP:RBI。如果设立名字空间的同时增设页面查看权限（回退员及以上），我会考虑支持。--YF dyh000（留言） 2021年1月15日 (五) 12:28 (UTC)[回复]

但似乎普遍意見並不贊同LTA升格真命名空間，即使有潛力但卻缺乏社群共識，也難以行事。--LuciferianThomas．留言 2021年1月15日 (五) 17:40 (UTC)[回复]

(－)反对设立MOS和LTA名字空间，这与技术问题无关，而是目前MOS和LTA页面的数量和读者关注的程度远远达不到需要设立新名字空间的地步。LTA页面的数量充其量也就一百个左右，MOS页面的数量更是少得可怜，才十几个，远远没有达到维基专题那样的2000多个页面。同时，LTA只有熟悉CU等站务的编者会去查阅，MOS查阅的人数更少，这些也完全比不上熟悉某些特定领域的编者和读者都会关注的维基专题。因此，我反对设立以上两个名字空间，对设立伪名字空间表示(＝)中立。——BlackShadowG（留言）维基百科20周年庆即将到来 2021年1月15日 (五) 13:41 (UTC)[回复]

LTA数量可能少，但shortcut还是蛮多的。而且LTA数量也会增多-- ——羊羊 (留言|贡献) 2021年1月16日 (六) 12:55 (UTC)[回复]

偽命名空間只是for捷徑連結而已，原本的頁面不會被移動。--LuciferianThomas．留言 2021年1月16日 (六) 13:12 (UTC)[回复]

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

捷徑空间提案

标题添加： ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)[回复]

否決：

設立捷徑專用名字空間無法有效解決本案核心問題。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月20日 (三) 07:14 (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)[回复]
    可是缺點是，以後如果有其他捷徑字首的需求，都要去phab申請，可擴充性不佳。偽名字空間的優點就是擴充性佳、容易設立。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 05:38 (UTC)[回复]
    呃等等，如此LTA:123==MOS:123？若未來出現了一個「兩岸四地用語破壞者」，而現時的WP:CS4D佔用MOS:CS4D==L:CS4D，那麼就只能迴避LTA:CS4D==L:CS4D？--LuciferianThomas．留言 2021年1月19日 (二) 07:19 (UTC)[回复]
    阿，沒有想到這個問題。這太困難了，突然覺得設立「偽名字空間」才是最省事的方案。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 07:24 (UTC)[回复]
  還有一個盲點，要說跨空間，老實那句，這命名空間的重定向也是跨命名空間，還是要修訂R2。--LuciferianThomas．留言 2021年1月19日 (二) 07:34 (UTC)[回复]
  @A2569875：撤回議案…？--LuciferianThomas．留言 2021年1月20日 (三) 00:20 (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)[回复]

再提捷徑空间提案

本主題全部或部分段落文字，已轉移至Wikipedia:互助客栈/技术#捷徑空间提案2。执行人：Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～}。標記人：_{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月25日 (一) 06:32 (UTC)。[回复]

尝试推动LTA空间

結以待續，請發起新議案。--LuciferianThomas．留言 2021年1月31日 (日) 23:09 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

经过上方的讨论，我认为LTA更适宜作为真·名字空间。好处是（上方有人提到）可以设置所有页面为NOINDEX，增设页面查看权限（体现WP:RBI，而且有天邪鬼这种……）。

此外，LTA与Project空间联系性不大，没有维护问题。而且，如果设伪名字空间之后再讨论升级为名字空间，所有带LTA:前缀的页面还要重新移动一遍。(mw:Help:Namespace)

至于LTA页面数量少……我是不知道设立名字空间还有页面数量门槛啊…… 囧rz…… ——羊羊 (留言|贡献) 2021年1月23日 (六) 05:20 (UTC)[回复]

如果用户不可查看的名字空间不会显示在Special:搜索，我想名字空间多不是个大问题。赞成“LTA与Project空间联系性不大”。不认为二次移动是个大问题，社群可以先用伪名字空间看看效果。--YF dyh000（留言） 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)[回复]
本議案可能須分階段討論，要討論的項目有：
1. 是否需要默認關閉LTA頁面的Special:搜索？（mw:Manual:$wgNamespacesToBeSearchedDefault設定）
2. 是否需防止LTA頁面被機器人或網路爬蟲索引？（mw:Manual:$wgNamespaceRobotPolicies設定）
3. 是否需設定LTA頁面的檢視權限？（例如，只有自動確認用戶、巡查員、回退員、管理員能檢視/訪問這些頁面，需引入mw:Extension:Lockdown）
等。如具備以上需求，才有必要定為名字空間。以上，請討論-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 04:57 (UTC)[回复]
- 根据之前的一些Task維基媒体不会启用mw:Extension:Lockdown。但是如果只是为了避免WP:BEANS而没有保密需求那么用CSS屏蔽掉内容显示即可。--GZWDer（留言） 2021年1月27日 (三) 11:58 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

@羊羊32521：討論不知道為什麼被關掉了，(？)疑問你有要繼續推動的意願嗎？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月1日 (一) 09:36 (UTC)[回复]
YFdyh000说让社群看看伪名字空间的效果……我觉得可以先这样？过一段时间再提吧-- ——羊羊 (留言|贡献|古典音乐专题) 2021年2月1日 (一) 09:43 (UTC)[回复]

關掉是希望這個分開重新討論，不要卡在議案的中間，有點尷尬，歡迎開新討論。--LuciferianThomas．留言 2021年2月1日 (一) 12:28 (UTC)[回复]

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

通過：

公示七日結束，共識期間唯一異議排除，公示獲得通過，有關條文。即日起MOS、LTA偽命名空間獲得CSD R2例外，上述命名空間作為格式手冊和長期破壞者頁面的正規連結。--LuciferianThomas．留言 2021年1月31日 (日) 03:11 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

本討論已近一個月，得到的回饋有：

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

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

現行條文

R2. 跨名字空间的重定向。

由条目的名字空间重定向至非條目名字空间，将用户页移出条目名字空间時遺留的重定向，或者从草稿名字空间指向非草稿名字空间的重定向。（有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遺留的重定向頁前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。）

提議條文

R2. 跨名字空间的重定向。

由条目的名字空间重定向至非條目名字空间，将用户页移出条目名字空间時遺留的重定向，或者从草稿名字空间指向非草稿名字空间的重定向。經社群同意設立的偽命名空間屬於本規則之例外。注意：有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遺留的重定向頁前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。

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

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

同意提案。SAN MO SA _SPQR 2021年1月20日 (三) 08:10 (UTC)[回复]

(＋)贊成R2修正案，另就WP:捷徑，我看了一遍，似乎要整個重新整理過。--LuciferianThomas．留言 2021年1月20日 (三) 10:04 (UTC)[回复]

捷徑修正細節是最後一項討論內容，目前先以偽命名空間為討論對象。也歡迎對捷徑規範作重新整理。--臺灣杉在此發言 (會客室) 2021年1月20日 (三) 12:19 (UTC)[回复]

(＋)支持WP:CSD修正案與偽名字空間。我原本是支持名字空間的，但經歷了上述討論以及主持了專題名字空間的設立，我發現偽名字空間是有許多優點的。先看名字空間，名字空間是需要「安裝」的，本地獲得共識之後要等待工程師安裝，期間從數周到數月不等，且不具備可擴充性，即每新增一個名字空間都要請工程師協助，本地管理員、介面管理員、模組編輯員都無能為力，只有基金會工程師可以執行，「真名字空間」可擴充性不佳。我們來看看「偽名字空間」，它「免安裝」耶，隨加即用，涉及命名空間判斷的本地模板與模組本地的管理員、介面管理員、模組編輯員都能即時加入，也不必等待工程師安裝，「偽名字空間」可擴充性十分良好。假如今天社群需要一個新的捷徑前綴或字首，真名字空間需要等待工程師安裝，而偽名字空間公示通過後就能隨加即用，是多麼的方便，然而要實現此需要修正WP:CSD#R2，正如臺灣杉在此發言 (會客室)所言：「如果偽命名空間不會造成「系統性」的重大問題，就可以納入考量。」，參見#宇帆於2021年1月19日 (二) 07:16 (UTC)之發言，未見要修正WP:CSD#R2會出現什麼系統性問題，故此(＋)支持WP:CSD修正案。以上-- _{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月21日 (四) 08:06 (UTC)[回复]

想向諸位確認一下@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：兩者應當一同公示並通過，否則會有合法性問題。SAN MO SA _SPQR 2021年1月23日 (六) 08:55 (UTC)[回复]

借問：現在討論似乎已經算超過一個月了（這提案承接上次討論，已經很久了），而已經達到基本社群共識（共識不強求全然同意，但可採取主流意見），理論上可以7DAYS？--LuciferianThomas．留言 2021年1月23日 (六) 09:25 (UTC)[回复]

那就現在公示吧。--臺灣杉在此發言 (會客室) 2021年1月24日 (日) 02:47 (UTC)[回复]

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

@Taiwania 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)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

進一步討論

自動提刪R2

完成 by Jimmy Xu--LuciferianThomas．留言 2021年2月1日 (一) 23:04 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

現時主命名空間的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)[回复]

軟重定向

已否決：

--LuciferianThomas．留言 2021年1月31日 (日) 04:58 (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)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

技術問題處理

已通過：

已完成設定並佈署。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:50 (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)[回复]

(：)回應由於U:YFdyh000提到的誤導問題，故反對使用個人用戶小工具模式，因為誤導問題就是在於不知此事的人，知道的人啟用小工具又有什麼卵用？故強烈建議全站套用。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月2日 (二) 10:50 (UTC)[回复]

@A2569875：可以考虑作为默认启用的小工具，这样也方便维护。--安忆 ^Talk 2021年2月2日 (二) 12:35 (UTC)[回复]

@Pseudo Classes：閣下錯引方針了，該章節位於「使用和處理編輯請求」章節底下，指明是管理員和模板編輯員在處理編輯請求的情況下才需要經過討論及七日公示。該模板僅為半保護防止破壞，而非模板保護。--LuciferianThomas．留言 2021年2月2日 (二) 11:47 (UTC)[回复]

@LuciferianThomas：首句「在受保護的頁面上編輯時，應當特別小心，並於共識和任何相關的指導方針相一致」，只要是受保護的頁面均受此限制。--空氣小貓（留言） 2021年2月2日 (二) 11:54 (UTC)[回复]

該章節也提到：「一些會輕微影響使用方式和外觀顯示的編輯，需在提交編輯請求後等待七天，無爭議方可進行修改」，您沒有提出編輯請求即自行變更，可視為繞過程序。--空氣小貓（留言） 2021年2月2日 (二) 11:58 (UTC)[回复]

自動確認用戶編輯非編輯爭議的半保護頁面也要提出編輯請求是什麼說法？那麼怎麼不直接模板保護？--LuciferianThomas．留言 2021年2月2日 (二) 12:01 (UTC)[回复]

@LuciferianThomas：依照您這個說法，難道模板編輯員和管理員對模板重大更新，都不用提交編輯請求？此外，半保護並不是只有防止破壞，其亦屬於高風險模板。--空氣小貓（留言） 2021年2月2日 (二) 12:17 (UTC)[回复]

已處理，見本人討論頁。--LuciferianThomas．留言 2021年2月2日 (二) 12:45 (UTC)[回复]

當初本議案一堆人以「介面會顯示[條目]」為由異議，後來是提出了「修改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)[回复]

(：)回應@AnYiLin：User:A2569875/pseudonamespace_UI.js已修改。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月2日 (二) 19:48 (UTC)[回复]

感觉用'ontouchstart' in document.documentElement来判断更合适。--安忆 ^Talk 2021年2月3日 (三) 08:59 (UTC)[回复]

完成Special:Diff/64090030，已加入代碼。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月3日 (三) 09:33 (UTC)[回复]

(＋)支持預設啟用小工具，在使用上與修改介面理應無異；亦方便維護，當通過新偽命名空間時可快速增添設定。--LuciferianThomas．留言 2021年2月3日 (三) 08:47 (UTC)[回复]

(～)補充：亦支持直接修改介面，這真的視乎最終選擇。--LuciferianThomas．留言 2021年2月3日 (三) 08:53 (UTC)[回复]

@LuciferianThomas：修改介面？那不就又回到獨立成新的命名空間了嗎？（技術問題還少些）-- Sunny00217 2021年2月4日 (四) 08:47 (UTC)[回复]

…你是真的沒有跟上整個討論對吧…所謂「修改界面」是修改顯示界面，僅表示顯示界面時捷徑頁不是直接顯示頁面為「條目」而已，實際上不影響任何其他方面。--LuciferianThomas．留言 2021年2月4日 (四) 08:52 (UTC)[回复]

小工具執行結果
以頁面[[MOS:MOS]]為例

設定為繁體中文(以zh-tw為例)	設定為簡體中文(以zh-cn為例)

提供目前版本小工具運行結果圖，供公示參考用。右上角的連結為Wikipedia:偽名字空間用於說明，如有缺漏歡迎改善。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月3日 (三) 19:03 (UTC)[回复]

@A2569875：等等等一下，這版在像是Mos:$1沒有大寫的也會執行耶，，，-- Sunny00217 2021年2月4日 (四) 08:45 (UTC)[回复]

(：)回應@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)[回复]
  我反對隱藏，我個人不需要這個功能，想將其關閉。使用者誤關閉不會造成嚴重問題，如果有人問起相關問題，叫他重新打開就好了，看不出隱藏的必要性。--Xiplus#Talk 2021年2月15日 (一) 04:34 (UTC)[回复]
  但是如果这段代码直接按最初设想放进common.js的话，也是关不掉的吧。--安忆 ^Talk 2021年2月15日 (一) 04:44 (UTC)[回复]
  做成小工具就是因为有关闭的需求，其次是维护的需求。--YF dyh000（留言） 2021年2月15日 (一) 04:46 (UTC)[回复]
  做成小工具本来就是我提出来的，从未考虑过提供其他需求（比如自由选择开关），只是为了方便维护，不用去改common.js，放进common.js根本没得选。--安忆 ^Talk 2021年2月15日 (一) 04:51 (UTC)[回复]

公示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)[回复]

於Phabricator查看
編號T178356的工單

@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)[回复]

meta:User_talk:Jon_(WMF)#Gadget-pseudonamespace-UI@zhwiki，問題似乎已解決？—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月25日 (四) 05:46 (UTC)[回复]

完成：已通過並佈署。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:50 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

自動半保護偽命名空間

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

不應做出預見性保護。--Xiplus#Talk 2021年2月2日 (二) 10:26 (UTC)[回复]

若捷徑指向的條目因為破壞被保護，有需要跟隨進行保護嗎？--LuciferianThomas．留言 2021年2月2日 (二) 12:06 (UTC)[回复]

不需要吧，有這樣的案例嗎？--Xiplus#Talk 2021年2月2日 (二) 12:30 (UTC)[回复]

案例我不清楚，但我倒是覺得需要，尤其本來有某些LTA有破壞自己LTA頁的傾向，可算是高風險。--LuciferianThomas．留言 2021年2月2日 (二) 12:59 (UTC)[回复]

有破壞事實就能保護，不需預先保護。--Xiplus#Talk 2021年2月2日 (二) 13:04 (UTC)[回复]

建议用滥用过滤器阻止非自动确认用户编辑，配以相关警告。--YF dyh000（留言） 2021年2月2日 (二) 13:07 (UTC)[回复]

(＋)支持用滥用过滤器阻止非自动确认用户编辑，配以相关警告。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月7日 (日) 04:08 (UTC)[回复]

提議設立快速刪除標準 O8

通過。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:28 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

現行條文

(無)

提議條文

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

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

使用模板{{d|O8}}。

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

(＋)支持，若有條目真的需要以偽命名空間佔用條目前綴，使用全形冒號而非半形冒號以辨別即可，此可避免之前有用戶擔憂會佔用主空間條目名的情況。另外，我本來是在想可以把這條同時套用於不當使用偽命名空間重定向至其他頁面，但想起有個別屬於格式手冊的論述其實不在Wikipedia:格式手冊/前綴（WP:SAL），所以暫時作罷。--LuciferianThomas．留言 2021年2月1日 (一) 11:12 (UTC)[回复]

@LuciferianThomas：使用全形冒號，極有可能違反命名常規。--空氣小貓（留言） 2021年2月2日 (二) 05:46 (UTC)[回复]

未見命名常規有不能用全形冒號的規則。若以與事物本身名稱不同說違反常規，可按照其他命名技術限制做法，不加冒號或改用全形冒號，並以{{Wrongtitle}}標記即可。--LuciferianThomas．留言 2021年2月2日 (二) 05:52 (UTC)[回复]

@LuciferianThomas：名從主人，這就是有使用者擔憂會佔用主空間條目名的情況，也有像en:Gadget:Invention, Travel, & Adventure類似的情況。--空氣小貓（留言） 2021年2月2日 (二) 06:04 (UTC)[回复]

可直接按照該情況處理，若通過則當作技術限制即可。用{{DISPLAYTITLE}}修正亦可。--LuciferianThomas．留言 2021年2月2日 (二) 06:21 (UTC)[回复]

這理論上可以出現在任何命名空間的情況，故按照命名空間一般處理方式即可。--LuciferianThomas．留言 2021年2月2日 (二) 06:24 (UTC)[回复]

很抱歉，{{DISPLAYTITLE}}需使用全名，少一個冒號就不會變更顯示。--空氣小貓（留言） 2021年2月2日 (二) 06:33 (UTC)[回复]

(＋)支持。--忒有钱 🌊塩水あります🐳（留言） 2021年2月1日 (一) 15:20 (UTC)[回复]

為何不是移動到合適的名稱？例如在LTA:誤建LTA頁面應該移動到WP空間後，讓原先頁面成為重新導向之類的。--Xiplus#Talk 2021年2月2日 (二) 05:53 (UTC)[回复]

若果明顯屬於錯誤建立有關專題頁面的當然可以移動，這裡應該是指創建與該專題無關的頁面。--LuciferianThomas．留言 2021年2月2日 (二) 06:01 (UTC)[回复]

那就要寫清楚，避免被提快速刪除後，管理員未注意直接刪除。--空氣小貓（留言） 2021年2月2日 (二) 06:07 (UTC)[回复]

(！)意見：偽命名空間的設立理應是用作指向比較複雜的Wikipedia命名空間項目，不應用以指向其他無關條目，或許可以增加刪除「非指向維基百科命名空間的重定向」條款？理論上偽命名空間屬於WP空間的延伸，不應該出現指向WP以外的偽命名空間，其他命名空間有自己的命名空間別稱，不會使用偽命名空間捷徑。未來倘若通過將部分項目升格命名空間，但該項目本身有偽命名空間捷徑，該等捷徑理應全數自動納入新命名空間而不會保留於主命名空間，不會影響此規則。--LuciferianThomas．留言 2021年2月2日 (二) 06:12 (UTC)[回复]

呃忘了有幾條MOS在PJ空間。--LuciferianThomas．留言 2021年2月3日 (三) 08:48 (UTC)[回复]

還有這種事？！-- Sunny00217 2021年2月3日 (三) 09:18 (UTC)[回复]

有啊，專題的條目指引有幾條跟隨專題搬過去了。列表有寫。也有疑似專題移了但分頁未移的餘孽，但遲早都要搬過去吧。--LuciferianThomas．留言 2021年2月3日 (三) 11:10 (UTC)[回复]

§ 第二階段：轉移至新名字空間在讨论这类MOS的更名，很快就能解决。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月4日 (四) 11:18 (UTC)[回复]

加了附加條件之後讓我覺得這個準則永遠不會被使用，無論是什麼內容都應該根據內容來移動到新名稱，若是破壞也可用現存的G3等刪除。--Xiplus#Talk 2021年2月3日 (三) 13:59 (UTC)[回复]

至少這也能成為移動操作的依據。快速刪除方針的應用有時並不限於快速刪除本身。SAN MO SA _SPQR 2021年2月17日 (三) 15:06 (UTC)[回复]

「快速刪除方針的應用有時並不限於快速刪除本身」如無異議將在適當的時間進行公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月7日 (三) 06:24 (UTC)[回复]
公示7日-- 五歲抬頭雪菲（☎️·☘️） 2021年4月14日 (三) 03:34 (UTC)[回复]

Module:Template:Delete/data模組的對應修改見User:Sanmosa/O8模組。SAN MO SA _Σουέζ 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)[回复]

需要是獨立的名字空間才能設定noindex—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月18日 (四) 10:12 (UTC)[回复]

@羊羊32521：我認為如果可以設定的話會更佳，但可能命名空間化會比較方便。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:20 (UTC)[回复]

那我周末再提一下 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月3日 (三) 15:00 (UTC)[回复]

(？)疑問：改这个是否可行？--安忆 ^Talk 2021年3月3日 (三) 15:13 (UTC)[回复]

仍支持命名空間案，我只是覺得提升命名空間案一直被人以奇怪的理由關掉很可惜。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 15:21 (UTC)[回复]

那就搬新段重開吧，抱歉太亂了。--LuciferianThomas．留言 2021年3月6日 (六) 06:51 (UTC)[回复]

也沒有亂吧，個段落應該分開檢視吧，怎麼會不能放在兩個結束之議案的中間呢？-- 五歲抬頭雪菲（☎️·☘️） 2021年3月10日 (三) 06:00 (UTC)[回复]

从语法看可以。--YF dyh000（留言） 2021年3月3日 (三) 15:22 (UTC)[回复]

以往phab有修改此部分的先例嗎?-- 五歲抬頭雪菲（☎️·☘️） 2021年3月17日 (三) 06:42 (UTC)[回复]

如果沒有的話，我認為很難實行。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月31日 (三) 06:51 (UTC)[回复]

實測上Google應沒有對重新導向進行索引（例如搜尋"LTA:蘇俞安"找不到該重新導向或是目標頁面），所以我們應沒必要再對其標記NOINDEX。--Xiplus#Talk 2021年3月31日 (三) 08:55 (UTC)[回复]

Google搜尋重新導向時會顯示目標頁的內容，即會有一行「（重新導向自）」，請見[4]，但是不影響偽命名空間。--空氣小貓（留言） 2021年4月5日 (一) 07:29 (UTC)[回复]

google:detache出现了一个到https://en.wikipedia.org/?title=Detach%C3%A9&redirect=no的搜索结果。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月11日 (日) 14:31 (UTC)[回复]

這個不像是主動收錄的網址，而且有設定canonical，理應不會收錄這個重定向。--Xiplus#Talk 2021年4月14日 (三) 05:32 (UTC)[回复]

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到部署完成。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

WP:捷徑指引草案修訂

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:捷徑、Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间（錯誤：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向頁面）。

[編輯此導航模板] 設立新命名空間及偽命名空間無共識：2018年12月的先前討論全案結以待續：第一輪討論 - 開放偽命名空間作捷徑連結用結以待續：設立LTA、MOS、PJ三個偽命名空間結以待續：升格維基專題為命名空間結以待續：修正命名空間資訊頁面結以待續：將「Wikipedia:捷徑」訂為方針完結：第二輪討論完成部署：設立專題命名空間相關討論及任務已通過：討論升格維基專題為命名空間任務完成：向Phabricator申請部署維基專題命名空間已合併：在Gerrit提交所需修正編碼任務完成：在Phabricator請求合併編碼完成：事實性修訂「Wikipedia:命名空間」以包含新的維基專題命名空間完成，待檢查：將專案命名空間下的維基專題移動至維基專題命名空間專題移動列表專題重定向移動列表已完成：修正指向專題的內部連結機器人任務已完成：調整專題模板已通過：討論捷徑的設立方式已通過：其他議題討論完結：設立偽命名空間相關討論已通過：討論設立LTA及MOS偽命名空間供捷徑使用已否決：設立捷徑空間供LTA/MOS捷徑使用已否決：設立捷徑空間作其他用途結以待續：升格LTA為命名空間完結：後續討論處理事項完成：修改機械人操作不提刪偽命名空間捷徑無結論：格式手冊新捷徑名稱討論 MOS捷徑列表已否決：舊捷徑改為軟重定向完成：設置預設啟用小工具已否決：自動半保護偽命名空間條目已通過：提議設立新快速刪除標準完結：第三輪討論已否決：捷徑命名空間已完成：捷徑指引草案修訂已通過：增設更多偽命名空間（一）已通過但未實行：第三次推动设立LTA命名空间

說明

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

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

本討論的各階段分為：

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

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

專題命名空間通過，剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (UTC)[回复]

偽命名空間和專題空間都設立了。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:21 (UTC)[回复]

說明剩下的第四點，有部分項目正在等待專題、格式手冊、LTA等命名空間的相關議題之討論或公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月21日 (三) 02:51 (UTC)[回复]

專題命名空間問題

本主題全部或部分段落文字，已轉移至Wikipedia:互助客栈/方针#專題命名空間。执行人：臺灣杉在此發言 (會客室)。標記人：_{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:44 (UTC)。[回复]

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

本主題全部或部分段落文字，已轉移至Wikipedia:互助客栈/方针#偽命名空間。执行人：臺灣杉在此發言 (會客室)。標記人：_{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月24日 (三) 05:54 (UTC)。[回复]

已通過：

已通過，並完成主要設定。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:55 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

完成技術的部分已完成大部分的設定，剩下制度完善的部分。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月25日 (四) 05:48 (UTC)[回复]
- 如有技術問題，請回報至討論對應章節。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月10日 (三) 05:58 (UTC)[回复]

完成：設定完畢，有問題請在此提出。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:55 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

捷徑細部修訂

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

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

我對捷徑不是很熟，但#快捷方式的命名真的是中維社群慣例嗎（ ——羊羊 (留言|贡献|古典音乐专题) 2021年2月5日 (五) 12:08 (UTC)[回复]
- ……我好像一不小心把“不鼓勵不按”看成了“不鼓勵按” 囧rz…… 眼瞎不好意思，當我沒說 ——羊羊 (留言|贡献|古典音乐专题) 2021年2月5日 (五) 12:13 (UTC)[回复]
  慣例還有簡單中文簡稱以及其他，所以才要修正相關內容，歡迎提出修改方案。--臺灣杉在此發言 (會客室) 2021年2月11日 (四) 07:41 (UTC)[回复]
  目前還有多少未完善之處？—- 五歲抬頭雪菲（☎️·☘️） 2021年4月7日 (三) 06:14 (UTC)[回复]

首段建議附加維基專題空間，他們會稍後設立捷徑。--LuciferianThomas．留言 2021年2月6日 (六) 04:03 (UTC)[回复]

(：)回應Wikipedia:互助客栈/方针#第五階段：討論重新導向與捷徑的設立方式討論已開始。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:51 (UTC)[回复]

@Taiwania Justo？--LuciferianThomas．留言 2021年2月21日 (日) 00:13 (UTC)[回复]

目前在忙著RFC以及其他現實生活事務，且目前還有殘餘議案等待處理，待完全告一段落後再行整理該案。--臺灣杉在此發言 (會客室) 2021年2月21日 (日) 03:46 (UTC)[回复]

不急，因為#第五階段：討論重新導向與捷徑的設立方式也還在討論。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月17日 (三) 06:43 (UTC)[回复]

上述第五階段將會在適當的時機公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月31日 (三) 06:50 (UTC)[回复]

上述第五階段已開始公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月14日 (三) 03:45 (UTC)[回复]

有關某年代相關分類命名統一事宜

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:分类名称。

最近Jarodalien對某年代相關分類進行了大規模的重新命名工作（將“XXXX年代”重新命名為“YY世紀YY年代”、將“建立”重新命名為“創立”），並聲稱其理由為“先到先得”，然而“先到先得”並不適用於非條目頁面。我曾就部分分類的擬議重新命名（移動請求）進行反對，然而被其無視，其不但無視反對意見照樣進行移動操作，更反過來誣指我取消重新命名的操作為“破壞”，更牽連到其他本與相關移動請求不相關的分類。在其進行大規模的重新命名工作後，我收到部分用戶反映其重新命名工作導致部分由模板自動產生的分類出錯，可見其大規模的重新命名工作輕率且窒礙模板維護，構成破壞。請管理員盡快回退其移動操作，並以一切可行的辦法阻止其繼續進行相關破壞性移動。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 10:54 (UTC)[回复]

@AT。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 10:54 (UTC)[回复]

@Iokseng。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 10:56 (UTC)[回复]

我建議通報至管理員佈告版。--A T 2021年2月25日 (四) 10:58 (UTC)[回复]

@AT：WP:AIV提報過了，但當時我未收到部分用戶對於其重新命名工作導致部分由模板自動產生的分類出錯的反映。我覺得至少也得把他做的移動操作全數回退，這比較急。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 11:00 (UTC)[回复]

@Jarodalien：請參與討論，不然我會考慮禁制您編輯分類空間。謝謝。--A T 2021年2月25日 (四) 11:15 (UTC)[回复]

正在回退一部分他移動過的分類，但數量有點多，我移不完。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 12:16 (UTC)[回复]

？什么意思？是说只允许别的用户把本来是叫“XX世纪XX年代”的分类移动成“XXXX年代”，不允许反过来吗？就像Category:1910年代美国罪案本来是20世纪10年代美国罪案等等。既然先到先得不适用分类，那么为什么不能够移动？为什么“埃及定居地‎”不对只能移动到“埃及聚居地”，“非洲各国定居点‎”不行要移动到繁体的“非洲各國聚居地‎”？--7（留言） 2021年2月25日 (四) 12:48 (UTC)[回复]

你還記得你上次不允許將「获奖名单」、「获奖列表」等分類移動到「获奖与提名列表」嗎？你都會說沒事不要移動了，現在突然搞這些是有事嗎？ --無心*插柳*柳橙汁 2021年2月25日 (四) 13:01 (UTC)[回复]

注意翻历史纪录，不只是我的纪录。我一向的主张是先到先得，是楼主说分类不先到先得。以此为由把Category:20世纪10年代美国罪案移动到Category:1910年代美国罪案。我也想确认是不是真的“分类不先到先得”，我个人是觉得很不可思议，因为这就意味着什么谁都明白。--7（留言） 2021年2月25日 (四) 13:13 (UTC)[回复]

命名常規只規範條目、不規範分類，自然不適用「先到先得」，不要把你自己當成方針。分類的命名看的是更宏觀的其他東西。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 15:42 (UTC)[回复]

不允许反过来吗。前后极其相似或许先到先得（因为没必要改、WP:OWN），改变命名方式已经不只是先到先得的范畴了。--YF dyh000（留言） 2021年2月25日 (四) 16:04 (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)[回复]

我不同意「這個人一定不懂漢語」的論斷，一時看得較快看錯了所導致的誤認是非常正常的事情。就此例而言，這是前述情況最為經典的例子。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 15:42 (UTC)[回复]

这是认知不广泛的“常识”（就像公元1年到公元前1年之间有几年，不一定有过半数人答对），有更清楚且简洁表达的情况下不应该改成更模糊、更容易出错的。--YF dyh000（留言） 2021年2月25日 (四) 16:00 (UTC)[回复]

@YFdyh000：所以說答案是空集，還是元素為“0年”的單元素集合？⋯⋯--洛普利宁 2021年2月26日 (五) 15:46 (UTC)[回复]

这不重要吧……我指看似常识的东西很多人并不清楚，如有没有公元0年，世纪怎么算，年代又怎么算。相比可能模糊但容易猜对的xxxx年代，双重模糊的xx世纪xx年代更难判断。--YF dyh000（留言） 2021年2月26日 (五) 16:01 (UTC)[回复]

@Jarodalien：無論如何，你進行的重新命名工作導致部分由模板自動產生的分類出錯這一點是無庸置疑的，我認為你應該將先前所建立和重新命名的分類（包括但不限於某年代相關分類，我認為其他相關分類很可能也有同樣情形）全部統一回模板自動產生的格式，否則這無庸置疑會嚴重影響模板維護工作。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 15:42 (UTC)[回复]

為免後患，我建議就各類頁面（包括但不限於分類頁）引入「命名一致性」的規定，以有效減少頁面命名上的紛爭，並便利維護。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 15:56 (UTC)[回复]

支持這個提議，而且可以把「年代分類」當作首要討論對象，未來可以擴及其他分類原則。我支持“1950年代”這個寫法，理由如下：

此次討論顯示“19世纪50年代”這個用法確實容易導致誤判。
“1950年代”寫法較為簡潔。
分類與主條目名稱統一對讀者來說最為便利，按照年代列表目前所有年代主條目都是採取“1950年代”這個寫法。
User:Sanmosa在上方已提及的分類維護問題。--迴廊彼端（留言） 2021年3月6日 (六) 03:10 (UTC)[回复]

“19世纪50年代”不是相等於“1950年代”嗎。--Temp3600（留言） 2021年2月26日 (五) 13:29 (UTC)[回复]

認真？“19世纪50年代”相等於“1850年代”，“20世纪50年代”才相等於“1950年代”。-游蛇脫殼/克勞棣 2021年2月26日 (五) 14:16 (UTC)[回复]

@Temp3600：想一下2000年是几世纪，称多少年代。以及Category:2000年代怎么整。--YF dyh000（留言） 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世纪了

捂脸--YF dyh000（留言） 2021年2月26日 (五) 15:24 (UTC)[回复]

读作零零年代、一零年代，就像九零后、零零后。--YF dyh000（留言） 2021年2月26日 (五) 16:01 (UTC)[回复]

①“20世纪50年代”=“1950年代”=“1950年到1959年”，這應該比較沒有爭議；②但如您所舉例，遇到100的倍數就麻煩了；③「20世纪50年代」、「21世紀00年代」、「21世紀10年代」我會分別讀「二十世紀五零年代」、「二十一世紀零零年代」、「二十一世紀一零年代」，至於別人怎麼讀，我就不知道了。-游蛇脫殼/克勞棣 2021年2月26日 (五) 16:15 (UTC)[回复]

00和10以外的年代，我大概会读作“__十年代”，读法上没问题。--YF dyh000（留言） 2021年2月26日 (五) 21:01 (UTC)[回复]

@@YFdyh000：說到年代的是，請教大家一個問題，最近我都不太用維基百科了，今天我在找資料時發現有條目裡面原有年代的部分被刪除了，查了查是有編輯者刪除了，可能他認為那是考古專家學者考據的年代，不是當時人寫下的年代，譬如，古埃及第三xxx王朝約西元前xxx年-西元前xxx年，所以編輯者把年代刪除在內容改成不知道，現在可以這樣嗎？><?我怕搞不清楚狀況所以問問。--User:浪子魚|愛偷懶的魚🐠※User talk:浪子魚|留言 2021年2月26日 (五) 16:43 (UTC) ──以上未簽名的留言由浪子魚（討論｜貢獻）加入。

@浪子魚：不太清楚您的意思，是条目内容还是分类，年代与条目主题的关系。麻烦您将签名加上内部链接，不然别人不方便查阅和回复，您的ping也不会生效。--YF dyh000（留言） 2021年2月26日 (五) 21:01 (UTC)[回复]

@YFdyh000：好，謝謝你告訴我浪子魚（留言） 2021年3月9日 (二) 07:12 (UTC)[回复]

針對性決議

通過：

通過。SAN MO SA _Σουέζ 2021年3月29日 (一) 09:11 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

我這裏的建議是：為便利分類維護，並避免由模板自動產生的分類出錯，當將所有以“YY世紀YY年代”格式命名的分類重新命名為“XXXX年代”格式、將所有以“創立”格式命名的分類重新命名為“建立”格式。頁面命名一致性的通用（普遍性）條文會稍後草擬，針對性的決議應該先通過。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 08:18 (UTC)[回复]

現公示以下針對性決議7日：將所有以「YY世紀YY年代」格式命名的分類重新命名為「XXXX年代」格式、將所有以「創立」格式命名的分類重新命名為「建立」格式。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 10:15 (UTC)[回复]

(＋)贊成--YF dyh000（留言） 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)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

@YFdyh000、StevenK234、迴廊彼端：決議已通過。名為「創立」的分類已經全部處理。以“YY世紀YY年代”格式命名的分類太多，未能全部重新命名，暫時只處理了「19世紀00年代」、「19世紀10年代」、「21世紀10年代」、「21世紀20年代」和整個18世紀，其他可能需要請求bot，或靠各位的幫助自行移動，我會嘗試移動一部分。移動理由應使用「Special:diff/64972159決議通過統一命名格式」。SAN MO SA _Σουέζ 2021年3月29日 (一) 09:28 (UTC)[回复]

頁面命名一致性的通用（普遍性）條文

暫時不太想得到該怎樣寫。我可能要再看一看英文維基百科的對應規定，7日內應該能夠寫好。各位如果有其他的草案提議，也可以直接提。SAN MO SA _Σουέζ 2021年3月29日 (一) 11:35 (UTC)[回复]

引入一致性之后，一致性和常用（同主条目一致=主条目命名时的常用）会有冲突的问题。 --达师 - 370 - 608 2021年4月13日 (二) 16:37 (UTC)[回复]
如果是說條目的話，確然，因此若確立命名一致性規定，可能需要就個別條目的命名再進行討論，但實際操作上通常會依照主條目常用名作命名一致性處理，因此發生衝突的機會可能沒想像中大。如果是說條目以外的頁面的話（我會將對條目以外的頁面的規定分開處理，不放入命名常規），則未必。SAN MO SA _Σουέζ 2021年4月14日 (三) 13:14 (UTC)[回复]

暫時有這個條文草稿：

就條目命名（寫入Wikipedia:命名常规#技术要求或Wikipedia:命名常规#命名原则，寫入位置的不同會影響規則強度）：

“

快捷方式

命名一致性

條目（包括列表條目，下同）的命名的格式（包括但不限於用詞）應與其他同類條目的命名的格式一致^{[註 1]}。部分專題已經設置適用於該專題的子命名常規，並已在其中包含對該類條目的命名的格式的規範。其他條目的命名的格式由社群討論商定，並應立為子命名常規，否則應在《條目命名一致性決議》頁面予以記載。

”

就分類頁面命名（寫入Wikipedia:分类名称#通则）：

“

命名一致性

分類頁面的命名的格式（包括但不限於用詞）應與其他同類分類頁面的命名的格式一致^{[註 1]}。分類頁面的命名的格式由社群討論商定，並在《分類頁面命名一致性決議》頁面予以記載。

”

就其他非條目頁面命名（另開頁面）：

“

命名一致性

非條目頁面的命名的格式（包括但不限於用詞）應與其他同類非條目頁面的命名的格式一致^{[註 1]}。方針及指引頁面的命名的格式由《方針及指引》頁面的相關條文指定，而分類頁面的命名的格式則由《分類名稱》頁面的相關條文指定。其他非條目頁面的命名的格式由社群討論商定，並在《其他非條目頁面命名一致性決議》頁面予以記載。

”

^ ^1.0 ^1.1 ^1.2 使用地區詞處理至一致也算作一致。

以上。@hat600、Milkypine、YFdyh000。SAN MO SA _Σουέζ 2021年4月19日 (一) 06:24 (UTC)[回复]

本討論章節會維持開放，暫時不按最後意見發表時間存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

支持讓子命名常規處理該類條目的命名的格式的規範。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:05 (UTC)[回复]

請求第三方管理員參與評估和總結可靠來源討論

本主題全部或部分段落文字，已移動至WP:VPD。执行人：痛心疾首 2021年4月18日 (日) 12:40 (UTC)。[回复]

關於Wikipedia:命名常规 (音乐)

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:命名常规 (音乐)。

延續上次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)[回复]

有ping到。請簡單歸納一下你覺得討論者需要注意的重點。謝謝。－hiJK910 ^七一_七二一 2021年3月15日 (一) 14:10 (UTC)[回复]

@Hijk910：注意的重點嘛...，當屬於上次關於外文問題所寫的「外文規範」，另外我也把上次羊羊32521大的古典音樂內容放入其中。而括號的使用和消歧義，想說藉由這次討論一起解決。 --無心*插柳*柳橙汁 2021年3月15日 (一) 15:11 (UTC)[回复]

有。我被ping了兩次。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年3月15日 (一) 14:14 (UTC)[回复]

(！)意見：1. 「夠格」一詞不夠正式。2. 關於「「『(歌曲)』：適用於所有歌曲，通常命名時優先使用」，請問是不是指像炎 (歌曲)這些「(歌曲)」跟「(單曲)」皆可的條目，「必須」還是「建議」以「(歌曲)」為消歧義呢？－hiJK910 ^七一_七二一 2021年3月15日 (一) 14:18 (UTC)[回复]

~~我這個人最沒有主見了~~，關於「(單曲)」，我上次被百战天虫大說服後[5]，覺得很有道理。當然，如果是像ARRIVAL OF EVERGLOW這種單曲專輯使用「(單曲)」，我就覺得還行。

但就目前而言，都是歌曲不用「(歌曲)」而使用「(單曲)」到底是為什麼？我這邊問一下@Ryokie38：，當初建立½ (川本真琴單曲)使用單曲而不像1/2 (川本真琴の曲)（日语：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)[回复]

对于单首发行的歌曲，消歧义时用歌曲没有问题，但是当单曲发行时有附带B面歌曲且该条目也有介绍该B面歌曲（而不是顺带提及）的时候，用单曲消歧义更合适吧。--无所事事/想要狗带 2021年3月16日 (二) 19:05 (UTC)[回复]

@Softyu：我也有這麼想過，但鑑定不容易。我在下面列出幾個，你覺得哪些可以保留其單曲消歧义。 --無心*插柳*柳橙汁 2021年3月17日 (三) 15:49 (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)[回复]

单曲与歌曲是明显不同的概念，只要以单曲形式发行的作品，不论是一首歌几首歌，都应称为单曲。对于某些特殊的歌曲，比如我和你 (歌曲)之类，其制作背景不是以发行单曲为目的，或没有发行单曲，此时才合适用歌曲。->>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)[回复]

很抱歉，我不能理解只在乎容器，而忽視它終究是飯的事實。關於單曲與歌曲的問題就看其他維基人的意思，再來評斷。 --無心*插柳*柳橙汁 2021年3月26日 (五) 05:44 (UTC)[回复]

"上次討論"的連結失效了。--Temp3600（留言） 2021年3月17日 (三) 17:55 (UTC)[回复]

"上次討論"的連結以補充。 --無心*插柳*柳橙汁 2021年3月17日 (三) 23:56 (UTC)[回复]

Wikipedia:命名常规 (音乐)1.0更新報告

感謝大家的意見回饋，自3/14以來，本指引更新下列內容，歡迎大家查閱。 --無心*插柳*柳橙汁 2021年3月25日 (四) 05:33 (UTC)[回复]

「古典音樂作品」敘述修正
「使用中文」內容增加
「外文規範」內容增加
「括號的使用」修改為「符號使用」，並增加「斜線」、「書名號」和「特殊符號」的說明與範例。
「消歧義」內容增加
「注釋」敘述修正

由於人數眾多，這邊分開ping相關討論用戶。 --無心*插柳*柳橙汁 2021年3月25日 (四) 05:42 (UTC)[回复]

我本来就对“古典音乐作品”第一行“对序号是10（不含）以上的作品，‘号’字省略”有点疑虑，这样分类讨论，不利于条目名的统一性。^[1]希望能交付社群讨论。另ping一下之前参与过相关讨论的@Foamposite、Iokseng、Anakharsis： ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月25日 (四) 06:05 (UTC)[回复]
我認為日文羅馬化可能需要詳細規定，例如shi或si到底要使用何者，《日語羅馬字》中有寫到三種羅馬化方式，看是要採用哪一種。空氣小貓（留言） 2021年3月25日 (四) 10:24 (UTC)[回复]
我建議如果官方沒有給出羅馬字的話，全部統一用平文式羅馬字。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 10:27 (UTC)[回复]
我也是這樣認為。空氣小貓（留言） 2021年3月25日 (四) 10:48 (UTC)[回复]
@Pseudo Classes、Sanmosa：以新增。 --無心*插柳*柳橙汁 2021年3月25日 (四) 11:05 (UTC)[回复]

@Milkypine：「對序號是10（不含）以上的作品，『號』字省略」是此類音樂作品的常用名稱的做法嗎？SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 09:57 (UTC)[回复]

@Sanmosa：古典音樂的部分主要根據User:Anakharsis/沙盒#建立条目編寫，至於是否為此類音樂作品的常用名稱做法...這部分需要古典音樂的編輯來回答（技術上來講我會寫原聲帶但不等於我熟悉古典音樂）。 --無心*插柳*柳橙汁 2021年3月26日 (五) 12:41 (UTC)[回复]

@Milkypine：我看了一下應該是對現行做法的總結。然而，我也看過了來源一下，似乎即使號碼大過10，加「號」字還是比較常見。我建議基於常用名稱的原則，將『序號使用阿拉伯數字，前面有「第」字；作曲家名字放在半角括號內，括號之前有一個半角空格。對序號是10（不含）以上的作品，「號」字省略』的規則改為『序號使用阿拉伯數字，前面有「第」字，後面有「號」字；作曲家名字放在半角括號內，括號之前有一個半角空格』。SAN MO SA _{江南好，風景舊曾諳} 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）我注意到大家关于“号”的讨论，我赞成“第”后面加“号”，不需要去管超过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)[回复]

我赞同你的说明，特别是对于第5项的说明。我认为完全可以纳入到命名的规则之中。感谢~-李新阳（留言） 2021年4月3日 (六) 19:06 (UTC)[回复]

我原先倒是想一律不用号字。我在大陆，我看到的来源（包括中央音乐学院的本科招生简章、校外考级教材，中国音乐家协会的考级教材，人民音乐出版社和花城出版社的初高中课本）只要是数字+体裁的，都没有号字。但是数字用的是汉字。难道这得按地区词处理？ ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月28日 (日) 14:55 (UTC)[回复]

(～)補充：在花城出版社《音乐鉴赏》（2004.8第一版）第115页下方对莫扎特的介绍中出现了阿拉伯数字的写法：“《g小调第40交响曲》《第41交响曲》（朱比特）” ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月28日 (日) 15:51 (UTC)[回复]

我理解羊羊说到的这个现象，不同地区对于曲目的命名确实存在差异。如中国爱乐乐团的曲目设置中，我们称“《古斯塔夫·马勒：第七交响曲》”，^[2]而在国立台湾交响乐团的曲目设置中，我们称“《馬勒：D大調第一號交響曲》”。^[3]当然这并不意味着大陆就一定不使用“号”，或台湾地区就一定使用“号”，比如国家大剧院就称呼“《贝多芬 C小调第五号交响曲，Op.67》”或^[4]在“实践中”，维基百科古典音乐条目的命名中我们普遍使用“号”这个东西。虽然我个人觉得“号”不“号”的无可厚非，但我认为我们应当在维基百科中有一个统一的有共识的对于“号”的规定，我可能不会建议在这样的事情上按地区词处理，可能显得没有必要。(＆)建議：我个人支持在命名时保留“号”这个东西，因为这似乎已经成了维基百科“没有特别规定的共识和实践”，且考虑到这个实践已经存在很长时间了，符合大家的写作习惯。我支持应当采用汉字表示具体的数字，如一、二等，而非使用阿拉伯数字。因为这个是对于大陆和台湾地区而言都通用的。--李新阳（留言） 2021年3月28日 (日) 18:35 (UTC)[回复]

可也。不过我还是建议阿拉伯数字——第一百零三号交响曲 (海顿)实在难看-- ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 05:18 (UTC)[回复]

而且可能得设重定向 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 05:22 (UTC)[回复]

思来也是，而且也考虑到现在维基百科的大多数条目都是用阿拉伯数字的惯例的话。羊羊举得这个例子很好，一百零三号交响曲，哈哈哈哈哈哈；那么使用阿拉伯数字可以应付汉字所不能应付的情况，我认为可。感谢~--李新阳（留言） 2021年4月3日 (六) 19:14 (UTC)[回复]

对于李新阳其它几点内容：

见上。
“（贝多芬作品）”不在条目名称里，这个括号只是解释说明作用，没什么关系^[5]。但是个人觉得这一条有点问题，可能有不止一个作曲家的降E大调弦乐五重奏序号不详、有争议或无可靠来源使用，建议改成：调性优先，若无须消歧义，作曲家名字可以省略。
调性的问题。我认为应该用汉字“升”和“降”。至于字母大小写，我觉得争议出在小调上。英维古典音乐专题的Guidelines有说，大意是D小调可以简写为d调，但不能写d小调这种缝合怪。^[6]然而我能看到的来源，（作品名还有行文）D小调和d小调都有，甚至感觉d小调更多。我觉得还是按中文习惯，大调大写，小调小写。
建议改成：如果该作品的名称是独一无二的，且无须消歧义，则作曲家名字也可以省略。
我觉得应该不是问题，第一条解决的就是通用情况。

以上。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 06:02 (UTC)[回复]

感谢羊羊对于关于大小调的叙述，我支持进行“大调大写，小调小写”的方式，合乎乐理，然后使用汉语表示升降号，以及新增关于“且无须消歧义”的条文。--李新阳（留言） 2021年3月29日 (一) 08:11 (UTC)[回复]

我自己反而是沒看過「小調小寫」的處理。SAN MO SA _Σουέζ 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)[回复]

补了个签名 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月1日 (四) 15:26 (UTC)[回复]

好吧，为尽快了结，可以搞一个独立的拆分讨论大小调的问题。对于[[夜曲Op. 9 (蕭邦)]这种东西现在就暂时不做处理（吗）？（我倒是无所谓，我比较随意）。--李新阳（留言） 2021年4月3日 (六) 18:58 (UTC)[回复]

「命名中几乎遇不到小调大小写的情况」，我不清楚古典音樂們有多少，但對於小調，我想這部分可以一起處理，尤其是Template:Circle of fifths。~~不過這麼一搞，條目裡面有出現小調我可能都要修改了OTZ~~ --Loving You Is A Losing Game 2021年3月31日 (三) 14:28 (UTC)[回复]

辛苦啦~--李新阳（留言） 2021年4月3日 (六) 19:00 (UTC)[回复]

Wikipedia:命名常规 (音乐)2.0更新報告

感謝大家的意見回饋，這次根據上次1.0的討論修改古典音樂，並增加「 (單曲專輯)」的消歧義。歡迎大家查閱。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:04 (UTC)[回复]

由於人數眾多，這邊分開ping相關討論用戶。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:06 (UTC)[回复]

括號一節舉的例子不是有全形字元（中文字）嗎？如果我沒理解錯誤的話，不應該是要用全形括號？空氣小貓（留言） 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)[回复]

已查閱，感謝貢獻。--SickManWP_{歡迎參與♥️邊緣人小組的活動·✏簽到}發表於 2021年4月10日 (六) 08:25 (UTC)[回复]

作出了一笔事实性编辑，另“大调大写，小调小写”的例子不妥（D大调、d小调），毕竟页面第一个字必须大写，建议改成

條目名稱須符合「大調大寫，小調小寫」，如“D大調”、“d小調”。

或是

條目名稱須符合「大調大寫，小調小寫」，如“D大調”、“d小調”。
例：降B大調、升f小調

以上。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月10日 (六) 15:33 (UTC)[回复]

@羊羊32521：页面第一个字雖然必须大写，但d小調和iPhone一樣，都在其（樂理）領域屬於特定詞語，因此使用小血沒有問題。 --Loving You Is A Losing Game 2021年4月10日 (六) 16:50 (UTC)[回复]

好 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月11日 (日) 02:26 (UTC)[回复]

Wikipedia:命名常规 (音乐)公示

感謝大家的意見，現將Wikipedia:命名常规 (音乐)公示。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:36 (UTC)[回复]

由於人數眾多，這邊分開ping相關討論用戶。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:39 (UTC)[回复]

(？)疑問@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 talk:共识。

最近客棧的提案實在是不勝Wikipedia:共识#提案討論及公示時間的困擾，但不太想盡廢，因此提一個修正案：

現行條文

為了確保所有使用者有充足的時間發表意見以及得悉改動，如果在互助客栈中被提出的提案在七天內沒有新留言或至少討論達一個月以上的情況下，只要取得共識便可公示，為期七天。公示期間若无异议，则提案算作通过；如果有新意見，請通過協商解決問題。存檔後如果要重新提出公示的話，應同時補回相關討論連結，以便社群查閱。

提議條文

為確保所有使用者有充足的時間發表意見及得悉改動，在互助客栈中被提出的提案若在7日內無新留言^[1]，又或討論已持續28日以上的情況下，只要討論取得共識，即可公示，公示為期至少7日。公示期間若無合理異議，作通過論，若有新合理意見，應經協商解決問題。

参考資料

^ 不對提案進行實則性點評的支持意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

以上。SAN MO SA _{江南好，風景舊曾諳} 2021年3月14日 (日) 15:31 (UTC)[回复]

主要影響：

不對提案進行實則性點評的支持意見不造成重算7日。
與提案本身無關的意見不造成重算7日。
將浮動的時間範圍「1個月」界定為固定的時間範圍「28日」。
容許公示在有必要時可長於7日。

以上。SAN MO SA _{江南好，風景舊曾諳} 2021年3月14日 (日) 15:36 (UTC)[回复]

(？)疑問：

原條文有「如果在互助客栈中被提出的提案」一句，在新條文要刪去嗎?
參閱Wikipedia:互助客栈/条目探讨#春晚及春晚 (消歧義)，這種在Wikipedia:互助客栈/条目探讨的提案是否需要遵守WP:7DAYS?或是要將WP:7DAYS限定在Wikipedia:互助客栈/方针?--CaryCheng（留言） 2021年3月15日 (一) 02:41 (UTC)[回复]

@CaryCheng：（1）漏留意，已補回。（2）理論上要遵從。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 05:53 (UTC)[回复]

@CaryCheng：就（2）作補充：我是説如果決定要進行公示的話，理論上要遵從WP:7DAYS，但是如果不涉及修改方針指引或修改高風險模板的話，一般性的爭議解決討論好像是不用進行公示的，基本上爭議解決了就可以直接關。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 08:45 (UTC)[回复]

(？)疑問:這個提案改過很多次，而且30天和28天就差兩天，有必要改來改去嗎？而且一年就只有二月會有28天，大家都會以30天為一個月的概念，這種修改有甚麼意義呢？--蟲蟲飛♡♡→♡℃※留言 2021年3月15日 (一) 03:52 (UTC)[回复]

1年有7個月是31日，何來「以30天為一個月的概念」？再者，1年12個月的日數不同，假設我在2月1日提案，我最遲可以在28日後公示，但假設我在3月1日提案，我最遲在31日後才能公示（4月同理，最遲在30日後才能公示），這對於在有30日／31日的月份提案的人非常不公平，但如果統一為30日，這會損害在2月提案者的公平性，因為30日的時間必定比2月長，這樣在2月提案的人就會要在多於一個月的時間後才能公示。因此，最公平的方式為統一成28日。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 05:53 (UTC)[回复]

(？)疑問:大致同意，而且也會看到這裡用雪球快速公示，好像也沒完全照規定走。但是這裡有些疑問要問一下，如何界定「已取得共識」、「合理異議」，「合理意見」？合理異議、意見會不會變成兩集團互斥對方不合理。只有一人提問，無人贊成、反對，算不算已取得共識，然後可以公示?這些提案人可以一併考慮，把規定寫更好一些。--2001:B042:1:A9ED:F58C:12D4:4C7B:B776（留言） 2021年3月15日 (一) 06:32 (UTC)[回复]

（1）沒人抓的話其實是沒人會遵守這規定。（2）以前的人進行公示的時候都是説“現公示7日，無合理異議者即作通過”，跟以前的做法處理。（3）提案與現行辦法對於“只有一人提問，無人贊成、反對”的提案的態度是原則上可以公示，這當然會產生一些奇怪的現象（當然如果提案人能夠好好處理提問的話，我倒是覺得可以照樣公示通過），先前討論也談論過，但沒人管。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 07:54 (UTC)[回复]

回答的很完整。不縮小「無新留言」範圍，結果時間等太久，沒人抓大家就不走規定。不討論「已達成共識」定義，結果「一人提問，無人贊成、反對」，反而7日後就可以公示。這是不見得會有問題，但又有一些奇特的現象。--2001:B042:1:ABD5:F58C:12D4:4C7B:B776（留言） 2021年3月15日 (一) 08:27 (UTC)[回复]

所以有時候我會抓一下7日的計算（雖然我自己也不滿現在這規定）。如果“只有一人提問，無人贊成、反對”的提案出現的話，提案人能不能夠好好處理提問是一個重點，如果不能的話，理論上可以抓「已取得共識」一條來說有程序性問題。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 08:42 (UTC)[回复]

(－)反对:重看了一下，註腳很有問題，而且只會增加爭議，應刪去。--蟲蟲飛♡♡→♡℃※留言 2021年3月15日 (一) 06:41 (UTC)[回复]

不同意。這是修訂提案的主要目的之一。之前的討論的主流意見都認同不應該使所有意見都能導致重算7日（我個人比較看重的是DrizzleD的意見）。我邀請一下之前參與過討論的@KirkLU、DrizzleD、BureibuNeko、UjuiUjuMandan、Fire-and-Ice來好了。SAN MO SA _{江南好，風景舊曾諳} 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）現成的問題。SAN MO SA _{江南好，風景舊曾諳} 2021年3月16日 (二) 05:53 (UTC)[回复]

(※)注意:請看一下這個提案，有一大堆支持，也已經討論了一個月，還是有人反對，當時也有人催快點公示，也有朋友對說我要快公示，怕夜長夢多，會出現(－)反对，但提案的目的是要尋求共識，而不是快快通過，然後出現爭議，因此急於通過是不必要的，有共識的提案也不怕多放幾天。--蟲蟲飛♡♡→♡℃※留言 2021年3月16日 (二) 06:13 (UTC)[回复]

你對互助客棧討論的想法完全違背進行互助客棧討論應有的健康心態。SAN MO SA _{江南好，風景舊曾諳} 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)[回复]

然而方針指引不能阻止任何用戶發表不相關的意見。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 05:43 (UTC)[回复]

如何定義「不相關」？誰去決定？雙方也可以互相指責對方的留言「不相關」，為甚麼要令提案增加不必要的爭議？AT現行版本是最好的，「七天沒留言」是客觀標準，沒有爭議空間。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:12 (UTC)[回复]

（1）依據「共識應當考慮到所有正當合理的意見」此條方針來定義。（2）最極端的情況就找行政員，天仍然不會因此塌下來。（3）極端嚴格的「7天沒留言」是客觀標準沒錯，然而違反常識、慣性、正常討論生態和「共識應當考慮到所有正當合理的意見」此條方針。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 12:43 (UTC)[回复]

所以，這種提案還是，被改完的7days攔下吧？-- Sunny00217 2021年3月22日 (一) 16:25 (UTC)[回复]

从现存留言上来看，应该会，因为相邻两条有说理的评论之间均小于7天。当然，改了WP:7Days之后同时可能会促使反对的人更早留言，这就是另一回事了。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 06:27 (UTC)[回复]

@Sunny00217。SAN MO SA _{江南好，風景舊曾諳} 2021年3月16日 (二) 05:56 (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)[回复]

不如此修訂的話，會對互助客棧的討論生態造成嚴重扭曲。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 05:43 (UTC)[回复]

「討論被扭曲」是您說的，不是事實。客棧的提案不是為了收集支持，而是看看有沒有(－)反对，因為提案如果沒有反對，公示後就可以通過，因此公示的過程就是要令提案收集更多的意見，而這七天已經是下限，沒必要再縮減。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:08 (UTC)[回复]

DrizzleD的1和2已經駁斥了你上面聲稱的東西（這個修正案完全沒說要縮短七天這個時間；留言支持者越多，說明通過提案越不強行，而不是相反）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 12:14 (UTC)[回复]

那也要看回應的理據是否成立，不是回應了就算。我在上面還沒看到有任何理據是成立。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:21 (UTC)[回复]

我真誠相信這是因為你中文理解能力有問題的緣故。換作任何其他一個人，他們都必定能夠理解提案的原因，並認為其合理。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 12:43 (UTC)[回复]

您請保持禮儀及文明﹗也請不要訴諸人身﹗--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:51 (UTC)[回复]

没有对“不修改”、“現行版較佳”的观点表示反对。核心是认为可以没有明示规定但要尊重实操中的默契。（比如，规则上尽可以挑战Wikipedia:互助客栈/方针/存档/2021年3月#修订R3适用情形五的公示[毕竟严格意义上他远没有7天]，但缺乏意义，只会把程序性修订也拖得冗长。于我个人而言，如果有挑战，我一定会尊重这种挑战，因为方针如此，效果也不过是拖到下个月再公示。但缺乏意义。）--Kirk★ # 2021年3月17日 (三) 13:36 (UTC)[回复]

不肯定您記得不記得，之前就試過有提案因為公示沒有嚴格依從7days去進行，結果即使提案通過了多天，仍然引發了社羣對提案的有效性的質疑。請注意方針修訂是要面對整個社羣，而不是幾個討論的人同意就可以繞過方針。而且方針指引的有效性不是一時的，可以在幾年後，十幾年後，用戶翻閱存檔時，也可以再次質疑提案的有效性。此外，如果提案是有共識，就不要心急通過，也不用怕多放幾天會有反對。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 13:45 (UTC)[回复]

這是因為此規則存在。假設此規則不存在，該公示理論上是完全沒問題的。極端嚴格的「7天沒留言」規則會帶來遊戲規則的可操作性。SAN MO SA _{江南好，風景舊曾諳} 2021年3月18日 (四) 05:47 (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日了，結果就直接過了。SAN MO SA _{江南好，風景舊曾諳} 2021年3月19日 (五) 09:28 (UTC)[回复]

其他用戶怎樣做，我不評論，但IAR是不能亂用。而且我覺得現行方針較佳，沒必要修改，而且提案也帶出了新的爭議。--蟲蟲飛♡♡→♡℃※留言 2021年3月20日 (六) 08:41 (UTC)[回复]

正是因为不能一直IAR下去，所以才要改规定啊。--DrizzleD _{(按此给我留言)} 2021年3月21日 (日) 05:21 (UTC)[回复]

剩下两点。1.没必要不是只有“必要”的事我们才做，有益于维基百科就可以了。2.新的争议争议不是个天生的坏东西，当区分有益的时候，有争议也要区分。--DrizzleD _{(按此给我留言)} 2021年3月21日 (日) 05:36 (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)[回复]

(＋)支持。——BlackShadowG（留言）_{维基百科20岁生日快乐！} 2021年3月21日 (日) 01:27 (UTC)[回复]
(－)反对：不看好新版条文，因为容易引发争议。--DavidHuai1999※Talk 2021年3月21日 (日) 05:41 (UTC)[回复]
有时候，增加争议是有益的。--DrizzleD _{(按此给我留言)} 2021年3月21日 (日) 06:10 (UTC)[回复]

(？)異議：方針修訂屬於重大提案，如果出現任何爭議都會令提案的合法性受到質疑，所以我覺得ＡＴ現行版本較佳，修訂版本不但沒有解決問題，而且帶出了新的問題。--蟲蟲飛♡♡→♡℃※留言 2021年3月21日 (日) 06:17 (UTC)[回复]

增加爭議是有益的^{[來源請求]}-- Sunny00217 2021年3月22日 (一) 16:34 (UTC)[回复]

论据已经写在上面（并已链接到）了。WP空间内容不是条目，来源不一定有必要，不然讨论没办法进行。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 06:43 (UTC)[回复]

調適案1

現行條文

為了確保所有使用者有充足的時間發表意見以及得悉改動，如果在互助客栈中被提出的提案在七天內沒有新留言或至少討論達一個月以上的情況下，只要取得共識便可公示，為期七天。公示期間若无异议，则提案算作通过；如果有新意見，請通過協商解決問題。存檔後如果要重新提出公示的話，應同時補回相關討論連結，以便社群查閱。

提議條文

為確保所有使用者有充足的時間發表意見及得悉改動，在互助客栈中被提出的提案若在7日內無新留言^[1]，又或討論已持續28日以上的情況下，只要討論取得共識，即可公示，公示為期至少7日。公示期間若無異議，作通過論，若有新合理意見，應經協商解決問題。存檔後如果要重新提出公示的話，應同時補回相關討論連結，以便社群查閱。

参考資料

^ 不對提案進行任何點評的支持或中立意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

我還是想做到一些東西，退而求其次一下好了。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 08:03 (UTC)[回复]

主要影響：

不對提案進行任何點評的支持或中立意見不造成重算7日。
與提案本身無關的意見不造成重算7日，而意見是否與提案有關根據《討論頁指引》的規定界定。
將浮動的時間範圍「1個月」界定為固定的時間範圍「28日」。（依舊）
容許公示在有必要時可長於7日。（依舊）

以上。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 08:09 (UTC)[回复]

(－)反对:理由同上，我還是覺得AT現行版本較佳，而且提案不但沒有解決問題，而且註腳部分帶出更多的公示爭議。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 13:31 (UTC)[回复]

「不對提案進行任何點評的支持或中立意見」是很容易看出來的事情，多一句話就已經是「點評」了，非常明確，怎麼可能「帶出更多的公示爭議」？《討論頁指引》的規定也應該很清楚明白吧，難道說《討論頁指引》也是形同虛設的？將浮動的時間範圍界定為固定的時間範圍也是明確指引的處理。修訂容許公示時間可長於7日，但沒容許可短於7日，因此公示時間上也不可能產生爭議。綜以上，我完全不認同調適案1「帶出更多的公示爭議」。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 13:39 (UTC)[回复]

現在方針修改頻繁，AT版七天已經算是很合理的時間，頻繁的方針修訂中，讓社群有足夠時間去消化，及讓提案有足夠時間收集更多意見是必須的。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 13:47 (UTC)[回复]

頻繁的方針修訂正是因為社羣有迫切的需求，如果社羣不理解方針修訂的內容，理當向提案人發問（這樣做無論是在原始提案下，抑或在調適案1下，都仍然會造成重算7日），我不明白社羣怎麼在遇到看不明白的事情都不會發問。一味壓抑社羣的迫切需求對社羣而言並不健康，我僅是希望將equilibrium position稍稍推回到提案人一邊一些而已。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 14:07 (UTC)[回复]

像下方#交通關注度指引修訂這樣的方針修訂，我是不見得需要多長的時間來「消化」。需要較長的時間來「消化」可能是像下方#分案1這樣的方針修訂，那為何不像MINQI這樣去發問？這可能比自己自行「消化」提案內容來得更有效率，使自己更快清楚明白提案內容。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 14:11 (UTC)[回复]

您搞錯了兩者因果關係，正因為修訂頻繁，提案更不應急於公示，應該收集更多意見，而不是火速公示，強行通過，然後有些用戶來不及表達意見，結果爭議不斷。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 14:14 (UTC)[回复]

不，方針指引修訂頻繁是社羣的迫切需求的結果。現行條文只是在無視社羣實際存在的迫切需求，並將之強行壓抑。社羣的迫切需求是方針指引修訂頻繁的產出來源，應當做的是滿足需求，而非壓抑需求。再者，現實上方針指引修訂頻繁不可能等到所有人發表了意見才能處理，否則這就屬於遊戲共識形成程序的情形。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 10:36 (UTC)[回复]

@Sanmosa：不能认可方针的快速频繁修订（及提案和公示）。方针应该是总结归纳长久的共识，仅在争议严重时依充分讨论规定妥协方案（如COVID-19命名）。将未成熟的方针及公示作为约束或指导后续编辑的手段是不正确的，WP:BURO：“不是盲目跟随默认的方针和程序。要避免编写过分冗长的指示。”。应更多以讨论确认意见、指引，而非编立方针来不必要的规约。设立规则来制止他人反而会有GAME之嫌。--YF dyh000（留言） 2021年3月27日 (六) 12:16 (UTC)[回复]

既然社羣存在如此的迫切需求，那相關的規約自然是必要的。必要性取決於需求。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 13:13 (UTC)[回复]

「迫切需求」是您的意見，不是社羣，方針屬於重大提案，應該讓社羣有足夠時間消化及表達意見，千萬不要心急，有共識的提案就不用怕多放幾天有(－)反对，而且急於通過，火速公示，然後爭議不斷，那通過的提案也不是反映共識。--蟲蟲飛♡♡→♡℃※留言 2021年3月28日 (日) 04:54 (UTC)[回复]

方针快速频繁修订是个问题，但如果真的要修订，这里的关注点是，单纯支持之意见不该导致重算。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 06:53 (UTC)[回复]

要说多少遍本提案和“七天”没有任何关系。实话说，您要是觉得时间短，延长到十天我也没意见，但“不对提案进行任何点评的支持或中立意见”能导致重算，究竟合理吗？--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 06:50 (UTC)[回复]

您說沒有評點就提前公示，為甚麼要以不同名目去提前公示呢？請瞭解AT版當時訂的版本就是為了解決社羣急於公示而帶出的爭議問題，為甚麼不能讓提案多收集一些意見呢？而且要注意不是每個用戶都很活躍，讓提案多放一些時才能收集更多意見，因此我覺得AT現行版本較佳。--蟲蟲飛♡♡→♡℃※留言 2021年3月28日 (日) 06:58 (UTC)[回复]
我明白您的意思。您可以看看下面的方案如何。或许看了之后您可以更了解我的想法。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 07:06 (UTC)[回复]

说到这个，为了拯救陷入同义反复的讨论，我决定提出一个新想法，看看能不能抛砖引玉。改成：

為確保所有使用者有充足的時間發表意見及得悉改動，在互助客栈中被提出的提案若在10日內無新留言^[1]，又或討論已持續28日以上的情況下，只要討論取得共識，即可公示，公示為期至少7日。公示期間若無異議，作通過論，若有新合理意見，應經協商解決問題。存檔後如果要重新提出公示的話，應同時補回相關討論連結，以便社群查閱。

参考資料

^ 不對提案進行任何點評的支持或中立意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

即额外把7日改成10日，这下新提案的讨论时间应该不会比旧的情况少了。“应该让社群有足够时间消化及表达意见，千万不要心急，有共识的提案就不用怕多放几天有(－)反对，而且急于通过，火速公示，然后争议不断，那通过的提案也不是反映共识”，那多几天总没问题吧。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 07:01 (UTC)[回复]

我還是覺得註腳部分有爭議，因為「有沒有點評」不同人都有可能有不同的解讀，而且客棧遇到激烈爭議時，這個註腳只會帶出更多爭議，而且本站社羣還沒有達到英維的客觀與理性，無視反對意見，指鹿為馬等奇怪的事常有，因此我還是(－)反对注腳部分。反而，Sanmosa想爭取28天，減兩天，這個我沒有異議。--蟲蟲飛♡♡→♡℃※留言 2021年3月28日 (日) 07:19 (UTC)[回复]
好，Sanmosa想争取28天，减两天，这个我没有异议，看来我们已经达成了第一个共识，讨论是有成果的了。

下一个点是，您是否觉得不对提案进行任何点评的支持意见不导致重算合理。如果是的话，那我们就达成了下一个共识，只需要关心有没有办法解决“有没有点评”不同人都有可能有不同的解读这个问题就可以了。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 07:51 (UTC)[回复]

「不對提案進行任何點評的支持或中立意見不造成重算7日」這句話的意思我要解釋一下，就是只寫了「支持」、「中立」、「沒意見」、「不反對」之類的，我認為定義已經足夠明確。我不要求只有「實則性點評」才能導致重算7日已經是很大的讓步了。SAN MO SA _······ 2021年3月28日 (日) 23:51 (UTC)[回复]

這是不必要，而且這是您的理解，實際的爭議時，不同人都可能有不同的解讀，我還是覺得AT現行版本較佳，即「七天沒有留言」就可以公示，完全沒有爭議。但您以不同名目去縮短公示期限，這是不必要，而且容易造成爭議。提案的公示一旦有爭議，提案的合法性就會受到質疑，過去是有先例的。--蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 05:05 (UTC)[回复]
- 问题在于，现在有些人看到讨论过了几天，避免重算也不敢支持也不敢中立，我觉得反而不好收集社群意见。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 06:07 (UTC)[回复]

您有所不知，客棧的提案不是收集支持或中立，而是看看有沒有(－)反对，因為提案放出來，七天完全沒有留言，已經可以公示，公示後，沒異議就通過，其他維基也是一樣，因此提案的反對意見比支持的意見重要。而且，「七天沒留言」在維基可視為默認共識，見WP:TALKDONTREVERT：「假如編者已停止在討論頁內回覆相關討論，便可以假定共識已經形成。」--蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 06:30 (UTC)[回复]
如果相關支持意見或中立意見裏面有其他建設性的提議的話，那些意見和反對意見是同等重要的，然而現行條文有可能阻礙相關附有有其他建設性的提議的話支持意見或中立意見的表達。SAN MO SA _······ 2021年3月29日 (一) 06:36 (UTC)[回复]

所以我希望最後的共識能確立該條條文以我上方的解讀為準。SAN MO SA _······ 2021年3月29日 (一) 06:36 (UTC)[回复]

還是回到那個問題，甚麼叫“有建設性的意見”？標準誰定？爭議時互相指責對方的意見“無建設性”，結果把本來不應有的公示爭議，變得非常有爭議。蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 06:53 (UTC)[回复]

我請你重看我的調適案1，我的調適案1完全無提及過「有建設性的意見」，我不知道你是從哪裏看到的，還是你不小心看到了甚麼一般人看不到的東西。如果你是從我上面的留言看到的話，那我只能夠說你真的沒有一般人應有閱讀中文的能力，我說的是現行的條文讓人不願意留下附有其他建設性的提議的支持意見或中立意見，而不是直接阻止，具阻止性質的效果有時候並不需要直接言明的條文達到；至於這事情會產生的問題，那就是只有反對意見得以顯現，使實際的意見比例和表面上所看到的意見的比例不符。SAN MO SA _Σουέζ 2021年3月29日 (一) 10:00 (UTC)[回复]

請重看您於「2021年3月29日 (一) 06:36 (UTC)」的留言。而且「進行任何點評」也是換了不同的名目，性質也是一樣，這些都是不必要的，AT現行版本已經很清晰，沒有修改的必要。--蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 14:02 (UTC)[回复]

完全不一樣，這制限條件已經完全不同了。我真的只能認為你真的沒有一般人應有閱讀中文的能力，這分明已經是兩種完全不同的情況。SAN MO SA _Σουέζ 2021年3月31日 (三) 07:49 (UTC)[回复]

請不要人身攻擊﹗您是換了不同名目去縮短公示期，這是與AT版解決火速公示的提案原意不合。而且我反而我看到您平時公示時一有異議就重新公示，我覺這個操作很不錯，所以建議加一條「公示期間如有異議應重新公示」。--蟲蟲飛♡♡→♡℃※留言 2021年3月31日 (三) 10:35 (UTC)[回复]

「縮短公示期」從不存在，不論是原案抑或調適案也如是。我認為所有用戶均有重新公示的意識，而且重新公示的操作可以依規進行，無須特別規範。SAN MO SA _Σουέζ 2021年4月1日 (四) 00:51 (UTC)[回复]

(－)反对，讚同蟲飛飛的意見。AT的版本已經很清晰。Walter Grassroot（留言） 2021年4月1日 (四) 01:34 (UTC)[回复]

（咦？）SAN MO SA _Σουέζ 2021年4月2日 (五) 08:43 (UTC)[回复]

提案目的并非让方针更“清晰”。--DrizzleD _{(按此给我留言)} 2021年4月4日 (日) 16:24 (UTC)[回复]

(－)反对：在此种情况下应依据常识进行判断，而不是拘泥于方针细节之中。--Yining Chen（留言|签名） 2021年4月4日 (日) 12:05 (UTC)[回复]

就在WP:UCS这一页的图表：是否是规则错了？是→改变规则。--DrizzleD _{(按此给我留言)} 2021年4月4日 (日) 16:29 (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日已經過長，現行方針正在過分鼓吹“讓人有較多時間討論”，結果適得其反，這也是提出是次方針修訂的主因）。我本來的想法是直接縮短那個期限到比任何定義上的“一個月”更短。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:02 (UTC)[回复]

不認為現在的冗長辯論的主因是多了這兩三天，提案要是具爭議的，無論定多少天都會有人拉下去，以現狀來推斷「30日已經過長」、「不可能訂立一個較長的日數」，我認為理據非常不充份。--街燈電箱150號開箱維修抄錶檢驗證明 2021年4月19日 (一) 02:03 (UTC)[回复]

@Cdip150：建議你看看這規則通過以來的所有客棧討論，一個與討論主題不相關的留言直接導致公示延後非常常見。現行規則唯一的“作用”是在不必要地拖時間。SAN MO SA _Σουέζ 2021年4月19日 (一) 02:15 (UTC)[回复]

「一個與討論主題不相關的留言」與至少多少天是不相關的，就算定了28天，不代表那些不相關的留言就會少。又或者說簡單一點，這種延後的原因本來就不是出在「一個月」身上。--街燈電箱150號開箱維修抄錶檢驗證明 2021年4月19日 (一) 03:23 (UTC)[回复]

受影響規模會縮減。SAN MO SA _Σουέζ 2021年4月19日 (一) 03:54 (UTC)[回复]

(？)異議:完全同意Cdip150，完全看不到有甚麼理據一定要改為28天，而且不認為會減少影響，而且這個提案根本就沒必要。頻繁提案改方針，急速公示，強行通過，除了增加爭議，一點意義都沒有。--蟲蟲飛♡♡→♡℃※留言 2021年4月19日 (一) 04:20 (UTC)[回复]

(－)傾向反對，意見同Cdip150閣下。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年4月19日 (一) 05:30 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:捷徑、Wikipedia talk:偽命名空間輔助說明。

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

@A2569875、Taiwania Justo、Yining Chen、羊羊32521、YFdyh000、@LuciferianThomas、Ericliu1912、MilkyDefer、Super Wang、Sunny00217。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 09:08 (UTC)[回复]

(＋)支持。偽命名空間運行暢順，可選擇有需要的計劃空間內容增設偽命名空間。(＆)建議命名常規使用「NC」字首、關注度使用「N」字首。另(＆)建議增設共識（討論）捷徑「CON」，連結至各討論存檔（Talk、WT、PJT）或資訊頁（WP），如CON:COVID19指向COVID-19條目共識。--LuciferianThomas．留言 2021年3月24日 (三) 09:32 (UTC)[回复]

NC和N可行。CON可行，但建議另外討論，因為CON可以重新導向到的目標有太多類頁面。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 10:00 (UTC)[回复]

支持N和NC，对CON保留意见 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月25日 (四) 06:07 (UTC)[回复]

N的话会不会短了点？之前MOS和LTA的时候因为是三个字母，跟正式条目命名撞车的可能性小所以没有问题。这一个N我个人有点拿不准。此外我觉得CON可能还不是时候。在我的认知中，单独讨论出共识单独成页的也就只有COVID-19这一个了，至少应当等类似的页面数量足够多了再提出会比较好。如果有我不知道的类似页面尽管告诉我。 --Milky·Defer 2021年3月25日 (四) 07:36 (UTC)[回复]

檢查過，現時沒有條目空間的頁面是「N:」開首的。如果真的不放心的話，NT和NOTE也可以（但不能NOT）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 07:44 (UTC)[回复]

@sanmosa：维基新闻的前缀就是“n:”，烦请查询Special:跨wiki。--痛心疾首 2021年4月2日 (五) 15:43 (UTC)[回复]

啊，忘了。SAN MO SA _Σουέζ 2021年4月3日 (六) 00:12 (UTC)[回复]

先跑题：MOS基本没用过，看到时我习惯改用WP前缀。LTA用过但没有独立空间所以搜索很不方便，期望未来设独立空间、增设访问限制。然后：我不清楚相关页面有多少，如果很少，可能用的人也不会很多？以及持久性不会好（几年后失效）。N有点短，NOTE我想到[{tl|TA}}和备注，命名常规为什么不是NAME:（但未来会不会冲突？）。关注度没想法，考虑到“关注度”定名本身都有质疑，我暂时想不到很好的。NT在中国大陆网络有贬义“脑瘫”，不赞成。--YF dyh000（留言） 2021年3月25日 (四) 12:14 (UTC)[回复]

@YFdyh000：「NAME:」應該不會衝突吧，也不不失是一個好提議。「NT:」你當我真的NT了吧（在香港「NT」指新界，不過以地名開首還是有些怪）。「NOTA:」不知如何，有種葡文風，但字源仍是「Notability」，衝突的機會也低。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 13:01 (UTC)[回复]

(－)反对，如果将编辑社群页面等因为与Wikipedia命名空间关联性不强而划分出的话，方针等与项目运营有关的的页面不应该划出Wikipedia空间，而且本身这部分已经能通过消歧义的方式处理，没坏别瞎修。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年3月26日 (五) 00:54 (UTC)[回复]

@cwek：偽命名空間僅用於設置重新導向頁面（這是指引指明的），完全沒有你所說的「（將導向目標）劃出Wikipedia空間」那回事。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 01:00 (UTC)[回复]

偽命名空間作用並非直接劃出內容，而是作捷徑之用：#偽命名空間、WP:PNS、WP:PNS+。因為似乎對於提案內容有所誤解，反對的事也並非現在實際正在討論之議案，故難以算作有效反對意見。--LuciferianThomas．留言 2021年3月28日 (日) 06:23 (UTC)[回复]

又想了一下，关注度用用NOTA:什么的太长，不是太有必要，WP:Nxxxx辨识度已经够，NT可行。仍支持NC。nc不是还有脑残的意思？（ ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月8日 (四) 15:16 (UTC)[回复]
Naming Conventions... 別想歪就好了啦。--LuciferianThomas．留言 2021年4月10日 (六) 23:10 (UTC)[回复]

初步定案

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

模板颜色相关规范

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手冊/文字格式、Wikipedia talk:分類、列表與導航模板。

本主題或以下段落文字，移動自Wikipedia:互助客栈/条目探讨。执行者：SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 08:57 (UTC)。[回复]

想问一下关于模板的相关规范：现在的模板并没有任何关于颜色的规范。我个人希望模板的颜色本身不应被任何其他的配色所取代（模板不应被着色），尤其是没有达成任何Accessability相关要求的共识前，均不应当修改任何着色，否则将会可能影响读者正常阅读模板。--1233 （T / C） 2021年3月22日 (一) 13:19 (UTC)[回复]

可参见WCAG 2.1 AA。--痛心疾首 2021年3月22日 (一) 13:34 (UTC)[回复]

Wikipedia:格式手冊/文字格式#颜色及内联图像算不算？SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 13:52 (UTC)[回复]

導航模板不算正文（邏輯上）。就是此前處理了一個WCAG 2.1有問題的模板我才開啟討論。1233 （T / C） 2021年3月23日 (二) 03:51 (UTC)[回复]

Wikipedia:格式手冊/文字格式#颜色及内联图像的確無法處理導航模板。 --無心*插柳*柳橙汁 2021年3月24日 (三) 03:31 (UTC)[回复]

@1233、Milkypine：可以擴大Wikipedia:格式手冊/文字格式#颜色及内联图像的適用範圍。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 04:40 (UTC)[回复]

完全支持擴大適用範圍。 --無心*插柳*柳橙汁 2021年3月25日 (四) 05:13 (UTC)[回复]

可解決問題，故支持。唯此格式手冊的修訂將會影響大量的模板，故需要更深入的討論。--1233 （T / C） 2021年3月25日 (四) 15:23 (UTC)[回复]

@痛心疾首、Milkypine、1233：已移動討論至方針區。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 09:01 (UTC)[回复]

擬修改如下：

現行條文

颜色及内联图像

在条目正文及表格之中，禁止手动或使用模板将文字染成某种特殊的颜色，可以接受的情况仅限于信息框中。这一方面是为了减轻服务器负担以及方便后来编辑者的维护，另一方面是为了方便色盲、色弱或使用黑白版本的读者阅读文字。^[1]

只有在背景顏色可幫助闡釋條目內容，且沒有其他更佳的表達方式時，才可對表格或其他的內文元素加入背景顏色。為了照顧視障或色覺障礙讀者的需要，請避免單獨地使用背景顏色來表達某一含義，而應適當地同時以文字方式表述。為了保障條目的可讀性，請避免使用飽和度過高，或與文字對比度不足的顏色作為表格的背景色。禁止使用CSS代碼對表格背景加入花俏的樣式（如漸層色等）。

类似地，条目正文中，禁止使用内联图像（例如在文字中出現這樣的图像），但若在表格及信息框中使用則是可以接受的。

参考資料

^ 参见Wikipedia:鐵道專題/移除著色文字模板。

提議條文

颜色及内联图像

条目正文、表格及各類模板（包括信息框）中禁止手动或使用（其他）模板将文字及背景顏色染成非預設颜色。此舉乃是为减轻服务器负担並方便后来编辑者的维护，亦是为方便色盲、色弱或使用黑白版本的读者阅读文字。^[1]

只有在背景顏色可幫助闡釋條目內容，且沒有其他更佳的表達方式時，才可對表格或其他的內文元素加入背景顏色。為了照顧視障或色覺障礙讀者的需要，請避免單獨地使用背景顏色來表達某一含義，而應適當地同時以文字方式表述。為了保障條目的可讀性，請避免使用飽和度過高，或與文字對比度不足的顏色作為表格的背景色。禁止使用CSS代碼對表格背景加入花俏的樣式（如漸層色等）。

同理，条目正文中亦禁止使用内联图像（例如在文字中出現這樣的图像），但在表格及信息框中使用内联图像則可接受。

参考資料

^ 参见WikiProject:鐵道/移除著色文字模板。

以上。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 23:40 (UTC)[回复]

格式手冊僅適用於條目。關於模板的格式指引應該置於維基百科:分類、列表與導航模板。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年3月27日 (六) 09:20 (UTC)[回复]
理論上可以在WP:分類、列表與導航模板直接套用Wikipedia:格式手冊/文字格式#颜色及内联图像的內容處理（會動用到onlyinclude參數，效果和模版編輯員方針有關行使權力的條文的效果一致），所以這反而不成問題。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 10:23 (UTC)[回复]

@Ericliu1912。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 10:26 (UTC)[回复]
順便把footnote的連結改為WikiProject:鐵道/移除著色文字模板吧。--LuciferianThomas．留言 2021年3月28日 (日) 06:25 (UTC)[回复]

似乎应该是不在条目里用带特殊颜色的模板，而不是规定模板不得带颜色。所以建议“条目正文、表格及各类模板”→“条目正文、表格及条目中使用的各类模板”。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 08:04 (UTC)[回复]

@DrizzleD：然而這裏最原始的提議就是禁止所有模板著色（如果我沒理解錯的話），@1233。SAN MO SA _······ 2021年3月28日 (日) 23:48 (UTC)[回复]

@DrizzleD、Sanmosa：我的概念是應當建立相關Accessibility的指引（例如對規範模板中文字和背景色的對比度）。而又當此等指引未達成共識前，則不應對模板著色。--1233 （T / C） 2021年3月29日 (一) 02:39 (UTC)[回复]

禁止所有模板着色恐怕不现实。且不提{{支持}}这种模板或者就在本句话中使用的{{tq}}，单是为数众多的多彩用户框就不可能处理过来啊。--DrizzleD _{(按此给我留言)} 2021年3月29日 (一) 14:48 (UTC)[回复]

如果我沒理解錯誤的話，是不是Infobox系列模板都不能自訂文字和背景的顏色？空氣小貓（留言） 2021年3月29日 (一) 04:28 (UTC)[回复]

是的（如果我沒理解錯1233的意思的話）。SAN MO SA _······ 2021年3月29日 (一) 05:31 (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)[回复]

@Xiplus：像这三个案例{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}呢，有本事你对Geological_range和古近纪图形时间线的英维版禁止着色啊。反对一刀切致使中维倒退的方针。你少代表正常人对地质年代发表看法，也只是对你来说難以閱讀而已。U:Lab06 N 参与微软专题 2021年4月3日 (六) 12:46 (UTC)[回复]

(－)強烈反对：对地质和生物学相关等特殊模板有严重影响！1.减轻服务器负担这个理由就经不起推敲，难道现在的服务器机能还不如以前的服务器？2.另外照顾色盲色弱群体这个理由已经有人反驳了。U:Lab06 N 参与微软专题 2021年3月30日 (二) 13:57 (UTC)[回复]

那完全不是合理的反駁理由。“因為在色盲色弱看來，無論普通模板還是上色模板基本都是一片灰，並無本質上的區別”是錯的，普通模板的話全色盲至少還能分得到淺色和深色（白色和黑色），上色模板全色盲就完全分不到了。全色盲還是能分辨白色和黑色的，他們只是cone cell不能function而已，rod cell還是能function的。SAN MO SA _Σουέζ 2021年3月31日 (三) 07:53 (UTC)[回复]

既然已經了解提案禁止對Infobox等模板上色，那麼我(－)反对此提案，畢竟有些Infobox模板的顏色對辨別條目類型有很大的幫助，不能因為視覺障礙人士而選擇單一的格式，不過如果是限制背景顏色和文字顏色之間的對比度，這我能夠接受。空氣小貓（留言） 2021年4月1日 (四) 14:20 (UTC)[回复]

仔细想了想，倾向不赞同：

（主要）现行方针能够确保色盲（弱）人士能够获取充分信息，根据现行方针要旨，只需避免“单独地使用背景颜色来表达某一含义”，同时避免“饱和度过高，或与文字对比度不足”，上述举措——
- 确保了色盲（弱）人士能够不依赖颜色获取足够信息，确保所有人阅读的文字是清晰的；
- 在此基础上，不对辅助性背景填色进行“一刀切”，能保障更多色觉正常的人士能借背景色获得获取信息上的便利。
（次要）变更宜乎审慎行事，仅高速公路一类就有逾千条条目和大量模板受到影响，即便上述修改要实施，修正案也未能列出批量变动的页面范围和变动的具体方案。

以上。--Kirk # 2021年4月1日 (四) 14:33 (UTC)[回复]

個人認為對現行模板應當是採取沒壞別修的態度：應當先行禁止新（類型）的模板著色，再討論如何界定為“可行”且為輔助性的背景著色，再解決“應當在何時著色”和“怎樣才是可行的著色”的兩個問題--1233 （T / C） 2021年4月3日 (六) 02:41 (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}}、和{{古近纪图形时间线}}請問有哪個一定需要顏色？或者說這些顏色必須一定要有的理由為何？（當然也可以直接開民調調查有顏色大家會不會比較ＯＫ）。如果這些顏色有一定的存在理由，那就針對這點做改善（例如常用習慣等）。 --Loving You Is A Losing Game 2021年4月5日 (一) 13:11 (UTC)[回复]

意見頗為分歧，我建議就此進行投票，不知各位意下如何。SAN MO SA _Σουέζ 2021年4月10日 (六) 06:39 (UTC)[回复]

這不是投票就能解決的問題，一來是不能只因為視覺障礙人士而選擇單一的樣式，再者是影響範圍過大，投票並不能體現所有使用者的意見（匿名使用者不能投票，請留意維基百科並非專給註冊使用者閱讀）。如果您要發起民調，我沒意見，但是我反對發起投票。空氣小貓（留言） 2021年4月10日 (六) 07:05 (UTC)[回复]

然而現時的狀況確實對視障人士構成嚴重的歧視，我認為所有人現在最基本要知道的就是現時模板的着色情形已經嚴重影響到視障人士的閱讀體驗。投票的選項亦非只有兩種（至少我初步的計劃如是）。在陷入複雜討論的泥潭時，投票顯然是一種快速收集意見以凝聚共識的方法，不能單純因為「影響範圍過大」和「不能體現所有使用者的意見」而反對發起投票和變相剝削視障人士的合理閱讀體驗。SAN MO SA _Σουέζ 2021年4月11日 (日) 14:26 (UTC)[回复]

@Sanmosa：「影響範圍過大」和「不能體現所有使用者的意見」已經不是您所指的單純問題了。您發起民調來蒐集意見我沒意見，但是要將投票結果作為共識執行，我不能接受。當然您要發起與否是您的自由，如果社群能夠接受結果，那我也沒話說，只是還請留意，我不能接受投票不代表我反對投票，也不代表我變相剝奪視覺障礙人士的合理閱讀體驗，這只是表達我的個人意見，而我的意見是對於此種議題，應該有比投票更能體現共識的方式。空氣小貓（留言） 2021年4月12日 (一) 02:31 (UTC)[回复]

發起投票的最主要目的是在討論各方意見很大程度上分歧時確立討論的大方向，如果連大方向都不能確立，我難以相信討論能有效持續。SAN MO SA _Σουέζ 2021年4月14日 (三) 13:19 (UTC)[回复]

@Sanmosa：確立討論的方向，請使用民調而非投票。空氣小貓（留言） 2021年4月14日 (三) 18:01 (UTC)[回复]

(－)反对Template:元素週期表會無法呈現，更不用說縮圖型導航的Template:NavPeriodicTable，此舉同時也導致了之前色弱友善元素週期表顏色配置Template talk:Isotope nav#同位素模板顏色更換全部白討論了，浪費了社群資源。考量到需要區分元素本身特性，以下主題有許多層級需要區分
1. 元素週期表（Template:元素週期表、Template:NavPeriodicTable）
  - 鹼金屬、鹼土金屬、過渡金屬、貧金屬、非金屬、鹵素、稀有氣體.... 等至少7種等級
2. 元素穩定性表（Template talk:Isotope nav）
  - 大量穩定同位素、僅一種穩定同位素、僅有觀測上穩定同位素、最穩定同位素半衰期萬年、半衰期千年、半衰期1年或以下、半衰期以日計、半衰期以時計、半衰期以秒計、目前未發現同位素（如Uue）等至少10種等級
3. 元素分區（Template:元素週期表_(正文)#範例）
  - s區元素、p區元素、d區元素、f區元素、g區元素等至少5種等級
要區分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)[回复]

變通提案

以下是小弟的變通提案：

現行條文

颜色及内联图像

条目正文、表格及各類模板（包括信息框）中禁止手动或使用（其他）模板将文字及背景顏色染成非預設颜色。此舉乃是为减轻服务器负担並方便后来编辑者的维护，亦是为方便色盲、色弱或使用黑白版本的读者阅读文字。^[1]

只有在背景顏色可幫助闡釋條目內容，且沒有其他更佳的表達方式時，才可對表格或其他的內文元素加入背景顏色。為了照顧視障或色覺障礙讀者的需要，請避免單獨地使用背景顏色來表達某一含義，而應適當地同時以文字方式表述。為了保障條目的可讀性，請避免使用飽和度過高，或與文字對比度不足的顏色作為表格的背景色。禁止使用CSS代碼對表格背景加入花俏的樣式（如漸層色等）。

同理，条目正文中亦禁止使用内联图像（例如在文字中出現這樣的图像），但在表格及信息框中使用内联图像則可接受。

参考資料

^ 参见WikiProject:鐵道/移除著色文字模板。

提議條文

颜色及内联图像

条目正文、表格及各類模板（包括信息框）中，使用原始碼或其他模板将文字或背景顏色染成非預設颜色，應以幫助闡釋條目內容為第一目的。同時，編者也需要考慮色盲、色弱或使用黑白版本的读者的實際需求。^[1]

除非編者有正當理由，並且能在討論頁自證有理，否則：

同一表格、導航模板或信息框模板只能使用一種邊界色、一種標題欄背景色、一種標題欄文字色，且總共不能超過三種顏色；
請避免單獨地使用背景顏色來表達某一含義，而應適當地同時以文字方式表述；
邊界色、標題背景色、標題文字色之間應該有可視的對比度；
內容背景色和內容文字色之間也應該有可視的對比度；
表格/模板邊界色和內容背景色兩者的飽和度不能太高；
禁止手動將表格或模板的內容文字染成其他顏色。
禁止使用CSS代碼對表格/模板的任何部份加入花俏的樣式（如漸層色等）。

為避免編輯爭議，建議編者在編輯的同時，即在編輯摘要或討論頁中說明上色的理由。

同理，禁止在正文中使用内联图像（例如在文字中出現這樣的图像）、什錦字型或繪文字，但符合以下條件圖像則不在此限：

與正文內容密切相關，不使用就無法（或很難）準確闡釋條目內容；
編者有理由相信電腦無法正常解碼和顯示；
（非強制）有對應Unicode代碼的天然語言字符或專業符號，或者符合知名度要求的人造語言的字符，或者以 $L a T e X$ 製作的科學表述。

此外，在表格及信息框中也可以使用内联图像。

参考資料

^ 参见WikiProject:鐵道/移除著色文字模板。

「一種顏色」的定義為一個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)[回复]

- 拿這個：[7]--1233 （T / C） 2021年4月16日 (五) 08:32 (UTC)[回复]
(－)反对只能使用三種顏色。Template:元素週期表會無法呈現，更不用說縮圖型導航的Template:NavPeriodicTable，此舉同時也導致了之前色弱友善元素週期表顏色配置Template talk:Isotope nav#同位素模板顏色更換全部白討論了，浪費了社群資源。考量到需要區分元素本身特性，以下主題有許多層級需要區分
1. 元素週期表（Template:元素週期表、Template:NavPeriodicTable）
  - 鹼金屬、鹼土金屬、過渡金屬、貧金屬、非金屬、鹵素、稀有氣體.... 等至少7種等級
2. 元素穩定性表（Template talk:Isotope nav）
  - 大量穩定同位素、僅一種穩定同位素、僅有觀測上穩定同位素、最穩定同位素半衰期萬年、半衰期千年、半衰期1年或以下、半衰期以日計、半衰期以時計、半衰期以秒計、目前未發現同位素（如Uue）等至少10種等級
3. 元素分區（Template:元素週期表_(正文)#範例）
  - s區元素、p區元素、d區元素、f區元素、g區元素等至少5種等級
要區分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)[回复]
@A2569875：請閣下留意：
例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)[回复]

(▲)同上。空氣小貓（留言） 2021年4月15日 (四) 11:27 (UTC)[回复]

魔方问题可以像英语维基百科那样用右侧图像，或者像论文那样<gallery />加“如图1”。一图胜千言，但没看出图像非要内联的理由。而且

、

这三个内连例子真心一点都不大方，图片小小、看着眼晕；图片优势没发挥出来不说，还搞到正文稀稀拉拉的。至于Unicode字符列表这种，特殊字符独占单元格的环境，我认为不算内连。--洛普利宁 2021年4月15日 (四) 17:50 (UTC)[回复]

魔術方塊可能不是個很好的例子，那麼我換個例子基礎摺法、索馬立方（en:Soma_cube），這也難以純粹文字描述。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月15日 (四) 21:40 (UTC)[回复]

同意Lopullinen的看法。不一定要用內聯圖像，可以用右側圖像或者圖片庫。例如《索馬立方》可以改用如下的圖片庫：

《索馬立方》圖片庫

第一片，或稱為V。
第二片，或稱為L：三個立方體排成一列，左下方加一個立方體。
第三片，或稱為T：三個立方體排成一列，中間下方加一個立方體。
第四片，或稱為Z：二個立方體排成一列，上面是另外二個立方體，往右排一格。

第五片，或稱為A：V型的三立方體平放，另一個立方體放在順時針的第一個立方體上方，有立體的不對稱性。
第六片，或稱為B：V型的三立方體平放，另一個立方體放在逆時針的第一個立方體上方，有立體不對稱性。
第七片，或稱為P：V型的三立方體平放，另一個立方體放在轉折的立方體上方的第一個，有立體對稱性。

這樣就既不需要使用內聯圖像，也不需要單純依賴文字描述。📕📙📒📗📘📚📖 2021年4月15日 (四) 22:14 (UTC)[回复]

仍然堅持會有需要把文字和圖片放在一起的情況，摺紙的你們還沒回應，我將會繼續尋找，補充一個找了一整晚的
- en:PlayStation (console)#Marketing success：「The console was marketed with advertising slogans stylised as "LIVE IN YUR WRLD. PLY 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），用作解釋聲隨韻母（ㄢ、ㄣ、ㄤ、ㄥ）時使用，的字形是ㄋ多加一筆直豎，ㄤ解作ㄚ+ㆭ、ㄥ解成ㄜ+ㆭ、ㄢ為ㄚ+、ㄣ為ㄜ+；同理，複韻母ㄞ解為ㄚ+ㄧ、ㄠ為ㄚ+ㄨ。ㆭ、ㆬ、絕少單獨使用，「嗯」常唸作「˙ㄣ」，也有人唸成「˙」」

(將會陸續補充)

以上-- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 05:23 (UTC)[回复]

(～)補充另外，關於「

」的描述，我認為應該要這樣「方塊下兩層已完成，且頂面顏色在頂面上呈

形狀時....」不然圖像還要引用旁邊另外圖像，真的很詭異。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 05:40 (UTC)[回复]

CFOP#下兩層（F2L）可以改成如下形式：

「設法在不破壞其他已完成部分，將一柱轉成以下兩種形式之一（圖1.1和圖1.2）：」

圖1.1	圖1.2

這樣一來，魔方的圖案想再放大些都不怕影響排版。
摺紙的案例和索馬立方的案例一樣，可以製作表格或圖片庫，不需使用內聯圖像。
天文學符號完全可以在表格或者Infobox裏面用，不需用作內聯圖像。
中華民國國語那個注音符號，以及那個阿拉伯樂譜符號，都已經符合「與正文內容密切相關，不使用就無法準確闡釋條目內容」的例外條件。
至於PlayStation和濱崎步的案例簡直就是邊緣得不能再邊緣了。PlayStation的那句營銷口號，完全可以上傳一張自製圖片來表示，反正像這種簡單的幾何符號，是怎麼都達不到原創性門檻的。濱崎步的案例已經涉嫌過量使用非自由圖像，違反《WP:NFCC#3》了。

另：@Lopullinen、1233：小弟新增了無正當理由禁止使用什錦字型或繪文字的條文，請回應。📕📙📒📗📘📚📖 2021年4月16日 (五) 06:19 (UTC)[回复]

內文其實禁止更改字體的，不過無意見。--1233 （T / C） 2021年4月16日 (五) 08:11 (UTC)[回复]

(：)回應我認為索馬立方、摺紙與正文密切相關。天文符號其他例子例如電路符號、化學特殊符號、化學結構式（有苯環的）生物學符號，我不建議在旁邊放成表格，一堆一個小符號整理成表格非常詭異。以及「
：頂面顏色在頂面上呈形狀」的亦與正文密切相關。同時，整個連純文字也包成圖片放旁邊表格將會有「無法複製其中文字」的缺點。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 06:27 (UTC)[回复]

小整理一下，以便針對點討論
- 已解決的問題
  - 自身有獨特排版，且為學術界慣例，又需要顏色表達之表格
    - 元素週期表的背景色。（無法用排版取代，根據討論任意變更元素週期表的排版將構成WP:原創研究）
  - 無法使用現有文字代替的符號（打不出來的字，或者非自然語言表達範疇之記號）
    - 未收錄漢字（如{{缺字}}）
    - 數學符號（如{{CDD}}）
    - 樂譜記號
    - 特殊的語言
- 未解決問題
  - 可以用排版代替顏色的表
    - 地質年代表的背景色。
    - 生物保育狀態的背景色。
  - 可以使用現有文字代替的符號
    - 天文符號
    - 化學結構式
  - 具表意功能圖示使用時機
    - 如摺紙圖示
    - 文字不易描述的瑣碎形狀圖示(一句話出現多種時，使用表格反而雜亂)
    - Emoji、繪文字
    - 什錦符號
  - 特殊標語口號
    - 「LIVE IN YUR WRLD. PLY IN URS」（整個做成圖片將會導致文字複製困難）
    - $L a T e X$
以上-- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 07:06 (UTC)[回复]

在我看來明文限制使用顏色或內文圖片會造成很多麻煩，更不應該直接限制着色，應當按照情況逐例處理；例如在有用戶提出更好減少使用顏色的情況下，若內容不造成明顯閱讀困難就應儘量以顏色較少的方式處理（即指排版妥當；不應以「比較那個比較方便閱讀」為準則，只要整體不造成閱讀困難即可）。列表條目中適當使用顏色協助用戶進行分類，限制用色比限制着色更實際。--LuciferianThomas．留言 2021年4月16日 (五) 09:41 (UTC)[回复]

「地質年代表的背景色」和「生物保育狀態的背景色」我在上面已經說過符合例外條件，因此不屬於「未解決問題」。嚴格來說，俄羅斯方塊的圖像也屬於「與正文內容密切相關，不使用就無法準確闡釋條目內容」，只是編者有責任證明非使用內聯圖像不可。
我加入了或者以 $L a T e X$ 製作的科學表述，以包括數學公式和化學方程式等。
我粗略閱讀了《烴》、《苯》等化學條目，裏面的圖像都不算「內聯圖像」。「內聯圖像」是指插入段落之內，文字之間的圖像。但這些條目當中的圖像都是用在段落之間，而非段落之內，因此不符合「內聯圖像」的定義。
天文符號可以在表格或Infobox裏使用，不需使用內聯圖像。
「LIVE IN YUR WRLD. PLY IN URS」這種標語是不是非加入不可？「導致文字複製困難」似乎暗示閣下打算複製粘貼到其他條目，但除了PS條目本身以外，還有哪些條目非有這條標語不可？
@LuciferianThomas：限制著色是為了防止出現像某個IP對《追夢 Do Re Mi》瘋狂著色的情況再次出現。而我提出「一種邊界色、一種標題欄背景色、一種標題欄文字色，除非能自證有理」是為了方便執行，盡可能壓制遊戲維基規則的空間。另外，我在上面的提案也有限制用色的條文：「背景色飽和度不能太高」。

歡迎回應。📕📙📒📗📘📚📖 2021年4月16日 (五) 15:29 (UTC)[回复]

關於複製，我指的是會困擾讀者，讀者將無法或難以複製該文字。維基百科不應搞得像那種讓讀者複製不了東西的神秘部落格，且讀者理應要能夠方便地複製「LIVE IN YUR WRLD. PLY IN URS」以便到其他地方利用或查詢其他相關資料，整個包成圖像你是要讀者去研究影像辨識和機器視覺？？；另外「有對應Unicode代碼」en:Coxeter–Dynkin_diagram、{{CDD}}沒有對應unicode 代碼， $L a T e X$ 也不支援，且由於其抽象性，難以用文字說明代替。另外我相信應該還有一些數學公式或符號不被unicode與 $L a T e X$ 支援，但是需要與文字一同描述。—- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 15:39 (UTC)[回复]

總歸一句話，複雜的限制只會更容易被忽略，再加上你遇到例外就加上去、加上去，最後限制越來越多。至少我沒有這麼有耐性看完這些限制，就算看完也好，我也不能確保我不會被混淆。你提議修正條文，就有必要將條文修到完整、易讀的狀態，除非你讓這些條文更加簡潔，否則我(－)反对的立場不會改變。空氣小貓（留言） 2021年4月16日 (五) 16:43 (UTC)[回复]

不限制著色，但漸層應明文禁制；另覺得表格什麼的不是不能上色，但必須整個條目一致就是了。--LuciferianThomas．留言 2021年4月16日 (五) 18:07 (UTC)[回复]

我认为维基百科不应搞得花花绿绿的像粉丝部落格。如果「LIVE IN Y

UR W

RLD. PL

Y IN

URS」包装成图像读者能理解，那就不应该使用内连图像；再说这东西复制出来居然是“LIVE IN YOUR WORLD. PLAY IN OURS”，圈叉三角呢，打哑谜？况且stylized包括大小写、颜色、文字大小等等元素，其主要作用也是视觉冲击，所以本来就更适合用图片表示（再用图注说明，其中四个字母置换成为PlayStation的圈、叉、正方、三角标志）。总之简单一句话：图像可以用，但不要放在正文；如果想放在正文，请想想能不能单独提出来：如果提不出来，再想想所谓的“不用图片不行”整句话是否举例过细，对维基百科这种通用百科并无必要；如果真的很重要，业界也常常这样用，那再讨论要不要内连。科学类条目可以制定自己的格式手册，决定哪些图片可以在兼顾排版的情况下，视同文字在正文中使用。但对于大多数条目，要让编者（特别是新编者）从大方向感觉到，维基百科不鼓励使用内连图像。同时也要鼓励编者锻炼文字表达能力：编者作为爱好者可能以为图片很直观，但非圈内读者很可能根本get不到点。（

这个例子要是不配文字，花花绿绿的我还真不知道想表达最下面两层已完成。）--洛普利宁 2021年4月16日 (五) 18:34 (UTC)[回复]

顏色和附圖塞內文概念上是一樣的，上面列的都是附圖案例，顏色例如：

电子游戏分级制度：「此版适龄提示于2019年由中宣部和网游道德委员会设置。将游戏分为 6+ ， 12+ ， 16+ 和 18+ 四等。」

在我看來，許多狀況，有加附圖或顏色，比起沒加附圖或顏色，「更有助於幫助讀者了解主題」。反而沒有上面說的那麼嚴重。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月17日 (六) 07:51 (UTC)[回复]

@A2569875：您说的这篇条目，正好证明内文颜色不必要乃至多余。您举例的下一段就附了个参考文献；此文献是“8+ (green), 12+ (blue), and 16+ (yellow)”这样用纯文字描述的，而显然编者正确理解了文字（先不讨论绿色用#5CB531是不是原创研究）。由此可见，使用纯文字也能起到等价的效果。另一方面，禁止内连颜色不是禁止使用颜色；正确的方法是这样，用侧边图像大大方方地表示。所以我没看出来，直接给文字上色什么时候成了唯一手段。在我看来，图片放到侧边并配上图注详述、正文做一些大方向上的解释，比起使用不知所以的内联图像或颜色，更有助于读者理解主题。PS：感谢提醒，我把这条目正文中的颜色全部移除了（最上面那个是表格的图示，不属于内连的范畴；下面全都在东施效颦）。--洛普利宁 2021年4月17日 (六) 17:42 (UTC)[回复]

關於顏色，我覺得沒必要限死三種顏色。{{中国历史}}目前的配色可以追溯到Special:Diff/432308，距今近16年，幾無异议。只要色盲色弱人士能看得清，颜色又不会太抢眼就没关系。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月18日 (日) 13:40 (UTC)[回复]
如果不想讓例子增加到這麼多的話，那就是換個方向，讓某些變成不符合（不過看下來，不管是從符合還是不符合，兩邊內容都很多）。我只希望大家在追求顏色自由的同時也能考慮顏色自由亂象，不能因為自己的方便造成別人的困擾。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:01 (UTC)[回复]

提议对WP:DYKC的投票须知进行修改

本主題全部或部分段落文字，已移動至维基百科讨论:新条目推荐/候选。执行人：Jimmy-bot（留言） 2021年4月20日 (二) 08:14 (UTC)。[回复]

调整界面管理员方针之“权限取得”一节

根据先前讨论一和先前讨论二，提议向“资格要求”追加一项“需现任管理员”，以达到逻辑和运作上的自洽。--安忆 ^Talk 2021年4月4日 (日) 06:59 (UTC)[回复]

所以你自己這個案會怎樣處理？-某人 ✉ 2021年4月4日 (日) 08:06 (UTC)[回复]

是指权限不足？方针改了的话，这个问题就迎刃而解了。后来的人没问题就行了，我自己可以暂时在需要的时候拜托其他是管理员的人。--安忆 ^Talk 2021年4月4日 (日) 08:22 (UTC)[回复]

讓您成為唯一一位例外並不太好; 可是要求您辭職又更過分了。--Temp3600（留言） 2021年4月4日 (日) 18:40 (UTC)[回复]

我想这不是一个特别难解决的矛盾，不看这个，就方针本身的变动而言，请问有什么意见吗？--安忆 ^Talk 2021年4月5日 (一) 02:30 (UTC)[回复]

由於我一向支持將技術組與行政組盡量分拆，我反對您的建議。--Temp3600（留言） 2021年4月10日 (六) 12:36 (UTC)[回复]

我认为，界面管理员确实有跛脚的问题，但尚没有到必须要所有界管都一定要管理员权限的境地。有最好，但没有的话也不是没法开展工作。--痛心疾首 2021年4月5日 (一) 04:14 (UTC)[回复]

目前介面管理員沒有delete、editcontentmodel、move、move-subpages和suppressredirect等權限，就您的個案來看，這個提案是很實際的。不過對於臨時申請介面管理員的使用者（外站也有可能），這些權限可能不是那麼重要。如果提案通過，介面管理員將永遠不能申請臨時權限。--空氣小貓（留言） 2021年4月5日 (一) 07:15 (UTC)[回复]

可以临时授权管理员，历史上有过先例，所以在迫切需要的时候，应该也可以临时授权界管。--安忆 ^Talk 2021年4月5日 (一) 07:23 (UTC)[回复]

我相信當初從管理員拆分出介面管理員有一定的道理，如果提案通過，那麼拆分還有什麼意義呢？臨時授權管理員又是另一回事了，因為管理員和介面管理員的業務內容不同，雙重授權必須要從許多方面考量，但是只依申請者的需求來單一授權，手續就不會那麼繁瑣，畢竟臨時授權可能是緊急的，如果從太多方面考量，時間必定會被拖延。這是我的個人意見。--空氣小貓（留言） 2021年4月5日 (一) 17:59 (UTC)[回复]

(－)反对提案，不明白「达到逻辑和运作上的自洽」是甚麼意思，根本上介面管理員跟管理員做的事大都有所分別，如果一個人被信任在有權限編輯介面，不代表他/她能解決編輯爭議且能獲得Special:UserGroupRights#sysop中非常多的權限（不止上面列舉的那些）而不濫權。雖然不知道設立這方針時是怎麼想的，但我覺得介管不須管理員權限才能申請也是因為希望兩者是分工合作。--Sun8908 _{怯就輸一世} 2021年4月5日 (一) 12:27 (UTC)[回复]

不赞同。理由同痛心疾首和空气小猫。我认为只要可信任+有技术就可以当介面管理员。目前还没有到需要先当上管理员来证明可信度的地步。至于权限不足，也不是什么事情都不能做，而且可以由介面管理员提出编辑请求，让管理员协助。--dqwyy (talk) _{我们终将成为枫音乡的过客} 2021年4月6日 (二) 06:58 (UTC)[回复]

我還是覺得直接讓介面管理員擴權就可以。SAN MO SA _Σουέζ 2021年4月7日 (三) 05:36 (UTC)[回复]

@Sanmosa：早在近三月前，我便问过了编辑类权限。但连编辑类权限都要不来，更不要说其他杂七杂八的权限。--安忆 ^Talk 2021年4月8日 (四) 05:08 (UTC)[回复]

我認為這是單純因為你使用個人名義請求的緣故。如果有社群共識的話，我估計可能會有所不同。SAN MO SA _Σουέζ 2021年4月8日 (四) 05:10 (UTC)[回复]

我也是这么认为的，所以才有了之后的几个提案，但现在看起来还是不太可行。--安忆 ^Talk 2021年4月8日 (四) 05:18 (UTC)[回复]

@sanmosa、AnYiLin：我建议，可以授予界面管理员目前没有的editcontentmodel、move、move-subpages和suppressredirect四个和界面调整直接相关且相对不敏感权限。删除权限让人联想到页面的存废，或许太过敏感，可以日后再说。--痛心疾首 2021年4月10日 (六) 07:56 (UTC)[回复]
同意。可以一步一步來。SAN MO SA _Σουέζ 2021年4月10日 (六) 09:32 (UTC)[回复]

( ✓ )同意。根据界面管理员实际，我提出了下面的条文，以一劳永逸地解决上述大部分问题，请各位参考：

現行條文

介面管理員持有下列權限：

editinterface︰修改MediaWiki名字空間頁面。
editsitecss︰修改MediaWiki名字空間下之CSS頁面。
editsitejs︰修改MediaWiki名字空間下之JS頁面。
editsitejson︰修改MediaWiki名字空間下之json頁面。
editusercss︰修改用戶名字空間下之CSS頁面。
edituserjs︰修改用戶名字空間下之JS頁面。
edituserjson︰修改用戶名字空間下之json頁面。
oathauth-enable︰可以開啟雙重認證（2FA）。

提議條文

介面管理員持有下列權限：

editcontentmodel：编辑页面的内容模型。
editinterface︰修改MediaWiki名字空間頁面。
editsitecss︰修改MediaWiki名字空間下之CSS頁面。
editsitejs︰修改MediaWiki名字空間下之JS頁面。
editsitejson︰修改MediaWiki名字空間下之json頁面。
editusercss︰修改用戶名字空間下之CSS頁面。
edituserjs︰修改用戶名字空間下之JS頁面。
edituserjson︰修改用戶名字空間下之json頁面。
move-subpages：可以在移動主頁面時一併移動子頁面（上限100個）。
oathauth-enable︰可以開啟雙重認證（2FA）。
suppressredirect：可以移動時並不保留重定向。
templateeditor：编辑保护级别为“仅允许模板编辑员和管理员”的页面。

请各位审阅。--悔晚齋（臆語） 2021年4月10日 (六) 14:57 (UTC)[回复]

(－)反对新增不是只有管理員擁有的權限，請留意介面管理員是能編輯全站CSS或JavaScript頁面的使用者群組，與編輯模板無關，更何況這兩個使用者群組的授權標準不同，如有需要另行申請即可。空氣小貓（留言） 2021年4月10日 (六) 15:11 (UTC)[回复]

@悔晚斋： (▲)同上 --痛心疾首 2021年4月12日 (一) 10:08 (UTC)[回复]

(？)疑問可不可以设立新的CSD供界面管理员快速删除需要删除的页面？还可以设立类似“快速编辑请求”，界管提出后，除非明显破坏或违反方针，管理员不得驳回？ ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月11日 (日) 03:41 (UTC)[回复]
刪除介面頁多為不緊急，沒必要設立新的快速刪除機制，這樣管理員在執行刪除時，手續反而會太繁瑣。如有需要快速刪除，在該介面頁的討論頁註明和掛上模板即可，也可直接提交到存廢討論。--空氣小貓（留言） 2021年4月12日 (一) 13:46 (UTC)[回复]
個人認為將技術審閱與行政管理分柝操作，增加一道複檢，不是壞事。-Temp3600（留言） 2021年4月18日 (日) 05:22 (UTC)[回复]

模板修訂建議

本主題或以下段落文字，在討論結束後應存檔至Template talk:Refimprove。

已通过：

已修改。--痛心疾首 2021年4月19日 (一) 03:45 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

最近參照一下英維，留意到{{refimprove}}模板下有一行可讓用戶透過搜尋平台（Google、JSTOR）搜索該條目相關而可能有用的參考資料（即類似於{{notability}}的那段「來源搜索」）。小弟認為既然段首模板用意旨在讓其他用戶為條目加入更多參考資料「以彰顯其關注度」，現提議修訂如下：

現有模板

（未有相關內容）

修訂建議

在date參數前加入以下字句：
來源搜索：「條目名稱」—網頁 · 新聞 · 書籍 · 學術 · 圖像 · JSTOR
（連結已刪去，與{{notability}}做法類似）

歡迎討論。—小文人（見山 ‧ 客棧） 2021年4月4日 (日) 13:47 (UTC)[回复]

从最终得益的角度，加上也没什么不好。而如果要加，{{blpunsourced}}{{blpsources}}{{unref}}{{onesource}}{{primarysources}}{{third-party}}{{or1}}这些都应该加上，且前三个优先级更高。另外这几个模板也经常同时使用，之间的冗余问题，以及如何在{{issues}}中展示都需要解决。->>Vocal&Guitar->>_留言 2021年4月5日 (一) 02:09 (UTC)[回复]

先從不太常用的模版開始試用也是有的。--Temp3600（留言） 2021年4月10日 (六) 18:59 (UTC)[回复]

(＋)傾向支持：没什么问题。--安忆 ^Talk 2021年4月5日 (一) 02:25 (UTC)[回复]

有個疑惑。像遊戲條目經常有這种情况：作品在中文圈人氣不高~~甚至約等於零~~，用條目名（中文）搜没什麽結果，用原文（西文）搜索結果一大堆。如果創建者搞了個中文條目名，而巡查員又是搜中文没结果挂{{Notability}}的，那標籤上搜尋工具基本就等於廢的。推而廣之，不少非中文圈的事物都有這類問題。所以，能不能在模板文檔和TW里推廣一下，允許挂板者手工指定搜尋字串，或者輸入en自動套用（或將來他人連結WD後自動套用）Wikidata上的英文名等。~~此處不得不羡慕英文世界語言+出版業發達，哪怕日本獨佔作品都有不少可用文獻。~~--洛普利宁 2021年4月10日 (六) 19:19 (UTC)[回复]

已经先在相关模板处提出编辑请求。--痛心疾首 2021年4月18日 (日) 10:03 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

设计一个制度解决部分速删模板挂不上去的页面的删除问题

参见Wikipedia:互助客栈/求助/存档/2021年4月#请帮忙删除 User:Tranve/工坊/workshop.json，像 JSON 和 Module: 名字空间的页面，速删模板挂不上去。希望可以在方针制度层面解决这个问题。--Tranve (✉) 2021年4月5日 (一) 13:07 (UTC)[回复]

cc@蟲蟲飛、Xiplus、Sunny00217 --Tranve (✉) 2021年4月5日 (一) 13:09 (UTC)[回复]

說到這個，才想去WT:TW提案讓.json的速刪能不能轉到AFD之類的呢xxdd-- Sunny00217 2021年4月5日 (一) 13:43 (UTC)[回复]

注：可参考英文维基方针。--Tranve (✉) 2021年4月10日 (六) 06:30 (UTC)[回复]

@Tranve：英文維基的en:Module:Module_wikitext可以讓WP:TW支援（見en:MediaWiki:Gadget-twinklespeedy.js），會能很方便地像掛模板那樣，手機也能操作；但是呢！！(※)注意英文維基的en:Module:Module_wikitext在中文維基無效！Module:Module_wikitext，見測試Special:PermaLink/65279867。如果需要引入，可能需要請介面管理員修改介面。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月20日 (二) 03:22 (UTC)[回复]

同上意见。-门可罗雀的霧島診所_{三天打鱼两天晒网}^{神社的羽毛飘啊飘} 2021年4月18日 (日) 03:54 (UTC)[回复]

(※)注意:如果TW可以像封禁選項讓管理員點選「提刪請求參見討論頁」還好，否則要管理員輸入詳細的提刪位置，手機不好操作。而且被刪除的頁面如果沒有任何提刪模板，而且公開的日誌中又未能清楚查看誰在哪裏提出刪除，對操作管理員來說都容易有爭議；刪除的操作不能馬虎，操作不清楚，時隔多天後，如果連操作管理員也忘了用戶在哪裏提出請求，而頁面又沒有提刪模板，對管理員會很不利，可以成為有心人質疑管理員操作的藉口，因此我比較同意Sunny00217建議，或者直接找管理員，或者在用戶自己的討論頁ping管理員請求刪除，管理員刪除時加個編輯差異，這樣才好保障管理員以免陷入不必要的爭議，而且安憶現在已經造了一個編輯差異複製黏貼的小工具，很好用。--蟲蟲飛♡♡→♡℃※留言 2021年4月18日 (日) 04:19 (UTC)[回复]

@蟲蟲飛：我不同意阁下的观点。首先，如果一个快速删除请求仅仅因为删除的页面是一个特殊页面而需要单独联络管理员，这已经违背了快速删除请求“快速”的特质；其次，如果需要到 WP:AFD 去汇报的话，相当于破坏了 AFD 的功能（AFD 原本应用于存废讨论），会导致站务管理混乱。我大致上同意仿照英文维基的方针。目前的技术问题先看看能不能联系管理员解决，如果不能解决的话，再尝试您的方案吧。请问如何联系管理员？--Tranve (✉) 2021年4月20日 (二) 10:41 (UTC)[回复]

(？)疑問:1.全保護的頁面通常是很重要的，有頻繁刪除的需要嗎？而且過去五年，我只看到您一個人有這方面的提刪需求和困難。2.走去找管理員討論頁討頁請求很困難嗎？如果覺得有困難，您在自己討論頁ping在線管理員，請求刪除，有甚麼困難？--蟲蟲飛♡♡→♡℃※留言 2021年4月20日 (二) 13:29 (UTC)[回复]

@Tranve：en:Module:Module_wikitext關於在中文維基無效Module:Module_wikitext的問題，導致en:MediaWiki:Gadget-twinklespeedy.js中文維基用不了的問題，請找WP:介面管理員。例如User:安忆是介面管理員。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月20日 (二) 11:17 (UTC)[回复]

@A2569875：没来得及细看（大致看了下关键字）。请问具体需要我的什么帮助？如果是Module的话需要模板编辑员才行。--安忆 ^Talk 2021年4月20日 (二) 14:28 (UTC)[回复]

@安忆：看了一下追查英文維基相關功能的添加紀錄（關於Module:Module_wikitext），為en:Special:Diff/977236565，這個模板编辑员也無法，只能管理員；介面管理員能做的應該是中文維基的en:Special:Diff/977236565完成後，參照英文維基en:MediaWiki:Scribunto-doc-page-does-not-exist修改介面。 @Tranve：涉及如此複雜修該應需要公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月20日 (二) 14:36 (UTC)[回复]

限縮{{电视节目的变迁}}模板使用範圍

電視節目我印象中的認知是綜藝、名嘴那種節目，電視劇個人感覺像是跟電視動畫一樣的存在，只是娛樂產物，雖然我是想直接刪掉這麼雞肋的模板，但似乎無共識，那提議限縮使用範圍如何？以上僅個人拙見。--1.200.74.250（留言） 2021年4月9日 (五) 03:28 (UTC)[回复]

我認爲可以廢掉。前後檔節目一般没有直接關係。如果有關係，也應該是用條目正文說明經緯，比如“前檔的古裝劇《XXX》意外大熱，故電視臺决定延續古裝題材”。類比WP:DATELINK可以說，Template:電視節目的變遷羅列接檔條目時，其聯繫不能祇是“節目在同一時段且前後相連”這种程度。畢竟模板占那麽大位置（三行比一些導航模板都高，還不能折叠），正文又什麽東西都說不出來，那基本就是WP:UNDUE。至於重要電視臺的黄金檔電視劇，這本身就是個話題；可考慮作爲整體直接建導航模板，將一系列條目按時序列出。總而言之：和主題的其他製作、放映資訊相比，前後檔節目這一句話說清的事實是有多緊要，值得獨佔三行空間介紹？--洛普利宁 2021年4月10日 (六) 18:33 (UTC)[回复]

真的没啥用，前后节目本无关联，如有在正文能说明白了。太占位置了，同意直接废除。🌟🌟_Talk 2021年4月11日 (日) 01:31 (UTC)[回复]

中立，感觉类似“参见”（相关条目），不适合写入正文，不是都有明显的意义和参考资料，类似时间线资料。更看不惯收视率章节的统计表。需要电视专题的参与者决定，不然会反弹。--YF dyh000（留言） 2021年4月13日 (二) 12:10 (UTC)[回复]

人家電影票房好歹有來源，电视节目的变迁和收视率一堆沒來源還刪除不了真的是恐怖情人，想甩甩不掉。 --Loving You Is A Losing Game 2021年4月13日 (二) 17:00 (UTC)[回复]

(▲)同上(＋)支持：尤其如果後來隔幾年又有哪個電視台購買版權又添加，簡直沒完沒了，像三生三世十里桃花_(电视剧)#電視節目的變遷就很誇張。～立ち直り中^ಇ 2021年4月20日 (二) 08:33 (UTC)[回复]

通用行為準則/2021諮詢

本主題全部或部分段落文字，已移動至WP:VPN。执行人：--Yining Chen（留言|签名） 2021年4月16日 (五) 14:31 (UTC)。[回复]

设立过滤器禁止将维基百科用作来源

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:可供查證。

在修订爱丁堡公爵菲利普亲王的时候，我发现有用户将维基百科条目用作来源，由于维基百科早有方针禁止在条目中使用维基百科作为来源，这类编辑显然违反有关方针。然而，维基百科上引用维基百科的条目实在不少，例如以中文维基为例，证明这些方针一直以来未能发挥有效作用。故在此建议设立过滤器，禁止在引用中使用维基百科的内容（URL或者内部链接）。--百战天虫（留言） 2021年4月12日 (一) 13:03 (UTC)[回复]

請提供至少5筆編輯差異供測試。--Xiplus#Talk 2021年4月12日 (一) 13:11 (UTC)[回复]

巡查員申請條件嗎www-- Sunny00217 2021年4月12日 (一) 13:21 (UTC)[回复]

不足100条，应当清理。过滤器可以打标签，至多警告，阻止不建议，可能有合理的WP:自我参照和其他值得保留内容，清理这种内容也不会太麻烦。--YF dyh000（留言） 2021年4月12日 (一) 13:18 (UTC)[回复]

@Xiplus：是指这类条目的编辑差异吗？--百战天虫（留言） 2021年4月12日 (一) 13:50 (UTC)[回复]

您認為應該被阻止的「那筆編輯」，盡量在1個月內的編輯。--Xiplus#Talk 2021年4月12日 (一) 13:53 (UTC)[回复]

1个月内的比较难，更久一点倒可以找。--百战天虫（留言） 2021年4月12日 (一) 13:58 (UTC)[回复]

如果情況過少就可能不會考慮建立過濾器，當然可以先建立看看實際觸發量，但不排除在確認過少後停用。--Xiplus#Talk 2021年4月14日 (三) 15:36 (UTC)[回复]

也可以按照上面的意见做个警告加标签，暂不设立过滤器。不过现在有引用的肯定要清理了。--百战天虫（留言） 2021年4月14日 (三) 15:56 (UTC)[回复]

@Xiplus：阁下的意见？--百战天虫（留言） 2021年4月18日 (日) 07:34 (UTC)[回复]

或者將Special:滥用过滤器/39不可信來源中的豁免取消掉。--Xiplus#Talk 2021年4月18日 (日) 07:54 (UTC)[回复]

本人不怎么看，就是个路人，罢了--Raptor (Unknown)

订立编辑松相关规章制度

上次中塞编辑松由于主持人Walter Grassroot的一些行为对社群造成了恶劣的影响。实际上截至目前本地并没有对编辑松的举办、规则的订立相关的方针或指引，为避免再次发生类似于中塞编辑松的恶劣事件，本人提议在本地订立编辑松的相关指引。我认为至少可以作以下要求：

在提出举办编辑松时，需将举办计划提交至互助客栈由社群审阅；
编辑松规则订立时，不得订立任何歧视维基人的规则；
规则订立完成后，同样需要交由互助客栈审阅；
编辑松开始之后，除非规则有重大问题，否则不得修改编辑松规则。

以上。--忒有钱 🌊塩水あります🐳（留言） 2021年4月17日 (六) 18:46 (UTC)[回复]

(＋)支持。完善制度比指責個別人對維基百科更加有益（但這不代表無人需要為之前的紛擾負責）。--Yangwenbo99^{論文} 2021年4月17日 (六) 22:35 (UTC)[回复]

(－)反对，提议者本身就是此次闹剧的编造者，此事本身就是对大陆社群的污名化行动。目前又想伪造社群共识以实现对中国大陆社群的侮辱既定事实。对此我表示坚决反对。门可罗雀的霧島診所_{三天打鱼两天晒网}^{神社的羽毛飘啊飘} 2021年4月18日 (日) 03:53 (UTC)[回复]

我也是中国大陆人，而且现在就生活在中国大陆，大陆人和大陆人之间能有什么坏心思呢？（确信）--忒有钱🌊塩水あります🐳（留言） 2021年4月18日 (日) 04:54 (UTC)[回复]
- 其实我也好奇为什么热衷于打压和破坏大陆社群的老管理员为什么都是大陆人。。。。。--飞贼燕子（留言） 2021年4月19日 (一) 23:22 (UTC)[回复]
  「規管和（要求）遏止不恰當的行為就算是『打壓』和『破壞』」這種歪理是不會被社羣認可的。SAN MO SA _Σουέζ 2021年4月20日 (二) 04:50 (UTC)[回复]
  当年某位把占海特一家领到活动场地进行蹭热度和政治活动的时候可没听说过那条管规和指引让他们这么玩，但这并不妨碍那些管理员把反对和知道真相的用户一个一个封掉以企图掩盖的行为。不过有一点你说的很对，后来的事实证明那几个管理员的歪理确实没有被社群认可。--飞贼燕子（留言） 2021年4月20日 (二) 07:50 (UTC)[回复]
  這是站外的東西，站內無權管，沒必要將這些站外的恩怨帶進站內，反正當事人以外的任何一個人都對此沒有興趣。SAN MO SA _Σουέζ 2021年4月20日 (二) 12:53 (UTC)[回复]

站内无权管当初干嘛心虚的不得了，封人家捂人家嘴还处处针对别人，大家早就都知道他几个是干什么职业的了，掩盖的多了吧那叫歪理。--飞贼燕子（留言） 2021年4月21日 (三) 02:10 (UTC)[回复]

我不知道忒有钱君什么时候成为“此次闹剧的编造者”的。Eric君被Walter君踢出WMC编辑群，忒有钱君在互助客栈请求取消Walter君的WMC编辑群管理员职务。后来该讨论才演变成对Walter君移除编辑松条目的讨论。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月18日 (日) 05:30 (UTC)[回复]
上面那個投反對票的不關注忒有钱的提議是否有道理，上來就訴諸人身。提議有提到「不得订立任何歧视维基人的规则」，所以你是不反對此類歧視性規則咯--Googol19980904（留言） 2021年4月18日 (日) 11:20 (UTC)[回复]

你们组织的所谓社群，党同伐异，异己者唯除之而后快，连制定规章都要反对。--𢿃𠫱（留言） 2021年4月19日 (一) 04:44 (UTC)[回复]

这里明明是在谈防止公报私仇行为的再次出现，不要扯到地域问题上来。--🔨（留言） 2021年4月19日 (一) 10:53 (UTC)[回复]

(▲)同上。--14-5-2@维基抗生素协会 2021年4月18日 (日) 04:09 (UTC)[回复]

上面那個投反對票的本身就是很多爭議的製造者，甚至假定惡意來封鎖使用者，真是八兩笑一斤。空氣小貓（留言） 2021年4月18日 (日) 16:09 (UTC)[回复]

八兩笑一斤？百步笑五十步比較準確吧。--Yangwenbo99^{論文} 2021年4月18日 (日) 16:53 (UTC)[回复]

我是指他自己份量太輕，竟然指責（笑）比自己份量更重的人。空氣小貓（留言） 2021年4月19日 (一) 00:38 (UTC)[回复]

不限于编辑松，任何对外合作的编辑活动建议在开始前将活动规则在公开讨论中报备一次，并且避免产生会对特定或所有编辑不友好的行为。我认为这个提议可以考虑，——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年4月19日 (一) 01:00 (UTC)[回复]

同上。提案本身是沒有問題的。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:35 (UTC)[回复]

(＋)支持，强烈譴責因為一己私欲敗壞社群名聲的行為。--Newbamboo（留言） 2021年4月19日 (一) 04:36 (UTC)[回复]

(＋)支持，同上。----𢿃𠫱（留言） 2021年4月19日 (一) 04:40 (UTC)[回复]

一、你這個編輯松的定義是甚麼？動員令、亞洲月（及其附屬活動）算不算？安可牌條目提升計劃算不算？如果動員令、亞洲月算，我認為兩者都應該獲得豁免（近十年來，曾經有兩三個人意圖擾亂動員令，但最後都折戟沉沙）。二、個別編輯松的主辦者制定規則排斥個別用戶，這應該用NPA、CIV處理。三、可以考慮為編輯松的舉辦流程制定原則、指引和違規處理機制（不要求為綜合文本，可散見於不同頁面），但不贊成舉行甚麼編輯松都要上客棧報備，這樣容易橫生枝節。--春卷柯南－發前人所未知 ( 論功行賞 ) 2021年4月19日 (一) 10:39 (UTC)[回复]

一：动员令只是中维站内活动，当然不算；亚洲月本就是与其他语言联合举办的编辑松的一种形式，需要算在内。二：( ✓ )同意，但最好还是先定下规则（我认为我草拟的规则中第四条非常重要）。三：未必是上客栈，可以用专用页面（比如Wikipedia:编辑松的子页面）。--忒有钱 🌊塩水あります🐳（留言） 2021年4月19日 (一) 21:07 (UTC)[回复]

一、你這個定義標準是站不住腳的，編輯松的本質就是鼓勵別人做編輯，寫條目的活動啊，而動員令和亞洲月都是條目競賽。二、暫時不回覆。三、我的意思是說報備這一步是不必要的。一個通知還不夠嗎？如果通知以後，有一群人認為事情不對勁，也就是在客棧事後審查，一如目前的做法。--春卷柯南－發前人所未知 ( 論功行賞 ) 2021年4月20日 (二) 13:46 (UTC)[回复]

@春卷柯南：（1）認同你的見解，但需要考慮到的是協調各維基百科的亞洲月的相關人士未必清楚本站內負責的主持人的主持方式是否恰當，因此不贊同豁免亞洲月。（3）2月的事件已經證明了事後審查的成效不大。雖然說那三個核心人物之一已經獲得處理，但明明問題就已經存在而且非常明顯了，到現在還是有人敢公然向大家說不存在問題，就已經證明了現在編輯松的舉辦者會走通知程序的漏洞，然後恣意妄為，並且把這當成常態。如果沒有人濫用現行程序，我相信他也不會走出來提這案。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:16 (UTC)[回复]

支持社群采取一切合理措施阻止个别有过公报私仇前科且拒绝认错及改善的编者担任往后一切活动（包括但不限于动员令和编辑松等）的主持人，及阻止活动中一切存在显著问题及争议规则的制定与实施，如果无法阻止编辑松由有公报私仇前科且拒绝认错及改善的编者担任其中一位主持人，或无法阻止存在显著问题及争议规则在编辑松当中的出现，则支持社群采取一切合理措施阻止相应编辑松在本站的宣传。--🔨（留言） 2021年4月19日 (一) 11:44 (UTC)[回复]

(－)反对，好像每次举办社群活动的时候一般会向社群发通告吧，几位的意思是不经过几位批准以后大家都别搞了是吧。不知几位是打算怎么审批呢？是打算投票比人头呢还是在客栈聚众扯皮呢？个人觉得这个提议当个笑话看看完了没必要去较真。--飞贼燕子（留言） 2021年4月19日 (一) 23:06 (UTC)[回复]

社羣討論的共識或大方向一旦不合己意就胡亂聲稱其已失效，這不是只有你一個人正在做的事情，但大家都在看著。SAN MO SA _Σουέζ 2021年4月20日 (二) 04:50 (UTC)[回复]

我也不見得籌辦編輯松的程序開誠布公是壞事（所有社羣成員都能就此發表意見），除非籌辦者意圖利用編輯松進行違反使用條款和方針指引的事項。SAN MO SA _Σουέζ 2021年4月20日 (二) 04:55 (UTC)[回复]

怎么办活动怎么办好像参与和组织者都会写在公告上谁都可以看吧，不觉得谁会举办前就在公告里刻意违反规则指引啥的，再者个人不觉得谁会听一个完全无关闲人去批准同不同意。--飞贼燕子（留言） 2021年4月20日 (二) 07:31 (UTC)[回复]
但舉辦期間這樣做的情況已經出現了。社群作為編輯松的參與者，怎麼可能是「閑人」？不然編輯松是開來做甚麼的？SAN MO SA _Σουέζ 2021年4月20日 (二) 12:53 (UTC)[回复]

「不觉得谁会举办前就在公告里刻意违反规则指引啥的」——上一次活動是在活動中更改規則，違反指引的。--Yangwenbo99^{論文} 2021年4月21日 (三) 03:34 (UTC)[回复]
操作涉及操作问题一次不行下次可以修正，社群活动的参与者不少但是那些喜欢捣蛋的闲人也一样不少。方针规则这东西这次你能用下次别人一样能拿来用，届时就社群活动就谁都别搞不了只能在互助客栈扎堆审查扯皮，我看这个提案就是为那些闲人在社群活动时审查扯皮捣蛋准备的提案。--飞贼燕子（留言） 2021年4月21日 (三) 02:10 (UTC)[回复]

我不介意重複一次上面的話：「社羣討論的共識或大方向一旦不合己意就胡亂聲稱其已失效，這不是只有你一個人正在做的事情，但大家都在看著。」「社群作為編輯松的參與者，怎麼可能是『閑人』？」（還是說，你已經把特定的社群參與者，不當成是社群的一分子，然後要把他們排擠出去？）你的反對理由是完全無效的。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:07 (UTC)[回复]

「届时就社群活动就谁都别搞不了只能在互助客栈扎堆审查扯皮」——所以閣下認為舉行「社羣活動」不需要取得「社羣共識」？「操作涉及操作问题一次不行下次可以修正」——制訂規則就是為了防止之後出現類似問題。我明白閣下希望維基百科都是舉手機器，但是殘酷的現實是，維基百科有一批編者是有獨立思考能力的知識分子，而這當中有一部分人願意為維基百科的益處進行爭論。--Yangwenbo99^{論文} 2021年4月21日 (三) 03:34 (UTC)[回复]

將「青島」、「中國青島」或「山東青島」改成「中華人民共和國山東省青島」是否有必要

近日有不少更改是將城市名改為類似「中華人民共和國山東省青島」的詳細行政區劃名。其中單個使用者一兩日內（初步估計）過百次類似編輯，所以應當訂立規定。舉例如下：

此等做法是否存在必要性？我不相信有中文維基百科使用者會不知道青島現由中華人民共和國管轄，亦不相信會有人無法輕易查得青島屬於山東省。另外，在下對把机器人们带走的存在感给抢回来的行為相當欣賞。

就將「中國」改為「中華人民共和國」一事，可能是相關編者受Wikipedia:格式手册/两岸四地用语#使用「中國」一詞中「在1949年之後的相關條目中，應儘量使用中華人民共和國和中華民國等全稱」的影響。但是Wikipedia:格式手册/两岸四地用语#指定樣式表便違背了Wikipedia:格式手册/两岸四地用语#使用「中國」一詞的建議，要求特定人士使用「中国」而非「中华人民共和国」標註國籍。可見，「在1949年之後的相關條目中，應儘量使用中華人民共和國和中華民國等全稱」之不可實踐性。

就應當以何種形式在文中提及城市，似乎 (a) 以行政區劃全稱和 (b) 直接以城市名提及，兩者未能增減文章可讀性。在二者間進行更改似乎建設性不強。而維基百科似乎缺乏相關規定。

以上--Yangwenbo99^{論文} 2021年4月18日 (日) 00:22 (UTC)[回复]

就「使用『中國』一詞」的權宜修正

現行條文

此外：

……

提議條文

此外：

……

對於不存在主權、治權爭議之地理概念，仍舊可逕作「中國」而無需使用置頂宣言。具體以何種形式書寫，依照先到先得之原則處理。

以上。--Yangwenbo99^{論文} 2021年4月18日 (日) 00:53 (UTC)[回复]

就提及兩岸四地之下級地區作出規定

參考Wikipedia:命名常规#地名，提下列提案。

現行條文

下級行政區劃若非描述法理狀況（de jure），在描述兩岸四地下級行政區劃所屬的國家時，應以事實論述（de facto）為主。

提議條文

下級行政區劃若非描述法理狀況（de jure），在描述兩岸四地下級行政區劃所屬的國家時，應以事實論述（de facto）為主。

在不引起歧義的情況下，在文中提及兩岸四地任何知名城市時，通常應當直接不加前綴地直接使用該城市名（如：「青島」或「青島市」）。在會產生歧義時，應當使用能够区分的最上级行政区划名消歧義。在不違背本規則的前提下，具體以何種形式書寫，依照先到先得之原則處理。

以上。--Yangwenbo99^{論文} 2021年4月18日 (日) 00:53 (UTC)[回复]

(＋)支持@K.Y.K.Z.K.：Newbamboo（留言） 2021年4月18日 (日) 02:51 (UTC)[回复]
(－)反对，此款条例是为特定人群进行的政治分肥行为。地级市和直辖市的使用必须尊重并遵循事实，不能采取偷袭或者删减的方式刻意为之。门可罗雀的霧島診所_{三天打鱼两天晒网}^{神社的羽毛飘啊飘} 2021年4月18日 (日) 04:01 (UTC)[回复]
- 亦不應採取大規模襲擊或機械式附加內容的方式刻意為之。那麼閣下有何避免此等情況發生的建議呢？--Yangwenbo99^{論文} 2021年4月18日 (日) 08:27 (UTC)[回复]
  - @Yangwenbo99：“採取大規模襲擊或機械式附加內容的方式刻意為之”應該是“未經授權而使用bot”或“濫用bot”的情況，應該依照bot的相關方針處理。不過我個人也是覺得説成是“政治分肥”也不至於。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:43 (UTC)[回复]
以陈倩_(游泳运动员)为例，该条目的最初版本即为{{CHN}}[[山东省]][[青岛市]]，但在2016年被User:K.Y.K.Z.K.将其中的[[山东省]]移除。范学伟和任永顺两条目亦是如此。翻查User:K.Y.K.Z.K.的编辑历史，其在过去多年内，长期刻意将青岛相关条目中的山东一词抹去（如在青岛地铁的讨论页中移除山东专题），可能构成WP:POINT。Itcfangye（留言） 2021年4月18日 (日) 04:59 (UTC)[回复]
- 希望這個規定就是為了避免在「青島」、「山東青島」、「中國青島」、「中國山東青島」之間反覆變換。如果只是個別編輯，則大可不必在意，但這是單個使用者一兩日內初步估計過百次類似編輯，所以應當訂立規定。更簡單的替代方案是完全依照先到先得的規則，不知閣下意下如何。--Yangwenbo99^{論文} 2021年4月18日 (日) 08:22 (UTC)[回复]
- 我觉得应该对K.Y.K.Z.K.的相应编辑进行编辑禁制，禁止相关用户“反覆變換”相关内容来违反WP:POINT，而没有必要去明确说哪些可以。哪怕放在某些格式手册里，这种“是否需要对知名城市冠以国家/地区名称”也是比较有争议的。--痛心疾首 2021年4月18日 (日) 09:38 (UTC)[回复]
  - 請注意，有許多出現類似情況的條目中K.Y.K.Z.K.並未參與編輯。--Yangwenbo99^{論文} 2021年4月18日 (日) 09:59 (UTC)[回复]
    - Itcfangye、痛心疾首的观点在理。根据K.Y.K.Z.K.的用户页及历史版本，可以看出，他主张青岛市从山东省分离出去。--DavidHuai1999※Talk 2021年4月18日 (日) 10:12 (UTC)[回复]
    - 了解了，但请恕个人很难赞同这种高度争议化的提案。这里需要说明的是，本人反对未阐释观点扰乱性编辑，也不支持这种可能引发强大争议的提案。“以事實論述（de facto）為主”反而能稳定表达一个地方，比如“中华人民共和国山东省青岛市”，不然「青島」、「山東青島」、「中國青島」、「中國山東青島」……可以搞出不晓得多少种来。--痛心疾首 2021年4月18日 (日) 10:15 (UTC)[回复]
      - 據我理解，依事實描述指應當使用「北京市」而非「北平」指稱中央政府所在地等事項。使用「中华人民共和国山东省青岛市」來避免「不晓得多少种」論述，實在是冗長而無比要。如要寫出行政區劃全程，則必然會造成戲劇性結果。下舉一例來自东湖旅店的段落，依照閣下建議，應當改寫為

惠州解放后，东湖旅店曾被用于中华人民共和国广东省惠阳專区武装部的办公场所。2000年代，东湖旅店的产权被以数百万人民币的价格售予私人买家。之后，相关人士在不早于2009年8月对该旅店进行了修缮，并令其回归私人住宅用途。2012年，中华人民共和国广东省惠州市惠城区人民政府将其确定为不可移动文物。2014年11月，东湖旅店被辟为一间名为“水东院子”的休闲咖啡吧。

2017年2月28日，中华人民共和国广东省惠州市惠城区召开宣传思想文化工作会议，指出将抓好包含东湖旅店在内的多幢历史建筑的修缮工作。次月，中华人民共和国广东省惠州市惠城区人民政府以人民币750万元的价格收购了旅店的产权。2018年3月3日，上述咖啡吧于社交网络发布停业装修的公告，随后于当月25日正式宣布结业转让。

以上。--Yangwenbo99^{論文} 2021年4月18日 (日) 12:23 (UTC)[回复]

(▲)同上。--山东济南，中国青岛 2021年4月18日 (日) 06:07 (UTC)[回复]
- 回應(▲)同上。--Yangwenbo99^{論文} 2021年4月18日 (日) 08:22 (UTC)[回复]
不對上述條文置可否，但是我認為在資訊框裡應使用完整的行政區劃，正文則是至少第一次提及時建議使用。另外，不知兩岸以外地區的行政區劃寫法是否有所規範？—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年4月18日 (日) 14:58 (UTC)[回复]

請問現在究竟是僅討論地名的條目命名，還是擴及地名「在文中」的使用？-游蛇脫殼/克勞棣 2021年4月18日 (日) 15:51 (UTC)[回复]

只討論在正文中的使用。條目命名已有相關規定，即只能使用「青島市」這一種形式。--Yangwenbo99^{論文} 2021年4月18日 (日) 17:04 (UTC)[回复]

(－)反对，理由如下：

就前者：‘但是Wikipedia:格式手册/两岸四地用语#指定樣式表便違背了Wikipedia:格式手册/两岸四地用语#使用「中國」一詞的建議，要求特定人士使用「中国」而非「中华人民共和国」標註國籍。可見，「在1949年之後的相關條目中，應儘量使用中華人民共和國和中華民國等全稱」之不可實踐性。’是錯誤描述。指定樣式表的規範屬於Wikipedia:格式手册/两岸四地用语#使用「中國」一詞的規範的例外條文，而且僅限於國籍，是依據國籍的國際標準表示方式而行，不存在“違背”和“不可實踐”的情形，我要求提案人立即收回其錯誤表述。
就後者：完整的行政區劃和單稱在條目内的不同地方有不同的使用，不可能在一個條目内的所有地方都完全只用完整的行政區劃或單稱。一般來説，資訊框和正文首次提及時會使用完整的行政區劃（例如“中華人民共和國山東省濟南市”、“德國北萊茵-西法倫州（代特莫爾德行政區棉登-呂貝克縣）棉登”），然後正文其餘地方使用單稱（例如“濟南”、“棉登”）。

綜以上，提議修訂屬矯枉過正，我不可能支持。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:21 (UTC)[回复]

補充説明：WG對埃琳·派齐條目的修改是完全錯誤的，1939年的青島是院轄市，不受山東省管轄。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:31 (UTC)[回复]

補充説明2：香港和澳門比較特別，通常不會把（任何形式的）國名和“特別行政區”五個字寫進去（因為嚴格上“十八區”不算是行政分區），因此基本上不會使用完整的行政區劃（唯一表達式：“中華人民共和國XX特別行政區”）。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:38 (UTC)[回复]

另外請各位關注Wikipedia:頁面存廢討論/記錄/2021/04/16中對Template:QDCT、Template:QDC和Template:QDS的提刪。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:50 (UTC)[回复]

循例請一下@K.Y.K.Z.K.、Cxbats過來好了。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:58 (UTC)[回复]

就新事項再通知一次@Itcfangye、痛心疾首。SAN MO SA _Σουέζ 2021年4月19日 (一) 02:00 (UTC)[回复]

这样子，就是在目前青岛市治权还在山东省的情况下，加山东省毫无问题。等未来N年后有机会光荣直辖（要是到时候我死了就在讨论页@我一下），再改也不迟。我本来就在用户页里说了：“除内文必须要提及山东外，仅需要在条目序言提一次山东即可。”

条目里该是山东还是山东，但我永远不会承认自己是山东人。当然，造成这一原因的不是山东人民，而是山东省政府和山东与青岛之间的文化差异性。--K·Y·K·Z·K ◢ 2021年4月19日 (一) 05:36 (UTC)[回复]

真要想成為中國的直轄市，廣州和深圳不比青島更有資格？--Googol19980904（留言） 2021年4月19日 (一) 09:42 (UTC)[回复]

即使青岛在20AA年成为直辖市，也不能否认其在1949-20AA年间是地级市。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月19日 (一) 15:33 (UTC)[回复]

那麼，單純地依據「先到先得」如何？--Yangwenbo99^{論文} 2021年4月19日 (一) 10:25 (UTC)[回复]

仍反對，我的理由2仍適用。SAN MO SA _Σουέζ 2021年4月20日 (二) 04:44 (UTC)[回复]

訂立影片加入相關指引

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:文件使用方针。

我發現最近有很多條目中都被加入了影片，雖然其中不少都對條目大有裨益，但是我也發現相當一部分條目中被加入了與條目本身關係不大的内容或與條目本身不對稱的内容（比如在青藏高原條目加入中科院院士的演講影片和在小條目加入長達20分鐘的影片），所以想請問一下社群是否需要訂立相關指引來規範條目中的影片加入？--Newbamboo（留言） 2021年4月20日 (二) 04:11 (UTC)[回复]

谢谢，这个是我在Telegram提起来的，WP:AGF的话是我确定这些内容是对维基百科的内容大有益处（尤其很多内容是我们这些普通编者很难接触到或者获取到的）的也非常感谢把他们传到commons的同仁，但是视频尤其新闻报道可能会涉及WP:NPOV的问题，即使没有NPOV问题也涉及到篇幅的问题（一个小作品里出现几十分钟的视频肯定是读者没有耐心去看的），我想了一下，有以下几个点可能可以改进：

针对新闻视频，提供新闻供稿人的名称，供读者自行辨识观点。
针对过长的视频，考虑进行剪辑或者进行截图，然后将截图插入条目进行展示。
或者如果实在认为新闻信息对条目非常宝贵，将新闻视频转写成文字的形式作为来源扩充条目。

不知道各位意向如何？--Parker^Tian 2021年4月20日 (二) 04:21 (UTC)[回复]

@Newbamboo、Park1996：已有相關規範，見WP:VUP。SAN MO SA _Σουέζ 2021年4月20日 (二) 04:28 (UTC)[回复]

虽然说针对视频资料过度使用影响阅读体验的问题，去年就已经修订相应方针来加以限制。不过就现在的情况来看，相关方针执行力度并不算强。--🔨（留言） 2021年4月20日 (二) 06:25 (UTC)[回复]

@Liu116：有甚麼條目是違反相關方針的，請列出來，我動手清理一下，有人回退的話，我就依方針提報。SAN MO SA _Σουέζ 2021年4月20日 (二) 12:55 (UTC)[回复]

……这个我没法完整列出，我顶多只知道脱贫攻坚战条目中原本被移除掉的视频后来又都被加了回来，还有2019冠状病毒病疫苗条目，以及部分“202X年X月中国大陆”的条目也有这样的问题。--🔨（留言） 2021年4月20日 (二) 13:08 (UTC)[回复]

我看到的是驻港部队有过多视频。好像很多都是WG君加入的，能不能跟他说一下让他自己改正呢--Parker^Tian 2021年4月20日 (二) 18:33 (UTC)[回复]

當中兩段影片未獲正文提及，另有一段與正文關係不夠密切，已代為刪除。--Yangwenbo99^{論文} 2021年4月20日 (二) 23:33 (UTC)[回复]

對於「加入影片」這一行為，已有相關規定——Wikipedia:文件使用方针#使用守則，即必須同時滿足

與條目有密切關連、
在條目內文有所提及、
符合中立的觀點（包括旁白、註釋），且比重需合理，及
僅保留具代表性之檔案，每條目一般不應同時存在多於五條影片。

而若在無共識的情況下將原本被刪除的影片重新加入，即屬蓄意挑起WP:編輯戰。

建議加入一條「一般而言，新聞報導與條目所論述內容有關，並不代表其內容與條目主題直接相關。僅在該影片所論述之內容本身為所在條目或所在章節之主要論述內容時，方可被認為與條目主題直接相關。」

另外，可以考慮將與內容相關，但是不便加入條目的影片放置於外部鏈接當中。甚至可以訂立指引，表示外部鏈接中可以設一節放置相關影片，以及規定收錄影片的標準。

此外，同意就編輯影片以便加入條目訂立指引。

以上。--Yangwenbo99^{論文} 2021年4月20日 (二) 23:26 (UTC)[回复]

[a1-1] 1.0 ^1.1 ^1.2 使用地區詞處理至一致也算作一致。

[2] 英维古典音乐专题的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).

[3] 纪念古斯塔夫·马勒逝世110周年系列音乐会之二. [2021-03-28].

[4] 【海神家族與馬勒巨人】簡文彬與國臺交將以音樂帶您感受作曲家與文學家筆下的深刻情感. [2021-03-28].

[5] 贝多芬的第五号交响曲.

[6] 理论上在正文出现的括号应该用全角，哈哈

[7] 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

[8] 不對提案進行實則性點評的支持意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

[9] 不對提案進行任何點評的支持或中立意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

[10] 不對提案進行任何點評的支持或中立意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

[11] 参见Wikipedia:鐵道專題/移除著色文字模板。

[12] 参见WikiProject:鐵道/移除著色文字模板。

[13] 参见WikiProject:鐵道/移除著色文字模板。

[14] 参见WikiProject:鐵道/移除著色文字模板。

[註 1]

[1]

[2]

[3]

[4]

[5]

[6]

[1]

[1]

[1]

[1]

[1]

[1]

[1]

@@ 第316行： / 第316行： @@
 ==== <span id="R2"></span><span id="interwk"></span> R2. 跨[[H:NS|名字空间]]的[[WP:R|重定向]]。 ====
 :包括以下幾種類型：
-:#由条目的名字空间指向非條目名字空间的重定向；
+:#从条目名字空间指向非條目名字空间的重定向；
-:#将用户页移出条目名字空间時遺留的重定向；
+:#从用户页名字空间移動至条目名字空间時遺留的重定向；
 :#从草稿名字空间指向非草稿名字空间的重定向；
 :#從計畫命名空間（Wikipedia）指向維基專題命名空間（WikiProject）的重定向；及
-:#從維基專題命名空間指向計畫命名空間的重定向。
+:#從維基專題命名空間（WikiProject）指向計畫命名空間（Wikipedia）的重定向。
 :經社群同意設立的[[Wikipedia:捷徑#偽命名空間|偽命名空間]]屬於本規則之例外。
 :'''注意'''：有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遺留的重定向頁前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。
@@ 第330行： / 第330行： @@
 ::上面的結論有指明「清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向」，所以應該需要bot，再不然發通知邀請社群協力清理也可。[[U:Sanmosa|SAN]][[UT:Sanmosa|MO]][[Special:Contribs/Sanmosa|SA]] <sub>Σουέζ</sub> 2021年4月17日 (六) 11:00 (UTC)
 :{{意见}}：“2. 将用户页移出条目名字空间时遗留的重定向”真包含于“1. 由条目{{删除条文|的}}名字空间指向非條目名字空间的重定向”，可以删去。另外那个{{删除条文|的}}看起来怪怪的，建议删去。&nbsp;——[[U:羊羊32521|<span style="color:#080;font-size:17px;font-family:楷体;">'''羊羊'''</span>]] <small>[ [[UT:羊羊32521|留言]] [[Special:Contribs/羊羊32521|贡献]] [[WP:WCN|维猫报]] [[PJ:CM|古典音乐专题]] ]</small> 2021年4月20日 (二) 04:57 (UTC)
+::{{ping|羊羊32521}}（1）1是（條目命名空間）→（非條目命名空間），2是（非條目命名空間）→（條目命名空間），2不能刪。（2）完成。[[U:Sanmosa|SAN]][[UT:Sanmosa|MO]][[Special:Contribs/Sanmosa|SA]] <sub>Σουέζ</sub> 2021年4月21日 (三) 03:38 (UTC)
+:容許我再多等待三日，上面的提案會稍為調整。[[U:Sanmosa|SAN]][[UT:Sanmosa|MO]][[Special:Contribs/Sanmosa|SA]] <sub>Σουέζ</sub> 2021年4月21日 (三) 03:38 (UTC)
 === 第六階段：(暫不開放) ===

查论编布告板
以灰色標註者尚未正式啟用
一般	管理員行政員仲裁委员会教育專案首頁錯誤志愿者回覆團隊監督權限一般機器人機器用户解除權限
條目與內容	疑似侵權可靠來源尋求資源垃圾链接黑名單白名單標題黑名單白名單受限制文件翻譯
頁面處理	合併匯入發送大量訊息移動机器人作业保護刪除修訂版本存廢討論頁面檔案覆核查詢已刪除內容
用户行為	利益衝突著作权调查破壞編輯爭議其他不當行為禁制傀儡調查調查助理不當用户名仲裁请求立案澄清及修正动议
其他	更改用户名防濫用過濾器新增或修改回報錯誤問題知識問答新條目徵求意見分類索引討論頁話題索引互助客棧消息方針技術求助條目探討其他字詞轉換地区词候选修復請求各地維基人
維基百科布告板

查论编徵求意見（全部）
條目主題	傳記（`bio`）經濟、貿易與公司（`econ`）歷史與地理（`hist`）語言及語言學（`lang`）數學、科學與科技（`sci`）媒體、藝術與建築（`media`）政治、政府與法律（`pol`）宗教與哲學（`reli`）社會、體育運動與文化（`soc`）
非條目主題	維基百科格式與命名（`style`）維基百科方針與指引（`policy`）維基專題與協作（`proj`）維基百科技術議題與模板（`tech`）維基百科提議（`prop`）未分類
提示	要將某一個討論加入上述列表中：在討論頁中的對應討論章節頂端加上`{{rfc\|xxx}}`標籤，其中「xxx」為分類縮寫。各類分類縮寫已列於上方項目中，並應將其插入`{{rfc}}`中。多個分類請使用管道符號分開，如`{{rfc\|xxx\|yyy}}`，其中「xxx」為第一個分類，「yyy」為第二個分類。
更多資訊請參閱維基百科:徵求意見。請在維基百科討論:徵求意見回報有關錯誤。本列表由LuciferianBot於每個小時進行更新。

2021年4月21日 (三) 03:38的版本

正在廣泛徵求意見的議題

專題命名空間

專題空間設立流程與細節

第一階段：申請

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

第二階段：轉移至新名字空間

第二階段 之 公示狀態通告

第二階段 之 公示期討論

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

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

第四階段：調整專題模板

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

第五階段：小結

第六階段：(暫不開放)

偽命名空間

小结1

小结2

捷徑空间提案

小結3

再提捷徑空间提案

尝试推动LTA空间

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

進一步討論

自動提刪R2

MOS捷徑名稱

軟重定向

技術問題處理

自動半保護偽命名空間

提議設立快速刪除標準 O8

將LTA空間設定為noindex

WP:捷徑指引草案修訂

說明

專題命名空間問題

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

捷徑細部修訂

有關某年代相關分類命名統一事宜

針對性決議

頁面命名一致性的通用（普遍性）條文

請求第三方管理員參與評估和總結可靠來源討論

關於Wikipedia:命名常规 (音乐)

Wikipedia:命名常规 (音乐)1.0更新報告

Wikipedia:命名常规 (音乐)2.0更新報告

Wikipedia:命名常规 (音乐)公示

（重提）Wikipedia:共识#提案討論及公示時間的執行力度

調適案1

第一步

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

初步定案

模板颜色相关规范

變通提案

提议对WP:DYKC的投票须知进行修改

调整界面管理员方针之“权限取得”一节

模板修訂建議

设计一个制度解决部分速删模板挂不上去的页面的删除问题

限縮{{电视节目的变迁}}模板使用範圍

通用行為準則/2021諮詢

设立过滤器禁止将维基百科用作来源

订立编辑松相关规章制度

將「青島」、「中國青島」或「山東青島」改成「中華人民共和國山東省青島」是否有必要

就「使用『中國』一詞」的權宜修正

就提及兩岸四地之下級地區作出規定

訂立影片加入相關指引

第二階段之公示狀態通告

第二階段之公示期討論