跳转到内容

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

本页使用了标题或全文手工转换
维基百科，自由的百科全书
以互动方式浏览历史
←上一编辑下一编辑→
删除的内容 添加的内容
可视化wikitext
第316行： 第316行：
==== <span id="R2"></span><span id="interwk"></span> R2. 跨[[H:NS|名字空间]]的[[WP:R|重定向]]。 ====
==== <span id="R2"></span><span id="interwk"></span> R2. 跨[[H:NS|名字空间]]的[[WP:R|重定向]]。 ====
:包括以下幾種類型：
:包括以下幾種類型：
:#由条目的名字空间指向非條目名字空间的重定向；
:#从条目名字空间指向非條目名字空间的重定向；
:#将用户页移出条目名字空间時遺留的重定向；
:#从用户页名字空间移動至条目名字空间時遺留的重定向；
:#从草稿名字空间指向非草稿名字空间的重定向；
:#从草稿名字空间指向非草稿名字空间的重定向；
:#從計畫命名空間（Wikipedia）指向維基專題命名空間（WikiProject）的重定向；及
:#從計畫命名空間（Wikipedia）指向維基專題命名空間（WikiProject）的重定向；及
:#從維基專題命名空間指向計畫命名空間的重定向。
:#從維基專題命名空間（WikiProject）指向計畫命名空間（Wikipedia）的重定向。
:經社群同意設立的[[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)
::上面的結論有指明「清理連入頁面後刪除現有跨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)
:{{意见}}：“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)


=== 第六階段：(暫不開放) ===
=== 第六階段：(暫不開放) ===

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

快捷方式

此页面探讨维基百科的方针与指引。


请注重礼仪、遵守方针与指引，一般问题请至互助客栈其他区或知识问答提出，留言后请务必签名（点击 ）。


发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。

议题最后回应时间为1月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 提议将所有子命名常规与命名常规提案页面的名称格式一概改为子页面的名称格式 21 7 S8321414 2025-01-13 09:25
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次改组”。Sanmosa 新朝雅政 2024年12月4日 (三) 14:09 (UTC)

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

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

维基百科方针与指引

Wikipedia talk:互助客栈 § 有关互助客栈方针版的长度压力问题

此前，互助客栈方针版的长度一度逾60万位元组，在我搬运了若干已结束或stale了的讨论后才降到40多万，然而这个长度还是比起其他互助客栈的版块来得长（互助客栈其他版的长度现在是20多万位元组，条目探讨版是10多万，消息、技术与求助版不超过10万），而且在页面载入与编辑上也产生了一些问题（我在电脑尝试载入或编辑页面的话，页面完全载入所需的时间显著地延长了）。有鉴于此前曾有讨论提议以WP:征求意见机制取代互助客栈方针版的机能，我认为现在是合适的时机来提出这件事情。Sanmosa 新朝雅政 2024年10月23日 (三) 00:30 (UTC)

Wikipedia talk:保护方针 § 对于全保护的一些建议

对《破·地狱》现在的全保护有感，觉得需对管理员提出一点意见。我对全保护的观感，始于2023年3月《中年好声音》，在播映期间因部分延伸确认用户发生编辑战而全保护3个月之久，过长的全保护漠视了其他没有参与编辑战用户的权利，且当时交战双方在对方的个人讨论页进行指责，却没有人试图在条目讨论页发起讨论，连事后其他人追溯到底发生过什么事都有困难。这次破·地狱全保护的时长合理，但一般人根本难以注意有讨论存在于Wikipedia:互助客栈/条目探讨#电影条目过度收录问题，希望管理员也能多做一点促进讨论。就此，我建议如下：

  1. 全保护后如未有人发起讨论，管理员可在条目讨论页发起，通知有关用户。
  2. 如管理员得知已有人发起相关讨论，但并非在条目讨论页，管理员可在条目讨论页留下连结。
  3. 保护模板可否进化一下，能加入相关讨论连结？--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:收錄標準/交通/道路特殊收錄限制列表”

既然都是交通收录标准的子集了，我觉得放在子页面比较合理吧？--SunAfterRain 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年设立新名字空间及伪名字空间是重定向页面）。

[编辑此导航模板]

本主题全部或部分段落文字，转移自Wikipedia:互助客栈/方针#WP:捷径指引草案修订。执行人：台湾杉在此发言 (会客室)。标记人：来人啊，喂宫子吃布丁！ ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:44 (UTC)。[回复]

捷径指引草案的讨论，源自于“伪命名空间”的讨论，英语维基百科对于捷径相关的规范及伪命名空间的设立已有成熟的执行方式。中文维基百科中的部分编辑者对于“格式手册”、“长期破坏者”及“专题”这三个主题提出可升级成命名空间或以伪命名空间形式存在，并有正反两方的陈述与看法。

目前较为接近共识的是“专题”提升为正式命名空间，反对者的论述已由支持者回应，且反方无进一步论述。然为求慎重，且将捷径与命名空间等议题作系统性讨论，将会执行阶段修订，以取得最大共识。

本讨论的各阶段分为：

  1. 专题提升为命名空间与否及其细节；
  2. 格式手册及长期破坏者是否成为命名空间或伪命名空间；
  3. 伪命名空间规范写入捷径规范内（如前项通过）或是否允许伪命名空间（如前项不通过）；
  4. 捷径规范细部讨论并决定是否成为指引。

各阶段不得同时讨论，前一项讨论完结之后，才能进行下一段讨论。台湾杉在此发言 (会客室) 2020年12月10日 (四) 05:47 (UTC)[回复]

专题命名空间通过，剩馀细节独立讨论。台湾杉在此发言 (会客室) 2021年1月11日 (一) 11:20 (UTC)[回复]
目前的后续讨论须等phab:T271612布署完毕后才能继续进行。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月12日 (二) 13:08 (UTC)[回复]

已通过：
已 公示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)[回复]
小总结

根据以上讨论，目前共有两个选项：

  1. 开放伪命名空间；
  2. 将PJ纳入命名空间并作为别名，MOS、LTA再行讨论。

伪命名空间看起来是3人反对，5人左右支持，仅能算过半支持，但也未达到绝对多数，且目前还没看到反对方出来针对正方回应进行进一步论述。而部分支持伪命名空间的使用者也不反对后者的提案。

所以目前的共识倾向为将PJ（专题）独立成为新的命名空间，伪命名空间将继续讨论。因本讨论最后一次发言起过5日，公示期延长为9日。因此现在起 公示9日，2020年12月6日 (日) 03:26 (UTC) 结束。台湾杉在此发言 (会客室) 2020年11月27日 (五) 03:26 (UTC)[回复]

至于遗留下来的问题，将会由下方讨论继续进行。台湾杉在此发言 (会客室) 2020年11月27日 (五) 03:37 (UTC)[回复]
反对将专题独立为（伪）命名空间。众所皆知维基专题在本地一直发展不起来，除部分专题有实质工作外，多数专题基本上就只有评级的作用而已。连专题发展蓬勃的英文维基百科都没有将专题独立为（伪）命名空间了，本地大概更没需要。另外，我从没见过哪位编者用PJ代指维基专题的，多半直接用专题简称。现在这样子感觉像是为独立而独立，硬是找一个英文缩写当作别名。反倒是LTA，我觉得可以独立为伪命名空间。—— Eric Liu 创造は生命（留言．留名．学生会） 2020年11月27日 (五) 04:19 (UTC)[回复]
不是伪，是“真”。“专题:数学”显然比“维基百科:数学专题”更简洁。 见日语维基和法语维基。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月27日 (五) 08:05 (UTC)[回复]
等等，PJ:和P(ortal):的区别我没太搞清。哪位可以解释一下？Zhuofan WuCien años de soledad 2020年11月29日 (日) 03:08 (UTC)[回复]
ZhuofanWu ——羊羊 (留言|贡献) 2020年11月29日 (日) 04:11 (UTC)[回复]
一个是Portal，一个是Project。--台湾杉在此发言 (会客室) 2020年11月29日 (日) 08:31 (UTC)[回复]
如果要细节的话：Portal（主题）有点类似各知识领域的主页，展示该领域重要或优良的条目之用；Project（专题）则是说明该领域知识的编辑建议与规则，以及该领域社群的讨论场所。台湾杉在此发言 (会客室) 2020年11月29日 (日) 10:07 (UTC)[回复]
Wait，有bug。Project命名空间在中文维基百科等价于Wikipedia命名空间。SANMOSA SPQR 2020年11月29日 (日) 14:24 (UTC)[回复]
不成问题，见日维相关讨论。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月29日 (日) 14:28 (UTC)[回复]
那倒不如直接设PJ命名空间在中文维基百科等价于Wikipedia命名空间（如同WP命名空间），反正各专题现时皆在Wikipedia命名空间下，这样会较能保持一致性，也不会衍生Project的指代问题。SANMOSA SPQR 2020年11月29日 (日) 14:33 (UTC)[回复]
那这样起不到“减少命名冲突”的效果…… ——羊羊 (留言|贡献) 2020年11月30日 (一) 22:06 (UTC)[回复]
@Sanmosa：见下-- Sunny00217  2020年12月2日 (三) 14:25 (UTC)[回复]
我在这里作出过的留言可供参考。--MilkyDefer，推迟，咕咕 2020年11月29日 (日) 16:16 (UTC)[回复]

依照目前公示后讨论情况，将会和下面的捷径指引案并案讨论，并采取分阶段修订。今天晚上会进行整合。台湾杉在此发言 (会客室) 2020年12月6日 (日) 07:38 (UTC)[回复]

依据先前讨论，专题命名空间的讨论已接近达成共识之阶段，目前问题包含：

  1. 英文命名部分，其一为Project并取消与Wikipedia空间连动，其二为以WikiProject命名；
  2. 部分使用者认为直接将PJ与Wikipedia连动即可。

请讨论。台湾杉在此发言 (会客室) 2020年12月10日 (四) 05:47 (UTC)[回复]

  • 个人以为Project名字空间肯定不能变，否则可能会造成不少链接失效。因此名字空间应该命名为“WikiProject”，对应的中文名字空间应该命名为“维基专题”，以便于与“WikiProject”对应。——BlackShadowG（留言） 2020年12月11日 (五) 16:27 (UTC)[回复]
    • 我认为中文叫做“专题”并无不妥，也无冲突。将“WikiProject:”作为程式系统前缀；“专题”、“维基专题”、“PJ”作为别名。其他中文别名也可以之后再议再补。并依照法维和日维和其他姐妹计划的统一定义，定为{{ns:102}}(目前显示为“WikiProject”，空白是因为本地尚未实装）。— ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月11日 (五) 18:16 (UTC)[回复]
确定英文名称不会冲突就可以，中文名称应该没问题。SANMOSA SPQR 2020年12月12日 (六) 03:34 (UTC)[回复]
支持命名为WikiProject/专题 ——羊羊 (留言|贡献) 2020年12月16日 (三) 15:08 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

专题空间设立流程与细节

参考ja:Special:PermaLink/39099771#ウィキプロジェクト用名前空间の新设以及ja:Wikipedia:ウィキプロジェクト/名前空间の新设，本地的处理方式预计会分成5个阶段进行：

  1. 向phab:提交申请设立专题空间；
  2. 将专题页与讨论页批次移动到专题空间（可能需WP:FLOOD）；
  3. 修正指向专题的内部链接（可能需WP:FLOOD）；
  4. 调整专题模板；
  5. 讨论重新导向与捷径的设立方式；
  6. 其他议题。
以上。以上流程不会立即执行，会在社群对流程没有异议之后公示后执行。如有其他相关疑问可继续在下方讨论。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 07:44 (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)[回复]
转交 转交phab:T271612。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月9日 (六) 08:16 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第一点五阶段：内容事实修订

由于该命名空间设立完毕，已修正WP:命名空间新增该空间说明。如需补充欢迎讨论。台湾杉在此发言 (会客室) 2021年1月27日 (三) 13:40 (UTC)[回复]

您漏了WP:NS#缩写和别名。--LuciferianThomas．留言 2021年1月28日 (四) 08:08 (UTC)[回复]
完成。--台湾杉在此发言 (会客室) 2021年1月29日 (五) 13:37 (UTC)[回复]
请协助复查是否全部的相关说明页都修复完毕。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月25日 (四) 05:49 (UTC)[回复]

第二阶段：转移至新名字空间

已通过：
公示从2021年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)[回复]

第二阶段 之 公示状态通告

第二阶段 之 公示期讨论

公示通过，即将开始移动-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 13:04 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
专题指引更名
“维基专题:维基专题:XX”的页面
已处理：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第二点五阶段：相关技术问题修正

于Phabricator查看
编号T273763的工单
状态：已解决

根据phab:T273763（设立专题空间后，连入页面API于 pywikibot 出错），此修正案导致部分机器人出错。目前phab:T273763已解决，留此节讨论其他相关技术出问题时的策略与解决方案。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月8日 (一) 17:54 (UTC)[回复]

前几天发现WikiProject:传统百科全书条目因为页面移动后造成大部分子页面出现错误，目前已经修复一部分--百無一用是書生 (☎) 2021年3月16日 (二) 02:37 (UTC)[回复]

第三阶段：修正指向专题的内部链接

各阶段不得同时讨论，前一项讨论完结之后，才能进行下一段讨论。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 19:29 (UTC)[回复]

第四阶段：调整专题模板

已完成：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第五阶段：讨论重新导向与捷径的设立方式

各阶段不得同时讨论，前一项讨论完结之后，才能进行下一段讨论。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 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。--LightyearsTalk·Sign#订阅维猫报喵！ 2021年2月14日 (日) 11:15 (UTC)[回复]
  • 个人意见
    1. 为了避免混淆，将来应该一律禁止建立跨WP与PJ空间的捷径重定向。
    2. 目前存在的WP重定向到PJ的捷径应该全部转移到PJ，若无链入或很少链入，可考虑(×)删除；若数量过大，或者已经在讨论中被引用，则可考虑(○)保留以仅供历史参考。
    3. 同时，将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径，不再推荐使用以WP开头的捷径。

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

同上，不然就没必要伪命名空间了。 2021年2月14日 (日) 13:49 (UTC)[回复]
我觉得从PJ空间捷径连出没什么问题，WP空间也有捷径连至Help。PJ分拆了就不要再从WP连过去了，旧的就随它吧。--LuciferianThomas．留言 2021年2月14日 (日) 14:09 (UTC)[回复]
旧的捷径如要批量删除的话可能要请求管理员开删除机器人...-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 14:11 (UTC)[回复]
所以把PJ空间的{{shortcut}}全部更新，提醒将来的编者不要再用WP链接到PJ的捷径就行了。那些没有链入的WP捷径删了也无妨。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月16日 (二) 02:05 (UTC)[回复]
个人意见：
  1. 原则上不允许，但社群就个别页面的特殊情形可以例外特许。建议以修改R2规范处理。
  2. 不允许。如出现，应清除连入并删除。
  3. 可行。清除连入可以请求bot（WP→PJ），删除的话我觉得开一个list，然后转AFD即可。
以上。SANMOSA SPQR 2021年2月17日 (三) 14:40 (UTC)[回复]
既然（我认为）未来不允许建立跨WP与PJ空间的非捷径重新导向，而且非条目命名空间的非捷径重新导向本来就使用率低下，如果真的有人意外建立了，都不会有多少连入，清除连入也不是甚么困难的事，而且还能避免未来的误用。SANMOSA Σουέζ 2021年3月31日 (三) 07:43 (UTC)[回复]
Wikipedia:专题和Wikipedia:专题委员会等部分页面为何还没有移动到新的名字空间？还是这些页面不应该移动？--百無一用是書生 (☎) 2021年2月19日 (五) 02:46 (UTC)[回复]
先前讨论有提到将专题介绍留在WP空间。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月19日 (五) 17:12 (UTC)[回复]
专题委员会并非专题介绍，Wikipedia:专题似乎也称不上是介绍，更像是WikiProject:首页的作用--百無一用是書生 (☎) 2021年3月1日 (一) 02:54 (UTC)[回复]
个人认为跨WP->PJ没差，但PJ->WP的不行-- Sunny00217  2021年2月21日 (日) 13:56 (UTC)[回复]

第五阶段：小结

总结以上讨论意见：

  1. 禁止建立跨WP与PJ空间的捷径重新导向。并清理连入页面后删除现有跨WP与PJ空间的捷径重新导向；同时，将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径，不再推荐使用以WP开头的捷径。→修改R2规范
  2. Wikipedia:专题和Wikipedia:专题委员会移动到PJ空间。→需探讨是否留重定向
以上-- 五岁抬头雪菲（☎️·☘️） 2021年4月7日 (三) 06:22 (UTC)[回复]
补：R2修改内容：
现行条文

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

由条目的名字空间重定向至非条目名字空间，将用户页移出条目名字空间时遗留的重定向，或者从草稿名字空间指向非草稿名字空间的重定向。经社群同意设立的伪命名空间属于本规则之例外。注意：有时新加入的维基人偶尔会在主条目空间误建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遗留的重定向页前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。
  • 使用模板{{d|R2}}或{{d|interwk}}。
提议条文

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

包括以下几种类型：
  1. 从条目名字空间指向非条目名字空间的重定向；
  2. 从用户页名字空间移动至条目名字空间时遗留的重定向；
  3. 从草稿名字空间指向非草稿名字空间的重定向；
  4. 从计画命名空间（Wikipedia）指向维基专题命名空间（WikiProject）的重定向；及
  5. 从维基专题命名空间（WikiProject）指向计画命名空间（Wikipedia）的重定向。
经社群同意设立的伪命名空间属于本规则之例外。
注意：有时新加入的维基人偶尔会在主条目空间误建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遗留的重定向页前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。
  • 使用模板{{d|R2}}或{{d|interwk}}。

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

Module:Template:Delete/data模组的对应修改见User:Sanmosa/R2模组。SANMOSA Σουέζ 2021年4月17日 (六) 04:24 (UTC)[回复]
现时有3502个WP->WPJ的重新导向，33个WPJ->WP的重新导向。--Xiplus#Talk 2021年4月17日 (六) 05:07 (UTC)[回复]
上面的结论有指明“清理连入页面后删除现有跨WP与PJ空间的捷径重新导向”，所以应该需要bot，再不然发通知邀请社群协力清理也可。SANMOSA Σουέζ 2021年4月17日 (六) 11:00 (UTC)[回复]
(！)意见：“2. 将用户页移出条目名字空间时遗留的重定向”真包含于“1. 由条目的名字空间指向非条目名字空间的重定向”，可以删去。另外那个的看起来怪怪的，建议删去。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月20日 (二) 04:57 (UTC)[回复]
@羊羊32521：（1）1是（条目命名空间）→（非条目命名空间），2是（非条目命名空间）→（条目命名空间），2不能删。（2）完成。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)[回复]
容许我再多等待三日，上面的提案会稍为调整。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)[回复]

第六阶段：(暂不开放)

各阶段不得同时讨论，前一项讨论完结之后，才能进行下一段讨论。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:41 (UTC)[回复]

本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到部署完成。欲让机器人存档，请移除本模板。留言请置于本模板上方。

伪命名空间

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间（错误：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向页面）。

[编辑此导航模板]

本案讨论格式手册及长期破坏者提升问题。目前有三案：

  • 格式手册及长期破坏者提升为命名空间，英语名称待定；
  • 格式手册及长期破坏者成为伪命名空间，缩写为MOS及LTA；
  • 维持现行方式。

请讨论。台湾杉在此发言 (会客室) 2020年12月25日 (五) 01:23 (UTC)[回复]

建议立为伪命名空间（方案2）。SANMOSA SPQR 2020年12月27日 (日) 07:32 (UTC)[回复]
支持提升为命名空间，因为会违反快速删除方针的R2准则。 2020年12月28日 (一) 07:06 (UTC)[回复]
如果是伪命名空间通过，就会在下一阶段修订快速删除、捷径以及命名空间规范。--台湾杉在此发言 (会客室) 2020年12月28日 (一) 09:53 (UTC)[回复]
支持成为伪命名空间。命名空间涉及较多技术问题，未来如需求明显，可再议转换。--YFdyh000（留言） 2020年12月30日 (三) 13:01 (UTC)[回复]
如需要立为名字空间也并非不可，只是要决定其所使用的数字ID
  • 0-99的命名空间ID要保留给维基媒体系统使用，故需要使用100以上的命名空间ID
    下面整理许多语言版本维基百科的命名空间ID使用(主空间是偶数，讨论空间是奇数)
命名空间 命名空间ID
/
讨论页ID 		维基百科
各语言版本
使用状况(未穷举) 		本地使用状况 备注
主题: 100/101 全部语言版本维基百科皆有启用 （参考此处整理） 本地已使用 Help:主题
专题: 102/103 中文及加泰兰文、世界文、法文、韩文、奥克西坦文、日文等 本地已使用 Wikipedia:专题
附件: 104/105 西班牙文等 未使用 类似中文维基辞典的附录
列表: 104/105 仅立陶宛文维基 未使用 WP:列表
文献: 104/105 法文、奥克西坦文等 未使用 参考User:青子守歌的整理
仲裁: 106/107 俄罗斯文等 未使用 (本地未通过相应指引)
WP:仲裁委员会
图书: 108/109 超过25个语言版本使用。 本地通过的共识为 :
繁简转换系统处理完毕后引入，然而P站仍在努力中，因此还是有机会使用此数值 		Help:图书
110/111 未使用
草稿: 118/119 超过25个语言版本使用。 本地已使用 WP:草稿
以上补充。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月31日 (四) 09:52 (UTC)[回复]
(＋)支持为设立伪命名空间，对设为真命名空间(＃)有保留。--LuciferianThomas．留言 2020年12月31日 (四) 15:58 (UTC)[回复]
我对成立真命名空间(＃)有保留，尤其是格式手册。对格式手册而言，因为格式手册同时也是指引，对它成立真命名空间将意味着指引分散两地。 --Milky·Defer 2020年12月31日 (四) 17:13 (UTC)[回复]

小结1

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

我想补充一个意见：我反对MOS及LTA设为真命名空间，仅支持MOS及LTA设为伪命名空间。SANMOSA SPQR 2021年1月2日 (六) 08:17 (UTC)[回复]
支持命名空间，反对伪命名空间。SmallTim（留言） 2021年1月5日 (二) 13:56 (UTC)[回复]
(？)疑问@SmallTim：有鉴于WP:投票不能代替讨论，能否请您补充一下反对伪命名空间的理由，以便汇整、推进讨论？感激不尽。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月5日 (二) 18:25 (UTC)[回复]
这整得跟投票一样，建议各位将(＋)支持和(－)反对的理由写出来，逐一进行讨论，以此达到共识。毕竟投票不能代替讨论。 ——羊羊 (留言|贡献) 2021年1月5日 (二) 15:50 (UTC)[回复]
我建议直接排除成为真命名空间的可能性，这样会产生维护问题。SANMOSA SPQR 2021年1月6日 (三) 06:10 (UTC)[回复]
方针指引宜集中于同一命名空间。SANMOSA SPQR 2021年1月6日 (三) 06:45 (UTC)[回复]
(！)意见@Sanmosa：LTA不是方针、指引、态度指引、草案、提议、论述、专题、主题、存档、书籍、条目、分类、介面...都不是。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 06:48 (UTC)[回复]
那你当我的建议仅适用于MOS。SANMOSA SPQR 2021年1月6日 (三) 06:51 (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。如果设立名字空间的同时增设页面查看权限（回退员及以上），我会考虑支持。--YFdyh000（留言） 2021年1月15日 (五) 12:28 (UTC)[回复]
但似乎普遍意见并不赞同LTA升格真命名空间，即使有潜力但却缺乏社群共识，也难以行事。--LuciferianThomas．留言 2021年1月15日 (五) 17:40 (UTC)[回复]

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

LTA数量可能少，但shortcut还是蛮多的。而且LTA数量也会增多-- ——羊羊 (留言|贡献) 2021年1月16日 (六) 12:55 (UTC)[回复]
伪命名空间只是for捷径连结而已，原本的页面不会被移动。--LuciferianThomas．留言 2021年1月16日 (六) 13:12 (UTC)[回复]
  • (＋)支持伪名字空间。我原本是支持名字空间的，但经历了上述讨论以及主持了专题名字空间的设立，我发现伪名字空间是有许多优点的。先看名字空间，名字空间是需要“安装”的，本地获得共识之后要等待工程师安装，期间从数周到数月不等，且不具备可扩充性，即每新增一个名字空间都要请工程师协助，本地管理员、介面管理员、模组编辑员都无能为力，只有基金会工程师可以执行，“真名字空间”可扩充性不佳。我们来看看“伪名字空间”，它“免安装”耶，随加即用，涉及命名空间判断的本地模板与模组本地的管理员、介面管理员、模组编辑员都能即时加入，也不必等待工程师安装，“伪名字空间”可扩充性十分良好。假如今天社群需要一个新的捷径前缀或字首，真名字空间需要等待工程师安装，而伪名字空间公示通过后就能随加即用，是多么的方便。正如台湾杉在此发言 (会客室)所言：“如果伪命名空间不会造成“系统性”的重大问题，就可以纳入考量。”且许多问题如模板输出都可以透过技术手段解决，参见#宇帆于2021年1月19日 (二) 07:14 (UTC)之发言。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 07:16 (UTC)[回复]

捷径空间提案

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

否决：
设立捷径专用名字空间无法有效解决本案核心问题。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月20日 (三) 07:14 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

小结3

在使用者自订的Common.js测试有关代码的结果。测试于[[MOS:001]]。
(：)回应@LuciferianThomas：已测试相关代码（程式码片段）在Common.js中的行为，Special:Diff/63843386，以[[MOS:001]]为例，效果见图File:Pseudo-Namespace MOS UI Test in Chinese Wikipedia.png。如伪名字空间通过设立可以考虑请求介面管理员添加相关代码于MediaWiki:Common.js。副知@羊羊32521：重定向页显示条目已有可行解决办法。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月21日 (四) 08:32 (UTC)[回复]

再提捷径空间提案

本主题全部或部分段落文字，已转移至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空间联系性不大”。不认为二次移动是个大问题，社群可以先用伪名字空间看看效果。--YFdyh000（留言） 2021年1月23日 (六) 12:25 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

伪命名空间相关方针及WP:捷径修正

通过：
@Taiwania Justo、Pseudo Classes、Sanmosa、A2569875、GZWDer：公示七日结束，共识期间唯一异议排除，公示获得通过，有关条文。即日起MOS、LTA伪命名空间获得CSD R2例外，上述命名空间作为格式手册和长期破坏者页面的正规连结。--LuciferianThomas．留言 2021年1月31日 (日) 03:11 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

本讨论已近一个月，得到的回馈有：

  1. 主流意见认为格式手册及长期破坏者（持续出没的破坏者）宜设立伪命名空间；
  2. 已有技术手段可分出伪命名空间与主命名空间的差异性；
  3. 设立伪命名空间无重大系统性问题，且部署容易，不牵涉到基金会层面之程式修改。

由此，伪命名空间将会在上段讨论开始一个月后进行公示（也没过几天），而相关规范也将尽速修正或设立，下列针对快速删除方针R2进行修正，及将WP:捷径中的伪命名空间部分做为指引。下列为R2修正提案。

现行条文

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

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

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

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

捷径中伪命名空间的规范详见这里。

请讨论。台湾杉在此发言 (会客室) 2021年1月20日 (三) 06:53 (UTC)[回复]

同意提案。SANMOSA SPQR 2021年1月20日 (三) 08:10 (UTC)[回复]
(＋)赞成R2修正案，另就WP:捷径，我看了一遍，似乎要整个重新整理过。--LuciferianThomas．留言 2021年1月20日 (三) 10:04 (UTC)[回复]
捷径修正细节是最后一项讨论内容，目前先以伪命名空间为讨论对象。也欢迎对捷径规范作重新整理。--台湾杉在此发言 (会客室) 2021年1月20日 (三) 12:19 (UTC)[回复]
(＋)支持WP:CSD修正案与伪名字空间。我原本是支持名字空间的，但经历了上述讨论以及主持了专题名字空间的设立，我发现伪名字空间是有许多优点的。先看名字空间，名字空间是需要“安装”的，本地获得共识之后要等待工程师安装，期间从数周到数月不等，且不具备可扩充性，即每新增一个名字空间都要请工程师协助，本地管理员、介面管理员、模组编辑员都无能为力，只有基金会工程师可以执行，“真名字空间”可扩充性不佳。我们来看看“伪名字空间”，它“免安装”耶，随加即用，涉及命名空间判断的本地模板与模组本地的管理员、介面管理员、模组编辑员都能即时加入，也不必等待工程师安装，“伪名字空间”可扩充性十分良好。假如今天社群需要一个新的捷径前缀或字首，真名字空间需要等待工程师安装，而伪名字空间公示通过后就能随加即用，是多么的方便，然而要实现此需要修正WP:CSD#R2，正如台湾杉在此发言 (会客室)所言：“如果伪命名空间不会造成“系统性”的重大问题，就可以纳入考量。”，参见#宇帆于2021年1月19日 (二) 07:16 (UTC)之发言，未见要修正WP:CSD#R2会出现什么系统性问题，故此(＋)支持WP:CSD修正案。以上-- 来人啊，喂宫子吃布丁！ ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月21日 (四) 08:06 (UTC)[回复]
想向诸位确认一下@A2569875、Taiwania Justo：此案中已经说明伪命名空间的实施，意即此案通过则伪命名空间同步通过？--LuciferianThomas．留言 2021年1月22日 (五) 11:32 (UTC)[回复]
顺序是上面的MOS、LTA先公示完毕，本案才会接著进行公示。于此期间两边同步讨论。--台湾杉在此发言 (会客室) 2021年1月22日 (五) 15:05 (UTC)[回复]
我认为两案必然挂钩，建议若公示伪命名空间则同步公示R2修订，没有分部处理的必要。--LuciferianThomas．留言 2021年1月22日 (五) 22:06 (UTC)[回复]
@Taiwania Justo：两者应当一同公示并通过，否则会有合法性问题。SANMOSA SPQR 2021年1月23日 (六) 08:55 (UTC)[回复]
借问：现在讨论似乎已经算超过一个月了（这提案承接上次讨论，已经很久了），而已经达到基本社群共识（共识不强求全然同意，但可采取主流意见），理论上可以7DAYS？--LuciferianThomas．留言 2021年1月23日 (六) 09:25 (UTC)[回复]
那就现在公示吧。--台湾杉在此发言 (会客室) 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

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

现时主命名空间的R2好像有机械人自动提速删？是否要请BOT主修正，或暂时透过过滤器阻止机械人速删？--LuciferianThomas．留言 2021年1月31日 (日) 03:11 (UTC)[回复]

@Jimmy Xu。--台湾杉在此发言 (会客室) 2021年1月31日 (日) 04:31 (UTC)[回复]
Special:Diff/64056831-- Sunny00217  2021年2月1日 (一) 11:53 (UTC)[回复]
已更新。--Jimmy Xu 论 2021年2月1日 (一) 14:07 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

MOS捷径名称

LTA空间的捷径大部分都可以快速移动，但格式手册的捷径很多不同格式，在此希望各位一同组成完整的新捷径列表。--LuciferianThomas．留言 2021年1月31日 (日) 03:11 (UTC)[回复]

WP:NS2021/MOSSC，已列出部分格式手册可用捷径，请检查，并协助补充。--LuciferianThomas．留言 2021年2月1日 (一) 08:48 (UTC)[回复]
已完成，请协助检查。--LuciferianThomas．留言 2021年2月3日 (三) 04:35 (UTC)[回复]

软重定向

已否决：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

原有的捷径可否改为软重定向并作出提示“此捷径已移动至XXX，请直接使用新捷径”？--LuciferianThomas．留言 2021年1月31日 (日) 03:11 (UTC)[回复]

(－)反对，原有重新导向应保留，没必要软重新导向。-- 2021年1月31日 (日) 03:56 (UTC)[回复]
或是透过JS小工具提示功能，让用户在非讨论页面中点击旧有连结时提示修改为新连结？--LuciferianThomas．留言 2021年1月31日 (日) 04:23 (UTC)[回复]
不必更动，英语维基百科部分MOS也有用WP的捷径。--台湾杉在此发言 (会客室) 2021年1月31日 (日) 04:32 (UTC)[回复]
好的，那么就舍弃软重定向，只重新议论MOS的捷径名称。--LuciferianThomas．留言 2021年1月31日 (日) 04:52 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

技术问题处理

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

命名空间侦测模板以及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)[回复]
建立预设启用/默认启用的小工具来呈现伪名字空间介面
还有个小建议：当处于移动视图时，不必在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)[回复]
完成@AnYiLin：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)[回复]
(※)注意：为免混淆WP:伪名字空间原有内容移动至WP:PNS+，并改为指向WP:捷径#伪命名空间使其等价WP:伪命名空间的重定向。--LuciferianThomas．留言 2021年2月5日 (五) 06:21 (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)[回复]
完成：已通过并布署。-- 五岁抬头雪菲（☎️·☘️） 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)[回复]
建议用滥用过滤器阻止非自动确认用户编辑，配以相关警告。--YFdyh000（留言） 2021年2月2日 (二) 13:07 (UTC)[回复]

提议设立快速删除标准 O8

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
现行条文

(无)

提议条文

O8. 在伪命名空间中建立的非重新导向页面。

伪命名空间仅能用于重新导向。如可以移动到合适的名称，请将页面移动到合适的名称，否则请使用此款快速删除。若页面明显是一个条目，则不适用此款快速删除。
  • 使用模板{{d|O8}}。

根据上述讨论，伪命名空间应仅能是重定向页。位于伪命名空间中的非重定向页应可被快速删除。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月1日 (一) 09:53 (UTC)[回复]

(＋)支持，若有条目真的需要以伪命名空间占用条目前缀，使用全形冒号而非半形冒号以辨别即可，此可避免之前有用户担忧会占用主空间条目名的情况。另外，我本来是在想可以把这条同时套用于不当使用伪命名空间重定向至其他页面，但想起有个别属于格式手册的论述其实不在Wikipedia:格式手册/前缀（WP:SAL），所以暂时作罢。--LuciferianThomas．留言 2021年2月1日 (一) 11:12 (UTC)[回复]
@LuciferianThomas：使用全形冒号，极有可能违反命名常规。-- 2021年2月2日 (二) 05:46 (UTC)[回复]
未见命名常规有不能用全形冒号的规则。若以与事物本身名称不同说违反常规，可按照其他命名技术限制做法，不加冒号或改用全形冒号，并以{{Wrongtitle}}标记即可。--LuciferianThomas．留言 2021年2月2日 (二) 05:52 (UTC)[回复]
@LuciferianThomas：名从主人，这就是有使用者担忧会占用主空间条目名的情况，也有像en:Gadget:Invention, Travel, & Adventure类似的情况。-- 2021年2月2日 (二) 06:04 (UTC)[回复]
可直接按照该情况处理，若通过则当作技术限制即可。用{{DISPLAYTITLE}}修正亦可。--LuciferianThomas．留言 2021年2月2日 (二) 06:21 (UTC)[回复]
这理论上可以出现在任何命名空间的情况，故按照命名空间一般处理方式即可。--LuciferianThomas．留言 2021年2月2日 (二) 06:24 (UTC)[回复]
很抱歉，{{DISPLAYTITLE}}需使用全名，少一个冒号就不会变更显示。-- 2021年2月2日 (二) 06:33 (UTC)[回复]
(＋)支持。--忒有钱🌊塩水あります🐳（留言） 2021年2月1日 (一) 15:20 (UTC)[回复]
为何不是移动到合适的名称？例如在LTA:误建LTA页面应该移动到WP空间后，让原先页面成为重新导向之类的。--Xiplus#Talk 2021年2月2日 (二) 05:53 (UTC)[回复]
若果明显属于错误建立有关专题页面的当然可以移动，这里应该是指创建与该专题无关的页面。--LuciferianThomas．留言 2021年2月2日 (二) 06:01 (UTC)[回复]
那就要写清楚，避免被提快速删除后，管理员未注意直接删除。-- 2021年2月2日 (二) 06:07 (UTC)[回复]
(！)意见：伪命名空间的设立理应是用作指向比较复杂的Wikipedia命名空间项目，不应用以指向其他无关条目，或许可以增加删除“非指向维基百科命名空间的重定向”条款？理论上伪命名空间属于WP空间的延伸，不应该出现指向WP以外的伪命名空间，其他命名空间有自己的命名空间别称，不会使用伪命名空间捷径。未来倘若通过将部分项目升格命名空间，但该项目本身有伪命名空间捷径，该等捷径理应全数自动纳入新命名空间而不会保留于主命名空间，不会影响此规则。--LuciferianThomas．留言 2021年2月2日 (二) 06:12 (UTC)[回复]
呃忘了有几条MOS在PJ空间。--LuciferianThomas．留言 2021年2月3日 (三) 08:48 (UTC)[回复]
还有这种事？！-- Sunny00217  2021年2月3日 (三) 09:18 (UTC)[回复]
有啊，专题的条目指引有几条跟随专题搬过去了。列表有写。也有疑似专题移了但分页未移的馀孽，但迟早都要搬过去吧。--LuciferianThomas．留言 2021年2月3日 (三) 11:10 (UTC)[回复]
§ 第二阶段：转移至新名字空间在讨论这类MOS的更名，很快就能解决。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月4日 (四) 11:18 (UTC)[回复]
加了附加条件之后让我觉得这个准则永远不会被使用，无论是什么内容都应该根据内容来移动到新名称，若是破坏也可用现存的G3等删除。--Xiplus#Talk 2021年2月3日 (三) 13:59 (UTC)[回复]
至少这也能成为移动操作的依据。快速删除方针的应用有时并不限于快速删除本身。SANMOSA SPQR 2021年2月17日 (三) 15:06 (UTC)[回复]
Module:Template:Delete/data模组的对应修改见User:Sanmosa/O8模组。SANMOSA Σουέζ 2021年4月17日 (六) 04:32 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

将LTA空间设定为noindex

认为LTA空间应设定为noindex 避免搜寻引擎索引。 具体的作法可建立专用于标记伪名字空间的模板，在模板内用{{Namespace_detect}}判断是否为LTA空间，加入noindex 魔术字。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月3日 (三) 13:43 (UTC)[回复]

条目空间中无法使用noindex魔术字。--Xiplus#Talk 2021年2月3日 (三) 13:54 (UTC)[回复]
@Xiplus：意思说部分维护模板的设定是设定辛酸的？！-- Sunny00217  2021年2月3日 (三) 14:54 (UTC)[回复]
@羊羊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)[回复]
从语法看可以。--YFdyh000（留言） 2021年3月3日 (三) 15:22 (UTC)[回复]
以往phab有修改此部分的先例吗?-- 五岁抬头雪菲（☎️·☘️） 2021年3月17日 (三) 06:42 (UTC)[回复]
如果没有的话，我认为很难实行。-- 五岁抬头雪菲（☎️·☘️） 2021年3月31日 (三) 06:51 (UTC)[回复]
实测上Google应没有对重新导向进行索引（例如搜寻"LTA:苏俞安"找不到该重新导向或是目标页面），所以我们应没必要再对其标记NOINDEX。--Xiplus#Talk 2021年3月31日 (三) 08:55 (UTC)[回复]
Google搜寻重新导向时会显示目标页的内容，即会有一行“（重新导向自）”，请见[4]，但是不影响伪命名空间。-- 2021年4月5日 (一) 07:29 (UTC)[回复]
google:detache出现了一个到https://en.wikipedia.org/?title=Detach%C3%A9&redirect=no的搜索结果。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月11日 (日) 14:31 (UTC)[回复]
这个不像是主动收录的网址，而且有设定canonical，理应不会收录这个重定向。--Xiplus#Talk 2021年4月14日 (三) 05:32 (UTC)[回复]

本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到部署完成。欲让机器人存档，请移除本模板。留言请置于本模板上方。

WP:捷径指引草案修订

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:捷径、Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间（错误：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向页面）。

[编辑此导航模板]

说明

捷径指引草案的讨论，源自于“伪命名空间”的讨论，英语维基百科对于捷径相关的规范及伪命名空间的设立已有成熟的执行方式。中文维基百科中的部分编辑者对于“格式手册”、“长期破坏者”及“专题”这三个主题提出可升级成命名空间或以伪命名空间形式存在，并有正反两方的陈述与看法。

目前较为接近共识的是“专题”提升为正式命名空间，反对者的论述已由支持者回应，且反方无进一步论述。然为求慎重，且将捷径与命名空间等议题作系统性讨论，将会执行阶段修订，以取得最大共识。

本讨论的各阶段分为：

  1. 专题提升为命名空间与否及其细节（phab:T271612）；
  2. 格式手册及长期破坏者是否成为命名空间或伪命名空间；
  3. 伪命名空间规范写入捷径规范内（如前项通过）或是否允许伪命名空间（如前项不通过）；
  4. 捷径规范细部讨论并决定是否成为指引。

各阶段不得同时讨论，前一项讨论完结之后，才能进行下一段讨论。台湾杉在此发言 (会客室) 2020年12月10日 (四) 05:47 (UTC)[回复]

专题命名空间通过，剩馀细节独立讨论。台湾杉在此发言 (会客室) 2021年1月11日 (一) 11:20 (UTC)[回复]
伪命名空间和专题空间都设立了。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:21 (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年3月24日 (三) 05:55 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

捷径细部修订

本案进入倒数第二个部分，捷径细节修订。目前伪命名空间部分已成为指引，其馀部分仍须修订。

在上次讨论当中，有提及中文捷径等相关问题，欢迎进一步讨论。台湾杉在此发言 (会客室) 2021年1月31日 (日) 07:42 (UTC)[回复]

首段建议附加维基专题空间，他们会稍后设立捷径。--LuciferianThomas．留言 2021年2月6日 (六) 04:03 (UTC)[回复]
(：)回应Wikipedia:互助客栈/方针#第五阶段：讨论重新导向与捷径的设立方式讨论已开始。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:51 (UTC)[回复]
@Taiwania Justo？--LuciferianThomas．留言 2021年2月21日 (日) 00:13 (UTC)[回复]
目前在忙著RFC以及其他现实生活事务，且目前还有残馀议案等待处理，待完全告一段落后再行整理该案。--台湾杉在此发言 (会客室) 2021年2月21日 (日) 03:46 (UTC)[回复]
不急，因为#第五阶段：讨论重新导向与捷径的设立方式也还在讨论。-- 五岁抬头雪菲（☎️·☘️） 2021年3月17日 (三) 06:43 (UTC)[回复]
上述第五阶段将会在适当的时机公示。-- 五岁抬头雪菲（☎️·☘️） 2021年3月31日 (三) 06:50 (UTC)[回复]
上述第五阶段已开始公示。-- 五岁抬头雪菲（☎️·☘️） 2021年4月14日 (三) 03:45 (UTC)[回复]

有关某年代相关分类命名统一事宜

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:分类名称。

最近Jarodalien对某年代相关分类进行了大规模的重新命名工作（将“XXXX年代”重新命名为“YY世纪YY年代”、将“建立”重新命名为“创立”），并声称其理由为“先到先得”，然而“先到先得”并不适用于非条目页面。我曾就部分分类的拟议重新命名（移动请求）进行反对，然而被其无视，其不但无视反对意见照样进行移动操作，更反过来诬指我取消重新命名的操作为“破坏”，更牵连到其他本与相关移动请求不相关的分类。在其进行大规模的重新命名工作后，我收到部分用户反映其重新命名工作导致部分由模板自动产生的分类出错，可见其大规模的重新命名工作轻率且窒碍模板维护，构成破坏。请管理员尽快回退其移动操作，并以一切可行的办法阻止其继续进行相关破坏性移动。SANMOSA 誓山海而长在，似日月而无休 2021年2月25日 (四) 10:54 (UTC)[回复]

@AT。SANMOSA 誓山海而长在，似日月而无休 2021年2月25日 (四) 10:54 (UTC)[回复]
@Iokseng。SANMOSA 誓山海而长在，似日月而无休 2021年2月25日 (四) 10:56 (UTC)[回复]
我建议通报至管理员布告版。--AT 2021年2月25日 (四) 10:58 (UTC)[回复]
@AT：WP:AIV提报过了，但当时我未收到部分用户对于其重新命名工作导致部分由模板自动产生的分类出错的反映。我觉得至少也得把他做的移动操作全数回退，这比较急。SANMOSA 誓山海而长在，似日月而无休 2021年2月25日 (四) 11:00 (UTC)[回复]
@Jarodalien：请参与讨论，不然我会考虑禁制您编辑分类空间。谢谢。--AT 2021年2月25日 (四) 11:15 (UTC)[回复]
正在回退一部分他移动过的分类，但数量有点多，我移不完。SANMOSA 誓山海而长在，似日月而无休 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)[回复]
命名常规只规范条目、不规范分类，自然不适用“先到先得”，不要把你自己当成方针。分类的命名看的是更宏观的其他东西。SANMOSA 誓山海而长在，似日月而无休 2021年2月25日 (四) 15:42 (UTC)[回复]
不允许反过来吗。前后极其相似或许先到先得（因为没必要改、WP:OWN），改变命名方式已经不只是先到先得的范畴了。--YFdyh000（留言） 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)[回复]
我不同意“这个人一定不懂汉语”的论断，一时看得较快看错了所导致的误认是非常正常的事情。就此例而言，这是前述情况最为经典的例子。SANMOSA 誓山海而长在，似日月而无休 2021年2月25日 (四) 15:42 (UTC)[回复]
这是认知不广泛的“常识”（就像公元1年到公元前1年之间有几年，不一定有过半数人答对），有更清楚且简洁表达的情况下不应该改成更模糊、更容易出错的。--YFdyh000（留言） 2021年2月25日 (四) 16:00 (UTC)[回复]
@YFdyh000：所以说答案是空集，还是元素为“0年”的单元素集合？⋯⋯--洛普利宁 2021年2月26日 (五) 15:46 (UTC)[回复]
这不重要吧……我指看似常识的东西很多人并不清楚，如有没有公元0年，世纪怎么算，年代又怎么算。相比可能模糊但容易猜对的xxxx年代，双重模糊的xx世纪xx年代更难判断。--YFdyh000（留言） 2021年2月26日 (五) 16:01 (UTC)[回复]
@Jarodalien：无论如何，你进行的重新命名工作导致部分由模板自动产生的分类出错这一点是无庸置疑的，我认为你应该将先前所建立和重新命名的分类（包括但不限于某年代相关分类，我认为其他相关分类很可能也有同样情形）全部统一回模板自动产生的格式，否则这无庸置疑会严重影响模板维护工作。SANMOSA 誓山海而长在，似日月而无休 2021年2月25日 (四) 15:42 (UTC)[回复]
为免后患，我建议就各类页面（包括但不限于分类页）引入“命名一致性”的规定，以有效减少页面命名上的纷争，并便利维护。SANMOSA 誓山海而长在，似日月而无休 2021年2月25日 (四) 15:56 (UTC)[回复]
支持这个提议，而且可以把“年代分类”当作首要讨论对象，未来可以扩及其他分类原则。我支持“1950年代”这个写法，理由如下：
  1. 此次讨论显示“19世纪50年代”这个用法确实容易导致误判。
  2. “1950年代”写法较为简洁。
  3. 分类与主条目名称统一对读者来说最为便利，按照年代列表目前所有年代主条目都是采取“1950年代”这个写法。
  4. User:Sanmosa在上方已提及的分类维护问题。--回廊彼端（留言） 2021年3月6日 (六) 03:10 (UTC)[回复]
认真？“19世纪50年代”相等于“1850年代”，“20世纪50年代”才相等于“1950年代”。-游蛇脱壳/克劳棣 2021年2月26日 (五) 14:16 (UTC)[回复]
@Temp3600：想一下2000年是几世纪，称多少年代。以及Category:2000年代怎么整。--YFdyh000（留言） 2021年2月26日 (五) 14:20 (UTC)[回复]
似乎2000年是20世纪90年代（1991至2000年）的最后一年，以及2000年代（2000至2009年）的第一年⋯⋯像1世纪是1至100年，21世纪是2001年至2100年；而X世纪00年代是这个世纪的第一个十年。所以21世纪00年代是2001年至2010年，和2000年代严格来说还不是一个东西？PS：“21世纪00年代”和“21世纪10年代”怎么读？“二十一世纪零十年代”“二十一世纪一十年代”？--洛普利宁 2021年2月26日 (五) 15:10 (UTC)[回复]
这，尴尬了，我记成21世纪了 捂脸--YFdyh000（留言） 2021年2月26日 (五) 15:24 (UTC)[回复]
读作零零年代、一零年代，就像九零后、零零后。--YFdyh000（留言） 2021年2月26日 (五) 16:01 (UTC)[回复]
①“20世纪50年代”=“1950年代”=“1950年到1959年”，这应该比较没有争议；②但如您所举例，遇到100的倍数就麻烦了；③“20世纪50年代”、“21世纪00年代”、“21世纪10年代”我会分别读“二十世纪五零年代”、“二十一世纪零零年代”、“二十一世纪一零年代”，至于别人怎么读，我就不知道了。-游蛇脱壳/克劳棣 2021年2月26日 (五) 16:15 (UTC)[回复]
00和10以外的年代，我大概会读作“__十年代”，读法上没问题。--YFdyh000（留言） 2021年2月26日 (五) 21:01 (UTC)[回复]
@@YFdyh000：说到年代的是，请教大家一个问题，最近我都不太用维基百科了，今天我在找资料时发现有条目里面原有年代的部分被删除了，查了查是有编辑者删除了，可能他认为那是考古专家学者考据的年代，不是当时人写下的年代，譬如，古埃及第三xxx王朝约西元前xxx年-西元前xxx年，所以编辑者把年代删除在内容改成不知道，现在可以这样吗？><?我怕搞不清楚状况所以问问。--User:浪子鱼|爱偷懒的鱼🐠※User talk:浪子鱼|留言 2021年2月26日 (五) 16:43 (UTC) ──以上未签名的留言由浪子鱼（讨论｜贡献）加入。
@浪子魚：不太清楚您的意思，是条目内容还是分类，年代与条目主题的关系。麻烦您将签名加上内部链接，不然别人不方便查阅和回复，您的ping也不会生效。--YFdyh000（留言） 2021年2月26日 (五) 21:01 (UTC)[回复]
@YFdyh000：好，谢谢你告诉我浪子鱼（留言） 2021年3月9日 (二) 07:12 (UTC)[回复]

针对性决议

通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
我这里的建议是：为便利分类维护，并避免由模板自动产生的分类出错，当将所有以“YY世纪YY年代”格式命名的分类重新命名为“XXXX年代”格式、将所有以“创立”格式命名的分类重新命名为“建立”格式。页面命名一致性的通用（普遍性）条文会稍后草拟，针对性的决议应该先通过。SANMOSA 江南好，风景旧曾谙 2021年3月15日 (一) 08:18 (UTC)[回复]
现公示以下针对性决议7日：将所有以“YY世纪YY年代”格式命名的分类重新命名为“XXXX年代”格式、将所有以“创立”格式命名的分类重新命名为“建立”格式。SANMOSA 江南好，风景旧曾谙 2021年3月22日 (一) 10:15 (UTC)[回复]
(＋)赞成--YFdyh000（留言） 2021年3月22日 (一) 11:06 (UTC)[回复]
前者同意，以便于维护，减少因格式之混杂不一所造成的分类维护困难；但后者则建议以既有母分类（诸如“各年建立的OOO”等，后续子分类一并以“建立的OOO”为原则）的命名格式为主，倘若尚无母分类者建议以“建立”为主要命名格式。--Steven |_-｡) 2021年3月23日 (二) 14:52 (UTC)[回复]
两者皆赞成，理由如下：
XXXX年代部分－
  1. 以上讨论显示“19世纪50年代”这个用法容易误判。
  2. “1950年代”写法较为简洁。
  3. 分类与主条目名称统一对读者来说最为便利，按照年代列表目前所有年代主条目都是采取“1950年代”这个写法。
  4. User:Sanmosa在上方已提及的分类维护问题
建立部分－
  1. 以“创立”为名的分类数量明显少于以“建立”为名的分类。--回廊彼端（留言） 2021年3月23日 (二) 15:15 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
@YFdyh000、StevenK234、迴廊彼端：决议已通过。名为“创立”的分类已经全部处理。以“YY世纪YY年代”格式命名的分类太多，未能全部重新命名，暂时只处理了“19世纪00年代”、“19世纪10年代”、“21世纪10年代”、“21世纪20年代”和整个18世纪，其他可能需要请求bot，或靠各位的帮助自行移动，我会尝试移动一部分。移动理由应使用“Special:diff/64972159决议通过统一命名格式”。SANMOSA Σουέζ 2021年3月29日 (一) 09:28 (UTC)[回复]

页面命名一致性的通用（普遍性）条文

暂时不太想得到该怎样写。我可能要再看一看英文维基百科的对应规定，7日内应该能够写好。各位如果有其他的草案提议，也可以直接提。SANMOSA Σουέζ 2021年3月29日 (一) 11:35 (UTC)[回复]

  • 引入一致性之后，一致性和常用（同主条目一致=主条目命名时的常用）会有冲突的问题。 --达师 - 370 - 608 2021年4月13日 (二) 16:37 (UTC)[回复]
    如果是说条目的话，确然，因此若确立命名一致性规定，可能需要就个别条目的命名再进行讨论，但实际操作上通常会依照主条目常用名作命名一致性处理，因此发生冲突的机会可能没想像中大。如果是说条目以外的页面的话（我会将对条目以外的页面的规定分开处理，不放入命名常规），则未必。SANMOSA Σουέζ 2021年4月14日 (三) 13:14 (UTC)[回复]
暂时有这个条文草稿：
  • 就其他非条目页面命名（另开页面）：
  1. ^ 1.0 1.1 1.2 使用地区词处理至一致也算作一致。

以上。@hat600、Milkypine、YFdyh000。SANMOSA Σουέζ 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:命名常规 (音乐)

希望各位可以给点意见，协助改善该命名常规@Ohtashinichiro、和平至上、Leehsiao、Sanmosa、Tombus20032000、百战天虫、Kriz Ju、生米一粒、Pseudo Classes、KodokunaSmile、Easterlies、AT、卡達、Yumeto、SickManWP、羊羊32521、EdwardAlexanderCrowley、Zhaoweizhi0325、MoonLight3650、HXXXX、Punkhippie、Louis0921gee、Peace 621、Whykitty、Moonshimmer93、夜来南风起、Fake12345：。 --无心*插柳*柳橙汁 2021年3月15日 (一) 06:12 (UTC)[回复]

提示：阁下该次ping操作没有一个人会收到，因为您一次性同时ping了超过五十人。--Milky·Defer 2021年3月14日 (日) 20:08 (UTC)[回复]
@MilkyDefer：(´_ゝ`)你没提，我都忘了我人数超标了。 --无心*插柳*柳橙汁 2021年3月15日 (一) 06:13 (UTC)[回复]
我有ping到人吗？@TreasureBabe325、Hijk910、Jacklamf1d14、Ericliu1912、Naverad、Softyu、Sammypan、Tw drama、Shingkei、李新阳、CHih-See Hsie、Pv163、JoJo_append、Lopullinen、AnYiLin、Yel D'ohan、Temp3600、Bigbullfrog1996、陳寅恪、Tenhumantenok、Prince of Erebor、K.Y.K.Z.K.、Arivgao、FredYYoo、Apple v、Tfcheng5597、Comrade John、Adsa562、Austin Zhang、MoonLight3650、Gracelllee、Shwangtianyuan： --无心*插柳*柳橙汁 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)[回复]
  1. 四季 (单曲)
  2. Gravity (LUNA SEA单曲)
  3. CLEAR (坂本真绫单曲)
  4. 矛盾心理 (榉坂46单曲)
  5. Lemon (米津玄师单曲)
个人观点来说，保留单曲的程度是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日 (三) 23:56 (UTC)[回复]

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

@Ohtashinichiro、和平至上、Leehsiao、Sanmosa、Tombus20032000、百战天虫、Kriz Ju、生米一粒、Pseudo Classes、KodokunaSmile、Easterlies、AT、卡達、Yumeto、SickManWP、羊羊32521、EdwardAlexanderCrowley、Zhaoweizhi0325、MoonLight3650、HXXXX、Punkhippie、Louis0921gee、Peace 621、Whykitty、Moonshimmer93、夜来南风起、Fake12345、TreasureBabe325、Hijk910、Jacklamf1d14、Ericliu1912、Naverad、Softyu、Sammypan、Tw drama：感谢大家的意见回馈，自3/14以来，本指引更新下列内容，欢迎大家查阅。 --无心*插柳*柳橙汁 2021年3月25日 (四) 05:33 (UTC)[回复]

  1. “古典音乐作品”叙述修正
  2. “使用中文”内容增加
  3. “外文规范”内容增加
  4. “括号的使用”修改为“符号使用”，并增加“斜线”、“书名号”和“特殊符号”的说明与范例。
  5. “消歧义”内容增加
  6. “注释”叙述修正
@Shingkei、Hikki、李新阳、CHih-See Hsie、Pv163、JoJo_append、Lopullinen、AnYiLin、Yel D'ohan、Temp3600、Bigbullfrog1996、陳寅恪、Tenhumantenok、Prince of Erebor、K.Y.K.Z.K.、Arivgao、FredYYoo、Apple v、Tfcheng5597、Comrade John、Adsa562、Austin Zhang、Gracelllee、Shwangtianyuan、星巴克女王、金善賢、老奋、Lilychen1388、Drippinpunch：由于人数众多，这边分开ping相关讨论用户。 --无心*插柳*柳橙汁 2021年3月25日 (四) 05:42 (UTC)[回复]
@Milkypine：“对序号是10（不含）以上的作品，‘号’字省略”是此类音乐作品的常用名称的做法吗？SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 09:57 (UTC)[回复]
@Sanmosa：古典音乐的部分主要根据User:Anakharsis/沙盒#建立条目编写，至于是否为此类音乐作品的常用名称做法...这部分需要古典音乐的编辑来回答（技术上来讲我会写原声带但不等于我熟悉古典音乐）。 --无心*插柳*柳橙汁 2021年3月26日 (五) 12:41 (UTC)[回复]
@Milkypine：我看了一下应该是对现行做法的总结。然而，我也看过了来源一下，似乎即使号码大过10，加“号”字还是比较常见。我建议基于常用名称的原则，将‘序号使用阿拉伯数字，前面有“第”字；作曲家名字放在半角括号内，括号之前有一个半角空格。对序号是10（不含）以上的作品，“号”字省略’的规则改为‘序号使用阿拉伯数字，前面有“第”字，后面有“号”字；作曲家名字放在半角括号内，括号之前有一个半角空格’。SANMOSA 江南好，风景旧曾谙 2021年3月27日 (六) 05:28 (UTC)[回复]
有关“号”的问题，综观惯常一般音乐会场刊的处理，通常都没有特意加上“号”的，但本人自最初编写萧士达高维契交响曲时，经观察和有前人提醒过名称上要加上“号”，所以才不论第1还是第15都有加上“号”，且也觉得没有问题，至于“超过10就不用加号”的说法，倒没有听过，不过User:Sanmosa建议不论序号，统一采用“第X号○○○ (某某)”的写法，个人表示认同和支持。-Foamposite（留言） 2021年3月27日 (六) 07:40 (UTC)[回复]
@Iokseng、Anakharsis：两位的看法如何？ --无心*插柳*柳橙汁 2021年3月28日 (日) 03:29 (UTC)[回复]
  • 我不知道现在还可不可以为这个讨论作出贡献。我主要编辑古典音乐这方面，所以以下是我对于该方面的浅见：
1）我注意到大家关于“号”的讨论，我赞成“第”后面加“号”，不需要去管超过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)[回复]
对于李新阳其它几点内容：
  1. 见上。
  2. “（贝多芬作品）”不在条目名称里，这个括号只是解释说明作用，没什么关系[5]。但是个人觉得这一条有点问题，可能有不止一个作曲家的降E大调弦乐五重奏序号不详、有争议或无可靠来源使用，建议改成：调性优先，若无须消歧义，作曲家名字可以省略。
  3. 调性的问题。我认为应该用汉字“升”和“降”。至于字母大小写，我觉得争议出在小调上。英维古典音乐专题的Guidelines有说，大意是D小调可以简写为d调，但不能写d小调这种缝合怪。[6]然而我能看到的来源，（作品名还有行文）D小调和d小调都有，甚至感觉d小调更多。我觉得还是按中文习惯，大调大写，小调小写。
  4. 建议改成：如果该作品的名称是独一无二的，且无须消歧义，则作曲家名字也可以省略。
  5. 我觉得应该不是问题，第一条解决的就是通用情况。
以上。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 06:02 (UTC)[回复]
感谢羊羊对于关于大小调的叙述，我支持进行“大调大写，小调小写”的方式，合乎乐理，然后使用汉语表示升降号，以及新增关于“且无须消歧义”的条文。--李新阳（留言） 2021年3月29日 (一) 08:11 (UTC)[回复]
我自己反而是没看过“小调小写”的处理。SANMOSA Σουέζ 2021年3月29日 (一) 09:01 (UTC)[回复]
那这样D小调不就需要...。 --Loving You Is A Losing Game 2021年3月29日 (一) 13:55 (UTC)[回复]
严格意义上来说，在乐理的学习和考试中以及大多数的实践中，都应当使用“大调大写，小调小写”的原则，这样合乎规范也严谨一些。您提到的D小调是一个很好的且应该进行改正的例子。--李新阳（留言） 2021年3月30日 (二) 05:36 (UTC)[回复]
我理解现在的许多音乐会，新闻或者乐评不强求或者不讲究这个，因为往往来说观众都更在意“大调”还是“小调”而非“大写”还是“小写”这样的“技术性问题”。我个人认为为了避免歧义，应当遵循“大调大写，小调小写”的原则。--李新阳（留言） 2021年3月30日 (二) 05:43 (UTC)[回复]
同意，我在音乐系学习时，按西方惯常命名时，大调用大写，小调用小写是不成名做法，这个和乐理和声学有关，当然用在普及化的层面来说，大小写的意义不大，对此我觉得在维基内可以因着便利性而不执行大小写的做法，至于“降号”和“升号”，由于真正的写法和“#”及“b”有别，涉及要用音乐符号模版，我倾向都是用文字表述为佳。--Foamposite（留言） 2021年4月2日 (五) 12:32 (UTC)[回复]
(！)意见：命名中几乎遇不到小调大小写的情况，不属于命名常规讨论范畴，建议拆分为新讨论。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年3月31日 (三) 06:08 (UTC)[回复]
进行拆分的话倒是没有任何问题，我主要是看到了“降E大调弦乐五重奏”这个玩意儿，认为应当讨论一下大小写的问题。我现在发现了一个新东西，就是这个夜曲Op. 9 (萧邦)以及前奏曲Op.28, No. 15 (萧邦)，我们可能需要引入一个新的话题，即Op和No的问题。我建议翻译出来比较好，要不然看这很别扭。--李新阳（留言） 2021年3月31日 (三) 06:59 (UTC)[回复]
夜曲 (肖邦第9号作品)？前奏曲 (肖邦第28号作品第15首)？太难看了……我觉得这些小问题还是不要讨论了吧，讨论是讨论不完的……你看看英维的音乐命名常规，古典音乐写了多长…… ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月1日 (四) 05:13 (UTC)[回复]
补了个签名 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 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更新报告

@Ohtashinichiro、和平至上、Leehsiao、Sanmosa、Tombus20032000、百战天虫、Kriz Ju、生米一粒、Pseudo Classes、KodokunaSmile、Easterlies、AT、卡達、Yumeto、SickManWP、羊羊32521、EdwardAlexanderCrowley、Zhaoweizhi0325、MoonLight3650、HXXXX、Punkhippie、Louis0921gee、Peace 621、Whykitty、Moonshimmer93、夜来南风起、Fake12345、TreasureBabe325、Hijk910、Jacklamf1d14、Ericliu1912、Naverad、Softyu、Sammypan、Tw drama：感谢大家的意见回馈，这次根据上次1.0的讨论修改古典音乐，并增加“ (单曲专辑)”的消歧义。欢迎大家查阅。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:04 (UTC)[回复]

@Shingkei、Hikki、李新阳、CHih-See Hsie、Pv163、JoJo_append、Lopullinen、AnYiLin、Yel D'ohan、Temp3600、Bigbullfrog1996、陳寅恪、Tenhumantenok、Prince of Erebor、K.Y.K.Z.K.、Arivgao、FredYYoo、Apple v、Tfcheng5597、Comrade John、Adsa562、Austin Zhang、Gracelllee、Shwangtianyuan、星巴克女王、金善賢、老奋、Lilychen1388、Drippinpunch、Kuliv、Lienwingyan：由于人数众多，这边分开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小调”。

例：降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:命名常规 (音乐)公示

@Ohtashinichiro、和平至上、Leehsiao、Sanmosa、Tombus20032000、百战天虫、Kriz Ju、生米一粒、Pseudo Classes、KodokunaSmile、Easterlies、AT、卡達、Yumeto、SickManWP、羊羊32521、EdwardAlexanderCrowley、Zhaoweizhi0325、MoonLight3650、HXXXX、Punkhippie、Louis0921gee、Peace 621、Whykitty、Moonshimmer93、夜来南风起、Fake12345、TreasureBabe325、Hijk910、Jacklamf1d14、Ericliu1912、Naverad、Softyu、Sammypan、Tw drama：感谢大家的意见，现将Wikipedia:命名常规 (音乐)公示。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:36 (UTC)[回复]

@Shingkei、Hikki、李新阳、CHih-See Hsie、Pv163、JoJo_append、Lopullinen、AnYiLin、Yel D'ohan、Temp3600、Bigbullfrog1996、陳寅恪、Tenhumantenok、Prince of Erebor、K.Y.K.Z.K.、Arivgao、FredYYoo、Apple v、Tfcheng5597、Comrade John、Adsa562、Austin Zhang、Gracelllee、Shwangtianyuan、星巴克女王、金善賢、老奋、Lilychen1388、Drippinpunch、Kuliv、Lienwingyan、Bbene98、Paristung、Joshua Zhan、Achanhk：由于人数众多，这边分开ping相关讨论用户。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:39 (UTC)[回复]
  • (？)疑问@Milkypine：看完整体草案，有疑惑的是“对于官方没有给出罗马化名称的日文作品，根据平文式罗马字罗马化。”这条，特别指的是日本作品，那么韩国作品有必要依照马科恩-赖肖尔表记法将韩文转换成罗马字？若有的话，以“보라빛 밤”为例，是要以罗马字呈现的英文“Pporappippam”为条目名称，还是按照过去以编者翻译先到先得、名从主人所相辅相成的WP:NAME规范，维持“紫光夜”的条目名称？--🍫巧克力～✿ 2021年4月20日 (二) 07:46 (UTC)[回复]

参考资料

  1. ^ 英维古典音乐专题的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).
  2. ^ 纪念古斯塔夫·马勒逝世110周年系列音乐会之二. [2021-03-28]. 
  3. ^ 【海神家族與馬勒巨人】簡文彬與國臺交將以音樂帶您感受作曲家與文學家筆下的深刻情感. [2021-03-28]. 
  4. ^ 贝多芬的第五号交响曲. 
  5. ^ 理论上在正文出现的括号应该用全角，哈哈
  6. ^ 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日。公示期间若无合理异议，作通过论，若有新合理意见，应经协商解决问题。

参考资料

  1. ^ 不对提案进行实则性点评的支持意见，以及与提案本身无关的意见，皆不视作此条文所指的“新留言”。

以上。SANMOSA 江南好，风景旧曾谙 2021年3月14日 (日) 15:31 (UTC)[回复]

主要影响：
  1. 不对提案进行实则性点评的支持意见不造成重算7日。
  2. 与提案本身无关的意见不造成重算7日。
  3. 将浮动的时间范围“1个月”界定为固定的时间范围“28日”。
  4. 容许公示在有必要时可长于7日。
以上。SANMOSA 江南好，风景旧曾谙 2021年3月14日 (日) 15:36 (UTC)[回复]
(？)疑问：
  1. 原条文有“如果在互助客栈中被提出的提案”一句，在新条文要删去吗?
  2. 参阅Wikipedia:互助客栈/条目探讨#春晚及春晚 (消歧义)，这种在Wikipedia:互助客栈/条目探讨的提案是否需要遵守WP:7DAYS?或是要将WP:7DAYS限定在Wikipedia:互助客栈/方针?--CaryCheng（留言） 2021年3月15日 (一) 02:41 (UTC)[回复]
@CaryCheng：（1）漏留意，已补回。（2）理论上要遵从。SANMOSA 江南好，风景旧曾谙 2021年3月15日 (一) 05:53 (UTC)[回复]
@CaryCheng：就（2）作补充：我是说如果决定要进行公示的话，理论上要遵从WP:7DAYS，但是如果不涉及修改方针指引或修改高风险模板的话，一般性的争议解决讨论好像是不用进行公示的，基本上争议解决了就可以直接关。SANMOSA 江南好，风景旧曾谙 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日。SANMOSA 江南好，风景旧曾谙 2021年3月15日 (一) 05:53 (UTC)[回复]
(？)疑问:大致同意，而且也会看到这里用雪球快速公示，好像也没完全照规定走。但是这里有些疑问要问一下，如何界定“已取得共识”、“合理异议”，“合理意见”？合理异议、意见会不会变成两集团互斥对方不合理。只有一人提问，无人赞成、反对，算不算已取得共识，然后可以公示?这些提案人可以一并考虑，把规定写更好一些。--2001:B042:1:A9ED:F58C:12D4:4C7B:B776（留言） 2021年3月15日 (一) 06:32 (UTC)[回复]
（1）没人抓的话其实是没人会遵守这规定。（2）以前的人进行公示的时候都是说“现公示7日，无合理异议者即作通过”，跟以前的做法处理。（3）提案与现行办法对于“只有一人提问，无人赞成、反对”的提案的态度是原则上可以公示，这当然会产生一些奇怪的现象（当然如果提案人能够好好处理提问的话，我倒是觉得可以照样公示通过），先前讨论也谈论过，但没人管。SANMOSA 江南好，风景旧曾谙 2021年3月15日 (一) 07:54 (UTC)[回复]
回答的很完整。不缩小“无新留言”范围，结果时间等太久，没人抓大家就不走规定。不讨论“已达成共识”定义，结果“一人提问，无人赞成、反对”，反而7日后就可以公示。这是不见得会有问题，但又有一些奇特的现象。--2001:B042:1:ABD5:F58C:12D4:4C7B:B776（留言） 2021年3月15日 (一) 08:27 (UTC)[回复]
所以有时候我会抓一下7日的计算（虽然我自己也不满现在这规定）。如果“只有一人提问，无人赞成、反对”的提案出现的话，提案人能不能够好好处理提问是一个重点，如果不能的话，理论上可以抓“已取得共识”一条来说有程序性问题。SANMOSA 江南好，风景旧曾谙 2021年3月15日 (一) 08:42 (UTC)[回复]
(－)反对:重看了一下，注脚很有问题，而且只会增加争议，应删去。--虫虫飞♡♡→♡℃※留言 2021年3月15日 (一) 06:41 (UTC)[回复]
不同意。这是修订提案的主要目的之一。之前的讨论的主流意见都认同不应该使所有意见都能导致重算7日（我个人比较看重的是DrizzleD的意见）。我邀请一下之前参与过讨论的@KirkLU、DrizzleD、BureibuNeko、UjuiUjuMandan、Fire-and-Ice来好了。SANMOSA 江南好，风景旧曾谙 2021年3月15日 (一) 07:49 (UTC)[回复]
不是说增加争议就不好。举个简单例子，根据中华人民共和国刑法，故意杀人的，处死刑、无期徒刑或者十年以上有期徒刑；情节较轻的，处三年以上十年以下有期徒刑，显然在不少案件中具体判罚轻重会有“争议”，但为什么不干脆故意杀人的都处死刑呢？因为不同的案件真的不一样，不能统一判罚。这里类似，单纯支持也好，给建议也好，反对也好，无关意见也好，对共识形成的作用完全不同，却都能导致重算7日，这就背离了WP:7DAYS帮助确认共识的初衷。--DrizzleD (按此给我留言) 2021年3月15日 (一) 09:41 (UTC)[回复]
(？)异议:您误解了WP:7DAYS的初衷，当时AT就是为了解决在讨论不足的情况下，用户火速公示，然后强行通过提案的问题。原先是要30天后才公示，后来才七天后没有留言公示。七天算是合理时间，没必要再缩短，否则又会回到以前火速公示，强行通过提案的问题，然后争议不断，问题多多。而且现在WP:7DAYS未见有甚么问题，没必要再放寛。--虫虫飞♡♡→♡℃※留言 2021年3月15日 (一) 13:12 (UTC)[回复]
不不不，是您误解了我的意思，我说它帮助确认共识，意思是它告诉我们什么时候算是确认了共识，不是说它帮助加速通过提案。然后：1. 七天算是合理时间，没必要再缩短，我同意，但这个修正案完全没说要缩短七天这个时间，此说法和此修正案不相关 不相关。2. 又会回到以前火速公示，强行通过提案的问题，当然不，留言支持者越多，说明通过提案越不强行，而不是相反。 3. 而且现在WP:7DAYS未见有什么问题，这个我现在不太活跃确实不太清楚，但Sanmosa似乎能够确认如此，@Sanmosa可以来说说。--DrizzleD (按此给我留言) 2021年3月15日 (一) 13:47 (UTC)[回复]
（3）现成的问题。SANMOSA 江南好，风景旧曾谙 2021年3月16日 (二) 05:53 (UTC)[回复]
(※)注意:请看一下这个提案，有一大堆支持，也已经讨论了一个月，还是有人反对，当时也有人催快点公示，也有朋友对说我要快公示，怕夜长梦多，会出现(－)反对，但提案的目的是要寻求共识，而不是快快通过，然后出现争议，因此急于通过是不必要的，有共识的提案也不怕多放几天。--虫虫飞♡♡→♡℃※留言 2021年3月16日 (二) 06:13 (UTC)[回复]
你对互助客栈讨论的想法完全违背进行互助客栈讨论应有的健康心态。SANMOSA 江南好，风景旧曾谙 2021年3月16日 (二) 06:58 (UTC)[回复]
@蟲蟲飛：不吸烟也可能患肺癌，这不代表我们不用去倡导戒烟，关键是可能性。类似地，同样是暂时没有反对意见，一个有许多人支持的提案和一个没人理的提案，哪一个有潜在问题的可能性更大？这是不言自明的。
要解决所谓“已经讨论了一个月，还是有人反对”的问题，相关的方案是延长WP:7DAYS中7天或者是1个月的限制（当然可能会有一些别的问题），但这与本案无关。本案的要求是赞成或不相关的意见不影响时间（不管是7天还是什么其他时间）的重算。--DrizzleD (按此给我留言) 2021年3月17日 (三) 02:13 (UTC)[回复]
然而方针指引不能阻止任何用户发表不相关的意见。SANMOSA 江南好，风景旧曾谙 2021年3月17日 (三) 05:43 (UTC)[回复]
如何定义“不相关”？谁去决定？双方也可以互相指责对方的留言“不相关”，为甚么要令提案增加不必要的争议？AT现行版本是最好的，“七天没留言”是客观标准，没有争议空间。--虫虫飞♡♡→♡℃※留言 2021年3月17日 (三) 12:12 (UTC)[回复]
（1）依据“共识应当考虑到所有正当合理的意见”此条方针来定义。（2）最极端的情况就找行政员，天仍然不会因此塌下来。（3）极端严格的“7天没留言”是客观标准没错，然而违反常识、惯性、正常讨论生态和“共识应当考虑到所有正当合理的意见”此条方针。SANMOSA 江南好，风景旧曾谙 2021年3月17日 (三) 12:43 (UTC)[回复]
所以，这种提案还是，被改完的7days拦下吧？-- Sunny00217  2021年3月22日 (一) 16:25 (UTC)[回复]
从现存留言上来看，应该会，因为相邻两条有说理的评论之间均小于7天。当然，改了WP:7Days之后同时可能会促使反对的人更早留言，这就是另一回事了。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:27 (UTC)[回复]
@Sunny00217。SANMOSA 江南好，风景旧曾谙 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)[回复]
提案人有邀请讨论，我稍微简单说一下自己的浅见：
  1. 类似于“最后一天有编辑补了个‘支持’，结果导致要重新计算公示前的无留言时间”的情况客观存在；
  2. 个人是支持上例的这种问题能够更灵活化的处理（毕竟，表达一下支持，甚或——更宽泛一点——由于方针通过、问题解决的喜悦在讨论串下面开了个适当的玩笑，都不是什么不合理的事情；让这种表达起到延长公示前时间的效果，并非方针的本意，也一定程度上压抑了这种合理表达的机会——毕竟既然赞成提案，谁也不希望自己表达的支持反而造成了拖延的反效果）；
  3. 我能理解反对此种灵活化处理的编辑有种种疑虑，此种情况下不改变现有方针我觉得也是可以理解、认同；
  4. 但即使方针不变，只要翻看存档，就会发现此种灵活化处理在往例中比比皆是，在这些案例中大家某种程度上用一种“默示共识（或称沉默共识，或称通过不提出异议来支持）”的方式使得灵活化缩短时程得以实现；
  5. 也因此，如3，方针改不改在我看来也许真的问题不大（如果大家真的不期待太明确地以规则确认上述惯例，或至少有些编辑还对此存在很大疑虑，如3，我个人觉得也是能一定程度理解），只是希望即使不改方针，至少这种实践中自然而然的习惯不被刻意地挑战，只要大家觉得适当的情况，就可以稍微灵活一点。事实上，我觉得这也最大程度体现出维基的精神。
以上。--Kirk★ # 2021年3月15日 (一) 17:02 (UTC)[回复]
  • 您是忽略了修订版本中争议性的问题，因为如何定义“不相关”有时也有很大争议，否则之后提案又出现是否合法公示的问题，以前已经出现过很多次公示争议，不应加一个具争议性的注脚。我觉得AT现行版较佳，没有修改的必要。--虫虫飞♡♡→♡℃※留言 2021年3月17日 (三) 02:45 (UTC)[回复]
不如此修订的话，会对互助客栈的讨论生态造成严重扭曲。SANMOSA 江南好，风景旧曾谙 2021年3月17日 (三) 05:43 (UTC)[回复]
“讨论被扭曲”是您说的，不是事实。客栈的提案不是为了收集支持，而是看看有没有(－)反对，因为提案如果没有反对，公示后就可以通过，因此公示的过程就是要令提案收集更多的意见，而这七天已经是下限，没必要再缩减。--虫虫飞♡♡→♡℃※留言 2021年3月17日 (三) 12:08 (UTC)[回复]
DrizzleD的1和2已经驳斥了你上面声称的东西（这个修正案完全没说要缩短七天这个时间；留言支持者越多，说明通过提案越不强行，而不是相反）。SANMOSA 江南好，风景旧曾谙 2021年3月17日 (三) 12:14 (UTC)[回复]
那也要看回应的理据是否成立，不是回应了就算。我在上面还没看到有任何理据是成立。--虫虫飞♡♡→♡℃※留言 2021年3月17日 (三) 12:21 (UTC)[回复]
我真诚相信这是因为你中文理解能力有问题的缘故。换作任何其他一个人，他们都必定能够理解提案的原因，并认为其合理。SANMOSA 江南好，风景旧曾谙 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天没留言”规则会带来游戏规则的可操作性。SANMOSA 江南好，风景旧曾谙 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日了，结果就直接过了。SANMOSA 江南好，风景旧曾谙 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)[回复]
增加争议是有益的[来源请求]-- Sunny00217  2021年3月22日 (一) 16:34 (UTC)[回复]
论据已经写在上面（并已链接到）了。WP空间内容不是条目，来源不一定有必要，不然讨论没办法进行。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:43 (UTC)[回复]

调适案1

现行条文

为了确保所有使用者有充足的时间发表意见以及得悉改动，如果在互助客栈中被提出的提案在七天内没有新留言或至少讨论达一个月以上的情况下，只要取得共识便可公示，为期七天。公示期间若无异议，则提案算作通过；如果有新意见，请通过协商解决问题。存档后如果要重新提出公示的话，应同时补回相关讨论连结，以便社群查阅。

提议条文

为确保所有使用者有充足的时间发表意见及得悉改动，在互助客栈中被提出的提案若在7日内无新留言[1]，又或讨论已持续28日以上的情况下，只要讨论取得共识，即可公示，公示为期至少7日。公示期间若无异议，作通过论，若有新合理意见，应经协商解决问题。存档后如果要重新提出公示的话，应同时补回相关讨论连结，以便社群查阅。

参考资料

  1. ^ 不对提案进行任何点评的支持或中立意见，以及与提案本身无关的意见，皆不视作此条文所指的“新留言”。

我还是想做到一些东西，退而求其次一下好了。SANMOSA 江南好，风景旧曾谙 2021年3月25日 (四) 08:03 (UTC)[回复]

主要影响：
  1. 不对提案进行任何点评的支持或中立意见不造成重算7日。
  2. 与提案本身无关的意见不造成重算7日，而意见是否与提案有关根据《讨论页指引》的规定界定。
  3. 将浮动的时间范围“1个月”界定为固定的时间范围“28日”。（依旧）
  4. 容许公示在有必要时可长于7日。（依旧）
以上。SANMOSA 江南好，风景旧曾谙 2021年3月25日 (四) 08:09 (UTC)[回复]
(－)反对:理由同上，我还是觉得AT现行版本较佳，而且提案不但没有解决问题，而且注脚部分带出更多的公示争议。--虫虫飞♡♡→♡℃※留言 2021年3月26日 (五) 13:31 (UTC)[回复]
“不对提案进行任何点评的支持或中立意见”是很容易看出来的事情，多一句话就已经是“点评”了，非常明确，怎么可能“带出更多的公示争议”？《讨论页指引》的规定也应该很清楚明白吧，难道说《讨论页指引》也是形同虚设的？将浮动的时间范围界定为固定的时间范围也是明确指引的处理。修订容许公示时间可长于7日，但没容许可短于7日，因此公示时间上也不可能产生争议。综以上，我完全不认同调适案1“带出更多的公示争议”。SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 13:39 (UTC)[回复]
现在方针修改频繁，AT版七天已经算是很合理的时间，频繁的方针修订中，让社群有足够时间去消化，及让提案有足够时间收集更多意见是必须的。--虫虫飞♡♡→♡℃※留言 2021年3月26日 (五) 13:47 (UTC)[回复]
频繁的方针修订正是因为社群有迫切的需求，如果社群不理解方针修订的内容，理当向提案人发问（这样做无论是在原始提案下，抑或在调适案1下，都仍然会造成重算7日），我不明白社群怎么在遇到看不明白的事情都不会发问。一味压抑社群的迫切需求对社群而言并不健康，我仅是希望将equilibrium position稍稍推回到提案人一边一些而已。SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 14:07 (UTC)[回复]
像下方#交通关注度指引修订这样的方针修订，我是不见得需要多长的时间来“消化”。需要较长的时间来“消化”可能是像下方#分案1这样的方针修订，那为何不像MINQI这样去发问？这可能比自己自行“消化”提案内容来得更有效率，使自己更快清楚明白提案内容。SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 14:11 (UTC)[回复]
您搞错了两者因果关系，正因为修订频繁，提案更不应急于公示，应该收集更多意见，而不是火速公示，强行通过，然后有些用户来不及表达意见，结果争议不断。--虫虫飞♡♡→♡℃※留言 2021年3月26日 (五) 14:14 (UTC)[回复]
不，方针指引修订频繁是社群的迫切需求的结果。现行条文只是在无视社群实际存在的迫切需求，并将之强行压抑。社群的迫切需求是方针指引修订频繁的产出来源，应当做的是满足需求，而非压抑需求。再者，现实上方针指引修订频繁不可能等到所有人发表了意见才能处理，否则这就属于游戏共识形成程序的情形。SANMOSA 江南好，风景旧曾谙 2021年3月27日 (六) 10:36 (UTC)[回复]
@Sanmosa：不能认可方针的快速频繁修订（及提案和公示）。方针应该是总结归纳长久的共识，仅在争议严重时依充分讨论规定妥协方案（如COVID-19命名）。将未成熟的方针及公示作为约束或指导后续编辑的手段是不正确的，WP:BURO：“不是盲目跟随默认的方针和程序。要避免编写过分冗长的指示。”。应更多以讨论确认意见、指引，而非编立方针来不必要的规约。设立规则来制止他人反而会有GAME之嫌。--YFdyh000（留言） 2021年3月27日 (六) 12:16 (UTC)[回复]
既然社群存在如此的迫切需求，那相关的规约自然是必要的。必要性取决于需求。SANMOSA 江南好，风景旧曾谙 2021年3月27日 (六) 13:13 (UTC)[回复]
“迫切需求”是您的意见，不是社群，方针属于重大提案，应该让社群有足够时间消化及表达意见，千万不要心急，有共识的提案就不用怕多放几天有(－)反对，而且急于通过，火速公示，然后争议不断，那通过的提案也不是反映共识。--虫虫飞♡♡→♡℃※留言 2021年3月28日 (日) 04:54 (UTC)[回复]
方针快速频繁修订是个问题，但如果真的要修订，这里的关注点是，单纯支持之意见不该导致重算。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:53 (UTC)[回复]
要说多少遍本提案和“七天”没有任何关系。实话说，您要是觉得时间短，延长到十天我也没意见，但“不对提案进行任何点评的支持或中立意见”能导致重算，究竟合理吗？--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:50 (UTC)[回复]
说到这个，为了拯救陷入同义反复的讨论，我决定提出一个新想法，看看能不能抛砖引玉。改成：
为确保所有使用者有充足的时间发表意见及得悉改动，在互助客栈中被提出的提案若在10日内无新留言[1]，又或讨论已持续28日以上的情况下，只要讨论取得共识，即可公示，公示为期至少7日。公示期间若无异议，作通过论，若有新合理意见，应经协商解决问题。存档后如果要重新提出公示的话，应同时补回相关讨论连结，以便社群查阅。

参考资料

  1. ^ 不对提案进行任何点评的支持或中立意见，以及与提案本身无关的意见，皆不视作此条文所指的“新留言”。
即额外把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日已经是很大的让步了。SANMOSA ······ 2021年3月28日 (日) 23:51 (UTC)[回复]
  • 您有所不知，客栈的提案不是收集支持或中立，而是看看有没有(－)反对，因为提案放出来，七天完全没有留言，已经可以公示，公示后，没异议就通过，其他维基也是一样，因此提案的反对意见比支持的意见重要。而且，“七天没留言”在维基可视为默认共识，见WP:TALKDONTREVERT：“假如编者已停止在讨论页内回复相关讨论，便可以假定共识已经形成。”--虫虫飞♡♡→♡℃※留言 2021年3月29日 (一) 06:30 (UTC)[回复]
    如果相关支持意见或中立意见里面有其他建设性的提议的话，那些意见和反对意见是同等重要的，然而现行条文有可能阻碍相关附有有其他建设性的提议的话支持意见或中立意见的表达。SANMOSA ······ 2021年3月29日 (一) 06:36 (UTC)[回复]
所以我希望最后的共识能确立该条条文以我上方的解读为准。SANMOSA ······ 2021年3月29日 (一) 06:36 (UTC)[回复]
我请你重看我的调适案1，我的调适案1完全无提及过“有建设性的意见”，我不知道你是从哪里看到的，还是你不小心看到了甚么一般人看不到的东西。如果你是从我上面的留言看到的话，那我只能够说你真的没有一般人应有阅读中文的能力，我说的是现行的条文让人不愿意留下附有其他建设性的提议的支持意见或中立意见，而不是直接阻止，具阻止性质的效果有时候并不需要直接言明的条文达到；至于这事情会产生的问题，那就是只有反对意见得以显现，使实际的意见比例和表面上所看到的意见的比例不符。SANMOSA Σουέζ 2021年3月29日 (一) 10:00 (UTC)[回复]
完全不一样，这制限条件已经完全不同了。我真的只能认为你真的没有一般人应有阅读中文的能力，这分明已经是两种完全不同的情况。SANMOSA Σουέζ 2021年3月31日 (三) 07:49 (UTC)[回复]
请不要人身攻击﹗您是换了不同名目去缩短公示期，这是与AT版解决火速公示的提案原意不合。而且我反而我看到您平时公示时一有异议就重新公示，我觉这个操作很不错，所以建议加一条“公示期间如有异议应重新公示”。--虫虫飞♡♡→♡℃※留言 2021年3月31日 (三) 10:35 (UTC)[回复]
“缩短公示期”从不存在，不论是原案抑或调适案也如是。我认为所有用户均有重新公示的意识，而且重新公示的操作可以依规进行，无须特别规范。SANMOSA Σουέζ 2021年4月1日 (四) 00:51 (UTC)[回复]
(－)反对，赞同虫飞飞的意见。AT的版本已经很清晰。Walter Grassroot（留言） 2021年4月1日 (四) 01:34 (UTC)[回复]
（咦？）SANMOSA Σουέζ 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日已经过长，现行方针正在过分鼓吹“让人有较多时间讨论”，结果适得其反，这也是提出是次方针修订的主因）。我本来的想法是直接缩短那个期限到比任何定义上的“一个月”更短。SANMOSA Σουέζ 2021年4月19日 (一) 01:02 (UTC)[回复]
不认为现在的冗长辩论的主因是多了这两三天，提案要是具争议的，无论定多少天都会有人拉下去，以现状来推断“30日已经过长”、“不可能订立一个较长的日数”，我认为理据非常不充份。--街燈電箱150號 开箱维修 抄表 检验证明 2021年4月19日 (一) 02:03 (UTC)[回复]
@Cdip150：建议你看看这规则通过以来的所有客栈讨论，一个与讨论主题不相关的留言直接导致公示延后非常常见。现行规则唯一的“作用”是在不必要地拖时间。SANMOSA Σουέζ 2021年4月19日 (一) 02:15 (UTC)[回复]
“一个与讨论主题不相关的留言”与至少多少天是不相关的，就算定了28天，不代表那些不相关的留言就会少。又或者说简单一点，这种延后的原因本来就不是出在“一个月”身上。--街燈電箱150號 开箱维修 抄表 检验证明 2021年4月19日 (一) 03:23 (UTC)[回复]
受影响规模会缩减。SANMOSA Σουέζ 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专门指向站内各已正式通过和未正式通过的格式手册。我有一个想法是能不能为命名常规和关注度指引也设立专门的捷径伪命名空间？SANMOSA 江南好，风景旧曾谙 2021年3月24日 (三) 09:02 (UTC)[回复]

@A2569875、Taiwania Justo、Yining Chen、羊羊32521、YFdyh000、@LuciferianThomas、Ericliu1912、MilkyDefer、Super Wang、Sunny00217。SANMOSA 江南好，风景旧曾谙 2021年3月24日 (三) 09:08 (UTC)[回复]
(＋)支持。伪命名空间运行畅顺，可选择有需要的计划空间内容增设伪命名空间。(＆)建议命名常规使用“NC”字首、关注度使用“N”字首。另(＆)建议增设共识（讨论）捷径“CON”，连结至各讨论存档（Talk、WT、PJT）或资讯页（WP），如CON:COVID19指向COVID-19条目共识。--LuciferianThomas．留言 2021年3月24日 (三) 09:32 (UTC)[回复]
NC和N可行。CON可行，但建议另外讨论，因为CON可以重新导向到的目标有太多类页面。SANMOSA 江南好，风景旧曾谙 2021年3月24日 (三) 10:00 (UTC)[回复]
支持N和NC，对CON保留意见 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月25日 (四) 06:07 (UTC)[回复]
N的话会不会短了点？之前MOS和LTA的时候因为是三个字母，跟正式条目命名撞车的可能性小所以没有问题。这一个N我个人有点拿不准。此外我觉得CON可能还不是时候。在我的认知中，单独讨论出共识单独成页的也就只有COVID-19这一个了，至少应当等类似的页面数量足够多了再提出会比较好。如果有我不知道的类似页面尽管告诉我。 --Milky·Defer 2021年3月25日 (四) 07:36 (UTC)[回复]
检查过，现时没有条目空间的页面是“N:”开首的。如果真的不放心的话，NT和NOTE也可以（但不能NOT）。SANMOSA 江南好，风景旧曾谙 2021年3月25日 (四) 07:44 (UTC)[回复]
@sanmosa： 维基新闻的前缀就是“n:”，烦请查询Special:跨wiki。--痛心疾首 2021年4月2日 (五) 15:43 (UTC)[回复]
啊，忘了。SANMOSA Σουέζ 2021年4月3日 (六) 00:12 (UTC)[回复]
先跑题：MOS基本没用过，看到时我习惯改用WP前缀。LTA用过但没有独立空间所以搜索很不方便，期望未来设独立空间、增设访问限制。然后：我不清楚相关页面有多少，如果很少，可能用的人也不会很多？以及持久性不会好（几年后失效）。N有点短，NOTE我想到[{tl|TA}}和备注，命名常规为什么不是NAME:（但未来会不会冲突？）。关注度没想法，考虑到“关注度”定名本身都有质疑，我暂时想不到很好的。NT在中国大陆网络有贬义“脑瘫”，不赞成。--YFdyh000（留言） 2021年3月25日 (四) 12:14 (UTC)[回复]
@YFdyh000：“NAME:”应该不会冲突吧，也不不失是一个好提议。“NT:”你当我真的NT了吧（在香港“NT”指新界，不过以地名开首还是有些怪）。“NOTA:”不知如何，有种葡文风，但字源仍是“Notability”，冲突的机会也低。SANMOSA 江南好，风景旧曾谙 2021年3月25日 (四) 13:01 (UTC)[回复]
(－)反对，如果将编辑社群页面等因为与Wikipedia命名空间关联性不强而划分出的话，方针等与项目运营有关的的页面不应该划出Wikipedia空间，而且本身这部分已经能通过消歧义的方式处理，没坏别瞎修。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年3月26日 (五) 00:54 (UTC)[回复]
@cwek：伪命名空间仅用于设置重新导向页面（这是指引指明的），完全没有你所说的“（将导向目标）划出Wikipedia空间”那回事。SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 01:00 (UTC)[回复]
伪命名空间作用并非直接划出内容，而是作捷径之用：#伪命名空间、WP:PNS、WP:PNS+。因为似乎对于提案内容有所误解，反对的事也并非现在实际正在讨论之议案，故难以算作有效反对意见。--LuciferianThomas．留言 2021年3月28日 (日) 06:23 (UTC)[回复]

初步定案

建议为命名常规和关注度指引设立专门的捷径伪命名空间，其中命名常规的专门捷径伪命名空间为“NC:”，而关注度指引的专门捷径伪命名空间则为“NT:”。SANMOSA Σουέζ 2021年4月14日 (三) 13:24 (UTC)[回复]

模板颜色相关规范

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:格式手册/文字格式、Wikipedia talk:分类、列表与导航模板。

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：SANMOSA 江南好，风景旧曾谙 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:格式手册/文字格式#颜色及内联图像算不算？SANMOSA 江南好，风景旧曾谙 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:格式手册/文字格式#颜色及内联图像的适用范围。SANMOSA 江南好，风景旧曾谙 2021年3月25日 (四) 04:40 (UTC)[回复]
完全支持扩大适用范围。 --无心*插柳*柳橙汁 2021年3月25日 (四) 05:13 (UTC)[回复]
可解决问题，故支持。唯此格式手册的修订将会影响大量的模板，故需要更深入的讨论。--1233 （T / C） 2021年3月25日 (四) 15:23 (UTC)[回复]
@痛心疾首、Milkypine、1233：已移动讨论至方针区。SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 09:01 (UTC)[回复]
拟修改如下：
现行条文

颜色及内联图像

关于图像的规定为Wikipedia:格式手册/图像的覆盖范围，应及时建立并移动过去。

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

只有在背景颜色可帮助阐释条目内容，且没有其他更佳的表达方式时，才可对表格或其他的内文元素加入背景颜色。为了照顾视障或色觉障碍读者的需要，请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述。为了保障条目的可读性，请避免使用饱和度过高，或与文字对比度不足的颜色作为表格的背景色。禁止使用CSS代码对表格背景加入花俏的样式（如渐层色等）。

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

参考资料

  1. ^ 参见Wikipedia:铁道专题/移除著色文字模板。
提议条文

颜色及内联图像

关于图像的规定为Wikipedia:格式手册/图像的覆盖范围，应及时建立并移动过去。

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

只有在背景颜色可帮助阐释条目内容，且没有其他更佳的表达方式时，才可对表格或其他的内文元素加入背景颜色。为了照顾视障或色觉障碍读者的需要，请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述。为了保障条目的可读性，请避免使用饱和度过高，或与文字对比度不足的颜色作为表格的背景色。禁止使用CSS代码对表格背景加入花俏的样式（如渐层色等）。

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

参考资料

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

以上。SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 23:40 (UTC)[回复]

似乎应该是不在条目里用带特殊颜色的模板，而不是规定模板不得带颜色。所以建议“条目正文、表格及各类模板”→“条目正文、表格及条目中使用的各类模板”。--DrizzleD (按此给我留言) 2021年3月28日 (日) 08:04 (UTC)[回复]
@DrizzleD：然而这里最原始的提议就是禁止所有模板著色（如果我没理解错的话），@1233。SANMOSA ······ 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的意思的话）。SANMOSA ······ 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的。SANMOSA Σουέζ 2021年3月31日 (三) 07:53 (UTC)[回复]
既然已经了解提案禁止对Infobox等模板上色，那么我(－)反对此提案，毕竟有些Infobox模板的颜色对辨别条目类型有很大的帮助，不能因为视觉障碍人士而选择单一的格式，不过如果是限制背景颜色和文字颜色之间的对比度，这我能够接受。 2021年4月1日 (四) 14:20 (UTC)[回复]
仔细想了想，倾向不赞同：
  1. （主要）现行方针能够确保色盲（弱）人士能够获取充分信息，根据现行方针要旨，只需避免“单独地使用背景颜色来表达某一含义”，同时避免“饱和度过高，或与文字对比度不足”，上述举措——
    • 确保了色盲（弱）人士能够不依赖颜色获取足够信息，确保所有人阅读的文字是清晰的；
    • 在此基础上，不对辅助性背景填色进行“一刀切”，能保障更多色觉正常的人士能借背景色获得获取信息上的便利。
  2. （次要）变更宜乎审慎行事，仅高速公路一类就有逾千条条目和大量模板受到影响，即便上述修改要实施，修正案也未能列出批量变动的页面范围和变动的具体方案。
以上。--Kirk # 2021年4月1日 (四) 14:33 (UTC)[回复]
个人认为对现行模板应当是采取没坏别修的态度：应当先行禁止新（类型）的模板著色，再讨论如何界定为“可行”且为辅助性的背景著色，再解决“应当在何时著色”和“怎样才是可行的著色”的两个问题--1233 （T / C） 2021年4月3日 (六) 02:41 (UTC)[回复]
  • (－)反对，限制面太广，用户框、导航模板等都会受影响。可行的着色可以按常识判断。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月3日 (六) 04:56 (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)[回复]
意见颇为分歧，我建议就此进行投票，不知各位意下如何。SANMOSA Σουέζ 2021年4月10日 (六) 06:39 (UTC)[回复]
这不是投票就能解决的问题，一来是不能只因为视觉障碍人士而选择单一的样式，再者是影响范围过大，投票并不能体现所有使用者的意见（匿名使用者不能投票，请留意维基百科并非专给注册使用者阅读）。如果您要发起民调，我没意见，但是我反对发起投票。 2021年4月10日 (六) 07:05 (UTC)[回复]
然而现时的状况确实对视障人士构成严重的歧视，我认为所有人现在最基本要知道的就是现时模板的着色情形已经严重影响到视障人士的阅读体验。投票的选项亦非只有两种（至少我初步的计划如是）。在陷入复杂讨论的泥潭时，投票显然是一种快速收集意见以凝聚共识的方法，不能单纯因为“影响范围过大”和“不能体现所有使用者的意见”而反对发起投票和变相剥削视障人士的合理阅读体验。SANMOSA Σουέζ 2021年4月11日 (日) 14:26 (UTC)[回复]
@Sanmosa：“影响范围过大”和“不能体现所有使用者的意见”已经不是您所指的单纯问题了。您发起民调来搜集意见我没意见，但是要将投票结果作为共识执行，我不能接受。当然您要发起与否是您的自由，如果社群能够接受结果，那我也没话说，只是还请留意，我不能接受投票不代表我反对投票，也不代表我变相剥夺视觉障碍人士的合理阅读体验，这只是表达我的个人意见，而我的意见是对于此种议题，应该有比投票更能体现共识的方式。 2021年4月12日 (一) 02:31 (UTC)[回复]
发起投票的最主要目的是在讨论各方意见很大程度上分歧时确立讨论的大方向，如果连大方向都不能确立，我难以相信讨论能有效持续。SANMOSA Σουέζ 2021年4月14日 (三) 13:19 (UTC)[回复]
@Sanmosa：确立讨论的方向，请使用民调而非投票。 2021年4月14日 (三) 18:01 (UTC)[回复]

变通提案

以下是小弟的变通提案：

现行条文

颜色及内联图像

关于图像的规定为Wikipedia:格式手册/图像的覆盖范围，应及时建立并移动过去。

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

只有在背景颜色可帮助阐释条目内容，且没有其他更佳的表达方式时，才可对表格或其他的内文元素加入背景颜色。为了照顾视障或色觉障碍读者的需要，请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述。为了保障条目的可读性，请避免使用饱和度过高，或与文字对比度不足的颜色作为表格的背景色。禁止使用CSS代码对表格背景加入花俏的样式（如渐层色等）。

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

参考资料

  1. ^ 参见WikiProject:铁道/移除著色文字模板。
提议条文

颜色及内联图像

关于图像的规定为Wikipedia:格式手册/图像的覆盖范围，应及时建立并移动过去。

条目正文、表格及各类模板（包括信息框）中，使用原始码或其他模板将文字或背景颜色染成非预设颜色，应以帮助阐释条目内容为第一目的。同时，编者也需要考虑色盲、色弱或使用黑白版本的读者的实际需求。[1]

除非编者有正当理由，并且能在讨论页自证有理，否则：

  • 同一表格、导航模板或信息框模板只能使用一种边界色、一种标题栏背景色、一种标题栏文字色，且总共不能超过三种颜色；
  • 请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述；
  • 边界色、标题背景色、标题文字色之间应该有可视的对比度；
  • 内容背景色和内容文字色之间也应该有可视的对比度；
  • 表格/模板边界色和内容背景色两者的饱和度不能太高；
  • 禁止手动将表格或模板的内容文字染成其他颜色。
  • 禁止使用CSS代码对表格/模板的任何部份加入花俏的样式（如渐层色等）。

为避免编辑争议，建议编者在编辑的同时，即在编辑摘要或讨论页中说明上色的理由。

同理，禁止在正文中使用内联图像（例如在文字中出现这样的图像）、什锦字型或绘文字，但符合以下条件图像则不在此限：

  • 与正文内容密切相关，不使用就无法（或很难）准确阐释条目内容；
  • 编者有理由相信电脑无法正常解码和显示；
  • （非强制）有对应Unicode代码的天然语言字符或专业符号，或者符合知名度要求的人造语言的字符，或者以LaTeX制作的科学表述。

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

参考资料

  1. ^ 参见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)[回复]
@1233：已修订为“同一表格、导航模板或信息框模板只能使用一种边界色、一种标题栏背景色、一种标题栏文字色，且总共不能超过三种颜色”。另外，能否解释一下怎样才算“WCAG 2.0中两种低于2.0的配色”？📕📙📒📗📘📚📖 2021年4月14日 (三) 21:37 (UTC)[回复]
  • (－)反对只能使用三种颜色。Template:元素周期表会无法呈现，更不用说缩图型导航的Template:NavPeriodicTable，此举同时也导致了之前色弱友善元素周期表颜色配置Template talk:Isotope nav#同位素模板颜色更换全部白讨论了，浪费了社群资源。 考量到需要区分元素本身特性，以下主题有许多层级需要区分
    1. 元素周期表（Template:元素周期表、Template:NavPeriodicTable）
    2. 元素稳定性表（Template talk:Isotope nav）
      • 大量稳定同位素、仅一种稳定同位素、仅有观测上稳定同位素、最稳定同位素半衰期万年、半衰期千年、半衰期1年或以下、半衰期以日计、半衰期以时计、半衰期以秒计、目前未发现同位素（如Uue） 等至少10种等级
    3. 元素分区（Template:元素周期表_(正文)#范例）
    要区分5种以上等级，禁用颜色根本强人所难，无法实行，或实行会导致元素周期表等相关条目无法准确制作示意图表。-- 五岁抬头雪菲（☎️·☘️） 2021年4月14日 (三) 19:05 (UTC)—- 五岁抬头雪菲（☎️·☘️） 2021年4月15日 (四) 02:24 (UTC)[回复]
    同时也反对禁用内连图像。{{缺字}}、或Unicode未收录符号、特殊的语言（如克林贡语）和特殊数学符号（如en:Coxeter–Dynkin_diagram、{{CDD}}），全是内连图像，禁用的话，全部都难以或无法描述条目了。特别是en:Coxeter–Dynkin_diagram，根本不可能用文字描述代表一个en:Coxeter–Dynkin_diagram，要求只能放在图表将导致内文难以描述，必须在内文呈现符号再加以说明，这个如果禁的话，那我认为数学公式也该禁。仍然坚持，特殊数学符号是有必要跟文字一起使用的。-- 五岁抬头雪菲（☎️·☘️） 2021年4月15日 (四) 02:24 (UTC)[回复]
    @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。
    第一片，或称为V。
  • 第二片，或称为L：三个立方体排成一列，左下方加一个立方体。
    第二片，或称为L：三个立方体排成一列，左下方加一个立方体。
  • 第三片，或称为T：三个立方体排成一列，中间下方加一个立方体。
    第三片，或称为T：三个立方体排成一列，中间下方加一个立方体。
  • 第四片，或称为Z：二个立方体排成一列，上面是另外二个立方体，往右排一格。
    第四片，或称为Z：二个立方体排成一列，上面是另外二个立方体，往右排一格。
  • 第五片，或称为A：V型的三立方体平放，另一个立方体放在顺时针的第一个立方体上方，有立体的不对称性。
    第五片，或称为A：V型的三立方体平放，另一个立方体放在顺时针的第一个立方体上方，有立体的不对称性。
  • 第六片，或称为B：V型的三立方体平放，另一个立方体放在逆时针的第一个立方体上方，有立体不对称性。
    第六片，或称为B：V型的三立方体平放，另一个立方体放在逆时针的第一个立方体上方，有立体不对称性。
  • 第七片，或称为P：V型的三立方体平放，另一个立方体放在转折的立方体上方的第一个，有立体对称性。
    第七片，或称为P：V型的三立方体平放，另一个立方体放在转折的立方体上方的第一个，有立体对称性。
这样就既不需要使用内联图像，也不需要单纯依赖文字描述。📕📙📒📗📘📚📖 2021年4月15日 (四) 22:14 (UTC)[回复]
  • 仍然坚持会有需要把文字和图片放在一起的情况，折纸的你们还没回应，我将会继续寻找，补充一个找了一整晚的
(将会陆续补充)
以上-- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 05:23 (UTC)[回复]
(～)补充另外，关于“
”的描述，我认为应该要这样“方块下两层已完成，且顶面颜色在顶面上呈形状时....”不然图像还要引用旁边另外图像，真的很诡异。-- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 05:40 (UTC)[回复]

“设法在不破坏其他已完成部分，将一柱转成以下两种形式之一（图1.1和图1.2）：”

图1.1 图1.2
  • 这样一来，魔方的图案想再放大些都不怕影响排版。
  • 折纸的案例和索马立方的案例一样，可以制作表格或图片库，不需使用内联图像。
  • 天文学符号完全可以在表格或者Infobox里面用，不需用作内联图像。
  • 中华民国国语那个注音符号，以及那个阿拉伯乐谱符号，都已经符合“与正文内容密切相关，不使用就无法准确阐释条目内容”的例外条件。
  • 至于PlayStation和滨崎步的案例简直就是边缘得不能再边缘了。PlayStation的那句营销口号，完全可以上传一张自制图片来表示，反正像这种简单的几何符号，是怎么都达不到原创性门槛的。滨崎步的案例已经涉嫌过量使用非自由图像，违反《WP:NFCC#3》了。
另：@Lopullinen、1233：小弟新增了无正当理由禁止使用什锦字型或绘文字的条文，请回应。📕📙📒📗📘📚📖 2021年4月16日 (五) 06:19 (UTC)[回复]
  • (：)回应我认为索马立方、折纸与正文密切相关。天文符号其他例子例如电路符号、化学特殊符号、化学结构式（有苯环的）生物学符号，我不建议在旁边放成表格，一堆一个小符号整理成表格非常诡异。以及“
    ：顶面颜色在顶面上呈形状”的亦与正文密切相关。同时，整个连纯文字也包成图片放旁边表格将会有“无法复制其中文字”的缺点。-- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 06:27 (UTC)[回复]
  • 小整理一下，以便针对点讨论
    • 已解决的问题
      • 自身有独特排版，且为学术界惯例，又需要颜色表达之表格
      • 无法使用现有文字代替的符号（打不出来的字，或者非自然语言表达范畴之记号）
        • 未收录汉字（如{{缺字}}）
        • 数学符号（如{{CDD}}）
        • 乐谱记号
        • 特殊的语言
    • 未解决问题
      • 可以用排版代替颜色的表
        • 地质年代表的背景色。
        • 生物保育状态的背景色。
      • 可以使用现有文字代替的符号
        • 天文符号
        • 化学结构式
      • 具表意功能图示使用时机
        • 如折纸图示
        • 文字不易描述的琐碎形状图示(一句话出现多种时，使用表格反而杂乱)
        • Emoji、绘文字
        • 什锦符号
      • 特殊标语口号
        • “LIVE IN YOUR WORLD. PLAY IN OURS”（整个做成图片将会导致文字复制困难）
        • LaTeX
    以上-- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 07:06 (UTC)[回复]
在我看来明文限制使用颜色或内文图片会造成很多麻烦，更不应该直接限制着色，应当按照情况逐例处理；例如在有用户提出更好减少使用颜色的情况下，若内容不造成明显阅读困难就应尽量以颜色较少的方式处理（即指排版妥当；不应以“比较那个比较方便阅读”为准则，只要整体不造成阅读困难即可）。列表条目中适当使用颜色协助用户进行分类，限制用色比限制着色更实际。--LuciferianThomas．留言 2021年4月16日 (五) 09:41 (UTC)[回复]
  • “地质年代表的背景色”和“生物保育状态的背景色”我在上面已经说过符合例外条件，因此不属于“未解决问题”。严格来说，俄罗斯方块的图像也属于“与正文内容密切相关，不使用就无法准确阐释条目内容”，只是编者有责任证明非使用内联图像不可。
  • 我加入了或者以LaTeX制作的科学表述，以包括数学公式和化学方程式等。
  • 我粗略阅读了《烃》、《苯》等化学条目，里面的图像都不算“内联图像”。“内联图像”是指插入段落之内，文字之间的图像。但这些条目当中的图像都是用在段落之间，而非段落之内，因此不符合“内联图像”的定义。
  • 天文符号可以在表格或Infobox里使用，不需使用内联图像。
  • “LIVE IN YOUR WORLD. PLAY IN OURS”这种标语是不是非加入不可？“导致文字复制困难”似乎暗示阁下打算复制粘贴到其他条目，但除了PS条目本身以外，还有哪些条目非有这条标语不可？
  • @LuciferianThomas：限制著色是为了防止出现像某个IP对《追梦 Do Re Mi》疯狂著色的情况再次出现。而我提出“一种边界色、一种标题栏背景色、一种标题栏文字色，除非能自证有理”是为了方便执行，尽可能压制游戏维基规则的空间。另外，我在上面的提案也有限制用色的条文：“背景色饱和度不能太高”。
欢迎回应。@A2569875、1233、Lopullinen、Pseudo Classes、Sanmosa、蕭漫、Lab06 N、羊羊32521：📕📙📒📗📘📚📖 2021年4月16日 (五) 15:29 (UTC)[回复]
  • 关于复制，我指的是会困扰读者，读者将无法或难以复制该文字。维基百科不应搞得像那种让读者复制不了东西的神秘部落格，且读者理应要能够方便地复制“LIVE IN YOUR WORLD. PLAY IN OURS”以便到其他地方利用或查询其他相关资料，整个包成图像你是要读者去研究影像辨识和机器视觉？？；另外“有对应Unicode代码”en:Coxeter–Dynkin_diagram、{{CDD}}没有对应unicode 代码，LaTeX也不支援，且由于其抽象性，难以用文字说明代替。另外 我相信应该还有一些数学公式或符号不被unicode与LaTeX支援，但是需要与文字一同描述。—- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 15:39 (UTC)[回复]
总归一句话，复杂的限制只会更容易被忽略，再加上你遇到例外就加上去、加上去，最后限制越来越多。至少我没有这么有耐性看完这些限制，就算看完也好，我也不能确保我不会被混淆。你提议修正条文，就有必要将条文修到完整、易读的状态，除非你让这些条文更加简洁，否则我(－)反对的立场不会改变。 2021年4月16日 (五) 16:43 (UTC)[回复]
不限制著色，但渐层应明文禁制；另觉得表格什么的不是不能上色，但必须整个条目一致就是了。--LuciferianThomas．留言 2021年4月16日 (五) 18:07 (UTC)[回复]
我认为维基百科不应搞得花花绿绿的像粉丝部落格。如果“LIVE IN YOUR WORLD. PLAY IN OURS”包装成图像读者能理解，那就不应该使用内连图像；再说这东西复制出来居然是“LIVE IN YOUR WORLD. PLAY IN OURS”，圈叉三角呢，打哑谜？况且stylized包括大小写、颜色、文字大小等等元素，其主要作用也是视觉冲击，所以本来就更适合用图片表示（再用图注说明，其中四个字母置换成为PlayStation的圈、叉、正方、三角标志）。总之简单一句话：图像可以用，但不要放在正文；如果想放在正文，请想想能不能单独提出来：如果提不出来，再想想所谓的“不用图片不行”整句话是否举例过细，对维基百科这种通用百科并无必要；如果真的很重要，业界也常常这样用，那再讨论要不要内连。科学类条目可以制定自己的格式手册，决定哪些图片可以在兼顾排版的情况下，视同文字在正文中使用。但对于大多数条目，要让编者（特别是新编者）从大方向感觉到，维基百科不鼓励使用内连图像。同时也要鼓励编者锻炼文字表达能力：编者作为爱好者可能以为图片很直观，但非圈内读者很可能根本get不到点。（
这个例子要是不配文字，花花绿绿的我还真不知道想表达最下面两层已完成。）--洛普利宁 2021年4月16日 (五) 18:34 (UTC)[回复]
颜色和附图塞内文概念上是一样的，上面列的都是附图案例，颜色例如：
在我看来，许多状况，有加附图或颜色，比起没加附图或颜色，“更有助于帮助读者了解主题”。反而没有上面说的那么严重。-- 五岁抬头雪菲（☎️·☘️） 2021年4月17日 (六) 07:51 (UTC)[回复]
@A2569875：您说的这篇条目，正好证明内文颜色不必要乃至多余。您举例的下一段就附了个参考文献；此文献是“8+ (green), 12+ (blue), and 16+ (yellow)”这样用纯文字描述的，而显然编者正确理解了文字（先不讨论绿色用#5CB531是不是原创研究）。由此可见，使用纯文字也能起到等价的效果。另一方面，禁止内连颜色不是禁止使用颜色；正确的方法是这样，用侧边图像大大方方地表示。所以我没看出来，直接给文字上色什么时候成了唯一手段。在我看来，图片放到侧边并配上图注详述、正文做一些大方向上的解释，比起使用不知所以的内联图像或颜色，更有助于读者理解主题。PS：感谢提醒，我把这条目正文中的颜色全部移除了（最上面那个是表格的图示，不属于内连的范畴；下面全都在东施效颦）。--洛普利宁 2021年4月17日 (六) 17:42 (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)[回复]
我还是觉得直接让介面管理员扩权就可以。SANMOSA Σουέζ 2021年4月7日 (三) 05:36 (UTC)[回复]
@Sanmosa：早在近三月前，我便问过了编辑类权限。但连编辑类权限都要不来，更不要说其他杂七杂八的权限。--安忆Talk 2021年4月8日 (四) 05:08 (UTC)[回复]
我认为这是单纯因为你使用个人名义请求的缘故。如果有社群共识的话，我估计可能会有所不同。SANMOSA Σουέζ 2021年4月8日 (四) 05:10 (UTC)[回复]
我也是这么认为的，所以才有了之后的几个提案，但现在看起来还是不太可行。--安忆Talk 2021年4月8日 (四) 05:18 (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)[回复]

模板修订建议

本主题或以下段落文字，在讨论结束后应存档至Template talk:Refimprove。

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

最近参照一下英维，留意到{{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)[回复]
同上意见。-门可罗雀的雾岛诊所三天打鱼两天晒网神社的羽毛飘啊飘 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)[回复]
中立，感觉类似“参见”（相关条目），不适合写入正文，不是都有明显的意义和参考资料，类似时间线资料。更看不惯收视率章节的统计表。需要电视专题的参与者决定，不然会反弹。--YFdyh000（留言） 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:自我参照和其他值得保留内容，清理这种内容也不会太麻烦。--YFdyh000（留言） 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的一些行为对社群造成了恶劣的影响。实际上截至目前本地并没有对编辑松的举办、规则的订立相关的方针或指引，为避免再次发生类似于中塞编辑松的恶劣事件，本人提议在本地订立编辑松的相关指引。我认为至少可以作以下要求：

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

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

(＋)支持。完善制度比指责个别人对维基百科更加有益（但这不代表无人需要为之前的纷扰负责）。--Yangwenbo99论 文 2021年4月17日 (六) 22:35 (UTC)[回复]
(－)反对，提议者本身就是此次闹剧的编造者，此事本身就是对大陆社群的污名化行动。目前又想伪造社群共识以实现对中国大陆社群的侮辱既定事实。对此我表示坚决反对。门可罗雀的雾岛诊所三天打鱼两天晒网神社的羽毛飘啊飘 2021年4月18日 (日) 03:53 (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)[回复]
同上。提案本身是没有问题的。SANMOSA Σουέζ 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月的事件已经证明了事后审查的成效不大。虽然说那三个核心人物之一已经获得处理，但明明问题就已经存在而且非常明显了，到现在还是有人敢公然向大家说不存在问题，就已经证明了现在编辑松的举办者会走通知程序的漏洞，然后恣意妄为，并且把这当成常态。如果没有人滥用现行程序，我相信他也不会走出来提这案。SANMOSA Σουέζ 2021年4月21日 (三) 03:16 (UTC)[回复]
支持社群采取一切合理措施阻止个别有过公报私仇前科且拒绝认错及改善的编者担任往后一切活动（包括但不限于动员令和编辑松等）的主持人，及阻止活动中一切存在显著问题及争议规则的制定与实施，如果无法阻止编辑松由有公报私仇前科且拒绝认错及改善的编者担任其中一位主持人，或无法阻止存在显著问题及争议规则在编辑松当中的出现，则支持社群采取一切合理措施阻止相应编辑松在本站的宣传。--🔨（留言） 2021年4月19日 (一) 11:44 (UTC)[回复]
(－)反对，好像每次举办社群活动的时候一般会向社群发通告吧，几位的意思是不经过几位批准以后大家都别搞了是吧。不知几位是打算怎么审批呢？是打算投票比人头呢还是在客栈聚众扯皮呢？个人觉得这个提议当个笑话看看完了没必要去较真。--飞贼燕子（留言） 2021年4月19日 (一) 23:06 (UTC)[回复]
社群讨论的共识或大方向一旦不合己意就胡乱声称其已失效，这不是只有你一个人正在做的事情，但大家都在看著。SANMOSA Σουέζ 2021年4月20日 (二) 04:50 (UTC)[回复]
我也不见得筹办编辑松的程序开诚布公是坏事（所有社群成员都能就此发表意见），除非筹办者意图利用编辑松进行违反使用条款和方针指引的事项。SANMOSA Σουέζ 2021年4月20日 (二) 04:55 (UTC)[回复]
  • 怎么办活动怎么办好像参与和组织者都会写在公告上谁都可以看吧，不觉得谁会举办前就在公告里刻意违反规则指引啥的，再者个人不觉得谁会听一个完全无关闲人去批准同不同意。--飞贼燕子（留言） 2021年4月20日 (二) 07:31 (UTC)[回复]
    但举办期间这样做的情况已经出现了。社群作为编辑松的参与者，怎么可能是“闲人”？不然编辑松是开来做甚么的？SANMOSA Σουέζ 2021年4月20日 (二) 12:53 (UTC)[回复]
    “不觉得谁会举办前就在公告里刻意违反规则指引啥的”——上一次活动是在活动中更改规则，违反指引的。--Yangwenbo99论 文 2021年4月21日 (三) 03:34 (UTC)[回复]
  • 操作涉及操作问题一次不行下次可以修正，社群活动的参与者不少但是那些喜欢捣蛋的闲人也一样不少。方针规则这东西这次你能用下次别人一样能拿来用，届时就社群活动就谁都别搞不了只能在互助客栈扎堆审查扯皮，我看这个提案就是为那些闲人在社群活动时审查扯皮捣蛋准备的提案。--飞贼燕子（留言） 2021年4月21日 (三) 02:10 (UTC)[回复]
我不介意重复一次上面的话：“社群讨论的共识或大方向一旦不合己意就胡乱声称其已失效，这不是只有你一个人正在做的事情，但大家都在看著。”“社群作为编辑松的参与者，怎么可能是‘闲人’？”（还是说，你已经把特定的社群参与者，不当成是社群的一分子，然后要把他们排挤出去？）你的反对理由是完全无效的。SANMOSA Σουέζ 2021年4月21日 (三) 03:07 (UTC)[回复]
“届时就社群活动就谁都别搞不了只能在互助客栈扎堆审查扯皮”——所以阁下认为举行“社群活动”不需要取得“社群共识”？“操作涉及操作问题一次不行下次可以修正”——制订规则就是为了防止之后出现类似问题。我明白阁下希望维基百科都是举手机器，但是残酷的现实是，维基百科有一批编者是有独立思考能力的知识分子，而这当中有一部分人愿意为维基百科的益处进行争论。--Yangwenbo99论 文 2021年4月21日 (三) 03:34 (UTC)[回复]

将“青岛”、“中国青岛”或“山东青岛”改成“中华人民共和国山东省青岛”是否有必要

近日有不少更改是将城市名改为类似“中华人民共和国山东省青岛”的详细行政区划名。其中单个使用者一两日内（初步估计）过百次类似编辑，所以应当订立规定。举例如下：

  1. 陈倩 (游泳运动员)
  2. 范学伟
  3. 任永顺
  4. 青岛市区道路新旧名称对照表
  5. 埃琳·派齐
  6. 李通 (足球运动员)

此等做法是否存在必要性？我不相信有中文维基百科使用者会不知道青岛现由中华人民共和国管辖，亦不相信会有人无法轻易查得青岛属于山东省。另外，在下对把机器人们带走的存在感给抢回来的行为相当欣赏。

就将“中国”改为“中华人民共和国”一事，可能是相关编者受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)[回复]

惠州解放后，东湖旅店曾被用于中华人民共和国广东省惠阳专区武装部的办公场所。2000年代，东湖旅店的产权被以数百万人民币的价格售予私人买家。之后，相关人士在不早于2009年8月对该旅店进行了修缮，并令其回归私人住宅用途。2012年，中华人民共和国广东省惠州市惠城区人民政府将其确定为不可移动文物。2014年11月，东湖旅店被辟为一间名为“水东院子”的休闲咖啡吧。
2017年2月28日，中华人民共和国广东省惠州市惠城区召开宣传思想文化工作会议，指出将抓好包含东湖旅店在内的多幢历史建筑的修缮工作。次月，中华人民共和国广东省惠州市惠城区人民政府以人民币750万元的价格收购了旅店的产权。2018年3月3日，上述咖啡吧于社交网络发布停业装修的公告，随后于当月25日正式宣布结业转让。
以上。--Yangwenbo99论 文 2021年4月18日 (日) 12:23 (UTC)[回复]
请问现在究竟是仅讨论地名的条目命名，还是扩及地名“在文中”的使用？-游蛇脱壳/克劳棣 2021年4月18日 (日) 15:51 (UTC)[回复]
只讨论在正文中的使用。条目命名已有相关规定，即只能使用“青岛市”这一种形式。--Yangwenbo99论 文 2021年4月18日 (日) 17:04 (UTC)[回复]
(－)反对，理由如下：
  1. 就前者：‘但是Wikipedia:格式手册/两岸四地用语#指定样式表便违背了Wikipedia:格式手册/两岸四地用语#使用“中国”一词的建议，要求特定人士使用“ 中国”而非“ 中华人民共和国”标注国籍。可见，“在1949年之后的相关条目中，应尽量使用中华人民共和国和中华民国等全称”之不可实践性。’是错误描述。指定样式表的规范属于Wikipedia:格式手册/两岸四地用语#使用“中国”一词的规范的例外条文，而且仅限于国籍，是依据国籍的国际标准表示方式而行，不存在“违背”和“不可实践”的情形，我要求提案人立即收回其错误表述。
  2. 就后者：完整的行政区划和单称在条目内的不同地方有不同的使用，不可能在一个条目内的所有地方都完全只用完整的行政区划或单称。一般来说，资讯框和正文首次提及时会使用完整的行政区划（例如“中华人民共和国山东省济南市”、“德国北莱茵-西法伦州（代特莫尔德行政区棉登-吕贝克县）棉登”），然后正文其馀地方使用单称（例如“济南”、“棉登”）。
综以上，提议修订属矫枉过正，我不可能支持。SANMOSA Σουέζ 2021年4月19日 (一) 01:21 (UTC)[回复]
补充说明：WG对埃琳·派齐条目的修改是完全错误的，1939年的青岛是院辖市，不受山东省管辖。SANMOSA Σουέζ 2021年4月19日 (一) 01:31 (UTC)[回复]
补充说明2：香港和澳门比较特别，通常不会把（任何形式的）国名和“特别行政区”五个字写进去（因为严格上“十八区”不算是行政分区），因此基本上不会使用完整的行政区划（唯一表达式：“中华人民共和国XX特别行政区”）。SANMOSA Σουέζ 2021年4月19日 (一) 01:38 (UTC)[回复]
另外请各位关注Wikipedia:页面存废讨论/记录/2021/04/16中对Template:QDCT、Template:QDC和Template:QDS的提删。SANMOSA Σουέζ 2021年4月19日 (一) 01:50 (UTC)[回复]
循例请一下@K.Y.K.Z.K.、Cxbats过来好了。SANMOSA Σουέζ 2021年4月19日 (一) 01:58 (UTC)[回复]
就新事项再通知一次@Itcfangye、痛心疾首。SANMOSA Σουέζ 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仍适用。SANMOSA Σουέζ 2021年4月20日 (二) 04:44 (UTC)[回复]

订立影片加入相关指引

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:文件使用方针。

我发现最近有很多条目中都被加入了影片，虽然其中不少都对条目大有裨益，但是我也发现相当一部分条目中被加入了与条目本身关系不大的内容或与条目本身不对称的内容（比如在青藏高原条目加入中科院院士的演讲影片和在小条目加入长达20分钟的影片），所以想请问一下社群是否需要订立相关指引来规范条目中的影片加入？--Newbamboo（留言） 2021年4月20日 (二) 04:11 (UTC)[回复]

谢谢，这个是我在Telegram提起来的，WP:AGF的话是我确定这些内容是对维基百科的内容大有益处（尤其很多内容是我们这些普通编者很难接触到或者获取到的）的也非常感谢把他们传到commons的同仁，但是视频尤其新闻报道可能会涉及WP:NPOV的问题，即使没有NPOV问题也涉及到篇幅的问题（一个小作品里出现几十分钟的视频肯定是读者没有耐心去看的），我想了一下，有以下几个点可能可以改进：
  1. 针对新闻视频，提供新闻供稿人的名称，供读者自行辨识观点。
  2. 针对过长的视频，考虑进行剪辑或者进行截图，然后将截图插入条目进行展示。
  3. 或者如果实在认为新闻信息对条目非常宝贵，将新闻视频转写成文字的形式作为来源扩充条目。
不知道各位意向如何？--ParkerTian 2021年4月20日 (二) 04:21 (UTC)[回复]
@Newbamboo、Park1996：已有相关规范，见WP:VUP。SANMOSA Σουέζ 2021年4月20日 (二) 04:28 (UTC)[回复]
虽然说针对视频资料过度使用影响阅读体验的问题，去年就已经修订相应方针来加以限制。不过就现在的情况来看，相关方针执行力度并不算强。--🔨（留言） 2021年4月20日 (二) 06:25 (UTC)[回复]
@Liu116：有甚么条目是违反相关方针的，请列出来，我动手清理一下，有人回退的话，我就依方针提报。SANMOSA Σουέζ 2021年4月20日 (二) 12:55 (UTC)[回复]
……这个我没法完整列出，我顶多只知道脱贫攻坚战条目中原本被移除掉的视频后来又都被加了回来，还有2019冠状病毒病疫苗条目，以及部分“202X年X月中国大陆”的条目也有这样的问题。--🔨（留言） 2021年4月20日 (二) 13:08 (UTC)[回复]
我看到的是驻港部队有过多视频。好像很多都是WG君加入的，能不能跟他说一下让他自己改正呢--ParkerTian 2021年4月20日 (二) 18:33 (UTC)[回复]
当中两段影片未获正文提及，另有一段与正文关系不够密切，已代为删除。--Yangwenbo99论 文 2021年4月20日 (二) 23:33 (UTC)[回复]
对于“加入影片”这一行为，已有相关规定——Wikipedia:文件使用方针#使用守则，即必须同时满足
  1. 与条目有密切关连、
  2. 在条目内文有所提及、
  3. 符合中立的观点（包括旁白、注释），且比重需合理，及
  4. 仅保留具代表性之档案，每条目一般不应同时存在多于五条影片。
而若在无共识的情况下将原本被删除的影片重新加入，即属蓄意挑起WP:编辑战。
建议加入一条“一般而言，新闻报导与条目所论述内容有关，并不代表其内容与条目主题直接相关。仅在该影片所论述之内容本身为所在条目或所在章节之主要论述内容时，方可被认为与条目主题直接相关。”
另外，可以考虑将与内容相关，但是不便加入条目的影片放置于外部链接当中。甚至可以订立指引，表示外部链接中可以设一节放置相关影片，以及规定收录影片的标准。
此外，同意就编辑影片以便加入条目订立指引。
以上。--Yangwenbo99论 文 2021年4月20日 (二) 23:26 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/方针&oldid=65294620”