維基百科:互助客棧 (全部)

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

按此重新整理頁面。

		歡迎光臨互助客棧！
	互助客棧是維基人議事相助之處，用以討論消息、方針、技術以及編輯、求助等議題。 發表議題之前請搜尋先前文章，遵守指導及禮儀。任何與維基百科無關的問題，請前往知識問答。
消息	方針	技術	求助	條目探討	其他
討論維基相關新聞與消息	討論方針與草案	解決或報告技術疑難	解決在維基百科中所遇疑難	條目、模板、主題相關探討	未符任何分區之議題
發表 | 監視	發表 | 監視	發表 | 監視	發表 | 監視	發表 | 監視	發表 | 監視
檢視全部討論
幫助目錄 · 提出疑問 · wikitext基礎 · 常見問題 · 常見錯誤 · 布告板 · 了解術語 · 即時協助 · 規則簡述 · 使用指南
維基百科社群 互助客棧 消息 方針 技術 求助 條目探討 其他 徵求意見 專題 維護 協作討論 總幫助頁 方針與指引 社群媒體 Discord IRC QQ Telegram Line 互聯群 聚會
If you don't use Chinese, and want to contact Chinese Wikipedia, please leave your message here.

我想要……	請前往……
如何有效並安全地存取維基百科的方法	如何存取維基百科
與繁簡處理有關的問題	字詞轉換
協助或尋求條目的改善意見	同行評審
對某些特定來源的討論	可靠來源布告欄
尋找參考文獻	文獻傳遞
參與即時討論或透過電子郵件進行討論	「即時討論」或者「郵寄清單」

---

消息

Wikidata weekly summary #659

Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2024-12-23. Missed the previous one? See issue #658

Discussions

• New request for comments:
  • P518 scope - Should scope of league or competition (P118) include forms and aspects?
  • Trying to get a consensus on English label for Q30 -- "United States of America" vs "United States"

Events

• Ongoing: Wikidata Cleanup 2024 - Romaine continues his initiative, "Wikidata Cleanup," to coordinate community efforts in addressing the problem of items missing basic properties during the last ten days of 2024, when many users have extra time due to holidays. The aim is to improve data quality by focusing on ensuring all items have essential properties like "instance of" (P31) or "subclass of" (P279), adding relevant country and location data, and maintaining consistency within item series.
• Upcoming events: Data Reuse Days - online event focusing on projects using Wikidata's data, 18-27 February 2025. You can submit a proposal for the program on the talk page until January 12th.

Press, articles, blog posts, videos

• Blogs
  • Exploring YouTube Channels Via Wikidata, by Tara Calishain. "This time I'm playing with a way to browse YouTube channels while using Wikidata as context. And you can try it too, because it doesn't need any API keys!"
  • Wikidata Items "described at URL" domain ranked list, by Magnus Manske
• Papers: Finding Female Film Editors in Wikidata: How to Query and Visualize Filmographic Records
• Videos: How to link a Wikipedia article to Wikidata (Spanish)

Tool of the week

• Flying Dehyphenator is an Ordia game. Given the start part of a word, use the spacebar to move the word and hit the next part of the word. Only hyphenations described with the Unicode hyphenation character work.
• Want a wrap of your Wikidata activities in 2024? Wiki Year In Review has it for you! (use www.wikidata.org for the project URL)

Other Noteworthy Stuff

• Wikibase/Suite-Contributing-Guide: Wikibase Suite's contributing guide has been published. This guide aims to help anyone who wants to contribute and make sure they are equipped with all the relevant information to do so.

Newest properties and property proposals to review

• Newest General datatypes:
  • bequest income (the sum a organisations receives from bequests/legacies in a timeframe)
  • taxon known by this common name (taxon item of which this common name refers)
  • homonymous taxon (taxon item of which the taxon name is an exact homonym)
  • role named as (use as qualifier to indicate how the object's role was named in the credits of its respective work)
  • meeting of (subject is a meeting or session of this organization)
• Newest External identifiers: PCGames.de product ID, PUG authority ID, Three Decks class ID, Vidas author ID, Usito ID, ZSL authority ID, Collectie Nederland ID, Hachette author ID, CamerounWeb person ID, Hindi Shabdamitra entry ID, OpenSSF Practices ID, Japanese Health Insurance System Facility ID, Centre d'Etudes Picasso ID, CUATM statistical code, CUATM unique identification code, JudaicaLink person (GND) ID, teams.by national team ID, Eyrolles author ID, Mémoire des avocats ID, BCU Kirundi-English Dictionary ID, Estonian–Latvian Dictionary ID, WHL player ID, Indo-European Lexicon ID, Battle.net game ID
• New General datatypes property proposals to review:
  • About box (Screenshot of the About Box of the respective software (contains important information such as authors, license, version number and year(s) and is included in almost every software))
  • nonprofit tax status (country specific tax status of organisations like non-profits)
  • nomenclatural type of (taxon item of wich this item is the taxonomic type)
  • World Heritage type (Propriety of World heritage site : the Type (Cultural, Natural, Mixed))
  • DVD region code (DVD release is restricted to region code)
  • number of shading units (Number of shading units in a graphics card.)
  • Archaeological National Register code (identifier of elements of the National archaeological register of Moldova)
  • presented works (works of art performed, displayed or presented at a given event)
  • identifiant REGAFI ()
• New External identifier property proposals to review: Three Decks conflict ID, Algeria Press Service tag ID (French), Algeria Press Service tag ID (English), Algeria Press Service tag ID (Arabic), Newmark Albanian-English Dictionary ID, Norsk oversettterleksikon ID, footballdatabase.eu match ID, Kamus Pelajar Edisi Kedua ID, Berlinische Galerie object ID, Singapore Unique Entity Number, Lyricfind artist ID, HonestGamers game ID, identifiant MACM d'un artisite, Syrian Memory person ID, Identifiant d'un(e) auteurice sur le site Mille ans de littérature d'oc, Paris Match ID, Kamus Dewan Edisi Tiga, identifiant Registre national des gels, DOSBox Wiki, Identifiant Cimetières de France, Ech-Chaab tag ID, Amsterdam Monumentenstad ID, Kyiv Independent Topic, Lutris company ID, Shamela Algeria person ID, enterprise number (Germany), Ohio University ArchivesSpace Subject ID, Progetto Euploos ID, Nafziger Order of Battle ID, National Football Teams.com stadium ID, Play:Right genre ID, DataGov dataset, ERR keyword ID, Comprehensive Historical Dictionary of Ladino entry ID, Ohio University ArchivesSpace Agent ID, Russian Football National League player ID, Gaia ID, Inventory of Natural Heritage site ID, Inventory of Natural Heritage tree ID, Wellcome Collection concept ID

You can comment on all open property proposals!

Did you know?

• Query examples:
  • Countries that have had a woman serving as Minister of Defense
  • Leonardo DiCaprio's partners (source)
  • Countries that have most items with Mastodon or PeerTube (ActivityPub) social networks (source)
  • Olympians who died during the year 2024 (source)
• WikiProject Highlights: Nonprofit Organizations/Japan
• Newest database reports: Items with a sitelink to Dutch Wikipedia and have no P31 and/or P279 (source) (replace 2x the "nl" into the language code of your language)
• Showcase Items: Boeing (Q66) - American global aerospace and defense corporation
• Showcase Lexemes: julehilsen - Christmas greeting in Danish

Development

• With the winter holidays upon us, the development team is taking a break, and there will be no deployments for Wikidata during this time.

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.

Weekly Tasks

• Add labels, in your own language(s), for the new properties listed above.
• Contribute to the showcase Item and Lexeme above.
• Govdirectory weekly focus country:
• Summarize your WikiProject's ongoing activities in one or two sentences.
• 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!

· Previous issue · Mohammed Abdulai (WMDE) (talk) · MediaWiki message delivery（留言） 2024年12月23日 (一) 18:00 (UTC)

The Signpost: 24 December 2024

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

• News and notes: Responsibilities and liabilities as a "Very Large Online Platform"

• Op-ed: Beeblebrox on Wikipediocracy, the Committee, and everything

• Opinion: Graham87 on being the first-ever administrator recall subject

• In the media: Delhi High Court considers Caravan and Ken for evaluating the ANI vs. WMF case

• From the archives: Where to draw the line in reporting?

• Recent research: "Wikipedia editors are quite prosocial", but those motivated by "social image" may put quantity over quality

• Humour: Backlash over Santa Claus' Wikipedia article intensifies

• Gallery: A feast of holidays and carols

• Traffic report: Was a long and dark December

Read this Signpost in full · Single-page · Unsubscribe · Global message delivery 2024年12月25日 (三) 00:04 (UTC)

Weekly Summary #660

Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2024-12-30. Missed the previous one? See issue #659

Welcome to 2023’s Final Weekly Summary!

A huge thank you to everyone who contributed to the newsletter this year! 🎉 Each of your contributions, whether big or small, has made a difference and has helped us create a vibrant and informative resource for the Wikidata community. 🙏 Let's continue building and sharing knowledge together in the coming year! 🙌✨

Discussions

• Open request for oversight: Ameisenigel (RfP scheduled to end at 6 January 2025 21:52 UTC)

Press, articles, blog posts, videos

• Papers
  • Library Data in Wikimedia Projects: Case Study from the Czech Republic by Jansová, L., Maixnerová, L., & Š´tastná, P. (2024). "The paper outlines the collaboration between the National Library of the Czech Republic and Wikimedia since 2006, focusing on linking authority records with Wikipedia articles and training librarians and users. By 2023, the National Library provided most of its databases under a CC0 license, launched a "Wikimedians in Residence" program, and collaborated on projects involving linked data and using authority records in Wikidata. This partnership has enhanced their cooperation for mutual benefit, identifying key factors for their successful long-term collaboration."
  • How have you modelled my gender? Reconstructing the history of gender representation in Wikidata by Melis, B., Fioravanti, M., Paolini, C., & Metilli, D. (2024). "The paper traces the evolution of gender representation in Wikidata, showing how the community has moved from a binary interpretation of gender to a more inclusive model for trans and non-binary identities. The Wikidata Gender Diversity project (WiGeDi) timeline highlights the significant changes influenced by external historical events and the community's increased understanding of gender complexity."
• Videos: Arabic Wikidata Days 2024 - Data Science Course - First Practical Session: Wikibase-CLI Tool (part 1, part 2) by Saeed Habishan. "The Wikibase-CLI enables command-based interaction with Wikidata using shell scripts and JavaScript. The tool runs on NodeJS and enables automatic reading and editing of Wikidata."

Tool of the week

• WikiORA - is a tool designed for gene over-representation analysis. It integrates data from Wikidata, Wikipedia, Gene Ontology, and PanglaoDB to help researchers identify significantly enriched gene sets in their data.

Newest properties and property proposals to review

• Newest General datatypes:
  • bequest income (the sum a organisations receives from bequests/legacies in a timeframe)
  • taxon known by this common name (taxon item of which this common name refers)
  • homonymous taxon (taxon item of which the taxon name is an exact homonym)
  • role named as (use as qualifier to indicate how the object's role was named in the credits of its respective work)
  • meeting of (subject is a meeting or session of this organization)
• Newest External identifiers: PCGames.de product ID, PUG authority ID, Three Decks class ID, Vidas author ID, Usito ID, ZSL authority ID, Collectie Nederland ID, Hachette author ID, CamerounWeb person ID, Hindi Shabdamitra entry ID, OpenSSF Practices ID, Japanese Health Insurance System Facility ID, Centre d'Etudes Picasso ID, CUATM statistical code, CUATM unique identification code, JudaicaLink person (GND) ID, teams.by national team ID, Eyrolles author ID, Mémoire des avocats ID, BCU Kirundi-English Dictionary ID, Estonian–Latvian Dictionary ID, WHL player ID, Indo-European Lexicon ID, Battle.net game ID, Singapore Unique Entity Number, AniSearch character ID, Three Decks conflict ID, Berlinische Galerie object ID
• New General datatypes property proposals to review:
  • About box (Screenshot of the About Box of the respective software (contains important information such as authors, license, version number and year(s) and is included in almost every software))
  • nonprofit tax status (country specific tax status of organisations like non-profits)
  • nomenclatural type of (taxon item of which this item is the taxonomic type)
  • World Heritage type (Propriety of World heritage site : the Type (Cultural, Natural, Mixed))
  • DVD region code (DVD release is restricted to region code)
  • number of shading units (Number of shading units in a graphics card.)
  • Archaeological National Register code (identifier of elements of the National archaeological register of Moldova)
  • presented works (works of art performed, displayed or presented at a given event)
  • identifiant REGAFI ()
  • Maximum beam energy (Maximum beam energy of a particle accelerator)
  • Accused of (Crime or other misdeed a person has been accused of, but ''not proven or convicted'')
  • hat gespendet (Amount of money donated to a person or organization)
• New External identifier property proposals to review: Algeria Press Service tag ID (French), Algeria Press Service tag ID (English), Algeria Press Service tag ID (Arabic), Newmark Albanian-English Dictionary ID, Norsk oversettterleksikon ID, hockey1946.ru player id, footballdatabase.eu match ID, Kamus Pelajar Edisi Kedua ID, Lyricfind artist ID, HonestGamers game ID, identifiant MACM d'un artisite, Syrian Memory person ID, Identifiant d'un(e) auteurice sur le site Mille ans de littérature d'oc, Paris Match ID, Kamus Dewan Edisi Tiga, identifiant Registre national des gels, DOSBox Wiki, Identifiant Cimetières de France, Ech-Chaab tag ID, Amsterdam Monumentenstad ID, Kyiv Independent Topic, Lutris company ID, Shamela Algeria person ID, enterprise number (Germany), Ohio University ArchivesSpace Subject ID, Progetto Euploos ID, Nafziger Order of Battle ID, National Football Teams.com stadium ID, Play:Right genre ID, DataGov dataset, ERR keyword ID, Comprehensive Historical Dictionary of Ladino entry ID, Ohio University ArchivesSpace Agent ID, Russian Football National League player ID, Gaia ID, Inventory of Natural Heritage site ID, Inventory of Natural Heritage tree ID, Wellcome Collection concept ID, Spanish-German Dictionary ID, UAF match ID, Identifiant d'un(e) journaliste sur Francetvinfo, Game Vortex software ID, VG247 game ID, identifiant Pappers d'un dirigeant, Database of Canada's Early Women Writers ID, Canadian Writing Research Collaboratory ID, Mishramilan catalog ID, SearchCulture.gr ID, Cinema Belgica venue ID, Cinema Belgica person ID, Cinema Belgica film ID, Cinema Belgica company ID, Cinema Belgica censorship ID, Archaeological Cadastre (Greece) ID, Hankook Ilbo tag ID, Rijksmuseum ID, SOIUSA code, myCast work ID

You can comment on all open property proposals!

Did you know?

• Query examples:
  • trees of motifs described in Thompson's motif index (first two levels)
  • Think tanks by country (source)
  • Painters that have died before 1925 but do not have a Wikimedia Commons category on their Wikidata Item (source)
• Newest WikiProjects: Uganda - aims to be a central hub for the curation of any and all items (biographical, cultural, geographical, organisational, etc...) relating to Uganda (Q1036)
• WikiProject Highlights:
  • Narration/Folktales - creation of Items for motifs described in Thompson's motif index completed
  • Austria - concerns itself with improving data from nonprofit organizations in Austria
• Newest database reports: Deleted Wikidata entities used in SDC
• Showcase Items: Wressle Castle (Q8037764) - late 14th-century quadrangular castle in East Yorkshire, England, UK
• Showcase Lexemes: ਲੇਟਣ (L750580) - in Punjabi (pa) and "لیٹݨ" in Punjabi Shahmukhi (pnb) transliterate to "Leṭaṇ," which means "to lie down" or "to rest" in English.

Development

• Most of the development team staff are still taking a break, so no development happened.

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.

Weekly Tasks

• Add labels, in your own language(s), for the new properties listed above.
• Contribute to the showcase Item and Lexeme above.
• Govdirectory weekly focus country: Liechtenstein
• Summarize your WikiProject's ongoing activities in one or two sentences.
• 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 · Previous issue · Unsubscribe · Mohammed Abdulai (WMDE) talk · MediaWiki message delivery（留言） 2024年12月30日 (一) 15:11 (UTC) ·

方針

關於Wikipedia:避免地域中心#地理，建議增加關於「來」字的論述

1）識別問題

「來」字的用法常常是錯誤的，例如「來華」、「來港」，乃至一般用法的「來到」。從邏輯上來說它不僅是地域中心的思考所導致的，甚至比現行方針中地域中心#地理的例子更加直接。在WP:避免主觀用詞里有更詳細的論述。複製如下：

來：在非引用的情況下維基百科正文幾乎不會出現作為動詞使用的「來」。（當然了全文搜索「來」字，搜到的大部分都不是作為動詞使用的來。）不過，還是比較容易發現一些誤用的例子的。這類問題多發於「來中國/來華」或者「來中國的某個特定地方」。因為中文材料中默認以中國或者特定地區為「此地」的做法不少。

• • 來華、來中國、來滬、來港
  • 來到

目前我不做具體修改的提議，因為我認為「識別問題」、「提出解決問題的方案」和「解決問題」是三個不同階段的事情，直接眉毛鬍子一把抓會導致思維混亂。所以目前我只徵求大家的意見，看「在避免地域中心方針里不提及「來某地」的用法」是不是問題。如果是問題，再討論如何解決。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年11月19日 (二) 08:41 (UTC)

如果有人在此話題里直接討論解決方案，我將進行勸阻。如果不聽勸阻，我會視作擾亂討論，做提報。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年11月19日 (二) 08:43 (UTC)

本人的看法：不是。原因如下：

1. 方針涵蓋的用例應該是只符合該方針的情況。如您所言，「來Ｘ」邏輯上不是以地域中心為主因。
2. 某程度上，「地域中心」是「主觀用詞」的子集。

其他事情待您決定把討論推進到下一階段再說。

以上--派翠可夫 (留言按此) 2024年11月19日 (二) 09:21 (UTC)

了解。同意地域中心是主觀用詞的子集。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年11月19日 (二) 15:16 (UTC)

以前就有人對《避免地域中心》提出異議。既然「來X」和地域有關，不妨先當補丁摞上去，等到有哪位勇士來改制《避免地域中心》再說。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月20日 (三) 06:59 (UTC)

除引用原文外（這種毋庸贅論），若條目係聚焦某地，「來某地」此類用法也不總是有問題。例如撰寫中國基督教史之類議題，行文寫出「傳教士某氏來華後，有若干作為」，這應該是可以接受的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月19日 (二) 13:45 (UTC)

並不認同。以「中國基督教史」為例，如果因為話題是「中國這一地區的」基督教史，就認為可以說「來華」，那麼美國移民史就可以說歐洲移民「來美」嗎？正常行文是不該如此的吧？--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年11月19日 (二) 15:18 (UTC)

「來華」始終比「抵華」、「到華」（甚至「到中國」之類）聽著理順，這似乎是中文語言（尤其「華」字簡稱本身）的一種性質，已經超出單純地域中心問題。個人不反對於格式手冊明確提倡少用此種語彙，但完全禁止亦不甚現實。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月20日 (三) 07:03 (UTC)

有沒有一種可能是『「來華」始終比「抵華」、「到華」（甚至「到中國」之類）聽着理順』這種感覺本身也是地域中心的一種體現？這樣説吧：假如把「華」換成兩岸四地、漢字文化圈以外的地方，就比方説位於歐洲的匈牙利，或是位於南美洲的阿根廷之類的，這種感覺真的會仍然存在嗎？Sanmosa _新朝雅政 2024年11月20日 (三) 07:53 (UTC)

若此為中文語言本身而非本站編者自行造成的特性，本人認為可以容忍（但當然也可以同時優先推薦別種寫法）。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月25日 (一) 06:45 (UTC)

我既不認為這是中文本身的特性，也不認為這是zhwiki用戶自行造成的特性。就「來華」這詞而言，這多多少少都有些政治意涵，可以説「來華」這詞是在帶有相當政治目的的情況下被植入中文體系裏的。這確實超出了單純的地域中心問題：這根本就是直接抵觸了NPOV好嗎？Sanmosa _新朝雅政 2024年11月25日 (一) 08:38 (UTC)

這誤會就大了，老早就有的用法，別什麼都扯政治好吧。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月3日 (二) 12:32 (UTC)

「來華」未必比「抵華」通順，但確實比「到華」通順，後者文白混雜。考慮到「來華」不強調「抵達」，或可以「赴華」替代。--Xsgzjmxs（留言） 2024年11月26日 (二) 02:38 (UTC)

抱歉方才忘記簽名了。--Xsgzjmxs（留言） 2024年11月26日 (二) 02:42 (UTC)

此前見到過哪個條目里寫某日本藝人「來台」，顯然是不合適的。不是經常見到。——暁月凜奈 (留言) 2024年11月19日 (二) 13:52 (UTC)

可以規定應避免使用「來」。Sanmosa _新朝雅政 2024年11月20日 (三) 00:24 (UTC)

不知道是否應該另開新題，不過這令我聯想到「返X」是否可能也有地域中心的問題。比方「李安返台頒發金馬獎」，李安是台灣人，這是客觀事實，他從台灣以外的地方到台灣頒獎，對他而言確實是「返台」，但是這句話是否有讀者也是台灣人的暗示？-游蛇脫殼/克勞棣 2024年11月23日 (六) 15:31 (UTC)

夏爾·戴高樂：1918年戰爭結束之後他終於返回法國。我覺得沒有任何問題。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月23日 (六) 20:35 (UTC)

是我多慮了。謝謝！-游蛇脫殼/克勞棣 2024年11月24日 (日) 03:30 (UTC)

我覺得可能要看具體語境。戴高樂的例子我並不反對。不過，假如現在有個情況是A的出生地是X、常居地是Y，把A由X以外的地方前往X的行為稱為「返X」並不合適，但把A由Y以外的地方前往Y的行為稱為「返Y」則相對而言問題不大。Sanmosa _新朝雅政 2024年11月25日 (一) 00:16 (UTC)

出生地和常居地一樣的話，我覺得也問題不大。--Hamish T 2024年12月2日 (一) 17:29 (UTC)

有點吹毛求疵了吧？如果「來」有異議，那麼「去」呢？--航站區（留言） 2024年11月24日 (日) 03:34 (UTC)

你不說我還沒留意，「去」確實有著與「來」類近的問題。Sanmosa _新朝雅政 2024年11月25日 (一) 00:13 (UTC)

如果經過討論發現「來」和「去」都有問題，那麼應該用什麼詞語替換？我目前沒有想到通順且無此問題的詞語。--GUT412454（留言） 2024年12月2日 (一) 19:22 (UTC)

接目的地的「抵」，接來源地的「離」，均可用。Xsgzjmxs（留言） 2024年12月2日 (一) 19:39 (UTC)

討論串發起者UjuiUjuMandan君有言如果有人在此話題里直接討論解決方案，我將進行勸阻。如果不聽勸阻，我會視作擾亂討論，做提報。--Hamish T 2024年12月3日 (二) 12:54 (UTC)

抱歉，是我是我過失了。謝謝提醒。

不過這裡確實存在一個「詞彙是否暗示特定地點視角」或者「哪些詞彙暗示特定地點視角」的問題，這似乎這是整個議題的核心。個人認為，「來」「去」依站位而定，預設了地點視角，是不恰當的。不過這樣，「返」字怎麼算？個人理解，如果在單次或作為連續整體的行程中再次達到出發地，則這個「返」可以理解為從出發地視角而非敘述者視角陳述，可以接受，如「某甲自新加坡出發，歷訪上海、台北，三日後返抵獅城」，這段敘述完全可以是從例如紐約做出的敘述；但「來」「去」恐怕不行，其中以「來」為最；「去」第三方視角敘述（如紐約視角：「某甲從東京去了首爾」）也尚可接受，但這種用法似乎語體不算正式。鄙意「來」和「去」確實以少用、不用為妙。

Xsgzjmxs（留言） 2024年12月5日 (四) 21:06 (UTC)

我是在想這個問題是否存在解決方案。因為如果不存在解決方案，那麼討論是否應該解決這個問題是沒有意義的。不過上面Xsgzjmxs已經提出了一個解決方案，所以現在討論是否應該解決這個問題是有意義的。（雖然不一定要用這個解決方案）--GUT412454（留言） 2024年12月7日 (六) 15:04 (UTC)

至 和 達 @Xsgzjmxs--航站區（留言） 2024年12月9日 (一) 06:46 (UTC)

@UjuiUjuMandan：我希望確認一下這裏是否已經形成「來」的用法有問題的共識。Sanmosa _{Samāʾun la-ʿamruka ʾaw ka-s-samā} 2024年12月17日 (二) 02:12 (UTC)

@Sanmosa：special:diff/85335302為何莫名加了個魔琴用戶頁的鏈接？--自由雨日🌧️❄️ 2024年12月17日 (二) 02:41 (UTC)

應該是使用留言工具輸入留言時複製其他留言造成的錯誤，已刪去。Sanmosa _蚌埠 2024年12月17日 (二) 03:34 (UTC)

我覺得可以前進到解決方案的討論了。也不是必須我來發起，但這次我來做吧。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年12月17日 (二) 05:39 (UTC)

2）解決方案

看來關於「來」的用法是否有問題已經有共識了，那麼請允許我徵求解決方案。

上面已經有人提到可以用不含敘述者主觀方向的用詞，比如帶有動作實施者主觀方向的「赴」、「返」等和不帶主觀方向的「抵」、「達」、「到」等。我個人認為是可以的。我也看不到有什麼副作用。各位怎麼看？ --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年12月17日 (二) 05:29 (UTC)

和之前的做法一樣，討論解決方案時請關注利弊和所需要做的工作之類的問題，不要把問題的解決方案和解決方案的作業放在一起看。即使我們同意採納某個解決方案，也許這個問題永遠不能徹底解決，但至少今後看到條目里有這種問題我們知道社群認為應該怎麼做。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年12月17日 (二) 05:41 (UTC)

基本上不反對這個結論。考慮到我的憂慮很大可能屬於細節問題，我就不在這階段説了。Sanmosa _蚌埠 2024年12月17日 (二) 08:36 (UTC)

可以在這個階段談具體憂慮，但我建議你給一兩個具體例子這樣方便理解。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年12月17日 (二) 09:08 (UTC)

那我就説一下帶有動作實施者主觀方向的用字的問題吧。我在上方有提到假如A的出生地是X、常居地是Y，把A由X以外的地方前往X的行為稱為「返X」並不合適的事情，這點除了「返」字外，「赴」字也同樣適用，而我相信這點適用於所有帶有動作實施者主觀方向的用字。我擔憂的是如果沒有對帶有動作實施者主觀方向的用字的使用條件作必要的限定，這會導致帶有動作實施者主觀方向的用字在被不當使用時產生與「來」字相同或相近的問題，因為這種類型的不當使用在中文圈與兩岸四地中尤為常見。簡而言之：「來」字（與「去」字）通常有問題，帶有動作實施者主觀方向的用字有些時候有問題，不帶主觀方向的用字通常沒有問題，需要界定帶有動作實施者主觀方向的用字有問題的情境。Sanmosa _蚌埠 2024年12月17日 (二) 14:44 (UTC)

建議把敘述者主觀方向和動作實施者主觀方向分開考慮。

• 敘述者主觀方向：「來」。非引用原文的情況下應避免使用。（「去」則也可能是動作實施者主觀方向。）
• 動作實施者主觀方向：「赴」、「返/回」等。並沒有問題。你舉的那個例子我覺得不是問題。少小離家老大回，有何不可。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年12月18日 (三) 17:25 (UTC)

一般來説確實是這樣，然而就兩岸四地的情況來説，在特定情境下利用「赴」、「返/回」可能會帶有一定的政治意涵，這種表述我擔憂會影響中文維基百科的中立性。Sanmosa _蚌埠 2024年12月19日 (四) 10:46 (UTC)

這一點我沒有理解到，所以能否舉個例子？--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年12月28日 (六) 03:13 (UTC)

見下。Sanmosa _蘭絮 2024年12月28日 (六) 03:37 (UTC)

3）解決問題（？）

我不清楚現在是否適合直接快進到第三階段討論，然而自從第二階段討論開始以來，就只有我與UjuiUjuMandan還在參與討論，因此我感覺現在或許是適合開展第三階段討論的時機。故此，現提議將下述條文加入WP:避免地域中心#用語方面：

「

主觀方向的用詞

除專有名詞或語錄外，在任何情況下均不應將明示或暗示特定地點視角的詞彙用於敘述性內文，如使用帶敘述者主觀方向的詞彙（如「來」等），或使用帶動作實施者主觀方向的詞彙（如「去」、「赴」、「返」等）時將並非動作實施者的常居地的地點設為主視角地點等。應使不帶主觀方向的詞彙（如「抵」、「達」、「到」等）代替，或在使用帶動作實施者主觀方向的詞彙時修正主視角地點為動作實施者的常居地，以避免明示或暗示特定地點視角。

」

以上。Sanmosa _腦洞大開 2024年12月26日 (四) 14:26 (UTC)

(－)反對：「赴」是從一個地點「出發」到另一個地點的常用詞彙，對標「到達」（如「抵」），如「赴會」、「赴某地與會」此類語句並不違和；同理，「返」則是描述返回居住地或據點的客觀詞彙，如某人長居某地、自某地出發等，若搭配行文明確，從某地出發完後，自可說「返回某地」。兩者本為漢語（包含眾多可靠來源）廣泛使用，均奠基於事實經過，與所謂「中立」無甚關聯，若不加思索而禁止使用（所謂「在任何情況下均不應」），除關係行文流暢與否，將導致基本書寫發生無謂之迂迴問題。舉個兼用的例子：某國外交部部長獲邀參與某地某會議，於某年某月某日出訪赴會，期間並途經若干友邦，於某日返回某地。百科全書條目中，此種用法情境比比皆是；若清一色改為上述所謂「不帶主觀方向的詞彙」，不僅顯得單調死板，且根本未有任何實質改善可言。個人認為，所謂「中立」或「政治意涵」，重點並非按辭典斤斤計較個別詞彙，而是結合上下文使用脈絡，評判相對主觀程度是否不當；不存在所謂劃一標準，可以用作格式手冊絕對「一刀兩斷」。故上述若干朋友所言差矣。與此同時，則些許認同減少使用「來」、「到」此類詞彙之必要。我不知道後面「或在使用帶動作實施者主觀方向的詞彙時修正主視角地點為動作實施者的常居地」是不是但書；不過，此修訂案整體而言欠缺考慮，尤其所謂「（帶、不帶）主觀方向」之說並不總是成立，宜重行調整範圍，減少過度拘束。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月27日 (五) 23:37 (UTC)

另外我還是覺得「傳教士來華是中國歷史上的重大事件」行文優於「傳教士抵華是中國歷史上的重大事件」之類（實際上可靠來源也罕用，因為此類歷史事件意義本在強調東西方相對性質）。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月27日 (五) 23:45 (UTC)

這一點上我並不認同，因為憑什麼讀者懂中文就要覺得中國是自己的國家呢？--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年12月28日 (六) 03:14 (UTC)

是的，我相信我生於、長於、居於新加坡的親戚會有這個困惑。Sanmosa _蘭絮 2024年12月28日 (六) 14:16 (UTC)

若此修訂案改以「須明示地點視角」為主要規範內容，並兼述某些多數情況均不適宜之詞彙，我則較很同意。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月27日 (五) 23:57 (UTC)

@Ericliu1912：然而「返華」與藝人「返台」卻不是你所説的那種情況，這就是我上面所説的我擔憂會影響中文維基百科的中立性的情況。Sanmosa _蘭絮 2024年12月28日 (六) 01:01 (UTC)

我覺得你要思考什麼時候會用到「返華」或「返臺」。實際上他們本來就「在華／臺」且曾有「離華／臺」，所以屆時纔是「返」。只要能夠於上下文中描述此些脈絡，就已然無關所謂「中立」與否，尤其不涉及此話題之初衷——地域中心問題，因為你已向讀者闡明行文視角。格式手冊所應禁止者，乃使用前述詞彙卻未能講解其中「返」、「赴」等意義，或無法正確提出主觀視角之相對關係而使讀者知悉等情況。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月28日 (六) 01:10 (UTC)

那要不你自己提一個版本吧，畢竟如你上面看到的，我的這個分段標題也是自己給自己打了個問號的。Sanmosa _蘭絮 2024年12月28日 (六) 01:16 (UTC)

好，近期稍忙需些時候，但應能速提對案。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月28日 (六) 01:20 (UTC)

提案前，仍先詢問@UjuiUjuMandan君意見，以求兩全。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月28日 (六) 01:22 (UTC)

例如某條目若能闡明林茂生是國民參政會臺灣籍參政員，而參政會在南京市開會，那應當允許寫出「國民參政會開幕之際，林氏因被捕失蹤，亦未能及時赴會」等語，不必一再點出「臺灣」或「南京」；其他情況同理。個人認為，除少數確應強制規定者外，大抵能靠編者視全文情況靈活處理，毋須寫死。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月28日 (六) 01:20 (UTC)

將WP:格式手冊所有方針與論述移動到MOS命名空間，並將MOS命名空間更名為「格式手冊」

因為此案涉及到方針指引的移動，故不放在技術區，放在方針區

前言

見前次討論，已有初步共識，不過當時有意見認為需近一步討論，也因 此案涉及到方針指引的移動故需要在方針區確認共識或進一步討論。

方針/指引的部分即：

• 將所有WP:格式手冊的子頁面(►)移動到MOS:空間下。

技術細節：

• 將MOS更名為「格式手冊」，即：

• 編輯以下頁面：

在這些介面設定頁面中 MediaWiki:Nstab-mos MediaWiki:Nstab-mos/zh MediaWiki:Nstab-mos/zh-hant MediaWiki:Nstab-mos/zh-tw MediaWiki:Nstab-mos/zh-hk MediaWiki:Nstab-mos/zh-mo MediaWiki:Nstab-mos/zh-hans MediaWiki:Nstab-mos/zh-cn MediaWiki:Nstab-mos/zh-sg MediaWiki:Nstab-mos/zh-my MediaWiki:Conversion-ns126

中填入格式手册或格式手冊

• 提出工單將「格式手册」和「格式手冊」設定為「MOS」的別名（比照當時維基專題命名空間的設置）
• 命名空間偵測模板更新「格式手冊」命名空間名稱

正文

見前次討論，因為MOS語言維基百科的創立，因此本站設立的MOS捷徑得以因此技術原因phab:T363538，被升格為命名空間。當時的討論主流共識認為，既然都有名字空間了，不如把對應頁面都(►)移動進去。

我現在的想法是，既然基金會都升格MOS為正式命名空間了，我們不使用實在浪費。且屆時上述更名技術操作全部完成後，移動到下面的頁面如維基百科:格式手冊/避免自我提及將會直接顯示為「格式手冊:避免自我提及」同當時「維基百科:XX專題」變為「專題:XX」的好處。

提及上次「關於本命名空間」之討論參與者@S8321414、SunAfterRain、魔琴：歡迎再次發表意見。

• (～)補充 現行「指引上」MOS的地位現在是偽命名空間，然而目前基金會已經將之升格為「真」命名空間，因此「技術上」MOS的地位現在是「真」命名空間。這次希望的修訂就是能充分利用這個「真」命名空間，同時修訂相關方針指引以滿足phab:T363538的現況。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月5日 (四) 04:06 (UTC)

計畫時程

1. [方針] 「方針/指引」獲得共識
2. [技術] 技術調整（[管理員/模板編輯員]編輯模板、[phab]設定空間中文別名、[phab]開啟命名空間子頁面功能、[介面管理員]編輯介面）
3. [機器人] 批次(►)移動頁面，計畫為「WP:格式手冊/XXX」→「格式手冊:XXX」（如技術調整已完成，格式手冊:XXX將會等同於MOS:XXX）；會保留WP:格式手冊這頁，及相關重定向頁（同上次「維基專題」辦理辦法）；涉及頁面Special:前缀索引/格式手册及Special:前缀索引/格式手冊（不多，規模比上次PJ空間小很多，目測少於500頁面）
4. [方針] MOS從捷徑指引中移除或修改措辭

以上，歡迎討論-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 05:51 (UTC)

不反對，但第四步能不能解釋得詳細一點？--冥王歐西里斯（留言） 2024年12月4日 (三) 06:26 (UTC)

• (：)回應：@S8321414：Wikipedia:捷徑#偽命名空間移除MOS，因為不再需要了，因為MOS已不在條目命名空間，故不需要快速刪除相關條文。然後其他相關指引中關於MOS的描述可能都要檢查或修訂，涉及偽命名空間的則需移除。（如上說明，因涉及方針或指引修改，故本討論放方針區）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 06:37 (UTC)

  OK，那我暫時沒什麼其他意見了。--冥王歐西里斯（留言） 2024年12月4日 (三) 06:45 (UTC)

(※)注意，這次與專題的命名空間有不同，基金會設立專題空間時有把全寫「WikiProject:」和縮寫「PJ:」納入作為可用的前綴；但對於MOS空間，基金會衹把縮寫「MOS:」作為可用的前綴，而沒有全寫。由此可見，基金會設立MOS空間是用來放捷徑重定向的，並沒有預期會當成正式的頁面來用。我們需要先確認這樣做是不會產生新的技術問題、以及沒有違背基金會設定的技術用法才行。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年12月4日 (三) 13:42 (UTC)

已知的技術問題：（歡迎補充）

1. MOS和MOS_talk空間並沒有子頁面功能（測試：MOS talk:標點符號/存檔1不被MW系統視為MOS talk:標點符號的子頁面，故MOS talk:標點符號/存檔1的標題欄下沒有自動顯示上一層的連結，對比Wikipedia_talk:格式手冊/標點符號/存檔1則有自動上一層的連結）--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年12月4日 (三) 13:42 (UTC)

隱藏可能不太WP:禮儀的討論 @Cdip150：我上面寫的計畫時程「2.[技術] 技術調整」就是已經包含去phab申請「命名空間別名」、子頁面等東西啊。這東西沒有本地共識是要怎麼申請？？？我在方針區提，而不是在技術區題就是為了這個啊。你的那些問題都會在本地共識有了之後，提請phab修改啊，那樣不就都解決了？你變成直接這樣提，那，從哪來本地共識？？ 沒有本地共識要怎麼申請phab工單解決你的問題？？？？ 拜託不要製造套娃問題好嗎？ 拜託不要製造遞迴/迴圈問題好嗎？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 13:52 (UTC) 我上面寫的「如技術調整已完成，格式手冊:XXX將會等同於MOS:XXX」就正是你質疑的「基金會設立專題空間時有把全寫「WikiProject:」和縮寫「PJ:」納入作為可用的前綴」、「基金會衹把縮寫「MOS:」作為可用的前綴，而沒有全寫」，我就是要先或的本地共識再比照專題空間去申請啊，那你以這個「要有本地共識才能形成的結果」拿來反對「形成本地共識」的理由，是甚麼意思？？？？ 拿「要有本地共識才能有結果」的東西來「阻止本地共識的形成」(！)抗議-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 13:55 (UTC) 你不讓我尋求本地共識，我是要拿甚麼依據去給PHAB？？？？？？？？？？？？？？？？？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 13:58 (UTC) 你完全不是在「政策上反對」，而是「技術上有意見」，但問題是「該技術意見全部都可以政策通過後去phab解決」，你把「政策」過了之後才會提請的「技術」修改當作「阻止政策通過」的意見，是否搞錯了什麼？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 14:01 (UTC) (※)注意：@Cdip150：「基金會設立專題空間時有把全寫「WikiProject:」和縮寫「PJ:」納入作為可用的前綴」，「基金會」？ 不好意思，那段程式碼我寫的，謝謝，提案也是我提的，所以根本不是「基金會設立有納入」，而是「本地共識為需要納入」，然後我寫程式給phab，他們佈到正式機而已。所以「基金會設立有納入」，錯，是「本地社群共識設立有納入」謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 14:07 (UTC) 首先我沒有任何「反對」的意思，不知為何被理解成反對，請勿過度解讀。還有再次提醒閣下注意一下Wikipedia:禮儀，也許我的意見有問題，但實在不應該這樣罵街式回應和動輒就「抗議」人家。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年12月4日 (三) 15:15 (UTC)

• 抱歉：@Cdip150：(：)回應：很抱歉過度解讀了您的留言，還用了缺乏Wikipedia:禮儀的說詞，真的很抱歉，我未來會謹慎調整措辭、會繼續加以改善情緒避免未來再次發生。另外，很抱歉，仔細檢視了我上方提案也有缺漏之處，例如預期要給phab設定命名空間別名、子頁面等技術作業我只寫了一個「空間別名」過於簡短短、詞不達意，以致於造成誤會，我在此深感抱歉，對不起...-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 23:47 (UTC)

話可不能這樣説，MOS的地位現在是偽命名空間，偽命名空間是不需要通過基金會設立的，我認為你應該要更正你此前存在事實錯誤的言論，以免對其他討論參與者產生誤導。Sanmosa _新朝雅政 2024年12月5日 (四) 01:29 (UTC)

• (：)回應：@Sanmosa：雖然「指引上」MOS的地位現在是偽命名空間，但「技術上」此時此刻，它是「真」命名空間。你這裡點出的另外一個問題就是目前現行指引跟實際技術已被基金會設定好的內容不符。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月5日 (四) 04:03 (UTC)

  那我就不太理解你說的「真」又是何義了。Sanmosa _新朝雅政 2024年12月5日 (四) 05:40 (UTC)

  • (：)回應：@Sanmosa：根據之前語言代碼為MOS的維基百科被設立時phab:T363538，之後MOS在技術上已經變成貨真價實的命名空間了。所謂的「偽」命名空間是指，它實際放在「條目命名空間」，但phab:T363538之後，MOS:就都不是位於「條目命名空間」了，那麼直接違反「偽」命名空間的定義。既然他已經不「放置（技術上的）」於「條目命名空間」，那他就不「偽」了，而是「真」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月5日 (四) 06:58 (UTC)

    啊，既然是這樣的話，那自然是移動為好了，不用白不用。Sanmosa _新朝雅政 2024年12月5日 (四) 08:15 (UTC)

本子段落的「子共識」：
　● 建議(►)移動到新命名空間

• (！)意見：當時設置維基專題空間時就是認為維基專題並不嚴格符合Project命名空間的用途，即「有關維基百科的內容信息，包括維基百科自身的信息、方針、指引、論述，以及維基人的討論空間『互助客棧』、知識問答等 」。但是MOS（以及NT、NC）確實就是維基百科本身的方針指引，如此拆分不知是否合適。先前設置維基專題命名空間時，Wikipedia:電子遊戲專題/條目指引和Wikipedia:錢幣學專題/條目指引因為有指引的地位並沒有隨着主頁面遷入維基專題命名空間，而是更名後留在Project空間中。另外，如果確認獨立格式手冊空間，應該修改Wikipedia:方針與指引#方針及指引的用詞。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月4日 (三) 14:01 (UTC)
  • (：)回應這次主要是因為格式手冊在社群討論前就出現了「現存命名空間」，與上次設置維基專題空間不同，上次維基專題空間在本地討論與申請前並不存在有關的「現存命名空間」。所以我想現在的討論就可以「我們要不要使用這個現存命名空間」。我認為拆分有一定的合適性，畢竟格式手冊也有其自身的一些獨特性。關於延伸議題格式手冊「放進現存命名空間」後，NT、NC是不是也要有專屬命名空間之事可以之後再議，畢竟他們倆個現在「沒有現存命名空間」也是事實，目前唯一有「現存命名空間」的是格式手冊。至於格式手冊如果確定要放在之前基金會開設的「現存命名空間」的話，應該修改Wikipedia:方針與指引#方針及指引的用詞，這是當然的，如果本案獲得本地共識，並且調整好技術細節，在我「計畫時程」中「[方針] MOS從捷徑指引中移除或修改措辭」就包含了這個部分。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 23:41 (UTC)

    我覺得「MOS:」放在哪裡都不影響這一疑慮（即將完全符合Project空間用途的頁面遷出）。雖然我不懂技術細節，但我認MOS單獨作一個重定向空間並沒有什麼「不使用實在浪費」的，Wikipedia:格式手冊/子頁面也不會自動空出來。另外MOS空間即使形式上獨立，但是在和方針政策相關的規範上可能仍然要視作Project空間，比如有人想搜索方針相關字詞，就得在搜索頁面同時勾選「維基百科」、「MOS」，要查討論就得連talk都一起勾選了；有人喜歡不討論就修正方針指引字詞被提報了，就要同時禁制Project和MOS空間……反倒可能操作上不方便。而主題和專題拆出去不會有這樣的問題。「格式手冊也有其自身的一些獨特性」，未見。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月5日 (四) 08:36 (UTC)

    • 一個命名空間會有各種功能、統計功能，但重定向頁事實上用不到獨立的命名空間會提供的大部分功能，因此一個獨立的命名空間若只放了重定向頁，將會浪費獨立的命名空間會提供的大部分功能。　　　　但是我覺得能分開搜尋是一種好處。　　　　能分開禁制不是更好？搞不好有人只破壞格式手冊。　　　　格式手冊只是「提供一些使所有條目的編輯風格變得一致的準則」，「這些規則和條例，並非像法律條款一般堅若磐石。它們只是就一般情況而言，必須靈活運用。」。方針是所有使用者通常應該遵守的標準；指引是共識所支持的最佳做法。編輯者應嘗試遵守指引，但最好仍要以常識判斷是否合適，因為不排除會有例外情況；而格式手冊更接近對於條目撰寫方式的「建議」，只要在不違反方針指引下，格式手冊的「建議」可以選擇性不採用。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月8日 (日) 00:28 (UTC)

      1. 不假，MOS確實獲得了統計功能，但是為什麼要把它的統計功能從Wikipedia空間分開？我們還有幾千幾萬個ns number沒有使用，是不是也是浪費了那麼多ns number提供的功能？2. 設置「在Wikipedia:格式手冊的子頁面」也能單獨搜索。3. 罕見情況就不討論了，只是舉個例子。 4. Wikipedia不是什麼方針空間，也不是紅線空間，您這裡提出的「獨特性」我認為也適用於所有指引——甚至方針也可以IAR。另外Wikipedia空間還有數量不小的信息頁、論述，根本不需要人遵守，他們是不是也不適用於Wikipedia空間？按我對於Wikipedia空間的理解，這會導致Wikipedia空間的基礎分崩離析。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月9日 (一) 10:40 (UTC)

      • 其他ns number又還沒有被「分配」，哪來的「浪費」一說？現在明顯就只有格式手冊MOS被基金會「擅自」分配了，且是「已經」被「分配」了，那麼怎麼跟你那些「還沒有被分配」的ns number比較，不公平，不苟同。分一個格式手冊哪會造成Wikipedia空間的基礎分崩離析？？哪邊崩了？？怎麼個崩法？？完全不認同也不認為把一些頁面歸類到一個「已經」被基金會擅自「分配」的空間會造成甚麼鬼東東崩掉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月9日 (一) 11:51 (UTC)
        • 其實沒話浪不浪費，維基上有不少功能原先也是早已配置但處於停用狀態，直到我們說有需要時才啟用（例如zh-mo和zh-my功能早在2009年配置，但直到2013年和2018年等到我們說有需要時才啟用），但停用期間我們不會說浪費了，重點是我們需不需要。說到管理上的問題，現有情況如要禁制某人編輯格式手冊全系列的話，技術上衹需要設定「WP:格式手[冊册]」的前綴即可；但移到MOS空間的話，除了要設定「MOS:」前綴外，還要單獨對WP:格式手冊進行禁制設定（其他管理功能也如是），要做的功夫確實是變多了；而且還未知有沒有加重其他管理操作的問題。我想提案人有必要說明一下我們是否真的很有需要去對MOS:空間啟用更多頁面功能，以及這種做法帶來的缺點是否值得我們去犧牲，而不應僅僅說「不想浪費」，否則難免會讓人覺得很片面。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年12月12日 (四) 15:20 (UTC)
          • 如果是要從零開始——從「沒有這個命名空間」也「沒分配ns number」開始，確實要討論很多，要考慮很多諸如「我們值不值得開一個新的命名空間」，這種確實需要考慮到這種做法帶來的缺點是否值得我們去犧牲，討論完成之後才是去申請「分配ns number」，基金會同意後就會從「沒有這個命名空間」變成「有這個命名空間」，也「有分配ns number」，這時討論的主要議題就會變成「我們如何去使用這個已經被分配的命名空間」。；；而現在的情況不太一樣，已經不是從「沒有這個命名空間」也「沒分配ns number」要到「已經有這個命名空間要開始使用」，而是「基金會已經開了這個命名空間」且「有分配ns number」，那我覺得討論「我們如何去使用這個命名空間」會比「我們當作沒看到這個命名空間」來的好。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月13日 (五) 05:56 (UTC)

(：)回應：@Cdip150：我的理由其實很簡單。2020年底社群其實就有不少聲音希望格式手冊(MOS)升格為「真」命名空間（非偽），包括但不限於User:Pseudo_Classes等人（Wikipedia_talk:命名空間/2021年設立新命名空間及偽命名空間#小結2），我現在只是把這些聲音「複誦」出來而已。四年後，基金會正是提升格式手冊(MOS)升格為「真」命名空間（非偽），且在 前次討論（3個月前）提出此提議時，也沒有明顯的反對聲浪，因此我才在方針版正式將此提議進行提案。且我是認為，未來格式手冊歸檔後，原「維基百科:格式手冊/標點符號」將得以變成「格式手冊:標點符號」看起來更易讀，且現行前面的「維基百科」是多餘的，我們都知道這是「維基百科」的格式手冊，無須多提，因此若能以「格式手冊:標點符號」作為標題名稱會更好（技術原理：格式手冊若被設定為MOS的中文名，此時[[MOS:標點符號]]等同於[[格式手冊:標點符號]]，就如同「維基百科」被設定為Wikipedia命名空間的中文名，因此[[Wikipedia:格式手冊]]等同於[[維基百科:格式手冊]]一樣道理）；僅此而已。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月13日 (五) 06:31 (UTC)

我覺得可以在MOS:空間中分配「MOS:標點符號」的重新導向，方便檢索。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月16日 (一) 00:24 (UTC)

(：)回應：(1)我不認爲這樣比較有何不公平之處，是否分配爲真·命名空間，只要我們並不去用它存放實際內容，對我們來說並沒有區別。 (4)只是個人對於維基百科命名空間一個比較粗淺的理解。我覺得如果格式手冊能分出來，其他方針指引也能分出來，我們就不好解釋這個「Wikipedia」空間究竟有什麼作用了。 (a) 「我們如何去使用這個命名空間」：用途自然是避免語莫西語跨語言連結衝突。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月16日 (一) 00:45 (UTC)

本子討論段的子段落最早的實質異議 發言於2024年12月5日 (四) 08:36 (UTC)，並在之後已獲正當合理的回應且沒有再提出新的異議，在本子討論段的子段中，最後發言於2024年12月16日 (一) 00:45 (UTC)，本條發言發言於2024年12月20日 (五) 00:38 (UTC)，因此離最後發言已逾三日，且期內發言人未能對後續意見進行有效異議，因此根據WP:7DAYS之條文引述的規定，此意見依法判定為「問題已解決」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月20日 (五) 00:37 (UTC)

本子段落的「子共識」：
　● 不應(►)移動到新命名空間
　● 新命名空間可作相關重新導向方便檢索

不反對此提議，另外也不反對上面提到的為命名常規與關注度指引單設命名空間的提議。Sanmosa _新朝雅政 2024年12月4日 (三) 14:28 (UTC)

• (：)回應：@Sanmosa：先一項一項來吧，格式手冊優先吧。不然一下「綑綁」太多方針指引也不好討論。如果格式手冊通過了，屆時，再來討論命名常規與關注度也不遲。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月4日 (三) 23:01 (UTC)

  這點我也不反對。Sanmosa _新朝雅政 2024年12月5日 (四) 01:21 (UTC)

  格式手冊....不如叫「體例」--百無一用是書生 (☎) 2024年12月5日 (四) 03:06 (UTC)

  • (？)疑問：@Shizhao：所以要將「体例」也納入別名設置嗎？ 所以上面的描述要變成『將「格式手册」、「格式手冊」、「体例」和「體例」設定為「MOS」的別名』嗎？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月5日 (四) 04:27 (UTC)

    不反對同時將格式手冊與體例設定為MOS空間的別名。--冥王歐西里斯（留言） 2024年12月5日 (四) 04:57 (UTC)

    Shizhao說的大概是將格式手冊更名為體例？ ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月5日 (四) 08:36 (UTC)

    傾向認為可以做為別名，但不要把格式手冊這個名字換掉--SunAfterRain 2024年12月13日 (五) 08:47 (UTC)

本子段落的「子共識」：
　● 不反對移動到新命名空間
　● 建議更名或新增別名「體例」（但共識不夠明確）

• (！)意見：我一直認為中文維基百科應當有一個幾乎所有正式工具書都會有的《凡例》頁面，但我認為《格式手冊》並不是這樣的頁面。「格式手冊」是較為複雜的，供編者閱讀的頁面；而「凡例」是供讀者閱讀的，力求簡潔的頁面。這兩者就像百科全書的《凡例》（往往只有兩三頁）和編委會編輯部內部的格式規定（想必非常複雜）一樣的區別。--自由雨日🌧️❄️ 2024年12月16日 (一) 09:49 (UTC)

  小結：
  　● 格式手冊和體例應共存
  　● 格式手冊面向編者
  　● 體例面向讀者

(－)反對拆分：格式手冊頁面本寥寥無幾，且性質未全然有別於其他方針與指引，不若維基專題而難成獨立體系，實無必要特別自計畫命名空間劃出。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月5日 (四) 10:11 (UTC)

然而現在的情況是MOS因為其他緣故（而非中文維基百科的請求）而已經成為一個獨立的命名空間了，這獨立的命名空間也不好空著。Sanmosa _新朝雅政 2024年12月5日 (四) 12:27 (UTC)

• 誰說空間不能「只有寥寥無幾」的頁面？誰說空間必須「成獨立體系」的頁面？沒有人。也沒有道理。 且現在不是「特別自計畫命名空間劃出」，而是基金會「已經劃出一個空間」在那兒了-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月5日 (四) 22:56 (UTC)

  本子討論段的子段落最早的發言 發言於2024年12月5日 (四) 10:11 (UTC)，並在之後已獲正當合理的回應（發言人未對本段的其他任何發言另做未表態視為已獲合理回應），且本子討論段的子段的最後發言時間為2024年12月5日 (四) 22:56 (UTC)，而此時此刻是2024年12月9日 (一) 00:27 (UTC)。在本子討論段的子段中，最後發言已逾三日，且期內發言人未能對後續意見進行有效異議，因此根據WP:7DAYS「為確保討論的連貫性，任何正當合理的意見若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何使用者重複提出，可提示該使用者相關意見已獲解決，除此以外無須另作回應。」的規定，此意見依法判定為「問題已解決」。請勿再重複提出類似意見，以免違反方針或指引。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月9日 (一) 00:27 (UTC)

  • 如對以上言論有異議，請去提案修改WP:7DAYS，而不是在本子討論段「的子段落」做出任何發言。本子討論段「的子段落」已Dead，請在本案中開啟子討論段的「新的子段落」，如：下方重新縮排處。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月9日 (一) 00:36 (UTC)

    本子段落的「子共識」：
    　● 格式手冊暫時必要特別自計畫命名空間劃出
    　● 不支持(►)移動到新命名空間

• 重讀了一下整段討論，對於將現有格式手冊「自計畫命名空間劃出」有異議存在，但針對設置格式手冊命名空間（別名、令子頁面有效及介面中文顯示）以方便檢索的部分較無異議，因此已分拆本案，在下方立了個折衷方案，歡迎討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月17日 (二) 09:07 (UTC)

折衷方案

上面有存在短期未能取得共識之反對移動至新命名空間的意見存在，但我注意到魔琴的這則意見「可以在MOS:空間中分配「MOS:標點符號」的重新導向，方便檢索」，結合「因此若能以「格式手冊:標點符號」作為標題名稱會更好」：

1. 我們可以設置「格式手册」和「格式手冊」為「MOS」的別名，以建立「MOS:標點符號」=「格式手冊:標點符號」方便檢索，同時開啟子頁面，解決部分格式手冊的父—子關係問題。格式手冊主要文字仍寫於「WP」命名空間，並且不(►)移動現存的任何格式手冊。
2. 「體例」是否設置格式手冊的別名應另立案擇日再討論；
3. 是否要創建「體例」編寫「面向讀者」的格式手冊並與現有「格式手冊」（面向編者）並存應另立案擇日再討論；
4. 「格式手冊」要不要放到新命名空間（即格式手冊移動案）應另立案擇日再討論；

• 折衷方案則是上述第一點，只對MOS:空間進行設置，使「MOS:標點符號」得以分配方便檢索，而其它要不要移動、體例是另外寫還是就指向格式手冊則另外擇日再討論，現有格式手冊維持原樣。

即將此案分拆為技術案（只設置命名空間，執行本地化）、修改案（體例如何處理）及移動案（格式手冊移進設置完成後的命名空間），先只做第一案折衷方案，看大家能不能接受。（我覺得「MOS:」能顯示為「格式手冊:」是要做的吧，這樣才有本地化（翻譯）啊，其他命名空間都有設置中文名，可「MOS」是英文）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月17日 (二) 09:00 (UTC)

作為提議人(＋)支持。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月17日 (二) 10:11 (UTC)

同意，並可先建立對應頁面重新導向。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月17日 (二) 10:51 (UTC)

(＋)支持設定在地化別名與開啟MOS命名空間的子頁面功能。--冥王歐西里斯（留言） 2024年12月17日 (二) 11:38 (UTC)

不反對，好歹先本地化，畢竟已經存在了。Sanmosa _蚌埠 2024年12月18日 (三) 11:22 (UTC)

同意。--Hamish T 2024年12月18日 (三) 15:54 (UTC)

討論串改走RFC機制。Sanmosa _蚌埠 2024年12月20日 (五) 00:58 (UTC)

@A2569875：抱歉啊，主要是因為VPP長度過長的緣故，我不得不挪動一下討論串的位置。Sanmosa _蚌埠 2024年12月20日 (五) 01:10 (UTC)

(＋)支持：終於跨出一步了。空氣小貓（留言） 2024年12月20日 (五) 15:46 (UTC)

因涉及超過一個總政策，故移回客棧，待討論完結一併存檔。另此部分修訂案應有共識，可予公示。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月27日 (五) 23:29 (UTC)

如果不(►)移動的話，我覺得不需要子頁面功能，應該不會有人在捷徑重定向頁裏找父子頁面——要找的話在正式頁面已經找了，不會點進重定向後才找。到真的要移動時才啟用子頁面功能也未遲，故現階段(－)不支持子頁面功能。別名和重定向則(＝)中立。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年12月29日 (日) 04:27 (UTC)

• 反對已經七日未有發言後才來發言。根據上述Ericliu1912提出的主流共識，顯示出主流共識是支持子頁面，且如果未來要移動才「再提出新請求」等於會去煩phab好幾次，強烈反對此種做法。因此我主張既然有有放八日未有異議的主流共識存在，且此意見為「不支持」而已，因此我主張子頁面仍含在此案內，不對八日前的修訂再進行再異動，否則子頁面要拆去哪一案？反對將案件流程複雜化、反對「任何可能要多煩幾次phab」的提案、提議、意見及建議。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月29日 (日) 04:37 (UTC)
  • 且我認為有些存檔可以放MOS空間，此時需要子頁面。要不要放可以容後討論，討論結果可能是要或不要，無法預測，但一旦要放就必須再次去煩phab（如果這次沒開）這樣可能會讓phab對中文維基有出爾反爾、、朝三暮四的印象，故，強烈反對此意見-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月29日 (日) 04:40 (UTC)

結合A2569875上面提到的與phab溝通的問題，我覺得街燈你之前説的這話其實是有點道理的，因此你現在説的這話我倒是不理解了。Sanmosa _蘭絮 2024年12月29日 (日) 08:31 (UTC)

重新留意敝人之前説的這話：「直到我們說有需要時才啟用（例如zh-mo和zh-my功能早在2009年配置，但直到2013年和2018年等到我們說有需要時才啟用），但停用期間我們不會說浪費了，重點是我們需不需要」，MOS現在還是作為重定向來用的話，敝人當下實在看不到子頁面功能現在有何需要？（如果重定向是需要子頁面的，基金會當初為何不啟用子頁面？）同一段話的另一點，2013年我們請求phab去啟用zh-mo而不啟用zh-my，然後2018年才去請求啟用zh-my，難道2018當年phab認為中文維基這樣多煩一次是出爾反爾、朝三暮四？我覺得太誇張了。我的意見是——現在有需要的現在啟用，將來有需要的將來才啟用，而不是現在就啟用將來都不知會不會用的功能。當然，我是不支持，但也不是反對，您們還是堅持要啟用的話悉隨尊便。另外，「有些存檔可以放MOS空間」？可否舉個例子說明哪些存檔會放到MOS空間裏？--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年12月31日 (二) 17:28 (UTC)

@A2569875、Pseudo Classes。此外，@Cdip150：你有必要回應Pseudo Classes下方對你的言論的質疑，不過基於你上面的説法，那我根據前例理解成你並不是真的想要反對這個提案。Sanmosa _蘭絮 2025年1月1日 (三) 01:35 (UTC)

• 我已經「折衷」退讓了，現在是底線了，如果要再退讓的話，我就會直接變成(－)反對整案，因為這樣搞成原本跨一步被弄成只剩半步根本沒有做的意義。只能跟User:Pseudo Classes說抱歉了，原本要跨出的一步被街燈毀了。不過為了避免「要跟User:Pseudo Classes說抱歉」的話，那我只能跟U:Sanmosa說抱歉了，因為如果街燈怎樣都不肯退讓，我也說這是我底線了，因此我們可能再創七萬字的客棧方針區板塊。但是我非常不想讓上述兩種情況的其中一種發生。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月29日 (日) 08:53 (UTC)

  倒不用跟我道歉，下方還有個遠更長的討論串呢，那邊那個討論串早就破9萬了。Sanmosa _蘭絮 2024年12月29日 (日) 09:10 (UTC)

  @A2569875、Sanmosa：所有「應該」語句純屬臆測，無法作為客觀事實。倘若Cdip150無法提供更具說服力的意見，我是認為可以按照重行公示簡易規定重新進入公示程序。空氣小貓（留言） 2024年12月29日 (日) 09:17 (UTC)

  從我自己過去的經驗來看，你真要這樣做的成功率恐怕不太樂觀，除非真到了那個地步時你選擇VPO。Sanmosa _蘭絮 2024年12月29日 (日) 09:20 (UTC)

  我想問一下「子頁面」是什麼操作？可舉實例以便參考。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年1月1日 (三) 06:57 (UTC)

  • @Ericliu1912： 例維基百科:互助客棧/方針是維基百科:互助客棧的「子頁面」。以上例為例，重定向頁也是可以分「父/子」方便管理所引的（在標題下「維基百科，自由的百科全書」的下方會標示「子頁面」的「父頁面」是誰）條目空間就無此設定，例如A/B測試不會被視為A的「子頁面」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 07:02 (UTC)
    • (～)補充WP:捷徑也是有子頁面的，例如WP:DYKC/A是WP:DYKC的「子頁面」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 07:18 (UTC)

      @A2569875：道理我懂，但格式手冊多半是兩級制，換算成捷徑就是一級制（MOS:某），有什麼情況需要子頁面嗎？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年1月2日 (四) 09:54 (UTC)

      • WP:DYKC/A是兩級捷徑。道理我懂，但為什麼鴿子那麼大-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月2日 (四) 10:35 (UTC)

(＋)支持增加「格式手冊」和「格式手册」兩個別名。另外注意到其他命名空間的規範名稱均是英文全寫（例如維基百科命名空間的正名是「Wikipedia」，「維基百科」僅爲別名之一），若是準備日後移動格式手冊頁面，爲保持一致，如果可行，建議將命名空間名稱定爲英文名「Manual of Styles」，將「MOS」定爲別名之一。（這當然也可以在移動的時候才向Phab提出，和開啓子頁面一樣，對於執行的時機我保持(＝)中立，私以爲不急。）從站務隱退幾年，怎麼感覺站務討論都變得有火藥味了。--1F616EMO（喵留言） 2025年1月2日 (四) 14:11 (UTC)

提議維基百科:抄襲併入維基百科:不要包含原始資料的副本

想法： 維基百科:抄襲 ：

現行條文 抄襲指的是將他人所貢獻的作品，在沒有提供足夠的作者權益資訊之下，將其語言以及思想變成是自己的作品（在學術寫作中，如果未能在論文中充分標註來源，而借用他人的任何想法或語言，便會被視為抄襲。無論來源是已出版的作者、其他學生、無明確作者的網站、販售學術論文的網站或其他任何人：將他人的工作據為己有就是偷竊，這在所有學術情況下都不能接受，無論你是故意還是無意這樣做。）該來源提供了各種抄襲類型的例子，包括逐字抄襲、拼湊抄襲、不充分的改寫、未標註來源的改寫和未標註來源的引用。劍橋大學將抄襲定義為：「將他人作品的部分或全部內容當作自己的作品提交，而沒有適當標明來源，無論是否有意圖欺騙。 維基百科有三項核心內容方針，其中兩項很可能在不經意間產生抄襲問題。非原創研究防止我們將自己的想法放入條目當中，而可供查證要求條目必須基於可靠的已發表來源。這些方針意味著維基百科人非常容易被指責為抄襲者，因為我們非常執著於來源，但不能在內容上太過接近來源文本。由於抄襲的發生可能沒有欺騙的意圖，因此我們的關注方向應當放在教育編輯者清理條目內容。

提議條文 抄襲指的是將他人所貢獻的作品，在沒有提供足夠的作者權益資訊之下，將其語言以及思想變成是自己的作品。各種抄襲類型的例子包括逐字抄襲、拼湊抄襲、不充分的改寫、未標註來源的改寫和未標註來源的引用。 我們建議編輯者應引用多方來源，條目的每一分段或單一事件應避免完全依靠同一個網站或書藉（每單元），當中包括官方網站及書藉。我們不建議編輯者原文引錄來源的任何連續句（透過轉述他人直接發表的關鍵言論除外）。對於產品或服務的使用條款或詳細使用方法，應使用外部連結功能連結至記載相關資訊的官方網站或可靠來源。

以上！--唔好阻住我愛國（留言） 2024年12月6日 (五) 07:36 (UTC)

(！)意見，你的條文「逐字抄襲、拼湊抄襲、不充分的改寫」，你這樣改會有問題，試問如何界定拼湊抄襲？
我常把日文內容翻譯到中文條目裡，別人也是跟我一樣翻譯，同樣一道菜，從原本日本菜，轉換成中文菜，翻的內容本來就會有雷同，如何界定這是拼湊？如果要把條文這樣改，我隨翻日文內容都能跟巴哈姆特的動畫介紹文雷同，很容易觸犯維基百科，你所寫的拼湊抄襲，到時候隨便都能被檢舉我抄了誰，這是拼湊抄襲，因為翻譯內容雷同。
你把這些條文寫得太詳盡、細節太仔細規範，只會造成文字獄的問題。--Znppo（留言） 2024年12月6日 (五) 08:43 (UTC)??1

第二段才是定義，主要限制如需全面講述整個事件的起承轉合，請拿出至少三個來源講述，避免依賴一個來源。--唔好阻住我愛國（留言） 2024年12月6日 (五) 08:54 (UTC)

1. 拼湊抄襲是現行條文就有的，請仔細讀。
2. 將日文可靠來源內容直接翻譯寫入中文維基百科當然屬於「抄襲」，看來你之前已經有大量侵權編輯需要檢查了。——自由雨日🌧️❄️ 2024年12月6日 (五) 08:54 (UTC)

請求@0xDeadbeef、人间百态、魔琴協助： ——自由雨日🌧️❄️ 2024年12月6日 (五) 09:02 (UTC)

維基百科翻譯本來就被允許的，Wikipedia:翻譯指引。你覺得內容抄襲，請自行提出證據。--Znppo（留言） 2024年12月6日 (五) 10:53 (UTC)??1

《翻譯指引》說的是可以翻譯外文維基百科，而不是可以翻譯外文來源寫入中維。--自由雨日🌧️❄️ 2024年12月6日 (五) 10:58 (UTC)

請問使用者魔琴，你接連在我的發文底下，發出兩則「react|??|魔琴」，請問有何涵義？我看不懂你的意思，能否使用一般中文敘明你的意思。--Znppo（留言） 2024年12月6日 (五) 14:23 (UTC)

（編輯衝突）也就是說我把《哈利·波特》翻譯成中文，就可以貼上維基百科了？那為什麼出版社還要去爭翻譯版權？ ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月6日 (五) 14:33 (UTC)

我又沒有把哈利波特完整翻譯到中文維基百科裡，你舉例失當，我僅是看完整部作品，融會貫通，以我自己的語意，簡擇其要，寫出符合介紹類之文。要翻譯哈拉波特10餘本小說，我沒那個精力。--Znppo（留言） 2024年12月6日 (五) 14:38 (UTC)

要不我舉一個沒那麽極端的例子吧。以kotobank網站集合的各日文百科全書與辭典對堀河天皇的記載為例子，如果我沒理解錯魔琴的意思的話，他應該會覺得一個用戶把那些記載整篇翻譯成中文後直接貼上中文維基百科是不被容許的。Sanmosa _新朝雅政 2024年12月6日 (五) 14:44 (UTC)

總之，我已表達我的說法了，自由雨日說要檢查我的過往編輯，請自便。我靜候各位的侵犯版權通知，後續不再回應。--Znppo（留言） 2024年12月6日 (五) 14:54 (UTC)

@自由雨日：值得留意的是WP:抄襲並非現行方針指引。Sanmosa _新朝雅政 2024年12月6日 (五) 13:46 (UTC)

哦哦，沒注意。不過我認為上面Znppo說的顯然和HK5201314提出的修訂完全沒有關係，因為「將外文來源翻譯寫入中文條目」本就是毫無爭議的抄襲。--自由雨日🌧️❄️ 2024年12月6日 (五) 13:58 (UTC)

然而維基百科:頁面存廢討論/疑似侵權是基於法律方針而有的。--唔好阻住我愛國（留言） 2024年12月6日 (五) 14:03 (UTC)

WP:頁面存廢討論/疑似侵權僅有一處提到「抄襲」，而且那裏「抄襲」的用法甚至還不準確，此外該頁面完全沒有提到WP:抄襲頁面。Sanmosa _新朝雅政 2024年12月6日 (五) 14:23 (UTC)

如果是翻譯日文維基百科內容，則不會有侵犯版權問題，只需要在編輯摘要是記得表明出處就行。根據相關版權法律，以Wikipedia:近似複述#創意表達的相關信息來看，「雷同」與「抄襲」之間是由衡量空間的，假如原描述有創意表達的部分，原封不動地被翻譯到條目中，是不合理的。只有簡單的事實陳述的情況才可以直接翻譯、引用、使用。--0xDeadbeef (留言) 2024年12月7日 (六) 00:54 (UTC)

然而從Znppo上方的表述和其之後解釋的自相矛盾，結合他編輯記錄中相關內容、編輯摘要、日文維基百科對應條目等來看，我實在難以認為他所說的「翻譯」是指「翻譯日文維基百科」，而是「翻譯日文來源」。這種情況該如何進行著作權調查思考... ——自由雨日🌧️❄️ 2024年12月7日 (六) 02:07 (UTC)

其實很難查證，甚至照翻日文來源與看了日文來源來寫出自己的理解之間的界綫本身有些時候也很模糊（比如我上面舉的堀河天皇的例子）。Sanmosa _{大統領님의政變方式은} 2024年12月7日 (六) 14:14 (UTC)

另外，這樣改還有數個好處，當中包括官方資訊不能是條目主要來源；愛好者資訊不能完整表達，特別是車輛及路線資料；萬一有一個媒體倒閉，還有另一個媒體可以支撐條目的來源需求。最尾那句是補足原始資料副本-不應在條目記錄條款細則。--唔好阻住我愛國（留言） 2024年12月6日 (五) 09:21 (UTC)

（就「愛好者資訊不能完整表達，特別是車輛及路線資料」而言）如果你是為了這個目的來提案的話，那我根據WP:FORUMSHOP一條反對你的提案，請不要把你自己開的WP:互助客棧/條目探討#公車迷將過多愛好者內容加入條目之限制方針或指引討論當空氣。Sanmosa _新朝雅政 2024年12月6日 (五) 13:36 (UTC)

這個公車迷討論不是我開的，而且開這個討論目的不單指公車迷，而是因為有不少條目僅依靠一個來源，所以採用的字眼是「建議」，而不是「必須」。--唔好阻住我愛國（留言） 2024年12月6日 (五) 13:59 (UTC)

例如公司或學校條目，編輯者較常僅引用其官網作為來源編輯內容，個人主張單一事件應採用至少一半是官網，一半是第三方或至少兩篇第三方，這是回應WP:不要包含原始資料的副本的精神。--唔好阻住我愛國（留言） 2024年12月6日 (五) 14:10 (UTC)

就算正式的指引條文寫的是「建議」，條文的實際效果其實還是硬性規定，就算換成其他指引也一樣，這點我希望你留意。再者，你在這裏説了「愛好者資訊不能完整表達，特別是車輛及路線資料」，有鑒於VPD那邊的討論裏你有著意圖完全禁止一切巴士路線資訊的危險傾向，就算這真的不是硬性規定，我認為你很可能會在條文通過後進行大量操作使這非硬性規定事實上變成硬性規定，這點我非常擔憂。Sanmosa _新朝雅政 2024年12月6日 (五) 14:21 (UTC)

WP:假定善意，謝謝！--唔好阻住我愛國（留言） 2024年12月6日 (五) 15:05 (UTC)

另外，我沒有打算 「完全禁止一切巴士路線資訊的危險傾向」，因為維護相較吃力而不討好。另外，這個提案還是要收緊「官方資訊」的濫錄。，畢竟這裡不是為官方服務。--唔好阻住我愛國（留言） 2024年12月6日 (五) 15:10 (UTC)

那我暫且收回我的反對意見，但如果你在這條文通過後利用這條文來試圖完全禁止一切巴士路線資訊，我保留就此提報你的權利。Sanmosa _{大統領님의政變方式은} 2024年12月7日 (六) 01:18 (UTC)

除了上面的反對理由外，我也就提案條文本身的不合理之處給出一個(－)反對理由：「同一篇線上文章或書藉（每單元）引用的資訊不應超過該文章資訊量的40%」裏的「40%」作為硬性標準並不合適，用Shizhao的話來説這「40%」就「是個毫無依據的拍腦袋數字」。Sanmosa _新朝雅政 2024年12月6日 (五) 13:44 (UTC)

40%是一個建議的浮動數字，原意是避免就一件事引用單一來源。--唔好阻住我愛國（留言） 2024年12月6日 (五) 13:54 (UTC)

然而WP:不要包含原始資料的副本是正式指引，你把「40%」寫進去就相當於把「40%」弄成硬性標準了。此外，如果「40%」真的如你所言是「一個建議的浮動數字」的話，那這個「浮動」有標準嗎？寫進正式規則但沒有標準的「浮動」要麽就是會被不當詮釋，要麽就是有了與沒有一樣，那倒不如不要提這個數字。還有，我再想了一下，我説的「毫無依據的拍腦袋數字」問題與你給的「40%」是否「浮動」也沒有直接關係，你給的「40%」就算真是「浮動」也還是「毫無依據的拍腦袋數字」。請問「40%」的依據在哪裏？Sanmosa _新朝雅政 2024年12月6日 (五) 14:14 (UTC)

@Sanmosa:已刪除40%--唔好阻住我愛國（留言） 2024年12月6日 (五) 15:02 (UTC)

@0xDeadbeef @Sanmosa @Znppo @自由雨日 @魔琴:

如無反對意見，一日後開始公示流程。--唔好阻住我愛國（留言） 2024年12月13日 (五) 00:32 (UTC)

小挑刺：條文中不要用「我們建議」，可以把我們建議編輯者應引用多方來源改成編者應引用多方來源，並把至於產品或服務的使用條款或詳細使用方法，我們建議使用外部連結功能，鏈接至記載相關信息的官方網站或可靠來源。 改成對於產品或服務的使用條款或詳細使用方法，應使用外部連結功能鏈接至記載相關信息的官方網站或可靠來源。--0xDeadbeef (留言) 2024年12月13日 (五) 01:12 (UTC)

已改。--唔好阻住我愛國（留言） 2024年12月13日 (五) 15:53 (UTC)

7日無人反對，現就本提案進行7日 公示，由2024年12月14日至2024年12月21日止。--唔好阻住我愛國（留言） 2024年12月14日 (六) 03:54 (UTC)

(－)反對，不要將不同問題混為一談。--dringsim 2024年12月6日 (五) 16:00 (UTC)

@沈澄心:只接受WP:建設性意見，謝謝配合！--唔好阻住我愛國（留言） 2024年12月6日 (五) 16:44 (UTC)

(－)反對，不應該不建議編輯者原文引錄來源的任何連續句，如果來源文字是沒有版權，而且文字本身的百科性極強，那麼直接引錄不是問題。--Peck2442 2024年12月19日 (四) 15:15 (UTC)

不建議不等於不容許。

如果來源文字是沒有著作權，前提是要同時提供一份CC BY SA文件證明沒有著作權，有的話用常識繞過就行了。

文字本身的百科性極強，那麼直接引錄不是問題。—>你肯定這不是抄襲？--唔好阻住我愛國（留言） 2024年12月19日 (四) 16:19 (UTC)

另外知會@0xDeadbeef @Sanmosa @Znppo @自由雨日 @魔琴有新意見。--唔好阻住我愛國（留言） 2024年12月19日 (四) 16:49 (UTC)

1. 這項討論的標題是「提議維基百科:抄襲併入維基百科:不要包含原始資料的副本」。抄襲是指將他人的全部或部分作品變成像是您自己的作品，而沒有適當標明來源，所涉及的文字是融入條目中的；包含原始資料的副本（英語：include the full text of lengthy primary sources）是指在條目中完整列出長篇原始資料（顯然應帶有來源信息），而不作適當刪節，所涉及的文字嵌入到條目中，是條目的評述對象。兩個不同的問題如何能夠合併？！（當前版本的WP:NPS確實提到了「複製其他版權已經過期的百科全書內容或以其作為寫作的基礎」云云。在英維，這個問題是放在Wikipedia:Plagiarism討論的。en:WP:NPS寫道：「For guidelines for using compatibly licensed encyclopedic text in Wikipedia articles, see Wikipedia:Plagiarism § Copyright expired sources.」我認為WP:NPS應當重新翻譯。）
2. 提案「建議編輯者應引用多方來源」，這對解決抄襲或包含原始資料副本問題有什麼幫助呢？寫條目時同時從《辭海》和《中國大百科全書》抄？還是往條目里塞某部法規時同時引用北大法寶和《戶口管理法律法規規章政策匯編》？不知道這份提案是要解決什麼問題，提案者似乎也沒有說明，想法：，然後是不知所謂的條文修訂，以上！，簽名，沒有了！只接受WP:建設性意見，謝謝配合！那@HK5201314能否回答一下，你認為你這份提案，它的建設性體現在哪裡呢？
3. 哦，原來原因寫在另一條留言裡，跟提案隔了2小時：「另外，這樣改還有數個好處，當中包括官方信息不能是條目主要來源；愛好者信息不能完整表達，特別是車輛及路線資料；萬一有一個媒體倒閉，還有另一個媒體可以支撐條目的來源需求。最尾那句是補足原始資料副本-不應在條目記錄條款細則。」
   1. 官方信息不能是條目主要來源，和抄襲/包含原始資料副本的關係是？
   2. 愛好者信息不能完整表達，特別是車輛及路線資料，這個算是跟「不要包含原始資料的副本」有點關係，但是和編輯者應引用多方來源的關係是？
   3. 萬一有一個媒體倒閉，還有另一個媒體可以支撐條目的來源需求，和抄襲/包含原始資料副本的關係是？

--dringsim 2024年12月19日 (四) 15:19 (UTC)

首先，閣下在公示結束前最後兩日，也離閣下上一次發言也有13日也未曾對提案有進一步看法，有合理懷疑閣下是在擾亂。不過算，暫不深究。

——-

回應1，這裏是中文維基百科，沒有與英文維基百科對標的義務。

回應2，提案目標不「是寫條目時同時從《辭海》和《中國大百科全書》抄」，而是同一個事件/分段應引用至少2個來源。

回應3，看來閣下並沒有仔細閱讀及理解WP:建設性意見的精神。

回應4， 「官方資訊不能是條目主要來源」，你把整個官方網站抄下來做唯一來源，好嗎？那維基是官方的輔助工具？

回應5， 「愛好者資訊不能完整表達，特別是車輛及路線資料，這個算是跟「不要包含原始資料的副本」有點關係，但是和編輯者應引用多方來源的關係是」在這句出現之時，指的是同一分段來源最多應40%40%20%說明事件。你一條巴士路線就算官網40%，政府網站40%，你總要有20%第三方網站對標的義務，然而這個限制刪除了。

回應6，「 萬一有一個媒體倒閉，還有另一個媒體可以支撐條目的來源需求」這個是bonus ，既然已經有兩個來源表達同一件事，如果其中一個連結失效了，還有另外一個連結達到可供查證要求。--唔好阻住我愛國（留言） 2024年12月19日 (四) 16:44 (UTC)

關於回應3，是要解決Wikipedia_talk:愛好者內容#公車迷將過多愛好者內容加入條目之限制方針或指引討論這類的問題，本提案是第一步，禁止官方來源主導整個條目+不收錄使用條款及方法（往往這些條款也是抄官網）。及後還有第二步第三步。--唔好阻住我愛國（留言） 2024年12月19日 (四) 17:08 (UTC)

回應7，君不見我把抄襲原文濃縮至一小段至僅餘各項抄襲常見例子，因為主體仍是「不要包含原始資料的副本」，而不是「抄襲」，而那些例子正正是容易包含原始資料。--唔好阻住我愛國（留言） 2024年12月19日 (四) 17:20 (UTC)

@HK5201314：我覺得你或許應該考慮暫時撤下公示，而且我希望讓這討論串改走RFC機制。Sanmosa _蚌埠 2024年12月20日 (五) 01:20 (UTC)

我打算用3 Days 指引完成公示（昨日、今日、明日）。--唔好阻住我愛國（留言） 2024年12月20日 (五) 01:23 (UTC)

@沈澄心、Peck2442。Sanmosa _蚌埠 2024年12月20日 (五) 01:53 (UTC)

• 這裡是中文維基百科，沒有與英文維基百科對標的義務。WP:ENWPSAIDSAID。為何兩件不同的事，在英維能夠分清楚，到了中維就可以混為一談呢？
• 提案目標不「是寫條目時同時從《辭海》和《中國大百科全書》抄」，而是同一個事件/分段應引用至少2個來源。仍未回應對解決抄襲或包含原始資料副本問題有何幫助。
• 「官方信息不能是條目主要來源」，你把整個官方網站抄下來做唯一來源，好嗎？那維基是官方的輔助工具？和抄襲/包含原始資料副本的關係是？請注意區分思想的具體表達和思想本身。
• 「萬一有一個媒體倒閉，還有另一個媒體可以支撐條目的來源需求」這個是bonus ，既然已經有兩個來源表達同一件事，如果其中一個鏈接失效了，還有另外一個鏈接達到可供查證要求。那就請修改WP:可供查證，不要什麼都到處亂塞。
• 君不見我把抄襲原文濃縮至一小段至僅餘各項抄襲常見例子，因為主體仍是「不要包含原始資料的副本」，而不是「抄襲」，而那些例子正正是容易包含原始資料。閣下如果不知道什麼是「副本」，可以查閱《重編國語辭典》：「依照書籍或文件的正本謄錄或影印出來的複製本。」

--dringsim 2024年12月20日 (五) 08:04 (UTC)

@HK5201314。説真的，既然沈澄心他現在給意見給到這個地步了，你要不真的考慮暫時撤下公示？Sanmosa _蚌埠 2024年12月20日 (五) 09:00 (UTC)

至今他還沒有「正當合理意見」，只是強調「精神的重要性」，很難撤下公示。--唔好阻住我愛國（留言） 2024年12月20日 (五) 09:31 (UTC)

撤下公示的條件是能對提案給予改善建議，而不是透過強調論述或拖延時間妨礙成文化。--唔好阻住我愛國（留言） 2024年12月20日 (五) 09:40 (UTC)

@Sanmosa--唔好阻住我愛國（留言） 2024年12月20日 (五) 09:41 (UTC)

你這回應我看了我也不滿意，你好歹上點心吧。Sanmosa _蚌埠 2024年12月20日 (五) 09:49 (UTC)

回應1:兩邊制度完全不一樣，你堅持要與英維對標的話就另外提案對標。這裏的所有規條也全都需要經過本土化、在地化。

回應2:請提供WP:建設性意見指明意見格式對提案提供具體意見及改善方案，否則不當正當合理的意見，而不是不斷在我的回覆上死纏爛打。

回應3:請提供WP:建設性意見指明意見格式對提案提供具體意見及改善方案，否則不當正當合理的意見，而不是不斷在我的回覆上死纏爛打。

回應4:也說了這個是bonus，既然有引用多方來源重寫，那如何談上抄襲？

回應5: 《重編國語辭典》：「依照書籍或檔案的正本謄錄或影印出來的複製本。」—>也即是赤裸裸的完整抄襲。--唔好阻住我愛國（留言） 2024年12月20日 (五) 09:10 (UTC)

否，抄襲（不標註來源，將他人的作品變成像是自己的作品；為編寫百科條目，如果抄襲的文本不是百科性的，則還會伴隨改寫）和包含原始資料的副本（將原始資料原樣呈現）並不相同，甚至可以說是互斥的，除了（可能的）著作權侵犯外沒有什麼關聯。沒有讀者會把義勇軍進行曲條目中的歌詞、樂譜當成「維基百科編者編寫的百科性文字」。--dringsim 2024年12月20日 (五) 10:03 (UTC)

關於回應3，有少許補充。「維基百科不是官方的鏡像網站」，你首先在官網抄下產品介紹，在抄下歷史背景，然後貼上至維基百科內。那不是包含原始資料副本，還是什麼？--唔好阻住我愛國（留言） 2024年12月20日 (五) 09:23 (UTC)

改善方案早就提過了，那就是不予合併。--dringsim 2024年12月20日 (五) 09:45 (UTC)

由於有合理理由相信公示期間合理異議未獲妥為處理，現撤下公示。另：由於VPP過長，此討論串改走RFC機制。Sanmosa _蚌埠 2024年12月21日 (六) 04:08 (UTC)

因涉及超過一個政策，故移回客棧，待討論完結一併存檔。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月27日 (五) 23:29 (UTC)

公共交通路線條目格式手冊的相關討論

原標題為：建議Wikipedia:愛好者內容擴增「交通迷內容」方針之請求與討論

小弟最近遇到不太理性的H君交通迷，對於其之前在義大客運所撰寫的內容（包含過多愛好者資訊和路線圖中過多色彩標記和外文地名翻譯等）被刪除和多次被退回，在討論頁大動肝火、文字攻擊和強調路線番號用色是依據高雄市政府交通局路線性質給予顏色做使用等。尚不接受任何有效溝通和理解維基百科的方針、指引。

邀請擅長撰寫和制訂方針指引的維基人能協助進行Wikipedia:愛好者內容中擴增「交通迷內容」相關方針或指引，期能避免往後又有類似的情形發生。敬請參見先前討論過的公車迷將過多愛好者內容加入條目之限制方針或指引討論內容。

小弟在此通知之前參與過上述討論的閣下們@街燈電箱150號、@唔好阻住我愛國、@Tisscherry、@Sanmosa、@鐵路1、@Sanmosa、@YFdyh000，先謝過各位閣下們。--英國皇家歐拉夫王子（留言） 2024年12月13日 (五) 08:42 (UTC)

我個人是較偏向寫一本格式手冊，因為FANS是較主觀的論述。而交通格式手冊如無意外，成文後應成為全球專案中第一個有這本手冊。

當年由0開始計劃這本手冊（即是街燈管理員說不合要求的那本），這個point form也是我一手一腳編寫的，奈何來自交通迷的反對的意見太多了，而且交通條目維護員也不發言，所以我也不花時間把他轉化成完整段落，也因此一直也未能成文。--唔好阻住我愛國（留言） 2024年12月13日 (五) 15:41 (UTC)

如果有人願意改進那本手冊，我當然歡迎，因為我暫時沒有時間完善條文。在我的排程中，除了那兩個正/即公示項目外，還有「GAME/DYK/FA/GA」這個提案。--唔好阻住我愛國（留言） 2024年12月13日 (五) 15:47 (UTC)

我也覺得確實該明文訂下，但上次討論到哪我後來沒跟上，能稍微整理放上來嗎，謝謝。--提斯切里（留言） 2024年12月13日 (五) 16:27 (UTC)

感謝閣下的說明，小弟認同建立交通格式手冊的必要性，但看來沒有想像中的那麼容易。--英國皇家歐拉夫王子（留言） 2024年12月14日 (六) 01:34 (UTC)

最重要值得關注的是，如果可以，我較希望在重修手冊前先建立/修正下列指引，直接製作一本手冊可能有反效果。

• 「站外條目所有權及舉報機制」：因為那些願意花時間在交通條目的往往也是IP玩家，他們會在社群媒體宣稱他們擁有條目的控制權。一旦有合乎要求的修改，他們會馬上回退。
• 「維基百科不是」：目前並沒有關於交通類的篇幅，單憑一本格式手冊也仍不足讓管理員對他們進行封鎖。

--唔好阻住我愛國（留言） 2024年12月14日 (六) 03:43 (UTC)

（前）已有WP:條目所有權，是現行方針。（後）「單憑一本格式手冊也仍不足讓管理員對他們進行封鎖」不正確，如果該格式手冊是指引，那違反該格式手冊是可以被封鎖的情形。Sanmosa _{Samāʾun la-ʿamruka ʾaw ka-s-samā} 2024年12月17日 (二) 02:16 (UTC)

關於own，我說的是類似Module_talk:CGroup/SAO#香港_亞斯娜/明日奈？最後ipv6玩家的發言，引用外部勢力發言，干預維基共識。--唔好阻住我愛國（留言） 2024年12月17日 (二) 12:02 (UTC)

@Sanmosa--唔好阻住我愛國（留言） 2024年12月17日 (二) 12:03 (UTC)

我相信這只是個別事件，並不構成需要為此特意修訂規則的理由。Sanmosa _蚌埠 2024年12月17日 (二) 12:17 (UTC)

交通條目的干預比ACG還要大，不修正這個，無論有如何完善的條文也沒有用。--唔好阻住我愛國（留言） 2024年12月17日 (二) 12:28 (UTC)

我認為你完全是在誇大其詞，至少我看不到這種事情有廣泛地發生。Sanmosa _蚌埠 2024年12月17日 (二) 14:34 (UTC)

當然沒有明文報告啦！因為沒有人願意對此進行大規模維護工作（包括向社群報告及舉報）。我以前曾經做過這個工作，就是看見社群媒體的巴士愛好者對巴士條目大規模出征，鬥不過他們，所以才決定不再做巴士條目維護工作。你要知道交通路線條目至少也差不多2萬條，你要一個人每日關注2萬條條目是非常困難，而且要同時觀察交通愛好者的社群帳號、討論區，當有宣布出征時還要關注哪些條目受到影響，涉及哪些IP。沒見到有廣泛地發生是因為閣下並沒有關注交通愛好者的社群帳號、討論區。而且目前大多數交通條目也不符合基本要求之餘也沒有掛上模版，所以有這個錯覺出現。--唔好阻住我愛國（留言） 2024年12月17日 (二) 15:17 (UTC)

然而這依舊沒有超出WP:條目所有權涵蓋的範圍。Sanmosa _蚌埠 2024年12月17日 (二) 23:16 (UTC)

引用這個例子，發表所有權言論的是站外導演，並不是IPv6玩家，顯然已經繞過了條目所有權指引（不能因這個言論以own封禁ipv6玩家）。

———

恭喜User:Sohryu Asuka Langley Not Shikinami成功驚動粵語版的配音導演本人，成功嘔心了人家，成功成為了11年來同類無理取鬧的代表性例子，還成功讓維基醜給人看，成功令人家對維基感到嘔心。果然『不斷重複「塔利班」不會令你成爲「塔利班」』，而是你自己的行為令你自己成為「塔利班」的。有什麼事不用跟我說，去跟導演本人說 : [1]，[2]，[3]，[4]（User talk:2001:B011:E008:7AF6:D404:867B:2D8F:3D03|留言） 2024年11月22日, 星期五 (26日前), 06:27 pm (UTC+0)

——-

你要知道，交通條目的那些IP玩家也是像導演一樣這樣操作，只不過沒有人提上wiki討論區，因為只要提上討論區，那些帳號基本上與玩完無異。他們先在自己的社群媒體宣稱條目所有權，然後以IP玩家身分進行own行為。--唔好阻住我愛國（留言） 2024年12月18日 (三) 03:15 (UTC)

並沒有繞過。WP:條目所有權#一人所有權説的是「如果您發現編者持續敵視他人、進行人身攻擊或捲入編輯戰，請儘量不要理會毀損性編輯，並在討論頁發起討論，如情況持續可提交至維基百科:互助客棧/條目探討」，該用戶引用的是哪個或哪些人的言論不重要，只要能證明該用戶（通過引用他人言論的方式，雖然這個條件並不必要）作出持續敵視他人的行徑，那該用戶就能被視為在主張條目所有權。當然，我引述的條文裏的VPD連結是否需要換成其他頁面的連結是可以探討的地方。Sanmosa _蚌埠 2024年12月18日 (三) 11:29 (UTC)

Let’s say 以上方例子中，只有那4條連結及編輯記錄，並沒有wiki討論區的發言，那如何讓管理員相信他是在own?

xxxx

最後，我不太想花時間在此爭論格式手冊的前期準備。讓我給一個地面公共交通路線格式手冊點子結構，你就知道其複雜程度。

• 鐵路
  • A型路權路線
    • 州際鐵路 e.g. 歐洲之星
    • 城際鐵路 e.g. 台灣高鐵
    • 地鐵（Metro) e.g. 北京地鐵3號線
    • 輕軌 e.g. 澳門輕軌
  • B型路權路線
    • 誇市鐵路 e.g. 埼京線
    • 輕軌 e.g. 高雄捷運環狀輕軌
  • C型路權鐵路
    • 輕軌 e.g.香港電車
• 公交/巴士
  • 城際 e.g.灰狗巴士
  • 市區 e.g.九龍巴士1號線
  • 公車捷運系統 e.g.雙威線

--唔好阻住我愛國（留言） 2024年12月18日 (三) 12:18 (UTC)

你這話説得就很怪，一個用戶如果要試圖主張條目所有權的話，那他一定會想辦法發表或引述相關的言論，或是反覆把頁面回退到一個或若干個特定版本。其中，後者的行為正是我上方引述的條文裏説的「捲入編輯戰」，有些情況下發起或捲入編輯戰與主張條目所有權是全部或局部重合的，而且既往的慣例也不乏將反覆把頁面回退到一個或若干個特定版本的行為視為主張條目所有權的舉動。既然你列出來的格式手冊的結構如此複雜，那我建議你可以考慮將之拆分為若干個格式手冊，比如跨城市鐵路系統一個、單一城市內鐵路系統一個、非鐵路系統一個之類的，我感覺把你上面列舉的這些統統放到同一個格式手冊本來就不甚合理。Sanmosa _蚌埠 2024年12月19日 (四) 10:28 (UTC)

這個問題是交通條目主編不參與討論，及需要編寫的量非常大，部分名詞需要定義，還有在地化問題，特別是現時沒有其他語言維基可以參考，這裏成文了就等於全球首創。--唔好阻住我愛國（留言） 2024年12月19日 (四) 10:57 (UTC)

我自認為是在條目品質方面把控得比較嚴格的人，如有需要我可以幫忙把關，畢竟我也主導過相當數量的規則的制訂。交通條目主編不參與討論的問題可以通過邀請他們參與討論來處理。Sanmosa _蚌埠 2024年12月19日 (四) 11:06 (UTC)

改走RFC機制。Sanmosa _蚌埠 2024年12月21日 (六) 04:13 (UTC)

因涉及超過一個總政策，故移回客棧，待討論完結一併存檔。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月27日 (五) 23:29 (UTC)

歡迎就Wikipedia:格式手冊/無障礙/2025草稿提供意見

草稿基本上已翻譯完畢，頗具規模，但仍需潤色。部分子頁面也需要編寫，但最重要的還是了解中文屏幕閱讀器的習性（因為我沒用過）。--ItMarki^探討人生 2024年12月15日 (日) 17:02 (UTC)

zh-cn:稀有气体;zh-tw:惰性氣體;zh-hk:貴氣體;zh-sg:惰性气体;，要不咱換四書五經吧。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月16日 (一) 03:15 (UTC)

改成四書了。--ItMarki^探討人生 2024年12月16日 (一) 04:58 (UTC)

差異連結。@ItMarki：我會希望你簡要地説明一下你翻譯的版本與現版本有甚麽主要的分別。Sanmosa _蚌埠 2024年12月21日 (六) 04:21 (UTC)

添加內容、翻譯未翻譯的語句。--ItMarki^探討人生 2024年12月21日 (六) 05:09 (UTC)

具體添加了甚麽？（翻譯未翻譯的語句的部分我暫時沒有疑問）Sanmosa _蚌埠 2024年12月21日 (六) 05:12 (UTC)

@ItMarki。Sanmosa _蚌埠 2024年12月21日 (六) 07:25 (UTC)

#分數、#標註外文、#書寫系統、#圖像位置、#圖標和#其他垂直列表這些章節。--ItMarki^探討人生 2024年12月21日 (六) 08:30 (UTC)

@Sanmosa：這個坑是我開的，現行內容搬過來是十年前，很難說技術日新月異的今天我們用十年前的翻譯版會不會有問題。特別是你看到舊版頁面還有1024*768的屏幕。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月22日 (日) 06:22 (UTC)

啊，我以為這是按現enwiki的內容翻的。亲，我簽名那刻的時間是 2024年12月22日 (日) 07:08 (UTC)

/2025確實是按enwiki內容譯的 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月22日 (日) 07:14 (UTC)

我也只是循例問一下具體差異而已，我起初看到這討論串時其實也get不到提案具體要做甚麽，我相信如果我不問的話其他人大多也不知道。亲，我簽名那刻的時間是 2024年12月22日 (日) 08:53 (UTC)

@ItMarki如果你不追求硬體上的螢幕閱讀功能，可以使用Ctrl+Shift+U在Microsoft Edge上測試及驗證部分敘述是否與實際一致。如果使用WINDOW作業系統也可以嘗試使用預設的無障礙設定(文字轉語音)功能測試--Rastinition（留言） 2024年12月21日 (六) 08:37 (UTC)

感覺很爛，難以想象視障人士得用這種東西。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月22日 (日) 07:16 (UTC)

@ItMarki (～)補充行動設備也預設文字轉語音功能，你可以自行測試，macOS雖然是另外一套獨立系統，也有預設類似功能。--Rastinition（留言） 2024年12月22日 (日) 12:40 (UTC)

(～)補充Microsoft Edge似乎還可以，默認無障礙真的感覺很爛。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月23日 (一) 00:25 (UTC)

對於外文必須用lang，表示存疑，尤其是簡單、常見的英文詞彙，或者中文詞彙本身含拉丁字母的。--YFdyh000（留言） 2024年12月22日 (日) 07:30 (UTC)

執行上可以有一定的例外，比如Facebook、Instagram（IG）這類的詞彙確實不需要真的用到lang。另一種未來潛在會有同樣問題的詞彙是臺灣原住民人名，現在的臺灣原住民一般傾向於以拉丁字母而非漢字音譯表示其本名，比如Kolas Yotaka，站內此前有就臺灣原住民條目的命名作一定的討論，而臺灣現在已經開始把以拉丁字母拼寫的臺灣原住民人名當成中文一樣處理，如果外文必須用lang的規定要完全硬性地執行，這在未來將會導致一些尷尬的情況。就此，我會建議可以指明一些帶有非漢字字符的詞彙類型視為中文。亲，我簽名那刻的時間是 2024年12月22日 (日) 09:04 (UTC)

@ItMarki。Sanmosa 2024年12月22日 (日) 12:35 (UTC)

已修訂。--ItMarki^探討人生 2024年12月22日 (日) 13:23 (UTC)

special:diff/85405847(？)疑問：什麼是「含外文文字的中文專有名詞」？（這個詞組語義上就自相矛盾）--自由雨日🌧️❄️ 2024年12月22日 (日) 13:45 (UTC)

騰訊QQ、哆啦A夢、上證A股。常用非中文詞彙，存在一些邊緣情況，希望能互相理解、避免衝突、以常用軟件實際表現為準，比如Google（谷歌）、Facebook（臉書）在中國大陸算不算常用英文詞，或者頻頻爭論的日文漢字詞彙。NBA大概算常用？TCL、TLC又怎麼看待。--YFdyh000（留言） 2024年12月22日 (日) 20:16 (UTC)

「騰訊QQ」等你可以說是「中文占主要部分的專有名詞」，「上證A股」是「中文占主要部分的普通名詞」，「NBA」等是字母詞（前兩類也通常歸入字母詞）；「Google」等是「中文語境下常用的外文詞彙」（這類詞幾乎都是英文詞）。至於日文漢字詞則是日文不是中文。現在仍然將「日文漢字詞視作中文」稱為有「爭論」我實在是很無語……非正當合理意見並不是「爭論」。我當然知道「含外文文字的中文專有名詞」想表達什麼，也完全不是反對它想表達的內容；我是想強調作為格式手冊，用語必須嚴謹，「含外文文字的中文 專有名詞」肯定是不對的表達（外文並不是中文，這項規定也不應限於專有名詞）。綜合前述幾類，說成「字母詞，或中文語境下常出現的外文詞」即可。（如果要再嚴謹點，再額外排除「中文文本括注等專門說明外文詞彙時出現的外文」。）--自由雨日🌧️❄️ 2024年12月22日 (日) 21:48 (UTC)

Special:Diff/85411565 這樣寫可以嗎？--ItMarki^探討人生 2024年12月23日 (一) 04:26 (UTC)

我覺得不錯。另外還可以舉例「CD」這種純字母詞（相對於「A股」這種字母+漢字的字母詞而言）。——自由雨日🌧️❄️ 2024年12月23日 (一) 04:31 (UTC)

「希望能互相理解、避免衝突」指的是？--自由雨日🌧️❄️ 2024年12月23日 (一) 04:19 (UTC)

就是感覺，可能不存在嚴格的規則來決定怎麼加lang；特定條目里，大量lang或許對源代碼編輯及模板限制是個負擔而收益有限？--YFdyh000（留言） 2024年12月23日 (一) 05:08 (UTC)

稍早在監視清單看到一個例子(被記錄在編輯摘要)，原文是现在存在一个页面模版使用率过高，导致无法显示langja的模版，甚至都无法使用reflist；这种subpage解决方法没有任何的用，不知道怎么办了，如果強制要求使用lang，在部份愛好者頁面可能會提早呈現模板失能的狀態。(( π )題外話愛好者頁面過度擴充遇到問題才想到要分拆，分拆以後確認問題解決又重新無節制，直到問題再重新發生，不斷的循環)--Rastinition（留言） 2024年12月23日 (一) 14:21 (UTC)

把模板展開成模塊，把reflist改成<references />，還能撐一會兒。但是還是刪愛好者內容才是正道。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月24日 (二) 02:44 (UTC)

哦哦。我還以為您是將我那條留言理解成了我反對這一條款，讓我「互相理解、避免衝突」（我並未反對，只是單純對那個詞組措辭提出意見而已；現在的表述已經修正了）。--自由雨日🌧️❄️ 2024年12月24日 (二) 00:28 (UTC)

對於外語的標註，如果沒有下載對應語言的語音包，似乎只會用中文語音亂合，或者直接跳過？ ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月23日 (一) 01:08 (UTC)

提議DYK/GA/FA引入cooldown time(或譯冷靜時間)

背景：Wikipedia:管理員布告板/其他不當行為#Kalin8111 有不少編輯者認為在投票結束前最後一刻才投票的觀感極差，因為這個行為是讓編輯者不能在合理時間內進行修正。

建議方案1：

• 於DYK/GA/FA引入cooldown time （24小時），在這時間，不接受新投票，只有點票員可以發言。
• 若然有人在投票完結前24小時提出反對，隨即啟動cooldown time。
• 提名者可在cooldown time 進行修正，由點票員決定是否已作正當合理的修正。
• 點票員在cooldown time 完結當刻進行檢視反對票意見工作，如果那個反對意見已被解決，點票員以劃票作結。（反對者在這個時間沒有資格發言，因為他在投票完結前24小時才發言（意指下次請早））

建議方案2:

• 於DYK/GA/FA引入cooldown time （24小時），在這時間，不接受新投票，只有點票員可以發言。
• 若然有人在投票完結前24小時提出反對，隨即啟動cooldown time。
• 提名者可在cooldown time 進行修正，由點票員會透過ping通知所有投票者，在cooldown time 結束後24小時內投票表決那份意見是否得到解決。
• 點票員在cooldown time +24小時 （總時長是結束投票後48小時）完結當刻進行檢視投票結果，如果那個反對意見已被解決，點票員以劃票作結。（反對者在這個時間沒有資格發言，因為他在投票完結前24小時才發言（意指下次請早））

以上

（P.S.下方提案POINT是本案延伸，敬請各位繼續參與。）--唔好阻住我愛國（留言） 2024年12月18日 (三) 14:34 (UTC)

編輯者代表：@MykolaHK@SickManWP@自由雨日@Patrickov@Sanmosa@紅渡廚@FradonStar@ATannedBurger

管理員代表：@春卷柯南 @Cdip150@AT--唔好阻住我愛國（留言） 2024年12月18日 (三) 15:03 (UTC)

作為當事人我(＋)強烈支持是理所當然，唯現實執行上可能比想像中複雜。--Mykola（留言） 2024年12月18日 (三) 16:26 (UTC)

目前(＋)傾向支持若在臨通過前有反對票啟動cooldown time，並由點票員確認條目問題是否解決，判斷條目評選是否通過。--維基病夫_{❤️邊緣人小組·簽到·Donald Trump 45 and 47!} 2024年12月18日 (三) 16:23 (UTC)

全數(－)反對，基本上我跟@黑暗魔君、SunAfterRain於上次的意見類似。首先歸根究柢的問題——為甚麼會被人投出合理的反對？很大程度就是參選前沒有確認清楚條目的問題所致，如果因此而被人投反對，不論是任何時間甚至最後一刻投出，我覺得一點都不值得寬限，就算是觀感極差也是參選人自己討來，為甚麼條目的問題不是應該參選之前就要知道？而要等到投票途中才被其他人發現？（參選前去VPD也好、PR也好、甚至單獨詢問其他熟練的維基人也好［我以前就試過］）我認為以上的方案會縱容大家不把條目問題先完全搞定就參選，也對於一些能守時發現並解決問題的參選者不公（參考@春卷柯南於該例的意見），更何況現有機制已允許重新提名；事實上我已經不太滿意一些支持票已滿但實際上不合要求的條目，仍可以在投票完結後一定時間經改善後當選的做法（在我而言，如果被證實投票時已經不合要求，投票結束時即使支持已滿但未改好，則之後不論改善與否都應該直接取消資格，請參選者改善後重新一輪投票程序才對，而不是現在那樣改善後直接算當選）。如果是一些不合理的票（不論是支持還是反對），現有的機制本來就可以讓人提請例外處理，讓一些不合理的票不算（很多年試過一次，不記得哪一例了，衹依稀記得當時@AT好像有參與過程）。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年12月18日 (三) 16:30 (UTC)

反對票其實隨便找個理由就可以隨便投（甚至有一些偽君子就用字數太少、資訊框太占元組等蠢理由不斷投反對票），甚至有些所謂問題後來還被打臉。我想說的是現在就算是隨機挑一篇FA如果非常非常仔細找也是會找到一點所謂的瑕疵，而那一點點也就會無限輪迴擠牙膏，這樣就永遠不會選上，內容評選統統不用做了。--Mykola（留言） 2024年12月18日 (三) 16:59 (UTC)

您用Talk:塞爾希·葉克利奇克這個例子我就更氣忿，人家已經不是最後一刻投票，而是兩天多就投票說您可供查證有問題，然後餘下幾天您做了些甚麼？條目的可供查證問題到了今天還是未完全改正，還有紅紅的錯誤訊息留到今天，請問這真的值得可憐嗎？說要給寬限期，其實類似的寬限做法其實也給過閣下（如Talk:東瑞丁郡議會），但到頭來您又做過些甚麼？居然捏造來源意圖蒙騙過關。這也是為甚麼我會很抗拒這種寬限提議，過往有些人就是這樣不好好利用這些寬限機會，增加管理員把關的壓力。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年12月18日 (三) 17:57 (UTC)

如果要說來源引用錯誤就是「捏造來源」的話我就算了。說到最近的DYK，查證內容是要更清楚沒錯，但其他問題的提出擺明是來亂的。還有我不知道他為什麼就一定要擠牙膏，內容評選這樣做影響雖相對比較少，但到了要討論做出決策的時候就很麻煩了。--Mykola（留言） 2024年12月18日 (三) 19:01 (UTC)

還是看回最近那次DYKC，如果您不做第一步的修正連結，請問別人怎樣能確認全部來源不足以支持內容？這是很合理的逐步提問。當然別人是有說錯的地方，但其還是有跟閣下道歉，不過亦不推翻您寫的內容未能完全可供查證這一事實。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年12月18日 (三) 19:24 (UTC)

反對票隨便投固然不應該，但支持票隨便投又該如何管制？提出要嚴格檢視反對票是否正當合理，那麼是否亦應提出相應機制檢視支持票是否正當合理？社群裡會認真做評審把關條目的用戶已經不多，還想進一步打擊參與評審的積極性，是想條目評審要爛到甚麼程度？--黑暗魔君（留言） 2024年12月19日 (四) 00:40 (UTC)

親！我們還有 即時不合資格 選項，那個條目可因自身問題而不可能通過，只要有一票反對也不能通過。--唔好阻住我愛國（留言） 2024年12月19日 (四) 01:40 (UTC)

@黑暗魔君:

君可見DYK的無限暖暖遊戲因一票反對被點票員暫停審閱當中，可見點票員發揮了作用。--唔好阻住我愛國（留言） 2024年12月19日 (四) 01:44 (UTC)

Wikipedia:新條目推薦/候選#無限暖暖--唔好阻住我愛國（留言） 2024年12月19日 (四) 02:14 (UTC)

條目評審不是用來解決條目的問題，而是讓人評審條目是否達標，嚴格來說評審的條目應該是提交那一刻的版本。即使有用戶在評審期間解決了反對意見提及的問題，點票員也不應該劃去反對票。--黑暗魔君（留言） 2024年12月19日 (四) 02:28 (UTC)

說難聽一點的，現在這個支持票制度直接廢掉支持票然後結束時不能有反對票都還比較恰當--SunAfterRain 2024年12月19日 (四) 13:03 (UTC)

我在以前有提過這個方案，但當時的社羣不太買單。Sanmosa _蚌埠 2024年12月19日 (四) 23:50 (UTC)

下次再來就好了。GFA就等一個月，DYK還能無限續杯。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月18日 (三) 23:23 (UTC)

(＝)中立／(－)傾向反對：先旨聲明，本人也傾向認同街燈君的意見，即是另外MykolaHK君自己在編修條目的工作質素也確實頗有改進空間。而且從他在Kalin8111君提報案件以及本次提案的發言，本人是覺得他比較傾向改變制度（推動有利自己的提案通過）多於改變自己，所以本人對這提案是有相當程度的保留。本人認為，要改的話，頂多是明文擴大點票員的相關權限，例如「當存在關鍵反對票時，點票員可酌情啟動特別處理（例如冷靜期）」，而非一刀切否決。強制冷靜期之類的措施有可能令以投反對票把關為己任者感到不便甚至不安，不建議實行。 -- 派翠可夫 (留言按此) 2024年12月19日 (四) 03:23 (UTC)

基於建議方案1而有的方案3：

• 於DYK/GA/FA引入cooldown time （24小時），在這時間，不接受新投票，只有點票員可以發言。
• 若然有人在投票完結前24小時提出反對，而點票員認為相關反對意見可以在cooldown time內完成修正+提名者有能力解決，可酌情啟動cooldown time。
• 提名者可在cooldown time 進行修正，由點票員決定是否已作正當合理的修正。
• 點票員在cooldown time 完結當刻進行檢視反對票意見工作，如果那個反對意見已被解決，點票員以劃票作結。（反對者在這個時間沒有資格發言，因為他在投票完結前24小時才發言（意指下次請早））
• 若然提名者濫用cooldown time機制，或會讓點票員認為該名提名者沒有能力解決問題。

相反，

• 若然反對者在任何時候提出的正當合理意見可預見無法在短時間內解決或相關意見指出需要大幅度調整內容才可解決問題。點票員有權在cooldown time內判定該次投票即時不合資格。

--唔好阻住我愛國（留言） 2024年12月19日 (四) 06:59 (UTC)

(－)反對：提案人顯然沒有理解內容評選的基本含義，評選的目的是選出合適的條目，理論上應當是開始投票時即是提名人認為符合該評選標準，出現合理反對意見說明準備不足，等準備好下次再戰即可，沒有必要引入額外時間改善機制。現在的評選過程中允許修改使意見消失已經是開了口子了。所謂沒有合理時間修正，請移步WP:PR，那裡是讓別人提修改建議的地方，而不是內容評選。如果疑慮不合理投票，驗票員可以劃掉不合理的反對票，本就不是問題。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月19日 (四) 09:10 (UTC)

你這樣說，是否可以理解為在DYK/GA/FA評選期間，應予以全保護，禁止任何人做修改？欲須修正意見，應使用PR?--唔好阻住我愛國（留言） 2024年12月19日 (四) 09:33 (UTC)

顯然不是。首先要對提交時版本本身討論只需要討論歷史版本本身而無需保護，其次我只是說對於「評選」這個詞而言，現在內容評選流程是開了一個讓編者能在評選投票過程內能修改的口子，沒說這個口子不該被開（事實上開出這個口子能減少無謂的反覆提交），只是在表達不應該把這個口子再擴大，否則就和評選完全背離了。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月19日 (四) 11:38 (UTC)

然而目前是走「現行版本」，而不是「歷史版本」。既然是「現行版本」，理應給予編輯者合理時間進行修正，而不是一刀切（例如在結束前30分鐘提出反對，根本不可能進行修正）禁止修正。--唔好阻住我愛國（留言） 2024年12月19日 (四) 11:46 (UTC)

規則上哪裡有提是「現行版本」？事實上用「現行版本」來審是不合理的，例如前面的兩票其實是投給當時的「現行版本」，後面的兩票投給當前的「現行版本」，評審對象都不一致，這樣的評審難言公正。當然，目前的實際情況的確是這樣只是因為沒有人在意，不等於合理。你提到的「理應給予編輯者合理時間進行修正」，我非常不同意，提名人在提名之前有許多時間修正條目，提名人或主編自己應做的工作沒有做好，反倒要怪在最後時刻提出合理反對意見的用戶身上，我認為是荒謬。--黑暗魔君（留言） 2024年12月19日 (四) 12:07 (UTC)

你沒理解我的意思，我的核心觀點是你交上去的版本本來就是你認為符合要求的版本，理論上這種版本不應該有合理的反對意見。在這個邏輯下，如果沒弄好就交上去，反對意見能處理掉當選算運氣好，出現壓哨反對然後落選只能自認倒霉，改好了重新上評選就行。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月19日 (四) 12:12 (UTC)

然而很多時劃票/改投支持的原因是已按反對者意見進行修正，如果是堅持以「歷史版本」進行評審，那不如禁止劃票/改票及在規則內明文說明應以「歷史版本」進行評審+重定向至「歷史版本」，而非「現行版本」。然後配合下方 「流程結束前極短時間內投出或表達反對意見」的討論方案，應該減低對提案者不快的情緒。--唔好阻住我愛國（留言） 2024年12月19日 (四) 12:58 (UTC)

您這個非常明顯過度理解了，對方只有說「你拿出來的版本你要自己認為符合要求」，壓根沒有提到半個字說要用歷史版本來評選。--SunAfterRain 2024年12月19日 (四) 13:06 (UTC)

然而我是回應@黑暗魔君--唔好阻住我愛國（留言） 2024年12月19日 (四) 13:09 (UTC)

與我對下方的提案的意見類似，應該要被規管的是經常性及／或針對性的壓綫反對，而不是所有的壓綫反對。再者，壓綫反對的問題並非條目評選所獨有，我傾向於把這交給較大的規則（即方針、指引等）來處理，因此我認為不存在需要為專門為條目評選制定有關壓綫反對的規則的合理理由，為此我(－)反對這裏的三版提案。Sanmosa _蚌埠 2024年12月19日 (四) 09:38 (UTC)

有問題的條目就不應該通過，搞什麼冷靜時間不可取，對此只能遺憾表示(－)反對，如果有惡意反對意見單案IAR處理就好。--SunAfterRain 2024年12月19日 (四) 12:57 (UTC)

(！)意見，我只想說cooldown time一般被譯為「冷卻時間」，通常指技能的再使用時間。若要譯成冷靜時間，改成calmdown time會比較適合。
另外針對投票到期前，臨時有人投入反對票，我支持加入延長機制，例如，投票截止前24小時內，有人臨時投入反對票，這時觸發「融斷機制」（保險絲融斷），整個投票計算暫停，給予72小時靜止期，讓主編者或條目建立者，有時間參考這些反對意見，對條目進行內容改善。72小時候重開計票，再由相關人員審視這些反對票是否仍為有效票。--Znppo（留言） 2024年12月19日 (四) 17:12 (UTC)

@Cdip150、Hotaru Natsumi：看到你倆的意見後，我有一個問題想問一下你倆的，就是當一個條目的（潛在）問題超出一般人的正常認知時，用戶（包括但不限於主編自己）是否真的有能力在條目被送去評選前識別到相關超出一般人的正常認知的（潛在）問題？Sanmosa _蚌埠 2024年12月19日 (四) 23:54 (UTC)

我會認為這種假設過分極端。如果這是一個任何人都看不出的問題，那在評選流程被投票人看出只能說投票人是超人；如果有一般人能看出這個問題，那麼PR流程就大概率可以解決了。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月20日 (五) 04:44 (UTC)

@Hotaru Natsumi：那我想知道Talk:山口縣行政區劃#特色列表評選裏所提到的Vector 2022寬度的事情到底是否超出一般人的正常認知？它如何超出或沒有超出一般人的正常認知？另一方面，我認為你倆或許把PR想像得過度理想化了，我並不是沒有遇過自己或其他人把條目送去PR時沒收到任何意見，到了評選時才遇到各種各樣的意見的情況，而且這現象似乎到現在仍然持續。可以説，PR的失能使相當數量的社羣成員跳過無法起實際效用的PR，然而現在你們給他們的意見是先走一次PR程序，對他們而言這意見給了就像沒給一樣，也難怪現在這裏產生了一個肉眼可見的社羣對立的情境。Sanmosa _蚌埠 2024年12月20日 (五) 04:54 (UTC)

關於Vector，我理解這是吹毛求疵的問題，950px是相對於他的視口寬度（可能是1080或更窄）來的，更寬的視口寬度使用Vector 2022不會有這個問題，比如現在比較常見的1440和2160。另外，移動版頁面視口寬度更窄。不應該要求作者非得適配到所有設備所有主題和所有瀏覽器窗口大小，維基百科不為他一人服務。硬要說這是普遍問題，也應該去問基金會為什麼不給Vector 2022的表格默認加上overflow-x屬性，而不是在評選過程中找主編的麻煩。至於說PR，如果PR沒收到反饋，在內容評選被各種反饋的話，只能說明現在社群對PR的重視程度完全不足 囧rz……，可能要看能不能對PR做一些改制，比如分配給專題成員什麼的，要另案討論。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月20日 (五) 05:09 (UTC)

不過那時候由於我自己也在用Vector 2022（而且那時候我經常忽略了左邊的目次欄可以隱藏，雖説現在我知道但仍然不用），我還是想了些辦法縮短了表格的寬度，我並沒有任何怪責他的意思，但這類型的意見的出現如果能被推給「沒走PR或類似程序」這種理由的話，我會認為是不理性的。其實我也不知道PR改制是否真的有用，畢竟部分「活躍」的專題在我看來實際上可能也不甚活躍，我直接向較專業的用戶提問（比如日本相關的我會問AT，這我試過很多次了；還有之前寫如心園的時候我也就遣辭問題問過UjuiUjuMandan）可能還比較快，但有一點需要考慮的是並不是所有用戶都像我這樣認識這麽多較專業的用戶。在這些因素的影響下，在我看來，用於回應或處理壓綫反對意見的合理時間有存在的客觀必要性（當然，我覺得上面HK5201314的版本可能過於rigid了）。Sanmosa _蚌埠 2024年12月20日 (五) 05:35 (UTC)

PR失能再加上不認識專業用戶確實會讓內容評選作為唯一獲得意見的手段，在這個前提下我會覺得給內容評選加凍結有合理之處，但是一個不好忽視的副作用是PR的地位會進一步降低，也就是，「反正內容評選和PR都會得到意見，內容評選選上了我還有榮譽，那別PR了」，所以我仍然會對加熔斷有一定疑慮，而更偏向於對PR作改制，改制不一定非得是分配給現有專題，也可以是弄個像AFC那樣的獨立專題，把PR的給出的意見、PR後條目有沒有被內容評選選上等等和獎章掛個勾之類的，重新使能PR。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月20日 (五) 05:59 (UTC)

我個人不認同「用於回應或處理壓綫反對意見的合理時間有存在的客觀必要性」，哪怕給了時間改善從而使反對理由消失，反對票也不會因此而自動無效，投票人依然可以保留反對票，原因是這個合理的反對意見是在評選期間被抽出來的，這依然是一個合理的反對意見。如果條目因此而落選，那麼請下次再來。--黑暗魔君（留言） 2024年12月20日 (五) 06:01 (UTC)

我覺得大家首先需要弄清楚的可能是評選的本質是甚麽，我的看法是評選的本質是予以到達一定品質的條目相應程度的認可，以鼓勵社羣在力所能及的範圍內貢獻較高品質的內容，因此評選應該是以條目品質來導向的。讓滿足品質要求的條目無法獲得相應程度的認可會引申一個潛在的負面影響，就是社羣會認為「既然我在盡力讓條目滿足品質要求後還是無法讓條目獲得相應程度的認可，那我為甚麽還要繼續要求自己貢獻的內容與相應的品質要求看齊？」，而這會導致社羣貢獻的內容的品質下降，這種情況是悖於維基百科建設百科全書的宗旨的。Sanmosa _蚌埠 2024年12月20日 (五) 06:10 (UTC)

我認同這個本質，我也相信這個討論的所有人都認可這個本質。我們的分歧其實不在這裡，而是在於時間點。我會認為提交評選的那一刻是提交人認為「我已經盡力達到要求了」，而不是提交人提交後根據評選意見改善這個過程是盡力達到要求的時間，這和「評選」這個詞是矛盾的。所以我也在說PR和重新使能PR的重要性。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月20日 (五) 06:18 (UTC)

說實話，我認為兩者並不矛盾：正如你上方所認可的一樣，「PR失能再加上不認識專業用戶確實會讓內容評選作為唯一獲得意見的手段」，條目主編當時可能確實已經盡力達到要求了，但他還是沒有辦法完全排除一切問題，而這導致評選期間評選意見的產生，這時候條目主編再根據條目主編繼續盡力使條目達到要求。Sanmosa _蚌埠 2024年12月20日 (五) 06:24 (UTC)

問題就是理論上PR應該是獲得意見的手段之一，內容評選只應當是評選，反對意見附言給出的意見是附帶的。如果把內容評選變成可以一直處理反對意見這類，那麼PR很可能徹底失能。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月20日 (五) 06:38 (UTC)

然而就算是像enwiki走共識制的評選，也沒有禁止評選期間處理評選意見的做法。我覺得真要讓PR發揮應有的功效的話，可能需要一些強制性的措施使PR不得不得到社羣的重視，而如果PR機制的失能無可避免，那這有可能説明PR機制並不適合zhwiki。Sanmosa _蚌埠 2024年12月20日 (五) 06:45 (UTC)

不是不讓處理反對票，是說時間到了反對票沒處理好就下次再來。我理想中的內容評選通過形式是「編者自己盡力完成->PR得到其他編者建議->提名內容評選->對少量的反對意見進行處理->通過」。不過這樣想確實出現壓線反對不好辦，確實可以考慮設置緩衝期，不過不是HK的三種方案，而是固定的24小時緩衝期處理反對意見，處理流程和一般反對意見處理流程一致，不是由計票員判斷，而是由投票者和編者協商處理（如果24小時到了編者做了回應但是投票者沒動靜可以特殊處理），驗票員劃票的權限仍然保留，不管怎麼樣投票期間所有的投票都應該一致處理，不能因為有人投得晚就不准他追加解釋。如果這24小時還處理不好就下次再來了。另外關於PR的部分您說的確實有道理。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月20日 (五) 07:01 (UTC)

我贊同你對於緩衝期處理的見解。但是這裏牽涉到另一種情況，就是壓綫投票兼擠牙膏式發表意見，這種情況下我認為這24小時的緩衝期可能需要就每個獨立的意見各給予一次。Sanmosa _蚌埠 2024年12月20日 (五) 07:04 (UTC)

我同意是「條目品質導向」，正因為是「條目品質導向」，合理的反對票理應起到把關的作用，阻止提名人提交的不合要求條目當選，提名人提交的版本不合要求，不論隨後如何改，也不應納入考慮。條目評選不應該是讓條目在評選期間改到當選為止。--黑暗魔君（留言） 2024年12月20日 (五) 06:22 (UTC)

然而你這裏說的話與WP:編輯方針與WP:勇於更新頁面等規則的精神可謂南轅北轍。再者，條目主編或評選提名人與其他用戶的關係也不應該是對立的，其他用戶給予意見的目的應該是為了讓條目能真的達到相關要求，以對建設百科全書起建設性的作用。Sanmosa _蚌埠 2024年12月20日 (五) 06:28 (UTC)

我不認為有何違背，你依然可以根據意見改善條目，但你不應該預期甚至要求其他投票人在同一次評選裡改票，改到當選為止。就像我在上面的意見，條目在評選期間改來改去，難道你又要讓所有投票人跟著你不斷更新的版本改來改去？這算是甚麼評選？--黑暗魔君（留言） 2024年12月20日 (五) 06:33 (UTC)

既然其他用戶給予意見的目的是為了讓條目能真的達到相關要求，那給予意見的用戶應該合理期望條目主編能真的按照他們的意見來改善條目，他們為了確認這點自然需要查看條目是否有所更新。這不是我「讓所有投票人跟著不斷更新的版本改來改去」，而是給予意見的用戶為確保條目得到改善而自然而然地作出的建設性跟進，這點甚至在走共識制的enwiki也是一樣的。此外，我查了一下「評選」的定義，沒有證據證明「評選」必須基於一個固定的版本或狀態來進行，所以你問我「這算是甚麼評選」我自己是感覺很奇怪的，因為這問題並不該問。Sanmosa _蚌埠 2024年12月20日 (五) 06:42 (UTC)

如果評選的對象不是同一個，投票的對象也會變成不一樣，前面的幾票實際上是投給舊的修訂版本，後面的幾票投給最新修訂版本。你覺得這樣的評選有意義嗎？除非你能在投票結束時能把所有參與投票的用戶喊過來重新確認他們的投票，否則不停根據新修訂版本來投票就會造成這樣的問題。--黑暗魔君（留言） 2024年12月20日 (五) 07:03 (UTC)

「除非你能在投票結束時能把所有參與投票的用戶喊過來重新確認他們的投票」，這好像就是現在評選的一般慣例啊，雖然實際執行上不會真的每個都ping那麽誇張。如果你的要求僅僅是規範化你説的這個重新確認機制的話，我倒是不反對（就算是真的強制要求每個都ping，我也不反對），我認為這是件好事情。説到底，這或許是投票制的一種硬傷，共識制下ping所有參與評選討論的用戶重新確認意見會顯得比投票制下ping所有參與評選投票的用戶重新確認投票來得自然得多。Sanmosa _蚌埠 2024年12月20日 (五) 07:06 (UTC)

這不是現在的慣例吧？特別是投了支持票，有哪個會特意確認投票結束時的條目版本就是當初投票那時的版本，事實上我認為這是一個很嚴重的公正問題。舉例說，甲用戶投了支持票給修訂版本A，乙用戶投了反對票給同一個版本，然後條目被修改了成修訂版本B，乙用戶改投支持票，然而甲用戶沒有說他支持修訂版本B呀，說不定他會覺得修訂版本A更好，結果到算票時卻變成是甲、乙用戶都支持現行版本。--黑暗魔君（留言） 2024年12月20日 (五) 07:20 (UTC)

我理解你在説甚麽，但這不影響我那個留言裏後面説的話的有效性。Sanmosa _蚌埠 2024年12月20日 (五) 07:38 (UTC)

@黑暗魔君：我之後再想了一下，我發現一個問題，就是即使沒有人在一個評選裏投反對票，這並不妨礙任何人（包括但不限於主編與提名者）更動條目裏的任何東西，而只要這種情況發生了，那按你的道理來説這個評選也同樣是「沒有意義」的，因為「不停根據新修訂版本來投票」的情況也同樣發生了。然而，這種認定顯然是非理性的，因為在執行上不可能做到，除非你主張以上面所提到的全保護一般極端的手段來處理（但我也需要事先説明全保護不能這樣用）。Sanmosa _蚌埠 2024年12月21日 (六) 07:17 (UTC)

甚至再誇張一點說，假如一個條目在GA通過前的評選期間完全沒有任何的內容更動，但在GA通過後出現幾次內容更動，那按你的道理來説，每出現一次這樣的更動，這條目就要交到GAR一次，因為你主張評選僅按提交時的版本評定，而更動後的版本已經不是提交時的版本。這會導致一個極端的情況，就是用戶需要多次提交同一個條目的無數個版本到評選頁面。這種認定顯然也是非理性的，就算是enwiki也不可能有這樣的人力資源來做這種事。Sanmosa _蚌埠 2024年12月21日 (六) 07:21 (UTC)

所以這就是為何我和@Hotaru Natsumi都認為評審對象應以提名人提交的那一個版本為準才是對的，當然目前在實際執行上沒有人在意這個問題。--黑暗魔君（留言） 2024年12月21日 (六) 09:13 (UTC)

不，我正是想説你説的這種做法是有問題的，因為參與評選者根本沒有這個心思去對照版本，這不是他們應該花的時間與精力。我的意思是「評審對象應以提名人提交的那一個版本為準」是impratical的，因此認為出現「（不停）根據新修訂版本來投票」的情形的評選是「沒有意義」的也是impratical的。Sanmosa _蚌埠 2024年12月21日 (六) 13:17 (UTC)

我同意要解決這個問題不容易，但不是沒有辦法，例如英維共識制只需參與討論的用戶對現行版本達成共識，不會牽涉投票造成的這個問題。你總不能否認目前這樣的評選有欠公允吧？--黑暗魔君（留言） 2024年12月21日 (六) 13:55 (UTC)

我確實是在否認目前的評選機制有欠公允，因為試圖承認這件事情的舉動是impratical的。而且這個世界上本來也沒有絕對的公平，你的「公允」可能是就投反對票的用戶而言的，Mykola的「公允」可能是就條目主編而言的，而我認為我的「公允」是就作為百科全書的維基百科本身而言的。亲，我簽名那刻的時間是 2024年12月21日 (六) 14:00 (UTC)

請恕我不能同意，投票對象不一的評選不可能是公允。( π )題外話話說為何你轉了簽名後，我無法按「回覆」回應？有bug嗎？--黑暗魔君（留言） 2024年12月21日 (六) 14:20 (UTC)

然而你無法否定「這個世界上本來也沒有絕對的公平」這一點。再者，比起評選公不公允，我更在意的是優特狀態的取得與喪失公不公允，應該成為優特內容的條目無法成為優特內容對維基百科而言屬於重大損失。應該是強制顯示原文符的問題，我已經調整了我的簽名的設定。亲，我簽名那刻的時間是 2024年12月21日 (六) 14:24 (UTC)

如果條目經修改後真的符合要求，而只是因為提交的版本遭到反對，那麼下次再提交就行了，為何要執著於一次就要通過？--黑暗魔君（留言） 2024年12月21日 (六) 14:43 (UTC)

你還是沒有弄明白我在意的點是甚麽：我在意的點是條目符合要求就該取得對應的優特狀態，在條目符合要求的情況下不容許條目取得對應的優特狀態悖於優特內容機制的設想，這與提交的次數無關。我上面已經提到了我認為我的「公允」是就作為百科全書的維基百科本身而言的，如果你執意要認為我的「公允」是就條目主編而言的，那我認為我們之間很難進行具建設性的討論。亲，我簽名那刻的時間是 2024年12月21日 (六) 14:57 (UTC)

條目達到要求就該取得優特，這沒有問題，然而這個「取得」的程序應當是嚴謹和公允，我保留這個意見。--黑暗魔君（留言） 2024年12月21日 (六) 23:44 (UTC)

你這個意見過於官僚化了。亲，我簽名那刻的時間是 2024年12月22日 (日) 00:18 (UTC)

書面規則本身並沒有設定公認的做法。目前的規定並沒有不允許以提名人提交的版本不符合要求而提出反對。我自己除了參與評審，也編寫了不少條目，我更希望自己所寫的條目是通過正當的評選獲得肯定。--黑暗魔君（留言） 2024年12月22日 (日) 03:33 (UTC)

「目前的規定並沒有不允許」不代表這樣做是正確的。我拿一個極端的例子來説：近親性交在部分國家與地區並不是違法行為（參見近親性行為相關的法律），但這不代表近親性交是正確的。假如現在有人以「提名人提交的版本不符合要求」這個理由來投反對票並無視或罔顧條目在被提名後的變化的話，我會認為這是在濫用社羣的善意，也是屬於游戲規則的行為。亲，我簽名那刻的時間是 2024年12月22日 (日) 04:03 (UTC)

我完全不認同重視評選正當公允的反對是「濫用社群善意」和「遊戲規則」。--黑暗魔君（留言） 2024年12月22日 (日) 05:08 (UTC)

然而這也只是你的「公允」的已，不是維基百科本身或社羣整體的「公允」。亲，我簽名那刻的時間是 2024年12月22日 (日) 05:26 (UTC)

反對票就要被百般刁難，水票就放任不管，我完全不同意這是維基百科本身或社群整體的「公允」。--黑暗魔君（留言） 2024年12月22日 (日) 05:39 (UTC)

強制捆綁其他提案的意見在社羣討論中不可取，這兩個議題應該分開討論。我現在有理由相信你其實只是在仇視支持票而已。亲，我簽名那刻的時間是 2024年12月22日 (日) 05:41 (UTC)

不，因為你提到「整體公允」，閣下和社群部分人對反對票和支持票的反差態度，令我確實看不到哪裡「公允」。--黑暗魔君（留言） 2024年12月22日 (日) 06:06 (UTC)

你這話無視了支持票附理由的規定的設立、執行與廢除的歷程，你的意見顯然是impractical的。亲，我簽名那刻的時間是 2024年12月22日 (日) 06:29 (UTC)

而且你來説這話也完全沒有説服力，Talk:遜尼派#典範條目評選也不是你口中的「正當的評選」，因為評選參與者並非完全僅按提交時的版本評定，由此説來你也是你口中的「不正當的評選」的受益者。如果你自己也沒辦法以身作則的話，那你也沒有任何正當的理由要求其他人這樣做。亲，我簽名那刻的時間是 2024年12月22日 (日) 05:34 (UTC)

我沒有期待或要求投反對票的用戶劃票，而且我對那位投反對票的用戶表達了感謝，請問我如何沒有以身作則？如果你認為該條目有問題，我絕對歡迎任何人提出重審。--黑暗魔君（留言） 2024年12月22日 (日) 06:09 (UTC)

既然你主張評選參與者完全僅按提交時的版本評定，那你應該要求所有投（支持）票的人真的僅按提交時的版本評定才是。我沒有這個主張，所以也用不着因為這個理由來提FAR。亲，我簽名那刻的時間是 2024年12月22日 (日) 06:17 (UTC)

我確實是這樣主張，不論是不劃去反對票或劃去支持票，我都沒有意見，也不會因此橫加指責。--黑暗魔君（留言） 2024年12月22日 (日) 06:24 (UTC)

不，你做的東西和你的主張是相違背的。你但凡重新讀一次自己的留言，你應該不難找出其中矛盾之處。亲，我簽名那刻的時間是 2024年12月22日 (日) 06:27 (UTC)

不是，我的意見是壓線的合理反對票沒有管制的必要，因為評選就是評選，不是給你修正的地方，如果因為條目修正了就強制反對票撤銷，那麼同樣應有相應機制確保此前的支持票不會被錯判。--黑暗魔君（留言） 2024年12月22日 (日) 06:38 (UTC)

那你其實也是雙重標準，只不過你寬待的是反對票而已，因為你的前設已經假定反對票在任何情況下都是不會被錯判的。亲，我簽名那刻的時間是 2024年12月22日 (日) 06:52 (UTC)

哪裡雙重標準？既然目前支持票是可以一直保留，那麼反對票亦有權一直保留，這正是現行的規定。管制所謂合理的壓線反對票才是雙重標準。--黑暗魔君（留言） 2024年12月22日 (日) 06:59 (UTC)

你假定所有反對票必然是正當合理的，但並沒有同樣地假定所有支持票必然是正當合理的（「水票」）。亲，我簽名那刻的時間是 2024年12月22日 (日) 07:03 (UTC)

首先，我沒有這樣的假定。其次，以我過往參與條目評選的經歷，確實發現一些條目有顯然易見的問題，然而還是有一堆支持票，而不合理的反對票很容易會被提報，而那些不負責任的支持票卻可以繼續不負責任。相對來說，如果壓線的反對票是不合理和明顯擾亂，提報是可以處理的，如果提報的壓線反對票是合理，那為何有必要處理？不負責任的支持票都可以容忍，卻容不下合理的壓線反對票，這樣的反差要怎樣解釋？--黑暗魔君（留言） 2024年12月22日 (日) 10:42 (UTC)

我上面不是已經提過了？而且嚴格意義上來説，自從支持票附理由的規定被廢除後，幾近所有的支持票都能落入你所説的「不負責任的支持票」（反正你質疑並不需要成本，其他人證明卻需要大量成本，那我就先假定你的質疑成立好了），你這話相當於要讓幾近所有的支持票團滅，那整個條目評選的機制都會崩潰。Sanmosa 2024年12月22日 (日) 10:48 (UTC)

此外我也要更新一點：Hotaru Natsumi在與我在上方作相當的探討後，已經基本認可緩衝期的必要性。當然，Hotaru Natsumi主張的並非HK5201314的任何方案，而我認為Hotaru Natsumi提出的初步方案是合理的。亲，我簽名那刻的時間是 2024年12月21日 (六) 14:06 (UTC)

至於你說的GA通過後出現變動，如果被認為導致條目未達要求，那麼回退或提交重審即可。如果沒有人認為有問題，那自然不需要「提交同一個條目的無數個版本到評選頁面」。--黑暗魔君（留言） 2024年12月21日 (六) 09:23 (UTC)

既然如此，為何評選期間出現的變動就算「沒有人認為有問題」也不能被納入考量？你這話顯然是自相矛盾的，當條目的評選的版本認定從嚴處理時，條目的優特狀態的版本認定自然也應當從嚴處理，否則這就是雙重標準。Sanmosa _蚌埠 2024年12月21日 (六) 13:18 (UTC)

不一樣，評選期間投票對象不一致會造成票數上的誤判，影響評選的公平公正。當選後條目的變動並不牽涉評選，不會造成評選不公。--黑暗魔君（留言） 2024年12月21日 (六) 13:47 (UTC)

然而條目的優特狀態並不能反映條目的變化，這有機會讓後人錯誤解讀當時的評選結果。要是你說評選期間投票對象不一致會造成不公的話，那條目獲取優特狀態後的變化造成的不公可比評選期間投票對象不一致造成的不公大得多了。亲，我簽名那刻的時間是 2024年12月21日 (六) 13:53 (UTC)

如果投票對象是一致，那麼就是說他們都認同這個版本的優特狀態，儘管優特狀態不會隨新修訂版本更新，但這並等同他們認同隨後的版本，投票人當初的投票沒有被錯誤扭曲，如何造成不公？--黑暗魔君（留言） 2024年12月21日 (六) 14:16 (UTC)

假如你説的話成立，也就是他們都認同這個版本的優特狀態不等同他們都認同隨後的版本的優特狀態成立的話，那該條目的隨後的版本不應該具備與先前版本同樣的優特狀態，因為該條目的隨後的版本的優特狀態並未得到任何評選的認可。評選期間投票對象不一致好歹還有幾個人認可不同的版本，隨後的版本可是一個人的認可也沒有。亲，我簽名那刻的時間是 2024年12月21日 (六) 14:21 (UTC)

有人不認可隨後版本的優特狀態，那就可以考慮回退到當選的版本或有共識的版本，甚或提出重審。不等同他們認同隨後版本的優特狀態，與撤銷優特狀態是兩回事，要撤銷就走重審的流程。--黑暗魔君（留言） 2024年12月21日 (六) 14:39 (UTC)

僅因不認可而「回退到當選的版本」違反規則，見WP:編輯戰#何謂編輯戰。僅因不認可而提出重審是不理性的做法，現時的重審機制相當於重新確認條目的優特狀態，也就是需要淨6或8支持票才能維持條目優特狀態，而如果讓重審也套用你上面的固定版本理論，那理論上幾近所有的重審的結果必然是除名，這大大增加了社羣（包括但不限於主編）維護條目的成本，而且也同樣牽涉到我上面提及的優特狀態的取得與喪失上的不公允。（否則這就會涉及到一個悖論，就是既然幾近所有的重審的結果必然是除名，那為何我還要等待7或14或28日來讓條目被除名，而非一經發現立即除名？）亲，我簽名那刻的時間是 2024年12月21日 (六) 15:03 (UTC)

不是很理解你說的這段話，把條目修得更糟糕了，自然應該回退，如何構成編輯戰？重審也是，目前機制也允許用戶對不認可的條目提出重審，你的意思是目前的重審機制不合理嗎？--黑暗魔君（留言） 2024年12月21日 (六) 23:36 (UTC)

回退只能用於非建設性的編輯，你不能假定所有你認為「把條目修得更糟糕」的編輯為非建設性的編輯。由於現行重審的流程實際上是重新進行一遍評選的流程，那對於評選的條件理論上也應該適用於重審。既然你主張評選須以提交時的狀態為準，那重審自然也須以提交時的狀態為準，而這自然會導致幾近所有的重審的結果必然是除名，然而重審機制本來是為了給條目一個及時修正的機會以保持優特狀態的，這個結果與重審機制的目的相悖。我是反對評選須以提交時的狀態為準的做法的，也因此我不會認為重審須以提交時的狀態為準，在我對評選的觀點下我沒理由認為重審機制不合理，但如果我套用的是你的觀點，那重審機制就會變得不合理了。亲，我簽名那刻的時間是 2024年12月22日 (日) 00:17 (UTC)

不同意重審機制就是「給條目一個及時修正的機會」，評選就應該是評選，重審該給予的意見是為何此條目符合/不符合，而不是修正意見，目前機制沒有給予修正意見的要求，閣下添加的這項評選功能只可以說僅是閣下的意見。--黑暗魔君（留言） 2024年12月22日 (日) 05:32 (UTC)

然而你的説法與WT:典範條目評選/檔案1#對特色條目評選的改進建議的説明存在重大出入，該説明甚至也不認可你對一般評選的觀點。亲，我簽名那刻的時間是 2024年12月22日 (日) 05:38 (UTC)

我沒有看到現行機制上有強制提出修正意見的要求，也從來沒有看到不含修正意見的合理反對票會被視作無效。我目前的這個反對票也只是指出問題，沒有修正意見，你是否會劃去這票？--黑暗魔君（留言） 2024年12月22日 (日) 06:01 (UTC)

這不完全算沒有「修正意見」的情形，指出來源無法使內容可供查證的implied meaning是either尋求新來源使內容可供查證or刪去相關內容。亲，我簽名那刻的時間是 2024年12月22日 (日) 06:21 (UTC)

然而哪怕加上新來源也可能是有問題的來源，刪去這部分內容也可能使條目內容比例不恰當，我的這一票不是修正意見。--黑暗魔君（留言） 2024年12月22日 (日) 06:32 (UTC)

那你對「修正意見」的理解未免過於狹隘了。亲，我簽名那刻的時間是 2024年12月22日 (日) 06:54 (UTC)

另一方面，「把條目修得更糟糕」是一種個人感覺，僅因條目出現了一些你認為「把條目修得更糟糕」的編輯而提出重審實際上是在濫用重審機制，這事Jarodalien做過，然後被社羣猛烈批判了。亲，我簽名那刻的時間是 2024年12月22日 (日) 00:23 (UTC)

任何「個人」有合理理由就可以提出重審，如何構成濫用？--黑暗魔君（留言） 2024年12月22日 (日) 05:20 (UTC)

然而個人感覺不能充當合理理由啊，你但凡真的嘗試查一下Jarodalien做了些甚麽東西，你就會知道我為何要用到「濫用」一詞了。亲，我簽名那刻的時間是 2024年12月22日 (日) 05:27 (UTC)

他算不算濫用，我沒有仔細研究過，所以我就不評論了，我想說的是只要理由合理，提出重審或回退是沒有問題的，這不是濫用，也不是編輯戰。--黑暗魔君（留言） 2024年12月22日 (日) 05:44 (UTC)

前提是理由真的合理，你不能僅因為你自己認為理由合理而無視或罔顧理由實際上是否真的合理。亲，我簽名那刻的時間是 2024年12月22日 (日) 05:45 (UTC)

請問提出者如何確認「實際上」是合理？任何提出者都是個人認為有合理理由才提出的，除非是明顯擾亂，否則一來就指責提出者「濫用」是不對的。--黑暗魔君（留言） 2024年12月22日 (日) 05:56 (UTC)

我還是上面這句話：你但凡真的嘗試查一下Jarodalien做了些甚麽東西，你就會知道我為何要用到「濫用」一詞了。你一方面說自己「沒有仔細研究過」Jarodalien的case，另一方面又指責我「一來就指責提出者『濫用』是不對的」，這顯對於我這個有仔細研究過Jarodalien的case的人不公道。亲，我簽名那刻的時間是 2024年12月22日 (日) 06:24 (UTC)

他認為他的做法有問題，那你就提報他，但我不理解的是你說要「實際上」認為有合理理由而非「個人」認為有合理理由的意思，到底該如何確認有實際上合理的理由？--黑暗魔君（留言） 2024年12月22日 (日) 06:55 (UTC)

參照方針指引、參照方針指引條文的相關討論以推敲出條文的實際含義、思考該推敲出來的實際含義是否務實理性。亲，我簽名那刻的時間是 2024年12月22日 (日) 07:01 (UTC)

或許我説得更明白一些：評選的本質是予以到達一定品質的條目相應程度的認可，然而條目到達一定品質的時間點並沒有而且不應該有限制。亲，我簽名那刻的時間是 2024年12月21日 (六) 15:06 (UTC)

認同你這句話，然而評選過程也應該是嚴謹和公允。--黑暗魔君（留言） 2024年12月21日 (六) 23:40 (UTC)

見上。亲，我簽名那刻的時間是 2024年12月22日 (日) 00:19 (UTC)

主編或提名人把條目先提交給PR，即使期間得不到任何意見，我也認為這是主編或提名人一種盡責盡力的表現，嘗試過查找自己無法發現的問題或不足，我自己也會傾向這樣做。如果PR得不到反饋，而評選期間卻出現各種各樣的意見，只要這些意見是合理，我也不認為有甚麼問題，照樣根據意見改善，下次重新再提名就是。--黑暗魔君（留言） 2024年12月20日 (五) 05:18 (UTC)

我不認同的是Cdip150把「條目的問題不是應該參選之前就要知道」的問題完全推給「沒走PR或類似程序」這點，這種觀點我會覺得是完全悖於現實的。我希望藉上面的問題説明的是任何自我檢查、PR或類似程序都不能確保完全排除一切問題，主編無法發現條目所有的（潛在）問題不能完全一刀切地歸咎於主編，因為人（甚或AI）都不能確保自己100%不出錯。我留意到上面有用戶很瘋狂地一看到制衡壓綫反對意見的方案就無差別反對，而我也實在想不到一個能讓社羣成員回歸理性討論的辦法。另見上。Sanmosa _蚌埠 2024年12月20日 (五) 05:28 (UTC)

或許我再舉另一個例子：Talk:香港神社#新條目推薦討論裏提到的「境內」的用法的事情到底是否超出一般人的正常認知？它如何超出或沒有超出一般人的正常認知？Sanmosa _蚌埠 2024年12月20日 (五) 05:44 (UTC)

我認為這可能是一個爭議點，而不是一個實際的問題，倒不是說日文和中文或者術語非術語的問題，更像是允不允許使用非常見義或者引申義。比如「境內」，廣義實際上是「區域的邊界內部」，那用在這裡實際上沒有問題，但是非要去說成狹義，也就是「國家或地區的邊界內部」，那就是錯誤的。牛津詞典的釋義是近似前一種「國家或區域的邊界以內」。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月20日 (五) 05:59 (UTC)

然而，同樣地，把這推給「沒走PR或類似程序」也是不合理的吧？Sanmosa _蚌埠 2024年12月20日 (五) 06:02 (UTC)

這本身是一種爭議，也就是不管走內容評選還是PR（先當PR工作正常），都大概率會有人因為這種爭議出來提意見，這種爭議按道理是說服對方用法正確合理就行，不太需要改動條目本身。出現這類意見不應當推給沒走PR，只是說沒走PR會讓編輯沒法預見到內容評選途中出現這種意見。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月20日 (五) 06:09 (UTC)

你的話還好，然而現在社羣存在並不乏把這種你定性為「爭議」的東西的責任同樣一律歸咎於條目主編的人，這點我認為是非常危險的。Sanmosa _蚌埠 2024年12月20日 (五) 06:12 (UTC)

基於討論而有的建議方案4：

• DYK/FA/GA由目前提交「現行版本」改為提交「提交版本」
• 所有評審需基於「提交版本」進行。
• 不接受改票或棄票，點票員只會確認首投票是支持還是反對。
• 不接受支持或反對以外其他選項（包括疑問及意見），一旦發現，點票員可予以刪除。
• 如投反對，不用提供可接受的改善建議，但必須提出條目的哪個位置出現什麼問題。
• 於DYK/GA/FA引入cooldown time （最多24小時），在這時間，不接受新投票，只有點票員可以發言。
  • 如沒有人投反對票且符合通過要求指定票數，則通過論。
  • 如有人投反對票但符合通過要求指定票數，
    • 若然有人任一編輯者提出反對，隨即啟動cooldown time。
    • 點票員在cooldown time內透過檢視「提交版本」確定關反對意見是否正當合理。
    • 如合理，不通過
    • 如不合理，通過
  • 如有人投反對票但同時不符合通過要求指定票數，不通過。

--唔好阻住我愛國（留言） 2024年12月22日 (日) 09:30 (UTC)

首四點你是認真的嗎？黑暗魔君在上面發表一些不理性言論不代表你需要遷就那些不理性言論，共識僅考慮正當合理的意見。亲，我簽名那刻的時間是 2024年12月22日 (日) 09:32 (UTC)

@SunAfterRain@Hotaru Natsumi@Cdip150@Sanmosa@Patrickov@SickManWP@黑暗魔君

既然所有票數也是基於不可更改的 「提交版本」，那何時發表基本上也沒有分別。--唔好阻住我愛國（留言） 2024年12月22日 (日) 09:33 (UTC)

(－)反對：首四點反直覺。亲，我簽名那刻的時間是 2024年12月22日 (日) 09:36 (UTC)

(－)反對：第一、二：沒必要把原來的口子關掉，很顯然這個口子可以減少無謂的重複提交，如果條目在評選時間以內因為任何理由被改得足夠好，就沒必要因為提交時版本不夠好而拒絕通過，這樣實際上會讓條目被隨即（或在冷靜期後立刻）被重新提名；第三、四：明顯不合常識；第五：規範性指引不應當說明不需要做什麼，而是說明應當做什麼，這樣寫會讓PR和內容評選都無法得到有效意見，比現在的情況還糟糕；第六：這樣把計票者的權限拉到極其高的地步。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月22日 (日) 10:31 (UTC)（序號勘誤，主要內容沒變。於𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月22日 (日) 10:53 (UTC)）

@黑暗魔君：你看，也不是所有人都認同你如此偏激的觀點的。Sanmosa 2024年12月22日 (日) 10:38 (UTC)

實際上只要投票人有權保留反對票，我並不反對保留這個口子，我認為你誤解了我的意見。--黑暗魔君（留言） 2024年12月22日 (日) 10:44 (UTC)

「保留反對票」本身就不應該被視為一種「權利」。如果「保留反對票」能被視為一種「權利」，那它在條目符合要求時的惟一作用就只有故意阻攔符合要求的條目取得對應的優特狀態。Sanmosa 2024年12月22日 (日) 10:54 (UTC)

無論條目如何更改，你主張支持票也可以保留，但反對票就不能保留。如此雙重標準，那我當然只能堅持我的意見。--黑暗魔君（留言） 2024年12月22日 (日) 10:59 (UTC)

反對票在現行機制的影響力其實已經大於支持票了。DYKC裏除了反對票與支持票1:1抵銷的規定與4絕對票支持的要求外，其意見在實務操作上可以invalidate支持票所形成的結果。至於GA、FA與FL評選裏除了反對票與支持票1:1抵銷的規定與6或8絕對票支持的要求外，更要求反對票數低於或等於總票數的1/3才能使條目當選（後面這要求本來僅FA與FL評選適用，當初還是我來引入GA評選的）。現時的制度其實也是一種雙重標準，但是是偏向反對票的雙重標準。再者，現時實務上爭取認定反對票無效的要求非常高，因為即使反對票的理由完全不正當合理，管理員一般也不會處理這些請求，這使得反對票無論實際上是否正當合理也在計算上被認為有效。由此可見，理由不正當合理的反對票所產生的危害比你所仇視的所謂「水票」的危害大得多了，而你的所謂「公平」實際上損害了公義。Sanmosa 2024年12月22日 (日) 11:16 (UTC)

「反對票在現行機制的影響力其實已經大於支持票了。」完全不能認同，隨便一個可以不給理由的支持票就能抵消一個要花時間看條目、寫理由的反對票。可能閣下不太經常參與評選，不太了解不負責任的支持票有多猖獗。--黑暗魔君（留言） 2024年12月22日 (日) 13:48 (UTC)

你能説這話代表你完全無視了我上面寫的那一大串話。如果我説甚麽你都不認真看的話，那這裏的討論又有何意義？而且「不負責任」是很嚴重的指控，你僅因為現在的支持票不需要附理由而指控所有支持票「不負責任」屬於輕率指控，是文明方針所認定的粗魯無禮的行為。再者，真正「不太經常參與評選」的人可能是你而不是我。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月22日 (日) 13:50 (UTC)

或許黑暗魔君閣下確實應該具體證明現時不負責任支持票的猖獗情況，但您也似乎要冷靜一下。--派翠可夫 (留言按此) 2024年12月22日 (日) 14:20 (UTC)

@Patrickov：我嘗試冷靜一下，但如果他不認真看我的留言的行為持續，你恐怕要不斷重複這個提醒很多次。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月22日 (日) 14:31 (UTC)

你又超譯了，我不是「僅因為現在的支持票不需要附理由而指控所有支持票「不負責任」」，而是我的評選經驗能說明我為何覺得許多支持票都不負責任，如果你對此有質疑，你可以看一下我過往投反對票的評選，許多是顯然易見的問題，但仍有一堆支持票。無論你如何反對我，你也不能改變我在這方面的感受和意見。--黑暗魔君（留言） 2024年12月22日 (日) 14:53 (UTC)

我沒有指控過你的意見違反任何方針指引，然而閣下卻把各種帽子扣到我的頭上，甚至指我違反文明，實在匪夷所思。--黑暗魔君（留言） 2024年12月22日 (日) 15:08 (UTC)

你的「評選經驗」也只能説是你的個人感受而已（你總不會真的參與了中文維基百科所有的評選吧），個人感受是不能作準的（畢竟你看到的也不是全貌），因此還請你提出真憑實據，否則我仍將考慮提報。你這指控算是無差別攻擊了，既然你提出了如此嚴重的指控，那你必須預期大家會期望一個較高的舉證要求。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月22日 (日) 23:32 (UTC)

我不知道你想要提報甚麼？我沒有指名道姓指控誰，僅表示我認為支持票濫投現象嚴重。如果你期望用提報來威脅我閉嘴，可能只會有反效果。--黑暗魔君（留言） 2024年12月23日 (一) 00:07 (UTC)

Patrickov説的話你總也不能視而不見吧，你輕率地無差別指控他人，然後完全沒有任何的具體證明？原來現在指控他人的成本竟如此地低？我給出的指控在指控的當下已經給了具體證明，然而你給出的指控至今還是完全沒有任何的具體證明。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 00:22 (UTC)

我已經具體說明了：去看看我投反對票的那些條目，有顯然易見的問題仍有一堆支持票。你我在此問題上的分歧暫時不能達成共識，但你不停扣我的帽子不是解決分歧的做法。--黑暗魔君（留言） 2024年12月23日 (一) 00:27 (UTC)

然而我上面也提到了你看到的也不是全貌，你看到的東西也有可能是抽樣誤差。此外，如果你繼續試圖把我嘗試維護討論秩序的舉措視為惡意行為，那我會認為你是真的在無視指引規定。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 00:29 (UTC)

不參與全部評選就說看不到全貌，你要這樣說就無法討論了。--黑暗魔君（留言） 2024年12月23日 (一) 00:35 (UTC)

我自認參與評選與觀察評選狀況的頻率比你高（至少我很長的一段時間裏是每天都看那四個頁面的），然而我看到的情況是相當數量的評選裏的反對票的意見都並非正當合理，一個很具代表性的例子是這個與我上面提到的香港神社DYK。你説的情況也不是完全沒有出現，但出現的頻率遠遠沒有你說得那麽高。我也是看不到全貌的，但好歹我的sampling的涵蓋範圍是比你大的，相對而言抽樣誤差也就小了。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 00:47 (UTC)

你表示我的說法是「看不到全貌」，那為何維基百科:常年提案裡的「典優評審以非純點票形式結案」會出現「為解決不負責任支持票的問題，以其他模式取代（或半取代）純點票制結案。」按你的意見來說，這句話也是輕率指控和違反指引嗎？--黑暗魔君（留言） 2024年12月23日 (一) 00:54 (UTC)

WP:常年提案頁面裏的描述是可以改動的，「為解決不負責任支持票的問題」也只是一家之言而已，我記得有幾次改行共識制的討論是我發起的，然而如你在這裏所見的，我不認可所謂的「水票」問題。至於是誰不加思考把不恰當的輕率指控照搬到那個頁面裏我並不知道，但這確實並不影響那句話屬輕率指控並違反指引，畢竟我甚至還曾經當著管理員的面説過他違反規則的話。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 01:02 (UTC)

要這麼說，從這裡的討論來看，要管制壓線反對票暫時也只是一家之言而已，我同樣不認可需要管制。--黑暗魔君（留言） 2024年12月23日 (一) 01:29 (UTC)

然而我的sampling的涵蓋範圍是比你大的，這也意味著我的觀察的可信度比你的觀察來得高，不是嗎？你用一個可信度較低的觀察來否定一個可信度較高的觀察的結論並不合理。你要麽給更強的證據出來，要麽嘗試縮小你的抽樣誤差，否則我實在無法説服自己你的舉證是可信的。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 01:30 (UTC)

我嘗試總結一下你的意見，你認為相當數量的評選裏的反對票的意見都並非正當合理，壓線而不合理的反對票會導致本應當選的條目落選，所以壓線反對票需要管制。那麼我的意見就是，壓線反對票不需要管制，因為純屬擾亂的反對票本來就受到管制，而正當合理的反對票，不論是否壓線，本來就是為了阻止投票人認為不合要求的條目當選，不管條目有沒有在評選期間獲得修正，反對票也不會自動失效，因此沒有管制的需要。--黑暗魔君（留言） 2024年12月23日 (一) 01:45 (UTC)

「純屬擾亂的反對票本來就受到管制」這點不成立，見下。我自己就好幾次試過爭取將純屬擾亂的反對票認定為無效，然而每一次都徒勞無功，管理員根本不管。但凡管理員認真處理這事，這提案也不可能現在就出現。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 01:47 (UTC)

如果是為了管制純屬擾亂的反對票而把合理的反對票都一併管制，這個方向也不對吧--黑暗魔君（留言） 2024年12月23日 (一) 01:57 (UTC)

我上面説的事情會發生的根本原因是管理員無能力或拒絕區分純屬擾亂的反對意見與正當合理的反對意見。如果不是這樣的話，我也不想的，現在把反對意見一概管制也是考慮到管理員的能力與意願的緣故，這就是主觀意願受客觀條件制限的一種情況。當然，我自己還是會比較傾向於Hotaru Natsumi上面提到的grace period方案。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 02:04 (UTC)

這樣說吧，投票制度下，你指望所有選民的投票都是理性是辦不到的。無論是「水票」還是「純屬擾亂的反對票」也會存在，如果你要管制「純屬擾亂的反對票」，那麼我會認為「水票」也要管制才對。--黑暗魔君（留言） 2024年12月23日 (一) 02:29 (UTC)

@黑暗魔君：這樣説吧，從過往的實踐經驗來看，你口中的「水票」是無法管制的。2015年時DYKC曾引入投票附理由的硬性規定，但隨後引發了支持理由為「符合標準」的有效性的問題，而社羣的結論是投票附理由的硬性規定屬於形式主義，無助於解決所謂的「水票」問題，但是當時的意見比較不傾向於直接廢除該硬性規定，導致當時最終的結論變成了理由為「符合標準」的支持票被認為有效。然而這只不過是把該硬性規定的形式主義問題延後爆發而已，2019年的討論最終重新廢除了該硬性規定。支持票（或許這樣説，投票制）的存在本身就意味著所謂的「水票」存在，任何試圖管制所謂的「水票」的approach都必定是擾民與形式主義的，因此所謂的「水票」在事實上是無法管制的。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 02:53 (UTC)

都是投票制的產物，你認為「水票」無法管制，但認為為了管制「純屬擾亂的反對票」而一併把所有反對票都管制，對我而言，這樣的說法不能說服我。--黑暗魔君（留言） 2024年12月23日 (一) 03:13 (UTC)

那很簡單，如果你能提出一個能有效管制你口中的「水票」而且還不擾民與形式主義的方案，那我可以reconsider我的意見，然而我不認為這裏的任何一個人能做到。再不然你就讓管理員有能力且不再拒絕區分純屬擾亂的反對意見與正當合理的反對意見，如果你能做到的話，我確實會認為這裏的提案都是不必要的。我希望給予你的一個建議是你應該嘗試把客觀條件置於主觀意願之前，而不要假定自己的主觀意願是必定能實現的。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 03:23 (UTC)

此外，「無論你如何反對我，你也不能改變我在這方面的感受和意見」這句話也是違反規則的，這落入了WP:共識#形成共識的誤區和錯誤所説的「傾向性的編輯」的範疇，而從上面的情況來看你已經成功地讓這討論串變成了冗長辯論，當然你也並非中文維基百科裏第一個這樣做的人就是了。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月22日 (日) 23:44 (UTC)

致黑暗魔君閣下：個人認為您說的現象與Sanmosa君所述都對。一方面支持票確實可直接抵銷反對票；另一方面反對票由於規則所限，內容必然較豐富，部份較高級的評選更要求反對票不超過某一比例，故單一反對票的「實際震懾力」確實也大於同量的支持票。本人其實也在DYKC見過有人投反對之後，即使條目已改善，其他人也完全不敢再投支持的情況。本人還不計反對者有可能會狙擊支持票（例如Kalin8111君就曾在投反對票時公開質問投支持票的人，留意本人並沒有認為他不對，只是想指出有這種可能性而已）。本人的看法是：Sanmosa君所述的效果，正是為了減緩您提出的「猖獗」情況。當然，如果您能稍為舉證證明這種「猖獗」情況，效果會更佳。--派翠可夫 (留言按此) 2024年12月22日 (日) 14:38 (UTC)

嗯，你說的東西我之前在ANM也有説過，然而我無法阻止任何想要視而不見的人視而不見。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月22日 (日) 14:42 (UTC)

本人比較認為是大家關注的重點不同而已。先看他對本人的解讀有甚麼回應吧。--派翠可夫 (留言按此) 2024年12月22日 (日) 14:49 (UTC)

@Patrickov：現在看來並非如此，他都開始無視指引規定了。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 00:26 (UTC)

目前的評選確實往往出現一個現象，就是有些人的心態是「既然有人提出反對，那我就先觀望」，而不是獨自評估並給出自己的判斷。歸根究底，我認為這與整體的評審素質有關，這不是反對票自身的本意，把它歸納成反對票自身的震懾力，我認為不太準確。--黑暗魔君（留言） 2024年12月22日 (日) 15:40 (UTC)

然而主觀上是否有震懾的意圖並不影響客觀上是否有震懾的效果，你不能因為主觀上震懾的意圖不存在而否認客觀上震懾的效果存在。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月22日 (日) 23:34 (UTC)

基本上反對提案3的均認為最後一刻投反對票的對提名人來說是「活該」的，而且堅持使用「提交版本」進行評審。論「提交版本」，這是不可變更的，故無論如何在評審期間如何優化，也無法改變「提交版本」。如果是對「現行版本」進行評審，理應給予充足時間讓提名者進行修改。倘若有人在評審期間對條目作出破壞，那提名者也需要在極短時間完成修正，獲取投票者的支持。--唔好阻住我愛國（留言） 2024年12月22日 (日) 12:22 (UTC)

然而管理員説的話也不一定是正確的，比如管理員認為某個用戶「活該」並不代表他真的「活該」。Sanmosa 2024年12月22日 (日) 12:28 (UTC)

既然都可以確認是破壞造成的結果那直接結算時跳過就好了嘛，投票的人不讀條目沒去看是不是破壞的結果，其他人和點票員也要這樣犯蠢嗎？（很明顯其他看出來的人可以作提醒嘛）--SunAfterRain 2024年12月22日 (日) 18:24 (UTC)

@SunAfterRain：然而實務上就算我們真的和管理員這樣説了，管理員還是不處理，因此按規則這些票還是不能被算成無效。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月22日 (日) 23:41 (UTC)

@Sanmosa：我個人傾向認為這是可以IAR處理的啦，不過就扯遠了。--SunAfterRain 2024年12月23日 (一) 03:38 (UTC)

@SunAfterRain：你猜我沒提過這事嗎？我提過了，但管理員還是不處理。如果你真的要把這種情況形容為「犯蠢」的話，那我認為這個形容詞適用的地方可能比你想像中多。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 03:42 (UTC)

我知道能用的地方很多啊，只是我也懶得吐槽而已，多我一個人吐槽也不會改變事實的話就不要水編輯啦。--SunAfterRain 2024年12月23日 (一) 03:45 (UTC)

然而從上面的討論可見，適當的時候還是該提一下的，不然會真的有人否認問題存在。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 03:57 (UTC)

改走RFC機制。Sanmosa 2024年12月22日 (日) 11:18 (UTC)

至少(－)反對第1-4點。

• 第1-3點執行上有困難。除非有管理用機械人自動在評選開始時全保護頁面，否則用固定版本評選、忽略後續改動，會造成混亂。（留意條目上首頁後，連結是連到現行版本的）
• 關於第4點，如上方Sanmosa君及黑暗魔君閣下所述，支持、反對票各有其威力，本人一般不會輕易投下。即使有意見，本人也傾向以意見表示。現在在評選中禁絕這種操作，本人該如何發表意見？去條目討論頁另開一串的話可能也會造成混亂。

以上--派翠可夫 (留言按此) 2024年12月22日 (日) 14:44 (UTC)

小(～)補充：或許也可以考慮在投票須知中加入WP:請讀條目的連結 -- 派翠可夫 (留言按此) 2024年12月22日 (日) 15:43 (UTC)

除了5以外全部(－)反對（並且因為5是常識所以也不該列進條文），請不要因噎廢食。--SunAfterRain 2024年12月22日 (日) 18:17 (UTC)

不同意任何形式之所謂「冷靜時間」，也不同意以上任何箝制評選或給編者「分級賦權」之提議，不僅全部不現實，也變相消極阻礙編者即時改善條目。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月24日 (二) 04:54 (UTC)

不是，這裏哪裏出現了「分級賦權」？Sanmosa _腦洞大開 2024年12月24日 (二) 05:18 (UTC)

「點票員」是啥鬼？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月25日 (三) 14:30 (UTC)

@Ericliu1912

檢查員：巡查員、回退員、巡查豁免者及管理員

在草案中基於行為選擇此詞，並無特別意思。--唔好阻住我愛國（留言） 2024年12月25日 (三) 14:39 (UTC)

基於上方建設性意見而有的建議方案5 （不包括缺乏可接受建議的意見）：

• DYK/FA/GA評選「現行版本」。
• 如有第三方進行破壞，提名者應及時回退及上報，若相關用戶因此被封禁，點票員可酌情延長投票時間至最多12小時。
• 提名人有責任在有結果前持續維持條目品質，當中包括提名期及cooldown time。
• 如條目在提名期間遇上編輯爭議且被提報，「即時不合資格」。
• 如投反對，必須在一個回覆內指出條目的哪個位置出現什麼問題。如果是全篇條目有問題，應考慮掛上維護模版，從而讓點票員判定「即時不合資格」。
• 於DYK/GA/FA引入cooldown time （最多24小時），在這時間，不接受新投票，只有點票員可以發言。
  • 如沒有人投反對票且符合通過要求指定票數，則通過論。
  • 如有人投反對票但符合通過要求指定票數，
    • 若然有人任一編輯者提出反對，隨即啟動cooldown time。
    • 點票員在cooldown time內根據反對意見，檢視「現行版本」確定相關指明位置是否有提出的問題及相關反對意見是否正當合理。
    • 如合理及相關問題仍然存在，不通過，點票員會另外解釋不通過的原因。
    • 如不合理或相關問題已經解決，通過
  • 如有人投反對票但同時不符合通過要求指定票數，不通過。

以上！另註：這個方案是避免水票泛濫。反正現行做法投票期後不是即時點票，這個空間交由點票員決定何時開票。--唔好阻住我愛國（留言） 2024年12月25日 (三) 09:17 (UTC)

基本上Cdip150說得全對，現有制度已提供重新提名及例外寬限管道，你所說情況（如非預期破壞等）也有前例，沒有必要選定一個期間作「冷靜期」來處理。另外，我根本建議將新條目推薦候選與其他評選分開討論（當然並不代表其中一方必定可以通過），後者更偏向共識制一些，又有提名冷卻期，故你所謂「冷靜期」或許有機會適用。但總之，上述方案細節仍太粗糙，要再討論。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月25日 (三) 14:50 (UTC)

@Ericliu1912：那我想你看一看我上面的兩段話（1、2）後再想一下「Cdip150說得全對」這個説法是否有問題的。當然，這並不代表我支持HK5201314的提案。Sanmosa _腦洞大開 2024年12月26日 (四) 02:00 (UTC)

至少就我個人過往參與情況，他說得大部分正確。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月27日 (五) 23:29 (UTC)

說好聽些，「大部分正確」並不是「全對」，還是有不正確的地方，現在的情況就是不正確的地方無法得到妥當的處理，因此需要想辦法處理不正確的地方。說難聽些，在PR無法有效運作的情況下，Cdip150他説的完全就是空話，把一切問題不論具體情況統統歸咎於條目主編「自己討來」可謂對中文維基百科社羣的無差別惡意。Sanmosa _蘭絮 2024年12月28日 (六) 01:07 (UTC)

因涉及超過一個總政策，故移回客棧，待討論完結一併存檔。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月27日 (五) 23:29 (UTC)

@Ericliu1912：在你把討論串再搬來VPP後，VPP的長度立即超過20萬位元組了，那我在WT:互助客棧#有關互助客棧方針版的長度壓力問題提的問題就會再度出現，還請你以後搬運討論時先考慮一下頁面的載入問題，不然這對所有參與討論的人都不好。Sanmosa _蘭絮 2024年12月28日 (六) 01:12 (UTC)

@Sanmosa：我其實有考慮過，所以仲委會的話題就沒移動回來（畢竟亦已完結）。而且不知你是否有注意，閣下此前一週餘所移動大部份政策話題，幾乎移回討論頁後，討論便從此停滯。這對政策討論實是相當不利，也證明徵求意見制度有其局限。當然，此話題參與本相對熱烈，故若討論篇幅繼續暴漲，仍可考慮再移回討論頁。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月28日 (六) 01:29 (UTC)

為RFC議題清單裏的每個列表項都加一個能產生目次連結的anchor可能有一定的正面效果，但這可能需要再討論。Sanmosa _蘭絮 2024年12月28日 (六) 01:32 (UTC)

行。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月29日 (日) 06:04 (UTC)

理論上相關試行議案即將完結（原提案指12月交報告），路西法人至今仍未交報告。@Ericliu1912，是否可以發起討論終止整個試行議案？--唔好阻住我愛國（留言） 2024年12月28日 (六) 03:09 (UTC)

【諷刺性評論】看上去有點挺複雜的，我提一個一步到位的方案（？）吧。

• DYK/GA/FA 評選現行版本。提名人提交後條目接受全保護。
• 提交後，由專門人員進行即時不合資格審核。如果通過審核，則交由審閱人審核。
• 審閱人有一周時間對條目提供評論。在此期間，評論內容對投稿人保密。
• 評論公開後，提名人有一周的時間對審閱人的意見進行回應，也可以向點票人傳送私密消息。
• 回應時間結束後審閱人可以更新自己的評論。點票人平衡審閱人的意見和作者的回應決定是否通過提名。
• 提名人可以在任何時候撤回提名，點票人可以在任何時候宣告即時不合資格。
• 審閱結束後條目解除保護，作者進行對應的修改，之後上首頁。
• 極不負責任的審閱人可由點票人實行對應的懲罰，比如無條件拒絕其提名的條目等。

什麼？看上去好熟悉？這就對味了嘛～

整個社群評審共識製做不起來，上面的1-5所有方案都不治本。連治標都不好說。--MilkyDefer 2024年12月28日 (六) 03:15 (UTC)

然而社羣確實無能力實行評選共識制？Sanmosa _蘭絮 2024年12月28日 (六) 03:41 (UTC)

（我也不對共識制有希望，或者說，以前有過）--MilkyDefer 2024年12月28日 (六) 03:47 (UTC)

然而壓綫發表意見（不論是否評選）本質上應該不是constructive的？Sanmosa _蘭絮 2024年12月28日 (六) 06:50 (UTC)

電子遊戲與日本動漫條目命名的標點符號使用規定

參照Talk:加油！中村同學！！，現提議如下：

修訂WP:命名常規 (電子遊戲)

現行條文 外文遊戲副標題的表示方式尊重原題，但標題中的非中文標點應改為對應中文標點（例如英文「:」和日文「〜」應改為中文下的全角「：」和「～」）。

提議條文 外文遊戲副標題的表示方式尊重原題，但標題中的非全形標點應改為對應全形標點（例如英文「:」和日文「〜」應改為中文下的全角「：」和「～」）。前後均緊接半形字符（包括但不限於拉丁字母、數字、半形標點等，下同）的標點符號與前接半形字符且位於末端的標點符號例外，這兩種情況下標題中的非半形標點應改為對應半形標點。

為WP:命名常規 (日本動漫遊戲條目)新增條文

新增條文如下：

「 條目標題中標點符號的使用不受上述規則所限，而受下述規則所限：

1. 任何緊接全形字符的標點符號應用全形；
2. 前後均緊接半形字符（包括但不限於拉丁字母、數字、半形標點等，下同）的標點符號應用半形；
3. 前接半形字符且位於末端的標點符號應用半形。

」

以上。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 04:10 (UTC)

依WP:共識#提案討論及公示時間，互助客棧中的提案在7日內無新留言時可在已取得共識的前提下公示，故現公示此案7日。Sanmosa _蘭絮 2024年12月31日 (二) 02:26 (UTC)

條文沒有問題。是不是提示一下半角字符包括英文字母比較好？--The Puki desu（留言） 2024年12月31日 (二) 09:24 (UTC)

那我希望知道現時有多少條目標題使用到全形的拉丁字母的。Sanmosa _蘭絮 2024年12月31日 (二) 09:52 (UTC)

我只是覺得可能大部分人只知道標點符號有全角和半角的區分。我先確定一下，這個修訂會讓如「COVID-19」中間的連接符使用半角「-」而不是全角「−」吧。--The Puki desu（留言） 2024年12月31日 (二) 14:24 (UTC)

「COVID-19」不是電子遊戲或日本動漫遊戲吧？但假設是的話，你説得對。Sanmosa _蘭絮 2025年1月1日 (三) 01:50 (UTC)

我也只是一時想不起來什麼電子遊戲的名字有這個格式，所以舉了這個例子，既然如此我覺得你的提議條文是正確的。那我覺得你標註一下「半角字符（如英文標點符號、拉丁字母、數字）」會更好。--The Puki desu（留言） 2025年1月1日 (三) 02:26 (UTC)

@The Puki desu：已調整。Sanmosa _蘭絮 2025年1月1日 (三) 02:48 (UTC)

WP:SW

現今劇透內容大多是原創研究，是否需要增加劇透必須為非原創研究，敬請公決。-- A0_{(討論·簽名)} 2024年12月24日 (二) 13:15 (UTC)

現今劇透內容大多是原創研究？未標來源是使用了作品作為一手來源，而非原創研究。當然，一些可能有爭議的劇情（比如懸疑劇的不同解讀）我確實認為應要求加入來源，而不能由編者自己分析。但「大多是原創研究」並不至於吧？敘述不會有爭議的劇情雖當然有來源更好，但不標註來源也不構成原創研究。--自由雨日🌧️❄️ 2024年12月24日 (二) 13:23 (UTC)

在格式手冊/虛構的作品寫法格式中，是沒有強制相關作品介紹或者劇情介得要加上引註，可以另外參照轄下的章節引用與來源內容資訊的描述，作品本身的介紹可以視為WP:第一手來源，但也可以添加引註，而這不影響整體作品介紹。--薏仁將🍀 2024年12月24日 (二) 22:35 (UTC)

那會影響典優條目的評選嗎-- A0_{(討論·簽名)} 2024年12月25日 (三) 00:14 (UTC)

當然不會。《普羅米修斯》 ——自由雨日🌧️❄️ 2024年12月25日 (三) 00:21 (UTC)

永遠都是有則更好無則也罷。當然，高度爭議性的劇情，以及非明顯的劇情解釋除外。--MilkyDefer 2024年12月27日 (五) 04:51 (UTC)

如果是對未來事件的預判，用下方陳述換算處理對等議題

• 2024年12月27日 (五) 10:47 (UTC)，XXX書出版第12冊
• 2025年2月8日，XXX書出版第13冊

因第12冊和第13冊出版物根本還沒有公開，更新第12及13冊內容時屬於原創內容(混合WP:水晶球)，因為添購12冊和13冊需要時間，包含取得書籍的運輸時間、拆封時間、閱讀資料的時間等，在剛經過2024年12月27日 (五) 10:47 (UTC)這個時間點不久的資料更新的第12冊資訊也屬於原創內容，具體還要考慮資料來源的通路。如果在奇妙的時間點產生12冊或13冊資訊，且資訊正確，只能假定WP:COI或者資訊來源產自盜版，如果是後者，還有維基百科是否支持收錄盜版資訊的問題。--Rastinition（留言） 2024年12月27日 (五) 09:54 (UTC)

然而他說的是劇透行為根本不涉及未來作品的內容。而是涉及到觀看者向未觀看者提前預知已有作品劇情的行為。（對於非影視愛好者來說，被劇透確實是一種很難理解的事情。）----甜甜圈認為2025年是朝鮮和台灣最惡臭的一年 2024年12月27日 (五) 11:04 (UTC)

這樣説吧：現在尹錫悅與韓悳洙都已經被南韓國會彈劾了，但假如有人在現在甚至連尹錫悅宣告戒嚴的事情也不知道的話，那你告訴他尹錫悅因為宣告戒嚴而被南韓國會彈劾的事情屬於這裏所討論的劇透。由於韓悳洙是在今天才被南韓國會彈劾的，假如我在昨天告訴那位連尹錫悅宣告戒嚴的事情也不知道的人韓悳洙被（注意不是「會被」）南韓國會彈劾的事情的話，這不是劇透，而是預測。Sanmosa _腦洞大開 2024年12月27日 (五) 12:10 (UTC)

他沒提「作品未來劇情如何發展」，針對的是一般情形的劇透？( π )題外話隔壁萌娘百科倒是在討論BanG Dream! Ave Mujica超前點映帶來的「作品未來劇情如何發展」問題。--屠麟傲血（留言） 2025年1月2日 (四) 11:03 (UTC)

請先定義「劇透」，有些官方在作品外公布的消息，一部分作品觀眾回顧可能都覺得構成了劇透（很極端的情況）。如果這都要被打上原創研究的表簽，也太寸步難行了。--屠麟傲血（留言） 2025年1月2日 (四) 11:03 (UTC)

重提為可供查證方針與可靠來源指引調整有關用戶生成內容的規定

此前提議為可供查證方針與可靠來源指引調整有關用戶生成內容的規定的討論以無共識作結，然而當時我自己的提案在經過解釋後並未遭到任何人的反對，因此我感覺我的提議應該是有機會能凝聚共識的，為此我希望把我的提案再一次交予社羣檢視，以促進中文維基百科及其社羣的建設性發展。具體提案如下：

WP:可供查證

現行條文 個人出版物（網絡與紙媒） 任何人均可自創網站或自費出書，並藉此聲稱自己是某領域的專家。因而，絕大多數個人出版之書籍、業務通訊、個人網站、開放性wiki、網誌、內容農場、論壇貼文、社群媒體及類似來源均不得被認可為可靠來源。 但在某些情形下，個人出版物亦仍可以被接受。例如，出版人為受到肯定的專家，從事與條目主題相關領域的工作，並曾在可靠的第三方出版物中發表過該領域工作的文章。但是，此類來源的使用需要謹慎，並且如果有關信息的確值得記載，很可能已有他人做了相同的工作。 個人出版物在任何情況下均不可作為有關在世人物的第三方來源，即便其作者是著名的職業調查員或作家。詳見維基百科:生者傳記。 參考資料

提議條文 個人出版物（網絡與紙媒） 任何人均可在網絡上發表言論或自費出書，並藉此聲稱自己是某領域的專家。因而，絕大多數個人出版之書籍、業務通訊、個人網站、開放性wiki、網誌、內容農場、論壇貼文、社群媒體及類似來源通常不被認可為可靠來源。 但在某些情形下，個人出版物亦仍可以被接受。例如，出版人為受到肯定的專家，從事與條目主題相關領域的工作，並曾在可靠的第三方出版物中發表過該領域工作的文章。但是，此類來源的使用需要謹慎，並且如果有關信息的確值得記載，很可能已有他人做了相同的工作。 個人出版物在任何情況下均不可作為有關在世人物的第三方來源，即便其作者是著名的職業調查員或作家。詳見生者傳記方針。 參考資料

WP:可靠來源

現行條文 BBS、wiki和新聞組的帖子 BBS和新聞組的帖子、Wiki的內容或者Blog上的留言都絕不能成為可接受的一次或者二次來源。這是因為我們無法知道它們究竟是誰寫的。對於Wiki的情形，文章的內容可能在任何時刻發生變化，而且沒有編輯人員監管或者第三方核查事實。

提議條文 用戶生成內容 由於缺乏事實查核以及普遍有效的帳戶認證，用戶生成內容通常並不可靠。此類內容可能在任何時刻發生變化，而且缺乏編輯人員監管或第三方事實查核。個人網站、博客、網絡論壇、社交媒體、粉絲網站、視頻分享網站、網絡相冊、Wiki通常都含有用戶生成內容。 部分社交媒體設有帳戶認證制度，以表明某個社交媒體賬戶由真實個人或組織擁有並運營。在這種情況下，該賬號的可靠性可以自該人或組織本身繼承。

以上。Sanmosa _腦洞大開 2024年12月27日 (五) 13:15 (UTC)

贊成。「可以自該人或組織本身繼承」改成「可能」，存在賬號竊用或濫用。最後一句可能需潤色，例如「部分社交媒體的賬號認證制度可表明賬號由可靠的個人或組織持有，此種情況下該賬號的言論有可能繼承賬號持有者的可靠性。」--YFdyh000（留言） 2024年12月27日 (五) 13:40 (UTC)

@YFdyh000：帳號竊用或濫用不屬於一般情況，如果有人在帳號遭竊用或濫用的情況下仍然堅持主張帳號的可靠性自該人或組織本身繼承，這屬於遊戲規則，因此這樣改是不必要的。Sanmosa _腦洞大開 2024年12月27日 (五) 14:17 (UTC)

存在懷疑、質疑但無法定論的情況。包括小編、助理或其他人操作賬號的現象。基於WP:斷言，如果出現令人意外的內容，認證賬號言論的可靠性不應繼承，認證賬號作為單一身份因素，可能無法全權代表當事人意見。--YFdyh000（留言） 2024年12月27日 (五) 14:32 (UTC)

@YFdyh000：「可以自該人或組織本身繼承」的「可以」本來也不是絕對性的，WP:可供查證#非同尋常的斷言需要非同尋常的來源作為方針本就有比指引稍高的優先性，WP:可靠來源指引的規定應該要被理解為並不優先於WP:可供查證等方針條文執行的，因此我還是認為這樣改是不必要的。Sanmosa _蘭絮 2024年12月27日 (五) 15:10 (UTC)

那還好，但仍覺得「可以繼承」的含義類似「等同」，所以傾向改。其他條文修改我沒意見。--YFdyh000（留言） 2024年12月27日 (五) 15:15 (UTC)

自創網站這一點不應該去掉吧？和自費出書是一個性質。——暁月凜奈 (留言) 2024年12月27日 (五) 16:04 (UTC)

定義不清、沒什麼意義，開一個博客賬號算自創網站嗎，與開設獨立博客站有多少區別。--YFdyh000（留言） 2024年12月27日 (五) 16:34 (UTC)

贊成--Xiumuzidiao|本是青燈不歸客，卻因濁酒戀紅塵※【留言】 2024年12月27日 (五) 16:47 (UTC)

在X，認證制度是買回來的，阿豬阿狗也可以在完成X premium的購買過程後就可以擁有認證。

在小紅書，不是想花錢都可以搞認證，只要相關用戶具備他們定下的關注度要求，交足指定文件才可以擁有認證權。

在Meta，帳號要達到指定追蹤數，然後交身分證資料就可以擁有認證。

上述平台的認證制度均是月費制或年費制，只要不付款，平台就會剝奪認證。

.

當時我說，維基百科應訂立一套自己的認證制度，避免依靠平台的認證制度，於是寫了一大篇論述說明如何認證。有人認為剝奪認證等於平台不為相關用戶的真實性背書。那現在我說，那如果有創作者不認同認證制度而不使用認證功能（像KMB Instagram 帳號；這個帳號在香港是僅有不做認證的帳號之一且獲官方網站及媒體多次引用。）；萬一其他平台更改認證制度，至像X一樣，任何人也可以購買認證 ，如維基照單全收平台的認證，則大大降低認受性。

.

所以我是(－)反對這句：「部分社交媒體設有帳號認證制度，以表明某個社交媒體帳號由真實個人或組織擁有並運營。在這種情況下，該帳號的可靠性可以自該人或組織本身繼承。」--唔好阻住我愛國（留言） 2024年12月27日 (五) 17:14 (UTC)

另外我記得印象中可供查證原文並沒有「社群媒體」選項，相關選項至今是沒有達成共識，應該是有不明編輯者擅自加進去的。--唔好阻住我愛國（留言） 2024年12月27日 (五) 17:22 (UTC)

「維基百科應訂立一套自己的認證制度」是怎樣的存在，原創研究還是WP:RSN？「不使用認證功能」我認為仍可通過其他渠道（例如官方鏈接）和討論辨別，以及並不能照單全收認證機制，那只是用來參考。「購買認證」後的認證結果是？並不是認證=可靠來源，僅僅是認證=證明身份。上方也提到只是指引。有無「社群媒體」未感到差異。--YFdyh000（留言） 2024年12月27日 (五) 17:39 (UTC)

WP:RSN或官方連結或討論辨別也是可接受方法。

歐盟也說「 歐盟委員會指出，在「黑暗模式」（dark patterns）一類，X平台使用了該模式來誤導用戶，影響用戶在真實資訊下作出自由判斷的能力；藍勾勾認證方面，則是允許任何人透過訂閱獲得藍勾勾認證，這不符合產業慣例，並且有證據表明「有動機的惡意行為者」濫用此認證來欺騙用戶。 [1]」歐盟說這句的原因是[2]—>意指「 僅僅是認證不能等於證明身分」--唔好阻住我愛國（留言） 2024年12月27日 (五) 18:29 (UTC)

所以我傾向「可能」而非「可以」，以便用共識排除特定認證的可靠性與可用性。關於惡意濫用，基於WP:SOCIALMEDIA，來源可以只證明可供查證的事實（認證為XXX的賬號發表XXX）或者因突兀斷言而不寫，無需過度擔心。--YFdyh000（留言） 2024年12月27日 (五) 19:10 (UTC)

我看了一下最近的RSN存檔，似乎RSN機制在近期無法產生甚麽有效的結論，我擔憂依賴RSN機制會導致條文實際上的執行情況比本來設想的遠更嚴格。而且你應該還記得你上次因為在參與這個話題的討論時有不當行徑而被封鎖WP空間的編輯1年的事情吧？Sanmosa _蘭絮 2024年12月28日 (六) 01:21 (UTC)

• RSN失效的原因是機器人已重投運作，準時存檔，缺乏共識的仍依舊存檔，沒有等待人進來討論。
• 請問閣下是否記得是誰執行當次封鎖？現在那個人去了哪裡？（已離題）

--唔好阻住我愛國（留言） 2024年12月28日 (六) 02:31 (UTC)

放下棍子，並從馬的屍體慢慢離開，RSN的存檔機制並無問題。你莫不是忘記了自己封鎖申訴被拒的事情？Sanmosa _蘭絮 2024年12月28日 (六) 04:37 (UTC)

由於被管理員認定為擾亂，本框內討論文字已關閉，相關文字不再存檔。

如有異議，請諮詢互助客棧或其他管理員。執行人：Sanmosa _蘭絮 2024年12月29日 (日) 05:45 (UTC)

RSN的存檔機器人並無問題呀！問題是RSN的存檔機制7日對於冷門討論區才是問題，這個與你強推RfC一樣，當一個討論被安排至冷門區域繼續討論時，像Eric管理員指出的一樣，會變得無人發言/討論氣氛非常冷淡。最終誠如閣下道「RSN機制在近期無法產生甚麽有效的結論」。--唔好阻住我愛國（留言） 2024年12月28日 (六) 05:04 (UTC)

我無法阻止你胡亂牽扯其他事情，但我還是這句話：「放下棍子，並從馬的屍體慢慢離開」。Sanmosa _蘭絮 2024年12月28日 (六) 05:14 (UTC)

是你「牽扯」我的封禁記錄讓我禁言在先，你見我有阻止你嗎？--唔好阻住我愛國（留言） 2024年12月28日 (六) 05:19 (UTC)

然而你現在做的事情和你當時做的事情如出一轍，ANM那邊就另一案的意見也不認為在處理當前不當行為時綜合考慮過去的長期同類行為屬於翻舊帳。此外，我建議你看一下蟲蟲飛的前例，你胡亂聲稱我意圖「禁言」只會顯得你更沒有道理。Sanmosa _蘭絮 2024年12月28日 (六) 05:31 (UTC)

另外，當時Elon並還未入主Twitter，故你們不明白我的擔憂，現在經歷過Twitter Blue事件，我的擔憂已充分得到驗證。未來我會放一個維基假期，暫不會推新想法，完成不限期那個提案後就休息。

總之，只要提案指依靠平台認證證明身分，我是無條件反對。--唔好阻住我愛國（留言） 2024年12月28日 (六) 02:38 (UTC)

「無條件反對」之說屬WP:共識#形成共識的誤區和錯誤所稱的「傾向性的編輯」，「如若編者拒絕任何共識而固執己見，無限期地發表冗長辯論以實現其目標，那麼他／她將會破壞掉共識過程」，因此此意見不被視為正當合理的意見。Sanmosa _蘭絮 2024年12月28日 (六) 04:39 (UTC)

你是不是想玩程序戰？透過查找用戶的不足而不讓/無視用戶發言。我有提供可接受方案，但你沒有基於我提出的方案展開討論，這個是你的問題。--唔好阻住我愛國（留言） 2024年12月28日 (六) 04:56 (UTC)

現在看起來是你想強推不被社群認可的方案，看來你想犯下兩年前我發生的過錯？--唔好阻住我愛國（留言） 2024年12月28日 (六) 04:58 (UTC)

然而這裏現在也只有你一個人有反對意見，而且還是不合理的反對意見。YF上方的說法是「那還好」，這已經代表他並不反對我的說法了。Sanmosa _蘭絮 2024年12月28日 (六) 05:11 (UTC)

WP:共識不是點票這個道理你應該是明白的嗎？你一日未解決所有合理反對意見，一日我會堅持撤下公示以繼續討論。

我重申，我的反對意見是平台的 「僅僅是認證不能等於證明身分」。這個歐盟政府也這樣說。在閣下的提案指出「 在這種情況下，該帳號的可靠性可以自該人或組織本身繼承。」我理解為100%依靠平台的認證決定身分。在Twitter Blue事件當中，有不少所謂假冒者假冒「著名人士」註冊認証並成功通過，如果按照你的提案中的這句「在這種情況下，該帳號的可靠性可以自該人或組織本身繼承。」那些假冒者的言論將視為「著名人士」的言論。

我擔心後續還可能有類似Twitter Blue事件再發生，故提出 「訂立一套自己的認證制度」。下方@Rastinition的方案我是支持的，反建議基於他的方案做些少延伸。

以上！--唔好阻住我愛國（留言） 2024年12月28日 (六) 05:51 (UTC)

共識應當考慮到所有正當合理的意見；共識不強求一致同意。Sanmosa _蘭絮 2024年12月28日 (六) 06:07 (UTC)

由於HK5201314的言論已被管理員認定為擾亂，再加上前次討論對其觀點的強烈不認可，我有理由相信HK5201314的意見應被認為屬WP:共識#提案討論及公示時間所稱的「並非正當合理的意見」。此外，HK5201314的意見中尚算合理的部分已獲YFdyh000的有效合理解釋，因此應認為HK5201314的意見中尚算合理的部分已獲解決。Sanmosa _蘭絮 2024年12月29日 (日) 05:49 (UTC)

維基百科「訂立一套自己的認證制度」似乎屬於原創研究？Sanmosa _蘭絮 2024年12月28日 (六) 01:03 (UTC)

下文不針對條文解釋及處理，但實際上應該可以混合已經存在的WP:RSN針對個別處理，另外提及其它概念

• 原則性的禁止使用en:WP:UGC，判斷是否可以使用的要個別另外處理。可豁免的例外以明顯是組織及WP:生者傳記明述的生者自身發表的內容可以成為來源(但不能成為主要來源)，以官方網站為例，在官方網站所陳列其它官方連結的不用各別處理。
• ( π )題外話WP:外部連結有提及如果A頁面(官方網站)已經提供B、C等不同網域連結，不用再列，我提的豁免是指A頁面(官方網站)陳列的不同網域連結。
• 總結第一手來源的使用原則上要節制，幾乎只用第一手來源當成主要依靠的條目本身，和直接閱讀第一手來源的價值相等。這樣的條目存在沒有什麼價值。僅是純粹的第一手來源轉譯品。

--Rastinition（留言） 2024年12月28日 (六) 01:21 (UTC)

第二分段可以改為「豁免的例外以明顯是組織及WP:生者傳記明述的生者自身發表的內容可以成為來源(但不能成為主要來源)」+ 如何認證（可接受方案如針對媒體用RSN，針對組織或關鍵人物用自身條目的外部連結。缺乏條目者都不應被維基保證及引用。）--唔好阻住我愛國（留言） 2024年12月28日 (六) 02:50 (UTC)

題外話：或許更應該考慮如何調整方針，適應傳統媒體衰落、自媒體崛起的新常態吧？--MilkyDefer 2024年12月28日 (六) 02:55 (UTC)

由於被管理員認定為擾亂，本框內討論文字已關閉，相關文字不再存檔。

如有異議，請諮詢互助客棧或其他管理員。執行人：Sanmosa _蘭絮 2024年12月29日 (日) 05:45 (UTC)

RSN其實已有基於現有方針指引的個別自媒體相關討論，如立場新聞及眾新聞，暫時未見需要調整方針。--唔好阻住我愛國（留言） 2024年12月28日 (六) 03:04 (UTC)

這兩個什麼時候成為自媒體了？你可真是天天都在顛覆我的認知啊。--MilkyDefer 2024年12月28日 (六) 03:19 (UTC)

如我在DYKC那邊說的，他已經不是第一次這樣胡言亂語了，我記得上次他還因為胡言亂語而被封鎖了在WP空間的編輯一年（對，就是我在上面說的「不當行徑」）。Sanmosa _蘭絮 2024年12月28日 (六) 04:42 (UTC)

難度太大，不太可能就「自媒體」達成共識。傳統媒體的新媒體渠道以及部分傳統媒體都存在爭議和不少問題。--YFdyh000（留言） 2024年12月28日 (六) 09:13 (UTC)

即便賬號認證為傳統媒體，但難以確認是否由該媒體直接運營，或是委託其他第三方運營；難以確認賬號操作者身份及職務權限；難以確認發布時的內容已經過該組織的審校。

根據平台特性，認證賬號也可能發布與新聞無關的其他內容（包括非原創），或轉發由其他賬號發布的內容。

再次表達一貫反對任何社交網站或自媒體成為可靠來源的立場。->>Vocal&Guitar->>_留言 2024年12月30日 (一) 03:44 (UTC)

這個確實是個問題，例如邱毅在其製作的自媒體節目中稱青鳥為台獨以及黃智賢在其製作的自媒體節目中對柯文哲進行有罪推定。而相關來源如果被認定為可靠來源說不定跟看自媒體發動戒嚴的尹錫悅一樣製造新的鬧劇。----甜甜圈認為2025年是台灣最惡臭和木毛的一年 2024年12月30日 (一) 04:26 (UTC)

就更別提傳統媒體的採編質量本身也在逐漸下降。（例如中國大陸的地方級媒體[3]以及台灣中時新聞網以及tvbs[4]。）----甜甜圈認為2025年是台灣最惡臭和木毛的一年 2024年12月30日 (一) 04:44 (UTC)

@YFdyh000。Sanmosa _蘭絮 2024年12月30日 (一) 08:57 (UTC)

用戶生成內容中，社交媒體設有帳戶認證制度有不同，可能要再深化，基本上反對；但影片分享網站，如被維基百科討論為可靠來源的媒體引用，即持開放態度--Abcet10（留言） 2024年12月30日 (一) 14:54 (UTC)

我不理解「持開放態度」的含義，請舉例。--YFdyh000（留言） 2024年12月30日 (一) 15:21 (UTC)

[5]如這影片，引用了Lee-Geun-young，這種情況我覺得可以討論--Abcet10（留言） 2024年12月30日 (一) 15:39 (UTC)

媒體採編的內容應該不算「通常都含有用戶生成內容」所指範圍，正如官方博客不是。--YFdyh000（留言） 2024年12月30日 (一) 15:48 (UTC)

噢，我表達的就是上述列子那種情況，原先是由用戶生成的，如有可靠來源的媒體引用，就可以討論；如官方博客除外，就當我沒說過--Abcet10（留言） 2024年12月30日 (一) 15:54 (UTC)

可否在標題置入繁體地區詞的簡體字／簡體地區詞的繁體字？

如題，除全部用字繁簡同體外，可否在條目標題（或需轉換地區詞的正文處）置入以簡體字書寫的繁體地區特有詞／以繁體字書寫的簡體地區特有詞，社群並保障此字形不被改變_{（除非此詞所指對象從標題中消失）}？有無需要顧及地區詞轉換？此類字形例如簡體「数位相机」、繁體「數字照相機」、簡體「三温暖」、繁體「鼠標」等。

若可置入並獲社群保障，即應還原“宿務”→“宿霧”、“马木留克”→“马穆鲁克”、“聖女的救濟”→“聖女的救贖”、“麥卡·門羅”→“麦卡·门罗”、“艾丽·高登”→“艾麗·高登”、“直線電動機”→“直线电动机”(直線摩打)等移動？

上列討論供參考各式具體情形及理據，並非指責或針對任何個例或個人。相信除甚少故意外，大多數是無意——例如多文化背景或熱衷非母文——或牽涉易名流轉等因素——例如驚天駭浪、國慶驚情、至愛梵高、消失的愛人等繁體地區暫譯／前譯名稱被新加坡等簡體地區採用，後被繁體地區捨棄。--— Gohan 2024年12月28日 (六) 09:34 (UTC)

原則上不支持在標題置入繁體地區詞的簡體字或簡體地區詞的繁體字，這對轉換機制不友好。神秘悟飯在第三自然段所説的符合實情。Sanmosa _蘭絮 2024年12月28日 (六) 09:39 (UTC)

不論是標題還是正文，都應儘量避免使用繁/簡體書寫簡/繁體特有詞。這類標題應當移動至任一使用對應的繁/簡體書寫的地區詞。由於移動前的標題寫法不合理，故我認為標題「選擇權」應交予移動者，移動者可任一選擇某一地的地區詞並用繁/簡體書寫，且根據移動者的選擇而「先到先得」（當然，我個人在做這類移動時，通常是不動地區詞，只動繁簡，這樣是改動最小的）。--自由雨日🌧️❄️ 2024年12月28日 (六) 09:48 (UTC)

支持這個見解。Sanmosa _蘭絮 2024年12月28日 (六) 10:22 (UTC)

若有共識，可望增修有關指引，惟措辭實在犯難。「簡體地區特有詞」／「繁體地區特有詞」爲便社群記憶，可寫於正文；但是易有爭議或被新人誤讀，難免附帶腳註加以界定。然而，迄今尚無方針、指引或説明明確（普適地）界定何爲「地區詞」或（在語言層面）如何構成「地區詞」，「地區詞」或許是維基社群最難説明的非技術概念，説明「簡體地區特有詞」／「繁體地區特有詞」更是難上加難。【中國大陸、馬來西亞或新加坡所用而香港、澳門及臺灣皆相對罕有，而理應納入地區詞轉換的語詞】／【香港、澳門或臺灣所用而中國大陸、馬來西亞及新加坡皆相對罕有，而理應納入地區詞轉換的語詞】是在下目前所能想到的較優定義，供以集思廣益。（註，因爲簡體中文不屬於馬來西亞官方文字，繁體中文在馬來西亞也不算不通用、不常用或不主流，所以如何界定「簡體地區」都似不妥，乾脆一並省去）另外，捷徑命名如何是好？是「簡詞繁寫」、「繁詞簡寫」，還是「簡詞繁體」、「繁詞簡體」，抑或是前列四個都建？是否需要另建「簡×簡×」、「繁×繁×」？--— Gohan 2024年12月31日 (二) 10:19 (UTC)

(＋)支持這個定義。另外補充一點我個人對「地區詞」的見解。我通常會在滿足兩個條件的情況下將某詞視作（非該地的）地區詞：一、未在該地大部分語文詞典收錄（或有收錄但明確標註是另一地用語）；二、在表示該概念（假設有A、B兩詞）時A詞使用率低於5%（參考統計上判斷顯著性常用的p值）。否則不視作地區詞。例如「的士」一詞，雖在中國大陸遠不如「出租車」常用但它在《現代漢語詞典》收錄且未標註「<方>」（即該詞典認為「的士」屬於普通話用語），我即認為「的士」並非香港特有詞，而是在大陸簡體模式也可使用，不必轉換成「出租車」。（但上述情況不包括學科術語，學科術語不僅要考慮使用率，還要考慮到學者對於何者更「合理」的意見。）當然這僅是我個人對「地區詞」的看法，沒必要寫入指引。指引直接簡潔地定義為「中國大陸、馬來西亞或新加坡所用而香港、澳門及台灣皆相對罕有，而理應納入地區詞轉換的語詞」即可。捷徑命名我認為可以建立所有這些重定向，多幾個重定向並不會有什麼害處。--自由雨日🌧️❄️ 2024年12月31日 (二) 10:44 (UTC)

承接以上共識，擬在Wikipedia:地區詞處理#注意事項增補以下一節為#注意事項的第一節。由於各地名稱框等不作地區詞轉換之處規限繁簡不具效用，在這些地方以繁體字書寫一簡對多繁的字反而往往能夠避免繁簡轉換錯誤（例如慾望城市），故豁免不作地區詞轉換之處。

現行條文 注意事項 （新增一節）

提議條文 注意事項 繁簡得當 除「各地名稱」介紹等理應不作地區詞轉換之處外，不應以簡體字書寫繁體地區特有詞，亦不應以繁體字書寫簡體地區特有詞，以便地區詞轉換。若有此等不當詞形，宜予修正。

並為釋除可能的疑慮，擬對Wikipedia:破壞#繁簡、異體及地區用詞破壞修訂如下：

現行條文 無正當理由下手動將頁面原始碼中的繁簡或異體字替換為另一變體，或僅為變更繁簡、異體或地區詞而移動標題頁面標題；或刪除不同地區的翻譯名稱或用詞，僅保留特定地區之用詞。 中文維基百科配置了繁簡及地區詞轉換系統，容許讀者在不同變體環境下閱讀內容，因此不應手動替換繁簡、異體或地區詞，而是添加轉換標籤容許字詞在不同變體下自動轉換。技術性修復錯誤轉換或繁簡混雜造成的連結錯誤而手動轉換異體及地區詞，則不構成破壞。

提議條文 無正當理由下手動將頁面原始碼中的繁簡或異體字替換為另一變體，或僅為變更繁簡、異體或繁簡得當的地區詞而移動標題頁面標題；或刪除不同地區的翻譯名稱或用詞，僅保留特定地區之用詞。 中文維基百科配置了繁簡及地區詞轉換系統，容許讀者在不同變體環境下閱讀內容，因此不應手動替換繁簡、異體或繁簡得當的地區詞，而是添加轉換標籤容許字詞在不同變體下自動轉換。修正繁簡不當的地區詞、技術性修復錯誤轉換或繁簡混雜造成的連結錯誤而手動轉換異體及地區詞，則不構成破壞。

若對Wikipedia:地區詞處理#注意事項的修訂不通過，「繁簡得當的」、「繁簡不當的地區詞」二條內鏈則改鏈至H:AC#編輯一般文章時的注意事項。 — Gohan 2025年1月2日 (四) 10:12 (UTC)

@神秘悟饭：根據WP:方針與指引#方針及指引的用詞，「宜予修正」不是合適的條文用詞，而考慮到此處的討論共識傾向於禁止置入繁體地區詞的簡體字／簡體地區詞的繁體字，「宜」字應以表達強制滿足的條件的「須」字代替。除此以外，總體上支持此版提案。Sanmosa _蘭絮 2025年1月2日 (四) 10:49 (UTC)

此外，為確保相關規定可直接規制條目命名，WP:命名常規#技術要求應嵌入預定增補於WP:地區詞處理#注意事項的章節，嵌入位置為「繁簡統一」與「不要使用條目的名稱來表示條目的層次」之間。Sanmosa _蘭絮 2025年1月2日 (四) 11:08 (UTC)

現行用戶頁指引條文規定的定義問題

原標題為：請求澄清有關快速刪除方針O1款的條文

有鑒於現行用戶頁指引（2024年11月27日通過）規定「標題以User（用戶）和User talk（用戶討論）命名空間開頭的頁面都被視為用戶頁面」，而現行快速刪除方針O1款則規定「用戶請求刪除自己的用戶頁或其子頁面」，並為「用戶頁」一詞加上了現行用戶頁指引的連結，而這使得先前將2024年11月27日前不被視為「用戶頁」的用戶討論頁排除適用快速刪除方針O1款的結論可被認為已自動失效。因此，現行快速刪除方針O1款是否應比照現行用戶頁指引的規定同時適用於2024年11月27日前不被視為「用戶頁」的用戶討論頁？Sanmosa _蘭絮 2024年12月28日 (六) 10:40 (UTC)

用戶討論頁通常不應刪除吧思考... ——自由雨日🌧️❄️ 2024年12月28日 (六) 11:07 (UTC)

是的，我自己也是這樣認為的，因此我感覺「標題以User（用戶）和User talk（用戶討論）命名空間開頭的頁面都被視為用戶頁面」這個規定的設置可能有些問題，尤其是在同一指引下方又有區別對待用戶頁與用戶討論頁的條文的情況下。Sanmosa _蘭絮 2024年12月28日 (六) 12:05 (UTC)

將指引的標題改為《WP:用戶空間》（且為防止歧義，不使用「用戶頁面」一詞）？--自由雨日🌧️❄️ 2024年12月28日 (六) 12:14 (UTC)

然而這就會把「用戶頁」與「用戶頁面」的混淆轉變為「用戶命名空間」與「用戶空間」的混淆，這似乎並沒有解決到問題……但至少這裏應該能確定現行規定的設置是有問題的，對吧？Sanmosa _蘭絮 2024年12月28日 (六) 14:09 (UTC)

「用戶命名空間」和「用戶空間」好像就是同義詞？另外我怎麼一直感覺你提這個討論的主要用意是在說明後半句 ——自由雨日🌧️❄️ 2024年12月28日 (六) 14:28 (UTC)

（前）我以為你是打算把「標題以User（用戶）和User talk（用戶討論）命名空間開頭的頁面都被視為用戶頁面」裏的「用戶頁面」也一同改成「用戶空間」，這情況下「用戶命名空間」與「用戶空間」會是兩個distinct的概念。（後）靈感來源。當然，如果社羣不認為現行用戶頁指引的規定的設定有問題的話，我可以轉為主張現行快速刪除方針O1款的規定是有問題的（而且這才是我一開始的想法，雖然我想了一下以後感覺好像不太好，然後就放棄了），好歹我也算是識別了一個問題。Sanmosa _蘭絮 2024年12月28日 (六) 14:44 (UTC)

啊，我本來其實就是想把那句話中的「用戶頁面」改成「用戶空間」……以及我發現前面我搞錯了（沒仔細看WP:命名空間的說明 囧rz……）原來用戶命名空間是只包括「U:」不包括「UT:」的。這樣來看「用戶空間」和「用戶命名空間」概念不同，確實有混淆問題……（而且應該是任何情況都distinct吧？怎麼沒指出我明顯的錯誤（）另外我仔細讀了讀又發現O1好像沒有問題？O1說的是「用戶頁」而不是「用戶頁面」，那按現行用戶頁指引也是不包括「UT:」的；而且加的好像不是「WP:用戶頁」的鏈接，而是「help:用戶頁」（哪怕加的是現行用戶頁鏈接，用詞上並非「用戶頁面」，也並不包括「UT:」）？--自由雨日🌧️❄️ 2024年12月28日 (六) 15:11 (UTC)

我的理解上「用戶頁」與「用戶頁面」兩者是等義的。連結的問題確實是我看錯了，然而這不影響我的總論。Sanmosa _蘭絮 2024年12月28日 (六) 15:13 (UTC)

這不就類似於我上面的錯誤「我的理解上『用戶命名空間=用戶空間』」了嗎？《WP:用戶頁》指引明確寫了「用户页面 = 用户空间 = { :U(用户页) , :UT(用户讨论页) }」。--自由雨日🌧️❄️ 2024年12月28日 (六) 15:19 (UTC)

啊，還有這回事？那這種設定也是有問題的，因為粵語母語地區較常用單音節詞（比如比起「頁面」，粵語母語地區更傾向使用「頁」），在閲讀書面語時粵語母語地區的讀者會自動把不常用的多音節詞自動簡化為常用的單音節詞，這使得粵語母語地區的讀者無法理解「（用戶）頁」與「（用戶）頁面」兩者如何可以合理地不等義。Sanmosa _蘭絮 2024年12月28日 (六) 15:26 (UTC)

確定是粵語的關係嗎……因為我也認為「用戶頁面」是非常奇怪的表述，會傾向直接理解為「用戶頁」。那看來就得把所有「用戶頁面」一律用「用戶空間」替代了，至於衍生的「和『用戶命名空間』混淆」的問題，應該並不如「頁/頁面」混淆問題更大。--自由雨日🌧️❄️ 2024年12月28日 (六) 15:31 (UTC)

剛剛才發現VPO的討論那邊的用戶也同樣地將「用戶頁」與「用戶頁面」兩者視為同義詞了，看來這也不只是粵語母語地區讀者的問題啊。如果可以的話，我還是希望完全杜絕混淆問題。Sanmosa _蘭絮 2024年12月28日 (六) 15:32 (UTC)

唉，的確會有混淆的潛在問題...--薏仁將🍀 2024年12月29日 (日) 01:43 (UTC)

考慮到現行用戶頁指引條文規定的定義存在定義不清與自相矛盾的問題，為盡可能減少對現條文與規則實際執行的影響，現提議如下：

現行條文 用戶頁是維基百科提供的頁面，是用於組織計劃參與者（即維基人）在維基百科上所做的工作以及與其他維基人交流的頁面。用戶頁主要用於人際討論、通知、測試和草稿（參見沙盒），以及（如果需要）有限的自傳和個人內容。標題以User（用戶）和User talk（用戶討論）命名空間開頭的頁面都被視為用戶頁面。

提議條文 用戶頁是維基百科提供的頁面，是用於組織計劃參與者（即維基人）在維基百科上所做的工作以及與其他維基人交流的頁面。用戶頁主要用於人際討論、通知、測試和草稿（參見沙盒），以及（如果需要）有限的自傳和個人內容。標題以User（用戶）和User talk（用戶討論）命名空間開頭的頁面都被視為「用戶自治空間」的一部分。

以上。這裏希望通過定義一個新的術語「用戶自治空間」來區別「用戶頁（面）」與「用戶命名空間」，此處「自治」指「autonomous」，代表用戶對其「用戶自治空間」內的頁面有較高自由度的處置權，但該處置權並非絕對。此外，同指引內其他提及「用戶頁（面）」的地方也需要探討是否需要改為「用戶自治空間」。Sanmosa _蘭絮 2024年12月29日 (日) 04:02 (UTC)

至少可以做個區分，而不會讓用戶感到困惑。--薏仁將🍀 2024年12月29日 (日) 04:46 (UTC)

現行條文 用戶子頁面 您的用戶子頁面是在User:Example/TestPage或者User talk:Example/TestPage的頁面。用戶空間中的子頁面可用於存儲沙盒、有關維基百科的論述以及維基百科條目的草稿等。您可以自行創建子頁面。 用戶空間 您的用戶空間（或稱用戶頁面）是指上面的合集。即使您沒有這些頁面的所有權，但您可以根據自己的意願自定義管理頁面，只要您這樣做是合理的並且符合這些準則即可。

提議條文 用戶子頁面 您的用戶子頁面是在User:Example/TestPage的頁面。用戶頁的子頁面可用於存儲沙盒、有關維基百科的論述以及維基百科條目的草稿等。您可以自行創建子頁面。 用戶討論頁子頁面／用戶子頁面討論頁 您的用戶討論頁子頁面與用戶子頁面討論頁均在User talk:Example/TestPage的頁面。用戶討論頁子頁面用於存檔用戶討論頁上的討論串，而用戶子頁面討論頁則用於討論有關用戶子頁面的內容。有關前者的更多信息，請參閱Help:如何將討論頁存檔；有關後者的更多信息，請參閱Wikipedia:討論頁。與用戶子頁面一樣，您也可以自行創建用戶討論頁子頁面與用戶子頁面討論頁。 用戶自治空間 您的用戶自治空間是指上面的合集。即使您沒有這些頁面的所有權，但您可以根據自己的意願自定義管理頁面，只要您這樣做是合理的並且符合這些準則即可。

上方為補充修訂。Sanmosa _蘭絮 2024年12月29日 (日) 14:36 (UTC)

此外，用戶頁指引中自「用戶空間提供的選項」章節（含章節標題自身）起的所有「用戶空間」均應替換為「用戶自治空間」。Sanmosa _蘭絮 2024年12月29日 (日) 14:41 (UTC)

關於請辭問題

根據Special:Diff/85486055，User:Munford雖然已經在行政員佈告版表態請辭，但是尚未於元維基作正式申請，這看來僅符合Wikipedia:管理員的離任中「如果您是管理人員，基於某些原因想要離任並取消管理人員權限，請在行政員布告板提出，並到元維基上的m:Requests_for_permissions#Removal of access進行正式申請。」的要求的一半。在這種情況下，是否只能讓其前往元維基申請？或是說有沒有可能修改條文，讓行政員直接前往元維基提出？希望得到各位的意見。謝謝。--AT⊿⁴⁶ 2024年12月30日 (一) 06:35 (UTC)

（Wikipedia:管理員的離任）將相關聲明轉發到meta上。他自己說提請的，到時反悔就怪不得人。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年12月30日 (一) 07:36 (UTC)

類似的，本地罷免之後，也是通報到meta並附上鏈接，讓meta處理。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年12月30日 (一) 07:37 (UTC)

（meta:Steward_requests/Permissions#Removal_of_access），如果除權類見這。應該本人過去申請的。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年12月30日 (一) 07:39 (UTC)

其實我覺得請他人代為轉交也是可行的？當然這得要先有明確授權。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月31日 (二) 10:06 (UTC)

緊急修正快速刪除O1款

鑑於#現行用戶頁指引條文規定的定義問題，我要求現行O1條款緊急追加一句「僅適用於用戶（User）命名空間」。由於未實際更動方針文本，我將在24小時後執行。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月31日 (二) 13:29 (UTC)

其實不追加也無所謂？因為現行指引和修訂指引都是「用戶頁」=用戶（U:）命名空間。 ——自由雨日🌧️❄️ 2024年12月31日 (二) 13:37 (UTC)

那麼用戶討論頁存檔呢？--千村狐兔（留言） 2024年12月31日 (二) 13:38 (UTC)

一直是不行的，Delete模板調用的數據（Module:Delete/data#L-271）寫明O1需要User空間。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月31日 (二) 13:58 (UTC)

WP:RELIST

WP:RELIST要試行多久？新的一年，該決定要正式立為指引或者停止試行了吧。不然「永久試行」先例一開，以後議案都不用正式通過，全部掛試行就能一直上路，豈有此理？請討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 09:34 (UTC)

考慮到此機制已成為既成事實，建議直接確立為正式指引。Sanmosa _蘭絮 2025年1月1日 (三) 10:24 (UTC)

relist有個小問題就是（體感上）很多討論會拖滿一個月但是後兩周也是無人回復，特別是一堆關注度提報在那裡疊疊樂，頭都大了。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2025年1月1日 (三) 11:22 (UTC)

 吐槽：Wikipedia:頁面存廢討論/記錄目前太長了，打開困難，「積壓討論」名存實亡。以及舊有討論的幾次跳轉有點麻煩。--YFdyh000（留言） 2025年1月1日 (三) 11:51 (UTC)

沒錯，希望可以推薦個小工具跳轉到最新的討論區 Stang^★ 2025年1月2日 (四) 12:42 (UTC)

其實看起來成效不算太差，(＋)傾向支持定為正式指引。--冥王歐西里斯（留言） 2025年1月1日 (三) 12:15 (UTC)

用着沒什麼問題，(＋)支持轉正為正式指引。--—— 紅渡廚（留言・貢獻） 2025年1月2日 (四) 09:26 (UTC)

(＋)支持，過了很長一段時間也沒什麼問題。Пусть от победы☆к победе ведёт! 2025年1月2日 (四) 11:57 (UTC)

(＋)支持，沒什麼問題。--Haohaoh4（留言） 2025年1月2日 (四) 13:38 (UTC)

提議將WP:關注度改名

WP:關注度施行許久，但近期本人注意到有許多新用戶或其餘人士會望文生義，將該方針指引名稱「關注度」望文生義理解為類似「觸及度」或「點擊量」的東西，在實際工作中造成極大不便。現新開議題，共議新名。

介於該方針指引內容與特殊性，本人在站外同幾位用戶討論後，目前有幾個方案：

1. 模仿日文維基百科的「WP:特筆性」（值得特別下筆寫作的內容）
2. WP:收錄標準
3. 收錄價值
4. 收錄指引
5. 收錄標準指引

2025年1月2日 (四) 08:49 (UTC)補充劃線文字：

1. 「收錄標準專題指引」（以專題指引形式呈現，下屬各指引獨立成條
2. 可寫性
3. 獨立成條標準

目前包括shizhao君與其餘維基人另表示，收錄標準一詞會因為範圍過廣致使需要收錄包括NOT等在內更多原有指引，問題在於原關注度只是收錄標準的一部分，有一解決方案是將該指引以專題形式表現，以「收錄標準專題指引」為名，下列「通用收錄標準指引」等。該方案優點在於除現有Notability指引外亦可將NOT與侵權指引等包含在內，亦滿足獨立成條性質。

我另外想說的是，前一次討論拘泥於「價值」「標準」「指引」而未取得共識，希望今次討論可以不要介意這些小問題，現在討論已經取得基本改名共識，倘若就此放棄未免過於可惜。「收錄價值」與「收錄標準」一詞因為過於模糊不清故此我(－)反對使用，至於「指引」與否倒是無所謂，因為就算成為維基百科方針指引也未必需要在名稱後面加註相關名詞。我會(＋)傾向支持使用「特筆性」與「收錄指引」。各位也可以讀一下維基百科:既非關注，也非度作為參考。 --Talimu0518（留言） 2025年1月1日 (三) 11:05 (UTC)

先前討論：維基百科:集中討論/關注度指引改名事宜（2023年1月） ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2025年1月1日 (三) 11:09 (UTC)

傾向「收錄標準」，「特筆性」太不符合現代漢語習慣。--自由雨日🌧️❄️ 2025年1月1日 (三) 11:09 (UTC)

故此本人有特別註明特筆性來自日文維基百科，倒不如說，正是因為不符合現代漢語習慣，所以讓人看見了會想點進去了解而不是掃一眼就望文生義。

現在我在AFC審核草稿期間，不知道遇見多少次望文生義認為關注度=點擊次數或者其他的，正因為如此所以才要推動改名。--Talimu0518（留言） 2025年1月1日 (三) 11:21 (UTC)

我之前也意識到了「難以理解」恰恰可能具有某種優勢，不過我仍然不太贊成為了這種優勢而使用不合現代漢語語感的日文漢字詞。--自由雨日🌧️❄️ 2025年1月1日 (三) 12:17 (UTC)

我覺得可以先列為候選名稱，慢慢來談要不要用比較好。--Talimu0518（留言） 2025年1月1日 (三) 12:21 (UTC)

@Peacearth、自由雨日、SickManWP、水餃喵、Iming、Sanmosa、魔琴、Ericliu1912、Yfdyh000、AT、SunAfterRain、MilkyDefer、Hotaru Natsumi、ATannedBurger、FradonStar、MykolaHK、Nishino Asuka、Allervous、ZhaoFJx、WenChuanHighway、Yumeto、ElectronicGhost、Air7538、ASid、Jonathan5566、神秘悟飯、S8321414、Ghren、Stang、SCP-2000、LuciferianThomas、Shizhao、A2569875、Shyangs、Leiem、Cwek、Wong128hk、PexEric、Dewadipper、Bluedeck、KirkLU、Borschts、Kenny023、桐生ここ、Didaictor、HualinXMN、Psycho CSL、BureibuNeko、Jane9306、ATannedBurger：--Talimu0518（留言） 2025年1月1日 (三) 11:18 (UTC)

另復知原提案發起人@UjuiUjuMandan：。--Talimu0518（留言） 2025年1月1日 (三) 11:22 (UTC)

建議把原討論的人都ping來 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2025年1月1日 (三) 11:34 (UTC)

好，等我一下。--Talimu0518（留言） 2025年1月1日 (三) 12:03 (UTC)

@井上麻雀喵、0xDeadbeef、花開夜、31cc、阿南之人、Manchiu：--Talimu0518（留言） 2025年1月1日 (三) 13:13 (UTC)

不要擠牙膏式的ping法好嗎...--SunAfterRain 2025年1月1日 (三) 13:19 (UTC)

不要忘記ping一次最多只能50人。我重寫的ping模組我可清楚得很。--MilkyDefer 2025年1月1日 (三) 13:34 (UTC)

@MilkyDefer：我吐槽的原因是他用10+1+1+1+1+1+1+...這種ping法--SunAfterRain 2025年1月1日 (三) 14:14 (UTC)

@August0422：--Talimu0518（留言） 2025年1月1日 (三) 13:21 (UTC)

(＋)支持用「收錄標準」。--Allervous迷い星のように叫ぼう 2025年1月1日 (三) 23:24 (UTC)

直接修改留言是Ping不到的 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2025年1月2日 (四) 06:51 (UTC)

(＋)支持。見論述wp:既非關注，也非度。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2025年1月2日 (四) 14:50 (UTC)

(＋)支持。「關注度」早該改了，可以根據Wikipedia:集中討論/關注度指引改名事宜進一步討論，得到新的共識。--Hexexie 2025年1月1日 (三) 11:19 (UTC)

依據歷史討論紀錄，那時候還是糾結在「收錄指引」還是「收錄標準指引」還是「收錄標準」，建議以投票調查解決。臺灣杉在此發言 (會客室) 2025年1月1日 (三) 11:39 (UTC)

(＋)支持：社群苦「關注度」久矣--人間百態,獨尊變態(討論)(簽名) 2025年1月1日 (三) 11:26 (UTC)

(＋)支持更改，多年來令許多新手摸不清相關概念。--維基病夫_{❤️邊緣人小組·簽到·🕯Jimmy Carter 1924~2024} 2025年1月1日 (三) 11:30 (UTC)

(＋)支持，「關注度」之名實在難懂，改成「收錄標準」就好很多，另外也見到有人提案「收錄價值」一名。-- ElectronicGhost｜👻 2025年1月1日 (三) 11:43 (UTC)

價值也不行，Notability是一條邊界，既不是程度也不是價值--SunAfterRain 2025年1月1日 (三) 13:17 (UTC)

維基百科:既非關注，也非度。--Talimu0518（留言） 2025年1月1日 (三) 14:45 (UTC)

(＋)支持。之前無共識實在是太可惜了，希望這次可以解決這一長期問題。--碟之舞📀💿 2025年1月1日 (三) 11:44 (UTC)

(＋)支持。同前次討論意見。--在下荷花，請多指教（歡迎簽到） 2025年1月1日 (三) 11:56 (UTC)

(＋)支持改名，個人傾向於使用「收錄標準」。—FradonStar祝各位2025年諸事順遂！ 2025年1月1日 (三) 11:57 (UTC)

(＋)支持改名為「知名度」，「Notability」在中文的意思是「知名度」，以音樂條目為例，知名度可用於該專輯/歌曲有沒有登上公認排行榜或入圍重要性高的頒獎典禮獎項。--Sinsyuan✍️5️⃣0️⃣8️⃣ 2025年1月1日 (三) 12:03 (UTC)

(－)強烈反對：我在AFC計畫審草稿，見過各種各樣的以藝人為主題寫成的草稿，現在用「關注度」都有一大堆人跑來用各種各樣的內容農場來源跟點擊量問都這樣了為什麼還不算有關注，您要是真推動用知名度，到時候我的工作量就更大了⋯⋯

況且您這個方案跟現在的「關注度」一樣都是原創翻譯，我不認為換成這個方案會讓現在的情況有什麼改變。--Talimu0518（留言） 2025年1月1日 (三) 12:16 (UTC)

(－)強烈反對：「知名度」帶來的負面影響甚至可能比「關注度」還要更大。--自由雨日🌧️❄️ 2025年1月1日 (三) 12:17 (UTC)

另外我不理解Sinsyuan為什麼留言時經常多縮進一（幾）格（我已經調整）。 ——自由雨日🌧️❄️ 2025年1月1日 (三) 12:19 (UTC)

關注度根本不是度，不要混淆。--SunAfterRain 2025年1月1日 (三) 13:15 (UTC)

多倫多方臉也是一個「知名度」相當高的人物，畢竟他的粉絲數量很多。請問您覺得他適合被寫進維基百科？--Nishino⭐Asuka 2025年1月1日 (三) 18:30 (UTC)

(＋)支持改名。 --窩法乙烷 兒法夢碎 2025年1月1日 (三) 12:11 (UTC)

(＋)支持改名，傾向「收錄標準」，但上面有人提到的「收錄價值」也不錯。--冥王歐西里斯（留言） 2025年1月1日 (三) 12:14 (UTC)

(！)意見2種都可以，但是如果用收錄標準，且明確定義標準的內容，有助於操作及判斷。--Rastinition（留言） 2025年1月1日 (三) 12:18 (UTC)

贊成Rastinition之意見。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2025年1月1日 (三) 17:10 (UTC)

(＋)支持「收錄標準」 自由雨日🌧️❄️ 2025年1月1日 (三) 12:29 (UTC)

考慮到此問題，我亦支持命名為「獨立成條標準」。--自由雨日🌧️❄️ 2025年1月2日 (四) 08:47 (UTC)

等我加一下。--Talimu0518（留言） 2025年1月2日 (四) 08:48 (UTC)

(＋)支持：「notability」一詞如果形容的是某件事物引起了人們的足夠關注和討論（也就是足夠引人注目）的話，那麼用「關注度」這個詞就是可以的。但在維基百科當中，一個條目是否值得被收錄看的不只是這個條目描述的主體的受關注的程度，還看的是像被可靠來源詳細介紹這樣的客觀標準，多倫多方臉就是個典型的例子。雖然他在中文互聯網社群中相當知名，「受關注的程度」也比較高。但能夠查到的詳細地介紹他的可靠來源並不是特別多（我唯一能查到的就是美國之音的這個來源，不過我看這個來源的性質有點類似於個人訪談類的節目？如果是這樣的話，那它就屬於第一手來源）。所以這個人是否符合維基百科的「收錄條件」（或者就如同塔里木君所說的「收錄標準」）就是值得懷疑的了。所以基於我的上述觀點，我支持這一更名。--Nishino⭐Asuka 2025年1月1日 (三) 12:30 (UTC)

介於此前曾有過討論時未能就「收錄指引」「收錄標準指引」「收錄標準」取得共識之情況，這次本人僅列舉收錄標準一詞。但如果以我本人來講，我比較喜歡「特筆性」一詞。

「特筆性」來源於日文維基百科，同中文站現行的「WP:關注度」一樣。這個詞的特點在於，有一定程度的特殊性，不符合現代漢語習慣。但我在回覆自由雨日的時候也有提到，夠特殊、夠另類、不符合現行習慣的這個詞可以有效防止望文生義現象繼續產生。假如我們採用這個詞彙，那麼讀者或不熟悉情況的編者在看見時必然會被這個詞所吸引，從而點入該頁面閱讀相關內容，從而杜絕望文生義情況。

現在情況是，中文站內為該方針指引使用「關注度」一詞，我在AFC計畫審核草稿期間不止一次遇到過，有編者或讀者在自己的草稿被拒絕後前來提問：

「為什麼我草稿的主題不符合標準？我明明已經列舉了[各種可靠或不可靠內容]作為參考來源，更何況點擊數已經[數字]了，怎麼可能不符合標準？！你們維基百科太爛了！」

上述我列舉的就是其中一種常見狀況。這種情況大概率是這位用戶望文生義，從而介於自己對方針的錯誤認知做出的判斷。我遇見的大部分情況都可以總結為認為「關注度=點擊數/瀏覽量/轉載數/刊登文章數」等等，現行方案早就不適合編輯需求，故此我提請改名。--Talimu0518（留言） 2025年1月1日 (三) 12:48 (UTC)

「特筆性」一詞根據下文地球君的解釋，就是「足以特別（或值得特別）動筆來寫條目的」性質。不過這裡的「特別」到底指的是哪方面「特別」？哪裡「特別」？還是需要專門來解釋一下，不然容易被某些不明白所以然的新手所曲解。所以我覺得與其將該指引的名稱改為「特筆性」，還不如改成更加貼切和易懂的「顯著性」。--Nishino⭐Asuka 2025年1月1日 (三) 18:27 (UTC)

考慮到下文Shizhao的觀點，既然「收錄標準」或「收錄條件」定義太過寬泛，其不僅包括「Notability」，還包括不能侵權、維基百科不是什麼等等因素。那麼將該指引當前的名稱「關注度」改成「顯著性」可不可以？「Notability」的中文含義大致是「值得注意的（或顯著的）性質」，「顯著性」在這裡的意思就是這篇條目「顯著地」被可靠或獨立的來源進行有效的介紹的性質。其他維基人對此還有什麼疑問嗎？--Nishino⭐Asuka 2025年1月2日 (四) 10:37 (UTC)

顯著性聽着也很有道理——敬頌冬綏 ZhaoFJx_(論•簽) 2025年1月2日 (四) 12:48 (UTC)

這裡 說明一下，我提出的「收錄價值」應該是「notability」的翻譯。方針的改名問題我保持(＝)中立。--ItMarki^探討人生 2025年1月1日 (三) 12:31 (UTC)

價值也不行，Notability是一條邊界，既不是程度也不是價值--SunAfterRain 2025年1月1日 (三) 13:18 (UTC)

本人(＋)支持名稱變更且變更後名稱的前兩字是「收錄」，然而在「收錄」後跟進的詞語則值得斟酌，例如是偏向指導的「指引」，還是表明底綫的「原則」，抑或是說明性質的「標準」。

PS：粵維將 WP:Notability 稱作「收錄指引」，而韓維將其稱作「條目登載標準（문서 등재 기준）」。--Didaictor（留言） 2025年1月1日 (三) 13:04 (UTC)

與我兩年前的意見保持一致，傾向支持改為「收錄標準」。Sanmosa _蘭絮 2025年1月1日 (三) 13:13 (UTC)

兩年前的討論因為未能在標準指引中取得共識，故此未能成功推動改名。我希望這次不要拘泥於這種小問題，如果可以改變當然最好不過。「指引」一詞未必需要放在名稱中，維基百科的方針也並非每條都有寫上「XX方針」。--Talimu0518（留言） 2025年1月1日 (三) 13:16 (UTC)

(＋)支持，本人支持改為「收錄標準」--August0422_討論頁 2025年1月1日 (三) 13:25 (UTC)

(＋)支持改名至收錄標準。Пусть от победы☆к победе ведёт! 2025年1月1日 (三) 13:32 (UTC)

(！)意見：所以有無人告訴我上一次失敗的原因？ （PS如果這一次成功了，我可以寫一篇相關的論述） --MilkyDefer 2025年1月1日 (三) 13:38 (UTC)

暴論：集中討論導致的。--Talimu0518（留言） 2025年1月1日 (三) 13:43 (UTC)

認同改名為「收錄標準」。--~~Sid~~ 2025年1月1日 (三) 13:42 (UTC)

(＊)提醒@塔里木君，除非您有特殊情況，否煩請別ping我，謝謝。--花開夜（留言） 2025年1月1日 (三) 14:00 (UTC)

本人對先前發生的事件感到遺憾與抱歉，亦撤銷相關自我隔離禁制，惟站務事關重大，改名亦為必須，諸維基人均有參加討論之權利，故今次誠邀閣下前來參加相關討論，望君前嫌盡釋，共議方針。--Talimu0518（留言） 2025年1月2日 (四) 06:28 (UTC)

(＋)支持，這樣我們之後審核就不會這麼麻煩了--Kanshui0943（留言） 2025年1月1日 (三) 15:21 (UTC)

改成收錄標準或者收錄指引。--Alice_8585 音游如命（留言） 2025年1月1日 (三) 15:24 (UTC)

(！)意見「收錄範圍」一詞是否合適？——Huangsijun17（留言） 2025年1月1日 (三) 16:42 (UTC)

不合適，會寫成列表。--Talimu0518（留言） 2025年1月1日 (三) 16:43 (UTC)

(＋)支持「特筆性」或「收錄標準」，二者各有其優點。「特筆性」個人認為可理解為「足以特別動筆寫條目的性質」，且新手比較不會望文生義。「收錄標準」則是可以方便向新手介紹。-Peacearth（留言） 2025年1月1日 (三) 17:37 (UTC)

(＋)支持「收錄標準」。--PC2025年1月1日 (三) 18:25 (UTC)

(＋)支持 收錄標準就挺好的——敬頌冬綏 ZhaoFJx_(論•簽) 2025年1月1日 (三) 18:39 (UTC)

(＋)支持很有創造性的一個改變。--薀川｜公路 2025年1月1日 (三) 22:56 (UTC)

(＋)支持「收錄標準」。--Wolfch (留言) 2025年1月2日 (四) 00:27 (UTC)

如果WP:N的第一節可以足夠解釋「關注度」作為一個維基百科術語所產生的作用，那麼我不認為改或不改有很大的實際意義。所謂將「關注度」理解為「知名度」或「點擊量」等，只說明了他們在撰寫條目前可能沒有閱讀（或認真閱讀）過關注度指引，以及其他相關的可供查證方針、可靠來源指引等。想辦法讓他們有更大的機會可以在動筆之前先理解清楚維基百科的規則，比在這裡改名有意義得多。條目的受眾是所有讀者，術語的受眾是維基人和打算成為維基人的人，作為一個術語，我不認為「關注度」非常罪大惡極，比如在座的各位都能清楚理解「關注度」代表什麼意思，那沒有理由假定其他人不能接受。->>Vocal&Guitar->>_留言 2025年1月2日 (四) 02:19 (UTC)

問題在於關注度只是收錄標準的一部分，收錄標準還包括了不能侵權、維基百科不是什麼那一大堆--百無一用是書生 (☎) 2025年1月2日 (四) 02:32 (UTC)

「收錄准入標準」「收錄遴選標準」？——Huangsijun17（留言） 2025年1月2日 (四) 03:18 (UTC)

顯然是前者，收錄標準是一個門檻，而不是從眾多條目里選出什麼東西來符合標準，我覺得後者約等於在說關注度是「度」。--—FradonStar祝各位2025年諸事順遂！ 2025年1月2日 (四) 03:40 (UTC)

這個東西當然不是「度」，不過我想如果說可以的話應當從「收錄方針」或「收錄標準」中二選一。--Talimu0518（留言） 2025年1月2日 (四) 06:25 (UTC)

實在不行『撰錄標準』也是可行的。--薀川｜公路 2025年1月2日 (四) 03:50 (UTC)

有任何區別嗎…… ——自由雨日🌧️❄️ 2025年1月2日 (四) 07:15 (UTC)

@Shizhao：改叫「門檻」如何？倘若確實有範圍過廣的問題，那使用門檻一詞如何？既不會像收錄標準一樣範圍過廣，而又符合我們現行方針實際使用情況，畢竟確實是最基礎的門檻。--Talimu0518（留言） 2025年1月2日 (四) 06:36 (UTC)

有什麼區別？「門檻」就不包括NOT了？關鍵問題是「關注度」的核心語義是「獨立成條（的標準/門檻）」，只要沒點出這層含義，就沒法解決Shizhao說的問題。--自由雨日🌧️❄️ 2025年1月2日 (四) 06:44 (UTC)

目前本人有一個解決方案，即為將該指引寫成專題，然後其餘各notability指引再獨立成條。大專題名為「收錄指引專題」，其餘如通用收錄指引等再另寫，NOT這些可以收錄在內。--Talimu0518（留言） 2025年1月2日 (四) 06:49 (UTC)

迷惑，從沒聽過將方針/指引降為專題的。--自由雨日🌧️❄️ 2025年1月2日 (四) 06:52 (UTC)

可能本人解釋有誤，應為「專題指引」。--Talimu0518（留言） 2025年1月2日 (四) 06:58 (UTC)

而且你這麼做跟本次討論一點關係都沒有，仍然要解決「notability」一詞的翻譯問題。--自由雨日🌧️❄️ 2025年1月2日 (四) 06:53 (UTC)

剩餘包括不了的直接在原方針內註明不就好了麼⋯⋯--Talimu0518（留言） 2025年1月2日 (四) 07:00 (UTC)

啥？？我的意思是notability是一個重要的概念，必須有一個中文詞彙去對應。你這麼做並沒有解決翻譯問題，反而還造成notability指引被弱化成子指引。--自由雨日🌧️❄️ 2025年1月2日 (四) 07:02 (UTC)

本人先前已經提到「特筆性」一詞，下文的@WenChuanHighway：亦有「撰遴性」一詞供使用。--Talimu0518（留言） 2025年1月2日 (四) 07:05 (UTC)

那不就還是回到這詞的翻譯問題（即修改「關注度」一詞）了嗎……你提的「改成專題」完全和這一問題無關了。--自由雨日🌧️❄️ 2025年1月2日 (四) 07:11 (UTC)

個人偏向『撰遴性』這一說法，另外新人不看的問題可以由其導師在『新手主頁』說明，也就是說一定要利用上導師這個工具。--薀川｜公路 2025年1月2日 (四) 03:44 (UTC)

不必把一個作為維基百科基礎支撐性質的名詞描摹得這麼晦澀吧，讓導師來教什麼的是在同時增加導師和新用戶的時間成本，「收錄標準」這樣的詞彙是相當明了易懂的呀--—FradonStar祝各位2025年諸事順遂！ 2025年1月2日 (四) 03:54 (UTC)

前文本人已經講過，晦澀難懂也有避免新手想入非非直接望文生義的作用。雖說公路君的名稱也不錯，但目前共識還是傾向於使用更為簡潔易懂的「收錄標準」，二者皆有可行之處。--Talimu0518（留言） 2025年1月2日 (四) 06:12 (UTC)

我的意思是在『您的導師』一欄有導師歡迎語，在歡迎語中加入要求看方針即可--薀川｜公路 2025年1月2日 (四) 10:44 (UTC)

不認為新手一定會看那邊的東西。倘若假定他們真的會看，也許我們現在就沒那麼多工作量了。--Talimu0518（留言） 2025年1月2日 (四) 11:25 (UTC)

(－)強烈反對:「關注度」一詞本就屬於中文站內早前自行創造出的原創翻譯詞彙，況且現在你也知道不會有太多人去讀並且理解不了這個詞的意思。非常遺憾的，維基百科用戶來到這裡是為了編輯貢獻，而不是充當他人的教師，我們也沒有很多時間去教會他們。如果閣下願意，那就請你自己去教吧。並非罪大惡極才要被改掉，也沒有人說「關注度」這個詞罪大惡極。

另外，你只是自己覺得在座的各位都理解關注度是什麼意思，不要把維基人都想成接受過良好教育並且具備理解溝通能力的人。我對閣下的詭辯言論表示遺憾。--Talimu0518（留言） 2025年1月2日 (四) 06:21 (UTC)

如果今天的名字是什麼諾塔比利性，本身名字沒有奇怪的含意，那我認同你的說法，不需要去改；但今天的關注度字面上的意思關注程度根本不是Notability。--SunAfterRain 2025年1月2日 (四) 07:31 (UTC)

雖然不反對修改為收入錄標準，但是這個名稱之前求聞百科就用過。----甜甜圈認為2025年是台灣最惡臭和木毛的一年 2025年1月2日 (四) 04:12 (UTC)

方臘用過「永樂」年號並不妨礙朱棣選擇使用「永樂」年號。Sanmosa _蘭絮 2025年1月2日 (四) 04:40 (UTC)

提醒一下，是「收錄標準」，另外現在維基新聞那邊用於討論站務的頁面名叫「茶館」，與求聞百科相同，既然已有先例，我不認為這有什麼問題。--Talimu0518（留言） 2025年1月2日 (四) 06:32 (UTC)

求聞是求聞，維基是維基，只要是對維基好的東西就當然可以用，和求聞沒有任何關係。求聞都說了要把維基好的一面學習過去，我希望維基人不要看到是求聞的東西就唯恐避之而不及。--—FradonStar祝各位2025年諸事順遂！ 2025年1月2日 (四) 06:38 (UTC)

這不重要吧？--碟之舞📀💿 2025年1月2日 (四) 08:38 (UTC)

「收錄標準」一詞在現行WP:關注度原文裡面本來就有，跟其它網站有啥關係。--Haohaoh4（留言） 2025年1月2日 (四) 08:41 (UTC)

確實是沒考慮到站內條目，

中有提及「收錄標準」一詞。只不過那個指引提及了關注度這個名稱存在問題。----甜甜圈認為2025年是台灣最惡臭和木毛的一年 2025年1月2日 (四) 09:40 (UTC)

(＋)支持關注度易造成誤解，而且「通用關注度指引」裡面本來原文就用了獨立條目的收錄標準如下這樣的字眼。兩個詞混用很容易讓人覺得「收錄標準」和「關注度」是兩個不同概念。具體用詞我覺得「收錄指引」更好一些，因為標題叫「指引」肯定能吸引新人進去看，同時既不像「關注度」這樣易望文生義，也不會像文言文那樣過於晦澀，容易讓人看不懂。而且「收錄標準」用詞聽起來包括的範圍過大，還是用指引表達要準確一些。如果要強調是「獨立條目」的收錄標準的話，獨立條目收錄指引？WP:可獨立收錄條目？--Haohaoh4（留言） 2025年1月2日 (四) 09:03 (UTC)

是「獨立成條」指引/標準，「獨立條目收錄指引/標準」依然具有「獨立條目內部內容收錄指引/標準」的語義，即Shizhao說的問題。 ——自由雨日🌧️❄️ 2025年1月2日 (四) 09:09 (UTC)

@Talimu0518：special:diff/85524182不要修改他人已經回復過的留言，若要修改，應表示出新增的留言並加上修改時間（五個波浪線簽名），否則構成歪曲討論。--自由雨日🌧️❄️ 2025年1月2日 (四) 07:01 (UTC)

(＋)支持收錄標準一詞。--Leiem（留言·簽名·維基調查） 2025年1月2日 (四) 09:12 (UTC)

(＋)支持更名，贊成使用收錄標準，但(－)反對使用「特筆性」。 Iming 彼女の愛は、甘くて痛い。 2025年1月2日 (四) 11:27 (UTC)

(＋)支持：支持改名。--Bowleerin（留言） 2025年1月2日 (四) 13:42 (UTC)

(＋)支持方案1（模仿「特筆性」）或方案2（「收錄標準」），不過本人對Talimu君這句正是因為不符合現代漢語習慣，所以讓人看見了會想點進去了解而不是掃一眼就望文生義很感興趣，因此更(＋)傾向支持模仿「特筆性」。然而"筆"需要改成中文更常見的動詞。--😺水餃喵與他的討論頁^🤝 2025年1月2日 (四) 14:24 (UTC)

(＋)支持。早該改改了，個人傾向「可收錄性」。--BigBullfrog（𓆏） 2025年1月2日 (四) 14:36 (UTC)

感覺不太符合中文文法⋯⋯--Talimu0518（留言） 2025年1月2日 (四) 14:41 (UTC)

(＋)支持：支持改為收錄標準。—Jane 閱·論·簽— 2025年1月2日 (四) 14:39 (UTC)

(＋)支持：支持收錄標準，但我更支持模仿日維，寫成更詳細的「創建獨立條目的標準」。--The Puki desu（留言） 2025年1月2日 (四) 14:58 (UTC)

或者按字面分析「關注度」的原詞「notability」：note（記錄）+able（可）+ity（性），從而翻譯成「可收錄性」。--The Puki desu（留言） 2025年1月2日 (四) 15:02 (UTC)

謝絕原創翻譯⋯⋯不過「特筆性」一詞實際上就是來自日文維基百科，我本人也比較支持一點。--Talimu0518（留言） 2025年1月2日 (四) 15:13 (UTC)

別胡言亂語。《非原創研究》是內容方針，不約束方針指引本身（哪條方針指引不是中維編者的「原創研究」？）。「特筆性」是日文，中文沒有這個詞，你直接把日文漢字移植過來也是在原創翻譯。--自由雨日🌧️❄️ 2025年1月2日 (四) 15:31 (UTC)

「特筆性」不是中文，請大家不要隨便照抄日本漢字詞。至於原創翻譯這件事情，本提問就是notability的現翻譯不好，也沒有合適的其他現成翻譯，才要討論出一個新方案來（擺手），所以大夥其實都是在新創。--The Puki desu（留言） 2025年1月2日 (四) 15:37 (UTC)

個人更支持「可收錄性」這個翻譯，至少它能夠更好兼容目前用法：「可收錄性的有效證明」聽起來確實比「符合收錄標準的有效證明」順嘴--Trz1118（留言）來人救救金屬學和材料科學條目們吧 2025年1月2日 (四) 15:28 (UTC)

移動時不留重定向、大面積紅鏈與批量清理鏈入

Wikipedia:重定向#移動時不留重定向沒有提及「批量清理鏈入」的事宜，是不是應該加入相關的敘述？--Txkk（留言） 2025年1月2日 (四) 13:49 (UTC)

我舉一個場景，某個頁面標題為A（內容為「甲」），但這個標題是明顯不適當的，就需要更名為B，因此由A不留重定向移動到了B，但有很多頁面是鏈接到內容為「甲」的頁面，然而由於沒有更改這些頁面的源代碼，這些頁面仍然是鏈接到了A，所以要批量更改這些頁面把內鏈改成B，不然的話就產生了大面積的紅鏈。--Txkk（留言） 2025年1月2日 (四) 13:58 (UTC)

「批量清理鏈入」屬於清除長期積累的歷史遺留問題，所以涉及到的頁面可能少則有四五個十多個二三十個四五十個多則幾百個（我還是往保守了說的），所以會非常耗時及耗費精力。--Txkk（留言） 2025年1月2日 (四) 14:06 (UTC)

建議查閱維基百科:機器人/作業請求——Huangsijun17（留言） 2025年1月2日 (四) 14:39 (UTC)

存廢討論時也是一樣。經存廢討論共識為刪除的重定向，我認為也應該像合併條目一樣，處理結果為「允許刪除，待清理完鏈入後通知管理員進行刪除」，而非直接刪除，典型的就是錯誤譯名（當然一些重定向如R7本就不應清理鏈入）。另邀請@Ericliu1912： ——自由雨日🌧️❄️ 2025年1月2日 (四) 14:52 (UTC)

同意移動不留重新導向時應一併清理連入頁面；若存廢討論取得刪除共識，亦當先行清理連入頁面再由管理員正式刪除。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年1月2日 (四) 16:49 (UTC)

技術

濫用過濾器警告信息

剛剛不小心觸發了Special:濫用過濾器/12，收到警告但因無明確信息我根本不知道爲什麽會觸發。現在知道了，但請為此過濾器（及其他僅使用「abusefilter-warning」做警告信息的過濾器）補充明確説明，方便編者，謝謝。--惣流·明日香·蘭格雷不姓式波 2024年11月18日 (一) 01:36 (UTC)

好像有簡要提示？……概述如下：字詞轉換缺少簡體設置。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年11月18日 (一) 01:41 (UTC)

啊，瞎了，前面太長沒看到 囧rz……不過考慮把概述搬到前面？方便我此類「盲毛」--惣流·明日香·蘭格雷不姓式波 2024年11月18日 (一) 01:50 (UTC)

「您的此次編輯觸發了關於某某原因的編輯器……」類似這樣的？——敬頌冬綏 ZhaoFJx_(論•簽) 2024年11月18日 (一) 13:22 (UTC)

類似，我的想法之一是「警告：您的操作觸發了濫用規則，其描述為：字詞轉換缺少簡體設置 [新行] 此操作已被系統自動識別為……」。--惣流·明日香·蘭格雷不姓式波 2024年11月18日 (一) 23:23 (UTC)

警告：您的操作觸發了濫用規則，其描述為：$1。無意義的操作會被迅速地回退，而過分或重複的無意義編輯會導致您的帳戶或IP地址遭到封禁。如果您確信本次操作是有意義的，您可以再次點擊「發布變更」以提交它。

如何？——敬頌冬綏 ZhaoFJx_(論•簽) 2024年11月18日 (一) 23:37 (UTC)

(＋)支持最好$1後開新行，但這也可以。--惣流·明日香·蘭格雷不姓式波 2024年11月18日 (一) 23:47 (UTC)

等待更多意見形成共識後就去MediaWiki_talk:Abusefilter-warning提編輯請求（）放到bulletin上哩——敬頌冬綏 ZhaoFJx_(論•簽) 2024年11月19日 (二) 00:18 (UTC)

好的，另建議「如果您確信本次操作是有意義的，您可以再次點擊「發佈變更」以提交它。」同樣寫於新行，但必要性不及$1後開新行。--惣流·明日香·蘭格雷不姓式波 2024年11月19日 (二) 01:34 (UTC)

現行條文 警告：此操作已被自動識別為有害。無意義的操作會被迅速地回退，而過分或重複的無意義編輯會導致您的帳戶或IP地址遭到封禁。如果您確信本次操作是有意義的，您可以再次點擊「發布變更」以提交它。與您此次行為所匹配的過濾規則概述如下：$1

提議條文 警告：您的操作觸發了濫用過濾規則，其描述為：$1。 無意義的操作會被迅速地回退，而過分或重複的無意義編輯會導致您的帳戶或IP地址遭到封禁。 如果您確信本次操作是有意義的，您可以再次點擊「發布變更」以提交它。

這樣？——敬頌冬綏 ZhaoFJx_(論•簽) 2024年11月19日 (二) 02:14 (UTC)

清晰多了，感謝閣下的協助。--惣流·明日香·蘭格雷不姓式波 2024年11月19日 (二) 02:36 (UTC)

@ZhaoFJx：濫用規則→過濾（器）規則，本地習慣--SunAfterRain 2024年11月29日 (五) 14:42 (UTC)

@SunAfterRain：贊，謝謝提醒。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年11月29日 (五) 17:02 (UTC)

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

Navbox hlist 數字清單 多餘開括號（重開）

之前開過，沒人回存檔了，例見沙盒。剛剛又稍微研究了一下，雖然不太懂不過應該找到問題所在了，似乎是Template:Hlist/styles.css line 143附近的first-child::before。希望懂行的幫忙處理一下，謝謝。--惣流·明日香·蘭格雷不姓式波 2024年11月30日 (六) 04:49 (UTC)

參照日文維基百科，應該是要把MediaWiki:Common.css#L-162--L-172，改成Template:Hlist/styles.css#L-127--L-102，註釋掉的部分，不可有.hlist ol ol:before--Qqkuro66541（留言） 2024年12月2日 (一) 15:23 (UTC)

在遷移完Navbox和Hatnote之後，接下來準備着手遷移Hlist/Plainlist，只不過需要精力以及人手支援。--Dabao qian℡ 2024年12月17日 (二) 18:15 (UTC)

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

應將使用Fullurl模板之頁面連結排除於待建立模板外

於Phabricator查看
編號T363708的工單
狀態：問題應於本地解決
因此請求無效

如題。但不知這是本站獨有問題，亦或全域皆然？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月14日 (六) 13:40 (UTC)

調用方式是解析器函數而非模板。統計功能bug？--YFdyh000（留言） 2024年12月14日 (六) 13:52 (UTC)

• @Ericliu1912：是這個問題phab:T363708，似乎是我之前某個操作導致的，但我最近工作真的太忙了，真的沒空修理這個。真的非常抱歉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月14日 (六) 14:03 (UTC)
  • 問題原因是模組:TemplateExist把所有{{XXX}}格式的字串都當成模板進行統計了，包含{{Fullurl:XXX}}，但問題是{{Fullurl:XXX}}並非模板而是解析器函數，而這個「解析器函數」被模組:TemplateExist當成模板一起統計了（正確的做法是統計時應排除包括但不限於{{Fullurl:XXX}}在內的解析器函數）故造成整個統計功能跟著模組:TemplateExist一起將之「誤認」為模板了。

    解決方式是模組:TemplateExist裡面要開發一個「解析器函數排除清單」的功能函數。但礙於模板被全保護，然後這種東西如果用沙盒測試要花超多時間，且在「沙盒測試過程」也沒有辦法確定正式上線時會否解決問題，所以可能還需要複製一個跟中文維基百科相同的測試站進行測試，但這需要花費的時間非常多。也不可能直接在該模組裡面直接修改開發（因為全保護）。我每天工作上班就要花上超過12.5個小時，然後我還要通勤、吃飯等，然後我之前嘗試只睡覺不到五小時，然後現在身體各處都在發炎（因睡眠不足），眼睛裡面、皮膚、腸胃等等……平均三五天去一次醫院或診所……如果現在叫我去修，我可能會暴斃在維基百科。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月14日 (六) 14:11 (UTC)

    • @A2569875：能不能直接回退某些頁面？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月14日 (六) 14:21 (UTC)
      • 不能。因為它嵌在一個複雜的體系裡面。例如：如果將模塊:PJBSClass/TrackingCategory回退至沒有Module:TemplateExist的版本，將導致其他與Module:TemplateExist無關的功能發生災難性損毀，因為它們是一起加入的，或者加入Module:TemplateExist時，某些與Module:TemplateExist無關的功能還未完成、正在製作/開發、或只做了一半。此外，所有已經上線的「讓同一頁面的重複模板不顯示」的部分頁面將全數損毀。所以此法不可行。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月17日 (二) 08:32 (UTC)

  TemplateExist研究進展見Module:TemplateExist/sandbox、User:YFdyh000/沙盒1，或能解決大部分問題，供參考。不過我對模塊:PJBSClass/TrackingCategory的功能機制了解為零及興趣不大，難以助力。Lua中調用mw.ext.ParserFunctions.expr來解析包含魔術字的表達式我沒能成功。請宇帆保重身體為先。抄送U:Kanashimi。--YFdyh000（留言） 2024年12月14日 (六) 19:49 (UTC)

  • 看起來似乎可行，感謝User:YFdyh000君的貢獻，小的在此獻上無盡的感謝（畢竟當時基金會點名叫我修改，但進職場之後要騰出時間弄維基……真的很難；又不敢睡太少，也不敢讓老闆看到我在偷偷編輯維基），看User:YFdyh000有沒有空可以整理一下，然後@Ericliu1912：上個緊急補丁，解決問題；另因為涉及到Module:TemplateExist的修改，本討論串是否也需要存檔至對應討論頁呢？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月14日 (六) 23:04 (UTC)
    • 也麻煩@Kanashimi：幫忙確認下，此一修改會否影響模塊:PJBSClass/TrackingCategory，以及修正此問題是否需修訂模塊:PJBSClass/TrackingCategory。我目前初估此問題無須修改模塊:PJBSClass/TrackingCategory即可解決，且Module:TemplateExist的修改理論上不影響模塊:PJBSClass/TrackingCategory的運作。抄送U:YFdyh000協助看看我的初估是否準確。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月21日 (六) 11:34 (UTC)

      好像沒看到什麼問題。--Kanashimi（留言） 2024年12月22日 (日) 02:36 (UTC)

• @YFdyh000：有新進展嗎？還是目前沙盒的版本已經修復問題了？如果是後者，我想可以提編輯請求以便修復問題，本案也能因此結案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月20日 (五) 10:53 (UTC)

  目前沙盒版本是魔術字的別名不夠全面，但預計修復主要問題，如果急着解決可以嘗試，後續再完善某些細節。我是想等等更好方案或測試的，但看上去沒啥人。--YFdyh000（留言） 2024年12月20日 (五) 13:24 (UTC)

  • @Ericliu1912：您覺得如何呢？我稍微看了一下，沙盒的程式碼應該能解決主要問題，但是可能有細節需要繼續完善。看您，如果您覺得這個問題有修復的急迫性，可以先上一版，沙盒的那一版。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月20日 (五) 23:44 (UTC)

    其實不急，最後能解決就好。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月21日 (六) 02:49 (UTC)

  • 我是想等等更好方案或測試的，但看上去沒啥人(：)回應：那就先以公示的名義，將這討論放置一周，如無異議（其實是看看是不是都沒人討論）由於初估功能是沒問題的且可以解決主要問題，我覺得一周後可以先編輯請求上一個版。未來如有出現更好方案，或是還有本案的其他修改，可再追加新的編輯請求。畢竟一直放在沙盒也沒法「確認」問題解決了沒以及解決了多少。考慮到模板嵌入是有緩存的，所以要能確認Fullurl模板之頁面連結是否已排除於待建立模板是需要等待數日清除緩存的，尤其是這種高引用之全保護模版，系統後台伺服器緩存可能需要清理數日至數周之久，因此我認為如目前沙盒沒有太大問題的話可以考慮上版，到時可能要麻煩User:Ericliu1912您編輯Module:TemplateExist，因為全保護只能由管理員修改。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月21日 (六) 11:30 (UTC)

    贊成。通過預覽能看到預覽所用模板中的紅鏈消失，所以解決大部分問題是能確認的，只是擔心未觀察到的bug或邊緣案例有多少、是否要一併解決，因為緩存刷新成本。( π )題外話，Module:PJBSClass/TrackingCategory/sandbox頁面顯示出，機器人保護的高引用頁面不再高引用後，不會被解除保護。--YFdyh000（留言） 2024年12月21日 (六) 18:53 (UTC)

    • (：)回應：@YFdyh000：那就只能一 　 個、一個 　 手動提請解除保護囉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月26日 (四) 04:46 (UTC)

    • 我認為先上一版，等緩存刷新。不然現在對「問題解決了多少」的掌握是很有限的；一直放沙盒的話，將永遠停在「掌握十分有限」狀態，也不利本案的繼續推動。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月21日 (六) 22:40 (UTC)

      到時候哪一個頁面需要，可以提個編輯請求哈。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月22日 (日) 21:47 (UTC)

  • 又過三天沒有異議了，我覺得編輯請求可以提了，反正流程都需要時間。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月25日 (三) 03:00 (UTC)

• User:YFdyh000的草案/初版編輯請求內容已經佈署。

  經測試，原Special:whatLinksHere/Template:Fullurl:Wikipedia:新條目推薦/候選第一項為talk:黑客，經手動編輯強制清除單頁的緩存：Special:Diff/85439435後，發現talk:黑客已從Special:whatLinksHere/Template:Fullurl:Wikipedia:新條目推薦/候選消失，說明本次修訂是有效的。

  由於有上萬頁面被緩存，因此接下來靜置一週，等待緩存清除後，屆時始可開始檢驗本案之問題是否有獲得解決。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月26日 (四) 01:00 (UTC)

  • 報告：待建立模板之Template:Fullurl:Wikipedia:新條目推薦/候選（{{Fullurl}}之Wikipedia:新條目推薦/候選）：
    • 於2024年12月26日 (四) 01:21 (UTC)檢視特殊:待建立模板為：

      1.Template:Fullurl:Wikipedia:新條目推薦/候選（4,598 個連結）

    • 於2024年12月26日 (四) 01:36 (UTC)檢視嵌入包含量/Template:Fullurl:Wikipedia:新條目推薦/候選

      找到在4160頁上使用。

  這說明特殊:待建立模板中的模板:Fullurl已正在逐漸消化。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月26日 (四) 01:21 (UTC)

  • (～)補充：於2024年12月28日 (六) 01:54 (UTC)檢閱嵌入包含量/Template:Fullurl:Wikipedia:新條目推薦/候選已歸零。不過嵌入包含量/Template:Fullurl:Wikipedia:優良條目評選/提名區還有好幾千，仍需繼續等待緩存清除。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月28日 (六) 01:54 (UTC)
    • 更新：於2024年12月29日 (日) 04:23 (UTC)檢閱特殊:待建立模板：Template:Fullurl:Wikipedia:新條目推薦/候選已從特殊:待建立模板中消失。但：

      1.Template:Fullurl:Wikipedia:优良条目评选/提名区（1,148 個連結）
      2.Template:Fullurl:Wikipedia:優良條目評選/提名區（1,148 個連結）

    Template:Fullurl:Wikipedia:優良條目評選/提名區的緩存仍在清除中（昨天看是二千多，估算下來一天大概會消化幾百條），仍需繼續等待緩存清除。

    • 說明User:YFdyh000的Patch有效。 目前並非發現其他問題，麻煩有空的人也可以幫檢查有無出現其他預期外問題，感謝-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月29日 (日) 04:23 (UTC)

      Fullurl:、Int:等涉及:的肯定有效，應無需回報。只需關注是否有漏判的魔術字呈現紅鏈，或者誤判為魔術字的模板調用（不容易發現）。

      前幾天了解到API查詢現有生效定義的方法，但其中的解析器函數（如ifeq）等特殊類型魔術字我沒找到區分方式。--YFdyh000（留言） 2024年12月29日 (日) 08:59 (UTC)

等待中……於2024年12月27日 (五) 00:45 (UTC)檢閱Special:需要的模板，數字仍很高。系統緩存仍在清除中-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月27日 (五) 00:45 (UTC)

• 等太久了...我直接用WP:NULLEDIT機器人User:WhitePhosphorus-bot/controls/purge了Special:Diff/85503226。等User:WhitePhosphorus-bot/controls/purge/status變成succeeded再檢查即可。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月31日 (二) 12:18 (UTC)

  不是近期問題，也不是很久吧……68萬鏈入會重新被刷一遍，如果只刷新剩下的能節省不少資源，但稍微費工。--YFdyh000（留言） 2024年12月31日 (二) 12:27 (UTC)

  • @YFdyh000：但直接WP:NULLEDIT似乎最有效。現在（2024年12月31日 (二) 13:52 (UTC)）看Special:需要的模板似乎已經沒看到{{Fullurl}}了。麻煩@Ericliu1912：幫忙確認下待建立模板中是不是已經沒有Fullurl模板了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月31日 (二) 13:52 (UTC)

待建立模板列表「最後更新於2024年12月31日 (二) 16:04」，晚於NULLEDIT任務遞交，之前慢慢消耗掉的。肯定有效，但執行效率未知，有服務器成本。--YFdyh000（留言） 2024年12月31日 (二) 13:58 (UTC)

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

禮儀師之奏鳴曲頁面開頭的典範條目之星是不是太大了？

我不知道如何把典範條目之星改小，所以在此求助一下。--Yurivikyi（留言） 2024年12月17日 (二) 15:29 (UTC)

異常巨大了。「引用模板後大小超過限制的頁面」，似乎導致頁面元素div id="mw-indicator-[[:#if:]]?'"`UNIQ--item-487--QINU`"'?"而非id="mw-indicator-FA"。--YFdyh000（留言） 2024年12月17日 (二) 16:00 (UTC)

{{Featured article}}所用Template:Top icon調用的Template:Category handler似乎占用了不少模板配額，兩三成？--YFdyh000（留言） 2024年12月17日 (二) 16:11 (UTC)

似乎可以把Template:Category handler lua化一下？--百無一用是書生 (☎) 2024年12月18日 (三) 02:10 (UTC)

已將Template:Category handler lua化，請檢查是否有問題--百無一用是書生 (☎) 2024年12月24日 (二) 08:24 (UTC)

看來不完全是{{Category handler}}問題，lua化後送行者：禮儀師的樂章仍然星星圖標巨大化，引用模板後大小超過限制：Special:PermaLink/85423621--百無一用是書生 (☎) 2024年12月24日 (二) 08:30 (UTC)

似乎Movie轉換組占用了1MB的展開後大小？--YFdyh000（留言） 2024年12月24日 (二) 08:57 (UTC)

那看來就要實施這個了：Wikipedia_talk:字詞轉換處理/公共轉換組#思路：條目預儲公共轉換組中匹配的規則，減少載入時間。暫時先用測試階段的{{noteTA-lite}}處理了，看來可以解決這個問題，的確是轉換組太大造成的--百無一用是書生 (☎) 2024年12月24日 (二) 09:09 (UTC)

iOS行動版app加入連結功能易引導他人違反WP:NOTBROKEN

於Phabricator查看
編號T382816的工單

我日前要將條文內文中的中華民國大陆時期（無內部連結的純文字）加入內部連結，使用手機ios app編輯，將中華民國大陆時期選取後，按下方的「加入連結」圖示，直接選取中華民國大陸時期（下方灰字：重新導向自中華民國大陆時期），就自動顯示為[[中華民國大陸時期|中華民國大陆時期]]了，因而被提醒違反WP:NOTBROKEN。因此，認為有改善此功能之必要，否則一般人沒想那麼多非常容易就無意間違反規定了。--アレックス（留言） 2024年12月19日 (四) 07:18 (UTC)

可視化編輯器也是這樣。--Kcx36（留言） 2024年12月21日 (六) 09:40 (UTC)

已提交工單。--SCP-0000（留言） 2024年12月29日 (日) 15:27 (UTC)

條目左上角的「維基百科，自由的百科全書」怎麼不見了？

如標題所述。--碟之舞📀💿 2024年12月24日 (二) 12:40 (UTC)

剛剛看了一下，其他語言版本還有（本站舊版Vector也有），所以是本站新版外觀的問題？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月24日 (二) 14:31 (UTC)

Wayback Machine追溯得知今年5月Vector 2022也還有，但是6月就沒有了。--碟之舞📀💿 2024年12月25日 (三) 02:14 (UTC)

HTML代碼現在是這樣：

<div id="siteSub" class="noprint" style="display: none;">维基百科，自由的百科全书</div>

英文版沒有style部分，這個內聯css暫時沒找到是哪裡給加上的--百無一用是書生 (☎) 2024年12月25日 (三) 03:48 (UTC)

看了一下幾個中文姊妹項目，維基詞典、維基文庫、維基學院、維基導遊沒有顯示；維基語錄、維基新聞、維基教科書顯示--百無一用是書生 (☎) 2024年12月25日 (三) 03:57 (UTC)

@Shizhao：我這裡沒有display: none啊，開安全模式試試？--碟之舞📀💿 2024年12月25日 (三) 11:41 (UTC)

我好像明白了，是不是今年6月份開始Vector 2022皮膚不加載MediaWiki:Vector.css導致的？--碟之舞📀💿 2024年12月25日 (三) 11:44 (UTC)

找到了：meta:Tech/News/2024/13。--碟之舞📀💿 2024年12月25日 (三) 11:51 (UTC)

可能找到問題出在哪裡了，一是MediaWiki:Gadget-WikidataDesc.js#L-63這行會加上style這部分，啟用了這個小工具的話就會被隱藏掉；二是默認加載的css樣式[6]有：

#siteSub {
  font-size:0.875rem;
  display:none
}

所以即使沒啟用前面說的那個小工具，也仍然不顯示這一行字--百無一用是書生 (☎) 2024年12月25日 (三) 13:23 (UTC)

難怪舊版Vector也是這樣！—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月25日 (三) 14:19 (UTC)

但如果是「沒載入CSS」也不會變成「元素被加display: none吧」

圖片截於條目《質因數表》

我這邊看也是display: none。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月25日 (三) 11:58 (UTC)

已參照en:MediaWiki:Common.css#L-254在本地MediaWiki:Common.css進行了修復，但是如果啟用MediaWiki:Gadget-WikidataDesc.js，仍然不會顯示該行字。--百無一用是書生 (☎) 2024年12月25日 (三) 13:34 (UTC)

同時在MediaWiki:Vector-2022.css進行了修復，不在首頁顯示這行字--百無一用是書生 (☎) 2024年12月25日 (三) 13:47 (UTC)

這樣的話，是不是MediaWiki:Vector.css#L-40、MediaWiki:Monobook.css#L-80可以刪除了？--碟之舞📀💿 2024年12月25日 (三) 14:01 (UTC)

Timeless用戶表示之前一直都沒有這十個字的，修改之後有了……--Tim Wu（留言） 2024年12月25日 (三) 15:35 (UTC)

已刪除--百無一用是書生 (☎) 2024年12月26日 (四) 02:44 (UTC)

我這邊看似乎已修復。

圖片截於條目《質因數表》

-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月25日 (三) 23:03 (UTC)

這邊在Timeless上的標語顯示為斜體，是期望的效果嗎？--Kethyga（留言） 2024年12月28日 (六) 12:05 (UTC)

看了一下css，默認就是斜體，不是bug--百無一用是書生 (☎) 2024年12月29日 (日) 10:16 (UTC)

我認為中文不應該有斜體，所以最好還是調整一下。--碟之舞📀💿 2024年12月29日 (日) 11:24 (UTC)

Arbcom 關聯

請導入en:Template:Arbcom notice到Template:Arbcom notice，謝謝。---Lemonaka 2024年12月26日 (四) 12:33 (UTC)

怎麽用{{Start date and age}}和{{wikidata}}？

我在修改條目Beyond Compare，我想要更新latest_release_version和latest_release_date。我看到英文維基百科寫的是

latest_release_version {{=}} {{wikidata|property|edit|reference|Q4899956|P348}}
latest_release_date {{=}} {{start date and age|{{wikidata|qualifier|Q4899956|P348|P577}}}}

但是在中文維基百科，這樣的代碼出錯。甚至在英文維基百科，「25 November 2024; 24 days ago」是計算得不對的。

請問{{Start date and age}}和{{wikidata}}應該怎麽樣配合使用？謝謝--JasonCho110（留言） 2024年12月26日 (四) 21:10 (UTC)

{{wikidata|qualifier|raw|Q4899956|P348|P577}}得到ISO日期格式。Start date and age的參數1是年份，所以計算不正確。本地不填寫參數就好，目前信息框會自動取維基數據，畫蛇添足了吧。--YFdyh000（留言） 2024年12月26日 (四) 22:02 (UTC)

原來是這樣。{{Infobox_software}}寫了「本模板使用維基數據資源P348, P577」。謝謝大蝦。--JasonCho110（留言） 2024年12月28日 (六) 11:50 (UTC)

樂詞網模板連結有時會失效

模板:樂詞網 此模板似乎有問題，連結有時會失效，不確定是不是維基百科的問題。 以下面這個例子為例：

微軟視窗. 樂詞網. 國家教育研究院 （中文（臺灣））. 

建議各位先用手機點擊連結試試。

1. 用電腦點擊上面連結「可能」能正確進入詞條頁面 https://terms.naer.edu.tw/detail/2d85e05dd13d4f0e5f84212d858d71f8/?startswith=zh&seq=2 ，但也有機率不能。
2. 如果不要用電腦先點，直接用手機點擊連結（無論safari或app），只會導向搜尋頁，而非該詞條。
3. 2.試過後，改用電腦進行1.，如果1.成功正確進入到詞條頁面的話，再回頭嘗試2.，就也能正確進入了。但過陣子再試又會失敗。

㊟：我手機是使用iOS系統，電腦iOS或Windows都有。

隨便多幾個例子給各位試試，上面的「微軟視窗」連結如果1.~3.試過變正常了，用手機點下面兩個沒點過的連結，可能不一定會是正常的。

維基百科. 樂詞網. 國家教育研究院 （中文（臺灣））. 

蘋果公司作業系統. 樂詞網. 國家教育研究院 （中文（臺灣））. 

--アレックスAlexwikix 2024年12月30日 (一) 01:55 (UTC)

@Kethyga： ——自由雨日🌧️❄️ 2024年12月30日 (一) 02:00 (UTC)

我用這些鏈接只能進入搜索頁。以前也遇到過，我以為之前編者寫的不對。應該屬於網站問題，搜索結果頁有csrfmiddlewaretoken、產生cookie csrftoken，是網站拒絕直接訪問詞條頁面？--YFdyh000（留言） 2024年12月30日 (一) 09:24 (UTC)

他們網站自身的問題，咱們沒轍。不如讓維基媒體台灣分會找樂詞網團隊的人解決。--Txkk（留言） 2024年12月31日 (二) 01:01 (UTC)

提議給MediaWiki:Noarticletext和MediaWiki:Noarticletext-nopermission（含所有中文變體）加上維基數據

簡：

<tr>
<td align="center" >[[File:Wikidata-logo.svg|30x30px|link=]]</td>
<td>[[d:Special:Search/{{PAGENAME}}|维基数据]]（自由的知识库）</td></tr>

繁：

<tr>
<td align="center" >[[File:Wikidata-logo.svg|30x30px|link=]]</td>
<td>[[d:Special:Search/{{PAGENAME}}|維基數據]]（自由的知識庫）</td></tr>

--Txkk（留言） 2024年12月30日 (一) 07:16 (UTC)

從源碼來看，贊成。--YFdyh000（留言） 2024年12月30日 (一) 09:02 (UTC)

贊成？我都寫錯了你還沒看出來？看起來你也不咋認真吶！🤣🤣🤣 --Txkk（留言） 2024年12月31日 (二) 00:54 (UTC)

我沒檢查這裡，只是贊成加入……因為直接查看MediaWiki:Noarticletext看不到相關項，所以我說源碼上看。--YFdyh000（留言） 2024年12月31日 (二) 11:08 (UTC)

不藍不綠的綠鏈問題

示例：漢斯·鮑爾。明明頁面存在，鼠標挪上去依然顯示提示框，並且導致我做的新版測試錯誤。我認為是模板代碼的問題，希望修正。問題在於ILH沒有適配MediaWiki的自動標題簡繁轉換。--碟之舞📀💿 2024年12月30日 (一) 15:48 (UTC)

這個本來的ILH小工具也不行吧？反正我自己改的也顯示紅鏈。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月30日 (一) 16:04 (UTC)

是不行，原因是模塊自己生成的代碼有問題，所以要修復也是在模塊層面修復。--碟之舞📀💿 2024年12月31日 (二) 02:59 (UTC)

編者應該手動替換成藍字連結。

至於為什麼機器人一直沒幫忙替換掉，這個要問@Cewbot。--SuperGrey (留言) 2024年12月30日 (一) 16:13 (UTC)

• (：)回應：@Diskdance、魔琴、SuperGrey：這種現象的原因已載於此範例：Module:ZhConversion#標題轉換。簡而言之就是ILH相關Module無法識別「漢斯·鮑爾」與「汉斯·鲍尔」的差異所致。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月31日 (二) 01:04 (UTC)

@Kanashimi：麻煩看一下。--碟之舞📀💿 2024年12月31日 (二) 02:52 (UTC)

@Diskdance 有實際的文章為例嗎?--Kanashimi（留言） 2024年12月31日 (二) 03:35 (UTC)

@Kanashimi：上面第一行的「示例」就是。如果您是要實際存在問題的頁面的話，Template:元首地堡內的最後居住者有好幾個這樣的鏈接。--碟之舞📀💿 2024年12月31日 (二) 03:37 (UTC)

機器人可以處理。也許該清快取了。--Kanashimi（留言） 2024年12月31日 (二) 09:18 (UTC)

• 繁簡問題吧。請考慮在ILH相關Module中引入Module:ZhConversion協助判斷繁簡。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月30日 (一) 23:39 (UTC)

  @A2569875：可以先做一個版本出來嗎？另外，@SunAfterRain在嘗試給Lua引入MW字詞轉換，我覺得將來直接用這個會更健壯一點。--碟之舞📀💿 2024年12月31日 (二) 02:57 (UTC)

  那種東西還是再等等吧（--SunAfterRain 2024年12月31日 (二) 03:03 (UTC)

  • @SunAfterRain、Diskdance：？？？Module:ZhConversion這東東不就是已經「給Lua引入MW字詞轉換」了嗎？？？？？？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月31日 (二) 03:39 (UTC)

    完整地從phab:source/mediawiki/browse/master/includes/languages/data/ZhConversion.php抄來的轉換表就長在這耶Module:ZhConversion/data，都已經與MW的ZhConversion.php同步了，還有「需要另外給Lua引入MW字詞轉換」的必要？？？？？ 難道你們要造新API寫進mw裡？？？？？？？？？？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月31日 (二) 03:41 (UTC)

    （已經在站外跟對方解釋了，請各位無視）--SunAfterRain 2024年12月31日 (二) 04:49 (UTC)

  • @Diskdance：我現在上班很忙，無法。Module:ZhConversion這東東就是給Lua引入MW字詞轉換，你只需要把繁簡轉換函數帶到ILH判斷頁面名稱之前就可以了，做法可參考Module:TemplateExist#L-226-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月31日 (二) 03:45 (UTC)

  Module:沙盒/SuperGrey/Ilh。已測試（Special:Permalink/85499947），供參考。--SuperGrey (留言) 2024年12月31日 (二) 04:40 (UTC)

  此為修改差異：Special:Diff/85499863。--SuperGrey (留言) 2024年12月31日 (二) 04:42 (UTC)

  @SuperGrey：謝謝。但是我注意到您的代碼調用了三次高開銷函數exists，想問一下這樣會不會導致性能問題？--碟之舞📀💿 2024年12月31日 (二) 08:24 (UTC)

  • @Diskdance、SuperGrey：Special:Diff/85502422弄成只叫一次，如何？高開銷改非高開銷判定方式。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月31日 (二) 09:17 (UTC)

    👍--SuperGrey (留言) 2024年12月31日 (二) 18:12 (UTC)

    @A2569875：Special:PermaLink/85502422#L-153附近的注釋也改一下吧？--碟之舞📀💿 2025年1月1日 (三) 03:29 (UTC)

    • @Diskdance：改了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 03:47 (UTC)

Module_talk:Ilh#編輯請求_2025-01-01。--碟之舞📀💿 2025年1月1日 (三) 04:23 (UTC)

@Diskdance：「content or getContent(): Returns the (unparsed) content of the page, or nil if there is no page. The page will be recorded as a transclusion.」，exists只是高消耗方法，調用getContent()相當於一次嵌入，「Post‐expand include size」可能會更炸裂。有一個替代方法，在模塊外的模版調用傳入ifexist的判斷，因為ifexist這個判斷應該有適配繁簡問題，模塊中預留了$exist$入參判斷。——Sakamotosan路過圍觀 | 避免做作，免敬 2025年1月1日 (三) 08:33 (UTC)

ifexist 沒有此功能。魔術字都沒有 ，之前寫Module:ZhConversion時研究過了，寫Module:ZhConversion的動機也是「魔術字頁面判斷不支援繁簡標題轉換」@cwek：。並未觀察到更炸裂。至少當時做{{Va}}沒有炸裂。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 08:42 (UTC)

參考這個Module:沙盒/Cwek/test3（oldid=85513309）。——Sakamotosan路過圍觀 | 避免做作，免敬 2025年1月1日 (三) 08:44 (UTC)

用frame:callParserFunction調用外部的ifexist，ifexist好像是支持繁簡轉換的。不過很骯髒，需要frame的調用包裝為匿名方法來傳入進一步的業務方法。——Sakamotosan路過圍觀 | 避免做作，免敬 2025年1月1日 (三) 08:49 (UTC)

• 沒有「好像支援」。當初寫Module:ZhConversion就是因為魔術字及解析器函數沒有找到支援「繁簡頁面標題差異」的功能。沒有功能就沒有功能，沒有「好像有功能」這種東西。沒有就沒有，沒有「好像」。@Cwek：。 - - 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 08:59 (UTC)
• 不然就是這兩年內Mediawiki系統有相關修訂，修改了這個的支援性。- - 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 09:04 (UTC)
• 如果今年支援了，那就你來協助改ilh 沙盒吧。我還有工作要加班，沒法協助改上。- - 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 09:06 (UTC)
• 看到你在沙盒好像有測出東西了，證明我2020年的測試可能過時了。就說明一下，不過我要去忙了，就麻煩你把沙盒依照你的想法修改吧。這樣Module:ZhConversion就不用變成全保護的超高風險模板了-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 09:09 (UTC)

• @A2569875：，看一下oldid=85513309，我這邊初步測試，ifexist判斷漢斯·鮑爾能判斷到汉斯·鲍尔，用Lua掉外部解析器同效。ilh最初模板版判斷頁面存在就是用ifexist，ifexist是很久的方法，應該當時反饋過處理標題繁簡問題。——Sakamotosan路過圍觀 | 避免做作，免敬 2025年1月1日 (三) 09:10 (UTC)

@Winston Sung：雖然我沒看過MW相關代碼，但是我猜#ifexist應該和MW本體用了相同邏輯，也共享MW標題自動簡繁重定向的行為，是這樣嗎？這個行為是否是有意為之，也就是說將來不會意外改壞掉？--碟之舞📀💿 2025年1月1日 (三) 13:59 (UTC)

• 目前是有意為之，但不能保證之後是否會繼續沿用這個邏輯。

https://gerrit.wikimedia.org/g/mediawiki/extensions/ParserFunctions/+/b5fbdc5/includes/ParserFunctions.php#350

--Winston Sung（留言） 2025年1月2日 (四) 14:14 (UTC)

• ( π )題外話我看到您在Module:WikidataLink也提了與『新版小工具』相關的編輯請求——Module_talk:WikidataLink#編輯請求_2024-12-31，是指新版小工具馬上就要上線了嗎/或已經上線了嗎？還是還需要等待，只是先做前置作業（沒找到有關新版小工具的上線討論）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年1月1日 (三) 04:37 (UTC)

所以，它改正後，類似樓主的內連，能被Category:有藍鏈卻未移除內部連結助手模板的頁面Scan到嗎 ?--約翰同志－條目裱糊匠（留言） 2025年1月2日 (四) 10:25 (UTC)

頑固的緩存

我發覺在近期緩存很頑固，怎麼purge都purge不掉。比方說，我批量修改了內鏈，purge無數遍之後，之前的內鏈仍舊在Special:WhatLinksHere裡面，甚至過了好多天還是這樣子。--Txkk（留言） 2024年12月31日 (二) 01:12 (UTC)

WP:NULLEDIT試過嗎--YFdyh000（留言） 2024年12月31日 (二) 10:47 (UTC)

試過很多次啦，沒一點用 聳肩 --Txkk（留言） 2025年1月1日 (三) 06:32 (UTC)

模板引入？這類情況需要將嵌入這個模板的全部頁面都purge一次。如果嵌入的不是模板頁，更需要這樣做。模板頁好像有後台隊列更新，其他空間沒有？——Sakamotosan路過圍觀 | 避免做作，免敬 2025年1月1日 (三) 07:03 (UTC)

太繁瑣了吧，想想就頭大。--Txkk（留言） 2025年1月1日 (三) 07:58 (UTC)

修訂間差異不太智能

見[7] 有連續的很多段文字，每一段修改較少，但是沒有被識別出來，沒有一一對應。這些文字的一個特點是刪除了段落開頭的兩個星號。後面還有一段把差異較大的文字進行了比較（加利福尼亞大學和民進黨立委這兩段）--GUT412454（留言） 2025年1月1日 (三) 16:03 (UTC)

求助

請求協助上傳檔案 2024-12-24 05:38

我想要上傳的圖片來源是<從某個網址下載，請提供網址https://w.wiki/CLyE / 自行拍攝>，想要使用在請提供條目名稱https://w.wiki/CUCP（如果條目還不存在，請先建立條目再請求上傳文件）的<資訊框/某個段落，請說明>。 --Pineappleq（留言） 2024年12月24日 (二) 05:38 (UTC)

我希望能獲得更多關於新建條目語氣、中立性以及來源選用的建議，並了解目前草稿是否符合維基百科的條件。感謝大家的協助。

大家好，我是一名維基百科的熱心編輯者，我的朋友胡女士最近撰寫了一篇關於藝術家蔡爾平的條目，草稿多次被退回，所以前來尋求我的協助，我希望能獲得大家的建議，幫助我改善條目的語氣、中立性以及整體結構，並確認目前草稿是否符合維基百科的方針與指引。她撰寫的條目是「蔡爾平」，一位臺灣旅美藝術家，條目內容多次被退回，理由主要是「宣傳語調過於強烈」。目前草稿已進行以下修改： 一、精簡了榮譽記錄，並補充了更多第三方來源（如中央通訊社報導）。 二、刪除了過度主觀的表述，如「受到各界讚賞」。 三、刪除了過於抽象的描述，如「一般認為其創作特色為色彩鮮豔、工法精緻、且蘊含自然童趣」。

   我希望能獲得更多關於語氣、中立性以及來源選用的建議，並了解目前草稿是否符合維基百科的條件。感謝大家的協助！
   草稿鏈接：https://zh.wikipedia.org/wiki/Draft:%E8%94%A1%E7%88%BE%E5%B9%B3--125.228.111.55（留言） 2024年12月25日 (三) 09:56 (UTC)

請求協助上傳檔案 2024-12-27 11:14

我想要上傳的圖片來源是<https://www.youtube.com/watch?v=GAFL0Ne4AeE>，想要使用在裝甲兵進行曲的<音頻位置>。 --帝國突擊隊123（留言） 2024年12月27日 (五) 11:14 (UTC)目前的音頻已經失效

你是該視頻的創作者嗎？--Talimu0518（留言） 2024年12月27日 (五) 11:19 (UTC)

個人認為改用WP:ELMIN的方式置入條目會更好。--Allervous迷い星のように叫ぼう 2024年12月27日 (五) 23:28 (UTC)

文件具有版權且可能不符合非自由內容使用準則。--Iming 彼女の愛は、甘くて痛い。 2024年12月28日 (六) 08:15 (UTC)

請求大量刪除

新手上路，想詢問能否幫忙刪除臺南市長黃偉哲條目的一些文字

分別是立法委員: "2014年底起"到最後的"領取津貼一事，進行檔案核實。"

臺南市市長: "臺南市議員謝龍介"到"合理範圍，判其敗訴"

還有南鐵東移的"隨即引起民眾不滿"到"最大的同理和尊敬。"

理由: 第一是類似評論的內容、第二是跟條目所指人物關係不明、第三是無意義的繁瑣引用(可簡括為引發爭議，不須逐人羅列)

關於在半夜提交了那麼多次都被系統擋下來我很抱歉，個人不是故意的。

--Qinnix（留言） 2024年12月27日 (五) 19:01 (UTC)

現在內容已經亟少，請具體指出-- A0_{(討論·簽名)} 2024年12月28日 (六) 08:00 (UTC)

請求代為上傳文件

希望將 https://file.koolearn.com/77511503390932.jpg上传为 孟炎.png--佩奇君•查•論•不許編 2024年12月28日 (六) 08:10 (UTC)

似乎並非為公有領域圖像，且原網址沒有給出文件版權描述。除非給出合理使用憑據，否則恐無法上傳。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月28日 (六) 18:42 (UTC)

使用「犧牲」這種詞語是否違反中立語氣？

我覺得在戰爭等軍事政治情況中使用「犧牲」一詞可能違反中立語氣方針。但想請問一下：用「犧牲」一詞描述「在因拯救公共財產或其他生命的過程中遇難的行為」是否違反中立語氣方針？--261026CQ 2024年12月28日 (六) 11:06 (UTC)

《現代漢語詞典》中對「犧牲」一詞的解釋是「為了正義的目的捨棄自己的生命」。如果某種目的像「地球是圓的」那樣被絕大多數人公認為「正義」（比如不涉及軍事衝突的救火？）的話，我覺得或許可以使用「犧牲」一詞？--自由雨日🌧️❄️ 2024年12月28日 (六) 11:13 (UTC)

不太確定，這種用法總感覺還是帶點立場的。但我認為像是捨身救人，或是在救火等公共安全事件中因公遇難 這種語境下感覺應該可以吧？而且維基百科上也有眾多條目在這種語境下使用「犧牲」一詞，如：2019年木里森林火災、衡陽「11·3」特大火災、1·29貴州綏陽飛機墜毀事故等等，並且甚至在戰爭等軍事政治詞條中使用「犧牲」的例子也很多，如：中國工農紅軍第二十五軍、新四軍第5師、中國抗日戰爭犧牲者列表等等--261026CQ 2024年12月28日 (六) 11:30 (UTC)

不基於可靠來源的去改掉可靠來源中的「不中立」用詞，我懷疑是不正確的，WP:POV要求撇除偏見去表達可靠來源中的重要觀點，少數採用中性用詞的觀點可能是不重要的，認為可靠來源普遍使用詞彙不中立也可能本身存在偏見與原創研究。「中立要求將觀點不帶偏見地表達出來」，如果所引觀點（視角?）稱犧牲，轉述時仍要用犧牲？--YFdyh000（留言） 2024年12月28日 (六) 11:39 (UTC)

我覺得犧牲一詞可以用陣亡代替，如是工作職務上可以使用殉職，這一部分上的文字問題比較有爭議，還可以再討論--Liao_509 ^{☄️Fighting！簽名🖋} 2025年1月2日 (四) 14:42 (UTC)

新進改動的telegram wikipedia-zh-autoconfirmed 申請加入機制不工作？

關閉：

Gluo88已經被不限期封禁。Пусть от победы☆к победе ведёт! 2024年12月31日 (二) 04:51 (UTC)

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

---

1. 以前即使不加入wikipedia-zh-autoconfirmed， 也可以看到wikipedia_zh_ac內容， 但前幾個星期開始看不到了。看來wikipedia-zh-autoconfirmed 設置幾個星期前被改動了。
2. 於是試着申請加入該群。 在網頁https://t.me/+Cu_MIgmfTZoxMjk1，可見 wikipedia-zh-autoconfirmed 246 members, 31 online。 點擊了的「JOIN GROUP" 可以進入telegram app的 wikipedia-zh-autoconfirmed群，繼續點擊了群的 「JOIN GROUP", 並沒有出現 讓我驗證的信息。 反而顯示 「Sorry, this group is not accessible"。
3. 似乎設置幾個星期前被改動， 是否該群接收新成員的設置 出了問題？ 請求幫助解決申請加入該群的設置。

--Gluo88（留言） 2024年12月29日 (日) 06:47 (UTC)

---

你被ban了，不要當笨蛋--SunAfterRain 2024年12月29日 (日) 10:52 (UTC)

已經對他的不文明行為提報了--Gluo88（留言） 2024年12月29日 (日) 14:15 (UTC)

---

請管理員關注:

1. 打開被關閉的討論.
2. 調查 SunAfterRain 疑似不實說法（「你被ban了」）， 我以前根本就沒進入過這個群。SunAfterRain也不可能知道我的ID。
3. 警告SunAfterRains （其用了不文明語言）

--Gluo88（留言） 2024年12月29日 (日) 13:12 (UTC)

任何人都能重開討論。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月29日 (日) 14:00 (UTC)

此問題刻正處理中。另外我個人建議SunAfterRain不要在別人求助時倒打一把，不是每個人都理解Telegram運作機制，請有點同理心。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月30日 (一) 16:32 (UTC)

@Ericliu1912 不用處理了，他已經被不限期封禁了。Пусть от победы☆к победе ведёт! 2024年12月31日 (二) 04:47 (UTC)

---

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

為什麼{{deltalk}}模板不應替換引用而{{CW}}模板只能替換引用？

使用{{subst:deltalk/autho|}}代碼，雖然前面帶有「subst:」，但使用後的效果並非替換引用（可查看Special:鏈入頁面/Template:Deltalk）。但同樣是撤回留言的模板{{CW}}卻必須替換引用。這是為什麼？--自由雨日🌧️❄️ 2024年12月29日 (日) 07:47 (UTC)

因為{{subst:deltalk/auto}}直接將Template:Deltalk/auto模板引用到頁面上，也就是下面的文本：

‎

{{deltalk|sign=~~<includeonly></includeonly>~|time=~~<includeonly></includeonly>~~<includeonly></includeonly>~<noinclude>|reason=[[Wikipedia:讨论页指导方针|與本討論頁面無關]]|</noinclude>{{sub<includeonly></includeonly>st:#if: {{{1|{{{reason|}}}}}} | {{sub<includeonly></includeonly>st:!}}reason={{{1|{{{reason}}}}}}|  }}}}‎

可見，實際上{{subst:deltalk/auto}}的作用是，引用了deltalk模板本體後，自動填寫用戶名和時間。

然而{{subst:CW}}的原理就簡單了，沒有附屬頁面，替換引用時直接簽名並補上時間。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月30日 (一) 18:35 (UTC)

我主要問的不是設計本身，而是為什麼需要這麼設計…… ——自由雨日🌧️❄️ 2024年12月31日 (二) 03:37 (UTC)

請求協助上傳檔案 2024-12-29 09:14

我想要上傳的圖片來源是https://mp.weixin.qq.com/mp/profile_ext?action=home&__biz=MzA3Nzc3Nzg5MQ，想要使用在福州外國語學校教育集團的資訊框。 --Rinuan（留言） 2024年12月29日 (日) 09:14 (UTC)

請參考維基百科:非自由文件使用依據指南，提供一份合理的依據。此外，這個鏈接似乎無法打開？——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月30日 (一) 18:37 (UTC)

請求協助上傳檔案 2024-12-30 05:25

我想要上傳的圖片來源是<https://cronicasmacaenses.com/wp-content/uploads/2015/05/macau-casa-gruta-de-camc3b5es-01.jpg>，想要使用在東方基金會會址的<右側第一張圖片，原因是現時的相片並非昔日的舊建築,編輯者所引用的相片有誤>。 --W. Brahm（留言） 2024年12月30日 (一) 05:25 (UTC)

圖片可在[8]處找到，不過尚不確定版權要求。如果是合理使用則請檢查維基百科:非自由文件使用依據指南，並提供合理的解釋，辛苦。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月30日 (一) 18:41 (UTC)

請求協助加入可信來源ctext.org

https://ctext.org/ 是一個可靠的網站，收藏了海量古文，對中文世界貢獻巨大！--Lyrieek（留言） 2024年12月30日 (一) 08:22 (UTC)

請解釋「加入」。按FAQ，網站的Wiki部分隨意編輯、不做審查，應不能視作可靠，Library部分不確定。--YFdyh000（留言） 2024年12月30日 (一) 09:00 (UTC)

因為我加入其他鏈接時不會有提示，但是加入https://ctext.org/的<ref>時會提示鏈接可靠來源 https://zh.wikipedia.org/wiki/Wikipedia:%E5%A4%96%E9%83%A8%E9%93%BE%E6%8E%A5--Lyrieek（留言） 2024年12月31日 (二) 02:31 (UTC)

聽不懂。而且你也沒有說明ctext為何是可信來源。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月31日 (二) 04:28 (UTC)

他說「標籤：增加不可靠來源」。八成因為網址有wiki.pl。而如上所述，該網站的wiki板塊不做審查、隨意修改，不應視作可靠來源。--YFdyh000（留言） 2024年12月31日 (二) 10:56 (UTC)

ctext屬於線上圖書館，使用其作為來源時，來源其實是具體的書籍，討論圖書館本身可不可靠意義不大。--Kcx36（留言） 2024年12月30日 (一) 09:57 (UTC)

使用古籍作為參考文獻的問題見Wikipedia:互助客棧/條目探討/存檔/2021年11月#多篇只以古籍作來源的特優條目去留。--Kcx36（留言） 2024年12月30日 (一) 09:59 (UTC)

草稿轉正式頁面

請幫我把Draft:平戸中平改成正式頁面.

感謝大神.--平城伊（留言） 2025年1月1日 (三) 09:53 (UTC)

@平城伊：您好，我已將該草稿正式改成「快速刪除候選」。不用謝。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2025年1月1日 (三) 09:58 (UTC)🫢1

可否創建重定向

「・」為錯誤兼常用的間隔號，可否創建重定向條目「・」至「間隔號」。--HaydenWong（留言） 2025年1月1日 (三) 15:47 (UTC)--HaydenWong（留言） 2025年1月1日 (三) 15:49 (UTC)

請求創建條目

• 丁韻仙（d:Q131417486）
• 陳敬輝（d:Q113442032，《穿制服的少女》的作者）

都是台灣畫家。Google上能找到他們資料，可惜的是只有Wikidata有條目。--Thyj (คุย) 2025年1月2日 (四) 09:53 (UTC)

條目探討

參考資料

誤用Wikipedia:持續出沒的破壞者/User:Qqqyyy惡作劇內容的書籍

Wikipedia:持續出沒的破壞者/User:Qqqyyy自2007年就開始以不同傀儡在中文維基條目對歷史、宗教、民俗偽造內容。若被刪除他也會加回，被質疑則作擾亂與人身攻擊言論。等外界誤用，他就加上作循環認證。

維基外面已多有誤用，甚至包含有一定學術地位的書籍，恐怕中文維基哪一天消失了，這些惡作劇也會繼續散播下去。其破壞時間、範圍、程度、惡質人品遠超User:折毛，但受關注度卻相反。我將目前（2024年12月19日為止）發現受其惡作劇內容的書籍整理如下表，因本人精力與程度有限，以下恐是冰山一角。

誤用書籍

偽造時間	偽造項目	誤用書籍
2007年	偽造謝安稱呼「謝聖王」	2013年《臺南王爺信仰與儀式》第140頁 2022書《清代噶瑪蘭寺廟興建與市街形成》第216頁
2009年	偽造孫中山化名「品蘭堂」	2016年《趣味漫畫資治通鑑：清(下)》第173頁
2009年	偽造鍾離權稱為「正陽開悟傳道重教帝君」	《謝選駿全集》第221卷第530頁 2009年《極樂八仙》未標頁碼 2023年《歇後語：探索中華智慧》未標頁碼
2010年	捏造古書名「異蹟略」、「異跡略」與假原文、捏造宋高宗、宋孝宗歷史	謝選駿《謝選駿全集》第159卷387頁
2010年	捏造古書名「稱謂雜記」與假原文	2013年《我學易經的第一步：「易」有幾千歲的壽命，而且活得很有活力》第18頁 2017年《夕堂戲墨箋注》第306到307頁
2010年	偽造古書名「蓬萊小語」	2013年《臺灣文藝叢誌》〈森春濤與《新文詩》系列〉第20頁 2019年《森春濤的香奩詩受容與漢詩創作》頁碼待查
2010年	偽造李贄稱呼「溫陵先師」與民俗	《謝選駿全集》157卷第602頁 《易經故事 無妄》未標頁碼 2018年《地球論理(世界各國)》第247頁 2020年《紫柏真可:鐵膽禪僧》第54頁
2010年	偽造林本源家族、林維源、李春生、洪騰雲資產數據	2016年《生活在這塊土地的你可以拿來說嘴的七十則冷知識》第34頁 2017年《一看就懂台灣博覽》第27頁 2024年《日式街屋建築：臺北篇》第65頁
2010年	偽造古書名「如來淵源攷」與原文	2024年《滴露研朱: 第五輯》未標頁碼
2011年	張巡稱呼「尊武尊王」移花接木至王潮	2022年《圖解閩南語概論》第29頁
2011年	偽造王潮稱呼「泉安尊王」	2022年《圖解閩南語概論》第29頁
2011年	偽造部分八家將稱為「四季帝君」	2015年出版的《圖解台灣史》第81頁
2011年	捏造羅清字號「思孚」、又名「羅思孚」	2012年《武道狂之詩卷十一劍豪戰爭》未標頁碼 2016年《我在人間的靈修迷藏: 70年靈修大調查，看穿靈修人的過去、現在與未來》第101頁 2024年《看懂一貫道》未標頁碼 2024《看懂北海老人全書》未標頁碼
2011年	捏造文昌帝君稱呼「文昌武烈梓潼帝君」	2023年布拉格文創社《東京夢華錄》第300頁
2011年	柳修因稱呼「普渡真君」移花接木至面燃大士	2016年《賴惠川竹枝詞研究:以<<悶紅墨屑>>、<<續悶紅墨屑>>為主要線索》第289頁 2016年《香港盂蘭夜話》第16頁 2023年《《金瓶梅詞話》歲時節令》第62頁 2023年《上水虎地坳風物志》 第43頁
2011年	捏造面燃大士稱呼「面燃大士普渡真君」	2023年《金瓶梅詞話歲時節令 》第62頁
2011年	捏造骷髏杯稱為「首爵」	《謝選駿全集》第102卷第580頁
2011年	捏造古書名「佛名釋典傳略與原文」	2015年《關於佛教諸佛的100個故事》第58頁 2017年《般若花開: 佛教諸佛最精彩的故事》第58頁
2012年	捏造大院君別稱「雲峴君」	《謝選駿全集》第179卷113頁 2017年《拆拆中國史：原來中國史可以這樣整理》第320頁 2022年《追溯近現代中國起源與歷史 第二章》第253頁 2022年《你必須認識的韓國人》第54頁
2012年	偽造蒯祥字號「香山」	2019年《藝術生活(視覺應用)》第87頁
2012年	偽造鍾馗等合稱「三伏魔帝君」	2015年《林金鍊跳鍾馗儀式劇場》第15頁 2019年《濁水溪流域彰化縣東南區客家文化傳衍之研究》第219頁 2020年《明代宗教雜劇研究》第335頁 2021年《和魂漢神: 中國民間信仰在德川日本的在地化》第171頁
2012年	偽造鍾馗稱為「鎮宅真君」	2015年《香港樂活節氣文化》第115頁 2015年《林金鍊跳鍾馗儀式劇場》第15頁 2015年《波斯和中國: 帖木兒及其後》第128頁
2012年	偽造玄天上帝稱為「北極蕩魔天尊」	2014年《天律聖典大全譯註》1410頁 2024年《史上最有梗的東方魔法書：奇幻深遠的道門咒語》第17頁 2024年《看懂道教》未標頁碼
2012年	偽造面然大士稱呼「面燃大士羽林監齋普渡真君」	2016年鬼故事小說《香港盂蘭夜話》未標頁碼 2022年《流行閒情系列(16)：香港盂蘭夜話【精華版】》未標頁碼
2013年	偽造謝安稱呼「廣惠靈應顯濟尊王」	2022年《清代噶瑪蘭寺廟興建與市街形成》第216頁
2013年	偽造李鴻章說「白銀更勝白米，錢根即是命根」	2016年 《走近徽州文化》第47頁 2018年《搞懂顧客服務旅程: 打造鐵粉》第107頁
2013年	偽造劉海蟾稱為「廣陽真人」	2018年《地球論理(世界各國)》第121頁 2022年《太乙金華宗旨 : 天心金丹秘法》第vii頁 2024年《看懂道教》未標頁碼
2013年	偽造王重陽、呂洞賓、劉海蟾、王玄甫、鍾離權合稱「五陽祖師」	2018年《地球論理(世界各國)》第115頁 2019年《第十屆臺灣總督府檔案學術研討會論文集》〈從檔案看明治36年（1903）臺南廳之官廟調查概況〉第141頁 2021年《天律聖典大全譯註》第1299頁 2023年《《關尹子》公案徹底終結》未標頁碼 2024年《看懂道教》未標頁碼
2014年	偽造比干被周武王追封為「壟神（國神）」	2016年《日日見財！全台33家超人氣必拜財神廟開運指南》第10頁
2014年	偽造謝安稱為「謝府太傅」	2022年《清代噶瑪蘭寺廟興建與市街形成》第216頁
2014年	偽造比干稱為「守財真君」	2016年《日日見財！全台33家超人氣必拜財神廟開運指南》第10頁 2018年《解讀2018風水密碼》第34頁 2021年《台灣百神巡禮嚴選100尊神明，領略東方文化的神奇與奧秘》第105頁
2014年	偽造比干稱為「財祿真君」	2016年《日日見財！全台33家超人氣必拜財神廟開運指南》第10頁
2014年	偽造比干稱為「文財真君」	2016年《日日見財！全台33家超人氣必拜財神廟開運指南》第10頁
2014年	偽造比干稱為「增福真君」	2016年《日日見財！全台33家超人氣必拜財神廟開運指南》第10頁
2015年	偽造蓮池祩宏、紫柏真可、憨山德清、蕅益智旭合稱「蓮柏椒蕅」	以下林姓作者電子書 2019年《般若心要》未標頁碼 2019年《圓滿覺悟》未標頁碼 2019年《學佛指南》未標頁碼 2019年《亂世好修莊子禪》未標頁碼 2019年《你真的讀懂老子道德經》未標頁碼 2020年《跟著大師學易經》未標頁碼 2021年《蕅益大師教淨土法門》未標頁碼 2022年《唯識心要》未標頁碼 2022年《開悟在楞嚴》未標頁碼 2024年《唯識觀心》未標頁碼 2023年《都市養生Urban Health》第390頁 2024年《看懂中國及藏傳佛教》未標頁碼 2024年《隱元隆琦──日本黃檗宗初祖》第59頁
2016年	偽造宗教術語「海德堡探題」	2022年《焚書：遭到攻擊與在烈焰中倖存的知識受難史》第282頁
2016年	偽造宗教術語「路德小探題」、「路德大探題」	2023年《論點‧西洋史學：一本掌握！橫跨世界五大洲的歷史學關鍵課題》第14頁
2016年	偽造宗教術語「天主教探題」	2020年《建築設計：涵構與理路》第132頁 2023年《宗教超圖解：100張圖秒懂世界信仰文明與神祇知識》未標頁碼
2016年	偽造黃阿祿嫂稱呼「艋舺大檀越」	2021年《臺灣文獻季刊》72卷4期「臺灣軟身媽祖神像的製作與展演—以艋舺啟天宮、白沙屯拱天宮為例」194頁
2016年	偽造熟語「要生意，找顏李」	2024年《末代女礦工》第6頁
2017年	虛構歷史人物「公沙曉」	2022年《追溯近現代中國起源與歷史第二章（下）》第75頁
2017年	偽造張仙稱為「桂宮廣應善利育嗣賜子真君」	2022年《圖解台灣行業神明圖鑑台南體傳統工藝》第245頁
2017年	偽造管輅稱為「觀相真君」	2018年《地球論理(世界各國)》第310頁
2017年	偽造李白稱為「太白先師」	2019年《華人社會與文化》第74頁
2017年	偽造孫思邈稱為「天醫妙應廣援善濟真君」	2022年《圖解台灣行業神明圖鑑》第59頁 2023年《衣冠南渡》第120頁 2024年《看懂道教》未標頁碼
2017年	偽造文昌帝君稱為「七曲山雷澤神龍濟渡大王」	2021年《天律聖典大全譯註》第565頁
2018年	偽造玉皇大帝稱為 「太上開天執符御歷含真體道金闕至尊無上至尊自然妙有彌羅至真玉皇大天尊昊天玄穹高上帝」	2021年在《天律聖典大全譯註》1192頁 2022年《神明便利商店》第41頁
2018年	偽造玉皇大帝稱為「昊天玄穹上帝」	2021年《天律聖典大全譯註》第1323頁
2018年	偽造六福是「名、利、健康、長壽、善終、多子多孫」、「名、利、壽、安康、善終、多子多孫」	2021年《台灣百神巡禮嚴選100尊神明，領略東方文化的神奇與奧秘》第75頁 2021年《客家民俗禁忌》第128頁
2019年	偽造宗教術語「結盟宗 」	《謝選駿全集》236卷第658頁 2020年商周出版《紅與黑（法文全譯本）》未標頁碼 2024年《看懂基督教》第103頁
2019年	偽造宗教術語「盎格魯宗」	《謝選駿全集》236卷第658頁 《謝選駿全集》327卷第38頁 2024年《寫在歐洲行起飛前：36個旅途中的生活文化與行程規劃答疑》第86頁 2024年《看懂基督教》未標頁碼
2020年	偽造朱衣神稱呼「文選帝君」	2024年《看懂道教》未標頁碼
2020年	偽造呂洞賓稱呼「文尼帝君」	2024年《看懂道教》未標頁碼

--Outlookxp（留言） 2024年12月19日 (四) 07:52 (UTC)

@Outlookxp：或許你可以考慮建一個專門的頁面來説明？Sanmosa _蚌埠 2024年12月19日 (四) 10:42 (UTC)

我有建了，放在只是為了增加google能見度。--Outlookxp（留言） 2024年12月19日 (四) 11:03 (UTC)

啊，我的意思是建一個專門的頁面或章節來放類似上面的表格的東西，表格化的資訊比較方便社羣對照與具體引述，比如我要提及被虛構出來的人物「公沙曉」時我可以説「見LTA:QY『公沙曉』項」之類的。Sanmosa _蚌埠 2024年12月19日 (四) 11:18 (UTC)

最好是能知會原作者或出版社，並提醒他們慎防誤用。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月19日 (四) 20:49 (UTC)

簡直觸目驚心，氣得我血壓都高了，感謝您一直辛苦地排雷。--BigBullfrog（𓆏） 2024年12月23日 (一) 16:27 (UTC)

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

建於西夏的建築物歸為「宋朝建築物」是否合適

西夏與宋朝同時期。建於西夏的建築物，如建於西夏晚期的宏佛塔，歸為「宋朝建築物」合適嗎？--紺野夢人 2024年12月19日 (四) 05:31 (UTC)

我認為歸類為「建於宋時代的建築物」應該合適（畢竟國務院就是這麼表示的），但「宋朝」可能不太好。--自由雨日🌧️❄️ 2024年12月19日 (四) 05:35 (UTC)

上級分類就叫「宋朝」，沒有「宋時代」這種分類。--—— 紅渡廚（留言・貢獻） 2024年12月19日 (四) 06:05 (UTC)

維基百科分類？沒有可以建啊。--自由雨日🌧️❄️ 2024年12月19日 (四) 06:32 (UTC)

之前有人把「X代」的分類統一改成了「X朝」，比如Special:Diff/61855120。--—— 紅渡廚（留言・貢獻） 2024年12月19日 (四) 06:45 (UTC)

為什麼不新建一個「西夏建築物」，這樣不是更直觀、更簡潔、更不會產生其他衍伸問題?--Djhuty（留言） 2024年12月19日 (四) 08:11 (UTC)

分類:西夏建築，已經有了。--—— 紅渡廚（留言・貢獻） 2024年12月19日 (四) 08:31 (UTC)

《維基百科:非原創研究》：維基百科不是存放原創研究或原創觀念的場所。在維基百科裡所謂原創研究或原創觀念，指的是未發表的事實、爭論、觀點、推論和想法；以及對已發表材料進行的未發表分析、綜合或總結，並產生或暗示新的結論。維基百科編者不負責、也不應該負責對來源進行分析、綜合或總結。來源寫西夏，條目就寫西夏；來源寫宋朝，條目就寫宋朝。就這麼簡單。--—— 紅渡廚（留言・貢獻） 2024年12月19日 (四) 06:29 (UTC)

來源寫的好像不是宋朝，而是宋時代？--自由雨日🌧️❄️ 2024年12月19日 (四) 06:33 (UTC)

我個人認為這與說「愛因斯坦出生於光緒五年」類似，如果能接受這種說法，「西夏建築物建於宋朝」就可以，如果不能接受，就不可以。-游蛇脫殼/克勞棣 2024年12月19日 (四) 09:12 (UTC)

學習了 只是在實際習慣中，很少有人會把西夏的遺蹟說為西夏，更喜歡說北宋南宋。當然這種習慣並不準確，尤其不適用於百科。只是嘛，話雖如此實際做起來還是容易編纂出錯。頭疼呢。--花開夜（留言） 2024年12月21日 (六) 20:48 (UTC)

西夏在後期甚至已經不是宋朝的藩屬，這種描述顯然是不合適的。Sanmosa _蚌埠 2024年12月19日 (四) 09:52 (UTC)

類似地有：南詔—唐朝，大理國—宋朝。--Kcx36（留言） 2024年12月19日 (四) 12:31 (UTC)

「宋朝建築物」有歧義，我認為指「宋朝統治地區內建造的建築物」較好。若此分類指「時期」而非「地區」，那是否美國白宮也要列入「清朝建築物」分類？後者違反直覺，要分類也應該稱「與清朝同時代的建築物」。--歡顏展卷（留言） 2024年12月19日 (四) 18:35 (UTC)

「宋朝」其實有兩個意思，一個是中國國家「宋（朝）」，一個是中國歷史時段「宋代」（即所謂「宋時代」）。如果「宋朝」前者涵義不宜用，個人認為可斟酌考慮使用「宋代」。至於何者應歸屬之，應考量現代分類情況，如大陸當局既將上述文化資產分類於「宋時代」，則未嘗不可用「宋代建築物」統一收納。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月24日 (二) 10:14 (UTC)

(！)意見，我認為這裡必須說明白一件事情。舉個例子來說，任何一個接受過義務教育的人，都應該知道1+1=2。但如果，有個來源說1+1＝3，或者1+1＝4，這種明擺着存在基礎性錯誤的來源，我完全同意把它們摒棄，堅決不予採納於條目中。但是，對於宋朝還是西夏，這應該是學者們才需要去考慮的學術性問題，而我們是維基百科，是維基百科的編者，我們要做的就是，不帶任何偏見地，將所有寫在來源中的內容，如實記錄在條目中，這就可以了。而且，本案中的來源，作者是中華人民共和國的國務院，是一國的中央政府，國務院的背後是有國家文物局，以及大量文物專家在為這個來源背書的，權威性不可謂不高。我們沒有理由對國務院的來源不予採納。農夫山泉有句話說的好：我們不生產水，我們只是大自然的搬運工。而我們維基百科編者則是：我們不生產條目，我們只是來源的搬運工。—— 紅渡廚（留言・貢獻） 2024年12月25日 (三) 03:26 (UTC)

@紅渡廚：國務院可以作為可靠來源，但沒有排除其他觀點的權威性，還是要看不同的可靠來源的觀點，否則這是一種違反中立性的「地域中心」，以中華人民共和國政府的觀點排除其他可靠來源的觀點。--歡顏展卷（留言） 2024年12月25日 (三) 04:14 (UTC)

請你不要二極管，我說要採納國務院的來源，但我沒有說不要採納西夏的來源。--—— 紅渡廚（留言・貢獻） 2024年12月25日 (三) 04:18 (UTC)

(！)意見，同時，《維基百科:中立的觀點》指出：在一個特定主題中，具有可靠來源的可供查證觀點之間並不一定完全一致，它們可能會相互矛盾，而保持中立的觀點正是解決這種矛盾的方法。當同一主題存在多個或相互牴觸的觀點時，應平等表達每一個觀點。不應讓對一個特定觀點的介紹占有不合理的比重，或聲稱某特定觀點為「真理」。如此可讓讀者接觸到各種重要且已發表的觀點，而不僅僅是最流行的那一個。同樣地，也不應斷言各種不同觀點之中，某種觀點（不論其是否最流行的觀點或中間觀點）為正確，並把除前述以外的觀點當成只為貶損而提及。我們應該讓讀者形成他們自己的意見。維基百科及其編者不負責選擇哪一種觀點為絕對真理，維基百科只負責展示所有的觀點。—— 紅渡廚（留言・貢獻） 2024年12月29日 (日) 05:51 (UTC)

分類可能要折衷「選取」一種看法，因為其一大本質是維護追蹤，也不可能展示所有觀點。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月30日 (一) 16:38 (UTC)

回顧歷史來看，主要分裂時期列舉如下：東周（春秋戰國），三國，東晉十六國，南北朝，五代十國，宋遼金夏。

這樣一看，也就東晉和宋朝有這種用單一政權的名字來命名一個時代的情況，在其他時代沒有（其實東周也算，但是沒什麼人在乎周王畿）。因此我們或許可以就個案來做個決定。

或許我們可以設置一個「宋遼金夏時期」，但是感覺略顯複雜。強行把「宋朝」和「宋代」分開來表達朝代和時間的做法，我雖然覺得有些文字上的道理，但是鑑於兩者混用的情況，我不建議這麼做。

但至少，我覺得把西夏的文物簡單歸類於「宋朝」是有問題的。西夏最多也就是個藩屬國，而朝鮮長期也是中原王朝的藩屬國，請問有誰把朝鮮文物歸進中原王朝的？我理解國務院這麼寫主要是按照時間分段，但是如果能更嚴謹些也不能迷信權威。--The Puki desu（留言） 2025年1月1日 (三) 17:12 (UTC)

關於「西安市市長列表」一條目的名稱問題

雖然本條目標題為「西安市市長列表」，但實際上列出的內容不僅包括歷任（民國和人民共和國時期的）西安市市長，還涵蓋了1930年至1944年西安市政府廢立期間的西京籌備委員會委員長、西安市政處處長，以及1949年中共接管西安後的西安市軍事管制委員會主任和文革時期的革命委員會主任。所以本條目到底是更名為「西安市行政首長列表」，還是保留現有名稱，我希望社群能在這裡討論一下。--Nishino⭐Asuka 2024年12月19日 (四) 21:12 (UTC)

「市長」設立以前的職位可以作為前身來敘述，標題使用「市長」可能仍然可行。如果從一致性來考慮可能需要一併討論分類:中國市長列表下各條目。--紺野夢人 2024年12月20日 (五) 00:20 (UTC)

如果條目標題使用「市長」一詞可行的話。那目前這個條目的架構，也就是列舉的項目依然是以「市長」為主（比如西安市政府市長、西安市人民委員會市長等等），而以其他行政首長，也就是我上面列舉的那些例子為輔，並在對應的子標題中用「附」這個字來和主項目做區分。這樣做難道也是可行的？不需要考慮標題和列表項目之間的完全一致性？--Nishino⭐Asuka 2024年12月20日 (五) 15:44 (UTC)

如果要保證一致性的話，可以用Sanmosa建議的「行政首長列表」作為標題。不過我更傾向於認同Nishino Asuka的方法用「附」的方式標註非市長名號的行政首長。--—ФрадонСтар|^{Меня зовут Хайшэньвай} 2024年12月24日 (二) 06:22 (UTC)

其實就此例而言，我更傾向於維持現名。Sanmosa _腦洞大開 2024年12月24日 (二) 06:23 (UTC)

@FradonStar、Sanmosa：如果維持現名更好的話，那就維持現名吧。我覺得這樣做也是沒問題的。--Nishino⭐Asuka 2024年12月24日 (二) 06:26 (UTC)

丹麥語譯寫導則

@BigBullfrog：您在網上能搜索到丹麥語譯寫導則的徵求意見稿嗎？我注意到您及其他編輯已在或正在修改丹麥的市區條目及車站條目的名稱。地名辭典等權威來源里一般只收入各國各級聚居地（一般到基層政權一級，有時也會到村一級）的譯名，這些譯名通常是採用音譯的。但有時也會採用意譯的。

我在網上找到了芬蘭語譯寫導則的徵求意見稿。裡面細則5.1.2規定「明顯反應地理實體特徵的專名宜意譯」，例子有「Kallioniemi-岩石半島」（而不是音譯為「卡利奧涅米」，如果該名是個市鎮的話，則肯定該音譯），及「Koivusaari-白樺島」（如果是一個市鎮的話肯定該音譯為「科伊武薩里」，同名地鐵站我已按此譯為白樺島站了）。細則5.2.1則規定「通名宜意譯」，例子有「Aurajoki-奧拉河」（如果某個市鎮以河為名的話則會譯為「XX約基」），及「Haltiatunturi-哈爾蒂亞山」。前面這些例子都是自然地理地名，但問題是這樣的地名也會延申到市鎮之下的市區名、街道名、車站名里。這種情況下我覺得能意譯的都應該意譯，何況在芬蘭還有另外一種官方語言瑞典語，而芬瑞地名里有很多都是互相意譯而來的，因此有時候不管源語言是芬蘭語或瑞典語，意譯過來都是一樣的。我試着按照芬蘭語譯寫導則意譯了一些芬蘭地名（zh:Category:赫爾辛基市區、zh:Category:赫爾辛基地鐵站），感興趣的話請檢查並在有問題時一起討論。

這讓我聯想到丹麥的地名可能跟瑞典地名（及芬蘭地名）類似。如果丹麥語譯寫導則也有類似規定的話，那麼厄斯特布羅也許就可以譯為「東橋（區）」，諾勒布羅站也可以譯為「北橋站」，旁邊的街道譯為「北橋街」等等。--萬水千山（留言） 2024年12月22日 (日) 01:13 (UTC)

@BigBullfrog：連同丹麥語地名譯寫導則徵求意見稿在內的網上資源冷門的譯寫規則我傳Dropbox了（不斷更新中），您可自取。問題稍後作答。--BigBullfrog（𓆏） 2024年12月22日 (日) 09:02 (UTC)

@TuhansiaVuoria（BigBullfrog你咋自己ping自己了？）。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 01:55 (UTC)

手誤了，這下尷尬了…--BigBullfrog（𓆏） 2024年12月23日 (一) 01:57 (UTC)

沒事的，既然我問了問題，肯定會不是過來看看。:) 不過謝謝了！--萬水千山（留言） 2024年12月23日 (一) 07:29 (UTC)

樂見中國大陸的譯寫導則開始認可意譯。一般而言，意譯較不會產生地域差異的問題，因為一個詞語在不同地方的讀法不影響詞義。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 02:29 (UTC)

好像一直認可的吧？--自由雨日🌧️❄️ 2024年12月23日 (一) 02:37 (UTC)

@自由雨日：見上，現時一般情況下是不認可的，這也是我一直以來覺得中國大陸的翻譯規則反直覺的一點。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 03:01 (UTC)

下載了BigBullfrog給的鏈接中的一些文檔，裡面有一個《外語地名漢字譯寫導則》應用指南的文檔，值得一讀。好像是針對99年版的國標，不知有沒有更新的版本。不過這些說明應該是通用的，況且99版和09年版的國標可能只是一些細微的更新。不管怎樣，例如在英語的指南部分是這麼說明的（我精簡了一下）：

地名專名一般音譯是總原則，但歷史上不乏有些地名被意譯了。意譯的地名不宜過多，且應儘量避免。地名譯寫的主要作用在於方便人們交流，知其音知其名足以。地名漢字譯寫時，特別強調要對本條紋中「明顯」兩字的理解。所意譯的地名應是較大的，而且譯名確實要與地名指稱的地理實體特徵相吻合。例子有「紅海」、「長島」。

不過在小語種如丹麥語給出的例子為「熊島」，芬蘭語導則中的例子為「岩石半島」和「白樺島」。這些好像也不是什麼大地名，且熊島上可能不再有熊，芬蘭到處都是岩石和白樺，白樺島上可能大部分是松樹。再以「白樺島/Koivusaari」為例，如果該名指代的是島嶼的話，saari作為通名肯定要意譯為「島」，在「科伊武島」和「白樺島」兩個譯名中，似乎「白樺島」更佳。但如果Koivusaari作為一個行政單位（如最低的行政單位市鎮）的名稱時，則肯定要全音譯為「科伊武薩里」。但問題是當這個名字從島嶼名延伸至市區或居民小區，甚至被採用為車站名時該如何翻譯為好。我看丹麥的一些市區及車站條目原先的名稱是採用意譯的，現在正在被調整至音譯名。我也意譯了一些赫爾辛基的市區名和地鐵站名。所以希望社群關注並討論一下。--萬水千山（留言） 2024年12月23日 (一) 08:39 (UTC)

@Sanmosa：不是「開始」，其實大陸歷來規範一直都有意譯相關規定，上文提到的意譯規定早在快三十多前的導則里就有了，不是新加的，也已有不少意譯案例（例：紅軍城、英雄港、三河城、大急流城、解放者聖馬丁將軍鎮），只不過對意譯有限定罷了，不能啥都亂意譯一氣。此外限定意譯也不是大陸特色，台灣方面對音譯意譯的處理和大陸也是差不多的，實際案例也是如此，只不過大部分人不遵循罷了。--BigBullfrog（𓆏） 2024年12月23日 (一) 08:51 (UTC)

但無論如何，意譯適用範圍的擴大於我而言是一件好事情。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 09:01 (UTC)

但總歸要杜絕規定之外的過度濫譯。--BigBullfrog（𓆏） 2024年12月23日 (一) 16:25 (UTC)

提議將伊爾汗國的條目標題移動到伊利汗國

關閉：

提案人已被證實為夏土賢的傀儡，已被封禁。Пусть от победы☆к победе ведёт! 2024年12月26日 (四) 04:13 (UTC)

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

---

伊爾汗國現行的條目標題並非常用譯名，建議移動到學界的通用譯名伊利汗國。--Custthedown（留言） 2024年12月24日 (二) 02:35 (UTC)

原來被封鎖了換了小號來，又來一個所謂「非常用譯名」提案。雖然此人被封鎖已經不能再回應，但是還是說一句，至少在台灣，教科書用的名字都是「伊兒汗國」，沒聽過所謂「伊利汗國」，我還伊莉討論區呢。就算真的在大陸是那樣說，最多就是調整字詞轉換，否則先到先得。——George6VI（留言） 2024年12月24日 (二) 03:56 (UTC)

在中國大陸的讀秀平台搜索，「伊兒汗國」371條，「伊爾汗國」186條，「伊利汗國」363條，不管大陸模式用「伊兒」還是「伊利」，也用不了「伊爾」。這種使用狀況差不多的名字，不存在所謂「非常用譯名」的問題，我同意先到先得的翻譯模式。

真是搞笑，被封了還秉性不改，一邊在主賬號保證自己不會再隨意發表名為「自己內心的想法」實則擾亂的議題，一邊把自己當初沒被管理員封禁的漏網傀儡重新拿出來又發表這種提案，真是難繃。--—ФрадонСтар|^{Меня зовут Хайшэньвай} 2024年12月24日 (二) 06:14 (UTC)

---

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

疑似又有老師布置「編輯維基百科」作業？

Talk:亞洲中心主義頁面近期有多個新用戶加入疑似使用大語言模型生成的內容。其中，User:WANGYIZHE1124在多個其他條目中加入疑似使用機器翻譯的內容。其他參與編輯Talk:亞洲中心主義的用戶也有類似行為。根據其用戶名，猜測此類編輯行為的原因是再度有老師給學生布置了「編輯維基百科」作業。是否有必要對此深入調查？--ℚ𝕦𝕒𝕤𝕚𝕓𝕠𝕠𝕤𝕥^{𝕥𝕒𝕝𝕜} 2024年12月24日 (二) 04:18 (UTC)

@Quasiboost：此為韓國大學的教育專案，如有任何意見可至佈告版提出。另外，就個人所知，導師有提醒學生切勿使用機器翻譯及 LLM，但似乎有部分學生沒有理會。謝謝。--SCP-0000（留言） 2024年12月24日 (二) 05:01 (UTC)

請求協助評級

請見此--Gaolezhe（留言） 2024年12月25日 (三) 11:42 (UTC)

「五代十國」與「五代」、「十國」分類

「五代十國」即（後）梁、（後）唐、（後）晉、（後）漢、（後）周先後「五代」與同時期的（楊）吳、（南）唐、吳越、閩、（前）蜀、（後）蜀、荊南、（馬）楚、（南）漢、（北）漢「十國」。本站有必要在上層的「五代十國」與下層的「後梁」、「南唐」等分類之間建立「五代」與「十國」這樣的中間分類（例如分類:五代十國的州>分類:五代的州與分類:五代十國的州>分類:十國的州），還是只需要上層及下層分類，將「五代」與「十國」這樣的中間分類重新導向至「五代十國」分類（例如將分類:五代的州與分類:十國的州與重新導向至分類:五代十國的州）？--紺野夢人 2024年12月27日 (五) 13:00 (UTC)

總統繼位順序

因為韓國出現了罕見的代總統的代總統，所以很好奇韓國的總統繼位順序。請問相關資訊記載在哪個條目裡？如果沒有，應該要記載在哪個條目裡？ 我知道美國總統繼位順序在條目中，請問還有其他國的總統繼位順序被寫進去嗎？是否能弄個各國領導人繼位順序的特色列表？--2603:8000:500:FB00:8CA:FB5E:1076:44E1（留言） 2024年12月29日 (日) 03:03 (UTC)

韓國總統繼位順序在韓文維基有，各國繼位順序應在其自身條目寫出即可--Kanshui0943（留言） 2025年1月1日 (三) 14:52 (UTC)

電影技術分類應該改為影視作品拍攝技術

Category:電影技術下大部分技術都是影像拍攝技術，不限於電影，劇集、廣告、音樂視頻等都能運用。應該改名，如「影視作品拍攝技術」一類名稱，移離電影分類之下，移到更高母分類。--Factrecordor（留言） 2024年12月29日 (日) 08:13 (UTC)

除非能勸說其他語言的社群更名不然沒戲。（該分類與其他語言的分類有關聯）----甜甜圈認為2025年是朝鮮和台灣最惡臭的一年 2024年12月29日 (日) 08:30 (UTC)

為什麼一定要跟其他語言的一樣？--PC 2024年12月31日 (二) 03:55 (UTC)

因為維基數據有將這些部分關聯。----甜甜圈認為2025年是台灣最惡臭和木毛的一年 2024年12月31日 (二) 04:35 (UTC)

這不是理由。--自由雨日🌧️❄️ 2024年12月31日 (二) 04:37 (UTC)

可改。無需與外文分類詞義對應；原本就與外文詞義不盡相同。--— Gohan 2024年12月31日 (二) 02:30 (UTC)

改，理由同上。--PC 2024年12月31日 (二) 03:57 (UTC)

初步來看，「影視技術」[9][10]和「電影技術」[11][12][13]這兩個稱呼皆存在，而「Cinematic」直譯是電影（的），個人認為或可保留「電影技術」這稱呼？另外，個人認為可以創建一個「電影/影視拍攝技術」的子分類。謝謝。--SCP-0000（留言） 2024年12月31日 (二) 04:43 (UTC)

合併請求

關閉：

已全部重定向處理。Jeffchu2014（留言） 2024年12月31日 (二) 19:19 (UTC)

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

---

金鐘獎一般節目類剪輯獎及金鐘獎非戲劇類節目剪輯獎併入金鐘獎節目類剪輯獎

金鐘獎一般節目類導播獎及金鐘獎非戲劇類節目導播獎併入金鐘獎節目類導播獎

金鐘獎一般節目類導演獎及金鐘獎非戲劇類節目導演獎併入金鐘獎節目類導演獎

金鐘獎一般節目類攝影獎及金鐘獎非戲劇類節目攝影獎併入金鐘獎節目類攝影獎

金鐘獎一般節目類燈光獎併入金鐘獎節目類燈光獎

金鐘獎一般節目類節目創新獎併入金鐘獎節目類節目創新獎

金鐘獎一般節目類美術設計獎併入金鐘獎節目類美術設計獎

金鐘獎一般節目類聲音設計獎併入金鐘獎節目類聲音設計獎

金鐘獎科學節目獎得獎列表併入金鐘獎自然科學紀實節目獎得獎列表

以上為獎項更名，實際上為同一獎項--2401:E180:8D03:B747:2416:DDD1:EFB4:3BC4（留言） 2024年12月29日 (日) 08:41 (UTC)

我代為分一下行，不然大家真的會看得很辛苦。Sanmosa _蘭絮 2024年12月29日 (日) 09:26 (UTC)

看了一下編輯歷史，標題帶「一般」的條目均為同一個ip用戶所創建--Shawwww（留言） 2024年12月29日 (日) 15:09 (UTC)

---

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

上海「兩鐵合併」請求

前序討論見Talk:中春路站#合併建議，目前包括：

• 中春路站 (市域鐵路) + 中春路站 (地鐵) → 中春路站
• 景洪路站 (市域鐵路) + 景洪路站 (地鐵) → 景洪路站
• 康橋東站 (市域鐵路) + 康橋東站 (地鐵) → 康橋東站
• 浦東1號2號航站樓站 (市域鐵路) + 浦東1號2號航站樓站 (地鐵) → 浦東1號2號航站樓站

市域康橋東我提了DYK的，形式上能不能做成刪消歧義把市域挪進去？這樣不要影響投票，但是刪除頁面就需要管理員操作了。--Nanhuajiaren（留言） 2024年12月29日 (日) 14:06 (UTC)

關於最近某些族群模板的格式問題

其實我有點難以理解耶！舊的格式用的好好的，頂多在該地區族群模板補充介紹來自該地區的海外僑民，這可以理解，而且舊版用民族分的，民族差異是天生的，無可厚非，為什麼新版非得要刻意用相當晚近、人為的國籍概念區分？什麼叫「外來人口」？除了最開始先定居該地區的原住民族外，其他人對於該地都是外來人口吧！

真的沒有必要用「外來人口」，如此具有相當具有族群歧視意味的分類，可以多多去找尋和補充新的資料，例如：利用翻譯器和中外詞典從中文和非中文維基、網路資料、其他資料中，補充中維沒有的信息。

例如：該地區的族群模板，也可以補充上對於該地區歷史民族的資料，而不是一昧的重新改寫這些已知信息，並自以為是的簡化某些重要內容，這對於維基百科是相當有害而無益的行為。

貢獻的方式有很多，但是改寫已知內容，而且顯然是沒有仔細的研究過僅僅為寫而寫的內容，就好像AI合成文章那樣，是蠻low的行為。

Nkywvuong（留言） 2024年12月30日 (一) 15:01 (UTC)

是否應在中文條目中介紹外文詞源？

中文維基百科很多條目中有「詞源」一段。有些條目的這一段介紹了中文詞源（例如犬儒主義和涅槃），但有些條目的這一段只介紹了外文詞源（例如虛無主義）。我知道很多條目是翻譯自外文維基百科（尤其是英文維基百科），但是中文維基百科是否需要介紹外文詞源？--GUT412454（留言） 2025年1月1日 (三) 16:40 (UTC)

我認為，應該看中文可靠來源在討論這一概念時，是否會介紹以及如何介紹（中文/外文）詞源。通常非專有名詞/專科術語的詞源是詞典內容而非百科內容，一般完全不需介紹；而一些專有名詞或專科術語的詞源則可能是百科內容。其中一些直譯自外文的中文詞彙，確實中文可靠來源也常常會對外文詞源作介紹，例如「精神分裂症」，這時候介紹外文詞源顯然是必要的。但如果僅是翻譯自外文條目或參考外文可靠來源（而非參考中文可靠來源撰寫），則確實要考慮將其中的外文詞源內容翻譯過來是否有必要——尤其是中文詞彙並不譯自外文時。--自由雨日🌧️❄️ 2025年1月1日 (三) 16:44 (UTC)

《中美建交公報》中介紹acknowledge的詞源是必要的，因為該詞在《上海公報》中譯成「認識到」，而建交公報中譯成「承認」，如何準確翻譯就牽涉到詞源。ac-（in acknow "to confess knowledge of,"）+ knowledge，意為「表示知道」。用於法律上，意義包括"to make known to a sender or giver the receipt of (what has been sent or given) or the fact of (one's having received what has been sent or given)"，如 "acknowledge receipt of a letter"。這不是簡單翻英漢字典就能決定的。--歡顏展卷（留言） 2025年1月1日 (三) 17:07 (UTC)

若該詞原始於中文以外，則可斟酌予以介紹。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年1月2日 (四) 11:31 (UTC)

應考慮詞源對解釋本條目是否有幫助。例如蘋果條目顯然沒有必要解釋apple，而蛇果就很有必要解釋英文詞源了。--The Puki desu（留言） 2025年1月2日 (四) 15:41 (UTC)

能用分類替代嗎？

1950年中國大陸電影列表、2000年美國電影作品列表、2007年美國電影作品列表、2009年美國電影作品列表、2019年美國電影作品列表、2021年美國電影作品列表、2022年美國電影作品列表、亞美尼亞電影作品列表、中國電影作品列表、1985年台灣電影作品列表、1986年台灣電影作品列表、1991年台灣電影作品列表、2006年電影作品列表、2008年電影作品列表、2010年電影作品列表、2011年電影作品列表、2012年電影作品列表、2013年電影作品列表、2014年電影作品列表、2015年電影作品列表、2016年華語電影列表、2017年華語電影列表、2018年華語電影列表、2019年華語電影列表、2021年華語電影列表--101.12.31.171（留言） 2025年1月2日 (四) 09:24 (UTC)

顯然分類較列表缺失了信息。--Teetrition（留言） 2025年1月2日 (四) 09:50 (UTC)

注意LTA:青蛙—— Matt Zhuang表示有事按「此」留言 2025年1月2日 (四) 09:53 (UTC)

其他

在本地啟用安全投票及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 ( [email protected] ) if and when consensus is reached. Thank you!--JSutherland (WMF)（留言） 2024年10月17日 (四) 20:07 (UTC)

---

翻譯：

大家好！我是Joe Sutherland，來自維基媒體基金會信任與安全團隊。過去，我們了解到貴社群對使用SecurePoll進行選舉有一定興趣——或許你們已經通過votewiki進行了相關選舉。我們目前正在研究如何使這一功能能在本地社區中啟用，以允許社群自行舉辦選舉。這將需要在貴項目上啟用「electionadmin」權限，該權限允許訪問一些敏感信息。

因此，貴社群可能需要進行一次請求評論（或類似流程）來確定是否有共識啟用此功能。為幫助此類討論，我們在一個元維基頁面上提供了更多關於啟用該權限對貴社群意味着什麼的資訊。

如果貴社群經過討論並決定推進此事，信任與安全團隊願意提供支持——請在達成共識後通過電子郵件( [email protected] )告知我們。謝謝！

譯者：即請秋安 ZhaoFJx_(論•簽) 2024年10月17日 (四) 20:25 (UTC)

---

electionadmin是幹嘛的？元維基中的介紹，供參考：

electionadmin is a right that allows users to set up elections with SecurePoll. However, crucially, it allows these users to view voter data, which includes CheckUser-level IP and user agent information for all voters. This is to allow detection of duplicate votes. Its sensitive nature means it should be handed out with extreme caution and only to trusted users (for instance, those who already possess the CheckUser right).

—即請秋安 ZhaoFJx_(論•簽) 2024年10月17日 (四) 20:31 (UTC)

TLDR：electionadmin可以看到所有投票者的IP及UA信息，應高度謹慎授權，並建議賦權給本地CU權限持有者。--Hamish T 2024年10月18日 (五) 04:31 (UTC)

已更改標題以準確描述。--Hamish T 2024年10月18日 (五) 03:39 (UTC)

目前是OS和Steward監票，他們在votewiki的權限是不是和electionadmin一樣？ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月18日 (五) 05:36 (UTC)

Yes，不過本地OS在該站是臨時權限。未來若打算維持是CU和OS負責監票，就可以直接把監票權限直接給CU和OS。--路西法人 2024年10月18日 (五) 06:33 (UTC)

	現狀	本地啟用後
準備工作	-	本地請求監管員授予相關人士"electionadmin"權限
創建投票	T&S在votewiki創建	electionadmin在本站創建
生成名單	沒有變化
投票	沒有變化
監票	T&S授予相關人士"electionadmin"權限，划去應作廢的票	"electionadmin"划去應作廢的票
宣布結果	沒有變化

以上是我個人對「本地舉辦安全投票的理解」，其中electionadmin可以在選舉開始前在m:SRP上臨時授予給相關人士，避免高級權限帶來的隱私問題。在我看來，本地舉辦可以讓界面變成中文；創建投票不再強依賴於T&S，不會有什麼「等聖誕假期」這種過去遇到的問題；不再需要在phabricator創建任務，社群參與度更高；界面上有什麼詞寫錯了可以更快的修復：目前還沒想到明顯的缺點，可能是會有人質疑投票存在被本地干預的風險（相較於votewiki）？ Stang^★ 2024年10月19日 (六) 03:34 (UTC)

votewiki:Special:UserGroupRights：votewiki上electionadmin僅有「偷看選民信息」(securepoll-view-voter-pii)和「破壞用戶界面」(editinterface)兩個權限，「創建投票」權限(securepoll-create-poll)只有electcomm和staffsupport擁有。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月23日 (三) 01:49 (UTC)

小課堂時間，咱來解釋一些容易混淆的概念：

我們這裡有四個概念，scrutineer（監票員）、Election administrators（選舉管理員）、electionadmin、electcomm

• 監票員是在一場選舉之中對所有選票進行檢查的人，他會負責查看投出選票的人是否是符合標準的，這張選票是不是重複的（比如多個分身賬號、傀儡投票什麼的）；
• 選舉管理員是創建並設置投票的人，目前T&S的那兩位就是「選舉管理員」；
• electionadmin是一個用戶權限組，我們的監票員們需要這個權限組來查看那些PII，來判斷某張選票是否符合標準；
• electcomm則是另一個權限組，這個權限組是給選舉委員會的成員準備的，T&S的人說這個權限組設計之初是為了方便理事會選舉的一些事項。它在實際中跟「electionadmin」這個組沒什麼區別。

source，希望有幫助 Stang^★ 2024年10月23日 (三) 02:19 (UTC)

感謝，但是暈暈。所以監票員（scrutineer）和選舉管理員（Election administrators）在技術上不存在？electionadmin 的 user group right 包括 securepoll-create-poll 嗎？ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月23日 (三) 02:57 (UTC)

可以這麼理解；在votewiki上不，但是根據這裡的描述，本地是會有的。換個方法解釋一下：在votewiki上，electcomm負責創建和配置選舉，並給一些人electionadmin的權限，後者會去做監票的工作；本地如果啟用，electionadmin會負責創建和配置選舉，以及負責監票。這麼說的話，我建議把這個新的權限組翻譯成「選舉管理員」。@魔琴： Stang^★ 2024年10月23日 (三) 03:15 (UTC)

明白。感謝。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月23日 (三) 03:29 (UTC)

若本地啟用安全投票，即可廢去現行被迫定期集中舉行申請之制度，回復原先之自由提名制，或得促進社群成員申請管理人員。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年10月19日 (六) 10:45 (UTC)

或許也可參考英維搞自由提名與集中申請制度並行。--人間百態,獨尊變態(討論) 2024年10月20日 (日) 12:54 (UTC)

長期授予監督員監票權限會不會有問題？是否需要重提取回CU權限？ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月21日 (一) 18:04 (UTC)

也沒說一定要長期授予啊，如果社群對長期授予有疑慮完全可以改為臨時權限。--人間百態,獨尊變態(討論) 2024年10月22日 (二) 14:18 (UTC)

---

隨便先列了幾條文字以推動討論。

現行條文 Wikipedia:申請成為管理人員： 若本地有兩名或以上監督員在安全投票開始前表示願意監票，則由願意執行監票工作的監督員與其他監管員共同協助監票。若本地能夠執行監票工作的監督員不足兩人，則由監管員獨自負責監票。

提議條文 監選員（electionadmin，暫譯）權限應僅授予用戶查核員、監督員、監管員。 若本地有至少兩名用戶查核員或監督員在安全投票開始前表示願意監票，則由願意執行監票工作的本地用戶與其他監管員共同協助監票，用戶查核員優先於監督員。若本地能夠執行監票工作的用戶不足兩人，則由監管員獨自負責監票。 投票開始前，應請求監管員授予本地負責用戶監選員權限。 投票結束後應及時除去權限。 監選員擁有以下權限： 編輯用戶界面(editinterface) 訪問投票者的個人可識別信息(securepoll-view-voter-pii)

既然是長期的制度性存在的用戶組我就將CU考慮進來了。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月23日 (三) 01:48 (UTC)

「選舉管理員」有可能是動賓短語，個人認為應該避免，所以擬了一個「監選員」譯名，也許有更好的。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月23日 (三) 03:35 (UTC)

其實權限不需要用一次去一次吧？如果是擔心CU隱私的話，electionadmin只能看到投票人在本次securepoll的信息，並不能用該權限直接去CU別人。另建議用腳註注釋下「個人可識別信息」 ——即請秋安 ZhaoFJx_(論•簽) 2024年10月23日 (三) 10:57 (UTC)

既為任務編組權限，如機器使用者般，則一般不應長期持有。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年10月23日 (三) 11:19 (UTC)

所以意思是每有選舉就要再申請/授予權限？--J.Wong 2024年10月27日 (日) 06:03 (UTC)

@Wong128hk：或者規定簽署隱私協議之行政員、監督員等可當然持有此權限，協助鋪張選舉，我覺得也符合本地未來可能情況。畢竟以後就不用強迫定期集體申請了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年10月27日 (日) 11:08 (UTC)

反正本地有SecurePoll後，用戶可以隨時申請成為管理人員，每次都授予／解除權限也太麻煩，electionadmin完全可以讓OS或CU長期持有。倒是如仲委會選舉未來該設eleccomm，就是每次選舉再每次授權了。--路西法人 2024年10月28日 (一) 04:29 (UTC)

建議譯為「選舉監察員」，符合漢語用例。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年10月23日 (三) 11:19 (UTC)

---

於Phabricator查看
編號T380020的工單

距上條留言已過三日，姑且總結一下討論。目前討論用戶基本就引入electionadmin用戶組達成共識，在是否允許簽署隱私協議的行政員和監督員長期成為electionadmin也基本得出結論，然對於electionadmin的譯名尚未有定論。當下討論用戶一共給出了三種方案，分別為Stang君提議的「選舉管理員」、魔琴君提議的「監選員」以及EricLiu君提議的「選舉監察員」。不知三位用戶可否進一步闡明一下選擇該譯名的理由。當然如果有用戶認為自己有更好的譯名方案也歡迎提出。--人間百態,獨尊變態(討論) 2024年10月31日 (四) 14:29 (UTC)

@ZhaoFJx、Ericliu1912、Wong128hk、LuciferianThomas、魔琴、Stang、Hamish：通知下曾參與討論的用戶--人間百態,獨尊變態(討論) 2024年10月31日 (四) 14:33 (UTC)

上一條其實ping到了。然後我個人傾向於「選舉管理員」這個名字，監選員和選舉監察員總覺得怪怪的。而且本身electionadmin這個權限本身就可以管理選舉的創建，我覺得更符合其實際用途。--Hamish T 2024年10月31日 (四) 14:37 (UTC)

因爲「選舉」能作名詞能作動詞，所以「選舉某某員」一詞有歧義。這種歧義能在語境中消解，但是我認爲比較有礙溝通，特別是對不知道有此術語的用戶來説。我也在想其它用詞，但可能比較文，也不易於理解，譬如因知有管理之義而叫「知選」「知選員」，因監（去聲）有官員之義而叫「選監」…… ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月31日 (四) 15:28 (UTC)

我不理解。「監督員」、「（使用者）查核員」甚至「管理員」也全部是這種名詞，亦幾未見誤解。仍建議叫「選舉監察員」，行文時則可非正式簡稱為「監察員」。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年10月31日 (四) 17:45 (UTC)

員不能成詞啊，不可能理解為監督出一個「員」來。（量詞可以成詞。） ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月1日 (五) 02:09 (UTC)

@魔琴：「選舉」不能作名詞，除非您認同沈老的「名動包含論」（）--自由雨日🌧️（留言｜貢獻） 2024年11月1日 (五) 04:35 (UTC)

現漢上的全忘了，意思理解就好（？ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月1日 (五) 06:10 (UTC)

(－)不支持「監選員」這一翻譯。該詞字面上來看十分奇怪。個人無法理解為何要用一個看起來像是「簡稱」的名詞來作為一個權限的正式譯名；其次，該譯名也無法直觀地體現該權限的作用。--Yining Chen（留言|貢獻） 2024年11月9日 (六) 11:39 (UTC)

那您認為「選舉管理員」和「選舉監察員」哪個名稱更好？--人間百態,獨尊變態(討論)(簽名) 2024年11月9日 (六) 12:38 (UTC)

按照慣例，感覺「選舉管理員」或許更加符合使用習慣。包括此前的一些討論，在稱呼此權限時似乎也傾向於使用這一名稱。--Yining Chen（留言|貢獻） 2024年11月10日 (日) 14:23 (UTC)

如果可能的話，我倒是希望可以把「創建並管理投票」和「唱票及查看IP信息」的這兩個權限分開。前者可以長期保留以確保靈活，後者則應用時申請不用時取消。其他的看起來不錯。——即請秋安 ZhaoFJx_(論•簽) 2024年10月31日 (四) 15:30 (UTC)

或者更大膽，所有延確用戶都能訪問計票統計，但監督行政員可以看到IP覆核投票更方便，也能減輕壓力。——即請秋安 ZhaoFJx_(論•簽) 2024年10月31日 (四) 15:32 (UTC)

那咱覺得倒不如把securepoll-create-poll直接給管理員，只把敏感的view-voter-pii受給監選員。--人間百態,獨尊變態(討論)(簽名) 2024年11月6日 (三) 14:33 (UTC)

有道理……我去留言問下是否可行——即請秋安 ZhaoFJx_(論•簽) 2024年11月6日 (三) 16:34 (UTC)

如果可以分開給的話，其實直接把securepoll-create-poll給管理員，然後view-voter-pii給監督員。--Hamish T 2024年11月15日 (五) 10:41 (UTC)

郵件已獲回復，摘抄：

Thank you for reaching out. I'll escalate this internally. It looks like some of this work may already have been done by SD0001: https://phabricator.wikimedia.org/T377531

——敬頌冬綏 ZhaoFJx_(論•簽) 2024年11月16日 (六) 19:21 (UTC)

「選舉監察員」及「選舉管理員」均可。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月10日 (日) 16:29 (UTC)

小結 (安全投票)

以上關於本地進行安全投票的討論看起來並沒有收到反對意見，個人覺得可以進行公示並進行下一步操作了。簡單總結一下達成的共識：

1. 本站認為在本站內部自行舉辦安全投票可行；
2. 本站將向管理員用戶組添加若干權限，以允許管理員創建並配置安全投票；
3. 本站繼續沿用先前約定，使用「兩名或以上監督員」進行監票，新增一個（名稱待定的）用戶組並（臨時/永久待定的）授予當前的監督員。

在完成技術上的修改後，可以考慮在本地舉辦下一場安全投票，也可以考慮先進行一場測試來保證功能正常符合預期。以上@人间百态、ZhaoFJx、Ericliu1912、Wong128hk、LuciferianThomas、魔琴、Hamish、自由雨日、Yining Chen： Stang^★ 2024年11月20日 (三) 09:08 (UTC)

( ✓ )同意1與2。3，想請問社群是否同意，如技術上可行的話，直接授予監督員securepoll-create-poll和securepoll-view-voter-pii權限，還是一定要將二權限授予（名稱待定的）用戶組，再將該用戶組（臨時/永久待定的）授予當前的監督員。希望進行一場測試，但不知道能不能。--Hamish T 2024年11月20日 (三) 10:11 (UTC)

個人感覺這樣不是太妥當，有失某個權限組的純粹性，咱還是建議新增獨立權限組的。比如「監票」跟監督這一特殊的版本刪除方式並無關係，甚至可能本站之前讓OSer去監票也有點望文生義的意思（ Stang^★ 2024年11月26日 (二) 12:51 (UTC)

可以目前暫定讓OS去監票，因為本站目前只有他們是簽署NDA的funct。如本站以後要引入CU時再讓CU來監票其實更妥當。--0xDeadbeef (留言) 2024年12月1日 (日) 01:47 (UTC)

不太確定第二條中所述的管理員創建投票，其餘(＋)支持——敬頌冬綏 ZhaoFJx_(論•簽) 2024年11月20日 (三) 16:09 (UTC)

全部(＋)支持——敬頌冬綏 ZhaoFJx_(論•簽) 2024年11月21日 (四) 01:14 (UTC)

國民黨六屆三中全會會議紀錄

經碰巧看到考察資料，我收回此前意見；「監選員」確實是漢語用詞，且較簡潔，故應可行。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月20日 (三) 15:18 (UTC)

仍然保持此前的觀點，即平日交流中可用「監選員」做簡稱（像是WP:AFD可簡稱「提刪」），但在正式確定其名稱時仍應着重考慮完整、全面、嚴謹且易於理解的譯名。--Yining Chen（留言|貢獻） 2024年11月21日 (四) 09:15 (UTC)

「選舉監察員」，簡稱「監選員」，何如？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月21日 (四) 13:05 (UTC)

(＋)傾向支持。 --Yining Chen（留言|貢獻） 2024年11月23日 (六) 13:37 (UTC)

可。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年12月1日 (日) 09:14 (UTC)

公示以上取得共識部分：1、2，及新增（名稱待定的）用戶組，爲期7日，2024年12月8日 (日) 01:50 (UTC)結束 0xDeadbeef (留言) 2024年12月1日 (日) 01:50 (UTC)

公示結束，正在準備部署，目前需要一名管理員來協助進行測試（創建安全投票） Stang^★ 2024年12月8日 (日) 08:52 (UTC)

個人可協助測試。--SCP-0000（留言） 2024年12月8日 (日) 09:34 (UTC)

處理中…… 計劃於世界協調時12月23日下午部署。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月20日 (五) 14:31 (UTC)

未完成 @Stang 有人對更改提出了包括數據庫和權限管理在內的問題，鑑於「這是年底最後一次部署，我們不應該冒險」，於是推遲到明年一月份。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月23日 (一) 14:08 (UTC)

小結2 (安全投票)

以下部分仍然欠缺討論：

1. 用戶組譯名（選舉監察員/選舉管理員/監選員）
2. 是否延續監督員監票，或使新用戶組獨立於監督員
3. 是否允許延確用戶看到票數
4. 引入本地安全投票後，可否放寬提名時限，（在舉行固定時間選舉的基礎上）允許管理員等申請隨時提出。

論。 0xDeadbeef (留言) 2024年12月1日 (日) 02:04 (UTC)

對於2，個人建議獨立於監督員，理由前文已述，「有失權限組的純粹性，「監票」跟監督這一特殊的版本刪除方式並無關係」；對於3，（「票數」我理解成「誰進行了投票」）在本站相關的即時通訊群組內有用戶反對，認為這有害於「最大限度地保護用戶隱私」，同時技術上似乎只能是所有用戶都可以看到票數 vs. 只有選舉管理員可以看到票數；對於4，支持，本來就應該是想什麼時候選就什麼時候選。 Stang^★ 2024年12月1日 (日) 02:43 (UTC)

@Stang：不知你對於我們下面所說的，針對2，暫定監督員監票有沒有意見。--0xDeadbeef (留言) 2024年12月13日 (五) 13:44 (UTC)

沒意見，我的意思是不修改目前監督員的權限，差不多和你說的目前就由每次申請時由行政員/監管員賦予是一回事。 Stang^★ 2024年12月14日 (六) 03:00 (UTC)

@0xDeadbeef：補ping Stang^★ 2024年12月14日 (六) 03:02 (UTC)

傾向維持支持半年選舉方案。

一）臨時管理員任期問題。當選臨時管理員用戶需半年後重選，每半年集中提名選舉的方式有助社群在半年內集中時間考察相關用戶表現是否應授予長期權限。隨時提名選舉的情況下可能每隔數月便要舉行臨時管理員延長權限投票，社群難以集中一併檢視用戶表現。

二）有利節省社群精力。在舉行投票均需有開啟人事討論、答問兩周等環節，都近乎一個月以上，頗費用戶時間及精力，集中選舉每年辦兩場，於該月份前後則可解決近半年的管理員選舉，較節省社群用戶時間精力。

三）減少頻密進行管理員投票情況。就本年度管理人員選舉，四月及十月有十三項提名。若年度提名的話，差不多是每月有管理人員提名，目前站務情況似乎可以容許維持半年度提名的程序，避免每月都進行管理人員投票的人力消耗。

自施行新管理人員制度以來，半年一選似乎已行之穩定。似暫無需修改。我傾向維持目前制度。-千村狐兔（留言） 2024年12月2日 (一) 16:37 (UTC)

我不認同你的觀點。為什麼社群應該「集中考察」或「一併查看」用戶表現呢？我個人認為如果臨時管理員的任期不在同一時間段下，反而減少社群投票的壓力（不用一次投票時要決定很多個候選人），而且也能夠減少可能出現的比較候選人造成反對的情況（也許這是在說我自己，但是情況大概存在？）。

對於社群精力來說，單獨管理員申請不需要開啟預討論，而答問環節也屬於申請的正常流程，若用戶不願意參與此環節，也可以不去參與，因為人事選舉並不強迫他人參與。並且，我個人認為在中維管理員人手一直不夠這個前提下，社群應當去花更多的時間來使管理員申請更容易，以便這個項目能夠吸引到更多人來當管理員。也就是說，管理員選舉不是說一個需要「解決」的事情，而對此抱有更加積極的態度也許會更好。另外，如提問環節過於耗費用戶時間與精力，是否說明平時集中選舉時的提問並非與候選人相關，而是直接利用「方便」來給所有人提問？（那不集中選舉的時候直接繼續用自己之前問過的問題不也行？）

根據以上，若中文真能每月有管理人員提名，難道不是一個好事情？英維都不能做到每月都有提名，英維還在天天說那裡人手不夠，那是說我們中維不需要新管理員了嗎？

我也沒說需要修改半年集中選舉，兩個程序完全可以同時運行。集中選舉來說能使社群注意力更分散，應當保留，我也能理解有候選人更傾向參與集中選舉。你所說的「似乎穩定」，不清楚是什麼理據？程序基本成熟所以就不能繼續改善了嗎？--0xDeadbeef (留言) 2024年12月7日 (六) 16:20 (UTC)

(？)疑問，提名和安全投票需要時間準備，從確認被提名人、到提問環節開始、加上投票就超過一個月去，這樣看來下一位重疊到的機率很高，還沒點到票又要提名管理員了，若是這樣的運作，我不認為這是容易選出管理員的方式。—提斯切里（留言） 2024年12月7日 (六) 19:06 (UTC)

一般來說隨時申請不需要行政員確認，只要在發起之前回答三個問題就行。如有無效的情況由行政員關閉就行了。集中選舉需要行政員確認是因為有流程步驟。另外或許可以徵求更多實際參加過選舉之類站務的人的意見。--0xDeadbeef (留言) 2024年12月8日 (日) 09:49 (UTC)

我對於譯名的選擇問題來說，個人支持Eric上方所提出的「選舉監察員」，因為能夠直截了當地說明職務（監票）。--0xDeadbeef (留言) 2024年12月7日 (六) 16:24 (UTC)

本人認為可以慣例由監督員監票，每次申請時授予相應權限即可。此外，若技術門檻不高，本人亦認為可以重新允許隨時發起管理員申請，同時保留集體申請制度，俾便有志者自由選擇。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月7日 (六) 21:16 (UTC)

我以上也說過，由監督員監票可作為（暫定）方案，直到本站對於取回本地CU權限能有比較清楚的路徑。在本站還沒有本地CU的時候，由本站的OS（唯一本地funct）來監票無疑是省了很多麻煩的方案（不然又要成為獨立一體的NDA用戶組），如果本站之後可以引入本地CU，那麼個人認為監票員可由CU成員選出。這個的進一步討論最好是與取回CU的討論一起進行，目前就由每次申請時由行政員/監管員賦予就好。--0xDeadbeef (留言) 2024年12月9日 (一) 08:15 (UTC)

不認同減少比較做法。社群本來就能比較候選人是否勝任。沒有必要削足適履，為了增加管理員數量而修改制度去減少反對票。所謂反對票，支持票也是社群對用戶的信任體現。

過多人事投票會導致社群疲勞。之前已說過，倘以本年度提名為例，則基本上社群每月有選舉，答辯及投票也需耗時月餘。這顯然會造成社群疲勞。此外獲提名不一定代表站務會獲得順利解決。

早在以前未實施安全投票時，已有用戶表達社群不應過多人事投票。在目前集中選舉下，我認為是恰當的，俾使社群毋須每月也有選舉。純屬個人意見。-千村狐兔（留言） 2024年12月19日 (四) 14:36 (UTC)

既然社群成員能夠比較管理人員是否可以勝任，那麼分散集中選舉才是給社群更少壓力，一次性投多個候選人和時不時投一個候選人性質就不一樣，你要不要看看英維搞集中選舉的時候投票有多麻煩。

另外，我的主要觀點是「社群壓力」是一個非常沒意義的觀點。誠然，多選出一個管理員不一定能減少站務積壓，但是少選出一個管理員肯定是更解決不了了。--0xDeadbeef (留言) 2024年12月20日 (五) 05:18 (UTC)

安全投票小結3

以下為以上共識內容：

1. electionadmin用戶組本地譯名為「選舉監察員」。
2. 選舉監察員目前暫定由每次選舉需要時賦予監督員，由本站監督員負責監票事務。此暫定方案可由本地取回CU權限後再一同再次決議。
3. 在保留集中申請管理員等權限機制的情況下，獲取隨時發起本地選舉的技術能力後，重新允許社群成員隨時發起管理員等權限申請。

討論已過七日並意見已有得到合理反駁，取得共識，故 公示7日，2024年12月26日 (四) 13:42 (UTC)結束。0xDeadbeef (留言) 2024年12月19日 (四) 13:42 (UTC)

更正：目前這個新的用戶組的名字是"scrutineer"，這一點參考了enwiki方面的想法，希望可以叫法上統一。對本地譯名沒什麼看法，挺好的，twn上已經更新了。@0xDeadbeef： Stang^★ 2024年12月20日 (五) 01:41 (UTC)

好的，感謝提醒--0xDeadbeef (留言) 2024年12月20日 (五) 01:47 (UTC)

通過。--0xDeadbeef (留言) 2024年12月28日 (六) 04:51 (UTC)

我在這裡先寫了一個草稿，歡迎各位社群成員來修改改善。技術層面上可行後即可寫入實際界面。--0xDeadbeef (留言) 2024年12月28日 (六) 05:29 (UTC)

為何刪除幾個「行政員」？除此之外，尚有一些行文卡頓，不過大體無礙。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月28日 (六) 06:46 (UTC)

@Ericliu1912：主要是自由提名的時候不需要行政員來確認。一般流程是明顯不符合要求的申請可以由社群成員關閉的。不過可以說由管理員來確認？因為要他們來創建選舉。--0xDeadbeef (留言) 2024年12月29日 (日) 14:55 (UTC)

讚 我稍微改了下點票一章的措辭。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月29日 (日) 01:36 (UTC)

管理操作覆核請求：不認為Ericliu1912在8月28日的雙向互動禁制處理符合方針指引等社群共識

此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。

操作： 雙向互動禁制

執行者： Ericliu1912 （討論 · 貢獻 · 日誌）

首先說在前面：「管理操作覆核請求用於覆核管理人員或其他進階權限持有人用權時是否符合方針與指引的規範。……管理操作覆核請求旨在就具體管理操作是否適當達成共識，而非追究責任。」所以，這筆管理操作覆核既非封禁/禁制申訴（禁制期早已過），也非追究管理員Ericliu1912的責任（否則就是RFDA了），僅是用於討論該操作是否適當。

• 在2024年8月26日，我在WP:管理員布告板/其他不當行為由於被誹謗而提報了用戶Chinuan12623。在阿南之人、Patrickov、Tisscherry、ASid、薏仁將、Wolfch、Heihaheihaha、WilliamSkyWalk等近10人參與提報區討論之後，8月28日，管理員Ericliu1912作出了對Chinuan1262和我的互動禁制決定（另也對Chinuan1262和Tisscherry作了互動禁制）。首先，對當時提報區的討論做一個總結：
  • 阿南之人認為我屬於回退明顯破壞，要求Shizhao解釋在提報之前對我的封禁。我的封禁與該提報無直接關聯，但封禁原因正是由於我三次用{{deltalk}}移除Chinuan誹謗我的留言。即，阿南之人顯然認為Chinuan12623的誹謗性留言不當。
  • Tisscherry對我表示感謝（因為我從最開始接觸Chinuan12623就是由於在監視列表看Ericliu1912討論頁時，看到他直接向管理員要求處理Tisscherry，而出手幫忙），並表示Chinuan12623存在屢次曲解方針的行為和持續剪接留言的行為。
  • 2024年8月26日 (一) 07:58 (UTC)，Chinuan12623再度作出違反討論頁指引的操作，將新留言置於舊留言之上（版本差異），4分鐘後我在編輯摘要明確說明根據討論頁指引移動留言（版本差異）。隨後，Patrickov表示他也正想移動，即認可我的操作；隨後Chinuan12623堅稱其留言位置正確，並稱他人「刪改」其留言。總結，Patrickov顯然同意其留言位置不符合《討論頁指引》。
  • 隨後，Chinuan12623繼續同Patrickov爭執，堅稱自己留言位置沒錯，稱其「不計較也不告你倆亂改他人留言」等等。Patrickov繼續表示已給過《討論頁指引》，此時薏仁將也表示Chinuan12623的留言不符合《討論頁指引》
  • 隨後，Chinuan12623繼續同薏仁將發生爭執，不多時，Wolfch也加入討論，表示我的操作是「是維基百科允許的，不是亂刪，也不是亂屏蔽他人留言」，認同我的操作，並不認為我違反任何指引。
  • 隨後，Heihaheihaha參與討論，並就「處理」欄位等同Chinuan12623發生爭議。爭鬥中，Chinuan連ping Manchiu、Ericliu1912要求管理員揪處Heihaheihaha，隨後Wolfch表示是Chinuan自己的操作有問題，但顯然溝通無果。
  • 同時，WilliamSkyWalk加入討論，懷疑Chinuan的編輯傾向。
  • 最後，Tisscherry加入討論，作出讓步的姿態，但受到對方的負面回應。
  • 8月28日，管理員Ericliu1912作出最終處理，處理結果為，施予Chinuan12623和我、Chinuan12623和Tisscherry兩組一周雙向禁制，除此之外再無任何處理。其聲稱處理依據為：「雙方已陷入「編輯遭回退、認為自身沒錯（「為什麼他要回退我？」「管理員為什麼不趕快封鎖對方？」）、變本加厲反擊」之向下螺旋，討論情勢持續惡化。無論雙方具體堆積對錯之分量，本人認為現有必要強行中止此一循環，俾便社群回歸正常討論氛圍，或至少有機會較冷靜審視自身態度。」
• 我完全不認為Ericliu1912的這筆管理操作適當，接下來分析不合理原因：
  • 《WP:禁制方針#禁制的意義》明文有言：「當用戶造成極端或頑固問題的擾亂行為（包括但不限於打編輯戰、持續與他人產生爭執，或為闡述其觀點在特定頁面或主題觸犯其他方針指引），而其他制裁措施無法阻止有關行為，則可採用禁製作為最後制裁措施。」接下來就針對該文本考慮幾個問題：
    • 「極端頑固問題的擾亂行為」的起因是什麼，是哪一方？既然是雙向互動禁制而非單向，那也就是對雙方來說平等的處置。我和Chinuan12623，雙方是否均都進行了極端的擾亂行為？Ericliu聲稱「雙方已陷入『編輯遭回退、認為自身沒錯』」的向下螺旋，這一表述字面義成立，雙方確實都「認為自身沒錯」；然而，究竟雙方「哪一方有錯」，這顯然是一個可以判斷的命題（根據方針指引，根據提報區的討論）。在這一問題上，管理員Ericliu1912卻直接放棄了判斷。
    • 我和Chinuan12623是否滿足「持續於他人產生爭執」這一禁制中的舉例？在該提報區下，我同其的爭執是否嚴重？這個提報最先提報的是Chinuan12623對我的誹謗行為，這屬於雙方的「爭執」嗎？在該提報區下，Chinuan12623因不願遵守《討論頁指引》而與其他用戶連續爭議，這些能算是「爭執」嗎？
    • 這個提報的訴求，究竟是要阻止什麼行為？近十人編者參與討論，究竟是要阻止Chinuan12623的誹謗行為、不合討論頁指引的編輯行為，還是要阻止誰和誰的爭執行為？很顯然，管理員Ericliu1912在此完全判斷錯誤，將該提報的目的判斷成了要阻止編者間的爭議。
    • 即便在其判斷錯誤的前提下，是否沒有其他措施可以阻止，是否必須動用「禁制」這一最後手段？
  • 《WP:管理員》方針第二段明文有言：「管理員唯能實現社群討論所得的共識」。什麼是「共識」？顯然，五大支柱、社群常年累月通過大量討論得出的各類方針與指引，以及，在不當行為提報區下編者討論呈現的共識，這些都屬於共識。不當行為最初的提報是針對被提報用戶的誹謗行為，隨後多位編者又指出其亂排留言的行為，這些行為顯然違反《WP:討論頁指引》，而「持續違反指引應受封禁」明文寫於《封禁方針》。數十位編者在提報區下的討論，均有共識表示Chinuan12623行為不當，幾乎無人表示我行為不當。管理員的最終處理，這一處理的性質是「實現社群討論所得的共識」，但根據違反方針指引的情況和相應的封禁方針，根據不當行為提報區的討論，管理員Ericliu1912卻得出了「社群討論所得的共識應是雙向互動禁制」這樣的判斷。
• 在這筆案子了結以後，2024年9月，Chinuan12623再因違反《討論頁指引》被提報，ATannedBurger處理聲稱先前溝通不足，未做處理，「均不見涉事雙方或其他管理員有提及此論述或就爭論的解決展開討論」側面反映Ericliu1912完全未關注其違反指引的行為並向其溝通；2024年10月，Chinuan12623又因違反《討論頁指引》被提報，並由Shizhao封禁編輯所有討論頁1個月；封禁期結束後，隨即在2024年11月，又因違反《討論頁指引》被提報（( π )題外話：目前仍無人處理）。很顯然，從結果論上看，管理員Ericliu1912在8月26日對我提報其違反《討論頁指引》所作出的「雙向互動禁制」，完全、絲毫沒有解決該用戶的不當編輯擾亂行為。

以上，我認為管理員Ericliu1912在2024年8月26日該案中所作的「雙向互動禁制」處理是完全錯誤的，該處理完全違背社群共識，且沒有對制止被提報用戶的不當行為起到任何作用。最後強調，這是管理操作覆核請求，僅用於討論管理操作是否適當，而非追究責任、更非解任議案。 --自由雨日🌧️🌨️ 2024年11月13日 (三) 18:28 (UTC)

在Wikipedia:管理操作覆核請求/存檔裡，有自由雨君之前提過的䨱核請求，也有部份當時的回應，供作大家參考。--Wolfch (留言) 2024年11月13日 (三) 23:47 (UTC)

@Wolfch：當時那個覆核請求和這個應該關聯不大？那是對「不處理違反交互禁制行為」的覆核，不是對這一操作本身的討論。--自由雨日🌧️🌨️ 2024年11月14日 (四) 02:34 (UTC)

已劃刪除線--Wolfch (留言) 2024年11月14日 (四) 04:38 (UTC)

附知@Ericliu1912。Пусть от победы☆к победе ведёт! 2024年11月14日 (四) 06:59 (UTC)

我已經第一時間在討論頁通知他了（ ，這也是《WP:管理操作覆核請求》要求的。——自由雨日🌧️🌨️ 2024年11月14日 (四) 08:12 (UTC)

該覆核請求的簡短 總結：

• 管理操作：8月26日，用戶Chinuan12623因誹謗被提報，經過多位用戶討論後，Ericliu1912決定對Chinuan12623與提報者（Tisscherry以及自由雨日）之間實施雙向禁制。
• 提報區討論情況：提報區的討論顯示，社群認為Chinuan12623的行為存在多次違反討論頁指引的情況，而提報者的操作被其他用戶認可。
• 請求管理操作覆核理據：Ericliu1912未能合理判斷雙方的責任，錯誤地將爭執視為雙向問題，未能有效制止Chinuan12623的不當行為。此外，管理方針明確指出，禁制應作為最後手段，而在此案例中並未充分考慮其他可能的解決方案。

註：以上文字使用LLM輔助整理以避免太長不讀，僅供參考，更詳細準確的意見及理據請見提請人的原留言。--HeihaHeihaHa-麻瓜了……（留言） 2024年11月14日 (四) 01:32 (UTC)

認同以上描述，(＋)支持該管理操作覆核請求。--HeihaHeihaHa-麻瓜了……（留言） 2024年11月14日 (四) 01:35 (UTC)

(＋)支持覆核該操作，該禁制明顯不當。Пусть от победы☆к победе ведёт! 2024年11月14日 (四) 05:51 (UTC)

(＋)支持覆核 Benho7599 ^{三民主義好} 2024年11月14日 (四) 08:10 (UTC)

根據Wikipedia:管理員布告板/其他不當行為/存檔/2024年8月，管理員Eric Liu 回覆處理的第（三）點，雙向互動禁制是為了避免當時雙方「編輯遭回退、認為自身沒錯、變本加厲反擊」的螺旋，為了讓雙方冷靜而採取的作法。請大家再評估此作法的合理性。--Wolfch (留言) 2024年11月14日 (四) 04:36 (UTC)

首先，我認為，「編輯遭回退，認為自身沒錯」是從回退明顯破壞—回退違反方針指引（但非明顯破壞）的編輯—可簡單判斷和討論得出共識的爭議—難以得出共識的長期編輯戰這一「光譜」上的任何行為都會存在的現象，只有依照方針、指引和其他編者討論等均無法判斷哪方行為不當（即單純因觀點不同而引發的激烈編輯戰或長期編輯戰等）時，才可能適用互動禁制；但Ericliu沒有作任何判斷，而是直接強行互動禁制（顯然當時不屬於我說的這種適用情況，而是根據方針指引和提報區討論都已很明顯得出了哪一方行為不當）。其次，「為了讓雙方冷靜」並不是禁制的合理理由，（就像WP:封禁也不能用於為了讓人冷靜一樣，）WP:禁制方針明言禁制用於「造成極端或頑固問題的擾亂行為……其他制裁措施無法阻止有關行為」，且「僅應在容許有關用戶繼續編輯已足以構成嚴重擾亂及問題編輯的風險時採用」。--自由雨日🌧️🌨️ 2024年11月14日 (四) 05:22 (UTC)

(＋)支持復核此管理操作。--Wolfch (留言) 2024年11月15日 (五) 16:26 (UTC)

@Tisscherry 請問你有意願對你的禁制申請管理操作覆核請求嗎？Пусть от победы☆к победе ведёт! 2024年11月14日 (四) 06:15 (UTC)

我當時是以為，因為自由雨日和我有互相宣稱，如果其中一人被封鎖，那請連帶處理，類似這樣的發言（我沒去找diff，晚點想到再找）我想Ericliu管理員是看到了，故我當時欣然接受沒有其他意見。以此邏輯，自由雨日申請操作覆核，我會跟隨( ✓ )同意和(＋)支持。基本上我尊重管理員判斷，但我希望他若要做出說明，請儘量使用淺顯易懂的文字，維基百科不是官僚體系，不要刻意畫線拉距離。--提斯切里（留言） 2024年11月14日 (四) 06:50 (UTC)

我從未「刻意畫線拉距離」，「維基百科不是官僚體系」方針說的也完全不是這個意思。我不認為我說的內容比精密模板代碼更難理解。--自由雨日🌧️🌨️ 2024年11月14日 (四) 08:09 (UTC)

( π )題外話：這個「他」似乎不是閣下？--銀色雪莉（留言） 2024年11月14日 (四) 08:43 (UTC)

哦哦，好像確實可能不是……如果我理解錯了的話表示抱歉 囧rz……（因為前幾天他也說我寫的文字「太長不讀」）不過就算是指Ericliu1912，他也沒有「刻意畫線拉距離」，跟「官僚」也沒啥關係，只是他的語言習慣喜歡文白夾雜。當然我也希望儘量少用文言用法，多使用平實的現代漢語。--自由雨日🌧️🌨️ 2024年11月14日 (四) 08:47 (UTC)

謝謝銀色雪莉君，我是指E管無誤。管理員形象方面就不再離題。--提斯切里（留言） 2024年11月14日 (四) 14:55 (UTC)

自由雨日與Tisscherry，就兩人提出的控訴，應各自獨立檢視其覆核的理據。參考Talk:王必勝的編修歷史，管理員Shizhao在8月26日認定自由雨日、Chinuan12623進行編輯戰，禁止編輯該頁面31小時，管理員或會因應近期雙方在討論頁發生過編輯戰而進一步採取互動禁制，單是這點，自由雨日與Tisscherry的覆核背景已不一樣。在現實中，管理員Ericliu1912僅能審視8月27日及之前的情況，所以Chinuan12623在10月6日被Shizhao編輯禁制一個月在此是不用考慮的，8月27日之後的事態及提出的結論，均不在Ericliu1912於8月27日當天作出判斷的可考慮範圍內，簡言之不能說某個用戶在今天被永久封禁，就可以推定管理員在以往對相關或對立用戶在處理上有明顯的過錯。--Starcopter（留言） 2024年11月14日 (四) 18:43 (UTC)

支持Tisscherry若要覆核應另開一筆覆核請求，以避免討論混亂。不過我們這裡並沒有請求覆核Shizhao對我的封禁，在talk:王必勝進行的編輯戰，Shizhao作出封禁並制止，這和ANM的提報（誹謗，以及後來衍伸出的縮排、留言位置等）只針對違反《WP:討論頁指引》的行為是完全獨立的。至於Chinuan12623在10月的封禁（以及我提到的9月、11月），確實不能作為主要的考慮依據（我也僅是在最後提及），但絕非「不用考慮」，因為那些提報及封禁的理由仍然是違反《WP:討論頁指引》，和我的提報指向同一件事。這些之後的提報用於管理員並沒有依據《WP:封禁方針#防止擾亂》等有效起到制止他人持續違反指引擾亂的情況，自然意味着管理員的處理不妥。假設現在有一個違反格式手冊到處亂加粗體的用戶，管理員作出的是將其和回退其編輯的編者互動禁制的決定，結果其之後繼續於頁面亂加粗體，那麼顯然可以佐證管理員的決定不當，因為絲毫未起到制止其違反指引行為的作用。--自由雨日🌧️🌨️ 2024年11月15日 (五) 04:19 (UTC)

(＋)支持覆核，是次處理還導致自由雨日閣下失去仲裁員候選資格，個人認為是不太合理的。—ФрадонСтар|^{Меня зовут Хайшэньвай} 2024年11月26日 (二) 02:56 (UTC)

那倒不只是這次處理，還有另外一次封禁（）而且「失去仲裁員候選資格」這件事完全不能成為處理本身不合理的理由😂 ——自由雨日🌧️❄️ 2024年11月26日 (二) 03:00 (UTC)

共識挺明確了，看看哪個管理員能幫忙翻案。Пусть от победы☆к победе ведёт! 2024年12月18日 (三) 11:23 (UTC)

---

@Ericliu1912：管理操作覆核請求還未關閉，為何存檔了？——自由雨日🌧️❄️ 2024年12月8日 (日) 03:09 (UTC)

@Ericliu1912 請解釋這一筆編輯的目的。Пусть от победы☆к победе ведёт! 2024年12月8日 (日) 03:21 (UTC)

存檔即是自然關閉。另外本人不評價上述任何「馬後砲」式批評處置的看法。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月8日 (日) 04:49 (UTC)

@Ericliu1912：然而管理操作覆核請求必須「有共識」（並「總結討論中達成的共識、明確說明相關操作的正當性是否被是社群認可」）或「顯然無共識」後才能關閉，且不能由當事管理員關閉（見WP:管理操作覆核請求） ——自由雨日🌧️❄️ 2024年12月8日 (日) 05:03 (UTC)

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

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)

(＋)支持：基金會向法院披露身份信息必然影響編輯的日常生活和隱私安全，且收到威脅的一定不限於英維；抗議可以是聲援自我保護的第一步。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年11月15日 (五) 03:35 (UTC)

哈，WMF考慮向印度法院披露編輯身份信息，有編輯卻擔心基金會會因為中維的條目而敗訴。--日期20220626（留言） 2024年11月15日 (五) 03:51 (UTC)

目前趨勢似乎是不會閉站。我認為本站反應弱於直接相關方英維是可以接受的，但弱於德、法、俄、西、意等維基社群是不可以接受的，不然就有跟不上國際維基社群主流意識的觀感。但未見德、法等有採取行動的跡象，除了俄維，而跟不上俄維的意識似乎並非問題。我承認上述分析是見風使舵、隨大流的，但我的看法還是：既不先於俄維，也不後於德維。--Fire Ice 2024年11月15日 (五) 04:01 (UTC)

我不認為中維應該被所謂「國際社群的主流」牽着走。中維應該要有自己的想法。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年11月15日 (五) 09:28 (UTC)

中維可以有自己的想法，但現在英維閉站的反對票仍大比例領先，我認為至少不能早於英維閉站。--Fire Ice 2024年11月15日 (五) 09:50 (UTC)

(※)注意，英維RFC已被IAR關閉，跟隨閉站的前提暫不成立。--Fire Ice 2024年11月16日 (六) 02:09 (UTC)

(＋)支持中維閉站抗議。--——— 紅渡廚（留言・貢獻） 2024年11月15日 (五) 04:36 (UTC)

(！)意見：有件事讓本人有點納悶，那就是為何基金會或者吉米威爾斯本人對印度的法律行動反應這麼大？別的國家直接封殺維基百科也沒有見他們有很大反應（至少以人口／覆蓋率來說，中國大陸至少是跟印度同級數的），難道是因為他們認為對印度「還有爭取的餘地」？說實在話，從本人以前閱讀某些媒體報導的觀感，印度雖然毫無疑問是民主國家，但其當局在立惡法、打壓異見方面未必落後於專制國家。--派翠可夫 (留言按此) 2024年11月15日 (五) 04:49 (UTC)

印度：莫迪問題，基金會似乎有點雙標了？--日期20220626（留言） 2024年11月15日 (五) 07:48 (UTC)

更新：威爾斯本人似乎在勸說不要閉站。有部份認為此事嚴重的人士直接向他提出了異議。--派翠可夫 (留言按此) 2024年11月15日 (五) 08:42 (UTC)

本人利益直接相關自然會勸說。JW極力配合印度方面有可能是出於挽留當前可訪問本站的最多人口國家之考慮——留給他的市場已經不多了。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年11月15日 (五) 09:33 (UTC)

印度封鎖維基，損失的只是印度人自己。--日期20220626（留言） 2024年11月15日 (五) 12:05 (UTC)

印度確有打壓異己的狀況，例如印度教徒打壓伊斯蘭教徒。WMF沒做過類似向中國政府披露異議人士類編輯身份信息這件事。--Lanwi1^Talk 2024年11月15日 (五) 15:06 (UTC)

印度已有先例，很難保證中國大陸不是下一個。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年11月16日 (六) 04:46 (UTC)

個人認為黑掉的部份直說無妨。--派翠可夫 (留言按此) 2024年11月15日 (五) 17:29 (UTC)

(＋)支持閉站 Benho7599 ^{三民主義好} 2024年11月15日 (五) 07:44 (UTC)

我也反對公開編輯私人信息，哪怕是對民主程度高的西方國家都要謹慎的事情，對印度這種封殺批評總理紀錄片、打壓示威而且動不動就對部分地區斷網的國家更是不該放任。個人認為基金會應該像對待中國大陸一樣，寧可讓印度封鎖基金會網站也不要便宜這樣的表面上民主，實則人權問題及打壓異見問題沒好到哪裡去的國家（反正印度不也早已經因為和中國的邊界問題封鎖了不少中國網站）！--💊✖️2️⃣3️⃣（留言） 2024年11月15日 (五) 09:09 (UTC)

• 不要被西方勢力利用，維基必須要從尊重法律--北極企鵝觀賞團（留言） 2024年11月15日 (五) 09:27 (UTC)

此話相當含糊而缺乏價值，可能產生各種理解。--YFdyh000（留言） 2024年11月15日 (五) 09:55 (UTC)

印度在中國之西，向其叩頭似乎也是被西方勢力利用^{[開玩笑的]}--派翠可夫 (留言按此) 2024年11月15日 (五) 09:57 (UTC)

維基也未嘗不是西方勢力。^{[開玩笑的]}-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年11月15日 (五) 10:19 (UTC)

請不要在嚴肅場合開玩笑（指上方二位）。--碟之舞📀💿 2024年11月15日 (五) 10:40 (UTC)

我也反對這一披露編輯身份信息的做法，但是我希望社群謹慎考慮這一決定。任何抗議都應該有明確的目標，而不是為了跟進而抗議。--碟之舞📀💿 2024年11月15日 (五) 10:40 (UTC)

是這樣的。本地的行動需要明確的共識，但是看起來本地、包括中文世界沒人關心。這樣，把本段標題改成

• WMF考慮向印度法院披露編輯身份信息，本站是否應該關站抗議

完全不提一次別的wiki的話，應該沒人去了解討論吧？--Akishima Yuka（留言） 2024年11月15日 (五) 10:55 (UTC)

相比「關站」，顯著位置（首頁和頂置）掛橫幅、通告吸引關注是否可行？--YFdyh000（留言） 2024年11月15日 (五) 11:58 (UTC)

僅憑notice可能不足以扭轉基金會的決策。中維的影響力沒有英維大，但用戶或讀者眾多；關站帶來的震動遠比notice有效。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年11月15日 (五) 13:03 (UTC)

關於標題調整的事項，副知@魔琴。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年11月15日 (五) 13:10 (UTC)

可也。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月15日 (五) 18:30 (UTC)

中文（嚴謹點說是漢語）在印度屬小眾語言，我自認為印度根本不care這門語言。--Txkk（留言） 2024年11月15日 (五) 12:14 (UTC)

關站的施壓目標是基金會而不是印度。--YFdyh000（留言） 2024年11月15日 (五) 12:30 (UTC)

(＋)支持：我建議在關站通告說明這不單是為了印度，更是為了中維（反對內容審查、反對披露編輯者身份資訊）。--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2024年11月15日 (五) 16:25 (UTC)

(～)補充：11月14日，法官已向編者發出傳單。維基媒體基金會會將傳票通過「所有允許的方式（包括WMF被要求提供的用戶郵箱）」送達至其他被告，來源。部分重點摘要：Let summons be issued to defendants 2-4. The summons can be served through all permissible modes... including email addresses to be supplied by the defendant 1 [Wikipedia], the court said in the order while fixing December 16 as the next date of hearing.--𝓯𝓮𝔂𝓪𝓷ヽ(＾∀＾)ﾉ訊 2024年11月15日 (五) 18:15 (UTC)

• Writing this in English to perhaps reach a larger audience: Regardless of what the English Wikipedia decides, I ( ✓ )同意 that Chinese Wikipedia should participate in the blackout. Wikipedia builds on the idea of free flow of information and expression, which builds on the ability and/or possibly for editors to contribute anonymously or pseudonymously. This is particularly true in environments where editors may face persecution or retaliation for their contributions. Disclosing editors' private information will severely compromise editorial independence and create an irreversible chilling effect. Such an idea should not even be proposed, let alone considered. This, combined with the unique nature of Chinese Wikipedia, where editors have faced different threats, both legally from governments and from peers, makes this a dangerous precedent to set and might send the wrong signal.

Should WMF decide to disclose the personal information of editors, it will open a Pandora's box that not only endangers the safety of editors but also the integrity of Wikipedia itself. We urge WMF to stand firm on protecting its contributors and its very own mission on promoting free flow of information.-某人✉ 2024年11月17日 (日) 10:20 (UTC)

其實可以再等一會。這事兒還急不到我們份上。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月18日 (一) 03:32 (UTC)

若屆時須起草公開信，可以附贊英文版信件理念，以表示對他們的支持。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月20日 (三) 15:10 (UTC)

(＋)支持本站先於英維關站--Office563（留言） 2024年11月20日 (三) 07:57 (UTC)

此事件涉及眾多編者的人身安全，應該置頂到首頁--Office563（留言） 2024年11月20日 (三) 08:09 (UTC)

先把英文維基那個公開信翻譯過來吧--Office563（留言） 2024年11月20日 (三) 08:17 (UTC)

英語維基百科社區一直密切關注近期「亞洲國際新聞訴維基媒體基金會案」的相關事件，且對此深感憂慮。在一個許多利益相關方試圖控制維基百科內容的世界中，我們認為保護編者的匿名性對於維護百科全書的全面性、可靠性和中立性至關重要。我們數以百萬計的志願者依賴基金會保護我們免受強大的外部勢力影響，包括對已發表來源的內容進行篩選和平衡。基於此，我們對基金會可能考慮向德里高等法院披露志願者身份信息的建議深表關切。我們理解國際法律糾紛中披露此類信息的複雜性，並對基金會一貫抵制信息披露以及協助陷入法律困境的編輯者表示讚賞。然而，我們呼籲基金會將志願者的安全與福祉置於首位，即使這可能導致基金會面臨法律訴訟或其他代價。任何其他行動都可能對志願者的工作產生寒蟬效應，同時也會增加外部勢力影響維基百科的可能。簡而言之，這將危及我們這個項目的未來。

此公開信在英維已有1100+人簽署，其中包括管理員、監督員、回退員等，個人無法接受披露編者信息之行為。--𝓯𝓮𝔂𝓪𝓷ヽ(＾∀＾)ﾉ訊 2024年11月20日 (三) 09:06 (UTC)

公開信應該被發到原味雞上，翻譯成多種語言--Office563（留言） 2024年11月21日 (四) 06:25 (UTC)

元維基--Office563（留言） 2024年11月21日 (四) 06:26 (UTC)

公開信已經建立單獨譯本頁面：Wikipedia:2024年致維基媒體基金會的公開信。感謝貢獻。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月21日 (四) 06:43 (UTC)

既然基金會已經交了信息還代發了傳票，那確實應該抗議，不過個人認為可以考慮在首頁掛橫幅和在本地簽公開信，不一定需要關站抗議。--🎋竹生🎍 2024年11月20日 (三) 13:05 (UTC)

基金會真沒種，大不了讓印度當局把Wikipedia封了。好歹應該學學Google，Google不滿中國大陸的審查，直接退出中國大陸。--日期20220626（留言） 2024年11月20日 (三) 13:15 (UTC)

既然基金會已經交了信息還代發了傳票。目前這還懸而未決。我仍認為，一切行動均不應早於英維。--Fire Ice 2024年11月20日 (三) 17:08 (UTC)

現在說話都這麼不負責任的麼？怎麼就傳成了「基金會已經交了信息」？--百無一用是書生 (☎) 2024年11月21日 (四) 02:47 (UTC)

在下是在這[14]看到的，如果是在下對英文新聞的理解有誤還望您指教。--🎋竹生🎍 2024年11月21日 (四) 04:30 (UTC)

原文寫 would be，應該看成是「已答應或作出提議，但未實行」。當然，這已經夠糟，但畢竟跟做了是有分別的。--派翠可夫 (留言按此) 2024年11月21日 (四) 05:05 (UTC)

(～)補充：本人已簽署公開信--派翠可夫 (留言按此) 2024年11月21日 (四) 05:09 (UTC)

如果在下沒有理解錯的話，根據這篇[15]報道，基金會與ANI達成的同意令（consent order）包括「維基百科同意與法院秘密共享必要的用戶訊息，並將誹謗訴訟傳票直接送達相關用戶」，且法院已經執行了同意令並要求在4天內送達傳票（也就是說傳票在11月18日前已經送達涉事維基人郵箱），故在下竊以為相關basic subscriber information已經被送到法院處。在此深表憂慮。--🎋竹生🎍 2024年11月21日 (四) 05:44 (UTC)

(～)補充，根據在下上面提供的兩個新聞，「The summons can be served through all permissible modes...including email addresses to be supplied by the defendant 1 [Wikipedia].」如果在下沒理解錯，基金會至少已經將涉事維基人的電郵地址（以密封方式）交予法院方面？--🎋竹生🎍 2024年11月21日 (四) 09:17 (UTC)

這裡的To be的意思似乎是「將由……提供」或「被要求由……提供」？儘管如此，按照新聞所說Basic Subscriber Information諸如用戶名之類的，應該是強制提交給法院，ANI只擁有法院版本的修改版？但是就算法院和ANI什麼都沒有編者的官司也吃定了。編維基百科還要吃官司，真可怕。。。。--𝓯𝓮𝔂𝓪𝓷ヽ(＾∀＾)ﾉ訊 2024年11月21日 (四) 09:52 (UTC)

贊成首頁掛橫幅，不影響使用又顯聲援之意。--Uyi liu2 _{幸泉居士✍️} 2024年11月21日 (四) 02:43 (UTC)

基金會這麼做顯然是個壞的先例，尤其對於中國大陸、香港和澳門編者而言，雖然我不想評論是否應該閉站，不過如果中文站早於英文站閉站，那就有趣了，畢竟這更能向基金會宣示中文站編者對於自己個人信息的泄露問題是有多在意。--💊✖️2️⃣3️⃣（留言） 2024年11月21日 (四) 03:47 (UTC)

話說以前ProtonMail曾經披露過法國一社會組織成員的相關信息，也引發過爭議。--💊✖️2️⃣3️⃣（留言） 2024年11月21日 (四) 04:08 (UTC)

(！)意見我認為用聯署聲明的方式表示態度比較好。——暁月凜奈 (留言) 2024年11月21日 (四) 05:03 (UTC)

聯署不痛不癢，尤其上述基金會已經交了資訊--某人✉ 2024年11月21日 (四) 09:14 (UTC)

一、依據11月14日 WMF 法務部門的說法和創辦人兼理事會成員 Jimmy Wale 的說法，WMF 從未披露過任何個人資料。而情況應為基金會代替法院向三名編者發送傳票，其電郵地址應未有披露予法院及訴訟方。

二、正如 Jimmy Wale 在英維的討論所言「The title of this is "Should a blackout be organized in protest of the Wikimedia Foundation's actions" - which is of course very premature as the WMF has not released anyone's data. So what's to protest?」，個人認為應三思而行，而非為關站而關站，也建議各位可翻閱英維關站之相關討論及了解他們為何沒有關站。

三、即使基金會披露相關個人資料予印度法院（儘管此情況並沒有發生），也並不代表會披露予中國大陸政府。認為資料會披露予中國大陸政府之說法無疑是滑坡推論。謝謝。--SCP-0000（留言） 2024年11月21日 (四) 09:59 (UTC)

我對硬性關站（條目內容不可用）和探索此事細節沒什麼興趣，但關於二和三，我覺得這涉及基金會行動面臨雙重標準及信任度的質疑，不同標準問題必然存在和應被關注。所以如果有，我會支持橫幅或可關閉的全屏通告。--YFdyh000（留言） 2024年11月21日 (四) 10:34 (UTC)

感謝，雖然按您所說傳票是代為轉達，但可以確定的是法院已經（在WMF願意的情況下）執行了（要求提供使用者基本資料的）同意令，如果在下沒有理解錯的話，這似乎意味著只要基金會要繼續打這個官司，就必定會（以密封方式）向法院提供涉事維基人的基本資料（Jimmy和法務的聲明似只是「從未提供」到14日為止），除非基金會（在還沒將基本資料送出去的情況下）願意「藐視法庭最後讓維基在印度被封」。不知您的看法如何。--🎋竹生🎍 2024年11月21日 (四) 11:56 (UTC)

可能但並非必然。正如 WMF 說服了法庭以代為傳達的方式來避免披露個人資料，他們也可能有其他說服法庭的策略以免披露，或者最後選擇不披露和就披露命令上訴至最高法院。當然，由於 Sub judice 的原則下（參見法務部門 10 月時的聲明），他們不能披露案件細節，所以無從得知他們的策略，但可以肯定的是他們現在仍未披露任何個人資料。至於為何最後更新是14日為止，這是因為最後一次聆訊是在14日。謝謝。--SCP-0000（留言） 2024年11月21日 (四) 12:39 (UTC)

另，Jimmy 在 15 日留下了一段簡短的更新，儘管未有提供任何細節「I can't share anything other than my pride in the entire board and the staff. Seriously. You'd all be overjoyed if you could hear it. (As ever, I only speak for myself as a Wikipedian who is passionate about neutrality, truth, privacy, and individual (human) rights.)」--SCP-0000（留言） 2024年11月21日 (四) 12:57 (UTC)

俄維一周前就起草了他們自己的公開信，行文似乎有些不一樣。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月21日 (四) 12:41 (UTC)

有無譯者（ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月22日 (五) 02:25 (UTC)

借Chrome把俄文機翻成英文再自行翻譯中文：「作為簽署本公開信的俄文維基百科編者，我們謹此宣告：保護編者的身份不被公開，是本百科全書工作的重要前提。尤其是在多個國家的法律中，中立如實地根據來源陳述事實被視為嚴重罪行，匿名性成為唯一能夠確保編者人身安全的措施。我們對維基媒體基金會考慮將部份編者的個人資料透露予德里高等法院的做法表示震驚。我們了解國際間披露個人資料的法律爭議甚為複雜，亦感謝基金會一直阻止個人資料外洩及協助受法律威脅的編者。然而，我們亦促請基金會，即使可能要因此而使自身面對法律行動，其亦應將編者的人身安全及身心健康放在第一位。任何偏離或不符這個目標的行動皆將增加未來所受的壓力及訴訟風險，令編輯條目成為不可能的任務。簡而言之，那將危及本計劃（維基百科）的未來。」--派翠可夫 (留言按此) 2024年11月22日 (五) 02:59 (UTC)

七日分割線

討論已經將近七日。觀察到沒有人明確反對閉站，但是支持方有以為應立刻閉站者，有以為應暫作壁上觀者，亦有人只留支持之語而並不明確關站具體時機。現設置議題討論區明確意向，並希望通過討論（不是投票）達成共識。另外設置議題2討論其他抗議措施。建議事態更新等其他討論仍發布在上一小節。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月21日 (四) 09:32 (UTC)

議題1：是否閉站

本站應該立刻準備閉站抗議

#如上述，基金會已經交了資料。聯署不痛不癢，且中維不是英維中文版，更何況交資料impact中維遠甚於英維-某人✉ 2024年11月21日 (四) 09:46 (UTC)

1. (＋)支持：理由同上，這樣的事只有零次和無限次。Benho7599 ^{三民主義好}

   @AINH、Hoben7599： 見上留言，基金會並未披露任何個人資料。--SCP-0000（留言） 2024年11月21日 (四) 10:43 (UTC)

   During a hearing (...) on October 28, Wikimedia relented to the High Court's demand that Wikipedia reveal identifying information of the online users involved in editing the ANI page. --某人✉ 2024年11月21日 (四) 14:00 (UTC)

   WMF 已經表示沒有披露任何個人資料，這似乎是媒體的解讀錯誤（媒體也不是第一次對維基百科的運作有錯誤的理解）。當然，您可以認為 WMF 並不可信，這是您的自由。謝謝。--SCP-0000（留言） 2024年11月21日 (四) 14:18 (UTC)

2. (＋)支持，由於中文維基百科的特殊性，為了編者的安全，不需要照搬英文維基的做法--Office563（留言） 2024年11月21日 (四) 10:56 (UTC)
3. (＋)支持：理由同上——中國大陸對WM的封鎖現在可謂遠近皆知，本人在實際生活中過去的三年也已經遇到諸多因此發生的影響。各位很難保證WM未來不會為了進入大陸向中國大陸行政部門方面提供後者所需的資料（雖可能性很小但尚微存），因此本人認為完全有理由比英維處理的早而果斷。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年11月24日 (日) 12:42 (UTC)

   讚--Office563（留言） 2024年11月24日 (日) 14:02 (UTC)

   比如（節刪）--Office563（留言） 2024年11月25日 (一) 04:11 (UTC)

4. (＋)支持建議直接去m:PCP提交正式關站申請。--Liuxinyu970226（留言） 2024年11月25日 (一) 01:17 (UTC)

   原味雞大概率不會同意，直接本地界面管理員先動手吧--Office563（留言） 2024年11月25日 (一) 04:09 (UTC)

   @Office563這種做法有可能被監管員伺候一頓的風險，德語幹過一次，後果嘛超級保護了解一下。--Liuxinyu970226（留言） 2024年11月25日 (一) 04:43 (UTC)

   所以要先下手為強，直接炸掉網站跑路（--Office563（留言） 2024年11月25日 (一) 05:32 (UTC)

   您這個做法是對讀者、站內其他編者很不負責任的行為。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年11月25日 (一) 10:54 (UTC)

本站應該閉站抗議，但應該等到事態變化（如法院、WMF確認有進一步操作，或者英維閉站）。請明確您認為的應該觸發閉站抗議的事件

1. (＋)支持 -- 派翠可夫 (留言按此) 2024年11月21日 (四) 09:38 (UTC)

   (～)補充：當法院、WMF確認有進一步操作，毋需等候英文維基行動 -- 派翠可夫 (留言按此) 2024年11月22日 (五) 02:01 (UTC)

2. 如果Jimbo和法務的說法屬實，且基金會仍未交出信息，我認為暫時不需要閉站。閉站這一措施應該留給需要更加強烈的反應的場合。若確認WMF將個人隱私信息披露予法院，或者法院作出不利於基金會的裁決，不論其他社區有何措施，應該立刻閉站抗議。如果英維、俄維閉站抗議應該考慮跟隨。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月21日 (四) 11:04 (UTC)
3. (▲)同上，當然現階段中維可以先作其他抗議。（英維不關站不代表中維不須關站）--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2024年11月21日 (四) 14:10 (UTC)
4. 若確認WMF即將或已將個人隱私信息披露予法院(不論其他語種反應)應立刻閉站抗議-某人✉ 2024年11月22日 (五) 02:11 (UTC)
5. 我不反對跟隨英維抗議。另外我相信，該議題下的所有問題，包括為何抗議，抗議對象，抗議內容，抗議的技術手段，抗議的法律問題，只要英維決定抗議，他們就會全部解決。我相信英文維基百科社群的智慧。Fire Ice 2024年11月22日 (五) 04:10 (UTC)
6. 雖然其它維基不需要關閉，但考慮到中維的特殊性，應等到WMF將編輯身份信息披露給法院後才能關閉。--Lanwi1^Talk 2024年11月24日 (日) 20:10 (UTC)
7. 現階段發個橫幅通告公開信之類的都行。這有點類似罷工，故意讓讀者不方便是為了讓這件事能夠被更多人關注形成輿論以阻止相關情事發生，也因此必須要很嚴重才可以啟動，我認為必須經確認WMF披露編輯隱私，且英維已先行表達抗議仍未見回應，前者不符合則反對關閉，後者不符合的話能有條件關閉，如各語言的公開信皆被無視、遭施壓不得抗議或表達等。--Rice King 信箱 · 留名．邊緣人 2024年11月25日 (一) 12:56 (UTC)
8. (＋)支持--BigBullfrog（𓆏） 2024年11月25日 (一) 19:35 (UTC)
9. (＋)支持 我覺得跟英維吧，畢竟英維比中維人多太多了。--Martin 去我的簽名簿簽名！！ 2024年11月30日 (六) 04:40 (UTC)
10. (＋)支持 一當WMF披露電子郵件後，本站應立即關站，以表抗議，倘若WMF依印度法院繳交資料，現行所有大陸編者皆可能有危險 August0422 (T／C) 2024年11月30日 (六) 05:03 (UTC)
11. 前幾次關站，《歐盟一般資料保護規範》討論過後，我們沒有任何動作，SOPA/PIPA只有專題頁面以及Sitenotice公告，為何中維一定要跟隨其他維基百科關站呢？在事不完全關已之情況下，首頁橫額已是最嚴重的手段了。除非WMF決定公開編者個人資訊，否則不建議中維犧牲公眾利益。更何況我們有研討關站的細節嗎？草率實行，只會被人笑稱草台班子。--Mısaka✨M1koto 2024年12月11日 (三) 06:16 (UTC)

反對閉站抗議

1. 不同意躁進而未全盤考慮讀者權益之行為，至少社群亦須經相當規模編者投票確認存在共識。有英文維基百科在前，本站概不必就此議題強做先鋒。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月21日 (四) 13:06 (UTC)

   難道人身安全就不是權益了嗎--Office563（留言） 2024年11月21日 (四) 13:10 (UTC)

   Liu說讀者權益。--YFdyh000（留言） 2024年11月21日 (四) 13:20 (UTC)

   補充意見：但寫個橫幅聲援英文社群還是可以的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月25日 (一) 03:08 (UTC)

2. (＋)支持劉醬，本人(－)強烈反對閉站。目前諸多事宜尚未明晰，在此情況下不應貿然選擇閉站示威，且在取得共識並有75%支持率前均不應閉站。沒必要搶這個風頭，純屬火上澆油。先前亦見到Jimmy Wales在英文維基百科進行討論，編者諸君可移步英維閱讀他的意見。--Talimu0518（留言） 2024年11月22日 (五) 04:15 (UTC)

   Jimmy Wales不是WMF--Office563（留言） 2024年11月22日 (五) 05:08 (UTC)

   不過他身兼基金會理事，所以起碼知道得比社群多（ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年11月25日 (一) 06:50 (UTC)

3. 這根本就是沒事也要折騰出些事來。另外，閉站是抗議誰？抗議什麼？似乎也沒說明白？--百無一用是書生 (☎) 2024年11月22日 (五) 03:42 (UTC)
4. 基金會不該包庇罪犯。立即供出所有材料。--北極企鵝觀賞團（留言） 2024年11月22日 (五) 04:00 (UTC)

   建議先了解無罪推定原則及針對公眾參與的策略性訴訟，在未經審判下稱呼涉事編者為「罪犯」並非妥當。謝謝。--SCP-0000（留言） 2024年11月22日 (五) 04:43 (UTC)

5. 閉站受害的只有讀者，而且我不相信基金會會因為閉站而做出改變。最近我所住區域裡也有不少罷工罷課事件（出於各種原因），造成了我個人不少不便。還有，我覺得不少編輯應該有必要明白這點：是基金會提供了維基百科這樣的平台給各位編輯，It's a privilege, not a right. 現在你在別人的平台上對擁有平台的人抗議，不知道會想搞這齣的是不是沒分清楚主賓關係，真有本事就自己像Techyan一樣自立門戶吧。WP:NOTANARCHY。一定程度上的抗議，比如連署書或當隔壁閉站受到批評時做出聲援，個人認為是妥當的，但若是涉及到維持自由百科本身的承諾，那我不得不(－)反對閉站。忍耐是有極限的。--$\int$（☎）dt 2024年11月22日 (五) 04:36 (UTC)

   雖然我也不支持閉站，但是你這個話術聽上去有點像「因為你們的工作是我提供的，所以你們不能罷工，你們要是罷工我就立即解僱你們」。--日期20220626（留言） 2024年11月22日 (五) 06:17 (UTC)

   可能現實主義成分太多吧，畢盡大實話不是所有人都愛聽。--$\int$（☎）dt 2024年11月22日 (五) 07:08 (UTC)

6. 雖然基金會涉嫌提交編輯資料以及為了討好印度方面而刪條目不可取，甚至說做的非常醜陋，但是中文站閉站還是免了。—日期20220626（留言） 2024年11月22日 (五) 06:21 (UTC)

   討好部分，要不是基金會卡在訴訟中，基金會大概也不怎麼想碰這種問題。--SunAfterRain 2024年11月25日 (一) 08:34 (UTC)

7. 受介紹第一次來到這裡，但一來就看到了關站的提議，在詳細了解了事情起因後，本人(－)強烈反對這項提議，此事暫未波及至中文維基百科，並且我也沒有看到此事會有任何波及到中文維基百科的可能性或是跡象，中文維基百科關站除了會為讀者以及我們貢獻者本身帶來不便以外，沒有任何作用。若各位一定想要對英文維基百科的維基社群做出聲援的話，在主頁最底部放置對英文維基百科的聲援訊息是更加合理且可行的做法。--Pathfinbird（留言） 2024年11月22日 (五) 06:30 (UTC)
8. 中文維基百科使用者沒有權限關閉中文維基百科，不管投票結果如何都沒有作用呀，最多只能使用者集體逃亡，退出編輯而已。--CaryCheng（留言） 2024年11月25日 (一) 06:52 (UTC)

   搞破壞，給雞精會製造麻煩就行了--Office563（留言） 2024年11月25日 (一) 07:25 (UTC)

   這麼喜歡閉站可以自己開一個站點自己過家家，維基百科不是只有你們這幫蠢貨，還有其他讀者跟編者，拜託不要連累人好嗎？

   你們關站純粹是為了自己顱內高潮而已，「皇帝不急太監急」行為，英文站點那邊WMF都沒把編輯身分丟出來你們就先急上了？如果真的這麼害怕那麼你可以「寧蹈東海而死，義不帝秦」，在自己用戶頁掛retired模板然後拍拍屁股滾蛋。--Talimu0518（留言） 2024年11月25日 (一) 07:49 (UTC)

   麻煩不要把自己看得太重要，中文維基百科少你一個也能運轉下去，況且現在你們要閉站抗議，抗議誰？抗議什麼？抗議多久？還「搞破壞，給雞精會製造麻煩」，有你這樣的用戶就是維基百科最大的麻煩。--Talimu0518（留言） 2024年11月25日 (一) 07:52 (UTC)

   閣下如此發言實在不負責任，這樣的行為除了為讀者徒添笑料傷害到我們編者群體自身以外，還能起什麼作用？就目前所見，維基媒體基金會仍舊對此案十分負責，在有任何確切的信息和結果之前進行無謂的恐慌和抗議又和亂編來源不詳的條目有什麼區別？-- Pathfinbird（留言） 2024年11月25日 (一) 08:19 (UTC)

9. 沒有意義，這次根本都還沒波及到中文維基百科，僅為了那不知道有多少的可能性關站純粹是在浪費時間浪費生命，維基百科不是民主試驗場。--SunAfterRain 2024年11月25日 (一) 08:28 (UTC)
10. 很難評，除了影響讀者，閉站有個什麼用？換而言之，除了讀者，誰關心？是能影響到德里高等法院啊，還是能影響到美國政府呢？Iming 彼女の愛は、甘くて痛い。 2024年11月25日 (一) 10:54 (UTC)

    影響的是讀者、編者和基金會。屬於更大影響力的抗議。着眼未來而不限於本案，雖然效果無人能評。--YFdyh000（留言） 2024年11月25日 (一) 11:31 (UTC)

    對基金會有影響嗎？如果基金會僱員平時看的是英維，反而英維關站對他們影響更大吧。--日期20220626（留言） 2024年11月25日 (一) 11:55 (UTC)

    不過正是對我有影響，所以我反對閉站。如果關閉的是其他語種的站點，我無所謂，不過英文站最好還是不要關閉。--日期20220626（留言） 2024年11月25日 (一) 11:57 (UTC)

    影響來自編者看法、媒體輿論，而非使用上的直接影響。從使用者福祉來說，我也反對硬性關閉，如果是可關閉或不遮擋的大幅廣告，我不介意，網站求捐款或者反對法案而發這種並不罕見，但我不確定是否違背使用條款等。公開信表態抗議估計更可行。先觀望也可以。--YFdyh000（留言） 2024年11月25日 (一) 12:05 (UTC)

    雖然但是，你維關站對基金會而言只是多一些無聊的麻煩事而已，如果真的再遇到被迫需要交出資料的情境，一點用也沒有--SunAfterRain 2024年11月25日 (一) 14:46 (UTC)

    關站本身是這樣的，但可能產生後續的未知影響。目前討論看，暫時沒有關站共識的可能。--YFdyh000（留言） 2024年11月25日 (一) 15:08 (UTC)

    我只能說，從現實世界的角度看，基金會目前來看已經做得很好了，要抗議我覺得抗議印度法院或原告都比抗議基金會強。為何有人總覺得自己比基金會的法務還懂法律呢？--百無一用是書生 (☎) 2024年11月26日 (二) 03:07 (UTC)

    我覺得抗議「惡行/惡法」與「懂法律」是平行線，總不能對一切抗議者說你怎麼不走法律程序。沒人說抗議只針對基金會，但法院和原告是真的不會與暫時不能在乎吧。做得很好有爭議，因為用戶寄予不同的期望。--YFdyh000（留言） 2024年11月26日 (二) 13:08 (UTC)

    抗議「惡行/惡法」當然沒問題啊，可是這討論里從沒提過「惡行/惡法」啊--百無一用是書生 (☎) 2024年11月27日 (三) 14:59 (UTC)

    參考上方俄文公開信中譯。顯然崇尚「自由主義」的編者群體反對威權審查，以及擔心基金會因利益相關去權衡和妥協。--YFdyh000（留言） 2024年11月27日 (三) 16:34 (UTC)

    要抗議我覺得抗議印度法院或原告都比抗議基金會強。這點我贊同。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月26日 (二) 13:13 (UTC)

11. WP:DEM。我覺得最多掛個公告完了。--Leiem（留言·簽名·維基調查） 2024年11月26日 (二) 04:11 (UTC)
12. zhwiki閉站可能對WMF一點影響都沒有，人家根本不看 囧rz……，有別的辦法傳達zhwiki社群的抗議嗎？--Htmlzycq（留言） 2024年11月26日 (二) 12:33 (UTC)

    zhwiki算大了，閉站基金會應該會注意到。--Martin^{我強烈反對WMF給出個人信息，支持閉站抗議} 2024年12月1日 (日) 20:03 (UTC)

    說實話你們閉站會看見的只有讀者，最後你們閉站，WMF根本不鳥、編者除了顱內自我高潮覺得自己很高尚之外剩下大部分都在罵、讀者罵編者不幹人事，除了這些我根本想不出你們閉站會帶來什麼改變。

    是說現在大部分都在提出抗議WMF交出個人資訊而不是抗議德里法院下達命令，除了本末倒置之外反正最後交出與否都是WMF決定，說難聽點他們只要想根本不需要採納什麼狗屁社群意見，你們抗議示威並不能左右結果，除了可以自我高潮一下之外毫無用處。--Talimu0518（留言） 2024年12月1日 (日) 20:29 (UTC)

13. 註：此處原有文字，因為原作者刪除，已由August0422 肅此 (T／C)於2024年11月28日 (四) 14:07 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

    註：此留言已被原作者（User:Patrickov）移除。2024年11月29日 (五) 04:14 (UTC)

    註：此處原有文字，因為原作者刪除，已由August0422 肅此 (T／C)於2024年11月28日 (四) 14:07 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

14. (－)反對關站抗議，這會影響到讀者的權益，但可以適當公示，或另尋合適方法抗議。--78-Yellowcat（留言） 2024年12月10日 (二) 13:46 (UTC)
15. (－)強烈反對完全沒有這個必要，印度的事情對zh.wiki的影響根本是無中生有。不要「世上本無事，庸人自擾之」。一期一會再見難（留言） 2024年12月10日 (二) 14:38 (UTC)
16. 純粹是覺得關閉中文版維基百科是多此一舉的行為，而且連中文WP都關閉導致中文用戶的不便的話說不定印度政府還會更愉悅了，個人倒是不反對關英文甚至是印度相關語言的WP。同舟（論 · 歷） 2024年12月11日 (三) 07:20 (UTC)

相關討論

• (＆)建議第一項改為「本站應該立刻準備閉站抗議，無論事態有否變化」 -- 派翠可夫 (留言按此) 2024年11月21日 (四) 09:40 (UTC)

  已刪除有關英維文字。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月21日 (四) 09:43 (UTC)

• (＆)建議第二項改為：確認WMF已將編輯信息透露給法院，或英維決定閉站。Fire Ice 2024年11月21日 (四) 10:13 (UTC)

  已調整標題。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月21日 (四) 10:17 (UTC)

議題2：其他抗議措施

目前上方已有的抗議措施包括：起草本地公開信、翻譯英維公開信（已完成）、首頁掛橫幅。另外若上方決定閉站，或可在起草本地相關文件時提前擬好。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月21日 (四) 09:32 (UTC)

本地公開信是必要的，另外建議大家準備好橫幅/關站聲明內容。--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2024年11月21日 (四) 14:12 (UTC)

先暫擬一份ASN：維基百科豐富而中立的內容依賴於編者的安全。然而，這一安全正在受到威脅。了解詳情 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月22日 (五) 02:12 (UTC)

實在看不出來這怎麼就是威脅了？至多是不同意基金會的做法。但基金會的做法應該是有全面的法律上的考慮的，我們是否應該先聘請法律顧問諮詢一下呢？如果根本沒什麼問題，那豈不是很沒意思--百無一用是書生 (☎) 2024年11月22日 (五) 03:46 (UTC)

我認為提出社群意見還是可行的，至於基金會那邊有什麼考量，那就是他們自己要去想的了。講難聽點，基金會完全沒有義務理會社群提出的意見。--$\int$（☎）dt 2024年11月22日 (五) 04:43 (UTC)

被人告了不能說不算威脅吧。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月22日 (五) 05:41 (UTC)

法律上的考慮相當含糊，並且決定肯定不限於「遵守法律」。簡單來說，如果大陸/香港/美國/...政府基於某項理由要求數據或其他配合（歷史事件），基金會的處置流程和態度以及對外界的影響。如果「根本沒什麼問題」，基金會有責任和必要盡力澄清或表明態度/政策（在法律允許下），而編者亦應了解和表態。--YFdyh000（留言） 2024年11月22日 (五) 11:30 (UTC)

「互聯網不是法外之地」這句話放在全世界哪個地方都說得通--航站區（留言） 2024年11月30日 (六) 15:59 (UTC)

不明白這句話在這裡的作用。比如，基金會應該盡力執行各國法令？--YFdyh000（留言） 2024年11月30日 (六) 16:04 (UTC)

Wikipedia:免責聲明「請注意將您在這裡所找到的信息發布出去有可能會違反您所在國家或司法管轄區的法律。維基百科的數據庫都是儲存在位於美國的服務器中，因而任何內容都受到當地法律和美國聯邦法律的保護。您所在國家或司法管轄區的法律有可能沒有對相同種類的言論和發行進行保護。維基百科並不鼓勵任何人觸犯法律，因此如果您鏈接到此域名或使用、複製或轉載本站包含的信息，維基百科無法為可能帶來的違反此類法律的行為負責。」--航站區（留言） 2024年11月30日 (六) 17:42 (UTC)

我建議您再讀一遍這個聲明。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月30日 (六) 17:44 (UTC)

我引用的那段話是要表達「互聯網不是法外之地」這句話放在全世界哪個地方都說得通--航站區（留言） 2024年11月30日 (六) 18:12 (UTC)

「維基百科並不鼓勵」是中立態度，與「維基百科將協助打擊」在立場和影響上有明顯區別。免責聲明是指出，受美國法律保護。--YFdyh000（留言） 2024年11月30日 (六) 18:26 (UTC)

所以啊 這種法律話題 最好還是邀請那些法學者來討論 是最佳的--航站區（留言） 2024年11月30日 (六) 18:31 (UTC)

這應該可以存檔了吧 August0422_討論頁 2025年1月1日 (三) 13:20 (UTC)

續：管理員布告板排版

兩個月前由@Ericliu1912提出的討論中，共識似乎是社群討論都應置於「處理」欄位下方。但由於「發現人」欄位在「處理」欄位上方且會附帶簽名，導致會有大量討論（由於直接點按「回復」）出現在「處理」欄位上方。目前是否應儘快執行@Miyakoo的建議，將「發現人」欄位置於「處理」下方（即最下方），以避免「處理」的上方、下方同時分別展開討論的現象？（另一相反的建議見下方） ——自由雨日🌧️❄️ 2024年11月29日 (五) 11:10 (UTC)

竊以爲然。另，或應規定不得直接回覆處理意見，以免殊途同歸。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月29日 (五) 15:08 (UTC)

要是考慮到這個的話，我倒其實是一直傾向於「處理」欄放在最下方，即「社群討論」置於「處理」上方的，這樣更符合「新留言放在下方」的直覺（「處理」這條留言的時間一般來說肯定是在討論之後），並且處理之後再繼續回復也不會打亂時間線。至於注釋中的那行「非管理員僅可標記已執行的封禁，針對提報的意見請放在下一行」，我認為那行注釋並非意在規範「上方/下方」，而是在說「非管理員不要將意見放在『處理』行」而已，「下方」只是虛指或者說隨手一寫？（之所以剛剛沒提是我覺得「統一時間順序」要比「上方還是下方」更重要，不過既然看到有這個問題，感覺不如改提出「討論置於上方」思考... ——自由雨日🌧️❄️ 2024年11月29日 (五) 20:37 (UTC)

@Miyakoo、Sanmosa： ——自由雨日🌧️❄️ 2024年11月29日 (五) 21:20 (UTC)

不反對「討論置於上方」。

我是覺得處理比討論重要，應該放在較爲顯眼的位置，放在討論下方有點不明顯。--Miyakoo（留言） 2024年11月30日 (六) 01:45 (UTC)

我支持在處理之前的討論放在上方，下方留給對處理結果的討論。各個區域之間可以用----分隔。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月1日 (日) 07:43 (UTC)

如果不允許直接回覆處理意見，按照0xDeadbeef的建議直接用{{Archive top}}關閉可能更好？--Miyakoo（留言） 2024年11月30日 (六) 01:46 (UTC)

似乎也沒必要禁止回復處理意見？--自由雨日🌧️❄️ 2024年11月30日 (六) 01:48 (UTC)

這樣「針對提報的意見」和「針對處理的意見」會混在一起吧。--Miyakoo（留言） 2024年11月30日 (六) 02:06 (UTC)

嗯？按我說的方案好像就不會啊（即其他意見只能直接回復提報人、放在「處理」上方，對「處理」的意見則放在「處理」下方、回復管理員）？--自由雨日🌧️❄️ 2024年11月30日 (六) 02:27 (UTC)

可我回覆的是或應規定不得直接回覆處理意見，以免殊途同歸。

還是我理解錯了？--Miyakoo（留言） 2024年11月30日 (六) 02:36 (UTC)

嗯？魔琴的「以免殊途同歸」意思是，如果針對提報的討論規定放在處理下方的話，那就得規定不能回復「處理」，否則同樣（即「同歸」）會導致時間混亂的現象。所以我說按我的方案就可以避免這種現象，也就沒必要禁止回復處理欄。--自由雨日🌧️❄️ 2024年11月30日 (六) 02:41 (UTC)

看來是我理解錯了。

我覺得這種程度上的「時間混亂」是可以忽視的，畢竟新提報在舊提報上方本來也沒怎麼遵守「新留言在下方」。--Miyakoo（留言） 2024年11月30日 (六) 02:55 (UTC)

那不一樣……新提報在舊提報上方更有利於處理，就像監視列表/最近更改裡面新頁面也在舊頁面上面一樣。但同一提報（同一章節內）應該儘量按WP:討論頁指引的要求（先來後到的時間順序）？--自由雨日🌧️❄️ 2024年11月30日 (六) 02:59 (UTC)

但如果允許對處理回覆且處理在提報人下方，一旦針對處理的回覆和針對提報的回覆都很多的情況下，處理會夾中間，很不明顯。

也許處理可以單開一小節？--Miyakoo（留言） 2024年11月30日 (六) 03:44 (UTC)

如果是用「回復」方式處理的話，因為一般來說WP:討論頁指引要求不用項目符號進行縮排，所以「處理」前面的項目符號是可以起到加強作用的。我認為不會有不明顯的問題。——自由雨日🌧️❄️ 2024年11月30日 (六) 04:03 (UTC)

嗯，也行吧，反正總比現在好。--Miyakoo（留言） 2024年11月30日 (六) 04:06 (UTC)

雖然有先來後到時間順序要求，但這似乎是討論頁規範沒更新的目前狀態？我知道的是以往討論留言不似現在，現在每個留言都有回覆按鈕，按此串討論看來，解法只在最後一個留言有回覆，或者是拿掉回覆，強制執行只能用原始碼並在最後添加新留言、等等這不就回到早期狀態？--提斯切里（留言） 2024年11月30日 (六) 04:00 (UTC)

沒懂你的意思…… ——自由雨日🌧️❄️ 2024年11月30日 (六) 04:03 (UTC)

以最近一個對我的提報為例：U:Iming首先在06:14 (UTC)在「處理」欄位下方留言，後U:Patrickov於06:15 (UTC)點按「回復」在「處理」欄上方留言，U:Talimu0518於06:19 (UTC)繼續在「處理」欄上方Patrickov下方留言，這導致了「新留言位於舊留言」上方的現象，不過畢竟有「處理」欄分割，尚未造成明顯問題。但可能由於「處理」欄在中間，U:Manchiu做出處理時並未注意到，所以於11:49 (UTC)在最下方做出了處理，這樣就有了兩個「處理」欄（這裡會有「處理」欄不明顯的問題）。於是U:Tisscherry於14:07 (UTC)移除了中間的處理欄，這就導致同一區塊內的留言，Iming最早的留言完全位於最下方了，遂我剛才又調整了順序。總之，若不對留言規範做出約定，這樣的現象未來還會持續發生。--自由雨日🌧️❄️ 2024年11月29日 (五) 23:10 (UTC)

每個留言都有回覆按鈕可以點擊，使用者也可以使用原始碼放置留言，除非過分的編輯排版造成扭曲發言，我覺得不必在此「嚴格」規範。--提斯切里（留言） 2024年11月30日 (六) 03:39 (UTC)

我認為目前的情況已經是「扭曲發言」。--自由雨日🌧️❄️ 2024年12月2日 (一) 00:44 (UTC)

包括對漠南的提報在內也一樣，除上方自由雨日提及的「處理欄分割留言」外，管理員處理時亦有出現找不到處理欄而自行另開一欄的情況，致使最終提報討論中出現兩個處理欄。--Talimu0518（留言） 2024年11月30日 (六) 04:37 (UTC)

所以說應該直接廢除處理欄而轉用使用{{archive top}}來關閉討論。這樣有結果和無結果的案件區別明顯，管理員所處理的結果顯眼可找，並且不會存在兩個討論串時間穿越的情況。不僅解決當下問題，還附帶更多好處。--0xDeadbeef (留言) 2024年11月30日 (六) 13:24 (UTC)

確實，除了「不太方便對處理進行評論」之外基本完全利大於弊（我是覺得沒必要禁止處理後繼續評論，但也不覺得必須允許）。故也支持beef的方案。--自由雨日🌧️❄️ 2024年11月30日 (六) 22:12 (UTC)

然而對處理進行評論一者可以在archive bottom下面評論，或在客棧中開啟覆核程序，所以基本這個弊端不是太大。--0xDeadbeef (留言) 2024年12月1日 (日) 00:48 (UTC)

(＋)支持，但可能需要將result放得更顯眼。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月1日 (日) 08:46 (UTC)

{{archive top}}還不夠顯眼嗎…… ——自由雨日🌧️❄️ 2024年12月1日 (日) 08:47 (UTC)

似乎現在在框區的右上角？可以更寬大一些。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月1日 (日) 08:49 (UTC)

或者說直接在提報區禁用回復按鈕。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月30日 (六) 14:49 (UTC)

為什麼……這樣做有什麼好處嗎思考...以及這樣一來看中維很多編者在有「回復」按鈕還常常亂插亂排留言（且一般從不會有管理員管理這類事）的情況下，若再禁用，排版一定會更亂 ——自由雨日🌧️❄️ 2024年11月30日 (六) 18:31 (UTC)

@魔琴：您為何又把這條留言移到下方了，這不是繼續「上方下方同時展開討論、時間線錯亂」問題了嗎（（ ——自由雨日🌧️❄️ 2024年11月30日 (六) 19:32 (UTC)

但我一般是在處理欄下面回覆的，目前也沒有共識要改到上面，而且註釋寫了應該寫在下面，所以就還是移回去。反正沒太大差別。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月30日 (六) 19:58 (UTC)

好吧，我當時移動的原因是我覺得上方下方並不重要，我在意的是「保持時間線穩定」（也可以把上方評論挪到下方，但這樣一來肯定會有其他人點「回復」放到上方，所以就把您評論挪上方了） ——自由雨日🌧️❄️ 2024年11月30日 (六) 22:14 (UTC)

另外有一個辦法，就是不先列出「處理」項，等真的有人要處理再加上，這樣就不會干擾到意見區。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月1日 (日) 17:52 (UTC)

也(＋)支持這一方案，總之能讓意見區像條目探討等任何討論一樣「按正常時間順序、正常縮排」即可。--自由雨日🌧️❄️ 2024年12月2日 (一) 00:45 (UTC)

其實只要把提報人和提報時間戳拆成兩行，就可以禁用提報區的回覆按鈕（版本85183558），甚至整個區都沒有回覆按鈕，逼迫被褻瀆的現代討論工具侵蝕了靈魂的^{[開玩笑的]}維基百科人用無上、至理、聖潔的^{[開玩笑的]}源代碼模式發表評論。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年12月3日 (二) 07:21 (UTC)

界面的去人性化，時代的退步。^{[開玩笑的]}而且提報人和提報時間分兩行會很影響閱讀體驗，很反編者直覺。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月3日 (二) 07:59 (UTC)

(－)強烈反對：極易導致億惡的編輯衝突。--自由雨日🌧️❄️ 2024年12月3日 (二) 08:51 (UTC)

那可能是Wikiplus等快速編輯工具導致的，用系統自帶的源代碼模式編輯，能夠自動合併無衝突段落的編輯衝突。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月17日 (二) 11:23 (UTC)

民意調查

由於不同意見太多，故進行民意調查。最終並非完全以投票（支持/反對）數量決定，僅是輔助參考。若有其他方案可直接在下方補充。——自由雨日🌧️❄️ 2024年12月3日 (二) 02:44 (UTC)

方案一：維持現狀，編者自由選擇在「處理」欄上方或下方留言，且管理員處理後仍可自由回復

1. (－)強烈反對：已有諸多問題。如時間線混亂、縮排混亂、「處理」欄不明顯等。——自由雨日🌧️❄️ 2024年12月3日 (二) 02:44 (UTC)
2. (－)反對：時間線很難區分，且毫無層次感。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月3日 (二) 03:44 (UTC)
3. (－)反對:無法區分時間 — 此請爐安 August0422 (T / S) 2024年12月4日 (三) 10:43 (UTC)
4. (－)強烈反對：這一欄不是應該是名副其實地是各用戶爭論討論後的管理員處理行動嗎？--Mykola（留言） 2024年12月5日 (四) 14:31 (UTC)

方案二：討論統一在「處理」欄上方按時間順序留言（一般為直接點按「回復」），對「處理」的討論則在下方留言

1. (＋)支持：基本完全符合討論時間線 ——自由雨日🌧️❄️ 2024年12月3日 (二) 02:44 (UTC)
2. (＋)支持：合乎邏輯，理由(▲)同上。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月3日 (二) 03:44 (UTC)
3. (＋)支持：合理。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月3日 (二) 12:38 (UTC)
4. (＋)支持:合理 — 此請爐安 August0422 (T / S) 2024年12月4日 (三) 10:43 (UTC)
5. (＋)強烈支持：以上同理。--Mykola（留言） 2024年12月5日 (四) 14:31 (UTC)

方案三：在管理員處理前取消「處理」欄，其他同方案二

1. (＋)支持。和方案二相比好處是（規定在「處理」欄上方留言後）不會再有編者放錯位置，但壞處是可能使「是否已有處理」更不明顯 ——自由雨日🌧️❄️ 2024年12月3日 (二) 02:44 (UTC)
2. (？)疑問：這似乎本質上和方案二可以同時實現。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月3日 (二) 03:44 (UTC)

   看我上面的留言的最後半句（）有那個問題，所以區分成兩個方案了。--自由雨日🌧️❄️ 2024年12月3日 (二) 04:09 (UTC)

   (＋)支持-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月3日 (二) 07:57 (UTC)

3. (＋)支持：相對靈活。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月3日 (二) 12:38 (UTC)
4. 如果要這樣實現乾脆直接廢止處理一欄吧--SunAfterRain 2024年12月4日 (三) 17:36 (UTC)
5. (＋)傾向支持：也稍微同理，這樣做減少混亂。--Mykola（留言） 2024年12月5日 (四) 14:31 (UTC)
6. (＋)強烈支持：參考Wikipedia:申請解除權限等其他布告板。Пусть от победы☆к победе ведёт! 2024年12月8日 (日) 04:20 (UTC)
7. (＋)支持：曾見過有提報因為很多用戶參與討論，導致處理欄消失不見的情形，推測是有用戶在討論時無意間移除。身為管理員，在進行結案時還得要尋找處理欄在哪裡，感覺不如自己多打個幾個字更快更簡單。至於自由雨日所擔心的「使是否已有處理更不明顯」疑慮，其實就是看處理的管理員如何標示了。個人認為，靈活標示反而更可能解決結案不明顯的問題，因為結案管理員能夠視情況彈性處置。-Peacearth（留言） 2024年12月20日 (五) 17:59 (UTC)

方案四：討論統一在「處理」欄下方留言（並修改「發現人」位置以便點按回復），並在管理員處理後禁止回復「處理」欄

1. (－)傾向反對：沒有必要「禁止回復」。但若不禁止，又會造成時間線混亂的問題 ——自由雨日🌧️❄️ 2024年12月3日 (二) 02:44 (UTC)
2. (－)反對：時間邏輯不合理。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月3日 (二) 03:44 (UTC)
3. (！)反對反對：後續翻查存檔時提報內容和處理結果最為重要，時間和回復邏輯相對來說並不重要。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年12月3日 (二) 08:45 (UTC)

   個人不這麼認為。最終處理結果當然重要，但幾乎所有討論（尤其是方針指引修改）都有一個「最終共識」，我不認為「最終共識」的重要性會高到可以無視「討論內容的時間線、縮進等排版」。--自由雨日🌧️❄️ 2024年12月3日 (二) 08:49 (UTC)

4. (－)反對：不應禁止回覆任何留言。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月3日 (二) 12:38 (UTC)
5. (－)反對禁止回覆 — 此請爐安 August0422 (T / S) 2024年12月4日 (三) 10:43 (UTC)
6. (－)反對很混亂，不需要特地這樣搞--SunAfterRain 2024年12月4日 (三) 17:36 (UTC)
7. (－)強烈反對--Mykola（留言） 2024年12月5日 (四) 14:31 (UTC)

方案五：取消「處理」欄，並使用{{archive top}}關閉討論

1. (＋)支持：除了有方案三的好處外，更解決了方案三的壞處，甚至遠比過去的方案可使「是否已有處理」明顯得多。但弊端是「對管理員處理的回覆」較過去不便 ——自由雨日🌧️❄️ 2024年12月3日 (二) 02:44 (UTC)
2. 有條件反對：{{archive top}}的result參數只能表示處理的結果。但後續針對處理的討論串如何用此模板關閉則有待商榷；若無定案則反對。-- $[{\text{H}}^{+}]$$\ >$${\sqrt {K_{w}}}$ 2024年12月3日 (二) 03:44 (UTC)

   既然已處理，就不必需要再回復。如果有對管理員的處理有意見，我認為有三種方法：一、在ANM重提討論，開啟新討論串；二、在管理員的用戶討論頁開啟新討論串；三、在客棧提出管理操作覆核程序。--0xDeadbeef (留言) 2024年12月3日 (二) 08:50 (UTC)

3. 我已經在上方提出此選擇的附帶好處：有結果和無結果的案件區別明顯，管理員所處理的結果顯眼可找，並且不會存在兩個討論串時間穿越的情況，故支持。0xDeadbeef (留言) 2024年12月3日 (二) 08:52 (UTC)
4. (＋)支持：但傾向關閉討論後，若對管理員處理有意見，不要在ANM再開討論，而是到管理員的使用者討論頁開討論串或提AARV（但順位在管理員的使用者討論頁之後）。--冥王歐西里斯（留言） 2024年12月3日 (二) 09:17 (UTC)
5. (－)傾向反對：相對不易使用，並可能阻撓管理員處理後其他留言，注意管理員張貼處理結果並不總是等於直接結案，應當一定程度允許其後交流。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月3日 (二) 12:38 (UTC)

   為什麼說不易使用？其後交流的意義又是如何？--0xDeadbeef (留言) 2024年12月4日 (三) 00:56 (UTC)

   @Ericliu1912：由於這並非純投票，所以我認為您還是得回應一下beef這裡的問題？——自由雨日🌧️❄️ 2024年12月7日 (六) 18:01 (UTC)

   要用模板就是比較麻煩。而且把整個討論框起來會讓人誤以為管理員處理後即不允許留言。相對於其他方案，這是無必要的缺點。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月8日 (日) 04:51 (UTC)

   其實可以寫一個腳本方便關閉[16]

   對於框起來的事情，我個人覺得本來就是為了discourage人去繼續評論。如果真有人覺得自己有必要、有價值的評論完全可以在其他地方延續。--0xDeadbeef (留言) 2024年12月8日 (日) 09:54 (UTC)

6. 個人認為不是不行，但方案三似乎也允許方案五這種操作？與其強制規定要使用{{archive top}}關閉，方案三反而更有彈性應對各種不同情形？-Peacearth（留言） 2024年12月20日 (五) 17:59 (UTC)

總結

似乎共識是傾向方案三和方案五（方案三支持的人略多），另@U:魔琴已在WP:ANM嘗試了一次方案五。接下來是允許兩種方案並存（管理員自由使用）呢，還是繼續討論，還是規定使用方案三……？——自由雨日🌧️❄️ 2024年12月16日 (一) 14:35 (UTC)

方案二和三似乎沒有差別？我個人是擔心沒法一眼看到處理欄。我使用方案五是因為劃了hr還有三個「處理」欄實在太亂，因此框起來總結。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月17日 (二) 11:27 (UTC)

三比二支持的人更多點吧？另外就是考慮到如果要貫徹落實的話，為避免有人維持舊有習慣，還是取消處理欄更好（即三和二當中淘汰二）。--自由雨日🌧️❄️ 2024年12月17日 (二) 11:34 (UTC)

個人會建議推進方案三，這是較多人支持而且對排版改動較少的方案。Sanmosa _蚌埠 2024年12月17日 (二) 15:04 (UTC)

---

個人初步想法：

• 在管理員布告板提報時，不設置「處理」欄，其他排版不變。
• 不論是被提報用戶還是其他用戶，均通過點按「回復」提報人來留言，並遵循相關的討論頁指引，舊留言在前新留言在後、正確縮排等。
• 建議管理員在處理時，在所有留言最末頂格使用一個項目符號來標示處理結果。處理後，其他用戶可繼續在處理欄下對結果進行討論。但也允許管理員使用{{archive top}}關閉討論，不過關閉後不禁止其他用戶在框外繼續對處理結果等進行討論。
• 以上排版適用於ANM、AN3、VIP布告板（2024年12月31日 (二) 07:06 (UTC)補充：WP:DRV、WP:COIN）。

以上。——自由雨日🌧️❄️ 2024年12月19日 (四) 00:17 (UTC)

不反對這個提議。Sanmosa _蚌埠 2024年12月19日 (四) 10:57 (UTC)

不反對，不過不知道有無更好的突出顯示處理欄的方法？ ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月19日 (四) 14:52 (UTC)

我剛想說應該限制WP:管理員布告板/其他不當行為#Wildcursive這裡你和薏仁將頂格書寫的排版（因為會導致時間線混亂），然後發現限制也正好可以避免處理欄不清晰。--自由雨日🌧️❄️ 2024年12月20日 (五) 05:47 (UTC)

可是如果等到有人回覆了，處理欄就被淹沒了。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月20日 (五) 12:52 (UTC)

頂格書寫怎麼會淹沒？--自由雨日🌧️❄️ 2024年12月20日 (五) 13:03 (UTC)

也對，但得確保沒有其他人頂格書寫。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月20日 (五) 13:08 (UTC)

一般點按回復就不會頂格書寫。當然總有人不按回復又愛頂格書寫的，客棧也很常見。--自由雨日🌧️❄️ 2024年12月20日 (五) 13:12 (UTC)

附加一個提議分頁討論 -Lemonaka 2024年12月22日 (日) 01:57 (UTC)

話說，WP:存廢覆核請求是否也要作此處理？--自由雨日🌧️❄️ 2024年12月27日 (五) 04:20 (UTC)

(＋)支持，現在處理結果：這一欄經常被無視，導致排版混亂。Пусть от победы☆к победе ведёт! 2024年12月28日 (六) 09:40 (UTC)

另外還漏了WP:COIN Пусть от победы☆к победе ведёт! 2024年12月28日 (六) 05:59 (UTC)

我的另一個方案是把「處理結果」放在「討論」上面，這樣即無問題。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月29日 (日) 01:59 (UTC)

嗯？這不就是方案四嗎？--自由雨日🌧️❄️ 2024年12月29日 (日) 02:25 (UTC)

討論已達30日， 公示7日，2025年1月7日 (二) 07:06 (UTC)結束。Lemonaka的「分頁討論」和本案相對獨立，可繼續討論，不影響公示。 ——自由雨日🌧️❄️ 2024年12月31日 (二) 07:06 (UTC)

Wpcpey和Longway22禁制復核

根據Wikipedia:禁制紀錄，Wpcpey（討論 | 貢獻）和Longway22（討論 | 貢獻） 被 Mys_721tx（討論 | 貢獻） 全站範圍禁制，

然而，
維基百科:禁制方針

全站範圍禁制褫奪在中文維基百科的一切編輯權利，被禁制人士不論使用任何帳號或IP位址均禁止在任何情況下編輯中文維基百科的任何部分，依照 § 禁制申訴規範在其使用者討論頁提出的申訴為唯一例外。全站範圍禁制可用於以下情況：

• 屢次繞過封鎖：全站範圍禁制在使用者主帳號被不限期封鎖，且使用者查核最少三次確認濫用多重帳號的情況自動生效。
• 全域鎖定：全站範圍禁制在使用者帳號於中文維基百科被不限期封鎖，且因跨維基破壞或濫用多重帳號而被全域鎖定的情況自動生效；因帳號被盜而被全域鎖定者不在此限。

這不符合規範，請澄清。 -Lemonaka 2024年12月5日 (四) 08:16 (UTC)

既然實用，可以增列適用情況。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月5日 (四) 10:08 (UTC)

Eric，這種判斷完全不能接受，我需要澄清封鎖和全站封禁之間的區別，而你指出的是「先前的判斷是正確的」。然而，在改變政策的共識達成之前聲稱某事是正確的，並利用這種預先聲明來實施某種制裁，這確實違背了當前項目的章程。如果可能的話，我希望請關注這個問題。 -Lemonaka 2024年12月5日 (四) 10:22 (UTC)

是的，我們當然可以添加這樣的補充，但是在添加之前他們已經受到了制裁，所以這兩者之間仍然需要澄清。 -Lemonaka 2024年12月5日 (四) 10:24 (UTC)

我需要澄清這兩種封鎖之間的區別，以及它們應該在什麼情況下使用。 -Lemonaka 2024年12月5日 (四) 10:26 (UTC)

所以就因為我們開除了Mys_721tx的管理員，您就希望解除有關禁制？--Liuxinyu970226（留言） 2024年12月6日 (五) 04:31 (UTC)

不要聽風就是雨。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月6日 (五) 04:44 (UTC)+1 自由雨日為此+1了。

謝謝。 -Lemonaka 2024年12月7日 (六) 01:26 (UTC)

你的說法讓我無比難過，但願主與你同在，這也不是你的錯。
當年因為我反對解任Mys_721tx而被WMLO屢次進行死亡威脅和郵件騷擾，我頂著壓力和社群調查此案。如今你說出這樣的話，毫無邏輯也十分異常，我真的很痛心。
這不是你的錯，請原諒我，我累了。告辭。 -Lemonaka 2024年12月7日 (六) 01:23 (UTC)

誠實地，我不能知道兩件事間有何連結。 -Lemonaka 2024年12月7日 (六) 01:30 (UTC)

@Liuxinyu970226：我完全可以認為你這句話有違善意推定，甚至客觀上起到造謠誹謗的效果。--自由雨日🌧️❄️ 2024年12月7日 (六) 02:04 (UTC)

您覺得這句話有違那我收回了，反正與己無關。--Liuxinyu970226（留言） 2024年12月7日 (六) 02:08 (UTC)

我的意思是，既然有實際用途，可以按情況添進方針。我也知道應予澄清，此或可移往方針區討論。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月7日 (六) 21:18 (UTC)

請移動 -Lemonaka 2024年12月8日 (日) 09:13 (UTC)

本人認為，有關禁制當屬廣域頁面禁制，而非真正的「全站範圍禁制」，僅是用詞類似。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月7日 (六) 21:20 (UTC)

Mys_721tx存在惡意推定、曲解方針等問題，因此其做出的封禁容易被質疑，也是其被解任的原因。--Lanwi1^Talk 2024年12月7日 (六) 11:07 (UTC)

我從未見過稱「永久封鎖」禁制的，亦未見合法。我也並不要求解封，只想澄清一下。 -Lemonaka 2024年12月7日 (六) 11:18 (UTC)

你說的沒錯，即使Mys_721tx的封禁有問題，還是要按方針解封。我認為Mys_721tx過嚴，壓力過大也會容易做出問題行為。--Lanwi1^Talk 2024年12月8日 (日) 07:55 (UTC)

這和 @Mys 721tx沒有關係，Shizhao這麽做我也會起疑。 -Lemonaka 2024年12月9日 (一) 09:51 (UTC)

不限期全站封鎖相當於永久封禁，確實需要慎重決定，全站封鎖只應對長期破壞同持續使用傀儡的用戶，或者需要設立覆核機制，避免完全由單一管理員作出這類操作。Wpcpey及Longway22的個案，按機制需要兩人提出申訴才能解封，不過一般維基人因爭議事件而需要離開一段時間後，也未必有心情回來。--Uranus1781（留言） 2024年12月10日 (二) 05:27 (UTC)

此事關鍵，沒有有效的回應，不應關閉。 -Lemonaka 2024年12月12日 (四) 22:44 (UTC)

@Lemonaka：您要求有效的回應，您是想Mys_721tx在此親自解釋嗎？至於受到直接影響的Wpcpey及Longway22，他們兩位目前並不可能在此發言；或者，您有沒有指定的對象，要求他們在此澄清；您亦可提出對全站封鎖的處理方案，例如建議增修相關的方針指引；一般用戶不太可能代替Mys_721tx澄清這兩次操作，如果他不解釋，又沒有夠分量的人員協助釐清，您又不提出跟進的方案，這個章節長期開放不存檔，也不太可能獲得有用的結論。--Uranus1781（留言） 2024年12月13日 (五) 09:18 (UTC)

是的。兩種方法

1. Mys_721tx在此親自解釋
2. 全站封鎖增修

-Lemonaka 2024年12月13日 (五) 11:44 (UTC)

全站封鎖條文增補

提議

舊 全站範圍禁制褫奪在中文維基百科的一切編輯權利，被禁制人士不論使用任何帳號或IP位址均禁止在任何情況下編輯中文維基百科的任何部分，依照 § 禁制申訴規範在其使用者討論頁提出的申訴為唯一例外。全站範圍禁制可用於以下情況： 屢次繞過封鎖：全站範圍禁制在使用者主帳號被不限期封鎖，且使用者查核最少三次確認濫用多重帳號的情況自動生效。 全域鎖定：全站範圍禁制在使用者帳號於中文維基百科被不限期封鎖，且因跨維基破壞或濫用多重帳號而被全域鎖定的情況自動生效；因帳號被盜而被全域鎖定者不在此限。

新 全站範圍禁制褫奪在中文維基百科的一切編輯權利，被禁制人士不論使用任何帳號或IP位址均禁止在任何情況下編輯中文維基百科的任何部分，依照 § 禁制申訴規範在其使用者討論頁提出的申訴為唯一例外。全站範圍禁制可用於以下情況： 屢次繞過封鎖：全站範圍禁制在使用者主帳號被不限期封鎖，且使用者查核最少三次確認濫用多重帳號的情況自動生效。 全域鎖定：全站範圍禁制在使用者帳號於中文維基百科被不限期封鎖，且因跨維基破壞或濫用多重帳號而被全域鎖定的情況自動生效；因帳號被盜而被全域鎖定者不在此限。 廣域頁面禁制：同時在主空間和討論空間持續擾亂，實質上全站範圍禁制自動生效。

---Lemonaka 2024年12月13日 (五) 11:48 (UTC)

我有一個反建議：既然相關全站範圍禁制不合現行規定，那就沒有理由維持相關全站範圍禁制，對該二人的全站範圍禁制應予解除。Uranus1781上面説的話很有道理。Sanmosa _蚌埠 2024年12月17日 (二) 15:34 (UTC)

這不矛盾，但有人說「就因為我們開除了Mys_721tx的管理員，您就希望解除有關禁制？」 -Lemonaka 2024年12月17日 (二) 19:23 (UTC)

話不能這樣説，相關全站範圍禁制不合現行規定的問題你不提出來大家也沒留意，我的意見僅僅針對相關全站範圍禁制不合現行規定的事情。也就是説，即使你是在Mys_721tx沒下台的情況提出這個問題，我這裏的意見也不會有任何的變化，雖然這種情況下我很有可能被部分自發側翼猛烈攻擊，但我對於這種攻擊性言論是怎樣的態度你也是清楚的。Sanmosa _蚌埠 2024年12月18日 (三) 02:27 (UTC)

@User:Shizhao @AT -Lemonaka 2024年12月19日 (四) 06:40 (UTC)

管理操作覆核請求

此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。

操作： Wpcpey禁制、Longway22禁制

執行者： Mys 721tx （討論 · 貢獻 · 日誌）

先前討論：Wikipedia:管理員解任投票/Mys_721tx/第2次、Wikipedia:互助客棧/其他#Wpcpey和Longway22禁制復核---Lemonaka 2024年12月26日 (四) 01:07 (UTC)

在下附議上面的提議:既然相關全站範圍禁制不合現行規定，那就沒有理由維持相關全站範圍禁制，對該二人的全站範圍禁制應予解除 "Wpcpey和Longway22禁制覆核"(1） 以及 (2)。感謝Lemonaka發現和向社群通報管理操作不合現行規定的案件。--Gluo88（留言） 2024年12月22日 (日) 03:33 (UTC)

有鑒於管理操作覆核請求有專門的程序，我在此重申自己支持解除對該二人的全站範圍禁制的意見。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月22日 (日) 14:10 (UTC)

Per @Gluo88、 @Sanmosa 改爲(＋)支持解除對該二人的全站範圍禁制 -Lemonaka 2024年12月23日 (一) 00:50 (UTC)

@Jimmy Xu@Shizhao此事複雜，請審核。 -Lemonaka 2024年12月23日 (一) 10:18 (UTC)

我傾向支持解除有問題的此禁制，問題管理員容易濫用規則。--Lanwi1^Talk 2024年12月23日 (一) 13:13 (UTC)

@Lanwi1、Uranus1781。Sanmosa _{在黑魔法的幫助下密謀推翻軍政府} 2024年12月23日 (一) 00:51 (UTC)

支持Wpcpey、Longway22個案的覆核，主因是這兩起全站禁制不符合禁制方針，這並不等於全面否定Mys 721tx之前對其他用戶的禁制，不能說成是因為其現在已不是管理員就尋求推翻其操作；即使管理員在是非的判定正確，採取不限期封禁或禁制的行動及必要性卻值得商榷。--Uranus1781（留言） 2024年12月24日 (二) 05:10 (UTC)

對兩人的禁制是否屬上方所提及的「有關禁制當屬廣域頁面禁制」？--千村狐兔（留言） 2024年12月31日 (二) 10:38 (UTC)

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

廢棄草稿

我發覺機器人似乎不再自動提刪超過半年沒有被編輯的草稿（ns118）了，不知道這是不是我的錯覺。--Txkk（留言） 2024年12月16日 (一) 10:39 (UTC)

如果機器人不自動提刪過期草稿，草稿就會越積越多，越積越多，越積越多……--Txkk（留言） 2024年12月16日 (一) 11:44 (UTC)

我倒是支持廢除速刪舊草稿，至少不要自動化速刪。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月16日 (一) 14:34 (UTC)

曾經沒有O7的時候有用戶在AFD提刪大量廢棄草稿，也不是合適處理方式。--GZWDer（留言） 2024年12月20日 (五) 13:29 (UTC)

至少用戶頁的草稿也會有矛盾之處，比如用戶沙盒不會被刪除，但用戶頁的草稿卻會被刪除。對新手用戶尤其影響大。--千村狐兔（留言） 2024年12月20日 (五) 13:36 (UTC)

同意，我覺得至少應該排除掉用戶頁草稿。如果社群認為真要保留O7，或許可限定草稿名字空間。然而，AFD大量提刪廢棄草稿的行為似乎也不足以論證O7的必要性，畢竟反過來說可以勸導乃至阻止相關用戶進行如此非必要的批量提刪行為。-Peacearth（留言） 2024年12月20日 (五) 17:31 (UTC)

我認為應當如此：

• 只有草稿名字空間可以因廢棄草稿的原因自動提交速刪；
• 用戶名字空間的不應該以「廢棄草稿」的名義自動提交速刪；
• 因廢棄草稿而提交速刪的不應該使用機器人自動刪除，而應該交由人工複查

--百無一用是書生 (☎) 2024年12月24日 (二) 08:54 (UTC)

補充：如果不刪除Draft空間的廢棄草稿，會不會有新手不會更新？要不參考O3的模式，機器人自動以O7的名義存檔廢棄草稿？ ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月24日 (二) 11:07 (UTC)

話說，現在是有機器人自動掛速刪廢棄草稿的模板，還是掛有草稿模板的頁面在一段時間後無編輯就自動顯示速刪模板？--百無一用是書生 (☎) 2024年12月25日 (三) 03:26 (UTC)

大部分是後者。--千村狐兔（留言） 2024年12月28日 (六) 13:01 (UTC)

另外不少新手用戶把完善、增加的內容搬到主條目，但因草稿未獲審批而遭不少提刪。似乎要增加相關刪除要求，比如條目比草稿更多內容、完善後不應一律以G18提刪條目，提刪者需要作檢查。--千村狐兔（留言） 2024年12月31日 (二) 10:29 (UTC)

@Peacearth、Shizhao：各位，各位，是「命名空間」，老版術語措辭「名字空間」早就被丟棄了。--Txkk（留言） 2024年12月31日 (二) 01:31 (UTC)

 吐槽：在zh-tw模式下您的發言顯示為「各位，各位，是「命名空間」，老版術語措辭「命名空間」早就被丟棄了。」，這個字詞轉換😂-Peacearth（留言） 2024年12月31日 (二) 05:02 (UTC)

呃……我沒注意到這個情況，剛剛加上隔斷代碼了。--Txkk（留言） 2024年12月31日 (二) 05:43 (UTC)

@魔琴：如果廢除速刪舊草稿，草稿命名空間就成大型垃圾場了😒😒😒 --Txkk（留言） 2024年12月31日 (二) 01:31 (UTC)

現在記得是半年無編輯才提交速刪吧？這麼長時間都不編輯，認為廢棄相當合理--百無一用是書生 (☎) 2024年12月31日 (二) 02:45 (UTC)

重啟Automoderator部署討論

於Phabricator查看
編號T367306的工單

十餘月前，該討論向社群引介了自動化反破壞Automoderator工具，然其因熱度不足而無疾而終。因此，我謹引用原留言：

大家好，我的名字是Sam Walton，是管理員工具（Moderator Tools）團隊的產品經理。我們正在開發一個名為Automoderator的項目，該項目讓社群能夠根據社群自定義的規則自動回退破壞性編輯。我們正在尋求對我們項目的意見，並有一些問題需要巡查員和管理員的參與，以幫助我們更好地理解。除了項目主頁面上的概述和問題之外，我們還有兩個子頁面提供更具體的資訊：

如果您想研究Automoderator的準確率，並查看它在不同編輯上的表現，我們設置了一個測試流程。您可以幫助我們找到新的模式，並在Automoderator部署之前將其納入考慮範圍（譯註：例如怎樣改善誤判問題、使用什麼程度的準確率（cution levels）比較好）。 評估計劃是用來確定Automoderator是否實現目標且不會產生負面影響的計劃初稿。如果您對我們收集的數據或制定的指標有任何想法，那麼您可以在這裡分享！

如果您對Automoderator有任何疑問，或者您的社群是否想要使用這個工具，請告訴我！
— User:Samwalton9_(WMF)

還請社群評估該工具部署之可能性及價值為荷。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月18日 (三) 19:45 (UTC)

理念上支持。所提供通用模型隨機樣本的表格數據，我看了一些高風險的，感覺挺多是不該被回退的。多語言模型的樣本好很多，並且預計回退數量似乎很低？如果有人及時巡檢和調控該工具，可以考慮引入。--YFdyh000（留言） 2024年12月18日 (三) 23:54 (UTC)

兩者個人也曾測試，無論前者和後者只要是使用「Cautious」或以上的閾值，基本上近乎是沒有誤判。以自動反破壞工具而言，其誤判率個人認為可接受，現實上也不可能存在沒有誤判的工具。而預設值為最嚴謹的「Most Cautious」，基本上不會有什麼大問題。

「如果有人及時巡檢和調控該工具，可以考慮引入」，個人作為管理員願意幫忙調整。謝謝。--SCP-0000（留言） 2024年12月19日 (四) 14:12 (UTC)

有沒有在本站模擬環境下的測試數據？有這些數據大家才好判斷。--碟之舞📀💿 2024年12月19日 (四) 04:54 (UTC)

按這些步驟。Google表格，文件-複製（製作副本），Test Automoderator工作表，選擇zhwiki，有30組數據集（目前是今年7月的數據），每組30筆編輯，每筆審閱後可查看該工具在各警惕級別下是否會自動回退。似乎夠謹慎，但也存在誤判和漏判。--YFdyh000（留言） 2024年12月19日 (四) 05:15 (UTC)

基本支持。我相信足夠多的trial and error能克服誤判與漏判的情況。Sanmosa _蚌埠 2024年12月19日 (四) 11:11 (UTC)

感覺可推進下一步。Deploying說無需正式RFC，只需有足夠多參與者感興趣。用戶名要保持原名嗎，譯名會更易懂（如「自動回退」？），但簡繁選用等層面是否不方便。不清楚其會發送簡體還是繁體版本的留言消息。所需用戶頁譯本已準備Draft:User_AutoModerator（回退、撤銷的用詞可能需斟酌），後續可單獨討論和改進。--YFdyh000（留言） 2024年12月20日 (五) 00:34 (UTC)

自動版主？自動管理員？自動編輯檢查？其實用Automoderator也可以（）——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月20日 (五) 02:42 (UTC)

版主太生硬了。且版主常被指責濫權，會誤導新手；管理員誤導性，並沒有封號等機制；編輯檢查與現有機制（tag、濫用過濾器）重名了。維持原名確實可以，中庸之舉，但好的譯名會更好，不看用戶頁或留言也能迅速了解是被自動化程序回退了。「自動回退器」感覺偏生硬。「回退機器人」太直白和不好理解、難以聯想到原名。--YFdyh000（留言） 2024年12月20日 (五) 04:00 (UTC)

自動巡查器或者自動回退器吧，用繁體就行，就一個動字簡化了，簡體使用者應該都能看得懂。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月20日 (五) 12:48 (UTC)

前者與巡查混淆。後者我沒意見。簡體的、原名的賬戶名可能應設法占用並重定向過去。--YFdyh000（留言） 2024年12月20日 (五) 13:26 (UTC)

感覺稱作自動巡檢器會比較好。--雨朝_{Talk#我要退出CRYCHIC} 2024年12月20日 (五) 14:35 (UTC)

Moderator的角色一般是維護頁面，因此我會建議譯為「自動維護工具」或「自動維護器」，再不然像Twinkle那樣沿用英文名也可以。如果不要求忠實翻譯的話，其實叫「自動法器」也成。^{[開玩笑的]}亲，我簽名那刻的時間是 2024年12月21日 (六) 14:13 (UTC)

傾向反對按原文字面而非功能來譯。以上兩個譯名太像一個大類。如果無共識，該考慮用戶名沿用英文，以及用戶頁、討論等允許怎樣的中文稱呼。--YFdyh000（留言） 2024年12月21日 (六) 19:03 (UTC)

回退破壞性編輯也算一種維護吧，我不認為我沒有按功能來譯，但比較微妙的是我個人確實偏好沿用英文名。亲，我簽名那刻的時間是 2024年12月22日 (日) 09:54 (UTC)

所以各位打算選哪個用戶名。--YFdyh000（留言） 2024年12月27日 (五) 19:01 (UTC)

我比較喜歡英文的，不用擔心繁簡轉換，也能迴避翻譯問題。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月27日 (五) 19:44 (UTC)

公示3日：使用原始英文用戶名，公示結束後申請引入。--YFdyh000（留言） 2025年1月1日 (三) 18:16 (UTC)

支持導入。--Hamish T 2024年12月20日 (五) 15:21 (UTC)

支持導入用以試驗。-Peacearth（留言） 2024年12月20日 (五) 17:50 (UTC)

en:user:ClueBot NG -Lemonaka 2024年12月23日 (一) 01:02 (UTC)

(＋)支持導入。--Martin^{我強烈反對WMF給出個人信息，支持閉站抗議} 2024年12月27日 (五) 18:41 (UTC)

提議將每日提示內容同步到首頁「提示」版塊展示

原標題為：編輯提示已建設完畢，現提議將內容同步到首頁「每日提示」版塊展示

經過Tisscherry君最近一段時間的不懈努力，Wikipedia:提示的所有每日提示內容已經建設完成（終於完成了一個天坑orz）。有鑑於此，如Wikipedia:每日提示維護小組#任務所述，現提議將「提示」內容同步到首頁「每日提示」版塊更新，特此徵求社群意見。--Jeffchu2014（留言） 2024年12月19日 (四) 10:43 (UTC)

等等，7月還有6天，這禮拜會完成，請稍等我一下。--提斯切里（留言） 2024年12月19日 (四) 11:06 (UTC)

已經全部完成，並且再次檢查過。--提斯切里（留言） 2024年12月20日 (五) 16:00 (UTC)

真的不容易，該給與掌聲鼓勵:)--薏仁將🍀 2024年12月21日 (六) 04:39 (UTC)

---

可以參考這個版本展示，同時每日的內容全部參照WP:歷史上的今天設置半保護。--Jeffchu2014（留言） 2024年12月21日 (六) 04:56 (UTC)

剛發現這個版本沒有替換掉「參與維基百科」版塊，這個替換掉了，以這個版本進行討論。--Jeffchu2014（留言） 2024年12月21日 (六) 19:00 (UTC)

內容還請大家多幫忙看看，大多數內容都是機翻，讀起來很不通順，還有些是照搬英文的過期內容，現在已經無法復現。--Jeffchu2014（留言） 2024年12月21日 (六) 19:29 (UTC)

（修改了標題，因為編輯提示指的是Editnotice）--SunAfterRain 2024年12月22日 (日) 04:51 (UTC)

可能1～7月的部分機翻問題要再確認，我是從7月20日左右接手，還有另一位使用者@琉綺在11月和12月的部分幫了不少忙。我初步檢查大部分都是符合中維現況的。--提斯切里（留言） 2024年12月22日 (日) 09:43 (UTC)

他是不是不太熟悉維基的術語啊，article是「條目」，怎麼老是說「文章」，太不專業了。--Jeffchu2014（留言） 2024年12月22日 (日) 19:19 (UTC)

可能還略有疏漏，我再檢查確認。--提斯切里（留言） 2024年12月24日 (二) 12:46 (UTC)

@Tisscherry：詢問一下是否確認完畢。--人間百態,獨尊變態(討論)(簽名) 2024年12月31日 (二) 11:57 (UTC)

漏回覆了請見諒。目前機翻問題都已排除，地區詞轉換大部分都補上，往後也會再持續檢查。--提斯切里（留言） 2024年12月31日 (二) 12:25 (UTC)

管理操作覆核請求：對Wildcursive的處理

此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。

操作： [17]

執行者： Ch.Andrew （討論 · 貢獻 · 日誌）

先前討論：維基百科:管理員布告板/其他不當行為#Wildcursive

@Wildcursive：首先，這位用戶對於自己討論頁上由Cindyzs寫出的宣傳性內容置之不理，經我移除後再次加回。引用@薏仁將的話：……雖然WP:TPG對於用戶討論區使用自由度是相對寬鬆的，而本案被提報人對於相對當事者用戶採取寬容容忍的態度去看待那些個人主觀意識的政治觀點宣傳，然而被提報用戶是可以有多次機會對相對用戶進行勸告及以相關方針教導其用戶避免再度出現不適當的行為，但被提報用戶選擇被動、消極的方式選擇不作為的冷處理，此等則會被相對用戶認為不反對即表認同的錯誤認知而持續性的做出不適當的行為；雖然該用戶暫時已被封鎖一週，但是難保解封後不再出現相同的不適當行為，而身為當事者的您，難道某個角度立場來說是無任何責任？又或者這種消極寬容的態度不也是變相的縱容對方行為？

而管理員章安德魯對於此次提報，作出以下處理： 還原。以User:Wildcursive自行決定的版本為準/態度指引WP:OWNTALK：「對於用戶討論頁而言，這些方針的遵循度會比其他討論頁較為寬鬆」「以上方針並不限制用戶在自己的討論頁移除留言」、編輯指引WP:PUT：「您可以按照您認為合適的方式將討論串刪除、存檔，或者是簡要地總結以前的討論」等語可以清楚得知，用戶對於自身帳號的討論頁具有裁量權，保留或刪除內容由帳號所有者自行決定即可，其他非當事用戶無須干涉。

然而，很明顯，方針（這甚至只是指引)中註明的是「較為寬鬆」而非「完全無需執行」，當然無法輕率得出「保留或刪除內容由帳號所有者自行決定即可」的結論。同時，WP:NOT中寫明：「維基百科拒絕宣傳。維基百科不是演講台、討論區、宣傳工具、廣告場所或者展覽平台。此項適用於用戶名、條目、分類、檔案、討論頁、模板及用戶頁。」

綜上所述，管理員的此次決定是不恰當的，因此我提出操作覆核。 --WiiUf🐉 2024年12月20日 (五) 05:20 (UTC)

(～)補充：被提報用戶在ANM進行政治宣傳，而管理員完全沒有考慮這點。--WiiUf🐉 2024年12月20日 (五) 05:26 (UTC)

(＋)支持覆核。——自由雨日🌧️❄️ 2024年12月20日 (五) 05:54 (UTC)

(＋)支持覆核：剛注意到這邊有討論，把我剛在那裡留的意見改一下放這：

Ch.Andrew 解釋他的處置理由有不少問題：不限制使用者在自己的討論頁『移除』留言並沒有「不限制使用者『還原』因違反方針而被其他人移除的留言」之意，而他又以指引導出使用者對於自身帳號的討論頁具有裁量權，保留或刪除內容由帳號所有者自行決定即可，其他非當事使用者無須干涉，然而他引用的WP:PUT是指引，WP:SOAP是方針，指引和方針衝突時是方針優先，遭移除的內容是違反方針，用指引當理由說可以保留違反方針的內容根本是無效的：

1. 用這邏輯，每個使用者都可以在自己討論頁放這些違反方針的內容，因為自己的討論頁自己當然有裁量權啊。
2. 當 A 把自己討論頁上被移除之違反方針內容加回去，那就是 A 的編輯行為了，原本加的人違反方針，A 當然也違反方針。

我並質疑，這個案子原本已有其他管理員開始處理，為何不常活動的 Ch.Andrew 突然介入迅速處理掉這件案子。--LHD（留言） 2024年12月20日 (五) 05:57 (UTC)

(？)疑問:另一個矛盾的點，依照處理的管理員認定的標準，那麼:我只要找政治理念相同的用戶B，或者用戶C不反對我個人政治觀點，那麼我可以將那些政治觀點放置在用戶B與用戶C個人討論區，而且只要相對用戶不反對，那麼就不構成WP:SOAP相關限制(因為B、C君用戶有自己裁量自己討論區討論議題權利)？那麼請問WP:SOAP存在的意義是？那麼問題來了，如果依照處理管理員認定的方式，B君與C君不表態、不反對那麼那些已發生的宣傳行為就不算構成WP:SOAP條件(裁量權在對方用戶身上?)，那麼連帶的是否連WP:DE也構不上邊？然後更有趣的是:如果有人刪除那些政治觀點，我可以仿傚他作法警告那些依照理據刪除的用戶要他們不要「越俎代庖」(因為訊息接受者沒反對，裁量權在對方用戶身上)請問是這個意思嗎?請問可以如此作法嗎？蠻好奇這種「特殊」認定標準。--薏仁將🍀 2024年12月20日 (五) 07:29 (UTC)

可能離題請見諒，其實上次就想提出，不曉得這是否算討論頁的漏洞？我認為可能需要研討是否需要修改，因為雖然看似不妥，但對應現行方針指引確實沒有明確違規，管理員處不處理都很難。感覺上暫時實施封禁的管理員是用了共識封，不過這是中維沒有的方針。若沒有界定標準，往後也可能再發生，故我認為可能需要進一步另行討論。--提斯切里（留言） 2024年12月20日 (五) 09:36 (UTC)

是的，標準的漏洞，看看屆時發生處理的管理員怎麼認定怎麼解釋或者類推適用，有沒有慣例案例可循，的確需要填補漏洞，不然可能造成仿效效應。--薏仁將🍀 2024年12月20日 (五) 09:42 (UTC)

我認為不存在漏洞。明顯已經違反WP:NOT。--自由雨日🌧️❄️ 2024年12月20日 (五) 09:55 (UTC)

這樣就有處理落差了，我先前確實覺得這是為不妥，但現在可以理解了這是個人討論頁要如何處理的自由意志，而且以討論頁方針來說，到別人的討論頁進行「討論的狀況」不涉及宣傳，那麼實為不應該封禁的，管理員不處理也是正確的。

我這裡指的漏洞，是要考慮這樣認知差異的，而且確實不明確。--提斯切里（留言） 2024年12月20日 (五) 16:14 (UTC)

但像是比較敏感性質的議題又或者如本案般主觀意識政治內容的傳遞，那麼在認定標準上這是否為宣傳行為的一種？若屬於宣傳行為，那麼其他用戶是否可依據對應的方針指引予以移除？又或者必須知會訊息接受者相關內容可能有不適當之虞?倘若訊息接收者並無任何表態亦不反對，那麼這些有疑慮的內容是否仍可移除？這些可能屬於比較算認定上會造成的差異(或說灰色地帶)也許值得討論。--薏仁將🍀 2024年12月20日 (五) 23:01 (UTC)

也認同 這些可能屬於比較算認定上會造成的差異(或說灰色地帶)也許值得討論。。 儘管我認同「管理員不處理也是正確」, 既然社群有分歧，可以就這是個人討論頁要如何處理的自由意志，而且以討論頁方針來說，到別人的討論頁進行「討論的狀況」不涉及宣傳進行專門討論。--Gluo88（留言） 2024年12月21日 (六) 23:51 (UTC)

@Tisscherry 在下也認同 而且以討論頁方針來說，到別人的討論頁進行「討論的狀況」不涉及宣傳，那麼實為不應該封禁的，管理員不處理也是正確的。--Gluo88（留言） 2024年12月21日 (六) 23:45 (UTC)

版主(：)回應：本人參與維基已約二十年，我自己的討論版面有何文字、如何回應、取捨，向來是本人的自由，幾無人越權干涉，亦屬尊重版主之傳統，包括許多行政管理人員皆能分清界線並協助回退對本人討論頁的真實破壞，違反本人意志亂刪亂動才是無禮。我對於符合《世界人權宣言》、臺灣人民自主意志與「自己的國家自己救」理念及維基百科自由民主多元開放精神的善意留言基本上皆大致不反對、不反感、不反彈。美國法律規範的維基百科可不是獨裁中國、專制共產黨或其百毒等工具，也絕不容遭其可憐打手操控限制。若我不覺得留言不當，屬表達意見、交流新舊條目編輯方向、及我可接受的言論自由，其實輪不到遠不相干之他人管太寬任意置喙。

已不常回維基的我是被動回應、被迫說明，說清楚、講明白、暢所欲言、闡明理據是必要且正常的。既然遠非明顯破壞、亦屬無害（有被害人嗎？只有我吧！），我自然有在個人留言版對合理言論自由沉默不作為、不採取任何行動或回復原狀的權利！我有回應或不回應的自由。之前也有較清醒開明曾多少呼吸過較自由空氣的中國人來我版談上海獨立自治、女權、漢人殺滿人等。或香港人來談魚蛋革命等，具善意的鄰國維基人來我版面跟我談政治，我通常會予以回復，編維基百科不可或缺的事實、史實、真理與普世價值等皆屬越辯越明。

每個人自己的版面多少出現與條目直接或間接相關的文字很平常。大家摸著良心自問自己或他人名下的版面其實歷來有多少連個條目名稱都未出現的瞎扯蛋？要倒查22年嗎？我有本版言論方向尺度的管轄權與裁量權, 這歷來皆屬自主自治自理自決的心證自留地空間。事實上, 許多維基化留言提醒我出現哪些新條目可查閱或補充增刪, 又有哪些我已知的主題議題可加強。這些留言者與其純粹條列出那些條目要我關注, 不如寫成短文表達意見, 更能吸引我的關注而參與編輯, 我看不出兩種方式的關鍵字詞有何太大差別, 但絕對更有效, 引發更多點入的好奇或編輯的欲望, 對維基也自然是好的。無謂與過度禁制對維基生產力只是有害而無益。這跟平舖直敘廣告沒人看、沒人買單是同樣的道理，Did you know的DYK問題指南「請創作可以引起讀者興趣的問題」已驗證了十幾年。留言者想引起我的閱讀編輯興趣，或我的回應能否引起他人的閱讀編輯興趣，從這些留言是「待協作完善清單」的角度解釋，有何不可？誰曰不宜？這與真正編輯條目時需依多重可靠來源，既不違背，也能並存。「不管黑貓白貓，會捉老鼠就是好貓」，這是相同的實用主義功益考量，能促進維基發展才是硬道理。捏死窒息中維才是罪人吧。

寫動漫的能在彼此討論頁邊寫邊聊動漫，沒人說不可。寫日本女星的在留言板互稱某某美很漂亮、喜歡某某子，是不是宣傳？說今天又看了10部，打算下周增補創建其中7條，是不是宣傳？寫交通的小聊維基假期旅遊，說想去臺南高雄玩，是不是宣傳？寫生醫的討論疫情，寫文學的聊戲劇，皆很合理。為何寫法政的就不能在自版小聊法政，礙了誰嗎？這種種文字在本質上有重大區別嗎？

維基百科有多少比例不是「宣傳」？幾乎大多數的圖片文字皆可被解讀為具某種宣傳或反宣傳之意。在某些人眼中耳裏，不習慣的事物都很敏感、大驚小怪，但在早已熟悉如日常生活者看來卻是如呼吸般再自然平常不過。此定義模糊不明而極可能衍生超多重標準的思想與言論警察之例一開，徒費時間精力，如同讓真理部、老大哥與朝陽群眾管到每個人在私宅的言行、門口的對聯、信箱的廣告、牆上的壁畫、鄰居的私語、手機的通信，有人來串門子，還要被檢查，實屬荒謬。每個人的頁面用戶框等自由編排創作就是貼在家門口的宣言標語，用戶對待其個人版面的方式亦屬自介自治的一部份，兩者的性質、內在邏輯與適用對待應屬相近。若縱容少數人企圖在他人版上搞擴大文革糾鬥，將成永無寧日的浩劫。無處不在的監控只會製造更多爭端，茲生更廣衝突，轉移消耗編者注意力，終成反噬人人而成龐大數位極權主義的一九八四。

如果裹小腳的慈禧看到奧運女子金牌就罵人家傷風敗俗成何體統、或如果有個別極端伊斯蘭教徒看到餐廳在賣豬腳火腿貢丸就呼天搶地說違逆真主要斬首、要下地獄、要燒店家，顯非合理，政治控制與資訊封鎖是沒必要的，別讓中國迄今仍時常發生的作法自斃、請君入甕再實現，維基百科不該日益封閉退步。

管理員千村狐兔（[18]）與章安德魯（[19]）均已表明尊重版主的態度，這基本上也是由正規編者自理其個人討論頁的傳統，除非真屬破壞或已被自刪、警告表明不受歡迎者。企圖懲處被留言者或已表明自行判斷篩選者是很奇怪的事。當事人對此個案沒意見、不在意、不覺得被騷擾，那就不需要再浪費時間強入人於罪。

十多年來本版基本自在自適健康無礙，天下本無事，實不煩庸人自擾擾人。--WildCursive（留言） 2024年12月20日 (五) 11:54 (UTC)

實際上維基百科並不保障你在討論頁的言論自由，維基百科並非論壇，第五點：與維基百科無關的專案內容。請勿存放與維基百科無關的材料，包括使用者空間。請參閱WP:UPNOT了解不得包含的內容的範例。

，WP:UPNOT有此外，您不得在使用者空間中包含可能損害專案聲譽或可能引起廣泛冒犯的材料（例如種族主義意識形態）。無論是嚴肅的還是惡意的，「維基百科不是演講台」與百科全書條目一樣適用於使用者空間，而「維基百科不會審查內容」則適用於條目頁面和圖像；在其他命名空間中則存在一些限制，旨在確保與社群的相關性及不擾亂社群。您在使用者空間確實比其他地方擁有更多的自由度，但不要粗心大意。任何編輯者都可以立即刪除極具冒犯性的材料。，這些是具有冒犯性的，此外管理員的論點並不代表整個維基百科，宣傳政治理念，誹謗民意代表，為不可接受的行為，例如誹謗馬文君為叛國賊明顯違反與維基百科無關的爭論性言論，或攻擊或誹謗編輯群體、個人或其他實體的言論。這些言論均被視為分裂性的並會被刪除，而重新加入將被視為擾亂。，這些都是合理證據，因此刪除該些留言為正當。-- A0_{(討論·簽名)} 2024年12月21日 (六) 12:44 (UTC)

個人認為甚至可能違反UCoC第3.1 侮辱：這類行為包括惡言、侮蔑、使用刻板印象、基於個人特質的攻擊行為。侮辱可指感知特質，其諸如智力、外貌、民族、種族、宗教（或無宗教信仰）、文化、種姓、性取向、認同性別、生理性別、殘障、年齡、國籍、政治派別或其他特質。在部分情況中，反覆地嘲笑嘲弄、諷刺挖苦、或侵犯攻擊會構成集體侮辱。和引戰：以故意擾亂話題或惡意地發佈言論方式，有意圖地挑釁他人。-- A0_{(討論·簽名)} 2024年12月21日 (六) 12:55 (UTC)

什麼叫打著維基之名，不適當就是不適當，你認為你可以去公共政策網路參與平台提案說那些嗎，當然不行，因為地方錯了-- A0_{(討論·簽名)} 2024年12月21日 (六) 15:10 (UTC)

我認為我有處理我的討論頁的自由，我不想要別人插手我討論頁面的事情。實在有不合規的內容我會摺疊，但我不認同別人替我刪除還不讓我處置。 --MilkyDefer 2024年12月20日 (五) 13:45 (UTC)

你這話就相當於在說你認為你對你的用戶頁和用戶討論頁有所有權。--自由雨日🌧️❄️ 2024年12月20日 (五) 22:56 (UTC)

我記得使用者對於用戶討論頁面僅有「使用權」，但閣下的說法，恐怕會變成用戶對於自己的討論頁面及相關用戶頁面有「擁有權」，這錯誤的理解吧？。--薏仁將🍀 2024年12月20日 (五) 23:08 (UTC)

這個事件是一個編者在第三人的討論頁面發布宣傳性內容（但是我認為那些內容可以搬到維基新聞做opinion piece），然後第四人意圖移除內容後被還原，莫名其妙就要召喚管理員介入。此事之奇葩程度聞所未聞，因為那個編者沒有濫用自己的討論頁。你們可以規定任何人不得反對他人在自己的討論頁面嚴格執法，但是我認為與其把原則法律化並且不斷打補丁，不如讓所有編者把自己的賬號交出來交給三百多萬個硬編碼規則的機器人。--MilkyDefer 2024年12月21日 (六) 10:34 (UTC)

所以你的意思是，在條目討論頁、在用戶頁、在用戶空間子頁面均不得放置的宣傳性內容，可以轉而在用戶討論頁放置？--自由雨日🌧️❄️ 2024年12月21日 (六) 10:38 (UTC)

讚--Dryrace（留言） 2024年12月28日 (六) 10:53 (UTC)

程序問題：Wikipedia:管理操作覆核請求有提到「在發起覆核請求前，建議嘗試與執行操作人（當事人）討論，以解決問題」，請問提請覆核之人等是否已和當事管理員進行過充分討論溝通？雖說這只是「建議」，但是如果以後每個人都在未經充分溝通的情況下就逕行提請社群覆核管理員操作，恐致社群無謂困擾、消耗社群精力。-Peacearth（留言） 2024年12月20日 (五) 16:19 (UTC)

本人已根據您的建議在有關管理員的討論頁留言。由於本人已於該留言詳述意見，請恕不在此重複。--派翠可夫 (留言按此) 2024年12月21日 (六) 03:50 (UTC)

若要較真需注意上述WP:NOT中所列只有用戶頁，並無用戶討論頁。WP:TPG#別人的意見中也着重強調（而這也是使用 deltalk 中自動生成的標籤所鏈接到的頁面）{{deltalk}}是用來移除非常明顯的人身攻擊和不文明的留言，而涉及到的留言段落明顯不屬於這一類。另外想提醒一些編者，並不是所有您看到的不喜歡的內容都要跑到WP:ANM中提一個新提報，特別是本討論中涉及到的留言並非發送給提報者。您這種行為相當於在兩人間對話時擅自插嘴並大叫「我不喜歡這個對話！你們必須停止！」，這樣十分不禮貌。若當事人認為此對話不妥自然會自行處理，但既然當事人認為這對話並不冒犯那我認這留言也並無大礙。我知道這留言相對於某些用戶來說確實感到冒犯，但正如我之前所說，這些話並不是對您說的，您可以選擇無視。參與維基百科所需要適應的一點是需要接受有用戶的想法及觀點與您不同，且，並不是所有您不喜歡的內容都必須刪除。--廣雅 范★ 2024年12月20日 (五) 19:06 (UTC)

NOT中列出了討論頁，顯然用戶討論頁屬於討論頁。此外，《WP:用戶頁》指引中還列出了更廣泛的適用於用戶空間的條款。最後一句加粗的留言則屬於混淆視聽，從一開始所有人提出行為不當的理據就是宣傳，而不是所謂「不喜歡的內容必須刪除」。--自由雨日🌧️❄️ 2024年12月20日 (五) 23:00 (UTC)

宣傳指的是對多數不特定的人推廣自己的觀點或者產品，如在條目空間打廣告，又如在用戶頁大肆宣揚自己的政治立場。在討論頁這種兩人對話的情況下是怎麼成為宣傳的呢？再者，也說過了，應由接收方判斷這能不能接受，而不是完全不是接收方的第三者。--廣雅 范★ 2024年12月21日 (六) 06:25 (UTC)

照這個邏輯，我放置在自己的用戶頁或討論頁將屬於宣傳的內容，我只要放在對方的討論頁，就可以避免被當作「宣傳」？那以後大家做宣傳只要將這些內容互相往對方討論頁放就行了，只要事先互相打好招呼，同意對方放置。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:19 (UTC)

這是屬於WP:GAME以及WP:POINT的行為。--廣雅 范★ 2024年12月21日 (六) 07:32 (UTC)

是的，所以為什麼目前他們二位未落入這個範疇呢？--自由雨日🌧️❄️ 2024年12月21日 (六) 07:36 (UTC)

范給的前設條件是「對多數不特定的人」，而且要滿足WP:GAME的話一般還需要證明相關用戶是帶有目的性地持續這樣做。Sanmosa _蚌埠 2024年12月21日 (六) 07:40 (UTC)

「對多數不特定的人」什麼意思？至於「帶有目的性地持續這樣做」的話，從其多次被提報來看，我認為已經可以這樣認為了。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:42 (UTC)

「對多數不特定的人」我會理解為「無差別」，比如「對多數不特定的人攻擊」相當於「無差別攻擊」。Sanmosa _蚌埠 2024年12月21日 (六) 07:47 (UTC)

我沒看到他給這個前設條件？（我這句指的也主要是「兩人互相放置宣傳材料」，當然多人互相放置也適用）--自由雨日🌧️❄️ 2024年12月21日 (六) 07:52 (UTC)

#c-范-20241221062500-自由雨日-20241220230000。Sanmosa _蚌埠 2024年12月21日 (六) 08:14 (UTC)

哦。我的意思是，「放置內容」本身就已經構成了無差別傳播，因為它們是公開可見的（郵件則不是），尤其是用戶討論頁，曝光率是很高的。--自由雨日🌧️❄️ 2024年12月21日 (六) 08:16 (UTC)

對多數不特定的人：比如客棧、條目、用戶頁，放在那裡的用意就是被大家看到；帶有目的性地持續這樣做：被提報者是反對第三方直接修改討論頁內容，並沒有持續性進行宣傳的意圖。--廣雅 范★ 2024年12月21日 (六) 07:52 (UTC)

然而用戶討論頁是僅次於用戶主頁的很多人會查看的頁面。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:53 (UTC)

另外，放置於用戶子頁面、訪問量幾乎沒有的內容也是可以因宣傳而刪除的。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:57 (UTC)

那麼本案例中被刪除的留言是違反了WP:TPG#別人的意見內的哪一條呢？--廣雅 范★ 2024年12月21日 (六) 08:11 (UTC)

違反了WP:SOAP ——自由雨日🌧️❄️ 2024年12月21日 (六) 08:13 (UTC)

這是編輯他人的留言，操作需符合WP:TPG#別人的意見中的一點。--廣雅 范★ 2024年12月21日 (六) 09:36 (UTC)

違反了SOAP啊。「移除不允許的資料，例如……等」。--自由雨日🌧️❄️ 2024年12月21日 (六) 12:00 (UTC)

違反了WP:NOTADVOCACY，作任何遊說、宣傳或招攬，包括商業、政治、科學、宗教、國家、體育或其他性質。條目當然可以客觀地描述某人或事物，但必須符合中立觀點。如有觀點或意見希望得到其他人支持，請移駕至個人網誌或論壇。，即為宣傳政治，且本條適用所有命名空間。-- A0_{(討論·簽名)} 2024年12月21日 (六) 12:51 (UTC)

還有WP:NOTOPINION-- A0_{(討論·簽名)} 2024年12月21日 (六) 12:52 (UTC)

還有WP:NPA，攻擊某些特定政治人物-- A0_{(討論·簽名)} 2024年12月21日 (六) 13:06 (UTC)

(！)意見:一些有趣的問題請教參與議題的諸位

1. 用戶討論區算不算討論區的一種型態展現？
2. 承上，若用戶討論區屬於討論區的一種呈現樣態，那麼試問用戶討論區是否也受到WP:SOAP規範限制範疇內？若用戶討論區非討論區定義條件，那麼也請說明其認定意見。
3. 用戶A傳送高敏感議題(如：政治觀點，如XXXX年的選舉活動理想政治人選)傳遞投放給與其他用戶至其討論區，請問是否構成宣傳行為？
4. 承上假設這是構成WP:SOAP行為條件定義，而傳遞者也依照前述遭管理員封鎖，那麼請問：消極、被動不表任示何立場的訊息接收用戶B消極不移除那些敏感話題而任憑展示，試問是否同樣構成WP:SOAP相關要件？傳遞者被管理員封鎖，難道相對訊息接收者就無需收到任何管理員口頭提醒警告，告知該等敏感內容有WP:SOAP之虞，要求對方移除？

請參與該議題的諸位好好思考一下提問內容，思考這件議案處理是否妥適，謝謝。--薏仁將🍀 2024年12月21日 (六) 00:23 (UTC)

用戶命名空間相對起維基百科命名空間及條目命名空間來說更具有私人性質，正如一般不允許隨意修改他人用戶頁一樣，用戶討論頁的內容也應該由頁主自行定奪。您的第三點確實構成了宣傳，但如果 A 因為宣傳被封這是因為他做出了「宣傳」這種不當行為，而不是單憑他發的內容。B 作為宣傳材料的接收者，若覺得無需理會則不移除並沒有什麼問題。不像維基百科命名空間會有多人同時參與討論與條目命名空間會被索引，用戶討論頁一般是對該用戶的留言區，依我看來不是「任憑展示」。--廣雅 范★ 2024年12月21日 (六) 06:34 (UTC)

感謝閣下特地撥冗協助釐清與回覆，所以閣下認為:用戶討論區亦屬於討論區的樣態形式，但是由於定位上屬於個別用戶「私人」性質，所以界定上，即便他人傳遞高敏感內容議題，則裁量權(刪除、存檔、保留)這些權益則屬於個別用戶的權利範圍之內，而若沒明顯違反不文明、人身攻擊，對方用戶不排斥亦不反對情形下，第三方用戶則毋須介入處理，請問如此解釋是否正確？--薏仁將🍀 2024年12月21日 (六) 06:54 (UTC)

是的，我是這樣認為的。--廣雅 范★ 2024年12月21日 (六) 07:02 (UTC)

那這樣子的話，基本上，照原處理管理員處理方式(還原對方用戶遭他方用戶介入移除的內容)是沒有太多問題的，感謝閣下協助釐清。--薏仁將🍀 2024年12月21日 (六) 07:11 (UTC)

WP:NOTSOCIAL，WP:NOTHERE，顯著違反方針的內容，移除行為無需經由任何人同意。->>Vocal&Guitar->>_留言 2024年12月21日 (六) 07:18 (UTC)

這裏我覺得值得關注的一點是「與維基百科相關的資料」應該如何解讀，因為不同的解讀方式會影響Ch.Andrew的操作具備正當性與否。Sanmosa _蚌埠 2024年12月21日 (六) 07:31 (UTC)

@WiiUf。Sanmosa _蚌埠 2024年12月21日 (六) 07:32 (UTC)

順便也ping一下@薏仁將。Sanmosa _蚌埠 2024年12月21日 (六) 07:41 (UTC)

這個要看切入的點是什麼，所以我才會設置那些問題問參與討論的諸位，貌似范君與原處置的管理員看法立場是近似的，但是我仍傾向認為即便是私人的性質，則也不應當消極任憑放置具有敏感爭議的宣傳材料，這邊可能需要諸位需進一步釐清討論，我個人覺得可能會有用戶會利用這種認知判斷差異落差而作仿效，屆時倘若要規範，恐怕也許會被對方說嘴。--薏仁將🍀 2024年12月21日 (六) 07:54 (UTC)

我的問題是「與維基百科相關的資料」到底是說「與維基百科此一項目本身相關的資料」還是說「與維基百科的內容相關的資料」？Sanmosa _蚌埠 2024年12月21日 (六) 08:12 (UTC)

應該是被定義成:「與協作改善維基百科條目或者商討相關姐妹計畫、本身或內容相關聯性議題」不論是個人前述定義或者您提出的二個要件，傳送個人政治觀點給與他人這已經很明確是「宣傳行為」，不用懷疑；但是那些政治觀點內容放置，似乎不像是「與維基百科存在相關性的資料」，就直接開門見山的問:一則202X年XXX直轄縣市長選舉理想人選被放置於用戶討論區，你能說明它關條目協作改善或維基百科相關性質議題資料有甚麼相關性？沒有啊，不就是個人主觀評價的內容？好像根本與條目改善協作或者相關議題商討無關聯性吧？--薏仁將🍀 2024年12月21日 (六) 08:35 (UTC)

我提這點主要是給大家一個思考的方向，我大致理解你的意見了。亲，我簽名那刻的時間是 2024年12月22日 (日) 08:49 (UTC)

其實有關頁面內容的方針是可適用於使用者頁面空間的，標題以User（使用者）和User talk（使用者討論）開頭的頁面都被視為使用者頁面。另外當用戶發現其用戶討論頁面有使用不當情形，則應優先發布{{subst:uw-userpage}}提醒通知。--薏仁將🍀 2024年12月26日 (四) 11:02 (UTC)

@薏仁將：我留意到用戶頁指引在今年11月有過一次修訂，我在VPP那邊就著那個修訂提了一些問題，其中就牽涉到「用戶頁（面）」一詞的理解，這恐怕也會影響這裏的結果。Sanmosa _蘭絮 2024年12月28日 (六) 15:30 (UTC)

但至少「用戶討論頁」無疑是屬於「討論頁」的，故用戶討論頁肯定是適用WP:SOAP的。--自由雨日🌧️❄️ 2024年12月28日 (六) 15:34 (UTC)

說「無疑」太絕對了，至少敝人個人是持疑的。敝人認為，「討論頁」和「用戶討論頁」是不同的頁面，WP:SOAP僅適用於前者。--Matt Smith（留言） 2024年12月29日 (日) 02:23 (UTC)

那你得拿出證據，而不是空穴來風。--自由雨日🌧️❄️ 2024年12月29日 (日) 03:53 (UTC)

法律無明文規定者，不為罪。WP:SOAP說適用對象是「用戶名、條目、分類、檔案、討論頁、模板及用戶頁」，這些對象中關於用戶的只有「用戶頁」，沒有「用戶討論頁」。--Matt Smith（留言） 2024年12月29日 (日) 04:38 (UTC)

WP:UP，標題以User（使用者）和User talk（使用者討論）命名空間開頭的頁面都被視為使用者頁面。-- A0_{(討論·簽名)} 2024年12月29日 (日) 04:41 (UTC)

我前面早已回復「用戶討論頁」屬於「討論頁」。--自由雨日🌧️❄️ 2024年12月29日 (日) 04:44 (UTC)

標題以User（使用者）和User talk（使用者討論）開頭的頁面都被視為使用者頁面，皆須受內容方針規範，只是為了用戶使用用戶討論頁便利性及彈性，規定較寬鬆，但寬鬆不代表完全不受限制，這點要先釐清，而前面內容皆在使用者頁面有相同說明。--薏仁將🍀 2024年12月29日 (日) 04:56 (UTC)

了解，謝謝。--Matt Smith（留言） 2024年12月29日 (日) 05:04 (UTC)

您好，使用者頁面上的衍生定義應當是不妨害影響這邊的討論結果，因為它可以幫助釐清究竟使用者頁面的範圍包括在哪？限制又在哪？還是說其實定義所指向的標的為全然不同的東西？--薏仁將🍀 2024年12月28日 (六) 21:19 (UTC)

於我而言，新版條文的規定無法使我有效判斷兩者是否為全然不同的東西，因此這個問題我無法解答，而這也是我要在VPP尋求解決方案的原因。Sanmosa _蘭絮 2024年12月29日 (日) 03:49 (UTC)

我想問大家，那今天夏土賢如果是在討論頁發表的話，照以上的邏輯，是不是就可以了-- A0_{(討論·簽名)} 2024年12月21日 (六) 10:08 (UTC)

這樣説吧，發表是一回事，移除是另一回事。用戶不能任意發表不當言論或許並不意味用戶可以任意移除不當言論。亲，我簽名那刻的時間是 2024年12月21日 (六) 13:36 (UTC)

這好像轉移焦點了吧？假如目前被提報（及覆核）的是移除留言的人，這條評論（評價移除操作是否恰當）才對題。但這裡討論的是將宣傳性內容加回的用戶的「加回」操作。——自由雨日🌧️❄️ 2024年12月21日 (六) 21:48 (UTC)

然而這裏也涉及到一個邏輯問題，就是如果移除操作本身並不恰當，那移除操作是應該要被無效化的，那Ch.Andrew的操作就不能被認為不具備正當性。亲，我簽名那刻的時間是 2024年12月21日 (六) 23:29 (UTC)

哦，那就是我前面論證的我認為這一內容本身確實不應存在了（畢竟放置於幾乎無人訪問的用戶子頁面、且我認為宣傳意味並不如本案高的內容，社群共識也是刪除）——即我認為移除是正當合理的。--自由雨日🌧️❄️ 2024年12月21日 (六) 23:32 (UTC)

然而我這裏也主張言論本身是否不當與移除是否正當合理不存在直接的關係。亲，我簽名那刻的時間是 2024年12月22日 (日) 00:09 (UTC)

你的意思是二個問題(行為)要分開看分開討論，對嗎？--薏仁將🍀 2024年12月22日 (日) 00:16 (UTC)

是的，你可以這樣理解。亲，我簽名那刻的時間是 2024年12月22日 (日) 08:48 (UTC)

是說之前好像有個民眾黨黨工因為宣傳被封進了是吧，剛才翻了一下討論頁，守望者愛孟在2017年說了Wild閣下這裡是維基百科的民進黨總部，Jackac就是深愛台灣的請願民眾。。。哈哈哈，大概好久前就是這樣了-- A0_{(討論·簽名)} 2024年12月22日 (日) 01:16 (UTC)

(！)意見： 從討論中看到，對是否可以刪除其他人個人討論頁上的這類留言，以及恢復自己個人討論頁被他人刪除的這類留言爭議不小。當對立雙方的判斷不一致時，往往會導致編輯刪除和恢復的反覆。

1. 鑑於雙方的判斷具有主觀性，是否可以看作是編輯爭議， 是否可以通過提報到編輯爭議頁面，由社群討論並形成共識後再處理？
2. 若有人違反共識進行操作，則可再提報至「維基百科:管理員布告板/其他不當行為」，並在此階段請求管理員介入處理, 注重討論建設性與公平性。

--Gluo88（留言） 2024年12月21日 (六) 19:12 (UTC)

Cindyzs等用戶在該討論頁所作所為顯然與建設維基百科毫無關聯。若Wildcursive想恢復其留言，唯一合理的理由就是這些留言與維基百科及社群相關，而不是其對討論頁的所有權，因為用戶並沒有對這種絕對的裁量權。至於拿着自由民主及思想自由說事的部分用戶，仿佛是搞不清Wikimedia不是政府、第一修正案並不適用於此一樣。看上去仿佛自己是民主鬥士，實際上和拿法律條文要求維基百科自我審查的用戶沒什麼區別，完全是無效論據。不重視社群共識，恰恰是與維基媒體運動的行事方式背道而馳的。——暁月凜奈 (留言) 2024年12月22日 (日) 00:37 (UTC)

那今天他說剷除親中國勢力者，是否會造成大陸編者或政治立場偏向大陸之編者之不快或感受到人身威脅，這明顯非文明，又或是否違反UCoC第2.1我們期望所有維基媒體人都能對他人表示尊重。不論在維基媒體的線上還是線下環境，在與他人交流過程中，我們要以互相尊重的態度對待對方。，分明是不行的，明顯具有重大違規事宜，那怎麼能夠保留，又說他人是無恥政客，亦不尊重對面政治立場的人，所以維基百科根本是不容許這些的。-- A0_{(討論·簽名)} 2024年12月22日 (日) 09:15 (UTC)

什麼叫做「那今天他說剷除親中國勢力者」，請你不要把我沒說過寫過的話塞給我！如果你指的是Cindyzs說的，他留言以來，我對話頁也沒出現那樣的文字。這已是你至少第二次胡亂把我沒寫的文字栽贓給我，易生誤會。至於Cindyzs在我討論頁明白引用黃國昌的前一個黨時代力量及其黨主席王婉諭批他是「無恥政客」，這是有來源轉述，我不認為他這樣寫有何大問題。至於為何他要特別提黃國昌，我猜是因為那其實是我於2013年創建的頁面[20]，無論他是奚落暗諷我、感嘆我為何當年如此，我都沒意見，這也算針對編輯史交換意見。我看不出有什麼好屢屢刪除的。--WildCursive（留言） 2024年12月24日 (二) 04:01 (UTC)

我指的本來就不是你啊，這裡是說soap的爭論-- A0_{(討論·簽名)} 2024年12月24日 (二) 04:45 (UTC)

戒嚴那邊-- A0_{(討論·簽名)} 2024年12月24日 (二) 04:46 (UTC)

WP:OWNTALK，有提到對於使用者討論頁而言，這些方針的遵循度會比其他討論頁較為寬鬆，雖然留言內容看起來處處和方針指引相悖，也引起了反應，但這實質都不屬於違規的部分，因為使用者對於自己的討論頁擁有自主權，而且發布的位置不是被嚴格規範的。試問，今天若是情況相反，Wildcursive使用者無法移除他不想留的內容，而到布告板尋求幫助，但是大家都跟他說這沒有違規所以不能刪除，適當的處理狀況不應該是，讓使用者自己決定什麼留言可以留什麼不留，只要他不剪貼拼接扭曲意思，要幫助的時候管理員適當地提供協助，這樣才是合乎討論頁自主權的。

這邊另外想建議@Wildcursive，我留意到同樣內容的留言您放了幾個地方，在個人討論頁是為寬鬆的留言，但若上了客棧或布告板就有為難的狀況，我先前沒表達很好，不過我想請您考慮自行減去會違反討論頁方針的內容，這樣或許會對討論的結果較為友善。--提斯切里（留言） 2024年12月22日 (日) 10:04 (UTC)

較為寬鬆並不代表不適用-- A0_{(討論·簽名)} 2024年12月22日 (日) 10:06 (UTC)

@Tisscherry： 我就是在個人討論頁回應，主文也放被提報頁及此客棧，我不可能期待大家都翻來翻去的看，總該讓我在被公審處完整陳述吧。有人說刪了還是有紀錄，有心人都看得見，我也沒啥好隱藏的。人有偏好與慣性，我刪了這，說不定你想的是那，若直接告訴我還可商榷或討論。父子騎驢討好不了誰，我還是集中擺在一起，也會再抽空增修。我是被動回應、被迫說明，難得一次自辯，如同答辯書給各審不算超過，這是程序正義，稱不上宣傳。--WildCursive（留言） 2024年12月24日 (二) 05:29 (UTC)

@Wildcursive君，我主要指的是最新的金牌的那段，放在客棧和布告板就不太妥當，且平心而論，這含有的身分識別較為強烈，可能不是那麼公允，這讓我想到之前曾經介入個體育項目的溝通，該名使用者認為不懂籃球的都是女性，後來一直用「妳」指稱本人，一直要我去問男朋友或老公（？？？）。我想您應該能夠明白，就點到為止了。刪了的記錄可以請求版本刪除做隱藏，如果不會請求，直接找線上管理員也是可以的。--提斯切里（留言） 2024年12月24日 (二) 11:22 (UTC)

@Tisscherry： 既然妳/你點明，請管理員刪除似乎耗些工程也未必即時、全面，本想用刪除線，想想還是略修。--WildCursive（留言） 2024年12月25日 (三) 00:26 (UTC)

這人也跟夏土賢一樣整天嘴上掛著文革-- A0_{(討論·簽名)} 2024年12月24日 (二) 12:21 (UTC)

@Wildcursive君，您可以直接找Manchiu管理員，他處理很有經驗的。謝謝您願意考量，就看您的決定了。--提斯切里（留言） 2024年12月25日 (三) 01:12 (UTC)

(＋)支持覆核，本人不認為管理員此舉得當，理應予以討論頁編輯禁制。--Talimu0518（留言） 2024年12月23日 (一) 14:07 (UTC)

我是覺得，如果有誰移除了不合適的內容，討論頁主人不應該恢復，否則應該要算到他頭上。我自己對於我自己的討論頁也是很開放，胡話我不小心回退了都會撤回。但是來反破壞的移除留言我是不會加回來的。不過沒收別人的星章還是不妥，我覺得W應該恢復這條。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月24日 (二) 11:59 (UTC)

(－)反對覆核，方針或指引未明文限制用戶處置其對話頁的內容。--Matt Smith（留言） 2024年12月25日 (三) 02:57 (UTC)

(！)意見:在使用者頁面開宗名義的就已經說明:「使用者頁面用於維基人之間的交流與協同運作。雖然您可以自由地個性化和管理您的使用者空間，但它們是社群專案頁面，而不是個人網站、部落格、社群網路媒體或維基百科條目。它們應該用於更好地參與社群，而不是過度用於無關目的或損害專案的聲譽。」而同一個規範章節對於使用者頁面定義是:「使用者頁面主要用於人際討論、通知、測試和草稿（參見沙盒），以及（如果需要）有限的自傳和個人內容。標題以User（使用者）和User talk（使用者討論）命名空間開頭的頁面都被視為使用者頁面。」，是故，如果以定義去結合相關前述條件限制，消極的置放政治觀點議題是不允許的，只是解釋的人沒有前後上下文的關聯性給找出來罷了，所以縱使訊息接收用戶認為政治觀點屬於一種言論表達的自由，但綜合前述對於使用者頁面定義與限制條件，仍不可以放置於用戶討論頁面，因為視為宣傳行為。這樣子解釋有清楚嗎？--薏仁將🍀 2024年12月26日 (四) 09:05 (UTC)

(～)補充:被提報者目前已被管理員做出相關限制措施，請參照WP:ANO#Wildcursive及Special:Diff/85443983描述案件處理，詢問@WiiUf君是否考慮撤銷提案？--薏仁將🍀 2024年12月26日 (四) 09:17 (UTC)

管理操作覆核重點是覆核「管理操作」本身（WP:管理操作覆核請求），被提報者後續是否有被限制，並不影響這裡的覆核吧？--自由雨日🌧️❄️ 2024年12月26日 (四) 09:22 (UTC)

瞭解。--薏仁將🍀 2024年12月26日 (四) 09:46 (UTC)

(！)意見：看了以上一大串，很驚訝這會有這麼大的討論。相關慣例已行之有年，並形成指引。用戶討論頁是用來讓編輯之間討論的，尊重用戶編輯本身的意願是慣例，應以用戶以及跟他正在交流中的編輯為主。第三方直接進入，介入對話，強制進行刪除，不符合指引，也不禮貌。指引方針為「一般情況下，應避免大量編輯其他人的用戶頁和用戶討論頁，除非編輯可能會有幫助。如果不確定，請詢問。 」如果第三方編輯對留言有意見，不應該直接進入刪除別人的留言，因為這會影響到原本兩位編輯之間的交流，扭曲留言的意思。「如果對某個用戶的頁面有顧慮，最好的辦法是通過討論頁引起對方的注意。如果對方同意，就讓對方自己編輯。」如果認為這段對話真的有必要移除，用戶不願意主動進行，應該在社群頁面發起議題討論，經過社群達成共識之後，再根據共識，禮貌的請用戶移除相關段落。以尊重慣例來進行處理，為最好方向。--Alfredo ougaowen（留言） 2024年12月26日 (四) 15:08 (UTC)

剛剛看到他已經被部分封鎖了，這個覆核請求可以關閉了吧。Пусть от победы☆к победе ведёт! 2024年12月26日 (四) 16:22 (UTC)

上面我有提過看看原提出用戶是否願意撤回提案，但自由雨日君認為，這並不影響覆核程序進行。--薏仁將🍀 2024年12月26日 (四) 22:57 (UTC)

其實有關頁面內容的方針是可適用於使用者頁面空間的，標題以User（使用者）和User talk（使用者討論）開頭的頁面都被視為使用者頁面。另外當用戶發現其用戶討論頁面有使用不當情形，則應優先發布{{subst:uw-userpage}}提醒通知。另並非用戶討論頁面不受其拘束，而是標題以User（使用者）和User talk（使用者討論）開頭的頁面都被視為使用者頁面，皆須受內容方針規範，只是為了用戶使用用戶討論頁便利性及彈性，規定較寬鬆，但寬鬆不代表完全不受限制，這點要先釐清。--薏仁將🍀 2024年12月26日 (四) 22:52 (UTC)

我仍然希望能夠繼續此次覆核請求（至少應移除該用戶討論頁中的廣告內容）。—WiiUf🐉 2024年12月27日 (五) 10:21 (UTC)

同上，我認為應該移除該用戶討論頁的違反方針內容，因此(＋)支持覆核。還有上面某位前管理員的言論，感覺根本沒有理解方針，或者說是為反駁而反駁。--Dryrace（留言） 2024年12月28日 (六) 10:51 (UTC)

(＋)支持覆核。我認為僅移除與維基百科無關的政治宣傳即可，用戶討論頁存在過多的與維基百科無關的內容會容易被認為濫用。--Lanwi1^Talk 2024年12月29日 (日) 09:05 (UTC)

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

Please allow editing of User:Masterlau467/沙盒.

已處理：

已代為替換圖片。Sanmosa _蘭絮 2024年12月29日 (日) 13:02 (UTC)

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

---

Please allow editing of User:Masterlau467/沙盒. I need to replace File:"Possible Productions knotwork" by Steve Ball.png with File:-Possible Productions knotwork- by Steve Ball.svg.--OperationSakura6144（留言） 2024年12月29日 (日) 02:10 (UTC)

@OperationSakura6144：I have just replaced it, so maybe the acceptance of this request is now not necessary, right? Sanmosa _蘭絮 2024年12月29日 (日) 09:24 (UTC)

Thank you, User:Sanmosa, and, yeah, I kinda agree with your statement. I think I should've used a right phrasing since you replied me. Anyway, best wishes for 2025. Bye.--OperationSakura6144（留言） 2024年12月29日 (日) 11:42 (UTC)

---

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

新年標誌

新年在1月29日，是時候徵集新年標誌了。 ——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月29日 (日) 15:15 (UTC)

還好是農曆，要不然只剩3天就2025了——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月29日 (日) 17:54 (UTC)

我給一個可能的方向：「乙巳」二字均狀似蛇，或許可以考慮將這兩個字弄成蛇的形狀。Sanmosa _蘭絮 2024年12月29日 (日) 23:54 (UTC) 自由雨日說讚。

可以參考這種新年郵票、[21]，中國郵政的「福納百祥」恰好類似二字的圖形化。--Kethyga（留言） 2024年12月31日 (二) 06:42 (UTC)

那我參考看看，或許我能畫個草稿。Sanmosa _蘭絮 2025年1月1日 (三) 01:54 (UTC)

草稿

剛弄好草稿了搞錯了一些東西，稍後再修復。Sanmosa _蘭絮 2025年1月1日 (三) 02:31 (UTC)

正好是25，贊。不過右邊的因為不對稱看着有點胖（）——敬頌冬綏 ZhaoFJx_(論•簽) 2025年1月1日 (三) 02:34 (UTC)

@ZhaoFJx：那個是我畫錯了，現在的才是正確版本。Sanmosa _蘭絮 2025年1月1日 (三) 02:44 (UTC)

蛇環繞維基球如何？ -Lemonaka 2024年12月31日 (二) 06:46 (UTC)

File:2013logohant.png

或者我們還有一個選擇就是把十二年前@Buernia老師做的拿出來複用。——魔琴［身份聲明 留言 貢獻 PJ:NEW23］ 2024年12月31日 (二) 13:09 (UTC)

不是不好看，但感覺……就真像是12年前的。Sanmosa _蘭絮 2025年1月1日 (三) 01:53 (UTC)

我提議如下，蛇環繞維基球 左側尾部形成2，頭部爲5 @Sanmosa 如何？ -Lemonaka 2025年1月1日 (三) 03:09 (UTC)

這比較複雜，我處理不來，而且我預感這樣的構圖就算成形也會很chaotic。Sanmosa _蘭絮 2025年1月2日 (四) 12:34 (UTC)

或許透過 ASN 或公告欄公開徵集設計？本站應該不缺乏會設計的人才，問題是沒有人知道。--SCP-0000（留言） 2025年1月1日 (三) 04:59 (UTC)

@SCP-2000：公告欄有放了，但放ASN不會太過擾民了嗎？--SunAfterRain 2025年1月1日 (三) 08:48 (UTC)

如果放幾日（例如一週）應該沒有大問題。--SCP-0000（留言） 2025年1月1日 (三) 17:55 (UTC)

@魔琴：剛剛想起一個問題，就是vector 2022的標誌是中文字位於維基球右側的，因此中文字位於維基球下側的自訂標誌無法於vector 2022顯現，我不清楚vector 2022的標誌裏的中文字與維基球是否兩個分別的圖像，還有vector 2022的標誌圖像是否可以通過類似vector 2010的自訂標誌的方式來替換。Sanmosa _蘭絮 2025年1月2日 (四) 12:38 (UTC)

是兩個獨立的文件；可以 Stang^★ 2025年1月2日 (四) 12:43 (UTC)

@Stang：感謝代為回應，那我現在趕工把乙巳雙蛇的純圖像檔案給弄上來。Sanmosa _蘭絮 2025年1月2日 (四) 12:48 (UTC)

@Stang：不好意思，要再ping一次，但我也想知道如何在vector 2022實現類似User:Sanmosa/Logo test.js的效果，畢竟我自己也需要預覽一下。Sanmosa _蘭絮 2025年1月2日 (四) 13:00 (UTC)

@Sanmosa：SunAfterRain提供的片段供參考：$('.skin-vector-2022 .mw-logo > .mw-logo-icon').attr('src', 'https://upload.wikimedia.org/wikipedia/commons/c/cc/%E4%B9%99%E5%B7%B3_snake.png').removeAttr('height').css('height', 'auto') Stang^★ 2025年1月2日 (四) 14:08 (UTC)

已更新代碼。Sanmosa _蘭絮 2025年1月2日 (四) 14:21 (UTC)

Sanmosa版

• 
  乙巳雙蛇（繁體）SVG
• 
  乙巳雙蛇（簡體）SVG
• 
  乙巳雙蛇（僅圖像）SVG
• 
  乙巳雙蛇（繁體）PNG
• 
  乙巳雙蛇（簡體）PNG
• 
  乙巳雙蛇（僅圖像）PNG

剛才基於草稿稍稍上了色，大家可以給些評價。Sanmosa _蘭絮 2025年1月2日 (四) 12:18 (UTC)

如果想試試提前在中文維基百科全站換上SVG樣式的logo的話，在自己的JS頁加這個碼就好：importScript('User:Sanmosa/Logo test.js');。Sanmosa _蘭絮 2025年1月2日 (四) 12:20 (UTC)

好看！很簡約的徽標，不過會不會太簡約了（（——敬頌冬綏 ZhaoFJx_(論•簽) 2025年1月2日 (四) 12:50 (UTC)

與我兩年前説的一樣，我個人偏好極簡風。只要看起來是舒服的，那簡不簡約其實並不重要。另一方面，簡約的標誌一般也有利於識別，因此設計簡約也是有一定的好處的。Sanmosa _蘭絮 2025年1月2日 (四) 12:58 (UTC)

能結合「25」就更好了。--東風（留言） 2025年1月2日 (四) 13:22 (UTC)

然而「巳」與「5」的字形好像是衝突的？Sanmosa _蘭絮 2025年1月2日 (四) 14:53 (UTC)

個人感覺，這個logo完全沒有維基百科的元素。或者說，如果沒有底部的文字，我完全看不出這是維基百科的logo 囧rz……而歷年的logo都有維基百科的特色。個人建議新年標志結合原版的維基球製作，在這一點上我比較傾向於@Lemonaka的「蛇環繞維基球」提議。

題外話，第一眼看上去，感覺蛇的形狀更像是「2C」（--Nebulatria（留言） 2025年1月2日 (四) 13:38 (UTC)

然而2021年的農曆新年特別標誌除了「W」形牛角與「維」字外也沒有多少「維基百科的特色」，而且兩者的「維基百科的特色」並不明顯。（看上去更類似的字元可能是「ƧꞆ」？）Sanmosa _蘭絮 2025年1月2日 (四) 14:29 (UTC)

(！)意見：左邊那條蛇像「己」字多於「乙」字。（附：1989年是己巳年） -- 派翠可夫 (留言按此) 2025年1月2日 (四) 15:09 (UTC)

諸位

諸位，2025年5月19號就是中國全面封鎖中文維基百科的十周年，屆時我們應該更換logo來紀念。這是一個一次性賬號，後面再也不發言了，不要檢舉我到SPI喔。

Wikipedia logo china ban 2025 zh hans

--A20152025A（留言） 2025年1月2日 (四) 14:18 (UTC)