维基百科

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

快捷方式

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

按此刷新页面。

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

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

查看全部讨论

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

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

消息

Wikidata weekly summary #536

 
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-15. Please help Translate.

Discussions

  • New requests for permissions/Bot: SpinachBot - Task/s: AI agent-enabled question answering through the creation and execution of complex SPARQL queries on Wikidata. Users tag the bog with wikidata-related questions, and it tries to come up with an answer by iteratively creating SPARQL queries.

Events

Press, articles, blog posts, videos

Tool of the week

  • Relationships between two Wikidata items a new tool hosted on Observable which looks at all statements involving a pair of Wikidata items.
  • User:Magnus Manske/ac2wd.js - This script adds an "AC2WD" link in the tools sidebar. When you click on it, it uses the AC2WD tool to check the item for certain Authority Control IDs (eg VIAF). It then checks these AC datasets for statements (and more AC IDs). It will then add any new information it found as new statements, or add more references to existing statements where possible. A green checkmark will be appended to the link if data was added (reload the page to see), otherwise a "—" if no new data was available.

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

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

Books & Bytes – Issue 63

The Wikipedia Library: Books & Bytes
Issue 63, May – June 2024

  • One new partner
  • 1Lib1Ref
  • Spotlight: References check

Read the full newsletter

Sent by MediaWiki message delivery on behalf of The Wikipedia Library team --2024年7月18日 (四) 12:16 (UTC) —此条未加入日期时间的留言是于2024年7月18日 (四) 16:14 (UTC)之前加入的。[回复]

维基媒体运动宪章批准投票结果

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

大家好，

经过仔细统计个人和自治体选票后，宪章选举委员会很高兴地宣布维基媒体运动宪章投票的最终结果。

根据宪章选举委员会的通知，7月9日 23:59 UTC投票结束时，我们已达到自治体投票和个人投票的法定人数。我们感谢在批准过程中投票的所有2,451名个人和129名自治体代表。您们的投票和评论对于运动策略的未来步骤非常宝贵。

2024年6月25日至7月9日举行的维基媒体运动宪章批准投票的最终结果如下：

个人投票：

截至7月9日 23:59 UTC，共有2,451名选民投票，其中2,446张选票被认定为有效票。有效票中，1,710名投下“赞成”；623名投下“反对”；113名选择“–”（中立）。由于中立票不计入总票数，73.30%的选民投票支持宪章（1710/2333），26.70%的选民投票否决宪章（623/2333）。

自治体投票：

截至7月9日 23:59 UTC，共有129名自治体指定投票人投票，其中129张选票被认定为有效票。有效票中，93名投下“赞成”；18名投下“反对”；18名选择“–”（中立）。由于中立票不计入总票数，83.78%的自治体投票支持宪章（93/111），16.22%的自治体投票否决宪章（18/111）。

维基媒体基金会理事会：

维基媒体基金会理事会于2024年7月8日举行的特别理事会会议中投票决议不批准拟议的宪章。维基媒体基金会理事会主席Nataliia Tymkiv分享了投票结果、决议、会议记录以及提议后续步骤。

综上所述，维基媒体运动宪章的目前修订版本未获批准。

我们由衷感谢您参与我们运动治理的重要时刻。

宪章选举委员会，

Abhinav619、Borschts、Iwuala Lucy、Tochiprecious、Der-Wir-Ing

MediaWiki message delivery（留言） 2024年7月18日 (四) 17:52 (UTC)[回复]

The Signpost: 22 July 2024

 
News, reports and features from the English Wikipedia's newspaper
Read this Signpost in full · Single-page · Unsubscribe · Global message delivery 2024年7月22日 (一) 09:34 (UTC)

Wikidata weekly summary #637

 
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-22. Please help Translate.

Discussions

  • New requests for permissions/Bot:
    • DannyS712 bot - Task/s: I want to get approval for a bot with translation admin rights that will automatically mark pages for translations if and only if the latest version is identical to the version that is already in the translation system, i.e. only pages with no "net" changes in the pending edits.
    • DerIchBot - Task/s: Adding data about schools provided by the German and Austrian governments to wikidata.
    • DifoolBot 5 - Task/s: Change reference URLs into the related ID property and merge references with the same ID property.
    • AroundTheBot - Task/s: Automated import of Albanian nouns with IPA from Wiktionary, with the long-term goal of using this data to do pronunciation-based comparison/word evolution between languages.

Events

  • Past: Wikimedia Indonesia hosted the 2024 Data Visualization Competition from June 5 to 18. The event featured data visualizations (posters and graphics) and short essays using data from Wikidata. Visit the competition page (in Indonesian) to view the winning entries.
  • Upcoming: Wikidata's 12th birthday decentralized events will take place in October and November 2024. Feel free to browse the documentation pages to learn how to organize an event in your area, get funding, and get in touch with other organizers.

Press, articles, blog posts, videos

Tool of the week

  • Paulina, a new tool for exploring public domain works.

Other Noteworthy Stuff

  • WMF Product and Technology Advisory Council (PTAC) invites interested volunteers to apply. As part of the movement strategy recommendation for "Coordinating Across Stakeholders," the PTAC will bring technical contributors and the Wikimedia Foundation together to co-define a more resilient, future-proof technological platform.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • mul: We fixed the last blocker for the limited MUL rollout to Wikidata on July 29th (phab:T362917)
  • EntitySchemas:
  • Query Service: preparation for the graph split is continuing by the Search Platform Team. We started looking into adapting the constraints checks for it (phab:T369079)

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


方针

提议英维指引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)[回复]

版本7(分句公示)

没有争议/争议已在版本6解决

1.标题：播放资讯

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

6.原生中文节目在非中文使用地区的首播资讯；

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

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

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

15. *推迟不足30分钟或并非偶发的延误播放之资讯。

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

16. *电视节目重播资讯。
**在该节目授权区域内的相关播放平台(同一媒介)可观看人数较首播平台(同一媒介)的可观看人数高一倍或更多的可被本段记录
**如节目的重播曾被第三方独立可靠来源引用重播资料并作主题介绍，请记录相关主题介绍于回响、影响等合适章节。这情况下编辑者可在本章节简单提及重播日期、时段及引起主题介绍的播放平台。

--唔好阻住我爱国（留言）

修订版本

17. 不是以中文提供字幕或配音的播放平台。
    • 节目原产地区播放平台或以中文制作的节目不在此限。
    • 如相关节目因该播放平台的播放而对当地社群引起重大回响，则不在此限。
    • 如相关节目的所有播放平台不设中文字幕或配音及未能引起重大回响，编辑者可以选择从下列序列中选择最多3个其他语言的播放平台，唯相关资料必须曾被第三方可靠来源收录。
      • 跨洲份播放平台，跨洲份数量越多序列越高，如欧洲跨美洲。
      • 以整个洲份为主要“可观看地区”。
      • 当地在地化，如该节目曾于当地重新配音、剪接等，但不包括添加当地字幕。
      • 于当地转播及添加当地字幕。
      • 于当地转播，并没有任何后制工作。

--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:17 (UTC)[回复]

@Factrecordor--唔好阻住我爱国（留言） 2024年7月15日 (一) 11:26 (UTC)[回复]
不反对--Factrecordor（留言） 2024年7月17日 (三) 16:39 (UTC)[回复]
基于已清除所有反对意见，此版本将在3日后开始公示。--唔好阻住我爱国（留言） 2024年7月20日 (六) 06:43 (UTC)[回复]
(？)疑问：家有儿女先在香港J2台播出，然后在澳视澳门台播出。因为澳门可以收看J2台，所以在澳视台播出之前澳门观众已经在J2台看过一次。这种情况，家有儿女可不可以收录澳视的播放资讯？（就这样看好像不可以？）--素菓霖 2024年7月21日 (日) 19:05 (UTC)[回复]
这个反倒是先收集TDM的信息吧。(当时TVB的授权只有香港地区直到TVB Anywhere上线澳门为止。)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月21日 (日) 21:32 (UTC)[回复]
澳门可以虽然收看J2台，但是在收费有线电视及OTT 平台 TVB ANYWHERE，与免费电视TDM的媒介不一，根本比较不到，所以楼上说的没有错。--唔好阻住我爱国（留言） 2024年7月22日 (一) 00:35 (UTC)[回复]
我换个例子：贾神探，先在TVB明珠台播出，然后在澳视澳门台播出。翡翠台和明珠台在澳门一直都是可以免费收看的，所以在澳视台播出之前澳门观众已经在明珠台看过一次。这种情况，贾神探可不可以收录澳视的播放资讯？（就这样看好像不可以？）--素菓霖 2024年7月23日 (二) 05:20 (UTC)[回复]
然而TVB播出的贾神探只有香港地区的授权并没有在澳门地区的授权所以依旧只能收录TDM的资讯(实际上澳门合规传输香港台的途径就只有公共天线、澳门有线电视以及TVB Anywhere并且TVB Anywhere因播出节目版权仅限香港的原因并未上架明珠台节目)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月23日 (二) 07:17 (UTC)[回复]
如果明珠台在澳门公共天线合规传输，那么TVB放在明珠台的节目应该也要有澳门的授权，如果TVB没有贾神探的澳门授权，TVB是不可以把贾神探放在明珠台播放的，只能放在只有香港合规看到而澳门合规看不到的频道。既然贾神探可以在明珠台播放，应该可以合理推断TVB也有澳门的授权，否则TVB这样会侵犯版权。--素菓霖 2024年7月25日 (四) 09:38 (UTC)[回复]
所以首段先说“节目的OTT播放平台及网络电视的节目可观看地区均需列明来源，”如果需要改至“节目的可观看地区均需列明来源，”我无任欢迎，不过大家有没有听过“讯号溢出”这个名词？--唔好阻住我爱国（留言） 2024年7月25日 (四) 11:38 (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)[回复]
(？)疑问-（谢谢Sanmosa通知在下）(1)请教，为什么能够径行宣告提案通过？这是不是不妥当、效力也有问题吧？在下不大能理解这作法。其他用户提出疑虑的意见，有被处理吗？(2)这样径行宣告通过的作法，让在下感到，在下所提醒、忧心的 问题，恐怕会出现：“以前维基百科的方针明确、对管理员的说明责任条件有所要求。在下建议要注意，新订方针，例如高风险主题方针、修改方针，不宜模糊、过多由管理员全权，这容易出现主观等副作用问题。会不会架空了过去的维基百科核心基础方针呢？”。Wetrace欢迎参与WP人权专题 2024年7月18日 (四) 11:21 (UTC)[回复]

电视剧演员名单序列

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

本主题或以下段落文字，移动自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)[回复]
@Sa Young Sun，阁下可能误会了，情况不是陈豪被列为主演，反而有很多来源提到他是客串，包括电视台自己的官方报道，只是剧集官方网页的演员排序把它排在第一[9]，而官方网页那个排序的字眼是“演员”，不是“主演”。换言之，官方没有否定陈豪是客串此一事实，但他们就是喜欢把这个客串但最大卡士放在第一，而官方这种做法有违中立，恐怕有其商业或其他利益考虑，维基应否依从其利益考虑？我在上面强调的正是维基向来都警剔官方（一手来源）的不中立，所以不应在此条文认定官方不容质疑，我只是希望加入质疑官方的机制，且需要强共识才可不遵从官方。像《黑道律师文森佐》的刘宰明，按你指出的理据，就算讨论都没法形成强共识。--Factrecordor（留言） 2024年7月17日 (三) 15:09 (UTC)[回复]
不管有无商业、利益考量，在排序上应不会造成中立问题，我认为“警惕”应在于剧集本身的评价等，而不是在排序上争论。个人观点，排序就像人物设定，是官方本身所设定或决定。比如《新宿伤痕恋歌》的女主角是加藤爱，但她的存在感却比中岛美嘉低；又比如我先前举的《伊甸园之东 (电视剧)》，女主角李多海不仅第6集才登场、角色定位不明，最后还辞演。若以阁下的逻辑，这些主演可能会因为编辑者自认的实情，而将其排除，包括我前面举例的刘宰明，那显然又跟官方释出的资讯（可靠来源）不符，便难以断定何谓“实情”。
而且排除二手来源的原因，是因为二手来源并不一定知道官方、剧组内部的设定，又或是只报导较为人熟知的演员（人气），例如《八尺门的辩护人》，报导只写李铭顺主演，但实际片头片尾的主演名单并不只有他一人，由此可证二手来源的正确性大多不如一手来源（仅指戏剧设定范畴）。
我言下之意并不是“官方不容质疑”，而是依循官方的排序，可以避免编辑者原创研究、自行认定。在有可靠来源的情况下，都会引发编辑战了，没有可靠来源的强共识更难以形成保障。而我前述也提及，排序若产生争议“可以用可靠来源来补足”。另外，我觉得别被“主演”所限制，很多戏也都没有标明“主演”，或甚至是群戏，那就依照演员名单填入即可，其他思虑只是徒增原创研究的可能。
总而言之，我所要强调的是，现行的方针是已经尽量考量所有的可能性，阁下新增的条文可能会因此推翻原先的条文，而回到原本没有增设方针时的情况，那您必须再设法把编辑战、原创研究的避免方式考量进去。--Sa Young Sun（留言） 2024年7月17日 (三) 16: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)[回复]

重新公示

虽然上次公示时有意见提到应“将段落侵权的新代码另外新建模板”，但由于没有人提出任何有关方案，我认为现阶段以原案重新推进比较适合，因此依据WP:7DAYS的规定（其实已经隔了8日）重新公示原案7日。Sanmosa 蚌埠 2024年7月21日 (日) 09:32 (UTC)[回复]

所以技术上是打算怎样处理？--SCP-0000（留言） 2024年7月21日 (日) 10:58 (UTC)[回复]
@SCP-2000：Shwangtianyuan在上方有提议一个Uw-copyright模板的更新版本，我计划直接以之替换既有版本（也就是条目侵权与段落侵权都是用同一个模板），此外提报侵权流程也会按Shwangtianyuan上方的提议修改。Sanmosa 蚌埠 2024年7月23日 (二) 11:20 (UTC)[回复]

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

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

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

不反对合并。不过能否询问下您会怎么设计合并之后页面评级的章文结构，如果可以的话能否参考下Temp君的意见。--人间百态,独尊变态(讨论) 2024年6月23日 (日) 08:37 (UTC)[回复]
我应该会在最后面开一章“通用评级”，并入相关内容。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月21日 (日) 08:42 (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)[回复]
  公示七日，至2024年7月28日 (日) 08:42 (UTC)结束。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月21日 (日) 08:42 (UTC)[回复]
(＋)支持，我建议把整个Wikipedia:条目重要度评级标准也并进去。L'Internationale, Sera le genre humain! ✏️ 2024年7月21日 (日) 13:52 (UTC)[回复]
(＊)提醒：For Each element In group ... Next君在编写Draft:页面评级草案，如对内容有其他需求且不着急，可考虑等草案的完全版本再来商议。否则现阶段版本的合并也是问题。--PexEric💬|📝 2024年7月22日 (一) 14:13 (UTC)[回复]
先合并，等他写好了直接整页更新（我预期旧版本也没有保留必要），未见扞格之处。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月22日 (一) 14:46 (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)[回复]
  • 上方两名用户都将“质疑者”定性为“反对提案的人”，但这个条文写的是“编辑者”，同样可以套用于“正方质疑反方提出的回应”，正方的质疑同样需要详细论证论点的不足。
  • “可接受的建议”确实过于主观。
  • 上方用户指出质疑者没有必要教提案人如何写好方针好吗，同样可以还一句“提案人没必要教反方如何提出真正有力的论述”。现在很多时候是反方恃着自己是反方，然后不论自己意见是否合理，就硬打说提案有反对意见不应通过；演变成“反方说自己的反对意见有效就行，不论正方怎样有力的反驳、反方自己的意见如何无力，反方的反对意见依然自称有效”，和“反方不同意自己意见被认定非正当合理或已被回应，但同时却在认定正方的回应并非正当合理，令自己的意见维持有效”。现在的厘清显然是将天秤从偏向反对方拉回中间而已。
--路西法人 2024年7月17日 (三) 04:47 (UTC)[回复]
“可接受的建议”—>“改善建议”
这个可以吗？--唔好阻住我爱国（留言） 2024年7月17日 (三) 10:20 (UTC)[回复]
不太行。指出对方说法有问题后并无原因要协助修正对方的说法。指出对方错误后推翻其提案/意见难以构成“改善建议”，但确实仍能合理推翻对方意见。--路西法人 2024年7月18日 (四) 08:32 (UTC)[回复]
“，并就每一不足论点详细说明该论点的不足之处及提出可接受的建议。”—>“，并就每一不足论点详细说明该论点的不足之处。”--唔好阻住我爱国（留言） 2024年7月18日 (四) 10:34 (UTC)[回复]
Version 2:

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

--唔好阻住我爱国（留言） 2024年7月20日 (六) 06:41 (UTC)[回复]
不行，不一定要详细才能指出对方不足，有时简短的两三句话就已经足够说明不足之处。相对的，详细也不一定可以说明不足之处，如果论点本身有错，再详细也没有用。--素菓霖 2024年7月23日 (二) 05:42 (UTC)[回复]
同。说一百句但言之无物也没用，指出对方说法逻辑谬误三五句也可以足以驳回对方论点。--路西法人 2024年7月23日 (二) 09:15 (UTC)[回复]
“详细”：没有列明字数，但不相信一句就能反驳，你们的对我的反驳也至少两句啦。--唔好阻住我爱国（留言） 2024年7月23日 (二) 15:06 (UTC)[回复]
这是模糊与否的问题（--路西法人 2024年7月24日 (三) 02:36 (UTC)[回复]
但如果是玩规程问题或模糊表达，当然与“详细说明”有很大落差。--唔好阻住我爱国（留言） 2024年7月25日 (四) 13:52 (UTC)[回复]
我们在编辑某些条目，察觉一些方针需要制订或修改，却不一定常涉足所有受该方针影响的范畴，先反思影响范围，再看看哪些用户经常活跃于个中话题，邀请讨论，所有潜在疑问可能在两三星期内就能被大家想出来了，可以集中解决。若不这样做，往往有个人偶尔路过，又放下一个疑问，自然无休无止。就算你曾经顺利通过提案，也只是你的一时幸运，而你的幸运不一定是维基之福。--Factrecordor（留言） 2024年6月26日 (三) 13:01 (UTC)[回复]
“偶尔路过，又放下一个疑问”，这个绝对支持，唯该路人是不是应该负起责任，主动跟进自己问过的疑问，如有需要，应尽他能力以最快时间进行追问，避免社群其他成员无限的等待，这对提案者绝对是一个折磨。--唔好阻住我爱国（留言） 2024年6月26日 (三) 13:13 (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)[回复]
公示修订提议7日。Sanmosa 蚌埠 2024年7月21日 (日) 07:39 (UTC)[回复]

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

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

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

支持公布具投票资格人数，个人建议可在开放用户投票前15日公布具投票资格的用户人数；至于用户名单是否一并公布、是否有任何安全或隐私等疑虑，可视具体情况调整，或是有任何疑虑也可直接提出。--Kriz Ju（留言） 2024年7月18日 (四) 21:08 (UTC)[回复]
开放用户投票前先行公布有资格投票者人数与名单应可行（说实话现在不都有MMS发送名单了吗）。但“定期公布投票人数俾便社群追踪任免案之整体动态”个人尚看不出必要性，望进一步阐明？-Peacearth（留言） 2024年7月19日 (五) 03:24 (UTC)[回复]
技术上投票前，投票权人名单必定会在phab公布，增设方针明文要求我不反对。反而我认为应该关闭隐藏已投票人名单的功能，方便社群查核，毕竟投票选项已经保密，保密已投票人名单有意义吗，别人只能知道谁投了票，又不知道投了什么。--桐生ここ★[讨论] 2024年7月19日 (五) 11:41 (UTC)[回复]
保密已投票人名单有意义，不排除有人威胁特定用户必须或不能投票的情况，前者会使投票满足最低票数要求，后者会使投票无法满足最低票数要求。Sanmosa 蚌埠 2024年7月19日 (五) 12:03 (UTC)[回复]
看来还是有点意义，不过我仍然认为应该公开已投票名单，或者在投票完成之后公开已投票者名单。--桐生ここ★[讨论] 2024年7月22日 (一) 09:19 (UTC)[回复]
考虑到近期的事情，我不认为短期内我们可以这样做。Sanmosa 蚌埠 2024年7月23日 (二) 04:47 (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)[回复]
像现在普通话（国语）与粤语混着用的情况，未来要作无障碍怎么办？--Kethyga（留言） 2024年7月16日 (二) 14:47 (UTC)[回复]
@落花有意12138：法语维基辞典有个叫{{cmn-pron}}的模板，输入汉语拼音可以自动生成法国远东学院拼音、威妥玛拼音、耶鲁拼音和注音字母（但其他方向就不行）。在下认为：如果有需要的话，可以把这个模板搬运过来，这样就能像Kinder出奇蛋那样，一次过满足四个愿望。📕📙📒📗📘 赌博机构最坚定的反对者 📚📖 2024年7月15日 (一) 04:13 (UTC)[回复]
上一轮讨论中，提到了方针维基百科不是词典的问题。个人观点是支持LuciferianThomas的“连结至维基词典方案”。个人反对在条目内大量标注配音的方案，即当前方案。--Nostalgiacn（留言） 2024年7月15日 (一) 05:41 (UTC)[回复]
想了想还是说下，阁下给的例子可能会有点小小瑕疵。首先是Wikipedia:格式手册/序言章节#生物中，学名应该置前放置就是了，所以应该是

福氏长爪鹡鸰（学名：Macronyx fuelleborni，台湾作富勒氏长爪鹡鸰，“鹡”，拼音：jí，注音：ㄐㄧˊ，粤拼：zik3、“鸰”，拼音：líng，注音：ㄌㄧㄥˊ，粤拼：ling4）是...(下略)

然后另外件小事，这长爪鹡鸰实际上还有更上层的分级：是鹡鸰科长爪鹡鸰属，但读者实际操作上也不太可能一路从上层分类点进下层页面去吧...？以及若其最上层是亚目、亚科等预设不显示（除非有特地呼叫display parent）的次要分类单元的话那要怎么办？觉得不要把常用字限太死。--WiTo🐤💬 2024年7月15日 (一) 08:43 (UTC)[回复]
(？)疑问：那么请问如何定义“没有在以下三个常用字表中均出现的汉字”（该汉字仅在这三个常用字表之中的一或二个出现，或均没有出现）是否常用？-游蛇脱壳/克劳棣 2024年7月15日 (一) 09:32 (UTC)[回复]
上次讨论时我已提出类似方案四的东西，不过有一点我必须提出：如果是整个词组就请整个词组连结（wikt:鹡鸰），不要逐个字连结。（即：{{wikt sup|鹡鸰}} ）--路西法人 2024年7月17日 (三) 04:02 (UTC)[回复]
看到这个建议才想到，如果用了{{地区用词}}作为首句的话，该模板会根据显示语体显示不同顺序，但这样写成
福氏长爪鹡鸰 （学名：Macronyx fuelleborni，台湾作富勒氏长爪鹡鸰 ）是...会不会稍嫌累赘？
而福氏长爪鹡鸰 （学名：Macronyx fuelleborni，台湾作富勒氏长爪鹡鸰）是...像这样只挑一边写也不太好吧，会需要有人协助修改把标音放在最前面。--WiTo🐤💬 2024年7月17日 (三) 05:01 (UTC)[回复]
加个参数吧。--路西法人 2024年7月17日 (三) 05:36 (UTC)[回复]
另一可行方案是仅标于{{各地中文名}}之中。--路西法人 2024年7月17日 (三) 05:39 (UTC)[回复]
{{各地中文名}}的用法有些不同，这是拿来显示地区词差异的，不是拿来表示读音的。Sanmosa 蚌埠 2024年7月17日 (三) 14:02 (UTC)[回复]
倾向于方案3（{{zy}}）与4A（{{wikt sup}}，包裹整个词语），但个人认为在有{{Infobox Chinese}}的情况下可以不用在引言特别标注注音模式。Sanmosa 蚌埠 2024年7月17日 (三) 14:02 (UTC)[回复]
@落花有意12138：你介不介意让这讨论串改走RFC机制？现在VPP页面的长度实在惊人，要load进去要花比较长的时间。Sanmosa 蚌埠 2024年7月17日 (三) 14:16 (UTC)[回复]

Wikipedia:中立的观点#条目命名微调建议

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

现行条文

此外，维基百科编者不能为了解决非中立争议而使用标新立异的条目名称。

提议条文

此外，维基百科编者不能为了解决“不中立”争议而使用标新立异的条目名称。

避免阅读断句为“非‘中立争议’”——既中立性以外的争议禁止原创名称，中立性争议则隐含允许。--此条未正确签名的留言由YFdyh000（讨论｜贡献）于2024年7月16日 (二) 10:01 (UTC)加入。[回复]

英文维基百科早于2010年10月淘汰有关条文。与其小修小补，中维应全面重新检讨是否应跟随英文维基百科更新《中立的观点》方针条文。--路西法人 2024年7月17日 (三) 04:14 (UTC)[回复]
如果考虑修葺中立的方针和命名常规的问题的话，参考这些：Wikipedia_talk:命名常规/存档17#关于WP:命名常规与WP:POV的冲突、User:Cwek/工作室/关于条目常规的一些备存。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月17日 (三) 05:37 (UTC)[回复]
支持此修订。另外，由于本站原创命名问题特别严重，且汉语命名格式本较英语多样，更易孳生争议，故现阶段不建议取消条文。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月17日 (三) 08:21 (UTC)[回复]
首先何谓“标新立异”已经极度模糊，更易产生争议。--路西法人 2024年7月18日 (四) 08:22 (UTC)[回复]
很明显指脱离命名常规等一般命名规则的标题。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月18日 (四) 15:34 (UTC)[回复]
这里我倒是认同LuciferianThomas的说法（这也是我下面说“短期内”的原因），毕竟随着社会观念的转变，一些以前被认为是“标新立异”的东西在现在已经不被认为是“标新立异”，那可想而知一些现在被认为是“标新立异”的东西在未来也有可能会不被认为是“标新立异”，或许社群对命名常规等一般命名规则的理解在未来也会有一定程度上的转变。Sanmosa 蚌埠 2024年7月18日 (四) 15:39 (UTC)[回复]
此处仅为概括规范，主要是得为社群发起相关讨论提供法源，其实践自然是由社群个案探讨。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月22日 (一) 14:45 (UTC)[回复]
我的理解是原创或者仅少数来源使用的罕用命名。“在未来”常见就留到未来再改，不然有维基百科影响传媒的问题。--YFdyh000（留言） 2024年7月18日 (四) 16:24 (UTC)[回复]
如果我的理解，应该就是类似的具有争议事务中，为了达到所谓某些人的主观中立，而排除一些该事物已有（并且有可靠来源彰显的）的直接专有名称（排除一些来自其他语源的来源并翻译后的中文名称），而在本项目另行创造的名称，作为条目命名。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月19日 (五) 01:30 (UTC)[回复]
所谓“为达致中立而自行创造名称”反而是英文维基百科容许的标题取法，非“奇”非“异”，更是当前中维条文对应的英维条文在2010年被汰除后容许的行为，而“常用但不中立”的标题则只是“可以”（may）而不是“必须使用”。光从这一点已经展现“标奇立异”的说法存在极大模糊和操作空间，应从方针中移除此等模糊不清的描述。--路西法人 2024年7月22日 (一) 09:33 (UTC)[回复]
但en中立方针对于命名的方面，列出允许的模式就是：常用但不中立的名字，或者描述性名字（en举例为“Restoration of the Everglades（大溪地的恢复）”、“Political impact of the Boston Massacre（茶壶山丑闻案的政治影响）”）。后者可能针对一些非实体事物时的一种概括性“虚”体的命名方法。现时一些针对主观性“中立”的命名争议上，会可能根据编者的主观思想，另外草拟一些非描述性或者尝试对实体事件一个定向定性，而且并不是具有实际来源的名称，我认为如果要完善或者避免这种类型的情况，可以考虑将en中立与命名常规这部分相互照应的部分引入，来解决这类的命名争议。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月22日 (一) 09:54 (UTC)[回复]
所以说“标奇立异”的表述过于模糊，限制就该明确而非模糊不清。--路西法人 2024年7月23日 (二) 04:24 (UTC)[回复]
可能这个说法最核心的观点就是：排除已经存在专用用名的情况，在没有来源直接支撑下，为了“中立”而原创命名。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月23日 (二) 05:37 (UTC)[回复]
(＋)支持。--BigBullfrog（𓆏） 2024年7月17日 (三) 13:43 (UTC)[回复]
不反对这个修订，至少在短期内是有作用的。Sanmosa 蚌埠 2024年7月17日 (三) 14:04 (UTC)[回复]
会不会把“非中立”三字删去更简单？所有命名争议都应该先寻求共识吧？--派翠可夫 (留言按此) 2024年7月19日 (五) 01:17 (UTC)[回复]
确实，什么是中立的争议啦  囧rz……--SunAfterRain 2024年7月21日 (日) 10:33 (UTC)[回复]
此处无关寻求共识，是说共识不该走向原创或非常用名称。有些条目是会使用非常用名称的。例子暂时想不起。--YFdyh000（留言） 2024年7月22日 (一) 16:05 (UTC)[回复]

关于Wikipedia:格式手册/文字格式#颜色及内联图像的问题

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

前情提要：Wikipedia:特色列表评选/提名区#美国总统列表

我跟U:Y. Sean阁下认为表格中使用“色块”（考虑到有争议，暂且先这样称呼）来表示所属政党不合适，另有U:深鸣阁下和U:Sanmosa阁下提出了不同意见，特发至客栈以寻求共识。

关于本次讨论我觉得需要强调一点，就是我们不应该把讨论的重点集中在对于条文的理解上，而是应该着重于哪种做法能够对读者（这里主要是视障或色觉障碍读者）更有利，若现行条文不足以满足读者利益，也许我们应该考虑完善该指引。我们不能把这个讨论方向搞错了。--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 13:42 (UTC)[回复]

重新说一下我的看法吧。我认为添加合适的背景颜色是没有问题的。
  • 首先，滥加饱和度过高的背景颜色是不合适的，例如此例，颜色达不到WCAG 2 AA标准（[12]）。
  • 其次，合适的背景颜色能够为色觉正常的读者更快地传达信息。以“岩手县行政区划”条目为例，此处的颜色是符合WCAG 2 AAA标准的（[13]）。原条文中请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述，就是针对视障或色觉障碍读者的。而我认为“以文字方式表述”有些狭隘，只要以非颜色形式传达同等的信息即可。像是岩手县行政区划中的符号，我认为也是可行的。同时我们也可以通过使用灰度颜色滤镜模拟色觉障碍的情况，该特色列表中添加的背景色对于色觉障碍者而言，丝毫没有干扰。
  • 最后回到“美国总统列表”这个条目，当前列表中存在的问题是：副总统的党籍以及时间线模板仅以颜色表示，对于视障或色觉障碍读者来说无法得到对应信息。除去该问题，这里的色块对于视觉正常者而言，更有利于快速找到党籍信息；对于色觉障碍读者而言，打开灰度颜色滤镜后，对阅读也没有影响。
--深鸣（留言） 2024年7月18日 (四) 14:08 (UTC)[回复]
现代美国政党的颜色相当广为人知，以色块表示现代政党问题不大。然而撇开民主、共和两党，其他政党颜色对多数读者来说一点帮助也没有。举个例子好了，其他列表（如印度总理列表）的政党颜色，对不熟悉印度政治的读者（即绝大多数的中文读者）来说只会扰乱视觉而已，对读者来说并没有什么便利性，既然列表里面已经提到政党的话，大可不必填上许多花花绿绿甚至刺眼的色块。
我还是澄清一下，我不反对以色块表示党籍，但依我对方针的理解，这是不合适的。
这次的问题症结应该是MOS:NOCOLOR中只有在背景颜色可帮助阐释条目内容，且没有其他更佳的表达方式时，才可对表格或其他的内文元素加入背景颜色的背景颜色定义为何。我坚持背景颜色定义即是表格内除图片及文字的颜色，毕竟方针说表格（而非文字）可以被加入背景颜色。而另外两位则坚持颜色前一定要有其他元素才叫背景颜色。既然这段方针解读有歧义，或许是时间修改一下了。--Y. Sean 2024年7月18日 (四) 14:56 (UTC)[回复]
如果不纠结于“背景颜色”的定义，阁下的意思是否是说，表格中可以添加背景颜色以及色块，但是需对多数读者有益。--深鸣（留言） 2024年7月18日 (四) 15:28 (UTC)[回复]
我维持我的主张：讨论共识不能推翻一个词汇的实际词义，所以社群无法也无权通过“讨论共识”来推翻一个词汇的实际词义，因为这属于对规则条文的超译，而且这样做犯了诉诸群众与诉诸不相关领域的权威的谬误。我认为现行条文只表达了“表格与其他的内文元素都是技术上可被加入背景颜色的对象”这点，而并没有任何定义一切通过背景颜色的mechanism形成的颜色资料格均应用了“背景颜色”的意思。此外，我并不认为视障或色觉障碍读者会因为通过背景颜色的mechanism形成的颜色资料格（或此处红渡厨所称的“色块”）的存在而使致其任何利益得不到必要的满足。Sanmosa 蚌埠 2024年7月18日 (四) 15:05 (UTC)[回复]
这里我也引述一下我在FLC打的比方：红渡厨与Y. Sean的主张的谬误相当于声称由于所有女婴都是她们的母亲十月怀胎生下的，而所有男婴同样都是他们的母亲十月怀胎生下的，故而所有男婴都是女婴，而红渡厨现在在客栈这里开讨论串的行为则相当于试图寻求“讨论共识”以满足其强行把一个男婴说成女婴的个人主观意愿。我只想问一个问题：这真的能把一个男婴在实际意义上变成女婴吗？Sanmosa 蚌埠 2024年7月18日 (四) 15:09 (UTC)[回复]
我前述的加粗文字正是回应了阁下的该观点，本次讨论的重点并非是争执谁对条文的理解是正确的，而是应该着重讨论哪种做法更有利于读者。--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 15:21 (UTC)[回复]
不，我的意思正是无论“讨论哪种做法更有利于读者”这个理念如何地崇高，这仍然不构成逾越“讨论共识不能推翻一个词汇的实际词义”的限制的理由。Sanmosa 蚌埠 2024年7月18日 (四) 15:29 (UTC)[回复]
我没理解阁下的意思，因为“讨论哪种做法更有利于读者”这件事情，已经无关于“词汇的实际意义”了。--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 15:40 (UTC)[回复]
这样说吧：假设A与B都是X国人且都位于X国，X国司法独立且有死刑。A认为B做了一些他认为十恶不赦且必须要处以死刑的事情，于是他谋杀了B，A在之后就因为谋杀罪而被处死了，因为虽然X国有死刑，但在X国只有司法机关才能决定是否对B处以死刑，而这权限并不是A所拥有的。因此，无论A谋杀B背后的理念如何崇高，A不能逾越法律给予他的权限。Sanmosa 蚌埠 2024年7月18日 (四) 15:51 (UTC)[回复]
当然，你或许也会说施剑翘也是一模一样的情况，但她一开始的时候只被判7年监禁，后来更是被特赦了，然而那时候ROC的政治环境非常复杂，她的有期徒刑判决与特赦的政治色彩都是非常浓厚的，因此我认为不能作准。Sanmosa 蚌埠 2024年7月18日 (四) 15:57 (UTC)[回复]
还是不懂。--——— 红渡厨（留言・贡献） 2024年7月19日 (五) 02:54 (UTC)[回复]
如果情况真的是这样的话，那我认为你其实也并不知道自己正在做什么。Sanmosa 蚌埠 2024年7月19日 (五) 04:45 (UTC)[回复]
为什么我觉得讨论已经完全离题了--——自由雨日（留言・贡献） 2024年7月19日 (五) 04:51 (UTC)[回复]
我想，Sanmosa阁下仍然是拘泥于已有指引。未能跳脱出已有框架。您不愿清晰明确表达自身观点，那我也只能这样猜测。--——— 红渡厨（留言・贡献） 2024年7月19日 (五) 05:37 (UTC)[回复]
我愿再次表明我的观点，本次讨论的重点并不在于方针指引怎么写的，然后我们要如何执行方针指引这件事，而是在于我们应该讨论一下哪种做法是符合读者利益的，如果现行方针无法满足读者利益，那么我们可以依据讨论后的结果修改方针指引。--——— 红渡厨（留言・贡献） 2024年7月19日 (五) 05:46 (UTC)[回复]
这不是“拘泥”，而是遵守应有的约束。既然条文并没有任何定义一切通过背景颜色的mechanism形成的颜色资料格均应用了“背景颜色”的意思，那“背景颜色”一词就不能如此扩张解释，因此就算真的有一个所谓的“讨论共识”做了扩张解释这种如此荒谬的事情，这种“讨论共识”是必然无效的，因为“背景颜色”这个词语的实际含义本来就不是由社群决定的。我最担忧的事情正是任何人在以后会借着“满足社群利益”或类似的由头来恣意曲解方针指引，这种后果并不是社群能够承受的。Sanmosa 蚌埠 2024年7月19日 (五) 10:14 (UTC)[回复]
至于修改方针指引的事情，我认为很显而易见地这里不太可能会形成这样的一个共识。这里容我重复一次我在上方说过的话：我并不认为视障或色觉障碍读者会因为通过背景颜色的mechanism形成的颜色资料格（或此处红渡厨所称的“色块”）的存在而使致其任何利益得不到必要的满足。Sanmosa 蚌埠 2024年7月19日 (五) 10:17 (UTC)[回复]
从维基百科:特色列表评选#云南省县级行政区列表此评选来看，相关格式手册（MOS:NOCOLOR）有应用过当之虞，导致即使颜色较淡、已搭配图例之类，仍然有违反规定之可能，或须考虑调整行文。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月23日 (二) 22:59 (UTC)[回复]
不要挡到正文显示，一般都没问题。目前多数纯色块使用都会搭配文字解说，已经十分足够。社群特别需要注意的，其实不是背景颜色使用，而是颜色本身是否过于花哨刺眼，甚至违反某些网页使用规范。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月18日 (四) 15:57 (UTC)[回复]
  1. 我理解的背景颜色应当只是纯粹的指html和css中所指的背景色，即background-color、bgcolor这种，参考[14]
  2. 具体到该列表条目中的色块，我一直不确定这种形式的色块在深色模式下如何处理为妥？
--百無一用是書生 (☎) 2024年7月19日 (五) 07:35 (UTC)[回复]

可否订明绕过存废讨论，自行清空分类，属于不当行为？

编辑时或看别人讨论时，偶有发现有人绕过存废讨论，自行清空分类，让分类在其他人难以察觉的情况下被自动删除。相比条目被删除，可恢复及查看编辑历史知道以前的版本是什么面貌，分类中本来曾有什么条目，更难追寻，我认为自行清空分类这行为非常恶劣，希望能在方针订明是不当行为，必须先提交存废讨论。--Factrecordor（留言） 2024年7月18日 (四) 15:22 (UTC)[回复]

(＋)支持--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 15:28 (UTC)[回复]
毋须明定，此类行为通常属于游戏维基规则。另外，我推荐大家使用追踪分类变更的小工具，很方便抓出分类趋势。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月18日 (四) 15:31 (UTC)[回复]
@Ericliu1912那么可否在Wikipedia:游戏维基规则加入这种行为作为具体例子？--Factrecordor（留言） 2024年7月18日 (四) 15:51 (UTC)[回复]
我相信你们三位会想参与这个讨论？Sanmosa 蚌埠 2024年7月18日 (四) 15:32 (UTC)[回复]
@Factrecordor、红渡厨、Ericliu1912。Sanmosa 蚌埠 2024年7月18日 (四) 15:32 (UTC)[回复]
我对管理员怎么删O4的规程并不了解，因此我想就不班门弄斧了。--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 15:49 (UTC)[回复]
btw我自己一般会点进去，用小工具及编辑历史、日志等（有时候是因为移动导致清空）确定分类变更是否合理，然后再决定是要保留（加条目进来）、重新导向还是删除。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月18日 (四) 15:54 (UTC)[回复]
原则上支持，但具体细则需商榷。例如，未经讨论且无共识，更名分类而修改大量（>5个）条目的行为，使原分类事实上废弃、提升改回难度，我也认为不妥。--YFdyh000（留言） 2024年7月18日 (四) 16:19 (UTC)[回复]
O4好像是机器人自动清理的。或者需要指定完整的流程来避免这种情况：暂停或者废止O4，将清空分类引用和删除行为转到存废讨论；需要一些机制检查分类清空前的编辑（好像只能通过RC机制（最近编辑、页面监视）检查分类的成员增减操作历史）。主要问题是，只有RC机制才能记录分类的成员增减操作历史，分类页面本身没记录，只有分类成员的页面编辑历史有记录但会很分散，可以利用RC机制的时限性（好像设置了90天清空RC表旧记录）逃避检查。或者利用机器人，在O4删除分类后，立即对RC机制下的最近更新表查询，检查最近一段时间内是否存在该分类的成员大量减出，然后预警提醒检查是否故意清空成员来诱使分类删除的情况（可能是提报页面存废或者存废复核，来讨论）。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月19日 (五) 01:45 (UTC)[回复]
我有询问Jimmy Xu此问题，他的回复见讨论页。若社群达成共识，可以请他修改机器人设定。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月20日 (六) 17:30 (UTC)[回复]
O4不是机器人删除的话，可以写一个API工具查删除前最近更新中有没大量成员减出记录。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月19日 (五) 02:01 (UTC)[回复]
其实白磷的小工具也还是能用的吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月20日 (六) 17:30 (UTC)[回复]
请大家协助检视一下分类Category:定海人的清空和删除（O4）操作，是否需要回退相关操作。--Kethyga（留言） 2024年7月20日 (六) 12:16 (UTC)[回复]
Yumeto分几批清空了该分类。Sanmosa 蚌埠 2024年7月20日 (六) 13:30 (UTC)[回复]
已经有人（包括我）多次提醒Yumeto不要这么干了，仍然我行我素的话我只能建议提报了。--——— 红渡厨（留言・贡献） 2024年7月20日 (六) 13:38 (UTC)[回复]
@红渡厨：我这样说有点幸灾乐祸、煽风点火，不过与其“等”，不如直接干下去。查过那个用户名，“来头不小”，搞不好对方“我行我素”是这个原因。--派翠可夫 (留言按此) 2024年7月20日 (六) 15:34 (UTC)[回复]
阅读本站的定海、定海区、镇海区 (宁波市)即知原分类设计有何问题，遂将其下页面逐一阅读后改为更适切的既有分类。管理员AT都是这样处理的（株札、捞金鱼、流觞曲水、投壶、双陆、樗蒲）。 绀野梦人 2024年7月20日 (六) 15:51 (UTC)[回复]
能消歧义就消歧义、能重新导向就重新导向，成本向来不高，确实需要立即删除者为少数。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月20日 (六) 17:30 (UTC)[回复]
这个议题需要考虑建立的分类本身是否合理，而不是单纯追究整理分类的用户。例如母分类本来收录页面就不多，却有多个子分类、缺乏跨语言版本且无细分必要的孤立分类或重复分类等等。--AT 2024年7月21日 (日) 07:24 (UTC)[回复]
我认为任何涉及完全清空及导致分类被删除的行动，都应有机制通知其他人正有此行动，不宜由一个账号（尤其不是管理员）自己判断是否合理。这样反而就不会有事后追究。对于YFdyh000君指出的大量修改，我则不置可否。--Factrecordor（留言） 2024年7月21日 (日) 12:56 (UTC)[回复]
阻止被随便O4速删显然更合理。--SunAfterRain 2024年7月21日 (日) 10:31 (UTC)[回复]
若能做到这两点，我就没什么意见：
  • 有工具协助找回本来加到分类中的条目。
  • 取消自动速删，让其他人能察知。
--Factrecordor（留言） 2024年7月21日 (日) 12:38 (UTC)[回复]
@Factrecordor：1现有技术是可以找出谁最近被移出分类，但要自动移回去我觉得不可行；2废除自动提删就更没人会察觉到这个问题了，不符合的人手复原就好。--SunAfterRain 2024年7月21日 (日) 16:15 (UTC)[回复]
你不如说，“收回所有移动分类的权利（包括机器人）”，又或者“清空分类需要有强共识”。--唔好阻住我爱国（留言） 2024年7月21日 (日) 13:25 (UTC)[回复]

提议修改维基百科:命名常规 (音乐)

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:命名常规 (音乐)。

现行条文

使用中文

  • 命名音乐条目时，优先使用最为通用的中文名称命名。对于拥有官方译名的外文音乐作品，可优先考虑使用该中文名称；如果作品拥有不同官方译名的作品，则以常用名称为主。鉴于华语各地区音乐作品译名往往不同，条目命名地域归属由编写者“先到先得”，并通过地区词转换解决译名差异问题。
作品在不同地区拥有不同中文名称，依据“先到先得”处理。例：型 (歌曲)、荣耀强袭
作品在单一地区拥有不同中文名称，按照“最早的中文名称”处理。例：骇到爆炸、金黄耀眼
作品在单一地区拥有不同中文名称，但不同地区拥有相同中文名称时，则以“常用名称”为主。例：不会是我
  • 关于作品的官方翻译，可参考各地唱片公司和媒体平台。
中国大陆可以参考星外星与新索唱片
台湾可以参考索尼、环球、华纳唱片
  • 没有官方中文名称的音乐作品，优先使用常用中文名称命名。当音乐作品的原文名称比中文翻译名称更为常用，或其不存在中文翻译名称，依据“外文规范”处理。
例：电子游乐场 (歌曲)、四季 (单曲)、向夜晚奔去
  • 原生中文音乐作品因各地代理而产生的名称不同“不视为译名差异”，条目应以唱片公司最初定名为准，名称不设转换。台湾、港澳地区命名使用繁体中文，中国大陆、新马地区使用简体中文。除技术限制外，条目命名应与转换后名称之一相符。
例：光点 (单曲)、舞娘 (专辑)
  • 除非作品拥有正式中文昵称，否则不作条目名称命名。
正确： 当一个小兵（当一个小兵加入了战争，他就会像个国王般去思考，他所知道的就是在战争时奋力出击，这样他一旦加入了战争就会获得全面性的胜利；在你的信念成为你所持有的武力时，就没有人能打倒你；所以如果你是一个人独自奋斗，你要自己坚持下去，记住深度是最崇高的，如果你能认清你的立足点，你才会看到你应该要在哪里降落，如果你掉下来了也没关系，因为你知道你是对的）
错误： 浦西（湿湿小可爱）、盲光（Blinding Lights）、小诗（敬微小事物的诗）
提议条文

在中国大陆与台湾使用中文

  • 命名音乐条目时，在中国大陆与台湾优先使用最为通用的中文名称命名。对于拥有官方译名的外文音乐作品，可优先考虑使用该中文名称；如果作品拥有不同官方译名的作品，则以常用名称为主。鉴于华语各地区音乐作品译名往往不同，条目命名地域归属由编写者“先到先得”，并通过地区词转换解决译名差异问题。
作品在不同地区拥有不同中文名称，依据“先到先得”处理。例：型 (歌曲)、荣耀强袭
作品在单一地区拥有不同中文名称，按照“最早的中文名称”处理。例：骇到爆炸、金黄耀眼
作品在单一地区拥有不同中文名称，但不同地区拥有相同中文名称时，则以“常用名称”为主。例：不会是我
  • 关于作品的官方翻译，可参考各地唱片公司和媒体平台。
中国大陆可以参考星外星与新索唱片
台湾可以参考索尼、环球、华纳唱片
  • 没有官方中文名称的音乐作品，优先使用常用中文名称命名。当音乐作品的原文名称比中文翻译名称更为常用，或其不存在中文翻译名称，依据“外文规范”处理。
例：电子游乐场 (歌曲)、四季 (单曲)、向夜晚奔去
  • 原生中文音乐作品因各地代理而产生的名称不同“不视为译名差异”，条目应以唱片公司最初定名为准，名称不设转换。台湾、港澳地区命名使用繁体中文，中国大陆、新马地区使用简体中文。除技术限制外，条目命名应与转换后名称之一相符。
例：光点 (单曲)、舞娘 (专辑)
  • 除非作品拥有正式中文昵称，否则不作条目名称命名。
正确： 当一个小兵（当一个小兵加入了战争，他就会像个国王般去思考，他所知道的就是在战争时奋力出击，这样他一旦加入了战争就会获得全面性的胜利；在你的信念成为你所持有的武力时，就没有人能打倒你；所以如果你是一个人独自奋斗，你要自己坚持下去，记住深度是最崇高的，如果你能认清你的立足点，你才会看到你应该要在哪里降落，如果你掉下来了也没关系，因为你知道你是对的）
错误： 浦西（湿湿小可爱）、盲光（Blinding Lights）、小诗（敬微小事物的诗）

在香港、澳门、新加坡与大马保留原文

  • 由于在香港、澳门、新加坡与大马地区，英文、葡萄牙文等语言仍是当地的官方或常用语文，且这些地区在引进相关音乐唱片时往往不对外文作品做出翻译。因此创建非中文的音乐条目时，除非有常用的中文译名，否则在这些地区应当保持该作品的原名（非拉丁字母的名称需要罗马化处理）。对于在中国大陆和台湾已有中文译名的条目，需要通过地区词转换解决命名差异问题，请务必使用单向转换，以防参考文献过度转换。

如上述修改所述，原始版本根本没考虑到中国大陆和台湾以外的地区。我认为这些地区应该保留原名，而不是跟着陆台使用中文。@Milkypine：还请帮我多ping一些人讨论一下这个修改。--Scarsnevergoaway（留言） 2024年7月21日 (日) 12:31 (UTC)--Scarsnevergoaway（留言） 2024年7月21日 (日) 12:31 (UTC)[回复]

这里是“中文维基百科”，在命名时需以“中文”为核心，阁下的提案中提出“香港、澳门、新加坡与大马保留原文”，本人认为没有必要性。香港及澳门有“粤语维基百科”、“英语维基百科”及“葡语维基百科”；马来西亚有“马来语维基百科”；而新加坡也同样有“英语维基百科”覆盖当地。
而WP:命名常规总方针也提到“使用中文”作为命名主要规范之一。--唔好阻住我爱国（留言） 2024年7月21日 (日) 13:35 (UTC)[回复]
歌曲原名我倾向于认为属于常用名称。使用Spotify或AM等检索的时候，听众会检索的是原名，而非中文翻译。况且除了大陆和台湾，其它地区根本没有引入中文翻译，这时候名从主人已经不适用了。再说中国大陆和台湾没有翻译的条目，目前也大量保留了原名。使用原名并无不妥，我认为唯一需要界定的是何时使用原名。--Scarsnevergoaway（留言） 2024年7月21日 (日) 13:48 (UTC)[回复]
当有作品中文名时，观众就会以中文名搜寻。以团结Band (专辑)作例，只要在wikidata做一些动作，Youtube Music 就会自动索引专辑名字至维基简介。不信？自己试试看先。--唔好阻住我爱国（留言） 2024年7月22日 (一) 11:00 (UTC)[回复]
日音和西音不太一样吧，罗马字母和非罗马字母还是不同的。话说你这个例子逻辑循环了啊，相当于Youtube用了维基的原创研究了--Scarsnevergoaway（留言） 2024年7月22日 (一) 15:54 (UTC)[回复]
所以首先应要避免原创研究先，这个时候又要谈WP:列明来源。--唔好阻住我爱国（留言） 2024年7月23日 (二) 14:59 (UTC)[回复]
支持修改方向，不止歌曲、乃至歌手都需如此——西洋歌曲、歌手在任何一地若无中文译名而有地区词转换时，应预设为当地中文文本常用的拉丁字母文字，这也符合命名常规通则“惟若原文名称比中文翻译的名称在中文中更加常用，或如果不存在中文翻译的名称，则应使用原文名称”。例如drivers license、Olivia Rodrigo硬用中文只会徒增不解。但是章节标题“在香港、澳门、新加坡与大马保留原文”建议改为“在香港、澳门、新加坡与大马使用中文文本常用语词”以免误解。— Gohan 2024年7月21日 (日) 23:53 (UTC)[回复]
人名我持保留意见，因为人名可以用译音表译出，在中文维基上很少有人名保留原名的例子。--Scarsnevergoaway（留言） 2024年7月21日 (日) 23:58 (UTC)[回复]
歌曲和艺名或可保留原文名，歌手则不应保留原文名。难道其他领域的人物中文名会比原文名更常用？--微肿头龙（留言） 2024年7月22日 (一) 16:08 (UTC)[回复]
我其实一直非常想吐槽您维对外文人名的处理。虽然中国大陆科技术语完全与你们“以英语为纲”相反，但人名其实大部分都是以原文出现的（在科技文献几乎不翻译，在普通文献有时也不翻译，牛顿、爱因斯坦等除外）。但是您维连人名都要翻译成中文……标题我支持，但是正文一堆译名实在是看得眼花缭乱……我觉得纯属画蛇添足。--——自由雨日（留言・贡献） 2024年7月22日 (一) 17:05 (UTC)[回复]
正常来说一篇文章的译名要统一，另外没有条目的译名第一次出现的时候需要括号内附上原文--Scarsnevergoaway（留言） 2024年7月23日 (二) 14:21 (UTC)[回复]
不需要另立章节，直接移到“使用中文”章节最底作为特例即可。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月22日 (一) 14:43 (UTC)[回复]
我担心自己对这个讨论有误解。假设有一首英文歌，香港地区的销售平台与媒体并没有提供译名，都是直接展示英文名称，各位的想法是不是以下这样？
  • @Scarsnevergoaway版本：一个香港维基人可以直接用英文名称建立条目，其他中文地区常用译名设NoteTA转换。若一个台湾维基人先以当地译名建立条目，设NoteTA转换时香港地区采用英文名称。
  • @唔好阻住我爱国版本：纵使香港没有常用中文名，也要创造一个或移植一个其他地区的译名作为香港版本译名。（另外，用维基相关手段试图影响Youtube/Google，让某一个中文名称看似更广泛认可，是不是一种有违中立、原创的行为？甚至近似编辑一段内容试图制造循环引用？）
--Factrecordor（留言） 2024年7月22日 (一) 15:47 (UTC)[回复]
你说的是对的--Scarsnevergoaway（留言） 2024年7月22日 (一) 15:57 (UTC)[回复]
所以这个命名应要更小心，避免出现“循环引用”问题。--唔好阻住我爱国（留言） 2024年7月23日 (二) 15:01 (UTC)[回复]
“请务必使用单向转换，以防参考文献过度转换”是没有必要的吧？参考文献在正常情况下章节、标题等参数就是停用字词转换的，如果参考文献被转换了说明它本身就没有写好。而且，不用双向转换而使用单向转换，这并不能防止很多过度转换吧？反而正文该转换的部分会无法转换，即必然导致某一字词模式下一会儿中文一会儿英文。--——自由雨日（留言・贡献） 2024年7月22日 (一) 15:53 (UTC)[回复]
你说的有道理，我觉得可以把这句删掉--Scarsnevergoaway（留言） 2024年7月22日 (一) 15:56 (UTC)[回复]
婀...，请问这个问题Wikipedia:命名常规_(音乐)#外文规范没有办法解决吗？ --窝法乙烷 儿法梦碎 2024年7月22日 (一) 16:02 (UTC)[回复]
那我觉得最好声明一下在哪些地区默认使用原名，作为一种规范比较好。另外我认为这一段应该加上禁止全大写活全小写的规定，以适应WP:命名常规的总方针，例如GUTS应该改为Guts--Scarsnevergoaway（留言） 2024年7月22日 (一) 16:08 (UTC)[回复]
而且目前我在音乐条目几乎没有看到在港澳新马转为原文的情况，我认为必须要把这个作为指引才行。--Scarsnevergoaway（留言） 2024年7月22日 (一) 16:11 (UTC)[回复]
命名常规跟转换是两回事，哪有这样扩权的？另外没特意写大小写也是当时的反对意见，至少有人一律当成专有名词来命名。 --窝法乙烷 儿法梦碎 2024年7月22日 (一) 17:39 (UTC)[回复]
转换也是命名的一种，转换是因为条目只能有一个命名，如果是港澳新马人建立的歌曲条目，那么明显可以使用原名命名。把这个明确是为了将原名命名条目正式合法化。现有条文给人的感觉是原名不能命名音乐类条目，区别在这里。--Scarsnevergoaway（留言） 2024年7月23日 (二) 00:49 (UTC)[回复]
我不清楚中国大陆的译名情形, 但以台湾来说, 有些歌曲的英文名称知名度比中文要高, 例如Yesterday、Yellow Submarine等。--Wolfch (留言) 2024年7月22日 (一) 16:11 (UTC)[回复]
上个世纪的歌曲基本都这样，中国这边也是如此。而且上个世纪的歌曲基本找不到官方的翻译，所以我最近把很多上个世纪的歌曲都移动到原名了。但上个世纪的专辑基本都有官方中文翻译，作为对比，我也把一些使用原名的专辑移动到了中文名去了。--Scarsnevergoaway（留言） 2024年7月22日 (一) 16:18 (UTC)[回复]
大陆也一样，比如几乎所有人都知道《You Raise Me Up》但几乎没有人知道《你鼓舞了我》。--——自由雨日（留言・贡献） 2024年7月23日 (二) 14:31 (UTC)[回复]
在大陆，谈到歌曲和专辑的时候基本上都会直接用外文名，很多歌曲和专辑的中文译名都是“为了取而取”的。--BigBullfrog（𓆏） 2024年7月23日 (二) 12:53 (UTC)[回复]
是的，我也是大陆人，就我个人所知，哪怕是环球音乐国际部，他们在自己的文宣里面也是保留原名的。但是中国大陆的特殊在于星外星新索在引进专辑的时候会使用中文译名，根据名从主人和使用中文的原则，我倒不反对使用译名作为条目名称。但台湾保留中文的争议应该不那么大，因为环球台湾索尼台湾在宣传的时候基本都是用歌曲和专辑的中文名去宣传的，从常用而言都理应保留中文。--Scarsnevergoaway（留言） 2024年7月23日 (二) 13:39 (UTC)[回复]
但是无论陆台如何处理，港澳星马用中文是毫无道理的，他们引进的时候根本就不翻译这些歌曲啊。陆台有官方翻译，这些地区可没有--Scarsnevergoaway（留言） 2024年7月23日 (二) 13:41 (UTC)[回复]
这也不能这么说，毕竟这里是中文维基百科，使用中文有一定的道理。以马来西亚为例，大部分的外国事物都是英语名更普遍，但不代表地区词处理时需要把马来西亚的故意转成英语。而且相当部分的马来西亚网友根本不会来看中维，英维更香。马来西亚的“官方”翻译基本随中国大陆。（严格上不存在具有影响力的官方翻译，事实上如果有使用中文的需求就跟大陆）还有，导言部分就已经会给出原文名，纵使会不熟悉也不会存在看不懂的情况。--微肿头龙（留言） 2024年7月23日 (二) 14:31 (UTC)[回复]
强烈赞同微肿头龙的说法。新马多地日常口语可能都是中英（或其他语言如马来语）混杂，除非在纯中文语境下常用原文，否则不应将中外混杂语境中的外文视作中文语境下常用。包括在中国大陆，在很多经常需要接触英语的场合（比如科学研究）也常中英混杂，对英文科技名词比对中文熟悉得多，这些英文不应视作是中文的一部分。只有“X光”“CD”等字母词和少数“Bug”（程序错误）、“Boss”（游戏头目）等外文单词这类词语可视作“准中文”。对音乐作品来说，若在中文可靠来源中明显几乎都以外文形式出现，这可视作“准中文”（“准中文”我这里指被部分学者认为可归属于中文的“字母词”，以及极少数总是以原文形式出现在中文语境的外文词；“中文”则特指完全汉字书写的汉语词），即可以（甚至应该）以原文形式直接在中文维基百科出现，但标题我仍倾向使用中文（如果有译名的话）——就像CD条目正文大量使用“CD”纯字母词，但标题仍使用中文，尽管中文显然远不如字母词常用。--——自由雨日（留言・贡献） 2024年7月23日 (二) 14:42 (UTC)[回复]
新马我不完全清楚，但是香港的中文媒体在介绍这些音乐作品的时候通常会保留原文的，我认为可以视作一种在中文语境下常用原文的例子。--Scarsnevergoaway（留言） 2024年7月23日 (二) 14:49 (UTC)[回复]
这种情况我支持在该地地区词模式下使用原文，包括地区词模式下的标题——但不包括标题本身，甚至即便有证据表明所有地区可靠来源都常用《You Raise Me Up》而非《你鼓舞了我》，我仍倾向保留《你鼓舞了我》中文标题，只在正文使用原文（具体到地区词模式下，则是引进了《你鼓舞了我》译名的地区使用中文标题并正文使用原文，其他地区均使用原文）。--——自由雨日（留言・贡献） 2024年7月23日 (二) 14:54 (UTC)[回复]
是的，我认为这是合理的。大陆我认为应该用中文，因为我记得媒体会把这些作品翻译成中文，我记得这是政府的规定。这属于在中文语境下也使用中文的例子--Scarsnevergoaway（留言） 2024年7月23日 (二) 14:57 (UTC)[回复]
况且大陆本身也有名从主人的翻译。--Scarsnevergoaway（留言） 2024年7月23日 (二) 14:59 (UTC)[回复]
政府规定不一定所有媒体都会遵守，并且可靠来源也不只有媒体，例如这篇硕士论文就使用《You Raise Me Up》原文（不讨论硕士论文被用于条目时的可靠性问题）。若事实上可靠来源中使用原文更多，那么大陆模式仍可使用原文（标题除外）。--——自由雨日（留言・贡献） 2024年7月23日 (二) 15:04 (UTC)[回复]
虽然离题，但〈You Raise Me Up〉台湾最早翻〈鼓舞我〉，而大陆引进版称为〈一切因你〉（没找到引进专辑《忆游红月》的资讯，只有缺乏英文对照的相关报导[15]），可能是中维影响，因为后续发行作品和相关报导都称为〈你鼓舞了我〉。 --窝法乙烷 儿法梦碎 2024年7月24日 (三) 12:51 (UTC)[回复]
讲真，如果我来到中维看到满屏的拉丁字母我还不如去看英维，内容丰富也熟悉。--微肿头龙（留言） 2024年7月23日 (二) 14:50 (UTC)[回复]
那其实很简单，你看下新马当地的媒体怎么处理这些歌曲名称的，如果是翻译成中文，那我建议跟随大陆也用中文。如果是维持原名，那我建议也维持原名--Scarsnevergoaway（留言） 2024年7月23日 (二) 14:58 (UTC)[回复]
我对这些文艺类的东西不怎么感兴趣，平时也不关注，可能不能提供特别有用的意见。但能提供一个在地普通人的视角吧。马来西亚（新加坡不知）的中文媒体是有故意使用中文的倾向，比如各大新闻都会使用“马哈迪”，但在口语中不会有人这么叫，都是叫Mahathir的。甚至不怎么常见的人物媒体也会特意转写成中文（本地人物不存在规范，外地人物随大陆）。可见，即便马来西亚媒体真的用中文也不能反应民间实际情况。不过娱乐圈是否有故意用中文的情况我也不清楚，毕竟我很少关注。赞同新马随大陆，大陆用中文就跟着用，大陆用原文也跟着用。--微肿头龙（留言） 2024年7月23日 (二) 15:08 (UTC)[回复]
为什么要这样区别对待？命名也要地域中心？有译名时给出来源，没译名时用原文啊。。。--Abcet10（留言） 2024年7月23日 (二) 14:16 (UTC)[回复]
因为这个译名只能代表部分地区，例如环球台湾的翻译对港澳星马没有意义，因为环球台湾不能代理这些地方的唱片，只能代理台湾本土，译名也只适用于台湾。大陆的星外星和新索亦然，他们的译名对台港澳星马没有意义--Scarsnevergoaway（留言） 2024年7月23日 (二) 14:19 (UTC)[回复]
因为这里是中文维基百科，我个人倾向于命名时尽量使用中文，即如果“陆港澳台新马有任意一地常用中文”的情况，不论其他各地是否常用原文，均使用中文命名，这对每一地都是等价的，并不会有地域中心之虞。但可以通过标题和内容字词转换让每一地地区词个性化显示，类似《赛博朋克2077》在香港繁体模式即显示为《Cyberpunk 2077》。--——自由雨日（留言・贡献） 2024年7月23日 (二) 14:26 (UTC)[回复]
我觉得字词转换应该至少以某种方式写进音乐条目的格式指引内，现有的音乐条目几乎没有将陆台以外的地区改用原名，这是不太合常理的事情。--Scarsnevergoaway（留言） 2024年7月23日 (二) 14:30 (UTC)[回复]
字词转换方面我赞同。甚至很多歌曲我认为大陆简体模式可能也应该用原文，比如刚刚前面提到的《你鼓舞了我》（我日常感觉绝对是英文常用得多，当然主要应根据可靠来源频率来判断）。--——自由雨日（留言・贡献） 2024年7月23日 (二) 14:33 (UTC)[回复]
是的，在大陆我的观感也是英文用得多。但正规的媒体一般会把歌曲和专辑翻译成中文，况且大陆这边很多歌曲有官方翻译，所以我对中维在大陆使用中文没太多意见。港媒好像一般不把歌曲翻译出来，也没一个官方的中文翻译，建议按照Cyberpunk 2077一样，改用原名显示。--Scarsnevergoaway（留言） 2024年7月23日 (二) 14:39 (UTC)[回复]
另外，已经有“没有官方中文名称的音乐作品，优先使用常用中文名称命名。当音乐作品的原文名称比中文翻译名称更为常用，或其不存在中文翻译名称，依据‘外文规范’处理。”所以也没必要再写一段。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月24日 (三) 15:10 (UTC)[回复]

布告板更名

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

WP:布告板（en:WP:Noticeboards）非常容易让人误会成WP:公告栏，这在WP:各地布告板的实践中已经是如此。新手估计很难正确理解，出现提报特定问题不知去往何处的局面。提议将“布告板”更名为“留言板”，{{布告板连结}}的标题或可修改为“留言与请求”之类。因为此类页面多为“请求”、“申请”或“报告”等，所以应该只需移动WP:管理员布告板→管理员留言板、WP:行政员布告板→行政员留言板即可。--PexEric💬|📝 2024年7月23日 (二) 03:48 (UTC)[回复]

感觉作用有限，留言板也有歧义，显得比较随意。--YFdyh000（留言） 2024年7月23日 (二) 04:02 (UTC)[回复]
名为站务板块更简单直接。您维是时候重组一下这些模糊不清的概念了（还有方针指引的分类）。--路西法人 2024年7月23日 (二) 04:59 (UTC)[回复]
布告板不止有留言，真的布告也不少。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月23日 (二) 13:08 (UTC)[回复]
各地布告板可以改为各地公告栏 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月23日 (二) 20:20 (UTC)[回复]
改成“站务布告板”。--BigBullfrog（𓆏） 2024年7月24日 (三) 12:08 (UTC)[回复]

技术

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

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

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

这说来有点话长，但日前因为在修理相关条目时遇到了“𫛚”这种字（该字位于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)[回复]
说起来，大陆当局没说能不能“类推简化”？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月23日 (二) 23:09 (UTC)[回复]
本来通用表的草案是有说不得简化的，但后来正式公布时删去该行字了。所以我想应该是可以的。--WiTo🐤💬 2024年7月24日 (三) 04:27 (UTC)[回复]
但我看条目里说《解读》中还是提到了类推简化的问题。规范公布后出版的字典类书籍也还是有的选择类推，有的选择保留。--——“あたいってば最⑨ね！” 2024年7月24日 (三) 05:32 (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)[回复]
[16]，分别是固定宽、不固定宽，使用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)[回复]
state=collapsed丧失作用的原因似乎与这个主题谈论的内容有关，我对这个主题不熟悉，可能需要导入机器人修正(因为影响的页面可预见非常多)--Rastinition（留言） 2024年7月17日 (三) 23:54 (UTC)[回复]
参见Module talk:Navbox#编辑请求 2024-07-17--Dabao qian℡ 2024年7月18日 (四) 09:45 (UTC)[回复]

UX

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

小蓝条？是不是一整栏的标题行？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月15日 (一) 00:41 (UTC)[回复]
@魔琴：可以参考User:SunAfterRain/js/TalkendFrameToggle.js--SunAfterRain 2024年7月16日 (二) 03:28 (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)[回复]
cc @Shizhao--Func（讨论·贡献） 2024年7月19日 (五) 21:23 (UTC)[回复]

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

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

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

猜测可能是近期系统字体大小调整导致的？--百無一用是書生 (☎) 2024年7月15日 (一) 02:59 (UTC)[回复]
“近期”，大概是什么时候的调整？🤔--——自由雨日（留言・贡献） 2024年7月18日 (四) 02:11 (UTC)[回复]
大概2、3个月前？--百無一用是書生 (☎) 2024年7月19日 (五) 07:37 (UTC)[回复]
凭我自己印象是，“按钮较高”的问题至少已经大半年（或更久）了，似乎是自我打开该工具以来一直就是这样🤔只是之前觉得影响不大一直懒得提（）--——自由雨日（留言・贡献） 2024年7月19日 (五) 10:01 (UTC)[回复]

本主题或以下段落文字，在讨论结束后应存档至Module 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)[回复]
尝试修了一下[17]，现在除了示例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)[回复]
(？)疑问：{{Navbox}}的state参数设定折叠好像失效。--Qqkuro66541（留言） 2024年7月16日 (二) 15:34 (UTC)[回复]
之前我修改的的查论编字体变小，可以看一下现在较大字体下的问题：Template:Campaignbox 塞尔维亚－奥斯曼战争 (中世纪)，Template:Campaignbox 巴勒斯坦托管地犹太人暴动。查论编和标题部分重叠了--百無一用是書生 (☎) 2024年7月22日 (一) 06:19 (UTC)[回复]
@Cookai1205：看看怎么修复标题文字换行的问题吧。--Dabao qian℡ 2024年7月22日 (一) 11:45 (UTC)[回复]
是指改回这样？我没什么想法。毕竟那是3个元素会推挤才会换行，而这次的改法就是让他们不会互相影响。
如果目标是避免重叠，我想到可以调大MediaWiki:Common.css#L-398的左右padding（5em？），但这样在关掉navbar的情况会浪费空间。--Cookai饼块🍪（💬留言） 2024年7月22日 (一) 16:38 (UTC)[回复]
或者用JavaScript调整，navbox-title宽度小于一定数值时禁用position属性，这个就需要计算了。--Dabao qian℡ 2024年7月22日 (一) 17:28 (UTC)[回复]

Infobox person/Wikidata 出生日期

本主题或以下段落文字，在讨论结束后应存档至Template talk: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://zh.wikipedia.org/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)[回复]
经测试，该栏会随着界面语言改变（zh-hk、ko）（登入与否的差异应该跟这有关），行为与{{#time}}类似
  • {{#time:Y年Fj日|1942-10-16|zh-hans}}（“1942年10月16日”）
  • {{#time:Y年Fj日|1942-10-16|zh-hant}}（“1942年10月16日”）
  • {{#time:Y年Fj日|1942-10-16|zh-hk}}（“1942年十月16日”）
可能跟MediaWiki:October月份系列有关：
--Cookai饼块🍪（💬留言） 2024年7月15日 (一) 13:27 (UTC)[回复]
需要去TWN修改--Dabao qian℡ 2024年7月17日 (三) 15:35 (UTC)[回复]
已修改，待下次MediaWiki版本更新即可应用，请留意技术新闻--Dabao qian℡ 2024年7月20日 (六) 12:21 (UTC)[回复]

存废重新提交

我去看《溯源之惧》的存废讨论，7月4日重新提交，但是我找不到重新提交的页面。标注是重新提交到Wikipedia:页面存废讨论/记录/2024/07/12，但是编辑记录和页面都没有《溯源之惧》的存废讨论移动记录。--Nostalgiacn（留言） 2024年7月15日 (一) 08:55 (UTC)[回复]

@Shizhao：是不是小工具故障？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月15日 (一) 20:22 (UTC)[回复]
@Manchiu。我以前的确遇到过几回，偶尔会故障一下--百無一用是書生 (☎) 2024年7月16日 (二) 01:34 (UTC)[回复]
啊不好意思。已重新提交到Wikipedia:页面存废讨论/记录/2024/07/16#溯源之惧，避免因失误造成讨论不公。。-千村狐兔（留言） 2024年7月16日 (二) 02:25 (UTC)。[回复]

Template:Hlist-comma

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

日维动画条目的各话列表节使用{{剧集列表}}模板时，参数都会使用{{Hlist-comma}}模板，且会根据当前画面宽度自动换行，中维也有相同模板{{Hlist-comma}}，不过不会自动换行，想知道是什么原因。--夏冰 2024年7月16日 (二) 00:18 (UTC)[回复]

这参考Template_talk:Hlist#单独使用{{hlist}}会导致同一页面的{{Infobox}}内建的hlist出现多余的空格，inline-block的问题一修又有另一个的问题--Qqkuro66541（留言） 2024年7月16日 (二) 17:01 (UTC)[回复]

2024年第29期技术新闻

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

技术新闻调查

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

最近更改

  •   维基媒体开发者现在可以正式继续使用Gerrit和GitLab，基于维基媒体基金会于6月24日决定支持在这两个平台共同进行软件开发。Gerrit和GitLab皆是开发者用来编写、审查和部署软件代码的代码储存库，而这些代码支撑著MediaWiki——用于建构维基专案，也是编辑者用于创建和改进内容的工具。这项决定将保障开发者们的生产力，并避免code review——代码审查方面的问题影响用户。更多详情请见迁移状态页面。
  • 维基媒体基金会诚征产品与技术咨询委员会（PTAC）申请人。该小组将汇集技术贡献者与维基媒体基金会，共同开发一个更具弹性、与时俱进的技术平台。委员会成员将对维基媒体运动的产品与技术活动进行评估与咨询，以便我们开发多代的项目。我们正在寻找来自世界各地具有不同项目经验的技术贡献者。请于8月10日前在此申请。
  • 持有回退权的编辑者可以在Android版维基百科App使用新的编辑巡查功能。这些功能包括最近更改的新动态、撤销和回退等相关链接，以及创建和保存个人的用户讨论消息库以供巡查时使用。如果您所在的wiki希望向没有回退权但编辑次数达到一定门槛的用户提供这些功能，您可以联络团队。更多关于此项目，请参阅Diff文章。
  • 在基金会进行联络沟通后，有权访问维基百科图书馆的编辑者再度能使用SpringerLinks中的非开放访问内容。延伸阅读上周完成的22个社群提交工单。

本周更改

未来更改

  •   下周，邀请工作人员、志愿工具维护者和软件开发团队在测试维基上测试临时账号功能。临时账号功能有助于改善wiki上的隐私保护。目前未有其他进一步的部署安排。欢迎在项目讨论页发表意见和提出疑问。 [18]
  • 邀请跨维基上传文件或教导他人如此操作的编辑者，参与维基共享资源上的讨论。共享资源社群正在讨论将能够通过跨维基上传功能（或称上传对话框）上传文件的用户，限缩为维基共享资源上的自动确认用户。这是因为通过这种方式上传的文件大量侵犯了著作权。Commons:跨维基上传有简短摘要，讨论位于Commons:互助客栈。

技术新闻由技术新闻编者撰写，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。 欢迎订阅维基媒体基金会公报获取更多新闻。

MediaWiki message delivery 2024年7月16日 (二) 01:29 (UTC)[回复]

法属圭亚那行政区划列表显示问题

于Phabricator查看
编号T253907的工单

法属圭亚那条目行政区划章节有一个列表，乍一看没什么问题，但只要点击上方任意一个排序，最右边每一格都会变成硕大的法属圭亚那地图。这张表是复制翻译的英维的，英维也有同样问题，请问应怎样改写代码才能修复？--BigBullfrog（𓆏） 2024年7月16日 (二) 04:16 (UTC)[回复]

具体来说发生的是：合并储存格在排序后会被分割，即使排序取消了（回到 状态）依然不会恢复合并。
排序表格遇到合并储存格好像一直是这样。--Cookai饼块🍪（💬留言） 2024年7月16日 (二) 05:15 (UTC)[回复]
phab:T122214提到类似问题，被评为Not a bug。不过当中没有提到“排序取消了依然不会恢复合并。”，可以考虑针对这点提新的工单？--Cookai饼块🍪（💬留言） 2024年7月16日 (二) 05:27 (UTC)[回复]
可以考虑把大地图移出表格。--Cookai饼块🍪（💬留言） 2024年7月16日 (二) 05:21 (UTC)[回复]
phab:T253907。--GZWDer（留言） 2024年7月16日 (二) 14:57 (UTC)[回复]

Template:Cite X

这玩意有必要存在吗？直接在template:cite twitter加个日期检测，自动调整输出不就行了？英维（相信其他站也是）都是直接重定向到cite twitter，本站template:tweet也能正确处理X。最大问题是知道cite twitter存在的人数肯定比知道cite x的多，我相信不少人都“误用旧模板”了。--惣流·明日香·兰格雷不姓式波 2024年7月16日 (二) 05:36 (UTC)[回复]

谁有空研究改写就行了。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月16日 (二) 06:56 (UTC)[回复]
谁能帮忙改写成检测日期输出，在此谢过了，此外template:tweet也需要改一下。--BigBullfrog（𓆏） 2024年7月16日 (二) 12:27 (UTC)[回复]

tweet貌似早前已改好？

name  
@username

text

9999-12-31

name1  
@username1

text1

1-12-31

应该可以大致照抄至cite tweet。--惣流·明日香·兰格雷不姓式波 2024年7月16日 (二) 12:38 (UTC)[回复]

还是有问题的，只是按时间检测修改了图标，reference还是会显示“通过Twitter”而不是“通过X”。--BigBullfrog（𓆏） 2024年7月17日 (三) 01:02 (UTC)[回复]
确实，但这问题应该会随cite twitter的改动而自动解决，因为tweet似乎也只是调用cite tweet。（可能还要找bot把现存的“问题”tweet ref解决一下）--惣流·明日香·兰格雷不姓式波 2024年7月17日 (三) 02:48 (UTC)[回复]
你们好，还请麻烦你们检查一下你们讨论的的话题发表的言论使用的源代码是否有不妥之处，我发表的话题（在下面）的标题（在电脑端维基百科上）显示的有点不对劲，我怀疑是不是你们的模板使用不妥造成的，谢谢。--■■■■（留言） 2024年7月16日 (二) 14:41 (UTC)[回复]

六四事件词条无法正常显示某些模板

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

如题，我发现模板:六四事件在六四事件中不能正常显示，不知道这是不是自己设备的问题，本人试图将模板复制到条目中并提交编辑仍不能解决问题，请有经验的编者协助解决，谢谢！--■■■■（留言） 2024年7月16日 (二) 14:36 (UTC)[回复]

@大慈树王：由于条目中使用太多模版（条目中用到{{ }}的就算）, 该条目已属于Category:引用模板后大小超过限制的页面的隐藏分类，针对该问题，我知道的解法是调整条目内容, 减少模版的使用量。--Wolfch (留言) 2024年7月16日 (二) 14:44 (UTC)[回复]
注意到条目在引用同一本书的不同页码时写成分开的脚注，且部分引用的书籍还包含{{link-en}}绿链，可以想见占用空间颇大，目前已修改成使用单一脚注并用{{rp}}表示页码，似乎底部的模板已经可以显示。Irralpaca（留言） 2024年7月16日 (二) 21:04 (UTC)[回复]

模板折叠问题

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

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

突然发现使用Navbox模板时候，纵然state的一栏采用了collapsed，仍然无法折叠，想请教这是出现了问题还是其他原因，谢谢。--Yutommy 崖上的孤儿 北桥的狗 2024年7月16日 (二) 17:03 (UTC)[回复]

+1同发现问题，比较显著的页面如勒布朗·詹姆斯、长相思 (电视剧)。--桃花影落飞神剑（留言） 2024年7月16日 (二) 21:11 (UTC)[回复]
if args.title and (args.state ~= 'plain' and args.state ~= 'off') then
		if args.state == 'collapsed' then args.state = 'mw-collapsed' end
		tbl
			:addClass('mw-collapsible')
			:addClass(args.state or 'autocollapse')
	end
在Module:Navbox316行加入，请再测试一下，感谢，可参见en:Template_talk:Navbox--Qqkuro66541（留言） 2024年7月16日 (二) 23:02 (UTC)[回复]
@Dabao qian：前面的#在导航模板中淘汰过时的可折叠表格支持后面提过，启用了小工具“可折叠表格”后，这部分其实可以不用改的了。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月17日 (三) 00:25 (UTC)[回复]
@Dabao qian、cwek：zh:MediaWiki:Gadget-collapsibleTables.js，请问是这个吗？预设是开启的。--Qqkuro66541（留言） 2024年7月17日 (三) 01:40 (UTC)[回复]
对的，这个小工具已经有针对原有折叠参数的兼容，导致了Navbox这样参数的两不像。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月17日 (三) 01:44 (UTC)[回复]
所以若然现在要让navbox在载入页面时折叠﹐该如何处理？谢谢！--Yutommy 崖上的孤儿 北桥的狗 2024年7月17日 (三) 04:48 (UTC)[回复]
我好像找到了﹐是不是使用mw-collapsed？--Yutommy 崖上的孤儿 北桥的狗 2024年7月17日 (三) 04:52 (UTC)[回复]
参见Module_talk:Navbox#编辑请求_2024-07-17，从粤维搬了个hack过来，等待管理员应用即可。--Dabao qian℡ 2024年7月17日 (三) 05:34 (UTC)[回复]
感谢！--Yutommy 崖上的孤儿 北桥的狗 2024年7月17日 (三) 09:05 (UTC)[回复]
en区的讨论页里似乎提到过，不修改是由ResourceLoader懒加载，修改后直接由解析器预处理，性能上会有所提升--Dabao qian℡ 2024年7月17日 (三) 06:31 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

崩溃

于Phabricator查看
编号T370304的工单

维基百科是不是刚刚崩溃了？有人知道发生什么了吗？--Martin 去我的签名簿签名！！ 2024年7月19日 (五) 00:56 (UTC)[回复]

见上。--碟之舞📀💿 2024年7月19日 (五) 04:08 (UTC)[回复]
EST时间下午遇到过MediaWiki internal error.--桃花影落飞神剑（留言） 2024年7月19日 (五) 04:08 (UTC)[回复]

首页的“维基百科”四字过大

还是Wikipedia:互助客栈/技术/存档/2024年6月#首页顶栏排版错乱，这次是Vector 2022皮肤。依照mw:Heading HTML changes，昨日开始h1标题都会嵌套一层<div class="mw-heading mw-heading1">，故首页上的“维基百科”四个大字变成了原本的1.8倍大。Irralpaca（留言） 2024年7月19日 (五) 02:05 (UTC)[回复]

还有一个bug，单击搜索框后会变成英文
动图--Bovemdep（留言） 2024年7月19日 (五) 09:19 (UTC)[回复]
点击前是MediaWiki:Searchbutton，点击后变成了MediaWiki:Cdx-search-input-search-button-label--百無一用是書生 (☎) 2024年7月19日 (五) 11:52 (UTC)[回复]
于Phabricator查看
编号T370517的工单
--百無一用是書生 (☎) 2024年7月19日 (五) 12:01 (UTC)[回复]
2010版变得与下方标语一样大。已经懒得吐槽近期更改了。——暁月凛奈 (留言) 2024年7月19日 (五) 09:29 (UTC)[回复]
Special:Diff/83427432/83472463，好了。——暁月凛奈 (留言) 2024年7月19日 (五) 09:35 (UTC)[回复]
看起来好像还是有点和以前不一样，“人人可编辑的自由百科全书”似乎离底边比以前近了--百無一用是書生 (☎) 2024年7月19日 (五) 09:47 (UTC)[回复]
那在TemplateStyles里面给mw-heading1再加上padding: 0;？--Irralpaca（留言） 2024年7月19日 (五) 14:08 (UTC)[回复]

wrap换行

在Template:时代年度风云人物中使用了模板{{wrap}}，但是未能正常换行，在Template:奥斯卡荣誉奖也试着加了{{wrap}}也未能换行。--Kethyga（留言） 2024年7月19日 (五) 10:45 (UTC)[回复]

英文维基en:MediaWiki:Common.css#L-376 有定义样式，而中文维基没有，另{{Normalwraplink}}、{{Allow wrap}}，如有新增样式，可一倂更新，感谢。--Qqkuro66541（留言） 2024年7月21日 (日) 16:25 (UTC)[回复]

captcha

可不可以行行好，让captcha可以接受全型英文，别让人敲了两个字母才发现不对又切回来，然后为了编辑又要切回去，很好玩是不是？

如果不会，我教你。建个一维阵列，以A到Z和a到z或其unicode为索引，内容则是全型字母，这就切换过去了，而且是O(1)。简单吧？

如果还要拿什么安全来说嘴，那拜托内容不要用英文，用中文字好吗？这不是更安全吗？打完字也不用切换全型半型了，拜托拜托。

我没有请人拿掉这个没经过投票就私加的captcha喔，没有喔。我是拜托在展现想加就加的莫大权力之后，也展现一下程式能写就写，能力跟权力匹配，这不过分吧？我知道一定有人要飞什么安全的大帽子过来，那就改成中文字让机器人更没机会运作，这方向没有错吧？拜托拜托，行行好。--2603:8000:500:FB00:89EE:D188:8491:54F3（留言） 2024年7月20日 (六) 03:38 (UTC)[回复]

@August0422：请不要乱误导他人，这怎么看都跟方针没有半点关系--SunAfterRain 2024年7月22日 (一) 05:31 (UTC)[回复]
准确来说，这是基金会添加的插件mw:Extension:ConfirmEdit，我们本地社群都是普通用家，管理配置和开发维护都是基金会的事。如果对于是否启用插件有意见，请去meta:Requests for comment请求讨论意见（并且期望有人关注）；如果对于代码实现逻辑有意见，请去phab:tag/confirmedit_captcha_extension开工单反馈，或者参与到相关的开发小组中。跟我们本地社群喷这个问题毫无用处。或者考虑注册一个账号，注册账户并达到自动确认用户级别可以免除这个验证。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月20日 (六) 06:50 (UTC)[回复]
您可以提交功能请求，详细信息见此处。还有中文问题，这个验证码本身就是在西文语境下制作的，文化隔阂的问题不止一人提过，但是都找不到合适的开源替代品。--碟之舞📀💿 2024年7月20日 (六) 15:26 (UTC)[回复]
这个我觉得可以请基金会做一下全半形映射处理--SunAfterRain 2024年7月22日 (一) 05:30 (UTC)[回复]
这本地没办法处理，你在这边讲没用。--冥王欧西里斯（留言） 2024年7月24日 (三) 14:02 (UTC)[回复]

Campaignbox被默认为开启状态，使用指令皆无法更改

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

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

在模板:Campaignbox War of the Spanish Succession这个模板中，我尽了一切办法仍然无法让他在读者刚开始阅读时是闭合状态，明明指令与其他模板以及英文维基对应模板相同，但其他模板就没有这个问题，想请大佬们帮忙解决 --Waylon1104（留言） 2024年7月20日 (六) 15:16 (UTC)[回复]

@Waylon1104 完成。
虽然可以个别页面处理，但collapsed的无效显然需要导入机器人批量替换成uw-collapsed，丧失作用的页面过多。--Rastinition（留言） 2024年7月20日 (六) 15:21 (UTC)[回复]
好的了解，太感谢您了--Waylon1104（留言） 2024年7月20日 (六) 15:30 (UTC)[回复]
@Rastinition：能不能直接修改模板代码，相容参数啊？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月20日 (六) 17:31 (UTC)[回复]
参见Module_talk:Navbox#编辑请求_2024-07-17--Dabao qian℡ 2024年7月20日 (六) 18:26 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

快速删除候选问题

[[Category:快速删除候选]]里面的原神系列条目没有被任何人挂上速删模版，但是却出现在这个分类里面，这是怎么回事？--日期20220626（留言） 2024年7月22日 (一) 07:16 (UTC)[回复]

百分之百是其他页面导致。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月23日 (二) 23:04 (UTC)[回复]
我当时也是这么认为，但是没找到是哪个页面导致的，不过现在好了。--日期20220626（留言） 2024年7月24日 (三) 00:21 (UTC)[回复]
嵌入的模板Template:原神 (Special:Diff/83507391/83507391)--Kethyga（留言） 2024年7月24日 (三) 11:39 (UTC)[回复]

2024年第30期技术新闻

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

功能周报

  • 监管员现在可以对账号实施全域封禁。在此更改之前，全域封禁仅能针对IP地址和IP范围实施。不同于全域锁定，全域账号封禁不会将被封禁的用户登出。全域锁定不受此更改影响。新的全域账号封禁功能与临时账号项目有关，这种新型态的用户账号用于取代未注册编辑者的IP地址，使其不再公开可见。
  • 本周稍晚，FlaggedRevs（标记修订，又称“待定更改”）的界面将得到改进，与MediaWiki的其他界面及维基媒体设计系统Codex保持一致。移动设备和Minerva皮肤上的FlaggedRevs界面体验原本与他处不一致，后经由Growth团队和一些志愿者修复并移植到Codex。 [19]
  • 维基媒体网站用户现在可以通过GlobalVanishRequest提交账号隐退请求。当贡献者希望永远停止编辑时，可以使用此功能。它可以帮您隐藏过去的关联和编辑，以保护您的隐私。一旦处理完成，该账号将被锁定并重新命名。 [20]
  • 您试过使用手机监控和应对维基百科中的破坏行为吗？一篇关于移动应用程序中的巡查功能的Diff文章重点介绍了一些新功能，包括滑动浏览最近更改动态以及个人化的用户讨论消息库，供使用手机巡查时使用。
  • 维基媒体贡献者和GLAM机构（美术馆、图书馆、档案馆及博物馆）现在可以使用“共享资源影响力指标”分析面板，了解与衡量维基共享资源对于创建高品质百科全书内容的影响。该面板提供诸如分类每月编辑数、浏览量最高的文件、使用共享资源图片的维基条目等方面的分析。有了这些新的数据转储，GLAM机构可以更精准衡量将内容引入数位共享资源的投资回报率。 [21]

项目近况

  • 快来在崭新重启的社群愿望清单分享您对改善维基的想法。社群愿望清单是供志愿者分享他们改善维基运作方式的想法（称为愿望）的维基媒体论坛。新版愿望清单始终开放，wikitext和可视化编辑器皆可使用，并允许以任何语言提交愿望。

增广见闻

  • 你有没有想过维基媒体软件如何支持300多种语言？这比Google Chrome的界面多了253种语言，而这绝非偶然。维基媒体基金会的语言与产品在地化团队通过调整所有工具和界面，使其适应您的语言和其他语言，为您提供支持。阅读Diff文章了解更多关于该团队及其即将开展的工作。
  • 维基媒体如何在维护如此频繁使用的网站之时，同时建构创新和实验性的产品？维基媒体基金会职员Johan Jönsson近期发表的一篇Diff文章，重点介绍了基金会的“未来受众”计划的工作，其目标不是建构完善的产品，而是测试新的想法，例如ChatGPT插件和“加入事实”等，帮助维基媒体走向未来。

技术新闻由技术新闻编者撰写，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。 欢迎订阅维基媒体基金会公报获取更多新闻。

MediaWiki message delivery 2024年7月23日 (二) 00:03 (UTC)[回复]

默认折叠的侧栏模板不居右

见国家国防动员委员会。中华人民共和国中央军事委员会主席#参见如果没有上方的侧栏，也是如此。--YFdyh000（留言） 2024年7月23日 (二) 17:48 (UTC)[回复]

@Dabao qian：您的这笔编辑把模板改爆了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月23日 (二) 23:02 (UTC)[回复]
但是这样直接用表格语法编写的Infobox或者Sidebar模板是不规范的，等Common.css里的样式全部下放到模板样式之后这些就都会爆掉，长远考虑这类直接用I表格语法写的Infobox或者Sidebar都需要完全重写。--Dabao qian℡ 2024年7月24日 (三) 03:38 (UTC)[回复]

使用“快速回复”回复任一话题之后，“快速编辑”按钮消失

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

“快速回复”即“参数设置->编辑->讨论页”的第一个选项“启用快速回复”功能。（我的设置中6个选项都是勾选的。）在任何讨论页点“回复”按钮回复任何留言之后，章节旁的“快速编辑”按钮就会消失，需要重新刷新页面才会出现，非常不便于“回复”后快速修改留言错字等操作。（另外，我开启了“查看源代码”的显示，它也会消失，即“快速回复”之后“编辑源代码/查看源代码｜快速编辑”三个按钮只会剩下“编辑源代码”一个。）印象中这个问题似乎也是持续存在的，至少已经存在好几个月了。勿推荐我使用CD工具解决这一问题，因为我之前尝试该工具的第一笔编辑就遭遇了重大Bug，回复一条留言结果新增回复直接出现在了前面十万八千里的完全不相关话题下  囧rz……--——自由雨日（留言・贡献） 2024年7月23日 (二) 18:50 (UTC)[回复]

test--百無一用是書生 (☎) 2024年7月24日 (三) 02:26 (UTC)[回复]
未发现问题。另，“快速编辑”按钮是什么？我没有看到过。会不会是小工具或用户脚本的问题造成的？--百無一用是書生 (☎) 2024年7月24日 (三) 02:28 (UTC)[回复]
啊，“快速编辑”就是“WP:Wikiplus”啊，前辈不用的吗？--——自由雨日（留言・贡献） 2024年7月24日 (三) 02:33 (UTC)[回复]
不用这个。那看来很可能就是这个工具的问题了--百無一用是書生 (☎) 2024年7月24日 (三) 02:44 (UTC)[回复]
另外“查看源代码”按钮也会消失（即参数设置->小工具->界面显示工具中的“编辑页签及编辑段落链接（[编辑]）附带检视源代码（[源码]）链接”），应该也存档至该小工具？（存废讨论页中）TW的“关闭存废”按钮并不会消失，故确实应该是每个小工具各自的问题。--——自由雨日（留言・贡献） 2024年7月25日 (四) 09:16 (UTC)[回复]
快速回复应该是会刷新整个内容块（content div），导致脚本的更新全部没掉。CD最近确实有问题，我已经卸了，现在用回快速回复功能怪不习惯的。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月24日 (三) 03:40 (UTC)[回复]

求助

请求协助添加跨语言链接

本主题或以下段落文字，在讨论结束后应存档至Talk:瓦西利斯·波利蒂斯。

我新创建了页面瓦西利斯·波利蒂斯，想建立到英语维基页面Vasilis Politis的跨语言链接。不过我自己完成不了这件任务，所以想请各位帮下忙，多谢。--Fgju（留言） 2024年7月17日 (三) 12:28 (UTC)[回复]

已完成。--Wolfch (留言) 2024年7月17日 (三) 12:44 (UTC)[回复]

请求协助上传档案 2024-07-17 16:24

我想要上传的图片来源是<https://a5.mzstatic.com/us/r1000/0/Music122/v4/dc/74/1c/dc741c3c-6592-ea72-c79a-1a58a2a70fc4/4894894575142.jpg>，想要使用在[[卡西莫多的礼物）]]的<资讯框>。 --VerregneteNacht（留言） 2024年7月17日 (三) 16:24 (UTC)[回复]

 未完成：条目不存在，请先创建条目，再请求上传图片。----伞木 霙留言 2024年7月21日 (日) 13:37 (UTC)[回复]

我在翻译en:Hydrogen economy碰到一个表格，不晓得是否有先进能帮忙，填上隔线？

根据英文版翻译而来的源代码如下。如果能添上隔线，或许对于读者会较易阅读吧。谢谢。

生产方式 注释 目前成本 (2020年–2022年) 预计2030年成本 预计2050年成本
灰氢 (未包含碳税)
国际能源署提供[1] 2022年6月估计的成本（俄罗斯入侵乌克兰导致天然气价格飙升） 2021: 1.0–2.5 – –
2022: 4.8–7.8
普华永道提供[2] 2021: 1.2–2.4
蓝氢
国际能源署提供[1] 2022年6月（俄罗斯入侵乌克兰导致天然气价格飙升）估计的成本 2021: 1.5–3.0 – –
2022: 5.3–8.6
英国能源安全及净零部 提供[3] 范围受天然气价格影响 2020: 1.6–2.7 1.6–2.7 1.6–2.8
美国顾问公司GEP Worldwide提供[4] 2022: 2.8–3.5 - -
国际智囊团能源转型委员会（英语：Energy Transitions Commission）提供[5]（p. 28） 2020: 1.5–2.4 1.3–2.3 1.4–2.2
绿氢
国际能源署提供[1] 对2030年及2050年的估计，把在条件良好地区建设太阳能发电厂的假设列入 2021: 4.0–9.0 <1.5 <1.0
2022: 3.0-4.3
英国政府提供[3] 使用电网电力（适用于英国），范围取决于电价、电解技术和成本。 2020: 4.9–7.9 4.4–6.6 4.0–6.3
利用闲置可再生电力（适用于英国），范围取决于电解技术和成本。 2020: 2.4–7.9 1.7–5.6 1.5–4.6
国际再生能源总署（IRENA）提供[6] 2020: 2.2–5.2 1.4–4.1 1.1–3.4
GEP Worldwide[4] 资料来源指出从2010年起，绿氢生产成本已下降60% 2022: 3.0–6.0
投资银行Lazard提供[7] 2022: 2.8–5.3
普华永道提供[2] 2021: 3.5–9.5 1.8–4.8 1.2–2.4
能源转型委员会提供[5]（p. 28） 2020: 2.6–3.6 1.0–1.7 0.7–1.2

--ThomasYehYeh（留言） 2024年7月17日 (三) 23:49 (UTC)[回复]

见此，已填上“隔线”。
生产方式 注释 目前成本 (2020年–2022年) 预计2030年成本 预计2050年成本
灰氢 (未包含碳税)
国际能源署提供[1] 2022年6月估计的成本（俄罗斯入侵乌克兰导致天然气价格飙升） 2021: 1.0–2.5 – –
2022: 4.8–7.8
普华永道提供[2] 2021: 1.2–2.4
蓝氢
国际能源署提供[1] 2022年6月（俄罗斯入侵乌克兰导致天然气价格飙升）估计的成本 2021: 1.5–3.0 – –
2022: 5.3–8.6
英国能源安全及净零部 提供[3] 范围受天然气价格影响 2020: 1.6–2.7 1.6–2.7 1.6–2.8
美国顾问公司GEP Worldwide提供[4] 2022: 2.8–3.5 - -
国际智囊团能源转型委员会（英语：Energy Transitions Commission）提供[5]（p. 28） 2020: 1.5–2.4 1.3–2.3 1.4–2.2
绿氢
国际能源署提供[1] 对2030年及2050年的估计，把在条件良好地区建设太阳能发电厂的假设列入 2021: 4.0–9.0 <1.5 <1.0
2022: 3.0-4.3
英国政府提供[3] 使用电网电力（适用于英国），范围取决于电价、电解技术和成本。 2020: 4.9–7.9 4.4–6.6 4.0–6.3
利用闲置可再生电力（适用于英国），范围取决于电解技术和成本。 2020: 2.4–7.9 1.7–5.6 1.5–4.6
国际再生能源总署（IRENA）提供[8] 2020: 2.2–5.2 1.4–4.1 1.1–3.4
GEP Worldwide[4] 资料来源指出从2010年起，绿氢生产成本已下降60% 2022: 3.0–6.0
投资银行Lazard提供[9] 2022: 2.8–5.3
普华永道提供[2] 2021: 3.5–9.5 1.8–4.8 1.2–2.4
能源转型委员会提供[5]（p. 28） 2020: 2.6–3.6 1.0–1.7 0.7–1.2

--——自由雨日（留言・贡献） 2024年7月17日 (三) 23:54 (UTC)[回复]

只要在第一行加入class="wikitable"即可。--——自由雨日（留言・贡献） 2024年7月17日 (三) 23:55 (UTC)[回复]
谢谢。学到了。--ThomasYehYeh（留言） 2024年7月19日 (五) 05:29 (UTC)[回复]

参考资料

  1. ^ 1.0 1.1 1.2 1.3 1.4 1.5 Global Hydrogen Review 2022. IEA. : 93 [2023-08-25] （英国英语）. 
  2. ^ 2.0 2.1 2.2 2.3 PricewaterhouseCoopers. Green hydrogen economy – predicted development of tomorrow. PwC. [2023-08-25] （en-gx）. 
  3. ^ 3.0 3.1 3.2 3.3 Hydrogen Production Costs 2021 annex: Key assumptions and outputs for production technologies. GOV.UK. [2023-08-25] （英语）. 
  4. ^ 4.0 4.1 4.2 4.3 Saini, Anshuman. Green & Blue Hydrogen: Current Levelized Cost of Production & Outlook | GEP Blogs. www.gep.com. January 12, 2023 [2023-08-25] （英语）. 
  5. ^ 5.0 5.1 5.2 5.3 引用错误：没有为名为:4的参考文献提供内容
  6. ^ IRENA (2020), Green Hydrogen Cost Reduction: Scaling up Electrolysers to Meet the 1.5 °C Climate Goal, International Renewable Energy Agency, Abu Dhabi, p. 91.
  7. ^ 2023 Levelized Cost Of Energy+. Lazard. 2023-04-12: 27 [2023-08-25] （英语）. 
  8. ^ IRENA (2020), Green Hydrogen Cost Reduction: Scaling up Electrolysers to Meet the 1.5 °C Climate Goal, International Renewable Energy Agency, Abu Dhabi, p. 91.
  9. ^ 2023 Levelized Cost Of Energy+. Lazard. 2023-04-12: 27 [2023-08-25] （英语）. 

请求协助上传档案 2024-07-18 09:54

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

 未完成：未说明图片来源。----伞木 霙留言 2024年7月21日 (日) 13:37 (UTC)[回复]

刚才发表一篇低碳电力（翻译自en:Low-carbon electricity）碰到的问题

我把en:Low carbon electricity翻译为中文。文中有一节是摘录自en:Sustainable energy（有一篇算是简短的永续能源与之连结），但我在低碳电力文中引用永续能源时，总会被引导至再生能源，而中文版中再生能源与永续能源是两篇不同的文章，而en:Sustainable energy和en:Renewable energy也是两篇不同的文章。不知道此问题该如何解决？--ThomasYehYeh（留言） 2024年7月19日 (五) 05:39 (UTC)[回复]

什么叫“引用永续能源……”，能否实际操作一下我看看？--——自由雨日（留言・贡献） 2024年7月19日 (五) 05:57 (UTC)[回复]
不好意思，我正准备长篇大论，为我的问题提出说明。结果上了刚才发表的低碳电力，发现我之前提的问题已经不见了。谢谢。--ThomasYehYeh（留言） 2024年7月19日 (五) 08:49 (UTC)[回复]

阿赖耶、阿摩罗、涅槃寂静三页面之删除讨论

本人因“没有资格”而无法提出存废讨论。原讨论如下：
此三个“数字单位”最早出现于日文维基百科ja:命数法的版本5493605（2006年4月28日），编辑者为匿名IP（ja:特别:投稿记录/59.120.251.217），未列出参考文献，且该IP的唯一贡献即为上述编辑。最后这些“数字单位”于2022年4月21日经讨论后被删除（ja:命数法的版本89148055）。此参考资料中列出最小的单位为“静”或“清净”。此外，本人亲自用搜索引擎搜寻了“涅槃寂静+单位”等组合，其结果均为个人网志，均著于2006年4月28日至2022年4月21日之间，其参考文献或无，或为上述日文维基百科页面，或只提到某“佛典”而未明确指定哪一部，可见该错误流传之广，甚至NHK教育频道的《ja:にほんごであそぼ》中的歌曲《1より小さい数》都提到了这三个“单位”。
参考日文维基百科对此三个“数字单位”页面的删除讨论：ja:Wikipedia:削除依赖/阿摩罗と阿赖耶、ja:Wikipedia:削除依赖/涅槃寂静 (数)——OosakaNoOusama（留言） 2024年7月19日 (五) 06:49 (UTC)[回复]

是不是LTA:Qqqyyy干的？他喜欢“恶搞”佛教相关条目。--Thyj (คุย) 2024年7月19日 (五) 07:49 (UTC)[回复]
现阶段还不能确认是不是Qqqyyy，但我发现Qqqyyy有一曾用IP为59.120.117.226，而日文维基百科上的IP同样以59.120开头，不知道这两个有什么关系。——OosakaNoOusama（留言） 2024年7月19日 (五) 09:40 (UTC)[回复]
有可能就是他，因为IP段相近。查询结果是来自台湾台北市或高雄市的IP。--Thyj (คุย) 2024年7月19日 (五) 11:58 (UTC)[回复]

关于台风模版

最近小弟在东京台风中心热带气旋等级中新增了两个新等级（强烈台风VSTY及猛烈台风VITY）。但在模板:Infobox hurricane current的编辑中遇到困难。具体问题为在模版的JMAcategory参数中输入TY，它的右上方就会显示出TY，但小弟在该参数中输入VSTY/VITY，右上方只会显示TC，尝试了多次也未能解决问题。故在此寻求帮助。 p.s.该模板VITY/VSTY背景颜色及文字显示(强烈台风/猛烈台风)目前都没有问题，唯右上方小方格显示出现问题--Aaroncheung 895（留言） 2024年7月20日 (六) 04:50 (UTC)[回复]

目前已成功修复--Aaroncheung 895（留言） 2024年7月20日 (六) 08:06 (UTC)[回复]

关于第一手来源资料

如果我引用照片中的内容来填充条目内容，如某公园公告牌，是否满足WP:可供查证和WP:非原创研究？--——“あたいってば最⑨ね！” 2024年7月20日 (六) 08:04 (UTC)[回复]

您是说想将公园公告牌中的文字作为照片上传吗？这可能会侵犯著作权，建议谨慎。来源评估方面，我个人认为官方设置的公告牌是可以作为辅助性的可靠来源的，但不应作为条目内容的主要来源。--——自由雨日（留言・贡献） 2024年7月20日 (六) 09:18 (UTC)[回复]
若不上传照片，还能根据公告牌作为来源吗？——“あたいってば最⑨ね！” 2024年7月20日 (六) 10:31 (UTC)[回复]
难道书籍必须存在PDF链接才能用作来源吗？--——自由雨日（留言・贡献） 2024年7月20日 (六) 11:23 (UTC)[回复]
书籍不一样，出版物内容在出版时被固定，公告牌则不是。--YFdyh000（留言） 2024年7月20日 (六) 12:37 (UTC)[回复]
电子出版物（即网站，国标文献类型标识代码“EB”）内容远比公告牌不固定吧？如果怕“不固定”的话，像电子资源那样写上“access-date”不就行了（）--——自由雨日（留言・贡献） 2024年7月20日 (六) 13:01 (UTC)[回复]
但网页容易被查证，大多也能网页存档。像是一般网页不是“已发表且可靠”，可信来源提供的一手来源才行，所以一般人拍的照片应不属于已可靠发布。--YFdyh000（留言） 2024年7月20日 (六) 13:30 (UTC)[回复]
我个人是在曲院风荷条目用过景区标牌（）--——自由雨日（留言・贡献） 2024年7月20日 (六) 13:02 (UTC)[回复]
建议最低限度的使用。如果未经出版物或官方发表，严格来说不符“已发表且可靠的第一手来源”，一张照片本身难以证明由谁、在哪、设立了多久。--YFdyh000（留言） 2024年7月20日 (六) 12:41 (UTC)[回复]
所以您认为至少需要有照片才能作为来源，且难以认为是“可靠的第一手来源”，所以最好尽量不要使用，是这样吗？--——“あたいってば最⑨ね！” 2024年7月20日 (六) 12:47 (UTC)[回复]
是，不然哪天牌子撤了或改了，先前内容就是无头案。网友上传的照片，有时会出现作伪之争。不能基于一手内容作延伸解读。--YFdyh000（留言） 2024年7月20日 (六) 12:51 (UTC)[回复]

周小川

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

我注意到维基百科上的文章说，经济学家周小川出生时，他的父母在黑龙江省东安市东北军工部直属二厂（东安电器厂）工作。但出生地却标注为宜兴。这是一个奇怪的差异。--87.1.243.195（留言） 2024年7月20日 (六) 16:33 (UTC)[回复]

感谢您指出该问题，我暂时给加了个模板……--——自由雨日（留言・贡献） 2024年7月20日 (六) 17:00 (UTC)[回复]
已修改。疑似有少数来源（[22]、变革 元宇宙与数字经济[M]. 2022）误称生于宜兴市。--YFdyh000（留言） 2024年7月20日 (六) 18:22 (UTC)[回复]

请求协助上传档案 2024-07-21 04:20

我想要上传的图片来源是<从某个网址下载，请提供网址 / 自行拍摄>，想要使用在请提供条目名称（如果条目还不存在，请先建立条目再请求上传文件）的<资讯框/某个段落，请说明>。 --Papa1qq（留言） 2024年7月21日 (日) 04:20 (UTC) https://www.facebook.com/photo/?fbid=1159051634158935&set=a.761152617282174[回复]

想要使用在Centaur Cafe Mega 150条目作为介绍，不知道是否可行?谢谢

 未完成：条目不存在，请先创建条目，再请求上传图片。----伞木 霙留言 2024年7月21日 (日) 13:37 (UTC)[回复]

如何将Wikiplus的默认编辑摘要“//Edit via Wikiplus”去除

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

WP:Wikiplus的设置参数一章提到可以通过修改“defaultSummary”参数来修改默认编辑摘要，但是去哪里设置“defaultSummary”这个参数呢……工具->Wikiplus设置中是空白页面。顶注提示的“请在下方按规范修改Wikiplus参数”，“规范”在哪里（）--——自由雨日（留言・贡献） 2024年7月21日 (日) 05:26 (UTC)[回复]

设置中加"defaultSummary":""。——暁月凛奈 (留言) 2024年7月21日 (日) 06:12 (UTC)[回复]
似乎不行？设置框下方会提示“Unexpected non-whitespace character after JSON at position 16 (line 1 column 17)”，如果点“提交”的话会直接无法成功，左下角弹出“设置存在语法错误 请检查后重试”。--——自由雨日（留言・贡献） 2024年7月21日 (日) 06:22 (UTC)[回复]
{
  "key": "value",
  "language": "zh-cn",
  "defaultSummary": "",
  "esc_to_exit_quickedit": "true"
}

直接复制到设置中呢？——暁月凛奈 (留言) 2024年7月21日 (日) 06:38 (UTC)[回复]

设置是保存成功了，但……貌似“//Edit via Wikiplus”编辑摘要还在（已使用Shift+刷新清除缓存并重进）？  囧rz……--——自由雨日（留言・贡献） 2024年7月21日 (日) 06:46 (UTC)[回复]
试试将"defaultSummary": "",改成"defaultSummary": null,？——暁月凛奈 (留言) 2024年7月21日 (日) 06:59 (UTC)[回复]
刚才试了一下，Wikiplus似乎不支持空的编辑摘要，留空即默认“// Edit via Wikiplus”，像我的换成中文“// 使用Wikiplus编辑”就可以正常使用。放null也没有作用。您要实在不想看见那个默认编辑摘要不如就放个句号或者空格吧。--微肿头龙（留言） 2024年7月21日 (日) 07:01 (UTC)[回复]
我一直是默认空摘要。我一直在用旧点的那个版本。——暁月凛奈 (留言) 2024年7月21日 (日) 07:02 (UTC)[回复]
我发现改成空格或任何其他字符之后，（本来点击章节的“编辑”按钮会自动加上章节名称的，）任何编辑就都没有章节名称，只有那个改的字符（比如空格）了……算了，还是不改了吧  囧rz……（本来我想改是因为我觉得标签栏已经会显示“Wikiplus”了，再在摘要里显示一遍就很多余，既是视觉上的冗余信息又占用维基百科服务器的存储空间（）--——自由雨日（留言・贡献） 2024年7月21日 (日) 07:14 (UTC)[回复]

请求协助上传档案 2024-07-21 12:17

我想要上传的图片来源是 青岛二中校徽 青岛二中logo，想要使用在青岛第二中学的资讯框。 --YuzhenQin（留言） 2024年7月21日 (日) 12:17 (UTC)[回复]

 完成。--伞木 霙留言 2024年7月21日 (日) 13:32 (UTC)[回复]

求助Infobox school地图

请问类似于天津市耀华中学的Infobox school中的地图是怎么添加的，在源代码里没有看到。--YuzhenQin（留言） 2024年7月22日 (一) 01:15 (UTC)[回复]

我猜测您想要添加地图的条目应该是青岛第二中学？它的维基数据项目d:Q7267809上原本没有坐标，在维基数据那边添加之后已经可以在条目内看到地图了。Irralpaca（留言） 2024年7月22日 (一) 02:05 (UTC)[回复]
感谢--YuzhenQin（留言） 2024年7月22日 (一) 02:33 (UTC)[回复]

关于用户:Zhangmoon618大量建立侵权条目，需要更多的人来协助确认其创建的条目是否有没被发现的侵权

如题，我这两天发现用户:Zhangmoon618于2012年创建的红太阳广场毛泽东塑像、武汉防汛纪念碑、汉口商业银行大楼等3条目涉嫌侵权。查阅该用户讨论页历史，可知该用户创建的条目已经被多次提出版权验证。其至今已经创建了7000+条目，我有理由怀疑在这7000+条目中仍然有未发现的侵权条目，需要更多用户协助确认该用户创建的条目是否仍有未被发现的侵权。--——— 红渡厨（留言・贡献） 2024年7月22日 (一) 06:13 (UTC)[回复]

@0xDeadbeef：--——自由雨日（留言・贡献） 2024年7月22日 (一) 06:30 (UTC)[回复]
这位阁下自己以前有清理过一次了，恐怕是没有完全清理完。（2023年7月时有被WMLO丢上客栈讨论，后于2023年10月清理完一大批。）--WiTo🐤💬 2024年7月22日 (一) 08:39 (UTC)[回复]
原来就是他呀……（之前看到过他的“致歉信”，也是在23·7存档，印象还挺深的）--——自由雨日（留言・贡献） 2024年7月22日 (一) 09:13 (UTC)[回复]
这些条目创建时间超过10年，去年7月我集中清理了近一年创建的生物类条目，因为这些条目是如何创建的我很清楚。目前没有筛查那么久远，而且本人也不可能还记得当年是如何创建的，如有侵权可以提删，本人仍然愿意接受社群任何监督和处分。我确实创建了7000余条目，但主要是生物和地理类条目。早年创建的生物条目都很小，我记得最初自己缺乏查找文献的能力，每个生物分类条目几乎就是一个小列表。地理类条目主要集中在湖泊和河流，主要引用的文献是《中国湖泊志》与《中国河湖大典》，这类条目估计占了一半，这类条目我可以保证没有侵权，可以随便验证。如果还有侵权的条目可能就集中在一时兴起创建的文保单位、热门事件、人物等很杂的条目，因为事件跨度很大，不太容易查找。不过9月以后如果我有时间，我会自己试着再筛查一遍。--zhangmoon618（留言） 2024年7月22日 (一) 11:43 (UTC)[回复]
Wikipedia:互助客栈/其他#设立编者著作权调查 是不是可以用下这边的工具，如果当事人忘记写了什么的话 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月22日 (一) 13:36 (UTC)[回复]
忘了回复这里了。这几天我比较忙，估计没有时间。但是Zhangmoon618的编辑历史非常长，生成出来有足足8页。我之前在考虑是否将diff添加字节下限从+150调整到更高一点而减少需要查核的内容。--0xDeadbeef (留言) 2024年7月23日 (二) 14:31 (UTC)[回复]

技术求助

本主题或以下段落文字，在讨论结束后应存档至Talk:塞特波齐战役。

我最近编写的条目“塞特波齐战役”在英维中脚注采Sfn格式，将其移动到中维后我加了一个“ref=harv”以使其能正常引证，但第一个脚注“Dotson 2006”却无法链到来源上，明明来源的作者和年份参数都没问题，但就是无法解决该疑难，特就此问题前来求助。--Yankees from Canada（留言） 2024年7月23日 (二) 00:32 (UTC)[回复]

@Yankees from Canada 已修复。ref=harv写到Google Books模板里面了。--Kethyga（留言） 2024年7月23日 (二) 00:40 (UTC)[回复]

User:Pclee9413/马纪筠

表达式错误：预期外的<运算符。(±)合并到马纪筠。不让人自删。马纪筠正式条目写了，不想留底。

提交的维基人及时间：Pclee9413（留言） 2024年7月24日 (三) 14:58 (UTC)--Pclee9413（留言） 2024年7月24日 (三) 14:58 (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)[回复]
如果此处的祭如同战祭、丰年祭，是指庆典或活动的话，可参见《教育部异体字字典》释义五。[23]--夜月辰星（留言） 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)[回复]

如果没有其他意见，会采用折中做法。--Nostalgiacn（留言） 2024年7月19日 (五) 15:23 (UTC)[回复]
(＋)赞成。--AT 2024年7月20日 (六) 09:37 (UTC)[回复]
(＋)赞成。
--Daniel1023（留言） 2024年7月21日 (日) 04:11 (UTC)[回复]
@Nostalgiacn：届时“祭典”与“节日”的母子分类关系？祭典算是一种节日吧，所以前者归至后者？然后我可以协助恢复“日本节日”分类的编辑历史。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月21日 (日) 08:22 (UTC)[回复]
“祭典”与“节日”为Category:日本年度活动的平行分类，恢复“日本节日”分类以对齐其他语言维基，减少混乱与不协调。--Nostalgiacn（留言） 2024年7月21日 (日) 14:58 (UTC)[回复]

已经更新了相关分类，并在“日本节日”和“日本祭典”加入说明。

由于平衡分类的做法，原本“冲绳县的祭”是用于记录琉球传统节日，没有符合“祭典”，所以先恢复到原本的“Category:东亚传统节日”和“Category:亚洲各民族节日”分类方式。日后如有这些冲绳祭典的条目，可以另建“冲绳县祭典”分类归纳。

冲绳的分类涉及一个问题，法律上日本不承认有少数民族，实际上日本有少数民族。由于中维在两岸问题的多年钻研，所以对类似问题更为敏感，相关分类处理应该更为细腻，兼容一些中维独有的分类系统。--Nostalgiacn（留言） 2024年7月23日 (二) 03:22 (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)[回复]
据我所知是没有，比如中国高等植物数据库全库记载的榉树，“国外分布”一栏只写着朝鲜和日本，而其他参考文献是明确有写它分布在韩国的（[24]），我也因此认为其他相关的以中国高等植物数据库全库为参考的植物条目中的“朝鲜”，应该指的是朝鲜地区/半岛，而不是朝鲜民主主义人民共和国。就算确实指后者，写朝鲜地区/半岛也没错，且不会出现歧义的问题。----FradonStar|八闽风云 2024年7月3日 (三) 04:15 (UTC)[回复]
我觉得下结论可能原创研究。如无额外来源证明，我宁可取消内部链接。扩大范围恐怕是曲解来源。
按使用帮助文档最后一页，国外分布可能写中南半岛、马来半岛。但是，没有写成朝鲜半岛。
数据集来源是中国植物志。[25]榉树的介绍，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)[回复]
前者还包括离岛，例如济州岛。--Daniel1023（留言） 2024年7月16日 (二) 05:40 (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以“满人不称姓”大量删除了条目中满族人物的姓氏，搜索了一下不同人物情况应该不同。比如爱新觉罗·启骧，有大量直接用长名“爱新觉罗·启骧”，而不是简单只用其名，举例[26]、[27]、[28]、[29]、[30]，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)[回复]

在艺人条目列举演出作品的格式问题

本主题或以下段落文字，在讨论结束后应存档至WikiProject talk:歌手和演员。

（15日中午时分在维基专题讨论:歌手和演员发问了一次，但随后发现那个专题好像没有什么流量，讨论又都是在互助客栈搬过去的，所以改到这里来。抱歉）

我看到现在的艺人出演作品列表有两种写法。

想问哪一个才对？谢谢！--派翠可夫 (留言按此) 2024年7月15日 (一) 16:39 (UTC)[回复]

没有强制规定。WP:WORKS。“列表应该尽量单纯，记载最简要的资料，避免不必要的备注，华而不实的格式应该清理”“若列表项目变得过于复杂，可能需要考虑使用表格加以整理”。也可参考Wikipedia:优良条目/分类/传播媒体#传播媒体人物传记或其他高关注度条目。--YFdyh000（留言） 2024年7月15日 (一) 17:09 (UTC)[回复]
嗯... 可能要参照爱玛·史东条目的做法了... 她用了15年才累积到的量，我打算写的那位可能仅用了5年... 不过如果真那样做，条目主体又可能变得太单薄，或许需要反复尝试。--派翠可夫 (留言按此) 2024年7月15日 (一) 17:29 (UTC)[回复]
看了您的问题，我倒是想借您这个话题问一个可能有点歪楼但可能也不是太歪的问题（希望不会有人认为我扰乱讨论）——色情演员的演出作品数量可能相当多（相比一般艺人，可能是异乎寻常地多），是否应该比照一般艺人列出？若列出，是应该在内文列出还是独立列表条目列出？--银色雪莉（留言） 2024年7月15日 (一) 17:43 (UTC)[回复]
个人觉得，首先要排除那些重复推出的作品，例如精选、合集之类；其次单位应该由大至小，例如尽量以DVD为单位，如果有个别没有被DVD收录的作品才独立表列。--派翠可夫 (留言按此) 2024年7月15日 (一) 23:53 (UTC)[回复]
以篠田步美这条目为例，“无码”部分的做法是对的（我知道的精选／合集都被跳过了，不过倒过来也有一两部要补回去），“有码”部分有些属于精选或合集的应该可以减省掉--派翠可夫 (留言按此) 2024年7月16日 (二) 00:05 (UTC)[回复]
完全赞成您的观点，我认为合集（个人精选和片商多人）都不必列。——只是说就像篠田步美或波多野结衣这类单体，周期长数量大，即使去掉了前面说的这些，也还是很多（捂脸）这是比较让人头疼的（这还没有算上像您说的上下马问题，就只论有码而言）——像后者现在是是干脆没有这个列表的，我认为这样肯定是不好，因为没有依据表明其他的非色情类别作品就比色情类作品有更多的列出的价值，但是要列出，就又多到了一个令人“发指”的地步。又譬如像一些出道年份较长的专属，像吉泽明步，也很难避免这样。——我倾向于对这类情况（太多了的）还是采取独立列表条目，只是不知道普遍的看法是否觉得这样做合适。--银色雪莉（留言） 2024年7月16日 (二) 04:08 (UTC)[回复]
基于WP:NOTSTATS，我不赞成全数列出，只需要介绍有关注的。假设影视演员出演了近千部作品，也是一样，名不见经传甚至没上映的，对艺人没影响的作品不需要提。如果是作品列表条目，可能适当放宽。--YFdyh000（留言） 2024年7月16日 (二) 03:17 (UTC)[回复]
了解您的意思，我想这说到底还是一个关注度的问题，而结合数量的实际情况，可能独立列表会是某些情况下较好的选择。--银色雪莉（留言） 2024年7月16日 (二) 04:14 (UTC)[回复]

@YFdyh000 / @银色雪莉： 更新一下。我最后选择了分拆。列表有大约40K，主条16K，虽然主条短一些但不至于太短。草稿暂时放在我的用户空间，进度大约是80%：

  1. 主条目
  2. 作品列表

现在差两个小列表还没补完，之后再收拾一下作品列表的简介就打算正式建立条目。不过在此之前先询问您俩的意见，看看以上做法是否恰当，谢谢。

以上 -- 派翠可夫 (留言按此) 2024年7月18日 (四) 04:57 (UTC)[回复]

作品列表内容没感觉特别多和多到分拆，但脚注蛮多。广告和代言人如果写入列表，可能太水，明星常有大量广告合约和出演，只有少数具记载价值，既有效介绍——非独立来源应该也行，如自传提到其影响。--YFdyh000（留言） 2024年7月18日 (四) 08:41 (UTC)[回复]
@YFdyh000：其实我就只是把原文版本的列表整合而已，我甚至嫌原版分得太仔细而减省了两、三个分节。广告其实相当少（原版只有12个），主要都是电影和电视剧。
其实我认为要分拆的原因有两个：一、条目描述的这个人在可见将来还会有很多值得记载的作品和成就，与其到时再拆，不如现在就做，免得主条目太拥肿；二、我其实没见过一个列表脚注这么充足，所以其实是打算按FL的方向去编修。
现在比较大的问题是我没有能力判断哪个有记载价值，顶多是没来源的直接不写而已。而现在确实除了广告之外全部都有来源。有些是原版没有而我自己找到的，例如原版有些MV的来源是放在演唱者的条目里。--派翠可夫 (留言按此) 2024年7月18日 (四) 11:19 (UTC)[回复]
分拆我觉得可以接受。广告代言部分基于WP:广告代言感觉要重新考量，我认为在这个共识的前提下，除非是主业广告，否则最好不写；非主业广告一定要写的话，只写确实有相当大影响力的广告（不过即使是那种，也是散文化写到正文里会比独立列出好）。获奖记录是不是还要中文化一下？列举演员作品这事，只要来源OK，在列表这个环节，个人以为能列就列——大家不喜欢的可能是正文短小而列表漫长（有些传记条目连正文都没有，纯作品列表），但不是不喜欢列出作品。--银色雪莉（留言） 2024年7月18日 (四) 12:36 (UTC)[回复]
@銀色雪莉：就是因为获奖纪录还没译所以才说只有80%，不过那段其实很容易，只要从作品列表和获奖模板复制贴上就行（事实上这人出道只有5年已经进了6个获奖模板也是我急于写她的主因之一）。现在先解决最需要解决的事。两位都给了很好的意见，我思考一下再尝试修修--派翠可夫 (留言按此) 2024年7月18日 (四) 12:54 (UTC)[回复]

有关中央弘前站移除维护模版事宜

本主题全部或部分段落文字，已移动至Talk:中央弘前站。执行人：路西法人 2024年7月17日 (三) 04:49 (UTC)。[回复]

请注意近年一用户对参考格式的编辑

如毫不解释就在参考资料栏挂这种模板[31][32]。

多在Cite_news加入publication-place，但这是指该报媒的出版地点，他却当成新闻发生点，在各条目填入，且填入又奇怪，如写成[台]北县[33]、 新北[市][34]、新竹[县][35]、台中[市][36]、台北[市][37][38][39][40]。

对于括号，Wikipedia:格式手册/标点符号有特别规定:“括号的其他形式还包括全形方括号“［］”、六角括号“〔〕”和方头括号“【】”等，仅应在特定文体内出现。”--Outlookxp（留言） 2024年7月16日 (二) 10:41 (UTC)[回复]

我回退后且说明后[41]，他依然继续这样加入[42]。 --Outlookxp（留言） 2024年7月16日 (二) 10:18 (UTC)[回复]

那是我们稍有时差的缘故，我已即刻有所说明，请参考。--59cond12（留言） 2024年7月16日 (二) 10:30 (UTC)[回复]
谢谢，是因我刚刚看到这样编辑感到太激动了。目前就这样[43]。--Outlookxp（留言） 2024年7月16日 (二) 10:46 (UTC)[回复]

在条目页面里(非顶部)加入需要清理模版，此举是否扰乱阅读?

本主题或以下段落文字，在讨论结束后应存档至Talk:靠废柴技能【状态异常】成为最强的我将蹂躏一切。

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

详见《靠废柴技能【状态异常】成为最强的我将蹂躏一切》这个条目。
User:Tisscherry近日在上述条目里，在“登场人物”这一项里，擅自在内容里面加了需要清理模版。
我来维基百科这么久，还是第一次见到可以把需要清理模板直接加到条目里的，这类需要清理模版通常是加到条目顶部才对。
这种行为是不是严重妨碍条目阅读？麻烦发表一下意见。
如果属于妨碍阅读之类的扰乱行为，我想直接对他发出警告。--Znppo（留言） 2024年7月16日 (二) 14:50 (UTC)[回复]

@Znppo：, 在Template:Long_plot/doc#用法中有提到“该模板应放置于条目的某一段落下或某部分下，而非条目头部。”目前的用法应该没有问题。--Wolfch (留言) 2024年7月16日 (二) 15:08 (UTC)[回复]
了解，感谢阁下告知，既然此类挂模版行为合规，则我没有余话可讲。--Znppo（留言） 2024年7月16日 (二) 15:14 (UTC)[回复]
简单来说，可以。这类这类标记模板有支持插入段落的样式，部分有放出开关参数来指定的。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月17日 (三) 01:23 (UTC)[回复]
了解，只是我认为单挂这类模版无意义。维基百科被挂需要清理模版的条目何其之多，如过江之鲫。
只会挂一个清理模版，之后人就跑了的，多的是。清理模版即使挂再久，条目本身也不会有人主动去改善。
想挂清理模版的人，不如自己负清理之责，自己动手整理条目。
不然“就等于是徒具形式”的挂挂清理模版了事，具体意义不大，仅具象征意义。--Znppo（留言） 2024年7月17日 (三) 01:51 (UTC)[回复]
(！)意见：WP:维基百科不强迫任何人参与，“自己负清理之责，自己动手整理条目”当然是最好的，但没有任何理由要求人人这么做。挂清理模板既可以提示其他编者改善条目，又可以提醒读者下面的内容可能存在质量问题，只要理由得当，绝不是“无意义”或仅有“象征意义”的贡献。--——自由雨日（留言・贡献） 2024年7月17日 (三) 02:25 (UTC)[回复]
感谢回应的各位意见，往后放这类型模板会注意注明原因。我的做法是想要整理，但目前暂时不行，所以我会用提示模版。另一方用意也是希望不要无限扩充，毕竟ACG条目有时候就是会越写越无节制。--提斯切里（留言） 2024年7月17日 (三) 02:59 (UTC)[回复]
本来就是无意义、跟象征意义。
单纯挂清理模版，不会有人理。
你这种理想化，跟实际情况不符。--Znppo（留言） 2024年7月17日 (三) 03:44 (UTC)[回复]
话说从头，一个月后无人整理，我会记得自己来的。--提斯切里（留言） 2024年7月17日 (三) 03:49 (UTC)[回复]
我上面是回复另一使用者，不是针对你。--Znppo（留言） 2024年7月17日 (三) 03:50 (UTC)[回复]
你单纯挂清理模版就跑，还是后续打算清理，我没有意见。--Znppo（留言） 2024年7月17日 (三) 03:51 (UTC)[回复]
“本来就是无意义、跟象征意义。”“单纯挂清理模版，不会有人理。”对这种随意评价他人改善行为，随意臆测其他编者之后行为的评论，我没有任何回复的兴趣。--——自由雨日（留言・贡献） 2024年7月17日 (三) 03:51 (UTC)[回复]
我也是对你抱持同一想法。跟你多言无益。--Znppo（留言） 2024年7月17日 (三) 03:53 (UTC)[回复]
还有，没人说理由不当。
他若是理由不当，我早把清理模版移除了。
要挂清理模版，谁都可以挂，绝没人说不可以。
要拔清理模版，可是会反被警告滥移除模版。
我也不是第一天来维基百科，怎么能做什么不能做，不用你来教。--Znppo（留言） 2024年7月17日 (三) 03:49 (UTC)[回复]
完全不知道你在说什么，你要是仅扰乱就可以闭嘴了。--——自由雨日（留言・贡献） 2024年7月17日 (三) 03:52 (UTC)[回复]
谁捣乱，我开的串你跑来我的串里，说我捣乱，你当你是谁。--Znppo（留言） 2024年7月17日 (三) 03:53 (UTC)[回复]
@自由雨日谢谢您，@Znppo不要紧张，熊熊勇闯异世界我也还没整理完，我会记得的，--提斯切里（留言） 2024年7月17日 (三) 03:54 (UTC)[回复]
大家冷静，一开始是我没有执行妥当，造成误解非常抱歉，往后会更小心的。--提斯切里（留言） 2024年7月17日 (三) 03:56 (UTC)[回复]
再次重申，你要怎么作我没意见。
每个人都有他以自己方式编辑或维护维基百科条目的权利。
我原始开这串的目的，是询问你这种直接在条目里挂清理模版，而不是在条目里最顶挂模版的行为，是否影响阅读构成扰乱。
本串我已经得到解答了。如此而已。--Znppo（留言） 2024年7月17日 (三) 04:04 (UTC)[回复]
那此一讨论应该就可以结束了，请大家冷静，谢谢--Wolfch (留言) 2024年7月17日 (三) 04:22 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

Category:官方繁体中文化游戏、Category:官方简体中文化游戏、Category:官方中文化游戏

在此建议，如果游戏都有繁体中文跟简体中文，就直接使用Category:官方中文化游戏的页面分类，不需要做繁体跟简体的分别。--2402:7500:4E8:40C:9192:DE34:8D62:8895（留言） 2024年7月17日 (三) 04:35 (UTC)[回复]

能精确分类的应当精确分类。——暁月凛奈 (留言) 2024年7月17日 (三) 05:02 (UTC)[回复]
同上--YFdyh000（留言） 2024年7月17日 (三) 05:28 (UTC)[回复]
不太适合，类比朝鲜海峡应同时归入“日本海峡”与“韩国海峡”，而非仅归入“亚洲海峡”。--绀野梦人 2024年7月19日 (五) 06:08 (UTC)[回复]

中国大陆文物类条目命名中的“旧址”二字

本主题或以下段落文字，在讨论结束后应存档至WikiProject talk:中国文化遗产。

前情提要：Talk:李凡诺夫公馆旧址#建议更名：“汉口季凡诺夫公馆”→“李凡诺夫公馆旧址”

U:Sanmosa阁下提出，“旧址”一般用于某组织现时仍然存在，但不在原址的情况，我考虑后认为Sanmosa阁下讲的是有道理的，我同意他的观点。但同时考虑到此事可能涉及到大量文物条目的更名，兹事体大，特发至客栈寻求共识，若无异议，希望能将本条确立为方针或指引。--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 14:03 (UTC)[回复]

@YFdyh000：我看到你也表达了类似观点，我认为你也应该参与这个讨论。Sanmosa 蚌埠 2024年7月18日 (四) 15:15 (UTC)[回复]
若条目以“文物保护单位”本身为主题，命名一般可跟随官方。但若超出此范围，包含更加丰富的历史陈述，则“旧址”一词则可尽量不用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月18日 (四) 16:04 (UTC)[回复]
“若条目以‘文物保护单位’本身为主题”，你这个意见在实务中不好判定。--——— 红渡厨（留言・贡献） 2024年7月19日 (五) 02:59 (UTC)[回复]
同Eric Liu。倾向旧址作别名留在条目序言和叙述中，而条目命名，取决于条目主要内容是被保护单位还是原单位沿革。--YFdyh000（留言） 2024年7月18日 (四) 16:13 (UTC)[回复]
“旧址”二字是以现在为中心的叫法，某种意义上跟地域中心问题一样，只是维度从空间变成了时间而已。--派翠可夫 (留言按此) 2024年7月18日 (四) 17:07 (UTC)[回复]
乱解，旧址是指该地原来有什么组织事件，与这个组织现今存不存在、这个建物现今存不存在都没有关系。特别在文物条目，官方定名更加不容瞎改。->>Vocal&Guitar->>留言 2024年7月18日 (四) 23:46 (UTC)[回复]
@Ohtashinichiro：官方名称也是针对有关地点的现况而加上“旧址”等后缀。假如条目着眼于该设施（或者其用途）的整个历史，我不认为这个官方后缀适用。--派翠可夫 (留言按此) 2024年7月19日 (五) 00:57 (UTC)[回复]
这或许是中国大陆的特殊用法吧，但这种意思在中国大陆以外是肯定不存在的。Sanmosa 蚌埠 2024年7月19日 (五) 10:43 (UTC)[回复]
如果某个事物的原始专用名称就包括了“旧址”的话，那这部分就是这个专用名称的一部分，不应该忽略。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月19日 (五) 01:32 (UTC)[回复]
阁下不妨举个例子？--——— 红渡厨（留言・贡献） 2024年7月19日 (五) 03:04 (UTC)[回复]
例如中华全国总工会旧址 (广州)、黄埔军校旧址，越南青年政治训练班旧址、越南青年革命同志会旧址。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月19日 (五) 06:34 (UTC)[回复]
中华全国总工会（与黄埔军校，某程度上）现时好像仍然存在？Sanmosa 蚌埠 2024年7月19日 (五) 10:44 (UTC)[回复]
归根到底，与其现在组织是否存在并没有关联，主要是这个事物的“命名”是否作为专用名词，是的话，里面存在“旧址”就保留下来，没必要花更多的讨论去争执组织是否存在或延续的问题，需要从多个名称中选择的问题就是很简单地通过命名常规去解决。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月20日 (六) 00:17 (UTC)[回复]
就是因为命名常规的各种原则不好选择，选择的时候各种观点容易打架，所以我想有形成共识的必要。--——— 红渡厨（留言・贡献） 2024年7月20日 (六) 02:39 (UTC)[回复]
不过对于这里的问题，或者从命名常规的常用与名从解决更好？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月19日 (五) 06:34 (UTC)[回复]
归根结底一句话：情况太多，需要视情况而定。要我来说，与其说是讨论“旧址”一词该不该有，不如说是讨论一个章程来说“旧址”一词在什么环境下使用。另外注意一些情况：1.“旧址”一词也用在了一些会议的会址上（诸如还没建立条目的汉口杨森公馆，省保公布名为“国共汉口会议旧址”，我认为建立条目时显然汉口杨森公馆作为条目名称更好）。2.有一些文物的使用者甚至组织（算上多次改制的后继者）都没有变化，诸如既济水电公司宗关水厂旧址，因为现今仍是宗关水厂的生产办公设施，我便将组织与文物联合叙述，这些又毋须考虑条目名用不用旧址了。3.诚然在现实称呼中称呼某栋建筑以“旧址”一词指代的情况并不少见，毕竟一栋建筑的业主常有变化，但是带旧址的称呼反而能更全面地概括这个建筑本身的使用历史，否则就得使用门牌号作为条目名了（但事实上门牌号也并不算得上是长期一致）。总而言之，“一刀切”的论证“旧址”一词应该存在与否，可能使得后续条目的建设困难加大。—— 西行寺海苔子 ハナノモトニテ 2024年7月19日 (五) 03:28 (UTC)[回复]
我本来也无意“一刀切”地论证，但我确实认为多数的“旧址”属于滥用，我的主张就是只有真正适合用“旧址”的才能用“旧址”，仅此而已。就好比我写的老隆福建会馆，全国重点文保的用名是“香港文化名人大营救指挥部旧址”，但这显然地使老隆福建会馆的历史扁平化，因此我当时选择了以省市县文保的用名来命名条目。Sanmosa 蚌埠 2024年7月19日 (五) 10:41 (UTC)[回复]
我觉得阁下提到的只有真正适合用“旧址”的才能用“旧址”需要有一个判断标准。--——— 红渡厨（留言・贡献） 2024年7月19日 (五) 11:06 (UTC)[回复]
不适合用“旧址”的主题分几种情况：
  • 第一种是用“旧址”会产生某组织现时仍然存在，但不在原址的误解（比如条目名现作“李凡诺夫公馆旧址”的李凡诺夫公馆，还有条目名一度作“伪满建国忠灵庙旧址”的建国忠灵庙）；
  • 第二种是用“旧址”不会产生如此的误解，但会使主题的历史扁平化（比如老隆福建会馆的全国重点文保用名“香港文化名人大营救指挥部旧址”忽略了老隆福建会馆本身其他丰富的历史）；
  • 第三种是即使用“旧址”既不会产生误解，也不会使主题的历史扁平化，如果不用“旧址”不会引申任何其他误解的话，那也没必要用（比如虎门炮台现在根本不是炮台，因此“虎门炮台旧址”这个名字不会产生误解，而且虎门炮台的功能性本来就很单一，因此“虎门炮台旧址”这个名字也不会使主题的历史扁平化，然而“虎门炮台”这个名字并不会引申任何其他误解）。
故此，只有使用“旧址”既不会产生误解，也不会使主题的历史扁平化，而不使用“旧址”会引申任何其他误解的情况才能算是真正适合用“旧址”的情况。Sanmosa 蚌埠 2024年7月19日 (五) 12:12 (UTC)[回复]
1. 个人没有这种感觉，旧只是说明曾经在那里。如中共一大会址也被称为“中共一大会议旧址”，这不代表“中共一大会议”仍在召开。2. 这要看条目主题。3. 可能要考虑主题和名从主人问题。WP:常用名称，不该擅自去掉旧址。--YFdyh000（留言） 2024年7月20日 (六) 14:51 (UTC)[回复]
补充一个情况，中国大陆很多文保有中国共产党革命旧址的性质，官方将其列入保护名录时往往会以“旧址”“遗址”命名之，比如以战役命名的霍童暴动旧址、西竹岔战斗遗址（该链接重定向到了战役条目的章节中），以战役之外事件命名的，如宁德天后宫（列入县保时名称为“国共和谈旧址”）、闽东独立师集训地，以及以组织机构命名的，如周宁闽东独立师旧址、新四军六团留守处旧址（条目实际名称没有“旧址”）、中共闽东特委独立团旧址（条目使用其建筑原名西胜寺），如前文所说，确实会存在拎不清究竟要不要在条目中加入“旧址”的情况，需要一个标准来界定。----FradonStar|八闽风云 2024年7月19日 (五) 12:45 (UTC)[回复]
还有，还需要补充的一点是“遗址”一词也同样地被滥用，我认为也应当明确客观上并非遗址的地方的条目在任何情况下都不能以“遗址”命名，此外上面提到的第三种情况对“遗址”比照适用。Sanmosa 蚌埠 2024年7月20日 (六) 03:46 (UTC)[回复]
遗址在中国大陆也是有很多用法，如果地方文保管理部门拎不清文物保护单位的分类，就会把一些带有“遗址”名称，但已建立新建筑的文保划到“古遗址”的分类。据我所知的文保以遗址命名的主要有这么几类，一个是考古遗址，比如这块地挖出来过新石器时代、商周时期的石块陶片，就可能会被列入“xx遗址”的文保，这种遗址就没什么好争议的了；一个是古建筑遗址，但不排除这些建筑原址已经有重新建造的建筑或者照旧修旧的情况，比如圆明园遗址、大山庙遗址、宁德文庙遗址等，我认为如果有修建新的建筑，或者原建筑历史意义比较重大，那么这类建筑不应以“旧址”“遗址”做结尾；一个是前面提到的战役遗址，这个一般来讲也只是一片土地，有的地方可能会有纪念馆，但整体保护范围会是很大的，所以用遗址或者旧址我觉得没有问题；还有就是前面历史事件或者历史组织机构的发生地遗址，这种遗址大概率是建筑，我认为尽量以建筑命名为好，但如果建筑本身不出名，也就是说其关注度完全来源于这一历史事件，那可以使用中国大陆公布的旧址名称作为条目名。----FradonStar|八闽风云 2024年7月20日 (六) 05:01 (UTC)[回复]

Template:中国保护区列表

有不少词条都使用了Template:中国保护区列表（见[44]），但似乎这个已经被删掉了，这个模板原来是什么呢？也未见其相关的讨论，应该怎么处理比较好呢？--——“あたいってば最⑨ね！” 2024年7月20日 (六) 14:42 (UTC)[回复]

@Karoke Cirno：这模板是重定向，目标在存废讨论好像没共识，但被Shizhao干掉了。--派翠可夫 (留言按此) 2024年7月20日 (六) 15:48 (UTC)[回复]
我提删的。该存废讨论有明确的共识，并且请注意存废讨论不是数人头，是依靠存废讨论中正当合理的意见。当然，如果您仍有不同意见，您可以依照程序，到维基百科:存废复核请求表达您的意见。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 03:46 (UTC)[回复]
@紅渡廚：我的认知是有正反意见而没有讨论完结迹象就是没共识。这不是谁多谁少的问题，而是双方理据是否充分并且是否获得解决的问题。我不是发问者，所以有这个程序理论上都应该先让楼主去做。不过既然您这样说，那请问那个讨论的共识在哪里？--派翠可夫 (留言按此) 2024年7月21日 (日) 04:51 (UTC)[回复]
请参阅WP:共识的定义。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 04:55 (UTC)[回复]
我没看出那个讨论有哪里达到指引页面上的定义要求，请您具体解释一下。--派翠可夫 (留言按此) 2024年7月21日 (日) 05:00 (UTC)[回复]
我想您应该优先指出，您认为那个讨论有哪里没达到。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 05:02 (UTC)[回复]
@红渡厨：那里最后一条留言都是指要保留，而之后那意见都没有被确实回应，那么共识在哪里？如果说之前那一个删除没有人回应就是有共识，那为什么保留那条可以被无视？也难怪那人提交存废复核请求了。我会到那里声援他。 -- 派翠可夫 (留言按此) 2024年7月21日 (日) 05:08 (UTC)[回复]
你声援不声援我不管，Wikipedia:页面存废讨论/记录/2024/06/29#Template:中华人民共和国各类资源保护列表，但在该讨论中，最后一条保留意见，仅是在说“不符合”，并没有给出任何理由，这连有效回复都算不上。明显无法被考量进共识内。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 05:15 (UTC)[回复]
他的理由就是情况跟他引述的条文对不上。--派翠可夫 (留言按此) 2024年7月21日 (日) 05:21 (UTC)[回复]
他又没给出任何他觉得对不上的理由。他说对不上就对不上？维基百科的方针解释权又不在他那。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 05:26 (UTC)[回复]
有点常识的应该就看得出来吧（反而是您刚才把整篇指引丢给我要求我全篇慢慢看更不合理）。就算您（或者Shizhao）认为他的回应不成立，也应该先在讨论中指出那段回应的问题，让他哑口无言再删除，而不是连回应都不给一个。这个让其他人看来真的很霸王硬上弓。--派翠可夫 (留言按此) 2024年7月21日 (日) 05:30 (UTC)[回复]
存废讨论每天有那么多人留言，不可能每条都有回应，这点还请阁下理解。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 05:35 (UTC)[回复]
反正不是您动手的，我们静待复核事件的发展吧。--派翠可夫 (留言按此) 2024年7月21日 (日) 05:44 (UTC)[回复]
关于阁下提到的让他哑口无言再删除，我单独回复你一下：不可能的，如果这个世界上存在说几句话就能让对方哑口无言，让对方同意你的意见。那么这个世界上就不可能会再有争吵、不可能会再有战争，这是极其不现实的理想主义。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 07:16 (UTC)[回复]
(～)补充：如果那个理由一开始可以被无视，讨论就不会被重新提交一次了 -- 派翠可夫 (留言按此) 2024年7月21日 (日) 05:23 (UTC)[回复]
其实若确实决定要删除，管理员也应该要清理连入页面。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月21日 (日) 08:25 (UTC)[回复]

省直管县级行政区

本主题或以下段落文字，在讨论结束后应存档至Category talk:中国省直管县级行政区。

中华人民共和国的省直管县级行政区到底有哪些，如何将其归入分类:中国省直管县级行政区？条目久未更新，对于部分政区到底是不是“省直管县级行政区”又语焉不详。--绀野梦人 2024年7月24日 (三) 09:22 (UTC)[回复]

完美世界的国际版

请问一下完美世界 (公司)的国际版是不是用“Perfect World Games”，因为不同地区。就很像米哈游一样。--Sim Chi Yun（留言） 2024年7月24日 (三) 09:51 (UTC)[回复]

根据目前推行的讨论递进机制试行案，你应该在条目讨论页先发起讨论，过一段时间没人回应再转到这里发文。LuciferianThomas怎么还没移动话题，我都不知道是要现在回复，还是等转移后才回复。--Nostalgiacn（留言） 2024年7月25日 (四) 10:29 (UTC)[回复]

其他

没有主题的页面如何评级

本主题全部或部分段落文字，已移动至WT:通用评级。执行人：Sanmosa 蚌埠 2024年7月17日 (三) 14:50 (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)[回复]
  • 先多谢各位，意见都很有见地。希望在上方再拆一个小标题。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)[回复]
  • （有感而发）除了本子节开始的争议外，以上讨论与研究其实都满有意义和价值的，如果能提前在去年十二月，也就是我当初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)[回复]
@Bluedeck：能更新进度吗？--路西法人 2024年7月22日 (一) 02:49 (UTC)[回复]
@Bluedeck：预计试行多久？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月20日 (六) 17:44 (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作“工单”[45]。再甚者，直接“搜寻申请”也是得了，不需要特地什么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)[回复]
理论上可以开twn（translatewiki.net） project啦，不过要担心被乱改的问题。--SunAfterRain 2024年7月22日 (一) 07:02 (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)[回复]
(－)反对，考虑到Unblock-zh未来极有可能受到GFW封锁。--mije meli carrot_233 -- 讨论 2024年7月25日 (四) 11:33 (UTC)[回复]
网信办说的？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月25日 (四) 15:07 (UTC)[回复]

冻结RFDA

本主题全部或部分段落文字，已移动至Wikipedia talk:管理员的离任。执行人：Jimmy-bot（留言） 2024年7月25日 (四) 08:14 (UTC)。[回复]

当前解任案效力

本主题全部或部分段落文字，已移动至Wikipedia talk:管理员解任投票/Mys 721tx/第2次。执行人：Jimmy-bot（留言） 2024年7月25日 (四) 08:14 (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://en.wikipedia.org/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)[回复]

  公示7日，2024年7月26日 (五) 13:51 (UTC) 结束：最后一条留言距今已过7日且所有意见已解决，进入公示期。--人间百态,独尊变态(讨论) 2024年7月19日 (五) 13:51 (UTC)[回复]

或许可以考虑m:CampaignEvents？--百無一用是書生 (☎) 2024年7月21日 (日) 06:55 (UTC)[回复]
不反对，不过中维有引入这个插件吗--人间百态,独尊变态(讨论) 2024年7月21日 (日) 07:08 (UTC)[回复]
教育专案不会用。至于如果您是指编辑松，建议另开新讨论。谢谢。--SCP-0000（留言） 2024年7月21日 (日) 07:11 (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)[回复]
当初的删除理由是“在讨论页开新段落自然是寻求讨论，无必要专门用一模板彰显”。我觉得可以改成预设索引对象包含两者，一种像现在这样一定时间内发起讨论，另一种就是特别标示有此模板的话题（无论发起多久）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月17日 (三) 08:02 (UTC)[回复]
正是我上方留言所说的做法。--路西法人 2024年7月17日 (三) 08:41 (UTC)[回复]
有关页面整体内容过多问题，可以考虑同过往一般，按命名空间拆分子页面。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月20日 (六) 17:42 (UTC)[回复]
已更新至WP:TALKINDEX。--路西法人 2024年7月17日 (三) 03:12 (UTC)[回复]
我觉得可以加上对话页对应页面的状态，如保护、特色、优良以及页面不存在等--百無一用是書生 (☎) 2024年7月21日 (日) 06:14 (UTC)[回复]
若祇是索引话题，是否有一些多余？当然，若机器人能做到，那仍可以图示为附注之类。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月21日 (日) 08:04 (UTC)[回复]
确实很实用。感觉可以考虑下放给各专题。以专题分类索引相关条目的讨论页话题，做成状态通告那样可以自定义的工作流，不知在技术是否会有难度。--PexEric💬|📝 2024年7月22日 (一) 13:43 (UTC)[回复]
如此想必可以进一步盘活讨论页。各专题协作起来也更高效。--PexEric💬|📝 2024年7月22日 (一) 13:45 (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)[回复]
该用户的使用者页面仍未挂{{WMF-legal banned user}}，请管理员协助处理。--132.234.229.216（留言） 2024年7月17日 (三) 08:26 (UTC)[回复]
主账号影武者并未受到基金会全域禁制。L'Internationale, Sera le genre humain! ✏️ 2024年7月17日 (三) 10:04 (UTC)[回复]
不影响，禁制针对的是个人（或组织，但就此例而言不适用），而不是单一账号。Sanmosa 蚌埠 2024年7月17日 (三) 14:19 (UTC)[回复]

请求社群判断已经数据过期的用户是否为傀儡

见相关SPI提报，现时最少有法国饮食文化、如懿传、册封体制受到影响（很可能还不止这些），请调查助理、管理员和其TA用户判断和彻底清查，谢谢！--MCC214（Sign | Contributions） 2024年7月18日 (四) 05:12 (UTC)[回复]

  • 外加一些账号（包括SPA），请检查是否为冏；
延伸内容

以上。--MCC214（Sign | Contributions） 2024年7月18日 (四) 05:24 (UTC)[回复]

这难道不应该直接在傀儡调查页面处理？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月20日 (六) 17:39 (UTC)[回复]
这些Stale了的账号，即使有可疑，放上SPI也查不了，所以只能放此。--MCC214（Sign | Contributions） 2024年7月21日 (日) 05:32 (UTC)[回复]

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

有没有“勿添加违法网址”的警示模板？

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

因为又有人在创意私房加入网站网址，虽然网址被台湾政府停止解析，但仍有从其他国家进入的可能，添加网址会违反使用条款。所以我想要不要在条目顶端放个警示模板，但不知道要去哪里找。--世界解放者（留言） 2024年7月20日 (六) 05:28 (UTC)[回复]

添加网址并不等于ToU中提到的那些。网址本身并非色情内容。——暁月凛奈 (留言) 2024年7月20日 (六) 05:45 (UTC)[回复]
之前User:SCP-2000是用这个理由删去网址，虽然台湾的法律张贴网址可能不违法，但美国的法律我不清楚。--世界解放者（留言） 2024年7月20日 (六) 07:00 (UTC)[回复]
网址与网站内容是两回事，直接将内容，比如截图甚至视频发布至维基百科显然是违反使用条款的，但网址只是一串字符，和条目标题性质相同。提供链接不等于提供内容，用户自行访问和分享内容不是维基百科的问题。您也可以参考涉及版权纠纷的网站案例。——暁月凛奈 (留言) 2024年7月20日 (六) 09:44 (UTC)[回复]
好像在有些州，仅是观看也可能触法。我不认为“和条目标题性质相同”，一般来说连结就是要点开来看的，一个不能点的连结又有什么添加的必要？而且Google会移除不当的搜寻结果，目前搜寻“创意私房”是找不到网站的。--世界解放者（留言） 2024年7月20日 (六) 12:28 (UTC)[回复]
我在英维搜寻了一下，虽然没有正式的相关规定，但用户的共识是不要贴，包括暗网之类的连结。--世界解放者（留言） 2024年7月20日 (六) 12:54 (UTC)[回复]
对一个网站进行介绍而又完全不提及其域名不是很奇怪吗？“连结就是要点开来看的”——若是如此，广告商也没必要费力提高点击率了，很多链接并不会被点击，比如参考来源。对于想要访问的人，即使这里没有也会想方设法寻找域名进而访问。Google不是美国政府，它的展示策略是它自己的设置，搜索引擎也不是只有Google。另外，移除此类网站的链接并不是中英文社群的通行做法，相反，存在Category:被美国封锁的网站、en:Category:Domain name seizures by United States这类分类。对于域名被查封，或是已经关闭的网站而言，提及域名应该是必要的。再者，就该讨论的标题而言，警告式的模板通常仅应用于用户讨论页和编辑提示，而不是放到条目上方。——暁月凛奈 (留言) 2024年7月20日 (六) 13:18 (UTC)[回复]
我的意思是，你用条目标题Google搜索可能搜不到东西，但可以直接用网址连过去，两者的意义不同。条目洛丽塔之城也没有提供网址，在英维的讨论页编者们是认为不要放连结，也不确定是否会有法律问题。
还有，问题不仅在于“想要访问的人”，维基已经不止一次因为儿童色情内容惹上麻烦了（见网络观察基金会与维基百科、en:Reporting of child pornography images on Wikimedia Commons），我可不想看到“惊！维基百科居然可以连到创意私房的网站？”这样的台湾新闻报导。--世界解放者（留言） 2024年7月20日 (六) 13:37 (UTC)[回复]
我提到用户讨论页和编辑提示，是因为您想达到的目的不是只有在条目中放警告才能实现。在条目上方放警告可能适得其反。en的讨论参与人数并不多，更多的网站介绍仍然包括网址。另外，现在网络已与2008年不同，Wikimedia强制使用https。——暁月凛奈 (留言) 2024年7月20日 (六) 13:51 (UTC)[回复]
这可能属Wikimedia Foundation Combating Online Child Exploitation Policy的管理范围。当中清楚表明Sharing links to (or purporting to be to) such material is also in violation of this policy。当然若有关连结及图片有明确的教育价值除外[该方针原则上禁止在没有产生教育价值的地方上传完全纯虚构的儿童色情]。当然创意私房最大问题我反而会说是无差别诱骗强迫偷拍，从某黄姓艺人的收藏中可得知当中不少是成年人的[我不是说那边涉儿色的没问题]。--S叔 2024年7月21日 (日) 00:36 (UTC)[回复]
既然基金会有规定，那就好。我来研究编辑提示怎么弄。--世界解放者（留言） 2024年7月21日 (日) 11:16 (UTC)[回复]
感谢User:Hoben7599建立编辑提示。--世界解放者（留言） 2024年7月21日 (日) 11:27 (UTC)[回复]
@暁月凜奈：虽然张贴连结不等于直接散布儿童色情，但en:PROTECT Act of 2003有禁止“广告”，张贴连结有可能算是“广告”。--世界解放者（留言） 2024年7月22日 (一) 01:40 (UTC)[回复]
这讨论主题让人想起处女杀手和网络观察基金会与维基百科，不过在这一案例，基金会维持了有关图片的展示。创意私房可以说在任何主要的司法管辖区都完全不合法，也没有教育意义，链接或许可以基于共识加入过滤器。我觉得无须创建一个单一用途模板，您可以直接手写提醒用户，而在条目挂模板可能会WP:BEAN。--桐生ここ★[讨论] 2024年7月22日 (一) 09:12 (UTC)[回复]
目前添加过连结的编者（包括条目创建者）应该非属恶意编辑，我有在讨论页提醒但不一定会被看到，所以想说有没有一定会看到的方法。现在已经用Template:Editnotices/Page/创意私房来提醒。
依据New York v. Ferber禁止真人儿童色情不需要考虑其含有的价值，而创意私房的内容在en:Dost test下应该算是色情，所以不存在豁免的可能性。--世界解放者（留言） 2024年7月22日 (一) 12:13 (UTC)[回复]
明确一点来说，色情[引起性欲的物品，娱乐用]与教育价值应成反比。很难想个例子是同时有效刺激性欲和有教育目的[除了极少数人的性兴趣就是学习]，最多分开进行。因此这只是界定何谓色情物品的标准。--S叔 2024年7月22日 (一) 13:18 (UTC)[回复]
有一说一，libgen和Z-Library的链接是不是也是违法网址 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月20日 (六) 18:41 (UTC)[回复]
我打“勿添加违法网址”是因为我想可能没有“勿添加儿童色情网址”这种模板。--世界解放者（留言） 2024年7月21日 (日) 11:21 (UTC)[回复]
建议直接永久保护该条目--Bovemdep（留言） 2024年7月22日 (一) 07:34 (UTC)[回复]
没有必要，这是因噎废食。--世界解放者（留言） 2024年7月22日 (一) 12:18 (UTC)[回复]
直接加外部链接黑名单吧（或是更极端点如果基金会明显会禁止的话问看看要不要加全域黑名单）--SunAfterRain 2024年7月22日 (一) 14:47 (UTC)[回复]
我在几天前给基金会发了邮件，基金会那边还没回复。Python6345（留言） 2024年7月22日 (一) 15:42 (UTC)[回复]
注意有一种处理方法是仅仅描述网址（www.example.com），不作为可以点击的链接（http://example.com）。英文版的例子。--GZWDer（留言） 2024年7月23日 (二) 13:49 (UTC)[回复]
中文维百也有例子--Bovemdep（留言） 2024年7月23日 (二) 15:31 (UTC)[回复]

维基百科iOS应用程序替代文字功能实验

您好，我是维基媒体基金会负责支援移动应用程序团队的资深运动通讯专家阿玛尔·拉马丹（Amal Ramadan）。

维基百科iOS应用程序伊始乃以阅读为主要用途。最近两年间，我们亦加强了应用程序的通讯功能，为此后支援“建议编辑”（Suggested edits）机制打下良好基础。我们首先设计了替代文字（alternative text，alt text）原型为概念验证，再引进“图像建议”（Image Recommendations）功能，为iOS应用程序建议编辑机制的第一波适用对象。我们在下一阶段将扩大实验，推广替代文字任务。

为何选择替代文字？目前，维基百科许多条目中的图像尚未提供替代文字，不利于视觉障碍人士及网络连线品质不佳者浏览。替代文字能够有效描述图像，增加可存取性，并促进使用者参与。近期研究指出，以iOS应用程序图像建议功能添加的图像，只有16%有替代文字，其中品质优良者更是屈指可数。本次实验希望厘清，为编者指定替代文字任务是否能提升替代文字的数量及品质，并同时确认此种任务是否无论新手或资深编者都能上手。

我们诚挚邀请社群关注本次实验，并在计划页面随时跟进其进展及成效。本次实验预定于2024年9月至10月间举行，其间完成至少一次有效编辑的使用者，将获得一次提示，学习如何撰写高品质替代文字；所谓“有效编辑”，指以图像建议功能添加图像，或在有缺乏替代文字图像的条目发布编辑者。在本次短期实验期间开放编辑次数少于50次者存取iOS应用程序提供的图像建议功能，以便评估新手在图像建议及替代文字任务中的表现。

欢迎您在讨论页提供回馈意见或针贬不足之处，帮助我们改善功能。您可在实验期间登入iOS应用程序，以图像建议功能发布编辑等，亲自尝试替代文字任务。

不要错过有关本次重大实验的更新消息！

--ARamadan-WMF（留言） 2024年7月23日 (二) 12:33 (UTC)[回复]

检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”