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

本页互助客栈 (全部)是供以方便浏览所有讨论而特别设置。如果您想要新增讨论内容，请在互助客栈中选择最合适的版面。

按此刷新页面。

		欢迎光临互助客栈！
	互助客栈是维基人议事相助之处，用以讨论消息、方针、技术以及编辑、求助等议题。 发表议题之前请搜索先前文章，遵守指导及礼仪。任何与维基百科无关的问题，请前往知识问答。
消息	方针	技术	求助	条目探讨	其他
讨论维基相关新闻与消息	讨论方针与草案	解决或报告技术疑难	解决在维基百科中所遇疑难	条目、模板、主题相关探讨	未符任何分区之议题
发表 | 监视	发表 | 监视	发表 | 监视	发表 | 监视	发表 | 监视	发表 | 监视
查看全部讨论
帮助目录 · 提出疑问 · 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)

提议维基百科:抄袭并入维基百科:不要包含原始资料的副本

想法： 维基百科:抄袭 ：

现行条文 抄袭指的是将他人所贡献的作品，在没有提供足够的作者权益资讯之下，将其语言以及思想变成是自己的作品（在学术写作中，如果未能在论文中充分标注来源，而借用他人的任何想法或语言，便会被视为抄袭。无论来源是已出版的作者、其他学生、无明确作者的网站、贩售学术论文的网站或其他任何人：将他人的工作据为己有就是偷窃，这在所有学术情况下都不能接受，无论你是故意还是无意这样做。）该来源提供了各种抄袭类型的例子，包括逐字抄袭、拼凑抄袭、不充分的改写、未标注来源的改写和未标注来源的引用。剑桥大学将抄袭定义为：“将他人作品的部分或全部内容当作自己的作品提交，而没有适当标明来源，无论是否有意图欺骗。 维基百科有三项核心内容方针，其中两项很可能在不经意间产生抄袭问题。非原创研究防止我们将自己的想法放入条目当中，而可供查证要求条目必须基于可靠的已发表来源。这些方针意味著维基百科人非常容易被指责为抄袭者，因为我们非常执著于来源，但不能在内容上太过接近来源文本。由于抄袭的发生可能没有欺骗的意图，因此我们的关注方向应当放在教育编辑者清理条目内容。

提议条文 抄袭指的是将他人所贡献的作品，在没有提供足够的作者权益资讯之下，将其语言以及思想变成是自己的作品。各种抄袭类型的例子包括逐字抄袭、拼凑抄袭、不充分的改写、未标注来源的改写和未标注来源的引用。 我们建议编辑者应引用多方来源，条目的每一分段或单一事件应避免完全依靠同一个网站或书藉（每单元），当中包括官方网站及书藉。我们不建议编辑者原文引录来源的任何连续句（透过转述他人直接发表的关键言论除外）。对于产品或服务的使用条款或详细使用方法，应使用外部链接功能连结至记载相关资讯的官方网站或可靠来源。

以上！--唔好阻住我爱国（留言） 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)

重提为可供查证方针与可靠来源指引调整有关用户生成内容的规定

此前提议为可供查证方针与可靠来源指引调整有关用户生成内容的规定的讨论以无共识作结，然而当时我自己的提案在经过解释后并未遭到任何人的反对，因此我感觉我的提议应该是有机会能凝聚共识的，为此我希望把我的提案再一次交予社群检视，以促进中文维基百科及其社群的建设性发展。具体提案如下：

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)

现行用户页指引条文规定的定义问题

原标题为：请求澄清有关快速删除方针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)

技术

滥用过滤器警告信息

刚刚不小心触发了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)

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

Category:巴西游泳运动员和Category:巴西游泳運動員

如题，我发现明明有Category:巴西游泳運動員这个分类的情况下，Category:巴西游泳运动员还是显示的红链而非蓝链，但同样的繁简不同Category:阿富汗游泳运动员却能正常指向到Category:阿富汗游泳運動員。--💊✖️2️⃣3️⃣（留言） 2024年12月16日 (一) 09:57 (UTC)

猜测可能是因为全局转换中将“西游”识别成简体，系统认为这个短语是繁简混用，比如10年前的分类讨论页中Category talk:巴西游泳运动员的移动请求，不过一直无人处理，目前处理办法估计是移动到简体的分类。全局转换中的“西游->西遊”可能需要删除或者增加其他修复。同样的Category:巴西游泳场馆也无法用简体搜索。另外Category:巴西游泳在繁体情况下自动转换成了“分類:巴西遊泳”。--Kethyga（留言） 2024年12月16日 (一) 11:22 (UTC)

原来是“西游”造成的过度转换啊……那确实需要在全局转换当中修复一下了……搞得我一开始还以为分类的繁简内链转换坏了……个人倾向增加其他修复（就是追加“巴西游泳”⇔“巴西游泳”的规则）--💊✖️2️⃣3️⃣（留言） 2024年12月16日 (一) 12:12 (UTC)

可能有“巴西游击队”，不如转换“巴西游”即可。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年12月17日 (二) 10:52 (UTC)

我还想到有：根西游泳运动员、泽西游泳运动员……不过这两个都不常出现……--💊✖️2️⃣3️⃣（留言） 2024年12月20日 (五) 17:38 (UTC)

看Kethyga在Wikipedia:字词转换/修复请求开了此案，原来还有“山西游泳”、“陕西游泳”、“江西游泳”、闽西游击区这些啊。--💊✖️2️⃣3️⃣（留言） 2024年12月23日 (一) 04:57 (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年的测试可能过时了。就说明一下，不过我要去忙了，就麻烦你把沙盒依照你的想法修改吧。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年1月1日 (三) 09:09 (UTC)

• @A2569875：，看一下oldid=85513309，我这边初步测试，ifexist判断漢斯·鮑爾能判断到汉斯·鲍尔，用Lua掉外部解析器同效。ilh最初模板版判断页面存在就是用ifexist，ifexist是很久的方法，应该当时反馈过处理标题繁简问题。——Sakamotosan路过围观 | 避免做作，免敬 2025年1月1日 (三) 09:10 (UTC)

• ( π )题外话我看到您在Module:WikidataLink也提了与‘新版小工具’相关的编辑请求——Module_talk:WikidataLink#编辑请求_2024-12-31，是指新版小工具马上就要上线了吗/或已经上线了吗？还是还需要等待，只是先做前置作业（没找到有关新版小工具的上线讨论）-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年1月1日 (三) 04:37 (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)

求助

请求协助上传档案

我想要上传的图片来源是<黑川互动媒体艺术官网的LOGO图片,https://www.peppercorns.com.tw/wp-content/uploads/2018/11/logo-2.png>，想要使用在黑川互动媒体艺术的<资讯框>LOGO位置，感谢协助。--What2692（留言） 2024年12月10日 (二) 04:44 (UTC)

已上传--Edmond 92110002（留言） 2024年12月19日 (四) 06:45 (UTC)

感谢协助 !--What2692（留言） 2024年12月23日 (一) 08:07 (UTC)

我想要上传的图片来源是<https://www.facebook.com/photo.php?fbid=970241927800398&set=pb.100044437989452.-2207520000&type=3 ]的臣铭形象图片,>，想要使用在臣铭的<大头照>大头照位置，感谢协助。--此条未正确签名的留言由David857806（讨论｜贡献）于2024年12月10日 (二) 09:07 (UTC)加入。

请求协助上传文件

我想要上传的图片来源是<https://www.shinchosha.co.jp/book/772728/>的图书封面，我想用在三咲同学是非攻略对象的<信息框>位置，感谢协助--此条未正确签名的留言由FSRCE（讨论｜贡献）于2024年12月22日 (日) 10:22 (UTC)加入。

请求协助上传档案 2024-12-22 12:24

我想要上传的图片来源是<https://drive.google.com/file/d/1L2DEtbEq6wBrll-Yccan3McjTzgw1zby/view?usp=sharing>，想要使用在刘温馨的<图片>，谢谢。 --Kwokennykwok（留言） 2024年12月22日 (日) 12:24 (UTC)

请求协助上传档案 2024-12-22 15:27

我想要上传的图片来源是<https://ichijin-plus.com/comics/89324057887009>的书籍封面，想要使用在毁掉一切地狱再爱的<条目信息框>。感谢协助。 --MoonBaDog（留言） 2024年12月22日 (日) 15:27 (UTC)

编辑请求

你们好，LTA:Yage Wu“编辑倾向”一节提供的第三个连结有误，该连结里的资讯并非由Yage Wu上传，因此希望有人能帮忙按这里修改“编辑倾向”一节，谢谢。--78-Yellowcat（留言） 2024年12月23日 (一) 05:16 (UTC)

完成。请检查。 ——魔琴［身份声明 留言 贡献 PJ:NEW23］ 2024年12月23日 (一) 10:22 (UTC)

没问题，谢谢您。--78-Yellowcat（留言） 2024年12月23日 (一) 13:43 (UTC)

请求协助上传档案 2024-12-24 05:38

我想要上传的图片来源是<从某个网址下载，请提供网址https://w.wiki/CLyE / 自行拍摄>，想要使用在请提供条目名称https://w.wiki/CUCP（如果条目还不存在，请先建立条目再请求上传文件）的<资讯框/某个段落，请说明>。 --Pineappleq（留言） 2024年12月24日 (二) 05:38 (UTC)

我希望能获得更多关于新建条目语气、中立性以及来源选用的建议，并了解目前草稿是否符合维基百科的条件。感谢大家的协助。

大家好，我是一名维基百科的热心编辑者，我的朋友胡女士最近撰写了一篇关于艺术家蔡尔平的条目，草稿多次被退回，所以前来寻求我的协助，我希望能获得大家的建议，帮助我改善条目的语气、中立性以及整体结构，并确认目前草稿是否符合维基百科的方针与指引。她撰写的条目是“蔡尔平”，一位台湾旅美艺术家，条目内容多次被退回，理由主要是“宣传语调过于强烈”。目前草稿已进行以下修改： 一、精简了荣誉记录，并补充了更多第三方来源（如中央通讯社报导）。 二、删除了过度主观的表述，如“受到各界赞赏”。 三、删除了过于抽象的描述，如“一般认为其创作特色为色彩鲜艳、工法精致、且蕴含自然童趣”。

   我希望能獲得更多關於語氣、中立性以及來源選用的建議，並了解目前草稿是否符合維基百科的條件。感謝大家的協助！
   草稿鏈接：https://wiki.citie.us.kg/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)

新进改动的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)

图片可在[7]处找到，不过尚不确定版权要求。如果是合理使用则请检查维基百科:非自由文件使用依据指南，并提供合理的解释，辛苦。——敬颂冬绥 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://wiki.citie.us.kg/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)

条目探讨

参考资料

误用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)

关于“西安市市长列表”一条目的名称问题

虽然本条目标题为“西安市市长列表”，但实际上列出的内容不仅包括历任（民国和人民共和国时期的）西安市市长，还涵盖了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)

电影技术分类应该改为影视作品拍摄技术

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)

初步来看，“影视技术”[8][9]和“电影技术”[10][11][12]这两个称呼皆存在，而“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)

其他

在本地启用安全投票及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)

在下是在这[13]看到的，如果是在下对英文新闻的理解有误还望您指教。--🎋竹生🎍 2024年11月21日 (四) 04:30 (UTC)

原文写 would be，应该看成是“已答应或作出提议，但未实行”。当然，这已经够糟，但毕竟跟做了是有分别的。--派翠可夫 (留言按此) 2024年11月21日 (四) 05:05 (UTC)

(～)补充：本人已签署公开信--派翠可夫 (留言按此) 2024年11月21日 (四) 05:09 (UTC)

如果在下没有理解错的话，根据这篇[14]报道，基金会与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)

续：管理员布告板排版

两个月前由@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)

   其实可以写一个脚本方便关闭[15]

   对于框起来的事情，我个人觉得本来就是为了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)

支持导入。--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:管理操作复核请求所提出，请先阅读相关内容。

操作： [16]

执行者： 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条，是不是宣传？写交通的小聊维基假期旅游，说想去台南高雄玩，是不是宣传？写生医的讨论疫情，写文学的聊戏剧，皆很合理。为何写法政的就不能在自版小聊法政，碍了谁吗？这种种文字在本质上有重大区别吗？

维基百科有多少比例不是“宣传”？几乎大多数的图片文字皆可被解读为具某种宣传或反宣传之意。在某些人眼中耳里，不习惯的事物都很敏感、大惊小怪，但在早已熟悉如日常生活者看来却是如呼吸般再自然平常不过。此定义模糊不明而极可能衍生超多重标准的思想与言论警察之例一开，徒费时间精力，如同让真理部、老大哥与朝阳群众管到每个人在私宅的言行、门口的对联、信箱的广告、墙上的壁画、邻居的私语、手机的通信，有人来串门子，还要被检查，实属荒谬。每个人的页面用户框等自由编排创作就是贴在家门口的宣言标语，用户对待其个人版面的方式亦属自介自治的一部份，两者的性质、内在逻辑与适用对待应属相近。若纵容少数人企图在他人版上搞扩大文革纠斗，将成永无宁日的浩劫。无处不在的监控只会制造更多争端，兹生更广冲突，转移消耗编者注意力，终成反噬人人而成庞大数位极权主义的一九八四。

如果裹小脚的慈禧看到奥运女子金牌就骂人家伤风败俗成何体统、或如果有个别极端伊斯兰教徒看到餐厅在卖猪脚火腿贡丸就呼天抢地说违逆真主要斩首、要下地狱、要烧店家，显非合理，政治控制与资讯封锁是没必要的，别让中国迄今仍时常发生的作法自毙、请君入瓮再实现，维基百科不该日益封闭退步。

管理员千村狐兔（[17]）与章安德鲁（[18]）均已表明尊重版主的态度，这基本上也是由正规编者自理其个人讨论页的传统，除非真属破坏或已被自删、警告表明不受欢迎者。企图惩处被留言者或已表明自行判断筛选者是很奇怪的事。当事人对此个案没意见、不在意、不觉得被骚扰，那就不需要再浪费时间强入人于罪。

十多年来本版基本自在自适健康无碍，天下本无事，实不烦庸人自扰扰人。--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年创建的页面[19]，无论他是奚落暗讽我、感叹我为何当年如此，我都没意见，这也算针对编辑史交换意见。我看不出有什么好屡屡删除的。--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) 自由雨日觉得这挺赞的。

可以参考这种新年邮票、[20]，中国邮政的“福纳百祥”恰好类似二字的图形化。--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)

或许透过 ASN 或公告栏公开征集设计？本站应该不缺乏会设计的人才，问题是没有人知道。--SCP-0000（留言） 2025年1月1日 (三) 04:59 (UTC)

@SCP-2000：公告栏有放了，但放ASN不会太过扰民了吗？--SunAfterRain 2025年1月1日 (三) 08:48 (UTC)