跳转到内容

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

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

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

按此刷新页面。

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

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

查看全部讨论

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

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

消息

Edit check experiment results

Hello everyone

Sorry to use English. 请帮助翻译至您的语言. 感谢您。

We recently tested References Check at your wiki, so as at 10 other wikis. This feature encourages newcomers and IP users to add citations when they add a new paragraph on Wikipedia.

We tested this feature at your wiki between February 18 and April 4, 2024. We gave References Check to 50% of new accounts and IP users, while the remaining 50% got the regular experience, with no encouragement. This way, we were able to compare the experience for the two groups.

What was found?

Reference Check caused an increase in the quality of edits newcomers publish and did not cause any significant disruption. on average, 19% of users were adding a reference without being asked to. When References Check encourages them to add a citation, the percentage increases to 42.4%. On mobile, users add references 4.2 times more than on desktop when they are encouraged to.

For your wiki specifically, on average, 26.6% of users were adding a reference without being asked to. When References Check encourages them to add a citation, the percentage increases to 57.6%, one of the best percentages we got.

We published the detailed results, and you can ask me if you have any more question about it.

What is next?

Given the good results, we ended the A/B est and deployed References Check for all beginners and IPs at your wiki.

We are also working on a a new Check, a new encouragement for IPs and newcomers. We are looking for ideas for this next step. In your opinion, what could be useful to explain to beginners when they start editing?

You can ask me if you have any more question about this project. Trizek (WMF)（留言） 2024年6月26日 (三) 15:56 (UTC)[回复]

大家好
我们最近在您的wiki测试了“参考检查”，和其他10个wiki一同进行测试。此功能鼓励新手编者和IP使用者在维基百科上新增段落时附上引用。
我们于2024年2月18日至4月4日期间在您的wiki测试了此功能。在测试期间，我们为50%的新帐号和IP使用者提供了“参考检查”，而其馀50%的使用者则获得常规体验，没有任何鼓励。透过这种方式，我们可以比较两组使用者的体验。
我们的发现
“参考检查”提高了新手编者发布的编辑品质，并且没有造成任何严重干扰。平均而言，19%的使用者在未经要求的情况下附上参考资料。当“参考检查”鼓励他们附上引用时，该百分比上升到42.4%。当使用者被鼓励时，在行动装置上新增的参考资料数量是在桌面装置上的4.2倍。
至于针对您的wiki，平均有26.6%的使用者在未经要求的情况下附上参考资料。当“参考检查”鼓励他们附上引用时，该百分比上升到57.6%，是我们获得的最佳百分比之一。
我们已经公布了详细结果，如果您还有任何疑问，可以问我。
我们的下一步
鉴于测试结果良好，我们结束了A/B测试，并为您的wiki的所有新手编者和IP使用者部署了“参考检查”。
我们正在制定一项新的检查，这是对IP使用者和新手编者的新鼓励。我们正在为下一步的工作征求意见。您认为，当新手编者开始编辑时，向他们解释什么是有用的？
如果您对这个专案还有任何疑问，可以问我。 Trizek (WMF)（留言）
--Cookai饼块🍪（💬留言） 2024年6月26日 (三) 16:55 (UTC)[回复]
@Trizek (WMF): Hello, thank you for your information!
As I said before, it is recommended that displaying reminders, which include information about our policy, when users select the "No" option (See my detailed suggestions in the previous discussion). Moreover, some users often translate articles from other language Wikipedia, where the content may not have references (e.g. Special:Diff/82953754). Thus, it is recommended to add a new dismissing reason "I translate articles from other language Wikipedia" or something else.--SCP-0000（留言） 2024年7月5日 (五) 16:25 (UTC)[回复]

批准维基媒体运动宪章的投票即将结束

您可以在元维基上找到这则讯息其他语言的翻译。 请帮助翻译至您的语言

大家好，

谨此提醒您，批准 维基媒体运动宪章 的投票期将于2024 年 7 月 9 日 23:59 （世界协调时间）结束。

如果您尚未投票，请在此 SecurePoll 上的连结投票。

谨代表维基媒体运动宪章选举委员会，

RamzyM (WMF) 2024年7月8日 (一) 03:46 (UTC)[回复]

Wikidata weekly summary #635

Here's your quick overview of what has been happening around Wikidata over the last week.
This is the Wikidata summary of the week before 2024-07-08. Please help Translate.

Events

  • Upcoming:
    • The next Wikidata+Wikibase office hours will take place on Wednesday, 16:00 UTC on Wednesday, 10th July 2024 (18:00 Berlin time) in the Wikidata Telegram group. The Wikidata and Wikibase office hours are online events where the development team presents what they have been working on over the past quarter, and the community is welcome to ask questions and discuss important issues related to the development of Wikidata and Wikibase.
    • Registration for Wikimania 2024 is open! In-person participants: please register until 26 July, 11:59 p.m., UTC. Virtual participants can register anytime. If you received a scholarship from the Wikimedia Foundation, you will receive an email with a registration code and instructions.

Tool of the week

  • User:Teester/EntityShape.js - a userscript that adds an input box to a Wikidata page wherein you can enter an EntitySchema (such as E10). When you click "Check", checks whether each statement and property conforms to the schema. It then displays a summary at the top of the Item for each property indicating whether they conform or not. It also adds a badge to each statement and each property on the page indicating whether they conform or not.

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • EntitySchemas: The new datatype to link to EntitySchemas in statements has been released.
  • mul language code: We are preparing the release.

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

This Month in Education: June 2024

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

This Month in Education

Volume 13 • Issue 6 • June 2024

In This Issue

U4C Special Election - Call for Candidates

You can find this message translated into additional languages on Meta-wiki. 请帮助翻译至您的语言

Hello all,

A special election has been called to fill additional vacancies on the U4C. The call for candidates phase is open from now through July 19, 2024.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members are invited to submit their applications in the special election for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

In this special election, according to chapter 2 of the U4C charter, there are 9 seats available on the U4C: four community-at-large seats and five regional seats to ensure the U4C represents the diversity of the movement. No more than two members of the U4C can be elected from the same home wiki. Therefore, candidates must not have English Wikipedia, German Wikipedia, or Italian Wikipedia as their home wiki.

Read more and submit your application on Meta-wiki.

In cooperation with the U4C,

-- Keegan (WMF) (talk) 2024年7月10日 (三) 00:03 (UTC)[回复]

This Month in GLAM: June 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.


方针

提议英维指引en: MOS:TVINTL经本地化后引入中维维基百科:格式手册/电视

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:格式手册/电视。

目前，英维en: MOS:TVINTL有限制维基百科应收集怎样的播放资讯，但中维没有相关限制，导致各电视节目（包括剧集及日本动漫）均记录了世界各地每一地区的播放资讯或重播资讯，本人认为条目内记录每一地区的播放资讯或重播资讯是非常冗长而没经筛选，更甚有条目的播放资讯比例占整个条目一半或更多，有机会违反WP:SOAP及WP:NOTTVGUIDE。对此，引入en: MOS:TVINTL也许可解决问题。
en: MOS:TVINTL： Broadcast
This subsection should cover broadcast and release information about the series or season. This can include: the original network or streaming service of release in the country of production (e.g. the British network for a British series such as Doctor Who); a change in network throughout the run, such as with Futurama; start and end dates; and discussion of technical data such as picture and audio format, accompanied by critical commentary. Days or timeslots are not inherently notable, but if covering a series that switches these during its run, it may be helpful to note them for each season. If episodes are released all at once on a streaming service, it may be more appropriate to title this section "Release" rather than "Broadcast". Any syndication deals can also be noted.

As Wikipedia is not a television guide, do not include an indiscriminate list of every network that carried a series outside the country of production. Editors are encouraged instead to add noteworthy foreign broadcasts, if reliably sourced. These can include: broadcasts in primarily English-speaking nations such as the United States, Canada, United Kingdom, Australia and New Zealand; special cases such as an American series airing its finale first in France; or a mass international distribution deal, such as Netflix acquiring the international rights for Riverdale and Designated Survivor. If reliable sources exist for English broadcasts in other countries, a talk page discussion should decide whether these are notable.

可以这样本地化：

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外播放系列的每个播放平台。 相反，如果来源可靠，鼓励编辑新增值得注意的非生产地区的广播或串流资讯。 这些可能包括：在中国、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的广播或串流资料；其馀地区除了特殊情况外，包括如相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议，否则不应被记录。

下列资料不应记录：

  • 播放时间（不包括播放日期）
  • 电视重播资讯
  • 电视延后播放资讯（只记录该地区最先出现的资讯）
  • 马拉松式播放资讯（例如在一天内连续播放5集电视节目）
  • 节目原产地区外，不是以中文提供字幕或配音的播放平台
  • 相关串流平台官网、其他可靠来源均没有记录相关节目的准确播放地区且相关播放平台设置了IP限制 (特别注意：Disney+、Netflix、Amazon Prime Video、TVB Anywhere、Viu OTT)
  • 如相关节目于中文地区有“代理发行”资讯，则只可记录可在该播放平台清淅辨认相关代理资料的网路播放平台。(特别注意：日本电视动漫)

由于此条文适用于所有曾于电视广播的节目，故在此提案。部分字眼可改，只求尽快通过。--唔好阻住我爱国（留言） 2024年4月22日 (一) 07:16 (UTC)[回复]

个人感觉：“值得注意的”是重点，但不十分明确。短期内或频繁的重播可能琐碎，得到有效来源介绍的则可考虑。“除了特殊情况外”后面的语句可能仍需润色，不好懂。“播放时间”如果有来源我觉得可以，但可能很多是查证不足。“下列资料不应记录”第三条及之后的含义和用法我不太明白，或许应补充例子。建议邀请活跃编者，可预期存在反对声音，另外它是指引，强制力在短期内可能不会很高，只能作为理由依据。--YFdyh000（留言） 2024年4月22日 (一) 07:56 (UTC)[回复]
  • “值得注意的”段落可以extend，但应如何extend则交由社群决定。
  • “频繁的重播”当然是琐碎，难道要准确收录何时重播？
  • “播放时间”见下方解答
  • “第三条及之后的含义和用法”，不是电视节目条目编辑者不明白是正常的。
最后那点，请参阅在Wikipedia talk:格式手册/日本动漫游戏 § 提议将WP:MOSACG跨媒体部分提升为指引的讨论。--唔好阻住我爱国（留言） 2024年4月22日 (一) 09:26 (UTC)[回复]
那之前疫情的时候部分作品由于制作原因推迟播出，算不算电视延后播放信息？而且这一段(如相关节目于中文地区有“代理发行”信息，则只可记录可在该播放平台清淅辨认相关代理资料的网络播放平台。(特别注意：日本电视动漫))应该要加上特摄作品的信息。(有部分特摄作品也会标注其代理信息)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 07:58 (UTC)[回复]
第一点：想法是只记录该集数最先出现的播放平台，例如“A节目在B平台的播放时间是0900，在C平台的播放时间是0930，在D平台的播放时间是1200…”，这样写实在太冗长及无谓。想法是“A节目于B、C、D平台上架。”
第二点括号内的是我个人想法，当然是不会加入条文之中。--唔好阻住我爱国（留言） 2024年4月22日 (一) 09:04 (UTC)[回复]
第一个的话这个不反对(反正超级战队系列特摄作品条话一般都是按散文方式写在哪一个平台上架不大受会受影响，但是假面骑士和奥特曼系列的话有可能会受到影响删内容。)第二点的话就是说所有电视类条目都得遵守该规范吗？--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 11:22 (UTC)[回复]
总之曾在电视广播的节目条目也适用。--唔好阻住我爱国（留言） 2024年4月23日 (二) 06:04 (UTC)[回复]
依MOS:CHINA，修改为“这些可能包括：在中国大陆、台湾、”。--CaryCheng（留言） 2024年4月22日 (一) 18:21 (UTC)[回复]
下一版本会更正。--唔好阻住我爱国（留言） 2024年4月23日 (二) 06:03 (UTC)[回复]

版本2

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外播放系列的每个播放平台。 相反，如果来源可靠，鼓励编辑者新增值得注意的非生产地区的广播或串流资讯。这些可能包括：在中国大陆、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的广播或串流资料；相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议。

下列资料不应被记录：
  • 播放时间（不包括播放日期）
  • 电视重播资讯
  • 马拉松式播放资讯（例如在一天内连续播放5集电视节目）
  • 节目原产地区外，不是以中文提供字幕或配音的播放平台

下列资料必须曾被播放平台官网或第三方可靠来源记载方能保留：
  • 夸地区网路播放平台上架影片的准确上架地区 (特别注意：Disney+、Netflix、Amazon Prime Video、TVB Anywhere、Viu OTT)
  • 如相关节目于中文地区有“代理发行”资讯，则只可记录可在该播放平台清淅辨认相关代理资料及相关代理公告了的网路播放平台。(特别注意：日本电视动漫、 特摄作品等)
--唔好阻住我爱国（留言） 2024年4月25日 (四) 05:07 (UTC)[回复]
另ping @PexEric、@BlackShadowG、@Cdip150、@U:Skiate--唔好阻住我爱国（留言） 2024年4月25日 (四) 05:12 (UTC)[回复]
“下列资料不应记录”之后的内容，不是英维既有的内容，不少看起来过于一刀切，个人认为相关条文有些不合实际操作：
第一条，日本动画作品的时刻表通常使用三十小时制，不记录“播放时间”，只记录日期很容易出错
第二条的实际操作预计会删除很多内容，需要更多人参与讨论，以减少潜在的编辑冲突，以还珠格格#电视节目的变迁举例，要删掉“复播”的内容。一些记录特定电台的播放节目模板，如{{中视八点档}}《还珠格格》几轮重播都有记录，这些又如何处理。
第三条个人认为有记录必要，一来是平台发布方式的不同，如Netflix是一次性全部发布的，二来中国大陆节目播放是有政策限制的，2014年之前是“一剧四星”，之后是“一剧两星”（[2]）
可靠来源才加入内容，这应该是一般的内容要求。“下列资料必须曾被播放平台官网或第三方可靠来源记载方能保留”的描述十分累赘，完全可以合并成一句话概括：“节目的播放平台及网络电视的节目可观看地区都需要列明来源”。
PS：错字“夸地区”。--Nostalgiacn（留言） 2024年4月25日 (四) 08:49 (UTC)[回复]
1. 编辑者有责任将日本30小时制转换至中文地区的24小时制，这样可提高条目可读性。（注：近期日本动画条目已停止记录30小时制播放时间表，仅列出24小时制首播及完结日期。）
2. 不记录重播资讯，只记录首播资讯是英维要求。节目模板可以保留。
3. 可以删除，反正第二条有相同功用。
4. 下一版本会更正，并放在首段。
整个句子可能是“节目的播放平台及网络电视的节目可观看地区都需要列明来源，否则其他编辑者有权移除未能辨认可观看地区的播放平台及网络电视播放资讯。 因应地区IP而调整播放内容的网路播放平台连结、需要登入方能阅读播放清单的网路播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。”--唔好阻住我爱国（留言） 2024年4月25日 (四) 10:24 (UTC)[回复]
(＋)支持。--CaryCheng（留言） 2024年4月25日 (四) 16:00 (UTC)[回复]
对于日本动画的话，电视播放途径会有一手来源（官方本身有类似onAir的来源），可以考虑保留时间。网站播放途径不确定其发布时间是不是确定的，可以不保留。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月26日 (五) 01:10 (UTC)[回复]
整顿完TV后就该整顿TV anime，电视联播网也不知道是什么…英维已有部分条目采用电视联播网归纳全日本电视台，与中维日剧条目差不多处理方法。
况且播放时间能证明什么？
时段可以，但准确时间万万不可。试想想，如果上一节目时段因为紧急直播10分钟而导致此节目延迟10分钟结束节目，编辑者通常在条目解释为何延迟播放此节目，唯解释普遍没有来源且与节目条目无关，备注长度砧比节目介绍，香港电视条目正深受其害。--唔好阻住我爱国（留言） 2024年4月26日 (五) 03:25 (UTC)[回复]
往常处理也是不考虑临时的延时、改期情况，如果需要的话，是有来源引述时在动画节目章节内导言中提及。时间的话，需要多精确？onair来源中来精确到“23:00”的话，就按照这个时间描述则可。电视联播网现在ja都不提及的，电视播放渠道只需要按照来源说明哪个电视台播放基本足够。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月26日 (五) 06:02 (UTC)[回复]
  • 这里该处理整体电视条目，而非单指日本电视动画…
  • “临时的延时、改期情况”在日本条目实属少见，唯香港条目是普遍。
  • “23:00”时段即可，免得又说因为xxx事而延误xx分钟播放。
--唔好阻住我爱国（留言） 2024年4月26日 (五) 06:13 (UTC)[回复]

版本3

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外播放系列的每一个广播或串流资讯。 相反，如果来源可靠，鼓励编辑者新增值得注意的非生产地区的广播或串流资讯。这些可能包括：在中国大陆、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的广播或串流资讯；相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议。节目的播放平台及网络电视的节目可观看地区都需要列明来源及符合可供查证原则，否则其他编辑者有权移除未能辨认可观看地区的播放平台及网络电视播放资讯。 因应地区IP而调整播放内容的网路播放平台连结、需要登入方能阅读播放清单的网路播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。

下列资料不应被记录：
  • 准确播放时间（不包括播放日期及播放时段）
  • 电视节目即日延误播放资讯（包括为何延误播放及延误时间）
  • 电视节目重播资讯
  • 节目原产地区外，不是以中文提供字幕或配音的播放平台

--唔好阻住我爱国（留言） 2024年4月26日 (五) 06:21 (UTC)[回复]

那包含在特定节目内的应不应该记录准确播放时间？(例如目前在翡翠台播出的小书痴以及东电在某些时段冠其他名称的动画)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月26日 (五) 07:13 (UTC)[回复]
准确播间是类似香港TVB晚上八点档爱回家，电视节目时间表写20:00播放至20:30结束，但实际播放时间是20:03-20:27。
故写播放时间时只需提及“此节目逢星期一至六晚上八时正首播。”--唔好阻住我爱国（留言） 2024年4月26日 (五) 07:43 (UTC)[回复]
与原有时段严重不符的特殊偶发延误资讯应可记录，例如延误半小时以上。亦即经常延误的节目不宜记录，例如习近平时代的央视新闻联播其后的电视剧等节目；据称胡锦涛时代的央视新闻联播延误极少，由此导致的节目延误应容许记录。--— Gohan 2024年4月27日 (六) 02:09 (UTC)[回复]
如何符合列明来源及符合可供查证原则？
请提供相关记录的例子，谢谢！--唔好阻住我爱国（留言） 2024年4月27日 (六) 06:06 (UTC)[回复]
与本问题无关（即不应因部分内容无来源而全面禁止以至牵连有来源的内容）。但有例子：フジテレビは地震発生时……映画‘ヲタクに恋は难しい’を放送……报道特番に切り替わり、深夜1时25分ごろに続きの放送が再开された。その后、2时间15分押しで深夜1时35分から‘さんまのお笑い向上委员会’……--— Gohan 2024年4月27日 (六) 09:33 (UTC)[回复]
只限于临时的节目时间改动，有来源（例如报道）的情况就可以作为描述文段提及。至于其原有的周期性播放时间点，也按照已有来源参照描述则可。例如[3]这种，每个播放电视台的周期播放时间是可以引述来源上描述的，如果当时的播放时间有偏差（例如上面提及的《爱回家》的时间）或者突然的变动，有来源提及就描述，没就不管。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月28日 (日) 02:06 (UTC)[回复]
建议第2点改为：
  • 推迟不足30分钟或并非偶发的延误播放之资讯
再者，一个节目若在渗透率二成的卫星电视或收费有线电视频道首播，而后在渗透率九成的地面电视频道重播，后者应容许记载。故建议第3点改为：
  • 重播资讯，除非传播媒介不同而使该重播频道渗透率倍增于此前任一已播出频道
此外，“相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯”文法不通，难以理解，应予修改；“在生产地区以外播放系列的每一个广播或串流资讯”中，“系列”显然是机械翻译，亦应修改。
另外，建议条文可能致使编者以为跨国播出只能在“播出国家／地区”栏目列出原产国或中维六地（例如以为GEM TV ASIA的此列法违规）而令所示播出范围小于实际，需要澄清；“广播”一词有歧义，在部分地方仅意味大气电波播出，亦需更改。--— Gohan 2024年4月28日 (日) 07:48 (UTC)[回复]
  • 第一点(＋)支持，下一版本会更正。
  • 第二点有点麻烦，毕竟以“渗透率”作标准有争议。
  • 第三点是英维要求，应如何改善？
  • 第四点(＋)支持，下一版本会更正。
  • GEM TV ASIA是采用内嵌字幕，除了香港是嵌入中文外，其馀东南亚地区是嵌入英文，故列出东南亚地区其实是不符合最后一点原则。
  • 英维是采用“广播”，中维可用“播放”，下一版本统一至“播放”。
--唔好阻住我爱国（留言） 2024年4月28日 (日) 08:43 (UTC)[回复]
更正一点:GEM TV ASIA实际使用的是DVBSUB形式的隐藏式字幕并非是内嵌字幕。(部分运营商会将外挂式字幕转为内嵌式字幕)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月28日 (日) 08:47 (UTC)[回复]
“等主要中文地区”--唔好阻住我爱国（留言） 2024年4月28日 (日) 08:58 (UTC)[回复]
同一频道同一时间播出何必作出区隔？省去几个字国名？如此致使读者以为GEM TV ASIA在此时段香港才播出此节目，在其他地方不然。因此主张在任一地方满足条件即可；同样，在任一地方属于首播即可，而不应刻意遗漏同一频道同一时间播出同一节目而非首播的地方。--— Gohan 2024年4月28日 (日) 08:58 (UTC)[回复]
这是英维“English licensee”所主张的。在英维，同一频道列A地区不列B地区是常见。--唔好阻住我爱国（留言） 2024年4月28日 (日) 09:33 (UTC)[回复]
查无相似主张。英维的Release章节并不规定：若一个电视频道同时向英语、非英语国家播出同一节目，只能列出英语国家；或一个电视频道同时向多地播出同一节目，只能列出提供英文字幕的国家或地区。一个电视频道同时向多地播出同一节目应视为单一行为，不宜片面陈述，正如可标识跨国流媒体“全球”播出。--— Gohan 2024年4月29日 (一) 06:34 (UTC)[回复]
当然是查无主张啦，因为这仅是实际操作。
个人是反对“全球”一词，世界上没有任何一个媒体可以全球通行，以 “全球”作结表示该名编辑者没有进行资料搜集、原创研究、发放错误讯息。--唔好阻住我爱国（留言） 2024年4月29日 (一) 12:59 (UTC)[回复]
若在该串流媒体的任何任务区可看，“全球”无可厚非；或许只需一个自订或变态的“ 全世界”模板作解释或tooltip。--— Gohan 2024年4月30日 (二) 08:22 (UTC)[回复]
服务地区（Service Area）--唔好阻住我爱国（留言） 2024年5月1日 (三) 02:50 (UTC)[回复]
按照您的说法那b站本身也不能作为可靠来源。(B站本身限制海外地区浏览中国大陆的影视内容只能通过B站以及代理商社交媒体查询。)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年5月1日 (三) 08:42 (UTC)[回复]
外维是直接禁止引用播放清单（不论英维还是其他维），但我的条文中却只要求该播放清单全球任何一地均可阅覧及能清楚辨认属地即可。
bilibili应该是不受影响，而YouTube, Netflix, Disney+, Viu OTT,爱奇艺等全球性平台才是影响较大。--唔好阻住我爱国（留言） 2024年5月1日 (三) 08:56 (UTC)[回复]
虽然因为确实没有主张，但是确实是有这么做的(在WP:共识中有提到在维基百科，共识是一种典型但往往含蓄无形的过程。所有没有异议或不被其他编者回退的编辑，均可假定其具备共识。)类似于J2更名为TVB Plus英语社群这边鉴于该频道只是更名并增加财经节目并不符合独立关注度所以没有跟现在中维一样建立新条目而是将条目进行移动。(要是真按照英语的共识那高清翡翠台、J5应该要合并到无线财经 体育 资讯台并删除大量琐碎细节内容。以及按照命名常规将无线财经 体育 资讯台更名为更常用的无线财经体育资讯台)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月30日 (二) 06:49 (UTC)[回复]
虽然二位都未明指“主张”是什么，但是在下意会有关主张后随机搜寻思绪中首先浮现的电视节目，竟就足以驳倒“确实是有这么做的”：英维“如懿传”条目国际播出章节列出：Star Chinese Channel在Hong Kong and Southeast Asia播出、三个越南电视台播出三次越南语配音的版本，无论如何设想都不符合“若一个电视频道同时向英语、非英语国家播出同一节目，只能列出英语国家；或一个电视频道同时向多地播出同一节目，只能列出提供英文字幕的国家或地区”或“不应记录”“节目原产地区外，不是以中（英）文提供字幕或配音的播放平台”。此外，毫不认同有关英维J2的评论，离题不赘。--— Gohan 2024年4月30日 (二) 08:21 (UTC)[回复]
然而相关方针指的是原生英文的节目。例如瑞克与莫蒂、汪汪队立大功这两个条目都是以散文的形式标注具体提供的配音版本以及配音版本的播出频道。(实际就是要求跟英文一样尽量使用散文和信息框的形式，而不是纯信息框。)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月30日 (二) 11:35 (UTC)[回复]
日后希望您在提出有关方针或指引的说法，请明示依据或直接引述。至少en:Wikipedia:Manual of Style/Television查无有关“原生英文的节目”的条文，否则请指明；版本3至今所有人的提案中亦无“原生中文的节目”一说，您提出“原生英文”所为何故？不免怀疑您在2024年4月28日 (日) 08:58 (UTC)下属的一串讨论中的近两次留言已离题，也难以猜测“确实是有这么做的”（2024年4月30日 (二) 06:49 (UTC)）到底是指怎么做？--— Gohan 2024年5月1日 (三) 03:54 (UTC)[回复]
看了一下，确实没有直接写明禁止非英语但是提到英语系国家优先。(对应段落en:MOS:TVINTLAs Wikipedia is not a television guide, do not include an indiscriminate list of every network that carried a series outside the country of production. Editors are encouraged instead to add noteworthy foreign broadcasts, if reliably sourced.These can include: broadcasts in primarily English-speaking nations such as the United States, Canada, United Kingdom, Australia and New Zealand)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年5月1日 (三) 06:43 (UTC)[回复]
要是真在某特定区域播出，直接写对应的地区就行(例如无职转生在东南亚地区曾在ANIMAX播出就直接写东盟就行了。)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月28日 (日) 10:37 (UTC)[回复]
你要说“东盟”或“东南亚”的话，请证明此动画可在泰国以Animax观看。--唔好阻住我爱国（留言） 2024年4月28日 (日) 14:41 (UTC)[回复]
该频道本身在泰国已经于2017年停播，但是部分节目仍可在TrueID以点播的形式提供。类似于ANIPLUS在香港的情况。(而且在无职转生的英语条目中对于该台播出的地区描述用的是模糊的东南亚地区而并未精准到国家)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月29日 (一) 00:05 (UTC)[回复]
如无渗透率作标准，而全面禁止重播资讯，则会导致一个电视节目若在几乎没人会看（例如渗透率低于百分之一、收视率低于万分之一）的频道首播，在最多人收看（渗透率九成八）的频道第二次播出，而后者不得记述，违背情理。--— Gohan 2024年4月29日 (一) 06:36 (UTC)[回复]
真要按渗透率台湾的无线五台(台视、中视、华视、民视以及公视)与第四台(有线电视)的基本频道渗透率相当(台湾的无线五台在第四台是必传频道)那怎么算呢？(香港这种被TVB和政府垄断而不能自由收视的地方真是令人悲哀。)--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年4月29日 (一) 07:08 (UTC)[回复]
渗透率相当，显然不符合我所提议的条文中的豁免条件：“除非传播媒介不同而使该重播频道渗透率倍增于此前任一已播出频道”。--— Gohan 2024年4月29日 (一) 11:51 (UTC)[回复]
若要用渗透率作标准，则大大提高编辑难道或引起编辑争议。
“我认为A媒体渗透高些，B很少人看。”
“我认为B媒体渗透高些，A没有人看。”--唔好阻住我爱国（留言） 2024年4月29日 (一) 13:02 (UTC)[回复]
相较收视率或其他数字，渗透率稳定、透明、标准一致，最为可取。若无更佳标准、不取渗透率，可以改为禁止“同一收视方式或受众更狭窄的收视方式的频道重播之资讯”；若仍有争议，恐怕只能改成禁止“同一频道重播资讯”；以免“一个电视节目若在几乎没人会看（例如渗透率低于百分之一、收视率低于万分之一）的频道首播，在最多人收看（渗透率九成八）的频道第二次播出，而后者不得记述”。此外，或许需要括注“（惟特有中文名称可标注相应电视台或频道）”。--— Gohan 2024年4月30日 (二) 08:26 (UTC)[回复]
这个世界有基于广告的“电视覆盖率(TV Overlay Rate)”。--唔好阻住我爱国（留言） 2024年5月1日 (三) 02:36 (UTC)[回复]
依据目前资料理解，在任何框定区域内，A频道与B频道的渗透率的比率、A频道与B频道的覆盖率的比率，是一致的（因为A频道与B频道的渗透率的分母一致，A频道与B频道的覆盖率的分母亦一致；A频道的渗透率、覆盖率的分子一致、B频道的渗透率、覆盖率的分子亦一致）。所以渗透率、覆盖率孰优孰劣，在我的提议条文（“渗透率倍增”）中没有差异。--— Gohan 2024年5月1日 (三) 03:53 (UTC)[回复]
他愿不愿意愿意到相关地区收看是他个人决定，总之这个台在该版权地区是有提供服务。
以日本为例，TVer的覆盖范围与ABEMA一致，可观看人数达124,090,000人。
TVU福岛覆盖全福岛县，可观看人数达 1,817,228人
TBS电视台覆盖整个关东广域圈，可观看人数达43,191,414人--唔好阻住我爱国（留言） 2024年5月1日 (三) 02:49 (UTC)[回复]
“渗透／覆盖不到”即循此种方式无法观看，外乎意愿。--— Gohan 2024年5月1日 (三) 03:53 (UTC)[回复]
我想探讨一下“范围”，以上面的全球和东协为例，难道要为了几个没有营业国家/地区而特地列出实际有播出的国家/地区吗？这对串流节目、大型赛事可是一大麻烦（例如欧洲歌唱大赛特地把俄罗斯以外的欧洲国家写出来）。 --窝法乙烷 儿法梦碎 2024年5月1日 (三) 03:46 (UTC)[回复]
至少英语社群相关方面都是直接写模糊的地区而不是写对应国家。--马哈迪跟哈迪阿旺走的越来越近了。--老墨泡芙真好吃。 2024年5月1日 (三) 03:51 (UTC)[回复]

版本4

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外的播放资讯。 相反，如果来源可靠，鼓励编辑者新增值得注意的非生产地区的播放资讯。这些可能包括：在中国大陆、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的播放资讯；相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议。节目的播放平台可观看地区都需要列明来源及符合可供查证原则，否则其他编辑者有权因可能违反著作权法为由移除未能辨认可观看地区的整组播放资讯。因应地区IP而调整播放内容的网路播放平台连结、需要登入方能阅读播放清单的网路播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。

下列资料不应被记录：
  • 准确播放时间。（不包括播放日期及播放时段）
  • 推迟不足30分钟或并非偶发的延误播放之资讯。
  • 电视节目重播资讯（在该节目授权区域内的相关播放平台覆盖比率/可观看人数较首播平台的覆盖比率/可观看人数高一倍或更多除外。）
  • 节目原产地区外，不是以中文提供字幕或配音的播放平台。

--唔好阻住我爱国（留言） 2024年5月1日 (三) 05:08 (UTC)[回复]

你的文本内容越来越累赘，有些内容不妨说得再直白一点，修改一下部分描述：“维基百科不是电视指南，请勿不分青红皂白地列出原产地之外的播放资讯。编辑者在有来源可靠的情况下，在条目中记录值得注意的非原产地的播放资讯，如中国大陆、台湾、香港、澳门、马来西亚、新加坡等中文使用地区的首播资讯，还有原生中文节目在还非中文使用地区的首播资讯，或者大规模的国际播放资讯。节目的播放平台及网络电视的节目可观看地区都需要列明来源，网络电视节目连结不合适作为来源，因地区限制访问，部分编者无法查核，来源是否可靠请通过讨论协商。”

英维原文可没有“否则其他编辑者有权因可能违反著作权法为由移除未能辨认可观看地区的整组播放资讯。因应地区IP而调整播放内容的网路播放平台连结、需要登入方能阅读播放清单的网路播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。”这段，而是建议讨论来源是否可靠，因为条目使用可靠来源本身就是“内容指引”，需要的是讨论来源是否可靠（WP:RSP）。--Nostalgiacn（留言） 2024年5月1日 (三) 15:55 (UTC)[回复]

第一段不反对，第二段仅重申Category:电视外部资源模板相关连结只是外部链接，并非来源。更什有编辑者直接扔了Netflix连结出来，当开启连结时发现是Error。
因应地区IP而调整播放内容的网路播放平台连结、需要登入方能阅读播放清单的网路播放平台连结—> 重新解䆁WP:可供查证及WP:外部链接方针。--唔好阻住我爱国（留言） 2024年5月1日 (三) 18:13 (UTC)[回复]
而如直接使用WP:RSP，bilibili及Youtube已经不给使用了。--唔好阻住我爱国（留言） 2024年5月1日 (三) 18:15 (UTC)[回复]
WP:RSP描述是，官方内容作为一手资料可靠，也符合可供查证的自身说明（WP:ABOUTSELF）。bilibili及Youtube也适用，不过结合“网络电视节目连结不合适作为来源”的描述。更建议使用官方在官网、社交平台、或bilibili及Youtube上预告节目播放的日期动态/公告。--Nostalgiacn（留言） 2024年5月4日 (六) 01:22 (UTC)[回复]


现行条文

由于维基百科不是电视指南，因此不要不分青红皂白地列出在生产地区以外的播放资讯。 相反，如果来源可靠，鼓励编辑者新增值得注意的非生产地区的播放资讯。这些可能包括：在中国大陆、台湾、香港、澳门、马来西亚、新加坡等主要中文地区的播放资讯；相关地区的通用语言不是中文，但首次播放以中文制作节目的播放资讯；或大规模国际发行协议。节目的播放平台可观看地区都需要列明来源及符合可供查证原则，否则其他编辑者有权因可能违反著作权法为由移除未能辨认可观看地区的整组播放资讯。因应地区IP而调整播放内容的网路播放平台连结、需要登入方能阅读播放清单的网路播放平台连结、Category:电视外部资源模板相关连结及社群媒体并不是可接受能证明可观看地区的来源。

提议条文

维基百科不是电视指南，请勿不分青红皂白地列出原产地之外的播放资讯。编辑者在有来源可靠的情况下，在条目中记录值得注意的非原产地的播放资讯，如中国大陆、台湾、香港、澳门、马来西亚、新加坡等中文使用地区的首播资讯；原生中文节目在非中文使用地区的首播资讯；或大规模的国际播放资讯。节目的播放平台及网络电视的节目可观看地区都需要列明来源，网络电视节目连结不合适作为来源，因地区限制访问，部分编者无法查核。关于个别播放平台节目连结是否可被直接引用，请在本指引讨论页讨论协商或评选，唯讨论重点应放在著作权法及可供查证原则。

曾经有编辑者把盗版连结放入播放平台区域，故希望借此指引提醒编辑者著作权法的重要性。--唔好阻住我爱国（留言） 2024年5月1日 (三) 18:34 (UTC)[回复]

上方讨论太长未看全，就该版本的疑问（如已有结论，希望加脚注）：原产地之内的播放信息似乎被暗示可“不分青红皂白地列出”。原产地的准确定义，范围，联合制作、外包、仅外销等。很多字句应修饰，如“在有来源可靠的情况下”等，由于非定稿我暂时不全部列出。“网络电视节目链接不合适作为来源”听上去有点奇怪，有点像某个来源非公开可用（需登录/部分地区/线下来源）就不适合作来源，可能意思需改善，比如不能访问现象本身、无法存档的网页内容，不适合作来源。--YFdyh000（留言） 2024年5月1日 (三) 19:36 (UTC)[回复]
@YFdyh000:
欢迎任何具建设性的修饰句子。--唔好阻住我爱国（留言） 2024年5月2日 (四) 11:07 (UTC)[回复]
改为“原产地的首播资讯”就行，上面《还珠格格》就是限制播放资讯在“首播”。
YFdyh000提到的情况，我想起了近期一个例子《食草老龙被冠以恶龙之名》，日本轻小说，由中国大陆澜映画制作的动画版在bilibili上首播（2022年7月），2023年1月才在日本电视台播出（[4]）（[5]）。这种涉及跨国版权的节目，“原产地”算中国大陆，还是日本。
早年中港、港台合拍剧也不少，不过都属于“中文使用地区的”，所以反而没有这些记录争议。--Nostalgiacn（留言） 2024年5月4日 (六) 01:35 (UTC)[回复]

版本5

希望这是最终版

标题：播放资讯

维基百科不是电视指南，请勿不分青红皂白地列出电视节目的所有播放资讯。编辑者在附上可靠来源的情况下，可在条目中记录值得注意的播放资讯，如节目原产地的首播资讯；中国大陆、台湾、香港、澳门、马来西亚、新加坡等中文使用地区的首播资讯；原生中文节目在非中文使用地区的首播资讯；或大规模的国际播放资讯。节目的OTT播放平台及网络电视的节目可观看地区均需列明来源，网络电视节目播放连结不建议作为证明“可观看地区”的来源，因网络电视节目播放连结通常不会记录可观看地区。关于能否引用特定OTT播放平台的连结，可在本指引的讨论页商议，重点为著作权法和非原创研究原则。

下列资料即使附上来源也不应被记录：

  • 准确播放时间。（不包括播放日期及播放时段）
  • 推迟不足30分钟或并非偶发的延误播放之资讯。
  • 电视节目重播资讯。（在该节目授权区域内的相关播放平台可观看人数较首播平台的可观看人数高一倍或更多除外。）
  • 不是以中文提供字幕或配音的播放平台。（节目原产地区播放平台或以中文制作的节目除外。）

--唔好阻住我爱国（留言） 2024年5月8日 (三) 08:26 (UTC)[回复]

“网络电视节目播放链接不合适作为来源，因地区限制访问，部分编者无法查核。”语序希望优化；地区性或可能失效的视频的网络播放源，有时是有用的，作为某些信息的一手来源，{{Cite AV media}}，但提供者唯一且无法存档的确实不宜用。“网络电视节目播放链接”被运用时如何区分，我担心存在理解差异。
“个别”是“特定（某个）”吗。“直接引用”，所以有间接引用吗。建议可在、协商或评选、唯应，感觉语意重复。“关于能否引用特定播放平台的链接，可在本指引的讨论页商议，重点为著作权和可供查证原则”。
“准确播放时间”指的是实际播出时点、时长吗，是否与下一条有重复。
“非偶发的延误播放之信息”指什么，已宣布的推迟播放不宜记录？--YFdyh000（留言） 2024年5月8日 (三) 08:51 (UTC)[回复]
  • 对不起，不能使用“视频”字眼，因实际应用场合不同，放在繁体字地区，意思截然不同。
  • 网路电视是IPTV,网路播放平台是OTT。
  • “关于能否引用特定播放平台的连结，可在本指引的讨论页商议，重点为著作权和可供查证原则”，这个可以。
  • 没有重复。
  • 意指不应收录恒常延误播放资讯。如果每一集也记录为什么延迟播放，那么与电视指南有什么分别？
--唔好阻住我爱国（留言） 2024年5月8日 (三) 10:31 (UTC)[回复]
@YFdyh000、@Nostalgiacn、@Milkypine、@Cwek、@CaryCheng、@甜甜圈真好吃、@神秘悟饭:
如没有特别大的问题，3日后将按照版本5进行公示。--唔好阻住我爱国（留言） 2024年5月10日 (五) 09:55 (UTC)[回复]
我发现有些概念有待厘清，网络电视目前英维对应是Streaming television，IPTV也可以翻译做“网络电视”。搞清楚条目内容和概念，可以更准确描述内容。Streaming television在描述上包括IPTV和OTT等情况。--Nostalgiacn（留言） 2024年5月10日 (五) 10:54 (UTC)[回复]
沿用中文解释及例子，因为这里是中文维基百科。中文社群均认为OTT是类似Netflix, Disney+，甚至有播放平台以OTT自居，如myTV SUPER。更什台湾有OTT协会，大部分台湾网络播放平台也加入了。--唔好阻住我爱国（留言） 2024年5月11日 (六) 00:33 (UTC)[回复]
换句话说，除非有人重新整理该两个条目至英维内容，否则再改也没有意思。但是在中文社群而言，英维对OTT的理解是错误的。--唔好阻住我爱国（留言） 2024年5月11日 (六) 00:47 (UTC)[回复]
(＋)支持。--CaryCheng（留言） 2024年5月10日 (五) 15:36 (UTC)[回复]
——
3日内无反对声音，现就版本5进行公示，公示7日至5月20日星期一止。--唔好阻住我爱国（留言） 2024年5月13日 (一) 03:25 (UTC)[回复]
(＋)支持版本5。 --窝法乙烷 儿法梦碎 2024年5月16日 (四) 14:33 (UTC)[回复]

方针研究

无奈衹能(－)反对，仅仅“因地区限制访问，部分编者无法查核”就不能作为来源的话，未免过严。举例说：西游记 (无线1996年电视剧)，那个年代TVB还没有网站，这样的规定岂不是不能引用首播前的广告（广告里有说明首播日期）作为来源？（那个广告衹在香港播出，理论上衹有香港地区才能看到）［当然有人在FB上传了那个广告而可能非法地突破了地区限制，故也因此将来可能随时会被移除］--街燈電箱150號 开箱维修 抄表 检验证明 2024年5月17日 (五) 18:24 (UTC)[回复]
  • 我有合理怀疑阁下并没有仔细阅读清楚条文，仅意气用事。
  • 请望淸楚“因地区限制访问，部分编者无法查核”是针对那些媒介。
    • 针对那些媒介提及的例子，请问阁下可否拿出连结？
  • 既然阁下不打算改可供查证，不看得出对阁下提及的例子有任何影响，因条文建议编辑者依靠可供查证为个别媒体进行协商。
  • **条文并无要求传统电视内容提供来源**
  • FB已被可靠来源方针定为不可靠（不是我改的）
--唔好阻住我爱国（留言） 2024年5月18日 (六) 04:01 (UTC)[回复]
@Cdip150--唔好阻住我爱国（留言） 2024年5月18日 (六) 04:07 (UTC)[回复]
问题不是出在针对哪些媒介，也不是是否要求传统电视内容提供来源的问题。正如Ghren君在下面所述，地区限制的连结本来就是可供查证允许的东西，所以根本不可以“因地区限制访问，部分编者无法查核”为由去说“网络电视节目播放连结不合适作为来源”。换句话说，在现有可供查证方针下，这些连结本应就不需要经过协商便能使用，但您这样一改变成把它预设为不适当、而需要额外的协商才能用，有僭越可供查证方针之虞。另外，由于有关问题需要继续研讨，恕敝人要先把公示中止。--街燈電箱150號 开箱维修 抄表 检验证明 2024年5月19日 (日) 10:34 (UTC)[回复]
@Cdip150:
首先，我希望阁下可以看清楚到底是什么需要什么的来源。 该句的首句是“可观看地区”需要来源，如果坚持是反对，看看阁下有没有违反WP:非原创研究方针。换句话说，你要用一个网路电视播放清单证明A,B,C地区可以观看。
然而，运用CDN限制的平台，如果要证明A,B,C地区可以观看，实际是违反WP:非原创研究的 “综合已发表材料”段落。--唔好阻住我爱国（留言） 2024年5月20日 (一) 01:13 (UTC)[回复]
为了你，再改。但下次可否不要在公示完结当天反对？其实我可以因公示完成而无视阁下的反对。
———
节目的OTT播放平台及网络电视的节目可观看地区均需列明来源，网络电视节目播放连结不合适作为来源，因网络电视节目播放连结通常不会记录可观看地区。关于能否引用特定OTT播放平台的连结，可在本指引的讨论页商议，重点为著作权法和非原创研究原则。--唔好阻住我爱国（留言） 2024年5月20日 (一) 01:37 (UTC)[回复]
应该是描述有歧义，需要更准确的描述，现在的条文是可以理解成限制地区访问的连结不能作为来源，这个思路会出现Youtube中国大陆不能访问，所以不能用。
而你想限制的是来源不能用于说明可观看地区。如，Ani-One Asia的Youtube频道，过去的视频简介是没有写明可观看地域（[6]），近年有了“播放地区：孟加拉、不丹、汶莱、柬埔寨、斐济、香港、印度、印尼、寮国、澳门、马来西亚……”（[7]）--Nostalgiacn（留言） 2024年5月22日 (三) 16:20 (UTC)[回复]
对，没有错！这是呼应其他维（不限于英维）的实际做法，但稍微放宽。其他维是完全禁止使用播放清单作为证明可观看地区的来源。而我的提案只需符合著作权法和非原创研究原则即可。
.
以下是个人见解，与新提案可能有关。
Netflix, Disney+, Amazon Prime Video, YouTube, IQIYI, Viu OTT 的播放清单是肯定违反非原创研究方针。
friDay, KKTV, LiTV, Hami Video, myTV SUPER, now E 的播放清单可能违反是非原创研究方针中的“综合已发表材料” ，因播放清单中没有说明可观看地区，只在平台使用条款说明。--唔好阻住我爱国（留言） 2024年5月22日 (三) 16:56 (UTC)[回复]
“网络电视节目播放连结不合适作为来源，因网络电视节目播放连结通常不会记录可观看地区”：如果“网络电视节目播放连结”记录了可观看地区，能否记录？--Ghren🐦🕑 2024年5月24日 (五) 06:23 (UTC)[回复]
是的--唔好阻住我爱国（留言） 2024年5月24日 (五) 08:22 (UTC)[回复]
由于@Cdip150在本人回答及更正部分用词后3天没有进一步回复。根据WP:共识#一般公示基本规定，现视播放清单不能作为证明“可观看地区”的问题已经获得解决。
————
现就版本5 V2进行公示，公示7日至5月31日星期五止。--唔好阻住我爱国（留言） 2024年5月24日 (五) 05:53 (UTC)[回复]
正如Ghren君在下面所述，可以注明是在哪个地区下浏览（事实上cite模板还有location参数可以注明是哪个区的），自然也不会有原创研究的问题。还有搞清楚“综合已发表材料”的前提——是将多个内容作出综合才会触法，也即是说如果从香港区的Netflix播放清单作为来源去证明香港区可以观看及香港区的播放时间，是不会违反非原创研究方针中的“综合已发表材料”，因为根本不是在多个内容中综合出来的资料，而衹是取自一个内容。阁下上面的理由足见阁下对于非原创研究“综合已发表材料”的见解并不正确，故此上述问题并未合理解决。而且，阁下在恢复公示后，Ghren君抛一个问题出来才又修改（公示后才将“不合适”改为“不建议”，两个完全不同的意思），加上有关条文还是基于阁下对于非原创研究的可能不正确之见解，故此恕敝人还是要把公示中止，有关问题需要继续研讨。（还有请阁下说话前查明事实——我早在公示结束前3天已经提出反对，而非您说的在公示完结当天才反对）--街燈電箱150號 开箱维修 抄表 检验证明 2024年5月27日 (一) 19:44 (UTC)[回复]
@Cdip150:
首先，如何证明你从香港区的Netflix播放清单作为来源去证明香港区可以观看？按Netflix,除了网络限制区不能浏览外，全世界也可浏览，你要如何证明特定播放清单内的特定集数可在特定区域成功观看？这个见解请在及后的商议自行发表，而非在此发表。
其次，请看清楚“ “综合已发表材料””是针对哪些例子？
第三，请看清楚该段首句“ 以下是个人见解”，如阁下认为Netflix可以基于版权及非原创可被引用，阁下应待通过后自行与其他编辑者商议。
回应@Ghren在上方述“ “网络电视节目播放连结不合适作为来源，因网络电视节目播放连结通常不会记录可观看地区”：如果“网络电视节目播放连结”记录了可观看地区，能否记录？”，既然该播放清单有提供所需资讯，为何不能遭引用？
——
另外，公示继续，因提案提及对于非原创研究的理解是以集体商议为主，而非个人见解。以上！--唔好阻住我爱国（留言） 2024年5月28日 (二) 14:33 (UTC)[回复]
承Ghren君在下面所说的：“就算是借阅，也是有指定图书馆的（地区限制）”，意味读者衹需亲身前往指定图书馆便可查证得到；换成香港区的Netflix播放清单的话，就是读者亲身前往香港并浏览Netflix便可证实得到“香港区可以观看”；注意Ghren君也说的“‘需要注册、付费、特定区域、启动外部程式或插件的网站’……也无损于来源的可靠性”。既然是维基制度内允许的东西，本应就是不用事先商讨就能用的东西，“这个见解请在及后的商议自行发表”根本无从谈起，不然您这样有僭越方针之虞。
Wikipedia:非原创研究#综合已发表材料针对的是“因为A和B，所以C”的情形，而编者直接浏览香港区的Netflix播放清单后将香港区的播放资讯写在条目里，明显就不是“因为A和B，所以C”的情形（这是看到来源说了A，条目里照写A）；所以直接引用Netflix播放清单并不违反非原创研究。（是故阁下所说“运用CDN限制的平台，如果要证明A,B,C地区可以观看，实际是违反WP:非原创研究的‘综合已发表材料’段落”本身就是错误的说法，况且读者可以亲身前往A,B,C地区浏览有关资讯来进行验证）
那么既然一开始就不可以认定引用Netflix播放清单是违反非原创研究，何解还要“应待通过后自行与其他编辑者商议”？当本身就没有违反非原创研究时，从何谈起“对于非原创研究的理解是以集体商议为主”？也就是说，“关于能否引用特定OTT播放平台的连结，可在本指引的讨论页商议”这种规则本来就不该订出来，这是变相预先假定引用特定OTT平台是在进行原创研究。
另外我是说“两个完全不同的意思”，何解您会理解为“不能遭引用”？我根本没有这个意思，衹是想说您公示后才改为意义不同的内容，根本不宜继续公示。不过我也要指出的是：“因网络电视节目播放连结通常不会记录可观看地区”并非“不建议作为来源”的合理理由，原因如前述——读者可亲自前往所指的可播放地区浏览该网络电视平台进行验证。
基于上述指出的问题仍然有讨论必要，本人中止此公示，在没有得到明确结论前不应恢复公示，还望阁下留意。--街燈電箱150號 开箱维修 抄表 检验证明 2024年5月28日 (二) 19:51 (UTC)[回复]
首先，针对Netflix，实际是违反“ 维基百科不是存放原创研究或原创观念的场所。在维基百科里所谓原创研究或原创观念，指的是未发表的事实、争论、观点、推论和想法；以及对已发表材料进行的未发表分析、综合或总结，并产生或暗示新的结论。以上意味著维基百科不是存放您的个人观点、经验或争论的场所。”段落，而非综合已发表段落。
Netflix有这样的播放清单，但只字不提哪里可以看。如编辑者单凭一个Netflix播放清单就可判定哪些地区可以看，此仅是“产生或暗示新的结论。”。--唔好阻住我爱国（留言） 2024年5月29日 (三) 00:27 (UTC)[回复]
这边的人没人接触过Netflix等以外的早年OTT平台？够Yeah在互联网档案馆上的存档随便点一部动画[如一骑当千第二季]的立即播放按钮进去会显示“此片只在香港地区放映”。相信这难以说是原创研究。--S叔 2024年6月27日 (四) 06:30 (UTC)[回复]
问题是这个是一个编辑者自行测试的一个过程，如果阁下可在不用转换ip的状况下获得该影片的可观看地区，那应该没有人会质疑是这是原创研究。--唔好阻住我爱国（留言） 2024年6月27日 (四) 11:18 (UTC)[回复]
网路档案馆就是以其服务器及其IP地址存储某一网站在某日子的存档，然后再开放给大众阅覧存档。因此在上面是能够在够Yeah服务范围[如香港]的情况下显示上述语句，这不会因为改IP而出现变动。同样，若一个只服务中国大陆的OTT服务由港澳台用户使用也可能显示“此影像只供中国大陆地区的用户”使用。为何你会认为需要别人改IP才能试出？--S叔 2024年6月27日 (四) 11:46 (UTC)[回复]
如果阁下可在不用转换ip的状况下获得该影片的可观看地区，那应该没有人会质疑是这是原创研究。--唔好阻住我爱国（留言） 2024年6月27日 (四) 11:55 (UTC)[回复]
假设您在中英街接收香港的移动信号或者是在厦门接收台湾的移动信号。应该不算是原创总结吧？--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月27日 (四) 11:59 (UTC)[回复]
如果是香港，是原创研究，因为香港电讯商不公布流动网络的街道覆盖范围（这是他们的内部资料）。而台湾不算，因为他们三家电讯商有主动公布覆盖范围。--唔好阻住我爱国（留言） 2024年6月27日 (四) 12:09 (UTC)[回复]
另求管理员@Ericliu1912，希望我是对非原创研究方针的理解是没有错。--唔好阻住我爱国（留言） 2024年5月29日 (三) 00:30 (UTC)[回复]
“实际是违反WP:非原创研究的‘综合已发表材料’段落”这句明明就是阁下说的，所以您现在是反口吗？不过也不紧要，请注意方针开头的序言实际上是下面段落细节的浓缩版，条目内容实际有否违反方针，当然要依方针后面段落的明细来判断，而非仅拿方针的序言就算，也就是说条目内容有没有犯“维基百科不是存放原创研究……经验或争论的场所”，当然还是要看回相关段落（这里也就是Wikipedia:非原创研究#综合已发表材料）的详细解释。您现在仅仅引用方针开头的序言就片面去说违反，怎么可能恰当？
假设某人在香港，从播放清单观看得到某节目，然后该人在该节目的条目中写香港区可以看，这是一个非常直观的描述，不属于“产生或暗示新的结论”。内容有没有原创研究，完全要看编者写成怎样才会知道，不可能事先认定使用某种来源就一定是原创研究。--街燈電箱150號 开箱维修 抄表 检验证明 2024年5月30日 (四) 23:57 (UTC)[回复]
这个是其中一个笑话：PUI PUI 天竺鼠车车
“木棉花授权地区以外地区：Netflix”，意指公众可在北韩、俄罗斯等网络限制区开Netflix即可查证…
还有的是“亚洲：Netflix”，意指公众可在北韩、中华人民共和国等网络限制区开Netflix即可查证…--唔好阻住我爱国（留言） 2024年5月31日 (五) 01:58 (UTC)[回复]
我需要行政员@AT看看街灯的这个表述有没有错，毕竟之前有管理员以此进行封锁。--唔好阻住我爱国（留言） 2024年5月31日 (五) 02:00 (UTC)[回复]
您这样相当于是说用Netflix作为来源表示北韩可看会是原创研究，继而去说用Netflix作为来源表示美国可看也是原创研究，您这样无疑是在以偏概全。还是这句：“内容有没有原创研究，完全要看编者写成怎样才会知道，不可能事先认定使用某种来源就一定是原创研究”。--街燈電箱150號 开箱维修 抄表 检验证明 2024年6月2日 (日) 17:43 (UTC)[回复]
一个Netflix播放清单，配上播放地区，请问如何写才不算原创研究？
文章没有表述的而强行配上个人见解不是原创研究，这个“管理员”说法我一定会大规模推广的。--唔好阻住我爱国（留言） 2024年6月3日 (一) 00:26 (UTC)[回复]
另外，格式手册的精神不是防止人治吗？
“内容有没有原创研究，完全要看编者写成怎样才会知道，不可能事先认定使用某种来源就一定是原创研究”—>这句在不少编辑者视为“如有任何争议，依管理员决定为最终依归”，而不是“如有任何争议，依白纸黑字为最终依归”
.
另外，此提案只有阁下一人反对，其他人也支持，显然阁下希望扰乱共识。此外，本提案参与者普遍即日互相讨论交换意见，显然提案有迫切需要，而阁下也在我每次回应后临近“一般公示基本规定”临界点才提出回复，显然有“拉布”企图。
.
另外，不知是哪位管理员（不点名批评曾被我ping过而默不出声的管理员），更改了公告栏的标题，原标题已无法反映当前讨论的内容，故本人更改了。
.
最后，烦请希望@Cdip150表达意见前ping一ping提案所有参与者，让他们知道阁下的看法。--唔好阻住我爱国（留言） 2024年6月3日 (一) 11:28 (UTC)[回复]
“编者直接浏览香港区的Netflix播放清单后将香港区的播放资讯写在条目里”这句我想已经说得很白；
文章没有明确表述，但若文章本来就有所指的意思，则不属于产生或暗示新的结论或个人见解，很明显您这样的理解是在断章取义。
“完全要看编者写成怎样才会知道”从来就不是由管理员一个来决定，这是您个人猜想出来的见解，无从稽考。事实上也是要各人依照现有的规则去认定，谈不上任何“人治”。
注意共识不是点票，况且其他人表示支持时敝人仍未指出问题，坦白说如果您不是另外又发起#提议外部链接指引WP:ELNO同时编入WP:可供查证，我也未必察觉到上述提案与现有的方针不相配，所以我才出手，并不是要希望扰乱共识。还有我除了一次是隔八天和一次是隔两天半回复外，基本上自阁下最后回应后不足两天就回复阁下，何来每次回应后临近“一般公示基本规定”临界点才提出回复？另外本人因现实生活繁忙不太可能每天都上来回复，隔几天才上来这种事在参与本讨论前已经出现，并非刻意拉布。再一次提醒阁下在说话前查明事实，勿轻率作出指控。@YFdyh000、Nostalgiacn、Milkypine、Cwek、CaryCheng、甜甜圈真好吃、神秘悟饭--街燈電箱150號 开箱维修 抄表 检验证明 2024年6月5日 (三) 00:17 (UTC)
试说明下列影片的完整可播放地区及说明阁下是基于甚么证据会有这个见解？ https://www.netflix.com/hk/title/81771389 --唔好阻住我爱国（留言） 2024年6月6日 (四) 10:54 (UTC)[回复]
参考“文章没有明确表述，但若文章本来就有所指的意思，则不属于产生或暗示新的结论或个人见解，很明显您这样的理解是在断章取义。”，请问文章本来所指的意思是什么？如果阁下可根据Netflix的播放清单说明播放地区，那看来阁下才是“断章取义。”--唔好阻住我爱国（留言） 2024年6月6日 (四) 13:48 (UTC)[回复]
利用代理器切到世界各个地区，每个地区都各浏览一次该网址便可查验。日本区看到这是WIND BREAKER—防风少年—，其他区均显示404信息。
尽管网站没有表明香港可以浏览，但您在香港确实可以浏览该网站的话，如果仅因为网站没有明确表示香港可以浏览，所以不能说香港可以浏览，就是在断表面之意，而未取可以一望而知的实际意义（真的可以在香港浏览）。--街燈電箱150號 开箱维修 抄表 检验证明 2024年6月9日 (日) 04:01 (UTC)[回复]
  • “一望而知”概念仅适用于本地OTT平台，如一看到KKTV就想起只有台湾可以观看。
  • “利用代理器切到世界各个地区，每个地区都各浏览一次该网址便可查验。”难道阁下不是花了4天才得出完整可观看地区？如果可透过“一望而知”就知道可观看地区，那还需要利用代理器切到世界各个地区，每个地区都各浏览一次该网址便可查验？
--唔好阻住我爱国（留言） 2024年6月9日 (日) 07:37 (UTC)[回复]
不懂你们说什么，但自己试出限制显然不可靠、原创研究、非可供查证。网站可能屏蔽代理、云主机等，校园网、家宽IP或网站防火墙等都会干扰结果。--YFdyh000（留言） 2024年6月9日 (日) 11:04 (UTC)[回复]
既然日本限定的难不到阁下，可挑战台湾限定的。
这个是村里来了个暴走女外科于Netflix的播放清单，当使用台湾代理器（大品牌）进入此播放清单，应被跳至（重路由至）南美洲，从而得出404。
在这个情况下，阁下提出的“就是在断表面之意”就更不成立，因为测试过程可以被干扰。
https://www.netflix.com/hk/title/81592470--唔好阻住我爱国（留言） 2024年6月9日 (日) 11:26 (UTC)[回复]
“一望而知”并非“合计衹望一次而知”啊，是在说前往各地区进入一次后即可知道当前的地区能不能看，而非立即从播放清单的表面就知道哪里能看。
事实上最正确的查验方法是亲身前往各个地区进入一次该网站，我用代理衹不过是尽量模拟真实情况来节省时间，不然我要花更长更长的时间才能答得到您（我切换到台湾区后是可以在Netflix看到村里来了个暴走女外科），即使代理可能会因上述一些因素而未必准确，但不应因此也要认定亲身前往特定地区浏览也是原创研究。另须注意花很久时间才能查证不代表不可查证，如果我旅行往日本在Netflix的播放清单看得到WIND BREAKER—防风少年—，然后当我说在日本可以用Netflix看也要被视为原创研究，我觉得有些不合情理。其实上面Nostalgiacn君已经指出了一点：英维对应的规则其实并没有禁止或不建议因应地区IP而调整播放内容的网络播放平台连结，已经可见一斑。还是这句：“内容有没有原创研究，完全要看编者写成怎样才会知道，不可能事先认定使用某种来源就一定是原创研究。”--街燈電箱150號 开箱维修 抄表 检验证明 2024年6月11日 (二) 06:39 (UTC)[回复]
回应“英维对应的规则其实并没有禁止或不建议因应地区IP而调整播放内容的网络播放平台连结”，
本人于6月9日到英维互助客栈求助区查询Netflix播放清单可不可以证明可观看，结果有2名编辑者回答，一名有名编辑者表示会违反非原创研究方针，一名IP用户表示如引用则会被封锁，即使是管理员也如此。--唔好阻住我爱国（留言） 2024年6月11日 (二) 11:31 (UTC)[回复]
回应“即使代理可能会因上述一些因素而未必准确，但不应因此也要认定亲身前往特定地区浏览也是原创研究。”，
请问哪条方针指引容许“维基人到现场目测后在维基内记录所见所闻”？--唔好阻住我爱国（留言） 2024年6月11日 (二) 11:35 (UTC)[回复]
@HK5201314、Cdip150：我看了最近的一大串讨论，Cdip150的观点大概是来自英维的en:WP:SOURCEACCESS，本地可供查证尚缺乏这方面的讨论。
就实体书而言，这个规则是默认的。简而言之，编者在A国图书馆能找到这本书，B国编者在当地找不到，不能以此为由认为这个书“不存在”。你们上面的讨论算是互联网版本，除了一般的付费墙拦截问题，Netflix的国别限制访问又出现新的问题。
我认为上面讨论混淆了“能否访问网页”和“网页上内容”两个概念，后者容易理解，和“各地图书馆藏书”的例子一样，B国无法访问网站，不等于A国访问看到的内容不算数。
前者就是现在争论的点，网络技术让A国编者可以用VPN换地区一个一个试能否访问，以得出“那些地区能访问”的结论。这个行为，个人认同YFdyh000的说法试出限制显然不可靠、原创研究、非可供查证。--Nostalgiacn（留言） 2024年6月12日 (三) 05:55 (UTC)[回复]
@Nostalgiacn:
街灯管理员的例子应是：
编者A在A国图书馆能找到这本书，编者B在B国图书馆找不到这本书。于是编者A用该书本的“ISBN编号”说明A国图书馆能找到这本书。
.
然后不断强调：
“内容有没有原创研究，完全要看编者写成怎样才会知道，不可能事先认定(使用某种来源)就一定是原创研究。”
换做例子，应是：
“内容有没有原创研究，完全要看编者写成怎样才会知道，不可能事先认定(引用ISBN编号证明该书本可于某地阅览)就一定是原创研究。”
.
然而，可供查证方针仅指出内容本身，而非透过该内容的标题及其内容而说明可在哪个图书馆获取相关书本。--唔好阻住我爱国（留言） 2024年6月12日 (三) 11:10 (UTC)[回复]
这就是我说的混淆了“能否访问网页”和“网页上内容”两个概念。Cdip150说的是后者，你其实是想针对的是前者。为了避免前者的情况，限制“平台的连结”。造成他忧虑是变相限制“网页上内容”的利用。
需要在描述上厘清两者差异，避免可能的误解。--Nostalgiacn（留言） 2024年6月12日 (三) 11:47 (UTC)[回复]
原句：“网络电视节目播放连结不建议作为证明“可观看地区”的来源，因网络电视节目播放连结通常不会记录可观看地区。”
.
我针对的也是后者呀！“能否访问网站”是可供查证本身规管的（现已放弃相关句子），而“网页上内容”是原创研究规管的（此公示的句子）。网站本身没有提及的要诬蔑它有说的是原创研究，对吗？
原案也提及播放连结只是不建议作为证明“可观看地区”的来源，而不是不建议作为“正式标题”／在“？？平台上架”的来源。--唔好阻住我爱国（留言） 2024年6月12日 (三) 12:08 (UTC)[回复]
我明白你的意思，毕竟2024年5月22日我就在用Ani-One Asia的例子说明这种情况。请循其本Cdip150质疑的文段是“因地区限制访问，部分编者无法查核”。单从这个描述，是可以简单解读为“B国无法访问网站，等于A国访问看到的内容不算数”这个结论。
然后你们讨论开始歪楼到“能否访问网页”这个议题上了。说到底还是在条文上厘清两者差异，避免可能的误解。--Nostalgiacn（留言） 2024年6月12日 (三) 13:16 (UTC)[回复]
(？)疑问：下列资料即使附上来源也不应被记录：“电视节目重播资讯。”这是不是指大时代 (香港电视剧)#2015年翡翠台重播的内容全部都要删除？--素菓霖 2024年6月15日 (六) 12:45 (UTC)[回复]
如果是“大时代 (香港电视剧)#2015年翡翠台重播的内容”，一半准确。事件的重点应放在财政司司长的发言及万千星辉颁奖典礼上，而非节目的播放资讯如播放平台及播放日期。--唔好阻住我爱国（留言） 2024年6月15日 (六) 14:55 (UTC)[回复]
只针对@Kalin8111提出的疑问给出思想实验
  • A是一个全球/区域性的作品，从上映到现在已经10年以上，也有至少多个系列作(含翻拍、重制、重剪辑或电影版)产生，一或多个区域每年重播。假设有帐号有能力针对每次重播提出来源，页面增加将近1000个来源。在这个情境，是否适合记录。
  • B是一个区域性的作品，从上映到现在大约将近1年，因为当地有多种平台(包含单一公司有数种播放平台)，除了在首映的平台重播外，也在其他数个平台重播，假设有帐号有能力针对每次重播提出来源，页面增加将近20个来源，在这个情境，是否适合记录。
  • 第二项的情境，B每年固定增加同样数值的重播资讯及来源，在这个情境，是否适合记录。
  • 第三项的情境，B可以使用的来源几乎全部是第一手来源，是否WP:关注度不足
--Rastinition（留言） 2024年6月15日 (六) 20:17 (UTC)[回复]
“ 第一手来源”通常即指@Cdip150最关注的“播放清单”问题。如果他没有其他反对论点的话，3日后即公示。--唔好阻住我爱国（留言） 2024年6月16日 (日) 05:20 (UTC)[回复]
@HK5201314我个人认为你如果一直没办法公示完成，调整方向，同时分项公示，先把已经结束且没有异议的用讨论关闭的方式处理，随著时间经过，你的主题和讨论的方向会无可避免的琐碎/复杂/肥大混合些许离题。
可以关闭/通过的，即使只有少数或小部份，能关闭就能避免过度增生。其他还不能关闭/通过的留著继续处理。--Rastinition（留言） 2024年6月27日 (四) 12:08 (UTC)[回复]

基于Cdip150对条文的异议并本人因他的异议而作出了用词上的修订（目标与原第五版一致）。在修订后7日内，共有3名编辑者均对他提出见解及例子表示了其结构性问题，而他并没有对相关问题有任何回应，根据WP:共识，Cdip150提出的疑问已获得解决。 因此，本提案（版本5）将继续公示，由2024年6月18日公示7日至2024年6月25日。以上！--唔好阻住我爱国（留言） 2024年6月18日 (二) 13:58 (UTC)[回复]

(－)反对：大时代的情况如果不能记录播放日期，怎样带出因那次重播而引生的现象：财政司司长的发言和TVB的广告大赚和颁奖典礼等？这样会令一些重点资讯变成半天吊，规则要再修改。--素菓霖 2024年6月23日 (日) 18:22 (UTC)[回复]
然而重播时发生的股市相关事件跟大时代这个电视剧本身是没关系的，纯粹就是巧合并且相关效应有独立条目压根就没必要在电视剧自身的条目里写。--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月23日 (日) 21:44 (UTC)[回复]
@甜甜圈真好吃：他说的是大时代 (香港电视剧)不是大时代，而且有一点倒是很值得留意的——“这段时间的广告时段比往常的长”，那次重播吸引了很多商家买TVB那个时段的广告，这点又不能说没有关系。--街燈電箱150號 开箱维修 抄表 检验证明 2024年6月24日 (一) 00:42 (UTC)[回复]
目前暂时发现没有发现TVB在重播该剧时广告商购买的广告数量明显增多的相关来源。（所以相关言论属于观众自行观看节目得到的原创总结。）--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月24日 (一) 01:54 (UTC)[回复]
找到有来源：东方日报和独立媒体。--素菓霖 2024年6月24日 (一) 07:56 (UTC)[回复]
“ 重播而引生的现象”，即“回响”段落，而非“ 播放资讯”段落，而目前“回响”段落还没有规定，故只要将重点放在“ 财政司司长的发言和TVB的广告大赚和颁奖典礼等”并记录于“回响”段落即可。--唔好阻住我爱国（留言） 2024年6月24日 (一) 11:51 (UTC)[回复]
正如相关段落放在影响段落，而非“播放资讯”，故看不到有影响。--唔好阻住我爱国（留言） 2024年6月24日 (一) 11:59 (UTC)[回复]
@Kalin8111--唔好阻住我爱国（留言） 2024年6月24日 (一) 12:11 (UTC)[回复]
回看整个对答过程，我问“大时代 (香港电视剧)#2015年翡翠台重播的内容全部都要删除？”，你答“一半准确。事件的重点应放在财政司司长的发言及万千星辉颁奖典礼上，而非节目的播放资讯如播放平台及播放日期”。如果相关段落放在影响段落就没有东西要删除，那连“一半准确”都没有。然而你说“一半准确”，即就算放在影响段落，有部分内容还要删除。而因为“而非节目的播放资讯如播放平台及播放日期”这句话，那么要删除的部分内容就是当中的播放平台及播放日期，而只能留下财政司司长的发言和TVB的广告大赚和颁奖典礼的内容。那么依照你的“一半准确”的回答，就算放在“回响”“影响”段落怎可能没有影响？你的第一次回答和第二次回答自相矛盾。--素菓霖 2024年6月24日 (一) 19:06 (UTC)[回复]
这个仅是重点问题，如该重播没有关注度，理应删除。
但阁下的例子有关注度，继而应放在 “回响”“影响”段落，重点描述其重要事件，而非“播放资讯”段落。如果 财政司司长的发言和TVB的广告大赚和颁奖典礼的内容 放在“播放资讯”段落，这是离题。
至于一半准确论则视乎阁下如何理解，阁下说“是不是全部都要删除”，我会说如果该段落放在“播放资讯”，应删除，因离题。如该段落放在“回响”“影响”段落，仅应删除过份仔细的句子。--唔好阻住我爱国（留言） 2024年6月25日 (二) 00:02 (UTC)[回复]
又发现了其实是没有可靠来源记录该段落所有论点，删除（除广告商大赚外的所有）是正常不过。
P.S. 不怪得要挂模版啦！--唔好阻住我爱国（留言） 2024年6月25日 (二) 00:08 (UTC)[回复]
另外，独媒的那个是blog,而非报导。而东方的没有证据支持论点。--唔好阻住我爱国（留言） 2024年6月24日 (一) 11:53 (UTC)[回复]
由于出现新的反对理据，有关问题需要继续讨论，恕敝人中止公示。--街燈電箱150號 开箱维修 抄表 检验证明 2024年6月24日 (一) 00:42 (UTC)[回复]
出现问题的原因是源于提问者选择来源有误。--唔好阻住我爱国（留言） 2024年6月24日 (一) 11:23 (UTC)[回复]
另外，该提问者已错失提问时机，在其他编辑者回应8日有多才有进一步回应，与现有公示程序条文有冲突。根据WP:共识，问题已获得解决，另无需再回应，因此不影响公示。如有任何问题，请另提出更改WP:共识议案。--唔好阻住我爱国（留言） 2024年6月24日 (一) 11:28 (UTC)[回复]
你的回应前后矛盾，已经不是正当合理回应，问题未解决，公示应当中断。--素菓霖 2024年6月24日 (一) 19:10 (UTC)[回复]
这个来源可以吧[8]--Factrecordor（留言） 2024年6月25日 (二) 16:47 (UTC)[回复]
这个是应放在影响，而不是播放资讯--唔好阻住我爱国（留言） 2024年6月25日 (二) 16:51 (UTC)[回复]
先(－)反对，这个讨论好像完全没有尝试通知经常编辑这类条目的用户前来参与讨论，甚有疑虑。--Factrecordor（留言） 2024年6月25日 (二) 15:34 (UTC)[回复]
无效反对（没有针对提案作出实质意见），此讨论已维持3个月又3日，足够引起社群关注度。而且路西法人的共识议案不包括此方针区。--唔好阻住我爱国（留言） 2024年6月25日 (二) 15:53 (UTC)[回复]
经常编辑的用户不一定会注意方针讨论，不赞成你这样在后面闭门造车，再要求在前面实战的遵从。--Factrecordor（留言） 2024年6月25日 (二) 16:33 (UTC)[回复]
请针对下方所有提案也这样说--唔好阻住我爱国（留言） 2024年6月25日 (二) 16:48 (UTC)[回复]
以往看见很多讨论在某个阶段都召唤活跃编辑者，原则上我认为每个方针讨论都应该这样，但我比较专注自己感兴趣的范畴。其实讨论拖得久，或者像上面那样纠缠在有没有来源，其中一个原因，正是熟悉此话题的人士参与不足。例如你们在讨论大量内容缺乏来源的大时代条目，而我就是曾为此条目添加唯一学术性来源的人。--Factrecordor（留言） 2024年6月25日 (二) 16:58 (UTC)[回复]
“熟悉编辑者”：有啊，大部分熟悉议题的也在公示前已表达意见及润色条文，你可以看到版本5的支持程度。但因为管理员Cdip进行无限拉布行为，导致拉布产生的回应多于完善条文产生的回应。--唔好阻住我爱国（留言） 2024年6月25日 (二) 17:06 (UTC)[回复]
  • 第一眼印象，“不分青红皂白地”在这里绝非合适用词，可用“不经筛选地”一类字眼。
  • 我反对将这些资讯视为没有价值的东西。我的观念是，它们很多时候价值不那么高，若情况是不加以限制，它们的数量就会过于庞大，则唯有作出取舍。中文维基是指以中文写成，并不是只收录和中文地区有关连的内容。如果英维的方针也基于上述精神，大致可以接受。但我觉得英文地区的人因近代的长期主导地位总有点自大，不重视外文外事，往往只视作一种猎奇，反而变得眼光狭隘，相反我们需重视外文外事，更懂海纳百川。文化不同，做法也可不同。
  • 不能写准确的播放时间，但能够写时段，那么时段具体来说是什么？没有数字的“深宵时段”、 “黄金时段”？有数字的“月九”、“十点档”？如来源所写的就是具体时间，那么是否会变成原创研究一个时段名称去描述它？时段与具体时间的字元相差不多，有如此限制的必要？
  • 说起大时代的重播回响，我想起自己曾在亚洲电视外购剧集列表的编辑。虽然亚视末期在黄金时段重播旧节目，沦为笑话，但该台其实曾在1990年代中在黄金时段播放1970年代日剧配音版，并获得正面回响。现实中出现过的情况是千奇百怪的。
  • 我认为条文应明确指出：“当节目的重播曾被二手来源作为主题介绍，可写于回响、影响等合适章节，这情况下可在该段落提及日期与时段。”不必研究这一半和那一半可不可以，这种情况下写多一点点，能有什么不良影响。
  • 关于一般（没有回响记载）的重播情况，我想起无线电视多年前所拍的金庸剧，在其传统的翡翠台的重播次数，二十至四十年来可能平均就只有两三次，就算是平均五六次上下，如果全世都是这种情况的话，我会觉得在内文以一两句散文概述，只提及重播年份，无伤大雅；然而，那些旧金庸剧至今还在中国内地各卫视时有重播，恐怕没有谁有兴趣一一列出来。因此，我猜这种差异形成了有些地方的人热衷记录重播资讯（因为较“珍贵”也并不那么琐碎），有些地方的人不习惯这样做（重播太常见太琐碎了）。研究重播也未必只有电视迷才有兴趣，《文艺生活》2010年第12期《我国电视剧重播现状、存在问题及其对策研究》、《视听》2019年第6期《新媒体语境下经典电视剧重播的价值》、《电视研究》1996年第8期《谈优秀国产电视剧重播的价值》 。
  • 大致看了一遍第5版本，如果没理解错，非中文地区作品在产地以外的非中文地区的播出资讯，是被禁止收录。如上，我倾向如有二手来源支持内容写成回响、影响一类章节，不应受此限制。
  • 记得@JuneAugust君在扩编白色巨塔 (2003年电视剧)选dyk时曾引用重播报道；当时我也加了此剧在台湾因太受欢迎，首播后立即重播之先河。有否意见？
  • 关于串流播放平台的讨论较为复杂，我想仔细再看一遍，想想有没有意见。
--Factrecordor（留言） 2024年6月26日 (三) 12:37 (UTC)[回复]
这个是一个优质论点，请容我连同这个“关于串流播放平台的讨论较为复杂，我想仔细再看一遍，想想有没有意见。”一并回答。--唔好阻住我爱国（留言） 2024年6月26日 (三) 12:52 (UTC)[回复]
首先回答论点2，在我翻译英维前研究所有维基专案，发现只有中文维基百科非常好人地点列世界各地不同媒体的播放资讯。即使是韩维、日维、法维及英维也只专注自己地区的播放资讯，不记录中文地区的播放资讯，即使是他们的节目卖至中文地区，也不记录，而英维也明文禁止这个行为。
但考虑到中文维基很喜欢无限放大中文节目回响，以证明节目对中文社群的重要性，故在翻译时考虑放宽中文节目在非中文地区的播放状况。--唔好阻住我爱国（留言） 2024年6月26日 (三) 13:05 (UTC)[回复]
说到这个日维这边有部分作品的话，是有标注中文地区的播出信息。(例如爆旋陀螺系列、爆丸这种玩具广告类动画。)--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月26日 (三) 13:49 (UTC)[回复]
数量是极少，差不多每一万条就有一条这样操作。--唔好阻住我爱国（留言） 2024年6月26日 (三) 14:04 (UTC)[回复]
美英日是传统的作品输出“大国”，韩国现在也成顶流（韩维规模很小），他们的作品在各地播出，以至被译成各地语文，是习以为常之事，当然不觉得列出来有什么意义，但中文地区作品能在其他语言地区播出，尤其能反过来输出至英美日那些“大国”、尤其被配译为外语，这情况仍时被视为可贵之事，能引起来源特别提及之事，这不是中文维基的风气，而是中文地区的风气。这正是文化差异。--Factrecordor（留言） 2024年6月26日 (三) 13:49 (UTC)[回复]
但是有部分中文维基人把这个习惯带到了其他语言社群的非中文作品中就不大好。(之前就有在日语维基看见过在日本动画条目中写大中华地区播出情况的)@Factrecordor--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月26日 (三) 13:55 (UTC)[回复]
例如某部以新干线为主题的动画。提及的内容如下(这段内容像是中文这边的动画爱好者写的。):

香港 2018年11月22日から2019年8月15日まで无线电视翡翠台にて、‘新干线战士’のタイトルで毎周木曜、金曜の17时20分-17时50分に放送。広东语 & 日本语二ヶ国语放送、繁体字字幕あり。 台湾 2019年3月31日から2020年9月13日まで东森幼幼台にて、‘新干线变形机器人’のタイトルで毎周日曜日、10时30分に放送。 --东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月26日 (三) 14:00 (UTC)[回复]

新干线変形ロボ_シンカリオン#日本国外での放送（第1期）（日语：新幹線変形ロボ_シンカリオン#日本国外での放送（第1期））:看完这个描述，觉得很羞家。--唔好阻住我爱国（留言） 2024年6月26日 (三) 14:09 (UTC)[回复]
也有不丑的时候，如香港首播《大拇指姑娘》，早于日本首播。播映《美少女战士》时原作者武内直子访问无线配音组。--F，actrecordor（留言） 2024年6月26日 (三) 16:56 (UTC)[回复]

版本6(分句公示)

标题：播放资讯

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

维基百科不是电视指南，请勿不经筛选地列出电视节目的所有播放资讯。

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

编辑者在附上可靠来源的情况下，可在条目中记录值得注意的播放资讯，

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

如节目原产地的首播资讯；

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

中国大陆、台湾、香港、澳门、马来西亚、新加坡等中文使用地区的首播资讯；

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

@Underconstruction00:“等中文使用地区”--唔好阻住我爱国（留言） 2024年7月4日 (四) 02:08 (UTC)[回复]
另外，这4个items不是规范重点，因为规范主体是下方的“限制收录”部分，基本上，如马来西亚的播放资料若不是中文（转播），其收录次序将大大降低。
至于指定的6个地区，是中维中文支援地区。基本上，如欲质疑这6个地区的正当性，只能前往元维基反映意见，包括可能新增“英国繁体”、“美国简体”等。
至于“马来西亚”及“新加坡”，这边提及的并不是“官方语言”，而是“通用语言”。--唔好阻住我爱国（留言） 2024年7月4日 (四) 02:17 (UTC)[回复]
原生中文节目在非中文使用地区的首播资讯；

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

或大规模的国际播放资讯。

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

节目的OTT播放平台及网络电视的节目可观看地区均需列明来源，

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

OTT播放平台及网络电视平台播放清单不建议作为证明“可观看地区”的来源，因为相关平台及播放清单通常不会明文记录可观看地区。

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

若相关OTT播放平台及网络电视平台播放清单明文记录可观看地区，则不受此限。

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

如编辑者对于个别OTT播放平台及网络电视平台播放清单是否可以直接引用作为证明“可观看地区”有疑问，可在本指引的讨论页商议，重点为著作权法和非原创研究原则。

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

节目的播放时间应以当地时间12小时制或24小时制为准，如来源使用其他报时制式，请转换至当地时间12小时制或24小时制报时制式。

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:32 (UTC)[回复]

*下列资料即使附上来源也不应被记录：

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

*准确播放时间。（不包括播放日期及播放时段）
**例子：如节目时间表列明节目的播放时间是06:00-06:30，但实际的播放时间是06:03-06:12及06:15-06:27。编辑者应记录播放时间是06:00-06:30。

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

了解，没意见。--Factrecordor（留言） 2024年6月27日 (四) 15:09 (UTC)[回复]
*推迟不足30分钟或并非偶发的延误播放之资讯。

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

想明确：推迟指起播，延长非推迟。a或b的延误播放信息。本次《新闻联播》需要xx分钟，若作案例，算偶发吗，是以前少见现在常见。判断偶发是否偏主观。--YFdyh000（留言） 2024年7月4日 (四) 02:33 (UTC)[回复]
我不相信会有可靠来源记录一节目每集延播的原因。况且，如果是因为上一节目或上一大事而造成的延播，应放在上一节目或上一大事条目记录，因为与本节目无关。
新闻联播自伟大领袖上台至今，已经算是恒常。不过，不知道有哪间媒体敢质疑下一节目因伟大领袖的讲话而导致延播。--唔好阻住我爱国（留言） 2024年7月4日 (四) 02:53 (UTC)[回复]
不需要每集，一集的也能写。不理解，如果电视剧因晚会延播一次，在晚会条目写它导致电视剧播出延迟/取消，恐怕过于不重要。电视报可能叙述，或者按常识？我说的是，新闻联播因某项大事延长，如何算定数还是偶发；下一节目里是否提，我感觉意义小，类似突发的不可抗力。--YFdyh000（留言） 2024年7月4日 (四) 03:25 (UTC)[回复]
按常识即可，因为这些延播通常没有可靠来源记录。即使有，但维基百科可不是电视EPG，恒常记录延播会导致文章比例出现问题，如果条目来源一半是关于延误播放，馀下的是其他部分，显然出现了问题。但若只有少部份的来源是关于延误播放，那问题不大且显得偶发。--唔好阻住我爱国（留言） 2024年7月6日 (六) 11:28 (UTC)[回复]
*电视节目重播资讯。
**在该节目授权区域内的相关播放平台可观看人数较首播平台的可观看人数高一倍或更多的可被本段记录
**如节目的重播曾被第三方独立可靠来源引用重播资料并作主题介绍，请记录相关主题介绍于回响、影响等合适章节。这情况下编辑者可在本章节简单提及重播日期、时段及引起主题介绍的播放平台。

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

不是以中文提供字幕或配音的播放平台。（节目原产地区播放平台或以中文制作的节目除外。）

--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

@Factrecordor:这句是英维中English license 定义，封锁了非英文播放平台。
为确保中维指引与全球对接，避免认知落差（毕竟现时只有中维这样恒常操作）及公平对待每一节目（避免只有中维过份详细地列出锁碎／全部资料）。换句话说，阁下的论点1不能对接世界各地。--唔好阻住我爱国（留言） 2024年6月27日 (四) 16:57 (UTC)[回复]
换言之，如按照英维指引精神，应这样记录
范例：一套美国剧
曾在德国、法国播映：不记录（与中文社群有什么关系？）
曾在德国、法国、义大利、瑞士播映：不记录（与中文社群有什么关系？）
曾在台湾、香港、德国、法国播映：“此剧自2000年起曾在多个地区播映，包括台湾XX频道（2000年），香港XX频道（2002年）等。”
曾在台湾、香港、澳门、中国内地、马来西亚、德国、法国播映：“此剧自2000年起曾在多个地区播映，包括台湾XX频道（2000年），香港XX频道（2002年），澳门XX频道（2002年），中国内地XX频道（2003年），马来西亚XX频道（2004年）等。--唔好阻住我爱国（留言） 2024年6月27日 (四) 17:10 (UTC)[回复]
说一下一些看法：一种语言的维基百科里，看似之于某语言社群没关连的项目实在多的是。例如我以为中维中充斥著本来自英维的内容，与英维中本来自中维的内容，本质是不同的。在中维，很多人是自发性从英/外维翻译成与中文世界没有关连的条目。但依我看来，在英维不少跟英语世界没有关连的条目，则都是懂英文的其他语言维基人前去编写。若不是个维基百科，说不定英语世界的人已经会在大量提删这些条目。以我理解这就是上述所谓的文化不同。--Will629（留言） 2024年6月28日 (五) 12:22 (UTC)[回复]
据我自己的见闻，在中维里如果一个条目全部都是英文来源不会受到“歧视”，但在英维一个条目全部都是中文来源的话，会大受质疑。正如最初所说，我认为在这些方面，中维的态度更正确，我们不必跟他们看齐，更不应出现以眼还眼的想法，是英维应当学习我们。--Factrecordor（留言） 2024年6月28日 (五) 13:42 (UTC)[回复]
Wikipedia:是英文维基说的！和Wikipedia:诚如英文维基所说，虽然只是论述，不是方针，但足见全球对接不是必需的。--Factrecordor（留言） 2024年6月28日 (五) 13:51 (UTC)[回复]
假设有两套没有在中文地区播映过的德国旧电视剧，一套只在德国本土播映过，一套在欧洲很多国家都播映过，如果它们的条目对中文读者是有意义的，我相信对于这些读者来说，两者在欧洲的差别也是有一点意义的，值得中维仅仅多用一两句去记录。--Factrecordor（留言） 2024年6月28日 (五) 14:06 (UTC)[回复]
如果放宽至中文来源记录相关播放资料，可以吗？
因为如果该节目对中文读者是有意义的，应该有中文来源记录，从而知道该节目对中文社群的重要性。--唔好阻住我爱国（留言） 2024年6月28日 (五) 14:17 (UTC)[回复]
如上文所说，中维没有“歧视”全外文来源的风气，中维也对翻译条目乐此不疲，原则上我(－)强烈反对以来源语文作为判断准则，甚至担心这种观念若蔓延，他朝条目主题本身的关注度都要按来源语文来判断。--Factrecordor（留言） 2024年6月29日 (六) 11:10 (UTC)[回复]
留名等看之后会在中维看到非洲、南美洲的播放资料，反正我手上是有这些资料。--唔好阻住我爱国（留言） 2024年6月29日 (六) 11:28 (UTC)[回复]
不过如果之后看到 非洲、南美洲的播放资料，会不会被批评WP:NOTIINFO就令一回事。--唔好阻住我爱国（留言） 2024年6月29日 (六) 11:31 (UTC)[回复]
如上，只要有限制数量的规则，琐碎内容不能无限制大量罗列，不是什么大问题。--Factrecordor（留言） 2024年7月1日 (一) 10:56 (UTC)[回复]
中文字幕配音/其他语言（原产地)—>无要求
其他语言（非原产地)—>请@Factrecordor建议一个可行可量化数字限制收录。（初步我打算extend这句“ 或大规模的国际播放资讯。”）--唔好阻住我爱国（留言） 2024年7月1日 (一) 11:15 (UTC)[回复]
同上，3个，如何？--Factrecordor（留言） 2024年7月3日 (三) 18:25 (UTC)[回复]
  • 中文及原产播放资讯：无限制，可使用播放清单。
  • 如没有中文播放资讯：3个（大至小），但必须曾被第三方可靠来源记录。
    • 跨洲份优先（跨洲份数量越多序列越高），如欧洲跨美洲
    • 以整个洲份为主要“可观看地区”
    • 当地在地化（如该节目曾于当地重新配音、剪接等，不包括添加当地字幕）
    • 于当地单纯转播及添加当地字幕
    • 于当地单纯转播
——
这个可以吗？@Factrecordor--唔好阻住我爱国（留言） 2024年7月4日 (四) 00:57 (UTC)[回复]
没问题。--Factrecordor（留言） 2024年7月4日 (四) 15:45 (UTC)[回复]
我认为最大3个太死板，如果有4个外国地区的播放资讯真的很受关注的，也要强迫删除其中1个？这样似乎又不合理。--素菓霖 2024年7月9日 (二) 09:46 (UTC)[回复]
“ 我认为最大6个太死板，如果有7个外国地区的播放资讯真的很受关注的，也要强迫删除其中1个？”
“ 我认为最大7个太死板，如果有8个外国地区的播放资讯真的很受关注的，也要强迫删除其中1个？”--唔好阻住我爱国（留言） 2024年7月9日 (二) 15:12 (UTC)[回复]
虽然全球只有中维 “没有“歧视”全外文来源的风气”，但如果编辑者认真起来，把全球国家及地区的所有播放资料连来源一并列出，在文章比例上有一定问题，而且显得资料不经筛选，过分详细。如单计首播平台，也有超过100个来源也是关于播放资料，还不计个别重播资料。--唔好阻住我爱国（留言） 2024年6月29日 (六) 12:18 (UTC)[回复]
最主要应concern是假设我写了YouTube TV可以看A节目，但不幸地，Youtube TV的服务地区只有美国，对于常用中文社群地区，应透过什么途径使用Youtube TV收看此节目，相关方法是否符合平台的著作权法？另外，YouTube TV只有英文配音及英文字幕，对于常用中文社群，是否会故意利用YouTube TV收看此节目也成问题，--唔好阻住我爱国（留言） 2024年6月28日 (五) 14:27 (UTC)[回复]

集中讨论！--唔好阻住我爱国（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

我对串流平台的讨论没有意见。--Factrecordor（留言） 2024年6月27日 (四) 15:11 (UTC)[回复]
经过一天，我认为以散文简述及限制数量，比起全禁，更能平衡需求。初步提案如下：
  1. 非中文地区作品在产地以外非中文地区的电视播放资讯，不能列于资讯框，可在内文以散文形式简述。限制如下：数量只限三个（但中文地区不受此限制）；如曾播放国家/地区只有一至三个（包括中文地区），则可以全数提及国家/地区、电视频道与首播年份；如曾播放的国家/地区多于三个，为免陷入何地可以作为例子的争论，列出中文地区之馀，其他地区只能以“自XXXX年起曾在多个地区播映”一类的语句简单概括；如中文地区已有三个或以上，其他地区亦只能以“自XXXX年起曾在多个地区播映”一类的语句简单概括。
    范例：一套美国剧
    • 曾在德国、法国播映：“此剧2000年曾在德国XX频道播映，2002年曾在法国XX频道播映。”
    • 曾在德国、法国、意大利、瑞士播映：“此剧自2000年起曾在多个地区播映。”
    • 曾在台湾、香港、德国、法国播映：“此剧自2000年起曾在多个地区播映，包括台湾XX频道（2000年），香港XX频道（2002年）等。”
    • 曾在台湾、香港、澳门、中国内地、马来西亚、德国、法国播映：“此剧自2000年起曾在多个地区播映，包括台湾XX频道（2000年），香港XX频道（2002年），澳门XX频道（2002年），中国内地XX频道（2003年），马来西亚XX频道（2004年）等。”
  2. 原产地的重播资讯，不能列于资讯框，可在内文以散文形式概述。限制如下：只可收录编者所知（按照来源）的最早一次重播及最近一次重播的具体资讯，包括播放频道及时间。最早一次及最近一次重播年份对了解重播情况有参考作用，但由于未必能确定是否最早及最近，最近的重播也需要更新，建议避免在文中直接使用“最早”“最近”这类字眼。若重播次数超过两次，其他重播可概括为曾于XX频道（若不止一个，可写“多个频道”一类字眼）重播多次（若有来源统计次数，可具体写“X次”）。时间方面，若重播频密程度达一年多次，可精细至重播首天的日期，否则只可提及重播年份。若节目的重播曾被二手来源作为主题介绍，可写于回响、影响等合适章节，则不受上述限制。
    范例：此剧曾在不同频道重播多次，较早期的有1999年在XX频道的重播，较后期的有2018年在XX频道的重播。
  3. 非原产地的重播资讯，一般没必要收录，有二手来源证明具特别回响除外。
--Factrecordor（留言） 2024年6月27日 (四) 15:07 (UTC)[回复]
举例：七十二家房客:到目前为止，此节目逢星期一至五下午3-5在大湾区卫视（包括之前的南方卫视）重播，连续重播了十年有多，按照阁下的理据，应如何记录？--唔好阻住我爱国（留言） 2024年6月27日 (四) 16:38 (UTC)[回复]
对于这种情况，最好当然是找到来源视之为非常见情况，作出特别介绍，最理想的描述就是直接采用你上述的描述（但未必需要仔细至时段），连具体年份也变得不重要。若来源未能支持写得那么仔细，也可简述为“此剧经常重播”。但若对引用来源及非原创持绝对严格的态度，但手上实际又只有电视节目表的话，那么我建议写：“此剧在XXXX年已有重播（如有旧节目表证明，如没有则可不写这句），2020年代仍有重播。”我主张的理念是一旦情况复杂，数量过多，就尽量简略概括，而不要因噎废食，因有些条目情况复杂，就要那些简短的也一起陪葬。--Factrecordor（留言） 2024年6月28日 (五) 14:11 (UTC)[回复]
但是如果是换到另外的频道首播(实质仍是该公司范围内的频道重播)类似于翡翠台的橘色荣耀！(该节目是重播同公司另外一个电视频道的电视节目)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月9日 (二) 12:06 (UTC)[回复]
可观看人数一致（740万人可以收看），媒介一致（免费电视），配音也不是在翡翠台优先发放（J2有粤配先），故应放弃翡翠台资料。--唔好阻住我爱国（留言） 2024年7月9日 (二) 15:22 (UTC)[回复]
但除非能证明TVB Anywhere版本的翡翠台有播橘色荣耀（观众群由香港变成全球），这个就可以记录（J2没有TVB Anywhere版本）--唔好阻住我爱国（留言） 2024年7月9日 (二) 15:25 (UTC)[回复]
该节目只在香港地区有版权，所以海外不会播出。--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月11日 (四) 06:49 (UTC)[回复]
@Pyruvate、Stevencocoboy、CyrussKK1230、Ckh3111、Apple v、Tw drama、Nickice、Yau Sze Long、Bosco64、Will629、Ricky36、SeoTae、Redmi123465、Benkwokmars、Tanqrsucks、任晏延、紅軍28、Hkmjai、WiKilover022、Underconstruction00、Achanhk：各位，这是关于电视剧条目格式的指引修订，旨在对一些琐碎的播放资讯进行限制，主要着眼于重播资讯、非中文地区播放资讯、OTT播放平台及网络电视平台播放资讯，请看看有没有意见？
--Factrecordor（留言） 2024年6月27日 (四) 15:35 (UTC)[回复]
没有意见，Factrecordor大的补充条目我觉得可以写进去。 --窝法乙烷 儿法梦碎 2024年6月27日 (四) 16:12 (UTC)[回复]
没有意见--WiKilover022（留言） 2024年6月29日 (六) 04:46 (UTC)[回复]
@Cdip150@Kalin8111请问两位对后续讨论有没有意见？--Factrecordor（留言） 2024年6月29日 (六) 11:24 (UTC)[回复]
中文好像不是马来西亚的官方语文，如何定义它属于中文地区？近数十年加拿大是华人热门移民地点，我也可以说那里的华文华语市场不容忽视。参考汉语国家和地区列表 ？--Underconstruction00（留言） 2024年7月4日 (四) 01:25 (UTC)[回复]

提议统一整合维基百科:命名常规 (电子游戏)及维基百科:命名常规 (日本动漫游戏条目)

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:命名常规 (电子游戏)、Wikipedia talk:命名常规 (日本动漫游戏条目)。

议程1:通用译名定义更新及移除日本游戏、新增日本小说议案获得通过！--唔好阻住我爱国（留言） 2024年6月25日 (二) 00:26 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

为避免混淆讨论重点，于是设置了懒人包 ！

是次讨论重点如下：

  • “日本动漫游戏条目手册”废除规管日本游戏类别，新增规管所有电视及电影类别条目。
  • 日本游戏纳入“电子游戏手册”规管。日本游戏命名方式由“命名先后次序”原则改为沿用一般游戏的“通用的中文名称命名”原则。
  • 建议新增夸媒介条目优先命名办法。如小说、漫画、动画、电子游戏、电视节目、电影、简体中文、繁体中文、官方名称、正式名称、通用名称等。

.--唔好阻住我爱国（留言） 2024年5月26日 (日) 15:10 (UTC)[回复]

讨论内容如下：

维基百科:命名常规 (日本动漫游戏条目)主张：(命名先后次序)

1.官方译名、正式译名和通用译名相同。

2.正式译名和常用译名相同，无官方译名或官方译名与其他译名不相同。

3.只有通用译名，或通用译名和官方译名、正式译名不相同。此情况常见于先在网络流行一段时间的作品，导致字幕组等非正式译名较官方和正式译名通用。此外也有其他原因导致官方和正式译名不通用。在这个情况下，可按命名常规的使用事物的常用名称规则使用通用译名为条目名称。

4.只有官方译名和正式译名。

5.只有正式译名。

6.官方译名、正式译名和通用译名均不存在时，应考虑在出现前述其中一种译名后把条目移动至该名称。

维基百科:命名常规 (电子游戏)主张：

1.使用最为通用的中文名称命名。对于外文游戏通常即是由发行商或代理商确定的官方译名，但如果代理商影响力较弱，导致其官方译名通行程度远低于通用译名（多见于中国大陆），应选用通用译名命名（例如中国大陆译名马里奥系列）。

2.中文译名的选用标准仅包括是否官方、通用程度等客观条件，译名翻译是否正确、是否信达雅等主观因素不在此列。

3.鉴于华语各地区游戏译名往往不同，条目命名地域归属由编写者“先到先得”，并通过地区词转换解决译名差异问题。

4.地区名称选取标准（包括是否使用中文译名、使用何种中文译名）仅以该地区情况为参考根据，各地名称均独立平等对待，互不影响，不得以任何理由将某地区名称条目移动至另一地区译名。

5.原生中文游戏因各地代理而名称不同（多见于网络游戏）不视为译名差异，条目应以开发公司最初定名为准，名称不设转换。

6.台湾、港澳地区命名使用繁体中文，中国大陆、新马地区使用简体中文。除技术限制外，条目命名应与转换后名称之一相符。

7.请为同一游戏各地不同的译名（例如“超级马里奥兄弟”和“超级玛利欧兄弟”）以及其他代称（例如“超级玛丽”）加入重新导向以引导至正确的页面。对于名称相似的不同游戏，应在条目内加入顶注。

问题就来了：

1.两者命名准则不一，而且也共同管理日本游戏条目，如果编辑者想建立日本游戏条目，应优先使用哪一个常规？

2.在电视类别方面，目前只有日本动漫设有条目命名常规，剧集、综艺方面却没有特定命名常规，期望各位编辑者探讨是否有空间更改两个命名常规管理范围。

以下是提案，如果各位编辑者支持此概念，才提出重写方案。

  • “日本动漫游戏条目”延伸至管理所有电视电影节目，并删除与游戏相关规条，可改名至“电视电影条目”；
  • “电子游戏”名称及大部分内容维持不变，并与日本游戏规条整合一起。
  • 当两者有冲突时，以该项目首个发表媒介的官方／正式中文名称为优先。
    • 如小说漫画的官方／正式中文名称是最先出现，则以小说漫画为首。
    • 如电视电影的官方／正式中文名称最先出现，则以电视电影为首。
    • 如电子游戏的官方／正式中文名称是最先出现，则以电子游戏为首。
    • 如繁体中文名称是最先发布，则以繁体中文为首，其后使用字元转换工具新增简体中文名称。
    • 如简体中文名称是最先发布，则以简体中文为首，其后使用字元转换工具新增繁体中文名称。
    • 如官方名称不是中文，正式名称是中文，优先使用正式名称。（中文优先）
    • 如该项目没有中文名称，则以维基百科:命名常规 一般规则处理。

以上。--唔好阻住我爱国（留言） 2024年5月26日 (日) 10:46 (UTC)[回复]

注：此提案是基于Kizuna no Allele发现的bug，有中文名称却使用全英文字，有“妹大过主人婆”之嫌；而且Google TV首页节目推介严重依赖维基百科译名，电视语言设置为中文而电视IP在非中文地区的话，首页的当地节目播放清单会改为显示中文维基百科名字，非当地语言。故产生整合命名常规想法。--唔好阻住我爱国（留言） 2024年5月26日 (日) 11:18 (UTC)[回复]
那对于有一些周边产品的作品(例如特摄作品及部分推销周边玩具的动画作品。)那周边产品先出名称的话那应该是周边产品为准还是以作品本身为准？(两岸三地通常是周边产品先于作品本身推出)--LTA:LC99反对昌明政府的居心何在？。--老墨泡芙真好吃。 2024年5月26日 (日) 11:37 (UTC)[回复]
“最先出现”原则。（依从维基百科:命名常规:先到先得）--唔好阻住我爱国（留言） 2024年5月26日 (日) 11:55 (UTC)[回复]
当然是针对主题本身来命名啊，周边展品只能算条目中的一个小节（制作/宣传章节）……--For Each element In group Next（留言） 2024年5月26日 (日) 12:56 (UTC)[回复]
但是很多周边产品的名称会影响作品本身的名称。--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--林吉祥 。 2024年5月27日 (一) 07:45 (UTC)[回复]
所以说，条目命名以主题本身为准啊。就算周边产品影响了，那条目还是依照作品本身来命名。只不过官方命名的缘由可能是“保持IP命名一致性”之类，这点如果需要介绍，可以在制作等章节说明。（其他条目也有谈到官方命名的理由；只不过你说的这种情况太平凡，很少有来源介绍，所以没什么好写的）无论如何，命名的根本原则还是针对主题自身。--For Each element In group Next（留言） 2024年5月27日 (一) 14:19 (UTC)[回复]

意见：

  1. 提案时请在对应的页面留言，指出该页面正在被讨论，并告知相关专题。真正关注该领域命名的编者，未必有闲心天天盯着互煮客栈。
  2. 命名以最细的方针为准。游戏条目（或以游戏为原作的系列条目），当然优先依照游戏命名常规（游戏#6）；如果是动漫条目（或以动漫为原作的系列条目），则不套用游戏命名常规。我想这个应该都能理解，我也确实没在这方面见过有什么冲突。
  3. “如X体中文名称是最先发布，则以X体中文为首，其后使用字元转换工具新增Y体中文名称”可以说是完全推翻了现行的命名常规精神：
    游戏领域各地区用字平权。如果条目以A地区用字创建，则实体标题只在A地区的名称（包括官方名称和常用非官方名称）中考虑；亦即不得以B地区的官方名称为由，将A地的常用非官方名称移动到B地官方名称（中文命名规范#4）。这是游戏命名常规基石之一，当初也将许多地区词移动战消灭在了萌芽之中，要改这点就等于彻底重建游戏条目命名体系了。实体标题是内部维护作用（zh对外是隐藏的），给读者看的还是最终的各地转换标题。包括先到先得也好，命名常规的作用就是解决争议（特别是地区词争议）；现在的方针实行有十年，我认为也确实解决了地区词编辑战的问题。
    “日本动漫游戏条目”也有说“由于中国大陆地区代理作品机会较小，因此通常只需要确认译名为最常用译名（即第三项），而此译名正常来说也是中国大陆地区顺位最高的译名（除非有更适合的译名）。如条目适用的名称符合上述译名优先顺序的使用规范（即该地区最适合的译名），其他地区的译名差异应以手动字词转换技术解决（即“先到先得”原则）”。不过仔细来说游戏命名常规和日本动漫游戏条目表述有点不同：如果编者以A地用字来命名，结果选了个既不官方也不常用的“错误”标题，按“日本动漫游戏条目”要求，似乎不反对其他编者移动到B地的正确标题；但游戏命名常规就明确规定，只能在A地的命名中重选一个😂
  4. ACG命名常规创立的一个前提是处理繁杂的命名冲突——此类作品在各地译名往往不同，且即使在一个地区内，也会因为代理商的不同，有多个正式或民间的命名。游戏条目主要是继承了各地用词互不干涉这块，而且依照游戏领域实际情况，也没有搞“官方名称”“正式名称”那么细。电视节目可能没有太多可比性？

--For Each element In group Next（留言） 2024年5月26日 (日) 12:11 (UTC)[回复]

1. 目前没有电视电影命名常规，如要通知的话应该是放在电视电影命名常规，而非日本动漫命名常规，因为日本动漫原则是不受影响。
2. 日本动漫、游戏条目也不受影响，真正受影响仅限日本游戏及电视电影条目。
3. 近年，日本动漫已有真人化趋势（如高木同学、僵尸100等），如不与时更新手册的话，迟早出事。
4. 既然ACG有手册规管，而当中“A”的父系“电视节目”却没有规管，这未免怪怪的。--唔好阻住我爱国（留言） 2024年5月26日 (日) 13:07 (UTC)[回复]
简单来说，电子游戏范围以内可管理的继续沿用电子游戏规条，不过只是新增日本游戏类别，此类别由“命名先后次序”原则改为沿用一般游戏的“通用的中文名称命名”原则。--唔好阻住我爱国（留言） 2024年5月26日 (日) 13:13 (UTC)[回复]
电子游戏的方针指引本来就规范所有的电子游戏条目，包括日本的和非日本的。而现在维基百科:命名常规 (日本动漫游戏条目)其实更像“日本动漫游戏作品的地区词与译名处理原则”，本身没有太具体的规则（例如OVA作品条目该用“OVA”还是“动画”消歧义）？您的提案如果只是要扩大到其他领域那倒也无妨，但是您的提案相当与写了一个和原方针几乎完全抵触的内容：原来的提案是“如果条目以一地的常用名称创建，则其他编者不得移动到另一地的官方名称”，而您的提案是“原标题已然合适的情况下，其他编者依然可以移动到另一地的官方名称”。电子游戏条目是继承了现行原则的，您把原则内容都改掉了，那游戏领域命名的命名常规又是依赖着什么呢？
您是赞同维基百科:命名常规 (日本动漫游戏条目)的理念，希望将这个原则扩大到其他作品领域；还是反对维基百科:命名常规 (日本动漫游戏条目)的理念，希望重写一个来取代；再还是您只是想让影视领域也有一个命名方针，而没理解维基百科:命名常规 (日本动漫游戏条目)的理念和背景？您主张扩大适用范围，但重写方案又是一个完全相反的内容。我没有理解您想表达什么。---For Each element In group Next（留言） 2024年5月26日 (日) 13:39 (UTC)[回复]
1.“只是要扩大到其他领域”：这个是理解正确的， 提案首句写道“日本动漫游戏条目”延伸至管理所有电视电影节目，并删除与游戏相关规条。
2. 现时两本手册没有注明哪个媒介优先命名，有条目以游戏命名，有条目以小说命名，也有条目以动画命名，于是提议新增优先次序，方便之后处理命名争议。--唔好阻住我爱国（留言） 2024年5月26日 (日) 13:59 (UTC)[回复]
那麻烦您先在相关方针的讨论页留下通知，并告知所有受到影响的专题吧。（包括您认为受到规制和取消规制的）--For Each element In group Next（留言） 2024年5月26日 (日) 14:08 (UTC)[回复]
通知了ACG Project, 和两个受影响手册。--唔好阻住我爱国（留言） 2024年5月26日 (日) 14:51 (UTC)[回复]
3. “原标题已然合适的情况下，其他编者依然可以移动到另一地的官方名称”，这个想法是一半正确一半不正确的，这是依从“名从主人”方针，“如果一个条目所述的主体——人、物或可谓有“拥有者”之事，其拥有者或代表者的官方中文资料出现此主体的中文名称，可优先考虑使用该中文名称。”。
  • 但为避免产生大量落差及分别，游戏条目／游戏分段内继续沿用游戏手册。
  • 新提案仅要求如该项目同时有电视及游戏／电影及游戏才适用于建议命名方法。这个命名方法目前是在中维是“不成文共识”，不过仅是“小说及动画”类别。
--唔好阻住我爱国（留言） 2024年5月26日 (日) 14:16 (UTC)[回复]
我们俩都是完全正确的 您强调的是命名总则针对一般条目的要求，而我表述的是ACG领域针对自己的实际情况制定的细节。有细节规则时，就按细节的规则来走（所以游戏命名常规和ACG命名常规也不冲突）。
至于跨媒体的问题，我认为首先应该明确条目主题是什么，也就是把定义句写好。如果您是在介绍小说条目，那样条目第一句就会是“《XXX》是20XX年发行的小说”，我们自然也就根据小说来命名（可能有先行热身的动画，但那不是条目的主题，只能放在宣发章节里）。--For Each element In group Next（留言） 2024年5月26日 (日) 14:35 (UTC)[回复]
目前有不少日本小说没有中文化，但有中文地区动画代理商引入其小说改编的动画，在这个情况下，现行中维做法是该条目标题以动画为准。新提案是同时将这个做法成文化。--唔好阻住我爱国（留言） 2024年5月26日 (日) 15:04 (UTC)[回复]
条目主题是小说，那条目当然应该把小说当成独立的主题，走一遍命名常规。如果来源普遍接受动画的名称来称呼小说，那小说自然会以该动画的名称来命名；如果小说的“常用名称”与动画的官方名称不同，那当然应该以小说的常用名称命名。官方名称就不是最高顺位，更何况条目的主题是小说而不是动画，所以这个“官方名称”和条目主题没有直接的联系，因此这个做法从逻辑上讲就没法“成文”。游戏命名常规在这方面有明确表述：“其他媒体作品译名仅当游戏无中文译名时作为参考”（游戏#5，粗体为本人所加）。这种方式在肯定了现在做法的同时，逻辑上也很自洽。--For Each element In group Next（留言） 2024年5月27日 (一) 13:53 (UTC)[回复]
范围以内可继续沿用子手册，唯夸范围时应优先考虑使用父手册（NC:名从主人）。
很明显20年前的编辑者在达成共识时没有考虑过这个问题--唔好阻住我爱国（留言） 2024年5月27日 (一) 14:15 (UTC)[回复]
本身我没有兴趣大改这三个命名常规，在看到阁下的言论后，才发觉这三个命名常规有这么多的问题。
1. 名从主人论：父常规提出的“名从主人”指引原来是不适用于子常规（动漫及游戏命名常规）
2. 主宾关系：编辑者要在创建条目之先就要决定哪个媒介是主，哪个媒介是宾。订立条目名称时，如该条目主体是小说，就必须使用小说的译名，即使小说没有官方/正式译名也应原创一个出来，如改编漫画有官方/正式译名，也应继续使用小说的原创译名，因条目主体是小说。—>除非定立完整的ACG/文学创作格式手册，媒介主宾关系不是命名常规能处理的，既然阁下有这么多的想法，靠您由0开始撰写，毕竟子系列的电视电影格式手册还未完成。
3. 不成文共识：实际上目前99%新建条目也采用我提及的方法定名，包括上方提及的绊之Allele，如需将这个“不成文共识”砍掉，恐怕需要花极大量时间重新审视近20年以内的建立的ACG条目有否满足要求。
近期，中国短影音兴起，中国人会在短影音分享ACG剧情，但往往也原创一个新译名而不采用当地代理商的译名，每集观看次数以十万起跳。
  • 按照ACG的6个次序的次序1，由于通用译名不一，故不适用
  • 按照ACG的6个次序的次序2，由于常用译名与正式译名不一，故不适用。
  • 按照ACG的6个次序的次序3，条目最后会采用非常具“热度”的原创译名，到最后公众就会质问这个条目是形容什么的作品，为什么我在正版平台找不到与条目相同名称的作品？
--唔好阻住我爱国（留言） 2024年5月27日 (一) 14:55 (UTC)[回复]
方针指引是用来解决问题的，主手册是，子手册也是。主手册能解决问题就主手册就够，但主手册覆盖面太宽，未必能针对具体问题提出解决方案；如果有更好的解决方法，自然可以单独提出子手册。
即使是主手册，“名从主人”作为“命名惯例”，比命名常规的“常用名称”也低一档。子常规也是常用优于官方。我只看到子常规是遵循主常规原则的。
“条目主体是小说”意味着我们要以小说为主体，套用命名常规原则来命名。小说没有中文译名的情况下：如果命名常规规定用原文那就用原文；如果命名常规规定可以参考系列其他作品，那就参考其他作品；如果命名常规允许生造一个，那就生造一个。但这不意味着，应该让一个主题的名称直接指向另一个主题的名称上。
不成文共识又没有写到纸面上，请问怎么砍，砍哪句话？另外我的表述是“其他媒体作品译名仅当该作品无中文译名时作为参考”和您表述的“最先出现”原则在很多情况下结果是一样的，我没明白这只是表述上的差异，还是逻辑上有根本不同。
我不熟悉其他领域作品的译名情况。比如同为电视节目，我不熟悉“意大利电视新闻”和“日本电视动画”的各地译名情况是否一样；同为文字作品，我不知道日本轻小说和《舞会之后》是否有区域间的，区域内官方和非官方的译名分歧。我已经解释了ACG领域的命名原则（和主手册处理上所区别）。我赞同下方Ericliu1912的说法，您先分析一下“电视电影”领域的命名问题，看ACG命名常规是否适用于其他影视节目。如果比照ACG命名常规来操作，是否能解决当前的争议？是否会劳心又劳力（比如涉及地区词方面的移动，结果引来很多争议）。
PS：ACG命名常规有两个原则。一是常用优于官方；以前主手册在字面上，常用和官方平起平坐，所以这个原则很有特色；但现在主手册已经明确了两者顺位，所以这项就没什么特别的了。二是ACG命名手册肯定了各地最优名称平等，例如A地的常用名称（没有官方）和B地的常用兼官方名称是平级的，不得以B地官方为由进行地区词移动。从这个角度看，游戏命名常规是继承ACG命名常规的，依从游戏命名常规就是依从ACG命名常规，没有什么冲突。--For Each element In group Next（留言） 2024年5月27日 (一) 15:35 (UTC)[回复]
在完成“电影电视”前，优先解决ACG问题先。除非新常规完全不采用ACG方案及新常规成文化后即删除ACG常规。
台湾及香港正式动画名称：她来自烦星 (2022年动画)
中文显示：福星小子_(2022年动画)
香港区显示：山T女福星 (2022年动画)
按照目前常规，试评论一下这个标题有什么问题。--唔好阻住我爱国（留言） 2024年5月27日 (一) 16:09 (UTC)[回复]
““条目主体是小说”意味著我们要以小说为主体，套用命名常规原则来命名。小说没有中文译名的情况下：如果命名常规规定用原文那就用原文；如果命名常规规定可以参考系列其他作品，那就参考其他作品；如果命名常规允许生造一个，那就生造一个。但这不意味著，应该让一个主题的名称直接指向另一个主题的名称上。”
这个论点目前命名常规没有要求，可在此一并解决。--唔好阻住我爱国（留言） 2024年5月27日 (一) 16:17 (UTC)[回复]
这个作品我不熟，我不知道信息框填写的内容是否正确。但如果信息框的内容无误，且官方译名“她来自烦星”不常用，那香港和台湾显示标题符合命名常规，没什么问题。--For Each element In group Next（留言） 2024年5月27日 (一) 16:38 (UTC)[回复]
只是稍微修正下（以免其他人误会），所谓“她来自烦星”严格来说只不过是代理商羚邦集团的正式译名，而非真正的官方译名。所谓正式译名其实是指代理商译名，不能完全代表作品官方之命名，并如前所说即使在一个地区内，也会因为代理商的不同，有多个正式或民间的命名。而真正的官方译名是像类似“哆啦A梦”（多啦A梦）这种由原作者、其他持有原作品版权的公司、组织或其法定分支机构所订定及公布的中文译名。--Wengier（留言） 2024年5月27日 (一) 16:53 (UTC)[回复]
问题是，如要严格按照ACG命名规则，官方译名的序号是“4”，通用译名的序号是“3”，这个已是一个结构性问题问题，危及近10年来条目的命名习惯，必要时可能要每一个条目重新审视。--唔好阻住我爱国（留言） 2024年5月27日 (一) 17:02 (UTC)[回复]
我觉得，有一定流通度的官方译名（原作者译名）应高于其它通用译名。就以哆啦A梦为例，“哆啦A梦”（多啦A梦）是官方译名，但在中国大陆、台湾等地亦常使用类似“机器猫”、“小叮当”这样的非官方译名（出现于官方译名之前），但条目仍遵循“名从主人”原则以官方译名命名。即使不是ACG直接相关内容，其它条目如华特迪士尼公司也是以遵循“名从主人”的原则以官方译名“迪士尼”来命名，而不是用诸如“迪斯尼”之类非官方的其它常用译名命名。--Wengier（留言） 2024年5月27日 (一) 17:18 (UTC)[回复]
您说的对。常用+官方（正式）译名当然优于单纯的常用译名或单纯的官方（正式）译名。但这个“一定”实操上该怎么判断，我觉得社区条文和判例都不足够。例如这个讨论，“官方译名”大概是“常用译名”的一半，两者搜索结果都是十万数量级以上，这算不算有足够流通度？最近我也提出过这个问题，“官方”这个标签到底能加多少分？这还是得社群这个层面有个说法，具体领域才好执行。--For Each element In group Next（留言） 2024年5月27日 (一) 17:37 (UTC)[回复]
以2006年标准，当年网路不发达，不是每一个人也可以使用互联网，更何况是一般个人在网上写文章？
今年是2024年，互联网已普及化，网路撰稿员职业随之诞生，在网络上开帖发文已经很简单，什至可以叫ChatGPT写文。对此，有必要重新调整命名准则。
——-
优先考虑：弃用ACG命名规则，因为已经不合时宜。--唔好阻住我爱国（留言） 2024年5月27日 (一) 17:54 (UTC)[回复]
讨论方向：
1.定义条目主体宾体先(究竟条目标题应以小说/漫画/电视电影为首)
2. 命名先后次序原则：
2.1 需要一个可量度的通用译名准则（以搜寻器结果计算，还是讨论区讨论热度）
2.2 时限性问题（参考山T）
2.3 名从主人常规是否更合宜或不合宜？
2.4 官方／正式／通用译名使用先后次序
3. 是否同时处理角色命名问题？
4. 所有译名是否需要附上来源，有没有来源要求？
5. 小说没有中文译名的情况下：如果命名常规规定用原文那就用原文；如果命名常规规定可以参考系列其他作品，那就参考其他作品；如果命名常规允许生造一个，那就生造一个。
6. 中文优先常规是否更合宜或不合宜？--唔好阻住我爱国（留言） 2024年5月27日 (一) 18:07 (UTC)[回复]
命名总则指出原则（常用名称）高于惯例（名从主人）。这两条规则原来是一个等级，正是2018年修正案提出划分层次的，这等于说社群正是最近肯定了ACGNAME的思路……
ACGNAME和NCVG使用官方名称的背书条款是NC:名从主人，但社群这个名从主人规则的也是个口袋规定：“……官方中文资料出现此主体的中文名称，可优先考虑使用该中文名称”。那到底什么情况可以优先，什么情况下优先也没用？社群对此是否有初步概念？可否举出一些临界案例判定情况？至此，我成功地把锅甩给社群，并且把想法传达给po主了；再说下去就是车轱轳话了，我先撤了，各位继续--For Each element In group Next（留言） 2024年5月27日 (一) 18:10 (UTC)[回复]
同意以上说法，一个重点就在于“官方”这个标签到底能加多少分。当然，要拿出很具体的量化标准也未必那么容易，不太可能绝对化。但暂且在这里抛砖引玉吧，比方说如果是“正式译名”（代理商译名），那么搜索结果或许可以乘以1.5倍(左右)进行比较，而如果是“官方译名”（原作者译名），那么搜索结果可以乘以2至3倍进行比较。类似这样的算法和优先原则（当然可能还会有其它考量）。--Wengier（留言） 2024年5月27日 (一) 18:46 (UTC)[回复]
我们好像忽视了“可靠来源译名”…--唔好阻住我爱国（留言） 2024年5月28日 (二) 01:23 (UTC)[回复]
或许可以这样：如果某译名是官方译名或正式译名，应该有可靠来源予以支持或证实。如果是非官方非正式的常用译名，至少要有一个可靠来源支持（证实）该译名的存在。然后再按之前所说的进行量化比较。而如果某作品没有任何可通过可靠来源予以支持或证实的官方译名/正式译名/常用译名，那么只能尽量采用已被使用的译名（即使只有非可靠来源使用该译名）。--Wengier（留言） 2024年5月28日 (二) 02:02 (UTC)[回复]
(＋)支持:现就此方向写“虚构”常规。--唔好阻住我爱国（留言） 2024年5月28日 (二) 14:41 (UTC)[回复]
次序：
1. 官方译名/正式译名/通用译名/可靠来源译名均一致
2. 正式译名和大部分可靠来源的译名相同，无官方译名或官方译名与其他译名不相同。
3.大部分可靠来源的译名（量化准则待定）
4. 官方译名（中文）
5. 正式译名 （中文）
6. 官方译名（其他语言）
7. 正式译名 （其他语言）
8. 通用译名 （字幕组等非可靠来源使用的译名 ）--唔好阻住我爱国（留言） 2024年5月28日 (二) 14:51 (UTC)[回复]
如果该片商/代理商宣传到位的话，去到3就可以停了。所有日本动漫于台湾地区到3便完了，因为台湾动漫平台巴哈姆特获社群评为可靠来源。--唔好阻住我爱国（留言） 2024年5月28日 (二) 15:06 (UTC)[回复]
一般而言可以落到4或之后只有以下场境
1. 于中文地区没有关注度可言
2. 可靠来源之间对使用哪个译名的分歧很大--唔好阻住我爱国（留言） 2024年5月28日 (二) 15:11 (UTC)[回复]
上面所说的“2. 正式译名和大部分可靠来源的译名相同，无官方译名或官方译名与其他译名不相同”，这个显然也需要量化标准，特别是有官方译名但与其他译名不相同的情况下。官方译名显然有一定的优先度，至于具体量化标准，可参考之前所说的其搜索结果可以乘以某个因数（比如2至3倍）进行比较。--Wengier（留言） 2024年5月28日 (二) 15:33 (UTC)[回复]
用“比例”是否更合适？回应“ 2. 可靠来源之间对使用哪个译名的分歧很大”，如果是一半可靠来源用A译名，一半可靠来源用B译名，只会造成移动争议，与其有这样争议，为何不跳到下一项？又例如，如果该译名于各可靠来源至少占7成或更多，是否算有够流足够流通性？--唔好阻住我爱国（留言） 2024年5月28日 (二) 15:46 (UTC)[回复]
用“比例”或“比重”来形容当然也不错，像官方译名与正式译名之间的比重差不多可以是二比一。举例说明，假设官方译名和正式译名同时存在，但一半可靠来源用官方译名，一半可靠来源用正式译名，那么肯定是使用官方译名。但假如说75%可靠来源用正式译名，25%可靠来源用官方译名，那么应使用正式译名。--Wengier（留言） 2024年5月28日 (二) 15:58 (UTC)[回复]
主体：
A:如 条目主要论述 <小说>, 条目标题就以<小说>走上述程序。
B:如条目主要论述 B年份的作品, 条目标题就以B年份为中心走上述程序。
值得注意的是A及B的条目名称可以不一致。--唔好阻住我爱国（留言） 2024年5月28日 (二) 14:58 (UTC)[回复]
背景：
上一个使用“山T女福星”已是英属香港时期，目前此条目的“主”是2022年改编动画，而非20世纪的原作。
你试一下搜寻“山T女福星”，应该是没有结果或结果不是指向2022年动画。--唔好阻住我爱国（留言） 2024年5月27日 (一) 16:57 (UTC)[回复]

如果小说的常用名称是另一个与动画不同的名称，那自然以这个常用（但不官方）的名称为准。相关媒体命名仅供参考，但不能作为直接命名依据。我认为这种表述逻辑上更自洽。--For Each element In group Next（留言） 2024年5月27日 (一) 13:53 (UTC) 另外有中文名称却使用英文字的问题，我在这里谈过，本质上还是社群命名常规总则对“常用名称”和“使用中文”的优先度解释不清。比如ACG方针指出“维基条目通常应以中文命名”，游戏命名方针也规定“外文名称比中文更为通用时方可使用外文命名条目”；这两个原则都是依赖命名常规总则的，但现在社群在命名常规执行上就是一锅粥，说实话这不是两个领域方针应该解决的问题。--For Each element In group Next（留言） 2024年5月26日 (日) 12:29 (UTC)[回复]

我不认为有关电视及电影专题之变更应该动到此命名常规，请更新在别的地方。大可立一个新的“命名常规 (电视电影)”，顺便整合其他既有惯例。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月26日 (日) 21:08 (UTC)[回复]
  • 既然ACG的“命名先后次序”行之有效，为何不延伸至电视及电影？
  • 提案同时是建议改名，脱离ACG专题，改为依从父系“电视电影”类别。
  • 有需要时可启动维基百科:命名常规 (书籍)计划，将当中的“C”纳入，但命名准则参考“A”还是“G”待社群商议。
.
  • “A”：简单来说，可以理解成提案是建议废除“日本动漫游戏条目命名常规”，本身“日本动漫游戏条目命名常规”99.9%内容可以移植至提议的“电视电影命名常规”
  • “C”：维基百科:命名常规 (书籍)计划可以启动，但依从“A”还是“G”仍可商议。
  • “G”：原先“日本游戏”只是更改了依从办法，减低编辑者对选择依从哪个常规的疑问。
  • 至于“整合其他既有惯例。”，即夸媒介命名，可能要重写维基百科:命名常规#动漫和电子游戏作品段落。
--唔好阻住我爱国（留言） 2024年5月27日 (一) 05:54 (UTC)[回复]
关于您最上方的总结，我就说一点吧。您列出维基百科:命名常规 (日本动漫游戏条目)的6项看着长，但一言以蔽之就是“常用优于官方”。而这正是Wikipedia:命名常规_(电子游戏)#中文命名规范的第1项的两句话。遵守WP:ACGNAME就是遵守WP:NCVG第一条，反之亦然。在日本游戏命名方式由“命名先后次序”原则改为沿用一般游戏的“通用的中文名称命名”原则中，您这个“改”字用得很不恰当--For Each element In group Next（留言） 2024年5月27日 (一) 16:46 (UTC)[回复]

关于影视条目，已有命名常规草案，请另外提案修改。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月28日 (二) 05:50 (UTC)[回复]

不用“影视”，用“虚构”，因为上方编辑者提出主宾问题。--唔好阻住我爱国（留言） 2024年5月28日 (二) 14:39 (UTC)[回复]
如果针对Kizuna no Allele的话，这个原作是电视动画，属于ACG组，优先使用ACG的命名常规；ACG命名常规对于使用非中文名作为命名有一个例外：“容许非中文命名的例外情况：如正式译名使用或包含原名英文，条目名称可根据命名常规的原文常用规则沿用原名。”并且举例了，请自行参照。ACG命名常规的制定似乎被电子游戏更早，可能早期是有包括电子游戏的适用，但既然有针对电子游戏专类的适配，如果条目主体概念是纯电子游戏类的，可以优先适用电子游戏的命名规则；如果主体概念是跨媒体模式（同时介绍原作及改编媒体），可以按照原作媒体优先来处理。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 00:54 (UTC)[回复]
针对两个问题：1.对于日本电子游戏的话，电子游戏的范围小于ACG（ACG专题也是统管电子游戏专题），所以优先按电子游戏专题；2.类似的日本电视动画剧集的范围小于通常性电视剧集（通常性电视剧集可以包括不同地区的不同类型电视剧集，包括真人类等），所以优先按ACG专题（更何况剧集类命名规则没成事）。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 00:59 (UTC)[回复]
对于对于现有的ACG的命名规则，G组有电子游戏更小的对应命名规则；C（N）对应的书籍命名常规还没成事，而且按照范围的话，通用的书籍范围比CN的范围更大，不通用（另外，参考书籍关注度，有定向排除过（“暂不提供”）“漫画、杂志”等类似书籍，可能也存在这样的问题）；A组现在规则也没有明显冲突地方。似乎这样修改有点多此一举。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 01:06 (UTC)[回复]
连书籍、影视的命名常规都没搞好，就肆意破坏现有已行的规则，这看上去不像是一个良好的提案。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 01:10 (UTC)[回复]
现在是提议用ACG常规（框架）管“ 书籍、影视”，上方已开始有想法。--唔好阻住我爱国（留言） 2024年5月29日 (三) 01:16 (UTC)[回复]
如果觉得ACG的命名方式（更准确来说，是其理念）对于“书籍、影视”也合适的话，意见是应该推动后者定向规则的指定，移植理念，而不需要改动现有的规则（已定规则扩界可能会有更多意想不到的与已有条目例子不符的问题，并且会破坏现有规则）。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 01:24 (UTC)[回复]
No No No, 现在不是移植理念这么简单，单纯“移植理念”已经不能满足“主宾关系”问题，ACG常规没有表明“主宾关系”，所以现正写“虚构常规”，将包括管理条目名称、分部标题、角色名称、分集标题。--唔好阻住我爱国（留言） 2024年5月29日 (三) 01:31 (UTC)[回复]
鬼叫现在中维“ 条目名称、分部标题、角色名称、分集标题”也有各自的条目。--唔好阻住我爱国（留言） 2024年5月29日 (三) 01:32 (UTC)[回复]
不建议在现有已使用的规则的概念上无限上拓。另外对于主体牵引的列表类条目的作品名部分应该考虑用一致性来与对应的作品主体条目关联。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 02:14 (UTC)[回复]
如果针对的福星小子_(2022年动画)和福星小子，前者是改编动画，后者是原作漫画，基于这点，再套用规则来判断命名次序，不过，可能要靠这个特定改编媒体创建或者拆离自原作条目时的命名一致性，如果可以的话，应该和原作的命名方式一致。这点或者可以考虑补充到ACG命名常规中。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 01:20 (UTC)[回复]

初步方向 (“A”部分/有足够共识的话将同时挂在影视常规)

现行条文

1.官方译名、正式译名和通用译名相同。
2.正式译名和常用译名相同，无官方译名或官方译名与其他译名不相同。
3.只有通用译名，或通用译名和官方译名、正式译名不相同。此情况常见于先在网络流行一段时间的作品，导致字幕组等非正式译名较官方和正式译名通用。此外也有其他原因导致官方和正式译名不通用。在这个情况下，可按命名常规的使用事物的常用名称规则使用通用译名为条目名称。
4.只有官方译名和正式译名。
5.只有正式译名。
6.官方译名、正式译名和通用译名均不存在时，应考虑在出现前述其中一种译名后把条目移动至该名称。

提议条文

1. 官方译名/正式译名/通用译名/可靠来源译名均一致
2. 正式译名和大部分可靠来源（量化准则：按该译名于各可靠来源出现比例）的译名相同，无官方译名或官方译名与其他译名不相同。
3.大部分可靠来源的译名（量化准则：按该译名于各可靠来源出现比例）
--
除非没有可靠来源证实或可靠来源之间对使用某译名的分歧很大，否则很难落到第四次序
--
4. 官方译名（含中文字元）
5. 正式译名 （含中文字元）
6. 官方译名（不含中文字元）
7. 正式译名 （不含中文字元）
8. 通用译名 （字幕组等非可靠来源使用的译名 ）

简单说明：现行版本是2006年版本，当时没有Netflix等串流平台播放，严重依赖极少量的电视台播放。 目前是2024年，网上串流服务市场已成熟，观众可透过OTT平台收看正版节目，仍然将字幕组译名先于合规译名已不合时宜，对正版节目是一种侮辱。至于“通用译名”，何谓通用应优先交由可靠来源决定，而非单单一句“另有翻译：”。 如果官方及代理商宣传到位的话，可靠来源译名相等于官方译名及正式译名，而且如果某译名是官方译名或正式译名，应该有可靠来源予以支持或证实。另外这还是优质的二手来源，减低使用一手来源或不列来源的机率。--唔好阻住我爱国（留言） 2024年5月29日 (三) 02:49 (UTC)[回复]

然而并不符合中国大陆地区的情况。由于中国大陆存在先审后播的情况很多媒体基本上都会使用字幕组提供的翻译名称(尤其是代理商不宣传以及未引进的低龄向作品)--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 。 2024年5月29日 (三) 04:34 (UTC)[回复]
我们这不是有字词转换吗？Sanmosa 人人皆王 2024年5月29日 (三) 04:39 (UTC)[回复]
然而我指的是来源问题，而不是语言问题。--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 。 2024年5月29日 (三) 06:17 (UTC)[回复]
所以“可靠来源的译名”先于官方译名及正式译名。--唔好阻住我爱国（留言） 2024年5月29日 (三) 05:08 (UTC)[回复]
所以有什么必要改日本动漫命名常规？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月29日 (三) 04:57 (UTC)[回复]
标准化“通用译名”--唔好阻住我爱国（留言） 2024年5月29日 (三) 08:49 (UTC)[回复]
“官方译名及正式译名”不就是一种“可靠来源的译名”？而且还是考虑部分跨地区跨语种的平台的不普及性（可能某些极端案例下，华语使用范围的平台没有播放某部作品，而只有华文字幕组有译制），依然应该以常用判断优先。看不出这样提高“可靠来源的译名”的意义何在。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 06:32 (UTC)[回复]
“译名决定办法”其实也确定不同地区的取名模式的优先序：先到先得，即可能台地区有一个正式译名，大陆地区有一个通用译名，如果两者相同的话，适用序列2（台的正式译名），如果两者不同，原则应该适用序列3（大陆的通用译名），（后一点不能确定）但可以遵从先到先得来抢坑。整体而言，通用的命名常规和细则ACG命名规范，一直都是通用（常用）优先，只是通用有可能和官方的一样。类似的论述：Wikipedia:官方名称——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 06:40 (UTC)[回复]
“如果官方及代理商宣传到位的话，可靠来源译名相等于官方译名及正式译名”，如果官方等宣传到位，这个名字不就成了通用名称（常用）？那字幕组等另开名字就还是抢不到常用啊？你官方不给力不就是官方的问题吗？——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 06:44 (UTC)[回复]
可能参考Wikipedia_talk:命名常规_(日本动漫游戏条目)、WikiProject:ACG/译名与命名/决议投票、WikiProject:ACG/有关正式译名/决议投票、WikiProject_talk:ACG/译名与命名，Special:重定向/revision/13760352（ACG命名规范建立前比较近的一版命名常规）、Special:重定向/revision/4002166（对应Wikipedia:格式手册/日本动漫游戏2006年的命名规范）时的讨论意见。对于常用命名判断的话，我认为可以参考搜索引擎的量来推断，如果某个特定名字相对其他名字在数量上足够拉开数量级差距，并且有相关的符合可靠来源要求的来源引述过（可能是传统媒体或专门资讯报道、或者研究文章等），则可以作为可选的通用（常用）名称选择；退而次至是非符合可靠来源（也就是类似字幕组的译制名来源等）；再次至就是只看搜索量。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 07:07 (UTC)[回复]
可不可以简单点列阁下的次序？--唔好阻住我爱国（留言） 2024年5月29日 (三) 09:00 (UTC)[回复]
？——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 09:30 (UTC)[回复]
是指通用名称筛选策略：通过搜索引擎等可以测定名称使用量的机制，对特定（作品）命名的用词的数量进行统计。如果某个特定名字相对其他名字在数量上足够拉开数量级差距，并且1.有相关的符合可靠来源要求的来源引述过（可能是传统媒体或专门资讯报道、或者研究文章等）；2.非符合可靠来源的来源（类似字幕组的译制名来源等）引述过；3.无法确定，只能评价统计的数量级。优先选择序列为1>2>3。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月29日 (三) 09:30 (UTC)[回复]
换句话说，即“可靠来源译名”优先？--唔好阻住我爱国（留言） 2024年5月29日 (三) 10:02 (UTC)[回复]
官方译名（原作者译名）及正式译名（代理商译名）只要能被证实同样是一种“可靠来源的译名”。如前面的讨论，官方译名及正式译名的话同时按一定比例加分，与普通译名进行比较。--Wengier（留言） 2024年5月29日 (三) 18:50 (UTC)[回复]
准确来说，是通过统计分析（方法不限，可以包括搜索引擎测试）下，占常用优势的，依次序优先下降是“有可靠来源引述的”、“‘不太’可靠来源引述的”、“无可靠来源引述”，单纯“可靠来源引述的译名”并不够，可能只是没人用的“官方”或“代理”译名。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月30日 (四) 00:13 (UTC)[回复]
现行条文
  • 通用译名（常用译名）：该作品在某地或更多地方经常使用或普遍使用的中文译名。其通用程度可以使用译名的书籍册数、出版量等来验证，并须遵守Wikipedia:关注度所订立的标准。
提议条文
  • 通用译名（常用译名）：该作品在某地或更多地方经常使用或普遍使用的中文名字／译名。其通用程度可以可透过搜寻引擎测试等方式判断，该作品的特定名字／译名于搜寻引擎测试较其他名字／译名在数量上足够拉开数量级差距，并曾至少被一个可靠来源引述的可优先使用，另须遵守Wikipedia:关注度所订立的标准。
--唔好阻住我爱国（留言） 2024年5月30日 (四) 01:29 (UTC)[回复]
如改定义，则条文如下：
现行条文

1.官方译名、正式译名和通用译名相同。
2.正式译名和常用译名相同，无官方译名或官方译名与其他译名不相同。
3.只有通用译名，或通用译名和官方译名、正式译名不相同。此情况常见于先在网络流行一段时间的作品，导致字幕组等非正式译名较官方和正式译名通用。此外也有其他原因导致官方和正式译名不通用。在这个情况下，可按命名常规的使用事物的常用名称规则使用通用译名为条目名称。
4.只有官方译名和正式译名。
5.只有正式译名。
6.官方译名、正式译名和通用译名均不存在时，应考虑在出现前述其中一种译名后把条目移动至该名称。

提议条文

1. 官方译名/正式译名/通用译名译名均一致
2. 正式译名和曾被可靠来源证实的通用译名的译名相同，无官方译名或官方译名与其他译名不相同。
3. 曾被可靠来源证实的通用译名
--
除非完全没有可靠来源证实或各译名之间未能有足够数量级差距，否则很难落到第四次序
--
4. 官方译名（含中文字元）
5. 正式译名 （含中文字元）
6. 官方译名（不含中文字元）
7. 正式译名 （不含中文字元）
8. 其他通用译名 （字幕组等未被任何可靠来源使用的译名 ）

--唔好阻住我爱国（留言） 2024年5月30日 (四) 01:42 (UTC)[回复]
正如维基百科需要列明来源，在这的次序可是二手（曾被可靠来源使用），一手（官方／正式），原创／来源不佳（字幕组）--唔好阻住我爱国（留言） 2024年5月30日 (四) 01:49 (UTC)[回复]
我觉得举几个例子进行说明或许不错，可让大家看看其具体如何执行以及执行中可能出现的问题。至于二手、一手的顺序，大体应该是如果二手能拉开足够数量级差距时用二手，否则优先考虑一手。--Wengier（留言） 2024年5月30日 (四) 02:32 (UTC)[回复]
完善“通常译名（常用译名）”的定义即可，但没必要改动下面的判断顺序，因为应该一直以来“常用优先于官方”，严格来说，字幕组的发布内容也算是（译名的）一手来源信息。当时这个不考虑来源的可靠性也可能基于来源本身难满足可靠来源的要求。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月30日 (四) 02:36 (UTC)[回复]
貌似所谓“常用优先于官方”的原则只不过是“有时”，并仅限于维基百科中的部分内容。上面就说过“以前主手册在字面上，常用和官方平起平坐”，可见并非“一直以来”都是这样。再以华特迪士尼公司条目为例，其对话页中显然有部分使用者多次要求将其中的“迪士尼”改为“迪斯尼”（被认为在中国大陆更常用），但每次都被其他维基人以名从主人的原则拒绝。可见名从主人的原则对于这些条目命名之重要性。--Wengier（留言） 2024年5月30日 (四) 02:44 (UTC)[回复]
但现时命名常规，常用是第一级的“命名原则”，名从是第二级的“主要命名惯例”，就好像美国的名从为“美利坚合众国”、苏联的名从是“苏维埃社会主义共和国联盟”。而且过往命名常规版本下，常用也似乎一直压着名从。根据应该一位老人Chiefwei所说（[9]），名从实际上2008年引入的（oldid=8766872），而且不是来自en的，ACG的命名规范是2006年确定的。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月30日 (四) 03:04 (UTC)[回复]
说明一下，上面说的“官方”译名不是指所谓没人用的“官方”译名，而是指存在一定使用度的官方译名，虽然也许在所有中文译名中仅排名第二。比如说非官方的某中文译名的使用度为60%，而官方中文译名的使用度为40%。两者其实均为常用译名，而前者为最常用译名，后者则为官方+第二常用译名。但两者显然并不能拉开足够数量级差距。上面主要说的就是类似这种情况（即使是2005年的ACG命名规范的文氏图显然亦认为官方+通用译名高于单纯官方或通用译名）。而不是说类似非官方的某中文译名的使用度为90%，而官方中文译名的使用度仅为10%之类的存在数量级差距的情况。阁下提到的老人Chiefwei所说的话，他自己承认“个人对这一条并不以为然”（表明为个人意见），同时承认“目前中文维基百科的命名常规确实是冲突的”。不同维基人显然可能对命名常规存在不同理解，像华特迪士尼公司等条目就是典型的例子。--Wengier（留言） 2024年5月30日 (四) 03:27 (UTC)[回复]
“一定使用度的官方译名”，就是同时具有“通用译名”和“官方译名”/“正式译名”两个性质的名字，实际上这样就属于序列1、序列2的情况。现在来看，这部分除了完善“通用译名”的定义外，没需要调整选择排序。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月30日 (四) 06:04 (UTC)[回复]
更改定义后，整体多了2个选项。故有必要重新调整选择排序。--唔好阻住我爱国（留言） 2024年5月31日 (五) 02:05 (UTC)[回复]
而且
“3.只有通用译名，或通用译名和官方译名、正式译名不相同。此情况常见于先在网络流行一段时间的作品，导致字幕组等非正式译名较官方和正式译名通用。此外也有其他原因导致官方和正式译名不通用。在这个情况下，可按命名常规的使用事物的常用名称规则使用通用译名为条目名称。
4.只有官方译名和正式译名。
5.只有正式译名。
6.官方译名、正式译名和通用译名均不存在时，应考虑在出现前述其中一种译名后把条目移动至该名称。”
写到一旧旧咁（不清不楚），导致现行编辑者使用更简单昜明的名从主人原则，GA上的条目标题也是以“名从主人”为依归，而非“通用译名”。--唔好阻住我爱国（留言） 2024年5月31日 (五) 02:11 (UTC)[回复]
“ （不）含中文字符”这个说法好像有冲突或者不必要，因为原规则也声明了“如正式译名使用或包含原名英文，条目名称可根据命名常规的原文常用规则沿用原名。”，下面也有举类似例子，也就是翻译后的名称（举例为官方性译名，但不确定有没涉及常用译名的例子）包含外文“不译”则保留“原文”。至于第三条的说法，后大部分是对于前面规定的一些补充解释，核心是前面“只有通用译名 | 或通用译名和官方译名、正式译名不相同”，也就是存在一个译名判断为“通用译名”，而没有官方性译名；或者存在官方性译名，但其无法判断为“通用译名”的，选具有“通用译名”性质的那个。其实看规则上面的文氏图，就是看某个译名具有三个属性中的哪种，按照规则的指定归属和顺序就是优选顺序。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月31日 (五) 03:34 (UTC)[回复]
又以“官方译名”Kizuna no Allele作例，你认为 Kizuna no Allele 的排名是否应比 绊之Allele 高？--唔好阻住我爱国（留言） 2024年5月31日 (五) 05:32 (UTC)[回复]
使用Google搜索测试来看：“"Kizuna no Allele" -"絆之Allele" -"絆的Allele" -wiki -"维基" -"維基" -site:wikipedia.org”的索引量为203000，“"絆之Allele" -"Kizuna no Allele" -"絆的Allele" <排除词，略>”为303000，“"絆的Allele" -"絆之Allele" -"Kizuna no Allele" <略>”为6330，从数量级的话“Kizuna no Allele”，“绊之Allele”相近（虽然前者基本上都是英文的搜索内容），都近似常用，前者具有“官方”性质（也能使没完全翻译？），我认为根据规则来看，选“Kizuna no Allele”似乎也可以。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月2日 (日) 07:30 (UTC)[回复]
问题是这里是中文维基百科，而非其他文维基百科。论搜寻量来说，一定是外文比例占优，但新定义如何确保中文地位为优先？--唔好阻住我爱国（留言） 2024年6月2日 (日) 14:22 (UTC)[回复]
字幕组等中文译名（只要有一定使用量，不管能不能找到可靠来源）应高于纯粹的非中文名称。--Wengier（留言） 2024年6月2日 (日) 15:41 (UTC)[回复]
例如规则举例Fate/stay night的说明（或者说Fate系列）。如果非要中文的话，那只能套用通用常规的“使用中文”命名原则（与“常用”同等）。（好吧，还有IBM、Google）——Sakamotosan路过围观 | 避免做作，免敬 2024年6月3日 (一) 05:55 (UTC)[回复]
那么，用第二个计算又如何？
  • 通用译名（常用译名）：该作品在某地或更多地方经常使用或普遍使用的中文名字／译名。其通用程度可以可透过搜寻引擎测试等方式判断，该作品的特定名字／译名于搜寻引擎测试（并使用“所有中文结果”功能筛选）较其他名字／译名在数量上足够拉开数量级差距，并曾至少被一个可靠来源引述的可优先使用，另须遵守Wikipedia:关注度所订立的标准。
--唔好阻住我爱国（留言） 2024年6月3日 (一) 11:08 (UTC)[回复]
seems good，但是否保留“使用译名的书籍册数、出版量”这个判断方式（虽然感觉是判断官方的出版物，但是否也适用于其他纸质出版物的判断，例如以前的资讯杂志）。其实“Kizuna no Allele”对于例外规则也对不上：“如正式译名使用或包含原名英文”，这个应该是官方译名？——Sakamotosan路过围观 | 避免做作，免敬 2024年6月4日 (二) 03:29 (UTC)[回复]
按现行标准来说，使用“使用译名的书籍册数、出版量”已不合时宜。因书籍册数及出版量只是传统书才适用。对于近期兴起的连载书及游戏改编，完全不适用。
如以“书籍册数、出版量”为标准，即提升正式译名的地位。--唔好阻住我爱国（留言） 2024年6月4日 (二) 13:10 (UTC)[回复]
“虽然感觉是判断官方的出版物，但是否也适用于其他纸质出版物的判断，例如以前的资讯杂志”，当然如果认为现在基本上没有纸质非官方出版物，避免和官方的定义重合的，也行。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月5日 (三) 01:21 (UTC)[回复]
另外看了GA的评选上，好像也没有提及明显的命名要求，如果需要满足规范，命名规范的话就是跟随通用的命名常规和针对性的ACG命名常规。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月31日 (五) 03:40 (UTC)[回复]
就是有ACG条目当选了GA而没有以通用翻译为依归…--唔好阻住我爱国（留言） 2024年5月31日 (五) 05:27 (UTC)[回复]
没看懂？——Sakamotosan路过围观 | 避免做作，免敬 2024年6月2日 (日) 07:30 (UTC)[回复]
好像GA并有相关的限制？——Sakamotosan路过围观 | 避免做作，免敬 2024年6月3日 (一) 05:55 (UTC)[回复]

虽说我个人觉得外文衍伸作品（小说、剧集、电影、音乐和游戏）其名称应该和原作相同，但它们都该分别看待，

  1. 刚好相同如小说《群_(小说)》VS剧集《群_(电视剧)》
  2. 刚好不同如小说《猎魔人》VS游戏《巫师_(游戏)》
能一样最好，但不一样也不会怎么样。 --窝法乙烷 儿法梦碎 2024年6月5日 (三) 05:42 (UTC)[回复]
《群》的举例既不是ACG也不是电子游戏；《巫师》或者适配电子游戏组，但仅限于电子游戏，另一个是普通小说，不属于ACG（N）的轻小说范围。当然，考虑这些本作条目及其改编媒体条目的命名一致性或者要考虑到。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月5日 (三) 06:06 (UTC)[回复]
都谈扩权了，就不特地找ACG正相关，但要找也是有啦，小说《All You Need Is Kill》VS电影《明日边缘》。此外ACG（N）里面的N比起轻小说更属于小说吧，毕竟《十二国记》那年代谁会这么分。 --窝法乙烷 儿法梦碎 2024年6月5日 (三) 06:37 (UTC)[回复]
谁跟你谈扩界啊¿ 还是前面说的，如果觉得ACG组的命名规范好的，可以将这套方案搬迁到其他主题，而不是扩界。其次ACG（N）也锚定以日式轻小说为主题，非日式小说体系的不归ACG组管，自己找WikiProject:小说……哦，这个专题已经死了。WikiProject:文学、WikiProject:电影、WikiProject:电视……哦，半死不活的那种，大概。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月5日 (三) 08:06 (UTC)[回复]
关于小说部分，最初锚定的是日式轻小说，但是也有一批日式传统小说由于改编动画、漫画等，只能算是意外归入（或者仅限于日式轻小说和改编动画、漫画过的日式传统小说？）。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月5日 (三) 08:18 (UTC)[回复]
也就是像这些改编过动画、漫画的《十二国记》、《古籍研究社系列》、《小市民系列》、《UN-GO》的原作小说，算是传统小说还是轻小说。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月5日 (三) 08:22 (UTC)[回复]
毕竟轻小说标准过于灵活，有种宝可梦日常被开除JRPG的美。 --窝法乙烷 儿法梦碎 2024年6月5日 (三) 09:10 (UTC)[回复]
不一定是这个问题，轻小说到将自己定性为“轻小说”的连载杂志出现后，这之后的媒体题材就基本能确定，而且也有一些明确的判断来源。至于之前的没有这样定性自己的作品的，是看本项目能不能接纳。如果我对这个定义的话，倾向就是1.日式轻小说、2.被改编为日式动画（包括动画电影）、漫画、电子游戏、真人演绎媒体的日式或者日语原作传统小说，可以归入ACG专题协作管理。（真人演绎主要就是All You Need Is Kill和明日边缘，山田君与7人魔女和山田君与7人魔女 (电视剧)……）——Sakamotosan路过围观 | 避免做作，免敬 2024年6月5日 (三) 09:51 (UTC)[回复]
至于All You Need Is Kill和明日边缘（Edge of Tomorrow），后者姑且能归入ACG？或者对于ACG组来说，最近十年内的确多了一批西方资本购买日式ACG原作题材进行接近原作的改编或者彻底的新编，是ACG组过往少见的。（对于前面一对例子，姑且两者的作品名字毫无关联，题材上似乎大改不少，不提及估计不会认为后者是前者的改编）。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月5日 (三) 08:18 (UTC)[回复]
反方向也不是没有，例如电影《哈尔的移动城堡》VS小说《魔幻城堡》。 --窝法乙烷 儿法梦碎 2024年6月5日 (三) 09:13 (UTC)[回复]
ACG污染：要么本身就是ACG范围内，要么其被改编媒体变成ACG范围内。类似GPL。但感觉为了一致性扯远了，未完全解决归属方式下这种衍生改编容易带出更多问题。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月5日 (三) 09:40 (UTC)[回复]
不然改用原教旨主义，只有ACG才是ACG。漫画出广播剧、动漫出原声带、游戏联名奢持品以及主题乐园都不算。 --窝法乙烷 儿法梦碎 2024年6月6日 (四) 02:27 (UTC)[回复]
感觉还是扯远和玩笑开多了。如果真要认真讨论的话，还需要这几个议题：1.N的范围（基础部分为日式轻小说，但因为被改编为日式动画、漫画等媒体的原作（可能不限于日文或日式）小说是否也纳入）；2.真人演绎改编媒体的独立条目（包括电影和电视连续剧）是否纳入（主要是部分ACG（N）组内作品被改编为真人演绎作品，例如前述的《All You Need Is Kill》（有独立条目）、《山田君与7人魔女》（有独立条目）、《孤独的美食家》（无独立条目，不影响讨论，暂时是）等，好像这不是罕见例子）；3.在解决前面归属问题后，再就是不同媒体下的独立条目的命名一致性问题（例如原作为漫画的《All You Need Is Kill》，其改编真人电影的《Edge of Tomorrow》，是否需要系列命名的一致性）；4.范围“感染性”，就是前面一个小问题，被改编为ACG（N）组内媒体的独立条目，如果存在对应的不属于ACG（N）组的媒体的独立条目，该条目是否也被纳入组内协作管理（或者称之为反向感染），正向感染似乎没疑问，除非对类似《All You Need Is Kill》的例子有疑问。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月6日 (四) 03:10 (UTC)[回复]
如果不纳入组内管理的话，组外条目就自然不适用组内的规则，而且也不用考虑与组内条目的命名一致性需要。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月6日 (四) 03:12 (UTC)[回复]

“A”、“C”、“N”部分第二版

只更改定义并新增：

现行条文
  • 通用译名（常用译名）：该作品在某地或更多地方经常使用或普遍使用的中文译名。其通用程度可以使用译名的书籍册数、出版量等来验证，并须遵守Wikipedia:关注度所订立的标准。
提议条文
  • 通用译名（常用译名）：该作品在某地或更多地方经常使用或普遍使用的中文名字／译名。其通用程度可以可透过搜寻引擎测试等方式判断，该作品的特定名字／译名于搜寻引擎测试（并使用“所有中文结果”功能筛选）较其他名字／译名在数量上足够拉开数量级差距，并曾至少被一个可靠来源引述的可优先使用，另须遵守Wikipedia:关注度所订立的标准。

概念：

  • 此部分不适用于日本游戏。关于日本游戏，另请参阅电子游戏手册的命名次序。
  • 条目／段落命名次序须以条目／段落的中心媒介为首。如该条目／段落主要描述小说，条目／段落标题则须以小说走命名程序。

--唔好阻住我爱国（留言） 2024年6月5日 (三) 12:03 (UTC)[回复]

常用名称本身就指的是可靠来源（而不是论坛或粉丝圈）中人、物或事项的常见的名称，因此“至少被一个可靠来源引述”完全多余——如果没有可靠来源使用，这就不该叫作“常用名称”。十来年前中维对来源可靠性的评估要求很低，所以那时候可能是来源都行；但现在逐渐注重来源可靠性，那之前关于“常用”的界说就极其粗糙了。而且关注度指主题独立开设条目的资格，和条目起什么名字无关。我想要改方针的话，那就直接按当今的标准改好。
不过借用其他讨论中的一个论点，中维的基础建设跟不上，大概执行时还是只能按以前的套路😂 而且当然中文圈在作品译名方面，宁愿生造硬编也不会像英文那样用抄罗马字兜底，这就的确很棘手。--For Each element In group Next（留言） 2024年6月5日 (三) 14:31 (UTC)[回复]
“至少被一个可靠来源引述”仅用作参考来源及归纳网路通用性。若没有“一个可靠来源”证实，我说网上流行这个译名就行了？--唔好阻住我爱国（留言） 2024年6月5日 (三) 15:07 (UTC)[回复]
所以说，常用名称本身就指的是可靠来源中的常用，而不是“网上流行”。完整来说“通用译名（常用译名）是指该作品在可靠来源中经常使用或普遍使用的中文名字／译名”，没有可靠来源使用的名称连入局资格都没有。入局的名称就是pk可靠来源使用量，所以“一个可靠来源”也说明不了什么问题--For Each element In group Next（留言） 2024年6月6日 (四) 13:03 (UTC)[回复]
原定义仅指出通用程度只靠书籍出版量作定断，只字不提“可靠来源”。--唔好阻住我爱国（留言） 2024年6月6日 (四) 13:41 (UTC)[回复]
嗯，正如您上方讨论说的，十几年足以让很多东西变化；网路的兴起与纸媒的衰落是如此，社群对条目命名等方针的理解也是如此。那按照今日的方针，原定义的内涵和表述是否还合适？毕竟在我看来，当年可能不讲究，但今日我们都是按可靠来源说话，“某地或更多地方”这个表述预设就已经限定在可靠来源范围内了。（除非您声明包括论坛等不可靠来源在内）--For Each element In group Next（留言） 2024年6月6日 (四) 14:00 (UTC)[回复]
那就变成回到我之前说过的：“通过搜索引擎等可以测定名称使用量的机制，对特定（作品）命名的用词的数量进行统计。如果某个特定名字相对其他名字在数量上足够拉开数量级差距，并且1.有相关的符合可靠来源要求的来源引述过（可能是传统媒体或专门资讯报道、或者研究文章等）；2.非符合可靠来源的来源（类似字幕组的译制名来源等）引述过；3.无法确定，只能评价统计的数量级。优先选择序列为1>2>3。”或者说，我们现在还要不要接受以前那套不完全根据可靠来源来判断这个事项。PS，一个作品的“常用名字”在爱好者间口口相传，但就没有中文的主流或者传统媒体引用这个名字（或者无论哪个名字）关注或者详细介绍，它在那，也不在那。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月6日 (四) 00:38 (UTC)[回复]
1.官方译名、正式译名和通用译名相同。
2.正式译名和常用译名相同，无官方译名或官方译名与其他译名不相同。
3.只有通用译名，或通用译名和官方译名、正式译名不相同。此情况常见于先在网络流行一段时间的作品，导致字幕组等非正式译名较官方和正式译名通用。此外也有其他原因导致官方和正式译名不通用。在这个情况下，可按命名常规的使用事物的常用名称规则使用通用译名为条目名称。
4.只有官方译名和正式译名。
5.只有正式译名。
6.官方译名、正式译名和通用译名均不存在时，应考虑在出现前述其中一种译名后把条目移动至该名称。
@Cwek:
按照阁下的计划，连同上方原有的次序，应如何排列？还是完全放弃上方原来次序？因为阁下的提案多了三个选项。--唔好阻住我爱国（留言） 2024年6月6日 (四) 10:43 (UTC)[回复]
我想，那三个选项是针对“通用译名”怎么判定的问题，不影响上方的原来次序。--For Each element In group Next（留言） 2024年6月6日 (四) 13:25 (UTC)[回复]
就是这个意思。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月7日 (五) 01:09 (UTC)[回复]

上方的讨论也提到过，这里的“通用译名”是只能有一个，还是可以有多个（1个最通用+n个次通用）？如果可以有多个“通用译名”，那这个问题应该能得到一个大家都满意的结果：

  • 没有官方（正式）译名，大家都是第3档，那自然“最通用”优于“次通用”
  • 如果有官方（正式）译名，就会出现“次通用+官方/正式”（第1/2档）优于“最通用”（第3档的情况）

那现在的问题就有两个：一、“通用译名”如何界说？是直接严格规定“可靠来源”中的通用，排除论坛、实况主的用法（能执行多好另说），还是保持现在的模糊表述？二、“次通用”的门槛是什么？例如相对用量方面，之前讨论也提到过很多数字，1/2、1/3、1/10（数量级）。--For Each element In group Next（留言） 2024年6月6日 (四) 13:39 (UTC)[回复]

数量级，以10的幂为一级，然后同级的话，按照同级有效值对比，例如10000比1000优先，9000比1000优先，5000比4000略优先，9200比9100略微优先（或者近似）。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月7日 (五) 01:09 (UTC)[回复]
至于判定来源上，有符合可靠来源的情况（包括传统媒体、专门资讯网站等）优先，没有的话则考虑非可靠来源（也就是民间字幕组发布信息，爱好者交流信息等）的情况。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月7日 (五) 01:09 (UTC)[回复]
那大致就是下面这样？

通用译名（常用译名）：作品在某地或更多地方普遍使用的中文译名（名称）。原则上，应依据某地的独立可靠中文来源，来判定译名在该地是否通用。若可靠来源没有形成使用惯例（如无可靠来源介绍主题），则编者可参考搜索量等资料，透过讨论决定名称通用性。条目应有一个最通用译名，其他译名在使用量上未与最通用译名拉开数量级差距的，亦属于通用译名之列。

非可靠来源毕竟难登大雅之堂，方针上我就没有明写。另一个就是绝对数量的问题，虽然我上面留了个坑：如果只有惟一一个可靠来源提及了一个译名，这个名称到底算常用还是偶然 耸肩--For Each element In group Next（留言） 2024年6月7日 (五) 13:53 (UTC)[回复]
这个可以，如果更改了定义，应该还可以处理Gundom问题，将Gundom系列重新列入本手册规管。毕竟不可能为公平性而将Gundom系列而用英文表达（中文地区Gundom没有通用性，只有钢达／高达）。
是的，是用“搜寻量”决定通用性，如果“钢达”使用率高就用“钢达”，如果“高达”使用率高就用“高达”。--唔好阻住我爱国（留言） 2024年6月8日 (六) 10:40 (UTC)[回复]
回应“ 如果只有惟一一个可靠来源提及了一个译名，这个名称到底算常用还是偶然”，故建议先计算搜寻量，然后再找可靠来源补底。--唔好阻住我爱国（留言） 2024年6月8日 (六) 11:48 (UTC)[回复]
我的意思是，不是由搜索量本身决定，而是参考搜索量决定。或者说先检查可靠来源，可靠来源没有惯例用法后，再找搜索量补底。再或者说，先统计可靠来源中的搜寻量，如果可靠来源（几乎）没结果，再放开到其他网站。您的理解和我的表述可能还是不同。--For Each element In group Next（留言） 2024年6月8日 (六) 14:20 (UTC)[回复]
原来如此，可以。--唔好阻住我爱国（留言） 2024年6月8日 (六) 14:33 (UTC)[回复]
另外，建议阁下同时参与下方WP:IS的讨论，因为下方讨论内容会影响本提案的这句（应依据某地的独立可靠中文来源）应如何理解。--唔好阻住我爱国（留言） 2024年6月8日 (六) 14:42 (UTC)[回复]

“A”、“C”、“N”部分第三版

更改如下：
1. “日本动漫游戏”（NC:ACG）更名至“日本小说、漫画及动画”（NC:ACN）
注：游戏有游戏手册，谈不上两本手册共同管理同一项目，而且原标题匆视了小说的存在。

2.

现行条文
  • 通用译名（常用译名）：该作品在某地或更多地方经常使用或普遍使用的中文译名。其通用程度可以使用译名的书籍册数、出版量等来验证，并须遵守Wikipedia:关注度所订立的标准。
提议条文
  • 通用译名（常用译名）：作品在某地或更多地方普遍使用的中文译名（名称）。原则上，应依据某地的独立可靠中文来源，来判定译名在该地是否通用。若可靠来源没有形成使用惯例（如无可靠来源介绍主题），则编者可参考搜索量（并通过“所有中文结果”进行筛选）等资料，于条目讨论页透过讨论决定名称通用性。条目应有一个最通用译名，其他译名在使用量上未与最通用译名拉开数量级差距的，亦属于通用译名之列。
现行条文

只有通用译名，或通用译名和官方译名、正式译名不相同。 此情况常见于先在网路流行一段时间的作品，导致字幕组等非正式译名较官方和正式译名通用。此外也有其他原因导致官方和正式译名不通用。在这个情况下，可按命名常规的使用事物的常用名称规则使用通用译名为条目名称。

提议条文

只有通用译名，或通用译名和官方译名、正式译名不相同。 此情况常见于影片发行商/书藉出版商或代理商没有引入相关作品到中文地区，导致机器译名、自媒体译名等非正式译名于中文社群通用。此外也有其他原因导致官方和正式译名不通用。在这个情况下，请依照通用译名定义决定条目名称。

注：这是2024年更新版（试行），如一年内效果显著及测试成功（意指在2024-2025年新建或大规模修改的条目标题符合科学化通用标题为首的要求。），2025年将明确提出延伸至其他电视节目及相关条目。

以上！--唔好阻住我爱国（留言） 2024年6月10日 (一) 08:09 (UTC)[回复]

大致如此，但还是不建议将这个特定专题的命名规则原地拓展到其他专题上。当其他专题（电视节目专题等）也想使用类似规则，可以移植条文。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月11日 (二) 02:15 (UTC)[回复]
感谢支持，当然不会“原地拓展”。但因处理上方管理员的见解而头痛，暂时没想拓展方案。--唔好阻住我爱国（留言） 2024年6月11日 (二) 11:40 (UTC)[回复]
另，更新了次序3的句子。@User:cwek--唔好阻住我爱国（留言） 2024年6月11日 (二) 13:56 (UTC)[回复]
另，命名常规的话原来应该是NC:ACG（还有WP:ACGNAME）吧。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月11日 (二) 02:15 (UTC)[回复]

注：2006年没有OTT平台，2024年有大量OTT平台，外地片源以比当年更容易进入中文社群，回应上方的编辑者语道今时今日还在口中提及字幕组等盗版平台是放不上台面（桌子上），故简单修改了使用通用译名的原因。--唔好阻住我爱国（留言） 2024年6月11日 (二) 13:56 (UTC)[回复]

seems good。但也仍存在部分作品没有中文代理商，导致还是没有官方性中文译名。（好像本季度的Girls Band Cry的东映，好像连巴哈都没有上线，虽然在B站上官方账号有发布过角色PV，作品名就是英文字型，角色名的假名字型不译，嗯……）那个“等”字就当是也会考虑字幕组等蹭了常用度判断的来源之一吧。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月12日 (三) 00:50 (UTC)[回复]
按照新次序表，Girls band cry 可走到次序3的可靠来源部分，因为巴哈姆特GNN新闻有相关报导并使用“Girls Band Cry”一词。
https://gnn.gamer.com.tw/detail.php?sn=261094--唔好阻住我爱国（留言） 2024年6月12日 (三) 11:21 (UTC)[回复]
而“哭泣少女乐队”是没有可靠来源使用，故优先度次于Girls Band Cry.--唔好阻住我爱国（留言） 2024年6月12日 (三) 11:26 (UTC)[回复]

ACG是专有名词而ACN不是（？），可以考虑ACG重定向至ACGN，然后在页面内添加“其中游戏不在本页面中叙述”之类的内容。--Leiem（留言·签名·维基调查） 2024年6月12日 (三) 03:07 (UTC)[回复]


公示版本

标题：维基百科:命名常规 (日本小说、漫画及动画条目)（NC:ACGN）

此规则是用于规范ACG的日本小说、漫画及动画部分条目及段落的命名规则。由于ACG条目中以日文系作品占大多数，但根据《命名常规》，维基条目通常应以中文命名，因此社群在经讨论后制定此规则以统一条目命名方式，并避免因条目命名问题而出现移动战。

此规则之多数定义与条文于2006年ACG相关条目译名、命名决议投票、相关讨论及2024年通用译名定义更新议案中获得社群共识通过。

定义
  • 官方译名：原作者、其他持有原作品版权的公司、组织或其法定分支机构所订定及公布的中文译名。
  • 正式译名：获原作者、其他持有原作品版权的公司、组织或其法定分支机构授权出版、播放或发行该作品的机构或代理商所使用的中文译名。
  • 通用译名（常用译名）：作品在某地或更多地方普遍使用的中文译名（名称）。原则上，应依据某地的独立可靠中文来源，来判定译名在该地是否通用。若可靠来源没有形成使用惯例（如无可靠来源介绍主题），则编者可参考搜索量（并通过“所有中文结果”进行筛选）等资料，并于条目讨论页透过讨论决定名称通用性。条目应有一个最通用译名，其他译名在使用量上未与最通用译名拉开数量级差距的，亦属于通用译名之列。

按上述规则，以下是一个关于哆啦A梦（日语：ドラえもん）译名的例子：

官方译名 正式译名 通用译名
（常用译名）
简体中文：哆啦A梦[1]

繁体中文：哆啦A夢[2]		 中国大陆地区：哆啦A梦 (艾影(上海))[3]

台湾地区：哆啦A梦 (国际影视]])[4]

港澳地区：多啦A夢 (myTV SUPER)[5]		 可靠来源：
哆啦A梦（中国大陆：环球时报[6]；台湾：TVBS [7]）

多啦A夢（香港：Yahoo 新闻[8]）
按搜寻量数据：
机器猫小叮当、超能小叮当、神奇小叮当、万能小叮当、蓝胖子、机器猫、叮当
优先次序

下图说明了译名使用的优先次序。

以下为上图中各项目的说明。条目标题和正文中对作品的正式称呼的译名均应使用优先次序最高的译名。如其后出现优先次序更高的译名，应经讨论确认使用新的译名后移动条目。

  1. 官方译名、正式译名和通用译名相同。
  2. 正式译名和常用译名相同，无官方译名或官方译名与其他译名不相同。
  3. 只有通用译名，或通用译名和官方译名、正式译名不相同。
    • 此情况常见于影片发行商/书藉出版商或代理商没有引入相关作品到中文地区，导致机器译名、自媒体译名等非正式译名于中文社群通用。此外也有其他原因导致官方和正式译名不通用。在这个情况下，请依照通用译名定义决定条目名称。
  4. 只有官方译名和正式译名。
  5. 只有正式译名。
  6. 官方译名、正式译名和通用译名均不存在时，应考虑在出现前述其中一种译名后把条目移动至该名称。

下方段落没有任何更改

如无反对意见，3日后启动公示程序。--唔好阻住我爱国（留言） 2024年6月16日 (日) 07:29 (UTC)[回复]

@Cwek、@Leiem、@For_Each_element_In_group_Next、@Milkypine、@Wengier、@甜甜圈真好吃:
.
7日内没有人表示异议，因此本提案现正公示，由2024年6月18日公示7日至2024年6月25日。以上！--唔好阻住我爱国（留言） 2024年6月18日 (二) 14:07 (UTC)[回复]
@HK5201314：可否简单解释修改了什么？上方讨论过于冗长。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 16:46 (UTC)[回复]
1.通用译名定义（由 书本出版量 改为 依据可靠来源，如没有可靠来源记录，则依靠搜寻量）。
2.移除日本游戏、新增日本小说。--唔好阻住我爱国（留言） 2024年6月19日 (三) 00:16 (UTC)[回复]
@Ericliu1912:即
#“A”、“C”、“N”部分第三版内容。
另外，这是为期一年的测试，看看变更定义后是否仍有效处理命名问题。有效的话才想其他延伸议案。--唔好阻住我爱国（留言） 2024年6月19日 (三) 00:20 (UTC)[回复]
“简体中文的命名”／“繁体中文的命名”是什么？--— Gohan 2024年6月19日 (三) 12:30 (UTC)[回复]
“原始码”表格与上下文内容关联不大，示意什么？而且全文转换规则若与标题转换规则一致，则是多馀，平添日后维护劳力；zh:的“标题名称”若与其后地区词相同，也是多馀；不带公共转换组及其他地区词或许不是妥当示范。内链转换语法页面即可，无需在此示范。--— Gohan 2024年6月19日 (三) 12:36 (UTC)[回复]
这个（繁简转换及原始码）是2006年的共识，不在本提案讨论范围。不过阁下的意见有助整理一年后的虚构命名手册的提案。--唔好阻住我爱国（留言） 2024年6月19日 (三) 13:18 (UTC)[回复]
2006年的过时、违规内容也应及时清除，如不清除，等于再次肯定。2006年尚未有星、马、澳变体、公共转换组，以及地区词转换方针指引，今时不同往日。2006年之后的几年，机械人还会将zh-cn:替换为zh-hans:，zh-tw:替换为zh-hant:，现已违反Wikipedia:字词转换处理#繁简与地区词转换分开；如再保留“为方便处理纷争，简体中文的命名将以中国大陆地区的标准评核，而繁体中文的命名则以港台地区的标准评核。”，即鼓动编者在已可转换地区词的zh-cn、zh-tw之外，违规另加与此二者一致的zh-hans、zh-hant，甚或如十几年前的机械人一般，将zh-cn、zh-tw替换为zh-hans、zh-hant。去除此句以及表格，不会阻碍对此ACGN规则理解、有利无弊，另在适宜字词补充内部链接至Wikipedia:地区词处理即可。最后一句“若港台地区和中国大陆地区的最合适译名不相同，港台地区命名应使用繁体中文，中国大陆地区则应使用简体中文命名。”当今亦是多馀的废话，宜去除或改为“香港、澳门、台湾译名应使用繁体中文，中国大陆、马来西亚、新加坡译名则应使用简体中文。”。--— Gohan 2024年6月20日 (四) 00:35 (UTC)[回复]
不是我不想改，而是共识认为不要搞那么多东西。所以在首句列出“此规则之多数定义与条文于2006年ACG相关条目译名、命名决议投票、相关讨论及2024年通用译名定义更新议案中获得社群共识通过。”
.
另外我要重申，这本手册是需要寿终正寝，因为我的目标是以更大范围的“虚构命名手册”取代NC:ACGN--唔好阻住我爱国（留言） 2024年6月20日 (四) 10:53 (UTC)[回复]
我同意Gohan君的意见，修正字词转换方面的表述。（建议Gohan君直接把改法贴出来，很多编者不是太明白这一方面）如果现在不想讨论，也建议将这一部分用省略号表述，意味著“未经讨论故不修改”。把原文拷贝一遍，这就好像这部分是经过讨论后再度确认的结果。--For Each element In group Next（留言） 2024年6月20日 (四) 14:56 (UTC)[回复]
还是认为避免原地扩大已有的规则。如果针对其他媒体也有自己适用的规则的话，可以移植一套过去。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 01:08 (UTC)[回复]
另外根据MOS:PSEUDOHEAD，目录应该用== 標題 ===而不是; 標題表示，我排了一下版。--For Each element In group Next（留言） 2024年6月20日 (四) 15:01 (UTC)[回复]
当“虚构命名手册”出场后，这本手册就可以寿终正寝了！--唔好阻住我爱国（留言） 2024年6月19日 (三) 13:20 (UTC)[回复]
抱歉，我必须在这里放入一个{{reflist-talk}}，才能避免在本页末尾看到一大串不知属于哪个讨论主题的参考资料。--CaryCheng（留言） 2024年6月24日 (一) 17:13 (UTC)[回复]

参考资料

  1. ^ 哆啦A梦未来百货店官方网站
  2. ^ 哆啦A梦未来百货公司官方网站
  3. ^ 艾影(上海)官方网站
  4. ^ 哆啦A梦台湾官网
  5. ^ myTV SUPER 多啦A梦播放清单
  6. ^ 潘小多. 哆啦A梦诞生无关梦境. 环球时报. 2024-05-30. 
  7. ^ 颜敏翔. 不要再叫「鹹蛋超人」！日影集已正名《超人力霸王》24年). 2024-01-05. 
  8. ^ 多啦A夢巡展七月登陸香港 大雄行「藍地毯」致敬港產片 K11 MUSEA設收費展區. 2024-05-24. 
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

议程2:废除不合时宜条文

议程2: NC:ACGN废除不合时宜条文获得通过！--唔好阻住我爱国（留言） 2024年7月6日 (六) 14:10 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
建议从“译名决定办法”至文末的条文如下：
译名决定办法
条目命名争议的解决
  • 若对条目名称有异议，需于条目讨论页提出讨论。
  • 若各地最合适译名不同，香港、澳门、台湾译名应使用繁体中文，中国大陆、马来西亚、新加坡译名则应使用简体中文。
已述必要更动不再赘述，说明其他顺便的更动：
  1. “符合上述译名优先顺序的使用规范”中“使用规范”像是强行宏大化的拼凑词语，改为更为实在、上文已有的字词。
  2. “其他地区的译名差异……（即“先到先得”原则）”中“先到先得”与前文连读不通，调整语序。
  3. “复数条目”可低至2，显然只有2个条目使用的地区词转换项目不宜建立相应公共转换组，故改为“不少条目”。
  4. 公共转换组不止是模板，还有模组，故去除“模板”。
— Gohan 2024年6月21日 (五) 02:06 (UTC)[回复]
我看不到这个改了什么主体。未必需要公示也可按阁下的条文直接更改。--唔好阻住我爱国（留言） 2024年6月21日 (五) 11:35 (UTC)[回复]
依据程序恐难成事，除非阁下能召集足够人数同意免除公示。或者，阁下的版本既然在“译名决定办法”章节之下几无变动，就裁去“译名决定办法”章节之后的部分，不作公示，以免被我继续反对；阁下版本剩馀的部分与我的提案（“译名决定办法”章节之后的部分）一齐或分别公示，亦互不影响效力。--— Gohan 2024年6月21日 (五) 14:12 (UTC)[回复]
删减了非公示部分--唔好阻住我爱国（留言） 2024年6月21日 (五) 17:05 (UTC)[回复]
仅通知管理员@Ericliu1912实行移动手册。--唔好阻住我爱国（留言） 2024年6月25日 (二) 10:38 (UTC)[回复]
即刻起公示此案（“译名决定办法”至文末的条文）7天。— Gohan 2024年6月29日 (六) 08:26 (UTC)[回复]
(＋)支持--唔好阻住我爱国（留言） 2024年6月29日 (六) 10:09 (UTC)[回复]
@神秘悟饭:
It’s time--唔好阻住我爱国（留言） 2024年7月6日 (六) 11:12 (UTC)[回复]
公示期满，修订通过。（您亦可宣布通过）--— Gohan 2024年7月6日 (六) 12:40 (UTC)[回复]
点都要要知会你一声/无论如何也要让你知道 ，因为是你发起的。--唔好阻住我爱国（留言） 2024年7月6日 (六) 14:03 (UTC)[回复]
Wikipedia:命名常规 (电子游戏):
提议条文

请在命名条目时遵守维基百科:命名常规。

而 维基百科:命名常规 (日本小说、漫画及动画条目)则公示@神秘悟饭蓝框版本--唔好阻住我爱国（留言） 2024年6月25日 (二) 12:05 (UTC)[回复]

与“电子游戏”命名常规的补充

在翻阅Wikipedia:命名常规 (电子游戏)时，里面有一句“请在命名条目时遵守维基百科:命名常规和Wikipedia:命名常规 (日本动漫游戏条目)”，但考虑到现在的修订已经不覆盖电子游戏范围，并且类似的讨论已经提及过（Wikipedia_talk:命名常规_(日本动漫游戏条目)#提请标题改为Wikipedia:命名常规_(动漫游戏条目)）。所以追加认定现状，就是Wikipedia:命名常规 (电子游戏)不再保留“遵守Wikipedia:命名常规 (日本动漫游戏条目)”的部分，并且本规则命名改为“Wikipedia:命名常规 (动漫条目)”或者“Wikipedia:命名常规 (日本ACN类附注：“动漫”也行条目)”（前者一个名称会涉及扩大范围）。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月25日 (二) 10:04 (UTC)[回复]

新标题已被公示记录了。
—
公示版本
标题：维基百科:命名常规 (日本小说、漫画及动画条目)（NC:ACGN）--唔好阻住我爱国（留言） 2024年6月25日 (二) 10:40 (UTC)[回复]
那就仅补充调整Wikipedia:命名常规 (电子游戏)的描述则可了。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月25日 (二) 11:09 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

议程3:管理员改名工作进度

目前，本提案2个议程已获得通过，但隔了两个星期，管理员还未执行重新命名工作，相关申请已在WP:管理员布告版提报。此讨论将继续维持，直至管理员完成此工作。--唔好阻住我爱国（留言） 2024年7月6日 (六) 14:24 (UTC)[回复]

有关维基百科:高风险主题中回退限制的修订意见

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

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

在此讨论中，桐生ここ建议：“我觉得应该修改高风险主题相关方针，确立一个原则，就是0RR不能长期使用，就像IP不能永久封锁一样。”
我认为这有一点道理，故建议修改维基百科:高风险主题中回退限制：

现行条文

管理员可对特定页面实施回退限制（如回退不过一或回退零容忍）

提议条文

管理员可对特定页面实施回退限制（如回退不过一或回退零容忍[a]）

  1. ^ 必须加上非永久执行期限

不知大家意见如何？--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的！ 2024年6月9日 (日) 08:32 (UTC)[回复]

不建议强制限定必须加上期限，毕竟方针的说法是理想的情况下所有的条目都应该是0RR。建议把强制性质改为建议性质。Sanmosa Snipe–Clam Grapple 2024年6月9日 (日) 13:19 (UTC)[回复]
你说的理想情况是自愿实行，维基百科:高风险主题说的是管理员按这方针强制执行，两者不一样。--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的！ 2024年6月9日 (日) 15:26 (UTC)[回复]
然而无可否认的是如此修订方针将会起到从根本上否定理想情况的效果。此外，我不认为你能保证未来完全不会有需要不限期实行的0RR。Sanmosa Snipe–Clam Grapple 2024年6月9日 (日) 15:44 (UTC)[回复]
如有就到时再改（要求保证本身还是一种WP:BALL），实际上，由回退不过一、到回退零容忍、到永久回退零容忍都需要时间，管理员也可以局部封锁/页面禁制/主题禁制某些长期编辑战者，故“需要不限期实行0RR”是极端假设（本来我想建议高风险主题0RR最长一年，为争取支持而最后放弃）。--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的！ 2024年6月9日 (日) 16:32 (UTC)[回复]
现行条文

管理员可对特定页面实施回退限制（如回退不过一或回退零容忍）

提议条文

管理员可对特定页面实施回退限制（如回退不过一或回退零容忍[a]）

  1. ^ 回退零容忍通常不应该为永久限制

建议可以修改一下用词。--桐生ここ★[讨论] 2024年6月9日 (日) 18:35 (UTC)[回复]

比较赞同这个版本的写法。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 02:29 (UTC)[回复]
反对修订，提案人对“不限期”有明显错误的理解。请@Cmsth11126a02搞清楚“永久”跟“不限期”的分别。高风险主题没有“永久”限制，只有“不限期”限制，而现在在各方针逐渐淘汰“永久”一词的同时不应继续继续加入“永久限制”等本身就不符合方针解读的用词。“不限期”0RR意旨“不知道什么时候才能停止一切编辑战行为”而不能单纯通过任意时间阻止后续的编辑战，而不是“不管编辑争议是否停止也继续”。
根据WP:CTOP#修订或撤销编辑限制，任何高风险措施都能由执行管理员或共识在任何时候解除，由管理员自行实施超过一年的限制也能由任何管理员解除。如果0RR已不适用，直接按方针指明的程序解除限制即可，根本用不著刻意加注释。--路西法人 2024年6月10日 (一) 03:59 (UTC)[回复]
0RR跟全保护并不相同，全保护完全剥夺一般编者的编辑权，0RR仅是要求回退前先行讨论获取共识，并不阻止编者编辑，“极端措施”说著响亮，但根本就不“极端”，尤其在社群认定有高的编辑战风险的主题中，实施更严格措施直至合理相信不再有编辑战行为更是不能称作“极端”。--路西法人 2024年6月10日 (一) 04:03 (UTC)[回复]
@LuciferianThomas：还请你说明一下你反对的是否包括桐生ここ的提议。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 04:22 (UTC)[回复]
在我眼中两人的提案毫无分别，“永久限制”一概念已有明显错误。--路西法人 2024年6月10日 (一) 09:14 (UTC)[回复]
如果只是字词使用不当的问题，那修正相关字词就是了：
现行条文

管理员可对特定页面实施回退限制（如回退不过一或回退零容忍）

提议条文

管理员可对特定页面实施回退限制（如回退不过一或回退零容忍，惟后者一般不会不限期实施）

这种写法说明了0RR的限制一般不会不限期实行，但如果有确实需要不限期实行0RR的情形，条文本身不禁止如此作为。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 10:35 (UTC)[回复]
换了字眼仍然是对“不限期限制”的错误理解。换了字不代表就对了。任意选择的限制期间能保证结束后不再有类似的长期或严重编辑战行为？相反，主题在短时间内解决争端后，就算是不限期限制，不也可以请求解除？“不限期”不是“不能被撤销”，只是“不会自动解除”。0RR措施本身不限制对条目的善意更新，亦没有可预见的滥用可能，甚至实施了也不会有任何负面影响，根本没有限制的原因。上面用户提出“极端措施”的说法跟“不限期封锁比有限期封锁更‘重’”一观念是同样错误，“不限期”是确保问题解决才解除，“有限期”反而是不论情况是否有改善都自动解除，显然没有解决问题。--路西法人 2024年6月10日 (一) 13:05 (UTC)[回复]
你维的不限期事实上是永久，没有人去申诉，管理员会自己主动看情况撤销吗？--桐生ここ★[讨论] 2024年6月10日 (一) 17:18 (UTC)[回复]
如果你认为“没有人去申诉”是问题，那么为什么不是去鼓励申诉，而是去管制不限期呢？--路西法人 2024年6月12日 (三) 03:28 (UTC)[回复]
申诉也会让后来处理的管理员觉得“我这样撤销了，会不会驳了前面管理员的面子”，你看有几个不限期能申诉成功？而0RR意味着编者要走在钢丝上，可能没有回退的意思，但就不小心触犯了，如果是1RR还有一个缓冲。--桐生ここ★[讨论] 2024年6月10日 (一) 17:22 (UTC)[回复]
申诉也会让后来处理的管理员觉得“我这样复原了，会不会驳了前面管理员的面子”，至今未曾有同样例子，管理员解除其他管理员实施的不限期封锁案例众多，从来没人觉得这样是会下了他人的面子。反而更多出现执行管理员不同意解除但最后还是解除了的不限期封锁，你说的情况连“事实上”都不符合，纯属臆测。
1RR的措施不是给“缓冲”用，实际情况是在回退他人编辑后才发起讨论（仍然不是良好的编辑态度），而不是0RR鼓励的先发起讨论再回退。况且，0RR“不小心触犯了”还可以被警告、还得获明确告知限制才会构成触犯，并不是触犯了就一定是直接封锁，缓冲本来就存在。下面回复你的留言的时候已经叙述。--路西法人 2024年6月12日 (三) 03:37 (UTC)[回复]
建议修改至“设置不限期／永久回退零容忍的管理员需(定期)检视及在公示版说明检视结果。”
注：管理员的任何管理行动需向共识交待，而且管理员需要证明该事件只有回退零容忍才能解决问题，定期主动检视正正可以让其他编辑者知道管理员有持续关注此事。--唔好阻住我爱国（留言） 2024年6月10日 (一) 05:07 (UTC)[回复]
(＋)支持设置不限期／永久回退零容忍的管理员需(定期)检视及在公示版说明检视结果。防止不限期变成实际上的永久，以及做出决定之后就撒手不管。--桐生ここ★[讨论] 2024年6月10日 (一) 17:34 (UTC)[回复]
Wikipedia:高风险主题#申诉及复核中已有复核机制以修改对条目的限制措施，未见必要。--Mys_721tx（留言） 2024年6月10日 (一) 06:59 (UTC)[回复]
@Mys_721tx：这样说吧：一般性地实行作为限制措施的不限期0RR是否有违比例原则？我不是不信任复核机制，但我认为可以通过更细致的规范来避免用户不得不触发复核机制。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 10:35 (UTC)[回复]
说出“不得不”就完全证明你对“不限期”的理解完全错误。问题解决就可以随时提出解除限制，这从来不是“希望避免”或“需要避免”、不是“不得不”（不情愿）触发的机制。--路西法人 2024年6月10日 (一) 13:09 (UTC)[回复]
@LuciferianThomas：我的用词或许不够precise，但我的出发点是管理员有可能错误判断问题的严重程度（也就是说有些不限期0RR从一开始就不应该设置），这就是我说的比例原则问题，而这与问题在何时得到解决无关。如果你为了我用词的问题而忽略我背后的出发点的话，那你就是在因人废言了。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 13:19 (UTC)[回复]
我已经很清楚论述，0RR不是一刀切禁制回退，而是要求回退非破坏编辑前先行获取共识。“通过回退去回应编辑争议”本来就不属于用户的“权利”，用户并无任何被侵犯、限制的权利，完全不违反比例原则。如果管理员错误判断问题的严重程度，那就直接走共识或跟管理员交涉更改措施啊，如果是“错判”问题的话，那么应该处理的就是错判的问题，经申诉、复核修改实施的编辑限制，这个情况下改方针是毫无意义的啊。
“因人废言”：不考虑说话者的言论是否合理，只因其身分、品貌不合己意就不采纳其意见。指的是人身攻击的言论，我并没有发表针对你人身的言论，而是指出你的理解错误，正是针对你背后出发点已经存在错误这一点去回应。我现在要再次指出你的发言中对“因人废言”存在观念错误，并必须指出你指控我“因人废言”属于诽谤，请为你的不当发言道歉。--路西法人 2024年6月10日 (一) 15:43 (UTC)[回复]
我认为不应该长期使用0RR的原因并非阁下所说“通过回退去回应编辑争议”，而是编者可能没有回退的意思，但在编辑过程中可能修改了别人的内容，造成非主观意愿上的回退或其他人眼中认为参与了编辑战，造成不自觉的违反了0RR，然后招致封禁。和意图利用回退进行编辑战是不同的。如果长期使用0RR，意味着编者永远走在钢丝上，可能为了怕违反0RR，直接就不参与编辑了。而如果是1RR则有一个缓冲，让人放心，即使不小心搞错了还有一次机会。--桐生ここ★[讨论] 2024年6月10日 (一) 17:32 (UTC)[回复]
“修改他人内容”并不属于回退，“有人认为”并不代表“确实违反”；仅有。另，依据高风险主题方针的机制，用户需获充分告知编辑限制措施，才会因违反而有进一步管理行动。更何况，管理行动不代表必然即刻封锁，首犯可发警告处理（当然，有编辑战前科的用户可能会被直接封锁）。还有，0RR正是鼓励对内容有异议时不要迳自编辑，而是先与其他用户商讨，确认有共识再改，有共识的回退显然不构成0RR的条件。这么多缓冲条件还不够？--路西法人 2024年6月11日 (二) 12:42 (UTC)[回复]
如果你能确保所有管理员都能做到不把“修改他人内容”认定为回退的话，那你这里说的话我愿意相信三分。此外，WP:编辑战#豁免情况并没有提到“有共识的回退”属于豁免情况，你说的“有共识的回退显然不构成0RR的条件”似乎没有方针的明确支持。Sanmosa Snipe–Clam Grapple 2024年6月11日 (二) 14:07 (UTC)[回复]
编者未能商定页面内容而反复删改或复原对方编辑的行为称为编辑战，经讨论共识商定页面内容就已经不构成编辑战中删改或复原他人编辑的情况。下面一边说要看方针的原则，却连编辑战最基本的构成原则都忽视了，这是什么说话态度？--路西法人 2024年6月11日 (二) 15:30 (UTC)[回复]
我说的是practical的执行情形。当然，我并不鼓励你冲红灯。Sanmosa Snipe–Clam Grapple 2024年6月11日 (二) 16:21 (UTC)[回复]
空口无凭的说辞真的显得非常软弱无力。实际运作上任何管理员不能也未曾有案例将“已经达成共识而撤销他人编辑”视作编辑战。--路西法人 2024年6月12日 (三) 03:57 (UTC)[回复]
从你上面的回应来看，你可以说是完全没有正确理解我提到的出发点（既然如此，那你确实算不上“忽略”我的出发点，也从而算不上“因人废言”了），我说的是“从一开始”来避免错误判断的发生，而不是错误判断的事后处理，事前与事后两者在性质上还是有很大的不同的，夸张一点说，这可以类比成事前选择安全性行为与事后发现怀孕然后选择堕胎的分别。此外，我认为桐生ここ的意见有一定的合理之处，你完全没有考虑到不限期0RR可能引申的副作用，毕竟practical的实行状况还是很重要的。还是说你觉得我说的“副作用”实际上也是“作用”？那只能说我跟你对0RR的理解有著重大差别，而这种重大差别并不能从任何意义上理解成“观念错误”。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 22:29 (UTC)[回复]
建议性质的限制显然不能“从一开始”解决问题，“建议”的措施往往形同虚设，在真的要用的情况下还能被拿出来说嘴阻挡。这是我在多个讨论都明确说过的。而在这个情况下，0RR也不适合被限制可以维持多久，这是目前提案的核心修改，在我针对提案方对“永久”和“不限期”等词汇存在错误理解经已回应（不限期比有限期更严重观念错误）。提案方到底是在提出限制使用0RR还是限制0RR时长？我在针对提案核心“时长”问题提出驳论，提案方给我扯去0RR作用干嘛？更何况，这里所说的“副作用”是忽略机制已经存在的其他缓冲条件（警告、明确告知编辑限制等）的说词。我反对的是限制措施时长，你要规定管理员在针对违规事例的处理手法（要求先行对首犯编辑战者警告、明确告知回退界线、告知应先获取共识，再犯才封锁），我是完全不反对。--路西法人 2024年6月11日 (二) 12:56 (UTC)[回复]
“建议性质的限制显然不能‘从一开始’解决问题”倒不一定，虽说我承认大部分情况下确实如你所说的一样，但是这次的情况不一样。在没有现在这里提议的“建议性质的限制”的情况下，VPO那边依然有相当数量的用户认为法轮功主题的不限期0RR有不妥当之处，由此可见社群机制已经初步形成不能轻易实行不限期0RR的普遍观点，将这个观点明文化有助于社群在提议实行不限期0RR时先三思，以及在管理员计划实行不限期0RR时起监督、检视之效。
我就再拿上面提到的安全性行为与堕胎的分别来说明吧，在我看来你这里的观点可以类比成反对提倡安全性行为，具体的理由则可以类比成认为提倡安全性行为的效果是“形同虚设”的，并且认为提倡安全性行为是部分人对性教育的“错误理解”，以及认为警告意欲进行不安全性行为者与告知意欲进行不安全性行为者进行不安全性行为的风险能足够避免进行不安全性行为的风险。我倒不是说我类比出来的观点是十恶不赦的，但我个人对于你就0RR的观点与我类比出来的观点都同样抱持著不认可的态度。
WP:何谓忽略所有规则#何谓“忽略所有规则”也有特别提到“规则的精神高于规则的言辞”，由此可见真正重要的其实是文字背后的实际含义，而不是文字表面上的含义，如果文字表面上的含义与背后的实际含义并不对应的话，修改表面上的用辞实际上无济于事。要是你真的觉得规则文字表面上的含义特别重要的话，你优先做的应该是让规则文字表面上的含义成为新的实际含义。
Sanmosa Snipe–Clam Grapple 2024年6月11日 (二) 13:57 (UTC)[回复]
那边的讨论是“不实施”0RR，这个提案是“限制0RR实施时长”，我针对的是提案中“限制实施时长”的说法，也是明确各方针中“不限期事实上不是永久”，而是在适当时候才提出撤销措施，不能接受任何“不限期等于永久”的扭曲观点。在封锁方针及实行上，不少案例在有限期的编辑限制后仍无改善，只能通过搞事和封锁的轮回处理，而现今开始有管理员实践“不限期不等于永久，在能表现改善态度后即能解封”的“不限期不是永久”原则，该等情况下起码能尽可能确保问题解决才撤销编辑限制，而非任意在问题未解决就自动解除编辑限制，然后无限出现扰乱及限制的轮回。这个本来就是原则。
更可笑的是，本地版本的高风险主题就是我推的。我所指出的都是高风险主题方针和机制本地版本设计时的基础原则，Sanmosa却完全无视我引入机制时的“规则的精神”，说辞仿佛好像比我还更清楚我自己写的内容和方针机制的设计，然后把他自己全新诠释的观点视作“规则的精神”。并非只有我才能诠释我的条文，但起码要尊重一下引入方针者指出引入规则时的想法和精神吧？强硬把不符合规则本身精神的观点强加于规则之上，然后将其称作“规则的精神”，这跟阅读理解卷子问“作者写这文章时的心态是什么”连作者都不同意标准答案有啥分别？--路西法人 2024年6月11日 (二) 15:47 (UTC)[回复]
我感觉我跟你关注的点并不一样，我很难认为这样的讨论如此持续下去能有甚么建设性的成果，毕竟我自己现在并不是不推进此案不可的情形，这方面的讨论不如到此为止。但无论怎样说，我并不认为你能有效释除其他讨论参与者对于practical的执行方式的疑虑，如果这个问题不能解决的话，那可以预期的是就算这次的提案没有通过，此后仍然有可能会不断出现类似的提案。Sanmosa Snipe–Clam Grapple 2024年6月11日 (二) 16:16 (UTC)[回复]
你支持的提案修改的是0RR的时长，而不是整体限制0RR的使用。限制0RR使用时长并不会解决你口中的“执行疑虑”，执行期间仍然会存在你所说的“疑虑”，不会因限制执行0RR时长而改变这一点，限制执行时长反而产生“问题未解决就自动解除措施”的新问题。提案并无实质的针对处理你口中的问题，简单来说就是你说的一切根本就跟提案无关。--路西法人 2024年6月12日 (三) 03:43 (UTC)[回复]
既然你都这样说了，那你尝试处理其他讨论参与者的意见吧，反正我也没打算继续参与这里的讨论了。Sanmosa Snipe–Clam Grapple 2024年6月12日 (三) 06:38 (UTC)[回复]
这种限制是不是不应该明文写出，而应该经由实际操作形成惯例？不过若社群有共识，仍然可以写。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月10日 (一) 18:44 (UTC)[回复]
同意桐生ここ的“不限期事实上=永久”意见，只考虑不限期的字面意思而无视中维事实往好的说是官僚主义，往坏的说⋯⋯（我不说了，毕竟要AGF）--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的！ 2024年6月11日 (二) 13:33 (UTC)[回复]

离题

根据WP:INDEF，
不限期封锁是指无失效时限的封锁，通常用于防止严重扰乱维基百科正常运作的行为或严重违反维基百科方针指引的行为。不限期封锁或适合用以阻止持续的不当行为，但仍需注意同样不是作惩罚之用。 参见：Wikipedia:不限期不等于永久 另需注意“不限期”不应理解为“永久”，即不代表该封锁永恒不可变，而仅代表未有订立封锁时长，封锁不会自动过期解除。被不限期封锁的使用者在合适的情况下可获解除封锁，并在让其被观察的情况下继续编辑，以确保该使用者未来不再违反维基百科的不同规范。但在特别严重的情况下，如无管理员愿意解除封锁，该使用者实际上已被社群禁止编辑。

建议WP:0RR可以参照WP:INDEF统一“不限期”用法，连同新增上方提及的“持续审视”方案。 以上！--唔好阻住我爱国（留言） 2024年6月11日 (二) 14:31 (UTC)[回复]

反提案

LuciferianThomas版本

上面提案方对“永久”的理解错误已经使提案不能被采纳，但限缩0RR使用的观点也是有道理。就此提出反提案，以对方针用词的正确理解去修订回退限制的描述。

§ 标准措施 §§ 回退限制

现行条文

管理员可对特定页面实施回退限制（如回退不过一或回退零容忍），此对所有编辑该条目的用户均有效；管理员亦可对经常涉及编辑争议的个别用户实施同类回退限制，以此阻止编辑战，同时鼓励其优先以沟通处理争议。

提议条文

管理员可对特定页面或个别用户实施回退限制（如回退不过一或回退零容忍），鼓励用户优先以沟通处理争议，避免编辑战延续。任何用户编辑已实施此编辑限制页面时均需遵守回退限制。社群及管理员仅应在页面编辑者持续未能在回退前试图以讨论解决争议的情况下对页面实施回退零容忍。

§ 时长

现行条文

高风险主题的编辑限制可由管理员自由裁量，设为任何时长以至不限期。

提议条文

高风险主题的编辑限制可由社群及管理员自由裁量，设为任何时长以至不限期。社群应在问题解决后主动提请复核编辑限制，确认问题解决后即应放松以至撤销编辑限制。管理员可以依复核程序主动复审编辑限制，并应在接获申诉时积极依程序处理。

--路西法人 2024年6月13日 (四) 06:50 (UTC)[回复]

(＋)支持U:LuciferianThomas的Counterproposal。--CaryCheng（留言） 2024年6月13日 (四) 09:56 (UTC)[回复]
还行。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:42 (UTC)[回复]
听上去还行。--YFdyh000（留言） 2024年6月14日 (五) 14:17 (UTC)[回复]

Cmsth11126a02版本

(－)反对：这不能解决桐生ここ的“不限期事实上=永久”，延长及重新确认限制一段说其他管理员可以“在限制生效一年后，延长或重新确认其认为需要维持的原有限制”，但如没有其他管理员作任何行动就会维持现状（加上桐生也说过：“我这样复原了，会不会驳了前面管理员的面子”）。因此我建议：

§ 时长

现行条文

高风险主题的编辑限制可由管理员自由裁量，设为任何时长以至不限期。

提议条文

高风险主题的编辑限制可由管理员自由裁量。

§ 延长及重新确认限制

现行条文

任何第三方管理员（包括原执行者）均可在限制生效一年后，延长或重新确认其认为需要维持的原有限制；更新限制的管理员将被视作该编辑限制的执行者。

社群共识针对特定页面实施的编辑限制不适用此程序。

提议条文

任何第三方管理员（包括原执行者）均必须在限制生效满一年前，更新其认为需要维持的限制，否则限制将在生效满一年后失效；回退零容忍限制更新前需要确认社群共识；更新限制的管理员将被视作该编辑限制的执行者、更新限制的时间将重新计算时限。

社群共识针对特定页面实施的回退不过一限制不适用此程序。

以上没有禁止一直实行回退零容忍限制，而是要求最少每年让社群确认一次回退零容忍限制是否需要继续，以增加透明度。--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的！ 2024年6月15日 (六) 05:40 (UTC)[回复]

标记删除条文及新增条文。--CaryCheng（留言） 2024年6月15日 (六) 11:44 (UTC)[回复]
(－)反对：管理员人数少，社群成员人数多。还是别要求管理员主动记得处理这些限制，而是让社群成员在时间到了之后申请解除限制，再由管理员排案处理。--CaryCheng（留言） 2024年6月15日 (六) 11:52 (UTC)[回复]
反对阁下的反对。现时维基理论上有60多位管理员，而高风险主题目前只有10个，阁下的忧虑仅源于管理员不作为。--唔好阻住我爱国（留言） 2024年6月16日 (日) 02:25 (UTC)[回复]
  • 咦??反对我的反对??
  • 管理员不作为??我没记错的话，现在的情况就是活跃的管理员不足，积压的工作则是爆炸多，就算高风险主题只有10个，活跃的管理员还是做不完吧...
--CaryCheng（留言） 2024年6月17日 (一) 14:20 (UTC)[回复]
主要是社群的推力太大，中文维基百科社群没什么吸引力，基于热情而开始编辑的使用者（包含管理员）经过一段时间热情完全消退后，社群也没有给予动力再继续，加上互助客栈的讨论品质时常不是很好，讨论时用户之间常常针锋相对，让人更不想参与，长久下来是推力大于拉力，人变得越来越少，这是我所观察到的现象。
中文维基百科很多问题不是单一原因造成的，是种种问题累积下来产生的结果。 (--~~Sid~~ 2024年6月17日 (一) 16:26 (UTC)[回复]
同意。--CaryCheng（留言） 2024年6月19日 (三) 15:42 (UTC)[回复]
（就Cmsth11126a02的counter-counter-proposal而言）我在下方AARV的讨论里提过引入类似助言（日语：助言）的机制，我认为高风险保护或许可以以同样的方式办理，这里以“有共识后再执行”来处理“管理员独自判断”的潜在弊端与下面AARV的情况一样存在一定程度上不符比例原则的问题。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 13:50 (UTC)[回复]
(－)反对因对不限期的原则及复原原状的实际情况存在错误理解而发起的提案。不限期并非事实上等于永久，近期管理员多了执行不限期封锁，并在问题解决的情况下获得解除，不但证明了“不限期并非永久”，更是证明了不存在“会不会驳了前面管理员的面子”。提案人并无任何例子证明“有管理员会觉得撤销其他管理员操作是会驳了前面管理员的面子”，反而是大量的解除封锁操作反证这个情况毫不存在，即使执行管理员不同意，还是会有管理员出面解封的情况。Cmsth11126a02的提案是毫不必要地增加管理员的工作量，且严重忽略了高风险主题本质上就是“已知长期存在扰乱编辑”的主题才导致有不限期编辑限制的需求，而单纯基于其自己认为社群不愿意提出复核（事实上社群经常且非常愿意质疑管理员操作）而作出扭曲“不限期”本意的提案。高风险主题的原意就是在这些高扰乱风险的主题上容许管理员更大程度上严格实施编辑限制，堵截持续已久的扰乱行为，此提案的唯一效果并非“保障”编辑权限，而是导致高风险主题赋予管理员在局部主题上更高执行权力的意义全无。--路西法人 2024年6月20日 (四) 02:49 (UTC)[回复]
(？)疑问-在下以为，以前维基百科的方针明确、对管理员的说明责任条件要求。在下建议要注意，新订方针，例如高风险主题方针、修改方针，不宜模糊、过多由管理员权力，容易出现主观等问题。Wetrace欢迎参与WP人权专题 2024年6月30日 (日) 03:14 (UTC)[回复]

LuciferianThomas版本公示

原提案因观念错误无法继续推进，而Cmsth11126a02后来的反反提案未获任何支持且有多人反对；针对2024年6月13日 (四) 06:50 (UTC)发布的反提案的唯一反对意见仍是以推进， 公示7日，2024年7月10日 (三) 02:03 (UTC) 结束。--路西法人 2024年7月3日 (三) 02:03 (UTC)[回复]

我不认为counter-proposal有具足WP:共识#什么是共识所指明的“和重要少数的意见作出适当妥协”，因此容许我程序性反对公示counter-proposal。将讨论串中超过一半的讨论以“观念错误”之名打成非正当合理的意见显然并非正当合理的做法。Sanmosa 蚌埠 2024年7月3日 (三) 23:34 (UTC)[回复]
同意Sanmosa，他的“观念错误”理由是方针原文是他写的，但正是对此原文有质疑才有此讨论，这“观念错误”是循环论证（甚至不客气地说，这可能是对该方针的WP:OWN）。--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的！ 2024年7月4日 (四) 17:02 (UTC)[回复]
另外在公告栏暂停公示。--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的！ 2024年7月4日 (四) 17:06 (UTC)[回复]
选择性摘用“和重要少数的意见作出适当妥协”，而无视“共识应当考虑到所有正当合理的意见”的程序性反对显然与方针要求有所抵触。少数意见除了“妥协”外，还有“回应”的选项。对其反反提案及意见的个人留言已有清晰的回应，依Sanmosa自己写的方针注释“任何正当合理的意见（无论是否于公示前或公示后提出）若已获提案人正当合理的回应，且自该回应起计的3日后无进一步再回应，应视为该意见已解决”。若两位认定Cmsth的反对意见正当合理，只空口说“以‘观念错误’之名打成非正当合理的意见”，却完全不论证如何不构成我所指出的“观念错误”，就是“没有回应我的回驳”，又凭甚么认定我依照我自己修订的方针在当初提案时已经清晰指出的诠释来回驳其观念错误并非“正当合理的回应”从而不能视为“已解决的意见”？
再次重申反驳“不限期事实上=永久”：在多个方针内容的“不限期”均赋予社群充分的权利去就不限期措施提出复核和申诉，有权利而不用并非“事实上等于永久”而是个别用户自己的问题。多则不限期封锁能获得申诉解除、过往设立高风险主题前的多则不限期或长期保护均获得提前解除等案例均证明，这一点不论从方针基础还是实际情况均不成立，实际情况就是社群本来就有人会善用这个赋予的权利，并不存在“等于永久”的“事实”。这是原提案、对反提案的反对意见及反反提案中的观念错误、理解错误、事实错误、论证错误。
由于Sanmosa及Cmsth11126a02未能反论证其意见如何不符合我所说与方针原则及社群运作的例证事实，其程序性反对并未附有任何实际论证而无效，维持公示状态。--路西法人 2024年7月5日 (五) 02:17 (UTC)[回复]
“共识应采纳多数人的意见，并和重要少数的意见作出适当妥协”与“重大修改更应获得绝大多数的同意”是现行方针条文没错吧，“多数人的意见”在哪里？Sanmosa 蚌埠 2024年7月5日 (五) 02:42 (UTC)[回复]
认同，因是LuciferianThomas提出公示，故其应该先证明这是“多数人的意见”（而不是由反对者先证明这不是），为避免编辑战，我给其24小时，24小时后如没有这是“多数人的意见”的证明则我去暂停公示、直至相关证明出现为止。--Cmsth11126a02 (留言) 沈伯洋是被大陆国民党立委扯衣服导致头部落地的！ 2024年7月5日 (五) 02:52 (UTC)[回复]
反提案之提案人（我本人）、CaryCheng明确表明支持；Ericliu1912及YFdyh000虽未明确表明支持，也有表示认可反提案，言语上视同支持或不反对提案。针对反提案内容唯一提出实质反对意见是Cmsth11126a02，而有关说法已经论证是存在谬误的论证，经回应后视作意见已解决。Sanmosa的程序性反对基于Cmsth11126a02已被解决的意见，且并非对提案进行实则性点评的意见，依注释一规定不视作此条文所指的“新留言”与“相关意见”。
共识不是算人头，而是看论据的强弱，这是自制定方针之时已经提出的基本原则，至今仍然不会改变。Cmsth11126a02的意见连拿来论证的例证都存在事实性错误，这显然不是一个强论点，而是基本可以视作无效的论点（论点的基础并不存在）。再说，就算真的点人头了，4:1也显然是一个多数。不论是论点还是人数都是符合共识方针的要求。我在上方留言要求两位提出有效回驳我所指Cmsth11126a02的论点存在谬误，你们都完全回避掉，仅继续以不存在的程序问题拉布。若两位执意扰乱显然存在有效多数意见的提案公示，我将请求其他管理员介入。--路西法人 2024年7月5日 (五) 06:04 (UTC)[回复]
正如我此前所言，我感觉我关注的点跟你并不一样，而我重看一次整个讨论串后，我认为Cmsth11126a02、桐生ここ等人关注的点也跟你并不一样。这里一直抓着“不限期”与“永久”的关系不放，而不尝试处理有人认为“不限期”事实上等同于“永久”的背后成因的处理相当诡异，而且令这个讨论串俨然成了两个相互独立而被强行放在一起的讨论串。说白些，你对着他们两位（和当时的我）就有如对牛弹琴一般，我不认为对牛弹琴能从任何意义上被认为是“合理回应”。Sanmosa 蚌埠 2024年7月5日 (五) 06:52 (UTC)[回复]
有人认为“不限期”事实上等同于“永久”不等于这就是事实，而事实例证证明事实并非如此，这已经足够回应。我一直都是在回你方之观点，只是你一直不觉得我在回，不等于我没回。对牛弹琴比喻对不懂道理的人讲道理（wikt），所以你是在说你自己不懂道理，也不愿意听吗？--路西法人 2024年7月5日 (五) 08:07 (UTC)[回复]
“对牛弹琴”也可以用于“比喻讲话、做事不看对象”（另外我相信你知道维基词典不是可靠来源，虽说你给出来的解释确是较为通用的解释就是了），你所说的“我一直都是在回你方之观点，只是你一直不觉得我在回”也有可能是你一直以为自己是在回应对方的观点，但实际上并没有，而我也没办法阻止大家（对，不止你一位）回避正视我所提到的“背后成因”的问题。平心而论，我对你的提案本身并没有意见，但我实在无法从任何意义上认为你的提案有满足“作出适当妥协”的要件，因此我提出的只是程序性反对，如果你能妥善处理“作出适当妥协”的要件的事情的话，我不反对你的提案付诸公示。Sanmosa 蚌埠 2024年7月5日 (五) 08:35 (UTC)[回复]
minor tangent: 个人一直以为“我和你讨论就是对牛弹琴”含贬义而非中性。--0xDeadbeef (留言) 2024年7月5日 (五) 08:53 (UTC)[回复]
我就针对了所谓“背后成因”指出了反例例证了，你假装看不到不是我的问题。--路西法人 2024年7月5日 (五) 23:46 (UTC)[回复]
我看了一次整个讨论串，我还是无法从你在这里说的每一句话里找到任何一句有真正回应到管理人员相关信任问题的话。在这里处理一下管理人员相关信任问题的事情就有那么难吗？Sanmosa 蚌埠 2024年7月6日 (六) 05:52 (UTC)[回复]
上方讨论提及“管理员”的留言仅围绕“管理员不愿意回退其他管理员的操作”（已有充分案例证明不符合事实）和“担忧管理员错判形势”（早前已回应有充分的申诉机制，还有四个不同的申诉途径，未来更有第五种），而从头到尾仅仅现在才出现“信任”二字套在管理员身上。你假装看不到不是我的问题。--路西法人 2024年7月6日 (六) 08:57 (UTC)[回复]
我不认为这些话有真正回应到管理人员相关信任的问题。从上方的相关讨论可见他们对于你说的那些“申诉机制”并不全然信任（补充一点：我留意到社群里对“申诉机制”的不信任是作为对管理人员的不信任的一部分存在的），我认为这是能用直觉来推断的事情，然而你却没有尝试这样做。另一方面，你也不能强制要求他们必须信任那些“申诉机制”。我不知道你会不会考虑我在2024年6月18日 (二) 13:50 (UTC)的留言里提到的助言机制，我认为这应该能足够处理相关的信任问题了，但最终是否在提案里采用这机制的决定权在你。Sanmosa 蚌埠 2024年7月6日 (六) 10:54 (UTC)[回复]
所谓“不信任申诉机制”是基于“管理员不愿意回退其他管理员的操作”的声称，既然该声称已经证明不符合事实，那么“不信任申诉机制”亦无其他论据。--路西法人 2024年7月7日 (日) 00:56 (UTC)[回复]
这样说吧：我倾向于把社群成员认为“管理员不愿意回退其他管理员的操作”理解为社群成员对管理人员的不信任的一种表现形式，而显然地社群成员对管理人员的不信任的表现形式不可能只有一种，因此就算“管理员不愿意回退其他管理员的操作”这种表现形式并不成立，这并不意味社群成员对管理人员的不信任同样地并不存在。而且，就算没有这里的讨论串，我相信社群不用脑子也能知道社群成员对管理人员的不信任是普遍存在的。Sanmosa 蚌埠 2024年7月7日 (日) 01:31 (UTC)[回复]
没有论证、论据的论点不是一个讨论或辩论中需要被考量的有效论点。凭空而来的“不信任”毫无讨论价值，因此说法毫无基础成本但可造成无限伤害。--路西法人 2024年7月7日 (日) 15:58 (UTC)[回复]
否定不信任的存在才是真正的伤害。世间上的各种制衡机制都来自于肯定／默认不信任的存在，否定不信任的存在会使本应建立的制衡机制不能建立，从而使本应被制衡者可以行使不合比例原则地大的权力。任何情况下，只要牵涉高阶权限的信任问题，都应该假定不信任的存在，直至反证成立，因此这里应该是你来论证不信任的不存在或不适用，而非其他人来论证不信任的存在。Sanmosa 蚌埠 2024年7月8日 (一) 00:15 (UTC)[回复]
维基百科本来就跟外面的体制不一样，我们走假定善意原则。你竟然说不是由“怀疑他人”的一方论证而是由“依假定善意信任他人”的一方论证，假定不信任就完全是假定恶意的体现，与维基百科的基本原则相悖；参与、议事心态显然很有问题。同时，我已充分论证在各场所都存在管理员适当使用复核权的情况，包括解除长期保护、解除封锁等，多数情况都没造成争议，这已充分反映社群在很大程度上信任管理员正确行使复核权；目前社群中所谓的“不信任”仅仅是个别不愿接受管理员依方针的复核结果而产生的现象，如过往行政员推翻RFDA效力等，并非行政员的做法不符合方针（即当下之社群共识），而是有人拒绝接受。--路西法人 2024年7月8日 (一) 01:40 (UTC)[回复]
我认为滥用“个别”一词并非好主意。假定善意也并非无条件、无限制的，毕竟连你也没有否认并非所有情况都没造成争议（你的用词是“多数”），社群要重建对一组人员或一件事情的信任不可能是三言两语、一朝一夕的事情。此外，当时显然不止一人认为行政员对“沟通无效”的理解有根本上的问题，对去年行政员提早中止RFDA程序的做法的不认可也显然不能被描述为“个别人士拒绝接受”。管理人员本就应该预期他们都能在有需要时为自己的一言一行作合理解释。Sanmosa 蚌埠 2024年7月8日 (一) 05:46 (UTC)[回复]
考虑到我实在没有舌战群儒的耐心，我虽则依旧维持我的程序性反对，但我不会再干预你对此公示所作的任何一切宣告，不过我也不会就任何其他人对你的公示本身及你对此公示所作的任何一切宣告所采取的行动负任何的责任。Sanmosa 蚌埠 2024年7月8日 (一) 06:05 (UTC)[回复]
（补充说明：我认为是次讨论出现有人认为“不限期”事实上等同于“永久”的情况的背后成因是社群中相当数量的成员对管理人员的不信任，故此满足“作出适当妥协”的要件的方式应该是以合适的方式处理相关信任问题。）Sanmosa 蚌埠 2024年7月5日 (五) 08:39 (UTC)[回复]
另外，我也有必要声明我的反对仅为程序性反对，而非针对任何特定提案。Sanmosa 蚌埠 2024年7月5日 (五) 07:18 (UTC)[回复]
@Ericliu1912：这是否需要管理员intervene的情形？Sanmosa 蚌埠 2024年7月5日 (五) 02:51 (UTC)[回复]
依据上次共识方针的经验，管理员介入大概也没有用，尤其本人特别不适合。看到此案例，我想你自己应可衡量共识方针所谓“正当合理意见”条款实务运用效果如何了。另外，相关方案需要社群支持，自非任何人说的就算。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月5日 (五) 04:41 (UTC)[回复]
@桐生ここ、Wetrace，我真的完全不知道LuciferianThomas他是如何“点人头”数出4:1的。Sanmosa 蚌埠 2024年7月5日 (五) 06:43 (UTC)[回复]
(？)疑问-关于Sanmosa上面提出的疑惑，是不是请LuciferianThomas能协助说明厘清？关于LuciferianThomas的公示，程序上似乎已经引起些用户的疑问？Wetrace欢迎参与WP人权专题 2024年7月7日 (日) 15:38 (UTC)[回复]
还有，Cmsth的论点真的很难以置信。当前社群正在进行（明显违反方针）的RFDA，起因正是有管理员愿意去推翻其他管理员的不限期编辑限制操作而引发（虽然后来调查后解除限制的管理员发现自己的调查确实存在问题），这已经充分证明了桐生声称有管理员可能会想“我这样复原了，会不会驳了前面管理员的面子”而不推翻前人实施编辑限制的说法完全不符合事实，我真的不知道Cmsth和桐生是活在平行宇宙还是怎样。这么重大的案例证明“管理员不会因为维护前人面子而拒绝推翻操作”，究竟是怎么能继续提出“我这样复原了，会不会驳了前面管理员的面子”这个完全不符合事实的虚幻说法作为论证。--路西法人 2024年7月5日 (五) 02:28 (UTC)[回复]
支持路西法人提案，反对Cmsth11126a02的提案。反对是因为容易被钻空子，给管理员增添不必要的麻烦。（需要每年都更新）事实上禁制没用了再取消禁制不就好了。支持是因为将复核的一半责任交给社群，不仅可以通过讨论形成解除禁制的共识还不限制管理员自行复审。不限期与永久这一议题明显有争议，而路西法人的提案经我观察对于不限期vs永久这一争论来说是没有太大关系的。0xDeadbeef (留言) 2024年7月5日 (五) 07:14 (UTC)[回复]
(？)疑问-(1)现行高风险主题的运作，最核心的议题是不是：是否确实有依照该方针，进行对条目风险的合理“论证”？(2)在下还是重申一点意见：以前维基百科的方针明确、对管理员的说明责任条件有所要求。在下建议要注意，新订方针，例如高风险主题方针、修改方针，不宜模糊、过多由管理员全权，这容易出现主观等副作用问题。会不会架空了过去的维基百科核心基础方针呢？Wetrace欢迎参与WP人权专题 2024年7月7日 (日) 15:38 (UTC)[回复]
你在回复我的观点吗？我怎么看不懂你在表达什么。--0xDeadbeef (留言) 2024年7月7日 (日) 15:53 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
循例通知：@LuciferianThomas：你似乎忘了更新{{Bulletin}}。@Cmsth11126a02、桐生ここ、Wetrace：LuciferianThomas已经迳行宣告其提案通过。Sanmosa 蚌埠 2024年7月12日 (五) 15:52 (UTC)[回复]
Special:Diff/83340332说：维基百科:不限期不等于永久是封禁方针论述，不是维基百科的核心方针或指引，未获社群广泛承认⋯⋯而LuciferianThomas的提案正是建基于“不限期不等于永久”已获社群广泛承认的前提，按照演绎推理我质疑这提案有效性。（当然如LuciferianThomas坚持这提案有效，我也不会硬碰硬，我只在此证明我质疑过）--Cmsth11126a02 (留言) 国民党的正确名称是大陆国民党！ 2024年7月14日 (日) 15:26 (UTC)[回复]

管理操作复核的议题

原标题为：提议设立请求封禁机制以及扩大AARV的使用

提议设立请求封禁机制以及扩大AARV的使用

我建议社群考虑设置类似“请求封禁”的机制，即对于非纯破坏行为，有共识后再执行封禁，而非管理员独自判断引起争议。

对于解封请求，我建议扩大WP:AARV的使用，申请人可以选择请求任何一名用户协助提出AARV，由社群进行判断封禁是否适当。

提请各位讨论，有关方针条文也请踊跃发表。--桐生ここ★[讨论] 2024年6月14日 (五) 07:53 (UTC)[回复]

Ping有对提案发表意见的人@日期20220626、ChiuHsiao1221、Shwangtianyuan、HYHJKJYUJYTTY。--桐生ここ★[讨论] 2024年6月14日 (五) 07:55 (UTC)[回复]
本人是(＋)支持，社群考虑设定类似“请求封锁”的机制，确实能解决很多不必要争议，非纯破坏行为，至于解封请求，建议扩大WP:AARV的使用，我也支持，--HYHJKJYUJYTTY（留言） 2024年6月14日 (五) 08:10 (UTC)[回复]
本人亦是倾向(＋)支持。针对某位编辑账号的封禁无异于是在维基百科范围类对某人“执行死刑”。既然现实里文明国家的死刑都有复核和救济制度，那我认为维基社群也应该考虑。除了机器人账号或纯粹破坏行为外，针对其他行为的封锁账号行为要给于“拟被封所账号者”一个申诉和申请复核的渠道。--Chiu Hsiao (✉️Message) 2024年6月14日 (五) 08:20 (UTC)[回复]
原则上同意扩大AARV，但实际执行上对社群整体正确解读及执行方针有极大疑虑。在社群本身已经存在失能、有不少用户连最基本的方针指引都愿意无视的情况下，我不认为当前的社群整体而言有足够能力作出完全合乎方针指引及背后原则理解，以此判读管理人员的管理行为是否恰当。光是社群中仍对于“不限期”错误理解为“永久”或“比其他更重”的观点（WP:不限期不等于永久才是正确理解）已经反映社群缺乏判读封锁是否恰当的能力。在多个解封案例中，多名用户未有真的分析封锁理据、没有考量方针指引要求、未有从执行人的视角去看事件，甚至只是因为跟管理人员的个人恩怨就直接提出反对，反映社群缺乏作此判断的能力。原则上AARV是一件好事，但实际需要达到的效果目标及需要的技巧跟担任仲裁员无异；而仲裁委员会都尚会是社群经选举选上去的一群人，AARV的参与社群却是未经社群检视资质的用户技能参与，粗暴点说就是平民版仲裁，跟仲裁委员会的公信力还要差个天差地别。
请求封锁有极度严重社群程序官僚化及暴民政治的风险，如同上方所述，社群整体而言本身缺乏正确判读什么情况适合或不适合封锁的能力，也往往主张采取不足以阻截扰乱编辑的措施。请求封锁涉及管理员权限，又是由谁来判读共识又是一大问题：社群本身缺乏判读共识的能力（永远只会点人头而不看论据强弱），管理员自己判读共识又产生一个会起疑的点，简单来说就是没解决任何问题，还产生了更多的问题的提案。--路西法人 2024年6月14日 (五) 09:57 (UTC)[回复]
反对引入仲裁制度的人，却提案引入一个目标近似仲裁的机制，但这机制极度取决于社群能力（惟社群已经展现其失能），却也完全没有仲裁要求的严谨。在社群缺乏有关判断能力、扭曲理解方针、无视方针原则的行为获得控制前，AARV就只是一个跟当前RFDA没分别，只会制造更多争议的体制。--路西法人 2024年6月14日 (五) 10:27 (UTC)[回复]
那这么说吧，蓝桌的调查报告很好，如果封禁非纯破坏用户前，要求管理员写一份调查报告呢？--桐生ここ★[讨论] 2024年6月14日 (五) 11:11 (UTC)[回复]
包括所有差异链接，逐条说明为什么违反方针，决定量刑多久，决定量刑的理由。如果当事人怎样做可以获得原谅和解封。或者遭不限期封禁者，多久之后提出申诉可以考虑解封。--桐生ここ★[讨论] 2024年6月14日 (五) 11:17 (UTC)[回复]
管理员在封锁理据中已经提供理由和对应的diff即可视作已提供封锁报告。如果处理每一个非破坏用户都需要这样写的话，用意是好但极度官僚，手续过多可能导致愿意处理此类封锁的管理员越来越少，反而变成放任了这些扰乱者继续搞事。不过，我是同意可以要求管理员在执行不限期封锁时在封锁讯息下写出不限期封锁的考量，并在有可预见的改善可能（即不属VOA、SPA或再次封锁的用户）情况下提供WP:不限期不等于永久的说明，并写说需要对方了解什么方针指引即可获得解封（第二次机会）。
至于详细的封锁报告，则应是在AARV或仲裁的情形下提供。惟发起AARV的门槛过低，除了担忧AARV参与者素质外，还担忧会被滥用以针对特定管理员，制造毫不必要的工作量。--路西法人 2024年6月15日 (六) 00:24 (UTC)[回复]
你维管理员封禁此类人士已经圣母到极致，若是再加调查报告这种减速带我看你维是不想请捣乱的人离开了？--0xDeadbeef (留言) 2024年7月6日 (六) 16:16 (UTC)[回复]
Wikipedia:管理员布告板/编辑争议和Wikipedia:管理员布告板/其他不当行为已经复杂到我不愿意碰了，再弄这个的话更不会没事去看了....--百無一用是書生 (☎) 2024年6月17日 (一) 02:14 (UTC)[回复]
社群针对此议题是不是讨论过不少次了？为什么我感觉几个月以前才有一次。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 12:50 (UTC)[回复]
基本上这种制度是聊胜于无，比起现在的情况肯定是利大于弊。但也要指出，管理员执行封锁操作时，理论上已经要确定当事人违反本站政策，“独自判断引起争议”可以是对管理员裁量权的事后合理质疑，但不是限制管理员行使封锁权限的前提。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 12:52 (UTC)[回复]
支持，帮助明确共识。但裁量权目前还是得有。--YFdyh000（留言） 2024年6月14日 (五) 14:24 (UTC)[回复]
理解提案的用意，乐见其成。但在实践上可能会如路西法人君所说产生更多问题，或许会造成另一个管理员布告板。明白提案及用户对管理权运用的忧虑。－千村狐兔（留言） 2024年6月14日 (五) 15:53 (UTC)[回复]
注：此留言已被原作者（User:月都）移除。
我觉得也应该探讨一下为什么管理员们不愿意碰WP:ANMWP:AN3，如果ANM、AN3都不愿意碰，再开一个AARV事实上只会让管理员的事情变更多，我想这某种程度上并没有解决问题，反而多了另一个问题，再提醒一下管理员也是"志愿者"。
社群愿意的话亦可探讨为什么管理员越来越不活跃，还有什么方法吸引管理员回来帮忙扫地，或是另外寻求一条出路解决这个问题。--~~Sid~~ 2024年6月17日 (一) 13:04 (UTC)[回复]
额外补充我并不是要反对提案，只是不希望社群设立之后却没有达到预想的效果。--~~Sid~~ 2024年6月17日 (一) 13:05 (UTC)[回复]
以“有共识后再执行封锁”来处理“管理员独自判断”的潜在弊端可能不符比例原则，我更倾向于引入类似助言（日语：助言）的机制，要求管理员在执行不限期封锁前应先取得至少一位未涉事的第三方用户的同意，以确保所有不限期封锁的执行都不违反比例原则。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 13:35 (UTC)[回复]
我认为这个方法可行。--~~Sid~~ 2024年6月18日 (二) 14:59 (UTC)[回复]
少打字，修正留言。~~Sid~~ 2024年6月18日 (二) 15:00 (UTC)[回复]
不合适。破坏者还要助言？说这是明显例外吧，但又有什么应该是例外呢？到头来还是要争吵。如此官僚主义弊病过重，我想事后复查比事前在那边极其复杂地商榷认定界线要容易得多。另外我还是要指出，理论上若管理员是依据社群讨论通过的方针与指引执行封锁，就是在确保社群共识得到实践；故除理据不清之外，通常不能说管理员“未依共识”执行封锁，至多是对方针与指引认知有争议。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 17:46 (UTC)[回复]
啊，我忘了提及“非纯破坏行为”的前设。Sanmosa 蚌埠 2024年6月19日 (三) 05:47 (UTC)[回复]
支持@Sanmosa的助言机制，这个方法应该可行。--桐生ここ★[讨论] 2024年6月20日 (四) 19:20 (UTC)[回复]
有点怀疑“未涉事的第三方用户”的评判可能出现争议，并可能使部分用户有意避嫌、延后表态（私下抱团沟通）。--YFdyh000（留言） 2024年6月21日 (五) 11:57 (UTC)[回复]
关于“私下抱团沟通”，根据WP:共识，仅建议不应私下讨论维基百科相关的事项，个人建议需更改这段的用词至严禁私下讨论维基百科相关的事项，并配合利益申报 （如该名编辑者曾在外站讨论，则应当“涉事用户”处理并应主动向社群申报），否则的话也没有意思。关于最近私下讨论的例子，就是路西法人的共识议案，完全将跳过了共识形成过程便产生共识，此不合程序公义。如果之后AARV容许私下抱团沟通，那只好反对。
.
“维基外的讨论。我们不鼓励编者在其他网站、论坛、聊天工具、电子邮件或其他本专案外的地方讨论。这些讨论在“维基内”决定共识时是不予考虑的，并在它们被揭发后会引发猜疑和不信任情绪。尽管我们需要在维基外讨论少数问题以顾及隐私，但绝大多数维基百科相关的事项都应在维基百科上讨论，这样它们将对所有参与者可见。”--唔好阻住我爱国（留言） 2024年6月21日 (五) 12:40 (UTC)[回复]
我觉得与其在客栈提案（现行写法），不如改置管理员布告板的子布告板（可命名为“管理操作复核”），集中处理涉及高阶权限的使用行为。既有之“其他不当行为”子布告板，则继续留作解决普通使用者争议之处。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月24日 (一) 01:09 (UTC)[回复]
(＋)支持。--桐生ここ★[讨论] 2024年6月29日 (六) 21:17 (UTC)[回复]
诚如书生君所言，本站处理相关问题之场所一向不缺——Wikipedia:管理员布告板/编辑争议和Wikipedia:管理员布告板/其他不当行为。所以这个与前列两者分别何在？固然多一人一起讨论如何行使权限，未尝不可。但本站有足够人手么？在下甚是疑惑。本提案立意良善，但欠缺具体系统设计。坦白说，就是怕管理员滥权，但又没有给管理员足够配套。然后，调查事情不一定要管理员权限，所以又有多少人有能力且愿意担起此责？--J.Wong 2024年7月1日 (一) 13:46 (UTC)[回复]
我只是特别羡慕ja有这个；对于解封，en有这个，看起来都是和气的达成了共识，不知道为什么在zh，最后都是客栈吵得不可开交，甚至上RFDA解决。--桐生ここ★[讨论] 2024年7月1日 (一) 14:12 (UTC)[回复]
立意就是希望大家多用AARV，最后不用走到RFDA这一步。--桐生ここ★[讨论] 2024年7月1日 (一) 14:28 (UTC)[回复]
所以这次有提出过使用吗？有空间容许第三方审核及说话的馀地吗？--J.Wong 2024年7月2日 (二) 05:46 (UTC)[回复]
其实这次事件当中是见到Bluedeck有意愿作出独立调查，但本站社群之中，竟然未见有人愿意伸出援手。
然后就去羡慕这个，羡慕那个……
纵观整个讨论，在下见到大家更关心程序，数够票就下一步，甚少理会双方所言是否在理，能否经得起第三方审核。如果这点不变，开再多讨论空间，阁下都只能继续羡慕。--J.Wong 2024年7月2日 (二) 05:57 (UTC)[回复]

将管理操作复核设置为管理员布告板的子布告板

如题，见上方讨论，将管理操作复核设置为管理员布告板的子布告板，将作为集中处理涉及高阶权限的使用行为。桐生ここ★[讨论] 2024年6月29日 (六) 21:23 (UTC)[回复]

或者是直接指定管理员布告板本身也行吧？要评估一下流量。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月30日 (日) 04:13 (UTC)[回复]
应该不行，管理员布告板本身没法提供那些AARV的规则。再说管理员布告板本身也没有人会去用，目前貌似只是一个为存在而存在的东西。--桐生ここ★[讨论] 2024年6月30日 (日) 07:32 (UTC)[回复]
其实也可说是“制造”用途⋯⋯ —— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月1日 (一) 19:21 (UTC)[回复]

电视剧演员名单序列

本主题或以下段落文字，移动自WP:VPD。执行者：路西法人 2024年6月26日 (三) 08:03 (UTC)。[回复]

年初编辑《飞常日志》时我已发起过讨论，当时因陈豪 (演员)在官方网页名列于首，维基条目无奈跟从，此剧男主角实际上是马国明，而陈豪 (演员)只是客串，均是显然易见的、无需争论（撇开拿出官方排名盲目跟从此一理由）的事实。近来留意到《巨塔之后》又出现类似争议，这次轮到马国明客串，他到底应不应列为主演。就此，我倡议不论官方或任何传媒来源，如果在演员名单排序上出现明显偏离实情的情况，维基人应该酌情讨论一个较符合实情的共识，讨论中不应再盲目依从来源（如撇除该些来源而有争议者，则可参考该些来源）。就算是官方排名，也可能是基于一些利益关系去进行排序，一些传媒来源则可能照抄官方；维基向来对自传及非独立/一手来源的中立性有所警惕，因此我认为明显不符实情的排序可视为不中立，维基人应该酌情处理，不要盲目依从，不顾实情。--Factrecordor（留言） 2024年6月18日 (二) 13:14 (UTC)[回复]

@Rastinition、Manchiu、Pyruvate、Stevencocoboy、CyrussKK1230、Ckh3111、Apple v、Tw drama、Nickice、Yau Sze Long、Bosco64、Will629、Ricky36、SeoTae、Redmi123465、Benkwokmars、Tanqrsucks、任晏延、银色雪莉：--Factrecordor（留言） 2024年6月18日 (二) 13:35 (UTC)[回复]
你好，我想大概知道发生甚么事--Tanqrsucks（留言） 2024年6月18日 (二) 13:53 (UTC)[回复]
简单来说就是如果官方（网页或海报等）的演员名单排序，把一个明显只是客串、戏份甚少的演员放得很前，维基条目是应该依从，还是撇开官方而按实情讨论。我根据以往及2024年tvb剧集编辑纪录中看似较活跃者来邀请讨论。--Factrecordor（留言） 2024年6月18日 (二) 14:15 (UTC)[回复]
？？？--任晏延（留言） 2024年6月18日 (二) 14:35 (UTC)[回复]
扬子晚报，“在《新闻女王》中有亮眼表现的马国明和高海宁，本次将继续担任主演角色。”，或许陈豪可能比较知名，算是宣传手段吧。--Kethyga（留言） 2024年6月18日 (二) 13:38 (UTC)[回复]
当时说明马国明是男主角，陈豪是客串的报道有不少，问题是Wikipedia:格式手册/电视有依照官方的演员名单排序的条文，因此便被拿出来当作金科玉律，什么都不管了。所以本次讨论我特意指出官方有不中立的时候，不可盲目跟从。--Factrecordor（留言） 2024年6月18日 (二) 14:03 (UTC)[回复]
  • | X = or ===X===
这个栏位只写入X
  • | Y = or ===Y===
这个栏位只写入Y
  • | Z = or ===Z===
这个栏位只写入Z
  • 因为<ref A>将X、Y、Z混合陈列而在第一项、第二项、第三项出现X、Y、Z任2至3项数值混合排序的状况都是异常的
  • 针对其他部分不表述。分类=分类没有疑义，排序=排序没有疑义。分类=排序的议题即使改陈述成排序=分类也同样不可能存在
--Rastinition（留言） 2024年6月18日 (二) 14:27 (UTC)[回复]
从列明来源，非原创研究，中立观点等角度，按官方名单没错，也撇开不必要的责任。
纠偏纠错要有其他可靠的非数据来源，加入正文或注释。依赖数据会催生奇怪结论，如角色A的出场时间更多所以该放在B的前面。--YFdyh000（留言） 2024年6月18日 (二) 14:41 (UTC)[回复]
接在YFdyh000后方的原因是我懒得编辑原始码。但仍大略依YFdyh000提及的文字作为开头叙述，以我看过的现象，比较少出现角色A的出场时间更多所以该放在B的前面。的情形。
  • 较常看到的状况是资讯框的 |主演= 使用来源后，没有完整列出主演，却依照来源排序将"非主演"列在主演中
  • 首段较常见的状况是将|主演=的栏位资讯重新复制贴上再增加一些叙述，因为有叙述所以通常也会将来源中的分类用散文形式补上
  • 演员名单或演员表的情形较常见的状况是将|主演=的栏位资讯重新复制贴上后重制成表格，预留一个关系的栏位插入异常复杂的谁是谁'的谁"资讯
  • 通常经过上面的过程，单一个条目可以连续看到近乎完整的三次演员名单，用3种不同表现方式呈现。(...) 吐槽演员名单连续列明三次，这或许可以称为演员名单炸弹。
  • 第一项通常包含列出的资讯不准确问题(包含不是主演的对象)。第二项因为首段必定散文化，是最没有问题的。第三项问题很复杂，这牵涉到是否针对演员的性质/角色/剧情分类，因为涉及分类就必定不可能完全按照官方排序陈列。仅有一个情形例外，仅在将性质也列入排列对象时成立。但如果官方名单排序并未经过分类的打散排序时，例外也不存在。
总结为了排序这个目标而排序又希望排序完整，比较可行的位置是首段。但为了可行而刻意每个页面都生成3组演员名单，是否有这个必要也需要考虑。(～)补充我提出的质疑是为了排序而排序，不太可能写出像en:House_(TV_series)(剧情分类式写法)这种品质的页面，从目标或构成结构的角度都不一致--Rastinition（留言） 2024年6月18日 (二) 15:41 (UTC)[回复]
维基百科对演员的排名不等同对主配的认定。依据官方名单比较省力便捷，依据实情或多方来源则众说纷纭、莫衷一是、费时费力。如有多份官方名单排名不同，可以第一产地的海报为准。不过，若对单一作品达成强共识，或许可豁免官方名单的规限。此外，戏份居次亦有可能是最为重要的灵魂人物。--— Gohan 2024年6月19日 (三) 03:01 (UTC)[回复]
我觉得大部分情况下依从官方是可以，但总有些不寻常的情况，“单一作品达成强共识，或特许豁免官方名单的规限”大概就是这个原则。--Factrecordor（留言） 2024年6月19日 (三) 08:05 (UTC)[回复]
个人认为这个议题是没有讨论空间，因为已成文指引Wikipedia:格式手册/电视#演员及角色资料已解答阁下的疑惑。--唔好阻住我爱国（留言） 2024年6月20日 (四) 11:18 (UTC)[回复]
请问阁下是不是希望修改此部分条文？如是，请移动此讨论至方针区。--唔好阻住我爱国（留言） 2024年6月20日 (四) 11:21 (UTC)[回复]
好的，我不熟悉移动模板，有足够精神时再处理。--Factrecordor（留言） 2024年6月25日 (二) 15:58 (UTC)[回复]
@Rastinition君的意见更为复杂，我先提案有条件豁免遵从官方序列的规限。--Factrecordor（留言） 2024年6月28日 (五) 16:06 (UTC)[回复]
@Factrecordor你在你的留言下方回复后提到我的意见，如果你是希望我回复你或者困惑为什么我没理你，那是因为你提出提案提出的议题/问题情境在对象页面不存在，更精确的说法，巨塔之后这个页面的问题我在更早前的留言已经尽量简短叙述，如果没理解实际问题或认为是离题或复杂到不能理解，@Factrecordor不用勉强自己理解，而且这与你的提案本身无关。(提案根据不存在的议题，实际发生的状况和提案无关，针对状况的发言与提案本身会离题是自然现象)。Fake性质议题。如果看前后条文，也能发现只是新增一段废话。上述废话是相对礼貌性说法，较不客气的说法，这是扭曲@神秘悟饭原意后将他的发言转换成新的条文--Rastinition（留言） 2024年6月28日 (五) 23:18 (UTC)[回复]

正式提案

现行条文

演员与角色讯息（含信息框中的主演栏）一般可以正式官方网站公开发布讯息收录，若编者因对于作品之可靠官方来源选择或判定不一，或因其他理由，导致对于演员排序认定歧异，则依序以下列来源为依据：

  1. 影片中完整的演职员表（如片尾演职员表或片中的跑马字幕），若影片是依出场顺序排序则不适用。
  2. 影片片头的演职员排序，若影片是依出场顺序排序则不适用。
  3. 官方海报的演员名单排序。
  4. 官方网站的演员或人物介绍排序。
  5. 其他官方发行产品上的演员名单（如相关刊物、影音产品包装等其他多媒体）。
提议条文

演员与角色讯息（含信息框中的主演栏）一般可以正式官方网站公开发布讯息收录，若编者因对于作品之可靠官方来源选择或判定不一，或因其他理由，导致对于演员排序认定歧异，则依序以下列来源为依据：

  1. 影片中完整的演职员表（如片尾演职员表或片中的跑马字幕），若影片是依出场顺序排序则不适用。
  2. 影片片头的演职员排序，若影片是依出场顺序排序则不适用。
  3. 官方海报的演员名单排序。
  4. 官方网站的演员或人物介绍排序。
  5. 其他官方发行产品上的演员名单（如相关刊物、影音产品包装等其他多媒体）。
  6. 若有编者对单一作品的官方序列提出合理质疑，可发起讨论。此讨论应参考更多官方以外可靠来源的演员序列，及对个别角色的戏份、演出性质之描述。若达成强共识，可豁免遵从官方序列的规限。

--Factrecordor（留言） 2024年6月28日 (五) 16:02 (UTC)[回复]

可能要重点说明相关演艺人员的名气是不影响演员序列。举例以“香港顶流”炎氏作例，倘若他在节目只有一句话，不应因为名气而把他置顶。--唔好阻住我爱国（留言） 2024年6月28日 (五) 16:36 (UTC)[回复]
(－)反对增列的内文基本是根据其他帐号发言，加入了原发言者未提及的文字
  • 句子应该精简后改成若对单一作品的官方名单有合理质疑，可发起讨论。讨论应参考更多WP:可靠来源。若达成共识，可不受前列条文限制。这个文字避免了对原发言的过度解释，文字也概要的提及WP:共识精神。已经符合WP:可靠来源的项目，不应该再有筛选/排除的状况(这是针对更多官方以外文字)，重要的是WP:可供查证精神(WP:ABOUTSELF第5项，WP:断言、WP:REFNOTTRUE)
  • (～)补充这个议题大致上属于WP:ABOUTSELF第4项的讨论范畴
--Rastinition（留言） 2024年6月28日 (五) 23:55 (UTC)[回复]
同Rastinition。某些“官方”来源可能对排名作出详细解释，不应排除。--YFdyh000（留言） 2024年6月29日 (六) 02:30 (UTC)[回复]
@Rastinition@YFdyh000，但我仍希望在“讨论应参考更多WP:可靠来源”之后，具体强调要注重该些来源的“演员序列，及对个别角色的戏份、演出性质之描述”，亦同意HK5201314君的意见，即强调“避免演员序列被演员的名气所影响”。两位觉得如何？--Factrecordor（留言） 2024年6月29日 (六) 14:42 (UTC)[回复]
避免名气影响，我觉得是避免沦为宣传工具，但这可能不是中立的观点、非原创研究所推荐。因为以其他特定标准来呈现和调整，可能不满足这两项，也较难得出公认的一致的合理标准，也许还不如给原列表加脚注。--YFdyh000（留言） 2024年6月29日 (六) 16:58 (UTC)[回复]
那么@HK5201314君有没有进一步回应？--Factrecordor（留言） 2024年7月1日 (一) 10:51 (UTC)[回复]
不知道为什么，我想用TVB爱回家作例，话说当年杨明刚刚被TVB解冻，他获解冻后出埸的第一集，对白有超过10句，但TVB的操作是把他放在演员序列中最后一个。
什至，中国大陆常常封杀“不道德演员”，做法是打码／打格仔，并删除该演员资料。
如按照现行做法，是完全不尊重“不道德演员”及“刚解冻演员”，并违反中立原则，因为现行做法完全偏向制片商。--唔好阻住我爱国（留言） 2024年7月1日 (一) 11:30 (UTC)[回复]
所以建议新增如有任何争议，可按可靠来源介绍量／文章多寡决定演员序列。--唔好阻住我爱国（留言） 2024年7月1日 (一) 11:32 (UTC)[回复]
按文章量不可行，计算结果是原创总结（哪些来源算，如何去重，数量平手，情况改变），也同样容易操纵（争议人物排第一）。--YFdyh000（留言） 2024年7月1日 (一) 15:19 (UTC)[回复]
如果是“角色介绍量”呢？我不信只有一句对白的角色就有一整篇文章介绍该角色特性。--唔好阻住我爱国（留言） 2024年7月2日 (二) 12:14 (UTC)[回复]
润笔费给足，吹嘘解读不用愁。如果是重要角色或明星，但播出版本全剪掉了，又怎么办。别自定标准了，见下。--YFdyh000（留言） 2024年7月6日 (六) 13:59 (UTC)[回复]
我相信阁下有能力判断何谓“可靠来源”。--唔好阻住我爱国（留言） 2024年7月6日 (六) 15:50 (UTC)[回复]
写成看不出来不难，包括以量取胜。--YFdyh000（留言） 2024年7月7日 (日) 02:57 (UTC)[回复]
当初会建立指引，就是为了防止每个用户依据自己所认定的来进行排序，进而引发编辑战。同时，还必须考虑到欧美剧常有主演退出的情况。另外，有些戏之所以会将看似客串的演员列为主演，可能是认定其角色在某个阶段吃重，比如《黑道律师文森佐》的刘宰明，前三集是主演，但角色死亡后，第四集变成客串，可是不会因此推翻他在前三集是主演的事实。又，报奖策略出现的主配问题，例如《一把青》的排序是天心、杨谨华，但奖项竞赛却是杨谨华报名女主角、天心报名女配角，列入这些情况太过繁杂。
所以最好的方法，就是撇开个人模糊的“实情”认定，不论是剧情编排转变，还是宣传手段与否，尽量依据官方或可靠来源为准，主演写谁就是谁、客串是谁就是谁，这样可以避免自行量化、计算，而导致涉及原创研究的问题。其馀的，可以用可靠来源来补足，例如陈豪虽然被列为主演，但其偏向客串性质云云、演员被删除的原因等等。--Sa Young Sun（留言） 2024年7月5日 (五) 19:41 (UTC)[回复]
现实的影视作品中片尾的演员排列表为了避免演员争大争小的问题，出现了按年资序、笔划序、拼音序、出现序的各种做法。日本甚至形成了自己独特的排列方式，一些占相当大戏分的演员反而是在最后的。所以引进外国的时候，引进方经常是会随意调查番位的。您维非得将争大争小的问题变成编者自己争论的问题，这显然是不合维基百科的非原创研究精神的。--Ghren🐦🕛 2024年7月12日 (五) 16:43 (UTC)[回复]
日本应该是跟美国类似。美国会把比较大牌、资深（但可能戏份不及主角）的演员，用with、and排到最后，例如《嘻哈帝国》、《小谎言 (电视剧)》（[10]）、《柏青哥 (电视剧)》（[11]）等，韩国现在也会用“그리고”把演员排到后面。日本的话，还包含他们对“主演”的定义稍稍严格，所以有些戏份多的，才会排到最后。所以，建议依照官方排序，省得去解析with、and这些情况。--Sa Young Sun（留言） 2024年7月14日 (日) 15:18 (UTC)[回复]

提议修订著作权验证模板与提报侵权流程

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:页面存废讨论/疑似侵权。

前一段时间我重新看了下著作权验证模板的一些问题（在之前的讨论中提及过，不再重复具体描述），发现到此模板还是只能按全文处理。至于英文版，这个模板已经于2023年8月-10月进行了改版讨论，同时发现到该模板可以按全文或段落处理。相比而言，英文维基对著作权验证的处理更为灵活，而中文维基依旧按全文处理，显然过于死板，以至于某些人会觉得这是“过度使用”。尤其是涉及到影视类条目，过去一段时间看到涉及“剧情”部分侵权，还是按全文处理，确实是不灵活的。特别是2024年2月因为我写的大江大河之岁月如歌“剧情”一节涉嫌侵权，一开始就说提报人不合理，之后就被无限期封禁，到现在看还是相当无辜，如果当时发现到模板有问题就可能不会有后来的事。

因此，我提议对著作权验证模板进行重大修订改版。主要的修订要点：参考英文版的模板设计，采用条目消息框的样式，更直观、更清楚地传达这是一个与删除相关的问题，重新排列层次结构；根据实际情况，保留“如何解决”和“提示”部分，删除提报人的签名（在“疑似侵权”列表已有签名，不必要在模板重复使用此栏，其他删除模板也未见提报人的签名栏）。与此同时，我将对提报侵权流程进行修订（主要增加涉及新创建条目段落文字侵权的处理步骤）。

提议新模板设计

以下是我提议的新模板设计：


用字调查：是用“验证”好还是“调查”好？

借鉴了下英维对应模板使用的是“调查”（investigation），而中维用的是“验证”。在此我做一个调查，就是问下新模板是用“验证”好还是“调查”好。

提议修订提报侵权流程

配合模板的改版，本人提议对提报侵权流程作修订，建议的程序如下：

疑似侵犯版权条目的处理步骤
条目有 未侵权的历史版本 时
  1. 回退页面到未侵权的版本。
    侵犯版权的内容仍然会保留在页面历史，如果最新版本不侵权但历史版本侵权，可直接执行第3步。
  2. 在张贴侵犯版权内容的贡献者对话页中加入以下的文字：
    {{subst:Uw-copyright|條目名稱}} -- ~~~~
  3. 向 Wikipedia:修订版本删除请求 提报修订版本删除。
如果 当前的修订版本 某一段落侵犯了版权
  1. 将下面的模板放置在侵权文本上方。将下面模板中的“来源”改为相应的原文本的网址或其他的来源。（注意：搜索引擎结果不能作为来源）
    {{subst:Copyvio/auto|url=
    * 来源1
    * 来源2
    }}
  2. 将下面的模板放置在侵权文本下方。
    {{subst:Copyvio/bottom}}
  3. 在今天的疑似侵权部份加上：
    {{subst:CopyvioVFDRecord|條目名稱}}
  4. 在张贴侵犯版权内容的贡献者对话页中加入以下的文字：
    {{subst:CopyvioNotice|條目名稱}}
如果 所有的修订版本 都侵犯了版权
  1. 如果原页面内容符合其他快速删除的标准的同时又侵犯版权，则应当先按快速删除处理。
  2. 如果该页面是一个主页面侵权后建立的草稿页面，请直接提交快速删除（G16）。
  3. 将原文全部移走，用下面的模板取代。将下面模板中的“来源”改为相应的原文本的网址或其他的来源。（注意：搜索引擎结果不能作为来源）
    {{subst:Copyvio/auto|url=
    * 来源1
    * 来源2
    }}
  4. 在今天的疑似侵权部份加上：
    {{subst:CopyvioVFDRecord|條目名稱}}
  5. 在张贴侵犯版权内容的贡献者对话页中加入以下的文字：
    {{subst:CopyvioNotice|條目名稱}}

技术问题

因为此模板是可以用Twinkle提报的，所以修订就涉及技术上的问题了：整篇条目侵权可以用Twinkle提报，那如果引入段落侵权机制的话，Twinkle如何提报？如何定位我所需要的侵权段落？希望能有精通技术的人参与讨论。--Shwangtianyuan 不忘初心 牢记使命 2024年6月21日 (五) 16:36 (UTC)[回复]

用户界面层面应无问题，可以列出和选择章节，或者给章节加按钮。另就上一节，调查可能比验证更深入，比如复制自网页但文字是公有领域，或者来自维基百科但未正确署名。--YFdyh000（留言） 2024年6月22日 (六) 06:38 (UTC)[回复]
也是，我之前就碰到过某年度中华人民共和国政府工作报告条目，文字来源是中国政府网，但其网页记录的是政府工作报告全文，严格来说这属于公有领域。因此根据阁下意见，称呼调查比验证更准确。--Shwangtianyuan 不忘初心 牢记使命 2024年6月22日 (六) 14:53 (UTC)[回复]
@Shwangtianyuan：是否计划公示此案？Sanmosa 蚌埠 2024年6月29日 (六) 15:31 (UTC)[回复]
可以的。--Shwangtianyuan 不忘初心 牢记使命 2024年6月29日 (六) 15:33 (UTC)[回复]
现公示提案7日。Sanmosa 蚌埠 2024年6月29日 (六) 15:37 (UTC)[回复]
因应下方意见中止公示期。Sanmosa 蚌埠 2024年7月5日 (五) 07:33 (UTC)[回复]
我提一个技术上的小问题：不应该直接替换{{Copyvio}}的功能（保留原有功能），也就是将段落侵权的新代码另外新建模板，如{{CopyvioSection/top}}和配套的{{CopyvioSection/bottom}}。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月2日 (二) 02:35 (UTC)[回复]
url参数应该单列一行，而不是作为行内部分。可能存在列出多个侵权来源信息，需要列项显示。用语方面，原有是“页面正在进行版权验证”，所以对应段落的版本应该也是类似“本段落正在进行版权验证”而不是“有编者已就此条目发起著作权调查。正在调查的文本目前已隐藏，”。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月2日 (二) 02:39 (UTC)[回复]
@Shwangtianyuan。Sanmosa 蚌埠 2024年7月5日 (五) 07:32 (UTC)[回复]
技术上的问题我并不是太懂，希望能有其他精通技术的人前来讨论。--Shwangtianyuan 不忘初心 牢记使命 2024年7月5日 (五) 07:41 (UTC)[回复]
（不好意思，最近才稍稍有时间处理一下这边的问题）@Cwek。Sanmosa 蚌埠 2024年7月13日 (六) 01:31 (UTC)[回复]

其他

好像针对段落的侵权，现时做法是直接删掉+RDD，没有考虑过按段落重写的问题。或者在这个原有逻辑上，添加额外的段落标识+草稿重写来处理。原有的全文流程还是保持不变。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 00:43 (UTC)[回复]

我只是来发泄一下。话说《黄飞鸿传》是我初在维基最早期建立电影条目，当时受友人所托对百部不可不看的香港电影进行遗补。但当时我不熟悉方针，还傻傻的担心剧情简介“原创”不好，所以按照来源──香港电影资料馆出版的实体书籍《香港影片大全》系列逐字逐句打出来，哪知影片大全系列的很多内容早被电子化至康文署的网上资料库，又被各网站复制，条目被指为侵犯那些网站的版权，需要整个重建。然而，整个条目中，只有剧情简介是一字一句完全与来源一样，其他内容包括人物简介，均是自己消化后创作出来。后来，我发现一些电视剧的剧情介绍常被放入复制自作品官方的文字，处理方法有的是挂上一个章节可能侵权的模板（连内容也没删），有的是删除该章节内容。换言之，出现一个疑问，为什么我当初的条目没被这样处理？自此，我对侵权处理印象极差。顺带一提，后来我曾在讨论指出，正如我当时想法，其实有些人无意侵犯什么，也不是懒，只是觉得依从作品官方或具权威性的出版物之介绍，比自己原创更好。当然，如果照搬的文字不是来自官方，是其他有版权的作品，像我当初那样抄《香港影片大全》，侵权问题确需注意，但是如果照搬的是作品官方公开宣传用的文字介绍，你愿意免费替官方把他们的介绍宣扬开去，他们可能还会多谢你，试问天下间除了维基人，谁会担心作品官方会控告这样的所谓侵权。官方介绍的问题反而是宣传性过高，有时不中立，甚至有时与真实剧情相违。--Factrecordor（留言） 2024年6月29日 (六) 14:13 (UTC)[回复]
“他们可能还会多谢你”是说不好的，维基百科的协议允许商业化和修改衍生，需要为版权状态做更多努力，避免后患。剧情介绍的编写着实麻烦。--YFdyh000（留言） 2024年6月29日 (六) 17:02 (UTC)[回复]

提议将通用评级指引并入页面评级

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

由于前者亦属页面评级，可以并入后者为部分有效之章节，毋须置独立页面。此提议不涉及指引实际内容变更。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 01:57 (UTC)[回复]

不反对合并。不过能否询问下您会怎么设计合并之后页面评级的章文结构，如果可以的话能否参考下Temp君的意见。--人间百态,独尊变态(讨论) 2024年6月23日 (日) 08:37 (UTC)[回复]
@Temp3600：不知有何意见？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月2日 (二) 04:20 (UTC)[回复]
合并比较好。不过也要注意通用评级指引指引本身还有其他需要修改的地方，所以上一次讨论时就没有提出合并的单独请求。--Temp3600（留言） 2024年7月2日 (二) 14:47 (UTC)[回复]
好，之后准备公示（抱歉最近比较没空）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月12日 (五) 16:35 (UTC)[回复]
应该可以合并--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 14:52 (UTC)[回复]

提议清楚定义何谓“正当合理的回应”

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

根据WP:共识的公示条文：

另外，为确保讨论的连贯性，任何正当合理的意见（无论是否于公示前或公示后提出）若已获提案人正当合理的回应，且自该回应起计的3日后无进一步再回应，应视为该意见已解决。已获解决的意见若被任何使用者重复提出，可提示该使用者相关意见已获解决，除此以外无须另作回应。

假设提问者在提案讨论提出一个具建设性的问题给提案人，而提案人为了希望该提案尽快获得通过，以解决当前指引的漏洞，故提案人选择坐在电脑前，当提问者提出意见后，提案人秒回提问者的意见。3天后，提问者并无进一步回应。

根据上述条文，应视为该意见已解决且不需再回复。

可是，在7天后（即回答问题后10日），也是公示期结束前一天，提问者认为提案者的回应不正当合理，于是强行终止公示。

个人认为这是一个拉布的行为，严重影响共识形成。

1.首先，何谓“正当合理的回应”？谁有权在3日限时以外可以judge这个回应？

2.其次，理论上，共识应解决所有合理的问题，唯提问者在提案者回答后3日不回应相关答案，算不算已解决相关问题。

3.如果这里有4名编辑者参与讨论，当提案者回答提问者（这里已有2人）问题后，其馀2位编辑者也发表与提案者类近回答及补充。4日后，提问者可不可以认为提案者的回应不正当合理而当提案者的回应不算数？

以上！（希望在条文中清楚定义何谓“正当合理的回应”，可以是其他编辑者投票或第三方管理员进行判定，以避免因此而造成拉布的理由。）--唔好阻住我爱国（留言） 2024年6月25日 (二) 11:20 (UTC)[回复]

不要墨守成规，以讨论而非流程时限去判定。
是否已解决，提问者最有发言权，视为已解决是一种假定（类似自动评价），当事人始终有权在公示前后再度表态，不能以流程堵嘴说来晚了、已视为已解决，且“共识可以改变”。
问答是否正当，参与讨论者均可表态与附议，不清晰可以直接问。
恶意拉锯请考虑游戏维基规则的警告、举报，可附注之前回应或者更广泛的意见。但执意推进不成熟的提案同理。--YFdyh000（留言） 2024年6月25日 (二) 14:24 (UTC)[回复]
“提问者最有发言权”，难道我可以在问题被回答后十个月后提出该回答是否合理？--唔好阻住我爱国（留言） 2024年6月26日 (三) 12:01 (UTC)[回复]
视作新问题？是否打破之前共识，倾向按常识个案讨论处理。视作已解决不代表失去未来资格，可能要看是否应当解决。--YFdyh000（留言） 2024年6月26日 (三) 16:14 (UTC)[回复]
显然是祇能个案判断。虽然本人一向认为近来若干讨论有扩大解释的不良倾向。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月26日 (三) 04:16 (UTC)[回复]
离题的当然就不可能是正当合理意见。若有违基本逻辑，能被指出逻辑漏洞甚至是逻辑谬误的意见，客观及字面意思上不符合“正当合理”，因存在逻辑谬误的论点本来就是客观认定的“invalid arguments”（某大学资源、人文作家、GPT辅助解释、另一大学资源）。若并无明显违反逻辑或存在逻辑谬误，则以是否与其他方针指引抵触为考量因素，确实与其他方针指引相违背的不可能视作有效意见考量。另外，共识方针也指明过往已获回应，而并未提出新观点，仅仅重复过往观点的留言不需重复回应。其馀绝大多数情况都是正当合理的意见。--路西法人 2024年6月26日 (三) 08:01 (UTC)[回复]
“共识方针也指明过往已获回应，而并未提出新观点，仅仅重复过往观点的留言不需重复回应。”：
甲人：我认为论点A是十分重要 —> 1日后—> 乙人：基于论点A，这是见解B ；丙、丁、戍人：见解B所言正解—> 3日后 —> 开始公示 —>6日后—> 甲人：我认为你没有回答问题，见解B的论点完全不合理，所以我还是认为论点A是十分重要，于是强行终止公示。
——
换算是阁下的共识议案，我套用这个逻辑找阁下提案的不足，阁下肯定会觉得非常不满。--唔好阻住我爱国（留言） 2024年6月26日 (三) 11:49 (UTC)[回复]
因为这个逻辑，本人的提案已被拉锯足足2个月（讨论及完善条文仅使用1个月），而对手是管理员，根本无从入手解决问题。--唔好阻住我爱国（留言） 2024年6月26日 (三) 11:57 (UTC)[回复]
单单说“没有回答问题”而没有论证则同样为无效，除非能够论证如何没有回应问题，否则都不能说对方的回应不合理。--路西法人 2024年6月27日 (四) 06:54 (UTC)[回复]
条文没有这样写…
而且隔这么久先质疑回应的正当性会不会有问题？--唔好阻住我爱国（留言） 2024年6月27日 (四) 11:20 (UTC)[回复]
如果重复为了拖延提案而选在公示将近结束前才发表反对意见，就是游戏共识形成过程的行为。况且，缺乏论证的观点本来就不属于可供参考的意见，缺乏论证或论证明显有误的“没有回答问题”也同样不会是有效的程序质疑。--路西法人 2024年6月28日 (五) 02:42 (UTC)[回复]
比较想不用颇主观性的游戏维基规则，如管理员参与了战争，一切最终决定权还是管理员。
—-
打算这样改
另外，为确保讨论的连贯性，任何正当合理的意见（无论是否于公示前或公示后提出）若已获提案人正当合理的回应（如编辑者欲质疑相关回应是否正当合理，必须于问题被回应后3天内提出，并详细说明该回应有什么不足），且自该回应起计的3日后无进一步再回应，应视为该意见已解决。已获解决的意见若被任何使用者重复提出，可提示该使用者相关意见已获解决，除此以外无须另作回应。--唔好阻住我爱国（留言） 2024年6月28日 (五) 03:34 (UTC)[回复]
不认为有必要限制必须在三天内提出，但确实有必要规定述明有何不足。--路西法人 2024年6月28日 (五) 09:41 (UTC)[回复]
但应同时避免无限期等待或最后一刻先发表重复的意见。--唔好阻住我爱国（留言） 2024年6月28日 (五) 14:14 (UTC)[回复]
这是当然，但这样写就会变得相当模糊，还不如直接将其视作玩弄社群建立共识的程序处理更好。--路西法人 2024年7月3日 (三) 01:48 (UTC)[回复]

另外，为确保讨论的连贯性，任何正当合理的意见（无论是否于公示前或公示后提出）若已获提案人正当合理的回应（如编辑者欲质疑相关回应是否正当合理，必须于问题被回应后尽快提出，并就每一不足论点详细说明该论点的不足之处及提出可接受的建议。），且自该回应起计的3日后无进一步再回应，应视为该意见已解决。已获解决的意见若被任何使用者重复提出，可提示该使用者相关意见已获解决，除此以外无须另作回应。

我相信管理员在调查破坏者是否玩弄社群时会参考破坏者的贡献记录，看看是否达到“尽快”要求。--唔好阻住我爱国（留言） 2024年7月3日 (三) 15:14 (UTC)[回复]
@Ericliu1912@Factrecordor@LuciferianThomas@YFdyh000:三日后无反对意见的话就开始公示这个版本。--唔好阻住我爱国（留言） 2024年7月12日 (五) 11:05 (UTC)[回复]
您不能只要求“质疑者”详细说明该论点的不足，还要提出可接受的建议这样子。“提案者”和“质疑者”两者的责任并不相称。而且“可接受的建议”也太主观，也不合适。质疑者没有必要教提案人如何写好方针好吗。--Ghren🐦🕛 2024年7月12日 (五) 16:52 (UTC)[回复]
游戏维基社群也属于主观规条。
正如路西法人道“ 缺乏论证的观点本来就不属于可供参考的意见”，不能单单一句“我不同意这个回复”而影响整个讨论。--唔好阻住我爱国（留言） 2024年7月13日 (六) 01:18 (UTC)[回复]
请问Ghren在说天秤两边重量不成比例，导致共笔版本倾斜于提案方的问题吗？即使想厘清正当合理的状况，但要其他人质疑来决定正当合理与否，此举潜在默认了没有受到质疑的回应。 -- 月都 ※ 2024年7月14日 (日) 16:10 (UTC)[回复]
我们在编辑某些条目，察觉一些方针需要制订或修改，却不一定常涉足所有受该方针影响的范畴，先反思影响范围，再看看哪些用户经常活跃于个中话题，邀请讨论，所有潜在疑问可能在两三星期内就能被大家想出来了，可以集中解决。若不这样做，往往有个人偶尔路过，又放下一个疑问，自然无休无止。就算你曾经顺利通过提案，也只是你的一时幸运，而你的幸运不一定是维基之福。--Factrecordor（留言） 2024年6月26日 (三) 13:01 (UTC)[回复]
“偶尔路过，又放下一个疑问”，这个绝对支持，唯该路人是不是应该负起责任，主动跟进自己问过的疑问，如有需要，应尽他能力以最快时间进行追问，避免社群其他成员无限的等待，这对提案者绝对是一个折磨。--唔好阻住我爱国（留言） 2024年6月26日 (三) 13:13 (UTC)[回复]

关于视频平台能否作为一手来源的困惑

由于有两个用户因为在编辑澳视澳门台相关条目时(Special:PermaLink/82462720)，对条目的原创总结以及B站影像资料能否作为来源的问题而引发争执。想问一下视频平台的影像资料及动态信息能否作为一手来源？--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年6月30日 (日) 13:35 (UTC)[回复]

没找到争议，请列位置。已认证账号发的内容可能作一手来源，引用价值和方式需具体评估。--YFdyh000（留言） 2024年6月30日 (日) 15:50 (UTC)[回复]
已经补上了。(事后才在讨论页说明User talk:YouTube zou zou)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年6月30日 (日) 22:06 (UTC)[回复]
未见涉及条目中来源。如果前后都无来源，请求来源或者全部移除。--YFdyh000（留言） 2024年7月1日 (一) 05:15 (UTC)[回复]
我记得日语维基百科那边是禁止使用视频中的内容作为参考来源的，中维这边不太清楚有没有类似要求。——— 红渡厨（留言・贡献） 2024年7月3日 (三) 02:23 (UTC)[回复]
@红渡厨不过之前在日维的决斗大师条目中看到了有用户使用YouTube的视频链接作为参考来源。--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月9日 (二) 22:02 (UTC)[回复]
你这话说的。。。。中维还有人不加来源呢，你能因此说不加来源是中维的方针吗。--——— 红渡厨（留言・贡献） 2024年7月9日 (二) 23:34 (UTC)[回复]
只是吐槽一下原条目内的原创总结。(官方的生放送视频只提及动画将于当月底完结并未提及不会再有新动画作品。)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月11日 (四) 04:53 (UTC)[回复]
我记得没有完全禁止，有要求限制而已，官方验证媒体帐号，自行出版物与可疑来源中的材料可以用作说明其释出者（如某人、组织或其他实体）或该来源自身资讯的参考来源，通常在释出者相关条目或以该来源本身为主题的条目中，而不要求是由该领域的专家发表，只要：
  1. 没有过度的自我宣扬；
  2. 不包括针对其他人、组织、实体的主张或观点；
  3. 不包括与主题无直接关联事件的主张；
  4. 来源内容的真实性未受到合理的质疑；
  5. 不是条目主要的来源。

这一方针同样适用于社交网络上的内容，如Facebook、Twitter、人人、微博等，但建议不要经常使用，有更好就使用更好--HYHJKJYUJYTTY（留言） 2024年7月3日 (三) 02:40 (UTC)[回复]

关于Wikipedia:格式手册/列表#条目内嵌入人物列表的收录标准的问题

缘起：近期，U:向史公哲曰挨个移除城市条目中著名人物章节的内容，统一替换为{{Category see also|XX人}}，即使写成散文体，也难免劫难。向君有言“这种叙述看似是散文体，实则是换皮列表。如有意见，请去互助客栈指出”。向君所据，概为Wikipedia:格式手册/列表#条目内嵌入人物列表的收录标准，然此仅一指引，加粗有注一般应该尽量遵守。先不谈直接对优典条目动大刀合不合适，也不谈事前不与主编商议直接上手删内容礼不礼貌，再不谈“我认为这是换皮列表，这就是列表，删除之”的做法妥不妥当。在此河某只想请教一个问题：散文体编写的著名人物章节是否违反此指引，如违反，著名人物章节要怎么写？

回顾：“行政区划条目，禁止嵌入本地出身名人之类的列表”这一指引，出自2019年9月底的讨论Wikipedia talk:格式手册/列表/存档2#提议新增“条目内嵌入列表的收录标准”。此鲜有编者讨论的提案快速通过，2019年12月即有编者疾呼“直到今天我才知道，Baomi方案竟然作为共识修订案通过了”，另一编者同月一度试图重启讨论废除此案。

想法：

  • 关于“列表”：禁止条目内嵌列表的初衷，想必是列表内容冗杂，嵌于条目中有碍阅读，影响条目质量云云。河某认可此说，禁止大型列表嵌入条目是有必要的，不过寥寥数行的嵌入式列表放置在必要位置并不会影响条目质量。个人不反对点列式编写著名人物章节，但更偏向于散文体，不认可用“列表”展现，视觉上太奇怪了。
  • 关于城市/政区的“著名人物”章节：当代网络百科的城市政区条目体例很大程度上沿袭自方志，方志人物志有传、录、表等体裁。著名人物按类型又可以分为乡贤、卓行、忠义、宦绩、孝友、列女等，是对志书在地影响深远或为人称道的人物，也是地区文教礼化的表现，在志书中必不可少。优秀的百科条目，应当给予读者恰到好处的信息，著名人物应该有，附带一句话或几个字的简介，列出的人物数量不能多不能少，视情况而定。关于著名人物数量的问题，河某有两种思路。一为量化“著名人物”章节列出的人物数量，不过无论是拍脑袋提出的10个20个，亦或根据人口计算出“最高著名人物数量上限”，都不合适，前者毫无理据，后者深圳一类新兴城市不公平。二为不设限制，由主编自行判断、决定展现多少/哪些名人合适，把条目编辑权交还给熟悉此领域的编辑，乱放一大堆名人搞得太过分，就在优典评审甚至DYK中卡住投反对不予通过。
  • 关于{{Category see also|XX人}}：把读者引向分类页面是个很糟的主意，试想读者难道会在拥有27个子分类、469个条目的分类里遨游，一个个点开条目阅读？维基百科的分类系统对于读者来说是非常困惑的。可以留在章节开头，但个人不建议。

提案：

现行条文

姓氏条目禁止嵌入“著名人物”等人物列表，此类信息应由“分类:×姓”或独立列表体现。

行政区划条目禁止嵌入“本地出身人物”等人物列表，此类信息应由“分类:××人”或独立列表体现。

疾病条目禁止嵌入“知名患者”等人物列表，此类信息应由“分类:×疾病患者”或独立列表体现。

提议条文

姓氏条目禁止嵌入“著名人物”等人物列表，此类信息应由“分类:×姓”或独立列表体现。

行政区划条目禁止嵌入“本地出身人物”等人物列表，此类信息应由“分类:××人”或独立列表体现。散文体撰写的内容不属此列。

疾病条目禁止嵌入“知名患者”等人物列表，此类信息应由“分类:×疾病患者”或独立列表体现。

知会：天津市、滨海新区@Amazingloong：，嘉义市@Ketsu1213：，怀仁市@如沐西风：，宁波市、镇海区@Siyuwj：，杭州市@Huandy618：，沙门镇@MintCandy：，肥城市@Eguersi：，广德市@深鸣：，卢氏县@Newbamboo：，固始县@Sinopitt：，广州市、深圳市@Donwun：、祥云县@Kcx36：，日本系列@Suicasmo：，法国系列@Yzergues：，欢迎各位政区条目同好发表建议。如有叨扰深表歉意。--河水|滇 2024年7月2日 (二) 01:10 (UTC)[回复]

为什么说阁下的编辑是换皮列表呢？因为在我看来，瑞丽的著名历史人物有麓川君主思可法、思伦法、思任法、思机法及末代勐卯土司衎景泰；中华人民共和国时期的政界人物有第五届全国人大常务委员瑞板，政协云南省十二届委员会副主席黄毅；宗教界著名人物有上座部佛教高僧乌阿匝，中国佛教协会第六届理事会副会长伍并亚·温撒，中国佛教协会第九、十届理事会副会长诏祜巴等傣；文化界著名人物有孔雀舞大师毛相，傣族诗人召尚弄·岩相、庄相等。这段文字与

政治人物

  • 麓川君主思可法、思伦法、思任法、思机法
  • 末代勐卯土司衎景泰
  • 第五届全国人大常务委员瑞板
  • 政协云南省十二届委员会副主席黄毅

宗教人物

  • 上座部佛教高僧乌阿匝
  • 中国佛教协会第六届理事会副会长伍并亚·温撒
  • 中国佛教协会第九、十届理事会副会长诏祜巴等傣

文化人物

  • 孔雀舞大师毛相
  • 傣族诗人召尚弄·岩相、庄相
没有任何区别。（考虑到篇幅问题，没有细分列表）另外大部分条目的名人页面也都是导向分类的，这不是鄙人的发明。--向史公哲曰（留言） 2024年7月2日 (二) 01:30 (UTC)[回复]
既然阁下有时间用这么多篇幅解释，为什么没有时间改善条目，反而是一删（更正，应该是三删）了之呢？至少也应该事先与原先的编者沟通。--🐹通辽署理交通相（讨论·成就·交通点滴） 2024年7月2日 (二) 02:26 (UTC)[回复]
因为这属于列举名人的内容，根据大部分条目的编辑情况是要删除的。--向史公哲曰（留言） 2024年7月2日 (二) 02:29 (UTC)[回复]
既然本人的行为是极不妥当的，那么你们完全可以去提报我，然后把所有行政区划条目的名人章节全部恢复，这并不难。--向史公哲曰（留言） 2024年7月2日 (二) 02:32 (UTC)[回复]
毕竟维基百科的行政区划条目理应罗列名人，体现当地的“人杰地灵“。而我对建设性内容大面积删除是极不妥当的，不符合中国大陆维基人共识的。我干这种滔天大罪，难道不应该被提报破坏，争求封禁吗？--向史公哲曰（留言） 2024年7月2日 (二) 02:35 (UTC)[回复]
理论上说，散文和列表在许多情况下是可以相互改写的，所以你只是论述了原先的散文可以用列表取代。如果认为这样的散文就是换皮列表，我也只能言尽于此了。另外讨论是交换意见，让条目内容很好，而不是指控其他人，所以大可不必用这样的语调回复。--深鸣（留言） 2024年7月2日 (二) 03:09 (UTC)[回复]
更不用说大多数行政区划条目的名人板块都违反了npov和原创研究方针。（例如这些名人都会冠以政治家，军事家等名号）（例如名人的选取标准十分混乱，凡是出生于此、祖籍于此、旅游至此、工作于此，长居于此的名人都在这些维基条目的罗列范围，总之名人的选取标准也是颇具争议的。）--向史公哲曰（留言） 2024年7月2日 (二) 01:35 (UTC)[回复]
诚然个别名人“在地影响深远”，但亦有与当地几无瓜葛甚或认同者，故建议改为“以散文体陈述对当地有重大影响者除外”／“不属此列”，否则既属琐碎亦涉嫌离题。--— Gohan 2024年7月2日 (二) 01:51 (UTC)[回复]
中国的传统历史书也有人物传记，是不是中国历史条目也要罗列“中国历史名人”？--向史公哲曰（留言） 2024年7月2日 (二) 02:09 (UTC)[回复]
历史条目中，如果安排得当，对历史影响较大的人物在先前的内容中应该都已经提及，因此没有必要单独再列出历史名人。也就是说，如果罗列“中国历史名人”，说明前面的内容安排不合理。--深鸣（留言） 2024年7月2日 (二) 03:04 (UTC)[回复]
同意此看法。在行政区划条目中列出人物，还是为了介绍条目的主题。列出一部分能够体现当地特色的人物，能够展示当地的特点。并且行政区划类条目与方志类似，方志中也有类似的人物章节。--深鸣（留言） 2024年7月2日 (二) 03:01 (UTC)[回复]
能够体现当地特色的名人，其筛选标准是什么？另外外文维基百科面对名人列举问题，采取的方法是建立xx人列表。--向史公哲曰（留言） 2024年7月2日 (二) 03:10 (UTC)[回复]
该问题不可能有固定的标准，使用常识即可。若存在争议则再根据具体的情况讨论即可。这种情况其实类似于各民族信息框中列举一些名人。创建xx人列表，我认为不必，直接使用分类取代即可。--深鸣（留言） 2024年7月2日 (二) 03:26 (UTC)[回复]
如果当地名人的选取标准能够使用wp:使用常识判断的话，那么中维乃至全社会关于名人是哪里人的争议就不会那么多了。另外有些能体现当地特色的名人并不一定直接与当地有关，例如舒婷，她的自我认同是鼓浪屿人，且她的常居地在鼓浪屿。但是她出生在漳州，祖籍在泉州。--向史公哲曰（留言） 2024年7月2日 (二) 03:59 (UTC)[回复]
再比如说，一些人虽然的确是当地人，但是他与当地并没有太大的关系。例如王洪文是毫无争议的长春人，但是他的主要事迹都与上海有关。--向史公哲曰（留言） 2024年7月2日 (二) 04:02 (UTC)[回复]
我认为这类例子就可以不添加。“关于名人是哪里人的争议”，这个讨论主体是名人，因为其经历复杂而有争议是正常的，不适用于使用常识，与本提案没有什么关联。我所说的“使用常识”指的是在选取名人方面，而不是判断争议名人的归属方面，毕竟存在争议的人还是少数。例如瑞丽的著名历史人物有麓川君主思可法、思伦法、思任法、思机法及末代勐卯土司衎景泰；中华人民共和国时期的政界人物有第五届全国人大常务委员瑞板，政协云南省十二届委员会副主席黄毅；宗教界著名人物有上座部佛教高僧乌阿匝，中国佛教协会第六届理事会副会长伍并亚·温撒，中国佛教协会第九、十届理事会副会长诏祜巴等傣；文化界著名人物有孔雀舞大师毛相，傣族诗人召尚弄·岩相、庄相等。这段话里面应该大多数人还是没有争议的吧，并且单纯从这段话而言，能够体现出瑞丽市宗教与文化方面的特点，对主体是有益的。--深鸣（留言） 2024年7月2日 (二) 04:30 (UTC)[回复]
首先，结合我近日的编辑来看，存在归属争议的名人并不在少数。其次，名人的选取标准应该以什么为准绳？是否身居要职就应该罗列上去，还是说有维基条目就可以列上去？--向史公哲曰（留言） 2024年7月2日 (二) 04:39 (UTC)[回复]
此外还有一个问题，名人的选取标准是否应当顾及到当地名人的多寡（名人多的标准放高，名人少的标准放低），还是说应当要统一选人标准？--向史公哲曰（留言） 2024年7月2日 (二) 04:41 (UTC)[回复]
虽然存在归属争议的名人并不在少数，但是从整体来看，多数名人还是不存在归属争议的。或者就说，列举的名人就从不存在归属争议中的挑选。关于名人的选取标准以及人数多少，我认为就应该使用常识，根据具体的情况判断。总体来说不是太多就可以，并且也应该是当地名人中较为出名的那一批。--深鸣（留言） 2024年7月2日 (二) 05:00 (UTC)[回复]
如果所谓的“不是太多就可以，并且也应该是当地名人中较为出名的那一批”没有一个可以量化的标准，那事实上这样的标准就会成为原创研究。--——— 红渡厨（留言・贡献） 2024年7月2日 (二) 09:28 (UTC)[回复]
维基百科:规则只是原则，不是什么东西都必须有一个“可以量化的标准”，许多东西运用常识即可。维基百科不是官僚体系，不是盲目跟随默认的方针和程序。--深鸣（留言） 2024年7月2日 (二) 09:37 (UTC)[回复]
如果阁下有在生活中接触过大量的人，你就会发现，这个世界上根本就没有所谓的“常识”：比如，有人认为“讲卫生”是常识，但事实上有大量的人不讲卫生；比如，有人认为“如何购买地铁票”是常识，但事实上有大量的人不知道如何购买。许多人所以为的“常识”，事实上只是“身边统计学”而已。以及，我非常反感话都没开始说几句就抛出一个维基百科:忽略所有规则（或其他类似观点，后续统称“该方针”）来堵对方嘴，我认为这只是为了拒绝执行其他方针找的一个借口而已。虽然该方针我有时候也拿出来说，但我认为该方针是用于现有维基百科方针不足以说明当前情况时，用来类推相似做法。--——— 红渡厨（留言・贡献） 2024年7月2日 (二) 10:04 (UTC)[回复]
虽然某一个人的常识不一定是常识，但是大量的人的常识汇总起来，那么就可以认为是常识。我本意并不是批评或评价阁下，但是我确实认为阁下像是读法律条款一般去读维基百科的各种方针，什么东西都要找到对应的条款。正因为这种观念，所以出现了不少诸如一刀切现象的存在。不过我不认为这种观念适用于维基百科。另外，我提出忽略所有规则类似的观点并不是想堵住对方的嘴，只是想说明“不是太多就可以，并且也应该是当地名人中较为出名的那一批”类似的语句就已经足够了，原来的规定行政区划条目禁止嵌入“本地出身人物”等人物列表的本意应该是防止大量琐碎内容的堆积。有些规则确实只是传达了一种精神而已，如果非要量化，像法律条款那样规定“列举的人物不得超过五个，且至少为XX职称云云”，阁下认为这样的规则合适吗？如果制定了这样的规则，就很容易陷入连锁悖论之中。当然，我认为阁下的意思是，没有极其明确的规则的话，就可能存在争议，但是这也是没有办法避免的事情。--深鸣（留言） 2024年7月2日 (二) 10:30 (UTC)[回复]
这里提一嘴，我个人感觉将人物列表以简单粗暴的手法改写成散文体，并不能阻止"堆积内容"的情况。例如在天津条目和杭州条目的人物章节（存在于上一个历史版本）中，便存在各式人物罗列的情况。我对这些名人内容的评价是"出生于此、祖籍于此、旅游至此、工作于此，长居于此的名人和虚拟名人的大乱炖"。目前，我个人看到过最好的名人叙述章节在宁波条目（虽然被我删除了）。--向史公哲曰（留言） 2024年7月2日 (二) 12:51 (UTC)[回复]
“一刀切”禁止不妥，相关提案本意当是避免在条目中塞入臃肿列表影响叙述重心，或避免“缺乏定义”问题，并非任何列表均禁止添加。又若有可靠来源直接指出某些人物为当地名人，则不一定属于“原创总结”。另外，若列表篇幅不足以建立独立列表，亦应允许直接放在条目中。此处与其指定“散文体行文除外”，不如改成“（一般而言）禁止嵌入仅单纯列点之列表”，给予编者更大空间。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月2日 (二) 04:15 (UTC)[回复]
我倾向每项列举和定义（特点、著名）都有来源，作为基础条件。排序、原创总结等问题尽量避免，但只要写就肯定存在问题，是将多个来源的内容整合为一段。容易违背中立的观点。--YFdyh000（留言） 2024年7月2日 (二) 05:11 (UTC)[回复]
人物章节确实容易形成堆砌内容的风格。如果以改善为目标，则更应该强调此类章节的逻辑性。而不是简单删除，放一个分类在这里。即便是待改善的点列式，也比简单删除的做法好。宁波市此前的人物段落虽不充实，但写作的感觉和逻辑性较好，值得借鉴。--Amazingloong（留言） 2024年7月2日 (二) 14:42 (UTC)[回复]
统一回复上述讨论串的疑问、质疑、建议：
  • 大部分条目的名人页面也都是导向分类的，以前不是这样的，应该是这个指引出来后逐步被改的。我RFA的时候有被问到过对条目嵌入列表的看法，只是在RFA里做了回复，没有参与这个讨论。当时觉得这个指引规定的是“列表”，未曾想到如今会扩展到散文体的段落。
  • 著名人物章节选择哪些人物进行展示、筛选标准是什么，不是此案的讨论范围。从方志实践的角度看，出生于此、祖籍于此、旅游至此、工作于此、长居于此都可以被列入，这些应该是编者编写条目自己考量的东西，属于内容范畴，不属格式手册管辖范围。具体对内容有质疑，应该在条目的讨论页或者优典评审中提出。看到许多讨论都偏题了，重心偏向如何界定“著名人物”去了，本案只讨论格式手册限定的格式问题，深入讨论“著名人物”的界定问题我觉得在维基百科:互助客栈/条目探讨开一个版比较合适。
  • 外文维基百科面对名人列举问题，采取的方法是建立xx人列表。小城市条目的著名人物也是直接写在“著名人物”章节，还都是用点列式写的，例子：en:Kennewick, Washington、de:Bobonaro (Gemeinde)、ja:门司区，都是外维GA里随机挑的。不反对建立XX人列表，但也不提倡，这个列表的意义和分类没太大区别，还需要手动更新，属于吃力不讨好的活，没人看，只能感动自己。如果著名人物双手双脚数得过来，又何必单独建立列表。
  • 建议改为“以散文体陈述对当地有重大影响者除外”／“不属此列”，我认可这样的想法，但不赞同这种做法，“对当地有重大影响者”无法量化，不应该在方针指引中写入这样模糊的话语，会对未来埋下矛盾。是否是值得列入的、有重大影响的著名人物，应是条目内容的范畴，同前所述。
  • 将人物列表以简单粗暴的手法改写成散文体，并不能阻止"堆积内容"的情况。确实，但是禁止列表难道能够阻止“堆积内容”吗？政区条目有一万种可以灌水堆积内容的方式：按新方志大事记体裁事无巨细写历史，地理章节拿着地名志把山川河流全写上，人口经济章节用统计年鉴疯狂写数据（参考百度百科）……出现在这个讨论串的，想必都是对政区条目有一番心得的编者，简言之都会写条目，谁会觉得这样堆积内容的条目是优质条目，又会这么做呢？真的堆积内容，应该在条目质量评审中卡住，还是那句话，内容的问题和格式的问题是两码事。格式手册应是基本格式的下限，不是束缚编者的枷锁。
  • 改成“（一般而言）禁止嵌入仅单纯列点之列表”，赞同。
  • 以上。--河水|滇 2024年7月2日 (二) 22:59 (UTC)[回复]
同意河水君的看法。不过个人认为新的提议条文中，前后两句话在语义上或有矛盾之处。或可直接删除，或可改为“（一般而言）行政区划条目中禁止嵌入仅单纯列点之人物列表”。--深鸣（留言） 2024年7月3日 (三) 17:16 (UTC)[回复]

正式提案（准备公示）

三日未见新的疑问、质疑，河某权当诸君认可此修订案基本方向，修改正式提案如下，再待三日，若无异议将进行公示。

现行条文

姓氏条目禁止嵌入“著名人物”等人物列表，此类信息应由“分类:×姓”或独立列表体现。

行政区划条目禁止嵌入“本地出身人物”等人物列表，此类信息应由“分类:××人”或独立列表体现。

疾病条目禁止嵌入“知名患者”等人物列表，此类信息应由“分类:×疾病患者”或独立列表体现。

提议条文

姓氏条目禁止嵌入“著名人物”等人物列表，此类信息应由“分类:×姓”或独立列表体现。

行政区划条目禁止嵌入“本地出身人物”等人物列表，此类信息应由“分类:××人”或独立列表体现。

疾病条目禁止嵌入“知名患者”等人物列表，此类信息应由“分类:×疾病患者”或独立列表体现。

一般而言，行政区划条目中禁止嵌入仅单纯列点之人物列表，此类信息应由“分类:××人”或独立列表体现。

是否有必要提供例子进行条文解释，明确何谓仅列点之人物列表，可再议。--河水|滇 2024年7月5日 (五) 10:42 (UTC)[回复]

‘此类资讯应由“分类:××人”或独立列表体现’这句分句可以保留。总体上暂时不反对此提案。Sanmosa 蚌埠 2024年7月5日 (五) 12:33 (UTC)[回复]
或改成“可由（略）体现”。另“仅列点”可改为“仅单纯列点”，排除混合写法。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月5日 (五) 14:35 (UTC)[回复]
已根据建议调整新增条文。原新增条文：一般而言，行政区划条目中禁止嵌入仅列点之人物列表。--河水|滇 2024年7月5日 (五) 20:58 (UTC)[回复]
(－)反对之前是因为收录标准不明，而不允许姓氏、区划类条目加入人名列表的，之前“美国人列表”之类的也是因此而被禁止的吧--苞米(☎)💴 2024年7月5日 (五) 21:10 (UTC)[回复]
@Baomi：还请你说明一下你反对的是河水的提案本身还是我对河水的提案的建议。Sanmosa 蚌埠 2024年7月6日 (六) 11:01 (UTC)[回复]
(＋)支持，比之前的条文合理--苞米(☎)💴 2024年7月6日 (六) 12:09 (UTC)[回复]
@瑞丽江的河水：我认为你现在可以考虑是否公示此提案。Sanmosa 蚌埠 2024年7月13日 (六) 01:39 (UTC)[回复]
开始公示七日。--河水|滇 2024年7月13日 (六) 08:36 (UTC)[回复]

提议限制无意义用户名

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

不通过：
社群主流意见显然反对在“无意义用户名”不能被妥为定义的情况下限制无意义用户名的提案，故提早关闭讨论。Sanmosa 蚌埠 2024年7月13日 (六) 01:29 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

在此提议于用户名方针中限制明显无意义的用户名（如“ADSCCGBDFVDYCVFWGDGDHFS”）。

理由很简单，我认为正常参与维基百科的用户很少会起很杂乱的用户名，因为只会妨碍交流；而破坏者出于恶作剧的目的更有动机使用这样的用户名。这鸭子测试一样，也是有效的经验法则。限制此类用户名可以帮助社群更快速地处理破坏行为。

作为参考，葡萄牙语维基百科有类似的方针，节录如下：

Nome ininteligível, composto por um conjunto de caracteres repetidos ou uma sequência de seis ou mais caracteres aleatórios, como "aaaaaaaaaaaa" ou "8i98uijkwoel3plwç"

难以理解的名称，由一组重复字符或六个或更多随机字符的序列组成，例如“aaaaaaaaaaaa”或“8i98uijkwoel3plwç”

以上。--碟之舞📀💿 2024年7月2日 (二) 10:57 (UTC)[回复]

这样，我会很尴尬，所以(－)反对抱歉，而且很多其他语言维基百科没有这样限制--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 11:01 (UTC)[回复]
没有必要+无法评估意义和混淆度。IP地址同样有区分难度。正常的处理恶意混淆用户名即可。--YFdyh000（留言） 2024年7月2日 (二) 11:21 (UTC)[回复]
认同YFdyh000说法--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 11:23 (UTC)[回复]
(＋)支持 事实证明葡萄牙语维基百科已经利用此规则阻止了扰乱用户在该站活动。--——🦝Interaccoonale（留言・贡献） 2024年7月2日 (二) 11:28 (UTC)[回复]
请问很多其他语言维基百科，为什么不统一使用葡萄牙语维基百科规则呢???因为早期很多都是很杂乱的使用者名称，因为不知取什么名字，所以乱打，才造成有这些人，但并非破坏者，而且满多人有对维基做出贡献，不能因为破坏者取这样名称，而限制很多人权利，这如YFdyh000讲得一样，没有必要+无法评估意义和混淆度--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 11:36 (UTC)[回复]
@HYHJKJYUJYTTY:
请问你改这个名字的意义是什么，有没有特别含义？--唔好阻住我爱国（留言） 2024年7月2日 (二) 12:11 (UTC)[回复]
当初只是为了编辑而已，所以没有认真取名字--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 12:13 (UTC)[回复]
其实你是可以申请改名的。不过，如果我因某一事项想找人讨论，我很难联想你的出现，因为你的名字只是 “随机字元的序列组成（随便改名）”，如果我要ping你，也要记起HYHJKJYTTY的字元组合先，只要忘记其中一个字元，也不能顺利地找你。--唔好阻住我爱国（留言） 2024年7月2日 (二) 12:59 (UTC)[回复]
有那么困难吗，通常可以记前几个字母来找。--YFdyh000（留言） 2024年7月2日 (二) 16:02 (UTC)[回复]
目前从事反纯破坏工作或翻译--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 12:14 (UTC)[回复]
您自己的一些编辑已经在破坏行为的边缘了；并且您既不熟悉英语、也不熟悉汉语（WP:管理员布告板/其他不当行为#HYHJKJYUJYTTY），您的翻译内容已经引起了多位用户的不满。。。--自由雨日（留言） 2024年7月2日 (二) 13:20 (UTC)[回复]
我最初翻译跟他最新版本翻译，根本差不多，先不聊，但我警告后，根本没后续坚持，还有其实跟这个处理方针无关--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:28 (UTC)[回复]
抱歉我熟悉汉语，只有不熟悉英语而已--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:30 (UTC)[回复]
是不是不朔及既往就可以？让HYHJKJYUJYTTY大这样的ＩＤ变成绝版造型也是好方法。 --窝法乙烷 儿法梦碎 2024年7月2日 (二) 13:13 (UTC)[回复]
不朔及既往，算是不错作法，但限制没有意义--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:23 (UTC)[回复]
很多用户名对用户本身有其意义，不过是对外人而言无法理解罢了。比如，请问诸位在点进KaurJmeb君的用户页之前会觉得这个用户名有意义吗？再者，纵使我们假设扰乱者才会乱取用户名，我对提案的政策多大程度上能够限制扰乱者表示怀疑，因为要取一个有意义的用户名也不是多难的事。去维基词典点击随机页面就必然可以得到一个“有意义”的词汇，这不比乱敲几下键盘难多少。Irralpaca（留言） 2024年7月2日 (二) 13:36 (UTC)[回复]
认同，无意义使用者名称跟防止破坏者，关联程度不高，因为确实破坏者可以取有意义名称--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:42 (UTC)[回复]
@YFdyh000、Irralpaca：感谢留言。目前我只是提出了大体方向，具体方针怎么写还没有想好。考虑到汉字的性质肯定不能照抄ptwiki的方针。
至于您给的例子，我认为是细节上如何界定“无意义”或者“难以辨识”的问题。我的想法是那些使用常识直观判断不存在任何有意义的可能性的用户名（比如KaurJmeb这个名字的熵值其实不是很高，而且用户给出了解释）。第二个问题的话，本提案只是想进一步规范用户名，方针本身就是一点一点优化的，反破坏的效果只要有就行，并且长远来看禁止这样的名字对社群没坏处。--碟之舞📀💿 2024年7月2日 (二) 13:58 (UTC)[回复]
想要建议这方针必须是不影响共识之前的使用者权利，还有必须厘清无意义使用者名称跟防止纯破坏者，关联程度，但目前为止看不出来--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 14:03 (UTC)[回复]
您可以使用现代标准汉语发言吗？--——🦝Interaccoonale（留言・贡献） 2024年7月2日 (二) 14:29 (UTC)[回复]
平行时空的人你好--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 14:36 (UTC)[回复]
阁下您那整句到底是什么意思？您前半是在说建议这个方针不要溯及既往（还是在说不要损害既得者利益所以反对提议？），然后后半是在说还需要进一步厘清“无意义的名称”跟“破坏者”的关系吗？阁下您的用词感觉似乎漏掉好几个字词且顺序混乱，读得颇吃力。--WiTo🐤💬 2024年7月2日 (二) 14:59 (UTC)[回复]
我什么时候建议不要溯及既往，是别人建议，我认为好，但限制没有意义，文字要看懂，根本没吃力，真的不要怪别人--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:08 (UTC)[回复]
我用词并没有漏掉好几个字词，那是你看很多人讨论，造成混乱--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:19 (UTC)[回复]
提醒你碟之舞目前还没有正式方针草案--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:21 (UTC)[回复]
无法判断。可发音或者用单词组成的用户名，可能反而是用软件（字典）生成。不需要朗读，未见规范用户名的需求。明显的弊大于利，无论短期长期。--YFdyh000（留言） 2024年7月2日 (二) 16:08 (UTC)[回复]
不认为有必要限制。因为主观标准不同。YFdyh000、Irralpaca、T45614631这种难道能直接看出有什么意义？甚至Ericliu1912，也是因为社群知道本人使用Eric Liu的称呼，才显得有意义。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月2日 (二) 15:23 (UTC)[回复]
不正规统计，没七成，至少超过五成都是没有直接意义，认同Eric Liu 主观标准不同，所以很难怎么处置，确实不必要--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:30 (UTC)[回复]
您到底在说些什么？--——🦝Interaccoonale（留言・贡献） 2024年7月2日 (二) 15:32 (UTC)[回复]
所以你要表达什么--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:36 (UTC)[回复]
是我在问你，你在表达什么。--——🦝Interaccoonale（留言・贡献） 2024年7月2日 (二) 15:38 (UTC)[回复]
我表达反对意见，认同其他人类似意见，如果你是为了反驳而反驳，大可不必--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:42 (UTC)[回复]
老实说，我的还真的没有意义（是当时键盘随便码的数字），之前曾有动念想改，但一直迟迟没去申请。不过我个人对这议案期望能带来的效果感到怀疑（以及对标准拿捏有疑虑），但不试不知效果，故现在保持中立。--WiTo🐤💬 2024年7月2日 (二) 15:49 (UTC)[回复]
阁下还是申请更名吧，有时想找阁下老费劲了：D（我只能记前3个数字）--微肿头龙（留言） 2024年7月3日 (三) 15:00 (UTC)[回复]
支持理念，但判定过于主观，难以合理执行。
  • “有意义”与否尚不能保证用户名“便于辨识”。若有用户使用仓颉码或注音码来建立帐号，用户名看起来也像是乱码，确实有实际意义却仍然不便于辨识（并非所有人都懂得仓颉或注音）。
  • “有意义”与否应视用户是否能解释自己的用户名的意思。如果能大致给个有道理的解释（例如过往网名），那么就显然不是“没有意义”；如果解释不了的，那显然就只是个乱码。
--路西法人 2024年7月3日 (三) 00:28 (UTC)[回复]
另，同其他用户的部分意见，不同意将“无意义用户名”直接归于“防止破坏”。任何此类规范都是应以“阻碍协作”为推进前提，直接标签为破坏未免过甚。--路西法人 2024年7月3日 (三) 01:47 (UTC)[回复]
反对，本身用户名就是主观性或者对于使用者来说就有意义的，站在旁人的角度自然就是没意义的，这样实际上会令本社群为了“审核”用户名的“意义”而官僚化。破坏和用户名是否对于用户本人或者旁人并无直接关联。不应该将用户名的“有意义”性作为破坏或者提前阻止的推断，对应用户做出破坏的编辑的时候再说。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月3日 (三) 01:00 (UTC)[回复]
(－)反对，在无恶意的情况下，选用什么样的用户名是用户的自由。--Leiem（留言·签名·维基调查） 2024年7月3日 (三) 02:49 (UTC)[回复]
(－)反对，无意义，完全是主观认定他人用户名不合适，有违WP:假定善意。——— 红渡厨（留言・贡献） 2024年7月3日 (三) 03:42 (UTC)[回复]
(－)反对，讨论使用者名称有没有意义没有意义--银河市长—☎️— 2024年7月3日 (三) 05:45 (UTC)[回复]
(－)反对，“有意义”的认定标准非常主观。用户名随时间的增加会越来越多，“有意义”的选项会越来越少。--微肿头龙（留言） 2024年7月3日 (三) 14:56 (UTC)[回复]
有一说一，“意义”本就是人为赋予的，所以所有用户名既可以全都是有意义的，也可以全都是没意义的。Sanmosa 蚌埠 2024年7月3日 (三) 23:56 (UTC)[回复]
以“是否有意义”的角度来看会遭到反对。我个人认为这里更多是“是否对编者互相沟通造成阻碍”。上方已有举出一个例子：阁下还是申请更名吧，有时想找阁下老费劲了：D（我只能记前3个数字）像乱码、纯数字用户名，不好记，容易妨碍沟通。--0xDeadbeef (留言) 2024年7月4日 (四) 06:01 (UTC)[回复]
沟通障碍同样难评。用户名与签名无关，算制造障碍吗。您的用户名我也记不住。有特点的用户名或签名出现仿冒，是最有可能的，但很多仍难鉴定是否恶意。假设取名“日期2024年7月4日”。又如站内的范、范博，我会不自觉的记混，但也许只有我。--YFdyh000（留言） 2024年7月4日 (四) 08:39 (UTC)[回复]
实际上大家的使用者名称多半没什么“客观”意义。这同时也是网路文化特性，太有意义反而增加辨认风险。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月5日 (五) 14:33 (UTC)[回复]
(！)意见：直接限制用户名或许太过严格，那么是否可以在“创建账户”页面“用户名”输入框下加一行类似“推荐不要采用长串无意义字符”的建议呢？不强制要求，就像“电子邮箱地址”也是推荐填写。这类提示相信是可以影响到大量有意作出善意编辑的人，让本来可能就随便输入几个字符的新用户改取有意义用户名的。--——自由雨日（留言・贡献） 2024年7月5日 (五) 00:16 (UTC)[回复]
不反对，虽说效用大不大另说。Sanmosa 蚌埠 2024年7月5日 (五) 12:34 (UTC)[回复]
不认为有意义，如果当事人自己觉得好和方便，可能不会听劝。目前没有推荐“采用长串无意义字符”，故猜测不少是用户自主选择，但修改用户名是有点麻烦的。--YFdyh000（留言） 2024年7月5日 (五) 15:27 (UTC)[回复]
不一定是用户“自主选择”用户名，我认为至少有一半无意义用户名只是注册时没有多想、懒得取名（没有想到需要和社群讨论和互动、没有想到编辑记录中会经常出现用户名、没有想到个人的多比贡献问题可能共同会被社群指导，等等），而不是他们有意“选择”了无意义字符串。有这种提示至少可以使这半用户稍微输入一点不那么随机的字符串。--——自由雨日（留言・贡献） 2024年7月5日 (五) 15:35 (UTC)[回复]
要不我给个新思路：我们先不要执著于“有没有意义”的事情，我们能否界定甚么是“乱码”？Sanmosa 蚌埠 2024年7月6日 (六) 11:05 (UTC)[回复]
可以。其实我想限制的就是乱码，只不过觉得这个词不适合出现在方针里所以没提。--碟之舞📀💿 2024年7月6日 (六) 11:08 (UTC)[回复]
葡萄牙语维百的方针我觉得应该是能够界定的：难以理解的名称，（且）由一组重复字符或六个或更多随机字符的序列组成。至于什么是（六个以上）“随机”字符，我觉得应该可以依照常识判断吧……（虽然我个人是倾向不必强制限定，只向新注册用户“推荐”不要采用乱码的，那也就无需定义，“乱码”“无意义”或类似的词语已经足够）——自由雨日（留言・贡献） 2024年7月6日 (六) 11:11 (UTC)[回复]
那就取决于社群是否认为“随机字元”能被妥为定义了，如果社群认为不能的话，那强制性规定应该是不太可能了。Sanmosa 蚌埠 2024年7月6日 (六) 11:56 (UTC)[回复]
不认为可界定。按上文，5个随机字符组成的序列可规避。--YFdyh000（留言） 2024年7月6日 (六) 13:10 (UTC)[回复]
@Diskdance、Interaccoonale：根据我对这里的讨论情势的观察，我认为社群普遍不太认同“随机字元”可被妥为定义，并因此或出于其他原因不赞同限制无意义用户名的提案，因此我想让两位再重新想想是否还要继续推进此案。Sanmosa 蚌埠 2024年7月7日 (日) 09:54 (UTC)[回复]
还是那句，编者能解释的就不是乱码。硬是给我编得出一个合理的解释就行。甚至说是以前在其他平台就已经有用过的乱码用户名，现在在维基百科重用，也是有意义的。--路西法人 2024年7月9日 (二) 02:49 (UTC)[回复]
(－)反对，有无意义无法界定，即便本为一段乱码，使用者在被问及其意义时亦可辩称：这是一段密码，恕我无法透露其内容。如若进一步强求解释，任何人也可以就一段乱码为其赋予意义，只要联想便是了。因此这属于无法界定的规则，也便实质上无法执行。Boreas Sawada 2024年7月8日 (一) 22:01 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

MOS:ACG配音部分移植到MOS:TV成为正式指引。

草拟方针:

1.一般只记载原作国家地区及中文维基主要地区的配音员，以符合大多数中文维基使用者所关心。

3.原作地区和中文地区的配音请尽量提供可靠的来源。(例如来自发行方、播出平台和配音公司的一手来源以及媒体报道的二手来源。)

2.配音员的标示请使用全称，避免使用有消歧义争议的“CV”。--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月3日 (三) 11:43 (UTC)[回复]

原因是因为本人在超级战队条目配音员问题上与@DarkWizardCody起过争执（该用户主张应使用可靠的二手以及三手来源不应使用一手来源。)以及本人与香港配音社群和台湾配音社群的争执。（对官方未公开配音人员资讯的作品主张使用爱好者社群网站以及使用原创总结的手段得到的配音员资讯。)顺带ping以下其他相关专题的用户。@HK5201314--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月3日 (三) 11:54 (UTC)[回复]
@甜甜圈真好吃:
我只可说，所有规条也是相辅相成。
1. 你要“一般只记载原作国家地区及中文维基主要地区的配音员”，但你维没有完全禁止列出其他地区的播放资料（规条不对称 )，什至有编辑者@Factrecordor认为中维应接纳世界各地的资讯。
2.WP:使用全称，可以redirect到这个。
——
总括而言，可以把这个提案放在#电视剧演员名单序列一并讨论，反正两个的特性是一致。--唔好阻住我爱国（留言） 2024年7月3日 (三) 14:58 (UTC)[回复]
语言不超过3种时，我感觉条文1或可不应用，或者使该条文无强制力。条文2，如果官方资料使用呢，ACGN有时常用CV。不算反对，只是是否要如 配音（CV）等表述。条文3，为什么不是所有。或者，有哪些不够可靠的来源是可明确接受的。--YFdyh000（留言） 2024年7月3日 (三) 15:03 (UTC)[回复]
论点3目前已受MOS:TV规管，所以先说在上方一并讨论。--唔好阻住我爱国（留言） 2024年7月3日 (三) 15:19 (UTC)[回复]
  • 首先，应说清楚与DarkWizardCody、香港配音社群、台湾配音社群的争议是什么。是否你们之间有人想收录英语、法语等等的外语配音员名单？按之前其他讨论中透露，似乎不是这样，而是连收录某些中文地区的华语配音员名单都受到阻止。如果我说得没错的话，那么眼前的问题，其实本来和我主张的“中维应接纳世界各地的资讯”没有关系。若草拟方针是全新的，那么“一般可记载原作国家地区及中文维基主要地区的配音员”更能针对眼前的问题。然而，这是参考自MOS:ACG，是因为特摄爱好者多与ACG重叠，但又不属于ACG范围吧，那么应该先看看非ACG与特摄条目，究竟有没有收录外语配音员名单（原产地以外）的习惯，如有，应通知那边活跃编辑者前来讨论，如没有或根本不存在这样的条目，那就跳到下一点。
  • 不论我有没有搞错眼前的问题，对于我主张的“中维应接纳世界各地的资讯”，我判断的大原则是视乎设数量限制及中文地区优先之后，能不能有效解决或改善问题。配音员名单和之前讨论的播放或重播资讯不同，它们是不能简述的，所以问题会更难解决，只收录中文地区恐怕是合理取舍。条文既写了“一般”，将来发现特例再讨论也可。我在这里只强调，资讯性质不同，所以处理手法也可各异，不必视为不对称。
--Factrecordor（留言） 2024年7月3日 (三) 18:03 (UTC)[回复]
然而非ACG和特摄类的条目的话也有收入配音员资讯例如韩剧来自星星的你、日剧极主夫道。--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月4日 (四) 01:35 (UTC)[回复]
重点在于配音资讯有没有必要收录（DarkWizardCody主张不收录配音资讯)以及配音资料来源的可靠性（港台配音社群对于无一手来源提供资料的主张使用原创总结内容以及配音爱好者网站作为来源）--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月4日 (四) 03:42 (UTC)[回复]
既然下面也提到MOS:ACG吵了这么久就是无法指引化，我觉得这有点像香港修例事件一样，为了解决一件事，引入会影响很多很多东西的条例，可能引起很多疑虑、轩然大波，倒不如寻求更具针对性的修订。在这些争议中最值得讨论清楚的是什么是合适来源。至于DarkWizardCody，这个名字不时都出现在编辑争议中。我认为主张不收录配音资讯是很个人的见解，向来在很多作品条目都被收录非原产地的配音员名单，可见这是不少人的习惯，除了来源问题，看不出什么现有条文能作为有力的理据反对收录。--Factrecordor（留言） 2024年7月4日 (四) 15:36 (UTC)[回复]
有没有发觉一件事，就是DarkWizardCody遇上编辑争议时不参与讨论。这个讨论已ping他3日有多，但他仍没有任何回应或让步，还以高高在上的心态指导编辑工作。有一种霸住/占领条目之嫌，但管理员对他的态度是“不作为”/“没有任何反应”。--唔好阻住我爱国（留言） 2024年7月5日 (五) 00:27 (UTC)[回复]
说到合适来源最大的问题就是作品本身能不能成为来源(部分作品的配音人员名单一般只在作品本身的制作人员列表标注而不会标注平播放平台的制作人员列表内)以及部分未认证的配音公司社交媒体账号能否作为可靠来源使用。(部分配音公司由于条件限制只会在社交平台发布。)(DarkWizardCody相关:DarkWizardCody一般只回应在讨论页的回复不会接受ping。)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月5日 (五) 13:41 (UTC)[回复]
DarkWizardCody是会主动使用互助客栈机制的，也懂得引用条文。没这样做，恐怕反映他自己都觉得在“法理”上占不到便宜。--Factrecordor（留言） 2024年7月5日 (五) 15:32 (UTC)[回复]
日本动漫的配音指引能适用于全部电视专题条目？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月3日 (三) 18:36 (UTC)[回复]
因为配音的作品不只是动漫还有电视剧、纪录片等其他类型的电视作品需要规范。--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月3日 (三) 23:09 (UTC)[回复]
MOS:ACG吵了这么久就是无法指引化，感觉是否具有参考价值？另外倾向用“移植”而不是“移动”的说法。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 03:10 (UTC)[回复]
我认为一手来源（例如作品官网角色来源，这个例子可能还包括代理商发布平台的介绍或者社交媒体上的介绍？）可以使用。“如果维基百科使用一次文献，仅当该文献被可信赖的出版社发表过，比如，由法庭速记员出版的庭审记录，或出现于资料汇编中的历史文献。我们不可以使用未经可信赖出版者发布的一次文献。”不要只关注后句，而是前句也需要留意，也就是“作品官网角色页面”、“代理商发布平台的介绍”应该对标为“文献被可信赖的出版社发表过”的情况。当然非要觉得“官方网站是不可信赖的，它都懂个屁作品配音介绍”的，那就当我没说过。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 03:19 (UTC)[回复]
非独立的一手来源？“如由大学出版社或主流报纸发表”恐怕在要求编审独立、信任主流出版物的查证水平。不过，某些正式出版物的准确性，可能还不如其他资料，尤其是宣传稿或仅提及。--YFdyh000（留言） 2024年7月4日 (四) 08:26 (UTC)[回复]

提议引入每周协作

俄语维基的首页上有名为“每周协作”（也就是主题周）的协作项目，专对某个话题的条目进行改善或新建（清绿链），并对参与协作的用户进行奖励。个人认为，这种协作项目可以大幅提升或改善中文维基的条目数量和质量，并鼓励更多熟悉相关话题用户参与维基百科的编辑。提议中维也引入这种协作方式改善条目（或模板及文件）的质与量，不知社群有何看法。--Azure✦留言 请关注中维大量绿链堆积 2024年7月4日 (四) 07:50 (UTC)[回复]

给个链接：ru:Википедия:Кандидаты_на_работу_недели-Azure✦留言 请关注中维大量绿链堆积 2024年7月4日 (四) 08:22 (UTC)[回复]

感觉跟已近乎荒废的WP:COTW相似，要不要考虑把那边翻新一下比较好？--WiTo🐤💬 2024年7月4日 (四) 08:11 (UTC)[回复]
这些东西已经挂了很久了，而且还是用户自主发起，不是老用户或许都找不到这些东西。个人感觉不如采用俄维版本，由用户提名每周协作主题并在首页展示，这样用户参与的积极性更高。--Azure✦留言 请关注中维大量绿链堆积 2024年7月4日 (四) 08:25 (UTC)[回复]
纵使如“每周翻译”，效果亦不是很好，遑论规模更大的“每周合作”。我想若要复兴条目多人合作撰写，首先需要讨论如何集中社群量能。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月5日 (五) 04:49 (UTC)[回复]
中文维基也有Wikipedia:协作计划，大家一起翻译某一个条目，最近一个完成的条目是于2021年完成的哺乳动物。不过要花许多的心力。我觉得中文维基各领域的人力较不平均，因此若要协作的是人力较不足的领域，效果自然较弱。另外，“要怎么协作”也是一个问题。WP:COTW和Wikipedia:每周翻译其实也是协作计划。
以我觉得，"大家合写一个条目"的作法实务上较不容易, 有可能各段意思都对, 但加起来看就是怪怪的。若是要针对模版，大家合作消绿链，就可以大家各写各的条目，但每一个绿链都对应一个条目，工作量可能很大（总不好因为要消绿链，就创建一个小作品充数吧）。可以考虑一下中文维基以往类似的计划，再思考中文维基适合用什么方式推协作计划。--Wolfch (留言) 2024年7月4日 (四) 08:24 (UTC)[回复]
目前的问题主要是社群协作项目得不到推广、宣传，大家都各玩各的。类似俄站的每周协作就比较显眼、及时更新同时给予维基奖励鼓励编者，个人认为这种方式能够吸引更多编者，这就是我提议模仿俄语版的原因。当然，我也期待其他更好的协作方法。--Azure✦留言 请关注中维大量绿链堆积 2024年7月4日 (四) 08:46 (UTC)[回复]
过往是存在送过实物奖励的活动，但现有环境很难大量推展（个人信息隐私隐忧等原因）。没有实物奖励下，只靠“爱”就更难维持。如前，过去就有各种类似的合作编辑活动或者项目，如果有需要的话，可以重新接手这些项目来推进。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 00:44 (UTC)[回复]

提案修正Wikipedia:用户名#更改用户名

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

提案背景如下：

  • 目前本地用户更名方针中，限制了对于“少量甚至没有编辑纪录的帐户”的更名请求。

Are zero edit-renames allowed?
They are allowed. Some users use Wikipedia accounts for saving articles to reading lists on Wikipedia apps and they hardly make any edits. Earlier such requests were rejected with a claim that they save server resources, but that's no longer true [12] and we shouldn't be worried about server resources.

——m:Global_renamers/FAQ#Are_zero_edit-renames_allowed?
  • 因此，本人认为应移除本地之“一般不会为只有少量甚至没有编辑纪录的帐户重新命名”相关叙述。另外，该段落其后的文字叙述语句极不通顺，容易妨碍理解，因此本人亦提出若干修订，使之更容易依循。

方针修订方案如下：

现行条文

全域更名者和监管员可以为用户修改其用户名；可至本地或元维基提出申请，亦可使用Special:GlobalRenameRequest表单进行申请。一般不会为只有少量甚至没有编辑纪录的帐户重新命名，因有更快及更容易的途径——注册一个新的帐户。

当更改用户时，隶属于现有帐户的贡献纪录将会被移至新名旗下，当中包括页面历史、差异、日志及用户贡献等纪录的更动。至于讨论页中的签名则会继续使用原有的用户名。虽然这些签名可以依靠人手改动过来，然而如果不是因为私人理由而想把所有有关之前用户名的资料删除且越多越好的话，我们不建议您这样做。另外，这些旧名依旧会存在于讨论页面的旧版本中。用户更动的纪录会详列于用户名变更日志中。

提议条文

全域更名者和监管员可以为用户修改其用户名；可至本地或元维基提出申请，亦可使用Special:GlobalRenameRequest表单进行申请。

当用户名更改后，原帐户的所有贡献记录将会被转移至新用户名下，包括页面历史、编辑差异、日志及用户贡献等。至于讨论页中的现存签名则会保持原有的用户名不变。虽然可以手动更改这些签名，但除非出于隐私等特殊原因需要彻底删除旧用户名的相关资料，否则我们不建议您这样做。另外，这些旧用户名依旧会保留在讨论页面的历史版本中。所有用户名更动的纪录均会详列于用户名变更日志中。

以上。-Peacearth（留言） 2024年7月4日 (四) 18:09 (UTC)[回复]

副知本地活跃的全域更名员@Jianhui67、Mys_721tx、Wong128hk以及近期经常在Wikipedia:更改用户名协助结案的@ChasingAir。-Peacearth（留言） 2024年7月4日 (四) 18:41 (UTC)[回复]
(＋)支持此提案。Sanmosa 蚌埠 2024年7月4日 (四) 22:23 (UTC)[回复]
(＋)支持：那句看起来原本是从英文维基百科翻译过来的，不过既然全域更名无此限制，删了好像也无所谓就是。--冥王欧西里斯（留言） 2024年7月5日 (五) 03:31 (UTC)[回复]
应该是没什么争议的修订。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月5日 (五) 04:47 (UTC)[回复]
(＋)支持此提案。感谢Peacearth的通知。Jianhui67（留言） 2024年7月5日 (五) 17:02 (UTC)[回复]
这个提案需要考虑到不妥当的用户名问题。不妥当用户名的用户通常已经被封禁，不但无法提出相关申请，就算有途径能够改名，需时亦较注册新帐号要长，这对于处理封禁申诉来说也缺乏效率。--AT 2024年7月6日 (六) 13:29 (UTC)[回复]
我觉得这可以用常识来处理，没必要为此明文规定，毕竟这提案主要是想要与Global rename policy看齐，而practically让管理员建议使用了不妥当用户名的用户注册使用妥当用户名的新帐号与提议的修改并不冲突。Sanmosa 蚌埠 2024年7月6日 (六) 13:49 (UTC)[回复]
@AT：这个提案是取消本地对于“少量甚至没有编辑纪录的帐户”的旧有改名限制，并不影响不妥当用户名问题的处理方式。相关问题的处理仍然照旧，并没有限制他们一定要使用何种途径改名或者注册新帐号。另外补充一点，即使相关用户被封禁也不会无法提出相关申请，因为我们经常会在 Special:GlobalRenameRequest 接收到相关申请。事实上，本提案乃是全域更名现行实务作法，其实可以说只是事实性修订而已，一点都不会影响到您考虑的部分。唯一影响到的，就只是不会再因为某用户只有少量或没有任何编辑纪录而拒绝他的更名请求而已。-Peacearth（留言） 2024年7月6日 (六) 18:44 (UTC)[回复]
既不影响，那我没有异议。--AT 2024年7月7日 (日) 00:11 (UTC)[回复]
(＋)滋磁--L'Internationale, Sera le genre humain! ✏️ 2024年7月10日 (三) 15:38 (UTC)[回复]
注：此留言已被原作者（User:Sanmosa）移除。2024年7月13日 (六) 01:50 (UTC)[回复]
根据WP:共识#提案讨论及公示时间，“互助客栈及征求意见中的提案仅在7日内无新留言时或已讨论达30日后，方可在已取得共识的前提下公示”，“与提案本身无关的意见……不视作此条文所指的‘新留言’与‘相关意见’”，现公示此提案7日。Sanmosa 蚌埠 2024年7月13日 (六) 01:53 (UTC)[回复]

关于同一网页参考资料不同版本的引用问题

我正在编写条目中科宇航。条目中部分内容的参考资料以前在该企业官网一页面上，但去年该网页内容进行了修改（但标题、url均不变）。

由于新旧两版本的网页都被互联网档案馆所记录，我该如何处理新旧参考资料？我目前的做法仅仅是把旧版设为dead-url=yes，并区分了参考资料名和引用时间。

链接：

--Yusancky（留言） 2024年7月6日 (六) 06:16 (UTC)[回复]

这种处理方法初步看上去没甚么大问题。Sanmosa 蚌埠 2024年7月6日 (六) 11:06 (UTC)[回复]
参考资料的模板只支持一个连结，可以用备注的参数加注另外一个连结，或者使用2个<ref>--Rastinition（留言） 2024年7月6日 (六) 11:09 (UTC)[回复]
我相信他是在代码上把新旧两版当成两个分别的来源处理的，也就是你所说的第二种办法。Sanmosa 蚌埠 2024年7月6日 (六) 11:53 (UTC)[回复]

关于被无限期封禁者的用户页清空问题

我有一个问题，就是根据观察，被无限期封禁者（及被全域锁定者、被WMF封禁者）的用户页基本上都会被清空，然后再挂上各类无限期封禁模板。请问清空用户页这点在中维有无相关规定指引？反正在英维，无限期封禁者的用户页不会被清空，只是会额外挂上无限期封禁模板而已。--BigBullfrog（𓆏） 2024年7月8日 (一) 03:32 (UTC)[回复]

请参阅这里。Python6345（留言） 2024年7月8日 (一) 05:50 (UTC)[回复]
这条文仅限indef封锁。全域锁定虽然实务上比照indef封锁的方式办理，但并无本地成文规定。全域禁制一般不是本地处理的。Sanmosa 蚌埠 2024年7月8日 (一) 05:58 (UTC)[回复]
由于 维基百科:不限期不等于永久 不是方针，故管理员可以清空使用者页面。--唔好阻住我爱国（留言） 2024年7月8日 (一) 14:54 (UTC)[回复]

原文重定向的可靠来源

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

刚刚细读才发现WP:RFAL有这么一句“创建者应在重定向页面加入证明外文名称的可靠来源，除非外文名符合以下豁免条件之一：”。请问能在重定向里放来源的吗？如果不能要怎么执行这一句？还是当初制定方针时写错了？@自由雨日：--微肿头龙（留言） 2024年7月9日 (二) 13:58 (UTC)[回复]

起因可见：WP:页面存废讨论/记录/2024/07/09#批量提删--——自由雨日（留言・贡献） 2024年7月9日 (二) 14:00 (UTC)[回复]
技术上可能，编辑摘要或HTML注释，重定向语法后面印象中也可行。不曾注意到该方针的存在，我怀疑这是否“反映社群共识”。Special:Diff/55642771，提案可能未获充分讨论。--YFdyh000（留言） 2024年7月9日 (二) 14:41 (UTC)[回复]
但实务上较困难吧？我也不觉得有人会特别注意重新导向有无来源，最好是能直接附在重新导向目标页面中为宜。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月10日 (三) 12:20 (UTC)[回复]
@微肿头龙、自由雨日、YFdyh000、Ericliu1912：如果大家不反对的话，我建议把“创建者应在重定向页面加入证明外文名称的可靠来源”改为“创建者应在条目本身或重定向页面的讨论页加入证明外文名称的可靠来源”。Sanmosa 蚌埠 2024年7月13日 (六) 01:37 (UTC)[回复]
(＋)倾向支持，甚至“在讨论页”就是我一开始（错误）理解的（见WP:页面存废讨论/记录/2024/07/09#批量提删）。不过如果只是在编辑摘要中加入也未尝不可，至少只要某编者在建立时提供了来源，就不能说他是“未遵守方针滥建外文重定向”。--——自由雨日（留言・贡献） 2024年7月13日 (六) 01:47 (UTC)[回复]
放在编辑摘要并非不可，但遇上失效连结的时候不好处理，放在讨论页至少还能存档来源。Sanmosa 蚌埠 2024年7月13日 (六) 01:49 (UTC)[回复]
(＋)支持，不过我不觉得会有多少人加来源。--微肿头龙（留言） 2024年7月13日 (六) 04:37 (UTC)[回复]
建议改为“条目本身或重新导向页面的讨论页”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月13日 (六) 18:12 (UTC)[回复]
不反对，已调整。Sanmosa 蚌埠 2024年7月14日 (日) 22:34 (UTC)[回复]

有关巡查豁免权的门槛

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:巡查豁免权、Wikipedia talk:权限申请。

近期希望提名一位有突出贡献且编辑及创建过多篇GA及DYK的用户获得巡查豁免权，希望减轻巡查的压力，奈何发现该君创建条目数量离75还有一定距离。但我发现巡查豁免权的申请门槛，多处表述均有不同：

请问75条的门槛是否为强制？建议以上各处应统一表述。--Tim Wu（留言） 2024年7月9日 (二) 14:54 (UTC)[回复]

我倾向于并非强制性，能建GA的话想必也不会出大问题。Sanmosa 蚌埠 2024年7月9日 (二) 15:01 (UTC)[回复]
我记得以前有未达建议标准而授权的例外情况。--千村狐兔（留言） 2024年7月9日 (二) 15:24 (UTC)[回复]
改掉编辑提示吧。信任和质量为主，数量不能代表什么，创建一百个同质化的有效条目不能证明其他方面，除非他不会涉足创建其他条目。--YFdyh000（留言） 2024年7月9日 (二) 16:23 (UTC)[回复]
此要求并非强制，应考虑统一使用“建议门槛”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月9日 (二) 19:10 (UTC)[回复]
我自己目前的巡查豁免权就是在满75条前被推荐拿到的，当时帮我申请的Dewadipper阁下以IAR的理由替我申请了，供上当时纪录。--WiTo🐤💬 2024年7月10日 (三) 07:58 (UTC)[回复]
“Wikipedia:权限申请”是程序方针，“Wikipedia:巡查豁免权”是说明具体情况（但不是方针、指引），“Wikipedia:权限申请/editnotice/zh”是申请时的条件说明。第一个的规则性更明显，但实务上是否认定需要或者强制需要75条条目？可以认定“75条”是建议，或者干脆让后两个复述“Wikipedia:权限申请”的说明，也就是不限制条目数量要求。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月10日 (三) 08:23 (UTC)[回复]
@TimWu007、Manchiu、YFdyh000、Ericliu1912、WiTo7946、Cwek：通知一下：考虑到各位都倾向于认为75是建议门槛，而编辑提示显然地从任何意义上都不可能是方针指引条文，因此我已经将所有相关的编辑提示（zh版、繁简体版、6种地区模式版）里的“基本”都改成“建议”了。我相信这里的潜在问题已经基本解决。Sanmosa 蚌埠 2024年7月10日 (三) 12:12 (UTC)[回复]
建议把Wikipedia:巡查豁免权升级为指引，以便看齐其他权限页面和门槛。L'Internationale, Sera le genre humain! ✏️ 2024年7月10日 (三) 15:43 (UTC)[回复]

有关公布管理人员任免案投票人数等事

现行管理人员任免案，均采行安全投票，且不提供投票者名单，仅投票管理员（监督员、监管员）可以查阅。鉴于安全投票制度之初衷，暨当事人安全及隐私等疑虑，不公开具体投票者尚能理解。然而，或许应考虑定期公布投票人数（情况允许者，并应先行公布有资格投票者人数），俾便社群追踪任免案之整体动态。另不确定相关方针与指引本来是否有明文规定应提供投票者名单？一并请社群讨论商榷。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月13日 (六) 12:30 (UTC)[回复]

重提注音格式要求

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:格式手册/序言章节。

先前讨论总体上有通过的希望，但是后来因讨论不活跃存档。现在10个月后重新提案：

在格式手册“表格”一章后加入

提议条文

注音

条目名及其别名中某字不属于常用字，或者属于常用字的不常见读音的（如有特殊读音的姓、特定领域专有读音等），推荐在其首次出现（一般为条目定义句）处注音。

为确保中文维基百科对常用字的定义不存在任何地域中心的问题，确定本维基的常用字范围采取如下方法：

  1. 在以下三个常用字表中均出现的汉字视为中文维基百科的常用字：
    1. 《通用规范汉字表》的一级字或二级字（共6500字）（中国大陆）[1]；
    2. Big5码定义的常用字（共5401字）（台湾）；以及
    3. 《常用字字形表》（共4762字）（香港）[2]。
  2. 由条目的需要的前置知识可以推断读者知道某字的读音的，认为是常用字，比如在2-氨基-7,7-二甲基-2',5-二氧亚基-5,6,7,8-四氢螺［苯并吡喃-4,3'-吲哚啉］-3-甲腈中无须注明“腈”字的读音，但是在腈中需要；
  3. 根据编者实际调查，可以找到语料证明在两岸四地都常用的字。

编者决定是否注音时，应该考虑到两岸四地的使用实际和语言流变。在判断过程中，仅有繁简或常用异体差别的汉字均视为同一汉字（如“羣”（香港）与“群”（中国大陆、台湾）视为同一汉字）。

为字词注音时，编者可以自由选择在文章内标注，也可以外链至维基词典。

如果使用行内注音，推荐使用字词转换机制在不同变体下分别展示各地区模式适用的注音模式：

  1. 就所有简体模式而言，使用汉语拼音[3]；
  2. 就台湾正体模式而言，使用注音符号；
  3. 就香港繁体与澳门繁体模式而言，由于香港与澳门的读者普遍均以粤语（而非官话）学习中文书面语，因此：
    • 在有粤语同音常用字的情况下，标注该常用字或粤拼，但两者不可在同一条目中混用；
    • 在没有粤语同音常用字的情况下，标注粤拼。

可使用{{zy}}来实现顶头标注。

如果外链至维基词典，应该保证目标词条中有记录读音，并且包含条目中的使用情况。

  1. ^ 马来西亚与新加坡在改用简体字时直接沿袭中国大陆当时的《现代汉语通用字表》为其标准。由于《现代汉语通用字表》于2013年在中国大陆已停止使用，此处以中国大陆的现行常用字表权充马来西亚与新加坡的常用字标准。
  2. ^ 澳门没有自己的常用字表，因此此处以香港的常用字表权充澳门的常用字标准。
  3. ^ 马来西亚与新加坡在改用简体字时同步由注音符号改用汉语拼音。

现在各个方案的样子：

  1. 富勒氏长爪鹡鸰（“鹡”，拼音：jí，注音：ㄐㄧˊ，粤拼：zik3、“鸰”，拼音：líng，注音：ㄌㄧㄥˊ，粤拼：ling4，中国大陆作福氏长爪鹡鸰，南非语：Angolakalkoentjie。学名：Macronyx fuelleborni）是……（不用字词转换的行内）
  2. 富勒氏长爪鹡鸰（“鹡”，拼音：jí“鸰”，拼音：líng，中国大陆作福氏长爪鹡鸰，南非语：Angolakalkoentjie。学名：Macronyx fuelleborni）是……（用字词转换的行内）
  3. 富勒氏长爪鹡（jí）鸰（líng）（中国大陆作福氏长爪鹡鸰，南非语：Angolakalkoentjie。学名：Macronyx fuelleborni）是……（{{zy}}）
  4. 富勒氏长爪鹡鸰（中国大陆作福氏长爪鹡鸰，南非语：Angolakalkoentjie。学名：Macronyx fuelleborni）是……（{{wikt sup}}）
  5. 羟基（汉语拼音：qiǎng；注音符号：ㄑㄧㄤˇ；粤拼：keong5 *）（和1不同于最后的星号）
  6. 还有用脚注的不演示

另外有台湾大陆香港以及韩国的常用汉字比较表（日文）供参考（感谢118.170.4.163）

cc 原讨论部分参与者@Sanmosa、LuciferianThomas、118.170.4.163、Nostalgiacn：

以上。——落花有意12138 2024年7月14日 (日) 10:04 (UTC)[回复]

维基百科不应该是词典，不应该承载字音教育的需要。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月15日 (一) 00:50 (UTC)[回复]
粤拼难道不是粤语维基百科的事情么？--百無一用是書生 (☎) 2024年7月15日 (一) 02:22 (UTC)[回复]
加粤拼就说应该是粤维的事，不加又说会怠慢。然后新马是不是真的跟随汉语拼音作为教学方案？所以依序的话，最好是不标，次至内链到维基词典，再次至为脚注。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月15日 (一) 03:12 (UTC)[回复]
@落花有意12138：法语维基辞典有个叫{{cmn-pron}}的模板，输入汉语拼音可以自动生成法国远东学院拼音、威妥玛拼音、耶鲁拼音和注音字母（但其他方向就不行）。在下认为：如果有需要的话，可以把这个模板搬运过来，这样就能像Kinder出奇蛋那样，一次过满足四个愿望。📕📙📒📗📘 赌博机构最坚定的反对者 📚📖 2024年7月15日 (一) 04:13 (UTC)[回复]
上一轮讨论中，提到了方针维基百科不是词典的问题。个人观点是支持LuciferianThomas的“连结至维基词典方案”。个人反对在条目内大量标注配音的方案，即当前方案。--Nostalgiacn（留言） 2024年7月15日 (一) 05:41 (UTC)[回复]

技术

《通用规范汉字表》以外的简体字是否应该类推简化

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。

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

这说来有点话长，但日前因为在修理相关条目时遇到了“𫛚”这种字（该字位于Unihan扩充C区），接著就发现小苇𫛚及小葦鳽并不被系统视为是同个字，所以数天前至WP:TS报修。但稍早前微肿头龙阁下提及这是因为该字在《通用规范汉字表》以外的缘故，所以需要一些意见讨论是否应该将可能会使用到的表外字作类推简化（并修改转换表）重定向或移动到合适标题，又或是直接限制仅使用在表内的字或要求使用繁体标题以回避问题。毕竟实质上不少表外字可能已经被经常使用，而导致部分条目标题实质上是繁简混杂的，却因非表内字而无法被正常转换。

另外现在有个问题是如果硬套{{僻字}}转换处理的话，有时候似乎会出现蛮可怕的悬浮文字框，但我一时不太知道怎么处理及触发的。举例来说，在大陆简体模式下大麻鹭属的右侧导航框中的“麻𫛚亚科”悬浮文字。--WiTo🐤💬 2024年5月6日 (一) 16:40 (UTC)[回复]

有多少字？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月6日 (一) 17:39 (UTC)[回复]
老实说我不知道，我目前也只是偶然发现有几个字是这样的状况。但辶、门、金、食、马、鸟、鱼等字旁的字个人猜测可能会有不少这种情形，应该会需要电脑协助筛出有在Unihan扩充区内但不在表内的字。范围上可能从扩充A区就要开始找了，A区的“䴙䴘”疑似就有类似情形（北美䴙䴘属、北美鸊鷉屬、北美鷿鷈屬，不过这组有牵涉到异体字的问题可能不一定真是如此）--WiTo🐤💬 2024年5月7日 (二) 00:33 (UTC)[回复]
根据我近期看到的一些中文学术著作，似乎并没有统一的做法，有人就用繁体字，有人则用简体字（生物类）--百無一用是書生 (☎) 2024年5月7日 (二) 09:36 (UTC)[回复]
仅考虑学术用字的话几百个应该还是有的，但如果范围扩大至所有领域恐怕得去到一千个以上（尤其是古人名、古地名）。--微肿头龙（留言） 2024年5月7日 (二) 01:43 (UTC)[回复]
忘了副知提醒我此事的@微肿头龙阁下及当时先使用了𫛚一字的@Interaccoonale阁下。--WiTo🐤💬 2024年5月7日 (二) 00:40 (UTC)[回复]
这个讨论串是否应该移动到技术版？--——🦝Interaccoonale（留言・贡献） 2024年5月7日 (二) 01:18 (UTC)[回复]
我大概说一下我的想法：
  • 从法律上讲，之前《通用规范汉字表》的草案有规定过表外汉字不类推简化，但是正式版把这一条删掉了，所以含有类推简化偏旁的表外汉字是应该简化的。
  • 从实际应用上讲，《中华人民共和国国家重点保护野生动物名录》对于生物中文名的表外汉字作类推简化处理，大部分正式学术著作也作类推简化处理。
  • 从技术上讲，如果相关的bug实在太多，我不反对改回原状，对于表外汉字在简体模式下显示繁体字。
我之前有思考过比当前的{{僻字}}模板更优雅的渲染方式，我之前想的是根据当前页面中包含的扩展区段字符，自动生成一个含有相关僻字的字体文件（字形档），然后用CSS引入到当前页面中，就可以避免这种恐怖的悬浮文字框（有时候这些文字会被显示在Tools-redirect中以及底部的页面分类里面，会变得尤其可怕）。比如大麻鹭属就会自动生成一个仅含有𫛚字的字体文件（字形档）。
其实如果只考虑自动生成的部分，在技术上还不算太难，以遍黑体为基础字体（字形）就可以，能在服务器端编辑字体文件（字形档）的库也有很多。但是我不清楚要如何跟mediawiki整合起来。
另一种技术上更简单（但是操作上更复杂）的方法就是手动将相关字符拆分出来，然后上传到commons，然后在页面中引用即可。--——🦝Interaccoonale（留言・贡献） 2024年5月7日 (二) 01:31 (UTC)[回复]
若根据NC:COMMON的话，那就应该是要随名录名称类推简化没错了。但希望能以操作上简易的方式处理，不然像我这种电脑技术笨蛋恐怕就不会操作了，不过命名标题会不会有需要额外调整？另若认为搬去技术版更合适，那还请协助移动。--WiTo🐤💬 2024年5月7日 (二) 03:27 (UTC)[回复]
我早前用字形wiki的字体做过一个小工具来实现类似你说的这种方法，后来因为技术和安全原因失效了。其实现在仍然可以利用字形wiki的字体资源来实现，只是要把字体之类的资源搬到toolforge上去，然后本地用小工具调用。c区似乎不能上传字体文件？“根据当前页面中包含的扩展区段字符”其实并不是一个很好的做法，因为每个人电脑/终端上的字库未必不一样，在甲上不能正常显示的字形，在乙那里没准就可以正常显示。所以最好的办法是自动检测某人设备上哪些字形不能正常显示，不能正常显示的就即时下载相应的字形文件（可能会遇到一些优化工作要做）。目前来说，我知道的是这种自动检测方法chrome和firefox下都有解决方案，其他浏览器内核的不确定--百無一用是書生 (☎) 2024年5月7日 (二) 09:47 (UTC)[回复]
  • chrome检测法：将代表不能显示的字符形状映射到画布，然后将文本中的每个字符一个一个映射到画布并进行比较，如果比较结果一致，就表示该字符无法在这个设备上显示
  • firefox检测法：将文本中所有字符设为斜体，如果某个字符不是斜体，就表示该字符无法在这个设备上显示（比如𱎼家人和𱎼家人）
--百無一用是書生 (☎) 2024年5月29日 (三) 04:05 (UTC)[回复]
@T45614631、Interaccoonale、Ericliu1912：我根据知乎上的一些文章整理出来了未被收录进《通用规范汉字表》的科学技术用字，见我的子页面User:微肿头龙/E。这个表肯定是不完整的，欢迎补充。--微肿头龙（留言） 2024年5月7日 (二) 06:52 (UTC)[回复]
这样看起来的话，有些表外字还是有被正常转换耶，像是𫚉、鳋、鿔等，那是被手动增加转换的吗？--WiTo🐤💬 2024年5月7日 (二) 07:49 (UTC)[回复]
那几个字确实已经加入全域转换了。这里有维基百科的完整繁简转换表--微肿头龙（留言） 2024年5月7日 (二) 09:01 (UTC)[回复]
所以现在算是有共识要处理这个繁简问题吗？感觉上这些字迟早会变成正规简化字...--WiTo🐤💬 2024年5月13日 (一) 03:47 (UTC)[回复]
@Shizhao、Interaccoonale、T45614631、Ericliu1912：所以几位觉得需要处理这些繁简问题吗？还是放着不用理？我个人是觉得需要简化。--微肿头龙（留言） 2024年5月16日 (四) 07:48 (UTC)[回复]
我是支持简化的，但还是要考虑显示的问题？——🦝Interaccoonale（留言・贡献） 2024年5月16日 (四) 08:16 (UTC)[回复]
@Interaccoonale：其实就我个人来说{{僻字}}就已经够用了，但如果有更好的方式也可以。我的电脑技术很差，这方面就爱莫能助了。--微肿头龙（留言） 2024年5月16日 (四) 08:36 (UTC)[回复]
目前维护内置转换表的管理意见，应该是大部分都只转换到中日韩统一表意文字扩展B区，后面扩展区域的因为大部分设备字体兼容性不足，一般不转换（大部分类推简化的繁体本字能正常显示）。上面有表外漏转汉字可能要从扩展A区开始找的观点，我(＋)支持这种找法，扩AB两个区先查一遍看看有什么没转换的。至于后面的扩展区我暂保持中立。--屠麟傲血（留言） 2024年5月17日 (五) 14:53 (UTC)[回复]
那我就转到技术区看要有没有人能处理这问题了。--WiTo🐤💬 2024年5月25日 (六) 03:50 (UTC)[回复]
拿脚本找了一下Unihan数据库（里面可能有不适用的，例如“奨，奖”还有大部分一简多繁转换）：
筛选出了简繁皆为基础及扩AB区的
--User:What7what8🏠 2024年5月25日 (六) 06:51 (UTC)[回复]
如果通过的话，WP:R3可能也有需要更改。--User:What7what8🏠 2024年6月14日 (五) 03:12 (UTC)[回复]
如果通过的话Template:繁简混杂重定向也要改，不过只有几个页面应该不难改。--User:What7what8🏠 2024年5月25日 (六) 07:52 (UTC)[回复]
粗略看来一下阁下列出的，当中有些是违反简化规则的。比如“㳕,灡”，“蘭/兰”字位于《简化字总表》的第一表，因此是不可类推简化的。也就是说，如果有一天“灡”字被列为规范汉字，也仅会对“門”部件进行简化变成“𬞕”，而不是将整个“蘭”进行简化。再比如“䓕,薳”，由于“遠/远”也是不可类推简化部件，所以“薳”也是不必简化的，刚巧《通用规范汉字表》就有收录“薳”字。所以阁下的这个恐怕要进行超大规模的整理才能提交啊。而且我觉得没有具体使用例子的就没必要简化了。不过还是要感谢一下阁下把它们整理出来。@What7What8：--微肿头龙（留言） 2024年5月25日 (六) 13:40 (UTC)[回复]
另外想问一下哪一种字体支援最完整？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月26日 (日) 03:41 (UTC)[回复]
应当是宋体吧，因为Unicode的文件也是宋体，Microsoft在显示生僻字时好像也是默认宋体。--微肿头龙（留言） 2024年5月26日 (日) 03:46 (UTC)[回复]
宋体是字体风格不是一种字体。--Miyakoo（留言） 2024年5月26日 (日) 11:05 (UTC)[回复]
好吧，是我搞错了两个概念。谢谢指出。@Miyakoo：--微肿头龙（留言） 2024年5月26日 (日) 11:09 (UTC)[回复]
Unifont吧，不过是点阵字形，可以参考Wikipedia:Unicode扩展汉字还有Template:Unihan
( π )题外话，Special:链入页面/Wikipedia:Unicode扩展汉字“𰻝𰻝面 ‎ （← 连结 | 编辑）”怎么全变方框了，还有𱎼家人的标题“家人”也变成方框了，是有什么bug吗？--User:What7what8🏠 2024年5月26日 (日) 15:30 (UTC)[回复]
Firefox正常显示，Chrome显示方框。--Kethyga（留言） 2024年5月29日 (三) 00:38 (UTC)[回复]
我这里不能复现--百無一用是書生 (☎) 2024年5月29日 (三) 03:28 (UTC)[回复]
我这也是，认真说应该是我两台电脑都开chrome，一台正常显示，另一台则是全方框。--WiTo🐤💬 2024年5月29日 (三) 05:34 (UTC)[回复]
天珩全字库（大陆标准）和字云（日本标准），它们都支援到了I区。--Miyakoo（留言） 2024年5月26日 (日) 10:58 (UTC)[回复]
目前转换表主要是我在维护，过来解释一下。确实如上文所说，目前只支持到中日韩统一表意文字扩展B区及以前的规则，B区之后基本只支持了通用规范汉字表表内的规则。这么做主要还是考虑到大众用户的设备显示，现在大家使用手机访问的频率变得更高，但目前手机显示基本只支持到扩展A区+所有表内汉字，因此不敢妄作扩张，怕反而伤害了用户的阅读体验。—Chiefwei（论 - 历） 2024年6月8日 (六) 13:23 (UTC)[回复]

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

Module:Mapframe、Module:Location map报错

问题已解决
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

好像就在近期，新出现了不少Module:Mapframe、Module:Location map的Lua错误[13][14]，如天门山寺、和合石。--Kcx36（留言） 2024年6月9日 (日) 10:35 (UTC)[回复]

我也注意到了；似乎在条目内将{{coord}}中的display=title改为display=inline,title可以解决报错。从时间上看，会不会和为了解决上面的问题（#Template:Infobox_body_of_water中的坐标会重复两次），Shizhao在Module:Coordinates的几个编辑（82849253）有关？Irralpaca（留言） 2024年6月9日 (日) 11:12 (UTC)[回复]
看来似乎是Module:Coordinates修改后，导致Module:Location_map#L-122取不到/取错值了--百無一用是書生 (☎) 2024年6月9日 (日) 12:17 (UTC)[回复]
改为display=inline,title或者display=inline都可以解决报错--百無一用是書生 (☎) 2024年6月9日 (日) 12:30 (UTC)[回复]
测试了一下，Module:Location map用display=title的时候，坐标并不会显示在标题右上角（直接就不显示），似乎这样和coord对参数的声明不符合？--百無一用是書生 (☎) 2024年6月9日 (日) 12:36 (UTC)[回复]
最近更新了Module:Coordinates，似乎这个问题解决了？--百無一用是書生 (☎) 2024年7月14日 (日) 11:54 (UTC)[回复]
好像是解决了。--Kcx36（留言） 2024年7月14日 (日) 11:57 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

Wikiplus导致Navbar被换行

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

RT，{{Navbox}}模板最近才出现的问题，启用Wikiplus后会导致Navbar被换行，粤维无此问题。--Dabao qian℡ 2024年6月12日 (三) 18:19 (UTC)[回复]

您是指快速编辑按钮没有和查论遍在同一行？——暁月凛奈 (留言) 2024年6月12日 (三) 18:51 (UTC)[回复]
他会不会说的是“编”被挪到了下一行的问题？我也困扰一段时间了，之前显示是“查·论·编/(快速编辑)”，但近段时间一直显示为“查·论·/编(快速编辑)”了。--自由雨日（留言） 2024年6月12日 (三) 19:00 (UTC)[回复]
没错，而且粤维的显示就是正常的“睇·倾·改(快速编辑)”无换行，不知道中维哪个CSS出了问题。--Dabao qian℡ 2024年6月13日 (四) 08:30 (UTC)[回复]
涉及排版的因素挺多的，不同设备可能区别明显，我目前未遇到此问题，不过此前也有过。zh和yue的网站设置有一些区别，最近的话可能是zh的字号调整。模板的css似乎并没有更动。——暁月凛奈 (留言) 2024年6月13日 (四) 08:39 (UTC)[回复]
Timeless用户表示已出现了一段时间orz--Tim Wu（留言） 2024年6月13日 (四) 08:48 (UTC)[回复]
粤维是连“(快速编辑)”都不会换到下一行吗？（粤维我不是自动确认用户，看不了Wikiplus效果。）我在中维一直是必看到换行的，只不过之前是“查·论·编/(快速编辑)”这种换行方式，相对来说还算美观。我以为“快速编辑”肯定会被换行……--自由雨日（留言） 2024年6月13日 (四) 09:27 (UTC)[回复]
.navbox-title .navbar { width: 8em; }，加上那个按钮后宽度爆掉了，就这么简单。（粤维这行被拆掉了）--SunAfterRain 2024年6月15日 (六) 10:56 (UTC)[回复]
已修复，但留意到问题：最近@Shizhao：修改Common.css后，navbar“查论编”这三个字的颜色，不能被设置了（详见Template:香港电台频道及该模板在今年4月30日的存档）。--Tim Wu（留言） 2024年6月19日 (三) 07:46 (UTC)[回复]
Module:Navbar/styles.css，.navbar-mini abbr { color: inherit !important; }，加上这个之后颜色就不能设置了。而且font-size: 88%;这行也应该去掉，中文似乎不需要。--Dabao qian℡ 2024年6月19日 (三) 09:25 (UTC)[回复]
为求省事抄的enwiki--百無一用是書生 (☎) 2024年6月19日 (三) 13:55 (UTC)[回复]
不加这行，“查论编”在dark模式下是黑色字，看不清，我暂时没找到其他的修改方法...--百無一用是書生 (☎) 2024年6月19日 (三) 14:04 (UTC)[回复]
Module:Navbox的第62行fontstyle = (args.basestyle or '') .. ';' .. (args.titlestyle or '') .. ';background:none transparent;border:none;'没有定义color:inherit;。--Dabao qian℡ 2024年7月4日 (四) 16:23 (UTC)[回复]
把background:none transparent;删掉不知行不行--百無一用是書生 (☎) 2024年7月5日 (五) 03:46 (UTC)[回复]
经测删掉会露出自定义背景颜色--Dabao qian℡ 2024年7月5日 (五) 07:09 (UTC)[回复]
完成--百無一用是書生 (☎) 2024年7月5日 (五) 08:34 (UTC)[回复]
把color:inherit;放到最前面才对吧，不然自定义字体颜色还是会被覆盖掉，以及Module:Navbar/styles.css里的hack可以去掉了。--Dabao qian℡ 2024年7月5日 (五) 08:41 (UTC)[回复]
话说，修复之后，navbar的颜色怎么变成无色了 囧rz……--自由雨日（留言） 2024年6月20日 (四) 14:32 (UTC)[回复]
上几行留言正是在讨论此事……--Cookai饼块🍪（💬留言） 2024年6月20日 (四) 14:35 (UTC)[回复]
啊？上面不是在讨论“查论编”三个字（而非背景）的颜色吗……--自由雨日（留言） 2024年6月20日 (四) 14:38 (UTC)[回复]
抱歉看错了，背景色是深色模式强制覆盖掉的。--Cookai饼块🍪（💬留言） 2024年6月20日 (四) 14:47 (UTC)[回复]
我没有开深色模式……？而且刚好就是修复之后变成浅色的……--自由雨日（留言） 2024年6月20日 (四) 16:54 (UTC)[回复]
 已修复，之前改坏了--百無一用是書生 (☎) 2024年6月21日 (五) 09:15 (UTC)[回复]
8em那个是因为看到有个导航框的标题歪掉了（忘了是哪个了）--百無一用是書生 (☎) 2024年6月19日 (三) 13:52 (UTC)[回复]
8em和font-size:88%其实在Template:Navbox写过说明了。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月19日 (三) 11:24 (UTC)[回复]
简单调整之后发现了新问题，很多导航框的副标题歪掉了，比如Template:芒果超媒。--Dabao qian℡ 2024年6月25日 (二) 16:29 (UTC)[回复]
并不是副标题歪了，而是标题歪了（）明显是“快速编辑”按钮把标题往右“挤”了，不过具体算法我就不懂了……另外上面的回复（8em之类的）似乎就是Shizhao等前辈在研究这一问题。--自由雨日（留言） 2024年6月25日 (二) 21:50 (UTC)[回复]
如果综合来看的话，可能是自己引用的wikiplus导致破坏微妙的平衡。结合“Module:Navbox”和Navbar的设计，Navbar在Navbox默认在左边为固定width:8em，为了保持平衡，右边的折叠按钮块也是固定width:8em。而且还有根据是否启用navbar、是否禁用折叠按钮状态（常见对应是子块Navbox作为嵌套到父块中），来补充一个固定的8em空白块来填补位置（具体看Navbox模块的renderNavBar方法）。8em可能考虑Navbar常见就3个字+2个间隔号，就算是4个字（查编历讨）+3个字也是7em，因此预留8em。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 02:17 (UTC)[回复]

美国县级行政区地图显示故障

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

本主题或以下段落文字，移动自WP:VPD。执行者：路西法人 2024年6月26日 (三) 08:20 (UTC)。[回复]

于Phabricator查看
编号T367645的工单
状态：已解决

如弗吉尼亚州县级行政区列表，密西西比州县级行政区列表，密苏里州各县列表，马里兰州行政区划，爱达荷州县级行政区列表等列表中的小地图显示故障，只显示一个红色块而没有网格，同时对应各县的条目的地图也是一样的问题，好像是原图批量出了问题？

--桃花影落飞神剑（留言） 2024年6月17日 (一) 15:43 (UTC)[回复]
是批量出了问题，我建了很多个县都是这样子。经调查，这不是本人能力范围内能解决的，只能坐等一天恢复正常。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年6月17日 (一) 15:51 (UTC)[回复]
是维基共享使用的底图出问题了，各种语言维基都有显示问题。这边不动手，英维那边也会吵起来，让相关人员处理。这个应该算是技术问题？大概很快就有{{Tracked}}的工单。--Nostalgiacn（留言） 2024年6月17日 (一) 16:59 (UTC)[回复]
怀疑与最近librsvg版本升级有关--百無一用是書生 (☎) 2024年6月18日 (二) 03:02 (UTC)[回复]
根据phab:T367645#9902624的说法，svg文件原本就有问题，只是没有表现出来，librsvg升级后这个问题变严重了。可以参考下这个[15]，一大堆的报错--百無一用是書生 (☎) 2024年6月19日 (三) 02:25 (UTC)[回复]
举例的图片，以上传新图片解决了。不过仍然有很多图片没有上传新图片取代。如右图（Virginia）
Virginia
--Nostalgiacn（留言） 2024年6月30日 (日) 06:50 (UTC)[回复]
工单上编者Nux已经使用机器人替换相关图片，美国相关图片已经替换。不清楚是否有有其他国家或地区使用同类图片，Phabricator上的工单已经标记完成，关闭了。--Nostalgiacn（留言） 2024年7月7日 (日) 02:53 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

TW部分功能故障

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

  1. 存废讨论中三级标题右侧不出现“关闭讨论”
  2. 在存废讨论中无法关闭讨论，只能删除相关提删页面或移除相关提删页面的模板，但无法关闭相应的讨论
  3. 另外发现Wikipedia:页面存废讨论/记录/2024/06/22使用tw关闭讨论时，发生了错位（“赖拥连”错位到了“Code Geass角色列表”，“Category:各国县治、Category:县治”错位到了“家庭教师HITMAN_REBORN!角色列表”），当时#2问题还未发生

--百無一用是書生 (☎) 2024年6月30日 (日) 06:17 (UTC)[回复]

@Xiplus @Manchiu--百無一用是書生 (☎) 2024年6月30日 (日) 06:19 (UTC)[回复]
大概是mw:Heading HTML changes？——暁月凛奈 (留言) 2024年6月30日 (日) 06:43 (UTC)[回复]
能否给一下具体的案例（固定版本号或差异），不然上面三个问题我目前都无法重现。--Xiplus#Talk 2024年6月30日 (日) 13:08 (UTC)[回复]
  1. 1应为此版本。我也有同样情况。以为是自己浏览器问题。（我本身需F5多遍方看到关闭讨论键。）-千村狐兔（留言） 2024年6月30日 (日) 13:15 (UTC)[回复]
    @Manchiu，Wikipedia:页面存废讨论/记录/2024/06/24，你的操作似乎也发生了错位，杨尚铭和王红权星被标记为允许并入，Eva IM client被标记为删除，已删除的陈美琪 (企业家)被标记为允许并入...--百無一用是書生 (☎) 2024年7月1日 (一) 02:09 (UTC)[回复]
    Special:PermaLink/83231036--百無一用是書生 (☎) 2024年7月1日 (一) 02:10 (UTC)[回复]
    建议这个问题未修好前，暂时不要使用TW来处理存废讨论，我刚用了一下，结果错位得太离谱了！--百無一用是書生 (☎) 2024年7月1日 (一) 02:15 (UTC)[回复]
    谢谢修正错误。真的不好意思！--千村狐兔（留言） 2024年7月1日 (一) 02:26 (UTC)[回复]
    @Manchiu：Wikipedia:页面存废讨论/记录/2024/06/23也有错位的问题。--夏冰 2024年7月1日 (一) 03:43 (UTC)[回复]
    我重新回退后，全手工处理了一遍，请复查--百無一用是書生 (☎) 2024年7月1日 (一) 02:28 (UTC)[回复]
2.无法关闭是[16]（TW删除）、Special:Diff/83221043（手动关闭）
3.错位是Special:Diff/83212283--夏冰 2024年7月1日 (一) 01:08 (UTC)[回复]
已确认这是由Vector2022引起的，Vector2010运作正常。--Xiplus#Talk 2024年7月1日 (一) 14:04 (UTC)[回复]
根据 Heading HTML changes，应该所有的标题（h1-h6）都会被加上 mw-heading，但不知为何在 Vector 2022 仅有 h2 被加上，导致计算章节数量时错误而造成此问题，为避免 Vector 2022 后续再次更改，我暂时决定在 Heading HTML changes 完成前不会支援 Vector 2022，请改用其他外观，经测试本功能在 Vector 2010 运作正常。--Xiplus#Talk 2024年7月1日 (一) 14:45 (UTC)[回复]
顺便说一下，Timeless下好像也无关闭讨论按钮。--Kethyga（留言） 2024年7月7日 (日) 10:49 (UTC)[回复]

Attached KML模板的display=title显示位置有问题

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

{{Attached KML}}模板的display=title在Vector2022皮肤下，显示位置有问题。示例：美国国道41号商业线 (密西根州马凯特)。对照英维的话，“路线图”显示在与“坐标”相同的位置比较好。--深鸣（留言） 2024年6月30日 (日) 07:02 (UTC)[回复]

 已修复--百無一用是書生 (☎) 2024年7月5日 (五) 03:30 (UTC)[回复]

维基百科:其他语言的维基百科典范条目/英语版这样的标题是否属于繁简混用？

维基百科:其他语言的维基百科典范条目/英語版这样的标题是否属于繁简混用？有很多这样的页面需要移动。--Midleading（留言） 2024年7月1日 (一) 09:38 (UTC)[回复]

命名常规的简繁统一仅约束条目。要求子页面统一简繁会带来很多麻烦，讨论存档、新建子页面，需要手动转换简繁。有/分割，也不会有转换分词等问题。--YFdyh000（留言） 2024年7月1日 (一) 15:32 (UTC)[回复]
许多时候区分繁简或许还别有意义。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月3日 (三) 10:59 (UTC)[回复]
原来如此 Midleading（留言） 2024年7月6日 (六) 12:29 (UTC)[回复]

像Category:埃里克·貝特爾森命名的生物分类这样的分类名是否属于繁简混用呢？ Midleading（留言） 2024年7月12日 (五) 08:18 (UTC)[回复]

理论上不算，https://dict.variants.moe.edu.tw/dictView.jsp?ID=50466 。
不过维基百科系统无法自动转换。--Miyakoo（留言） 2024年7月12日 (五) 08:57 (UTC)[回复]

在导航模板中淘汰过时的可折叠表格支持

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

参见MediaWiki talk:Common.css、MediaWiki talk:Common.js、Module talk:Navbox，对应上述三处编辑请求，停用导航模板中过时的可折叠表格支持，改为MediaWiki自带的折叠语法。--Dabao qian℡ 2024年7月3日 (三) 20:56 (UTC)[回复]

使用mw核心提供的表格折叠会不会存在问题？能否复刻一个样式看看？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 00:44 (UTC)[回复]
Template:Navbox/sandbox3、Module:Navbox/sandbox3、Template:香港行车隧道/sandbox。mw版技术手册mw:Manual:Collapsible_elements。另外好像有亿点点小问题：默认预设折叠的参数等和本来的不一致（mw的是“mw-collapsed”、而我们脚本是“collapsed”；上面的例子就是改了mw后加的是我们脚本的参数，当然意料之内不生效；需要统计Navbox下加了这个参数有多少影响和是否需要兼容机制），另外我们实现的折叠脚本有自动折叠机制：挂了“autocollapse”的结构，数量超过2个时会默认全部折叠起来。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 01:05 (UTC)[回复]
MediaWiki:Gadget-collapsibleTables.js英维3.0版本改了机制，会给有collapsible和collapsed的地方自动叠加带mw-的class（纯向下兼容），中维因为涉及到导航模板所以暂时没有部署（仍沿用2.04版本）。autocollapse、innercollapse和outercollapse需要修改Common.js才能实现。--Dabao qian℡ 2024年7月4日 (四) 01:56 (UTC)[回复]
User:Dabao qian/common.js这里的最后两段脚本，一是为mw-collapsible增加autocollapse、innercollapse和outercollapse三种元素的支持，二是3.0版本的可折叠表格支持。--Dabao qian℡ 2024年7月4日 (四) 02:06 (UTC)[回复]
可能还需要更新en:MediaWiki:Gadget-collapsibleTables.js等配套脚本，需要更多测试，而不是说换就换。当然怕出问题的话，没坏别修。就像一堆java 8、java 6不升级的——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 02:34 (UTC)[回复]
其他语言的可折叠表格支持都是直接放在Common.js的，不像中维是以小工具的形式提供。需要灰度测试的话，关掉小工具里的可折叠表格支持，然后复制User:Dabao qian/common.js和MediaWiki talk:Common.css里面的相关代码到您的用户页JS/CSS就可以了。不过英、粤维早就已经实际运行很长时间了，问题应该不大。--Dabao qian℡ 2024年7月4日 (四) 02:39 (UTC)[回复]
需要将相应的功能整理成单独的脚本，然后通过小工具或者Commons.js引入。初步来看是暂时没看出还有什么明显问题，但也要考虑为什么很多看上去应该全站点代码一致的站点自定义功能，实际操作上都是脱同步的——每个站点具体实施上又加了自己的调整。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 02:49 (UTC)[回复]
好像改了会不会影响标题居中？为了保证标题居中，我写的User:Cwek/collapsibleTables.js默认给了折叠按钮8em的宽度，Navbar按照以前也给了8em的宽度。如果改了mw加Navbar不固定宽度的话，标题稍微略微偏右？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 01:37 (UTC)[回复]
好像哪里见过MediaWiki:Gadget-collapsibleTables.js、Navbox、或者配套的css，折叠按钮是设定8em，所以我的实现也跟着8em。如果要保持Navbox内标题居中的话，必须Navbar（还有它的空白替代块）和折叠按钮块的宽度一致，才能将标题挤到居中。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 03:06 (UTC)[回复]
Special:Diff/83093979，左右平衡的实现语法在Common.css，新版的话就用mw-collapsible-toggle替换掉collapseButton。--Dabao qian℡ 2024年7月4日 (四) 04:10 (UTC)[回复]
试过，这样做法不是左右平衡的。因为两个块的长度不等，所以挤占的中间块不是完全居中，所以才搞固定宽度。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 06:44 (UTC)[回复]
@Dabao qian：如果启用折叠按钮块，保证Navbox标题居中，折叠按钮初始化时需要读取同行Navbar的宽度，然后手工设成相同。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 07:50 (UTC)[回复]
我测算的话，Narbar的宽为49.563、折叠按钮的宽为34.266。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 01:39 (UTC)[回复]
居中问题有没解决思路？当然Wikiplus的是它自己的问题，没必要考虑它的感受。建议的话，可以考虑Wikiplus做个兼容补充，劫持编辑链接，改成弹窗形式机制询问是快速编辑还是传统编辑，从而不用因为额外添加内容导致box溢出偏移，维持Navbox内Navbar和折叠按钮微妙的宽度平衡。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 02:57 (UTC)[回复]
英维的Navbox早就改了好几回了，粤维当前版本也早就不是中维当前版本了，不再需要Common.css定义宽度，而且英维的{{Navbar}}是不会出现快速编辑按钮的。--Dabao qian℡ 2024年7月4日 (四) 04:18 (UTC)[回复]
那就测试一下，两个块不固定宽度后，能不能保证标题居中？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 06:30 (UTC)[回复]
提起“Wikiplus”，是因为上面提到类似问题，所以猜测Wikiplus的编辑按钮修改是否会影响。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 06:42 (UTC)[回复]
英维改了方案，编辑按钮的链接换成了Special:Editpage内部链接，Wikiplus读不出来自然也就不会自作主张地额外加按钮，已经在Module:Navbox提EP按照英维方案修改。--Dabao qian℡ 2024年7月4日 (四) 08:02 (UTC)[回复]
那不就是Wikiplus的问题，Wikiplus没有正确识别出编辑链接，自己处理错了，为什么不是Wikiplus去自己修正？而且代码不一定要跟en同步吧？而且编辑部分不应该是Navbar去实现的？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 08:18 (UTC)[回复]
你说的编辑链接问题，就是我们的Navbar还是用fullurl+action=edit生成链接（Module:Navbar#L-81），而en是用内链+加上Special:EditPage特殊页生成内链（en:Module:Navbar#L-70）。在链接生成上没明显差异。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 08:26 (UTC)[回复]
@Dabao qian：，Navbar的生成模式上，编辑和历史的链接生成模式，只需要移植这部分（en:Module:Navbar#L-69--L-72）就对应了。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 08:37 (UTC)[回复]
[17]，分别是固定宽、不固定宽，使用mw折叠、小工具折叠、小工具改写折叠的样式。如果固定宽度的话，标题字会更接近中间。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 07:05 (UTC)[回复]
打开F12实时调试使用mw折叠且按照旧版Common.css方案设定两端固定宽度8em之后效果与小工具改写折叠相差无几--Dabao qian℡ 2024年7月4日 (四) 08:50 (UTC)[回复]
@Dabao qian：你调成这样当然没问题了。这里分两个主要部分：1.改用mw折叠，可以考虑，但需要一组兼容性脚本用于处理自制折叠参数的兼容处理和自动折叠处理；2.标题居中，需要Navbox中的Navbar和折叠按钮块的宽度固定且相等，这可能需要脚本控制而不能靠css的自动宽度控制（因为两者长度大概率不等，需要脚本比较计算和注入覆盖）；2.1.Wikiplus的撑爆，一定程度上和Navbar固定宽有关，要么Wikiplus自己适配，要么结合前面前面计算新的宽度和重新注入。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 09:31 (UTC)[回复]
1.User:Dabao qian/collapsibleTables-new.js以及MediaWiki:Common.js和MediaWiki:Common.css的两处EP即可实现；2.似乎没有找到其他合适的方法--Dabao qian℡ 2024年7月4日 (四) 09:37 (UTC)[回复]
第1点暂时seems good。虽然我更喜欢我自己写的，能使th那一栏同时也绑定上折叠按钮功能。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 09:53 (UTC)[回复]
经测试启用Wikiplus后两端宽度设为10em即可避免撑爆。--Dabao qian℡ 2024年7月4日 (四) 16:05 (UTC)[回复]
那应该是Wikiplus自己搞，还是学微软帮用户擦屁股？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 00:40 (UTC)[回复]
我有个问题，我同时用Wikiplus和InPageEdit应该怎么办[开玩笑的] ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月5日 (五) 15:05 (UTC)[回复]
那只能自己写脚本（js或者css）适配了，简而言之，两个块固定宽度且相等就可以保证navbox标题挤占居中。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月6日 (六) 00:27 (UTC)[回复]

更新清单

  2. 以上完毕了，才需要更新Module:Navbox、Module:NavboxV2的折叠参数调整。
@Dabao qian：如果理解和没异议的话，可以推进下去。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 02:20 (UTC)[回复]
无异议，宽度和深色模式适配的问题后续再议（当然这不属于本次讨论范围）。--Dabao qian℡ 2024年7月5日 (五) 03:46 (UTC)[回复]
@Dabao qian：，看了collapsibleTables-new.js，其实Module:Navbox、Module:NavboxV2不用换，因为按照脚本逻辑，“table.collapsible:not(.mw-collapsible)”就能够选出保持兼容class的table，然后后面加上“mw-collapsible”就是加上mw的折叠功能。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 08:33 (UTC)[回复]

UX

啊所以现在想展开已关闭的存废讨论，就必须按右边的[展开]，而不能直接点击小蓝条了？有点麻烦…… ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月14日 (日) 16:55 (UTC)[回复]

小蓝条？是不是一整栏的标题行？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月15日 (一) 00:41 (UTC)[回复]

条目标题左侧出现多余的“维基百科”

于Phabricator查看
编号T369537的工单

如题，条目标题出现多余得“维基百科”，今天第一次出现，见截图，多出的是图片版的File:Wikipedia-wordmark-zh.svg，像是和MediaWiki:Common.css中的的“content: url(/static/images/mobile/copyright/wikipedia-wordmark-zh-hans.svg);”有关--Kethyga（留言） 2024年7月4日 (四) 12:49 (UTC)[回复]

不能复现，或许与您使用的js脚本之类的有关--百無一用是書生 (☎) 2024年7月4日 (四) 12:58 (UTC)[回复]
我使用Timeless，从几个小时前开始也这样。--Tim Wu（留言） 2024年7月4日 (四) 13:10 (UTC)[回复]
我在Timeless下测试，未发现问题--百無一用是書生 (☎) 2024年7月5日 (五) 03:32 (UTC)[回复]
使用隐私模式复现，可能不是脚本问题（？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月5日 (五) 12:55 (UTC)[回复]
看起来像是MediaWiki:Common.css#L-1035的问题，似乎只匿名用户有这问题？应该是Timeless最近更新导致？--百無一用是書生 (☎) 2024年7月5日 (五) 13:23 (UTC)[回复]
我、Kethyga还有下面的ElectronicGhost都算是匿名用户？--Tim Wu（留言） 2024年7月5日 (五) 13:25 (UTC)[回复]
目前我只能在firefox的隐私模式下能复现，chrome隐私模式不能复现（都是未登陆状态）。两个浏览器非隐私模式登录状态下都不能复现--百無一用是書生 (☎) 2024年7月5日 (五) 13:32 (UTC)[回复]
我在Chrome/Firefox的登录/隐私模式都出现这个问题……在Chrome登录小号也复现……怎么回事 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月5日 (五) 14:38 (UTC)[回复]
本人的Timeless skin，目前只在登录模式下（Chrome/Firefox）出现，隐私模式下暂时没有。--Kethyga（留言） 2024年7月5日 (五) 15:06 (UTC)[回复]
上面结果在隐私模式下未登录，使用的默认皮肤。--Kethyga（留言） 2024年7月6日 (六) 05:01 (UTC)[回复]
我在使用Timeless皮肤的情况下，无论使用Safari、Chrome还是Firefox抑或是在各个浏览器开启隐私模式并登陆，这个问题都会出现。 -- ElectronicGhost｜👻 2024年7月6日 (六) 04:48 (UTC)[回复]
这样看起来，只有使用小工具和用户权限的差异了--百無一用是書生 (☎) 2024年7月7日 (日) 06:16 (UTC)[回复]
造成需要这段站内css的问题已经修复（phab:T369537），在下周部署后可以直接删除相关段落。--Func（讨论·贡献） 2024年7月10日 (三) 16:55 (UTC)[回复]

深色模式现在可供所有使用者使用！

大家好，在过去的一年里，维基媒体基金会的网页团队一直致力于深色模式的开发。这项工作是无障碍阅读计划的一部分（该计划引入了对 Vector 2022 和 Minerva 皮肤的更改）。这提高了可读性，并允许每个人（无论是未登入的使用者还是已登入的使用者）自订以阅读为中心的设定。

自今年年初以来，深色模式已作为测试版功能在行动版和桌面版网站上向大家提供。我们一直在与模板编辑者和其他技术贡献者合作，为此功能准备不同的维基专案。这项工作包括修复模板并确保许多页面均可以以深色模式显示，而不会出现任何无障碍问题。我们对参与此事的所有人表示衷心的感谢。因为已经做了很多工作，深色模式已经可供未登入及已登入的使用者在行动版网站上使用。在接下来的两周内，我们将向桌面版网站的使用者释出此功能！

部署配置和时间表

  • 第 1 级别与第 2 级别维基百科：与浅色模式相比，深色模式的问题数量并不显著的维基百科。这些维基专案已经为未登入及已登入的使用者提供深色模式。不过，模板中可能仍存在一些小问题。我们将添加报告这些问题的方法，以便我们可以继续与编辑者一起修复模板。
  • 第 3 级别维基百科：与浅色模式相比，深色模式的问题数量非常多的维基百科。这些维基只会为已登入的使用者提供深色模式。我们希望为所有用户提供深色模式。然而，有些维基专案仍然需要社群的工作来调整模板。与上面的群组类似，这些维基专案同时会收到一个报告问题的链接，这将有助于识别剩馀的问题。
  • 7 月 1 日的当周：第 1 级别的维基百科（包括中文维基百科）上的行动版网站（Minerva 皮肤）
  • 7 月 15 日的当周：所有维基百科上的桌面版网站（Vector 2022 皮肤）；行动版网站：在第 2 级别维基百科上已登入的使用者和未登入的使用者，第 3 级别维基百科仅限于已登入的使用者

如何开启深色模式

此功能会与文字和宽度选项一起出现在“外观”功能列表中。根据相容性和技术架构的不同，某些页面可能无法在深色模式下使用。对于这些页面，选单中会出现一则通知，提供更多资讯。

如何让深色模式变得更好！

如果您想协助让更多页面适合深色模式，请前往我们先前的讯息并查看“我们希望您做什么（模板编辑者、介面管理员、技术编辑者）”部分。

谢谢大家。我们期待您的问题、意见和评论！(Translated by VLui (WMF) and SCP-2000)--SGrabarczuk (WMF)（留言） 2024年7月4日 (四) 13:48 (UTC)[回复]

可喜可贺！L'Internationale, Sera le genre humain! ✏️ 2024年7月4日 (四) 14:05 (UTC)[回复]
Note: I bolded some sentences for easier reading. Thanks. --SCP-0000（留言） 2024年7月4日 (四) 14:15 (UTC)[回复]
借个楼顺便说一下中维导航模板的深色模式适配还是有问题，Shizhao做完深色模式适配之后“查论编”链接在正常模式下无法更改颜色了。--Dabao qian℡ 2024年7月4日 (四) 15:56 (UTC)[回复]
@Dabao qian：深色模式兼容性问题可在Wikipedia:征求意见/深色模式反映。--SCP-0000（留言） 2024年7月5日 (五) 01:06 (UTC)[回复]
楼上的签名在深色模式下不适配....--百無一用是書生 (☎) 2024年7月5日 (五) 03:33 (UTC)[回复]
能否有高人帮我看一下本人的签名和主编条目肯塔基州城市列表、堪萨斯州城市列表等在深色模式下是否有问题？本人怎么设置也无法在Vector 2022中试用深色模式。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年7月5日 (五) 04:32 (UTC)[回复]
@SickManWP：如果您是使用桌面版，现阶段您需要先在测试功能设定中启用“无障碍阅读”才能使用。而行动版可在设定中启用。--SCP-0000（留言） 2024年7月5日 (五) 04:41 (UTC)[回复]
已设置完成。不过我希望看看其他用户对条目的意见，避免过几天本人编写更多类似列表时出现显示问题，影响条目评选。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年7月5日 (五) 04:48 (UTC)[回复]
两个条目的表格颜色有问题--百無一用是書生 (☎) 2024年7月5日 (五) 08:15 (UTC)[回复]
相关条目的问题本人已于Wikipedia:征求意见/深色模式中提出，目前正在寻找解决办法。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年7月5日 (五) 08:19 (UTC)[回复]

Dark mode for logged-in users on desktop coming this week!

Hello! In the previous message, we announced that dark mode on desktop would be rolled out in one step, for both logged-in and logged-out users, in the week of July 15 (that is, next week). However, we'd be more comfortable to enable it for logged-in users first. Articles here on zh Wikipedia look very good in dark mode, and again, thanks to everyone who is contributing to it!

We are going to enable dark mode on desktop just for logged-in users this week. If everything goes well (it has been going very well so far!) we will enable it on desktop for logged-out users next week as we previously announced. It's gonna be exciting :D Thanks! SGrabarczuk (WMF)（留言） 2024年7月10日 (三) 01:36 (UTC)[回复]

简单而言：本周先向桌面版的登入用户提供深色模式。如果一切顺利，便会照原定计划在下周向未登入用户提供。--SCP-0000（留言） 2024年7月10日 (三) 02:04 (UTC)[回复]

Twinkle关闭存废讨论无法在Vector 2022使用

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

最近几天有使用Vector 2022介面的使用者，可以发现在WP:AFD及WP:FFD无法用Twinkle关闭存废讨论，需要改以Vector 2010介面才能使用，有甚么方法修复这样错误？谢谢！--Sinsyuan✍️🌏🚀 2024年7月5日 (五) 01:27 (UTC)[回复]

见Xiplus君的说明。--伞木 霙留言 2024年7月5日 (五) 01:34 (UTC)[回复]
囧rz……能否合并讨论串至“TW部分功能故障”？--Sinsyuan✍️🌏🚀 2024年7月5日 (五) 03:42 (UTC)[回复]

Timeless显示错误

自昨日开始，在使用Timeless作为皮肤的情况下，打开任意页面都会在页面标题前额外显示一个多余的“维基百科”字样。--ElectronicGhost｜👻 2024年7月5日 (五) 07:24 (UTC)[回复]

@ElectronicGhost 见上方 Wikipedia:互助客栈/技术#条目标题左侧出现多余的“维基百科”--Kethyga（留言） 2024年7月5日 (五) 08:42 (UTC)[回复]

小工具“编辑段落链接（[编辑]）靠右排列”使编辑按钮较正常位置偏高

本主题或以下段落文字，在讨论结束后应存档至MediaWiki talk:Gadget-moveEditsectionBack.css。

印象中这个问题似乎一直存在，今天来客栈提一下，不知道是否是普遍的情况。开启该工具（可在参数设置->小工具->界面显示工具一节找到）后，在每一个段落出现“[编辑源代码/查看源代码|快速编辑]”都明显较正常（不开启该工具）位置高，在条目标题旁边，因为位置太高，甚至会使“[编辑源代码/查看源代码|快速编辑]”文字大约上1/3部分“隐没”。--——自由雨日（留言・贡献） 2024年7月7日 (日) 03:04 (UTC)[回复]

猜测可能是近期系统字体大小调整导致的？--百無一用是書生 (☎) 2024年7月15日 (一) 02:59 (UTC)[回复]

T:Summer Olympics by year category navigation

本主题或以下段落文字，在讨论结束后应存档至Template talk:Summer Olympics by year category navigation。

参见Category:2024年夏季奥运足球赛（简）、Category:2024年夏季奥运足球赛阵容（繁），想请问有什么方法可以让此模板同时在简中/繁中标题的分类中使用？--Liebhart 💬👩‍🚀 2024年7月7日 (日) 04:15 (UTC)[回复]

(＆)建议还是将模板撷取至"YYYY年夏季"，就不会有简繁问题，虽然可以加入前缀、后缀来达到目的，但然容易产生标题简繁不一的现象。--Qqkuro66541（留言） 2024年7月9日 (二) 17:40 (UTC)[回复]
了解，看见您已经将模板修改好了，感谢帮助！——Liebhart 💬👩‍🚀 2024年7月10日 (三) 02:52 (UTC)[回复]

移动版Navbox

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

现在移动版在Wikipedia:命名空间下会显示Navbox了，不确定正不正常。[18]--User:What7what8🏠 2024年7月7日 (日) 12:20 (UTC)[回复]

没留意到技术新闻有相关的更新信息。也没见到条目放开Navbox等的渲染调整。如果不是wmf开发测试中，或者是以前就可以？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月8日 (一) 00:44 (UTC)[回复]
显示的惨不忍睹的正常--百無一用是書生 (☎) 2024年7月8日 (一) 02:35 (UTC)[回复]
看了眼en。如果没有过往记录印证是除条目空间外的navbox是隐藏外，可能是基金会测试？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月8日 (一) 09:36 (UTC)[回复]

2024年第28期技术新闻

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

最近更改

问题

  • Vector 2022中出现一个问题，讨论页标签的颜色始终显示为蓝色，即使不存在页面本应显示为红色。此问题已解决。

未来更改

  • 信任与安全产品团队希望以尽可能不干扰工具和工作流的方式引入临时帐号。恳请志愿开发者——包括小工具和用户脚本维护人员——更新您维护的工具和功能的代码以应对临时帐号。团队已建有文档来解释如何进行更新。了解更多。

技术新闻调查

  • 邀请您填写这份简短问卷调查，协助我们改善技术新闻。本次调查旨在更有效地满足阅读技术新闻的各类读者的需求。本次调查还会开放一周。本次调查适用这份隐私声明。本次调查提供其他语言的翻译版本。

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

MediaWiki message delivery 2024年7月8日 (一) 21:30 (UTC)[回复]

CampaignEvents似乎可以考虑？--百無一用是書生 (☎) 2024年7月9日 (二) 02:20 (UTC)[回复]

检测模板限制

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

模板限制很烦人，而且往往不知问题具体出在何处。是否有工具可协助编者确认哪里调用特别多资源？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月9日 (二) 10:38 (UTC)[回复]

好像没有很好的方法？页面“div.mw-parser-output”里面结尾有段HTML注释“NewPP limit report”和“Transclusion expansion time report”，可以看那个模板消耗时间和调用次数较多。或者借助WP:SB将内容逐点替换来分析。不过大部分情况，WP:模板限制基本上都说了：Navbox（尤其是包含大量ilh系的），包含了大量Navbox的Navboxlist，还有太多脚注的reflist系脚注模板。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月9日 (二) 11:21 (UTC)[回复]

古籍模版似乎默认地区为中华人民共和国

老残游记一文可以看到右侧模版显示出版地点为“中华人民共和国”但在代码中并未体现此内容。在下在模版的页面也并未见到此项默认选项，是故提出，希望有同仁可以帮忙调整。--懒癌哪天行→Laziness, as no today's excuse. 2024年7月9日 (二) 10:59 (UTC)[回复]

已处理，是wikidata那边的事情。--银色雪莉（留言） 2024年7月9日 (二) 12:53 (UTC)[回复]

首页下半部分排版乱了

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

Wikipedia:首页排版乱了，下方的常用链接和姊妹计划全都挤到右侧了，动态热门和欢迎词的间距也变了。查了最近的修改，未发现修改有问题--百無一用是書生 (☎) 2024年7月10日 (三) 02:10 (UTC)[回复]

看时光机存档（2024年1月1日）的话，“div.mp-2012-links”、“div.mp-2012-sisters”是放在“div.mp-2012-body”孩子中，与“div.mp-2012-column-left”、“div.mp-2012-column-right”是兄弟。现在是放在“div.mp-2012-column-right”里面。是不是有脚本可以判断“div.mp-2012-column-left”和“div.mp-2012-column-right”的高度，然后将前者抽出去？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月10日 (三) 02:26 (UTC)[回复]
Wikipedia:每日图片/2024年7月10日，宽度调小一点，不知道有没问题？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月10日 (三) 02:33 (UTC)[回复]
应该有脚本做平衡处理，[19]是抽了links和sisters出来平级，[20]则抽了links跟column-left“同宽”嵌进去了。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月10日 (三) 02:35 (UTC)[回复]
 已修复，最近一次的{{itn}}更新误删了一个</div>--百無一用是書生 (☎) 2024年7月10日 (三) 02:50 (UTC)[回复]
乐。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月10日 (三) 03:07 (UTC)[回复]

销售认证模板被我改出了bug

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

问题已解决
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

出错的文件在Template:Certification_Table_Entry模板，具体出错的几行代码如下： 

{{!}} {{#if:{{{nocert|}}}|{{sdash}}{{#if:{{{nocat|}}}||{{main other|<!-- [[Category:使用Certification Table Entry沒有認證的頁面]]-->}}}}|{{#ifeq:{{{region|}}}|Mexico|{{Certification Table Entry/MexicanAward|award={{{award|}}}|number={{{number|}}}|number2={{{number2|}}}|number3={{{number3|}}}}}|{{#if:{{{number|}}}|{{#ifeq:{{{number}}}|1||{{{number}}}×}}|}} {{{award}}}{{#switch:{{{award|}}}|Silver|Gold|Platinum|Diamond|Million|Billion|Platinum+Gold|Diamond+Gold|Diamond+Platinum|Diamond+Platinum+Gold=|#default={{main other|[[Category:Pages using Certification Table Entry with unsupported award]]}}}}{{#switch:{{{type|}}}|album|single|video|jazz|compilation|videosingle|ringtone|EP|=|#default={{main other|[[Category:Pages using Certification Table Entry with unsupported type]]}}}} {{#if:{{{Spanish|}}}|([[RIAA certification#{{#switch:{{{type}}}|album=Latin|single=Singles}}|Latin]])}}}}}}

请问如何修改这一段，让输入Silver、gold等英文的时候，模板转为显示成银、白金等中文呢？--Scarsnevergoaway（留言） 2024年7月10日 (三) 08:30 (UTC)[回复]

Help:解析器函数#switch。目前好像写反，该“Silver|银|银=银|Gold=金|Platinum=白金|”这样？代码很乱没弄清。--YFdyh000（留言） 2024年7月10日 (三) 13:00 (UTC)[回复]
谢谢，我明天改改--Scarsnevergoaway（留言） 2024年7月10日 (三) 15:40 (UTC)[回复]
问题已解决，请求关闭讨论--Scarsnevergoaway（留言） 2024年7月13日 (六) 06:35 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

提报DC的小工具什么时候能更新啊

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:动员令/第二十二次动员令。

如题，都开始好几天了一直没人更新脚本，手填既不方便还容易出错，都没参与的积极性了（恼）。DC本身的讨论页有不少人反映过了，但也没见脚本更新……--Nanhuajiaren（留言） 2024年7月11日 (四) 01:26 (UTC)[回复]

@Nanhuajiaren：目前主持人正在讨论中。技术人手不足Orz —— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月11日 (四) 05:35 (UTC)[回复]
今年和去年的东西几乎差不多的吧？除了修改常量之外也就去掉界面上新增来源那一行（因为去年有缺来源的小项今年没有）。--Nanhuajiaren（留言） 2024年7月11日 (四) 07:11 (UTC)[回复]
@Nanhuajiaren：主要是动员令主持人团队向来仰赖本站仅有的几位介面管理员，最近刚好不少在休息，没空帮忙。这一两天应该能解决。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月11日 (四) 16:32 (UTC)[回复]
应该已经好了。--Leiem（留言·签名·维基调查） 2024年7月12日 (五) 17:13 (UTC)[回复]

Navbox标题置中

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

Navbox标题似乎还是没法对齐中间（见模板说明页面范例，可参照above参数位置及英文版本），是不是需要额外设定什么间距？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月11日 (四) 06:26 (UTC)[回复]

中维以前的方案是固定宽度左右各保留8em，至于Wikiplus会撑爆那就让Wikiplus自己修吧。--Dabao qian℡ 2024年7月11日 (四) 10:14 (UTC)[回复]
不是Wikiplus问题，Template:Navbox中的示例1和3（从上往下数）的确现在往右歪了一点，但示例4却差不多是居中的。把.navbox-title .navbar的样式改成margin-right: -1.6em;示例1和3似乎能差不多居中了，但是示例4却又歪了--百無一用是書生 (☎) 2024年7月11日 (四) 13:01 (UTC)[回复]
尝试修了一下[21]，现在除了示例4外，其他看起来差不多都居中了--百無一用是書生 (☎) 2024年7月11日 (四) 13:38 (UTC)[回复]
但是navbar和展开被挡住了，点不到。--Cookai饼块🍪（💬留言） 2024年7月11日 (四) 13:42 (UTC)[回复]
回退了，这样修改后，左右两侧都无法点击了--百無一用是書生 (☎) 2024年7月11日 (四) 13:42 (UTC)[回复]
如果是让左右侧absolute呢？
即Special:PermaLink/83367707加上
.navbox-title .navbar { position: absolute; left: 1em; }

.navbox-title .mw-collapsible-toggle { position: absolute; right: 1em; }
--Cookai饼块🍪（💬留言） 2024年7月11日 (四) 14:04 (UTC)[回复]
.navbox-title .navbar {
    /* @noflip */
    float: left;
    /* @noflip */
    text-align: left;
    /* @noflip */
    margin-right: 0.5em;
    width: auto;
    padding-left: 0.2em;
    position: absolute;
    left: 1em;
}

/* In navboxes, the show/hide button balances the v·d·e links
   from [[Template:Navbar]], so they need to be the same width. */
.navbox .mw-collapsible-toggle {
    margin-left: 0.5em;
    position: absolute;
    right: 1em;
}

这样看上去并没有什么问题。当然，Module:Navbox也需要做修改，因为设置|navbar=plain之后产生的占位符也需要有相同的样式。 

    -- Render the spacer div.
    if spacerSide then
        titleCell
            :tag('span')
                :css('float', spacerSide)
                :css('position', 'absolute')
                :css(spacerSide, '1em')
                :css('margin-' .. (spacerSide == 'left' and 'right' or 'left'), '0.5em')
                :css('padding-' .. spacerSide, '0.2em')
                :wikitext('&nbsp;')
    end
end

--Dabao qian℡ 2024年7月11日 (四) 15:26 (UTC)[回复]

@Shizhao：用这个模板来看，可以知道目前标题还是歪的。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月11日 (四) 16:31 (UTC)[回复]
这样修改之后Template:JR东日本的车辆似乎显示有问题，左右两侧的按钮会和色块重叠，这种情况需要写脚本修复到4em才能正常显示。--Dabao qian℡ 2024年7月11日 (四) 17:44 (UTC)[回复]
在Special:PermaLink/83367707的基础上按上述方案分别修改MediaWiki:Common.css和Module:Navbox即可。--Dabao qian℡ 2024年7月11日 (四) 18:57 (UTC)[回复]
改了，看看是否还有问题--百無一用是書生 (☎) 2024年7月12日 (五) 02:46 (UTC)[回复]
目前发现的问题是当浏览器宽度（window.innerWidth）小于640px时，点击右侧折叠按钮后，折叠按钮、查论编和标题全都会跑到左侧叠在一起。暂不确定是否和本次修订相关--百無一用是書生 (☎) 2024年7月12日 (五) 03:05 (UTC)[回复]
可以复现，原先是页面宽度小于640px时会折行显示，改完之后强制缩排在同一行就会直接叠在一起。--Dabao qian℡ 2024年7月12日 (五) 18:16 (UTC)[回复]

现有的技术能否做到将新条目自动加入相关专题的新进条目列表内

我记得现在专题页面有个机器人，可以查看最近在评选FA、GA、DYK的各专题相关条目。但我打开音乐专题，发现新进条目这里还是靠人去手工加入的。能否让机器人自动更新一下，把近三十天创建的，且挂上各个专题评级模版的条目自动放进各个专题的首页，这样就免去人为添加了。--Scarsnevergoaway（留言） 2024年7月13日 (六) 06:31 (UTC)[回复]

我制作了一个自动翻译榜单排行的小工具，请问有什么办法可以推广？

我目前正开发一个音乐条目的自动翻译工具，希望能实现以下功能：

  1. 自动翻译单曲周榜单和年终榜单的表格。
  2. 自动翻译专辑周榜单和年终榜单的表格。
  3. 自动修正常见的榜单错误翻译。
  4. 自动翻译专辑和单曲条目制作人员名单的分工类型。
  5. 自动翻译曲目列表的部分常用类型。
  6. 自动翻译发行历史的国家名称和日期。
  7. 单曲和专辑信息框模版清理。
  8. 根据信息框模版自动生成条目导言。

目前已完成单曲榜单的自动翻译功能的初始版本。 使用方法如下： 将mw.loader.load('//baike.710302.xyz/w/index.php?title= User:Scarsnevergoaway/Tool/singlechart.js&action=raw&ctype=text/javascript');加入您的common.js页。

使用时，进入源代码编辑页，工具一栏会出现“单曲榜翻译”等分类，按照需求点击分类下的各功能按钮即可。在编写条目时，务必先使用本工具，再使用链接自动翻译器。

这个工具在经常参与音乐专题，翻译歌曲条目的编者这里还是挺好用的，可以省去大量重复性工作。请问有什么办法能推广一下这个吗。--Scarsnevergoaway（留言） 2024年7月13日 (六) 06:34 (UTC)[回复]

Infobox person/Wikidata 出生日期

中文数字与阿拉伯数字混用，例见热尔玛娜·维亚娜，“出生”显示为“1972年十月16日”--惣流·明日香·兰格雷不姓式波 2024年7月13日 (六) 07:52 (UTC)[回复]

无法复现。或许已经修复？--PexEric💬|📝 2024年7月13日 (六) 11:54 (UTC)[回复]
刚刚看了一下，似乎是只有香港和澳门版本有此问题，应与使用的装置和浏览器无关--惣流·明日香·兰格雷不姓式波 2024年7月14日 (日) 01:30 (UTC)[回复]
未登录时港澳版本可重现，登录后无法重现。--YFdyh000（留言） 2024年7月14日 (日) 02:22 (UTC)[回复]
哪个浏览器？我win11 firefox和edge，登入与否，无痕与否，均能复现，chrome的话没安装试不了。--惣流·明日香·兰格雷不姓式波 2024年7月14日 (日) 06:33 (UTC)[回复]
Win10 Edge。curl -v https://baike.710302.xyz/zh-mo/%E7%83%AD%E5%B0%94%E7%8E%9B%E5%A8%9C%C2%B7%E7%BB%B4%E4%BA%9A%E5%A8%9C 的源码里也能看到>1972年十月16日&#160;<。--YFdyh000（留言） 2024年7月14日 (日) 11:10 (UTC)[回复]
我这只有未登录时香港、澳门繁体能复现。--Kcx36（留言） 2024年7月14日 (日) 10:45 (UTC)[回复]

用户头衔模板重叠

似乎当两个template:Encourage之间有template:top icon时（例如任一有Encourage的头衔模板紧接一个Template:反破坏工作小组成员），两个Encourage头衔框会部分重叠，具体见User:方志维（随机选的，但他的情况非常明显）的一堆头衔。（小弟用户页直接复制了Template:反破坏工作小组成员的Encourage源码，所以没有此问题）--惣流·明日香·兰格雷不姓式波 2024年7月14日 (日) 09:19 (UTC)[回复]

我这里未发现有什么问题--百無一用是書生 (☎) 2024年7月14日 (日) 11:51 (UTC)[回复]
他刚刚移除了一堆模板，在历史版本仍可见（图），另见User:Ericliu1912（图）--惣流·明日香·兰格雷不姓式波 2024年7月14日 (日) 13:22 (UTC)[回复]
我自己看了看倒是没问题？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月14日 (日) 15:42 (UTC)[回复]
同上，我还是看不出截图中的问题，或许是浏览器或使用了某些js脚本导致？--百無一用是書生 (☎) 2024年7月15日 (一) 02:24 (UTC)[回复]
这就怪了，我win11 Firefox（有一些插件）登入与否都能复现，edge（没有插件）及android chrome（没有插件）同理。--惣流·明日香·兰格雷不姓式波 2024年7月15日 (一) 02:29 (UTC)[回复]
那可能是某个本站的js小工具或用户脚本导致的？--百無一用是書生 (☎) 2024年7月15日 (一) 03:03 (UTC)[回复]
但我的edge没有任何extention，也应该没有动过任何设定（平常用firefox），没有登入的话理应没有脚本或小工具？会否与装置或浏览器的语言或地区设定有关？--惣流·明日香·兰格雷不姓式波 2024年7月15日 (一) 03:10 (UTC)[回复]
咦，刚才重新打开了这两个用户页，莫名的就复现了...--百無一用是書生 (☎) 2024年7月15日 (一) 03:06 (UTC)[回复]
是重叠的模板写的有问题，解析成html后多了一个空行，可以参考我刚刚在Template:维基座标工作小组、Template:边缘人小组和Template:维权联盟盟友的修改方式对其他模板一并修改，把top icon和Encourage模板之间用<!-- -->断行，最后的分类和模板之间不要断行或者也用<!-- -->断行--百無一用是書生 (☎) 2024年7月15日 (一) 03:23 (UTC)[回复]
{{维基近卫骑士}}怎么修改？--Miyakoo（留言） 2024年7月15日 (一) 04:21 (UTC)[回复]
 已修复--百無一用是書生 (☎) 2024年7月15日 (一) 06:22 (UTC)[回复]

求助

Category:中南大学大学维基人的移动问题

本主题或以下段落文字，在讨论结束后应存档至Category talk:中南大学维基人。

已解决：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

由于分类中南大学大学维基人有语法错误，我已将其移动至中南大学维基人，但是不知道怎么回事，分类页面好像出问题了； 各位编者还是去看下是怎么回事吧。（我是不知道怎么办了）--—梦夕琳 如有事，请快来沟通 2024年7月3日 (三) 05:38 (UTC)[回复]

还有，{{User CSU}}里面的分类也修改了。--—梦夕琳 如有事，请快来沟通 2024年7月3日 (三) 05:41 (UTC)[回复]
看起来没问题了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月3日 (三) 08:21 (UTC)[回复]
@Ericliu1912 应该是有人修复了。—梦夕琳 如有事，请快来沟通 2024年7月3日 (三) 11:29 (UTC)[回复]
其实您把模板分类处理完，其馀页面就会自动归类。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月3日 (三) 18:30 (UTC)[回复]
出了什么问题？--自由雨日（留言） 2024年7月3日 (三) 08:54 (UTC)[回复]
@自由雨日 没问题了，已经有人搞好了；就是一开始分类移动没搞好。—梦夕琳 如有事，请快来沟通 2024年7月3日 (三) 11:30 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

请求协助编辑内容

请求协助编辑此条连结中的内容：Talk:洛阳钼业#请求协助增添以及删除社会责任章节相关内容 。谢谢！--SandroP3l（留言） 2024年7月4日 (四) 03:10 (UTC)[回复]

完成 --伞木 霙留言 2024年7月6日 (六) 09:22 (UTC)[回复]

请求协助上传档案 2024-07-05 10:11

我想要上传的图片来源是迷你玩的官网下载,url为https://mnweb.mini1.cn/activity/miniweb/images/bottom_logo1.png，想要使用在迷你玩的信息框 --BlackTea67（留言） 2024年7月5日 (五) 10:11 (UTC)[回复]

完成 --伞木 霙留言 2024年7月6日 (六) 09:21 (UTC)[回复]

Category:获得圣基茨和尼维斯公民身份者

本主题或以下段落文字，在讨论结束后应存档至Category talk:归化圣基茨和尼维斯公民。

Category:获得圣基茨和尼维斯公民身份者 (linked to en:Category:People with acquired Saint Kitts and Nevis citizenship) is not needed. Please replace it with {{分类重定向|归化圣基茨和尼维斯公民}},--Fayenatic london（留言） 2024年7月5日 (五) 21:54 (UTC)[回复]

如何使用Twinkle一次提删多个页面？

如题。据我所知存废讨论是可以一次提删多个页面的（比如这个），但似乎Twinkle并没有这个功能？--古怪的Wang31（讨论 | 贡献） 2024年7月6日 (六) 09:32 (UTC)[回复]

此例是人手写的，Special:Diff/83094952。
上面很长的，也是人手写的，Special:Diff/82711408。
TW应该是没有这个功能。--Miyakoo（留言） 2024年7月6日 (六) 09:56 (UTC)[回复]
Twinkle无此功能（单一标题并列多个页面名称），但有“批量提删”功能。Sanmosa 蚌埠 2024年7月9日 (二) 05:23 (UTC)[回复]

请求协助编辑国旗相关模板

请求熟悉国旗模板的维基人协助编辑{{Country data Kingdom of Italy}}。

  • {{flag|Kingdom of Italy}}→ 义大利王国。效果正确。
  • {{flagicon|Kingdom of Italy}}→义大利王国。链接指向不正确。
  • {{flagathlete|谁谁谁|Kingdom of Italy}}→ 谁谁谁（义大利王国）。链接指向不正确。

——三猎（留言） 2024年7月6日 (六) 12:29 (UTC)[回复]

请求协助上传档案 2024-07-06 14:18

我想要上传的图片来源是<https://cdn.pingwest.com/portal/2023/09/26/42HtQ7dQ6KK7C7SXQ3EnS6MPA68hP74M.jpeg?x-oss-process=style/article-body>，想要使用在（https://baike.710302.xyz/wiki/%E5%88%98%E4%BC%9F_(%E7%B1%B3%E5%93%88%E6%B8%B8)>。 --Rg4srefg1e5（留言） 2024年7月6日 (六) 14:18 (UTC)[回复]

untitled

希望在中维创建一些目前缺失的主流投资机构页面，但是发现标题中带有“投资”的无法创建。希望创建的页面有：鼎晖投资、厚朴投资。--Muyao (Roy) Liu（留言） 2024年7月7日 (日) 21:00 (UTC)[回复]

页面易被用作广告宣传，所以社群使用标题黑名单进行了限制。您可以在沙盒页面创建草稿，若内容合适，其他用户可以协助移动。——暁月凛奈 (留言) 2024年7月7日 (日) 23:24 (UTC)[回复]
1.请求协助移动，应该在哪个页面申请合适？
2.绝大多数XX Investments的机构官译中文均为“XX投资”，妥否有更合适方案？--Muyao (Roy) Liu（留言） 2024年7月8日 (一) 06:32 (UTC)[回复]
直接在页面相应的讨论页使用Template:Requested move提出即可，它会把页面加到Category:移动请求中。这一类标题的限制是允许自动确认用户创建，即达到一定注册时长和编辑次数的用户。目前的技术水平大概无法自动判断内容是否为广告宣传。——暁月凛奈 (留言) 2024年7月9日 (二) 02:06 (UTC)[回复]

无法编辑页面

https://baike.710302.xyz/zh-tw/%E6%B6%BC%E6%A3%AE%E7%8E%B2%E5%A4%A2

我想新增凉森玲梦的作品，但编辑后不能储存，请协助--はなか有花果（留言） 2024年7月8日 (一) 07:00 (UTC)[回复]

请协助编辑页面内容

https://baike.710302.xyz/wiki/Wikipedia:%E6%B2%99%E7%9B%92 我需要将以上沙盒的内容编辑到‘凉森玲梦’的页面

https://baike.710302.xyz/zh-tw/%E6%B6%BC%E6%A3%AE%E7%8E%B2%E5%A4%A2--はなか有花果（留言） 2024年7月8日 (一) 07:12 (UTC)[回复]

协助请求：请帮忙确认条目符合生者传记方针

生者传记条目李琴峰发生编辑战，有用户执意为该条目加入违反生者传记方针的内容，包含:“有关在世人物的无来源或少来源的争议内容”、不可信的“自行出版来源（如传主个人页面，以及特定政党脸书粉丝页之发文）”，并侵害传主个人资料以及姓名的隐私。该编辑明显违反方针，但因条目关注度较低，无法取得立即性的修复，故在此邀请并请求社群协助关注，以确保条目符合维基百科方针。--Alibadaba159（留言） 2024年7月8日 (一) 15:38 (UTC)[回复]

请求协助上传档案 2024-07-08 16:50

我想要上传的图片来源是<https://www.opentix.life/event/1519603192318570498>，网站内简介说明中的第一张照片，想要使用在达康.come的主要照片，并加上说明<达康.come在2019年于国家两厅院活动《厅院指南：活尸末日剧院求生守则》拍摄之照片>，初次使用维基，谢谢你们的协助。 --SADONE28（留言） 2024年7月8日 (一) 16:50 (UTC)[回复]

请求协助上传档案 2024-07-09 13:39

我想要上传的图片来源是<https://s2.loli.net/2024/07/09/MsbQ3AvXJKYmewN.jpg>，想要使用在伞少女的<电影信息框/图像>。 --三水少年（留言） 2024年7月9日 (二) 13:39 (UTC)[回复]

请求协助上传档案 2024-07-09 14:25

我想要上传的图片来源是<https://www.nmns.edu.tw/ch/research/research-and-writing/detail?id=A047&no=2>，想要使用在image的自介栏中<birth_date>上方插入。 --Mason H.Huang（留言） 2024年7月9日 (二) 14:25 (UTC)[回复]

请求协助上传档案 2024-07-10 19:51

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

战队配音问题

战队战士人物的香港配音现在被铲掉，超力霸王、假面骑士却有主要战士显示有香港配音员而且没有构成对维基百科方针的内容违背。可否重新加上？--Mr tiger Shun Kit（留言） 2024年7月12日 (五) 03:27 (UTC)[回复]

停用结构式讨论造成错误

于Phabricator查看
编号T369975的工单
状态：已解决

我的讨论页User_talk:C9mVio9JRy本来用结构式讨论，因为收到通知说要终止该功能，所以点选了停用，结果我的讨论页似乎就坏掉了？--C9mVio9JRy（留言） 2024年7月13日 (六) 07:41 (UTC)[回复]

帮你喊有能力解决这个问题的人了，请稍等。--碟之舞📀💿 2024年7月13日 (六) 07:57 (UTC)[回复]
@C9mVio9JRy：已修复。--碟之舞📀💿 2024年7月13日 (六) 10:30 (UTC)[回复]
直接帮你修好了。结构式讨论真是令人头大！—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月13日 (六) 10:31 (UTC)[回复]
谢谢！--C9mVio9JRy（留言） 2024年7月13日 (六) 10:49 (UTC)[回复]

关于来源问题

--Yoly0514（留言） 2024年7月13日 (六) 11:47 (UTC) 我最近在编辑一个YT上的小网红(黄诗敏)的页面，但是他毕竟是小网红，所以我在网路上也找不太到有关他的报导，大部分的来源都是来自他的影片或是社群媒体，但是又不能用他自己说的东西做来源，我想尽快解决这个问题，因为这让我非常困扰，如果有路过的管理员可以说明，麻烦用口语化一点，不然太官腔或正式的语言会让我很难理解:([回复]

  1. 未能满足Wikipedia:关注度 (人物)、Wikipedia:关注度 (音乐)
  2. 未能满足WP:生者传记对于知名的公众人物，应使用大量可靠的第三方出版来源来取得内容
  3. 未能满足WP:生者传记对于第一手来源不是文章主要的来源的要求
  4. 未能满足需WP:关注度#通用关注度指引，缺乏第二手来源（二次文献）或第三手来源
--Rastinition（留言） 2024年7月13日 (六) 12:02 (UTC)[回复]
但是就是找不到第三方来源怎么办--Yoly0514（留言） 2024年7月13日 (六) 12:30 (UTC)[回复]
那就请不要建立，就算是网路百科全书，也不是什么文章都收的，请待有合适的来源出现再建。--WiTo🐤💬 2024年7月13日 (六) 12:43 (UTC)[回复]
上述二位维友已提供意见，如果没有关注度就不要强行建立，避免潜在的违规扰乱行为反而招致管理员限制您的编辑权限，谢谢。--薏仁将🍀 2024年7月13日 (六) 20:20 (UTC)[回复]

User talk:SkEy/结构式讨论 存档 1

于Phabricator查看
编号T238427的工单

这个页面一直被分类到Category:快速删除候选，想要删掉但是找不到这个分类文本放在什么地方--百無一用是書生 (☎) 2024年7月15日 (一) 02:43 (UTC)[回复]

似乎属技术问题，见Wikipedia:互助客栈/求助/存档/2024年6月#用户讨论:SkEy/结构式讨论_存档_1--千村狐兔（留言） 2024年7月15日 (一) 02:49 (UTC)[回复]
这个问题是我重启结构式讨论之后再次禁用出现的，我暂时也没什么好的解决办法。—さき せかいSaki Sekai（讨论｜贡献） 2024年7月15日 (一) 05:17 (UTC)[回复]

请求协助上传档案 2024-07-15 07:28

我想要上传的图片来源是自行拍摄，想要使用在船形山站的副站名说明。 --瀚可（留言） 2024年7月15日 (一) 07:28 (UTC)[回复]


条目探讨

用于表示日本节庆活动的“祭”是否可以视为恰当的中文用法

看到将“Category:琉球节日”改为“Category:冲绳县的祭”现象，产生的疑惑--苞米(☎)💴 2024年6月14日 (五) 09:14 (UTC)[回复]

你成功勾起了我对“纪”这个字的心理阴影。--MilkyDefer 2024年6月14日 (五) 12:22 (UTC)[回复]
大草，你是在说这个？--BigBullfrog（𓆏） 2024年6月16日 (日) 18:38 (UTC)[回复]
不应视为中文。汉语“祭”无此用法（可查阅《现代汉语词典》《国语辞典》《辞源》等等）。--自由雨日（留言） 2024年6月14日 (五) 12:33 (UTC)[回复]
如果此处的祭如同战祭、丰年祭，是指庆典或活动的话，可参见《教育部异体字字典》释义五。[22]--夜月辰星（留言） 2024年6月14日 (五) 12:44 (UTC)[回复]
如果此处讨论的是Category名的话，或许可以参照Category:日本铁路公司，条目名使用特例的铁道，而Category名则用惯例的铁路。--夜月辰星（留言） 2024年6月14日 (五) 12:57 (UTC)[回复]
既然《教育部异体字字典》给出了这个义项，那么说明“祭”在汉语中确实可以表示“庆典活动”的意思，但我仍不认为可以用来作标题，理由有三：一、《异体字字典》没有给出词性说明，不过从例句（例词）为“雪祭”、“海洋祭”、“音乐祭”等来看，“祭”表示此义时可能只能用作词缀（例如“作者”“读者”的“者”字、“产业化”“绿化”的“化”字等），“冲绳县的祭”中“祭”直接作为成词语素，这可能是不合法的，至少很不符合语感；二、目前只有台湾的词典给出这种用法，可能不是所有汉语地区广泛的用法；三、即便在中国大陆等地区的词典中找到了这种用法，用“祭”来表示庆典活动在汉语中仍是不常见的，完全可以用更常见的方式来表达。--自由雨日（留言） 2024年6月14日 (五) 12:57 (UTC)[回复]
这两个节日名称本来就是沿用日治时期的日文写法吧？--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年7月8日 (一) 05:03 (UTC)[回复]
意味不明啊？维基人接纳某些活动常用名称为中文就算了，分类可以自己命名就或许不必如此了吧？不过日本相关分类好像都这样，有整体考虑必要。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 12:47 (UTC)[回复]
可以改用祭典。--AT 2024年6月14日 (五) 13:20 (UTC)[回复]
中文普通名词“节日”不应换成日语的“祭”，并非是专有名词。现代标准汉语中“祭”一般是祭祀的意思。反对使用祭典，祭典不是节日。百科全书面向的是普通的中文读者。--Kethyga（留言） 2024年6月14日 (五) 14:05 (UTC)[回复]
条目祭 (日本)在2007年由武藏创建并使用了“祭”，分类:日本的祭>分类:日本各都道府县的祭>……亦依从了这样的命名。如需更改应一并更改，可使用“祭典”。--绀野梦人 2024年6月14日 (五) 14:08 (UTC)[回复]
如果祭是普通日语词汇而非有特别意义和限定，不应这样用。--YFdyh000（留言） 2024年6月14日 (五) 14:13 (UTC)[回复]
同意Kethyga君，贡寮国际海洋音乐祭可以，但Category:冲绳县的祭不行，因为前者是专有名词，而且用“祭”表达活动或庆典仍不是中文圈普遍的用法。固然语文是活的、会改变、会交流的，语文也可以有外来语，但此种用法尚未成为中文外来语。-游蛇脱壳/克劳棣 2024年6月14日 (五) 15:26 (UTC)[回复]
应该是一种日文汉字借入中文汉字语境的情况，但仅限于专用名词化（例如札幌雪祭等），如果作为一个独立语素作为其他语素的被修饰对象，类似上述举例，应该没有对应类似“节日”、“祭典”的意思，可能需要对应替换为相应语言的独立语素“节日”或者“祭典”。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月15日 (六) 00:53 (UTC)[回复]
但纠结下去的话，“祭”在中文汉字的语言有“对死者表示追悼、敬意的仪式”、“供奉鬼神或祖先”的意思，对应日文汉字其意思也有类似的语义：因为日本这些“祭”的前身有相当是与“供奉鬼神”等的仪式。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月15日 (六) 00:53 (UTC)[回复]
经我再三考虑，我建议全面废除“日本的祭”以下所有分类，改以“神道祭事”取代（有需要的话可再按都道府县细分），与神道无关的如札幌雪祭等则划入日本年度活动（有需要的话可再按都道府县细分），只有明确区分祭典和活动才能解决目前的问题。--AT 2024年6月15日 (六) 08:52 (UTC)[回复]
"祭"可以作为日语汉字直接引入汉语的外来词。--小河仔（留言） 2024年6月26日 (三) 10:22 (UTC)[回复]
未经词典等收录，不得人为“引入”外来词，这属于原创研究（原创新词）。另外，您是新注册用户，第一条编辑便是在条目探讨内突然回复，这是为何？（这种现象难免令人多想，故需确认）--自由雨日（留言） 2024年6月26日 (三) 10:29 (UTC)[回复]
在编辑条目时看到了互助客栈。--小河仔（留言） 2024年6月26日 (三) 10:30 (UTC)[回复]
上一条回复是您的第一笔编辑。按理说，新用户并不熟悉客栈。如您有其他主账号，还请根据WP:傀儡政策公开。若真是新注册用户，那可以忽略我说的。--自由雨日（留言） 2024年6月26日 (三) 10:33 (UTC)[回复]
我刚刚接触互助客栈，觉得很新奇，像BBS论坛一样。--小河仔（留言） 2024年6月26日 (三) 10:39 (UTC)[回复]
哦哦，好的。欢迎来到维基百科。--自由雨日（留言） 2024年6月26日 (三) 10:45 (UTC)[回复]
据我所知，“祭”（名词）在现代汉语中是不成词语素，不能单独作为一个词使用，即使在日本文化相关的语境下也是如此。因此即使表示日本节庆活动的“祭”可以视为恰当的中文用法，“XX节日”也不宜改为“XX的祭”。--CuSO4 · 龙年大吉 2024年6月15日 (六) 17:12 (UTC)[回复]
也许从分类命名一致性出发，所有相关分类都应该使用“节日”为后续。现在Category:各国节日分类之下，也就是“日本的祭”显得独行独立。
看了一下日维，对方是ja:Category:各国の祭，日本的分类有点过分名从主人。--Nostalgiacn（留言） 2024年6月16日 (日) 01:36 (UTC)[回复]
日本节日是可以有的，但是这不等同于祭，例如御盆节本身是个节日，而非祭，尽管在这些节日期间很大机会举行各种各样祭，两者还是不对等的。因此，神道祭事本身也不打算归类至各国节日，日本节日则应该是日本年度活动的子分类。--AT 2024年6月16日 (日) 09:48 (UTC)[回复]
就算是“Category:神道祭事”这个分类，在Category:宗教节日也显得独行独立，其他都是“佛教节日”、“基督教节日”。对比其他语言维基，英维也是“Shinto festivals”（宗教名+festivals），日维是“神道行事”（宗教名+行事）。
还是上面说的日本的分类有点过分名从主人，感觉应该使用“分类命名一致性”处理一下。
就算不说XX祭这个问题，退一步讲，当前应该先建立“日本节日”分类，冲绳县的祭也应该恢复“琉球节日”。--Nostalgiacn（留言） 2024年6月17日 (一) 02:22 (UTC)[回复]
“冲绳县节日”与“琉球节日”是否有差别？严格意义上肯定有（后者传统一些），但宽泛一些的分类是否也有？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月17日 (一) 06:36 (UTC)[回复]
琉球可以指曾经一个国家（琉球国），冲绳县是现在日本一个行政区。当前的移动本来就很怪。
退一步说，未来有祭祀活动的分类，也应该另建“冲绳县宗教节日”，在“冲绳县节日”之下。
关系如下：
琉球节日》冲绳县节日》冲绳县宗教节日--Nostalgiacn（留言） 2024年6月17日 (一) 08:01 (UTC)[回复]
琉球除了是个国家，还是个民族，“琉球节日”在当前语境中更应该不理解为琉球民族的节日--苞米(☎)💴 2024年6月17日 (一) 13:00 (UTC)[回复]
欢迎补充，那么你是否支持改回“琉球节日”，以作为整合琉球文化相关节日的分类，再另建“冲绳县节日”作为下行分类。--Nostalgiacn（留言） 2024年6月17日 (一) 16:52 (UTC)[回复]
其实分类的话不用那么严格，分类重新导向即可。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月25日 (二) 10:58 (UTC)[回复]
分类收录的确实是冲绳县的节庆，这样命名是考虑到与d:Q8447345对应及与本站既有分类一致（随讨论结果同步修改）。琉球国是冲绳县的建前历史（类比Category:夏威夷州>Category:夏威夷州历史>Category:夏威夷建州前历史>Category:夏威夷王国），琉球民族是来自这一地域的族群（类比Category:夏威夷州>Category:夏威夷原住民），这样分类是可行的，如需细分也可再设立子分类。但这已经不是本则讨论的主旨了。--绀野梦人 2024年6月18日 (二) 04:02 (UTC)[回复]
我翻了一些分类，明白为何有种违和感，因为中维有Category:亚洲各民族节日这个分类体系，英维没有这个体系，你将一个原本是基于“各民族节日”建立的分类，转换成“各国节日”。有点生搬硬套导致的违和感。--Nostalgiacn（留言） 2024年7月9日 (二) 02:52 (UTC)[回复]

上面讨论都大致认为应该日本的相关分类统一为“Category:XX的节日”。如果没有其他意见，会稍后进行操作。

“神道祭事”分类个人提出应该与其他“宗教节日”统一为“神道节日”，这个有其他看法吗。--Nostalgiacn（留言） 2024年7月5日 (五) 07:27 (UTC)[回复]

“的”字多不必。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月5日 (五) 07:30 (UTC)[回复]
(－)反对更改神道祭事分类，祭事不是节日，例如葵祭仅仅是个别神社的仪式，在神道内没有作为节日的共通性。另外，日本节日分类的设立仍然要考虑如何归类，不是有个“祭”字就是节日。--AT 2024年7月5日 (五) 08:28 (UTC)[回复]
能否解释一下，英维为何用festivals（en:Category:Shinto festivals），日维用ja:Category:神道行事（年中行事（日语：年中行事）），而中维使用“祭事”一词。
你不反对前面的吧，毕竟你也说日本节日则应该是日本年度活动的子分类。分出另一个“祭”作为下级分类是一回事，“日本节日”还是要有的。--Nostalgiacn（留言） 2024年7月7日 (日) 02:07 (UTC)[回复]
(－)反对“祭”不等于“节日”，参照《教育部异体字字典》，“祭”确实是中文用法。-Hierro） 2024年7月6日 (六) 16:31 (UTC)[回复]
认同“祭”不等同“节日”，但反对根据《教育部异体字字典》将其认定为“中文用法”，重复一下前面的论证：一、《异体字字典》没有给出词性说明，不过从例句（例词）为“雪祭”、“海洋祭”、“音乐祭”等来看，“祭”表示此义时可能只能用作词缀（例如“作者”“读者”的“者”字、“产业化”“绿化”的“化”字等），“冲绳县的祭”中“祭”直接作为成词语素，这可能是不合法的，至少很不符合语感；二、目前只有台湾的词典给出这种用法，可能不是所有汉语地区广泛的用法；三、即便在中国大陆等地区的词典中找到了这种用法，用“祭”来表示庆典活动在汉语中仍是不常见的，完全可以用更常见的方式来表达。另外为什么您的UTC时间超前1小时……——自由雨日（留言・贡献） 2024年7月6日 (六) 15:39 (UTC)[回复]
现在都国际化，让我们直接看日本旅游局的资料，有提供官方中文，日文“日本の祭りとイベント”，英文Japanese Festivals & Events，繁体中文是节庆活动、简体中文是日本祭典与盛会。
个人合理怀疑目前“日本的祭”的翻译是“日本の祭り”机翻，中文应该翻译“节庆”或者“祭典”。--Nostalgiacn（留言） 2024年7月7日 (日) 02:20 (UTC)[回复]
祭典不是指节日。--Daniel1023（留言） 2024年7月8日 (一) 05:09 (UTC)[回复]
从翻译角度来说，我举例的时日本给出的官方翻译，“日本の祭りとイベント”其中一个官方翻译就是“节庆”，可以理解为节日和庆典的缩写。
上面很多关于“祭”的讨论，都是中文语境的“祭”，变成语言考据的原创研究现场，“祭典不是指节日”这个问题也是如此。根本不是在讨论“日本の祭り”的翻译问题。
就我目前找到的资料来看，“日本の祭り”应该翻译作“日本祭典”或者“日本节庆”，如果有人强调要“祭”，选用日本官方的简体翻译“日本祭典”更好。--Nostalgiacn（留言） 2024年7月9日 (二) 01:52 (UTC)[回复]

继琉球节日，我再翻看了一些相关分类。明白一直存在的违和感在哪里了。

有好几套的分类系统，也由于不同编者的想法，导致一些概念和分类混在。Category:亚洲各民族节日这个分类方式搞出来的Category:日本传统节日。实际操作上，英维是连“日本电影节”都归到“日本节日”（请见en:Category:Film festivals in Japan）。按现在日本节日条目的说法，“日本节日包括日本的传统节日、公共假日、主题日和地方祭典”，很直观表达了“各国节日”这个分类方式要记录什么。Category:日本节日重复创建和删除的记录，可以看出各种想法冲突导致的混乱。

补充现状：英维很早就将Matsuri（英语：Matsuri）（祭り）重定向到Japanese festivals（英语：Japanese festivals）（本地日本节日），而日维很早就把“祭り（日语：祭り）”重定向到ja:祭（本地节日）。

除了改名，也许需要在wikidata改变其他语言维基的关联的分类，作为有很多知日派的中维，这里也可以采用折中道路，建立两个平衡分类，一个“日本节日”（日本的传统节日、公共假日、主题日），一个“日本祭典”（日本各地祭典），达至遥遥领先，与众不同。--Nostalgiacn（留言） 2024年7月9日 (二) 09:39 (UTC)[回复]

关于生长在朝鲜半岛的植物条目

本主题或以下段落文字，在讨论结束后应存档至WikiProject talk:植物、WikiProject talk:朝鲜半岛。

这是我之前发起对朝鲜条目的移动请求之后发现的问题，早前由机器人创建的植物条目以中国大陆的参考来源为标准，可能有些大陆的资料来源是1992年以前的，就把朝鲜半岛统称为“朝鲜”，导致大量这类条目的“分布”中都出现了朝鲜的消歧义内链，而且经查，确实会有分布在韩国的植物（如桧柏）在中国大陆的资料里“国外分布”一栏依旧是写“朝鲜”的情况，现在的问题是，要把这些条目消歧义，但消歧义页面有朝鲜 (地区)和朝鲜半岛似乎都可以选择，所以想问一下社群对此持有何看法。我个人倾向于链接去朝鲜 (地区)，因为中国大陆、日本均为偏政治化的地理概念，与朝鲜半岛这样的纯地理概念不太相同。（也就是说，如果使用朝鲜半岛的话，其他对应的应该是“日本群岛”“华北平原”之类的纯地理概念）。----FradonStar|八闽风云 2024年7月1日 (一) 03:31 (UTC)[回复]

地域上的“朝鲜”与韩半岛范围基本一致，连结过去都是没有问题的。不过若从来源能判明是半岛，还是将“朝鲜”字样直接改成“朝鲜半岛”以避免仅理解为朝鲜民主主义人民共和国较好；若难以判明，可以不变“朝鲜”字样，连结至较大范围的朝鲜 (地区)或朝鲜半岛。至于与政区并列，并无不可，“分布于某地形区”与“分布于某政区”都是成立的。--绀野梦人 2024年7月1日 (一) 16:40 (UTC)[回复]
@Yumeto：我觉得最好是定一个标准，不然虽说两个都可以链，但最终应该链到何处去呢？没有一个统一标准的话，后期的消歧义工作很难开展。----FradonStar|八闽风云 2024年7月2日 (二) 03:01 (UTC)[回复]
可以考虑把政治地理的“朝鲜 (地区)”移动到“朝鲜”，消歧义的“朝鲜”移动到“朝鲜 (消歧义)”。纯地理的朝鲜半岛并不包含济州岛、独岛这些离岛。--D（留言） 2024年7月2日 (二) 01:50 (UTC)[回复]
反对作此移动。既然“朝鲜”重定向至“朝鲜民主主义人民共和国”是中国大陆地域中心，那么“朝鲜”重定向至“朝鲜 (地区)”同样是“非中国大陆”地域中心，因为目前（至少21世纪以来）中国大陆从不会将“朝鲜 (地区)”称作“朝鲜”。--自由雨日（留言） 2024年7月2日 (二) 05:39 (UTC)[回复]
现况我不做评价，但是我前面提到的植物条目里面提到的“朝鲜”或许解释成地区更有说服力，而且这些条目的来源可能创建于1991年左右，那个时候中韩尚未建交，撇去政治因素的话，把朝韩两国称为朝鲜或许只能用地区来解释。----FradonStar|八闽风云 2024年7月2日 (二) 14:44 (UTC)[回复]
相关书籍有没有“南朝鲜”？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月2日 (二) 18:25 (UTC)[回复]
据我所知是没有，比如中国高等植物数据库全库记载的榉树，“国外分布”一栏只写着朝鲜和日本，而其他参考文献是明确有写它分布在韩国的（[23]），我也因此认为其他相关的以中国高等植物数据库全库为参考的植物条目中的“朝鲜”，应该指的是朝鲜地区/半岛，而不是朝鲜民主主义人民共和国。就算确实指后者，写朝鲜地区/半岛也没错，且不会出现歧义的问题。----FradonStar|八闽风云 2024年7月3日 (三) 04:15 (UTC)[回复]
我觉得下结论可能原创研究。如无额外来源证明，我宁可取消内部链接。扩大范围恐怕是曲解来源。
按使用帮助文档最后一页，国外分布可能写中南半岛、马来半岛。但是，没有写成朝鲜半岛。
数据集来源是中国植物志。[24]榉树的介绍，1998年出版。--YFdyh000（留言） 2024年7月3日 (三) 14:52 (UTC)[回复]
没错儿，上面的思维方式很容易构成原创研究。我觉得保持消歧义链接就是最好的方式，表示根据来源并不能不确定“朝鲜”具体指什么；然后再根据最新的文献资料逐一更新这些生物的具体分布地。--自由雨日（留言） 2024年7月3日 (三) 16:57 (UTC)[回复]
我上面只是反对说将“朝鲜 (地区)”移动到“朝鲜”，至于植物具体分布地的问题，建议根据最新的参考文献逐一考虑，简单地视作朝鲜/北韩或朝鲜（地区）都是不妥的（也进一步说明移动并不是好的处理方法）。30多年前的文献本身也不太适合使用。--自由雨日（留言） 2024年7月3日 (三) 05:37 (UTC)[回复]
可能不易确定所用来源和原始含义。建议保持+补充来源。--YFdyh000（留言） 2024年7月2日 (二) 12:14 (UTC)[回复]
问题是，这种植物小条目很多，每个一一确定麻烦很多，而且现状是朝鲜链入了消歧义页面，理论上这也是不应该的，而且现在就有比较合适的办法，就是链入朝鲜 (地区)或者朝鲜半岛。现在主要探讨的问题应该是链入哪个更为合适。----FradonStar|八闽风云 2024年7月3日 (三) 04:18 (UTC)[回复]
前者范围或许更大。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月3日 (三) 10:53 (UTC)[回复]
综合各方意见，现在对部分只链入“朝鲜”条目而未链入“韩国”的植物条目有三个解决方案：①去除条目中的朝鲜链接；②保持原来的消歧义链接；③将消歧义链接改为链入朝鲜 (地区)或朝鲜半岛。也邀请前面参与过相关讨论的用户@Yumeto、DEMONBANE、Ericliu1912、YFdyh000、自由雨日；另副知移动请求讨论的参与者@E2568、Lantx、CaryCheng、暁月凛奈。
我个人的意见是支持③，不反对①，反对②。消歧义页面本来就不应该作为一个健康的条目应该在正文中链入的页面，除非明确要把读者引导到消歧义页面中去，所以保持消歧义条目的链接我是绝不认可的。这也有了我此前发起的对朝鲜这一消歧义页面的移动请求，既然社群愿意去做朝鲜的消歧义，我也愿意配合消歧义的工作，但在这过程中，绕不开的就是对“朝鲜”一词的现代定义，不论是植物也好，还是其他相关事物也好，必然是需要链接到一个有实际内容的条目页面的，而不应该链入消歧义页面，所以恕我不能接受保持消歧义链接的处理方式。另外我这个人是比较调和折中的，我最希望解决的问题就是取消消歧义链接的链入，所以我不反对去除链接，这也不失为一种解决问题的方式，但既然这个朝鲜明明是有明确含义的，它很显然是一个地区的概念，我也很难理解为何有编者认为此等想法有曲解来源之嫌。现在链入朝鲜的页面过于庞大，逐一确定绝对不是解决问题的长久之计，只会让这个问题不断积压，久而未决。--FradonStar|八闽风云 2024年7月8日 (一) 05:40 (UTC)[回复]
上面支持②“保持消歧义链接”的应该只有我了。首先要明确我说的“保持”肯定不是“永久保持”，消歧义链接本身就是不应在条目内使用的；其次为何我支持“维持现状”，是因为每个条目的情况都不同，所以只能进行逐一改动而非整体改动。比如泽番椒属中的朝鲜黄链和鸡爪槭中的朝鲜黄链显然就不是同个意思。现在中维整个条目空间，大段无来源的、疑似原创研究的、需要维基化的内容比比皆是，如何解决，当然是一个个条目分别解决，而不是用机器人把所有无来源内容全部删掉；同理，这些黄链具体应该链至哪个“朝鲜”，应该逐条目一一对应，且建议根据近年来的新来源对应（而非1950年代的植物学词典）。--——自由雨日（留言・贡献） 2024年7月8日 (一) 05:59 (UTC)[回复]
@自由雨日：这个倒是问题不大，有如果一个植物分布在朝鲜半岛，分布上又同时出现了“朝鲜”“韩国”两个字眼，使用DisamAssist也能看得见，自然应该链入朝鲜民主主义人民共和国。但这不是主要的问题，也不是我提出这个问题的初衷，因为更多具有类似泽番椒属这样条目的问题还需要解决。----FradonStar|八闽风云 2024年7月8日 (一) 06:42 (UTC)[回复]
显然有很多条目全篇没有“韩国”两字但依然应链至“朝鲜民主主义人民共和国”，如全光益。（看错了，讨论的条目仅限植物条目。）——自由雨日（留言・贡献） 2024年7月8日 (一) 06:50 (UTC)[回复]
@自由雨日：请阁下看一下标题，这里讨论的是植物条目，其他的情况难道不应该要具体情况具体分析么？做消歧义工作的编者不可能连这么简单的辨别能力都没有；退一步说，就算植物条目只分布在朝鲜半岛北半部，那链入朝鲜 (地区)/朝鲜半岛也没有问题。----FradonStar|八闽风云 2024年7月8日 (一) 06:54 (UTC)[回复]
我知道，我发出这句话之后在您回复前马上就修改了（）不过建议将“现在的解决方法有三：①去除植物条目中的朝鲜链接；②保持原来……”中的“植物”一词提到最外面，以免其他编者再误会。--——自由雨日（留言・贡献） 2024年7月8日 (一) 06:56 (UTC)[回复]
已修改上面的文字。另外(～)补充一下，已经有编者在做消歧义工作了，我看到ta的处理方式是将其改为链入“朝鲜半岛”。----FradonStar|八闽风云 2024年7月8日 (一) 07:04 (UTC)[回复]
我认为应该根据最新来源全面改写。。然后直接使用精确的语词而不是管道链接。链接并不是谁都会去点击（或鼠标悬停）的，不管链入半岛还是链入地区或是链入北朝鲜，读者都只能看到显示的是“朝鲜”，并不清楚具体涵义，尤其是中国大陆读者基本会误认为是北朝鲜。本来保持黄链还能提示读者朝鲜的含义有争议，一旦清理黄链并用上了管道链接，反而使人误解。（当然，如果您说的改为链入“朝鲜半岛”是指直接改写成“[[朝鲜半岛]]”而非“[[朝鲜半岛|朝鲜]]”，那还稍微好点。）--——自由雨日（留言・贡献） 2024年7月8日 (一) 07:10 (UTC)[回复]
您的想法很好，但是现在没有足够多的人力去处理这些，至于提醒读者的这个说法恕我不认可，还是那句话，除非有意链接，正常的条目内容是不应该拥有消歧义页面的，至于阁下建议的直接使用“[[朝鲜半岛]]”，我只能说阁下的建议很好，但是现在的技术做不到批量处理那么多页面，阁下前面提出的解决方案其实也是一样的，拥有相同的问题，那就是现在如此庞大的页面没有办法通过批量处理达到阁下所希望的解决方式。----FradonStar|八闽风云 2024年7月8日 (一) 10:22 (UTC)[回复]
正常的条目内容是不应该拥有黄链，但更不应该误导读者，我没有说“应该”保持黄链，我是说黄链相对于管道链接来说甚至不那么容易误导。将消歧义链接改为管道链接显然是捡了芝麻丢了西瓜，尤其是对大陆读者。--——自由雨日（留言・贡献） 2024年7月8日 (一) 10:44 (UTC)[回复]
如上所述，文献写成朝鲜而非朝鲜半岛，我不能赞成它们显然都是朝鲜地区。中韩建交后仍写作朝鲜，虽暂不排除沿用了旧资料。--YFdyh000（留言） 2024年7月8日 (一) 06:17 (UTC)[回复]
@YFdyh000：如上面我的回复，我们不是在试图统一所有链入朝鲜之页面的情况，我们应该讨论对只出现“朝鲜”内链的个例的共识，而对于这种明显的朝韩并立的页面就没有必要提出来做个例了，因为这类情况没有需要讨论解决的问题。----FradonStar|八闽风云 2024年7月8日 (一) 06:45 (UTC)[回复]
我觉得我没说“所有链入朝鲜之页面”，只是说“中国高等植物数据库全库记载”为依据的这一批个例。--YFdyh000（留言） 2024年7月9日 (二) 17:38 (UTC)[回复]
啊啊啊啊......今天才看到这个讨论......
我从7/1开始清理“朝鲜”的消歧义连结，已经把至少1000个条目（包含动物类和植物类）中的“朝鲜”连结至“朝鲜半岛”了，如果讨论结果是应该连至“朝鲜 (地区)”，恐怕得要找管理员或是机器人出来收拾善后...--CaryCheng（留言） 2024年7月9日 (二) 16:42 (UTC)[回复]
见此，您无论将“朝鲜”消歧义页链入“朝鲜半岛”还是“朝鲜 (地区)”，均会误导中国大陆等地的读者，因为他们只有少部分人会点击内链，若未点击，他们就会认为是DPRK而不是朝鲜半岛，就算他们点击，也会让他们觉得困惑。--——自由雨日（留言・贡献） 2024年7月9日 (二) 16:48 (UTC)[回复]
  • 连到哪一个都好，我没意见，大家达成共识就行。
  • 现在问题已经造成，这种问题我没遇过，有没有人知道怎么挽救呢?真找不到办法的话，我也就只能手动回退这1000笔编辑了。
--CaryCheng（留言） 2024年7月9日 (二) 17:02 (UTC)[回复]
短鲬、大泷六线鱼所对应的2006年《中国动物志》，同一作者的表述略有不同，朝鲜等地，朝鲜半岛、日本等地海域。此外还有“朝鲜，韩国和日本”2006.中国动物志.鸟纲，“朝鲜半岛和日本”2008. 中国动物志。不想轻率认定是编撰者未统一规范用词。--YFdyh000（留言） 2024年7月9日 (二) 18:10 (UTC)[回复]

满族姓名

本主题或以下段落文字，在讨论结束后应存档至Talk:满族人名、WikiProject talk:满族。

Coddlebean以“满人不称姓”大量删除了条目中满族人物的姓氏，搜索了一下不同人物情况应该不同。比如爱新觉罗·启骧，有大量直接用长名“爱新觉罗·启骧”，而不是简单只用其名，举例[25]、[26]、[27]、[28]、[29]，Google图片搜索能看到不少带“爱新觉罗”姓氏的。--Kethyga（留言） 2024年7月1日 (一) 12:38 (UTC)[回复]

@Coddlebean：“满人不称姓”不代表维基百科条目行文不能用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月1日 (一) 19:13 (UTC)[回复]
旗人传统上不称姓，但是事异时移，今时今日如果一个人就是以“爱新觉罗某某”行走江湖（注意，人物类条目名称采用的是其主要为人所知的名字，所以艺名优先于法律上的本名），那么当然条目里也应该称其为爱新觉罗某某。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年7月2日 (二) 00:49 (UTC)[回复]

中华人民共和国

本主题全部或部分段落文字，已移动至Talk:中华人民共和国。执行人：路西法人 2024年7月8日 (一) 01:43 (UTC)。[回复]

Lumo页面编辑历史及相关消歧义问题

本主题全部或部分段落文字，已移动至Talk:Lumo。执行人：路西法人 2024年7月8日 (一) 01:42 (UTC)。[回复]

基督教音乐

本主题全部或部分段落文字，已移动至Talk:基督教音乐。执行人：路西法人 2024年7月9日 (二) 02:42 (UTC)。[回复]

关于福建维基人用户框的图片选用问题

Template talk:User Fujian § 关于图片选用有用户正在征求社群意见，敬请编者关注。

截至目前该话题仅4位用户参与讨论，且尚未得到明确共识，故在此发出讨论通告。敬请诸位维基人，尤其是关心用户框和福建主题的维基人多多参与讨论。--射命丸 마음과 마음을 잇는 일은 언어를 뛰어넘는 일이다 2024年7月9日 (二) 15:24 (UTC)[回复]

其实争议的问题不是一个，而是两个：1.二级行政区划的用户框图标应当选用地图还是建筑地标/风景地标？（有官方旗帜或徽章的二级行政区划不在讨论范围内）。2.二级行政区划的用户框应当要统一颜色，还是说不统一颜色（台湾二级行政区划、香港二级行政区划、中国三级行政区划的用户框的现况）。--向史公哲曰（留言） 2024年7月10日 (三) 15:08 (UTC)[回复]
射君认为：福建人用户框模板的背景颜色和图案与其他中国大陆省级行政区的用户框模板样式不同，这是特殊性的彰显，十分不妥。（尽管在射君提出意见的时候，吉林和江苏的用户框格式也是与众不同的。）--向史公哲曰（留言） 2024年7月10日 (三) 15:12 (UTC)[回复]
不应该在那边讨论？这样会把讨论分散吧？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月12日 (五) 08:27 (UTC)[回复]
单纯陈述争议点也还好。--路西法人 2024年7月12日 (五) 10:13 (UTC)[回复]

条目内链相关问题

近日在提交DC22时，一篇化学物质的条目中包含了化学式的链接，但有主持人认为化学式的链接属于消歧义链接（C3H7ClO2），放在条目内不合适。在此咨询一下社群的看法。--Leiem（留言·签名·维基调查） 2024年7月10日 (三) 03:22 (UTC)[回复]

链接方便查阅者查找同分异构体，其实最好的办法是法语wiki那样，在chembox中自带内链--Htmlzycq（留言） 2024年7月10日 (三) 07:35 (UTC)[回复]
我觉得这事可以分两部分说。一，其实我不认为应当在正文里加入化学式，因为资讯框里已经有了，且知道了化学式对某一物质的认识帮助不大。除非加入化学式有助于理解，那就合适。二，如果要找异构体，让chembox自带内链或许是个不错的主意。但好像不影响页面归入Special:链接到消歧义页的页面。说回动员令，我觉得还是别放任何消歧义吧，免得开例外坏了规矩。可以等动员令结束再放。--微肿头龙（留言） 2024年7月10日 (三) 08:59 (UTC)[回复]
“除非加入化学式有助于理解”，这样的话应该可以放那些能表示结构的化学式，例如乙醇“C2H5OH”或“CH3CH2OH”、氯化钾（离子化合物）“KCl”等。--Leiem（留言·签名·维基调查） 2024年7月10日 (三) 09:14 (UTC)[回复]
我觉得这些可以，但如果要在比如说药物条目里放化学式，我觉得没有必要，读者来找药物条目想必不是来找化学式的。--微肿头龙（留言） 2024年7月10日 (三) 09:18 (UTC)[回复]
消歧义页不是条目，不提供百科资讯。他的作用是引导读者进入正确的条目，例如2-氯-1,3-丙二醇或3-氯-1,2-丙二醇之类，而不是告诉读者C3H7ClO2这个主题包括哪几种化学物质。所以对于条目中的消歧义链接，应该把链接修复到具体的项目（例如2-氯-1,3-丙二醇），给个模糊的链接让读者猜测文章到底在指哪种物质，这的确不合适。
传达C3H7ClO2有哪些同分异构体，这就属于告诉读者百科知识，那就成了条目该干的事情。这时就应该像英维那样，把en:C3H7ClO2定位成列表式条目（即同类索引类条目）。
当然，如果只是单纯列出某物质的化学式，那写纯文字C3H7ClO2就够，不需要加链接。--For Each element In group ... Next 2024年7月10日 (三) 09:36 (UTC)[回复]
是的，化学式条目都应该是Wikipedia:同类索引条目，这需要修改{{Isomerdab}}模板--Htmlzycq（留言） 2024年7月10日 (三) 12:44 (UTC)[回复]
（参见Category:化学同类索引）--Leiem（留言·签名·维基调查） 2024年7月10日 (三) 13:31 (UTC)[回复]
所以是要调整成同类索引吗？Category:化学消歧义要不要也并入Category:化学同类索引？--微肿头龙（留言） 2024年7月10日 (三) 13:46 (UTC)[回复]
看起来大部分是应该改组成同类索引，但微量元素应该是消歧义页没错。--For Each element In group ... Next 2024年7月10日 (三) 15:02 (UTC)[回复]
@Leiem、Htmlzycq、For Each element In group Next：我已将{{Isomerdab}}和{{Chemistry index}}改成同类索引，但还没移动Category:化学式消歧义。你们可以检查两个模板还有什么要改的地方。既然成了同类索引，Isomerdab和{{MolFormDisambigNav}}也应该要换名了。--微肿头龙（留言） 2024年7月12日 (五) 07:17 (UTC)[回复]
@微肿头龙：看上去没问题，最后就是分类（Category）还需要改一下。--Leiem（留言·签名·维基调查） 2024年7月12日 (五) 07:20 (UTC)[回复]
@Nucleus hydro elemon：顺便知会阁下。如果现在还想改回消歧义还来得及。等Category:化学式消歧义移动了要改回去就麻烦了。--微肿头龙（留言） 2024年7月12日 (五) 07:21 (UTC)[回复]
然后有一个“如果您是通过某条目的内部链接转到本页，希望您能协助更正该处的内部链接，将它直接指向正确的条目”，这个表述是针对消歧义的。--Leiem（留言·签名·维基调查） 2024年7月12日 (五) 07:21 (UTC)[回复]
我看到{{Set index article}}也有这一句？@Leiem：--微肿头龙（留言） 2024年7月12日 (五) 07:23 (UTC)[回复]
@微肿头龙：这个可能是从enwp那边直接翻译过来的，不过enwp的同类索引写的“incorrectly led you here”（错误链接至此）、消歧义写的“led you here”（链接至此），还有那边的WP:SIA提到了“red links to help editors create articles on notable entries”（红链可以让编者创建有价值的条目）。--Leiem（留言·签名·维基调查） 2024年7月12日 (五) 07:33 (UTC)[回复]
比如写成“除非您是有意链接至本页，否则应将相应条目的内部链接指向正确的条目。”--Leiem（留言·签名·维基调查） 2024年7月12日 (五) 07:35 (UTC)[回复]
已采纳阁下意见。--微肿头龙（留言） 2024年7月12日 (五) 07:38 (UTC)[回复]
把Isomerdab和MolFormDisambigNav改成MolFormIndex和MolFormIndexNav如何？还是前者要随英文全称Molecular formula index。原来的Isomerdab和MolFormDisambigNav需要留下重定向吗？--微肿头龙（留言） 2024年7月12日 (五) 07:32 (UTC)[回复]
看有没有使用吧，移动完成后没有使用可以直接删了。另外也可以改成MolFormNav之类的（短一点）（仅供参考）。--Leiem（留言·签名·维基调查） 2024年7月12日 (五) 07:36 (UTC)[回复]
突然想到Molecular formula是不是不包含像CuSO4这种的？还是要改成Chemical formula（也对应“化学式同类索引”）？--微肿头龙（留言） 2024年7月12日 (五) 07:41 (UTC)[回复]
@Leiem--微肿头龙（留言） 2024年7月12日 (五) 08:22 (UTC)[回复]
@微肿头龙：应该是吧，但是类似CuSO4没有同分异构体，可以直接重定向至条目。--Leiem（留言·签名·维基调查） 2024年7月12日 (五) 08:23 (UTC)[回复]
有少数有包含金属C55H70MgN4O6。但确实不多，还是用回MolForm吧。@Leiem：--微肿头龙（留言） 2024年7月12日 (五) 08:34 (UTC)[回复]
（题外话：包含金属的可以单独整理出“Category:化学式同类索引/含金属”之类的，这些同分异构体主要是在有机部分，比如正丁基锂和叔丁基锂、α-羟基丁酸钠和γ-羟基丁酸钠等）--Leiem（留言·签名·维基调查） 2024年7月12日 (五) 13:31 (UTC)[回复]
已添加分类，不过由于有机金属化学包括类金属，因此在下把硅等类金属也算进金属里。--氢氰酸留言区 2024年7月12日 (五) 15:46 (UTC)[回复]
谢谢，不过硅、硼之类的在中文里很少称作金属？（先这样吧）--Leiem（留言·签名·维基调查） 2024年7月12日 (五) 16:01 (UTC)[回复]
已修改，现在不算作金属的元素包括H、He、B~Ne、Si~Ar、As~Kr、Te~Xe、At、Rn。--氢氰酸留言区 2024年7月13日 (六) 04:45 (UTC)[回复]
支持缩短模版名。不过，目前MolFormDisambigNav的引用量高达2000+，不用机器人的话需要很久才能改完。--氢氰酸留言区 2024年7月12日 (五) 09:01 (UTC)[回复]
这个可以用AWB慢慢改（化学式条目还有一些其他东西我想一并改），但我有点担心会对Special:最近更改造成大量覆盖，干扰到其他巡查员工作。--微肿头龙（留言） 2024年7月12日 (五) 09:07 (UTC)[回复]

请求关注：Talk:地球大气层 § 建议更名：“地球大气层”→“大气层”

Talk:地球大气层 § 建议更名：“地球大气层”→“大气层”有用户正在征求社群意见，敬请编者关注。

简要说明：无法就“大气层”是否有专指地球大气层的定义达成共识，邀请社群参与讨论。

--路西法人 2024年7月11日 (四) 05:06 (UTC)[回复]

让我编辑

要把{{noteTA}} 删去 但被警告不能删--2407:4D00:5C00:762C:B475:3521:AE71:F4B8（留言） 2024年7月12日 (五) 21:27 (UTC)[回复]

见草稿:Re:scene。-千村狐兔（留言） 2024年7月13日 (六) 00:51 (UTC)[回复]
过滤器无误，不应移除字词转换模板，除非您确认它出现了问题；另外，03月26日应写为3月26日，不需要前导零。——暁月凛奈 (留言) 2024年7月13日 (六) 00:57 (UTC)[回复]

关于扎基拉姆

本主题全部或部分段落文字，已移动至Talk:扎基拉姆。执行人：路西法人 2024年7月15日 (一) 05:47 (UTC)。[回复]

其他

没有主题的页面如何评级

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

已解决：
因Wikipedia:通用评级已通过，故没有主题的页面已可透过通用评级来进行评级，故此问题已解决-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月5日 (二) 09:31 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

像是包、比 (消歧义)、值 (消歧义)这种，内容并不属于任何专题管辖的页面，要如何评级？有没有办法“无专题评级”？不然在统计工具上面，这些未评级的页面都无法正常显示页面种类。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 08:59 (UTC)[回复]

主题更多是用来评判重要度而非写作水准的吧，或许可以考虑一个通用评级，比如实际上并不应该被划到单一专题内的消歧义页。——暁月凛奈 (留言) 2023年12月7日 (四) 09:34 (UTC)[回复]
(？)疑问@暁月凛奈：比方说创建一个专用的、通用的评级模板，无专题，不使用{{WPBannerMeta}}元模板，内部只塞“本页面获评XX级”和Special:页面评级的解析器语法，然后没有别的说明？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 09:48 (UTC)[回复]
我基本没有参与评级相关，我不太明白为什么条目质量一定要和专题挂钩。举个例子的话，页面李的六个链接五个是姓氏，一个是植物，被划到生物还是人文都显然不合适，而且消歧义页本来也不算做条目。或许也可以设计成，“本页面尚未划分到具体专题，欢迎协助标记”，然后消歧义页等页面用参数取消这一句。——暁月凛奈 (留言) 2023年12月7日 (四) 11:51 (UTC)[回复]
{{WikiProject Article assessment}}可托管没有专题支援的条目--洛普利宁 2023年12月7日 (四) 11:58 (UTC)[回复]
(：)回应PJ:条目质量评级“这个维基专题已经废弃。”。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 12:18 (UTC)[回复]
几乎所有专题都是废弃的，只是这个专题明面上写了而已；稍微好一点的是只有一个人参加的“个人专题”，不过这种专题基本上也是三分钟热度。如果你只是为了评级，那就不用管专题是否活跃，直接把{{WikiProject Article assessment}}往讨论页上贴就可以。以中维的实力来说，条目没有专题评级才应该是正常的，有评级的反而属于异端--洛普利宁 2023年12月7日 (四) 12:41 (UTC)[回复]
模板、分类、甚至是档案也是需要评级的项目，算上去真的跟异端没两样。而挂上专题模板呈现的未评级状态能算评级吗。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:03 (UTC)[回复]
(：)回应：@Milkypine：WP:评级：“约有38万条目”，中文维基百科条目数也才100万啊。哪有“异端”？我还异端儿勒。另WP:评级#统计，所有挂有评级模板条目讨论页有562,943页，未填写评级的“未评级状态”之条目讨论页有182,858页，562,943 − 182,858 = 380,085。所以被评级的“条目”是38万无误，100万分之38万 = 38%。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 14:33 (UTC)[回复]
@A2569875：先定义何谓异端，如果数字多就不算异端，那么日本和中国市场可以除名异端状态了。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:54 (UTC)[回复]
更不用38%是数字少的一方，对中维其馀62%条目来讲，这38%就是异端。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:59 (UTC)[回复]
{{WikiProject Disambiguation}}，这个？--Kethyga（留言） 2023年12月7日 (四) 12:47 (UTC)[回复]
这个连专题主页都不存在 囧rz……-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 13:02 (UTC)[回复]
这个模板没有评级参数，而且doc页写明不要仅为放置该模板而新建讨论页。--Kcx36（留言） 2023年12月8日 (五) 03:38 (UTC)[回复]
仅供参考: enwiki之前也有相关讨论，现在已由{{WPBS}}自动为这类型非条目赋予NA-、Redirect-级别的评级与重要度。请参见w:wn:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24。中文或许如Category:非条目级条目?--Kanashimi（留言） 2024年1月10日 (三) 06:05 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

Random Thought: 跟进英维的WikiProject banner shell改版

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

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

我倒是想起一个事儿。英维最近改版了{{WikiProject banner shell}}模版（新样式在这里），新的模版可以单独给条目一个总体的品质评级，各个WikiProject可以直接继承这个quality assessment，也可以搞自己的评级。你看是不是能实现你的没有管辖之WikiProject依然可以有评级的愿望？ --MilkyDefer 2023年12月7日 (四) 14:59 (UTC)[回复]

@A2569875，附知。--MilkyDefer 2023年12月8日 (五) 09:03 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第一阶段：修改WikiProject banner shell

已修改：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
工程量挺大，就看谁愿意改了。（几年前可能我有兴趣，现在我就精神上支持了）--洛普利宁 2023年12月8日 (五) 14:53 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第二阶段：修改WPBannerMeta

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

@Willy1018：提到了一个很有意义的问题。如果上方的变更套用了的话，只有“表面上”给了页面通用评级，而实际上的通用评级在各个专题中并没有达成“继承评级”的效果。这是因为评级模板预设不会知道他外面包著{{WikiProject banner shell}}模板，因此，如果要让每个评级模板都能读到通用评级，需要再一个编辑请求。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月24日 (日) 05:15 (UTC)[回复]

预计的修改方案以及其布署连结（记得填写讨论通过的diff和客栈PermaLink版本号）。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月3日 (三) 05:00 (UTC)[回复]

本主题或以下段落文字移动自Template_talk:WPBannerMeta#编辑请求_2024-01-08（固定链接），新留言请置于框外。执行人：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月9日 (二) 13:21 (UTC)[回复]

相关议案

的配套修改-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 05:03 (UTC)[回复]

想谘询一下@Kanashimi君相关修改是否有问题？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月8日 (一) 05:53 (UTC)[回复]
@Ericliu1912、Kanashimi：这主要是依据共识，让专题横幅能继承{{PJBS}}输入的评级值。我已经在{{多面体专题}}、{{电子游戏专题}}测试过了，没有问题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 06:00 (UTC)[回复]
User:A2569875的努力有目共睹。只不过我原先料想的是直接改w:en:Module:WikiProject banner及w:en:Module:Banner shell，而宇帆-娜娜奇看起来很辛苦的重构了代码，并且有些参数不太一样，这样我就不太好评论了。--Kanashimi（留言） 2024年1月8日 (一) 06:12 (UTC)[回复]
@Kanashimi：考虑到日后长期维护需求，我倾向请您以英文版本为基础来更新相关模板。是否能够确认有什么模板需要更新（或在互助客栈列出之类）？不过在此过渡期间，若技术上没有问题，是可以斟酌先批准既有之编辑请求。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月8日 (一) 12:18 (UTC)[回复]
这两个（Template_talk:WPBannerMeta#编辑请求_2024-01-08、Template_talk:WPBannerMeta/core#编辑请求_2023-12-28）属于案《Random Thought: 跟进英维的WikiProject_banner_shell改版》可以先进行；剩下的属于另一案（Module_talk:Class/data#编辑请求_2023-12-28、Template_talk:Class_mask#编辑请求_2024-01-05、Template_talk:Class_mask/core#编辑请求_2023-12-25、Template_talk:Class/colour#编辑请求_2024-01-05）属于案《同步各模板/块的评级值》目前正在公示，所以暂时还不用。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 14:59 (UTC)[回复]
@Ericliu1912：要改哪些模板我在客栈上其实都有列，主要在案《没有主题的页面如何评级》和案《评级系统缺失问题》的子章节里。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 15:03 (UTC)[回复]
（不用一直提及我，我有在看）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月8日 (一) 15:11 (UTC)[回复]
@Ericliu1912、Kanashimi：另外参见此发言，User:Willy1018已复核效果符合预期，认为修改没有问题。测试也都充分了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 06:31 (UTC)[回复]
@Ericliu1912：另外如果要接受编辑请求的话，也把Template_talk:WPBannerMeta/core#编辑请求_2023-12-28也接受吧，两者是互相配套的（{{WPBannerMeta}}与{{WPBannerMeta/core}}高度相依）。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 06:33 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第三阶段：完善制度

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

在Template_talk:WPBannerMeta#编辑请求_2024-01-08中有人认为需要给通用评级订一个“能填写甚么级别”的标准来避免争议，因此立了草案Wikipedia:通用评级如下：

  1. 若一条目没有专题或不受任何专题管辖，则其通用评级可填写任意有被{{WikiProject banner shell}}支援的级别，仅要该条目有达到该级别的标准或满足该级别的条件，都可以评。
  2. 若一条目仅有一个专题，其通用评级应与该专题所评的等级一致。
  3. 若一条目有多个专题，通常由机器人自动依照规则4进行评级，但一旦出现争议时则通用评级应以所有专题都有开设的级别为主。
    • 例如：若一条目有四个专题，而有一个专题没有开设“丙级列表级”，那么通用评级就不得填写“丙级列表级”
  4. 对于有多个专题的条目，通用评级应填写最多专题评的那一等级。
    • 例如有一个条目有四个专题，其中三个专题都评为乙级，但有一个专题评为丙级，则通用评级应填写乙级。
  5. 若在规则4的情况抵触规则3，则应填写与对应级别最接近的且满足规则3的级别。
    • 例如有一个条目有四个专题，其中三个专题都评为“丙级列表级”，但有一个专题评为“列表级”且这个专题不开设“丙级列表级”。依据规则3，最多专题评的级别是“丙级列表级”，但有一个专题不开设“丙级列表级”，则通用评级应填写与“丙级列表级”最接近且位于该条目所有专题都有开设的级别，也就是“列表级”。
    • “最接近的级别”应该向下填写，例如未启用乙级的专题，通用级别遇到规则3判为乙级的情况时，则向下填写为丙级。如果丙级也有专题未开设，就再向下填写为初级。如遇到无法评级的情况，该通用评级模板就该留空。

提议将之升为指引，不晓得各位觉得如何？@Ma3r、Kanashimi、Z7504、桐生ここ：@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 09:44 (UTC)[回复]

实作上是否能让那些没开设大宗评级（数量最多专题）的在专题横幅内设定好参数即可？这样看起来就不会因为没开设评级、被覆盖而出问题。机器人很难判别每个专题开设的评级，因此条件3会让让机器人无法自动作业。
仅供参考，就enwiki来说，纯粹只考虑数量最多的评级。采用特殊评级的专题横幅有特殊分类，机器人处理时不会动到其评级。--Kanashimi（留言） 2024年1月14日 (日) 10:35 (UTC)[回复]
@Kanashimi：技术上不能读取评级模板的|QUALITY_SCALE=内容和/class子页面吗？如果|QUALITY_SCALE=填subpage，读取/class子页面就能得知该专题哪些评级有启用。例如{{多面体专题}}是|QUALITY_SCALE=subpage，所以读取Template:多面体专题/class原始码即可得到哪些级别是yes、哪些级别是no。如果|QUALITY_SCALE=填extended则是定义于{{Class mask/extended}}的级别。未填或standard就是只使用大宗评级。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 11:00 (UTC)[回复]
如果改成“若一条目有多个专题，通常由机器人自动依照规则4进行评级，但一旦出现争议时则通用评级应以所有专题都有开设的级别为主。”机器人会不会好办一点？意为机器人填写值优先，但如果是人工评级时，才须考虑是否所有专题都有开设，且是遇到争议之时，这是为了解决“但是如果有人说“根据Wikipedia:条目质量评级标准#非标准级别和一些专题评CL的惯例，这篇列表内容充分，尽管支援条目的专题都没有设CL级别，但既然WPBS能评CL那我就评CL”呢？所以，这个评级的定位该怎么看？您作出了如此复杂的功能，但如果因为使用规则不完善而部署而引发争议，相信这是您不愿意见到的。”所描述的争议情境。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 11:06 (UTC)[回复]
@A2569875 现在cewbot采用的方式是选出最大宗的评级（数量最多的评级），填入{{WPBS}}并且移除所有相同的评级。所有不同的评级都保留不动。不晓得这样的作业方式是否会产生问题？--Kanashimi（留言） 2024年1月14日 (日) 11:16 (UTC)[回复]
@Kanashimi：上面的情境说的是人为评级时可能出现的争议；如果是机器人评级，我相信应该没什么争议。所以应该不会有问题。该规则仅为了处理人为评级发生的争议，理应不影响机器人运作。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 11:20 (UTC)[回复]
既然如此那我作为机器人操作者没有什么意见。当{{WPBS}}已经指定class，机器人不会动到{{WPBS}}的class。--Kanashimi（留言） 2024年1月14日 (日) 11:28 (UTC)[回复]
我在疗养，您自己请便。由于这个事情的业务逻辑挺复杂的，我不会拦着你用什么样的Lua。--MilkyDefer 2024年1月14日 (日) 12:48 (UTC)[回复]

公示已逾七日，公示期已过，期内无合理异议，因此提案通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月29日 (一) 03:28 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

临时动议：关于基础条目的额外提议

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

已通过：
基础条目并入{{WPBS}}已经通过；{{WikiProject Biography}}参数还在讨论中。先行布署已通过的《将{{Vital article}}并入{{WPBS}}的|vital=参数》案。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
  • 似乎已有共识，跟随enwiki改版之后会由机器人自动完成：对各种专题横幅不再个别指定 class，而是统一置于{{WPBS}}。
  • 跟随enwiki改版之后会由机器人自动完成：将{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数皆改以{{WPBS}}处理，
  • 跟随enwiki改版之后会由机器人自动完成：将{{Vital article}}并入{{WPBS}}

这边最近在帮忙enwiki自动化这过程。这边将申请自动更新Wikipedia:基础条目所有子页面的图示（这部分最近测试中，已趋稳定。），以及定期维护{{WPBS}}（将各种专题横幅并入{{WPBS}}并维护 'class', 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'等相关参数）。不知大家对此是否有建议？ --Kanashimi（留言） 2024年1月2日 (二) 09:53 (UTC)[回复]

本主题或以下段落文字移动自Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版，暨将{{Vital_article}}并入{{WPBS}}（固定链接），新留言请置于框外。执行人：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月3日 (三) 05:20 (UTC)[回复]

引入enwiki近期{{WPBS}}之改版，暨将{{Vital article}}并入{{WPBS}}

enwiki近期改版{{WikiProject banner shell}}，

这边最近在帮忙enwiki自动化这过程，并且将定期维护。想请教大家对上几种改变的赞否。

另这边将申请自动更新Wikipedia:基础条目的图示（这部分最近测试中，已趋稳定。），以及维护{{WPBS}}（将各种专题横幅并入{{WPBS}}）。不知大家对此是否有建议？

副知User:Ma3r、User:Ericliu1912--Kanashimi（留言） 2024年1月2日 (二) 06:11 (UTC)[回复]

其实个人早已注意到相关更新，只是苦于自身技术实力不足而未能协助，乐见在充分确保相容性的情况下跟进。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月2日 (二) 06:21 (UTC)[回复]
(＋)支持全部。--Ma3r（铁塔） 2024年1月2日 (二) 06:25 (UTC)[回复]
是的，enwiki采w:en:Category:WikiProjects using a non-standard quality scale表示自订评级的专题，bot亦已考虑此问题，在User:Cewbot/log/20200122/configuration有此项。待zhwiki完成部署，填好User:Cewbot/log/20200122/configuration便可apply。--Kanashimi（留言） 2024年1月3日 (三) 07:08 (UTC)[回复]
  • 整理一下目前共识：
    • {{PJBS}}设立通用评级，可以统一管理同一条目的所有专题评级（已公示通过）
    • 确保最大相容性的前提下跟进英文维基的相关功能
    • 专题横幅看各专题意愿，评级可以选择统一放置于{{PJBS}}也可以自行输入
    • 未输入评级的专题横幅以继承载于{{PJBS}}的评级值为主，会优先采用载于{{PJBS}}的评级值
    • 如页面能自动判断评级则无论输入什么评级，都要以自动判断的评级为优先（原始来自这则留言，后续有在上方简单讨论）；另有设置参数能复写此设定。
    • 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'已并入{{PJBS}}，但是否废除{{WikiProject Biography}}内的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'还有待讨论
    • {{WPBS}}已经加入{{Vital article}}的所有参数，但是否要用{{WPBS}}取代{{Vital article}}还有待讨论
以上-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月9日 (二) 18:08 (UTC)[回复]

我有不同意见。英维的WPBannerMeta模组有很长一大坨代码都是在处理这个Vital Article的事情；具体来说，他们把校验这个Vital Article是不是真的Vital Article什么的逻辑全部写进去了。这一坨东西让可维护性和可读性（有可能还有效率）遭到了重大影响。我认为这更适合由一个外部机器人维护，而不是剥削这个已经很折磨人的Lua。 --MilkyDefer 2024年1月14日 (日) 12:53 (UTC)[回复]

我的建议方案是，|vital=参数可以存在，但是只有UI作用，由一个外部的机器人进行监察和更新操作。--MilkyDefer 2024年1月14日 (日) 12:55 (UTC)[回复]
若能简单改enwiki的程式码来用，或许不必担心折腾的问题。另一方面假如只留UI功能的话，是否干脆维持原来的{{Vital article}}就好?--Kanashimi（留言） 2024年1月14日 (日) 13:06 (UTC)[回复]
Module:Vital_articles都已经分成类似杂凑表查询了，有甚么折腾的问题？已经高效率优化了好吗。理论上，此实现的记忆体开销甚至有望低于英文维基，因为英文维基只分成27个表，而中文维基是36个表，代表中文维基每个表的项目数量更少，在类似散列函数计算之后，要读取的JSON更小，表示记忆体用量更少，单个表项目更少表示查询更快。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 13:12 (UTC)[回复]
基础条目模板合并案公示

见公示声明。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月24日 (三) 03:38 (UTC)[回复]
  • 还真的没有，那应该误会了。那这BOTTOM TEXT参数到底是从哪里来的？该废除的参数还是应该尽早废除。基本上只剩下一个(？)疑问：是不是还要写{{WPBS|class=xxx}}才能让其强制正常显示？--Z7504非常建议必要时多关注评选（留言） 2024年1月22日 (一) 06:05 (UTC)[回复]
  • 总之全部都是Module:PJBSClass/main的问题，不镶嵌模板就无法判断，但“条目内挂了模板所以可以判断”，您如果那么清楚的话，那就直接建模板阿。标准的自欺欺人，结果居然是没动脑过的回复，被泼冷水真的刚好而已。这样如何保证里面可以不用写上比如|class=xxx的参数，变成{{WPBS|collapsed=yes||class=xxx还能让它正常显示？--Z7504非常建议必要时多关注评选（留言） 2024年1月22日 (一) 23:21 (UTC)[回复]
    • 不需要保证，因为机器人会自动填写{{WPBS|collapsed=yes||class=xxx，保证的话等于和机器人抢工作，与本案背道而驰，因为该设计就是要给机器人维护的空间，如果没有正面回答此陈述将视为无效。没填写|class=显示不一样，反而还有能分辨机器人是否填过的功能，岂不是更好？ 另，(！)抗议没考量读者体验就乱讲的提案，评级是面向编者的资讯，(－)强烈反对把评级写在条目里，故我认为目前的方案已是最适合的方案； 另，在此警告，在此案讨论|class=参数已离题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月23日 (二) 01:24 (UTC)[回复]
@Z7504：我直接针对你最初的问题回答“是不是还要写{{WPBS|class=xxx}}才能让其强制正常显示？”，是，所以需要手动填上。本案并不包含甲乙丙初级自动判断，公示也不包含这个部分，若你希望有甲乙丙初级自动判断请另提他案，因为不在本案处理范围内。 此外，你也无须担心“是不是还要写{{WPBS|class=xxx}}才能让其强制正常显示？”问题，因为下方Kanashimi已经申请机器人了，您无需手动填写，此意见可以结案了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月23日 (二) 01:44 (UTC)[回复]
本公示不包含甲乙丙初级自动判断，若三日后还在要求甲乙丙初级自动判断将视为无效意见。若希望|class=没输入也能自动显示甲乙丙初级请另外提案谢谢，不在本案有办法处理的范围内。“这点小bug麻烦也先改了吧，不然都还要强制输入才能确保正常显示，问题不大才对”本案是处理基础条目自动化，而不包含class有没有输入的问题，因此不在此案处理范围内，请另提他案，谢谢。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月23日 (二) 02:02 (UTC)[回复]

已提出机器人作业申请，欢迎提供建议，谢谢。 --Kanashimi（留言） 2024年1月23日 (二) 01:38 (UTC)[回复]

公示期已到，期内无合理异议，且公示期内的意见之意见提出者已妥协，因此提案公示通过，将进行布署。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
{{WikiProject Biography}}参数案

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

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

公示到期，期内无合理异议，提案通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:40 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
是否废除{{WikiProject Biography}}原生的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数

无共识：
没有共识，择日再议，结以待续。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月19日 (五) 06:32 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

待机器人User:Cewbot/log/20200122/configuration清理完所有{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数再开始讨论。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:42 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
Category:缺少listas变量的传记专题页面改由{{WPBS}}加入

本主题或以下段落文字，在讨论结束后应存档至Category talk:缺少listas变量的传记专题页面。

搁置：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
Category:缺少listas变量的传记专题页面方案二
已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
{{Find page text}}引入成功。已为新方案建立Patch，Special:Diff/82875808，并且经过测试Special:Diff/82875855，测试为有效，能正确地实现本案《Category:缺少listas变量的传记专题页面改由{{WPBS}}加入》的预期效果。且由于其判定的方式，该参数得以保留，并且达到预期效果，因而解决了User:Shizhao所提出的问题。本声明放置一周，若无异议，将进行下一个阶段。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年6月1日 (六) 10:47 (UTC)[回复]
说实话根本看不懂相关提案，也不知道从何评价Orz —— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月3日 (一) 02:32 (UTC)[回复]
因为这案子基本已经尾声很久了，且最后一个项目也公示通过了，只是后来发生了点事情导致本案《Category:缺少listas变量的传记专题页面改由{{WPBS}}加入》需要“公示通过后再变更”。@Ericliu1912：简单来讲，本案就是要解决#临时动议：关于基础条目的额外提议，Kanashimi的User:Cewbot已经把{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数合并到{{WPBS}}处理，在机器人处理了几十万页面后，发现这样会造成{{WikiProject Biography}}和{{WPBS}}重复加上分类、或者是{{WikiProject Biography}}的有关参数已被机器人改到{{WPBS}}去了，{{WikiProject Biography}}变成没有参数而导致分类误加。为了解决此问题，于是诞生了议案《Category:缺少listas变量的传记专题页面改由{{WPBS}}加入》一案。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年6月7日 (五) 23:38 (UTC)[回复]
还是看不懂，但我觉得这种技术小众议题，又没什么大争议，公示个三天就够了吧？此案已经在客栈积压太久了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月8日 (六) 17:00 (UTC)[回复]
从此声明发出至今已约9天，期内没有明显异议，加上原案其实已公示通过，且自变更案开始讨论至今已超过一个月，视为有共识。不过公示方面还是谨慎点吧。三天真的太少。不过如上描述加上Ericliu1912的陈述，本案争议不大属实，就取3天和7天的中间数吧，公示5天。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年6月10日 (一) 00:41 (UTC)[回复]

编辑请求已由Shizhao完成，全案通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年6月26日 (三) 13:16 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
已结案：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
@A2569875：这整个话题是否还有任何需要讨论之事项？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 02:01 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

评级系统缺失问题

（原始标题为“将{{Classicon}}与{{Class/icon}}同步”配合公告栏调整标题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月5日 (五) 07:47 (UTC)）[回复]

配合上方#Random_Thought: 跟进英维的WikiProject_banner_shell改版因此需要解决评级系统缺失问题，故提出以下议案-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)[回复]

第一阶段：修正评级值不同步问题

议案1：将{{Classicon}}与{{Class/icon}}同步

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

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

我认为应将{{Classicon}}与{{Class/icon}}进行同步。{{Class/icon}}提供了比{{Classicon}}更多种级别的图示，如请求、未来、动态等评级的图示，{{Classicon}}都没有。而若{{Classicon}}与{{Class/icon}}合并的话，则等同于{{Classicon}}改成Module模式，需要社群共识，故发起讨论。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)[回复]

(＋)支持合并，后者（{{Class/icon}}）目前只有在154页上使用。-- Willy1018（留言） 2023年12月26日 (二) 01:33 (UTC)[回复]
(？)疑问：@Willy1018：那要不要{{Classicon}}重定向到{{Class/icon}}？刚才已补充{{Classicon}}所有功能到{{Class/icon}}了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月26日 (二) 02:33 (UTC)[回复]
可以，但前者{{Classicon}}被全保护，只有管理员才能进行编辑，需要提{{ep}}。-- Willy1018（留言） 2023年12月26日 (二) 04:56 (UTC)[回复]
似乎未来之类的评级并未被整个评级系统完全支持？--百無一用是書生 (☎) 2023年12月28日 (四) 02:24 (UTC)[回复]
(：)回应：@Shizhao：有支持，显示评级的最后一个调用是{{WPBannerMeta/qualityscale/mask}}，而{{WPBannerMeta/qualityscale/mask|future}}→“未来”，但在要送入{{#assessment:}}的{{Class_mask}}需要设|future=yes才有，不然会被滤掉。而要送入{{#assessment:}}的{{Class_mask}}直接写死无法设定参数，故建议将要送入{{#assessment:}}的mask改用{{WPBannerMeta/qualityscale/mask}}，这样才能正确支援。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月28日 (四) 02:50 (UTC)[回复]
支持合并。不过纯模板实现也不错。--桐生ここ★[讨论] 2023年12月28日 (四) 21:48 (UTC)[回复]
@桐生ここ：完全不建议模板实现。现时模板实现是使用{{#switch:}}，您忘了2020年初{{#switch:}}爆炸事件Special:PermaLink/58036835#A_technical_issue_with_articles_of_French_communes导致中维崩溃的事件了吗。{{#switch:}}的开销要高于模组实现，所以建议使用模组实现，安全又有效率。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月29日 (五) 00:06 (UTC)[回复]
这边最近在处理基础条目与{{WikiProject banner shell}}的图示问题（Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版，暨将{{Vital_article}}并入{{WPBS}}），(＆)建议直接采用{{Icon}}会更通用。--Kanashimi（留言） 2024年1月2日 (二) 09:18 (UTC)[回复]
但我觉得要有专题专用模板。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月2日 (二) 09:33 (UTC)[回复]
我想采用不同模板来处理同一件事的问题是较不易维护。--Kanashimi（留言） 2024年1月2日 (二) 09:49 (UTC)[回复]
@Kanashimi：问题是目前{{Icon}}并未完整涵盖Class/icon现有内容。改用{{Icon}}将会导致部分图是消失，或发生变化。我认为专题图示应该要统一的Style，但例如{{Icon|image}}文件和{{Class/icon|image}}文件级就不一致，而且{{Icon|image}}文件与以下图示比较{{Class/icon|image}}文件级、{{Class/icon|A}}甲级、{{Class/icon|B}}乙级、{{Class/icon|C}}丙级明显Style严重变调，故(－)反对。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月2日 (二) 10:13 (UTC)[回复]
或许我们可以扩展{{Icon}}使之涵盖我们想要的范畴，例如采用{{Icon|image_class}}？--Kanashimi（留言） 2024年1月2日 (二) 10:20 (UTC)[回复]
@Kanashimi：我这个议案只是想先动全保护模板{{Classicon}}，至少先同步图示，但您目前这样介入会导致共识乱了，连同不都做不到了，会导致花费更多“跑流程”时间，我想先同步，也做好patch了，都准备好了被你弄没了？我想先动全保护模板{{Classicon}}至少先同步图示；至于以后怎么维护可以再讨论。而且您的提议“例如采用{{Icon|image_class}}”也还没有patch，先现实一点吧，不要纸上谈兵，我只想赶快同步图示，并让Style一致，评级图示是评级图示，其他图示是其他图示；评级图示就该有评级图示自己的Style，(！)抗议乱七八糟的不一致Style图示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月2日 (二) 10:29 (UTC)[回复]
也好。那就等这个讨论结束再说吧。--Kanashimi（留言） 2024年1月2日 (二) 10:30 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

议案2：修正评级系统被不当过滤掉的评级值

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

“未来级”等级被正确识别（使用沙盒class mask避免被滤掉而实现的），见此[1]。

上方User:Shizhao提到“未来级”等评级级别无法被完整支持问题，是因为送入评级系统的评级值被不当过滤掉了，即使专题上层已启用该等评级，但最终还是会被“未继承上层参数的{{class mask}}”过滤掉，这样的话就算专题启用了该等评级也没有用，都被滤掉了，根本装饰，白启用了，因此提议将送入评级系统的评级值改为{{WPBannerMeta/qualityscale/mask}}模板，见编辑请求Template_talk:WPBannerMeta/core#编辑请求_2023-12-28，修改前后的比较Special:PermaLink/80307466，可以看到原有的版本评级值大部分都被滤掉了，建议换成提议的Patch，以让“未来级”等评级级别能真正被支持。同时，我也确认值接送未来级能正确被工具识别，见右图，连图示都有，代表评级系统是支援此输出的，能正确地被读取并识别。

因此提出本动议。不晓得各位有没有异议或意见。Ping参与过相关讨论的人@桐生ここ、Z7504、Shizhao、Willy1018：，上方参与过评级讨论的也Ping一下@暁月凛奈、Lopullinen、Milkypine、MilkyDefer：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月31日 (日) 08:29 (UTC)[回复]

支持。( π )题外话：台湾之星的标识现在还没改。--桐生ここ★[讨论] 2023年12月31日 (日) 10:36 (UTC)[回复]
资慈，我觉得行。 --窝法乙烷 儿法梦碎 2024年1月1日 (一) 14:38 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

议案3：同步各模板/块的评级值

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

目前有多个被全保护的评级模板/块的评级值（如有的有漏掉、有的图案、颜色不一致）并不同步，因此提议同步各评级模板/块的评级值。不晓得各位有没有异议或意见。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月31日 (日) 10:30 (UTC)[回复]

(～)补充相应的编辑请求Module_talk:Class/data#编辑请求_2023-12-28、Template_talk:Class_mask/core#编辑请求_2023-12-25和Template_talk:Class_mask#编辑请求_2024-01-05（和2023-12-25是配套的），颜色的部分：Template_talk:Class/colour#编辑请求_2024-01-05。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月31日 (日) 10:31 (UTC)[回复]
支持。--桐生ここ★[讨论] 2024年1月1日 (一) 09:03 (UTC)[回复]
就先改看看，让其他用户实际去测试这样才准，而不是每天一直喊支持。不然只是一直放沙盒而不去实际更改的话，完全不知道到底能不能测试。虽然维基百科终于有认知要将其功能“进步”，但也不应每日这样“无止尽的讨论而没有作为”才是。因此，这个讨论就不用再多说什么了。--Z7504非常建议必要时多关注评选（留言） 2024年1月1日 (一) 11:52 (UTC)[回复]
(：)回应：@Z7504：其实我有私下找User:AT了，但他一直说影响范围太大要先讨论 囧rz…………。我当然也希望能直接改啊，不然WP:7DAYS获共识再公示7天半个月就过去了……-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月1日 (一) 12:05 (UTC)[回复]
还想说中文维基百科不是长期以来都对专题这个东西爱理不理的，这不就是专题模板在用的相关评级吗？为什么不直接修改让其他人测试呢？建议AT直接帮忙修改吧。因为如果要叫维基百科废除已经存在多年的专题，显然是不可能的，更没有讨论是否要废除专题的必要。--Z7504非常建议必要时多关注评选（留言） 2024年1月1日 (一) 13:45 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

提案已通过请求布署

已布署：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
布署相关编辑，也就是编辑以下模板：
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月16日 (二) 13:23 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

评级缺失问题目前办理状况

截至2024年1月5日 (五) 17:08 (UTC)已提出三案讨论，三案皆在等待初步共识，以便公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]

评级缺失案办理状况
进度 讨论中 初步共识 公示中 部署中 已完成 后续维运
*通用评级设立 已获共识 已通过 已完成 已完成 进行中
*评级继承机制 初步共识 公示通过 已完成 进行中
评级值同步 初步共识 公示通过 已完成 进行中
修正过度过滤评级值 初步共识 公示通过 已完成 进行中
评级图示同步 初步共识 公示通过 已完成 进行中
完善评级系统规范 讨论中 等待中
注：标有“*”表示是其他相关提案。
以上为截至2024年2月2日 (五) 09:45 (UTC)的办理状况。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]
2024年2月2日 (五) 09:45 (UTC)更新-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月2日 (五) 09:45 (UTC)[回复]
2024年4月6日 (六) 08:29 (UTC)更新-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月6日 (六) 08:29 (UTC)[回复]

第二阶段：依据先前共识将不是条目命名空间的评级分类从“XX级条目”改为“XX级页面”

已通过：
公示通过。分类改名涉页面较多，会再进行公告；而Wikipedia:条目质量评级标准移动到Wikipedia:页面质量评级标准将会立即执行。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:18 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

根据先前共识，需要将不是条目命名空间的评级“XX级条目”的分类改为“XX级页面”，但因技术限制未能将“XX级条目”的分类改为“XX级页面”，因此本案已提出新的方案，依据页面命名空间添加分类，以实现该共识。具体执行方案在Template:WPBannerMeta/qualityscale/sandbox。同时将Wikipedia:条目质量评级标准移动到Wikipedia:页面质量评级标准，不知道各位有没有异议？-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月17日 (三) 04:57 (UTC)[回复]

没有异议，就是不知道会不会出现突发状况。 --窝法乙烷 儿法梦碎 2024年1月17日 (三) 11:35 (UTC)[回复]
已在多面体专题进行测试，详见Category:分类级多面体页面、Category:模板级多面体页面，目前测试整个多面体专题尚未出现问题。待本案正式通过之后才会正式(►)移动分类页面。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月17日 (三) 11:39 (UTC)[回复]
没有意见，但在专题页面（WikiProject）中使用到的{{Articles by Quality and Importance}}模板应一并解决显示异常之问题（前几天似乎还有这问题，现在不知道），虽然这模板平常根本没什么人在意 囧rz……（所以没解决可能也没差吧？因为专题本来就没什么人在意了）--Z7504非常建议必要时多关注评选（留言） 2024年1月18日 (四) 14:26 (UTC)[回复]
首先，结尾为“XX重要度”的分类不会移动，不在本计画内，而{{Articles by Quality and Importance}}是读取结尾为“XX级XX重要度”的分类，故基本上本案不会影响{{Articles by Quality and Importance}}。再来，如果这个真的要处理，要本案通过后，分类全部清理好，分类全数移动完成后才能处理，不然现在处理数字都会变成0。故应是下一个阶段要处理的（或者共识是暂不处理），不是此案此阶段讨论范围。此外，如果是{{Articles by Quality}}的话，直接更新分类名称即可。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月18日 (四) 16:02 (UTC)[回复]
已逾一周无新发言，根据WP:7DAYS七日无进一步发言视为已获初步共识，如本声明无人有异议，将准备进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月26日 (五) 00:32 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

分类改名准备

已完成：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

虽Special:Diff/80961277已公示通过，但因涉及的页面众多，因此宜再进行全站公告。公告完后将进行两个阶段完成：

  • 阶段1：全保护页面编辑请求：Template:WPBannerMeta/qualityscale和Template:Class
    由于该等分类都是以上被全保护的模板自动添加的，因此需要执行以上编辑请求。等编辑请求完成后，数万个页面缓存自动清理完毕后，分类将自动从“XX级条目”改归为“XX级页面”。
  • 阶段2：正式(►)移动分类页面（可能是约阶段1完成后再过一周）
    等缓存全部清完，再将“XX级条目”分类，逐个(►)移动到“XX级页面”分类。
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:30 (UTC)[回复]

公告一周。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:31 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第三阶段：Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引

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

本案最初的初衷就是完成此共识Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引，来完成WP:QUALITY_升为指引一事，来正式解决“评级系统缺失问题”（指引/规范未立也算是本系统的一种“缺失”）。等上方都完成，此处将继续。声明：当这些“缺失”都解决后，本人将不再碰评级系统这块了，这烫手山竽真是消磨人的精神。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 04:40 (UTC)[回复]

可能我上面没说清楚，让你以为我是反对分类改名的，更不是什么越给我搞复杂，好啊WP:QUALITY永远升不了指引都你害的，不能有问题不让说是不是。总之是以下几点：
  1. 页面重新命名为Wikipedia:条目质量评级标准：因为评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别（WP:QUALITY就是这么写的），那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。除非你打算搞什么甲级模板级，那不是更复杂。此外还存在Wikipedia:条目重要度评级标准，那是否要改成Wikipedia:页面重要度评级标准，总之得有一个要改
  2. 目前Wikipedia:条目重要度评级标准和Wikipedia:页面质量评级标准是正交的，所以有Category:分类级低重要度宗教条目这种东西的存在，那是不是得命名成Category:分类级低重要度宗教页面。既然分类级不属于标准评级，因此也不必设置重要度，引入更多复杂性，这类页面统统扔去Category:不适用重要度条目去（或者说Category:不适用重要度页面）。
  3. {{Grading scheme}}修改，因为Wikipedia:页面质量评级标准调用了，这个就是作为WP:指引用词统一的问题
--Kunjinkao（留言） 2024年3月8日 (五) 05:20 (UTC)[回复]
  1. 无论是前次讨论还是本次讨论，都没有提到重要度，因此认为重要度的那个论述怎么样，并不碍于WP:QUALITY升为指引一事。
  2. 此修改技术成本过大，且认为这样修改与否并不碍于WP:QUALITY升为指引一事。由于目前架构问题，该修改技术上的复杂性，不建议做此修改。除非有人能提出具体的patch ，否则我不支持也不相信此修改能够被实际执行。（当然，如果有人做patch 就另当别论）-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回复]
  3. 如果没有人有异议，你可以自行修改。
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回复]
关于第一点，重要度只是顺带提及，核心是评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别，那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。--Kunjinkao（留言） 2024年3月8日 (五) 06:26 (UTC)[回复]
Wikipedia_talk:页面质量评级标准#c-Cdip150-2016-03-14T04:31:00.000Z-Liaon98-2016-03-14T02:44:00.000Z。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 06:47 (UTC)[回复]

第二阶段正式完成后的第三阶段讨论

已完成当时的共识Wikipedia_talk:页面质量评级标准#总结“将不是条目命名空间的评级分类从XX级条目改为XX级页面”，因此将安排Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引重新公示。重Ping当时参与讨论的人：@Liaon98、JyunWaan、Lssrn：@Cdip150、Temp3600、Peacearth：。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月19日 (二) 10:49 (UTC)[回复]
  • 当时的讨论是专题各自评级，而现在的情况是多了通用评级（WPBS）。所以时过境迁，WP:QUALITY要重新讨论了。我之前没有参与讨论，现在有不少想法：
  1. WPBS评级是专题评级的容器，还是一套有自己标准的独立评级？现行做法属于前者：WPBS评级继承专题的评级，且受各专题各方面的干涉，因此评级原则看似“随意”。

    一篇列表WPBS获评List级而非CL级，是因为它确实没到CL级。另一篇列表获评List级而非CL级，只是因为某个参评专题不设CL级。第三篇列表和第二篇品质相似却成功获评CL级，原因竟是不设CL级的专题没有“染指”该列表。

    所以我的看法是，通用评级就该如WPBS模板所言，确实地“依照页面品质评定标准”来独立评定，而不是在各专题评级间谋求公约数。可以参考专题评级，但把专题评级当爸爸就不对了😂
  2. 承上，如果我们确定WP:ASSESS本位而非专题评级本位，那就要讨论条目的WPBS该设立哪些级别？英维的PIQA是只支持FA、A、GA、B、C、Start、Stub、FL、List、Unassessed几个经典的“标准级别”。而我们的WPBS是大杂烩：既包括BL、CL这种品质向评级，也包括Future这种非品质向评级。所以WPBS评级所支持的“标准等级”该设哪些？
    • BL、CL等品质向等级有两条出路。一是如同英维，只收录广为人知的传统评级，不收录BL、CL这种额外等级；个别专题想启用就在自己的横幅上评。二是将BL、CL升格为通用评级，全体专题横幅亦自动启用BL和CL；如果个别专题自己讨论后坚持不用BL，那可以用掩码把BL改成List或B。
    • 对于Future级，一篇未来级条目可以很烂（Stub），也可以比较充实（C），那Future这个等级就没有实现“评价页面质量”的作用。我能想到的用途是在话题中，用未来级作为宽限条目的标记，暂时不影响认定。但这个等级的确不够“通用”，或者说和条目所用的品质评级不是一个维度。
    • 对于A级条目。英维的A级在军事史专题存活（且活得很好），但其他专题都是死的。因此英维多次讨论A级的出路，比如从PIQA里开除把A级之类。但你维是真的所有专题都不评A级；所以，把这个只有理论价值的等级从通用评级中灭了挺好。
    • 上面的想法也会影响小工具的设定：包括对标准评级的契合，对各专题自定等级的支援，对非条目评级的简化（非条目空间一般人手评级无效）。
  3. 下文有提到“消歧义级条目/页面”。如果按照命名空间来理解，那就有一个问题：重定向在各个空间都有，那到底是叫“重定向级条目”还是“重定向级页面”？（或者两个都要，但这徒增烦恼）另一方面从实用性上看，专题统计“条目数”都是排除Disambig级的，那消歧义占据条目空间就成了bug而非feature。这次从“条目”移到“页面”更像是正名，但是后缀分家无论是技术实现上还是命名统一性上，带来的麻烦都不少。考虑将后缀统一为“页”，比如品质评级这边的“乙级条目页”“丙级列表页”“模板页”，重要度那边也可以叫“高重要度页”“未知重要度页”，这样观后缀就知道是页面评级体系在整活。
我明白很多内容都不在讨论范围内，但我认为之前讨论本身就是系统性不足。比如把非条目品质评级改为“XX级页面”，那为何条目品质评级和非条目重要度分类不动？是改条目和重要度分类真的弊大于利，还是单纯没有讨论过而已？作为这套系统创始者，英文版的非条目还用articles的，个中原因是否值得参考？--For Each element In group Next（留言） 2024年3月19日 (二) 16:05 (UTC)[回复]
争议已消失：
上述争议因进一步讨论已展开，因此可以视为争议已消失-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年6月1日 (六) 10:55 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
@For Each element In group Next：老实说我真的不懂你们这些这时候再来提意见是用什么心态再看事情的，这个提案已经放超过三个月了，又不是放一个星期就说要公示，硬是等提案要准备收尾才来提意见是怎么回事？！我可以当成你是打算扰乱干扰提案通过吗？！--SunAfterRain 2024年3月19日 (二) 16:40 (UTC)[回复]
我几年前的主业之一就是评级理论。Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引6年前甚至6个月前，我都会像推动MOS:FICT那样，亲自提出修改意见和方案（如WP:QUALITY第二段不符合新形式），让WP:QUALITY成为更优质的指引。但现在评级方面，我认为和这个装睡的社群去合作没有什么意义。所以我的做法就是不发言，看着这个社群未来到底走向哪里。出于对当初理想的怀念，我写下了这些明者自明的意见，但也仅此而已了。通过提案无非就是页面多个“指引”的标签；您看我用户页，就该知道我对这种“社群众评标签”有没有兴趣了。--For Each element In group Next（留言） 2024年3月20日 (三) 16:36 (UTC)[回复]
@For Each element In group Next：我不管你到底对这个议题有没有兴趣，反正你现在的意思是上方内容纯粹是发牢骚你没有要干扰这个提案？！--SunAfterRain 2024年3月20日 (三) 17:12 (UTC)[回复]
还没有细看，但我对洛普利宁君遭到这样的对待感到很悲哀。--Temp3600（留言） 2024年3月20日 (三) 17:43 (UTC)[回复]
在有用的讨论串下面离题吵架实在无奈，但似乎VP环境已经如此。
WP:CON明确指出"共识应采纳多数人的意见，并和重要少数的意见作出适当妥协。"、"共识在维基百科是持续不断的过程"，对于方针修改，更再次明示"共识最终将根据支持和反对该议题的论点质量所决定"。方针中没有任何字眼要求讨论应"收尾"，反而暗示了讨论本身是可以无限延长，以不断修改共识更贴合实况的。所谓扰乱更是莫名其妙。
回到讨论本身，如果有足以反驳洛普利宁君的理据，直接提出来就可以。如果反驳不了，甚至根本没有考虑到这一讨论角度，那显然就说明"之前讨论本身就是系统性不足"，提案一方存有思考盲点，应该进一步讨论下去。
回到这个提案。我与八年前一样，支持将WP:ASSESS建立为指引。然而，洛普利宁的问题必须先得到回答:维基百科:通用评级与维基百科:页面质量评级标准之间有潜在矛盾。通用评级到底是独立的评级系统，还是专题评级的平均分?我对这两者没有特别的见解，但WP:ASSESS应该清楚指明这一上下级关系。
如果不幸某页面只有一个专题，而这个专题将页面评为"未来级"等奇怪级别，通用评级是否跟随?
请赐教。--Temp3600（留言） 2024年3月21日 (四) 19:45 (UTC)[回复]
@Temp3600：那我倒觉得您来主持好了，包含修改模板模组的部分，反正您看起来很闲可以泡在客栈陪大家一直耗。--SunAfterRain 2024年3月22日 (五) 01:35 (UTC)[回复]
  • 折腾了三个月，我已经没有修改评级模组的心力了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月22日 (五) 01:52 (UTC)[回复]
  • Special:PermaLink/81985508#第三阶段：完善制度这里有说，一切以维基百科:页面质量评级标准为主，当专题评完后，维基百科:通用评级再取各专题WP:ASSESS的公约数，不认为有矛盾。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月22日 (五) 02:00 (UTC)[回复]
    • @A2569875：如果方针是FA级，指引是GA级，那现行WP:QUALITY+维基百科:通用评级大概只有C的水平，还需要很多工作完善：
      • WP:QUALITY说“评级主要由专题进行……”。那WPBS评级人是作为什么身份评的？社群成员，还是专题成员？现在WPBS开展一段时间了，相信大部分人的评级逻辑是直接对WPBS评级（而不是专门针对各个专题）。这就和“评级主要由专题进行……”矛盾。
      • 有了WPBS后，就有了“社群心目中的评级”，这个评级就是WPBS的评级。这样，大部分专题出于信任社群/懒得评级，而继承了通用评级。对于旧页面，现在的做法很好——假定WPBS评级为各专题评级的公约数。不过这个做法并非必然，我们也可以取各专题的最高值/最低值，只要社群愿意信赖专题。例如英维只有WP:MILHIST真正地在评A，而其他专题是评GA或者B，此时一个做法是取A，而非众数或向下取GA/B。
      • 但是下面的问题理论上和执行上都很成问题。例如维基百科:通用评级第5点要求“例如未启用乙级的专题，通用级别遇到规则3判为乙级的情况时，则向下填写为丙级……”。
        • 首先，很难判定专题是否启用某个级别。机器人运行者好像都说过做不到这个事情，就更不用说人工评级了。
        • 其次，如果B级是标准评级，且多数专题都评B级，那这个条目在社群心目中就是B级。我们不应该迁就特例独行的专题，否则公认的B级条目评C，那B和C还有什么可比性？应该是说，不设B级的专题应该自己收拾自己的摊子，例如专题评级继承B而表示为unassessed，或者用掩码改成C。
        • 第三，现在的BL是标准评级吗？如果不是标准评级，那应该呈现在社群通用的WPBS上吗？如果呈现在WPBS上，多数编者没见过BL，他们看得懂吗？如果你认为大家能看懂，且乐见对列表细致评级，那不如将BL升格为标准评级？如果升格为标准评级，就应该预设对所有专题的class mask启用BL，否则又回到上一点专题“特立独行”的老路。
      • 只有一个专题评Future，那WPBS技术上当然可以评Future（且只能评Future）。但上面BL甚至D级都是品质导向级别，那Future和他们并列（而不是attention之类的flag）是什么用意？还有，如果两个专题一个是CL，另一个是Future，而且两者都未设对方的级别，那WPBS到底听谁的？
      • 上述问题可以不断打补丁解决（维基百科:通用评级就是打补丁的成果），但这并非良方。大道至简，最实际的方法是：编者以社群成员的身份，以WP:QUALITY的标准评级中的选项为依据，针对WPBS评级。专题评级理论上和WPBS独立，但实践上的评级方式是信任社群评级。然后，我们讨论WPBS具体该支援哪些级别——对于条目，我建议支援传统级别，或传统级别+BL/CL/(SL?)；而Future、Merge不属于品质评估，而A级又极不活跃常常被人误解，这两类可以考虑从通用级别中除去。至于要修改的地方，无非就是修订WP:QUALITY、WPBS支援代码、class/mask预设启用代码，就像您说的，要改很简单。
      • 您可能看不懂我的留言，也可能看懂了但没有观点。建议您和有实际开设特殊级别的专题联络，看看他们的意见。我可以写出蓝本，但我不想干涉这件事情，也不想在这个物是人非的地方留言。
    • @SunAfterRain：我可以当成你是打算扰乱干扰提案通过吗？！。当然可以！您怎么想是您的权利。--For Each element In group Next（留言） 2024年3月22日 (五) 16:26 (UTC)[回复]
      你以为你维的评级模组是Module:Namespace/data这种随手改一改就好的是吧，改一次的成本有多高您可以自己改看看，不是什么看起来很简单改一改就好--SunAfterRain 2024年3月23日 (六) 03:13 (UTC)[回复]
      我2015年到2016年大幅更改过WPBM相关子模组，比如引入bchecklist。而且如果WPBM不能满足我的需要，我也有能力手写模板。我固然不是A2569875那样的技术专家，但我也知道那些内容属于微调，哪些内容属于重炼。（那时候您似乎还没注册，如果您问一下八九年前一些关注评级的老用户，您大概会知道我都干过什么）
      上面的问题我早在两个月前就A2569875君交流过。当时他表示现在只讨论技术问题，具体制度问题可以后议。我的意见不是技术问题——等真正的技术修改部署后，对WPBS屏蔽某些等级就OK——所以的确可以后议。A2569875当时态度很激烈，我不想影响他的心情，而且他应该是没有看懂我的意见，所以我就没有继续争论下去。另一方面如果我做主导人，和议案有关的问题无论在发哪里讨论，我都会接受；而A2569875的思路就是a讨论页不谈b问题（我不知道这是不是今日你维的讨论规矩）。我们俩电波对不上，我也不想在客栈留言，所以就直接走了。现在的论题正是“第三阶段（WP:QUALITY_升为指引）讨论”，既然是讨论（而不是走形式直接通过）那我充分陈述我对WP:QUALITY的看法很合理吧？而且讨论3月19日开始，我也没有拖到26日要结案的时候发。
      就我看来，应该一开始就讨论WP:QUALITY评级这个哲学问题，讨论好方向之后再开始技术修改。而且有了修改体系背书，A2569875的技术修改也能一路绿灯，不用喊“折腾了三个月，我已经没有修改评级模组的心力了”。不过中维人少，评级哲学上确实没几个人能想到这么深；就像技术方面没A2569875，其他人也推不了这个提案。最后我认为本站应该以理服人，而不是靠方针指引或没讨论深度的“共识”堵嘴：能指出问题的内容标上指引也是根基不牢，有道理的论述没有标签也应该令人尊敬。--For Each element In group Next（留言） 2024年3月23日 (六) 05:29 (UTC)[回复]
      别为你不参与讨论找借口，电波对不上不代表就可以事后再来批判，你说以理服人光是你用这个理由我就觉得你服不了人了
      另外你觉得你的意见不是技术问题但事实就是改动不小的技术问题，光是要改动一个分类就要牵涉到多少模板模组了--SunAfterRain 2024年3月23日 (六) 05:49 (UTC)[回复]
      您的考虑方向我很赞同。不过如果例子举成“改动一个模板就会牵涉多少分类的移动”，那会更有说服力 --For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回复]
      你到底在举什么...--SunAfterRain 2024年3月23日 (六) 07:28 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
  • 首先感谢宇凡君的努力，您辛苦了。顺便说一点离题得罪人的话：
  • 目前的问题如要解决，通用评级指引势必重写。问题只是要怎样重写而已。说白了，洛普利宁是反对通用评级的“由下而上”逻辑，再深挖下去，涉及专题组与社群整体之间的互动问题，对应现实生活中的中央－地方政府间，集权－分权的冲突。这样展开就显然太复杂了，我只是希望指出为什么洛普利宁会认为这个指引写得不好。
    回到维基。尽管从宪法的观点出发，确立各子组织间的权力分立应是建立规则的第一步，但考虑到中文维基并不怎么关注这一问题，我就建议维持现状好了，省得麻烦。反正即使是下而上，要修改专题评级，直接一起修改所有专题的评级就可以（显然这就一次侵犯了数个专题的自主权，但上面说了，中维人这方面的理解力有限）。下而上的（理论上）优势当然是“各专题组可以按各自所擅长的领域，共同对跨领域的条目进行评级，会比WPBS只用一个评级员来得准确”。实际上嘛，就是懒得改。
    “WPBS评级人是作为什么身份评的”：从下而上的观点而言，没有专题组的条目评级，算是社群托管了该条目，留待专题组前来接收，等价于联合国托管理事会。最终还是需要专题组的专家前来正式评级。
    "标准评级":基于减少修改范围（懒）的因素，建议只容许使用“标准级别”来评级。也就是说，暂时放弃将BL／CL加入WPBS，待更多专题启用这些评级，更为人所熟悉后，再来讨论。future等评级则不容许更新到WPBS上去，机械人应视这些条目为“没有评级”，由人类前来处理。
    最后，感谢@For Each element In group Next：前来，指出这些要点供大家讨论。说实话我本来也不想发言的，打了这些东西花了我一个多小时。也希望你能与我一起坚持到这项修改完结。
    以上。--Temp3600（留言） 2024年3月23日 (六) 03:33 (UTC)[回复]
    如果硬要扯开这个话题，我反倒支持废掉所有专辑的质量评级全部统一处理，因为你维专题参与人数实在少到除了几个大专题之外没有办法给出一个真的符合自己专题的评级标准，而且去查大专题的评级标准实际上也与通用标准没有差异，那这样给各专题评质量有什么意义？--SunAfterRain 2024年3月23日 (六) 05:54 (UTC)[回复]
    （以上没有要废掉重要度评级）--SunAfterRain 2024年3月23日 (六) 05:56 (UTC)[回复]
    如果完全废除专题评级，将权力上移给WPBS，那就算不谈这种集权行为是否影响了专题组的自治，也需要将目前已经由专题组评级的条目改为WPBS格式，并处理评级不一致的问题。我是不太看好能搞定啦。--Temp3600（留言） 2024年3月23日 (六) 07:10 (UTC)[回复]
    @Temp3600：感谢您的解释！虽然讨论很不愉快，但至少讨论者都能理解我要引出的思考点了。现在我的任务大功告成了--For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回复]
    喂喂，不准跑掉（ --Temp3600（留言） 2024年3月23日 (六) 07:14 (UTC)[回复]
    所以你知道为甚么我说他明显有意扰乱了吧（摊手--SunAfterRain 2024年3月23日 (六) 07:26 (UTC)[回复]

随意的分段

  • 另外回应SAR的是，技术人员与行政官僚本身就是两项不同的工作，互相批评在我看来并无意义。nerd的下场，可以参考为什么苹果公司会赶走乔布斯。--Temp3600（留言） 2024年3月23日 (六) 03:37 (UTC)[回复]
    • (：)回应：@Temp3600：最初的提案是Wikipedia:互助客栈/其他#没有主题的页面如何评级。起因是我遇到有条目不属于任何专题，所以如果要评级，会有困难。（所以，我的动机很简单，我本来就只是在写条目，遇到了一个问题，我来客栈讨论解方，结果折腾了三个月，途中不乏某些维基人精神攻击，提案看起来快搁浅，精力消磨没了，写条目的动力也没了。在本案开始之前，我一个月写十几个条目，本案开始之后，三个月我只写了两个条目。）。关于该问题由MilkyDefer给出的解决方案是修改{{WPBS}}，于是开始讨论共识并执行，以及其配套的《评级系统缺失案》甚至还因技术需要跑了几趟phab(如phab:T360012)。因为最原始的目的《没有主题的页面如何评级》，代表其讨论页会放置空{{WPBS}}，也就是没有任何专题的{{WPBS}}，所以当然要能支援填写所有评级级别，包括但不限于非标准级别（为此，我还特地翻过所有专题、所有维基百科上出现过的评级级别，统整出所有专题定义的所有级别，大概40几个）。而当{{WPBS}}如果开始填入复数个专题，{{WPBS}}如果又要限制能填写的级别，程式逻辑势必变得复杂，所以我的解决方案是不改程式（你知道的，改全保护的程式不是那么简单），改立WP:通用评级指引制约，如可能也把评级系统的不同步级缺失补齐，其实目的也就只是《没有主题的页面如何评级》而已。而只是恰好Kanashimi要跑评级机器人，所以我索性再修改一下程式，跑客栈共识+公示流程，虽中间与Z7504发生争议（其实消耗了我非常多精神）但最后都通过了，而“去match Kanashimi机器人”这部分其实已经超出我原本想编写的程式内容了。后续所有技术案都通过了（过程中洛普利宁在客栈中不发一语）所以程式码当然不会包含他所期望的部分啊。维基百科是志工性质，不强迫任何人参与，既然我已经写好我想写的程式，那我为何还要在最后“可能”可以收尾的时候，帮“洛普利宁的理想”写程式？程式技术不难，但全保护和繁杂的评级系统，加上客栈不时出现精神攻击，说实在我的精力已经耗尽。我提供的任何一段程式码都没有拿到任何薪水，纯粹就是最初我想做、我想解决某些问题，但像现在这样节外生枝是否生得太夸张了？-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月23日 (六) 04:13 (UTC)[回复]
    我想，在洛普利宁的心中，他在最初就已经您解决了你的问题：维基百科有一个万能专题{{WikiProject Article assessment}}，你只要将没有专题的条目通通添加到这个专题下就可以，问题立刻解决，不需要碰WPBS。我也认为这是最简单的方法。只需要跑一次机械人，把所有没有专题的条目全部加入WikiProject Article assessment，就可以了。
    顺便一说，我自己也试过帮助条目找专题，但即便有新rater的协助，仍然很难。最大的问题是，我不知道有那些专题存在，又不知道他们的简写。如果宇凡你能改良rater，让程式可以搜寻，甚至推介专题给我来选择，会很有帮助。比如有一个英国足球队条目，但还没有专题，但分类已经写了这是英国条目，rater能不能够提示我加入英国专题（或者别的甚么专题？）。
    如果不行，可以考虑一个简单一点的修改方案：当条目没有专题时，rater预设添加WikiProject Article assessment，就可以照常评级了。
    但现在WPBS已经生出来了，总不能走回头路。但这个也不容易，一会儿再写。--Temp3600（留言） 2024年3月23日 (六) 04:47 (UTC)[回复]
    @Temp3600：这完全不是什么两种不同工作的问题，有意见之前重写模组时一起纳入考量重写就好，那时候提出我想娜娜奇也会尽可能配合的，但洛普利宁同学是喔我支持改写，人家写完都开始运行了再来抱怨。不要跟我说什么滚动式修正，他提出的意见很显然不是因为模组上线才出现的。--SunAfterRain 2024年3月23日 (六) 05:38 (UTC)[回复]
    然后回到“Template_talk:WPBannerMeta#编辑请求_2024-01-08”。洛普利宁的批评是对的：宇帆在这次重构中，只考虑了技术层面上如何实行WPBS的改版，忽略了行政上的架构问题：所谓通用评级，由于每个条目只能有一个，客观上就有压倒原来专题评级的意味。于是这就进一步产生了通用评级与专题评级的冲突，新建立的WPBS机关在权责上如何与原来的专题委员会划分的问题。现在那些WPBS有没有CL级，未来级的问题，本质上都是没有完成项目定义就急于进入开发阶段，结果现在开发成果不完全符合要求，但是要再更改，工作量又很大，于是卡住了。
    所以现在还是要回到那个编辑请求，解决掉1月时的问题。然后由于技术负债，问题要尽量靠行政程序解决。这就是目前的工作。
    宇凡那时的观点，也不能说错，毕竟维基百科也没有技术可以阻止你发侵权垃圾内容对不对，但是我们有行政手段，有制度可以将侵权内容透过删除页面功能处理掉。我估计这边最后也会采用相同的方向，WPBS模版支持很多参数，但在指引中，会指明只有部分参数才可以合法使用，如果用了其他值，即使能够正常显示评级，其他人也可以回退，警告这一套。--Temp3600（留言） 2024年3月23日 (六) 08:43 (UTC)[回复]
    • @Temp3600：问题就出在于，最早MilkyDefer的起草就有未来级、CL级等等，然后我还Ping了洛普利宁问他这样可不可以，但他完全没有任何答复，到头来还是只有一句“精神上支持”，我怎么知道问题在哪，直到一月开发完成才开始说这里不对、那里不对，这样我是要怎么搞。反而User:Willy1018事先指出了具体问题，我得以依照他的问题在开发阶段先行解决，并让User:Willy1018说出了“感谢贡献，目前已复核已符合预期。”。完成后才再修改成本比较高，一开始又不讲清楚，说完“精神上支持”然后跑掉，然后现在争议后要叫我扛责任。我这样消磨掉的精神状况可能需要去放维基假期了-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月23日 (六) 09:00 (UTC)[回复]
      A2569875：首先向您道歉，我没有及时回复您的提醒，在1月份的讨论中，我也没有坚持将意见表达清楚，因为我认为您将来会用掩蔽代码的方式处理WPBS评级。我也知道了为何SunAfterRain君会将我提报到破坏区。其次感谢您完成了迄今所有的技术工作。我的意见是针对政策层面，亦即评级体系如何开展。我不参与客栈讨论，亦不会干涉指引讨论的工作；因为很多等级都是我带起来的，我这次只提出我的想法，希望让社群自行讨论如何评级等级。如果讨论结果是敲定启用或不启用某些等级而需要修改模组，而您疲于修改模组，我可以参与技术工作吗？最后就像Temp3600君所言，在下确实有责任。--For Each element In group Next（留言） 2024年3月23日 (六) 09:40 (UTC)[回复]
    (＋)支持User:Temp3600提的：不当使用WPBS参数时，其他人也可以回退，警告这一套。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月23日 (六) 09:11 (UTC)[回复]
  • 如果能够masking掉WPBS旳等级，待日后成熟等再开启，那自然是最好；不行的话，单改指引也算是解决了问题。--Temp3600（留言） 2024年3月24日 (日) 03:25 (UTC)[回复]
  • 另外拖@MilkyDefer：出来，future grade 条目要直接沿用还是怎样处理(pia!) --Temp3600（留言） 2024年3月24日 (日) 03:33 (UTC)[回复]
    什么叫沿用？事实上我连现在future grade的使用情况都不是很清楚，可否说明一下背景信息？--MilkyDefer 2024年3月24日 (日) 03:55 (UTC)[回复]
    @MilkyDefer：例如en:Talk:Texas_State_Highway_32按你的构想，是什么评级。背景资料....按我很初步的认识，英文WPBS的条目评级系统只容许BCStub等标准评级，但专题组可以按各自需要将条目评为future级等特殊等级。这与目前WP:QUALITY中建议的评级方案并不一致。--Temp3600（留言） 2024年3月24日 (日) 04:05 (UTC)[回复]
    有什么……不一致吗？Future Class列在非标准等级下，并且写有“部分专题还会启用附加等级。”看上去挺一致的欸。--MilkyDefer 2024年3月24日 (日) 04:36 (UTC)[回复]
    咦我写错了...en:Talk:Texas_State_Highway_32如果按维基百科:通用评级，它下面只有一个future-class的专题评级，那么就不能评为stub.在我看来这是问题。--Temp3600（留言） 2024年3月24日 (日) 05:01 (UTC)[回复]
    en:Template:WikiProject U.S. Roads列在en:Category:WikiProjects using a non-standard quality scale，因此此篇文章的评级没问题。我觉得WPBS的评级主要是条目整体评价，在zhwiki实施起来基本上也是这个目的。只不过 zhwiki评级似乎比较复杂，所以允许各专题自订标准，每个专题模板都算non-standard quality scale。这部分实施起来，其精神与enwiki也相同。--Kanashimi（留言） 2024年3月24日 (日) 05:12 (UTC)[回复]
    按英文版的评级方式是没有问题，但来到中维，维基百科:通用评级并不是英维的对等翻译。于是就有了"若一条目仅有一个专题，其通用评级应与该专题所评的等级一致。"这样的条款，影响到WPBS专注在内容评级的工作。顺带一说，这一点也和LP为什么建议全面转用英维制度，将内容评级由专题组上提到社群的精神一致。不过这样就涉及更复杂的改动，恐怕还是免了。--Temp3600（留言） 2024年3月24日 (日) 05:30 (UTC)[回复]
    我个人觉得这一条仅限于单一专题模板采用标准评级的情况下才有效。但假如所有专题模板都属于 non-standard quality scale，则不如废掉。--Kanashimi（留言） 2024年3月24日 (日) 05:49 (UTC)[回复]
    • @Temp3600：我觉得像Future、Current（某主题是否是新闻事件或未来事件完全取决于专题领域，例如某主题在A领域可能是一件大新闻，所以评Future，但另一个领域关它屁事所以评甲乙丙丁初之一）Merge、Need（这种通常都是向特定专题请求重定向扩充为条目的标记，无关专题就标通用评级的重定向级 重定向级吧）这些“聚焦于特定专题”的级别就让相关的专题沿用吧，然后从通用评级的标准评级撤下变成非标准评级，我想问题应该就解决了。修订的部分，我想等到下面确立哪些要设为标准评级之后，再将通用评级指引加上“只能用标准评级”之类的规范应该就能从行政手段解决了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月26日 (二) 17:36 (UTC)[回复]
  • 另另外我约略看了一下英维，看来它们已经将各专题评级整合起来，会个条目只有一个评级。这是你提出由上而下的背曔原因吗?@For Each element In group Next：--Temp3600（留言） 2024年3月24日 (日) 03:38 (UTC)[回复]
    我也认为WPBS是社群基于标准（WP:QUALITY）对条目做出的评价。当然，社群也允许专题依照自己的标准对条目做出评价，并标记在讨论页上。某种意义上，社群评级和专题评级是“人格独立”的，这里的“上”和“下”更像依赖的上下游，而不是官大一级的上下层。然后既然专题评级是独立的，那专题就可以选择各种策略：
    • 社群人多力量大，自行评级太繁杂，WPBS填啥我填啥。（看起来就像评级被废了，但其实是选择和WPBS的做法一样）如果对专题成员评级不服，要么以社群成员身份找社群吵，要么推动专题退群。这就是英维绝大部分专题的策略。
    • 预设继承社群评级，但也可以自行覆盖社群评级。这就是我们现在的状态。
    • 不继承WPBS的评级，只要自己的class不填就是未评级。英维的退群专题（比如有BL的WP:MILHIST、没A的WP:VG）都是这个策略。不排除有些专题是想自己搞；但也有专题是只开除掉A级，其他等级想继承社群，但因为英维技术不支持策略2而被迫退的。
    像SunAfterRain说的，绝大多数专题用策略1就够，而且理论上标准相同的专题应该评同样的等级。个别专题有特殊的评级标准，那就采用策略2。真有专题完全不想社群插手，那就上策略3。策略1那就是纯粹的自上而下了。此外，对上游的WPBS规定好标准等级后，将非标准等级映射到标准等级（假设规定BL->List、D->Start、Current->Unassessed），也可以让机器人参考策略2和3的专题填WPBS。
    自下而上主要还是一堆奇葩等级，逻辑上没法搞。刻度尺测量物体长度，得到的结果应该是稳定的；一次测3 cm、一次测5 cm，就说明测量错了。但如果两次测量都操作无误，那你用的大概不是尺子 WPBS本来评CL，因为来了个不支持CL的专题就改评List，两次评级都没有错，这就说明该制度不适合衡量条目品质。如果将奇葩等级改成WPBS标准评级，或者拒绝参考非标准等级，那这个制度就可行；但这基本就又成了上面的问题。--For Each element In group Next（留言） 2024年3月24日 (日) 16:21 (UTC)[回复]
    • 我觉得改动WPBS最少的可能是将所有“条目品质性”（甲乙丙丁初等）和“非条目类别性”（Disambig、SIA、Template等）的级别全部设为标准评级（含少数专题另设的Bplus和D、以及很少专题用的A级等[有专题用A级，如台风之类的专题。]），“性质性”（Future、Current等）的级别全部设为非标准评级。这些“与条目品质无关”的评级就让专题自己评，不影响WPBS，就不会出现要在CL级或Future级取舍的状况了。然后各自专题不要的，自己去mask（到时全站公告一下，想接受的专题就接受，不想接受的专题就自行写mask，这样写mask的责任就不会在此次修改上）。技术上成本最小。 只不过以上作法因会将AL、BL、CL、SL也列入标准级别，代表List级别可能会变成没有任何页面会被评成List级，看是要废除List级还是保留List级在代码里，不想跟进的专题自己mask。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月25日 (一) 04:43 (UTC)[回复]
    • 然后主题专题自设的Complete、Substantial、Basic、Incomplete因WPBS预设在非条目命名空间时会因“Namespace优先”而评成“主题级”，所以我想应该也问题不大。如需在WPBS中禁掉，可可以将Module:PJBSClass#L-53的一堆if陈述式注解掉。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月25日 (一) 04:57 (UTC)[回复]
      您说的也是可行方案。目前启用BL、CL的专题，List基本都是当和Start对等的级别来理解；如果都接受List级=初级列表，而不用新建等级，那留着List级也OK。唯一担心的是A级，倒不是有没有人用的问题。A级是高于GA的，英维也是A级评级比GA评级规格高：GA可以随便一个外行评，A级专题内部出三个专家评，FA是包括专题专家在内的社群集体评，所以有FA>A>GA的逻辑链。但是我们的FAC/GAN和英维评级模式完全是两码事，到头会不会还是社群认GA不认A？--For Each element In group Next（留言） 2024年3月25日 (一) 14:33 (UTC)[回复]
  • 先多谢各位，意见都很有见地。希望在上方再拆一个小标题。A级与GA的问题是老大难了，我想这次还是先不处理为好。A级虽然很少用，但一直都算是标准评级，现在一下子移除不太好。List级对等于初级列表长远是好主意，但要标记清楚，因为许多旧列表是list级。所以现在list级代表初级或以上的列表。或许长远要建立start list?—Temp3600（留言） 2024年3月25日 (一) 23:35 (UTC)[回复]

D级与B+级等标准讨论

接上文宇帆君列出的等级。新级别是要写文档的，所以下列意见供参考：

  • D级目前看来只有宇帆君活跃的多面体在用，其条目是介于C和Start之间。讲真，流行文化领域，因为关注粉丝向这种扣分内容，D级还是很好用的。
    • 比如明星条目，内容上已经有C级该有的内容，但因为很多内容都以粉丝介绍口吻出现，需要大量清理和改写；这时评Start太可惜，就可以评D级。这基本就像多面体专题说的，“内容上可能达到C级水准，但其他方面有严重缺陷”。或者说，写条目的人擅长事实性内容，但不了解这里的格式手册，写出的东西很随意不像百科。
    • 另一方面，虚构作品条目也强调要写反响等现实世界内容。一般来说，编者不写现实世界内容，就表示他不熟悉格式手册，所以条目格式、行文等方面也不会太好。这种条目又要清理又要扩充，就可以给Start。但也有从英维FA翻译一半的，条目序言完整、作品介绍也很规范，但该到制作历史和评价，他又他不翻译了。这种只用扩充不用清理的，也可以从Start抬升为D。
    • 可以看到，流行文化领域这个D级主要还是可以彰显“内容杂乱/格式差”。但科学等领域大概没有“粉丝内容”，所以这个D级通常会怎么用？
    • 另外有了D，是不是未来有可能对等增加DL？
  • B+只有英维数学专题有用过，而且现在删了；本地没有专题实装过，只在一些理论研究中提到，所以还是要想想标准怎么订。
    • 之前B+的评级标准是“条目高于B级标准”，再把B级标准抄了一遍，这就比较不良定义。GA和B的区别主要在GA还要求中立性稳定性，且文笔和格式的要求高于B。如果要搞B+，那标准大概就是“不要求中立性和稳定性，但其他方面同GA标准”？PS：B6提到的WP:JARGON和地区词在GA标准里没有体现，所以B在某些方面还高于GA；不过现在的英维已经把JARGON要求增补到GA标准里了。
    • 之前有提过增设优良列表（GL）。GL和FL的主要区别可以理解为GL不管红（绿）链，且序言不用太优美；这个境界就有点像B+和GA了。不过，FL和GL应该是要有本质差异的——类似WP:GVF的comperhensive和board coverage。例如对于游戏系列，FA应该像死忠那样列出小众改编作品，而GA可以只列出重要作品。（但是很多领域列表是不是没有这种问题？）
  • 小小作品更像是一个临时状态，和未评级一样是不该长期存在的。而且小小作品只是长度短，问题还没有广告、侵权等小作品更严重，所以整体统计上把小小作品拆出来的意义是？从维护追踪角度考虑，WP:PETSCAN或者Shizhao的专题机器人通告应该都很好用了。--For Each element In group Next（留言） 2024年3月26日 (二) 15:50 (UTC)[回复]
    • 感谢提供意见。关于增设新评级级别，如您提出的D-List和Temp君提出Start-List以及上述提到的GL，我想作为长远目标来讨论，现阶段先不处理。一来是phab:T360012本站评级资料表更新工单根据API测试似乎已合并到主程式，而GL则是因为评选设立草案无共识所以工单中就没有申请加入该等级，所以就算现在评了GL可能也无法被某些系统正确识别，同时，一直频繁变更感觉对基金会人员也不太好意思；二来是又要改十馀个全保护模板了 囧rz……。（注：如果说有了D就要对等增加DL，那为何有了GA没有对等增加GL😅 甚至图片有“特色图片”若对应FA的话，那为何没有GA对应“优良图片”、A对应“甲级图片”、B对应“乙级图片”[开玩笑的]）另外您提供的D级条目用法也十分不错，我(＋)附议这样子的用法，科学上可能可以用在使用了太多行话术语导致多数人看不太懂的这种情况吧；而Bplus 我这边是暂无其他想法，如果有其他维基人有什么想法欢迎补充；小小作品级是当时评级系统开发阶段进行测试时增加的级别，当时我找了几篇正文少于50字的条目但没被挂小小作品模板的“老条目”评上了此级，来试验系统能否接受输入，不过后来这些条目一些被提交AFD了、一些被扩充成小作品级了，但考虑到条目如果持续扩充也会持续升级啊，例如小作品升初级，这只是换成小小作品升小作品级而已，只是通常条目停留在小小作品级 小小作品级的时间可能会非常短而已。另外，我前几个小时仔细重看了一下每个级别，发现比较有问题的应该是deferred级（中维评级系统本次更新完显示为搁置级 搁置级）经查，该级别于2015年被加入中维评级系统资料表中，但在WP:TG简单讨论并对照英文维基还有此级别的专题说明显示，该级别代表的意义是“本专题不提供评级，转介由涵盖本专题的专题提供评级”所以可能也不叫做“搁置级 搁置级”，TG上有群友建议“转介级”，不过这种级别对上通用评级的话，基本上存在感就没了，阿卡林～，不过UUM表示这种转介具有一定程度“重要性”，可能要讨论一下，看是要改名还是干脆就废除掉，或者以“未评级”论之类的。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月26日 (二) 16:52 (UTC)[回复]
    • 感谢宇凡的研究，这个转介级我都没听说过。评级级别方面，宇凡君所指的技术困难确实存在，就像我们这几天讨论了一下，又想到找到这么多评级。如果每次都去phab改，不免扰民。我初步的想法是，quality 指引的标准评级部分建立为指引，规定wpbs 目前社群认可的评级；专题评级维持论述级，方便专题修改，待有共识后再处理。至于wpbs模版，则不需修改原码，只需在模版说明页等写清楚那一些评级因尚未有广泛共识，暂不开放使用，就可以了。
    • 标准级方面，我比较关注CL与乙上，大家懂不懂得评。虽说当成推广也无不可。—Temp3600（留言） 2024年3月26日 (二) 23:53 (UTC)[回复]
  • （有感而发）除了本子节开始的争议外，以上讨论与研究其实都满有意义和价值的，如果能提前在去年十二月，也就是我当初Ping了洛普利宁时，他就发表了这些意见，并开展了我们现在所讨论的东西，那我觉得WPBS应该会更完美。不过现在说这些都是后话了。另，跟大家说声抱歉，我当时一心只想著如何把MilkyDefer起草的临时方案开发成正式方案、如何pass所有testcases 和解决讨论页上各种问题回报（1、2等），一切考量都以技术为优先（我当时优先级最高的考量是：程式怎么写更省效能，于是出现了mw.loadData("Module:PJBSClass/page")用于让该功能在整个页面解析的过程只会跑一次，而不会每次调用通用评级时都跑以节省效能），却忽略了行政上的执行问题，而导致了今次的争议，我感到十分抱歉。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月27日 (三) 01:30 (UTC)[回复]

B+我之前写过论述。鉴于中维的GAN机制（时间短、需求票数多，且评审者普遍社会惰性），B+当GAN预审还是很有生态位的。但是在务实上，等GAN评审素质普遍超过这个乙级评级，B+才会有得玩 耸肩

我想B+（Bplus）的标准可以用WP:WIABCA的大纲来套用WP:WIAGA：

这样B级评审时也顺手按GA（B+）提意见。--For Each element In group Next（留言） 2024年3月28日 (四) 14:20 (UTC)[回复]

WPBS级别列表

目前{{WPBS}}能接受输入的级别大部分都是phab:T360012向P站登记的级别以级在案《第一阶段：修正评级值不同步问题》时所有评级Data模板统一同步更新的评级值列举如下（共50个。此外由于表格过长，已折叠。请单击[显示]以展开表格）：

能够由{{WPBS}}程式自动评级的级别（详情）
典范 特色列表 特色图片 优良 小作品 列表 同类索引
消歧义 重定向 沙盒 模板 模块 分类 文件
草稿 主题 专题 用户 使用说明 界面 非条目

以下建议供行政组参考：

  • 标准品质级别（可填写在WPBS）：
    典范级 典范级[FA]、特色列表级 特色列表级[FL]、特色图片级 特色图片级[FM]、甲级 甲级[A]、甲级列表级 甲级列表级[AL]、优良级 优良级[GA]、乙上级 乙上级[B+]、乙级 乙级[B]、乙级列表级 乙级列表级[BL]、丙级 丙级[C]、丙级列表级 丙级列表级[CL]、丁级 丁级[D]、初级 初级[Start]、列表级 列表级[List]（暂时作为初级 初级列表使用）、小作品级 小作品级[Stub]、小列表级 小列表级[SL]、小小作品级 小小作品级[Substub]、无级别 无级[No]
  • 标准类别级别（可填写在WPBS）：
    消歧义级 消歧义级[Disambig]、同类索引级 同类索引级[SIA]、重定向级 重定向级[Redirect]、沙盒级 沙盒级[Sandbox]、模板级 模板级[Template]、模块级 模块级[Module]、分类级 分类级[Category]、文件级 文件级[File]、草稿级 草稿级[Draft]、主题级 主题级[Portal]、专题级 专题级[Project]、用户级 用户级[User]、使用说明级 使用说明级[Help]、使用说明级 界面级[interface]、非条目级 非条目级[NA]（如TimedText:空间）
  • 非标准类别级别（不应该填写在WPBS）：
    图书级 图书级[Book]（曾有共识引入，但因技术原因部署无限期推迟）、音频级 音频级[Audio]（只有少数专题将File级做细分，WPBS应都填入File级）、图像级[Image]（(▲)同上）、非页面级 非页面级[NAPage]（只用于特殊专题）
  • 非标准品质级别（不应该填写在WPBS）：
    优良列表级 优良列表级[GL]（讨论尚无结果）、特色图片 特色主题[FPO]（未通过设立）、完成级 完成级[Complete]、充实级 充实级[Substantial]、简单级 简单级[Basic]（完成、充实、简单仅用于PJ:主题）
  • 非标准级别（不应该填写在WPBS）：
    未来级 未来级[Future]、动态级 动态级[Current]、合并级 合并级[Merge]、请求级 请求级[Needed]、搁置级 搁置级[Deferred]、
  • 技术性级别（不应该填写在WPBS）：
    委员会级 委员会级[council]（仅做图示用途，不应手动输入此级）、 错误级[Error]（出错时会自动加入，不应手动输入此级）、未评级 未评级[Unassessed]（无提供时自动产生，不应手动输入此级）、未知级 未知级[Unknown]（无法正确识别的情况，应修正之，而不应手动输入此级）
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月6日 (六) 03:43 (UTC)[回复]
感谢总结。我有一些疑问：
  • Substub作为标准品质，似乎比较增加维护负担？会创建小小作品的基本都是新手，他们不懂得在讨论页挂{{WPBS}}填|class=substub。维护人员也都在条目页标记{{substub}}，然后打捞人员再从Category:小小作品追踪，这就基本就没人会管讨论页。而且就算有专题模板，如果利用讨论页的分类来维护，就要从讨论页跳转到主页面，也是比较低效的。（MilkyDeferBot可以根据讨论页横幅和条目页{{substub}}自动生成页面列表，这样也没必要用讨论页评级）此外如果substub是被人手填了，那就还要经常盯着条目，看评级是否过时。所以依靠评级模板来维护substub，感觉有种打捞一分钟，评级三十秒，性价比相当低。所以，WPBS层面统合到stub是否好些？
  • 正规条目都应该有品质评级，尚未评估品质的条目是Unassessed，条目空间的Disambig等特殊页面也考虑进去了。看英维也没no这个级别，所以无级别的条目会是怎样的？
--For Each element In group Next（留言） 2024年4月6日 (六) 05:20 (UTC)[回复]

等级标准小结

洛普利宁在上文提到的“PJBS之PJBSClass.getClassByPage()”自动评级（小勘误：自动评级实由PJBSClass/main.getClassAuto()和PJBSClass.getAutoClass()共同完成，前者以页面状态和挂有模板判断、后者只看Namespace），这些评级会根据页面挂的模板、子页面名称、页面状况和所在命名空间等进行自动评级。这些评级分为两类：不可被|class=参数复写的评级以级可被|class=参数复写的评级。
这些级别有：
  • 不可被|class=参数复写的评级：重定向级 重定向级、特色图片级 特色图片级（注：|class=有值时会强制被改为File级）、模板级 模板级、模块级 模块级、分类级 分类级、文件级 文件级、草稿级 草稿级、主题级 主题级、专题级 专题级、用户级 用户级、使用说明级 使用说明级、使用说明级 界面级、非条目级 非条目级
  • 可被|class=参数复写的评级：典范级 典范级、特色列表级 特色列表级、优良级 优良级、小作品级 小作品级、沙盒级 沙盒级、列表级 列表级、同类索引级 同类索引级、消歧义级 消歧义级
上文提到，目前不在WP:QUALITY中的级别都需要补上文档，因此我起了以下草稿供参考：
（注：如果有需要修改可以直接编辑本表格，无须经过我的同意(不被视为修改他人留言)）
（注2：下表只列出目前未出现于WP:QUALITY的级别）
（注3：由于表格过长，已折叠。请单击[显示]以展开表格）
预计种类分成三类：标准级别（描述条目品质）、标准类别（描述页面种类）、非标准级别（专题自定的东西）
@Temp3600：您看看这些资讯对行政组作业有没有帮助？（请单击[显示]以展开表格）-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月5日 (五) 10:48 (UTC)[回复]
感谢宇帆君的总结。我大胆做了一些调整，说明如下：
  • Bplus之于GA类似A之于FA。A级的标准和文档页指出要走比较正规评审，类似这种，而不能像评B、C那样随手改|class=。所以Bplus的要求中我也提了要做评审；不过这也就是这么一说，大家肯定还是会随手改的😂。另外A级开始才算专业，GA只能叫接近专业（我上面说的，英维A级需要专家来评审，而GA不需要），所以调整了一下措辞。
  • D级还是可能有格式问题的，基本上B级才算比较遵循格式手册，连C级可能都差一点，而且爱好者内容广义上也算格式问题。其他方面调整了一下语言，大体是说条目内容方面有含量，但其他方面比较差。
--For Each element In group Next（留言） 2024年4月5日 (五) 13:54 (UTC)[回复]

页面评级与通用评级指引调整

    • 非常感谢娜娜奇。但我因为现实原因(pia!)暂时不能积极参与讨论。我预计会于19-21日的周末发言，这段时间麻烦诸位了。--Temp3600（留言） 2024年4月12日 (五) 11:29 (UTC)[回复]
      • 约略看过没有问题。在格式上有一点想法: 每个类别还是找一个例子，当参考。另外，会否用Template:Guideline section，只将标准评级立为指引会较好?如果专题组日后创立新评级供内部使用，便无须经VP共识修改评级表，而可自行加入。不过倒过来，如果自行加入评级会弄坏模版，那么还是经VP讨论，协调好再修改较好。这方面我不清楚，请给意见。--Temp3600（留言） 2024年4月12日 (五) 11:58 (UTC)[回复]
        • @Temp3600：届时，如果确定该等级都标准化的话，仅需要将{{Class_mask/core}}中，目前还没标准化的级别做“开放”即可（不必改程式，只要改类似config(设置)的东东），而专题自建级别已有相应功能，无须动到核心模板，范例见{{WikiProject_Example}}，因此完全无需更动本次系列模板/模组或任何程式码的核心，故自行加入评级不至于会弄坏模版。常见的专题非标准评级我觉得可以在WP:QUALITY提，在章节标题标注“本段不是指引”应该就可以了，就不必走VP共识了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月12日 (五) 15:49 (UTC)[回复]
          • 先抱歉晚了许多上来...生活艰难QQ。
          • 如果如此，那么标准级别一节立为指引就可以，并在非标准级别一节清楚列明专题可以如何自行加入新评级(好像在模版说明里已经写好?那么就只需要提供连结)。--Temp3600（留言） 2024年5月5日 (日) 07:27 (UTC)[回复]

对于Wikipedia:页面质量评级标准（以及Wikipedia:通用评级）还有一些逻辑上的考量：

  • 英文版的页面en:Wikipedia:Content assessment翻译过来是内容评级。其内涵理论上包括评级流程、评级标准等多个部分。而中文版的标题是“页面质量评级标准”，一只介绍标准本身，二又强调品质评级。而当前页面是从古早期英维版翻译过来，现在两边都改了很多，这就很微妙了。所以页面是否要改名“Wikipedia:页面评级”？
  • 如果从标题强调质量评级来看，页面似乎应该将“标准质量评级”（≈条目）和“标准类别级别”（≈非条目）分设为两个大节。说约等于是因为特色图片属于非条目但又要评估品质，而同类索引（SIA）是自动评级但理论上属于条目。
    • 对于条目品质评级部分，是否需要流程图辅助说明？（比如写入指引页，或放在论述页给个连接）
  • 如何表述“通用评级”与“专题评级”的关系？从目前的讨论来看，可能还需要一个页面（可能是Wikipedia:页面评级）厘清：
    • 社群和专题都可以各自独立地对页面评级。评级结果登记于条目讨论页顶部。
    • 通用评级由社群编者评估，对社群负责。本页刊载的等级标准为通用标准，即适用于WPBS的通用评级。
    • 专题评级由专题自行解释，但因为专题评级一般直接继承通用评级，所以也还是这套标准。部分专题可能自选启用或关闭级别，也可能重新诠释通用级别，这些内容具体在专题评级页刊载。

我希望听听其他编者的意见，所以暂时不会积极回复。--For Each element In group Next（留言） 2024年4月14日 (日) 15:17 (UTC)[回复]

  • en:Wikipedia:Content assessment 有较多的内容，我认为这是因为他们是这个制度的来源地，所以有关于制度的历史流变等可以写。中维目前只是引入的制度，还没有社群的经验，因此没有这部分的本地经验可以立为指引，而只能写一些硬规定。我认为这暂时不是问题，如日后成熟，自然可以再将这些段落引进，指引名字也可以更改。“页面质量评级标准”就暂时只写标准，待评级流程成熟后，就可以加入这一部分的指引。
同意将“标准质量评级”与“标准类别级别”分立为两个三级标题。这是一项不涉及本质的结构修改，不难。
流程图最好有，但要有人来画...

“通用评级”与“专题评级”的关系:这是我最早就想改写的部分。既然“通用评级”只可填标准评级而专题评级可以填其他自订评级，那么维基百科:通用评级就需要至少修改"若一条目仅有一个专题，其通用评级应与该专题所评的等级一致。"，最好是重新理顺这一部分的逻辑。

整理目前的讨论，建议"机器人会根据该页面最多专题评等的评级等级作为通用评级"继续保留，但机械人应检查这会否导致WPBS被评为非正式级别，如发生这种情况，那么机械人则跳过该条目(可以考虑加入"需要手动进行WPBS评级"的分类)，留待人类前来。
同意"社群和专题都可以各自独立地对页面评级"的基本策略。这样就解决了list级的问题。即使专题的评级只有list级，WPBS仍可以手动评为更准确的CL/BL等细分级别。由机械人自动评的list级也与这个逻辑没有冲突。
长远的最终方向是，WPBS作为条目的内容评级，专题评级则为某一方面提供额外的资讯，类似tag.但这个需要将目前的评级逻辑反过来，我猜一两年也无法完成，就写在这而已。--Temp3600（留言） 2024年5月5日 (日) 08:10 (UTC)[回复]

修订案

维基百科:通用评级
  • 解决“通用评级”与“专题评级”的关系。断开两者的上下级关系。
  • 通用评级只限填写标准评级。
  • 介绍一些其他功能，例如专题可以自行加入评级，不过这些不属于WPBS的范围，将它们指示到其他页面去。
维基百科:页面质量评级标准
  • 对应通用评级的改动，明确两者间的关系。即: QUALITY负责规定那些级别属于标准评级，及提供评级的参考。也提供其他非标准级别的介绍。通用评级指引则负责通用评级的流程，由社群负责，为条目的质量提供评级，而专题级模版级等请不要来找WPBS.
  • 结构调整，将“标准质量评级”与“标准类别级别”分立为两个三级标题。
T: Grading scheme
  • 为所有标准类别补上例子。

似乎除了这笔移动外没太大进展，那我就先写个Draft:页面评级吧。T:Grading scheme的例子就没办法了，甲级估计社群这辈子也评不出来（现在的Talk:家牛也没找到评审在哪）😂 --For Each element In group ... Next 2024年7月10日 (三) 17:45 (UTC)[回复]

后续讨论

关于 rater.js 脚本

前面的讨论貌似没有涉及到老版本的rater.js脚本（User:Chiefwei/rater aka en:User:Kephir/gadgets/rater）。貌似enwiki那边已经废弃了老版本的rater.js，并且由Evad37推出了新版的rater.js（en:User:Evad37/rater）。我再考虑将新版本引入并做本地化，不知道目前是否已经有类似的工作了？--Ceba_robot 才不是机器人！ 2024年2月16日 (五) 17:57 (UTC)[回复]

有见到Ericliu1912和YFdyh000两版。--Cookai饼块🍪（💬留言） 2024年2月16日 (五) 18:17 (UTC)[回复]
妥了，看起来YFdyh000的目前跟上游已经同步，还是不要做重复工作比较好（--Ceba_robot 才不是机器人！ 2024年2月16日 (五) 18:24 (UTC)[回复]
我也跟进借鉴了，至少现在用哪一个版本都不会落后。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年3月4日 (一) 11:51 (UTC)[回复]

Unblock-zh.org

Unblock-zh.org网站的样子

很久以前讨论过的一个项目，也就是unblock-zh的网站版，我最近给他做出来了，如果对测试版软件感兴趣的话，请去 https://unblock-zh.org 这里去看看。（注意测试版软件，你的用户最后很可能被删掉！）7月7日update：软件进入试运行阶段，此时产生的工单等数据将永久保留。Bluedeck 2024年7月8日 (一) 19:21 (UTC)[回复]

附带一个教学视频 https://www.youtube.com/watch?v=IImfyNnRB4M

目前站外用户申请账户的方式是Wikipedia:账号请求发送邮件，其实也没有太不方便。但是这个途径我觉得还是更直观一点，比邮件列表好用一点，尤其是管理员处理的时候。我的想法是网站可以和邮件列表并存，或者以后达成互联。欢迎提出意见。Bluedeck 2024年4月29日 (一) 04:05 (UTC)[回复]

PS. 已经收到tigerzeng的意见，允许用户自定义提供的IP地址字段，以解决部分代理的问题。Bluedeck 2024年4月29日 (一) 04:22 (UTC)[回复]
超 英 赶 美 —— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月29日 (一) 08:09 (UTC)[回复]
我最期待的画面出现了。--AT 2024年4月29日 (一) 09:14 (UTC)[回复]
好吧，终于把这个弄出来了——是蓝桌弄的？那就不出奇了。👍 赞——Sakamotosan路过围观 | 避免做作，免敬 2024年4月29日 (一) 09:29 (UTC)[回复]
非常好UX。至于是否方便了用户，我好奇能否在合理的范围内收集一些统计数据作对比，这样最有说服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)[回复]
另外这个工具让我想到了我很久之前做的维基媒体服务器连通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)[回复]
非常好软件。
不必要的功能建议：1.通过遍历封禁日志的摘要有无对应模板，显示是否是ip封禁。2.通过接口调用在界面一键创建账户（和授予ipbe？）
另外问一下数据托管在哪里？将来投入使用的话需要作为存档使用，所以数据需要备份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)[回复]
一键创建账户/授予PIBE的话，有两种途径。第一，管理员通过oAuth授权unblock-zh.org，通过管理员账户操作，然后从本地日志看来，操作者是管理员。第二种途径是，成立一个机器人账户，比如名叫 unblock-helper-abot，并且赋予机器人管理权限，然后通过机器人操作，并在摘要里说明是根据哪个管理员的指令操作的。让我来决定的话，我倾向于使用第二种方式，因为我希望尽量不要向第三方授权我自己的账户，但是第一种方式的日志更加清晰。请问一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)[回复]
使用OAuth可以只需要简单的身份识别获得权限，用于确认是不是登录系统的对应是wiki的哪个用户。然后代理操纵的机器人可以标记操作人员的wiki用户名（通过前面获得的信息）。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:33 (UTC)[回复]
如果不改变单管理员授权模式，我倾向于第一种，这样和原先的工作模式保持一致，便于查询。
mw:OAuth/For_Developers称应用做的操作会有标签。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)[回复]
在这里没有看到可以使用oauth给用户添加组别的选项，那么也是说IPBE的授予只能透过abot进行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)[回复]
的确只能这样。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月2日 (四) 03:40 (UTC)[回复]
咱好像记着这种权限似乎不需要特别勾上某个选项就默认拥有，您要不尝试一下？ Stang★ 2024年5月8日 (三) 01:14 (UTC)[回复]
真的假的，在授权的时候不声明却可以操作改变用户组这么重要的操作？如果是真的那也是个bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)[回复]
用API能查IP有没本地封或者全域封，好像不是必要。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:26 (UTC)[回复]
👍 赞👍 赞👍 赞 牛逼--Dnaimfz（留言） 2024年5月11日 (六) 04:04 (UTC)[回复]
@Bluedeck：话说可给管理员布告板抄送一份通知连结至此？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月1日 (六) 08:43 (UTC)[回复]
@Bluedeck：想好奇请问是否有考虑过部属在wikitech:Help:Cloud VPS？如果有，为什么不选择部属在该处？--SunAfterRain 2024年6月4日 (二) 09:30 (UTC)[回复]
管理员通告版：不知道效果会怎么样啊。等上线后在ASN通告一下，然后TG呀IRC呀广播一下应该就行。CloudVPS：他的介绍说自己是标准的VPS，但是又有迹象表明他不是完全标准的环境，导致我不想把时间花在部署，测试，更换环境，以及踩坑上面。对我来说，写软件是趣味十足的事情，而调试环境则是让我胃肠不适的事情。目前我没有换环境的需求，因为开销太小。如果有我再考虑cloudvps。cloudvps的另一个问题是只有在virginia有DC，但这不是一个大问题。Bluedeck 2024年6月8日 (六) 04:00 (UTC)[回复]
以我个人看法，部属在CloudVPS的隐私疑虑绝对会比一个外部网站好很多，当然你维社群愿意接受那我也没什么意见就是了。虽然不清楚是笔误还是什么的，如果开销太小的话我自己是会考虑换过去啦。--SunAfterRain 2024年6月10日 (一) 17:54 (UTC)[回复]
可以理解你所说的。我可以把cloudVPS当作一个长期目标，最终迁移到那上面去。Bluedeck 2024年6月14日 (五) 05:29 (UTC)[回复]

试运行

在过去的几周里，我增加了最后的一些的功能，分别是1）按日期搜索排列工单；2）邮件回复模板；3）管理员删除工单、删除消息界面；4）用户改名功能。我想知道大家觉得还缺少哪些网站本身的功能（邮件服务器、机器人授予IPBE除外）。如果感觉差不多了，那么可以进行试运行。试运行期间，再对可能发现的新的功能需求进行补充。试运行的提议正在进行公告。如果通过，将会将网站首页文字改为试运行，并暂时移除一些只具有展示效果的链接，然后在用户无法注册的提示页面加入网站的链接，这些操作大概最多需要一天就能完成。在试运行决议通过前，如果对网站有任何问题，欢迎在此讨论。Bluedeck 2024年5月13日 (一) 23:30 (UTC)[回复]

功能方面，个人认为管理员不应该有删除工单的能力，这个应该由维护者来做，比如遇到spam/扰乱性工单就打上相应的标签，若干天后自动删除；可不可以出个statistics大概写一下某月某人处理了多少工单之类的；反spam方面怎么样，你觉得需要加个recaptcha吗；模板建议是放到Github或者类似公开的地方，需要改的人发pr；可以考虑加一个link/merge功能么，比如一个用户就一个问题发了多个ticket，这个时候可以把它们关联起来；感觉可以把login改的小一点，或者让非管理人员意识到不需要登录就可以发ticket。
另外就是建议放到toolforge或者cloud VPS上。顺便问个问题，你觉得这个系统需要承担unblock-zh最原始的封禁申诉职能吗 Stang★ 2024年5月14日 (二) 01:47 (UTC)[回复]
  • 谢谢提议！简短回应：
  • 删除工单就是为了应对扰乱才设计的功能。删除之后可以恢复或检视。（UI需要另外添加）工单的永久保留或删除问题在下面讨论。
  • 反spam：UTRS目前是阻止同一个IP地址多次发送工单。但是我的方案不记录IP地址，无法阻止。我可以考虑一下记录ip地址的hash，并由此进行rate limit。我个人完全不喜欢captcha，除非不得已，我可能会考虑上captcha。在此之前我会尽量用其他手段处理spam问题。我有一些asymmetric proof of work的方法能防止自动化的spam。如果有人无聊到要手工spam，那么唯有记录IP并进行区段查封这一个办法。（但是这样一来，不就把本身的目的给击败了？？）
  • 邮件模板：我不会放在github，毕竟不是每个管理员都会开PR，我简单的开一个用户页面存储目前的模板，谁想添加，给我留个言即可。邮件模板都是非常简单的纯文字模板。当然，如果你喜欢用gh，那么在前端的repo里有一个文件，你也可以直接PR这个文件。
  • link/merge：race condition太多，最多做成stack overflow/github issues那样，“标记为#109的duplicate。关闭”这种解决方案。
  • login改小：我肯定会让新用户看到不login就能发工单，这是一个重要的因素。
  • statistics：这个我一定会做，因为这会让处理工单变得很有趣，我的设想是做一个leaderboard，能够激发人们对于处理工单的无限潜能，哈哈哈哈。
  • Hosting：toolforge不能满足我的要求，CloudVPS不熟悉。将来打算支持图片上传，需要一个能挂载S3的环境，另外多区域host允许你把服务器托管在东京/首尔/LA。目前，服务器托管在Vultr的新泽西区上面。
  • 这个网站做成网站的形式，是为了新用户方便的注册+IPBE（也就是unblock-zh-ipbe的功能）。处理被长期封禁的用户在邮件列表中50-100封邮件那么长的申诉，并不是网站初衷。如果有人就是要在网站上申诉，管理员也选择在网站上处理，那我不会站出来阻止，但是如果网站上出现了对维基百科历史有一定意义的讨论内容，我觉得有应当抄送一份到邮件列表。
Bluedeck 2024年5月14日 (二) 04:12 (UTC)[回复]
update: 已经增加了查看和恢复已删除工单的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)[回复]

另外还有两个别的需要讨论的问题：

  1. 工单是否永久保存？永久保存是目前的默认，而且邮件列表也是永久保存的。但是我觉得比如挂上“处理结束”标记90/180天之后永久删除相关信息这个是更安全的做法，想征求一下大家的意见。
  2. 开源：从一开始我就设想开源。这个项目有4个repo，其中3个可以在最近开源。一个需要我检查一下有没有API Key之类的物品遗落在代码中，然后才能开源。请期待。
  3. 共同参与：如果您想共同参与开发，或者参与对服务器的运维，欢迎在这里提出来。Bluedeck 2024年5月14日 (二) 04:49 (UTC)[回复]
感谢贡献，整体非常完善。如有需要可以协助维护。--Borschts™ 欢迎外带一碗罗宋汤 2024年5月14日 (二) 13:32 (UTC)[回复]
存档应保留，只是可以限制普通使用者存取。另外，也应考虑先行在站内撰写说明页面，或补充现有方针与指引不足，以便利用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月14日 (二) 15:05 (UTC)[回复]
注意到两点可以改善：
  • 无法创建帐号者不应提供“我不想提供邮箱”的选项，创建帐号时需填写对方电邮地址才能安全发送临时密码。如果不想提供邮箱则难以协助创建帐号。
  • 需要添加提示文字，若不提供IP地址则申请有可能不获受理（始终审批IPBE时需要验证用户是否使用proxy）。
--路西法人 2024年5月15日 (三) 07:52 (UTC)[回复]
我脑海中预想的不提供邮件的处理方式：网站生成一个强的随机密码并记录在工单中，用户通过随机密码登入。优点：用户不需要邮箱地址。缺点：不提供邮箱的用户等于需要不断的刷新页面查看处理进度，是一个糟糕的体验。对于管理员，需要复制粘贴网站生成的密码来创建账户，也是多了一个步骤。上面我只是说明了操作的可行性，至于这个功能是否保留，可以继续讨论决定。对于第二点，IPBEG如果有这个要求，那我完全可以添加这个提示文字（甚至可以在维基百科设置一个页面，比如Template:Unblock-zh/strings/new-ticket-notice，然后网站可以反映这个页面的任意文字。）Bluedeck 2024年5月19日 (日) 06:22 (UTC)[回复]
我的想法是只要有任何第三方人员可以接触到任何密码的方案都是不安全的，尤其在发送邮件时在此类第三方网站留存临时密码亦是相当危险的；即使我信任你会尽力保障网络安全，但显然不安全的操作应尽可能完全避免。邮件、代理IP地址等都尚算不太危险的资讯，密码真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)[回复]
我想了一下觉得你说得很有道理。如果有的用户收到临时密码后不加更改，那么等于这个用户的密码永远的挂在一个所有管理员都能看到的地方，是不妥的。我已经把界面改成如果请求账户，必须提供邮箱，否则无法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)[回复]
一些minor的建议：about一页，Puzzle Globe似可译为“拼图球”，Wikibooks译名应为“维基教科书”非“维基图书”。不提供邮件的提示，“一串30几位的工单”应作“三十几位”。login界面没有明显的返回按钮，侧栏也消失了。lookup界面可以考虑加注工单号和邮箱择一提供即可。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月21日 (二) 03:01 (UTC)[回复]
另外我在想让其选择点选提交IP的选项是否也应该把UA也提供给审核用户检阅（方便反破坏比对）。--路西法人 2024年5月23日 (四) 07:54 (UTC)[回复]
统一回复。1）login界面有意如此设计。2）必须同时输入工单号和邮件，否则任意人士可以通过广泛查询邮件探知私密工单。3）UA信息只有CU才能访问，所以显然不能提供。另外就算用户主动提供了，那么IPBE处理者拿什么进行比对呢？毕竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)[回复]
2) 啊那就是提前提示创建工单时未提供电子邮件的须放空？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月27日 (一) 06:29 (UTC)[回复]
没有提供电邮的工单号会比较长，所以我可以改一下软件，让这种工单号不论是否输入电邮都能够正常查询。这样可以不破坏界面简洁易用。Bluedeck 2024年5月29日 (三) 06:45 (UTC)[回复]
好的👍 赞 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月29日 (三) 07:32 (UTC)[回复]

将开始试运行。公示已经进行了一个多月，收集到了很多改进意见，并实施了很多更新。今天起，我将正式修改MediaWiki软件界面，在网站上标注试运行字样，并在公告栏和ASN中对社区和管理员们进行公告。Bluedeck 2024年7月7日 (日) 16:26 (UTC)[回复]

@Bluedeck：请问IPBEG们可以如何存取工单？--路西法人 2024年7月10日 (三) 03:25 (UTC)[回复]
@LuciferianThomas：我正在编写为IPBE权限持有者提供权限的功能。完成后，IPBE将获得和管理员基本一致的功能。目前编写的功能是对于下方讨论中方案一的实现。编写完成后，我将会在用户讨论页面通知IPBEG权限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)[回复]

繁体支援

这个网站估计主要的受众是大陆梯子人士。但是，由于很多管理员是繁体使用者，那么我就增加了一系列的繁体支援，但是都是Google翻译的。请繁体管理员看看管理界面的翻译如果有很不和谐的地方，请指出来。如有需要，网站可以支援香港、台湾和澳门繁体的分别翻译。Bluedeck 2024年5月30日 (四) 08:15 (UTC)[回复]

感谢蓝桌照顾繁体使用者，但我目前检视似乎有一些介面仍然是简体中文的，例如新建工单的部分，另查台湾的教育部字典，work order这个词在台湾可以翻译为“工令”、“工作命令”、“工作通知单”或“工作单”等，就是没有查到称之为“工单”之翻译，惟我日常生活中前开所有词汇均较为少见，平常类似功能之提交申请平台反而被称之为“电子表单”，这部分可能需要更多繁体使用者来指出正确的翻译。--小过儿（留言） 2024年5月30日 (四) 15:30 (UTC)[回复]
新建工单的繁体化已经完成。关于工单这个用语的翻译，我参考了一下asus的网站，叫做“请求支援”、“搜寻案件”。不知道这算不算合适的翻译。如果觉得“案件”听其来正确，那么我就把繁体语言的工单改称案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)[回复]
“工单”是对应“ticket”而不是“work order”，比如Zendesk香港也是叫ticket作“工单”[32]。再甚者，直接“搜寻申请”也是得了，不需要特地什么ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)[回复]
@Bluedeck：怎么查阅或更改翻译？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月1日 (一) 19:44 (UTC)[回复]
通过改变浏览器的语言设置并刷新页面，可以查看不同的语言版本。目前要修改，可以直接留言告诉我哪里需要改。以后，会开放一个repo在github上可以pr。不熟悉sveltekit和github的用户仍然可以直接联系我。Bluedeck 2024年7月2日 (二) 06:00 (UTC)[回复]

工单的永久删除

目前没有这个功能。不过，根据欧盟GDPR要求，在用户请求的情况下，应该提供一种方法永久移除其个人信息。我想让管理员能够在工单上添加一个标记，被标记的工单约一个月后真正的删除。删除真正执行前可取消。这种删除只应该在特别的情况下进行（也就是用户请求）。（也可以单独只允许行政员执行真正删除，但是我觉得管理员已经足够可信，并且还有一个缓冲期间。）Bluedeck 2024年5月31日 (五) 23:04 (UTC)[回复]

这个功能不错。( π )题外话：我想知道维基百科不能删除账号是否符合GDPR，以及即使OS似乎也不是真删除，这是否符合GDPR。有人去举报一下是不是基金会就会实现这个功能了。--桐生ここ★[讨论] 2024年5月31日 (五) 23:25 (UTC)[回复]
应该是不符合的，而且显示未登录用户ip这个似乎也有一定问题。然而我们要团结一致，不要把基金会举报给欧盟。Bluedeck 2024年6月1日 (六) 05:34 (UTC)[回复]

让 IPBEG 在 Unblock-zh 上获得和管理员一样的权限

因为我觉得 IPBE 也是一大痛点，所以我觉得让 IPBEG 能够一起帮助处理会大有裨益。现在抛出几个方案讨论：

  1. 让IPBEG组和管理员同在unblock-zh.org/zhwp下有一样的（或者接近的）权限。
  2. 像邮件列表一样，单独新建 unblock-zh.org/zhwp-ipbe空间。
    1. 网站面向用户的界面不改变，根据用户是否需要 IPBE，自动将工单分发至 zhwp 或 zhwp-ipbe
    2. 网站设计改变，入口页面一分为二，用户需要自己选择是投递给zhwp还是zhwp-ipbe
  3. 不支持 IPBEG。

我觉得，从用户体验的角度，不希望入口一分为二。另外，不管选择 1 还是 2，都需要一段时间来修改网站的代码，但是 2 所花时间会更久一点，并且会增加日后维护的工作量（主要是会出现两套表单同步的问题）。关于用户隐私，由于 IPBEG 是签署 NDA 的，应该视为可信人员，所以我比较倾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)[回复]

设立IPBEG的本意就是许可IPBEG处理该类申请邮件，理论上可以说已有社群共识支持选项2，但已有共识未必支持选项1。IPBEG不能处理unblock-zh上非申请IPBE的工单。我是认为，一般而言封锁申诉本应都是在公开场合发起，申诉内容多数都应该可被所有用户检视，实质需要使用邮件申诉封锁的仅有无法编辑讨论页的情况。如你所言，IPBEG本有签署NDA，就算看了也不应该会造成什么问题（虽然能避免最好）。如果是最后采用最简化的选项1，那我觉得您可以最低限度在处理人员的界面中加入标签工单的功能，让IPBEG能明确标记跟他们职务无关的申请，从IPBE队列隐藏，仅能由添加标记的IPBEG（直至工单标签被管理员确认）及管理员检视。--路西法人 2024年6月2日 (日) 11:58 (UTC)[回复]
如果要让IPBEG不能看到非IPBE工单，那应该执行方式2更优。如果执行方式2，那么管理员、行政员也应该自动获得zhwp-ipbe空间权限，并进行工单自动分发。Bluedeck 2024年6月3日 (一) 08:34 (UTC)[回复]
不是“不能看到”，而是“不再跟IPBE有关的就没必要继续显示在同一队列，令其他正在处理IPBE申请的用户不小心点进去”。“看到”大概是不会有什么大问题的。--路西法人 2024年6月5日 (三) 02:22 (UTC)[回复]
分成两列或许方案2实现起来更简单？--桐生ここ★[讨论] 2024年6月5日 (三) 09:51 (UTC)[回复]
不是不行，但必须考量没签署NDA的管理人员是否有权限接触unblock-zh内的工单，一般视乎工单是否涉及IP位址等可辨识资讯。如果要再这样分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)[回复]
还是那句话，我无法理解WMF要求邮件列表内的IP必须有签署NDA才能接触，但允许使用unblock模板直接把IP公开。--桐生ここ★[讨论] 2024年6月6日 (四) 09:48 (UTC)[回复]
我一开始听说IPBEG需要NDA，但管理员不需要NDA的时候，我也觉得很费解。而且你知道吗，你用的任何JS组件要是对外部资源进行请求，那么就可能有意无意泄露IP。甚至你收到一封邮件，邮件里带个图，这图也能泄露IP。虽然说IP在wiki上被当作隐私，其实整个互联网对IP的保护可以用奇差来形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)[回复]
似乎是祇有涉及IP等隐私资讯时，才要求管理员签署相关协议。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 02:13 (UTC)[回复]
@Bluedeck：只要不僭越社群赋予之权限，应尽可能以您自身方便为宜。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月6日 (四) 00:11 (UTC)[回复]

提供的IP问题

现在有个问题

  • 如果申请者没有使用代理时使用此网站提交工单，被此网站自动带入的IP是其真实IP，而非使用代理且受到IP封禁的IP，对于IPBEG应该使用真实IP还是受到封禁的IP判断？如果有人使用代理访问此网站，有人不使用代理访问此网站，也会产生差异。
  • 是否像传统邮件列表一样另外要求用户手动填入封禁界面上显示的受封禁的IP或封禁ID？这样也有好处，就是IPBEG可以看到申请者被封禁IP同时也能看到真实IP，确定申请者处于中国大陆等受限地区。但产生另外一个风险，就是如果确实提供的是中国大陆IP地址，一旦泄露可能产生严重后果。--桐生ここ★[讨论] 2024年6月6日 (四) 10:00 (UTC)[回复]
    • 技术上有很多方法可以尽量避免记录IP，比如只记录部分IP、以及对管理员不显示IP，只显示IP是否处于封禁列表中。但是这些方法无一例外的会对管理员处理造成问题。我想到的各种方法中，只有一个值得实践的，是在工单解决之后将IP相关信息从工单中清除，避免永久留存。除此之外，就只有请管理员和IPBEG不要泄露IP地址。对于代理的问题，我可以加一个提示让用户记得开代理，再者就是干脆取消自动侦测IP这个功能，让用户自己填写IP和查封ID，和邮件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)[回复]
      我有一个方案
      • 申请者不提供IP：不提交IP
      • 申请者选择提供IP：检测IP是否中国大陆或其他受限地区
        • 是：不提交IP地址，只自动提交申请者IP地区，并且要求申请者手动填写受封禁IP
        • 否：自动带入IP地址
      --桐生ここ★[讨论] 2024年6月7日 (五) 09:10 (UTC)[回复]
      补充：IP地区是提交由服务端判断，而不是在前端处理，所以实际上仍然会提交中国大陆IP，只是不会储存在服务器上。--桐生ここ★[讨论] 2024年6月7日 (五) 09:13 (UTC)[回复]
      检测IP是否中国大陆或其他受限地区 这个感觉不是长久之计，GFW未来可能会给Unblock-zh上SNI封锁，用户会不得不套代理访问，这样Unblock-zh获取到的就不是真实IP--Yuki Rutygr (留言) 2024年7月9日 (二) 13:15 (UTC)[回复]
      • 我想过geoip定位这个方案，但是ip定位数据库需要每个月更新，而且并不完全准确。连维基媒体基金会都放弃了自己的geoip API（否则我就可以利用了）。有一个折衷办法，那就是查询封禁数据库。如果用户目前的IP不再封禁列表中，大概率说明没有开代理，此时我弹窗提示开代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)[回复]

RFDA（及未来成立仲裁委员会后的解任程序）相关探讨

原标题为：动议：冻结社群解任管理人员程序直至仲裁委员会成立或按照当前新主流共识更改RFDA要求

撤回冻结方针动议，下方继续探讨正在讨论的话题。--路西法人 2024年6月14日 (五) 04:04 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

在与最新一期管理人员投票同步进行，有关“管理人员解任在多大程度由仲裁委员会处理？”匿名RFC中，获得不少针对解任程序未来去向的意见，其中存在绝对多数用户同意或不反对任一先行经过调查才能解任的方案，反映社群有非常强烈的初步共识认为解任管理人员前应先经过调查确认是否存在违规事实，由社群部分人的片面之词（甚至是扭曲方针指引及事实的说辞）来发动解任显然已经不再是主流观点。

由此，我谨此动议，冻结社群解任管理人员程序，直至仲裁委员会成立或按照新的主流民意调整RFDA的基本立案要求，确保RFDA仍然符合社群的最新意见和初步共识。当然，“直至仲裁委员会成立”可能还要等比较久，冻结至完成调整RFDA立案要求至满足新主流观点为止。

补充说明：若是在仲裁委员会成立前调整RFDA立案条件，则是参考仲裁委员会机制下“先调查、确认违规事实存在，再开展除权程序”。虽然我可以想像由社群来调查很可能也仍然会被部分人通过扭曲事实扰乱调查，但起码要比现在任意发起RFDA，不用顾不当行为事实是否成立要强。 --路西法人 2024年6月13日 (四) 15:04 (UTC)[回复]

看了一下Wikipedia_talk:仲裁委员会#管理人员解任和其中的问卷，我觉得这个方法是可行的，问卷当中也确实绝大多数人对此抱有期待，期待改变中文维基百科社群有处理的情况，也许在一些保持反对意见的人来看这不是什么好事，但某种意义上是一种进步，社群试图寻找出路。不过有一些要点还是要提醒下
1.仲裁委员会成员受到社群信任
受到信任的成员发出来的报告，报告的性质才不会被因"人"的原因产生变化，试著想想不受信任的仲裁委员会发布的报告，社群大多数人会接受与否。
2.仲裁委员会的意见及报告等社群要接受
这里的接受不需要所有人都接受，只需要做到绝大多数人都接受，注意这不是忽略少数人的观点，只是社群很难做到所有人都接受的事情，在很多事情上必然要做出取舍，如果所有人都要同意才能进行改变，长久下来对社群的发展是不好的。
3.仲裁委员会的在中维当中是处于什么样的位置
处于什么位置很重要，没有确立好，很容易产生争执。
----
最后看完讨论后我倒是有个建议，在"乙"的提案中加入一个前提，确保RFDA讨论是无法有效进行，谁也不让谁的情况再交由仲裁委员会，不需要一开始就交给仲裁委员会，如果社群能够处理，那就不需要仲裁委员介入，一定程度上可以避免争议，毕竟即便是仲裁委员发出的报告，也必然会有一部分的人不认同，如果全权都交给仲裁委员会，社群对仲裁委员会的不满意度会越滚越大，最后反倒吵起来说要把仲裁委员会撤掉，这是我所担心的，以上希望我的建议能为大家所考虑，谢谢。--~~Sid~~ 2024年6月13日 (四) 15:56 (UTC)[回复]
题外话，我建议社群可以的话，请为方针指引设立案例页面，用很明确的方式告诉所有人什么样子的行为与内容违反方针指引是不能做的，指引可能会遇到的例外情况也建议一并列举。--~~Sid~~ 2024年6月13日 (四) 16:28 (UTC)[回复]
此外RFDA我认同可以冻结，但如同上方意见，有些事情或许应该多加考量。--~~Sid~~ 2024年6月13日 (四) 16:36 (UTC)[回复]
注意我认同可以冻结，并不是代表一定要冻结，可以的话我仍建议可以讨论一下，当然我希望是有效的讨论，而不是大家又吵成一团 ( ~~Sid~~ 2024年6月13日 (四) 16:59 (UTC)[回复]
我不认同冻结，RFA和RFDA是维基百科的根基，仲裁委员会是尚未验证的后来之物。至于上方RFDA请求是否成立，诉诸共识或大多数人的共识即可。--桐生ここ★[讨论] 2024年6月13日 (四) 18:16 (UTC)[回复]
  • 管理人员解任在多大程度由仲裁委员会处理？
    • 甲、仲裁委员会按调查事实及方针指引，直接作出除权决定。
    • 乙、由仲裁委员会调查事实并发布管理人员操守报告，确认存在违规事实后，才转交社群决议除权。
    • 丙、仲裁委员会完全不参与管理人员解任。
问卷问题不当，并没有说明是所有RFDA按上方甲乙丙处理，还是只有争议无法在社群解决然后送到仲裁委员会的RFDA案件，按上方甲乙丙处理。--桐生ここ★[讨论] 2024年6月13日 (四) 18:24 (UTC)[回复]
当初问卷内容实际上没有经过社群共识决定（贴出草稿而已，没有正式公示通过），所以问题很多。当初我早就提出质疑，也未获澄清，就莫名其妙拿去安全投票了。还好问卷祇是谘询性质，没有产生什么约束结果。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月13日 (四) 20:24 (UTC)[回复]
(－)反对冻结程序：现有之管理人员解任程序本来就是经共识产生；前述问卷祇是就仲裁委员会之角色提出谘询，没有如何连带处理社群既有程序的要求，故本来与此无涉，至少不应该过度延伸。再说，最近几次案例也显示，原来没有共识基础的解任投票提案，都根本不会通过，甚至一大部分提早就宣布无效，正是彰显社群尚未失能，现行程序运作无碍。另外，现有方针很明确定义管理人员解任条件及必要程序，早也就是所谓“确认违规事实存在（内容不符或原因不合理，可视作申请无效），再开展除权程序”之流程，差别只是在仲裁委员会作为实体机制，调查结果大概可以比较明确，而现有程序中，社群之“确认”较为隐性，反映在支持连署及讨论过程中。现有程序并没有任何常规替代方案（不计紧急解任），或可说共识陈旧而需要修订，然在有具体解方前，显然不应该剥夺社群对管理人员人事的最后决定权。该问卷祇是再一次确认社群长年以来认为有相当理据才能解任管理人员（这也应该是常识），并认同社群拥有最后决定权（而非由仲裁委员会迳行决定）的固有认知（不是所谓“新主流共识”）；社群合资格者（以后的仲裁委员会当然也在内）都能提出解任，但祇有社群后续判断理据确实者，才有机会获得足够支持，这是兼顾维基人发言权利及社群意志实践的作法，自然符合社群共识。此提案属于凭空制造问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月13日 (四) 20:05 (UTC)[回复]
你的主张是现有方针很明确定义管理人员解任条件及必要程序，早也就是所谓“确认违规事实存在（内容不符或原因不合理，可视作申请无效），再开展除权程序”之流程，然而跟你自己的主张相抵触的是，你身为此解任案的第三方管理员，在该用户明显威胁、胁迫其他第三方管理员等不文明行为、连其主张的滥用封锁权限都已经被解封管理员的说法打脸（封锁理由成立只是解封管理员认为不需封锁），更公然声明将不会讨论违规事实成立与否、仅由联署人自行认定沟通无效，完全跟你口中的“必要程序”相抵触的时候，却完全不予阻止袖手旁观，这不就反映社群阻拦不文明、滥提解任的失能完全成立？过往非当时管理员依照方针赋予的权力提前结束解任案还受质疑，岂不是完全反映社群决策能力已完全失能，而仅有少数正常的管理人员维护方针？--路西法人 2024年6月13日 (四) 22:17 (UTC)[回复]

本主题全部或部分段落文字，已移动至#当前解任案效力。

一并回复Ericliu1912及桐生ここ：……（讨论已移动至下方）--路西法人 2024年6月13日 (四) 22:36 (UTC)[回复]
(－)强烈反对：
  1. 仲裁委员会机制尚未验证，其实际效果和操作过程尚不明确。为了一个尚未验证的机制，而冻结现行的有效程序（显然不会因行政员争议性的终止等同无效），无异于舍本逐末。关于仲裁委员会在管理人员解任中的角色，在下同@桐生ここ：目前的问卷问题存在明显的不足。问卷没有明确说明是所有RFDA按上述甲、乙、丙方案处理，还是仅有争议无法在社群解决的RFDA案件按上述方案处理。此种不明确性导致问卷结果不能充分反映社群的真实意见。
  2. 考虑到仲裁委员会的设立、仲裁员选举、立案时长分析、条文讨论等过程显而易见地非常冗长，冻结现行程序更有阻挠现行政策正常运作，即时处理当事管理员问题之嫌。应按照现行规则即时的处理管理员问题，确保社群的正常运作，不受争议管理员可能之危害。
  3. 最后，在下坚决反对行政员可能在任意时间决定冻结RFDA程序的行动。此种争议做法在前次已经引发“官官相卫”“未得社群共识”“违反官僚体系”等严重质疑，损害社群讨论之原则。甚至换句话说，如果仲裁委员会一日不建立，便一日不能追究、及时处理管理员之问题，显然干扰社群监察程序。综上，在下反对冻结。并建议直接滚雪球关闭此讨论。--Gluo88（留言） 2024年6月13日 (四) 20:18 (UTC)[回复]
@LuciferianThomas：还请动议人在此处说明一下仲裁委员会相关事宜的进度。假如进度推进得足够快的话，冻结程序并不一定必要。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 23:13 (UTC)[回复]
目前尚馀总结解任相关观点，并设计出符合尽量多人意愿的解任相关机制后，就能写整个方针，经过社群公投endorse后上路。
就算进度推进得够快，也无法阻挡当前Gluo88公然发表违反解任程序要求的提案，在修订社群解任途径确保程序公义前或仲委会机制上路前，仍应冻结当前程序。--路西法人 2024年6月13日 (四) 23:31 (UTC)[回复]
(！)意见-将这两件事情连结起来成为条件，恐怕有疑虑，是否要开这样的先例？恐怕会带来些副作用与后遗症。会否让既有方针被冻结了？过去，没有仲裁委员会，相关的程序与方针仍然持续进行，就是依照既有方针在做。Wetrace欢迎参与WP人权专题 2024年6月14日 (五) 00:21 (UTC)[回复]
实际上早有先例。过往就是本地用户查核权出了问题，使基金会冻结本地用户查核权。另外，请注意提案中除了“冻结到有仲裁委员会成立”外，还有“或（冻结至）按照调查得出大家的主流观点”（或如某些人否定调查得出的多数意见，也需确保程序公义得到彰显）的选项。--路西法人 2024年6月14日 (五) 02:09 (UTC)[回复]
社群提出与仲裁委员会调查管道实际上仍应并行，这里讨论的祇有前者。因为很显然，仲裁委员会祇能处理于该处提出告诉的案件，不能为整个社群越俎代庖。但我有点担心，新提案在加入仲裁委员会角色同时，还打算一并消灭社群自行提出管道。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 00:33 (UTC)[回复]

本主题全部或部分段落文字，已移动至#仲裁体系下的解任机制。

我跟ATB正在共同筹备有关未来解任制度走向的提案……（讨论已移动至下方）……--路西法人 2024年6月14日 (五) 01:16 (UTC)[回复]
是否无论如何一定要先经过仲裁委员会“确认”？本人认为社群自身仍有迳行运作程序的能力，不用全部经过仲裁委员会审查，祇有拒绝受理才能被动提案。当然，若要避免所谓“民粹政治”，可以提高标准。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:31 (UTC)[回复]
或许我说的不清晰：我在ATB方案上增添的走线是给“社群提交给仲裁委员会”新增了前设，故产生“社群无人提请仲裁（而社群自行解决解任问题）”的走线。若社群自行走解任程序时理据出了问题，自然会有人提交给仲裁委员会；若真的几乎没有争议的，那社群自己走完整个程序都不会需要仲裁委员会插手。如果有人提交，仲裁委员会又认定社群本身在该案已能自行处理（发起除权无明显问题需要仲裁委员会插手），即可拒绝社群请求。不经仲委会提出除权的条件也不需要怎么提高，还是满足最基本的程序公义即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)[回复]
本人认为，现行情况实际上就是这样，也就是社群多数时候能够有效拒绝理由不完备的提案正式投票。那或许是对“事前”部分疑虑较多？也就是欲阻止伊始即直接上客栈“大乱斗”的丑陋局面。不如拿上面刚刚提出的解任案问问，你觉得该案提请有什么可能不满足程序正义之处，毕竟有实际案例较好切磋。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:54 (UTC)[回复]
另外抱歉刚刚太认真看右边那张图，没仔细注意您有提出“比图片多一条”的走线Orz —— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:58 (UTC)[回复]
(－)反对。认为应该在选出仲裁委员会成员，完善相关方针之后再议，RFDA毕竟不是RFA，冻结不会带来什么好处，反而会带来麻烦，比如当前这项解任案，我不会对其进行任何评价，如果直接将之冻结，可能会使相关用户作出其他极端行为。如果其解任违反相关方针，可以直接由行政员决定关闭，而非冻结之。--在下荷花，请多指教（欢迎签到） 2024年6月14日 (五) 02:20 (UTC)[回复]
注意，解任方针是规定任何非当事管理员已可决定关闭，并无限制只能是行政员。另，我理解您反对冻结，若管理人员能及时阻止本次明显有可能要违规闯关的提案，而有关用户持续扭曲管理员言行的行为获确切的阻止，那我将不会继续追求冻结解任。能否请您就上方我和ATB（未在此留言，但右方流程图是他制作的）提出的解任走向有何意见？若我在仲裁委员会成立前参照该走向修改解任方针（就是把仲裁委员会替换成社群整体调查，走先调查后解任的流程，确保未来不能再有同类事情发生，你又是否同意？--路西法人 2024年6月14日 (五) 02:30 (UTC)[回复]
(－)反对，我觉得先等仲裁委员会成立，且已确定相关的流程及规则，再来调整RFDA的作法。不太适合此时冻结解任管理人员的程序。--Wolfch (留言) 2024年6月14日 (五) 02:37 (UTC)[回复]
(－)反对，目前没有数据是否有效，更且仲裁委员会还没成立，成立后，必须先观察，不需马上处理冻结解任管理人员的程序--HYHJKJYUJYTTY（留言） 2024年6月14日 (五) 03:43 (UTC)[回复]
(－)倾向反对：正如Gluo88君所说，“仲裁委员会的设立、仲裁员选举、立案时长分析、条文讨论等过程显而易见地非常冗长”，而这段时间内仍有RFDA的需求。如果现在冻结RFDA，恐怕会导致这些需求难以得到满足。--CuSO4 · 龙年大吉 2024年6月14日 (五) 03:48 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

当前解任案效力

一并回复Ericliu1912及桐生ここ： 虽然题目是针对仲裁委员会，但有关留言中的论据却很多是广泛对社群现象的描述，“社群失能”、“需要评估事实”、“先调查后除权”等显然是广泛的观念。该问卷无法直接影响此动议，但有一定参考价值；所谓“仲裁委员会只处理社群无法解决才送到仲裁委员会的RFDA案件”也几乎是没考虑到“毫无疑问需要除权的操作大概都是走紧急除权”，管理人员解任投票也甚少有不会引起争议，基本上到最后90%的都还得送到仲裁委员会解决（尤其是双方不认可对方的论证的情况），近年每次除权争议更是暴露了社群无法管控用户不捏造事实、不扭曲方针、不无视解任程序的弱点，完全佐证了当前解任程序需要更明确要求调查确认有违规事实再发起除权程序。所谓“比较隐性的确认”反而是“完全没有在发起前就明确确认”的意思，所谓的“确认”通过“联署及讨论过程”，但显然发起解任程序的用户没有也不会考量讨论内容，而是径自联署就打算闯关，联署也无法发表实际的反对意见，简而言之就是“七名无公信力用户自行认定有罪”就开展解任，并不存在真实的“确认”违规事实，这也是近期情况和你的声称所互相矛盾的。

另外，看到两位的反对都是针对仲裁委员会，然而我自己也在动议中表明更理想的情况不是“等仲裁委员会决定”，而是当前就直接明确RFDA的要求。还是那句，虽然题目针对仲裁委员会，但意见的变化是显而易见的，我也没有打算要把那个调查当作“已经存在的共识”来说话而是“参考其意见而发起新的动议”，请搞清楚此提案的意义。--路西法人 2024年6月13日 (四) 22:36 (UTC)[回复]

那可以继续讨论。由于本人支持未来社群提案与仲裁委员会调查两管道继续并行，自然也有检视前者并加以调整之必要。本人也并未否认近年来见得诸多不成熟之解任提案，徒然浪费社群资源。此处只是要指出，不应该因为若干使用者可能脱序或滥用之行为，就要求直接“冻结”社群的民主权利，现在又不是什么非常时期。“提出解任”本身也是程序不可忽略的一部分，无论内容有多么不合理，至少也要先“存在”才能予以驳斥（更何况其实指引已经明确指出，提案伊始即“内容必须详细，指出管理滥权的原因，并根据编辑记录及使用者贡献提出相关证据”，理论上不满足即自始无效）；即使往后要组织某种详细“调查”，也是要先有人“提出”或“申请”管理人员可能的滥权行为，不可能凭空造成。所以本人并不理解过度夸大此一阶段乱象的用意。另外，若既已为满足前述有效条件之提出，则此后之辩论，维基人间存在观点差异亦实属正常；虽不排除确实有“无脑支持”者（实际上任何站务程序都有），但迳行认定联署是“无公信力用户自行认定有罪就开展解任”，则恐怕有歧视若干社群参与者及菁英主义思维作祟之嫌。照这种说法，所有人可能都是“无公信力用户”，管理员解任申请不就变成“无公信力用户法庭”。不过如此一来倒是大概可以理解，为什么那么坚持要走以仲裁委员会迳行裁决这种路线。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 00:07 (UTC)[回复]
一般用户不经任何选举，公信力是undefined（这种“没有公信力”）。仲裁委员整体有一定公信力。
另，虽解任案未正式发起，管理员未能按解任方针取缔，但他能预告将会作出违反程序的行为，管理人员也可明确告知违反程序的提案将会被截停，并呼吁其遵守程序，在已知会发生的问题发生前直接堵截，而不是等到问题发生才做事。--路西法人 2024年6月14日 (五) 01:29 (UTC)[回复]
若方针持续遭到滥用、扭曲，且情况非常明显，如果放任不管也会造成明显大的伤害（如除权方针），那么自然就该冻结程序，这好比现实中正在提出释宪的法案可被临时暂停执行；正如如果未来社群选出的仲裁委员会go rogue，放任不管也会造成明显的伤害，那么自然就该冻结程序。--路西法人 2024年6月14日 (五) 02:18 (UTC)[回复]
本人不认为冻结整个程序符合比例原则。所谓“持续”，也不必然。况且就该案而言，当事管理员作风问题乃长久以来众所皆知，也引起诸多争议。提请解任本身或许过当，但其来有自，当中所隐含的问题并非全然无探讨之可能。我们管理员是有权力的一方，本来就应该赋予对造相对多话语权，易言之即容许较大限度之发言自由，这本来也是他们唯一可以“制衡”管理员行使职权的办法。本人不认为该案之提出者在“滥用”解任程序，至少也不应该是扩大到其他个别案件的理由。另外，现行解任程序少数的大问题，就是虽然指出要“沟通无效”，但很多时候当事管理员坚持立场，就很容易构成，然后就是客栈提案一片混乱。本人认为就条文相关部分讨论如何清晰定义（尤其是什么样的内容理由为“有效”），且“同时”兼顾当事管理员及提请人权益，要比冻结整个程序实际多了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:38 (UTC)[回复]
以上讨论分拆自上方讨论。--路西法人 2024年6月14日 (五) 04:02 (UTC)[回复]
Gluo88以威胁的语气试图阻拦其他管理员正常行使方针的语气，并在其本身对管理员行为的扭曲理解下营造管理员滥权的不实情形，并可以从其语调看得出不会接受任何解释。反观苗君仍在积极解释、回应或回驳观点，也通过讨论、交涉获得解封Gluo88的蓝桌君出来说话，表明不认同Gluo88对苗君的指控。这些反映苗君确实有在积极沟通（回驳观点也是沟通的一种）。反而是Gluo88的态度表明拒绝接受一切解释，自己拒绝沟通并持续扭曲事实，自行制造沟通无效的条件，这显然不是解任方针的本意。--路西法人 2024年6月14日 (五) 04:02 (UTC)[回复]
我刚刚才发现，解任投票根本还没正式提出，那就更不用为此谈相关程序问题了吧？该话题现在已经变成实质沟通之处。唯一认同者，即在此情况下，当事人不宜迳行提出解任。若未能如愿，而届时社群能有效应对，那亦可再度证明解任程序运作有效。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 04:20 (UTC)[回复]
否，我上面有指出：虽解任案未正式发起，管理员未能按解任方针取缔，但他能预告将会作出违反程序的行为，管理人员也可明确告知违反程序的提案将会被截停，并呼吁其遵守程序，在已知会发生的问题发生前直接堵截，而不是等到问题发生才做事。--路西法人 2024年6月14日 (五) 04:29 (UTC)[回复]
我不太理解，难道质疑管理员亦不可？他虽如此“威胁”，但未付诸实行之前，无论如何实不可以“现行犯”论之。若社群多人持续表达关切意见，他也并非不可能拒绝“听劝”。此外，这毕竟也与解任投票本身没有直接关联（因为解任投票尚未启动，不构成程序问题）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 06:10 (UTC)[回复]
不是不能质疑，而是不能以扭曲方针的理解来质疑管理员，连给Gluo88解封的管理员都认为苗不存在扰乱或诽谤，而他自行判读管理员解封就代表对其的封锁是诽谤、是滥权，这不就反映观念上就有问题，问题并非出自于被发起除权的一方？Gluo不断合理化自己的行为，而苗、我甚至是蓝桌都一再指出Gluo88先前行为并非妥当（只是蓝桌认为不至封锁），这不叫质疑，而是扭曲方针及事件事实而诽谤管理员吧。--路西法人 2024年6月14日 (五) 09:38 (UTC)[回复]
他可以提出质疑，社群则可以适当支持或反驳之，这是共识形成的正常过程。在此案中，大概认为理由不充分者居多，是否成案尚有商榷馀地。本人也不好评价个别管理员作风“惹人怨”的程度，但明显可见并非孤例，故此处比起“带有情绪而冲动质疑”之类形容，“诽谤”一词或需要慎用。当然也可能是我对此类批评管理权限行使问题态度向来比较“宽容”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 13:05 (UTC)[回复]
上方解任案成功且合规立案的可能性之低，我已无意愿再参与讨论。不论是原则上还是方针条文上，都没有条文能支持他做的事，如果他还是正式发起解任案，我再请求其他管理人员制裁有关行为即是。--路西法人 2024年6月15日 (六) 00:59 (UTC)[回复]
“以扭曲方针的理解”的操作空间过大，并非一个适合的判定标准，不然大家互相指控其他人的理解“扭曲方针”还得了。Sanmosa Snipe–Clam Grapple 2024年6月15日 (六) 00:58 (UTC)[回复]
每个方针都有背后的大原则，如果是对方针条文理解有误的人，都难以推翻背后的大原则。明知自己对方针条文理解与方针背后原则和用意冲突的情况仍继续坚持的，那就只能是扭曲方针了。--路西法人 2024年6月15日 (六) 01:02 (UTC)[回复]
我的意思是，真到了我说的那个情况，那个人是否真的“扭曲方针”还重要吗？我最担忧的事情是大家互相指控其他人的理解“扭曲方针”的时候，大家的指控实际上都是成立的，因为根本没有人（在任何意义上）“正确理解方针”。Sanmosa Snipe–Clam Grapple 2024年6月15日 (六) 07:53 (UTC)[回复]
同意。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月15日 (六) 18:02 (UTC)[回复]

仲裁体系下的解任机制

我跟ATB正在共同筹备有关未来解任制度走向的提案，当中不会完全汰除社群自行发动解任的途径，只是会有一定改动确保程序公义。右图是ATB建议的走向，而我的想法是再向上加一条走线：社群发起解任后，用户只能在投票发起前才能提交证据请求由仲裁处理，仲裁委员会在七日内需决定是否受理（条件：初步认为解任提案理由有问题）并展开详细调查。由于解任走SecurePoll似已通过，准备SecurePoll也需要时间，多等七天不会有什么大问题。拒绝受理或投票发起后不能由仲裁截停（已放弃受理权）；因拉票等因素而截停则不是RFDA仲裁机制了，而是一般用户行为仲裁。这样能确保仲裁不会被过度使用之馀确保未来解任程序能达到程序公义。补充：若社群提交给仲委会的理由跟发起除权的理由太不同，则自然不能视作仲裁委员会已放弃调查权，为防被滥用规则而挟带不当理由闯关。--路西法人 2024年6月14日 (五) 01:16 (UTC)[回复]

是否无论如何一定要先经过仲裁委员会“确认”？本人认为社群自身仍有迳行运作程序的能力，不用全部经过仲裁委员会审查，祇有拒绝受理才能被动提案。当然，若要避免所谓“民粹政治”，可以提高标准。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:31 (UTC)[回复]
或许我说的不清晰：我在ATB方案上增添的走线是给“社群提交给仲裁委员会”新增了前设，故产生“社群无人提请仲裁（而社群自行解决解任问题）”的走线。若社群自行走解任程序时理据出了问题，自然会有人提交给仲裁委员会；若真的几乎没有争议的，那社群自己走完整个程序都不会需要仲裁委员会插手。如果有人提交，仲裁委员会又认定社群本身在该案已能自行处理（发起除权无明显问题需要仲裁委员会插手），即可拒绝社群请求。不经仲委会提出除权的条件也不需要怎么提高，还是满足最基本的程序公义即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)[回复]
本人认为，现行情况实际上就是这样，那或许是对“事前”部分疑虑较多？也就是欲阻止直接上客栈“大乱斗”的丑陋局面。或许拿上面刚刚提出的解任案问问，你觉得该案提请有什么不满足程序正义之处，毕竟有实际案例较好切磋。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:54 (UTC)[回复]
  1. Gluo88提出苗君滥用封锁的证据，光是与给他解封的管理员的理解已有显著落差。提案人迳自认定管理员滥用权限或封锁有瑕疵，而未经审视方针是否禁止某些行为，违规事实并不明确，解任案则不应成立。
  2. Gluo88对苗君诽谤Lanwi1的指控显然存在误差，苗君作为当年事件的当事人，除了当时短时间内就补充提供了公开讨论的记录外，其当年作为用户查核员能将Lanwi1的公开口供跟技术资讯比对，亦可作为其指控或怀疑的证据。有证有据者的合理怀疑显然难以构成诽谤，反观Gluo88在他人（我）指出苗君确有提供证据后，选择性无视并谎称“没有证据”（证据已经提供了，还有一些是苗君显然不能公开的），还在毫无证据的背景下相信Lanwi1的说辞，用以指控苗君诽谤，乃是明显的拉偏架，“诽谤”指控也难以成立。
  3. 苗君在讨论中积极解释、说明其行为，也通过交涉获得解封Gluo88的蓝桌君的认同；反观Gluo88全然不接受任何解释，并拒绝一切依照方针的规范及通用理解的观念，显然并非管理员所致之沟通无效（而是提案人拒绝沟通），不能成立解任案沟通无效之要件。
  4. Gluo88在一开头就声明将会发起明显违反方针（不审核是否构成解任条件，只凭其自身及联署人认定），亦有威胁其他管理人员不可执行方针赋予的权力（终止不当解任案），显然严重侵犯程序公义。
光是这些，若仲委会已成立，以上程序问题已经足以将此由社群发起的解任案提交仲裁委员会处理了。--路西法人 2024年6月14日 (五) 04:20 (UTC)[回复]
  1. Gluo88提出苗君滥用封禁的证据，光是与给他解封的管理员的理解已有显著落差。在管理员最初已认定封禁查封理由欠缺，这是事实。也尊重审核管理员认为程度不到罢免的理念。涉事管理员的理解与本人的理解（及其他用户的理解）也不相干，除非诉诸权威。
  2. Gluo88对苗君诽谤Lanwi1的指控显然存在误差，苗君作为当年事件的当事人...通篇仍然持续为当事人未经认证（CU、CA）臆测伪证据发言，并忽略当事人已遭受严重精神重创的事实。打个不恰当的比喻，如果一个强奸受害者侮辱强奸犯，然后某个认说她犯了侮辱诽谤罪，她的言行客观上是不妥的，但这种检讨受害人的行为更是拉偏架，扭曲一般人道德理解，态度可谓令人发指。
  3. 苗君在讨论中积极解释、说明其行为，也通过交涉获得解封Gluo88的蓝桌君的认同...先不论在下几乎已全面驳斥阁下及涉事用户谬论（并且您除了诡辩，显然无法正面回应；另一位也没有能力全面回应在下的质疑）只能是个人意见，不代表我认同（及其他潜在用户认同），照@LuciferianThomas这种伪逻辑，在下尝试总结一下：大概就是只要当事人不断“发言论证沟通”就不构成“沟通无效”（并将其归责于提案人及联署人死活不认可），上个这么声称及类似的案例已被基金会制裁了。
  4. Gluo88在一开头就声明将会发起明显违反方针（不审核是否构成解任条件，只凭其自身及联署人认定），亦有威胁其他管理人员不可执行方针赋予的权力（终止不当解任案）... 我并没说不审核，而是交由联署人审核认定（本来现行方针就不用一致共识确认），这恰恰是符合过往惯例标准的原则（《方针》政策指出，大部分被人们接受的惯例不会立即被写上。方针只是明文的惯例标准。）反观前次管理人员的所谓“决定”已被广泛质疑“官官相卫”“违反官僚主义”“凌驾讨论”“无权确认”“不避嫌”这种藐视社群的决定，恰恰是侵害程序公义的行为(“管理员没有任何高于其他用户的特权，唯能实现社群讨论所得的共识“)，更应该就行政员争议行为交到仲裁委员会裁决，以正视听。
  5. 其实面对您的指控，在下本来是不打算留言的，但在下考虑到您并未停止有关涉嫌扰乱及游戏讨论行为，甚至发出明显的威胁，呼吁第三方管理员制裁在下，才不得不在此回应。此外，这个发言涉嫌“针对特定受众”基于“推销立场”的拉票行为。根据行政员前次所谓认定，“RFDA是本站大事”浏览量极高，所以已经构成大幅张贴效果。考虑到相关留言通篇粗亮红字体，还有可能构成情绪勒索骚扰用户（与第三方管理员）。副知在上次解任时发起讨论“拉票”的@魔琴阁下就此发表看法。
以上可合理确认LuciferianThomas君的所谓“程序问题”，无一例外其实都站不住脚。即使仲裁委员会成立，诸位仲裁员面对阁下指出的“程序问题”，在仔细审阅相关讨论后，除了给您发不应在讨论中，使用过多特效使别人感到骚扰的提醒或警告外，基于方针的正常理解相信也只能一笑而已。
在下请@LuciferianThomas君停止为涉嫌袒护涉事用户试图干扰本次Rfda的行为，并期望根据在下对阁下提出的质询，检讨当事管理员及自身问题，作出有益讨论事情。--Gluo88（留言） 2024年6月16日 (日) 01:06 (UTC)[回复]
我不好说其他人对于拉票是怎么定义的 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月16日 (日) 02:07 (UTC)[回复]
另外抱歉刚刚太认真看右边那张图，没仔细注意您有提出“比图片多一条”的走线Orz —— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:58 (UTC)[回复]
这个我自己也没说清楚。--路西法人 2024年6月14日 (五) 04:22 (UTC)[回复]
大致同意上述图片的内容。--在下荷花，请多指教（欢迎签到） 2024年6月14日 (五) 04:34 (UTC)[回复]
简而言之，我反对把像台湾选总统一样的直接民主改成香港选特首一样的代议民主。香港特首怎么选，我觉得你也知道。--桐生ここ★[讨论] 2024年6月14日 (五) 07:22 (UTC)[回复]
同意桐生的想法。--千村狐兔（留言） 2024年6月16日 (日) 01:43 (UTC)[回复]
右方为添加了我所说的比ATB版本多一个走法的机制，Ericliu1912及Hehua可以参考看看如何。除了RFDA，其实多数其他仲裁调查都可以比照处理。--路西法人 2024年6月14日 (五) 05:59 (UTC)[回复]
看起来主动权是否仍在仲裁委员会？因若每一案总是有人要求受理调查，那程序上便实质造成社群直接管道不得通。管理员解任争议向来大，可预见会有不少辩称个案程序不符合方针者。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 06:11 (UTC)[回复]
是也没错，我甚至是预期未来绝大多数的仲裁提案最终必须经过仲裁委员会的手一次，但既然管理人员解任社群没办法自己处理（真的有问题的时候，还是得仲裁介入，总不能坚持不让仲裁处理违规事项吧？），那把这个程序几乎完全交给仲裁是可以理解的。我是不反对设置反联署的机制（联署改交仲裁委员会），但送往调查的门槛会要比直接送投票的要低一截（例如送往调查需5人联签，解任联署门槛提高至10人）。
不过起码这里保障了多数情况下社群仍保有投票除权的权力，也确保仲裁委员会仅能在真的有问题的时候才介入管理人员解任程序（在社群能自己处理及未获解任程序中的合理质疑的情况下应拒绝受理），但也确保在必要情况下由仲裁委员会自行行使去除管理人员权限的权力。（所谓必要情况，指滥用傀儡等所有可致（非短期）封锁或禁制的违规情况）--路西法人 2024年6月14日 (五) 06:58 (UTC)[回复]
如此怕是有游戏规则之嫌，毕竟祇要提出质疑，就可以强制将讨论拖入仲裁程序，也很难预见仲裁委员会不会因为期望有案件，而对此倾向“照单全收”之类。此外，本人认为仲裁委员会试行第一任期期间，不宜移交过多权力。希望还有某种折衷或过渡方案供社群选择。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 12:59 (UTC)[回复]
不过，考虑到社群或有希望仲裁委员会针对此类提案提供调查报告，若祇是请求类似国际法院就议题提供谘询意见之类，而不直接跳过其他社群既有流程（即最右边那条路线），那本人并不反对。其区别在于是仲裁委员会是主动受理调查，还是基于社群需求被动提供意见（用词或有差异，但总之应该是这意思）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 13:09 (UTC)[回复]
回应第一则留言：
  • 很难预见仲裁委员会不会因为期望有案件，而对此倾向“照单全收”之类：仲裁委员会在接获针对已经发起的RFDA案请求时，并非单单议决“是否受理”，仲裁员公开议决是否受理案件时还必须指出受理或拒绝理据，也不能空口无凭说“社群已无法通过社群渠道解决”，而是要提供论证。究竟是怎样无法通过社群渠道解决，究竟是否非当事的管理人员采取行动即能解决，都是必须论证的点。当仲裁委员会收到直接提请调查管理人员行为之时，条件同样适用，这情况下提出调查的人也是需要论证为何不通过社群解任程序（例如：提出解任一方论据不当，可预期他们走社群解任必然会造成问题）。仲裁委员会就算是“想接受案件”也要写个合理到不行的理由，但有合理的理由就代表真的要接受案件了。
回应第二则留言：
  • 你的理解大致正确，但必须指出在“已经有明显必要解任”、“紧急解任”或“根本不成立”等情况下，则不会发起任何解任投票，而直接由仲裁委员会作出决定。你所说基于社群需求，这个就很难定义什么叫“社群需求”了，究竟是有人联署发起仲裁，还是需要有共识，都会有人不同意；后者在已经吵得不可开交的情况下显然已经难以实行，所以唯有通过联署的方式发起仲裁以确保真的是“社群”需求而非“个人”需求了。
--路西法人 2024年6月15日 (六) 00:48 (UTC)[回复]
据我所知，社群共识不希望仲裁委员会作出迳行除权决定。那紧急除权外的“已经有明显必要解任”是什么意思？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月15日 (六) 18:01 (UTC)[回复]
说过了啊。--路西法人 2024年6月17日 (一) 01:53 (UTC)[回复]
这还真是没看清楚（ —— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 17:58 (UTC)[回复]
感谢提及，我个人基本(＋)支持此方案。--在下荷花，请多指教（欢迎签到） 2024年6月14日 (五) 07:55 (UTC)[回复]
我认为此方案可以。--~~Sid~~ 2024年6月14日 (五) 08:36 (UTC)[回复]
支持这个版本。--Rice King 信箱 · 留名．边缘人 2024年6月14日 (五) 11:25 (UTC)[回复]
(＋)支持此一版本。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年6月14日 (五) 11:41 (UTC)[回复]
我问个问题，如果RFDA只有一人认为不符合方针，即使整个社群都支持联署，也必须进入仲裁委员会程序？这个有人认为的有人是多少人？--桐生ここ★[讨论] 2024年6月14日 (五) 13:03 (UTC)[回复]
这自然是需要"讨论"的，当然也有个更简单的方法是让认为不符合方针的人自己送，仲裁委员会看到这种情况自然会拒绝请求，有个坏处是会让仲裁委员会很累就是，如果要采用，建议赋予仲裁委员禁止滥用仲裁的人提出仲裁请求的权力。--~~Sid~~ 2024年6月14日 (五) 14:09 (UTC)[回复]
如我上方留言所述，确实可以新增反联署的概念，或为五名符合人事任免投票权的用户联署，或为最低限度一符合人事任免投票权的用户加一非当事管理员共签请求仲裁。一个人（尤其是当事管理员本人）即可发起进入仲裁程序也还真的门槛过低。--路西法人 2024年6月15日 (六) 00:29 (UTC)[回复]
如果要改革的话，我觉得应该加入反联署过程才能被仲裁委员会受理，不然就像你说的，当事管理员反对然后就进入仲裁就有点不合适了。--桐生ここ★[讨论] 2024年6月18日 (二) 19:23 (UTC)[回复]
原则上(＋)支持，太需要了。--Shwangtianyuan 不忘初心 牢记使命 2024年6月14日 (五) 16:13 (UTC)[回复]
  • 个人意见是发表调查报告后，解任与否应公付社群决议。即便调查报告认为提请解任是多么错误，社群应拥有解任事宜的最终裁量权。-千村狐兔（留言） 2024年6月16日 (日) 02:25 (UTC)[回复]
    此前社群谘询性投票已明确认可这点，我相信应该会体现在最终方案。没有的话再来商榷。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月16日 (日) 04:22 (UTC)[回复]
    大致上认同这个观点，毕竟不能排除调查报告出错的可能性（是的，请质疑一切的权威），但我的个人意见是如果调查报告的结果是管理人员因属于有必要的情况或紧急情况而被直接解任，这并不属于社群的裁量范围。换言之，我认为如果调查报告认为这不属于可以解任的情况，但社群形成了显然相反的共识时，无论调查报告是否出错，社群依旧可以在有相当共识的情况下发起解任投票，但其他方面我认同File:ArbCom de-admin procedure chart (LT version).png的表述。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 12:09 (UTC)[回复]
    “真有必要”就直接解任了，没必要再提出调查报告，祇需要简短说明。“真有必要”的情况应当已经很明确，正常人都看得出来（常识判断），否则就不能说是“真有必要”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 17:57 (UTC)[回复]
    实际上就连上面举例的滥用傀儡，我也不觉得必然适用直接解任，至多是调查期间允许暂时褫夺管理权限。因为这终究取决社群对管理员的信赖，说不准社群愿意原谅过失，那凭什么需要由仲裁委员会擅自代为“处刑”呢？由于已经有真正最后手段“紧急解任”，我甚至不觉得有必要给予仲裁委员会所谓“有必要情况”除权的选择。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 18:02 (UTC)[回复]
    管理员不会有其他用户没有的豁免权，管理员做出应受非短期(全站范围)封锁或禁制的行为理应受与一般用户相同的处理，而受(全站范围)封锁或禁制期间管理员本身就无权参与社群事务。近期受过封锁的用户本来就不能参选管理员，这个相比其他“建议条件”而言更几乎是“必然需要符合”的要求，也是社群的基本期望。因严重违规而致非短期封锁或禁制行为的用户本来就不适任管理员，这种情况的解任是弹劾而非罢免。社群有权在被弹劾用户接受封锁及一年冷静期后经重新选举上任管理员，但显然有过错的就不是“可以被社群原谅”的行为。用户单单因管理员身份而被“原谅过失”显然变成获得其他用户没有的特权。--路西法人 2024年6月19日 (三) 02:02 (UTC)[回复]
    本人早已指出，调查期间仲裁委员会认为确有必要时，可暂时取消当事人之管理权限，至于最终处份问题则完全是两回事；既然说“管理员做出应受非短期封锁或禁制的行为理应受与一般用户相同的处理”，那解除权限方针明确指出“当管理员封锁任何一位依从权限申请方针获得权限的使用者时，请同时提报，让其他使用者复核考虑是否为之除权”，而管理员就可以被仲裁委员会迳行除权了？若真“理应受相同处理”，那此等失职行为，就虽自然成为得提出解任（“复核考虑是否为之除权”）之“理由”，但并不总是直接等于“结果”。又此种“复核”之对象一般而言是社群整体，不是仲裁委员会（部分例外既已言明于上述草案，此处不赘述）；社群有权就管理员解任案成立与否予以最后决定，此时又可参考解除权限方针提到的“蓄意犯规”、“草率行事”、“执于己见”、“没有悔意”等要件，构成对管理员与其他权限持有者一视同仁之量尺，达到所谓“理应受与一般使用者相同的处理”。
    解任乃最终手段，请与社群事先商榷什么情况值得如此做，不要自己定义“本来”、“显然”、“特权”、“不是可以原谅的行为”，仿佛理所当然一般。尤其社群已明确倾向反对由仲裁委员会迳行处份失职管理人员，是以若一定要置若干例外，依据比例原则及法律保留原则（当然本站政策不是法律，但基本观念类似），理当以明文列出，且或可能严格限缩处理。又即使如我个人意见上述如此，也没迳行强求或压制谁去接受，祇是提出供社群参考，我想任何人的意见都一样；假使认为“应受非短期全站封锁或禁制的行为”可以由仲裁委员会迳行除权，那就是首先要由社群确定是否同意此等条件，或初步予以修正（如不包含某些“禁制”情况、有权经社群额外同意排除某些意外情况个案之类），然后还要厘清所谓“非短期”具体指什么、又此种行为应可能包含什么情况（如上方提到“滥用傀儡”，具体是多严重之类）等细节，最后才得凝聚为真正可行且符合程序正义之共识（以上是随意举例）。不是提一些模棱两可的条件顺溜过去就行。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月19日 (三) 17:52 (UTC)[回复]
    考虑一些过往案例，本人目前认为所谓“有必要情况”祇有遭遇值得受不限期封锁之行为。受如此重大处份且未能申诉成功之管理员，亦往往会遭社群事后除权，甚至多数是紧急除权。本人认为，仲裁委员会在此种情况下裁决迳予除权，并不逾越社群过往实践缔造之共识及一般常识。若有其他认为可适用情况，还请社群具体提出。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月19日 (三) 18:20 (UTC)[回复]
    “因为这终究取决社群对管理员的信赖”不全然，这也视乎他本身造成的危害的严重性，这不是擅自代为“处刑”，而是避免社群擅自慷受害者之慨。这样说：就算你原谅了一个杀人犯，他还是一样要被判死刑或终身监禁，不能说因为你原谅了而直接认为他无罪。Sanmosa 蚌埠 2024年6月19日 (三) 05:55 (UTC)[回复]
    社群是本站最高“政权机关”及一切事务最终决定者，本人认为真有共识（大前提）的话要“慷受害者之慨”也行；反过来说，如果仲裁委员会经审酌决定“慷受害者之慨”，阁下又该如何应对？何况在本站，所谓“极刑”不过是禁止编辑，且除极少数社群不可抗力情况（如基金会行动、全域禁制等）外，没有真正不可逆的处份，此处完全不宜援用现实司法情况。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月19日 (三) 17:52 (UTC)[回复]
    真要用司法来比拟的话，仲裁委员会可以“限制迁徙”甚至“拘禁”，防止“嫌犯”继续迫害他人，也可以提出“证据”（此处指调查报告，并非报告本身采用的证据）给予“法官”（社群）参考；仲裁委员会在其他管辖内案件可能自己兼任“法官”，但就管理人员解任议题而言，最终判决“有期徒刑”（本站没有“死刑”）者则仍是社群，不是仲裁委员会（所以说为什么不应该用现实司法比较，因为太强行硬凑了）。社群已经彰显意志，不打算将仲裁委员会打造为非常之国民公会。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月19日 (三) 17:55 (UTC)[回复]
    我正是考虑到如此情况才会有上方“如果调查报告认为这不属于可以解任的情况，但社群形成了显然相反的共识时，无论调查报告是否出错，社群依旧可以在有相当共识的情况下发起解任投票”的提议，这已经足够救济仲裁委员会“慷受害者之慨”所造成的损害了。虽然我个人比较倾向于权限较大的仲裁委员会，但从我上方的留言可见，国民公会形态的仲裁委员会也不是我支持的东西。Sanmosa 蚌埠 2024年6月20日 (四) 14:25 (UTC)[回复]
    反过来说，岂不亦适用？可再商讨。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月22日 (六) 05:24 (UTC)[回复]
    这样说吧，我既不希望一个被架空的仲裁委员会，也不希望一个被架空的社群，我期望的是仲裁委员会与社群旗鼓相当、能相互制衡，所以如果我没有理解错你说的“反过来说”的意思的话，这正是我自己期望的效果。Sanmosa 蚌埠 2024年6月23日 (日) 14:52 (UTC)[回复]
    另外，我同意有关社群就与仲委会意见相左时，可重行循联署管道形成共识发起解任案的意见。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 18:05 (UTC)[回复]
    (！)意见：同Eric Liu，此版本和上一个版本不同，缺少仲裁委员会拒绝后社群自行形成共识的流程，建议增加此流程。--桐生ここ★[讨论] 2024年6月22日 (六) 08:15 (UTC)[回复]
    直接沿用既有联署流程即可。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 06:48 (UTC)[回复]
    (！)意见：个人路过，仅额外表达身为用户的意见，恕不参与后续和在此乱入。个人建议若有共识将类似仲裁的机制设立专属页面或区块，让有意愿的用户视案件试行参与，或若产生共识，视实际需求再看后续是否执行即可；在尚不具备特殊权限的情况下试行，若往后具备良好的实际效益和需求，以此另外举行相关选举也或无不可。然而我认为仲裁权的施行争议似乎仍有讨论空间，且难以比照现实生活的机制，光是“仲裁”本身具备的效力就极具争议，且定位难明（现实中的仲裁可能具备法律效果，但仍有法律管道作为当事人不服的救济机制；国际争端那种姑且不论），而如果只具备所谓“调查权”，再交付社群议论，其实与当前机制相去不远，直接交由社群议论或许更直接，了解议题或有兴趣的人自可参与，与是否具备权限亦无关；此外，若仲裁员本身遭到当事用户欺瞒拐骗又该如何？势必仍需另寻管道明查暗访、审慎查察等等，事实上这个过程和一般用户参与讨论相去不远。而一个连具备实际特殊权限的管理员也无法维持秩序的社群，特别选出负责厘清事情的用户，若再产生其他事实认定上的争论，又或者其他用户若有不服，救济制度何在？仲裁效益何在？又或是仲裁委员因仲裁无方、标准不一、效果不齐，是否又衍生其它争执呢？是否最后仍须交付基金会呢？而若绕回社群议决，一个不具实际决定性效果的权限是否可能绕一圈后又回归争执呢？而若具决定性效果，该具备何种权限，或许仍须回归实际需求，如果其实不太需要的话，也可能根本不需另行规划。这样看来，“仲裁”似乎有点像是“监察权”，但现实中的某些监察权亦已为人诟病颇多（笑）。以上并不代表不应规划此类机制或权限，而是此制度的施行就目前社群现况、投票及讨论结果来看，众人对于社群事务和机制中，强调“制衡”所带来的公平性和安全感，似乎仍远胜对于“决断或判定”所带来实际效益的信任和需求。既然如此，真正需要详加调查讨论的问题，终须回归社群决议，而议事的过程个人认为这仍属社群自制力和是否具共同目标的根本问题；至于管理员用权的“认事用法”问题，我认为则回归管理员所具备权限性质的长期命题，多数争议亦往往来自于此，而当前诸多网路平台似乎也是如此（警察＋判官，但好像也都是这样）。对于个案，个人倾向让具管理经验的行政员直接判断特定管理员是否于特定案例滥权或用权过当，以此提供实务意见，社群再行议论，这和诉诸社群民意类似，但可能可以尝试结合试行机制看看。目前是否需直接特别设立选举产生的特殊权限，个人倾向斟酌。--Kriz Ju（留言） 2024年7月1日 (一) 14:31 (UTC)[回复]
    支持Manchiu的意见，解任与否的决定权应在社群，仲裁委员会在解任案中不应拥有最终决定权，其作用更应该是处理私密资讯和提供对证据的调查报告以供社群作出决定。当然我不反对仲裁委员会可以执行紧急除权等极为特殊的事态。另“仲裁委员会调查期间冻结案件”应明确规定冻结时间。--🎋竹生🎍 2024年7月7日 (日) 02:28 (UTC)[回复]

临时暂停特权机制

I'm going to make a proposal about temporarily desysopping, when a sysop, oversight or checkuser are being investigated, their priviledge may need to be temporarily removed by Arbcom to prevent further disruption if necessary. And shall not obtained again unless the investigation is over. Especially, for VRT and the ones who have signed NDA, Wikimedia Foundation need to be noticed if neccessary to remove such priviledge. I'm a little bit tired but good luck, god bless you.---Lemonaka 2024年6月14日 (五) 13:08 (UTC)[回复]

我准备提出一个关于暂时取消系统管理员的提案，当系统管理员、监督员或检查用户正在接受调查时，Arbcom可能需要暂时取消他们的权限，以防止在必要时造成进一步的干扰。除非调查结束，否则不得再次获得。特别是对于 VRT 和签署了保密协议的人，维基媒体基金会需要注意是否有必要取消这种权限。我有点累了，但祝你好运，上帝保佑你。---Lemonaka 2024年6月14日 (五) 13:08 (UTC)[回复]

@Ericliu1912 @LuciferianThomas -Lemonaka 2024年6月14日 (五) 13:11 (UTC)[回复]
仲裁委员会大概可以视情况决定是否技术上暂时取缔管理员行使权限。不过本地相较于英文维基百科，尚没有直接取消管理员系统操作权之权力，本人认为这代表两地社群习惯差异，故制度移植时亦应有本地化措施以为反映（例如缩减可取缔权限之案件种类等）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 13:15 (UTC)[回复]
我觉得可以提出紧急冻结机制，类似紧急除权，比方说监督员、界面管理员等重要权限，正在调查期间社群或行政员认为必须先除权以保证安全，则先除权，等待调查结果再恢复或维持除权。--桐生ここ★[讨论] 2024年6月14日 (五) 13:21 (UTC)[回复]
重点在于“无罪推定”（虽然应该少援用司法概念）。除上述情况外，本人认为唯有涉及管理权限行使可能损及当事人权利，或妨碍案件之进行，或有正当合理之依据认为案件进行中不适宜持有权限者，方得暂时除权。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 13:40 (UTC)[回复]
这有个问题是谁来判定会比较好，Arbcom判定社群会有人不认同，社群自己来讨论要不要暂时除权又会因为争执而不了了之，一个很尴尬的情况。--~~Sid~~ 2024年6月17日 (一) 09:08 (UTC)[回复]
Sid说的有道理。仲裁委员会只是是少数人的决定，社群大多数人的共识才具有公信力。--桐生ここ★[讨论] 2024年6月22日 (六) 08:17 (UTC)[回复]
这种观点我真的不认同。仲裁委员会是社群选出来的，细节是由社群敲定的，最终的提案也是要由社群通过的。在这样的程序下，仲裁委员会的决定必须具有公信力。如果说决定不具有公信力那么要仲裁委员会干什么？
我选择甲的原因也同理。如果委员会需要调查再由社群讨论，那搞选举、审议这些程序完全没用。完全可以找几个看起来社群信得过的人，组成一个“非官方”的委员会，也可以调查。
再往普通解决行为争议来看，即使无法除权管理员，委员会一定需要有封禁，设置编辑禁制的能力。设置委员会就是为了一个“最终解决方案”。如果例如ANM上面的案子十分棘手，以至于没有管理员愿意去处理，那么就去找委员会。委员会基于社群方针来判断事务是否使用管理工具来处理，而不创建新的方针。如果说委员会在处理普通用户争议的时候也要“推荐”管理员如何处理，实则无权的话，那这个委员会不要也罢。--0xDeadbeef (留言) 2024年6月25日 (二) 11:54 (UTC)[回复]
说到底我怀疑社群能否选出这么一个委员会。--桐生ここ★[讨论] 2024年6月25日 (二) 13:33 (UTC)[回复]
我保持乐观，但我的想法是，与其将委员会的权力一砍再砍，就为了社群能够选出一批人，结果选出来也不能改变社群生态，不如保留委员会权力，社群在知情委员会权力的情况下选，选出则能对社群环境有一定的影响力，选不出就当失败。--0xDeadbeef (留言) 2024年6月25日 (二) 17:39 (UTC)[回复]
@0xDeadbeef What about A/B group? They can scrutinize each other. -Lemonaka 2024年6月26日 (三) 03:46 (UTC)[回复]
Not sure how well that will work in practice, but maybe worth a try if people want to.--0xDeadbeef (留言) 2024年6月26日 (三) 07:31 (UTC)[回复]
无论是ArbCom还是社群讨论处理，我认为可以先讨论当Arbcom决议有人不认同时社群要怎么解决，当社群讨论发生争执导致讨论不了了之时怎么解决，这是可以预想到的情况。
我很不希望到时候社群不接受仲裁委员会的决议，又嚷嚷著要罢免仲裁委员会，那是非常难看的情况。--~~Sid~~ 2024年6月30日 (日) 09:51 (UTC)[回复]
问题是这个“选的门槛”、“敲定的细节”，过程及结果是否合理？不少人有疑虑。既然并非如英文那边当年由威尔斯“君权神授”，本人认为本地仲裁委员会的权威是要经由实际裁决确立，不是伊始就赋予莫大权限。尤其涉及直接处理管理权限者，应不必属于首届就奉送委员会的工具。目前本站与监管员等全域社群合作无间，本人虽一贯主张社群拿回应有之自治权，但现阶段也未见到由仲裁委员会接掌彼等紧急处置权限的必要。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月26日 (三) 05:30 (UTC)[回复]
那你觉得仲裁委员会是来干什么的呢？早就有人使用“没必要”这个理由来否认各种事情，我对此的回应是，确实，WP:CHOICE也说了，编辑维基百科也没必要。你当维基百科管理员有必要吗？那为什么还有人编辑百科，为什么你还要当维基百科管理员呢？
我知道我在委员会是否应该有权力去除管理员这个讨论中持少数观点，所以我也不想继续陈述我的观点。你说循序渐进我无所谓，要是能够通过实际判决历史来让社群更信任委员会是好事，但是我其实想强调的是刚开始ArbCom也至少应当拥有设立禁制及设高风险主题的权力。如果选出来的委员会没有办法实现决议出来的结果那就非常无能。就和WP:NAC不能关闭为删除一样。--0xDeadbeef (留言) 2024年6月26日 (三) 07:07 (UTC)[回复]
据我所知，仲裁委员会职能到现在都没有确定。具体而言，目前高风险主题在客栈提案模式运作良好（除了法轮功本来争议较多），对于本站来说高风险主题本来就是个低层级议题，确实不用仲委会插手。另外，我不确定你是想要仲委会有权下达什么形式的禁制，但大部分情况应该都没问题，因为社群至少有共识赋予仲委会某种裁决封锁操作之权，这自然也就包含禁制。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月26日 (三) 08:19 (UTC)[回复]
那就好。--0xDeadbeef (留言) 2024年6月26日 (三) 12:06 (UTC)[回复]
我是认为高风险主题作为编辑限制的一种，可以作为仲委会的争议解决手段之一（跟禁制权相似），但绝对不会覆盖社群本身订立高风险主题的权力。目前CTOP下，社群经共识实施的编辑限制只能由社群经共识解除，而不能由任何管理员自行解除；仲委会的则可有相似机制，仲委会的高风险主题限制（不论是设定新的高风险主题或是编辑限制）都只能由仲委会或极广泛共识（30人80%支持？）解除，仲委会也可基于方针及其原则解除社群共识订立的编辑限制（不过只能是回应申诉）。--路西法人 2024年6月27日 (四) 03:20 (UTC)[回复]
本人亦认为仲委会有权在必要时自行提出高风险主题，为其执行手段之一。当然，社群对此当有复核权，其门槛应与经一般社群管道（客栈）制定者相同。相对而言，仲委会祇能被动决定解除已无需求之高风险主题，而不应主动介入（这应该与阁下观点相同）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月27日 (四) 04:16 (UTC)[回复]
@桐生ここ What? Arbcom are elected by the whole community, unless the community consensus is hijacked by a small group of users, the arb will be reviewed as the representative of the whole community. Why will they become the minor? -Lemonaka 2024年6月26日 (三) 03:48 (UTC)[回复]
问题是争议发生当下，当事人们是否认同委员会是他们选举出来的吗？而且事实上仲裁委员会的决定是有限数量的委员们达成的共识，而社群可以组成共识的人数是无限的。--桐生ここ★[讨论] 2024年6月27日 (四) 02:38 (UTC)[回复]
不认同也得认同。就像如果我进行扰乱维基百科，游戏维基百科的事情的话，有管理员要封禁我，我是不是说“我不认同你是被社群选举出来的管理员，你的决议不是社群共识，请在社群中形成共识再封禁我”就可以有免死金牌了？--0xDeadbeef (留言) 2024年6月27日 (四) 02:49 (UTC)[回复]
管理员是执行共识，仲裁委员会是没有共识的情况下制造一个“共识”，还是有点不一样。--桐生ここ★[讨论] 2024年7月1日 (一) 19:52 (UTC)[回复]
在什么情况下仲裁委员会是在没有共识的情况下制造一个共识，而不是执行共识？--0xDeadbeef (留言) 2024年7月2日 (二) 03:25 (UTC)[回复]
其实若仲裁委员会按方针与指引精神裁定，那本质上与管理员行使自由裁量权意涵相同，都是执行社群共识。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月2日 (二) 04:21 (UTC)[回复]
有几种民主解方：一种是社群以足够高门槛另行达成有效共识，推翻仲裁委员会决议；另一（两）种是经罢免或次届选举移除若干社群认为不适任之委员。社群可以决定是否两（三）种解方并行，或祇允许其中几种。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月1日 (一) 19:47 (UTC)[回复]
初期仲裁委员会或本地行政员都还没有权限可以自行取消管理员权限，这个或许要到未来届数的仲委会选举前再解决。目前状态下，仅有“可能需要紧急除权”、“（发布报告后）已经确认符合解任发起条件，等候社群投票重新确认管理员权限”两个情况是适合直接冻结权限。
虽然目前尚无技术手段直接冻结管理员权限，仲委会仍可通过审议施行禁制权，临时禁制当事人使用任何管理人员权限，违者亦可直接视作严重违规而符合除权条件即可。
不过如果是“冻结权限”，那么就不是“解任投票”而是“重新确认投票”，重新确认投票的通过标准（此处指支持留任比率）或许要提高；反过来解任投票的通过标准（此处指支持解任比率）也需因应略微提高（例如55%）。--路西法人 2024年6月15日 (六) 00:56 (UTC)[回复]
How can you “冻结”(maybe temporarily stop) VRT priviledge without removing them? What about Oversight? -Lemonaka 2024年6月15日 (六) 02:22 (UTC)[回复]
基本上都是需要通过暂时除权处理。使用行政手段如禁制也是可以等同冻结权限，违者即直接除权即可。--路西法人 2024年6月15日 (六) 03:15 (UTC)[回复]

机要原则

Taking the current privilege of ARBCOM into consideration, the member of ARBCOM should have signed or need to sign NDA before appointment, the result is that nearly all member from mainland China are excluded and they may not trust this group at all. However, Wikipedia is working based on the consensus, having a whole subgroup excepted from those may make it hard to function.

以ARBCOM目前享有的特权来看，ARBCOM的成员在任职前应该签署或者需要签署保密协议，结果就是几乎所有来自中国大陆的成员都被排除在外，他​​们可能根本不信任这个团体。然而，维基百科是基于共识运作的，如果将整个子群体排除在共识之外，可能会使其难以正常运作。---Lemonaka 2024年7月9日 (二) 01:34 (UTC)[回复]

这也是没办法的事，2021年时WMF好像已经有不承认中国大陆人士签署的保密协议的做法，这不是中文维基百科的裁量范围。Sanmosa 蚌埠 2024年7月9日 (二) 05:18 (UTC)[回复]
否。我记得过往讨论中是安排照样容许无法签署保密协议的用户参选，而在必须有前保密协议才能接触的证据的情况下设subcommittee处理有关证据或案件。--路西法人 2024年7月9日 (二) 06:42 (UTC)[回复]
我的理解是他是在表述他认为所有ArbCom成员都应该需要签署保密协议的个人意见，而不是在表述过往讨论的结论。Sanmosa 蚌埠 2024年7月9日 (二) 22:47 (UTC)[回复]
我没有说他正在表述过往讨论。你无法好好阅读、理解我的留言，并屡次超译我发言的行为已经严重造成我的困扰，请你停止。--路西法人 2024年7月10日 (三) 01:52 (UTC)[回复]
我好像也没表达出你说的这个意思？真正在超译的人是你吧？Sanmosa 蚌埠 2024年7月13日 (六) 01:23 (UTC)[回复]
@LuciferianThomas@SanmosaPlease focus on the topic, ARBCOM members are responsible for on and off-wiki invesitgation, including evidence regarding privacy, how can users send these information to the Arbcom members who never sign NDA?
请关注主题，ARBCOM 成员负责维基内外调查，包括有关隐私的证据，用户如何将这些信息发送给从未签署保密协议的 Arbcom 成员？ -Lemonaka 2024年7月15日 (一) 01:30 (UTC)[回复]
subcommittee，小组委员会，即仅有部分成员参与的调查。简而言之：不涉及隐私证据的案件可由所有仲裁员参与，涉及隐私证据的案件仅可由已签署NDA的仲裁员参与（未签署NDA的仲裁员recuse）。--路西法人 2024年7月15日 (一) 01:44 (UTC)[回复]
[来源请求]? -Lemonaka 2024年7月11日 (四) 03:17 (UTC)[回复]
Wikipedia_talk:仲裁委员会#保密协议及处理涉及隐私证据案件之职务、#公示RFC结果及仲裁方针草案。--路西法人 2024年7月11日 (四) 03:38 (UTC)[回复]
可尽量细分仲委会行使职权，最敏感部分才考虑保密协议为必要条件。具体之执行，应以个案为基准，确定证据是否涉及隐私，再行规划。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月9日 (二) 16:16 (UTC)[回复]

新用户通过撰写新条目的方式“完成学科作业”的处理讨论

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:教育专案、Wikipedia talk:给老师们的提示。

近日巡查当中发现疑似存在新用户通过撰写新条目的方式“完成学科作业”，目前主要涉及两位用户U:JINJINYAN和U:ZixuanHE以及其创建的四篇条目，见人权史（Draft:人权史）、中朝关系史（Draft:中朝关系史）、Draft:修理权、Draft:性别薪酬差距（目前的处理为：已全部转移至草稿空间，部分被绕过草稿空间重新发布的条目已提报存废讨论）。四篇条目均为机翻或者潦草翻译，且未进行维基化。据ZixuanHE所述，这些条目的创建疑似为“学科作业”，且必须发布才有可能拿到“节课的成绩”（见UT:ZixuanHE#阁下所创建条目已被移动至草稿）。

鉴于此类行为为显然带有倾向性或非百科编辑性动机的条目创建行为（可能不符合但类似于维基百科:有偿编辑方针），故提出此话题以寻求如何处理该类问题。--Sinet（讨论） 2024年6月14日 (五) 08:43 (UTC)[回复]

在下认为，无论以何种理由对中维条目进行编辑，都必须依照维基百科的方针和标准进行。完成学科作业并不是提交质量不佳的条目的理由。Sinet君将条目暂移至草稿空间以便于编者继续编辑的做法得体适当。--SheltonMartin留言|签名 2024年6月14日 (五) 08:49 (UTC)[回复]
看两人的对话确实像是要完成作业。但我记得本来就会有一些计划是让学生练习写条目的？--Rice King 信箱 · 留名．边缘人 2024年6月14日 (五) 09:30 (UTC)[回复]
enwp那边有类似的教学/课堂行为，参考那边的处理方式？--Leiem（留言·签名·维基调查） 2024年6月14日 (五) 09:31 (UTC)[回复]
en:Wikipedia:Wiki_Ed/Massachusetts_Institute_of_Technology/Organometallics_(Spring_2024) ← 找到了这个。--Leiem（留言·签名·维基调查） 2024年6月15日 (六) 08:34 (UTC)[回复]
中文维基有Wikipedia:给老师们的提示，另外，台湾维基人在推的教育专案（Wikipedia:台湾教育专案），是让作业放在教育专案以下的空间（如Wikipedia:台湾教育专案/台大物理系服务学习二_(107-1)/物理学家），该计划有维基人在该空间进行评分，符合维基百科标准的再移动到正式条目空间。以我的印象，中文维基百科的人力不太够帮助老师修正（或评改）同学的作业， 而新手若没有人协助的话， 也不太可能在短期（例如一周）产出符合维基百科规定， 不会被提删的条目。--Wolfch (留言) 2024年6月14日 (五) 09:48 (UTC)[回复]
此为韩国汉阳大学的教育专案，而教育专案显非“有偿编辑”。如果条目存在机械翻译等问题，移至草稿即可。另外，本站或许应建立专门讨论教育专案的布告板，如英文维基的 en:Wikipedia:Education noticeboard？谢谢。cc @Hanyangprofessor2：--SCP-0000（留言） 2024年6月14日 (五) 13:20 (UTC)[回复]
我好像听过这个事情，这位教授好像在我的讨论页面中提到过这个项目。--MilkyDefer 2024年6月14日 (五) 15:35 (UTC)[回复]
Yes, they are my students. They are Chinese nationals and supposedly fluent in Chinese (I do not speak Chinese, apologies). They are required to proofread their works so that it reads well in Chinese (instructions are at en:User:Piotrus/Ideas for students; I explicitly ask them to read 维基百科:翻译指引). They are also encouraged to ask for feedback at Chinese Discord or at 维基百科:同行评审. I am afraid some some students may not follow the instructions (yes, I am sure you are all shocked), for which I can only apologize, and some try to finish the Wikipedia-writing assignment (which is supposed to take ~3 months) in less time (say, a week or two before the class is supposed to be finished...). On the other hand, I'll also note that we should not assume that all poor translation is the result on reliance on machine translation - some people (students) may not know how to write properly, and the errors may be of their own making, rather than the fault of the translation software (just a thought). To end, I'll repeat the idea I mentioned few months ago here (at Chinese Wikipedia) - to create a Chinese equivalent of the en:Wikipedia:Education noticeboard mentioned above, as well as a dedicated space for students to list their works and ask for a review (so that their assignments do not flood the 维基百科:同行评审). PS. If anyone feels like this, one of my students got blocked again and their case could use a review, once they apply for an unblock, as I told them to (of course, I expect them to read and understand the reasons for their block...). User:Liangyiqiao2004
是的，他们是我的学生。他们是中国公民，据说中文很流利（我不会说中文，抱歉）。他们需要校对自己的作品，以便其中文可读性良好（学生的说明位于：en:User:Piotrus/Ideas；我明确要求他们阅读维基百科：翻译指引）。我们也鼓励他们在 Chinese Discord 或维基百科：同行评审中寻求回馈。我担心有些学生可能不遵循指示（是的，我相信你们都感到震惊），对此我只能表示歉意，还有一些学生尝试完成维基百科写作作业（预计需要大约 3 个月的时间）在更短的时间内（例如，在课程结束前一两周…）。另一方面，我还要指出，我们不应该假设所有糟糕的翻译都是依赖机器翻译的结果 - 有些人（学生）可能不知道如何正确书写，并且错误可能是他们自己造成的，而不是翻译软体的错（只是一个想法）。最后，我将重复几个月前在这里（中文维基百科）提到的想法——创建一个相当于上面提到的en:Wikipedia:Education 布告栏的中文版本，以及一个专门的空间，供学生列出他们的作品和要求审查（这样他们的作业就不会淹没维基百科：同行评审）。附言。如果有人有这样的感觉，我的一个学生再次被屏蔽，一旦他们申请解锁，他们的案件就可以进行审查，正如我告诉他们的那样（当然，我希望他们阅读并理解屏蔽的原因。 ..) 。使用者：Liangyiqiao2004--Hanyangprofessor2（留言） 2024年6月17日 (一) 10:00 (UTC)[回复]
@Hanyangprofessor2：I'm afraid that the block would stay on for a while for Liangyiqiao until he/she/they answers the question from local admin @Tigerzeng： on the user talk page. I understand that there might be deadlines for students to reach, but if Liangyiqiao is not able to answer the question that Tigerzeng presents, it would be hard to convince the admins (I supposed that is at least Tigerzeng and myself) that he/she/they understands the reason for the block.
恐怕Liangyiqiao的封锁将会持续一段时间，直到他在用户讨论页上回答Tigerzeng的问题。我理解学生很有可能有缴交作品的截止日期需要达成，但如果Liangyiqiao无法回答Tigerzeng提出的问题，这将会很难让管理员（我想至少是Tigerzeng和我自己）相信他自己已经了解了封锁的原因。
注：原文是以英文写出后再翻译，若有不同之处请以英文为准。--（☎）dt 2024年6月21日 (五) 02:00 (UTC)[回复]
@ATannedBurger Of course, I understand. It is the student's responsibility to monitor messages and answer them in a timely manner. 当然，我明白。查看信息并及时回复是学生的责任。--Hanyangprofessor2（留言） 2024年6月22日 (六) 03:57 (UTC)[回复]
又有一个。--Rice King 信箱 · 留名．边缘人 2024年6月15日 (六) 07:26 (UTC)[回复]
英维也有这种，主框架是Wikipedia:教育专案，具体课程例子比如 https://enbaike.710302.xyz/wiki/Wikipedia:Wiki_Ed/University_of_Southern_California_Viterbi_School_of_Engineering/WRIT_340_for_Engineers_-_Spring_2024_(Spring_2024) ，这种页面注明了哪个大学，哪个课程，哪个学期，哪个讲师，并有维基编辑审核。但中文维基只有这个“教育专案”的主页面，实际页面内没有规范。--桃花影落飞神剑（留言） 2024年6月15日 (六) 15:02 (UTC)[回复]
社群可以趁此机会完善相关的页面与规定，就我的观察教育专案在中维的需求不算低，但也没有到频繁。--~~Sid~~ 2024年6月17日 (一) 09:29 (UTC)[回复]
(＋)支持，可以对en:Wikipedia:Education进行引入或者设计其他暂行方针以标准化相关内容的处理。--Sinet（讨论） 2024年6月17日 (一) 12:52 (UTC)[回复]
(＋)支持，同上--HYHJKJYUJYTTY（留言） 2024年6月21日 (五) 07:40 (UTC)[回复]
(＋)支持--Rice King 信箱 · 留名．边缘人 2024年6月22日 (六) 04:27 (UTC)[回复]
@SCP-2000 @ATannedBurger @Flyinet Hello. Can you tell me why majority of my students contribution was removed from those two articles? 性别薪酬差距 and 修理权 . I am afraid I cannot understand the problem from edit summar or article's history, they look mostly fine to me? If there is a problem, I can tell the student to fix it in the near future, but I need to know what the problem is first. (Content was removed by @日期20220626)
你好。你能告诉我为什么我学生的大部分贡献被从这两篇文章中删除吗？ 性别薪酬差距和修理权 。恐怕我无法从编辑摘要或文章历史中了解问题所在，它们对我来说大部分都很好？如果有问题，我可以告诉学生在不久的将来修复它，但我需要先知道问题是什么。（内容被@日期20220626删除）--Hanyangprofessor2（留言） 2024年6月22日 (六) 08:28 (UTC)[回复]
There are comments about these two articles on User talk:JINJINYAN from user:ZixuanHE "However, the structure of some of your sentences is relatively complex, which affects the reading fluency".--Wolfch (留言) 2024年6月22日 (六) 08:52 (UTC)[回复]
@Hanyangprofessor2: Hello, if I understand correctly, 日期20220626 shortened articles and removed content with poor translation quality (i.e. translated by machine translation) and lack of Wikify, so that they can be published in the main namespace.
Students can write in the draft namespace and submit it for AFC review (by adding code {{subst:submit}} on the top of the page). Thanks.--SCP-0000（留言） 2024年6月22日 (六) 09:08 (UTC)[回复]
Hi, I am the patroller who reviewed the articles created by your two students. Overall, the reasons for the articles being disqualified can be summarized into three categories:
  1. The most severe and obvious reason is the massive presence of machine translation appearance throughout the articles. There are numerous noticeable signs of machine translation, including but not limited to: evident translation tone, incorrect Chinese proper nouns, and English-style sentence structures. These issues are easily detectable to native Chinese readers, leading to the articles being directly judged as unqualified.
  2. The articles lack proper "Wikification." They consist mainly of plain text and line breaks, without using any syntax to design headings or organize the article structure, resulting in poor readability. Additionally, some terminologies lack internal links or have incorrect links. These are obvious mistakes, making the articles clearly fail to meet Wikipedia's inclusion standards.
  3. The articles are primarily composed of assertive sentences without any connectors or transitional paragraphs. This results in a lack of coherence and logical flow, making the articles very difficult to read.
--Sinet（讨论） 2024年6月22日 (六) 09:27 (UTC)[回复]
@Flyinet @SCP-2000 @Wolfch Thank you for the explanation. I will ask the student @JINJINYAN to address those problems. 谢谢你的解释。我会请同学@JINJINYAN 解决这些问题。--Hanyangprofessor2（留言） 2024年6月23日 (日) 03:32 (UTC)[回复]

设立教育布告板

根据上方的讨论共识，已设立教育布告板的草案，欢迎各位前来讨论。--人间百态,独尊变态(讨论) 2024年6月22日 (六) 11:06 (UTC)[回复]

Ping一下相关用户@Flyinet、SheltonMartin、RiceKing、Leiem、SCP-2000、MilkyDefer、Hanyangprofessor2、ATannedBurger、桃花影落飞神剑、ASid、HYHJKJYUJYTTY：--人间百态,独尊变态(讨论) 2024年6月22日 (六) 11:12 (UTC)[回复]

你设计还不错--HYHJKJYUJYTTY（留言） 2024年6月22日 (六) 11:17 (UTC)[回复]
据我所知，目前有教育专案，都是在互助客栈其他区通报。至于是否需要独立的教育专案布告板，则尚待商榷。但无论具体地点如何，总是应鼓励教育专案主持人通报，俾利于社群复核。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 02:20 (UTC)[回复]
“教育”布告板此称呼较含糊，或许改为“教育专案”布告板？谢谢。--SCP-0000（留言） 2024年6月23日 (日) 15:52 (UTC)[回复]
完成--人间百态,独尊变态(讨论) 2024年6月24日 (一) 13:29 (UTC)[回复]
教育专案布告板看起来不错。--冥王欧西里斯（留言） 2024年6月27日 (四) 01:33 (UTC)[回复]
我觉得这个设计的不错，支持。--桐生ここ★[讨论] 2024年6月25日 (二) 16:21 (UTC)[回复]
在看草案之前我以为是用来通报/报备教学计划的布告板，但起来好像不是这个用途。
  • “参与教育专案的学生的条目作业已产生或可能产生的问题”是不是在条目讨论页或用户讨论页讨论相关问题会比较直接？除此之外还有互助客栈的条目讨论版。
  • “教育专案运行中产生的问题”需要为这些问题设立布告板吗？相关问题的讨论频率似乎不多，是否可以继续在互助客栈讨论？
  • “关于维基教育基金会的讨论”个人对这个基金会了解不多，其曾经在中文维基百科举办过什么活动吗？
--Steven Sun（留言） 2024年7月2日 (二) 02:11 (UTC)[回复]
@人间百态：感觉通报教育专案也可以纳入范围。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月2日 (二) 04:24 (UTC)[回复]
不反对。--冥王欧西里斯（留言） 2024年7月2日 (二) 04:44 (UTC)[回复]
建议加入一个列表备案当前进行中的教育项目，并要求教育项目的主管者填报，备案信息可包括：
  • 项目名称（相关机构名称）
  • 教育项目编写的条目性质（翻译或原创）
  • 教育项目的主管者用户ID以及其他监管者ID
  • 教育项目的参与者ID
  • 教育项目内正在编写的条目列表
方便巡查员和社群了解正在进行的项目信息。--Sinet（讨论） 2024年7月2日 (二) 15:26 (UTC)[回复]
@Flyinet，已完成。--人间百态,独尊变态(讨论) 2024年7月3日 (三) 14:20 (UTC)[回复]
已将通报教育项目纳入范围，顺便回复一下Steven Sun君的疑问。我对教育专案布告板设计的定位和英维是大致相同的，即集中处理维基教育专案的老师和学生在编写维基百科时可能产生的问题。条目讨论页、用户讨论页、互助客栈，这些地方确实比布告板直接不少，但这些页面比起布告板来或曝光度不足，或查阅困难。布告板设立后能够让社群更加有效的处理相关问题，并提供存档供用户查阅如何处理相关话题。--人间百态,独尊变态(讨论) 2024年7月2日 (二) 13:57 (UTC)[回复]
又想了一下，教育项目运行中产生的问题的讨论频率确实不是很大，就算出现大部分也是有关学生的作业质量问题。故此已将学生的作业质量问题一项并入教育项目运行中产生的问题之中。--人间百态,独尊变态(讨论) 2024年7月2日 (二) 14:10 (UTC)[回复]
  • 我想请问这个布告栏未来如何运作？目前看不出来有任何方法可以使想发起作业的老师能提前知道要来通报，而且如果要用维基介面写通报，大概使用率会很低；社群依然会一天到晚先被作业洗，然后才通知老师去登记，完全没有发挥预警效果。如果是合作社群要去登记……目前大宗会有合作案的就台湾社群，但我们已经有教育专案页面了。--Reke（留言） 2024年7月6日 (六) 15:02 (UTC)[回复]
    interesting的问题。不知道Reke君有没有关注过近来英维的教育布告板的讨论记录，在近几年中也几乎没有人用该布告板来提报项目。一来英维老师通常会使用Wiki ED进行课程，二来在英维老师也是不太管注教育布告板的。实际上这个布告板本来就不是为了“预警效果”而设计的，其目的正如上方的回复所说为了让社群“集中处理维基教育项目的老师和学生在编写维基百科时可能产生的问题”。布告板的确无法改变社群始终慢一步的事实，但它能在事情发生后让社群更加直接的处理相关问题并通知有关用户。--人间百态,独尊变态(讨论) 2024年7月7日 (日) 03:30 (UTC)[回复]
    感谢，我是看上方讨论都要把通报列入当中，而且目前板面说明中也容许提报教育专案，所以才这样问的。
    如果单就集中处理问题来讲，我建议不如在互助客栈开设一个“/教育专案”的分页面？这样子看互助客栈的其他版面时，也就可以顺便去关切一下。--Reke（留言） 2024年7月9日 (二) 04:14 (UTC)[回复]
    我个人是倾向不要再开客栈的子页面啦，况且看客栈的特定子页面的时候也未必会去看其他子页面就是了。--冥王欧西里斯（留言） 2024年7月9日 (二) 05:20 (UTC)[回复]
    同意，挺不错的设计。--SheltonMartin留言|签名 2024年7月11日 (四) 06:38 (UTC)[回复]

讨论页话题自动索引

为配合WP:CON/TRIAL鼓励用户多善用条目讨论页，我尝试重制了类似过往Shizhao君制作的Talkindexbot（WP:TALKINDEX），自动索引各讨论页的近期话题。目前索引暂时置于本人用户空间（User:LuciferianThomas/讨论页索引），未来将正式申请机械人任务更新WP:TALKINDEX。若各位对索引测试有任何意见或建议，欢迎在此提出。--路西法人 2024年7月6日 (六) 12:51 (UTC)[回复]

支持这个initiative（虽说这在WP:CON/TRIAL的提议出现前就该出现了）。Sanmosa 蚌埠 2024年7月6日 (六) 13:53 (UTC)[回复]
挺好的，不过我也发现了点问题，但恐怕并不容易修复：
  1. 有些讨论已经结束（比如，编辑请求解决了），却仍会出现在此索引上，导致其十分冗长
  2. 有些讨论发起时间比较早，或讨论较长时间都没有人回应，就不会出现在此索引上；这可能并不利于问题的解决/共识的形成
--古怪的Wang31（讨论 | 贡献） 2024年7月7日 (日) 13:09 (UTC)[回复]
聊胜于无，有问题可以之后慢慢改善。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月7日 (日) 15:35 (UTC)[回复]
  1. 现在仍然在初步测试阶段，未来将参考Cewbot，将已经结束（已有Archive框模板）的讨论以另一种方式标记；其馀标签如已解决之编辑请求、移动请求等亦可纳入考量。此部分还请社群协助列举。
  2. 目前机械人设计为每次都搜索最近14天的RC来弄这个列表，未来或许会以暂存方式优化；但起始搜索RC也最多只能到30天，而14天的讨论串数量已贴近400大关，可以想像起始数据需要索引蛮久的（以防轰炸资料库）。不是做不了，但最多也只能做30天，但也还是会多串到用户难以索引不再有效的地步。另一个方法是恢复{{indiscussion}}模板以防拖延时间过长讨论不被索引，这又是另一个需要社群去讨论的议题。
--路西法人 2024年7月7日 (日) 15:51 (UTC)[回复]
其实很多讨论就没有结束，或即使结束了也未必有任何标记来表示已结束。我认为话题索引只索引最多30天内有进行讨论的就好了，30天都没人参与的讨论那就是暂时没人在意或没能力参与，或者讨论页的留言就只是对条目内容的一个注记，没有讨论必要。讨论页话题自动索引最大的意义是让人能够了解和检索近期发生在讨论页的所有讨论，以期达到能够有更多人关注参与讨论的目的--百無一用是書生 (☎) 2024年7月8日 (一) 02:45 (UTC)[回复]
目前确实其实是没什么大问题的，我提的只是算是一点细枝末节的问题，得不出结论也无伤大雅。
  1. 讨论结束的，通过一些模板标记可以排除；当然，这对机器人在技术上的设计要求就会比较高。要是总体上没有特别多活跃讨论，直接忽略其实也问题不大
  2. 没解决但没人回复的讨论，确实是个比较矛盾的问题。无限索引就的讨论无论从技术上还是价值上肯定都是不太现实的，还是要考虑是否需要一种“标记”。一方面，就让这些讨论不了了之，感觉也不太好，尤其一些争议要是总是不解决，可能容易产生积患；另一方面，如果真的把所有“未结束”的讨论都列出来，却没人想去讨论，那仍然会让索引变得越来越长，失去意义。（突然想到，这个问题其实也可以类比存废讨论的积压讨论的存在，关键在于讨论的问题到底重不重要）
    我也给个我的建议，可以考虑先恢复{{indiscussion}}（我不清楚模板具体内容，总之是恢复或创建一种标识“此处有讨论正在进行”的模板），试用一段时间，要是积压的讨论越来越多，就还是用按日期索引的方案。
--古怪的Wang31（讨论 | 贡献） 2024年7月9日 (二) 14:37 (UTC)[回复]

私自发布（怀疑自我原创）英国官员译名

参见：Talk:施纪贤 § Victoria Starmer之译名

最近适逢英国政府换阁，一系列官员的会有港式译名，但需要等英国领事馆发布。但我看到一些用户，似乎急不及待的将自己相信的译名发布出来。甚至我见到一些ip用户，如14.198.208.124，甚至发布英国首相配偶、和子女的译名。据了解，使馆没有发布这些人的译名，或者媒体也未必会“创造”这些译名，明显是该用户的私人原创。

我已经很久没有在此活动，但这些行动似乎已经违反不能发布原创内容的规则，希望有关管理员能适当处置此事。--JéRRy ~ 雨雨 （留言） 2024年7月7日 (日) 07:08 (UTC)[回复]

@Yuyu：若此类编辑没有可靠来源佐证，均可迳予回退。也请多注意违规使用者，并协助通知提报。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月7日 (日) 12:05 (UTC)[回复]
我最多已经回退多一次，但上面的ip依然活跃发布其幻想，你们看看要不要处置一下？--JéRRy ~ 雨雨 （留言） 2024年7月7日 (日) 13:37 (UTC)[回复]
@Yuyu、Ericliu1912：还有这位@Jimmy HCH：在阿克莎塔·穆尔蒂的编辑（Special:Diff/79839604），于2023年11月22日发布。然而使用谷歌搜索香港译名“麥雅賢”发现关于她的新闻都是在2024年的，也有维基百科译名循环引用的可能。--The3moboi（留言） 2024年7月7日 (日) 14:58 (UTC)[回复]
也有可能是香港方面2024年新增的。不过也要看看使用量，若香港方面也不怎么用该译名应移除。--微肿头龙（留言） 2024年7月8日 (一) 03:32 (UTC)[回复]
以英国首相配偶为例，马卓安的夫人，一直看各种文件都没见过“庄乐敏”这个名字，搜google 几乎全都是维基百科。其他名字，除了“彭雪玲”有印象被广泛报导，其他基本上都出处不明。当然，一票子人还在疯狂维护。--JéRRy ~ 雨雨 （留言） 2024年7月8日 (一) 09:10 (UTC)[回复]
不好意思，该译名的确是还没有正式来源，不应回退你的。--Mykola（留言） 2024年7月8日 (一) 10:10 (UTC)[回复]
现在不吵甚么善意了吗？--JéRRy ~ 雨雨 （留言） 2024年7月8日 (一) 13:48 (UTC)[回复]
嗯，是我误解了。--Mykola（留言） 2024年7月8日 (一) 13:54 (UTC)[回复]
尝试搜索了几个，并没有搜到来源。--杰里毛斯（留言） 2024年7月8日 (一) 10:39 (UTC)[回复]
还在有人说“杜安妮”是Anneliese Dodds 的官译，还说星岛01可以作数。之前不是他们信誓旦旦说 David Lammy 是“林伟德”吗，现在是甚么样子？留著你们自己闹腾吧--JéRRy ~ 雨雨 （留言） 2024年7月10日 (三) 13:32 (UTC)[回复]

设立编者著作权调查

鉴于最近本人发现有些许编辑持续侵犯著作权的情况，为了记录并核实侵权情况是否属实，与此同时可协作处理并查删确实存在侵权情况的内容，认为应将英维的en:WP:CCI搬过来，不知各位有何意见。以下是我的一些想法：

  • 任何编者被发现有5个实际侵权的情况后可以开启著作权调查案件。
  • 英维有设定调查助理，而限制只能管理员或助理查核侵权属实才可开启调查。个人看法是可以先不需要助理或管理员把关，仅需任意第三方查核证明侵权属实即可。
  • 可运行ContributionSurveyor.java开启调查并列出所有需要检查的编辑。例
  • 调查开启后，使用、、?标注是否为侵权。侵权文本应当被删除，如需WP:RD也应提删。

--0xDeadbeef (留言) 2024年7月7日 (日) 10:47 (UTC)[回复]

不反对，但硬性指标建议是暂定、灵活的。按英文说法，着眼于长期的侵权。不清楚怎么算5个，比如5个条目，5个修订版本或5个章节等。任意可能太过宽松而浪费调查资源，至少一或两名延伸确认用户？--YFdyh000（留言） 2024年7月7日 (日) 17:05 (UTC)[回复]
可暂定一名延伸确认用户吧。5个在英维是instances，算是较模糊，我认为是5个修订版本，但至少应有一些证据证明非单一侵权（多个条目均有）--0xDeadbeef (留言) 2024年7月7日 (日) 17:41 (UTC)[回复]
如果有志工自愿协助，似乎也不妨碍。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月8日 (一) 07:33 (UTC)[回复]
我已试着在自己用户空间暂时记录我对于HYHJKJYUJYTTY侵权的查核以及处理，见User:0xDeadbeef/CCI/HYHJKJYUJYTTY。如有人想帮忙可以安装我搬过来的Deputy脚本--0xDeadbeef (留言) 2024年7月8日 (一) 08:31 (UTC)[回复]
不反对，不过不知道会有多少人参与。--冥王欧西里斯（留言） 2024年7月9日 (二) 05:27 (UTC)[回复]
我只想说人手不够：（
要设立的话流程请从简不要太复杂。--~~Sid~~ 2024年7月9日 (二) 14:08 (UTC)[回复]
不反对，这个东西貌似还不错。--桐生ここ★[讨论] 2024年7月14日 (日) 09:54 (UTC)[回复]

关于IPBE申请的问题

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:IP封锁豁免权授予者、Wikipedia talk:IP封禁豁免。

哈啰大家好，我是IPBEG，我想就以下几个问题请社群讨论，给予我们明确的共识，这个是我个人发起的讨论，并没有与其他授予者讨论，希望大家尽量参予。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

不强迫备案WP:RFR/IPBE

目前的情况是都会备案到权限申请，我希望可以不强迫，应该说不知道从何时开始有了惯例会备案至权限申请，事实上日志都写得很清楚，这个备案会让我们多一个步骤，备案时所描述的内容事实上并没有提供到多大的帮助，邮件列表只有订阅相关邮件列表的人才能查询。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

授权标准

目前基本上都是授予永久权限，各位应该有注意到我授权会经常授予临时权限，这是因为有人反映说授权过于宽松，所以我希望可以针对这一部分进行讨论，在不使处理变繁杂的情况下，兼顾标准的部分。有关于这一部分我是希望本地恢复CU，交由CU来定期随机查核使用者是否确实有需要用到IPBE，不是授予者与管理员们提高标准，即便提高也无法防止有意骗取IPBE的使用者。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

我理解有一些人可能会觉得这个讨论有点多馀，然而我的目的是在于确保社群有一定的共识，不会单方面变更后有人跳出来说，你怎么这么做你应该这么做：​（--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

稍微解释一下为什么是永久权限。曾经首次授权一般都是临时权限的，但是后来发现没有太多意义。基本上所有到期之后还想要继续编辑的都会申请续期，这里也没有太多可以审查的东西，基本上遇到申请都会转成永久权限。所以没有续期的那些，也就是没有实际编辑，到了时间就忘了的人。这部分人的除权，现在由机器人自动执行。所以永久权限和首次的临时权限本质上区别也就不大了，而且还减少处理的负担。这部分是有过讨论的，找一下的话应该是可以找到讨论的。--Tiger（留言） 2024年7月9日 (二) 14:45 (UTC)[回复]
感谢Tiger。--~~Sid~~ 2024年7月10日 (三) 06:46 (UTC)[回复]

BlackShadowG

同 LuciferianThomas 君，且个人早已联络 emergency@。考虑到无后续讨论的需要，故关闭之。祝愿她平安无事。--SCP-0000（留言） 2024年7月11日 (四) 03:53 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

Can anyone get in touch with BlackShadowG（讨论 | 贡献）? It has been 10 days since their last announcement of committing suicide. I'm quite worried about them.
Google. 有人能联系到 BlackShadowG（讨论 | 贡献） 吗？距离他上次宣布自杀已经过去了 10 天。我相当担心他。 -Lemonaka 2024年7月10日 (三) 08:39 (UTC)[回复]

如有必要，应发件至emergency@ 请求协助，在这里公布似乎没有用。反正无法证明的死讯也不应挂模板。--路西法人 2024年7月11日 (四) 03:41 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

影武者已被基金会全域禁制

查询meta:List_of_globally_banned_users时发现，影武者已于7月9日被列入基金会全域禁制（WMF Ban）名单中。--Itcfangye（留言） 2024年7月12日 (五) 11:28 (UTC)[回复]

🍾--2A0D:2683:C100:0:0:0:0:F（留言） 2024年7月13日 (六) 07:54 (UTC)[回复]
大快人心。何时轮到WMLO？L'Internationale, Sera le genre humain! ✏️ 2024年7月14日 (日) 09:40 (UTC)[回复]
检索自“https://baike.710302.xyz/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”