跳转到内容

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

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

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

按此刷新頁面。

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

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

查看全部討論

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

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

消息

Edit check experiment results

Hello everyone

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

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

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

What was found?

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

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

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

What is next?

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

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

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

大家好
我們最近在您的wiki測試了「參考檢查」，和其他10個wiki一同進行測試。此功能鼓勵新手編者和IP使用者在維基百科上新增段落時附上引用。
我們於2024年2月18日至4月4日期間在您的wiki測試了此功能。在測試期間，我們為50%的新帳號和IP使用者提供了「參考檢查」，而其餘50%的使用者則獲得常規體驗，沒有任何鼓勵。透過這種方式，我們可以比較兩組使用者的體驗。
我們的發現
「參考檢查」提高了新手編者發布的編輯品質，並且沒有造成任何嚴重干擾。平均而言，19%的使用者在未經要求的情況下附上參考資料。當「參考檢查」鼓勵他們附上引用時，該百分比上升到42.4%。當使用者被鼓勵時，在行動裝置上新增的參考資料數量是在桌面裝置上的4.2倍。
至於針對您的wiki，平均有26.6%的使用者在未經要求的情況下附上參考資料。當「參考檢查」鼓勵他們附上引用時，該百分比上升到57.6%，是我們獲得的最佳百分比之一。
我們已經公布了詳細結果，如果您還有任何疑問，可以問我。
我們的下一步
鑑於測試結果良好，我們結束了A/B測試，並為您的wiki的所有新手編者和IP使用者部署了「參考檢查」。
我們正在製定一項新的檢查，這是對IP使用者和新手編者的新鼓勵。我們正在為下一步的工作徵求意見。您認為，當新手編者開始編輯時，向他們解釋什麼是有用的？
如果您對這個專案還有任何疑問，可以問我。 Trizek (WMF)（留言）
--Cookai餅塊🍪（💬留言） 2024年6月26日 (三) 16:55 (UTC)[回复]
@Trizek (WMF): Hello, thank you for your information!
As I said before, it is recommended that displaying reminders, which include information about our policy, when users select the "No" option (See my detailed suggestions in the previous discussion). Moreover, some users often translate articles from other language Wikipedia, where the content may not have references (e.g. Special:Diff/82953754). Thus, it is recommended to add a new dismissing reason "I translate articles from other language Wikipedia" or something else.--SCP-0000（留言） 2024年7月5日 (五) 16:25 (UTC)[回复]

基金會及全域社群事項整理（2024年6月）

以下是本年6月，基金會及全域社群相關且影響本站社群事項之整理。此整理複製自本人用戶頁 User:SCP-2000/WMF update。

  • 2024-06-27：為了提高維基百科的閱讀體驗，現時未登入用戶的預設字體大小已增加（更改為「標準」選項），已登入用戶維持不變，同時向所有用戶提供新的外觀選單，以便調整字體大小及內容寬度。此修改僅影響使用 Vector 2022（預設外觀）的用戶。參見相關討論。
  • 2024-06-27：維基媒體運動憲章的批准投票已開始，至7月9日23:59（UTC）完結。運動憲章皆在定義在維基媒體運動內的價值觀、持分者的角色和責任，同時將創建新的決策機構「全球理事會」（Global Council），來取代基金會現有部分職能。

--SCP-0000（留言） 2024年7月1日 (一) 13:01 (UTC)[回复]

Wikidata weekly summary #634

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

Discussions

  • New requests for permissions/Bot:
    • DifoolBot 4 Task(s) - Split single references containing multiple reference URLs into multiple references.
    • Bot Bozze Task(s) - Add sitelinks to itwiki draft articles after they've been moved to the main namespace.
  • New request for comments: Spelling convention for labels and descriptions in English - RfC started 2024-06-25. This RfC requests feedback and input for finding consistency in spelling convention as English has multiple regional variations.

Events

  • Past: The Lexicodays 2024 was an online event designed to offer a discussion space for the Wikidata community about Lexicographical Data. An archive of some of the slides and session recordings are here c:Category:Lexicodays 2024. More will be added as they become available.
  • Upcoming:
    • The next Wikidata+Wikibase office hours will take place on Wednesday, 16:00 UTC on Wednesday, 10th July 2024 (18:00 Berlin time) in the Wikidata Telegram group. The Wikidata and Wikibase office hours are online events where the development team presents what they have been working on over the past quarter, and the community is welcome to ask questions and discuss important issues related to the development of Wikidata and Wikibase.
    • Talk to the Search Platform / Query Service Team—July 3, 2024
    • Botany-focused Wikidata online workshop online as part of the #IBC2024. Date: Tuesday 9th July at 9pm NZST (GMT+12) / 11 am central Europe. Register here!

Press, articles, blog posts, videos

Tool of the week

Other Noteworthy Stuff

  • The second iteration of the Wikidata:Open Online Course has begun. Class will continue until August 11. Whether you're a beginner taking your first steps, an individual in need of a refresher on Wikidata concepts, or a seasoned trainer looking to level up your skills - this course is right for you.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • EntitySchemas:
    • We worked around an issue where EntitySchema pages were no longer considered “content” and had become unsearchable (phab:T368010)
    • We prepared for the release of the new datatype on July 2nd.
  • mul language code: We are working on the last remaining blocker before rolling out the first stage to Wikidata (phab:T362917)
  • Wikibase REST API: We are continuing to rework API errors (phab:T366911, phab:T366239)

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

Weekly Tasks

—此條未加入日期時間的留言是于2024年7月2日 (二) 00:14 (UTC)之前加入的。

The Signpost: 4 July 2024

News, reports and features from the English Wikipedia's newspaper


方針

提議英維指引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)[回复]
雖然全球只有中維 「沒有「歧視」全外文來源的風氣」，但如果編輯者認真起來，把全球國家及地區的所有播放資料連來源一併列出，在文章比例上有一定問題，而且顯得資料不經篩選，過分詳細。如單計首播平台，也有超過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)[回复]
@Pyruvate、Stevencocoboy、CyrussKK1230、Ckh3111、Apple v、Tw drama、Nickice、Yau Sze Long、Bosco64、Will629、Ricky36、SeoTae、Redmi123465、Benkwokmars、Tanqrsucks、任晏延、紅軍28、Hkmjai、WiKilover022、Underconstruction00、Achanhk：各位，這是關於電視劇條目格式的指引修訂，旨在對一些瑣碎的播放資訊進行限制，主要着眼於重播資訊、非中文地區播放資訊、OTT播放平台及網絡電視平台播放資訊，請看看有沒有意見？
--Factrecordor（留言） 2024年6月27日 (四) 15:35 (UTC)[回复]
沒有意見，Factrecordor大的補充條目我覺得可以寫進去。 --窝法乙烷 儿法梦碎 2024年6月27日 (四) 16:12 (UTC)[回复]
沒有意見--WiKilover022（留言） 2024年6月29日 (六) 04:46 (UTC)[回复]
@Cdip150@Kalin8111請問兩位對後續討論有沒有意見？--Factrecordor（留言） 2024年6月29日 (六) 11:24 (UTC)[回复]
中文好像不是馬來西亞的官方語文，如何定義它屬於中文地區？近數十年加拿大是華人熱門移民地點，我也可以說那裡的華文華語市場不容忽視。參考漢語國家和地區列表 ？--Underconstruction00（留言） 2024年7月4日 (四) 01:25 (UTC)[回复]

关于国籍的原创研究

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:非原创研究、Wikipedia talk:格式手册/两岸四地用语。

近日发现WP:CS4D内对于国籍的标记有所规范，然而发现当中有不合法律，原创研究的地方。中国很长时期对于国籍的法律编定都不上心，据站内中国国籍条目：

  • 1909年，清政府颁布《大清国籍条例》
  • 1912年，北洋政府制定了《国籍法》
  • 1980年，中华人民共和国颁布了《中华人民共和国国籍法》
  • MOS:NATIONALITY稱1912年（不含）前（未內渡的臺灣（含澎湖）人則為住民去就決定日前）的大清臣民，其為大清臣民期間的國籍應表述為「清朝」。然而，「住民去就決定日」，即1895年時，清朝根本沒有國籍法，怎何能標示其所謂「國籍」？
  • 1949年後，1980年前，中國缺乏正式的國籍法規（請參考 Shao, Dan. Chinese by Definition: Nationality Law, Jus Sanguinis, and State Succession, 1909–1980. Twentieth-Century China. 2009, 35 (1): 4–28. S2CID 201771890. doi:10.1353/tcc.0.0019. ，第五頁）。MOS:NATIONALITY稱1949年以後的中華人民共和國公民，如其在中國大陸設有戶籍，其為中華人民共和國公民期間的國籍應表述為「中華人民共和國」，沒有國籍法規之下，將國籍硬說成「中華人民共和國」是否合適？設有戶籍則推定他有國籍這種做法又不知道是否合適？
  • 此外，如金毓黻。中華民國根本不承認滿洲國，資訊框寫1932年退出中華民國國籍，1936年重新加入中華民國國籍的說法，到底有沒有資料支持？

--Ghren🐦🕘 2024年5月12日 (日) 13:04 (UTC)[回复]

没有国籍法=没有国籍 吗，值得探究“国籍”的含义、该填什么。按资料，用宪法规定国籍最早见于法国1791年宪法，用单行法规定国籍最早见于1842年普鲁士（德国）国籍法。瑞士國籍法始于1952年，丹尼尔·伯努利的国籍（Nationality）瑞士为错误信息？“1901年取得瑞士国籍”于 物理学小词典[M]. 1987。“1923年，黑塞加入瑞士籍。”，英文条目“In 1923, Hesse was granted Swiss citizenship.”，而有些文章会写成瑞士国籍。--YFdyh000（留言） 2024年5月12日 (日) 13:54 (UTC)[回复]
同問，無國籍法即無國籍之説顯然不合常理。Sanmosa 全方貧工之聯合 2024年5月12日 (日) 14:11 (UTC)[回复]
(＋)支持U:YFdyh000的論點。國籍是現代概念，而在介紹國籍法出現前的古代人物時，依WP:常識即可認定其國籍。--CaryCheng（留言） 2024年5月12日 (日) 16:14 (UTC)[回复]
英文nationality有兩層含義，一層是the official right to belong to a particular country、一層是a group of people of the same race, religion, traditions, etc.。當我們說伯努利是瑞士數學家、古騰堡是德國印刷學者，用的是nationality後者的含義。在中文中「國籍」是這樣定義的：「一个人属于某一个国家的国民或公民的法律资格」（《辭海》），沒有法律定義自然沒有所謂的「國籍」，沒有nationality的第二種含義。您可以說李善蘭是清朝數學家，但不能說他是大清帝國籍的數學家。不能這樣硬套上去的。--Ghren🐦🕛 2024年5月12日 (日) 16:59 (UTC)[回复]
没有为国籍这一概念立法时，就不存在“official right”概念了吗。依旧有法律和现实意义上的国籍身份和权利义务，只是未成文或者以其他形式体现。[9]。当然，谨慎运用减少问题是应当的。另外，金毓黻条目那种，我会怀疑原创研究。--YFdyh000（留言） 2024年5月12日 (日) 17:17 (UTC)[回复]
我會認為「中華人民共和國」適用於雖沒有為國籍這一概念立法，但有「official right」的說法，算作有國籍或者合適。但再拉前到清朝立國籍法前的年代，實在有欠謹慎。--Ghren🐦🕐 2024年5月12日 (日) 17:27 (UTC)[回复]
另，馬丁·路德現時標注的國籍是「薩克森選侯國」。國籍形成在民族國家之後的事，為其標注國籍是否不正當？--Ghren🐦🕙 2024年5月12日 (日) 14:50 (UTC)[回复]
民族国家产生之后一个人也不一定拥有国籍吧？
要没有来源不如不标国籍，而且国籍是一个人属于一个国家国民的法律资格，国籍法出现之前何来国籍之说呢？--newerdrawn（留言） 2024年5月12日 (日) 15:46 (UTC)[回复]
可以参考UNHCR对1954年《关于无国籍人地位的公约》的阐述[10]，【该定义中提及的“法律”应当宽泛理解为不仅包括立法，还包括部级法令、条例、命令、判例法（在有先例的国家），并在适当时包括习惯做法】，“包括习惯做法”。所以，正式设立国籍法前，在世俗意义上，仍可能认为和称之为国籍？比如获得了当地户籍、居住权之类的？--YFdyh000（留言） 2024年5月12日 (日) 16:08 (UTC)[回复]
所以您認為「薩克森選侯國」是合適的國籍？還是應該是「德國」？--Ghren🐦🕐 2024年5月12日 (日) 17:01 (UTC)[回复]
这主要涉及到现代对于国家的认知。一般而言，中国大陆政治学界一般采取四元素论，即：主权、领土、人口、政府，如果一国能事实上作为“对内最高、对外代表”的存在，并符合有固定领土、统治之下有人口、有统治的政府，那么可以认为是国家，进而存在国籍。往回追溯至威斯特伐利亚体系前，一般则认为其是否是主权者的臣民，如果该人是主权者的臣民则应被视为有一国国籍。综上，萨克森选侯作为萨克森选侯国的主权者，如果其事实上有“对内最高”（即其命令不可被任何政治实体推翻）、“对外代表”（如可以签署条约并被公认为是元首），则可以认为“萨克森选侯国”相比较于“神圣罗马帝国”是更为合适的国籍。以上，供参考讨论。--CHNAQW（戳我进入讨论页！o(*^▽^*)o~） 2024年6月13日 (四) 06:19 (UTC)[回复]
應該明確規定禁止擅自為近代以前歷史人物添加國籍，這是對資訊框nationality參數的濫用。至於「中共」國籍的例子，我就覺得有點吹毛求疵，無論如何要說彼時中國大陸居民處於無國籍狀態是不合情理的。但其實多數人物沒有添加nationality參數的必要吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月12日 (日) 17:02 (UTC)[回复]
我承認有點吹毛求疪，但這是有實際問題的。像是韓戰間來台的大陸的「反共義士」的國籍、國軍與解放軍間的駕機叛逃事件等等的國籍問題等等。中華民國當時不承認大陸國籍，自然不存在「反共義士」的「中華民國」國籍被取消的問題。實務上，我認為搞不清楚就不要填為妙，就用「效忠」欄位繞過他就好嘛。--Ghren🐦🕐 2024年5月12日 (日) 17:23 (UTC)[回复]
真要較真的話，那些人應該一直都是中國人（華籍），只是政府承認轉換問題，與國籍本來無涉。但這其實是政治問題，我認為本站編者不應該為自己憑空製造麻煩。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月13日 (一) 08:48 (UTC)[回复]
或者没有可靠来源提出该人的国籍，就不应当在条目中或信息框中注明国籍？--百無一用是書生 (☎) 2024年5月13日 (一) 02:53 (UTC)[回复]
應該慎重考慮引進，尤其近年來原創研究現象一直很嚴重。試想某人生於美國、居於美國、死於美國，那推想其國籍為美國也是很正常的事情，但資訊框這樣記載有什麼意義？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月13日 (一) 08:48 (UTC)[回复]
生於美國、居於美國、死於美國，还真的未必就是美国国籍....--百無一用是書生 (☎) 2024年5月13日 (一) 09:01 (UTC)[回复]
對呀！所以原創研究是不對的。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月13日 (一) 17:04 (UTC)[回复]
如果他不是外交官的子女倒是（詳見美國憲法第十四修正案）。--Billytanghh 討論 🇺🇦🇮🇱 2024年6月21日 (五) 13:22 (UTC)[回复]
又順帶一提，像錢鍾書這種標示國籍，在國籍裏硬塞朝代變遷有什麼意義呢？--Ghren🐦🕐 2024年5月12日 (日) 17:49 (UTC)[回复]
还有问题很严重的，像政治人物，每个职位都加上国旗，出生、逝世地点也要硬塞上国旗，生怕别人不认得。--Kethyga（留言） 2024年5月22日 (三) 09:52 (UTC)[回复]
不知道能不能要求信息框中国旗最多只能出现一次？--百無一用是書生 (☎) 2024年5月30日 (四) 03:30 (UTC)[回复]
多次使用同一旗帜模板明显会违反MOS:OVERLINK（过度内链和重复链接）。--Kethyga（留言） 2024年6月21日 (五) 02:48 (UTC)[回复]
職位根本就不應該添加旗幟。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月31日 (五) 05:54 (UTC)[回复]
@Ghren：我在想是不是可以修訂格式手冊，明定一般來說沒可靠來源編者就別在資訊框中自己推測了？不過因為已經成習，也不適合突然推翻。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月29日 (三) 21:56 (UTC)[回复]
我覺得「國籍」的概念還是有必要搞清楚的。孔子是魯國人的來源一找一大把，如果不將概念搞清楚，很難單靠可靠來源將這些篩掉。當然，直接修訂對您維來說也是一大好事。--Ghren🐦🕐 2024年5月30日 (四) 05:42 (UTC)[回复]
对于古代，简易标准是在某国有户籍或长期居住？古代的x国人不等同现代国籍，可能出生地或自我认同。--YFdyh000（留言） 2024年6月7日 (五) 01:24 (UTC)[回复]
古代都没有国籍一说--百無一用是書生 (☎) 2024年6月7日 (五) 07:05 (UTC)[回复]
金毓黻有关问题我对阁下的意见表示赞同，条目内存在冲突。条目内经历一章节表述其“......拒绝担任伪职”，却又与右侧标注其中华民国国籍终止于1932年，存在逻辑冲突，应当予以改善。--CHNAQW（戳我进入讨论页！o(*^▽^*)o~） 2024年6月13日 (四) 06:22 (UTC)[回复]
假設存在「國籍資訊需要（可靠）來源」的方針或指引，做個思想實驗：在中原土生土長的某人歷經大清、中華民國，在日本當局統治、錄入其戶籍及國籍後不久即死，死前向大報記者表示「沒想到我死的時候會是大日本帝國國民」，死後至今只有大日本帝國國籍的資料而無任何其他國籍資料或來源。因此，其國籍欄只可填寫「大日本帝國」。--— Gohan 2024年6月21日 (五) 03:06 (UTC)[回复]
但历经也是来源，自称不一定是可靠来源，吧？不需要第一手资料，第二手第三手的总结才是基准。--YFdyh000（留言） 2024年6月21日 (五) 05:19 (UTC)[回复]
我的意思是既有他的自述見報，也有日本當局的原始國籍資料，雙重印證。「歷經」不一定能確證，如今在某國土生土長都可能不是該國公民，何況是更不重視出生地的前代。--— Gohan 2024年6月21日 (五) 11:39 (UTC)[回复]
自述和原始资料都是第一手，可能伪造。报纸可能是第二手。历经而国籍，看是谁总结的。如果只有一个可信，之前写未知/空缺似乎是合理的。--YFdyh000（留言） 2024年6月21日 (五) 11:51 (UTC)[回复]
剛好就碰上的問題：張忠謀具有ROC國籍是否屬於原創研究？--Rice King 信箱 · 留名．邊緣人 2024年6月22日 (六) 19:09 (UTC)[回复]
張氏據報稱「同時具有中華民國及美國國籍」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:19 (UTC)[回复]
據暸解算嗎？--Rice King 信箱 · 留名．邊緣人 2024年6月23日 (日) 05:35 (UTC)[回复]
「據了解」其實就是按可靠來源寫。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 04:25 (UTC)[回复]

提議統一整合維基百科:命名常規 (電子遊戲)及維基百科:命名常規 (日本動漫遊戲條目)

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:命名常规 (电子游戏)、Wikipedia talk:命名常規 (日本動漫遊戲條目)。

議程1:通用譯名定義更新及移除日本遊戲、新增日本小說議案獲得通過！--唔好阻住我愛國（留言） 2024年6月25日 (二) 00:26 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

為避免混淆討論重點，於是設置了懶人包 ！

是次討論重點如下：

  • 「日本動漫遊戲條目手冊」廢除規管日本遊戲類別，新增規管所有電視及電影類別條目。
  • 日本遊戲納入「電子遊戲手冊」規管。日本遊戲命名方式由「命名先後次序」原則改為沿用一般遊戲的「通用的中文名稱命名」原則。
  • 建議新增誇媒介條目優先命名辦法。如小說、漫畫、動畫、電子遊戲、電視節目、電影、簡體中文、繁體中文、官方名稱、正式名稱、通用名稱等。

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

討論內容如下：

維基百科:命名常規 (日本動漫遊戲條目)主張：(命名先後次序)

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

2.正式譯名和常用譯名相同，無官方譯名或官方譯名與其他譯名不相同。

3.只有通用譯名，或通用譯名和官方譯名、正式譯名不相同。此情況常見於先在網絡流行一段時間的作品，導致字幕組等非正式譯名較官方和正式譯名通用。此外也有其他原因導致官方和正式譯名不通用。在這個情況下，可按命名常規的使用事物的常用名稱規則使用通用譯名為條目名稱。

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

5.只有正式譯名。

6.官方譯名、正式譯名和通用譯名均不存在時，應考慮在出現前述其中一種譯名後把條目移動至該名稱。

維基百科:命名常規 (電子遊戲)主張：

1.使用最為通用的中文名稱命名。對於外文遊戲通常即是由發行商或代理商確定的官方譯名，但如果代理商影響力較弱，導致其官方譯名通行程度遠低於通用譯名（多見於中國大陸），應選用通用譯名命名（例如中國大陸譯名馬里奧系列）。

2.中文譯名的選用標準僅包括是否官方、通用程度等客觀條件，譯名翻譯是否正確、是否信達雅等主觀因素不在此列。

3.鑑於華語各地區遊戲譯名往往不同，條目命名地域歸屬由編寫者「先到先得」，並通過地區詞轉換解決譯名差異問題。

4.地區名稱選取標準（包括是否使用中文譯名、使用何種中文譯名）僅以該地區情況為參考根據，各地名稱均獨立平等對待，互不影響，不得以任何理由將某地區名稱條目移動至另一地區譯名。

5.原生中文遊戲因各地代理而名稱不同（多見於網絡遊戲）不視為譯名差異，條目應以開發公司最初定名為準，名稱不設轉換。

6.台灣、港澳地區命名使用繁體中文，中國大陸、新馬地區使用簡體中文。除技術限制外，條目命名應與轉換後名稱之一相符。

7.請為同一遊戲各地不同的譯名（例如「超級馬里奧兄弟」和「超級瑪利歐兄弟」）以及其他代稱（例如「超級瑪麗」）加入重新導向以引導至正確的頁面。對於名稱相似的不同遊戲，應在條目內加入頂註。

問題就來了：

1.兩者命名準則不一，而且也共同管理日本遊戲條目，如果編輯者想建立日本遊戲條目，應優先使用哪一個常規？

2.在電視類別方面，目前只有日本動漫設有條目命名常規，劇集、綜藝方面卻沒有特定命名常規，期望各位編輯者探討是否有空間更改兩個命名常規管理範圍。

以下是提案，如果各位編輯者支持此概念，才提出重寫方案。

  • 「日本動漫遊戲條目」延伸至管理所有電視電影節目，並刪除與遊戲相關規條，可改名至「電視電影條目」；
  • 「電子遊戲」名稱及大部分內容維持不變，並與日本遊戲規條整合一起。
  • 當兩者有衝突時，以該項目首個發表媒介的官方／正式中文名稱為優先。
    • 如小說漫畫的官方／正式中文名稱是最先出現，則以小說漫畫為首。
    • 如電視電影的官方／正式中文名稱最先出現，則以電視電影為首。
    • 如電子遊戲的官方／正式中文名稱是最先出現，則以電子遊戲為首。
    • 如繁體中文名稱是最先發佈，則以繁體中文為首，其後使用字元轉換工具新增簡體中文名稱。
    • 如簡體中文名稱是最先發佈，則以簡體中文為首，其後使用字元轉換工具新增繁體中文名稱。
    • 如官方名稱不是中文，正式名稱是中文，優先使用正式名稱。（中文優先）
    • 如該項目沒有中文名稱，則以維基百科:命名常規 一般規則處理。

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

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

意见：

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

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

1. 目前沒有電視電影命名常規，如要通知的話應該是放在電視電影命名常規，而非日本動漫命名常規，因為日本動漫原則是不受影響。
2. 日本動漫、遊戲條目也不受影響，真正受影響僅限日本遊戲及電視電影條目。
3. 近年，日本動漫已有真人化趨勢（如高木同學、殭屍100等），如不與時更新手冊的話，遲早出事。
4. 既然ACG有手冊規管，而當中「A」的父系「電視節目」卻沒有規管，這未免怪怪的。--唔好阻住我愛國（留言） 2024年5月26日 (日) 13:07 (UTC)[回复]
簡單來說，電子遊戲範圍以內可管理的繼續沿用電子遊戲規條，不過只是新增日本遊戲類別，此類別由「命名先後次序」原則改為沿用一般遊戲的「通用的中文名稱命名」原則。--唔好阻住我愛國（留言） 2024年5月26日 (日) 13:13 (UTC)[回复]
电子游戏的方针指引本来就规范所有的电子游戏条目，包括日本的和非日本的。而现在維基百科:命名常規 (日本動漫遊戲條目)其实更像「日本动漫游戏作品的地区词与译名处理原则」，本身没有太具体的规则（例如OVA作品条目该用「OVA」还是「动画」消歧义）？您的提案如果只是要扩大到其他领域那倒也无妨，但是您的提案相当与写了一个和原方针几乎完全抵触的内容：原来的提案是「如果条目以一地的常用名称创建，则其他编者不得移动到另一地的官方名称」，而您的提案是「原标题已然合适的情况下，其他编者依然可以移动到另一地的官方名称」。电子游戏条目是继承了现行原则的，您把原则内容都改掉了，那游戏领域命名的命名常规又是依赖着什么呢？
您是赞同維基百科:命名常規 (日本動漫遊戲條目)的理念，希望将这个原则扩大到其他作品领域；还是反对維基百科:命名常規 (日本動漫遊戲條目)的理念，希望重写一个来取代；再还是您只是想让影视领域也有一个命名方针，而没理解維基百科:命名常規 (日本動漫遊戲條目)的理念和背景？您主张扩大适用范围，但重写方案又是一个完全相反的内容。我没有理解您想表达什么。---For Each element In group Next（留言） 2024年5月26日 (日) 13:39 (UTC)[回复]
1.「只是要擴大到其他領域」：這個是理解正確的， 提案首句寫道「日本動漫遊戲條目」延伸至管理所有電視電影節目，並刪除與遊戲相關規條。
2. 現時兩本手冊沒有註明哪個媒介優先命名，有條目以遊戲命名，有條目以小說命名，也有條目以動畫命名，於是提議新增優先次序，方便之後處理命名爭議。--唔好阻住我愛國（留言） 2024年5月26日 (日) 13:59 (UTC)[回复]
那麻烦您先在相关方针的讨论页留下通知，并告知所有受到影响的专题吧。（包括您认为受到规制和取消规制的）--For Each element In group Next（留言） 2024年5月26日 (日) 14:08 (UTC)[回复]
通知了ACG Project, 和兩個受影響手冊。--唔好阻住我愛國（留言） 2024年5月26日 (日) 14:51 (UTC)[回复]
3. 「原標題已然合適的情況下，其他編者依然可以移動到另一地的官方名稱」，這個想法是一半正確一半不正確的，這是依從「名從主人」方針，「如果一個條目所述的主體——人、物或可謂有「擁有者」之事，其擁有者或代表者的官方中文資料出現此主體的中文名稱，可優先考慮使用該中文名稱。」。
  • 但為避免產生大量落差及分別，遊戲條目／遊戲分段內繼續沿用遊戲手冊。
  • 新提案僅要求如該項目同時有電視及遊戲／電影及遊戲才適用於建議命名方法。這個命名方法目前是在中維是「不成文共識」，不過僅是「小說及動畫」類別。
--唔好阻住我愛國（留言） 2024年5月26日 (日) 14:16 (UTC)[回复]
我们俩都是完全正确的 您强调的是命名总则针对一般条目的要求，而我表述的是ACG领域针对自己的实际情况制定的细节。有细节规则时，就按细节的规则来走（所以游戏命名常规和ACG命名常规也不冲突）。
至于跨媒体的问题，我认为首先应该明确条目主题是什么，也就是把定义句写好。如果您是在介绍小说条目，那样条目第一句就会是「《XXX》是20XX年发行的小说」，我们自然也就根据小说来命名（可能有先行热身的动画，但那不是条目的主题，只能放在宣发章节里）。--For Each element In group Next（留言） 2024年5月26日 (日) 14:35 (UTC)[回复]
目前有不少日本小說沒有中文化，但有中文地區動畫代理商引入其小說改編的動畫，在這個情況下，現行中維做法是該條目標題以動畫為準。新提案是同時將這個做法成文化。--唔好阻住我愛國（留言） 2024年5月26日 (日) 15:04 (UTC)[回复]
条目主题是小说，那条目当然应该把小说当成独立的主题，走一遍命名常规。如果来源普遍接受动画的名称来称呼小说，那小说自然会以该动画的名称来命名；如果小说的「常用名称」与动画的官方名称不同，那当然应该以小说的常用名称命名。官方名称就不是最高顺位，更何况条目的主题是小说而不是动画，所以这个「官方名称」和条目主题没有直接的联系，因此这个做法从逻辑上讲就没法「成文」。游戏命名常规在这方面有明确表述：「其他媒体作品译名仅当游戏无中文译名时作为参考」（游戏#5，粗体为本人所加）。这种方式在肯定了现在做法的同时，逻辑上也很自洽。--For Each element In group Next（留言） 2024年5月27日 (一) 13:53 (UTC)[回复]
範圍以內可繼續沿用子手冊，唯誇範圍時應優先考慮使用父手冊（NC:名從主人）。
很明顯20年前的編輯者在達成共識時沒有考慮過這個問題--唔好阻住我愛國（留言） 2024年5月27日 (一) 14:15 (UTC)[回复]
本身我沒有興趣大改這三個命名常規，在看到閣下的言論後，才發覺這三個命名常規有這麼多的問題。
1. 名從主人論：父常規提出的「名從主人」指引原來是不適用於子常規（動漫及遊戲命名常規）
2. 主賓關係：編輯者要在創建條目之先就要決定哪個媒介是主，哪個媒介是賓。訂立條目名稱時，如該條目主體是小說，就必須使用小說的譯名，即使小說沒有官方/正式譯名也應原創一個出來，如改編漫畫有官方/正式譯名，也應繼續使用小說的原創譯名，因條目主體是小說。—>除非定立完整的ACG/文學創作格式手冊，媒介主賓關係不是命名常規能處理的，既然閣下有這麼多的想法，靠您由0開始撰寫，畢竟子系列的電視電影格式手冊還未完成。
3. 不成文共識：實際上目前99%新建條目也採用我提及的方法定名，包括上方提及的絆之Allele，如需將這個「不成文共識」砍掉，恐怕需要花極大量時間重新審視近20年以內的建立的ACG條目有否滿足要求。
近期，中國短影音興起，中國人會在短影音分享ACG劇情，但往往也原創一個新譯名而不採用當地代理商的譯名，每集觀看次數以十萬起跳。
  • 按照ACG的6個次序的次序1，由於通用譯名不一，故不適用
  • 按照ACG的6個次序的次序2，由於常用譯名與正式譯名不一，故不適用。
  • 按照ACG的6個次序的次序3，條目最後會採用非常具「熱度」的原創譯名，到最後公眾就會質問這個條目是形容什麼的作品，為什麼我在正版平台找不到與條目相同名稱的作品？
--唔好阻住我愛國（留言） 2024年5月27日 (一) 14:55 (UTC)[回复]
方针指引是用来解决问题的，主手册是，子手册也是。主手册能解决问题就主手册就够，但主手册覆盖面太宽，未必能针对具体问题提出解决方案；如果有更好的解决方法，自然可以单独提出子手册。
即使是主手册，「名从主人」作为「命名惯例」，比命名常规的「常用名称」也低一档。子常规也是常用优于官方。我只看到子常规是遵循主常规原则的。
「條目主體是小說」意味着我们要以小说为主体，套用命名常规原则来命名。小说没有中文译名的情况下：如果命名常规规定用原文那就用原文；如果命名常规规定可以参考系列其他作品，那就参考其他作品；如果命名常规允许生造一个，那就生造一个。但这不意味着，应该让一个主题的名称直接指向另一个主题的名称上。
不成文共识又没有写到纸面上，请问怎么砍，砍哪句话？另外我的表述是「其他媒体作品译名仅当该作品无中文译名时作为参考」和您表述的「最先出現」原则在很多情况下结果是一样的，我没明白这只是表述上的差异，还是逻辑上有根本不同。
我不熟悉其他领域作品的译名情况。比如同为电视节目，我不熟悉「意大利电视新闻」和「日本电视动画」的各地译名情况是否一样；同为文字作品，我不知道日本轻小说和《舞会之后》是否有区域间的，区域内官方和非官方的译名分歧。我已经解释了ACG领域的命名原则（和主手册处理上所区别）。我赞同下方Ericliu1912的说法，您先分析一下「電視電影」领域的命名问题，看ACG命名常规是否适用于其他影视节目。如果比照ACG命名常规来操作，是否能解决当前的争议？是否会劳心又劳力（比如涉及地区词方面的移动，结果引来很多争议）。
PS：ACG命名常规有两个原则。一是常用优于官方；以前主手册在字面上，常用和官方平起平坐，所以这个原则很有特色；但现在主手册已经明确了两者顺位，所以这项就没什么特别的了。二是ACG命名手册肯定了各地最优名称平等，例如A地的常用名称（没有官方）和B地的常用兼官方名称是平级的，不得以B地官方为由进行地区词移动。从这个角度看，游戏命名常规是继承ACG命名常规的，依从游戏命名常规就是依从ACG命名常规，没有什么冲突。--For Each element In group Next（留言） 2024年5月27日 (一) 15:35 (UTC)[回复]
在完成「電影電視」前，優先解決ACG問題先。除非新常規完全不採用ACG方案及新常規成文化後即刪除ACG常規。
台灣及香港正式動畫名稱：她來自煩星 (2022年動畫)
中文顯示：福星小子_(2022年動畫)
香港區顯示：山T女福星 (2022年動畫)
按照目前常規，試評論一下這個標題有什麼問題。--唔好阻住我愛國（留言） 2024年5月27日 (一) 16:09 (UTC)[回复]
「「條目主體是小說」意味著我們要以小說為主體，套用命名常規原則來命名。小說沒有中文譯名的情況下：如果命名常規規定用原文那就用原文；如果命名常規規定可以參考系列其他作品，那就參考其他作品；如果命名常規允許生造一個，那就生造一個。但這不意味著，應該讓一個主題的名稱直接指向另一個主題的名稱上。」
這個論點目前命名常規沒有要求，可在此一併解決。--唔好阻住我愛國（留言） 2024年5月27日 (一) 16:17 (UTC)[回复]
这个作品我不熟，我不知道信息框填写的内容是否正确。但如果信息框的内容无误，且官方译名「她來自煩星」不常用，那香港和台湾显示标题符合命名常规，没什么问题。--For Each element In group Next（留言） 2024年5月27日 (一) 16:38 (UTC)[回复]
只是稍微修正下（以免其他人误会），所谓「她來自煩星」严格来说只不过是代理商羚邦集團的正式译名，而非真正的官方译名。所谓正式译名其实是指代理商译名，不能完全代表作品官方之命名，并如前所说即使在一个地区内，也会因为代理商的不同，有多个正式或民间的命名。而真正的官方译名是像类似“哆啦A夢”（多啦A夢）这种由原作者、其他持有原作品版权的公司、组织或其法定分支机构所订定及公布的中文译名。--Wengier（留言） 2024年5月27日 (一) 16:53 (UTC)[回复]
問題是，如要嚴格按照ACG命名規則，官方譯名的序號是「4」，通用譯名的序號是「3」，這個已是一個結構性問題問題，危及近10年來條目的命名習慣，必要時可能要每一個條目重新審視。--唔好阻住我愛國（留言） 2024年5月27日 (一) 17:02 (UTC)[回复]
我觉得，有一定流通度的官方譯名（原作者译名）应高于其它通用译名。就以哆啦A夢为例，“哆啦A夢”（多啦A夢）是官方译名，但在中国大陆、台湾等地亦常使用类似“机器猫”、“小叮当”这样的非官方译名（出现于官方译名之前），但条目仍遵循“名从主人”原则以官方译名命名。即使不是ACG直接相关内容，其它条目如华特迪士尼公司也是以遵循“名从主人”的原则以官方译名“迪士尼”来命名，而不是用诸如“迪斯尼”之类非官方的其它常用译名命名。--Wengier（留言） 2024年5月27日 (一) 17:18 (UTC)[回复]
您说的对。常用+官方（正式）译名当然优于单纯的常用译名或单纯的官方（正式）译名。但这个「一定」实操上该怎么判断，我觉得社区条文和判例都不足够。例如这个讨论，「官方译名」大概是「常用译名」的一半，两者搜索结果都是十万数量级以上，这算不算有足够流通度？最近我也提出过这个问题，「官方」这个标签到底能加多少分？这还是得社群这个层面有个说法，具体领域才好执行。--For Each element In group Next（留言） 2024年5月27日 (一) 17:37 (UTC)[回复]
以2006年標準，當年網路不發達，不是每一個人也可以使用互聯網，更何況是一般個人在網上寫文章？
今年是2024年，互聯網已普及化，網路撰稿員職業隨之誕生，在網絡上開帖發文已經很簡單，什至可以叫ChatGPT寫文。對此，有必要重新調整命名準則。
——-
優先考慮：棄用ACG命名規則，因為已經不合時宜。--唔好阻住我愛國（留言） 2024年5月27日 (一) 17:54 (UTC)[回复]
討論方向：
1.定義條目主體賓體先(究竟條目標題應以小說/漫畫/電視電影為首)
2. 命名先後次序原則：
2.1 需要一個可量度的通用譯名準則（以搜尋器結果計算，還是討論區討論熱度）
2.2 時限性問題（參考山T）
2.3 名從主人常規是否更合宜或不合宜？
2.4 官方／正式／通用譯名使用先後次序
3. 是否同時處理角色命名問題？
4. 所有譯名是否需要附上來源，有沒有來源要求？
5. 小說沒有中文譯名的情況下：如果命名常規規定用原文那就用原文；如果命名常規規定可以參考系列其他作品，那就參考其他作品；如果命名常規允許生造一個，那就生造一個。
6. 中文優先常規是否更合宜或不合宜？--唔好阻住我愛國（留言） 2024年5月27日 (一) 18:07 (UTC)[回复]
命名总则指出原则（常用名称）高于惯例（名从主人）。这两条规则原来是一个等级，正是2018年修正案提出划分层次的，这等于说社群正是最近肯定了ACGNAME的思路……
ACGNAME和NCVG使用官方名称的背书条款是NC:名從主人，但社群这个名从主人规则的也是个口袋规定：「……官方中文资料出现此主體的中文名称，可优先考虑使用该中文名称」。那到底什么情况可以优先，什么情况下优先也没用？社群对此是否有初步概念？可否举出一些临界案例判定情况？至此，我成功地把锅甩给社群，并且把想法传达给po主了；再说下去就是车轱轳话了，我先撤了，各位继续--For Each element In group Next（留言） 2024年5月27日 (一) 18:10 (UTC)[回复]
同意以上说法，一个重点就在于「官方」这个标签到底能加多少分。当然，要拿出很具体的量化标准也未必那么容易，不太可能绝对化。但暂且在这里抛砖引玉吧，比方说如果是“正式译名”（代理商译名），那么搜索结果或许可以乘以1.5倍(左右)进行比较，而如果是“官方译名”（原作者译名），那么搜索结果可以乘以2至3倍进行比较。类似这样的算法和优先原则（当然可能还会有其它考量）。--Wengier（留言） 2024年5月27日 (一) 18:46 (UTC)[回复]
我們好像忽視了「可靠來源譯名」…--唔好阻住我愛國（留言） 2024年5月28日 (二) 01:23 (UTC)[回复]
或许可以这样：如果某译名是官方译名或正式译名，应该有可靠來源予以支持或证实。如果是非官方非正式的常用译名，至少要有一个可靠來源支持（证实）该译名的存在。然后再按之前所说的进行量化比较。而如果某作品没有任何可通过可靠來源予以支持或证实的官方译名/正式译名/常用译名，那么只能尽量采用已被使用的译名（即使只有非可靠来源使用该译名）。--Wengier（留言） 2024年5月28日 (二) 02:02 (UTC)[回复]
(＋)支持:現就此方向寫「虛構」常規。--唔好阻住我愛國（留言） 2024年5月28日 (二) 14:41 (UTC)[回复]
次序：
1. 官方譯名/正式譯名/通用譯名/可靠來源譯名均一致
2. 正式譯名和大部分可靠來源的譯名相同，無官方譯名或官方譯名與其他譯名不相同。
3.大部分可靠來源的譯名（量化準則待定）
4. 官方譯名（中文）
5. 正式譯名 （中文）
6. 官方譯名（其他語言）
7. 正式譯名 （其他語言）
8. 通用譯名 （字幕組等非可靠來源使用的譯名 ）--唔好阻住我愛國（留言） 2024年5月28日 (二) 14:51 (UTC)[回复]
如果該片商/代理商宣傳到位的話，去到3就可以停了。所有日本動漫於台灣地區到3便完了，因為台灣動漫平台巴哈姆特獲社群評為可靠來源。--唔好阻住我愛國（留言） 2024年5月28日 (二) 15:06 (UTC)[回复]
一般而言可以落到4或之後只有以下場境
1. 於中文地區沒有關注度可言
2. 可靠來源之間對使用哪個譯名的分歧很大--唔好阻住我愛國（留言） 2024年5月28日 (二) 15:11 (UTC)[回复]
上面所说的“2. 正式譯名和大部分可靠來源的譯名相同，無官方譯名或官方譯名與其他譯名不相同”，这个显然也需要量化标准，特别是有官方譯名但与其他譯名不相同的情况下。官方译名显然有一定的优先度，至于具体量化标准，可参考之前所说的其搜索结果可以乘以某个因数（比如2至3倍）进行比较。--Wengier（留言） 2024年5月28日 (二) 15:33 (UTC)[回复]
用「比例」是否更合適？回應「 2. 可靠來源之間對使用哪個譯名的分歧很大」，如果是一半可靠來源用A譯名，一半可靠來源用B譯名，只會造成移動爭議，與其有這樣爭議，為何不跳到下一項？又例如，如果該譯名於各可靠來源至少佔7成或更多，是否算有夠流足夠流通性？--唔好阻住我愛國（留言） 2024年5月28日 (二) 15:46 (UTC)[回复]
用「比例」或「比重」来形容当然也不错，像官方译名与正式译名之间的比重差不多可以是二比一。举例说明，假设官方译名和正式译名同时存在，但一半可靠來源用官方譯名，一半可靠來源用正式譯名，那么肯定是使用官方译名。但假如说75%可靠來源用正式譯名，25%可靠來源用官方譯名，那么应使用正式译名。--Wengier（留言） 2024年5月28日 (二) 15:58 (UTC)[回复]
主體：
A:如 條目主要論述 <小說>, 條目標題就以<小說>走上述程序。
B:如條目主要論述 B年份的作品, 條目標題就以B年份為中心走上述程序。
值得注意的是A及B的條目名稱可以不一致。--唔好阻住我愛國（留言） 2024年5月28日 (二) 14:58 (UTC)[回复]
背景：
上一個使用「山T女福星」已是英屬香港時期，目前此條目的「主」是2022年改編動畫，而非20世紀的原作。
你試一下搜尋「山T女福星」，應該是沒有結果或結果不是指向2022年動畫。--唔好阻住我愛國（留言） 2024年5月27日 (一) 16:57 (UTC)[回复]

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

我不認為有關電視及電影專題之變更應該動到此命名常規，請更新在別的地方。大可立一個新的「命名常規 (電視電影)」，順便整合其他既有慣例。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月26日 (日) 21:08 (UTC)[回复]
  • 既然ACG的「命名先後次序」行之有效，為何不延伸至電視及電影？
  • 提案同時是建議改名，脫離ACG專題，改為依從父系「電視電影」類別。
  • 有需要時可啟動維基百科:命名常規 (書籍)計劃，將當中的「C」納入，但命名準則參考「A」還是「G」待社群商議。
.
  • 「A」：簡單來說，可以理解成提案是建議廢除「日本動漫遊戲條目命名常規」，本身「日本動漫遊戲條目命名常規」99.9%內容可以移植至提議的「電視電影命名常規」
  • 「C」：維基百科:命名常規 (書籍)計劃可以啟動，但依從「A」還是「G」仍可商議。
  • 「G」：原先「日本遊戲」只是更改了依從辦法，減低編輯者對選擇依從哪個常規的疑問。
  • 至於「整合其他既有慣例。」，即誇媒介命名，可能要重寫維基百科:命名常規#動漫和電子遊戲作品段落。
--唔好阻住我愛國（留言） 2024年5月27日 (一) 05:54 (UTC)[回复]
关于您最上方的总结，我就说一点吧。您列出維基百科:命名常規 (日本動漫遊戲條目)的6项看着长，但一言以蔽之就是「常用优于官方」。而这正是Wikipedia:命名常规_(电子游戏)#中文命名规范的第1项的两句话。遵守WP:ACGNAME就是遵守WP:NCVG第一条，反之亦然。在日本遊戲命名方式由「命名先後次序」原則改為沿用一般遊戲的「通用的中文名稱命名」原則中，您这个「改」字用得很不恰当--For Each element In group Next（留言） 2024年5月27日 (一) 16:46 (UTC)[回复]

關於影視條目，已有命名常規草案，請另外提案修改。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月28日 (二) 05:50 (UTC)[回复]

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

初步方向 (「A」部分/有足夠共識的話將同時掛在影視常規)

現行條文

1.官方譯名、正式譯名和通用譯名相同。
2.正式譯名和常用譯名相同，無官方譯名或官方譯名與其他譯名不相同。
3.只有通用譯名，或通用譯名和官方譯名、正式譯名不相同。此情況常見於先在網絡流行一段時間的作品，導致字幕組等非正式譯名較官方和正式譯名通用。此外也有其他原因導致官方和正式譯名不通用。在這個情況下，可按命名常規的使用事物的常用名稱規則使用通用譯名為條目名稱。
4.只有官方譯名和正式譯名。
5.只有正式譯名。
6.官方譯名、正式譯名和通用譯名均不存在時，應考慮在出現前述其中一種譯名後把條目移動至該名稱。

提議條文

1. 官方譯名/正式譯名/通用譯名/可靠來源譯名均一致
2. 正式譯名和大部分可靠來源（量化準則：按該譯名於各可靠來源出現比例）的譯名相同，無官方譯名或官方譯名與其他譯名不相同。
3.大部分可靠來源的譯名（量化準則：按該譯名於各可靠來源出現比例）
--
除非沒有可靠來源證實或可靠來源之間對使用某譯名的分歧很大，否則很難落到第四次序
--
4. 官方譯名（含中文字元）
5. 正式譯名 （含中文字元）
6. 官方譯名（不含中文字元）
7. 正式譯名 （不含中文字元）
8. 通用譯名 （字幕組等非可靠來源使用的譯名 ）

簡單說明：現行版本是2006年版本，當時沒有Netflix等串流平台播放，嚴重依賴極少量的電視台播放。 目前是2024年，網上串流服務市場已成熟，觀眾可透過OTT平台收看正版節目，仍然將字幕組譯名先於合規譯名已不合時宜，對正版節目是一種侮辱。至於「通用譯名」，何謂通用應優先交由可靠來源決定，而非單單一句「另有翻譯：」。 如果官方及代理商宣傳到位的話，可靠來源譯名相等於官方譯名及正式譯名，而且如果某譯名是官方譯名或正式譯名，應該有可靠來源予以支持或證實。另外這還是優質的二手來源，減低使用一手來源或不列來源的機率。--唔好阻住我愛國（留言） 2024年5月29日 (三) 02:49 (UTC)[回复]

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

1.官方譯名、正式譯名和通用譯名相同。
2.正式譯名和常用譯名相同，無官方譯名或官方譯名與其他譯名不相同。
3.只有通用譯名，或通用譯名和官方譯名、正式譯名不相同。此情況常見於先在網絡流行一段時間的作品，導致字幕組等非正式譯名較官方和正式譯名通用。此外也有其他原因導致官方和正式譯名不通用。在這個情況下，可按命名常規的使用事物的常用名稱規則使用通用譯名為條目名稱。
4.只有官方譯名和正式譯名。
5.只有正式譯名。
6.官方譯名、正式譯名和通用譯名均不存在時，應考慮在出現前述其中一種譯名後把條目移動至該名稱。

提議條文

1. 官方譯名/正式譯名/通用譯名譯名均一致
2. 正式譯名和曾被可靠來源證實的通用譯名的譯名相同，無官方譯名或官方譯名與其他譯名不相同。
3. 曾被可靠來源證實的通用譯名
--
除非完全沒有可靠來源證實或各譯名之間未能有足夠數量級差距，否則很難落到第四次序
--
4. 官方譯名（含中文字元）
5. 正式譯名 （含中文字元）
6. 官方譯名（不含中文字元）
7. 正式譯名 （不含中文字元）
8. 其他通用譯名 （字幕組等未被任何可靠來源使用的譯名 ）

--唔好阻住我愛國（留言） 2024年5月30日 (四) 01:42 (UTC)[回复]
正如維基百科需要列明來源，在這的次序可是二手（曾被可靠來源使用），一手（官方／正式），原創／來源不佳（字幕組）--唔好阻住我愛國（留言） 2024年5月30日 (四) 01:49 (UTC)[回复]
我觉得举几个例子进行说明或许不错，可让大家看看其具体如何执行以及执行中可能出现的问题。至于二手、一手的顺序，大体应该是如果二手能拉开足夠數量級差距时用二手，否则优先考虑一手。--Wengier（留言） 2024年5月30日 (四) 02:32 (UTC)[回复]
完善“通常译名（常用译名）”的定义即可，但没必要改动下面的判断顺序，因为应该一直以来“常用优先于官方”，严格来说，字幕组的发布内容也算是（译名的）一手来源信息。当时这个不考虑来源的可靠性也可能基于来源本身难满足可靠来源的要求。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月30日 (四) 02:36 (UTC)[回复]
貌似所谓“常用优先于官方”的原则只不过是“有时”，并仅限于维基百科中的部分内容。上面就说过“以前主手册在字面上，常用和官方平起平坐”，可见并非“一直以来”都是这样。再以华特迪士尼公司条目为例，其对话页中显然有部分使用者多次要求将其中的“迪士尼”改为“迪斯尼”（被认为在中国大陆更常用），但每次都被其他维基人以名从主人的原则拒绝。可见名从主人的原则对于这些条目命名之重要性。--Wengier（留言） 2024年5月30日 (四) 02:44 (UTC)[回复]
但现时命名常规，常用是第一级的“命名原则”，名从是第二级的“主要命名惯例”，就好像美国的名从为“美利坚合众国”、苏联的名从是“苏维埃社会主义共和国联盟”。而且过往命名常规版本下，常用也似乎一直压着名从。根据应该一位老人Chiefwei所说（[11]），名从实际上2008年引入的（oldid=8766872），而且不是来自en的，ACG的命名规范是2006年确定的。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月30日 (四) 03:04 (UTC)[回复]
说明一下，上面说的“官方”译名不是指所谓没人用的“官方”译名，而是指存在一定使用度的官方译名，虽然也许在所有中文译名中仅排名第二。比如说非官方的某中文译名的使用度为60%，而官方中文译名的使用度为40%。两者其实均为常用译名，而前者为最常用译名，后者则为官方+第二常用译名。但两者显然并不能拉开足夠數量級差距。上面主要说的就是类似这种情况（即使是2005年的ACG命名规范的文氏图显然亦认为官方+通用译名高于单纯官方或通用译名）。而不是说类似非官方的某中文译名的使用度为90%，而官方中文译名的使用度仅为10%之类的存在數量級差距的情况。阁下提到的老人Chiefwei所说的话，他自己承认“个人对这一条并不以为然”（表明为个人意见），同时承认“目前中文维基百科的命名常规确实是冲突的”。不同维基人显然可能对命名常规存在不同理解，像华特迪士尼公司等条目就是典型的例子。--Wengier（留言） 2024年5月30日 (四) 03:27 (UTC)[回复]
“一定使用度的官方译名”，就是同时具有“通用译名”和“官方译名”/“正式译名”两个性质的名字，实际上这样就属于序列1、序列2的情况。现在来看，这部分除了完善“通用译名”的定义外，没需要调整选择排序。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月30日 (四) 06:04 (UTC)[回复]
更改定義後，整體多了2個選項。故有必要重新調整選擇排序。--唔好阻住我愛國（留言） 2024年5月31日 (五) 02:05 (UTC)[回复]
而且
「3.只有通用譯名，或通用譯名和官方譯名、正式譯名不相同。此情況常見於先在網絡流行一段時間的作品，導致字幕組等非正式譯名較官方和正式譯名通用。此外也有其他原因導致官方和正式譯名不通用。在這個情況下，可按命名常規的使用事物的常用名稱規則使用通用譯名為條目名稱。
4.只有官方譯名和正式譯名。
5.只有正式譯名。
6.官方譯名、正式譯名和通用譯名均不存在時，應考慮在出現前述其中一種譯名後把條目移動至該名稱。」
寫到一舊舊咁（不清不楚），導致現行編輯者使用更簡單昜明的名從主人原則，GA上的條目標題也是以「名從主人」為依歸，而非「通用譯名」。--唔好阻住我愛國（留言） 2024年5月31日 (五) 02:11 (UTC)[回复]
“ （不）含中文字符”这个说法好像有冲突或者不必要，因为原规则也声明了“如正式译名使用或包含原名英文，条目名称可根据命名常规的原文常用规则沿用原名。”，下面也有举类似例子，也就是翻译后的名称（举例为官方性译名，但不确定有没涉及常用译名的例子）包含外文“不译”则保留“原文”。至于第三条的说法，后大部分是对于前面规定的一些补充解释，核心是前面“只有通用譯名 | 或通用譯名和官方譯名、正式譯名不相同”，也就是存在一个译名判断为“通用译名”，而没有官方性译名；或者存在官方性译名，但其无法判断为“通用译名”的，选具有“通用译名”性质的那个。其实看规则上面的文氏图，就是看某个译名具有三个属性中的哪种，按照规则的指定归属和顺序就是优选顺序。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月31日 (五) 03:34 (UTC)[回复]
又以「官方譯名」Kizuna no Allele作例，你認為 Kizuna no Allele 的排名是否應比 絆之Allele 高？--唔好阻住我愛國（留言） 2024年5月31日 (五) 05:32 (UTC)[回复]
使用Google搜索测试来看：“"Kizuna no Allele" -"絆之Allele" -"絆的Allele" -wiki -"维基" -"維基" -site:wikipedia.org”的索引量为203000，“"絆之Allele" -"Kizuna no Allele" -"絆的Allele" <排除词，略>”为303000，“"絆的Allele" -"絆之Allele" -"Kizuna no Allele" <略>”为6330，从数量级的话“Kizuna no Allele”，“絆之Allele”相近（虽然前者基本上都是英文的搜索内容），都近似常用，前者具有“官方”性质（也能使没完全翻译？），我认为根据规则来看，选“Kizuna no Allele”似乎也可以。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月2日 (日) 07:30 (UTC)[回复]
問題是這裏是中文維基百科，而非其他文維基百科。論搜尋量來說，一定是外文比例佔優，但新定義如何確保中文地位為優先？--唔好阻住我愛國（留言） 2024年6月2日 (日) 14:22 (UTC)[回复]
字幕组等中文译名（只要有一定使用量，不管能不能找到可靠来源）应高于纯粹的非中文名称。--Wengier（留言） 2024年6月2日 (日) 15:41 (UTC)[回复]
例如规则举例Fate/stay night的说明（或者说Fate系列）。如果非要中文的话，那只能套用通用常规的“使用中文”命名原则（与“常用”同等）。（好吧，还有IBM、Google）——Sakamotosan路过围观 | 避免做作，免敬 2024年6月3日 (一) 05:55 (UTC)[回复]
那麼，用第二個計算又如何？
  • 通用譯名（常用譯名）：該作品在某地或更多地方經常使用或普遍使用的中文名字／譯名。其通用程度可以可透過搜尋引擎測試等方式判斷，該作品的特定名字／譯名於搜尋引擎測試（並使用「所有中文結果」功能篩選）較其他名字／譯名在數量上足夠拉開數量級差距，並曾至少被一個可靠來源引述的可優先使用，另須遵守Wikipedia:關注度所訂立的標準。
--唔好阻住我愛國（留言） 2024年6月3日 (一) 11:08 (UTC)[回复]
seems good，但是否保留“使用译名的书籍册数、出版量”这个判断方式（虽然感觉是判断官方的出版物，但是否也适用于其他纸质出版物的判断，例如以前的资讯杂志）。其实“Kizuna no Allele”对于例外规则也对不上：“如正式译名使用或包含原名英文”，这个应该是官方译名？——Sakamotosan路过围观 | 避免做作，免敬 2024年6月4日 (二) 03:29 (UTC)[回复]
按現行標準來說，使用「使用譯名的書籍冊數、出版量」已不合時宜。因書籍冊數及出版量只是傳統書才適用。對於近期興起的連載書及遊戲改編，完全不適用。
如以「書籍冊數、出版量」為標準，即提升正式譯名的地位。--唔好阻住我愛國（留言） 2024年6月4日 (二) 13:10 (UTC)[回复]
“虽然感觉是判断官方的出版物，但是否也适用于其他纸质出版物的判断，例如以前的资讯杂志”，当然如果认为现在基本上没有纸质非官方出版物，避免和官方的定义重合的，也行。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月5日 (三) 01:21 (UTC)[回复]
另外看了GA的评选上，好像也没有提及明显的命名要求，如果需要满足规范，命名规范的话就是跟随通用的命名常规和针对性的ACG命名常规。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月31日 (五) 03:40 (UTC)[回复]
就是有ACG條目當選了GA而沒有以通用翻譯為依歸…--唔好阻住我愛國（留言） 2024年5月31日 (五) 05:27 (UTC)[回复]
没看懂？——Sakamotosan路过围观 | 避免做作，免敬 2024年6月2日 (日) 07:30 (UTC)[回复]
好像GA并有相关的限制？——Sakamotosan路过围观 | 避免做作，免敬 2024年6月3日 (一) 05:55 (UTC)[回复]

雖說我個人覺得外文衍伸作品（小說、劇集、電影、音樂和遊戲）其名稱應該和原作相同，但它們都該分別看待，

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

「A」、「C」、「N」部分第二版

只更改定義並新增：

現行條文
  • 通用譯名（常用譯名）：該作品在某地或更多地方經常使用或普遍使用的中文譯名。其通用程度可以使用譯名的書籍冊數、出版量等來驗證，並須遵守Wikipedia:關注度所訂立的標準。
提議條文
  • 通用譯名（常用譯名）：該作品在某地或更多地方經常使用或普遍使用的中文名字／譯名。其通用程度可以可透過搜尋引擎測試等方式判斷，該作品的特定名字／譯名於搜尋引擎測試（並使用「所有中文結果」功能篩選）較其他名字／譯名在數量上足夠拉開數量級差距，並曾至少被一個可靠來源引述的可優先使用，另須遵守Wikipedia:關注度所訂立的標準。

概念：

  • 此部分不適用於日本遊戲。關於日本遊戲，另請參閱電子遊戲手冊的命名次序。
  • 條目／段落命名次序須以條目／段落的中心媒介為首。如該條目／段落主要描述小說，條目／段落標題則須以小說走命名程序。

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

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

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

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

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

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

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

非可靠来源毕竟难登大雅之堂，方针上我就没有明写。另一个就是绝对数量的问题，虽然我上面留了个坑：如果只有惟一一个可靠来源提及了一个译名，这个名称到底算常用还是偶然 耸肩--For Each element In group Next（留言） 2024年6月7日 (五) 13:53 (UTC)[回复]
這個可以，如果更改了定義，應該還可以處理Gundom問題，將Gundom系列重新列入本手冊規管。畢竟不可能為公平性而將Gundom系列而用英文表達（中文地區Gundom沒有通用性，只有鋼達／高達）。
是的，是用「搜尋量」決定通用性，如果「鋼達」使用率高就用「鋼達」，如果「高達」使用率高就用「高達」。--唔好阻住我愛國（留言） 2024年6月8日 (六) 10:40 (UTC)[回复]
回應「 如果只有惟一一個可靠來源提及了一個譯名，這個名稱到底算常用還是偶然」，故建議先計算搜尋量，然後再找可靠來源補底。--唔好阻住我愛國（留言） 2024年6月8日 (六) 11:48 (UTC)[回复]
我的意思是，不是由搜索量本身决定，而是参考搜索量决定。或者说先检查可靠来源，可靠来源没有惯例用法后，再找搜索量补底。再或者说，先统计可靠来源中的搜寻量，如果可靠来源（几乎）没结果，再放开到其他网站。您的理解和我的表述可能还是不同。--For Each element In group Next（留言） 2024年6月8日 (六) 14:20 (UTC)[回复]
原來如此，可以。--唔好阻住我愛國（留言） 2024年6月8日 (六) 14:33 (UTC)[回复]
另外，建議閣下同時參與下方WP:IS的討論，因為下方討論內容會影響本提案的這句（應依據某地的獨立可靠中文來源）應如何理解。--唔好阻住我愛國（留言） 2024年6月8日 (六) 14:42 (UTC)[回复]

「A」、「C」、「N」部分第三版

更改如下：
1. 「日本動漫遊戲」（NC:ACG）更名至「日本小說、漫畫及動畫」（NC:ACN）
註：遊戲有遊戲手冊，談不上兩本手冊共同管理同一項目，而且原標題怱視了小說的存在。

2.

現行條文
  • 通用譯名（常用譯名）：該作品在某地或更多地方經常使用或普遍使用的中文譯名。其通用程度可以使用譯名的書籍冊數、出版量等來驗證，並須遵守Wikipedia:關注度所訂立的標準。
提議條文
  • 通用译名（常用译名）：作品在某地或更多地方普遍使用的中文译名（名称）。原则上，应依据某地的独立可靠中文来源，来判定译名在该地是否通用。若可靠来源没有形成使用惯例（如无可靠来源介绍主题），则编者可参考搜索量（並通過「所有中文結果」進行篩選）等资料，於條目討論頁透过讨论决定名称通用性。条目应有一个最通用译名，其他译名在使用量上未与最通用译名拉开数量级差距的，亦属于通用译名之列。
現行條文

只有通用譯名，或通用譯名和官方譯名、正式譯名不相同。 此情況常見於先在網路流行一段時間的作品，導致字幕組等非正式譯名較官方和正式譯名通用。此外也有其他原因導致官方和正式譯名不通用。在這個情況下，可按命名常規的使用事物的常用名稱規則使用通用譯名為條目名稱。

提議條文

只有通用譯名，或通用譯名和官方譯名、正式譯名不相同。 此情況常見於影片發行商/書藉出版商或代理商沒有引入相關作品到中文地區，導致機器譯名、自媒體譯名等非正式譯名於中文社群通用。此外也有其他原因導致官方和正式譯名不通用。在這個情況下，請依照通用譯名定義決定條目名稱。

註：這是2024年更新版（試行），如一年內效果顯著及測試成功（意指在2024-2025年新建或大規模修改的條目標題符合科學化通用標題為首的要求。），2025年將明確提出延伸至其他電視節目及相關條目。

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

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

註：2006年沒有OTT平台，2024年有大量OTT平台，外地片源以比當年更容易進入中文社群，回應上方的編輯者語道今時今日還在口中提及字幕組等盜版平台是放不上枱面（桌子上），故簡單修改了使用通用譯名的原因。--唔好阻住我愛國（留言） 2024年6月11日 (二) 13:56 (UTC)[回复]

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

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


公示版本

標題：維基百科:命名常規 (日本小說、漫畫及動畫條目)（NC:ACGN）

此規則是用於規範ACG的日本小說、漫畫及動畫部分條目及段落的命名規則。由於ACG條目中以日文系作品佔大多數，但根據《命名常規》，维基條目通常應以中文命名，因此社群在經討論後制定此規則以統一條目命名方式，並避免因條目命名問題而出現移動戰。

此規則之多數定义与條文于2006年ACG相关条目译名、命名决议投票、相關討論及2024年通用譯名定義更新議案中获得社群共識通过。

定義
  • 官方譯名：原作者、其他持有原作品版權的公司、組織或其法定分支機構所訂定及公佈的中文譯名。
  • 正式譯名：獲原作者、其他持有原作品版權的公司、組織或其法定分支機構授權出版、播放或發行該作品的機構或代理商所使用的中文譯名。
  • 通用譯名（常用譯名）：作品在某地或更多地方普遍使用的中文譯名（名稱）。原則上，應依據某地的獨立可靠中文來源，來判定譯名在該地是否通用。若可靠來源沒有形成使用慣例（如無可靠來源介紹主題），則編者可參考搜索量（並通過「所有中文結果」進行篩選）等資料，並於條目討論頁透過討論決定名稱通用性。條目應有一個最通用譯名，其他譯名在使用量上未與最通用譯名拉開數量級差距的，亦屬於通用譯名之列。

按上述規則，以下是一個關於哆啦A夢（日语：ドラえもん）譯名的例子：

官方譯名 正式譯名 通用譯名
（常用譯名）
簡體中文：哆啦A梦[1]

繁體中文：哆啦A夢[2]		 中國大陸地区：哆啦A梦 (艾影(上海))[3]

臺灣地區：哆啦A夢 (國際影視]])[4]

港澳地區：多啦A夢 (myTV SUPER)[5]		 可靠來源：
哆啦A梦（中國大陸：環球時報[6]；台灣：TVBS [7]）

多啦A夢（香港：Yahoo 新聞[8]）
按搜尋量數據：
機器貓小叮噹、超能小叮噹、神奇小叮噹、萬能小叮噹、蓝胖子、機器貓、叮噹
優先次序

下圖說明了譯名使用的優先次序。

以下為上圖中各項目的說明。條目標題和正文中對作品的正式稱呼的譯名均應使用優先次序最高的譯名。如其後出現優先次序更高的譯名，應經討論確認使用新的譯名後移動條目。

  1. 官方譯名、正式譯名和通用譯名相同。
  2. 正式譯名和常用譯名相同，無官方譯名或官方譯名與其他譯名不相同。
  3. 只有通用譯名，或通用譯名和官方譯名、正式譯名不相同。
    • 此情況常見於影片發行商/書藉出版商或代理商沒有引入相關作品到中文地區，導致機器譯名、自媒體譯名等非正式譯名於中文社群通用。此外也有其他原因導致官方和正式譯名不通用。在這個情況下，請依照通用譯名定義決定條目名稱。
  4. 只有官方譯名和正式譯名。
  5. 只有正式譯名。
  6. 官方譯名、正式譯名和通用譯名均不存在時，應考慮在出現前述其中一種譯名後把條目移動至該名稱。

下方段落沒有任何更改

如無反對意見，3日後啟動公示程序。--唔好阻住我愛國（留言） 2024年6月16日 (日) 07:29 (UTC)[回复]

@Cwek、@Leiem、@For_Each_element_In_group_Next、@Milkypine、@Wengier、@甜甜圈真好吃:
.
7日內沒有人表示異議，因此本提案現正公示，由2024年6月18日公示7日至2024年6月25日。以上！--唔好阻住我愛國（留言） 2024年6月18日 (二) 14:07 (UTC)[回复]
@HK5201314：可否簡單解釋修改了什麼？上方討論過於冗長。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 16:46 (UTC)[回复]
1.通用譯名定義（由 書本出版量 改為 依據可靠來源，如沒有可靠來源記錄，則依靠搜尋量）。
2.移除日本遊戲、新增日本小說。--唔好阻住我愛國（留言） 2024年6月19日 (三) 00:16 (UTC)[回复]
@Ericliu1912:即
#「A」、「C」、「N」部分第三版內容。
另外，這是為期一年的測試，看看變更定義後是否仍有效處理命名問題。有效的話才想其他延伸議案。--唔好阻住我愛國（留言） 2024年6月19日 (三) 00:20 (UTC)[回复]
「簡體中文的命名」／「繁體中文的命名」是什麽？--— Gohan 2024年6月19日 (三) 12:30 (UTC)[回复]
「原始碼」表格與上下文內容關聯不大，示意什麽？而且全文轉換規則若與標題轉換規則一致，則是多餘，平添日後維護勞力；zh:的「標題名稱」若與其後地區詞相同，也是多餘；不帶公共轉換組及其他地區詞或許不是妥當示範。内鏈轉換語法頁面即可，無需在此示範。--— Gohan 2024年6月19日 (三) 12:36 (UTC)[回复]
這個（繁簡轉換及原始碼）是2006年的共識，不在本提案討論範圍。不過閣下的意見有助整理一年後的虛構命名手冊的提案。--唔好阻住我愛國（留言） 2024年6月19日 (三) 13:18 (UTC)[回复]
2006年的過時、違規內容也應及時清除，如不清除，等於再次肯定。2006年尚未有星、馬、澳變體、公共轉換組，以及地區詞轉換方針指引，今時不同往日。2006年之後的几年，機械人還會將zh-cn:替換爲zh-hans:，zh-tw:替換爲zh-hant:，現已違反Wikipedia:字詞轉換處理#繁簡與地區詞轉換分開；如再保留「為方便處理紛爭，簡體中文的命名將以中國大陸地區的標準評核，而繁體中文的命名則以港臺地區的標準評核。」，即鼓動編者在已可轉換地區詞的zh-cn、zh-tw之外，違規另加與此二者一致的zh-hans、zh-hant，甚或如十幾年前的機械人一般，將zh-cn、zh-tw替換為zh-hans、zh-hant。去除此句以及表格，不會阻碍對此ACGN規則理解、有利無弊，另在適宜字詞補充内部連結至Wikipedia:地区词处理即可。最後一句「若港臺地區和中國大陸地區的最合適譯名不相同，港臺地區命名應使用繁體中文，中國大陸地區則應使用簡體中文命名。」當今亦是多餘的廢話，宜去除或改爲「香港、澳門、臺灣譯名應使用繁體中文，中國大陸、馬來西亞、新加坡譯名則應使用簡體中文。」。--— Gohan 2024年6月20日 (四) 00:35 (UTC)[回复]
不是我不想改，而是共識認為不要搞那麼多東西。所以在首句列出「此規則之多數定義與條文於2006年ACG相關條目譯名、命名決議投票、相關討論及2024年通用譯名定義更新議案中獲得社群共識通過。」
.
另外我要重申，這本手冊是需要壽終正寢，因為我的目標是以更大範圍的「虛構命名手冊」取代NC:ACGN--唔好阻住我愛國（留言） 2024年6月20日 (四) 10:53 (UTC)[回复]
我同意Gohan君的意見，修正字詞轉換方面的表述。（建議Gohan君直接把改法貼出來，很多編者不是太明白這一方面）如果現在不想討論，也建議將這一部分用省略號表述，意味著「未經討論故不修改」。把原文拷貝一遍，這就好像這部分是經過討論后再度確認的結果。--For Each element In group Next（留言） 2024年6月20日 (四) 14:56 (UTC)[回复]
还是认为避免原地扩大已有的规则。如果针对其他媒体也有自己适用的规则的话，可以移植一套过去。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 01:08 (UTC)[回复]
另外根據MOS:PSEUDOHEAD，目錄應該用== 標題 ===而不是; 標題表示，我排了一下版。--For Each element In group Next（留言） 2024年6月20日 (四) 15:01 (UTC)[回复]
當「虛構命名手冊」出場後，這本手冊就可以壽終正寢了！--唔好阻住我愛國（留言） 2024年6月19日 (三) 13:20 (UTC)[回复]
抱歉，我必須在這裡放入一個{{reflist-talk}}，才能避免在本頁末尾看到一大串不知屬於哪個討論主題的參考資料。--CaryCheng（留言） 2024年6月24日 (一) 17:13 (UTC)[回复]

参考資料

  1. ^ 哆啦A梦未来百货店官方網站
  2. ^ 哆啦A夢未來百貨公司官方網站
  3. ^ 艾影(上海)官方網站
  4. ^ 哆啦A夢台灣官網
  5. ^ myTV SUPER 多啦A夢播放清單
  6. ^ 潘小多. 哆啦A梦诞生无关梦境. 環球時報. 2024-05-30. 
  7. ^ 顏敏翔. 不要再叫「鹹蛋超人」！日影集已正名《超人力霸王》24年). 2024-01-05. 
  8. ^ 多啦A夢巡展七月登陸香港 大雄行「藍地毯」致敬港產片 K11 MUSEA設收費展區. 2024-05-24. 
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

議程2:廢除不合時宜條文

議程2: NC:ACGN廢除不合時宜條文獲得通過！--唔好阻住我愛國（留言） 2024年7月6日 (六) 14:10 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
建議從「譯名決定辦法」至文末的條文如下：
譯名決定辦法
條目命名爭議的解決
  • 若對條目名稱有異議，需於條目討論頁提出討論。
  • 若各地最合適譯名不同，香港、澳門、臺灣譯名應使用繁體中文，中國大陸、馬來西亞、新加坡譯名則應使用簡體中文。
已述必要更動不再贅述，説明其他順便的更動：
  1. 「符合上述譯名優先順序的使用規範」中「使用規範」像是強行宏大化的拼凑詞語，改爲更爲實在、上文已有的字詞。
  2. 「其他地區的譯名差異……（即「先到先得」原則）」中「先到先得」與前文連讀不通，調整語序。
  3. 「複數條目」可低至2，顯然只有2個條目使用的地區詞轉換項目不宜建立相應公共轉換組，故改爲「不少條目」。
  4. 公共轉換組不止是模板，還有模組，故去除「模板」。
— Gohan 2024年6月21日 (五) 02:06 (UTC)[回复]
我看不到這個改了什麼主體。未必需要公示也可按閣下的條文直接更改。--唔好阻住我愛國（留言） 2024年6月21日 (五) 11:35 (UTC)[回复]
依據程序恐難成事，除非閣下能召集足夠人數同意免除公示。或者，閣下的版本既然在「译名决定办法」章節之下幾無變動，就裁去「译名决定办法」章節之後的部分，不作公示，以免被我繼續反對；閣下版本剩餘的部分與我的提案（「译名决定办法」章節之後的部分）一齊或分別公示，亦互不影響效力。--— Gohan 2024年6月21日 (五) 14:12 (UTC)[回复]
刪減了非公示部分--唔好阻住我愛國（留言） 2024年6月21日 (五) 17:05 (UTC)[回复]
僅通知管理員@Ericliu1912實行移動手冊。--唔好阻住我愛國（留言） 2024年6月25日 (二) 10:38 (UTC)[回复]
即刻起公示此案（「譯名決定辦法」至文末的條文）7天。— Gohan 2024年6月29日 (六) 08:26 (UTC)[回复]
(＋)支持--唔好阻住我愛國（留言） 2024年6月29日 (六) 10:09 (UTC)[回复]
@神秘悟饭:
It’s time--唔好阻住我愛國（留言） 2024年7月6日 (六) 11:12 (UTC)[回复]
公示期滿，修訂通過。（您亦可宣佈通過）--— Gohan 2024年7月6日 (六) 12:40 (UTC)[回复]
點都要要知會你一聲/無論如何也要讓你知道 ，因為是你發起的。--唔好阻住我愛國（留言） 2024年7月6日 (六) 14:03 (UTC)[回复]
Wikipedia:命名常規 (電子遊戲):
提議條文

請在命名條目時遵守維基百科:命名常規。

而 維基百科:命名常規 (日本小說、漫畫及動畫條目)則公示@神秘悟饭藍框版本--唔好阻住我愛國（留言） 2024年6月25日 (二) 12:05 (UTC)[回复]

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

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

新標題已被公示記錄了。
—
公示版本
標題：維基百科:命名常規 (日本小說、漫畫及動畫條目)（NC:ACGN）--唔好阻住我愛國（留言） 2024年6月25日 (二) 10:40 (UTC)[回复]
那就仅补充调整Wikipedia:命名常规 (电子游戏)的描述则可了。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月25日 (二) 11:09 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

議程3:管理員改名工作進度

目前，本提案2個議程已獲得通過，但隔了兩個星期，管理員還未執行重新命名工作，相關申請已在WP:管理員佈告版提報。此討論將繼續維持，直至管理員完成此工作。--唔好阻住我愛國（留言） 2024年7月6日 (六) 14:24 (UTC)[回复]

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

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

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

現行條文

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

提議條文

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

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

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

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

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

提議條文

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

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

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

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

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

提議條文

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

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

離題

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

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

反提案

LuciferianThomas版本

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

§ 標準措施 §§ 回退限制

現行條文

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

提議條文

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

§ 時長

現行條文

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

提議條文

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

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

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

Cmsth11126a02版本

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

§ 時長

現行條文

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

提議條文

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

§ 延長及重新確認限制

現行條文

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

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

提議條文

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

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

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

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

LuciferianThomas版本公示

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

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

管理操作复核的议题

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

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

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

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

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

Ping有对提案发表意见的人@日期20220626、ChiuHsiao1221、Shwangtianyuan、HYHJKJYUJYTTY。--桐生ここ★[讨论] 2024年6月14日 (五) 07:55 (UTC)[回复]
本人是(＋)支持，社群考慮設定類似「請求封鎖」的機制，確實能解決很多不必要爭議，非純破壞行為，至於解封請求，建議擴大WP:AARV的使用，我也支持，--HYHJKJYUJYTTY（留言） 2024年6月14日 (五) 08:10 (UTC)[回复]
本人亦是倾向(＋)支持。针对某位编辑账号的封禁无异于是在维基百科范围类对某人“执行死刑”。既然现实里文明国家的死刑都有复核和救济制度，那我认为维基社群也应该考虑。除了机器人账号或纯粹破坏行为外，针对其他行为的封锁账号行为要给于“拟被封所账号者”一个申诉和申请复核的渠道。--Chiu Hsiao (✉️Message) 2024年6月14日 (五) 08:20 (UTC)[回复]
原則上同意擴大AARV，但實際執行上對社群整體正確解讀及執行方針有極大疑慮。在社群本身已經存在失能、有不少用戶連最基本的方針指引都願意無視的情況下，我不認為當前的社群整體而言有足夠能力作出完全合乎方針指引及背後原則理解，以此判讀管理人員的管理行為是否恰當。光是社群中仍對於「不限期」錯誤理解為「永久」或「比其他更重」的觀點（WP:不限期不等於永久才是正確理解）已經反映社群缺乏判讀封鎖是否恰當的能力。在多個解封案例中，多名用戶未有真的分析封鎖理據、沒有考量方針指引要求、未有從執行人的視角去看事件，甚至只是因為跟管理人員的個人恩怨就直接提出反對，反映社群缺乏作此判斷的能力。原則上AARV是一件好事，但實際需要達到的效果目標及需要的技巧跟擔任仲裁員無異；而仲裁委員會都尚會是社群經選舉選上去的一群人，AARV的參與社群卻是未經社群檢視資質的用戶技能參與，粗暴點說就是平民版仲裁，跟仲裁委員會的公信力還要差個天差地別。
請求封鎖有極度嚴重社群程序官僚化及暴民政治的風險，如同上方所述，社群整體而言本身缺乏正確判讀什麼情況適合或不適合封鎖的能力，也往往主張採取不足以阻截擾亂編輯的措施。請求封鎖涉及管理員權限，又是由誰來判讀共識又是一大問題：社群本身缺乏判讀共識的能力（永遠只會點人頭而不看論據強弱），管理員自己判讀共識又產生一個會起疑的點，簡單來說就是沒解決任何問題，還產生了更多的問題的提案。--路西法人 2024年6月14日 (五) 09:57 (UTC)[回复]
反對引入仲裁制度的人，卻提案引入一個目標近似仲裁的機制，但這機制極度取決於社群能力（惟社群已經展現其失能），卻也完全沒有仲裁要求的嚴謹。在社群缺乏有關判斷能力、扭曲理解方針、無視方針原則的行為獲得控制前，AARV就只是一個跟當前RFDA沒分別，只會製造更多爭議的體制。--路西法人 2024年6月14日 (五) 10:27 (UTC)[回复]
那这么说吧，蓝桌的调查报告很好，如果封禁非纯破坏用户前，要求管理员写一份调查报告呢？--桐生ここ★[讨论] 2024年6月14日 (五) 11:11 (UTC)[回复]
包括所有差异链接，逐条说明为什么违反方针，决定量刑多久，决定量刑的理由。如果当事人怎样做可以获得原谅和解封。或者遭不限期封禁者，多久之后提出申诉可以考虑解封。--桐生ここ★[讨论] 2024年6月14日 (五) 11:17 (UTC)[回复]
管理員在封鎖理據中已經提供理由和對應的diff即可視作已提供封鎖報告。如果處理每一個非破壞用戶都需要這樣寫的話，用意是好但極度官僚，手續過多可能導致願意處理此類封鎖的管理員越來越少，反而變成放任了這些擾亂者繼續搞事。不過，我是同意可以要求管理員在執行不限期封鎖時在封鎖訊息下寫出不限期封鎖的考量，並在有可預見的改善可能（即不屬VOA、SPA或再次封鎖的用戶）情況下提供WP:不限期不等於永久的說明，並寫說需要對方瞭解什麼方針指引即可獲得解封（第二次機會）。
至於詳細的封鎖報告，則應是在AARV或仲裁的情形下提供。惟發起AARV的門檻過低，除了擔憂AARV參與者素質外，還擔憂會被濫用以針對特定管理員，製造毫不必要的工作量。--路西法人 2024年6月15日 (六) 00:24 (UTC)[回复]
你维管理员封禁此类人士已经圣母到极致，若是再加调查报告这种减速带我看你维是不想请捣乱的人离开了？--0xDeadbeef (留言) 2024年7月6日 (六) 16:16 (UTC)[回复]
Wikipedia:管理员布告板/编辑争议和Wikipedia:管理员布告板/其他不当行为已经复杂到我不愿意碰了，再弄这个的话更不会没事去看了....--百無一用是書生 (☎) 2024年6月17日 (一) 02:14 (UTC)[回复]
社群針對此議題是不是討論過不少次了？為什麼我感覺幾個月以前纔有一次。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 12:50 (UTC)[回复]
基本上這種制度是聊勝於無，比起現在的情況肯定是利大於弊。但也要指出，管理員執行封鎖操作時，理論上已經要確定當事人違反本站政策，「独自判断引起争议」可以是對管理員裁量權的事後合理質疑，但不是限制管理員行使封鎖權限的前提。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 12:52 (UTC)[回复]
支持，帮助明确共识。但裁量权目前还是得有。--YFdyh000（留言） 2024年6月14日 (五) 14:24 (UTC)[回复]
理解提案的用意，樂見其成。但在實踐上可能會如路西法人君所說產生更多問題，或許會造成另一個管理員布告板。明白提案及用戶對管理權運用的憂慮。－千村狐兔（留言） 2024年6月14日 (五) 15:53 (UTC)[回复]
建議統稱「封禁探討」，專門討論用户行為是否足以封禁，因為有些人請求社群告訴他怎麼辦，提報或申訴可以其他渠道發起。 -- 月都 ※ 2024年6月16日 (日) 18:02 (UTC)[回复]
我覺得也應該探討一下為什麼管理員們不願意碰WP:ANMWP:AN3，如果ANM、AN3都不願意碰，再開一個AARV事實上只會讓管理員的事情變更多，我想這某種程度上並沒有解決問題，反而多了另一個問題，再提醒一下管理員也是"志願者"。
社群願意的話亦可探討為什麼管理員越來越不活躍，還有什麼方法吸引管理員回來幫忙掃地，或是另外尋求一條出路解決這個問題。--~~Sid~~ 2024年6月17日 (一) 13:04 (UTC)[回复]
額外補充我並不是要反對提案，只是不希望社群設立之後卻沒有達到預想的效果。--~~Sid~~ 2024年6月17日 (一) 13:05 (UTC)[回复]
以“有共識後再執行封鎖”來處理“管理員獨自判斷”的潛在弊端可能不符比例原則，我更傾向於引入類似助言（日语：助言）的機制，要求管理員在執行不限期封鎖前應先取得至少一位未涉事的第三方用戶的同意，以確保所有不限期封鎖的執行都不違反比例原則。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 13:35 (UTC)[回复]
我認為這個方法可行。--~~Sid~~ 2024年6月18日 (二) 14:59 (UTC)[回复]
少打字，修正留言。~~Sid~~ 2024年6月18日 (二) 15:00 (UTC)[回复]
不合適。破壞者還要助言？說這是明顯例外吧，但又有什麼應該是例外呢？到頭來還是要爭吵。如此官僚主義弊病過重，我想事後複查比事前在那邊極其複雜地商榷認定界線要容易得多。另外我還是要指出，理論上若管理員是依據社群討論通過的方針與指引執行封鎖，就是在確保社群共識得到實踐；故除理據不清之外，通常不能說管理員「未依共識」執行封鎖，至多是對方針與指引認知有爭議。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 17:46 (UTC)[回复]
啊，我忘了提及「非純破壞行為」的前設。Sanmosa 蚌埠 2024年6月19日 (三) 05:47 (UTC)[回复]
支持@Sanmosa的助言机制，这个方法应该可行。--桐生ここ★[讨论] 2024年6月20日 (四) 19:20 (UTC)[回复]
有点怀疑“未涉事的第三方用户”的评判可能出现争议，并可能使部分用户有意避嫌、延后表态（私下抱团沟通）。--YFdyh000（留言） 2024年6月21日 (五) 11:57 (UTC)[回复]
關於「私下抱團溝通」，根據WP:共識，僅建議不應私下討論維基百科相關的事項，個人建議需更改這段的用詞至嚴禁私下討論維基百科相關的事項，並配合利益申報 （如該名編輯者曾在外站討論，則應當「涉事用戶」處理並應主動向社群申報），否則的話也沒有意思。關於最近私下討論的例子，就是路西法人的共識議案，完全將跳過了共識形成過程便產生共識，此不合程序公義。如果之後AARV容許私下抱團溝通，那只好反對。
.
「維基外的討論。我們不鼓勵編者在其他網站、論壇、聊天工具、電子郵件或其他本專案外的地方討論。這些討論在「維基內」決定共識時是不予考慮的，並在它們被揭發後會引發猜疑和不信任情緒。儘管我們需要在維基外討論少數問題以顧及隱私，但絕大多數維基百科相關的事項都應在維基百科上討論，這樣它們將對所有參與者可見。」--唔好阻住我愛國（留言） 2024年6月21日 (五) 12:40 (UTC)[回复]
我覺得與其在客棧提案（現行寫法），不如改置管理員布告板的子布告板（可命名為「管理操作覆核」），集中處理涉及高階權限的使用行為。既有之「其他不當行為」子布告板，則繼續留作解決普通使用者爭議之處。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 01:09 (UTC)[回复]
(＋)支持。--桐生ここ★[讨论] 2024年6月29日 (六) 21:17 (UTC)[回复]
誠如書生君所言，本站處理相關問題之場所一向不缺——Wikipedia:管理员布告板/编辑争议和Wikipedia:管理员布告板/其他不当行为。所以這個與前列兩者分別何在？固然多一人一起討論如何行使權限，未嘗不可。但本站有足夠人手麼？在下甚是疑惑。本提案立意良善，但欠缺具體系統設計。坦白說，就是怕管理員濫權，但又沒有給管理員足夠配套。然後，調查事情不一定要管理員權限，所以又有多少人有能力且願意擔起此責？--J.Wong 2024年7月1日 (一) 13:46 (UTC)[回复]
我只是特别羡慕ja有这个；对于解封，en有这个，看起来都是和气的达成了共识，不知道为什么在zh，最后都是客栈吵得不可开交，甚至上RFDA解决。--桐生ここ★[讨论] 2024年7月1日 (一) 14:12 (UTC)[回复]
立意就是希望大家多用AARV，最后不用走到RFDA这一步。--桐生ここ★[讨论] 2024年7月1日 (一) 14:28 (UTC)[回复]
所以這次有提出過使用嗎？有空間容許第三方審核及說話的餘地嗎？--J.Wong 2024年7月2日 (二) 05:46 (UTC)[回复]
其實這次事件當中是見到Bluedeck有意願作出獨立調查，但本站社群之中，竟然未見有人願意伸出援手。
然後就去羨慕這個，羨慕那個……
縱觀整個討論，在下見到大家更關心程序，數夠票就下一步，甚少理會雙方所言是否在理，能否經得起第三方審核。如果這點不變，開再多討論空間，閣下都只能繼續羨慕。--J.Wong 2024年7月2日 (二) 05:57 (UTC)[回复]

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

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

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

人事任免投票草案

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:人事任免投票資格。

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

原始提案

目前，人事任免投票存在漏洞。用戶可以先編輯條目50次（小修改不需1小時便可完成），等待7天後便可在無Captcha驗證的情況下利用自動化程式編輯條目1450次，符合人事任免投票的第二條資格，因此提出此草案（由於人事任免投票的保密性，目前尚不知是否有類似案例）。

現行條文

凡管理人員解任投票聯署或上任投票開始之前，符合以下兩項之至少一項條件者有權投票：

  1. 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）；

2. 編輯至少3000次，或編輯條目至少1500次。

以上所稱「編輯」，均指在中文維基百科的編輯，且不含明顯的破壞和測試。

提議條文

凡管理人員解任投票聯署或上任投票開始之前，符合以下兩項之至少一項條件者有權投票：

1. 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）；

2. 註冊滿120天，編輯至少3000次，或編輯條目至少1500次。

以上所稱「編輯」，均指在中文維基百科的編輯，且不含明顯的破壞和測試。

--WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 10:39 (UTC)[回复]

具體天數還可進一步商討。--WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 10:41 (UTC)[回复]
(＋)傾向支持：参与人事任免投票应熟悉方针指引，对申请上任或被解任的人员有一定的了解，限制注册天数（或像延伸确认用户一样限制90天）可以进一步防止傀儡等问题，且大部分一般用户（理应满足熟悉方针指引等前述条件的用户）不会受影响。--自由雨日（留言） 2024年6月18日 (二) 10:49 (UTC)[回复]
對了，第二條中可以再加上「近90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）」。--WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 10:56 (UTC)[回复]
听上去只是增加了筹备的时间成本。希望有更可靠方案对抗操作多重账号和自动刷编辑。--YFdyh000（留言） 2024年6月18日 (二) 12:45 (UTC)[回复]
请问阁下有什么(＆)建議吗？--WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 12:56 (UTC)[回复]
（就“對抗操作多重帳號”而言）一個很費全域CUer的做法會是要求CUer在投票結束後對所有投票、發言的用戶一律進行查核，但我不認為meta會接受這個做法，這個做法可能在zhwiki再度擁有本地CUer時才比較適合實行。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 13:25 (UTC)[回复]

提案2

凡管理人員解任投票聯署或上任投票開始之前，符合基础条件，并符合以下兩項之至少一項次要條件者有權投票：

基础条件

聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）；

次要条件

1. 解任投票聯署提出或上任投票開始120天前，編輯至少500次；

2. 用户参与投票时，註冊滿120天，且編輯至少3000次或編輯條目至少1500次。

以上所稱「編輯」，均指在中文維基百科的編輯，且不含明顯的破壞和測試。

--WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 13:51 (UTC)[回复]

@Sanmosa,YF,自由雨日 我修訂了新的草案版本，請大家檢閱--WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 14:04 (UTC)[回复]
代為微調，以免產生歧義。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 14:10 (UTC)[回复]
個人認為為防止幽靈帳號擾亂投票結果，應以相關公告上Bulletin當刻作準。
「聯署提出前90天內至少有1次編輯（不包括任何使用者頁面及使用者對話頁）；--唔好阻住我愛國（留言） 2024年6月18日 (二) 14:20 (UTC)[回复]
可以请您详细说明吗（我还听不太懂）--WiiUf ——青龍出世，傲視蒼穹 2024年6月18日 (二) 14:26 (UTC)[回复]
書面語：本人認為條文應為防止幽靈帳號擾亂投票結果，應以相關公告刊登Bulletin當刻作準。
而非以討論階段作準，因為如非活躍編輯者在看到公告後即輕微修改條目的一隻字，即可繞過限制。而且如果以刊登Bulletin當刻作準，因為編輯者不會知道何時發起這些討論，如果不持續編輯，很難繞過這個限制。--唔好阻住我愛國（留言） 2024年6月18日 (二) 14:48 (UTC)[回复]
支持。我之前也在考虑这个问题，但是我把“解任投票联署或上任投票开始之前”就是理解成“刊登当刻”了……--自由雨日（留言） 2024年6月18日 (二) 14:52 (UTC)[回复]
其實還有個更簡單會但有點麻煩的方法可以強而有力的防止您說到的情況，那就是每次RFA或RFDA都重新討論一遍人事任免投票條件，壞處是如果社群沒討論好可能會延遲到選舉的進行，還有這種方法會導致每次人事任免投票條件都不同，社群有一部分人可能不會同意。
這只是我想到的方法您們參考看看即可。--~~Sid~~ 2024年6月18日 (二) 14:58 (UTC)[回复]
我認為限制註冊日期是有用的門檻。不過此條件設計時，本來沒有考慮到會有安全投票這種延遲許久的機制，二來條件分為兩種是有其意義，後者乃保障資深使用者，不用總是在投票前刷編輯數。我覺得改為限定「提名討論發起」之時，即可有效阻止看到通知纔開始「刷編輯」者。不需要修改其餘任何門檻。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 15:58 (UTC)[回复]
可購順便定義一下編輯必須在本站進行的。免得出現一些好笑的情況。--1233 （T / C） 2024年6月19日 (三) 08:25 (UTC)[回复]
无此必要。下文已经注明。—-WiiUf ——青龍出世，傲視蒼穹 2024年6月19日 (三) 10:45 (UTC)[回复]

提案3

符合基础条件，并符合以下兩項之至少一項次要條件者（不含机器人及附属帐号）有權投票：

基础条件

用户在討論發起之時註冊滿120天，且前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）。

次要条件

1. 解任投票聯署提出或上任投票開始120天前，編輯至少500次；

2. 用户参与投票时，註冊滿120天，且編輯至少3000次或編輯條目至少1500次。

以上所稱「編輯」，均指在中文維基百科的編輯，且不含明顯的破壞和測試。

@Eric Liu,唔好阻住我愛國, 自由雨日,Sanmosa, Asid, 1233 根据社群意见，我已再次修改此草案，请大家审阅。

——WiiUf ——青龍出世，傲視蒼穹 2024年6月19日 (三) 10:45 (UTC)[回复]

可以！--唔好阻住我愛國（留言） 2024年6月19日 (三) 13:15 (UTC)[回复]
還是沒改到重點啊。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月19日 (三) 14:13 (UTC)[回复]
(？)疑問：请问是要把第一句改成限定「提名討論發起」之時吗？--WiiUf ——青龍出世，傲視蒼穹 2024年6月19日 (三) 23:21 (UTC)[回复]
@WiiUf：閣下之意，是否打算限制「一百二十日內編輯超過三千（條目一千五百）次」者之人事任免資格？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:07 (UTC)[回复]
是的。畢竟很少有人能夠在不通過自動化程式的情況下於120日內編輯（條目）滿3000（1500）次。就算有極端情況，用戶在120日內也難以全面了解百科的相關方針。--WiiUf ——青龍出世，傲視蒼穹 2024年6月23日 (日) 10:40 (UTC)[回复]
我的意思是，條件一、二有點重複。措辭有待調整。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 00:25 (UTC)[回复]

提案4（準備公示）

凡管理人員申請提名討論發起或解任投票開啟聯署之時，註冊滿120天，且符合以下兩項之至少一項條件者，均有權投票：

  1. 在申請提名討論發起或解任投票開啟聯署120天前，已有至少500次编辑，並在其90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）；
  2. 累計編輯次數至少3000次或累计編輯條目次数至少1500次。

以上所稱「編輯」，均指在中文維基百科的編輯，且不含明顯的破壞和測試。

@唔好阻住我愛國，YF，San，Asid，自由雨日，1233，我已按照Eric的意見修改了草案，現在 公示7天，若無有效反對意見，草案將於2024年7月1日 06:00（UTC）通過。 —WiiUf ——青龍出世，傲視蒼穹 2024年6月24日 (一) 06:01 (UTC)[回复]

其实我一直感觉“（某个时间点，）编辑至少XX次”有点语病，编辑是个动词，只能用于“（某个时间段内，）编辑XX次”，尤其是“120天前，编辑至少500次”就可能让人误解为“从120天前到投票这一时间段内编辑500次”（原先的方针有“90天内至少1次”的表述还可能可以防止误解，但目前这样误解的可能性就比较大了）。我觉得应该表述为“累计编辑次数/累计编辑量至少达到XXX次”？--自由雨日（留言） 2024年6月24日 (一) 06:36 (UTC)[回复]
已完成。--WiiUf ——青龍出世，傲視蒼穹 2024年6月24日 (一) 06:42 (UTC)[回复]
我又做了点用词上的小修改（Special:Diff/83150857）。--自由雨日（留言） 2024年6月24日 (一) 06:48 (UTC)[回复]
另外这一“公示”是不是太早了？我觉得好像并没有完全达成共识吧？--自由雨日（留言） 2024年6月24日 (一) 06:39 (UTC)[回复]
已經撤下公示，按規定需要再等待一會。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 09:14 (UTC)[回复]
調整方案，整合基礎條件及次要條件。本人認為編輯次數足夠者，既已滿足註冊資歷要求，則不需要再滿足期間編輯次數條件。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 09:14 (UTC)[回复]

稍微修正，以免产生歧义。—WiiUf ——青龍出世，傲視蒼穹 2024年6月25日 (二) 04:17 (UTC)[回复]

近幾天沒有任何異議，現在 公示7天，2024年7月5日 05:00(UTC)通過。—WiiUf ——青龍出世，傲視蒼穹 2024年6月28日 (五) 04:51 (UTC)[回复]

这意味要修改SQL，重新生成投票人名单……--桐生ここ★[讨论] 2024年6月28日 (五) 09:21 (UTC)[回复]
幽靈帳號問題？不見了相關條文？--唔好阻住我愛國（留言） 2024年6月29日 (六) 14:31 (UTC)[回复]
(？)疑問-如果以「註冊滿120天」為前提，那麼第一款(120天、500次)、第二款（編輯條目1500次）就沒有區別意義，是否形同廢掉了原來的第二款投票資格？有沒有可能120天內編輯條目達1500次，每天十幾、二十筆編輯，不是沒有可能。Wetrace歡迎參與WP人權專題 2024年6月30日 (日) 03:10 (UTC)[回复]
一、「註冊滿一百二十日」與「申請（投票）前一百二十日」並不相同；二、若有遊戲規則情況，大可特別論處。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月30日 (日) 04:22 (UTC)[回复]

完成。—-WiiUf ——青龍出世，傲視蒼穹 2024年7月5日 (五) 05:04 (UTC)[回复]

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

電視劇演員名單序列

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

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

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

正式提案

現行條文

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

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

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

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

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

可能要重點說明相關演藝人員的名氣是不影響演員序列。舉例以「香港頂流」炎氏作例，倘若他在節目只有一句話，不應因為名氣而把他置頂。--唔好阻住我愛國（留言） 2024年6月28日 (五) 16:36 (UTC)[回复]
(－)反对增列的內文基本是根據其他帳號發言，加入了原發言者未提及的文字
  • 句子應該精簡後改成若對單一作品的官方名單有合理質疑，可發起討論。討論應參考更多WP:可靠來源。若達成共識，可不受前列條文限制。這個文字避免了對原發言的過度解釋，文字也概要的提及WP:共識精神。已經符合WP:可靠來源的項目，不應該再有篩選/排除的狀況(這是針對更多官方以外文字)，重要的是WP:可供查證精神(WP:ABOUTSELF第5項，WP:斷言、WP:REFNOTTRUE)
  • (～)補充這個議題大致上屬於WP:ABOUTSELF第4項的討論範疇
--Rastinition（留言） 2024年6月28日 (五) 23:55 (UTC)[回复]
同Rastinition。某些“官方”来源可能对排名作出详细解释，不应排除。--YFdyh000（留言） 2024年6月29日 (六) 02:30 (UTC)[回复]
@Rastinition@YFdyh000，但我仍希望在「討論應參考更多WP:可靠來源」之後，具體強調要注重該些來源的「演員序列，及對個別角色的戲份、演出性質之描述」，亦同意HK5201314君的意見，即強調「避免演員序列被演員的名氣所影響」。兩位覺得如何？--Factrecordor（留言） 2024年6月29日 (六) 14:42 (UTC)[回复]
避免名气影响，我觉得是避免沦为宣传工具，但这可能不是中立的观点、非原创研究所推荐。因为以其他特定标准来呈现和调整，可能不满足这两项，也较难得出公认的一致的合理标准，也许还不如给原列表加脚注。--YFdyh000（留言） 2024年6月29日 (六) 16:58 (UTC)[回复]
那麼@HK5201314君有沒有進一步回應？--Factrecordor（留言） 2024年7月1日 (一) 10:51 (UTC)[回复]
不知道為什麼，我想用TVB愛回家作例，話說當年楊明剛剛被TVB解凍，他獲解凍後出埸的第一集，對白有超過10句，但TVB的操作是把他放在演員序列中最後一個。
什至，中國大陸常常封殺「不道德演員」，做法是打碼／打格仔，並刪除該演員資料。
如按照現行做法，是完全不尊重「不道德演員」及「剛解凍演員」，並違反中立原則，因為現行做法完全偏向製片商。--唔好阻住我愛國（留言） 2024年7月1日 (一) 11:30 (UTC)[回复]
所以建議新增如有任何爭議，可按可靠來源介紹量／文章多寡決定演員序列。--唔好阻住我愛國（留言） 2024年7月1日 (一) 11:32 (UTC)[回复]
按文章量不可行，计算结果是原创总结（哪些来源算，如何去重，数量平手，情况改变），也同样容易操纵（争议人物排第一）。--YFdyh000（留言） 2024年7月1日 (一) 15:19 (UTC)[回复]
如果是「角色介紹量」呢？我不信只有一句對白的角色就有一整篇文章介紹該角色特性。--唔好阻住我愛國（留言） 2024年7月2日 (二) 12:14 (UTC)[回复]
润笔费给足，吹嘘解读不用愁。如果是重要角色或明星，但播出版本全剪掉了，又怎么办。别自定标准了，见下。--YFdyh000（留言） 2024年7月6日 (六) 13:59 (UTC)[回复]
我相信閣下有能力判斷何謂「可靠來源」。--唔好阻住我愛國（留言） 2024年7月6日 (六) 15:50 (UTC)[回复]
写成看不出来不难，包括以量取胜。--YFdyh000（留言） 2024年7月7日 (日) 02:57 (UTC)[回复]
當初會建立指引，就是為了防止每個用戶依據自己所認定的來進行排序，進而引發編輯戰。同時，還必須考慮到歐美劇常有主演退出的情況。另外，有些戲之所以會將看似客串的演員列為主演，可能是認定其角色在某個階段吃重，比如《黑道律師文森佐》的劉宰明，前三集是主演，但角色死亡後，第四集變成客串，可是不會因此推翻他在前三集是主演的事實。又，報獎策略出現的主配問題，例如《一把青》的排序是天心、楊謹華，但獎項競賽卻是楊謹華報名女主角、天心報名女配角，列入這些情況太過繁雜。
所以最好的方法，就是撇開個人模糊的「實情」認定，不論是劇情編排轉變，還是宣傳手段與否，盡量依據官方或可靠來源為準，主演寫誰就是誰、客串是誰就是誰，這樣可以避免自行量化、計算，而導致涉及原創研究的問題。其餘的，可以用可靠來源來補足，例如陳豪雖然被列為主演，但其偏向客串性質云云、演員被刪除的原因等等。--Sa Young Sun（留言） 2024年7月5日 (五) 19:41 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至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)[回复]

其他

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

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

提议收紧创建新页面的权限

我前段时间关注到英文维基的用户权限级别规定，发现创建页面（讨论页除外）必须注册用户才可以，特别是创建条目还需成为自动确认用户才可以（详见2018年讨论）。我们知道，中文维基百科绝大多数注册达7天并编辑达50次的用户均会成为自动确认用户，虽然说要求比英维严，但这做法还是远远不够。匿名用户（或者说IP用户）、注册用户目前在中维都可以创建页面（被白纸保护的页面除外），但某些匿名用户或者新注册用户因为不了解方针，把维基百科当成是宣传场所，创建条目用于宣传，违背了初衷与目标。而且随着条目的增加（现有条目140多万），社群不断壮大，风险也越来越大。

为了满足今后发展的需要，堵住进一步的风险，我提议修订用户权限级别的规定，收紧创建新页面的权限。参考英文维基的标准：创建页面（讨论页除外）最低权限是注册用户，创建条目最低权限是自动确认用户。目的旨在于让新用户先了解方针，先开始在既有页面编辑。不知各位有何看法。--Shwangtianyuan 不忘初心 牢记使命 2024年6月21日 (五) 16:37 (UTC)[回复]

完全(＋)支持，处理新用户宣传性、甚至破坏性页面创建明显地消耗了很多用户和管理员不少精力。上个月我就在某新用户沟通无效反复创建被快速删除的页面以推广边缘语文学说和网络新词/方言，且完全无视方针指引、严重扰乱讨论秩序、游戏维基规则上耗费了大量时间（[12]），限制自确用户创建条目即可限制此类问题的发生频率。此外，部分长期破坏者、傀儡长期创建破坏性、甚至侮辱性页面显然也给巡查员、管理员工作带来不小的额外负担。--自由雨日（留言） 2024年6月21日 (五) 17:17 (UTC)[回复]
Shwangtianyuan的主張也會擋掉一部分想建立條目的ip用戶和新用戶，所以我比較支持願意建立合規品質條目的ip用戶，至少我看到很多重要條目的創立者是ip用戶或編輯數量很少的新用戶，所以從這一點來說，並不是很想幫那些和新用戶爭執、想著降低新頁面負擔之類的用戶。--日期20220626（留言） 2024年6月22日 (六) 17:27 (UTC)[回复]
日期君误会了，如果您有所了解，我是对新用户持很强的善意推定并努力引导的，在几天前就还因为善意推定、游说管理员将一个我觉得可能没有恶意的不限期封禁新用户解封，结果放过了一个真的LTA[13]……我很少和新用户“争执”，上一段举的例子，恰恰是因为我试图为他提供一些方针指引引导他作出建设性编辑（其他编者也尝试与其沟通，只是没有像我一样继续下去，见[14][15]），才“引起了争执”，因为我坚持宽容新手不能以牺牲条目质量和基本方针指引为代价（另外当时在存废讨论页@您纯粹是由于查到您是该条目创建者，并非“请您帮忙”）。也正是我发现很多急于创建条目的新手并像我想象的那样抱有善意，多次懊悔自己的信任与付出，才倾向从严、收紧权限的。不过，@桐生ここ和您的意见确实很有启发，让我觉得确实没必要限制新用户在草稿空间的发挥，故而我转为支持只将新条目限定为自确用户，其他继续放开，允许IP创建草稿。--自由雨日（留言） 2024年6月22日 (六) 18:30 (UTC)[回复]
提议“创建页面（讨论页除外）”改成“创建页面（讨论页、草稿页及自己的用户页除外）”。--Leiem（留言·签名·维基调查） 2024年6月21日 (五) 17:47 (UTC)[回复]
“自己的用户页”完全没有必要，因为和“注册用户”自相矛盾，非注册用户怎么能创建自己的用户页呢？“草稿页”，我倾向同样从严，只有注册用户才能创建，以防止IP用于破坏、人身攻击或宣传。（修改意见，除创建条目仍支持限定为自确用户外，其他转为支持下段桐生ここ的意见，支持“放开”。）--自由雨日（留言） 2024年6月21日 (五) 18:00 (UTC)[回复]
我反而认为只有条目应该注册用户才能创建，其他的继续放开，毕竟你维只要允许匿名编辑页面，就可以用来破坏、人身攻击和宣传。--桐生ここ★[讨论] 2024年6月21日 (五) 20:54 (UTC)[回复]
随着条目的增加，社群不断壮大，风险也越来越大。我不是很理解这三者有什么逻辑关系；另外，您可前往https:/stats.wikimedia.org查看统计数据，会发现中文维基百科的活跃用户（当月有5次以上编辑的用户）数量在2021年8月达到最高点3,598后一直呈下降趋势，至今已下跌24%；编者（当月有1次以上编辑的用户）数量则下跌了37%。社群没有壮大，反而是正在缩小。可能有人会觉得这是OA2021的缘故，但这一下跌并非2021年那几个月造就的，不如说在OA2021之后用户数量还反弹了不少，在后续的两年间才陆陆续续地跌到了越来越低的水平。Irralpaca（留言） 2024年6月21日 (五) 20:55 (UTC)[回复]
题外，以10年为范围的，统计站的5次活跃的平均值就在2500~3000这个范围，甚至相对10年还略高。说不上涨了，又好像基本没变。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 00:40 (UTC)[回复]
同Irralpaca，社群並非不断壮大，Shwangtianyuan的前提就不成立。Shwangtianyuan如果能讓中維的規模和英維一樣龐大，或者解決「中維怎麼一堆條目都缺失」的問題，他的提議我可以支持。一個條目數量只有英維條目數量六分之一且編輯用戶規模還在縮小的中維，沒必要去照搬英維。--日期20220626（留言） 2024年6月22日 (六) 17:23 (UTC)[回复]
(＊)提醒：英文维基百科的自动确认用户是4天+10编辑。另外，过滤器这样的自动化反破坏工具应用还是不充分。——暁月凛奈 (留言) 2024年6月21日 (五) 23:03 (UTC)[回复]
如果流程成熟，可以要求必须先是草稿。目前而言，不觉得需要照搬英文维基，各方面数量都不足。--YFdyh000（留言） 2024年6月22日 (六) 06:27 (UTC)[回复]
Wolfch下面提到草稿審核時間過長，人手不足，所以草稿制度不應該強制推廣。--日期20220626（留言） 2024年6月22日 (六) 17:28 (UTC)[回复]
(＊)提醒：有關IP用戶創建條目的投票（Wikipedia:投票/開放IP創建條目權限），我有找到2010年提出的投票（不確定後來是否還有類似的投票），當時的結果是「票數處於50%至66%中，故執行三個月試運行」。
若維持IP用戶可創建條目（和現在一樣），這些條目需讓巡查員巡查，巡查員工作量會比較大（這是目前現況，因此有可能目前巡查員的工作量就比較大）。若改為IP用戶可創建草稿，那會加重WikiProject:建立條目審核員的工作量。
請大家在決定時，考量Special:最新页面中新頁面的巡查更改情形，以及 中草稿的數量以及處理速度（依Draft:周瑛下方模版所示，依目前審核員的人力，草稿審核可能需要等待7週），再作決定。--Wolfch (留言) 2024年6月22日 (六) 06:50 (UTC)[回复]
我倾向于支持，但还是希望提案人提供一些数据来论证措施有用（比如英维实行规则的前后对比？），这样可以更有说服力。--碟之舞📀💿 2024年6月22日 (六) 07:29 (UTC)[回复]
参考英维的讨论，就是说收紧权限之后，确实降低了新页面巡查的负担，所以它的确有一定好处。--Shwangtianyuan 不忘初心 牢记使命 2024年6月22日 (六) 14:49 (UTC)[回复]
中維新用戶或ip創建的條目有多少？如果不達標的數量並不多，那並沒有增加多少新頁面巡查負擔。而且如果用戶沒有成為巡查員、免巡查用戶，它建立的條目也要巡查，如果只是從降低新页面巡查負擔考慮，是不是多讓幾個人獲得相關權限，負擔也能減輕？--日期20220626（留言） 2024年6月22日 (六) 17:34 (UTC)[回复]
此更改會影響IP用戶的編輯，我覺得是較大的更動，建議在template:Bulletin中列出，讓多一點人參加討論。--Wolfch (留言) 2024年6月22日 (六) 15:08 (UTC)[回复]
我之前的想法是：技术上暂不限制创建条目，但可以页面上将建立条目精灵作为首选项（效果图）。我也赞成有足够的人看草稿，才能限制创建条目。题外话：现在巡查员可以直接参与创建条目专题草稿审核，无需申请，希望更多人参与。及时雨 留言 2024年6月23日 (日) 04:34 (UTC)[回复]
這個提議不錯。--日期20220626（留言） 2024年6月23日 (日) 04:36 (UTC)[回复]
(！)意見：巡查员通常用模板来标记条目问题，而AFC审核需要更准确地告知撰写者（通常是新手）具体的问题段落和应该如何改善。不过不反对先试行允许巡查员审核AFC。Python6345（留言） 2024年6月23日 (日) 06:06 (UTC)[回复]
同。目前尚未有必要直接禁止新用戶建立條目。這個方案引導新用戶經AFC瞭解基本內容規範外，將善意建立條目的用戶引流後，也能更集中針對新用戶直接建立的條目反破壞（因破壞者甚少會建立草稿）。--路西法人 2024年6月24日 (一) 02:10 (UTC)[回复]
同意。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 05:50 (UTC)[回复]
作為負責教育專案/藝術專案的編者，本人認為禁止新用戶建立條目有可能會造成不少問題。如果需要限制的話，請至少給予確認用戶(confirmed)建立頁面的權利。謝謝。--1233 （T / C） 2024年6月24日 (一) 03:58 (UTC)[回复]
确认用户和自动确认用户除投票权以外权限都一样，上面的讨论最严就是到限制（自动）确认用户可以创建条目为止，没有提出过更严的限制。--自由雨日（留言） 2024年6月24日 (一) 04:06 (UTC)[回复]
(＋)支持將建立條目頁面的權限放到自動確認（或確認）使用者以上，若未通過，則建議將建立條目精靈的直接建立條目入口移除（僅留草稿空間與使用者子頁面草稿的建立方式）並突顯建立條目精靈，同時鼓勵巡查員加入草稿審核團隊。--冥王歐西里斯（留言） 2024年6月27日 (四) 01:42 (UTC)ㄜ[回复]
(＋)支持冥王君上面的全部意見。有位友人曾經和我說，就算讓一個教授來編寫維基，他最初都必定舉步為艱。中維看似自由（因為有這種基本方針），實際上仿如危機四伏的深海，有很多東西等待吞噬嚮往自由而來的人。如果中維活躍人數越來越少，趕客的是一些讓人覺得被排擠的不良風氣、研究維基「法律學」的嚴謹性好像比推動內容貢獻更重要的風氣，等等。相較之下，保留創建條目的自由度對於吸引有質素的新編者，幫助不大，只會更易引來那些質素低下的人和破壞者。我認為一個有質素的新編者，對於這種限制是會理解的，說不定會傾向認同，因為這反而能顯示自己比那些隨意胡編、濫建的人要高一等，而且級別權限之分在其他平台或現實世界都是經常存在的，不是什麼特別的事。增加活躍人數，則需切實從反思風氣入手。--Factrecordor（留言） 2024年7月1日 (一) 09:52 (UTC)[回复]
(＋)支持将创建主命名空间页面权限调整为自动确认用户，但允许非自动确认用户可以创建草稿，用户页等.--mije meli carrot_233 -- 讨论 2024年7月3日 (三) 05:37 (UTC)[回复]

根据实际需要修订“游戏维基规则”指引

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:游戏维基规则。

我在这里再提一个议案。游戏维基规则的部分条文本人认为需要进一步增修，在此参考英维对应指引，建议在“游戏方针与指引使用”——“方针斗法”一节加入示例，内容为： 例如：通过撤销您的破坏性编辑，告知其他用户违反回退不过三原则。（回退明显的破坏性编辑是回退不过三原则的一个例外情况。）

另外在“游戏共识形成程序”一节增加两条内容，建议的内容为（在形成共识前可能还需进一步修改）：

  1. 使用煤气灯效应策略，例如改写历史、否认现实、误导、毫无根据的矛盾、将自己的弱点投射到他人身上、訴諸斷言或离题闲聊——通过播下怀疑和不和来破坏讨论。
    例如：否认您所发布的内容、暗示某人同意他们并未同意的事情、假装您的问题尚未得到解答、歪曲方针的实际内容或含义、对主张的明显含义含糊其辞、或在您的立场被共识推翻或拒绝时拒绝让步。
  2. 以牙还牙，要求编者根据您在其他地方为他们所做的努力采取行动（例如在讨论中改变他们的立场）；或暗示除非他们采取您希望的行动，否则您将不会为他们做出努力。
    例如：一位编者根据第一位编者先前给予的支持或代表他采取的其他行动，要求另一位编者改变其在申请成为管理人员的投票。
    例如：一位编者要求管理员警告另一位编者涉嫌推动不中立的观点，并暗示如果管理员不采取行动，第一位编者对条目的優良條目評選或典范条目评选流程可能会陷入危险。
    例如：一位编者要求另一位编者支持他们的RfC，以换取他们在另一场讨论中的支持。

同时我建议加入“游戏用户权限”一节，加入在“游戏对扰乱行为的制裁”的一节的后面，内容为：

  1. 为了提升用户权限级别进行非建设性的编辑。
    例如：一位新编者进行了50次空編輯以获得自动确认用户权限，然后对受到半保护的条目进行了有争议的更改，将宣传草稿移至条目空间，或者以其他方式进行破坏性编辑或破坏条目。
    例如：一位编者在沙盒中做出许多非建设性的编辑以获得延伸確認用户权限，然后对受到延伸確認保護的条目做出有争议的更改。

写在最后：以上我提出的三份建议，是我继封禁方针提出进一步修订后，就“如何让维基百科变得更好”迈出的又一大步。三份建议已经按照我的计划全部提出，后续我将就第二十二次動員令做准备。欢迎大家就我的建议提出意见。

以上。--Shwangtianyuan 不忘初心 牢记使命 2024年6月21日 (五) 16:38 (UTC)[回复]

为什么“撤销自己的破坏性编辑”可导致“其他用户违反3RR”？能否举一个实例？--自由雨日（留言） 2024年6月21日 (五) 17:35 (UTC)[回复]
可能意思是，破坏者被回退了三次，然后破坏者给回退员发了违反3RR的模板。--桐生ここ★[讨论] 2024年6月21日 (五) 20:58 (UTC)[回复]
哦哦！我找到原文了，这个“by”不应翻译为“通过”，而是“由于”，而且“by reverting…3-revert rule”应该是作为整个“Telling another user that…”的从句才对。不过这样太啰嗦，我尝试改为更符合中文习惯的表述：“在破坏性编辑被某用户多次回退的情况下，声称该用户违反了回退不过三原则。”（原先的表述起头一句“通过撤销您的……”太容易让人理解成“游戏维基者”本人撤销本人的破坏性编辑了……）--自由雨日（留言） 2024年6月21日 (五) 21:16 (UTC)[回复]
对于“游戏共识形成程序”部分有保留。关于“为了提升用户权限级别进行非建设性的编辑”定义，章节上就有“为了得到自动确认用户权限而做50次无贡献性或破坏性编辑。”，可以在此补充。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 01:02 (UTC)[回复]
「遊戲使用者權限」可改為「不當攫取使用者權限」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:00 (UTC)[回复]
查阅多本词典，感觉“攫取”侧重于“掠夺（有限资源）”？（用户权限是“无限资源”，不需要抢夺。）不如改成“套取”“诈取”“窃取”……？--自由雨日（留言） 2024年6月23日 (日) 02:11 (UTC)[回复]
「詐取」吧，「詐」其實就是「遊戲」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 07:13 (UTC)[回复]
「詐」字本來就有「不當」的意思在內，寫成「不當詐取」要麼語義重複，要麼變相暗示存在非不當的「詐取」的情形，不妥。「不當獲取用戶權限」可能較好。Sanmosa 蚌埠 2024年6月23日 (日) 14:43 (UTC)[回复]
那直接寫成「詐取權限」即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 01:42 (UTC)[回复]
我考慮了一下，「詐取權限」要求滿足主觀性，但「不當獲取用戶權限」不要求如此。如果最終的條文是「詐取權限」，那就相當於要求必須證明該用戶主觀上有不當獲取用戶權限的意願，但「不當獲取用戶權限」僅要求確認該用戶不當獲取用戶權限的事實。Sanmosa 蚌埠 2024年6月27日 (四) 23:10 (UTC)[回复]
不当获取 标准含糊，是否容易寒蝉效应和滥发指责。但诈也容易导致滥用和过于慎重。对于禁止性条文，推定善意和推定恶意需要并存，当事人的合理解释、合适处置可能重要。中性描述，可能是提前/过早取得用户权限/入选资格，尤其是用于提报和警告？--YFdyh000（留言） 2024年6月29日 (六) 11:43 (UTC)[回复]
「不當獲取」標準含糊的話，社羣為「不當獲取」下定義就是了。Sanmosa 蚌埠 2024年6月30日 (日) 04:07 (UTC)[回复]
「警告另一位編者涉嫌推動中立的觀點」？--路西法人 2024年6月30日 (日) 00:42 (UTC)[回复]
註：此留言已被原作者（User:Sanmosa）移除。2024年6月30日 (日) 09:48 (UTC)[回复]
你再讀一次提案人寫了什麼。--路西法人 2024年6月30日 (日) 05:47 (UTC)[回复]
“以牙还牙”的说法更像是用来说明“要挟”，“以牙还牙”会搭配“以眼还眼”来表示相同方式反击？另外第二个举例，“管理员警告第二个编辑推动中立的方针”，中立的方针不应该是好的，推动不好？为什么要警告？还是应该用“推倒”？“第一个编辑对条目评选可能会陷入危险”，是第一个的评选（他的条目或者他推举的评选）陷入危险？还是第一个对评选造成危险？这句话的案例看上去不太清晰。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月30日 (日) 08:02 (UTC)[回复]
就是漏了個“不”字的問題而已，補上就是了。Sanmosa 蚌埠 2024年6月30日 (日) 09:48 (UTC)[回复]

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

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

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

不反對合併。不過能否詢問下您會怎麽設計合併之後页面评级的章文結構，如果可以的話能否參考下Temp君的意見。--人间百态,独尊变态(讨论) 2024年6月23日 (日) 08:37 (UTC)[回复]
@Temp3600：不知有何意見？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 04:20 (UTC)[回复]
合併比較好。不過也要注意通用評級指引指引本身還有其他需要修改的地方，所以上一次討論時就沒有提出合併的單獨請求。--Temp3600（留言） 2024年7月2日 (二) 14:47 (UTC)[回复]
應該可以合併--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 14:52 (UTC)[回复]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我相信管理員在調查破壞者是否玩弄社群時會參考破壞者的貢獻記錄，看看是否達到「儘快」要求。--唔好阻住我愛國（留言） 2024年7月3日 (三) 15:14 (UTC)[回复]
我們在編輯某些條目，察覺一些方針需要制訂或修改，卻不一定常涉足所有受該方針影響的範疇，先反思影響範圍，再看看哪些用戶經常活躍於箇中話題，邀請討論，所有潛在疑問可能在兩三星期內就能被大家想出來了，可以集中解決。若不這樣做，往往有個人偶爾路過，又放下一個疑問，自然無休無止。就算你曾經順利通過提案，也只是你的一時幸運，而你的幸運不一定是維基之福。--Factrecordor（留言） 2024年6月26日 (三) 13:01 (UTC)[回复]
「偶爾路過，又放下一個疑問」，這個絕對支持，唯該路人是不是應該負起責任，主動跟進自己問過的疑問，如有需要，應儘他能力以最快時間進行追問，避免社群其他成員無限的等待，這對提案者絕對是一個折磨。--唔好阻住我愛國（留言） 2024年6月26日 (三) 13:13 (UTC)[回复]

MOS:-的来源请求

近日发现template:convert中表示数值范围的短横被改了，根据Module talk:Convert/text的讨论推测，修改的来源是MOS:-。这边短横的使用是否有出处？表示数值范围的话应该用dash符号（–）而非破折号的一半（—），参见维基词典相关内容。--Leiem（留言·签名·维基调查） 2024年6月29日 (六) 08:43 (UTC)[回复]

这里是中文维基百科，不是英文维基词典，MOS:-是社群商议制定的格式指引，不是条目，不适用“来源请求”。若欲修改格式指引，需客栈讨论。--自由雨日（留言） 2024年6月29日 (六) 08:47 (UTC)[回复]
Wikipedia_talk:格式手册/标点符号/存档3#连接号一字线的符号选择--YFdyh000（留言） 2024年6月29日 (六) 09:32 (UTC)[回复]
就template:convert目前的显示结果来看，使用一字线在数字和表达式中过长。--Kethyga（留言） 2024年6月29日 (六) 10:40 (UTC)[回复]

目前显示的效果是这样的：{{convert|1|-|2|C|K}} → 1—2 °C（274—275 K） --Leiem（留言·签名·维基调查） 2024年7月1日 (一) 06:37 (UTC)[回复]

其實應該確定中文各地標準如何？不應由維基人自創。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 04:18 (UTC)[回复]
之前就是参考各地中文标准确定的呀（还是Liu君的意思是要进一步用地区词来实现不同地区不同显示），主要就是参考中华人民共和国教育部国家推荐标准（[16]）和中华民国《重订标点符号手册》（[17]）的。有关连接号的部分，表述数值范围都是使用一字线（只在“–”符号上有所区别，中国大陆将“–”视作可与短横线“-”混用，而台湾将“–”视作可与一字线“—”混用）。--自由雨日（留言） 2024年7月2日 (二) 05:14 (UTC)[回复]

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

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

没找到争议，请列位置。已认证账号发的内容可能作一手来源，引用价值和方式需具体评估。--YFdyh000（留言） 2024年6月30日 (日) 15:50 (UTC)[回复]
已经补上了。(事后才在讨论页说明User talk:YouTube zou zou)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年6月30日 (日) 22:06 (UTC)[回复]
未见涉及条目中来源。如果前后都无来源，请求来源或者全部移除。--YFdyh000（留言） 2024年7月1日 (一) 05:15 (UTC)[回复]
我记得日语维基百科那边是禁止使用视频中的内容作为参考来源的，中维这边不太清楚有没有类似要求。——— 红渡厨（留言・贡献） 2024年7月3日 (三) 02:23 (UTC)[回复]
我記得沒有完全禁止，有要求限制而已，官方驗證媒體帳號，自行出版物与可疑来源中的材料可以用作说明其釋出者（如某人、組織或其他實體）或該來源自身資訊的参考来源，通常在釋出者相關條目或以該來源本身為主題的條目中，而不要求是由该领域的专家发表，只要：
  1. 没有过度的自我宣扬；
  2. 不包括针对其他人、組織、實體的主張或觀點；
  3. 不包括与主题无直接关联事件的主张；
  4. 来源内容的真实性未受到合理的质疑；
  5. 不是条目主要的来源。

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

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

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

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

想法：

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

提案：

現行條文

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

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

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

提議條文

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

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

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

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

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

政治人物

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

宗教人物

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

文化人物

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

正式提案（准备公示）

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

現行條文

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

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

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

提議條文

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

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

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

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

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

‘此類資訊應由「分類:××人」或獨立列表體現’這句分句可以保留。總體上暫時不反對此提案。Sanmosa 蚌埠 2024年7月5日 (五) 12:33 (UTC)[回复]
或改成「可由（略）體現」。另「僅列點」可改為「僅單純列點」，排除混合寫法。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月5日 (五) 14:35 (UTC)[回复]
已根据建议调整新增条文。原新增条文：一般而言，行政区划条目中禁止嵌入仅列点之人物列表。--河水|滇 2024年7月5日 (五) 20:58 (UTC)[回复]
(－)反对之前是因为收录标准不明，而不允许姓氏、区划类条目加入人名列表的，之前“美国人列表”之类的也是因此而被禁止的吧--苞米(☎)💴 2024年7月5日 (五) 21:10 (UTC)[回复]
@Baomi：還請你説明一下你反對的是河水的提案本身還是我對河水的提案的建議。Sanmosa 蚌埠 2024年7月6日 (六) 11:01 (UTC)[回复]
(＋)支持，比之前的条文合理--苞米(☎)💴 2024年7月6日 (六) 12:09 (UTC)[回复]

提议限制无意义用户名

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

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

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

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

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

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

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

這樣，我會很尷尬，所以(－)反对抱歉，而且很多其他語言維基百科沒有這樣限制--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 11:01 (UTC)[回复]
没有必要+无法评估意义和混淆度。IP地址同样有区分难度。正常的处理恶意混淆用户名即可。--YFdyh000（留言） 2024年7月2日 (二) 11:21 (UTC)[回复]
認同YFdyh000說法--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 11:23 (UTC)[回复]
(＋)支持 事实证明葡萄牙语维基百科已经利用此规则阻止了扰乱用户在该站活动。--——🦝Interaccoonale（留言・贡献） 2024年7月2日 (二) 11:28 (UTC)[回复]
請問很多其他語言維基百科，為什麼不統一使用葡萄牙語維基百科规则呢???因為早期很多都是很雜亂的使用者名稱，因為不知取什麼名字，所以亂打，才造成有這些人，但並非破壞者，而且滿多人有對維基做出貢獻，不能因為破壞者取這樣名稱，而限制很多人權利，這如YFdyh000講得一樣，沒有必要+無法評估意義和混淆度--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 11:36 (UTC)[回复]
@HYHJKJYUJYTTY:
請問你改這個名字的意義是什麼，有沒有特別含義？--唔好阻住我愛國（留言） 2024年7月2日 (二) 12:11 (UTC)[回复]
當初只是為了編輯而已，所以沒有認真取名字--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 12:13 (UTC)[回复]
其實你是可以申請改名的。不過，如果我因某一事項想找人討論，我很難聯想你的出現，因為你的名字只是 「隨機字元的序列組成（隨便改名）」，如果我要ping你，也要記起HYHJKJYTTY的字元組合先，只要忘記其中一個字元，也不能順利地找你。--唔好阻住我愛國（留言） 2024年7月2日 (二) 12:59 (UTC)[回复]
有那么困难吗，通常可以记前几个字母来找。--YFdyh000（留言） 2024年7月2日 (二) 16:02 (UTC)[回复]
目前從事反純破壞工作或翻譯--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 12:14 (UTC)[回复]
您自己的一些编辑已经在破坏行为的边缘了；并且您既不熟悉英语、也不熟悉汉语（WP:管理员布告板/其他不当行为#HYHJKJYUJYTTY），您的翻译内容已经引起了多位用户的不满。。。--自由雨日（留言） 2024年7月2日 (二) 13:20 (UTC)[回复]
我最初翻譯跟他最新版本翻譯，根本差不多，先不聊，但我警告後，根本沒後續堅持，還有其實跟這個處理方針無關--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:28 (UTC)[回复]
抱歉我熟悉漢語，只有不熟悉英語而已--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:30 (UTC)[回复]
是不是不朔及既往就可以？讓HYHJKJYUJYTTY大這樣的ＩＤ變成絕版造型也是好方法。 --窝法乙烷 儿法梦碎 2024年7月2日 (二) 13:13 (UTC)[回复]
不朔及既往，算是不錯作法，但限制沒有意義--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:23 (UTC)[回复]
很多用户名对用户本身有其意义，不过是对外人而言无法理解罢了。比如，请问诸位在点进KaurJmeb君的用户页之前会觉得这个用户名有意义吗？再者，纵使我们假设扰乱者才会乱取用户名，我对提案的政策多大程度上能够限制扰乱者表示怀疑，因为要取一个有意义的用户名也不是多难的事。去维基词典点击随机页面就必然可以得到一个“有意义”的词汇，这不比乱敲几下键盘难多少。Irralpaca（留言） 2024年7月2日 (二) 13:36 (UTC)[回复]
認同，無意義使用者名稱跟防止破壞者，關聯程度不高，因為確實破壞者可以取有意義名稱--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:42 (UTC)[回复]
@YFdyh000、Irralpaca：感谢留言。目前我只是提出了大体方向，具体方针怎么写还没有想好。考虑到汉字的性质肯定不能照抄ptwiki的方针。
至于您给的例子，我认为是细节上如何界定“无意义”或者“难以辨识”的问题。我的想法是那些使用常识直观判断不存在任何有意义的可能性的用户名（比如KaurJmeb这个名字的熵值其实不是很高，而且用户给出了解释）。第二个问题的话，本提案只是想进一步规范用户名，方针本身就是一点一点优化的，反破坏的效果只要有就行，并且长远来看禁止这样的名字对社群没坏处。--碟之舞📀💿 2024年7月2日 (二) 13:58 (UTC)[回复]
想要建議這方針必須是不影響共識之前的使用者權利，還有必須釐清無意義使用者名稱跟防止純破壞者，關聯程度，但目前為止看不出來--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 14:03 (UTC)[回复]
您可以使用现代标准汉语发言吗？--——🦝Interaccoonale（留言・贡献） 2024年7月2日 (二) 14:29 (UTC)[回复]
平行時空的人你好--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 14:36 (UTC)[回复]
閣下您那整句到底是什麼意思？您前半是在說建議這個方針不要溯及既往（還是在說不要損害既得者利益所以反對提議？），然後後半是在說還需要進一步釐清「無意義的名稱」跟「破壞者」的關係嗎？閣下您的用詞感覺似乎漏掉好幾個字詞且順序混亂，讀得頗吃力。--WiTo🐤💬 2024年7月2日 (二) 14:59 (UTC)[回复]
我什麼時候建議不要溯及既往，是別人建議，我認為好，但限制沒有意義，文字要看懂，根本沒吃力，真的不要怪別人--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:08 (UTC)[回复]
我用詞並沒有漏掉好幾個字詞，那是你看很多人討論，造成混亂--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:19 (UTC)[回复]
提醒你碟之舞目前還沒有正式方針草案--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:21 (UTC)[回复]
无法判断。可发音或者用单词组成的用户名，可能反而是用软件（字典）生成。不需要朗读，未见规范用户名的需求。明显的弊大于利，无论短期长期。--YFdyh000（留言） 2024年7月2日 (二) 16:08 (UTC)[回复]
不認為有必要限制。因為主觀標準不同。YFdyh000、Irralpaca、T45614631這種難道能直接看出有什麼意義？甚至Ericliu1912，也是因為社群知道本人使用Eric Liu的稱呼，纔顯得有意義。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 15:23 (UTC)[回复]
不正規統計，沒七成，至少超過五成都是沒有直接意義，認同Eric Liu 主觀標準不同，所以很難怎麼處置，確實不必要--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:30 (UTC)[回复]
您到底在说些什么？--——🦝Interaccoonale（留言・贡献） 2024年7月2日 (二) 15:32 (UTC)[回复]
所以你要表達什麼--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:36 (UTC)[回复]
是我在问你，你在表达什么。--——🦝Interaccoonale（留言・贡献） 2024年7月2日 (二) 15:38 (UTC)[回复]
我表達反對意見，認同其他人類似意見，如果你是為了反駁而反駁，大可不必--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:42 (UTC)[回复]
老實說，我的還真的沒有意義（是當時鍵盤隨便碼的數字），之前曾有動念想改，但一直遲遲沒去申請。不過我個人對這議案期望能帶來的效果感到懷疑（以及對標準拿捏有疑慮），但不試不知效果，故現在保持中立。--WiTo🐤💬 2024年7月2日 (二) 15:49 (UTC)[回复]
阁下还是申请更名吧，有时想找阁下老费劲了：D（我只能记前3个数字）--微肿头龙（留言） 2024年7月3日 (三) 15:00 (UTC)[回复]
支持理念，但判定過於主觀，難以合理執行。
  • 「有意義」與否尚不能保證用戶名「便於辨識」。若有用戶使用倉頡碼或注音碼來建立帳號，用戶名看起來也像是亂碼，確實有實際意義卻仍然不便於辨識（並非所有人都懂得倉頡或注音）。
  • 「有意義」與否應視用戶是否能解釋自己的用戶名的意思。如果能大致給個有道理的解釋（例如過往網名），那麼就顯然不是「沒有意義」；如果解釋不了的，那顯然就只是個亂碼。
--路西法人 2024年7月3日 (三) 00:28 (UTC)[回复]
另，同其他用戶的部分意見，不同意將「無意義用戶名」直接歸於「防止破壞」。任何此類規範都是應以「阻礙協作」為推進前提，直接標籤為破壞未免過甚。--路西法人 2024年7月3日 (三) 01:47 (UTC)[回复]
反对，本身用户名就是主观性或者对于使用者来说就有意义的，站在旁人的角度自然就是没意义的，这样实际上会令本社群为了“审核”用户名的“意义”而官僚化。破坏和用户名是否对于用户本人或者旁人并无直接关联。不应该将用户名的“有意义”性作为破坏或者提前阻止的推断，对应用户做出破坏的编辑的时候再说。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月3日 (三) 01:00 (UTC)[回复]
(－)反对，在无恶意的情况下，选用什么样的用户名是用户的自由。--Leiem（留言·签名·维基调查） 2024年7月3日 (三) 02:49 (UTC)[回复]
(－)反对，无意义，完全是主观认定他人用户名不合适，有违WP:假定善意。——— 红渡厨（留言・贡献） 2024年7月3日 (三) 03:42 (UTC)[回复]
(－)反对，討論使用者名稱有沒有意義沒有意義--銀河市長—☎️— 2024年7月3日 (三) 05:45 (UTC)[回复]
(－)反对，“有意义”的认定标准非常主观。用户名随时间的增加会越来越多，“有意义”的选项会越来越少。--微肿头龙（留言） 2024年7月3日 (三) 14:56 (UTC)[回复]
有一說一，「意義」本就是人為賦予的，所以所有用戶名既可以全都是有意義的，也可以全都是沒意義的。Sanmosa 蚌埠 2024年7月3日 (三) 23:56 (UTC)[回复]
以「是否有意义」的角度来看会遭到反对。我个人认为这里更多是「是否对编者互相沟通造成阻碍」。上方已有举出一个例子：阁下还是申请更名吧，有时想找阁下老费劲了：D（我只能记前3个数字）像乱码、纯数字用户名，不好记，容易妨碍沟通。--0xDeadbeef (留言) 2024年7月4日 (四) 06:01 (UTC)[回复]
沟通障碍同样难评。用户名与签名无关，算制造障碍吗。您的用户名我也记不住。有特点的用户名或签名出现仿冒，是最有可能的，但很多仍难鉴定是否恶意。假设取名“日期2024年7月4日”。又如站内的范、范博，我会不自觉的记混，但也许只有我。--YFdyh000（留言） 2024年7月4日 (四) 08:39 (UTC)[回复]
實際上大家的使用者名稱多半沒什麼「客觀」意義。這同時也是網路文化特性，太有意義反而增加辨認風險。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月5日 (五) 14:33 (UTC)[回复]
(！)意見：直接限制用户名或许太过严格，那么是否可以在“创建账户”页面“用户名”输入框下加一行类似“推荐不要采用长串无意义字符”的建议呢？不强制要求，就像“电子邮箱地址”也是推荐填写。这类提示相信是可以影响到大量有意作出善意编辑的人，让本来可能就随便输入几个字符的新用户改取有意义用户名的。--——自由雨日（留言・贡献） 2024年7月5日 (五) 00:16 (UTC)[回复]
不反對，雖説效用大不大另説。Sanmosa 蚌埠 2024年7月5日 (五) 12:34 (UTC)[回复]
不认为有意义，如果当事人自己觉得好和方便，可能不会听劝。目前没有推荐“采用长串无意义字符”，故猜测不少是用户自主选择，但修改用户名是有点麻烦的。--YFdyh000（留言） 2024年7月5日 (五) 15:27 (UTC)[回复]
不一定是用户“自主选择”用户名，我认为至少有一半无意义用户名只是注册时没有多想、懒得取名（没有想到需要和社群讨论和互动、没有想到编辑记录中会经常出现用户名、没有想到个人的多比贡献问题可能共同会被社群指导，等等），而不是他们有意“选择”了无意义字符串。有这种提示至少可以使这半用户稍微输入一点不那么随机的字符串。--——自由雨日（留言・贡献） 2024年7月5日 (五) 15:35 (UTC)[回复]
要不我給個新思路：我們先不要執著於“有沒有意義”的事情，我們能否界定甚麽是“亂碼”？Sanmosa 蚌埠 2024年7月6日 (六) 11:05 (UTC)[回复]
可以。其实我想限制的就是乱码，只不过觉得这个词不适合出现在方针里所以没提。--碟之舞📀💿 2024年7月6日 (六) 11:08 (UTC)[回复]
葡萄牙语维百的方针我觉得应该是能够界定的：难以理解的名称，（且）由一组重复字符或六个或更多随机字符的序列组成。至于什么是（六个以上）“随机”字符，我觉得应该可以依照常识判断吧……（虽然我个人是倾向不必强制限定，只向新注册用户“推荐”不要采用乱码的，那也就无需定义，“乱码”“无意义”或类似的词语已经足够）——自由雨日（留言・贡献） 2024年7月6日 (六) 11:11 (UTC)[回复]
那就取決於社羣是否認為「隨機字元」能被妥為定義了，如果社羣認為不能的話，那強制性規定應該是不太可能了。Sanmosa 蚌埠 2024年7月6日 (六) 11:56 (UTC)[回复]
不认为可界定。按上文，5个随机字符组成的序列可规避。--YFdyh000（留言） 2024年7月6日 (六) 13:10 (UTC)[回复]
@Diskdance、Interaccoonale：根據我對這裏的討論情勢的觀察，我認為社羣普遍不太認同「隨機字元」可被妥為定義，並因此或出於其他原因不贊同限制無意義用戶名的提案，因此我想讓兩位再重新想想是否還要繼續推進此案。Sanmosa 蚌埠 2024年7月7日 (日) 09:54 (UTC)[回复]

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

草拟方针:

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

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

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

原因是因为本人在超级战队条目配音员问题上与@DarkWizardCody起过争执（该用户主张应使用可靠的二手以及三手来源不应使用一手来源。)以及本人与香港配音社群和台湾配音社群的争执。（对官方未公开配音人员资讯的作品主张使用爱好者社群网站以及使用原创总结的手段得到的配音员资讯。)顺带ping以下其他相关专题的用户。@HK5201314--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月3日 (三) 11:54 (UTC)[回复]
@甜甜圈真好吃:
我只可說，所有規條也是相輔相成。
1. 你要「一般只記載原作國家地區及中文維基主要地區的配音員」，但你維沒有完全禁止列出其他地區的播放資料（規條不對稱 )，什至有編輯者@Factrecordor認為中維應接納世界各地的資訊。
2.WP:使用全稱，可以redirect到這個。
——
總括而言，可以把這個提案放在#電視劇演員名單序列一併討論，反正兩個的特性是一致。--唔好阻住我愛國（留言） 2024年7月3日 (三) 14:58 (UTC)[回复]
语言不超过3种时，我感觉条文1或可不应用，或者使该条文无强制力。条文2，如果官方资料使用呢，ACGN有时常用CV。不算反对，只是是否要如 配音（CV）等表述。条文3，为什么不是所有。或者，有哪些不够可靠的来源是可明确接受的。--YFdyh000（留言） 2024年7月3日 (三) 15:03 (UTC)[回复]
論點3目前已受MOS:TV規管，所以先說在上方一併討論。--唔好阻住我愛國（留言） 2024年7月3日 (三) 15:19 (UTC)[回复]
  • 首先，應說清楚與DarkWizardCody、香港配音社群、台灣配音社群的爭議是什麼。是否你們之間有人想收錄英語、法語等等的外語配音員名單？按之前其他討論中透露，似乎不是這樣，而是連收錄某些中文地區的華語配音員名單都受到阻止。如果我說得沒錯的話，那麼眼前的問題，其實本來和我主張的「中維應接納世界各地的資訊」沒有關係。若草擬方針是全新的，那麼「一般可記載原作國家地區及中文維基主要地區的配音員」更能針對眼前的問題。然而，這是參考自MOS:ACG，是因為特攝愛好者多與ACG重疊，但又不屬於ACG範圍吧，那麼應該先看看非ACG與特攝條目，究竟有沒有收錄外語配音員名單（原產地以外）的習慣，如有，應通知那邊活躍編輯者前來討論，如沒有或根本不存在這樣的條目，那就跳到下一點。
  • 不論我有沒有搞錯眼前的問題，對於我主張的「中維應接納世界各地的資訊」，我判斷的大原則是視乎設數量限制及中文地區優先之後，能不能有效解決或改善問題。配音員名單和之前討論的播放或重播資訊不同，它們是不能簡述的，所以問題會更難解決，只收錄中文地區恐怕是合理取捨。條文既寫了「一般」，將來發現特例再討論也可。我在這裡只強調，資訊性質不同，所以處理手法也可各異，不必視為不對稱。
--Factrecordor（留言） 2024年7月3日 (三) 18:03 (UTC)[回复]
然而非ACG和特摄类的条目的话也有收入配音员资讯例如韩剧来自星星的你、日剧极主夫道。--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月4日 (四) 01:35 (UTC)[回复]
重点在于配音资讯有没有必要收录（DarkWizardCody主张不收录配音资讯)以及配音资料来源的可靠性（港台配音社群对于无一手来源提供资料的主张使用原创总结内容以及配音爱好者网站作为来源）--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月4日 (四) 03:42 (UTC)[回复]
既然下面也提到MOS:ACG吵了這麼久就是無法指引化，我覺得這有點像香港修例事件一樣，為了解決一件事，引入會影響很多很多東西的條例，可能引起很多疑慮、軒然大波，倒不如尋求更具針對性的修訂。在這些爭議中最值得討論清楚的是什麼是合適來源。至於DarkWizardCody，這個名字不時都出現在編輯爭議中。我認為主張不收錄配音資訊是很個人的見解，向來在很多作品條目都被收錄非原產地的配音員名單，可見這是不少人的習慣，除了來源問題，看不出什麼現有條文能作為有力的理據反對收錄。--Factrecordor（留言） 2024年7月4日 (四) 15:36 (UTC)[回复]
有沒有發覺一件事，就是DarkWizardCody遇上編輯爭議時不參與討論。這個討論已ping他3日有多，但他仍沒有任何回應或讓步，還以高高在上的心態指導編輯工作。有一種霸住/佔領條目之嫌，但管理員對他的態度是「不作為」/「沒有任何反應」。--唔好阻住我愛國（留言） 2024年7月5日 (五) 00:27 (UTC)[回复]
说到合适来源最大的问题就是作品本身能不能成为来源(部分作品的配音人员名单一般只在作品本身的制作人员列表标注而不会标注平播放平台的制作人员列表内)以及部分未认证的配音公司社交媒体账号能否作为可靠来源使用。(部分配音公司由于条件限制只会在社交平台发布。)(DarkWizardCody相关:DarkWizardCody一般只回应在讨论页的回复不会接受ping。)--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月5日 (五) 13:41 (UTC)[回复]
DarkWizardCody是會主動使用互助客棧機制的，也懂得引用條文。沒這樣做，恐怕反映他自己都覺得在「法理」上佔不到便宜。--Factrecordor（留言） 2024年7月5日 (五) 15:32 (UTC)[回复]
日本動漫的配音指引能適用於全部電視專題條目？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月3日 (三) 18:36 (UTC)[回复]
因为配音的作品不只是动漫还有电视剧、纪录片等其他类型的电视作品需要规范。--马来西亚华人权益是不会因为某些人士（例如东姑阿都拉曼以及马华公会)龌龊的伎俩中断的--甜甜圈 2024年7月3日 (三) 23:09 (UTC)[回复]
MOS:ACG吵了这么久就是无法指引化，感觉是否具有参考价值？另外倾向用“移植”而不是“移动”的说法。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 03:10 (UTC)[回复]
我认为一手来源（例如作品官网角色来源，这个例子可能还包括代理商发布平台的介绍或者社交媒体上的介绍？）可以使用。“如果维基百科使用一次文献，仅当该文献被可信赖的出版社发表过，比如，由法庭速记员出版的庭审记录，或出现于资料汇编中的历史文献。我们不可以使用未经可信赖出版者发布的一次文献。”不要只关注后句，而是前句也需要留意，也就是“作品官网角色页面”、“代理商发布平台的介绍”应该对标为“文献被可信赖的出版社发表过”的情况。当然非要觉得“官方网站是不可信赖的，它都懂个屁作品配音介绍”的，那就当我没说过。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 03:19 (UTC)[回复]
非独立的一手来源？“如由大学出版社或主流报纸发表”恐怕在要求编审独立、信任主流出版物的查证水平。不过，某些正式出版物的准确性，可能还不如其他资料，尤其是宣传稿或仅提及。--YFdyh000（留言） 2024年7月4日 (四) 08:26 (UTC)[回复]

提议引入每周协作

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

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

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

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:用戶名、Wikipedia talk:更改用户名。

提案背景如下：

  • 目前本地用戶更名方針中，限制了對於「少量甚至沒有編輯紀錄的帳戶」的更名請求。

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

——m:Global_renamers/FAQ#Are_zero_edit-renames_allowed?
  • 因此，本人認為應移除本地之「一般不會為只有少量甚至沒有編輯紀錄的帳戶重新命名」相關敘述。另外，該段落其後的文字敘述語句極不通順，容易妨礙理解，因此本人亦提出若干修訂，使之更容易依循。

方針修訂方案如下：

現行條文

全域更名者和监管员可以為用戶修改其用戶名；可至本地或元维基提出申請，亦可使用Special:GlobalRenameRequest表单进行申请。一般不會為只有少量甚至沒有編輯紀錄的帳戶重新命名，因有更快及更容易的途徑——註冊一個新的帳戶。

當更改用戶時，隸屬於現有帳戶的貢獻紀錄將會被移至新名旗下，當中包括頁面歷史、差異、日誌及用戶貢獻等紀錄的更動。至於討論頁中的簽名則會繼續使用原有的用戶名。雖然這些簽名可以依靠人手改動過來，然而如果不是因為私人理由而想把所有有關之前用戶名的資料刪除且越多越好的話，我們不建議您這樣做。另外，這些舊名依舊會存在於討論頁面的舊版本中。用戶更動的紀錄會詳列於用戶名變更日誌中。

提議條文

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

當用戶名更改後，原帳戶的所有貢獻記錄將會被轉移至新用戶名下，包括頁面歷史、編輯差異、日誌及用戶貢獻等。至於討論頁中的現存簽名則會保持原有的用戶名不變。雖然可以手動更改這些簽名，但除非出於隱私等特殊原因需要徹底刪除舊用戶名的相關資料，否則我們不建議您這樣做。另外，這些舊用戶名依舊會保留在討論頁面的歷史版本中。所有用戶名更動的紀錄均會詳列於用戶名變更日誌中。

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

副知本地活躍的全域更名員@Jianhui67、Mys_721tx、Wong128hk以及近期經常在Wikipedia:更改用户名協助結案的@ChasingAir。-Peacearth（留言） 2024年7月4日 (四) 18:41 (UTC)[回复]
(＋)支持此提案。Sanmosa 蚌埠 2024年7月4日 (四) 22:23 (UTC)[回复]
(＋)支持：那句看起來原本是從英文維基百科翻譯過來的，不過既然全域更名無此限制，刪了好像也無所謂就是。--冥王歐西里斯（留言） 2024年7月5日 (五) 03:31 (UTC)[回复]
應該是沒什麼爭議的修訂。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月5日 (五) 04:47 (UTC)[回复]
(＋)支持此提案。感谢Peacearth的通知。Jianhui67（留言） 2024年7月5日 (五) 17:02 (UTC)[回复]
這個提案需要考慮到不妥當的用戶名問題。不妥當用戶名的用戶通常已經被封禁，不但無法提出相關申請，就算有途徑能夠改名，需時亦較註冊新帳號要長，這對於處理封禁申訴來說也缺乏效率。--AT 2024年7月6日 (六) 13:29 (UTC)[回复]
我覺得這可以用常識來處理，沒必要為此明文規定，畢竟這提案主要是想要與Global rename policy看齊，而practically讓管理員建議使用了不妥當用戶名的用戶註冊使用妥當用戶名的新帳號與提議的修改並不衝突。Sanmosa 蚌埠 2024年7月6日 (六) 13:49 (UTC)[回复]
@AT：這個提案是取消本地對於「少量甚至沒有編輯紀錄的帳戶」的舊有改名限制，並不影響不妥當用戶名問題的處理方式。相關問題的處理仍然照舊，並沒有限制他們一定要使用何種途徑改名或者註冊新帳號。另外補充一點，即使相關用戶被封禁也不會無法提出相關申請，因為我們經常會在 Special:GlobalRenameRequest 接收到相關申請。事實上，本提案乃是全域更名現行實務作法，其實可以說只是事實性修訂而已，一點都不會影響到您考慮的部分。唯一影響到的，就只是不會再因為某用戶只有少量或沒有任何編輯紀錄而拒絕他的更名請求而已。-Peacearth（留言） 2024年7月6日 (六) 18:44 (UTC)[回复]
既不影響，那我沒有異議。--AT 2024年7月7日 (日) 00:11 (UTC)[回复]

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

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

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

链接：

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

這種處理方法初步看上去沒甚麽大問題。Sanmosa 蚌埠 2024年7月6日 (六) 11:06 (UTC)[回复]
參考資料的模板只支持一個連結，可以用備註的參數加註另外一個連結，或者使用2個<ref>--Rastinition（留言） 2024年7月6日 (六) 11:09 (UTC)[回复]
我相信他是在代碼上把新舊兩版當成兩個分別的來源處理的，也就是你所説的第二種辦法。Sanmosa 蚌埠 2024年7月6日 (六) 11:53 (UTC)[回复]

技術

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

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

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

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

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

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

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

Module:Mapframe、Module:Location map报错

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

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

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

Wikiplus导致Navbar被换行

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

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

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

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

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

於Phabricator查看
編號T367645的工單
狀態：已解決

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

--桃花影落飞神剑（留言） 2024年6月17日 (一) 15:43 (UTC)[回复]

是批量出了問題，我建了很多個縣都是這樣子。經調查，這不是本人能力範圍內能解決的，只能坐等一天恢復正常。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月17日 (一) 15:51 (UTC)[回复]
是維基共享使用的底圖出問題了，各種語言維基都有顯示問題。這邊不動手，英維那邊也會吵起來，讓相關人員處理。這個應該算是技術問題？大概很快就有{{Tracked}}的工單。--Nostalgiacn（留言） 2024年6月17日 (一) 16:59 (UTC)[回复]
怀疑与最近librsvg版本升级有关--百無一用是書生 (☎) 2024年6月18日 (二) 03:02 (UTC)[回复]
根据phab:T367645#9902624的说法，svg文件原本就有问题，只是没有表现出来，librsvg升级后这个问题变严重了。可以参考下这个[21]，一大堆的报错--百無一用是書生 (☎) 2024年6月19日 (三) 02:25 (UTC)[回复]
舉例的圖片，以上傳新圖片解決了。不過仍然有很多圖片沒有上傳新圖片取代。如右圖（Virginia）
Virginia
--Nostalgiacn（留言） 2024年6月30日 (日) 06:50 (UTC)[回复]
工單上編者Nux已經使用機器人替換相關圖片，美國相關圖片已經替換。不清楚是否有有其他國家或地區使用同類圖片，Phabricator上的工單已經標記完成，關閉了。--Nostalgiacn（留言） 2024年7月7日 (日) 02:53 (UTC)[回复]

请求修改Cite book对统一书号的支持

前次未获回应的请求见此，这里重新复制粘贴下：

发现大量由中国标准出版社出版的中华人民共和国国家标准纸质出版物，将统一书号的第二部分添加了短横线（如 GB/T 10302-2010 的 155066·1-40495、GB/T 33677-2017 的 155066·1-56323 等），也出现混用了圆点·与短横线-的情况（GB/T 32626-2016 的 155066-1-55030）。虽然暂时没找到短横线的意义是什么，但请求修改Module:Citation/CS1/Identifiers以添加对第二个短横线的支持，以及不要强制将-转为·。--Tim Wu（留言） 2024年6月28日 (五) 06:05 (UTC)[回复]

需要耐心等待，之前類似的统一书号修改請求（Cite_book的unified需要更新），我在2022年10月提出，到2024年5月才給出臨時應對方案{{统一书号}}，我想應該優化的是{{统一书号}}。因為英維根本不用统一书号，沒法參考，要這邊獨立寫。--Nostalgiacn（留言） 2024年6月30日 (日) 06:47 (UTC)[回复]

TW部分功能故障

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

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

@Xiplus @Manchiu--百無一用是書生 (☎) 2024年6月30日 (日) 06:19 (UTC)[回复]
大概是mw:Heading HTML changes？——暁月凛奈 (留言) 2024年6月30日 (日) 06:43 (UTC)[回复]
能否給一下具體的案例（固定版本號或差異），不然上面三個問題我目前都無法重現。--Xiplus#Talk 2024年6月30日 (日) 13:08 (UTC)[回复]
  1. 1應為此版本。我也有同樣情況。以為是自己瀏覽器問題。（我本身需F5多遍方看到關閉討論鍵。）-千村狐兔（留言） 2024年6月30日 (日) 13:15 (UTC)[回复]
    @Manchiu，Wikipedia:頁面存廢討論/記錄/2024/06/24，你的操作似乎也发生了错位，杨尚铭和王红权星被标记为允许并入，Eva IM client被标记为删除，已删除的陳美琪 (企業家)被标记为允许并入...--百無一用是書生 (☎) 2024年7月1日 (一) 02:09 (UTC)[回复]
    Special:PermaLink/83231036--百無一用是書生 (☎) 2024年7月1日 (一) 02:10 (UTC)[回复]
    建议这个问题未修好前，暂时不要使用TW来处理存废讨论，我刚用了一下，结果错位得太离谱了！--百無一用是書生 (☎) 2024年7月1日 (一) 02:15 (UTC)[回复]
    謝謝修正錯誤。真的不好意思！--千村狐兔（留言） 2024年7月1日 (一) 02:26 (UTC)[回复]
    @Manchiu：Wikipedia:頁面存廢討論/記錄/2024/06/23也有錯位的問題。--夏冰 2024年7月1日 (一) 03:43 (UTC)[回复]
    我重新回退后，全手工处理了一遍，请复查--百無一用是書生 (☎) 2024年7月1日 (一) 02:28 (UTC)[回复]
2.無法關閉是[22]（TW刪除）、Special:Diff/83221043（手動關閉）
3.錯位是Special:Diff/83212283--夏冰 2024年7月1日 (一) 01:08 (UTC)[回复]
已確認這是由Vector2022引起的，Vector2010運作正常。--Xiplus#Talk 2024年7月1日 (一) 14:04 (UTC)[回复]
根據 Heading HTML changes，應該所有的標題（h1-h6）都會被加上 mw-heading，但不知為何在 Vector 2022 僅有 h2 被加上，導致計算章節數量時錯誤而造成此問題，為避免 Vector 2022 後續再次更改，我暫時決定在 Heading HTML changes 完成前不會支援 Vector 2022，請改用其他外觀，經測試本功能在 Vector 2010 運作正常。--Xiplus#Talk 2024年7月1日 (一) 14:45 (UTC)[回复]
顺便说一下，Timeless下好像也无关闭讨论按钮。--Kethyga（留言） 2024年7月7日 (日) 10:49 (UTC)[回复]

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

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

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

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

機器人給隱退用戶發消息的情況

隱退用戶理論上不再使用賬號了，但是我留意到機器人還是會繼續給這些用戶發消息，如這個。請問是否有改善的空間，例如隱退就自動屏蔽所有消息？--Nostalgiacn（留言） 2024年6月30日 (日) 11:00 (UTC)[回复]

可以nobots或者保护页面。但，是否有显著的必要性？--YFdyh000（留言） 2024年6月30日 (日) 12:20 (UTC)[回复]
儘管浪費的這些性能和佔用的空間可能微不足道，但是給我一種感覺，人已經搬走了，外面的信箱還一直收到郵件。不清楚隱退後，討論頁的電子郵箱的通知功能是否也一併自動除去，否則也是給用戶電郵寄送垃圾郵件。--Nostalgiacn（留言） 2024年7月1日 (一) 02:25 (UTC)[回复]

维基百科:其他语言的维基百科典范条目/英語版這樣的標題是否屬於繁簡混用？

维基百科:其他语言的维基百科典范条目/英語版這樣的標題是否屬於繁簡混用？有很多這樣的頁面需要移動。--Midleading（留言） 2024年7月1日 (一) 09:38 (UTC)[回复]

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

2024年第27期技術新聞

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

最近更改

  • 在未來三週內，從行動版網頁開始，深色模式將逐步供所有用户使用，無論登入與否。這實現了社群最迫切的願望之一，並改善低對比環境下的閱讀體驗以及低光環境下的使用。作為這些變更的一部分，深色模式現在可以在用户页和主題頁面使用。詳情請見網頁團隊的最新更新。 [23]
  • 已登入用户現在可以设置字型大小和深色模式的全域参数设置，感謝基金會各團隊的共同努力。如此，穿梭多個wiki的維基人能夠輕鬆地建立一致的閱讀體驗，例如，只需设置一次即可為所有wiki切換淺色或深色模式。 [24]
  • 維基媒體維基上的部分功能將不再兼容老舊的網頁瀏覽器。這將影響Internet Explorer 11以及早於2016年的Chrome、Firefox和Safari版本。這使我們能夠使用新的CSS特性，並向所有讀者傳送更少的代碼。 [25][26]
  • 維基百科管理員可以使用社群配置功能，輕鬆自訂本地配置選項。社群配置旨在使社群能夠自訂特定功能的運作方式，以滿足不同語言版本維基的獨特需求。目前，管理員可以在其維基配置Growth功能，以更有效地吸引和留住新編輯者。未來幾個月將提供更多選項。 [27]
  • 有興趣探討與Unicode標準相關語言議題的編輯者，現可於MediaWiki.org的新對話空間討論這些話題。維基媒體基金會現已成為Unicode聯盟的會員，協調小組將共同審查討論議題，並適當地傳達給Unicode聯盟。
  • 一個新的維基已创建： 曼代靈語维基百科 (w:btm:) [28]

問題

  • 在修復錯誤後，編輯者再度能夠在可视化编辑器中點擊引註預覽中的連結，感謝編輯團隊修復錯誤。 [29]

未來更改

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

技術新聞由技術新聞編者撰寫，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

MediaWiki message delivery 2024年7月1日 (一) 23:57 (UTC)[回复]

跨語言連結

中文條目有半敞篷車（汽車）和蘭道車（馬車），英文條目有en:Landau (carriage)，en:Landaulet (car)和消歧義en:Landaulet。“半敞篷車”原連至wikidata:Q1297112（消歧義），我已改爲連至wikidata:Q4044718（汽車），但現時中維點去英維仍連至消歧義，這是系統更新需時還是其他技術原因？--惣流·明日香·蘭格雷不姓式波 2024年7月3日 (三) 06:39 (UTC)[回复]

Special:Diff/83261102。页面内的会比wikidata的优先。——暁月凛奈 (留言) 2024年7月3日 (三) 06:50 (UTC)[回复]
學到了，請問那些連結是舊做法對吧，現在還有沒有情況會用到，還是已連至wikidata下的情況可全部移除？--惣流·明日香·蘭格雷不姓式波 2024年7月3日 (三) 07:05 (UTC)[回复]
一些特殊情况下能够用到，不过通常来说是用不上的。——暁月凛奈 (留言) 2024年7月3日 (三) 11:47 (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)[回复]
[30]，分别是固定宽、不固定宽，使用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)[回复]

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

如题，条目标题出现多余得“维基百科”，今天第一次出现，见截图，多出的是图片版的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)[回复]

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

大家好，在過去的一年裡，維基媒體基金會的網頁團隊一直致力於深色模式的開發。這項工作是無障礙閱讀計劃的一部分（該計劃引入了對 Vector 2022 和 Minerva 皮膚的更改）。這提高了可讀性，並允許每個人（無論是未登入的使用者還是已登入的使用者）自訂以閱讀為中心的設定。

自今年年初以來，深色模式已作為測試版功能在行動版和桌面版網站上向大家提供。我們一直在與模板編輯者和其他技術貢獻者合作，為此功能準備不同的維基專案。這項工作包括修復模板並確保許多頁面均可以以深色模式顯示，而不會出現任何無障礙問題。我們對參與此事的所有人表示衷心的感謝。因為已經做了很多工作，深色模式已經可供未登入及已登入的使用者在行動版網站上使用。在接下來的兩週內，我們將向桌面版網站的使用者釋出此功能！

部署配置和時間表

  • 第 1 級別與第 2 級別維基百科：與淺色模式相比，深色模式的問題數量並不顯著的維基百科。這些維基專案已經為未登入及已登入的使用者提供深色模式。不過，模板中可能仍存在一些小問題。我們將添加報告這些問題的方法，以便我們可以繼續與編輯者一起修復模板。
  • 第 3 級別維基百科：與淺色模式相比，深色模式的問題數量非常多的維基百科。這些維基只會為已登入的使用者提供深色模式。我們希望為所有用戶提供深色模式。然而，有些維基專案仍然需要社群的工作來調整模板。與上面的群組類似，這些維基專案同時會收到一個報告問題的鏈接，這將有助於識別剩餘的問題。
  • 7 月 1 日的當週：第 1 級別的維基百科（包括中文維基百科）上的行動版網站（Minerva 皮膚）
  • 7 月 15 日的當週：所有維基百科上的桌面版網站（Vector 2022 皮膚）；行動版網站：在第 2 級別維基百科上已登入的使用者和未登入的使用者，第 3 級別維基百科僅限於已登入的使用者

如何開啟深色模式

此功能會與文字和寬度選項一起出現在「外觀」功能列表中。根據相容性和技術架構的不同，某些頁面可能無法在深色模式下使用。對於這些頁面，選單中會出現一則通知，提供更多資訊。

如何讓深色模式變得更好！

如果您想協助讓更多頁面適合深色模式，請前往我們先前的訊息並查看「我們希望您做什麼（模板編輯者、介面管理員、技術編輯者）」部分。

謝謝大家。我們期待您的問題、意見和評論！(Translated by VLui (WMF) and SCP-2000)--SGrabarczuk (WMF)（留言） 2024年7月4日 (四) 13:48 (UTC)[回复]

可喜可贺！L'Internationale, Sera le genre humain! ✏️ 2024年7月4日 (四) 14:05 (UTC)[回复]
Note: I bolded some sentences for easier reading. Thanks. --SCP-0000（留言） 2024年7月4日 (四) 14:15 (UTC)[回复]
借个楼顺便说一下中维导航模板的深色模式适配还是有问题，Shizhao做完深色模式适配之后“查论编”链接在正常模式下无法更改颜色了。--Dabao qian℡ 2024年7月4日 (四) 15:56 (UTC)[回复]
@Dabao qian：深色模式兼容性問題可在Wikipedia:徵求意見/深色模式反映。--SCP-0000（留言） 2024年7月5日 (五) 01:06 (UTC)[回复]
楼上的签名在深色模式下不适配....--百無一用是書生 (☎) 2024年7月5日 (五) 03:33 (UTC)[回复]
能否有高人幫我看一下本人的簽名和主編條目肯塔基州城市列表、堪薩斯州城市列表等在深色模式下是否有問題？本人怎麼設置也無法在Vector 2022中試用深色模式。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年7月5日 (五) 04:32 (UTC)[回复]
@SickManWP：如果您是使用桌面版，現階段您需要先在測試功能設定中啟用「無障礙閱讀」才能使用。而行動版可在設定中啟用。--SCP-0000（留言） 2024年7月5日 (五) 04:41 (UTC)[回复]
已設置完成。不過我希望看看其他用戶對條目的意見，避免過幾天本人編寫更多類似列表時出現顯示問題，影響條目評選。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年7月5日 (五) 04:48 (UTC)[回复]
两个条目的表格颜色有问题--百無一用是書生 (☎) 2024年7月5日 (五) 08:15 (UTC)[回复]
相關條目的問題本人已於Wikipedia:徵求意見/深色模式中提出，目前正在尋找解決辦法。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年7月5日 (五) 08:19 (UTC)[回复]

Twinkle關閉存廢討論無法在Vector 2022使用

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

最近幾天有使用Vector 2022介面的使用者，可以發現在WP:AFD及WP:FFD無法用Twinkle關閉存廢討論，需要改以Vector 2010介面才能使用，有甚麼方法修復這樣錯誤？謝謝！--Sinsyuan✍️🌏🚀 2024年7月5日 (五) 01:27 (UTC)[回复]

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

Timeless显示错误

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

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

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

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

T:Summer Olympics by year category navigation

參見Category:2024年夏季奧運足球賽（簡）、Category:2024年夏季奧運足球賽陣容（繁），想請問有什麼方法可以讓此模板同時在簡中/繁中標題的分類中使用？--Liebhart 💬👩‍🚀 2024年7月7日 (日) 04:15 (UTC)[回复]

求助

怎么关闭结构式讨论

测试功能里好像没有这个选项了，我想把我的讨论页面的结构式讨论关掉。--Vozhuowhisper 2024年6月18日 (二) 04:09 (UTC)[回复]

感觉是bug，可以请求管理员协助或者在Phab上开个工单？--碟之舞📀💿 2024年6月18日 (二) 07:50 (UTC)[回复]
考慮到不太可能有人願意修正，那唯有管理員人手移動就是了。cc @Ericliu1912：--SCP-0000（留言） 2024年6月21日 (五) 18:35 (UTC)[回复]
@SCP-2000：至少有序退場是基金會應保有的程序正義。我是覺得先試著開工單，順便提醒全域社群，沒有下文的話再說。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月21日 (五) 19:53 (UTC)[回复]
@Ericliu1912：看來這是已知問題，他們似乎沒有修正的打算，所以管理員手動修正就可。--SCP-0000（留言） 2024年6月22日 (六) 02:41 (UTC)[回复]
@Vozhuo：我已經協助移動您的討論頁，目前看起來一切正常。有問題可再通知我。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月27日 (四) 06:24 (UTC)[回复]
谢谢。--Vozhuowhisper 2024年6月27日 (四) 10:23 (UTC)[回复]

請求協助上傳檔案 2024-06-20 12:08

我想要上傳的圖片來源是<https://dramago.ptsplus.tv/wp-content/uploads/2024/05/%E5%B0%B1%E7%AE%97%E4%B8%80%E5%80%8B%E4%BA%BA%E4%B9%9F%E5%8F%AF%E4%BB%A5%E5%A5%BD%E5%A5%BD%E7%9A%84%E5%90%83%E9%A3%AF-%E6%9D%8E%E7%8E%B2%E8%91%A6-04-1024x1536.jpg>，想要使用在李玲葦的<資訊框>。 --Fujiwara nastuki（留言） 2024年6月20日 (四) 12:08 (UTC) 由於權限不夠無法上傳，共享資源所上傳的圖片檔案也被移除，希望有更高權限使用者增加上述圖片。 如果可以的話，請在正文也添加相關圖片以豐富內容。[回复]

@Fujiwara nastuki您好，此图片似乎非自由版权图片，且因在世人物无法合理使用，不能上传。--在下荷花，请多指教（欢迎签到） 2024年6月28日 (五) 14:40 (UTC)[回复]

如何上傳論文研究成果

如題--焦畯甫（留言） 2024年6月21日 (五) 19:39 (UTC)[回复]

維基百科不是發表您個人思想或分析，或者公布新資訊的地方。如果在初級研究之中獲得成果，請於其他場所，例如論文期刊、其他紙本形式、開放研究或網上出版物發表。維基百科會等到一項研究獲得發表，得到同行評審及公認為知識以後，才記載此項研究。——暁月凛奈 (留言) 2024年6月21日 (五) 19:55 (UTC)[回复]
上传论文的研究成果的话，维基学院可能适合你。--桐生ここ★[讨论] 2024年6月21日 (五) 20:45 (UTC)[回复]
( π )题外话：可等来一个有论文研究成果的了，维基学院都不像一个发表研究成果的地方，快变成Fandom了。--桐生ここ★[讨论] 2024年6月21日 (五) 20:49 (UTC)[回复]
@桐生ここ、Ericliu1912：不是，他的论文是正经学位论文，过了review的，大概已经是申明COI就能直接引用的程度？ --Trz1118（留言）来人救救金属学和材料科学条目们吧 2024年6月30日 (日) 04:38 (UTC)[回复]
建議前往維基學院。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 09:44 (UTC)[回复]

身份被冒用

不知為何被亂用我的名義--2401:E180:8D03:9F59:3A82:E572:108B:89C（留言） 2024年6月25日 (二) 16:53 (UTC)[回复]

您指？--HeihaHeihaHa-麻瓜了……（留言） 2024年6月25日 (二) 16:58 (UTC)[回复]
查編輯歷史，人家是1917年—1995年的人，怎麼冒用你的名義？--桐生ここ★[讨论] 2024年6月26日 (三) 00:07 (UTC)[回复]
遇上重名的能咋办，还能把人家挖出来求他改名吗？不如学学江总书记，另一个江泽民死了还管送花圈的--Trz1118（留言）来人救救金属学和材料科学条目们吧 2024年6月30日 (日) 04:32 (UTC)[回复]

导航框过长

本主題全部或部分段落文字，已移動至Template talk:2018年太平洋颶風季。执行人：Jimmy-bot（留言） 2024年7月7日 (日) 08:14 (UTC)。[回复]

請求協助上傳檔案 2024-06-27 08:44

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

?--在下荷花，请多指教（欢迎签到） 2024年6月28日 (五) 14:37 (UTC)[回复]
@毕明明请提供信息--在下荷花，请多指教（欢迎签到） 2024年6月28日 (五) 14:38 (UTC)[回复]

調用重複模板參數小工具

如標題，請問現在有人有顯示模板意外使用到重複參數時能提醒是哪個參數重複了的小工具嗎？我常常會先寫好一大堆cite模板後才發現有重複參數，但根本不知是哪個重複到...得花很多時間回去找。因為小工具好像都四散在不同編者的用戶內頁，不知從何找起只好來這裡詢問了。--WiTo🐤💬 2024年6月27日 (四) 10:31 (UTC)[回复]

维基百科:命名常规#地名的执行问题，需要更多用户关注

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

早在6年前，该方针的地名章节规定的除区划条目自身以外，涵盖某一行政区全境内情况的条目、模板、分类等，其命名均应采用区划全称就已经获得通过（Wikipedia_talk:命名常规/存档13#提议修改Wikipedia:命名常规#地名（其二）），但目前仍然有大量的分类名称和模板名称未将本条执行到位，需要有更多用户对本情况予以关注。希望能尽早对没有改过来的现存分类和模板更名完毕。--——— 红渡厨（留言・贡献） 2024年6月27日 (四) 15:54 (UTC)[回复]

如何更改明星首頁圖片

--KyuKyu99（留言） 2024年6月28日 (五) 16:27 (UTC) 請問如何更改明星首頁的圖片？ 我是阿ken經紀人～很希望能換掉首頁的圖片[回复]

謝謝

我的信箱是：[email protected]

謝謝

版權檢查請求

大家好。本人懷疑條目香港賽馬會慈善事務一節有侵權疑慮：我認爲該節直接複製來自此處，且原文網站底部載有「版權所有 不得轉載 © 2000-2024 香港賽馬會」字樣。希望大家能協助檢查該條目的版權問題。--夢之風 2024年6月29日 (六) 01:27 (UTC)[回复]

有没有方法能够查找到在正文中出现外部链接的页面？

某次浏览维基百科时，发现部分页面在正文中大量使用外部链接代替跨语言链接（例如这个）或代替网址导航（例如这个），这显然违背了WP:ELNO。

我希望找出更多类似页面，但由于搜索引擎只会抓取文字内容，难以直接利用搜索来寻找类似内容。此外，追踪分类和WP:PETSCAN也没有提供类似的筛选功能，因此我只好在此求助，希望了解如何寻找这类在正文中堆砌外链的页面。 --Trz1118（留言）来人救救金属学和材料科学条目们吧 2024年6月30日 (日) 04:24 (UTC)--Trz1118（留言）来人救救金属学和材料科学条目们吧 2024年6月30日 (日) 04:24 (UTC)[回复]

补充：专门设计用来堆放外链的“外部链接”章节技术上也属于正文，使得这个问题更加难以解决了。--Trz1118（留言）来人救救金属学和材料科学条目们吧 2024年6月30日 (日) 04:25 (UTC)[回复]
或可問問@Kanashimi有沒有遇過這種情況。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月30日 (日) 06:19 (UTC)[回复]
[31]--Kanashimi（留言） 2024年6月30日 (日) 09:50 (UTC)[回复]
感谢，虽然只解决了部分问题，但估计够维护好久了……--Trz1118（留言）来人救救金属学和材料科学条目们吧 2024年6月30日 (日) 16:19 (UTC)[回复]
其實這應該能用機器人修...--Kanashimi（留言） 2024年6月30日 (日) 20:49 (UTC)[回复]
en:H:INSOURCE--Miyakoo（留言） 2024年6月30日 (日) 15:28 (UTC)[回复]
發現還有用英維當來源的。--Miyakoo（留言） 2024年6月30日 (日) 15:49 (UTC)[回复]

請求協助上傳/替換照片

我想要上傳的圖片來源於該藝人的個人官方網頁<https://x.com/NEWENTRY_Niel/status/1741836717580325203> 想要使用新的照片替換目前NIEL個人維基百科的照片，因權限不夠無法上傳，請求幫助，謝謝您。新的照片連結如下: https://x.com/NEWENTRY_Niel/status/1741836717580325203--BooniNI（留言） 2024年7月1日 (一) 12:24 (UTC)[回复]

這是非自由圖片而且在世人物禁止合理使用--—— Matt Zhuang表示有事按「此」留言 2024年7月1日 (一) 13:00 (UTC)[回复]

请协助撤销疑似的破坏性修改

该修改是否涉及破坏？我的撤销编辑被警告违反方针。--ChromaPIE（留言） 2024年7月2日 (二) 06:18 (UTC)[回复]

您的意思是说您无法撤销这笔编辑吗？可能是过滤器触发了：实际上IP的该修改是破坏，但您的反修改被过滤器误认为是破坏。这种情况下，只要您能肯定自己的编辑没问题，是可以再点击确认无视过滤器警告从而实现编辑的（否则IP也没法作出这笔编辑）。--自由雨日（留言） 2024年7月2日 (二) 06:22 (UTC)[回复]
好的。感谢。--ChromaPIE（留言） 2024年7月2日 (二) 06:53 (UTC)[回复]

申请语言链接X波段防卫通信卫星至日文，并删除我命名空间下的内容

本主題或以下段落文字，在討論結束後應存檔至Talk:X波段防卫通信卫星。

我最近把jp:Xバンド防衛通信衛星翻译成了中文。但由于翻译权限不够，先创建了User:Yusancky/X波段防卫通信卫星，再移动到了X波段防卫通信卫星。

我想删除User:Yusancky/X波段防卫通信卫星，但是没有权限。我不打算再对其修改，申请删除。

由于 X波段防卫通信卫星是jp:Xバンド防衛通信衛星的中文条目，现在此申请语言链接。

--Yusancky（留言） 2024年7月2日 (二) 06:32 (UTC)[回复]

已帮您挂上{{delete|o1}}模板，以后想删除自己用户页时在条目顶端写上它就行（因为这是跨命名空间的重定向，可能过一段时间机器人也会自动请求删除？）。语言链接，可以通过工具->添加跨语言链接操作，我刚刚帮您完成了。--自由雨日（留言） 2024年7月2日 (二) 06:38 (UTC)[回复]
另外，根据著作权要求，翻译页面需在条目讨论页挂上模板说明，您可根据{{翻译自}}模板选择参数填写。谢谢！--自由雨日（留言） 2024年7月2日 (二) 06:48 (UTC)[回复]
谢谢你的提醒和操作，我已经挂上了模板。--Yusancky（留言） 2024年7月2日 (二) 09:41 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Category talk:中南大学维基人。

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

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

还有，{{User CSU}}里面的分类也修改了。--—梦夕琳 如有事，请快来沟通 2024年7月3日 (三) 05:41 (UTC)[回复]
看起來沒問題了。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月3日 (三) 08:21 (UTC)[回复]
@Ericliu1912 应该是有人修复了。—梦夕琳 如有事，请快来沟通 2024年7月3日 (三) 11:29 (UTC)[回复]
其實您把模板分類處理完，其餘頁面就會自動歸類。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月3日 (三) 18:30 (UTC)[回复]
出了什么问题？--自由雨日（留言） 2024年7月3日 (三) 08:54 (UTC)[回复]
@自由雨日 没问题了，已经有人搞好了；就是一开始分类移动没搞好。—梦夕琳 如有事，请快来沟通 2024年7月3日 (三) 11:30 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

請求協助編輯內容

請求協助編輯此條連結中的內容：Talk:洛陽鉬業#請求協助增添以及刪除社會責任章節相關內容 。謝謝！--SandroP3l（留言） 2024年7月4日 (四) 03:10 (UTC)[回复]

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

請求協助上傳檔案 2024-07-05 10:11

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

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

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

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

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

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

此例是人手寫的，Special:Diff/83094952。
上面很長的，也是人手寫的，Special:Diff/82711408。
TW應該是沒有這個功能。--Miyakoo（留言） 2024年7月6日 (六) 09:56 (UTC)[回复]

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

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

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

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

請求協助上傳檔案 2024-07-06 14:18

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


條目探討

闽方言条目命名

1987年《中国语言地图集》（“第1版”）将汉语方言（指汉语族下除了东干语的方言连续体，下同）分成五个层次：大区——区——片——小片——点。官话区、闽语区两个方言区列为大区，下设区；其它方言区下设片。闽语的划分人张振兴在载1997年《方言》第4期的《重读〈中国语言地图集〉》中说：

2012年《中国语言地图集》（第2版）中闽语就降格为区，譬如闽南方言原称闽南区现称闽南片。

今天我注意到@桜花雪 君根据12年地图集做了一些更改，包括将闽东语移动到闽东片，将长乐话 (闽东语)移动到长乐话 (闽语)，将条目中闽语的语（区）改为片、片改为小片等。

我认为首先「闽东片」可能不符合WP:COMMONNAME：谷歌搜索"闽东语"有一千七百万结果，"闽东话"三万六千，"闽东方言"一万两千，"闽东片"仅964。闽南语-闽南话-闽南方言-闽南片则是6.7亿-673万-13万-3220。再看泉漳片:泉漳小片是48700:818，虽然没有排除2012年以前的数据（忘设置了，懒得重搜）但是几个数量级的差异面前我认为闽东片还是不适合作条目名称的。

另外就是12年地图集中闽语方言的新名字在学术文章的流行度也存疑。找了近年的几篇文章有用12年地图集片-小片的，也有按传统区-片的。

  • 前者如
    • 2024年陈浩淼《再论泉州方言豪韵［-ɔ］和［-o］的关系》（12年地图集）「归入闽语闽东片侯官小片的尤溪方言」
    • 2024年陈浩淼《闽北方言豪韵语音层次》「一些闽语闽南片、雷州片、琼文片方言」「属闽语邵将片的光泽方言」
    • 2023年徐睿渊《福建厦门方言的动词重叠》「据（12年地图集），厦门方言属闽语闽南片泉漳小片。」
    • 2022年张燕芬《广东揭阳(榕城)方言同音字汇》「（揭阳）境内闽方言属于闽南片潮汕小片」
    • 2022年江裕婷《汉语“缺少”义词研究》「闽语闽南片的厦门话」
    • 2022年林玲《20世纪中叶浙江方言词语的地理语言学考察》「属闽语闽东片方言」
  • 后者如
    • 2024年张爱玲 et al.《探究地名用字“屿”》「调查了闽南区泉漳片」
    • 2023年秋谷裕幸《闽东区方言的｛眼睛｝义词及其相关的词语》「闽南区潮汕片海丰方言」
    • 2022年任翔宇《闽东方言的形成：地理与历史因素的交汇》「闽东方言南片（侯官片）和北片（福宁片）」
    • 2022年陈泽平 et al.《〈戚林八音〉“遮同奇”初探》「（87年地图集中）宁德方言属于侯官片，本文则把它归属福宁片。」「莆仙区仙游方言读作」
    • 2017年陈伟蓉《福建惠安闽南方言的关系从句标记》「隶属闽南区泉漳片」
  • 甚至还有颜铌婷 et al.《永春方言先行事态助词的形式、分布及来源》混用。

另外，本站还会参考ISO 639-3，如果将语改片的话会不会很奇怪？但是如果不从12年地图集的话，可能后续新的方言片的调整会遇到命名难题，无法向后兼容了。

因此我向客栈寻求解决方案，包括代号为cdo的语言的命名，以及对闽语各方言的划分和称呼。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月25日 (六) 21:48 (UTC)[回复]

《中國語言地圖集》顯然並非唯一且毫無爭議的劃分標準。Sanmosa 人人皆王 2024年5月26日 (日) 23:39 (UTC)[回复]
首先、閣下你得要看閩語方言內部劃分的歷史：
「閩東語」這一詞最早也是有中國大陸語言學界提出的、台灣只有也只認閩南語和閩北語兩語劃分稱謂。相反到最後台灣學術界也是慢慢的採用中國大陸的這套劃分標準。
但到了西曆2012年後、閩語方言內部就又劃分成把閩語內部所謂的「語換片」（即：閩東片・莆仙片・閩南片・閩北片・閩中片・邵將片・瓊文片・雷州片）和「片換小片」（即：侯官小片・福寧小片・泉漳小片・大田小片・潮汕小片・浙東南小片・贛東北小片・建甌小片・建陽小片・邵武小片・將樂小片・府城小片・文昌小片・萬寧小片・崖縣小片・昌感小片）。至此劃分情況基本和粵語吳語一致統一定性。
在現有劃分（即：語-片-小片）之前、也有學者對閩語方言內部的（即：語-語）頗有爭議。如：在詹伯慧的一篇『關於聞方言研究的一些思考』的論文裡就提到過：
故此、現已經在『中國語言地圖集』提出了最新版本的劃分、目前看也是沒有爭議的（『關於聞方言研究的一些思考』也是在西曆2012年出版『中國語言地圖集』之前發表）、故此應當引用新標準的劃分更為合適。如果還按照舊制（即：語-語）劃分、說明在維基百科閩語條目中引用的文獻資料有很嚴重的知識年代滯後性、要掛上「此章節是已過時的用法、需要及時更新」的模板、並且要在粵語和吳語或者是其它語言條目引用過『中國語言地圖集』（西曆2012年第二版）的文獻都應該刪掉。--桜花雪・爲了儂家各儂其閩越共民族 2024年5月27日 (一) 03:56 (UTC)[回复]
  • 首先我觉得，根据WP:COMMONNAME采用「闽东语」的条目名称，和「拒绝采纳12年地图集」根本没有关系。虽然《中国语言地图集》并不是国家规范，但其划分也是学术的（比较重要的）一说，我没有主张过将12年地图集的参考资料删去。
  • 另外，并非只有第一级方言才能用「语」。李荣《汉语方言分区的几个问题》（1985）2.1 通名部分就举「闽南语」「苏州语」的例子。后文也只说「语」「一般用来组成方言区的名称」：
  • 再者，《地图集》并不是规范，异说很多，87年提出的晋语、平话独立还辩了二十年呢（好像一直排他性也得打个问号）。闽语也不是2012年一出版就突然从大区变成区了。87版地图集A2图李荣《汉语方言的分区》就提出「闽语大区也许改成闽语区好一点」。张振兴《重读〈中国语言地图集〉》（1997）也说「闽语大区应改为区」。而从近期的论文来看这种变动并非是广泛接受的，用旧划分法的并不是一个两个。不过原片现小片的可以考虑使用情况改等级（不过如果原来有小片的话就要变成「点」了？好像有点奇怪）
 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月30日 (四) 09:20 (UTC)[回复]
閣下引用的『漢語方言分區的幾個問』、像「福州語」「蘇州語」這種以地級市冠名語的一般不是漢藏語系的學術劃分、反而更是民間對於當地方言的一種別稱、有約定俗成的情況。而「閩南語」則相反、早是在民國時期就已經有在學術界提出來了、這兩種情況不能同日而語。故此像「福州語」「蘇州語」這種以地級市冠名語的不具有學術意義的採用詞彙、這也是為什麼這種地級市+語的稱呼只能放在「又稱」一欄後面的原因。
而且閣下引用文獻的這個時間段根本就還沒有2012年新版劃分的問世。按照正常情況來看、如果說『中國語言地圖集』是具有爭議的劃分書籍、那應該請閣下拿出自2012年以後（不包括2012年以前）在學術界對『中國語言地圖集』（2012年第二版）的反對觀點和意見論文才對、而不是去追究名詞採用的問題。閣下引用支持「語-語」的劃分文獻均是上世紀八九十年代的論證、「歷史文件不具有現實意義」。--桜花雪・爲了儂家各儂其閩越共民族 2024年5月30日 (四) 12:09 (UTC)[回复]
1. 是的，所以我要说语并不是一个方言单位（什么「语—语」「语—片」，都不是地图集的划片方式），大区—区—片—小片—点才是，用「闽东语」也并不违反12年地图集「闽东片」的划分，何况这个词符合WP:COMMONNAME。2. 一部学术作品不可能没有「争议」，确实有一些论文对12年地图集的划片提出意见，但争闽语是区还是大区我连写一篇维基论述都不想写，想来是没有论文愿意去争这个。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月2日 (日) 07:36 (UTC)[回复]
一・「閩東片」才符合WP:COMMONNAME、因為這也是目前學術能搜得到並且是有官方認可的劃分。如果說是為了WP:COMMONNAME裡的：使用常用的名稱作為標題也更易於讀者搜尋。的話、那直接加重定向即可。也就是說「閩東語」直接可以重定向到「閩東片」去即可。就像民間更多把學術界稱呼的高吸水性聚合物稱呼為水晶寶寶一樣處理。而且水晶寶寶一詞也更為被民間所人知、比高吸水性聚合物一詞說的更多、也更符合閣下所說的WP:COMMONNAME裡的：使用常用的名稱作為標題也更易於讀者搜尋。以及和一般情況下，常用的名稱也是較為簡短的，可以避免條目名稱過於冗長。所以高吸水性聚合物為何不用的水晶寶寶該稱呼？
二・有爭議就應該拿出來看看、這些都是什麼類型的爭議、其次是這些類型論文佔比一共有多少篇、然後再和02年版本的『中國語言地圖集』來相比看哪一個爭議會更多、如果說2012年的『中國語言地圖集』的爭議比02年的『中國語言地圖集』的爭議少、那就應當引用該文獻裡的詞彙。閣下說有論文指向對12年地圖集的劃片提出意見、那就應該展示出來分析裡面到底是講了什麼意見情況。而不是說把這些全部意見都打入到反對2012年的『中國語言地圖集』劃分中去。--桜花雪 2024年6月2日 (日) 11:32 (UTC)[回复]

闽方言条目是否应采用12年地图集「闽语—片—小片」的命名方式？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月2日 (日) 07:38 (UTC)[回复]
目前臺澎金馬方面有機構正式管理該語，也是某地的官方語言，理應以文化部稱呼命名。如果臺方官方機構仍在稱「閩東語」，那麼這反映部分以該語為官方語言的地區仍然同意「上世紀八九十年代的論證」，而不能視作「歷史檔案」；中國大陸方面的「中國語言地圖集」調整了語言及方言的命名劃分，那就只修改中國大陸簡體顯示模式的變體就好，中國大陸方面的語言政策管不到臺澎金馬，不應該為此就排除了臺方的叫法。此〔閩東語〕→〔閩東片〕移動屬為轉換地區詞而移動條目，應是目前方針不容許的。--路西法人 2024年6月2日 (日) 08:25 (UTC)[回复]
一些台方官方机构的网站上确在使用“闽东语”这一称呼：[32][33]--CuSO4 · 龙年大吉 2024年6月5日 (三) 22:43 (UTC)[回复]
中华人民共和国官方用“壮侗语族”（或侗台语族）而非“壮侗语系”（[34]），在中国知网搜索，“壮侗语族”也呈压倒性优势（若使用关键词搜索“壮侗语系”甚至得到0结果），但中维并不采用“壮侗语族”这一名称。--自由雨日（留言） 2024年6月6日 (四) 03:29 (UTC)[回复]
另外除知网外，根据Google也可明显得出谁是COMMONNAME：带引号搜索，“壮侗语族”681,000结果，“壮侗语系”仅19,100结果。同样是常用性有压倒性差异，同样是有官方机构采用“语族”，为什么对壮侗语和闽语的条目命名不同呢？--自由雨日（留言） 2024年6月11日 (二) 03:43 (UTC)[回复]
这两个条目的情况并不完全相同，“壮侗语系”这一条目名也并非一定合适或一定不合适。在下已在下方的讨论中阐释了支持“闽东语”作条目名的理据，如果您确实认为“壮侗语系”条目名不妥，可以另行讨论。--CuSO4 · 龙年大吉 2024年6月11日 (二) 08:12 (UTC)[回复]
「閩東片」、「閩東語」乃是觀點上的差異，而非地區詞。--Ghren🐦🕑 2024年6月10日 (一) 06:50 (UTC)[回复]
在下不是认为这两个词应视作地区词，而是为路西法人君的观点提供一些参考。在下自己认为应当维持现有“闽东语”标题，并在下方的讨论中阐释了理据。--CuSO4 · 龙年大吉 2024年6月11日 (二) 08:08 (UTC)[回复]
「閩東片」這種具有官方修正性質定義的才是應當把「閩東語」移動到「閩東片」條目中去、如果其他地區無此共識才是直接使用語言轉換變成「閩東語」。--桜花雪󠄁 2024年6月11日 (二) 11:52 (UTC)[回复]
「閩東片」這種具有官方修正性質定義的才是應當把「閩東語」移動到「閩東片」條目中去、如果其他地區無此共識才是直接使用語言轉換變成「閩東語」。--桜花雪󠄁 2024年6月11日 (二) 11:50 (UTC)[回复]

即使“可以把闽东方言称为‘闽东片’”是没有争议的，这也不代表“不可以把闽东方言称为‘闽东语’”是没有争议的。将条目名定为“闽东语”，并不需要对“闽东片”这一名称的学术性反对意见，只需要对“闽东语”这一名称的足够支持理据即可。

樱花雪君对WP:COMMONNAME的理解亦让人难以苟同。樱花雪君认为“闽东片”才是“目前学术能搜得到”的名称，说得就好像“闽东语”不属于“目前学术能搜得到”的名称一样。分别谷歌学术搜索2012年以来使用“闽东语”“闽东片”的文章，会发现前者结果数目显著高于后者。这一事实与樱花雪君的言论给人造成的印象是相反的。如果考虑到学术界之外的日常使用，那么就像魔琴君展示的那样，“闽东语”有着几个数量级的压倒性优势。

此外，樱花雪君还提出了一种惊人的观点：樱花雪君认为，如果将标题定为“闽东语”，就不应引用新版《中国语言地图集》作参考资料。这种想法完全没有道理。认为条目应当使用与新版《中国语言地图集》所用称呼不同的标题，不等于认为新版《中国语言地图集》不应用作条目的来源。即使新版《中国语言地图集》是最高的权威著作，在维基百科条目中我们也可以选择性地接受其中的观点，而非要么完全接受要么完全拒绝。总之，由于WP:COMMONNAME，此条目的标题应当维持为“闽东语”。--CuSO4 · 龙年大吉 2024年6月5日 (三) 13:16 (UTC)[回复]

閣下對我認為的想法是純屬子虛烏有。首先、我沒有說過「目前學術能搜得到」這個說法、而且我的完整說法是目前學術能搜得到並且是有官方認可的劃分。閣下把我官方後面一句的說法給我斷章取義掉可真有意思。
那既然已經有官方背書的『中國語言地圖集』（2012年第二版）情況下的2012年當初在閩語分支歷史上為何不新增該文獻？還在引用一個20年前的歷史文件？是沒有人更新？還是閩語區的維基人「刻意隱去」？本人不好說。
還有、如果說不是刻意隱去那為什麼粵語和吳語均採用了『中國語言地圖集』（2012年第二版）的文獻資料呢？而閩語就沒人去新添這一重要的文獻資料呢？--桜花雪󠄁 2024年6月5日 (三) 15:01 (UTC)[回复]
中国社会科学院语言研究所不是中国大陆的语言主管机构。教育部发的稿件2016年还在引用黄廖版《现代汉语》的七区说（19年改引12地图集）。这里也没人说不要新增该文献，只是说标题命名仍然按“语”。首段可以这样写：
被ISO 639注册为独立语言这点不知道如何插进去，看看有没人有想法。
侯官小片可以这样写：
至于所谓“刻意隐去”，只是没人更新罢了，晋语、官话都没提到12班地图集，平话连地图集都没说，甚至在{{汉语}}中还归到粤语下面。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月15日 (六) 13:23 (UTC)[回复]
“被ISO 639视为一种语言”这件事依在下之见不用写，信息框里有ISO 639-3代码足够了。“注册为独立语言”这种说法略显不妥，可能使人误以为“ISO 639认为闽东语是单独的一种语言，不属于汉语”。--CuSO4 · 龙年大吉 2024年6月15日 (六) 16:54 (UTC)[回复]
　既然按台灣官方的話、明體在台灣的正式官方機構叫做宋體、但是在維基百科上的說明為何標題又是標以明體？本人認可明體在台灣民眾傳播度的情況、但明體只能作為又稱不能作為標題。所以、如果要改的話、也是把閩東語一詞轉移到閩東片去、然後在使用字體轉換到台灣的時候、直接把閩東片轉成閩東語即可。而且如果還要再論接管語言的話、也就只有閩東片和閩南片是接管的、其他閩語方言如：莆仙片・閩北片・閩中片・邵將片・瓊文片・雷州片不受中華民國管理、那這些就應該改成片。而且關於不互通的還有一個例子、吳語：
既然吳語也是內部不互通的情況、那又為何分成片？為何也不是把各個地方叫做語？--桜花雪󠄁 2024年6月15日 (六) 23:40 (UTC)[回复]
宋体/明体字词转换了啊。闽东语和闽东片一个是语言（方言）名称一个是分类地位，感觉不适用字词转换。

方言的名目有专名部分和通名部分之别。比方说，“吴语区、吴语、苏州话”，“区”字是指分布范围的通名部分，“语”字和“话”字是指方言的通名部分，……

——1987地图集A2
如果用1987地图集的话说就是，一个是方言的通名，一个是分布范围的通名。我也不知道为什么吴语不分为五个区，大概是习惯使然吧，搜了一下似乎没有相关论述。另外小片以下好像没有词了？（点应该指的是某一处而不是划分范围。）陈波《海南方言的分区》（1986）把琼文方言从区分到小片，改用琼文片的学者分到小片好像就不再分了。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月16日 (日) 02:32 (UTC)[回复]
小片下面就是話了啊。如：閩語-閩東片-侯官小片-福州話・閩語-閩東片-福寧小片-霞浦話。而且闽东片和闽东语兩個都是相同的分類、就只是名稱不同。而且如果要這麼「語-語」分的話、那其他地方的語言應該也要劃分成：粵語-粵海語・吳語-上湖語。而且宋体/明体字词转换了、那為何不按照人家的官方的說法來？上面所謂的「閩東語」又引用台灣官方、這個宋体/明体就又不引用官方的了、什麼雙標和選擇性失明？——桜花雪󠄁 2024年6月16日 (日) 03:17 (UTC)[回复]
@桜花雪：之前有些地方没说清楚，我重新解释一下吧：
一、无论是在学术界还是在民间，“闽东语”都比“闽东片”常用得多，因此条目名应根据“使用常用名称”这条命名原则选用前者。
二、《中国语言地图集》采用“闽东片”，不影响第一条的成立。
三、高吸水性聚合物的命名、宋体的字词转换、粤语和吴语采用的文献资料，都与闽方言条目命名无关。--CuSO4 · 龙年大吉 2024年6月22日 (六) 19:11 (UTC)[回复]
就像“白罗斯”一样，闽东片什么时候获得中文学术界的广泛认同，我就支持将闽东语移动至闽东片。另外我奉劝桜君：不要看到别人对你的“正名化”想法提出异议就玩“转移话题”的那一套（如引入蒋中正人名争议，最近阁下已经在数个讨论区这么干了）。--向史公哲曰（留言） 2024年6月26日 (三) 07:29 (UTC)[回复]
那請問閣下你在結城明日奈討論的時候說的一句順便一提是在表達什麼？這不就是畫蛇添足的轉移話題？然後進行人身攻擊？這就是閣下作為維基用戶對其它維基用戶的基本素質？既然你能發表你所謂的個人看法和意見、難道我不能發表個人看法？雙標是吧？閣下是在反駁金字塔裡的倒三層是嗎？就不能好好說話？自從編輯福建人條目一開始、你之前和本人的發言態度問題也當作WP:假定善意處理了。但現在看來再結合之前的言論態度、根本就不像是一個維基人該有的基本素質。而且每次閣下討論話題的時候總是想把本人往我有「正名化」想法上拐、這不是轉移話題是什麼？？？如果閣下再這樣得寸進尺那有必要進行一個提告了。至始至終、閣下對本人攻擊尤為強烈、其它維基用戶對於閣下的言論態度也都看在眼裡。--桜花雪󠄁 2024年6月26日 (三) 07:57 (UTC)[回复]
首先，在各类“正名化”讨论中，你都有转移话题的迹象。举个例子，在本话题中，你就将话题转移至“高吸水性聚合物的命名、宋体的字词转换、粤语和吴语采用的文献资料”，这可与本人的讨论无关。其次，你如果对我有意见，且想要提告的话，那你就应当去提告版控告，而不是在条目探讨处控告本人。另外你如果想要本人被封禁的话，我会推荐你联名其他维基人对本人进行控告，这样我本人被封禁的成功率会上升。最后，命名常规相关话题中本来就有“正名化”和“常名化”的矛盾，你的想法从客观上来看确实接近“正名化”立场，这有什么问题吗？--向史公哲曰（留言） 2024年6月26日 (三) 08:28 (UTC)[回复]
你的想法從客觀上來看確實接近「正名化」立場屬於是本人的無中生有・原創研究、本人在舊時南越與南越國的社群討論中、是誰更傾向於「正名化」立場？如果說本人有「正名化」立場、那如何解釋本人在該討論中的立場？？--桜花雪󠄁 2024年6月26日 (三) 09:07 (UTC)[回复]
而且這個是語言問題、不單單是人物的名字問題。閩語方言內部是要考慮互通性。現在之所以全部降級為了片、也正是因為現考究的閩語方言內部還有一部分的底層詞彙和使用文字還是具有一定的一致性。而且不互通的閩語方言只是白讀音、閩語裡本身就有文白異讀的現象。閩語方言內部不互通的是白讀音、閩語文讀音是互通的。不然不怎麼解釋閩劇為何能具有一定的傳播力和影響力？--桜花雪󠄁 2024年6月26日 (三) 09:27 (UTC)[回复]
首先、如果使用語的話、會造成分層混亂、會變成兩個是同級存在、如會出現：「閩語-閩東語」這種分層混亂的情況。其次、如果說民間使用情況的話、使用平話一詞的情況比使用閩東語一詞的情況會更多、那為何又不使用平話一詞？還有、如果內部使用「語」之級別、那說明在閩語方言中、不管是文讀音還是白讀音甚至是具有一致性的詞彙・文字和讀音上都是絕對的完全無法互通。（這也是早期學術界認為的觀點）但就上世紀自李如龍教授和陳章太教授發表的『論閩方言的一致性』研究論文結果來看、絕對的完全無法互通的說法完全不存在。故此這也更好的解釋了閩劇這個用閩語（福州話）文讀音為何能在福建・台灣・東南亞（其中台灣和東南亞的華人還是使用下南腔的下南儂主體族群）具有一定的傳播力和影響力呢？如果說閩語方言內真的完全是個隔離以「語」來分的話、那下南儂怎麼能聽的懂閩語（福州話）文讀音的閩劇呢？按民間樸素的認知來講閩東南北中莆仙邵將語都應該是絕對的完全隔離才對哇、因為都是完全不同的詞彙・讀音和文字才對哇。--桜花雪󠄁 2024年6月28日 (五) 03:21 (UTC)[回复]
「閩東語」是常用名稱吧？維基百科當然也應該記載學術名稱，但標題自可沿用常用名稱，這應該沒什麼問題纔是。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月27日 (四) 03:59 (UTC)[回复]
仍為此標題的話、會有明顯的主觀判斷認為閩語方言內部下的方言片不管是文讀音還是白讀音甚至是具有一致性的詞彙・文字和讀音上都是絕對的完全無法互通的歧義向。但就自李如龍教授和陳章太教授的發表論文『論閩方言的一致性』結果來看、絕對的完全無法互通的說法完全不存在。這就比如說：福州　閩語閩東片：Hók-ciŭ　閩語莆仙片：Ho̤h-ciu　閩語閩南片：Hok-chiu　閩語閩北片：Hŭ-ciú、在這種只是不同口音的情況下、雖然能聽出略有有差別、但是還是能聽出你在表達的是什麼詞的這個情況。故此在閩語方言中是有單個詞拿出來的情況下仍是有相同的互通一致性情況。--桜花雪󠄁 2024年6月27日 (四) 04:42 (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)[回复]
如果此處的祭如同戰祭、豐年祭，是指慶典或活動的話，可參見《教育部異體字字典》釋義五。[35]--夜月辰星（留言） 2024年6月14日 (五) 12:44 (UTC)[回复]
如果此處討論的是Category名的話，或許可以參照Category:日本鐵路公司，條目名使用特例的鐵道，而Category名則用慣例的鐵路。--夜月辰星（留言） 2024年6月14日 (五) 12:57 (UTC)[回复]
既然《教育部异体字字典》给出了这个义项，那么说明“祭”在汉语中确实可以表示“庆典活动”的意思，但我仍不认为可以用来作标题，理由有三：一、《异体字字典》没有给出词性说明，不过从例句（例词）为「雪祭」、「海洋祭」、「音樂祭」等来看，“祭”表示此义时可能只能用作词缀（例如“作者”“读者”的“者”字、“产业化”“绿化”的“化”字等），“冲绳县的祭”中“祭”直接作为成词语素，这可能是不合法的，至少很不符合语感；二、目前只有台湾的词典给出这种用法，可能不是所有汉语地区广泛的用法；三、即便在中国大陆等地区的词典中找到了这种用法，用“祭”来表示庆典活动在汉语中仍是不常见的，完全可以用更常见的方式来表达。--自由雨日（留言） 2024年6月14日 (五) 12:57 (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: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)[回复]

關於台灣閩南族群相關名稱爭議

本主題全部或部分段落文字，已移動至WikiProject talk:臺灣。执行人：Jimmy-bot（留言） 2024年7月6日 (六) 16:14 (UTC)。[回复]

水滸傳一百单八将獨立關注度

近日在Category:自2024年6月主題關注度不足的條目，水滸傳一百单八将陸續被掛板，數量很多。倒不如直接來討論，例如怎樣的來源才算具備獨立關注度。--Factrecordor（留言） 2024年6月25日 (二) 15:53 (UTC)[回复]

我随机点进去一个阮小二，来源挂零；再点进去一个丁得孙，来源挂零；再点进去一个鄧飛，来源挂零；再点进去一个戴宗，全是水浒传本身的来源。所以你的问题就是个前提错误的假命题：你抛出的这个问题预设这些条目有品质稍差的来源但是可能有人觉得不合标准，但是事实是这些条目要么没有来源要么全是一手原始来源。--MilkyDefer 2024年6月25日 (二) 16:42 (UTC)[回复]
這些條目一般都是有來源的，只是來源不合「虛構事物」規定而已。比如在《中国古典文学人物形象大辞典》中應該是一百零八個不落的，只是內容基本上不出虛構小說中的人物經歷而已。其他來源也大多如此。戴宗因為在《水滸》戲分較多，應有WP:虛構要求的來源。其他不好說。其實無論是當今ACG的虛構人物，還是古代的虛構人物都好，讀者更多關心的是人物設定而不是有什麼反響和評價。您維現在多少有點本末倒置的感覺。--Ghren🐦🕓 2024年6月25日 (二) 20:10 (UTC)[回复]
同上。Wikipedia:頁面存廢討論/記錄/2022/08/26#觔斗雲也是。--YFdyh000（留言） 2024年6月26日 (三) 04:41 (UTC)[回复]
再不濟也能全部重新導向至「一百單八將」，總之應該沒有刪除疑慮。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月3日 (三) 10:50 (UTC)[回复]

移动条目“郑燮”至“郑板桥”

本主題全部或部分段落文字，已移動至Talk:郑燮。执行人：Jimmy-bot（留言） 2024年7月6日 (六) 16:14 (UTC)。[回复]

提删所有【各地旅游】和【各地旅游景点】这两大类别的分类

我知道这里不是存废讨论，发到这里是有两个事情，一个是问一下如何操作如此庞大体量的提删，再一个毕竟涉及到这么多的分类，先来问一下社群的初步意见。

说一下我的依据，因为这两类分类没有清晰明确的分类标准，《分类:旅游景点》←点开这个分类看，这里面包含了公园、剧院、商场、地下街、墓地、宗教场所、温泉、体育场地等等各种稀奇古怪的东西，但如果要问这些是不是旅游景点？某种意义上确实可以是，属于是任何人说任何东西属于旅游（景点）都有道理，主观性过强，那这些分类就成了毫无意义的分类，也违反了非原创研究方针，据以上，我认为应该提删。--——— 红渡厨（留言・贡献） 2024年6月28日 (五) 15:32 (UTC)[回复]

旅游可以放旅游业等条目。墓地、廣場等广泛分类显然不宜放入旅游景点，温泉、度假村也牵强，有旅游评级的才可考虑，例如并非所有温泉都有旅游价值。體育場地更是奇怪，很多不是为旅游所准备。综上，应该清理分类内容。--YFdyh000（留言） 2024年6月29日 (六) 02:42 (UTC)[回复]
可能我没有说清楚，我想提删的是类似于“Category:河北旅游、分类:伦敦旅游景点”这种，不是“分类:旅游”。然后，即使是清理内容，也无法改变分类标准不明的问题，就算人为确定能够挂这些旅游分类的内容，日后一样会有不明情况的其他用户乱挂。--——— 红渡厨（留言・贡献） 2024年6月29日 (六) 04:19 (UTC)[回复]
可以要求仅放入页面名称与旅游直接相关的，存在广泛的广义的旅游属性不足以置入。河北旅游分类，放入文旅部门、规定、事件（宜有单独分类）等应是无问题。--YFdyh000（留言） 2024年6月29日 (六) 08:45 (UTC)[回复]
我不认为每个用户在加分类时都会遵守这样的“要求”。--——— 红渡厨（留言・贡献） 2024年6月29日 (六) 09:31 (UTC)[回复]
假设喜羊羊等条目被放在分类:羊，要么根本不该加入（取决于讨论），要么缺乏细分分类而被放在根分类，两者都不该删除分类羊。此案同理。旅游景点分类是否能放景点评级等内容，可以讨论，过度延伸的可能属于景点的项目可做清理。--YFdyh000（留言） 2024年6月29日 (六) 11:29 (UTC)[回复]
「旅遊景點」分類確實存在這樣的問題，可以廢除「旅遊景點」分類，視情形歸入「地理>地形」或「建築物」等適當分類。「旅遊」分類可保留，僅收納產業、制度等內容，而不直接收納個別地點條目。至於有「旅遊評級」的地點，將這些地點歸入相應的「旅遊評級」分類（如分類:国家5A级旅游景区），再將分類作為制度歸入「旅遊」分類即可，仍避免個別地點條目直接歸入「旅遊」分類。--紺野夢人 2024年6月29日 (六) 08:02 (UTC)[回复]
我想提删【各地旅游】分类就是因为很大程度上这个分类被当做【各地旅游景点】分类在使。如果真能确立一个分类的标准，又该如何要求每个用户在挂分类时都能遵守呢？--——— 红渡厨（留言・贡献） 2024年6月29日 (六) 10:29 (UTC)[回复]
旅遊業作為服務業的分支可以分類。有人將「各地旅遊」分類當「各地旅遊景點」分類的原因是在模仿「先例」，只要清除這些「先例」（即廢除「旅遊景點」分類，移除「旅遊」分類中的單一地點），就不會有人不明就裡地模仿。--紺野夢人 2024年6月29日 (六) 10:47 (UTC)[回复]
这个量是极大的，我不看好移除。--——— 红渡厨（留言・贡献） 2024年6月29日 (六) 10:49 (UTC)[回复]
同梦人的意见。删除分类是简单粗暴的移除，不考虑是否有合理保留的例子。--YFdyh000（留言） 2024年6月29日 (六) 11:22 (UTC)[回复]
讚同移除，因這沒有準確的定義。—Outlookxp（留言） 2024年6月29日 (六) 08:31 (UTC)[回复]
行政區條目可不能進入旅遊分類--ZXX4444 議 作 2024年7月1日 (一) 00:25 (UTC)[回复]

关于是否可以（应当）在国家类条目Infbox的Native参数中添加地方法定或通行语文名称的问题

本问题因维基百科:管理员布告板/编辑争议#向史公哲曰争议中社群未对是否可以（应当）在国家类条目Infbox的Native参数中添加地方法定或通行语文名称之问题存有共识故提出，有一位编者@向史公哲曰对目前部分国家条目添加地方行政区法定或通行语言的国家名称持有反对意见，由于涉及条目基本属于重要度较高乃至WP:高风险主题条目，故在互助客栈以求得社群提供共识。（相关反对性编辑可见，中华人民共和国条目：Special:Diff/83194079、Special:Diff/83194147、Special:Diff/83194165；英国条目：Special:Diff/83204412）

目前主要之争论可以被划定为：

  • 添加一国地方法定或通行语文的国名名称翻译是否涉及WP:OR？
  • 添加一国地方法定或通行语文的国名名称翻译，且具有常识关注度的情况下（即属于可供查证并可以被读者常识所理解且具有一定帮助度的），但在未明确纳入标准的情况下是否可以被考虑为建设性内容？
  • 添加一国地方法定或通行语文的国名名称是否应当设定纳入标准，还是只允许采纳官方第一语言国名？

（注：先前地方法定或通行语文的国名均放置在collapsible list模板内，即除非点开内容，初始状态为不显示，属于由读者自主点击阅读项）

目前主要涉及条目包括：中华人民共和国与英国。Sinet（讨论） 2024年6月28日 (五) 16:56 (UTC)[回复]

引述一下f阁下对其选择地方语言的标准之解读
正如我之前的回复所说，其实并没有一套正式的选取标准，只是基于常见度所加入的建设性内容，目前被删除的内容的语言我列一下给各位看看：
1. 汉语拼音：中国大陆目前使用的注音系统
2. 藏文：西藏自治区的官方语文
3. 壮文：广西壮族自治区的官方语文
4. 维吾尔文：新疆维吾尔自治区的官方语文
5. 满文：并无官方语文地位（可在争议解决后删除）
6. 蒙古文：内蒙古自治区的官方语文
7. 朝鲜文：延边朝鲜族自治州、长白朝鲜族自治县的官方语文
8. 哈萨克文：伊犁哈萨克自治州的官方语文
9. 彝文：凉山彝族自治州的通行语文
10. 英文及葡萄牙文：两个特别行政区的官方语文
大部分语言基本上属于地方的官方语文或通行语文，并且除满语外基本上覆盖了中国大陆官方认定少数民族中人口占比较多的少数民族语言（见中国民族列表），同时覆盖几乎所有民族区域自治制度下官方使用的少数民族语言。考虑到有人可能驳斥“官方语文”这一地位，中国大陆目前的“官方语言”认定法律或多或少有一定的模糊之处，不过可参照《s:中华人民共和国民族区域自治法》中有关语言的规定推定其官方地位

--向史公哲曰（留言） 2024年6月28日 (五) 17:01 (UTC)[回复]

重复一下我个人的(－)反对意见:依据阁下的观点，美国应该增添夏威夷语的国名（夏威夷语是夏威夷州的官方语言）、20多种阿拉斯加土著语言的国名（阿拉斯加的官方语言有多种土著语）、萨摩亚语的国名（美属萨摩亚的官方语言）、西班牙语的国名（波多黎各的官方语言和新墨西哥州的特殊法定语言）、苏语的国名（南达科他州的官方语言）、查莫罗语的国名（关岛和北马里亚纳群岛的官方语言）、加罗林语的国名（北马里亚纳群岛的官方语言）……然而事实上，所有语言的维基百科都没有编辑这么做，更何况美国这些地方语言都是有地方法定地位的。啊对了，英国条目的其他语言也应该移除了，根据英维条目的内容显示，英国的官方国名仅用英文书写。纵观整个维基百科，将地方语言国名列入的条目几乎没多少，且有几个都集中于中维。--向史公哲曰（留言） 2024年6月28日 (五) 17:08 (UTC)[回复]
个人想法是：一国的官方语言、事实上的官方语言、该国境内使用程度非常广的语言（比如10%人口为母语者）都可以列入。其他语言不是很建议，因为选取标准很难界定。--微肿头龙（留言） 2024年6月29日 (六) 00:10 (UTC)[回复]
在prc，汉族占总人口的91%，所以说依据阁下的想法只能放汉语了。--向史公哲曰（留言） 2024年6月29日 (六) 02:02 (UTC)[回复]
10%只是我随意定的一个标准，可以调整的。--微肿头龙（留言） 2024年6月29日 (六) 04:31 (UTC)[回复]
那么该如何界定这门语言在该国境内的使用程度非常广呢？--向史公哲曰（留言） 2024年6月29日 (六) 04:55 (UTC)[回复]
当然，美国的西班牙语母语者估计占比超过10%，且美国的西班牙语是波多黎各的官方语言和新墨西哥州的特殊法定语言（地位类似于壮语之于广西），然而所有维基百科的条目都没有在美国条目中罗列西班牙语国名。--向史公哲曰（留言） 2024年6月29日 (六) 02:12 (UTC)[回复]
这种情况下，我的建议是参照其他语言维基百科的处理方针。例如英国条目的地方语言国名是否摆放，取决于英语维基百科的处理情况，誠如英文維基所說。至于prc条目，我们也可以广泛参考各大语言维基百科的处理经验，决定是否删削内容。--向史公哲曰（留言） 2024年6月29日 (六) 02:25 (UTC)[回复]
先不说prc条目，就英国条目而言，我并不认为支持"罗列地方语言国名"的维基人能比英语维基百科的维基人更懂"英国国名应当列举什么语言"这一议题。--向史公哲曰（留言） 2024年6月29日 (六) 02:29 (UTC)[回复]
另外，哪怕是百度百科的prc词条，也没有列举地方语言国名，而在所有语言的网络百科全书中，几乎只有中文维基百科的prc条目喜欢列举地方语言国名，这是为什么呢？这又是基于什么共识呢？--向史公哲曰（留言） 2024年6月29日 (六) 02:32 (UTC)[回复]
乌克兰几乎一半的国民都以俄语为母语，那么是否应该在乌克兰条目下罗列俄语国名？--向史公哲曰（留言） 2024年6月29日 (六) 02:56 (UTC)[回复]
就我个人认为，有必要。毕竟俄语是乌克兰的第二常见语言。--微肿头龙（留言） 2024年6月30日 (日) 06:04 (UTC)[回复]
全國層面官方語言的國名應添加，一國個別政區官方語言的國名不必添加。--紺野夢人 2024年6月29日 (六) 07:31 (UTC)[回复]
若沒有正式語言之國家（政權），均沒有必要予以添加。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月30日 (日) 05:04 (UTC)[回复]

希望有文辞流畅的网友可以帮助将一些関於中华人民共和国建立後成立的短期政权之条目進行中立化

対於中华人民共和国成立後建立的一些短期政权的相関条目（如大顺国、大汉中华国），大多直接引用中华人民共和国官方之说法，语句文辞很不中立…如充满“骨干”等詞汇。 然而不才文辞粗陋、対这些歴史也并不了解，恐怕修改错误、败坏文风，希望有文筆流畅、熟悉歴史上各国暴动、建国等条目之書写规范的朋友能够协助将这些条目中立化。

中国共产党同样以暴动起家，不才認为，完全可以参照共産党暴动之条目（如中華苏维埃共和国），借鉴其語言、行文方式，対这些中华人民共和国建立後的短期政权予以中立化。--2408:8435:320:9F3E:C17B:58AF:2B22:157B（留言） 2024年6月29日 (六) 06:46 (UTC)[回复]

不才文辞粗陋，難堪大任；
願有文辞流畅之编辑人，
可借鉴叙述辛亥革命时期、及中国共産党之暴动的条目，并广采列国暴动条目之文辞，対这些中华人民共和国成立後的政权予以中立化。--109.176.254.144（留言） 2024年6月29日 (六) 06:57 (UTC)[回复]
需要额外的可靠来源。来源是骨干，直接改掉反而不中立。“骨干成员10多人被”可以改动语序，体现出是审判之定义。--YFdyh000（留言） 2024年6月29日 (六) 08:50 (UTC)[回复]
嗯嗯，確実在只有一方面材料的情況下，中立化要困難一些……--Asteriphosa-Braag（留言） 2024年6月29日 (六) 11:33 (UTC)[回复]
也希望可以幫助一起修改大漢中華國、大順國等條目，之前嘗試修改，然而由於文筆鄙陋…總感覺自己改完的條目很不通暢……
大漢中華國（如大多數的「解放軍」三字均被擴展為「中國人民解放軍」、「區政府」前加「中華人民共和國」等…）--Asteriphosa-Braag（留言） 2024年6月29日 (六) 11:39 (UTC)[回复]
用詞可能有些不合適（回復又不好改…），還望見諒--Asteriphosa-Braag（留言） 2024年6月29日 (六) 11:40 (UTC)[回复]
中华人民共和国区政府 很怪异，当时也未建国。解放军有内链可能不需全名，或者以知名度来说不内链不全名。称中共临汝县人民政府如何？--YFdyh000（留言） 2024年6月29日 (六) 11:52 (UTC)[回复]
谢谢啦…另外，请教县独立团応該怎麽改……修改前的原文本来只是「县独立团」，之前改成了「中华人民共和国县独立团」…现在感觉同样不太合适…但如果单稱县独立团的话，㸔起來好像有些只承認单方面之武装的感觉……
不过，或许可以试着按照上下文补充县名，然後改为「中共XX县獨立团」--Asteriphosa-Braag（留言） 2024年6月29日 (六) 12:01 (UTC)[回复]
「或授权」为衍文，可能是打错字、可能是繁简转换导致的……--Asteriphosa-Braag（留言） 2024年6月29日 (六) 12:03 (UTC)[回复]
我觉得有上下文，不说是中共领导的……，也可以。--YFdyh000（留言） 2024年6月29日 (六) 12:04 (UTC)[回复]
联络会道门（首领）与联络会道门信徒（信众）是不一样的，可能会曲解来源？试图 可能无需，过于第三方视角，口号未必落实，试图相比宣称、谋求等也许更进一步。宣传改成宣称？部分地主 等修改，是否曲解了原始来源。暴动暴乱的区别，得考虑一下，或者冠来源。俘获听着有点温和？为什么枪决加了个杀死。--YFdyh000（留言） 2024年6月29日 (六) 12:02 (UTC)[回复]
嗯嗯，试着重做了一些修改…
枪决加殺死这一段，是为了和上文中共方面十人被殺相对应（修改前原文是被害），确実㸔起來語義有些重复…--Asteriphosa-Braag（留言） 2024年6月29日 (六) 12:18 (UTC)[回复]
「道徒」一詞是否有贬義，「道徒」和「信眾」含義是否一致…？如果一致，会尝试将「道徒」改为「信众」。--Asteriphosa-Braag（留言） 2024年6月29日 (六) 12:46 (UTC)[回复]
中華民国曾発布《統一對朱毛共匪及有關名稱要點》，其中稱呼中国共产党的「黨政軍頭目」为「朱毛匪首」，称呼中共「一般份子」为「朱毛匪徒」……讓人怀疑「道首」「道徒」这些词汇是否也與之類似，是中华人民共和国対这些短期政权人员的矮化稱谓…？--Asteriphosa-Braag（留言） 2024年6月29日 (六) 13:40 (UTC)[回复]
宣稱：我是太陽，日光菩薩，明年日出，太陽出頭就是我出頭。後年龍年，龍要翻身就是我要翻身。再過兩年，我即成道。那時萬國來朝，改國號「大順」，年號為「佛化元年」。（大顺国条目）
——上文中，引用语句和正文语句混淆不清…「宣称：」後本应添加引号，然而改国號、年号一段又類似正文，不知怎样修改比较好--Asteriphosa-Braag（留言） 2024年6月29日 (六) 12:58 (UTC)[回复]
双引号内改用单引号--YFdyh000（留言） 2024年6月29日 (六) 16:50 (UTC)[回复]
您其實得首先確保字體編碼吧.混雜字形,亦有委奴字見於漢語,恐爲天下笑..--ZXX4444 議 作 2024年7月1日 (一) 00:21 (UTC)[回复]
只是在一般情況的用字中使用日式新字體，在編輯條目的时候是使用简體的。
——不过白很親日这件事…不涉及條目编辑，大概沒有必要继続解釈……而很討厌反日这件事同样沒有必要説出來……这些都不涉及條目編輯，如果白想要将條目更改㝵更親日反而违反维基百科的規則……如果是白自己的䍏站，就会盡量完全使用白式字體（包括日式新字體，但有修改），且偏親日，但是編輯㒶共䍏站的时候会使用简體字。--Asteriphosa-Braag（留言） 2024年7月2日 (二) 05:09 (UTC)[回复]
到底想怎樣改。首先這些組織能算上「政權」嗎？我都不知道這些政權和「人民、領土、政府、主權」哪一項沾邊。學術上根本沒有什麼所謂的「秘密結社政權」。其次，本來「WP:中立的觀點」用的就是「可靠來源中發表過的重要觀點」，如果確實只有中國那方面的來源，其實基本上只可以這樣寫。那些來源本來就這樣糟糕，有些事實明顯就已經有政治色彩了，比如「大汉中华国」中說「在中國國民黨特務及地主的組織下」這句看來是不是事實都難說。看來就是中共萬事不決怪特務、地主的說法而已。將「特務」改成「特工」，感情色彩就算可能顯得較為中立一些（我沒有這個語感），但是如果事實本身就不準確，有什麼用。--Ghren🐦🕚 2024年6月30日 (日) 03:45 (UTC)[回复]
可以注明“……指其”。特务特工我感觉差异不小，特工像专门任务的人员，以前用特工一词吗。而且特务本就是中性词。--YFdyh000（留言） 2024年6月30日 (日) 16:05 (UTC)[回复]
这些政权就当是个滑稽看吧。本身来源就很少，地方县志，或者《帝梦惊华》那本奇书，地方县志当然以官方立场写，而《帝梦惊华》也只不过是以猎奇心态介绍罢了。很难做到真正中立的写法了。要介绍这些历史长河中一瞬即灭的政权，就只有这么多资料可供参考，这就决定了上限。--超级核潜艇（留言） 2024年7月2日 (二) 03:07 (UTC)[回复]
至少…把一些有厳重倾向色彩的詞語改掉叭……目前改过的几個條目已经㸔起來好多了。--Asteriphosa-Braag（留言） 2024年7月2日 (二) 05:19 (UTC)[回复]
是的，或許他们的组织远远没有达到建立政权的程度，还只祘是反抗武装。
不过，改掉一些厳重不中立、倾向性的内容是很有意義的。㒶共内容応該讓每個人自己思丂和評価歴史事件，而不是预先将强烈的立场強加給読者。
（「㒶」字即「公」字，「丂」字即「考」字）--Asteriphosa-Braag（留言） 2024年7月2日 (二) 05:38 (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)[回复]
据我所知是没有，比如中国高等植物数据库全库记载的榉树，“国外分布”一栏只写着朝鲜和日本，而其他参考文献是明确有写它分布在韩国的（[36]），我也因此认为其他相关的以中国高等植物数据库全库为参考的植物条目中的“朝鲜”，应该指的是朝鲜地区/半岛，而不是朝鲜民主主义人民共和国。就算确实指后者，写朝鲜地区/半岛也没错，且不会出现歧义的问题。----FradonStar|八闽风云 2024年7月3日 (三) 04:15 (UTC)[回复]
我觉得下结论可能原创研究。如无额外来源证明，我宁可取消内部链接。扩大范围恐怕是曲解来源。
按使用帮助文档最后一页，国外分布可能写中南半岛、马来半岛。但是，没有写成朝鲜半岛。
数据集来源是中国植物志。[37]榉树的介绍，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)[回复]

屠殺事件列表之屠殺一詞

巡查到紐西蘭屠殺事件列表，發現該用詞「屠殺」描述列表內容不當（遑論大屠殺），應是從英文頁面的Massacre直翻，搜索了一下發現類似的頁面有中國大屠殺列表、烏克蘭大屠殺列表、朝鮮屠殺事件列表（惟其內容與標題對應無不妥）。不知這幾個標題應該如何處理較好？慘案？多人殺害事件？ 可參考先前類似的討論。--Rice King 信箱 · 留名．邊緣人 2024年7月1日 (一) 04:52 (UTC)[回复]

杀戮事件？血案？维基数据里是屠杀。收录标准是否明确。--YFdyh000（留言） 2024年7月1日 (一) 05:11 (UTC)[回复]
屠就是殺，或者比殺略多皮開肉綻之意，有何不當？有「大」關乎規模，無「大」無關數量。--— Gohan 2024年7月1日 (一) 06:47 (UTC)[回复]
“屠就是杀，或者比杀略多皮开肉绽之意”，典型的原创研究，词语是你自己可以拆字解释的？《国语辞典》“屠杀”释为“残杀”（看错了，但不完全是错解，见下），《现代汉语词典》《新华词典》释为“大批残杀”，《现代汉语学习词典》释为“大批杀戮”。显然“屠杀”和“杀”不同，也跟什么皮开肉绽无关。--自由雨日（留言） 2024年7月1日 (一) 07:58 (UTC)[回复]
閣下給出的《國語辤典》連結（https://dict.revised.moe.edu.tw/dictView.jsp?ID=54128&q=1&word=%E5%B1%A0%E6%AE%BA） ：屠殺 釋義 屠宰、殺戮；相似詞 殘殺。您看錯行了？何出「《国语辞典》“屠杀”释为“残杀”」此言？無論是循環釋義的單字、還是組詞的釋義，「屠就是殺，或者比殺略多皮開肉綻之意」並非不合理。其他詞典望您提供來源；如與《國語辤典》有不同，只有三條路可走：一，符合任何一種釋義的「屠殺」皆可在維基百科使用；二，由於釋義分歧，爲免歧義，「屠殺」從此在維基百科消失、禁止使用；三，符合所有詞典釋義的「屠殺」才能稱作屠殺，這就可能排除活埋、槍殺等不至「分裂」、皮開肉綻之事。--— Gohan 2024年7月1日 (一) 08:15 (UTC)[回复]
《国语辞典》解释确实是我看错了，在此向您道歉。不过“残杀”本就是列在“相似词”里，继续搜索“屠宰、杀戮”后含义其实也不会差太多；而且类似“屠就是杀，或者比杀略多皮开肉绽之意”的自行拆字释义本就是原创研究，“窗户”的“户”意为“门”，按您的拆字逻辑，难道“窗户”在中维就应该被理解成“‘窗’和‘门’”的意思？另外，其他词典我的行文显然已经是给出了来源，有谁规定过“提供来源”必须要同时提供访问途径？它们没有公开链接，难道要我扫描提供盗版书籍PDF才算是“提供来源”？再补充一个来源，《辞海》中“屠杀”释义仍为“大批残杀”。--自由雨日（留言） 2024年7月1日 (一) 08:34 (UTC)[回复]
您既已查證且對此有提問，謹回答：拍攝正版書籍一兩句解釋是合理使用，毫不侵權。
對於通常循環解釋的詞典，拆字理解是習慣做法，否則且看會有如何結果：
  • 屠殺：屠宰、殺戮；
  • 屠宰：宰殺牲畜；
  • 殺戮：屠殺、殺害；
  • 殺害：以不正當理由而將人殺死；
  • 宰殺：屠殺、屠宰。
「屠殺」依然與數量無關。對於牲畜而非人，仍然不知「屠殺」／「屠宰」／「宰殺」何意，三者循環解釋；對於任何文字工作者，拆字都很自然。「屠」當然不是「屠殺」，但為言簡意賅，才以一句解釋點明主旨。附錄：《玉篇．尸部》：「屠，殺也。」《說文》：「屠，刳也。」《六書故．疑》：「屠，刳剝畜牲也。」《周禮．地官司徒．廛人》：「凡屠者，斂其皮角筋骨，入于玉府。」--— Gohan 2024年7月3日 (三) 02:13 (UTC)[回复]
附录部分，你先把现代汉语和古代汉语搞清楚再说吧。《国语辞典》部分，既然它没有明确解释，那么参考其他现代汉语中文词典才是最自然的；当然也可以认为台湾的这一词和中国大陆等地含义不同，这种情况也不少见，但绝非是你拆字解释逻辑下的原创研究。建议学习一下现代汉语合成词（两个或以上语素）的构词逻辑。--自由雨日（留言） 2024年7月3日 (三) 06:03 (UTC)[回复]
我倾向存在多种词义解释，屠杀是有条理的杀戮，人数只是体现方式之一。分尸未必屠杀（比如为了抛尸），割喉也存在意外，而毒气可以是屠杀。维基数据和系列条目可约定约束所用词义和标准。--YFdyh000（留言） 2024年7月1日 (一) 16:03 (UTC)[回复]

另外也可參閱en:List of massacres in Taiwan，我相信大家就更懂這裡的massacre為何翻譯成屠殺並不妥。--Rice King 信箱 · 留名．邊緣人 2024年7月1日 (一) 15:59 (UTC)[回复]

满族姓名

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

Coddlebean以“满人不称姓”大量删除了条目中满族人物的姓氏，搜索了一下不同人物情况应该不同。比如爱新觉罗·启骧，有大量直接用长名“爱新觉罗·启骧”，而不是简单只用其名，举例[38]、[39]、[40]、[41]、[42]，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)[回复]

Lumo的中文名是光明出行吗？

本主題全部或部分段落文字，已移動至Talk:Lumo (鐵路公司)。执行人：路西法人 2024年7月3日 (三) 02:12 (UTC)。[回复]

永恆艾莉絲工坊公司主體變更

本主題或以下段落文字，在討論結束後應存檔至Talk:永恆艾莉絲工坊。

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

問題在條目無人回應，加入「回饋請求系統」，24小時後也沒有加入到對應列表，所以我只能依照老方法，在這裡再發一次，尋求意見。相關條目是永恆艾莉絲工坊。

根據商工登記公示資料查詢服務，新公司應該是「沃兎奈股份有限公司」，原「永恆艾莉絲工坊有限公司」目前還沒撤銷。沃兎奈註冊地址和永恆艾莉絲工坊不同，是 臺中市西屯區惠來里惠中路二段78號。看了最近幾個月的活動，「永恆艾莉絲工坊」還繼續代理發行新遊戲。舊地址應該不再用了，infobox和分類應該怎麼處理這種變動？--Nostalgiacn（留言） 2024年7月3日 (三) 05:24 (UTC)[回复]

RFC模板放的位置不對，我已經調整過了。臺灣杉在此發言 (會客室) 2024年7月3日 (三) 05:37 (UTC)[回复]
我感覺去電子遊戲專題問，說不定還較有用。當然來客棧發文還是最有效的辦法。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月3日 (三) 07:45 (UTC)[回复]
儘管條目是一家遊戲公司，但這不算電子遊戲的問題，而是涉及公司分類和歸屬的問題。--Nostalgiacn（留言） 2024年7月3日 (三) 10:05 (UTC)[回复]
不過仍然可以在專題提出，重點是招人來。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月3日 (三) 10:47 (UTC)[回复]

請至Talk:永恆艾莉絲工坊繼續討論。--路西法人 2024年7月3日 (三) 10:09 (UTC)[回复]

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

中华人民共和国

现今中华人民共和国是不是可以说大多数情况下通称“中国”？请基于事实论述，而不是自己的政治立场。如果一个地方自称是改名，其他人也如此称呼，“通称”不是很正常？--Kethyga（留言） 2024年7月7日 (日) 08:36 (UTC)[回复]

其他

沒有主題的頁面如何評級

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

已解決：
因Wikipedia:通用評級已通過，故沒有主題的頁面已可透過通用評級來進行評級，故此問題已解決-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月5日 (二) 09:31 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

像是包、比 (消歧義)、值 (消歧義)這種，內容並不屬於任何專題管轄的頁面，要如何評級？有沒有辦法「無專題評級」？不然在統計工具上面，這些未評級的頁面都無法正常顯示頁面種類。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 08:59 (UTC)[回复]

主题更多是用来评判重要度而非写作水准的吧，或许可以考虑一个通用评级，比如实际上并不应该被划到单一专题内的消歧义页。——暁月凛奈 (留言) 2023年12月7日 (四) 09:34 (UTC)[回复]
(？)疑問@暁月凛奈：比方說創建一個專用的、通用的評級模板，無專題，不使用{{WPBannerMeta}}元模板，內部只塞「本頁面獲評XX級」和Special:页面评级的解析器語法，然後沒有別的說明？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 09:48 (UTC)[回复]
我基本没有参与评级相关，我不太明白为什么条目质量一定要和专题挂钩。举个例子的话，页面李的六个链接五个是姓氏，一个是植物，被划到生物还是人文都显然不合适，而且消歧义页本来也不算做条目。或许也可以设计成，“本页面尚未划分到具体专题，欢迎协助标记”，然后消歧义页等页面用参数取消这一句。——暁月凛奈 (留言) 2023年12月7日 (四) 11:51 (UTC)[回复]
{{WikiProject Article assessment}}可托管没有专题支援的条目--洛普利寧 2023年12月7日 (四) 11:58 (UTC)[回复]
(：)回應PJ:條目質量評級「這個維基專題已經廢棄。」。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 12:18 (UTC)[回复]
幾乎所有專題都是廢棄的，只是這個專題明面上寫了而已；稍微好一點的是只有一個人參加的「個人專題」，不過這種專題基本上也是三分鐘熱度。如果你只是為了評級，那就不用管專題是否活躍，直接把{{WikiProject Article assessment}}往討論頁上貼就可以。以中維的實力來說，條目沒有專題評級才應該是正常的，有評級的反而屬於異端--洛普利寧 2023年12月7日 (四) 12:41 (UTC)[回复]
模板、分類、甚至是檔案也是需要評級的項目，算上去真的跟異端沒兩樣。而掛上專題模板呈現的未評級狀態能算評級嗎。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:03 (UTC)[回复]
(：)回應：@Milkypine：WP:評級：「約有38萬條目」，中文維基百科條目數也才100萬啊。哪有「異端」？我還異端兒勒。另WP:評級#統計，所有掛有評級模板條目討論頁有562,943頁，未填寫評級的「未評級狀態」之條目討論頁有182,858頁，562,943 − 182,858 = 380,085。所以被評級的「條目」是38萬無誤，100萬分之38萬 = 38%。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 14:33 (UTC)[回复]
@A2569875：先定義何謂異端，如果數字多就不算異端，那麼日本和中國市場可以除名異端狀態了。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:54 (UTC)[回复]
更不用38%是數字少的一方，對中維其餘62%條目來講，這38%就是異端。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:59 (UTC)[回复]
{{WikiProject Disambiguation}}，这个？--Kethyga（留言） 2023年12月7日 (四) 12:47 (UTC)[回复]
這個連專題主頁都不存在 囧rz……-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月7日 (四) 13:02 (UTC)[回复]
这个模板没有评级参数，而且doc页写明不要仅为放置该模板而新建讨论页。--Kcx36（留言） 2023年12月8日 (五) 03:38 (UTC)[回复]
僅供參考: enwiki之前也有相關討論，現在已由{{WPBS}}自動為這類型非條目賦予NA-、Redirect-級別的評級與重要度。請參見w:wn:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24。中文或許如Category:非条目级条目?--Kanashimi（留言） 2024年1月10日 (三) 06:05 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

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

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

@A2569875，附知。--MilkyDefer 2023年12月8日 (五) 09:03 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

第一階段：修改WikiProject banner shell

已修改：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
工程量挺大，就看誰願意改了。（幾年前可能我有興趣，現在我就精神上支持了）--洛普利寧 2023年12月8日 (五) 14:53 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

第二階段：修改WPBannerMeta

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

@Willy1018：提到了一個很有意義的問題。如果上方的變更套用了的話，只有「表面上」給了頁面通用評級，而實際上的通用評級在各個專題中並沒有達成「繼承評級」的效果。這是因為評級模板預設不會知道他外面包著{{WikiProject banner shell}}模板，因此，如果要讓每個評級模板都能讀到通用評級，需要再一個編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月24日 (日) 05:15 (UTC)[回复]

預計的修改方案以及其佈署連結（記得填寫討論通過的diff和客棧PermaLink版本號）。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月3日 (三) 05:00 (UTC)[回复]

本主題或以下段落文字移动自Template_talk:WPBannerMeta#編輯請求_2024-01-08（固定鏈接），新留言请置于框外。执行人：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 13:21 (UTC)[回复]

相關議案

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

想諮詢一下@Kanashimi君相關修改是否有問題？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月8日 (一) 05:53 (UTC)[回复]
@Ericliu1912、Kanashimi：這主要是依據共識，讓專題橫幅能繼承{{PJBS}}輸入的評級值。我已經在{{多面體專題}}、{{電子遊戲專題}}測試過了，沒有問題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 06:00 (UTC)[回复]
User:A2569875的努力有目共睹。只不過我原先料想的是直接改w:en:Module:WikiProject banner及w:en:Module:Banner shell，而宇帆-娜娜奇看起來很辛苦的重構了代碼，並且有些參數不太一樣，這樣我就不太好評論了。--Kanashimi（留言） 2024年1月8日 (一) 06:12 (UTC)[回复]
@Kanashimi：考慮到日後長期維護需求，我傾向請您以英文版本為基礎來更新相關模板。是否能夠確認有什麼模板需要更新（或在互助客棧列出之類）？不過在此過渡期間，若技術上沒有問題，是可以斟酌先批准既有之編輯請求。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月8日 (一) 12:18 (UTC)[回复]
這兩個（Template_talk:WPBannerMeta#編輯請求_2024-01-08、Template_talk:WPBannerMeta/core#編輯請求_2023-12-28）屬於案《Random Thought: 跟进英维的WikiProject_banner_shell改版》可以先進行；剩下的屬於另一案（Module_talk:Class/data#編輯請求_2023-12-28、Template_talk:Class_mask#編輯請求_2024-01-05、Template_talk:Class_mask/core#編輯請求_2023-12-25、Template_talk:Class/colour#編輯請求_2024-01-05）屬於案《同步各模板/块的評級值》目前正在公示，所以暫時還不用。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 14:59 (UTC)[回复]
@Ericliu1912：要改哪些模板我在客棧上其實都有列，主要在案《沒有主題的頁面如何評級》和案《評級系統缺失問題》的子章節裡。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 15:03 (UTC)[回复]
（不用一直提及我，我有在看）—— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月8日 (一) 15:11 (UTC)[回复]
@Ericliu1912、Kanashimi：另外參見此發言，User:Willy1018已覆核效果符合預期，認為修改沒有問題。測試也都充分了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 06:31 (UTC)[回复]
@Ericliu1912：另外如果要接受編輯請求的話，也把Template_talk:WPBannerMeta/core#編輯請求_2023-12-28也接受吧，兩者是互相配套的（{{WPBannerMeta}}與{{WPBannerMeta/core}}高度相依）。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 06:33 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

第三階段：完善制度

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

在Template_talk:WPBannerMeta#編輯請求_2024-01-08中有人認為需要給通用評級訂一個「能填寫甚麼級別」的標準來避免爭議，因此立了草案Wikipedia:通用評級如下：

  1. 若一條目沒有專題或不受任何專題管轄，則其通用評級可填寫任意有被{{WikiProject banner shell}}支援的級別，僅要該條目有達到該級別的標準或滿足該級別的條件，都可以評。
  2. 若一條目僅有一個專題，其通用評級應與該專題所評的等級一致。
  3. 若一條目有多個專題，通常由機器人自動依照規則4進行評級，但一旦出現爭議時則通用評級應以所有專題都有開設的級別為主。
    • 例如：若一條目有四個專題，而有一個專題沒有開設「丙級列表級」，那麼通用評級就不得填寫「丙級列表級」
  4. 對於有多個專題的條目，通用評級應填寫最多專題評的那一等級。
    • 例如有一個條目有四個專題，其中三個專題都評為乙級，但有一個專題評為丙級，則通用評級應填寫乙級。
  5. 若在規則4的情況牴觸規則3，則應填寫與對應級別最接近的且滿足規則3的級別。
    • 例如有一個條目有四個專題，其中三個專題都評為「丙級列表級」，但有一個專題評為「列表級」且這個專題不開設「丙級列表級」。依據規則3，最多專題評的級別是「丙級列表級」，但有一個專題不開設「丙級列表級」，則通用評級應填寫與「丙級列表級」最接近且位於該條目所有專題都有開設的級別，也就是「列表級」。
    • 「最接近的級別」應該向下填寫，例如未啟用乙級的專題，通用級別遇到規則3判為乙級的情況時，則向下填寫為丙級。如果丙級也有專題未開設，就再向下填寫為初級。如遇到無法評級的情況，該通用評級模板就該留空。

提議將之升為指引，不曉得各位覺得如何？@Ma3r、Kanashimi、Z7504、桐生ここ：@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 09:44 (UTC)[回复]

實作上是否能讓那些沒開設大宗評級（數量最多專題）的在專題橫幅內設定好參數即可？這樣看起來就不會因為沒開設評級、被覆蓋而出問題。機器人很難判別每個專題開設的評級，因此條件3會讓讓機器人無法自動作業。
僅供參考，就enwiki來說，純粹只考慮數量最多的評級。採用特殊評級的專題橫幅有特殊分類，機器人處理時不會動到其評級。--Kanashimi（留言） 2024年1月14日 (日) 10:35 (UTC)[回复]
@Kanashimi：技術上不能讀取評級模板的|QUALITY_SCALE=內容和/class子頁面嗎？如果|QUALITY_SCALE=填subpage，讀取/class子頁面就能得知該專題哪些評級有啟用。例如{{多面體專題}}是|QUALITY_SCALE=subpage，所以讀取Template:多面體專題/class原始碼即可得到哪些級別是yes、哪些級別是no。如果|QUALITY_SCALE=填extended則是定義於{{Class mask/extended}}的級別。未填或standard就是只使用大宗評級。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 11:00 (UTC)[回复]
如果改成「若一條目有多個專題，通常由機器人自動依照規則4進行評級，但一旦出現爭議時則通用評級應以所有專題都有開設的級別為主。」機器人會不會好辦一點？意為機器人填寫值優先，但如果是人工評級時，才須考慮是否所有專題都有開設，且是遇到爭議之時，這是為了解決「但是如果有人說「根據Wikipedia:條目質量評級標準#非標準級別和一些專題評CL的慣例，這篇列表內容充分，儘管支援條目的專題都沒有設CL級別，但既然WPBS能評CL那我就評CL」呢？所以，這個評級的定位該怎麽看？您作出了如此複雜的功能，但如果因爲使用規則不完善而部署而引發爭議，相信這是您不願意見到的。」所描述的爭議情境。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 11:06 (UTC)[回复]
@A2569875 現在cewbot採用的方式是選出最大宗的評級（數量最多的評級），填入{{WPBS}}並且移除所有相同的評級。所有不同的評級都保留不動。不曉得這樣的作業方式是否會產生問題？--Kanashimi（留言） 2024年1月14日 (日) 11:16 (UTC)[回复]
@Kanashimi：上面的情境說的是人為評級時可能出現的爭議；如果是機器人評級，我相信應該沒什麼爭議。所以應該不會有問題。該規則僅為了處理人為評級發生的爭議，理應不影響機器人運作。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 11:20 (UTC)[回复]
既然如此那我作為機器人操作者沒有什麼意見。當{{WPBS}}已經指定class，機器人不會動到{{WPBS}}的class。--Kanashimi（留言） 2024年1月14日 (日) 11:28 (UTC)[回复]
我在疗养，您自己请便。由于这个事情的业务逻辑挺复杂的，我不会拦着你用什么样的Lua。--MilkyDefer 2024年1月14日 (日) 12:48 (UTC)[回复]

公示已逾七日，公示期已過，期內無合理異議，因此提案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月29日 (一) 03:28 (UTC)[回复]

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

臨時動議：關於基礎條目的額外提議

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

已通過：
基礎條目併入{{WPBS}}已經通過；{{WikiProject Biography}}參數還在討論中。先行佈署已通過的《將{{Vital article}}併入{{WPBS}}的|vital=參數》案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
  • 似乎已有共識，跟隨enwiki改版之後會由機器人自動完成：對各種專題橫幅不再個別指定 class，而是統一置於{{WPBS}}。
  • 跟隨enwiki改版之後會由機器人自動完成：將{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數皆改以{{WPBS}}處理，
  • 跟隨enwiki改版之後會由機器人自動完成：將{{Vital article}}併入{{WPBS}}

這邊最近在幫忙enwiki自動化這過程。這邊將申請自動更新Wikipedia:基礎條目所有子頁面的圖示（這部分最近測試中，已趨穩定。），以及定期維護{{WPBS}}（將各種專題橫幅併入{{WPBS}}並維護 'class', 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'等相關參數）。不知大家對此是否有建議？ --Kanashimi（留言） 2024年1月2日 (二) 09:53 (UTC)[回复]

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

引入enwiki近期{{WPBS}}之改版，暨將{{Vital article}}併入{{WPBS}}

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

這邊最近在幫忙enwiki自動化這過程，並且將定期維護。想請教大家對上幾種改變的贊否。

另這邊將申請自動更新Wikipedia:基礎條目的圖示（這部分最近測試中，已趨穩定。），以及維護{{WPBS}}（將各種專題橫幅併入{{WPBS}}）。不知大家對此是否有建議？

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

其實個人早已注意到相關更新，只是苦於自身技術實力不足而未能協助，樂見在充分確保相容性的情況下跟進。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月2日 (二) 06:21 (UTC)[回复]
(＋)支持全部。--Ma3r（铁塔） 2024年1月2日 (二) 06:25 (UTC)[回复]
是的，enwiki採w:en:Category:WikiProjects using a non-standard quality scale表示自訂評級的專題，bot亦已考慮此問題，在User:Cewbot/log/20200122/configuration有此項。待zhwiki完成部署，填好User:Cewbot/log/20200122/configuration便可apply。--Kanashimi（留言） 2024年1月3日 (三) 07:08 (UTC)[回复]
  • 整理一下目前共識：
    • {{PJBS}}設立通用評級，可以統一管理同一條目的所有專題評級（已公示通過）
    • 確保最大相容性的前提下跟進英文維基的相關功能
    • 專題橫幅看各專題意願，評級可以選擇統一放置於{{PJBS}}也可以自行輸入
    • 未輸入評級的專題橫幅以繼承載於{{PJBS}}的評級值為主，會優先採用載於{{PJBS}}的評級值
    • 如頁面能自動判斷評級則無論輸入什麼評級，都要以自動判斷的評級為優先（原始來自這則留言，後續有在上方簡單討論）；另有設置參數能複寫此設定。
    • 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'已併入{{PJBS}}，但是否廢除{{WikiProject Biography}}內的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'還有待討論
    • {{WPBS}}已經加入{{Vital article}}的所有參數，但是否要用{{WPBS}}取代{{Vital article}}還有待討論
以上-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 18:08 (UTC)[回复]

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

我的建议方案是，|vital=参数可以存在，但是只有UI作用，由一个外部的机器人进行监察和更新操作。--MilkyDefer 2024年1月14日 (日) 12:55 (UTC)[回复]
若能簡單改enwiki的程式碼來用，或許不必擔心折騰的問題。另一方面假如只留UI功能的話，是否乾脆維持原來的{{Vital article}}就好?--Kanashimi（留言） 2024年1月14日 (日) 13:06 (UTC)[回复]
Module:Vital_articles都已經分成類似雜湊表查詢了，有甚麼折騰的問題？已經高效率優化了好嗎。理論上，此實現的記憶體開銷甚至有望低於英文維基，因為英文維基只分成27個表，而中文維基是36個表，代表中文維基每個表的項目數量更少，在類似散列函數計算之後，要讀取的JSON更小，表示記憶體用量更少，單個表項目更少表示查詢更快。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月14日 (日) 13:12 (UTC)[回复]
基礎條目模板合併案公示

見公示聲明。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月24日 (三) 03:38 (UTC)[回复]
  • 還真的沒有，那應該誤會了。那這BOTTOM TEXT參數到底是從哪裡來的？該廢除的參數還是應該盡早廢除。基本上只剩下一個(？)疑問：是不是還要寫{{WPBS|class=xxx}}才能讓其強制正常顯示？--Z7504非常建議必要時多關注評選（留言） 2024年1月22日 (一) 06:05 (UTC)[回复]
  • 總之全部都是Module:PJBSClass/main的問題，不鑲嵌模板就無法判斷，但「條目內掛了模板所以可以判斷」，您如果那麼清楚的話，那就直接建模板阿。標準的自欺欺人，結果居然是沒動腦過的回覆，被潑冷水真的剛好而已。這樣如何保證裡面可以不用寫上比如|class=xxx的參數，變成{{WPBS|collapsed=yes||class=xxx還能讓它正常顯示？--Z7504非常建議必要時多關注評選（留言） 2024年1月22日 (一) 23:21 (UTC)[回复]
    • 不需要保證，因為機器人會自動填寫{{WPBS|collapsed=yes||class=xxx，保證的話等於和機器人搶工作，與本案背道而馳，因為該設計就是要給機器人維護的空間，如果沒有正面回答此陳述將視為無效。沒填寫|class=顯示不一樣，反而還有能分辨機器人是否填過的功能，豈不是更好？ 另，(！)抗议沒考量讀者體驗就亂講的提案，評級是面向編者的資訊，(－)強烈反对把評級寫在條目裡，故我認為目前的方案已是最適合的方案； 另，在此警告，在此案討論|class=參數已離題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 01:24 (UTC)[回复]
@Z7504：我直接針對你最初的問題回答「是不是還要寫{{WPBS|class=xxx}}才能讓其強制正常顯示？」，是，所以需要手動填上。本案並不包含甲乙丙初級自動判斷，公示也不包含這個部分，若你希望有甲乙丙初級自動判斷請另提他案，因為不在本案處理範圍內。 此外，你也無須擔心「是不是還要寫{{WPBS|class=xxx}}才能讓其強制正常顯示？」問題，因為下方Kanashimi已經申請機器人了，您無需手動填寫，此意見可以結案了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 01:44 (UTC)[回复]
本公示不包含甲乙丙初級自動判斷，若三日後還在要求甲乙丙初級自動判斷將視為無效意見。若希望|class=沒輸入也能自動顯示甲乙丙初級請另外提案謝謝，不在本案有辦法處理的範圍內。「這點小bug麻煩也先改了吧，不然都還要強制輸入才能確保正常顯示，問題不大才對」本案是處理基礎條目自動化，而不包含class有沒有輸入的問題，因此不在此案處理範圍內，請另提他案，謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月23日 (二) 02:02 (UTC)[回复]

已提出機器人作業申請，歡迎提供建議，謝謝。 --Kanashimi（留言） 2024年1月23日 (二) 01:38 (UTC)[回复]

公示期已到，期內無合理異議，且公示期內的意見之意見提出者已妥協，因此提案公示通過，將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]

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

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

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

公示到期，期內無合理異議，提案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:40 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
是否廢除{{WikiProject Biography}}原生的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數

無共識：
沒有共識，擇日再議，結以待續。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月19日 (五) 06:32 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

待機器人User:Cewbot/log/20200122/configuration清理完所有{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數再開始討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:42 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入

本主題或以下段落文字，在討論結束後應存檔至Category talk:缺少listas变量的传记专题页面。

擱置：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
Category:缺少listas變量的傳記專題頁面方案二
已通過：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
{{Find page text}}引入成功。已為新方案建立Patch，Special:Diff/82875808，並且經過測試Special:Diff/82875855，測試為有效，能正確地實現本案《Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入》的預期效果。且由於其判定的方式，該參數得以保留，並且達到預期效果，因而解決了User:Shizhao所提出的問題。本聲明放置一周，若無異議，將進行下一個階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月1日 (六) 10:47 (UTC)[回复]
說實話根本看不懂相關提案，也不知道從何評價Orz —— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月3日 (一) 02:32 (UTC)[回复]
因為這案子基本已經尾聲很久了，且最後一個項目也公示通過了，只是後來發生了點事情導致本案《Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入》需要「公示通過後再變更」。@Ericliu1912：簡單來講，本案就是要解決#臨時動議：關於基礎條目的額外提議，Kanashimi的User:Cewbot已經把{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數合併到{{WPBS}}處理，在機器人處理了幾十萬頁面後，發現這樣會造成{{WikiProject Biography}}和{{WPBS}}重複加上分類、或者是{{WikiProject Biography}}的有關參數已被機器人改到{{WPBS}}去了，{{WikiProject Biography}}變成沒有參數而導致分類誤加。為了解決此問題，於是誕生了議案《Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入》一案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月7日 (五) 23:38 (UTC)[回复]
還是看不懂，但我覺得這種技術小眾議題，又沒什麼大爭議，公示個三天就夠了吧？此案已經在客棧積壓太久了。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月8日 (六) 17:00 (UTC)[回复]
從此聲明發出至今已約9天，期內沒有明顯異議，加上原案其實已公示通過，且自變更案開始討論至今已超過一個月，視為有共識。不過公示方面還是謹慎點吧。三天真的太少。不過如上描述加上Ericliu1912的陳述，本案爭議不大屬實，就取3天和7天的中間數吧，公示5天。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月10日 (一) 00:41 (UTC)[回复]

編輯請求已由Shizhao完成，全案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月26日 (三) 13:16 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
@A2569875：這整個話題是否還有任何需要討論之事項？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:01 (UTC)[回复]

評級系統缺失問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

提案已通過請求佈署

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

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

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

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

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

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

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

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

分類改名準備

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

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

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

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

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

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

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

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

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

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

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

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

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

隨意的分段

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

D級與B+級等標準討論

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

  • D级目前看来只有宇帆君活跃的多面體在用，其条目是介于C和Start之间。讲真，流行文化领域，因为关注粉丝向这种扣分内容，D级还是很好用的。
    • 比如明星条目，内容上已经有C级该有的内容，但因为很多内容都以粉丝介绍口吻出现，需要大量清理和改写；这时评Start太可惜，就可以评D级。这基本就像多面体专题说的，「内容上可能达到C级水准，但其他方面有严重缺陷」。或者说，写条目的人擅长事实性内容，但不了解这里的格式手册，写出的东西很随意不像百科。
    • 另一方面，虚构作品条目也强调要写反响等现实世界内容。一般来说，编者不写现实世界内容，就表示他不熟悉格式手册，所以条目格式、行文等方面也不会太好。这种条目又要清理又要扩充，就可以给Start。但也有从英维FA翻译一半的，条目序言完整、作品介绍也很规范，但该到制作历史和评价，他又他不翻译了。这种只用扩充不用清理的，也可以从Start抬升为D。
    • 可以看到，流行文化领域这个D级主要还是可以彰显「内容杂乱/格式差」。但科学等领域大概没有「粉丝内容」，所以这个D级通常会怎么用？
    • 另外有了D，是不是未来有可能对等增加DL？
  • B+只有英维数学专题有用过，而且现在删了；本地没有专题实装过，只在一些理论研究中提到，所以还是要想想标准怎么订。
    • 之前B+的评级标准是「条目高于B级标准」，再把B级标准抄了一遍，这就比较不良定义。GA和B的区别主要在GA还要求中立性稳定性，且文笔和格式的要求高于B。如果要搞B+，那标准大概就是「不要求中立性和稳定性，但其他方面同GA标准」？PS：B6提到的WP:JARGON和地区词在GA标准里没有体现，所以B在某些方面还高于GA；不过现在的英维已经把JARGON要求增补到GA标准里了。
    • 之前有提过增设优良列表（GL）。GL和FL的主要区别可以理解为GL不管红（绿）链，且序言不用太优美；这个境界就有点像B+和GA了。不过，FL和GL应该是要有本质差异的——类似WP:GVF的comperhensive和board coverage。例如对于游戏系列，FA应该像死忠那样列出小众改编作品，而GA可以只列出重要作品。（但是很多领域列表是不是没有这种问题？）
  • 小小作品更像是一个临时状态，和未评级一样是不该长期存在的。而且小小作品只是长度短，问题还没有广告、侵权等小作品更严重，所以整体统计上把小小作品拆出来的意义是？从维护追踪角度考虑，WP:PETSCAN或者Shizhao的专题机器人通告应该都很好用了。--For Each element In group Next（留言） 2024年3月26日 (二) 15:50 (UTC)[回复]
  • （有感而發）除了本子節開始的爭議外，以上討論與研究其實都滿有意義和價值的，如果能提前在去年十二月，也就是我當初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
  • 為所有標準類別補上例子。

後續討論

关于 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 这里去看看。（注意测试版软件，你的用户最后很可能被删掉！）

附带一个教学视频 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)[回复]

繁体支援

这个网站估计主要的受众是大陆梯子人士。但是，由于很多管理员是繁体使用者，那么我就增加了一系列的繁体支援，但是都是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)[回复]

工单的永久删除

目前没有这个功能。不过，根据欧盟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)[回复]
      • 我想过geoip定位这个方案，但是ip定位数据库需要每个月更新，而且并不完全准确。连维基媒体基金会都放弃了自己的geoip API（否则我就可以利用了）。有一个折衷办法，那就是查询封禁数据库。如果用户目前的IP不再封禁列表中，大概率说明没有开代理，此时我弹窗提示开代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)[回复]

設立法輪功為高風險主題

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

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

設立原因及原方案請見Wikipedia talk:高風險主題#設立新興宗教為高風險主題。
法輪功頁面自2005年起，已經被反反覆覆保護超過40次以上；討論頁也無倖免、打辯論的經典副本。
範圍：
Template:法輪功、Category:法輪功
具體措施：

--Benho7599 | Talk 2024年5月26日 (日) 02:10 (UTC)[回复]

(＋)强烈支持，并建议将回退零容忍扩张至李洪志等关联条目。就最近讨论来看参与各方难以形成共识，导致编辑战频发。—Aggie Dewadipper 2024年5月26日 (日) 17:12 (UTC)[回复]
李洪志實際上似乎也十分需要0RR--Benho7599 | Talk 2024年5月28日 (二) 15:27 (UTC)[回复]
(＋)支持。从讨论页上连篇累牍的争执可以看出，法轮功是风险最高的政治相关主题之一。--CuSO4 · 龙年大吉 2024年5月26日 (日) 19:52 (UTC)[回复]
(＋)傾向支持WP:1RR 代替WP:0RR -Lemonaka 2024年5月27日 (一) 06:50 (UTC)[回复]
Skeptical toward whether 1RR would work. The current issue is that participating editors do not seek for consensus at all.--Aggie Dewadipper 2024年5月28日 (二) 05:20 (UTC)[回复]
不反對。Sanmosa 人人皆王 2024年5月28日 (二) 11:50 (UTC)[回复]
(＋)支持--August0422 2024年5月29日 (三) 03:57 (UTC)[回复]
第一條任何條目都適用，不用寫出來。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年5月29日 (三) 04:51 (UTC)[回复]
需要先確定具體範圍有多大，法輪功相關條目可不少。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月29日 (三) 17:29 (UTC)[回复]
我暫時想到的範圍是法輪功、法輪功的成員、法輪功的聯繫組織、與法輪功關係高度密切的人與組織。Sanmosa 人人皆王 2024年5月29日 (三) 23:39 (UTC)[回复]
分類：法輪功？--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年5月30日 (四) 13:40 (UTC)[回复]
@Cmsth11126a02、Ericliu1912：範圍暫定是Template:法輪功、Category:法輪功--Benho7599 | Talk 2024年5月31日 (五) 10:21 (UTC)[回复]
还要加上其他直接涉及对法轮功评价的条目（比如目前在EWIP吵的中国大陆宗教相关内容）。——Aggie Dewadipper 2024年5月31日 (五) 17:13 (UTC)[回复]
(＋)支持，(＆)建議可以先在互助客栈相关版面发起更具讨论度的共识讨论，以解决最近的编辑争议（如维基百科:管理员布告板/编辑争议#Marvin 2009）并为该例争议确立共识标准以及为未来可能的讨论页内争议（鉴于基本上并非寻求共识的情况）建立某种程度上从互助客栈引入共识的参考解决方案。Sinet（讨论） 2024年5月30日 (四) 22:48 (UTC)[回复]

已通过，建立Wikipedia:高風險主題/法輪功。-Mys_721tx（留言） 2024年6月3日 (一) 03:00 (UTC)[回复]

注：根据WP:CTOP注释一根据雪球法则一周结案。-Mys_721tx（留言） 2024年6月3日 (一) 03:22 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

（註：依據方針原則上應至少討論14天，但被提前關閉。6月3日後，後面有多位用戶仍在下面討論，還請先保留討論串。）--此條留言未正確簽名。

(！)意見+(？)疑問-(1)沒有注意到有這裡有此討論，沒有掛在「法輪功」條目頁通知。早上，在下在「法輪功」條目討論頁回應交流時，突然看到條目被半保護等。討論留言僅到5月31日，近期參與條目討論的用戶似乎並不知道、未能參與，是否應該在相關條目、例如主要條目上有個通知。(2)在下對於設立高風險主題的問題，認為需要更多的討論為宜。Wetrace歡迎參與WP人權專題 2024年6月3日 (一) 03:36 (UTC)[回复]
(？)疑問--共識並未達成。程序不符合方針規範，討論區8天剛過就遭關閉，但方針要求「維持開放最少兩週」。
  1. 依據WP:高風險主題---任何延伸確認用戶可在互助客棧其他板發起及參與指定高風險主題及相關編輯限制的討論。提案人必須論證主題之風險，並建議合適的編輯限制措施。討論發起一日內應於公告欄張貼通知。討論一般維持開放最少二週，若社群取得共識[a]即可由管理員結案，通過者並應創建主題子頁面（例如「維基百科:高風險主題/<主題>」）。
  2. 這次討論僅進行8天，違反「討論一般維持開放『最少二週』」的規範。
    1. Benho7599從5月26日UTC時間2點左右在互助客棧張貼，最後一筆留言在5月31日，管理員Mys 721tx在6月3日UTC時間3點左右關閉，討論只進行「剛滿8天」就遭到關閉、稱達成共識。在下Wetrace在法輪功條目討論頁留言後不久，就看到管理員Mys 721tx關閉討論，並列為「高風險主題」。----在下於6月3日UTC時間3點多，在互助客棧留言表示，認為需要更多的討論為宜、近期參與條目討論的用戶不知道、是否應該條目討論頁通知有此討論。
    2. 「討論發起一日內應於公告欄張貼通知」，請問是否有放在「公告欄」？「公告欄」是指哪裡？是否能有效的讓常參與的相關參與用戶知曉，表達意見？----討論包含發起人，僅7人（更正，10人）留言。
    3. 管理員Mys 721tx稱「根据雪球法则一周结案」，雪球法則不是方針、不是指引。尤其在只有7人（更正，10人）在5/26-31留言，許多人恐怕並未知曉來表達意見。
  3. 【後面有 重新整理這部分，這裡就畫線、不用重複看。】發起理由、範圍、方式都值得商榷。試舉幾例
    1. 發起人理由稱，2005年以來「法輪功」條目頁面保護40次----這是「19年」的時間，而且也要看看保護的原因。
    2. 涉及條目範圍恐怕過大，將「分類：法輪功」都納入，是不是都需要呢？由於涉及範圍大，條目的風險，論證是否足夠？依據方針，「提案人必須『論證』主題之風險，並建議合適的編輯限制措施。」
    3. 發起討論人的理由寫到「設立原因及原方案請見Wikipedia talk:高風險主題#設立新興宗教為高風險主題」。點入後裡面提到「不熟悉方針的新手／IP用戶可能會根據自己的立場加入不符合編輯方針的內容」---這其實可以先透過「半保護」就可大幅改善處理。
    4. 且例如，要求對條目0RR，也會大幅影響WP:修改、回退、討論循環的合理進行。留言中也有用戶提出不同意見。
  4. 此前，用戶違反3RR、人身攻擊屢屢違反文明方針，在下列出明確證據舉報後，管理員並未處理。從落實現有方針來改善，也是重要的作法。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 00:11 (UTC)[回复]
  • 討論一般維持開放最少二週，若社群取得共識[a]即可由管理員結案。
    • [a]：若討論發起七日後已有大量用戶參與且非常明顯近乎完全一致則可考慮提早結案。
可以看到上述讨论完全一致支持，适用雪球法则，而且一般来说在客栈讨论已经非常醒目，无需使用RFC、FRS或在其他讨论页通知。--桐生ここ★[讨论] 2024年6月4日 (二) 00:22 (UTC)[回复]
(－)反对-「討論一般維持開放最少二週，若社群取得共識[a]即可由管理員結案。」從方針來看，「開放至少兩週」+「若社群取得共識」，兩者皆為要件。方針中也並未規範「雪球法則」，這會不會架空了方針？管理員8天即關閉討論、並且在條目頁面半保護，引起在下注意到，發現原來正在進行此討論，在下隨即來此討論頁留言表達異議，認為需要更多時間討論、並是否應在條目討論頁採取方式讓參與編輯的用戶知悉、Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 00:33 (UTC)[回复]
你这个真的叫错误解读方针，和Gluo88那个不一样。--桐生ここ★[讨论] 2024年6月4日 (二) 00:56 (UTC)[回复]
Gluo88 是什麼事？在下不清楚。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 01:03 (UTC)[回复]
你看他日志。--桐生ここ★[讨论] 2024年6月4日 (二) 01:16 (UTC)[回复]
此外，按照以往案例，將在世人物傳記訂為高風險主題为4人支持，八九民主運動为6人支持，加密货币及区块链为6人支持，搜尋引擎優化與營銷为3人支持，因此支持人数按照以往案例来说并不低。--桐生ここ★[讨论] 2024年6月4日 (二) 00:38 (UTC)[回复]
桐生您好，該附款的要件是「七日後已有『大量用戶參與』且『非常明顯近乎完全一致』則可考慮提早結案」，而不是「支持人數」。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 12:53 (UTC)[回复]
(！)意見-桐生您好，這樣的支持人數，是不是很可能反映了這樣的討論，「公告」機制上的不足？方針要求「討論發起一日內應於『公告欄張貼通知』。」Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 00:46 (UTC)[回复]
2024年5月26日已经在公告栏通知。--桐生ここ★[讨论] 2024年6月4日 (二) 00:52 (UTC)[回复]
謝謝桐生貼出。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 13:07 (UTC)[回复]
(！)意見
  1. 方針要求「討論發起一日內應於『公告欄張貼通知』。」從方針要求「公告欄張貼通知」、討論「開放最少兩週」，顯示是讓社群有充分注意、討論。
  2. 方針寫到「討論一般維持開放最少二週，若社群取得共識[a]即可由管理員結案」。在[a]附註，「制定討論的共識不強求一致同意，但也不是點票。制定討論的共識需考量所有用戶提出的理據和觀點。若討論發起七日後已有大量用戶參與且非常明顯近乎完全一致則可考慮提早結案。」
    1. (1)將此重要訊息寫在 [a]附註，在公示效果上是否適當？在下高度保留，如果認為有此需要，應寫入本文。且使用上應相當謹慎。
    2. (2)a[附註]寫到「七日後已有大量用戶參與」---但是「七日後已有大量用戶參與」---加發起人僅7人留言（更正:含發起人10人-仍難屬「大量用戶」），屬於「大量用戶參與」嗎？這樣的認定，恐怕出現很大的恣意性空間，是否宜更審慎。 實際上大幅壓縮了方針「討論一般維持開放最少二週」。
    3. (3)當管理員到去對條目半保護等，在下發現此討論，就過來留言表達 需要更多時間討論。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 00:58 (UTC)[回复]
关于2(1)，方针既然已经这样写，说明管理员执行的没问题，即使写入了正文，也不会影响本次执行结果。--桐生ここ★[讨论] 2024年6月4日 (二) 01:05 (UTC)[回复]
(？)疑問--「討論一般維持開放最少二週」，[a]附註「七日後已有大量用戶參與」---加發起人僅7人留言（更正:10人-仍難屬「大量用戶」），屬於「大量用戶參與」嗎？這樣的認定，恐怕出現很大的恣意性空間，是否宜更審慎。否則，這樣的作法，實際上大幅壓縮了方針原則性的「討論一般維持開放最少二週」。---在下實在疑惑：既然鼓勵用戶「踴躍參與」表達意見，7人（更正:含發起人10人-仍難屬「大量用戶」）能算是維基社群的「大量用戶參與」嗎？Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 01:08 (UTC)[回复]
(！)意見-桐生您好， (1)7人討論（更正:含發起人10人-仍難屬「大量用戶」），很難說是「已有大量用戶參與」，因此「考慮提前結案」更應該審慎。在這樣情況下，應當遵循方針「討論一般維持開放最少二週」。何況，當管理員要提前結案，在下就來此表達不同意見，認為需要更多時間討論了。(2)即便在這7人的討論中，也對於內容、方法等有些意見，這些疑問還存在。討論應當持續進行。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 01:32 (UTC)[回复]
通过公示又推翻的又不是一次两次，@Wetrace所以您的看法是？ ——魔琴［留言 贡献］ 2024年6月4日 (二) 02:05 (UTC)[回复]
(！)意見-魔琴您好，如上表述的意見，在下以為，這一討論並未完成、參與者少、留言討論少、現有的留言也有分歧意見未獲充分討論，並不符合「已有大量用戶參與」的「考慮提前」關閉的情況。提前關閉並不合適，應依據方針開放至少14天的討論。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 02:16 (UTC)[回复]
我觉得提前结案没有问题，如果您反对提案或者有异议的话可以继续讨论，寻求达成新的共识 ——魔琴［留言 贡献］ 2024年6月4日 (二) 02:22 (UTC)[回复]
魔琴您好，在下以為，此一討論應該依據方針持續14天，不宜提前關閉。7人討論（更正:含發起人10人-仍難屬「大量用戶」），很難說是「已有大量用戶參與」，且也存在些具體不同意見。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 02:25 (UTC)[回复]
@Wetrace：我个人认为管理员的操作反映了共识。如果您认为现在不应该结案，那您具体的意见是什么呢？如果您也没有意见没必要再等吧？ ——魔琴［留言 贡献］ 2024年6月4日 (二) 09:31 (UTC)[回复]
(！)意見--魔琴您好，在下上面已經具體提出了一些具體疑問，例如範圍、作法、是否需要，等等。在下認為，應該至少討論14天Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 11:24 (UTC)[回复]
(！)意見--(1) 7人討論（更正:含發起人10人-仍難屬「大量用戶」），能算是「已有大量用戶參與」而提前關閉討論？在下以為，對於維基「高風險主題」方針的解讀、執行應嚴謹，不然，如果今天改一點、明天變一點，會不會似乎變相成了潛規則、被利用的漏洞？那麼，不僅對條目爭議不利，恐怕還可能增加了對新方針的誤導、糾偏的爭議或後遺症。(2)或許提案人本意想有助於解決問題，但解決問題，需要避免的情況是，會不會反而增加了問題複雜性。如果依據過去的主要方針不能解決問題，是執行方針的問題嗎？或者什麼？　如果需要 新設的「WP:高風險主題」方針，就一個議題設定為高風險主題，要形成共識，那麼方針規定「至少討論14天」，其實也意味可能需要更多討論時間，畢竟這不是局部小問題的探討，而可能是影響長久的，過程不宜粗糙的解讀操作，理應更多人參加較細緻的討論，不宜簡單過去。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 11:18 (UTC)[回复]
(！)意見-魔琴您好，與魔琴、發起人Hoben7599、參與的各位交流。對於本案，實質面，在下在上面列舉部分意見與疑慮，再整理如下，提供參考，感謝耐心閱讀：
  1. 此討論的，發起理由、範圍、方式，有些值得商榷處，試舉幾例提出交流
    1. 發起人理由稱，2005年以來「法輪功」條目頁面保護40次----這是「19年」的時間，而且也要看看保護的原因。
    2. 涉及條目範圍恐怕過大，將「分類：法輪功」中的條目都納入，相關條目，是不是都需要呢？涉及範圍大，條目的風險，論證是否足夠？依據方針，「提案人必須『論證』主題之風險，並建議『合適』的編輯限制措施。」
    3. 發起討論人的理由寫到「設立原因及原方案請見Wikipedia talk:高風險主題#設立新興宗教為高風險主題」。點入後裡面提到「不熟悉方針的新手／IP用戶可能會根據自己的立場加入不符合編輯方針的內容」---(1)這其實可以先透過「半保護」就可大幅改善處理。(2)發起人建議，對兩個條目的方案是「不限期半保護+0RR」，但是，0RR不得回退，會不會反過來 讓這些「不符合編輯方針的內容」不被回退，而限制了正常的編輯與反破壞？這會不會影響，很常見的WP:修改、回退、討論循環的合理進行。在前面的討論中，也有用戶提出對0RR的不同意見。是不是需要再商榷？
    4. 方案中，「『當有自動確認用戶參與爭議』時將條目提升至延伸確認保護」---「當有自動確認用戶參與爭議」---這要如何判斷？
    5. 發起人的方案，要求「恪守Wikipedia:中立的觀點、Wikipedia:文明、Wikipedia:可靠來源、Wikipedia:生者傳記」-----疑問：如果要方案，是不是該有相當關鍵核心的WP:可供查證？ 要有WP:不要人身攻擊？
  2. 此外，從落實現有方針來改善，也是重要的作法。此前，有用戶在相關條目上，違反3RR、人身攻擊屢屢違反文明方針，在下列出明確證據舉報後，不知為何管理員並未處理。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 12:06 (UTC)[回复]
(！)意見-查閱Wikipedia:高風險主題，各個討論期間，此前都在14天以上。
  1. 法輪功主題---討論期，2024年 5/26~6/3，8天。
  2. Wikipedia_talk:高風險主題/在世人物傳記--討論期 2023年8/30~9/13，約14天。
  3. Wikipedia_talk:高風險主題/臺灣海峽兩岸關係及政治地位---2023年8/30~9/18，約19天。
  4. Wikipedia_talk:高風險主題/加密货币及区块链--2023年 9/27~10/19，約22天
  5. Wikipedia_talk:高風險主題/反對逃犯條例修訂草案運動--2023年8/30~11/24，約25天。
  6. Wikipedia_talk:高風險主題/八九民主運動--2023年 11/7~12/19，約42天。
  7. Wikipedia_talk:高風險主題/医学--2023年10/9~11/22，約43-44天。
  8. Wikipedia_talk:高風險主題/搜尋引擎優化與營銷---2023年 8/31~10/27，約57天。
Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 12:44 (UTC)[回复]
其实你有意见可以直接提的，没必要搞一堆procedural comments然后浪费别人时间。剩下的我有精力的时候再说我想不想回你。--0xDeadbeef (留言) 2024年6月5日 (三) 14:15 (UTC)[回复]
0xDeadbeef您好，(1)在下有直接在上面提實質意見，例如其他用戶討論的0RR或1RR。(2)程序上、討論期間要審慎符合方針，是重要的，「高風險主題」的討論宜謹慎，開此例可能留下後遺症。Wetrace歡迎參與WP人權專題 2024年6月8日 (六) 01:07 (UTC)[回复]
WP:NOTBURO，如果没有对实际内容有反对意见的话，我看不出8天快速关闭有什么坏处。—-Aggie Dewadipper 2024年6月8日 (六) 03:02 (UTC)[回复]
看不懂他是打算支持還是反對？若只是程序性反對，那就等滿十四天，也沒啥不行的吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月6日 (四) 00:07 (UTC)[回复]
如果是程序性反对，我倒是还确实支持。--MilkyDefer 2024年6月6日 (四) 13:25 (UTC)[回复]
Ericliu MilkyDefer兩位好，程序上依據方針應討論至少14天，在過去也都如此；這次被縮短到8天，在下以為是很有疑慮的，「高風險主題」的討論宜謹慎，開此例可能留下後遺症。在下6/3即留言，認為需要更多討論，在下於前面也就實質議題也提出了一些疑問希望交流；部分議題是其他用戶在討論過程中也有提出的，但並未被釐清、進一步討論，就被關閉了。Wetrace歡迎參與WP人權專題 2024年6月7日 (五) 23:57 (UTC)[回复]
7天還是14天更多是程序議題，反而1RR還是0RR算是實質議題，故@Hoben7599、Dewadipper、CopperSulfate、Lemonaka、Sanmosa、August0422、Ericliu1912、Flyinet、John123521、Wetrace、桐生ここ、魔琴、0xDeadbeef、MilkyDefer：您們對法輪功或李洪志實施1RR還是0RR有何意見？--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年6月8日 (六) 08:15 (UTC)[回复]
不反對。John123521（留言-貢獻） 2024年6月8日 (六) 10:07 (UTC)[回复]
不反对，不过建议改1RR，0RR不应该长期使用。--桐生ここ★[讨论] 2024年6月8日 (六) 11:07 (UTC)[回复]
建議使用回退不過一--August0422 2024年6月8日 (六) 12:07 (UTC)[回复]
Inclined to WP:1RR instead of WP:0RR, which is too strict for such a topic. -Lemonaka 2024年6月8日 (六) 18:18 (UTC)[回复]
我觉得应该修改高风险主题相关方针，确立一个原则，就是0RR不能长期使用，就像IP不能永久封禁一样。--桐生ここ★[讨论] 2024年6月8日 (六) 23:42 (UTC)[回复]
已在方針區開啟有關討論。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年6月9日 (日) 08:37 (UTC)[回复]
1RR吧。--MilkyDefer 2024年6月9日 (日) 07:22 (UTC)[回复]
我个人建议暂时维持0RR，直到有关条目内容和编辑争议得到共识解决再改为1RR等。0RR并不限制反破坏（见WP:NOTEW），而是为了尽量避免编辑战。当前“法轮功”相关主题争议巨大，“回退战”反复发生（比如法轮功：撤销、手工回退），允许回退可能无助于解决争议。--Wnotieagusdr（留言） 2024年6月10日 (一) 01:22 (UTC)[回复]
暂时是暂时，不限期是不限期，上面反对的是不限期的0RR，而不是暂时的0RR。--桐生ここ★[讨论] 2024年6月10日 (一) 17:41 (UTC)[回复]
我感覺或許可以先為0RR設置一年的限期，要是一年後發現有限期的0RR並不足以處理相關情況，那就説明這並不屬於“一般情況”，因此有正當理由實行不限期的0RR。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 22:55 (UTC)[回复]
0RR反而可能衍生新的問題。如前所述，0RR不得回退，會不會反過來 讓這些「不符合編輯方針的內容」不被回退，而限制了正常的編輯與反破壞？這會不會影響，很常見的WP:修改、回退、討論循環的合理進行。Wetrace歡迎參與WP人權專題 2024年6月11日 (二) 23:51 (UTC)[回复]
0RR的重点是在回退前必须得到相关编者的共识（当然纯破坏用户/IP不算），目前来看非常有必要使用0RR：绝大多数法轮功相关条目的编辑都相当固执，执意说服别人而非寻求共识妥协，而显然维基百科不是游说的好地方，这些行为也鲜少有成功的，最终导致编辑战频繁。1RR是治标不治本的行为，只是把互相回退对方编辑的频率调低了，并不能减少编辑战。——Aggie Dewadipper 2024年6月12日 (三) 00:33 (UTC)[回复]
過去長期存在用戶添加 非第三方來源等問題。WP:修改、回退、討論循環。例如，發起討論人的理由寫到「設立原因及原方案請見Wikipedia talk:高風險主題#設立新興宗教為高風險主題」---點入後裡面提到「不熟悉方針的新手／IP用戶可能會根據自己的立場加入不符合編輯方針的內容」Wetrace歡迎參與WP人權專題 2024年6月12日 (三) 00:41 (UTC)[回复]
(＋)支持任何能防止法輪功相關編輯戰的措施，我看著這些條目被信徒寫成難以閱讀的模樣已經很多年了。我偏好最嚴格的無限期0RR，但也不反對其他任何較輕的手段，總之都好過現狀。--C9mVio9JRy（留言） 2024年6月11日 (二) 13:55 (UTC)[回复]
我寫CTOP方針時提供的限制措施是寫寂寞的啊？0RR的實際原理是要求編者儘可能先獲取共識再撤銷他人編輯，所謂「不讓回退不符合方針的內容」並不成立（獲取了共識就可以撤銷）。雖然0RR的編輯循環比較緩慢，但確保的是經過討論才撤銷他人編輯；方針也指明參照WP:NOTEW的條款，反破壞並不計入0RR之內，上方用戶所說「限制正常編輯與反破壞」均不成立。再說，如果覺得0RR嚴格，鑑於此主題的編輯戰的嚴重情況，改成0RR及1RR之間的「共識要求」不行嗎？硬是要雙方都回退對方編輯一次才開始討論？高風險主題的最高原則之一就是在該等條目遇編輯爭議應先行溝通而非回退戰解決，所謂「0RR太過嚴格」就反映了上面用戶着重於「要可以回退」而不是「先討論再行動」的戰鬥心態。--路西法人 2024年6月12日 (三) 03:54 (UTC)[回复]
倒不是「寫寂寞」，這不過是社羣並未對你當時設定出來的東西建立信心而已。Sanmosa Snipe–Clam Grapple 2024年6月12日 (三) 05:44 (UTC)[回复]
(！)意見-LuciferianThomas您好，謝謝您分享看法與初衷。在下提幾點切磋交換意見，思考看看，是否適合在個案？
  1. 關於共識的形成，維基百科，本來存在WP:修改、回退、討論循環的合理過程，這是一個極其常見、自然的運作過程。
  2. 您表述提到「0RR的實際原理是要求編者儘可能先獲取共識再撤銷他人編輯」。疑問，在維基百科上，新增內容、刪除既有內容呢？要不要獲取共識？（當發生編輯戰時，管理員經常會保護在 編輯戰發生之前的版本。）當被撤銷、或者修改，並且討論，就是尋求共識的一個過程，並非就是非善意，也不能說就是「編輯戰」了。
  3. 本案發起人提出的設定高風險理由，點入看，是「新手／IP用戶可能會根據自己的立場加入不符合編輯方針的內容」。在這裡0RR的作法，是否有助於達到那目的呢？會不會反向增加了用戶反破壞的負擔？
  4. 您說明「反破壞並不計入0RR之內」。不過，當另一方不認為是破壞，要怎麼斷定這一個RR是反破壞、不計入 0RR？這也說明0RR執行上的難度。在維基上現實情況，是不是破壞，也往往在吵；修改，是不是RR呢？原創研究內容、不符合維基要求的來源，被加入時呢？
以上幾點淺見思考，提出切磋。Wetrace歡迎參與WP人權專題 2024年6月13日 (四) 00:41 (UTC)[回复]
正常情況下，WP:BRD當然是非常理想的編輯生態。在高風險主題中，很多情況下連什麼是「合理符合方針」都無法清楚定義。除了非常明顯地不中立（完全傾向一邊，甚至包含攻擊特定群體的用詞）的情況適合直接回退（參考即將上路的新版破壞方針，目前公示中），用戶先行討論再撤銷是更好的做法。
在高風險主題編輯的用戶應學會忍。內容都存在問題這麼多年，顯然也不會因為編者回退了這一筆編輯就得到解決，糟的內容多放一天也沒分別。真的緊急的情況下，請求管理人員介入處理即可。
對於其他高風險主題而言，1RR仍能一定限度遏阻用戶開展回退戰。如這個議題這樣具爭議性的情況下，就算改施1RR，請問編者看到自己不同意的編輯回退對方編輯，對方基本上必然又用自己那一次「扣打」回退你的回退，你還是跟0RR一樣不能繼續回退，根本就沒有分別，反而是在討論開始前就產生了編輯戰和對對方的惡意。有些用戶提出「1RR能提供緩衝」，但這些議題下又有多少用戶是拿1RR來合理化自己的回退，大家心知肚明。既然0RR和1RR沒分別，編輯戰又如此嚴重，1RR也實際被當成quota對待，直接實施0RR是更加合理的。
此高風險議題除了要求用戶遵守0RR，也有數條方針是被社群要求嚴格遵守的，而管理員獲授權嚴格執行這些規則。目前社群的管理員多不帶特定立場，判別原創研究或不符合維基百科要求的內容也比較中性合理，與其編者自己回退，為何不提報交由社群公論後由管理員處理？如果管理員認為「不足以認定明顯違反規定而直接封鎖」，那不就代表這些編輯應先經討論再撤銷嗎？
上面說了一堆，必須說，比對0RR和1RR而言，我是覺得在此議題實施0RR更合適（限期的0RR也無法改變0RR的本質，限不限期幾乎是個偽議題）。我在引入高風險主題方針時，除了本地既有的回退限制外，也引入了「共識要求」的編輯限制，實際運作介乎0RR及1RR之間，這是BRD的加強版（BRD要求編輯被回退等候24小時，「共識要求」要等有共識）。如果社群有意願，可以改為實施這些編輯限制（我是認為這些實際要比nRR都好）。高風險主題是用來阻止編輯戰，鼓勵編者在編輯條目時以溝通為上；但如果編輯該主題的用戶還是抱着「先回退再討論」的觀念，那維持0RR不是壞事。--路西法人 2024年6月13日 (四) 06:14 (UTC)[回复]
另，CTOP本來設計的時候就有提早結束討論的條文，這裏所說的「大量用戶」雖然比較模糊，但可參照一般客棧每串討論參與的用戶數。以開啟七天的討論來說，約十名用戶參與討論已經算是「正常以上數量」，且可以明顯判斷出存在共識，那麼就能走完加速走流程開高風險主題，苗君的關閉符合我當時設計CTOP方針提供的加速選項條件。你就此提出的程序性反對與程序賦予管理員提早總結討論的設計不相容，不能當是正確合理的程序性反對。--路西法人 2024年6月13日 (四) 06:23 (UTC)[回复]
(！)意見- 您好，1RR、nRR，撤銷回退，需要適當理由。關於共識的形成，維基百科，本來存在WP:修改、回退、討論循環的合理過程。
  1. 手段 與 目的 應有合理有效的連結。高風險主題方針要求「提案人『必須論證』主題之風險，並建議合適的編輯限制措施。」------本案發起人提出的設定理由，點入看，例如是「新手／IP用戶可能會根據自己的立場加入不符合編輯方針的內容」。----但實施0RR 是抑制這問題？還是讓壓縮了處理這問題的空間？
  2. 0RR 與 1RR是有分別。部分的影響，前面已述。例如其中一點，您表述提到「0RR的實際原理是要求編者儘可能先獲取共識再撤銷他人編輯」。疑問，(1)在維基百科上，新增內容、刪除既有內容呢？（注意本案發起人的理由「新手／IP用戶可能會根據自己的立場加入不符合編輯方針的內容」）要不要獲取共識？（當發生編輯戰時，管理員經常會保護在 編輯戰發生之前的版本。）當被撤銷、或者修改，並且討論，就是尋求共識的一個過程，並非就是非善意，也不能說就是「編輯戰」了。(2)原創研究內容、不符合維基要求的來源，被加入時呢？(3)修改，是不是RR呢？
  3. 在下前面提問，0RR之下的反破壞？-----您提到「目前社群的管理員多不帶特定立場，判別原創研究或不符合維基百科要求的內容也比較中性合理，與其編者自己回退，為何不提報交由社群公論後由管理員處理」---幾點疑惑提出切磋，(1)這是否意味著，在0RR實際運作下，用戶處理反破壞等明顯編輯爭議的空間，恐怕被大幅壓縮、甚至會不會幾乎壓縮到零？(2)在下擔心，看起來為了解決一個問題，恐怕衍生更多問題。(3)維基百科的管理員，是否有這麼多時間？顯然情況不是如此。無此前，明確3RR、違反文明的人身攻擊案，在下提列完整證據，完全無人處理。
  4. 1RR，並不意味著用戶可以隨意無理撤銷。2RR、3RR也都不意味可以隨意撤銷。Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 01:15 (UTC)[回复]
(！)意見-LuciferianThomas您好，前面多位用戶表達了認為0RR過嚴的意見，即便在討論8天就被關閉前，也有用戶對0RR有不同意見，這沒有被處理到，就被關閉討論。-----您對於提前關閉討論的「大量用戶」的解釋，在下認為，應當審慎，不宜過模糊而超越了方針的原則性規範。
在下於前面其實提出多點 實質性意見。此外，在程序性問題方面，方針寫到「討論一般維持開放最少二週，若社群取得共識[a]即可由管理員結案」。在[a]附註，「制定討論的共識需考量所有用戶提出的理據和觀點。若討論發起七日後已有大量用戶參與且非常明顯近乎完全一致則可考慮提早結案。」。----這裡的「大量用戶」解釋上應當審慎。
查閱Wikipedia:高風險主題，各個討論期間，此前都在14天以上。
  1. 法輪功主題---討論期，2024年 5/26~6/3，8天。
  2. Wikipedia_talk:高風險主題/在世人物傳記--討論期 2023年8/30~9/13，約14天。
  3. Wikipedia_talk:高風險主題/臺灣海峽兩岸關係及政治地位---2023年8/30~9/18，約19天。
  4. Wikipedia_talk:高風險主題/加密货币及区块链--2023年 9/27~10/19，約22天
  5. Wikipedia_talk:高風險主題/反對逃犯條例修訂草案運動--2023年8/30~11/24，約25天。
  6. Wikipedia_talk:高風險主題/八九民主運動--2023年 11/7~12/19，約42天。
  7. Wikipedia_talk:高風險主題/医学--2023年10/9~11/22，約43-44天。
  8. Wikipedia_talk:高風險主題/搜尋引擎優化與營銷---2023年 8/31~10/27，約57天。Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 00:17 (UTC)[回复]
0RR被打破了再退回也是跟1RR类似，而1RR会多更多无谓的来回回退，倾向0RR。至于永久0RR过于严格的问题，Antigng曾经全保护汉服条目7年之久，我觉得可以参考；如果觉得不要永久，建议设置20年0RR，到2044年1月1日为止。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月15日 (六) 14:56 (UTC)[回复]
同意，不过20年太久，建议参考历史，以7年0RR为宜，之后改不限期1RR。--桐生ここ★[讨论] 2024年6月17日 (一) 07:11 (UTC)[回复]
Antigng保护汉服条目七年是基于14—21年打了七年编辑战，如果认为法轮功条目从05年来开始一直打编辑战的话，比照操作确实是20年 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月17日 (一) 07:22 (UTC)[回复]
很好奇我提议设立新型宗教为高风险主题时却没上过公告栏，是管理员的问题吗--重庆轨交18（留言） 2024年6月19日 (三) 14:12 (UTC)[回复]
您可以自己更新。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月19日 (三) 14:18 (UTC)[回复]
(？)疑問-魔琴、桐生、LuciferianThomas等用戶們好。前面多位用戶表達了認為0RR過嚴的意見，即便在討論8天就被關閉前，也有用戶對0RR有不同意見，這分歧沒有被處理到，卻就被提前關閉了討論。
在下淺見思索，是否對症下藥了？在下以為，0RR不一定能應對，還可能衍生新問題、副作用，維基會不會不再是自由編輯貢獻的維基了？(1)維基百科的措施、例如保護方針，盡量不影響用戶的編輯貢獻。(2)恐怕形成制度漏洞與風險被利用，有心人要在維基百科上去限制用戶編輯一些條目，動用IP用戶等，不時有人打編輯戰，就可以形成高風險、設定0RR？0RR這在手段、目的的對應上是否有效？例如最近客棧上Wikipedia:互助客栈/其他#將「1945年後臺灣政治」訂為高風險主題討論，發起人建議的方案是「不定期半保護」、「不定期半保護+1RR」。(3)目前看看，幾個被列高風險主題的（香港反送中、八九六四、台海政治），主要都是對中共的敏感議題。Wetrace歡迎參與WP人權專題 2024年6月19日 (三) 16:07 (UTC)[回复]
(！)意見- 依據高風險主題方針的規定，「提案人必須論證主題之風險，並建議合適的編輯限制措施。」，這部分在下感到在對應上可以再思考，例如 條目的保護歷史紀錄、情況，在過去一些「編輯戰」或者撤銷，許多情況實際上是反破壞、因應新註冊或IP用戶添加不符方針來源。
這次被提案 0RR的兩個條目，在下查詢過去5年半紀錄如下，在下認為0RR是非必要，手段與目標的連結與效果，值得思量。：
（一）【條目法輪功，從2019年起5年半，被保護紀錄6次】來觀察。(1)3次理由是「被IP用户或新用户破坏」。(2)2021年1次理由寫「編輯戰」，但原因是一方無理由刪除內容，另一方4天內只撤銷1次。(3) 2020年1次理由寫「編輯戰」，但原因是一方用戶無討論、模糊或不具理由刪除十多萬字長期內容，浮濫添加模板。--這是否應是反破壞。
  1. 2024年，1次，5月25日「全保護1週」，是因為「模板」的編輯戰問題（新註冊用戶堅持添加模板，在討論頁溝通）。（6月是因為高風險主題而被「不限期半保護」。）
  2. 2023年，沒有保護紀錄
  3. 2022年，1次，11月30日「不定期半保護」，理由是「被IP用户或新用户破坏」。
  4. 2021年，1次，5月31日，「全保護1週」，理由是「編輯戰」。---（有疑義？是否應屬反破壞。。查詢5/27~5/31編輯紀錄，A用戶5月27日無理由刪除第三方來源內容、無理由隨意改寫改變了原意；B用戶5/27只撤銷1次，到5/31都沒有再撤銷，4天內只撤銷1次「不附理由、刪除大量內容的編輯」。---這是否能算「編輯戰」？
  5. 2020年2次，(A)6月13日，「全保護一個月」，理由「編輯戰」。---(有疑義，應是反破壞)。查詢編輯紀錄，應是「反破壞」。原因是，A用戶未經討論、沒什麼具體理由，刪除了13萬-14萬字元來源長期內容，C用戶無理由浮濫添加十多個模板。---這應是反破壞。(B)7月18日，「半保護一年」，理由是「被IP用戶或新用戶破壞」。
  6. 2019年2次但應屬1次，8月16日「半保護3個月」，同一管理員3分鐘後改「半保護1年」，理由是「被IP用户或新用户破坏」。
（二）【條目李洪志，從2019年起5年半，2次保護】
  1. 2024年，沒有增保護紀錄
  2. 2023年，沒有增保護紀錄
  3. 2022年，沒有增保護紀錄
  4. 2021年，2次，6月12日「不限期半保護」。6月3日「全保護1週」，理由「編輯戰」。---(有疑義，應是反破壞)。原因是5月27日起，A用戶 無理由刪改大量內容，B用戶、C用戶在5/27~6/2 五天內，各自都附上理由說明 撤銷了1次。
註：以上兩個條目，五年來幾次被保護情況，3處提到的A(無理由刪改大量長期內容)是同一用戶。Wetrace歡迎參與WP人權專題 2024年6月19日 (三) 16:07 (UTC)[回复]
(！)意見@Wetrace：你的陈述，存在问题
  1. 关于最近一次全保护，你称是新注册用户坚持添加模板，在讨论页沟通，但实际却是你（@Wetrace）在既未解决问题也未形成共识的情况下反复移除{{pov}}模板（第一次刚回复就移除、第二次在被提醒讨论未结束后仍坚持同一理由移除、第三次仍是同一理由），讨论至今也未结束，如今却谎称别人“坚持添加模板”，有点颠倒是非黑白的意思。
  2. 关于所谓“反破坏”，我认为是你对WP:破坏方针的曲解。我不对编辑战双方的对错做出评价，但我必须指出，编辑争议引发的编辑战根本不属于WP:VANDTYPES任意一种，反而更属于WP:NOTVAND中的“勇于更新页面”“移除或回退非百科性质的内容”“无意间添加错误信息”。你说“反破坏”，有“假定恶意”之意。
--Wnotieagusdr（留言） 2024年6月20日 (四) 02:31 (UTC)[回复]
(：)回應-Wnotieagusdr您好，
  1. (1)關於您說的中立模板，在該條目的討論頁，有多位用戶參與討論向您提問，您沒有就該模板提出具體內容上的理由。(2)您指控他人是「謊稱」。儘管您在您的編輯次數過程中常提起一些維基規定包括縮寫、看來熟悉，但Wnotieagusdr這一帳號是新註冊，因此在下還是在這裡提醒，請您注意 文明方針、不要人身攻擊等方針。
  2. 您指控在下曲解了「破壞」。但是，當條目被無什麼理由就刪除十萬字元內容，被其他人撤銷質疑，卻持續無甚理由為之，這不算破壞？無理由添加十多個模板，這沒問題？----------如果您認為在下這樣是「惡意推定」，那麼兩相比較，您會不會感覺，您前面對在下 會不會是「非常惡意推定」？ Wetrace歡迎參與WP人權專題 2024年6月25日 (二) 01:55 (UTC)[回复]
@Wetrace
  1. 关于添加模板：
    1. 我没有就该模板提出具体内容上的理由？我最开始的2则留言就已经基本说明了情况（[46][47]，包括但不限于“语调”等问题），此后也一直在就此与 @诗琳童 进行讨论，何谓“没有具体内容上的理由”？
    2. 有多位用户参与讨论向您提问？除了最开始你提出意见（我回复过），和中途 @Rastinition 来插了几句话（我也回复了）以外，我就一直在和 @诗琳童 讨论，何来“多位用户”？
    3. 您指控他人是“谎称” 请您注意 文明方针、不要人身攻击等方针？
      1. 你并未对我上方的陈述做出回复，那我就再重复一遍：你称是新注册用户坚持添加模板，在讨论页沟通，但实际却是你（@Wetrace）在既未解决问题也未形成共识的情况下反复移除{{pov}}模板。这说明你的描述与事实严重不符（明明是你坚持移除，却成了我坚持添加），说是“谎称”，并无不妥
      2. 我并没有违反文明、不要人身攻击方针。请看訴諸人身#並非訴諸人身謬誤（应该已经有人提醒你看过了），我认为你说的有问题怎么就成了“人身攻击”或“不文明”了呢？找这个逻辑，你说我“坚持添加模板”，是不是也是“人身攻击”呢？这明显不合常理。
      3. 你现在指控我我违反文明方针、不要人身攻击等方针（你虽说“注意”，实则是指控），我认为已构成WP:轻率指控
  2. 关于其他过去的编辑：我并不特别了解具体的经过，我也实在没有精力去慢慢了解事情原委，或是再次就相关问题讨论。但我需要指出，如果果真是破坏，有关用户应当受到警告、封禁等。再具体的，请其他社群或管理员来评价。
以上讨论实则已偏离“高风险主题”这一话题，是我不得不而回复，建议他人在权衡后考虑折叠有关讨论。--Wnotieagusdr（留言） 2024年6月30日 (日) 03:17 (UTC)[回复]
(！)意見-Wnotieagusdr您好，(1)模板是「新增添加」的，新用戶是不是堅持？可以看討論與編輯紀錄。這無關人身攻擊。(2)3名用戶與您討論，不能說是多名？(3)您稱他人「謊稱」，是不是意指他人「說謊」？什麼是說謊的定義呢？因此，在下「提醒您」「注意」文明方針、不要人身攻擊方針。如果您認為這樣就是「輕率指控」，但您稱他人「謊稱」？Wetrace歡迎參與WP人權專題 2024年6月30日 (日) 03:43 (UTC)[回复]
  1. 模板并不是我加的，我只是支持添加、反对移除，并给出了理由；你却反复（3次）在无共识的情况下移除模板。这说明事实是你反复移除，而不是“新用户坚持添加”
  2. 我已经说明：我认为你“谎称”（没错，即“说谎”），是因为你的描述与事实严重不符（明明是你坚持移除，却成了我坚持添加）（这就是我对“谎称/说谎”的理解）。我已经说得很清楚，一来不轻率，二来不是人身攻击（我说了，訴諸人身#並非訴諸人身謬誤），有什么问题？
  3. 你却说您指控他人是“谎称”。...因此在下还是在这里提醒，请您注意 文明方针、不要人身攻击等方针。逻辑链则大致是“我说‘谎称’→我在人身攻击”，并没有其他解释，这又怎么不是轻率指控？
  4. 你“提醒”“注意”xx方针，意思难道不是指控我违反了xx方针吗？我也“提醒你”“注意”WP:SANCTIONGAME，你应该很显然能理解我的实际意思吧？
  5. 主要1人，次要2人真的是“多位”吗？
    1. 一般，也是一开始，我认为你表达的“多位”就是“很多/大量”的意思，我想一般人也会这么解读。如果你纯粹意思是“不止1人”，那确实没说错。
    2. 如果你确实表达的是“大量”的意思，那我用你的话反驳你：“7人讨论（更正:含发起人10人-仍难属“大量用户”），很难说是“已有大量用户参与””，难道3人，且争议极大，就是有共识了吗？
--Wnotieagusdr（留言） 2024年6月30日 (日) 04:21 (UTC)[回复]
前面被关闭的讨论仅有一位用户建议改1RR，这种情况下大多数的共识仍然是0RR，所以Mys_721tx的处理没有问题。而后续如果有不同意见，可以重新提案讨论，再修改相关条款，比如现在有一些“前期0RR，后期改1RR”的意见这样。--桐生ここ★[讨论] 2024年6月22日 (六) 08:26 (UTC)[回复]
桐生您好，(1)在討論被關閉後，後續其他的留言，約4-5位用戶看法是1RR，其中2位有參與「被關閉前」的討論。(2)管理員的處理過程仍有待商榷與疑問，在下不大認為，當時情況能算做有「大量用戶討論」而提前關閉討論。被關閉後，在下提出留言意見，但被關閉討論的紫色框並未被取消，這很影響用戶們討論上的認知與理解、討論。(3)高風險主題方針，要求發起人論證條目風險、提議適合建議。發起人此前提出一個條目2005年來被保護次數。在下於上面整理貼出 該「兩個條目」近五年的被保護情況與原因。Wetrace歡迎參與WP人權專題 2024年6月25日 (二) 01:55 (UTC)[回复]
在中立性问题得到有共识的改善之前，0rr显然无助于条目问题的解决，因此不认为0rr是可以接受的处理方式，我认为高风险主题在于预先善意提醒编辑参与编辑战的风险，而非成为问题条目的额外一层保护伞--重庆轨交18（留言） 2024年6月23日 (日) 04:07 (UTC)[回复]
重庆轨交18这个观点我支持。--桐生ここ★[讨论] 2024年6月30日 (日) 07:13 (UTC)[回复]
二週期限已過，目前看來社群還是有共識的。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:33 (UTC)[回复]
(？)疑問-您好，在下感到有待商榷。(1)要如何看「兩週」期限？在下以為，原來的討論8天就被關閉，該討論(被紫色關閉)沒有被管理員重啟、紫色框沒有被取消，看起來就是一個被關閉、既定結果下的討論。這些會影響後來討論用戶的理解認知、意見表達。(2)這一個不足，會顯然影響社群共識的形成。此外，有些疑義分歧。(3)在下建議，高風險主題的討論，不宜再有提前關閉情況，由於要件模糊恐怕容易被利用操作，而且容易有後遺症。以上淺見。Wetrace歡迎參與WP人權專題 2024年6月25日 (二) 01:55 (UTC)[回复]

RFDA（及未來成立仲裁委員會后的解任程序）相關探討

原标题为：動議：凍結社群解任管理人員程序直至仲裁委員會成立或按照當前新主流共識更改RFDA要求

撤回凍結方針動議，下方繼續探討正在討論的話題。--路西法人 2024年6月14日 (五) 04:04 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

在與最新一期管理人員投票同步進行，有關「管理人員解任在多大程度由仲裁委員會處理？」匿名RFC中，獲得不少針對解任程序未來去向的意見，其中存在絕對多數用戶同意或不反對任一先行經過調查才能解任的方案，反映社群有非常強烈的初步共識認為解任管理人員前應先經過調查確認是否存在違規事實，由社群部分人的片面之詞（甚至是扭曲方針指引及事實的說辭）來發動解任顯然已經不再是主流觀點。

由此，我謹此動議，凍結社群解任管理人員程序，直至仲裁委員會成立或按照新的主流民意調整RFDA的基本立案要求，確保RFDA仍然符合社群的最新意見和初步共識。當然，「直至仲裁委員會成立」可能還要等比較久，凍結至完成調整RFDA立案要求至滿足新主流觀點為止。

補充說明：若是在仲裁委員會成立前調整RFDA立案條件，則是參考仲裁委員會機制下「先調查、確認違規事實存在，再開展除權程序」。雖然我可以想像由社群來調查很可能也仍然會被部分人通過扭曲事實擾亂調查，但起碼要比現在任意發起RFDA，不用顧不當行為事實是否成立要強。 --路西法人 2024年6月13日 (四) 15:04 (UTC)[回复]

看了一下Wikipedia_talk:仲裁委员会#管理人員解任和其中的問卷，我覺得這個方法是可行的，問卷當中也確實絕大多數人對此抱有期待，期待改變中文維基百科社群有處理的情況，也許在一些保持反對意見的人來看這不是什麼好事，但某種意義上是一種進步，社群試圖尋找出路。不過有一些要點還是要提醒下
1.仲裁委員會成員受到社群信任
受到信任的成員發出來的報告，報告的性質才不會被因"人"的原因產生變化，試著想想不受信任的仲裁委員會發布的報告，社群大多數人會接受與否。
2.仲裁委員會的意見及報告等社群要接受
這裡的接受不需要所有人都接受，只需要做到絕大多數人都接受，注意這不是忽略少數人的觀點，只是社群很難做到所有人都接受的事情，在很多事情上必然要做出取捨，如果所有人都要同意才能進行改變，長久下來對社群的發展是不好的。
3.仲裁委員會的在中維當中是處於什麼樣的位置
處於什麼位置很重要，沒有確立好，很容易產生爭執。
----
最後看完討論後我倒是有個建議，在"乙"的提案中加入一個前提，確保RFDA討論是無法有效進行，誰也不讓誰的情況再交由仲裁委員會，不需要一開始就交給仲裁委員會，如果社群能夠處理，那就不需要仲裁委員介入，一定程度上可以避免爭議，畢竟即便是仲裁委員發出的報告，也必然會有一部分的人不認同，如果全權都交給仲裁委員會，社群對仲裁委員會的不滿意度會越滾越大，最後反倒吵起來說要把仲裁委員會撤掉，這是我所擔心的，以上希望我的建議能為大家所考慮，謝謝。--~~Sid~~ 2024年6月13日 (四) 15:56 (UTC)[回复]
題外話，我建議社群可以的話，請為方針指引設立案例頁面，用很明確的方式告訴所有人什麼樣子的行為與內容違反方針指引是不能做的，指引可能會遇到的例外情況也建議一併列舉。--~~Sid~~ 2024年6月13日 (四) 16:28 (UTC)[回复]
此外RFDA我認同可以凍結，但如同上方意見，有些事情或許應該多加考量。--~~Sid~~ 2024年6月13日 (四) 16:36 (UTC)[回复]
注意我認同可以凍結，並不是代表一定要凍結，可以的話我仍建議可以討論一下，當然我希望是有效的討論，而不是大家又吵成一團 ( ~~Sid~~ 2024年6月13日 (四) 16:59 (UTC)[回复]
我不认同冻结，RFA和RFDA是维基百科的根基，仲裁委员会是尚未验证的后来之物。至于上方RFDA请求是否成立，诉诸共识或大多数人的共识即可。--桐生ここ★[讨论] 2024年6月13日 (四) 18:16 (UTC)[回复]
  • 管理人員解任在多大程度由仲裁委員會處理？
    • 甲、仲裁委員會按調查事實及方針指引，直接作出除權決定。
    • 乙、由仲裁委員會調查事實並發佈管理人員操守報告，確認存在違規事實後，才轉交社群決議除權。
    • 丙、仲裁委員會完全不參與管理人員解任。
问卷问题不当，并没有说明是所有RFDA按上方甲乙丙处理，还是只有争议无法在社群解决然后送到仲裁委员会的RFDA案件，按上方甲乙丙处理。--桐生ここ★[讨论] 2024年6月13日 (四) 18:24 (UTC)[回复]
當初問卷內容實際上沒有經過社群共識決定（貼出草稿而已，沒有正式公示通過），所以問題很多。當初我早就提出質疑，也未獲澄清，就莫名其妙拿去安全投票了。還好問卷祇是諮詢性質，沒有產生什麼約束結果。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月13日 (四) 20:24 (UTC)[回复]
(－)反对凍結程序：現有之管理人員解任程序本來就是經共識產生；前述問卷祇是就仲裁委員會之角色提出諮詢，沒有如何連帶處理社群既有程序的要求，故本來與此無涉，至少不應該過度延伸。再說，最近幾次案例也顯示，原來沒有共識基礎的解任投票提案，都根本不會通過，甚至一大部分提早就宣布無效，正是彰顯社群尚未失能，現行程序運作無礙。另外，現有方針很明確定義管理人員解任條件及必要程序，早也就是所謂「確認違規事實存在（內容不符或原因不合理，可視作申請無效），再開展除權程序」之流程，差別只是在仲裁委員會作為實體機制，調查結果大概可以比較明確，而現有程序中，社群之「確認」較為隱性，反映在支持連署及討論過程中。現有程序並沒有任何常規替代方案（不計緊急解任），或可說共識陳舊而需要修訂，然在有具體解方前，顯然不應該剝奪社群對管理人員人事的最後決定權。該問卷祇是再一次確認社群長年以來認為有相當理據才能解任管理人員（這也應該是常識），並認同社群擁有最後決定權（而非由仲裁委員會逕行決定）的固有認知（不是所謂「新主流共識」）；社群合資格者（以後的仲裁委員會當然也在內）都能提出解任，但祇有社群後續判斷理據確實者，纔有機會獲得足夠支持，這是兼顧維基人發言權利及社群意志實踐的作法，自然符合社群共識。此提案屬於憑空製造問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月13日 (四) 20:05 (UTC)[回复]
你的主張是現有方針很明確定義管理人員解任條件及必要程序，早也就是所謂「確認違規事實存在（內容不符或原因不合理，可視作申請無效），再開展除權程序」之流程，然而跟你自己的主張相牴觸的是，你身為此解任案的第三方管理員，在該用戶明顯威脅、脅迫其他第三方管理員等不文明行為、連其主張的濫用封鎖權限都已經被解封管理員的說法打臉（封鎖理由成立只是解封管理員認為不需封鎖），更公然聲明將不會討論違規事實成立與否、僅由聯署人自行認定溝通無效，完全跟你口中的「必要程序」相牴觸的時候，卻完全不予阻止袖手旁觀，這不就反映社群阻攔不文明、濫提解任的失能完全成立？過往非當時管理員依照方針賦予的權力提前結束解任案還受質疑，豈不是完全反映社群決策能力已完全失能，而僅有少數正常的管理人員維護方針？--路西法人 2024年6月13日 (四) 22:17 (UTC)[回复]

本主題全部或部分段落文字，已移動至#當前解任案效力。

一併回覆Ericliu1912及桐生ここ：……（討論已移動至下方）--路西法人 2024年6月13日 (四) 22:36 (UTC)[回复]
(－)強烈反对：
  1. 仲裁委员会机制尚未验证，其实际效果和操作过程尚不明确。为了一个尚未验证的机制，而冻结现行的有效程序（显然不会因行政员争议性的终止等同无效），无异于舍本逐末。关于仲裁委员会在管理人员解任中的角色，在下同@桐生ここ：目前的问卷问题存在明显的不足。问卷没有明确说明是所有RFDA按上述甲、乙、丙方案处理，还是仅有争议无法在社群解决的RFDA案件按上述方案处理。此种不明确性导致问卷结果不能充分反映社群的真实意见。
  2. 考虑到仲裁委员会的设立、仲裁员选举、立案时长分析、条文讨论等过程显而易见地非常冗长，冻结现行程序更有阻挠现行政策正常运作，即时处理当事管理员问题之嫌。应按照现行规则即时的处理管理员问题，确保社群的正常运作，不受争议管理员可能之危害。
  3. 最后，在下坚决反对行政员可能在任意时间决定冻结RFDA程序的行动。此种争议做法在前次已经引发“官官相卫”“未得社群共识”“违反官僚体系”等严重质疑，损害社群讨论之原则。甚至换句话说，如果仲裁委员会一日不建立，便一日不能追究、及时处理管理员之问题，显然干扰社群监察程序。综上，在下反对冻结。并建议直接滚雪球关闭此讨论。--Gluo88（留言） 2024年6月13日 (四) 20:18 (UTC)[回复]
@LuciferianThomas：還請動議人在此處說明一下仲裁委員會相關事宜的進度。假如進度推進得足夠快的話，凍結程序並不一定必要。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 23:13 (UTC)[回复]
目前尚餘總結解任相關觀點，並設計出符合儘量多人意願的解任相關機制後，就能寫整個方針，經過社群公投endorse後上路。
就算進度推進得夠快，也無法阻擋當前Gluo88公然發表違反解任程序要求的提案，在修訂社群解任途徑確保程序公義前或仲委會機制上路前，仍應凍結當前程序。--路西法人 2024年6月13日 (四) 23:31 (UTC)[回复]
(！)意見-將這兩件事情連結起來成為條件，恐怕有疑慮，是否要開這樣的先例？恐怕會帶來些副作用與後遺症。會否讓既有方針被凍結了？過去，沒有仲裁委員會，相關的程序與方針仍然持續進行，就是依照既有方針在做。Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 00:21 (UTC)[回复]
實際上早有先例。過往就是本地用戶查核權出了問題，使基金會凍結本地用戶查核權。另外，請注意提案中除了「凍結到有仲裁委員會成立」外，還有「或（凍結至）按照調查得出大家的主流觀點」（或如某些人否定調查得出的多數意見，也需確保程序公義得到彰顯）的選項。--路西法人 2024年6月14日 (五) 02:09 (UTC)[回复]
社群提出與仲裁委員會調查管道實際上仍應並行，這裡討論的祇有前者。因為很顯然，仲裁委員會祇能處理於該處提出告訴的案件，不能為整個社群越俎代庖。但我有點擔心，新提案在加入仲裁委員會角色同時，還打算一併消滅社群自行提出管道。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 00:33 (UTC)[回复]

本主題全部或部分段落文字，已移動至#仲裁體系下的解任機制。

我跟ATB正在共同籌備有關未來解任制度走向的提案……（討論已移動至下方）……--路西法人 2024年6月14日 (五) 01:16 (UTC)[回复]
是否無論如何一定要先經過仲裁委員會「確認」？本人認為社群自身仍有逕行運作程序的能力，不用全部經過仲裁委員會審查，祇有拒絕受理才能被動提案。當然，若要避免所謂「民粹政治」，可以提高標準。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 03:31 (UTC)[回复]
或許我說的不清晰：我在ATB方案上增添的走綫是給「社群提交給仲裁委員會」新增了前設，故產生「社群無人提請仲裁（而社群自行解決解任問題）」的走線。若社群自行走解任程序時理據出了問題，自然會有人提交給仲裁委員會；若真的幾乎沒有爭議的，那社群自己走完整個程序都不會需要仲裁委員會插手。如果有人提交，仲裁委員會又認定社群本身在該案已能自行處理（發起除權無明顯問題需要仲裁委員會插手），即可拒絕社群請求。不經仲委會提出除權的條件也不需要怎麽提高，還是滿足最基本的程序公義即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)[回复]
本人認為，現行情況實際上就是這樣，也就是社群多數時候能夠有效拒絕理由不完備的提案正式投票。那或許是對「事前」部分疑慮較多？也就是欲阻止伊始即直接上客棧「大亂鬥」的醜陋局面。不如拿上面剛剛提出的解任案問問，你覺得該案提請有什麼可能不滿足程序正義之處，畢竟有實際案例較好切磋。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 03:54 (UTC)[回复]
另外抱歉剛剛太認真看右邊那張圖，沒仔細注意您有提出「比圖片多一條」的走線Orz —— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 03:58 (UTC)[回复]
(－)反对。认为应该在选出仲裁委员会成员，完善相关方针之后再议，RFDA毕竟不是RFA，冻结不会带来什么好处，反而会带来麻烦，比如当前这项解任案，我不会对其进行任何评价，如果直接将之冻结，可能会使相关用户作出其他极端行为。如果其解任违反相关方针，可以直接由行政员决定关闭，而非冻结之。--在下荷花，请多指教（欢迎签到） 2024年6月14日 (五) 02:20 (UTC)[回复]
注意，解任方針是規定任何非當事管理員已可決定關閉，並無限制只能是行政員。另，我理解您反對凍結，若管理人員能及時阻止本次明顯有可能要違規闖關的提案，而有關用戶持續扭曲管理員言行的行為獲確切的阻止，那我將不會繼續追求凍結解任。能否請您就上方我和ATB（未在此留言，但右方流程圖是他製作的）提出的解任走向有何意見？若我在仲裁委員會成立前參照該走向修改解任方針（就是把仲裁委員會替換成社群整體調查，走先調查後解任的流程，確保未來不能再有同類事情發生，你又是否同意？--路西法人 2024年6月14日 (五) 02:30 (UTC)[回复]
(－)反对，我覺得先等仲裁委員會成立，且已確定相關的流程及規則，再來調整RFDA的作法。不太適合此時凍結解任管理人員的程序。--Wolfch (留言) 2024年6月14日 (五) 02:37 (UTC)[回复]
(－)反对，目前沒有數據是否有效，更且仲裁委員會還沒成立，成立後，必須先觀察，不需馬上處理凍結解任管理人員的程序--HYHJKJYUJYTTY（留言） 2024年6月14日 (五) 03:43 (UTC)[回复]
(－)傾向反對：正如Gluo88君所说，“仲裁委员会的设立、仲裁员选举、立案时长分析、条文讨论等过程显而易见地非常冗长”，而这段时间内仍有RFDA的需求。如果现在冻结RFDA，恐怕会导致这些需求难以得到满足。--CuSO4 · 龙年大吉 2024年6月14日 (五) 03:48 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

當前解任案效力

一併回覆Ericliu1912及桐生ここ： 雖然題目是針對仲裁委員會，但有關留言中的論據卻很多是廣泛對社群現象的描述，「社群失能」、「需要評估事實」、「先調查後除權」等顯然是廣泛的觀念。該問卷無法直接影響此動議，但有一定參考價值；所謂「仲裁委員會只處理社群無法解決才送到仲裁委員會的RFDA案件」也幾乎是沒考慮到「毫無疑問需要除權的操作大概都是走緊急除權」，管理人員解任投票也甚少有不會引起爭議，基本上到最後90%的都還得送到仲裁委員會解決（尤其是雙方不認可對方的論證的情況），近年每次除權爭議更是暴露了社群無法管控用戶不捏造事實、不扭曲方針、不無視解任程序的弱點，完全佐證了當前解任程序需要更明確要求調查確認有違規事實再發起除權程序。所謂「比較隱性的確認」反而是「完全沒有在發起前就明確確認」的意思，所謂的「確認」通過「聯署及討論過程」，但顯然發起解任程序的用戶沒有也不會考量討論內容，而是徑自聯署就打算闖關，聯署也無法發表實際的反對意見，簡而言之就是「七名無公信力用戶自行認定有罪」就開展解任，並不存在真實的「確認」違規事實，這也是近期情況和你的聲稱所互相矛盾的。

另外，看到兩位的反對都是針對仲裁委員會，然而我自己也在動議中表明更理想的情況不是「等仲裁委員會決定」，而是當前就直接明確RFDA的要求。還是那句，雖然題目針對仲裁委員會，但意見的變化是顯而易見的，我也沒有打算要把那個調查當作「已經存在的共識」來說話而是「參考其意見而發起新的動議」，請搞清楚此提案的意義。--路西法人 2024年6月13日 (四) 22:36 (UTC)[回复]

那可以繼續討論。由於本人支持未來社群提案與仲裁委員會調查兩管道繼續並行，自然也有檢視前者並加以調整之必要。本人也並未否認近年來見得諸多不成熟之解任提案，徒然浪費社群資源。此處只是要指出，不應該因為若干使用者可能脫序或濫用之行為，就要求直接「凍結」社群的民主權利，現在又不是什麼非常時期。「提出解任」本身也是程序不可忽略的一部分，無論內容有多麼不合理，至少也要先「存在」才能予以駁斥（更何況其實指引已經明確指出，提案伊始即「內容必須詳細，指出管理濫權的原因，並根據編輯記錄及使用者貢獻提出相關證據」，理論上不滿足即自始無效）；即使往後要組織某種詳細「調查」，也是要先有人「提出」或「申請」管理人員可能的濫權行為，不可能憑空造成。所以本人並不理解過度誇大此一階段亂象的用意。另外，若既已為滿足前述有效條件之提出，則此後之辯論，維基人間存在觀點差異亦實屬正常；雖不排除確實有「無腦支持」者（實際上任何站務程序都有），但逕行認定聯署是「無公信力用戶自行認定有罪就開展解任」，則恐怕有歧視若干社群參與者及菁英主義思維作祟之嫌。照這種說法，所有人可能都是「無公信力用戶」，管理員解任申請不就變成「無公信力用戶法庭」。不過如此一來倒是大概可以理解，為什麼那麼堅持要走以仲裁委員會逕行裁決這種路線。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 00:07 (UTC)[回复]
一般用戶不經任何選舉，公信力是undefined（這種「沒有公信力」）。仲裁委員整體有一定公信力。
另，雖解任案未正式發起，管理員未能按解任方針取締，但他能預告將會作出違反程序的行為，管理人員也可明確告知違反程序的提案將會被截停，並呼籲其遵守程序，在已知會發生的問題發生前直接堵截，而不是等到問題發生才做事。--路西法人 2024年6月14日 (五) 01:29 (UTC)[回复]
若方針持續遭到濫用、扭曲，且情況非常明顯，如果放任不管也會造成明顯大的傷害（如除權方針），那麼自然就該凍結程序，這好比現實中正在提出釋憲的法案可被臨時暫停執行；正如如果未來社群選出的仲裁委員會go rogue，放任不管也會造成明顯的傷害，那麼自然就該凍結程序。--路西法人 2024年6月14日 (五) 02:18 (UTC)[回复]
本人不認為凍結整個程序符合比例原則。所謂「持續」，也不必然。況且就該案而言，當事管理員作風問題乃長久以來眾所皆知，也引起諸多爭議。提請解任本身或許過當，但其來有自，當中所隱含的問題並非全然無探討之可能。我們管理員是有權力的一方，本來就應該賦予對造相對多話語權，易言之即容許較大限度之發言自由，這本來也是他們唯一可以「制衡」管理員行使職權的辦法。本人不認為該案之提出者在「濫用」解任程序，至少也不應該是擴大到其他個別案件的理由。另外，現行解任程序少數的大問題，就是雖然指出要「溝通無效」，但很多時候當事管理員堅持立場，就很容易構成，然後就是客棧提案一片混亂。本人認為就條文相關部分討論如何清晰定義（尤其是什麼樣的內容理由為「有效」），且「同時」兼顧當事管理員及提請人權益，要比凍結整個程序實際多了。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 03:38 (UTC)[回复]
以上討論分拆自上方討論。--路西法人 2024年6月14日 (五) 04:02 (UTC)[回复]
Gluo88以威脅的語氣試圖阻攔其他管理員正常行使方針的語氣，並在其本身對管理員行為的扭曲理解下營造管理員濫權的不實情形，並可以從其語調看得出不會接受任何解釋。反觀苗君仍在積極解釋、回應或回駁觀點，也通過討論、交涉獲得解封Gluo88的藍桌君出來說話，表明不認同Gluo88對苗君的指控。這些反映苗君確實有在積極溝通（回駁觀點也是溝通的一種）。反而是Gluo88的態度表明拒絕接受一切解釋，自己拒絕溝通並持續扭曲事實，自行製造溝通無效的條件，這顯然不是解任方針的本意。--路西法人 2024年6月14日 (五) 04:02 (UTC)[回复]
我剛剛才發現，解任投票根本還沒正式提出，那就更不用為此談相關程序問題了吧？該話題現在已經變成實質溝通之處。唯一認同者，即在此情況下，當事人不宜逕行提出解任。若未能如願，而屆時社群能有效應對，那亦可再度證明解任程序運作有效。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 04:20 (UTC)[回复]
否，我上面有指出：雖解任案未正式發起，管理員未能按解任方針取締，但他能預告將會作出違反程序的行為，管理人員也可明確告知違反程序的提案將會被截停，並呼籲其遵守程序，在已知會發生的問題發生前直接堵截，而不是等到問題發生才做事。--路西法人 2024年6月14日 (五) 04:29 (UTC)[回复]
我不太理解，難道質疑管理員亦不可？他雖如此「威脅」，但未付諸實行之前，無論如何實不可以「現行犯」論之。若社群多人持續表達關切意見，他也並非不可能拒絕「聽勸」。此外，這畢竟也與解任投票本身沒有直接關聯（因為解任投票尚未啟動，不構成程序問題）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 06:10 (UTC)[回复]
不是不能質疑，而是不能以扭曲方針的理解來質疑管理員，連給Gluo88解封的管理員都認為苗不存在擾亂或誹謗，而他自行判讀管理員解封就代表對其的封鎖是誹謗、是濫權，這不就反映觀念上就有問題，問題並非出自於被發起除權的一方？Gluo不斷合理化自己的行為，而苗、我甚至是藍桌都一再指出Gluo88先前行為並非妥當（只是藍桌認為不至封鎖），這不叫質疑，而是扭曲方針及事件事實而誹謗管理員吧。--路西法人 2024年6月14日 (五) 09:38 (UTC)[回复]
他可以提出質疑，社群則可以適當支持或反駁之，這是共識形成的正常過程。在此案中，大概認為理由不充分者居多，是否成案尚有商榷餘地。本人也不好評價個別管理員作風「惹人怨」的程度，但明顯可見並非孤例，故此處比起「帶有情緒而衝動質疑」之類形容，「誹謗」一詞或需要慎用。當然也可能是我對此類批評管理權限行使問題態度向來比較「寬容」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 13:05 (UTC)[回复]
上方解任案成功且合規立案的可能性之低，我已無意願再參與討論。不論是原則上還是方針條文上，都沒有條文能支持他做的事，如果他還是正式發起解任案，我再請求其他管理人員制裁有關行為即是。--路西法人 2024年6月15日 (六) 00:59 (UTC)[回复]
「以扭曲方針的理解」的操作空間過大，並非一個適合的判定標準，不然大家互相指控其他人的理解「扭曲方針」還得了。Sanmosa Snipe–Clam Grapple 2024年6月15日 (六) 00:58 (UTC)[回复]
每個方針都有背後的大原則，如果是對方針條文理解有誤的人，都難以推翻背後的大原則。明知自己對方針條文理解與方針背後原則和用意衝突的情況仍繼續堅持的，那就只能是扭曲方針了。--路西法人 2024年6月15日 (六) 01:02 (UTC)[回复]
我的意思是，真到了我説的那個情況，那個人是否真的「扭曲方針」還重要嗎？我最擔憂的事情是大家互相指控其他人的理解「扭曲方針」的時候，大家的指控實際上都是成立的，因為根本沒有人（在任何意義上）「正確理解方針」。Sanmosa Snipe–Clam Grapple 2024年6月15日 (六) 07:53 (UTC)[回复]
同意。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月15日 (六) 18:02 (UTC)[回复]

仲裁體系下的解任機制

我跟ATB正在共同籌備有關未來解任制度走向的提案，當中不會完全汰除社群自行發動解任的途徑，只是會有一定改動確保程序公義。右圖是ATB建議的走向，而我的想法是再向上加一條走線：社群發起解任後，用戶只能在投票發起前才能提交證據請求由仲裁處理，仲裁委員會在七日內需決定是否受理（條件：初步認為解任提案理由有問題）並展開詳細調查。由於解任走SecurePoll似已通過，準備SecurePoll也需要時間，多等七天不會有什麼大問題。拒絕受理或投票發起後不能由仲裁截停（已放棄受理權）；因拉票等因素而截停則不是RFDA仲裁機制了，而是一般用戶行為仲裁。這樣能確保仲裁不會被過度使用之餘確保未來解任程序能達到程序公義。補充：若社群提交給仲委會的理由跟發起除權的理由太不同，則自然不能視作仲裁委員會已放棄調查權，為防被濫用規則而挾帶不當理由闖關。--路西法人 2024年6月14日 (五) 01:16 (UTC)[回复]

是否無論如何一定要先經過仲裁委員會「確認」？本人認為社群自身仍有逕行運作程序的能力，不用全部經過仲裁委員會審查，祇有拒絕受理才能被動提案。當然，若要避免所謂「民粹政治」，可以提高標準。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 03:31 (UTC)[回复]
或許我說的不清晰：我在ATB方案上增添的走綫是給「社群提交給仲裁委員會」新增了前設，故產生「社群無人提請仲裁（而社群自行解決解任問題）」的走線。若社群自行走解任程序時理據出了問題，自然會有人提交給仲裁委員會；若真的幾乎沒有爭議的，那社群自己走完整個程序都不會需要仲裁委員會插手。如果有人提交，仲裁委員會又認定社群本身在該案已能自行處理（發起除權無明顯問題需要仲裁委員會插手），即可拒絕社群請求。不經仲委會提出除權的條件也不需要怎麽提高，還是滿足最基本的程序公義即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)[回复]
本人認為，現行情況實際上就是這樣，那或許是對「事前」部分疑慮較多？也就是欲阻止直接上客棧「大亂鬥」的醜陋局面。或許拿上面剛剛提出的解任案問問，你覺得該案提請有什麼不滿足程序正義之處，畢竟有實際案例較好切磋。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 03:54 (UTC)[回复]
  1. Gluo88提出苗君濫用封鎖的證據，光是與給他解封的管理員的理解已有顯著落差。提案人逕自認定管理員濫用權限或封鎖有瑕疵，而未經審視方針是否禁止某些行為，違規事實並不明確，解任案則不應成立。
  2. Gluo88對苗君誹謗Lanwi1的指控顯然存在誤差，苗君作為當年事件的當事人，除了當時短時間內就補充提供了公開討論的記錄外，其當年作為用戶查核員能將Lanwi1的公開口供跟技術資訊比對，亦可作為其指控或懷疑的證據。有證有據者的合理懷疑顯然難以構成誹謗，反觀Gluo88在他人（我）指出苗君確有提供證據後，選擇性無視並謊稱「沒有證據」（證據已經提供了，還有一些是苗君顯然不能公開的），還在毫無證據的背景下相信Lanwi1的說辭，用以指控苗君誹謗，乃是明顯的拉偏架，「誹謗」指控也難以成立。
  3. 苗君在討論中積極解釋、說明其行為，也通過交涉獲得解封Gluo88的藍桌君的認同；反觀Gluo88全然不接受任何解釋，並拒絕一切依照方針的規範及通用理解的觀念，顯然並非管理員所致之溝通無效（而是提案人拒絕溝通），不能成立解任案溝通無效之要件。
  4. Gluo88在一開頭就聲明將會發起明顯違反方針（不審核是否構成解任條件，只憑其自身及聯署人認定），亦有威脅其他管理人員不可執行方針賦予的權力（終止不當解任案），顯然嚴重侵犯程序公義。
光是這些，若仲委會已成立，以上程序問題已經足以將此由社群發起的解任案提交仲裁委員會處理了。--路西法人 2024年6月14日 (五) 04:20 (UTC)[回复]
  1. Gluo88提出苗君滥用封禁的证据，光是与给他解封的管理员的理解已有显著落差。在管理员最初已认定封禁查封理由欠缺，这是事实。也尊重审核管理员认为程度不到罢免的理念。涉事管理员的理解与本人的理解（及其他用户的理解）也不相干，除非诉诸权威。
  2. Gluo88对苗君诽谤Lanwi1的指控显然存在误差，苗君作为当年事件的当事人...通篇仍然持续为当事人未经认证（CU、CA）臆测伪证据发言，并忽略当事人已遭受严重精神重创的事实。打个不恰当的比喻，如果一个强奸受害者侮辱强奸犯，然后某个认说她犯了侮辱诽谤罪，她的言行客观上是不妥的，但这种检讨受害人的行为更是拉偏架，扭曲一般人道德理解，态度可谓令人发指。
  3. 苗君在讨论中积极解释、说明其行为，也通过交涉获得解封Gluo88的蓝桌君的认同...先不论在下几乎已全面驳斥阁下及涉事用户谬论（并且您除了诡辩，显然无法正面回应；另一位也没有能力全面回应在下的质疑）只能是个人意见，不代表我认同（及其他潜在用户认同），照@LuciferianThomas这种伪逻辑，在下尝试总结一下：大概就是只要当事人不断“发言论证沟通”就不构成“沟通无效”（并将其归责于提案人及联署人死活不认可），上个这么声称及类似的案例已被基金会制裁了。
  4. Gluo88在一开头就声明将会发起明显违反方针（不审核是否构成解任条件，只凭其自身及联署人认定），亦有威胁其他管理人员不可执行方针赋予的权力（终止不当解任案）... 我并没说不审核，而是交由联署人审核认定（本来现行方针就不用一致共识确认），这恰恰是符合过往惯例标准的原则（《方针》政策指出，大部分被人们接受的惯例不会立即被写上。方针只是明文的惯例标准。）反观前次管理人员的所谓“决定”已被广泛质疑“官官相卫”“违反官僚主义”“凌驾讨论”“无权确认”“不避嫌”这种藐视社群的决定，恰恰是侵害程序公义的行为(“管理员没有任何高于其他用户的特权，唯能实现社群讨论所得的共识“)，更应该就行政员争议行为交到仲裁委员会裁决，以正视听。
  5. 其实面对您的指控，在下本来是不打算留言的，但在下考虑到您并未停止有关涉嫌扰乱及游戏讨论行为，甚至发出明显的威胁，呼吁第三方管理员制裁在下，才不得不在此回应。此外，这个发言涉嫌“针对特定受众”基于“推销立场”的拉票行为。根据行政员前次所谓认定，“RFDA是本站大事”浏览量极高，所以已经构成大幅张贴效果。考虑到相关留言通篇粗亮红字体，还有可能构成情绪勒索骚扰用户（与第三方管理员）。副知在上次解任时发起讨论“拉票”的@魔琴阁下就此发表看法。
以上可合理确认LuciferianThomas君的所谓“程序问题”，无一例外其实都站不住脚。即使仲裁委员会成立，诸位仲裁员面对阁下指出的“程序问题”，在仔细审阅相关讨论后，除了给您发不应在讨论中，使用过多特效使别人感到骚扰的提醒或警告外，基于方针的正常理解相信也只能一笑而已。
在下请@LuciferianThomas君停止为涉嫌袒护涉事用户试图干扰本次Rfda的行为，并期望根据在下对阁下提出的质询，检讨当事管理员及自身问题，作出有益讨论事情。--Gluo88（留言） 2024年6月16日 (日) 01:06 (UTC)[回复]
我不好说其他人对于拉票是怎么定义的 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月16日 (日) 02:07 (UTC)[回复]
另外抱歉剛剛太認真看右邊那張圖，沒仔細注意您有提出「比圖片多一條」的走線Orz —— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 03:58 (UTC)[回复]
這個我自己也沒說清楚。--路西法人 2024年6月14日 (五) 04:22 (UTC)[回复]
大致同意上述图片的内容。--在下荷花，请多指教（欢迎签到） 2024年6月14日 (五) 04:34 (UTC)[回复]
简而言之，我反对把像台湾选总统一样的直接民主改成香港选特首一样的代议民主。香港特首怎么选，我觉得你也知道。--桐生ここ★[讨论] 2024年6月14日 (五) 07:22 (UTC)[回复]
同意桐生的想法。--千村狐兔（留言） 2024年6月16日 (日) 01:43 (UTC)[回复]
右方為添加了我所說的比ATB版本多一個走法的機制，Ericliu1912及Hehua可以參考看看如何。除了RFDA，其實多數其他仲裁調查都可以比照處理。--路西法人 2024年6月14日 (五) 05:59 (UTC)[回复]
看起來主動權是否仍在仲裁委員會？因若每一案總是有人要求受理調查，那程序上便實質造成社群直接管道不得通。管理員解任爭議向來大，可預見會有不少辯稱個案程序不符合方針者。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 06:11 (UTC)[回复]
是也沒錯，我甚至是預期未來絕大多數的仲裁提案最終必須經過仲裁委員會的手一次，但既然管理人員解任社群沒辦法自己處理（真的有問題的時候，還是得仲裁介入，總不能堅持不讓仲裁處理違規事項吧？），那把這個程序幾乎完全交給仲裁是可以理解的。我是不反對設置反聯署的機制（聯署改交仲裁委員會），但送往調查的門檻會要比直接送投票的要低一截（例如送往調查需5人聯簽，解任聯署門檻提高至10人）。
不過起碼這裏保障了多數情況下社群仍保有投票除權的權力，也確保仲裁委員會僅能在真的有問題的時候才介入管理人員解任程序（在社群能自己處理及未獲解任程序中的合理質疑的情況下應拒絕受理），但也確保在必要情況下由仲裁委員會自行行使去除管理人員權限的權力。（所謂必要情況，指濫用傀儡等所有可致（非短期）封鎖或禁制的違規情況）--路西法人 2024年6月14日 (五) 06:58 (UTC)[回复]
如此怕是有遊戲規則之嫌，畢竟祇要提出質疑，就可以強制將討論拖入仲裁程序，也很難預見仲裁委員會不會因為期望有案件，而對此傾向「照單全收」之類。此外，本人認為仲裁委員會試行第一任期期間，不宜移交過多權力。希望還有某種折衷或過渡方案供社群選擇。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 12:59 (UTC)[回复]
不過，考慮到社群或有希望仲裁委員會針對此類提案提供調查報告，若祇是請求類似國際法院就議題提供諮詢意見之類，而不直接跳過其他社群既有流程（即最右邊那條路線），那本人並不反對。其區別在於是仲裁委員會是主動受理調查，還是基於社群需求被動提供意見（用詞或有差異，但總之應該是這意思）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 13:09 (UTC)[回复]
回應第一則留言：
  • 很難預見仲裁委員會不會因為期望有案件，而對此傾向「照單全收」之類：仲裁委員會在接獲針對已經發起的RFDA案請求時，並非單單議決「是否受理」，仲裁員公開議決是否受理案件時還必須指出受理或拒絕理據，也不能空口無憑說「社群已無法通過社群渠道解決」，而是要提供論證。究竟是怎樣無法通過社群渠道解決，究竟是否非當事的管理人員採取行動即能解決，都是必須論證的點。當仲裁委員會收到直接提請調查管理人員行為之時，條件同樣適用，這情況下提出調查的人也是需要論證為何不通過社群解任程序（例如：提出解任一方論據不當，可預期他們走社群解任必然會造成問題）。仲裁委員會就算是「想接受案件」也要寫個合理到不行的理由，但有合理的理由就代表真的要接受案件了。
回應第二則留言：
  • 你的理解大致正確，但必須指出在「已經有明顯必要解任」、「緊急解任」或「根本不成立」等情況下，則不會發起任何解任投票，而直接由仲裁委員會作出決定。你所說基於社群需求，這個就很難定義什麼叫「社群需求」了，究竟是有人聯署發起仲裁，還是需要有共識，都會有人不同意；後者在已經吵得不可開交的情況下顯然已經難以實行，所以唯有通過聯署的方式發起仲裁以確保真的是「社群」需求而非「個人」需求了。
--路西法人 2024年6月15日 (六) 00:48 (UTC)[回复]
據我所知，社群共識不希望仲裁委員會作出逕行除權決定。那緊急除權外的「已經有明顯必要解任」是什麼意思？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月15日 (六) 18:01 (UTC)[回复]
說過了啊。--路西法人 2024年6月17日 (一) 01:53 (UTC)[回复]
這還真是沒看清楚（ —— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 17:58 (UTC)[回复]
感谢提及，我个人基本(＋)支持此方案。--在下荷花，请多指教（欢迎签到） 2024年6月14日 (五) 07:55 (UTC)[回复]
我認為此方案可以。--~~Sid~~ 2024年6月14日 (五) 08:36 (UTC)[回复]
支持這個版本。--Rice King 信箱 · 留名．邊緣人 2024年6月14日 (五) 11:25 (UTC)[回复]
(＋)支持此一版本。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月14日 (五) 11:41 (UTC)[回复]
我问个问题，如果RFDA只有一人认为不符合方针，即使整个社群都支持联署，也必须进入仲裁委员会程序？这个有人认为的有人是多少人？--桐生ここ★[讨论] 2024年6月14日 (五) 13:03 (UTC)[回复]
這自然是需要"討論"的，當然也有個更簡單的方法是讓認為不符合方針的人自己送，仲裁委員會看到這種情況自然會拒絕請求，有個壞處是會讓仲裁委員會很累就是，如果要採用，建議賦予仲裁委員禁止濫用仲裁的人提出仲裁請求的權力。--~~Sid~~ 2024年6月14日 (五) 14:09 (UTC)[回复]
如我上方留言所述，確實可以新增反聯署的概念，或為五名符合人事任免投票權的用戶聯署，或為最低限度一符合人事任免投票權的用戶加一非當事管理員共簽請求仲裁。一個人（尤其是當事管理員本人）即可發起進入仲裁程序也還真的門檻過低。--路西法人 2024年6月15日 (六) 00:29 (UTC)[回复]
如果要改革的话，我觉得应该加入反联署过程才能被仲裁委员会受理，不然就像你说的，当事管理员反对然后就进入仲裁就有点不合适了。--桐生ここ★[讨论] 2024年6月18日 (二) 19:23 (UTC)[回复]
原则上(＋)支持，太需要了。--Shwangtianyuan 不忘初心 牢记使命 2024年6月14日 (五) 16:13 (UTC)[回复]
  • 個人意見是發表調查報告後，解任與否應公付社群決議。即便調查報告認為提請解任是多麼錯誤，社群應擁有解任事宜的最終裁量權。-千村狐兔（留言） 2024年6月16日 (日) 02:25 (UTC)[回复]
    此前社群諮詢性投票已明確認可這點，我相信應該會體現在最終方案。沒有的話再來商榷。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月16日 (日) 04:22 (UTC)[回复]
    大致上認同這個觀點，畢竟不能排除調查報告出錯的可能性（是的，請質疑一切的權威），但我的個人意見是如果調查報告的結果是管理人員因屬於有必要的情況或緊急情況而被直接解任，這並不屬於社羣的裁量範圍。換言之，我認為如果調查報告認為這不屬於可以解任的情況，但社羣形成了顯然相反的共識時，無論調查報告是否出錯，社羣依舊可以在有相當共識的情況下發起解任投票，但其他方面我認同File:ArbCom de-admin procedure chart (LT version).png的表述。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 12:09 (UTC)[回复]
    「真有必要」就直接解任了，沒必要再提出調查報告，祇需要簡短說明。「真有必要」的情況應當已經很明確，正常人都看得出來（常識判斷），否則就不能說是「真有必要」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 17:57 (UTC)[回复]
    實際上就連上面舉例的濫用傀儡，我也不覺得必然適用直接解任，至多是調查期間允許暫時褫奪管理權限。因為這終究取決社群對管理員的信賴，說不準社群願意原諒過失，那憑什麼需要由仲裁委員會擅自代為「處刑」呢？由於已經有真正最後手段「緊急解任」，我甚至不覺得有必要給予仲裁委員會所謂「有必要情況」除權的選擇。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 18:02 (UTC)[回复]
    管理員不會有其他用戶沒有的豁免權，管理員做出應受非短期(全站範圍)封鎖或禁制的行為理應受與一般用戶相同的處理，而受(全站範圍)封鎖或禁制期間管理員本身就無權參與社群事務。近期受過封鎖的用戶本來就不能參選管理員，這個相比其他「建議條件」而言更幾乎是「必然需要符合」的要求，也是社群的基本期望。因嚴重違規而致非短期封鎖或禁制行為的用戶本來就不適任管理員，這種情況的解任是彈劾而非罷免。社群有權在被彈劾用戶接受封鎖及一年冷靜期後經重新選舉上任管理員，但顯然有過錯的就不是「可以被社群原諒」的行為。用戶單單因管理員身份而被「原諒過失」顯然變成獲得其他用戶沒有的特權。--路西法人 2024年6月19日 (三) 02:02 (UTC)[回复]
    本人早已指出，調查期間仲裁委員會認為確有必要時，可暫時取消當事人之管理權限，至於最終處份問題則完全是兩回事；既然說「管理員做出應受非短期封鎖或禁制的行為理應受與一般用戶相同的處理」，那解除權限方針明確指出「當管理員封鎖任何一位依從權限申請方針獲得權限的使用者時，請同時提報，讓其他使用者覆核考慮是否為之除權」，而管理員就可以被仲裁委員會逕行除權了？若真「理應受相同處理」，那此等失職行為，就雖自然成為得提出解任（「覆核考慮是否為之除權」）之「理由」，但並不總是直接等於「結果」。又此種「覆核」之對象一般而言是社群整體，不是仲裁委員會（部分例外既已言明於上述草案，此處不贅述）；社群有權就管理員解任案成立與否予以最後決定，此時又可參考解除權限方針提到的「蓄意犯規」、「草率行事」、「執於己見」、「沒有悔意」等要件，構成對管理員與其他權限持有者一視同仁之量尺，達到所謂「理應受與一般使用者相同的處理」。
    解任乃最終手段，請與社群事先商榷什麼情況值得如此做，不要自己定義「本來」、「顯然」、「特權」、「不是可以原諒的行為」，彷彿理所當然一般。尤其社群已明確傾向反對由仲裁委員會逕行處份失職管理人員，是以若一定要置若干例外，依據比例原則及法律保留原則（當然本站政策不是法律，但基本觀念類似），理當以明文列出，且或可能嚴格限縮處理。又即使如我個人意見上述如此，也沒逕行強求或壓制誰去接受，祇是提出供社群參考，我想任何人的意見都一樣；假使認為「應受非短期全站封鎖或禁制的行為」可以由仲裁委員會逕行除權，那就是首先要由社群確定是否同意此等條件，或初步予以修正（如不包含某些「禁制」情況、有權經社群額外同意排除某些意外情況個案之類），然後還要釐清所謂「非短期」具體指什麼、又此種行為應可能包含什麼情況（如上方提到「濫用傀儡」，具體是多嚴重之類）等細節，最後纔得凝聚為真正可行且符合程序正義之共識（以上是隨意舉例）。不是提一些模稜兩可的條件順溜過去就行。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月19日 (三) 17:52 (UTC)[回复]
    考慮一些過往案例，本人目前認為所謂「有必要情況」祇有遭遇值得受不限期封鎖之行為。受如此重大處份且未能申訴成功之管理員，亦往往會遭社群事後除權，甚至多數是緊急除權。本人認為，仲裁委員會在此種情況下裁決逕予除權，並不逾越社群過往實踐締造之共識及一般常識。若有其他認為可適用情況，還請社群具體提出。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月19日 (三) 18:20 (UTC)[回复]
    「因為這終究取決社群對管理員的信賴」不全然，這也視乎他本身造成的危害的嚴重性，這不是擅自代為「處刑」，而是避免社羣擅自慷受害者之慨。這樣說：就算你原諒了一個殺人犯，他還是一樣要被判死刑或終身監禁，不能說因為你原諒了而直接認為他無罪。Sanmosa 蚌埠 2024年6月19日 (三) 05:55 (UTC)[回复]
    社群是本站最高「政權機關」及一切事務最終決定者，本人認為真有共識（大前提）的話要「慷受害者之慨」也行；反過來說，如果仲裁委員會經審酌決定「慷受害者之慨」，閣下又該如何應對？何況在本站，所謂「極刑」不過是禁止編輯，且除極少數社群不可抗力情況（如基金會行動、全域禁制等）外，沒有真正不可逆的處份，此處完全不宜援用現實司法情況。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月19日 (三) 17:52 (UTC)[回复]
    真要用司法來比擬的話，仲裁委員會可以「限制遷徙」甚至「拘禁」，防止「嫌犯」繼續迫害他人，也可以提出「證據」（此處指調查報告，並非報告本身採用的證據）給予「法官」（社群）參考；仲裁委員會在其他管轄內案件可能自己兼任「法官」，但就管理人員解任議題而言，最終判決「有期徒刑」（本站沒有「死刑」）者則仍是社群，不是仲裁委員會（所以說為什麼不應該用現實司法比較，因為太強行硬湊了）。社群已經彰顯意志，不打算將仲裁委員會打造為非常之國民公會。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月19日 (三) 17:55 (UTC)[回复]
    我正是考慮到如此情況才會有上方“如果調查報告認為這不屬於可以解任的情況，但社羣形成了顯然相反的共識時，無論調查報告是否出錯，社羣依舊可以在有相當共識的情況下發起解任投票”的提議，這已經足夠救濟仲裁委員會「慷受害者之慨」所造成的損害了。雖然我個人比較傾向於權限較大的仲裁委員會，但從我上方的留言可見，國民公會形態的仲裁委員會也不是我支持的東西。Sanmosa 蚌埠 2024年6月20日 (四) 14:25 (UTC)[回复]
    反過來說，豈不亦適用？可再商討。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月22日 (六) 05:24 (UTC)[回复]
    這樣說吧，我既不希望一個被架空的仲裁委員會，也不希望一個被架空的社羣，我期望的是仲裁委員會與社羣旗鼓相當、能相互制衡，所以如果我沒有理解錯你說的「反過來說」的意思的話，這正是我自己期望的效果。Sanmosa 蚌埠 2024年6月23日 (日) 14:52 (UTC)[回复]
    另外，我同意有關社群就與仲委會意見相左時，可重行循聯署管道形成共識發起解任案的意見。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 18:05 (UTC)[回复]
    (！)意見：同Eric Liu，此版本和上一個版本不同，缺少仲裁委员会拒绝后社群自行形成共识的流程，建议增加此流程。--桐生ここ★[讨论] 2024年6月22日 (六) 08:15 (UTC)[回复]
    直接沿用既有聯署流程即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 06:48 (UTC)[回复]
    (！)意見：個人路過，僅額外表達身為用戶的意見，恕不參與後續和在此亂入。個人建議若有共識將類似仲裁的機制設立專屬頁面或區塊，讓有意願的用戶視案件試行參與，或若產生共識，視實際需求再看後續是否執行即可；在尚不具備特殊權限的情況下試行，若往後具備良好的實際效益和需求，以此另外舉行相關選舉也或無不可。然而我認為仲裁權的施行爭議似乎仍有討論空間，且難以比照現實生活的機制，光是「仲裁」本身具備的效力就極具爭議，且定位難明（現實中的仲裁可能具備法律效果，但仍有法律管道作為當事人不服的救濟機制；國際爭端那種姑且不論），而如果只具備所謂「調查權」，再交付社群議論，其實與當前機制相去不遠，直接交由社群議論或許更直接，了解議題或有興趣的人自可參與，與是否具備權限亦無關；此外，若仲裁員本身遭到當事用戶欺瞞拐騙又該如何？勢必仍需另尋管道明查暗訪、審慎查察等等，事實上這個過程和一般用戶參與討論相去不遠。而一個連具備實際特殊權限的管理員也無法維持秩序的社群，特別選出負責釐清事情的用戶，若再產生其他事實認定上的爭論，又或者其他用戶若有不服，救濟制度何在？仲裁效益何在？又或是仲裁委員因仲裁無方、標準不一、效果不齊，是否又衍生其它爭執呢？是否最後仍須交付基金會呢？而若繞回社群議決，一個不具實際決定性效果的權限是否可能繞一圈後又回歸爭執呢？而若具決定性效果，該具備何種權限，或許仍須回歸實際需求，如果其實不太需要的話，也可能根本不需另行規劃。這樣看來，「仲裁」似乎有點像是「監察權」，但現實中的某些監察權亦已為人詬病頗多（笑）。以上並不代表不應規劃此類機制或權限，而是此制度的施行就目前社群現況、投票及討論結果來看，眾人對於社群事務和機制中，強調「制衡」所帶來的公平性和安全感，似乎仍遠勝對於「決斷或判定」所帶來實際效益的信任和需求。既然如此，真正需要詳加調查討論的問題，終須回歸社群決議，而議事的過程個人認為這仍屬社群自制力和是否具共同目標的根本問題；至於管理員用權的「認事用法」問題，我認為則回歸管理員所具備權限性質的長期命題，多數爭議亦往往來自於此，而當前諸多網路平台似乎也是如此（警察＋判官，但好像也都是這樣）。對於個案，個人傾向讓具管理經驗的行政員直接判斷特定管理員是否於特定案例濫權或用權過當，以此提供實務意見，社群再行議論，這和訴諸社群民意類似，但可能可以嘗試結合試行機制看看。目前是否需直接特別設立選舉產生的特殊權限，個人傾向斟酌。--Kriz Ju（留言） 2024年7月1日 (一) 14:31 (UTC)[回复]
    支持Manchiu的意見，解任與否的決定權應在社群，仲裁委員會在解任案中不應擁有最終決定權，其作用更應該是處理私密資訊和提供對證據的調查報告以供社群作出決定。當然我不反對仲裁委員會可以執行緊急除權等極為特殊的事態。另「仲裁委員會調查期間凍結案件」應明確規定凍結時間。--🎋竹生🎍 2024年7月7日 (日) 02:28 (UTC)[回复]

臨時暫停特權機制

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

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

@Ericliu1912 @LuciferianThomas -Lemonaka 2024年6月14日 (五) 13:11 (UTC)[回复]
仲裁委員會大概可以視情況決定是否技術上暫時取締管理員行使權限。不過本地相較於英文維基百科，尚沒有直接取消管理員系統操作權之權力，本人認為這代表兩地社群習慣差異，故制度移植時亦應有本地化措施以為反映（例如縮減可取締權限之案件種類等）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 13:15 (UTC)[回复]
我觉得可以提出紧急冻结机制，类似紧急除权，比方说监督员、界面管理员等重要权限，正在调查期间社群或行政员认为必须先除权以保证安全，则先除权，等待调查结果再恢复或维持除权。--桐生ここ★[讨论] 2024年6月14日 (五) 13:21 (UTC)[回复]
重點在於「無罪推定」（雖然應該少援用司法概念）。除上述情況外，本人認為唯有涉及管理權限行使可能損及當事人權利，或妨礙案件之進行，或有正當合理之依據認為案件進行中不適宜持有權限者，方得暫時除權。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 13:40 (UTC)[回复]
這有個問題是誰來判定會比較好，Arbcom判定社群會有人不認同，社群自己來討論要不要暫時除權又會因為爭執而不了了之，一個很尷尬的情況。--~~Sid~~ 2024年6月17日 (一) 09:08 (UTC)[回复]
Sid说的有道理。仲裁委员会只是是少数人的决定，社群大多数人的共识才具有公信力。--桐生ここ★[讨论] 2024年6月22日 (六) 08:17 (UTC)[回复]
这种观点我真的不认同。仲裁委员会是社群选出来的，细节是由社群敲定的，最终的提案也是要由社群通过的。在这样的程序下，仲裁委员会的决定必须具有公信力。如果说决定不具有公信力那么要仲裁委员会干什么？
我选择甲的原因也同理。如果委员会需要调查再由社群讨论，那搞选举、审议这些程序完全没用。完全可以找几个看起来社群信得过的人，组成一个「非官方」的委员会，也可以调查。
再往普通解决行为争议来看，即使无法除权管理员，委员会一定需要有封禁，设置编辑禁制的能力。设置委员会就是为了一个「最终解决方案」。如果例如ANM上面的案子十分棘手，以至于没有管理员愿意去处理，那么就去找委员会。委员会基于社群方针来判断事务是否使用管理工具来处理，而不创建新的方针。如果说委员会在处理普通用户争议的时候也要「推荐」管理员如何处理，实则无权的话，那这个委员会不要也罢。--0xDeadbeef (留言) 2024年6月25日 (二) 11:54 (UTC)[回复]
说到底我怀疑社群能否选出这么一个委员会。--桐生ここ★[讨论] 2024年6月25日 (二) 13:33 (UTC)[回复]
我保持乐观，但我的想法是，与其将委员会的权力一砍再砍，就为了社群能够选出一批人，结果选出来也不能改变社群生态，不如保留委员会权力，社群在知情委员会权力的情况下选，选出则能对社群环境有一定的影响力，选不出就当失败。--0xDeadbeef (留言) 2024年6月25日 (二) 17:39 (UTC)[回复]
@0xDeadbeef What about A/B group? They can scrutinize each other. -Lemonaka 2024年6月26日 (三) 03:46 (UTC)[回复]
Not sure how well that will work in practice, but maybe worth a try if people want to.--0xDeadbeef (留言) 2024年6月26日 (三) 07:31 (UTC)[回复]
無論是ArbCom還是社群討論處理，我認為可以先討論當Arbcom決議有人不認同時社群要怎麼解決，當社群討論發生爭執導致討論不了了之時怎麼解決，這是可以預想到的情況。
我很不希望到時候社群不接受仲裁委員會的決議，又嚷嚷著要罷免仲裁委員會，那是非常難看的情況。--~~Sid~~ 2024年6月30日 (日) 09:51 (UTC)[回复]
問題是這個「選的門檻」、「敲定的細節」，過程及結果是否合理？不少人有疑慮。既然並非如英文那邊當年由威爾斯「君權神授」，本人認為本地仲裁委員會的權威是要經由實際裁決確立，不是伊始就賦予莫大權限。尤其涉及直接處理管理權限者，應不必屬於首屆就奉送委員會的工具。目前本站與監管員等全域社群合作無間，本人雖一貫主張社群拿回應有之自治權，但現階段也未見到由仲裁委員會接掌彼等緊急處置權限的必要。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 05:30 (UTC)[回复]
那你觉得仲裁委员会是来干什么的呢？早就有人使用「没必要」这个理由来否认各种事情，我对此的回应是，确实，WP:CHOICE也说了，编辑维基百科也没必要。你当维基百科管理员有必要吗？那为什么还有人编辑百科，为什么你还要当维基百科管理员呢？
我知道我在委员会是否应该有权力去除管理员这个讨论中持少数观点，所以我也不想继续陈述我的观点。你说循序渐进我无所谓，要是能够通过实际判决历史来让社群更信任委员会是好事，但是我其实想强调的是刚开始ArbCom也至少应当拥有设立禁制及设高风险主题的权力。如果选出来的委员会没有办法实现决议出来的结果那就非常无能。就和WP:NAC不能关闭为删除一样。--0xDeadbeef (留言) 2024年6月26日 (三) 07:07 (UTC)[回复]
據我所知，仲裁委員會職能到現在都沒有確定。具體而言，目前高風險主題在客棧提案模式運作良好（除了法輪功本來爭議較多），對於本站來說高風險主題本來就是個低層級議題，確實不用仲委會插手。另外，我不確定你是想要仲委會有權下達什麼形式的禁制，但大部分情況應該都沒問題，因為社群至少有共識賦予仲委會某種裁決封鎖操作之權，這自然也就包含禁制。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 08:19 (UTC)[回复]
那就好。--0xDeadbeef (留言) 2024年6月26日 (三) 12:06 (UTC)[回复]
我是認為高風險主題作為編輯限制的一種，可以作為仲委會的爭議解決手段之一（跟禁制權相似），但絕對不會覆蓋社群本身訂立高風險主題的權力。目前CTOP下，社群經共識實施的編輯限制只能由社群經共識解除，而不能由任何管理員自行解除；仲委會的則可有相似機制，仲委會的高風險主題限制（不論是設定新的高風險主題或是編輯限制）都只能由仲委會或極廣泛共識（30人80%支持？）解除，仲委會也可基於方針及其原則解除社群共識訂立的編輯限制（不過只能是回應申訴）。--路西法人 2024年6月27日 (四) 03:20 (UTC)[回复]
本人亦認為仲委會有權在必要時自行提出高風險主題，為其執行手段之一。當然，社群對此當有覆核權，其門檻應與經一般社群管道（客棧）制定者相同。相對而言，仲委會祇能被動決定解除已無需求之高風險主題，而不應主動介入（這應該與閣下觀點相同）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月27日 (四) 04:16 (UTC)[回复]
@桐生ここ What? Arbcom are elected by the whole community, unless the community consensus is hijacked by a small group of users, the arb will be reviewed as the representative of the whole community. Why will they become the minor? -Lemonaka 2024年6月26日 (三) 03:48 (UTC)[回复]
问题是争议发生当下，当事人们是否认同委员会是他们选举出来的吗？而且事实上仲裁委员会的决定是有限数量的委员们达成的共识，而社群可以组成共识的人数是无限的。--桐生ここ★[讨论] 2024年6月27日 (四) 02:38 (UTC)[回复]
不认同也得认同。就像如果我进行扰乱维基百科，游戏维基百科的事情的话，有管理员要封禁我，我是不是说「我不认同你是被社群选举出来的管理员，你的决议不是社群共识，请在社群中形成共识再封禁我」就可以有免死金牌了？--0xDeadbeef (留言) 2024年6月27日 (四) 02:49 (UTC)[回复]
管理员是执行共识，仲裁委员会是没有共识的情况下制造一个“共识”，还是有点不一样。--桐生ここ★[讨论] 2024年7月1日 (一) 19:52 (UTC)[回复]
在什么情况下仲裁委员会是在没有共识的情况下制造一个共识，而不是执行共识？--0xDeadbeef (留言) 2024年7月2日 (二) 03:25 (UTC)[回复]
其實若仲裁委員會按方針與指引精神裁定，那本質上與管理員行使自由裁量權意涵相同，都是執行社群共識。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 04:21 (UTC)[回复]
有幾種民主解方：一種是社群以足夠高門檻另行達成有效共識，推翻仲裁委員會決議；另一（兩）種是經罷免或次屆選舉移除若干社群認為不適任之委員。社群可以決定是否兩（三）種解方並行，或祇允許其中幾種。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月1日 (一) 19:47 (UTC)[回复]
初期仲裁委員會或本地行政員都還沒有權限可以自行取消管理員權限，這個或許要到未來屆數的仲委會選舉前再解決。目前狀態下，僅有「可能需要緊急除權」、「（發佈報告後）已經確認符合解任發起條件，等候社群投票重新確認管理員權限」兩個情況是適合直接凍結權限。
雖然目前尚無技術手段直接凍結管理員權限，仲委會仍可通過審議施行禁制權，臨時禁制當事人使用任何管理人員權限，違者亦可直接視作嚴重違規而符合除權條件即可。
不過如果是「凍結權限」，那麼就不是「解任投票」而是「重新確認投票」，重新確認投票的通過標準（此處指支持留任比率）或許要提高；反過來解任投票的通過標準（此處指支持解任比率）也需因應略微提高（例如55%）。--路西法人 2024年6月15日 (六) 00:56 (UTC)[回复]
How can you 「凍結」(maybe temporarily stop) VRT priviledge without removing them? What about Oversight? -Lemonaka 2024年6月15日 (六) 02:22 (UTC)[回复]
基本上都是需要通過暫時除權處理。使用行政手段如禁制也是可以等同凍結權限，違者即直接除權即可。--路西法人 2024年6月15日 (六) 03:15 (UTC)[回复]

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

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

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

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

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

設立教育佈告板

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

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

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

错误的投票者名单

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:管理員解任投票/Mys 721tx/第2次。

各位好。

Why 維基百科最忠誠的反對者（讨论 | 貢獻）, Mafalda4144（讨论 | 貢獻） and Boogi wu（讨论 | 貢獻） are still on the voter list? How will they become eligble for voting in current RFDA? ---Lemonaka 2024年7月1日 (一) 08:33 (UTC)[回复]

Google:为什么 維基百科最忠誠的反對者（讨论 | 貢獻）、Mafalda4144（讨论 | 貢獻） 和 Boogi wu（讨论 | 貢獻） 仍在 投票者名单 上？他们是否在当前 RFDA 中取得投票资格？---Lemonaka 2024年7月1日 (一) 08:44 (UTC)[回复]

按照惯例不会手动剔除这些人，这些人将由投票结束后监督员确认没有他们的投票，例如上次RFA2024选举的投票者名单phab:P62400，也有WMLO等被封禁人士。此外WMLO已经全域锁定，也无法投票。--桐生ここ★[讨论] 2024年7月1日 (一) 12:37 (UTC)[回复]
请注意，投票者名单不会手动剔除已公开的合规傀儡账号、机器人等，即使在名单上，但投票人仍只能选择一个账号进行投票，使用多个账号是违反规定的。--桐生ここ★[讨论] 2024年7月1日 (一) 12:40 (UTC)[回复]
若因改名等原因，合资格用户未能出现在投票人名单上，以至无法投票，请及时反馈。--桐生ここ★[讨论] 2024年7月1日 (一) 13:02 (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)[回复]

私自發布(懷疑自我原創)英國官員譯名

参见：Talk:凱爾·斯塔摩 § Victoria Starmer之譯名

最近適逢英國政府換閣，一系列官員的會有港式譯名，但需要等英國領事館發布。但我看到一些用戶，似乎急不及待的將自己相信的譯名發布出來。甚至我見到一些ip用戶，如14.198.208.124，甚至發布英國首相配偶、和子女的譯名。據了解，使館沒有發布這些人的譯名，或者媒體也未必會「創造」這些譯名，明顯是該用戶的私人原創。

我已經很久沒有在此活動，但這些行動似乎已經違反不能發布原創內容的規則，希望有關管理員能適當處置此事。--JéRRy ~ 雨雨 （留言） 2024年7月7日 (日) 07:08 (UTC)[回复]

设立编者著作权调查

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

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

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

取自“https://baike.710302.xyz/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”