跳转到内容

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

维基百科，自由的百科全书
快捷方式

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

按此刷新页面。

  欢迎光临互助客栈！  
   
  互助客栈是维基人议事相助之处，用以讨论消息、方针、技术以及编辑、求助等议题。
发表议题之前请搜索先前文章，遵守指导及礼仪。任何与维基百科无关的问题，请前往知识问答。

消息
方针
技术
求助
条目探讨
其他
讨论维基相关新闻与消息 讨论方针与草案 解决或报告技术疑难 解决在维基百科中所遇疑难 条目、模板、主题相关探讨 未符任何分区之议题
发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视

查看全部讨论

帮助目录 · 提出疑问 · wikitext基础 · 常见问题 · 常见错误 · 布告板 · 了解术语 · 即时协助 · 规则简述 · 使用指南

If you don't use Chinese, and want to contact Chinese Wikipedia, please leave your message here.
我想要…… 请前往……
如何有效并安全地访问维基百科的方法 如何访问维基百科
与繁简处理有关的问题 字词转换
协助或寻求条目的改善意见 同行评审
对某些特定来源的讨论 可靠来源布告栏
寻找参考文献 文献传递
参与即时讨论或通过电子邮件进行讨论 “即时讨论”或者“邮件列表”

消息

Wikidata weekly summary #656

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

Discussions

Events

  • Upcoming:
    • Wikimedia Deutschland is providing a total of 15 participation scholarships for Wikimania 2025 (7 individual and 4 tandem scholarships). Further information is available on this page. An overview of all questions in the application form is here. Apply here. Closes 8 December 2024.
    • Talk to the Search Platform / Query Service Team—December 4, 2024. The time is 17:00 CET
    • Tomorrow / 3rd December 2024: Linked Data for Libraries LD4 Wikidata Affinity Group session @ 9am PT / 12pm ET / 5pm UTC / 6pm CET. If you would like to attend, please fill out the Etherpad form to ensure all necessary materials are provided for you.
    • Deadline for the Central Asian WikiCon 2025 scholarship application is December 30, 2024. We encourage you to make Wikidata-related submissions (the deadline for submission is March 22, 2025.

Press, articles, blog posts, videos

Tool of the week

  • LoRiS - Generate natural-language descriptions of SPARQL queries via LLM's.

Other Noteworthy Stuff

  • Wikidata:WordGraph: Google released the WordGraph dataset as a belated present for Wikidata’s 12th birthday. The dataset contains 968,153 forms in 39 languages.
  • Product Manager: Wikibase Suite: Wikimedia Deutschland has an open and exciting vacancy for a Product Manager of Wikibase Suite. Apply!
  • Tools or bots which use the wiki replicas (such as Quarry) will observe outdated data for up to 8-10 days, as a result of necessary database maintenance (T367856). Tools or bots which use the APIs will not be affected. (This was previously announced 2024-11-11 but didn’t actually take place yet.)

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • EntitySchemas: We are continuing the work on making it possible to search for an EntitySchema by its label or alias when making a new statement linking to an EntitySchema.
  • PropertySuggester: We have updated the script that generates the suggestions and will update the suggestions next.
  • Lexicographical data: We fixed a visual issue with search results on the Codex-based Special:NewLexeme (phab:T370057)
  • Vector 2022: We are working on designs to fix the remaining issues with the skin on Wikidata.
  • Wikibase REST API: We are finishing the prototype for supporting search in the API.

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

—此条未加入日期时间的留言是于2024年12月2日 (一) 16:14 (UTC)之前加入的。

Wikidata weekly summary #657

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

Discussions

  • New requests for permissions/Bot: KlaraBot - Task(s): Append a human's lifespan to descriptions when they can be authoritatively sourced.
  • Closed request for comments: Audio transcription (P9533) - Closed with no consensus. The discussion is ongoing on the Property P5933 talk page.

Events

  • Past: Amical Wikimedia, the Catalan-language and culture focused thematic Wikimedia Organization organized the Celebrem Wikidata (Let's celebrate Wikidata) project to celebrate Wikidata's 12th anniversary, from November 10 - 30. This included a Wikidata introduction workshop to equip participants with the editing skills to tackle the project's main aim. This was presented as a game to delete duplicate info on Wikidata and Catalan Viquipèdia infoboxes, in three areas: protected buildings, officers' positions and data related to sports teams players. At the end of the event, ~200 Wikidata-fed infoboxes and Wikidata items were improved and many Wikipedia editors edited Wikidata for the first time!
  • Upcoming events:
    • (Deutsch)Wikidata for Legal Historians - Tue. 10 December, 3pm - 7pm (UTC+1). This presentation explores Wikidata as a key platform for LOD, explains its Semantic Web foundation, introduces FactGrid (a Wikidata-based platform for historical research). Highlights potential of both platforms using examples and encourages discussion for legal historical research. Register here.
    • Today (09.12.2024) is the last chance to submit an Abstract for the Wikidata and Research conference (5 - 6 June 2025). If you are interested in participating, please review the submission acceptance format before submitting here.

Press, articles, blog posts, videos

Tool of the week

  • CAT🐈: Metrics computing simple metrics (number of labels, number of descriptions, number of sitelinks, number of statements) for item matching a simple claim.

Other Noteworthy Stuff

  • Template:Image properties New template listing properties that link to images.
  • Let's Connect invites you to get involved in helping spread awareness and knowledge of Wikidata, potentially help organise a Wikidata Learning Clinic. Are you interested in participating? Please sign-up on this registration form.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

Weekly Tasks

—此条未加入日期时间的留言是于2024年12月9日 (一) 16:14 (UTC)之前加入的。

This Month in Education: November 2024

Apologies for writing in English. Please help to translate in your language.

This Month in Education

Volume 13 • Issue 9 • November 2024

In This Issue

This Month in GLAM: November 2024



Headlines
Read this edition in full • Single-page

To assist with preparing the newsletter, please visit the newsroom. Past editions may be viewed here.


方针

导向重复的列表拆分逻辑是否成立？

前期和@红渡厨：讨论了“硚口区各级文物保护单位列表”、江岸区各级文物保护单位列表”类列表的存在逻辑，红渡厨提出，硚口区各级文物保护单位列表可以解释为对“武汉市各级文物保护单位列表”、“湖北省各级文物保护单位列表”的拆分（“这类列表，他的本质是一种拆分的逻辑”）。

而在年初无锡市全国重点文物保护单位列表、青岛市全国重点文物保护单位列表的讨论中，红渡厨认为 无锡市全国重点文物保护单位列表 和 江苏全国重点文物保护单位列表 属于同一事物重复创建条目，“江苏省表里面包不包含无锡市的内容？既然包含了，那这部分是不是和无锡市表的内容重复？”

那么现在问题是，如果说硚口区各级文物保护单位列表是对武汉市各级文物保护单位列表的拆分，那么无锡市全国重点文物保护单位列表也是对江苏全国重点文物保护单位列表的拆分，江苏省表里面无法排除无锡市的内容，武汉市表里也一定无法排除硚口区的内容，导向内容重复的列表拆分逻辑是否成立？--猫猫的日记本（留言） 2024年11月15日 (五) 13:34 (UTC)[回复]

NT:NRVE：由于格式和展示的原因而创建一篇分离的条目是一种常见情况；但这在本质上并不意味着“关注度的继承”，出于方便排版和浏览的原因，这种做法通常会得到接受。--——— 红渡厨（留言・贡献） 2024年11月15日 (五) 13:37 (UTC)[回复]

麻烦解释解释在这里具体的格式和展示原因是什么。--猫猫的日记本（留言） 2024年11月15日 (五) 13:43 (UTC)[回复]

太长。--——— 红渡厨（留言・贡献） 2024年11月15日 (五) 13:50 (UTC)[回复]
我试过了，我觉得并不长，长和不长未见有字数标准，都是你我主观判断，但长与不长都无法避免内容重复，除非按照 第七批全国重点文物保护单位 和 第七批全国重点文物保护单位中的古遗址，一个是文字介绍，另一个才是表格，这样确实可以不重复，但如果这种写法成立，那岂不是说，只要把 江苏全国重点文物保护单位列表 改成 文字介绍， 无锡市全国重点文物保护单位列表 甚至 梁溪区全国重点文物保护单位列表 就可以成立了。--猫猫的日记本（留言） 2024年11月15日 (五) 14:08 (UTC)[回复]
您拿《杭州市各级文物保护单位列表》来证明不长我觉得实在是很无语。市保和县保这两个正好是最多的，结果都拿出去单列，可不就不长吗！--——— 红渡厨（留言・贡献） 2024年11月15日 (五) 14:13 (UTC)[回复]
但有个细节阁下也要注意，现有的 XX区县各级文物保护单位列表 关于 XX区县本级 的内容，实质上和 XX区县文物保护单位 的条目内容完全一样，而借用地方志可以证明 XX区县文物保护单位 本身具有关注度，而且先于 XX区县各级文物保护单位列表 在维基百科出现， 那么在建立 XX区县各级文物保护单位列表 的时候，XX区县文物保护单位列表 是否又可以单独存在？单独存在，岂不是又出现了 同一事物重复创建条目 ？--猫猫的日记本（留言） 2024年11月15日 (五) 14:25 (UTC)[回复]
我说的过于拗口，举例 Template:上海市各区县文物保护单位索引 和 Template:上海各级文物保护单位，全部存在同一事物重复创建条目的情形。--猫猫的日记本（留言） 2024年11月15日 (五) 14:30 (UTC)[回复]
不对，这是两码事。“XX县文物保护单位”，介绍的是每一批县保都有谁，可以按批次写。而“XX区县各级文物保护单位列表”写的是该地文物保护单位的现有级别，这并不能被认为是提供同一种内容。--——— 红渡厨（留言・贡献） 2024年11月15日 (五) 14:31 (UTC)[回复]
这解释很牵强，并不是每个编者都跟阁下一样对条目持此种理解和操作，上海的例子就是如此，就像 Template:四川省文物保护单位 创建者认为必要，可以提供不同内容（见下面的 级别参数），而其他人未必这么以为。--猫猫的日记本（留言） 2024年11月15日 (五) 14:49 (UTC)[回复]
另外我感觉某种程度上出现了连环套，即松江区全国重点文物保护单位列表、松江区境内的上海市文物保护单位列表、松江区文物保护单位 是否可以视为 松江区各级文物保护单位列表 的拆分？如果按照区划拆分的逻辑成立，那么按照级别拆分的逻辑也成立，何况，地方志也能找到支持，既然都列各级了，那么自然每个级别也符合关注度。--猫猫的日记本（留言） 2024年11月15日 (五) 14:55 (UTC)[回复]
拿我自己的举例， 海宁市各级文物保护单位列表 和 松阳县各级文物保护单位列表 ，其中的县级内容即原来的 海宁市文物保护单位 和 松阳县保护单位列表，一字没动挪过来的松阳县文物保护单位，本质上，并无法统一 XX区县文物保护单位 中的 区县本级 内容是按批次写，还是按现状级别写。--猫猫的日记本（留言） 2024年11月15日 (五) 15:04 (UTC)[回复]
我感觉阁下似乎陷在“拆分”的逻辑里出不来了。市级拆到区县级列表，是因为太长，而把区县级列表再拆一遍，则没有必要，因为本身也不会有多长。--——— 红渡厨（留言・贡献） 2024年11月15日 (五) 15:05 (UTC)[回复]
我没看出来哪里牵强了，在不同页面提供同样的内容，本就不允许。阁下提到的上海的例子，那是因为条目创建者根本就没筛，直接把县保内容复制上去了，需要有人去整理。至于四川的模板，也许您忘了，Wikipedia:页面存废讨论/记录/2015/08/02#Template:四川省文物保护单位，当初您可是同意删除此模板的。--——— 红渡厨（留言・贡献） 2024年11月15日 (五) 14:59 (UTC)[回复]
拆分的逻辑可是阁下提出来的，阁下既然提出来了，就需要逻辑自洽，如果导向意想不到的结果，就可以反证逻辑自己的问题。不同页面提供不同的内容并不难，比如我上面说的一个文字，一个列表，但这是否就可以代表可以进行拆分了呢。--猫猫的日记本（留言） 2024年11月15日 (五) 15:11 (UTC)[回复]
唉，您真是让我不知道说什么好，10月30日阁下才去看过关注度是什么，结果今天又忘了。我今天又讲了一遍，阁下似乎转头又忘记了。拆分的逻辑，这是出自于NT:NRVE的说法，根本就不是我原创。--——— 红渡厨（留言・贡献） 2024年11月15日 (五) 15:20 (UTC)[回复]
可以说上海的例子是因为 区县本级文物保护单位 在前，直接编者抄一下，那么如果 区县各级文物保护单位 在前，再去建立 区县本级文物保护单位 呢，好像也无法避免“属于同一事物重复创建条目”，本质上“江苏省表里面包不包含无锡市的内容？既然包含了，那这部分是不是和无锡市表的内容重复？”这句适合每一种类似情形。
我要问的就是这个问题，关注度提到了“由于格式和展示的原因而创建一篇分离的条目”，但是如果进一步分析，如果分离出的条目与主条目几乎不可避免地重复，那么显然有违反了维基百科:删除方针“内容分歧（同一事物重复创建条目，除非合并或重定向更合适）”。--猫猫的日记本（留言） 2024年11月15日 (五) 15:29 (UTC)[回复]
我在开头就说了，阁下既奉 维基百科:关注度 为圭臬，又奉 维基百科:删除方针 为圭臬，现在两个圭臬自己打架，阁下需要再自创第三圭臬么？--猫猫的日记本（留言） 2024年11月15日 (五) 15:33 (UTC)[回复]
补充：如果阁下认为 松江区文物保护单位 和 松江区各级文物保护单位 不属于内容分歧 ，那么我认为 无锡市全国重点文物保护单位列表 和 江苏全国重点文物保护单位列表 同样不属于内容分歧，在几乎不存在内容分歧的情况下，到底能拆分到什么程度就需要重新审视了。--猫猫的日记本（留言） 2024年11月15日 (五) 15:47 (UTC)[回复]
  1. 在这个问题上，《维基百科:关注度》和《维基百科:删除方针》不存在冲突；
  2. 阁下提到的“区县本级文物保护单位”和“区县各级文物保护单位列表”条目不存在冲突。我上面已经回复过了：那是因为条目创建者根本就没筛，直接把县保内容复制上去了，需要有人去整理。
--——— 红渡厨（留言・贡献） 2024年11月15日 (五) 16:03 (UTC)[回复]
那么好了， 无锡市全国重点文物保护单位列表 和 江苏全国重点文物保护单位列表 同样不存在冲突，条目创建者甚至还做了筛选，提供了不同的内容（如果完全一样，DYK早就提删了不是么，DYK也不是走过场吧），没筛选的都可以通过有人去整理保留，有筛选的那也一样不需要删除。--猫猫的日记本（留言） 2024年11月15日 (五) 16:06 (UTC)[回复]
我要提醒阁下的是，《Wikipedia:页面存废讨论/记录/2024/03/19#无锡市全国重点文物保护单位列表》，当时的删除，是执行社群共识，而非我一个人的意见。--——— 红渡厨（留言・贡献） 2024年11月15日 (五) 16:14 (UTC)[回复]
本质上，“区县本级文物保护单位”和“区县各级文物保护单位列表中的区县本级文物保护单位内容”基本一样，即前者相当于后者的一部分，再怎么按批次也无法完全跳出来。那么同样的逻辑也适用于 无锡市全国重点文物保护单位列表 和 江苏全国重点文物保护单位列表，前者和后者的无锡市内容也是基本一样，前者也是后者的一部分，也无法完全跳出来，那么显然阁下这里是双重标准。
还说什么社群共识，社群共识个鬼啊，你看看当时几个投保留的？我那个济南古城又有几个持保留意见的？无数例子证明，如果社群共识和阁下一致，阁下就认为是共识，不一样，阁下并不认为是共识。--猫猫的日记本（留言） 2024年11月15日 (五) 16:18 (UTC)[回复]
  1. “区县本级文物保护单位”和“区县各级文物保护单位列表中的区县本级文物保护单位内容”并不一样，一个介绍现有县保，一个介绍历史上所有县保；
  2. WP:共识不是点票。
--——— 红渡厨（留言・贡献） 2024年11月16日 (六) 03:26 (UTC)[回复]
上面列出的 海宁市各级文物保护单位列表 和 松阳县各级文物保护单位列表 您不看么？--猫猫的日记本（留言） 2024年11月16日 (六) 08:38 (UTC)[回复]
我上面的回复您不看么？--——— 红渡厨（留言・贡献） 2024年11月16日 (六) 08:43 (UTC)[回复]
我再提一个例子，玉环市文物保护单位 和 玉环市各级文物保护单位列表，一个简写，一个详写，但是如此一来，阁下所担心的“市保和县保这两个正好是最多的，结果都拿出去单列，可不就不长吗”就不存在了，所谓武汉市各级文物保护单位列表因为太长拆分成各区的理由一样也不存在了。--猫猫的日记本（留言） 2024年11月16日 (六) 08:46 (UTC)[回复]
现在就陷入了一个悖论：
如果“区县各级文物保护单位列表中的区县本级文物保护单位内容”详写，那么必然和 “区县本级文物保护单位” 自身陷入内容重复。
如果“区县各级文物保护单位列表中的区县本级文物保护单位内容”简写，那么 地级市各级文物保护单位列表 太长而拆分成 区县各级文物保护单位列表 的逻辑便不成立。--猫猫的日记本（留言） 2024年11月16日 (六) 08:54 (UTC)[回复]
至于 区县本级文物保护单位”和“区县各级文物保护单位列表中的区县本级文物保护单位内容”，一个介绍现有县保，一个介绍历史上所有县保的这种设想，我拿自己的例子无法让阁下信服，但我拿其它人的玉环例子便可以证明无法达成共识，这里虽然分详写和简写，但都是介绍了历史上所有县保。--猫猫的日记本（留言） 2024年11月16日 (六) 09:06 (UTC)[回复]
您能别在这里自说自话好么？这证明啥了啊？都哪跟哪啊？--——— 红渡厨（留言・贡献） 2024年11月16日 (六) 09:36 (UTC)[回复]
证明了啥啊，如果要详写，不就等于导致“江苏省表里面包不包含无锡市的内容？既然包含了，那这部分是不是和无锡市表的内容重复？”结果不就是提删？
如果要简写，不就等于解决了“市保和县保这两个正好是最多的，结果都拿出去单列，可不就不长吗”， 那还拆啥呢？
这不都是阁下自己说的嘛。--猫猫的日记本（留言） 2024年11月16日 (六) 09:46 (UTC)[回复]
阁下左一下说江苏省表，右一下说玉环市表，七啊八啊的我看不懂，麻烦阁下重新整理您的语言和逻辑。--——— 红渡厨（留言・贡献） 2024年11月16日 (六) 10:00 (UTC)[回复]
阁下一向善辩，说到关键点上掉链子我是不信的--猫猫的日记本（留言） 2024年11月16日 (六) 10:02 (UTC)[回复]
我辩不辩你也要把话讲清楚啊？话都没讲清楚你让我说啥。--——— 红渡厨（留言・贡献） 2024年11月16日 (六) 10:04 (UTC)[回复]
我来理一下，建议阁下先不要着急回复，也等等其他人说话。
首先，在前期讨论中分析“硚口区各级文物保护单位列表”、江岸区各级文物保护单位列表”类列表的存在逻辑，红渡厨提出，硚口区各级文物保护单位列表可以解释为对“武汉市各级文物保护单位列表”、“湖北省各级文物保护单位列表”的拆分，我问为何要拆分，回复理由是“太长”。
而在另一个讨论中，红渡厨提删了 无锡市全国重点文物保护单位列表、青岛市全国重点文物保护单位列表，理由是江苏全国重点文物保护单位列表和山东全国重点文物保护单位列表对应内容重复，“江苏省表里面包不包含无锡市的内容？既然包含了，那这部分是不是和无锡市表的内容重复？”。
好，现在问题来了，类似“硚口区各级文物保护单位列表”、江岸区各级文物保护单位列表”这样的区县级列表绝大部分会包含区县本级文物的内容，逻辑很简单，各级都有了，本级还能没有么（个别没有的不算，我实话实说）？
但是在维基百科还同时存在很多以本级文物为名建立的条目，例如 Template:上海市各区县文物保护单位索引 和 Template:上海各级文物保护单位全部是同时存在的，再如玉环市文物保护单位 和 玉环市各级文物保护单位列表，也是同时存在的，而且 本级文物保护单位 条目 创建的时间一般早于 各级文物保护单位列表。
那么如果 区县各级文物保护单位列表 中详细列举 区县本级文物保护单位 的内容，必然出现“对应内容重复”，导向是需要删除 本级文物保护单位 ，就和上面提删 无锡市全国重点文物保护单位列表 一样。
那么如果 区县各级文物保护单位列表 中不去详细列举 区县本级文物保护单位 的内容，而是像玉环这样简单概括，那么 地级市各级文物保护单位列表 也完全可以简写 市级和县级的内容，把这些内容放到 市级和县级本级保护单位 里去写，甚至放个链接我认为也没问题，我以杭州市各级文物保护单位列表为例试过了，如此一来，只要武汉市各级文物保护单位列表就行了，完全不需要拆分，那么“硚口区各级文物保护单位列表”、江岸区各级文物保护单位列表”这些都可以删除，合并。--猫猫的日记本（留言） 2024年11月16日 (六) 10:20 (UTC)[回复]
  1. 条目的创建时间早晚，与条目的存在是否合理无关；
  2. 麻烦阁下不要举一堆例子，看的我头昏。您要么只拿一个例子举例；
  3. 我一再说过，“区县本级文物保护单位”和“区县各级文物保护单位列表中的区县本级文物保护单位内容”并不一样，一个介绍现有县保，一个介绍历史上所有县保（包括已经升级的）。他们提供的是两种内容；无论是阁下口中的“详细列举”或“简单概括”，他们提供的都是两种内容；
  4. 有鉴于目前中国大陆对于文物的重视程度越来越高，各地的文物保护单位只会越来越多，而不可能会变得越来越少。在这种情况下，我不认为大表的存在会比小表更合理。
--——— 红渡厨（留言・贡献） 2024年11月16日 (六) 12:23 (UTC)[回复]
另外，我确实表达过关注度可以作为“各级列表”的存在的合理解释，但我可从来没说过只有关注度才能作为“各级列表”的存在的合理解释。--——— 红渡厨（留言・贡献） 2024年11月16日 (六) 16:23 (UTC)[回复]

刚才在做表，那直接做个表好了，大家看上去比较直观，上面类似“一个介绍现有县保，一个介绍历史上所有县保”这种辩解已不值得一再反驳了，既然阁下倾向于拆分，且“不认为大表的存在会比小表更合理”，不如让大家直接一次讨论究竟可以拆分到哪一级好了，一次解决一个终极问题，理论上，除了国家级、省级、社区的市级和区县级四个最基本的表，其它表格都是历史上各位编者反复探索、不停倒腾出来的，本质上并没有创造新的内容，另外目前这些表格要么强干弱枝，要么强枝弱干，要么没干只有枝，要么没枝只有干。--猫猫的日记本（留言） 2024年11月17日 (日) 04:20 (UTC)[回复]

本来阁下讨论的是各级列表的问题，好家伙，现在又扩大到一堆列表，等我一点点看，后面再慢慢回复吧。--——— 红渡厨（留言・贡献） 2024年11月18日 (一) 07:11 (UTC)[回复]
体系 总表 第一级拆分 第二级拆分 第三级拆分 第四级拆分
国家级 全国重点文物保护单位（国家级，基础表） 江苏省境内的全国重点文物保护单位列表（按省拆分）
第一批全国重点文物保护单位（按批次拆分） 		无锡市全国重点文物保护单位列表（按地级市）
第七批全国重点文物保护单位中的古建筑（按批次再按类型进一步拆分） 		目前未见（格式为宜兴市全国重点文物保护单位列表）
省级 宁夏回族自治区文物保护单位
河北省文物保护单位（省级，基础表） 		银川市境内的宁夏回族自治区文物保护单位列表（按地级市拆分）
河北省第二批文物保护单位（按批次拆分） 		目前未见（按区县拆分，格式为灵武市境内的宁夏回族自治区文物保护单位列表）
设区的市级 杭州市文物保护单位（市表、基础表） （按区县拆分未见，格式为萧山区境内的杭州市文物保护单位列表）
第四批武汉市文物保护单位（按批次拆分）
区县级 松江区文物保护单位（区表、基础表）
长兴县文物保护单位（县表、基础表）
各级 目前未见（格式为全国各级文物保护单位列表，本表应完全包含这个表里的所有内容，理论上无必要） 目前未见（格式为浙江省各级文物保护单位列表，本表应完全包含国家级按省拆分的表、省本级、地级市本级、区县本级） 湖州市各级文物保护单位列表
广州市各级文物保护单位列表
南阳文物保护单位列表（按地级市拆分，本表应完全包含国家级按地市拆分的表、省保按地市拆分的表、地级市本级、区县本级） 		松江区各级文物保护单位列表（按区拆分，本表应完全包含国家级按区县拆分的表、省保按区县拆分的表、地级市按区县拆分的表、区县本级） 庐山各级文物保护单位列表，街道和镇一级别的已被删除（见此）

@Shizhao：这个系列的几次提删都有阁下的参与，我就@一下，上面表我都已经列了，在拆分（以及组合）方面的沉迷已经成为维基百科在文物领域长久的问题，也许各位管理员也可以讨论一下。--猫猫的日记本（留言） 2024年11月17日 (日) 04:59 (UTC)[回复]

这类问题其实是不是跟过度分类有异曲同工之妙，即向下到某个层级后，继续拆分反不利于百科全书维护？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月18日 (一) 06:58 (UTC)[回复]
我想确认一下，上面这个表格说明的是现状吗？Sanmosa 新朝雅政 2024年11月25日 (一) 09:15 (UTC)[回复]
大概是吧，同时带有猫猫的日记本自己的理解。--——— 红渡厨（留言・贡献） 2024年11月25日 (一) 09:17 (UTC)[回复]
这样说吧：我倾向于在列表在不分拆会导致长度过长的情况下分拆，直至所有子列表的长度不会过长为止，但这时候我不认为总表（或上表所称的“基础表”）有保留的必要，总表占的位置如果能合理地改写为概述条目的话就改写为条目，不然就该改为条目索引（或消歧义，至少现在的操作是这样）。我的这个意见不限于文物保护单位列表（比如日本年号列表现在的处理我是不满意的，我倾向于把它改为条目索引，但之前遭遇部分用户的反对而未能成事）。Sanmosa 新朝雅政 2024年11月25日 (一) 09:32 (UTC)[回复]
我部分支持Sanmosa的观点，继续就各级文物保护单位列表存在的必要性补充两句，一方面，子列表不仅是不会过长，而且还要不会过短。以浙江为例，浙江国保281处，省保990处，90个县级行政区平均一下，每个县只有3个国保，11个省保，大头是市县保，市保（设区的市级）通常覆盖市辖区，县级市、县大多并没有这一层级，剩下的就是自己的市县保，而它们可以独立建立条目（例如玉环市文物保护单位），这就导致，各级文物保护单位类的条目如果落实到县这一个层面，那么基本上就是平均3个国保+11个省保+可以独立建立条目的市县本级内容（例如玉环市各级文物保护单位列表，1个国保+7个省保+本级）。如果像玉环这样，把市县本级内容导向它们自己的条目，那么各级文物保护单位列表这个条目的长度是不够的，剩下只有国保和省保平均14个条目，如果不这样，那么就将导致很大一部分的重复工作。
另一方面，子列表的长和短不能靠编者自行发挥，由于所有列表都是脱胎于文物部门公布的名单，这部分原始内容其实是比较单薄的，而以硚口区各级文物保护单位列表、江岸区各级文物保护单位列表这样的特色列表为例，又出现了和条目内容重复的倾向，突出表现在编者自行发挥的“简介”一栏，例如“该文物为一佛寺建筑群，内有天王殿、大雄宝殿等建筑，亦为武汉四大丛林之一。该寺院开辟于1877年，初名“古德茅蓬”，阳夏战争期间古德寺僧众自发救助伤员及埋葬死者，战后获得中华民国政府嘉奖，黎元洪题匾并改为“古德禅寺”。大雄宝殿建于1921年，钢筋混凝土结构，外形仿照缅甸阿难陀寺风格。文革期间寺院宗教文物及陈设被毁，后用作武汉市照相机厂使用。1986年后产权归还佛教协会”（古德寺）。实际上，简介到底需不需要？即使需要，也不应该是这样的，从文物保护单位列表的主题出发，核心的是应当补充文物在构成（即进一步补充“子项”信息，说明古德寺哪些建筑是文物本体）、年代（即进一步补充“年代”信息，说明古德寺文物本体，或者代表性文物本体的年代）等前述信息的不足，最多再写一写文物价值（古德寺何以能够列入国保），实际上东拼西凑，有历史、现状、构成、年代、功能、形制等等（还没有几个提到价值），很多内容都完全可以放到条目本身里去讲，所以支撑其长度合理性的相当一部分内容也是值得推敲的。--猫猫的日记本（留言） 2024年11月25日 (一) 13:52 (UTC)[回复]
话说我曾经当面问过江岸区文化和旅游局的某文物工作负责人，问：古德寺文物构成有哪些？答曰：不知道。--——— 红渡厨（留言・贡献） 2024年11月25日 (一) 14:16 (UTC)[回复]
阁下要是还有什么问题您一个个问我吧。阁下惯常喜欢一问一大堆问题，我脑容量不够，反应不过来。我上维基百科只想搞点自己喜欢的事，您老让我这个曾经写作文交白卷的人，在维基百科写作文，脑子吃不消。我的观点总结起来大概也就这么几个：
  1. 长了、就拆：比如全国重点文物保护单位，每批国保基本上都是几百上千个，塞一个条目里铁定长，毫无必要，所以按批次、按省份拆；再比如，省保，别的省我不熟，湖北省文物保护单位，按湖北省文化和旅游厅的统计，目前共八批，一共1098处。一千多啊，放一个条目里怎么看得完，肯定也得拆；
  2. “各级文物保护单位列表”，就按县级来做“各级文物保护单位列表”。这是出于以下几点的考虑：
  1. 中国大陆的文物保护体制便是县级为最基础级；
  2. 中文维基百科的现实是，县级列表已大量铺开，再要改，很麻烦；
  3. 别的地方我不熟，还是说武汉市，按武汉市文化和旅游局的统计，该市目前一共有278处文物保护单位（最新公布的第六批市保和武汉市所有区保未纳入统计），一个条目里塞300~400多的列表项，仍然是很多的，不方便，最好还是拆到县一级；
  4. 若要交由编者自己判断到底是按地级市来写还是按县级来写，那会每个人都有不同理解、不同想法，干脆一刀切。大家都统一到县级的话，编者要编辑起来也更方便，读者查询也更方便。
--——— 红渡厨（留言・贡献） 2024年11月26日 (二) 11:10 (UTC)[回复]
(～)补充，今天正好又去看了一下《国务院关于进一步加强文物工作的指导意见》这份文件，其中提到：“文物保护，基础在县。”--——— 红渡厨（留言・贡献） 2024年11月26日 (二) 13:01 (UTC)[回复]
看到这里，我可以再给予一些进一步意见：
  1. 所有“（某地）各级文物保护单位列表”应该是不必要的。
  2. “（某地）（某级）文物保护单位列表”原则上应该分拆至县级。两种可能的例外情况分别是：
    • 拆至县级会使县级列表过短；
    • 该地级行政区是直筒子市，不管辖县级行政区。
  3. 省级文物保护单位似乎不需要另外按批次拆分列表，但全国重点文物保护单位数量繁多，因此全国重点文物保护单位的列表或许可以考虑先按批次，然后再按行政区划级别拆分，按行政区划级别拆分的方式参照2。Sanmosa 新朝雅政 2024年11月27日 (三) 06:06 (UTC)[回复]
我整体支持总表简、分表繁的方向，但我希望能达到两个目标，以最大限度地减少重复、节省人力，一是避免总表和分表使用同样的形式，最好能一个简一个繁（目前已出现的形式见表二），二是在内容足够的情况下，表格总量最少，上面红渡厨提出了武汉市目前一共有278处文物保护单位（以及一些区保），那么我这里直观列出两种分拆方式的表格总量（见表三）。--猫猫的日记本（留言） 2024年11月28日 (四) 16:25 (UTC)[回复]
阁下有一点说的不太对，最大限度地减少重复、节省人力，事实上真正愿意写文物的就那么几个人，而且大部分都不是经常写，把这些人平均到每个省，1/4个人都不到，本来就没什么人写。--——— 红渡厨（留言・贡献） 2024年11月30日 (六) 15:46 (UTC)[回复]
“事实上真正愿意写文物的就那么几个人”这句话隐含的应该是，一部分是写文物的，另一部分是刷文物的，比如：
（1）94rain刷的一批浙江省保（例如引坑钟氏大屋）
（2）Ngguls君刷的一批山东省保（例如五色崖赵氏节孝坊）
（3）Urga君刷的一批四川省保（例如唯仁山庄，当然还有另立一套模板的事情，不重复说了）
（4）Walter Grassroot君刷的一批山西省保、宁夏省保、江苏省保（例如义尖——安坪遗址、红山堡城址、伊芦山石刻群）
（5）Tianyamm君刷的一批河北省保、广西省保、甘肃省保、吉林省保、青海省保、广东市县保（例如东韩台古墓、石刻牌坊、山那树扎遗址、狼牙坝古墓群、松多乡慧宁寺、苏氏私塾）
（6）TIY刷的一批列表（就是各级文保列表）以及“曲线救国”式的另一批镇级列表（例如云山街道 (兰溪市)、女埠街道）
不同于模板，条目铺开就是一个烂摊子，小作品的烂摊子不详细说了，随便点开看看就行了，而靠TIY坚持不懈的努力，现在各级文物保护单位基本各省都有，但除了上海全市（这不是TIY的功劳，这是Fayhoo打下的基础）、云南全省（Kcx36的作品）,以及湖北（阁下参与的）、浙江（Siyuwj的作品、我也有一些）、福建（FradonStar的作品）、四川（Kcx36的作品）的极少部分外，剩下的也基本都是国保+省保摘编组合的烂摊子，格式都不带改的。
当年这些小作品基本上都是没有实质内容的垃圾，或者说好听一点，它并不能在政府公布名单的基础上提供新的内容，也有人去质疑，关于Walter Grassroot大量创建山东省文物保护单位、关于Tianyamm2使用BOT创建文保单位条目、关于User:Urga最近对四川省文物保护单位的贡献，但没什么效果，于是在后来无数的编者眼里，已经是既成事实了。
一样的，对于TIY刷出来的这些各级文保列表，后来的编者（比如Kcx36、FradonStar）也把它当作一个既成事实（这就像我当年把Template:老北京城、Template:老天津卫当作一个既成事实）。所以，我说的节省精力更多的不是指在座者，在座者的精力已经付出了，即便以后拆分一定是大势所趋，但趁现在想办法做一些扭转或者规范，长远得看去节省后来者的精力，那还是有必要的。--猫猫的日记本（留言） 2024年12月1日 (日) 14:38 (UTC)[回复]
方式 示例 信息量 篇幅 备注
按批次列表式 甘肃省文物保护单位 较多（编号、名称、分类、时代、地区、地址、坐标、图片），另外一些还有占了大约一半篇幅的简介 较长
按地区点列式 浙江省文物保护单位 一般（编号、名称、地区和图片） 一般
按地区模板式 山东省文物保护单位 较少（仅地区、名称） 较短
综合式 河南省文物保护单位（统计表式+按地区点列式）
云南省文物保护单位（大模板式+按批次列表式）
福建省文物保护单位（按批次列表式+按地区模板式）
分拆方式 分表 备注
按国省市县各级 武汉市境内的全国重点文物保护单位列表（33处）
武汉市境内的湖北省文物保护单位列表（106处）
武汉市文物保护单位（139处）
东西湖区文物保护单位、蔡甸区文物保护单位（类似列表一共能列5个，见备注） 		一共13个区里，我查到的是江岸区、江汉区、硚口区、汉阳区、青山区和洪山区没有，武昌区、汉南区只有1处没必要，东西湖区、蔡甸区、江夏区、黄陂区和新洲区数量较多可以列，如果我查错了请修正。虽然可以说这些数量少的区远期还可能会公布，但目前设区的市以市保代替区保也可能是一种趋势，杭州即是如此，当然上海这样的直辖市不算。
按区县各级 江岸区各级文物保护单位列表
硚口区各级文物保护单位列表（类似列表一共13个）
其实我想不明白总表存在的必要性在哪里，（各类，包括但不限于文保）列表内容重复的问题主要就是出在总表。Sanmosa 新朝雅政 2024年11月29日 (五) 05:39 (UTC)[回复]
我觉得总表有两部分的内容就够了，一是在空间线上给出一个数据统计，包括分批次、分类型、分地区、分时代（最后这个不一定必要）等等，顺带介绍其中的极值（类型最多的文物、文物最多的地区、年代最久的文物）或可以归纳的特点（某一类文物在某个地区集中，比如浙江的摩崖造像大约一半集中在杭州） ，类似于《全国重点文物保护单位统计特征分析与研究》，二是在时间线上给出一个历史上各个批次所体现出的在保护内容上的侧重（比如大量收录某一类型的文物）或者在保护观念上的突破（从单体到整体，从片段到全线，出现新的文物类型，出现新时代的文物），类似于《浙江省第八批省级文物保护单位名单公布》。如果编者想了解具体内容，除了分地区拆分出来的列表之外，还可以直接在维基文库中查询原始公布文件（代替分批次拆分出来的列表）。但显然就像前面提到的日本年号一样，这到底是不是能被大家普遍接受呢？--猫猫的日记本（留言） 2024年12月1日 (日) 15:40 (UTC)[回复]
具体能不能写的那么细，写“在时间线上给出一个历史上各个批次所体现出的在保护内容上的侧重”什么的，那也要看可靠来源有没有这方面的内容，这不是编者自己就能随心所欲的。
但是大体上，基本也就是“总简分繁”了。--——— 红渡厨（留言・贡献） 2024年12月1日 (日) 15:56 (UTC)[回复]
总体的介绍（至少包括有几批，各批公布时间、数量）总得有地方放吧，拆为分表后还需要有总表充当列表索引吧。然后我个人的意见是留个口子，允许总表以点列式列出所有项目，例如X省文物保护单位拆分至各批列表后，总表除了统计和综述外，还允许按所在地以纯点列式列出所有X省省级文保；这样一是方便检索（要不然查某项是不是省保难道要每批的条目都点进去看？），二是弥补了按批次拆分导致列表地域关联性差的缺点；排版紧凑点也占不了多少空间。--Kcx36（留言） 2024年12月1日 (日) 16:17 (UTC)[回复]
我自己的意见是总表占的位置如果能合理地改写为概述条目的话就改写为条目，不然就该改为条目索引。Sanmosa 新朝雅政 2024年12月2日 (一) 00:55 (UTC)[回复]

由于Special:Diff/84991994这个问题我认为与那边的讨论没有太大关系，因此我到这里回复：

答：合理。我认为省保条目的理想状态就是：不介绍具体有哪些省保，只写一些有关的数据，和一些纯文字性的信息，关于具体的省保有谁，这交给“第X批XX省文物保护单位”和“XX市境内的XX省文物保护单位”条目去写。大概就是类似于现有版本的《全国重点文物保护单位》条目和《第X批全国重点文物保护单位》条目、《XX省境内的全国重点文物保护单位列表》条目的关系。——— 红渡厨（留言・贡献） 2024年11月18日 (一) 08:37 (UTC)[回复]

姑且不论其他领域，若社群能就如何拆分大陆文化资产议题条目（列表）问题达成共识，相信能避免往后一再引发冲突。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月25日 (一) 06:48 (UTC)[回复]

关于Wikipedia:避免地域中心#地理，建议增加关于“来”字的论述

“来”字的用法常常是错误的，例如“来华”、“来港”，乃至一般用法的“来到”。从逻辑上来说它不仅是地域中心的思考所导致的，甚至比现行方针中地域中心#地理的例子更加直接。在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)[回复]

修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应

根据数月以来在存废讨论观察到的共识和一些编者的观点，以及多次和相关编者的交流讨论，现提出修订《外文重定向》方针。同时，阅读大量条目后发现，很多条目——包括大量典优条目——的首句外语名称标注格式已和现行MOS:外语名称差异较大，结合同一些编者的讨论，提出修订首句《外语名称》格式指引。除此以外，本次修订期待做到《外文重定向》与《外语名称》互相对应。

《外文重定向》方针
现行条文

基于维基百科不是词典，一般而言，仅在语言符合以下条件时方可建立来自此语言的重定向：

  1. 此语言（或使用此语言的文化）与目标条目有明确关联（例如：公司／作品／人物／地方的外文原名），和／或
  2. 有合理期望中文使用者会使用此语言指称目标条目（例如部分专业文献常见之拉丁化外文人名）
提议条文

基于维基百科不是词典，一般而言，仅在外语文本[1]符合以下条件之一时方可创建外文重定向（以下条文均已排除某外语文本已是中文维基百科条目标题[2]或消歧义页标题的情况）：

  1. 该外文文本常常直接在中文语境使用（有时甚至比对应中文更常用），通常为字母词（如CD指激光唱片）和英语词（如bug指程序错误）
  2. 该外文文本是专有名词（如人名、地名、作品名、公司名等），且该外语专名和外语语种与目标条目有明确联系，尤其是条目标题对应语言的外文专名
    • 若该外文文字不是拉丁字母，通常也可建立对应的罗马化转写文本作为重定向，除非该专名的罗马化转写在中文语境的出现率明显低于原文（如一些通常以汉字形式出现的原文仅由汉字组成的日语人名、地名等[3]）。若罗马化转写形式不止一种，社群对“是否应建立所有形式的罗马化文本”未有共识
    • 若该外语不是英语，通常也可建立对应英语的外文重定向，除非英语名称在中文语境的出现率明显低于原文名[4]
  3. 使用该外语的文化与目标条目有明确联系，且外文文本所指事物是目标条目的介绍对象（如使用外语的某一民族的特色饮食的外文名称）
    • 若该外文文字不是拉丁字母或该外语不是英语，可建额外的罗马化重定向与英语重定向的规则和上条相同
    • 若该外文文本仅是描述性的（多个单词的简单组合），例如“cinema of the United Kingdom”（英国电影），一般不要建重定向
  4. 鉴于英语是大部分学术领域的国际通用语言，且大量学科术语中文译名不统一、不固定（甚至尚无可靠来源译名），故建议创建通用的专科术语英语名重定向导向到对应的条目（除非相关领域学术研究使用中文的情况明显多于英语）。中英术语对照可参考术语在线（中国大陆）、乐词网（台湾）等网站，以及各类百科全书、专科辞典、专著、论文等（极少数学术词汇并非英语，也可比照创建）
  5. 生物学名（包括物种名和属名等分类单元的学名）、国际非专利药品名称（INN）等规范名或通用名
  6. 其他常会在中文语境出现的外文文本，或其他有合理期望中文使用者会使用外文文本指称目标条目的情况。创建者需在重定向讨论页说明创建理由

原则上不允许创建带消歧义后缀的外文重定向。当某一外文文本对应多个条目时，若有一个含义明显重要及常用，则重定向之；若没有一个含义明显重要及常用（即应“平等消歧义”的情况，参见WP:消歧义命名），则应将该外文文本重定向至相应的外文或中文消歧义页。确需创建带消歧义后缀外文重定向的，消歧义括号中的文字应使用中文，且创建者需在重定向讨论页说明创建的合理理由。

参考资料

  1. ^ 本章节所说的“外语/外文”指除中文以外的语言。“文本”（包括第1条中所说“专有名词”）包括了单词、词组，偶尔也包括句子等。
  2. ^ 指直接作为标题且不含消歧义后缀
  3. ^ 注意一些常见于学术领域的日语人名可能更常以罗马化形式出现。
  4. ^ 一些情况下，某非使用拉丁字母的外文专名，其对应的拉丁化转写和英语名形式相同，即此种情况和上一种情况是同一拉丁字母文本。
首句《外语名称》格式指引
现行条文

如果条目主题名称与外语有较大关联，那么与其同义的外文名称可以出现于导言里，并通常被括号包住。例如，一篇讲述非中文语言的地方条目会把该地的本土语言所用的名称写进去：

切尔诺夫策州（乌克兰语：Чернівецька область，Chernivetska oblast）是乌克兰西南部的一个州……

如果有多于一个外语名称需要展示，那么在导言里把它们放在独立的句子，或者在主体正文增设一个诸如“名称”的章称，而不要写在开首的句子里。另外，不要把仅仅作为展示词源的外文名称写进导言内。

提议条文

通常来说，若条目标题词[1]为中文（或偶尔中外混杂）且对应外文[2]符合建立外文重定向的条件，那么建议将该外语名称在首句写出，并通常出现在标题词后的括号中；否则不建议标注外文名称。具体如下：

  1. 标题词有同义外文文本常常直接在中文语境使用（甚至可能比标题词本身更常用），通常为字母词（如CD指激光唱片）和英语词（如bug指程序错误）
  2. 标题词是专有名词（如人名、地名、作品名、公司名等）且译自外文或与外文有紧密联系，建议标注对应的外文，并注明语种[3]。例如地名：切尔诺夫策州（乌克兰语：Чернівецька область，Chernivetska oblast）是乌克兰西南部的一个州……
    • 若该外文文字不是拉丁字母，其对应的罗马化转写是否标注与如何标注——即直接标注在原文之后（如上“切尔诺夫策州”例）、在原文之后使用注脚、不标注在首句（仅在信息框标注）等——均无共识
    • 若该外语不是英语，且英语名在中文语境的出现率不明显低于原文名，社群对是否在首句同时标注英语名称没有共识
    • 若有多于一个外语名称需要标注（含上例情况），社群对是否均在首句标注及如何标注没有共识
    • 若标题词有别名且该别名亦出现外文名称，若不致混淆，语种名称可以省略
  3. 标题词与使用某种外语的文化有明确联系，建议标注对应的外文，并注明语种
    • 同上例：是否额外标注罗马化名称、英语名称，如何处理多于一个外语名称的情况，暂无共识；语种名称不致混淆时可省略
    • 若该外文文本仅是描述性的（多个单词的简单组合），例如“cinema of the United Kingdom”（英国电影），一般无需标注外语名称
  4. 若标题词是专科术语（例如出现在术语在线、乐词网等提供中英术语对照的网站，以及各类百科全书、专科辞典、专著、论文等），那么建议在标题词后标注对应英语，对译名不统一、不固定的术语而言尤为如此；除非该标题词相关领域的中文学术文献数远多于英语。由于学术研究通用英语，“英语”这一语种名称可以省略。极少数术语并非英语，则可视情况标注语种；对术语通用另一语言（如乐谱音乐术语通用意大利语）的相关内容是否以及如何标注语种有待达成共识
  5. 若标题词为生物物种（或属名等分类单元名）、药品等，可标注生物学名、国际非专利药品名称（INN）等外文规范名、通用名，一般无需标注语种
  6. 其他有必要标注外语名称的情况。标注者需在讨论页解释标注理由

不要把仅仅用作展示词源的外文名称等相关内容写进首句。例如“俄罗斯”一词译自蒙古语[4]，不要加注蒙古语名或介绍相关内容；例如“精神分裂症”的英语名称“schizophrenia”由希腊语词根“skhizein”和“phrēn”构成[5]，不要在首句介绍这一外文名称的词源；再如“通用语”的术语“lingua franca”（英）来自意大利语[5]，不要在该外文词前写上“意大利语”语种或介绍该词词源。

除首句外的条目正文，以及消歧义页标注外语名称的方式可参考首句格式手册的规定，在“提供必要信息”和“保持文本简洁、避免冗余”之间做出平衡。唯由编者自行翻译的专有名词必须标注外语原文（包括首句与其他部分。参见WP:原创译名）。（这一段加在《外语名称》章节最末）

参考资料

  1. ^ 本节“标题词”指第一个加粗的词或短语（偶尔也可能是句子），不一定和条目标题完全相同。
  2. ^ 本章节所说的“外语/外文”指除中文以外的语言。
  3. ^ 一些难以标注语种的专名（如“让·西贝柳斯”）可不标语种。
  4. ^ 黄河清. 近现代汉语辞源. 上海: 上海辞书出版社: 387. 2019. ISBN 978-7-5326-5403-1. 
  5. ^ 5.0 5.1 J. Pearsall; P. Hanks; C. Soanes. 新牛津英汉双解大词典. 由《新牛津英汉双解大词典》编辑出版委员会翻译. 上海: 上海外语教育出版社. 2007. ISBN 9787810802758. 
主要修订记录

第一次（2024年11月20日 (三) 05:43 (UTC)）、第二次（2024年11月20日 (三) 09:39 (UTC)）、第三次（2024年11月24日 (日) 16:42 (UTC)）、第四次（2024年11月25日 (一) 00:36 (UTC)）、第五次（2024年11月25日 (一) 16:26 (UTC)）

集中讨论区

邀请相关编者加入讨论@微肿头龙、MykolaHK、Kethyga、Ericliu1912：自由雨日🌧️❄️ 2024年11月19日 (二) 17:17 (UTC)[回复]

刚刚忘记签名了 囧rz……重ping@微肿头龙、MykolaHK、Kethyga、Ericliu1912：--自由雨日🌧️❄️ 2024年11月19日 (二) 17:19 (UTC)[回复]

lingua franca 的词源似乎是意大利语。enwikt, Longman, Collins, Merriam-Webster, Oxford ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月20日 (三) 03:46 (UTC)[回复]
！！好像确实！——自由雨日🌧️❄️ 2024年11月20日 (三) 05:43 (UTC)[回复]
其实有必要把“没有共识”也写进去吗。--微肿头龙（留言） 2024年11月20日 (三) 07:58 (UTC)[回复]
“没有共识”代表已经讨论过了，反映一种讨论状态吧。据我所知写进去情况蛮多的，比如NC:消歧义括号中的全角括号、NC:先到先得中的“可否在必要时使用脚注存在分歧”，以及英维en:WP:NLIST中的第三段首句，等等。--自由雨日🌧️❄️ 2024年11月20日 (三) 08:02 (UTC)[回复]
同意。而且如果没特别写，还真的会有人误会成完全没讨论过。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月28日 (四) 13:44 (UTC)[回复]
“由于学术研究通用英语，一般无需在英语名前标注“英语”这一语种名称，这也是大部分学术文献的标注方式”我对这个规定保留意见，因为很多条目都有标注“英语”，且个人觉得不标有点怪。如果其他编者认为没有问题我也不反对。条文的其余部分我觉得没问题。
另外，一些（相对）基础的学术词汇有必要建立英语重定向吗？比如Ethanol、Glucose、Gravity这种（话说Gravity可以改成平等消歧义吗）。激进一点，可以把Water重定向到水吗。我觉得这可能和各种形式的罗马化一样难以有共识，只能个案讨论了，不知道各位怎么看。--微肿头龙（留言） 2024年11月20日 (三) 09:05 (UTC)[回复]
同样，也有很多条目并未标注“英语”语种，且绝大部分学术文献、工具书，以及教科书（中国大陆）是从来不标“英语”这个语种名的，个人觉得标注“英语”反而很怪以及冗余。基础的学术词汇，我认为只要是常见于术语表、工具书、教科书的，就应该创建（至少是“可以”创建）。刚刚翻了下中国大陆人教版高中《化学》，它甚至是特意空出侧边栏用来强调文中的英语名称的，比如“乙烯 ethene ／ 加成反应 addition reaction”等等。“water”我不确定有没有必要……如果创建的话，这就很接近“词典”性质而不是“百科”性质了，但它也确实可以视作学术词汇，只是正好和语文性词汇一样（两岸术语网站的情况是，术语在线没有，但乐词网有不少）；但如果建个“country”消歧义页说有“国家”和“乡村”两个义项，这就完全不行了，因为这是英汉词典内容。“gravity”等外语词如何消歧义的话，我觉得理想状态是看这个词在中文语境如何使用，更常指代什么（出现在教科书、学术文献等的括号标注中也属于使用）。--自由雨日🌧️❄️ 2024年11月20日 (三) 10:06 (UTC)[回复]
外文重定向：
1:内容有些长。
2:“罗马化转写文本”不准确，比如阿拉伯字母、斯拉夫罗马化转写方案有多种，有不少与常见的、以拉丁字母表示的名称不同。
3、“若罗马化转写形式不止一种，社群对“是否应创建所有形式的罗马化文本”未有共识”，那这个提案中涉及罗马化的部分似乎就失去意义了。
4、“建议创建专科术语的英语名重定向”与“方可创建外文重定向”的精神不符，没必要是专科术语就要去创建英语重定向。
首句《外语名称》格式指引：
由于学术研究通用英语，一般无需在英语名前标注“英语”这一语种名称，首次出现不标注语言名称恐与维基上现行实践不符。学术文献是默认现行的外文多用英语。
提案还未讨论就写“没有共识”，同 微肿头龙。--Kethyga（留言） 2024年11月21日 (四) 01:57 (UTC)[回复]
外文重定向：
  1. 虽然长，但确实总结下来的共识和讨论结果有这些……
  2. 确实不同啊。常见的拉丁字母文本是英语名，这里是要允许建立原文名罗马化
  3. 为什么失去意义？差不多就是，“可以建”，但并未完全鼓励编者全部建（即只鼓励建最通用的罗马化方案）
  4. 个人是希望“建议”的。因为我真的遇到大量明明在中文可靠文献（甚至是术语在线等）出现的学术词汇，明明在中维有条目但却搜不到，需要先去英维搜再通过跨语言链接转到中维的。中文学术译名真的很混乱
外文名称：
至少“需要标注”也与实践不符，因为有大量不标的（甚至有些专有名词等情况也未标语种，这我觉得不太好——但其实也不是不行，甚至大部分可靠来源也是不标的）。就像我几个月前提出“非专有名词无需大写”时，也有大量实践不符（现在也是），错误地大写非专有名词的情况甚至多于不大写情况。当然这里标注“英语”语种并非错误，只是我觉得冗余。
@Kethyga、微肿头龙：似乎无人加入讨论。那这里就我们来讨论下面几个问题：
  • 学科术语是否需要标注“英语”语种？我个人是强烈偏好不标的。绝大部分文献甚至对专有名词都一般不标语种而是直接给出原文，但是中维一般是标语种（也有不标的），对学科术语我就更没见过标语种的了。我认为标出“英语”两字几乎没有明显的好处，因为读者几乎不可能将这一单词误认为是其他语言——甚至这一单词是什么语言都不重要，它只是代表这一文本是国际通用学术词汇。当然，若两位认为应当标注，我可以接受将条文改为由于学术研究通用英语，一般无需在英语名前标注“英语”这一语种名称可以省略，以给编者更大的自由度。
  • 对任何条文中“无共识”的部分，都可以继续讨论，看看是否可以得出共识。——自由雨日🌧️❄️ 2024年11月24日 (日) 13:07 (UTC)[回复]
  • 其实看术语在线也会写“英文”，乐词网也写“English Terms”。我觉得一般的资料不标是因为通常这些资料都是面向特定领域的读者，而学术领域都默认英语为“唯一外语”。但维基百科作为一个综合性的百科全书覆盖了很多范围的主题，我认为标注语种会更好，也尽可能避免英语中心主义。而且就在首句多了两个字即不会占太多空间，也没有特别碍眼。如果说术语可以不标英语，也可能会延伸到其他领域可否也不标语种的问题。比如条文里的切尔诺夫策州否可以略掉“乌克兰语”三个字？毕竟乌克兰地名的条目想当然首句出现的外语肯定是乌克兰语，额外标注也显得很多余（语言名和国名不一样可能还是需要标出来）。不过，我也可以接受让编者自由决定（另外如果觉得有必要的话也可以写上“如果出现两个或以上语种时必须标注语种”之类字句）。
  • 现在暂时想不到什么可以讨论的，先放着吧。
--微肿头龙（留言） 2024年11月24日 (日) 16:28 (UTC)[回复]
术语在线和乐词网那是表格，不是文段，不一样（表格总得有个“表头”，没有也得有个出来）；就像《中国大百科全书》网络版在信息框内会写上“英语”，但正式出版的纸质版就没有“英语”两字。另外“英语中心主义”完全不属于《WP:地域中心》等违反中立的现象。国际上通用的学术语言是英语（以及大部分工具书和学术文献在文段中不标“英语”语种），这是既定事实，反映这一事实并不是“不中立”；就像“敎”字在现代汉语是罕用异体字，中文维基百科应使用通用字形“教”，这并不是“‘教’字中心主义”一样（或者一个更类似的例子是“公元”纪年通常无需写出“公元”两字）。如果“不标英语语种名是不中立”的话，那我也可以继续上纲上线说“只写英语名而不写俄语日语名等”也是不中立……至于“一般资料是因为面向特定领域的读者”不标，我想那也是不成立的，因为中小学教材显然是最典型的无差别面向全体同学的教材，但我从未见过任何一本科学/物理/化学/生物教材在文段内标注“英语”语种名的（至少中国大陆教材从不标）。至于“乌克兰语”是否可以省略，其实我并不完全反对省略（就像我说的，不少工具书也是省略的），只是觉得中维大部分条目有标注+专有名词语言复杂多样，不如统一要求标注。不过既然学术名词是否标“英语”有争议，我改成“可以省略”吧。——自由雨日🌧️❄️ 2024年11月24日 (日) 16:42 (UTC)[回复]
“两个以上语种必须标”，目前好像不是很有必要，因为这一般只会发生在专有名词，而目前专有名词是本就要求一般标语种的。--自由雨日🌧️❄️ 2024年11月24日 (日) 17:16 (UTC)[回复]
有些概念最早起源于非英语国家，因此非英语的外语术语也可能会有一定的使用场景。--微肿头龙（留言） 2024年11月25日 (一) 00:02 (UTC)[回复]
嗯？难道“relativity（相对论）”的德语有广泛使用场景？学术的通用语是什么语言和概念的起源地有关吗？--自由雨日🌧️❄️ 2024年11月25日 (一) 00:14 (UTC)[回复]
我只是说可能，并不一定都是如此。比如军事术语闪电战显然德语更常用，英语也直接搬德语而不采用英语化的单词。又如前几年普大帝创造的术语特别军事行动，中文使用者显然会有更高的概率知晓其英语称呼，但不写其俄语称呼显然不妥。--微肿头龙（留言） 2024年11月25日 (一) 00:35 (UTC)[回复]
“闪电战”感觉不太算典型术语，不过要算也可以算吧——但“英语也直接搬德语而不采用英语化的单词”，反而（比普通学术词汇）更可以直接写成（blitzkrieg）而不写德语或英语，这个括号就表示“这个术语的国际通用形式是blitzkrieg”（无需在意它是什么语种，我前面说一般不用标“英语”也有这层含义，此外也和“生物学名无需标‘拉丁语’语种名”差不多）。至于“特别军事行动”，这个其实我语感上就是个专有名词而不是术语，如果看成术语那就是更加不典型的术语了，这种情况确实是要标语种。--自由雨日🌧️❄️ 2024年11月25日 (一) 00:49 (UTC)[回复]
但是英德正字法不同啊，德语的话B要大写，英语看英维没有用大写。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月25日 (一) 02:49 (UTC)[回复]
这样的话，我有点怀疑微肿头龙说的“德语更常用”是否属实了，很可能是英语更常用。--自由雨日🌧️❄️ 2024年11月25日 (一) 02:57 (UTC)[回复]
但是英维标题用了意大利体啊。不过内文也是罗马体意大利体混用，大小写混用，加不加引号混用…… ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月25日 (一) 03:01 (UTC)[回复]
英维又不是可靠来源 ——自由雨日🌧️❄️ 2024年11月25日 (一) 03:03 (UTC)[回复]
看！ ——自由雨日🌧️❄️ 2024年11月25日 (一) 03:04 (UTC)😮1 [回复]
因为我不觉得这种100％照搬外语拼写的单词是典型的英语单词。英语单词应为Lightning war（术语在线用的是这个）。如同nomen nudum我也难以认定他是英语单词（但术语在线把它和naked name都称作英语。。）。--微肿头龙（留言） 2024年11月25日 (一) 03:30 (UTC)[回复]
英语本来就只有不到30%词汇是本族语，其他都是外来词啊。anyway，我觉得没必要追究它到底是什么语种，“语种”有争议，反而恰恰更支持“不用标出语种”的做法。--自由雨日🌧️❄️ 2024年11月25日 (一) 03:56 (UTC)[回复]
如果不确定语种的话，也没法注lang属性了？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 20:32 (UTC)[回复]
那就不注呗。说实话，看了“肯定前件”目前的显示效果之后，我甚至倾向这类非英语的术语也不一定需要注语种……首先是不美观，其次追究通用术语是什么语种更偏向词典内容，就像词源是词典内容一样（当然也不纯粹是语文性内容，否则像“‘俄罗斯’译自蒙古语”之类的内容就完全不应在正文任何章节出现了）；不过专有名词目前还是倾向标注。--自由雨日🌧️❄️ 2024年11月28日 (四) 20:44 (UTC)[回复]
注不注“拉丁语”也就四个字符宽度的差别，如果是“英语”也就只有三个，我觉得差不了多少。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 20:49 (UTC)[回复]
写成下面那种六角括号形式我觉得就美观很多（但应该完全不是本站的体例），可能我传统工具书看习惯了（）--自由雨日🌧️❄️ 2024年11月28日 (四) 20:51 (UTC)[回复]
冒号格式是不是也是搬英维的？不是不能改成六角括号。在逻辑中，肯定前件（〔拉丁语〕modus ponens）是有效的、简单的论证形式。顿涅茨克人民共和国（〔俄语〕Донецкая Народная Республика，罗马化：Donetskaya Narodnaya Respublika，缩写：ДНР / DNR；或按英语缩写为“DPR”[注 1]）是俄罗斯联邦在东欧事实上的联邦主体。俄占扎波罗热州（〔俄语〕Российская оккупация Запорожской области，〔乌克兰语〕Російська окупація Запорізької області），是从2022年2月24日俄罗斯入侵乌克兰第一天开始在扎波罗热州的军事占领地区。确实看起来可以。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 20:59 (UTC)[回复]
“语”字完全可以省略？“罗马化”那个小字加冒号显示方式我也一直觉得非常奇怪，不过暂时没想到怎么表示最好。--自由雨日🌧️❄️ 2024年11月28日 (四) 21:01 (UTC)[回复]
我觉得通常可以。但是世界语、美国英语、近代英语、简单英语、塞尔维亚-克罗地亚语这些特殊的语言省略“语”字会不会反倒不通或者有歧义？另外我还担心，比较罕见的语言如，伊多语（〔伊多〕Ido），沃拉普克语（〔沃拉普克〕Volapük），不知道体例的读者会不会不清楚是什么意思？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 21:12 (UTC)[回复]
而且语字是否应该隐藏？依靠屏幕阅读器的视障读者大概没办法知道这是个六角括号。比如〔[[伊多语|伊多<span style="display:none;user-select:none">语</span>]]〕。屏幕阅读器能读出user-select:none的文本吗？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 21:19 (UTC)[回复]
“user-select”是什么意思？思考...“语”字不读出也不影响理解吧？（或者说书面上省略不影响理解的，读出也不影响） ——自由雨日🌧️❄️ 2024年11月28日 (四) 21:35 (UTC)[回复]
这些或者写全称，或者简写（当然尽量不要自己发明简写，找其他工具书或论文常用的简写）然后加{{tooltip}}？--自由雨日🌧️❄️ 2024年11月28日 (四) 21:33 (UTC)[回复]
不用六角括号包裹的语种名总有种“成为正文、喧宾夺主”的感觉；语种应当仅是对外文单词的附加说明。--自由雨日🌧️❄️ 2024年11月28日 (四) 20:55 (UTC)[回复]
确实，不过括号内本身也不是正文。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 21:21 (UTC)[回复]
不对，但如果这样说，括号内标注“学名：”“INN：”甚至是“简称”“俗称”“缩写”是不是也会“喧宾夺主”？是不是也应该发明一种括号将之括起来呢？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 21:27 (UTC)[回复]
这不喧宾夺主啊。看下例，“学名/简称”之类的是对名称本身的注释，所以直接放括号里天经地义，但语种名是对外文的注释，它本身应该是个“二级括号”。--自由雨日🌧️❄️ 2024年11月28日 (四) 21:37 (UTC)[回复]
就像“切尔诺夫策州”例本身的逻辑应该是切尔诺夫策州（原文：〔乌克兰〕Чернівецька область），只不过一般把“原文”（即相当于“学名/简称”等的词）两字省略罢了。--自由雨日🌧️❄️ 2024年11月28日 (四) 21:48 (UTC)[回复]
另外缩写，如果是通常只在外语语境使用的缩写，那是对外文的注释（也类似“二级括号”），但我觉得这类缩写不应该标注，应当只标注“DNA”这种中文语境也常用的缩写，那显然就不是“二级注释”了，相当于是“脱氧核糖核酸”的“缩写”，所以“缩写：DNA”不必加“二级括号”。--自由雨日🌧️❄️ 2024年11月28日 (四) 21:50 (UTC)[回复]
很绕但可以理解。我大概写过“原文：英文：Foobar”之类的东西。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 23:15 (UTC)[回复]
严重违反冒号使用规范！--自由雨日🌧️❄️ 2024年11月28日 (四) 23:27 (UTC)[回复]
还有您似乎偏好加内链？这就更过分！（）注明语种本身已经不完全必要，还要直接在标题词后面链接至语种条目？（绝大部分条目和拉丁语/意大利语等语言本身根本没有关系。）我觉得只有“伊多语”之类的一般读者没听说过的语言需要加内链吧？--自由雨日🌧️❄️ 2024年11月28日 (四) 21:41 (UTC)[回复]
加内链并不会影响什么啊？目前似乎只有英语不加内链。“伊多语：”只有可能在伊多语条目出现，所以也不会加内链。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月28日 (四) 23:14 (UTC)[回复]
内部链接显然会驱赶读者，就像经济学条目拿马铃薯举例不应将内链加到马铃薯上一样，“拉丁语”之类的属于大部分读者都了解的语言。“伊多语”等罕见语言还可以在伊多民族特色事物中出现的（没点进去看，居然是人造语言……不过可以拿别的小语种来举例，道理一样）。--自由雨日🌧️❄️ 2024年11月28日 (四) 23:25 (UTC)[回复]
说到加内链的问题，本站目前的lang-xx系列模板对大语种不添加内链（英、法、俄等），而小语种则几乎全部自带内链，如果不想链接需用参数控制。我是觉得这样怪怪的，要么就全加要么全都不加。比如上述提及的俄占扎波罗热州，俄语没加内链，乌克兰语却有。（注：这里的大小语种并非依据使用人口划分，具体多少个语种没有被添加内链我也不清楚）--微肿头龙（留言） 2024年11月29日 (五) 03:50 (UTC)[回复]
其实我认为术语不必注语种的逻辑和“学名”“药品名”不必注语种的逻辑一样，可以看作是，如果完全写全，实际上它们是：精神分裂症（术语：〔英〕schizophrenia）、狼（学名：〔拉丁〕Canis lupus）、氟西汀（INN：〔英〕fluoxetine）。学名和药品名语种并不重要，所以省略；术语语种也同样的逻辑省略，最后再省去“术语”两字。--自由雨日🌧️❄️ 2024年11月28日 (四) 20:50 (UTC)[回复]
肯定前件（拉丁语：modus ponens）、跳弓（英语：spiccato）（意大利语：spiccato），虽然英语也是这样拼，但是英维用的是意大利体，大概不是真正的英文？另外括号里面也有可能是其他乱七八糟的东西，比如BWV Anh.114，或者Jean Sibelius这种没法标语言的名字。当然这些不是术语，不过是否会混淆？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月25日 (一) 02:48 (UTC)[回复]
“肯定前件”不算典型术语，至于标不标语种我认为都行（我倾向标，或者说，我倾向“英语默认不标，其他标”，类似“公元”的处理）；“跳弓”之类的音乐术语我觉得应该所有音乐术语特别处理，我倾向是不用标语种，作品号同（我对目前音乐作品条目的格式颇有意见）；Jean Sibelius应该不标即可。--自由雨日🌧️❄️ 2024年11月25日 (一) 03:00 (UTC)[回复]
已在条文写入上述讨论内容。——自由雨日🌧️❄️ 2024年11月25日 (一) 16:26 (UTC)[回复]
( π )题外话：不知道马来西亚怎么样，在中国大陆，绝大部分公共建筑上的中文（比如路牌、站牌、公共交通指示牌等等）全都会附带英文，而且从不标“英语”两个字 ——自由雨日🌧️❄️ 2024年11月24日 (日) 17:43 (UTC)[回复]
不能类比。标识牌没有默认语言，各种语言是面向其使用者的，只要有人看懂就行。中文维基百科面向中文读者，外文也是给中文使用者看的。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月24日 (日) 17:52 (UTC)[回复]
就“工具书能否起到提供必要信息”作用来说，不标“英语”几乎不会有负面作用，纯粹是告诉查阅的读者括注里的名称是学术通用词汇——而且，就像不写“公元”两字的年份通常默认是公元纪年，我不相信不写语种读者会疑惑那是什么语言。当然，或许可以设置《凡例》页面，告诉读者某些分类（学术研究涉及的自然科学类、社会科学类等）下的标题词后均括注英语名称（本来工具书的绝大部分格式、符号等内容就应该写进凡例而不是在每个条目里都用各种方式提供给读者）。此外还有一个问题就是，很多缩写（字母词）源于但已不被部分中文学者视作纯英语（如DNA等，直接收录进了《现代汉语词典》；当然专有名词也有可能存在这种现象）。--自由雨日🌧️❄️ 2024年11月24日 (日) 18:00 (UTC)[回复]
马来西亚的路牌一般只会写马来语，或只写英语。两个语言都写是很少的情况。假设有条路叫Jalan Rosa（Rosa Road），那只会写Jalan Rosa或Jln. Rosa，哪怕用英语交流时提到这条路也会用Jalan Rosa而不刻意念Rosa Road（相当于某些大陆路牌里的XX Lu）--微肿头龙（留言） 2024年11月24日 (日) 23:57 (UTC)[回复]
一个细枝末节的问题：如果省略“英文”的话会不会不好看出哪些外文没被lang包裹，还是说有什么界面小工具可以用一下。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月24日 (日) 17:01 (UTC)[回复]
不省略也有很多没有被包裹啊😂（即源代码是直接的英语：XXX） ——自由雨日🌧️❄️ 2024年11月24日 (日) 17:03 (UTC)[回复]
还有这种事？红温了😡 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月24日 (日) 17:05 (UTC)[回复]
另外，我两个方针指引都藏在注脚里的“描述性短语——如cinema of the United Kingdom（英国电影）——是否可建重定向/标注外文没有共识”（不知道你们有没有注意到😂）怎么看？我个人其实是倾向于不允许建重定向/不标注外文名称的。--自由雨日🌧️❄️ 2024年11月24日 (日) 21:49 (UTC)[回复]
我觉得不应该建重定向，但语种可视情况决定是否标上。如果文本语境显然无必要可以不标。--微肿头龙（留言） 2024年11月25日 (一) 00:17 (UTC)[回复]
“语种”是指“标注外语名称”吧（主要前面说到“语种”都是指“英语”“俄语”这几个字本身）？据我观察这类重定向有，外语名称也有而且很多（所以我才说“无共识”，不然可能会想要求尽量限制。当然如果这里讨论认为可以限制那我就要改条文成限制了。--自由雨日🌧️❄️ 2024年11月25日 (一) 00:21 (UTC)[回复]
不好意思，我会错了意。但观点不变：可视具体情况决定是否放入外文。如果写如外文是更好的则要写入，没必要的则省去。--微肿头龙（留言） 2024年11月25日 (一) 00:32 (UTC)[回复]
好的，那我先改成限制了。——自由雨日🌧️❄️ 2024年11月25日 (一) 00:36 (UTC)[回复]
如果是INN药物名的话，标注“INN：XX”是否好过标注“英语：XX”或不标？我目前就是标前者。这些药名实在很难称作是（典型的）英语单词。--微肿头龙（留言） 2024年11月25日 (一) 00:13 (UTC)[回复]
(＋)支持写INN：XX，就像生物学名写学名：XX（一般用模板实现）而不是拉丁语：XX一样。--自由雨日🌧️❄️ 2024年11月25日 (一) 00:15 (UTC)[回复]
或许可以提出，若某名称来自学术界专有规范（如学名、药名等），则可照样标注。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月25日 (一) 06:44 (UTC)[回复]
生物学名之前已经有提出了。药名似乎可以附在生物学名后面，已写入。——自由雨日🌧️❄️ 2024年11月25日 (一) 16:26 (UTC)[回复]

我想探讨“原则上不允许建立带消歧义后缀的外文重新导向。”这句话的适切性。虽然说是长期习惯，但不少编者在从外语百科翻译条目时书目都是直接照搬，如果该书目的原始条目带有消歧义后缀，则会因为此规定无法清除。打个比方来说，我在十个月前请机器人清理Polygon (website)这个与英文百科同名的连结，十个月后又有好几个条目使用，这个也是，但类似状况太多我无法每隔一段时间就回来请人处理，要建立机器人定期清理也不符合成本效益，若无其他特别考量，希望新版指引可以删除这句话，谢谢。--回廊彼端（留言） 2024年12月5日 (四) 13:39 (UTC)[回复]

同意，此种情况应有特别之适当豁免。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月5日 (四) 22:18 (UTC)[回复]
我个人是希望仍保持不允许的。翻译外语维百时各式各样的问题很多，如标点使用不当、大小写使用不当、照搬模板参数导致不对应等等，这些都属于错误，应该由中维编者修正，而不是为了适应这种错误去开放建立重定向……（这和“错字重定向”不一样，“错字重定向”是已经有不少可靠来源误用某一名称，但这里是编者自己在站内在翻译时的错误。）另邀请@微肿头龙讨论： ——自由雨日🌧️❄️ 2024年12月6日 (五) 14:09 (UTC)[回复]
个人也倾向不允许创建。如果允许创建就约等于认可了所有英维（或其他语言）标题都是可以创建的，毕竟难以有个客观的标准判断哪些是可以豁免的。那干脆不要限制重定向的建立算了。--微肿头龙（留言） 2024年12月6日 (五) 15:50 (UTC)[回复]

傀儡方针新增“被容许使用多重账号的行为”的情况（教育专案）

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:傀儡。

留意到某大学的学生课程作业要求他们编辑条目，之后有管理员就此发起了傀儡调查，并封禁了相关账号（详见傀儡调查页、用户讨论页）。我要说的是，这是学生的课程作业，学生们连接到学校公网（IP地址当然相同）进行编辑，而每个学生都注册有属于各自的账号，编辑范围已经很局限，根本就不是傀儡的行为，属于“被容许使用多重账号的行为”的情况。

关于这个问题我之前就在英文维基的傀儡方针看到过，即“教育专案”的例外情况。以下是方针条文：

Educators and students are encouraged to create a separate account that does not have to be linked to their main account for the purpose of managing or participating in student assignments. Use of the account should be limited to articles and other pages directly related to students and classwork.

之前我提出修订中维傀儡方针的时候并没有考虑引入此方针，主要原因是当时的条件不成熟。但这次的傀儡调查反映出中维傀儡方针没有对应内容支持这一点。在此我提出提案（之前我没有修订的计划，这次对我来说算是“紧急提案”），就是在傀儡方针新增“被容许使用多重账号的行为”的情况（拟定该情况为“教育专案”）。拟提议的条文如下：

我们鼓励教师和学生创建一个单独的账户，该账户不必与主账户关联，以便管理或参与学生作业。账户的使用应仅限于与学生和课堂作业直接相关的条目和其他页面。如用户发现有将举行或已举行的教育专案，可以在教育专案布告板上报告。

欢迎各位编辑参与讨论，尤其是我之前与@D2513850、Tisscherry、SCP-2000：讨论过的用户可以作进一步探讨。--Shwangtianyuan 不忘初心 牢记使命 2024年11月24日 (日) 13:54 (UTC)[回复]

鼓励的前后要有但书吧，注册一堆账号的要怎么办、留哪个、如何确认谁要确认、不肯表明学校的呢怎么处理？学校不主动通知，要让社群忙和确认，发现的时候问问题都不回。现在的状况看来几乎都是，号称老师叫他们来，但老师根本没出现过，学生们自己建账号，内容可能侵权，被傀儡调查了封了，他们要写作业这样就写完了吗？最近暨大的就很可疑，600字的内容可以交作业、都侵权被删光了怎么交，声称自己是同学，但巧妙的会避开对方的编辑，说难听的管理员已经在未经确认放行解封、不能至少在上班日电联或写信确认有无此课程（不是要确认学生或老师身份）后再解吗，就我所知的有其他学校破坏的，若注意到就可以声称使用了。--提斯切里（留言） 2024年11月25日 (一) 01:41 (UTC)[回复]
至少应该要求台湾的教育专案负责人联络台湾分会确认情况，逾期没有确认还是按正常流程。目前一般也只有台湾有这样的专案吧？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月25日 (一) 03:05 (UTC)[回复]
台湾分会也不预设“管辖”教育专案，至多予以建议吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月25日 (一) 06:46 (UTC)[回复]
或者联络VRT？就是不知道处理效率如何（ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月25日 (一) 06:48 (UTC)[回复]
你要如何让学校“知道”要主动通知？台湾分会发公文到全台湾共计155所大学吗？大学接到后会确实发给所有老师吗？还是要进一步发到上千的系所中？问问题都不回也很正常，你知道有些人在我们发出得奖通知后不断有登入及贡献，三年后才发现有“User talk”页面并写信来问还能不能拿奖品吗？维基的 UX 本来就不是多么一流的水准，现在还在持续改进中。
不要把大家都当成资深维基人。--Reke（留言） 2024年11月29日 (五) 06:03 (UTC)[回复]
这就是为什么应该要推广教育专案布告板，方便教师提前通知社群以避免误会。副知@Reke。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月25日 (一) 02:57 (UTC)[回复]
请他们打电话或寄E-mail给协会都很困难了，用布告板就更难了。--Reke（留言） 2024年11月29日 (五) 05:43 (UTC)[回复]
@Reke：或者就是“亡羊补牢”，封锁或警告账号的时候予以提醒之类。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月3日 (二) 12:29 (UTC)[回复]
其实由资深的人来通报协会，尽可能抽丝剥茧去查出课程然后联络老师比较有用。--Reke（留言） 2024年12月5日 (四) 17:09 (UTC)[回复]
英维这个方针指的应该是，为了统计或管理上的方便，即使我本来都用Reke这个账号，但在某个课程被要求要编维基当作业时，注册一个“OOO课程学生Reke”的傀儡，只用于编写这个课程的作业。引入这条规范对现在中文维基最常遇到的样态不同，学生通常是直接注册一个普通的个人账号，而被认定是技术上的傀儡，其实是因为这个行为往往可能在小组讨论或课堂上发生，共用机器与网络非常普遍。
我个人认为中文维基的傀儡调查本身不够精细才是问题的根源。--Reke（留言） 2024年11月29日 (五) 05:53 (UTC)[回复]
其实为什么要“编维基当作业”呢？--派翠可夫 (留言按此) 2024年11月29日 (五) 17:10 (UTC)[回复]
这你没法阻止啊。我相信OSM中国的朋友早就有相同的疑惑了。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月29日 (五) 19:00 (UTC)[回复]
有点离题，但编辑维基当作业有几个好处：
  1. 没办法抄维基去交作业。
  2. 学习成果可以转化为维基的内容跟别人共享。
--Reke（留言） 2024年12月5日 (四) 17:07 (UTC)[回复]
无论具体情况如何，此修订案可适当补充傀儡方针规定，实属合理，本人予以支持。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月3日 (二) 12:29 (UTC)[回复]
而每个学生都注册有属于各自的账号，编辑范围已经很局限，根本就不是傀儡的行为，属于“被容许使用多重账号的行为”的情况。这不是什么“被容许使用多重账号的行为的情况”，这根本就不属于“使用多重账号”。--dringsim 2024年12月3日 (二) 12:44 (UTC)[回复]
这段条文实际上针对的是（出于隐私原因）不愿公开主账号和（已与课程任务相关联的）教学专用账号之间关系的情况（讨论见en:Wikipedia talk:Sockpuppetry/Archive 15#Make it clear students are allowed to create alternate accounts for their Wiki Ed courses）。和共用IP/设备没有关系（没有课程任务时也会发生）。--dringsim 2024年12月3日 (二) 12:50 (UTC)[回复]

将WP:格式手册所有方针与论述移动到MOS命名空间，并将MOS命名空间更名为“格式手册”

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:命名空间。

因为此案涉及到方针指引的移动，故不放在技术区，放在方针区
前言

见前次讨论，已有初步共识，不过当时有意见认为需近一步讨论，也因 此案涉及到方针指引的移动故需要在方针区确认共识或进一步讨论。

方针/指引的部分即：

技术细节：

  • 将MOS更名为“格式手册”，即：
  • 编辑以下页面：
在这些界面设定页面中
中填入格式手册或格式手冊
正文

见前次讨论，因为MOS语言维基百科的创立，因此本站设立的MOS捷径得以因此技术原因phab:T363538，被升格为命名空间。当时的讨论主流共识认为，既然都有名字空间了，不如把对应页面都(►)移动进去。

我现在的想法是，既然基金会都升格MOS为正式命名空间了，我们不使用实在浪费。且届时上述更名技术操作全部完成后，移动到下面的页面如维基百科:格式手册/避免自我提及将会直接显示为“格式手册:避免自我提及”同当时“维基百科:XX专题”变为“专题:XX”的好处。

提及上次“关于本命名空间”之讨论参与者@S8321414、SunAfterRain、魔琴：欢迎再次发表意见。

计划时程
  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)[回复]

(※)注意，这次与专题的命名空间有不同，基金会设立专题空间时有把全写“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)[回复]
  • @Cdip150：我上面写的计划时程“2.[技术] 技术调整”就是已经包含去phab申请“命名空间别名”、子页面等东西啊。这东西没有本地共识是要怎么申请？？？我在方针区提，而不是在技术区题就是为了这个啊。你的那些问题都会在本地共识有了之后，提请phab修改啊，那样不就都解决了？你变成直接这样提，那，从哪来本地共识？？ 没有本地共识要怎么申请phab工单解决你的问题？？？？ 拜托不要制造套娃问题好吗？ 拜托不要制造递回/循环问题好吗？-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年12月4日 (三) 13:52 (UTC)[回复]
  • (※)注意：@Cdip150：“基金会设立专题空间时有把全写“WikiProject:”和缩写“PJ:”纳入作为可用的前缀”，“基金会”？ 不好意思，那段程式码我写的，谢谢，提案也是我提的，所以根本不是“基金会设立有纳入”，而是“本地共识为需要纳入”，然后我写程式给phab，他们布到正式机而已。所以“基金会设立有纳入”，错，是“本地社群共识设立有纳入”谢谢。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年12月4日 (三) 14:07 (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)[回复]
不反对此提议，另外也不反对上面提到的为命名常规与关注度指引单设命名空间的提议。Sanmosa 新朝雅政 2024年12月4日 (三) 14:28 (UTC)[回复]
(－)反对拆分：格式手册页面本寥寥无几，且性质未全然有别于其他方针与指引，不若维基专题而难成独立体系，实无必要特别自计划命名空间划出。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月5日 (四) 10:11 (UTC)[回复]
然而现在的情况是MOS因为其他缘故（而非中文维基百科的请求）而已经成为一个独立的命名空间了，这独立的命名空间也不好空着。Sanmosa 新朝雅政 2024年12月5日 (四) 12:27 (UTC)[回复]

应根据WP:用户页对WP:用户框进行修订

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:用户页、Wikipedia talk:用户框。

从范围上来看，用户框是用户页的子集。用户框的内容也应受到WP:UPNOT的限制。想起这一点是因为近日又有新用户（Carl66066）连续建立多个在我看来并不合适的用户框。以该用户此前的用户页为例：

  • 视觉效果十分糟糕：颜色搭配不当，背景颜色和文字颜色接近，文本框宽度参差不一；
  • 反复宣告自己的观点：使用大量文本详细描述自己的观点，而这些观点基本上与维基媒体运动及社群协作毫无关联；
  • 名称不明确：模板名称与文本内容不相符，或存在歧义。

由于类似的编辑者以往也存在，我认为有必要按照WP:UP修订WP:UBX，把Template:Subcat guideline-en从WP:UBX移掉，对目前的用户框进行整理，将文本内容过于注重表达个人意见的改为中性的陈述或简单的宣告，无可救药的模板批量送存废。——暁月凛奈 (留言) 2024年12月4日 (三) 15:19 (UTC)[回复]

(＋)支持。另外除了根据中维的《WP:用户页》修订之外，也可以根据目前英维的en:WP:Userboxes修订？因为似乎中维的版本有些落后了…… ——自由雨日🌧️❄️ 2024年12月4日 (三) 15:27 (UTC)[回复]
您想给的链接应该是打错了，我改了一下。(～)补充一点：我认为应该在WP:UBX中建议用户把理论上不会有其他人用的内容用Template:Userbox表达出来而不是新建一个页面。——暁月凛奈 (留言) 2024年12月4日 (三) 15:40 (UTC)[回复]
感觉很有必要！(＋)支持 ——自由雨日🌧️❄️ 2024年12月4日 (三) 15:42 (UTC)[回复]
我觉得Wikipedia:用户框要为编辑条目服务这篇论述写得很有道理，或可用于参考。——敬颂冬绥 ZhaoFJx(论•签) 2024年12月4日 (三) 16:26 (UTC)[回复]
如果是新增字数限制又及引入WP:避嫌又如何？
使用大量文本详细描述自己的观点—>以字数限制形式限制不要详述限制
反复宣告自己的观点—>若挂上相关立场鲜明的方块，即视为该编辑者会戴有色眼镜看待或编辑相关条目，基于WP:中立应予以禁止编辑相关条目--唔好阻住我爱国（留言） 2024年12月4日 (三) 18:26 (UTC)[回复]
您是说……例如A声明是某学校的学生或校友，出于利益冲突和可能不中立，不应该允许其编辑学校条目中关于排名的内容？
我建议如果某编者讨厌特定主题，除非TA表现出明显的POV并经确认，才可由管理员执行编辑禁制。否则，不赞成单凭用户页的用户框而预防性禁制。——敬颂冬绥 ZhaoFJx(论•签) 2024年12月4日 (三) 18:35 (UTC)[回复]
声明学生或校友没有问题，问题是声明自己是“讨厌/仇恨/热爱”那所学校的。当加上预设立场或形容词时，应考虑那个人是否可以不戴有色眼镜编辑那所学校的条目。--唔好阻住我爱国（留言） 2024年12月5日 (四) 01:20 (UTC)[回复]
那是不是应该禁制您编辑和中华人民共和国（含香港）有关的所有条目 ——自由雨日🌧️❄️ 2024年12月5日 (四) 01:24 (UTC)[回复]
你看到我的签名有说爱哪个国家吗🤣--唔好阻住我爱国（留言） 2024年12月5日 (四) 01:34 (UTC)[回复]
我觉得他并不是只看你的签名来下定论的。Sanmosa 新朝雅政 2024年12月5日 (四) 01:37 (UTC)[回复]
您从用户名到签名到用户页都“说”了啊🤣总不可能用户名是“香港我爱你一生一世”但签名是爱美国…… ——自由雨日🌧️❄️ 2024年12月5日 (四) 01:38 (UTC)[回复]
有没有想过520是粤语“唔要你”（不要你）？--唔好阻住我爱国（留言） 2024年12月5日 (四) 01:41 (UTC)[回复]
那就读不通了………而且也和您用户页和签名不吻合。--自由雨日🌧️❄️ 2024年12月5日 (四) 01:43 (UTC)[回复]
例如今日A君挂上“支持尹锡悦颁布戒严令”，B君挂上“支持尹锡悦颁布戒严令，抵抗朝鲜邪恶势力”
个人认为应该禁止B君那类方块。--唔好阻住我爱国（留言） 2024年12月5日 (四) 01:39 (UTC)[回复]
是这样的意思。B版并不合适。——暁月凛奈 (留言) 2024年12月5日 (四) 05:22 (UTC)[回复]
用能让有常识的人理解的话语写成指引比愚蠢的官僚式限制有用无数倍。比起把时间浪费在标准上，告诉用户这样做的原因、后果即可，有常识的人应当能作出合理的判断。
不合理到我甚至一时想不出如何用简单的语言表达。——暁月凛奈 (留言) 2024年12月4日 (三) 19:37 (UTC)[回复]
将《避嫌》《中立》方针用于用户页，就像将《非原创研究》用于项目页一样离谱…… ——自由雨日🌧️❄️ 2024年12月5日 (四) 00:39 (UTC)[回复]
(！)意见，我认为你应该是对Wikipedia:用户框/各国政治、Wikipedia:用户框/信仰与主张这些相关的UB感到有意见？如果只就UB的大小，行文格式进行规范的话，是不是有需要对此作更强烈的限制（例如UB的渲染高度），即使已经使用了{{Userbox}}做基底？对于这些政见表达，如何认定这些是不是与其在项目上的编辑有意见倾向？另，Wikipedia:用户框现在的行文，更像是{{Information page}}或者{{Wikipedia how-to}}，而不是{{Guideline}}。——Sakamotosan路过围观 | 避免做作，免敬 2024年12月5日 (四) 00:50 (UTC)[回复]
并非针对这两个页面的模板。很多用于表示政见的模板十分有用，但判断有用的依据是用户是否能根据这一点自我提醒，而不是用于向其他人宣传自己赞同的意识形态。以Wikipedia:用户框/信仰与主张#特定人物与政策为例，“这个用户相信维基百科能够改变愤青”是有意义的，“这位用户要求当局立即释放天主教上海教区马达钦主教并停止干涉教务”是具体而（对维基百科及社群）无用的。再比如：T:User hate DPRK的内容比T:User no DPRK更为妥当。如果一个用户的编辑可以说是试图在维基百科宣传其用户页提到的理念，那就可以说，用户框虽然没能提醒用户自己，但提醒了社群。
用户用户框的外观只能说是提供建议，告知制作者和使用者应尽可能规范，如果用户自己愿意用不规范的模板以至于自己用户页一团糟那是用户自己的问题。——暁月凛奈 (留言) 2024年12月5日 (四) 05:43 (UTC)[回复]
关于UB内容的表达，两方面：一方面对于UB内容是否过于“与维基百科目标无关的作品、信息、讨论和行为”、“与百科全书编辑无关的极具争议性或攻击性的内容”是否需要更强制的规范；另一方面是，用户堆叠自己的UB是否过于“与维基百科目标无关的作品、信息、讨论和行为”、“与百科全书编辑无关的极具争议性或攻击性的内容”。两方面的目标有所不同。——Sakamotosan路过围观 | 避免做作，免敬 2024年12月5日 (四) 08:55 (UTC)[回复]
用户选择用用户框表示和用自己的话写一段内容都是一样的性质，只不过如果存在大量不合适的用户框会导致不了解的用户更容易使用这些。此前某用户在用户页没有使用任何用户框，写了大篇幅的无关内容，一样是按WP:UPNOT送存废讨论删除。如果用户是自己定义了大量有用处的用户框，那么堆叠起来也没问题。重要的自然是内容。用户页不该有的，显然不能因为是用户框的形式就能留存，用户框反而加剧了跟着闯红灯的问题。问题不在强制不强制，维基百科不缺立法委员和法匠，UPNOT一直就在那里放着，如果现在不把问题说清楚，说不定就是在编辑争议和不当行为车轮战，我完全没精力和兴趣去应付。——暁月凛奈 (留言) 2024年12月5日 (四) 13:34 (UTC)[回复]
(＋)支持，一部分用户框存有过度阐释或个人化阐释的问题，急需依据规范修正。--向史公哲曰（留言） 2024年12月5日 (四) 03:45 (UTC)[回复]
(※)注意 已对该用户提报Wikipedia:利益冲突/布告板#Carl66066--航站区（留言） 2024年12月7日 (六) 11:50 (UTC)[回复]
我看了英文的en:Wikipedia:Userboxes指引，已经有指引介绍到用户框的内容要求，简要概括就是：用户框同样适用文明方针以及不是什么方针，不是自我宣传、发表个人观点、进行广告宣传的地方。但是既有的一些用户框（尤其是某人喜欢某品牌）都会打上品牌口号（广告语），如Template:User BYD和Template:User 蜜雪冰城等，是否算“宣传”？--Shwangtianyuan 不忘初心 牢记使命 2024年12月7日 (六) 15:25 (UTC)[回复]
目的性及作用上可大致区分。User BYD用途有点隐晦，喜欢、拥有，还是别的什么，或者什么都不表示。User 蜜雪冰城的广告语内容更接近幽默。--YFdyh000（留言） 2024年12月7日 (六) 15:48 (UTC)[回复]
表明自己的爱好有时有助于协作。即使都是正面语气，“这个用户喜欢XX”和“您不再需要通过XX来……”的区别还是非常明显的。——暁月凛奈 (留言) 2024年12月7日 (六) 18:45 (UTC)[回复]

目前UBX页面基本上是帮助文档。我打算用适当的篇幅说明上方提到的，用户框的作用、内容、视觉效果，然后在这下方重新整理用户框的最佳实践。由于内容等应受到的限制以用户页等方针指引为准，本身不增加额外的限制，所以完成上述步骤后直接移除无采纳共识的模板（像WP:BABEL这样不加任何方针指引模板）。如何？——暁月凛奈 (留言) 2024年12月9日 (一) 10:45 (UTC)[回复]

赋予过滤器助理修改滥用过滤器权限

注意到防滥用过滤器错误报告和防滥用过滤器请求积压，管理员及行政员负担较重，导致部分请求无法及时处理，这降低了过滤器阻止破坏的能力，亦增加了社群维护其的难度。因此，谨提议授予过滤器助理修改权限，协助管理滥用过滤器，尚祈社群商议为荷。

现行条文

权限总览 对比起一般使用者，过滤器助理可以：

  • 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private）
  • 查看被标记为非公开的滥用过滤器（abusefilter-view-private）
  • 启用双重身份验证（oathauth-enable）
  • 允许移除自己账号的用户组
提议条文

权限总览 对比起一般使用者，过滤器助理可以：

  • 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private）
  • 查看被标记为非公开的滥用过滤器（abusefilter-view-private）
  • 启用双重身份验证（oathauth-enable）
  • 创建或修改滥用过滤器（abusefilter-modify）
  • 修改包含受限动作的滥用过滤器（abusefilter-modify-restricted）
  • 允许移除自己账号的用户组

此外，亦请参见二年前之增设过滤器编辑员讨论。——敬颂冬绥 ZhaoFJx(论•签) 2024年12月5日 (四) 16:00 (UTC)[回复]

已知获权者皆熟悉过滤器和正则表达式，并考虑到目前的积压，(＋)支持本提案。不过，可能不应当授予abusefilter-modify-restricted权限，该权限实质上允许过滤器助理进行封禁这一管理动作。--Iming 彼女の爱は、甘くて痛い。 2024年12月5日 (四) 16:27 (UTC)[回复]
另可以增加限制：“仅在社群有明确共识时，过滤器助理才可以新建过滤器。”--Iming 彼女の爱は、甘くて痛い。 2024年12月5日 (四) 16:34 (UTC)[回复]
关于这个限制，需规定在 WP:AFR/可靠来源布告版 达成的共识才算数，实行没有共识的动作有机会遭除权。
BTW, 现在已经有GPT，有没有wiki人愿意付那20美金/690台币一个月，建立GPT BOT,喂他关于wiki独有的正则表达式技术文件及实行内容，建立或修改防滥用过滤器应该没什么难度[开玩笑的]。--唔好阻住我爱国（留言） 2024年12月5日 (四) 16:47 (UTC)[回复]
赞成您的观点，我补充一下：“仅在社群有明确共识时，过滤器助理才可以新建过滤器。如过滤器助理未经社群讨论并取得明确共识便自行设置过滤器，则不论过滤器性质为何，皆属违规，管理员可自行决定是否除权或给予警告，社群成员如有发现也可至布告板举报。”--Iming 彼女の爱は、甘くて痛い。 2024年12月5日 (四) 16:54 (UTC)[回复]
布—>布--唔好阻住我爱国（留言） 2024年12月5日 (四) 17:23 (UTC)[回复]
@HK5201314 布—>佈，考虑使用-{}-避免自动转换——敬颂冬绥 ZhaoFJx(论•签) 2024年12月5日 (四) 21:23 (UTC)[回复]
这个限制可能比较鸡肋，先是过滤器规则里面加个或条件就能在不创建新过滤器的情况下几乎达到新过滤器的功能，再是如果A过滤器本身是阻止，没有对应的警告过滤器，如果过滤器助理认为有必要拆分出仅警告的过滤器，还得走流程，也会变相积压。不如要求“依据常识判断，不合理的过滤器更动应被警告或除权”。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月6日 (五) 01:59 (UTC)[回复]
我觉得可以，您书的对。--Iming 彼女の爱は、甘くて痛い。 2024年12月6日 (五) 02:36 (UTC)[回复]

草案

草案 #1

提议条文

权限总览 对比起一般使用者，过滤器助理可以：

  • 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private）
  • 查看被标记为非公开的滥用过滤器（abusefilter-view-private）
  • 启用双重身份验证（oathauth-enable）
  • 创建或修改滥用过滤器（abusefilter-modify）
  • 允许移除自己账号的用户组

Iming指出，过滤器助理不应包含“修改包含受限动作的滥用过滤器”一权。根据滥用过滤器文档和之前讨论，过滤器助理将……

  1. 可以按照社群共识创建过滤器；
    1. 可以按照社群共识创建过滤器或根据相关讨论分拆过滤器；
  2. 可以按照错误报告修复过滤器；
  3. 不能创建或修改包含“撤销用户的自动确认状态”、“封禁进行编辑的用户和/或IP地址”两类操作的过滤编辑器。

——敬颂冬绥 ZhaoFJx(论•签) 2024年12月5日 (四) 22:02 (UTC)[回复]

参考上方Hotaru Natsumi君，第一条或可以改为“可以按照社群共识创建过滤器或根据相关讨论分拆过滤器；”--Iming 彼女の爱は、甘くて痛い。 2024年12月6日 (五) 16:25 (UTC)[回复]
plus 已添加——敬颂冬绥 ZhaoFJx(论•签) 2024年12月6日 (五) 16:49 (UTC)[回复]

修改申请标准和流程

在站外收到了一些意见，有些意见指出由于赋予编辑权，应当适当拔高AFH的申请标准。因而，本人参考WP:IPBEG、WP:BAG和WP:SPI/C，草拟了一份提案，尚祈社群商议为荷。

现行条文

申请程序 如果您有意申请过滤器助理的权限，请亲自到Wikipedia:权限申请/申请过滤器助理权限申请，或接受其他用户于该页发起的提名。

以下使用者不需要去申请或是为他们增加本权限，他们本身已经获自动授予同等的权限：

  • 管理员
提议条文

申请程序 符合申请过滤器助理要求者，可循一般程序，在权限申请页申请成为过滤器助理。

提出申请后，具有管理员、回退员或过滤器助理权限的用户可以提出问题，并自行按其认知支持或反对申请，惟须附上有效理由。在申请人明显不符合条件的情况下，一名管理员或过滤器助理可以快速关闭此申请。申请以七日为限，七日后如总有效票数大于等于四票，且满足以下条件，则一名管理员或过滤器助理可以结案并授予过滤器助理权限：

  1. 支持率在50%以上；
  2. 没有管理员或过滤器助理反对。

或：

  1. 支持率在80%以上；
  2. 没有管理员反对。

以上。Iming 彼女の爱は、甘くて痛い。 2024年12月6日 (五) 12:45 (UTC)[回复]

基于程序公义，烦请阁下透露相关意见是在哪个外站及哪个人发表，谢谢！--唔好阻住我爱国（留言） 2024年12月6日 (五) 12:50 (UTC)[回复]
似乎这不涉及程序正义？另相关建议在我的私人群组中提出，当事人信息属隐私，恕不能公开。如果您一定需要的话，请理解成是我的想法。如有带来困扰，还请谅解，感谢。--Iming 彼女の爱は、甘くて痛い。 2024年12月6日 (五) 12:55 (UTC)[回复]
这可能有些打破RFR逻辑？当前RFR的逻辑应该类似于申请人提出申请，其他人有疑问则提出，管理员依据疑问及其处理完成授权与否的判断，不是简单投票。这种要求支持率的是RFA而非RFR。而且RFR很少能出现“有效票数”≥4的情况。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:44 (UTC)[回复]
因为有些意见指出由于赋予编辑权，应当适当拔高AFH的申请标准，因而我参考IPBEG和BAG的申请流程，写了这么个东西，本身最主要的作用是让有能力判断是否适合担任AFH的人参与最终决定。如果您真的觉得这样不合适的话，那么取消无过滤器助理反对情况下的有效票数和支持率限制如何？而且我相信管理员在赋权时也会参考社群意见，对于明显无法达成合意的讨论会直接忽视。--Iming 彼女の爱は、甘くて痛い。 2024年12月10日 (二) 02:07 (UTC)[回复]

草案 #2

提议条文

权限总览 对比起一般使用者，过滤器助理可以：

  • 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private）
  • 查看被标记为非公开的滥用过滤器（abusefilter-view-private）
  • 启用双重身份验证（oathauth-enable）
  • 创建或修改滥用过滤器（abusefilter-modify）
  • 添加用户组：过滤器助理
  • 允许移除自己账号的用户组

有成员主张，根据上方的授权流程草稿，草案#2应明确，在#1的基础上，允许过滤器助理赋予其他受信任用户过滤器助理一组。相信此改革可显著减轻管理人员在过滤器相关方面的任务压力。——敬颂冬绥 ZhaoFJx(论•签) 2024年12月7日 (六) 04:03 (UTC)[回复]

(＋)赞成，在管理员工作积压严重的当下，我相信这样可以显著减轻管理人员在过滤器助理相关方面的任务压力。--Iming 彼女の爱は、甘くて痛い。 2024年12月7日 (六) 05:22 (UTC)[回复]
不同意过滤器助理授予他人此一权限。现行权限申请制度未至积压，请维持依照正常程序申请，俾便于社群检视。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月7日 (六) 22:35 (UTC)[回复]
同Eric君，以目前的申请积压情况无必要授予过滤器助理授予他人权限的权限--人间百态,独尊变态(讨论)(签名) 2024年12月8日 (日) 14:30 (UTC)[回复]
RFR现在没有积压，没有必要由现任AFH给申请人上权限，并且2024年AFH申请的频率极低，明显不会造成RFR积压，故反对这一部分。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:32 (UTC)[回复]
个人认为过滤器编辑员应该是另一种权限，这个权限远远比查看过滤器敏感（例如有过滤器编辑权限者可以建立过滤器封禁所有试图编辑的用户）。反对赋予过滤器助理修改滥用过滤器权限。--GZWDer（留言） 2024年12月10日 (二) 11:25 (UTC)[回复]
@GZWDer：草案一定义了权限中将不再存在abusefilter-modify-restricted一权，故“封禁所有试图编辑的用户”这一行动技术上即不可行。——敬颂冬绥 ZhaoFJx(论•签) 2024年12月11日 (三) 01:21 (UTC)[回复]
但是仍然可以创建一个过滤器阻止任何用户编辑。--GZWDer（留言） 2024年12月11日 (三) 11:34 (UTC)[回复]
没必要因噎废食。现在错误报告的积压呢是放在那里的，喊管理员呢是没有人管的。按过往讨论，单开编辑者权限估计过不了，在考虑到积压问题、过往讨论和现有AFH均具备技术能力的情况下，给予AFH除受限过滤器外过滤器的编辑权是最优解，我上方提出的“修改申请标准和流程”案就是为了解决您这个问题设计的。而且事实上，我写个机器人实时回退匹配的编辑也不是不能实现这个功能，所以我是觉得把需要管理员权限的扔出去就差不多了，您意下如何？--Iming 彼女の爱は、甘くて痛い。 2024年12月11日 (三) 15:23 (UTC)[回复]

在受限过滤器多次匹配正常编辑时的处理措施

已关闭：
提案人 撤回提案。——敬颂冬绥 ZhaoFJx(论•签) 2024年12月10日 (二) 02:16 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

按前文讨论，考虑到对包含受限动作的过滤器的编辑权限实际上等同于封禁权限，因而没有授予过滤器助理创建或编辑含受限动作的过滤器的权限。然而参考近期AF/FP，可预见的在未来会存在含受限动作过滤器错误匹配甚至封禁正常编辑者的情况。又考虑到WP:AF等页面不存在事实上的过滤器方针，宜同本案一并讨论。是故，本人有以下想法，尚祈社群商议为荷。

现行条文

不存在

提议条文

编辑受限过滤器 当确认到一个包含受限动作的过滤器存在不符合预期的行为或已严重影响到正常编者编辑时，过滤器助理可以请求管理员临时关闭相关过滤器或取消相关过滤器内的受限动作，直至问题解决为止。当管理员处理此类操作时，除非有其他原因，否则通常应当在关闭过滤器后取消相关过滤器内的受限动作以便其他管理员或过滤器助理修复。当一名管理员或过滤器助理确认问题得到解决后，就可以恢复过滤器至原先状态。

以上Iming 彼女の爱は、甘くて痛い。 2024年12月8日 (日) 16:14 (UTC)[回复]

反对这种处理，比如过滤器275这类自动化封禁破坏的过滤器显然不能简单取消受限，只能过滤器助理调查哪一个正则导致了错误触发并请管理员处理，取消受限造成的反破坏影响太大了。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:39 (UTC)[回复]
您说的确实很有道理，那可能我们需要进一步讨论在受限过滤器多次匹配正常编辑时的处理措施。至少，我认为应当将封禁一类操作改为阻止+标记以供人工审查，您觉得如何？如此应当可以有效减轻对反破坏工作的影响。--Iming 彼女の爱は、甘くて痛い。 2024年12月9日 (一) 10:44 (UTC)[回复]
275这种泛用过滤器出现这类同规则多次触发的情况下直接把封禁过滤器里面多次误报的那一个规则移动到阻止或者警告（这里可以是201和289），这个操作管理员很容易完成，过滤器助理只需要调查出受限过滤器哪一个特定规则造成了错误触发，通知管理员即可。而像是322这种针对某一特定LTA（或者类似的单一用途过滤器），多次假阳性可以改为不受限。简单说就是需要具体情况具体分析，不建议写成条文，而是出问题了再和管理员依据常识解决。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:55 (UTC)[回复]
可以，我很赞成您的观点。撤回提案。--Iming 彼女の爱は、甘くて痛い。 2024年12月9日 (一) 11:02 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

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

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:不要包含原始资料的副本、Wikipedia talk:抄袭。

想法： 维基百科:抄袭 ：

现行条文

抄袭指的是将他人所贡献的作品，在没有提供足够的作者权益资讯之下，将其语言以及思想变成是自己的作品（在学术写作中，如果未能在论文中充分标注来源，而借用他人的任何想法或语言，便会被视为抄袭。无论来源是已出版的作者、其他学生、无明确作者的网站、贩售学术论文的网站或其他任何人：将他人的工作据为己有就是偷窃，这在所有学术情况下都不能接受，无论你是故意还是无意这样做。）该来源提供了各种抄袭类型的例子，包括逐字抄袭、拼凑抄袭、不充分的改写、未标注来源的改写和未标注来源的引用。剑桥大学将抄袭定义为：“将他人作品的部分或全部内容当作自己的作品提交，而没有适当标明来源，无论是否有意图欺骗。

维基百科有三项核心内容方针，其中两项很可能在不经意间产生抄袭问题。非原创研究防止我们将自己的想法放入条目当中，而可供查证要求条目必须基于可靠的已发表来源。这些方针意味着维基百科人非常容易被指责为抄袭者，因为我们非常执著于来源，但不能在内容上太过接近来源文本。由于抄袭的发生可能没有欺骗的意图，因此我们的关注方向应当放在教育编辑者清理条目内容。

提议条文

抄袭指的是将他人所贡献的作品，在没有提供足够的作者权益资讯之下，将其语言以及思想变成是自己的作品。各种抄袭类型的例子包括逐字抄袭、拼凑抄袭、不充分的改写、未标注来源的改写和未标注来源的引用。

我们建议编辑者应引用多方来源，条目的每一分段或单一事件应避免完全依靠同一个网站或书藉（每单元），当中包括官方网站及书藉。我们不建议编辑者原文引录来源的任何连续句（透过转述他人直接发表的关键言论除外）。至于产品或服务的使用条款或详细使用方法，我们建议使用外部链接功能，连结至记载相关资讯的官方网站或可靠来源。

以上！--唔好阻住我爱国（留言） 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)[回复]
(－)反对，不要将不同问题混为一谈。--dringsim 2024年12月6日 (五) 16:00 (UTC)[回复]
@沈澄心:只接受WP:建设性意见，谢谢配合！--唔好阻住我爱国（留言） 2024年12月6日 (五) 16:44 (UTC)[回复]

请求社群关注仲裁委员会在管理员的离任讨论中相关的权限问题

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:管理员的离任、Wikipedia talk:仲裁委员会。

先前的结论，以及目前的讨论，目前的讨论若认为太长，可以拉到最下方，路西法人君有小结。此处讨论虽然有加上rfc，但关注度不够，讨论人数过少，没有持续推进。仲裁委员会上任在即，目前讨论的迹象看来，已经到了就此讨论内容预计强迫沉默共识通过公示，我认为事关重大，故到客栈另请讨论。另外有准委员于站外认为我过分强调先前共识。我到目前为止的发言，没有偷换任何概念，我仅认为社群未有共识的部分，不能就这样在漫长讨论中随意加上去，这是为不公。若果仲裁委员会的准委员们认为应该于此有决断决行的权限，请社群决定，是否认同仲裁委员会可以全面接手解任管理员的相关程序（除了自请离任）。解任管理员一事社群未有要全权授予仲委会，不能利用沉默共识达成。--提斯切里（留言） 2024年12月9日 (一) 15:45 (UTC)[回复]

能不能简要概括一下目前争议的（即需要社群讨论的）问题，因为实在太长了 囧rz…… ——自由雨日🌧️❄️ 2024年12月9日 (一) 15:46 (UTC)[回复]
简单说来，不能纠举和弹劾管理员，不能全面掌握解任管理员的权限，还必须提出报告说服社群一事，觉得不是很满意。如果完全不管上方讨论，应该预计通过可以纠举管理员、命令停止管理权限直到调查完成，且能够解任管理员，无需提出报告，也就是说，第一个连结的结论已经没有任何效力。若我有误解的地方，请跟我说，谢谢--提斯切里（留言） 2024年12月9日 (一) 15:51 (UTC)[回复]
@Tisscherry 谢谢您的推进，但注意到于讨论中对每一细节都执念于共识的达成。共识本身建立在讨论之上—自然也感谢您作为社群一分子参与讨论—而非一成不变的规则条文。若过分担忧“沉默共识”达成，岂非对讨论参与者与讨论旁观者存有疑虑？同理，若过分执着于流程细节，而是否会使得讨论陷入冗长僵局，而忽略了共识达成所需本身应有的效率与共同视角？提斯切里君对共识的高标准无疑令人钦佩，我也感激社群能有像您这样积极参与的维基人，但或许应从一定程度上更信任社群成员及其参与的对话。谨祝讨论愉快——敬颂冬绥 ZhaoFJx(论•签) 2024年12月9日 (一) 16:12 (UTC)[回复]
我知道我强调之前的共识的行为可能造成反感，看起来也是了，造成困扰请见谅，我也不想被安上扰乱的头衔，所以于此发起讨论，仅只是想提高社群关注，若果社群因此能决定是否同意让仲裁委员会全面接手管理员的离任ㄧ事，不需要经过报告说服社群，我想也是好事一桩。--提斯切里（留言） 2024年12月9日 (一) 16:27 (UTC)[回复]
没有啦，请不要对此感到自责，很感谢指出可能存在的问题。我也没有指责您，只是友善地提出一些想法。此外，还请注意讨论中的缩进，确保开头冒号比回复评论所多一个，就此评论而言，开头应该有两个::，我已代您修改排版。—敬颂冬绥 ZhaoFJx(论•签) 2024年12月9日 (一) 16:32 (UTC)[回复]
好的，谢谢您的排版。--提斯切里（留言） 2024年12月9日 (一) 16:37 (UTC)[回复]

重新讨论NT:MUSIC

各位编辑，在下长期以来在浏览编辑维基百科的过程中，发现存在大量的近似爱好者内容，这些作品大多以单曲、演唱会和部分音乐综艺节目为主，通常无法证明其关注度，内文更是不重要的内容堆砌。但是，这些条目又往往能绕过当前NT:MUSIC的相关论述，使编者很难在存废问题或其他条目编辑问题上达成共识。依在下所见，当前的NT:MUSIC至少存在以下问题：

  • 在关于来源的问题上，现今条文是他们曾经被多份独立于该音乐家或团体以外的已出版可靠来源所提及，但是根据中国大陆当前现状，由于充斥大量的内容农场和宣传内容，使许多看似可靠来源实则存在潜在的不中立现象，如自己按门铃自己听中的中国网来源（《歌手·当打之年》今晚终极奇袭 周深首秀未发布新曲）之类，在下看不到任何属于可靠来源的证据。
  • 在关于音乐作品的内容中，维基百科:商业排行与认证是部分维基编者编辑部分单曲条目的重要依靠，但是中国大陆的音乐榜单要么是平台的自嗨、要么是粉丝的刷榜，毫无公信力可言。如被部分编辑推崇的腾讯音乐由你榜，就曾被举报过开通年会员可大大提高用户打榜（主要包括播放、收藏、下载、分析、点赞歌曲等）权重（1），并且该榜单仅限腾讯拥有版权的音乐，此类排行榜获得什么周榜月榜第几名、有多少可信度自有公论，其他类似网易、酷狗等等推出的野鸡榜单更是不用再浪费时间。
  • 另外，在相当多内容的条目中存在大量毫无意义的内容，几乎要把维基百科变成Fandom。如“天外来物”世界巡回演唱会中什么“衢州新闻媒体中心在抖音官方账号上发布了视频，表达了对薛之谦的感谢”、自己按门铃自己听中类似“周深在演唱的时候，身穿一件珍珠装饰的牛仔夹克，搭配黑色T恤和牛仔裤亮相”的表述，在下看不出放在条目内的必要。
  • 现存的NT:MUSIC中没有关于演唱会关注度的表述。

综上所述，现存的NT:MUSIC及其他相关页面均为论述或指引，并且部分表述相当模糊，大量的条目游走在关注度的边缘，因此在下建议社群对上述内容进行重新讨论并争取达成共识并升格为方针。由于刚刚提起讨论，在下暂不提出新的方案内容，待社群讨论后再进行总结。--SheltonMartin留言|签名 2024年12月11日 (三) 01:22 (UTC)[回复]

技术

请求管理员编辑{{lang}}模板

本主题或以下段落文字，在讨论结束后应存档至Module talk:Lang。

《WP:格式手册/文字格式#罗马化转写不用斜体》已经通过半个月了。--自由雨日🌧️🌨️ 2024年11月15日 (五) 08:54 (UTC)[回复]

模板{{lang}}应该没有斜体效果，可能涉及到类似{{lang-ru}}系列模板中用到的模块Module:Lang的修改。--Kethyga（留言） 2024年11月15日 (五) 11:16 (UTC)[回复]
@Ericliu1912：--自由雨日🌧️❄️ 2024年11月20日 (三) 19:54 (UTC)[回复]
请给新版，方得据以改之。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月21日 (四) 12:53 (UTC)[回复]
我看不懂代码啊，效果就是把斜体去掉😀 ——自由雨日🌧️❄️ 2024年11月21日 (四) 12:57 (UTC)[回复]
应该636和696行字串的i改成span就行。未测试，改之前务必测试。——枰（留言） 2024年11月22日 (五) 00:55 (UTC)[回复]
有没有可能我也不会代码，所以要由社群提出经过检验的版本（ —— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月22日 (五) 16:48 (UTC)[回复]
请求模板编辑员协助@Kcx36：--自由雨日🌧️❄️ 2024年11月26日 (二) 01:59 (UTC)[回复]
要取消所有lang-xx模板转写的斜体，修改的是全保护的Module:Lang，还得请管理员操作@Shizhao。大概是把636、696行的<i>...</i>改为<span>...</span>，修改前请测试。--Kcx36（留言） 2024年11月26日 (二) 02:25 (UTC)[回复]
已修改636、696行，但是478和488行还有<i>标签，不确定是否要改，lua代码太长了，实在没时间仔细看....--百無一用是書生 (☎) 2024年11月26日 (二) 03:00 (UTC)[回复]
其实636、696行，那部分，应该连代码逻辑都改掉才比较好--百無一用是書生 (☎) 2024年11月26日 (二) 03:02 (UTC)[回复]
目前《莫斯科》条目好像罗马化已经不显示斜体了！效果上应该已经实现了。（而且如果手动加入''则可显示斜体。）--自由雨日🌧️❄️ 2024年11月26日 (二) 03:03 (UTC)[回复]
（提醒：目前无论是否加入''符号，罗马化都永远显示斜体。）--自由雨日🌧️❄️ 2024年11月26日 (二) 02:53 (UTC)[回复]
{{Jpn}}的罗马字要不要取消斜体？--Kcx36（留言） 2024年11月27日 (三) 13:16 (UTC)[回复]
要哇，我今天刚在该模板讨论页提出😂 ——自由雨日🌧️❄️ 2024年11月27日 (三) 14:11 (UTC)[回复]
哦哦，没看到，已经改了。编辑请求不挂{{Editprotected}}很难注意到。--Kcx36（留言） 2024年11月27日 (三) 14:15 (UTC)[回复]
看来不只一处要修改；动手时请别忘了“Template_talk:Lang#修改“Template:lang””。--微甜微酸微苦＿＿微咸（留言） 2024年12月3日 (二) 15:50 (UTC)[回复]
与本讨论无关，若您仍要求修改，请提出新讨论并取得共识。--Kcx36（留言） 2024年12月3日 (二) 15:56 (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)[回复]

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

每日图片溢出

其实这个情况不时会出现，但今日的《八十七神仙卷》尺寸极长（如图），甚至是超出了原本维基百科的界面（在Vector 2010、Vector 2022、Timeless外观下均是如此）。然而，在未有登入维基百科的情况下，图片未有溢出（如图）。未知可如何修理？--银の死神♠走马灯剧场祝你在乱流下平安 2024年11月24日 (日) 05:25 (UTC)[回复]

参数设置 → 小工具 → 首页 → 首页以本地时间显示。已登录用户以参数设置页面“外观”中的“时差”设置确定，未登录用户以系统时区确定。 → 取消选中。--MilkyDefer 2024年11月24日 (日) 08:03 (UTC)[回复]
懂了。感谢。--银の死神♠走马灯剧场祝你在乱流下平安 2024年11月24日 (日) 08:17 (UTC)[回复]
我认为这个解决方法虽然有效，但只是暂时规避了问题。这实际上暴露了“首页以本地时间显示”选项与过宽的每日图片的不兼容性，这可能是一个更深层次的问题，需要进一步解决。是否可以从根本上优化，以应对超长或超宽图片的情况？--GUT412454（留言） 2024年12月2日 (一) 19:16 (UTC)[回复]

本主题或以下段落文字，在讨论结束后应存档至Template talk:Navbox、MediaWiki talk:Common.css。

之前开过，没人回存档了，例见沙盒。刚刚又稍微研究了一下，虽然不太懂不过应该找到问题所在了，似乎是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)[回复]

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

2024年第49期技术新闻

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

近况更新 - 面向编辑者

  • 本周新增了两个解析器函数。{{#interwikilink}}用于加入跨维基链接、{{#interlanguagelink}}用于加入跨语言链接。这两个解析器函数可以在命名空间与跨维基前缀相冲突时使用。例如，英语维基百科上以MOS:开头的链接与莫西语维基百科的mos语言代码前缀相冲突。
  • 从本周开始，维基媒体维基不再支持使用旧式RSA型HTTPS凭证的连接，具体来说是RSA-2048。此举旨在提高所有使用者的安全性。部分较旧、不受支持的浏览器或智能移动设备将无法连接；反之，它们会显示连接错误。详情请参阅HTTPS浏览器建议页面。所有现代操作系统和浏览器始终能够访问维基媒体维基。 [1]
  • 12月16日开始，部分维基的结构式讨论页将自动存档并设为只读模式，这些维基包括：arwiki、​cawiki、​frwiki、​mediawikiwiki、​orwiki、​wawiki、​wawiktionary、​wikidatawiki、​zhwiki。这是结构式讨论弃用作业的一部分。如果您需要任何协助来预先存档您的讨论页，请联络Trizek (WMF)。 [2]
  • 本月，Chart图表扩展已部署至生产环境，目前可在共享资源和测试维基使用。随着安全审查的完成，维基试行部署预计于12月第1周开始。您可以在测试维基查看工作版本，并阅读11月的项目更新了解更多。
  • 查看上周解决的共23个社群提交工单。 例如，“下载为PDF”系统的错误现已修复。 [3]

近况更新 - 面向技术贡献者

  • 明年2月下旬，临时账号将在至少10个大型维基推出。这项部署将对由社群维护的代码产生重大影响，影响包括Toolforge工具、机器人、小工具，以及使用IP地址数据或可供未登录用户使用的用户脚本。信任与安全产品团队希望找出这些代码、监控它们，并在部署前协助更新，以尽量减少对工作流程的干扰。团队恳请技术编辑者和志愿开发者们协助找出此类工具，将它们加入此清单。此外，请查阅更新后的文档，了解如何调整此类工具。欢迎到项目讨论页或维基媒体社群Discord服务器（英文）的专门讨论区参与讨论，寻求支持并分享意见。

技术新闻由技术新闻编者撰写，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2024年12月2日 (一) 22:21 (UTC)[回复]

第一条新增两个解析器函数是不是意味着本站AbuseFilter要做相应调整？--碟之舞📀💿 2024年12月3日 (二) 03:33 (UTC)[回复]

infobox award wikidata 多于一图片显示异常

本主题或以下段落文字，在讨论结束后应存档至Template talk:Infobox award。

例见IEEE约翰·冯·诺伊曼奖章的infobox award，显示成红字“File:IEEE John von Neumann Medal.png、John von Neumann Medal.png”而无图片。--惣流·明日香·兰格雷不姓式波 2024年12月3日 (二) 12:12 (UTC)[回复]

已修复：Special:Diff/85186657。--Kcx36（留言） 2024年12月3日 (二) 12:32 (UTC)[回复]
感谢。--惣流·明日香·兰格雷不姓式波 2024年12月3日 (二) 13:05 (UTC)[回复]

旗帜模板显示问题

本主题或以下段落文字，在讨论结束后应存档至WikiProject talk:纹章及旗帜/旗帜模板。

本站的旗帜模板系统似乎不能正常显示设定别称（alias）跟陆、海、空三军别称？请参见法国旗帜模板中文版本与英文版本之对比。此外，相关模板分类亦有待整理。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月3日 (二) 19:18 (UTC)[回复]

Template:Flag/testcases。需要熟悉相关模板的维基人检查是否能符合预期。--YFdyh000（留言） 2024年12月3日 (二) 20:51 (UTC)[回复]
仔细想了想，别称问题虽源自技术原因，但可能要延迟处理，因为本站不少编者直接使用英文别称，恐造成显示错误。若能达成为若干别称设定特定显示方式（如“Republic of Korea”显示为“大韩民国”等）将是完美，但这需要额外技术成本，难以立即解决。陆海空军别称问题则应可照常修复。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月5日 (四) 12:15 (UTC)[回复]

Lang-xx斜体显示异常

以此内容为例，显示效果如下{{lang-en|''正常顯示''}}{{lang-no|''異常顯示''}}

英语：正常顯示[异常显示] 错误：{{Lang-xx}}：文本有斜体标记（帮助）

是因为不同语言参数造就此显示问题吗？还是其他语言不支援斜体？--窝法乙烷 儿法梦碎 2024年12月4日 (三) 15:18 (UTC)[回复]

{{lang-no|異常顯示|italic=yes}}
参见模板文档
此节部分从Template:Lang-x/doc/parameters（编辑 | 历史）转录。
lang-xx支持的参数
参数 定义 受制于 别名
text 非中文文本 – {{{1}}}
translit text内容的拉丁文字转译 – {{{2}}}
translit-std translit文字的转译标准。可接受的值有：ISO, DIN, IAST, ALA, ALA-LC –
translit-script 转译标准的文字标识 –
translation text的中文字面意思 – lit, {{{3}}}
label 使用的标记，代替模板提供的语言标记。可加维基连接。特殊关键字none会使模板以无标记呈现（包括转译和直译字段） –
link yes（默认） 链接语言名称和与translit和translation关联的静态文本。可接受的值有：no, yes。|link=no 不影响|label=设置的维基连接 – links
code text内容的IETF语言标签。由模板设置，不鼓励重写模板设置 –
script IETF语言文字子标签。当text中的内容使用不止一种书写系统时，此字段由模板设置。总是四个字母。Latn （不是"Latin"!）值强制斜体渲染，除非由italic字段重写。重写rtl italic
region IETF语言区域子标签 –
variant IETF语言变体子标签 –
rtl yes表示text内容使用从右至左的书写系统。可接受的值有：no（默认）, yes script
italic 参考表格"lang-xx |italic= 参数操作"; 可接受的值有：yes, no, unset, invert, default – italics
size 指定text内容的字体大小。使用适合与CSS font-size属性一起使用的值。应该是%或em提供的相对值，不是固定的px值。 –
nocat yes禁止自动分类。可接受的值有：no（默认）, yes –
lang-xx |italic= 参数操作
|italic= value 描述 示例代码 结果 HTML标记
  • 参数不存在；
  • 参数存在，未设置；
  • 无效值
  • 模块应用样式：
  •   模板设置, 或
  •   |script=latn；
  • 否则继承自外部标记
  • 无效值视为默认值
 {{lang-ru|тундра}} 俄语：тундра 俄语：<span lang="ru">тундра</span>
{{lang-ru|tûndra}} 俄语：tûndra 俄语：<span lang="ru">tûndra</span>
Incorrect markup; this requires |script=latn.
{{lang-fr|toundra}} 法语：toundra 法语：<span lang="fr">toundra</span>
{{lang-ru|script=latn|tûndra}} 俄语：tûndra 俄语：<i lang="ru-Latn">tûndra</i>
default {{lang-ru|тундра|italic=default}} 俄语：тундра 俄语：<span lang="ru">тундра</span>
{{lang-fr|toundra|italic=default}} 法语：toundra 法语：<span lang="fr">toundra</span>
{{lang-ru|script=latn|tûndra|italic=default}} 俄语：tûndra 俄语：<i lang="ru-Latn">tûndra</i>
no
  • 模块采用直立样式；
  • 重写|script=latn；
  • 重写外部标记
 {{lang-ru|тундра|italic=no}} 俄语：тундра 俄语：<span lang="ru" style="font-style: normal;">тундра</span>
{{lang-fr|toundra|italic=no}} 法语：toundra 法语：<span lang="fr" style="font-style: normal;">toundra</span>
{{lang-ru|script=latn|tûndra|italic=no}} 俄语：tûndra 俄语：<span lang="ru-Latn" style="font-style: normal;">tûndra</span>
''{{lang-ru|script=latn|tûndra|italic=no}}'' 俄语：tûndra ''俄语：<span lang="ru-Latn" style="font-style: normal;">tûndra</span>''
yes
  • 模块采用斜体样式；
  • 忽略|script=latn
 {{lang-ru|тундра|italic=yes}} 俄语：тундра 俄语：<i lang="ru">тундра</i>
{{lang-ru|script=latn|tûndra|italic=yes}} 俄语：tûndra 俄语：<i lang="ru-Latn">tûndra</i>
unset
  • 模块不使用样式；
  • 从外部标记继承样式；
  • 重写|script=latn
 {{lang-ru|тундра|italic=unset}} 俄语：тундра 俄语：<span lang="ru">тундра</span>
''{{lang-ru|тундра|italic=unset}}'' 俄语：тундра ''俄语：<span lang="ru">тундра</span>''
{{lang-ru|script=latn|tûndra|italic=unset}} 俄语：tûndra 俄语：<span lang="ru-Latn">tûndra</span>
''{{lang-ru|script=latn|tûndra|italic=unset}}'' 俄语：tûndra ''俄语：<span lang="ru-Latn">tûndra</span>''
invert
  • 模块不使用样式；
  • 反转内部标记的样式†
  • 禁用自动斜体
  • 重写文本子标签latn
 {{lang-ru|тундра|italic=invert}} 俄语：тундра 俄语：<span lang="ru">''тундра''</span>
''{{lang-ru|тундра|italic=invert}}'' 俄语：тундра ''俄语：<span lang="ru">''тундра''</span>''
{{lang-ru|script=latn|tûndra|italic=invert}} 俄语：tûndra 俄语：<span lang="ru-Latn">''tûndra''</span>
''{{lang-ru|script=latn|tûndra|italic=invert}}'' 俄语：tûndra ''俄语：<span lang="ru-Latn">''tûndra''</span>''

† 对比|italic=invert和|italic=unset：

{{Lang-de|... ein neues Opernprojekt in Angriff: ''Das Käthchen von Heilbronn'', nach Heinrich von Kleists gleichnamigem Drama.|italic=invert}}
德语：... ein neues Opernprojekt in Angriff: Das Käthchen von Heilbronn, nach Heinrich von Kleists gleichnamigem Drama.
{{Lang-de|''... ein neues Opernprojekt in Angriff: ''Das Käthchen von Heilbronn'', nach Heinrich von Kleists gleichnamigem Drama.''|italic=unset}}
德语：... ein neues Opernprojekt in Angriff: Das Käthchen von Heilbronn, nach Heinrich von Kleists gleichnamigem Drama.
--Qqkuro66541（留言） 2024年12月4日 (三) 22:21 (UTC)[回复]
还是您只是要问原因，在Module:Lang有说明，除非模板有|italic=unset or |italic=invert，排除字体控制，以方便由内部或外部套用模板文字的字体样式的标记，所以也可以用{{lang-no|''異常顯示''|italic=unset}}，上方模档文档也有范例。--Qqkuro66541（留言） 2024年12月4日 (三) 23:22 (UTC)[回复]

Arbcom 关联

请导入Wikipedia:仲裁/请求/案件/header自en:Wikipedia:Arbitration/Requests/Case/Header。谢谢。 -Lemonaka 2024年12月5日 (四) 08:25 (UTC)[回复]

请导入Template:Arbitration case request自en:Template:Arbitration case request。谢谢。有了这两个Arbcom可以测试操作。 ---Lemonaka 2024年12月5日 (四) 13:06 (UTC)[回复]

@Borschts、Ericliu1912： -Lemonaka 2024年12月5日 (四) 13:11 (UTC)[回复]
@Lemonaka：哈啰页面已经由我和ZhaoFJx汇入完成了，非常感谢您的协助。~~Sid~~ 2024年12月5日 (四) 14:22 (UTC)[回复]
Wikipedia:仲裁/请求/案件/header按钮并未向Template:仲裁立案请求 -Lemonaka 2024年12月5日 (四) 16:17 (UTC)[回复]
fixing. -Lemonaka 2024年12月5日 (四) 16:24 (UTC)[回复]
@ASid Now fixed. -Lemonaka 2024年12月6日 (五) 00:27 (UTC)[回复]
仍有问题，@0xDeadbeef 我们并没有一个{{admin}}的模板，因此当您针对管理员提起案件时，他们不会被列入当事方名单中。Special:Diff/85212370 -Lemonaka 2024年12月6日 (五) 00:43 (UTC)[回复]
Template:admin on this project is a redirect of {{administrator topicon}} -Lemonaka 2024年12月6日 (五) 00:44 (UTC)[回复]
Fixed as {{adminlinks}} -Lemonaka 2024年12月7日 (六) 12:11 (UTC)[回复]

WP:ANM中的过滤器错误

本主题全部或部分段落文字，已移动至Wikipedia:防滥用过滤器/错误报告。执行人：敬颂冬绥 ZhaoFJx(论•签) 2024年12月5日 (四) 14:06 (UTC)。[回复]

WP:AF/FP的机器人存档问题

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:防滥用过滤器/错误报告。

目前WP:AF/FP页面的机器人存档是14日内无新发言就会被Jimmy-bot存档，不会判断当前错误报告的状态是否为关闭或已解决。搜索存档中的状态： 确认可以得到很多由回退员或过滤器助理确认需要管理员处理，但管理员还未处理就被存档的错误报告，请问目前Jimmy-bot技术上能否实现存档时对{{bugstatus}}模板做判断只存档关闭和解决的（即|status=为cls和res）的情况？如果可以，能否更新存档逻辑为以上？𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月6日 (五) 06:12 (UTC)[回复]

副知机器人操作者@Jimmy Xu。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月6日 (五) 06:12 (UTC)[回复]
@Hotaru Natsumi：他应该是修了，另外他不收ping，下次可直接去他讨论页问（ —— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月8日 (日) 05:10 (UTC)[回复]
好的好的，感谢。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月8日 (日) 06:51 (UTC)[回复]

本主题或以下段落文字，在讨论结束后应存档至Template talk:NavboxV2。

效果差异请参见“台湾海峡两岸主题”模板“派出机构”部分。副知@Cwek。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月7日 (六) 21:13 (UTC)[回复]

子Navbox嵌入改参数1=child。参考T:广州市主要道路和T:广州市桥隧的嵌入。——Sakamotosan路过围观 | 避免做作，免敬 2024年12月8日 (日) 04:01 (UTC)[回复]
@Cwek：若技术上允许，希望能沿用include=true参数。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月8日 (日) 05:02 (UTC)[回复]
@Ericliu1912：，修复了，参数提取有问题。因为跟随Navbox的特性，include（也就是子Navbox的border改child）功能不加入（在模板外层添加判断参数解析器调用不太难）。——Sakamotosan路过围观 | 避免做作，免敬 2024年12月8日 (日) 05:07 (UTC)[回复]

条目翻译功能导致重复条目

日前清理未连wikidata的条目时，发现4组条目被重复创建。

英 中1 初版 中2 初版
en:PAAMS PAAMS 2024-01-22 PAAMS防空系统 2024-04-17
en:Plancherel theorem 普朗歇尔定理（简体标题） 2024-02-25 普朗歇尔定理（繁体标题） 2024-04-29
en:Masters of the Universe 决胜时空战区 2024-04-28 太空超人系列 2024-05-31
en:Omnium 全能赛（繁体标题） 2024-08-08 全能赛（简体标题） 2024-11-19

经简单调查，经过应该是：

  1. 两个编者（a、b）先后于内容翻译的建议页找到待翻译条目
  2. 其中一人（a）先发布，条目自动连至wikidata
  3. 第二人（b）不知a已发布，发布第二版本，新版自动连至wikidata，旧版变成孤儿

至少于两处可避免此类情况：

  1. 尽早更新内容翻译的建议页（以上例子两版间至少隔了一个月，个人推断b不太可能花这么长时间翻译，所以应该是a发布后仍在建议页看到）
  2. 经翻译系统发布时先检查wikidata是否已有连结（更理想做法是a发布后系统直接通知b，甚至于更早阶段令ab两人知道他们正翻译同一条目，但在b发布时检查应该是技术上最简单的）

@日期20220626、Adiu ica、Mbjpxncp7k、Råy kuø、203.218.99.114、XDXDXC、Ma3r：副知以上8篇条目的编者。--惣流·明日香·兰格雷不姓式波 2024年12月8日 (日) 05:51 (UTC)[回复]

我记得内容翻译会提示已有人在翻译此条目。没见过这种情况。--YFdyh000（留言） 2024年12月8日 (日) 06:17 (UTC)[回复]
刚刚模拟了一下，繁体“國泰港龍航空”连至英维“Cathay Dragon”，假设因某些原因更早阶段的警告被无视或未显示，至少在尝试翻译“Cathay Dragon->國泰港龍航空”（繁体标题）时编辑器会有警告提示（见此），蓝链重定向简体“港龙航空公司”亦有警告（见此），但尝试翻译至红链简体标题国泰港龙航空时则没有（见此），合理推测只要b的标题仍是红链就没有警告。--惣流·明日香·兰格雷不姓式波 2024年12月8日 (日) 06:46 (UTC)[回复]
我解释一下我参与的全能赛条目，希望有所帮助。当时是 XDXDXC 君先翻译的，但他发布在了草稿空间（繁体标题），所以我翻译的时候没有发现。（我不知道为什么他没有发布到正式空间，超过三个月了。）直到我发布（简体标题）之后再编辑时，才看到“存在草稿”云云。不过，我当时先把我的版本移动到个人草稿，不留重定向；然后再合并到他的草稿上，再发布到正式空间（繁体标题）。所以，简体标题的全能赛，应该是曾经存在过，现在并没有，对吗？此外，如果条目长（或者其它什么特殊情况）的话，翻译过程可能确实会超过两个月。我翻译加沙种族灭绝的时候，就是翻译半截发现爱喝奶茶君已经建立了条目。我估计是他没用翻译工具，要不然后翻译的人应该翻译不了。--Ma3r（铁塔） 2024年12月8日 (日) 10:10 (UTC)[回复]
此外，针对您的建议发表一下看法：
  1. ( ✓ )同意。对，如果有人已经翻译了，包括没发布的和发布到草稿的，（如果技术可行的话，）都不要再建议了。（虽然我不清楚现在的建议逻辑。）不过，我从来没有翻译过建议的条目，都是找感兴趣的和基础条目。
  2. ( ✓ )同意。不过，如果发布到草稿空间的话，是没有 wikidata 链接的，对吧？
--Ma3r（铁塔） 2024年12月8日 (日) 10:29 (UTC)[回复]
补充一组类似的重复条目，请协助合并：蓝色师奖章、蓝色师奖章。--Kcx36（留言） 2024年12月8日 (日) 15:09 (UTC)[回复]
这个的旧版（繁体）看起来不是用翻译系统的，但简繁标题也是存在已久的问题。 囧rz……--惣流·明日香·兰格雷不姓式波 2024年12月8日 (日) 23:36 (UTC)[回复]
针对简繁也有一个方案：创建页面时（含经翻译工具）先检查一下是否存在标题纯简繁差异的页面，可能用过滤器或者其他方法，禁止是不行的，毕竟有简繁重定向，但警告还是需要的。--惣流·明日香·兰格雷不姓式波 2024年12月9日 (一) 00:12 (UTC)[回复]

2024年第50期技术新闻

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

本周要闻

  • MediaWiki.org文档中心更新，技术文档贡献者现在可由此取得最新资源，并了解与社群及维基媒体技术文件团队的新联系方式。该页面提供以下连结：文档编写与改进资源、libera.chat上的新IRC频道#wikimedia-techdocs、过去和即将举办的文档相关活动清单、请求文档咨询或审查的方法。如果您对文档生态系统有任何想法或改进意见，请联络技术文档团队。

近况更新 - 面向编辑者

编辑检查功能的版面调整
  • 本周稍晚，桌面版的编辑检查框将移至侧边栏。编辑检查功能旨在协助新手编辑者遵循方针与指引。这项版面调整腾出的空间，让编辑者在输入文字时，能同时看到新的检查项目。初步结果显示，新手在遇到编辑检查框后，成功发布包含参考资料且未被回退的新内容编辑的可能性提高了2.2倍。
  • 数据可视化工具——Chart图表扩展已顺利部署至MediaWiki.org和3个试办维基（意大利语、瑞典语、希伯来语维基百科）。您可以在测试维基查看范例，并阅读11月的项目更新了解更多。
  • 在提供移动版内容翻译的维基中，翻译者现在可以从条目建议功能中的“所有收藏”分类中探索他们感兴趣的维基专题活动条目。维基专题的活动筹办人员可以使用此功能，透过将<page-collection> </page-collection>标签加入至元维基上的活动条目列表页面，帮助翻译者探索感兴趣的条目。这将提高这些条目在内容翻译工具中的能见度。关于如何使用该工具和标签的详情，请参阅逐步指南。 [4]
  • “大量删除”（Nuke）功能现在有了可多选的命名空间筛选。这使得用户在提取要删除的页面时，能够选择多个特定的命名空间，而不是仅选择一个或全部。
  • 此外，在待删除页面进入队列后，大量删除功能现在会提供以下连结：遭删除页面的创建者的用户页，以及其未被选择删除的页面。这使得管理员能更容易进行后续管理操作。感谢Chlod和Moderator Tools团队所做的这两项改进。 [5]
  • 编辑团队正在努力让自动填入引用产生器——Citoid更容易从archive.org填入引用。团队要求社群在每个使用Citoid的引用模板的TemplateData中预先加入两个参数archiveUrl和archiveDate。参见模板变更范例，以及所有相关模板的清单。 [6]
  • 一个新的维基已创建： 印尼语维基导游 (voy:id:) [7]
  • 上周，所有维基网站经历了持续30至45分钟的服务中断，无法顺利提供网页给已登录及部分未登录用户。此事件起因于数据库异常，调查仍在进行中。 [8]
  • 经常项目 查看上周解决的共19个社群提交工单。 例如，添加链接功能的错误现已修复。之前，在某些情况下，从添加链接功能排除的章节清单会被部分忽略。 [9][10]

近况更新 - 面向技术贡献者

  • 维基媒体设计系统——Codex现在有一个早期阶段的PHP实现。它可透过Composer在MediaWiki扩展与Toolforge应用程序供一般使用，并即将用于MediaWiki核心。更多详情请参阅文档。感谢Doğu的灵感以及对函式库的诸多贡献。 [11]
  • Wikimedia REST API用户，如机器人操作者和工具维护者，可能会受到正在进行的升级更新的影响。12月4日，MediaWiki界面团队着手将测试维基上的页面及修订版本的metadata、渲染后的HTML内容等端点，从RESTbase重编路由至相似的MediaWiki REST API端点。团队鼓励这些端点的活跃用户在测试维基验证其工具的行为，并于年底前将任何疑虑提交至相关的Phabricator工单，团队打算于1月初在所有维基媒体项目实施相同的变更。这是取代过时的RESTBase系统的作业的一部分。
  • 邀请维基媒体开发者社群填写2024年开发者满意度调查。如果您在维基媒体生态系统的软件开发中占有一角，请填写此问卷调查。调查开放填写至2025年1月3日，并请参阅相关隐私声明。
  • 本周没有MediaWiki的新版本。 [12]

会议与活动

技术新闻由技术新闻编者撰写，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2024年12月9日 (一) 22:14 (UTC)[回复]


求助

请求修改长洲（苏州）彭氏模板

模板内容有误，但不知道如何去修改，这问题我之前曾在Minorax大的留言板求助过，但没下文，所以想来这边再求助一次，看看是否有人能帮忙修改。--天夜叉（留言） 2024年11月26日 (二) 05:27 (UTC)[回复]

参考链接：Template:长洲彭氏、User_talk:Minorax#长洲彭氏模板谬误--GUT412454（留言） 2024年12月2日 (一) 19:25 (UTC)[回复]

请求协助上传档案 2024-11-29 06:06

我想要上传的图片来源是< https://www.instagram.com/p/C_P4jQ8vWN1/?igsh=MWFmNjFzNDVzcmRpZQ==>，想要使用在李娥妍的<资讯框>。 --仓鼠沙拉（留言） 2024年11月29日 (五) 06:06 (UTC)[回复]

驳回 驳回，请看著作权方针--——— 此请炉安 August0422 (T / S) 2024年12月2日 (一) 12:14 (UTC)[回复]

请求协助上传档案 2024-11-30 06:15

我想要上传的图片来源是<https://static.wixstatic.com/media/e3f7e0_89865164cdc24adf9db048802492d327~mv2.png>，想要使用在Hong Kong Airport Services的<logo>。 https://en.wikipedia.org/wiki/Hong_Kong_Airport_Services

--Apicture（留言） 2024年11月30日 (六) 06:15 (UTC)[回复]

驳回 驳回，请先建立条目--——— 此请炉安 August0422 (T / S) 2024年12月2日 (一) 12:14 (UTC)[回复]
你要使用的条目在英文维基百科，请去英文维基百科提此请求。--GUT412454（留言） 2024年12月2日 (一) 19:31 (UTC)[回复]
@Apicture：--GUT412454（留言） 2024年12月2日 (一) 19:32 (UTC)[回复]

请求协助上传档案 {{subst:https://www.kgi.com/zh-tw/-/media/Images/CDF/Header/CDF_logo}}

我想要上传的图片来源是<凯基金控官网的照片，https://www.kgi.com/zh-tw/-/media/Images/CDF/Header/CDF_logo / ，请协助置换目前旧的中华开发金控LOGO>，想要使用在请提供条目名称（如果条目还不存在，请先建立条目再请求上传文件）的<资讯框/某个段落，请说明>。 --2883cdf（留言） 2024年12月2日 (一) 01:10 (UTC)[回复]

请求协助上传档案 2024-12-03 03:30

我想要上传的图片来源是<香港四邑商工总会陈南昌纪念中学校网中的校舍相片,https://www.cnc.edu.hk/it-school/php/webcms/files/upload/tinymce//2024_25_photo/2025_25_school/cnc_2024_1733196142.jpg>，想要使用在香港四邑商工总会陈南昌纪念中学的资讯框。希望添加新的校舍相片，谢谢 --218.188.147.162（留言） 2024年12月3日 (二) 03:30 (UTC)[回复]

请求协助上传档案 2024-12-04 06:48

我想要上传的图片来源是<自行拍摄>，想要使用在TOH (The Only Hope)的<资讯框，示意成员>。 --Jmehuihiuyi（留言） 2024年12月4日 (三) 06:48 (UTC)[回复]

请上传至维基共享资源--— 此请炉安 August0422 (T / S) 2024年12月5日 (四) 12:52 (UTC)[回复]

请求协助上传档案 2024-12-04 08:43

我想要上传的图片来源是<从豆瓣网址下载，https://www.douban.com/note/12249315/?cid=127411&_i=3286930BVgk589>，想要使用在张毓文的<演出剧照>。 --VA7022（留言） 2024年12月4日 (三) 08:43 (UTC)[回复]

可能不符合版权协议--— 此请炉安 August0422 (T / S) 2024年12月5日 (四) 12:52 (UTC)[回复]

请求修改中华民国海军一六八舰队

图片“168舰队队徽”是错误的，该图片中的徽章属于“兰阳号巡防舰（FFG-935）”，非海军一六八舰队队徽--Alexcal0317（留言） 2024年12月4日 (三) 12:47 (UTC)[回复]

@T407210009：请回应。[13]--YFdyh000（留言） 2024年12月4日 (三) 18:34 (UTC)[回复]
阿打字后因中华民国使用的是繁体字所以显示的就是繁体字啊！--T407210009（留言） 2024年12月5日 (四) 00:06 (UTC)[回复]
没看懂此回复。是中华民国海军一六八舰队的图片注解疑似有误。--YFdyh000（留言） 2024年12月5日 (四) 01:12 (UTC)[回复]

请求协助上传档案 2024-12-05 06:10

我想要上传的图片来源是<https://drive.google.com/file/d/1-SU19phrDEyCwyZIXhEXZ54fs_GGREEb/view?usp=sharing，請提供網址 / 自行拍摄>，想要使用在KE柯萧的<资讯框>。 --Chunyau85（留言） 2024年12月5日 (四) 06:10 (UTC)[回复]

著作权状态不明--— 此请炉安 August0422 (T / S) 2024年12月6日 (五) 11:36 (UTC)[回复]

请求添加关于联合国中非综合稳定团相关条目的内容

本人希望参与编辑与修改关于新创页面中非综合稳定团(一个联合国组织)的相关内容，但是受限于其带有管理员限制的字符.*共.*和.*[国国囯].*等，导致无法正常发布。 希望管理员在看到相关内容后能够给予一定的理解与支持，方便该条目的发布。 谢谢。--Natu Yuki 0125（留言） 2024年12月6日 (五) 01:40 (UTC)[回复]

先用其他名称建立条目或草稿，然后请其他人移动。--YFdyh000（留言） 2024年12月6日 (五) 02:23 (UTC)[回复]

上传图片与知识共享问题

想请问如果上传于维基的图片来源已标注“ © I agree to publish this image under the Creative Commons Attribution-ShareAlike 4.0 International license” （来源1：https://www.instagram.com/p/DA-rBBnJBXl/?igsh=dzgzbG02dHZqaHUz） （来源2：https://www.instagram.com/p/DBTliRmPGZ-/?igsh=ZWRtZGtlbmplYzN5） 是否符合维基所能上传的创用cc标准呢？--Tifffanyyy（留言） 2024年12月6日 (五) 07:22 (UTC)[回复]

CC BY-SA 4.0应该是可以的，请参见WP:著作权信息#引入和使用文字--竹林下小径，月光映一叶 2024年12月6日 (五) 07:31 (UTC)[回复]
感谢阁下回复，但他人以此来源上传之图片被认为非cc而被删除，那这样还可以再上传吗？--Tifffanyyy（留言） 2024年12月6日 (五) 07:41 (UTC)[回复]
可以让其走c:Commons:VRT（志愿者响应团队）来单独授权确认。——Sakamotosan路过围观 | 避免做作，免敬 2024年12月6日 (五) 07:51 (UTC)[回复]
共享资源上的图片（[14][15]）第一次似乎是原上传者请求速删，第二次的删除理由“Commons:Licensing: promo/press photo”说的是带有宣传性质？不太懂。
图片已发布在社交媒体并声明授权，不用再联系VRT。--Kcx36（留言） 2024年12月6日 (五) 08:24 (UTC)[回复]
Licensing应该只涉及版权选择问题？不应该是用Deletion_policy？问一下第二个管理员。——Sakamotosan路过围观 | 避免做作，免敬 2024年12月6日 (五) 09:09 (UTC)[回复]
可能是指C:Commons:CSD#F1？因为一般来说promo/press photo都是有版权的？--Miyakoo（留言） 2024年12月6日 (五) 16:50 (UTC)[回复]
不建议擅自重新上传，请提报c:COM:UR。--Wcam（留言） 2024年12月6日 (五) 14:25 (UTC)[回复]
原贴在INTERSTELLAR·汪苏泷发布，Ins已经侵权了，Commons快速删除也没什么问题，而且微博置顶说了不允许公开发放。如你或上传人士是INTERSTELLAR·汪苏泷，请走VRT。--Abcet10（留言） 2024年12月6日 (五) 17:24 (UTC)[回复]

条目的注释中含有数学式，但注释的字体被缩小，可能看不清楚

稍早我为条目加上含有数学式的注释，不过数学式因为常有上标、下标、分数等…原本某些字体就比较小，而数学式放在注释中似乎又会因<references>又进一步被缩小，也许会有数学式看不清楚的问题，请问一般是如何处理这类的问题？--Justin545（留言） 2024年12月7日 (六) 13:38 (UTC)[回复]

无标题

我在更改空白字符的“字元”一词时，直接修改为字符。结果一看，我这边的使用是正确的，但其他地区（如港澳台）的习惯用词对不上。 这点详见字符。--阿米娅2011（留言） 2024年12月8日 (日) 11:01 (UTC)[回复]

参见字符 (计算机科学)的条目源码。可能不在默认转换表，需要加{{TA}}，并非因为简繁混用。@日期20220626：该条目质量及必要性感觉不行。“垂直的空白字符”是什么？来源不明确，无法佐证。--YFdyh000（留言） 2024年12月8日 (日) 11:19 (UTC)[回复]
我本来写的是垂直的空格，就是一个光标。--日期20220626（留言） 2024年12月8日 (日) 11:22 (UTC)[回复]
无法理解“垂直空格”概念，换行符不是可见、占位的字符。顶多两次回车后有水平空行（格?）。--YFdyh000（留言） 2024年12月8日 (日) 11:34 (UTC)[回复]
我再看看，英维已经不是当初的版本了。--日期20220626（留言） 2024年12月8日 (日) 11:37 (UTC)[回复]

Infobox officeholder模板的term_end参数

我在杜德文条目的Infobox officeholder信息框填写相应参数后，显示效果仍然是“现任 就任日期 2019年3月”，而非“任期 2019年3月—2024年12月”，这是什么原因？--大化国史馆从九品笔帖式（留言） 2024年12月8日 (日) 15:50 (UTC)[回复]

 已修复。好像是因为|term_end=的=前面有几个不换行空格的缘故，已由U:Qqkuro66541于版本85242977修正。--竹林下小径，月光映一叶 2024年12月9日 (一) 02:16 (UTC)[回复]
谢谢。--大化国史馆从九品笔帖式（留言） 2024年12月10日 (二) 16:39 (UTC)[回复]

请求协助上传档案 2024-12-09 10:35

我想要上传的图片来源是<https://i.namu.wiki/i/ePNS_Yij4Bv7IVsgp_Z_cbaoJYSeB3s6QhphxVXMcu4TtkNEYaDZdPbjlr9lvyzqa4z2nzGLB6o4qd4ETSho4g.webp>，想要使用在三流反派在学院生存的<资讯框>。 --Tsubasa0105（留言） 2024年12月9日 (一) 10:35 (UTC)[回复]

请求协助上传档案

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


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

Special:用户权限的“活动组织者”用户组未正确繁简转换

如题。在大陆简体下看到的仍为繁体，而非简体（其他用户组已显示正确内容）。--阿米娅2011（留言） 2024年12月10日 (二) 13:21 (UTC)[回复]

大抵是这个：MediaWiki:Group-event-organizer-member/zh-hans。----伞木 霙留言 2024年12月10日 (二) 14:30 (UTC)[回复]
 已修复--千村狐兔（留言） 2024年12月10日 (二) 14:43 (UTC)[回复]

请求协助上传档案 2024-12-10 23:36

我想要上传的图片来源是<从某个网址下载，请提供网址 / 自行拍摄>，想要使用在请提供条目名称（如果条目还不存在，请先建立条目再请求上传文件）的<资讯框/某个段落，请说明>。 --忠政（留言） 2024年12月10日 (二) 23:36 (UTC)[回复]

遇水易燃中已存在的引用错误

实在看不懂遇水易燃中的引用错误到底是什么原因，希望有人能够帮忙排查问题。
(我准备添加一些新内容，但是在解决引用错误之前，我将准备新添加的内容放置在了草稿命名空间内。)--209.9.202.205（留言） 2024年12月11日 (三) 01:34 (UTC)[回复]

各种引用脚注模板的底层基本都是<ref>，然后<ref>一嵌套起来就会冒出各种稀奇古怪的问题，建议尽量避免在脚注里面加脚注。我调整了一下写法，不知您觉得如何。Irralpaca（留言） 2024年12月11日 (三) 03:58 (UTC)[回复]

请求协助上传文件

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

你好像回复错了，还有，登录帐号了以后记得用~~~~签名。--209.9.202.205（留言） 2024年12月11日 (三) 02:40 (UTC)[回复]

请求协助上传档案 2024-12-11 01:49

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

请求协助上传档案 2024-12-11 05:53

我想要上传的图片来源是<https://www.facebook.com/photo.php?fbid=970241927800398&set=pb.100044437989452.-2207520000&type=3 ]的臣铭形象图片,>，想要使用在臣铭的<资讯框>图片位置，感谢协助。David857806（留言） 2024年12月11日 (三) 05:53 (UTC)[回复]

请求协助上传档案 2024-12-11 08:02

我想要上传的图片来源是中南大学湘雅医学院官网：中南大学湘雅医学院Logo，想要使用在中南大学湘雅医学院的资讯框图片位。 --XianlitiCN（留言） 2024年12月11日 (三) 08:02 (UTC)[回复]

请求协助上传档案 2024-12-11 13:33

我想要上传的图片来源是WikipediaEN，想要使用在星谈_(脱口秀节目)的资讯框。 --User0912（留言） 2024年12月11日 (三) 13:33 (UTC)[回复]


条目探讨

参考资料

提议：依据学术规范修正语音学术语，避免直译英语

背景

目前中文维基百科中的语音学术语，特别是音素名称，多数是按英语直译而来。然而，这种做法并不符合汉语学术规范，也可能导致概念理解的偏差。为了提高条目的学术性和准确性，我提议将这些术语根据最新的学术规范进行修正。

权威依据

本提议主要参考了《方言》2007年第1期第1页刊载的国际音标中文版。该版本由中国语言学会语音学分会翻译，并于2011年被国际语音学会在《国际语音学会会刊》（Journal of the International Phonetic Association）第41卷第2期正式收录承认。这无疑是目前最权威的中文版国际音标。

以下内容引用自 unt 在知乎发布的国际音标表（官方中文版） 一文：

国际音标的最权威中文版当属《方言》2007 年第 1 期第 1 页所刊载的版本，这一版本由中国语言学会语音学分会翻译，之后被国际语音学会在《国际语音学会会刊》（Journal of the International Phonetic Association）2011 年（第 41 卷）第 2 期收录承认。表格如下：

International Phonetic Alphabet Chart (official Chinese version)

语音学术语小组成员

顾问小组：鲍怀翘、曹剑芬、黄泰翼、林茂灿、吕士楠、郑秋豫、王洪君、王嘉龄、王理嘉、徐云扬

工作小组：胡方、孔江平、李爱军、麦耘、陶建华、王蕴佳、熊子瑜、朱晓农

该图片为 unt 提取自国际语音学会官网 Translation of IPA charts 里 The chart of the International Phonetic Alphabet in Chinese (2007) 的 PDF。这个收集各语言翻译版国际音标表的项目“Translation of IPA charts”正是受上面中译版的启发而设立的。

表中有一些术语值得注意，人们常常会误用，或者使用过时术语：

  • p、b 一行叫爆发音（plosive），不叫塞音（stop）。塞音可以包括爆发音（“简单塞音”）和塞擦音（“擦除阻塞音”），而爆发音是更精确的术语
  • 拍音（tap）或闪音（flap）是两个术语，略有不同：拍音的主动调音器官的运动方向垂直于被动调音器官，闪音是平行于。通常 ɾ 是拍音，ɽ 是闪音
  • ʋ、ɹ 一行叫近音（approximant），其旧称无擦通音（frictionless continuant）已过时。原则上，无擦通音包括近音和元音。通音（continuant）是在此基础上再包括上擦音，是含义更宽的概念
  • s、z 一列叫龈音（alveolar），其旧称齿龈音已过时。现在，“齿龈”可以指齿音或龈音。特别注意，t、d、n、l 等辅音横跨三列，它们可以表示齿音、龈音和龈后音
  • ʃ、ʒ 一列叫龈后音（postalveolar），其旧称舌叶音已过时。现在，舌叶性（laminal）描述的是主动调音器官（见附加符号部分），而不是调音部位
  • ʘ、ǀ 一列叫啧音（click），旧称搭嘴音（但仍然通行），后来朱晓农又改作喌音（但尚未推广开）
  • pʼ、tʼ 一列叫喷音（ejective），其旧称挤喉音应当过时
  • ʍ、w 作唇–软腭音（labial-velar），ɥ 作唇–硬腭音（labial-palatal），ɕ、ʑ 作龈–腭音（alveolo-palatal）。特别注意，ʍ 是擦音而不是近音
  • 描述辅音的顺序是调音部位+(送气)+清浊+调音方法+“音”。语言学爱好者常常说清浊+(送气)+调音部位+调音方法+“音”，这是中文维基百科上机械照搬英文语序的结果，不提倡使用
  • 气声（breathy voice）和嘎裂声（creaky voice）两个发声态的译名确定了（表中是“voiced”所以是“声性”），嘎裂声的旧译紧喉音、喉化音等已过时
  • rhotic 译作 r 色彩（更直接对应的英文是 r-colored），也有人作 r 音色，其旧称卷舌（性）、带 r 意味的、r 化、儿化等已过时
  • no audible release 译作无闻除阻，也有人作无听感除阻，其旧译唯闭音已过时。语言学爱好者常常说“不除阻”，是不正确的，因为爆发音不除阻的话人就憋死了。有人译作无声除阻也不妥当，因为“无声”易被误解为不带声（voiceless）。特别注意，汉语入声韵尾并没有必要加无闻除阻符号，因为汉语的鼻音韵尾也是无闻除阻的

具体修改建议

基于以上资讯，以下条目名称可作以下修改：齿齿龈音建议修改为 齿龈音；浊小舌塞擦音建议修改为“小舌浊塞擦音”；浊小舌塞音建议修改为“小舌浊爆发音”；浊小舌擦音建议修改为“小舌浊擦音”；清小舌内爆音建议修改为“小舌清内爆音”；清小舌塞擦音建议修改为“小舌清塞擦音”；清小舌塞音建议修改为“小舌清爆发音”；清小舌擦音建议修改为“小舌清擦音”；

技术方面的考量

为了实现这些修改，似乎可以考虑利用Wikipedia:字词转换功能？这不仅可以保证术语的一致性，还能兼顾不同读者群体的阅读习惯。

结语

采纳这一提议将显著提升维基百科语音学相关条目的学术性和准确性。这不仅有利于读者更好地理解相关概念，也能够使我们的内容更加符合当前学术界的规范。我恳请各位编辑者认真考虑并支持这一提议。让我们共同为提升维基百科的学术品质而努力！--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年10月19日 (六) 18:13 (UTC)[回复]

(＋)强烈支持：很多年前就在知乎拜读过unt的这篇文章，一直想提议大幅修改……中文维基百科学科术语的原创翻译向来也十分猖獗，只是我最近暂时只将推进到限制专有名词原创翻译上面……不过，“最权威中文版”不排除可能有大陆地域中心的问题，对其他地区词来说还需要确认一下。另外，个别名词虽然存在学术规范，但也有其他常用名称（比如虽然“爆发音”可能更规范，但“塞音”也显然很常见、尤其是在和“擦音”对举的时候），这些也可能需要额外考虑。——自由雨日🌧️（留言｜贡献） 2024年10月20日 (日) 02:04 (UTC)[回复]
塞音虽然是常用名称，但既然已经过时了，在不涉及歧义时似乎就应该尽量替换。我觉得不用太考虑和擦音对举的问题，爆发音和内爆音还可以对举呢。--Sihjee（留言） 2024年10月25日 (五) 18:44 (UTC)[回复]
我是说（仅在）对举/并列时使用。--自由雨日🌧️（留言｜贡献） 2024年10月25日 (五) 19:00 (UTC)[回复]
(！)意见：直接转换要慎重。以及有些旧称的确更加通行到无法忽视。不过，将新译名作为标准条目名是合理的。--The Puki desu（留言） 2024年10月20日 (日) 10:24 (UTC)[回复]
很需要注意地区词转换及常用名称原则等问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年10月20日 (日) 13:23 (UTC)[回复]
(＆)建议&(～)补充：
  • 权威性和准确性：国际语音协会所接受的术语名称应被采纳，以确保术语的一致性和准确性。同时，对于常见且通用的俗称，如生物分类学中提供学名和俗称一样，或许可以考虑在条目中提及或设置重定向，以帮助读者更好理解，例如学名“龈颤音”俗称“大舌音”；而俗称“小舌音”可能指“小舌颤音”或“小舌擦音”，或许可以考虑重定向。
  • 尊重历史事实：为尊重历史上广泛使用的通用名称，或许当将规范名称作为标准条目名称，但在内容中提及这些通用名称；同时或许可以提及旧称及已废除术语并加以解释，使读者了解学术知识和思想的发展变化。
@自由雨日@The Puki desu@Ericliu1912--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年10月20日 (日) 17:21 (UTC)[回复]
@Ryanlo713：台湾等地地区词我不确定，不好说。就中国大陆地区词而言，我完全支持这一做法。我强烈地认为，在名称常用度没有数量级差异时，（学科术语方面）“规范性”原则应高于“常用性”原则。——自由雨日🌧️（留言｜贡献） 2024年10月20日 (日) 18:47 (UTC)[回复]
如果其他地区没有相应规范，应该可以直接按大陆规范统摄。而且这似乎也不是大陆部门的规范？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月21日 (一) 11:36 (UTC)[回复]
(～)补充：根据现有的讨论，我有一些疑问，包括：
  • 是否需要设置正式投票程式让更多编辑参与表决？
  • 是否需要组建一个专门的工作组来推进这项修改？工作组可以进一步研究各地区的学术规范，整理出一份详细的修改清单，制定具体的实施计划等。
  • 是否需要采取分阶段实施的策略？例如：
    • 第一阶段：修改争议较小的术语
    • 第二阶段：修改有一定争议但多数人支持的术语
    • 第三阶段：处理存在较大分歧的术语
  • 是否需要设置过渡期？比如过渡期内保留旧称的重定向，并在条目中注明新旧称谓，以便读者适应。
  • 如何将措施落到实处？可能包括：
    • 需要指定一位主要负责人来协调整个过程？
    • 需要制定详细的时间表和里程碑？
    • 需要利用机器人来协助大规模修改？
    • 需要加强与语言学专业人士的合作，确保修改的专业性？
    • 需要定期在社群中通报进展，保持透明度？
  • 是否还有其他方面需要考虑？
--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年10月22日 (二) 17:09 (UTC)[回复]
  • 没必要投票。我们几乎都不使用投票来确定共识（而是讨论），只有在涉及面非常广的重大争议性问题上才使用投票的方式快速征求意见？（且最终也并非会以投票结果决定。）在“互助客栈·条目探讨”这里讨论已经是涉及面非常大的讨论，我觉得足够了。如果还要继续扩大的话，可以用{{RFC}}和{{公告栏}}。
  • 也许可以进一步请对该问题感兴趣的编者讨论，比如语言学专题编者。
  • 视争议情况而定，确实可以这么做。
  • 重定向应该长期保留；旧称/别称视情况而定，单纯译法语序问题（如“清小舌塞擦音”）应该可以直接不写，但“塞音”等别称应该（长期）写。
  • 应该不用这么复杂吧……大家都是志愿者，有空就可以作“负责人”协调者（比如您）；时间表/里程碑我想就不必了；和专业人士的合作，如果可以做到的话，我想也一定是好事儿。机器人修改的问题，如果是“清小舌塞擦音 -> 小舌清塞擦音”这类改动应该没问题，不过有些术语（比如“塞音”）可能不适合全盘改掉（因为和“擦音”对举时仍常称“塞音”而非“爆发音”）。
--自由雨日🌧️（留言｜贡献） 2024年10月22日 (二) 17:21 (UTC)[回复]
我对技术实施方面不太了解。什么时候方便开始？--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年10月24日 (四) 18:21 (UTC)[回复]
@Ryanlo713：我看目前并没有反对意见。如果再过几天没有反对意见的话，可以认为形成了更改的共识。您可以直接改。如果担心有人没看到讨论改完又反对的话，可以先用{{公告栏}}公示。--自由雨日🌧️（留言｜贡献） 2024年10月24日 (四) 18:35 (UTC)[回复]
维基百科不是官僚体系，没这么多繁文缛节，要改就改。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月25日 (五) 04:08 (UTC)[回复]
已通知语言学、语言两专题，并邀请Unt Phesoca。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月25日 (五) 04:21 (UTC)[回复]
unt您是怎么邀请的😨--自由雨日🌧️（留言｜贡献） 2024年10月25日 (五) 04:29 (UTC)[回复]
用户讨论页 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月25日 (五) 04:46 (UTC)[回复]
😱她居然在这里！--自由雨日🌧️（留言｜贡献） 2024年10月25日 (五) 04:58 (UTC)[回复]
谢谢！我非常支持修改。在十几年前，维基百科采用的术语翻译确实是比当时大陆学界更先进的；但是近年来，大陆学界的语音学学者越来越多采用这个中译版国际音标表里的术语了，维基百科的一些术语就显得过时了，尤其还有齿龈音vs齿齿龈音这种脑筋急转弯。2021年我那篇知乎文章发布后，就曾有人提议过修改条目术语（当然，当时也有人反对），但最终未能进行。我想，此时不改，更待何时--Unt Phesoca（留言） 2024年10月25日 (五) 13:41 (UTC)[回复]
关于“塞音”和“爆发音”，现在中英文学界在一般行文里仍然多是用“塞音/stop”专指“爆发音/plosive”的（即，不包含塞擦音），但是如果是专门提及音素名称，那就要说“爆发音/plosive”而不说“塞音/stop”了，这样显得严谨。我想音素的条目名还是应该用“爆发音”，正文里面用“塞音”倒是问题不大--Unt Phesoca（留言） 2024年10月25日 (五) 13:51 (UTC)[回复]
@Unt Phesoca：谢谢大佬回复！我曾多次在其他平台以不同身份和您有过几次小互动，在这里见到您是最开心的。--自由雨日🌧️（留言｜贡献） 2024年10月25日 (五) 14:03 (UTC)[回复]
@书画昼尽告诉我其曾给中文维基百科增加过多个音素条目，或能协助修改。--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年10月25日 (五) 13:57 (UTC)[回复]
惭愧，我注册维基账号后最早一批编辑（2020年12月）就是对IPA表“查缺补漏”，补上实际语例或翻译新条目。巧的是，包含创建条目在内的工作恰是在UntPhesoca的知乎文章发布（2021年2月2日）前夕完成的😂😂，是很难立刻回头大改，于是也是成了“历史遗留”。
新条目的条目名，当时是比照现有条目名译的，而“现有条目名”本就是字字直译，于是有了en:voiceless velar lateral fricative -> 清软腭边擦音等等。至于内容，现在看来实在是草草而成，也是可以借此机会润色、改正。
书画昼尽（留言） 2024年10月26日 (六) 01:59 (UTC)[回复]
(＋)支持 但我认为denti-alveolar consonant译为“齿-龈音”更好，以避免译为“齿龈音”会出现的几个问题：①新旧术语混淆导致不必要的误解；②后人会很难判断近年的文章/论文中的“齿龈音”具体表示什么；③避免使用反直觉的名称(也能防止非专业人士望文生义)，毕竟现代汉语以双音节词为主，“齿龈音”明显更容易被理解为与“齿龈”有关而非与“齿和龈”有关。--Sihjee（留言） 2024年10月25日 (五) 16:13 (UTC)[回复]
另外希望可以在比较显著的位置保留保留“清…”“浊…”的译法，而非仅仅重定向，毕竟这种命名已经广泛应用多年了。--Sihjee（留言） 2024年10月25日 (五) 16:18 (UTC)[回复]
“清”“浊”的位置含义自明，或许不必尽标。而且一些非语言学来源的用法是松散的，如加逗号作“软腭，清，不送气，爆发音”，似乎不当作是成词--物灵（浪迹江关嗟路浅，周流天地觉风频。请向我留言） 2024年10月26日 (六) 10:53 (UTC)[回复]
关于连字符的使用，我认为需强调与双重调音术语加以区分。
这类术语的构成是两个形容词的结合，应该由 “–” (U+2013, En dash) 分隔。例如，图表中的“唇–软腭”指代的是 en:Labial–velar consonant，而 “denti-alveolar consonant”则不涉及双重调音，且其构成涉及词根并入，含义是其调音部位位于齿与龈之间。
另外我看图表中的 en:Alveolo-palatal consonant 中文译名“龈‐腭音”中的连字符和双重调音术语的有所不同，可能是 “‐” (U+2010, Hyphen) 或 “-” (U+002D, Hyphen-Minus)--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年10月25日 (五) 16:53 (UTC)[回复]
哈哈，en:Alveolo-palatal consonant用的是en:Hyphen-minus，明显是错误的，竟然一直没人发现。我旧号丢了，现在没有移动页面的权限，谁有空可以改一下。
Alveolo-palatal consonant和齿-龈音都应该用en:Hyphen。--Sihjee（留言） 2024年10月25日 (五) 17:10 (UTC)[回复]
(补充：我不确定英维中Hypen-Minus是不是acceptable的)--Sihjee（留言） 2024年10月25日 (五) 17:24 (UTC)[回复]
@Sihjee：英维要求使用hyphen-minus，禁止用hyphen，见en:Wikipedia:Manual_of_Style#Hyphens。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月25日 (五) 17:34 (UTC)[回复]
中维我记得也是禁止了？--自由雨日🌧️（留言｜贡献） 2024年10月25日 (五) 17:36 (UTC)[回复]
明白了，一直误解了。--Sihjee（留言） 2024年10月25日 (五) 17:37 (UTC)[回复]
另外我发现一文：MOS:连接号--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年10月25日 (五) 17:38 (UTC)[回复]
连接号区分了多个排版符号--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年10月25日 (五) 17:40 (UTC)[回复]
就是Hypen和emdash，中文不用endash有点可惜…--Sihjee（留言） 2024年10月25日 (五) 17:58 (UTC)[回复]
以下内容与语言和其分类命名相关，虽然与语音学术语无关，但或许可一同解决。
我想或许能邀请黑之圣雷和H Zhang加入讨论（如果可能）；两位都曾提及过一些小语种的命名问题，例如（不一一列举）：
--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年10月25日 (五) 18:09 (UTC)[回复]
目前确实用的是阿非利卡语和亚非语系。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月28日 (一) 16:33 (UTC)[回复]

基本有共识，建议再讨论一下“denti-alveolar consonant”是“齿-龈音”还是“齿龈音”。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年10月28日 (一) 16:44 (UTC)[回复]

个人无条件听从Unt Phesoca的意见。--自由雨日🌧️（留言｜贡献） 2024年10月28日 (一) 16:49 (UTC)[回复]
确实有一点讨论需要。用新术语的教材对于denti-alveolar、alveolo-palatal加不加连字符也并不一致：
  • 江荻译《国际语音学会手册》（2008）龈-腭（该书未出现denti-alveolar）
  • 张维佳译《语音学教程》（2011）龈腭（该书未出现denti-alveolar）
  • 朱晓农《语音学》（2010）齿－龈、龈腭
  • 张维佳、田飞洋译《世界语音》（2015）齿-龈、龈-腭
按我的理解，英文denti-alveolar、alveolo-palatal的连字符仅仅是起到分隔语素的作用，不具有特别的语义，也有零星著作使用的是dentialveolar、alveolopalatal。用汉字书写不存在“分隔语素”的必要，单从这个角度看，就没必要加连字符。不过，从实用的角度看，如上面Sihjee所说，“齿-龈”作为条目名更明确，我个人是赞同加连字符（另外，中译版国际音标表alveolo-palatal也译成带连字符的龈-腭，按这个体例denti-alveolar也要带连字符）--Unt Phesoca（留言） 2024年10月29日 (二) 00:47 (UTC)[回复]

一周无新意见，可认为有共识。建议先移动各辅音条目，以及涉及的发音页面、发音方法条目，并修改IPA条目和相关模板。至于其他页面提及、链入的旧术语的替换，经过站外（ac群）讨论，建议手动修理，而且这次没有新旧术语冲突，应该不会造成太大问题。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月5日 (二) 06:16 (UTC)[回复]

至于其他地区的地区词，仍然没有编者提出其他地区有相关标准的证据，可以暂时认为跟从IPA官方中文版的用词（用词按照正常繁简转换）。如果后来发现其他地区使用不一样的用词，建议再讨论使用字词转换。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月5日 (二) 06:18 (UTC)[回复]

执行修改

（一）音素

？

（二）调音方法和调音部位

需要移动的调音方法和调音部位
现标题 建议标题
塞音* 爆发音
闪音 拍音与闪音
齿龈音 龈音
齿齿龈音 齿-龈音
齿龈后音 龈后音
搭嘴音 啧音
挤喉音 喷音
唇软腭音（重定向） 唇-软腭音
唇硬腭音 唇-硬腭音
龈腭音 龈-腭音
日化元音 R色彩
无声除阻 无闻除阻
  • 其中塞音应该尽快改写为包含爆发音和塞擦音的术语。

 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月6日 (三) 15:06 (UTC)[回复]

“r色彩”似乎是小写？--自由雨日🌧️🌨️ 2024年11月6日 (三) 19:42 (UTC)[回复]
技术限制。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月6日 (三) 19:47 (UTC)[回复]
不是可以{{小写标题}}吗（）（看来“建议标题”指的是原标题？--自由雨日🌧️🌨️ 2024年11月6日 (三) 19:50 (UTC)[回复]
对，主要是我用的模板自动转大写（） ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月6日 (三) 19:52 (UTC)[回复]
还有这种模板思考... ——自由雨日🌧️🌨️ 2024年11月6日 (三) 19:54 (UTC)[回复]
不区分连字符的类型吗--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年11月7日 (四) 19:57 (UTC)[回复]
肯定是短横线啊（另外汉语叫连接号） ——自由雨日🌧️🌨️ 2024年11月7日 (四) 21:14 (UTC)[回复]
Wikipedia:格式手册/标点符号#连接号，构成复合名词，均用连字暨减号（U+002D）。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月8日 (五) 02:12 (UTC)[回复]
意思是 labial–velar 和 denti-alveolar 的处理方式都一致？如果按复合名词的话后者不算复合名词，因为 denti- 是不成词语素。--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年11月9日 (六) 18:24 (UTC)[回复]
但这里讨论的是“齿”，不过齿也不能成词。那也没法用一字线啊。那得改方针？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月9日 (六) 18:32 (UTC)[回复]
唇软腭音 唇硬腭音 龈腭音 应该不需要用连字符，望斟酌。
另外，拍音或闪音作标题似乎有些奇怪，拍音/闪音是否更好？这样在中文语境里更像个标题，也不影响实际意思。--Sihjee（留言） 2024年11月7日 (四) 21:07 (UTC)[回复]
为何不用？这里讨论的就是依照官方中文版 ——自由雨日🌧️🌨️ 2024年11月7日 (四) 21:15 (UTC)[回复]
哦对--Sihjee（留言） 2024年11月8日 (五) 07:23 (UTC)[回复]
2.我写的是拍音与闪音。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月8日 (五) 02:14 (UTC)[回复]
ok--Sihjee（留言） 2024年11月8日 (五) 07:27 (UTC)[回复]
还要修改Module:IPA_symbol/data。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月13日 (三) 11:20 (UTC)[回复]
我已经处理（二）中的页面。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年12月2日 (一) 19:12 (UTC)[回复]
塞音这样写可否？

塞音（英语：stop）广义上指气流受到阻碍的音，可能包括爆发音、塞擦音、喷音、啧音、鼻音、内爆音等。

狭义上，塞音指爆发音（plosive)。

（参照杨新璐《新疆维吾尔语方言语音类型比较实验研究》p.73-74）

——魔琴［身份声明 留言 贡献 新手2023］ 2024年12月2日 (一) 19:21 (UTC)[回复]

塞音已由重定向改为以上文本。 ——魔琴［身份声明 留言 贡献 PJ:NEW23］ 2024年12月8日 (日) 10:21 (UTC)[回复]
之前错写为爆破音，已改为爆发音。 ——魔琴［身份声明 留言 贡献 PJ:NEW23］ 2024年12月8日 (日) 10:25 (UTC)[回复]

次闭元音

标题为魔琴所加。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年12月2日 (一) 19:12 (UTC)[回复]
又发现了一个问题，“次闭后圆唇元音”明显存在错误，似乎应改为“次闭次后圆唇元音”，其他此类条目同理。--Sihjee（留言） 2024年11月16日 (六) 00:46 (UTC)[回复]
我没有移动页面的权限，只能拜托大家改了。--Sihjee（留言） 2024年11月16日 (六) 00:48 (UTC)[回复]
@Sihjee：能否给用例？《普通话水平测试实施纲要（2021年版）》写的是“后近高圆唇元音”（p.23），林焘、王理嘉《语音学教程》对/ɪ/的描写是“前、次高、不圆唇”（p.40）。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月20日 (三) 06:37 (UTC)[回复]
“International Phonetic Association (1999), pp. 13, 170, 180.” 与它不同的表述都应该看作错误的或过时的。
另外，其他语言(如英语)的维基百科都是同样的描述。--Sihjee（留言） 2024年11月24日 (日) 18:54 (UTC)[回复]
ping移动ɪ、ʊ、ʏ到现名的@TongcyDai询问移动原因。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月26日 (二) 12:18 (UTC)[回复]
线下咨询后对方表示可能是随英维移动。但是英维已经于2020年移回。现不挂布告板地 公示将次闭后圆唇元音、次闭后不圆唇元音、次闭前圆唇元音、次闭前不圆唇元音分别移动到次闭次后圆唇元音、次闭次后不圆唇元音、次闭次前圆唇元音、次闭次前不圆唇元音，为期6小时。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年12月2日 (一) 19:09 (UTC)[回复]
公示结束，上述页面已移动。 ——魔琴［身份声明 留言 贡献 PJ:NEW23］ 2024年12月3日 (二) 14:24 (UTC)[回复]
感谢--Sihjee（留言） 2024年12月5日 (四) 21:07 (UTC)[回复]

关于术语 accent、stress 和“重音”、“重读”的分歧

在语言学中，术语术语 accent、stress 和“重音”、“重读”常常引起混淆。以下是对这两个术语的定义和区别的探讨。
以下例子来自《语言学与应用语言学百科全书词典》

重音　stress　　语音学术语。指相连的音节中某个音节发音突出的现象。重音有通过增加音强来表示的力重音和通过音高的变化来表示的乐调重音。重音还可以分为词重音和句重音。❶词重音，指具有区别词汇意义的重音。多音节词中各音节的轻重往往确定不变。例如，英语begin［bɪˈgɪn］中，第二音节必须读重音；英语中，ˈrecord表示名词义，reˈcord表示动词义。轻重音有时候和语法也有关，在以多音节为主的语言中，重音的作用较为明显，可以分为固定重音和自由重音。固定重音指有的语言中重音总落在词的同一位置上，如捷克语重音总在词的第一个音节上，波兰语总在倒数第二个音节上，法语和维吾尔语的大多数词则在最末一个音节上。自由重音指有的语言中重音不限定于落在词的某一个音节上，不同的词重音位置各不相同，称为自由重音，如英语中的词重音。根据词重音的突显程度，词重音可以分出主重音和次重音。主重音的突显程度最高，次重音低于主重音但高于非重读音节。英语次重音一般只在词单说或在句尾才比较明显，在语流中和非重读音节差别不大。❷句重音，指在一个语句中突显程度最高的重音。句重音的分类在研究界没有统一意见，但一般至少有语法重音和逻辑重音两种。语法重音是指由句法结构和语义特点决定的重音，即不表现特殊的思想感情的自然重读。常念语法重音的如一般短句的谓语，名词、动词、形容词的修饰语，动词后由形容词或其他动词充当的补语，表示指代、询问或任指的代词等。逻辑重音是表现特殊的思想感情的强调重读。逻辑重音重于语法重音。有的学者认为逻辑重音是对比重音，有的学者认为逻辑重音是强调重音，有的则认为逻辑重音包括对比重音、强调重音等。参见“音高重音”。

重读　accent　　语音学术语，亦称重音。一种语音现象，指在语流中对某些语音或语段以明显的偏高音调、较大音量和较长发音时间的方式进行强调。重读既可指单词发音中的重读音节。例如，英语名词import的重音音节落在第一音节上，读作/ˈɪmpɔːt/，而动词import的重音音节落在第二音节上，读作/ɪmˈpɔːt/；也可以指一个句子中被突出强调的词，即句重音。例如：She was waving a yellow handkerchief.　此句中，重音落在不同的词上会对句子语义产生一定的影响，如果重音落在yellow上，说明她所挥动的是一块黄色而非其他颜色的手帕；如果重音落在handkerchief上，则说明她挥动的是一块手帕而不是其他东西。重音也经常用于节律学中对重读度的描写。例如，在对政治家的演说中进行相关分析时可以发现其重读度较一般话语强。

音高重音　pitch accent; musical accent　　语音学术语。通过音高变化体现差异的一种单词重音形式。这种变化一般分布在多个音节上。在音高重音的语言中，音调的变化可以是词的结构的一部分，用以区分不同的词义，塞尔维亚和瑞典语中就是如此。例如，瑞典语中的tanken一词，如果第一音节读成降调锐重音时，则为英语tank的意思；如果第一音节读成降升调钝重音时，则为英语thought的意思。参见“声调重音”。

乐音重音　chromatic accent　　语音学术语。参见“音高重音”。

音调重音1　chromatic accent　　音系学术语，亦称音高重音（pitch accent）。指语流中某一部分的音高与其周围的音高不同，从而形成了音调重音。

声调重音　tonic accent　　语音学术语，亦称音调重音或音高重音。指在一个由相连的声调所组成的声调群中，使其中某一部分的声调突出从而形成的重音。在一些语言中，声调重音可以存在于某个词的发音中，并用来区分不同的词义。譬如，瑞典语tanken，若将第一音节发成降调锐重音，则表示“坦克”；若将第一音节发成降升调钝重音，则表示“思想”“想法”。

搭配重音　collocation accent　　语音学术语。指对于具有相同词项的结构区别意义的不同的重音模式。例如：［1］ˈthree-hundred-meter-wide walls（宽三百米的墙）　［2］three ˈhundred-meter-wide walls（三堵宽一百米的墙）　［3］three hundred ˈmeter-wide walls（三百堵宽一米的墙）　三个例子中，分别通过重音确定了walls的定语，从而消除了歧义。

逆行重音　recessive accent; recessive stress　　语音学术语，亦称词首强重音。指音节的强重音由词尾向词首第一音节移动的过程。在历史音变过程中，逆行重音是英语名词的显著倾向。例如detail、cigarette、magazine、research等词原先的重音都在词末，但现在为词首重音。

重读力　accentual force　　语音学术语。指发音时形成重读音节的空气动力。

重音系统　accentual system　　音系学术语。指一种语言中有关重读的全部体系，包括重音级别、重音模式和重音的语义功能等。因重音在大多数情况下与语调结合而起作用，故亦称“重音语调系统”。

重音音位　accentual phoneme　　音系学术语。超音段音位的一种。当重音成为区别词义的唯一手段时，重音模式就成为语义上的区别性特征，即起到音位的作用。例如，suspect一词，当重音在第一音节上，其为名词，意即“嫌疑人”，而当重音在第二音节上，其为动词，意思是“怀疑”“猜想”。

重音模式　accentual pattern; accentuation　　音系学术语。指一个语段中轻重读的结构型。有语言学意义的重音级别一般有三级：主重音、次重音、弱音。在英语单词的发音中，单音节的词无重音标记，含有两个音节的词会有重音，含有三个音节的词会有主重音，含有三个以上音节的词可能会有次重音。例如，work是单音节词，其读音中无需重音标记；begin和apple是双音节词，重音模式分别为“轻—重”和“重—轻”；超过三个音节的词一般会涉及次重音。例如，transformation和nationality的重音模式都为“次重—轻—重—轻”。

动力重音　dynamic accent; dynamic stress　　语音学术语，亦称为吐气重音（expiratory accent）、加重重音（stress accent）或音势重音（intensity stress）。指以音强强调出来的重音，也就是以呼气强度强调出来的重音，如英语的词重音。现代语言中动力重音型语言比较普遍，如英、俄、德、法等语言皆是。广义上的重音（stress；accent）包括动力重音和音调重音（pitch accent）两种基本类型。音调重音指因话语中某一部分的音调和紧密相临的部分音调不同而造成的该部分的突出，如瑞典语和古希腊语。

重音转移　reverse stress; stress shift　　语音学、音系学术语。指某些单词或合成词在用于连续话语时所发生的重音变化，这一变化取决于该单词或合成词后是否紧跟有重读名词。一般而言，此类单词和合成词都有一个次重音（secondary）和一个主重音。例如，indeˈpendent。在连续性话语中，如果该单词或合成词带有语调重音，则该单词或合成词保持其原有的重音模式。例如：［1］Frank was ˈvery independent.　［2］This window is ˈplate-glass．如果independent和plate-glass后面的名词带有主重音，或者带有语调重音，那么independent第三个音节上的主重音和plate-glass上的主重音就会失去，第一个音节上的次重音就会变成主重音。例如：［3］Frank has ˈindependent means.　［4］It's a plate-glass ˈwindow（↘）

重音移位　stress shift　　参见“节奏规则”。

固定重音　fixed accent；fixation accent；fixed stress　　音系学术语。指语言中所有的词的重音总是落在固定音节上的现象。如法语的重音总是落在最后音节；匈牙利语通常重读单词的第一个音节；波兰语和威尔士语是在倒数第二音节上重读；拉脱维亚语和捷克语的重音落在第一音节。固定重音可以用来以音节为单位划分词的界限，如捷克语重读音节标志词的开始，波兰语每一重读音节后再隔一个音节标志词的结束，但当词末辅音与后一个词的首元音连读而组成一个音节时，词的界限就难以按固定重音准确划分。与自由重音（free accent）相对立。参见“自由重音”。

词末重音　final accent　　语音学术语。指落在单词最后音节上的重音。

——语言学与应用语言学百科全书词典
英语维基词典将 unstressed 定义为 not stressed or accentuated；stressed 又能翻译为“带重音的”和“重读的”。
但就单词 stress 在语音学的用途而言，具有两个不同含义，一个宽松一个严格。

6. (countable, phonetics, loosely) A suprasegmental feature of a language having additional attention raised to a sound, word or word group by means of of loudness, duration or pitch; phonological prominence.

Synonym: accent

Some people put the stress on the first syllable of “controversy”; others put it on the second.

7. (countable, phonetics, strictly) The suprasegmental feature of a language having additional attention raised to a sound by means of of loudness and/or duration; phonological prominence phonetically achieved by means of dynamics as distinct from pitch.

Synonym: stress accent

Antonyms: pitch, pitch accent

——Wiktionary
在这两种意义中，前者与 accent 同义，而后者则应视为 accent 的一种，前者有时被翻译为“力重音”。
使用“重音”和“重读”哪个更为合适？或者两者有不同分工？或者有其他更具体的翻译建议？--Σ>―(〃°ω°〃)♡→天邪弱（に〇〇する） 2024年11月10日 (日) 19:54 (UTC)[回复]
就这两个词而言：重音通常是语音层面的、结构性的，表示语音单位的突出。而重读更多是语用层面的，与说话者的意图有关(主观性较强)。二者的侧重点有所区别。
如果你要编辑条目的话，我的建议是条目名使用重音，可以在词条内分出力重音。重读重定向即可，可以在条目内描述一下二者的区别。--Sihjee（留言） 2024年11月11日 (一) 20:39 (UTC)[回复]

关于公司活动节目类条目的“所有权者”、“母公司”、“营运单位”的疑问

是这样的，U:SunAfterRain在较早前于本人讨论区讨论这件事，大约内容是 “B公司的社群媒体明言，他是属于A公司𣄃下的。而C节目的代理发行一栏，SunAfterRain提倡写B公司，因为没有证据证明A公司（也即B公司的母公司）有C节目的代理权。”由于讨论有点长，欢迎到我的讨论页浏览。

在讨论后的冷静期，我翻看了其他有类似例子的条目，如

有见及此，现希望就规范列出上述三项变数的条件

1. 如在条目或模版需要列出负责专案的品牌公司名称时，请列出至负责这个专案的“品牌名称条目”。

2.如相关品牌名称不被维基收录，请列出相关品牌的“上级机构条目”。

3. 如“上级机构”不被维基收录，请列出至相关品牌的“总公司条目”或 “占最大股份的公司条目”

换句话说，提案最终效果应像九广铁路及KKBOX风云榜一样以层递方式按步列出责任权。

而YouTube Premium的拥有人应写Youtube LLC。Youtube条目的拥有人应写Google LLC。Google条目的拥有人应写Alphabet。

假设香港大公文汇传媒集团条目不存在（包括没有名称的重定向），则可以大公文汇这个名称，定向至香港中联办。类似这样[香港大公文汇传媒集团l香港中联办]

关于母公司一栏，如没有来源证明某公司占股超过51%，则不应使用“母公司”一栏，只可使用“主要股东”一栏。

由于是次讨论影响所有涉及公司的条目，故放在这里讨论，以上！--唔好阻住我爱国（留言） 2024年10月20日 (日) 16:09 (UTC)[回复]

(！)意见：
  1. 如果是非公司品牌，建议与公司名并列（例如KKBOX（科科世界））
  2. 如果是公司，不应该（随便）把母公司写进资讯框（即只写香港大公文匯傳媒集團或九廣鐵路公司），但引言或者内文可以按情况详述有关关系（如香港中聯辦擁有的香港大公文匯傳媒集團、香港特區政府全資擁有的九廣鐵路公司等）。
( π )题外话：@SunAfterRain：ChatGPT是不可以拿来当来源的。您跟@HK5201314君讨论的是应该怎样纳入资料，这是需要可供查证的，不论ChatGPT是否基于大量已发布可靠来源来回答您的问题，它本质上是生成式AI，用它给答案就是原创研究。另外本人想点您给HK5201314君的连结进去，结果什么都看不到。
以上--派翠可夫 (留言按此) 2024年10月20日 (日) 16:52 (UTC)[回复]
@Patrickov：您拿生成式AI这点来说我，但对方根本没拿出任何能证明的东西啊？那凭什么他发表的“子公司有拿代理权代表母公司可以以母公司的身份随便碰”就是可以查证呢［特别是他还强调是常识］？（至于404就404吧，消失了我也救不了）--SunAfterRain 2024年10月20日 (日) 16:56 (UTC)[回复]
一事还一事。本人只是认为ChatGPT不能用来讨论此事，这跟哪个观点对、哪个观点错无关。另外，本人上面有就问题本身发表意见。--派翠可夫 (留言按此) 2024年10月20日 (日) 17:00 (UTC)[回复]
@Patrickov：如果您有更好的解方［指不是理论层面的解方］还请您指教一下方便日后改进，但如果无法有效破局法虽然知道GPT可信度不高但我也只能用GPT处理。（节删）--SunAfterRain 2024年10月24日 (四) 11:48 (UTC)[回复]
那本人也没有用GPT去帮自己构建留言或者证据啊……（不过更重要的是本人不懂得用）--派翠可夫 (留言按此) 2024年10月24日 (四) 17:49 (UTC)[回复]
又，本人就真的只是针对那一段话（以及HK5201314君在其下的问题）去回应，哪一部分让您认为本人否定您整个立场了？ -- 派翠可夫 (留言按此) 2024年10月24日 (四) 17:51 (UTC)[回复]
（节删），我只是想问您有没有更好的方法而已，--SunAfterRain 2024年10月24日 (四) 18:55 (UTC)[回复]
那本人就完全不明白那个温馨提示的用意了。--派翠可夫 (留言按此) 2024年10月25日 (五) 01:15 (UTC)[回复]
因为一堆人喜欢话中有话或是往奇怪的地方解读（没有要批评您的意思，但这真的是你维目前的通病）所以才打上去的 囧rz……--SunAfterRain 2024年10月25日 (五) 06:13 (UTC)[回复]
你是否在说商业名称？营运实体和商号，其实并不冲突。一堆上市公司注册地是“开曼群岛”之流，他们并不会视为开曼群岛公司。
有些情况，品牌是以部门的方式运作（事业部制），也可以视为一个营运实体，只是没有公司化营运。例如你讨论页里面提到的Ani-One，既是一个品牌，又可以视为羚邦的日本动画部门，--Nostalgiacn（留言） 2024年10月21日 (一) 05:29 (UTC)[回复]
如果按照@Patrickov的倡议，关于我讨论区例子，可以这样表达？
1.资讯框“Ani-One(羚邦集团)”
1.条目内文“Ani-One(羚邦集团)”
2.资讯框“回归线娱乐”
2.条目内文“智宝国际集团旗下的回归线娱乐”
那么，如果以KMB巴士公司作例的话，那句子将会很长
资讯框：“九龙巴士公司”
条目内文：“新鸿基地产旗下的载通国际旗下的九龙巴士公司”（当中新鸿基及载通也是上市公司；如果是需要讲述九巴路线与龙运巴士、皇巴士的转乘优惠+KMB会员系统The Point）
简单来说，如果欲就资讯框达成共识，首先是需要确保 “所有权者”及“营运单位”等可列出公司名称的变数于同一公司架构只可以列出一间公司或机构。如果是非公司品牌负责专案，则品牌与上级责任公司名并列。--唔好阻住我爱国（留言） 2024年10月21日 (一) 16:34 (UTC)[回复]
澄清一下：本人的看法是“如果是公司，不应该（随便）把母公司写进资讯框”以及“引言或者内文可以按情况详述有关关系”。具体一点说的话，本人是认为如果母公司对主题有重要性才需要提及。举例来说，九巴的巴士路线就不需要提及载通和新鸿基，除非是像九龙巴士268M线那种明摆着是为新鸿基旗下物业（峻峦）服务的，但即使是那样也需要可靠来源报导或提及此事才能写进去。--派翠可夫 (留言按此) 2024年10月22日 (二) 02:12 (UTC)[回复]
@Nostalgiacn：大概以我的论点解释一下原始的争议是怎么来的
因为木棉花、Ani-One等品牌从容易取得的资料来看其实无法确定属于哪间公司（可能财报有但我并不清楚，并且羚邦也没有一间名为Ani-One (公司)的公司），也无法从公开资料确定是由哪家公司向日方取得代理权（就算知道也没有写进来维基百科的意义，你维也不太可能出现木棉花动漫、木棉花创投、羚邦动画、羚邦娱乐之类的公司的单独条目），所以写集团没什么问题
但智宝先是成立了回归线娱乐，而且从7月开始的动画上面的版权浮水印都是“智宝国际集团的回归线娱乐”，最新集团的代理贴文（Archive.is的存档，存档日期2024-10-24）也未有再提及智宝国际开发，与上方无法明确确定的情况完全相反，基于不能臆测智宝国际开发到底有没有拿到代理权（有其他内部消息告诉我其实没有），如果要写公司应当写回归线娱乐而非如同其他代理商一样写智宝国际开发
当然我是觉得人家品牌写什么就写什么上去就好了就是了，不过要写公司的话回归线代理的实在不适合写智宝国际开发--SunAfterRain 2024年10月24日 (四) 12:14 (UTC)[回复]
写 “智宝国际集团”可以，但万万不能写“回归线娱乐”。论关注度，“回归线娱乐”在智宝国际集团体制下可不可以独立成一条条目？除了那个随时可被删走的动画列表及股权文件外，你可以找到一篇单独介绍“回归线娱乐”业务的文章吗？
所以回应下方@Milkypine：3M公司本身既是条目（即符合关注度要求），又是一个公司实体，所以不用写“ 明尼苏达矿业制造公司 ”。--唔好阻住我爱国（留言） 2024年10月24日 (四) 13:52 (UTC)[回复]
现在没有，不代表近一两年就没有机会出现足够关注度成条，但我举的那四个（以及类似状态的公司）我是不太相信五年内有机会独立成条--SunAfterRain 2024年10月24日 (四) 14:59 (UTC)[回复]
部门（事业部制）有关注度，可以写成条目，如腾讯游戏，品牌的话，中维有很多游戏品牌条目，如Key (游戏品牌)。羚邦我不熟，但是品牌、部门作为独立条目，在游戏专题是很普遍的。--Nostalgiacn（留言） 2024年10月24日 (四) 15:25 (UTC)[回复]
Ani-One基本上没有什么独立成条的机会啊...
"Ani-One" -site:wikipedia.org -site:wikidata.org -site:youtube.com -site:youtu.be -site:facebook.com -site:instagram.com -site:threads.net -site:x.com -site:twitter.com -site:medialink.com.hk -site:ani-mall.asia -site:ani.gamer.com.tw -site:acg.gamer.com.tw -site:catchplay.com -site:hamivideo.hinet.net -site:kktv.me -site:linetv.tw -site:litv.tv -site:mytvsuper.com -site:myvideo.net.tw -site:ofiii.com
--SunAfterRain 2024年10月24日 (四) 19:04 (UTC)[回复]
所以之后是要写成3M公司（明尼苏达矿业制造公司）吗？ --窝法乙烷 儿法梦碎 2024年10月22日 (二) 16:18 (UTC)[回复]
3M已是有知名度的公司，不需要。--派翠可夫 (留言按此) 2024年10月23日 (三) 03:58 (UTC)[回复]
KKBOX和内文讲的几家公司也是有知名度的公司，怎么他们需要，3M不用。不是很懂这突然跑出来的“知名度”又是啥标准。 --窝法乙烷 儿法梦碎 2024年10月23日 (三) 20:45 (UTC)[回复]
重点应该是公司，上面本人也说过本身是公司就不需要写，但本人在举例时KKBOX好像被说是品牌而不是公司。--派翠可夫 (留言按此) 2024年10月24日 (四) 17:46 (UTC)[回复]
@Patrickov：要把KKBOX当公司应该用KKBOX（愿境网讯）这种写法吧，毕竟人家公司有中文名？--SunAfterRain 2024年10月29日 (二) 16:30 (UTC)[回复]
其实现在KKBOX、科科世界、愿境网讯三者的关系为何？看了几条条目感觉叙述不太一致--派翠可夫 (留言按此) 2024年10月30日 (三) 02:26 (UTC)[回复]
@Patrickov：跟其他人交流了一下，大概是 KKCulture Co., Ltd. 科科世界 > KKCompany Technologies 科科科技 > KKBOX Taiwan Co., Ltd. 愿境网讯 > KKBOX 这样--SunAfterRain 2024年10月30日 (三) 13:46 (UTC)[回复]
@HK5201314：我想问一下“不被收录”的定义，是“连重定向都建不了”［译著：品牌不够有名导致连列在母公司的条目里作为一个章节存在都做不到］吗？还是一定要有条目存在？--SunAfterRain 2024年10月27日 (日) 05:27 (UTC)[回复]
抛多一个例子出来，大榄隧道资讯框。
.
业主
三号干线（郊野公园段）有限公司
营运单位
三号干线（郊野公园段）有限公司
.
要以可读性来说，写三号公司好还是其母公司新鸿基地产好？
即
“三号公司”
“三号公司（新鸿基地产旗下公司）”<—针对非条目公司，提案预期效果。
“三号公司”
.
这样说实际上是避免因为白纸保护而产生红链，从而对向上查证造成一定困难。重新导向可建又如何，只要改一改分段标题，重新导向连结即时失效，到最后就连连结哪也不知道。关于所有权者，使用重定向只会让读者难以理解为什么会这样定向。--唔好阻住我爱国（留言） 2024年10月27日 (日) 09:09 (UTC)[回复]
没记错的话目前是有机器人在修正这种断链，而且我不是很懂您说的难以理解重定向是什么意思，我不认为Ani-One重定向到羚邦集团#Ani-One这样会有什么奇怪的误会，希望您可以细说一下。（顺带一提，“三号干线（郊野公园段）有限公司”这种也算是建不了重定向的，建了重定向后你要重定向到主条目的哪个章节？）--SunAfterRain 2024年10月27日 (日) 17:41 (UTC)[回复]

修订

看来讨论僵住了，补一个修订草稿好了。
现提议对Wikipedia:格式手册/信息框新增一小节“所有权者、母公司与营运单位”，内容如下：

所有权者与营运单位 当在原作者、开发者、营运者、代理发行或类似栏位填写公司或品牌时，基于非原创研究方针，若官方使用品牌名称对外公告，请优先使用品牌名称；若官方使用公司名称对外公告，请优先使用公司名称。

使用公司／品牌名称时：

  1. 若该公司／品牌存在独立条目，抑或是不存在独立条目但所属母公司与其同名并存在独立条目，则仅列出公司／品牌，例如：“KKBOX”应列为“KKBOX”、“Google”应列为“Google”。
  2. 若该公司／品牌不存在独立条目，且所属母公司存在独立条目，则同时列出公司／品牌及其母公司，例如“Google APIs（英语：Google APIs）”应列为“Google APIs（英语：Google APIs）（Google的产品）”。
  3. 否则请同时列出公司／品牌及其“集团条目”或“总公司条目”或“拥有该公司/品牌绝对控制权的公司条目”，无论其是否存在独立条目，例如：“Ani-One”应列为“Ani-One（羚邦集团）”、“回归线娱乐”应列为“回归线娱乐（智宝国际集团）”。

此规则不适用于任何书籍或专辑本身，即使已被官方当成品牌看待。

@HK5201314、Patrickov、Milkypine、Nostalgiacn--SunAfterRain 2024年11月7日 (四) 11:38 (UTC)[回复]
7日无人反对，现 公示此提案7日至2024年11月29日。--唔好阻住我爱国（留言） 2024年11月22日 (五) 02:29 (UTC)[回复]
（注：此段会加入成格式手册指引，虽然不加这句应该不会造成误会但还是补充一下）--SunAfterRain 2024年11月24日 (日) 16:53 (UTC)[回复]
由于有文句解读争议，故暂停公示直到确认该争议实际上不存在或是需要修正条文而重计公示期--SunAfterRain 2024年11月28日 (四) 18:02 (UTC)[回复]
根据要求明确写出书籍不适用规则--SunAfterRain 2024年12月10日 (二) 13:29 (UTC)[回复]
第二次修改--唔好阻住我爱国（留言） 2024年11月10日 (日) 09:18 (UTC)[回复]
  • “当在原作者、开发者、营运者、代理发行或类似栏位填写公司或品牌时，若官方通常使用品牌名称对外公告，请优先使用品牌名称。使用品牌名称时，请按照以下方式填写：”—>“当在原作者、开发者、营运者、代理发行或类似栏位填写公司或品牌时，基于WP:非原创研究原则，若官方使用品牌名称对外公告，请优先使用品牌名称；若官方使用公司名称对外公告，请优先使用公司名称。使用公司/品牌名称时，请按照以下方式填写：”
  • 第三个例子改一改，不应使用动漫主题。
--唔好阻住我爱国（留言） 2024年11月7日 (四) 12:06 (UTC)[回复]
@HK5201314：那您举一下例子好了，我一时之间想不到；前面那个修了--SunAfterRain 2024年11月7日 (四) 14:40 (UTC)[回复]
辛苦了。暂时没有意见。--派翠可夫 (留言按此) 2024年11月8日 (五) 03:58 (UTC)[回复]
第三点在实际操作上很不合理，首先{{Infobox animanga/Novel}}是文库（label）和出版社分别列出的。
正常来说是KADOKAWA（出版集团）旗下角川书店（出版社）的角川文库（品牌名）。
出版社也是母公司的一部分，但是品牌要给出母公司名讳，我觉得更应该探讨这列出母公司到底意义何在？--Nostalgiacn（留言） 2024年11月9日 (六) 06:16 (UTC)[回复]
@Nostalgiacn:前提是该品牌/责任公司是没有独立条目且母公司有独立条目。如果是角川，根本不需要括号母公司。--唔好阻住我爱国（留言） 2024年11月10日 (日) 09:11 (UTC)[回复]
上面说得不太清晰，用角川这个例子，是因为角川的产品整个链条都是一体的，由条目，方便理解。不同文化产品上，专辑有厂牌和发行商，书籍有丛书/文库和出版社。起码在图书出版时，丛书，读者更关注源于那个出版社，而不是属于哪个母公司（出版集团）。个人认为，起码在图书出版上，列出母公司意义不大。--Nostalgiacn（留言） 2024年11月12日 (二) 04:50 (UTC)[回复]
@Nostalgiacn：你举的例子，角川书店和角川文库都是独立条目，所以根本不会列到母公司，而且我不认为角川如果明天突然建立一个ABCDEF书店之类的出版社，列出版社会有人知道是哪个集团就是了（而且出版社也是公司吧，有出版社条目的也会走到第二条就终止吧？）--SunAfterRain 2024年11月12日 (二) 05:14 (UTC)[回复]
角川书店是KADOKAWA其中一个出版社，KADOKAWA还收购了很多出版社。我上面的问题是“丛书，读者更关注源于那个出版社，而不是属于哪个母公司”。给出角川这个例子，是因为都有条目，方便说明理解。--Nostalgiacn（留言） 2024年11月12日 (二) 06:07 (UTC)[回复]
OK! 换一个说法，假如这里有一本书，叫“他的名字”，由 ABCDEF书店 出版。
问题来了！ABCDEF书店 是什么的书店？为什么他出的书在社群间的影响这么大，ABCDEF书店还有什么书？
翻查资料，原来是 KADOKAWA的一个出版商，这个ABCDEF书店在网上的资料只有“ABCDEF书店是KADOKAWA的一个出版商”，没有其他了，所以没有可能为ABCDEF书店建立条目。
接下来，按照正常做法，ABCDEF书店会被重定向至KADOKAWA，因为有这个来源“ABCDEF书店是KADOKAWA的一个出版商”。
你说“他的名字”是KADOKAWA出的？又不是。所以不可能是使用“重定向”功能把ABCDEF书店连结至KADOKAWA，但要确保读者知道ABCDEF书店是与KADOKAWA有关。故有选项2及3。--唔好阻住我爱国（留言） 2024年11月15日 (五) 11:20 (UTC)[回复]
@Nostalgiacn：我认真思考了一下，你维应该是不太可能出现需要列出“作品（出版社）”的情况吧？如果是什么改编动画的条目那也是要主条目过长才会拆分，所以一定符合第一条规则。而列出出版社的情况大概也只有两种，“出版社”和“出版社（集团）”，如果那个出版社这么不有名以至于根本没有条目，读者看了出版社名字大概也不认识，我觉得这时候列集团应该算是一个适当的行为。--SunAfterRain 2024年11月22日 (五) 05:56 (UTC)[回复]
列出“作品（出版社）”是非常普遍的，只要按规范指引列出来源，只有是出版刊物，在使用cite系列模板时都有参数publisher，让你填出版社。
cite系列模板其实是根据传统论文引用来源格式，无论是美国的《芝加哥格式手册》，中国《信息与文献　参考文献著录规则》，引用来源要求，只求出版社，根本无需出版社的所属集团。
换句话，你建议的这个规则，在出版刊物范围上，是违反既有习惯。--Nostalgiacn（留言） 2024年11月23日 (六) 13:07 (UTC)[回复]
我要重申，“建议的这个规则”主要针对缺乏关注度的出版单位，并在资讯框显示，而不是在cite模版显示。你维又真的可以确保所有在维基资讯框的出版单位也有条目？--唔好阻住我爱国（留言） 2024年11月23日 (六) 14:06 (UTC)[回复]
@Nostalgiacn：这个修订只有要规范资讯框，修订的页面我写得很清楚了，是Wikipedia:格式手册/信息框，没有要更动cite系列模板啊，您是不是误会了什么？--SunAfterRain 2024年11月24日 (日) 16:46 (UTC)[回复]
上面我是以来源的格式，来证明“所属集团”并不是强制要求，以此来支持inbox模板出版社不标记“所属集团”。我指出的依旧是“丛书，读者更关注源于那个出版社，而不是属于哪个母公司”这个观点。
你们就算说“你维应该是不太可能”和“出版社这么不有名以至于根本没有条目”，不妨碍出版刊物传统上根本不注重“所属集团”的做法。--Nostalgiacn（留言） 2024年11月25日 (一) 09:02 (UTC)[回复]
你有这个见解是因为前人已做了重定向工作，例如把那个ABCDEF出版商定向至KADOKAWA。但是，显然地，那个作品不是KADOKAWA出版，那在说明责任权时为什么会关连至KADOKAWA？在关于责任权方面，我是反对使用重定向功能强行把缺乏关注度的出版商连结至 所属集团，因为你说不清两者的关系，为什么会这样连结，当中有没有原创研究成分，会不会窒碍读者辨别重定向关系。
Let’s say如果改成“在责任权方面，严禁使用重定向功能把责任定向至其他公司或品牌”+没有第二及第三，我是接受的，唯会不会影响条目的观感是另一个问题。--唔好阻住我爱国（留言） 2024年11月25日 (一) 11:41 (UTC)[回复]
你是否误解我的观点？inbox模板出版社不标记“所属集团”，我反对的是提案若该公司／品牌不存在独立条目，且所属母公司存在独立条目，则同时列出公司／品牌及其母公司。
我的意思就是，就算有“出版集团”（母公司），也没有列出的必要，这不符合既有做法。KADOKAWA的例子是为了说明，出版集团、出版社、公司和品牌之间的层级关系。与你说重定向与否无关，我上面说的是，出版刊物，无法发行商哪一个层级是否存在条目，列出“出版社”就可以了。没必要因为“出版集团”（母公司）存在，出版社或者丛书自身无条目，而要同时列出“母公司”。--Nostalgiacn（留言） 2024年11月26日 (二) 10:00 (UTC)[回复]
问题是，真的会有出版刊物被视作品牌，然后因为没有条目所以走到第三条吗？？？--SunAfterRain 2024年11月26日 (二) 14:52 (UTC)[回复]
仅以出版刊物而言，“丛书”（品牌）就是作品这个情况，如《中国语言生活绿皮书》。
inbox标记项目是“文库”{{Infobox animanga/Novel}}或“系列”{{Infobox book}}的方式，如果以你现在若该公司／品牌不存在独立条目，且所属母公司存在独立条目，则同时列出公司／品牌及其母公司。，就会出现“中国语言生活绿皮书（商务印书馆）”，这种情况。
上文我已经KADOKAWA的情况举例，请仔细看一下出版集团、出版社、公司和品牌之间的层级关系。
下面不妨再展开一下，音乐专题最近就“label”指什么展开讨论，事关到底指出品方、发行方、出版方、还是厂牌。这个提案既然想一刀切大一统，也请留意一下音乐发行上相关概念和标记传统。--Nostalgiacn（留言） 2024年11月27日 (三) 06:15 (UTC)[回复]
@Nostalgiacn：不，其实我很想说出版刊物跟音乐其实根本不算品牌，哪有东西既算产品又算品牌然后还要扯到条目问题的....（而且既然发展到转变成品牌来看待了，我不觉得还需要用那种模式看待，而且我真的不相信都变成品牌还能写进条目了还会出现尴尬到必须走到第三条的情况）--SunAfterRain 2024年11月28日 (四) 17:59 (UTC)[回复]
你是提议在Wikipedia:格式手册/信息框增加的内容，现在说这不适用，那不适用。那么是不是你提议“增加的内容”本身有问题，有不清晰的地方。
如果建议的内容只适用于特定的内容，就不要加到通用的“格式手册”，而是“特定主题”的格式手册。--Nostalgiacn（留言） 2024年12月2日 (一) 06:23 (UTC)[回复]
建议的内容只适用于资讯框，然而阁下扯至条目内文，是在哈啰？--唔好阻住我爱国（留言） 2024年12月2日 (一) 16:30 (UTC)[回复]
{{Infobox album}}label:此栏仅需填入最初发行专辑的唱片公司即可。
xxxx
换言之，那间唱片公司缺乏关注度，用第二及第三说明这个是什么公司，也没有与专题抵触。--唔好阻住我爱国（留言） 2024年12月2日 (一) 16:37 (UTC)[回复]
音乐的讨论，建议到音乐专题讨论，谢谢。--Nostalgiacn（留言） 2024年12月3日 (二) 05:30 (UTC)[回复]
我很想吐槽，一般人会把出版刊物和音乐全部当成是品牌的一种吗，这难道不是阁下联想力太丰富了吗...？--SunAfterRain 2024年12月3日 (二) 18:48 (UTC)[回复]
还有Wikipedia:格式手册/信息框本来就是一个特定主题的格式手册了，谢谢您。--SunAfterRain 2024年12月3日 (二) 18:53 (UTC)[回复]
我引用的“特定主题”的格式手册，是指{{Style}}上的分类方式，也就是维基百科:格式手册/电子游戏一类。
Wikipedia:格式手册/资讯框是属于“内容”，就是面向所有条目的格式指引。我不妨把话说明白点，就是因为你的方案处理不了出版刊物的问题，所以不适用于通用的“格式手册”。
希望你真的认真看一下相关内容，不要仓促回应。这样只会显得你的提案考虑不足。--Nostalgiacn（留言） 2024年12月4日 (三) 15:10 (UTC)[回复]
如果阁下坚持这样理解，那只好建议阁下提出把资讯框拆分至不同的“特定主题”的格式手册，按照每一专题量身打造各至的资讯框手册。在现行架构，所有专题的资讯框是under 资讯框手册规管，无一例外。单按照上方由阁下提出的三中商例子，“中国语言生活绿皮书（商务印书馆）”，这个就是预期效果。正确来说，除了中国文学爱好者外，没有人认识“中国语言生活绿皮书”，唯一般人也认识商务印书馆（因为达关注度要求而有条目）。这个动作是一个便民措施，而不是没有列出的必要。这个提案显然是更改既有做法（摆明这个旧有俗成有明显问题-我如何准确知道这是什么公司？）--唔好阻住我爱国（留言） 2024年12月4日 (三) 18:14 (UTC)[回复]
此提案从头到尾都没有要解决出版刊物的问题，您现在这是鸡蛋里挑骨头吗？往规范品牌与公司的条文钻出版刊物的漏洞，很好玩吗？提案要规范的是资讯框里的栏位，干嘛放到别的地方去？还有那几个栏位什么时候可以放出版刊物了......--SunAfterRain 2024年12月6日 (五) 03:57 (UTC)[回复]
@Nostalgiacn：如果您要坚持这个观点，我更想请您举例在这次变更通过后，什么时候infobox会需要做到注记“书名（出版社／母公司）”的情况，并且真的有条目受到此次变更波及。我觉得假设有条目将会受到波及实在不是个好做法，既然连现在都用不到了，那未来更不可能出现这种用法。--SunAfterRain 2024年11月25日 (一) 14:51 (UTC)[回复]
想问一下，所有权一半一半的该怎么写？以JW Anderson（英语：JW Anderson）、Fenty Beauty（英语：Fenty Beauty）为例，我该写成原作者（JW Anderson、Fenty Beauty）还是持有另一半股权的公司、集团（JW Anderson、Fenty Beauty）？当然还有像梅赛德斯AMG车队这种3人、公司、集团持有的 --窝法乙烷 儿法梦碎 2024年11月8日 (五) 14:37 (UTC)[回复]
其实我较为主张“绝对控制权（超过51％股权或体制内的企业／品牌”才可使用第3项的括号部分。启动目的是让读者知道谁作出这些决定+知道为什么会连结至那个条目。如果是各一半的话，正常也无法确定相关决策是谁负责，情愿不写括号会较合适。况且如那个品牌/公司有条目的话，根本不需要有括号公司。--唔好阻住我爱国（留言） 2024年11月8日 (五) 15:13 (UTC)[回复]
@Milkypine：没有过半应该连子母公司都说不上，所以我觉得这个应该没什么争议--SunAfterRain 2024年11月8日 (五) 15:53 (UTC)[回复]

我建议提案者，重新审视提案内容的在不同范畴的可行性，在修订出更好版本后，再继续进行讨论，谋求共识。我指出的一些范畴使用上存在问题，辩倒我是没意义的，这只是“解决提出问题的人”，问题依旧没有解决。--Nostalgiacn（留言） 2024年12月4日 (三) 15:19 (UTC)[回复]

然而阁下没有就每一范畴提出确实例子，很难判定阁下的回应是正当合理还是为反对而反对。--唔好阻住我爱国（留言） 2024年12月4日 (三) 17:58 (UTC)[回复]
然而阁下这是在条文本身就没有要触及的地方钻牛角尖，从头到尾都没有真正对条文要规范的地方发表有意义的意见。--SunAfterRain 2024年12月6日 (五) 03:59 (UTC)[回复]
@SunAfterRain:
不如这样，公示结束、通过并结束讨论吧！在这样持续被他拖延也不是办法。那个反对者只是玩程序问题，而且相关发言不是有助改善提案，而且没有任何改善建议。--唔好阻住我爱国（留言） 2024年12月6日 (五) 06:52 (UTC)[回复]
自11月9日，个人提出“第三点在实际操作上很不合理”，到现在差不多一个月，你们没有作为任何修订。现在又要强推共识结束，我真的无语了，我举例KADOKAWA各个层级都有条目，证明理论上各个层级都可以写成条目，但是其他出版社并不具备这个条件，或者说大部分都没有条目若干环节有不存在条目的情况，以提案的处理，就是会出现一些奇怪的状态。
由始至终我都认为“否则请同时列出公司／品牌及其“集团条目”或“总公司条目””的做法，违反了出版刊物的常用习惯。{{Infobox animanga/Novel}}是同时存在label/文库/丛书（品牌）、出版社的栏目，日本轻小说大部分都有文库，明明是一个很常见的情况，上面居然说是“钻牛角尖”、“鸡蛋里挑骨头”。KADOKAWA的文库有条目，不代表其他日本出版社的文库都有条目。而且小说模板已经有出版社的栏目，列出相关出版社就行了，无需在品牌列出“集团条目”或“总公司条目”。--Nostalgiacn（留言） 2024年12月6日 (五) 07:51 (UTC)[回复]
我们仅接受维基百科:建设性意见格式的意见，即如何改善提案。而不是单单为了一个专题而无视其他没有这个问题的专题。
针对 “否则请同时列出公司／品牌及其“集团条目”或“总公司条目”或“拥有该公司/品牌绝对控制权的公司条目”，无论其是否存在独立条目，”一看而知，同时列出即可，后方是只是其中一个列出格式例子。如果上面有，下面也有，那不是同时列出还能什么？--唔好阻住我爱国（留言） 2024年12月6日 (五) 08:51 (UTC)[回复]
我上面在修订出更好版本后，再继续进行讨论，谋求共识不就是维基百科:建设性意见的“建议作为指引/再修改一下某段/先讨论一下某问题已取得共识”。我个人的观点很明确，就是对“第三点在实际操作上很不合理”。你们完全可以搁置第三点，通过第一和第二。--Nostalgiacn（留言） 2024年12月8日 (日) 10:35 (UTC)[回复]
这个提案根本没有在规范出版刊物，是在违反什么常理？这不是“钻牛角尖”、“鸡蛋里挑骨头”不然是什么？您觉得有需要可以另外开一个讨论串，而不是自己在心中扩大别的提案的解释然后再说提案违反常识。--SunAfterRain 2024年12月6日 (五) 11:55 (UTC)[回复]
提案原文是当在原作者、开发者、营运者、代理发行或类似栏位填写公司或品牌时。
我上面重复说了好几次，丛书/文库就是“品牌”，如日本角川（KADOKAWA）旗下轻小说品牌“电击文库”（[16]）。丛书/文库具有双重属性，既是出版刊物系列，也是品牌。提案就是会影响到相关infox（如{{Infobox animanga/Novel}}）上栏目的填写。--Nostalgiacn（留言） 2024年12月8日 (日) 10:44 (UTC)[回复]
试说明如何影响，谢谢！--唔好阻住我爱国（留言） 2024年12月8日 (日) 12:54 (UTC)[回复]
例如label写“电击文库”， 出版社写“KADOKAWA”，这个效果及目的是与提案预期效果及目的也是一致，按照WP:常识，也没有问题。--唔好阻住我爱国（留言） 2024年12月8日 (日) 12:58 (UTC)[回复]
你可以去看看既有的轻小说条目里面，是怎么填的（如电击文库#作品一览）。出版社并不是填“KADOKAWA”。--Nostalgiacn（留言） 2024年12月9日 (一) 11:57 (UTC)[回复]
那显然那些编辑者在填写变数前没有看清楚技术文件，阁下贵为资深编辑者，有责任跟进及指导初级编辑者须跟从技术文件指示填写相应变数。--唔好阻住我爱国（留言） 2024年12月9日 (一) 13:35 (UTC)[回复]
@Nostalgiacn：请给出你的来源证明丛书一定是品牌；文库还请您举出不存在同名公司的例子，不然我不觉得“电击文库”和“电击文库（KADOKAWA）”这两种写法有什么太大违反常识的问题。--SunAfterRain 2024年12月9日 (一) 07:04 (UTC)[回复]
“范军将出版品牌定义为出版社所拥有的品牌，包括单本书品牌、丛书品牌、类别书品牌和出版社整体品牌”[1]。
出版社的自身的描述多得是：人教“品牌丛书”、“汉译世界学术名著丛书”是商务印书馆最为知名的社科学术丛书品牌、大型品牌丛书《21世纪作家精选文丛》组稿启事、广西师大社知名品牌“文学纪念碑”丛书又推新品、中国有话说多语种系列丛书 品牌启动仪式在海南举行
你认为没问题，请见上面我说的引用来源要求，只求出版社，根本无需出版社的所属集团。换句话，你建议的这个规则，在出版刊物范围上，是违反既有习惯。，列出“出版社”就可以，小说模板已经有出版社的栏目，列出相关出版社就行了，无需在品牌列出“集团条目”或“总公司条目”。--Nostalgiacn（留言） 2024年12月9日 (一) 11:53 (UTC)[回复]
好，等下我把丛书加进例外；你现在还在偷换概念是吧，讯息框≠引用来源，有什么好违反习惯的？你从头到尾都在说不符合引用来源习惯，但我根本没看见洽当的理由为什么讯息框得尊重你讲的习惯。--SunAfterRain 2024年12月10日 (二) 13:22 (UTC)[回复]
（上面词懒的更正了）资讯框是给一般读者读的，你讲的引用是要字数少但能表达清楚，自然不能直接把引用的习惯直接套来资讯框。--SunAfterRain 2024年12月10日 (二) 13:39 (UTC)[回复]

参考资料

  1. ^ 饶广祥,李佳逊.出版品牌:基于出版沟通的符号进路[J].现代出版,2024(2):66-76

关于拜占庭皇帝的条目标题

本主题或以下段落文字，在讨论结束后应存档至Talk:拜占庭皇帝列表。

根据陈志强等人新近出版的《拜占庭帝国大通史》，我认为有必要对有些拜占庭皇帝的条目标题做出更改。中文维基百科上的拜占庭皇帝译名是二十年前爱好者根据自身喜好翻译，现在看来有些已与目前的相关中文书籍的通用译名不符。比如Ἡράκλειος的Ἡ读伊的音，伊拉克略比希拉克略更合适。Μιχαήλ的读音接近米哈伊，而不是米海尔。Βασίλειος 的读音类似瓦西里奥斯，其中Βα读哇的音而不是巴，瓦西里比巴西尔合适。Ζωή的读音类似于邹伊的急读，邹伊比佐伊更合适。Ανδρόνικος 的κος的读音接近于库斯，而不是卡，所以安德罗尼库斯比安德洛尼卡合适。而且罗马皇帝后期出自不同家族，比如约翰五世·帕列奥列格比约翰五世 (拜占庭)适合当条目标题，约翰六世·坎塔库震努斯比约翰六世 (拜占庭)更适合当条目标题，因为他们生前，帕列奥列格和坎塔库震努斯的姓氏比他们的名字约翰更常用。由于有些书籍翻译译名时，直接照搬中文维基百科的现有译名，以至于有些不伦不类的译名流传很广，影响很不好。我认为，有必要将拜占庭皇帝的条目标题更正为学界的常规译名。

《拜占庭帝国大通史》：索菲亚连哄带骗让查士丁于574年12月7日任命提比略为凯撒，还确定后者为嗣子，封他为凯撒和共治皇帝，取名为提比略·君士坦丁（Tiberius Constantine，后来他在官方文件中使用该名）​。

黄煜文译 贝塔妮·休斯《伊斯坦布尔三城记》：578年到582年提比略二世·君士坦丁

《拜占庭帝国大通史》：伊拉克略的早年生平较为模糊，根据史料的零星记载，伊拉克略的父亲也称伊拉克略（下称老伊拉克略）​，曾在拜占庭帝国担任非洲总督，母亲是埃皮法尼娅。

陈志强《科索沃通史》：拜占庭皇帝伊拉克略联合克罗地亚人和塞尔维亚人进攻阿瓦尔人。

罗三洋《横行草原的柔然——从黄河到莱茵河》：他被叛兵在皇宫内抓获，押送到迦太基（Carthage，突尼斯）军阀伊拉克略（Herakleios）的战舰上。伊拉克略指责福卡斯祸国殃民，后者死到临头反而笑道：​“那你的统治又能多好？​”

《拜占庭帝国大通史》：皇帝与长子伊拉克略·君士坦丁的并排胸像，前者居左，留络腮胡，后者较小，时间在613—631年；这种类型的索里达上伊拉克略·君士坦丁的形象从很小逐渐变大，直至与父亲肖像等高。

《拜占庭帝国大通史》：伊拉克洛纳斯全名弗拉维乌斯·康斯坦提乌斯·伊拉克略(Flavius Constantius Heraclius)，又被称为伊拉克略二世，生于君士坦丁堡，卒于帝国皇宫。

《拜占庭帝国大通史》：康斯坦斯二世全名伊拉克略·康斯坦提乌斯(Heraclius Constantius)，受洗时的教名是伊拉克略，但加冕时使用的名字是君士坦丁，民众称其为康斯坦斯。

A.A.瓦西列夫《拜占庭帝国史》：仅仅根据这些新的情况，我们完全可以解释康斯坦斯二世为何希望离开君士坦丁堡，将首都迁回到古罗马城或意大利的其他地方。

《拜占庭帝国大通史》：关于利奥提乌斯的早年生平，学界知之甚少，零星的史料显示利奥提乌斯生于伊苏里亚，曾在查士丁尼二世统治时期担任军队将领。

陈志强等译《牛津欧洲史：中世纪风云三部曲》：利奥提乌斯虽然非常聪明且精力充沛，但是他却成为拜占庭历史上第二个废黜合法皇帝的人，那位制造灾难的前辈是602年的福卡斯。

陈高明、刘茹《拜占庭艺术：永恒的精神》：695年，一场反对查士丁尼二世统治的起义闻风而起，他也因此被推下了皇位，希腊军区的将军利奥提乌斯(Leontius)被拥为皇帝。

席代岳译《罗马帝国衰亡史》：利奥提乌斯是位赫赫有名的将领，有3年多的时间在黑暗的地牢里呻吟，同时服刑的还有几位出身高贵和功勋卓越的大公。

《拜占庭帝国大通史》：菲利彼库斯原名为巴登斯，因而又被称为菲利彼库斯-巴登斯。

A.A.瓦西列夫《拜占庭帝国史》：亚美尼亚人瓦尔丹（Vardan）或菲利彼库斯（Philippicus，711—713年在位）​、

《拜占庭帝国大通史》：关于塞奥多西三世成为皇帝之前的事迹，史料中只提到他是阿德拉米提翁的一位政府税收官。

《拜占庭帝国大通史》：769年，利奥四世同其父为其挑选的新娘——来自雅典的姑娘伊琳妮结婚。

任九菊译爱丽丝·巴尔内斯·布朗《萤火虫全球史051·拜占庭帝国》：雅典的伊琳妮作为第一位独立统治罗马的女性，伊琳妮的执政方式令人惊叹

《拜占庭帝国大通史》：斯达乌拉焦斯出生于778年之后，早年的生活不详，其父亲是尼基弗鲁斯一世，母亲情况不详。

齐建晓译查尔斯·欧曼《拜占庭帝国史：从拜占庭建城到君士坦丁堡陷落》：尼斯福鲁斯一世的独生子斯达乌拉焦斯宣称自己为拜占庭帝国皇帝，但他伤势越来越重，濒临死亡。

《拜占庭帝国大通史》：大约791年，尼基弗鲁斯将女儿普罗柯比娅嫁给年轻的贵族米哈伊尔·拉加贝(Michael Rhangabe)，即后来的皇帝米哈伊尔一世。

刘文孝《拜占庭文学史》：此书内容，正如其副标题说的，其记叙开始之处，也就是格奥尔基奥斯停笔之处，即284年罗马元首戴克里先登位，然后一直写到813年米哈伊尔一世拉加贝（Μιχαῆλ A'Ῥαγγαβέ，770—844年）退位。

《拜占庭帝国大通史》：这其中便包括“亚美尼亚人”利奥和“阿莫里人”米哈伊尔，即未来的拜占庭皇帝利奥五世和米哈伊尔二世（Michael Ⅱ，820—829年在位）​。

李达译John Julius Norwich《拜占庭的巅峰：从光复时代到曼齐刻尔特》：然而米哈伊尔二世的麻烦还没有结束。

《拜占庭帝国大通史》：米哈伊尔三世的父亲是塞奥菲鲁斯

维克多·斯宾内（Victor Spinei）著 孙昊、卢兆瑜译《东方视角下的11—12世纪巴尔干民族状况：叙利亚的米哈伊尔》：塞奥菲鲁斯（Theophilos，829—842）即位后，保加利亚人“向他称臣”​（III，50 and 73）​，这段记载——也像对于战略家利奥远征的记载一样——在《编年史》两个地方重复出现，显然是由于作者的疏忽所致。

《拜占庭帝国大通史》：米哈伊尔三世自幼任性，长大了肆意妄为，最终利用手中的皇权抓捕塞奥多拉和他自己的亲姊妹们，强行削去她们的头发并关入加斯特里亚(Gastria)修道院。

李达译John Julius Norwich《拜占庭的巅峰：从光复时代到曼齐刻尔特》：与此同时，皇帝米哈伊尔三世正在长大。

《拜占庭帝国大通史》：这样，经过马其顿王朝作家近两百年的努力，米哈伊尔三世的丑恶嘴脸和瓦西里一世的高大形象便确立起来。

A.A.瓦西列夫《拜占庭帝国史》：新任皇帝瓦西里一世在其上台伊始，即废黜了佛提乌的教职，请回伊格纳修斯重新担任君士坦丁堡牧首。

《拜占庭帝国大通史》：Romanos Ⅰ Lekapenos 罗曼努斯一世·雷卡平

A.A.瓦西列夫《拜占庭帝国史》：而当919年，当政权转移到君士坦丁的岳父罗曼努斯一世·雷卡平手中时，佐伊被送进修道院，尼古拉斯·米斯提克斯再次复职。

《拜占庭帝国大通史》：尼基弗鲁斯二世·福卡斯（Nikephorus Ⅱ Phocas；Νικηφóρος Β'Φωκς；生于912年，卒于969年，享年47岁）是马其顿王朝第四位篡位皇帝，963年8月16日至969年12月11日在位六年多。

陆大鹏译罗杰·克劳利《1453：君士坦丁堡之战（地中海三部曲）》：967年，离心离德的皇帝尼基弗鲁斯二世·福卡斯在泉源之门被愤怒的暴民用乱石击毙。

王晴佳《断裂与转型：帝国之后的欧亚历史与史学》：他受到了怠慢，而且不得不聆听拜占庭皇帝尼基弗鲁斯二世·福卡斯（Nikephoros II Phokas）对奥托、他的王国、他的军队和他治下诸民族的侮辱。

《拜占庭帝国大通史》：约翰一世·基米斯基（John Ⅰ Tzimiskes,Iωννης Α'Τζιμισκς，生于925年，卒于976年，享年51岁）是马其顿王朝第五位篡位皇帝，自969年12月11日登基，至976年1月10日病逝，在位六年有余。

《拜占庭帝国大通史》：随着瓦西里二世的登基，该王朝重新恢复正统秩序，拜占庭帝国进入鼎盛时期。

A.A.瓦西列夫《拜占庭帝国史》：自1025年强大的皇帝瓦西里二世死后，帝国进入连续不断的宫廷政变和无政府时期，这导致1056—1081年的混乱局面。

《拜占庭帝国大通史》：阿吉洛斯家族成员早期多在军中担任职务，鼎盛时期从政的罗曼努斯·阿吉洛斯就成为帝国皇帝罗曼努斯三世。

维克多·斯宾内（Victor Spinei）著 孙昊、卢兆瑜译《东方视角下的11—12世纪巴尔干民族状况：叙利亚的米哈伊尔》：君士坦丁八世（1025—1028）和罗曼努斯三世·阿吉洛斯（1028—1034）的文字之前，

《拜占庭帝国大通史》：约翰将自己的弟弟米哈伊尔推上王位，即后来的米哈伊尔四世，虽然他仍然只是孤儿院院长，但是掌管着帝国的行政和军事大权。

刘文孝《拜占庭文学史》：1041年10月，米哈伊尔四世去世，米哈伊尔五世继位。

《拜占庭帝国大通史》：米哈伊尔五世·卡拉发特斯是女皇邹伊和米哈伊尔四世的养子，米哈伊尔四世的外甥。

《拜占庭帝国大通史》：邹伊这个名字在希腊语中是“生命”的意思，她在君士坦丁八世和瓦西里二世共治期间，约978年生于帝国首都君士坦丁堡大皇宫的紫色寝宫中，遂获称“出生于紫色寝宫的邹伊”​，以示其为皇帝正统血亲嫡系、地位尊贵。​

陈志强等译《牛津拜占庭史》：同样，皇帝也不满意，因为他们的权力都依赖于邹伊。

文聘元《地中海战史》：由于他出生于皇宫之中，这在东罗马帝国的诸帝中并不是常有的事，因此被称为“Porphyrogennetos”​，意思是“生于紫室者”​，紫乃是当时的皇室之尊色。

《拜占庭帝国大通史》：邹伊与塞奥多拉共同执掌政权两个月有余。

《11世纪拜占庭帝国的历史书写转型探析————以邹伊和塞奥多拉的“紫衣女性”形象为例》：在这一转型中，被史家成功塑造出的邹伊和塞奥多拉的“紫衣女性”形象尤为全面地涵盖了转型的内容与特征，成为本文探讨的典范。

赵法欣 邹薇《普塞洛斯《编年史》中拜占廷帝王“形象”塑造的特点》：普塞洛斯所处的时代先后有3位女性统治者掌握帝国最高统治权，即邹伊、塞奥多拉和尤多西娅，她们无一例外地在《编年史》中占据重要的篇幅，作者并未因为她们是女性这一特有的“形象”而持有男性的偏见，而是能够较为客观地对这三位女性予以记述和评价。

《拜占庭帝国大通史》：后来，约翰被流放至米蒂里尼(Mytylene)，后任皇帝君士坦丁九世·摩诺马赫将他处死。

陈志强等译《新编剑桥中世纪史.第四卷，约1024年至约1198年.第2分册》：为了排除任何可能来自拜占庭方面的进攻，为了不让他的兄弟们利用拜占庭的支持来反对自己，米哈伊尔与皇帝君士坦丁九世·摩诺马赫达成和解。

A.A.瓦西列夫《拜占庭帝国史》：君士坦丁九世摩诺马赫（Constantine IX Monomachus）称帝，于1042—1055年统治帝国。

《拜占庭帝国大通史》：米哈伊尔六世·布林加斯（Michael Ⅵ Bringas，Μιχαλ ΣΤ'Βργγας，生年不详，卒于1057年前后）是马其顿王朝结束后的首位拜占庭皇帝,1056年8月22日或31日继位，至1057年8月30日退位，在位近1年。

《拜占庭帝国大通史》：他原是安纳托利亚军区的将军，在君士坦丁九世统治期间，曾积极支持伊萨克一世·科穆宁的军事叛乱。

黄煜文译《伊斯坦布尔三城记》：伊萨克一世·科穆宁（Isaac I Komnenos）试图重建国家财政，击败匈牙利国王安德烈一世（Andrew I）​，但不久便染上重病，因此退位隐居修道院。

维克多·斯宾内（Victor Spinei）著 孙昊、卢兆瑜译《东方视角下的11—12世纪巴尔干民族状况：叙利亚的米哈伊尔》：这位作者一直生活在雅各比派牧首教管辖下的一个中心地区，他声称伊萨克一世·科穆宁曾跨越多瑙河追击佩切涅格人，但这条信息的真实性尚不能确定，因为还未得到其他直接记述这场战役的材料的辅证。

《拜占庭帝国大通史》：君士坦丁十世·杜卡斯（Constantine Ⅹ Doukas，ΚωνσταντνοςΔοκας，生于1006年，卒于1067年5月，享年61岁）是杜卡斯王朝第一位皇帝，也是该王朝创立者，1059年11月在君士坦丁堡加冕称帝，1067年5月病逝于君士坦丁堡，在位七年半。

黄煜文译《伊斯坦布尔三城记》：1059年到1067年君士坦丁十世·杜卡斯（Constantine X Doukas） 削减军事开支，削弱帝国国防。

A.A.瓦西列夫《拜占庭帝国史》：伊萨克退位，君士坦丁十世杜卡斯即位（1059—1067年在位）​，他是个天才的理财者和正义的维护者，只关心国内行政事务，而对军务一般地毫不过问。

《拜占庭帝国大通史》：1067年，迫于国内外困境，尤多奇亚不顾群臣反对，违背誓言，嫁给了军事贵族罗曼努斯·狄奥根尼斯，后者在1068年1月1日加冕为帝，即罗曼努斯四世。

《拜占庭帝国大通史》：来自杜卡斯家族的米哈伊尔七世主要依靠叔叔约翰·杜卡斯领导军队，依靠宦官尼基弗利齐斯治理内政，在位6年多的时间里，多次大规模的军事贵族叛乱先后爆发。

陈志强等译《新编剑桥中世纪史.第四卷，约1024年至约1198年.第2分册》：米哈伊尔七世·杜卡斯鼓励他向牧首科斯马斯表白信仰，以此证明自己的清白。

任九菊译《萤火虫全球史051·拜占庭帝国》：回到君士坦丁堡后，罗曼努斯四世发现杜卡斯家族密谋造反，米哈伊尔七世·杜卡斯已经称帝。

《拜占庭帝国大通史》：尼基弗鲁斯三世·博塔尼埃蒂兹出生于小亚细亚的军事贵族家族，自称与杜卡斯家族有亲戚关系。

维克多·斯宾内（Victor Spinei）著 孙昊、卢兆瑜译《东方视角下的11—12世纪巴尔干民族状况：叙利亚的米哈伊尔》：米哈伊尔在第50卷提到阿莱克修斯一世·科穆宁的其他一些事件，这里有必要说说这些事件，因为其中的一些与前述第12章的引文存在某种联系。

谭琦译丹·琼斯《十字军：一部争夺圣地的战争史诗》：1095年，也就是他出任教皇的第七年，当四面受困的拜占庭帝国皇帝阿莱克修斯一世·科穆宁派出的使者们出现在阿尔卑斯山脚下时，他发现这恰好是他日思夜想的大业。

维克多·斯宾内（Victor Spinei）著 孙昊、卢兆瑜译《东方视角下的11—12世纪巴尔干民族状况：叙利亚的米哈伊尔》：这个段落属于栏目“政治历史事件”​，被放置在讲述同一年库尔德埃米尔入侵梅利泰内引起的骚乱事件，以及约翰二世·科穆宁继位引发的阴谋事件这两段文字之间。

谭琦译丹·琼斯《十字军：一部争夺圣地的战争史诗》：1143年4月初，约翰二世·科穆宁外出狩猎野猪，在与体格特别大的一只野猪搏斗时不慎被自己的毒箭筒擦伤了手。

维克多·斯宾内（Victor Spinei）著 孙昊、卢兆瑜译《东方视角下的11—12世纪巴尔干民族状况：叙利亚的米哈伊尔》：拜占庭皇帝曼努埃尔一世·科穆宁消灭塞尔柱突厥政治—军事势力的计划，在1176年密列奥塞法隆战役失败后完全破产。

谭琦译丹·琼斯《十字军：一部争夺圣地的战争史诗》：沿着多瑙河通过匈牙利，然后横越巴尔干半岛到达君士坦丁堡，在东方皇帝曼努埃尔一世·科穆宁的支持下穿过小亚细亚，经安条克进入十字军国家。

彭小瑜译《牛津中世纪欧洲史》：年轻的阿莱克修斯二世·科穆宁仅仅统治了三年(1180—1183年)

《拜占庭帝国大通史》：科穆宁王朝为拜占庭帝国第十个王朝，统治时间106年，先后有六个皇帝在位，即伊萨克一世（Isaac Ⅰ Komnenos,1057—1059年在位）​、阿莱克修斯一世（Alexios Ⅰ，1081—1118年在位）​、约翰二世（John Ⅱ，1118—1143年在位）​、曼努埃尔一世（Manuel Ⅰ，1143—1180年在位）​、阿莱克修斯二世（Alexios Ⅱ，1180—1183年在位）​、安德罗尼库斯一世（Andronicus Ⅰ，1183—1185年在位）​。

《拜占庭帝国大通史》：安德罗尼库斯一世·科穆宁（Andronikos I，Ανδρóνικος Κομνηνóς，生于1118年，卒于1185年9月12日，享年67岁）是科穆宁王朝第六位皇帝，也是该王朝的终结者，1183年9月至1185年9月12日67岁去世，在位两年。

维克多·斯宾内（Victor Spinei）著 孙昊、卢兆瑜译《东方视角下的11—12世纪巴尔干民族状况：叙利亚的米哈伊尔》：只是提到伊萨克二世继承了安德罗尼库斯一世·科穆宁（III，393）​，

《拜占庭帝国大通史》：他的上位是建立在罢黜、刺瞎他的弟弟伊萨克二世·安苴鲁斯的基础上，这成了后来阿莱克修斯四世联合第四次十字军围攻君士坦丁堡的借口。

《拜占庭帝国大通史》：米哈伊尔的母亲塞奥多拉·安吉丽娜·帕列奥列吉娜(Theodora Angelina Palaiologina)是安苴鲁斯王朝（Angelid dynasty,1185—1204年）皇帝阿莱克修斯三世·安苴鲁斯的孙女。

《拜占庭帝国大通史》：伊萨克与赫莉娜的长子阿莱克修斯被视为皇位继承人，也就是后来短暂统治拜占庭帝国的阿莱克修斯四世。

《拜占庭帝国大通史》：他的小女儿欧多基娅·安吉丽娜先后嫁给了三个手握重权的丈夫，她的第一任丈夫是塞尔维亚国王斯蒂芬·内马尼亚，第二任是皇帝阿莱克修斯五世·杜卡斯(Alexios V Doukas)，第三任是科林斯城的独裁者利奥·斯古罗斯(Leo Sgouros)。

杨乐言译约翰·朱利叶斯·诺里奇《威尼斯史：向海而生的城市共和国》：拜占庭皇帝阿莱克修斯五世·杜卡斯（​“眉毛杂乱者”​）

谭琦译丹·琼斯《十字军：一部争夺圣地的战争史诗》：他将皇位据为己有，号称阿莱克修斯五世·杜卡斯，并给十字军传去了一个直白的口信。

《拜占庭帝国大通史》：塞奥多利一世·拉斯卡利斯出生于1171年至1176年间，是尼西亚帝国的开国君主。

《拜占庭帝国大通史》：1246年，约翰三世·杜卡斯·瓦塔泽斯吞并了塞萨洛尼基。

A.A.瓦西列夫《拜占庭帝国史》：他死后，继位者是他的女婿，即其女儿伊琳娜的丈夫约翰三世杜卡斯·瓦塔泽斯（John III Ducas Vatatzes，1222—1254年）

莫玉梅译《新编剑桥中世纪史.第五卷，约1198年至约1300年》：在罗马尼亚反对威尼斯霸权的一次徒劳的努力中，热那亚试图与尼西亚的约翰三世·杜卡斯·瓦塔泽斯协商条约未果，

《拜占庭帝国大通史》：1254年继位为帝的塞奥多利二世·拉斯卡利斯试图摆脱大贵族的影响，加强自己的集权力度，因而启用了若干出身低微的官员并委以重任，其中尤以木扎伦(Mouzalon)兄弟为代表。

《拜占庭帝国大通史》：由于塞奥多利二世采用削弱贵族势力、重用寒门人士的政策，树敌过多，引起普遍不满，加上过度操劳，导致他的健康状况急剧恶化，于1258年8月去世。但他留下充盈的国库，去世前安排出身低微的重臣和密友乔治·木扎伦辅佐年幼儿子的约翰四世·拉斯卡利斯。

A.A.瓦西列夫《拜占庭帝国史》：约翰四世拉斯卡利斯（1258—1261年）

《拜占庭帝国大通史》：此后拉丁帝国开启了长达57年的统治，直到1261年尼西亚政府的皇帝米哈伊尔八世·帕列奥列格收复君士坦丁堡，恢复该城为拜占庭帝国首都。

周超宇，李达译科林·韦尔斯《拜占庭的赠礼：东罗马帝国对西欧、阿拉伯世界和斯拉夫地区的文化影响》：首先是几个敌对的流亡政权，然后是一个单一的拜占庭残余部分的国家，其领袖是米哈伊尔八世·帕列奥列格（Michael Ⅷ Paleologos）​，他自称“新君士坦丁”​。

《拜占庭帝国大通史》：安德罗尼库斯二世·帕列奥列格是拜占庭帝国末代王朝帕列奥列格王朝的第二任君主，生于1259年前后，其父亲是在同年发动政变加冕为尼西亚帝国的共治皇帝米哈伊尔八世·帕列奥列格，母亲是尼西亚帝国前代皇帝约翰三世·杜卡斯的侄女塞奥多拉·帕列奥列吉娜。其青少年时期的信息非常少，后人只知道他年轻时便被父亲加冕为共治皇帝。

《拜占庭帝国大通史》：米哈伊尔九世·帕列奥列格（Michael Ⅸ Palaiologos，Μιχαλ Θ Παλαιολóγος，生于1278年，卒于1320年10月12日）是帕列奥列格王朝第三位皇帝，1281年3岁时被祖父立为共治皇帝，1294年5月21日又被父亲立为共治皇帝，是拜占庭帝国历史上唯一与在位皇帝米哈伊尔八世同名命名的共治皇帝。

《拜占庭帝国大通史》：安德罗尼库斯三世·帕列奥列格（AndronikosⅢ Palaiologos，Ανδρóνικος ΓΠαλαιολóγος，生于1297年3月25日，卒于1341年6月15日）是帕列奥列格王朝第四位皇帝，1328年内战中取胜，迫使祖父退位，5月24日登基，至1341年6月15日去世，在位13年。

《拜占庭帝国大通史》：在他看来，只要年轻的约翰五世·帕列奥列格还活着，后者正式继承皇位是迟早的事。

陈志强等译《牛津拜占庭史》：同时，约翰五世·帕列奥列格也逐渐年长，开始设法掌握全权，并试图摆脱坎塔库泽努斯的控制。

周超宇，李达译科林·韦尔斯《拜占庭的赠礼：东罗马帝国对西欧、阿拉伯世界和斯拉夫地区的文化影响》：约翰五世·帕列奥列格在接下来的几十年中断断续续地掌权，他儿子们不时的纷争扰乱了他的统治。

《拜占庭帝国大通史》：再者，约翰六世·坎塔库震努斯(John ⅥKantakouzenos)的回忆录性质的作品则是从1321年米哈伊尔九世去世和内战爆发起笔，对于1321—1328年的内战进程的记录较为详细。

陈志强《拜占庭帝国政治史论》：法国王室和政府积极支持并赞助卢浮宫出版机构组织学者编辑出版拜占庭古籍系列丛书，1645年出版了丛书的第一册，即拜占庭皇帝约翰六世·坎塔库震努斯（John Ⅵ，Kantakouzenos，1347—1354年在位）的《历史》​，标志着有组织的资料整理工作正式开始。

《拜占庭帝国大通史》：叛乱失败以后，穆拉德一世刺瞎了他的儿子，他要求约翰五世也刺瞎安德罗尼库斯四世和约翰七世的双眼，但是，约翰五世仅刺瞎了儿子和孙子各自的一只眼睛。

《拜占庭帝国大通史》：安德罗尼库斯五世因其夭折，所以于历史的长河中仅存姓名而无事迹。

周超宇，李达译科林·韦尔斯《拜占庭的赠礼：东罗马帝国对西欧、阿拉伯世界和斯拉夫地区的文化影响》：曼努埃尔二世·帕列奥列格——凯多内斯在一封贺信中称他为柏拉图笔下的“哲学王”——在凯多内斯离开威尼斯的前不久继承了皇位。

周超宇，李达译科林·韦尔斯《拜占庭的赠礼：东罗马帝国对西欧、阿拉伯世界和斯拉夫地区的文化影响》：在过去的十年里，穆罕默德一世和曼努埃尔二世相继去世，分别由其子穆拉德二世（Murad Ⅱ）和约翰八世·帕列奥列格继位。

《拜占庭帝国大通史》：君士坦丁十一世·帕列奥列格（Constantine Ⅺ Palaiologos，Κωνσταντ[插图]νοςΠαλαιολóγος，生于1405年2月8日，卒于1453年5月29日）是帕列奥列格王朝第11位皇帝，也是该王朝最后一位皇帝和拜占庭帝国末代皇帝，1449年3月12日至1453年5月29日在位近四年。

各位意见如何？夏土贤（留言） 2024年11月13日 (三) 18:32 (UTC)[回复]

多数皇帝在中文语境迳称帝号，尚与外文习惯不同；又有些名称并非常用，且中文翻译亦不总是选用所谓“读音最接近”者（如“希拉克略”等，即是仍获广泛使用的传统译名）。总之，是否选为主标题，有必要一并结合既有中文来源考量。另副知@Zhxy 519。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月13日 (三) 22:27 (UTC)[回复]
Talk:查理一世 (英格兰)#英格兰国王查理一世和查理二世的条目标题。众人早有共识，历史译名不轻动。--Zhxy 519（留言） 2024年11月13日 (三) 23:57 (UTC)[回复]
刘文孝的《拜占庭文学史》就是用中文写的，使用过“米哈伊尔一世拉加贝”这样的称呼方式。王晴佳《断裂与转型》也是中文写的，但也使用过“尼基弗鲁斯二世·福卡斯”这样的称呼方式。特朗普肯定比唐纳德·特朗普更常用，但不妨碍条目以唐纳德·特朗普为标题。广泛使用是会改变的。例如塞奥菲鲁斯在相关中文论文中使用最广，比现行的狄奥斐卢斯更适合作为标题。有些书籍和网络文章的译名都是直接照搬自自中文维基百科，如果狄奥斐卢斯的条目标题改为塞奥菲鲁斯，我相信会随着时间的推移，书籍中使用塞奥菲鲁斯的会越来越多，成为最广泛的译名。夏土贤（留言） 2024年11月14日 (四) 08:28 (UTC)[回复]
然而维基百科并不是阁下宣扬学术观点的地方。--向史公哲曰（留言） 2024年11月14日 (四) 08:30 (UTC)[回复]
衷心地希望阁下尊重客观事实和命名常规的存在。--向史公哲曰（留言） 2024年11月14日 (四) 08:33 (UTC)[回复]
(－)强烈反对，NC:BIO。--SheltonMartin留言|签名 2024年11月19日 (二) 03:03 (UTC)[回复]
不反对为“伊拉克略”等出现在书籍中的译名设立重定向，但(－)强烈反对直接变更条目命名：有不少出版物使用目前的条目命名，您只列出使用您主张的译名的书籍而宣称这些是“学界常规”未免有摘樱桃之嫌疑，而将不使用您主张的译名的书籍称之为“不伦不类”更是典型的没有真正的苏格兰人。退一步讲，WP:FCFS。——Aggie Dewadipper ※ Beat Bobcats! 2024年11月14日 (四) 00:42 (UTC)[回复]
可能需要多找几种文献参照，在《拜占庭帝国大通史》（2023年）以前的书又怎么说？中文文献对于这些君主真的还会加上姓氏，让“某世”夹在中间吗？拉丁语、希腊语在中世纪以前开始不发“H”的音了，记得以前看过一个说法，现在中维看见的拜占庭君主译名，有些可能是透过俄语转音来的。——George6VI（留言） 2024年11月14日 (四) 00:51 (UTC)[回复]
我个人(＋)赞成使用阁下的办法消歧义，但(－)反对使用阁下的办法更迭没有歧义的名字（如君士坦丁十一世等）
另外，我个人(－)反对使用“帕列奥列格”这种冷门译名，赞成使用“巴列奥略”这种热门译名。--向史公哲曰（留言） 2024年11月14日 (四) 07:51 (UTC)[回复]
总之，我个人(－)倾向反对阁下的提议，但不排斥阁下的消歧义方法。--向史公哲曰（留言） 2024年11月14日 (四) 07:53 (UTC)[回复]
“帕列奥列格”不是冷门译名。陈志强编写的《拜占庭帝国史》、《拜占庭文明》、《拜占庭史研究入门》、《鹰旗飘落》、《科索沃通史》、《拜占庭帝国大通史》，以及他翻译的《牛津拜占庭史》、《新编剑桥中世纪史.第四卷，约1024年至约1198年.第2分册》都以“帕列奥列格”为译名。约翰·朱利叶斯·诺威奇的《拜占庭的衰亡：从希腊君主到苏丹附庸》、《征服，1016—1130：西西里的诺曼王朝Ⅰ》、《王国，1130—1194：西西里的诺曼王朝Ⅱ》的中译本，A.A.瓦西列夫《拜占庭帝国史》的中译本，2022年新近出版的周超宇，李达翻译的科林·韦尔斯《拜占庭的赠礼》中译本，也都是以“帕列奥列格”做译名的。卡尔十四世没有歧义，但不妨碍条目以卡尔十四世·约翰为标题。同理，君士坦丁十一世没有歧义，不妨碍以君士坦丁十一世·帕列奥列格为标题。夏土贤（留言） 2024年11月14日 (四) 08:45 (UTC)[回复]
1.你阅读过命名常规吗？2.张维为曾经说过：“一切都是比较而言”，希望你能够好好领会这句话的意思。3.卡尔十四世·约翰是通名，君士坦丁十一世·帕列奥列格是通名吗？如果阁下不列出数据比较，你的论证再多，也没有用。--向史公哲曰（留言） 2024年11月14日 (四) 08:52 (UTC)[回复]
“帕列奥列”系译名的常用度仅为“巴列奥略”系译名的一半，你知道这个差距多大吗？--向史公哲曰（留言） 2024年11月14日 (四) 08:56 (UTC)[回复]
陈志强使用的拜占庭皇帝主要译名更合适做条目标题。陈志强的著作和译著更符合中文拜占庭史的维基百科:可靠来源，可靠性不是乱七八糟的网络文章可以比拟的。夏土贤（留言） 2024年11月14日 (四) 19:19 (UTC)[回复]
请阁下停止摘樱桃。——Aggie Dewadipper ※ Beat Bobcats! 2024年11月14日 (四) 18:56 (UTC)[回复]
稍微看了一部分，上文提到Palaiologos（Παλαιολόγος）帕列奥列格（新译名）和巴列奥略（旧译名），我稍微查证一下夏土贤举例是否正确。陈志强的《拜占庭帝国大通史（1204—1461）》（2023）列出的书目看到，的确是使用“帕列奥列格”。
那么“巴列奥略”是哪里来的，我用百度学术找了一下，也是陈志强这个学者，早些年的《拜占庭帝国通史》（2014）就是用“巴列奥略”。两个翻译源头都是陈志强，2014年的著作面世早，已经被不少期刊论文使用范围，所以“巴列奥略”译名已经流传出去，换言之成为常用译名。2023年的著作更换了译名。辩证一点说，是否出于严谨的学术研究，而更换译名，还是单纯新一批帮忙的研究生用了其他资料。
退一步说，{{拜占庭帝国巴列奥略家族成员}}各条目名，帕列奥列格（新译名）和巴列奥略（旧译名）的使用也不统一。如曼努埃尔二世 (拜占庭)条目，内文全名曾经是“曼努埃尔二世·帕里奥洛格斯”，现在是“曼努埃尔二世·帕莱奥洛戈斯”（Manuel II Palaiologos），托马斯·帕里奥洛格斯（Thomas Palaiologos），这里出现了“帕莱奥洛戈斯”和“帕里奥洛格斯”两种新译名。Palaiologos的变体Palaiologina（女名），2007年创建的条目索菲娅·帕列奥罗格（Sophia Palaiologina）使用“帕列奥罗格”，恰好和帕列奥列格（新译名）一样，但是不是新著作的“帕列奥列吉娜”。
无论是坚持旧译名，还是使用新译名，现有相关条目，都有大量文本细节需要统一。不是只单单反对改条目名那么简单。--Nostalgiacn（留言） 2024年11月16日 (六) 18:29 (UTC)[回复]
陈志强的《拜占庭史研究入门》（2011-12出版）、《鹰旗飘落》（2016-8-10）、《拜占庭帝国史》（2017-4出版）、《拜占庭帝国政治史论》（2023-3-1出版）都是以“帕列奥列格”作为译名的，《拜占庭帝国通史》中的“巴列奥略”反而是个另类。“帕莱奥洛戈斯”则是Palaiologos的新华社译名，是大陆用来翻译现代希腊人姓氏的译名。夏土贤（留言） 2024年11月17日 (日) 14:23 (UTC)[回复]
我再以“巴列奥略”（Palaiologos）找一下资料，在中国社会科学文库，最早的是《苏联中东关系史》（1987）的【叶卡特琳娜二世推行彼得一世的南下政策】一章提到“复活东罗马帝国巴列奥略的君主制。”，之后《俄国史新论：影响俄国历史发展的基本问题》（2002）提到Palaiologina（女名）的“巴列奥略”类似译名“1472年，伊凡三世迎娶拜占廷公主索菲娅·巴列奥略格为妻”。在新近的《新编剑桥中世纪史.第六卷.约1300年至约1415年》（2020）还在使用，提及的是【第二十四章 14世纪时拜占庭帝国】（[17]）。《新编剑桥中世纪史》根据中国社会科学文库的记录，都在用“巴列奥略”译名。
回到巴列奥略王朝这个条目，2010年11月1日创建时就是“巴列奥略王朝”。先前学术研究已经使用“巴列奥略”，起码不是原创译名。
@Dewadipper、George6VI、向史公哲曰、Zhxy 519：条目名改不改另说，如果坚持继续使用“巴列奥略”，基于WP:命名一致性，是否也应该统一巴列奥略王室成员条目和提及相关人名时，都使用“巴列奥略”（Palaiologos）。毕竟如上文所说，从条目名到相关内文，Palaiologos的译名是多种多样，如托马斯·帕里奥洛格斯（Thomas Palaiologos）和索菲娅·帕列奥罗格（Sophia Palaiologina）。--Nostalgiacn（留言） 2024年11月18日 (一) 15:19 (UTC)[回复]
@Dewadipper、George6VI、向史公哲曰、Zhxy 519、夏土贤：既然夏土贤的译名修改建议，没人认同。上文建议基于WP:命名一致性，统一巴列奥略王室成员条目和提及相关人名，都使用“巴列奥略”（Palaiologos）。目前已经过了8天，符合WP:最后留言七天公示的情况，如果没有其他意见，可以进行公示。或者算无异议，可以进行相关修改。--Nostalgiacn（留言） 2024年11月26日 (二) 10:21 (UTC)[回复]
阁下修改罢--向史公哲曰（留言） 2024年11月26日 (二) 11:49 (UTC)[回复]
  • 真要追求准确的话，显然这里举的译名也不太好，首先无论是现有的还是拟改的很多都是拉丁化或者盎格鲁化的结果，比如ioannes变成了john，basileos变成了basil，isaakios变成了Issac，nikephoros变成了nikephorus,romanos变成了romanus，konstantinos变成了Constantine，andronikos变成了andronica，theodoros变成了theodore。中文又遵从这种英语化/拉丁化的译法（当然也有俄罗斯化的，如米哈伊尔、瓦西里），不合理的可太多了，我建议是就混沌下去吧.Dkzzl（留言） 2024年12月3日 (二) 15:49 (UTC)[回复]

目前已经粗略统一了相关条目的Palaiologos/Palaiologina译名。共识也存档维基百科:条目命名一致性决议。Palaiologos的变体Palaiologina（女名）目前未找到来源支持的译名，暂时统一作“巴列奥略”，未来有新来源支持可以再修改。

处理期间发现五种译名：巴列奥略吉娜、帕里奥洛吉娜、帕里奥洛加斯、帕里奥洛格斯、帕里奥洛加斯。

一叶知秋，拜占庭帝国相关人物译名非常混乱，虽然夏土贤的建议被反对，但是混乱问题不解决，不熟悉的人，就像在看“蒋介石”和“常凯申”一样混乱。此外，拜占庭帝国相关人物如此混乱的译名下，居然还有一些GA条目，可谓更匪夷所思。

跟着来源翻译，总比无来源的混乱译名好。正如吉米·威尔士所说没有内容强过有内容但没有来源。就算你们搁置不处理，如君士坦丁十一世条目中的全名“君士坦丁十一世·德拉加瑟斯·巴列奥略”（Constantine XI Dragases Palaiologos），我修正了Palaiologos（原巴列奥略戈斯），中间名Dragases源于他母亲“海伦娜·德拉加什”，两者不相同的混乱局面还会继续误人子弟。--Nostalgiacn（留言） 2024年12月3日 (二) 18:04 (UTC)[回复]

Palaiologina可以根据陈志强等人的《拜占庭帝国大通史》，音译成“帕列奥列吉娜”--夏土贤（留言） 2024年12月4日 (三) 07:35 (UTC)[回复]
Palaiologina是Palaiologos变体，译名上最好选类似的。英维条目上巴列奥略王朝女性成员，我看经常是XXX Palaiologina，又名XXX Palaiologos。目前统一影响不大。--Nostalgiacn（留言） 2024年12月4日 (三) 08:27 (UTC)[回复]
也可以根据《新编剑桥中世纪史》第6卷，翻译成“巴列奥略娜”，算是和“巴列奥略”配套的。“巴列奥略娜”和“帕列奥列吉娜”都是有中文书籍来源支撑的译名，阁下取舍吧。--夏土贤（留言） 2024年12月4日 (三) 08:37 (UTC)[回复]
你的意见或许有可取之处，但维基百科的译者社群并不赞成女性译名。--向史公哲曰（留言） 2024年12月4日 (三) 08:39 (UTC)[回复]
“巴列奥略娜”在中国社会科学文库找到一个结果（也就是你举例的《新编剑桥中世纪史》第6卷），但是孤证不立。而且巴列奥略王朝女性成员不止一个，基于常识，作为描述那段历史的书，也不可能只出现一次巴列奥略王朝女性成员。只有一处用到是很异常的，不排除其他女性成员使用其他译名。--Nostalgiacn（留言） 2024年12月4日 (三) 15:27 (UTC)[回复]

关于西北太平洋台风的条目命名方式

本主题或以下段落文字，在讨论结束后应存档至WikiProject talk:太平洋台风季。

最近几个月，“山陀儿”、“银杏”等首次使用的台风名称，刻意要在条目名称加注年份，明明该台风名称目前只被使用一次，却有使用者认为“除非此名称只用一次即被申请除名，否则过往风暴条目做法皆保留年份于条目名称。”我觉得这样很矛盾：第一，针对第一次使用的台风名称之条目命名方式有哪来共识？第二，根据U:Ericliu1912在台风山陀儿讨论页的发言：“因现时确实无歧义。维基百科反映人类现有知识的总和，而非未来。”综合以上观点，我倾向于针对第一次使用该台风名称的条目不应加记年份，不晓得大家怎么看？--Sinsyuan✍️💙🐻 2024年11月20日 (三) 23:21 (UTC)[回复]

中国大陆的台风正式名称（出现于气象志、气象类专著等）目前基本上都是XXXX号台风“某某”，例如2418号台风“山陀儿”，有时气象局对外服务时会将编号“展开”，称作2024年第18号台风“山陀儿”（事实上还有另一种命名方式，即不称“台风”而是称其最高强度，但和本问题无关，暂时不讨论）。一般只有被除名的台风（即使使用了不止一次）可以不加编号，因为非常为人所知（类似中维的“主从消歧义”），但正式名称仍然是带编号；或是并不严谨地称呼（不用于章节标题等）时可以只用“XXXX年的台风‘某某’”。上世纪的台风甚至经常只用编号而不使用台风名（当时是只用编号；目前是编号名字都用，但名字有时不带、编号必然带。因为当时没有台风命名表，现代文献用的台风名也是挪用当时美国JTWC名字的）。台风名并不重要，只是用于方便称呼，所以循环使用，台风的本质属性是编号。其他地区不知道，至少目前中维没有一个台风的命名是符合中国大陆气象领域专业称呼和常用称呼的。--自由雨日🌧️❄️ 2024年11月20日 (三) 23:59 (UTC)[回复]
澳门气象局不会在前面加编号，只有强度加名字[18]。--街燈電箱150號 开箱维修 抄表 检验证明 2024年11月21日 (四) 10:46 (UTC)[回复]
气象局的服务具有实时性，所以可以不加编号。百科全书作为工具书，应该主要参考气象志、专著的命名方式。另外，中央气象台是必然会加编号的[19]，而且强度也不冠在台风名前，而是在之后括注；后文则直接简称“<台风名>”。--自由雨日🌧️❄️ 2024年11月21日 (四) 10:57 (UTC)[回复]
道理明明简单，第一次出现未有重名，就直接占用主标题，第二次出现再给之补齐产生年份后缀，并建立消歧义页面即可。本站所有消歧义页面几乎都是这样。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月21日 (四) 01:58 (UTC)[回复]
但是台风的名字和其他事物名称不一样，虽然性质上是专有名词，但它本质上不是赋予某个台风的，而是台风命名表上供循环使用、方便气象服务和研究中上下文代称的名称。包括“除名”，也是未来不再循环使用这个名字，而不是将该名字“赋予”某个台风（否则在这个名字之前的台风都得改名）。--自由雨日🌧️❄️ 2024年11月21日 (四) 07:38 (UTC)[回复]
我知道。但在某个时间点，某一台风仅有一个指代对象，不用消歧义，这也是事实。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月21日 (四) 13:30 (UTC)[回复]
那倒也是。（从中国大陆视角）我是认为不论加不加消歧义后缀都不合适，应当采用气象志、专著里所有台风都带前缀编号的命名方式。有大陆人声称文本当中仅有第一次出现带编号、后面不带，所以应采用不带编号的更“常用”方式，这逻辑显然不对，因为常用名称是连“台风”两字都没有、应命名为万宜（2024年台风）了[20]。--自由雨日🌧️❄️ 2024年11月21日 (四) 13:47 (UTC)[回复]
这个可以一半援用消歧义指引，“台风万宜”>“万宜 (台风)”（ —— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月22日 (五) 16:46 (UTC)[回复]
要援用消歧义指引那就要援用到底啊（ （[21][22][23]）--自由雨日🌧️❄️ 2024年11月22日 (五) 16:54 (UTC)[回复]
但“台风万宜”应该>“2024年台风万宜”，所以（ —— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月25日 (一) 08:23 (UTC)[回复]
选择性使用方针指引，游戏维基规则😡 ——自由雨日🌧️❄️ 2024年11月25日 (一) 11:55 (UTC)[回复]
而且不是加年份，是编号。--自由雨日🌧️❄️ 2024年11月25日 (一) 12:12 (UTC)[回复]
而且这就跟路西法人的《地球大气层》不命名为《大气层》（用在此处则是《大气层 (地球)》）的逻辑一样（注意我是认为应直接命名为“大气层”的，因为几乎所有中文来源都将“大气层”直接定义为包裹地球的气体，但这里姑且承认路西法人等人的前设来论述问题，即“大气层”的含义是包裹天体的气体），“地球大气层”绝大部分来源中都称为“大气层”，但这不代表“大气层”本身具有“地球大气层”的含义；台风命名是循环使用命名表，而不是赋予某个台风的专有称呼，上下文语境下省称“万宜”或台风“万宜”，不代表这一台风就拥有这一称呼。既然《地球大气层》不命名为《大气层 (地球)》，台风条目也显然不能将编号（甚至现在不用编号，直接用年份）置于消歧义括号之中。--自由雨日🌧️❄️ 2024年11月25日 (一) 14:46 (UTC)[回复]
维基百科不是占卜师，不应预先推定某一台风名称将来会被重用。--街燈電箱150號 开箱维修 抄表 检验证明 2024年11月21日 (四) 10:46 (UTC)[回复]
事实上风暴名称每隔5至6年就会重用，这是现行机制，并非阁下所指的“预先推定”。反过来说，不应预先推定某一风暴名称会只用1次即被除名。--W. Synchro（背弃了理想，谁人都可以） 2024年11月21日 (四) 12:40 (UTC)[回复]
不明白为何这次会发展到有编者不经讨论页取得共识，直接强行移动条目的地步。以往即使在首次使用风暴名称的热带气旋条目，这个问题也没有引起过争议，因为对气象这方面有留意的读者都知道，按照现行机制，风暴名称是每隔5至6年就会重用；反而只用1次即被除名的风暴名称相对较少。就以2017年天鸽为例，当初的条目命名也是“台风天鸽 (2017年)”，直到翌年天鸽被申请除名兼获台风委员会通过后，条目名称才删去年份后缀，改成“台风天鸽”。--W. Synchro（背弃了理想，谁人都可以） 2024年11月21日 (四) 12:50 (UTC)[回复]
五年才重用一次，那也至少是五年没歧义而不必更名。整个中文维基百科也才二十多年历史，好几年以后的事显然届时再议不晚。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月21日 (四) 13:30 (UTC)[回复]
但还是要回归到一个问题：“维基百科不是占卜师”。即使台风名称可能会在五、六年后再度被使用，但维基百科是针对人类所观察到的事物来写的，并不是台风名称在第一次使用后就一定要加注年份，况且目前首次被使用的台风名称没有消歧义，照理来说不应该要加注年份，以免违反消歧义的宗旨。（参考英文维基百科，山陀儿对应条目没有加注年份）--Sinsyuan✍️💙🐻 2024年11月21日 (四) 13:41 (UTC)[回复]
出于对新手友善与方便连入的考量，如果一个台风命名在5至6年后才会重用，那预先消歧义除了完全不必要外，还某程度上是有害的。Sanmosa 新朝雅政 2024年11月25日 (一) 00:03 (UTC)[回复]
一直都是在后面加年份啦，例：台风天鸽原先为“台风天鸽 (2017年)”，确定除名后才删去年份。—-O（留言） 2024年11月30日 (六) 15:12 (UTC)[回复]
咦？您的叙述跟@Weather Synchronize蛮像的，不过我重新说明一次：尽管台风名称在五六年后可能会重复使用同一名称（ex：2024年首次使用的“山陀儿”、2023年首次使用的“小犬”），但在第一次使用该台风名称之后没有出现同名台风名称，因此没有建立消歧义的必要性。--Sinsyuan✍️💙🐻 2024年11月30日 (六) 15:22
惯例就是这样。你不听我没办法。你想改就全部改了吧，我不阻止你，前题你能肯定那名字以后都不再用。反正台风条目都变得不伦不类，九唔搭八。—-O（留言） 2024年11月30日 (六) 15:40 (UTC)[回复]
(：)回应：从我的观点来看，第一次使用的台风名称没有必要加注年分，假如五、六年后再度被使用，就再加注年份就OK了，不必为此争论。--Sinsyuan✍️💙🐻 2024年12月1日 (日) 02:07 (UTC)[回复]
提提你“小犬”是没有被除名的，那你5-6年后记得回来改哦。这是自古以来的习惯，你接受不了可以离开，门口在那边，好走，不送。--O（留言） 2024年12月1日 (日) 04:30 (UTC)[回复]
来到这里也是为寻求共识，心平气和讨论便可，没必要如此强硬。虽然小弟不同意改变这惯例，但是以上各资深编者的发言也有其道理。如果最后讨论共识确实是倾向推翻现时惯例，我们也应该尊重。--W. Synchro（背弃了理想，谁人都可以） 2024年12月1日 (日) 08:15 (UTC)[回复]
是否过往真正有共识、明文规则甚或“自古以来”都是如此，小弟也不敢说到太死，最多只会说是惯常做法、不成文惯例。因为大家都知道热带气旋名称是会重复使用，所以很自然地就会加上年份后缀，不去考虑那名称是否第1次使用。如果大家取得共识，或者投票结果是要改变这个惯常做法，小弟也会尊重和执行。--W. Synchro（背弃了理想，谁人都可以） 2024年12月1日 (日) 08:20 (UTC)[回复]
编辑指南虽然的确没有写明必须有年份。但这已成为以往众编者的共识。没想到3年没回来这里也是为这些问题争执。
另外，后面有括号也不一定是“歧义”也可以系补充资讯，以往亦有这种格式存在（例：2023年台风小犬）。--O（留言） 2024年12月1日 (日) 14:48 (UTC)[回复]
(？)疑问台风条目的链入量多吗？如果不加年份，等这个名称再次启用时是否需要手动地把“台风某某”大量替换为“台风某某 (某年)”？——杰里毛斯（留言） 2024年12月2日 (一) 08:35 (UTC)[回复]
连入量多少视乎热带气旋的影响和破坏程度而定。若是一个从没威胁任何陆地的远洋风暴，不会受到太多关注，连入量就自然会少；反之若一个热带气旋吹袭多个人口稠密的地区，造成广泛破坏甚至严重伤亡，连入量就当然会多，光是热带气旋警告信号相关的条目就占了不少连入量。--W. Synchro（背弃了理想，谁人都可以） 2024年12月2日 (一) 11:45 (UTC)[回复]
理论上需要，因为之后“台风XX”就会变成消歧义页面。到时需要改动的会包括：“20XX年太平洋台风季”、“页尾风季模版”、“港澳台的台风模版”、各热带气旋警告信号相关条目等。--O（留言） 2024年12月2日 (一) 12:33 (UTC)[回复]

韩国人汉字“正名”、WP:BLPNAME以及NC:名从主人

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:汉字文化圈语言专有名词中译规则。

一年多以来，有一名来自韩国的用户，不断使用账号（Dkg00000）以及多重IP（太多IP，只列一个，121.159.61.135），将至少二十多位韩国人条目的汉字“正名”，使用论坛文章或图片托管平台等来源，内容为不知从何处来的“族谱”截图。

假设上述族谱截图为真，此用户同时还以族谱在条目中写出传主家人的姓名，做出有违WP:BLPNAME的编辑，还请各位留意。--HanTsî（留言） 2024年11月21日 (四) 11:24 (UTC)[回复]

族谱非公开出版物，亦不符合WP:可供查证。凭我个人在中国大陆地区的认知，“族谱”也不见得有多大的参考价值，大多都是某个/某群宗族观念较强的人群搞些身份认同感（顺便敛个财）的把戏罢了。韩国的情况不清楚，但是不符合维基百科方针是必然的。(＋)支持对其编辑回退并予以禁制。--SheltonMartin留言|签名 2024年11月22日 (五) 02:47 (UTC)[回复]
基本同意上方说法。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月30日 (六) 18:18 (UTC)[回复]
以主动对公众公开的汉字为准，如果是私人未公开的族谱，就按照外界约定俗成的中文名为准--航站区（留言） 2024年12月9日 (一) 06:55 (UTC)[回复]

族谱这事，真的有必要一刀切吗？个人的经验中所谓“族谱非公开出版物”这不见得为真，有些只不过是没有管道取得，若那些少数可供验证、比方说具体哪本书哪一页的参考资料，应该还是应该保留，说完全没有参考价值也过于武断。比方说，《孔子世家谱》是有ISBN的出版物，两岸各有一套官方图书馆收藏可以调阅。韩国一些本贯的族谱在FamilySearch上也能找到，仁济大学族谱图书馆也有相同功能，韩国政府也已经朝鲜王室（韩国皇室）的古族谱扫描到每一页都能在网络上直接查阅了。——George6VI（留言） 2024年12月2日 (一) 10:37 (UTC)[回复]

还要区分自费出版，学术价值及可靠性吧？--YFdyh000（留言） 2024年12月2日 (一) 14:56 (UTC)[回复]
正名及族谱要分开讨论。旗谱不涉及名从主人。按个人经验，至少本人没见过族谱的第三方来源。正名的话，就算第三方来源，所谓的正名也不一定全对且现时新闻媒体不会逐一查证，过往亦有媒体用错名字及音译不注解的情况。最准确的来源肯定是由本人亲自说的一手来源，一般都是综艺节目上、粉丝见面会公开才会知道的。但上述来源在维基百科视为不可靠来源。如要强制统一，只能全部统一为艺名，但艺名亦有多个艺名同时使用的情况，如IU。--Abcet10（留言） 2024年12月2日 (一) 15:43 (UTC)[回复]
当然族谱中跟其他文献相冲突的是可以斟酌不加入，毕竟Wikipedia:昼饮夜溺的谬误该避免我也知道，有些谱系很明显有问题不能直接当成事实引用。不过我更关心的是，上述提及的这几个来源能不能用，就算只是非主要来源、作为补充（比方说一句话带过这种），难道也不可靠？——George6VI（留言） 2024年12月3日 (二) 01:05 (UTC)[回复]
很明显就直接回退了，其他来源就和维基百科:可靠来源/常见有争议来源列表有关了。etoday应该还好，但最好在Naver查一下有没有一手来源，另一个我不太清楚。--Abcet10（留言） 2024年12月4日 (三) 14:13 (UTC)[回复]

参考来源的引用应该在逗号/句号的前面还是后面？

本主题或以下段落文字，在讨论结束后应存档至Help talk:脚注。

我不确定是否有人已经问过这个问题，但是对于在条目中引用来源到底要在逗号/句号前面还是后面？在不少条目中两者都有且都被混用，而且似乎没有明确的方针。所以，到底是要怎样标注<ref>呢？是“地球是平的。[1]”还是“地球是平的[2]。”？--FK8438（留言） 2024年11月25日 (一) 06:14 (UTC)[回复]

Help:脚注、Help_talk:脚注#中文维基ref的位置应在句号前还是句号后？。我的意见是：一个从句，如果脚注修饰的是某段分句内容的，放标号左侧；如果针对整个从句，则是结尾句号右侧。——Sakamotosan路过围观 | 避免做作，免敬 2024年11月25日 (一) 06:40 (UTC)[回复]
(＋)赞成。不过实际写起来（尤其是一些长条目的编辑）编者自己可能都想不起来这层标点符号的关系，所以应该也无所谓吧。--SheltonMartin留言|签名 2024年11月25日 (一) 08:28 (UTC)[回复]
这个问题问过很多次。只有支撑一整段的来源才会放在最后一个句号的后面，其余情况都放标点前面，User:Sanmosa/论述/引用格式有很好的解释。--街燈電箱150號 开箱维修 抄表 检验证明 2024年11月25日 (一) 06:46 (UTC)[回复]
这也只是我自己的个人建议。一般来说，不同用户有不同的做法，我看过有全部放前面的，也有看过全部放后面的，甚至部分放前面、部分放后面，但决定前置或后置的条件与我自己的习惯不一样的我都有见过。这主要是中文的标点符号体系的发展所导致的，现在确实没有任何的规定指明放置的位置，而且要为此施加硬性规定也没有可行性。Sanmosa 新朝雅政 2024年11月25日 (一) 08:17 (UTC)[回复]
一如往常，没有定论。我个人就认为应一律置于标点符号前（涉及整段内容者可用重复注脚处理），但显然这不代表社群共识。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年11月25日 (一) 08:21 (UTC)[回复]
同意没完全定论，也没人愿意将特定的表示方法变成明文规范。只能给出确实有不同的表示方法。——Sakamotosan路过围观 | 避免做作，免敬 2024年11月25日 (一) 09:01 (UTC)[回复]
个人标注方式完全同Ericliu1912；对这一问题观点同上，即无需作出特别规定，尊重主编+先到先得即可。--自由雨日🌧️❄️ 2024年11月25日 (一) 12:10 (UTC)[回复]
当然需要指出的是，如果引注的文句最末有引号，那么无论通常脚注本身格式是放在句末点号前还是句号点号后，这时都应该放在引号之后。--自由雨日🌧️❄️ 2024年11月25日 (一) 20:26 (UTC)[回复]
(？)疑问:如果中维没有的话，那么别的语言和其他维基项目（甚至是非WM的）是否有类似的规矩和方针供参考？此外，按照逻辑来说在逗号的前面是更合理的（逗号通常没有额外信息，只是叙述用途且与引用通常无关），但是对于句号的话我也不知道怎么搞。--FK8438（留言） 2024年12月3日 (二) 01:57 (UTC)[回复]
英维是统一放句号后。对现实中（即可靠来源中）的文献来说，我没有仔细统计过，但习惯也是显然不统一的。不过一般是统一放句末点号前或后（感觉是放点号前更多见，但不确定），“段落来源放后、单句来源放前”之类的这种格式好像没在站外见过。此外，中华人民共和国《信息与文献 参考文献著录规则（GB/T 7714—2015）》中的示例是放点号前的格式（即Ericliu和我的格式），不过那个标准本身并没有对此做出任何规范。——自由雨日🌧️❄️ 2024年12月3日 (二) 02:08 (UTC)[回复]
英文标点符号较窄，中文很宽，足以造成视觉差异。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月3日 (二) 19:21 (UTC)[回复]
维基百科的不少格式其实是来自传统论文格式，或者说传统百科全书。可以直接参考书籍和论文的格式。我看了一些论文和数，有放标点符号前（[27]），也有放标点符号后（[28]）。学界都两可了，应该也没必要强制。个人是建议一个条目内统一一个做法，这样比较美观。--Nostalgiacn（留言） 2024年12月4日 (三) 16:01 (UTC)[回复]
放前放后有实际需求的，需求应大于美观。也就是放后面可能是一句/多句/一整段的来源，放前面可能只是这一句半句的脚注。除非有更好办法诞生来清楚标注脚注所能佐证的内容──我很期望，但目前没有。--YFdyh000（留言） 2024年12月4日 (三) 18:18 (UTC)[回复]
我多年以前在逗号的注解，都是采用方法二，仅在句号时，才用方法一。现在观念有改，无论逗号或句号的注解，一律采用方法一，理由只有一个，就是为了美观，整齐划一，给阅览者观看条目时，有较佳的语感。--Znppo（留言） 2024年12月4日 (三) 18:37 (UTC)[回复]

参考资料

  1. ^ 1.comQ
  2. ^ 2.com

波兰医学生事件相关事件子条目内容用词疑问

本主题全部或部分段落文字，已移动至Talk:波兰医学生事件。执行人：Sanmosa 新朝雅政 2024年12月5日 (四) 01:39 (UTC)。[回复]

古羌人

本主题全部或部分段落文字，已移动至Talk:古羌人。执行人：Sanmosa 新朝雅政 2024年12月5日 (四) 01:41 (UTC)。[回复]

2024年英国骚乱的来源存档问题

本主题全部或部分段落文字，已移动至Talk:2024年英国骚乱。执行人：Sanmosa 新朝雅政 2024年12月5日 (四) 01:44 (UTC)。[回复]

亨利·毕晓普

本主题全部或部分段落文字，已移动至Talk:亨利·毕晓普。执行人：Sanmosa 新朝雅政 2024年12月5日 (四) 01:46 (UTC)。[回复]

航空公司条目的疑似爱好者内容和广告

本主题或以下段落文字，在讨论结束后应存档至WikiProject talk:航空。

如题，今天在阅读“四川航空”条目时发现的问题。这个条目现在媒体文件多得已经到了从infobox一直延伸到条目的参考内容部分，这显然是不合适的；另外还有可能已经构成广告的会员俱乐部有关内容。因此，对于多数航空公司条目，我有以下几个问题：

  1. 是否应该在“机队”章节的表格中新增“图片”一列并对各行描述的不同航空器如涂装相同则选附最多一张图片、如有彩绘则各自额外附最多一张图片？
  2. 是否需要将会员制度描述的像“四川航空”一样详尽？--  2024年12月2日 (一) 11:49 (UTC)[回复]
Wikipedia:不要包含原始资料的副本--唔好阻住我爱国（留言） 2024年12月2日 (一) 16:43 (UTC)[回复]
这一般不适用于非文字。Sanmosa 新朝雅政 2024年12月4日 (三) 14:53 (UTC)[回复]
@Sanmosa:难道阁下不认为“会员制度”是复制贴上？--唔好阻住我爱国（留言） 2024年12月4日 (三) 17:55 (UTC)[回复]
看上去有这样的观感，但我查证了一下，条目用的并非“原始资料”的exact wording。Sanmosa 新朝雅政 2024年12月5日 (四) 01:20 (UTC)[回复]
国泰航空#马可孛罗会。学坏了估计。对于图片的话，理论上自由版权随便用，但考虑观感的话，可以考虑保留创始机（如果有），一幅普遍的涂装，特殊涂装可以以主题保留一幅，不同主题的内容可以保留一幅。——Sakamotosan路过围观 | 避免做作，免敬 2024年12月3日 (二) 00:27 (UTC)[回复]
(＋)支持：如此以来便可大幅节省页面空间。此布局也许可以寻求航空专题共识。--  2024年12月3日 (二) 06:09 (UTC)[回复]
(＋)支持：长荣华航等条目的内容完全不符维基百科的基本标准，感觉那些内容已经演变成旅游和航空迷的日记了。--Sinsyuan✍️💙🐻 2024年12月3日 (二) 14:04 (UTC)[回复]
可以考虑当作推荐格式，但不宜强制，毕竟各家航空公司情况不同。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月3日 (二) 19:26 (UTC)[回复]
@A Chinese ID、Cwek、Ericliu1912、HK5201314、Sinsyuan：现有规定为WP:文件使用方针#使用守则，因此如果可以论证该等图片与条目没有密切关连或未在条目内文有所提及，那理论上在条目里删掉那些图片是符合方针的规定的。Sanmosa 新朝雅政 2024年12月4日 (三) 14:53 (UTC)[回复]
(：)回应：其实我是针对内文做评断有没有标准，毕竟也要回归到WP:RELIABLE、WP:列明来源等相关方针。--Sinsyuan✍️💙🐻 2024年12月4日 (三) 16:04 (UTC)[回复]
我倒是认为现有情况略有违背“使用守则”中“文件数量应保持适中”这一句。--  2024年12月6日 (五) 04:25 (UTC)[回复]

请求协助批量移动日本参众两院选举条目

根据最近通过的WP:命名常规#选举，“介绍选举的条目在名称上以公历年份区分，而非以届次区分”，故现请求协助批量移动日本参众两院选举条目，将该等条目中的届次（如“第50届”）替换为公历年份（如“第50届日本众议院议员总选举”更名为“2024年日本众议院议员总选举”）。受影响的条目为{{日本国政选举}}中“众议院议员总选举”与“参议院议员通常选举”两列所列的所有条目，总计76个条目。Sanmosa 新朝雅政 2024年12月4日 (三) 13:53 (UTC)[回复]

有关日本内阁条目的命名问题

现时，各国家／地区（非国家之独立或高度自治政治实体）内阁条目的命名格式一般为“第X次某某某内阁”，如第二次苏贞昌内阁（台湾）、第二次约翰逊内阁（英国）、第四次默克尔内阁（德国）等，由此可见“第X次某某某内阁”是各国家／地区（非国家之独立或高度自治政治实体）内阁条目的通用命名格式，而且也符合中文的使用惯例。然而，日本内阁条目的命名在2022年10月6日被TKsdik8900由“第X次某某某内阁”批量移动至“第X届某某某内阁”，我认为这种表达方式不合中文的使用惯例（尤其是他把“第X次改组”也改成“第X届改组”的举动完全有悖于中文文法），而且在内阁条目的命名一般通用“第X次某某某内阁”的格式的情况下，此举也有悖于条目命名一致性的要求。因此，我认为中文维基百科现有的日本内阁条目的命名应该批量移回或移至“第X次某某某内阁”格式的名称，此外条目名称带“第X届改组”字样者亦应改回“第X次改组”。Sanmosa 新朝雅政 2024年12月4日 (三) 14:09 (UTC)[回复]

除“第某次改组”外，应统一改为“届”。“次”并不适用于命名单届政府（内阁）为量词，“第几次内阁”反而才不合汉语用法。且“届”整体而言亦较“次”常用，有数量级差距。至于要用“某人第一届内阁”还是“第一届某人内阁”，则另当别论。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月5日 (四) 10:00 (UTC)[回复]
“‘届’整体而言亦较‘次’常用”一说我不太认可，我的见解是“届”距离常用的门槛还有相当一大段的距离，因此只有“次”符合使用常用名称的命名原则。以第二次苏贞昌内阁为例：关键字为“"第二次苏贞昌内阁" -wikipedia.org”时还有一定数量的搜索结果，但到了关键字为“"第二届苏贞昌内阁" -wikipedia.org”时却是连一个搜索结果也没有了。此外，以第二次石破内阁为例，虽然日本国首相官邸网站给的翻译是“第二届石破内阁”，然而日本放送协会给的翻译是“第二次石破内阁”，此外中华民国外交部、中央通讯社与中央广播电台使用的名称均为“第二次石破（茂）内阁”。Sanmosa 新朝雅政 2024年12月5日 (四) 10:56 (UTC)[回复]
极可能是（一）本站用法污染或（二）日文汉字用法。历史上来看，“届”在中文来源用于各国内阁更多，若偏要用“命名一致性”来论，反而日本当是特例（自此前有关选举之讨论亦可见得）；纵有用“次”者，可靠来源用法亦显未有统一。及于本站条目，如印度尼西亚、加拿大或乌克兰内阁等，亦大有用“届”者，阁下所举并非全貌。无论如何，不应纯以此为由改易全部之“届”为“次”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月5日 (四) 12:32 (UTC)[回复]
“中央通讯社与中央广播电台被中文维基百科的用法污染”这种话你说出来你自己能信吗？而且现代中文并不乏和制汉语，“次”字是日文汉字用法并不意味“次”字不合中文文法。我甚至还怀疑“届”字是否真的符合中文文法，这点我要求一个合理解释。Sanmosa 新朝雅政 2024年12月5日 (四) 12:40 (UTC)[回复]
“‘届’字是否真的符合中文文法”，阁下稍微搜寻下“第几届内阁”或“第几届政府”来源就知道，甚至香港自己都用，我觉得这已经是基本语文理解问题。另外，本站某些条目用“次”命名者，内文都还有“某次内阁是某国第几届内阁”此种说明，可见标题大有可能是因袭罢了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月5日 (四) 12:42 (UTC)[回复]
不，你说的这些并不能证明“届”在“某内阁”的情境下符合中文文法。我的理解是“届”通常用于常设机构／组织（如香港第七届立法会、第十一届立法院）等，然而“某内阁”（相对于“内阁”本身而言）并非常设（因为由某一特定人士组阁并非恒常安排），用“届”在意思上会造成不必要的理解问题。Sanmosa 新朝雅政 2024年12月5日 (四) 23:50 (UTC)[回复]
我觉得你脑补太多。反而还要问“次”是第几次什么？口语或如此讲方便，但行文相对说不通了，最多拿来形容某人“第几次组成内阁”，这跟“第几届内阁”不应一概而论。何况若换成“次”，要怎么“次中有次”，逻辑更不明白；要牵强解释也行，但才倒是“在意思上会造成不必要的理解问题”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月6日 (五) 03:26 (UTC)[回复]
我坚决反对你所声称的“脑补太多”之说，我在学习如何判断文句是否存在文法问题时就是用这种方法来判别的，而且你还是回避了“第X<量词>内阁”与“第X<量词>某人内阁”的差别，但这个差别很重要。再者，如果用“次”真的“逻辑更不明白”，那关键字为“第二次苏贞昌内阁”时还有一定数量的搜寻结果，但到了关键字为“第二届苏贞昌内阁”时连一个搜寻结果也没有的情况是如何发生的？这个情况不是用“次”多于用“届”，而是完全没有用“届”的情况，这种情况还能说是“被中文维基百科的用法污染”吗？反正我不相信。Sanmosa 新朝雅政 2024年12月6日 (五) 05:40 (UTC)[回复]
我也不介意再举几个用“次”的例子：[29]、[30]、[31]、[32]、[33]，前三者是台湾的论文，后两者是中国大陆的官方新闻网站，五者均在“第X<量词>某人内阁”的格式中使用了“次”作为量词。就这五个例子而言，我认为“被中文维基百科的用法污染”、“行文相对说不通”或“逻辑更不明白”等说法是无法适用的。还是说，其实我用了假的搜索引擎，所以才会出现我搜索出来的结果与你预期我会搜索出来的结果完全相反的情况？Sanmosa 新朝雅政 2024年12月6日 (五) 05:51 (UTC)[回复]
我国不是真正的内阁制国家，“第几届”或“第几次”内阁的说法固然有，但向来不多，所以实际上近年很多用法是从维基百科外溢的，这很正常。至于日本，中文来源沿用日文或因袭他处称呼“次”者本来就有，本人不否认这一点；但官方及民间来源亦多有用“届”者，当然也不能说是你伊始所谓不合中文使用惯例了。总之，并没有到谁压倒谁的程度。又阁下另一论点在于试图扩大到各国内阁命名来处理问题，那就这一角度来看“次”在来源使用可就真不如“届”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月6日 (五) 08:44 (UTC)[回复]
“‘次’在来源使用可就真不如‘届’”这点我也不同意，我尝试拿第二次约翰逊内阁与第四次默克尔内阁来做我对第二次苏贞昌内阁做过的事情，而搜索引擎显示出来的情况往往都是量词用“届”完全没有结果，而用“次”则有些结果。Sanmosa 新朝雅政 2024年12月6日 (五) 10:34 (UTC)[回复]
另外，我同意不应将“第几次改组”写成“第几届改组”，此当有共识。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月6日 (五) 08:49 (UTC)[回复]
这点我知道，我没有认为你打算把“第几次改组”写成“第几届改组”，我也没有打算深入探究这部分。Sanmosa 新朝雅政 2024年12月6日 (五) 10:35 (UTC)[回复]
某国“第X<量词>内阁”与某人“第X<量词>内阁”可能不太一样。--绀野梦人 2024年12月6日 (五) 02:09 (UTC)[回复]
2022年T移动的时候说“根据日本国首相官邸网站，‘次’被翻译成‘届’”，我当时看官网发现确实如此，是使用了“第X届内阁”及“第X届改组”（第一届使用“首届”）。现在看的时候发现官网变得不太一致了（某些原本有的内容好像还不见了？），还是“第X届内阁”（第二届石破内阁），但“第X届改组”使用了“第X次改组”（第二届岸田内阁 第二次改组），再往前页面样式变成了旧式（当时是新式？），没有“第X届内阁”，使用了“第X届改造”（第2届改造、首届改造）。当然本站命名不必拘泥于官网，可以重新考虑命名。--绀野梦人 2024年12月6日 (五) 01:52 (UTC)[回复]
道理很简单：按日本以众议员届别选举为界的人头算法，内阁多次改组应当都在一届，并不独立成届，故“第几届内阁”的“第几次改组”，确实比较符合汉语语法，我觉得他们如此区别改得对。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月6日 (五) 03:28 (UTC)[回复]
然而在日文里众议院的届次称为“回”而非“次”，我不认为两者是等同的。Sanmosa 新朝雅政 2024年12月6日 (五) 05:58 (UTC)[回复]

出版书籍、杂志是否为WP:NOT

本主题全部或部分段落文字，已移动至WT:维基百科不是什么。执行人：Sanmosa 新朝雅政 2024年12月5日 (四) 11:05 (UTC)。[回复]

有关朝鲜半岛南北政权旗帜模板国名显示问题

本主题全部或部分段落文字，已移动至Template talk:ROK、Template talk:DPRK。执行人：Sanmosa 新朝雅政 2024年12月5日 (四) 12:30 (UTC)。[回复]

龙的“翻译问题”章节语句变更相关

本主题全部或部分段落文字，已移动至talk:龙#龙的“翻译问题”章节语句变更相关。执行人：自由雨日🌧️❄️ 2024年12月5日 (四) 07:26 (UTC)。[回复]

建议把东罗马帝国条目标题改回拜占庭帝国

本主题或以下段落文字，在讨论结束后应存档至Talk:东罗马帝国。

东罗马帝国就是个不伦不类的偏僻怪异标题，该帝国最广为人知的名称就是拜占庭帝国，查爱德华·吉本的《罗马帝国衰亡史》：“The nations of Europe and Asia were mingled by the expeditions to the Holy Land; and it is under the Comnenian dynasty that a faint emulation of knowledge and military virtue was rekindled in the Byzantine empire”，用的也是Byzantine Empire。大家提到这个帝国，只会用拜占庭，没人会用东罗马指代。现行的东罗马帝国就是个偏僻标题，建议将该条目标题，改成拜占庭帝国。夏土贤（留言） 2024年12月6日 (五) 02:40 (UTC)[回复]

不是，上面的讨论还没完，你还开一个新的？Sanmosa 新朝雅政 2024年12月6日 (五) 06:08 (UTC)[回复]
@Ericliu1912、Zhxy 519、Dewadipper、George6VI、Dkzzl、Nostalgiacn。Sanmosa 新朝雅政 2024年12月6日 (五) 07:41 (UTC)[回复]
匪夷所思的奇谈怪论，这人所引用的书籍文献都是支持他想法的，存在严重的摘樱桃问题，(－)强烈反对是次提案。—-Aggie Dewadipper ※ Beat Redbirds! 2024年12月6日 (五) 07:53 (UTC)[回复]
而且还有一点，就是“拜占庭帝国”一名本身可能存在西欧地域中心的偏谬。Sanmosa 新朝雅政 2024年12月6日 (五) 08:03 (UTC)[回复]
(－)强烈反对：很像引战的言论，一本英国的书怎么说，就能当圣旨了？外国如何称呼都还不一致，拜占庭帝国最多就是一个别称，没有改名必要。——George6VI（留言） 2024年12月6日 (五) 07:50 (UTC)[回复]
虽然这个问题本身我并不反对以“拜占庭帝国”命名，但我认为你提出的理据完全不成立，且已经在扰乱边缘了。--自由雨日🌧️❄️ 2024年12月6日 (五) 08:30 (UTC)[回复]
(－)强烈反对。东罗马朝廷一直都自称“罗马帝国”，“拜占庭帝国”这种说法是在君士坦丁堡沦陷之后才出现的。📕📙📒📗📘赌博机构最坚定的反对者戒赌热线：2343-2255 2024年12月7日 (六) 01:00 (UTC)[回复]

本主题或以下段落文字，移动自Talk:东罗马帝国。执行者：Sanmosa 新朝雅政 2024年12月6日 (五) 10:43 (UTC)。[回复]

东罗马帝国就是个不伦不类的名称，该帝国最正规的称呼方式就是拜占庭帝国。东罗马帝国涉及原创研究。夏土贤（留言） 2024年12月4日 (三) 04:31 (UTC)[回复]

两者都有一些常用性，未细查哪个更常用。建议指明原创研究的内容。如果序言属实，目前名称可能为了贴合原意，但这与名从主人要求的官方中文名似有偏差；以及，使用古代正式名而非后世常用名，可能不贴合易于识别、防止歧义？@Iokseng--YFdyh000（留言） 2024年12月6日 (五) 03:08 (UTC)[回复]
如果以名从主人来说，他们的自称是“罗马帝国”。东罗马帝国和拜占庭帝国都是他人赋予的名称，“东罗马帝国”不是原创研究。--Iokseng（留言） 2024年12月6日 (五) 03:55 (UTC)[回复]
东罗马帝国更贴近其自称，他人在称呼上有所矫正注明。拜占庭帝国则是绰号比本名更常用？就像汪精卫国民政府的各称呼。--YFdyh000（留言） 2024年12月6日 (五) 04:39 (UTC)[回复]
@Dewadipper、George6VI、自由雨日：我是否可以以夏土贤上面的这个言论为由认为他是在公然造谣？Sanmosa 新朝雅政 2024年12月6日 (五) 10:45 (UTC)[回复]
可以看看不管中文还是英文的拜占庭现代研究著作，有几个叫东罗马帝国的？--夏土贤（留言） 2024年12月6日 (五) 11:07 (UTC)[回复]
根据google scholar，中文文献大概一万五千篇，英文文献有260万篇，请停止扯淡。——Aggie Dewadipper ※ Beat Redbirds! 2024年12月6日 (五) 17:26 (UTC)[回复]
可以看看，拜占庭和东罗马，哪个用的最多？东罗马的使用数量，完全无法和拜占庭比。--夏土贤（留言） 2024年12月7日 (六) 01:20 (UTC)[回复]
还是根据google scholar，拜占庭帝国的中文文献3100篇，英文文献50万篇，整体大概是东罗马的五分之一，“完全无法和拜占庭比”是你在哪天晚上梦到的？——Aggie Dewadipper ※ Beat Redbirds! 2024年12月7日 (六) 04:14 (UTC)[回复]
scholar.google.com "东罗马帝国" 1,440 条结果，"拜占庭帝国 "1,690 条结果。--YFdyh000（留言） 2024年12月7日 (六) 04:49 (UTC)[回复]
感谢提醒，我使用的是不带引号的结果（也就是不限定于一字一句完全相同），不过哪怕按用引号的结果也不足以支撑应改名这一结论。另外用不带引号搜出来的结果如“甘肃靖远新出东罗马鎏金银盘略考”和“略谈我国出土的东罗马金币”这两篇文献中的东罗马显然指的是东罗马/拜占庭帝国。虽然往后翻几页确实有不少和这个政权无关的结果，但显然数量差距不足以强行移动东罗马帝国至拜占庭帝国（WP:FCFS）。——Aggie Dewadipper ※ Beat Redbirds! 2024年12月7日 (六) 05:04 (UTC)[回复]
然而这与“原创研究”完全是两回事吧？Sanmosa 大统领님의政变方式은 2024年12月7日 (六) 04:15 (UTC)[回复]
我觉得已经完全属于扰乱了。至于是否造谣我不确定……维基百科有关于“造谣”之类的方针吗？--自由雨日🌧️❄️ 2024年12月6日 (五) 11:11 (UTC)[回复]
维基百科并没有关于造谣之类的方针，但这种程度的造谣意在使维基百科背离其作为百科全书须力求准确的原则。Sanmosa 新朝雅政 2024年12月6日 (五) 12:44 (UTC)[回复]
我赞同这个说法，并支持任何人以“扰乱”和“造谣”为由将其提报至ANM。--自由雨日🌧️❄️ 2024年12月6日 (五) 17:31 (UTC)[回复]
行，我提了。Sanmosa 新朝雅政 2024年12月6日 (五) 23:37 (UTC)[回复]
我没理解您的指控。上面讨论的主题不相同的样子。另外，目前讨论递进机制不是建议移到条目讨论页吗，怎么反向移。--YFdyh000（留言） 2024年12月6日 (五) 11:21 (UTC)[回复]
可能是“东罗马帝国”一词会涉及大量页面吧。--自由雨日🌧️❄️ 2024年12月6日 (五) 11:25 (UTC)[回复]
@YFdyh000：主要是因为上面有一个关联讨论的缘故，我认为放在同一页面便于相互参照。Sanmosa 新朝雅政 2024年12月6日 (五) 12:36 (UTC)[回复]
这显然不算造谣扰乱之类，Byzantine Empire 在英语学界是绝对的通用名称，在我所知道的德法学界也是一样，国际研究会与会议也基本全用“拜占庭”。大陆有关研究机构也是以“拜占庭”命名的（不知台湾香港如何，我估计也是一样）。我个人也更喜欢用“拜占庭帝国”。但这个名称基本是后人的发明确实不假……（当然“东罗马帝国”本身也是东魏西魏一样的后人称呼）。Dkzzl（留言） 2024年12月7日 (六) 14:21 (UTC)[回复]
我同意“拜占庭帝国”多有人用（尤其是西方研究），但“东罗马帝国”显然亦不至罕见。无论如何，斥之为“偏僻怪异标题”并不理性。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月7日 (六) 22:32 (UTC)[回复]

书籍的封面人物

请问【我推的孩子】的漫画有没有加上封面人物？我没看过加上去。--Sim Chi Yun（留言） 2024年12月6日 (五) 11:01 (UTC)[回复]

讨论通告：模板:Infobox military conflict“结果”一词的涵义

寻求共识以减少编辑争议：Template_talk:Infobox_military_conflict#关于“结果”栏的规范--欢颜展卷（留言） 2024年12月6日 (五) 20:02 (UTC)[回复]

“二次元”孰与“ACG”

本主题或以下段落文字，在讨论结束后应存档至Talk:ACG。

目前“二次元”是消歧义页，而“ACG”是主条目，且条目首段有一句原创表述如下：“该词汇一般不翻译为中文，需要时可能会被译为“动漫游戏”、“二次元”或“动漫游”等。”

但是如今“ACG”和“二次元”的关系似乎不太一样了。在中国大陆，“二次元”似乎已经成为“ACG”的对译，且比“ACG”更常用；在台湾，“ACG”和“二次元”都比较常用。（历史背景：据此文献，“ACG”一词或发源于台湾，而“二次元”一词或发源于中国大陆。）

以下为Google进阶搜寻结果（注：减法为排除词，引号为完整匹配）：

搜寻内容 简体中文搜寻结果数量 繁体中文搜寻结果数量 备注
"二次元" 131,000,000 7,050,000 搜寻结果前几页未发现无关内容
"二次元" -"ACG" 125,000,000 6,740,000 搜寻结果前几页未发现无关内容
"ACG" 23,600,000 10,500,000 搜寻结果含部分无关义项
"ACG" -制药 -胃肠病 -留学 -耐克 -Nike 22,700,000 9,410,000 去掉了部分无关义项
"ACG" -"二次元" 20,400,000 9,970,000 搜寻结果含部分无关义项
"ACG" -"二次元" -制药 -胃肠病 -留学 -耐克 -Nike 19,800,000 9,120,000 去掉了部分无关义项

想抛砖引玉，看看大家对以下问题有什么见解？

  1. 是否要设为地区词转换？设为哪个层级的地区词转换？
  2. “二次元”为消歧义页是否合理？消歧义页中目前列出的其他义项在中文语境中实在是不太常用。要不要把“二次元”直接重新导向到“ACG”，原内容移动到“二次元 (消歧义)”？

--SuperGrey (留言) 2024年12月7日 (六) 05:53 (UTC)[回复]

AC还行，但二次元不管是原意还是衍伸都跟G没半毛钱关系。 --窝法乙烷 儿法梦碎 2024年12月7日 (六) 06:08 (UTC)[回复]
一种说法，G是Galgame--YFdyh000（留言） 2024年12月7日 (六) 06:31 (UTC)[回复]
那您认为“二次元”是否对译“动漫”呢？--SuperGrey (留言) 2024年12月7日 (六) 06:46 (UTC)[回复]
不能，二次元的定义宽泛，既能指事物也能只喜欢该事物的人。话说漫画没追、漫展没去也不知道有出动画，单纯喜欢角色的人按目前版本也是二次元，虽说这种行为在我看来跟宗教信仰、偶像崇拜没啥区别。 --窝法乙烷 儿法梦碎 2024年12月7日 (六) 09:12 (UTC)[回复]
那“二次元”理论上可以独立条目了，如果既不对应“ACG”也不对应“动漫”。--SuperGrey (留言) 2024年12月7日 (六) 09:28 (UTC)[回复]
没感觉需要地区词转换。对重定向中立，ACG接近主流文化，但其他“二次元”义项在人类文明、科学中也非罕见，只是声量低。重定向后ACG条目顶部会多一个消歧义，对直接访问ACG的用户或形成负担。--YFdyh000（留言） 2024年12月7日 (六) 06:34 (UTC)[回复]
顶部消歧义不过一句话，还不至于形成负担吧……--SuperGrey (留言) 2024年12月7日 (六) 06:49 (UTC)[回复]
不同时代的词吧，ACG出现早很多，指代动画、漫画、(Gal)Game最简单的关联，“二次元”和“三次元”相对，指作品中的虚构世界（或者说纸片人——相对于我们现实三维立体的，他们在媒体上是二维平面的）和现实世界。是后来“二次元”语义迁移了，指代ACG的相关的关联。——Sakamotosan路过围观 | 避免做作，免敬 2024年12月8日 (日) 05:12 (UTC)[回复]
或者说的人有不同的，爱好者可能偏好ACG，主流文化或者非爱好者的话会偏好“动漫”、“二次元”等。——Sakamotosan路过围观 | 避免做作，免敬 2024年12月8日 (日) 05:14 (UTC)[回复]

人物立场分类

有些人物的分类有反共主义者、支持统一、持不同政见者等立场的分类。那些分类是的根据和原因？-- 菜国人 ※聊天 2024年12月8日 (日) 23:19 (UTC)[回复]

“是的根据和原因”？部分此类分类可能有原创总结和非中立成分。条目内容及来源应该显著支撑分类，有争议的划分交由条目讨论页决定。--YFdyh000（留言） 2024年12月9日 (一) 04:33 (UTC)[回复]
原因是之前的分类:支持台湾独立的艺人被提删而相关的分类主要依赖中国大陆官方对于台独活动的定义。（参与过相关活动就被视为台独。）----甜甜圈向资瓷韩国戒盐的台湾政党致敬！ 2024年12月9日 (一) 11:14 (UTC)[回复]
除非有明确且一致的表态或学界认同，不然实际是“被xx指”，用此分类名不妥。如果是曾因某事被批评，更是有分析或观点成分，看上去违背断言及生者传记。--YFdyh000（留言） 2024年12月9日 (一) 11:22 (UTC)[回复]
那如果是定义模糊的话，那是不是只能使用被中国大陆指控参与台湾独立活动的艺人。（因为站内有支持两岸统一的艺人分类，那相对应的也应该有支持台湾独立的艺人分类以平衡两方立场。）以及支持两岸统一的分类，会不会因为模糊定义为由删除。（有部分人会随时转换立场。）----甜甜圈向资瓷韩国戒盐的台湾政党致敬！ 2024年12月9日 (一) 11:37 (UTC)[回复]
“中国大陆”无法“指控”，可能需要更具体，但分类意义变小、特定例子会出现争议（不同级别，非正式地指控或批评，以及转变，无法区分），可能更适合列表？--YFdyh000（留言） 2024年12月9日 (一) 12:12 (UTC)[回复]
还有我有制作关于反共网红的模板，我所做的分类是有根据这种资料判断的 菜国人 ※聊天 2024年12月9日 (一) 13:04 (UTC)[回复]
被中华人民共和国政府指控支持台湾独立的艺人？--糯米花（留言） 2024年12月10日 (二) 09:08 (UTC)[回复]
我不确定各种部门、人员或官方报刊上的批评能否都归类到指控、代表中国政府。依旧感觉列表会更清晰。--YFdyh000（留言） 2024年12月10日 (二) 09:23 (UTC)[回复]

是时候在阿富汗条目及模板挂上塔利班的旗帜了吧？

喀布尔陷落已经三年了，而民族抵抗阵线的声音也已经消失了三年，可以确认的是塔利班已经基本掌控整个阿富汗地区，是时候让阿富汗的旗帜换上塔利班的了。--糯米花（留言） 2024年12月10日 (二) 09:03 (UTC)[回复]

应该清点阿富汗旗帜模板使用，并统一执行替换。另外，叙利亚部分也可以开始考虑。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月10日 (二) 12:03 (UTC)[回复]
其他领域暂不清楚，但体育领域暂且不能换，塔利班不让女性参与体育运动，是不可能受以国际奥委会为首的国际体育界认可的。当然换塔利班旗帜的时候也要考虑塔利班政权不受国际大部分国家及联合国承认的事情。--💊✖️2️⃣3️⃣（留言） 2024年12月10日 (二) 12:35 (UTC)[回复]
体育、国际组织明确保留旗帜的部分继续使用旧旗帜？--糯米花（留言） 2024年12月10日 (二) 13:39 (UTC)[回复]
基本上明确使用阿富汗伊斯兰共和国名义活动的继续使用塔利班攻占喀布尔之前的旗帜，三年了也没看到有什么国际组织承认塔利班政权。--💊✖️2️⃣3️⃣（留言） 2024年12月10日 (二) 14:29 (UTC)[回复]
感觉在表示地点的地方可以用上塔利班的旗帜了。--糯米花（留言） 2024年12月11日 (三) 10:21 (UTC)[回复]
其实中维基本滥用旗帜……英维是规定除了体育比赛、军事冲突、行政区划等极少数情况之外其他情况一律禁止使用国旗的（我说的就是信息框）。我认为大部分情况不使用任何旗帜即可。--自由雨日🌧️❄️ 2024年12月11日 (三) 10:46 (UTC)[回复]
话说目前有国家明确承认塔利班政权为阿富汗国的合法代表吗？--自由雨日🌧️❄️ 2024年12月10日 (二) 12:49 (UTC)[回复]
几乎没有，虽说有少数接受其“大使”者。所以我想应慎重一些。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月10日 (二) 14:27 (UTC)[回复]

其他

为管理人员任免制度检讨等事

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:申请成为管理人员、Wikipedia talk:管理员解任投票、Wikipedia talk:管理员解任投票/Mys 721tx/第2次。

近期又一管理人员解任投票，甫应用安全投票之新制，技术实务运作尚难称熟稔；又逢显著外来干涉及共识形成程序疑虑，遂致前所未有之困窘，乱象丛生、弊端频出，社群矛盾对峙趋于激烈，此实无庸置疑。与此同时，定期审视更新管理人员任免制度，有助于人才新陈代谢，充实本站进阶维护量能。时值仲裁委员会组织筹备停滞之际，“远水难救近火”，故谨以此话题为首，先行就管理人员任免制度若干既存问题略作检讨，望社群踊跃发表意见。改革路程自不必操之过急，但求气象有所更新尔。本人谨提出三个大问题，社群可拨冗予以回应，或自行提出其他值得专门讨论之问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月18日 (日) 18:29 (UTC)[回复]

安全投票问题

目前，本站之管理人员任免案，均采行安全投票制度。安全投票之匿名，优缺点一体两面，优点在于得脱离现实外力束缚，保障自由表达意见，有助于完整呈现社群意志；缺点则在于几无制衡极端之手段，如此次投票之若干附言，或因涉及与当事人之私人恩怨，极尽猥琐下流之能事，对部分群体及特定个人之攻讦、人身攻击及无理羞辱等暴言（本人不拟重述各种不堪入耳之文字于此，请自行阅读相关内容），不仅早已背离解任投票本身形成有效共识之意旨，更远远超出社群应容忍之文明底限，而显难以“可受公评”为借口。此外，安全投票虽号称得以防堵大规模公然拉票之威胁，惟迄今其效果不仅有待商榷，而社群因该制度高度封闭之特性，反而难以协助查核投票细节；如此次投票虽有严重扰乱之指控，但仅有少数电子邮件等书面证据，社群无法对比既有编辑贡献，或额外确认许多可疑相关内容。又安全投票长期未能由本地社群完整掌握，须受制于全域社群等客观限制；投票设定程序繁琐冗长，更屡生不可抗力之技术问题，若与其他因素叠加，结果甚至可能损及管理人员任免案本身之公信力。安全投票本为预防若干外部势力之现实威胁而设，此种威胁既已有消退迹象（与本站志趣不合之同志，多已分道扬镳不复归），加之以前述安全投票之弊端，虽难谓前述恶意影响荡然无存（此处须特别强调仍不应低估危险），惟两相权衡下，认为有酌加商榷该制度应用之必要，至少亦应有些许合理讨论。谨尝试提出问题如下：

一、社群过往执行安全投票，就可自行控制之部分（不包含须迎合全域动态之技术安排等），有何应从速改善之处（如事前人事选定等筹备作业、事后点票及公告程序等）？
二、社群应是否继续于管理人员申请及管理员解任投票采行安全投票？或研议若干指标，持续评估是否沿用，乃至于采取行动，制裁投票过程可能出现违反方针与指引之举？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月18日 (日) 18:29 (UTC)[回复]
就管理员解任而言，我个人觉得非常有必要返回公开讨论的机制。
1、安全投票所带来的“隐私”实际弊大于利，共识应当是一个持有不同意见的人互相尝试说服对方的过程，而无法回复他人意见导致事实查核无法有效反驳（例：Bluedeck原话说不至于不限期封禁，在解任界面持续被说成第三方管理员不认同可构成查封理由，而Bluedeck实际上会有限期封禁。）另外，安全投票对于外部影响有混淆的负面效果，如果有人平时没有编辑的突然在解任案上发表意见，则可能是被拉票。公开投票则让社群更能够找出可能影响。
2、安全投票程序复杂，给志愿者带来不必要的工作
3、未发现公开讨论有哪些弊端，目前的恶意影响有利用信息不透明的嫌疑，因此不认为站内投票会加强恶意影响。--0xDeadbeef (留言) 2024年8月19日 (一) 02:35 (UTC)[回复]
1、可自行控制之部分之后基金会可能允许直接在本地维基上举行安全投票，有关要求可以跟基金会提。
2、安全投票可以保证意见不受干扰，虽然WP:暴力威胁风险降低，但也有公开表达意见者遭受WP:骚扰的问题，因此社群应继续采行安全投票。
3、对于制裁投票过程可能出现违反CIV、PA等投票内容，应该可以宣告辱骂他人等违反方针的投票无效，相信很多人就不会发出违反方针的内容了。必要情况下也可以请求基金会协助，因为技术上还是能找到这个人的。
4、投票前就可以讨论并尝试达成共识，投票中也仍然可以在站内讨论，也可以回复他人意见。另外也建议公开投票人名单即可找出可能的影响。
--桐生ここ★[讨论] 2024年8月19日 (一) 03:34 (UTC)[回复]
有公开表达意见者遭受WP:骚扰的问题 - 如何证明安全投票减少骚扰，或公开投票骚扰现象会更多？ 0xDeadbeef (留言) 2024年8月19日 (一) 11:18 (UTC)[回复]
使用安全投票，骚扰者不知道你的态度，所以根本不会骚扰你，因为他根本不知道你的意见和他一致还是相反。使用记名投票，骚扰者知道你的选择和他不同，自然可以骚扰你。你维现在也有邮件骚扰这种事。--桐生ここ★[讨论] 2024年8月19日 (一) 13:07 (UTC)[回复]
这个和安全投票防止暴力威胁的原理是差不多的。--桐生ここ★[讨论] 2024年8月19日 (一) 13:10 (UTC)[回复]
并不觉得这种未经证实的事情（你只是提供了“公开投票可能有更多骚扰行为”的解释，你并没有证明这实际上会发生）可以作为以投票代替讨论的理由。共识就应该以讨论来产生，安全投票只会导致原本愿意沟通的人更加两级分裂（参考此次解任案）而对于对方的合理观点不予理会。--0xDeadbeef (留言) 2024年8月19日 (一) 13:17 (UTC)[回复]
附议。甚至之于管理员选举等重要议事事项也未尝不能恢复到公开投票的模式。--SheltonMartin留言|签名 2024年8月20日 (二) 06:31 (UTC)[回复]
@SheltonMartin：可否澄清一下此附议是指哪一个留言--0xDeadbeef (留言) 2024年8月20日 (二) 12:58 (UTC)[回复]
您的。--SheltonMartin留言|签名 2024年8月22日 (四) 02:37 (UTC)[回复]
(！)意见 虽然安全投票可以很好地隐藏发言人，并且在结束前无法得知意见，但这也催生了一些可从本次投票窥见的问题。A. 安全投票能保护投票人，可能会有人抱着找不到我的心态投票，导致一些公开投票不会出现的留言；B. 依WP:投票不能代替讨论，隐藏意见对共识的取得是致命的，无疑盲人摸象。就好比辩论双方只能写意见到白板上，裁判喊321同时亮牌子并直接打分。纵观RFA/AFD投票，经常会有人被他人说服后改票。
直接取消安全投票也可，但我也想了两种不成熟的折中方案，供社群参考，抛砖引玉：
先行投票是否启用SecurePoll
在依方针举行SecurePoll前，先请各位维基人对是否启用安全投票进行投票。投票完毕后，则按照结果正常执行程序。补充：也可考虑仅允许投票选择投票方式的用户参加正式投票，此举一可以避免群发讨论页信息，二可提前筛选用户。
安全投票之优势在于避免受他人威胁与保护自我隐私，如果上述二种诉求不强烈，大可采用更便捷的公开投票。缺点则会使过程冗长。
自愿隐藏投票者
与旧投票方式无异，但是用户可自行选择隐藏投票签名者。目前能想到的办法是请求监督隐藏编辑者用户名？
优点是便于划无效票，并及时知道他人意见以供参考。缺点则会增加监督工作量。——即请秋安 ZhaoFJx(论•欢迎签名) 2024年8月20日 (二) 15:52 (UTC)[回复]
不觉得两方案可行，第一方案在原本SecurePool之上更加浪费时间，而不一定就解决投票代替讨论这一问题。第二方案，首先技术层面上就很难做到，其次也阻止不了“写下歪曲事实或诽谤的意见就走人”这种情况（因为如果实际匿名，那监督员不应知道是谁留下意见，而如果监督员知道所谓匿名的意义也就消失了，与其把扰乱用户揪出来的责任交给监督员不如公开让社群看到是谁）--0xDeadbeef (留言) 2024年8月24日 (六) 07:19 (UTC)[回复]
所以直接取消掉安全投票转公开投票也挺好的，不过还是要看社群共识。对第二个方案我想补充一下，显然不符合事实的投票质询回复来来回回，自然可看出谁有理。而且可以考虑允许监督员作为受信任用户监票并记录，同时在争议情况下综合意见判断特定投票是否有效。——即请秋安 ZhaoFJx(论•欢迎签名) 2024年8月24日 (六) 09:09 (UTC)[回复]
我有替代方案就是同时进行公开投票和安全投票，担心有安全风险或遭受暴力威胁骚扰报复的情况下可以登记为安全投票投票人，然后这些人使用安全投票，其他人使用公开投票。--桐生ここ★[讨论] 2024年8月24日 (六) 17:37 (UTC)[回复]
仍不能避免此制度遭滥用。另一个想法是恢复公开投票，但允许有必要者向第三方行政员（或管理员？）报备后使用未公开分身账号投票。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月26日 (一) 07:15 (UTC)[回复]
若那些留言严重到需要处理，社群完全可以请求基金会处理，而无需因噎废食。想想为什么基金会选举使用安全投票？为什么运动宪章使用安全投票？为什么UCoC使用安全投票？为什么en仲裁委员会使用安全投票？如果社群不打算彻底改革管理员任免，停止以投票决定结果，改成就某人是否能担任管理员一题不设时间限制辩论至得出共识为止，那么就不应该对投票制度倒行逆施。--桐生ここ★[讨论] 2024年8月26日 (一) 07:56 (UTC)[回复]
某些纯粹是道德低下的行为，如果换成公开投票，当事人不见得就敢如此在自己的签名前面大放厥词，就算坚持要发，至少也能公开为自己愚蠢的言论负责。我当然亦不会幻想这样做能解决所有问题，但肯定能解决不少。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月26日 (一) 15:36 (UTC)+1 [回复]
(！)意见：敝人在此结合上方“仲裁委员会”相关讨论斗胆提出意见。首先个人仍然倾向采行“安全投票”，既然采行此方法的各种用户投票偏好留言和外部干扰等相关影响难以预期，那么即便恢复公开讨论，也难保可杜绝此类影响，反倒留言的用户须承担更多所处地域和立场偏好所带来的相关风险，而且如果采用公开的途径检视或“审视”是否有人趁此机会提出“不公道”或偏颇的留言，个人觉得似乎变成一种对用户意愿或意见偏好进行言论审查的作法，人们反倒因为有所忌惮而无法表达真实偏好，进一步而言，既要人们表达意愿，又忌惮于让人们自在发言或选择，似有矛盾之处，个人担心可能导致每个用户的意见受到压力终究无法在此时呈现；长久观之，言论空间会否更为限缩呢？在表达个人真实偏好时，必须“先考虑提出具说服力或相当参考价值的观点”才敢发言，此种前提会否加诸用户自我审查的压力呢？此种压力是否必要？又或者使偏好表达更趋近于某种“立场正确”的形式？尤其在已经具备激烈争端，或者就是要表达自身立场偏好的时刻，个人认为值得深思。
再说投票当下，用户看不见其他人的留言和意见，投票后的结果，我认为也是众人各自参考，不论是否满意，既无法阻止人们从留言意见中寻求个人偏好的自我印证和反馈，也不具备颠覆或改变投票结果的影响力，各种留言反倒可能只是“偏好选择的顺势表态”而已，我倾向认为他人既不须陈义过高，也不须全盘认可。反而对身处争议的相关当事人而言，是否在此可能遭受他们认为“不公允评价”的过程中，受到不必要的恶意对待？社群是否提供当事人为自己发声、澄清、阐明或如何自述的机会，以降低不必要的负面影响？个人认为或许在相关页面中，投票结束后，可以提供当事人自我表达或社群协助点明显然不妥当恶意留言的机会。
个人会认为，在不受拘束、自由表达的前提下，其实用户发言的自我克制，可能是更值得被期待的。人们是否在意自身发言内容所抱持的心态和出发点，以及对他人的影响？无法一以概之或强求，但或许可以期许有些人会多一点考量，这有待时间验证。因此，敝人的想法是，可以考虑增设一种象征性的权限，名称大致是“社群事务协调员”之类，定义为：“于平台活动和事务中可与其他用户协作，于社群事务所表达言论和观点对社群关注的公共命题具相当程度参考性，惟不具有其他显明特殊、站务或社群事务权限。”而现正规划的“仲裁委员会”往后（比如此次选举以后）或可参酌此权限，甚至采机动编组，应实际案件需求组成。“社群事务协调员”的用户参选资格不高于“仲裁委员会”，投票资格依现行规定，“社群事务协调员”内容大致如下：
1.所有社群成员互相投票，形式可参照先前的“全域社群事务协调员”（好像是这个名称），但更为简化，用户可自行选择是否对他人发问或应答他人问题。每年一选，员额可以“社群当下具投票资格用户的1%”之类订定（比如3000人取30名、3500人取35名等），换言之在第一次选完后，往后每年随社群用户人数增加按比例新增增补员额。
2.持权状态同于其他站务权限，而除权条件为自行卸任除权、辞职、不活跃（一样不活动半年），或经客栈讨论达共识除权。
3.选出的协调员名单，为“仲裁委员会编组候选名单”，仲裁员名额和组成型态可依往后编组组成前所获共识，或者按照现行共识也行，也就是往后可能机动调整当下的实际编制之类。
4.具管理员资格的用户为协调员当然当选人员，可不列入协调员候选名单；其他用户依所获票数高低依序入选。
5.当（第一次或往后）仲裁委员会编组成立后，仲裁员编组有效期限可依现行共识，或于案件结束后解散。
6.往后增补的协调员所获票数，列入既有的协调员当选名单排序。
7.下一次仲裁委员会编组成立前，可从既有协调员名单中参照用户得票数高低，直接在征询当事人意愿后，列入委员会编组或候选名单，往后的历任仲裁委员会编组组成依此类推。随着旧有协调员是否有意愿、逐渐淡出、不活跃或不适任，自然可依名单往后逐名参考或征询“仲裁委员会”人选。
8.自然情形下，名单所列协调员可能逐渐增加。
个人倾向所有曾经或现在在此社群活动的用户，其编辑等活动可得到或许某种相对持平的阶段性评价，也或许可以某种程度降低“仲裁委员会”会否因“可能具备太大影响力”引起用户间的忌惮，毕竟如果此机制的成形和实现成为“另一个具特殊效果争执标的的开端”，对社群相关当事人和往后用户产生其他各种影响，美意不尽完整呈现就比较可惜了。个人意见，稍显冗胖，供参。--Kriz Ju（留言） 2024年9月4日 (三) 17:00 (UTC)[回复]
@Kriz Ju: 我仔细读完你的留言，我只能说我没看到你对于安全投票相对于公开投票的好处说出了个所以然。如果你想回复我这里的话我希望你能够提供一个完备点的逻辑（因为X，所以Y，所以安全投票比公开投票好）
对于为什么我个人认为公开投票会好，我上面已经写下了我自己的理由，其中主要有提到秘密投票无法回复他人意见导致事实查核无法有效反驳、公开投票让社群更能够找出可能[拉票]影响、安全投票程序复杂、不认为站内投票会加强恶意影响等论点。
那你这里有提到对于公开投票下言论空间会否更为限缩这一论点我想回应的是：不应假设“言论自由”就是好的。从公开投票和秘密投票的留言对比之下可以看到，秘密投票下留言更多存在不尊重其他编者、不文明、嘲讽、阴阳怪气的行为。我姑且认为这是因为秘密投票导致无法查询到发言人，所以大家可以畅所欲言，展现出人性丑陋的一面，但这就是好的吗？维基百科是什么地方？是大家合作写百科全书的地方。而畅所欲言的“言论自由”有助于编者合作吗？有助于社群风气吗？我认为没有。为什么维基百科需要有文明方针，限制“言论自由”？因为维基百科不是能够接纳任何人的地方。对于那些一直不尊重其他编者，颠倒事实的人，我们有必要请他离开我们社群。所以: 在表达个人真实偏好时，必须“先考虑提出具说服力或相当参考价值的观点”才敢发言，此种前提会否加诸用户自我审查的压力呢 - 我认为此压力是好的。对社群风气有正面影响。
对于你想推行的事务协调员我自己只能看完觉得太麻烦。而且对于你所在的讨论串公开讨论和秘密投票的讨论无关。--0xDeadbeef (留言) 2024年9月6日 (五) 15:18 (UTC)[回复]
对此命题，我不确定与0xDeadbeef阁下切入的视角是否全然一致。个人认为，虽然乍看是如您所说言论自由的相关命题，这肯定没错；而就个人所见以及随后的衍生观点，这是个小有复杂的命题，我认为这涉及几个面向，是包括言论自由与规管、人身安全、公众言论的影响力和传播效果、社群行为与文化、社群争端和价值冲突、授权信任的基础以及可能的社群永续经营等面向构成的系统性命题。恕敝人暂无才学和心力一一对以上项目细论并提供确切的科学客观理据。退一步而言，是否公开投票、利弊如何、留言标准守则等事宜，端视众人意见，比较简便的办法或许也可以在发言页面加注个比如“请注意文明发言和社群守则”之类的警语即可（不论该页面是否在第一时间公开），而且技术上应该也可以找到留言的使用者（必要性姑且不论）。至于您关切的焦点，个人在上方也已经提出看法乃至针对问题的具体作为，也纯粹对于以上涉及命题面向提出发想，无意企图证明什么，这也并非一般自然科学命题，更多时候我认为是一种综合性的选择评估，当然也是随人好恶参看，所以是否符合您的论证模式和喜好，就恕敝人由人随意看看、随喜心证了。感谢拨冗。--Kriz Ju（留言） 2024年9月8日 (日) 12:23 (UTC)[回复]
技术上应该也可以找到留言的用户 你是指安全投票？据我所知，安全投票完全匿名，无法从留言找到用户，于是才会有人身攻击等乱象。
我并非要将此作为多么严肃的命题来探讨，我知道里面包含很多不同元素，但我仅仅认为你所提出的理由不完整足以说明为何RFDA应当需要保留安全投票而已，不过既然你也不愿意继续讨论具体理由，那就罢了。--0xDeadbeef (留言) 2024年9月13日 (五) 09:21 (UTC)[回复]
我没什么意见，理据确实不足，阁下喜欢用什么投票就看众人意见，谢谢。另外，若有冒犯，请各位高抬贵手。--Kriz Ju（留言） 2024年10月5日 (六) 16:52 (UTC)[回复]
阁下所言“未公开身份账号”，或者编辑次数不达标账号，若没资格进行管理员存废之安全投票，那么该用户能自行投票吗？投票用户不是系统筛选出的符合资质之用户而后发出的邀请通知吗？所以我不明白不符合投票的人如何能进行安全投票，此事如果可能，当不会现在才存在和发生。
  • 另外，安全投票既然是之前的既定存在，必是前人多年经验和智慧之结晶，也是经过审慎讨论的。实行多年，现在为何就不合理了？当初都知道有公开投票，为何搞出安全投票，必是因为要解决出现的问题和隐患，那么现在这些问题就不存在了吗？正如已经有人提到的那样，说白了，管理员是人，或许发生官官相护、与某交情相投之类事，即便投票人有百分之一二可能招致报复类对待，也是应该考量的，这是民主制度人性化思维方式。我记得，在安全投票之前，对于该管理员的争议讨论是有很充分的双方意见交流展示的，关心社群的人想必大多都知道，罢免相关管理员的呼声也并非这一次。以此次事件为例，主要提议罢免的用户，之所以提出罢免，实在是相关管理员在多次争议沟通后不能改进并且让提议者看不到诚意，严重挫伤了社群的积极性。那么，在此种长期无法沟通解决的磋磨下，就剩下一个公投了结。不可回避，如若一个管理员在位时刚愎自用盛气凌人甚至歧视弱小，他必然是觉得有同伙撑腰而势大不可动摇，大多数反感之人考虑自身得失恐怕只得沉默，而安全投票恰恰给予了沉默多数一个机会。社群的真实声音才得以释放，这对于管理员和管理层是个提醒。靠疑心拉票来质疑安全投票的结果并无意义和根据，如果存在此类事，公开投票就不存在了嘛？
  • 还记得约三年前曾在社群里很活跃的一群人，动辄就琢磨更改规则的某些人，有朝一日在维基上层高管整治后暴露了很多问题。过去我们小编只能心中怀疑而没根据批评的事，都成了真。那些人被清理出去了，维基平静了一段时间。少了些中共的水军就少了破坏性导致的消耗战。那时候，如果社群能正常实施罢免之权力，及时限制不合格之人的权限，那么就不会发生大面积清退的事情，也不会有人被误打。当时也有人遗憾，觉得应该有个机制给予一些人机会。须知天理循环，蔑视别人机会，以狭隘之心对待社群用户之管理者，必遭反噬。与其想改变安全投票之规则，不如加强管理人员的测评机制，在一定时间内打分，几次分数不高，就降级或解职。因为有降级的过程，对上进者是个提醒，也是改正之机会。因为现实世界不在一个水平面，中国大陆与世界民主制度为敌，大陆网络封锁，而翻墙出来的管理人员本身的安全性以及对他人的安全性都与其他自由国度不同，为保障社群真实的声音，对管理者经常进行群众测评，德贤之人上，狭隘之人下，这才能让维基百科不离初心。--Nice-walker（留言） 2024年9月30日 (一) 20:46 (UTC)[回复]
我同意阁下的提议，但是无论用什么方式隐藏投票人的用户名都应该不会立即生效（监督员不可能在有人投票后立即隐藏他的用户名）--Wikipedia_Creeper（留言） 2024年9月23日 (一) 18:03 (UTC)[回复]
似乎有人提出匿名投票能够自由表达意见，那么能否在投票期以前用SP或者其他途径匿名征集意见？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年9月9日 (一) 01:39 (UTC)[回复]
这让我想到应开放亮票（可自由选择）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月11日 (三) 04:28 (UTC)[回复]
我个人没法想象有哪些只能匿名投票表达的意见而公开投票无法表达的。有例子吗？
还是说，有人会因为无法匿名就无法表达意见，那我很好奇这样的人是出于什么原因，这些原因是因为投票程序本身，还是此人的个人因素？--0xDeadbeef (留言) 2024年9月13日 (五) 09:23 (UTC)[回复]
这种例子恐怕不少，只是投票意见的正当性在匿名后更难审视，但意见也会更大胆。想到一种极端情况，交互禁制是否会干涉投票意见与程序，您觉得那些当事人有哪些权利。--YFdyh000（留言） 2024年9月13日 (五) 15:18 (UTC)[回复]
出处是Wikipedia talk:申请成为管理人员#c-Temp3600-20240323034300-SunAfterRain-20240331114100[锚点失效]，和记忆中的有点偏差。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年9月24日 (二) 02:18 (UTC)[回复]

对于离任转为公开讨论已公示，见下方。关于RFA是否应该回到公开讨论，个人认为须继续讨论，比如是否在管理员选举流程下附加自由提名公开讨论流程（英维目前在尝试的做法）或是直接废除以安全投票来管理员选举这一流程，完全回到过去的公开讨论？0xDeadbeef (留言) 2024年9月18日 (三) 11:04 (UTC)[回复]

考虑到WP:IBAN，或许可以先采亮票，如有问题再采安全投票也行--Mykola（留言） 2024年9月22日 (日) 16:49 (UTC)[回复]
个人确实无意见，以最适当形式即可。--Kriz Ju（留言） 2024年10月5日 (六) 17:09 (UTC)[回复]
恐怕目前首要折衷办法确实还是亮票。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年10月14日 (一) 06:37 (UTC)[回复]

RFDA转为公开讨论

不通过
暂未有共识之提议。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年10月26日 (六) 21:41 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

因以上讨论已对管理员解任投票回到公开讨论取得共识，且讨论已达30日，现以WP:7DAYS为此变动公示。

维基百科:管理员的离任：

现行条文

解任程序

[..]

  • 准备：在联署通过后，开始进行安全投票的准备程序。同时，被解任人有5天的答辩期，对于解任申请中指出的问题进行答辩。被解任人（或他许可的其他用户）可以整理答辩内容，并置于解任理由之下，这些内容不被折叠。如果被解任人在5天内没有答辩，被视为无答辩意见，不过仍可以继续发表意见。
  • 投票：安全投票开启后，应至少持续二周。符合人事任免投票资格者（不包括被解任人）可以投支持票（同意解任）或反对票（反对解任），投票人需在留言框按照指定格式投票并给出理由。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。重复投票和傀儡投票将被视为无效票。
    • 监票：若本地有两名或以上监督员在安全投票开始前表示愿意监票，则由愿意执行监票工作的监督员与其他监管员共同协助监票。若本地能够执行监票工作的监督员不足两人，则由监管员独自负责监票。
  • 计票和评估：在投票时间结束后，由监票者计算出得票比率。有效表决的最低总有效票数为25票。如总有效票数低于25票，则不论结果如何，均视为解任案不通过。若总有效票数达至少25票，且支持解任票数多于一半者，则投票通过。惟怀疑投票结果被作弊或其它不恰当行为严重影响，可由行政员讨论决定该次投票是否有效。
    • 解除权限：投票结果为解任时，则由行政员除权或将社群的共识提报给元维基，申请解除该管理人员的权限。
提议条文

解任程序

[..]

  • 准备：在联署通过后，被解任人有5天的答辩期，对于解任申请中指出的问题进行答辩。被解任人（或他许可的其他用户）可以整理答辩内容，并置于解任理由之下，这些内容不被折叠。如果被解任人在5天内没有答辩，被视为无答辩意见，不过仍可以继续发表意见。
  • 投票：答辩期过后，进入投票程序。投票期为14天，符合人事任免投票资格者（不包括被解任人）可以投支持票（同意解任）或反对票（反对解任），也可以在讨论区发表意见，无论支持票还是反对票，投票人需给出理由。联署人自动计为支持解任，但仍可以在投票期间改变意向。投票者可以在投票期间随时改变自己的决定，其态度按投票期结束时为准。重复投票和傀儡投票将被视为无效票。
  • 计票和评估：有效表决的最低总有效票数为25票。如总有效票数低于25票，则不论结果如何，均视为解任案不通过。若总有效票数达至少25票，且支持解任票数多于一半者，则投票通过。惟怀疑投票结果被作弊或其它不恰当行为严重影响，可由行政员讨论决定该次投票是否有效。
    • 解除权限：投票结果为解任时，则由行政员除权或将社群的共识提报给元维基，申请解除该管理人员的权限。

公示7日，2024年9月25日 (三) 11:04 (UTC)结束 0xDeadbeef (留言) 2024年9月18日 (三) 11:04 (UTC) 暂停公示：用户请求暂停公示以便讨论——即请秋安 ZhaoFJx(论•签) 2024年9月20日 (五) 00:27 (UTC)[回复]

假设骚扰及拉票的情形出现（e.g. Mys 721tx 第一次 RFDA），那社群应如何在没有安全投票的情况下应对？当然，幸运地当时有管理员愿意封禁，但不幸地情况无法控制又如何处理？再者，既然可预见仲裁委员会将于不久的未来成立，或许会否交由他们决定需否在特定情况下使用安全投票？谢谢。--SCP-0000（留言） 2024年9月18日 (三) 11:39 (UTC)[回复]
该怎么应对就怎么应对啊。这个讨论与投票是否公开好像没有太大的联系，请问转为开放投票会造成更大的骚扰/拉票影响吗？（公开的拉票影响大家都能看到，相对来说能处理，而不公开投票则是有站外影响可能无法处理的考虑）另外上方“其他意见”章节已有讨论仲委会是否应有主持投票事宜的权力，但是估计共识认定仲委会没有这个权力。--0xDeadbeef (留言) 2024年9月18日 (三) 11:48 (UTC)[回复]
的确，公开投票不会造成“更大的骚扰/拉票影响”，但用户因担忧骚扰而不愿投票的问题又如何解决？现在安全投票可确保用户不受站内外骚扰影响，自由地发表意见，但往后改为公开投票时该怎样做？站内外骚扰及干扰投票的现象即使 OA2021 前后以至 WMLO 被封禁后仍然存在（当时 rfda 改为安全投票某程度上亦因为这样），个人不见得社群现在存在足够能力解决此根深柢固的问题，至于仲裁委仍未成立，他们能否解决仍为言之尚早。谢谢。--SCP-0000（留言） 2024年9月19日 (四) 15:28 (UTC)[回复]
有道理，那么确实需要更多讨论。我现在在手机端，如果有人方便的话帮忙撤下公示继续讨论。--0xDeadbeef (留言) 2024年9月19日 (四) 23:16 (UTC)[回复]
“不公开投票则是有站外影响可能无法处理的考虑”，公开投票也是会有同样的问题啊（比如以往尚未引入安全投票的RFA/RFDA）。当年引入安全投票也是因为有些人认为可以减轻站外影响的问题，因为站外有意影响投票的势力更能够借由公开投票去“确保”各个特定用户是否真去照他们的动员投下了“支持”或“反对”。以往此类案例并不少见，甚至也有过用户反应因为其公开投票时的表态不合某站外人士的心意，被施压威胁而划票改票的情形出现。具体案例我就不说了，为了保障相关人士的隐私和安全，但相信经历过当年情况的很多社群成员会知道我所指为何事。-Peacearth（留言） 2024年9月19日 (四) 16:39 (UTC)[回复]
(？)疑问：Mys_721tx的RfDA是否需要重选？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年9月18日 (三) 11:40 (UTC)[回复]
与这个讨论串关系不是很大，可以单独开一个章节讨论。--0xDeadbeef (留言) 2024年9月18日 (三) 11:49 (UTC)[回复]
如果社群认为Mys解任案反映了RfDA有问题，那么明显Mys解任案是有问题的。有问题就应该重审。所以和本讨论串应该是相关的。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年9月19日 (四) 21:01 (UTC)[回复]
是否应就此事咨询WMF T&S？--在下荷花，请多指教（欢迎签到） 2024年9月18日 (三) 13:10 (UTC)[回复]
当初社群以OA2021为由为RFA使用安全投票，又后来决定RFDA也同样使用安全投票，而这些决议只有OA2021是与T&S相关，后面两个据我看来好像都是社群自己推行，所以个人也不认为这个提案需要咨询。如果认为有需要，还请哪位愿意的去通知一下吧。--0xDeadbeef (留言) 2024年9月18日 (三) 14:24 (UTC)[回复]
已咨询基金会意见，不过应当不影响提案的讨论。--在下荷花，请多指教（欢迎签到） 2024年9月20日 (五) 03:06 (UTC)[回复]
建议同时进行安全投票和公开投票，希望安全投票的人可以登记为安全投票投票人。--桐生ここ★[讨论] 2024年9月19日 (四) 12:52 (UTC)[回复]
另外既然RFDA被一些人认为不能使用安全投票，那么RFA是否也应该讨论是否继续使用安全投票？--桐生ここ★[讨论] 2024年9月19日 (四) 12:54 (UTC)[回复]
技术性(－)反对，应该等通告发完至少一周。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年9月19日 (四) 21:00 (UTC)[回复]
我对于RFDA废除SecurePoll持保留态度。Sanmosa Miyamoto Miyoko 2024年9月21日 (六) 23:25 (UTC)[回复]
(－)反对废除安全投票，废除安全投票会导致骚扰问题等担忧。且很难解释为什么RFA要安全投票，RFDA就不需要安全投票。WMF的选举都是安全投票也说明了安全投票的一些优势。--AnnaBeiyan（留言） 2024年9月22日 (日) 03:59 (UTC)[回复]
我在站外看到有人对Mys被罢免很不满，不知道是不是这个原因。--日期20220626（留言） 2024年9月22日 (日) 04:05 (UTC)[回复]
本人虽支持恢复公开投票，却亦认为相关共识未至充足。兹事体大，本不应如此随意。本人尤其注意到有关仲裁委员会之讨论及此话题，均有推进公示操之过急之现象，是否对社群有益，恐须特加商榷。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月22日 (日) 13:08 (UTC)[回复]
这是在说我吗？--0xDeadbeef (留言) 2024年9月24日 (二) 12:11 (UTC)[回复]
其实投票之前就可以讨论尝试互相说服对方，投票只是最终表决，安全投票和普通投票没有什么差异。如果认为安全投票影响讨论，不如取消投票，改成无限期讨论。--桐生ここ★[讨论] 2024年9月27日 (五) 00:17 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

若RfDA转为公开讨论，Mys_721tx第二次解任案是否应宣布无效重新投票

不通过
显未有共识之提议。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年10月14日 (一) 06:37 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

屁股声明：本次RfDA未投票。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年9月19日 (四) 21:05 (UTC)[回复]

赞成，且该解任案是RFDA投票中唯一使用安全投票的。——即请秋安 ZhaoFJx(论•签) 2024年9月21日 (六) 14:12 (UTC)[回复]
(？)疑问：如果认为使用安全投票是错误的因此任免案无效，那么使用安全投票的RFA是否有效？--桐生ここ★[讨论] 2024年9月22日 (日) 11:39 (UTC)[回复]
明显目前为止的安全RfA没有如此案一样有若干附言，或因涉及与当事人之私人恩怨，极尽猥琐下流之能事，对部分群体及特定个人之攻讦、人身攻击及无理羞辱等暴言；解任投票中，无法回复他人意见导致事实查核无法有效反驳所带来的危害远比管理员选举来得大。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年9月22日 (日) 13:09 (UTC)[回复]
安全rfa也有不文明的留言的。--日期20220626（留言） 2024年9月22日 (日) 13:13 (UTC)[回复]
开玩笑呢，有谁想让mys继续当管理员，明说就好了。--日期20220626（留言） 2024年9月22日 (日) 11:51 (UTC)[回复]
“法不溯及既往”，社群彰显意志，固然其间程序及执行问题颇多，仍不宜随意否认。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月22日 (日) 13:05 (UTC)[回复]
然。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年9月22日 (日) 13:10 (UTC)[回复]
(！)意见会检讨就是因为要把实际执行过程发现有缺失的部分做检讨并予以改善，如果宣布解任投票无效，那去年10月的投票是否也要无效计算？毕竟Wikipedia:征求意见/2024年管理人员制度改革就是去年选举结束时的产物。与其在弄一次RFDA,还不如看现在或明年4月管理员选举，当事人是否愿意参选管理员一职。Lily135（留言） 2024年9月22日 (日) 15:16 (UTC)[回复]
已经过完整讨论和投票，敝人认为似乎不宜也不须再持续进行上一次效果的探究。若总如此，将反复混乱。--Kriz Ju（留言） 2024年10月5日 (六) 17:01 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

涉及管理权限争议之过渡仲裁措施

此次投票，一大理据涉及管理权限特定争议。此种复杂之争议，本应考虑由具公信及专业之第三方维基人组织仲裁，详加审核相关操作及证据，并经深入思索提出报告供参为宜。“管理员的离任方针”亦明确强调，解任投票属最终手段，当有十足充分之考量而行之；若能借由仲裁措施或处分有效厘清双方权责过失，并借由沟通有效缓和争议、化解双方分歧，最终往往毋须诉诸解任。惟本地现有制度，尚未提供前述第三方仲裁措施之基础；如管理员布告板，向来无力处理特别严重之争端，而此次投票纵有若干管理员等社群成员就解任理据独立从事查证，惟其受时间、人力等客观限制，亦难称臻至完善，且未能获社群正式背书，效力恐有所折扣。近年来本站筹设仲裁委员会，固有就此问题予以釜底抽薪之可能，惟社群现阶段仍在讨论组织及人事细节，望其短时间内付诸运转、乃至于树立适当权威，自是天方夜谭。值此一过渡之际，实有赖社群即时研议临时仲裁措施，以处理涉及管理权限之争议。谨尝试提出问题如下：

一、社群对于现有个别管理员难以处理庞大管理权限争议之情况（如管理员布告板各子布告板等），有何协助应对之可能方案？
二、社群现阶段于严重权限争议及解任投票“决战”夹缝间，是否可能留有任何缓冲之选择？如比照相关权限方针，引进停权警惕机制？甚或搭配独立第三方调查制度，由行政员、管理员或其他有能社群成员联席组织，以停权当事人之临时处分，换取些许余裕，得为有限期而妥当之调查报告，而免于骤然跃进解任投票之地步？
注：有关仲裁委员会之组织细节，请继续踊跃参与上方相关段落讨论。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月18日 (日) 18:29 (UTC)[回复]

“临时”管理员任期问题

有关任期问题的条文已修改；有关明确临时管理员是否需要回答“三个问题”的提案已被撤回，关闭此处讨论。如有其他需要展开的请随意重新打开讨论。 Stang★ 2024年9月21日 (六) 06:44 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

社群晚近引进“临时”管理员机制，为尚待争取社群充分信任者提供有限期权限以为锻炼。惟“申请成为管理人员方针”指出：“临时权限与一般不限期权限无异，但需在任期结束前重新申请，并经社群投票确认，才能继续保留权限。”对于所谓“投票确认”之细节语焉不详，尤未有声明此种“临时”之有限效期是否得以连续申请无条件延长（形同“任期无限”），此于本年新一轮管理人员申请前当有所解决，方得回避无谓混乱。谨尝试提出问题如下：

一、社群是否应保留“临时”管理员机制？抑或取消之，或再研议其他制度以为替代？
二、社群是否应就“临时”管理员之任期有所限制？如限定任一期或连任特定次数以后，次轮（下轮）申请累积信任须达到正式通过门槛，否则即应收回“临时”权限，越次轮（下下轮）始得重行申请？或改为逐步提高次一任期之通过门槛，直至正式通过为止？
注：特副知目前本站唯一“临时”管理员@ATannedBurger。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月18日 (日) 18:29 (UTC)[回复]
临时管理员机制既然是提供给还没取得社群充分信任的人争取社群信任，那么临时管理员就应该把握时间让大家认可他，加上临时管理员权限与一般管理员无异，代表临时管理员在下一次申请前能充分表现，若是经过一次任期仍无法取得社群足够的信任，那或许就是暂时还不适任，因此我认为临时管理员在次轮申请时需至少达到正式通过门槛，若无法达到则应收回临时权限，下下轮才能再申请。--PC 2024年8月18日 (日) 20:36 (UTC)[回复]
我认为临时管理员机制多少还是有些必要性。不论是因为当前社群对永久管理员门槛的下调程度有限，又或者是在实务上能帮助社群多认识和了解新管理员处理事务的方式，贸然取消当前制度的话很可能导致经常被诟病的管理员难产问题再次重现。
第二个问题的话大致上同PC君的观点。考量到临时管理员的当选区间（65% ~ 75%）并没有很大，逐步提高次一任期之通过门槛究竟是需要离上次当选差多少百分比（换句话说，多少的提升才无法用误差范围/临界值来解释），为了避免此类争议，我觉得倒不如选择较为干脆的处理方式会比较洽当。--（☎）dt 2024年8月18日 (日) 20:52 (UTC)[回复]
1、若现在取消临时管理员，那么这个试验期太短，无法评判临时管理员制度效果，因此建议目前保留。
2、大致认同PC意见。--桐生ここ★[讨论] 2024年8月19日 (一) 03:40 (UTC)[回复]

总结一下讨论。讨论用户基本就临时管理员在第二次申请权限时须达到正式管理员标准才可保留权限一事基本达成一致。根据目前共识，个人提议在申请成为管理人员方针条文中修改以下内容：

现行条文

行政员须按投票中有效的支持票占总有效票的比例（支持率）判定管理人员申请是否获得通过。支持率达75%者，将获授予申请之权限（但根据全域用户查核和监督方针，用户查核员和监督员需要25票支持才能当选）。而管理员申请支持率达65%、但不足75%者，亦得获授予为期六个月的“临时权限”；临时权限与一般不限期权限无异，但需在任期结束前重新申请，并经社群投票确认，才能继续保留权限。

提议条文

行政员须按投票中有效的支持票占总有效票的比例（支持率）判定管理人员申请是否获得通过。支持率达75%者，将获授予申请之权限（但根据全域用户查核和监督方针，用户查核员和监督员需要25票支持才能当选）。而管理员申请支持率达65%、但不足75%者，亦得获授予为期六个月的“临时权限”；临时权限与一般不限期权限无异，但需在任期结束前重新申请，并在投票中的支持率达75%，才能继续保留权限。

--人间百态,独尊变态(讨论) 2024年8月26日 (一) 10:27 (UTC)[回复]

公示7日，2024年9月9日 (一) 13:19 (UTC)结束：无人对该方案有质疑，进入公示期。––人间百态,独尊变态(讨论) 2024年9月2日 (一) 13:19 (UTC)[回复]

公示通过，已修改方针。--人间百态,独尊变态(讨论) 2024年9月9日 (一) 14:42 (UTC)[回复]
给意见超过公示期了，但是咱还是写一点吧：提案人的更改给条文造成了一些不清晰的内容，咱认为应该将“保留权限”明确为“转为正式管理员”，类似于但需在任期结束前重新申请，并在投票中的支持率达75%来转为正式权限，否则将被移除临时权限。@人间百态： Stang★ 2024年9月11日 (三) 02:54 (UTC)[回复]
@人间百态、Stang：写成“而管理员申请支持率达65%、但不足75%者，亦得获授予为期六个月的‘临时权限’。此种权限与一般不限期权限无异，但应于任期结束前重新申请成为管理员，且申请支持率达75%，才能保留并取得不限期权限；否则权限将予取消，必须待下次再行申请。”如何？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月11日 (三) 04:26 (UTC)[回复]
惊人的好 Stang★ 2024年9月11日 (三) 04:28 (UTC)[回复]
不反对。--人间百态,独尊变态(讨论) 2024年9月11日 (三) 13:30 (UTC)[回复]
因为实际意思没变，再等几天无异议我就直接改了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月11日 (三) 17:06 (UTC)[回复]
@Ericliu1912 请问将被移除临时权限是指投票后立即结束还是等到期日？（如果是前者，就会不满6个月）。Пусть от победы☆к победе ведёт! 2024年9月18日 (三) 10:14 (UTC)[回复]
争议已解决，是到期日后除权。Пусть от победы☆к победе ведёт! 2024年9月18日 (三) 10:43 (UTC)[回复]

还有关于临时管理员回答三条问题的问题，虽然询问各个使用者后得出的结果是可选答，但在WP:RFA中没有列明。为了在日后的讨论中避免矛盾，便在此发起公示。

现行条文
  • 管理员被提名者或自荐者须回答三个基本问题，这些问题是：
    1. 您期望帮忙怎么样的管理事务？请先阅读管理员的介绍页面。
    2. 在所有您在维基百科撰写的条目或作过的贡献中，有没有让您觉得特别喜欢的部分？有的话，为什么？
    3. 您有没有在过去遇到任何有关编辑方面的冲突，或者是您认为其他用户造成您的压力？您如何处理这件事，以及未来遇到时您会怎么处理？
提议条文
  • 管理员被提名者或自荐者须回答三个基本问题，这些问题是：
    1. 您期望帮忙怎么样的管理事务？请先阅读管理员的介绍页面。
    2. 在所有您在维基百科撰写的条目或作过的贡献中，有没有让您觉得特别喜欢的部分？有的话，为什么？
    3. 您有没有在过去遇到任何有关编辑方面的冲突，或者是您认为其他用户造成您的压力？您如何处理这件事，以及未来遇到时您会怎么处理？
    • 临时管理员可选择不回答以上问题。临时管理员可选择直接使用上次申请的答案。

公示7日，2024年9月25日 (三) 10:38 (UTC)结束。Пусть от победы☆к победе ведёт! 2024年9月18日 (三) 10:38 (UTC)[回复]

(－)反对：权限“临时”与否，不应影响管理员必答问题回复与否之基本要求。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月18日 (三) 11:01 (UTC)[回复]
@Ericliu1912 这样好了些没？Пусть от победы☆к победе ведёт! 2024年9月18日 (三) 11:04 (UTC)[回复]
如此琐碎之事，其实不用写进指引。就如从前极少会问多次申请者是否可沿用上次申请答案一般。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月18日 (三) 11:06 (UTC)[回复]
@Ericliu1912 本人决定撤回更改。请问阁下为什么认为“不应影响管理员必答问题回复与否之基本要求”？普通管理员必须回答问题才可申请，而临时管理员再申请则可选答，这样的逻辑非常清晰。对于临时管理员而言，回答问题的确并非基本需求。Пусть от победы☆к победе ведёт! 2024年9月20日 (五) 10:04 (UTC)[回复]
不认为如此。反而鉴于“临时”权限设定一大初衷——即给予社群观察当事人表现机会——渠甚更有必要回答基本问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月20日 (五) 10:07 (UTC)[回复]
@Ericliu1912 怎么之前你还扬言道“大不了抄上次的”，现在又说“更有必要回答基本问题”？Пусть от победы☆к победе ведёт! 2024年9月20日 (五) 10:26 (UTC)[回复]
“大不了”是兜底，要不要重复回答问题是当事人的自由。这显然不代表本人对当事人期望有如此低，两者不可一概而论。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月20日 (五) 10:30 (UTC)[回复]
@CopperSulfate 可以到此发表意见。Пусть от победы☆к победе ведёт! 2024年9月19日 (四) 09:03 (UTC)[回复]
(＋)倾向支持：个人认为临时管理员申请续任（转正？）可选择不回答三个基本问题，甚至多次申请者在后续的申请中我也觉得可以不必每次都回答，首次申请必答就好。--冥王欧西里斯（留言） 2024年9月20日 (五) 23:17 (UTC)[回复]
鉴于ATannedBurger认为需要重答，本人决定撤销提案。Пусть от победы☆к победе ведёт! 2024年9月21日 (六) 06:26 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

停止以投票决定结果

不通过
暂未有共识之提议。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年10月26日 (六) 21:42 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

具体意见与前次RFC相同。在维基百科的权限得失上用投票得结果不过是拙劣的cosplay。既然这么喜欢互煮，建议改成就某人是否能担任管理员一题不设时间限制辩论至得出共识为止。——暁月凛奈 (留言) 2024年8月21日 (三) 08:36 (UTC)[回复]

所谓“投票”是有必要的，因为以社群规模永远不可能纯经讨论得出共识，最后还是会变成“类似投票”（!vote）。其实管理人员申请及解任投票理论上一直都是“类似投票”；个人反而觉得“解任投票”目前看来很有必要降低纯“投票”的成分（尽管社群整体意见仍占有极高比重）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月22日 (四) 13:53 (UTC)[回复]
有何差异，为何RFA如此特别，应该继续“类似投票”，无需降低“纯投票”成分？--桐生ここ★[讨论] 2024年8月26日 (一) 07:58 (UTC)[回复]
没办法透过纯讨论得出共识那也没关西阿，就是以后没管理员可以上任而已，这没什么啦。--~~Sid~~ 2024年8月30日 (五) 12:06 (UTC)[回复]
不用投票决定结果，难道以反对罢免的那几个人决定结果？--日期20220626（留言） 2024年8月25日 (日) 02:15 (UTC)[回复]
(！)意见：那估计会无限循环了。--超级核潜艇（留言） 2024年9月24日 (二) 02:30 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

RFA和RFDA是否要求提供理由

最近有些人认为应该废除RFDA要求提供理由：

  • 要求提供理由如同DYKC要求必须写废话
  • 判断理由是否有效造成点票困扰
  • 要求提供理由引发很多问题

也有人认为：

  • 要求提供理由对共识判断相当有帮助

提请社群讨论，如果要求提供理由没有意义，而且弊大于利，是否应该废除。如果要求提供理由利大于弊，对共识判断相当有帮助，是否应该也要求RFA必须提供理由。--桐生ここ★[讨论] 2024年8月24日 (六) 18:05 (UTC)[回复]

这可能与安全投票问题挂钩？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月11日 (三) 04:22 (UTC)[回复]
虽然有点关系，但不挂钩。公开投票一样可以要求必须提供理由，或不用提供理由。--桐生ここ★[讨论] 2024年9月19日 (四) 12:55 (UTC)[回复]
(＆)建议：若已有用户提供明确的理由，在该用户之后投票，且意见与前面用户相同的用户可以使用{{同上}}等模板。--WiiUf ——青龙出世，傲视苍穹 2024年9月21日 (六) 14:07 (UTC)[回复]

有关公开投票人列表的问题

在先前多场使用安全投票的管理人员选举之中，都依照既有共识对投票人列表进行了隐藏，使列表只能由监票人员查看。然而，在最近的一次管理人员解任投票之中，监票人对投票人列表进行了公开。个人理解这是出于对解任投票的一些“不透明”的批评的举措，但咱也希望这可以正式的定下来，关于使用安全投票的投票中，什么时候应公开投票人列表，什么时候不应公开。

  • 在管理人员上任投票中？
  • 在管理人员解任投票中？
  • （上方讨论区进行的）在仲裁委员会委员选举投票中？

谢谢。 Stang★ 2024年9月11日 (三) 02:54 (UTC)[回复]

(！)意见：个人斗胆结合相关讨论综合表达，认为各式投票结束后，投票人列表原则上应于选举结束后公开，若具备明确重大事由，可视情况特例不公开；毕竟投票这个行为本身并未透露当事人意向为何，若该行为本身对当事人已造成任何心理负担，建议当事人斟酌考量是否参与投票。至于是否在投票时提供投票意见，个人认为相关意见主要是在投票结果争议极大或临界判断时所用，界面上应具备该栏位供用户填答较佳，至于用户是否必须填答才能投票？目前个人倾向上任投票可选填，解任投票则必须填具。
至于相关争议个人认为仍回归信任度问题，不论是投票用户对投票制度或是观者对其他投票用户的信任感，但这又往往不离个人的主观评价；尤其以仲裁委员制度而言，如果往后确实具备某种决定性的效果或权限，对照上次的罢免投票，应如何评估异同或当中部分疑虑？历来此类讨论最大争点在于社群认为应该“数人头”抑或“讲共识”？长期以来论者各有利弊衡量和偏好，在此或可不论。然而重点在于，人们是否真能在更大规模的投票中，纯以就事论事、各提理据的公开争论和投票中有所共识呢？如果得到的投票结果就是共识，今日自也无须争议，重点可能还是在于“安全投票”的目的为何？以及为何全世界的大规模投票都可说是“安全投票”？个人认为关键有两个：一个在于投票或选举过程中人们的任何争论、命题、理据或偏好，在投票结果出炉前，都难以论断“前因”和“后果”是否具备得以直接、必然预测的因果关系；其次在于安全投票最大限度保障人们的表意自由，个人认为后者最为重要且关键。然而，考量中文社群的地域复杂性，又是否适合单纯数票数呢？即便试图公开讨论，某些用户在不具备客观理据的前提下，是否就不得表达特定意向偏好？而公开投票是否又如何判定该票是否有效？如此思索必然又陷入无止尽的取舍循环。若折衷由行政员裁定，也必然有站友质疑其认定标准等。既无绝对的方案，可能需要厘清相关制度之所以存在所欲彰显价值目标和实务考量取舍的先后标准。在此敝人尝试提出几个个人关注点：
1.仲裁委员是否可能被罢免？若可能，条件大致为何？个人认为这个问题的结果可能直接影响该制度运行，以及用户目前对此制度之初步评价。
2.以当前管理员罢免制度而言，和选任管理员的投票方式和界面是否有明显差异？个人倾向认为罢免管理员应更严谨审慎，原因有二：首先罢免投票是剥夺持权用户的既有权利，当事人既已获权，社群欲以“群体意向表达的制度”推翻先前选举的社群意向表达结果，并借此剥夺当事人权利，自然需要证明持权者是否因其持权而对社群的他人或事务造成何种程度的明显伤害或错误，获得证明方可决定如何处理甚而除权，因此对于罢免制度的严谨公开讨论，应该是合情合理。
反过来必有人疑问“选任管理员难道不需如此严谨吗？”持平而论，某人当选管理员获得授权，并未因此直接影响或剥夺何人权益，或是直接造成何种伤害（对当选者看不顺眼不在考量范围内，若讨论到代表性问题那这个话题可能就很难继续了（笑）），当事人当选前乃至当选当下，是否滥权或因“坐大”而对其他用户如何打击，亦需时间证明，况且管理员人数不限、也有其他持权用户同时持权，自然没有“占了谁的缺不干活”之类的事（过往有此一说），所以在授权前需要讨论审视，自属合理；然而“剥夺他人权限”如前所述，需要公开审视的程度涉及对前一次社群意向表达和当事人的直接否定。个人认为，参与罢免投票的用户更应填具适当的“不适任”理由，而若有显然灌票导致影响公信力的问题可能还是偏向技术面处理的问题。
其次，一名用户从开始活动至足以参选管理人员，一般而言光是如此即需要相当长的养成时间，等到真正参选并当选，又可能因各种因素作用而波折再三，当中至少经历数年以上时间；然而，只要一次的罢免投票成功，基本上该名被成功投票罢免的用户就仿佛社群信用全毁、持权基础破灭。罢免不适任者自属社群行使制度权利无疑，然而这当中所产生的影响是否仅于该次投票便结束？又或是新的开始？又或者对于可能具持权条件以及已经持权的用户产生何种影响？相关问题或可留待有心观者玩味。
3.安全问题如果发生在现实生活，个人不认为是管理员可以直接处理的事情；况且若此类情形发生，即便发生在线上，往往也已发生某种程度的结果或负面效果，再说并非所有用户都有能力或意愿对此类事情执著或如何追究，更可能直接因恐惧和伤害而放弃。我认为用户的身心安全和使用体验仍然是首要考量，这方面胜过一切；若知其风险实现的可能性显然存在，个人主观认为在此前提下选择其他考量而将用户安全问题置于其他选项后，可能会更像“显可预见而不预防”。在过往的投票方式选择问题上似已多有讨论，当然如果要采用公开投票，个人亦无甚意见（只是当初为何决定采用安全投票呢？）。
4.如果安全投票的单一投票认定存在争议，那么试问改为“公开投票”，若出现同样投票内容时（比如在经过各种讨论后，出现类似留言：“对该用户仍然不信任，投下反对票”；或者“经验欠缺，来日方长”、“轻舟已过万重山”等，如何看待该票有效性？此为有效或无效投票又或者不影响其有效性？或者难以一概而论之类？），关于投票有效性的判断标准就更容易认定或是更少争议呢？又或者有何异同？以仲裁委员而言，公开投票后，若当选门槛为过半，是否也代表可能有一半的用户不信任当选者呢？会否影响之后该权限的社群公信力？在相关问题具备明确答案前，又是否有更充分理由应该直接推翻先前的安全投票界面选用结果？
5.“社群对于仲裁委员的期望”以及“行政员和管理员依据何人的何种意见判定”一事，个人认为回归信任度问题，可能也涉及投票公正性一事（假设出现突然大量账号如何灌票等）。事实上，正因当前仲裁委员这个称谓和制度看似颇有影响，然而信任度问题从未真正直接有解，我认为关键在于当前不具备一个可以让用户彼此间“直接认同度对决”的机会。在此前提下，除了公开选举获得明显支持度的管理员以外，究竟应如何看待所有用户彼此之间所抱持的信任度？可能难以量化。或许可从平日社群、站务乃至线下活动，以及权限申请之类的事情衡量，但这是否可直接对接社群对于仲裁委员或管理人员的信任度呢？在前述的比如罢免争议投票意见中，有无更简便的方法让管理员和行政员看待取舍用户意见的参考性？这也是为何敝人先前尝试发想“事务协调员”之类的部分主因，也就是不同用户的意见具备之可信度或参考性如何看待？如果“条目建立”有“豁免者”，那么“社群言论和行为”是否具备对应存在的可能性呢？此类概念若存在，是否对于来日的各种权限选举更容易提供某种信任和衔接基础？若答案偏向否定，那么其实不论如何选举或者投票界面如何选择，结果可能大致偏向对于当前社群所孰悉现状的维持。相关命题端视留待社群如何讨论。--Kriz Ju（留言） 2024年9月11日 (三) 16:53 (UTC)[回复]

其他意见

此处供社群发表杂项意见，若有重要问题提出者，欢迎于上方新置章节。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月18日 (日) 18:29 (UTC)[回复]

除放置公告栏外，是否亦考虑寄送用户讨论页通告，俾便广大社群知悉参与？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月18日 (日) 18:29 (UTC)[回复]
同意应该寄送。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年8月20日 (二) 12:01 (UTC)[回复]
简要模仿管治讨论做了一份通告模板供参考。——即请秋安 ZhaoFJx(论•欢迎签名) 2024年8月21日 (三) 06:44 (UTC)[回复]
公示7日，2024年9月5日 (四) 07:29 (UTC)结束：讨论用户基本就寄送通告达成共识，进入公示期。--人间百态,独尊变态(讨论) 2024年8月29日 (四) 07:29 (UTC)[回复]
我晚点结合仲裁委员会选举事写一份更简洁的通告吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月29日 (四) 10:12 (UTC)[回复]
@魔琴、ZhaoFJx、人间百态：结合上方仲裁委员会事宜写了草稿，请确认是否得宜。另此种通告应寄送予何人？延伸确认用户（或达到相同贡献门槛但尚未自动升格者）何如？请讨论。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月10日 (二) 15:35 (UTC)[回复]
👍 赞，挺简洁的，发给延伸确认用户就好。不过浅黄色不是很好看思考...可否考虑浅蓝色或其他替代背景？——即请秋安 ZhaoFJx(论•签) 2024年9月11日 (三) 01:40 (UTC)[回复]
隔壁仲裁委员会通知都是用此种颜色，我觉得不错，用蓝色反倒相对刺眼。另外我也希望发通告给几年没编辑所以尚未取得延伸确认资格者，说不定人家看到就来参一脚发表有益意见啦。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月11日 (三) 04:21 (UTC)[回复]
有道理——即请秋安 ZhaoFJx(论•签) 2024年9月12日 (四) 02:12 (UTC)[回复]
现在祇差产生用户清单，然后即可递送。—— Eric Liu 創造は生命（留言・留名・学生会）──此条未正确附上签名时间的留言于2024年9月12日 (四) 07:23‎ (UTC)加入。[回复]
@魔琴、ZhaoFJx、人间百态：但我不会弄这种东西，是不是可以请你们帮忙一下？顺便问问@0xDeadbeef。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月14日 (六) 16:17 (UTC)[回复]
话说“几年没编辑所以尚未取得延伸确认资格者”怎么定义呢……注册满90天且编辑大于500次的用户比较庞大，python跑了一遍递归错误了 囧rz……先输出了一份目前所有的延伸确认用户加管理员的名单phab:P69123。——即请秋安 ZhaoFJx(论•签) 2024年9月14日 (六) 22:39 (UTC)[回复]
重新写了下代码，跑了五个小时跑完了中维上注册满90天和编辑满500次的7008名用户，phab:P69124——即请秋安 ZhaoFJx(论•签) 2024年9月15日 (日) 03:06 (UTC)[回复]
这么多啊？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月15日 (日) 11:01 (UTC)[回复]
纯粹吐槽而非真的要提出改方针：究竟是为啥会让已经多年无编辑跟社群完全脱节的用户参与投票？这跟尸位素餐只靠定期编辑一两次装活跃的管理员有啥分别？--路西法人 2024年9月16日 (一) 02:55 (UTC)[回复]
有人就想做读者，不打算编辑；现有“活跃”编辑者，也不见得较其更懂规矩。我自己开台大维基社，就有干部因为要备考，曾数年未有编辑；也认识有学长即将“升格”为社会人士，编辑频率大幅下降甚至停止等，但他们可没有因为一段时间没碰编辑器，就一瞬变成过时懞懂的老头儿啊，而且他们还是可以上维基百科看客栈在干嘛。当然，不否认确有类似案例，但见仁见智，尚不足以概括全局。吾人显不应以是否编辑或编辑多寡纵然断定某人是否脱节于社群。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月16日 (一) 06:54 (UTC)[回复]
可以查询注册满90天、编辑满500词、最近90天有编辑的用户:https://quarry.wmcloud.org/query/86391#--0xDeadbeef (留言) 2024年9月19日 (四) 11:18 (UTC)[回复]
@ZhaoFJx：话说是不是可以帮忙统一加“user talk:”后缀并汇入此处？系统没法自动辨别。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月20日 (五) 10:10 (UTC)[回复]
完成，Special:diff/84288815——即请秋安 ZhaoFJx(论•签) 2024年9月21日 (六) 03:30 (UTC)[回复]
通告现已发送予社群成员。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年9月21日 (六) 13:36 (UTC)[回复]

澄清解任过程中发言的不同解读

不通过
无后续讨论之议题。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年10月26日 (六) 21:43 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

关于0xdeadbeef阁下在讨论中提到（例：Bluedeck原话说不至于不限期封禁，在解任界面持续被说成第三方管理员不认同可构成查封理由，而Bluedeck实际上会有限期封禁。），在下认为是不当解读， 澄清可见于：澄清解任过程中发言的不同解读。 --Gluo88（留言） 2024年8月23日 (五) 09:45 (UTC)[回复]

您好，因与检讨相关制度并无直接关联，本人将此议题移至其他意见。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月24日 (六) 08:08 (UTC)[回复]
谢谢--Gluo88（留言） 2024年8月24日 (六) 13:05 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

关于管理员错误自查表/封禁补充的说明

请移步相关页面继续讨论，勿于此处别生枝节。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月24日 (六) 14:34 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

Bluedeck 于2017年4月28日创建这个文档:Wikipedia:管理员错误自查表/封禁，感觉目的挺好：“在中文维基百科的实践中，管理员和管理人员有时可能会因为未注意到方针指引的一些细节而出错。在此总结了一些常见的错误，以便管理员在执行封禁时更加符合方针和指引，同时也便于普通用户根据方针指引与管理员沟通，针对疑似不当封禁的类似情况提出质疑。”

有些管理员需要更加熟悉有关方针和指引， 约束自己的行为，避免长期多年做出大量违反方针和指引的封禁行为， 避免发展到需要社群启动弹劾程序。为此目的，我系统地阅读了方针指引，查找了众多案例，花费了大量时间，进行了较为详细的补充。

所增加的问题都是在实际过程中所观察到的。从目前情况来看，许多有多年经验的管理员对方针指引仍然不够熟悉。这些总结不仅有助于管理员自查，也能帮助受到不公正待遇的用户找到相关方针和指引，以分析实际遇到的问题。

更重要的是，我们希望管理员和用户都能够按照方针办事，这些总结是否能帮助管理员和用户、是否能帮助维基社群营造一个和谐公平的合作环境是我们需要考虑的重点。 希望大家关注如何帮助社群，如何帮助维基营造一个和平公正的合作环境。

有不同意见可以提出，社群可以继续补充和讨论， 有助于建立积极的中维社群环境。社群协作的关键在于理解、尊重和包容不同的观点。即使某些用户表现不佳，作为管理员，我们应该保持专业和耐心，应该保持客观、公正和理性，而不是简单地采取高压态度。公信力需要建立在合理和公正的行为基础上。 --Gluo88（留言） 2024年8月24日 (六) 13:13 (UTC)[回复]

其实在Wikipedia talk:管理员错误自查表/封禁#有关此页面新增内容，请大家协助确认及提供意见已有用rfc发起讨论，建议在该讨论页讨论即可。--Wolfch (留言) 2024年8月24日 (六) 13:28 (UTC)[回复]
谢谢您的理解， 社群需要一起合作， 进一步改善。这个补充的目的，和本次解任直接相关，涉及范围大时间长影响大，更应该在客栈的检讨此次检验程序的过程中讨论，让一切改动公开透明，广泛征求意见， 有助于避免将来再启动弹劾程序。
目前我的修改已经被全部彻底的回退。请测评用户看一看在下的补充，发表您的意见， 包括是否应该恢复在下的编辑。--Gluo88（留言） 2024年8月24日 (六) 13:48 (UTC)[回复]
(！)意见，此讨论内容已经和页面发起的rfc讨论重复，请求未参与其中的其他用户协助关闭此段讨论，谢谢。--提斯切里（留言） 2024年8月24日 (六) 13:55 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

小结

这个讨论串也被放置play了很长时间了，看样子就是没有新的意见了。小结一下目前仍然没有得出一个结论的议题：

  1. 管理人员上任是否要继续安全投票？可否以公开投票的形式进行？
  2. Wikipedia:管理员布告板/其他不当行为这类页面没人/少人处理怎么办？
  3. 设立某种“停权”机制，配合独立第三方调查人员处理设计权限的争议
  4. RFA和RFDA是否要求提供理由？
  5. 安全投票的投票人列表是否应向所有用户公开显示？

其中对于2和3，咱个人认为与正在组建的仲裁委员会有关；对于1，众多用户认为继续进行安全投票制度依旧是利大于弊。其他的议题似乎参与的用户很少，因此重新贴在这里吸引一下讨论。@Ericliu1912： Stang★ 2024年11月26日 (二) 13:06 (UTC)[回复]

在本地启用安全投票及electionadmin权限

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：即请秋安 ZhaoFJx(论•签) 2024年10月17日 (四) 20:53 (UTC)。[回复]

原标题：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)[回复]

小结2 (安全投票)

以下部分仍然欠缺讨论：

  1. 用户组译名（选举监察员/选举管理员/监选员）
  2. 是否延续监督员监票，或使新用户组独立于监督员
  3. 是否允许延确用户看到票数
  4. 引入本地安全投票后，可否放宽提名时限，（在举行固定时间选举的基础上）允许管理员等申请随时提出。

论。 0xDeadbeef (留言) 2024年12月1日 (日) 02:04 (UTC)[回复]

对于2，个人建议独立于监督员，理由前文已述，“有失权限组的纯粹性，“监票”跟监督这一特殊的版本删除方式并无关系”；对于3，（“票数”我理解成“谁进行了投票”）在本站相关的即时通讯群组内有用户反对，认为这有害于“最大限度地保护用户隐私”，同时技术上似乎只能是所有用户都可以看到票数 vs. 只有选举管理员可以看到票数；对于4，支持，本来就应该是想什么时候选就什么时候选。 Stang★ 2024年12月1日 (日) 02:43 (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)[回复]

管理操作复核请求：不认为Ericliu1912在8月28日的双向互动禁制处理符合方针指引等社群共识

本主题或以下段落文字，在讨论结束后应存档至Wikipedia:管理操作复核请求/存档。

此请求是根据Wikipedia:管理操作复核请求所提出，请先阅读相关内容。

操作： 双向互动禁制
执行者： Ericliu1912 （讨论 · 贡献 · 日志）

首先说在前面：“管理操作复核请求用于复核管理人员或其他进阶权限持有人用权时是否符合方针与指引的规范。……管理操作复核请求旨在就具体管理操作是否适当达成共识，而非追究责任。”所以，这笔管理操作复核既非封禁/禁制申诉（禁制期早已过），也非追究管理员Ericliu1912的责任（否则就是RFDA了），仅是用于讨论该操作是否适当。

  • 在2024年8月26日，我在WP:管理员布告板/其他不当行为由于被诽谤而提报了用户Chinuan12623。在阿南之人、Patrickov、Tisscherry、ASid、薏仁将、Wolfch、Heihaheihaha、WilliamSkyWalk等近10人参与提报区讨论之后，8月28日，管理员Ericliu1912作出了对Chinuan1262和我的互动禁制决定（另也对Chinuan1262和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)[回复]
@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)[回复]

(＋)支持：基金会向法院披露身份信息必然影响编辑的日常生活和隐私安全，且收到威胁的一定不限于英维；抗议可以是声援自我保护的第一步。--  2024年11月15日 (五) 03:35 (UTC)[回复]
哈，WMF考虑向印度法院披露编辑身份信息，有编辑却担心基金会会因为中维的条目而败诉。--日期20220626（留言） 2024年11月15日 (五) 03:51 (UTC)[回复]
目前趋势似乎是不会闭站。我认为本站反应弱于直接相关方英维是可以接受的，但弱于德、法、俄、西、意等维基社群是不可以接受的，不然就有跟不上国际维基社群主流意识的观感。但未见德、法等有采取行动的迹象，除了俄维，而跟不上俄维的意识似乎并非问题。我承认上述分析是见风使舵、随大流的，但我的看法还是：既不先于俄维，也不后于德维。--Fire Ice 2024年11月15日 (五) 04:01 (UTC)[回复]
我不认为中维应该被所谓“国际社群的主流”牵着走。中维应该要有自己的想法。--  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极力配合印度方面有可能是出于挽留当前可访问本站的最多人口国家之考虑——留给他的市场已经不多了。--  2024年11月15日 (五) 09:33 (UTC)[回复]
印度封锁维基，损失的只是印度人自己。--日期20220626（留言） 2024年11月15日 (五) 12:05 (UTC)[回复]
印度确有打压异己的状况，例如印度教徒打压伊斯兰教徒。WMF没做过类似向中国政府披露异议人士类编辑身份信息这件事。--Lanwi1Talk 2024年11月15日 (五) 15:06 (UTC)[回复]
印度已有先例，很难保证中国大陆不是下一个。--  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)[回复]
此话相当含糊而缺乏价值，可能产生各种理解。--YFdyh000（留言） 2024年11月15日 (五) 09:55 (UTC)[回复]
印度在中国之西，向其叩头似乎也是被西方势力利用[开玩笑的]--派翠可夫 (留言按此) 2024年11月15日 (五) 09:57 (UTC)[回复]
维基也未尝不是西方势力。[开玩笑的]--  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有效。--  2024年11月15日 (五) 13:03 (UTC)[回复]
关于标题调整的事项，副知@魔琴。--  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)[回复]
在下是在这[34]看到的，如果是在下对英文新闻的理解有误还望您指教。--🎋竹生🎍 2024年11月21日 (四) 04:30 (UTC)[回复]
原文写 would be，应该看成是“已答应或作出提议，但未实行”。当然，这已经够糟，但毕竟跟做了是有分别的。--派翠可夫 (留言按此) 2024年11月21日 (四) 05:05 (UTC)[回复]
(～)补充：本人已签署公开信--派翠可夫 (留言按此) 2024年11月21日 (四) 05:09 (UTC)[回复]
如果在下没有理解错的话，根据这篇[35]报道，基金会与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未来不会为了进入大陆向中国大陆行政部门方面提供后者所需的资料（虽可能性很小但尚微存），因此本人认为完全有理由比英维处理的早而果断。--  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)[回复]
    您这个做法是对读者、站内其他编者很不负责任的行为。--  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将编辑身份信息披露给法院后才能关闭。--Lanwi1Talk 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。一定程度上的抗议，比如连署书或当隔壁闭站受到批评时做出声援，个人认为是妥当的，但若是涉及到维持自由百科本身的承诺，那我不得不(－)反对闭站。忍耐是有极限的。--（☎）dt 2024年11月22日 (五) 04:36 (UTC)[回复]
    虽然我也不支持闭站，但是你这个话术听上去有点像“因为你们的工作是我提供的，所以你们不能罢工，你们要是罢工我就立即解雇你们”。--日期20220626（留言） 2024年11月22日 (五) 06:17 (UTC)[回复]
    可能现实主义成分太多吧，毕尽大实话不是所有人都爱听。--（☎）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)[回复]
相关讨论

议题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)[回复]
我认为提出社群意见还是可行的，至于基金会那边有什么考量，那就是他们自己要去想的了。讲难听点，基金会完全没有义务理会社群提出的意见。--（☎）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)[回复]

对于全保护的一些建议

对《破·地狱》现在的全保护有感，觉得需对管理员提出一点意见。我对全保护的观感，始于2023年3月《中年好声音》，在播映期间因部分延伸确认用户发生编辑战而全保护3个月之久，过长的全保护漠视了其他没有参与编辑战用户的权利，且当时交战双方在对方的个人讨论页进行指责，却没有人试图在条目讨论页发起讨论，连事后其他人追溯到底发生过什么事都有困难。这次破·地狱全保护的时长合理，但一般人根本难以注意有讨论存在于Wikipedia:互助客栈/条目探讨#电影条目过度收录问题，希望管理员也能多做一点促进讨论。就此，我建议如下：

  1. 全保护后如未有人发起讨论，管理员可在条目讨论页发起，通知有关用户。
  2. 如管理员得知已有人发起相关讨论，但并非在条目讨论页，管理员可在条目讨论页留下连结。
  3. 保护模板可否进化一下，能加入相关讨论连结？--Factrecordor（留言） 2024年11月24日 (日) 12:33 (UTC)[回复]
@AT、Manchiu、Ericliu1912、Shizhao、ATannedBurger：通知我所知的活跃管理员。--Factrecordor（留言） 2024年11月24日 (日) 12:45 (UTC)[回复]
补充建议：模板上可以注明任何人如想发起讨论，尽量在条目讨论页，如在其他地方发起，请在条目讨论页留下连结，以便其他关注此条目的人能参与。我是factrecordor--45.64.241.58（留言） 2024年11月25日 (一) 01:22 (UTC)[回复]
通知有关用户，是指近期编辑该条目的用户？--千村狐兔（留言） 2024年11月25日 (一) 01:50 (UTC)[回复]
本意只是指直接引发全保护的用户而已，如编辑战双方。当然，如能PING近期编辑该条目的用户就更好，但未知这样会否过度加重管理员工作量。--Factrecordor（留言） 2024年11月25日 (一) 12:45 (UTC)[回复]
管理员没义务做这事，这事情应该是有意参与讨论的人来做的--百無一用是書生 (☎) 2024年11月26日 (二) 02:52 (UTC)[回复]
那么只修改增加模板内容，呼吁应在条目讨论页发起讨论或留下讨论的连结。可以吗？--Factrecordor（留言） 2024年11月26日 (二) 15:22 (UTC)[回复]
@Factrecordor：目前模版中已有提到：“如果您不能修改此条目页，您可以请求修改、在讨论页提出修改提议……”，粗体部分都是连到讨论页的连结，若讨论是在互助客栈中进行，也可以请相关维基人在讨论页中说明，并在讨论页中加上对应的连结。想知道您希望如何调整模版？谢谢您--Wolfch (留言) 2024年11月30日 (六) 03:49 (UTC)[回复]
我完完全全没理解你在说什么。讨论？讨论什么？如何修改条目？不是模板上写着吗？追溯到底发生过什么事？为什么？编辑历史不是存在吗？ 囧rz……--Martin我强烈反对WMF给出个人信息，支持闭站抗议 2024年12月3日 (二) 17:08 (UTC)[回复]
@factrecordor：--Martin我强烈反对WMF给出个人信息，支持闭站抗议 2024年12月7日 (六) 20:51 (UTC)[回复]
编辑历史是不能取代讨论的。他们在编辑战时有没有进行过讨论？各自论点是什么？这对往后其他人继续编辑，或判断当中哪些用户的作风有问题，有参考价值，但社群很喜欢在对方的个人讨论页展开讨论，妨碍其他人参与或往后找回这些讨论。--Factrecordor（留言） 2024年12月8日 (日) 03:30 (UTC)[回复]
个人讨论页习惯是历史遗留原因，以前没有话题订阅和{{ping}}，现在也有不同的通知效果（邮件通知）。我也确实困扰这一点。--YFdyh000（留言） 2024年12月8日 (日) 06:29 (UTC)[回复]

有没有熟悉仲夏夜之淫梦的维基人

本主题或以下段落文字，在讨论结束后应存档至Talk:仲夏夜之淫梦。

User:Newbamboo以违反生者传记方针及无可靠来源等理由对条目进行大量的删改，然而Newbamboo对“淫梦”并不熟悉使得撰写的内容或有错误，本人对淫梦梗也只是稍有理解，希望有淫梦民可以协助完善条目。

Newbamboo将淫梦的起源——多田野数人的部分删除了，但不提及这一部分难以说明淫梦是如何兴起的，是否有不违反生者传记方针的方法？--世界解放者（留言） 2024年11月28日 (四) 13:48 (UTC)[回复]

@Newbamboo--  2024年12月1日 (日) 08:48 (UTC)[回复]
还有这里面的“下北泽国旗”仅由简单几何形状组成，是否有达到原创性门槛？--世界解放者（留言） 2024年12月3日 (二) 10:15 (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)[回复]
我支持在处理之前的讨论放在上方，下方留给对处理结果的讨论。各个区域之间可以用----分隔。--  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放得更显眼。--  2024年12月1日 (日) 08:46 (UTC)[回复]
{{archive top}}还不够显眼吗…… ——自由雨日🌧️❄️ 2024年12月1日 (日) 08:47 (UTC)[回复]
似乎现在在框区的右上角？可以更宽大一些。--  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)[回复]
界面的去人性化，时代的退步。[开玩笑的]而且提报人和提报时间分两行会很影响阅读体验，很反编者直觉。--  2024年12月3日 (二) 07:59 (UTC)[回复]
(－)强烈反对：极易导致亿恶的编辑冲突。--自由雨日🌧️❄️ 2024年12月3日 (二) 08:51 (UTC)[回复]

民意调查

由于不同意见太多，故进行民意调查。最终并非完全以投票（支持/反对）数量决定，仅是辅助参考。若有其他方案可直接在下方补充。——自由雨日🌧️❄️ 2024年12月3日 (二) 02:44 (UTC)[回复]

方案一：维持现状，编者自由选择在“处理”栏上方或下方留言，且管理员处理后仍可自由回复
  1. (－)强烈反对：已有诸多问题。如时间线混乱、缩排混乱、“处理”栏不明显等。——自由雨日🌧️❄️ 2024年12月3日 (二) 02:44 (UTC)[回复]
  2. (－)反对：时间线很难区分，且毫无层次感。--  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. (＋)支持：合乎逻辑，理由(▲)同上。--  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. (？)疑问：这似乎本质上和方案二可以同时实现。--  2024年12月3日 (二) 03:44 (UTC)[回复]
    看我上面的留言的最后半句（）有那个问题，所以区分成两个方案了。--自由雨日🌧️❄️ 2024年12月3日 (二) 04:09 (UTC)[回复]
    (＋)支持--  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)[回复]
方案四：讨论统一在“处理”栏下方留言（并修改“发现人”位置以便点按回复），并在管理员处理后禁止回复“处理”栏
  1. (－)倾向反对：没有必要“禁止回复”。但若不禁止，又会造成时间线混乱的问题 ——自由雨日🌧️❄️ 2024年12月3日 (二) 02:44 (UTC)[回复]
  2. (－)反对：时间逻辑不合理。--  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参数只能表示处理的结果。但后续针对处理的讨论串如何用此模板关闭则有待商榷；若无定案则反对。--  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)[回复]
    其实可以写一个脚本方便关闭[36]
    对于框起来的事情，我个人觉得本来就是为了discourage人去继续评论。如果真有人觉得自己有必要、有价值的评论完全可以在其他地方延续。--0xDeadbeef (留言) 2024年12月8日 (日) 09:54 (UTC)[回复]

请求澄清：全站范围禁制与封禁

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:禁制方针、Wikipedia talk:禁制纪录。

根据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 [回复]
谢谢。 -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存在恶意推定、曲解方针等问题，因此其做出的封禁容易被质疑，也是其被解任的原因。--Lanwi1Talk 2024年12月7日 (六) 11:07 (UTC)[回复]
我从未见过称“永久封锁”禁制的，亦未见合法。我也并不要求解封，只想澄清一下。 -Lemonaka 2024年12月7日 (六) 11:18 (UTC)[回复]
你说的没错，即使Mys_721tx的封禁有问题，还是要按方针解封。我认为Mys_721tx过严，压力过大也会容易做出问题行为。--Lanwi1Talk 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)[回复]

维基友爱有可能更新吗？

我发现维基人似乎被果仁蜜饼吃出生理反应了（看玩笑的）。

如果可能，在下希望可以拓宽以下维基友爱的部分内容，尤其是星章等。虽然可以通过直接复制模板解决友爱的快捷模板不足问题，但不如直接一次性解决了更好。--花开夜（留言） 2024年12月7日 (六) 17:49 (UTC)❤️1 [回复]

欢迎光临Wikipedia:维基餐厅，如有食物想要添加可以联络本人。--维基病夫❤️边缘人小组·签到·Donald Trump 45 and 47! 2024年12月7日 (六) 18:02 (UTC)[回复]
( π )题外话：适才逛了一下餐厅，白切鸡照片里居然用小棠菜作伴碟，天哪[开玩笑的]。--银色雪莉（留言） 2024年12月8日 (日) 05:13 (UTC)[回复]
阁下餐厅早有光顾，鄙人之意为拓展维基友爱。如果可能直接把这个餐厅复制到友爱？--花开夜（留言） 2024年12月8日 (日) 11:11 (UTC)[回复]
需要修改MediaWiki:WikiLove.js？维基餐厅菜品太多，维基友爱扩展能和适合承受吗。似乎可以做成扩展脚本供用户自选配置。--YFdyh000（留言） 2024年12月8日 (日) 11:24 (UTC)[回复]
重写Wikilove.js或许好一点，但制作成新的可选插件拓展脚本也是挺好的选择。--花开夜（留言） 2024年12月8日 (日) 12:58 (UTC)[回复]
个人支持写拓展脚本插件方案。--维基病夫❤️边缘人小组·签到·Donald Trump 45 and 47! 2024年12月8日 (日) 13:04 (UTC)[回复]
js供有志者参考。维基友爱界面已知问题：左侧类型似乎放不下太多组。右侧的图片尺寸偏小、不支持点开大图。也许面临地区词转换需求。--YFdyh000（留言） 2024年12月9日 (一) 14:43 (UTC)[回复]

《病夫有话儿》

本人希望早日建立美国各州的县城列表模板（例如Template:印第安纳州县城、Template:明尼苏达州县城、Template:密苏里州县城），目前总共有23个州希望能建立。惟本人日常生活繁忙，恐无法短时间内完成，因此希望在此找到会对建立模板感兴趣的维基人参与。任务内容为将英维的模板内容翻译为中文，并且将县城模板加到相关条目。如果每位志愿维基人都参与一个州的模板建立，本计划最多可安排23人参与。

以下为相关详情，粗体为该州并非以县为行政单位:

需建立的模板 对应英维模板 县城数量 负责用户
Template:阿拉巴马州县城 en:Template:Alabama county seats 69
Template:阿拉斯加州自治市镇首府 en:Template:Alaska borough seats 19
Template:亚利桑那州县城 en:Template:Arizona county seats 15
Template:阿肯色州县城 en:Template:Arkansas county seats 85
Template:加利福尼亚州县城 en:Template:California county seats 58
Template:科罗拉多州县城 en:Template:Colorado county seats 64
Template:康涅狄格州县城 en:Template:Connecticut county seats 8
Template:特拉华州县城（范例） en:Template:Delaware county seats 3 SickManWP
Template:佛罗里达州县城 en:Template:Florida county seats 67
Template:佐治亚州县城 en:Template:Georgia county seats 160 Kcx36
Template:爱达荷州县城 en:Template:Idaho county seats 44
Template:伊利诺伊州县城 en:Template:Illinois county seats 102
Template:堪萨斯州县城 en:Template:Kansas county seats 105
Template:肯塔基州县城 en:Template:Kentucky county seats 122
Template:路易斯安那州堂区首府 en:Template:Louisiana parish seats 64
Template:缅因州县城 en:Template:Maine county seats 16
Template:马里兰州县城 en:Template:Maryland county seats 24
Template:马萨诸塞州县城 en:Template:Massachusetts county seats 17
Template:密歇根州县城 en:Template:Michigan county seats 83
Template:密西西比州县城 en:Template:Mississippi county seats 92
Template:蒙大拿州县城 en:Template:Montana county seats 56
Template:内布拉斯加州县城 en:Template:Nebraska county seats 93
Template:内华达州县城 en:Template:Nevada county seats 17
Template:新罕布什尔州县城 en:Template:New Hampshire county seats 11

如对建立相关模板有兴趣，可以填写上方表格的“负责用户”一栏（加入[[User:SickManWP|SickManWP]]）。如对模板格式或分类有任何问题，可以在下方回应或直接联络本人。非常感谢各位的关注和参与！--维基病夫❤️边缘人小组·签到·Donald Trump 45 and 47! 2024年12月11日 (三) 04:49 (UTC)[回复]

等个几天给大家分工，剩下没人认领的我有空可以全部翻译一遍。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年12月11日 (三) 12:56 (UTC)[回复]
检索自“https://wiki.gdrain.workers.dev/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”