维基百科

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

快捷方式

本頁互助客棧 (全部)是供以方便瀏覽所有討論而特別設置。如果您想要新增討論內容，請在互助客棧中選擇最合適的版面。

按此刷新頁面。

  歡迎光臨互助客棧！  
   
  互助客栈是維基人議事相助之處，用以討論消息、方针、技术以及编辑、求助等議題。
發表議題之前請搜索先前文章，遵守指導及禮儀。任何與維基百科無關的問題，请前往知识问答。

消息
方针
技术
求助
條目探討
其他
討論維基相關新聞與消息 討論方針與草案 解決或報告技術疑難 解決在維基百科中所遇疑難 條目、模板、主題相關探討 未符任何分區之議題
发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视

查看全部討論

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

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

消息

Wikidata weekly summary #536

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

Discussions

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

Events

Press, articles, blog posts, videos

Tool of the week

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

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

Books & Bytes – Issue 63

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

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

Read the full newsletter

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

維基媒體運動憲章批准投票結果

您可以在元維基上找到這則訊息其他語言的翻譯。 请帮助翻译至您的语言

大家好，

經過仔細統計個人和自治體選票後，憲章選舉委員會很高興地宣布維基媒體運動憲章投票的最終結果。

根據憲章選舉委員會的通知，7月9日 23:59 UTC投票結束時，我們已達到自治體投票和個人投票的法定人數。我們感謝在批准過程中投票的所有2,451名個人和129名自治體代表。您們的投票和評論對於運動策略的未來步驟非常寶貴。

2024年6月25日至7月9日舉行的維基媒體運動憲章批准投票的最終結果如下：

個人投票：

截至7月9日 23:59 UTC，共有2,451名選民投票，其中2,446張選票被認定為有效票。有效票中，1,710名投下「贊成」；623名投下「反對」；113名選擇「–」（中立）。由於中立票不計入總票數，73.30%的選民投票支持憲章（1710/2333），26.70%的選民投票否決憲章（623/2333）。

自治體投票：

截至7月9日 23:59 UTC，共有129名自治體指定投票人投票，其中129張選票被認定為有效票。有效票中，93名投下「贊成」；18名投下「反對」；18名選擇「–」（中立）。由於中立票不計入總票數，83.78%的自治體投票支持憲章（93/111），16.22%的自治體投票否決憲章（18/111）。

維基媒體基金會理事會：

維基媒體基金會理事會於2024年7月8日舉行的特別理事會會議中投票決議不批准擬議的憲章。維基媒體基金會理事會主席Nataliia Tymkiv分享了投票結果、決議、會議記錄以及提議後續步驟。

綜上所述，維基媒體運動憲章的目前修訂版本未獲批准。

我們由衷感謝您參與我們運動治理的重要時刻。

憲章選舉委員會，

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

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

The Signpost: 22 July 2024

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

Wikidata weekly summary #637

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

Discussions

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

Events

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

Press, articles, blog posts, videos

Tool of the week

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

Other Noteworthy Stuff

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

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

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

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks


方針

提議英維指引en: MOS:TVINTL經本地化後引入中維維基百科:格式手冊/電視

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手冊/電視。

目前，英維en: MOS:TVINTL有限制維基百科應收集怎樣的播放資訊，但中維沒有相關限制，導致各電視節目（包括劇集及日本動漫）均記錄了世界各地每一地區的播放資訊或重播資訊，本人認為條目內記錄每一地區的播放資訊或重播資訊是非常冗長而沒經篩選，更甚有條目的播放資訊比例佔整個條目一半或更多，有機會違反WP:SOAP及WP:NOTTVGUIDE。對此，引入en: MOS:TVINTL也許可解決問題。
en: MOS:TVINTL： Broadcast
This subsection should cover broadcast and release information about the series or season. This can include: the original network or streaming service of release in the country of production (e.g. the British network for a British series such as Doctor Who); a change in network throughout the run, such as with Futurama; start and end dates; and discussion of technical data such as picture and audio format, accompanied by critical commentary. Days or timeslots are not inherently notable, but if covering a series that switches these during its run, it may be helpful to note them for each season. If episodes are released all at once on a streaming service, it may be more appropriate to title this section "Release" rather than "Broadcast". Any syndication deals can also be noted.

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

可以這樣本地化：

由於維基百科不是電視指南，因此不要不分青紅皂白地列出在生產地區以外播放系列的每個播放平台。 相反，如果來源可靠，鼓勵編輯新增值得注意的非生產地區的廣播或串流資訊。 這些可能包括：在中國、台灣、香港、澳門、馬來西亞、新加坡等主要中文地區的廣播或串流資料；其餘地區除了特殊情況外，包括如相關地區的通用語言不是中文，但首次播放以中文製作節目的播放資訊；或大規模國際發行協議，否則不應被記錄。

下列資料不應記錄：

  • 播放時間（不包括播放日期）
  • 電視重播資訊
  • 電視延後播放資訊（只記錄該地區最先出現的資訊）
  • 馬拉松式播放資訊（例如在一天內連續播放5集電視節目）
  • 節目原產地區外，不是以中文提供字幕或配音的播放平台
  • 相關串流平台官網、其他可靠來源均沒有記錄相關節目的準確播放地區且相關播放平台設置了IP限制 (特別注意：Disney+、Netflix、Amazon Prime Video、TVB Anywhere、Viu OTT)
  • 如相關節目於中文地區有「代理發行」資訊，則只可記錄可在該播放平台清淅辨認相關代理資料的網路播放平台。(特別注意：日本電視動漫)

由於此條文適用於所有曾於電視廣播的節目，故在此提案。部分字眼可改，只求盡快通過。--唔好阻住我愛國（留言） 2024年4月22日 (一) 07:16 (UTC)[回复]

个人感觉：“值得注意的”是重点，但不十分明确。短期内或频繁的重播可能琐碎，得到有效来源介绍的则可考虑。“除了特殊情况外”后面的语句可能仍需润色，不好懂。“播放时间”如果有来源我觉得可以，但可能很多是查证不足。“下列资料不应记录”第三条及之后的含义和用法我不太明白，或许应补充例子。建议邀请活跃编者，可预期存在反对声音，另外它是指引，强制力在短期内可能不会很高，只能作为理由依据。--YFdyh000（留言） 2024年4月22日 (一) 07:56 (UTC)[回复]
  • 「值得注意的」段落可以extend，但應如何extend則交由社群決定。
  • 「頻繁的重播」當然是瑣碎，難道要準確收錄何時重播？
  • 「播放時間」見下方解答
  • 「第三條及之後的含義和用法」，不是電視節目條目編輯者不明白是正常的。
最後那點，請參閱在Wikipedia talk:格式手冊/日本動漫遊戲 § 提議將WP:MOSACG跨媒體部分提升為指引的討論。--唔好阻住我愛國（留言） 2024年4月22日 (一) 09:26 (UTC)[回复]
那之前疫情的时候部分作品由于制作原因推迟播出，算不算电视延后播放信息？而且这一段(如相关节目于中文地区有“代理发行”信息，则只可记录可在该播放平台清淅辨认相关代理资料的网络播放平台。(特别注意：日本电视动漫))应该要加上特摄作品的信息。(有部分特摄作品也会标注其代理信息)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 07:58 (UTC)[回复]
第一點：想法是只記錄該集數最先出現的播放平台，例如「A節目在B平台的播放時間是0900，在C平台的播放時間是0930，在D平台的播放時間是1200…」，這樣寫實在太冗長及無謂。想法是「A節目於B、C、D平台上架。」
第二點括號內的是我個人想法，當然是不會加入條文之中。--唔好阻住我愛國（留言） 2024年4月22日 (一) 09:04 (UTC)[回复]
第一个的话这个不反对(反正超级战队系列特摄作品条话一般都是按散文方式写在哪一个平台上架不大受会受影响，但是假面骑士和奥特曼系列的话有可能会受到影响删内容。)第二点的话就是说所有电视类条目都得遵守该规范吗？--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 11:22 (UTC)[回复]
總之曾在電視廣播的節目條目也適用。--唔好阻住我愛國（留言） 2024年4月23日 (二) 06:04 (UTC)[回复]
依MOS:CHINA，修改為「這些可能包括：在中國大陸、台灣、」。--CaryCheng（留言） 2024年4月22日 (一) 18:21 (UTC)[回复]
下一版本會更正。--唔好阻住我愛國（留言） 2024年4月23日 (二) 06:03 (UTC)[回复]

版本2

由於維基百科不是電視指南，因此不要不分青紅皂白地列出在生產地區以外播放系列的每個播放平台。 相反，如果來源可靠，鼓勵編輯者新增值得注意的非生產地區的廣播或串流資訊。這些可能包括：在中國大陸、台灣、香港、澳門、馬來西亞、新加坡等主要中文地區的廣播或串流資料；相關地區的通用語言不是中文，但首次播放以中文製作節目的播放資訊；或大規模國際發行協議。

下列資料不應被記錄：
  • 播放時間（不包括播放日期）
  • 電視重播資訊
  • 馬拉松式播放資訊（例如在一天內連續播放5集電視節目）
  • 節目原產地區外，不是以中文提供字幕或配音的播放平台

下列資料必須曾被播放平台官網或第三方可靠來源記載方能保留：
  • 誇地區網路播放平台上架影片的準確上架地區 (特別注意：Disney+、Netflix、Amazon Prime Video、TVB Anywhere、Viu OTT)
  • 如相關節目於中文地區有「代理發行」資訊，則只可記錄可在該播放平台清淅辨認相關代理資料及相關代理公告了的網路播放平台。(特別注意：日本電視動漫、 特攝作品等)
--唔好阻住我愛國（留言） 2024年4月25日 (四) 05:07 (UTC)[回复]
另ping @PexEric、@BlackShadowG、@Cdip150、@U:Skiate--唔好阻住我愛國（留言） 2024年4月25日 (四) 05:12 (UTC)[回复]
「下列資料不應記錄」之後的內容，不是英維既有的內容，不少看起來過於一刀切，個人認為相關條文有些不合實際操作：
第一條，日本動畫作品的時刻表通常使用三十小时制，不記錄「播放時間」，只記錄日期很容易出錯
第二條的實際操作預計會刪除很多內容，需要更多人參與討論，以減少潛在的編輯衝突，以還珠格格#電視節目的變遷舉例，要刪掉「复播」的內容。一些記錄特定電台的播放節目模板，如{{中視八點檔}}《還珠格格》幾輪重播都有記錄，這些又如何處理。
第三條個人認為有記錄必要，一來是平台發佈方式的不同，如Netflix是一次性全部發佈的，二來中國大陸節目播放是有政策限制的，2014年之前是「一劇四星」，之後是「一劇兩星」（[2]）
可靠來源才加入內容，這應該是一般的內容要求。「下列資料必須曾被播放平台官網或第三方可靠來源記載方能保留」的描述十分累贅，完全可以合併成一句話概括：「節目的播放平台及網絡電視的節目可觀看地區都需要列明來源」。
PS：錯字「誇地區」。--Nostalgiacn（留言） 2024年4月25日 (四) 08:49 (UTC)[回复]
1. 編輯者有責任將日本30小時制轉換至中文地區的24小時制，這樣可提高條目可讀性。（註：近期日本動畫條目已停止記錄30小時制播放時間表，僅列出24小時制首播及完結日期。）
2. 不記錄重播資訊，只記錄首播資訊是英維要求。節目模板可以保留。
3. 可以刪除，反正第二條有相同功用。
4. 下一版本會更正，並放在首段。
整個句子可能是「節目的播放平台及網絡電視的節目可觀看地區都需要列明來源，否則其他編輯者有權移除未能辨認可觀看地區的播放平台及網絡電視播放資訊。 因應地區IP而調整播放內容的網路播放平台連結、需要登入方能閱讀播放清單的網路播放平台連結、Category:電視外部資源模板相關連結及社群媒體並不是可接受能證明可觀看地區的來源。」--唔好阻住我愛國（留言） 2024年4月25日 (四) 10:24 (UTC)[回复]
(＋)支持。--CaryCheng（留言） 2024年4月25日 (四) 16:00 (UTC)[回复]
对于日本动画的话，电视播放途径会有一手来源（官方本身有类似onAir的来源），可以考虑保留时间。网站播放途径不确定其发布时间是不是确定的，可以不保留。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月26日 (五) 01:10 (UTC)[回复]
整頓完TV後就該整頓TV anime，電視聯播網也不知道是什麼…英維已有部分條目採用電視聯播網歸納全日本電視台，與中維日劇條目差不多處理方法。
況且播放時間能證明什麼？
時段可以，但準確時間萬萬不可。試想想，如果上一節目時段因為緊急直播10分鐘而導致此節目延遲10分鐘結束節目，編輯者通常在條目解釋為何延遲播放此節目，唯解釋普遍沒有來源且與節目條目無關，備註長度碪比節目介紹，香港電視條目正深受其害。--唔好阻住我愛國（留言） 2024年4月26日 (五) 03:25 (UTC)[回复]
往常处理也是不考虑临时的延时、改期情况，如果需要的话，是有来源引述时在动画节目章节内导言中提及。时间的话，需要多精确？onair来源中来精确到“23:00”的话，就按照这个时间描述则可。电视联播网现在ja都不提及的，电视播放渠道只需要按照来源说明哪个电视台播放基本足够。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月26日 (五) 06:02 (UTC)[回复]
  • 這裏該處理整體電視條目，而非單指日本電視動畫…
  • 「臨時的延時、改期情況」在日本條目實屬少見，唯香港條目是普遍。
  • 「23:00」時段即可，免得又說因為xxx事而延誤xx分鐘播放。
--唔好阻住我愛國（留言） 2024年4月26日 (五) 06:13 (UTC)[回复]

版本3

由於維基百科不是電視指南，因此不要不分青紅皂白地列出在生產地區以外播放系列的每一個廣播或串流資訊。 相反，如果來源可靠，鼓勵編輯者新增值得注意的非生產地區的廣播或串流資訊。這些可能包括：在中國大陸、台灣、香港、澳門、馬來西亞、新加坡等主要中文地區的廣播或串流資訊；相關地區的通用語言不是中文，但首次播放以中文製作節目的播放資訊；或大規模國際發行協議。節目的播放平台及網絡電視的節目可觀看地區都需要列明來源及符合可供查證原則，否則其他編輯者有權移除未能辨認可觀看地區的播放平台及網絡電視播放資訊。 因應地區IP而調整播放內容的網路播放平台連結、需要登入方能閱讀播放清單的網路播放平台連結、Category:電視外部資源模板相關連結及社群媒體並不是可接受能證明可觀看地區的來源。

下列資料不應被記錄：
  • 準確播放時間（不包括播放日期及播放時段）
  • 電視節目即日延誤播放資訊（包括為何延誤播放及延誤時間）
  • 電視節目重播資訊
  • 節目原產地區外，不是以中文提供字幕或配音的播放平台

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

那包含在特定节目内的应不应该记录准确播放时间？(例如目前在翡翠台播出的小书痴以及东电在某些时段冠其他名称的动画)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月26日 (五) 07:13 (UTC)[回复]
準確播間是類似香港TVB晚上八點檔愛回家，電視節目時間表寫20:00播放至20:30結束，但實際播放時間是20:03-20:27。
故寫播放時間時只需提及「此節目逢星期一至六晚上八時正首播。」--唔好阻住我愛國（留言） 2024年4月26日 (五) 07:43 (UTC)[回复]
與原有時段嚴重不符的特殊偶發延誤資訊應可記錄，例如延誤半小時以上。亦即經常延誤的節目不宜記錄，例如習近平時代的央視新聞聯播其後的電視劇等節目；據稱胡錦濤時代的央視新聞聯播延誤極少，由此導致的節目延誤應容許記錄。--— Gohan 2024年4月27日 (六) 02:09 (UTC)[回复]
如何符合列明來源及符合可供查證原則？
請提供相關記錄的例子，謝謝！--唔好阻住我愛國（留言） 2024年4月27日 (六) 06:06 (UTC)[回复]
與本問題無關（即不應因部分内容無來源而全面禁止以至牽連有來源的内容）。但有例子：フジテレビは地震発生時……映画『ヲタクに恋は難しい』を放送……報道特番に切り替わり、深夜1時25分ごろに続きの放送が再開された。その後、2時間15分押しで深夜1時35分から『さんまのお笑い向上委員会』……--— Gohan 2024年4月27日 (六) 09:33 (UTC)[回复]
只限于临时的节目时间改动，有来源（例如报道）的情况就可以作为描述文段提及。至于其原有的周期性播放时间点，也按照已有来源参照描述则可。例如[3]这种，每个播放电视台的周期播放时间是可以引述来源上描述的，如果当时的播放时间有偏差（例如上面提及的《愛回家》的时间）或者突然的变动，有来源提及就描述，没就不管。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月28日 (日) 02:06 (UTC)[回复]
建議第2點改爲：
  • 推遲不足30分鐘或並非偶發的延誤播放之資訊
再者，一個節目若在滲透率二成的衛星電視或收費有綫電視頻道首播，而後在滲透率九成的地面電視頻道重播，後者應容許記載。故建議第3點改爲：
  • 重播資訊，除非傳播媒介不同而使該重播頻道滲透率倍增於此前任一已播出頻道
此外，「相關地區的通用語言不是中文，但首次播放以中文製作節目的播放資訊」文法不通，難以理解，應予修改；「在生產地區以外播放系列的每一個廣播或串流資訊」中，「系列」顯然是機械翻譯，亦應修改。
另外，建議條文可能致使編者以爲跨國播出只能在「播出國家／地區」欄目列出原產國或中維六地（例如以爲GEM TV ASIA的此列法違規）而令所示播出範圍小於實際，需要澄清；「廣播」一詞有歧義，在部分地方僅意味大氣電波播出，亦需更改。--— Gohan 2024年4月28日 (日) 07:48 (UTC)[回复]
  • 第一點(＋)支持，下一版本會更正。
  • 第二點有點麻煩，畢竟以「滲透率」作標準有爭議。
  • 第三點是英維要求，應如何改善？
  • 第四點(＋)支持，下一版本會更正。
  • GEM TV ASIA是採用內嵌字幕，除了香港是嵌入中文外，其餘東南亞地區是嵌入英文，故列出東南亞地區其實是不符合最後一點原則。
  • 英維是採用「廣播」，中維可用「播放」，下一版本統一至「播放」。
--唔好阻住我愛國（留言） 2024年4月28日 (日) 08:43 (UTC)[回复]
更正一点:GEM TV ASIA实际使用的是DVBSUB形式的隐藏式字幕并非是内嵌字幕。(部分运营商会将外挂式字幕转为内嵌式字幕)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月28日 (日) 08:47 (UTC)[回复]
「等主要中文地區」--唔好阻住我愛國（留言） 2024年4月28日 (日) 08:58 (UTC)[回复]
同一頻道同一時間播出何必作出區隔？省去幾個字國名？如此致使讀者以爲GEM TV ASIA在此時段香港才播出此節目，在其他地方不然。因此主張在任一地方滿足條件即可；同樣，在任一地方屬於首播即可，而不應刻意遺漏同一頻道同一時間播出同一節目而非首播的地方。--— Gohan 2024年4月28日 (日) 08:58 (UTC)[回复]
這是英維「English licensee」所主張的。在英維，同一頻道列A地區不列B地區是常見。--唔好阻住我愛國（留言） 2024年4月28日 (日) 09:33 (UTC)[回复]
查無相似主張。英維的Release章節並不規定：若一個電視頻道同時向英語、非英語國家播出同一節目，只能列出英語國家；或一個電視頻道同時向多地播出同一節目，只能列出提供英文字幕的國家或地區。一個電視頻道同時向多地播出同一節目應視爲單一行爲，不宜片面陳述，正如可標識跨國流媒體「全球」播出。--— Gohan 2024年4月29日 (一) 06:34 (UTC)[回复]
當然是查無主張啦，因為這僅是實際操作。
個人是反對「全球」一詞，世界上沒有任何一個媒體可以全球通行，以 「全球」作結表示該名編輯者沒有進行資料搜集、原創研究、發放錯誤訊息。--唔好阻住我愛國（留言） 2024年4月29日 (一) 12:59 (UTC)[回复]
若在該串流媒體的任何任務區可看，「全球」無可厚非；或許只需一個自訂或變態的「  全世界」模板作解釋或tooltip。--— Gohan 2024年4月30日 (二) 08:22 (UTC)[回复]
服務地區（Service Area）--唔好阻住我愛國（留言） 2024年5月1日 (三) 02:50 (UTC)[回复]
按照您的说法那b站本身也不能作为可靠来源。(B站本身限制海外地区浏览中国大陆的影视内容只能通过B站以及代理商社交媒体查询。)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年5月1日 (三) 08:42 (UTC)[回复]
外維是直接禁止引用播放清單（不論英維還是其他維），但我的條文中卻只要求該播放清單全球任何一地均可閱覧及能清楚辨認屬地即可。
bilibili應該是不受影響，而YouTube, Netflix, Disney+, Viu OTT,愛奇藝等全球性平台才是影響較大。--唔好阻住我愛國（留言） 2024年5月1日 (三) 08:56 (UTC)[回复]
虽然因为确实没有主张，但是确实是有这么做的(在WP:共识中有提到在维基百科，共识是一种典型但往往含蓄无形的过程。所有没有异议或不被其他编者回退的编辑，均可假定其具备共识。)类似于J2更名为TVB Plus英语社群这边鉴于该频道只是更名并增加财经节目并不符合独立关注度所以没有跟现在中维一样建立新条目而是将条目进行移动。(要是真按照英语的共识那高清翡翠台、J5应该要合并到無綫財經 體育 資訊台并删除大量琐碎细节内容。以及按照命名常规将無綫財經 體育 資訊台更名为更常用的無綫財經體育資訊台)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月30日 (二) 06:49 (UTC)[回复]
雖然二位都未明指「主張」是什麽，但是在下意會有關主張後隨機搜尋思緒中首先浮現的電視節目，竟就足以駁倒「確實是有這麽做的」：英維「如懿传」條目國際播出章節列出：Star Chinese Channel在Hong Kong and Southeast Asia播出、三個越南電視臺播出三次越南語配音的版本，無論如何設想都不符合「若一個電視頻道同時向英語、非英語國家播出同一節目，只能列出英語國家；或一個電視頻道同時向多地播出同一節目，只能列出提供英文字幕的國家或地區」或「不應記錄」「節目原產地區外，不是以中（英）文提供字幕或配音的播放平台」。此外，毫不認同有關英維J2的評論，離題不贅。--— Gohan 2024年4月30日 (二) 08:21 (UTC)[回复]
然而相关方针指的是原生英文的节目。例如瑞克与莫蒂、汪汪队立大功这两个条目都是以散文的形式标注具体提供的配音版本以及配音版本的播出频道。(实际就是要求跟英文一样尽量使用散文和信息框的形式，而不是纯信息框。)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月30日 (二) 11:35 (UTC)[回复]
日後希望您在提出有關方針或指引的説法，請明示依據或直接引述。至少en:Wikipedia:Manual of Style/Television查無有關「原生英文的節目」的條文，否則請指明；版本3至今所有人的提案中亦無「原生中文的節目」一説，您提出「原生英文」所爲何故？不免懷疑您在2024年4月28日 (日) 08:58 (UTC)下屬的一串討論中的近兩次留言已離題，也難以猜測「确实是有这么做的」（2024年4月30日 (二) 06:49 (UTC)）到底是指怎麽做？--— Gohan 2024年5月1日 (三) 03:54 (UTC)[回复]
看了一下，确实没有直接写明禁止非英语但是提到英语系国家优先。(对应段落en:MOS:TVINTLAs Wikipedia is not a television guide, do not include an indiscriminate list of every network that carried a series outside the country of production. Editors are encouraged instead to add noteworthy foreign broadcasts, if reliably sourced.These can include: broadcasts in primarily English-speaking nations such as the United States, Canada, United Kingdom, Australia and New Zealand)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年5月1日 (三) 06:43 (UTC)[回复]
要是真在某特定区域播出，直接写对应的地区就行(例如无职转生在东南亚地区曾在ANIMAX播出就直接写东盟就行了。)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月28日 (日) 10:37 (UTC)[回复]
你要說「東盟」或「東南亞」的話，請證明此動畫可在泰國以Animax觀看。--唔好阻住我愛國（留言） 2024年4月28日 (日) 14:41 (UTC)[回复]
该频道本身在泰国已经于2017年停播，但是部分节目仍可在TrueID以点播的形式提供。类似于ANIPLUS在香港的情况。(而且在无职转生的英语条目中对于该台播出的地区描述用的是模糊的东南亚地区而并未精准到国家)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月29日 (一) 00:05 (UTC)[回复]
如無滲透率作標準，而全面禁止重播資訊，則會導致一個電視節目若在幾乎沒人會看（例如滲透率低於百分之一、收視率低於萬分之一）的頻道首播，在最多人收看（滲透率九成八）的頻道第二次播出，而後者不得記述，違背情理。--— Gohan 2024年4月29日 (一) 06:36 (UTC)[回复]
真要按渗透率台湾的无线五台(台视、中视、华视、民视以及公视)与第四台(有线电视)的基本频道渗透率相当(台湾的无线五台在第四台是必传频道)那怎么算呢？(香港这种被TVB和政府垄断而不能自由收视的地方真是令人悲哀。)--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月29日 (一) 07:08 (UTC)[回复]
滲透率相當，顯然不符合我所提議的條文中的豁免條件：「除非傳播媒介不同而使該重播頻道滲透率倍增於此前任一已播出頻道」。--— Gohan 2024年4月29日 (一) 11:51 (UTC)[回复]
若要用滲透率作標準，則大大提高編輯難道或引起編輯爭議。
「我認為A媒體滲透高些，B很少人看。」
「我認為B媒體滲透高些，A沒有人看。」--唔好阻住我愛國（留言） 2024年4月29日 (一) 13:02 (UTC)[回复]
相較收視率或其他數字，滲透率穩定、透明、標準一致，最爲可取。若無更佳標準、不取滲透率，可以改爲禁止「同一收視方式或受衆更狹窄的收視方式的頻道重播之資訊」；若仍有爭議，恐怕只能改成禁止「同一頻道重播資訊」；以免「一個電視節目若在幾乎沒人會看（例如滲透率低於百分之一、收視率低於萬分之一）的頻道首播，在最多人收看（滲透率九成八）的頻道第二次播出，而後者不得記述」。此外，或許需要括注「（惟特有中文名稱可標注相應電視臺或頻道）」。--— Gohan 2024年4月30日 (二) 08:26 (UTC)[回复]
這個世界有基於廣告的「電視覆蓋率(TV Overlay Rate)」。--唔好阻住我愛國（留言） 2024年5月1日 (三) 02:36 (UTC)[回复]
依據目前資料理解，在任何框定區域內，A頻道與B頻道的滲透率的比率、A頻道與B頻道的覆蓋率的比率，是一致的（因爲A頻道與B頻道的滲透率的分母一致，A頻道與B頻道的覆蓋率的分母亦一致；A頻道的滲透率、覆蓋率的分子一致、B頻道的滲透率、覆蓋率的分子亦一致）。所以滲透率、覆蓋率孰優孰劣，在我的提議條文（「滲透率倍增」）中沒有差異。--— Gohan 2024年5月1日 (三) 03:53 (UTC)[回复]
他願不願意願意到相關地區收看是他個人決定，總之這個台在該版權地區是有提供服務。
以日本為例，TVer的覆蓋範圍與ABEMA一致，可觀看人數達124,090,000人。
TVU福島覆蓋全福島縣，可觀看人數達 1,817,228人
TBS電視台覆蓋整個關東廣域圈，可觀看人數達43,191,414人--唔好阻住我愛國（留言） 2024年5月1日 (三) 02:49 (UTC)[回复]
「滲透／覆蓋不到」即循此種方式無法觀看，外乎意願。--— Gohan 2024年5月1日 (三) 03:53 (UTC)[回复]
我想探討一下「範圍」，以上面的全球和東協為例，難道要為了幾個沒有營業國家/地區而特地列出實際有播出的國家/地區嗎？這對串流節目、大型賽事可是一大麻煩（例如歐洲歌唱大賽特地把俄羅斯以外的歐洲國家寫出來）。 --窝法乙烷 儿法梦碎 2024年5月1日 (三) 03:46 (UTC)[回复]
至少英语社群相关方面都是直接写模糊的地区而不是写对应国家。--马哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年5月1日 (三) 03:51 (UTC)[回复]

版本4

由於維基百科不是電視指南，因此不要不分青紅皂白地列出在生產地區以外的播放資訊。 相反，如果來源可靠，鼓勵編輯者新增值得注意的非生產地區的播放資訊。這些可能包括：在中國大陸、台灣、香港、澳門、馬來西亞、新加坡等主要中文地區的播放資訊；相關地區的通用語言不是中文，但首次播放以中文製作節目的播放資訊；或大規模國際發行協議。節目的播放平台可觀看地區都需要列明來源及符合可供查證原則，否則其他編輯者有權因可能違反著作權法為由移除未能辨認可觀看地區的整組播放資訊。因應地區IP而調整播放內容的網路播放平台連結、需要登入方能閱讀播放清單的網路播放平台連結、Category:電視外部資源模板相關連結及社群媒體並不是可接受能證明可觀看地區的來源。

下列資料不應被記錄：
  • 準確播放時間。（不包括播放日期及播放時段）
  • 推遲不足30分鐘或並非偶發的延誤播放之資訊。
  • 電視節目重播資訊（在該節目授權區域內的相關播放平台覆蓋比率/可觀看人數較首播平台的覆蓋比率/可觀看人數高一倍或更多除外。）
  • 節目原產地區外，不是以中文提供字幕或配音的播放平台。

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

你的文本內容越來越累贅，有些內容不妨說得再直白一點，修改一下部分描述：「維基百科不是電視指南，請勿不分青紅皂白地列出原產地之外的播放資訊。編輯者在有來源可靠的情況下，在條目中記錄值得注意的非原產地的播放資訊，如中國大陸、台灣、香港、澳門、馬來西亞、新加坡等中文使用地區的首播資訊，還有原生中文節目在還非中文使用地區的首播資訊，或者大規模的國際播放資訊。節目的播放平台及網絡電視的節目可觀看地區都需要列明來源，網絡電視節目連結不合適作為來源，因地區限制訪問，部分編者無法查核，來源是否可靠請通過討論協商。」

英維原文可沒有「否則其他編輯者有權因可能違反著作權法為由移除未能辨認可觀看地區的整組播放資訊。因應地區IP而調整播放內容的網路播放平台連結、需要登入方能閱讀播放清單的網路播放平台連結、Category:電視外部資源模板相關連結及社群媒體並不是可接受能證明可觀看地區的來源。」這段，而是建議討論來源是否可靠，因為條目使用可靠來源本身就是「內容指引」，需要的是討論來源是否可靠（WP:RSP）。--Nostalgiacn（留言） 2024年5月1日 (三) 15:55 (UTC)[回复]

第一段不反對，第二段僅重申Category:電視外部資源模板相關連結只是外部連結，並非來源。更什有編輯者直接扔了Netflix連結出來，當開啟連結時發現是Error。
因應地區IP而調整播放內容的網路播放平台連結、需要登入方能閱讀播放清單的網路播放平台連結—> 重新解䆁WP:可供查證及WP:外部連結方針。--唔好阻住我愛國（留言） 2024年5月1日 (三) 18:13 (UTC)[回复]
而如直接使用WP:RSP，bilibili及Youtube已經不給使用了。--唔好阻住我愛國（留言） 2024年5月1日 (三) 18:15 (UTC)[回复]
WP:RSP描述是，官方內容作為一手資料可靠，也符合可供查證的自身說明（WP:ABOUTSELF）。bilibili及Youtube也適用，不過結合「網絡電視節目連結不合適作為來源」的描述。更建議使用官方在官網、社交平台、或bilibili及Youtube上預告節目播放的日期動態/公告。--Nostalgiacn（留言） 2024年5月4日 (六) 01:22 (UTC)[回复]


現行條文

由於維基百科不是電視指南，因此不要不分青紅皂白地列出在生產地區以外的播放資訊。 相反，如果來源可靠，鼓勵編輯者新增值得注意的非生產地區的播放資訊。這些可能包括：在中國大陸、台灣、香港、澳門、馬來西亞、新加坡等主要中文地區的播放資訊；相關地區的通用語言不是中文，但首次播放以中文製作節目的播放資訊；或大規模國際發行協議。節目的播放平台可觀看地區都需要列明來源及符合可供查證原則，否則其他編輯者有權因可能違反著作權法為由移除未能辨認可觀看地區的整組播放資訊。因應地區IP而調整播放內容的網路播放平台連結、需要登入方能閱讀播放清單的網路播放平台連結、Category:電視外部資源模板相關連結及社群媒體並不是可接受能證明可觀看地區的來源。

提議條文

維基百科不是電視指南，請勿不分青紅皂白地列出原產地之外的播放資訊。編輯者在有來源可靠的情況下，在條目中記錄值得注意的非原產地的播放資訊，如中國大陸、台灣、香港、澳門、馬來西亞、新加坡等中文使用地區的首播資訊；原生中文節目在非中文使用地區的首播資訊；或大規模的國際播放資訊。節目的播放平台及網絡電視的節目可觀看地區都需要列明來源，網絡電視節目連結不合適作為來源，因地區限制訪問，部分編者無法查核。關於個別播放平台節目連結是否可被直接引用，請在本指引討論頁討論協商或評選，唯討論重點應放在著作權法及可供查證原則。

曾經有編輯者把盜版連結放入播放平台區域，故希望藉此指引提醒編輯者著作權法的重要性。--唔好阻住我愛國（留言） 2024年5月1日 (三) 18:34 (UTC)[回复]

上方讨论太长未看全，就该版本的疑问（如已有结论，希望加脚注）：原产地之内的播放信息似乎被暗示可“不分青紅皂白地列出”。原产地的准确定义，范围，联合制作、外包、仅外销等。很多字句应修饰，如“在有来源可靠的情况下”等，由于非定稿我暂时不全部列出。“网络电视节目链接不合适作为来源”听上去有点奇怪，有点像某个来源非公开可用（需登录/部分地区/线下来源）就不适合作来源，可能意思需改善，比如不能访问现象本身、无法存档的网页内容，不适合作来源。--YFdyh000（留言） 2024年5月1日 (三) 19:36 (UTC)[回复]
@YFdyh000:
歡迎任何具建設性的修飾句子。--唔好阻住我愛國（留言） 2024年5月2日 (四) 11:07 (UTC)[回复]
改為「原產地的首播資訊」就行，上面《還珠格格》就是限制播放資訊在「首播」。
YFdyh000提到的情況，我想起了近期一個例子《食草老龍被冠以惡龍之名》，日本輕小說，由中國大陸瀾映畫製作的動畫版在bilibili上首播（2022年7月），2023年1月才在日本電視台播出（[4]）（[5]）。這種涉及跨國版權的節目，「原產地」算中國大陸，還是日本。
早年中港、港台合拍劇也不少，不過都屬於「中文使用地區的」，所以反而沒有這些記錄爭議。--Nostalgiacn（留言） 2024年5月4日 (六) 01:35 (UTC)[回复]

版本5

希望這是最終版

標題：播放資訊

維基百科不是電視指南，請勿不分青紅皂白地列出電視節目的所有播放資訊。編輯者在附上可靠來源的情況下，可在條目中記錄值得注意的播放資訊，如節目原產地的首播資訊；中國大陸、台灣、香港、澳門、馬來西亞、新加坡等中文使用地區的首播資訊；原生中文節目在非中文使用地區的首播資訊；或大規模的國際播放資訊。節目的OTT播放平台及網絡電視的節目可觀看地區均需列明來源，網絡電視節目播放連結不建議作為證明「可觀看地區」的來源，因網絡電視節目播放連結通常不會記錄可觀看地區。關於能否引用特定OTT播放平台的連結，可在本指引的討論頁商議，重點為著作權法和非原創研究原則。

下列資料即使附上來源也不應被記錄：

  • 準確播放時間。（不包括播放日期及播放時段）
  • 推遲不足30分鐘或並非偶發的延誤播放之資訊。
  • 電視節目重播資訊。（在該節目授權區域內的相關播放平台可觀看人數較首播平台的可觀看人數高一倍或更多除外。）
  • 不是以中文提供字幕或配音的播放平台。（節目原產地區播放平台或以中文製作的節目除外。）

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

“网络电视节目播放链接不合适作为来源，因地区限制访问，部分编者无法查核。”语序希望优化；地区性或可能失效的视频的网络播放源，有时是有用的，作为某些信息的一手来源，{{Cite AV media}}，但提供者唯一且无法存档的确实不宜用。“网络电视节目播放链接”被运用时如何区分，我担心存在理解差异。
“个别”是“特定（某个）”吗。“直接引用”，所以有间接引用吗。建议可在、协商或评选、唯应，感觉语意重复。“关于能否引用特定播放平台的链接，可在本指引的讨论页商议，重点为著作权和可供查证原则”。
“准确播放时间”指的是实际播出时点、时长吗，是否与下一条有重复。
“非偶发的延误播放之信息”指什么，已宣布的推迟播放不宜记录？--YFdyh000（留言） 2024年5月8日 (三) 08:51 (UTC)[回复]
  • 對不起，不能使用「視頻」字眼，因實際應用場合不同，放在繁體字地區，意思截然不同。
  • 網路電視是IPTV,網路播放平台是OTT。
  • 「關於能否引用特定播放平台的連結，可在本指引的討論頁商議，重點為著作權和可供查證原則」，這個可以。
  • 沒有重複。
  • 意指不應收錄恆常延誤播放資訊。如果每一集也記錄為什麼延遲播放，那麼與電視指南有什麼分別？
--唔好阻住我愛國（留言） 2024年5月8日 (三) 10:31 (UTC)[回复]
@YFdyh000、@Nostalgiacn、@Milkypine、@Cwek、@CaryCheng、@甜甜圈真好吃、@神秘悟饭:
如沒有特別大的問題，3日後將按照版本5進行公示。--唔好阻住我愛國（留言） 2024年5月10日 (五) 09:55 (UTC)[回复]
我發現有些概念有待釐清，網絡電視目前英維對應是Streaming television，IPTV也可以翻譯做「網絡電視」。搞清楚條目內容和概念，可以更準確描述內容。Streaming television在描述上包括IPTV和OTT等情況。--Nostalgiacn（留言） 2024年5月10日 (五) 10:54 (UTC)[回复]
沿用中文解釋及例子，因為這裡是中文維基百科。中文社群均認為OTT是類似Netflix, Disney+，甚至有播放平台以OTT自居，如myTV SUPER。更什台灣有OTT協會，大部分台灣網絡播放平台也加入了。--唔好阻住我愛國（留言） 2024年5月11日 (六) 00:33 (UTC)[回复]
換句話說，除非有人重新整理該兩個條目至英維內容，否則再改也沒有意思。但是在中文社群而言，英維對OTT的理解是錯誤的。--唔好阻住我愛國（留言） 2024年5月11日 (六) 00:47 (UTC)[回复]
(＋)支持。--CaryCheng（留言） 2024年5月10日 (五) 15:36 (UTC)[回复]
——
3日內無反對聲音，現就版本5進行公示，公示7日至5月20日星期一止。--唔好阻住我愛國（留言） 2024年5月13日 (一) 03:25 (UTC)[回复]
(＋)支持版本5。 --窝法乙烷 儿法梦碎 2024年5月16日 (四) 14:33 (UTC)[回复]

方針研究

無奈衹能(－)反对，僅僅「因地區限制訪問，部分編者無法查核」就不能作為來源的話，未免過嚴。舉例說：西遊記 (無綫1996年電視劇)，那個年代TVB還沒有網站，這樣的規定豈不是不能引用首播前的廣告（廣告裏有說明首播日期）作為來源？（那個廣告衹在香港播出，理論上衹有香港地區才能看到）［當然有人在FB上傳了那個廣告而可能非法地突破了地區限制，故也因此將來可能隨時會被移除］--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年5月17日 (五) 18:24 (UTC)[回复]
  • 我有合理懷疑閣下並沒有仔細閱讀清楚條文，僅意氣用事。
  • 請望淸楚「因地區限制訪問，部分編者無法查核」是針對那些媒介。
    • 針對那些媒介提及的例子，請問閣下可否拿出連結？
  • 既然閣下不打算改可供查證，不看得出對閣下提及的例子有任何影響，因條文建議編輯者依靠可供查證為個別媒體進行協商。
  • **條文並無要求傳統電視內容提供來源**
  • FB已被可靠來源方針定為不可靠（不是我改的）
--唔好阻住我愛國（留言） 2024年5月18日 (六) 04:01 (UTC)[回复]
@Cdip150--唔好阻住我愛國（留言） 2024年5月18日 (六) 04:07 (UTC)[回复]
問題不是出在針對哪些媒介，也不是是否要求傳統電視內容提供來源的問題。正如Ghren君在下面所述，地區限制的連結本來就是可供查證允許的東西，所以根本不可以「因地區限制訪問，部分編者無法查核」為由去說「網絡電視節目播放連結不合適作為來源」。換句話說，在現有可供查證方針下，這些連結本應就不需要經過協商便能使用，但您這樣一改變成把它預設為不適當、而需要額外的協商才能用，有僭越可供查證方針之虞。另外，由於有關問題需要繼續研討，恕敝人要先把公示中止。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年5月19日 (日) 10:34 (UTC)[回复]
@Cdip150:
首先，我希望閣下可以看清楚到底是什麼需要什麼的來源。 該句的首句是「可觀看地區」需要來源，如果堅持是反對，看看閣下有沒有違反WP:非原創研究方針。換句話說，你要用一個網路電視播放清單證明A,B,C地區可以觀看。
然而，運用CDN限制的平台，如果要證明A,B,C地區可以觀看，實際是違反WP:非原創研究的 「綜合已發表材料」段落。--唔好阻住我愛國（留言） 2024年5月20日 (一) 01:13 (UTC)[回复]
為了你，再改。但下次可否不要在公示完結當天反對？其實我可以因公示完成而無視閣下的反對。
———
節目的OTT播放平台及網絡電視的節目可觀看地區均需列明來源，網絡電視節目播放連結不合適作為來源，因網絡電視節目播放連結通常不會記錄可觀看地區。關於能否引用特定OTT播放平台的連結，可在本指引的討論頁商議，重點為著作權法和非原創研究原則。--唔好阻住我愛國（留言） 2024年5月20日 (一) 01:37 (UTC)[回复]
應該是描述有歧義，需要更準確的描述，現在的條文是可以理解成限制地區訪問的連結不能作為來源，這個思路會出現Youtube中國大陸不能訪問，所以不能用。
而你想限制的是來源不能用於說明可觀看地區。如，Ani-One Asia的Youtube頻道，過去的視頻簡介是沒有寫明可觀看地域（[6]），近年有了「播放地區：孟加拉、不丹、汶萊、柬埔寨、斐濟、香港、印度、印尼、寮國、澳門、馬來西亞……」（[7]）--Nostalgiacn（留言） 2024年5月22日 (三) 16:20 (UTC)[回复]
對，沒有錯！這是呼應其他維（不限於英維）的實際做法，但稍微放寬。其他維是完全禁止使用播放清單作為證明可觀看地區的來源。而我的提案只需符合著作權法和非原創研究原則即可。
.
以下是個人見解，與新提案可能有關。
Netflix, Disney+, Amazon Prime Video, YouTube, IQIYI, Viu OTT 的播放清單是肯定違反非原創研究方針。
friDay, KKTV, LiTV, Hami Video, myTV SUPER, now E 的播放清單可能違反是非原創研究方針中的「綜合已發表材料」 ，因播放清單中沒有說明可觀看地區，只在平台使用條款說明。--唔好阻住我愛國（留言） 2024年5月22日 (三) 16:56 (UTC)[回复]
「網絡電視節目播放連結不合適作為來源，因網絡電視節目播放連結通常不會記錄可觀看地區」：如果「網絡電視節目播放連結」記錄了可觀看地區，能否記錄？--Ghren🐦🕑 2024年5月24日 (五) 06:23 (UTC)[回复]
是的--唔好阻住我愛國（留言） 2024年5月24日 (五) 08:22 (UTC)[回复]
由於@Cdip150在本人回答及更正部分用詞後3天沒有進一步回覆。根據WP:共識#一般公示基本規定，現視播放清單不能作為證明「可觀看地區」的問題已經獲得解決。
————
現就版本5 V2進行公示，公示7日至5月31日星期五止。--唔好阻住我愛國（留言） 2024年5月24日 (五) 05:53 (UTC)[回复]
正如Ghren君在下面所述，可以注明是在哪個地區下瀏覽（事實上cite模板還有location參數可以註明是哪個區的），自然也不會有原創研究的問題。還有搞清楚「綜合已發表材料」的前提——是將多個內容作出綜合才會觸法，也即是說如果從香港區的Netflix播放清單作為來源去證明香港區可以觀看及香港區的播放時間，是不會違反非原創研究方針中的「綜合已發表材料」，因為根本不是在多個內容中綜合出來的資料，而衹是取自一個內容。閣下上面的理由足見閣下對於非原創研究「綜合已發表材料」的見解並不正確，故此上述問題並未合理解決。而且，閣下在恢復公示後，Ghren君拋一個問題出來才又修改（公示後才將「不合適」改為「不建議」，兩個完全不同的意思），加上有關條文還是基於閣下對於非原創研究的可能不正確之見解，故此恕敝人還是要把公示中止，有關問題需要繼續研討。（還有請閣下說話前查明事實——我早在公示結束前3天已經提出反對，而非您說的在公示完結當天才反對）--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年5月27日 (一) 19:44 (UTC)[回复]
@Cdip150:
首先，如何證明你從香港區的Netflix播放清單作為來源去證明香港區可以觀看？按Netflix,除了網絡限制區不能瀏覽外，全世界也可瀏覽，你要如何證明特定播放清單內的特定集數可在特定區域成功觀看？這個見解請在及後的商議自行發表，而非在此發表。
其次，請看清楚「 「綜合已發表材料」」是針對哪些例子？
第三，請看清楚該段首句「 以下是個人見解」，如閣下認為Netflix可以基於版權及非原創可被引用，閣下應待通過後自行與其他編輯者商議。
回應@Ghren在上方述「 「網絡電視節目播放連結不合適作為來源，因網絡電視節目播放連結通常不會記錄可觀看地區」：如果「網絡電視節目播放連結」記錄了可觀看地區，能否記錄？」，既然該播放清單有提供所需資訊，為何不能遭引用？
——
另外，公示繼續，因提案提及對於非原創研究的理解是以集體商議為主，而非個人見解。以上！--唔好阻住我愛國（留言） 2024年5月28日 (二) 14:33 (UTC)[回复]
承Ghren君在下面所說的：「就算是借閱，也是有指定圖書館的（地區限制）」，意味讀者衹需親身前往指定圖書館便可查證得到；換成香港區的Netflix播放清單的話，就是讀者親身前往香港並瀏覽Netflix便可證實得到「香港區可以觀看」；注意Ghren君也說的「『需要註冊、付費、特定區域、啟動外部程式或插件的網站』……也無損於來源的可靠性」。既然是維基制度內允許的東西，本應就是不用事先商討就能用的東西，「這個見解請在及後的商議自行發表」根本無從談起，不然您這樣有僭越方針之虞。
Wikipedia:非原创研究#综合已发表材料針對的是「因為A和B，所以C」的情形，而編者直接瀏覽香港區的Netflix播放清單後將香港區的播放資訊寫在條目裏，明顯就不是「因為A和B，所以C」的情形（這是看到來源說了A，條目裏照寫A）；所以直接引用Netflix播放清單並不違反非原創研究。（是故閣下所說「運用CDN限制的平台，如果要證明A,B,C地區可以觀看，實際是違反WP:非原創研究的『綜合已發表材料』段落」本身就是錯誤的說法，況且讀者可以親身前往A,B,C地區瀏覽有關資訊來進行驗證）
那麼既然一開始就不可以認定引用Netflix播放清單是違反非原創研究，何解還要「應待通過後自行與其他編輯者商議」？當本身就沒有違反非原創研究時，從何談起「對於非原創研究的理解是以集體商議為主」？也就是說，「關於能否引用特定OTT播放平台的連結，可在本指引的討論頁商議」這種規則本來就不該訂出來，這是變相預先假定引用特定OTT平台是在進行原創研究。
另外我是說「兩個完全不同的意思」，何解您會理解為「不能遭引用」？我根本沒有這個意思，衹是想說您公示後才改為意義不同的內容，根本不宜繼續公示。不過我也要指出的是：「因網絡電視節目播放連結通常不會記錄可觀看地區」並非「不建議作為來源」的合理理由，原因如前述——讀者可親自前往所指的可播放地區瀏覽該網絡電視平台進行驗證。
基於上述指出的問題仍然有討論必要，本人中止此公示，在沒有得到明確結論前不應恢復公示，還望閣下留意。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年5月28日 (二) 19:51 (UTC)[回复]
首先，針對Netflix，實際是違反「 維基百科不是存放原創研究或原創觀念的場所。在維基百科裡所謂原創研究或原創觀念，指的是未發表的事實、爭論、觀點、推論和想法；以及對已發表材料進行的未發表分析、綜合或總結，並產生或暗示新的結論。以上意味著維基百科不是存放您的個人觀點、經驗或爭論的場所。」段落，而非綜合已發表段落。
Netflix有這樣的播放清單，但隻字不提哪裏可以看。如編輯者單憑一個Netflix播放清單就可判定哪些地區可以看，此僅是「產生或暗示新的結論。」。--唔好阻住我愛國（留言） 2024年5月29日 (三) 00:27 (UTC)[回复]
這邊的人沒人接觸過Netflix等以外的早年OTT平台？夠Yeah在互聯網檔案館上的存檔隨便點一部動畫[如一騎當千第二季]的立即播放按鈕進去會顯示「此片只在香港地區放映」。相信這難以說是原創研究。--S叔 2024年6月27日 (四) 06:30 (UTC)[回复]
問題是這個是一個編輯者自行測試的一個過程，如果閣下可在不用轉換ip的狀況下獲得該影片的可觀看地區，那應該沒有人會質疑是這是原創研究。--唔好阻住我愛國（留言） 2024年6月27日 (四) 11:18 (UTC)[回复]
網路檔案館就是以其服務器及其IP地址存儲某一網站在某日子的存檔，然後再開放給大眾閲覧存檔。因此在上面是能夠在夠Yeah服務範圍[如香港]的情況下顯示上述語句，這不會因為改IP而出現變動。同樣，若一個只服務中國大陸的OTT服務由港澳台用戶使用也可能顯示「此影像只供中國大陸地區的用戶」使用。為何你會認為需要別人改IP才能試出？--S叔 2024年6月27日 (四) 11:46 (UTC)[回复]
如果閣下可在不用轉換ip的狀況下獲得該影片的可觀看地區，那應該沒有人會質疑是這是原創研究。--唔好阻住我愛國（留言） 2024年6月27日 (四) 11:55 (UTC)[回复]
假设您在中英街接收香港的移动信号或者是在厦门接收台湾的移动信号。应该不算是原创总结吧？--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月27日 (四) 11:59 (UTC)[回复]
如果是香港，是原創研究，因為香港電訊商不公佈流動網絡的街道覆蓋範圍（這是他們的內部資料）。而台灣不算，因為他們三家電訊商有主動公佈覆蓋範圍。--唔好阻住我愛國（留言） 2024年6月27日 (四) 12:09 (UTC)[回复]
另求管理員@Ericliu1912，希望我是對非原創研究方針的理解是沒有錯。--唔好阻住我愛國（留言） 2024年5月29日 (三) 00:30 (UTC)[回复]
「實際是違反WP:非原創研究的『綜合已發表材料』段落」這句明明就是閣下說的，所以您現在是反口嗎？不過也不緊要，請注意方針開頭的序言實際上是下面段落細節的濃縮版，條目內容實際有否違反方針，當然要依方針後面段落的明細來判斷，而非僅拿方針的序言就算，也就是說條目內容有沒有犯「維基百科不是存放原創研究……經驗或爭論的場所」，當然還是要看回相關段落（這裏也就是Wikipedia:非原创研究#综合已发表材料）的詳細解釋。您現在僅僅引用方針開頭的序言就片面去說違反，怎麼可能恰當？
假設某人在香港，從播放清單觀看得到某節目，然後該人在該節目的條目中寫香港區可以看，這是一個非常直觀的描述，不屬於「產生或暗示新的結論」。內容有沒有原創研究，完全要看編者寫成怎樣才會知道，不可能事先認定使用某種來源就一定是原創研究。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年5月30日 (四) 23:57 (UTC)[回复]
這個是其中一個笑話：PUI PUI 天竺鼠車車
「木棉花授權地區以外地區：Netflix」，意指公眾可在北韓、俄羅斯等網絡限制區開Netflix即可查證…
還有的是「亞洲：Netflix」，意指公眾可在北韓、中華人民共和國等網絡限制區開Netflix即可查證…--唔好阻住我愛國（留言） 2024年5月31日 (五) 01:58 (UTC)[回复]
我需要行政員@AT看看街燈的這個表述有沒有錯，畢竟之前有管理員以此進行封鎖。--唔好阻住我愛國（留言） 2024年5月31日 (五) 02:00 (UTC)[回复]
您這樣相當於是說用Netflix作為來源表示北韓可看會是原創研究，繼而去說用Netflix作為來源表示美國可看也是原創研究，您這樣無疑是在以偏概全。還是這句：「內容有沒有原創研究，完全要看編者寫成怎樣才會知道，不可能事先認定使用某種來源就一定是原創研究」。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年6月2日 (日) 17:43 (UTC)[回复]
一個Netflix播放清單，配上播放地區，請問如何寫才不算原創研究？
文章沒有表述的而強行配上個人見解不是原創研究，這個「管理員」說法我一定會大規模推廣的。--唔好阻住我愛國（留言） 2024年6月3日 (一) 00:26 (UTC)[回复]
另外，格式手冊的精神不是防止人治嗎？
「內容有沒有原創研究，完全要看編者寫成怎樣才會知道，不可能事先認定使用某種來源就一定是原創研究」—>這句在不少編輯者視為「如有任何爭議，依管理員決定為最終依歸」，而不是「如有任何爭議，依白紙黑字為最終依歸」
.
另外，此提案只有閣下一人反對，其他人也支持，顯然閣下希望擾亂共識。此外，本提案參與者普遍即日互相討論交換意見，顯然提案有迫切需要，而閣下也在我每次回應後臨近「一般公示基本規定」臨界點才提出回覆，顯然有「拉布」企圖。
.
另外，不知是哪位管理員（不點名批評曾被我ping過而默不出聲的管理員），更改了公告欄的標題，原標題已無法反映當前討論的內容，故本人更改了。
.
最後，煩請希望@Cdip150表達意見前ping一ping提案所有參與者，讓他們知道閣下的看法。--唔好阻住我愛國（留言） 2024年6月3日 (一) 11:28 (UTC)[回复]
「編者直接瀏覽香港區的Netflix播放清單後將香港區的播放資訊寫在條目裏」這句我想已經說得很白；
文章沒有明確表述，但若文章本來就有所指的意思，則不屬於產生或暗示新的結論或個人見解，很明顯您這樣的理解是在斷章取義。
「完全要看編者寫成怎樣才會知道」從來就不是由管理員一個來決定，這是您個人猜想出來的見解，無從稽考。事實上也是要各人依照現有的規則去認定，談不上任何「人治」。
注意共識不是點票，況且其他人表示支持時敝人仍未指出問題，坦白說如果您不是另外又發起#提議外部連結指引WP:ELNO同時編入WP:可供查證，我也未必察覺到上述提案與現有的方針不相配，所以我才出手，並不是要希望擾亂共識。還有我除了一次是隔八天和一次是隔兩天半回覆外，基本上自閣下最後回應後不足兩天就回覆閣下，何來每次回應後臨近「一般公示基本規定」臨界點才提出回覆？另外本人因現實生活繁忙不太可能每天都上來回覆，隔幾天才上來這種事在參與本討論前已經出現，並非刻意拉布。再一次提醒閣下在說話前查明事實，勿輕率作出指控。@YFdyh000、Nostalgiacn、Milkypine、Cwek、CaryCheng、甜甜圈真好吃、神秘悟饭--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年6月5日 (三) 00:17 (UTC)
試說明下列影片的完整可播放地區及說明閣下是基於甚麼證據會有這個見解？ https://www.netflix.com/hk/title/81771389 --唔好阻住我愛國（留言） 2024年6月6日 (四) 10:54 (UTC)[回复]
參考「文章沒有明確表述，但若文章本來就有所指的意思，則不屬於產生或暗示新的結論或個人見解，很明顯您這樣的理解是在斷章取義。」，請問文章本來所指的意思是什麼？如果閣下可根據Netflix的播放清單說明播放地區，那看來閣下才是「斷章取義。」--唔好阻住我愛國（留言） 2024年6月6日 (四) 13:48 (UTC)[回复]
利用代理器切到世界各個地區，每個地區都各瀏覽一次該網址便可查驗。日本區看到這是WIND BREAKER—防風少年—，其他區均顯示404信息。
儘管網站沒有表明香港可以瀏覽，但您在香港確實可以瀏覽該網站的話，如果僅因為網站沒有明確表示香港可以瀏覽，所以不能說香港可以瀏覽，就是在斷表面之意，而未取可以一望而知的實際意義（真的可以在香港瀏覽）。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年6月9日 (日) 04:01 (UTC)[回复]
  • 「一望而知」概念僅適用於本地OTT平台，如一看到KKTV就想起只有台灣可以觀看。
  • 「利用代理器切到世界各個地區，每個地區都各瀏覽一次該網址便可查驗。」難道閣下不是花了4天才得出完整可觀看地區？如果可透過「一望而知」就知道可觀看地區，那還需要利用代理器切到世界各個地區，每個地區都各瀏覽一次該網址便可查驗？
--唔好阻住我愛國（留言） 2024年6月9日 (日) 07:37 (UTC)[回复]
不懂你们说什么，但自己试出限制显然不可靠、原创研究、非可供查证。网站可能屏蔽代理、云主机等，校园网、家宽IP或网站防火墙等都会干扰结果。--YFdyh000（留言） 2024年6月9日 (日) 11:04 (UTC)[回复]
既然日本限定的難不到閣下，可挑戰台灣限定的。
這個是村裡來了個暴走女外科於Netflix的播放清單，當使用台灣代理器（大品牌）進入此播放清單，應被跳至（重路由至）南美洲，從而得出404。
在這個情況下，閣下提出的「就是在斷表面之意」就更不成立，因為測試過程可以被干擾。
https://www.netflix.com/hk/title/81592470--唔好阻住我愛國（留言） 2024年6月9日 (日) 11:26 (UTC)[回复]
「一望而知」並非「合計衹望一次而知」啊，是在說前往各地區進入一次後即可知道當前的地區能不能看，而非立即從播放清單的表面就知道哪裏能看。
事實上最正確的查驗方法是親身前往各個地區進入一次該網站，我用代理衹不過是盡量模擬真實情況來節省時間，不然我要花更長更長的時間才能答得到您（我切換到台灣區後是可以在Netflix看到村裏來了個暴走女外科），即使代理可能會因上述一些因素而未必準確，但不應因此也要認定親身前往特定地區瀏覽也是原創研究。另須注意花很久時間才能查證不代表不可查證，如果我旅行往日本在Netflix的播放清單看得到WIND BREAKER—防風少年—，然後當我說在日本可以用Netflix看也要被視為原創研究，我覺得有些不合情理。其實上面Nostalgiacn君已經指出了一點：英維對應的規則其實並沒有禁止或不建議因應地區IP而調整播放內容的網絡播放平台連結，已經可見一斑。還是這句：「內容有沒有原創研究，完全要看編者寫成怎樣才會知道，不可能事先認定使用某種來源就一定是原創研究。」--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年6月11日 (二) 06:39 (UTC)[回复]
回應「英維對應的規則其實並沒有禁止或不建議因應地區IP而調整播放內容的網絡播放平台連結」，
本人於6月9日到英維互助客棧求助區查詢Netflix播放清單可不可以證明可觀看，結果有2名編輯者回答，一名有名編輯者表示會違反非原創研究方針，一名IP用戶表示如引用則會被封鎖，即使是管理員也如此。--唔好阻住我愛國（留言） 2024年6月11日 (二) 11:31 (UTC)[回复]
回應「即使代理可能會因上述一些因素而未必準確，但不應因此也要認定親身前往特定地區瀏覽也是原創研究。」，
請問哪條方針指引容許「維基人到現場目測後在維基內記錄所見所聞」？--唔好阻住我愛國（留言） 2024年6月11日 (二) 11:35 (UTC)[回复]
@HK5201314、Cdip150：我看了最近的一大串討論，Cdip150的觀點大概是來自英維的en:WP:SOURCEACCESS，本地可供查證尚缺乏這方面的討論。
就實體書而言，這個規則是默認的。簡而言之，編者在A國圖書館能找到這本書，B國編者在當地找不到，不能以此為由認為這個書「不存在」。你們上面的討論算是互聯網版本，除了一般的付費墻攔截問題，Netflix的國別限制訪問又出現新的問題。
我認為上面討論混淆了「能否訪問網頁」和「網頁上內容」兩個概念，後者容易理解，和「各地圖書館藏書」的例子一樣，B國無法訪問網站，不等於A國訪問看到的內容不算數。
前者就是現在爭論的點，網絡技術讓A國編者可以用VPN換地區一個一個試能否訪問，以得出「那些地區能訪問」的結論。這個行為，個人認同YFdyh000的說法试出限制显然不可靠、原创研究、非可供查证。--Nostalgiacn（留言） 2024年6月12日 (三) 05:55 (UTC)[回复]
@Nostalgiacn:
街燈管理員的例子應是：
編者A在A國圖書館能找到這本書，編者B在B國圖書館找不到這本書。於是編者A用該書本的「ISBN編號」說明A國圖書館能找到這本書。
.
然後不斷強調：
「內容有沒有原創研究，完全要看編者寫成怎樣才會知道，不可能事先認定(使用某種來源)就一定是原創研究。」
換做例子，應是：
「內容有沒有原創研究，完全要看編者寫成怎樣才會知道，不可能事先認定(引用ISBN編號證明該書本可於某地閱覽)就一定是原創研究。」
.
然而，可供查證方針僅指出內容本身，而非透過該內容的標題及其內容而說明可在哪個圖書館獲取相關書本。--唔好阻住我愛國（留言） 2024年6月12日 (三) 11:10 (UTC)[回复]
這就是我說的混淆了「能否訪問網頁」和「網頁上內容」兩個概念。Cdip150說的是後者，你其實是想針對的是前者。為了避免前者的情況，限制「平台的連結」。造成他憂慮是變相限制「網頁上內容」的利用。
需要在描述上釐清兩者差異，避免可能的誤解。--Nostalgiacn（留言） 2024年6月12日 (三) 11:47 (UTC)[回复]
原句：「網絡電視節目播放連結不建議作為證明「可觀看地區」的來源，因網絡電視節目播放連結通常不會記錄可觀看地區。」
.
我針對的也是後者呀！「能否訪問網站」是可供查證本身規管的（現已放棄相關句子），而「網頁上內容」是原創研究規管的（此公示的句子）。網站本身沒有提及的要誣蔑它有說的是原創研究，對嗎？
原案也提及播放連結只是不建議作為證明「可觀看地區」的來源，而不是不建議作為「正式標題」／在「？？平台上架」的來源。--唔好阻住我愛國（留言） 2024年6月12日 (三) 12:08 (UTC)[回复]
我明白你的意思，畢竟2024年5月22日我就在用Ani-One Asia的例子說明這種情況。請循其本Cdip150質疑的文段是「因地區限制訪問，部分編者無法查核」。單從這個描述，是可以簡單解讀為「B國無法訪問網站，等於A國訪問看到的內容不算數」這個結論。
然後你們討論開始歪樓到「能否訪問網頁」這個議題上了。說到底還是在條文上釐清兩者差異，避免可能的誤解。--Nostalgiacn（留言） 2024年6月12日 (三) 13:16 (UTC)[回复]
(？)疑問：下列資料即使附上來源也不應被記錄：「電視節目重播資訊。」這是不是指大時代 (香港電視劇)#2015年翡翠台重播的內容全部都要刪除？--素菓霖 2024年6月15日 (六) 12:45 (UTC)[回复]
如果是「大時代 (香港電視劇)#2015年翡翠台重播的內容」，一半準確。事件的重點應放在財政司司長的發言及萬千星輝頒獎典禮上，而非節目的播放資訊如播放平台及播放日期。--唔好阻住我愛國（留言） 2024年6月15日 (六) 14:55 (UTC)[回复]
只針對@Kalin8111提出的疑問給出思想實驗
  • A是一個全球/區域性的作品，從上映到現在已經10年以上，也有至少多個系列作(含翻拍、重製、重剪輯或電影版)產生，一或多個區域每年重播。假設有帳號有能力針對每次重播提出來源，頁面增加將近1000個來源。在這個情境，是否適合記錄。
  • B是一個區域性的作品，從上映到現在大約將近1年，因為當地有多種平台(包含單一公司有數種播放平台)，除了在首映的平台重播外，也在其他數個平台重播，假設有帳號有能力針對每次重播提出來源，頁面增加將近20個來源，在這個情境，是否適合記錄。
  • 第二項的情境，B每年固定增加同樣數值的重播資訊及來源，在這個情境，是否適合記錄。
  • 第三項的情境，B可以使用的來源幾乎全部是第一手來源，是否WP:關注度不足
--Rastinition（留言） 2024年6月15日 (六) 20:17 (UTC)[回复]
「 第一手來源」通常即指@Cdip150最關注的「播放清單」問題。如果他沒有其他反對論點的話，3日後即公示。--唔好阻住我愛國（留言） 2024年6月16日 (日) 05:20 (UTC)[回复]
@HK5201314我個人認為你如果一直沒辦法公示完成，調整方向，同時分項公示，先把已經結束且沒有異議的用討論關閉的方式處理，隨著時間經過，你的主題和討論的方向會無可避免的瑣碎/複雜/肥大混合些許離題。
可以關閉/通過的，即使只有少數或小部份，能關閉就能避免過度增生。其他還不能關閉/通過的留著繼續處理。--Rastinition（留言） 2024年6月27日 (四) 12:08 (UTC)[回复]

基於Cdip150對條文的異議並本人因他的異議而作出了用詞上的修訂（目標與原第五版一致）。在修訂後7日內，共有3名編輯者均對他提出見解及例子表示了其結構性問題，而他並沒有對相關問題有任何回應，根據WP:共識，Cdip150提出的疑問已獲得解決。 因此，本提案（版本5）將繼續公示，由2024年6月18日公示7日至2024年6月25日。以上！--唔好阻住我愛國（留言） 2024年6月18日 (二) 13:58 (UTC)[回复]

(－)反对：大時代的情況如果不能記錄播放日期，怎樣帶出因那次重播而引生的現象：財政司司長的發言和TVB的廣告大賺和頒獎典禮等？這樣會令一些重點資訊變成半天吊，規則要再修改。--素菓霖 2024年6月23日 (日) 18:22 (UTC)[回复]
然而重播时发生的股市相关事件跟大时代这个电视剧本身是没关系的，纯粹就是巧合并且相关效应有独立条目压根就没必要在电视剧自身的条目里写。--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月23日 (日) 21:44 (UTC)[回复]
@甜甜圈真好吃：他說的是大時代 (香港電視劇)不是大时代，而且有一點倒是很值得留意的——「這段時間的廣告時段比往常的長」，那次重播吸引了很多商家買TVB那個時段的廣告，這點又不能說沒有關係。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年6月24日 (一) 00:42 (UTC)[回复]
目前暂时发现没有发现TVB在重播该剧时广告商购买的广告数量明显增多的相关来源。（所以相关言论属于观众自行观看节目得到的原创总结。）--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月24日 (一) 01:54 (UTC)[回复]
找到有來源：東方日報和獨立媒體。--素菓霖 2024年6月24日 (一) 07:56 (UTC)[回复]
「 重播而引生的現象」，即「迴响」段落，而非「 播放資訊」段落，而目前「迴响」段落還沒有規定，故只要將重點放在「 財政司司長的發言和TVB的廣告大賺和頒獎典禮等」並記錄於「迴响」段落即可。--唔好阻住我愛國（留言） 2024年6月24日 (一) 11:51 (UTC)[回复]
正如相關段落放在影響段落，而非「播放資訊」，故看不到有影響。--唔好阻住我愛國（留言） 2024年6月24日 (一) 11:59 (UTC)[回复]
@Kalin8111--唔好阻住我愛國（留言） 2024年6月24日 (一) 12:11 (UTC)[回复]
回看整個對答過程，我問「大時代 (香港電視劇)#2015年翡翠台重播的內容全部都要刪除？」，你答「一半準確。事件的重點應放在財政司司長的發言及萬千星輝頒獎典禮上，而非節目的播放資訊如播放平台及播放日期」。如果相關段落放在影響段落就沒有東西要刪除，那連「一半準確」都沒有。然而你說「一半準確」，即就算放在影響段落，有部分內容還要刪除。而因為「而非節目的播放資訊如播放平台及播放日期」這句話，那麼要刪除的部分內容就是當中的播放平台及播放日期，而只能留下財政司司長的發言和TVB的廣告大賺和頒獎典禮的內容。那麼依照你的「一半準確」的回答，就算放在「迴响」「影響」段落怎可能沒有影響？你的第一次回答和第二次回答自相矛盾。--素菓霖 2024年6月24日 (一) 19:06 (UTC)[回复]
這個僅是重點問題，如該重播沒有關注度，理應刪除。
但閣下的例子有關注度，繼而應放在 「迴響」「影響」段落，重點描述其重要事件，而非「播放資訊」段落。如果 財政司司長的發言和TVB的廣告大賺和頒獎典禮的內容 放在「播放資訊」段落，這是離題。
至於一半準確論則視乎閣下如何理解，閣下說「是不是全部都要刪除」，我會說如果該段落放在「播放資訊」，應刪除，因離題。如該段落放在「迴響」「影響」段落，僅應刪除過份仔細的句子。--唔好阻住我愛國（留言） 2024年6月25日 (二) 00:02 (UTC)[回复]
又發現了其實是沒有可靠來源記錄該段落所有論點，刪除（除廣告商大賺外的所有）是正常不過。
P.S. 不怪得要掛模版啦！--唔好阻住我愛國（留言） 2024年6月25日 (二) 00:08 (UTC)[回复]
另外，獨媒的那個是blog,而非報導。而東方的沒有證據支持論點。--唔好阻住我愛國（留言） 2024年6月24日 (一) 11:53 (UTC)[回复]
由於出現新的反對理據，有關問題需要繼續討論，恕敝人中止公示。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2024年6月24日 (一) 00:42 (UTC)[回复]
出現問題的原因是源於提問者選擇來源有誤。--唔好阻住我愛國（留言） 2024年6月24日 (一) 11:23 (UTC)[回复]
另外，該提問者已錯失提問時機，在其他編輯者回應8日有多才有進一步回應，與現有公示程序條文有衝突。根據WP:共識，問題已獲得解決，另無需再回應，因此不影響公示。如有任何問題，請另提出更改WP:共識議案。--唔好阻住我愛國（留言） 2024年6月24日 (一) 11:28 (UTC)[回复]
你的回應前後矛盾，已經不是正當合理回應，問題未解決，公示應當中斷。--素菓霖 2024年6月24日 (一) 19:10 (UTC)[回复]
這個來源可以吧[8]--Factrecordor（留言） 2024年6月25日 (二) 16:47 (UTC)[回复]
這個是應放在影響，而不是播放資訊--唔好阻住我愛國（留言） 2024年6月25日 (二) 16:51 (UTC)[回复]
先(－)反对，這個討論好像完全沒有嘗試通知經常編輯這類條目的用戶前來參與討論，甚有疑慮。--Factrecordor（留言） 2024年6月25日 (二) 15:34 (UTC)[回复]
無效反對（沒有針對提案作出實質意見），此討論已維持3個月又3日，足夠引起社群關注度。而且路西法人的共識議案不包括此方針區。--唔好阻住我愛國（留言） 2024年6月25日 (二) 15:53 (UTC)[回复]
經常編輯的用戶不一定會注意方針討論，不贊成你這樣在後面閉門造車，再要求在前面實戰的遵從。--Factrecordor（留言） 2024年6月25日 (二) 16:33 (UTC)[回复]
請針對下方所有提案也這樣說--唔好阻住我愛國（留言） 2024年6月25日 (二) 16:48 (UTC)[回复]
以往看見很多討論在某個階段都召喚活躍編輯者，原則上我認為每個方針討論都應該這樣，但我比較專注自己感興趣的範疇。其實討論拖得久，或者像上面那樣糾纏在有沒有來源，其中一個原因，正是熟悉此話題的人士參與不足。例如你們在討論大量內容缺乏來源的大時代條目，而我就是曾為此條目添加唯一學術性來源的人。--Factrecordor（留言） 2024年6月25日 (二) 16:58 (UTC)[回复]
「熟悉編輯者」：有啊，大部分熟悉議題的也在公示前已表達意見及潤色條文，你可以看到版本5的支持程度。但因為管理員Cdip進行無限拉布行為，導致拉布產生的回應多於完善條文產生的回應。--唔好阻住我愛國（留言） 2024年6月25日 (二) 17:06 (UTC)[回复]
  • 第一眼印象，「不分青紅皂白地」在這裡絕非合適用詞，可用「不經篩選地」一類字眼。
  • 我反對將這些資訊視為沒有價值的東西。我的觀念是，它們很多時候價值不那麼高，若情況是不加以限制，它們的數量就會過於龐大，則唯有作出取捨。中文維基是指以中文寫成，並不是只收錄和中文地區有關連的內容。如果英維的方針也基於上述精神，大致可以接受。但我覺得英文地區的人因近代的長期主導地位總有點自大，不重視外文外事，往往只視作一種獵奇，反而變得眼光狹隘，相反我們需重視外文外事，更懂海納百川。文化不同，做法也可不同。
  • 不能寫準確的播放時間，但能夠寫時段，那麼時段具體來說是什麼？沒有數字的「深宵時段」、 「黃金時段」？有數字的「月九」、「十點檔」？如來源所寫的就是具體時間，那麼是否會變成原創研究一個時段名稱去描述它？時段與具體時間的字元相差不多，有如此限制的必要？
  • 說起大時代的重播迴響，我想起自己曾在亞洲電視外購劇集列表的編輯。雖然亞視末期在黃金時段重播舊節目，淪為笑話，但該台其實曾在1990年代中在黃金時段播放1970年代日劇配音版，並獲得正面迴響。現實中出現過的情況是千奇百怪的。
  • 我認為條文應明確指出：「當節目的重播曾被二手來源作為主題介紹，可寫於迴響、影響等合適章節，這情況下可在該段落提及日期與時段。」不必研究這一半和那一半可不可以，這種情況下寫多一點點，能有什麼不良影響。
  • 關於一般（沒有迴響記載）的重播情況，我想起無綫電視多年前所拍的金庸劇，在其傳統的翡翠台的重播次數，二十至四十年來可能平均就只有兩三次，就算是平均五六次上下，如果全世都是這種情況的話，我會覺得在內文以一兩句散文概述，只提及重播年份，無傷大雅；然而，那些舊金庸劇至今還在中國內地各衞視時有重播，恐怕沒有誰有興趣一一列出來。因此，我猜這種差異形成了有些地方的人熱衷記錄重播資訊（因為較「珍貴」也並不那麼瑣碎），有些地方的人不習慣這樣做（重播太常見太瑣碎了）。研究重播也未必只有電視迷才有興趣，《文艺生活》2010年第12期《我国电视剧重播现状、存在问题及其对策研究》、《视听》2019年第6期《新媒体语境下经典电视剧重播的价值》、《电视研究》1996年第8期《谈优秀国产电视剧重播的价值》 。
  • 大致看了一遍第5版本，如果沒理解錯，非中文地區作品在產地以外的非中文地區的播出資訊，是被禁止收錄。如上，我傾向如有二手來源支持內容寫成迴響、影響一類章節，不應受此限制。
  • 記得@JuneAugust君在擴編白色巨塔 (2003年電視劇)選dyk時曾引用重播報道；當時我也加了此劇在台灣因太受歡迎，首播後立即重播之先河。有否意見？
  • 關於串流播放平台的討論較為複雜，我想仔細再看一遍，想想有沒有意見。
--Factrecordor（留言） 2024年6月26日 (三) 12:37 (UTC)[回复]
這個是一個優質論點，請容我連同這個「關於串流播放平台的討論較為複雜，我想仔細再看一遍，想想有沒有意見。」一併回答。--唔好阻住我愛國（留言） 2024年6月26日 (三) 12:52 (UTC)[回复]
首先回答論點2，在我翻譯英維前研究所有維基專案，發現只有中文維基百科非常好人地點列世界各地不同媒體的播放資訊。即使是韓維、日維、法維及英維也只專注自己地區的播放資訊，不記錄中文地區的播放資訊，即使是他們的節目賣至中文地區，也不記錄，而英維也明文禁止這個行為。
但考慮到中文維基很喜歡無限放大中文節目迴響，以證明節目對中文社群的重要性，故在翻譯時考慮放寬中文節目在非中文地區的播放狀況。--唔好阻住我愛國（留言） 2024年6月26日 (三) 13:05 (UTC)[回复]
说到这个日维这边有部分作品的话，是有标注中文地区的播出信息。(例如爆旋陀螺系列、爆丸这种玩具广告类动画。)--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月26日 (三) 13:49 (UTC)[回复]
數量是極少，差不多每一萬條就有一條這樣操作。--唔好阻住我愛國（留言） 2024年6月26日 (三) 14:04 (UTC)[回复]
美英日是傳統的作品輸出「大國」，韓國現在也成頂流（韓維規模很小），他們的作品在各地播出，以至被譯成各地語文，是習以為常之事，當然不覺得列出來有什麼意義，但中文地區作品能在其他語言地區播出，尤其能反過來輸出至英美日那些「大國」、尤其被配譯為外語，這情況仍時被視為可貴之事，能引起來源特別提及之事，這不是中文維基的風氣，而是中文地區的風氣。這正是文化差異。--Factrecordor（留言） 2024年6月26日 (三) 13:49 (UTC)[回复]
但是有部分中文维基人把这个习惯带到了其他语言社群的非中文作品中就不大好。(之前就有在日语维基看见过在日本动画条目中写大中华地区播出情况的)@Factrecordor--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月26日 (三) 13:55 (UTC)[回复]
例如某部以新干线为主题的动画。提及的内容如下(这段内容像是中文这边的动画爱好者写的。):

香港 2018年11月22日から2019年8月15日まで無綫電視翡翠台にて、『新幹線戰士』のタイトルで毎週木曜、金曜の17時20分-17時50分に放送。広東語 & 日本語二ヶ国語放送、繁体字字幕あり。 台湾 2019年3月31日から2020年9月13日まで東森幼幼台にて、『新幹線變形機器人』のタイトルで毎週日曜日、10時30分に放送。 --东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月26日 (三) 14:00 (UTC)[回复]

新幹線変形ロボ_シンカリオン#日本国外での放送（第1期）（日语：新幹線変形ロボ_シンカリオン#日本国外での放送（第1期））:看完這個描述，覺得很羞家。--唔好阻住我愛國（留言） 2024年6月26日 (三) 14:09 (UTC)[回复]
也有不醜的時候，如香港首播《大拇指姑娘》，早於日本首播。播映《美少女戰士》時原作者武內直子訪問無綫配音組。--F，actrecordor（留言） 2024年6月26日 (三) 16:56 (UTC)[回复]

版本6(分句公示)

標題：播放資訊

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

維基百科不是電視指南，請勿不經篩選地列出電視節目的所有播放資訊。

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

編輯者在附上可靠來源的情況下，可在條目中記錄值得注意的播放資訊，

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

如節目原產地的首播資訊；

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

中國大陸、台灣、香港、澳門、馬來西亞、新加坡等中文使用地區的首播資訊；

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

@Underconstruction00:「等中文使用地區」--唔好阻住我愛國（留言） 2024年7月4日 (四) 02:08 (UTC)[回复]
另外，這4個items不是規範重點，因為規範主體是下方的「限制收錄」部分，基本上，如馬來西亞的播放資料若不是中文（轉播），其收錄次序將大大降低。
至於指定的6個地區，是中維中文支援地區。基本上，如欲質疑這6個地區的正當性，只能前往元維基反映意見，包括可能新增「英國繁體」、「美國簡體」等。
至於「馬來西亞」及「新加坡」，這邊提及的並不是「官方語言」，而是「通用語言」。--唔好阻住我愛國（留言） 2024年7月4日 (四) 02:17 (UTC)[回复]
原生中文節目在非中文使用地區的首播資訊；

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

或大規模的國際播放資訊。

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

節目的OTT播放平台及網絡電視的節目可觀看地區均需列明來源，

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

OTT播放平台及網絡電視平台播放清單不建議作為證明「可觀看地區」的來源，因為相關平台及播放清單通常不會明文記錄可觀看地區。

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

若相關OTT播放平台及網絡電視平台播放清單明文記錄可觀看地區，則不受此限。

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

如編輯者對於個別OTT播放平台及網絡電視平台播放清單是否可以直接引用作為證明「可觀看地區」有疑問，可在本指引的討論頁商議，重點為著作權法和非原創研究原則。

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

節目的播放時間應以當地時間12小時制或24小時制為準，如來源使用其他報時制式，請轉換至當地時間12小時制或24小時制報時制式。

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

*下列資料即使附上來源也不應被記錄：

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

*準確播放時間。（不包括播放日期及播放時段）
**例子：如節目時間表列明節目的播放時間是06:00-06:30，但實際的播放時間是06:03-06:12及06:15-06:27。編輯者應記錄播放時間是06:00-06:30。

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

了解，沒意見。--Factrecordor（留言） 2024年6月27日 (四) 15:09 (UTC)[回复]
*推遲不足30分鐘或並非偶發的延誤播放之資訊。

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

想明确：推迟指起播，延长非推迟。a或b的延误播放信息。本次《新闻联播》需要xx分钟，若作案例，算偶发吗，是以前少见现在常见。判断偶发是否偏主观。--YFdyh000（留言） 2024年7月4日 (四) 02:33 (UTC)[回复]
我不相信會有可靠來源記錄一節目每集延播的原因。況且，如果是因為上一節目或上一大事而造成的延播，應放在上一節目或上一大事條目記錄，因為與本節目無關。
新聞聯播自偉大領袖上台至今，已經算是恆常。不過，不知道有哪間媒體敢質疑下一節目因偉大領袖的講話而導致延播。--唔好阻住我愛國（留言） 2024年7月4日 (四) 02:53 (UTC)[回复]
不需要每集，一集的也能写。不理解，如果电视剧因晚会延播一次，在晚会条目写它导致电视剧播出延迟/取消，恐怕过于不重要。电视报可能叙述，或者按常识？我说的是，新闻联播因某项大事延长，如何算定数还是偶发；下一节目里是否提，我感觉意义小，类似突发的不可抗力。--YFdyh000（留言） 2024年7月4日 (四) 03:25 (UTC)[回复]
按常識即可，因為這些延播通常沒有可靠來源記錄。即使有，但維基百科可不是電視EPG，恆常記錄延播會導致文章比例出現問題，如果條目來源一半是關於延誤播放，餘下的是其他部分，顯然出現了問題。但若只有少部份的來源是關於延誤播放，那問題不大且顯得偶發。--唔好阻住我愛國（留言） 2024年7月6日 (六) 11:28 (UTC)[回复]
*電視節目重播資訊。
**在該節目授權區域內的相關播放平台可觀看人數較首播平台的可觀看人數高一倍或更多的可被本段記錄
**如節目的重播曾被第三方獨立可靠來源引用重播資料並作主題介紹，請記錄相關主題介紹於迴響、影響等合適章節。這情況下編輯者可在本章節簡單提及重播日期、時段及引起主題介紹的播放平台。

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

不是以中文提供字幕或配音的播放平台。（節目原產地區播放平台或以中文製作的節目除外。）

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

@Factrecordor:這句是英維中English license 定義，封鎖了非英文播放平台。
為確保中維指引與全球對接，避免認知落差（畢竟現時只有中維這樣恆常操作）及公平對待每一節目（避免只有中維過份詳細地列出鎖碎／全部資料）。換句話說，閣下的論點1不能對接世界各地。--唔好阻住我愛國（留言） 2024年6月27日 (四) 16:57 (UTC)[回复]
換言之，如按照英維指引精神，應這樣記錄
範例：一套美國劇
曾在德國、法國播映：不記錄（與中文社群有什麼關係？）
曾在德國、法國、義大利、瑞士播映：不記錄（與中文社群有什麼關係？）
曾在台灣、香港、德國、法國播映：「此劇自2000年起曾在多個地區播映，包括台灣XX頻道（2000年），香港XX頻道（2002年）等。」
曾在台灣、香港、澳門、中國內地、馬來西亞、德國、法國播映：「此劇自2000年起曾在多個地區播映，包括台灣XX頻道（2000年），香港XX頻道（2002年），澳門XX頻道（2002年），中國內地XX頻道（2003年），馬來西亞XX頻道（2004年）等。--唔好阻住我愛國（留言） 2024年6月27日 (四) 17:10 (UTC)[回复]
說一下一些看法：一種語言的維基百科裡，看似之於某語言社群沒關連的項目實在多的是。例如我以為中維中充斥著本來自英維的內容，與英維中本來自中維的內容，本質是不同的。在中維，很多人是自發性從英/外維翻譯成與中文世界沒有關連的條目。但依我看來，在英維不少跟英語世界沒有關連的條目，則都是懂英文的其他語言維基人前去編寫。若不是個維基百科，說不定英語世界的人已經會在大量提刪這些條目。以我理解這就是上述所謂的文化不同。--Will629（留言） 2024年6月28日 (五) 12:22 (UTC)[回复]
據我自己的見聞，在中維裡如果一個條目全部都是英文來源不會受到「歧視」，但在英維一個條目全部都是中文來源的話，會大受質疑。正如最初所說，我認為在這些方面，中維的態度更正確，我們不必跟他們看齊，更不應出現以眼還眼的想法，是英維應當學習我們。--Factrecordor（留言） 2024年6月28日 (五) 13:42 (UTC)[回复]
Wikipedia:是英文维基说的！和Wikipedia:誠如英文維基所說，雖然只是論述，不是方針，但足見全球對接不是必需的。--Factrecordor（留言） 2024年6月28日 (五) 13:51 (UTC)[回复]
假設有兩套沒有在中文地區播映過的德國舊電視劇，一套只在德國本土播映過，一套在歐洲很多國家都播映過，如果它們的條目對中文讀者是有意義的，我相信對於這些讀者來說，兩者在歐洲的差別也是有一點意義的，值得中維僅僅多用一兩句去記錄。--Factrecordor（留言） 2024年6月28日 (五) 14:06 (UTC)[回复]
如果放寬至中文來源記錄相關播放資料，可以嗎？
因為如果該節目對中文讀者是有意義的，應該有中文來源記錄，從而知道該節目對中文社群的重要性。--唔好阻住我愛國（留言） 2024年6月28日 (五) 14:17 (UTC)[回复]
如上文所說，中維沒有「歧視」全外文來源的風氣，中維也對翻譯條目樂此不疲，原則上我(－)強烈反对以來源語文作為判斷準則，甚至擔心這種觀念若蔓延，他朝條目主題本身的關注度都要按來源語文來判斷。--Factrecordor（留言） 2024年6月29日 (六) 11:10 (UTC)[回复]
留名等看之後會在中維看到非洲、南美洲的播放資料，反正我手上是有這些資料。--唔好阻住我愛國（留言） 2024年6月29日 (六) 11:28 (UTC)[回复]
不過如果之後看到 非洲、南美洲的播放資料，會不會被批評WP:NOTIINFO就令一回事。--唔好阻住我愛國（留言） 2024年6月29日 (六) 11:31 (UTC)[回复]
如上，只要有限制數量的規則，瑣碎內容不能無限制大量羅列，不是什麼大問題。--Factrecordor（留言） 2024年7月1日 (一) 10:56 (UTC)[回复]
中文字幕配音/其他語言（原產地)—>無要求
其他語言（非原產地)—>請@Factrecordor建議一個可行可量化數字限制收錄。（初步我打算extend這句「 或大規模的國際播放資訊。」）--唔好阻住我愛國（留言） 2024年7月1日 (一) 11:15 (UTC)[回复]
同上，3個，如何？--Factrecordor（留言） 2024年7月3日 (三) 18:25 (UTC)[回复]
  • 中文及原產播放資訊：無限制，可使用播放清單。
  • 如沒有中文播放資訊：3個（大至小），但必須曾被第三方可靠來源記錄。
    • 跨洲份優先（跨洲份數量越多序列越高），如歐洲跨美洲
    • 以整個洲份為主要「可觀看地區」
    • 當地在地化（如該節目曾於當地重新配音、剪接等，不包括添加當地字幕）
    • 於當地單純轉播及添加當地字幕
    • 於當地單純轉播
——
這個可以嗎？@Factrecordor--唔好阻住我愛國（留言） 2024年7月4日 (四) 00:57 (UTC)[回复]
沒問題。--Factrecordor（留言） 2024年7月4日 (四) 15:45 (UTC)[回复]
我認為最大3個太死板，如果有4個外國地區的播放資訊真的很受關注的，也要強迫刪除其中1個？這樣似乎又不合理。--素菓霖 2024年7月9日 (二) 09:46 (UTC)[回复]
「 我認為最大6個太死板，如果有7個外國地區的播放資訊真的很受關注的，也要強迫刪除其中1個？」
「 我認為最大7個太死板，如果有8個外國地區的播放資訊真的很受關注的，也要強迫刪除其中1個？」--唔好阻住我愛國（留言） 2024年7月9日 (二) 15:12 (UTC)[回复]
雖然全球只有中維 「沒有「歧視」全外文來源的風氣」，但如果編輯者認真起來，把全球國家及地區的所有播放資料連來源一併列出，在文章比例上有一定問題，而且顯得資料不經篩選，過分詳細。如單計首播平台，也有超過100個來源也是關於播放資料，還不計個別重播資料。--唔好阻住我愛國（留言） 2024年6月29日 (六) 12:18 (UTC)[回复]
最主要應concern是假設我寫了YouTube TV可以看A節目，但不幸地，Youtube TV的服務地區只有美國，對於常用中文社群地區，應透過什麼途徑使用Youtube TV收看此節目，相關方法是否符合平台的著作權法？另外，YouTube TV只有英文配音及英文字幕，對於常用中文社群，是否會故意利用YouTube TV收看此節目也成問題，--唔好阻住我愛國（留言） 2024年6月28日 (五) 14:27 (UTC)[回复]

集中討論！--唔好阻住我愛國（留言） 2024年6月27日 (四) 13:22 (UTC)[回复]

我對串流平台的討論沒有意見。--Factrecordor（留言） 2024年6月27日 (四) 15:11 (UTC)[回复]
經過一天，我認為以散文簡述及限制數量，比起全禁，更能平衡需求。初步提案如下：
  1. 非中文地區作品在產地以外非中文地區的電視播放資訊，不能列於資訊框，可在內文以散文形式簡述。限制如下：數量只限三個（但中文地區不受此限制）；如曾播放國家/地區只有一至三個（包括中文地區），則可以全數提及國家/地區、電視頻道與首播年份；如曾播放的國家/地區多於三個，為免陷入何地可以作為例子的爭論，列出中文地區之餘，其他地區只能以「自XXXX年起曾在多個地區播映」一類的語句簡單概括；如中文地區已有三個或以上，其他地區亦只能以「自XXXX年起曾在多個地區播映」一類的語句簡單概括。
    範例：一套美國劇
    • 曾在德國、法國播映：「此劇2000年曾在德國XX頻道播映，2002年曾在法國XX頻道播映。」
    • 曾在德國、法國、意大利、瑞士播映：「此劇自2000年起曾在多個地區播映。」
    • 曾在台灣、香港、德國、法國播映：「此劇自2000年起曾在多個地區播映，包括台灣XX頻道（2000年），香港XX頻道（2002年）等。」
    • 曾在台灣、香港、澳門、中國內地、馬來西亞、德國、法國播映：「此劇自2000年起曾在多個地區播映，包括台灣XX頻道（2000年），香港XX頻道（2002年），澳門XX頻道（2002年），中國內地XX頻道（2003年），馬來西亞XX頻道（2004年）等。」
  2. 原產地的重播資訊，不能列於資訊框，可在內文以散文形式概述。限制如下：只可收錄編者所知（按照來源）的最早一次重播及最近一次重播的具體資訊，包括播放頻道及時間。最早一次及最近一次重播年份對了解重播情況有參考作用，但由於未必能確定是否最早及最近，最近的重播也需要更新，建議避免在文中直接使用「最早」「最近」這類字眼。若重播次數超過兩次，其他重播可概括為曾於XX頻道（若不止一個，可寫「多個頻道」一類字眼）重播多次（若有來源統計次數，可具體寫「X次」）。時間方面，若重播頻密程度達一年多次，可精細至重播首天的日期，否則只可提及重播年份。若節目的重播曾被二手來源作為主題介紹，可寫於迴響、影響等合適章節，則不受上述限制。
    範例：此劇曾在不同頻道重播多次，較早期的有1999年在XX頻道的重播，較後期的有2018年在XX頻道的重播。
  3. 非原產地的重播資訊，一般沒必要收錄，有二手來源証明具特別迴響除外。
--Factrecordor（留言） 2024年6月27日 (四) 15:07 (UTC)[回复]
舉例：七十二家房客:到目前為止，此節目逢星期一至五下午3-5在大灣區衞視（包括之前的南方衛視）重播，連續重播了十年有多，按照閣下的理據，應如何記錄？--唔好阻住我愛國（留言） 2024年6月27日 (四) 16:38 (UTC)[回复]
對於這種情況，最好當然是找到來源視之為非常見情況，作出特別介紹，最理想的描述就是直接採用你上述的描述（但未必需要仔細至時段），連具體年份也變得不重要。若來源未能支持寫得那麽仔細，也可簡述為「此劇經常重播」。但若對引用來源及非原創持絕對嚴格的態度，但手上實際又只有電視節目表的話，那麼我建議寫：「此劇在XXXX年已有重播（如有舊節目表証明，如沒有則可不寫這句），2020年代仍有重播。」我主張的理念是一旦情況複雜，數量過多，就盡量簡略概括，而不要因噎廢食，因有些條目情況複雜，就要那些簡短的也一起陪葬。--Factrecordor（留言） 2024年6月28日 (五) 14:11 (UTC)[回复]
但是如果是换到另外的频道首播(实质仍是该公司范围内的频道重播)类似于翡翠台的橘色荣耀！(該節目是重播同公司另外一個電視頻道的電視節目)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月9日 (二) 12:06 (UTC)[回复]
可觀看人數一致（740萬人可以收看），媒介一致（免費電視），配音也不是在翡翠台優先發放（J2有粵配先），故應放棄翡翠台資料。--唔好阻住我愛國（留言） 2024年7月9日 (二) 15:22 (UTC)[回复]
但除非能證明TVB Anywhere版本的翡翠台有播橘色榮耀（觀眾群由香港變成全球），這個就可以記錄（J2沒有TVB Anywhere版本）--唔好阻住我愛國（留言） 2024年7月9日 (二) 15:25 (UTC)[回复]
该节目只在香港地区有版权，所以海外不会播出。--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月11日 (四) 06:49 (UTC)[回复]
@Pyruvate、Stevencocoboy、CyrussKK1230、Ckh3111、Apple v、Tw drama、Nickice、Yau Sze Long、Bosco64、Will629、Ricky36、SeoTae、Redmi123465、Benkwokmars、Tanqrsucks、任晏延、紅軍28、Hkmjai、WiKilover022、Underconstruction00、Achanhk：各位，這是關於電視劇條目格式的指引修訂，旨在對一些瑣碎的播放資訊進行限制，主要着眼於重播資訊、非中文地區播放資訊、OTT播放平台及網絡電視平台播放資訊，請看看有沒有意見？
--Factrecordor（留言） 2024年6月27日 (四) 15:35 (UTC)[回复]
沒有意見，Factrecordor大的補充條目我覺得可以寫進去。 --窝法乙烷 儿法梦碎 2024年6月27日 (四) 16:12 (UTC)[回复]
沒有意見--WiKilover022（留言） 2024年6月29日 (六) 04:46 (UTC)[回复]
@Cdip150@Kalin8111請問兩位對後續討論有沒有意見？--Factrecordor（留言） 2024年6月29日 (六) 11:24 (UTC)[回复]
中文好像不是馬來西亞的官方語文，如何定義它屬於中文地區？近數十年加拿大是華人熱門移民地點，我也可以說那裡的華文華語市場不容忽視。參考漢語國家和地區列表 ？--Underconstruction00（留言） 2024年7月4日 (四) 01:25 (UTC)[回复]

版本7(分句公示)

沒有爭議/爭議已在版本6解決

1.標題：播放資訊

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

2.維基百科不是電視指南，請勿不經篩選地列出電視節目的所有播放資訊。

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

3.編輯者在附上可靠來源的情況下，可在條目中記錄值得注意的播放資訊，

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

4.如節目原產地的首播資訊；

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

5.中國大陸、台灣、香港、澳門、馬來西亞、新加坡等中文使用地區的首播資訊；

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

6.原生中文節目在非中文使用地區的首播資訊；

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

7.或大規模的國際播放資訊。

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

8.節目的OTT播放平台及網絡電視的節目可觀看地區均需列明來源，

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

9.OTT播放平台及網絡電視平台播放清單不建議作為證明「可觀看地區」的來源，因為相關平台及播放清單通常不會明文記錄可觀看地區。

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

10.若相關OTT播放平台及網絡電視平台播放清單明文記錄可觀看地區，則不受此限。

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

11.如編輯者對於個別OTT播放平台及網絡電視平台播放清單是否可以直接引用作為證明「可觀看地區」有疑問，可在本指引的討論頁商議，重點為著作權法和非原創研究原則。

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

12.節目的播放時間應以當地時間12小時制或24小時制為準，如來源使用其他報時制式，請轉換至當地時間12小時制或24小時制報時制式。

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

13. *下列資料即使附上來源也不應被記錄：

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

14.*準確播放時間。（不包括播放日期及播放時段）
**例子：如節目時間表列明節目的播放時間是06:00-06:30，但實際的播放時間是06:03-06:12及06:15-06:27。編輯者應記錄播放時間是06:00-06:30。

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

15. *推遲不足30分鐘或並非偶發的延誤播放之資訊。

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

16. *電視節目重播資訊。
**在該節目授權區域內的相關播放平台(同一媒介)可觀看人數較首播平台(同一媒介)的可觀看人數高一倍或更多的可被本段記錄
**如節目的重播曾被第三方獨立可靠來源引用重播資料並作主題介紹，請記錄相關主題介紹於迴響、影響等合適章節。這情況下編輯者可在本章節簡單提及重播日期、時段及引起主題介紹的播放平台。

--唔好阻住我愛國（留言）

修訂版本

17. 不是以中文提供字幕或配音的播放平台。
    • 節目原產地區播放平台或以中文製作的節目不在此限。
    • 如相關節目因該播放平台的播放而對當地社群引起重大迴響，則不在此限。
    • 如相關節目的所有播放平台不設中文字幕或配音及未能引起重大迴響，編輯者可以選擇從下列序列中選擇最多3個其他語言的播放平台，唯相關資料必須曾被第三方可靠來源收錄。
      • 跨洲份播放平台，跨洲份數量越多序列越高，如歐洲跨美洲。
      • 以整個洲份為主要「可觀看地區」。
      • 當地在地化，如該節目曾於當地重新配音、剪接等，但不包括添加當地字幕。
      • 於當地轉播及添加當地字幕。
      • 於當地轉播，並沒有任何後製工作。

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

@Factrecordor--唔好阻住我愛國（留言） 2024年7月15日 (一) 11:26 (UTC)[回复]
不反對--Factrecordor（留言） 2024年7月17日 (三) 16:39 (UTC)[回复]
基於已清除所有反對意見，此版本將在3日後開始公示。--唔好阻住我愛國（留言） 2024年7月20日 (六) 06:43 (UTC)[回复]
(？)疑問：家有兒女先在香港J2台播出，然後在澳視澳門台播出。因為澳門可以收看J2台，所以在澳視台播出之前澳門觀眾已經在J2台看過一次。這種情況，家有兒女可不可以收錄澳視的播放資訊？（就這樣看好像不可以？）--素菓霖 2024年7月21日 (日) 19:05 (UTC)[回复]
這個反倒是先收集TDM的信息吧。(當時TVB的授權只有香港地區直到TVB Anywhere上線澳門為止。)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月21日 (日) 21:32 (UTC)[回复]
澳門可以雖然收看J2台，但是在收費有線電視及OTT 平台 TVB ANYWHERE，與免費電視TDM的媒介不一，根本比較不到，所以樓上說的沒有錯。--唔好阻住我愛國（留言） 2024年7月22日 (一) 00:35 (UTC)[回复]
我換個例子：賈神探，先在TVB明珠台播出，然後在澳視澳門台播出。翡翠台和明珠台在澳門一直都是可以免費收看的，所以在澳視台播出之前澳門觀眾已經在明珠台看過一次。這種情況，賈神探可不可以收錄澳視的播放資訊？（就這樣看好像不可以？）--素菓霖 2024年7月23日 (二) 05:20 (UTC)[回复]
然而TVB播出的贾神探只有香港地区的授权并没有在澳门地区的授权所以依旧只能收录TDM的资讯(实际上澳门合规传输香港台的途径就只有公共天线、澳门有线电视以及TVB Anywhere并且TVB Anywhere因播出节目版权仅限香港的原因并未上架明珠台节目)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月23日 (二) 07:17 (UTC)[回复]
如果明珠台在澳門公共天線合規傳輸，那麼TVB放在明珠台的節目應該也要有澳門的授權，如果TVB沒有賈神探的澳門授權，TVB是不可以把賈神探放在明珠台播放的，只能放在只有香港合規看到而澳門合規看不到的頻道。既然賈神探可以在明珠台播放，應該可以合理推斷TVB也有澳門的授權，否則TVB這樣會侵犯版權。--素菓霖 2024年7月25日 (四) 09:38 (UTC)[回复]
所以首段先說「節目的OTT播放平台及網絡電視的節目可觀看地區均需列明來源，」如果需要改至「節目的可觀看地區均需列明來源，」我無任歡迎，不過大家有沒有聽過「訊號溢出」這個名詞？--唔好阻住我愛國（留言） 2024年7月25日 (四) 11:38 (UTC)[回复]

有關維基百科:高風險主題中回退限制的修訂意見

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:高風險主題。

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

在此討論中，桐生ここ建議：「我覺得應該修改高風險主題相關方針，確立一個原則，就是0RR不能長期使用，就像IP不能永久封鎖一樣。」
我認為這有一點道理，故建議修改維基百科:高風險主題中回退限制：

現行條文

管理員可對特定頁面實施回退限制（如回退不過一或回退零容忍）

提議條文

管理員可對特定頁面實施回退限制（如回退不過一或回退零容忍[a]）

  1. ^ 必須加上非永久執行期限

不知大家意見如何？--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年6月9日 (日) 08:32 (UTC)[回复]

不建議强制限定必須加上期限，畢竟方針的説法是理想的情況下所有的條目都應該是0RR。建議把强制性質改為建議性質。Sanmosa Snipe–Clam Grapple 2024年6月9日 (日) 13:19 (UTC)[回复]
你説的理想情況是自願實行，維基百科:高風險主題說的是管理員按這方針強制執行，兩者不一樣。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年6月9日 (日) 15:26 (UTC)[回复]
然而無可否認的是如此修訂方針將會起到從根本上否定理想情況的效果。此外，我不認為你能保證未來完全不會有需要不限期實行的0RR。Sanmosa Snipe–Clam Grapple 2024年6月9日 (日) 15:44 (UTC)[回复]
如有就到時再改（要求保證本身還是一種WP:BALL），實際上，由回退不過一、到回退零容忍、到永久回退零容忍都需要時間，管理員也可以局部封鎖/頁面禁制/主題禁制某些長期編輯戰者，故「需要不限期實行0RR」是極端假設（本來我想建議高風險主題0RR最長一年，為爭取支持而最後放棄）。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年6月9日 (日) 16:32 (UTC)[回复]
現行條文

管理員可對特定頁面實施回退限制（如回退不過一或回退零容忍）

提議條文

管理員可對特定頁面實施回退限制（如回退不過一或回退零容忍[a]）

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

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

比較贊同這個版本的寫法。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 02:29 (UTC)[回复]
反對修訂，提案人對「不限期」有明顯錯誤的理解。請@Cmsth11126a02搞清楚「永久」跟「不限期」的分別。高風險主題沒有「永久」限制，只有「不限期」限制，而現在在各方針逐漸淘汰「永久」一詞的同時不應繼續繼續加入「永久限制」等本身就不符合方針解讀的用詞。「不限期」0RR意旨「不知道什麼時候才能停止一切編輯戰行為」而不能單純通過任意時間阻止後續的編輯戰，而不是「不管編輯爭議是否停止也繼續」。
根據WP:CTOP#修訂或撤銷編輯限制，任何高風險措施都能由執行管理員或共識在任何時候解除，由管理員自行實施超過一年的限制也能由任何管理員解除。如果0RR已不適用，直接按方針指明的程序解除限制即可，根本用不著刻意加注釋。--路西法人 2024年6月10日 (一) 03:59 (UTC)[回复]
0RR跟全保護並不相同，全保護完全剝奪一般編者的編輯權，0RR僅是要求回退前先行討論獲取共識，並不阻止編者編輯，「極端措施」說著響亮，但根本就不「極端」，尤其在社群認定有高的編輯戰風險的主題中，實施更嚴格措施直至合理相信不再有編輯戰行為更是不能稱作「極端」。--路西法人 2024年6月10日 (一) 04:03 (UTC)[回复]
@LuciferianThomas：還請你説明一下你反對的是否包括桐生ここ的提議。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 04:22 (UTC)[回复]
在我眼中兩人的提案毫無分別，「永久限制」一概念已有明顯錯誤。--路西法人 2024年6月10日 (一) 09:14 (UTC)[回复]
如果只是字詞使用不當的問題，那修正相關字詞就是了：
現行條文

管理員可對特定頁面實施回退限制（如回退不過一或回退零容忍）

提議條文

管理員可對特定頁面實施回退限制（如回退不過一或回退零容忍，惟後者一般不會不限期實施）

這種寫法説明了0RR的限制一般不會不限期實行，但如果有確實需要不限期實行0RR的情形，條文本身不禁止如此作為。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 10:35 (UTC)[回复]
換了字眼仍然是對「不限期限制」的錯誤理解。換了字不代表就對了。任意選擇的限制期間能保證結束後不再有類似的長期或嚴重編輯戰行為？相反，主題在短時間內解決爭端後，就算是不限期限制，不也可以請求解除？「不限期」不是「不能被撤銷」，只是「不會自動解除」。0RR措施本身不限制對條目的善意更新，亦沒有可預見的濫用可能，甚至實施了也不會有任何負面影響，根本沒有限制的原因。上面用戶提出「極端措施」的說法跟「不限期封鎖比有限期封鎖更『重』」一觀念是同樣錯誤，「不限期」是確保問題解決才解除，「有限期」反而是不論情況是否有改善都自動解除，顯然沒有解決問題。--路西法人 2024年6月10日 (一) 13:05 (UTC)[回复]
你维的不限期事实上是永久，没有人去申诉，管理员会自己主动看情况撤销吗？--桐生ここ★[讨论] 2024年6月10日 (一) 17:18 (UTC)[回复]
如果你認為「沒有人去申訴」是問題，那麼為什麼不是去鼓勵申訴，而是去管制不限期呢？--路西法人 2024年6月12日 (三) 03:28 (UTC)[回复]
申诉也会让后来处理的管理员觉得「我这样撤销了，会不会驳了前面管理员的面子」，你看有几个不限期能申诉成功？而0RR意味着编者要走在钢丝上，可能没有回退的意思，但就不小心触犯了，如果是1RR还有一个缓冲。--桐生ここ★[讨论] 2024年6月10日 (一) 17:22 (UTC)[回复]
申訴也會讓後來處理的管理員覺得「我這樣復原了，會不會駁了前面管理員的面子」，至今未曾有同樣例子，管理員解除其他管理員實施的不限期封鎖案例眾多，從來沒人覺得這樣是會下了他人的面子。反而更多出現執行管理員不同意解除但最後還是解除了的不限期封鎖，你說的情況連「事實上」都不符合，純屬臆測。
1RR的措施不是給「緩衝」用，實際情況是在回退他人編輯後才發起討論（仍然不是良好的編輯態度），而不是0RR鼓勵的先發起討論再回退。況且，0RR「不小心觸犯了」還可以被警告、還得獲明確告知限制才會構成觸犯，並不是觸犯了就一定是直接封鎖，緩衝本來就存在。下面回覆你的留言的時候已經敘述。--路西法人 2024年6月12日 (三) 03:37 (UTC)[回复]
建議修改至「設置不限期／永久回退零容忍的管理員需(定期)檢視及在公示版說明檢視結果。」
註：管理員的任何管理行動需向共識交待，而且管理員需要證明該事件只有回退零容忍才能解決問題，定期主動檢視正正可以讓其他編輯者知道管理員有持續關注此事。--唔好阻住我愛國（留言） 2024年6月10日 (一) 05:07 (UTC)[回复]
(＋)支持設置不限期／永久回退零容忍的管理員需(定期)檢視及在公示版說明檢視結果。防止不限期变成实际上的永久，以及做出决定之后就撒手不管。--桐生ここ★[讨论] 2024年6月10日 (一) 17:34 (UTC)[回复]
Wikipedia:高風險主題#申訴及覆核中已有复核机制以修改对条目的限制措施，未见必要。--Mys_721tx（留言） 2024年6月10日 (一) 06:59 (UTC)[回复]
@Mys_721tx：這樣説吧：一般性地實行作為限制措施的不限期0RR是否有違比例原則？我不是不信任覆核機制，但我認為可以通過更細緻的規範來避免用戶不得不觸發覆核機制。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 10:35 (UTC)[回复]
說出「不得不」就完全證明你對「不限期」的理解完全錯誤。問題解決就可以隨時提出解除限制，這從來不是「希望避免」或「需要避免」、不是「不得不」（不情願）觸發的機制。--路西法人 2024年6月10日 (一) 13:09 (UTC)[回复]
@LuciferianThomas：我的用詞或許不夠precise，但我的出發點是管理員有可能錯誤判斷問題的嚴重程度（也就是説有些不限期0RR從一開始就不應該設置），這就是我説的比例原則問題，而這與問題在何時得到解決無關。如果你為了我用詞的問題而忽略我背後的出發點的話，那你就是在因人廢言了。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 13:19 (UTC)[回复]
我已經很清楚論述，0RR不是一刀切禁制回退，而是要求回退非破壞編輯前先行獲取共識。「通過回退去回應編輯爭議」本來就不屬於用戶的「權利」，用戶並無任何被侵犯、限制的權利，完全不違反比例原則。如果管理員錯誤判斷問題的嚴重程度，那就直接走共識或跟管理員交涉更改措施啊，如果是「錯判」問題的話，那麼應該處理的就是錯判的問題，經申訴、覆核修改實施的編輯限制，這個情況下改方針是毫無意義的啊。
「因人廢言」：不考慮說話者的言論是否合理，只因其身分、品貌不合己意就不採納其意見。指的是人身攻擊的言論，我並沒有發表針對你人身的言論，而是指出你的理解錯誤，正是針對你背後出發點已經存在錯誤這一點去回應。我現在要再次指出你的發言中對「因人廢言」存在觀念錯誤，並必須指出你指控我「因人廢言」屬於誹謗，請為你的不當發言道歉。--路西法人 2024年6月10日 (一) 15:43 (UTC)[回复]
我认为不应该长期使用0RR的原因并非阁下所说「通過回退去回應編輯爭議」，而是编者可能没有回退的意思，但在编辑过程中可能修改了别人的内容，造成非主观意愿上的回退或其他人眼中认为参与了编辑战，造成不自觉的违反了0RR，然后招致封禁。和意图利用回退进行编辑战是不同的。如果长期使用0RR，意味着编者永远走在钢丝上，可能为了怕违反0RR，直接就不参与编辑了。而如果是1RR则有一个缓冲，让人放心，即使不小心搞错了还有一次机会。--桐生ここ★[讨论] 2024年6月10日 (一) 17:32 (UTC)[回复]
「修改他人內容」並不屬於回退，「有人認為」並不代表「確實違反」；僅有。另，依據高風險主題方針的機制，用戶需獲充分告知編輯限制措施，才會因違反而有進一步管理行動。更何況，管理行動不代表必然即刻封鎖，首犯可發警告處理（當然，有編輯戰前科的用戶可能會被直接封鎖）。還有，0RR正是鼓勵對內容有異議時不要逕自編輯，而是先與其他用戶商討，確認有共識再改，有共識的回退顯然不構成0RR的條件。這麼多緩衝條件還不夠？--路西法人 2024年6月11日 (二) 12:42 (UTC)[回复]
如果你能確保所有管理員都能做到不把「修改他人內容」認定為回退的話，那你這裏説的話我願意相信三分。此外，WP:編輯戰#豁免情况並沒有提到“有共識的回退”屬於豁免情況，你説的“有共識的回退顯然不構成0RR的條件”似乎沒有方針的明確支持。Sanmosa Snipe–Clam Grapple 2024年6月11日 (二) 14:07 (UTC)[回复]
編者未能商定頁面內容而反覆刪改或復原對方編輯的行為稱為編輯戰，經討論共識商定頁面內容就已經不構成編輯戰中刪改或復原他人編輯的情況。下面一邊說要看方針的原則，卻連編輯戰最基本的構成原則都忽視了，這是什麼說話態度？--路西法人 2024年6月11日 (二) 15:30 (UTC)[回复]
我說的是practical的執行情形。當然，我並不鼓勵你衝紅燈。Sanmosa Snipe–Clam Grapple 2024年6月11日 (二) 16:21 (UTC)[回复]
空口無憑的說辭真的顯得非常軟弱無力。實際運作上任何管理員不能也未曾有案例將「已經達成共識而撤銷他人編輯」視作編輯戰。--路西法人 2024年6月12日 (三) 03:57 (UTC)[回复]
從你上面的回應來看，你可以説是完全沒有正確理解我提到的出發點（既然如此，那你確實算不上“忽略”我的出發點，也從而算不上“因人廢言”了），我説的是“從一開始”來避免錯誤判斷的發生，而不是錯誤判斷的事後處理，事前與事後兩者在性質上還是有很大的不同的，誇張一點說，這可以類比成事前選擇安全性行為與事後發現懷孕然後選擇墮胎的分別。此外，我認為桐生ここ的意見有一定的合理之處，你完全沒有考慮到不限期0RR可能引申的副作用，畢竟practical的實行狀況還是很重要的。還是說你覺得我說的“副作用”實際上也是“作用”？那只能説我跟你對0RR的理解有著重大差別，而這種重大差別並不能從任何意義上理解成“觀念錯誤”。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 22:29 (UTC)[回复]
建議性質的限制顯然不能「從一開始」解決問題，「建議」的措施往往形同虛設，在真的要用的情況下還能被拿出來說嘴阻擋。這是我在多個討論都明確說過的。而在這個情況下，0RR也不適合被限制可以維持多久，這是目前提案的核心修改，在我針對提案方對「永久」和「不限期」等詞彙存在錯誤理解經已回應（不限期比有限期更嚴重觀念錯誤）。提案方到底是在提出限制使用0RR還是限制0RR時長？我在針對提案核心「時長」問題提出駁論，提案方給我扯去0RR作用幹嘛？更何況，這裡所說的「副作用」是忽略機制已經存在的其他緩衝條件（警告、明確告知編輯限制等）的說詞。我反對的是限制措施時長，你要規定管理員在針對違規事例的處理手法（要求先行對首犯編輯戰者警告、明確告知回退界線、告知應先獲取共識，再犯才封鎖），我是完全不反對。--路西法人 2024年6月11日 (二) 12:56 (UTC)[回复]
“建議性質的限制顯然不能‘從一開始’解決問題”倒不一定，雖説我承認大部分情況下確實如你所説的一樣，但是這次的情況不一樣。在沒有現在這裏提議的“建議性質的限制”的情況下，VPO那邊依然有相當數量的用戶認為法輪功主題的不限期0RR有不妥當之處，由此可見社羣機制已經初步形成不能輕易實行不限期0RR的普遍觀點，將這個觀點明文化有助於社羣在提議實行不限期0RR時先三思，以及在管理員計劃實行不限期0RR時起監督、檢視之效。
我就再拿上面提到的安全性行為與墮胎的分別來説明吧，在我看來你這裏的觀點可以類比成反對提倡安全性行為，具體的理由則可以類比成認為提倡安全性行為的效果是“形同虛設”的，並且認為提倡安全性行為是部分人對性教育的“錯誤理解”，以及認為警告意欲進行不安全性行為者與告知意欲進行不安全性行為者進行不安全性行為的風險能足夠避免進行不安全性行為的風險。我倒不是説我類比出來的觀點是十惡不赦的，但我個人對於你就0RR的觀點與我類比出來的觀點都同樣抱持著不認可的態度。
WP:何谓忽略所有规则#何谓“忽略所有规则”也有特別提到“規則的精神高於規則的言辭”，由此可見真正重要的其實是文字背後的實際含義，而不是文字表面上的含義，如果文字表面上的含義與背後的實際含義並不對應的話，修改表面上的用辭實際上無濟於事。要是你真的覺得規則文字表面上的含義特別重要的話，你優先做的應該是讓規則文字表面上的含義成為新的實際含義。
Sanmosa Snipe–Clam Grapple 2024年6月11日 (二) 13:57 (UTC)[回复]
那邊的討論是「不實施」0RR，這個提案是「限制0RR實施時長」，我針對的是提案中「限制實施時長」的說法，也是明確各方針中「不限期事實上不是永久」，而是在適當時候才提出撤銷措施，不能接受任何「不限期等於永久」的扭曲觀點。在封鎖方針及實行上，不少案例在有限期的編輯限制後仍無改善，只能通過搞事和封鎖的輪迴處理，而現今開始有管理員實踐「不限期不等於永久，在能表現改善態度後即能解封」的「不限期不是永久」原則，該等情況下起碼能儘可能確保問題解決才撤銷編輯限制，而非任意在問題未解決就自動解除編輯限制，然後無限出現擾亂及限制的輪迴。這個本來就是原則。
更可笑的是，本地版本的高風險主題就是我推的。我所指出的都是高風險主題方針和機制本地版本設計時的基礎原則，Sanmosa卻完全無視我引入機制時的「規則的精神」，說辭彷彿好像比我還更清楚我自己寫的內容和方針機制的設計，然後把他自己全新詮釋的觀點視作「規則的精神」。並非只有我才能詮釋我的條文，但起碼要尊重一下引入方針者指出引入規則時的想法和精神吧？強硬把不符合規則本身精神的觀點強加於規則之上，然後將其稱作「規則的精神」，這跟閱讀理解卷子問「作者寫這文章時的心態是什麼」連作者都不同意標準答案有啥分別？--路西法人 2024年6月11日 (二) 15:47 (UTC)[回复]
我感覺我跟你關注的點並不一樣，我很難認為這樣的討論如此持續下去能有甚麼建設性的成果，畢竟我自己現在並不是不推進此案不可的情形，這方面的討論不如到此為止。但無論怎樣說，我並不認為你能有效釋除其他討論參與者對於practical的執行方式的疑慮，如果這個問題不能解決的話，那可以預期的是就算這次的提案沒有通過，此後仍然有可能會不斷出現類似的提案。Sanmosa Snipe–Clam Grapple 2024年6月11日 (二) 16:16 (UTC)[回复]
你支持的提案修改的是0RR的時長，而不是整體限制0RR的使用。限制0RR使用時長並不會解決你口中的「執行疑慮」，執行期間仍然會存在你所說的「疑慮」，不會因限制執行0RR時長而改變這一點，限制執行時長反而產生「問題未解決就自動解除措施」的新問題。提案並無實質的針對處理你口中的問題，簡單來說就是你說的一切根本就跟提案無關。--路西法人 2024年6月12日 (三) 03:43 (UTC)[回复]
既然你都這樣説了，那你嘗試處理其他討論參與者的意見吧，反正我也沒打算繼續參與這裏的討論了。Sanmosa Snipe–Clam Grapple 2024年6月12日 (三) 06:38 (UTC)[回复]
這種限制是不是不應該明文寫出，而應該經由實際操作形成慣例？不過若社群有共識，仍然可以寫。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月10日 (一) 18:44 (UTC)[回复]
同意桐生ここ的「不限期事實上=永久」意見，只考慮不限期的字面意思而無視中維事實往好的說是官僚主義，往壞的說⋯⋯（我不說了，畢竟要AGF）--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年6月11日 (二) 13:33 (UTC)[回复]

離題

根據WP:INDEF，
不限期封鎖是指無失效時限的封鎖，通常用於防止嚴重擾亂維基百科正常運作的行為或嚴重違反維基百科方針指引的行為。不限期封鎖或適合用以阻止持續的不當行為，但仍需注意同樣不是作懲罰之用。 參見：Wikipedia:不限期不等於永久 另需注意「不限期」不應理解為「永久」，即不代表該封鎖永恆不可變，而僅代表未有訂立封鎖時長，封鎖不會自動過期解除。被不限期封鎖的使用者在合適的情況下可獲解除封鎖，並在讓其被觀察的情況下繼續編輯，以確保該使用者未來不再違反維基百科的不同規範。但在特別嚴重的情況下，如無管理員願意解除封鎖，該使用者實際上已被社群禁止編輯。

建議WP:0RR可以參照WP:INDEF統一「不限期」用法，連同新增上方提及的「持續審視」方案。 以上！--唔好阻住我愛國（留言） 2024年6月11日 (二) 14:31 (UTC)[回复]

反提案

LuciferianThomas版本

上面提案方對「永久」的理解錯誤已經使提案不能被採納，但限縮0RR使用的觀點也是有道理。就此提出反提案，以對方針用詞的正確理解去修訂回退限制的描述。

§ 標準措施 §§ 回退限制

現行條文

管理員可對特定頁面實施回退限制（如回退不過一或回退零容忍），此對所有編輯該條目的用戶均有效；管理員亦可對經常涉及編輯爭議的個別用戶實施同類回退限制，以此阻止編輯戰，同時鼓勵其優先以溝通處理爭議。

提議條文

管理員可對特定頁面或個別用戶實施回退限制（如回退不過一或回退零容忍），鼓勵用戶優先以溝通處理爭議，避免編輯戰延續。任何用戶編輯已實施此編輯限制頁面時均需遵守回退限制。社群及管理員僅應在頁面編輯者持續未能在回退前試圖以討論解決爭議的情況下對頁面實施回退零容忍。

§ 時長

現行條文

高風險主題的編輯限制可由管理員自由裁量，設為任何時長以至不限期。

提議條文

高風險主題的編輯限制可由社群及管理員自由裁量，設為任何時長以至不限期。社群應在問題解決後主動提請覆核編輯限制，確認問題解決後即應放鬆以至撤銷編輯限制。管理員可以依覆核程序主動複審編輯限制，並應在接獲申訴時積極依程序處理。

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

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

Cmsth11126a02版本

(－)反对：這不能解決桐生ここ的「不限期事實上=永久」，延長及重新確認限制一段説其他管理員可以「在限制生效一年後，延長或重新確認其認為需要維持的原有限制」，但如沒有其他管理員作任何行動就會維持現狀（加上桐生也說過：「我這樣復原了，會不會駁了前面管理員的面子」）。因此我建議：

§ 時長

現行條文

高風險主題的編輯限制可由管理員自由裁量，設為任何時長以至不限期。

提議條文

高風險主題的編輯限制可由管理員自由裁量。

§ 延長及重新確認限制

現行條文

任何第三方管理員（包括原執行者）均可在限制生效一年後，延長或重新確認其認為需要維持的原有限制；更新限制的管理員將被視作該編輯限制的執行者。

社群共識針對特定頁面實施的編輯限制不適用此程序。

提議條文

任何第三方管理員（包括原執行者）均必須在限制生效滿一年前，更新其認為需要維持的限制，否則限制將在生效滿一年後失效；回退零容忍限制更新前需要確認社群共識；更新限制的管理員將被視作該編輯限制的執行者、更新限制的時間將重新計算時限。

社群共識針對特定頁面實施的回退不過一限制不適用此程序。

以上沒有禁止一直實行回退零容忍限制，而是要求最少每年讓社群確認一次回退零容忍限制是否需要繼續，以增加透明度。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年6月15日 (六) 05:40 (UTC)[回复]

標記刪除條文及新增條文。--CaryCheng（留言） 2024年6月15日 (六) 11:44 (UTC)[回复]
(－)反对：管理員人數少，社群成員人數多。還是別要求管理員主動記得處理這些限制，而是讓社群成員在時間到了之後申請解除限制，再由管理員排案處理。--CaryCheng（留言） 2024年6月15日 (六) 11:52 (UTC)[回复]
反對閣下的反對。現時維基理論上有60多位管理員，而高風險主題目前只有10個，閣下的憂慮僅源於管理員不作為。--唔好阻住我愛國（留言） 2024年6月16日 (日) 02:25 (UTC)[回复]
  • 咦??反對我的反對??
  • 管理員不作為??我沒記錯的話，現在的情況就是活躍的管理員不足，積壓的工作則是爆炸多，就算高風險主題只有10個，活躍的管理員還是做不完吧...
--CaryCheng（留言） 2024年6月17日 (一) 14:20 (UTC)[回复]
主要是社群的推力太大，中文維基百科社群沒什麼吸引力，基於熱情而開始編輯的使用者（包含管理員）經過一段時間熱情完全消退後，社群也沒有給予動力再繼續，加上互助客棧的討論品質時常不是很好，討論時用戶之間常常針鋒相對，讓人更不想參與，長久下來是推力大於拉力，人變得越來越少，這是我所觀察到的現象。
中文維基百科很多問題不是單一原因造成的，是種種問題累積下來產生的結果。 (--~~Sid~~ 2024年6月17日 (一) 16:26 (UTC)[回复]
同意。--CaryCheng（留言） 2024年6月19日 (三) 15:42 (UTC)[回复]
（就Cmsth11126a02的counter-counter-proposal而言）我在下方AARV的討論裏提過引入類似助言（日语：助言）的機制，我認為高風險保護或許可以以同樣的方式辦理，這裏以「有共識後再執行」來處理「管理員獨自判斷」的潛在弊端與下面AARV的情況一樣存在一定程度上不符比例原則的問題。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 13:50 (UTC)[回复]
(－)反对因對不限期的原則及復原原狀的實際情況存在錯誤理解而發起的提案。不限期並非事實上等於永久，近期管理員多了執行不限期封鎖，並在問題解決的情況下獲得解除，不但證明了「不限期並非永久」，更是證明了不存在「會不會駁了前面管理員的面子」。提案人並無任何例子證明「有管理員會覺得撤銷其他管理員操作是會駁了前面管理員的面子」，反而是大量的解除封鎖操作反證這個情況毫不存在，即使執行管理員不同意，還是會有管理員出面解封的情況。Cmsth11126a02的提案是毫不必要地增加管理員的工作量，且嚴重忽略了高風險主題本質上就是「已知長期存在擾亂編輯」的主題才導致有不限期編輯限制的需求，而單純基於其自己認為社群不願意提出覆核（事實上社群經常且非常願意質疑管理員操作）而作出扭曲「不限期」本意的提案。高風險主題的原意就是在這些高擾亂風險的主題上容許管理員更大程度上嚴格實施編輯限制，堵截持續已久的擾亂行為，此提案的唯一效果並非「保障」編輯權限，而是導致高風險主題賦予管理員在局部主題上更高執行權力的意義全無。--路西法人 2024年6月20日 (四) 02:49 (UTC)[回复]
(？)疑問-在下以為，以前維基百科的方針明確、對管理員的說明責任條件要求。在下建議要注意，新訂方針，例如高風險主題方針、修改方針，不宜模糊、過多由管理員權力，容易出現主觀等問題。Wetrace歡迎參與WP人權專題 2024年6月30日 (日) 03:14 (UTC)[回复]

LuciferianThomas版本公示

原提案因觀念錯誤無法繼續推進，而Cmsth11126a02後來的反反提案未獲任何支持且有多人反對；針對2024年6月13日 (四) 06:50 (UTC)發佈的反提案的唯一反對意見仍是以推進，  公示7日，2024年7月10日 (三) 02:03 (UTC) 結束。--路西法人 2024年7月3日 (三) 02:03 (UTC)[回复]

我不認為counter-proposal有具足WP:共识#什么是共识所指明的「和重要少數的意見作出適當妥協」，因此容許我程序性反對公示counter-proposal。將討論串中超過一半的討論以「觀念錯誤」之名打成非正當合理的意見顯然並非正當合理的做法。Sanmosa 蚌埠 2024年7月3日 (三) 23:34 (UTC)[回复]
同意Sanmosa，他的「觀念錯誤」理由是方針原文是他寫的，但正是對此原文有質疑才有此討論，這「觀念錯誤」是循環論證（甚至不客氣地説，這可能是對該方針的WP:OWN）。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年7月4日 (四) 17:02 (UTC)[回复]
另外在公告欄暫停公示。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年7月4日 (四) 17:06 (UTC)[回复]
選擇性摘用「和重要少數的意見作出適當妥協」，而無視「共識應當考慮到所有正當合理的意見」的程序性反對顯然與方針要求有所牴觸。少數意見除了「妥協」外，還有「回應」的選項。對其反反提案及意見的個人留言已有清晰的回應，依Sanmosa自己寫的方針註釋「任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決」。若兩位認定Cmsth的反對意見正當合理，只空口說「以『觀念錯誤』之名打成非正當合理的意見」，卻完全不論證如何不構成我所指出的「觀念錯誤」，就是「沒有回應我的回駁」，又憑甚麼認定我依照我自己修訂的方針在當初提案時已經清晰指出的詮釋來回駁其觀念錯誤並非「正當合理的回應」從而不能視為「已解決的意見」？
再次重申反駁「不限期事實上=永久」：在多個方針內容的「不限期」均賦予社群充分的權利去就不限期措施提出覆核和申訴，有權利而不用並非「事實上等於永久」而是個別用戶自己的問題。多則不限期封鎖能獲得申訴解除、過往設立高風險主題前的多則不限期或長期保護均獲得提前解除等案例均證明，這一點不論從方針基礎還是實際情況均不成立，實際情況就是社群本來就有人會善用這個賦予的權利，並不存在「等於永久」的「事實」。這是原提案、對反提案的反對意見及反反提案中的觀念錯誤、理解錯誤、事實錯誤、論證錯誤。
由於Sanmosa及Cmsth11126a02未能反論證其意見如何不符合我所說與方針原則及社群運作的例證事實，其程序性反對並未附有任何實際論證而無效，維持公示狀態。--路西法人 2024年7月5日 (五) 02:17 (UTC)[回复]
「共識應採納多數人的意見，並和重要少數的意見作出適當妥協」與「重大修改更應獲得絕大多數的同意」是現行方針條文沒錯吧，「多數人的意見」在哪裏？Sanmosa 蚌埠 2024年7月5日 (五) 02:42 (UTC)[回复]
認同，因是LuciferianThomas提出公示，故其應該先證明這是「多數人的意見」（而不是由反對者先證明這不是），為避免編輯戰，我給其24小時，24小時後如沒有這是「多數人的意見」的證明則我去暫停公示、直至相關證明出現為止。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年7月5日 (五) 02:52 (UTC)[回复]
反提案之提案人（我本人）、CaryCheng明確表明支持；Ericliu1912及YFdyh000雖未明確表明支持，也有表示認可反提案，言語上視同支持或不反對提案。針對反提案內容唯一提出實質反對意見是Cmsth11126a02，而有關說法已經論證是存在謬誤的論證，經回應後視作意見已解決。Sanmosa的程序性反對基於Cmsth11126a02已被解決的意見，且並非對提案進行實則性點評的意見，依註釋一規定不視作此條文所指的「新留言」與「相關意見」。
共識不是算人頭，而是看論據的強弱，這是自制定方針之時已經提出的基本原則，至今仍然不會改變。Cmsth11126a02的意見連拿來論證的例證都存在事實性錯誤，這顯然不是一個強論點，而是基本可以視作無效的論點（論點的基礎並不存在）。再說，就算真的點人頭了，4:1也顯然是一個多數。不論是論點還是人數都是符合共識方針的要求。我在上方留言要求兩位提出有效回駁我所指Cmsth11126a02的論點存在謬誤，你們都完全迴避掉，僅繼續以不存在的程序問題拉布。若兩位執意擾亂顯然存在有效多數意見的提案公示，我將請求其他管理員介入。--路西法人 2024年7月5日 (五) 06:04 (UTC)[回复]
正如我此前所言，我感覺我關注的點跟你並不一樣，而我重看一次整個討論串後，我認為Cmsth11126a02、桐生ここ等人關注的點也跟你並不一樣。這裏一直抓着「不限期」與「永久」的關係不放，而不嘗試處理有人認為「不限期」事實上等同於「永久」的背後成因的處理相當詭異，而且令這個討論串儼然成了兩個相互獨立而被強行放在一起的討論串。說白些，你對着他們兩位（和當時的我）就有如對牛彈琴一般，我不認為對牛彈琴能從任何意義上被認為是「合理回應」。Sanmosa 蚌埠 2024年7月5日 (五) 06:52 (UTC)[回复]
有人認為「不限期」事實上等同於「永久」不等於這就是事實，而事實例證證明事實並非如此，這已經足夠回應。我一直都是在回你方之觀點，只是你一直不覺得我在回，不等於我沒回。對牛彈琴比喻對不懂道理的人講道理（wikt），所以你是在說你自己不懂道理，也不願意聽嗎？--路西法人 2024年7月5日 (五) 08:07 (UTC)[回复]
「對牛彈琴」也可以用於「比喻講話、做事不看對象」（另外我相信你知道維基詞典不是可靠來源，雖說你給出來的解釋確是較為通用的解釋就是了），你所說的「我一直都是在回你方之觀點，只是你一直不覺得我在回」也有可能是你一直以為自己是在回應對方的觀點，但實際上並沒有，而我也沒辦法阻止大家（對，不止你一位）迴避正視我所提到的「背後成因」的問題。平心而論，我對你的提案本身並沒有意見，但我實在無法從任何意義上認為你的提案有滿足「作出適當妥協」的要件，因此我提出的只是程序性反對，如果你能妥善處理「作出適當妥協」的要件的事情的話，我不反對你的提案付諸公示。Sanmosa 蚌埠 2024年7月5日 (五) 08:35 (UTC)[回复]
minor tangent: 个人一直以为「我和你讨论就是对牛弹琴」含贬义而非中性。--0xDeadbeef (留言) 2024年7月5日 (五) 08:53 (UTC)[回复]
我就針對了所謂「背後成因」指出了反例例證了，你假裝看不到不是我的問題。--路西法人 2024年7月5日 (五) 23:46 (UTC)[回复]
我看了一次整個討論串，我還是無法從你在這裏説的每一句話裏找到任何一句有真正回應到管理人員相關信任問題的話。在這裏處理一下管理人員相關信任問題的事情就有那麽難嗎？Sanmosa 蚌埠 2024年7月6日 (六) 05:52 (UTC)[回复]
上方討論提及「管理員」的留言僅圍繞「管理員不願意回退其他管理員的操作」（已有充分案例證明不符合事實）和「擔憂管理員錯判形勢」（早前已回應有充分的申訴機制，還有四個不同的申訴途徑，未來更有第五種），而從頭到尾僅僅現在才出現「信任」二字套在管理員身上。你假裝看不到不是我的問題。--路西法人 2024年7月6日 (六) 08:57 (UTC)[回复]
我不認為這些話有真正回應到管理人員相關信任的問題。從上方的相關討論可見他們對於你説的那些“申訴機制”並不全然信任（補充一點：我留意到社羣裏對“申訴機制”的不信任是作為對管理人員的不信任的一部分存在的），我認為這是能用直覺來推斷的事情，然而你卻沒有嘗試這樣做。另一方面，你也不能強制要求他們必須信任那些“申訴機制”。我不知道你會不會考慮我在2024年6月18日 (二) 13:50 (UTC)的留言裏提到的助言機制，我認為這應該能足夠處理相關的信任問題了，但最終是否在提案裏採用這機制的決定權在你。Sanmosa 蚌埠 2024年7月6日 (六) 10:54 (UTC)[回复]
所謂「不信任申訴機制」是基於「管理員不願意回退其他管理員的操作」的聲稱，既然該聲稱已經證明不符合事實，那麼「不信任申訴機制」亦無其他論據。--路西法人 2024年7月7日 (日) 00:56 (UTC)[回复]
這樣説吧：我傾向於把社羣成員認為「管理員不願意回退其他管理員的操作」理解為社羣成員對管理人員的不信任的一種表現形式，而顯然地社羣成員對管理人員的不信任的表現形式不可能只有一種，因此就算「管理員不願意回退其他管理員的操作」這種表現形式並不成立，這並不意味社羣成員對管理人員的不信任同樣地並不存在。而且，就算沒有這裏的討論串，我相信社羣不用腦子也能知道社羣成員對管理人員的不信任是普遍存在的。Sanmosa 蚌埠 2024年7月7日 (日) 01:31 (UTC)[回复]
沒有論證、論據的論點不是一個討論或辯論中需要被考量的有效論點。憑空而來的「不信任」毫無討論價值，因此說法毫無基礎成本但可造成無限傷害。--路西法人 2024年7月7日 (日) 15:58 (UTC)[回复]
否定不信任的存在才是真正的傷害。世間上的各種制衡機制都來自於肯定／默認不信任的存在，否定不信任的存在會使本應建立的制衡機制不能建立，從而使本應被制衡者可以行使不合比例原則地大的權力。任何情況下，只要牽涉高階權限的信任問題，都應該假定不信任的存在，直至反證成立，因此這裏應該是你來論證不信任的不存在或不適用，而非其他人來論證不信任的存在。Sanmosa 蚌埠 2024年7月8日 (一) 00:15 (UTC)[回复]
維基百科本來就跟外面的體制不一樣，我們走假定善意原則。你竟然說不是由「懷疑他人」的一方論證而是由「依假定善意信任他人」的一方論證，假定不信任就完全是假定惡意的體現，與維基百科的基本原則相悖；參與、議事心態顯然很有問題。同時，我已充分論證在各場所都存在管理員適當使用覆核權的情況，包括解除長期保護、解除封鎖等，多數情況都沒造成爭議，這已充分反映社群在很大程度上信任管理員正確行使覆核權；目前社群中所謂的「不信任」僅僅是個別不願接受管理員依方針的覆核結果而產生的現象，如過往行政員推翻RFDA效力等，並非行政員的做法不符合方針（即當下之社群共識），而是有人拒絕接受。--路西法人 2024年7月8日 (一) 01:40 (UTC)[回复]
我認為濫用「個別」一詞並非好主意。假定善意也並非無條件、無限制的，畢竟連你也沒有否認並非所有情況都沒造成爭議（你的用詞是「多數」），社羣要重建對一組人員或一件事情的信任不可能是三言兩語、一朝一夕的事情。此外，當時顯然不止一人認為行政員對「溝通無效」的理解有根本上的問題，對去年行政員提早中止RFDA程序的做法的不認可也顯然不能被描述為「個別人士拒絕接受」。管理人員本就應該預期他們都能在有需要時為自己的一言一行作合理解釋。Sanmosa 蚌埠 2024年7月8日 (一) 05:46 (UTC)[回复]
考慮到我實在沒有舌戰羣儒的耐心，我雖則依舊維持我的程序性反對，但我不會再干預你對此公示所作的任何一切宣告，不過我也不會就任何其他人對你的公示本身及你對此公示所作的任何一切宣告所採取的行動負任何的責任。Sanmosa 蚌埠 2024年7月8日 (一) 06:05 (UTC)[回复]
（補充說明：我認為是次討論出現有人認為「不限期」事實上等同於「永久」的情況的背後成因是社羣中相當數量的成員對管理人員的不信任，故此滿足「作出適當妥協」的要件的方式應該是以合適的方式處理相關信任問題。）Sanmosa 蚌埠 2024年7月5日 (五) 08:39 (UTC)[回复]
另外，我也有必要聲明我的反對僅為程序性反對，而非針對任何特定提案。Sanmosa 蚌埠 2024年7月5日 (五) 07:18 (UTC)[回复]
@Ericliu1912：這是否需要管理員intervene的情形？Sanmosa 蚌埠 2024年7月5日 (五) 02:51 (UTC)[回复]
依據上次共識方針的經驗，管理員介入大概也沒有用，尤其本人特別不適合。看到此案例，我想你自己應可衡量共識方針所謂「正當合理意見」條款實務運用效果如何了。另外，相關方案需要社群支持，自非任何人說的就算。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月5日 (五) 04:41 (UTC)[回复]
@桐生ここ、Wetrace，我真的完全不知道LuciferianThomas他是如何「點人頭」數出4:1的。Sanmosa 蚌埠 2024年7月5日 (五) 06:43 (UTC)[回复]
(？)疑問-關於Sanmosa上面提出的疑惑，是不是請LuciferianThomas能協助說明釐清？關於LuciferianThomas的公示，程序上似乎已經引起些用戶的疑問？Wetrace歡迎參與WP人權專題 2024年7月7日 (日) 15:38 (UTC)[回复]
還有，Cmsth的論點真的很難以置信。當前社群正在進行（明顯違反方針）的RFDA，起因正是有管理員願意去推翻其他管理員的不限期編輯限制操作而引發（雖然後來調查後解除限制的管理員發現自己的調查確實存在問題），這已經充分證明了桐生聲稱有管理員可能會想「我這樣復原了，會不會駁了前面管理員的面子」而不推翻前人實施編輯限制的說法完全不符合事實，我真的不知道Cmsth和桐生是活在平行宇宙還是怎樣。這麼重大的案例證明「管理員不會因為維護前人面子而拒絕推翻操作」，究竟是怎麽能繼續提出「我這樣復原了，會不會駁了前面管理員的面子」這個完全不符合事實的虛幻說法作為論證。--路西法人 2024年7月5日 (五) 02:28 (UTC)[回复]
支持路西法人提案，反对Cmsth11126a02的提案。反对是因为容易被钻空子，给管理员增添不必要的麻烦。（需要每年都更新）事实上禁制没用了再取消禁制不就好了。支持是因为将复核的一半责任交给社群，不仅可以通过讨论形成解除禁制的共识还不限制管理员自行复审。不限期与永久这一议题明显有争议，而路西法人的提案经我观察对于不限期vs永久这一争论来说是没有太大关系的。0xDeadbeef (留言) 2024年7月5日 (五) 07:14 (UTC)[回复]
(？)疑問-(1)現行高風險主題的運作，最核心的議題是不是：是否確實有依照該方針，進行對條目風險的合理「論證」？(2)在下還是重申一點意見：以前維基百科的方針明確、對管理員的說明責任條件有所要求。在下建議要注意，新訂方針，例如高風險主題方針、修改方針，不宜模糊、過多由管理員全權，這容易出現主觀等副作用問題。會不會架空了過去的維基百科核心基礎方針呢？Wetrace歡迎參與WP人權專題 2024年7月7日 (日) 15:38 (UTC)[回复]
你在回复我的观点吗？我怎么看不懂你在表达什么。--0xDeadbeef (留言) 2024年7月7日 (日) 15:53 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
循例通知：@LuciferianThomas：你似乎忘了更新{{Bulletin}}。@Cmsth11126a02、桐生ここ、Wetrace：LuciferianThomas已經逕行宣告其提案通過。Sanmosa 蚌埠 2024年7月12日 (五) 15:52 (UTC)[回复]
Special:Diff/83340332說：維基百科:不限期不等於永久是封禁方針論述，不是維基百科的核心方針或指引，未獲社群廣泛承認⋯⋯而LuciferianThomas的提案正是建基於「不限期不等於永久」已獲社群廣泛承認的前提，按照演繹推理我質疑這提案有效性。（當然如LuciferianThomas堅持這提案有效，我也不會硬碰硬，我只在此證明我質疑過）--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2024年7月14日 (日) 15:26 (UTC)[回复]
(？)疑問-（謝謝Sanmosa通知在下）(1)請教，為什麼能夠逕行宣告提案通過？這是不是不妥當、效力也有問題吧？在下不大能理解這作法。其他用戶提出疑慮的意見，有被處理嗎？(2)這樣逕行宣告通過的作法，讓在下感到，在下所提醒、憂心的 問題，恐怕會出現：「以前維基百科的方針明確、對管理員的說明責任條件有所要求。在下建議要注意，新訂方針，例如高風險主題方針、修改方針，不宜模糊、過多由管理員全權，這容易出現主觀等副作用問題。會不會架空了過去的維基百科核心基礎方針呢？」。Wetrace歡迎參與WP人權專題 2024年7月18日 (四) 11:21 (UTC)[回复]

電視劇演員名單序列

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手冊/電視。

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

年初編輯《飛常日誌》時我已發起過討論，當時因陳豪 (演員)在官方網頁名列於首，維基條目無奈跟從，此劇男主角實際上是馬國明，而陳豪 (演員)只是客串，均是顯然易見的、無需爭論（撇開拿出官方排名盲目跟從此一理由）的事實。近來留意到《巨塔之后》又出現類似爭議，這次輪到馬國明客串，他到底應不應列為主演。就此，我倡議不論官方或任何傳媒來源，如果在演員名單排序上出現明顯偏離實情的情況，維基人應該酌情討論一個較符合實情的共識，討論中不應再盲目依從來源（如撇除該些來源而有爭議者，則可參考該些來源）。就算是官方排名，也可能是基於一些利益關係去進行排序，一些傳媒來源則可能照抄官方；維基向來對自傳及非獨立/一手來源的中立性有所警惕，因此我認為明顯不符實情的排序可視為不中立，維基人應該酌情處理，不要盲目依從，不顧實情。--Factrecordor（留言） 2024年6月18日 (二) 13:14 (UTC)[回复]

@Rastinition、Manchiu、Pyruvate、Stevencocoboy、CyrussKK1230、Ckh3111、Apple v、Tw drama、Nickice、Yau Sze Long、Bosco64、Will629、Ricky36、SeoTae、Redmi123465、Benkwokmars、Tanqrsucks、任晏延、银色雪莉：--Factrecordor（留言） 2024年6月18日 (二) 13:35 (UTC)[回复]
你好，我想大概知道發生甚麼事--Tanqrsucks（留言） 2024年6月18日 (二) 13:53 (UTC)[回复]
簡單來說就是如果官方（網頁或海報等）的演員名單排序，把一個明顯只是客串、戲份甚少的演員放得很前，維基條目是應該依從，還是撇開官方而按實情討論。我根據以往及2024年tvb劇集編輯紀錄中看似較活躍者來邀請討論。--Factrecordor（留言） 2024年6月18日 (二) 14:15 (UTC)[回复]
？？？--任晏延（留言） 2024年6月18日 (二) 14:35 (UTC)[回复]
扬子晚报，“在《新闻女王》中有亮眼表现的马国明和高海宁，本次将继续担任主演角色。”，或许陈豪可能比较知名，算是宣传手段吧。--Kethyga（留言） 2024年6月18日 (二) 13:38 (UTC)[回复]
當時說明馬國明是男主角，陳豪是客串的報道有不少，問題是Wikipedia:格式手冊/電視有依照官方的演員名單排序的條文，因此便被拿出來當作金科玉律，什麼都不管了。所以本次討論我特意指出官方有不中立的時候，不可盲目跟從。--Factrecordor（留言） 2024年6月18日 (二) 14:03 (UTC)[回复]
  • | X = or ===X===
這個欄位只寫入X
  • | Y = or ===Y===
這個欄位只寫入Y
  • | Z = or ===Z===
這個欄位只寫入Z
  • 因為<ref A>將X、Y、Z混合陳列而在第一項、第二項、第三項出現X、Y、Z任2至3項數值混合排序的狀況都是異常的
  • 針對其他部分不表述。分類=分類沒有疑義，排序=排序沒有疑義。分類=排序的議題即使改陳述成排序=分類也同樣不可能存在
--Rastinition（留言） 2024年6月18日 (二) 14:27 (UTC)[回复]
从列明来源，非原创研究，中立观点等角度，按官方名单没错，也撇开不必要的责任。
纠偏纠错要有其他可靠的非数据来源，加入正文或注释。依赖数据会催生奇怪结论，如角色A的出场时间更多所以该放在B的前面。--YFdyh000（留言） 2024年6月18日 (二) 14:41 (UTC)[回复]
接在YFdyh000後方的原因是我懶得編輯原始碼。但仍大略依YFdyh000提及的文字作為開頭敘述，以我看過的現象，比較少出現角色A的出場時間更多所以該放在B的前面。的情形。
  • 較常看到的狀況是資訊框的 |主演= 使用來源後，沒有完整列出主演，卻依照來源排序將"非主演"列在主演中
  • 首段較常見的狀況是將|主演=的欄位資訊重新複製貼上再增加一些敘述，因為有敘述所以通常也會將來源中的分類用散文形式補上
  • 演員名單或演員表的情形較常見的狀況是將|主演=的欄位資訊重新複製貼上後重製成表格，預留一個關係的欄位插入異常複雜的誰是誰'的誰"資訊
  • 通常經過上面的過程，單一個條目可以連續看到近乎完整的三次演員名單，用3種不同表現方式呈現。  吐槽演員名單連續列明三次，這或許可以稱為演員名單炸彈。
  • 第一項通常包含列出的資訊不準確問題(包含不是主演的對象)。第二項因為首段必定散文化，是最沒有問題的。第三項問題很複雜，這牽涉到是否針對演員的性質/角色/劇情分類，因為涉及分類就必定不可能完全按照官方排序陳列。僅有一個情形例外，僅在將性質也列入排列對象時成立。但如果官方名單排序並未經過分類的打散排序時，例外也不存在。
  總結為了排序這個目標而排序又希望排序完整，比較可行的位置是首段。但為了可行而刻意每個頁面都生成3組演員名單，是否有這個必要也需要考慮。(～)補充我提出的質疑是為了排序而排序，不太可能寫出像en:House_(TV_series)(劇情分類式寫法)這種品質的頁面，從目標或構成結構的角度都不一致--Rastinition（留言） 2024年6月18日 (二) 15:41 (UTC)[回复]
維基百科對演員的排名不等同對主配的認定。依據官方名單比較省力便捷，依據實情或多方來源則衆説紛紜、莫衷一是、費時費力。如有多份官方名單排名不同，可以第一產地的海報為準。不過，若對單一作品達成強共識，或許可豁免官方名單的規限。此外，戲份居次亦有可能是最爲重要的靈魂人物。--— Gohan 2024年6月19日 (三) 03:01 (UTC)[回复]
我覺得大部分情況下依從官方是可以，但總有些不尋常的情況，「單一作品達成強共識，或特許豁免官方名單的規限」大概就是這個原則。--Factrecordor（留言） 2024年6月19日 (三) 08:05 (UTC)[回复]
個人認為這個議題是沒有討論空間，因為已成文指引Wikipedia:格式手冊/電視#演員及角色資料已解答閣下的疑惑。--唔好阻住我愛國（留言） 2024年6月20日 (四) 11:18 (UTC)[回复]
請問閣下是不是希望修改此部分條文？如是，請移動此討論至方針區。--唔好阻住我愛國（留言） 2024年6月20日 (四) 11:21 (UTC)[回复]
好的，我不熟悉移動模板，有足夠精神時再處理。--Factrecordor（留言） 2024年6月25日 (二) 15:58 (UTC)[回复]
@Rastinition君的意見更為複雜，我先提案有條件豁免遵從官方序列的規限。--Factrecordor（留言） 2024年6月28日 (五) 16:06 (UTC)[回复]
@Factrecordor你在你的留言下方回覆後提到我的意見，如果你是希望我回覆你或者困惑為什麼我沒理你，那是因為你提出提案提出的議題/問題情境在對象頁面不存在，更精確的說法，巨塔之后這個頁面的問題我在更早前的留言已經盡量簡短敘述，如果沒理解實際問題或認為是離題或複雜到不能理解，@Factrecordor不用勉強自己理解，而且這與你的提案本身無關。(提案根據不存在的議題，實際發生的狀況和提案無關，針對狀況的發言與提案本身會離題是自然現象)。Fake性質議題。如果看前後條文，也能發現只是新增一段廢話。上述廢話是相對禮貌性說法，較不客氣的說法，這是扭曲@神秘悟饭原意後將他的發言轉換成新的條文--Rastinition（留言） 2024年6月28日 (五) 23:18 (UTC)[回复]

正式提案

現行條文

演員與角色訊息（含信息框中的主演欄）一般可以正式官方網站公開發布訊息收錄，若編者因對於作品之可靠官方來源選擇或判定不一，或因其他理由，導致對於演員排序認定歧異，則依序以下列來源為依據：

  1. 影片中完整的演職員表（如片尾演職員表或片中的跑馬字幕），若影片是依出場順序排序則不適用。
  2. 影片片頭的演職員排序，若影片是依出場順序排序則不適用。
  3. 官方海報的演員名單排序。
  4. 官方網站的演員或人物介紹排序。
  5. 其他官方發行產品上的演員名單（如相關刊物、影音產品包裝等其他多媒體）。
提議條文

演員與角色訊息（含信息框中的主演欄）一般可以正式官方網站公開發布訊息收錄，若編者因對於作品之可靠官方來源選擇或判定不一，或因其他理由，導致對於演員排序認定歧異，則依序以下列來源為依據：

  1. 影片中完整的演職員表（如片尾演職員表或片中的跑馬字幕），若影片是依出場順序排序則不適用。
  2. 影片片頭的演職員排序，若影片是依出場順序排序則不適用。
  3. 官方海報的演員名單排序。
  4. 官方網站的演員或人物介紹排序。
  5. 其他官方發行產品上的演員名單（如相關刊物、影音產品包裝等其他多媒體）。
  6. 若有編者對單一作品的官方序列提出合理質疑，可發起討論。此討論應參考更多官方以外可靠來源的演員序列，及對個別角色的戲份、演出性質之描述。若達成強共識，可豁免遵從官方序列的規限。

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

可能要重點說明相關演藝人員的名氣是不影響演員序列。舉例以「香港頂流」炎氏作例，倘若他在節目只有一句話，不應因為名氣而把他置頂。--唔好阻住我愛國（留言） 2024年6月28日 (五) 16:36 (UTC)[回复]
(－)反对增列的內文基本是根據其他帳號發言，加入了原發言者未提及的文字
  • 句子應該精簡後改成若對單一作品的官方名單有合理質疑，可發起討論。討論應參考更多WP:可靠來源。若達成共識，可不受前列條文限制。這個文字避免了對原發言的過度解釋，文字也概要的提及WP:共識精神。已經符合WP:可靠來源的項目，不應該再有篩選/排除的狀況(這是針對更多官方以外文字)，重要的是WP:可供查證精神(WP:ABOUTSELF第5項，WP:斷言、WP:REFNOTTRUE)
  • (～)補充這個議題大致上屬於WP:ABOUTSELF第4項的討論範疇
--Rastinition（留言） 2024年6月28日 (五) 23:55 (UTC)[回复]
同Rastinition。某些“官方”来源可能对排名作出详细解释，不应排除。--YFdyh000（留言） 2024年6月29日 (六) 02:30 (UTC)[回复]
@Rastinition@YFdyh000，但我仍希望在「討論應參考更多WP:可靠來源」之後，具體強調要注重該些來源的「演員序列，及對個別角色的戲份、演出性質之描述」，亦同意HK5201314君的意見，即強調「避免演員序列被演員的名氣所影響」。兩位覺得如何？--Factrecordor（留言） 2024年6月29日 (六) 14:42 (UTC)[回复]
避免名气影响，我觉得是避免沦为宣传工具，但这可能不是中立的观点、非原创研究所推荐。因为以其他特定标准来呈现和调整，可能不满足这两项，也较难得出公认的一致的合理标准，也许还不如给原列表加脚注。--YFdyh000（留言） 2024年6月29日 (六) 16:58 (UTC)[回复]
那麼@HK5201314君有沒有進一步回應？--Factrecordor（留言） 2024年7月1日 (一) 10:51 (UTC)[回复]
不知道為什麼，我想用TVB愛回家作例，話說當年楊明剛剛被TVB解凍，他獲解凍後出埸的第一集，對白有超過10句，但TVB的操作是把他放在演員序列中最後一個。
什至，中國大陸常常封殺「不道德演員」，做法是打碼／打格仔，並刪除該演員資料。
如按照現行做法，是完全不尊重「不道德演員」及「剛解凍演員」，並違反中立原則，因為現行做法完全偏向製片商。--唔好阻住我愛國（留言） 2024年7月1日 (一) 11:30 (UTC)[回复]
所以建議新增如有任何爭議，可按可靠來源介紹量／文章多寡決定演員序列。--唔好阻住我愛國（留言） 2024年7月1日 (一) 11:32 (UTC)[回复]
按文章量不可行，计算结果是原创总结（哪些来源算，如何去重，数量平手，情况改变），也同样容易操纵（争议人物排第一）。--YFdyh000（留言） 2024年7月1日 (一) 15:19 (UTC)[回复]
如果是「角色介紹量」呢？我不信只有一句對白的角色就有一整篇文章介紹該角色特性。--唔好阻住我愛國（留言） 2024年7月2日 (二) 12:14 (UTC)[回复]
润笔费给足，吹嘘解读不用愁。如果是重要角色或明星，但播出版本全剪掉了，又怎么办。别自定标准了，见下。--YFdyh000（留言） 2024年7月6日 (六) 13:59 (UTC)[回复]
我相信閣下有能力判斷何謂「可靠來源」。--唔好阻住我愛國（留言） 2024年7月6日 (六) 15:50 (UTC)[回复]
写成看不出来不难，包括以量取胜。--YFdyh000（留言） 2024年7月7日 (日) 02:57 (UTC)[回复]
當初會建立指引，就是為了防止每個用戶依據自己所認定的來進行排序，進而引發編輯戰。同時，還必須考慮到歐美劇常有主演退出的情況。另外，有些戲之所以會將看似客串的演員列為主演，可能是認定其角色在某個階段吃重，比如《黑道律師文森佐》的劉宰明，前三集是主演，但角色死亡後，第四集變成客串，可是不會因此推翻他在前三集是主演的事實。又，報獎策略出現的主配問題，例如《一把青》的排序是天心、楊謹華，但獎項競賽卻是楊謹華報名女主角、天心報名女配角，列入這些情況太過繁雜。
所以最好的方法，就是撇開個人模糊的「實情」認定，不論是劇情編排轉變，還是宣傳手段與否，盡量依據官方或可靠來源為準，主演寫誰就是誰、客串是誰就是誰，這樣可以避免自行量化、計算，而導致涉及原創研究的問題。其餘的，可以用可靠來源來補足，例如陳豪雖然被列為主演，但其偏向客串性質云云、演員被刪除的原因等等。--Sa Young Sun（留言） 2024年7月5日 (五) 19:41 (UTC)[回复]
@Sa Young Sun，閣下可能誤會了，情況不是陳豪被列為主演，反而有很多來源提到他是客串，包括電視台自己的官方報道，只是劇集官方網頁的演員排序把它排在第一[9]，而官方網頁那個排序的字眼是「演員」，不是「主演」。換言之，官方沒有否定陳豪是客串此一事實，但他們就是喜歡把這個客串但最大卡士放在第一，而官方這種做法有違中立，恐怕有其商業或其他利益考慮，維基應否依從其利益考慮？我在上面強調的正是維基向來都警剔官方（一手來源）的不中立，所以不應在此條文認定官方不容質疑，我只是希望加入質疑官方的機制，且需要強共識才可不遵從官方。像《黑道律師文森佐》的劉宰明，按你指出的理據，就算討論都沒法形成強共識。--Factrecordor（留言） 2024年7月17日 (三) 15:09 (UTC)[回复]
不管有無商業、利益考量，在排序上應不會造成中立問題，我認為「警惕」應在於劇集本身的評價等，而不是在排序上爭論。個人觀點，排序就像人物設定，是官方本身所設定或決定。比如《新宿傷痕戀歌》的女主角是加藤愛，但她的存在感卻比中島美嘉低；又比如我先前舉的《伊甸園之東 (電視劇)》，女主角李多海不僅第6集才登場、角色定位不明，最後還辭演。若以閣下的邏輯，這些主演可能會因為編輯者自認的實情，而將其排除，包括我前面舉例的劉宰明，那顯然又跟官方釋出的資訊（可靠來源）不符，便難以斷定何謂「實情」。
而且排除二手來源的原因，是因為二手來源並不一定知道官方、劇組內部的設定，又或是只報導較為人熟知的演員（人氣），例如《八尺門的辯護人》，報導只寫李銘順主演，但實際片頭片尾的主演名單並不只有他一人，由此可證二手來源的正確性大多不如一手來源（僅指戲劇設定範疇）。
我言下之意並不是「官方不容質疑」，而是依循官方的排序，可以避免編輯者原創研究、自行認定。在有可靠來源的情況下，都會引發編輯戰了，沒有可靠來源的強共識更難以形成保障。而我前述也提及，排序若產生爭議「可以用可靠來源來補足」。另外，我覺得別被「主演」所限制，很多戲也都沒有標明「主演」，或甚至是群戲，那就依照演員名單填入即可，其他思慮只是徒增原創研究的可能。
總而言之，我所要強調的是，現行的方針是已經盡量考量所有的可能性，閣下新增的條文可能會因此推翻原先的條文，而回到原本沒有增設方針時的情況，那您必須再設法把編輯戰、原創研究的避免方式考量進去。--Sa Young Sun（留言） 2024年7月17日 (三) 16:41 (UTC)[回复]
現實的影視作品中片尾的演員排列表為了避免演員爭大爭小的問題，出現了按年資序、筆劃序、拼音序、出現序的各種做法。日本甚至形成了自己獨特的排列方式，一些佔相當大戲分的演員反而是在最後的。所以引進外國的時候，引進方經常是會隨意調查番位的。您維非得將爭大爭小的問題變成編者自己爭論的問題，這顯然是不合維基百科的非原創研究精神的。--Ghren🐦🕛 2024年7月12日 (五) 16:43 (UTC)[回复]
日本應該是跟美國類似。美國會把比較大牌、資深（但可能戲份不及主角）的演員，用with、and排到最後，例如《嘻哈帝國》、《小謊言 (電視劇)》（[10]）、《柏青哥 (電視劇)》（[11]）等，韓國現在也會用「그리고」把演員排到後面。日本的話，還包含他們對「主演」的定義稍稍嚴格，所以有些戲份多的，才會排到最後。所以，建議依照官方排序，省得去解析with、and這些情況。--Sa Young Sun（留言） 2024年7月14日 (日) 15:18 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:頁面存廢討論/疑似侵權。

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

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

提议新模板设计

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


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

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

提议修订提报侵权流程

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

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

技术问题

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

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

其他

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

我只是來發泄一下。話說《黃飛鴻傳》是我初在維基最早期建立電影條目，當時受友人所託對百部不可不看的香港電影進行遺補。但當時我不熟悉方針，還傻傻的擔心劇情簡介「原創」不好，所以按照來源──香港電影資料館出版的實體書籍《香港影片大全》系列逐字逐句打出來，哪知影片大全系列的很多內容早被電子化至康文署的網上資料庫，又被各網站複製，條目被指為侵犯那些網站的版權，需要整個重建。然而，整個條目中，只有劇情簡介是一字一句完全與來源一樣，其他內容包括人物簡介，均是自己消化後創作出來。後來，我發現一些電視劇的劇情介紹常被放入複製自作品官方的文字，處理方法有的是掛上一個章節可能侵權的模板（連內容也沒刪），有的是刪除該章節內容。換言之，出現一個疑問，為什麼我當初的條目沒被這樣處理？自此，我對侵權處理印象極差。順帶一提，後來我曾在討論指出，正如我當時想法，其實有些人無意侵犯什麼，也不是懶，只是覺得依從作品官方或具權威性的出版物之介紹，比自己原創更好。當然，如果照搬的文字不是來自官方，是其他有版權的作品，像我當初那樣抄《香港影片大全》，侵權問題確需注意，但是如果照搬的是作品官方公開宣傳用的文字介紹，你願意免費替官方把他們的介紹宣揚開去，他們可能還會多謝你，試問天下間除了維基人，誰會擔心作品官方會控告這樣的所謂侵權。官方介紹的問題反而是宣傳性過高，有時不中立，甚至有時與真實劇情相違。--Factrecordor（留言） 2024年6月29日 (六) 14:13 (UTC)[回复]
“他们可能还会多谢你”是说不好的，维基百科的协议允许商业化和修改衍生，需要为版权状态做更多努力，避免后患。剧情介绍的编写着实麻烦。--YFdyh000（留言） 2024年6月29日 (六) 17:02 (UTC)[回复]

重新公示

雖然上次公示時有意見提到應“将段落侵权的新代码另外新建模板”，但由於沒有人提出任何有關方案，我認為現階段以原案重新推進比較適合，因此依據WP:7DAYS的規定（其實已經隔了8日）重新公示原案7日。Sanmosa 蚌埠 2024年7月21日 (日) 09:32 (UTC)[回复]

所以技術上是打算怎樣處理？--SCP-0000（留言） 2024年7月21日 (日) 10:58 (UTC)[回复]
@SCP-2000：Shwangtianyuan在上方有提議一個Uw-copyright模板的更新版本，我計劃直接以之替換既有版本（也就是條目侵權與段落侵權都是用同一個模板），此外提報侵權流程也會按Shwangtianyuan上方的提議修改。Sanmosa 蚌埠 2024年7月23日 (二) 11:20 (UTC)[回复]

提議將通用評級指引併入頁面評級

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:页面评级。

由於前者亦屬頁面評級，可以併入後者為部分有效之章節，毋須置獨立頁面。此提議不涉及指引實際內容變更。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 01:57 (UTC)[回复]

不反對合併。不過能否詢問下您會怎麽設計合併之後页面评级的章文結構，如果可以的話能否參考下Temp君的意見。--人间百态,独尊变态(讨论) 2024年6月23日 (日) 08:37 (UTC)[回复]
我應該會在最後面開一章「通用評級」，併入相關內容。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月21日 (日) 08:42 (UTC)[回复]
@Temp3600：不知有何意見？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 04:20 (UTC)[回复]
合併比較好。不過也要注意通用評級指引指引本身還有其他需要修改的地方，所以上一次討論時就沒有提出合併的單獨請求。--Temp3600（留言） 2024年7月2日 (二) 14:47 (UTC)[回复]
好，之後準備公示（抱歉最近比較沒空）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月12日 (五) 16:35 (UTC)[回复]
應該可以合併--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 14:52 (UTC)[回复]
  公示七日，至2024年7月28日 (日) 08:42 (UTC)結束。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月21日 (日) 08:42 (UTC)[回复]
(＋)支持，我建议把整个Wikipedia:条目重要度评级标准也并进去。L'Internationale, Sera le genre humain! ✏️ 2024年7月21日 (日) 13:52 (UTC)[回复]
(＊)提醒：For Each element In group ... Next君在编写Draft:页面评级草案，如对内容有其他需求且不着急，可考虑等草案的完全版本再来商议。否则现阶段版本的合并也是问题。--PexEric💬|📝 2024年7月22日 (一) 14:13 (UTC)[回复]
先合併，等他寫好了直接整頁更新（我預期舊版本也沒有保留必要），未見扞格之處。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月22日 (一) 14:46 (UTC)[回复]

提議清楚定義何謂「正當合理的回應」

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:共识。

根據WP:共識的公示條文：

另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何使用者重複提出，可提示該使用者相關意見已獲解決，除此以外無須另作回應。

假設提問者在提案討論提出一個具建設性的問題給提案人，而提案人為了希望該提案盡快獲得通過，以解決當前指引的漏洞，故提案人選擇坐在電腦前，當提問者提出意見後，提案人秒回提問者的意見。3天後，提問者並無進一步回應。

根據上述條文，應視為該意見已解決且不需再回覆。

可是，在7天後（即回答問題後10日），也是公示期結束前一天，提問者認為提案者的回應不正當合理，於是強行終止公示。

個人認為這是一個拉布的行為，嚴重影響共識形成。

1.首先，何謂「正當合理的回應」？誰有權在3日限時以外可以judge這個回應？

2.其次，理論上，共識應解決所有合理的問題，唯提問者在提案者回答後3日不回應相關答案，算不算已解決相關問題。

3.如果這裡有4名編輯者參與討論，當提案者回答提問者（這裏已有2人）問題後，其餘2位編輯者也發表與提案者類近回答及補充。4日後，提問者可不可以認為提案者的回應不正當合理而當提案者的回應不算數？

以上！（希望在條文中清楚定義何謂「正當合理的回應」，可以是其他編輯者投票或第三方管理員進行判定，以避免因此而造成拉布的理由。）--唔好阻住我愛國（留言） 2024年6月25日 (二) 11:20 (UTC)[回复]

不要墨守成规，以讨论而非流程时限去判定。
是否已解决，提问者最有发言权，视为已解决是一种假定（类似自动评价），当事人始终有权在公示前后再度表态，不能以流程堵嘴说来晚了、已视为已解决，且“共识可以改变”。
问答是否正当，参与讨论者均可表态与附议，不清晰可以直接问。
恶意拉锯请考虑游戏维基规则的警告、举报，可附注之前回应或者更广泛的意见。但执意推进不成熟的提案同理。--YFdyh000（留言） 2024年6月25日 (二) 14:24 (UTC)[回复]
「提問者最有發言權」，難道我可以在問題被回答後十個月後提出該回答是否合理？--唔好阻住我愛國（留言） 2024年6月26日 (三) 12:01 (UTC)[回复]
视作新问题？是否打破之前共识，倾向按常识个案讨论处理。视作已解决不代表失去未来资格，可能要看是否应当解决。--YFdyh000（留言） 2024年6月26日 (三) 16:14 (UTC)[回复]
顯然是祇能個案判斷。雖然本人一向認為近來若干討論有擴大解釋的不良傾向。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 04:16 (UTC)[回复]
離題的當然就不可能是正當合理意見。若有違基本邏輯，能被指出邏輯漏洞甚至是邏輯謬誤的意見，客觀及字面意思上不符合「正當合理」，因存在邏輯謬誤的論點本來就是客觀認定的「invalid arguments」（某大學資源、人文作家、GPT輔助解釋、另一大學資源）。若並無明顯違反邏輯或存在邏輯謬誤，則以是否與其他方針指引牴觸為考量因素，確實與其他方針指引相違背的不可能視作有效意見考量。另外，共識方針也指明過往已獲回應，而並未提出新觀點，僅僅重複過往觀點的留言不需重複回應。其餘絕大多數情況都是正當合理的意見。--路西法人 2024年6月26日 (三) 08:01 (UTC)[回复]
「共識方針也指明過往已獲回應，而並未提出新觀點，僅僅重複過往觀點的留言不需重複回應。」：
甲人：我認為論點A是十分重要 —> 1日後—> 乙人：基於論點A，這是見解B ；丙、丁、戍人：見解B所言正解—> 3日後 —> 開始公示 —>6日後—> 甲人：我認為你沒有回答問題，見解B的論點完全不合理，所以我還是認為論點A是十分重要，於是強行終止公示。
——
換算是閣下的共識議案，我套用這個邏輯找閣下提案的不足，閣下肯定會覺得非常不滿。--唔好阻住我愛國（留言） 2024年6月26日 (三) 11:49 (UTC)[回复]
因為這個邏輯，本人的提案已被拉鋸足足2個月（討論及完善條文僅使用1個月），而對手是管理員，根本無從入手解決問題。--唔好阻住我愛國（留言） 2024年6月26日 (三) 11:57 (UTC)[回复]
單單說「沒有回答問題」而沒有論證則同樣為無效，除非能夠論證如何沒有回應問題，否則都不能說對方的回應不合理。--路西法人 2024年6月27日 (四) 06:54 (UTC)[回复]
條文沒有這樣寫…
而且隔這麽久先質疑回應的正當性會不會有問題？--唔好阻住我愛國（留言） 2024年6月27日 (四) 11:20 (UTC)[回复]
如果重複為了拖延提案而選在公示將近結束前才發表反對意見，就是遊戲共識形成過程的行為。況且，缺乏論證的觀點本來就不屬於可供參考的意見，缺乏論證或論證明顯有誤的「沒有回答問題」也同樣不會是有效的程序質疑。--路西法人 2024年6月28日 (五) 02:42 (UTC)[回复]
比較想不用頗主觀性的遊戲維基規則，如管理員參與了戰爭，一切最終決定權還是管理員。
—-
打算這樣改
另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應（如編輯者欲質疑相關回應是否正當合理，必須於問題被回應後3天內提出，並詳細說明該回應有什麼不足），且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何使用者重複提出，可提示該使用者相關意見已獲解決，除此以外無須另作回應。--唔好阻住我愛國（留言） 2024年6月28日 (五) 03:34 (UTC)[回复]
不認為有必要限制必須在三天內提出，但確實有必要規定述明有何不足。--路西法人 2024年6月28日 (五) 09:41 (UTC)[回复]
但應同時避免無限期等待或最後一刻先發表重復的意見。--唔好阻住我愛國（留言） 2024年6月28日 (五) 14:14 (UTC)[回复]
這是當然，但這樣寫就會變得相當模糊，還不如直接將其視作玩弄社群建立共識的程序處理更好。--路西法人 2024年7月3日 (三) 01:48 (UTC)[回复]

另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應（如編輯者欲質疑相關回應是否正當合理，必須於問題被回應後儘快提出，並就每一不足論點詳細說明該論點的不足之處及提出可接受的建議。），且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何使用者重複提出，可提示該使用者相關意見已獲解決，除此以外無須另作回應。

我相信管理員在調查破壞者是否玩弄社群時會參考破壞者的貢獻記錄，看看是否達到「儘快」要求。--唔好阻住我愛國（留言） 2024年7月3日 (三) 15:14 (UTC)[回复]
@Ericliu1912@Factrecordor@LuciferianThomas@YFdyh000:三日後無反對意見的話就開始公示這個版本。--唔好阻住我愛國（留言） 2024年7月12日 (五) 11:05 (UTC)[回复]
您不能只要求「質疑者」詳細說明該論點的不足，還要提出可接受的建議這樣子。「提案者」和「質疑者」兩者的責任並不相稱。而且「可接受的建議」也太主觀，也不合適。質疑者沒有必要教提案人如何寫好方針好嗎。--Ghren🐦🕛 2024年7月12日 (五) 16:52 (UTC)[回复]
遊戲維基社群也屬於主觀規條。
正如路西法人道「 缺乏論證的觀點本來就不屬於可供參考的意見」，不能單單一句「我不同意這個回覆」而影響整個討論。--唔好阻住我愛國（留言） 2024年7月13日 (六) 01:18 (UTC)[回复]
請問Ghren在說天秤兩邊重量不成比例，導致共筆版本傾斜於提案方的問題嗎？即使想釐清正當合理的狀況，但要其他人質疑來決定正當合理與否，此舉潛在默認了沒有受到質疑的回應。 -- 月都 ※ 2024年7月14日 (日) 16:10 (UTC)[回复]
  • 上方兩名用戶都將「質疑者」定性為「反對提案的人」，但這個條文寫的是「編輯者」，同樣可以套用於「正方質疑反方提出的回應」，正方的質疑同樣需要詳細論證論點的不足。
  • 「可接受的建議」確實過於主觀。
  • 上方用戶指出質疑者沒有必要教提案人如何寫好方針好嗎，同樣可以還一句「提案人沒必要教反方如何提出真正有力的論述」。現在很多時候是反方恃着自己是反方，然後不論自己意見是否合理，就硬打說提案有反對意見不應通過；演變成「反方說自己的反對意見有效就行，不論正方怎樣有力的反駁、反方自己的意見如何無力，反方的反對意見依然自稱有效」，和「反方不同意自己意見被認定非正當合理或已被回應，但同時卻在認定正方的回應並非正當合理，令自己的意見維持有效」。現在的釐清顯然是將天秤從偏向反對方拉回中間而已。
--路西法人 2024年7月17日 (三) 04:47 (UTC)[回复]
「可接受的建議」—>「改善建議」
這個可以嗎？--唔好阻住我愛國（留言） 2024年7月17日 (三) 10:20 (UTC)[回复]
不太行。指出對方說法有問題後並無原因要協助修正對方的說法。指出對方錯誤後推翻其提案/意見難以構成「改善建議」，但確實仍能合理推翻對方意見。--路西法人 2024年7月18日 (四) 08:32 (UTC)[回复]
「，並就每一不足論點詳細說明該論點的不足之處及提出可接受的建議。」—>「，並就每一不足論點詳細說明該論點的不足之處。」--唔好阻住我愛國（留言） 2024年7月18日 (四) 10:34 (UTC)[回复]
Version 2:

另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應（如編輯者欲質疑相關回應是否正當合理，必須於問題被回應後儘快提出，並就每一不足論點詳細說明該論點的不足之處。），且自該回應起計的3日後無進一步再回應，應視為該意見已解決。已獲解決的意見若被任何使用者重複提出，可提示該使用者相關意見已獲解決，除此以外無須另作回應。

--唔好阻住我愛國（留言） 2024年7月20日 (六) 06:41 (UTC)[回复]
不行，不一定要詳細才能指出對方不足，有時簡短的兩三句話就已經足夠說明不足之處。相對的，詳細也不一定可以說明不足之處，如果論點本身有錯，再詳細也沒有用。--素菓霖 2024年7月23日 (二) 05:42 (UTC)[回复]
同。說一百句但言之無物也沒用，指出對方說法邏輯謬誤三五句也可以足以駁回對方論點。--路西法人 2024年7月23日 (二) 09:15 (UTC)[回复]
「詳細」：沒有列明字數，但不相信一句就能反駁，你們的對我的反駁也至少兩句啦。--唔好阻住我愛國（留言） 2024年7月23日 (二) 15:06 (UTC)[回复]
這是模糊與否的問題（--路西法人 2024年7月24日 (三) 02:36 (UTC)[回复]
但如果是玩規程問題或模糊表達，當然與「詳細說明」有很大落差。--唔好阻住我愛國（留言） 2024年7月25日 (四) 13:52 (UTC)[回复]
我們在編輯某些條目，察覺一些方針需要制訂或修改，卻不一定常涉足所有受該方針影響的範疇，先反思影響範圍，再看看哪些用戶經常活躍於箇中話題，邀請討論，所有潛在疑問可能在兩三星期內就能被大家想出來了，可以集中解決。若不這樣做，往往有個人偶爾路過，又放下一個疑問，自然無休無止。就算你曾經順利通過提案，也只是你的一時幸運，而你的幸運不一定是維基之福。--Factrecordor（留言） 2024年6月26日 (三) 13:01 (UTC)[回复]
「偶爾路過，又放下一個疑問」，這個絕對支持，唯該路人是不是應該負起責任，主動跟進自己問過的疑問，如有需要，應儘他能力以最快時間進行追問，避免社群其他成員無限的等待，這對提案者絕對是一個折磨。--唔好阻住我愛國（留言） 2024年6月26日 (三) 13:13 (UTC)[回复]

原文重定向的可靠来源

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:重定向。

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

起因可见：WP:頁面存廢討論/記錄/2024/07/09#批量提刪--——自由雨日（留言・贡献） 2024年7月9日 (二) 14:00 (UTC)[回复]
技术上可能，编辑摘要或HTML注释，重定向语法后面印象中也可行。不曾注意到该方针的存在，我怀疑这是否“反映社群共识”。Special:Diff/55642771，提案可能未获充分讨论。--YFdyh000（留言） 2024年7月9日 (二) 14:41 (UTC)[回复]
但實務上較困難吧？我也不覺得有人會特別注意重新導向有無來源，最好是能直接附在重新導向目標頁面中為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月10日 (三) 12:20 (UTC)[回复]
@微肿头龙、自由雨日、YFdyh000、Ericliu1912：如果大家不反對的話，我建議把“创建者应在重定向页面加入证明外文名称的可靠来源”改為“创建者应在條目本身或重定向页面的討論頁加入证明外文名称的可靠来源”。Sanmosa 蚌埠 2024年7月13日 (六) 01:37 (UTC)[回复]
(＋)傾向支持，甚至“在讨论页”就是我一开始（错误）理解的（见WP:页面存废讨论/记录/2024/07/09#批量提删）。不过如果只是在编辑摘要中加入也未尝不可，至少只要某编者在建立时提供了来源，就不能说他是“未遵守方针滥建外文重定向”。--——自由雨日（留言・贡献） 2024年7月13日 (六) 01:47 (UTC)[回复]
放在編輯摘要並非不可，但遇上失效連結的時候不好處理，放在討論頁至少還能存檔來源。Sanmosa 蚌埠 2024年7月13日 (六) 01:49 (UTC)[回复]
(＋)支持，不过我不觉得会有多少人加来源。--微肿头龙（留言） 2024年7月13日 (六) 04:37 (UTC)[回复]
建議改為「條目本身或重新導向頁面的討論頁」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月13日 (六) 18:12 (UTC)[回复]
不反對，已調整。Sanmosa 蚌埠 2024年7月14日 (日) 22:34 (UTC)[回复]
公示修訂提議7日。Sanmosa 蚌埠 2024年7月21日 (日) 07:39 (UTC)[回复]

有關公布管理人員任免案投票人數等事

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:管理员。

現行管理人員任免案，均採行安全投票，且不提供投票者名單，僅投票管理員（監督員、監管員）可以查閱。鑑於安全投票制度之初衷，暨當事人安全及隱私等疑慮，不公開具體投票者尚能理解。然而，或許應考慮定期公布投票人數（情況允許者，並應先行公布有資格投票者人數），俾便社群追蹤任免案之整體動態。另不確定相關方針與指引本來是否有明文規定應提供投票者名單？一併請社群討論商榷。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月13日 (六) 12:30 (UTC)[回复]

支持公布具投票資格人數，個人建議可在開放用戶投票前15日公布具投票資格的用戶人數；至於用戶名單是否一併公布、是否有任何安全或隱私等疑慮，可視具體情況調整，或是有任何疑慮也可直接提出。--Kriz Ju（留言） 2024年7月18日 (四) 21:08 (UTC)[回复]
開放用戶投票前先行公布有資格投票者人數與名單應可行（說實話現在不都有MMS發送名單了嗎）。但「定期公布投票人數俾便社群追蹤任免案之整體動態」個人尚看不出必要性，望進一步闡明？-Peacearth（留言） 2024年7月19日 (五) 03:24 (UTC)[回复]
技术上投票前，投票权人名单必定会在phab公布，增设方针明文要求我不反对。反而我认为应该关闭隐藏已投票人名单的功能，方便社群查核，毕竟投票选项已经保密，保密已投票人名单有意义吗，别人只能知道谁投了票，又不知道投了什么。--桐生ここ★[讨论] 2024年7月19日 (五) 11:41 (UTC)[回复]
保密已投票人名單有意義，不排除有人威脅特定用戶必須或不能投票的情況，前者會使投票滿足最低票數要求，後者會使投票無法滿足最低票數要求。Sanmosa 蚌埠 2024年7月19日 (五) 12:03 (UTC)[回复]
看来还是有点意义，不过我仍然认为应该公开已投票名单，或者在投票完成之后公开已投票者名单。--桐生ここ★[讨论] 2024年7月22日 (一) 09:19 (UTC)[回复]
考慮到近期的事情，我不認為短期內我們可以這樣做。Sanmosa 蚌埠 2024年7月23日 (二) 04:47 (UTC)[回复]

重提注音格式要求

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手冊/序言章節。

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

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

提議條文

注音

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

為確保中文維基百科對常用字的定義不存在任何地域中心的問題，确定本维基的常用字范围采取如下方法：

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

编者决定是否注音时，应该考虑到两岸四地的使用实际和语言流变。在判断过程中，仅有繁簡或常用異體差別的漢字均視為同一漢字（如“羣”（香港）與“群”（中國大陸、臺灣）視為同一漢字）。

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

如果使用行内注音，推荐使用字詞转换機制在不同变体下分别展示各地區模式適用的注音模式：

  1. 就所有簡體模式而言，使用汉语拼音[3]；
  2. 就臺灣正體模式而言，使用注音符號；
  3. 就香港繁體與澳門繁體模式而言，由於香港與澳門的讀者普遍均以粤语（而非官话）學習中文書面語，因此：
    • 在有粵語同音常用字的情況下，標註該常用字或粵拼，但兩者不可在同一條目中混用；
    • 在沒有粵語同音常用字的情況下，標註粵拼。

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

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

  1. ^ 馬來西亞與新加坡在改用簡體字時直接沿襲中國大陸當時的《現代漢語通用字表》為其標準。由於《現代漢語通用字表》於2013年在中國大陸已停止使用，此處以中國大陸的現行常用字表權充馬來西亞與新加坡的常用字標準。
  2. ^ 澳門沒有自己的常用字表，因此此處以香港的常用字表權充澳門的常用字標準。
  3. ^ 馬來西亞與新加坡在改用簡體字時同步由注音符號改用漢語拼音。

现在各个方案的样子：

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

另外有台灣大陸香港以及韓國的常用漢字比較表（日文）供参考（感谢118.170.4.163）

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

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

维基百科不应该是词典，不应该承载字音教育的需要。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月15日 (一) 00:50 (UTC)[回复]
粵拼难道不是粤语维基百科的事情么？--百無一用是書生 (☎) 2024年7月15日 (一) 02:22 (UTC)[回复]
加粤拼就说应该是粤维的事，不加又说会怠慢。然后新马是不是真的跟随汉语拼音作为教学方案？所以依序的话，最好是不标，次至内链到维基词典，再次至为脚注。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月15日 (一) 03:12 (UTC)[回复]
像现在普通话（国语）与粤语混着用的情况，未来要作无障碍怎么办？--Kethyga（留言） 2024年7月16日 (二) 14:47 (UTC)[回复]
@落花有意12138：法語維基辭典有個叫{{cmn-pron}}的模板，輸入漢語拼音可以自動生成法國遠東學院拼音、威妥瑪拼音、耶魯拼音和注音字母（但其他方向就不行）。在下認為：如果有需要的話，可以把這個模板搬運過來，這樣就能像Kinder出奇蛋那樣，一次過滿足四個願望。📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年7月15日 (一) 04:13 (UTC)[回复]
上一輪討論中，提到了方針维基百科不是词典的問題。個人觀點是支持LuciferianThomas的「連結至維基詞典方案」。個人反對在條目內大量標註配音的方案，即當前方案。--Nostalgiacn（留言） 2024年7月15日 (一) 05:41 (UTC)[回复]
想了想還是說下，閣下給的例子可能會有點小小瑕疵。首先是Wikipedia:格式手冊/序言章節#生物中，學名應該置前放置就是了，所以應該是

福氏长爪鹡鸰（學名：Macronyx fuelleborni，台湾作富勒氏長爪鶺鴒，「鶺」，拼音：jí，注音：ㄐㄧˊ，粵拼：zik3、「鴒」，拼音：líng，注音：ㄌㄧㄥˊ，粵拼：ling4）是...(下略)

然後另外件小事，這長爪鶺鴒實際上還有更上層的分級：是鶺鴒科長爪鶺鴒屬，但讀者實際操作上也不太可能一路從上層分類點進下層頁面去吧...？以及若其最上層是亞目、亞科等預設不顯示（除非有特地呼叫display parent）的次要分類單元的話那要怎麼辦？覺得不要把常用字限太死。--WiTo🐤💬 2024年7月15日 (一) 08:43 (UTC)[回复]
(？)疑問：那麼請問如何定義「沒有在以下三個常用字表中均出現的漢字」（該漢字僅在這三個常用字表之中的一或二個出現，或均沒有出現）是否常用？-游蛇脫殼/克勞棣 2024年7月15日 (一) 09:32 (UTC)[回复]
上次討論時我已提出類似方案四的東西，不過有一點我必須提出：如果是整個詞組就請整個詞組連結（wikt:鶺鴒），不要逐個字連結。（即：{{wikt sup|鶺鴒}} ）--路西法人 2024年7月17日 (三) 04:02 (UTC)[回复]
看到這個建議才想到，如果用了{{地區用詞}}作為首句的話，該模板會根據顯示語體顯示不同順序，但這樣寫成
福氏长爪鹡鸰 （學名：Macronyx fuelleborni，台湾作富勒氏長爪鶺鴒 ）是...會不會稍嫌累贅？
而福氏长爪鹡鸰 （學名：Macronyx fuelleborni，台湾作富勒氏長爪鶺鴒）是...像這樣只挑一邊寫也不太好吧，會需要有人協助修改把標音放在最前面。--WiTo🐤💬 2024年7月17日 (三) 05:01 (UTC)[回复]
加個參數吧。--路西法人 2024年7月17日 (三) 05:36 (UTC)[回复]
另一可行方案是僅標於{{各地中文名}}之中。--路西法人 2024年7月17日 (三) 05:39 (UTC)[回复]
{{各地中文名}}的用法有些不同，這是拿來顯示地區詞差異的，不是拿來表示讀音的。Sanmosa 蚌埠 2024年7月17日 (三) 14:02 (UTC)[回复]
傾向於方案3（{{zy}}）與4A（{{wikt sup}}，包裹整個詞語），但個人認為在有{{Infobox Chinese}}的情況下可以不用在引言特別標註注音模式。Sanmosa 蚌埠 2024年7月17日 (三) 14:02 (UTC)[回复]
@落花有意12138：你介不介意讓這討論串改走RFC機制？現在VPP頁面的長度實在驚人，要load進去要花比較長的時間。Sanmosa 蚌埠 2024年7月17日 (三) 14:16 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:中立的观点。

現行條文

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

提議條文

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

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

英文維基百科早於2010年10月淘汰有關條文。與其小修小補，中維應全面重新檢討是否應跟隨英文維基百科更新《中立的觀點》方針條文。--路西法人 2024年7月17日 (三) 04:14 (UTC)[回复]
如果考虑修葺中立的方针和命名常规的问题的话，参考这些：Wikipedia_talk:命名常规/存档17#关于WP:命名常规与WP:POV的冲突、User:Cwek/工作室/关于条目常规的一些备存。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月17日 (三) 05:37 (UTC)[回复]
支持此修訂。另外，由於本站原創命名問題特別嚴重，且漢語命名格式本較英語多樣，更易孳生爭議，故現階段不建議取消條文。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月17日 (三) 08:21 (UTC)[回复]
首先何謂「標新立異」已經極度模糊，更易產生爭議。--路西法人 2024年7月18日 (四) 08:22 (UTC)[回复]
很明顯指脫離命名常規等一般命名規則的標題。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月18日 (四) 15:34 (UTC)[回复]
這裏我倒是認同LuciferianThomas的説法（這也是我下面說“短期內”的原因），畢竟隨著社會觀念的轉變，一些以前被認為是「標新立異」的東西在現在已經不被認為是「標新立異」，那可想而知一些現在被認為是「標新立異」的東西在未來也有可能會不被認為是「標新立異」，或許社羣對命名常規等一般命名規則的理解在未來也會有一定程度上的轉變。Sanmosa 蚌埠 2024年7月18日 (四) 15:39 (UTC)[回复]
此處僅為概括規範，主要是得為社群發起相關討論提供法源，其實踐自然是由社群個案探討。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月22日 (一) 14:45 (UTC)[回复]
我的理解是原创或者仅少数来源使用的罕用命名。“在未来”常见就留到未来再改，不然有维基百科影响传媒的问题。--YFdyh000（留言） 2024年7月18日 (四) 16:24 (UTC)[回复]
如果我的理解，应该就是类似的具有争议事务中，为了达到所谓某些人的主观中立，而排除一些该事物已有（并且有可靠来源彰显的）的直接专有名称（排除一些来自其他语源的来源并翻译后的中文名称），而在本项目另行创造的名称，作为条目命名。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月19日 (五) 01:30 (UTC)[回复]
所謂「為達致中立而自行創造名稱」反而是英文維基百科容許的標題取法，非「奇」非「異」，更是當前中維條文對應的英維條文在2010年被汰除後容許的行為，而「常用但不中立」的標題則只是「可以」（may）而不是「必須使用」。光從這一點已經展現「標奇立異」的說法存在極大模糊和操作空間，應從方針中移除此等模糊不清的描述。--路西法人 2024年7月22日 (一) 09:33 (UTC)[回复]
但en中立方针对于命名的方面，列出允许的模式就是：常用但不中立的名字，或者描述性名字（en举例为“Restoration of the Everglades（大溪地的恢复）”、“Political impact of the Boston Massacre（茶壶山丑闻案的政治影响）”）。后者可能针对一些非实体事物时的一种概括性“虚”体的命名方法。现时一些针对主观性“中立”的命名争议上，会可能根据编者的主观思想，另外草拟一些非描述性或者尝试对实体事件一个定向定性，而且并不是具有实际来源的名称，我认为如果要完善或者避免这种类型的情况，可以考虑将en中立与命名常规这部分相互照应的部分引入，来解决这类的命名争议。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月22日 (一) 09:54 (UTC)[回复]
所以說「標奇立異」的表述過於模糊，限制就該明確而非模糊不清。--路西法人 2024年7月23日 (二) 04:24 (UTC)[回复]
可能这个说法最核心的观点就是：排除已经存在专用用名的情况，在没有来源直接支撑下，为了“中立”而原创命名。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月23日 (二) 05:37 (UTC)[回复]
(＋)支持。--BigBullfrog（𓆏） 2024年7月17日 (三) 13:43 (UTC)[回复]
不反對這個修訂，至少在短期內是有作用的。Sanmosa 蚌埠 2024年7月17日 (三) 14:04 (UTC)[回复]
會不會把「非中立」三字刪去更簡單？所有命名爭議都應該先尋求共識吧？--派翠可夫 (留言按此) 2024年7月19日 (五) 01:17 (UTC)[回复]
確實，什麼是中立的爭議啦  囧rz……--SunAfterRain 2024年7月21日 (日) 10:33 (UTC)[回复]
此处无关寻求共识，是说共识不该走向原创或非常用名称。有些条目是会使用非常用名称的。例子暂时想不起。--YFdyh000（留言） 2024年7月22日 (一) 16:05 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手册/文字格式。

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

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

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

重新说一下我的看法吧。我认为添加合适的背景颜色是没有问题的。
  • 首先，滥加饱和度过高的背景颜色是不合适的，例如此例，颜色达不到WCAG 2 AA标准（[12]）。
  • 其次，合适的背景颜色能够为色觉正常的读者更快地传达信息。以“岩手縣行政區劃”条目为例，此处的颜色是符合WCAG 2 AAA标准的（[13]）。原条文中请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述，就是针对视障或色觉障碍读者的。而我认为“以文字方式表述”有些狭隘，只要以非颜色形式传达同等的信息即可。像是岩手縣行政區劃中的符号，我认为也是可行的。同时我们也可以通过使用灰度颜色滤镜模拟色觉障碍的情况，该特色列表中添加的背景色对于色觉障碍者而言，丝毫没有干扰。
  • 最后回到“美国总统列表”这个条目，当前列表中存在的问题是：副总统的党籍以及时间线模板仅以颜色表示，对于视障或色觉障碍读者来说无法得到对应信息。除去该问题，这里的色块对于视觉正常者而言，更有利于快速找到党籍信息；对于色觉障碍读者而言，打开灰度颜色滤镜后，对阅读也没有影响。
--深鸣（留言） 2024年7月18日 (四) 14:08 (UTC)[回复]
現代美國政黨的顏色相當廣為人知，以色塊表示現代政黨問題不大。然而撇開民主、共和兩黨，其他政黨顏色對多數讀者來說一點幫助也沒有。舉個例子好了，其他列表（如印度總理列表）的政黨顏色，對不熟悉印度政治的讀者（即絕大多數的中文讀者）來說只會擾亂視覺而已，對讀者來說並沒有什麼便利性，既然列表裡面已經提到政黨的話，大可不必填上許多花花綠綠甚至刺眼的色塊。
我還是澄清一下，我不反對以色塊表示黨籍，但依我對方針的理解，這是不合適的。
這次的問題癥結應該是MOS:NOCOLOR中只有在背景顏色可幫助闡釋條目內容，且沒有其他更佳的表達方式時，才可對表格或其他的內文元素加入背景顏色的背景顏色定義為何。我堅持背景顏色定義即是表格內除圖片及文字的顏色，畢竟方針說表格（而非文字）可以被加入背景顏色。而另外兩位則堅持顏色前一定要有其他元素才叫背景顏色。既然這段方針解讀有歧義，或許是時間修改一下了。--Y. Sean 2024年7月18日 (四) 14:56 (UTC)[回复]
如果不纠结于“背景颜色”的定义，阁下的意思是否是说，表格中可以添加背景颜色以及色块，但是需对多数读者有益。--深鸣（留言） 2024年7月18日 (四) 15:28 (UTC)[回复]
我維持我的主張：討論共識不能推翻一個詞彙的實際詞義，所以社羣無法也無權通過“討論共識”來推翻一個詞彙的實際詞義，因為這屬於對規則條文的超譯，而且這樣做犯了訴諸群眾與訴諸不相關領域的權威的謬誤。我認為現行條文只表達了“表格與其他的內文元素都是技術上可被加入背景顏色的對象”這點，而並沒有任何定義一切通過背景顏色的mechanism形成的顏色資料格均應用了「背景顏色」的意思。此外，我並不認為視障或色覺障礙讀者會因為通過背景顏色的mechanism形成的顏色資料格（或此處红渡厨所稱的“色块”）的存在而使致其任何利益得不到必要的滿足。Sanmosa 蚌埠 2024年7月18日 (四) 15:05 (UTC)[回复]
這裏我也引述一下我在FLC打的比方：红渡厨與Y. Sean的主張的謬誤相當於聲稱由於所有女嬰都是她們的母親十月懷胎生下的，而所有男嬰同樣都是他們的母親十月懷胎生下的，故而所有男嬰都是女嬰，而红渡厨現在在客棧這裏開討論串的行為則相當於試圖尋求“討論共識”以滿足其強行把一個男嬰說成女嬰的個人主觀意願。我只想問一個問題：這真的能把一個男嬰在實際意義上變成女嬰嗎？Sanmosa 蚌埠 2024年7月18日 (四) 15:09 (UTC)[回复]
我前述的加粗文字正是回应了阁下的该观点，本次讨论的重点并非是争执谁对条文的理解是正确的，而是应该着重讨论哪种做法更有利于读者。--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 15:21 (UTC)[回复]
不，我的意思正是無論“討論哪種做法更有利於讀者”這個理念如何地崇高，這仍然不構成逾越“討論共識不能推翻一個詞彙的實際詞義”的限制的理由。Sanmosa 蚌埠 2024年7月18日 (四) 15:29 (UTC)[回复]
我没理解阁下的意思，因为“讨论哪种做法更有利于读者”这件事情，已经无关于“词汇的实际意义”了。--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 15:40 (UTC)[回复]
這樣説吧：假設A與B都是X國人且都位於X國，X國司法獨立且有死刑。A認為B做了一些他認為十惡不赦且必須要處以死刑的事情，於是他謀殺了B，A在之後就因為謀殺罪而被處死了，因為雖然X國有死刑，但在X國只有司法機關才能決定是否對B處以死刑，而這權限並不是A所擁有的。因此，無論A謀殺B背後的理念如何崇高，A不能逾越法律給予他的權限。Sanmosa 蚌埠 2024年7月18日 (四) 15:51 (UTC)[回复]
當然，你或許也會説施劍翹也是一模一樣的情況，但她一開始的時候只被判7年監禁，後來更是被特赦了，然而那時候ROC的政治環境非常複雜，她的有期徒刑判決與特赦的政治色彩都是非常濃厚的，因此我認為不能作準。Sanmosa 蚌埠 2024年7月18日 (四) 15:57 (UTC)[回复]
还是不懂。--——— 红渡厨（留言・贡献） 2024年7月19日 (五) 02:54 (UTC)[回复]
如果情況真的是這樣的話，那我認為你其實也並不知道自己正在做甚麼。Sanmosa 蚌埠 2024年7月19日 (五) 04:45 (UTC)[回复]
为什么我觉得讨论已经完全离题了--——自由雨日（留言・贡献） 2024年7月19日 (五) 04:51 (UTC)[回复]
我想，Sanmosa阁下仍然是拘泥于已有指引。未能跳脱出已有框架。您不愿清晰明确表达自身观点，那我也只能这样猜测。--——— 红渡厨（留言・贡献） 2024年7月19日 (五) 05:37 (UTC)[回复]
我愿再次表明我的观点，本次讨论的重点并不在于方针指引怎么写的，然后我们要如何执行方针指引这件事，而是在于我们应该讨论一下哪种做法是符合读者利益的，如果现行方针无法满足读者利益，那么我们可以依据讨论后的结果修改方针指引。--——— 红渡厨（留言・贡献） 2024年7月19日 (五) 05:46 (UTC)[回复]
這不是「拘泥」，而是遵守應有的約束。既然條文並沒有任何定義一切通過背景顏色的mechanism形成的顏色資料格均應用了「背景顏色」的意思，那「背景顏色」一詞就不能如此擴張解釋，因此就算真的有一個所謂的「討論共識」做了擴張解釋這種如此荒謬的事情，這種「討論共識」是必然無效的，因為「背景顏色」這個詞語的實際含義本來就不是由社羣決定的。我最擔憂的事情正是任何人在以後會藉著「滿足社羣利益」或類似的由頭來恣意曲解方針指引，這種後果並不是社羣能夠承受的。Sanmosa 蚌埠 2024年7月19日 (五) 10:14 (UTC)[回复]
至於修改方針指引的事情，我認為很顯而易見地這裏不太可能會形成這樣的一個共識。這裏容我重複一次我在上方說過的話：我並不認為視障或色覺障礙讀者會因為通過背景顏色的mechanism形成的顏色資料格（或此處紅渡廚所稱的「色塊」）的存在而使致其任何利益得不到必要的滿足。Sanmosa 蚌埠 2024年7月19日 (五) 10:17 (UTC)[回复]
從维基百科:特色列表评选#云南省县级行政区列表此評選來看，相關格式手冊（MOS:NOCOLOR）有應用過當之虞，導致即使顏色較淡、已搭配圖例之類，仍然有違反規定之可能，或須考慮調整行文。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月23日 (二) 22:59 (UTC)[回复]
不要擋到正文顯示，一般都沒問題。目前多數純色塊使用都會搭配文字解說，已經十分足夠。社群特別需要注意的，其實不是背景顏色使用，而是顏色本身是否過於花哨刺眼，甚至違反某些網頁使用規範。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月18日 (四) 15:57 (UTC)[回复]
  1. 我理解的背景颜色应当只是纯粹的指html和css中所指的背景色，即background-color、bgcolor这种，参考[14]
  2. 具体到该列表条目中的色块，我一直不确定这种形式的色块在深色模式下如何处理为妥？
--百無一用是書生 (☎) 2024年7月19日 (五) 07:35 (UTC)[回复]

可否訂明繞過存廢討論，自行清空分類，屬於不當行為？

編輯時或看別人討論時，偶有發現有人繞過存廢討論，自行清空分類，讓分類在其他人難以察覺的情況下被自動刪除。相比條目被刪除，可恢復及查看編輯歷史知道以前的版本是什麼面貌，分類中本來曾有什麼條目，更難追尋，我認為自行清空分類這行為非常惡劣，希望能在方針訂明是不當行為，必須先提交存廢討論。--Factrecordor（留言） 2024年7月18日 (四) 15:22 (UTC)[回复]

(＋)支持--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 15:28 (UTC)[回复]
毋須明定，此類行為通常屬於遊戲維基規則。另外，我推薦大家使用追蹤分類變更的小工具，很方便抓出分類趨勢。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月18日 (四) 15:31 (UTC)[回复]
@Ericliu1912那麼可否在Wikipedia:游戏维基规则加入這種行為作為具體例子？--Factrecordor（留言） 2024年7月18日 (四) 15:51 (UTC)[回复]
我相信你們三位會想參與這個討論？Sanmosa 蚌埠 2024年7月18日 (四) 15:32 (UTC)[回复]
@Factrecordor、红渡厨、Ericliu1912。Sanmosa 蚌埠 2024年7月18日 (四) 15:32 (UTC)[回复]
我对管理员怎么删O4的规程并不了解，因此我想就不班门弄斧了。--——— 红渡厨（留言・贡献） 2024年7月18日 (四) 15:49 (UTC)[回复]
btw我自己一般會點進去，用小工具及編輯歷史、日誌等（有時候是因為移動導致清空）確定分類變更是否合理，然後再決定是要保留（加條目進來）、重新導向還是刪除。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月18日 (四) 15:54 (UTC)[回复]
原则上支持，但具体细则需商榷。例如，未经讨论且无共识，更名分类而修改大量（>5个）条目的行为，使原分类事实上废弃、提升改回难度，我也认为不妥。--YFdyh000（留言） 2024年7月18日 (四) 16:19 (UTC)[回复]
O4好像是机器人自动清理的。或者需要指定完整的流程来避免这种情况：暂停或者废止O4，将清空分类引用和删除行为转到存废讨论；需要一些机制检查分类清空前的编辑（好像只能通过RC机制（最近编辑、页面监视）检查分类的成员增减操作历史）。主要问题是，只有RC机制才能记录分类的成员增减操作历史，分类页面本身没记录，只有分类成员的页面编辑历史有记录但会很分散，可以利用RC机制的时限性（好像设置了90天清空RC表旧记录）逃避检查。或者利用机器人，在O4删除分类后，立即对RC机制下的最近更新表查询，检查最近一段时间内是否存在该分类的成员大量减出，然后预警提醒检查是否故意清空成员来诱使分类删除的情况（可能是提报页面存废或者存废复核，来讨论）。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月19日 (五) 01:45 (UTC)[回复]
我有詢問Jimmy Xu此問題，他的回覆見討論頁。若社群達成共識，可以請他修改機器人設定。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:30 (UTC)[回复]
O4不是机器人删除的话，可以写一个API工具查删除前最近更新中有没大量成员减出记录。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月19日 (五) 02:01 (UTC)[回复]
其實白磷的小工具也還是能用的吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:30 (UTC)[回复]
请大家协助检视一下分类Category:定海人的清空和删除（O4）操作，是否需要回退相关操作。--Kethyga（留言） 2024年7月20日 (六) 12:16 (UTC)[回复]
Yumeto分幾批清空了該分類。Sanmosa 蚌埠 2024年7月20日 (六) 13:30 (UTC)[回复]
已经有人（包括我）多次提醒Yumeto不要这么干了，仍然我行我素的话我只能建议提报了。--——— 红渡厨（留言・贡献） 2024年7月20日 (六) 13:38 (UTC)[回复]
@红渡厨：我這樣說有點幸災樂禍、煽風點火，不過與其「等」，不如直接幹下去。查過那個用戶名，「來頭不小」，搞不好對方「我行我素」是這個原因。--派翠可夫 (留言按此) 2024年7月20日 (六) 15:34 (UTC)[回复]
閱讀本站的定海、定海区、镇海区 (宁波市)即知原分類設計有何問題，遂將其下頁面逐一閱讀後改為更適切的既有分類。管理員AT都是這樣處理的（株札、撈金魚、流觞曲水、投壺、雙陸、樗蒲）。 紺野夢人 2024年7月20日 (六) 15:51 (UTC)[回复]
能消歧義就消歧義、能重新導向就重新導向，成本向來不高，確實需要立即刪除者為少數。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:30 (UTC)[回复]
這個議題需要考慮建立的分類本身是否合理，而不是單純追究整理分類的用戶。例如母分類本來收錄頁面就不多，卻有多個子分類、缺乏跨語言版本且無細分必要的孤立分類或重複分類等等。--AT 2024年7月21日 (日) 07:24 (UTC)[回复]
我認為任何涉及完全清空及導致分類被刪除的行動，都應有機制通知其他人正有此行動，不宜由一個帳號（尤其不是管理員）自己判斷是否合理。這樣反而就不會有事後追究。對於YFdyh000君指出的大量修改，我則不置可否。--Factrecordor（留言） 2024年7月21日 (日) 12:56 (UTC)[回复]
阻止被隨便O4速刪顯然更合理。--SunAfterRain 2024年7月21日 (日) 10:31 (UTC)[回复]
若能做到這兩點，我就沒什麼意見：
  • 有工具協助找回本來加到分類中的條目。
  • 取消自動速刪，讓其他人能察知。
--Factrecordor（留言） 2024年7月21日 (日) 12:38 (UTC)[回复]
@Factrecordor：1現有技術是可以找出誰最近被移出分類，但要自動移回去我覺得不可行；2廢除自動提刪就更沒人會察覺到這個問題了，不符合的人手復原就好。--SunAfterRain 2024年7月21日 (日) 16:15 (UTC)[回复]
你不如說，「收回所有移動分類的權利（包括機械人）」，又或者「清空分類需要有強共識」。--唔好阻住我愛國（留言） 2024年7月21日 (日) 13:25 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:命名常规 (音乐)。

現行條文

使用中文

  • 命名音樂條目時，優先使用最為通用的中文名稱命名。對於擁有官方譯名的外文音樂作品，可優先考慮使用該中文名稱；如果作品擁有不同官方譯名的作品，則以常用名稱為主。鑑於華語各地區音樂作品譯名往往不同，條目命名地域歸屬由編寫者「先到先得」，並通過地區詞轉換解決譯名差異問題。
作品在不同地區擁有不同中文名稱，依據「先到先得」處理。例：型 (歌曲)、榮耀強襲
作品在單一地區擁有不同中文名稱，按照「最早的中文名稱」處理。例：駭到爆炸、金黃耀眼
作品在單一地區擁有不同中文名稱，但不同地區擁有相同中文名稱時，則以「常用名稱」為主。例：不會是我
  • 關於作品的官方翻譯，可參考各地唱片公司和媒體平台。
中國大陸可以參考星外星與新索唱片
台灣可以參考索尼、環球、華納唱片
  • 沒有官方中文名稱的音樂作品，優先使用常用中文名稱命名。當音樂作品的原文名稱比中文翻譯名稱更為常用，或其不存在中文翻譯名稱，依據「外文規範」處理。
例：電子遊樂場 (歌曲)、四季 (單曲)、向夜晚奔去
  • 原生中文音樂作品因各地代理而產生的名稱不同「不視為譯名差異」，條目應以唱片公司最初定名為準，名稱不設轉換。台灣、港澳地區命名使用繁體中文，中國大陸、新馬地區使用簡體中文。除技術限制外，條目命名應與轉換後名稱之一相符。
例：光点 (单曲)、舞孃 (專輯)
  • 除非作品擁有正式中文暱稱，否則不作條目名稱命名。
正确： 當一個小兵（當一個小兵加入了戰爭，他就會像個國王般去思考，他所知道的就是在戰爭時奮力出擊，這樣他一旦加入了戰爭就會獲得全面性的勝利；在你的信念成為你所持有的武力時，就沒有人能打倒你；所以如果你是一個人獨自奮鬥，你要自己堅持下去，記住深度是最崇高的，如果你能認清你的立足點，你才會看到你應該要在哪裡降落，如果你掉下來了也沒關係，因為你知道你是對的）
错误： 浦西（濕濕小可愛）、盲光（Blinding Lights）、小詩（敬微小事物的詩）
提議條文

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

  • 命名音樂條目時，在中国大陆与台湾優先使用最為通用的中文名稱命名。對於擁有官方譯名的外文音樂作品，可優先考慮使用該中文名稱；如果作品擁有不同官方譯名的作品，則以常用名稱為主。鑑於華語各地區音樂作品譯名往往不同，條目命名地域歸屬由編寫者「先到先得」，並通過地區詞轉換解決譯名差異問題。
作品在不同地區擁有不同中文名稱，依據「先到先得」處理。例：型 (歌曲)、榮耀強襲
作品在單一地區擁有不同中文名稱，按照「最早的中文名稱」處理。例：駭到爆炸、金黃耀眼
作品在單一地區擁有不同中文名稱，但不同地區擁有相同中文名稱時，則以「常用名稱」為主。例：不會是我
  • 關於作品的官方翻譯，可參考各地唱片公司和媒體平台。
中國大陸可以參考星外星與新索唱片
台灣可以參考索尼、環球、華納唱片
  • 沒有官方中文名稱的音樂作品，優先使用常用中文名稱命名。當音樂作品的原文名稱比中文翻譯名稱更為常用，或其不存在中文翻譯名稱，依據「外文規範」處理。
例：電子遊樂場 (歌曲)、四季 (單曲)、向夜晚奔去
  • 原生中文音樂作品因各地代理而產生的名稱不同「不視為譯名差異」，條目應以唱片公司最初定名為準，名稱不設轉換。台灣、港澳地區命名使用繁體中文，中國大陸、新馬地區使用簡體中文。除技術限制外，條目命名應與轉換後名稱之一相符。
例：光点 (单曲)、舞孃 (專輯)
  • 除非作品擁有正式中文暱稱，否則不作條目名稱命名。
正确： 當一個小兵（當一個小兵加入了戰爭，他就會像個國王般去思考，他所知道的就是在戰爭時奮力出擊，這樣他一旦加入了戰爭就會獲得全面性的勝利；在你的信念成為你所持有的武力時，就沒有人能打倒你；所以如果你是一個人獨自奮鬥，你要自己堅持下去，記住深度是最崇高的，如果你能認清你的立足點，你才會看到你應該要在哪裡降落，如果你掉下來了也沒關係，因為你知道你是對的）
错误： 浦西（濕濕小可愛）、盲光（Blinding Lights）、小詩（敬微小事物的詩）

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

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

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

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

布告板更名

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:布告板。

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

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

技術

《通用規範漢字表》以外的簡體字是否應該類推簡化

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:繁简处理。

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

這說來有點話長，但日前因為在修理相關條目時遇到了「𫛚」這種字（該字位於Unihan擴充C區），接著就發現小苇𫛚及小葦鳽並不被系統視為是同個字，所以數天前至WP:TS報修。但稍早前微腫頭龍閣下提及這是因為該字在《通用規範漢字表》以外的緣故，所以需要一些意見討論是否應該將可能會使用到的表外字作類推簡化（並修改轉換表）重定向或移動到合適標題，又或是直接限制僅使用在表內的字或要求使用繁體標題以迴避問題。畢竟實質上不少表外字可能已經被經常使用，而導致部分條目標題實質上是繁簡混雜的，卻因非表內字而無法被正常轉換。

另外現在有個問題是如果硬套{{僻字}}轉換處理的話，有時候似乎會出現蠻可怕的懸浮文字框，但我一時不太知道怎麼處理及觸發的。舉例來說，在大陸簡體模式下大麻鷺屬的右側導航框中的「麻𫛚亚科」懸浮文字。--WiTo🐤💬 2024年5月6日 (一) 16:40 (UTC)[回复]

有多少字？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月6日 (一) 17:39 (UTC)[回复]
老實說我不知道，我目前也只是偶然發現有幾個字是這樣的狀況。但辶、門、金、食、馬、鳥、魚等字旁的字個人猜測可能會有不少這種情形，應該會需要電腦協助篩出有在Unihan擴充區內但不在表內的字。範圍上可能從擴充A區就要開始找了，A區的「䴙䴘」疑似就有類似情形（北美䴙䴘属、北美鸊鷉屬、北美鷿鷈屬，不過這組有牽涉到異體字的問題可能不一定真是如此）--WiTo🐤💬 2024年5月7日 (二) 00:33 (UTC)[回复]
根据我近期看到的一些中文学术著作，似乎并没有统一的做法，有人就用繁体字，有人则用简体字（生物类）--百無一用是書生 (☎) 2024年5月7日 (二) 09:36 (UTC)[回复]
仅考虑学术用字的话几百个应该还是有的，但如果范围扩大至所有领域恐怕得去到一千个以上（尤其是古人名、古地名）。--微肿头龙（留言） 2024年5月7日 (二) 01:43 (UTC)[回复]
忘了副知提醒我此事的@微肿头龙閣下及當時先使用了𫛚一字的@Interaccoonale閣下。--WiTo🐤💬 2024年5月7日 (二) 00:40 (UTC)[回复]
这个讨论串是否应该移动到技术版？--——🦝Interaccoonale（留言・贡献） 2024年5月7日 (二) 01:18 (UTC)[回复]
我大概说一下我的想法：
  • 从法律上讲，之前《通用規範漢字表》的草案有规定过表外汉字不类推简化，但是正式版把这一条删掉了，所以含有类推简化偏旁的表外汉字是应该简化的。
  • 从实际应用上讲，《中华人民共和国国家重点保护野生动物名录》对于生物中文名的表外汉字作类推简化处理，大部分正式学术著作也作类推简化处理。
  • 从技术上讲，如果相关的bug实在太多，我不反对改回原状，对于表外汉字在简体模式下显示繁体字。
我之前有思考过比当前的{{僻字}}模板更优雅的渲染方式，我之前想的是根据当前页面中包含的扩展区段字符，自动生成一个含有相关僻字的字体文件（字形档），然后用CSS引入到当前页面中，就可以避免这种恐怖的悬浮文字框（有时候这些文字会被显示在Tools-redirect中以及底部的页面分类里面，会变得尤其可怕）。比如大麻鷺屬就会自动生成一个仅含有𫛚字的字体文件（字形档）。
其实如果只考虑自动生成的部分，在技术上还不算太难，以遍黑体为基础字体（字形）就可以，能在服务器端编辑字体文件（字形档）的库也有很多。但是我不清楚要如何跟mediawiki整合起来。
另一种技术上更简单（但是操作上更复杂）的方法就是手动将相关字符拆分出来，然后上传到commons，然后在页面中引用即可。--——🦝Interaccoonale（留言・贡献） 2024年5月7日 (二) 01:31 (UTC)[回复]
若根據NC:COMMON的話，那就應該是要隨名錄名稱類推簡化沒錯了。但希望能以操作上簡易的方式處理，不然像我這種電腦技術笨蛋恐怕就不會操作了，不過命名標題會不會有需要額外調整？另若認為搬去技術版更合適，那還請協助移動。--WiTo🐤💬 2024年5月7日 (二) 03:27 (UTC)[回复]
我早前用字形wiki的字体做过一个小工具来实现类似你说的这种方法，后来因为技术和安全原因失效了。其实现在仍然可以利用字形wiki的字体资源来实现，只是要把字体之类的资源搬到toolforge上去，然后本地用小工具调用。c区似乎不能上传字体文件？“根据当前页面中包含的扩展区段字符”其实并不是一个很好的做法，因为每个人电脑/终端上的字库未必不一样，在甲上不能正常显示的字形，在乙那里没准就可以正常显示。所以最好的办法是自动检测某人设备上哪些字形不能正常显示，不能正常显示的就即时下载相应的字形文件（可能会遇到一些优化工作要做）。目前来说，我知道的是这种自动检测方法chrome和firefox下都有解决方案，其他浏览器内核的不确定--百無一用是書生 (☎) 2024年5月7日 (二) 09:47 (UTC)[回复]
  • chrome检测法：将代表不能显示的字符形状映射到画布，然后将文本中的每个字符一个一个映射到画布并进行比较，如果比较结果一致，就表示该字符无法在这个设备上显示
  • firefox检测法：将文本中所有字符设为斜体，如果某个字符不是斜体，就表示该字符无法在这个设备上显示（比如𱎼家人和𱎼家人）
--百無一用是書生 (☎) 2024年5月29日 (三) 04:05 (UTC)[回复]
@T45614631、Interaccoonale、Ericliu1912：我根据知乎上的一些文章整理出来了未被收录进《通用规范汉字表》的科学技术用字，见我的子页面User:微肿头龙/E。这个表肯定是不完整的，欢迎补充。--微肿头龙（留言） 2024年5月7日 (二) 06:52 (UTC)[回复]
這樣看起來的話，有些表外字還是有被正常轉換耶，像是魟、鰠、鎶等，那是被手動增加轉換的嗎？--WiTo🐤💬 2024年5月7日 (二) 07:49 (UTC)[回复]
那几个字确实已经加入全域转换了。这里有维基百科的完整繁简转换表--微肿头龙（留言） 2024年5月7日 (二) 09:01 (UTC)[回复]
所以現在算是有共識要處理這個繁簡問題嗎？感覺上這些字遲早會變成正規簡化字...--WiTo🐤💬 2024年5月13日 (一) 03:47 (UTC)[回复]
@Shizhao、Interaccoonale、T45614631、Ericliu1912：所以几位觉得需要处理这些繁简问题吗？还是放着不用理？我个人是觉得需要简化。--微肿头龙（留言） 2024年5月16日 (四) 07:48 (UTC)[回复]
我是支持简化的，但还是要考虑显示的问题？——🦝Interaccoonale（留言・贡献） 2024年5月16日 (四) 08:16 (UTC)[回复]
@Interaccoonale：其实就我个人来说{{僻字}}就已经够用了，但如果有更好的方式也可以。我的电脑技术很差，这方面就爱莫能助了。--微肿头龙（留言） 2024年5月16日 (四) 08:36 (UTC)[回复]
目前维护内置转换表的管理意见，应该是大部分都只转换到中日韓統一表意文字扩展B区，后面扩展区域的因为大部分设备字体兼容性不足，一般不转换（大部分类推简化的繁体本字能正常显示）。上面有表外漏转汉字可能要从扩展A区开始找的观点，我(＋)支持这种找法，扩AB两个区先查一遍看看有什么没转换的。至于后面的扩展区我暂保持中立。--屠麟傲血（留言） 2024年5月17日 (五) 14:53 (UTC)[回复]
那我就轉到技術區看要有沒有人能處理這問題了。--WiTo🐤💬 2024年5月25日 (六) 03:50 (UTC)[回复]
拿脚本找了一下Unihan數據庫（裏面可能有不適用的，例如“奨，奬”還有大部分一簡多繁轉換）：
篩選出了簡繁皆為基礎及擴AB區的
--User:What7what8🏠 2024年5月25日 (六) 06:51 (UTC)[回复]
如果通過的話，WP:R3可能也有需要更改。--User:What7what8🏠 2024年6月14日 (五) 03:12 (UTC)[回复]
如果通過的話Template:繁简混杂重定向也要改，不過只有幾個頁面應該不難改。--User:What7what8🏠 2024年5月25日 (六) 07:52 (UTC)[回复]
粗略看来一下阁下列出的，当中有些是违反简化规则的。比如“㳕,灡”，“蘭/兰”字位于《简化字总表》的第一表，因此是不可类推简化的。也就是说，如果有一天“灡”字被列为规范汉字，也仅会对“門”部件进行简化变成“𬞕”，而不是将整个“蘭”进行简化。再比如“䓕,薳”，由于“遠/远”也是不可类推简化部件，所以“薳”也是不必简化的，刚巧《通用规范汉字表》就有收录“薳”字。所以阁下的这个恐怕要进行超大规模的整理才能提交啊。而且我觉得没有具体使用例子的就没必要简化了。不过还是要感谢一下阁下把它们整理出来。@What7What8：--微肿头龙（留言） 2024年5月25日 (六) 13:40 (UTC)[回复]
另外想問一下哪一種字體支援最完整？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月26日 (日) 03:41 (UTC)[回复]
应当是宋体吧，因为Unicode的文件也是宋体，Microsoft在显示生僻字时好像也是默认宋体。--微肿头龙（留言） 2024年5月26日 (日) 03:46 (UTC)[回复]
宋體是字體風格不是一種字體。--Miyakoo（留言） 2024年5月26日 (日) 11:05 (UTC)[回复]
好吧，是我搞错了两个概念。谢谢指出。@Miyakoo：--微肿头龙（留言） 2024年5月26日 (日) 11:09 (UTC)[回复]
Unifont吧，不過是點陣字形，可以參考Wikipedia:Unicode扩展汉字還有Template:Unihan
( π )题外话，Special:链入页面/Wikipedia:Unicode扩展汉字“𰻝𰻝面 （← 連結 | 編輯）”怎麽全變方框了，還有𱎼家人的標題“家人”也變成方框了，是有什麽bug嗎？--User:What7what8🏠 2024年5月26日 (日) 15:30 (UTC)[回复]
Firefox正常显示，Chrome显示方框。--Kethyga（留言） 2024年5月29日 (三) 00:38 (UTC)[回复]
我这里不能复现--百無一用是書生 (☎) 2024年5月29日 (三) 03:28 (UTC)[回复]
我這也是，認真說應該是我兩台電腦都開chrome，一台正常顯示，另一台則是全方框。--WiTo🐤💬 2024年5月29日 (三) 05:34 (UTC)[回复]
天珩全字庫（大陸標準）和字雲（日本標準），它們都支援到了I區。--Miyakoo（留言） 2024年5月26日 (日) 10:58 (UTC)[回复]
目前转换表主要是我在维护，过来解释一下。确实如上文所说，目前只支持到中日韓統一表意文字扩展B区及以前的规则，B区之后基本只支持了通用规范汉字表表内的规则。这么做主要还是考虑到大众用户的设备显示，现在大家使用手机访问的频率变得更高，但目前手机显示基本只支持到扩展A区+所有表内汉字，因此不敢妄作扩张，怕反而伤害了用户的阅读体验。—Chiefwei（论 - 历） 2024年6月8日 (六) 13:23 (UTC)[回复]
說起來，大陸當局沒說能不能「類推簡化」？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月23日 (二) 23:09 (UTC)[回复]
本來通用表的草案是有說不得簡化的，但後來正式公布時刪去該行字了。所以我想應該是可以的。--WiTo🐤💬 2024年7月24日 (三) 04:27 (UTC)[回复]
但我看条目里说《解读》中还是提到了类推简化的问题。规范公布后出版的字典类书籍也还是有的选择类推，有的选择保留。--——「あたいってば最⑨ね！」 2024年7月24日 (三) 05:32 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Template talk:Navbox、Template talk:Navbar。

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

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

更新清单

  2. 以上完毕了，才需要更新Module:Navbox、Module:NavboxV2的折叠参数调整。
@Dabao qian：如果理解和没异议的话，可以推进下去。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 02:20 (UTC)[回复]
无异议，宽度和深色模式适配的问题后续再议（当然这不属于本次讨论范围）。--Dabao qian℡ 2024年7月5日 (五) 03:46 (UTC)[回复]
@Dabao qian：，看了collapsibleTables-new.js，其实Module:Navbox、Module:NavboxV2不用换，因为按照脚本逻辑，“table.collapsible:not(.mw-collapsible)”就能够选出保持兼容class的table，然后后面加上“mw-collapsible”就是加上mw的折叠功能。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 08:33 (UTC)[回复]
state=collapsed喪失作用的原因似乎與這個主題談論的內容有關，我對這個主題不熟悉，可能需要導入機器人修正(因為影響的頁面可預見非常多)--Rastinition（留言） 2024年7月17日 (三) 23:54 (UTC)[回复]
参见Module talk:Navbox#編輯請求 2024-07-17--Dabao qian℡ 2024年7月18日 (四) 09:45 (UTC)[回复]

UX

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

小蓝条？是不是一整栏的标题行？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月15日 (一) 00:41 (UTC)[回复]
@魔琴：可以參考User:SunAfterRain/js/TalkendFrameToggle.js--SunAfterRain 2024年7月16日 (二) 03:28 (UTC)[回复]

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

於Phabricator查看
編號T369537的工單

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

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

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

本主題或以下段落文字，在討論結束後應存檔至MediaWiki talk:Gadget-moveEditsectionBack.css。

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

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

本主題或以下段落文字，在討論結束後應存檔至Module talk:Navbox。

Navbox標題似乎還是沒法對齊中間（見模板說明頁面範例，可參照above參數位置及英文版本），是不是需要額外設定什麼間距？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月11日 (四) 06:26 (UTC)[回复]

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

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

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

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

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

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

@Shizhao：用這個模板來看，可以知道目前標題還是歪的。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月11日 (四) 16:31 (UTC)[回复]
这样修改之后Template:JR东日本的车辆似乎显示有问题，左右两侧的按钮会和色块重叠，这种情况需要写脚本修复到4em才能正常显示。--Dabao qian℡ 2024年7月11日 (四) 17:44 (UTC)[回复]
在Special:PermaLink/83367707的基础上按上述方案分别修改MediaWiki:Common.css和Module:Navbox即可。--Dabao qian℡ 2024年7月11日 (四) 18:57 (UTC)[回复]
改了，看看是否还有问题--百無一用是書生 (☎) 2024年7月12日 (五) 02:46 (UTC)[回复]
目前发现的问题是当浏览器宽度（window.innerWidth）小于640px时，点击右侧折叠按钮后，折叠按钮、查论编和标题全都会跑到左侧叠在一起。暂不确定是否和本次修订相关--百無一用是書生 (☎) 2024年7月12日 (五) 03:05 (UTC)[回复]
可以复现，原先是页面宽度小于640px时会折行显示，改完之后强制缩排在同一行就会直接叠在一起。--Dabao qian℡ 2024年7月12日 (五) 18:16 (UTC)[回复]
(？)疑問：{{Navbox}}的state參數設定摺疊好像失效。--Qqkuro66541（留言） 2024年7月16日 (二) 15:34 (UTC)[回复]
之前我修改的的查论编字体变小，可以看一下现在较大字体下的问题：Template:Campaignbox 塞爾維亞－鄂圖曼戰爭 (中世紀)，Template:Campaignbox 巴勒斯坦託管地猶太人暴動。查论编和标题部分重叠了--百無一用是書生 (☎) 2024年7月22日 (一) 06:19 (UTC)[回复]
@Cookai1205：看看怎么修复标题文字换行的问题吧。--Dabao qian℡ 2024年7月22日 (一) 11:45 (UTC)[回复]
是指改回這樣？我沒什麼想法。畢竟那是3個元素會推擠才會換行，而這次的改法就是讓他們不會互相影響。
如果目標是避免重疊，我想到可以調大MediaWiki:Common.css#L-398的左右padding（5em？），但這樣在關掉navbar的情況會浪費空間。--Cookai餅塊🍪（💬留言） 2024年7月22日 (一) 16:38 (UTC)[回复]
或者用JavaScript调整，navbox-title宽度小于一定数值时禁用position属性，这个就需要计算了。--Dabao qian℡ 2024年7月22日 (一) 17:28 (UTC)[回复]

Infobox person/Wikidata 出生日期

本主題或以下段落文字，在討論結束後應存檔至Template talk:Infobox person/Wikidata。

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

无法复现。或许已经修复？--PexEric💬|📝 2024年7月13日 (六) 11:54 (UTC)[回复]
剛剛看了一下，似乎是只有香港和澳門版本有此問題，應與使用的裝置和瀏覽器無關--惣流·明日香·蘭格雷不姓式波 2024年7月14日 (日) 01:30 (UTC)[回复]
未登录时港澳版本可重现，登录后无法重现。--YFdyh000（留言） 2024年7月14日 (日) 02:22 (UTC)[回复]
哪個瀏覽器？我win11 firefox和edge，登入與否，無痕與否，均能復現，chrome的話沒安裝試不了。--惣流·明日香·蘭格雷不姓式波 2024年7月14日 (日) 06:33 (UTC)[回复]
Win10 Edge。curl -v https://zh.wikipedia.org/zh-mo/%E7%83%AD%E5%B0%94%E7%8E%9B%E5%A8%9C%C2%B7%E7%BB%B4%E4%BA%9A%E5%A8%9C 的源码里也能看到>1972年十月16日&#160;<。--YFdyh000（留言） 2024年7月14日 (日) 11:10 (UTC)[回复]
我这只有未登录时香港、澳门繁体能复现。--Kcx36（留言） 2024年7月14日 (日) 10:45 (UTC)[回复]
經測試，該欄會隨著介面語言改變（zh-hk、ko）（登入與否的差異應該跟這有關），行為與{{#time}}類似
  • {{#time:Y年Fj日|1942-10-16|zh-hans}}（「1942年10月16日」）
  • {{#time:Y年Fj日|1942-10-16|zh-hant}}（「1942年10月16日」）
  • {{#time:Y年Fj日|1942-10-16|zh-hk}}（「1942年十月16日」）
可能跟MediaWiki:October月份系列有關：
--Cookai餅塊🍪（💬留言） 2024年7月15日 (一) 13:27 (UTC)[回复]
需要去TWN修改--Dabao qian℡ 2024年7月17日 (三) 15:35 (UTC)[回复]
已修改，待下次MediaWiki版本更新即可应用，请留意技术新闻--Dabao qian℡ 2024年7月20日 (六) 12:21 (UTC)[回复]

存廢重新提交

我去看《溯源之惧》的存廢討論，7月4日重新提交，但是我找不到重新提交的頁面。標註是重新提交到Wikipedia:頁面存廢討論/記錄/2024/07/12，但是編輯記錄和頁面都沒有《溯源之惧》的存廢討論移動記錄。--Nostalgiacn（留言） 2024年7月15日 (一) 08:55 (UTC)[回复]

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

Template:Hlist-comma

本主題或以下段落文字，在討論結束後應存檔至User talk:Summerize。

日維動畫條目的各話列表節使用{{劇集列表}}模板時，參數都會使用{{Hlist-comma}}模板，且會根據當前畫面寬度自動換行，中維也有相同模板{{Hlist-comma}}，不過不會自動換行，想知道是什麼原因。--夏冰 2024年7月16日 (二) 00:18 (UTC)[回复]

這參考Template_talk:Hlist#單獨使用{{hlist}}會導致同一頁面的{{Infobox}}內建的hlist出現多餘的空格，inline-block的問題一修又有另一個的問題--Qqkuro66541（留言） 2024年7月16日 (二) 17:01 (UTC)[回复]

2024年第29期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的翻译版本。

技術新聞調查

  • 邀請您填寫這份簡短問卷調查，協助我們改善技術新聞。本次調查旨在更有效地滿足閱讀技術新聞的各類讀者的需求。本次調查還會開放3天。本次調查適用這份隱私聲明。本次調查提供其他語言的翻譯版本。

最近更改

  •   維基媒體開發者現在可以正式繼續使用Gerrit和GitLab，基於維基媒體基金會於6月24日決定支持在這兩個平台共同進行軟體開發。Gerrit和GitLab皆是開發者用來編寫、審查和部署軟體代碼的代碼儲存庫，而這些代碼支撐著MediaWiki——用於建構維基專案，也是編輯者用於創建和改進內容的工具。這項決定將保障開發者們的生產力，並避免code review——代碼審查方面的問題影響用户。更多詳情請見遷移狀態頁面。
  • 維基媒體基金會誠徵產品與技術諮詢委員會（PTAC）申請人。該小組將匯集技術貢獻者與維基媒體基金會，共同開發一個更具彈性、與時俱進的技術平台。委員會成員將對維基媒體運動的產品與技術活動進行評估與諮詢，以便我們開發多代的项目。我們正在尋找來自世界各地具有不同项目經驗的技術貢獻者。請於8月10日前在此申請。
  • 持有回退權的編輯者可以在Android版維基百科App使用新的編輯巡查功能。這些功能包括最近更改的新動態、撤销和回退等相關链接，以及创建和保存個人的用户討論消息庫以供巡查時使用。如果您所在的wiki希望向沒有回退權但編輯次數達到一定門檻的用户提供這些功能，您可以聯絡團隊。更多關於此项目，請參閱Diff文章。
  • 在基金會進行聯絡溝通後，有權访问維基百科圖書館的編輯者再度能使用SpringerLinks中的非開放访问內容。延伸閱讀上週完成的22個社群提交工單。

本週更改

未來更改

  •   下週，邀請工作人員、志願工具維護者和軟體開發團隊在測試維基上測試臨時帳號功能。臨時帳號功能有助於改善wiki上的隱私保護。目前未有其他進一步的部署安排。歡迎在项目討論頁發表意見和提出疑問。 [18]
  • 邀請跨維基上傳文件或教導他人如此操作的編輯者，參與維基共享資源上的討論。共享資源社群正在討論將能夠通过跨維基上傳功能（或稱上傳對話框）上傳文件的用户，限縮為維基共享資源上的自动确认用户。這是因為通过這種方式上傳的文件大量侵犯了著作權。Commons:跨維基上傳有簡短摘要，討論位於Commons:互助客棧。

技術新聞由技術新聞編者撰寫，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。 歡迎訂閱維基媒體基金會公報獲取更多新聞。

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

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

於Phabricator查看
編號T253907的工單

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

具體來說發生的是：合併儲存格在排序後會被分割，即使排序取消了（回到 狀態）依然不會恢復合併。
排序表格遇到合併儲存格好像一直是這樣。--Cookai餅塊🍪（💬留言） 2024年7月16日 (二) 05:15 (UTC)[回复]
phab:T122214提到類似問題，被評為Not a bug。不過當中沒有提到「排序取消了依然不會恢復合併。」，可以考慮針對這點提新的工單？--Cookai餅塊🍪（💬留言） 2024年7月16日 (二) 05:27 (UTC)[回复]
可以考慮把大地圖移出表格。--Cookai餅塊🍪（💬留言） 2024年7月16日 (二) 05:21 (UTC)[回复]
phab:T253907。--GZWDer（留言） 2024年7月16日 (二) 14:57 (UTC)[回复]

Template:Cite X

這玩意有必要存在嗎？直接在template:cite twitter加個日期檢測，自動調整輸出不就行了？英維（相信其他站也是）都是直接重定向到cite twitter，本站template:tweet也能正確處理X。最大問題是知道cite twitter存在的人數肯定比知道cite x的多，我相信不少人都“誤用舊模板”了。--惣流·明日香·蘭格雷不姓式波 2024年7月16日 (二) 05:36 (UTC)[回复]

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

tweet貌似早前已改好？

name  
@username

text

9999-12-31

name1  
@username1

text1

1-12-31

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

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

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

本主題或以下段落文字，在討論結束後應存檔至Talk:六四事件。

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

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

模板摺疊問題

本主題或以下段落文字，在討論結束後應存檔至Module talk:Navbox。

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

突然發現使用Navbox模板時候，縱然state的一欄採用了collapsed，仍然無法摺疊，想請教這是出現了問題還是其他原因，謝謝。--Yutommy 崖上的孤兒 北橋的狗 2024年7月16日 (二) 17:03 (UTC)[回复]

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

崩溃

於Phabricator查看
編號T370304的工單

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

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

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

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

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

wrap换行

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

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

captcha

可不可以行行好，讓captcha可以接受全型英文，別讓人敲了兩個字母才發現不對又切回來，然後為了編輯又要切回去，很好玩是不是？

如果不會，我教你。建個一維陣列，以A到Z和a到z或其unicode為索引，內容則是全型字母，這就切換過去了，而且是O(1)。簡單吧？

如果還要拿什麼安全來說嘴，那拜託內容不要用英文，用中文字好嗎？這不是更安全嗎？打完字也不用切換全型半型了，拜託拜託。

我沒有請人拿掉這個沒經過投票就私加的captcha喔，沒有喔。我是拜託在展現想加就加的莫大權力之後，也展現一下程式能寫就寫，能力跟權力匹配，這不過份吧？我知道一定有人要飛什麼安全的大帽子過來，那就改成中文字讓機器人更沒機會運作，這方向沒有錯吧？拜託拜託，行行好。--2603:8000:500:FB00:89EE:D188:8491:54F3（留言） 2024年7月20日 (六) 03:38 (UTC)[回复]

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

Campaignbox被默認為開啟狀態，使用指令皆無法更改

本主題或以下段落文字，在討論結束後應存檔至Template talk:Campaign、Module talk:Navbox。

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

在模板:Campaignbox War of the Spanish Succession這個模板中，我盡了一切辦法仍然無法讓他在讀者剛開始閱讀時是閉合狀態，明明指令與其他模板以及英文維基對應模板相同，但其他模板就沒有這個問題，想請大佬們幫忙解決 --Waylon1104（留言） 2024年7月20日 (六) 15:16 (UTC)[回复]

@Waylon1104 完成。
雖然可以個別頁面處理，但collapsed的無效顯然需要導入機器人批量替換成uw-collapsed，喪失作用的頁面過多。--Rastinition（留言） 2024年7月20日 (六) 15:21 (UTC)[回复]
好的了解，太感謝您了--Waylon1104（留言） 2024年7月20日 (六) 15:30 (UTC)[回复]
@Rastinition：能不能直接修改模板代碼，相容參數啊？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:31 (UTC)[回复]
参见Module_talk:Navbox#编辑请求_2024-07-17--Dabao qian℡ 2024年7月20日 (六) 18:26 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

快速删除候选問題

[[Category:快速删除候选]]裡面的原神系列條目沒有被任何人掛上速刪模版，但是卻出現在這個分類裡面，這是怎麼回事？--日期20220626（留言） 2024年7月22日 (一) 07:16 (UTC)[回复]

百分之百是其他頁面導致。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月23日 (二) 23:04 (UTC)[回复]
我當時也是這麼認為，但是沒找到是哪個頁面導致的，不過現在好了。--日期20220626（留言） 2024年7月24日 (三) 00:21 (UTC)[回复]
嵌入的模板Template:原神 (Special:Diff/83507391/83507391)--Kethyga（留言） 2024年7月24日 (三) 11:39 (UTC)[回复]

2024年第30期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的翻译版本。

功能週報

  • 監管員現在可以對帳號實施全域封禁。在此更改之前，全域封禁僅能針對IP位址和IP範圍實施。不同於全域鎖定，全域帳號封禁不會將被封禁的用户登出。全域鎖定不受此更改影響。新的全域帳號封禁功能與臨時帳號项目有關，這種新型態的用户帳號用於取代未註冊編輯者的IP位址，使其不再公開可見。
  • 本週稍晚，FlaggedRevs（標記修訂，又稱「待定更改」）的介面將得到改進，與MediaWiki的其他介面及維基媒體設計系統Codex保持一致。行動裝置和Minerva皮肤上的FlaggedRevs介面體驗原本與他處不一致，後經由Growth團隊和一些志願者修復並移植到Codex。 [19]
  • 維基媒體網站用户現在可以通过GlobalVanishRequest提交帳號隱退請求。當貢獻者希望永遠停止編輯時，可以使用此功能。它可以幫您隱藏過去的關聯和編輯，以保護您的隱私。一旦處理完成，該帳號將被鎖定並重新命名。 [20]
  • 您試過使用手機監控和應對維基百科中的破壞行為嗎？一篇關於行動應用程式中的巡查功能的Diff文章重點介紹了一些新功能，包括滑動瀏覽最近更改動態以及個人化的用户討論消息庫，供使用手機巡查時使用。
  • 維基媒體貢獻者和GLAM機構（美術館、圖書館、檔案館及博物館）現在可以使用「共享資源影響力指標」分析面板，了解與衡量維基共享資源對於創建高品質百科全書內容的影響。該面板提供諸如分類每月編輯數、瀏覽量最高的文件、使用共享資源圖片的維基條目等方面的分析。有了這些新的數據轉儲，GLAM機構可以更精準衡量將內容引入數位共享資源的投資回報率。 [21]

项目近況

  • 快來在嶄新重啟的社群願望清單分享您對改善維基的想法。社群願望清單是供志願者分享他們改善維基運作方式的想法（稱為願望）的維基媒體論壇。新版願望清單始終開放，wikitext和可视化编辑器皆可使用，並允許以任何語言提交願望。

增廣見聞

  • 你有沒有想過維基媒體軟體如何支持300多種語言？這比Google Chrome的介面多了253種語言，而這絕非偶然。維基媒體基金會的語言與產品在地化團隊通过調整所有工具和介面，使其適應您的語言和其他語言，為您提供支持。閱讀Diff文章了解更多關於該團隊及其即將開展的工作。
  • 維基媒體如何在維護如此頻繁使用的網站之時，同時建構創新和實驗性的產品？維基媒體基金會職員Johan Jönsson近期發表的一篇Diff文章，重點介紹了基金會的「未來受眾」計畫的工作，其目標不是建構完善的產品，而是測試新的想法，例如ChatGPT插件和「加入事實」等，幫助維基媒體走向未來。

技術新聞由技術新聞編者撰寫，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。 歡迎訂閱維基媒體基金會公報獲取更多新聞。

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

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

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

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

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:Wikiplus。

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

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

求助

请求协助添加跨语言链接

本主題或以下段落文字，在討論結束後應存檔至Talk:瓦西利斯·波利蒂斯。

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

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

請求協助上傳檔案 2024-07-17 16:24

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

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

我在翻譯en:Hydrogen economy碰到一個表格，不曉得是否有先進能幫忙，填上隔線？

根據英文版翻譯而來的原始碼如下。如果能添上隔線，或許對於讀者會較易閱讀吧。謝謝。

生產方式 注釋 目前成本 (2020年–2022年) 預計2030年成本 預計2050年成本
灰氫 (未包含碳稅)
國際能源署提供[1] 2022年6月估計的成本（俄羅斯入侵烏克蘭導致天然氣價格飆升） 2021: 1.0–2.5 – –
2022: 4.8–7.8
普華永道提供[2] 2021: 1.2–2.4
藍氫
國際能源署提供[1] 2022年6月（俄羅斯入侵烏克蘭導致天然氣價格飆升）估計的成本 2021: 1.5–3.0 – –
2022: 5.3–8.6
英國能源安全及淨零部 提供[3] 範圍受天然氣價格影響 2020: 1.6–2.7 1.6–2.7 1.6–2.8
美國顧問公司GEP Worldwide提供[4] 2022: 2.8–3.5 - -
國際智囊團能源轉型委員會（英语：Energy Transitions Commission）提供[5]（p. 28） 2020: 1.5–2.4 1.3–2.3 1.4–2.2
綠氫
國際能源署提供[1] 對2030年及2050年的估計，把在條件良好地區建設太陽能發電廠的假設列入 2021: 4.0–9.0 <1.5 <1.0
2022: 3.0-4.3
英國政府提供[3] 使用電網電力（適用於英國），範圍取決於電價、電解技術和成本。 2020: 4.9–7.9 4.4–6.6 4.0–6.3
利用閒置可再生電力（適用於英國），範圍取決於電解技術和成本。 2020: 2.4–7.9 1.7–5.6 1.5–4.6
國際再生能源總署（IRENA）提供[6] 2020: 2.2–5.2 1.4–4.1 1.1–3.4
GEP Worldwide[4] 資料來源指出從2010年起，綠氫生產成本已下降60% 2022: 3.0–6.0
投資銀行Lazard提供[7] 2022: 2.8–5.3
普華永道提供[2] 2021: 3.5–9.5 1.8–4.8 1.2–2.4
能源轉型委員會提供[5]（p. 28） 2020: 2.6–3.6 1.0–1.7 0.7–1.2

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

见此，已填上“隔线”。
生產方式 注釋 目前成本 (2020年–2022年) 預計2030年成本 預計2050年成本
灰氫 (未包含碳稅)
國際能源署提供[1] 2022年6月估計的成本（俄羅斯入侵烏克蘭導致天然氣價格飆升） 2021: 1.0–2.5 – –
2022: 4.8–7.8
普華永道提供[2] 2021: 1.2–2.4
藍氫
國際能源署提供[1] 2022年6月（俄羅斯入侵烏克蘭導致天然氣價格飆升）估計的成本 2021: 1.5–3.0 – –
2022: 5.3–8.6
英國能源安全及淨零部 提供[3] 範圍受天然氣價格影響 2020: 1.6–2.7 1.6–2.7 1.6–2.8
美國顧問公司GEP Worldwide提供[4] 2022: 2.8–3.5 - -
國際智囊團能源轉型委員會（英语：Energy Transitions Commission）提供[5]（p. 28） 2020: 1.5–2.4 1.3–2.3 1.4–2.2
綠氫
國際能源署提供[1] 對2030年及2050年的估計，把在條件良好地區建設太陽能發電廠的假設列入 2021: 4.0–9.0 <1.5 <1.0
2022: 3.0-4.3
英國政府提供[3] 使用電網電力（適用於英國），範圍取決於電價、電解技術和成本。 2020: 4.9–7.9 4.4–6.6 4.0–6.3
利用閒置可再生電力（適用於英國），範圍取決於電解技術和成本。 2020: 2.4–7.9 1.7–5.6 1.5–4.6
國際再生能源總署（IRENA）提供[8] 2020: 2.2–5.2 1.4–4.1 1.1–3.4
GEP Worldwide[4] 資料來源指出從2010年起，綠氫生產成本已下降60% 2022: 3.0–6.0
投資銀行Lazard提供[9] 2022: 2.8–5.3
普華永道提供[2] 2021: 3.5–9.5 1.8–4.8 1.2–2.4
能源轉型委員會提供[5]（p. 28） 2020: 2.6–3.6 1.0–1.7 0.7–1.2

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

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

参考資料

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

請求協助上傳檔案 2024-07-18 09:54

我想要上傳的圖片來源是<從某個網址下載，請提供網址 / 自行拍攝>，想要使用在請提供條目名稱（如果条目还不存在，请先建立条目再请求上传文件）的<資訊框/某個段落，請說明>。 --民心一言（留言） 2024年7月18日 (四) 09:54 (UTC)[回复]

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

剛才發表一篇低碳電力（翻譯自en:Low-carbon electricity）碰到的問題

我把en:Low carbon electricity翻譯為中文。文中有一節是摘錄自en:Sustainable energy（有一篇算是簡短的永續能源與之連結），但我在低碳電力文中引用永續能源時，總會被引導至再生能源，而中文版中再生能源與永續能源是兩篇不同的文章，而en:Sustainable energy和en:Renewable energy也是兩篇不同的文章。不知道此問題該如何解決？--ThomasYehYeh（留言） 2024年7月19日 (五) 05:39 (UTC)[回复]

什么叫“引用永续能源……”，能否实际操作一下我看看？--——自由雨日（留言・贡献） 2024年7月19日 (五) 05:57 (UTC)[回复]
不好意思，我正準備長篇大論，為我的問題提出說明。結果上了剛才發表的低碳電力，發現我之前提的問題已經不見了。謝謝。--ThomasYehYeh（留言） 2024年7月19日 (五) 08:49 (UTC)[回复]

阿賴耶、阿摩羅、涅槃寂靜三頁面之刪除討論

本人因「沒有資格」而無法提出存廢討論。原討論如下：
此三個「數字單位」最早出現於日文維基百科ja:命数法的版本5493605（2006年4月28日），編輯者為匿名IP（ja:特別:投稿記録/59.120.251.217），未列出參考文獻，且該IP的唯一貢獻即為上述編輯。最後這些「數字單位」於2022年4月21日經討論後被刪除（ja:命数法的版本89148055）。此參考資料中列出最小的單位為「靜」或「清淨」。此外，本人親自用搜尋引擎搜尋了「涅槃寂靜+單位」等組合，其結果均為個人網誌，均著於2006年4月28日至2022年4月21日之間，其參考文獻或無，或為上述日文維基百科頁面，或只提到某「佛典」而未明確指定哪一部，可見該錯誤流傳之廣，甚至NHK教育頻道的《ja:にほんごであそぼ》中的歌曲《1より小さい数》都提到了這三個「單位」。
參考日文維基百科對此三個「數字單位」頁面的刪除討論：ja:Wikipedia:削除依頼/阿摩羅と阿頼耶、ja:Wikipedia:削除依頼/涅槃寂静 (数)——OosakaNoOusama（留言） 2024年7月19日 (五) 06:49 (UTC)[回复]

是不是LTA:Qqqyyy干的？他喜欢“恶搞”佛教相关条目。--Thyj (คุย) 2024年7月19日 (五) 07:49 (UTC)[回复]
現階段還不能確認是不是Qqqyyy，但我發現Qqqyyy有一曾用IP為59.120.117.226，而日文維基百科上的IP同樣以59.120開頭，不知道這兩個有什麼關係。——OosakaNoOusama（留言） 2024年7月19日 (五) 09:40 (UTC)[回复]
有可能就是他，因为IP段相近。查询结果是来自台湾台北市或高雄市的IP。--Thyj (คุย) 2024年7月19日 (五) 11:58 (UTC)[回复]

關於颱風模版

最近小弟在東京颱風中心熱帶氣旋等級中新增了兩個新等級（強烈颱風VSTY及猛烈颱風VITY）。但在模板:Infobox hurricane current的編輯中遇到困難。具體問題為在模版的JMAcategory參數中輸入TY，它的右上方就會顯示出TY，但小弟在該參數中輸入VSTY/VITY，右上方只會顯示TC，嘗試了多次也未能解決問題。故在此尋求幫助。 p.s.該模板VITY/VSTY背景顏色及文字顯示(強烈颱風/猛烈颱風)目前都沒有問題，唯右上方小方格顯示出現問題--Aaroncheung 895（留言） 2024年7月20日 (六) 04:50 (UTC)[回复]

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

关于第一手来源资料

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

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

周小川

本主題或以下段落文字，在討論結束後應存檔至Talk:周小川。

我注意到維基百科上的文章說，經濟學家周小川出生時，他的父母在黑龍江省東安市東北軍工部直屬二廠（東安電器廠）工作。但出生地卻標註為宜興。這是一個奇怪的差異。--87.1.243.195（留言） 2024年7月20日 (六) 16:33 (UTC)[回复]

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

請求協助上傳檔案 2024-07-21 04:20

我想要上傳的圖片來源是<從某個網址下載，請提供網址 / 自行拍攝>，想要使用在請提供條目名稱（如果条目还不存在，请先建立条目再请求上传文件）的<資訊框/某個段落，請說明>。 --Papa1qq（留言） 2024年7月21日 (日) 04:20 (UTC) https://www.facebook.com/photo/?fbid=1159051634158935&set=a.761152617282174[回复]

想要使用在Centaur Cafe Mega 150條目作為介紹，不知道是否可行?謝謝

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

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:Wikiplus。

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

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

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

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

請求協助上傳檔案 2024-07-21 12:17

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

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

求助Infobox school地图

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

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

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

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

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

技术求助

本主題或以下段落文字，在討論結束後應存檔至Talk:塞特波齐战役。

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

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

User:Pclee9413/馬紀筠

表达式错误：预期外的<运算符。(±)合併到馬紀筠。不讓人自刪。馬紀筠正式條目寫了，不想留底。

提交的維基人及時間：Pclee9413（留言） 2024年7月24日 (三) 14:58 (UTC)--Pclee9413（留言） 2024年7月24日 (三) 14:58 (UTC)[回复]


條目探討

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

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

你成功勾起了我对“纪”这个字的心理阴影。--MilkyDefer 2024年6月14日 (五) 12:22 (UTC)[回复]
大草，你是在说这个？--BigBullfrog（𓆏） 2024年6月16日 (日) 18:38 (UTC)[回复]
不应视为中文。汉语“祭”无此用法（可查阅《现代汉语词典》《国语辞典》《辞源》等等）。--自由雨日（留言） 2024年6月14日 (五) 12:33 (UTC)[回复]
如果此處的祭如同戰祭、豐年祭，是指慶典或活動的話，可參見《教育部異體字字典》釋義五。[23]--夜月辰星（留言） 2024年6月14日 (五) 12:44 (UTC)[回复]
如果此處討論的是Category名的話，或許可以參照Category:日本鐵路公司，條目名使用特例的鐵道，而Category名則用慣例的鐵路。--夜月辰星（留言） 2024年6月14日 (五) 12:57 (UTC)[回复]
既然《教育部异体字字典》给出了这个义项，那么说明“祭”在汉语中确实可以表示“庆典活动”的意思，但我仍不认为可以用来作标题，理由有三：一、《异体字字典》没有给出词性说明，不过从例句（例词）为「雪祭」、「海洋祭」、「音樂祭」等来看，“祭”表示此义时可能只能用作词缀（例如“作者”“读者”的“者”字、“产业化”“绿化”的“化”字等），“冲绳县的祭”中“祭”直接作为成词语素，这可能是不合法的，至少很不符合语感；二、目前只有台湾的词典给出这种用法，可能不是所有汉语地区广泛的用法；三、即便在中国大陆等地区的词典中找到了这种用法，用“祭”来表示庆典活动在汉语中仍是不常见的，完全可以用更常见的方式来表达。--自由雨日（留言） 2024年6月14日 (五) 12:57 (UTC)[回复]
这两个节日名称本来就是沿用日治时期的日文写法吧？--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年7月8日 (一) 05:03 (UTC)[回复]
意味不明啊？維基人接納某些活動常用名稱為中文就算了，分類可以自己命名就或許不必如此了吧？不過日本相關分類好像都這樣，有整體考慮必要。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 12:47 (UTC)[回复]
可以改用祭典。--AT 2024年6月14日 (五) 13:20 (UTC)[回复]
中文普通名词“节日”不应换成日语的“祭”，并非是专有名词。现代标准汉语中“祭”一般是祭祀的意思。反对使用祭典，祭典不是節日。百科全书面向的是普通的中文读者。--Kethyga（留言） 2024年6月14日 (五) 14:05 (UTC)[回复]
條目祭 (日本)在2007年由武藏創建並使用了「祭」，分類:日本的祭>分類:日本各都道府县的祭>……亦依從了這樣的命名。如需更改應一併更改，可使用「祭典」。--紺野夢人 2024年6月14日 (五) 14:08 (UTC)[回复]
如果祭是普通日语词汇而非有特别意义和限定，不应这样用。--YFdyh000（留言） 2024年6月14日 (五) 14:13 (UTC)[回复]
同意Kethyga君，貢寮國際海洋音樂祭可以，但Category:沖繩縣的祭不行，因為前者是專有名詞，而且用「祭」表達活動或慶典仍不是中文圈普遍的用法。固然語文是活的、會改變、會交流的，語文也可以有外來語，但此種用法尚未成為中文外來語。-游蛇脫殼/克勞棣 2024年6月14日 (五) 15:26 (UTC)[回复]
应该是一种日文汉字借入中文汉字语境的情况，但仅限于专用名词化（例如札幌雪祭等），如果作为一个独立语素作为其他语素的被修饰对象，类似上述举例，应该没有对应类似“节日”、“祭典”的意思，可能需要对应替换为相应语言的独立语素“节日”或者“祭典”。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月15日 (六) 00:53 (UTC)[回复]
但纠结下去的话，“祭”在中文汉字的语言有“对死者表示追悼、敬意的仪式”、“供奉鬼神或祖先”的意思，对应日文汉字其意思也有类似的语义：因为日本这些“祭”的前身有相当是与“供奉鬼神”等的仪式。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月15日 (六) 00:53 (UTC)[回复]
經我再三考慮，我建議全面廢除「日本的祭」以下所有分類，改以「神道祭事」取代（有需要的話可再按都道府縣細分），與神道無關的如札幌雪祭等則劃入日本年度活動（有需要的話可再按都道府縣細分），只有明確區分祭典和活動才能解決目前的問題。--AT 2024年6月15日 (六) 08:52 (UTC)[回复]
"祭"可以作爲日語漢字直接引入漢語的外來詞。--小河仔（留言） 2024年6月26日 (三) 10:22 (UTC)[回复]
未经词典等收录，不得人为“引入”外来词，这属于原创研究（原创新词）。另外，您是新注册用户，第一条编辑便是在条目探讨内突然回复，这是为何？（这种现象难免令人多想，故需确认）--自由雨日（留言） 2024年6月26日 (三) 10:29 (UTC)[回复]
在編輯條目時看到了互助客棧。--小河仔（留言） 2024年6月26日 (三) 10:30 (UTC)[回复]
上一条回复是您的第一笔编辑。按理说，新用户并不熟悉客栈。如您有其他主账号，还请根据WP:傀儡政策公开。若真是新注册用户，那可以忽略我说的。--自由雨日（留言） 2024年6月26日 (三) 10:33 (UTC)[回复]
我剛剛接觸互助客棧，覺得很新奇，像BBS論壇一樣。--小河仔（留言） 2024年6月26日 (三) 10:39 (UTC)[回复]
哦哦，好的。欢迎来到维基百科。--自由雨日（留言） 2024年6月26日 (三) 10:45 (UTC)[回复]
据我所知，“祭”（名词）在现代汉语中是不成词语素，不能单独作为一个词使用，即使在日本文化相关的语境下也是如此。因此即使表示日本节庆活动的“祭”可以视为恰当的中文用法，“XX节日”也不宜改为“XX的祭”。--CuSO4 · 龙年大吉 2024年6月15日 (六) 17:12 (UTC)[回复]
也許從分類命名一致性出發，所有相關分類都應該使用「節日」為後續。現在Category:各國節日分類之下，也就是「日本的祭」顯得獨行獨立。
看了一下日維，對方是ja:Category:各国の祭，日本的分類有點過分名從主人。--Nostalgiacn（留言） 2024年6月16日 (日) 01:36 (UTC)[回复]
日本節日是可以有的，但是這不等同於祭，例如御盆節本身是個節日，而非祭，盡管在這些節日期間很大機會舉行各種各樣祭，兩者還是不對等的。因此，神道祭事本身也不打算歸類至各國節日，日本節日則應該是日本年度活動的子分類。--AT 2024年6月16日 (日) 09:48 (UTC)[回复]
就算是「Category:神道祭事」這個分類，在Category:宗教節日也顯得獨行獨立，其他都是「佛教節日」、「基督教節日」。對比其他語言維基，英維也是「Shinto festivals」（宗教名+festivals），日維是「神道行事」（宗教名+行事）。
還是上面說的日本的分類有點過分名從主人，感覺應該使用「分類命名一致性」處理一下。
就算不說XX祭這個問題，退一步講，當前應該先建立「日本節日」分類，沖繩縣的祭也應該恢復「琉球節日」。--Nostalgiacn（留言） 2024年6月17日 (一) 02:22 (UTC)[回复]
「沖繩縣節日」與「琉球節日」是否有差別？嚴格意義上肯定有（後者傳統一些），但寬泛一些的分類是否也有？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月17日 (一) 06:36 (UTC)[回复]
琉球可以指曾經一個國家（琉球国），沖繩縣是現在日本一個行政區。當前的移動本來就很怪。
退一步說，未來有祭祀活動的分類，也應該另建「沖繩縣宗教節日」，在「沖繩縣節日」之下。
關係如下：
琉球節日》沖繩縣節日》沖繩縣宗教節日--Nostalgiacn（留言） 2024年6月17日 (一) 08:01 (UTC)[回复]
琉球除了是个国家，还是个民族，“琉球节日”在当前语境中更应该不理解为琉球民族的节日--苞米(☎)💴 2024年6月17日 (一) 13:00 (UTC)[回复]
歡迎補充，那麼你是否支持改回「琉球節日」，以作為整合琉球文化相關節日的分類，再另建「沖繩縣節日」作為下行分類。--Nostalgiacn（留言） 2024年6月17日 (一) 16:52 (UTC)[回复]
其實分類的話不用那麼嚴格，分類重新導向即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 10:58 (UTC)[回复]
分類收錄的確實是沖繩縣的節慶，這樣命名是考慮到與d:Q8447345對應及與本站既有分類一致（隨討論結果同步修改）。琉球國是沖繩縣的建前歷史（類比Category:夏威夷州>Category:夏威夷州歷史>Category:夏威夷建州前历史>Category:夏威夷王國），琉球民族是來自這一地域的族群（類比Category:夏威夷州>Category:夏威夷原住民），這樣分類是可行的，如需細分也可再設立子分類。但這已經不是本則討論的主旨了。--紺野夢人 2024年6月18日 (二) 04:02 (UTC)[回复]
我翻了一些分類，明白為何有種違和感，因為中維有Category:亚洲各民族节日這個分類體系，英維沒有這個體系，你將一個原本是基於「各民族节日」建立的分類，轉換成「各國節日」。有點生搬硬套導致的違和感。--Nostalgiacn（留言） 2024年7月9日 (二) 02:52 (UTC)[回复]

上面討論都大致認為應該日本的相關分類統一為「Category:XX的節日」。如果沒有其他意見，會稍後進行操作。

「神道祭事」分類個人提出應該與其他「宗教節日」統一為「神道節日」，這個有其他看法嗎。--Nostalgiacn（留言） 2024年7月5日 (五) 07:27 (UTC)[回复]

「的」字多不必。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月5日 (五) 07:30 (UTC)[回复]
(－)反对更改神道祭事分類，祭事不是節日，例如葵祭僅僅是個別神社的儀式，在神道內沒有作為節日的共通性。另外，日本節日分類的設立仍然要考慮如何歸類，不是有個「祭」字就是節日。--AT 2024年7月5日 (五) 08:28 (UTC)[回复]
能否解釋一下，英維為何用festivals（en:Category:Shinto festivals），日維用ja:Category:神道行事（年中行事（日语：年中行事）），而中維使用「祭事」一詞。
你不反對前面的吧，畢竟你也說日本節日則應該是日本年度活動的子分類。分出另一個「祭」作為下級分類是一回事，「日本節日」還是要有的。--Nostalgiacn（留言） 2024年7月7日 (日) 02:07 (UTC)[回复]
(－)反对「祭」不等於「節日」，參照《教育部異體字字典》，「祭」確實是中文用法。-Hierro） 2024年7月6日 (六) 16:31 (UTC)[回复]
认同“祭”不等同“节日”，但反对根据《教育部异体字字典》将其认定为“中文用法”，重复一下前面的论证：一、《异体字字典》没有给出词性说明，不过从例句（例词）为“雪祭”、“海洋祭”、“音乐祭”等来看，“祭”表示此义时可能只能用作词缀（例如“作者”“读者”的“者”字、“产业化”“绿化”的“化”字等），“冲绳县的祭”中“祭”直接作为成词语素，这可能是不合法的，至少很不符合语感；二、目前只有台湾的词典给出这种用法，可能不是所有汉语地区广泛的用法；三、即便在中国大陆等地区的词典中找到了这种用法，用“祭”来表示庆典活动在汉语中仍是不常见的，完全可以用更常见的方式来表达。另外为什么您的UTC时间超前1小时……——自由雨日（留言・贡献） 2024年7月6日 (六) 15:39 (UTC)[回复]
現在都國際化，讓我們直接看日本旅遊局的資料，有提供官方中文，日文「日本の祭りとイベント」，英文Japanese Festivals & Events，繁體中文是節慶活動、簡體中文是日本祭典与盛会。
個人合理懷疑目前「日本的祭」的翻譯是「日本の祭り」機翻，中文應該翻譯「節慶」或者「祭典」。--Nostalgiacn（留言） 2024年7月7日 (日) 02:20 (UTC)[回复]
祭典不是指節日。--Daniel1023（留言） 2024年7月8日 (一) 05:09 (UTC)[回复]
從翻譯角度來說，我舉例的時日本給出的官方翻譯，「日本の祭りとイベント」其中一個官方翻譯就是「節慶」，可以理解為節日和慶典的縮寫。
上面很多關於「祭」的討論，都是中文語境的「祭」，變成語言考據的原創研究現場，「祭典不是指節日」這個問題也是如此。根本不是在討論「日本の祭り」的翻譯問題。
就我目前找到的資料來看，「日本の祭り」應該翻譯作「日本祭典」或者「日本節慶」，如果有人強調要「祭」，選用日本官方的簡體翻譯「日本祭典」更好。--Nostalgiacn（留言） 2024年7月9日 (二) 01:52 (UTC)[回复]

繼琉球節日，我再翻看了一些相關分類。明白一直存在的違和感在哪裡了。

有好幾套的分類系統，也由於不同編者的想法，導致一些概念和分類混在。Category:亚洲各民族节日這個分類方式搞出來的Category:日本傳統節日。實際操作上，英維是連「日本電影節」都歸到「日本節日」（請見en:Category:Film festivals in Japan）。按現在日本節日條目的說法，「日本節日包括日本的傳統節日、公共假日、主題日和地方祭典」，很直觀表達了「各國節日」這個分類方式要記錄什麼。Category:日本节日重複創建和刪除的記錄，可以看出各種想法衝突導致的混亂。

補充現狀：英維很早就將Matsuri（英语：Matsuri）（祭り）重定向到Japanese festivals（英语：Japanese festivals）（本地日本節日），而日維很早就把「祭り（日语：祭り）」重定向到ja:祭（本地節日）。

除了改名，也許需要在wikidata改變其他語言維基的關聯的分類，作為有很多知日派的中維，這裡也可以採用折中道路，建立兩個平衡分類，一個「日本節日」（日本的傳統節日、公共假日、主題日），一個「日本祭典」（日本各地祭典），達至遙遙領先，與眾不同。--Nostalgiacn（留言） 2024年7月9日 (二) 09:39 (UTC)[回复]

如果沒有其他意見，會採用折中做法。--Nostalgiacn（留言） 2024年7月19日 (五) 15:23 (UTC)[回复]
(＋)贊成。--AT 2024年7月20日 (六) 09:37 (UTC)[回复]
(＋)贊成。
--Daniel1023（留言） 2024年7月21日 (日) 04:11 (UTC)[回复]
@Nostalgiacn：屆時「祭典」與「節日」的母子分類關係？祭典算是一種節日吧，所以前者歸至後者？然後我可以協助恢復「日本節日」分類的編輯歷史。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月21日 (日) 08:22 (UTC)[回复]
「祭典」與「節日」為Category:日本年度活動的平行分類，恢復「日本节日」分類以對齊其他語言維基，減少混亂與不協調。--Nostalgiacn（留言） 2024年7月21日 (日) 14:58 (UTC)[回复]

已經更新了相關分類，並在「日本節日」和「日本祭典」加入說明。

由於平衡分類的做法，原本「沖繩縣的祭」是用於記錄琉球傳統節日，沒有符合「祭典」，所以先恢復到原本的「Category:東亞傳統節日」和「Category:亚洲各民族节日」分類方式。日後如有這些沖繩祭典的條目，可以另建「沖繩縣祭典」分類歸納。

沖繩的分類涉及一個問題，法律上日本不承認有少數民族，實際上日本有少數民族。由於中維在兩岸問題的多年鑽研，所以對類似問題更為敏感，相關分類處理應該更為細膩，兼容一些中維獨有的分類系統。--Nostalgiacn（留言） 2024年7月23日 (二) 03:22 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至WikiProject talk:植物、WikiProject talk:朝鮮半島。

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

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

满族姓名

本主題或以下段落文字，在討論結束後應存檔至Talk:滿族人名、WikiProject talk:满族。

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

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

在藝人條目列舉演出作品的格式問題

本主題或以下段落文字，在討論結束後應存檔至WikiProject talk:歌手和演员。

（15日中午時分在維基專題討論:歌手和演員發問了一次，但隨後發現那個專題好像沒有甚麼流量，討論又都是在互助客棧搬過去的，所以改到這裏來。抱歉）

我看到現在的藝人出演作品列表有兩種寫法。

想問哪一個才對？謝謝！--派翠可夫 (留言按此) 2024年7月15日 (一) 16:39 (UTC)[回复]

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

@YFdyh000 / @银色雪莉： 更新一下。我最後選擇了分拆。列表有大約40K，主條16K，雖然主條短一些但不至於太短。草稿暫時放在我的用戶空間，進度大約是80%：

  1. 主條目
  2. 作品列表

現在差兩個小列表還沒補完，之後再收拾一下作品列表的簡介就打算正式建立條目。不過在此之前先詢問您倆的意見，看看以上做法是否恰當，謝謝。

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

作品列表内容没感觉特别多和多到分拆，但脚注蛮多。广告和代言人如果写入列表，可能太水，明星常有大量广告合约和出演，只有少数具记载价值，既有效介绍——非独立来源应该也行，如自传提到其影响。--YFdyh000（留言） 2024年7月18日 (四) 08:41 (UTC)[回复]
@YFdyh000：其實我就只是把原文版本的列表整合而已，我甚至嫌原版分得太仔細而減省了兩、三個分節。廣告其實相當少（原版只有12個），主要都是電影和電視劇。
其實我認為要分拆的原因有兩個：一、條目描述的這個人在可見將來還會有很多值得記載的作品和成就，與其到時再拆，不如現在就做，免得主條目太擁腫；二、我其實沒見過一個列表腳註這麼充足，所以其實是打算按FL的方向去編修。
現在比較大的問題是我沒有能力判斷哪個有記載價值，頂多是沒來源的直接不寫而已。而現在確實除了廣告之外全部都有來源。有些是原版沒有而我自己找到的，例如原版有些MV的來源是放在演唱者的條目裏。--派翠可夫 (留言按此) 2024年7月18日 (四) 11:19 (UTC)[回复]
分拆我觉得可以接受。广告代言部分基于WP:廣告代言感觉要重新考量，我认为在这个共识的前提下，除非是主业广告，否则最好不写；非主业广告一定要写的话，只写确实有相当大影响力的广告（不过即使是那种，也是散文化写到正文里会比独立列出好）。获奖记录是不是还要中文化一下？列举演员作品这事，只要来源OK，在列表这个环节，个人以为能列就列——大家不喜欢的可能是正文短小而列表漫长（有些传记条目连正文都没有，纯作品列表），但不是不喜欢列出作品。--银色雪莉（留言） 2024年7月18日 (四) 12:36 (UTC)[回复]
@銀色雪莉：就是因為獲獎紀錄還沒譯所以才說只有80%，不過那段其實很容易，只要從作品列表和獲獎模板複製貼上就行（事實上這人出道只有5年已經進了6個獲獎模板也是我急於寫她的主因之一）。現在先解決最需要解決的事。兩位都給了很好的意見，我思考一下再嘗試修修--派翠可夫 (留言按此) 2024年7月18日 (四) 12:54 (UTC)[回复]

有關中央弘前站移除維護模版事宜

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

請注意近年一用戶對參考格式的編輯

如毫不解釋就在參考資料欄掛這種模板[31][32]。

多在Cite_news加入publication-place，但這是指該報媒的出版地點，他卻當成新聞發生點，在各條目填入，且填入又奇怪，如寫成[臺]北縣[33]、 新北[市][34]、新竹[縣][35]、台中[市][36]、台北[市][37][38][39][40]。

對於括號，Wikipedia:格式手册/标点符号有特別規定:「括號的其他形式還包括全形方括號「［］」、六角括號「〔〕」和方頭括號「【】」等，僅應在特定文體內出現。」--Outlookxp（留言） 2024年7月16日 (二) 10:41 (UTC)[回复]

我回退後且說明後[41]，他依然繼續這樣加入[42]。 --Outlookxp（留言） 2024年7月16日 (二) 10:18 (UTC)[回复]

那是我們稍有時差的緣故，我已即刻有所說明，請參考。--59cond12（留言） 2024年7月16日 (二) 10:30 (UTC)[回复]
謝謝，是因我剛剛看到這樣編輯感到太激動了。目前就這樣[43]。--Outlookxp（留言） 2024年7月16日 (二) 10:46 (UTC)[回复]

在條目頁面裡(非頂部)加入需要清理模版，此舉是否擾亂閱讀?

本主題或以下段落文字，在討論結束後應存檔至Talk:靠廢柴技能【狀態異常】成為最強的我將蹂躪一切。

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

詳見《靠廢柴技能【狀態異常】成為最強的我將蹂躪一切》這個條目。
User:Tisscherry近日在上述條目裡，在「登場人物」這一項裡，擅自在內容裡面加了需要清理模版。
我來維基百科這麼久，還是第一次見到可以把需要清理模板直接加到條目裡的，這類需要清理模版通常是加到條目頂部才對。
這種行為是不是嚴重妨礙條目閱讀？麻煩發表一下意見。
如果屬於妨礙閱讀之類的擾亂行為，我想直接對他發出警告。--Znppo（留言） 2024年7月16日 (二) 14:50 (UTC)[回复]

@Znppo：, 在Template:Long_plot/doc#用法中有提到「該模板應放置於條目的某一段落下或某部分下，而非條目頭部。」目前的用法應該沒有問題。--Wolfch (留言) 2024年7月16日 (二) 15:08 (UTC)[回复]
了解，感謝閣下告知，既然此類掛模版行為合規，則我沒有餘話可講。--Znppo（留言） 2024年7月16日 (二) 15:14 (UTC)[回复]
简单来说，可以。这类这类标记模板有支持插入段落的样式，部分有放出开关参数来指定的。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月17日 (三) 01:23 (UTC)[回复]
了解，只是我認為單掛這類模版無意義。維基百科被掛需要清理模版的條目何其之多，如過江之鯽。
只會掛一個清理模版，之後人就跑了的，多的是。清理模版即使掛再久，條目本身也不會有人主動去改善。
想掛清理模版的人，不如自己負清理之責，自己動手整理條目。
不然「就等於是徒具形式」的掛掛清理模版了事，具體意義不大，僅具象徵意義。--Znppo（留言） 2024年7月17日 (三) 01:51 (UTC)[回复]
(！)意見：WP:维基百科不强迫任何人参与，“自己负清理之责，自己动手整理条目”当然是最好的，但没有任何理由要求人人这么做。挂清理模板既可以提示其他编者改善条目，又可以提醒读者下面的内容可能存在质量问题，只要理由得当，绝不是“无意义”或仅有“象征意义”的贡献。--——自由雨日（留言・贡献） 2024年7月17日 (三) 02:25 (UTC)[回复]
感謝回應的各位意見，往後放這類型模板會注意註明原因。我的做法是想要整理，但目前暫時不行，所以我會用提示模版。另一方用意也是希望不要無限擴充，畢竟ACG條目有時候就是會越寫越無節制。--提斯切里（留言） 2024年7月17日 (三) 02:59 (UTC)[回复]
本來就是無意義、跟象徵意義。
單純掛清理模版，不會有人理。
你這種理想化，跟實際情況不符。--Znppo（留言） 2024年7月17日 (三) 03:44 (UTC)[回复]
話說從頭，一個月後無人整理，我會記得自己來的。--提斯切里（留言） 2024年7月17日 (三) 03:49 (UTC)[回复]
我上面是回復另一使用者，不是針對你。--Znppo（留言） 2024年7月17日 (三) 03:50 (UTC)[回复]
你單純掛清理模版就跑，還是後續打算清理，我沒有意見。--Znppo（留言） 2024年7月17日 (三) 03:51 (UTC)[回复]
“本来就是无意义、跟象征意义。”“单纯挂清理模版，不会有人理。”对这种随意评价他人改善行为，随意臆测其他编者之后行为的评论，我没有任何回复的兴趣。--——自由雨日（留言・贡献） 2024年7月17日 (三) 03:51 (UTC)[回复]
我也是對你抱持同一想法。跟你多言無益。--Znppo（留言） 2024年7月17日 (三) 03:53 (UTC)[回复]
還有，沒人說理由不當。
他若是理由不當，我早把清理模版移除了。
要掛清理模版，誰都可以掛，絕沒人說不可以。
要拔清理模版，可是會反被警告濫移除模版。
我也不是第一天來維基百科，怎麼能做什麼不能做，不用你來教。--Znppo（留言） 2024年7月17日 (三) 03:49 (UTC)[回复]
完全不知道你在说什么，你要是仅扰乱就可以闭嘴了。--——自由雨日（留言・贡献） 2024年7月17日 (三) 03:52 (UTC)[回复]
誰搗亂，我開的串你跑來我的串裡，說我搗亂，你當你是誰。--Znppo（留言） 2024年7月17日 (三) 03:53 (UTC)[回复]
@自由雨日謝謝您，@Znppo不要緊張，熊熊勇闖異世界我也還沒整理完，我會記得的，--提斯切里（留言） 2024年7月17日 (三) 03:54 (UTC)[回复]
大家冷靜，一開始是我沒有執行妥當，造成誤解非常抱歉，往後會更小心的。--提斯切里（留言） 2024年7月17日 (三) 03:56 (UTC)[回复]
再次重申，你要怎麼作我沒意見。
每個人都有他以自己方式編輯或維護維基百科條目的權利。
我原始開這串的目的，是詢問你這種直接在條目裡掛清理模版，而不是在條目裡最頂掛模版的行為，是否影響閱讀構成擾亂。
本串我已經得到解答了。如此而已。--Znppo（留言） 2024年7月17日 (三) 04:04 (UTC)[回复]
那此一討論應該就可以結束了，請大家冷靜，謝謝--Wolfch (留言) 2024年7月17日 (三) 04:22 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

能精确分类的应当精确分类。——暁月凛奈 (留言) 2024年7月17日 (三) 05:02 (UTC)[回复]
同上--YFdyh000（留言） 2024年7月17日 (三) 05:28 (UTC)[回复]
不太適合，類比朝鲜海峡應同時歸入「日本海峽」與「韓國海峽」，而非僅歸入「亞洲海峽」。--紺野夢人 2024年7月19日 (五) 06:08 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至WikiProject talk:中国文化遗产。

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

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

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

Template:中国保护区列表

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

@Karoke Cirno：這模板是重定向，目標在存廢討論好像沒共識，但被Shizhao幹掉了。--派翠可夫 (留言按此) 2024年7月20日 (六) 15:48 (UTC)[回复]
我提删的。该存废讨论有明确的共识，并且请注意存废讨论不是数人头，是依靠存废讨论中正当合理的意见。当然，如果您仍有不同意见，您可以依照程序，到维基百科:存废复核请求表达您的意见。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 03:46 (UTC)[回复]
@紅渡廚：我的認知是有正反意見而沒有討論完結跡象就是沒共識。這不是誰多誰少的問題，而是雙方理據是否充分並且是否獲得解決的問題。我不是發問者，所以有這個程序理論上都應該先讓樓主去做。不過既然您這樣說，那請問那個討論的共識在哪裏？--派翠可夫 (留言按此) 2024年7月21日 (日) 04:51 (UTC)[回复]
请参阅WP:共识的定义。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 04:55 (UTC)[回复]
我沒看出那個討論有哪裏達到指引頁面上的定義要求，請您具體解釋一下。--派翠可夫 (留言按此) 2024年7月21日 (日) 05:00 (UTC)[回复]
我想您应该优先指出，您认为那个讨论有哪里没达到。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 05:02 (UTC)[回复]
@红渡厨：那裏最後一條留言都是指要保留，而之後那意見都沒有被確實回應，那麼共識在哪裏？如果說之前那一個刪除沒有人回應就是有共識，那為甚麼保留那條可以被無視？也難怪那人提交存廢覆核請求了。我會到那裏聲援他。 -- 派翠可夫 (留言按此) 2024年7月21日 (日) 05:08 (UTC)[回复]
你声援不声援我不管，Wikipedia:頁面存廢討論/記錄/2024/06/29#Template:中华人民共和国各类资源保护列表，但在该讨论中，最后一条保留意见，仅是在说“不符合”，并没有给出任何理由，这连有效回复都算不上。明显无法被考量进共识内。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 05:15 (UTC)[回复]
他的理由就是情況跟他引述的條文對不上。--派翠可夫 (留言按此) 2024年7月21日 (日) 05:21 (UTC)[回复]
他又没给出任何他觉得对不上的理由。他说对不上就对不上？维基百科的方针解释权又不在他那。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 05:26 (UTC)[回复]
有點常識的應該就看得出來吧（反而是您剛才把整篇指引丟給我要求我全篇慢慢看更不合理）。就算您（或者Shizhao）認為他的回應不成立，也應該先在討論中指出那段回應的問題，讓他啞口無言再刪除，而不是連回應都不給一個。這個讓其他人看來真的很霸王硬上弓。--派翠可夫 (留言按此) 2024年7月21日 (日) 05:30 (UTC)[回复]
存废讨论每天有那么多人留言，不可能每条都有回应，这点还请阁下理解。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 05:35 (UTC)[回复]
反正不是您動手的，我們靜待覆核事件的發展吧。--派翠可夫 (留言按此) 2024年7月21日 (日) 05:44 (UTC)[回复]
关于阁下提到的让他哑口无言再删除，我单独回复你一下：不可能的，如果这个世界上存在说几句话就能让对方哑口无言，让对方同意你的意见。那么这个世界上就不可能会再有争吵、不可能会再有战争，这是极其不现实的理想主义。--——— 红渡厨（留言・贡献） 2024年7月21日 (日) 07:16 (UTC)[回复]
(～)補充：如果那個理由一開始可以被無視，討論就不會被重新提交一次了 -- 派翠可夫 (留言按此) 2024年7月21日 (日) 05:23 (UTC)[回复]
其實若確實決定要刪除，管理員也應該要清理連入頁面。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月21日 (日) 08:25 (UTC)[回复]

省直管县级行政区

本主題或以下段落文字，在討論結束後應存檔至Category talk:中国省直管县级行政区。

中華人民共和國的省直管县级行政区到底有哪些，如何將其歸入分類:中国省直管县级行政区？條目久未更新，對於部分政區到底是不是「省直管县级行政区」又語焉不詳。--紺野夢人 2024年7月24日 (三) 09:22 (UTC)[回复]

完美世界的國際版

請問一下完美世界 (公司)的國際版是不是用「Perfect World Games」，因為不同地區。就很像米哈游一樣。--Sim Chi Yun（留言） 2024年7月24日 (三) 09:51 (UTC)[回复]

根據目前推行的討論遞進機制試行案，你應該在條目討論頁先發起討論，過一段時間沒人回應再轉到這裡發文。LuciferianThomas怎麼還沒移動話題，我都不知道是要現在回覆，還是等轉移後才回覆。--Nostalgiacn（留言） 2024年7月25日 (四) 10:29 (UTC)[回复]

其他

沒有主題的頁面如何評級

本主題全部或部分段落文字，已移動至WT:通用評級。执行人：Sanmosa 蚌埠 2024年7月17日 (三) 14:50 (UTC)。[回复]

評級系統缺失問題

（原始標題為「將{{Classicon}}與{{Class/icon}}同步」配合公告欄調整標題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 07:47 (UTC)）[回复]

配合上方#Random_Thought: 跟进英维的WikiProject_banner_shell改版因此需要解決評級系統缺失問題，故提出以下議案-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)[回复]

第一階段：修正評級值不同步問題

議案1：將{{Classicon}}與{{Class/icon}}同步

本主題或以下段落文字，在討論結束後應存檔至Template talk:Class/icon。

已通過：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

我認為應將{{Classicon}}與{{Class/icon}}進行同步。{{Class/icon}}提供了比{{Classicon}}更多種級別的圖示，如請求、未來、動態等評級的圖示，{{Classicon}}都沒有。而若{{Classicon}}與{{Class/icon}}合併的話，則等同於{{Classicon}}改成Module模式，需要社群共識，故發起討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)[回复]

(＋)支持合併，後者（{{Class/icon}}）目前只有在154頁上使用。-- Willy1018（留言） 2023年12月26日 (二) 01:33 (UTC)[回复]
(？)疑問：@Willy1018：那要不要{{Classicon}}重定向到{{Class/icon}}？剛才已補充{{Classicon}}所有功能到{{Class/icon}}了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月26日 (二) 02:33 (UTC)[回复]
可以，但前者{{Classicon}}被全保護，只有管理員才能進行編輯，需要提{{ep}}。-- Willy1018（留言） 2023年12月26日 (二) 04:56 (UTC)[回复]
似乎未來之类的评级并未被整个评级系统完全支持？--百無一用是書生 (☎) 2023年12月28日 (四) 02:24 (UTC)[回复]
(：)回應：@Shizhao：有支持，顯示評級的最後一個調用是{{WPBannerMeta/qualityscale/mask}}，而{{WPBannerMeta/qualityscale/mask|future}}→「未来」，但在要送入{{#assessment:}}的{{Class_mask}}需要設|future=yes才有，不然會被濾掉。而要送入{{#assessment:}}的{{Class_mask}}直接寫死無法設定參數，故建議將要送入{{#assessment:}}的mask改用{{WPBannerMeta/qualityscale/mask}}，這樣才能正確支援。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月28日 (四) 02:50 (UTC)[回复]
支持合并。不过纯模板实现也不错。--桐生ここ★[讨论] 2023年12月28日 (四) 21:48 (UTC)[回复]
@桐生ここ：完全不建議模板實現。現時模板實現是使用{{#switch:}}，您忘了2020年初{{#switch:}}爆炸事件Special:PermaLink/58036835#A_technical_issue_with_articles_of_French_communes導致中維崩潰的事件了嗎。{{#switch:}}的開銷要高於模組實現，所以建議使用模組實現，安全又有效率。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月29日 (五) 00:06 (UTC)[回复]
這邊最近在處理基礎條目與{{WikiProject banner shell}}的圖示問題（Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版，暨將{{Vital_article}}併入{{WPBS}}），(＆)建議直接採用{{Icon}}會更通用。--Kanashimi（留言） 2024年1月2日 (二) 09:18 (UTC)[回复]
但我覺得要有專題專用模板。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 09:33 (UTC)[回复]
我想採用不同模板來處理同一件事的問題是較不易維護。--Kanashimi（留言） 2024年1月2日 (二) 09:49 (UTC)[回复]
@Kanashimi：問題是目前{{Icon}}並未完整涵蓋Class/icon現有內容。改用{{Icon}}將會導致部分圖是消失，或發生變化。我認為專題圖示應該要統一的Style，但例如{{Icon|image}} 和{{Class/icon|image}} 就不一致，而且{{Icon|image}} 與以下圖示比較{{Class/icon|image}} 、{{Class/icon|A}} 、{{Class/icon|B}} 、{{Class/icon|C}} 明顯Style嚴重變調，故(－)反对。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 10:13 (UTC)[回复]
或許我們可以擴展{{Icon}}使之涵蓋我們想要的範疇，例如採用{{Icon|image_class}}？--Kanashimi（留言） 2024年1月2日 (二) 10:20 (UTC)[回复]
@Kanashimi：我這個議案只是想先動全保護模板{{Classicon}}，至少先同步圖示，但您目前這樣介入會導致共識亂了，連同不都做不到了，會導致花費更多「跑流程」時間，我想先同步，也做好patch了，都準備好了被你弄沒了？我想先動全保護模板{{Classicon}}至少先同步圖示；至於以後怎麼維護可以再討論。而且您的提議「例如採用{{Icon|image_class}}」也還沒有patch，先現實一點吧，不要紙上談兵，我只想趕快同步圖示，並讓Style一致，評級圖示是評級圖示，其他圖示是其他圖示；評級圖示就該有評級圖示自己的Style，(！)抗议亂七八糟的不一致Style圖示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 10:29 (UTC)[回复]
也好。那就等這個討論結束再說吧。--Kanashimi（留言） 2024年1月2日 (二) 10:30 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

議案2：修正評級系統被不當過濾掉的評級值

已通過：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

 
「未來級」等級被正確識別（使用沙盒class mask避免被濾掉而實現的），見此[1]。

上方User:Shizhao提到「未來級」等評級級別無法被完整支持問題，是因為送入評級系統的評級值被不當過濾掉了，即使專題上層已啟用該等評級，但最終還是會被「未繼承上層參數的{{class mask}}」過濾掉，這樣的話就算專題啟用了該等評級也沒有用，都被濾掉了，根本裝飾，白啟用了，因此提議將送入評級系統的評級值改為{{WPBannerMeta/qualityscale/mask}}模板，見編輯請求Template_talk:WPBannerMeta/core#編輯請求_2023-12-28，修改前後的比較Special:PermaLink/80307466，可以看到原有的版本評級值大部分都被濾掉了，建議換成提議的Patch，以讓「未來級」等評級級別能真正被支持。同時，我也確認值接送未來級能正確被工具識別，見右圖，連圖示都有，代表評級系統是支援此輸出的，能正確地被讀取並識別。

因此提出本動議。不曉得各位有沒有異議或意見。Ping參與過相關討論的人@桐生ここ、Z7504、Shizhao、Willy1018：，上方參與過評級討論的也Ping一下@暁月凛奈、Lopullinen、Milkypine、MilkyDefer：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月31日 (日) 08:29 (UTC)[回复]

支持。( π )题外话：台湾之星的标识现在还没改。--桐生ここ★[讨论] 2023年12月31日 (日) 10:36 (UTC)[回复]
資慈，我覺得行。 --窝法乙烷 儿法梦碎 2024年1月1日 (一) 14:38 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

議案3：同步各模板/块的評級值

已通過：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

目前有多個被全保護的評級模板/块的評級值（如有的有漏掉、有的圖案、顏色不一致）並不同步，因此提議同步各評級模板/块的評級值。不曉得各位有沒有異議或意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月31日 (日) 10:30 (UTC)[回复]

(～)補充相應的編輯請求Module_talk:Class/data#編輯請求_2023-12-28、Template_talk:Class_mask/core#編輯請求_2023-12-25和Template_talk:Class_mask#編輯請求_2024-01-05（和2023-12-25是配套的），顏色的部分：Template_talk:Class/colour#編輯請求_2024-01-05。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月31日 (日) 10:31 (UTC)[回复]
支持。--桐生ここ★[讨论] 2024年1月1日 (一) 09:03 (UTC)[回复]
就先改看看，讓其他用戶實際去測試這樣才準，而不是每天一直喊支持。不然只是一直放沙盒而不去實際更改的話，完全不知道到底能不能測試。雖然維基百科終於有認知要將其功能「進步」，但也不應每日這樣「無止盡的討論而沒有作為」才是。因此，這個討論就不用再多說什麼了。--Z7504非常建議必要時多關注評選（留言） 2024年1月1日 (一) 11:52 (UTC)[回复]
(：)回應：@Z7504：其實我有私下找User:AT了，但他一直說影響範圍太大要先討論  囧rz…………。我當然也希望能直接改啊，不然WP:7DAYS獲共識再公示7天半個月就過去了……-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月1日 (一) 12:05 (UTC)[回复]
還想說中文維基百科不是長期以來都對專題這個東西愛理不理的，這不就是專題模板在用的相關評級嗎？為什麼不直接修改讓其他人測試呢？建議AT直接幫忙修改吧。因為如果要叫維基百科廢除已經存在多年的專題，顯然是不可能的，更沒有討論是否要廢除專題的必要。--Z7504非常建議必要時多關注評選（留言） 2024年1月1日 (一) 13:45 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

提案已通過請求佈署

已佈署：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
佈署相關編輯，也就是編輯以下模板：
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:23 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

評級缺失問題目前辦理狀況

截至2024年1月5日 (五) 17:08 (UTC)已提出三案討論，三案皆在等待初步共識，以便公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]

評級缺失案辦理狀況
進度 討論中 初步共識 公示中 部署中 已完成 後續維運
*通用評級設立 已獲共識 已通過 已完成 已完成 進行中
*評級繼承機制 初步共識 公示通過 已完成 進行中
評級值同步 初步共識 公示通過 已完成 進行中
修正過度過濾評級值 初步共識 公示通過 已完成 進行中
評級圖示同步 初步共識 公示通過 已完成 進行中
完善評級系統規範 討論中 等待中
註：標有「*」表示是其他相關提案。
以上為截至2024年2月2日 (五) 09:45 (UTC)的辦理狀況。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]
2024年2月2日 (五) 09:45 (UTC)更新-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月2日 (五) 09:45 (UTC)[回复]
2024年4月6日 (六) 08:29 (UTC)更新-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月6日 (六) 08:29 (UTC)[回复]

第二階段：依據先前共識將不是條目命名空間的評級分類從「XX級條目」改為「XX級頁面」

已通過：
公示通過。分類改名涉頁面較多，會再進行公告；而Wikipedia:条目质量评级标准移動到Wikipedia:页面质量评级标准將會立即執行。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:18 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

根據先前共識，需要將不是條目命名空間的評級「XX級條目」的分類改為「XX級頁面」，但因技術限制未能將「XX級條目」的分類改為「XX級頁面」，因此本案已提出新的方案，依據頁面命名空間添加分類，以實現該共識。具體執行方案在Template:WPBannerMeta/qualityscale/sandbox。同時將Wikipedia:条目质量评级标准移動到Wikipedia:页面质量评级标准，不知道各位有沒有異議？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:57 (UTC)[回复]

沒有異議，就是不知道會不會出現突發狀況。 --窝法乙烷 儿法梦碎 2024年1月17日 (三) 11:35 (UTC)[回复]
已在多面體專題進行測試，詳見Category:分类级多面体页面、Category:模板级多面体页面，目前測試整個多面體專題尚未出現問題。待本案正式通過之後才會正式(►)移动分類頁面。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 11:39 (UTC)[回复]
沒有意見，但在專題頁面（WikiProject）中使用到的{{Articles by Quality and Importance}}模板應一併解決顯示異常之問題（前幾天似乎還有這問題，現在不知道），雖然這模板平常根本沒什麼人在意  囧rz……（所以沒解決可能也沒差吧？因為專題本來就沒什麼人在意了）--Z7504非常建議必要時多關注評選（留言） 2024年1月18日 (四) 14:26 (UTC)[回复]
首先，結尾為「XX重要度」的分類不會移動，不在本計畫內，而{{Articles by Quality and Importance}}是讀取結尾為「XX級XX重要度」的分類，故基本上本案不會影響{{Articles by Quality and Importance}}。再來，如果這個真的要處理，要本案通過後，分類全部清理好，分類全數移動完成後才能處理，不然現在處理數字都會變成0。故應是下一個階段要處理的（或者共識是暫不處理），不是此案此階段討論範圍。此外，如果是{{Articles by Quality}}的話，直接更新分類名稱即可。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月18日 (四) 16:02 (UTC)[回复]
已逾一周無新發言，根據WP:7DAYS七日無進一步發言視為已獲初步共識，如本聲明無人有異議，將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月26日 (五) 00:32 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

分類改名準備

已完成：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

雖Special:Diff/80961277已公示通過，但因涉及的頁面眾多，因此宜再進行全站公告。公告完後將進行兩個階段完成：

  • 階段1：全保護頁面編輯請求：Template:WPBannerMeta/qualityscale和Template:Class
    由於該等分類都是以上被全保護的模板自動添加的，因此需要執行以上編輯請求。等編輯請求完成後，數萬個頁面緩存自動清理完畢後，分類將自動從「XX級條目」改歸為「XX級頁面」。
  • 階段2：正式(►)移动分類頁面（可能是約階段1完成後再過一周）
    等緩存全部清完，再將「XX級條目」分類，逐個(►)移动到「XX級頁面」分類。
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:30 (UTC)[回复]

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

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:页面评级。

本案最初的初衷就是完成此共識Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引，來完成WP:QUALITY_升為指引一事，來正式解決「評級系統缺失問題」（指引/規範未立也算是本系統的一種「缺失」）。等上方都完成，此處將繼續。聲明：當這些「缺失」都解決後，本人將不再碰評級系統這塊了，這燙手山竽真是消磨人的精神。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 04:40 (UTC)[回复]

可能我上面没说清楚，让你以为我是反对分类改名的，更不是什么越给我搞复杂，好啊WP:QUALITY永远升不了指引都你害的，不能有问题不让说是不是。总之是以下几点：
  1. 页面重新命名为Wikipedia:条目质量评级标准：因为评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别（WP:QUALITY就是这么写的），那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。除非你打算搞什么甲级模板级，那不是更复杂。此外还存在Wikipedia:条目重要度评级标准，那是否要改成Wikipedia:页面重要度评级标准，总之得有一个要改
  2. 目前Wikipedia:条目重要度评级标准和Wikipedia:页面质量评级标准是正交的，所以有Category:分类级低重要度宗教条目这种东西的存在，那是不是得命名成Category:分类级低重要度宗教页面。既然分类级不属于标准评级，因此也不必设置重要度，引入更多复杂性，这类页面统统扔去Category:不适用重要度条目去（或者说Category:不适用重要度页面）。
  3. {{Grading scheme}}修改，因为Wikipedia:页面质量评级标准调用了，这个就是作为WP:指引用词统一的问题
--Kunjinkao（留言） 2024年3月8日 (五) 05:20 (UTC)[回复]
  1. 無論是前次討論還是本次討論，都沒有提到重要度，因此認為重要度的那個論述怎麼樣，並不礙於WP:QUALITY升為指引一事。
  2. 此修改技術成本過大，且認為這樣修改與否並不礙於WP:QUALITY升為指引一事。由於目前架構問題，該修改技術上的複雜性，不建議做此修改。除非有人能提出具體的patch ，否則我不支持也不相信此修改能夠被實際執行。（當然，如果有人做patch 就另當別論）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回复]
  3. 如果沒有人有異議，你可以自行修改。
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回复]
关于第一点，重要度只是顺带提及，核心是评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别，那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。--Kunjinkao（留言） 2024年3月8日 (五) 06:26 (UTC)[回复]
Wikipedia_talk:页面质量评级标准#c-Cdip150-2016-03-14T04:31:00.000Z-Liaon98-2016-03-14T02:44:00.000Z。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:47 (UTC)[回复]

第二階段正式完成後的第三階段討論

已完成當時的共識Wikipedia_talk:页面质量评级标准#總結「將不是條目命名空間的評級分類從XX級條目改為XX級頁面」，因此將安排Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引重新公示。重Ping當時參與討論的人：@Liaon98、JyunWaan、Lssrn：@Cdip150、Temp3600、Peacearth：。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月19日 (二) 10:49 (UTC)[回复]
  • 当时的讨论是专题各自评级，而现在的情况是多了通用评级（WPBS）。所以时过境迁，WP:QUALITY要重新讨论了。我之前没有参与讨论，现在有不少想法：
  1. WPBS评级是专题评级的容器，还是一套有自己标准的独立评级？现行做法属于前者：WPBS评级继承专题的评级，且受各专题各方面的干涉，因此评级原则看似「随意」。

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

    所以我的看法是，通用评级就该如WPBS模板所言，确实地「依照頁面品質評定標準」来独立评定，而不是在各专题评级间谋求公约数。可以参考专题评级，但把专题评级当爸爸就不对了😂
  2. 承上，如果我们确定WP:ASSESS本位而非专题评级本位，那就要讨论条目的WPBS该设立哪些级别？英维的PIQA是只支持FA、A、GA、B、C、Start、Stub、FL、List、Unassessed几个经典的「标准级别」。而我们的WPBS是大杂烩：既包括BL、CL这种品质向评级，也包括Future这种非品质向评级。所以WPBS评级所支持的「标准等级」该设哪些？
    • BL、CL等品质向等级有两条出路。一是如同英维，只收录广为人知的传统评级，不收录BL、CL这种额外等级；个别专题想启用就在自己的横幅上评。二是将BL、CL升格为通用评级，全体专题横幅亦自动启用BL和CL；如果个别专题自己讨论后坚持不用BL，那可以用掩码把BL改成List或B。
    • 对于Future级，一篇未来级条目可以很烂（Stub），也可以比较充实（C），那Future这个等级就没有实现「评价頁面质量」的作用。我能想到的用途是在话题中，用未来级作为宽限条目的标记，暂时不影响认定。但这个等级的确不够「通用」，或者说和条目所用的品质评级不是一个维度。
    • 对于A级条目。英维的A级在军事史专题存活（且活得很好），但其他专题都是死的。因此英维多次讨论A级的出路，比如从PIQA里开除把A级之类。但你维是真的所有专题都不评A级；所以，把这个只有理论价值的等级从通用评级中灭了挺好。
    • 上面的想法也会影响小工具的设定：包括对标准评级的契合，对各专题自定等级的支援，对非条目评级的简化（非条目空间一般人手评级无效）。
  3. 下文有提到「消歧义级条目/页面」。如果按照命名空间来理解，那就有一个问题：重定向在各个空间都有，那到底是叫「重定向级条目」还是「重定向级页面」？（或者两个都要，但这徒增烦恼）另一方面从实用性上看，专题统计「条目数」都是排除Disambig级的，那消歧义占据条目空间就成了bug而非feature 。这次从「条目」移到「页面」更像是正名，但是后缀分家无论是技术实现上还是命名统一性上，带来的麻烦都不少。考虑将后缀统一为「页」，比如品质评级这边的「乙级条目页」「丙级列表页」「模板页」，重要度那边也可以叫「高重要度页」「未知重要度页」，这样观后缀就知道是页面评级体系在整活。
我明白很多内容都不在讨论范围内，但我认为之前讨论本身就是系統性不足。比如把非條目品質評級改爲「XX級頁面」，那爲何條目品質評級和非條目重要度分類不動？是改條目和重要度分類真的弊大於利，還是單純沒有討論過而已？作爲這套系統創始者，英文版的非條目還用articles的，個中原因是否值得參考？ --For Each element In group Next（留言） 2024年3月19日 (二) 16:05 (UTC)[回复]
爭議已消失：
上述爭議因進一步討論已展開，因此可以視為爭議已消失-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月1日 (六) 10:55 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
@For Each element In group Next：老實說我真的不懂你們這些這時候再來提意見是用什麼心態再看事情的，這個提案已經放超過三個月了，又不是放一個星期就說要公示，硬是等提案要準備收尾才來提意見是怎麼回事？！我可以當成你是打算擾亂干擾提案通過嗎？！--SunAfterRain 2024年3月19日 (二) 16:40 (UTC)[回复]
我几年前的主业之一就是评级理论。Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引6年前甚至6个月前，我都会像推动MOS:FICT那样，亲自提出修改意见和方案（如WP:QUALITY第二段不符合新形式），让WP:QUALITY成为更优质的指引。但现在评级方面，我认为和这个装睡的社群去合作没有什么意义。所以我的做法就是不发言，看着这个社群未来到底走向哪里。出于对当初理想的怀念，我写下了这些明者自明的意见，但也仅此而已了。通过提案无非就是页面多个「指引」的标签；您看我用户页，就该知道我对这种「社群众评标签」有没有兴趣了。--For Each element In group Next（留言） 2024年3月20日 (三) 16:36 (UTC)[回复]
@For Each element In group Next：我不管你到底對這個議題有沒有興趣，反正你現在的意思是上方內容純粹是發牢騷你沒有要干擾這個提案？！--SunAfterRain 2024年3月20日 (三) 17:12 (UTC)[回复]
還沒有細看，但我對洛普利寧君遭到這樣的對待感到很悲哀。--Temp3600（留言） 2024年3月20日 (三) 17:43 (UTC)[回复]
在有用的討論串下面離題吵架實在無奈，但似乎VP環境已經如此。
WP:CON明確指出"共识应采纳多数人的意见，并和重要少数的意见作出适当妥协。"、"共识在维基百科是持续不断的过程"，對於方针修改，更再次明示"共识最终将根据支持和反对该议题的论点质量所决定"。方針中沒有任何字眼要求討論應"收尾"，反而暗示了討論本身是可以無限延長，以不斷修改共識更貼合實況的。所謂擾亂更是莫名其妙。
回到討論本身，如果有足以反駁洛普利寧君的理據，直接提出來就可以。如果反駁不了，甚至根本沒有考慮到這一討論角度，那顯然就說明"之前讨论本身就是系統性不足"，提案一方存有思考盲點，應該進一步討論下去。
回到這個提案。我與八年前一樣，支持將WP:ASSESS建立為指引。然而，洛普利寧的問題必須先得到回答:维基百科:通用評級與维基百科:页面质量评级标准之間有潛在矛盾。通用評級到底是獨立的評級系統，還是專題評級的平均分?我對這兩者沒有特別的見解，但WP:ASSESS應該清楚指明這一上下級關係。
如果不幸某頁面只有一個專題，而這個專題將頁面評為"未來級"等奇怪級別，通用評級是否跟隨?
請賜教。--Temp3600（留言） 2024年3月21日 (四) 19:45 (UTC)[回复]
@Temp3600：那我倒覺得您來主持好了，包含修改模板模組的部分，反正您看起來很閒可以泡在客棧陪大家一直耗。--SunAfterRain 2024年3月22日 (五) 01:35 (UTC)[回复]
  • 折騰了三個月，我已經沒有修改評級模組的心力了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月22日 (五) 01:52 (UTC)[回复]
  • Special:PermaLink/81985508#第三階段：完善制度這裡有說，一切以维基百科:页面质量评级标准為主，當專題評完後，维基百科:通用評級再取各專題WP:ASSESS的公約數，不認為有矛盾。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月22日 (五) 02:00 (UTC)[回复]
    • @A2569875：如果方针是FA级，指引是GA级，那现行WP:QUALITY+维基百科:通用評級大概只有C的水平，还需要很多工作完善：
      • WP:QUALITY说「评级主要由专题进行……」。那WPBS评级人是作为什么身份评的？社群成员，还是专题成员？现在WPBS开展一段时间了，相信大部分人的评级逻辑是直接对WPBS评级（而不是专门针对各个专题）。这就和「评级主要由专题进行……」矛盾。
      • 有了WPBS后，就有了「社群心目中的评级」，这个评级就是WPBS的评级。这样，大部分专题出于信任社群/懒得评级，而继承了通用评级。对于旧页面，现在的做法很好——假定WPBS评级为各专题评级的公约数。不过这个做法并非必然，我们也可以取各专题的最高值/最低值，只要社群愿意信赖专题。例如英维只有WP:MILHIST真正地在评A，而其他专题是评GA或者B，此时一个做法是取A，而非众数或向下取GA/B。
      • 但是下面的问题理论上和执行上都很成问题。例如维基百科:通用評級第5点要求「例如未啟用乙級的專題，通用級別遇到規則3判為乙級的情況時，則向下填寫為丙級……」。
        • 首先，很难判定专题是否启用某个级别。机器人运行者好像都说过做不到这个事情，就更不用说人工评级了。
        • 其次，如果B级是标准评级，且多数专题都评B级，那这个条目在社群心目中就是B级。我们不应该迁就特例独行的专题，否则公认的B级条目评C，那B和C还有什么可比性？应该是说，不设B级的专题应该自己收拾自己的摊子，例如专题评级继承B而表示为unassessed，或者用掩码改成C。
        • 第三，现在的BL是标准评级吗？如果不是标准评级，那应该呈现在社群通用的WPBS上吗？如果呈现在WPBS上，多数编者没见过BL，他们看得懂吗？如果你认为大家能看懂，且乐见对列表细致评级，那不如将BL升格为标准评级？如果升格为标准评级，就应该预设对所有专题的class mask启用BL，否则又回到上一点专题「特立独行」的老路。
      • 只有一个专题评Future，那WPBS技术上当然可以评Future（且只能评Future）。但上面BL甚至D级都是品质导向级别，那Future和他们并列（而不是attention之类的flag）是什么用意？还有，如果两个专题一个是CL，另一个是Future，而且两者都未设对方的级别，那WPBS到底听谁的？
      • 上述问题可以不断打补丁解决（维基百科:通用評級就是打补丁的成果），但这并非良方。大道至简，最实际的方法是：编者以社群成员的身份，以WP:QUALITY的标准评级中的选项为依据，针对WPBS评级。专题评级理论上和WPBS独立，但实践上的评级方式是信任社群评级。然后，我们讨论WPBS具体该支援哪些级别——对于条目，我建议支援传统级别，或传统级别+BL/CL/(SL?)；而Future、Merge不属于品质评估，而A级又极不活跃常常被人误解，这两类可以考虑从通用级别中除去。至于要修改的地方，无非就是修订WP:QUALITY、WPBS支援代码、class/mask预设启用代码，就像您说的，要改很简单。
      • 您可能看不懂我的留言，也可能看懂了但没有观点。建议您和有实际开设特殊级别的专题联络，看看他们的意见。我可以写出蓝本，但我不想干涉这件事情，也不想在这个物是人非的地方留言。
    • @SunAfterRain：我可以當成你是打算擾亂干擾提案通過嗎？！。当然可以！您怎么想是您的权利。--For Each element In group Next（留言） 2024年3月22日 (五) 16:26 (UTC)[回复]
      你以為你維的評級模組是Module:Namespace/data這種隨手改一改就好的是吧，改一次的成本有多高您可以自己改看看，不是什麼看起來很簡單改一改就好--SunAfterRain 2024年3月23日 (六) 03:13 (UTC)[回复]
      我2015年到2016年大幅更改过WPBM相关子模组，比如引入bchecklist。而且如果WPBM不能满足我的需要，我也有能力手写模板。我固然不是A2569875那样的技术专家，但我也知道那些内容属于微调，哪些内容属于重炼。（那时候您似乎还没注册，如果您问一下八九年前一些关注评级的老用户，您大概会知道我都干过什么）
      上面的问题我早在两个月前就A2569875君交流过。当时他表示现在只讨论技术问题，具体制度问题可以后议。我的意见不是技术问题——等真正的技术修改部署后，对WPBS屏蔽某些等级就OK——所以的确可以后议。A2569875当时态度很激烈，我不想影响他的心情，而且他应该是没有看懂我的意见，所以我就没有继续争论下去。另一方面如果我做主导人，和议案有关的问题无论在发哪里讨论，我都会接受；而A2569875的思路就是a讨论页不谈b问题（我不知道这是不是今日你维的讨论规矩）。我们俩电波对不上，我也不想在客栈留言，所以就直接走了。现在的论题正是「第三階段（WP:QUALITY_升為指引）討論」，既然是讨论（而不是走形式直接通过）那我充分陈述我对WP:QUALITY的看法很合理吧？而且讨论3月19日开始，我也没有拖到26日要结案的时候发。
      就我看来，应该一开始就讨论WP:QUALITY评级这个哲学问题，讨论好方向之后再开始技术修改。而且有了修改体系背书，A2569875的技术修改也能一路绿灯，不用喊「折騰了三個月，我已經沒有修改評級模組的心力了」。不过中维人少，评级哲学上确实没几个人能想到这么深；就像技术方面没A2569875，其他人也推不了这个提案。最后我认为本站应该以理服人，而不是靠方针指引或没讨论深度的「共识」堵嘴：能指出问题的内容标上指引也是根基不牢，有道理的论述没有标签也应该令人尊敬。--For Each element In group Next（留言） 2024年3月23日 (六) 05:29 (UTC)[回复]
      別為你不參與討論找藉口，電波對不上不代表就可以事後再來批判，你說以理服人光是你用這個理由我就覺得你服不了人了
      另外你覺得你的意見不是技術問題但事實就是改動不小的技術問題，光是要改動一個分類就要牽涉到多少模板模組了--SunAfterRain 2024年3月23日 (六) 05:49 (UTC)[回复]
      您的考虑方向我很赞同。不过如果例子举成「改动一个模板就会牵涉多少分类的移动」，那会更有说服力  --For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回复]
      你到底在舉什麼...--SunAfterRain 2024年3月23日 (六) 07:28 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
  • 首先感謝宇凡君的努力，您辛苦了。順便說一點離題得罪人的話：
  • 目前的問題如要解決，通用評級指引勢必重寫。問題只是要怎樣重寫而已。說白了，洛普利寧是反對通用評級的“由下而上”邏輯，再深挖下去，涉及專題組與社群整體之間的互動問題，對應現實生活中的中央－地方政府間，集權－分權的沖突。這樣展開就顯然太複雜了，我只是希望指出為什麼洛普利寧會認為這個指引寫得不好。
    回到維基。儘管從憲法的觀點出發，確立各子組織間的權力分立應是建立規則的第一步，但考慮到中文維基並不怎麼關注這一問題，我就建議維持現狀好了，省得麻煩。反正即使是下而上，要修改專題評級，直接一起修改所有專題的評級就可以（顯然這就一次侵犯了數個專題的自主權，但上面說了，中維人這方面的理解力有限）。下而上的（理論上）優勢當然是“各專題組可以按各自所擅長的領域，共同對跨領域的條目進行評級，會比WPBS只用一個評級員來得準確”。實際上嘛，就是懶得改。
    “WPBS评级人是作为什么身份评的”：從下而上的觀點而言，沒有專題組的條目評級，算是社群託管了該條目，留待專題組前來接收，等價於聯合國託管理事會。最終還是需要專題組的專家前來正式評級。
    "标准评级":基於減少修改範圍（懶）的因素，建議只容許使用“标准级别”來評級。也就是說，暫時放棄將BL／CL加入WPBS，待更多專題啟用這些評級，更為人所熟悉後，再來討論。future等評級則不容許更新到WPBS上去，機械人應視這些條目為“沒有評級”，由人類前來處理。
    最後，感謝@For Each element In group Next：前來，指出這些要點供大家討論。說實話我本來也不想發言的，打了這些東西花了我一個多小時。也希望你能與我一起堅持到這項修改完結。
    以上。--Temp3600（留言） 2024年3月23日 (六) 03:33 (UTC)[回复]
    如果硬要扯開這個話題，我反倒支持廢掉所有專輯的質量評級全部統一處理，因為你維專題參與人數實在少到除了幾個大專題之外沒有辦法給出一個真的符合自己專題的評級標準，而且去查大專題的評級標準實際上也與通用標準沒有差異，那這樣給各專題評質量有什麼意義？--SunAfterRain 2024年3月23日 (六) 05:54 (UTC)[回复]
    （以上沒有要廢掉重要度評級）--SunAfterRain 2024年3月23日 (六) 05:56 (UTC)[回复]
    如果完全廢除專題評級，將權力上移給WPBS，那就算不談這種集權行為是否影響了專題組的自治，也需要將目前已經由專題組評級的條目改為WPBS格式，並處理評級不一致的問題。我是不太看好能搞定啦。--Temp3600（留言） 2024年3月23日 (六) 07:10 (UTC)[回复]
    @Temp3600：感谢您的解释！虽然讨论很不愉快，但至少讨论者都能理解我要引出的思考点了。现在我的任务大功告成了 --For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回复]
    喂喂，不准跑掉（ --Temp3600（留言） 2024年3月23日 (六) 07:14 (UTC)[回复]
    所以你知道為甚麼我說他明顯有意擾亂了吧（攤手--SunAfterRain 2024年3月23日 (六) 07:26 (UTC)[回复]

隨意的分段

  • 另外回應SAR的是，技術人員與行政官僚本身就是兩項不同的工作，互相批評在我看來並無意義。nerd的下場，可以參考為什麼蘋果公司會趕走喬布斯。--Temp3600（留言） 2024年3月23日 (六) 03:37 (UTC)[回复]
    • (：)回應：@Temp3600：最初的提案是Wikipedia:互助客栈/其他#沒有主題的頁面如何評級。起因是我遇到有條目不屬於任何專題，所以如果要評級，會有困難。（所以，我的動機很簡單，我本來就只是在寫條目，遇到了一個問題，我來客棧討論解方，結果折騰了三個月，途中不乏某些維基人精神攻擊，提案看起來快擱淺，精力消磨沒了，寫條目的動力也沒了。在本案開始之前，我一個月寫十幾個條目，本案開始之後，三個月我只寫了兩個條目。）。關於該問題由MilkyDefer給出的解決方案是修改{{WPBS}}，於是開始討論共識並執行，以及其配套的《評級系統缺失案》甚至還因技術需要跑了幾趟phab(如phab:T360012)。因為最原始的目的《沒有主題的頁面如何評級》，代表其討論頁會放置空{{WPBS}}，也就是沒有任何專題的{{WPBS}}，所以當然要能支援填寫所有評級級別，包括但不限於非標準級別（為此，我還特地翻過所有專題、所有維基百科上出現過的評級級別，統整出所有專題定義的所有級別，大概40幾個）。而當{{WPBS}}如果開始填入複數個專題，{{WPBS}}如果又要限制能填寫的級別，程式邏輯勢必變得複雜，所以我的解決方案是不改程式（你知道的，改全保護的程式不是那麼簡單），改立WP:通用評級指引制約，如可能也把評級系統的不同步級缺失補齊，其實目的也就只是《沒有主題的頁面如何評級》而已。而只是恰好Kanashimi要跑評級機器人，所以我索性再修改一下程式，跑客棧共識+公示流程，雖中間與Z7504發生爭議（其實消耗了我非常多精神）但最後都通過了，而「去match Kanashimi機器人」這部分其實已經超出我原本想編寫的程式內容了。後續所有技術案都通過了（過程中洛普利寧在客棧中不發一語）所以程式碼當然不會包含他所期望的部分啊。維基百科是志工性質，不強迫任何人參與，既然我已經寫好我想寫的程式，那我為何還要在最後「可能」可以收尾的時候，幫「洛普利寧的理想」寫程式？程式技術不難，但全保護和繁雜的評級系統，加上客棧不時出現精神攻擊，說實在我的精力已經耗盡。我提供的任何一段程式碼都沒有拿到任何薪水，純粹就是最初我想做、我想解決某些問題，但像現在這樣節外生枝是否生得太誇張了？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月23日 (六) 04:13 (UTC)[回复]
    我想，在洛普利寧的心中，他在最初就已經您解決了你的問題：維基百科有一個萬能專題{{WikiProject Article assessment}}，你只要將沒有專題的條目通通添加到這個專題下就可以，問題立刻解決，不需要碰WPBS。我也認為這是最簡單的方法。只需要跑一次機械人，把所有沒有專題的條目全部加入WikiProject Article assessment，就可以了。
    順便一說，我自己也試過幫助條目找專題，但即便有新rater的協助，仍然很難。最大的問題是，我不知道有那些專題存在，又不知道他們的簡寫。如果宇凡你能改良rater，讓程式可以搜尋，甚至推介專題給我來選擇，會很有幫助。比如有一個英國足球隊條目，但還沒有專題，但分類已經寫了這是英國條目，rater能不能夠提示我加入英國專題（或者別的甚麼專題？）。
    如果不行，可以考慮一個簡單一點的修改方案：當條目沒有專題時，rater預設添加WikiProject Article assessment，就可以照常評級了。
    但現在WPBS已經生出來了，總不能走回頭路。但這個也不容易，一會兒再寫。--Temp3600（留言） 2024年3月23日 (六) 04:47 (UTC)[回复]
    @Temp3600：這完全不是什麼兩種不同工作的問題，有意見之前重寫模組時一起納入考量重寫就好，那時候提出我想娜娜奇也會盡可能配合的，但洛普利寧同學是喔我支持改寫，人家寫完都開始運行了再來抱怨。不要跟我說什麼滾動式修正，他提出的意見很顯然不是因為模組上線才出現的。--SunAfterRain 2024年3月23日 (六) 05:38 (UTC)[回复]
    然後回到“Template_talk:WPBannerMeta#編輯請求_2024-01-08”。洛普利寧的批評是對的：宇帆在這次重構中，只考慮了技術層面上如何實行WPBS的改版，忽略了行政上的架構問題：所謂通用評級，由於每個條目只能有一個，客觀上就有壓倒原來專題評級的意味。於是這就進一步產生了通用評級與專題評級的沖突，新建立的WPBS機關在權責上如何與原來的專題委員會劃分的問題。現在那些WPBS有沒有CL級，未來級的問題，本質上都是沒有完成項目定義就急於進入開發階段，結果現在開發成果不完全符合要求，但是要再更改，工作量又很大，於是卡住了。
    所以現在還是要回到那個編輯請求，解決掉1月時的問題。然後由於技術負債，問題要盡量靠行政程序解決。這就是目前的工作。
    宇凡那時的觀點，也不能說錯，畢竟維基百科也沒有技術可以阻止你發侵權垃圾內容對不對，但是我們有行政手段，有制度可以將侵權內容透過刪除頁面功能處理掉。我估計這邊最後也會採用相同的方向，WPBS模版支持很多參數，但在指引中，會指明只有部分參數才可以合法使用，如果用了其他值，即使能夠正常顯示評級，其他人也可以回退，警告這一套。--Temp3600（留言） 2024年3月23日 (六) 08:43 (UTC)[回复]
    • @Temp3600：問題就出在於，最早MilkyDefer的起草就有未來級、CL級等等，然後我還Ping了洛普利寧問他這樣可不可以，但他完全沒有任何答覆，到頭來還是只有一句「精神上支持」，我怎麼知道問題在哪，直到一月開發完成才開始說這裡不對、那裏不對，這樣我是要怎麼搞。反而User:Willy1018事先指出了具體問題，我得以依照他的問題在開發階段先行解決，並讓User:Willy1018說出了「感謝貢獻，目前已覆核已符合預期。」。完成後才再修改成本比較高，一開始又不講清楚，說完「精神上支持」然後跑掉，然後現在爭議後要叫我扛責任。我這樣消磨掉的精神狀況可能需要去放維基假期了-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月23日 (六) 09:00 (UTC)[回复]
      A2569875：首先向您道歉，我没有及时回复您的提醒，在1月份的讨论中，我也没有坚持将意见表达清楚，因为我认为您将来会用掩蔽代码的方式处理WPBS评级。我也知道了为何SunAfterRain君会将我提报到破坏区。其次感谢您完成了迄今所有的技术工作。我的意见是针对政策层面，亦即评级体系如何开展。我不参与客栈讨论，亦不会干涉指引讨论的工作；因为很多等级都是我带起来的，我这次只提出我的想法，希望让社群自行讨论如何评级等级。如果讨论结果是敲定启用或不启用某些等级而需要修改模组，而您疲于修改模组，我可以参与技术工作吗？最后就像Temp3600君所言，在下确实有责任。--For Each element In group Next（留言） 2024年3月23日 (六) 09:40 (UTC)[回复]
    (＋)支持User:Temp3600提的：不當使用WPBS參數時，其他人也可以回退，警告這一套。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月23日 (六) 09:11 (UTC)[回复]
  • 如果能夠masking掉WPBS旳等級，待日後成熟等再開啟，那自然是最好；不行的話，單改指引也算是解決了問題。--Temp3600（留言） 2024年3月24日 (日) 03:25 (UTC)[回复]
  • 另外拖@MilkyDefer：出來，future grade 條目要直接沿用還是怎樣處理(pia!) --Temp3600（留言） 2024年3月24日 (日) 03:33 (UTC)[回复]
    什么叫沿用？事实上我连现在future grade的使用情况都不是很清楚，可否说明一下背景信息？--MilkyDefer 2024年3月24日 (日) 03:55 (UTC)[回复]
    @MilkyDefer：例如en:Talk:Texas_State_Highway_32按你的構想，是什麼評級。背景資料....按我很初步的認識，英文WPBS的條目評級系統只容許BCStub等標準評級，但專題組可以按各自需要將條目評為future級等特殊等級。這與目前WP:QUALITY中建議的評級方案並不一致。--Temp3600（留言） 2024年3月24日 (日) 04:05 (UTC)[回复]
    有什么……不一致吗？Future Class列在非标准等级下，并且写有“部分專題還會啟用附加等級。”看上去挺一致的欸。--MilkyDefer 2024年3月24日 (日) 04:36 (UTC)[回复]
    咦我寫錯了...en:Talk:Texas_State_Highway_32如果按维基百科:通用評級，它下面只有一個future-class的專題評級，那麼就不能評為stub.在我看來這是問題。--Temp3600（留言） 2024年3月24日 (日) 05:01 (UTC)[回复]
    en:Template:WikiProject U.S. Roads列在en:Category:WikiProjects using a non-standard quality scale，因此此篇文章的評級沒問題。我覺得WPBS的評級主要是條目整體評價，在zhwiki實施起來基本上也是這個目的。只不過 zhwiki評級似乎比較複雜，所以允許各專題自訂標準，每個專題模板都算non-standard quality scale。這部分實施起來，其精神與enwiki也相同。--Kanashimi（留言） 2024年3月24日 (日) 05:12 (UTC)[回复]
    按英文版的評級方式是沒有問題，但來到中維，维基百科:通用評級並不是英維的對等翻譯。於是就有了"若一條目僅有一個專題，其通用評級應與該專題所評的等級一致。"這樣的條款，影響到WPBS專註在內容評級的工作。順帶一說，這一點也和LP為什麼建議全面轉用英維制度，將內容評級由專題組上提到社群的精神一致。不過這樣就涉及更複雜的改動，恐怕還是免了。--Temp3600（留言） 2024年3月24日 (日) 05:30 (UTC)[回复]
    我個人覺得這一條僅限於單一專題模板採用標準評級的情況下才有效。但假如所有專題模板都屬於 non-standard quality scale，則不如廢掉。--Kanashimi（留言） 2024年3月24日 (日) 05:49 (UTC)[回复]
    • @Temp3600：我覺得像Future、Current（某主題是否是新聞事件或未來事件完全取決於專題領域，例如某主題在A領域可能是一件大新聞，所以評Future，但另一個領域關它屁事所以評甲乙丙丁初之一）Merge、Need（這種通常都是向特定專題請求重定向擴充為條目的標記，無關專題就標通用評級的  重定向级吧）這些「聚焦於特定專題」的級別就讓相關的專題沿用吧，然後從通用評級的標準評級撤下變成非標準評級，我想問題應該就解決了。修訂的部分，我想等到下面確立哪些要設為標準評級之後，再將通用評級指引加上「只能用標準評級」之類的規範應該就能從行政手段解決了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月26日 (二) 17:36 (UTC)[回复]
  • 另另外我約略看了一下英維，看來它們已經將各專題評級整合起來，會個條目只有一個評級。這是你提出由上而下的背曔原因嗎?@For Each element In group Next：--Temp3600（留言） 2024年3月24日 (日) 03:38 (UTC)[回复]
    我也认为WPBS是社群基于标准（WP:QUALITY）对条目做出的评价。当然，社群也允许专题依照自己的标准对条目做出评价，并标记在讨论页上。某种意义上，社群评级和专题评级是「人格独立」的，这里的「上」和「下」更像依赖的上下游，而不是官大一级的上下层。然后既然专题评级是独立的，那专题就可以选择各种策略：
    • 社群人多力量大，自行评级太繁杂，WPBS填啥我填啥。（看起来就像评级被废了，但其实是选择和WPBS的做法一样）如果对专题成员评级不服，要么以社群成员身份找社群吵，要么推动专题退群。这就是英维绝大部分专题的策略。
    • 预设继承社群评级，但也可以自行覆盖社群评级。这就是我们现在的状态。
    • 不继承WPBS的评级，只要自己的class不填就是未评级。英维的退群专题（比如有BL的WP:MILHIST、没A的WP:VG）都是这个策略。不排除有些专题是想自己搞；但也有专题是只开除掉A级，其他等级想继承社群，但因为英维技术不支持策略2而被迫退的。
    像SunAfterRain说的，绝大多数专题用策略1就够，而且理论上标准相同的专题应该评同样的等级。个别专题有特殊的评级标准，那就采用策略2。真有专题完全不想社群插手，那就上策略3。策略1那就是纯粹的自上而下了。此外，对上游的WPBS规定好标准等级后，将非标准等级映射到标准等级（假设规定BL->List、D->Start、Current->Unassessed），也可以让机器人参考策略2和3的专题填WPBS。
    自下而上主要还是一堆奇葩等级，逻辑上没法搞。刻度尺测量物体长度，得到的结果应该是稳定的；一次测3 cm、一次测5 cm，就说明测量错了。但如果两次测量都操作无误，那你用的大概不是尺子  WPBS本来评CL，因为来了个不支持CL的专题就改评List，两次评级都没有错，这就说明该制度不适合衡量条目品质。如果将奇葩等级改成WPBS标准评级，或者拒绝参考非标准等级，那这个制度就可行；但这基本就又成了上面的问题。--For Each element In group Next（留言） 2024年3月24日 (日) 16:21 (UTC)[回复]
  • 先多謝各位，意見都很有見地。希望在上方再拆一個小標題。A級與GA的問題是老大難了，我想這次還是先不處理為好。A級雖然很少用，但一直都算是標準評級，現在一下子移除不太好。List級對等於初級列表長遠是好主意，但要標記清楚，因為許多舊列表是list級。所以現在list級代表初級或以上的列表。或許長遠要建立start list?—Temp3600（留言） 2024年3月25日 (一) 23:35 (UTC)[回复]

D級與B+級等標準討論

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

  • D级目前看来只有宇帆君活跃的多面體在用，其条目是介于C和Start之间。讲真，流行文化领域，因为关注粉丝向这种扣分内容，D级还是很好用的。
    • 比如明星条目，内容上已经有C级该有的内容，但因为很多内容都以粉丝介绍口吻出现，需要大量清理和改写；这时评Start太可惜，就可以评D级。这基本就像多面体专题说的，「内容上可能达到C级水准，但其他方面有严重缺陷」。或者说，写条目的人擅长事实性内容，但不了解这里的格式手册，写出的东西很随意不像百科。
    • 另一方面，虚构作品条目也强调要写反响等现实世界内容。一般来说，编者不写现实世界内容，就表示他不熟悉格式手册，所以条目格式、行文等方面也不会太好。这种条目又要清理又要扩充，就可以给Start。但也有从英维FA翻译一半的，条目序言完整、作品介绍也很规范，但该到制作历史和评价，他又他不翻译了。这种只用扩充不用清理的，也可以从Start抬升为D。
    • 可以看到，流行文化领域这个D级主要还是可以彰显「内容杂乱/格式差」。但科学等领域大概没有「粉丝内容」，所以这个D级通常会怎么用？
    • 另外有了D，是不是未来有可能对等增加DL？
  • B+只有英维数学专题有用过，而且现在删了；本地没有专题实装过，只在一些理论研究中提到，所以还是要想想标准怎么订。
    • 之前B+的评级标准是「条目高于B级标准」，再把B级标准抄了一遍，这就比较不良定义。GA和B的区别主要在GA还要求中立性稳定性，且文笔和格式的要求高于B。如果要搞B+，那标准大概就是「不要求中立性和稳定性，但其他方面同GA标准」？PS：B6提到的WP:JARGON和地区词在GA标准里没有体现，所以B在某些方面还高于GA；不过现在的英维已经把JARGON要求增补到GA标准里了。
    • 之前有提过增设优良列表（GL）。GL和FL的主要区别可以理解为GL不管红（绿）链，且序言不用太优美；这个境界就有点像B+和GA了。不过，FL和GL应该是要有本质差异的——类似WP:GVF的comperhensive和board coverage。例如对于游戏系列，FA应该像死忠那样列出小众改编作品，而GA可以只列出重要作品。（但是很多领域列表是不是没有这种问题？）
  • 小小作品更像是一个临时状态，和未评级一样是不该长期存在的。而且小小作品只是长度短，问题还没有广告、侵权等小作品更严重，所以整体统计上把小小作品拆出来的意义是？从维护追踪角度考虑，WP:PETSCAN或者Shizhao的专题机器人通告应该都很好用了。--For Each element In group Next（留言） 2024年3月26日 (二) 15:50 (UTC)[回复]
  • （有感而發）除了本子節開始的爭議外，以上討論與研究其實都滿有意義和價值的，如果能提前在去年十二月，也就是我當初Ping了洛普利寧時，他就發表了這些意見，並開展了我們現在所討論的東西，那我覺得WPBS應該會更完美。不過現在說這些都是後話了。另，跟大家說聲抱歉，我當時一心只想著如何把MilkyDefer起草的臨時方案開發成正式方案、如何pass所有testcases 和解決討論頁上各種問題回報（1、2等），一切考量都以技術為優先（我當時優先級最高的考量是：程式怎麼寫更省效能，於是出現了mw.loadData("Module:PJBSClass/page")用於讓該功能在整個頁面解析的過程只會跑一次，而不會每次調用通用評級時都跑以節省效能），卻忽略了行政上的執行問題，而導致了今次的爭議，我感到十分抱歉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月27日 (三) 01:30 (UTC)[回复]

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

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

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

WPBS級別列表

目前{{WPBS}}能接受輸入的級別大部分都是phab:T360012向P站登記的級別以級在案《第一階段：修正評級值不同步問題》時所有評級Data模板統一同步更新的評級值列舉如下（共50個。此外由於表格過長，已折疊。請單擊[顯示]以展開表格）：

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

以下建議供行政組參考：

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

等級標準小結

洛普利寧在上文提到的「PJBS之PJBSClass.getClassByPage()」自動評級（小勘誤：自動評級實由PJBSClass/main.getClassAuto()和PJBSClass.getAutoClass()共同完成，前者以頁面狀態和掛有模板判斷、後者只看Namespace），這些評級會根據頁面掛的模板、子頁面名稱、頁面狀況和所在命名空間等進行自動評級。這些評級分為兩類：不可被|class=參數複寫的評級以級可被|class=參數複寫的評級。
這些級別有：
  • 不可被|class=參數複寫的評級：  重定向级、  特色图片级（註：|class=有值時會強制被改為File級）、  模板级、  模块级、  分类级、  文件级、  草稿级、  主题级、  专题级、  用户级、  使用说明级、  界面级、  非条目级
  • 可被|class=參數複寫的評級：  典范级、  特色列表级、  优良级、  小作品级、  沙盒级、  列表级、  同类索引级、  消歧义级
上文提到，目前不在WP:QUALITY中的級別都需要補上文檔，因此我起了以下草稿供參考：
（註：如果有需要修改可以直接編輯本表格，無須經過我的同意(不被視為修改他人留言)）
（註2：下表只列出目前未出現於WP:QUALITY的級別）
（註3：由於表格過長，已折疊。請單擊[顯示]以展開表格）
預計種類分成三類：標準級別（描述條目品質）、標準類別（描述頁面種類）、非標準級別（專題自定的東西）
@Temp3600：您看看這些資訊對行政組作業有沒有幫助？（請單擊[顯示]以展開表格）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月5日 (五) 10:48 (UTC)[回复]
感谢宇帆君的总结。我大胆做了一些调整，说明如下：
  • Bplus之于GA类似A之于FA。A级的标准和文档页指出要走比较正规评审，类似这种，而不能像评B、C那样随手改|class=。所以Bplus的要求中我也提了要做评审；不过这也就是这么一说，大家肯定还是会随手改的😂。另外A级开始才算专业，GA只能叫接近专业（我上面说的，英维A级需要专家来评审，而GA不需要），所以调整了一下措辞。
  • D级还是可能有格式问题的，基本上B级才算比较遵循格式手册，连C级可能都差一点，而且爱好者内容广义上也算格式问题。其他方面调整了一下语言，大体是说条目内容方面有含量，但其他方面比较差。
--For Each element In group Next（留言） 2024年4月5日 (五) 13:54 (UTC)[回复]

頁面評級與通用評級指引調整

    • 非常感謝娜娜奇。但我因為現實原因(pia!)暫時不能積極參與討論。我預計會於19-21日的週末發言，這段時間麻煩諸位了。--Temp3600（留言） 2024年4月12日 (五) 11:29 (UTC)[回复]
      • 約略看過沒有問題。在格式上有一點想法: 每個類別還是找一個例子，當參考。另外，會否用Template:Guideline section，只將標準評級立為指引會較好?如果專題組日後創立新評級供內部使用，便無須經VP共識修改評級表，而可自行加入。不過倒過來，如果自行加入評級會弄壞模版，那麼還是經VP討論，協調好再修改較好。這方面我不清楚，請給意見。--Temp3600（留言） 2024年4月12日 (五) 11:58 (UTC)[回复]
        • @Temp3600：屆時，如果確定該等級都標準化的話，僅需要將{{Class_mask/core}}中，目前還沒標準化的級別做「開放」即可（不必改程式，只要改類似config(設置)的東東），而專題自建級別已有相應功能，無須動到核心模板，範例見{{WikiProject_Example}}，因此完全無需更動本次系列模板/模組或任何程式碼的核心，故自行加入評級不至於會弄壞模版。常見的專題非標準評級我覺得可以在WP:QUALITY提，在章節標題標註「本段不是指引」應該就可以了，就不必走VP共識了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月12日 (五) 15:49 (UTC)[回复]
          • 先抱歉晚了許多上來...生活艱難QQ。
          • 如果如此，那麼标准级别一節立為指引就可以，並在非标准级别一節清楚列明專題可以如何自行加入新評級(好像在模版說明裏已經寫好?那麼就只需要提供連結)。--Temp3600（留言） 2024年5月5日 (日) 07:27 (UTC)[回复]

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

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

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

  • en:Wikipedia:Content assessment 有較多的內容，我認為這是因為他們是這個制度的來源地，所以有關於制度的歷史流變等可以寫。中維目前只是引入的制度，還沒有社群的經驗，因此沒有這部分的本地經驗可以立為指引，而只能寫一些硬規定。我認為這暫時不是問題，如日後成熟，自然可以再將這些段落引進，指引名字也可以更改。「页面质量评级标准」就暫時只寫標準，待评级流程成熟後，就可以加入這一部分的指引。
同意將「标准质量评级」與「標準類別級別」分立為兩個三級標題。這是一項不涉及本質的結構修改，不難。
流程图最好有，但要有人來畫...

「通用评级」与「专题评级」的关系:這是我最早就想改寫的部分。既然「通用评级」只可填標準評級而專題評級可以填其他自訂評級，那麼维基百科:通用評級就需要至少修改"若一條目僅有一個專題，其通用評級應與該專題所評的等級一致。"，最好是重新理順這一部分的邏輯。

整理目前的討論，建議"機器人會根據該頁面最多專題評等的評級等級作為通用評級"繼續保留，但機械人應檢查這會否導致WPBS被評為非正式級別，如發生這種情況，那麼機械人則跳過該條目(可以考慮加入"需要手動進行WPBS評級"的分類)，留待人類前來。
同意"社群和专题都可以各自独立地对页面评级"的基本策略。這樣就解決了list級的問題。即使專題的評級只有list級，WPBS仍可以手動評為更準確的CL/BL等細分級別。由機械人自動評的list級也與這個邏輯沒有沖突。
長遠的最終方向是，WPBS作為條目的內容評級，專題評級則為某一方面提供額外的資訊，類似tag.但這個需要將目前的評級邏輯反過來，我猜一兩年也無法完成，就寫在這而已。--Temp3600（留言） 2024年5月5日 (日) 08:10 (UTC)[回复]

修訂案

维基百科:通用評級
  • 解決「通用评级」与「专题评级」的关系。斷開兩者的上下級關係。
  • 通用評級只限填寫標準評級。
  • 介紹一些其他功能，例如專題可以自行加入評級，不過這些不屬於WPBS的範圍，將它們指示到其他頁面去。
维基百科:页面质量评级标准
  • 對應通用評級的改動，明確兩者間的關係。即: QUALITY負責規定那些級別屬於標準評級，及提供評級的參考。也提供其他非標準級別的介紹。通用評級指引則負責通用評級的流程，由社群負責，為條目的質量提供評級，而專題級模版級等請不要來找WPBS.
  • 結構調整，將「标准质量评级」與「標準類別級別」分立為兩個三級標題。
T: Grading scheme
  • 為所有標準類別補上例子。

似乎除了這筆移動外沒太大進展，那我就先寫個Draft:页面评级吧。T:Grading scheme的例子就沒辦法了，甲級估計社群這輩子也評不出來（現在的Talk:家牛也沒找到評審在哪）😂 --For Each element In group ... Next 2024年7月10日 (三) 17:45 (UTC)[回复]

後續討論

关于 rater.js 脚本

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

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

Unblock-zh.org

 
Unblock-zh.org网站的样子

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

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

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

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

试运行

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

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

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

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

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

@Bluedeck：請問IPBEG們可以如何存取工單？--路西法人 2024年7月10日 (三) 03:25 (UTC)[回复]
@LuciferianThomas：我正在编写为IPBE权限持有者提供权限的功能。完成后，IPBE将获得和管理员基本一致的功能。目前编写的功能是对于下方讨论中方案一的实现。编写完成后，我将会在用户讨论页面通知IPBEG权限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)[回复]
@Bluedeck：能更新進度嗎？--路西法人 2024年7月22日 (一) 02:49 (UTC)[回复]
@Bluedeck：預計試行多久？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:44 (UTC)[回复]

繁体支援

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

感謝藍桌照顧繁體使用者，但我目前檢視似乎有一些介面仍然是簡體中文的，例如新建工單的部分，另查臺灣的教育部字典，work order這個詞在臺灣可以翻譯為「工令」、「工作命令」、「工作通知單」或「工作單」等，就是沒有查到稱之為「工單」之翻譯，惟我日常生活中前開所有詞彙均較為少見，平常類似功能之提交申請平臺反而被稱之為「電子表單」，這部分可能需要更多繁體使用者來指出正確的翻譯。--小過兒（留言） 2024年5月30日 (四) 15:30 (UTC)[回复]
新建工单的繁体化已经完成。关于工单这个用语的翻译，我参考了一下asus的网站，叫做“请求支援”、“搜寻案件”。不知道这算不算合适的翻译。如果觉得“案件”听其来正确，那么我就把繁体语言的工单改称案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)[回复]
「工單」是對應「ticket」而不是「work order」，比如Zendesk香港也是叫ticket作「工單」[45]。再甚者，直接「搜尋申請」也是得了，不需要特地什麼ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)[回复]
@Bluedeck：怎麼查閱或更改翻譯？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月1日 (一) 19:44 (UTC)[回复]
通过改变浏览器的语言设置并刷新页面，可以查看不同的语言版本。目前要修改，可以直接留言告诉我哪里需要改。以后，会开放一个repo在github上可以pr。不熟悉sveltekit和github的用户仍然可以直接联系我。Bluedeck 2024年7月2日 (二) 06:00 (UTC)[回复]
理論上可以開twn（translatewiki.net） project啦，不過要擔心被亂改的問題。--SunAfterRain 2024年7月22日 (一) 07:02 (UTC)[回复]

工单的永久删除

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

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

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

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

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

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

設立IPBEG的本意就是許可IPBEG處理該類申請郵件，理論上可以說已有社群共識支持選項2，但已有共識未必支持選項1。IPBEG不能處理unblock-zh上非申請IPBE的工單。我是認為，一般而言封鎖申訴本應都是在公開場合發起，申訴內容多數都應該可被所有用戶檢視，實質需要使用郵件申訴封鎖的僅有無法編輯討論頁的情況。如你所言，IPBEG本有簽署NDA，就算看了也不應該會造成什麼問題（雖然能避免最好）。如果是最後採用最簡化的選項1，那我覺得您可以最低限度在處理人員的界面中加入標籤工單的功能，讓IPBEG能明確標記跟他們職務無關的申請，從IPBE隊列隱藏，僅能由添加標記的IPBEG（直至工單標籤被管理員確認）及管理員檢視。--路西法人 2024年6月2日 (日) 11:58 (UTC)[回复]
如果要让IPBEG不能看到非IPBE工单，那应该执行方式2更优。如果执行方式2，那么管理员、行政员也应该自动获得zhwp-ipbe空间权限，并进行工单自动分发。Bluedeck 2024年6月3日 (一) 08:34 (UTC)[回复]
不是「不能看到」，而是「不再跟IPBE有關的就沒必要繼續顯示在同一隊列，令其他正在處理IPBE申請的用戶不小心點進去」。「看到」大概是不會有什麼大問題的。--路西法人 2024年6月5日 (三) 02:22 (UTC)[回复]
分成两列或许方案2实现起来更简单？--桐生ここ★[讨论] 2024年6月5日 (三) 09:51 (UTC)[回复]
不是不行，但必須考量沒簽署NDA的管理人員是否有權限接觸unblock-zh內的工單，一般視乎工單是否涉及IP位址等可辨識資訊。如果要再這樣分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)[回复]
还是那句话，我无法理解WMF要求邮件列表内的IP必须有签署NDA才能接触，但允许使用unblock模板直接把IP公开。--桐生ここ★[讨论] 2024年6月6日 (四) 09:48 (UTC)[回复]
我一开始听说IPBEG需要NDA，但管理员不需要NDA的时候，我也觉得很费解。而且你知道吗，你用的任何JS组件要是对外部资源进行请求，那么就可能有意无意泄露IP。甚至你收到一封邮件，邮件里带个图，这图也能泄露IP。虽然说IP在wiki上被当作隐私，其实整个互联网对IP的保护可以用奇差来形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)[回复]
似乎是祇有涉及IP等隱私資訊時，纔要求管理員簽署相關協議。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:13 (UTC)[回复]
@Bluedeck：只要不僭越社群賦予之權限，應儘可能以您自身方便為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月6日 (四) 00:11 (UTC)[回复]

提供的IP问题

现在有个问题

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

凍結RFDA

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

當前解任案效力

本主題全部或部分段落文字，已移動至Wikipedia talk:管理員解任投票/Mys 721tx/第2次。执行人：Jimmy-bot（留言） 2024年7月25日 (四) 08:14 (UTC)。[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:教育專案、Wikipedia talk:给老师们的提示。

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

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

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

設立教育佈告板

根據上方的討論共識，已設立教育佈告板的草案，歡迎各位前來討論。--人间百态,独尊变态(讨论) 2024年6月22日 (六) 11:06 (UTC)[回复]

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

你設計還不錯--HYHJKJYUJYTTY（留言） 2024年6月22日 (六) 11:17 (UTC)[回复]
據我所知，目前有教育專案，都是在互助客棧其他區通報。至於是否需要獨立的教育專案布告板，則尚待商榷。但無論具體地點如何，總是應鼓勵教育專案主持人通報，俾利於社群覆核。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:20 (UTC)[回复]
「教育」佈告板此稱呼較含糊，或許改為「教育專案」佈告板？謝謝。--SCP-0000（留言） 2024年6月23日 (日) 15:52 (UTC)[回复]
 完成--人间百态,独尊变态(讨论) 2024年6月24日 (一) 13:29 (UTC)[回复]
教育專案佈告板看起來不錯。--冥王歐西里斯（留言） 2024年6月27日 (四) 01:33 (UTC)[回复]
我觉得这个设计的不错，支持。--桐生ここ★[讨论] 2024年6月25日 (二) 16:21 (UTC)[回复]
在看草案之前我以为是用来通报/报备教学计划的布告板，但起来好像不是这个用途。
  • “参与教育专案的学生的条目作业已产生或可能产生的问题”是不是在条目讨论页或用户讨论页讨论相关问题会比较直接？除此之外还有互助客栈的条目讨论版。
  • “教育专案运行中产生的问题”需要为这些问题设立布告板吗？相关问题的讨论频率似乎不多，是否可以继续在互助客栈讨论？
  • “关于维基教育基金会的讨论”个人对这个基金会了解不多，其曾经在中文维基百科举办过什么活动吗？
--Steven Sun（留言） 2024年7月2日 (二) 02:11 (UTC)[回复]
@人间百态：感覺通報教育專案也可以納入範圍。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 04:24 (UTC)[回复]
不反對。--冥王歐西里斯（留言） 2024年7月2日 (二) 04:44 (UTC)[回复]
建议加入一个列表备案当前进行中的教育项目，并要求教育项目的主管者填报，备案信息可包括：
  • 项目名称（相关机构名称）
  • 教育项目编写的条目性质（翻译或原创）
  • 教育项目的主管者用户ID以及其他监管者ID
  • 教育项目的参与者ID
  • 教育项目内正在编写的条目列表
方便巡查员和社群了解正在进行的项目信息。--Sinet（讨论） 2024年7月2日 (二) 15:26 (UTC)[回复]
@Flyinet，已完成。--人间百态,独尊变态(讨论) 2024年7月3日 (三) 14:20 (UTC)[回复]
已將通报教育项目納入範圍，順便回復一下Steven Sun君的疑問。我對教育專案佈告板設計的定位和英維是大致相同的，即集中處理維基教育專案的老師和學生在編寫維基百科時可能產生的問題。条目讨论页、用户讨论页、互助客栈，這些地方確實比佈告板直接不少，但這些頁面比起佈告板來或曝光度不足，或查閲困難。佈告板設立後能夠讓社群更加有效的處理相關問題，并提供存檔供用戶查閲如何處理相關話題。--人间百态,独尊变态(讨论) 2024年7月2日 (二) 13:57 (UTC)[回复]
又想了一下，教育项目运行中产生的问题的討論頻率確實不是很大，就算出現大部分也是有關學生的作業質量問題。故此已將学生的作业质量问题一項并入教育项目运行中产生的问题之中。--人间百态,独尊变态(讨论) 2024年7月2日 (二) 14:10 (UTC)[回复]
  • 我想請問這個佈告欄未來如何運作？目前看不出來有任何方法可以使想發起作業的老師能提前知道要來通報，而且如果要用維基介面寫通報，大概使用率會很低；社群依然會一天到晚先被作業洗，然後才通知老師去登記，完全沒有發揮預警效果。如果是合作社群要去登記……目前大宗會有合作案的就台灣社群，但我們已經有教育專案頁面了。--Reke（留言） 2024年7月6日 (六) 15:02 (UTC)[回复]
    interesting的問題。不知道Reke君有沒有關注過近來英維的教育佈告板的討論記録，在近幾年中也幾乎沒有人用該佈告板來提報項目。一來英維老師通常會使用Wiki ED進行課程，二來在英維老師也是不太管注教育佈告板的。實際上這個佈告板本來就不是為了“預警效果”而設計的，其目的正如上方的回復所說為了讓社群“集中处理维基教育项目的老师和学生在编写维基百科时可能产生的问题”。佈告板的確無法改變社群始終慢一步的事實，但它能在事情發生後讓社群更加直接的處理相關問題並通知有關用戶。--人间百态,独尊变态(讨论) 2024年7月7日 (日) 03:30 (UTC)[回复]
    感謝，我是看上方討論都要把通報列入當中，而且目前板面說明中也容許提報教育專案，所以才這樣問的。
    如果單就集中處理問題來講，我建議不如在互助客棧開設一個「/教育專案」的分頁面？這樣子看互助客棧的其他版面時，也就可以順便去關切一下。--Reke（留言） 2024年7月9日 (二) 04:14 (UTC)[回复]
    我個人是傾向不要再開客棧的子頁面啦，況且看客棧的特定子頁面的時候也未必會去看其他子頁面就是了。--冥王歐西里斯（留言） 2024年7月9日 (二) 05:20 (UTC)[回复]
    同意，挺不错的设计。--SheltonMartin留言|签名 2024年7月11日 (四) 06:38 (UTC)[回复]

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

或许可以考虑m:CampaignEvents？--百無一用是書生 (☎) 2024年7月21日 (日) 06:55 (UTC)[回复]
不反对，不过中维有引入这个插件吗--人间百态,独尊变态(讨论) 2024年7月21日 (日) 07:08 (UTC)[回复]
教育專案不會用。至於如果您是指編輯松，建議另開新討論。謝謝。--SCP-0000（留言） 2024年7月21日 (日) 07:11 (UTC)[回复]

討論頁話題自動索引

為配合WP:CON/TRIAL鼓勵用戶多善用條目討論頁，我嘗試重製了類似過往Shizhao君製作的Talkindexbot（WP:TALKINDEX），自動索引各討論頁的近期話題。目前索引暫時置於本人用戶空間（User:LuciferianThomas/討論頁索引），未來將正式申請機械人任務更新WP:TALKINDEX。若各位對索引測試有任何意見或建議，歡迎在此提出。--路西法人 2024年7月6日 (六) 12:51 (UTC)[回复]

支持這個initiative（雖説這在WP:CON/TRIAL的提議出現前就該出現了）。Sanmosa 蚌埠 2024年7月6日 (六) 13:53 (UTC)[回复]
挺好的，不过我也发现了点问题，但恐怕并不容易修复：
  1. 有些讨论已经结束（比如，编辑请求解决了），却仍会出现在此索引上，导致其十分冗长
  2. 有些讨论发起时间比较早，或讨论较长时间都没有人回应，就不会出现在此索引上；这可能并不利于问题的解决/共识的形成
--古怪的Wang31（讨论 | 贡献） 2024年7月7日 (日) 13:09 (UTC)[回复]
聊勝於無，有問題可以之後慢慢改善。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月7日 (日) 15:35 (UTC)[回复]
  1. 現在仍然在初步測試階段，未來將參考Cewbot，將已經結束（已有Archive框模板）的討論以另一種方式標記；其餘標籤如已解決之編輯請求、移動請求等亦可納入考量。此部分還請社群協助列舉。
  2. 目前機械人設計為每次都搜索最近14天的RC來弄這個列表，未來或許會以暫存方式優化；但起始搜索RC也最多只能到30天，而14天的討論串數量已貼近400大關，可以想像起始數據需要索引蠻久的（以防轟炸資料庫）。不是做不了，但最多也只能做30天，但也還是會多串到用戶難以索引不再有效的地步。另一個方法是恢復{{indiscussion}}模板以防拖延時間過長討論不被索引，這又是另一個需要社群去討論的議題。
--路西法人 2024年7月7日 (日) 15:51 (UTC)[回复]
其实很多讨论就没有结束，或即使结束了也未必有任何标记来表示已结束。我认为话题索引只索引最多30天内有进行讨论的就好了，30天都没人参与的讨论那就是暂时没人在意或没能力参与，或者讨论页的留言就只是对条目内容的一个注记，没有讨论必要。討論頁話題自動索引最大的意义是让人能够了解和检索近期发生在討論頁的所有讨论，以期达到能够有更多人关注参与讨论的目的--百無一用是書生 (☎) 2024年7月8日 (一) 02:45 (UTC)[回复]
目前确实其实是没什么大问题的，我提的只是算是一点细枝末节的问题，得不出结论也无伤大雅。
  1. 讨论结束的，通过一些模板标记可以排除；当然，这对机器人在技术上的设计要求就会比较高。要是总体上没有特别多活跃讨论，直接忽略其实也问题不大
  2. 没解决但没人回复的讨论，确实是个比较矛盾的问题。无限索引就的讨论无论从技术上还是价值上肯定都是不太现实的，还是要考虑是否需要一种“标记”。一方面，就让这些讨论不了了之，感觉也不太好，尤其一些争议要是总是不解决，可能容易产生积患；另一方面，如果真的把所有“未结束”的讨论都列出来，却没人想去讨论，那仍然会让索引变得越来越长，失去意义。（突然想到，这个问题其实也可以类比存废讨论的积压讨论的存在，关键在于讨论的问题到底重不重要）
    我也给个我的建议，可以考虑先恢复{{indiscussion}}（我不清楚模板具体内容，总之是恢复或创建一种标识“此处有讨论正在进行”的模板），试用一段时间，要是积压的讨论越来越多，就还是用按日期索引的方案。
--古怪的Wang31（讨论 | 贡献） 2024年7月9日 (二) 14:37 (UTC)[回复]
當初的刪除理由是「在讨论页开新段落自然是寻求讨论，无必要专门用一模板彰显」。我覺得可以改成預設索引對象包含兩者，一種像現在這樣一定時間內發起討論，另一種就是特別標示有此模板的話題（無論發起多久）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月17日 (三) 08:02 (UTC)[回复]
正是我上方留言所說的做法。--路西法人 2024年7月17日 (三) 08:41 (UTC)[回复]
有關頁面整體內容過多問題，可以考慮同過往一般，按命名空間拆分子頁面。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:42 (UTC)[回复]
已更新至WP:TALKINDEX。--路西法人 2024年7月17日 (三) 03:12 (UTC)[回复]
我觉得可以加上对话页对应页面的状态，如保护、特色、优良以及页面不存在等--百無一用是書生 (☎) 2024年7月21日 (日) 06:14 (UTC)[回复]
若祇是索引話題，是否有一些多餘？當然，若機器人能做到，那仍可以圖示為附註之類。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月21日 (日) 08:04 (UTC)[回复]
确实很实用。感觉可以考虑下放给各专题。以专题分类索引相关条目的讨论页话题，做成状态通告那样可以自定义的工作流，不知在技术是否会有难度。--PexEric💬|📝 2024年7月22日 (一) 13:43 (UTC)[回复]
如此想必可以进一步盘活讨论页。各专题协作起来也更高效。--PexEric💬|📝 2024年7月22日 (一) 13:45 (UTC)[回复]

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

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

🍾--2A0D:2683:C100:0:0:0:0:F（留言） 2024年7月13日 (六) 07:54 (UTC)[回复]
大快人心。何时轮到WMLO？L'Internationale, Sera le genre humain! ✏️ 2024年7月14日 (日) 09:40 (UTC)[回复]
該用戶的使用者頁面仍未掛{{WMF-legal banned user}}，請管理員協助處理。--132.234.229.216（留言） 2024年7月17日 (三) 08:26 (UTC)[回复]
主账号影武者并未受到基金会全域禁制。L'Internationale, Sera le genre humain! ✏️ 2024年7月17日 (三) 10:04 (UTC)[回复]
不影響，禁制針對的是個人（或組織，但就此例而言不適用），而不是單一帳號。Sanmosa 蚌埠 2024年7月17日 (三) 14:19 (UTC)[回复]

請求社群判斷已經數據過期的用戶是否為傀儡

見相關SPI提報，現時最少有法國飲食文化、如懿傳、冊封體制受到影響（很可能還不止這些），請調查助理、管理員和其TA用戶判斷和徹底清查，謝謝！--MCC214（Sign | Contributions） 2024年7月18日 (四) 05:12 (UTC)[回复]

  • 外加一些賬號（包括SPA），請檢查是否為冏；
延伸內容

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

這難道不應該直接在傀儡調查頁面處理？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:39 (UTC)[回复]
這些Stale了的賬號，即使有可疑，放上SPI也查不了，所以只能放此。--MCC214（Sign | Contributions） 2024年7月21日 (日) 05:32 (UTC)[回复]

  本討論章節會維持開放，暫時不按最後意見發表時間存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

有沒有「勿添加違法網址」的警示模板？

本主題或以下段落文字，在討論結束後應存檔至Talk:創意私房。

因為又有人在創意私房加入網站網址，雖然網址被台灣政府停止解析，但仍有從其他國家進入的可能，添加網址會違反使用條款。所以我想要不要在條目頂端放個警示模板，但不知道要去哪裡找。--世界解放者（留言） 2024年7月20日 (六) 05:28 (UTC)[回复]

添加网址并不等于ToU中提到的那些。网址本身并非色情内容。——暁月凛奈 (留言) 2024年7月20日 (六) 05:45 (UTC)[回复]
之前User:SCP-2000是用這個理由刪去網址，雖然台灣的法律張貼網址可能不違法，但美國的法律我不清楚。--世界解放者（留言） 2024年7月20日 (六) 07:00 (UTC)[回复]
网址与网站内容是两回事，直接将内容，比如截图甚至视频发布至维基百科显然是违反使用条款的，但网址只是一串字符，和条目标题性质相同。提供链接不等于提供内容，用户自行访问和分享内容不是维基百科的问题。您也可以参考涉及版权纠纷的网站案例。——暁月凛奈 (留言) 2024年7月20日 (六) 09:44 (UTC)[回复]
好像在有些州，僅是觀看也可能觸法。我不認為「和條目標題性質相同」，一般來說連結就是要點開來看的，一個不能點的連結又有什麼添加的必要？而且Google會移除不當的搜尋結果，目前搜尋「創意私房」是找不到網站的。--世界解放者（留言） 2024年7月20日 (六) 12:28 (UTC)[回复]
我在英維搜尋了一下，雖然沒有正式的相關規定，但用戶的共識是不要貼，包括暗網之類的連結。--世界解放者（留言） 2024年7月20日 (六) 12:54 (UTC)[回复]
对一个网站进行介绍而又完全不提及其域名不是很奇怪吗？“連結就是要點開來看的”——若是如此，广告商也没必要费力提高点击率了，很多链接并不会被点击，比如参考来源。对于想要访问的人，即使这里没有也会想方设法寻找域名进而访问。Google不是美国政府，它的展示策略是它自己的设置，搜索引擎也不是只有Google。另外，移除此类网站的链接并不是中英文社群的通行做法，相反，存在Category:被美国封锁的网站、en:Category:Domain name seizures by United States这类分类。对于域名被查封，或是已经关闭的网站而言，提及域名应该是必要的。再者，就该讨论的标题而言，警告式的模板通常仅应用于用户讨论页和编辑提示，而不是放到条目上方。——暁月凛奈 (留言) 2024年7月20日 (六) 13:18 (UTC)[回复]
我的意思是，你用條目標題Google搜尋可能搜不到東西，但可以直接用網址連過去，兩者的意義不同。條目蘿莉塔之城也沒有提供網址，在英維的討論頁編者們是認為不要放連結，也不確定是否會有法律問題。
還有，問題不僅在於「想要訪問的人」，維基已經不止一次因為兒童色情內容惹上麻煩了（見網路觀察基金會與維基百科、en:Reporting of child pornography images on Wikimedia Commons），我可不想看到「驚！維基百科居然可以連到創意私房的網站？」這樣的台灣新聞報導。--世界解放者（留言） 2024年7月20日 (六) 13:37 (UTC)[回复]
我提到用户讨论页和编辑提示，是因为您想达到的目的不是只有在条目中放警告才能实现。在条目上方放警告可能适得其反。en的讨论参与人数并不多，更多的网站介绍仍然包括网址。另外，现在网络已与2008年不同，Wikimedia强制使用https。——暁月凛奈 (留言) 2024年7月20日 (六) 13:51 (UTC)[回复]
這可能屬Wikimedia Foundation Combating Online Child Exploitation Policy的管理範圍。當中清楚表明Sharing links to (or purporting to be to) such material is also in violation of this policy。當然若有關連結及圖片有明確的教育價值除外[該方針原則上禁止在沒有產生教育價值的地方上傳完全纯虛構的兒童色情]。當然創意私房最大問題我反而會說是無差別誘騙強迫偷拍，從某黃姓藝人的收藏中可得知當中不少是成年人的[我不是說那邊涉兒色的沒問題]。--S叔 2024年7月21日 (日) 00:36 (UTC)[回复]
既然基金會有規定，那就好。我來研究編輯提示怎麼弄。--世界解放者（留言） 2024年7月21日 (日) 11:16 (UTC)[回复]
感謝User:Hoben7599建立編輯提示。--世界解放者（留言） 2024年7月21日 (日) 11:27 (UTC)[回复]
@暁月凜奈：雖然張貼連結不等於直接散布兒童色情，但en:PROTECT Act of 2003有禁止「廣告」，張貼連結有可能算是「廣告」。--世界解放者（留言） 2024年7月22日 (一) 01:40 (UTC)[回复]
这讨论主题让人想起处女杀手和网络观察基金会与维基百科，不过在这一案例，基金会维持了有关图片的展示。創意私房可以说在任何主要的司法管辖区都完全不合法，也没有教育意义，链接或许可以基于共识加入过滤器。我觉得无须创建一个单一用途模板，您可以直接手写提醒用户，而在条目挂模板可能会WP:BEAN。--桐生ここ★[讨论] 2024年7月22日 (一) 09:12 (UTC)[回复]
目前添加過連結的編者（包括條目創建者）應該非屬惡意編輯，我有在討論頁提醒但不一定會被看到，所以想說有沒有一定會看到的方法。現在已經用Template:Editnotices/Page/創意私房來提醒。
依據New York v. Ferber禁止真人兒童色情不需要考慮其含有的價值，而創意私房的內容在en:Dost test下應該算是色情，所以不存在豁免的可能性。--世界解放者（留言） 2024年7月22日 (一) 12:13 (UTC)[回复]
明確一點來説，色情[引起性慾的物品，娛樂用]與教育價值應成反比。很難想個例子是同時有效刺激性慾和有教育目的[除了極少數人的性興趣就是學習]，最多分開進行。因此這只是界定何謂色情物品的標準。--S叔 2024年7月22日 (一) 13:18 (UTC)[回复]
有一说一，libgen和Z-Library的链接是不是也是违法网址 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月20日 (六) 18:41 (UTC)[回复]
我打「勿添加違法網址」是因為我想可能沒有「勿添加兒童色情網址」這種模板。--世界解放者（留言） 2024年7月21日 (日) 11:21 (UTC)[回复]
建议直接永久保护该条目--Bovemdep（留言） 2024年7月22日 (一) 07:34 (UTC)[回复]
沒有必要，這是因噎廢食。--世界解放者（留言） 2024年7月22日 (一) 12:18 (UTC)[回复]
直接加外部連結黑名單吧（或是更極端點如果基金會明顯會禁止的話問看看要不要加全域黑名單）--SunAfterRain 2024年7月22日 (一) 14:47 (UTC)[回复]
我在几天前给基金会发了邮件，基金会那边还没回复。Python6345（留言） 2024年7月22日 (一) 15:42 (UTC)[回复]
注意有一种处理方法是仅仅描述网址（www.example.com），不作为可以点击的链接（http://example.com）。英文版的例子。--GZWDer（留言） 2024年7月23日 (二) 13:49 (UTC)[回复]
中文维百也有例子--Bovemdep（留言） 2024年7月23日 (二) 15:31 (UTC)[回复]

維基百科iOS應用程式替代文字功能實驗

您好，我是維基媒體基金會負責支援行動應用程式團隊的資深運動通訊專家阿瑪爾·拉馬丹（Amal Ramadan）。

維基百科iOS應用程式伊始乃以閱讀為主要用途。最近兩年間，我們亦加強了應用程式的通訊功能，為此後支援「建議編輯」（Suggested edits）機制打下良好基礎。我們首先設計了替代文字（alternative text，alt text）原型為概念驗證，再引進「圖像建議」（Image Recommendations）功能，為iOS應用程式建議編輯機制的第一波適用對象。我們在下一階段將擴大實驗，推廣替代文字任務。

為何選擇替代文字？目前，維基百科許多條目中的圖像尚未提供替代文字，不利於視覺障礙人士及網路連線品質不佳者瀏覽。替代文字能夠有效描述圖像，增加可存取性，並促進使用者參與。近期研究指出，以iOS應用程式圖像建議功能添加的圖像，只有16%有替代文字，其中品質優良者更是屈指可數。本次實驗希望釐清，為編者指定替代文字任務是否能提升替代文字的數量及品質，並同時確認此種任務是否無論新手或資深編者都能上手。

我們誠摯邀請社群關注本次實驗，並在計畫頁面隨時跟進其進展及成效。本次實驗預定於2024年9月至10月間舉行，其間完成至少一次有效編輯的使用者，將獲得一次提示，學習如何撰寫高品質替代文字；所謂「有效編輯」，指以圖像建議功能添加圖像，或在有缺乏替代文字圖像的條目發布編輯者。在本次短期實驗期間開放編輯次數少於50次者存取iOS應用程式提供的圖像建議功能，以便評估新手在圖像建議及替代文字任務中的表現。

歡迎您在討論頁提供回饋意見或針貶不足之處，幫助我們改善功能。您可在實驗期間登入iOS應用程式，以圖像建議功能發布編輯等，親自嘗試替代文字任務。

不要錯過有關本次重大實驗的更新消息！

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

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