WP:VPALL

本頁互助客棧 (全部)是供以方便瀏覽所有討論而特別設置。如果您想要新增討論內容，請在互助客棧中選擇最合適的版面。

		歡迎光臨互助客棧！

	互助客栈是維基人議事相助之處，用以討論消息、方针、技术以及编辑、求助等議題。發表議題之前請搜索先前文章，遵守指導及禮儀。任何與維基百科無關的問題，请前往知识问答。
消息	方针	技术	求助	條目探討	其他
討論維基相關新聞與消息	討論方針與草案	解決或報告技術疑難	解決在維基百科中所遇疑難	條目、模板、主題相關探討	未符任何分區之議題
发表 \| 监视	发表 \| 监视	发表 \| 监视	发表 \| 监视	发表 \| 监视	发表 \| 监视
查看全部討論
帮助目录 · 提出疑问 · wikitext基础 · 常见问题 · 常见错误 · 布告板 · 了解术语 · 即时协助 · 規則简述 · 使用指南

维基百科社群事务討論方针提案其他提案协作讨论提问条目探讨請求专题维护部门目录帮助规则社群媒體 Discord IRC QQ Telegram Line 互联群即時聯繫維基人聚会

If you don't use Chinese, and want to contact Chinese Wikipedia, please leave your message here.

存檔

2005年12月以前的互助客栈存档
2005年12月以前的聊天室存档
2005年12月以后的存档：
消息 · 方针 · 技术 · 求助 · 条目探讨 · 其他

我想要……	请前往……
如何有效並安全地访问维基百科的方法	如何访问维基百科
与繁简处理有关的问题	字词转换
協助或尋求條目的改善意见	同行评审
对某些特定来源的讨论	可靠来源布告栏
寻找参考文献	文献传递
參與即時讨论或通过电子邮件进行讨论	「即時討論」或者「邮件列表」

消息

薇妮
虚构设定信息
物種	人鱗蛇
性別	女性
出生	地牢中層
所屬	赫斯提亞家族

Books & Bytes – Issue 55

The Wikipedia Library: Books & Bytes
Issue 55, January – February 2023

New bundle partners:
- Newspapers.com
- Fold3
1Lib1Ref January report
Spotlight: EDS SmartText Searching

Read the full newsletter

Sent by MediaWiki message delivery on behalf of The Wikipedia Library team --2023年3月16日 (四) 12:46 (UTC) —以上未加入日期時間的留言是于2023年3月16日 (四) 16:14 (UTC)之前加入的。回复[回复]

The Signpost: 20 March 2023

News, reports and features from the English Wikipedia's newspaper

News and notes: Wikimania submissions deadline looms, Russian government after our lucky charms, AI woes nix CNET from RS slate

Eyewitness: Three more stories from Ukrainian Wikimedians

In the media: Paid editing, plagiarism payouts, proponents of a ploy, and people peeved at perceived preferences

Featured content: Way too many featured articles

Interview: 228/2/1: the inside scoop on Aoidh's RfA

Traffic report: Who died? Who won? Who lost?

Read this Signpost in full · Single-page · Unsubscribe · Global message delivery 2023年3月20日 (一) 11:19 (UTC)

Wikidata weekly summary #564

Here's your quick overview of what has been happening around Wikidata over the last week.

Events
- Upcoming: WikiCite Monthly Meeting, online on 28 March 2023 at 16:00 UTC. Information and notes

Press, articles, blog posts, videos
- Blogs
  - In this week's update by the Abstract Wikipedia and Wikifunctions team, they are asking where the right place to store and maintain Abstract Wikipedia should be. All of the options involve Wikidata to some extent, some more, some less. If the content of Abstract Wikipedia is hosted on Wikidata, that would lead to an increased scope for the Wikidata community (and likely more contributors joining). But that is a decision the Wikidata community needs to be involved in as well. (Also, if you are interested, the Abstract Wikipedia updates might be worth to follow.)
- Papers
  - Investigating the potential of the semantic web for education: Exploring Wikidata as a learning platform
- Videos
- Notebooks
  - Country diversity of external links domain names in Wikipedia in French an analysis of all domain names in Wikipedia in French by country associated to the website.

Tool of the week
- User:BrokenSegue/shorten.js makes statements boxes for a particular property scrollable if it is too tall.

Other Noteworthy Stuff
- A new Wikidata Query Service scaling update has been published. It outlines the WDQS current state and summarizes the suggestions with the most impact we’re exploring now, with a few in-progress.

Did you know?
- Newest properties:
  - General datatypes: none
  - External identifiers: STS program ID, Electronic library encyclopedia.com.ua, Deutsche Synchronkartei person ID, A Dictionary of South African English on Historical Principles entry ID, Syoboi Calendar series ID, Malaysia Federal Legislation act ID, Moscow University Herbarium ID, Digital Daijisen ID (goo dictionary), Pakistan Sign Language Dictionary ID, IRIS UNICAMPUS author ID, IRIS UNIECAMPUS author ID, IRISanRaf author ID, Epigraphik-Datenbank Clauss / Slaby ID, NTV program ID, Faber Music music ID, Faber Music composer ID, Boosey & Hawkes music ID, Wise Music Classical work ID, IATE ID, Jewish English Lexicon ID, Wise Music Classical composer ID, Rate Your Music work ID, Norwegian Petroleum Directorate field ID, Epson Tour player ID, Digital Bhashakosha page number, PlaymakerStats.com competition ID, Electrodoc person ID, Archivarta ID, CassiOpeA author ID, IRIS UNIROMA2 author ID, IRIS UNIROMA3 author ID, Sjøhistorie ship ID, electrocd artist ID, köztérkép ID, ForPost person ID, Crimean virtual necropolis persons ID, eTK ID, eVK2 ID, Ivi title ID, Ivi person ID, Saint Petersburg Conservatory person ID, Hungarian National Namespace organisation ID (new)
- New property proposals to review:
  - General datatypes:
    - system requirements (system requirements for video game or software)
  - External identifiers: Brazzers ID, Universo del corpo ID, Zeneszöveg.hu international artist ID, Tekstowo.pl artist ID, Tekściory artist ID, Merchbar electronic dance music artist ID, BSDB player ID, The Athletic team ID, The Athletic player ID, GSAFD ID, Feminae ID, IFTTT service ID, stock keeping unit, Federiciana ID, LIBRA Unine ID
- Query examples:
  - Lexeme with a Sense related to a geolocated Item (source)
  - Highest TV seasons numbers (source)

Development
- EntitySchemas: We are preparing for adding a new datatype and other changes by improving tests, documentation, etc.
- Date input: We did a bug triage hour around issues with date parsing and improved it for Japanese dates (phab:T214002)
- Ontology issues: We started evaluating the survey responses for the survey about different types of ontology issues reusers are facing. More work is needed before we have results.
- REST API: We finished work on including the URL of an article in sitelink data (phab:T330252) as well as providing all aliases of an Item (phab:T327882)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Monthly Tasks
- Add labels, in your own language(s), for the new properties listed above.
- Comment on property proposals: all open proposals
- Suggested and open tasks!
- Contribute to a Showcase item.
- Help translate or proofread the interface and documentation pages, in your own language!
- Help merge identical items across Wikimedia projects.
- Help write the next summary!

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 2023年3月20日 (一) 16:55 (UTC)回复[回复]

Anti Vandalism (patroller) tool for Wikipedia Android App

本主題或以下段落文字，移動自Wikipedia talk:管理员布告板。执行者：东风（留言） 2023年3月22日 (三) 07:12 (UTC)。回复[回复]

"Apologies if this isn't in your native language, please help translate"

Hello, This is Amal Ramadan, Sr. community relations specialist supporting the apps team.

The Android team has heard many requests from the community to have ways to ensure that the edits made in the apps are of good quality. With the team's recent release of a native watchlist, contribution history, and edit history, as well as the addition of the undo and rollback button on the diff screen, there is an opportunity to create a moderating solution in the app. We would like to do this in partnership with the community.

We would like to invite you to test the first iteration of the patrolling tool designs. Your input at this stage will allow us to improve the tool before development as well as gather important feedback for the second iteration of the tool.

If you are interested in joining, please reply to this post or send me a message.

ARamadan-WMF（留言） 2023年3月22日 (三) 06:29 (UTC)--东风（留言） 2023年3月22日 (三) 07:12 (UTC)回复[回复]

維基媒體基金會理事會已批准《通用行為準則》執行規範

您可以在元維基上找到這則訊息其他語言的翻譯。

更多语言 • 请帮助翻译至您的语言

這是關於《通用行為準則》執行規範的重要更新：大多數人在2023年1月對《通用行為準則》執行規範的投票中表明贊成《通用行為準則》執行規範。這次投票共收到369條評論，我們近期將公佈評論的詳細摘要。一共有3097名選民參與投票，76%的人贊成當前版本的《通用行為準則》執行規範。您可以在元維基上查看投票統計。

隨著選民對《通用行為準則》執行規範的支持增加，這向維基媒體基金會理事會表明當前的版本已經解決了上一次在2022年審查期間指出的一些問題。維基媒體基金會理事會投票批准了《通用行為準則》執行規範。該決議可以在維基媒體基金會維基頁面上找到，您也可以在Diff上閱讀更多關於2023 年《通用行為準則》執行規範審查背後的過程。

根據《通用行為準則》執行規範提供的重要建議，我們需要採取一些後續步驟。有關時間表的更多詳細信息即將公佈。謝謝您的關注和參與。

謹代表《通用行為準則》項目團隊，

VChang (WMF) 2023年3月24日 (五) 14:18 (UTC)回复[回复]

方針

整理引导新手的相关页面

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:參與貢獻、Wikipedia talk:新手入門、Help talk:簡介、Wikipedia talk:新手上路、Wikipedia talk:第一印象、Help talk:從這裡開始、Wikipedia talk:新手簡明指南、Wikipedia talk:線上訓練、Wikipedia talk:維基百科大歷險、WikiProject talk:維基百科發展/新手2023。

目前用以帮助新人的页面实在庞杂。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：你是指怎樣安裝小工具的教程還是怎樣使用小工具的教程？（雖然我感覺兩個教程都能編製一下就是了）San mo sa _{Συ γάρ μοι και μοίρα εί και τύχη} 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)回复[回复]

最近試用2017版，有沒有加入重定向的快捷鍵?--Temp3600（留言） 2023年3月18日 (六) 10:01 (UTC)回复[回复]

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

这块应该申请已经较为便利了，重点应该在怎么编辑（看懂Wikitext、使用Wikitext之类的）--Eve sie sta_{COVID-19感染中} 2023年3月11日 (六) 02:36 (UTC)回复[回复]

@Kethyga：这不写个The Signpost，亦或是已经有人写过了。--ときさきくるみ 2023年3月21日 (二) 16:08 (UTC)回复[回复]

關注度指引改名事宜

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

為整合有關主題的討論，本討論已移動至Wikipedia:集中討論/關注度指引改名事宜 § 第一階段討論區進行集中討論。請至有關頁面發表意見。

執行人：路西法人 2023年1月20日 (五) 08:10 (UTC)回复[回复]

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

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:機械人方針、Wikipedia talk:翻譯指引。

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

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

可行的方案：

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

连接号一字线的符号选择

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手册/标点符号。

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

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

总结起来：

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

因此建议推荐使用 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)回复[回复]

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

综上反对提案。--。->>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)回复[回复]

如果现在版本macos依然在em dash后面贸然加这么“长空格”的话，我不排除主动联系苹果官方解决该问题，话说这问题该怎么报告？--Liuxinyu970226（留言） 2023年3月21日 (二) 04:22 (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）在简体中文下是破折号的一半，输入起来很方便。

在大陆，中华人民共和国国家标准规定了一字线的符号（[3]），看起来有点像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)回复[回复]

en dash未在《重訂標點符號手冊》修訂版--連接號中出现。em dash同时切合海峡两岸的规范，《重訂標點符號手冊》称为甲式連接號，GB/T 15834—2011称为一字线。--Lt2818（留言） 2023年3月12日 (日) 04:42 (UTC)回复[回复]

公示7日。--Lt2818（留言） 2023年3月12日 (日) 04:42 (UTC)回复[回复]

我取消了提案中对“中华人民共和国国家标准及中華民國教育部標準中”字样的删除。提案人未解释删除原因，且【浪纹线“～”可与一字线通用】的陈述不见得在标准外普遍适用。--Lt2818（留言） 2023年3月12日 (日) 05:14 (UTC)回复[回复]

針對目前「－」廣泛使用之情況，應該要有些許過渡規定。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月12日 (日) 09:04 (UTC)回复[回复]

我觉得既然「往者不可谏，来者犹可追」，是否应该设立过滤器处理来者的问题。----Cat on Mars 2023年3月12日 (日) 12:02 (UTC)回复[回复]

過渡需要改模板（如Template:Bd）、移动页面（机器人或JavaScript可以完成）等，应该无需多数用户参与。设立过滤器我认为不必，易带来叨扰和沮丧感，弊大于利。用户习惯可以慢慢改。--Lt2818（留言） 2023年3月13日 (一) 13:03 (UTC)回复[回复]

我建議在公示期間，一併整理需要進行之善後措施。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月13日 (一) 14:00 (UTC)回复[回复]

我对一字线与破折号形式之间的关系说明做了微调。--InstantNull（留言） 2023年3月19日 (日) 08:40 (UTC)回复[回复]

又是什麼鬼提案？顯然這個獨裁社群完全沒人考慮過比如Wikipedia:典范条目/列表、Wikipedia:特色列表/列表和Wikipedia:优良条目/列表運用在首頁的問題，然後就在公示了？講真的實在很不想說，但如果說了是不是跟沒說一樣硬是要強行通過？似乎仍舊沒有進步。─都早用習慣了，如果通過，是要全部替換嗎？看著辦吧，如果此提案過了，以後只會更少人願意寫維基百科，因為連個編輯方式都在管東管西的，完全失去所謂的維基百科本質：「自由的百科全書」。--Z7504非常建議必要時多關注評選（留言） 2023年3月12日 (日) 16:48 (UTC)回复[回复]
首先我建议这位编辑 stop crying. 您这样将您不喜欢的提案怪罪于社群无助于解决任何问题。本提案自提出已有一月有余，大部分编辑表示支持，对部分异议我也做出了解释和调整。且有关议题在过去几年已经多次做了充分讨论，过往的意见也多数表示支持。整个过程公开透明，哪里“独裁”？何来“强行通过”？您有反对意见可以提出，社群欢迎建设性讨论，但哭闹不会使您的观点更具有说服力，错误的习惯也仍然是错误。--InstantNull（留言） 2023年3月13日 (一) 04:53 (UTC)回复[回复]
就別在那邊自欺欺人了吧。獨裁就是獨裁，還說沒有說服力？這個可悲的獨裁社群意思就是說現在要把─全部強制換成U+2014嗎？到底是誰才沒邏輯啊？可悲獨裁社群，既然要通過提案就過啊，反正說了真的跟沒說一樣，只愛強行通過的獨裁社群。哪還需要公示？公示真的只是形式而已。也不會有人每天會願意為了這一槓吵，但是此種作法只會減少編輯者意願。啊本來維基百科就已經對新手很不友好了，再過這種鬼提案以後真的沒人要寫維基百科了。以後的新條目也會很難寫出來，因為都被前面的人寫完了，以前也講過很多次了。請問維基百科哪裡還稱得上是「別傷害新手」之說？而且維基百科還有多種條目是以比如「A國─B國關係」命名的，要不要全部條目名稱都改為「A國U+2014B國關係」？如果不要改，那就最好全部重定向處理。這提案當然是鬼提案啊。--Z7504非常建議必要時多關注評選（留言） 2023年3月13日 (一) 11:25 (UTC)回复[回复]

Wikipedia:典范条目/列表等三个页面中的U+FF0D不是连接号用例，自然不受影响。─（U+2500）与本提案没有关联。维基百科的自由体现在多个方面，但格式并非其一。--Lt2818（留言） 2023年3月13日 (一) 13:03 (UTC)回复[回复]
并非格式不能自由，而是既然我们已经在格式方面达成共识了，并且格式手册长期以来就有一致性的格式要求，那么大家应该遵守共识，维护共识，积极创造条件以更好维护原本的共识，共识才是约束的条件。----Cat on Mars 2023年3月13日 (一) 16:12 (UTC)回复[回复]
那請問像是「{{lang-en}}」是要強迫用戶都改成使用「{{langU+2014en}}」才甘願嗎？這種鬼提案到底是誰想的也不動動腦筋，想當然只好(－)強烈反对啊。難道還要舉例嗎？獨裁的爛社群。--Z7504非常建議必要時多關注評選（留言） 2023年3月18日 (六) 10:39 (UTC)回复[回复]
？？？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月19日 (日) 05:22 (UTC)回复[回复]
當否人的言論蠢到你懷疑是不是反串。你該不會認為「-{}-」和「」也要改吧？ --窝法乙烷儿法梦碎 2023年3月19日 (日) 14:11 (UTC)回复[回复]
獨裁社群果不其然硬是通過討論，而且已經明確指出問題了還只會裝傻。像這種公示7天只是意思意思走形式流程的獨裁社群，以後寫維基百科的人只會越來越少，因為這嚴重剝奪了編輯者的權益。--Z7504非常建議必要時多關注評選（留言） 2023年3月19日 (日) 16:33 (UTC)回复[回复]
？这是问题？模板的-和连接号有关系？--在下荷花，请多指教（欢迎签到） 2023年3月20日 (一) 02:10 (UTC)回复[回复]

你可能根本没有阅读提案和如上讨论。提案要把U+FF0D改用U+2014，U+2500与本提案毫无关系；提案说的是“一字线”，与短横线en dash也没有关系。你的疑问都有人答复，善后工作也正在展开，装傻好像只有你一人。--PexEric 💬|📝 2023年3月21日 (二) 00:02 (UTC)回复[回复]

格式手册已修改。--Lt2818（留言） 2023年3月19日 (日) 13:49 (UTC)回复[回复]

需要進行之善後措施

应Eric Liu君建议，在此整理需要進行之善後措施。我先列出移动页面的部分，用机器人或JavaScript完成比较适合。

U+FF0D作为连接号出现在大量标题中，这些需要移动到U+2014（em dash）的名称。移动应留重定向，以避免破坏内外链接。根据页面性质及行动方式的不同，我分了三个类别，下面的链接是用Quarry查询得到的页面列表：

受影响条目、主题——维基百科内容页面，移动无需附随其他操作。
受影响分类——维基百科内容页面，移动需附随分类内页面修改，或对应模板/模块修改。
受影响项目页——非内容页面，移动紧迫性不高。

移动完成后，模板内指向被移动页面的链接会被重定向，这是个小问题。

--Lt2818（留言） 2023年3月13日 (一) 15:29 (UTC)回复[回复]

模板部分似乎亦單獨列出為宜？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月14日 (二) 06:18 (UTC)回复[回复]

模板内U+FF0D内链--Lt2818（留言） 2023年3月14日 (二) 13:33 (UTC)回复[回复]

（我的意思是模板標題）—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月20日 (一) 01:30 (UTC)回复[回复]

上方“受影响项目页”链接中命名空间编号为10的就是模板。（似乎单独列出的必要性不大？）--Lt2818（留言） 2023年3月20日 (一) 13:36 (UTC)回复[回复]

U+2500影响的页面也有40个，可一并处理。--PexEric 💬|📝 2023年3月19日 (日) 10:53 (UTC)回复[回复]

還有沒有其他類似的符號？可以考慮一併列出。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月20日 (一) 01:30 (UTC)回复[回复]

连接号#相關符号和破折号#電腦應用已经列的很详细了，加上制表符里的U+2500，还有汉字“一”^{[開玩笑的]}。--PexEric 💬|📝 2023年3月20日 (一) 14:31 (UTC)回复[回复]

(～)補充：还有连字号#字元編碼，以及U+2212的减号。看了一下，quarry:query/72451，只有几个重定向把减号当作连接号，处理紧迫性不高。--PexEric 💬|📝 2023年3月20日 (一) 14:46 (UTC)回复[回复]

发现其中有不少页面应该是用短横线的。建议不要用机器人全自动移动，而是在判断正确的符号后再行处理。

个人体会：中文中的连接号不一定和英文对应。英文同样是en dash，中文可以是短横线（比尔-朗伯定律，格式手册中的例子）或一字线（伏爾加—波羅的海水路，表起止）。--Lt2818（留言） 2023年3月20日 (一) 13:36 (UTC)回复[回复]

机器人可以只批量修正U+FF0D到U+2014（em dash），U+002D（en dash）本来就不用管；U+2500是制表符，用作页面名是错误用例。--PexEric 💬|📝 2023年3月20日 (一) 14:22 (UTC)回复[回复]

我的意思是，许多现有的U+FF0D标题应换用短横线“-”（U+002D），批量改为em dash“—”（U+2014）未必合宜。我昨天移动的丹寧-藤川彗星就是个例子。--Lt2818（留言） 2023年3月20日 (一) 15:15 (UTC)回复[回复]

可以考慮匯入站內頁面，手動清查，由機器人更新剩餘清單；並可以考慮另設排程移動頁面，就是把頁面放到那裡去機器人就會幫忙移動之類的。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月21日 (二) 10:22 (UTC)回复[回复]

个人以为，西班牙语人名的条目会受到这个震撼弹决定影响，是否通知WikiProject:西班牙、WikiProject:墨西哥、WikiProject:秘鲁、WikiProject:古巴等？--Liuxinyu970226（留言） 2023年3月21日 (二) 04:13 (UTC)回复[回复]
人名應用「-」且現有多數條目已如此，不會受影響。--紺野夢人 2023年3月21日 (二) 07:41 (UTC)回复[回复]

重修封鎖方針及禁制方針

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:封锁方针、Wikipedia talk:編輯禁制方針。

重修封鎖方針

細讀本站封鎖方針發現極嚴重翻譯腔及歐化漢語問題，且遺漏關於多項實際有執行但沒寫在方針內的資訊（例如封鎖開放代理）或需要但不存在明確指引的資訊（如解除封鎖相關指導），故建議完全重修封鎖方針以改善以上情況。重修方針草稿置於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)回复[回复]

"以下列出部分被認為需要對帳戶作出封禁的行為"比新的一句好。輕微的擾亂，如果不斷重犯也可能被封。另外蓄意觸發過濾器有什麼問題?--Temp3600（留言） 2023年3月16日 (四) 14:45 (UTC)回复[回复]

蓄意觸發過濾器是指撞過濾器找漏洞。「以下列出部分被認為需要對帳戶作出封鎖的行為」感覺每段都能用，所以避開了。我大可直接移除嚴重兩字，不過晚點再弄。--路西法人 2023年3月17日 (五) 01:45 (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)回复[回复]

原意見補充說明（恕直接借了套用）

(！)意見：關於「有條件解除封鎖」的構想，敝人純粹補充說明如下：以「嚇阻破壞」兼具「導引行為」作為宗旨，在管理員封禁用戶後，若能有措施引導用戶重回社群甚而持續貢獻，對於管理員（封禁發揮實質效果，而非一封了事）、有心用戶（了解問題所在、重返社群並持續獲得樂趣）、社群（未失去可能的貢獻用戶、改善風氣（會否反而失去樂趣（笑）？））以及平台（社群規範得以發揚、社群發展得以良性循環、平台獲得貢獻）而言，將可能達成多贏局面。

管理員使用「有條件緩封禁」方案時，通常或許是用於「較活躍用戶」裁定較長時間封禁的情形，內含要素說明如下：

A.原釐定封鎖期限：管理員封禁時設定的封禁時間長度。
B.解封條件的釐定時長：被封禁用戶獲得解封後，裁以各項代替原封禁的「禁制」處分之時間長度。
C.解封條件約定之再犯釐定時長：管理員與被封禁用戶溝通協商時，約定的解封方案中，可提出若用戶再犯，將受何種裁處，處分中自然很可能包含封禁或各種禁制；若用戶在「社群觀察期」中，再違反相同規範將獲裁處的時間長度。
D.社群觀察期：用戶獲得解封後，持續活動時，屬於「解封約定的觀察改善期間」。
E.解除封鎖條件方案內含要求：用戶獲得解封後，持續活動時，所履行的解封條件，包含各種調整、承諾、貢獻、改善等。
F.時間釐定長度：

關於「釐定封鎖期限不超過一年者，其解除封鎖條件的釐定時長不得超過一年」：原封禁時間若僅數個月甚至更短，個人認為替代的禁制時長衡酌後，亦不應超過一年，一樣一年內（比如：原封禁 3 個月、改處ＸＸ禁制 4 個月；原封禁 2 週、改處ＸＸ禁制 1 個月）；個人認為應比原封禁時間略長，畢竟用戶已獲解封，部分禁制時間應較原封禁處分略長，用戶仍可於平台活動，處分實已減輕。
關於「釐定封鎖期限超過一年者（包括不限期封鎖），其解封條件的釐定時長不得超過三年」：原封禁時間若超過 1 年（比如 1 年又 1 小時），個人認為替代的禁制時長衡酌後，大概最多 3 年；一個處分 3 年，已經可以經過一個人的學生時期階段了；而不限期封鎖亦同，既然管理員願意先解封，用戶也同意 3 年的裁處，繼續使用這個帳號參與，時間再拉長，個人認為實質效益不大。
關於「解封條件約定之再犯釐定時長不得超過五年」：管理員與被封禁用戶溝通協商時，約定的解封方案中，可包含上方提及的「社群觀察期」（D），此時通常會同時提出「解封條件約定之再犯釐定時長」（C）；此兩者必須同時並存，否則不成立。換言之，必有觀察期、才會開出再犯的處分，兩者不可單獨存在，否則難以衡量、無意義、不合理，故不成立（比如：只有（D），然後呢？期間再犯又如何？又或者只有（C），單次處分後的觀察時間無限延長、處分約定永遠跟隨該用戶，個人認為比例過頭，且對該用戶可能造成永久汙名化，此種彷彿強制性的「社會信用標籤」作法，對於用戶的參與和平台應維護的現代精神，敝人認為不妥適（更何況已有封禁日誌、貢獻報告等諸多可查記錄，若用戶再犯另行處分即可；當然社群是否信任該用戶又是一回事）。「（C）+（D）」形成一個「緩封禁期間再犯的處分約定」，之後若用戶再犯，或可減少爭議。而一個處分 5 年，已經可以經過一個人的相當人生階段了，事實上個人不認為會有多少人受此時長的封禁後，仍願意苦苦守著這個帳號（笑），因此已經幾乎很接近永久封禁的狀態，時間再拉長似無實質效益。若真的再有嚴重違規，直接永久封禁即可。
關於「社群觀察期，釐定觀察期限為三個月起算，不得超過被封鎖使用者實際獲處之解封條件時長」：也就是觀察期至少 3 個月起算，不會更少，可以加長，但不論多長，不可超過「解封條件的釐定時長」（B）（比如：代替原封禁的解封條件是改處ＸＸ禁制 4 個月（B），結果觀察期 3 年，顯為失當；又或者（B）是 6 個月，觀察期 2 年，也太長；如果是（B）是 10 個月，觀察期 3 個月，又或是 6、7、8、9 個月，皆可）。為何呢？

個人認為用戶實際受到的替代處分也代表其違規情事之嚴重性，以及阻止其持續違規所裁量賦予的「阻卻時長」，敝人認為「觀察期」應短於違規用戶實際獲處生效的「阻卻時長」，除了代表社群對於違規用戶在觀察期過後賦予的一種「善意信任」之外，也標誌著用戶在實際獲處時長的剩餘時間裡，一方面需要自行注意、自我約束，二方面也代表在社群觀察期過後，「（C）+（D）」已不存在，此時違規用戶的行為、心理或客觀事實，已不存在對於原先「解除封鎖條件方案」所帶來的任何進一步或額外的壓迫、嚇阻、威懾、承諾、威迫等影響；換言之，違規用戶在觀察期過後的行為表現，或可假定為「真實自由的行為表現」，因此該用戶之後是否遵循或違反規定，已很接近其「自由意志」下的行為表現，端看其自行選擇，亦難謂受到什麼不當影響，也才能發揮對其自我約束之期許。再者，竊以為也正好作為其逐步重獲於本站之完整用戶權利、各方面行為和心理的「認知緩衝期」。反過來說，（D）設定的時間長度，也代表管理員留下多少「禁制期結束前的緩衝期」給違規用戶，這也是管理員行權的考量空間。

關於「若解除封鎖條件方案內含要求顯有違被封鎖使用者參與初衷和能力，或無涉其違規情事或公開申訴內容，或違反維基百科:維基百科不是什麼等本站宗旨和規範者，自始無效。」：條文略作異動。此部分來自「解除封鎖條件方案內含要求」（E），當然不得違反用戶參與的初衷、條件、能力（比如對方偏好寫條目，卻要求去反破壞；對方偏好維護條目，卻要求創建條目；對方擅長技術工程，卻要求明確擴編改寫條目；對方完全不懂技術，卻要求去寫代碼；對方完全不懂特定外文，卻要求去翻譯合宜可讀的特定外文條目等）。這當中所謂「本站精神」，最為顯著的一點就是「不強迫任何人參與」，因此任何條件皆不得超出本站內容範圍（比如：繳交罰金或捐獻、上傳自拍（別人的也不行）、提供任何個人資訊（別人的看情形（誤））、支援或參與站外活動、自行生出優良或典範條目、想辦法拿到站內榮譽、選上管理員、想辦法去推廣本站、翻譯 28 篇條目、上傳 500 張攝影作品......等任何額外報酬或勞務，或比例顯然失當的編輯類型和要求）；因此，當解封的協商條件違反平台精神和違背用戶個人意願時，自然無效，而用戶的參與意願為首要考量。

最後，此部分內容會否反倒促使管理員濫權呢？社群可監督、違規用戶可申訴、亦可不同意任何條件，管理員自不宜濫開條件，亦不可為了逼迫他人貢獻、投入、「導正」而「強迫勞動」，這也考驗管理員的行權手法（不然直接維持封禁即可）。

個人意見，純補充供參。--Kriz Ju（留言） 2023年3月9日 (四) 21:03 (UTC)回复[回复]

感謝Kriz Ju君解釋您在「有條件解除封鎖」一段的建議條文。有條件解除封鎖乃是完全原封不動引入自英文維基百科的en:WP:CONDUNBLOCK，但在考量後我還是覺得您的建議增修不適合採用：

原釐定封鎖期限超過一年者（包括不限期封鎖），其解封條件的釐定時長不得超過三年、解封條件約定之再犯釐定時長不得超過五年：有條件解除封鎖包括改為不限期局部封鎖或禁制取代不限期封鎖，但此建議修改條款阻礙了此類下修措施。
若解除封鎖條件方案內含要求顯有違被封鎖用戶參與初衷和能力，或無涉其違規情事或公開申訴內容，或違反維基百科:維基百科不是什麼等本站宗旨和規範者，自始無效。解除封鎖條件是一種禁制措施，解除封鎖條件不能要求用戶做什麼，只能要求用戶不可以做什麼，似乎沒必要寫進去。管理員使用此功能來要求用戶做什麼的話，相信社群也不可能會接受。

--路西法人 2023年3月10日 (五) 07:26 (UTC)回复[回复]

[4]。改了一下。--Ghren 🐦🕖 2023年3月10日 (五) 11:29 (UTC)回复[回复]

我稍後參考來改善一下。--路西法人 2023年3月11日 (六) 02:30 (UTC)回复[回复]

Special:Diff/76320848。--路西法人 2023年3月12日 (日) 04:21 (UTC)回复[回复]

在回退被封禁用戶編輯上，修正錯字及移除破壞的編輯等都應該保留，比改版的可被保留要強。舊版明顯不鼓勵機械人全面回退被封禁用戶的編輯。--Temp3600（留言） 2023年3月16日 (四) 15:07 (UTC)回复[回复]
這是有意為之。閣下需注意那不是指任何被封鎖用戶而是被封鎖用戶繞過封鎖使用其他帳號或IP作出的編輯。實務上，應對一些破壞性編輯遠多於建設性編輯的LTA時，幾十甚至幾百則編輯難以一一檢查，批量回退對於反破壞而言更具效益。我主張的是除了LTA刪除明顯違反BLP內容等編輯應毫無疑問地保留外，容許回退員批量回退後，任何用戶仍可以個人身分再次移除破壞及修正錯字的編輯。從應該保留（不能回退）變成可被保留（可被回退也可再恢復）就是在反破壞及保留善意編輯的平衡。--路西法人 2023年3月17日 (五) 01:11 (UTC)回复[回复]
封鎖->封禁?

這是要整個方針更名?--Temp3600（留言） 2023年3月16日 (四) 15:02 (UTC)回复[回复]

否，純粹是我開頁面的時候的用語習慣。字詞轉換有「簡體：封禁；繁體：封鎖」的規則，所以不需移動方針頁面；內文被重新翻譯的部分的原始碼都用了我的習慣地區用詞「封鎖」（除非是複製貼上），但有字詞轉換所以不影響簡體顯示「封禁」；有些章節標題我改了繁簡是避免出現整個標題都是繁體但卻用了「封禁」，為了連結的便利就改成了繁體的「封鎖」。--路西法人 2023年3月17日 (五) 01:00 (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後基本上再未出現管理員操控打壓特定社群並包庇特定用戶的情況。這些證明了：

濫用制度打壓異見社群並非源自權限而是源自人的問題，要用「擔憂被用作打壓異見社群」這點來說那您維連封鎖權限都不能有；及
現時中文維基百科各立場社群顯然比以前的更平衡和互相制約、更能求同存異，再出現同樣程度的集團式操控社群的機會不大。

在社群已經恢復正常的情況下，我覺得現在是適合探討重整禁制制度的合適時機，但基於過往社群討論的考量，確實可以在以英維版本作為基礎重修的同時制定更能防止集體濫用程序的情況發生。--路西法人 2023年3月3日 (五) 09:22 (UTC)回复[回复]

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

還是那句，功能、程序設計再好也還是可以被人濫用，我們該做的是排除被濫用的機會而非為了不被濫用而不改善。--路西法人 2023年3月3日 (五) 10:03 (UTC)回复[回复]

基於個人遭遇及部分同好之遭遇兼後續等多方實例，個人不能苟同路西法閣下的兩個分項結論，制度被濫用之情況函待繼續跟進，實際情況仍可能需要更多審慎和深入的研判商定，所以，應當對大幅修訂之過程進行更為嚴格和負責的分拆和分項檢視，並保證每一項都可以包括日落條款或保險機制等必要制衡其效力之元素，確保所謂改善過程是真正改善到社區及社羣體驗。--約克客（留言） 2023年3月13日 (一) 02:46 (UTC)回复[回复]

重修禁制方針條文已準備完畢並存於User:LuciferianThomas/專案/重修禁制方針。重修方針概要：

方針更名「編輯禁制方針」→「禁制方針」以更廣泛包含不屬編輯的可被禁制擾亂行為。
由於MediaWiki軟件已於2019年引入局部封鎖，故管理員不再需要通過「禁制」來限制用戶在特定頁面或命名空間的編輯，但仍給管理員保留針對編輯爭議採取局部封鎖無法取代的主題、互動禁制及回退限制。
正式引入全站範圍禁制，預設於繞過封鎖的用戶及全域鎖定用戶適用（如持續出沒的破壞者等），適合用於拒絕承認的情況。
將回退限制（回退不過一、回退零容忍）寫入禁制方針。
引入社群禁制程序，容許社群在達成廣泛共識下實施禁制，但仍需由管理員結案。程序規範較嚴謹，主要是確保社群廣泛知曉有禁制討論；然後現在大家都知道試圖操控社群的後果和向T&S檢舉方式，如果再發現那種團伙式違背維基百科理念及方針指引而包庇違規者或操控社群的情況那大家都知道該怎麽做。
- 此部分保留空間給無法設立ArbCom的中文社群通過全站共識達成ArbCom的管轄權效果。

社群與其永遠活在過去的陰影下，不如嘗試在現在恢復正常的時刻將合適的措施重新引入。--路西法人 2023年3月8日 (三) 15:49 (UTC)回复[回复]

通知曾參與討論的其他用戶：@GZWDer、Kriz Ju、魔琴、Ghren，希望幾位能協助複查用詞字句等並提供完善措施防止濫用。--路西法人 2023年3月8日 (三) 15:54 (UTC)回复[回复]

抱歉，結果還是重ping了……--路西法人 2023年3月8日 (三) 17:02 (UTC)回复[回复]

先不说几次在《维基百科:可靠来源/布告板》有意图以人数“达成共识”、夺取话语权（此问题非仅有本人如此认为），单论上次本人之被封禁某几位事关者要么无视要么强词夺理就是给不出非双标的合理解释，这次直接要把“集体独裁”合法化？并且个别用户明显违反方针、破坏扰乱却毫无惩治措施（可能其为IP豁免用户所以无法禁制IP）的明显对比，可见目前社群不适合“引入社群禁制程序”。--MINQI（留言） 2023年3月8日 (三) 18:22 (UTC)回复[回复]

共識確實不是強求一致同意，但我並不否認閣下舉出的案例中的共識形成或有缺陷，後來共識方針修訂的WP:7DAYS條款也開始令在客棧的同類情況被阻止，有outstanding且未解決的意見則必須暫停公示。多數人暴政或許是維基百科共識制度的本質缺陷，但若不引入社群禁制制度則此權僅落入管理員手中而社群難以推翻，更容易形成小數人暴政。我大可要求管理員結案時概括並衡量所有反對意見，在結案時要求公示，但還是那句：制度會不會被濫用不是制度的問題而是人的問題。與其讓管理員有社群無法控制的權限，而社群又不接受ArbCom這類小數人暴政，倒不如將禁制權參考英文維基百科下放社群。--路西法人 2023年3月9日 (四) 00:02 (UTC)回复[回复]

我问一个最简单的问题：如何确定“广泛共识”的定义？即什么是“广泛共识”？--MINQI（留言） 2023年3月9日 (四) 01:27 (UTC)回复[回复]

如同提案條文所述：社群共識禁制不是投票，管理員結案時必須考慮各論點的方針指引依據及強度作出判斷，此系包含考慮一切異議者所提出的理據及異議是否足以推翻其他支持意見或引致較輕裁定；單純!VOTE一個{{支持}}不是意見而只是立場，清楚說明為何支持，有論點的才是有效意見。--路西法人 2023年3月9日 (四) 02:43 (UTC)回复[回复]

嗯，由第一段第一句讀起來的感覺就很糟糕。太長，而且不停用分句來補充資訊。然後後面的內容就沒有時間仔細看了。您維的方針、指引和現實生活中較為相似的文體是章則、條例，這些文體是點列式的。您維的習慣雖是段落式，句子不需要這樣長的，也不需要一環套一環的。例如這句：「禁制為用戶造成極端或頑固問題（如嚴重擾亂行為）並對其他編者造成困擾的情況下，在其他制裁措施無法處理下才應考慮採用禁制作為制裁用戶的措施。」，那可能寫成「當用戶造成極端或頑固問題（如嚴重擾亂行為），並對其他編者造成困擾時，在其他制裁措施無法處理下可採用禁制以制裁用戶」。另外，有些程度字眼用得不準確，「應」這個字的約束程度較重，在章則這個文體，和這個情況下是不能接「考慮」的。「考慮」那就是還有彎可以轉，那接「應」有什麼用。

然後有些句子讀不通，什麼「雙向互動禁制並既往不咎通常可以快速而又輕易地阻止爭議進一步升級及引起更多擾亂。」；連續使用幾個「且」，「任何用戶不得代理或代表被禁制用戶編輯，除非該等編輯明顯有益於維基百科且代為編輯的用戶有合理且獨立的原因作出該等編輯。」、「任何用戶均可回退違反禁制作出的編輯且無需額外提供理由且不受回退不過三原則所規限，但需注意並非所有由被封鎖用戶繞過封鎖作出的編輯都需要被回退，一些明顯有益的編輯例如修正錯字及回退明顯破壞的編輯等可被保留」等等。比較忙，就不一一細檢當中用詞字句問題了，讀得懂就行。--Ghren 🐦🕐 2023年3月10日 (五) 17:37 (UTC)回复[回复]

有打算稍後再整理文句，內容比較重要。--路西法人 2023年3月11日 (六) 02:29 (UTC)回复[回复]

(！)意見：敝人綜合表達如下：

「頁面禁制」提議條文：「頁面禁制是禁止使用者編輯特定或多個頁面（不限命名空間）的禁制措施。.......需注意局部封鎖（相較於一般封鎖，使被封鎖用戶ＸＸＸ....）並不代表使用者被頁面禁制，但頁面禁制可透過局部封鎖執行；......。」。由於就條文觀之，「局部封鎖」一詞似乎較難理解其具體效果，以及與「頁面禁制」之間的差異何在，個人建議或可考慮將「管理行動禁制」段落的「局部封鎖」連結說明改為在此置入，並於內文略作簡要說明，或提供註記之類。
「實施禁制」的「社群共識禁制」提議條文：「未參與討論的管理員對於禁制提案可在達成明確共識時結案，取獲得廣泛共識的特定禁制措施並予以執行。需注意社群共識禁制不是投票，管理員結案時必須考慮各論點的方針指引依據及強度作出判斷；除雪球法則不通過的情況下，非管理員無權關閉禁制討論。」
「實施禁制」的「管理行動禁制」提議條文：「1.使用者間出現編輯爭議或其他形式的衝突爭端時，可實施主題、互動禁制和回退限制；....。」。
「禁制覆核」的提議條文：「使用者應於申訴時具體說明申訴原因，並根據實際需求提供所需理據。若禁制措施經由社群共識產生，開啟禁制覆核討論時應當通知所有曾參與該禁制討論的使用者，並由未參與先前禁制討論的管理員審視各方理據結案。」。彙整相關內容。

個人意見，供參。--Kriz Ju（留言） 2023年3月10日 (五) 19:47 (UTC)回复[回复]

已依據Ghren、Kriz Ju兩位的意見調整建議條文語句：Special:Diff/76320507，請兩位或其他用戶不吝指教。--路西法人 2023年3月12日 (日) 03:49 (UTC)回复[回复]

(！)意見：敝人斗膽再提一筆：「用戶應於申訴時具體說明申訴原因，並根據實際需求提供因應違規事由所需理據，例如用戶自被禁制或封鎖後所汲取的教訓、若被撤銷禁制會如何改變待人處事或如何認為禁制有不公平之處。」個人仍建議刪除後面的列舉示例，原因如下：

1.前文已概括基本含意。

2.由於違規樣態複雜，建議授予管理員依實際情形和需求判斷的空間，究竟需要何種理據，視情況而定。

3.通常避免列舉例證，例證亦很可能列舉不完。

4.列舉例證後，若有超出條文字面所述，或剛好吻合字面用字者，可能徒生無謂爭議（比如：違規用戶主張「上面沒說要這個啊」、「條文沒答應管理員可以要求這個，濫權了吧？！」、「不是只要心得說明而已嗎？」、「上次某人做了ＯＯ只被封ＸＸ而已，我怎麼這麼久？不公平！」、「他也沒被封啊，怎麼能封我？」等等）。

5.個人另有一主觀想法，字面明文所舉內容，有種威權下的道德教育或教化的濃厚教條感，可是事實上「違規」不限於待人處事如何，且個人認為平台無任何道德或額外義務「教化」或「教訓」用戶的為人處事，亦不需強求用戶為人如何，也不須奢求用戶皆為好人好事代表，規範所要求的僅為「適當合宜、不造成他人困擾且不傷害他人的行為而已」，而非訴諸品德教育或道德感化（「維基感化院」？（笑）），也不是在不違規或不妨礙社群以及其他用戶的前提下，以高壓體系監管他人性格德行甚而系統化，彷若畜牧豢養用戶於此，僅做「生產」或追求何種成效之用。吾人是否需要建立何種「美麗新世界」呢（笑）？

個人意見，供參。--Kriz Ju（留言） 2023年3月12日 (日) 20:24 (UTC)回复[回复]

Special:Diff/76333943--路西法人 2023年3月13日 (一) 01:09 (UTC)回复[回复]

反對任何以社群共識禁制用戶的程序。司法權由少數官僚掌管，與社會經眾議而控制的立法權分開，是阻止Trial of Socrates（英语：Trial of Socrates）一類以雄辯、黑箱政治誘導群眾作出決定的安全網。如果認為某君違反方針，完全可以通過現有的程序，提出事實，要求處理。現在的問題反而是AN3的程序水平相當低下，提出者很多連具體的diff link 都沒有給出，管理員沒有維持討論秩序，導致雙方在提報區混戰，管理員冷處理案子，欠缺具體的提報處理程序等。arbcom的人選是社群中的精英，由他們來當法官，至少判案書條理分明，立論清晰。由社群來搞，只會變成批鬥大會。說不定連批鬥的大字報都貼不出來，只有幾十行"贊成"，變成打內戰了。--Temp3600（留言） 2023年3月13日 (一) 18:02 (UTC)回复[回复]
上面已經說過單單的「贊成」不能視作有效「意見」，一個沒有半點方針指引基礎的提案就算有幾百個「贊成」也沒用。禁制討論不是投票，而是以論點質量而坐判定，這點在上方回覆MINQI的時候說過了，恕我只能視作重複且已回應的反對論點。

其次，英文維基百科的社群禁制並非必須通過仲裁委員會進行，跟閣下的論點顯然有所矛盾；在您指出程序水平低下的ANM誠然也是一種不成文、不規範的社群禁制。

閣下既然指出既有程序混亂，何不提出改善新制度的程序防止出現閣下指出的狀況呢？我早已預料社群禁制有可能需要煮一陣子，但我絕對歡迎並希望各位用戶能協助訂出一個更詳細的社群禁制規範以防止「混戰」情況出現。需記得最終判斷的仍是管理員，此提案僅是希望將整個程序具體化、規範化。

當然，此提案我可以再單獨分出此部分討論，反正我對於重新恢復禁制原有效力、引入全站禁制和完善處理被禁者編輯的規範等部分更為著重。--路西法人 2023年3月14日 (二) 01:47 (UTC)回复[回复]
"論點質量而坐判定"能做到當然是很好。但我按個人經驗，中維人員缺乏這樣的討論能力，如果希望在較短的期限(比如說，一個月)達成有意義討論的就更少。以下隨手僅舉數例:
Wikipedia:存廢覆核請求#奶头乐在五個月的混戰後仍無所得，milky的疑問未獲回應;

Wikipedia:存廢覆核請求/存檔/2022年6月#王士俊_(崇禎進士)混戰後一無所得;

Wikipedia:管理员布告板/编辑争议/存档/2022年12月#Invictus1995冷處理;

Wikipedia:頁面存廢討論/記錄/2022/12/04#大韓航空642號班機空難連事件是否存在也都未能確認;

當然，也有不少可算是"提出有效觀點後達成共識的例子"。然而，大部分例子要不是事件本身因簡單而不存在爭議，要不提出有用意見的人根本就是管理員，甚至是管理員的結案詞，結果還是依賴管理員的聖裁。幸或不幸，目前管理員團隊已集中了中維內說理能力較強的用戶。

英維當然好得多。我隨便翻了這年的en:Wikipedia:Administrators'_noticeboard/Archive333#Systematic deletion flags, flag templates and additional information (blocking edits)，即使是明顯違反現存社群共識的情況，討論者先引用在討論頁針對內容本身的討論(那項討論本身也很長，有十多人參與)，再引用了相關專題小組的討論，後來的討論者再對該用戶的行為整體作出評價，論證為什麼ban是必要手段。我敢說這個討論的細緻程度遠超AN3，恐怕某些RFA的討論也沒有如此詳盡的說理。如果說搬英維的方案，那得先搬英維的用戶過來。--Temp3600（留言） 2023年3月14日 (二) 15:52 (UTC)回复[回复]
我相當認同您對於中維人的討論能力的擔憂，但同時考量到沒有一個更好規範的制度強制中維人提出有意義的意見，中維人整體而言難以進步。與其程序和人員素質都在故步自封，倒不如寫出更好的程序和指導以提升中維討論素質；與其說管理員冷處理，倒不如讓社群推一些充足共識的提案給管理員結更好。--路西法人 2023年3月14日 (二) 16:03 (UTC)回复[回复]
提升社群論述能力非一日之功，無共識而依賴管理員裁斷的現象仍將長期存在。如果要說可以從手的方向，可以先規定提報者至少必須附上diff連結，還有選一些人，給予他們整理an3討論的權利，維持一下討論秩序。總之就是精英化，讓有能力的人不必在泥漿中混戰。--Temp3600（留言） 2023年3月14日 (二) 16:33 (UTC)回复[回复]
可，我稍後試著再草擬一份社群禁制討論指導（當然也適用於現行的AN3及ANM）。--路西法人 2023年3月15日 (三) 00:54 (UTC)回复[回复]

想問一下@Temp3600君：除社群共識禁制外，您對於封鎖方針修訂及禁制方針剩餘的修訂（方針更名、局部封鎖移出禁制、全站範圍禁制等）有無其他意見？整理出社群禁制討論指導後，您又有無可能改變對於該程序的意見？我期望的是讓社群通過社群禁制程序等逐步改進以慢慢達成可建立一個具代表性的ArbCom的程度。--路西法人 2023年3月16日 (四) 01:28 (UTC)回复[回复]
這個更改涉及的條文很多，今晚我先看了一部分。如果我認為某一項修訂影響重大，但未見討論，我將會提出分柝該部分的修改。

社群禁制的本質問題在於新程序有什麼好處，以至必須獨立分家出來。此外，我反對任何通過"社群共識"逼使管理員封人的程序。法無禁止即自由，必須先立法後封人，也就是說，先有了不准做某事的共識，才談得上違反社群共識; 而不能是翻舊帳，在作出共識的時候將還沒立法時候的舊例子翻出來封人。社群眾人更積極參與封禁討論，提出事證等本身當然是好事。--Temp3600（留言） 2023年3月16日 (四) 15:24 (UTC)回复[回复]

用一個更"哲學"的說法，就是社群共識本身也應被其他權力制衡。--Temp3600（留言） 2023年3月16日 (四) 15:25 (UTC)回复[回复]
我什麼時候說過可以用原先不存在的共識（如方針指引）來禁制人了？社群共識的基礎必須是現存方針指引，但有時候一些行為方針無法全部明確定義（如WP:GAME、WP:POINT、WP:CIV等，很多條文都是類似「包括但不限於」）。這些是已長久存在的方針，但管理員雖然可能有自己對於某些行為是否有違此類方針有個人看法，即使有方針基礎也缺乏社群認同特定行為是否屬於該等方針所指的不當行為。此並非「法無禁止」（確實有禁止遊戲規則、闡述觀點而擾亂及不文明行為等），但特定行為是否觸犯方針恐怕永遠無法每次都討論加入方針，社群禁制正應是用在這些情況。--路西法人 2023年3月17日 (五) 00:24 (UTC)回复[回复]

現存的ANM佈告板實質上也是社群禁制的制度：用戶提出請求、其他用戶辯論是否違反上述方針，管理員再視情況決定是否封鎖，只是現存ANM制度毫無規範而已。--路西法人 2023年3月17日 (五) 00:28 (UTC)回复[回复]
灰色地帶的部分我不認同。既然此前並沒有關於某項灰色地帶行為是否違反方針的共識，那就必須先討論，達成共識後才談得上「違反方針」。別人完全可以反駁，他既然較早前沒有被封（如在某次AN3討論中過關），那就說明這類行為在管理員的眼中沒有突破底線。這一點在我上面引用的英維討論有明確反映出來——英維社群為了糾正他的行動，第一件事是先在條目討論頁達成共識，指出那些條目應怎樣寫，下一步才是他因繼續違反了這一項新達成的條目共識而被禁制。Temp3600（留言） 2023年3月17日 (五) 10:10 (UTC)回复[回复]
清楚明白理解。若將本地社群禁制程序重寫為現狀（AN3+ANM+VP）而加以規範，其餘執行權不變，閣下是否認同？--路西法人 2023年3月18日 (六) 01:42 (UTC)回复[回复]
順道作一點補充︰我上面在討論的問題，現實來說是法律的解釋權應由那一個機構行使的問題。在大部分國家，這屬於憲法法庭及其他法院的職能。有一些國家有不同的制度，但就我看來，實施前者制度較為優勝。就維基百科的情況來說，WMF固然擁有Terms of Use的最終解釋權，但中維的日常爭議仍需由本地人員負起這份職責。考慮到中維沒有ARBCOM的現實，這份職能由管理員們--即社群中較熟識方針，說理能力較好的用戶負責，較為適合。

回到正題: 社群通過an3/VIP/VP，在封鎖有關的討論發表觀點，討論某種行為本身、條目內容的寫法，都是社群行之有效的程序，並應予以規範化。然而，社群即使達成共識，也不能向某用戶指名施加處分。

又例如，社群對某些事務，常會先通過討論，達成一項採用投票制來決定討論結果的共識，並接着舉行投票，某些圖示、翻譯名稱就是這樣決定的。但是，社群不能以共識決，決議舉辧投票來決定某名用戶是否違反方針。如afd一樣，封鎖討論只能是討論，不能通過共識改採投票制或其他制度。--Temp3600（留言） 2023年3月18日 (六) 11:16 (UTC)回复[回复]

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直至提案者更新提案：多忙兩天，過幾天再修訂提案。--路西法人 2023年3月22日 (三) 13:58 (UTC)。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。回复[回复]

重提草稿化討論

維基百科:草稿命名空間/2022年更新草案似有充分支持意見（先前討論：一、二）而未走公示程序，重推一下。通知@QiuLiming1、HTinC23、Cwek、YFdyh000、Kriz Ju、S8321414、Temp3600。--路西法人 2023年3月9日 (四) 02:57 (UTC)回复[回复]

看上去沒多大問題，但之前看到有人直接把條目移動到draft空間後就沒任何操作，就等於只做了草稿化操作指南第一條的第一點。--日期20220626（留言） 2023年3月9日 (四) 03:54 (UTC)回复[回复]

程序未正式訂立，有人沒能跟從操作尚不算不合理。--路西法人 2023年3月9日 (四) 04:36 (UTC)回复[回复]

"請將草稿頁面內殘留的頁面分類標記和非自由圖片連結化"最好有小工具協助完成。如果單靠人力，偶有遺漏實屬人之常情。--Temp3600（留言） 2023年3月12日 (日) 17:03 (UTC)回复[回复]

還有就是如果有人（比如作者）不同意移動到草稿，就提交到條目存廢討論決定去留嗎。--日期20220626（留言） 2023年3月9日 (四) 03:57 (UTC)回复[回复]

@LuciferianThomas：相关的，如果有巡查先按以往巡查操作给予了操作（包括标识问题、SD、AFD等），也就是不给予草稿化，然后其他编辑能否推翻这些决定，将其草稿化？——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:42 (UTC)回复[回复]

（為什麼ping我，我只是幫忙把舊討論拉出來而已）理應不衝突，但建議如果其他巡查員已做事，草稿化後通知一下做事的巡查員會比較好。--路西法人 2023年3月10日 (五) 00:50 (UTC)回复[回复]

看起來沒什麼問題，應該可以繼續推進。--冥王歐西里斯（留言） 2023年3月9日 (四) 05:07 (UTC)回复[回复]

如果不具强制性的话，可以考虑（有些编辑愿意好人做到底的话）。不过“质量明显不符合标准”的章节条件，似乎有点像完全兜底，SD不用SD，AFD预期不会保留的，小作品不挂小作品，全部可以扔去草稿，那这些之前机制好像没有了存在的意义？——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:35 (UTC)回复[回复]

之前的機制指的是？--日期20220626（留言） 2023年3月10日 (五) 00:38 (UTC)回复[回复]

正常情况下，该SD就SD（例如G11，你会扔草稿？），该AFD就AFD（保不保留是讨论后决定，不做结果水晶球），小作品就挂小作品等30天。这些就是之前机制。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:45 (UTC)回复[回复]

原則上應該是不符合SD、AFD、小小作品，但又不適合保留在條目空間的才會走草稿化吧，閣下覺得這裡的文字要怎麼修正才能體現這個流程？--冥王歐西里斯（留言） 2023年3月10日 (五) 01:23 (UTC)回复[回复]

是我的错误，没考虑前提条件是条件“全部符合”才需要考虑草稿化，这是其中的一个子条件。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 01:55 (UTC)回复[回复]

G11的作品如果有關注度但是自己想改善，可以先移動到草稿。不過大部分情況下想改善的人少，所以就直接G11了。--日期20220626（留言） 2023年3月10日 (五) 01:45 (UTC)回复[回复]

畢竟符合G11的條目基本上都是刪後重建比較快（。--冥王歐西里斯（留言） 2023年3月10日 (五) 02:45 (UTC)回复[回复]

“旧条目或不全满足以上条件的新条目不应直接草稿化，而须在存废讨论寻求草稿化共识或提报侵权。”，后面“或提报侵权”是不一定的操作，或者替换成“或其他页面处理方式（包括提报侵权）。”——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:42 (UTC)回复[回复]

我認為應該加入英維在昨年通過的條款——當條目已經建立90天（或其他合理的日數），不應草稿化。--Ghren 🐦🕖 2023年3月10日 (五) 11:30 (UTC)回复[回复]

那中維的話可以限定為未被巡查的新條目？--日期20220626（留言） 2023年3月10日 (五) 11:33 (UTC)回复[回复]

那也可以，畢竟那條是說除非在AFD達成共識，否則不應把在條目空間超過90天的條目移動到草稿空間。--冥王歐西里斯（留言） 2023年3月10日 (五) 11:35 (UTC)回复[回复]

巡查时限为30日，个人觉得30日足矣。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年3月10日 (五) 15:32 (UTC)回复[回复]

英維設90天應該是給一些沒有被即時巡查到的條目對巡查員給予寬限期啦，但限定為巡查期限內的好像也不是不行就是。--冥王歐西里斯（留言） 2023年3月10日 (五) 22:58 (UTC)回复[回复]

支持繼續推進。草稿化能給予新手更充足時間改寫條目，並尋求其他編者的幫助，有助緩和巡查員與新人之間的沖突。--Temp3600（留言） 2023年3月12日 (日) 16:59 (UTC)回复[回复]

每个人对草稿化“有发展成完整条目的潜力”的标准不同，执行起来或许会有争议。不如把草稿化作为AFD的一个处理结果。--Steven Sun（留言） 2023年3月13日 (一) 08:06 (UTC)回复[回复]

目前AFD的其中一個結果就會是草稿化（但很少出現），提這個討論的目的應是把目前部份巡查員做的事情指引化（因為部份條目真的不適合留在條目空間，但刪掉又很可惜），讓之後的編者有個可以遵循的依據。--冥王歐西里斯（留言） 2023年3月13日 (一) 23:24 (UTC)回复[回复]

始終草稿化有軟刪除的效果，有指引共識會更便於管理。--Temp3600（留言） 2023年3月18日 (六) 10:03 (UTC)回复[回复]

草稿化可以是AFD的結果，但其潛力更在於供巡查員處理新人條目這一方面。--Temp3600（留言） 2023年3月13日 (一) 15:19 (UTC)回复[回复]

(＋)支持&(！)意見：敝人不熟草稿流程，但支持持續推進，同時覺得草案所提及的草稿整理實務，對於巡查員或打算申請權限的用戶可能也是個可以參考的標準。另支持「舊條目或不全滿足以上條件的新條目不應直接草稿化，而須在存廢討論尋求草稿化共識或其他页面处理方式（包括提报侵权）。」。--Kriz Ju（留言） 2023年3月16日 (四) 18:32 (UTC)回复[回复]

@S8321414：我近期沒空，靠您推進這個討論了。--路西法人 2023年3月26日 (日) 06:55 (UTC)回复[回复]

看來上面主要要改的是引入新條目過30天後不應草稿化的條款，不知道還沒有有其他的意見。--冥王歐西里斯（留言） 2023年3月26日 (日) 11:53 (UTC)回复[回复]

再加上一個，如果對條目是否草稿化出現爭論，則建議直接提交存廢討論。--日期20220626（留言） 2023年3月26日 (日) 11:56 (UTC)回复[回复]

建议将WP:EVENT升格为社区正式指引

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:关注度 (事件)。

前续Wikipedia:互助客栈/条目探讨#准备批量清理Category:2022年中国大陆2019冠状病毒病聚集性疫情的条目的讨论，除了聚焦性疫情的条目，其实还有很多关注度有待商榷的条目需要进行清理，而这个问题的解决方案可能要归结到WP:EVENT上面来。综合前几次升格讨论，再结合目前WP:EVENT的实际情况，个人觉得需要打磨的地方还是特别多，在此向大家征求修改意见，争取在正式投票前完善现有内容。--百战天虫（留言） 2023年3月14日 (二) 04:15 (UTC)回复[回复]

(＋)支持--🎋🍣 2023年3月14日 (二) 12:18 (UTC)回复[回复]

(－)反对這樣會讓大量多年來建立的歷史事件條目有被刪除的危機，對讀者是不利，接收的資訊比以往更少。日後可能要出海外的圖書館才能查閲。--Wpcpey（留言） 2023年3月14日 (二) 12:26 (UTC)回复[回复]

你说的理由也可以用来反对现行的WP:GNG。--百战天虫（留言） 2023年3月15日 (三) 15:43 (UTC)回复[回复]

無後續影響的事件本來就會被人用關注度提刪（江澤民槍擊事件）。假如圖書館能找到好的來源，自然也能保留了。--日期20220626（留言） 2023年3月17日 (五) 03:22 (UTC)回复[回复]

(＋)支持：這個提案從十二年前就獲得大量用戶的認可，只是因爲細節問題暫且擱置。之後的一些指引中也有相應的條文，屬於事實上無冕規則。——WMLO（留言）。 2023年3月14日 (二) 13:24 (UTC)回复[回复]

(＋)支持--冥王歐西里斯（留言） 2023年3月14日 (二) 14:03 (UTC)回复[回复]

雖然此項關注度指引未正式通過，但社群的GNG關注度流程大概也是以跟隨此指引類似的標準的，故(＋)支持正式訂為指引。對於上面那個反對毫不意外，沒來反對才奇怪。--路西法人 2023年3月14日 (二) 15:56 (UTC)回复[回复]

(＋)支持：同時小改錯別字。--Kriz Ju（留言） 2023年3月15日 (三) 18:54 (UTC)回复[回复]

在本地配套機制及慣常措施未能適切發揮制約作用的情況下，有必要將該升格程序分拆及設定週期檢討期限，一旦發現該規限是被濫用或不合比例地適用，就應當啟動中止及重新審訂之程序——綜合改進過程，必要是將WP:MAJORITY、WP:NOTWIKI、WP:JNN、WP:BELONG、WP:JUSTAPOLICY、WP:IDONTLIKEIT、WP:DEFUNCTS等約定及關聯章節，同時間匹配地升格地位，並且強化及細化關聯章節之限制力以及反推作用，確保升格過程及後續影響不會偏頗地發生一邊倒效果。--約克客（留言） 2023年3月16日 (四) 02:48 (UTC)回复[回复]

如果是这样的话，会不会先讨论升格一下阁下所说的这些个规则比较好，起码可以提前上个保险啥的。如果是这样做，工程量肯定不小，不知道可不可以开个集中讨论。--百战天虫（留言） 2023年3月16日 (四) 05:41 (UTC)回复[回复]

en:WP:AADD也只是論述，且逐段提升也不是好主意，就算要也是整個WP:AADD提升指引；但不認為有任何執行價值，違反了也不認為可以導致任何後果，頂多就是提醒或忽略，沒有提升的意義。--路西法人 2023年3月16日 (四) 06:19 (UTC)回复[回复]

目前方针很明显还没有完善，连最基本的出发点也错了。WP:EVENT本则上所依的条文是WP:NOTINFO和WP:NOTNEWS，而非关注度条文。上方的疫情条目相信有不少条目是合「有效介绍」、「可靠」、「第二手」、「独立」的标准，但依WP:NOTINFO和WP:NOTNEWS不应收录。需要大幅修订。--Ghren 🐦🕓 2023年3月16日 (四) 09:24 (UTC)回复[回复]

？某些例行的新聞種類（包括絕大多數的犯罪、事故和死亡報道，名人或政治新聞，「震驚」新聞，缺乏持續價值的「奇聞」以及病毒傳播現象），無論是否悲劇，無論是否在當時被報道過，通常都不具有關注度，除非有其他事件可以賦予其持續的意義。--路西法人 2023年3月17日 (五) 00:32 (UTC)回复[回复]

所以就說「WP:EVENT本則上所依的條文是WP:NOTINFO和WP:NOTNEWS，而非關注度條文。」，這裏不應說「通常都不具有關注度」，而應該說「基於WP:NOTNEWS不應收錄」。下邊WP:ROUTINE說得很清楚了，是按照「按照維基百科方針（WP:NOTNEWS），對公告、體育運動等主題的例行新聞報道以及各種小報新聞，都不足以確立一篇獨立條目。」，而不是什麼關注度。--Ghren 🐦🕑 2023年3月17日 (五) 06:03 (UTC)回复[回复]

不衝突啊，§ 收录标准是關注度，§ 其他条件是基於其他方針，事件是否可以成條。關注度不就是「可不可以寫一個主題」嗎？為何就不是關注度了？--路西法人 2023年3月17日 (五) 08:05 (UTC)回复[回复]

說實話不知道您在說什麼。您上邊的那段引文我最少也想了三分鐘才看得懂您引用的目的是什麼。關注度是決定能否寫一個主題，但只是「假定」可以收錄。而在WP:NOTNEWS的規定下，這些條目不能收錄。「例行報道」是違反WP:NOTNEWS的問題，而不是關注度的問題。當然您也可以認為「例行報道」是違反關注度的要件。另外「例行報道」，或者「例行的新聞種類」感覺和英文原句「Routine coverage」有些距離。--Ghren 🐦🕒 2023年3月19日 (日) 07:47 (UTC)回复[回复]

看中英序言相差得大了点，是否需要重新翻译？--东风（留言） 2023年3月17日 (五) 15:14 (UTC)回复[回复]

既然本身就是從英維翻譯來的，英維更新了，中文的也應該同步跟進。--日期20220626（留言） 2023年3月17日 (五) 15:26 (UTC)回复[回复]

我更新一下。--百战天虫（留言） 2023年3月23日 (四) 06:47 (UTC)回复[回复]

“A地－B地关系”是不是该用短横线？

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:命名常规 (国际关系)、Wikipedia talk:格式手册/标点符号。

此话题无关“一字线的符号选择”，故另开一节。许多“A地－B地关系”条目标题用的是一字线，方针草案《WP:命名常规 (国际关系)》中谈及有关内容也用的是一字线，但是窃以为应该用短横线。按我对GB/T 15834-2011的理解，连接号只有表示“起止”时才该用一字线，而“A地－B地关系”中的连接号并不表示起止。

中华人民共和国外交部网站上有些类似情况也用了一字线^{[dash 1]}。然而窃以为，国家标准与外交部网站不同的时候，参照前者会更合适，故仍应使用短横线。--爱维基百科的CuSO₄ 2023年3月14日 (二) 21:19 (UTC)回复[回复]

现MOS:连接号1-4中复合名词用短横线的指引规定似乎已经与WP:命名常规 (国际关系)中的方针部分冲突。之前将国际关系命名常规升为格式指引的提案中已经有编者讨论，但看来毫无进展。@維基百科最忠誠的反對者、Sanmosa、Ericliu1912、虹色分子：故ping曾参与讨论的各位编者，希望能引起重视。--PexEric 💬|📝 2023年3月18日 (六) 12:50 (UTC)回复[回复]

@PexEric(＊)提醒：WP:命名常规 (国际关系)中的方针部分并不涉及连接号。只有“外交代表机构命名”一节是方针，涉及连接号的是其他章节。--爱维基百科的CuSO₄ 2023年3月19日 (日) 09:21 (UTC)回复[回复]

抱歉，是我眼瞎了。那看来可以直接修正。--PexEric 💬|📝 2023年3月19日 (日) 09:38 (UTC)回复[回复]

但是看起來很怪。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月19日 (日) 09:58 (UTC)回复[回复]

如果你說的短橫線是半形那種我就(－)反对。中文文章就應為美觀起見按全形格式統一用全形標點。--——勿用「進行」污染中文，要言簡意賅。　捍粵者 2023年3月22日 (三) 14:10 (UTC)回复[回复]

这个问题其实很复杂，我在“一字线的符号选择”提案里其实有意回避了这个问题。其实按照中国的旧标准GB/T 15834―1995，这种情况无疑应该使用一字线。在新标准中，这个问题被过度简化成“复合名词”(compound noun)。但按照语义理解这里的双边关系是两个实体名词之间的联系，不能简单看成一个词，英文中用 en dash 而不是 hyphen 连接，表示“A和B的关系”而不是一种“名为A-B的关系”。--InstantNull（留言） 2023年3月20日 (一) 07:51 (UTC)回复[回复]

看了一下GB/T 15834―1995，并没有明确规定不同情况下符号的长短。例中的秦岭－淮河线也可以理解成表示起止，和新标准不矛盾；en:Qinling–Huaihe Line也是用em dash。我认为还是应参新标准用短横线，不知道其他地区是否有类似标准。--PexEric 💬|📝 2023年3月20日 (一) 15:10 (UTC)回复[回复]

U+002D（連字暨減號，-）比半字短，显示效果不好。此外，w3c中短横线推荐的 en dash（U+2013，–）。另像牛頓-寇次公式感觉换成U+002D也是感觉短。--Kethyga（留言） 2023年3月25日 (六) 08:25 (UTC)回复[回复]

註釋

^ 如中国—阿拉伯国家合作论坛、澜沧江—湄公河合作、萨赫勒－撒哈拉国家共同体。

有考虑把「特色列表」改成「典范列表」吗？

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:典范条目、Wikipedia talk:特色列表、Wikipedia talk:特色图片。

目前中维有三类典范（特色）内容：典范条目（FA）、特色列表（FL）、特色图片（FP）。FP的内容在图站，本地都没有页面。其本身就有编外性质，可以抛开不谈。

剩下的FA和FL本质相同，分别象征本站条目和列表中的最佳。然而同样内涵的两者却叫不同的名字，这很让人困扰。比如FA+FL+GA并称都不知道该叫「典优内容」还是「特优内容」。严谨点的称呼是「典范（特色）和优良内容」，但是加个括号也挺啰嗦的。

话说社群有考虑「特色列表」改称「典范列表」吗？--洛普利寧 2023年3月19日 (日) 16:02 (UTC)回复[回复]

不知道當時為什麼沒有改全。不管是要改成「典範」還是反過來改回「特色」，無論如何是應該統一稱呼。另外其實我覺得特色圖片也一起改比較好。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月19日 (日) 16:21 (UTC)回复[回复]

這種討論遲早都會爆的，很想看看這個獨裁社群到底又要搞什麼花樣了。在FA改名成典範之後，到底知不知道已經改了多少個從「特色條目」改成「典範條目」的頁面了？總之，絕不會給出什麼意見，更不會選邊站，因為本質還是叫做FA/FL/FP。這個獨裁社群就是喜歡「沒事找事做」。更直接的說就是，可能這個獨裁社群每過幾年，就會把這種討論再重複搬出來詢問一次，周而復始永不止盡，即便到了退休甚至死亡了還是一樣不會改變。這裡並不是en版，如果是en版就沒有這個問題。--Z7504非常建議必要時多關注評選（留言） 2023年3月19日 (日) 16:29 (UTC)回复[回复]
本人非常建議您去看心理醫生而不是整天在這裡罵「這個獨裁社群」，這種留言難以對討論帶來實質幫助，謝謝您。--Sun After Rain 2023年3月20日 (一) 01:18 (UTC)回复[回复]
本來就是獨裁社群啊，請問「FA/FL/FP本質沒有變」不是事實嗎？您們所謂的沒壞別修的概念顯然都是假的。可悲獨裁的爛社群，然後就直接躲起來不敢討論了，呵呵呵，因為講的就是事實。有了這種獨裁社群，看了只會「賭爛」，而且願意編輯維基百科的人也只會越來越少，不會越來越多。--Z7504非常建議必要時多關注評選（留言） 2023年3月20日 (一) 13:31 (UTC)回复[回复]

我反而想让FA改回去。

——Sakamotosan路过围观 | 避免做作，免敬 2023年3月21日 (二) 00:15 (UTC)回复[回复]

典範圖片不好聽，我也不覺得圖片有「典範」可言。Temp3600（留言） 2023年3月21日 (二) 09:40 (UTC)回复[回复]
我都覺得FP可以廢了。FP檔案不在本站，首頁圖片和FP又沒關係，現在評審區也是門可羅雀。誰要覺得自己上傳的圖片優秀，自己去c站評就是。畢竟那邊有專業鑑定能力的編者多。--洛普利寧 2023年3月21日 (二) 14:10 (UTC)回复[回复]
我不覺得FP能再活躍起來，但保留程序當後備也沒什麼不好。--Temp3600（留言） 2023年3月21日 (二) 15:40 (UTC)回复[回复]
有点离题？不过FP要求图片在C区，和本地贡献者关系有限，变成帮别人做“嫁衣”，可有可无的鸡肋，程序上保留，选不选随缘。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月22日 (三) 01:00 (UTC)回复[回复]
那把FL改成「典范列表」（和FA相比，改FL变动比较少）；FP评选的是外站对象，姑且还用「特色」这个特殊的说法？--洛普利寧 2023年3月23日 (四) 14:04 (UTC)回复[回复]
我反而想让FA改回去。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月24日 (五) 00:48 (UTC)回复[回复]
(＋)支持改回去--百無一用是書生 (☎) 2023年3月24日 (五) 02:21 (UTC)回复[回复]

(＊)提醒：Wikipedia:特色条目候选/髮夾彎 --Milky Defer 2023年3月25日 (六) 09:35 (UTC)回复[回复]

提议将AI或深度学习技术生成的文章列为不可靠来源

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

AI或深度学习技术生成的文章常常似是而非，看上去没有问题而实际上却含有事实错误，因此，我本人提议将AI或深度学习技术生成的文章列为不可靠来源。--Sprt98（留言） 2023年3月20日 (一) 13:55 (UTC)回复[回复]

有没有可能，WP:RS没有将AI或深度学习技术生成的文章列为可靠来源。这样纸上谈兵意义何在？请给出提案的具体内容，例如如何界定文章是否由AI或深度学习技术生成。--PexEric 💬|📝 2023年3月20日 (一) 15:22 (UTC)回复[回复]

有的媒体会试用ChatGPT工具生成一些文章。如果明确署名或者声明了这篇文章是ChatGPT写的，那么这篇文章应该如何对待？还有的媒体偷偷摸摸在用，被其他媒体揭发，如CNET。英维以此为由直接将CNET（2022年11月及以后）的文章全数打为不可靠。--Milky Defer 2023年3月21日 (二) 04:49 (UTC)回复[回复]

(▲)同上且在有可靠的AI檢測器問世之前你維所有關於AI生成內容的規範提案都是偽命題--某人 ✉ 2023年3月20日 (一) 15:35 (UTC)回复[回复]

大致同上，同不太支持，但问题是，如何分辨出来？看手有没变形？

——Sakamotosan路过围观 | 避免做作，免敬 2023年3月21日 (二) 00:13 (UTC)回复[回复]

說個笑話，有人認為2001年1月15日之後的論文是不可靠

適應新時代，無需斬腳趾避沙蟲。--Nostalgiacn（留言） 2023年3月24日 (五) 03:02 (UTC)回复[回复]

建议把转基因食品定性为有害食品，建议把辅助生殖技术定性为促进劣性基因遗传，建议将所有外来移民当成潜在间谍或者未遂罪犯处理^{[開玩笑的]}，「常常」不是「必然因果」----Cat on Mars 2023年3月24日 (五) 05:47 (UTC)回复[回复]

一家報紙的文章「常常」是錯的，這種報紙我們應該列入不可靠來源吧？ ——魔琴 [ 万户涕泪 ] 2023年3月24日 (五) 11:13 (UTC)回复[回复]

不論正誤，既已屬於來源（AI或其他平臺）發表，而來源（AI或其他平臺）亦可查驗之情狀，即已適切維基基本要求。因無法接受合乎維基精神之打破陳規，不合邏輯之額外設限實在是阻礙採編空間，恐怕有違維基基石且嚴重制礙系統之協作改進。--約克客（留言） 2023年3月24日 (五) 12:12 (UTC)回复[回复]

同感，因「常常」而被判定為不可靠，是正常、合理且一直這樣做。--Factrecordor（留言） 2023年3月25日 (六) 08:44 (UTC)回复[回复]

注意不要偏離主題，報章和AI或其他新概念平臺兩者，並非等價而可以籠統概論之--約克客（留言） 2023年3月26日 (日) 09:13 (UTC)回复[回复]

政府單位「限閱」文件得否在撰寫條目時引用

本主題全部或部分段落文字，已移動至Wikipedia:互助客栈/其他。执行人：Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月21日 (二) 20:44 (UTC)。回复[回复]

技術

请求引入Popular pages bot和Extension:PageAssessments

於Phabricator查看
編號T326387的任務
已解決

於Phabricator查看
編號T328012的任務

於Phabricator查看
編號T329617的任務

请求引入meta:Community Tech/Popular pages bot，该机器人可以记录每个专题的高浏览量页面。不过在此之前还需要先引入Extension:PageAssessments并修改Template:WPBannerMeta。--BlackShadowG Slava Ukraini! 2022年12月31日 (六) 08:59 (UTC)回复[回复]

非常支持--百無一用是書生 (☎) 2023年1月3日 (二) 03:24 (UTC)回复[回复]

行。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年1月3日 (二) 16:08 (UTC)回复[回复]

PageAssessments对开发小工具和bot非常有用--百無一用是書生 (☎) 2023年1月5日 (四) 02:13 (UTC)回复[回复]

(＋)支持--冥王歐西里斯（留言） 2023年1月5日 (四) 02:25 (UTC)回复[回复]

(＋)支持--Taeas（留言） 2023年1月5日 (四) 02:51 (UTC)回复[回复]

见phab:T326387--百無一用是書生 (☎) 2023年1月6日 (五) 03:10 (UTC)回复[回复]

感谢，在引入PageAssessments之后，本地还需要参考英维修改Template:WPBannerMeta/core和Template:WPBannerMeta/taskforce。--BlackShadowG Slava Ukraini! 2023年1月6日 (五) 04:27 (UTC)回复[回复]

部署后会有一个新的特殊页面Special:PageAssessments，phab的讨论提到需要一个别名，如果各位没有其它意见，就直译为Special:页面评级如何？--BlackShadowG Slava Ukraini! 2023年1月10日 (二) 07:12 (UTC)回复[回复]

(＋)支持-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月10日 (二) 15:32 (UTC)回复[回复]

行。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年1月11日 (三) 23:10 (UTC)回复[回复]

已经把该别名提供给phab那边了。--BlackShadowG Slava Ukraini! 2023年1月13日 (五) 01:28 (UTC)回复[回复]

感觉现在可以请求机器人给条目讨论页挂专题模板。之前好像是因为有些问题停用了机器人。--Kethyga（留言） 2023年1月13日 (五) 11:42 (UTC)回复[回复]

那边回复了。--Taeas（留言） 2023年1月14日 (六) 09:16 (UTC)回复[回复]

phab那边有技术人员询问本地的评级模板如何修改，因此我把PageAssessments安装后本地需要修改的评级模板也写好了沙盒版本：

Template:WPBannerMeta、Template:WPBannerMeta/core和Template:WPBannerMeta/taskforce三个元模板需要修改，沙盒版本在Template:WPBannerMeta/sandbox、Template:WPBannerMeta/core/sandbox和Template:WPBannerMeta/taskforce/sandbox，测试结果无误，测试样例位于Template:WPBannerMeta/testcases。

测试样例中的目前直接显示在外的“{{#assessment:郁金香/原种郁金香工作组|丙|极高}}”和“{{#assessment:郁金香|丙|低}}”正是预期得到的结果，在PageAssessments安装后，这些会成为解析器函数。

修改方案也回复给了phab那边。--BlackShadowG Slava Ukraini! 2023年1月16日 (一) 03:03 (UTC)回复[回复]

(？)疑問：@BlackShadowG：{{#assessment:}}這個解析器函数支援諸如「丙」、「極高」或「极高」的「中文」評級值嗎？要不要問問Phab技術人員，評級值是否支援本地化或者能否設定别名（例如極高有「極高」和「极高」兩種名稱）？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月16日 (一) 04:41 (UTC)回复[回复]

@A2569875：应该是支持“中文”值的，我在写沙盒前特意去法语维基百科（安装了PageAssessments）看过，他们那边也是用的法语名称。

设定别名可能可以，但估计意义不大，毕竟有{{Class mask}}，也就是说（以ACG专题为例），无论评级模板是填写{{WikiProject ACG|importance=Top}}，还是{{WikiProject ACG|importance=極高}}，还是{{WikiProject ACG|importance=极高}}，到了{{#assessment:}}这里都会被统一成其中一者（目前是简体中文），所以设置别名可能意义不大。繁简方面的话，我觉得如果Special:PageAssessments这个页面能支持繁简转换应该就没有问题了。--BlackShadowG Slava Ukraini! 2023年1月16日 (一) 05:37 (UTC)回复[回复]

@BlackShadowG：還有一個問題，就是中文區還有一個英文區沒有的評級標準，也就是模組級（不是模板級）例如Category:模块级元素条目，這個擴展功能有支援嗎？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月16日 (一) 11:35 (UTC)回复[回复]

感覺就像一個普通的資料表，class字段沒有特別的約束，寫任何內容都可以。--洛普利寧 2023年1月16日 (一) 13:27 (UTC)回复[回复]

@Lopullinen：不是這樣的吧，你看 https://xtools.wmflabs.org/topedits/en.wikipedia.org/A2569875 英文維基的用戶各命名空間編輯最多的頁面統計中的評級欄位，有要能識別到 Stub=小作品級

（圖示才會正常）、 Start=初級

（圖示才會正常）、 B=乙級

（圖示才會正常）、 List=列表級

（圖示才會正常）等，要讓擴展能正常識別吧，不是「寫任何內容都可以的普通資料表」吧。如果識別不到（圖示不正常顯示）那這擴展估計沒用了，無法正常串接各工具和API。所以我認為需要標準化。所以才希望請@BlackShadowG：幫忙問問中文名稱能否正常被識別，如果無法，要如何設置才能被正確識別？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月17日 (二) 03:35 (UTC)回复[回复]

那应该是xtools自己有张表，把评级结果和图标关联起来。比如这份列表的「Biodiversity of Westchester County, New York」条目评级是SL，也有自己的图示（

）。xtools可以识别这个等级，只是该工具未指定关联图示而已。--洛普利寧 2023年1月17日 (二) 05:27 (UTC)回复[回复]

@Lopullinen：但前提是他們要識別到「正確的」評級，而不是隨便的字串。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月17日 (二) 05:29 (UTC)回复[回复]

我的意思是，擴展既然能支援隨便的字串，當然也能支援模組級。這個擴展本身就是記錄「專題名稱·品質級別·重要度級別」這樣一組三個字串而已。至於記錄的品質如何使用，那是另一件事情。比如要想讓xtools顯示圖示，那就要先做一個模組級的圖示，然後聯繫xtools的維護者做映射了。--洛普利寧 2023年1月17日 (二) 05:39 (UTC)回复[回复]

@Lopullinen：確定是這樣嗎？有沒有說明文件？還是可以諮詢phab 工程師？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月17日 (二) 05:45 (UTC)回复[回复]

我感覺是。要不諮詢工程師也行。--洛普利寧 2023年1月17日 (二) 05:52 (UTC)回复[回复]

是的，PageAssessments就是記錄「專題名稱·品質級別·重要度級別」三个字段的值，至于具体的值是什么PageAssessments并不限制，只要字符长度不超限就行--百無一用是書生 (☎) 2023年1月17日 (二) 06:52 (UTC)回复[回复]

另外，我建议这个扩展最好装到中文测试wiki上测试一下看看。。。--百無一用是書生 (☎) 2023年1月17日 (二) 06:53 (UTC)回复[回复]

另外Xtools可以識別正確的評級，只要我們在Wikitext中往{{#assessment}}中傳的是正確的。至於圖示的問題，我們本地{{classicon|Module}}的效果也是

啊。--洛普利寧 2023年1月17日 (二) 05:42 (UTC)回复[回复]

那边有技术人员提了个有关工作组的问题。--Taeas（留言） 2023年1月18日 (三) 16:05 (UTC)回复[回复]

Special:PageAssessments出現了，~~但是在繁體中文下怎麼變成了「頁面評比」了？~~有人解決了；然後Special:页面评级和Special:頁面評級怎麼還是紅鏈（截至2023年1月23日 (一) 16:19 (UTC)）-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月23日 (一) 14:57 (UTC)回复[回复]

不知道是我测试有问题，还是真的有问题。似乎专题名称输入简体就有结果，繁体就没有结果？--百無一用是書生 (☎) 2023年1月24日 (二) 06:46 (UTC)回复[回复]

大概搞明白了，扩展中出现的专题名称是模板中PROJECT参数定义的名称。例如Template:鐵道專題，专题页标题和模板名称都是繁体，但Template:鐵道專題中的PROJECT参数则是简体，就会导致输入“鐵道”查不到任何数据--百無一用是書生 (☎) 2023年1月24日 (二) 06:55 (UTC)回复[回复]

我建议PROJECT参数必须与相应的wikiproject页面名称保持一致（包括繁简），这样会避免很多麻烦--百無一用是書生 (☎) 2023年1月24日 (二) 06:59 (UTC)回复[回复]

我觉得是由于该扩展本身就繁简敏感，PROJECT参数填入简体则只能搜索简体，填入繁体则只能搜索繁体。--BlackShadowG Slava Ukraini! 2023年1月25日 (三) 13:01 (UTC)回复[回复]

专题名、品质级别、重要度级别全用英文算了。ACG专题输出的重要度是繁体「極高」，其他許多專題又是簡體。還有專題叫「条目-{zh-tw:品質;zh-cn:质量;}-提升计划]。反正簡繁各种猜。--洛普利寧 2023年1月25日 (三) 13:27 (UTC)回复[回复]

或者一个专题挂两个#assessment，一简一繁。--洛普利寧 2023年1月25日 (三) 13:29 (UTC)回复[回复]

担心挂繁简两个#assessment可能会被误认为有两个专题，我觉得最好把扩展不支持繁简转换的问题反映给phab那边，如果能修复就最好不过了。--BlackShadowG Slava Ukraini! 2023年1月26日 (四) 10:29 (UTC)回复[回复]

已经提交给phab：phab:T328012。--BlackShadowG Slava Ukraini! 2023年1月26日 (四) 12:05 (UTC)回复[回复]

电子游戏专题由于评级模板（Template:WikiProject Video games）未使用Template:WPBannerMeta无法查到数据，该专题的评级模板需要修改。目前似乎只有电子游戏专题没使用元模板，看起来没有其它需要修改的评级模板。--BlackShadowG Slava Ukraini! 2023年1月25日 (三) 12:47 (UTC)回复[回复]

此外，由于Template:Class mask和Template:Importance mask使用的是简体，所有目前所有的评级和重要度都以简体录入{{#assessment:}}，不过ACG专题使用的是繁体，可能导致繁体和简体被认为是两个数值，故提议将Template:ACG專題/class和Template:ACG專題/importance也统一为简体。--BlackShadowG Slava Ukraini! 2023年1月30日 (一) 10:31 (UTC)回复[回复]

(＋)支持。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月30日 (一) 11:09 (UTC)回复[回复]

看起来没有反对意见，通知@shizhao：修改Template:ACG專題/class和Template:ACG專題/importance。--BlackShadowG Slava Ukraini! 2023年2月8日 (三) 12:31 (UTC)回复[回复]

看起来shizhao君比较忙，通知其余几位关注本讨论的管理员&模板编辑员@Lopullinen、Ericliu1912、A2569875：请求修改上述模板，感谢！--BlackShadowG Slava Ukraini! 2023年2月9日 (四) 14:48 (UTC)回复[回复]

如果没记错功能，Template:ACG專題/importance的| disambig = na应该也要改成汉字| disambig = 不适用。--洛普利寧 2023年2月10日 (五) 12:59 (UTC)回复[回复]

但是好像現在不改簡繁也OK了。技術人員做了別名處理？--洛普利寧 2023年2月10日 (五) 13:09 (UTC)回复[回复]

@Lopullinen：未見技術人員做了別名處理。所以應該還是要改。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月17日 (五) 05:14 (UTC)回复[回复]

不太清楚是做了别名处理，还是只是Special:页面评级支持了繁简转换，如果是后者，那么存储到数据库中的恐怕还是繁简两个值。--BlackShadowG Slava Ukraini! 2023年2月19日 (日) 02:31 (UTC)回复[回复]

说明一下目前的进度：PageAssessments已经部署到中维，但由于没有及时在phab回应技术人员关于中维是否有工作组的问题，导致在部署时$wgPageAssessmentsSubprojects没有设置，所有工作组的评级都被当作专题的评级存储了。我已经向phab那边说明，但由于数据损坏需要重新存储，现在WMF的技术人员已经修改了（1、2）评级模板，移除了原先的{{#assessment:}}以清空数据库，过几天后技术人员会将其加回。引入机器人的工作也得等到那之后才能进行。

我希望在机器人完成引入并且确认PageAssessments没有任何问题之前，本讨论能一直开启。--BlackShadowG Slava Ukraini! 2023年2月8日 (三) 12:30 (UTC)回复[回复]

已在phab申请引入机器人：phab:T329617。--BlackShadowG Slava Ukraini! 2023年2月14日 (二) 11:47 (UTC)回复[回复]

除了繁简问题，PageAssessments目前看来一切运作正常--百無一用是書生 (☎) 2023年2月17日 (五) 02:16 (UTC)回复[回复]

等待机器人引入后再看效果如何。--BlackShadowG Slava Ukraini! 2023年2月25日 (六) 08:04 (UTC)回复[回复]

我在User:Shizhao/mostread首次尝试用了一下PageAssessments的数据--百無一用是書生 (☎) 2023年3月3日 (五) 08:58 (UTC)回复[回复]

Shizhao和BlackShadowGPageAssessments已经部署很长了，但Popular pages bot还没上架。是meta不批机器人？--洛普利寧 2023年3月25日 (六) 12:57 (UTC)回复[回复]

我是按照meta:Community Tech/Popular pages bot#How it works去phab申請的，但那邊一直沒有回應，不知道為什麼。--BlackShadowG Slava Ukraini! 2023年3月25日 (六) 14:16 (UTC)回复[回复]

可能是在忙今年的社群愿望清单？总而言之，这类请求一直都特别慢，也不知是为什么--百無一用是書生 (☎) 2023年3月26日 (日) 05:48 (UTC)回复[回复]

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

请求修复标题地区词转换错误

冤罪殺機这篇条目使用了{{noteTA|T=zh-cn:羞辱 (游戏);zh-tw:冤罪殺機;|1=zh-cn:羞辱;zh-tw:冤罪殺機;}}，但在大陆简体用词下标题显示为“羞辱”而非“羞辱 (游戏)”，请求修正，感谢。--BlackShadowG Slava Ukraini! 2023年3月5日 (日) 10:28 (UTC)回复[回复]

和上面提到的#目录影响部分条目标题显示应该是同一问题。--Stevenliuyi（留言） 2023年3月5日 (日) 10:50 (UTC)回复[回复]

似乎在旧版Vector也出现了这样的问题。--BlackShadowG Slava Ukraini! 2023年3月13日 (一) 14:57 (UTC)回复[回复]

标题转换最近遇见多个了，使用Timeless皮肤，比如比迪娅·戴维·班达里、苏丹莫哈末五世。--Kethyga（留言） 2023年3月14日 (二) 14:02 (UTC)回复[回复]

@BlackShadowG 好像修复了？--Kethyga（留言） 2023年3月24日 (五) 03:05 (UTC)回复[回复]

似乎还没有。--BlackShadowG Slava Ukraini! 2023年3月26日 (日) 02:49 (UTC)回复[回复]

@BlackShadowG 我上面两个例子都好了，你试试用零编辑看一下。--Kethyga（留言） 2023年3月26日 (日) 02:52 (UTC)回复[回复]

零编辑后没问题了，感谢指点。--BlackShadowG Slava Ukraini! 2023年3月26日 (日) 02:58 (UTC)回复[回复]

小寫標題

重複提問：Wikipedia:互助客栈/技术#目录影响部分条目标题显示。--顏嘉佑（留言｜貢獻） 2023年3月19日 (日) 12:50 (UTC)回复[回复]

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

{{Lowercase title}}似乎有問題，根據模板的說明將之放於{{noteTA}}下方，但是沒有效果。具體見IPhone。--Nostalgiacn（留言） 2023年3月12日 (日) 03:01 (UTC)回复[回复]

和Wikipedia:互助客栈/技术#目录影响部分条目标题显示#目录影响部分条目标题显示是同一個問題，這個問題可以關閉了。--Nostalgiacn（留言） 2023年3月12日 (日) 05:47 (UTC)回复[回复]

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

Global RfC filled to enable global abuse filters on large Wikimedia projects by default

您好!

Apologies for writing in English. 请帮助翻译至您的语言.

On Meta-Wiki, a set of global abuse filters is maintained by Meta-Wiki's administrators and the stewards. Global abuse filters are a powerful tool designed to fight against long-term abusers that operate cross-wiki. It is especially useful (and often irreplaceable by other means) when a cross-wiki LTA starts to rapidly change IP addresses (when that happens, regular blocks are significantly limited due to the IP hopping).

As of today, all small/medium Wikimedia projects (as-determined by number of articles) are automatically subscribed to global abuse filters. They are not, however, enabled on several Wikimedia projects classified as large (except several large Wikimedia projects who opted-in, such as Wikidata). This makes it possible for global long-term abusers to vandalize a project with no global filters enabled, which makes it significantly more difficult for the Stewards to fight against the abuse.

By this message, I'd like to let you know I submitted a global RfC (request for comments), where I propose enabling global abuse filters on large Wikimedia projects as an opt-out feature. This change will make global abuse filters an even more effective tool for combating long-term abuse at the global level. Please feel free to participate in the discussion, which happens at Meta-Wiki.

Thank you for your time.

Sincerely,
--Martin Urbanec (讨论) 2023年3月12日 (日) 17:15 (UTC)回复[回复]

不详尽的翻译：元维基启用了全域滥用过滤器，所有中小型维基项目（根据条目数）默认自动订阅这个过滤器组，大型维基项目除非申请了的（例如维基数据）外都未启用，认为这不利于打击全域破坏者，所以申请了一个全域RFC，提议将在大型维基项目启用这个功能作为选择排除选项，欢迎到元维基参与讨论。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月13日 (一) 00:34 (UTC)回复[回复]

二次省流：有人提出将全域过滤器从自愿加入制，改为默认启用、自愿退出制。--Milky Defer 2023年3月13日 (一) 06:19 (UTC)回复[回复]

需要召唤一些管理员看一下？我看有些本地过滤器实际是引进en版本的，或者少部分可以通用的通过这个机制沿用？但也说了，这会强化全域对本地社群的控制。（It will greatly improve the response to cross-wiki vandalism and spam, while also increasing community control over these global actions.）——Sakamotosan路过围观 | 避免做作，免敬 2023年3月13日 (一) 06:22 (UTC)回复[回复]

@KOKUYO、淺藍雪、Mys_721tx、Kolyma：，很抱歉打扰，因为你们是我用在线管理人员检查看到的。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月13日 (一) 06:31 (UTC)回复[回复]

@Shizhao、Xiplus、Jimmy Xu、Ericliu1912：，很抱歉打扰，因为你们是我想到管理员就会想到能找到的人。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月13日 (一) 06:31 (UTC)回复[回复]

以上有兴趣的去元维基看一下，看是否加入或者退出。如果觉得无关的话，那再次说声打扰了。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月13日 (一) 06:31 (UTC)回复[回复]

我意见是，有多少全域LTA类能打到zh区这边而需要这些过滤器，或者有多少通用的好的过滤器需要通过这种方式引入。从其中一个日志追去当地项目来看，似乎一旦启用，本地无法单独拒绝这些全域过滤器的个别。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月13日 (一) 06:39 (UTC)回复[回复]

我觉得从zhwiki管理现状上来说，能甩出去给别人打理真是减少积压工作的好办法--百無一用是書生 (☎) 2023年3月13日 (一) 07:29 (UTC)回复[回复]

@Shizhao：，但我认为现在这样全局加入再单独剔出的做法可能不够灵活，这个全局过滤器“要么全部不要，要么全部接受”，没法控制特定过滤器在本地的启用禁用。而且我留意到少部分针对特定内容主题的隐藏过滤器存在，一来可能不知道里面的规则怎样写，会不会变成一种另类的使用；二来可能存在语言不适配的问题（可能只针对英文等拉丁语境，而不是针对我们本地的中文等）。一些中小型站点参与人少，为了节省管理人力，可以考虑全部接收（见过de-source是没有本地过滤器了，全盘用全域过滤器），但对于我们大型站点，人手尚足，如果跨站点破坏很少影响到我们（而用不着针对跨站点的过滤器），可以通过单独启用个别全域过滤器来引进一些通用性较强的优质过滤器，可能更好。或者维持现状，大型站点默认不加入，可以单独加入。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月15日 (三) 01:32 (UTC)回复[回复]

我個人覺得能增進反破壞效能是好事。不過對於影響本地的全域隱藏過濾器，是不是考慮推舉幾位本地維基人做濫用過濾器助理之類的，以便查閱？或要求全域社群直接允許本地管理員或特定人士查閱？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年3月21日 (二) 05:42 (UTC)回复[回复]

可以，所以我认为至少全域过滤器能允许有本地私有过滤器查看权限的用户查看（或者对应的功能权限）（这个看了过滤器的权限表，看不出有类似的权限或者功能），和本地控制是否启用的权限，才考虑大型组全入再选择退出，类似的问题很早提出了，但基金会的开发不以为然，至少对于这种问题不能盲目点头。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月21日 (二) 06:34 (UTC)回复[回复]

如果管理員有需要查看全域過濾器，可以申請成為全域的 Abuse filter helpers 或是元維基的受限管理員。另外，目前本站有權限查看全域過濾器的管理員為：Jimmy Xu、Jusjih、Shizhao和WhitePhosphorus，供參考。--SCP-0000（留言） 2023年3月21日 (二) 06:43 (UTC)回复[回复]

@Ericliu1912、Mys_721tx：，en宣告退出了（en:Wikipedia:Edit_filter_noticeboard#Global_abuse_filters_applying_here）。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月21日 (二) 06:38 (UTC)

[2] Jiao, Wenxiang; Wang, Wenxuan; Huang, Jen-tse; Wang, Xing; Tu, Zhaopeng, Is ChatGPT A Good Translator? A Preliminary Study, arXiv, 2023-01-31 [2023-02-11], doi:10.48550/arXiv.2301.08745

[3] 如中国—阿拉伯国家合作论坛、澜沧江—湄公河合作、萨赫勒－撒哈拉国家共同体。

[1]

[dash 1]

维基百科:互助客栈 (全部)

消息