维基百科:徵求意見/全部
以下討論需要社群廣泛關注：（清除緩存）
傳記
[编辑]Wikipedia talk:收錄標準/音樂 § 修訂選秀五強，定義釐清
據知香港選秀節目《聲秀》今晚將進行決賽，其賽制很可能沒有明確的「五強」，加之想起以往因《校花校草2022》參賽者的討論，及設立演藝選秀標準的想法，有人提出了《全民造星系列》會否不屬於音樂選秀節目的迷思，因此提出修訂。
- ※ 此處原有{{CMP}}模板內容，因節省徵求意見摘要篇幅而省略，請至有關討論頁查看
Talk:AJ·李 § 這是英維優良條目，被提報不符收錄標準
經濟、貿易與公司
[编辑]目前此主題無正在討論的議題
歷史與地理
[编辑]Talk:特货贸易 § 关于“非简中环境下大多数时候特货都是关于鸦片贸易，不能以百度搜索标准为准”
Talk:切爾尼戈夫站 (基輔地鐵) § 建議更名：“切爾尼戈夫站 (基輔地鐵)”→“切爾尼希夫站 (基輔地鐵)”
Talk:美国国家森林 § 建議更名：“美国国家森林”→“美国国家林地”
Wikipedia:互助客栈/条目探讨 § 有关于江北区、渝北区、北碚区、两江新区各类条目调整
Module talk:Location map/data/Palestine § RfC：巴勒斯坦國使用的地理位置圖
目前英文維基百科使用File:Palestine location map wide.png（
）作為巴勒斯坦國的位置地圖，範圍包括以色列全境；而Commons上亦存在File:West Bank and Gaza Strip location map.svg（
），其範圍放大至加沙和西岸的周圍地區。個人認為放大後的圖片更加清晰準確，尤其利於巴勒斯坦國世界遺產列表這種需要密集標注的情形，但不清楚社群的偏好。
因此在此開啓RfC，徵求社群關於這一議題的意見：巴勒斯坦位置地圖應——
--Nebulatria 2025年11月11日 (二) 23:01 (UTC)語言及語言學
[编辑]Talk:Transformer架构 § 關於Transformer拼寫的大小寫
@魔琴您好！我注意到您回退了我關於"Transformer"拼寫的編輯。
作為專有名詞，我感覺Transformer保持首字母大寫似乎較優？我參照了以下材料：
- 英文維基[1]：英文維基百科以小寫transformer為主，亦有夾雜句中大寫的情況。
- 提出架構的原論文Attention Is All You Need[2]，其中只有冠以定語（如big，4-layer）時使用小寫。
- DeepSeek V3技術報告[3]，其中只有使用"transformers"（即復數形式）或在前冠以其餘定語（如Enhanced）時使用小寫。
- GPT-4技術報告[4]，正文全部採用大寫T，惟正文提及次數較少，主要出現在引用。
- Llama 3[5]，主要採大寫T，惟“40 transformer blocks”之類地方採小寫。
數學、科學與科技
[编辑]Talk:中日韓統一表意文字 (Unicode區段) § 是否应该改标题为「中日韩统一表意文字基本区」？
Talk:Transformer架构 § 關於Transformer拼寫的大小寫
@魔琴您好！我注意到您回退了我關於"Transformer"拼寫的編輯。
作為專有名詞，我感覺Transformer保持首字母大寫似乎較優？我參照了以下材料：
- 英文維基[7]：英文維基百科以小寫transformer為主，亦有夾雜句中大寫的情況。
- 提出架構的原論文Attention Is All You Need[8]，其中只有冠以定語（如big，4-layer）時使用小寫。
- DeepSeek V3技術報告[9]，其中只有使用"transformers"（即復數形式）或在前冠以其餘定語（如Enhanced）時使用小寫。
- GPT-4技術報告[10]，正文全部採用大寫T，惟正文提及次數較少，主要出現在引用。
- Llama 3[11]，主要採大寫T，惟“40 transformer blocks”之類地方採小寫。
媒體、藝術與建築
[编辑]Module talk:CGroup/音樂劇 § 音樂劇、歌劇、話劇等轉換組應分立抑或合體？
音樂劇（現有）、歌劇（未建）、話劇（未建）等應否分立各轉換組？或是以本組為基礎擴建為舞臺劇轉換組？
若能實現子板塊的設想，並能將各劇種轉換組設爲舞臺劇轉換組（相當於容器／空殼）的子板塊，似乎是以各劇種分立轉換組爲宜？
但若不能實現子板塊的設想，則合為一個轉換組更便利？--— Gohan 2025年10月28日 (二) 08:39 (UTC)政治、政府與法律
[编辑]目前本条目对国家的定义/解释是“广义而言，国家是指拥有共同的语言、文化、种族、宗教、领土、政权或历史之社会群体；狭义而言，国家为一定范围内的人群所形成的共同体”。这一说法确实常见，但我认为这样的表述无法区分一个群体是国家或不是国家。国家符合上面条件，但符合上面条件的不一定是国家。虽然使用国家一词并不总是有关政治，但对国家的界定似乎总与政治有关。我们只会说有政府的或者有主权的是国家，现实生活中我们不会因为有着共同的语音文化什么的就去说它是一个国家。（基于本人阅历，也有可能是个人所在地区地缘政治紧张才导致。我个人是真没见过其他用法的，不同的感受欢迎补充）
我尝试网上查询一些词典，供大家参考，我感觉是符合实际运用的：
漢典：1.長期佔有一塊固定領土,政治上結合在一個主權政府之下的人民的實體;一種特定形式的政府、政體或政治上組織起來的社會 2.由一個民族或多個民族組成並且具有或多或少確定的領土和一個政府的人民的共同體 3.由人民共同體所佔據的土地
（忽略所谓阶级压迫的工具这类用法）--SoAnnoyedToName（留言） 2025年8月17日 (日) 16:36 (UTC)Talk:臺灣光復節 § 有關臺灣光復節移動到臺灣光復日一事，想確認是否有共識
臺灣光復節一條目，在2025/10/25移動到臺灣光復日，我覺得這不是小修改，我想應該要在維基人有共識的情形下再修改。
"臺灣光復節"是中華民國以前對此節日的正式名稱，在2025年已更名為"臺灣光復暨金門古寧頭大捷紀念日", 不過在台灣仍習慣使用"臺灣光復節"此一名稱。
"臺灣光復日"是2025年10月時，中華人民共和國所訂立節日的名稱。
我覺得在沒有討論的情形下，將兩個政權下的節日直接移動到某一政權較晚才訂立的節日，是不合適的。（另外，依上述所述，我不贊成此一移動）
因此希望可以得到大家的意見，另@静魔魔女：，謝謝大家--Wolfch (留言) 2025年10月25日 (六) 05:59 (UTC)Talk:2025年沙巴选举 § 建議更名：“2025年沙巴选举”→“2025年沙巴州选举”
宗教與哲學
[编辑]不想一個邏輯學條目的頁面，居然帶有那麼多私貨。
邏輯教材應盡量選用中性、清楚、且容易理解的例子，避免政治、文化、性別爭議。
將焦點限定在邏輯結構上，不暗帶風向。
先釐清定義：
起源謬誤（genetic fallacy） 指在評斷某一主張時，因為它的「來源」或「背景」就予以贊成或駁斥，卻不去檢視這個主張本身的內容與證據。
例如：清清楚楚，無涉爭論。「這理論是拖鞋黨提出的，所以一定錯。」
或
「這藥是古希臘發明的，所以一定好。」
現下頁面的三個舉例，不僅有攜帶私貨之嫌，例一和例二甚至自帶邏輯形式上的問題。
勘誤結果： 乙並未否定「嘉南大圳提升生產力」這一事實命題，而是在進行價值層面的判斷：甲：「嘉南大圳造福了台灣西南部地區，使當地的農業生產力大增」
乙：「別忘了嘉南大圳是日據時代的產物，而設計嘉南大圳的人八田與一是大日本帝國軍國主義的支持者，崇拜一個軍國主義者搞出來的東西，說明了你根本是個皇民。」
乙認為甲不該贊同嘉南大圳，但他的論述是嘉南大圳起源自日本軍國主義支持者八田與一，而不是從事實和學理來說明為何嘉南大圳不該受激賞；另外乙在後半段稱甲是「皇民』這點可能涉及人身攻擊。
如上所述，乙方的反駁，針對的不是「事實命題（是否造福）」而是「價值命題（是否應被稱頌）」。 這不是什麼起源謬誤，如果乙的主張是：「嘉南大圳帶有殖民性與軍國主義色彩，因此不該被歌頌。」
或
「即便有功效，但它帶有殖民性與軍國主義色彩，因此不該被歌頌。」
那樣才是典型的起源謬誤。「因為八田與一是殖民者和軍國主義者，所以嘉南大圳並沒有造福農業。」
此處乙談的是道德層面的正當性，屬於倫理價值辯論範疇，不構成邏輯謬誤。
⚠️ 條目頁面在此誤將「價值觀之爭」視作「邏輯謬誤」，這是類型錯置（category mistake）。
除此之外，還有很多問題。
例如「激賞」不是中文的日常用語，「日據時代」、「八田與一」、「軍國主義」、「大日本帝國」、「皇民」……
一個那邏輯學的小頁面，放那麼多和邏輯學無關的內置連結，不妥當。
最後它還是個「混雜型」的例證，涉及人身攻擊（ad hominem）和 情感訴求（appeal to emotion），教學上容易混淆焦點。
例證二：Ben Barres勘誤結果：「Ben（Ben Barres）今天的演講真的很棒，不過他的研究實在比他作為女生的妹妹（Barbara Barres）好太多了。」 起源自女生的研究不表示比起源自男生的研究差，這除了訴諸起源外，亦為訴諸性別；況且Ben和Barbara其實是同一人。[1]
這句話在中文來講有語病，英文原文是“Ben Barres gave a great seminar today, but then his work is much better than his sister's.”
從譯句上看，存在不少問題：不合中文的表達習慣、「不過」的轉折邏輯不通順、缺乏上下文背景等。
綜合起來，很不明瞭，說到上下文背景，那就更複雜了。
事實上Ben Barres在該領域內（神經生物學）沒有一個妹妹，他是一位轉性者。
當初編寫這段的人，顯然也知道一些內情，所以註明Ben和Barbara其實是同一人，還專門加了來源：再次說明，根據網絡材料，Ben Barres在真實世界中，有兩個姊妹和一個兄弟，但沒有一個做相關科研的妹妹。一位跨性別科學家之死 – 記 Dr. Ben Barres. [2022-02-13]. （原始內容存檔於2022-02-13）.
本人是同情並支持，提高人們對於同性乃至轉性，這方面的公共探討和社會認知的。
但是我反對，故意把相關課題，植入一個邏輯學科普頁面的做法。
畢竟真實的情況和例句的陳述，太容易引起誤解和爭執，要考慮到這一層。
若要用於邏輯教材，應該改寫為：這樣才能準確展示「以性別作為研究品質依據」的邏輯謬誤。「你知道那個Barres吧？他現在變成男人後，研究比以前當女人時好多了。」
補加一句，「性別偏見（Gender Bias）」和「訴諸性別謬誤（Appeal to Gender）」會導致起源謬誤。
綜上所述，例二雖涉及爭議性議題，經過文句的修改後，是可以作爲起源謬誤（Genetic Fallacy）的一個舉例。
要不要保留，可置於公論。
例證三：「女子無才便是德」勘誤結果：甲：「這句『女子無才便是德』根本是歧視女性的用語，希望大家以後不要再使用。」
乙：「但『女子無才便是德』本來的意義不是歧視女性，而是勸女子要以德行為主，不要忘了原文的上句是『男子有德便是才』。」
乙藉由聲稱「女子無才便是德」在最一開始時並無歧視女性的意思這點來試圖辯駁甲的說法。
甲的發言，認為「女子無才便是德」從**根本**上就是歧視的用語。
乙的回應，也是從**根本**來和甲討論，該句話是否一定就是歧視用語。
由於甲既沒有確定時代語境，也沒有提供前因後果，可能會被解讀爲，這句話本質上、從起源到現代都是歧視女性。
乙恰好補充了時代背景，並試圖引入時間的語境因素，他的回應，是切題的且針對性的，更是因於命題的內容本身所展開的。
在學理上，乙的回答是一種標準的語用辯證（pragmatic clarification/pragmatics）:相反，如果乙說：Pragmatics is the study of how context contributes to meaning 語用學是研究語境（context）如何影響意義的學科
這才是起源謬誤，即錯誤地假設一個事物（例如一個詞、一句話或一個概念）的起源，會必然決定它現在的性質、意義或價值。「因爲古人原本沒有歧視意圖，所以這句話任何時候都不可能是歧視。」
例三話題的核心，就在一句古話到底什麼性質、意義或價值的認定上。
而這方面的認定（焦點對象是一句話），離不開語境的討論。
英文版的頁面上，有個相似的例子，用它倒是可以很好地訓練我們的思維並甄別：婚戒是物件，古話是言語，不相同。You're not going to wear a wedding ring, are you? Don't you know that the wedding ring originally symbolized ankle chains worn by women to prevent them from running away from their husbands? I would not have thought you would be a party to such a sexist practice. 你不會真的要戴婚戒吧？你難道不知道，婚戒最早象徵的是女人腳上的鎖鏈，用來防止她們逃離丈夫嗎？我真沒想到你也會參與這樣帶有性別歧視的做法。
婚戒的性質、意義或價值，在當事人，並不代表防止女方逃跑的腳鐐，而且他也未必知道這一典故（可視為編撰者的一種幽默，婚戒起源於腳鐐是個梗），所以不能以他不知道的一個起源，來冤枉他有性別歧視。
一句話的性質、意義或價值，卻不是孤立，隨便可以被賦予意義的，現代語義往往承接古代語義。
假如有人討論古代原意，提供歷史背景，分析語源。
這不是什麼起源謬誤，而是讓對方理解語義演變的脈絡，幫助判斷現代用法是否仍有歧視意味。
任何一句話的定性，必然要有語境，否則便是空中樓閣。
反觀甲先以自己的道德標準直接判定古語為「歧視」，反是「語境忽略謬誤」的絕佳例子：上面明顯是一種武斷式的價值判斷，缺語境。 那我們幫他圓個場，拿掉「根本」兩字，再加入現代語境的標註，看看會發生什麼：甲：「這句『女子無才便是德』根本是歧視女性的用語」
發現沒有，仍嫌是一種過於武斷式的價值判斷。甲：「這句『女子無才便是德』在當代來說是歧視女性的用語」
我們會這樣覺得，衹因爲我們心底下多少曉得一點，語言的性質。
最後，我們來復習一下，為什麼乙的回答不構起源謬誤（Genetic Fallacy）：拿一個涉及語句語境解析的例子來教「起源謬誤」，豈不笑話？乙沒有否定現代語境中可能的歧視現象，他衹是討論了語源事實。
乙沒有說「既然原始意義不是歧視，所以今天也不能說是歧視」。
補充語源與語境，是對一句話本身內容的直接討論，有助於判斷其真實語義。
它本身就犯了語境忽略謬誤（Contextomy）的問題，並且過度解讀（Over-Interpretation）。
若按此例，語境忽略謬誤和起源謬誤兩種非形式謬誤，甚至會相互抵牾。
綜合以上：
例證一、例證三本身存在邏輯缺陷，讓別人誤以為「乙犯了邏輯謬誤」。
教材本意是教「起源謬誤」，摻雜那麼多爭議，這究竟是邏輯教學，還是意識形態的輸出?
檢視歷史，有編輯者移除了其他相對單純、中立的示例，考慮到大規模改動，可能會引發編輯戰，先付與社區討論。
畢竟一個教人邏輯謬誤的頁面，本身不能充滿邏輯謬誤吧？
--Bluewhalie（留言） 2025年10月31日 (五) 20:10 (UTC)社會、體育運動與文化
[编辑]維基百科格式與命名
[编辑]Wikipedia talk:命名常规 § 重提在條目標題中正確使用書名號
Wikipedia talk:消歧义 § RfC：考慮将消歧義括号修正为中文括号
Wikipedia talk:格式手册/信息框 § 国籍应按主动认领国籍来算
我认为在格式手册的两岸四地及信息框等分页应增加描述，表面国籍应按主动认领且被承认有效的国籍来算，不能且不用添加法律条文上理论上存在，但个人并未真正使用的国籍。
Talk:特货贸易 § 关于“非简中环境下大多数时候特货都是关于鸦片贸易，不能以百度搜索标准为准”
Wikipedia talk:命名常规 § 日本寶塚歌劇團人物的條目名移動再確認
維基百科方針與指引
[编辑]Wikipedia talk:命名常规 § 重提在條目標題中正確使用書名號
Wikipedia talk:游戏维基规则 § 提议将WP:游戏维基规则改名
Wikipedia talk:新条目推荐/候选 § 對於缺票和水票的改革方案
依據上面的共識，先給出如下「半共識制」DYK評選方案，請大家敲定細節。此方案類似典優半共識制，但流程簡易許多，有益於降低社群參與和維護門檻。
主要變化：「7日投票期」縮減為「無票不限期」+「有票限期5日」；通過票數由「4票」縮減為「1+1票」（可由同一人投）；強調了「按照方面檢查」，強調評審者對投票背書。
- ※ 此處原有{{比較條文}}模板內容，因節省徵求意見摘要篇幅而省略，請至有關討論頁查看
Wikipedia talk:生者傳記 § 將生者傳記方針的適用範圍擴大到最近逝世者
Wikipedia talk:消歧义 § RfC：考慮将消歧義括号修正为中文括号
Wikipedia talk:申请成为管理人员 § 集中選舉廢除「提名區」，代以「報備區」
本次集中選舉中，由於依然存在「提名區」，仍存在不少「隔空喊話」的情況，甚至因此產生誤會，導致提名無效。爲矯正這一點，建議廢除集中選舉討論中的「提名區」；但考慮到社羣會預期所有消息都能在討論串中接收到，建議改設「報備區」，建議規定如下：
- 自薦者應自行創建申請頁，並於「報備區」內通知社羣；
- 若欲提名其他編者，則須先私下（站內用戶討論頁或站外）詢問意向，獲得同意方可建立申請頁，並於「報備區」內通知社羣。若意向詢問在站內進行，可張貼相關連結；若在站外進行，被提名者須在申請頁確認接受提名。（強烈建議被提名者亦於「報備區」內通知社羣；若被提名者未作出通知，他人可代爲轉達，但不影響提名有效性。）若該提名其實未獲同意，被提名者可以改爲拒絕提名，申請隨即關閉。被提名者回覆的期限，仍從WP:NBC之規定，定爲三天；逾時而未回覆，視同拒絕提名。
- 本提議中，「卡時間提名」的問題並不存在——創建申請頁的時間視爲申請時間，若回覆期部分處於提名期後，在提名期過後回覆也沒有問題。WP:NBC定義的三天時間也和現行集中選舉基本問題回答的72小時限期相容。
- 「報備區」不宜作與報備提名無關的留言，也不應用作「隔空喊話」邀請參選。若希望發起對提名的討論，宜前往該提名的「意見」區；若涉及多個提名，則可使用集中選舉討論的「討論區」。
Wikipedia talk:命名常规 § 建議在使用常用名稱章節明文規定傳主更名後，原則上不能立即移動條目到新名稱
建議在使用常用名稱章節明文（註釋或次一級標題皆可）規定「即使有可靠來源證實人物條目的傳主已更換本名、藝名或筆名，也不能立即移動條目到新名稱，除非新名稱已明顯比舊名稱常用」，以貫徹「使用常用名稱」原則。
話說今天我才看到臺灣藝人馬國畢更換藝名為馬國弼的消息（這件事到底有多少人知道？），到維基一查，果然馬國畢早已被移動到馬國弼了。竊以為這種一看到更名新聞，不管三七二十一就立即移動條目的行為顯然違反使用常用名稱原則，我自己也做過這種事，認為這樣不對，所以希望明文禁止之。---游蛇脫殼/克勞棣 2025年10月6日 (一) 03:17 (UTC)Wikipedia talk:格式手册/信息框 § 国籍应按主动认领国籍来算
我认为在格式手册的两岸四地及信息框等分页应增加描述，表面国籍应按主动认领且被承认有效的国籍来算，不能且不用添加法律条文上理论上存在，但个人并未真正使用的国籍。
Wikipedia talk:編輯戰 § Wikipedia:編輯戰#更嚴格的回退限制和Wikipedia:仅在必要时进行回退循环引用
在Wikipedia:編輯戰#更嚴格的回退限制中写道“在一些争议议题或编者间出现编辑争议时，社群或会采取更为严格的回退限制，譬如回退不过一（1RR）或回退零容忍（0RR），进一步限缩编者在争议中判定为编辑战的明确界限。即使未有明确规定或社群共识，编者也可自愿遵守更严格的回退限制，作为自己的编辑原则或用以应对特定争议领域的问题，详情请参阅维基百科:仅在必要时进行回退”，然而在Wikipedia:仅在必要时进行回退中却写道“当意识到持续的回退操作已经使得条目发展停滞时，各方应当对其他人的编辑给予超出平常的尊重。并不像“回退不过三”原则，这样的规则是自愿、自律的。对于这些规则适用的情况，参见其他回退规则”
也就是说，社群目前的确将0RR和1RR作为方针，但是没有写明使用情况--Gaolezhe（留言） 2025年10月17日 (五) 13:36 (UTC)Wikipedia talk:申请成为管理人员 § RFA頁面的用戶名稱是否應該更新
Wikipedia talk:不要带着正义感义愤填膺地编写维基百科 § 升为指引如何？
Wikipedia talk:封禁 § 仲裁及Unblock-zh.org相關事實適應性修訂
Wikipedia talk:封禁 § 临时账号封禁建議，及标记用户页的豁免情况
之前在有些群组中看到过有关封禁临时账号的讨论，此外我还觉得有些标记用户页的时的设置可能有点问题，因此在这里提请对封禁方针做出一些修订，详情见下。
请各位分别对1，2两条进行表态。此外，各位也可以适当的对一些表述不太恰当的位置或者说对要求重点标记的格式进行修改。谢谢各位。（主要是我时间不够……）--浅村しき（留言・来签个名吧） 2025年10月19日 (日) 15:23 (UTC)Wikipedia talk:管理員的離任 § 修订管理員的離任指引
Wikipedia:徵求意見/2025年管理人員制度改革中的议案6B和6C是关于管理员离任的修订，其中6B有修订共识但对于具体拟议条文结论并不明确；6C已有明确共识，可以直接进行公示。议案6B与管理人員活跃度标准有关。征集意见的结论显示主流意見認為應上調活躍度要求，但在具體方案上存在分歧。一方認可改為六個月十次操作，一方傾向加入長期活動標準。鑒於後者更能保證管理員的安全性+活躍度，故此採用後者……但對於具體規定仍存在爭議
。
- ※ 此處原有{{CMP}}模板內容，因節省徵求意見摘要篇幅而省略，請至有關討論頁查看
Wikipedia talk:草稿命名空间 § 提议：添加如何将草稿变成正式条目的指南
我在维基上从英文站翻译条目到中文站的时候，遇到过这个问题。增加这段有助于像我这样的萌新更方便地写新条目
- ※ 此處原有{{比較條文}}模板內容，因節省徵求意見摘要篇幅而省略，請至有關討論頁查看
Wikipedia talk:討論頁指引 § 引入英维折叠讨论中明显LLM文本的做法
英语维基的TPG今年加入了允许划去或折叠他人明显由LLM生成的留言的条款en:WP:AITALK（RFC、编辑请求），并提供了折叠模板en:Template:Collapse AI top。
鉴于本站也有在讨论中使用疑似由LLM生成的大段文本的现象（例如在WP:ANM等管理员布告板以及页面存废讨论），我认为值得引入此规则。相关用户见到发言被折叠后或许会收敛，因此在维持版面整洁的同时也能起到吓阻作用。目前本地用途类似的模板有{{TalkH}}（虽然不算常用），或许可将功能并入该模板；直接引入英维的Template:Collapse AI top亦可。--Srapoj（留言） 2025年10月24日 (五) 11:15 (UTC)Wikipedia talk:人工智慧 § 考慮將此資訊頁升為正式指引
Wikipedia talk:申请成为管理人员 § 釐清行政員及仲裁委員會於管理人員申請事宜的權責
仲裁案引起對行政員及仲裁委員會在管理人員申請過程中各自角色的疑問，謹此發起討論以作釐清。
簡而言之：建議明文化行政員「行政處分」之權，允許對拉票等導致投票結果失真的情況無效處分，以及在情況存疑或候選人申請期間失信的情況作臨時處分後轉交社群或仲委會商議；涉及隱密證據時交由仲裁委員會處理。而不論行政員或仲裁委員會，除投票結果失真之情況外，均無權宣告投票結果無效；惟仲裁委員會在必要情況可實施禁制，防止濫用者獲取權限，或轉交社群討論產生共識推翻投票結果。
--路西法人 2025年10月28日 (二) 01:15 (UTC)Wikipedia talk:行政员 § 明確行政員權力範圍
如同上方對《管理人員申請方針》的提議修訂中所述，當前行政員之權力模糊不清。謹此建議修訂《行政員方針》，明確行政員具「總結、解讀及執行共識」權，並將往例中的部分裁量權明文規範成「行政處分」權，詳情如下：
- ※ 此處原有{{比較條文}}模板內容，因節省徵求意見摘要篇幅而省略，請至有關討論頁查看
Wikipedia talk:维基百科不是什么 § 提案修正WP:BALL反應未來條目的行文
問題源自Wikipedia:頁面存廢討論/記錄/2025/10/27#北橫快速道路這邊。我發現「維基百科不是占卜師」的方針，在反應部份未來相關的條目（如台湾海峡通道）力有未逮，可能需要同步英維修改。暫時想這樣修正：
--Saimmx（留言） 2025年10月29日 (三) 08:56 (UTC)Wikipedia talk:傀儡 § 補充對於用戶被軟封鎖後另創帳戶並不違反傀儡方針的事實性修訂
根據Wikipedia:封禁#常見封鎖類型，對註冊用戶的軟封鎖僅禁止該特定帳號編輯而不影響其使用的IP地址。此設置適用於封鎖宣傳性用戶名及其他違反用戶名方針的情況，容許其建立符合用戶名方針的新帳號或繼續以IP編輯。
目前傀儡方針「被容許使用多重帳戶的行為」一節中並未提及此類狀況。在下對相關章節提議添加事實性修訂。先行根據英文維基百科的條文進行翻譯，條文如下：
--aqurs 🍧 2025年10月29日 (三) 15:08 (UTC)
Wikipedia talk:快速删除 § 擴展G15以包含被全域隱藏用戶的用戶自治空間
最近遇到Jimmy-bot以G15提刪LTA:XTX傀儡的用戶討論頁，發現是因爲監管員全域鎖定時全域隱藏了用戶名，而非賬戶本來不存在。嚴格上，既然用戶其實存在（技術上並無刪除或更改用戶名），應不屬於「孤立頁面」，但又確實毫無保留的必要，非時常跟蹤元維基請求進展的用戶更無法得知此用戶的存在。因此，建議擴充G15，以涵蓋被全域隱藏的用戶的用戶自治空間：
- 修訂一：接納Ericliu1912的逕行編輯，精簡擬議條文。2025年11月5日 (三) 16:18 (UTC)
- ※ 此處原有{{比較條文}}模板內容，因節省徵求意見摘要篇幅而省略，請至有關討論頁查看
Wikipedia talk:列明来源 § 希望再檢討原地更新的來源的規定
偶然得知在本年7月通過了新增的Wikipedia_talk:列明来源#原地更新的來源條文，當時沒有參與討論，但看後有以下疑惑：
- 我一直有個常想發問的小問題，既然現在指引提到有關事宜，建議確定答案後直接註明。這個疑問是關於訪問日期，在一些情況下，編寫及加入來源的日期比網址失效或網頁內容更新還要晚，例如該來源本是其他條目中的已備份來源，或是編者自己從Internet Archive掘出來的，換言之所看到的是依靠前人的備份而獲得的舊版本，這種情況下訪問日期應該填寫加入來源的日期還是備份日期？按避免誤導的原則我相信是備份日期。
- 沒誤會的話，條文以強制的口吻要求編者在引用「聲稱或表現出原地更新行為」的網頁作為來源時同時做兩件事，意味着沒有做那兩件事的編者將有違反指引之嫌。其一是填寫訪問日期，這很簡單，其二是對當前網頁版本進行備份，提醒需要這樣做固然是好事，條文以三言兩語描述此要求，好像看完這句話後是個正常人都自然做得來，就如填寫訪問日期一樣，然而我看網站備份這回事說難不難，但說易也不易，沒經驗的人可能會感到為難，覺得自己想加個來源也舉步為艱（就算有經驗的人也未必永遠得心應手，見下文），若指引沒有附帶足夠解釋及經驗分享，恐會對新手造成不公，或又成為一種向新手施下馬威的工具。最好別強制。
Wikipedia talk:收錄標準/音樂 § 修訂選秀五強，定義釐清
據知香港選秀節目《聲秀》今晚將進行決賽，其賽制很可能沒有明確的「五強」，加之想起以往因《校花校草2022》參賽者的討論，及設立演藝選秀標準的想法，有人提出了《全民造星系列》會否不屬於音樂選秀節目的迷思，因此提出修訂。
- ※ 此處原有{{CMP}}模板內容，因節省徵求意見摘要篇幅而省略，請至有關討論頁查看
Wikipedia talk:申请成为管理人员 § 修訂自由提名下公開投票之執行規範
當前社群已恢復允許用戶自由提名申請管理人員職位，惟在思考有關上方異常處分的情況時，注意到完全遺忘了自由提名的存在。以過往自由提名的運作機制，分列「支持」、「反對」及「中立」三段，且用戶投票時使用有序列表標記，點票上是很方便，但也同時方便了過往看着投票情況去拉票的不當操作，還變成「分派」的情況，加深社群分裂。由此，建議未來的公開投票的運作有以下修訂：
- 不再分列「支持」、「反對」及「中立」三段；社群成員不論意向為何，一律在「意見區」段發表。就算還沒能實行共識制申請，但比起單純的民意調查，起碼看起來像是一個討論，而不是一個純粹的投票。
- 在意見（投票）區禁用以顏色、放大文字方式過度強調投票意向的投票方式。投票意向僅可（也應該）用粗體展現（可以通過CSS把以上投票模板前面的上色部分去除達成），也是方便最終點票，但儘量使滾動式點票拉票變得較為困難，在更大程度上避免看着投票結果拉票的情況。
- 因以上調整，使用有序列表標記已無意義，故全面改用無序列表；另停用自動滾動剖析投票結果，意同上。
Wikipedia talk:檔案移動員 § 提议修改WP:FILEREDIRECT
Wikipedia talk:命名常规 § 日本寶塚歌劇團人物的條目名移動再確認
Wikipedia talk:游戏维基规则 § 修訂WP:遊戲維基規則之中利用微小錯誤的部分
Wikipedia talk:生者傳記 § 在姓名隐私里正式引入en的mos内容的性少数隐私部分
Wikipedia:互助客栈/方针 § 移除对Tor用户获得自动确认的额外限制
长期以来对于使用Tor进行编辑的用户，存在一种额外的限制约束他们获得自动确认状态。相较于其他用户在“注册达7天+编辑达50次”即可获得自动确认，通过Tor编辑的用户需要“注册达90天+编辑达100次”才能获得自动确认。
这一限制的必要性有待商榷：欲通过Tor编辑必须要申请IPBE权限，这意味着Tor用户必然实现经过了或多或少的人工确认。可能有用户认为“使用Tor的用户是破坏者的可能性更高，所以提高门槛存在必要”，但是我认为对于本站来说找不到支撑这个论点的证据。移除这一限制的另一好处是让判断一名用户有无获得自动确认更加简单，减少了一些可能的误解。结合其他社群来看，英文维基百科近期将这个额外限制移除了。
综上，建议本站移除对Tor用户获得自动确认的额外限制，让使用Tor进行编辑的用户也能在“注册达7天+编辑达50次”后获得自动确认状态。请求社群讨论，谢谢。 Stang1163 2025年11月14日 (五) 09:15 (UTC)維基專題與協作
[编辑]Wikipedia talk:新条目推荐/候选 § 對於缺票和水票的改革方案
依據上面的共識，先給出如下「半共識制」DYK評選方案，請大家敲定細節。此方案類似典優半共識制，但流程簡易許多，有益於降低社群參與和維護門檻。
主要變化：「7日投票期」縮減為「無票不限期」+「有票限期5日」；通過票數由「4票」縮減為「1+1票」（可由同一人投）；強調了「按照方面檢查」，強調評審者對投票背書。
- ※ 此處原有{{比較條文}}模板內容，因節省徵求意見摘要篇幅而省略，請至有關討論頁查看
Wikipedia talk:新条目推荐/候选 § 新條目推薦評選中的支持票會因「投票內容與條目或DYK問題無關」而無效嗎？
Wikipedia:互助客栈/技术 § 介绍：WebFont-ZH服务及小工具
各位维基人好，
针对本站生僻字（不包括Unicode未编码字）的显示问题，我提供了以下基于网络字体的全栈解决方案。（大致技术思路在上方也有阐释。）
- 后端：WebFont-ZH
WebFont-ZH是一个智能字体文件子集化分发、缓存平台，主要用来提供单字符字体分发，同时支持请求多字符字体。服务目前部署于Toolforge Kubernetes，技术栈使用Rust+Tokio+Axum，查看源代码仓库以了解API断点及实现。
- 前端：僻字小工具
僻字小工具（unihan-helper）支持为页面{{僻字}}获取并应用WebFont-ZH服务提供的网络字体。小工具集成了既有僻字弹窗工具的功能，同时具有以下特性：
-
弹窗外观（浅色） -
默认设置界面（浅色） -
启用网络字体的设置（浅色） -
启用网络字体的设置（深色）
_(zh-hans).png){kind=small}
_(zh-hans).png)
_(zh-hans).png)
_(zh-hans).png)
- 👋 鸣谢
感谢Shizhao阁下和他创作的webfont小工具；Shizhao阁下热心技术交流，无保留地提供了宝贵的技术启发。项目后端采用cn-font-split计划改编的工具库；前端架构参考了diskdance阁下创作的增强版跨语言链接工具，并使用HanAssist进行繁简转换。同时感谢参与上方讨论的诸位。
有很多维基人曾提出过与本项目类似的技术构想：Great Brightstar（2013年）、Xiaoxiangquan（2014年）、Beetshaw（2014年）、Interaccoonale（2024年）及T33791工单的参与者等。其中Xiaoxiangquan阁下为研究做出了开创性贡献，提供了完整的字体子集化实现。限于本人精力和才识，索引并不完全，对相关维基人一并表示感谢。（以上均为unping。）
- 🗺️ 下一步做什么？
放在这里可能不太合适，不过若您对此感兴趣，欢迎和我一起进一步讨论：
- 实现动态豆腐块检测。支持在检测本地字体无法显示后，再动态引入网络字体。
- Lua重构{{僻字}}，提供更智能的样式分配并完善追踪分类机制。
- 可能需申请Cloud VPS，字体缓存托管到对象存储，以支撑本站的流量。当然，必要性待研究。
现请社群讨论，望：部署僻字小工具，最终预设为所有用户开启。推荐以“试行代公示”的方法施行。部署方法：可直接使用release的产物。因本人在Beta Cluster申请权限未果，无法在与本站相似的环境中测试；又因有检验后端服务承载力的需求；所以试行阶段，可先将本工具置入“测试与开发中的工具”中，并设置稍长的试行时间以便广泛测试。考虑读者视觉体验，建议默认设置采用遍黑体字体并以网络字体“覆盖系统字体”。
针对CSP和隐私相关，单独说明：对于预设小工具能否请求Toolforge托管之资源，基金会似未命令禁止。你或许可称为处于灰色地带😂，但我觉得他们制定CSP的本意主要不是想制裁这种情况。维基人理解并承认，本小工具的原理是按需构建font-face的CSS样式，其中在src调用托管在Toolforge的woff2字体文件。（为什么托管在Toolforge，因为commons不让托管字体文件，ULS webfont也被叫停了。）因为加载外部字体的关键逻辑直接由开源的前端脚本通过CSS实现，基本不可能导致传统意义的跨站脚本（XSS）攻击。此外，服务端遵循Toolforge规则，并以Apache-2.0协议开放源代码，不会记录使用者IP、UA等；在Toolforge本地产生的数据（包括字体文件），在Toolforge本地处理，不会被传输到非WMF站点。如果社群认为跨站请求Toolforge托管的字体不能接受，小工具还是能用的，可将默认设置改为不请求网络字体，用户可自行启用，效果如上图所示。
其他Q&A：
- 为什么不使用Glyphwiki之数据？这就是真的不符合CSP了；同时希望字体风格统一，且黑体优先，故使用开源字体项目。
- unicode缺字怎么办？我的构想在上面，未在本项目考虑空间。
- 如何支持其他wiki和非{{僻字}}模板情况？目前设置为所有class为
inline-unihan的span生效。这也是为什么不急着改造{{僻字}}。
WikiProject talk:維基百科發展/新手2023 § 几个论坛如何存档
挂{{Historical}}的话，会不会还有新手挖坟（？。英维有个en:Wikipedia:Historical archive作集中存档，本地能否效仿？
“几个论坛”是指：--PexEric 2025年11月2日 (日) 08:26 (UTC)維基百科技術議題與模板
[编辑]Template talk:新增條文 § 新增條文和刪除條文的暗色模式問題
爲解決{{新增條文}}和{{刪除條文}}在暗色模式下的顯示問題，現提議修改這兩個模板以適配暗色模式，有兩個方案，演示如下：
|
一般檢視，修改前後應無分別。上至下：
|
|
暗色模式，上至下：
|
Module talk:Delete § 編輯請求 2025-10-25
Wikipedia:互助客栈/技术 § 介绍：WebFont-ZH服务及小工具
各位维基人好，
针对本站生僻字（不包括Unicode未编码字）的显示问题，我提供了以下基于网络字体的全栈解决方案。（大致技术思路在上方也有阐释。）
- 后端：WebFont-ZH
WebFont-ZH是一个智能字体文件子集化分发、缓存平台，主要用来提供单字符字体分发，同时支持请求多字符字体。服务目前部署于Toolforge Kubernetes，技术栈使用Rust+Tokio+Axum，查看源代码仓库以了解API断点及实现。
- 前端：僻字小工具
僻字小工具（unihan-helper）支持为页面{{僻字}}获取并应用WebFont-ZH服务提供的网络字体。小工具集成了既有僻字弹窗工具的功能，同时具有以下特性：
-
弹窗外观（浅色）
-
默认设置界面（浅色）
-
启用网络字体的设置（浅色）
-
启用网络字体的设置（深色）
- 👋 鸣谢
感谢Shizhao阁下和他创作的webfont小工具；Shizhao阁下热心技术交流，无保留地提供了宝贵的技术启发。项目后端采用cn-font-split计划改编的工具库；前端架构参考了diskdance阁下创作的增强版跨语言链接工具，并使用HanAssist进行繁简转换。同时感谢参与上方讨论的诸位。
有很多维基人曾提出过与本项目类似的技术构想：Great Brightstar（2013年）、Xiaoxiangquan（2014年）、Beetshaw（2014年）、Interaccoonale（2024年）及T33791工单的参与者等。其中Xiaoxiangquan阁下为研究做出了开创性贡献，提供了完整的字体子集化实现。限于本人精力和才识，索引并不完全，对相关维基人一并表示感谢。（以上均为unping。）
- 🗺️ 下一步做什么？
放在这里可能不太合适，不过若您对此感兴趣，欢迎和我一起进一步讨论：
- 实现动态豆腐块检测。支持在检测本地字体无法显示后，再动态引入网络字体。
- Lua重构{{僻字}}，提供更智能的样式分配并完善追踪分类机制。
- 可能需申请Cloud VPS，字体缓存托管到对象存储，以支撑本站的流量。当然，必要性待研究。
现请社群讨论，望：部署僻字小工具，最终预设为所有用户开启。推荐以“试行代公示”的方法施行。部署方法：可直接使用release的产物。因本人在Beta Cluster申请权限未果，无法在与本站相似的环境中测试；又因有检验后端服务承载力的需求；所以试行阶段，可先将本工具置入“测试与开发中的工具”中，并设置稍长的试行时间以便广泛测试。考虑读者视觉体验，建议默认设置采用遍黑体字体并以网络字体“覆盖系统字体”。
针对CSP和隐私相关，单独说明：对于预设小工具能否请求Toolforge托管之资源，基金会似未命令禁止。你或许可称为处于灰色地带😂，但我觉得他们制定CSP的本意主要不是想制裁这种情况。维基人理解并承认，本小工具的原理是按需构建font-face的CSS样式，其中在src调用托管在Toolforge的woff2字体文件。（为什么托管在Toolforge，因为commons不让托管字体文件，ULS webfont也被叫停了。）因为加载外部字体的关键逻辑直接由开源的前端脚本通过CSS实现，基本不可能导致传统意义的跨站脚本（XSS）攻击。此外，服务端遵循Toolforge规则，并以Apache-2.0协议开放源代码，不会记录使用者IP、UA等；在Toolforge本地产生的数据（包括字体文件），在Toolforge本地处理，不会被传输到非WMF站点。如果社群认为跨站请求Toolforge托管的字体不能接受，小工具还是能用的，可将默认设置改为不请求网络字体，用户可自行启用，效果如上图所示。
其他Q&A：
- 为什么不使用Glyphwiki之数据？这就是真的不符合CSP了；同时希望字体风格统一，且黑体优先，故使用开源字体项目。
- unicode缺字怎么办？我的构想在上面，未在本项目考虑空间。
- 如何支持其他wiki和非{{僻字}}模板情况？目前设置为所有class为
inline-unihan的span生效。这也是为什么不急着改造{{僻字}}。
Module talk:Lang § 有關更新模組以提升對不規範用例的兼容性
Module talk:Location map/data/Palestine § RfC：巴勒斯坦國使用的地理位置圖
目前英文維基百科使用File:Palestine location map wide.png（）作為巴勒斯坦國的位置地圖，範圍包括以色列全境；而Commons上亦存在File:West Bank and Gaza Strip location map.svg（），其範圍放大至加沙和西岸的周圍地區。個人認為放大後的圖片更加清晰準確，尤其利於巴勒斯坦國世界遺產列表這種需要密集標注的情形，但不清楚社群的偏好。
因此在此開啓RfC，徵求社群關於這一議題的意見：巴勒斯坦位置地圖應——
--Nebulatria 2025年11月11日 (二) 23:01 (UTC)Wikipedia:互助客栈/方针 § 移除对Tor用户获得自动确认的额外限制
长期以来对于使用Tor进行编辑的用户，存在一种额外的限制约束他们获得自动确认状态。相较于其他用户在“注册达7天+编辑达50次”即可获得自动确认，通过Tor编辑的用户需要“注册达90天+编辑达100次”才能获得自动确认。
这一限制的必要性有待商榷：欲通过Tor编辑必须要申请IPBE权限，这意味着Tor用户必然实现经过了或多或少的人工确认。可能有用户认为“使用Tor的用户是破坏者的可能性更高，所以提高门槛存在必要”，但是我认为对于本站来说找不到支撑这个论点的证据。移除这一限制的另一好处是让判断一名用户有无获得自动确认更加简单，减少了一些可能的误解。结合其他社群来看，英文维基百科近期将这个额外限制移除了。
综上，建议本站移除对Tor用户获得自动确认的额外限制，让使用Tor进行编辑的用户也能在“注册达7天+编辑达50次”后获得自动确认状态。请求社群讨论，谢谢。 Stang1163 2025年11月14日 (五) 09:15 (UTC)維基百科提議
[编辑]Wikipedia talk:游戏维基规则 § 提议将WP:游戏维基规则改名
Wikipedia talk:消歧义 § RfC：考慮将消歧義括号修正为中文括号
Wikipedia talk:封禁 § 临时账号封禁建議，及标记用户页的豁免情况
之前在有些群组中看到过有关封禁临时账号的讨论，此外我还觉得有些标记用户页的时的设置可能有点问题，因此在这里提请对封禁方针做出一些修订，详情见下。
请各位分别对1，2两条进行表态。此外，各位也可以适当的对一些表述不太恰当的位置或者说对要求重点标记的格式进行修改。谢谢各位。（主要是我时间不够……）--浅村しき（留言・来签个名吧） 2025年10月19日 (日) 15:23 (UTC)Wikipedia talk:人工智慧 § 考慮將此資訊頁升為正式指引
Wikipedia talk:檔案移動員 § 提议修改WP:FILEREDIRECT
Template talk:Non-free use rationale § 提議將Template:Nfur2合併到本模板
目前中文維基百科同時存在Nfur和Nfur2兩個模板，在英文維基百科，Nfur2已合併至Nfur。英文維基百科的合併理由是：兩個功能近乎相同的模板造成重複維護、使用者抉擇成本與潛在故障點倍增；而「非自由使用依據」屬高度制式、合規導向的頁面構件，標準化優於多樣化。
綜觀Nfur2，參數非常多，而且許多選項會讓使用者不知道如何回答；相較之下，Nfur不僅合乎規定，而且還很簡潔，對使用者而言非常友好。因此，在此提出合併請求。臺灣杉在此發言 (會客室) 2025年11月10日 (一) 10:26 (UTC)未分類
[编辑]目前此主題無正在討論的議題
以灰色標註者尚未正式啟用 | |
| 一般 | |
| 內容 | |
| 頁面處理 | |
| 用户行為 | |
| 其他 | |
