维基百科:互助客栈/方针

互助客栈： 消息  方针  技术  求助  条目探讨  其他 |  知识问答

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

公告栏

• [公告] 调整COVID-19条目共识的规定、规范日本选举条目命名及禁止有关艺人演出的独立列表条目罗列非固定参与的节目已经通过。
• [公告] 抄袭论述并入不要包含原始资料的副本指引、不限期不是永久-解封指引与第二次机会、在本地启用安全投票及electionadmin权限、规范信息框内母公司子品牌的列出方式及修订用户名方针与用户页指引正在公示，如有意见请尽快提出。
• [讨论] 互助客栈方针区正在讨论赋予过滤器助理过滤器编辑权、将格式手册移动到MOS命名空间下、在非原创方针新增例子以禁止综合常识及可靠来源、扩充ITNR获选类别、根据WP:用户页对WP:用户框进行修订及被不限期封禁用户不应默认复审移除IPBE，请踊跃参与讨论。
• [讨论] 互助客栈技术区正在讨论修订过滤器警告信息，请踊跃参与讨论。
• [讨论] 互助客栈条目探讨区正在讨论请求协助批量移动日本参众两院选举条目及有关日本内阁条目的命名问题，请踊跃参与讨论。
• [讨论] 互助客栈其他区正在讨论是否应关闭中文维基百科以抗议基金会举措、管理人员任免制度检讨等事及本地部署安全投票及相关权限，请踊跃参与讨论。
• [讨论] 互助客栈试行案讨论区正在讨论讨论递进机制试行案-检讨意见分享，请踊跃参与讨论。
• [广告] 第四届台湾－斯洛伐克编辑松正在进行中，直到12月31日结束，欢迎踊跃贡献！

• [协作] 现有135个页面需维基化，401个条目需清理，49个移动请求正在讨论。

#	💭 话题	💬	👥	🙋 最新发言	🕒 (UTC+8)
1	关于Wikipedia:避免地域中心#地理，建议增加关于“来”字的论述	29	11	航站区	2024-12-09 14:46
2	修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应	79	7	自由雨日	2024-12-14 16:51
3	傀儡方针新增“被容许使用多重账号的行为”的情况（教育专案）	17	7	Reke	2024-12-06 01:09
4	将WP:格式手册所有方针与论述移动到MOS命名空间，并将MOS命名空间更名为“格式手册”	41	8	SunAfterRain	2024-12-13 16:47
5	应根据WP:用户页对WP:用户框进行修订	36	12	暁月凛奈	2024-12-13 18:12
6	赋予过滤器助理修改滥用过滤器权限	37	9	ATannedBurger	2024-12-14 12:10
7	提议维基百科:抄袭并入维基百科:不要包含原始资料的副本	37	7	HK5201314	2024-12-14 11:54
8	请求社群关注仲裁委员会在管理员的离任讨论中相关的权限问题	18	6	Gluo88	2024-12-14 05:08
9	重新讨论NT:MUSIC	21	9	Milkypine	2024-12-15 11:40
10	维基百科:命名常规 (人名)中的例子姜太公已经移动	3	3	魔琴	2024-12-13 05:23
11	建议Wikipedia:爱好者内容扩增“交通迷内容”方针之请求与讨论	6	3	HK5201314	2024-12-14 11:43
12	被不限期封禁用户不应默认复审移除IP封禁豁免权限	38	10	Cwek	2024-12-15 10:07

发言更新图例
最近一小时内
最近一日内
一周内
一个月内
逾一个月
特殊状态
已移动至其他页面 或完成讨论之议题
手动设置
当列表出现异常时， 请先检查设置是否有误

正在广泛征求意见的议题

以下讨论需要社群广泛关注：（重新整理）

维基百科格式与命名

Talk:加油！中村同学！！ § 建议更名：“加油！中村同學!!”→“加油！中村同學！！”

“加油！中村同學!!” → “加油！中村同學！！”：! or ！--HeihaHeihaHa-麻瓜了……（留言） 2024年11月21日 (四) 06:30 (UTC)

(－)反对，标题为东立正式名称[1]。--HelloYu0910（留言） 2024年11月21日 (四) 07:14 (UTC)

Talk:南华大学 (湖南) § 建议更名：“南华大学 (湖南省)”→“南华大学 (湖南)”

“南华大学 (湖南省)” → “南华大学 (湖南)”：原本的条目名是“南华大学 (湖南)”，不知道为什么要被移动到“南华大学 (湖南省)”。“湖南”已足够消歧义，且更符合习惯，类似中国地质大学（北京）（这里的括号不是维基百科的消歧义，但能体现常用的命名习惯）。--小林子冲（留言） 2024年11月23日 (六) 22:00 (UTC)

Wikipedia:消歧义#条目的命名：“请注意所使用的消歧义词亦应符合命名常规。”这里需要符合的是Wikipedia:命名常规#地名，即使用“湖南省”。另外本条目就是“南华大学”，括弧及其内的文字只是本站用来消歧义的，而中国地质大学（北京）就是“中国地质大学（北京）”，并不类似。--绀野梦人 2024年11月24日 (日) 07:44 (UTC)

Talk:亨利·比索 § 有关为非汉字文化圈人事物拟定香港译名的问题

该条目的中文部分由本人创建，一直利用香港音译将Bishop写成“比索”，早阵才留意到原来两年前由浅蓝雪将我的标题改为“亨利·毕晓普”，本人今天打算重新增幅，亦因为见已有Note TA而将标题改回为本人最初的用语时，却被一名称为向史公哲曰的骚扰，他以广东话叫法为“原创研究”不断回退我的修改，甚至不容许我用任何方式将“毕晓普”转换为“比索”，甚至强行将我一直撰写开的“比索”换为“毕晓普”，意图不容许我日后再进行增减时再使用“比索”一词。并且将香港惯常处理英文读音的方法定义为“原创研究”和“无心中生有”。现在更刚在本人的讨论页上留下所谓“严重警告”的恐吓。

从Google中我同意“毕晓普”、“毕夏普”的使用可能比“比索”为多，但向史公哲曰执着中文维基内只有使用“毕晓普”、“毕夏普”所以不可以有“比索”的写法再硬塞以“原创研究”来打压，完全是架空中文维基的包容性和容许多样化，对此我需要提出社群的建议。

或是当我被向史公哲曰的横蛮干预而无法再为条目贡献时，我宁可以创建者的身份申请废掉条目。--Foamposite（留言） 2024年12月1日 (日) 08:27 (UTC)

Talk:协调世界时 § 建议删除"现在时间"框

该框内显示的时间并不是当前的协调世界时,而只是上次按"刷新"获得的时间.该时间并没有实际意义.增加一个链接到显示当前协调世界时的网站即可.--Uwuw（留言） 2024年12月5日 (四) 18:55 (UTC)

维基百科方针与指引

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

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

Wikipedia talk:可靠来源 § （硕士论文）怎样的影响可以算作“显著学术影响”

• “硕士学位论文通常未经类似评估，因此不如博士学位论文可靠，除非其具有显著学术影响。”是否需要用信息页说明“显著学术影响”？
• 对于一般的（无“显著学术影响”）硕士论文而言，相关行文似乎也有模糊之处，只点出硕士论文“不如博士论文可靠”，而未明言其“不是可靠来源”。是否需要点出“除非具有显著学术影响，否则硕士论文不是可靠来源”（英维是明确点出的：“Masters dissertations and theses are considered reliable only if they can be shown to have had significant scholarly influence.”）？--自由雨日🌧️（留言｜贡献） 2024年10月23日 (三) 16:21 (UTC)

Wikipedia talk:消歧义 § 2020年10月修订案与格式讨论

修订案主要涉及#章节安排问题（最简单的做法只需将一个三级标题改为二级标题），以及#修订WP:消歧义命名的问题。格式讨论涉及主从消歧义页面编写方式（若有必要则亦应修改指引）。——自由雨日🌧️（留言｜贡献） 2024年10月25日 (五) 04:39 (UTC)

Wikipedia talk:管理员的离任 § 仲裁委员会成立后的管理人员解任机制（续）

经共识订立的仲裁机制及其他过往讨论中均就仲裁委员会在处理管理人员解任案获得社群广泛同意，在维基百科讨论:仲裁委员会#管理人员解任中就达成了“仲裁委员会有权调查管理人员行为是否失当后交社群再行决议”，但就仲裁委员会如何行使有关职权仍有待商榷。我想将这个议题分拆成多个部分去探讨，期望获得最大程度的共识。本讨论分为以下部分：

1. 弹劾机制；
2. 纠举机制；
3. 直接除权；及
4. 依请求介入社群程序。

(※)注意：此四机制并非仅能采纳其中一个，这四个机制的设计是完全可以共容的。

--路西法人 2024年10月27日 (日) 16:39 (UTC)

Wikipedia talk:封禁方针 § 完善WP:封禁“不限期不是永久”总方针

所谓“不限期”不应理解为“永久”，但WP:封禁并没有指引给管理员对解封的指引，以确保符合这个目的。对此，建议修改WP:封禁方针，引入担保制及对巡查员或回退员进行扩权，以进行有条件解封。

想法：

• 管理员需就不限期封禁用户的封禁理由写上解封条件。
• 不限期封禁用户可在完成解封条件后找廷伸确认用户请求担保
• 由廷伸确认用户向管理员确定不限期封禁用户已完成解封条件，并声明会负责监督该名用户的编辑。
• 廷伸确认用户监管不力的话，会被剥夺担保资格。
• 巡查员或回退员对该名用户的编辑进行二次确认。
• 直至管理员认为那名编辑者真诚悔改，然后解除监管。
• 只要担保者决定不对该名用户进行担保或 巡查员或回退员 认为编辑有问题，随即启动即时封禁程序，解封条件会较上一次更严格。

好处：减低管理员的工作压力，从而达到不限期不是永久的目的。--唔好阻住我爱国（留言） 2024年11月9日 (六) 04:02 (UTC)

Wikipedia talk:非原创研究 § 关于非原创研究问题

1.假设美国某媒体报导：“2024年2月30日，川普发表了一场讲话，关于他上任后会征收关税。”

那么，我可不可以基于上述资料，断定美国将会在川普上任后会征收关税？

2.假设英国某媒体中文版报导：“2025年2月31日，白悟空将2026年2月31日于Google Play上架”

那么，我可不可以基于上述资料，断定白悟空不能在中国下载？

相关讨论：Wikipedia talk:格式手册/电视#对于刚订立的格式手册/电视，细节上的疑问--唔好阻住我爱国（留言） 2024年11月19日 (二) 11:21 (UTC)

Wikipedia talk:格式手册/两岸四地用语 § 提议容许中华民国（中华台北）体育代表队使用“中华队”简称

中华民国（中华台北）体育代表队使用“中华队”简称，乃其来有自。又无论“中华民国（代表）队”或“中华台北（代表）队”，均可简称为“中华队”，行文实较简易，且得维持一致格式。故比照港澳代表队之例，建议放宽格式手册规定，容许首次提及中华民国或中华台北代表队完整名称后，于条目正文（不包含表格及模板等）使用“中华队”简称；与此同时，仍继续禁止使用“中华”称呼，避免过度歧义。望社群斟酌。若有其他方案，亦可一并提出。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年11月26日 (二) 18:32 (UTC)

Talk:亨利·比索 § 有关为非汉字文化圈人事物拟定香港译名的问题

该条目的中文部分由本人创建，一直利用香港音译将Bishop写成“比索”，早阵才留意到原来两年前由浅蓝雪将我的标题改为“亨利·毕晓普”，本人今天打算重新增幅，亦因为见已有Note TA而将标题改回为本人最初的用语时，却被一名称为向史公哲曰的骚扰，他以广东话叫法为“原创研究”不断回退我的修改，甚至不容许我用任何方式将“毕晓普”转换为“比索”，甚至强行将我一直撰写开的“比索”换为“毕晓普”，意图不容许我日后再进行增减时再使用“比索”一词。并且将香港惯常处理英文读音的方法定义为“原创研究”和“无心中生有”。现在更刚在本人的讨论页上留下所谓“严重警告”的恐吓。

从Google中我同意“毕晓普”、“毕夏普”的使用可能比“比索”为多，但向史公哲曰执着中文维基内只有使用“毕晓普”、“毕夏普”所以不可以有“比索”的写法再硬塞以“原创研究”来打压，完全是架空中文维基的包容性和容许多样化，对此我需要提出社群的建议。

或是当我被向史公哲曰的横蛮干预而无法再为条目贡献时，我宁可以创建者的身份申请废掉条目。--Foamposite（留言） 2024年12月1日 (日) 08:27 (UTC)

Wikipedia talk:维基百科不是什么 § 出版书籍、杂志是否为WP:NOT

如题所述，请教以下情况什么时候属WP:NOT及判定依据?

• A)条目收录自行出版之书籍或论文(有一手来源、但没有二手、三手来源)；
• B)条目收录自行出版之书籍或论文(有二手、三手来源)；
• C)条目收录非自行出版之杂志，杂志内容包括照片、采访(有一手来源、没有二手、三手来源)；
• D)条目收录非自行出版之杂志，杂志内容包括照片、采访(有二手、三手来源)；
• E)条目收录非自行出版之杂志，杂志内容包括照片，但没有采访(有一手来源、没有二手、三手来源)；
• F)条目收录非自行出版之杂志，杂志内容包括照片，但没有采访(有二手、三手来源)；--Abcet10（留言） 2024年12月4日 (三) 14:31 (UTC)

Wikipedia talk:关注度 (人物) § 修订政治人物关注度指引

现拟修订WP:关注度 (人物)如下：

现行条文 政治实体及一级行政区的领导阶层（例如总统、总理和首相等等）、法律上或事实上最上级及一级行政区行政机构的成员（例如，内阁成员、中共中央政治局常委）、立法机关的议长、议员或代表。

提议条文 现任、曾任及／或候任国际级、国家／地区级及／或（采用联邦制或类似政治体制的国家的）一级行政区级权力机关的重要实权公职及／或立法机关成员。 参考资料

Sanmosa _{Samāʾun la-ʿamruka ʾaw ka-s-samā} 2024年12月13日 (五) 15:59 (UTC)

维基百科提议

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

原标题：SecurePoll elections with the electionadmin right

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

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:互助客栈/其他 § WMF考虑向印度法院披露编辑身份信息，本站是否应该关站抗议

原标题为：WMF考虑向印度法院披露编辑身份信息，英维正在讨论关站抗议

参见：亚洲国际新闻诉维基媒体基金会案、Wikipedia:页面存废讨论/记录/2024/11/14 § 亚洲国际新闻诉维基媒体基金会案、en:Wikipedia:Community response to Asian News International vs. Wikimedia Foundation、en:Wikipedia:2024 open letter to the Wikimedia Foundation和en:Wikipedia talk:2024 open letter to the Wikimedia Foundation § Update from 14 November hearing

2024年11月14日17:29 (UTC)，也就是几个小时以前，英文维基百科用户发起民意调查，讨论是否就基金会考虑向印度法院披露编辑身份信息而闭站抗议。如果英维闭站抗议，本站是否跟随？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月14日 (四) 20:09 (UTC)

整理引导新手的相关页面

目前用以帮助新人的页面实在庞杂。WP:欢迎、WP:入门、H:简介和WP:参与贡献内容都大差不差；WP:新手上路感觉也可和WP:第一印象等分享感受的页面合并；H:从这里开始是不是另一种WP:新手简明指南呢；WP:线上训练整得不明不白，又出来了WP:维基百科大历险。这些页面看似相同，实际偏向主题各不相同，但是新手看来只会感到困惑；且目前想快速编辑的新手也很难直接找到有用的帮助，是否应该参照英维在侧边栏放入引导页面的链接呢，比如H:简介。--甘糸（留言） 2022年11月7日 (一) 02:57 (UTC)

很搞笑的事情是主页上的“人人可编辑”链接转到WP:欢迎，左右两边都是navbox，各种鲜艳晃眼的色彩。反观英维就好看得多了。--0xDeadbeef（留言） 2022年11月9日 (三) 10:27 (UTC)

WP:欢迎其实完全可以被H:简介取代。--BlackShadowG Slava Ukraini! 2022年11月9日 (三) 13:34 (UTC)

有一种上世纪网页的美，花花绿绿，要是再来点滚动屏就更像了^{[开玩笑的]}----诚挚的 ZhaoFJx^{（论•编）} 2022年11月14日 (一) 14:49 (UTC)

怕搞混的话，就在最上方放“论述”也行吧！空气小猫（留言） 2022年11月15日 (二) 06:55 (UTC)

• 尽管支持，这可是个大工程。--Temp3600（留言） 2022年11月15日 (二) 16:46 (UTC)

建了个协作页面：WikiProject:维基百科发展/新手2023，个人觉得创建条目相关页面也需要优化整理。 ——魔琴 [ 留言 贡献 ] 2022年11月18日 (五) 09:08 (UTC)

认同有改革之必要，以确实分流。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年11月25日 (五) 18:18 (UTC)

话说这些页面的讨论页也挺乱的orz —— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年12月4日 (日) 16:27 (UTC)

下面有必要挂{{不存档}}吗？这应该是一个比较长期的工作，如果没有用户有意帮忙整理这些页面，似乎讨论串开着意义也不太大。--BlackShadowG Slava Ukraini! 2022年12月6日 (二) 12:21 (UTC)

那就先撤除模板吧，改日有进度再议。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年12月16日 (五) 17:03 (UTC)

老实说，目前wikiedu.org已经备有学生和教师的线上训练，但全都是英文版。

虽然说保留本地版本的线上训练是没问题的，但小弟粗略看过了一下，还有不少页面有待创建…--飘流书生（见山 · 客栈 · DC20） 2022年12月20日 (二) 15:26 (UTC)

看了这些文章我脑子已经晕了……

这里以读者看到页面的顺序，介绍一下我的思路，这是一个力求页面数最少的方案，读者在入门之前只需要看WP:关于和WP:参与贡献两个页面。

• 读者应该可以从首页进入WP:关于和WP:参与贡献（或者下面第三点提到的合并后的页面）。手机版主页也应该要有。
• 把WP:参与贡献的内容移动到WP:关于，后者应该包含维基百科简介、邀请加入的广告，顺便求他们捐款。（不过WP:参与贡献的界面做得不错，删了有点可惜）
• 把WP:欢迎和WP:新手入门/主页合并（我觉得WP:参与贡献才是最佳名称）。邀请读者注册账号，同时明显给出中国大陆用户无法编辑和注册的解决方案。此处开始给出求助方法（互助客栈）。第二页WP:新手入门/介绍开始入门。
• 继续往下，新手入门的其他部分不变。H:简介的那一堆按钮可以考虑放到新手入门里。

大概这样吧，之后再补充。--HSUZR（留言） 2023年1月2日 (一) 15:39 (UTC)

补充一下，我这种方案有两个缺点。一是会使WP:关于文字太多、过于臃肿；二是WP:欢迎起到了分流效果，把人分为可能想加入维基百科的人和普通读者，而这种方案让分流效果没了。如果让WP:关于来分流，它会变得更臃肿。--HSUZR（留言） 2023年1月2日 (一) 15:56 (UTC)

个人感觉WP:欢迎和Wikipedia:新手入门/主页都需要存废，但二者在中维确实影响巨大。关于分流，可以将想编辑的转到H:简介，普通读者阅读WP:关于就行。WP:参与贡献和WP:关于倒是改版成英维的形式比较好。--PexEric 💬|📝 2023年1月24日 (二) 07:10 (UTC)

感觉WP:参与贡献的东西太多了，而且分页里面还有一堆链接，我都懒得看 囧rz…… ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年2月27日 (一) 18:02 (UTC)

新手编辑疑难支援

不另开新文，话说咱们应另行创建一个供新手询问有关编辑事宜的地方（感觉既有的wp:VPD不太适合）。参考英维，新手大多所问的，均与一些编辑上的疑难有关。

而事实上，英维在其IRC免责声明页上有这样一句：

“ Help is provided by volunteers, so it might take a few minutes before someone replies to your question. Try leaving the chat window open for a bit. If you don't get a reply before you need to leave, consider asking your question at the Teahouse instead. ”

故此，我们需要在既有站外疑难解答群的基础上，另行创建一个站内版本，为新手编者提供询问疑难的另一渠道。暂时茶馆页面已成雏形，有兴趣可以看看。另可(＆)建议将wp:RD按不同主题分拆，欢迎讨论。—飘流书生（见山 · 客栈 · DC20） 2022年12月19日 (一) 04:25 (UTC)

对于茶馆，个人持正面态度，惟担忧加剧叠床架屋之局面；对于知识问答，个人强烈推荐停止使用结构式讨论，此技术非常不利于查询及追溯过往话题。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年12月20日 (二) 13:23 (UTC)

天灭结构式讨论，加载起来巨慢，而且还不能查找 ----顺颂时祺 ZhaoFJx^{（论•编）} 2022年12月21日 (三) 14:44 (UTC)

那么WP:VPA呢？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2022年12月31日 (六) 06:28 (UTC)

虽然新手亦可使用既有之询问台（即wp:VPA），但这里提议之“茶馆”概念，则是一个专为新手而设的问答平台，在友善的环境（没错，新手最需要的就是这个！）下，由“茶馆主持人”解答新手编辑疑难（参考这里以了解成为茶馆主持人的要求）。

具体细节还可以再讨论，毕竟现阶段还只是个雏形而已。--飘流书生（见山 · 客栈 · DC20） 2023年1月6日 (五) 07:22 (UTC)

• 标准答案是Wikipedia:互助客栈/求助，然而不太方便。--Temp3600（留言） 2023年1月8日 (日) 15:19 (UTC)

  既然说了“不方便”，那么解决方法是什么？这里提出的“茶馆”概念，正是以“为新手提供一个方便、友善的询问处所”为理念而创建的一个新页面。现有的wp:VPA仍旧可以保留，但茶馆的实践细节（包括本地化）仍有待各位一同讨论。--飘流书生（见山 · 客栈 · DC20） 2023年2月7日 (二) 15:28 (UTC)

  注：WP:茶馆已创建。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年3月7日 (二) 16:43 (UTC)

新人小工具配置指南

刚刚突然想到，新人其实欠缺很多常用小工具，必须先学习配置.js，有些实用小工具甚至连资深用户也未必了解。有否可能编制一份新人小工具配置指南?--Temp3600（留言） 2023年1月17日 (二) 11:32 (UTC)

这让我想起U:AT/js……啊，好像咕咕了 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年1月17日 (二) 12:37 (UTC)

对对，最好弄出一整块代码，新人复制到js 就可以立即使用。--Temp3600（留言） 2023年1月17日 (二) 13:33 (UTC)

@Temp3600：你是指怎样安装小工具的教程还是怎样使用小工具的教程？（虽然我感觉两个教程都能编制一下就是了）Sanmosa _{Συ γάρ μοι και μοίρα εί και τύχη} 2023年1月17日 (二) 12:39 (UTC)

的确两方面都需要。先弄出"一键式常用小工具安装教学"，再逐个小工具手把手教。不然新人就会觉得维基很多事情都要打一大串代码，根本办不过来，其实是依靠工具自动产生的。--Temp3600（留言） 2023年1月17日 (二) 13:41 (UTC)

做个小工具，自动对非自确用户启用？--洛普利宁 2023年1月18日 (三) 08:09 (UTC)

我觉得可以在小工具设置中新辟一区，罗列常用之小工具，以便新手直接批量勾选启用。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年1月18日 (三) 08:31 (UTC)

我刚刚去翻了一遍自己启用的小工具和用户脚本，实话说，我其实没注意到有小工具对新人而言帮助很大。目前小工具以协助维护工作居多，比如最常用的TW、Rater、HotCat、DisamAssist、HotDefaultSort都是协助维护工作的，对于刚学会编辑的新人而言帮助其实不算很大。--BlackShadowG Slava Ukraini! 2023年1月18日 (三) 11:38 (UTC)

先教“如何自动填充cite模版”。--Temp3600（留言） 2023年1月19日 (四) 14:35 (UTC)

是指Help:如何引用来源中提到的Wikipedia:参考文献工具列/2.0吗？印象中这个工具好像是默认启用的。--BlackShadowG Slava Ukraini! 2023年1月20日 (五) 04:02 (UTC)

得教怎样用。我早一阵子才知道那个放大镜是“自动填充”功能。--Temp3600（留言） 2023年1月21日 (六) 05:57 (UTC)

我是WP:自动退出的触发原理揭露时才知道有这玩意 囧rz……说到这，我记得台湾分会有针对这个的教学。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年1月24日 (二) 07:56 (UTC)

现在默认还不是可视化编辑吗？我记得这件事以前讨论了很久。2.0是只有source才有的功能。----Cat on Mars 2023年2月8日 (三) 05:34 (UTC)

新版编辑器更突出自动引用网址功能，我认为应该推荐新手使用。若担心可视化编辑器的一些问题，可使用（2017）源代码编辑器。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年1月24日 (二) 12:25 (UTC)

总觉得让新手用这些工具不太妥当，有点担心玩火上身或者不慎破坏之类的？像{{cite}}这些模板现在都可以用可视化编辑器来填充，别的工具大部分也是是锦上添花（？）——顺颂时祺 ZhaoFJx^{（论•编）} 2023年1月20日 (五) 15:39 (UTC)

没有外在工具，要画一个表格已经非常困难。--Temp3600（留言） 2023年1月21日 (六) 06:00 (UTC)

可视化编辑器和新版编辑器似乎都可以帮助画表格。--PexEric 💬|📝 2023年1月30日 (一) 09:23 (UTC)

@PexEric：不是似乎，是可以。作为一个采用新版源代码编辑器的编者，小弟不知试过直接利用“表格”按钮加入过多少表格了…--飘流书生（见山 · 客栈 · DC20） 2023年2月8日 (三) 00:56 (UTC)

这串又没动静了……我个人建议是整理出来两个页面，其中一个侧重编辑的直接塞在左侧栏里。毕竟就算有14亿+人说中文，中维活跃用户甚至比不上德维的一半……--ときさき くるみ 2023年2月17日 (五) 22:36 (UTC)

不知道有多少是被 Wikipedia:IP封禁例外 挡住的，如果可以在该拦截处能统计一下就好了。--Kethyga（留言） 2023年2月23日 (四) 14:27 (UTC)

建议将Wikipedia:不要诉诸法律威胁提升为法律方针

有鉴于最近发生的某些事件，我建议将WP:NLT正式升级为法律方针（如同英文维基百科），虽然可能没办法完全阻止类似的事情再次发生，但至少有个可以遵循的依据。--冥王欧西里斯（留言） 2022年11月20日 (日) 23:28 (UTC)

这是否需要法务或者具有法律背景的用户看看是否符合法律要求啊？--百無一用是書生 (☎) 2022年11月21日 (一) 03:04 (UTC)

或许，需要找人看看。--冥王欧西里斯（留言） 2022年11月21日 (一) 03:17 (UTC)

可能直接寄信给WMF法务部门请他们来看比较快？--SunAfterRain 2022年11月21日 (一) 09:07 (UTC)

页面未完善（有一句未翻译内容）和不算稳定。“法律方针”的概念？社群有权定义法律方针吗。也许更适合定为态度指引，但然严厉性可能弱很多。需注意，除了诉诸诉讼和举报，其他对行为合法性的暗示也可能在内和引致同等效果。非站内行为要约束吗，也许较难实现，但似乎很有意义（如WP:OA2021），但验证、警告和处置会相当麻烦。--YFdyh000（留言） 2022年11月21日 (一) 04:21 (UTC)

法律方针是指“These are policies with legal implications”。“不要诉诸法律威胁”此处理方式确实可能会造成法律上的影响。而英维亦将此视为法律方针。谢谢。--SCP-0000（留言） 2022年11月21日 (一) 04:41 (UTC)

那句应该是从英文维基百科来的，但说真的我也看不太懂那句是想要表达什么。--冥王欧西里斯（留言） 2022年11月21日 (一) 05:28 (UTC)

看上下文是违反这些方针的内容不受WP:NOTCENSOR限制，可以管辖条目内容。-Mys_721tx（留言） 2022年11月21日 (一) 05:40 (UTC)

那我有更多问题了。法律威胁关条目内容什么事？升格作法律方针又有什么效力/效果？这种经纪公司直接见一个ban一个不就行了吗？-某人✉ 2022年11月21日 (一) 08:31 (UTC)

(＋)赞成，对于某些法务方面的疑难，的确需要订立方针加以规范，免得用户们无意中触法。--Jiaweipan（留言） 2022年11月21日 (一) 09:24 (UTC)

“无意中触法”与此方针是相悖的吧。--YFdyh000（留言） 2022年11月21日 (一) 10:23 (UTC)

目前我跟下方LuciferianThomas君的观点比较像，虽然目前只是论述页面，也已有与此相关的封禁事件，但毕竟只是论述而非方针，将其提升为法律方针更能确立标竿，让管理员与其他社群成员面对类似事件时更有底气解决。--冥王欧西里斯（留言） 2022年11月22日 (二) 11:40 (UTC)

(＋)支持。正式订立为法律方针可以确保针对法律威胁的封禁能够有明确依据下执行。现今有关法律威胁的封禁一般都仅以无任何地位的WP:LEGAL作为封禁理据，当然执行上并非一定有问题，但实际上仍然是一个程序漏洞可以给人钻。--路西法人 2022年11月21日 (一) 14:56 (UTC)

我记得以前也有人以法律方式删除条目内不实内容：杨受成控告维基媒体基金会事件，对方只要有心走法律途径也能处理那些内容，当然这需要钞能力。--Nostalgiacn（留言） 2022年11月22日 (二) 08:21 (UTC)

“已截图存证”算是什么样的法律威胁？我真是想不明白啊。而且也不需要给这样多的例子吧。--Ghren🐦🕓 2022年11月22日 (二) 08:25 (UTC)

毕竟有唐泽贵洋（帮在2chan遭到网暴的高中生，顺着IP让不少人入狱）的情况，虽然也很少见啦。--Nostalgiacn（留言） 2022年11月22日 (二) 08:47 (UTC)

截图的法律效力较弱，但哪些是法律威胁，哪些是正当或不当的威胁/警告提醒/沟通态度问题，还是很难说。比如“您在本条目的所为已存档并转交我司相关部门/人员”，是法律威胁呢，还是表示不满+等待后续沟通的意思，换成“法务”就一定是法律威胁吗，不明说就无事吗。“已对相关发言进行公证”“已对相关发言进行永久存档（网页存档）”在同一场景中有多少本质区别。涉嫌网暴、人肉搜索等风险的非法威胁，是否不考虑同等规制，而且起诉是权力，威胁才是不当的。--YFdyh000（留言） 2022年11月29日 (二) 16:06 (UTC)

截图的法律效力较弱？看看香港的立场新闻涉煽动案件，其实截图都可以作为法律证据。--Wpcpey（留言） 2022年11月29日 (二) 16:15 (UTC)

未经公证不能保证未篡改，无法作为证据，所以个人“已截图”说是法律威胁比较牵强。如果已截图算，已保存网页、已记录永久链接难道也算法律威胁了。--YFdyh000（留言） 2022年11月29日 (二) 17:41 (UTC)

那看起来截图那条可以移除或是移动到其他相关的页面，其他的例子呢？--冥王欧西里斯（留言） 2022年11月30日 (三) 03:13 (UTC)

复看了一下，也可能是当时管理员自作主张移除掉（虽然理由是以“没有来源及来源可信度不明”移除内容）？虽然现在的话，可以用Wikipedia:修订版本删除请求的RD2、RD4来申请版本移除。就算声明了发律师函给基金会，也要等基金会是否接受和以基金会行动的方式来直接处理，本地对于这种现实法棍没必要理会。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月22日 (二) 10:15 (UTC)

(＋)支持：我的意见同LuciferianThomas君。--~~Sid~~ 2022年11月22日 (二) 15:51 (UTC)

是说目前似乎无人明显反对，能进公示流程了吗？--冥王欧西里斯（留言） 2022年11月29日 (二) 02:58 (UTC)

送公示吧。--路西法人 2022年11月29日 (二) 14:53 (UTC)

上方有些意见值得重视，但都未有展开有效讨论。--Xiplus#Talk 2022年11月29日 (二) 15:34 (UTC)

看起来下面部分条文已经有可用的版本出来了。--冥王欧西里斯（留言） 2022年12月11日 (日) 14:01 (UTC)

同xiplus.建议将提升为法律方针与更新案分开公示，两案皆通过后再同时执行。--Temp3600（留言） 2022年11月29日 (二) 16:12 (UTC)

那么法律方针本身的文字更新应该可以先公示了。--冥王欧西里斯（留言） 2022年11月29日 (二) 23:53 (UTC)

方针列表#法律方针不是任何指引。不需要公示。--Ghren🐦🕖 2022年11月30日 (三) 11:01 (UTC)

对于例子依然觉得不妥。例子重复，而且引用同一案的说话也不免太多了。--Ghren🐦🕖 2022年11月30日 (三) 11:10 (UTC)

不如阁下直接动手改？--冥王欧西里斯（留言） 2022年11月30日 (三) 11:39 (UTC)

(＋)部分支持：提出司法控诉、保留法律追究权、向警方报案，明确表示采取法律或行政手段，造成损害人身安全的风险；若被职员认为社群缺乏自我约束的能力，因此导致基金会行动，结果不是所有人乐见的。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

(－)部分反对：具体细节需要讨论。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

阁下可在下方的逐条讨论发表意见。--冥王欧西里斯（留言） 2022年12月2日 (五) 23:45 (UTC)

谢谢您的提醒，新增条文以浅绿色显示，删除条文以浅红色显示。 -- 月都 ※ 2022年12月3日 (六) 07:12 (UTC)

部分需要轻微修改；理解法律威胁章节，我认为中心句以外的需要重写，至少清晰化条文。 -- 月都 ※ 2023年1月26日 (四) 13:46 (UTC)

(＋)支持--Fox6667（留言） 2022年12月3日 (六) 18:02 (UTC)

(＋)支持。--Kriz Ju（留言） 2022年12月5日 (一) 19:01 (UTC)

(！)意见：“法律威胁的结论”一节加上“在被封禁前应该提醒用户不要诉诸法律威胁”之类的内容。理由：1.不是所有人都知道这一方针 2.用户可能并不是这个意思而对方会“感受到”法律威胁--落花有意12138 _{论 回复请ping我} 2022年12月21日 (三) 09:02 (UTC)

@冥王欧西里斯：(！)意见 导言第二行“您不应该发布法律威胁，而是应该尝试依照维基百科解决争议的程序来处理”后加上“除非前述程序未能达成您希望的结果”。理由：我们应当排斥的是不讨论就采取法律程序，而不是限制合法权利( π )题外话各位注意“权利”和“权力”的区别。--落花有意12138 _{论 回复请ping我} 2022年12月21日 (三) 10:12 (UTC)

反对落花有意的修订建议，违背LEGAL方针的本意，就算无法达成希望的结果，维基百科也不是发布法律威胁的地方。--路西法人 2022年12月21日 (三) 11:37 (UTC)

@LuciferianThomas：如果对方没有达成希望的结果，那么其自然会采取法律手段。目前定义的法律威胁包括通知已经采取法律手段。我认为这一通知应当被允许，因为社群提前知道对方采取法律手段比不知道要好。--落花有意12138 _{论 回复请ping我} 2023年1月17日 (二) 12:59 (UTC)

(！)意见：自然会采取没错，然而一旦获得通报，亦非平台鼓励之事，尤其严重伤害此平台立意宗旨的告知；而所谓比较好，请问如何比较好呢？还请落花君明示，谢谢。下方段落的条文有谈到并未全然断绝用户告知之权利，而是让管理员有较大空间裁处，只是告知和威胁难谓泾渭分明，也有滥用或技巧性使用、游走灰色地带之空间，因此若单论线上编辑行为或线下聚会活动，个人认为基本上此平台不欢迎动辄告知或通知采行法律途径。请热心站友可参阅下方段落。--Kriz Ju（留言） 2023年1月17日 (二) 19:14 (UTC)

(！)意见：用户拥有兴讼之合法权利或采取各式法律途径，是个人自由和行为，而法律恫吓或要胁并非一般站内或社群相关活动应容忍之事，况且诉诸法律者即便不知道站内规范，亦绝无可能于当下毫无诉诸法律之用意，也就是总不可能不知道自己正在告知或施压对方；反过来讲，站内程序是否让自己满意，亦非有心于站内活动者公开或私下对他人扬言采行法律途径，却无适当理由之借口。也就是说，人人可以有随意法律兴讼的自由，而站内和社群也可以有阻止此类用户于此平台或社群内活动的权利；至于法律争议孰是孰非，正因法律事件样态复杂，个人才会建议授权管理员决定适当的处理措施。--Kriz Ju（留言） 2022年12月21日 (三) 17:27 (UTC)

@Kriz Ju：用户的确可能宣布采取法律途径，而不知此站不允许宣布。一些用户可能并没有注意到维基百科与其他网站的不同，而这一常见的疏忽不应当成为封禁的理由。“诉诸法律”和“法律威胁”在语义上显然不同，但目前社群对其的定义并没有体现这一不同，我也提醒您注意不要混淆它们。我注意到，您认为“站内程序是否让自己满意，亦非有心于站内活动者公开或私下对他人扬言采行法律途径，却无适当理由之借口”，同时也认为“人人可以有随意法律兴讼的自由”。我是否可以认为，用户可以采取法律行动，但不可以告诉对方？我认为，用户声明已经或者将要采取法律途径解决问题，应当被允许；因为社群知道这一信息有助于当事人采取适当行动和社群共同解决问题，同时禁止这一行为有悖于法治的理念和社会共识。--落花有意12138 _{论 回复请ping我} 2023年1月17日 (二) 13:30 (UTC)

不好意思，在本站而言最常发生的“诉诸法律”在我看来通常就是一种威胁，否则试问为何对他人要诉诸法律呢？还是有什么要争取的？至于不知道相关规范，自然也会获得热心用户的警醒，这点倒不成大碍。至于告诉对方，“用户可以采取法律行动，但不可以告诉对方？”，您似乎没看到可适当告知对方，惟须注意已先采行站内调处程序，并避免公开宣扬、胁迫；换言之若争执两造因故（不论因为线上或实体活动之事由）一个要告上法院，一个通报回社群，两者皆存在、并不冲突，只是会闹到因为这里的事情诉诸法律，究竟何事呢？与其说“社群知道这一信息有助于当事人采取适当行动和社群共同解决问题”，请问为何不先以站内程序解决问题呢？而若因个人因素执意采取法律程序，请问“当事人采取适当行动和社群共同解决问题”所指为何呢？既已执意提告，如何行动呢？社群又能怎么共同解决呢？请问这与“法律威胁”差异何在呢？不会有寒蝉效应吗？若有明确事例，请举例。

法律事件复杂之处在于事件样态繁复且具衍生性，必须具体视情况讨论。举例而言，若双方因站内宣布或公告举办的相关线下推广活动于现实中见面发生纠纷，不论为了何事，一方提告另一方，站内亦根本无从实质从法律论断是非，比如：有人因站外活动被对方打而提告，施暴一方反举报回站内，主张自己被诉诸法律，管理员是否应该封禁该名因遭到施暴而提告的用户？若双方因线下的实体推广活动产生金钱纠纷而兴讼，又举报回站内，管理员是否封禁该名诉诸法律的提告用户？又或者双方互相提告、互控性侵并通报站内，双方皆指控对方对自己进行法律恫吓，管理员是否应该同时封禁两名用户？再或者两位用户于参与线下活动后，再转往他处进行私下活动，算不算站内相关活动呢？此时若发生争议产生法律纠纷是否应如何论处？甚至若争执的用户两造先因平台推广相关活动有债务关系在前（比如一方借贷予另一方举办线下实体活动），双方合意以站内互助活动如何相抵，结果欠钱的一方未于站内履行约定，并且拒不认债、长期拖欠，而债权人因讨债未果私下扬言提告，债务人反通报回站内，试问管理员该如何看待此事？上述事由之法律争端可能造成社群各种困扰，亦已超出站务人员所应或所能负担之范畴，难以论断，因此下方段落的条文才言明“获通报至站内，便可能构成管理员裁量是否以封禁账号等方式处理之理由。”，也就是管理员可自行裁量，未必直接封禁账号，相关用户亦因此才有机会停止无建设性之不良互动，而平台和社群亦无法实质介入、协助或干预实体的法律程序，只是站内、外的平台直接相关活动若产生争议未经站内机制适当调处便扬言或告知诉诸法律以要胁对方，并非此平台应允之事（这里的所谓“法律威胁”通常指用户间在站内、外活动中，因本站的相关内容和活动而扬言可能将诉诸法律的类型），基金会行动亦已主张此事了（也因此将用户行为规范之效力延伸至线下相关活动、或运用规管为平台内容和活动范畴之用户行为准则）。更何况如果单只是有人对页面内容或什么机制不满意，动辄诉诸法律押著别人就范显然不妥，而站内亦已提供适当处理机制，诉诸法律应为最后一步的个人选择，就敝人的认知而言大致如此运作；实际上，若就条目内容或平台机制争议而言，究竟有何需要告知诉诸法律呢？到底还有什么真正和站内外活动相关结果弄到要告人的情形呢（最常见就公众人物、演艺公司、私人业者的告知吧）？而敝人不太清楚您说的法治和社会共识所指为何，尤其各地域法律有别，还请明言，谢谢。--Kriz Ju（留言） 2023年1月17日 (二) 21:18 (UTC)

因此，敝人已于下方段落说明“用户之间若因维基百科站内相关活动产生法律纠纷，并获通报至站内，便可能构成管理员裁量是否以封禁账号等方式处理之理由。由于存在利益冲突，陷入法律纠纷的编辑者不应编辑与纠纷有关的条目，相关用户亦应停止无建设性之不良互动。”；“由于各式法律争议不一而足、样态复杂，且身为志工之管理员通常实无必要或义务主动涉入其中，抑或心力或能力不足，加上此类争端可能是非难论，此处建议赋予管理员较大之裁量空间。”；以及“争端仍回归相关当事人之实际沟通状况，以及管理员若获报后之实务判断。”下方讨论还烦请参阅，谢谢。--Kriz Ju（留言） 2023年1月17日 (二) 20:00 (UTC)

基于本地实际之各自诸种逻辑演绎等并非与参照语文体系之同一活动有一致之基础传统，本地化过程必须投入更多加以厘清和研判关联之纠纷事态等多样演绎，社群及社区有需要考虑到本地语文圈与参照语文圈之明显法理历史背景差异，对于判读本地日常实践之宣誓解决行动个案等，适宜同时参考有关本地认知因素和系统偏好、鉴识对应之行为理念和认识，即需判明限于本地语文背景基础因素下之、非普世价值背景因素下之律令性质威胁定义，而这一本地化过程如果有所滞后，个人认为是不足以支持该案达成应当达致之协助社区目标，也难以进一步讨论所谓允许什么情况采取什么行动去怎么保障社区成员之必要利益。--约克客（留言） 2023年1月19日 (四) 02:03 (UTC)

逐条讨论

本章节对于特定条文进行深入讨论，我已列出的都是与英文维基百科不同的，或是我不确定翻译的，未列出则表示条文与英文维基百科一致，如果您觉得有其他条文需要讨论，请按格式列出。为避免版面混乱，如果您认为条文都没有问题，请不要对每一项都写{{支持}}，请写在前一个段落，这不是投票，请不要仅留下{{支持}}而不留下意见。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

先改了报告地点与有偿编辑的部分。--冥王欧西里斯（留言） 2023年1月10日 (二) 08:33 (UTC)

看起来逐条讨论的部分都改得差不多了？应该可以进入公示流程了？--冥王欧西里斯（留言） 2023年2月9日 (四) 02:49 (UTC)

（方针名称）“不要诉诸法律威胁”

“法律威胁”一词直接翻译自en:Legal threat，但曾有人建议翻译成“不要威胁诉诸法律”，发动法律行动实际上会称为“诉诸法律行动”，而该方针是禁止“威胁要诉诸法律行动”，故缩短为“威胁诉诸法律”，但该称呼似乎会跟en:Appeal to the law混淆。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

另建议动词可以不要用诉诸，可改为“发布”、“张贴”等。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

如果是这样的话，不如改用张贴吧。--冥王欧西里斯（留言） 2022年12月1日 (四) 06:47 (UTC)

(＆)建议：页面标题维持现状。序言章节已有「不要在維基百科上發佈法律威脅」，诉诸法律威胁的意思是利用法律威胁途径解决问题。 -- 月都 ※ 2022年12月3日 (六) 07:27 (UTC)

(！)意见：个人倾向维持原标题。--Kriz Ju（留言） 2022年12月5日 (一) 19:02 (UTC)

(！)意见：看了一下，还是维持原标题好了，改成发布或张贴似乎反而怪怪的。--冥王欧西里斯（留言） 2022年12月14日 (三) 07:18 (UTC)

（简而言之）

除直接翻译外，加上“未被警告的情况下”及“维基百科已有相应的程序处理这些问题”两句。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

(＆)建议：保留“维基百科已有相应的程序处理这些问题”，这很好地解释了为什么不应动用法律手段。--Temp3600（留言） 2022年12月3日 (六) 18:23 (UTC)

(＋)支持：扼要地介绍了什么不是法律威胁；就如设立方针的理由，首先应循争议解决程序来解决问题，很多时候能避免诉诸法律来解决问题。 -- 月都 ※ 2022年12月3日 (六) 23:52 (UTC)

（导言第一行）法律威胁的定义

加上“诉讼、举报、告发”作为举例。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（导言第一行）报告地点

未翻译“elsewhere to an administrator”，原本想说统一报告到管理员布告板。但考量到提报人可能被变为诉讼对象，是不是应该提供私下报告方式比较好？可补翻译加入“管理员列表”及“管理员专用邮件清单 wikipedia-zh-admin”。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

并列吗？听起来应该可以。--冥王欧西里斯（留言） 2022年12月1日 (四) 06:50 (UTC)

(＋)支持：提供相关通报管道更为完备。--Kriz Ju（留言） 2022年12月5日 (一) 19:54 (UTC)

（导言第三行）两位用户之间无论是在维基百科或其他地方有法律纠纷，只要没有在维基百科上发布法律威胁，就不构成封禁的理由。由于存在利益冲突，陷入法律纠纷的编辑者不应编辑与纠纷有关的条目。

(＆)建议：删除上述条文。2021年维基媒体基金会行动，显示了只要搜集充足的证据，站外的法律威胁会遭到全域封禁；不一定存在利益冲突，愤怒的时候也可以诉诸法律威胁。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

(！)意见：建议异动为“用户之间若因维基百科站内相关活动产生法律纠纷，并获通报至站内，便可能构成管理员裁量是否以封禁账号等方式处理之理由。由于存在利益冲突，陷入法律纠纷的编辑者不应编辑与纠纷有关的条目，相关用户亦应停止无建设性之不良互动。”由于各式法律争议不一而足、样态复杂，且身为志工之管理员通常实无必要或义务主动涉入其中，抑或心力或能力不足，加上此类争端可能是非难论，此处建议赋予管理员较大之裁量空间。--Kriz Ju（留言） 2022年12月5日 (一) 19:54 (UTC)

已接受Kriz Ju的建议。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)

（导言第三行）“The only concern of this policy is the posting of legal threats on Wikipedia”未翻译。

暂未翻译。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

此方针仅关注在维基百科上张贴的威胁？可能还需要润一下文字。--冥王欧西里斯（留言） 2022年12月1日 (四) 06:51 (UTC)

(！)意见：个人倾向不需翻译。--Kriz Ju（留言） 2022年12月5日 (一) 20:03 (UTC)

这得看上面那条的讨论结果，如果站外也纳入的话，此条就不需要加入，但若维持仅关心站内的法律威胁的话，此条还是写上为佳。--冥王欧西里斯（留言） 2022年12月6日 (二) 01:26 (UTC)

（什么不是法律威胁 - 著作权）欢迎您告诉我们该使用方式是否符合授权

不太确定“a clear statement about whether it is licensed for such use is welcome”的意思，暂时用我自己的话重写。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

完整的述明是If you are the owner of copyrighted material that has been inappropriately added to Wikipedia, a clear statement about whether it is licensed for such use is welcome. 本地化句段似乎也未有准确转译有关内容，这整段话是以声称持有著作权者为辅助对象，通篇相信可表述为“假若您是某一被不适切地上载到维基站域内物件的著作权持有人，欢迎清晰声明是否许可上述用途”——这一点也是极大限制著作权提起路线之适用对象，即无论社区或社群并不适用为声称及行动对象。

另外以整体内容与WP:CIVIL、WP:HAR等相互衔接而言，加上延伸结合相关著作权判定专题及本地其他经验，明显不同于衡常司法环境之中文圈司法认知环境有诸多空间可能仍需本地化进程内严加关注及应对，认为该案适合进一步扩展研判中文圈语境或议题界线灰色化之下可能产生之独特的法律威胁。--约克客（留言） 2023年1月17日 (二) 02:01 (UTC)

（什么不是法律威胁 - 著作权）报告程序

Wikipedia:页面存废讨论/疑似侵权放在首位，这是稳定执行的现有处理程序。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（什么不是法律威胁 - 有偿编辑）“laws against undisclosed advertising”未翻译

不太清楚那是什么，暂未翻译。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

WP:NOHIDDENADS吧，所以是指提醒对方关于不得张贴秘密广告的这件事并不构成法律威胁。--冥王欧西里斯（留言） 2022年12月6日 (二) 07:52 (UTC)

（什么不是法律威胁）拟增订Wikipedia:生者传记

有些请求可能涉及隐私或任何生者传记规定事项，这些请求可能同时涉及法律威胁，但如果符合Wikipedia:生者传记规定应移除内容，应优先接受请求，而非指控其法律威胁，以免事态升级。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

已加上Wikipedia:不要诉诸法律威胁#生者传记。--Xiplus#Talk 2023年1月16日 (一) 14:24 (UTC)

（察觉法律威胁）标题

原文为“Perceived 感知、察觉”，暂用察觉一词。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

Perceived threat与real threat相对，指一方无控告的目的，而其措辞使另一方感觉受到了法律威胁。-Mys_721tx（留言） 2022年12月5日 (一) 20:06 (UTC)

重命名为“理解法律威胁”，该章节是用来说明如何判断一段留言是否属于法律威胁。--Xiplus#Talk 2023年1月16日 (一) 14:11 (UTC)

（察觉法律威胁）法律威胁的示例

考量到本案当事人和其他新人不熟悉该方针，参考了Wikipedia:条目所有权#所有权的行为示例和Wikipedia:不要人身攻击#例子都有相关的举例，给出示例能让所有人更容易理解界线在哪里，故目前给出很多示例。但我有在考虑方针是否真的适合收录示例列表，独立成一页作为{{辅助说明}}可能更为合适。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

搬到辅助说明页吧，这样也比较好增修。--冥王欧西里斯（留言） 2022年12月1日 (四) 06:54 (UTC)

建议独立成WP:NLT的子页面。--冥王欧西里斯（留言） 2022年12月6日 (二) 07:53 (UTC)

(＆)建议：删除整个章节的条文；任何人都可以不理会法律威胁，并且报告至Wikipedia:管理员布告板/其他不当行为。不必跟随英语维基百科的版本，片面字句或指控性词汇常被过于演绎，存在出于善意的可能性，因此尝试给他人解释的机会。 -- 月都 ※ 2022年12月5日 (一) 07:35 (UTC)

(！)意见：支持创建辅助说明页和月都君条文，另建议条文微调为“任何用户对于法律威胁皆可报告至Wikipedia:管理员布告板/其他不当行为等适当的协助管道。”--Kriz Ju（留言） 2022年12月5日 (一) 20:18 (UTC)

示例已拆分到Wikipedia:如何处理法律威胁，该页面亦可让管理员补充处理的技巧；该章节重命名为“理解法律威胁”，该章节是用来说明如何判断一段留言是否属于法律威胁，而非察觉及如何处理，该段文字已列在首段，故未被接受。--Xiplus#Talk 2023年1月16日 (一) 14:10 (UTC)

（察觉法律威胁）英文方针原本的举例“if you repeatedly assert that another editor's comments are "defamatory" or "libelous"”未翻译

续前，建议留下一个示例即可，但这两个词汇似乎都是诽谤，不知道怎么翻译，或许可以直接另外写一个合适的示例。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

美国法律上libel和slander是defamation的子集，libel是书面出版的，slander是口头的。-Mys_721tx（留言） 2022年12月5日 (一) 20:16 (UTC)

(！)意见：个人认为条文可译为“如果您持续断言其他编辑的评论是各种诽谤或中伤。”--Kriz Ju（留言） 2022年12月19日 (一) 20:27 (UTC)

（设立方针的理由）这会造成寒蝉效应

原本寒蝉效应是链接，但我觉得直接写出来该词汇有助于理解。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（设立方针的理由）冲突中的一方就有可能威胁并排斥另一方

原文“we risk one side of a dispute intimidating the other”，不确定翻译是否正确。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

• 大约是指有能力作出法律威胁的一方可以胁迫另一方闭嘴，从而破坏条目的自由编辑制度，导致systemic bias云云。--Temp3600（留言） 2022年12月5日 (一) 14:06 (UTC)

(！)意见：个人认为条文可译为“社群恐将产生任由争端出现恫吓胁迫等行为的风险”--Kriz Ju（留言） 2022年12月19日 (一) 20:40 (UTC)

已接受Kriz Ju的建议。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)

（设立方针的理由）社群与曾做出法律威胁的用户会留下糟糕的经历

原文“The project has had bad experiences with users who have posted legal threats in the past”，不太确定是指在（英文维基百科）以前曾发生糟糕的经历，还是指一旦进行了法律威胁，日后社群在与该位编者协作时会想起这段糟糕的经历。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

(＆)建议：删除上述条文，保障维基媒体基础设施或用户的安全。较为清楚地说明为什么不要诉诸法律威胁。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

(▲)对于保留上述条文改为中立的态度，虽然bad一词比较含糊。 -- 月都 ※ 2022年12月5日 (一) 07:35 (UTC)

（设立方针的理由）只有在您已经尝试了所有您知道的合理步骤来友善地解决问题，但争议解决程序仍不能解决您的问题时，您才可以选择采取法律行动。

原文“If the dispute resolution procedures do not resolve your problem, and you then choose to take legal action, you do so in the knowledge that you took all reasonable steps to resolve the situation amicably.”，不确定翻译是否正确。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

(！)意见：个人认为条文可译为“请您在选择采取法律行动之前，确认已经尝试所有可能的合理步骤友善解决问题，而相关的争端调解程序却仍未解决您的问题。”--Kriz Ju（留言） 2022年12月19日 (一) 20:54 (UTC)

已接受Kriz Ju的建议。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)

（法律威胁的结论）防止在寻求他人协助后，又将对方变为法律上的对造。

原文“prevents a situation in which someone seeks to be a collaborative partner, while posting as if they were a legal adversary.”，实际上看了很久都无法理解这句话的意思，更旧的原文是“It prevents the difficult situation where a person is both seeking to be collaborative partner and also setting themselves up as litigatious adversary (in general those two roles are mutually exclusive).”，相关的讨论请参见这里。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

这段话应该是阐述一种双重标准定位的参与语境，旧文可能更好体现到旨在防范之风险问题，difficult、setting up和exclusive等是有更一步述明一定隐含之诉诸特征，考虑结合精炼含义及原意，个人认为结论之阐述为“旨在避免出现以下某类参与者存在之复杂情况，即在社区过程内同时表现出两种截然矛盾身份且不能调和之参与者，其一方面看似寻求与其他参与者通盘合作之，但另一方面看似寻求合作同时在诉诸对方为官司追查对象之代理顾问”。--约克客（留言） 2022年12月1日 (四) 09:14 (UTC)

简单而言原提炼句基础上也可能可以再简练点，前设是阅览时意识到其表述一种可能处于司法语境里更显矛盾之两种身份——collaborative partner和litigatious adversary，好比合作证人和检控方，即同一语境里一方同时具有两种角色表征时即已存疑。--约克客（留言） 2022年12月1日 (四) 09:38 (UTC)

认同。维基人本应团结互助，善意假定，故是被此的 collaborative partner，但如果可能彼此是法律上的对造方，则合作时决不能真心诚意，此一身份矛盾即是维基人间不应以法律手段解决问题的原因。--Temp3600（留言） 2022年12月5日 (一) 10:20 (UTC)

（法律威胁的结论）在用户讨论页上反复进行法律威胁所能造成的扰乱及寒蝉效应范围有限，除非已经合理尝试发起文明的讨论，否则不应禁止编辑他们的讨论页。

但在本案中的当事人实际上很快地（而不是多次提出申诉）被禁止讨论页及电子邮箱，我个人不太认为本案（在被封讨论页当下）有达到非常严重的情况，如果本地社群决定更严厉执行该方针，或是给予管理员更灵活判断的权力，应删除本条。但其实本条是保障当事人申诉权利，及避免事态升级。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

(＆)建议：删除上述条文，于当前社群实践不符。--Fox6667（留言） 2022年12月4日 (日) 08:38 (UTC)

(＆)建议：删除上述条文，在用户讨论页上反复进行法律威胁所能造成的扰乱及寒蝉效应范围有限；如社群已经不可能阻止法律威胁的问题，或提供充分解释后执意做出诉诸法律威胁的行为，则应禁止用户编辑自己的讨论页面。有些时候找到代替的方法，意识到法律威胁的缺点，就不会重蹈覆辙，未来是一位建设维基百科的参与者；现实世界里没有采取或已完成法律行动或政府程序，参与者放弃追究相关责任，应该获得解除封禁的机会。 -- 月都 ※ 2022年12月5日 (一) 07:35 (UTC)

(！)意见：建议微调上述条文为“由于在用户讨论页上反复进行法律威胁所能造成的扰乱及寒蝉效应范围有限，社群应考虑发起适当讨论，否则不应未经警醒便禁止编辑他们的讨论页。在社群对相关用户进行善意沟通后，管理人员可依事态发展适当裁处。”--Kriz Ju（留言） 2022年12月5日 (一) 20:51 (UTC)

已接受Kriz Ju的建议并微调。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)

续前，电子邮箱是否构成法律威胁

翻译前的原先文字有“如果您决定要诉诸法律行动，请与相关用户以电邮联络，不要把问题放在维基论坛或讨论页。”，而且该方针的规范范围似乎仅及于公开的地方（可从用户讨论页就视为不够公开而给予特别宽容看出），故电子邮箱应该不包含在内，但本案中当事人实际上已被禁止电子邮箱，另法律威胁已被定义为Wikipedia:骚扰#恐吓和Wikipedia:不要人身攻击#例子的一种类型，而这两项规范范围理应包含电子邮箱，因此有矛盾之处。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

(＆)建议：应当认为是法律威胁，因有其他方针如此规定。--Fox6667（留言） 2022年12月3日 (六) 18:10 (UTC)

(！)意见：构成的要件是让人害怕受到法律行动或政府程序的影响；如使用Wikipedia的电邮联络此用户功能进行法律威胁，或许需要实施封禁。 -- 月都 ※ 2022年12月3日 (六) 23:52 (UTC)

私下威胁不见得比公开威胁好。--Temp3600（留言） 2022年12月5日 (一) 10:22 (UTC)

(！)意见：建议微调上述条文为“如果您决定要诉诸法律行动，建议您适当知会相关用户，避免持续通过维基论坛或讨论页等平台相关页面扩大争端。”其实既已决定诉诸法律，通过何种途径、管道或形式联系，似已非是否构成威胁恫吓之关键；若前面已有“用户之间若因维基百科站内相关活动产生法律纠纷，并获通报至站内，便可能构成管理员裁量是否以封禁账号等方式处理之理由。”之条文，争端仍回归相关当事人之实际沟通状况，以及管理员若获报后之实务判断。换言之，若相关用户选择不通报或已私下协调，则亦无诉诸何种媒介应如何处置的问题。--Kriz Ju（留言） 2022年12月5日 (一) 21:34 (UTC)

(？)疑问所谓私下之法律或他种活动云云，依据过往个案经验等而言，似乎亦无法避免站域内定义Perceived threat或real threat之可能性，归结其所隐含之尺度是一个非常需要关联专业协作之课题，故而可能有必要另行展开专版及适当程序订立处理，不能全由参与维基项目之用户自行承担被诉诸之风险。--约克客（留言） 2022年12月6日 (二) 02:51 (UTC)

您是把legalwikimedia.org当作摆设吗？--路西法人 2022年12月6日 (二) 03:43 (UTC)

(！)意见：这项相关规范主要只能用来约束真正有心参与的社群用户和违规用户而已（或许类似会员制），理想上希望尽可能提供能让用户安心编辑的环境，或至少在发生此类状况时能有基本应对措施；然而对于站外各种形式的施压，或是遇到有心人特地来“算账”或争执的情况，也仅能加以应对或取得对方理解而已，要是对方根本不参与站内活动，站内也无能为力吧（若涉及法律协助则已超出此规范原意）。因此只能提供各种管道让用户适当求助，只有先具备让人安心、安全发声反映的管道和规范基础才有协助的空间。--Kriz Ju（留言） 2022年12月15日 (四) 17:06 (UTC)

（法律威胁的结论）假定善意不是自杀协议

我其实不懂suicide pact的意思。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

按照en:Wikipedia:Our social policies are not a suicide pact，是WP:IAR。在用户页面散发法律威胁因为影响范围较小不会被立即禁止编辑讨论页面，但是持续此类行为会禁止编辑讨论页。-Mys_721tx（留言） 2022年11月30日 (三) 16:10 (UTC)

(＆)建议：在阻止破坏的同时也应该假定善意，但假定善意不是自杀协议，持续或无理取闹的申诉将导致用户被禁止编辑他们的讨论页。条文与法律威胁无关。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

不是很看得明白“自杀协议”以及上边两位的解释。--Ghren🐦🕓 2022年12月3日 (六) 09:52 (UTC)

浅红色标示的是提议删除条文，理由是仅限于假定善意和解除封禁的范畴，未能解释与法律威胁的关系；而且法律威胁的结论章节第一段，提到以原谅的态度对待放弃诉诸法律威胁者。 -- 月都 ※ 2022年12月3日 (六) 11:45 (UTC)

en:The Constitution is not a suicide pact:The phrase expresses the belief that constitutional restrictions on governmental power must be balanced against the need for survival of the state and its people. 大约是指规则设计出来并不是为了要弄死所有人的意思？“及陷于罪，然后从而刑之，是罔民也。”--Temp3600（留言） 2022年12月5日 (一) 13:59 (UTC)

(！)意见：支持删去“在阻止破坏的同时也应该假定善意，但假定善意不是自杀协议”，但保留“，持续或无理取闹的申诉将导致用户编辑他们的讨论页。”；合并前面条文则为：“由于在用户讨论页上反复进行法律威胁所能造成的扰乱及寒蝉效应范围有限，社群应考虑发起适当讨论，否则不应未经警醒便禁止编辑他们的讨论页。在社群对相关用户进行善意沟通后，管理人员可依事态发展适当裁处，持续或无理取闹的不当申诉将导致用户被禁止编辑他们的讨论页。”。个人意见，供参。--Kriz Ju（留言） 2022年12月5日 (一) 21:53 (UTC)

已接受Kriz Ju的建议。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)

公示不要诉诸法律威胁

基于上面已经过充分的讨论，现公示Wikipedia:不要诉诸法律威胁的目前版本，针对部分异议，统一回应如下：

• 众多举例已移出方针：管理员应综合考量具体内容及发布次数，不应通过单一句子判断是否构成法律威胁。
• 电子邮箱及是否可以通知要兴讼的问题：由于电子邮箱只有传送的双方可见，且设有拒接电子邮箱的功能，并考量本方针的要旨在于防止法律威胁对社群第三方的影响及以法律威胁代替讨论，一律规定电子邮箱“可以”或“不行”皆不恰当，应个别考量具体案例，故暂未明确写入方针，但在方针首段让管理员自由裁量。
• 初犯警告问题：是否进行警告已在Wikipedia:封禁方针#教育用户所规定，管理员应根据具体情况判断是否可以未经警告封禁，另Wikipedia:不要诉诸法律威胁#法律威胁的结论也规定若当事人已理解规定且愿意撤回发言，就可解除封禁。

公示14日，2023年3月9日 (四) 13:01 (UTC) 结束。--Xiplus#Talk 2023年2月23日 (四) 13:01 (UTC)

更新对法律方针的描述

现行条文 以下方针有法律上的后果。除这些方针外，基金会行动方针、维基百科不会审查内容也有法律上的意义。留意只要内容符合美国法律，维基不会对内容拖加限制。如想向维基百科提出法律投诉，可向维基媒体基金会提出正式投诉

提议条文 Mys 721tx 以下方针有法律后果。除下列方针和基金会行动方针外，只要维基百科上的内容符合美国法律，维基百科不会对自身可能令人反感的内容进行审查，或采纳其他管辖内容的法律提案。法律问题需通过维基媒体基金会正式提出。 月都 以下方针有法律后果。除下列方针和基金会行动方针外，只要维基百科内容符合美国法律，维基百科不会对自身可能令人反感的内容进行审查，或受其他管辖内容的法律提案约束。有关维基百科的法律问题，请参考争议解决指引以及请不要诉诸法律威胁。 Kriz Ju 以下方针有法律后果。除下列方针和基金会行动方针外，只要维基百科上的内容符合美国法律，维基百科不会对自身可能令人反感的内容进行审查，或使其受其他内容约束或审查相关法律囿限。关于维基百科的法律问题，可参考争议解决指引、请不要诉诸法律威胁；如想对维基百科提出法律投诉，请向维基媒体基金会正式提出。

顺手重新翻译了一下法律方针的描述。-Mys_721tx（留言） 2022年11月21日 (一) 05:50 (UTC)

(＋)支持：社群对不得进行法律威胁之条文虽现无明确列入其中，但已在实践过程中受到普遍性的承认。诸如WMC事件、修订傀儡方针涉及法胁内容以及诸管理员在封禁案例上也有体现。现在明文加入其中，显然是适当的。——2022年11月22日 (二) 15:37 (UTC)--以上未签名的留言由维基百科最忠诚的反对者（讨论｜贡献）加入。

(！)意见：虽然法律与判刑存在密切关系，但法官或律师意见可能有助于改进维基百科，且不一定被社群采纳。通常接受理性讨论；通常不接受法律威胁，即针对个人、团体或组织。 -- 月都 ※ 2022年12月3日 (六) 07:12 (UTC)

(▲)鼓励采用站内的争议解决程序；不鼓励以法律作为武器，强迫别人支持非方针或使用条款的法律观点。 -- 月都 ※ 2022年12月5日 (一) 08:06 (UTC)

(＋)支持相关修订，个人微微汇整上方两位站友版本。--Kriz Ju（留言） 2022年12月5日 (一) 22:21 (UTC)

(＋)支持Kriz Ju的版本。--冥王欧西里斯（留言） 2022年12月6日 (二) 07:58 (UTC)

@Mys 721tx：应该可以使用Kriz Ju的版本修改了？--冥王欧西里斯（留言） 2023年3月2日 (四) 06:49 (UTC)

完成--Mys_721tx（留言） 2023年3月2日 (四) 07:07 (UTC)

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

关注度指引改名事宜

为整合有关主题的讨论，本讨论已移动至Wikipedia:集中讨论/关注度指引改名事宜 § 第一阶段讨论区进行集中讨论。请至有关页面发表意见。

执行人：路西法人 2023年1月20日 (五) 08:10 (UTC)

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

图注的结尾的句号

现行MOS:句号指出，“图片和图表的描述……末尾不用句号。就算有时说明文字内容比较长，在前面的语段中已用句号，最后的结尾处仍不用句号。”

格式手册的例子“维基娘是维基百科萌拟人化后的美少女角色。由日本维基百科人创作”我认为不太好，“美少女角色”后应该用逗号。试另举一组例子：

• 
  维基百科标志
• 
  维基娘是维基百科萌拟人化后的美少女角色
• 
  维基娘是维基百科萌拟人化后的美少女角色。其虽非官方吉祥物，但已被官方和社群用于各类活动中。

第一张图的图注一般按短语理解，结尾不用句号为宜。第二张图的图注可以构成句子，但是当短语处理亦可；结尾句号可加可不加。第三张图的图注显然是两个句子，尾句不加句号我是感觉到别扭。

“视作短语的图注结尾不加句号，视作句子/语段的图注结尾加句号”可能更合适。但这样的结果是，一眼看上去图注结尾句号时有时无，表面上不够统一。各位怎样看？--洛普利宁 2023年1月22日 (日) 05:16 (UTC)

认同Lopullinen阁下的说法，短语不用句号，句子应用句号。(※)注意句2先前版本是“存在于图表中的短语式说明文字，其中部内容可用逗号，但末尾不用句号。就算是有些时候说明文字内容比较长，在前面的语段中已出现句号，最后的结尾处仍不用句号。”（粗体为后加）在下理解后句“说明文字内容⋯⋯最后的结尾处仍不用句号”仍仅适用于前句提到的短语式说明文字，不包括句子。Special:Diff/74616458中捍粤者阁下将“存在于图表中的短语式说明文字”修改成“图片和图表的描述”使该段落变成适用于句子，但似乎没有相关共识，应恢复成先前版本。另外Wikipedia_talk:格式手册/标点符号/存档3#新建一个去除图片介绍末尾标点符号的机器人曾讨论是否应加句号。——$\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}$（留言） 2023年1月22日 (日) 12:49 (UTC)

收到！--－－勿用“进行”污染中文，要言简意赅。　捍粤者 2023年1月22日 (日) 16:43 (UTC)

(＋)赞成“文字中已有句号或分号的语段应有恰当的标点收尾”。--Gohan 2023年1月23日 (一) 00:38 (UTC)

(＋)赞成。另外这方面的内容似乎移至MOS:CAP叙述更合适。--PexEric 💬|📝 2023年1月24日 (二) 06:37 (UTC)

(＝)中立：结尾是否要放上句点那是习惯问题，毕竟条目是应该写给读者看而不是自己看的。既然条目内容都是这样了，那图片当然也是这样，不应一竿子改变这种习惯。就好比如：<ref></ref>标签，请问您要放在句点前还是句点后？其实都行，因为是习惯问题。--Z7504非常建议必要时多关注评选（留言） 2023年1月30日 (一) 19:29 (UTC)

(＝)中立，习惯问题。个人偏好不加句号，主要我觉得图片下面的字无论是短语还是句子，放在文字旁都是补充内容，就好比是文本中括号内的内容。--Evesiesta_{🇩🇪❤️🇺🇦} 2023年2月5日 (日) 09:39 (UTC)

@Evesiesta：一个句子不加句号没有问题，毕竟去掉句号就是短语。关键是复数句子只有最后一句不加句号。就算是文本中的括号内容，里面如果有多个句子，最后一个句子不以标点收束还是很奇怪。--洛普利宁 2023年2月6日 (一) 14:41 (UTC)

(？)疑问：为什么要在图片的说明文字区域里面写落落长的文章，导致需要讨论文章结尾要不要用句号？--Anghualee（留言） 2023年2月8日 (三) 17:02 (UTC)

@Anghualee：不一定构成文章，但有时一句话不够用。以此条目正文图片为例。第一句话描述图片本身内容，第二句话呼应正文“长枪克剑，剑克斧，斧克长枪”（WP:NFCC#8，著作权图片应有助正文理解）。这用一句话可能不好表述。--洛普利宁 2023年2月9日 (四) 14:09 (UTC)

也就是说因为除了"游戏的战斗画面"这几个字以外的正文需要图片来达成你所谓的WP:NFCC#8，结果把正文放到图片说明文字区域里面。所以我问啊，你到底是为了有助正文理解加图片（正文摆在正文，图片摆在图片，图片底下说明文字写"游戏的战斗画面"），还是加了图片后为了理解写了落落长的文章解释图片（正文删掉，图片摆上去以后，把落落长的正文塞进去）。很明显前面是你所谓的WP:NFCC#8，后面不是。--Anghualee（留言） 2023年2月9日 (四) 23:51 (UTC)

再来我们讲图片理解这件事情，请问一下那张图哪边看出枪克制剑？你当然会说名字左边是武器，在有武器克制的情况下，武器右下角有箭头，箭头代表了武器的克制。Ok，拜托不要把上面那段加到已经落落长的说明文字里面了。我问啊，为什么不在图片上面的武器画一个圈，加一条线拉出去到旁边，写"武器图示：剑"，在箭头上面画一个圈，加一条线拉出去到旁边，写"武器克制示意"，这样图片里面指示清楚了，这个是剑，这个是箭头。然后图片说明文字就打武器克制示意图（枪克剑），不就好了？我为什么需要知道右边是罗伊啊？图片右上角没有吗？--Anghualee（留言） 2023年2月10日 (五) 00:12 (UTC)

首先这是张游戏截图是著作权图片。自行在上面加圆圈箭头修改是不合适的，换用盗版汉化版截图也是不合适的。而且这里是中文维基百科，应当假定读者只会中文。所以读者当然不知道“ロイ”是罗伊。

其次NFCC限制著作权图片数量，而游戏条目一般只能放一张截图。配图的机会珍贵，所以应该选一张具有代表性的图片。如果只是为了展示战斗画面，那完全可以传上传一张枪对枪不互克的截图。既然选了一张存在武器互克的截图来展示，当然应该用文字描述细节，让读者看懂你想表达的内容。（要不您不看图片描述和相关条目，猜一下这张图片想说什么？）

最后你问图片第二句话为什么不放到正文。因为这句话就是描述这张图片的，而不是正文的一部分（对正文太过琐碎）。如果条目不放图片，或者换成对话界面的截图，这句话自然不会出现。--洛普利宁 2023年2月10日 (五) 04:56 (UTC)

著作权我本来是不想讨论的，因为那个是另外一个问题。毕竟图片来源是 http://www.hardcoregaming101.net/，你确定该网站有"拥有使用CC-BY-SA协定释放该内容的授权／是该内容的原始作者"其中一种吗？再来你提到 NFCC，NFCC十点是必须全部符合的，第十点的 abc 都齐备了吗？

其次如果觉得图像著作权是你很关注的问题，可以完全采用 Mock 的方式从白纸开始，框出各个区域以文字描述这是状态栏，除非你能主张连游戏画面中的区块分布都具备著作权，否则 NFCC 第一点应该有跟你说如果可以用自由材料加以替代。

我前面就说过了，除了"游戏的战斗画面"这几个字以外，不是该丢到正文，就是琐碎信息。所以你拿这是中文维基百科云云，我是真的觉得，那你怎么不把 DMG、Rapier 都解释了咧。如果这些可以不用因为这里是中文维基百科而提供相应的中文说明，那罗伊就不用。就我的认知而言，图片的说明文字放"游戏的战斗画面"就好了。

至于你列出来的"这张图片"，以我来讲这像是一个勇者斗恶龙类型的战斗画面，就我认知上来说跟非游戏玩家的一般人展示时（如果有人还记得我们应该要这样做的话），图片的说明文字放"战斗画面"就好，我不会去介绍说这是什么怪物、为什么队伍是三个人、PP是什么、接下来战斗可能会有画面抖动（或许吧）。

我也不喜欢拿英文维基百科举例，毕竟这边是中文维基百科。不过你要不要想看看为啥英语维基百科就是一句"A battle between two units in The Binding Blade."就解决了？--Anghualee（留言） 2023年2月14日 (二) 02:54 (UTC)

图片来源是http://www.hardcoregaming101.net/没有问题。游戏截图可以上传者自己截，也可以别人（比如hardcoregaming101.net）截好我直接上传。很显然这张图片不是以“CC-BY-SA”协议授权的（否则会传到c站而不是这里）。然后看NFCC#10：a) 图像说明页已经表明著作权属于Intelligent Systems和Nintendo；b) 著作权标签是{{Non-free game screenshot}}，文档说明页已经放置；c) 哪篇条目使用这张图片需要指明，这点文档也清楚地链接了火焰之纹章 封印之剑条目。

我想说明由于著作权问题，游戏截图只能使用一张，而不能像Wikia通过大量图片来总结归纳。所以我需要通过文字发挥图片最大的效用。正文没说DMG所以我图片没解释DMG，正文没说Rapier所以我只说成剑而非刺剑，正文有说罗伊所以我图片有说罗伊，正文有说伯尔尼所以我有说伯尔尼兵，正文强调武器互克所以我专门才用一句话来辅助说明。另外正文不是我写的，图片也不是我传的。我只是根据正文的介绍，帮助图片发挥更大的作用。我认为图片的一个核心价值是表现了枪克剑；而在陈述清楚这点的基础上，文字当然短一些比较好。如果读者都懂日文，那图注确实可以压缩成一句话；但这里是中文维基百科，読者は日本語がわかりません，我只能用多一些的文字说明左边的角色拿枪、右边的角色持剑。当然，确实我语文能力有限，没有想到更短的介绍文字。

关于英维的图片用途您猜的对，就是为了说明勇者斗恶龙类型的战斗画面。这个讨论我注意到了一点，您懂的东西太多了。比如“ロイ”您假设读者是会读的，所以认为标注罗伊多余。这张图片您也能猜到上传者的意思，您可能认为英维图注第二句话也多余。但是对于没玩过勇者斗恶龙的读者，他们不会立刻往这方面想。能用文字说明白的东西，就不要让读者去猜谜。而且就像您说的，说不定人家还猜你就想强调“DQ是4人队伍、Mother是3人队伍”。

英文维基百科只写“A battle between two units in The Binding Blade”的做法我认为不够好，没有完全发挥图片的价值。而且中文版图片原来也只有这样的描述，第二句是我加的。而且图片还应该有替代文字，英文版懒得写，中文版也懒得写。当然，这是通病。

最后回到正题。如en:Mother_(video_game)#Gameplay所见，有复数句话的图注释确实是存在的。--洛普利宁 2023年2月14日 (二) 14:25 (UTC)

@Anghualee：另外和您相反，我倾向再用一句话表明我传图片的目的，并尽可能和正文呼应起来。比如最近的火焰之纹章 Engage我就没传任何截图，因为我想传一个同时表现纹章士和Break的战斗截图，但没找到合适的图片；而信息框的图注可以和正文“游戏视觉形象图以琉尔为中心绘制”相呼应。其他游戏条目参选优良时，我也提过图注太简单的意见。如果您有想法，欢迎到PJT:VG讨论；毕竟现在关注图注编写的人还是很少的。当然，图注写法对本讨论来说就是离题了。--洛普利宁 2023年2月14日 (二) 14:49 (UTC)

关于"英维图注第二句话也多余"这件事情我简单讲一下，他是两张图片用一个图片描述的方式描述，固定句型就是"左图为XXX，右图为XXX。图片描述"（当然也可以右图为XXX，左图为XXX。左右先后看撰者习惯，至少我没特别学过有对左右先后的相关规范）。就这样。--Anghualee（留言） 2023年3月1日 (三) 13:11 (UTC)

这里有一篇文章对这个问题做了解释，供各位参考。--InstantNull（留言） 2023年2月9日 (四) 18:51 (UTC)

@Lopullinen：似乎有初步共识，可以考虑继续推进。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年2月24日 (五) 01:52 (UTC)

提议限制在维基百科使用ChatGPT及类似工具

最近几个月爆火的ChatGPT可以按照人类的提示生成文本，并且能根据人类的意见进行修改。但其生成的文本常常似是而非，看上去没有问题而实际上却含有事实错误，因此如果在条目中大量使用，可能会具有非常恶劣的影响。

StackOverflow已经禁止使用ChatGPT生成的内容，因此，中文维基百科社群是否应该跟进？

可行的方案：

1. 完全禁止使用ChatGPT生成的内容编写条目；
2. ChatGPT生成的内容须经过人工审阅确认无问题之后才允许出现在条目中。

相关链接：

• Temporary policy: ChatGPT is banned - Meta Stack Overflow
• Should ChatGPT be used to write Wikipedia articles? - Slate

以上。--Diskdance 2023年1月28日 (六) 01:42 (UTC)

原则上支持，但不论是禁制还是审阅如何自动分辨为需要审核或禁止？人工难以审核每一个新页面和版本差异确认没有AI编写内容。--路西法人 2023年1月28日 (六) 01:47 (UTC)

以Stack Overflow为例，他们唯一能实际做的是在有用户被发现疑似使用ChatGPT的时候才予以禁制，无法杜绝有关内容的发布。您的两个建议方案都涉及审核所有ChatGPT写的内容，除了一般的举报外如何做到？还是只能跟现在的侵权提报一样有人发现才报？--路西法人 2023年1月28日 (六) 01:50 (UTC)

不认为您的方案可行。ChatGPT等工具并不像Google Translate那样输入和输出总是相同，很容易受到用户的影响，不是能够直接禁止的。社群似乎也不具备人工审核每一笔编辑的能力。若要求使用此类工具的用户主动声明倒是可以，但也定然不是所有用户都会主动声明。同时，用户也可能是生成后自行润色，将其质量提升到可接受的标准后再发布。—— 月_樱_雪 (留言) 2023年1月28日 (六) 01:54 (UTC)

1不实际可行，缺乏有效检测手段。2在当前意义不大，条目本应被巡查，没有必要“歧视”。如有滥建、批量创建发生，按寻常规则处理即可，判断是否出自AI及质量如何没有依据。对要求申报表示支持，参考机器人、有偿编辑等方针，但落实存难度会变成君子协定。--YFdyh000（留言） 2023年1月28日 (六) 03:09 (UTC)

这是恶意推定，我不知道使用ChatGPT造成何种破坏或者违法哪一方面的规则。--Cat on the Mars 2023年1月28日 (六) 03:56 (UTC)

这个时候就得搬出User:0xDeadbeef在英维举出的例子了。以下是使用ChatGPT生成的关于Rust for Linux的条目片段（方便不懂相关领域的编者，部分术语我自己添加了内链）：

Rust for Linux是向Linux内核项目提交的一系列补丁的总称，这一系列补丁让Rust语言可以用于编写内核组件。该项目始于2017年，由一群对将Rust用作系统底层开发感兴趣的志愿者发起。

Rust for Linux is a series of patches to the Linux kernel that adds the Rust programming language as a second language for writing kernel components. The project was started in 2017 by a group of volunteers who were interested in exploring the use of Rust for low-level systems programming.

早先的补丁是与Linux内核维护者以及开源群体一同合作开发而成的。这些补丁聚焦于将Rust的内存安全以及并行特性带入内核当中，同时提供对已有的C语言代码基础的相容性。

The initial patches were developed in collaboration with the Linux kernel maintainers and other members of the open-source community. They focused on integrating Rust's memory safety and concurrent programming features into the kernel, and on providing compatibility with the existing C codebase.

在2018年，这些补丁被合并至Linux内核代码库当中，令Rust成为第一门除C语言之外，获官方支持可以用作编写内核组件的语言。对于Rust语言社群来说是里程碑式的成就，展示了Rust语言可以胜任内核级别编程的需求。

In 2018, the patches were merged into the mainline Linux kernel, making Rust the first programming language other than C to be officially supported for writing kernel components. This marked a significant milestone for the Rust community, as it demonstrated the language's ability to handle the demanding requirements of kernel-level programming.

自Rust语言加入至Linux内核之中起，Rust for Linux项目持续发展，当前聚焦于改善Rust在内核中运作的兼容性以及效率。该项目还吸引了其他操作系统开发者的注意力，令他们对将Rust语言用作内核级别编程所带来的潜在优点感兴趣。

Since its inclusion in the Linux kernel, the Rust for Linux project has continued to evolve, with ongoing work on improving the compatibility and performance of Rust in the kernel. It has also attracted the attention of other operating system developers, who are interested in exploring the potential benefits of using Rust for kernel-level programming.

我就问一句，这么有模有样的段落你能发现这里面捏造了好几个关键事实吗？你们还觉得这不会造成破坏吗？ --MilkyDefer 2023年1月28日 (六) 09:12 (UTC)

注：我自己能注意到的捏造事实如下

• Rust for Linux项目起始于2020年，不是片段中宣称的2017年；
• Rust for Linux项目代码合并至Linux内核是在2022年，不是片段中宣称的2018年；
• 当前Rust for Linux还没有达到有闲心改善兼容性和效率的地步，当前只有最基础能让编译顺利通过的部分。

有这么方便的工具那些喜欢搞鬼祟破坏的LTA们简直笑开花了啊。 --MilkyDefer 2023年1月28日 (六) 09:16 (UTC)

另外不要忘记维基百科是自然语言处理领域重要的数据集来源，我们有义务不要搞出垃圾进入维基百科又被提取成训练垃圾生成器的原材料的事情。--MilkyDefer 2023年1月28日 (六) 09:21 (UTC)

我认为鉴于ChatGPT的现状，应该将它按对待人类新手的方式处理，事实上就内容而言我们也无法区分新手和机器人之间的区别，何况你站已经封禁了绝大多数代理网段，仅仅凭借实验内容无法证实其破坏性或者真的有人会用来破坏，加上理论上ChatGPT还在使用旧的数据集，分辨拙劣过时内容远远比分辨是否是高级AI作品更加具备可行性也更加重要，暂时没有必要就这件事因“人”立法，如果需要修改方针必须证明现有方针在哪一方面无法满足你的需求（包括劣质训练集，还不如去改进你站存废积压）。--Cat on the Mars 2023年1月28日 (六) 09:38 (UTC)

再新手也不会写出金玉其外败絮其中的内容，真正的新手是写出来读出来就像是新手。你说的这不是新手，是破坏者。--MilkyDefer 2023年1月28日 (六) 09:44 (UTC)

你维的毛某人浪迹天涯多少年了，这种抓不出来其他更是抓不到，你维有长过记性了吗，我说过不要因人立法，不是因为一会儿折毛，一会儿ChatGPT，封个把人就能解决的事情，ChatGPT就我的实际体验还不具备单独作案的能力，我刚刚想要让他搞点引用都得费神很久，像这么一大段无来源内容理所应当就是劣质内容，巡查员应该有自己的判断。----Cat on the Mars 2023年1月28日 (六) 10:01 (UTC)

本人基本同意CatOnMars的观点。--0xDeadbeef（留言） 2023年1月28日 (六) 10:17 (UTC)

至少举例中如果缺少来源（或者来源能通过编辑者审阅并确认过的话），还是能区分出行文问题。需要注意但不至于需要规例。——Sakamotosan路过围观 | 避免做作，免敬 2023年1月29日 (日) 00:41 (UTC)

(！)意见 我认为把可供查证做好就能避免大部分问题。--Taeas（留言） 2023年1月28日 (六) 12:10 (UTC)

• (＋)支持。我当然知道实际上禁之不绝，但态度还是要摆出来。--Temp3600（留言） 2023年1月28日 (六) 19:56 (UTC)

  我认为标题中说的“限制”就可以了，不必要禁止也难以禁止（如何分辨，难道搞一个ChatGPT检查器之类的？[2]但准确度又如何？）,非常同意Temp3600的意见，“态度还是要摆出来”--百無一用是書生 (☎) 2023年1月29日 (日) 03:11 (UTC)

  刚才用chatgpt-detector检测了一下上面的例子Rust for Linux，英文都能正确识别是ChatGPT，但翻译成中文就认为是人类了--百無一用是書生 (☎) 2023年1月29日 (日) 03:19 (UTC)

提问：ChatGPT是否会造成目前方针无法处理的破坏？如果有，是否说明目前的方针存在漏洞？--Steven Sun（留言） 2023年1月29日 (日) 03:44 (UTC)

按WP:破坏处理。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年1月29日 (日) 04:34 (UTC)

(＋)支持，MilkyDefer给出的例子已经很明显了，用于破坏实在是太过简单。--BlackShadowG Slava Ukraini! 2023年1月29日 (日) 04:27 (UTC)

支持禁止，列入行为方针即可。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年1月29日 (日) 04:32 (UTC)

我是持怀疑态度。首先是无法检测、无法证明。任何一段文字，就算GPT检测器说是GPT写的，你无法看到那个人把这段文字从GPT复制下来贴上了。第二，ChatGPT用法多种多样，不应该所有用法都不能用。我特别喜欢叫他帮我找错别字，和从其他语言翻译成中文。应该还有很多无破坏性的例子。Last but not least，现有规则已经可以cover ChatGPT造成的破坏。难道现在加一条说ChatGPT做好事也不行？--Gqqnb（留言） 2023年1月29日 (日) 13:01 (UTC)

我倒是有点想开了，维基百科又不是检查你们做大学作业，有些学校会怀疑是不是你自己写的，你只要写出来了，巡查员检查过了，我管你是怎么写的。我不明白有些人的逻辑，只要这种东西能够用来破坏，“很容易用来破坏”，那这种东西就一定要禁止，是不是你家做菜以后都不要拿刀了。且不论枪支弹药的道德属性，枪支弹药尚且可以用在正道，炸药都可以弄出个诺贝尔奖，你维连ChatGPT的影子都没有看到，便十分“有头有尾”有罪推定宣判ChatGPT死刑，似乎认定了默认利用AI的都是坏人一样，每个人在你维用一次ChatGPT就好像从你维的大厦下面偷一块砖，连基本的“假定善意”都丢掉了。借用鲁迅的一句话，“岂但乡下人之于雷峰塔，日日偷挖中华民国的柱石的奴才们，现在正不知有多少”，而这等这种视若无睹的理所应当更是令我更是匪夷所思。----Cat on the Mars 2023年1月29日 (日) 13:26 (UTC)

感觉类似机翻：内容提交人自己知道润色就OK；当然对初次参与维基百科的人，最保守的说法还是“禁止机翻”。--洛普利宁 2023年1月29日 (日) 13:31 (UTC)

翻译指引有一句“请勿使用机器翻译翻译条目”，在后面加一个“或人工智能机器人”之类的，赋予禁止使用相关工具之授权法源就行了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年1月29日 (日) 14:21 (UTC)

但提案不限于翻译，也包含创作。不过，如果创作后能做到可供查证，感觉没太大问题。--YFdyh000（留言） 2023年1月29日 (日) 14:38 (UTC)

“机器人方针适用于所有用以编辑维基百科的计算机程序或脚本，包括全自动、高速运作以及协助编者的工具。”

按我的理解，现行机器人方针完全适用于AI程序，要改也轮不到翻译指引。----Cat on the Mars 2023年1月30日 (一) 09:23 (UTC)

确实，一时间没有想到。不过两边都写亦无大碍，或可相呼应。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年1月31日 (二) 03:06 (UTC)

我们来关注这么一个问题。对于一个编辑经验不足的新编者而言，创建条目时候的提示信息都有哪些呢？关注度、非广告宣传、著作权、参考文献、WP:NOT，以及一个指向“其他”的链接。不论是机翻还是ChatGPT都没有足够可见的提示。巡查员一看，不行，从犄角旮旯里翻出一个方针的一个犄角旮旯的句子出来，新手直接炸毛了。--MilkyDefer 2023年2月3日 (五) 13:37 (UTC)

你应该去改F&Q而不是去改方针，现在的方针指引堪比屎山代码，我觉得与其改机器人方针内容，还不如改名字一目了然，以前叫他机器人，其实只是自动化程序，以后必然还会有AI程序，它这名字早就已经赶不上时代了。----Cat on the Mars 2023年2月3日 (五) 15:45 (UTC)

方针指引太多搞得管理员都不知道自己正在重复立法。----Cat on the Mars 2023年2月3日 (五) 15:51 (UTC)

我的意见本来与Ericliu1912相近的，但考虑到YFdyh000所言在理，我更倾向要求任何人确保他们在用AI写东西后必须先自己校对过才在维基百科发布，毕竟相关工具我自己感觉不是完全不能用，但一定要自己下手调整AI写出来的文本，这跟维基百科内置的机翻工具是一个道理。@YFdyh000、Ericliu1912：如果“似是而非”的文本符合“胡言乱语”的定义的话，这其实就是G1的范畴。Sanmosa _{Συ γάρ μοι και μοίρα εί και τύχη} 2023年1月30日 (一) 05:05 (UTC)

@Ericliu1912、shizhao：我想要请教管理员，如果我要在机器人方针第一句“机器人方针适用于所有用以编辑维基百科的计算机程序或脚本，包括全自动、高速运作以及协助编者的工具”“包括”后面加上一句“利用人工智能（AI）技术编辑维基百科的程序”，这是否超出了“修改方针及指引的文意”的小修改门槛。按照我的理解，机器人AI程序应该是在机器人方针“所有用以编辑维基百科的计算机程序或脚本”的范畴内。另外，从我的角度，防不如管，如果能够知道别人在使用AI总比盲盒瞎猜好很多。--Cat on the Mars 2023年2月4日 (六) 11:25 (UTC)

• (－)反对与其禁止使用AI生成内容，应该规定的是不是使用AI辅助后应先行复检后再发布？AI跟机器翻译一样，可以视为一个辅助手段，但不应该作为主要贡献。所谓的“似是而非”、“事实错误”全部现有方针已可处理。如果AI生成的内容可以被来源证实，我实在看不出一刀切禁止使用的原因-某人✉ 2023年2月6日 (一) 14:29 (UTC)

  所以说，机器翻译不正好是天怨人怨么……--MilkyDefer 2023年2月7日 (二) 11:45 (UTC)

  不喜欢或者讨厌不是禁止的理由。----Cat on Mars 2023年2月7日 (二) 14:26 (UTC)

  也不知怎么就天怒人怨了，一帮人整天在tg群讲相同的话真以为全宇宙都想得一样。--日期20220626（留言） 2023年2月8日 (三) 11:12 (UTC)

• 咕咕--Zyksnowy（留言） 2023年2月8日 (三) 09:14 (UTC)

怎么分辨并证明那些文字由ChatGPT等AI“生成”？何况那东西还在时刻“进化”。--安忆^Talk 2023年2月8日 (三) 09:36 (UTC)

我觉得按照机器人方针自觉申报就行了，我们还没有这个能力判断，也耗不起这个时间，以后GPT3.5推广了还会有更多AI程序，不可能永远靠人力查核。----Cat on Mars 2023年2月8日 (三) 09:59 (UTC)

• (－)反对:Some people against using you in Wikipedia. How can I refute?

Here are some arguments that you could use to defend the use of AI language models like me in Wikipedia:

Increased efficiency and accuracy: AI language models can assist in generating and verifying information in Wikipedia, potentially leading to improved accuracy and efficiency compared to manual editing.

Supplementing human labor: AI language models can help to supplement the work of human editors and writers, freeing up their time and energy to focus on more complex and strategic tasks.

Improving accessibility: AI language models can assist in generating and translating content, making Wikipedia more accessible to a wider audience and supporting the goal of creating a free and comprehensive encyclopedia.

Cost-effectiveness: Using AI language models can help to reduce the cost of creating and maintaining Wikipedia, making it more sustainable in the long-term.

Of course, it's also important to consider potential concerns and criticisms related to the use of AI in Wikipedia, such as the potential for biases in the training data and the importance of maintaining human oversight and control. Nevertheless, with proper safeguards and transparency, AI language models like me can be a valuable tool for supporting and improving Wikipedia.--維基小霸王（留言） 2023年2月9日 (四) 04:12 (UTC)

@MilkyDefer：这是使用ChatGPT生成的关于入间同学入魔了！的片段（使用“谈谈"入间同学入魔了!"这部动画”去生成）：

《入间同学入魔了!》是一部日本的动画，是由小畑健制作的一部歌舞片。这部动画以魔法为题材，讲述了主人公入间在升上高中后，逐渐接触到魔法世界，最终投身于魔法战争的故事。 这部动画以精彩的故事情节和生动的角色设计而受到许多观众的喜爱。它还以鲜明的风格和丰富多彩的音乐展示了魔法世界的魅力，为观众带来了一个充满奇幻与冒险的世界。 如果你是一个喜爱动画的观众，那么这部动画是值得一看的。它将带给你一个精彩的故事情节和生动的角色，让你进入一个充满魔法与冒险的世界。

，但入间同学入魔了！实际上是由西修所创作的日本漫画作品，且实际上小畑健曾经创作过《棋魂》，不是《入间同学入魔了！》，所以ChatGPT所生成的日本动漫类条目就有问题--林勇智 2023年2月9日 (四) 12:26 (UTC)

尝试限定维基百科的风格，并要求给出至少五个不是维基百科自身的公开可查证来源呢？--MilkyDefer 2023年2月9日 (四) 12:55 (UTC)

它以前给过我一本陈景润的《中国哲学史》。----Cat on Mars 2023年2月9日 (四) 12:58 (UTC)

所以我在看到U:outlookxp的查证的时候就觉得这是不是什么我们不知道、并且还在保密中的高级AI。----Cat on Mars 2023年2月9日 (四) 13:02 (UTC)

ChatGPT有点蠢，机翻都比它靠谱点。--日期20220626（留言） 2023年2月9日 (四) 13:09 (UTC)

用它机翻还是比较好用的。----Cat on Mars 2023年2月9日 (四) 13:24 (UTC)

大概是题外，看到提起维基内建机翻以及用机翻后要校正的内容等等的、那个啊今天凌晨逛最近更改的时候发现了不列颠共产党，有兴趣看哪位用户新增的请查看编辑摘要以及贡献，该用户共新增了三个条目，因为实在是没心力了所以只有挂了模板，看看此人会不会良心现前自己回来改，不改的话之后就删除，个人感想是遇过几次用机翻的用户，原则上大概也不知道自己开了什么箱，只是翻译出来的结果乍看满意好像吐出了象牙，奢望他们自己配备校对能力可能真的以为人本善良。--Mafalda4144（留言） 2023年2月9日 (四) 13:37 (UTC)

我尝试了一下改善翻译，然而并没有什么用处--Cat on Mars 2023年2月9日 (四) 14:17 (UTC)

这玩意据方舟子测试，简中资料来源自称是用百毒的样子。不过其他人有不同的结果。--S叔 2023年2月10日 (五) 02:19 (UTC)

显然ChatGPT自身生成的内容并不能作为证明其无害的依据。--Diskdance 2023年2月9日 (四) 15:04 (UTC)

好像有人测试医学类条目，ChatGPT会自己编造PubMed参考文献。另外不知道其在翻译条目中是否也会编造内容。关于其翻译质量，腾讯的一个实验室最近在arXiv上发了一篇论文。建议先行禁止。--Kethyga（留言） 2023年2月10日 (五) 12:41 (UTC)

(＋)支持明文禁止。——WMLO（留言）。 2023年2月10日 (五) 21:43 (UTC)

• @MilkyDefer：咱也模仿上面D2513850君使用《来自风平浪静的明天》生成的对话内容：（Q：谈谈《来自风平浪静的明天》这部动画）

《来自风平浪静的明天》（Your Name）是一部由新海诚执导的日本动画电影，于2016年在日本上映。该片以美妙的动画和复杂的人物关系角色，受到了广泛的好评。

故事讲述了两个生活在不同城市的高中生，偶然发现自己的身体可以穿越时空互换。随着故事的发展，他们不断努力寻找对方，以解决自己的身份困惑和生活困境。

该片的动画效果非常出色，景象壮丽，配乐优美。此外，它也提出了一些深刻的社会问题，如家庭、友情、爱情和对未来的希望，对观众产生了深远的影响。

总的来说，《来自风平浪静的明天》是一部非常优秀的动画片，值得每个动漫爱好者去观看。

感觉完全是按照《你的名字。》的内容去生成的 囧rz……--忒有钱🌊塩水あります🐳（留言） 2023年2月12日 (日) 19:58 (UTC)

• (－)反对：所有机器人辅助的编辑应该予以允许，但人类用户必须在发布前核对内容。--The Streif（留言） 2023年2月13日 (一) 04:21 (UTC)
• @忒有钱：建议在发布到维基百科前先检查chatGPT所生成的内容是否有问题（如事先阅读或观看内容（例如《入间同学入魔了！》漫画或PubMed文献））--林勇智 2023年2月14日 (二) 13:40 (UTC)
• 我也试了一下，看起来效果不佳，因为他生成的内容很容易有编造和过度联想的状况，少至生成的内容真伪查核困难。我的测试事先给ChatGPT阅读相关文章，再请他整理成维基百科条目：请阅读下列文章并将其整理成一篇中文维基百科条目，并且使用wikitext源代码编写条目，须包含内部链接和信息框。（贴上wikia:w:c:danmachi:Wiene的全部内容）

  ChatGPT给了以下回答（内部链接和信息框是ChatGPT加的，我一字未改）

  以下是使用 wikitext 源代码编写的薇妮的中文维基百科条目：

薇妮
角色设定信息
物种	人鳞蛇
性别	女性
出生	地牢中层
所属	赫斯提亚家族

薇妮（ウィーネ）是一位神秘的人鳞蛇女性，生于地牢的中层。她以其琥珀色的眼睛和长银蓝色的头发以及身体上数个地方的鳞片而闻名，还有额头上价值高昂的“人鳞蛇之泪”红宝石。

在留在赫斯提亚家族期间，薇妮穿着由贝尔·克拉内尔提供的“沙马兰德毛衣”，以隐藏她作为怪物的身份。

薇妮有讲话的能力，这在怪物中是很罕见的，她以善良的性格而闻名。她与赫斯提亚家族特别是贝尔和春姬产生了依恋。尽管她有善良的性格，薇妮最初有着怯弱的本质，但在她重生后，她变得更加勇敢。

在外貌上，当薇妮救了一个小男孩时，她的身体从背部长出了一只翅膀，翅膀很大，即使折叠也可以覆盖她一半的身体。

当中不少过度联想，例如Infobox 内的所属：赫斯提亚家族（应为赫斯缇雅眷族，但不是重点），薇妮并不属于赫斯缇雅眷族，他只是暂时借住在赫斯缇雅眷族，表示ChatGPT过度联想，造成其产生若干与事实不符的内容，且这若不对主题有一定程度的了解，是不可能发现的错误，因为似是而非，据我所知，有些编者喜欢通过编写不是那么熟悉的主题来增广知识，万一那些编者因此无法抓出ChatGPT编造和过度联想的状况造成编辑的内容出现似是而非的内容该怎么查核？编者可能因为用了ChatGPT而导致在条目加入了似是而非错误内容而不知情，且也难以查核，如果是这样，不如直接禁止ChatGPT生成内容为好。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年2月14日 (二) 14:00 (UTC)

• (！)意见：相较ChatGPT定位于“聊天机器人”，近期Google推出的Bard或是微软的全新Bing更像是一个“搜索助理”，可以即时搜索并更新最新的消息，以全新Bing为例，在回答的时候会给出多项参考网站来源（可参考这篇评测文章：[3]。）ChatGPT本身是一个模型，拿来训练的数据库是固定的（所以才说只能回答2021年前的问题），生成的内容常在相似的语句打转。但这类新的人工智能搜索助理，我认为值得期待，对维基百科的编者也会有很大帮助。巴波（留言） 2023年2月16日 (四) 12:55 (UTC)
• (！)意见：我看得都很尴尬，一个个光光讨论ChatGPT的性能问题，明明已经有相关规定（机器人方针）了却没有实施方法，AI模型本来就是一个很大范围的事情，我记得站内好像就有人用类似工具创建条目，是不是.Net之类的，有一个谁专门用什么程序修正错误之类的，后来基本都是被封了。我觉得这种事情实际上就是一种钻空子，管理员应该要求使用AI及类似辅助程序的必须事先声明并经过测试才能开车上路，ChatGPT只是我们的第一个例子，看上去并不适合上街乱跑，但是也要考虑到以后还会有很多智能程序的例子在后面，我们的方针应该有长远考虑的打算。--Cat on Mars 2023年2月16日 (四) 20:04 (UTC)

  可参考en:WP:LLM和en:WP:ChatGPT--百無一用是書生 (☎) 2023年2月21日 (二) 01:59 (UTC)

思考了一下，虽然AI问题很多，但或许可以参考维基媒体基金会台湾分会的这则贴文的说法，仅限资深用户使用，并且要严密检查？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年3月1日 (三) 17:53 (UTC)

我的提议是在在机器人方针中明确AI适用于本方针，如果按照链接内的条件（1.AI程序需要经过检验；2.AI程序需要自己负责；3.标记AI程序输出内容；4.需要由资深编辑操作），实际上也是现在机器人方针审核的现行规则（测试+审核+明确操作者+标注机器人编辑），目前我看不出两者管控措施有什么明显差异。----Cat on Mars 2023年3月4日 (六) 16:50 (UTC)

就现阶段而言，我亦认为在机器人方针及（或）翻译指引中相关段落明确提及人工智能即足矣。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年3月4日 (六) 19:42 (UTC)

刚刚测试感受了一下：一个样例--Evesiesta_{COVID-19感染中} 2023年3月5日 (日) 08:32 (UTC)

参考资料

如果维基百科现有的技术无法侦测到对方使用ChatGPT或类似AI工具的生成内容，那么楼上各位所说也只是空话，更何况出自人手造假的（例如：折毛事件），你们也是经过很多年之后才发现，这就是活生生的警惕。因此，如果在没有技术可以避免下，未来可能仍会有造假内容发生，这是现在维基百科的公信力最大的问题。--2001:B011:A401:3B94:3825:963C:D5D8:1D8（留言） 2023年3月8日 (三) 05:05 (UTC)

连接号一字线的符号选择

提议：当前MOS:连接号一字线的符号选择"U+FF0D － FULLWIDTH HYPHEN-MINUS"不是通行的做法。改用 U+2014 — EM DASH 是更好的选择。

之前已经有多次讨论，大部分编辑表示支持，但都没有继续推进：

• Wikipedia_talk:格式手册/标点符号/存档1#抛弃全角连字符（U+FF0D），改用em_dash（U+2014）字符表示“一字线”连接号
• Wikipedia_talk:格式手册/标点符号/存档2#又议格式手册标点符号中的连接号
• Wikipedia_talk:格式手册/标点符号/存档2#连接号字符

总结起来：

1. U+FF0D － FULLWIDTH HYPHEN-MINUS是短横线 U+002D - HYPHEN-MINUS的全形版本，二者应该表达相同的含义，不应重复使用。既然短横线已经选择了 U+002D - ，一字线就应该选用其他字符。
2. 使用 em dash 对字体渲染有更好的支持。
3. 使用 em dash 作为连接号是中文印刷品中的主流选择。
4. 全角连字符U+FF0D － 从未被广泛使用过。（除了中文维基百科）
5. 多数中文字体对全角连字符的支持并不理想。
6. 一字线应当恰好占据一个字符（即一个 em 长度）。
7. 一字线应当恰好是破折号的一半。

因此建议推荐使用 U+2014 — EM DASH 作为一字线的符号，不再把 U+FF0D － FULLWIDTH HYPHEN-MINUS 作为推荐的符号，但也并不将其列为错误用法。

现行条文 连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为：短横线“-”（U+002D）和一字线“－”（U+FF0D）。中华人民共和国国家标准及中华民国教育部标准中浪纹线“～”可与一字线通用，但在维基百科中不建议采用浪纹线。如果输入一字线不方便，可用{{一字线}}（{{连接号}}）。 连1：短横线用在： 化合物名称，如：β-巯基乙醇、β-羟-β-甲戊二酸单酰辅酶A。 连接号码，如：ISBN 978-0-12-155089-9 。 表示年月日，如：2012-12-21。 连接复合名词，如：南极-艾托肯盆地、比尔-朗伯定律。 产品的名称和型号，如：IA-64处理器。 汉语拼音、外来语内部的分合，如：玛丽亚·斯克沃多夫斯卡-居里。 连2：一字线可用在： 1. 相关项目的起止。 正确：法兰克福－巴黎 错误：法兰克福——巴黎、法兰克福—巴黎、法兰克福-巴黎 2. 数值范围。在不引起歧义的情况下，可省略前一数值的单位或附加符号，如：1000－2000年、1－5千克。

提议条文 连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为：短横线“-”（U+002D）和一字线“—”（U+2014）。浪纹线“～”可与一字线通用，但在维基百科中不建议采用浪纹线。一字线的输入方法与破折号类似。如果输入一字线不方便，可用{{一字线}}（{{连接号}}）。 连1：短横线用在： 化合物名称，如：β-巯基乙醇、β-羟-β-甲戊二酸单酰辅酶A。 连接号码，如：ISBN 978-0-12-155089-9 。 表示年月日，如：2012-12-21。 连接复合名词，如：南极-艾托肯盆地、比尔-朗伯定律。 产品的名称和型号，如：IA-64处理器。 汉语拼音、外来语内部的分合，如：玛丽亚·斯克沃多夫斯卡-居里。 连2：一字线可用在： 1. 相关项目的起止。 正确：法兰克福－巴黎 错误：法兰克福——巴黎、法兰克福-巴黎 2. 数值范围。在不引起歧义的情况下，可省略前一数值的单位或附加符号，如：1000－2000年、1－5千克。

--InstantNull（留言） 2023年2月8日 (三) 20:15 (UTC)

1. 不认同字符选择与表达含义间存在关联
2. 在默认及常见字体中未见明显证据
3. 部分承认（即便在正规印刷品中，002d也有一定使用，虽然可能是误用）
4. 承认
5. 在默认及常见字体中未见明显证据
6. 在微软雅黑中2014略长于em，反之ff0d未见问题
7. 未见可靠出处

综上反对提案。--。->>Vocal&Guitar->>_留言 2023年2月9日 (四) 02:54 (UTC)

• 不认同您对 (1) 的意见，Unicode符号本身是具有语义的，形似而不同义的字符都会进行分离，不应混用。en:hyphen和en:dash的用法是不同的；
• 连接号用U+2014是有权威出处的，如台教标在线网页《重订标点符号手册》修订版。大陆的GB/T 15834-2011虽然公开的是扫描件，不能确定码位，但也明显更像U+2014而不是U+ff0d。

--DvXg 📬 2023年2月9日 (四) 06:55 (UTC)

关于（1）我想不应该有疑问。正如David Xuang所说，Unicode对于每一个字符都有明确的定义。U+FF0D － 是 U+002D - 的全形版本（您可以参考全形和半形了解更多），它们本质上是同一符号的不同字符表示，在中文里同时混用是不恰当的。就如同我们不应该在中文里同时使用半形“/”和全形“／”是一个道理。

U+FF0D“－”在 macOS Chrome 下有衬线字体中的显示

关于（2）可以请您参考右侧的截图，U+FF0D － 在 macOS Chrome 浏览器中的显示效果。在正文中的是无衬线字体，在标题中的是有衬线字体，二者差异很大，标题中有衬线的字体显示效果非常不理想。

关于（6），我指一个字符宽即一个em 单位，参见Em (字体排印学)。

关于（7）我想多做一点解释。在英文中 en dash 和 em dash 的关系就类似于中文里的连接号与破折号之间的关系一样。传统上 en dash 的长度就是 em dash 的一半。类似的，中文里破折号既然已经广泛接受用两个em dash “——”表示，那么连接号用一个 em dash 才是符合惯例的。

--InstantNull（留言） 2023年2月9日 (四) 18:37 (UTC)

1. 我关心的是中维常年使用ff0d，现状是否对文章内容的表达产生了歧义？字符的定义在这里并没有特别强调的必要。即便如法兰克福—巴黎变为法兰克福-巴黎也不会产生另一种意义。

2. 我注意到这张截图是2018年，不清楚目前是否仍然有效，我持有的设备（Windows，Android，Ubuntu）上没有发现类似问题。我希望您能多举例以证实“多数中文字体支持不理想”的主张。

6. 建议实测。

7. 您个人的意见我无法评论。另我认同国标推中使用2014，但不认同维基百科需要调整。--。->>Vocal&Guitar->>_留言 2023年2月10日 (五) 03:54 (UTC)

可否将您的意见理解为"将错就错"?再比如,我在这行句子中,全部错误地使用了半形标点.但这其实丝毫不影响您理解这段话的意思对吗?

常年使用不是一个合理的理由。本人实际上是推动将MOS:标点符号升格为指引的发起者之一，当时连接号码位选择并没有经过讨论，该错误一直遗留至今。中文维基在发展中必然会遇到需要标准化的需要。方便编辑输入和方便读者阅读、检索是必要的现实需求。甚至有一些读者会将维基百科的格式奉为标准，因此我们有义务提供准确的信息。再者我也提到，新指引只是不再把 U+FF0D 作为推荐的符号，不妨碍兼容已有的使用。

截图中的问题仍然存在。之前提到 U+FF0D 从未被广泛使用过，因此有部分中文字体对 U+FF0D 做了专门的字形设计而另一些没有，使得其在实际的主流字体中没有一致的外观。和您提到微软雅黑的问题一样，这是一个字形（glyph）设计概念。这篇文章中有提到，旧版微软雅黑的标点是过时的且不符合国标。这篇文章介绍了相关背景：“但绝大多数中文字体甚至一些西文字体对 U+2014“—”（Em Dash）的显示效果比西文标点 Em Dash 应有的宽度宽一些，基本符合一字线的形式要求。”

以上内容并非个人观点，我已提供了一些资料供您参考，这基本上是中文字体排版的共识。W3C中文支持文档明确写道：“《标点符号用法》（GB/T 15834—2011）中没有指定这三个符号的码位，但是基本上可以推断一字线是U+2014 EM DASH [—]”。--InstantNull（留言） 2023年2月10日 (五) 07:56 (UTC)

( π )题外话：无论一字线用什么符号，美国－墨西哥－加拿大协议按MOS:连接号指引应该用短横线，应移动到“美国-墨西哥-加拿大协议”。——小林子冲（留言） 2023年2月20日 (一) 20:17 (UTC)

我个人亦希望能够规范连接号之使用。不过必须提醒，根据统计，目前本站至少有三千余篇条目及其他三千余个页面之标题含有“－”（另有四千余个重定向，总计一万出头），更不用提内文了；因此，若要更改连接号标准，应考虑动用机器人进行移动。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年2月10日 (五) 08:32 (UTC)

是的，所以我其实并不建议将原符号算作错误使用。较好的做法是将标准改正，确保新条目和新文章使用正确标准，并向后兼容，让社区自己逐渐修正。--InstantNull（留言） 2023年2月10日 (五) 17:30 (UTC)

我倒是建议进行一次集中批量移动，一劳永逸。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年2月11日 (六) 10:57 (UTC)

(＋)支持提案。中文维基百科选用U+FF0D作为连接号是奇怪的事情，既不符合任何规范又不便于输入。--Lt2818（留言） 2023年2月10日 (五) 14:06 (UTC)

囧rz……“一字线可以通过中文输入法输入破折号并删去一半得到”？我想说Windows10的仓颉输入法并没有这个功能。--街燈電箱150號 开箱维修 抄表 检验证明 2023年2月10日 (五) 14:22 (UTC)

仓颉输入法“ZXAY”会得出一个 Em dash. 谢谢提醒，我已对修订条文做了改动。--InstantNull（留言） 2023年2月10日 (五) 17:44 (UTC)

原则上支持。但我的担心是，如果只是推荐使用U+2014，而不将U+FF0D视为错误，那会造成两者同时存在的混乱局面，还有可能导致一些编辑争议出现。但另一方面，如果要禁止U+FF0D，那修正目前条目中现有的大量U+FF0D感觉是一项不小的工程。当然可以用机器人处理，但也需要注意不应误伤，比如参考文献的标题如果原本用的就是U+FF0D的话我想不应该去修正？还有一些有关Unicode、字体排版等条目中也有确需使用U+FF0D的情况。--Stevenliuyi（留言） 2023年2月11日 (六) 18:45 (UTC)

为了避免新旧共存引发混乱，我个人建议对现有页面进行一次集中批量移动。至于正文，可能需要研发小工具专门更改连接号，加快速度。参考资料的话更是一团乱，可能有本来就用这符号的，也可能有后来被改的，没有办法用机器人处理，只能比照正文，并研发小工具加速更改。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年2月12日 (日) 07:05 (UTC)

Wikipedia:格式手册/标点符号是不适用于参考文献的哈。--InstantNull（留言） 2023年2月13日 (一) 01:25 (UTC)

(？)疑问：有没有办法追踪有人有意或者无意地使用汉字“一”（壹）代替连接号“—”（U+2014），有些系统中汉字“一”和连接号肉眼区分不出来。快捷输入的问题，个人的方法是不少输入法（包括PC、手机）会提供自定义短语，比如设置成“一字线”的拼音或者其他码表，快捷输入应该问题不大。--Kethyga（留言） 2023年2月15日 (三) 11:17 (UTC)

在本人手机上U+FF0D的显示效果比PC网页上号。--Kethyga（留言） 2023年3月2日 (四) 06:20 (UTC)

它之所以叫“一字线”是有原因的哈哈。甚至可以说这是U+FF0D“－”的另一个问题：它太短了，和短横线太像而太不像“一”字了。故意用相近字形的字符替换不是 em dash 所特有的问题，正如同我们没有办法故意检测有人故意用数字0去替换字母O一样。在很多软件里也有自动替换功能，比如在Word里输入“--”会被自动替换成em dash--InstantNull（留言） 2023年2月16日 (四) 05:56 (UTC)

[0-9a-zA-z]一[0-9a-zA-z]这种情况也许是可以加入过滤器的（应该不会有假阳性），就是涵盖的范围可能还不是很够。--DvXg 📬 2023年2月17日 (五) 11:45 (UTC)

(＋)强烈支持。之前的讨论没有继续推进着实可惜，希望这次能一劳永逸解决中维连接号问题。--PexEric 💬|📝 2023年2月18日 (六) 08:48 (UTC)

(＋)支持：使用全角的连字暨减号（“－”，U+FF0D）作为“一字线”或“连接号”的确不是常用的做法。Em Dash（“—”，U+2014）在简体中文下是破折号的一半，输入起来很方便。

在大陆，中华人民共和国国家标准规定了一字线的符号（[4]），看起来有点像Em Dash，而不是全角的连字暨减号（连字暨减号看起来更短）。不过这是一个PDF文档，难以确定到底用的是哪一种。

在台湾，连接号条目里说了“台湾教育部《重订标点符号手册》修订版使用em dash作连接号。”

综合上述各地情况，支持将格式手册的连接号改为Em Dash（“—”，U+2014）。——小林子冲（留言） 2023年2月20日 (一) 20:06 (UTC)

(？)疑问：英维那边使用的连接号为 en dash（“–”，U+2013），而本地的 cite 系列引文模板自英维引进，其中用于连接页码的也是该符号，因此在站内有着大量用例。在本人的设备上看来，连字暨减号“－”（U+FF0D）太短，视觉效果很差，而 em dash“—”（U+2014）又显得过长了，超出了一个汉字的宽度。考虑到连接号最常使用的地方是在数字之间，故其长度如能与数字的宽度相仿理应看着最舒适。使用比汉字还宽的 em dash（U+2014）来连接数字，视觉效果似乎略显累赘。总之，这两个符号看上去都不如长度适中的 en dash（U+2013）美观，所以我们为什么不效仿英维，以 en dash 作为首选连接号？这样一来既能确保美观，又能与引文页码中的连接号保持一致。虽然参考文献使用的符号不必与正文相同，但如能使整篇条目中的连接号整齐划一，未尝不是更好的选择。--萧漫（留言） 2023年3月1日 (三) 23:19 (UTC)

这里所有的讨论只针对内文和标题，不适用于文献引用。文献引用有另外单独的格式标准。维基百科:格式手册/标点符号第一段最后一句也说明了这一情况。--InstantNull（留言） 2023年3月2日 (四) 03:26 (UTC)

再提取消文件移动员并下放权限

现今，文件移动员身份组仅有2人，且文件移动需求不高，在本地需移动的文件一般也无特别大的争议，故再次提议取消文件移动员并将权限下放，个人认为可下放至延伸确认用户。--在下荷花，请多指教（欢迎签到） 2023年2月11日 (六) 14:04 (UTC)

(＋)支持 感觉这个权限组没什么意义，建议将该权限进一步下放到自动确认用户。为避免移动破坏，保留“移动时不留重定向”给延伸确认用户。第一眼看到这个提案的反应是“什么，我们还有文件移动员？！”的顺颂时祺 ZhaoFJx^{（论•编）} 2023年2月12日 (日) 02:18 (UTC)^{[开玩笑的]}

我是，另外移动不留重定向在文件移动方面没有独立的权限，所以分不出来。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 03:09 (UTC)

唔，如果这样的话就不要下放了，因为移动破坏也不是不常见。——顺颂时祺 ZhaoFJx^{（论•编）} 2023年2月12日 (日) 03:12 (UTC)

不反对将文件移动权限（movefile）下放到延展确认用户。但移动后不留原名（suppressredirect）是否也下放到延展有保留。附，现在“文件移动”给了巡查阔免、巡查、文件移动组，“移动后不留原名”给了萝卜（bot）组、巡查、回退、跨维基导入。（或者说拿到巡查基本上都能用上）——Sakamotosan路过围观 | 避免做作，免敬 2023年2月12日 (日) 05:32 (UTC)

本案不提议下放不留重定向权限。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 06:31 (UTC)

(＋)支持下放 movefile 权限至延伸确认用户并移除文件移动员用户组。--冥王欧西里斯（留言） 2023年2月15日 (三) 03:17 (UTC)

	上任日	除权日	用权数
Sanmosa的移动日志	2021年9月23日	2022年2月1日	0
RyanCray的移动日志	2020年11月12日	2022年12月7日	17
Minorax 的移动日志	2019年7月13日	至今	1
TimWu007的移动日志	2019年10月28日	2020年8月11日	32
和平至上的移动日志	2018年6月13日	2018年6月17日	0
hehua的移动日志	2022年2月22日	至今	67

更新于：2023年2月12日 (日) 10:09 (UTC) 再作了一次统计。Ghren🐦🕕 2023年2月12日 (日) 10:11 (UTC)

看起来好像还可以，我是觉得这个需求不是很大可以下放。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 14:01 (UTC)

(＋)支持&(！)意见：若下放至扩展确认，不建议取消文件移动员组别，应保留以备自动确认组或是确认用户组的用户申请；若下放至自动确认用户，则支持取消文件移动员组别。另外，个人支持权限下放，文件移动员组别的权限敏感度应当和普通页面移动权类似，没有必要加以限制。至于是下放到扩展确认还是自动确认，由于文件方针较普通页面更严，认为先行下放至扩展确认较为合适。H.Natsumi ™ 2023年2月12日 (日) 14:53 (UTC)

那也可以。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 15:27 (UTC)

• (＋)支持：就是不知道哪些天兵用户想出来的类似巡查豁免权一样的没屁用权限（有跟没有意思一样），这讨论看了就真可悲，应当直接废除这种没屁用权限才是。还有，这个讨论不是应该再邀请热衷于文件存废讨论的@Wcam来讨论才合理吗？也没有人提到要是文件名与维基共享资源重复的问题？奇葩。总之，这讨论串基本上没什么好讨论的，独裁社群就是喜欢把简单的事情复杂化。--Z7504非常建议必要时多关注评选（留言） 2023年2月13日 (一) 15:53 (UTC)

现在来看基本上都支持下放至延确，但是对于是否取消用户组似乎还有不同意见，想问一下应不应该取消呢？个人是倾向取消，但是需要处理的移动文件分类可以保留。--在下荷花，请多指教（欢迎签到） 2023年2月15日 (三) 06:05 (UTC)

我个人倾向取消，毕竟中文维基百科目前的延伸确认用户已有三千多人，都已经是英文维基百科的文件移动员人数的十倍左右了（不过英文维基百科的文件移动员仅有 movefile 而无 suppressredirect 权限），保留文件移动员用户权限群组无甚必要，要找到延伸确认以上权限的用户协助移动也不困难。--冥王欧西里斯（留言） 2023年2月15日 (三) 06:37 (UTC)

@S8321414中文的文件移动员也没有不留重定向。--在下荷花，请多指教（欢迎签到） 2023年2月15日 (三) 07:49 (UTC)

那么更没有问题了，更何况 movefile 在管理员、巡查员与巡查豁免都有，就算自确没有，要找到有此权限的人也应当不困难。--冥王欧西里斯（留言） 2023年2月15日 (三) 08:30 (UTC)

个人提议如果下放扩展确认仍保留文件移动员组别的原因其实就是Minorax的权限申请，确实无法排除存在跨域贡献者愿意参加本地文件移动的可能性，而目前中文维基百科的扩展确认门槛较高（如果先前没有自动创建中文的账号则需要等待90天），合理认为这样会影响到跨域贡献者的贡献（虽然可以提交移动请求，但是显然对于这一类人直接授权来的更好）。H.Natsumi ™ 2023年2月15日 (三) 08:40 (UTC)

这个也确实，@S8321414 您怎么认为？--在下荷花，请多指教（欢迎签到） 2023年2月15日 (三) 12:00 (UTC)

我个人还是倾向废除文件移动员群组，但暂时保留还算是可接受的选项（不过这个暂时不知道有多久就是了）。--冥王欧西里斯（留言） 2023年2月15日 (三) 12:45 (UTC)

@Hotaru Natsumi：经查，Minorax已系延确。另：个人建议文件移动员权限可改为仅以临时权限形式授予。Sanmosa _{Συ γάρ μοι και μοίρα εί και τύχη} 2023年2月16日 (四) 06:49 (UTC)

大概接近想法。将“文件移动”下放到延展用户，现有组保留并辞退现有组员，只作为临时授权给没到延展用户的后备，可以自行移除自己组。这样避免浪费组功能，也可以应对特定情况。——Sakamotosan路过围观 | 避免做作，免敬 2023年2月16日 (四) 07:24 (UTC)

啊不是说Minorax的权限会因此而被移除，而是说因为Minorax的例子个人认为这个组应该要保留，以避免后续如Minorax这样的跨域贡献者在存在经验可以获得该权限的情况下难以直接获得这一权限。另外关于仅授权临时权限，应是合理且必要的，确实若得到这一权限，保持活跃编辑不出12个月应当能够达到扩展确认权限门槛。H.Natsumi ™ 2023年2月16日 (四) 09:01 (UTC)

感觉没有必要仅授予临时权限，没什么意义，达到了再除权就完了。--在下荷花，请多指教（欢迎签到） 2023年2月16日 (四) 09:04 (UTC)

这样也行，就是扩展确认本身是自动授权的，有必要的话可以写个机器人自动提报或者自动除权。H.Natsumi ™ 2023年2月16日 (四) 09:25 (UTC)

也可以。--在下荷花，请多指教（欢迎签到） 2023年2月16日 (四) 10:48 (UTC)

我认为你搞错了一些点，保留组是为了临时授权的需要，实务上不再使用“文件移动员”组，延展用户的达标是需要一定的编辑量，临时授权是为了前面的情况（例如上面提到的Minorax，19年授权，但到21年才到延展）。——Sakamotosan路过围观 | 避免做作，免敬 2023年2月17日 (五) 00:29 (UTC)

@Cwekemm我没明白，请问这里的临时授权说的是不授予无限期权限还是什么别的？--在下荷花，请多指教（欢迎签到） 2023年2月17日 (五) 06:37 (UTC)

就是有期限的组别授权。组别不再长期授予，保留组别是为了应对没到延展的情况临时使用。——Sakamotosan路过围观 | 避免做作，免敬 2023年2月17日 (五) 06:45 (UTC)

啊，那授予多长时间呢？这要修改方针吧。--在下荷花，请多指教（欢迎签到） 2023年2月17日 (五) 06:54 (UTC)

因为提出Minorax这个案例，我也不太确定。因为原本就是干脆整组移除的，Minorax的按钮才考虑临时留下。如果参照的话，可以看LIPE的临时授予期？好像常见是半年。——Sakamotosan路过围观 | 避免做作，免敬

大致支持。另外，延伸确认用户得到的不是完整的“文件移动员”权限，没有suppressredirect，不排除有人希望不留重定向移动文件，且不是巡退员。可留作该用。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年2月17日 (五) 14:29 (UTC)

@魔琴文件移动员本来就没有suppressredirect权限。--在下荷花，请多指教（欢迎签到） 2023年2月18日 (六) 01:01 (UTC)

哦这样啊，恕在下失察，谨撤回意见。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年2月18日 (六) 04:41 (UTC)

不反对也不支持下放。目前除了文件移动员外，movefile权限还赋予了管理员、巡查员与巡查豁免，后两者的门槛不高，且移动文件似乎基本上就是巡查工作才需要使用吧。不过既然suppressredirect不下放，倒也不用担心错误移动文件导致红链的问题，因此中立。--BlackShadowG Slava Ukraini! 2023年2月19日 (日) 02:24 (UTC)

也会有一些上传的时候填错了名想改发现只能请求的情况。--在下荷花，请多指教（欢迎签到） 2023年2月19日 (日) 09:05 (UTC)

我觉得权限留着也没有什么大碍。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年2月20日 (一) 02:28 (UTC)

提议条文

看上去是没什么大的反对意见了，先放个条文修改如下：

WP:EXTENDEDCONFIRMED：

现行条文 一个已注册的用户会在注册达90天并编辑达500次后自动被授予该群组权限。该群组的权限允许用户编辑受到延伸确认保护的页面。

提议条文 一个已注册的用户会在注册达90天并编辑达500次后自动被授予该群组权限。该群组的权限允许用户编辑受到延伸确认保护的页面，且相较于自动确认用户，还可以移动文件。

WP:FM：

现行条文 文件移动员用户权限允许有经验的用户，依据方针执行文件更名工作，以便享有如同自动确认用户移动维基百科条目的便利功能。 任何管理员可以在审慎考虑之下，授予可信任用户这个权限，该用户必须经常处理多媒体文件，且熟悉各类多媒体重新命名的相关方针与指引。文件移动员的资格基本资格要求是： 自首次编辑以来参与维基百科满30日； 至少250次编辑，以及过去3个月内（未满3个月之新注册用户，从注册之日起计算至当日）平均编辑次数多于1次；或曾经提出有效文件移动申请（包含维基共享资源）至少20次（将会从用户贡献中的文件编辑历程中查证）； 最近1年内未曾受到封禁处分（不合理封禁除外）；且 申请时须回答管理员或现有文件移动员相关方针与指引的知识及应用问题。 除此之外，文件移动员应当非常熟悉维基百科的图像与多媒体方针（尤其是本页面当中的重新命名指引）、对图像更名程序有充分了解和具有处理图像相关工作的经验。 如果用户曾在维基共享资源执行相同工作、使用相关工具以及其他多媒体文件的相关类似经验，管理员或许会将这些经验作为是否授予权限的考虑因素。 除非刚来的编辑者曾上传一定数量的文件，否则本用户权限一般不会授予此类编辑。 如果您有意为您或其他用户申请文件移动的权限，请到Wikipedia:权限申请/申请文件移动权申请。以下用户不需要去申请或是为他们增加本权限，他们本身已经获自动授予文件移动的权限： 管理员； 巡查员； 巡查豁免者。

提议条文 文件移动员用户权限允许有经验的用户，依据方针执行文件更名工作，以便享有如同自动确认用户移动维基百科条目的便利功能。 文件移动权限已于?年?月?日并入延伸确认用户组，文件移动员权限组现仅保留以便授予未达延伸确认的跨域贡献者文件移动权。 如果您有意为您或其他用户申请文件移动的权限，请到Wikipedia:权限申请/申请文件移动权申请。申请人应当已于维基共享资源或其他维基媒体旗下项目取得相应的文件移动权限，且在其他维基媒体项目进行过一定数量的文件移动。 当持有文件移动员权限组的用户达到了延伸确认或是取得了巡查或巡查豁免资格，则应当自行移除文件移动员组别。 以下用户不需要去申请或是为他们增加本权限，他们本身已经获自动授予文件移动的权限： 管理员； 巡查员； 巡查豁免者； 延伸确认用户。

以上。H.Natsumi ™ 2023年2月24日 (五) 02:49 (UTC)

好！--在下荷花，请多指教（欢迎签到） 2023年2月24日 (五) 05:42 (UTC)

申请资格第二项看起来是多余的，是否是延伸确认用户的笔误？--Xiplus#Talk 2023年2月24日 (五) 06:02 (UTC)

本意是不持有movefile这个权限，不是指文件移动员这个权限组，实际操作中有这个权限的应该也不会重复申请，想来确实可以移除这个条件，已修改。H.Natsumi ™ 2023年2月24日 (五) 08:24 (UTC)

(～)补充：此外Wikipedia:权限申请/申请文件移动权/header应当也要做相应更动，或者更加浅显地说，只保留欲申请文件移动权，请点击下方“增加新请求”。，并且加上：

注意：文件移动权已于?年?月?日并入延伸确认用户，此页面现仅供跨域贡献者在未达延伸确认要求，且未取得巡查员、巡查豁免者权限时临时申请文件移动权。普通用户不应在此申请文件移动权，而应使用{{Rename media}}代替，直到获得延伸确认用户权限、巡查权或巡查豁免权。详见Wikipedia:文件移动员。

供参。H.Natsumi ™ 2023年2月24日 (五) 08:43 (UTC)

(＋)支持--Evesiesta_{COVID-19感染中} 2023年2月26日 (日) 03:33 (UTC)

---

整案提出已近7天无反对意见，本案最终结果是下放文件移动员权限但不取消文件移动员，以方便跨维基贡献者进行文件移动。现 公示7日，2023年3月9日 (四) 13:48 (UTC) 结束。--在下荷花，请多指教（欢迎签到） 2023年3月2日 (四) 13:48 (UTC)

Wikipedia:格式手册/标点符号#书名号新增使用Template:《的方法，修改使用代码的方法，并调整“效果为”的位置

现行条文 维基百科提供了两种方法解决部分书名号使用地区差异，所以遇到部分书名号使用地区差异问题时应用以下两种方法解决，而不应单纯替换源码的双单书名号，否则会被视为繁简破坏。其中Template:单双书名号转换用于实现“书2”中双书名号与单书名号之间的使用差异。Template:引书号转换用于实现“书3”中引号与双书名号之间的使用差异。 使用模板： {{单双书号转换|需转换的作品名}} {{引书号转换|需转换的作品名}} 效果为： 《需转换的作品名》 “需转换的作品名” 使用代码： -{zh-hans:《;zh-hant:〈;}-需转换的作品名-{zh-hans:》;zh-hant:〉;}- -{zh-hans:“;zh-hant:《}-需转换的作品名-{zh-hans:”;zh-hant:》}- 效果为： 《需转换的作品名》 “需转换的作品名”

提议条文 维基百科提供了三种方法解决部分书名号使用地区差异，所以遇到部分书名号使用地区差异问题时应用以下三种方法解决，而不应单纯替换源码的双单书名号，否则会被视为繁简破坏。其中Template:单双书名号转换用于实现“书2”中双书名号与单书名号之间的使用差异。Template:引书号转换用于实现“书3”中引号与双书名号之间的使用差异。 使用模板： {{单双书号转换|需转换的作品名}} 效果为： 《需转换的作品名》 {{引书号转换|需转换的作品名}} 效果为： “需转换的作品名” 使用模板： {{《}}需转换的作品名{{》}}或{{〈}}需转换的作品名{{〉}} 效果均为： 《需转换的作品名》 使用代码： -{zh-hans:《;zh-tw:〈;zh-hk:《;}-需转换的作品名-{zh-hans:》;zh-tw:〉;zh-hk:》;}- 效果为： 《需转换的作品名》 -{zh-hans:“;zh-hant:《}-需转换的作品名-{zh-hans:”;zh-hant:》}- 效果为： “需转换的作品名”

1. 新增Template:《的方法，参见Template:《。
2. 修改zh-hans:《;zh-hant:〈;为zh-hans:《;zh-tw:〈;zh-hk:《;，否则在香港繁体下，模板的结果和代码的结果不一致。
3. 调整“效果为”的位置。
   ——小林子冲（留言） 2023年2月21日 (二) 05:28 (UTC)

• ( π )题外话：单双书名号可以设置地区词处理，为什么“标有引号的并列成分之间、标有书名号的并列成分之间通常不用顿号”不设置地区词处理，甚至还有用户说“有地域中心之嫌”？——小林子冲（留言） 2023年2月21日 (二) 05:34 (UTC)

三种方法本质都是一样的，只是代码实现上有所不同。对于格式手册写这么长太啰嗦了。直接写成下面这样就好：

{{《}}需转换的作品名{{》}}、{{〈}}需转换的作品名{{〉}}或{{单双书号转换|需转换的作品名}}

PS：另外还有一种方法是把双书名号改成单书名号，然后加入{{NoteTA|1=zh-cn:《;zh-tw:〈;zh-hk:《;}}。好像音乐类条目有这样的操作。--洛普利宁 2023年2月21日 (二) 13:54 (UTC)

(＆)建议：格式手册确实应修订部分条文，使站内的顿号用法得以规范化。可将以下代码加入手册供编者复制粘贴，在转换书名号的同时消除大陆简体模式下多余的顿号：

{{NoteTA
|1 = 〈=>zh-tw:〈; 〈=>zh-hk:《; 〈=>zh-cn:《; <!-- 中国大陆仅在双书名号之内使用单书名号 -->
|2 = 〉=>zh-tw:〉; 〉=>zh-hk:》; 〉=>zh-cn:》;
|3 = zh-tw:〉、〈; zh-hk:》、《; zh-hans:》、《; zh-cn:》《; <!-- 依中国大陆现行规范用法，书名号之间不加顿号 -->
|4 = zh-hant:》、《; zh-hans:》、《; zh-cn:》《;
|5 = zh-hant:」、「; zh-hans:”、“; zh-cn:”“; <!-- 依中国大陆现行规范用法，引号之间不加顿号 -->
}}

当然，更好的处理方式是将后三条转换规则加入全局转换。如遇特殊的例外情况，确需在标有引号或书名号的并列成分之间显示顿号，可手动添加-{}-以包含顿号。鉴于这种例外情况极其少见，故在此提议加入全局转换。--萧漫（留言） 2023年3月1日 (三) 22:06 (UTC)

(－)反对萧漫的提议，上次讨论确认不强制规定书名号及引号间用不用顿号才不过一个月不要立刻重提，不解决该讨论的有效反对意见则不应通过此项。--路西法人 2023年3月2日 (四) 03:07 (UTC)

上次反对的是直接两岸三地都将之视为标准吧，但没有反对在大陆使用此方案啊。--Ghren🐦🕓 2023年3月2日 (四) 08:11 (UTC)

您可以再读一次讨论，有留言指出虽然被列为标准但仅为新设且民间仍有不认同的声音。--路西法人 2023年3月2日 (四) 14:43 (UTC)

那个讨论我有看，也有发过言。Y君说的是不推荐也不反对，总之是没有人明确反对在大陆使用此案就是了。您可以说有人提出在该讨论说过该标准在大陆争议，然后您反对，而不是直接说解决该讨论的反对意见。谢谢。Ghren🐦🕚 2023年3月2日 (四) 15:21 (UTC)

YF君原话是可能不应推荐这种写法，但也无需禁止：“可能不应推荐”仍然是对该案和此案的有效争议意见。虽该留言未明确对大陆使用此案提出争议，但也是指出了相关争议，同样需要回应。看来只是我们对我们自己说的话以及他人留言的不同理解，无须再争论这点小事了。--路西法人 2023年3月3日 (五) 10:34 (UTC)

(－)反对。该方案在大陆有争议，实务上执行者也不多。

唐普.新国标《标点符号用法》并列的引号、书名号间省略顿号规定的问题辨正[J].四川师范大学学报(社会科学版),2022,49(02):199-208.DOI:10.13734/j.cnki.1000-5315.2022.02.023.

[1]张同学.对标点符号用法中一条顿号用法规则的探讨[J].传播与著作权,2020(04):22-24.DOI:10.16852/j.cnki.45-1390/g2.2020.04.009.

而且，据张龙的说法，“"《A》《B》和《C》""《A》《B》和《C》（D）"这两类用法并不违反国标规定,是经济实用的用法,应该成为顿号省略用法的取向;"《A》、《B》、《C》（D）""《A》（D）、《B》、《C》""《A》、《B》（D）、《C》""《A》（D）、《B》和《C》""《A》、《B》（D）和《C》"这五类用法中的顿号不可或缺。将前述7种用法中的书名号换为引号,亦然。 ”（张龙.出版传播中书名号或引号之间的顿号用法刍议[J].温州大学学报(社会科学版),2021,34(03):61-66.）

此转换方式会将"《A》、《B》、《C》（D）""《A》（D）、《B》、《C》""《A》、《B》（D）、《C》""《A》（D）、《B》和《C》""《A》、《B》（D）和《C》形式的顿号过度转换。--Ghren🐦🕓 2023年3月2日 (四) 08:17 (UTC)

提议设立“公共交通路线条目指引”

目前，公共交通路线条目的数量超过一万条，唯目前没有统一写法，而当中有大量条目以爱好者角度编写。故此，本人基于优良条目写了一个框架-“Wikipedia:公共交通路线条目指引”，望请列入格式手册。--唔好阻住我爱国（留言） 2023年2月23日 (四) 13:16 (UTC)

内容与Wikipedia:交通车辆条目指引高度重合。按你说的我也能造出来一堆毫无实际内容的格式指引。--PexEric 💬|📝 2023年2月26日 (日) 06:28 (UTC)

这是一个框架，是按照WP:GA条目的共通之处写的，最主要是看看这个框架有没有问题。--唔好阻住我爱国（留言） 2023年2月26日 (日) 15:50 (UTC)

铁路方面说“目前没有一定数量的条目列入优良条目标准，难以制定统一标准。”那巴士方面才不足十条优良条目也不见得就能代表到一万条条目的统一框架，而且目前全部优良条目都是来自香港的，其它地方却一条都没有，这就难保其它地方用这个框架会出现水土不服。看来现在根本还不是时候，所以(－)反对。--Maccomcre（留言） 2023年3月2日 (四) 01:50 (UTC)

有关管理员是否能删除自己之前投票删除的页面及其时效的问题

近日，本人提删了柯文哲和中华民国政党的关系的条目，后由管理员Shizhao执行删除。

不过该条目在四年前，Shizhao先生曾参与该条目初次的存废讨论，并投下删除一票。

因避嫌的一些事宜（删除：管理员不得删除自己提议删除或者投票删除的页面），我想向社群询问一下：

1. 管理员是否可以删除之前自己参与删除投票的条目？
2. 两次提删是否为避嫌守则中描写的一项事宜？

我个人是赞成删除。不过在守则方面，我们得谨慎一些。--WMLO（留言）。 2023年2月24日 (五) 14:06 (UTC)

WP:避嫌：“管理员不应该在一项事宜中使用普通用户和管理员的双重身份”。我认为两个AfD应该算两项事宜*。再者，管理员不可能记住自己所有参与过AfD的条目。因此我认为Shizhao的操作没有问题。当然，如果意识到之前参与过，主动避嫌还是一个很好的选择。［＊如果两次AfD有逻辑联系，比如第二次AfD来自DRV发还，或者是目前试行的RELIST流程，我认为还是应该视作一项事宜。］ ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年2月24日 (五) 17:21 (UTC)

你都说是四年前的事了，书生怎么可能记得呢，你会记得你四年前的今天吃了什么早餐麻:）--~~Sid~~ 2023年2月25日 (六) 01:54 (UTC)

@ASid：感谢您对于我记忆力的反问，但鄙人不善于吃早餐:) 若论不可能记得，这点同意：但删除页面的同时，也完全可以参考以前的提删事例，从这点也知道参与人数的意见，再进而看出以前自己曾参与过该页面的存废投票。并不是完全无可能的。当然，我也只是问一下一般人的标准。——WMLO（留言）。 2023年2月25日 (六) 12:03 (UTC)

至少要有时间间隔吧，因为有条目会在无共识保留一段时间后又被人提删了。假如两次提删的间隔不长，那么此时在上一次投过删除票的管理员就不应该删除。--日期20220626（留言） 2023年2月25日 (六) 13:50 (UTC)

佩服您翻旧账的能力。不过很难依据常识判断这两次提删属于一项事宜，两次页面的内容、编辑历史都是不同的，唯一的相同之处是在不同时间占用了同一名称。--PexEric 💬|📝 2023年2月26日 (日) 06:37 (UTC)

处理存废（包括积压）的时候，又要看有没有自己参与讨论，又要看讨论的最后时间是否超过5星期还是1星期，还要判断讨论的共识，这就已经难免顾此失彼了。。。。（说白了就是规则太复杂了）--百無一用是書生 (☎) 2023年2月28日 (二) 02:23 (UTC)

relist和vfd

由于relist启用，而vfd未相应更新，导致如想从条目页进入存废讨论必须再次点击，如多次relist，需多次点击。--Fire Ice 2023年2月26日 (日) 01:44 (UTC)

我已经提醒过Shizhao君了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年2月26日 (日) 14:29 (UTC)

试行期过了再决定要不要修比较好。--Ghren🐦🕑 2023年2月26日 (日) 18:09 (UTC)

重修封禁方针及禁制方针

重修封禁方针

细读本站封禁方针发现极严重翻译腔及欧化汉语问题，且遗漏关于多项实际有执行但没写在方针内的信息（例如封禁开放代理）或需要但不存在明确指引的信息（如解除封禁相关指导），故建议完全重修封禁方针以改善以上情况。重修方针草稿置于User:LuciferianThomas/项目/重修封禁方针。

望社群各成员协助复查并给予意见。--路西法人 2023年3月1日 (三) 03:32 (UTC)

仔细看了一下，解决了旧的问题，然后又产生了新的问题。很多句子您翻译进去的句子也是翻译腔和繁冗的，但我没有时间一一指出。另外，“手段”没有贬义。《汉语大词典》中“手段”有四个义项，此处是义项2，“为达成某种目的而采取的方法和措施”，而非带贬义的义项3。--Ghren🐦🕐 2023年3月1日 (三) 05:02 (UTC)

比如说：“封禁功能是管理员权限当中最具影响力的，管理员应当在执行封禁前了解情况，并必须能够佐证其执行的封禁的依据”：“封禁功能是管理员权限当中最具影响力的”，是不是“最具影响力”的呢，感觉很主观。“必须”就是“必须”，“能够”就是“能够”，什么是“必须能够”呢。“佐证”就是提出证据证明，那后边“依据”不就重复了。

“承诺停止不当行为并能展现已明白错误之处和汲取教训或已停止不当行为一段时间的用户可能可获解除封禁”，请问如何句读。

“如执行了一个可能具争议性的封禁”：“一个”是典型的翻译腔，然后“可能具争议性”句意上也不是很清楚。

“保护目的的封禁用于应对以下情形”：什么是“保护目的”？

““严重扰乱”包括不适合维基百科文明协作氛围及影响让参与者协作共建百科全书的行为”：为什么不能放到下边去呢。

“管理员可在发现被封禁用户操控其他账号绕过封禁编辑的情况下重设封禁时长；被封禁绕过封禁期间若继续有可致封禁的编辑行为，管理员亦可考虑延长封禁时长。”其实可以分成好几个小句的，不需要一句过的。不过我觉得这段内容全部都应该归到傀儡去就是了。--Ghren🐦🕒 2023年3月1日 (三) 07:27 (UTC)

正是需要社群协助复查。

• “手段”：我指的是negative connotation，虽然不是在此使用情况下带有贬义，但也可以被借来说是那个贬义的意思就变成讽刺，改成“技术措施”就没有这个问题，也是最factual的说法。
• “封禁功能是管理员权限当中最具影响力的。”删了
• “承诺停止不当行为并能展现已明白错误之处和汲取教训或已停止不当行为一段时间的用户可能可获解除封禁”改了。
• “如执行了一个可能具争议性的封禁”是旧版本已存在的问题，我没注意到这个。改成了“执行可能具争议性的封禁时”。
• “保护目的”亦是旧版本已存在的问题，指的是“保护用户或社群”的标题。改成了“包括但不限于以下情形”，因为重译版前面已经有说明了封禁在什么情况下保护用户和社群。
• ““严重扰乱”包括不适合维基百科文明协作氛围及影响让参与者协作共建百科全书的行为”不写在下面是因为下面的是“不适合维基百科[...]的行为”的例子，而这个是定义。
• “管理员可在发现[...]考虑延长封禁时长。”问题似乎不是很大。re“这段内容全部都应该归到傀儡”，其实应该两边都写（

如发现更多问题欢迎再次提出。--路西法人 2023年3月1日 (三) 07:46 (UTC)

“防止扰乱”：扰乱一词一般特指POINT（即“为阐释观点而扰乱维基百科”），可能会导致误解。不过暂时没想到更好的词。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年3月1日 (三) 10:54 (UTC)

全文所用扰乱是文字上的意思。基础方针得常人看得懂，不应有暗含意义，故扰乱一次不会作POINT的意思（除非全写）。--路西法人 2023年3月1日 (三) 11:02 (UTC)

那您为什么要突然去定义什么是“严重扰乱”呢。而且您这一句也不像是定义，而像是严重扰乱的一些例子。不论什么是“严重扰乱”根本和封禁方针的实行没有关系吧。--Ghren🐦🕘 2023年3月1日 (三) 13:26 (UTC)

“不适合维基百科文明协作氛围及影响让参与者协作共建百科全书的行为”非具体例子，仅是定义何谓“可致封禁的严重扰乱行为”，给了定义再给符合此描述的具体方针例子，怎么没关系了？--路西法人 2023年3月1日 (三) 14:11 (UTC)

您给我的留言感觉就是完全没在读旧版方针和我参照的英语版方针，这个也是旧方针已经存在的内容，我只是在paraphrase一下翻译腔和整理语序，怎么又成了我的问题了？英语版方针原文：A user may be blocked when their conduct severely disrupts the project; that is, when their conduct is inconsistent with a civil, collegial atmosphere and interferes with the process of editors working together harmoniously to create an encyclopedia.--路西法人 2023年3月1日 (三) 14:15 (UTC)

倒是修了个小笔误，“…协作氛围及影响让其他参与者协作…”。--路西法人 2023年3月1日 (三) 14:23 (UTC)

本来想不要把一句没有句读写很长，既然阁下看不懂那改成管理员可因用户作出不适合维基百科文明协作氛围或影响其他参与者协作共建百科全书的扰乱行为而实施封禁。--路西法人 2023年3月1日 (三) 14:34 (UTC)

（1）“其中包括但不限于以下属严重扰乱的行为”里面的“破坏”建议改成“故意破坏”，以减少歧义。（2）“不限期封禁”后面加上“（又称永久封禁）”，因为永久封禁这个词语仍然相当常用。--GZWDer（留言） 2023年3月3日 (五) 10:05 (UTC)

（1）破坏定义已包含故意的意思。（2）加了，并改了一点字眼。--路西法人 2023年3月3日 (五) 10:21 (UTC)

但是有些人认为“破坏”来对应damage，所以这里用“故意破坏”可能会好一些。--GZWDer（留言） 2023年3月3日 (五) 11:57 (UTC)

非建设性编辑如何？--路西法人 2023年3月3日 (五) 12:17 (UTC)

“非建设性编辑”比“故意破坏”要广。--GZWDer（留言） 2023年3月3日 (五) 12:59 (UTC)

加了。--路西法人 2023年3月4日 (六) 01:02 (UTC)

• (！)意见：敝人对路西法阁下所提供之草案全文表达微调意见，恕直接大块呈现：

• 第一部分“首段”提议条文：

“管理员可在接纳用户申诉、认为封禁缺乏适当依据、不再合适等情况下解除对用户的封禁（参见 § 解除封禁）。封禁与禁制有所不同：禁制是褫夺用户在维基百科全站或若干部分之编辑权的正式措施，并不直接阻止用户编辑页面，但禁制也可以通过封禁来执行。”个人认为标明红色的该句具体语意似对一般读者不甚明朗，有兴趣的读者可以直接详阅禁制方针。

• 第二部分“原则”提议条文：

“封禁应当具有遏制效果，以防止维基百科受破坏及扰乱，..........在一般不应以未持续发生且当前已无扰乱风险之事由作追溯式封禁。

被封禁用户可发起封禁申诉（参见 § 解除封禁）。解除封禁的请求同样应以遏制、阻却破坏性编辑和扰乱行为，或尝试引导善意的建设性编辑作为考量。承诺停止不当行为，并能对相关规范展现具诚信之适当理解的用户可能可获解除封禁；同样地，在解除封禁后持续出现相同不当行为的用户，其封禁申诉很可能会被拒绝以作阻吓作用并强调行为不当和改善的必要。”。

• 第三部分“常见的封禁原因”提议条文：

“执行可能显具争议性的封禁时，则应以适当方式（如管理员布告板）通知其他管理员进行复检。管理员应当在对于新用户需多加注意：..........但需注意用户在被充分提醒或警告后持续不当编辑仍可被封禁，此并不代表“不清楚维基百科的规则”可当作开脱责任的借口而用户拒绝或显为不当理解相关规范亦非规避封禁等裁处的理由。”个人认为由于封禁是否具争议性须视情形而定，亦可能因各种用户的主观认知而有所差异，若要有争议总会有争议，难以一概而论；考量管理员本身应已具备之能力和机动性，可选择适当的不同处置作为，达成风险降低或错误修正效果。另微调字面。

• 第四部分“保护用户或社群”提议条文：

“.....包括但不限于以下情形：.....其他可能危害用户安全的行为；..........持续在生者人物条目加入未能以可靠来源佐证，或显可合理查知推定其为虚伪，或已经公开证实为不实陈述之诽谤内容；....”。此项所欲保护者为条目在世主角之生者法益，但是诽谤一词涉事复杂，且各国或地区的法律标准、名目不一，即便可靠来源亦可能对公众人物构成诽谤，又或者负面和争议讯息经可靠来源报导散布亦仍可能涉及诉讼争议，是否诽谤又须经法律认定，因此“未能以可靠来源佐证”或“可能存在诽谤”两种情形在认定时可能出现矛盾，比如“能以可靠来源佐证”却也“可能存在诽谤”，又或者传主主张其为诽谤并诉诸法律，此时又该如何认定？极端而言，若传主大量兴讼，使相关载述事件皆进入法律程序，此时关于事件的公开传述是否“可能存在诽谤”？以上情形，除已超出一般善意用户之通常思虑和负荷能力，亦恐损及平台立意和公众利益，而若无所设限也失去原先规范立意。因此，于此若未明指规限范围，可能易生各种争议，尤以若平台遭不当利用为甚。个人建议直接明指在此规范者为“未经可靠来源传载，或显明可合理查知其具备虚假陈述”之诽谤疑虑者即可。

• 第五部分“防止扰乱”提议条文：“在一般情况下，用户在首次被封禁前会收到数次警告，但执行封禁时仍应当在被封禁用户的对话页提供适当说明或理据以减少争议”。

• 第八部分“绕过封禁”之“代替被封禁用户作出编辑”提议条文：

“任何用户不得代理或代表被封禁用户编辑，除非该等编辑明显有益于维基百科，且代为编辑的用户有合理且独立的原因作出该等编辑。模仿被封禁用户编辑行为的新用户（尤其是仅作此类编辑的用户账号）将可被视为傀儡或真人傀儡，并视具体情事被施以与其所模仿用户同等的适当裁处。”个人认为“方向”一词指涉过广且难以界定，即便换为“编辑内容、行为或倾向”也是相当容易误解；若实务上遇此类“疑似代理”行为，仍须就具体的编辑行为或内容查看其是否为“协助”或“代理”被封禁用户进行编辑。

• 第十一部分“封禁指导”之“教育用户”提议条文：

“所有维基人应尽力在采取封禁措施前优先考虑教育用户遵守方针指引，并在其作出与方针指引精神相违背的编辑时予以提醒或警告。请欢迎且不要伤害其他新手，并假定其有改善维基百科的意图。较有经验的维基人（包括管理员及一般用户）应于发现新手犯错时予以提醒或警告。用户可使用一系列的警告模板用以发送简单的罐头提示，但按情况量身编写的讯息更佳。封禁应为最后的手段，管理员应当在封禁违规的用户前确认有关用户知晓或已获告知相关的规范，并已给予足够时间让其停止不当行为。仅用于明显破坏、人身攻击或规避封禁等被禁止行为的账号不在此限，并可直接封禁。”。

• 第十二部分“解释封禁原因”之提议条文：

“.......因此必须基于可查的证据及合理判断，经详细考虑才执行。所有封禁的理据可在复审者提出要求下清楚提供。

知会用户 管理员必须在执行封禁时具体提供适当明确的理据。封禁理由应避免仅使用内部术语以确保被封禁的用户能理解相关理据。.........

附加信息 执行封禁的管理员可考虑在加入以下信息，以协助复审者查看裁处：......”。“判决”一词似过于正式，且对于站务行权恐生争议。

• 第十三部分“执行封禁”之提议条文：

“釐定封禁期限 .......，因此封禁期限应根据用户是否可能重复不当行为而定。再犯者可被假定可能再次或频繁出现同类扰乱行为，而可被施予较长的封禁，以阻截扰乱及减低维护工作的负担。简而言之.....”。

• 第十四部分“解释封禁原因”（此段重复？）

• 第十五部分“不限期封禁”之提议条文：

“不限期封禁（或称永久封禁）是指无失效时限的封禁，通常用于防止严重扰乱维基百科正常运作的行为，或严重违反维基百科相关适用规范的行为。不限期封禁或适合用以阻止持续的不当行为，但仍需注意同样不应作惩罚之用。不限期封禁并不代表永恒不可变，而仅代表未有订立封禁时长，封禁不会自动过期解除。被不限期封禁的用户在合适的情况下可获解除封禁，并在使其获得社群适当观察警醒的情况下继续编辑，以确保该用户未来不再违反维基百科的不同规范。”。

• 第十六部分“设置封禁选项”之提议条文：

“账号创建......，则应使用此封禁选项。此封禁设置会经自动封禁及IP硬封禁而套用于在受影响的IP地址登录，且未申获IP封禁例外的用户之上。

传送电子邮箱....，则可使用此封禁选项。此封禁设置会经自动封禁及IP硬封禁而套用于在受影响的IP地址登录，且未申获IP封禁例外的用户之上。

编辑自己的讨论页封禁选项会剥夺被封禁用户使用其用户讨论页的权利，此使其无法经用户讨论页进行封禁申诉。此选项在大部分情况下不应使用，仅应而在需组织被封禁用户显为滥用自己的对话页（包括但不限于：对社群进行各种威胁、恫吓、骚扰；试图公开他人个人信息；刻意提供具误导性之虚伪、不实陈述；以及多次重复申诉而无新申诉理据等滥用讨论页情况）下使用此封禁选项。

封禁使用此IP地址的登录用户.....，此选项禁止未申获IP封禁例外的用户账号在被封禁的IP地址及区段上使用被封禁功能，如编辑、创建账户及使用电邮联系功能。”。

• 第十七部分“封禁机器人”之提议条文：

“未经审核批准或豁免审核运行的机器人账号，或用户名因可能被误会为机器人而违反用户名方针的账号，可被即时不限期封禁；若机器人操作者被封禁，.....”。

• 第十八部分“标记用户页”之提议条文：

“若用户因滥用傀儡或被确认为他人的傀儡而被永久封禁，或在被永久封禁后被查出滥用傀儡或被确认为他人的傀儡，请务必以Template:略（对于滥用傀儡的用户）或Template:略（对于傀儡账号），替换原有的用户页内容（如已创建用户页）或创建用户页（如未创建用户页），并对之进行永久全保护；需拒绝承认的情况不在此限。”。

• 第十九部分“解除封禁”之提议条文：

“封禁申诉 作为封禁申诉的一部分，社群可参与申诉讨论，执行封禁的管理员则可能按情况被要求查看、参与申诉讨论，提供更多信息。.........社群并未制定针对同一封禁的申诉次数上限，但持续滥用申诉程序（包括但不限于：对社群进行各种威胁、恫吓、骚扰；试图公开他人个人信息；刻意提供具误导性之虚伪、不实陈述；以及多次重复申诉而无新申诉理据等情况）则可导致管理员禁止用户使用其用户讨论页的权限，但用户仍可通过封禁申诉邮件列表（unblock-zh@lists.wikimedia.org）进行申诉。...........

临时性质的解除封禁......，违反以上条件可处以额外制裁。除非讨论共识推翻原先裁处的封禁，否则讨论结束后应当恢复裁处结果。

有条件解除封禁 管理员具有封禁条件生效时长的决定权，但原釐定封禁期限不超过一年者，其解除封禁条件的釐定时长不得超过一年；原釐定封禁期限超过一年者（包括不限期封禁），其解封条件的釐定时长不得超过三年、解封条件约定之再犯釐定时长不得超过五年。若解除封禁条件方案包含社群观察期，釐定观察期限为三个月起算，不得超过被封禁用户实际获处之解封条件时长。若解除封禁条件方案内含要求显有违被封禁用户参与初衷和能力，或无涉其违规情事或公开申诉内容，或违反公序良俗者，自始无效。.........违反解除封禁条件或再作出可致封禁行为的用户可处重新封禁并被进一步制裁。”。--Kriz Ju（留言） 2023年3月7日 (二) 23:44 (UTC)

感谢Kriz Ju的详细校对。除最后“有条件解除封禁”一段的建议更改有点不够直白（如或违反公序良俗者，自始无效）和稍嫌过于复杂的时间规定，我觉得其他更改意见都相当合理，我已按照您的大部分意见更新方针草案（Special:Diff/76259540），但有以下几点说明：

• 在香港的各种正式条文中比起“遏制”更常用“阻吓”（见吓阻理论的地区词转换），故保留使用-{zh-hk:阻嚇;zh-hant:嚇阻;zh-hans:威慑;}-的用词；
• “裁处”同上，香港似乎完全没用这个词，“处分”应该更多地区使用。

请理解我的选词想法。--路西法人 2023年3月8日 (三) 01:14 (UTC)

重修禁制方针

由于近期有用户在处理持续出没的破坏者时出现误会一事，建议在禁制方针正式引入本地全站范围禁制供社群正式制裁用户剥夺参与本站编辑权利，类同全域禁制的本地版；建议添加该项而不并入不限期封禁是鉴于不限期封禁并不代表禁止编辑，有不当用户名软封禁和机器人出错的封禁等。此外，建议将“编辑禁制方针”更名为“禁制方针”，互动禁制和电邮禁制不是编辑权的一部分而是行为的制裁。--路西法人 2023年3月1日 (三) 03:32 (UTC)

首先中文版和英文版ban的概念不同，英文版的ban是根据社群共识的正式行为（site ban强于indef block），中文版是一种一种比block弱的管理手段（Wikipedia:互助客栈/其他/存档/2019年3月#建议编辑禁制）；此外“根据社群共识所执行的编辑禁制”中文版有显著的反对意见（例如这个场景）。--GZWDer（留言） 2023年3月3日 (五) 03:17 (UTC)

感谢阁下指出过往讨论，我也有研究过，但编辑禁制方针本来就是社群明确反对及后慢慢达成共识而通过的最佳例子。社群讨论过并不代表不能再讨论，且在上次讨论后经历过不少大事，社群的看法很可能有改变的情况。只要讨论制定得宜，过往讨论并不能做为不改变的原因。请阁下容我完成新建议版本的编写再提出更对意见，此仅为占位讨论串，您也可以看到我连条文都还没提出。--路西法人 2023年3月3日 (五) 04:12 (UTC)

过往社群屡次反对社群禁制措施的主要原因之一是担忧制度被滥用打压异见社群，但经历OA2021后社群的环境是显然可见地改善了。

即使是OA2021发生当下，社群内亦没有出现夺权或打压的情况，最终讨论出来也只有有限度制裁措施，试图完全打压整个社群（例如要求正式制裁WMCUG）的提案完全没能通过，最终只是有限度地移除特定链接和挂模板告知OA2021；OA2021后基本上再未出现管理员操控打压特定社群并包庇特定用户的情况。这些证明了：

1. 滥用制度打压异见社群并非源自权限而是源自人的问题，要用“担忧被用作打压异见社群”这点来说那您维连封禁权限都不能有；及
2. 现时中文维基百科各立场社群显然比以前的更平衡和互相制约、更能求同存异，再出现同样程度的集团式操控社群的机会不大。

在社群已经恢复正常的情况下，我觉得现在是适合探讨重整禁制制度的合适时机，但基于过往社群讨论的考量，确实可以在以英维版本作为基础重修的同时制定更能防止集体滥用程序的情况发生。--路西法人 2023年3月3日 (五) 09:22 (UTC)

社群正常也不意味着未来不分裂。甚至可能在Wikipedia:管理员解任投票/Shizhao的时代（约2010-2011年）社群已经出现了拉帮结派问题（虽然和后来的问题不是一回事）。--GZWDer（留言） 2023年3月3日 (五) 10:00 (UTC)

还是那句，功能、程序设计再好也还是可以被人滥用，我们该做的是排除被滥用的机会而非为了不被滥用而不改善。--路西法人 2023年3月3日 (五) 10:03 (UTC)

---

重修禁制方针条文已准备完毕并存于User:LuciferianThomas/项目/重修禁制方针。重修方针概要：

• 方针更名“编辑禁制方针”→“禁制方针”以更广泛包含不属编辑的可被禁制扰乱行为。
• 由于MediaWiki软件已于2019年引入局部封禁，故管理员不再需要通过“禁制”来限制用户在特定页面或命名空间的编辑，但仍给管理员保留针对编辑争议采取局部封禁无法取代的主题、互动禁制及回退限制。
• 正式引入全站范围禁制，默认于绕过封禁的用户及全域锁定用户适用（如持续出没的破坏者等），适合用于拒绝承认的情况。
• 将回退限制（回退不过一、回退零容忍）写入禁制方针。
• 引入社群禁制程序，容许社群在达成广泛共识下实施禁制，但仍需由管理员结案。程序规范较严谨，主要是确保社群广泛知晓有禁制讨论；然后现在大家都知道试图操控社群的后果和向T&S举报方式，如果再发现那种团伙式违背维基百科理念及方针指引而包庇违规者或操控社群的情况那大家都知道该怎么做。社群与其永远活在过去时间的阴影下不如

XX族的名称是否违反中立原则

编辑@JNO1：指出“条目名称中有族的为非中立，会造成误解”，希望创建方针，排除有族名的条目。提出讨论，是否要创建这样的方针。--Alfredo ougaowen（留言） 2023年3月7日 (二) 13:48 (UTC)

我的立场，条目名称以有充份可靠来源的名称为准，其次以先建者为准。如果维基同意他的方针，我也无话可说。--Alfredo ougaowen（留言）

我的立场是条目名称应采用不会产生歧义的命名，且仅限于中国上古时代，我从来没有提出要创建Alfredo ougaowen所谓“排除有族名的条目”的方针，将现代民族的命名排斥“族”是Alfredo ougaowen的主张，很明显是Alfredo ougaowen是在无中生有造谣--康族（留言） 2023年3月7日 (二) 15:22 (UTC)

提议于封禁方针新增应对口吻限制

原标题为：提议于新版中增应对口吻限制

现行条文 无

提议条文 同封禁者沟通 一位维基百科用户封禁与否，不代表其身为维基百科社群用户拥有受尊重权利的丧失，亦不应以仇视或明显轻蔑之语气批判、侮辱该用户。诚然，见到维基百科被破坏或可能的扰乱行为，您或会想“义愤填膺”地批判当事人，但刻薄的批评往往会有激化矛盾的风险。如果您想参与有关此用户封禁事务的讨论，请尽可能以冷静的口吻指出其犯下的过失，或以此给出相应的个人意见或建议。

此外我不建议将封禁与禁制的方针修订一并讨论，这可能会造成排版上的混杂（以及讨论注意力的分散）。我个人建议分为两个不同的讨论串。至于设立上述条文的目的只有两个：以合适的态度应对封禁及违规用户，以及减少任何制造LTA的可能。——WMLO（留言）。 2023年3月6日 (一) 23:21 (UTC)

(－)反对，内容与方针及论述并不尽相符，更有不少用词是相关方针没有的。“不代表其身为维基百科社群用户拥有受尊重权利的丧失”无法链接到用户行为不文明；“刻薄”一词过于广泛，严重程度从“unkind”、“harsh”到“mean”都可以叫做“刻薄”，定义非常广且空泛，前两者并不完全违反文明及礼仪方针，对事不对人的批评往往属于前两者，甚至警告讯息也能被很多人理解为“待人严苛”即“刻薄”的定义，而维基百科运营实务上显然不认同此看法。在不人身攻击、不侮辱人格且对事不对人的情况下，任何批评都不是违反文明方针或礼仪的行为；被封禁者态度差异可以很大，对有礼了解自己错误且愿意承担者有礼、对坚拒承认错误者严厉是天经地义，显然一刀切对所有被封禁用户（包括态度恶劣者）连批判（criticize）都“不应”绝不合理，提案人建议的内容仅仅给其他用户过度诠释文明方针和礼仪指引以拒绝接受合理意见的空间，实务上即使写得多精准也仅仅是在复述其他方针，完全没有必要写在封禁方针内。--路西法人 2023年3月7日 (二) 00:33 (UTC)

对于很可能具有善意但一直觉得自己是对的用户（正如Mosowai一案），你这样的态度就推动了宁可过度客气教他不成就随他被拒绝申诉及继续维持封禁，也不要骂醒他让他真正知道错误的做法，完全无助于解决封禁背后的起因事件。--路西法人 2023年3月7日 (二) 01:05 (UTC)

用词符不符合，并不妨碍此草案援引这类方针及论述背后精神，规则只是原则。而礼仪同文明订立的原则便是避免激化冲突，以造成不和谐的讨论氛围或避免用户将讨论页面当作不满情绪的宣泄口。而刻薄、仇视及轻蔑语句显然属于这类事务。另夹带着事物针对该人本身的，言语激烈批评的程度甚于超脱用户本身的只为发泄自己情绪目的的言语在某些案例中屡见不鲜（在Mosowai一案中含当事人在内有四名用户认为你的用词不妥）。我就是一刀切对所有被封禁用户，包括那些态度恶劣的。我反对的不是批判本身，而是刻薄的批判：第一这没有什么必要，第二用言语骂他通常只有两个结果：放弃自己坚持的自尊在你面前承认错误；被言语激怒后持续与你展开舌战。出于人类的感性惯性有相当一部分人属于后者。而从功利主义的角度来看，与其包裹着方针用激烈刻薄的言语批判他含着激化矛盾甚至制造为报复社群的LTA的行为风险，还不如以另一种口吻与他接触。再退步说，当平常的讲道理都无法说服他时，您用另一类“骂醒”式发言也只是在前者的基础下加点火药味罢了。——WMLO（留言）。 2023年3月7日 (二) 14:30 (UTC)

此外，也请您莫要模糊严厉与刻薄之间的界限转而将其包装成所谓的“合理意见”；我一向认可适当的严厉或直言不讳，比如Nanachi、薏仁将两位就在Mosowai一案中以适当的这类言行指出了他的错误。而您的言行不可否认也有合理的地方，但留言中参杂的情绪甚至于激化了你与他之间的矛盾，有些语句也显然是没有任何必要的：需要我再引用阁下那三句“完全无助于解决封禁背后的起因事件”的文段么？直言不讳地说，我认为阁下的言行和另一位管理员的重刑都是把他逼走的重要一环，这时教育用户的目的达到了么？又是否符合本站的精神？我引用菲茨杰拉德的一句话“当你要批评别人时，你切要记着，不是人人都有你那样的条件。当然，草案细节可以再议。但我认为仍然有必要添加这类条文以限制用户在封禁事务中的言行避免矛盾的激化。—WMLO（留言）。 2023年3月7日 (二) 14:32 (UTC)

能力亦为必须。如果你要说我的留言在该案无助解决封禁起因，那请你再读一下2023年1月该用户首次被封禁前个用户的“礼貌”留言他有没有采纳过，然后封禁解除后又在其他用户说明下是否屡次坚持其扭曲方针的立场而引来我再次回应他。最后警告模板采用的用词是“这是对阁下的最后警告”，无法理解为何封禁后反而“请停止某态度和行为”一句警告、直白指明错误之处、举出反面教材也是“刻薄批判”，甚至经你链接的方针指引在暗示这些是违反礼仪及文明的留言，那我对于阁下非常失望。整个提案跟社群惯常流程完全不衔接，尤其是最后警告后封禁却要对连最后警告都忽略和开始扭曲的人客客气气这一点使我无法理解。--路西法人 2023年3月8日 (三) 01:43 (UTC)

对于LTA，现行方针应该是“不接触、不理会、不承认”。对于封禁用户，应该适用于普通用户的规则，你这句话放到处理普通用户之间冲突那里都没有问题。----Cat on Mars 2023年3月7日 (二) 01:41 (UTC)

• 由于此案与封禁方针重修不相关而不冲突，若此案在封禁方针重修案前通过，新版封禁方针通过并不能覆盖此案所获取共识（如有），故分拆处理。--路西法人 2023年3月8日 (三) 15:47 (UTC)