跳转到内容

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

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

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

按此刷新页面。

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

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

查看全部讨论

帮助目录 · 提出疑问 · 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年之前是“一剧四星”，之后是“一剧两星”（[1]）
可靠来源才加入内容，这应该是一般的内容要求。“下列资料必须曾被播放平台官网或第三方可靠来源记载方能保留”的描述十分累赘，完全可以合并成一句话概括：“节目的播放平台及网络电视的节目可观看地区都需要列明来源”。
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)[回复]
只限于临时的节目时间改动，有来源（例如报道）的情况就可以作为描述文段提及。至于其原有的周期性播放时间点，也按照已有来源参照描述则可。例如[2]这种，每个播放电视台的周期播放时间是可以引述来源上描述的，如果当时的播放时间有偏差（例如上面提及的《爱回家》的时间）或者突然的变动，有来源提及就描述，没就不管。——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月才在日本电视台播出（[3]）（[4]）。这种涉及跨国版权的节目，“原产地”算中国大陆，还是日本。
早年中港、港台合拍剧也不少，不过都属于“中文使用地区的”，所以反而没有这些记录争议。--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频道，过去的视频简介是没有写明可观看地域（[5]），近年有了“播放地区：孟加拉、不丹、汶莱、柬埔寨、斐济、香港、印度、印尼、寮国、澳门、马来西亚……”（[6]）--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)[回复]
这个来源可以吧[7]--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)[回复]

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

本主题或以下段落文字，在讨论结束后应存档至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)[回复]

电视剧演员名单序列

本主题或以下段落文字，移动自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，阁下可能误会了，情况不是陈豪被列为主演，反而有很多来源提到他是客串，包括电视台自己的官方报道，只是剧集官方网页的演员排序把它排在第一[8]，而官方网页那个排序的字眼是“演员”，不是“主演”。换言之，官方没有否定陈豪是客串此一事实，但他们就是喜欢把这个客串但最大卡士放在第一，而官方这种做法有违中立，恐怕有其商业或其他利益考虑，维基应否依从其利益考虑？我在上面强调的正是维基向来都警剔官方（一手来源）的不中立，所以不应在此条文认定官方不容质疑，我只是希望加入质疑官方的机制，且需要强共识才可不遵从官方。像《黑道律师文森佐》的刘宰明，按你指出的理据，就算讨论都没法形成强共识。--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排到最后，例如《嘻哈帝国》、《小谎言 (电视剧)》（[9]）、《柏青哥 (电视剧)》（[10]）等，韩国现在也会用“그리고”把演员排到后面。日本的话，还包含他们对“主演”的定义稍稍严格，所以有些戏份多的，才会排到最后。所以，建议依照官方排序，省得去解析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)[回复]

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

本主题或以下段落文字，在讨论结束后应存档至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)[回复]
我们在编辑某些条目，察觉一些方针需要制订或修改，却不一定常涉足所有受该方针影响的范畴，先反思影响范围，再看看哪些用户经常活跃于个中话题，邀请讨论，所有潜在疑问可能在两三星期内就能被大家想出来了，可以集中解决。若不这样做，往往有个人偶尔路过，又放下一个疑问，自然无休无止。就算你曾经顺利通过提案，也只是你的一时幸运，而你的幸运不一定是维基之福。--Factrecordor（留言） 2024年6月26日 (三) 13:01 (UTC)[回复]
“偶尔路过，又放下一个疑问”，这个绝对支持，唯该路人是不是应该负起责任，主动跟进自己问过的疑问，如有需要，应尽他能力以最快时间进行追问，避免社群其他成员无限的等待，这对提案者绝对是一个折磨。--唔好阻住我爱国（留言） 2024年6月26日 (三) 13:13 (UTC)[回复]

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

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

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

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

想法：

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

提案：

现行条文

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

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

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

提议条文

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

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

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

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

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

政治人物

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

宗教人物

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

文化人物

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

正式提案（准备公示）

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

现行条文

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

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

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

提议条文

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

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

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

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

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

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

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

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

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

提案背景如下：

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

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

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

方针修订方案如下：

现行条文

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

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

提议条文

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

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

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

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

原文重定向的可靠来源

本主题或以下段落文字，在讨论结束后应存档至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)[回复]

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

现行管理人员任免案，均采行安全投票，且不提供投票者名单，仅投票管理员（监督员、监管员）可以查阅。鉴于安全投票制度之初衷，暨当事人安全及隐私等疑虑，不公开具体投票者尚能理解。然而，或许应考虑定期公布投票人数（情况允许者，并应先行公布有资格投票者人数），俾便社群追踪任免案之整体动态。另不确定相关方针与指引本来是否有明文规定应提供投票者名单？一并请社群讨论商榷。—— 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)[回复]

重提注音格式要求

本主题或以下段落文字，在讨论结束后应存档至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)[回复]
(＋)支持。--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)[回复]
不要挡到正文显示，一般都没问题。目前多数纯色块使用都会搭配文字解说，已经十分足够。社群特别需要注意的，其实不是背景颜色使用，而是颜色本身是否过于花哨刺眼，甚至违反某些网页使用规范。—— 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)[回复]

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

现行条文

使用中文

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

技术

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

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

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

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

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

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

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

Module:Mapframe、Module:Location map报错

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本主题全部或部分段落文字，已移动至Wikipedia talk:动员令/第二十二次动员令。执行人：Jimmy-bot（留言） 2024年7月23日 (二) 00:14 (UTC)。[回复]

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

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

中维以前的方案是固定宽度左右各保留8em，至于Wikiplus会撑爆那就让Wikiplus自己修吧。--Dabao qian℡ 2024年7月11日 (四) 10:14 (UTC)[回复]
不是Wikiplus问题，Template:Navbox中的示例1和3（从上往下数）的确现在往右歪了一点，但示例4却差不多是居中的。把.navbox-title .navbar的样式改成margin-right: -1.6em;示例1和3似乎能差不多居中了，但是示例4却又歪了--百無一用是書生 (☎) 2024年7月11日 (四) 13:01 (UTC)[回复]
尝试修了一下[19]，现在除了示例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)[回复]

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

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

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

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

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

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

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

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

Infobox person/Wikidata 出生日期

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

无法复现。或许已经修复？--PexEric💬|📝 2024年7月13日 (六) 11:54 (UTC)[回复]
刚刚看了一下，似乎是只有香港和澳门版本有此问题，应与使用的装置和浏览器无关--惣流·明日香·兰格雷不姓式波 2024年7月14日 (日) 01:30 (UTC)[回复]
未登录时港澳版本可重现，登录后无法重现。--YFdyh000（留言） 2024年7月14日 (日) 02:22 (UTC)[回复]
哪个浏览器？我win11 firefox和edge，登入与否，无痕与否，均能复现，chrome的话没安装试不了。--惣流·明日香·兰格雷不姓式波 2024年7月14日 (日) 06:33 (UTC)[回复]
Win10 Edge。curl -v https://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)[回复]

用户头衔模板重叠

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

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

存废重新提交

我去看《溯源之惧》的存废讨论，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上的隐私保护。目前未有其他进一步的部署安排。欢迎在项目讨论页发表意见和提出疑问。 [20]
  • 邀请跨维基上传文件或教导他人如此操作的编辑者，参与维基共享资源上的讨论。共享资源社群正在讨论将能够通过跨维基上传功能（或称上传对话框）上传文件的用户，限缩为维基共享资源上的自动确认用户。这是因为通过这种方式上传的文件大量侵犯了著作权。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 X的logo，一个风格化的X字母
@username

text

9999-12-31

name1 Twitter的logo，一个风格化的小蓝鸟
@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)[回复]

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

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

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

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

在模板: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)[回复]

2024年第30期技术新闻

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

功能周报

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

项目近况

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

增广见闻

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

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

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


求助

停用结构式讨论造成错误

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

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

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

关于来源问题

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

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

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

于Phabricator查看
编号T238427的工单

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

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

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

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

无法建立“China International Motorcycle Trade Exhibition”的页面

无法建立“China International Motorcycle Trade Exhibition”的页面，提示禁止创建和编辑--CIMA Jane（留言） 2024年7月15日 (一) 07:56 (UTC)[回复]

在英文维基百科吗？因为英文维基百科不允许非自动确认使用者建立条目页面，您必须从en:Draft:China International Motorcycle Trade Exhibition开始编写，另外，您也必须遵循en:WP:DCOI（甚至en:WP:PAID）的指示，揭露利益冲突，否则可能会被禁止编辑，谢谢。--冥王欧西里斯（留言） 2024年7月15日 (一) 08:14 (UTC)[回复]

请求协助添加跨语言链接

我新创建了页面瓦西利斯·波利蒂斯，想建立到英语维基页面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)[回复]

周小川

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

感谢您指出该问题，我暂时给加了个模板……--——自由雨日（留言・贡献） 2024年7月20日 (六) 17:00 (UTC)[回复]
已修改。疑似有少数来源（[24]、变革 元宇宙与数字经济[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”去除

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)[回复]

技术求助

我最近编写的条目“塞特波齐战役”在英维中脚注采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)[回复]


条目探讨

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

看到将“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)[回复]
如果此处的祭如同战祭、丰年祭，是指庆典或活动的话，可参见《教育部异体字字典》释义五。[25]--夜月辰星（留言） 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)[回复]

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

本主题或以下段落文字，在讨论结束后应存档至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)[回复]
据我所知是没有，比如中国高等植物数据库全库记载的榉树，“国外分布”一栏只写着朝鲜和日本，而其他参考文献是明确有写它分布在韩国的（[26]），我也因此认为其他相关的以中国高等植物数据库全库为参考的植物条目中的“朝鲜”，应该指的是朝鲜地区/半岛，而不是朝鲜民主主义人民共和国。就算确实指后者，写朝鲜地区/半岛也没错，且不会出现歧义的问题。----FradonStar|八闽风云 2024年7月3日 (三) 04:15 (UTC)[回复]
我觉得下结论可能原创研究。如无额外来源证明，我宁可取消内部链接。扩大范围恐怕是曲解来源。
按使用帮助文档最后一页，国外分布可能写中南半岛、马来半岛。但是，没有写成朝鲜半岛。
数据集来源是中国植物志。[27]榉树的介绍，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以“满人不称姓”大量删除了条目中满族人物的姓氏，搜索了一下不同人物情况应该不同。比如爱新觉罗·启骧，有大量直接用长名“爱新觉罗·启骧”，而不是简单只用其名，举例[28]、[29]、[30]、[31]、[32]，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)[回复]

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

本主题全部或部分段落文字，已移动至Template talk:User Fujian。执行人：Jimmy-bot（留言） 2024年7月22日 (一) 16:14 (UTC)。[回复]

条目内链相关问题

本主题或以下段落文字，在讨论结束后应存档至WikiProject talk:化学物质、Wikipedia talk:同类索引条目。

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

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

让我编辑

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

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

关于扎基拉姆

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

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

（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)。[回复]

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

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

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

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

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

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

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

前情提要：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)[回复]
  • (！)意见：这很简单。条目名称当然要和首句定义相符。如果定义是文保单位，那么用文保单位的官方名称OK。如果定义是建筑物，可以叫旧址也可以不叫。但如果定义是曾经存在的组织，比如某某银行，某某公司之类的，当然是不应该叫“旧址“。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年7月22日 (一) 08:16 (UTC)[回复]

Template:中国保护区列表

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

其他

Wikipedia:互助客栈/其他

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