跳至內容

維基百科:互助客棧 (全部)

維基百科，自由的百科全書
捷徑

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

按此重新整理頁面。

  歡迎光臨互助客棧！  
   
  互助客棧是維基人議事相助之處，用以討論消息、方針、技術以及編輯、求助等議題。
發表議題之前請搜尋先前文章，遵守指導及禮儀。任何與維基百科無關的問題，請前往知識問答。

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

檢視全部討論

幫助目錄 · 提出疑問 · wikitext基礎 · 常見問題 · 常見錯誤 · 佈告板 · 了解術語 · 即時協助 · 規則簡述 · 使用指南

If you don't use Chinese, and want to contact Chinese Wikipedia, please leave your message here.
我想要…… 請前往……
如何有效並安全地存取維基百科的方法 如何存取維基百科
與繁簡處理有關的問題 字詞轉換
協助或尋求條目的改善意見 同行評審
對某些特定來源的討論 可靠來源佈告欄
尋找參考文獻 文獻傳遞
參與即時討論或透過電子郵件進行討論 「即時討論」或者「郵寄清單」

消息

Edit check experiment results

Hello everyone

Sorry to use English. 請協助翻譯成您使用的語言. 感謝您。

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

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

What was found?

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

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

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

What is next?

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

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

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

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

批准維基媒體運動憲章的投票即將結束

您可以在元維基上找到這則訊息其他語言的翻譯。 請協助翻譯成您使用的語言

大家好，

謹此提醒您，批准 維基媒體運動憲章 的投票期將於2024 年 7 月 9 日 23:59 （世界協調時間）結束。

如果您尚未投票，請在此 SecurePoll 上的連結投票。

謹代表維基媒體運動憲章選舉委員會，

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

Wikidata weekly summary #635

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

Events

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

Tool of the week

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

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

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

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

Weekly Tasks

This Month in Education: June 2024

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

This Month in Education

Volume 13 • Issue 6 • June 2024

In This Issue

U4C Special Election - Call for Candidates

You can find this message translated into additional languages on Meta-wiki. 請協助翻譯成您使用的語言

Hello all,

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

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

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

Read more and submit your application on Meta-wiki.

In cooperation with the U4C,

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

This Month in GLAM: June 2024



Headlines
Read this edition in full • Single-page

To assist with preparing the newsletter, please visit the newsroom. Past editions may be viewed here.


方針

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

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

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

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

可以這樣本地化：

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

下列資料不應記錄：

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

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

個人感覺：「值得注意的」是重點，但不十分明確。短期內或頻繁的重播可能瑣碎，得到有效來源介紹的則可考慮。「除了特殊情況外」後面的語句可能仍需潤色，不好懂。「播放時間」如果有來源我覺得可以，但可能很多是查證不足。「下列資料不應記錄」第三條及之後的含義和用法我不太明白，或許應補充例子。建議邀請活躍編者，可預期存在反對聲音，另外它是指引，強制力在短期內可能不會很高，只能作為理由依據。--YFdyh000（留言） 2024年4月22日 (一) 07:56 (UTC)[回覆]
  • 「值得注意的」段落可以extend，但應如何extend則交由社群決定。
  • 「頻繁的重播」當然是瑣碎，難道要準確收錄何時重播？
  • 「播放時間」見下方解答
  • 「第三條及之後的含義和用法」，不是電視節目條目編輯者不明白是正常的。
最後那點，請參閱在Wikipedia talk:格式手冊/日本動漫遊戲 § 提議將WP:MOSACG跨媒體部分提升為指引的討論。--唔好阻住我愛國（留言） 2024年4月22日 (一) 09:26 (UTC)[回覆]
那之前疫情的時候部分作品由於製作原因推遲播出，算不算電視延後播放信息？而且這一段(如相關節目於中文地區有「代理發行」信息，則只可記錄可在該播放平台清淅辨認相關代理資料的網絡播放平台。(特別注意：日本電視動漫))應該要加上特攝作品的信息。(有部分特攝作品也會標註其代理信息)--馬哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 07:58 (UTC)[回覆]
第一點：想法是只記錄該集數最先出現的播放平台，例如「A節目在B平台的播放時間是0900，在C平台的播放時間是0930，在D平台的播放時間是1200…」，這樣寫實在太冗長及無謂。想法是「A節目於B、C、D平台上架。」
第二點括號內的是我個人想法，當然是不會加入條文之中。--唔好阻住我愛國（留言） 2024年4月22日 (一) 09:04 (UTC)[回覆]
第一個的話這個不反對(反正超級戰隊系列特攝作品條話一般都是按散文方式寫在哪一個平台上架不大受會受影響，但是假面騎士和奧特曼系列的話有可能會受到影響刪內容。)第二點的話就是說所有電視類條目都得遵守該規範嗎？--馬哈迪跟哈迪阿旺走的越來越近了。--老墨泡芙真好吃。 2024年4月22日 (一) 11:22 (UTC)[回覆]
總之曾在電視廣播的節目條目也適用。--唔好阻住我愛國（留言） 2024年4月23日 (二) 06:04 (UTC)[回覆]
依MOS:CHINA，修改為「這些可能包括：在中國大陸、台灣、」。--CaryCheng（留言） 2024年4月22日 (一) 18:21 (UTC)[回覆]
下一版本會更正。--唔好阻住我愛國（留言） 2024年4月23日 (二) 06:03 (UTC)[回覆]

版本2

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

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

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

版本3

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

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

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

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

版本4

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

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

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

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

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

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


現行條文

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

提議條文

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

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

上方討論太長未看全，就該版本的疑問（如已有結論，希望加腳註）：原產地之內的播放信息似乎被暗示可「不分青紅皂白地列出」。原產地的準確定義，範圍，聯合製作、外包、僅外銷等。很多字句應修飾，如「在有來源可靠的情況下」等，由於非定稿我暫時不全部列出。「網絡電視節目連結不合適作為來源」聽上去有點奇怪，有點像某個來源非公開可用（需登錄/部分地區/線下來源）就不適合作來源，可能意思需改善，比如不能訪問現象本身、無法存檔的網頁內容，不適合作來源。--YFdyh000（留言） 2024年5月1日 (三) 19:36 (UTC)[回覆]
@YFdyh000:
歡迎任何具建設性的修飾句子。--唔好阻住我愛國（留言） 2024年5月2日 (四) 11:07 (UTC)[回覆]
改為「原產地的首播資訊」就行，上面《還珠格格》就是限制播放資訊在「首播」。
YFdyh000提到的情況，我想起了近期一個例子《食草老龍被冠以惡龍之名》，日本輕小說，由中國大陸瀾映畫製作的動畫版在bilibili上首播（2022年7月），2023年1月才在日本電視台播出（[4]）（[5]）。這種涉及跨國版權的節目，「原產地」算中國大陸，還是日本。
早年中港、港台合拍劇也不少，不過都屬於「中文使用地區的」，所以反而沒有這些記錄爭議。--Nostalgiacn（留言） 2024年5月4日 (六) 01:35 (UTC)[回覆]

版本5

希望這是最終版

標題：播放資訊

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

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

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

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

「網絡電視節目播放連結不合適作為來源，因地區限制訪問，部分編者無法查核。」語序希望優化；地區性或可能失效的視頻的網絡播放源，有時是有用的，作為某些信息的一手來源，{{Cite AV media}}，但提供者唯一且無法存檔的確實不宜用。「網絡電視節目播放連結」被運用時如何區分，我擔心存在理解差異。
「個別」是「特定（某個）」嗎。「直接引用」，所以有間接引用嗎。建議可在、協商或評選、唯應，感覺語意重複。「關於能否引用特定播放平台的連結，可在本指引的討論頁商議，重點為著作權和可供查證原則」。
「準確播放時間」指的是實際播出時點、時長嗎，是否與下一條有重複。
「非偶發的延誤播放之信息」指什麼，已宣佈的推遲播放不宜記錄？--YFdyh000（留言） 2024年5月8日 (三) 08:51 (UTC)[回覆]
  • 對不起，不能使用「視頻」字眼，因實際應用場合不同，放在繁體字地區，意思截然不同。
  • 網絡電視是IPTV,網絡播放平台是OTT。
  • 「關於能否引用特定播放平台的連結，可在本指引的討論頁商議，重點為著作權和可供查證原則」，這個可以。
  • 沒有重複。
  • 意指不應收錄恆常延誤播放資訊。如果每一集也記錄為什麼延遲播放，那麼與電視指南有什麼分別？
--唔好阻住我愛國（留言） 2024年5月8日 (三) 10:31 (UTC)[回覆]
@YFdyh000、@Nostalgiacn、@Milkypine、@Cwek、@CaryCheng、@甜甜圈真好吃、@神秘悟飯:
如沒有特別大的問題，3日後將按照版本5進行公示。--唔好阻住我愛國（留言） 2024年5月10日 (五) 09:55 (UTC)[回覆]
我發現有些概念有待釐清，網絡電視目前英維對應是Streaming television，IPTV也可以翻譯做「網絡電視」。搞清楚條目內容和概念，可以更準確描述內容。Streaming television在描述上包括IPTV和OTT等情況。--Nostalgiacn（留言） 2024年5月10日 (五) 10:54 (UTC)[回覆]
沿用中文解釋及例子，因為這裏是中文維基百科。中文社群均認為OTT是類似Netflix, Disney+，甚至有播放平台以OTT自居，如myTV SUPER。更什台灣有OTT協會，大部分台灣網絡播放平台也加入了。--唔好阻住我愛國（留言） 2024年5月11日 (六) 00:33 (UTC)[回覆]
換句話說，除非有人重新整理該兩個條目至英維內容，否則再改也沒有意思。但是在中文社群而言，英維對OTT的理解是錯誤的。--唔好阻住我愛國（留言） 2024年5月11日 (六) 00:47 (UTC)[回覆]
(＋)支持。--CaryCheng（留言） 2024年5月10日 (五) 15:36 (UTC)[回覆]
——
3日內無反對聲音，現就版本5進行公示，公示7日至5月20日星期一止。--唔好阻住我愛國（留言） 2024年5月13日 (一) 03:25 (UTC)[回覆]
(＋)支持版本5。 --窩法乙烷 兒法夢碎 2024年5月16日 (四) 14:33 (UTC)[回覆]

方針研究

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

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

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

香港 2018年11月22日から2019年8月15日まで無綫電視翡翠台にて、『新幹線戰士』のタイトルで毎週木曜、金曜の17時20分-17時50分に放送。広東語 & 日本語二ヶ國語放送、繁體字字幕あり。 台灣 2019年3月31日から2020年9月13日まで東森幼幼台にて、『新幹線變形機械人』のタイトルで毎週日曜日、10時30分に放送。 --東姑阿都拉曼與賣華公會是出賣馬來西亞華人利益的罪魁禍首--甜甜圈 2024年6月26日 (三) 14:00 (UTC)[回覆]

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

版本6(分句公示)

標題：播放資訊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

是次討論重點如下：

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

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

討論內容如下：

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

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

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

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

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

5.只有正式譯名。

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

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

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

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

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

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

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

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

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

問題就來了：

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

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

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

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

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

註：此提案是基於Kizuna no Allele發現的bug，有中文名稱卻使用全英文字，有「妹大過主人婆」之嫌；而且Google TV首頁節目推介嚴重依賴維基百科譯名，電視語言設置為中文而電視IP在非中文地區的話，首頁的當地節目播放清單會改為顯示中文維基百科名字，非當地語言。故產生整合命名常規想法。--唔好阻住我愛國（留言） 2024年5月26日 (日) 11:18 (UTC)[回覆]
那對於有一些周邊產品的作品(例如特攝作品及部分推銷周邊玩具的動畫作品。)那周邊產品先出名稱的話那應該是周邊產品為準還是以作品本身為準？(兩岸三地通常是周邊產品先於作品本身推出)--LTA:LC99反對昌明政府的居心何在？。--老墨泡芙真好吃。 2024年5月26日 (日) 11:37 (UTC)[回覆]
「最先出現」原則。（依從維基百科:命名常規:先到先得）--唔好阻住我愛國（留言） 2024年5月26日 (日) 11:55 (UTC)[回覆]
當然是針對主題本身來命名啊，周邊展品只能算條目中的一個小節（製作/宣傳章節）……--For Each element In group Next（留言） 2024年5月26日 (日) 12:56 (UTC)[回覆]
但是很多周邊產品的名稱會影響作品本身的名稱。--東姑阿都拉曼與賣華公會是出賣馬來西亞華人利益的罪魁禍首--林吉祥 。 2024年5月27日 (一) 07:45 (UTC)[回覆]
所以說，條目命名以主題本身為準啊。就算周邊產品影響了，那條目還是依照作品本身來命名。只不過官方命名的緣由可能是「保持IP命名一致性」之類，這點如果需要介紹，可以在製作等章節說明。（其他條目也有談到官方命名的理由；只不過你說的這種情況太平凡，很少有來源介紹，所以沒什麼好寫的）無論如何，命名的根本原則還是針對主題自身。--For Each element In group Next（留言） 2024年5月27日 (一) 14:19 (UTC)[回覆]

意見：

  1. 提案時請在對應的頁面留言，指出該頁面正在被討論，並告知相關專題。真正關注該領域命名的編者，未必有閒心天天盯着互煮客棧。
  2. 命名以最細的方針為準。遊戲條目（或以遊戲為原作的系列條目），當然優先依照遊戲命名常規（遊戲#6）；如果是動漫條目（或以動漫為原作的系列條目），則不套用遊戲命名常規。我想這個應該都能理解，我也確實沒在這方面見過有什麼衝突。
  3. 「如X體中文名稱是最先發佈，則以X體中文為首，其後使用字元轉換工具新增Y體中文名稱」可以說是完全推翻了現行的命名常規精神：
    遊戲領域各地區用字平權。如果條目以A地區用字創建，則實體標題只在A地區的名稱（包括官方名稱和常用非官方名稱）中考慮；亦即不得以B地區的官方名稱為由，將A地的常用非官方名稱移動到B地官方名稱（中文命名規範#4）。這是遊戲命名常規基石之一，當初也將許多地區詞移動戰消滅在了萌芽之中，要改這點就等於徹底重建遊戲條目命名體系了。實體標題是內部維護作用（zh對外是隱藏的），給讀者看的還是最終的各地轉換標題。包括先到先得也好，命名常規的作用就是解決爭議（特別是地區詞爭議）；現在的方針實行有十年，我認為也確實解決了地區詞編輯戰的問題。
    「日本動漫遊戲條目」也有說「由於中國大陸地區代理作品機會較小，因此通常只需要確認譯名為最常用譯名（即第三項），而此譯名正常來說也是中國大陸地區順位最高的譯名（除非有更適合的譯名）。如條目適用的名稱符合上述譯名優先順序的使用規範（即該地區最適合的譯名），其他地區的譯名差異應以手動字詞轉換技術解決（即「先到先得」原則）」。不過仔細來說遊戲命名常規和日本動漫遊戲條目表述有點不同：如果編者以A地用字來命名，結果選了個既不官方也不常用的「錯誤」標題，按「日本動漫遊戲條目」要求，似乎不反對其他編者移動到B地的正確標題；但遊戲命名常規就明確規定，只能在A地的命名中重選一個😂
  4. ACG命名常規創立的一個前提是處理繁雜的命名衝突——此類作品在各地譯名往往不同，且即使在一個地區內，也會因為代理商的不同，有多個正式或民間的命名。遊戲條目主要是繼承了各地用詞互不干涉這塊，而且依照遊戲領域實際情況，也沒有搞「官方名稱」「正式名稱」那麼細。電視節目可能沒有太多可比性？

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

1. 目前沒有電視電影命名常規，如要通知的話應該是放在電視電影命名常規，而非日本動漫命名常規，因為日本動漫原則是不受影響。
2. 日本動漫、遊戲條目也不受影響，真正受影響僅限日本遊戲及電視電影條目。
3. 近年，日本動漫已有真人化趨勢（如高木同學、殭屍100等），如不與時更新手冊的話，遲早出事。
4. 既然ACG有手冊規管，而當中「A」的父系「電視節目」卻沒有規管，這未免怪怪的。--唔好阻住我愛國（留言） 2024年5月26日 (日) 13:07 (UTC)[回覆]
簡單來說，電子遊戲範圍以內可管理的繼續沿用電子遊戲規條，不過只是新增日本遊戲類別，此類別由「命名先後次序」原則改為沿用一般遊戲的「通用的中文名稱命名」原則。--唔好阻住我愛國（留言） 2024年5月26日 (日) 13:13 (UTC)[回覆]
電子遊戲的方針指引本來就規範所有的電子遊戲條目，包括日本的和非日本的。而現在維基百科:命名常規 (日本動漫遊戲條目)其實更像「日本動漫遊戲作品的地區詞與譯名處理原則」，本身沒有太具體的規則（例如OVA作品條目該用「OVA」還是「動畫」消歧義）？您的提案如果只是要擴大到其他領域那倒也無妨，但是您的提案相當與寫了一個和原方針幾乎完全牴觸的內容：原來的提案是「如果條目以一地的常用名稱創建，則其他編者不得移動到另一地的官方名稱」，而您的提案是「原標題已然合適的情況下，其他編者依然可以移動到另一地的官方名稱」。電子遊戲條目是繼承了現行原則的，您把原則內容都改掉了，那遊戲領域命名的命名常規又是依賴着什麼呢？
您是贊同維基百科:命名常規 (日本動漫遊戲條目)的理念，希望將這個原則擴大到其他作品領域；還是反對維基百科:命名常規 (日本動漫遊戲條目)的理念，希望重寫一個來取代；再還是您只是想讓影視領域也有一個命名方針，而沒理解維基百科:命名常規 (日本動漫遊戲條目)的理念和背景？您主張擴大適用範圍，但重寫方案又是一個完全相反的內容。我沒有理解您想表達什麼。---For Each element In group Next（留言） 2024年5月26日 (日) 13:39 (UTC)[回覆]
1.「只是要擴大到其他領域」：這個是理解正確的， 提案首句寫道「日本動漫遊戲條目」延伸至管理所有電視電影節目，並刪除與遊戲相關規條。
2. 現時兩本手冊沒有註明哪個媒介優先命名，有條目以遊戲命名，有條目以小說命名，也有條目以動畫命名，於是提議新增優先次序，方便之後處理命名爭議。--唔好阻住我愛國（留言） 2024年5月26日 (日) 13:59 (UTC)[回覆]
那麻煩您先在相關方針的討論頁留下通知，並告知所有受到影響的專題吧。（包括您認為受到規制和取消規制的）--For Each element In group Next（留言） 2024年5月26日 (日) 14:08 (UTC)[回覆]
通知了ACG Project, 和兩個受影響手冊。--唔好阻住我愛國（留言） 2024年5月26日 (日) 14:51 (UTC)[回覆]
3. 「原標題已然合適的情況下，其他編者依然可以移動到另一地的官方名稱」，這個想法是一半正確一半不正確的，這是依從「名從主人」方針，「如果一個條目所述的主體——人、物或可謂有「擁有者」之事，其擁有者或代表者的官方中文資料出現此主體的中文名稱，可優先考慮使用該中文名稱。」。
  • 但為避免產生大量落差及分別，遊戲條目／遊戲分段內繼續沿用遊戲手冊。
  • 新提案僅要求如該項目同時有電視及遊戲／電影及遊戲才適用於建議命名方法。這個命名方法目前是在中維是「不成文共識」，不過僅是「小說及動畫」類別。
--唔好阻住我愛國（留言） 2024年5月26日 (日) 14:16 (UTC)[回覆]
我們倆都是完全正確的 您強調的是命名總則針對一般條目的要求，而我表述的是ACG領域針對自己的實際情況制定的細節。有細節規則時，就按細節的規則來走（所以遊戲命名常規和ACG命名常規也不衝突）。
至於跨媒體的問題，我認為首先應該明確條目主題是什麼，也就是把定義句寫好。如果您是在介紹小說條目，那樣條目第一句就會是「《XXX》是20XX年發行的小說」，我們自然也就根據小說來命名（可能有先行熱身的動畫，但那不是條目的主題，只能放在宣發章節里）。--For Each element In group Next（留言） 2024年5月26日 (日) 14:35 (UTC)[回覆]
目前有不少日本小說沒有中文化，但有中文地區動畫代理商引入其小說改編的動畫，在這個情況下，現行中維做法是該條目標題以動畫為準。新提案是同時將這個做法成文化。--唔好阻住我愛國（留言） 2024年5月26日 (日) 15:04 (UTC)[回覆]
條目主題是小說，那條目當然應該把小說當成獨立的主題，走一遍命名常規。如果來源普遍接受動畫的名稱來稱呼小說，那小說自然會以該動畫的名稱來命名；如果小說的「常用名稱」與動畫的官方名稱不同，那當然應該以小說的常用名稱命名。官方名稱就不是最高順位，更何況條目的主題是小說而不是動畫，所以這個「官方名稱」和條目主題沒有直接的聯繫，因此這個做法從邏輯上講就沒法「成文」。遊戲命名常規在這方面有明確表述：「其他媒體作品譯名僅當遊戲無中文譯名時作為參考」（遊戲#5，粗體為本人所加）。這種方式在肯定了現在做法的同時，邏輯上也很自洽。--For Each element In group Next（留言） 2024年5月27日 (一) 13:53 (UTC)[回覆]
範圍以內可繼續沿用子手冊，唯誇範圍時應優先考慮使用父手冊（NC:名從主人）。
很明顯20年前的編輯者在達成共識時沒有考慮過這個問題--唔好阻住我愛國（留言） 2024年5月27日 (一) 14:15 (UTC)[回覆]
本身我沒有興趣大改這三個命名常規，在看到閣下的言論後，才發覺這三個命名常規有這麼多的問題。
1. 名從主人論：父常規提出的「名從主人」指引原來是不適用於子常規（動漫及遊戲命名常規）
2. 主賓關係：編輯者要在創建條目之先就要決定哪個媒介是主，哪個媒介是賓。訂立條目名稱時，如該條目主體是小說，就必須使用小說的譯名，即使小說沒有官方/正式譯名也應原創一個出來，如改編漫畫有官方/正式譯名，也應繼續使用小說的原創譯名，因條目主體是小說。—>除非定立完整的ACG/文學創作格式手冊，媒介主賓關係不是命名常規能處理的，既然閣下有這麼多的想法，靠您由0開始撰寫，畢竟子系列的電視電影格式手冊還未完成。
3. 不成文共識：實際上目前99%新建條目也採用我提及的方法定名，包括上方提及的絆之Allele，如需將這個「不成文共識」砍掉，恐怕需要花極大量時間重新審視近20年以內的建立的ACG條目有否滿足要求。
近期，中國短影音興起，中國人會在短影音分享ACG劇情，但往往也原創一個新譯名而不採用當地代理商的譯名，每集觀看次數以十萬起跳。
  • 按照ACG的6個次序的次序1，由於通用譯名不一，故不適用
  • 按照ACG的6個次序的次序2，由於常用譯名與正式譯名不一，故不適用。
  • 按照ACG的6個次序的次序3，條目最後會採用非常具「熱度」的原創譯名，到最後公眾就會質問這個條目是形容什麼的作品，為什麼我在正版平台找不到與條目相同名稱的作品？
--唔好阻住我愛國（留言） 2024年5月27日 (一) 14:55 (UTC)[回覆]
方針指引是用來解決問題的，主手冊是，子手冊也是。主手冊能解決問題就主手冊就夠，但主手冊覆蓋面太寬，未必能針對具體問題提出解決方案；如果有更好的解決方法，自然可以單獨提出子手冊。
即使是主手冊，「名從主人」作為「命名慣例」，比命名常規的「常用名稱」也低一檔。子常規也是常用優於官方。我只看到子常規是遵循主常規原則的。
「條目主體是小說」意味着我們要以小說為主體，套用命名常規原則來命名。小說沒有中文譯名的情況下：如果命名常規規定用原文那就用原文；如果命名常規規定可以參考系列其他作品，那就參考其他作品；如果命名常規允許生造一個，那就生造一個。但這不意味着，應該讓一個主題的名稱直接指向另一個主題的名稱上。
不成文共識又沒有寫到紙面上，請問怎麼砍，砍哪句話？另外我的表述是「其他媒體作品譯名僅當該作品無中文譯名時作為參考」和您表述的「最先出現」原則在很多情況下結果是一樣的，我沒明白這只是表述上的差異，還是邏輯上有根本不同。
我不熟悉其他領域作品的譯名情況。比如同為電視節目，我不熟悉「意大利電視新聞」和「日本電視動畫」的各地譯名情況是否一樣；同為文字作品，我不知道日本輕小說和《舞會之後》是否有區域間的，區域內官方和非官方的譯名分歧。我已經解釋了ACG領域的命名原則（和主手冊處理上所區別）。我贊同下方Ericliu1912的說法，您先分析一下「電視電影」領域的命名問題，看ACG命名常規是否適用於其他影視節目。如果比照ACG命名常規來操作，是否能解決當前的爭議？是否會勞心又勞力（比如涉及地區詞方面的移動，結果引來很多爭議）。
PS：ACG命名常規有兩個原則。一是常用優於官方；以前主手冊在字面上，常用和官方平起平坐，所以這個原則很有特色；但現在主手冊已經明確了兩者順位，所以這項就沒什麼特別的了。二是ACG命名手冊肯定了各地最優名稱平等，例如A地的常用名稱（沒有官方）和B地的常用兼官方名稱是平級的，不得以B地官方為由進行地區詞移動。從這個角度看，遊戲命名常規是繼承ACG命名常規的，依從遊戲命名常規就是依從ACG命名常規，沒有什麼衝突。--For Each element In group Next（留言） 2024年5月27日 (一) 15:35 (UTC)[回覆]
在完成「電影電視」前，優先解決ACG問題先。除非新常規完全不採用ACG方案及新常規成文化後即刪除ACG常規。
台灣及香港正式動畫名稱：她來自煩星 (2022年動畫)
中文顯示：福星小子_(2022年動畫)
香港區顯示：山T女福星 (2022年動畫)
按照目前常規，試評論一下這個標題有什麼問題。--唔好阻住我愛國（留言） 2024年5月27日 (一) 16:09 (UTC)[回覆]
「「條目主體是小說」意味着我們要以小說為主體，套用命名常規原則來命名。小說沒有中文譯名的情況下：如果命名常規規定用原文那就用原文；如果命名常規規定可以參考系列其他作品，那就參考其他作品；如果命名常規允許生造一個，那就生造一個。但這不意味着，應該讓一個主題的名稱直接指向另一個主題的名稱上。」
這個論點目前命名常規沒有要求，可在此一併解決。--唔好阻住我愛國（留言） 2024年5月27日 (一) 16:17 (UTC)[回覆]
這個作品我不熟，我不知道信息框填寫的內容是否正確。但如果信息框的內容無誤，且官方譯名「她來自煩星」不常用，那香港和台灣顯示標題符合命名常規，沒什麼問題。--For Each element In group Next（留言） 2024年5月27日 (一) 16:38 (UTC)[回覆]
只是稍微修正下（以免其他人誤會），所謂「她來自煩星」嚴格來說只不過是代理商羚邦集團的正式譯名，而非真正的官方譯名。所謂正式譯名其實是指代理商譯名，不能完全代表作品官方之命名，並如前所說即使在一個地區內，也會因為代理商的不同，有多個正式或民間的命名。而真正的官方譯名是像類似「多啦A夢」（多啦A夢）這種由原作者、其他持有原作品版權的公司、組織或其法定分支機構所訂定及公佈的中文譯名。--Wengier（留言） 2024年5月27日 (一) 16:53 (UTC)[回覆]
問題是，如要嚴格按照ACG命名規則，官方譯名的序號是「4」，通用譯名的序號是「3」，這個已是一個結構性問題問題，危及近10年來條目的命名習慣，必要時可能要每一個條目重新審視。--唔好阻住我愛國（留言） 2024年5月27日 (一) 17:02 (UTC)[回覆]
我覺得，有一定流通度的官方譯名（原作者譯名）應高於其它通用譯名。就以多啦A夢為例，「多啦A夢」（多啦A夢）是官方譯名，但在中國大陸、台灣等地亦常使用類似「機器貓」、「小叮噹」這樣的非官方譯名（出現於官方譯名之前），但條目仍遵循「名從主人」原則以官方譯名命名。即使不是ACG直接相關內容，其它條目如華特迪士尼公司也是以遵循「名從主人」的原則以官方譯名「迪士尼」來命名，而不是用諸如「迪斯尼」之類非官方的其它常用譯名命名。--Wengier（留言） 2024年5月27日 (一) 17:18 (UTC)[回覆]
您說的對。常用+官方（正式）譯名當然優於單純的常用譯名或單純的官方（正式）譯名。但這個「一定」實操上該怎麼判斷，我覺得社區條文和判例都不足夠。例如這個討論，「官方譯名」大概是「常用譯名」的一半，兩者搜索結果都是十萬數量級以上，這算不算有足夠流通度？最近我也提出過這個問題，「官方」這個標籤到底能加多少分？這還是得社群這個層面有個說法，具體領域才好執行。--For Each element In group Next（留言） 2024年5月27日 (一) 17:37 (UTC)[回覆]
以2006年標準，當年網絡不發達，不是每一個人也可以使用互聯網，更何況是一般個人在網上寫文章？
今年是2024年，互聯網已普及化，網絡撰稿員職業隨之誕生，在網絡上開帖發文已經很簡單，什至可以叫ChatGPT寫文。對此，有必要重新調整命名準則。
——-
優先考慮：棄用ACG命名規則，因為已經不合時宜。--唔好阻住我愛國（留言） 2024年5月27日 (一) 17:54 (UTC)[回覆]
討論方向：
1.定義條目主體賓體先(究竟條目標題應以小說/漫畫/電視電影為首)
2. 命名先後次序原則：
2.1 需要一個可量度的通用譯名準則（以搜尋器結果計算，還是討論區討論熱度）
2.2 時限性問題（參考山T）
2.3 名從主人常規是否更合宜或不合宜？
2.4 官方／正式／通用譯名使用先後次序
3. 是否同時處理角色命名問題？
4. 所有譯名是否需要附上來源，有沒有來源要求？
5. 小說沒有中文譯名的情況下：如果命名常規規定用原文那就用原文；如果命名常規規定可以參考系列其他作品，那就參考其他作品；如果命名常規允許生造一個，那就生造一個。
6. 中文優先常規是否更合宜或不合宜？--唔好阻住我愛國（留言） 2024年5月27日 (一) 18:07 (UTC)[回覆]
命名總則指出原則（常用名稱）高於慣例（名從主人）。這兩條規則原來是一個等級，正是2018年修正案提出劃分層次的，這等於說社群正是最近肯定了ACGNAME的思路……
ACGNAME和NCVG使用官方名稱的背書條款是NC:名從主人，但社群這個名從主人規則的也是個口袋規定：「……官方中文資料出現此主體的中文名稱，可優先考慮使用該中文名稱」。那到底什麼情況可以優先，什麼情況下優先也沒用？社群對此是否有初步概念？可否舉出一些臨界案例判定情況？至此，我成功地把鍋甩給社群，並且把想法傳達給po主了；再說下去就是車軲轤話了，我先撤了，各位繼續--For Each element In group Next（留言） 2024年5月27日 (一) 18:10 (UTC)[回覆]
同意以上說法，一個重點就在於「官方」這個標籤到底能加多少分。當然，要拿出很具體的量化標準也未必那麼容易，不太可能絕對化。但暫且在這裏拋磚引玉吧，比方說如果是「正式譯名」（代理商譯名），那麼搜索結果或許可以乘以1.5倍(左右)進行比較，而如果是「官方譯名」（原作者譯名），那麼搜索結果可以乘以2至3倍進行比較。類似這樣的算法和優先原則（當然可能還會有其它考量）。--Wengier（留言） 2024年5月27日 (一) 18:46 (UTC)[回覆]
我們好像忽視了「可靠來源譯名」…--唔好阻住我愛國（留言） 2024年5月28日 (二) 01:23 (UTC)[回覆]
或許可以這樣：如果某譯名是官方譯名或正式譯名，應該有可靠來源予以支持或證實。如果是非官方非正式的常用譯名，至少要有一個可靠來源支持（證實）該譯名的存在。然後再按之前所說的進行量化比較。而如果某作品沒有任何可通過可靠來源予以支持或證實的官方譯名/正式譯名/常用譯名，那麼只能儘量採用已被使用的譯名（即使只有非可靠來源使用該譯名）。--Wengier（留言） 2024年5月28日 (二) 02:02 (UTC)[回覆]
(＋)支持:現就此方向寫「虛構」常規。--唔好阻住我愛國（留言） 2024年5月28日 (二) 14:41 (UTC)[回覆]
次序：
1. 官方譯名/正式譯名/通用譯名/可靠來源譯名均一致
2. 正式譯名和大部分可靠來源的譯名相同，無官方譯名或官方譯名與其他譯名不相同。
3.大部分可靠來源的譯名（量化準則待定）
4. 官方譯名（中文）
5. 正式譯名 （中文）
6. 官方譯名（其他語言）
7. 正式譯名 （其他語言）
8. 通用譯名 （字幕組等非可靠來源使用的譯名 ）--唔好阻住我愛國（留言） 2024年5月28日 (二) 14:51 (UTC)[回覆]
如果該片商/代理商宣傳到位的話，去到3就可以停了。所有日本動漫於台灣地區到3便完了，因為台灣動漫平台巴哈姆特獲社群評為可靠來源。--唔好阻住我愛國（留言） 2024年5月28日 (二) 15:06 (UTC)[回覆]
一般而言可以落到4或之後只有以下場境
1. 於中文地區沒有關注度可言
2. 可靠來源之間對使用哪個譯名的分歧很大--唔好阻住我愛國（留言） 2024年5月28日 (二) 15:11 (UTC)[回覆]
上面所說的「2. 正式譯名和大部分可靠來源的譯名相同，無官方譯名或官方譯名與其他譯名不相同」，這個顯然也需要量化標準，特別是有官方譯名但與其他譯名不相同的情況下。官方譯名顯然有一定的優先度，至於具體量化標準，可參考之前所說的其搜索結果可以乘以某個因數（比如2至3倍）進行比較。--Wengier（留言） 2024年5月28日 (二) 15:33 (UTC)[回覆]
用「比例」是否更合適？回應「 2. 可靠來源之間對使用哪個譯名的分歧很大」，如果是一半可靠來源用A譯名，一半可靠來源用B譯名，只會造成移動爭議，與其有這樣爭議，為何不跳到下一項？又例如，如果該譯名於各可靠來源至少佔7成或更多，是否算有夠流足夠流通性？--唔好阻住我愛國（留言） 2024年5月28日 (二) 15:46 (UTC)[回覆]
用「比例」或「比重」來形容當然也不錯，像官方譯名與正式譯名之間的比重差不多可以是二比一。舉例說明，假設官方譯名和正式譯名同時存在，但一半可靠來源用官方譯名，一半可靠來源用正式譯名，那麼肯定是使用官方譯名。但假如說75%可靠來源用正式譯名，25%可靠來源用官方譯名，那麼應使用正式譯名。--Wengier（留言） 2024年5月28日 (二) 15:58 (UTC)[回覆]
主體：
A:如 條目主要論述 <小說>, 條目標題就以<小說>走上述程序。
B:如條目主要論述 B年份的作品, 條目標題就以B年份為中心走上述程序。
值得注意的是A及B的條目名稱可以不一致。--唔好阻住我愛國（留言） 2024年5月28日 (二) 14:58 (UTC)[回覆]
背景：
上一個使用「山T女福星」已是英屬香港時期，目前此條目的「主」是2022年改編動畫，而非20世紀的原作。
你試一下搜尋「山T女福星」，應該是沒有結果或結果不是指向2022年動畫。--唔好阻住我愛國（留言） 2024年5月27日 (一) 16:57 (UTC)[回覆]

如果小說的常用名稱是另一個與動畫不同的名稱，那自然以這個常用（但不官方）的名稱為準。相關媒體命名僅供參考，但不能作為直接命名依據。我認為這種表述邏輯上更自洽。--For Each element In group Next（留言） 2024年5月27日 (一) 13:53 (UTC) 另外有中文名稱卻使用英文字的問題，我在這裏談過，本質上還是社群命名常規總則對「常用名稱」和「使用中文」的優先度解釋不清。比如ACG方針指出「維基條目通常應以中文命名」，遊戲命名方針也規定「外文名稱比中文更為通用時方可使用外文命名條目」；這兩個原則都是依賴命名常規總則的，但現在社群在命名常規執行上就是一鍋粥，說實話這不是兩個領域方針應該解決的問題。--For Each element In group Next（留言） 2024年5月26日 (日) 12:29 (UTC)[回覆]

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

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

不用「影視」，用「虛構」，因為上方編輯者提出主賓問題。--唔好阻住我愛國（留言） 2024年5月28日 (二) 14:39 (UTC)[回覆]
如果針對Kizuna no Allele的話，這個原作是電視動畫，屬於ACG組，優先使用ACG的命名常規；ACG命名常規對於使用非中文名作為命名有一個例外：「容許非中文命名的例外情況：如正式譯名使用或包含原名英文，條目名稱可根據命名常規的原文常用規則沿用原名。」並且舉例了，請自行參照。ACG命名常規的制定似乎被電子遊戲更早，可能早期是有包括電子遊戲的適用，但既然有針對電子遊戲專類的適配，如果條目主體概念是純電子遊戲類的，可以優先適用電子遊戲的命名規則；如果主體概念是跨媒體模式（同時介紹原作及改編媒體），可以按照原作媒體優先來處理。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 00:54 (UTC)[回覆]
針對兩個問題：1.對於日本電子遊戲的話，電子遊戲的範圍小於ACG（ACG專題也是統管電子遊戲專題），所以優先按電子遊戲專題；2.類似的日本電視動畫劇集的範圍小於通常性電視劇集（通常性電視劇集可以包括不同地區的不同類型電視劇集，包括真人類等），所以優先按ACG專題（更何況劇集類命名規則沒成事）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 00:59 (UTC)[回覆]
對於對於現有的ACG的命名規則，G組有電子遊戲更小的對應命名規則；C（N）對應的書籍命名常規還沒成事，而且按照範圍的話，通用的書籍範圍比CN的範圍更大，不通用（另外，參考書籍關注度，有定向排除過（「暫不提供」）「漫畫、雜誌」等類似書籍，可能也存在這樣的問題）；A組現在規則也沒有明顯衝突地方。似乎這樣修改有點多此一舉。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 01:06 (UTC)[回覆]
連書籍、影視的命名常規都沒搞好，就肆意破壞現有已行的規則，這看上去不像是一個良好的提案。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 01:10 (UTC)[回覆]
現在是提議用ACG常規（框架）管「 書籍、影視」，上方已開始有想法。--唔好阻住我愛國（留言） 2024年5月29日 (三) 01:16 (UTC)[回覆]
如果覺得ACG的命名方式（更準確來說，是其理念）對於「書籍、影視」也合適的話，意見是應該推動後者定向規則的指定，移植理念，而不需要改動現有的規則（已定規則擴界可能會有更多意想不到的與已有條目例子不符的問題，並且會破壞現有規則）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 01:24 (UTC)[回覆]
No No No, 現在不是移植理念這麼簡單，單純「移植理念」已經不能滿足「主賓關係」問題，ACG常規沒有表明「主賓關係」，所以現正寫「虛構常規」，將包括管理條目名稱、分部標題、角色名稱、分集標題。--唔好阻住我愛國（留言） 2024年5月29日 (三) 01:31 (UTC)[回覆]
鬼叫現在中維「 條目名稱、分部標題、角色名稱、分集標題」也有各自的條目。--唔好阻住我愛國（留言） 2024年5月29日 (三) 01:32 (UTC)[回覆]
不建議在現有已使用的規則的概念上無限上拓。另外對於主體牽引的列表類條目的作品名部分應該考慮用一致性來與對應的作品主體條目關聯。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 02:14 (UTC)[回覆]
如果針對的福星小子_(2022年動畫)和福星小子，前者是改編動畫，後者是原作漫畫，基於這點，再套用規則來判斷命名次序，不過，可能要靠這個特定改編媒體創建或者拆離自原作條目時的命名一致性，如果可以的話，應該和原作的命名方式一致。這點或者可以考慮補充到ACG命名常規中。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 01:20 (UTC)[回覆]

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

現行條文

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

提議條文

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

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

然而並不符合中國大陸地區的情況。由於中國大陸存在先審後播的情況很多媒體基本上都會使用字幕組提供的翻譯名稱(尤其是代理商不宣傳以及未引進的低齡向作品)--東姑阿都拉曼與賣華公會是出賣馬來西亞華人利益的罪魁禍首--甜甜圈 。 2024年5月29日 (三) 04:34 (UTC)[回覆]
我們這不是有字詞轉換嗎？Sanmosa 人人皆王 2024年5月29日 (三) 04:39 (UTC)[回覆]
然而我指的是來源問題，而不是語言問題。--東姑阿都拉曼與賣華公會是出賣馬來西亞華人利益的罪魁禍首--甜甜圈 。 2024年5月29日 (三) 06:17 (UTC)[回覆]
所以「可靠來源的譯名」先於官方譯名及正式譯名。--唔好阻住我愛國（留言） 2024年5月29日 (三) 05:08 (UTC)[回覆]
所以有什麼必要改日本動漫命名常規？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月29日 (三) 04:57 (UTC)[回覆]
標準化「通用譯名」--唔好阻住我愛國（留言） 2024年5月29日 (三) 08:49 (UTC)[回覆]
「官方譯名及正式譯名」不就是一種「可靠來源的譯名」？而且還是考慮部分跨地區跨語種的平台的不普及性（可能某些極端案例下，華語使用範圍的平台沒有播放某部作品，而只有華文字幕組有譯製），依然應該以常用判斷優先。看不出這樣提高「可靠來源的譯名」的意義何在。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 06:32 (UTC)[回覆]
「譯名決定辦法」其實也確定不同地區的取名模式的優先序：先到先得，即可能台地區有一個正式譯名，大陸地區有一個通用譯名，如果兩者相同的話，適用序列2（台的正式譯名），如果兩者不同，原則應該適用序列3（大陸的通用譯名），（後一點不能確定）但可以遵從先到先得來搶坑。整體而言，通用的命名常規和細則ACG命名規範，一直都是通用（常用）優先，只是通用有可能和官方的一樣。類似的論述：Wikipedia:官方名稱——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 06:40 (UTC)[回覆]
「如果官方及代理商宣傳到位的話，可靠來源譯名相等於官方譯名及正式譯名」，如果官方等宣傳到位，這個名字不就成了通用名稱（常用）？那字幕組等另開名字就還是搶不到常用啊？你官方不給力不就是官方的問題嗎？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 06:44 (UTC)[回覆]
可能參考Wikipedia_talk:命名常規_(日本動漫遊戲條目)、WikiProject:ACG/譯名與命名/決議投票、WikiProject:ACG/有關正式譯名/決議投票、WikiProject_talk:ACG/譯名與命名，Special:重定向/revision/13760352（ACG命名規範建立前比較近的一版命名常規）、Special:重定向/revision/4002166（對應Wikipedia:格式手冊/日本動漫遊戲2006年的命名規範）時的討論意見。對於常用命名判斷的話，我認為可以參考搜尋引擎的量來推斷，如果某個特定名字相對其他名字在數量上足夠拉開數量級差距，並且有相關的符合可靠來源要求的來源引述過（可能是傳統媒體或專門資訊報道、或者研究文章等），則可以作為可選的通用（常用）名稱選擇；退而次至是非符合可靠來源（也就是類似字幕組的譯製名來源等）；再次至就是只看搜索量。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 07:07 (UTC)[回覆]
可不可以簡單點列閣下的次序？--唔好阻住我愛國（留言） 2024年5月29日 (三) 09:00 (UTC)[回覆]
？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 09:30 (UTC)[回覆]
是指通用名稱篩選策略：通過搜尋引擎等可以測定名稱使用量的機制，對特定（作品）命名的用詞的數量進行統計。如果某個特定名字相對其他名字在數量上足夠拉開數量級差距，並且1.有相關的符合可靠來源要求的來源引述過（可能是傳統媒體或專門資訊報道、或者研究文章等）；2.非符合可靠來源的來源（類似字幕組的譯製名來源等）引述過；3.無法確定，只能評價統計的數量級。優先選擇序列為1>2>3。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月29日 (三) 09:30 (UTC)[回覆]
換句話說，即「可靠來源譯名」優先？--唔好阻住我愛國（留言） 2024年5月29日 (三) 10:02 (UTC)[回覆]
官方譯名（原作者譯名）及正式譯名（代理商譯名）只要能被證實同樣是一種「可靠來源的譯名」。如前面的討論，官方譯名及正式譯名的話同時按一定比例加分，與普通譯名進行比較。--Wengier（留言） 2024年5月29日 (三) 18:50 (UTC)[回覆]
準確來說，是通過統計分析（方法不限，可以包括搜尋引擎測試）下，占常用優勢的，依次序優先下降是「有可靠來源引述的」、「『不太』可靠來源引述的」、「無可靠來源引述」，單純「可靠來源引述的譯名」並不夠，可能只是沒人用的「官方」或「代理」譯名。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月30日 (四) 00:13 (UTC)[回覆]
現行條文
  • 通用譯名（常用譯名）：該作品在某地或更多地方經常使用或普遍使用的中文譯名。其通用程度可以使用譯名的書籍冊數、出版量等來驗證，並須遵守Wikipedia:關注度所訂立的標準。
提議條文
  • 通用譯名（常用譯名）：該作品在某地或更多地方經常使用或普遍使用的中文名字／譯名。其通用程度可以可透過搜尋引擎測試等方式判斷，該作品的特定名字／譯名於搜尋引擎測試較其他名字／譯名在數量上足夠拉開數量級差距，並曾至少被一個可靠來源引述的可優先使用，另須遵守Wikipedia:關注度所訂立的標準。
--唔好阻住我愛國（留言） 2024年5月30日 (四) 01:29 (UTC)[回覆]
如改定義，則條文如下：
現行條文

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

提議條文

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

--唔好阻住我愛國（留言） 2024年5月30日 (四) 01:42 (UTC)[回覆]
正如維基百科需要列明來源，在這的次序可是二手（曾被可靠來源使用），一手（官方／正式），原創／來源不佳（字幕組）--唔好阻住我愛國（留言） 2024年5月30日 (四) 01:49 (UTC)[回覆]
我覺得舉幾個例子進行說明或許不錯，可讓大家看看其具體如何執行以及執行中可能出現的問題。至於二手、一手的順序，大體應該是如果二手能拉開足夠數量級差距時用二手，否則優先考慮一手。--Wengier（留言） 2024年5月30日 (四) 02:32 (UTC)[回覆]
完善「通常譯名（常用譯名）」的定義即可，但沒必要改動下面的判斷順序，因為應該一直以來「常用優先於官方」，嚴格來說，字幕組的發佈內容也算是（譯名的）一手來源信息。當時這個不考慮來源的可靠性也可能基於來源本身難滿足可靠來源的要求。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月30日 (四) 02:36 (UTC)[回覆]
貌似所謂「常用優先於官方」的原則只不過是「有時」，並僅限於維基百科中的部分內容。上面就說過「以前主手冊在字面上，常用和官方平起平坐」，可見並非「一直以來」都是這樣。再以華特迪士尼公司條目為例，其對話頁中顯然有部分使用者多次要求將其中的「迪士尼」改為「迪斯尼」（被認為在中國大陸更常用），但每次都被其他維基人以名從主人的原則拒絕。可見名從主人的原則對於這些條目命名之重要性。--Wengier（留言） 2024年5月30日 (四) 02:44 (UTC)[回覆]
但現時命名常規，常用是第一級的「命名原則」，名從是第二級的「主要命名慣例」，就好像美國的名從為「美利堅合眾國」、蘇聯的名從是「蘇維埃社會主義共和國聯盟」。而且過往命名常規版本下，常用也似乎一直壓着名從。根據應該一位老人Chiefwei所說（[9]），名從實際上2008年引入的（oldid=8766872），而且不是來自en的，ACG的命名規範是2006年確定的。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月30日 (四) 03:04 (UTC)[回覆]
說明一下，上面說的「官方」譯名不是指所謂沒人用的「官方」譯名，而是指存在一定使用度的官方譯名，雖然也許在所有中文譯名中僅排名第二。比如說非官方的某中文譯名的使用度為60%，而官方中文譯名的使用度為40%。兩者其實均為常用譯名，而前者為最常用譯名，後者則為官方+第二常用譯名。但兩者顯然並不能拉開足夠數量級差距。上面主要說的就是類似這種情況（即使是2005年的ACG命名規範的文氏圖顯然亦認為官方+通用譯名高於單純官方或通用譯名）。而不是說類似非官方的某中文譯名的使用度為90%，而官方中文譯名的使用度僅為10%之類的存在數量級差距的情況。閣下提到的老人Chiefwei所說的話，他自己承認「個人對這一條並不以為然」（表明為個人意見），同時承認「目前中文維基百科的命名常規確實是衝突的」。不同維基人顯然可能對命名常規存在不同理解，像華特迪士尼公司等條目就是典型的例子。--Wengier（留言） 2024年5月30日 (四) 03:27 (UTC)[回覆]
「一定使用度的官方譯名」，就是同時具有「通用譯名」和「官方譯名」/「正式譯名」兩個性質的名字，實際上這樣就屬於序列1、序列2的情況。現在來看，這部分除了完善「通用譯名」的定義外，沒需要調整選擇排序。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月30日 (四) 06:04 (UTC)[回覆]
更改定義後，整體多了2個選項。故有必要重新調整選擇排序。--唔好阻住我愛國（留言） 2024年5月31日 (五) 02:05 (UTC)[回覆]
而且
「3.只有通用譯名，或通用譯名和官方譯名、正式譯名不相同。此情況常見於先在網絡流行一段時間的作品，導致字幕組等非正式譯名較官方和正式譯名通用。此外也有其他原因導致官方和正式譯名不通用。在這個情況下，可按命名常規的使用事物的常用名稱規則使用通用譯名為條目名稱。
4.只有官方譯名和正式譯名。
5.只有正式譯名。
6.官方譯名、正式譯名和通用譯名均不存在時，應考慮在出現前述其中一種譯名後把條目移動至該名稱。」
寫到一舊舊咁（不清不楚），導致現行編輯者使用更簡單昜明的名從主人原則，GA上的條目標題也是以「名從主人」為依歸，而非「通用譯名」。--唔好阻住我愛國（留言） 2024年5月31日 (五) 02:11 (UTC)[回覆]
「 （不）含中文字符」這個說法好像有衝突或者不必要，因為原規則也聲明了「如正式譯名使用或包含原名英文，條目名稱可根據命名常規的原文常用規則沿用原名。」，下面也有舉類似例子，也就是翻譯後的名稱（舉例為官方性譯名，但不確定有沒涉及常用譯名的例子）包含外文「不譯」則保留「原文」。至於第三條的說法，後大部分是對於前面規定的一些補充解釋，核心是前面「只有通用譯名 | 或通用譯名和官方譯名、正式譯名不相同」，也就是存在一個譯名判斷為「通用譯名」，而沒有官方性譯名；或者存在官方性譯名，但其無法判斷為「通用譯名」的，選具有「通用譯名」性質的那個。其實看規則上面的文氏圖，就是看某個譯名具有三個屬性中的哪種，按照規則的指定歸屬和順序就是優選順序。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月31日 (五) 03:34 (UTC)[回覆]
又以「官方譯名」Kizuna no Allele作例，你認為 Kizuna no Allele 的排名是否應比 絆之Allele 高？--唔好阻住我愛國（留言） 2024年5月31日 (五) 05:32 (UTC)[回覆]
使用Google搜尋測試來看：「"Kizuna no Allele" -"絆之Allele" -"絆的Allele" -wiki -"维基" -"維基" -site:wikipedia.org」的索引量為203000，「"絆之Allele" -"Kizuna no Allele" -"絆的Allele" <排除词，略>」為303000，「"絆的Allele" -"絆之Allele" -"Kizuna no Allele" <略>」為6330，從數量級的話「Kizuna no Allele」，「絆之Allele」相近（雖然前者基本上都是英文的搜索內容），都近似常用，前者具有「官方」性質（也能使沒完全翻譯？），我認為根據規則來看，選「Kizuna no Allele」似乎也可以。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月2日 (日) 07:30 (UTC)[回覆]
問題是這裏是中文維基百科，而非其他文維基百科。論搜尋量來說，一定是外文比例佔優，但新定義如何確保中文地位為優先？--唔好阻住我愛國（留言） 2024年6月2日 (日) 14:22 (UTC)[回覆]
字幕組等中文譯名（只要有一定使用量，不管能不能找到可靠來源）應高於純粹的非中文名稱。--Wengier（留言） 2024年6月2日 (日) 15:41 (UTC)[回覆]
例如規則舉例Fate/stay night的說明（或者說Fate系列）。如果非要中文的話，那只能套用通用常規的「使用中文」命名原則（與「常用」同等）。（好吧，還有IBM、Google）——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月3日 (一) 05:55 (UTC)[回覆]
那麼，用第二個計算又如何？
  • 通用譯名（常用譯名）：該作品在某地或更多地方經常使用或普遍使用的中文名字／譯名。其通用程度可以可透過搜尋引擎測試等方式判斷，該作品的特定名字／譯名於搜尋引擎測試（並使用「所有中文結果」功能篩選）較其他名字／譯名在數量上足夠拉開數量級差距，並曾至少被一個可靠來源引述的可優先使用，另須遵守Wikipedia:關注度所訂立的標準。
--唔好阻住我愛國（留言） 2024年6月3日 (一) 11:08 (UTC)[回覆]
seems good，但是否保留「使用譯名的書籍冊數、出版量」這個判斷方式（雖然感覺是判斷官方的出版物，但是否也適用於其他紙質出版物的判斷，例如以前的資訊雜誌）。其實「Kizuna no Allele」對於例外規則也對不上：「如正式譯名使用或包含原名英文」，這個應該是官方譯名？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月4日 (二) 03:29 (UTC)[回覆]
按現行標準來說，使用「使用譯名的書籍冊數、出版量」已不合時宜。因書籍冊數及出版量只是傳統書才適用。對於近期興起的連載書及遊戲改編，完全不適用。
如以「書籍冊數、出版量」為標準，即提升正式譯名的地位。--唔好阻住我愛國（留言） 2024年6月4日 (二) 13:10 (UTC)[回覆]
「雖然感覺是判斷官方的出版物，但是否也適用於其他紙質出版物的判斷，例如以前的資訊雜誌」，當然如果認為現在基本上沒有紙質非官方出版物，避免和官方的定義重合的，也行。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月5日 (三) 01:21 (UTC)[回覆]
另外看了GA的評選上，好像也沒有提及明顯的命名要求，如果需要滿足規範，命名規範的話就是跟隨通用的命名常規和針對性的ACG命名常規。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月31日 (五) 03:40 (UTC)[回覆]
就是有ACG條目當選了GA而沒有以通用翻譯為依歸…--唔好阻住我愛國（留言） 2024年5月31日 (五) 05:27 (UTC)[回覆]
沒看懂？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月2日 (日) 07:30 (UTC)[回覆]
好像GA並有相關的限制？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月3日 (一) 05:55 (UTC)[回覆]

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

  1. 剛好相同如小說《群_(小說)》VS劇集《群_(電視劇)》
  2. 剛好不同如小說《獵魔人》VS遊戲《巫師_(遊戲)》
能一樣最好，但不一樣也不會怎麼樣。 --窩法乙烷 兒法夢碎 2024年6月5日 (三) 05:42 (UTC)[回覆]
《群》的舉例既不是ACG也不是電子遊戲；《巫師》或者適配電子遊戲組，但僅限於電子遊戲，另一個是普通小說，不屬於ACG（N）的輕小說範圍。當然，考慮這些本作條目及其改編媒體條目的命名一致性或者要考慮到。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月5日 (三) 06:06 (UTC)[回覆]
都談擴權了，就不特地找ACG正相關，但要找也是有啦，小說《All You Need Is Kill》VS電影《明日邊緣》。此外ACG（N）裏面的N比起輕小說更屬於小說吧，畢竟《十二國記》那年代誰會這麼分。 --窩法乙烷 兒法夢碎 2024年6月5日 (三) 06:37 (UTC)[回覆]
誰跟你談擴界啊¿ 還是前面說的，如果覺得ACG組的命名規範好的，可以將這套方案搬遷到其他主題，而不是擴界。其次ACG（N）也錨定以日式輕小說為主題，非日式小說體系的不歸ACG組管，自己找WikiProject:小說……哦，這個專題已經死了。WikiProject:文學、WikiProject:電影、WikiProject:電視……哦，半死不活的那種，大概。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月5日 (三) 08:06 (UTC)[回覆]
關於小說部分，最初錨定的是日式輕小說，但是也有一批日式傳統小說由於改編動畫、漫畫等，只能算是意外歸入（或者僅限於日式輕小說和改編動畫、漫畫過的日式傳統小說？）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月5日 (三) 08:18 (UTC)[回覆]
也就是像這些改編過動畫、漫畫的《十二國記》、《古籍研究社系列》、《小市民系列》、《UN-GO》的原作小說，算是傳統小說還是輕小說。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月5日 (三) 08:22 (UTC)[回覆]
畢竟輕小說標準過於靈活，有種寶可夢日常被開除JRPG的美。 --窩法乙烷 兒法夢碎 2024年6月5日 (三) 09:10 (UTC)[回覆]
不一定是這個問題，輕小說到將自己定性為「輕小說」的連載雜誌出現後，這之後的媒體題材就基本能確定，而且也有一些明確的判斷來源。至於之前的沒有這樣定性自己的作品的，是看本項目能不能接納。如果我對這個定義的話，傾向就是1.日式輕小說、2.被改編為日式動畫（包括動畫電影）、漫畫、電子遊戲、真人演繹媒體的日式或者日語原作傳統小說，可以歸入ACG專題協作管理。（真人演繹主要就是All You Need Is Kill和明日邊緣，山田君與7人魔女和山田君與7人魔女 (電視劇)……）——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月5日 (三) 09:51 (UTC)[回覆]
至於All You Need Is Kill和明日邊緣（Edge of Tomorrow），後者姑且能歸入ACG？或者對於ACG組來說，最近十年內的確多了一批西方資本購買日式ACG原作題材進行接近原作的改編或者徹底的新編，是ACG組過往少見的。（對於前面一對例子，姑且兩者的作品名字毫無關聯，題材上似乎大改不少，不提及估計不會認為後者是前者的改編）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月5日 (三) 08:18 (UTC)[回覆]
反方向也不是沒有，例如電影《哈爾的移動城堡》VS小說《魔幻城堡》。 --窩法乙烷 兒法夢碎 2024年6月5日 (三) 09:13 (UTC)[回覆]
ACG污染：要麼本身就是ACG範圍內，要麼其被改編媒體變成ACG範圍內。類似GPL。但感覺為了一致性扯遠了，未完全解決歸屬方式下這種衍生改編容易帶出更多問題。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月5日 (三) 09:40 (UTC)[回覆]
不然改用原教旨主義，只有ACG才是ACG。漫畫出廣播劇、動漫出原聲帶、遊戲聯名奢持品以及主題樂園都不算。 --窩法乙烷 兒法夢碎 2024年6月6日 (四) 02:27 (UTC)[回覆]
感覺還是扯遠和玩笑開多了。如果真要認真討論的話，還需要這幾個議題：1.N的範圍（基礎部分為日式輕小說，但因為被改編為日式動畫、漫畫等媒體的原作（可能不限於日文或日式）小說是否也納入）；2.真人演繹改編媒體的獨立條目（包括電影和電視連續劇）是否納入（主要是部分ACG（N）組內作品被改編為真人演繹作品，例如前述的《All You Need Is Kill》（有獨立條目）、《山田君與7人魔女》（有獨立條目）、《孤獨的美食家》（無獨立條目，不影響討論，暫時是）等，好像這不是罕見例子）；3.在解決前面歸屬問題後，再就是不同媒體下的獨立條目的命名一致性問題（例如原作為漫畫的《All You Need Is Kill》，其改編真人電影的《Edge of Tomorrow》，是否需要系列命名的一致性）；4.範圍「感染性」，就是前面一個小問題，被改編為ACG（N）組內媒體的獨立條目，如果存在對應的不屬於ACG（N）組的媒體的獨立條目，該條目是否也被納入組內協作管理（或者稱之為反向感染），正向感染似乎沒疑問，除非對類似《All You Need Is Kill》的例子有疑問。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月6日 (四) 03:10 (UTC)[回覆]
如果不納入組內管理的話，組外條目就自然不適用組內的規則，而且也不用考慮與組內條目的命名一致性需要。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月6日 (四) 03:12 (UTC)[回覆]

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

只更改定義並新增：

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

概念：

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

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

常用名稱本身就指的是可靠來源（而不是論壇或粉絲圈）中人、物或事項的常見的名稱，因此「至少被一個可靠來源引述」完全多餘——如果沒有可靠來源使用，這就不該叫作「常用名稱」。十來年前中維對來源可靠性的評估要求很低，所以那時候可能是來源都行；但現在逐漸注重來源可靠性，那之前關於「常用」的界說就極其粗糙了。而且關注度指主題獨立開設條目的資格，和條目起什麼名字無關。我想要改方針的話，那就直接按當今的標準改好。
不過借用其他討論中的一個論點，中維的基礎建設跟不上，大概執行時還是只能按以前的套路😂 而且當然中文圈在作品譯名方面，寧願生造硬編也不會像英文那樣用抄羅馬字兜底，這就的確很棘手。--For Each element In group Next（留言） 2024年6月5日 (三) 14:31 (UTC)[回覆]
「至少被一個可靠來源引述」僅用作參考來源及歸納網絡通用性。若沒有「一個可靠來源」證實，我說網上流行這個譯名就行了？--唔好阻住我愛國（留言） 2024年6月5日 (三) 15:07 (UTC)[回覆]
所以說，常用名稱本身就指的是可靠來源中的常用，而不是「網上流行」。完整來說「通用譯名（常用譯名）是指該作品在可靠來源中經常使用或普遍使用的中文名字／譯名」，沒有可靠來源使用的名稱連入局資格都沒有。入局的名稱就是pk可靠來源使用量，所以「一個可靠來源」也說明不了什麼問題--For Each element In group Next（留言） 2024年6月6日 (四) 13:03 (UTC)[回覆]
原定義僅指出通用程度只靠書籍出版量作定斷，隻字不提「可靠來源」。--唔好阻住我愛國（留言） 2024年6月6日 (四) 13:41 (UTC)[回覆]
嗯，正如您上方討論說的，十幾年足以讓很多東西變化；網路的興起與紙媒的衰落是如此，社群對條目命名等方針的理解也是如此。那按照今日的方針，原定義的內涵和表述是否還合適？畢竟在我看來，當年可能不講究，但今日我們都是按可靠來源說話，「某地或更多地方」這個表述預設就已經限定在可靠來源範圍內了。（除非您聲明包括論壇等不可靠來源在內）--For Each element In group Next（留言） 2024年6月6日 (四) 14:00 (UTC)[回覆]
那就變成回到我之前說過的：「通過搜尋引擎等可以測定名稱使用量的機制，對特定（作品）命名的用詞的數量進行統計。如果某個特定名字相對其他名字在數量上足夠拉開數量級差距，並且1.有相關的符合可靠來源要求的來源引述過（可能是傳統媒體或專門資訊報道、或者研究文章等）；2.非符合可靠來源的來源（類似字幕組的譯製名來源等）引述過；3.無法確定，只能評價統計的數量級。優先選擇序列為1>2>3。」或者說，我們現在還要不要接受以前那套不完全根據可靠來源來判斷這個事項。PS，一個作品的「常用名字」在愛好者間口口相傳，但就沒有中文的主流或者傳統媒體引用這個名字（或者無論哪個名字）關注或者詳細介紹，它在那，也不在那。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月6日 (四) 00:38 (UTC)[回覆]
1.官方譯名、正式譯名和通用譯名相同。
2.正式譯名和常用譯名相同，無官方譯名或官方譯名與其他譯名不相同。
3.只有通用譯名，或通用譯名和官方譯名、正式譯名不相同。此情況常見於先在網絡流行一段時間的作品，導致字幕組等非正式譯名較官方和正式譯名通用。此外也有其他原因導致官方和正式譯名不通用。在這個情況下，可按命名常規的使用事物的常用名稱規則使用通用譯名為條目名稱。
4.只有官方譯名和正式譯名。
5.只有正式譯名。
6.官方譯名、正式譯名和通用譯名均不存在時，應考慮在出現前述其中一種譯名後把條目移動至該名稱。
@Cwek:
按照閣下的計劃，連同上方原有的次序，應如何排列？還是完全放棄上方原來次序？因為閣下的提案多了三個選項。--唔好阻住我愛國（留言） 2024年6月6日 (四) 10:43 (UTC)[回覆]
我想，那三個選項是針對「通用譯名」怎麼判定的問題，不影響上方的原來次序。--For Each element In group Next（留言） 2024年6月6日 (四) 13:25 (UTC)[回覆]
就是這個意思。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月7日 (五) 01:09 (UTC)[回覆]

上方的討論也提到過，這裏的「通用譯名」是只能有一個，還是可以有多個（1個最通用+n個次通用）？如果可以有多個「通用譯名」，那這個問題應該能得到一個大家都滿意的結果：

  • 沒有官方（正式）譯名，大家都是第3檔，那自然「最通用」優於「次通用」
  • 如果有官方（正式）譯名，就會出現「次通用+官方/正式」（第1/2檔）優於「最通用」（第3檔的情況）

那現在的問題就有兩個：一、「通用譯名」如何界說？是直接嚴格規定「可靠來源」中的通用，排除論壇、實況主的用法（能執行多好另說），還是保持現在的模糊表述？二、「次通用」的門檻是什麼？例如相對用量方面，之前討論也提到過很多數字，1/2、1/3、1/10（數量級）。--For Each element In group Next（留言） 2024年6月6日 (四) 13:39 (UTC)[回覆]

數量級，以10的冪為一級，然後同級的話，按照同級有效值對比，例如10000比1000優先，9000比1000優先，5000比4000略優先，9200比9100略微優先（或者近似）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月7日 (五) 01:09 (UTC)[回覆]
至於判定來源上，有符合可靠來源的情況（包括傳統媒體、專門資訊網站等）優先，沒有的話則考慮非可靠來源（也就是民間字幕組發佈信息，愛好者交流信息等）的情況。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月7日 (五) 01:09 (UTC)[回覆]
那大致就是下面這樣？

通用譯名（常用譯名）：作品在某地或更多地方普遍使用的中文譯名（名稱）。原則上，應依據某地的獨立可靠中文來源，來判定譯名在該地是否通用。若可靠來源沒有形成使用慣例（如無可靠來源介紹主題），則編者可參考搜索量等資料，透過討論決定名稱通用性。條目應有一個最通用譯名，其他譯名在使用量上未與最通用譯名拉開數量級差距的，亦屬於通用譯名之列。

非可靠來源畢竟難登大雅之堂，方針上我就沒有明寫。另一個就是絕對數量的問題，雖然我上面留了個坑：如果只有惟一一個可靠來源提及了一個譯名，這個名稱到底算常用還是偶然 聳肩--For Each element In group Next（留言） 2024年6月7日 (五) 13:53 (UTC)[回覆]
這個可以，如果更改了定義，應該還可以處理Gundom問題，將Gundom系列重新列入本手冊規管。畢竟不可能為公平性而將Gundom系列而用英文表達（中文地區Gundom沒有通用性，只有鋼達／高達）。
是的，是用「搜尋量」決定通用性，如果「鋼達」使用率高就用「鋼達」，如果「高達」使用率高就用「高達」。--唔好阻住我愛國（留言） 2024年6月8日 (六) 10:40 (UTC)[回覆]
回應「 如果只有惟一一個可靠來源提及了一個譯名，這個名稱到底算常用還是偶然」，故建議先計算搜尋量，然後再找可靠來源補底。--唔好阻住我愛國（留言） 2024年6月8日 (六) 11:48 (UTC)[回覆]
我的意思是，不是由搜索量本身決定，而是參考搜索量決定。或者說先檢查可靠來源，可靠來源沒有慣例用法後，再找搜索量補底。再或者說，先統計可靠來源中的搜尋量，如果可靠來源（幾乎）沒結果，再放開到其他網站。您的理解和我的表述可能還是不同。--For Each element In group Next（留言） 2024年6月8日 (六) 14:20 (UTC)[回覆]
原來如此，可以。--唔好阻住我愛國（留言） 2024年6月8日 (六) 14:33 (UTC)[回覆]
另外，建議閣下同時參與下方WP:IS的討論，因為下方討論內容會影響本提案的這句（應依據某地的獨立可靠中文來源）應如何理解。--唔好阻住我愛國（留言） 2024年6月8日 (六) 14:42 (UTC)[回覆]

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

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

2.

現行條文
  • 通用譯名（常用譯名）：該作品在某地或更多地方經常使用或普遍使用的中文譯名。其通用程度可以使用譯名的書籍冊數、出版量等來驗證，並須遵守Wikipedia:關注度所訂立的標準。
提議條文
  • 通用譯名（常用譯名）：作品在某地或更多地方普遍使用的中文譯名（名稱）。原則上，應依據某地的獨立可靠中文來源，來判定譯名在該地是否通用。若可靠來源沒有形成使用慣例（如無可靠來源介紹主題），則編者可參考搜索量（並通過「所有中文結果」進行篩選）等資料，於條目討論頁透過討論決定名稱通用性。條目應有一個最通用譯名，其他譯名在使用量上未與最通用譯名拉開數量級差距的，亦屬於通用譯名之列。
現行條文

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

提議條文

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

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

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

大致如此，但還是不建議將這個特定專題的命名規則原地拓展到其他專題上。當其他專題（電視節目專題等）也想使用類似規則，可以移植條文。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月11日 (二) 02:15 (UTC)[回覆]
感謝支持，當然不會「原地拓展」。但因處理上方管理員的見解而頭痛，暫時沒想拓展方案。--唔好阻住我愛國（留言） 2024年6月11日 (二) 11:40 (UTC)[回覆]
另，更新了次序3的句子。@User:cwek--唔好阻住我愛國（留言） 2024年6月11日 (二) 13:56 (UTC)[回覆]
另，命名常規的話原來應該是NC:ACG（還有WP:ACGNAME）吧。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月11日 (二) 02:15 (UTC)[回覆]

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

seems good。但也仍存在部分作品沒有中文代理商，導致還是沒有官方性中文譯名。（好像本季度的Girls Band Cry的東映，好像連巴哈都沒有上線，雖然在B站上官方賬號有發佈過角色PV，作品名就是英文字型，角色名的假名字型不譯，嗯……）那個「等」字就當是也會考慮字幕組等蹭了常用度判斷的來源之一吧。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月12日 (三) 00:50 (UTC)[回覆]
按照新次序表，Girls band cry 可走到次序3的可靠來源部分，因為巴哈姆特GNN新聞有相關報導並使用「Girls Band Cry」一詞。
https://gnn.gamer.com.tw/detail.php?sn=261094--唔好阻住我愛國（留言） 2024年6月12日 (三) 11:21 (UTC)[回覆]
而「哭泣少女樂隊」是沒有可靠來源使用，故優先度次於Girls Band Cry.--唔好阻住我愛國（留言） 2024年6月12日 (三) 11:26 (UTC)[回覆]

ACG是專有名詞而ACN不是（？），可以考慮ACG重定向至ACGN，然後在頁面內添加「其中遊戲不在本頁面中敘述」之類的內容。--Leiem（留言·簽名·維基調查） 2024年6月12日 (三) 03:07 (UTC)[回覆]


公示版本

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

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

此規則之多數定義與條文於2006年ACG相關條目譯名、命名決議投票、相關討論及2024年通用譯名定義更新議案中獲得社群共識通過。

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

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

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

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

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

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

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

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

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

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

下方段落沒有任何更改

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

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

參考資料

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

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

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

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

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

與「電子遊戲」命名常規的補充

在翻閱Wikipedia:命名常規 (電子遊戲)時，裏面有一句「請在命名條目時遵守維基百科:命名常規和Wikipedia:命名常規 (日本動漫遊戲條目)」，但考慮到現在的修訂已經不覆蓋電子遊戲範圍，並且類似的討論已經提及過（Wikipedia_talk:命名常規_(日本動漫遊戲條目)#提請標題改為Wikipedia:命名常規_(動漫遊戲條目)）。所以追加認定現狀，就是Wikipedia:命名常規 (電子遊戲)不再保留「遵守Wikipedia:命名常規 (日本動漫遊戲條目)」的部分，並且本規則命名改為「Wikipedia:命名常規 (動漫條目)」或者「Wikipedia:命名常規 (日本ACN類附註：「動漫」也行條目)」（前者一個名稱會涉及擴大範圍）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月25日 (二) 10:04 (UTC)[回覆]

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

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

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

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

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

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

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

現行條文

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

提議條文

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

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

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

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

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

提議條文

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

  1. ^ 回退零容忍通常不應該為永久限制

建議可以修改一下用詞。--桐生ここ★[討論] 2024年6月9日 (日) 18:35 (UTC)[回覆]

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

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

提議條文

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

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

離題

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

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

反提案

LuciferianThomas版本

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

§ 標準措施 §§ 回退限制

現行條文

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

提議條文

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

§ 時長

現行條文

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

提議條文

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

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

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

Cmsth11126a02版本

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

§ 時長

現行條文

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

提議條文

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

§ 延長及重新確認限制

現行條文

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

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

提議條文

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

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

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

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

LuciferianThomas版本公示

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

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

管理操作覆核的議題

原標題為：提議設立請求封禁機制以及擴大AARV的使用

提議設立請求封禁機制以及擴大AARV的使用

我建議社群考慮設置類似「請求封禁」的機制，即對於非純破壞行為，有共識後再執行封禁，而非管理員獨自判斷引起爭議。

對於解封請求，我建議擴大WP:AARV的使用，申請人可以選擇請求任何一名用戶協助提出AARV，由社群進行判斷封禁是否適當。

提請各位討論，有關方針條文也請踴躍發表。--桐生ここ★[討論] 2024年6月14日 (五) 07:53 (UTC)[回覆]

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

將管理操作覆核設置為管理員佈告板的子佈告板

如題，見上方討論，將管理操作覆核設置為管理員佈告板的子佈告板，將作為集中處理涉及高階權限的使用行為。桐生ここ★[討論] 2024年6月29日 (六) 21:23 (UTC)[回覆]

或者是直接指定管理員佈告板本身也行吧？要評估一下流量。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月30日 (日) 04:13 (UTC)[回覆]
應該不行，管理員佈告板本身沒法提供那些AARV的規則。再說管理員佈告板本身也沒有人會去用，目前貌似只是一個為存在而存在的東西。--桐生ここ★[討論] 2024年6月30日 (日) 07:32 (UTC)[回覆]
其實也可說是「製造」用途⋯⋯ —— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月1日 (一) 19:21 (UTC)[回覆]

電視劇演員名單序列

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

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

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

正式提案

現行條文

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

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

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

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

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

可能要重點說明相關演藝人員的名氣是不影響演員序列。舉例以「香港頂流」炎氏作例，倘若他在節目只有一句話，不應因為名氣而把他置頂。--唔好阻住我愛國（留言） 2024年6月28日 (五) 16:36 (UTC)[回覆]
(－)反對增列的內文基本是根據其他帳號發言，加入了原發言者未提及的文字
  • 句子應該精簡後改成若對單一作品的官方名單有合理質疑，可發起討論。討論應參考更多WP:可靠來源。若達成共識，可不受前列條文限制。這個文字避免了對原發言的過度解釋，文字也概要的提及WP:共識精神。已經符合WP:可靠來源的項目，不應該再有篩選/排除的狀況(這是針對更多官方以外文字)，重要的是WP:可供查證精神(WP:ABOUTSELF第5項，WP:斷言、WP:REFNOTTRUE)
  • (～)補充這個議題大致上屬於WP:ABOUTSELF第4項的討論範疇
--Rastinition（留言） 2024年6月28日 (五) 23:55 (UTC)[回覆]
同Rastinition。某些「官方」來源可能對排名作出詳細解釋，不應排除。--YFdyh000（留言） 2024年6月29日 (六) 02:30 (UTC)[回覆]
@Rastinition@YFdyh000，但我仍希望在「討論應參考更多WP:可靠來源」之後，具體強調要注重該些來源的「演員序列，及對個別角色的戲份、演出性質之描述」，亦同意HK5201314君的意見，即強調「避免演員序列被演員的名氣所影響」。兩位覺得如何？--Factrecordor（留言） 2024年6月29日 (六) 14:42 (UTC)[回覆]
避免名氣影響，我覺得是避免淪為宣傳工具，但這可能不是中立的觀點、非原創研究所推薦。因為以其他特定標準來呈現和調整，可能不滿足這兩項，也較難得出公認的一致的合理標準，也許還不如給原列表加腳註。--YFdyh000（留言） 2024年6月29日 (六) 16:58 (UTC)[回覆]
那麼@HK5201314君有沒有進一步回應？--Factrecordor（留言） 2024年7月1日 (一) 10:51 (UTC)[回覆]
不知道為什麼，我想用TVB愛回家作例，話說當年楊明剛剛被TVB解凍，他獲解凍後出埸的第一集，對白有超過10句，但TVB的操作是把他放在演員序列中最後一個。
什至，中國大陸常常封殺「不道德演員」，做法是打碼／打格仔，並刪除該演員資料。
如按照現行做法，是完全不尊重「不道德演員」及「剛解凍演員」，並違反中立原則，因為現行做法完全偏向製片商。--唔好阻住我愛國（留言） 2024年7月1日 (一) 11:30 (UTC)[回覆]
所以建議新增如有任何爭議，可按可靠來源介紹量／文章多寡決定演員序列。--唔好阻住我愛國（留言） 2024年7月1日 (一) 11:32 (UTC)[回覆]
按文章量不可行，計算結果是原創總結（哪些來源算，如何去重，數量平手，情況改變），也同樣容易操縱（爭議人物排第一）。--YFdyh000（留言） 2024年7月1日 (一) 15:19 (UTC)[回覆]
如果是「角色介紹量」呢？我不信只有一句對白的角色就有一整篇文章介紹該角色特性。--唔好阻住我愛國（留言） 2024年7月2日 (二) 12:14 (UTC)[回覆]
潤筆費給足，吹噓解讀不用愁。如果是重要角色或明星，但播出版本全剪掉了，又怎麼辦。別自定標準了，見下。--YFdyh000（留言） 2024年7月6日 (六) 13:59 (UTC)[回覆]
我相信閣下有能力判斷何謂「可靠來源」。--唔好阻住我愛國（留言） 2024年7月6日 (六) 15:50 (UTC)[回覆]
寫成看不出來不難，包括以量取勝。--YFdyh000（留言） 2024年7月7日 (日) 02:57 (UTC)[回覆]
當初會建立指引，就是為了防止每個用戶依據自己所認定的來進行排序，進而引發編輯戰。同時，還必須考慮到歐美劇常有主演退出的情況。另外，有些戲之所以會將看似客串的演員列為主演，可能是認定其角色在某個階段吃重，比如《黑道律師文森佐》的劉宰明，前三集是主演，但角色死亡後，第四集變成客串，可是不會因此推翻他在前三集是主演的事實。又，報獎策略出現的主配問題，例如《一把青》的排序是天心、楊謹華，但獎項競賽卻是楊謹華報名女主角、天心報名女配角，列入這些情況太過繁雜。
所以最好的方法，就是撇開個人模糊的「實情」認定，不論是劇情編排轉變，還是宣傳手段與否，盡量依據官方或可靠來源為準，主演寫誰就是誰、客串是誰就是誰，這樣可以避免自行量化、計算，而導致涉及原創研究的問題。其餘的，可以用可靠來源來補足，例如陳豪雖然被列為主演，但其偏向客串性質云云、演員被刪除的原因等等。--Sa Young Sun（留言） 2024年7月5日 (五) 19:41 (UTC)[回覆]
現實的影視作品中片尾的演員排列表為了避免演員爭大爭小的問題，出現了按年資序、筆劃序、拼音序、出現序的各種做法。日本甚至形成了自己獨特的排列方式，一些佔相當大戲分的演員反而是在最後的。所以引進外國的時候，引進方經常是會隨意調查番位的。您維非得將爭大爭小的問題變成編者自己爭論的問題，這顯然是不合維基百科的非原創研究精神的。--Ghren🐦🕛 2024年7月12日 (五) 16:43 (UTC)[回覆]
日本應該是跟美國類似。美國會把比較大牌、資深（但可能戲份不及主角）的演員，用with、and排到最後，例如《嘻哈帝國》、《小謊言 (電視劇)》（[10]）、《柏青哥 (電視劇)》（[11]）等，韓國現在也會用「그리고」把演員排到後面。日本的話，還包含他們對「主演」的定義稍稍嚴格，所以有些戲份多的，才會排到最後。所以，建議依照官方排序，省得去解析with、and這些情況。--Sa Young Sun（留言） 2024年7月14日 (日) 15:18 (UTC)[回覆]

提議修訂著作權驗證模板與提報侵權流程

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

前一段時間我重新看了下著作權驗證模板的一些問題（在之前的討論中提及過，不再重複具體描述），發現到此模板還是只能按全文處理。至於英文版，這個模板已經於2023年8月-10月進行了改版討論，同時發現到該模板可以按全文或段落處理。相比而言，英文維基對著作權驗證的處理更為靈活，而中文維基依舊按全文處理，顯然過於死板，以至於某些人會覺得這是「過度使用」。尤其是涉及到影視類條目，過去一段時間看到涉及「劇情」部分侵權，還是按全文處理，確實是不靈活的。特別是2024年2月因為我寫的大江大河之歲月如歌「劇情」一節涉嫌侵權，一開始就說提報人不合理，之後就被無限期封禁，到現在看還是相當無辜，如果當時發現到模板有問題就可能不會有後來的事。

因此，我提議對著作權驗證模板進行重大修訂改版。主要的修訂要點：參考英文版的模板設計，採用條目消息框的樣式，更直觀、更清楚地傳達這是一個與刪除相關的問題，重新排列層次結構；根據實際情況，保留「如何解決」和「提示」部分，刪除提報人的簽名（在「疑似侵權」列表已有簽名，不必要在模板重複使用此欄，其他刪除模板也未見提報人的簽名欄）。與此同時，我將對提報侵權流程進行修訂（主要增加涉及新創建條目段落文字侵權的處理步驟）。

提議新模板設計

以下是我提議的新模板設計：


用字調查：是用「驗證」好還是「調查」好？

借鑑了下英維對應模板使用的是「調查」（investigation），而中維用的是「驗證」。在此我做一個調查，就是問下新模板是用「驗證」好還是「調查」好。

提議修訂提報侵權流程

配合模板的改版，本人提議對提報侵權流程作修訂，建議的程序如下：

疑似侵犯版權條目的處理步驟
條目有 未侵權的歷史版本 時
  1. 回退頁面到未侵權的版本。
    侵犯版權的內容仍然會保留在頁面歷史，如果最新版本不侵權但歷史版本侵權，可直接執行第3步。
  2. 在張貼侵犯版權內容的貢獻者對話頁中加入以下的文字：
    {{subst:Uw-copyright|條目名稱}} -- ~~~~
  3. 向 Wikipedia:修訂版本刪除請求 提報修訂版本刪除。
如果 當前的修訂版本 某一段落侵犯了版權
  1. 將下面的模板放置在侵權文本上方。將下面模板中的「來源」改為相應的原文本的網址或其他的來源。（注意：搜尋器結果不能作為來源）
    {{subst:Copyvio/auto|url=
    * 来源1
    * 来源2
    }}
  2. 將下面的模板放置在侵權文本下方。
    {{subst:Copyvio/bottom}}
  3. 在今天的疑似侵權部份加上：
    {{subst:CopyvioVFDRecord|條目名稱}}
  4. 在張貼侵犯版權內容的貢獻者對話頁中加入以下的文字：
    {{subst:CopyvioNotice|條目名稱}}
如果 所有的修訂版本 都侵犯了版權
  1. 如果原頁面內容符合其他快速刪除的標準的同時又侵犯版權，則應當先按快速刪除處理。
  2. 如果該頁面是一個主頁面侵權後建立的草稿頁面，請直接提交快速刪除（G16）。
  3. 將原文全部移走，用下面的模板取代。將下面模板中的「來源」改為相應的原文本的網址或其他的來源。（注意：搜尋器結果不能作為來源）
    {{subst:Copyvio/auto|url=
    * 来源1
    * 来源2
    }}
  4. 在今天的疑似侵權部份加上：
    {{subst:CopyvioVFDRecord|條目名稱}}
  5. 在張貼侵犯版權內容的貢獻者對話頁中加入以下的文字：
    {{subst:CopyvioNotice|條目名稱}}

技術問題

因為此模板是可以用Twinkle提報的，所以修訂就涉及技術上的問題了：整篇條目侵權可以用Twinkle提報，那如果引入段落侵權機制的話，Twinkle如何提報？如何定位我所需要的侵權段落？希望能有精通技術的人參與討論。--Shwangtianyuan 不忘初心 牢記使命 2024年6月21日 (五) 16:36 (UTC)[回覆]

用戶界面層面應無問題，可以列出和選擇章節，或者給章節加按鈕。另就上一節，調查可能比驗證更深入，比如複製自網頁但文字是公有領域，或者來自維基百科但未正確署名。--YFdyh000（留言） 2024年6月22日 (六) 06:38 (UTC)[回覆]
也是，我之前就碰到過某年度中華人民共和國政府工作報告條目，文字來源是中國政府網，但其網頁記錄的是政府工作報告全文，嚴格來說這屬於公有領域。因此根據閣下意見，稱呼調查比驗證更準確。--Shwangtianyuan 不忘初心 牢記使命 2024年6月22日 (六) 14:53 (UTC)[回覆]
@Shwangtianyuan：是否計劃公示此案？Sanmosa 蚌埠 2024年6月29日 (六) 15:31 (UTC)[回覆]
可以的。--Shwangtianyuan 不忘初心 牢記使命 2024年6月29日 (六) 15:33 (UTC)[回覆]
現公示提案7日。Sanmosa 蚌埠 2024年6月29日 (六) 15:37 (UTC)[回覆]
因應下方意見中止公示期。Sanmosa 蚌埠 2024年7月5日 (五) 07:33 (UTC)[回覆]
我提一個技術上的小問題：不應該直接替換{{Copyvio}}的功能（保留原有功能），也就是將段落侵權的新代碼另外新建模板，如{{CopyvioSection/top}}和配套的{{CopyvioSection/bottom}}。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月2日 (二) 02:35 (UTC)[回覆]
url參數應該單列一行，而不是作為行內部分。可能存在列出多個侵權來源信息，需要列項顯示。用語方面，原有是「頁面正在進行版權驗證」，所以對應段落的版本應該也是類似「本段落正在進行版權驗證」而不是「有編者已就此條目發起著作權調查。正在調查的文本目前已隱藏，」。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月2日 (二) 02:39 (UTC)[回覆]
@Shwangtianyuan。Sanmosa 蚌埠 2024年7月5日 (五) 07:32 (UTC)[回覆]
技術上的問題我並不是太懂，希望能有其他精通技術的人前來討論。--Shwangtianyuan 不忘初心 牢記使命 2024年7月5日 (五) 07:41 (UTC)[回覆]
（不好意思，最近才稍稍有時間處理一下這邊的問題）@Cwek。Sanmosa 蚌埠 2024年7月13日 (六) 01:31 (UTC)[回覆]

其他

好像針對段落的侵權，現時做法是直接刪掉+RDD，沒有考慮過按段落重寫的問題。或者在這個原有邏輯上，添加額外的段落標識+草稿重寫來處理。原有的全文流程還是保持不變。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月22日 (六) 00:43 (UTC)[回覆]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我相信管理員在調查破壞者是否玩弄社群時會參考破壞者的貢獻記錄，看看是否達到「儘快」要求。--唔好阻住我愛國（留言） 2024年7月3日 (三) 15:14 (UTC)[回覆]
@Ericliu1912@Factrecordor@LuciferianThomas@YFdyh000:三日後無反對意見的話就開始公示這個版本。--唔好阻住我愛國（留言） 2024年7月12日 (五) 11:05 (UTC)[回覆]
您不能只要求「質疑者」詳細說明該論點的不足，還要提出可接受的建議這樣子。「提案者」和「質疑者」兩者的責任並不相稱。而且「可接受的建議」也太主觀，也不合適。質疑者沒有必要教提案人如何寫好方針好嗎。--Ghren🐦🕛 2024年7月12日 (五) 16:52 (UTC)[回覆]
遊戲維基社群也屬於主觀規條。
正如路西法人道「 缺乏論證的觀點本來就不屬於可供參考的意見」，不能單單一句「我不同意這個回覆」而影響整個討論。--唔好阻住我愛國（留言） 2024年7月13日 (六) 01:18 (UTC)[回覆]
請問Ghren在說天秤兩邊重量不成比例，導致共筆版本傾斜於提案方的問題嗎？即使想釐清正當合理的狀況，但要其他人質疑來決定正當合理與否，此舉潛在默認了沒有受到質疑的回應。 -- 月都 ※ 2024年7月14日 (日) 16:10 (UTC)[回覆]
我們在編輯某些條目，察覺一些方針需要制訂或修改，卻不一定常涉足所有受該方針影響的範疇，先反思影響範圍，再看看哪些用戶經常活躍於箇中話題，邀請討論，所有潛在疑問可能在兩三星期內就能被大家想出來了，可以集中解決。若不這樣做，往往有個人偶爾路過，又放下一個疑問，自然無休無止。就算你曾經順利通過提案，也只是你的一時幸運，而你的幸運不一定是維基之福。--Factrecordor（留言） 2024年6月26日 (三) 13:01 (UTC)[回覆]
「偶爾路過，又放下一個疑問」，這個絕對支持，唯該路人是不是應該負起責任，主動跟進自己問過的疑問，如有需要，應儘他能力以最快時間進行追問，避免社群其他成員無限的等待，這對提案者絕對是一個折磨。--唔好阻住我愛國（留言） 2024年6月26日 (三) 13:13 (UTC)[回覆]

關於視頻平台能否作為一手來源的困惑

由於有兩個用戶因為在編輯澳視澳門台相關條目時(Special:PermaLink/82462720)，對條目的原創總結以及B站影像資料能否作為來源的問題而引發爭執。想問一下視頻平台的影像資料及動態信息能否作為一手來源？--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年6月30日 (日) 13:35 (UTC)[回覆]

沒找到爭議，請列位置。已認證賬號發的內容可能作一手來源，引用價值和方式需具體評估。--YFdyh000（留言） 2024年6月30日 (日) 15:50 (UTC)[回覆]
已經補上了。(事後才在討論頁說明User talk:YouTube zou zou)--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年6月30日 (日) 22:06 (UTC)[回覆]
未見涉及條目中來源。如果前後都無來源，請求來源或者全部移除。--YFdyh000（留言） 2024年7月1日 (一) 05:15 (UTC)[回覆]
我記得日語維基百科那邊是禁止使用視頻中的內容作為參考來源的，中維這邊不太清楚有沒有類似要求。——— 紅渡廚（留言・貢獻） 2024年7月3日 (三) 02:23 (UTC)[回覆]
@紅渡廚不過之前在日維的決鬥大師條目中看到了有用戶使用YouTube的視頻連結作為參考來源。--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年7月9日 (二) 22:02 (UTC)[回覆]
你這話說的。。。。中維還有人不加來源呢，你能因此說不加來源是中維的方針嗎。--——— 紅渡廚（留言・貢獻） 2024年7月9日 (二) 23:34 (UTC)[回覆]
只是吐槽一下原條目內的原創總結。(官方的生放送視頻只提及動畫將於當月底完結並未提及不會再有新動畫作品。)--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年7月11日 (四) 04:53 (UTC)[回覆]
我記得沒有完全禁止，有要求限制而已，官方驗證媒體帳號，自行出版物與可疑來源中的材料可以用作說明其釋出者（如某人、組織或其他實體）或該來源自身資訊的參考來源，通常在釋出者相關條目或以該來源本身為主題的條目中，而不要求是由該領域的專家發表，只要：
  1. 沒有過度的自我宣揚；
  2. 不包括針對其他人、組織、實體的主張或觀點；
  3. 不包括與主題無直接關聯事件的主張；
  4. 來源內容的真實性未受到合理的質疑；
  5. 不是條目主要的來源。

這一方針同樣適用於社交網絡上的內容，如Facebook、Twitter、人人、微博等，但建議不要經常使用，有更好就使用更好--HYHJKJYUJYTTY（留言） 2024年7月3日 (三) 02:40 (UTC)[回覆]

關於Wikipedia:格式手冊/列表#條目內嵌入人物列表的收錄標準的問題

緣起：近期，U:向史公哲曰挨個移除城市條目中著名人物章節的內容，統一替換為{{Category see also|XX人}}，即使寫成散文體，也難免劫難。向君有言「這種敘述看似是散文體，實則是換皮列表。如有意見，請去互助客棧指出」。向君所據，概為Wikipedia:格式手冊/列表#條目內嵌入人物列表的收錄標準，然此僅一指引，加粗有注一般應該儘量遵守。先不談直接對優典條目動大刀合不合適，也不談事前不與主編商議直接上手刪內容禮不禮貌，再不談「我認為這是換皮列表，這就是列表，刪除之」的做法妥不妥當。在此河某隻想請教一個問題：散文體編寫的著名人物章節是否違反此指引，如違反，著名人物章節要怎麼寫？

回顧：「行政區劃條目，禁止嵌入本地出身名人之類的列表」這一指引，出自2019年9月底的討論Wikipedia talk:格式手冊/列表/存檔2#提議新增「條目內嵌入列表的收錄標準」。此鮮有編者討論的提案快速通過，2019年12月即有編者疾呼「直到今天我才知道，Baomi方案竟然作為共識修訂案通過了」，另一編者同月一度試圖重啟討論廢除此案。

想法：

  • 關於「列表」：禁止條目內嵌列表的初衷，想必是列表內容冗雜，嵌於條目中有礙閱讀，影響條目質量云云。河某認可此說，禁止大型列表嵌入條目是有必要的，不過寥寥數行的嵌入式列表放置在必要位置並不會影響條目質量。個人不反對點列式編寫著名人物章節，但更偏向於散文體，不認可用「列表」展現，視覺上太奇怪了。
  • 關於城市/政區的「著名人物」章節：當代網絡百科的城市政區條目體例很大程度上沿襲自方志，方志人物誌有傳、錄、表等體裁。著名人物按類型又可以分為鄉賢、卓行、忠義、宦績、孝友、列女等，是對志書在地影響深遠或為人稱道的人物，也是地區文教禮化的表現，在志書中必不可少。優秀的百科條目，應當給予讀者恰到好處的信息，著名人物應該有，附帶一句話或幾個字的簡介，列出的人物數量不能多不能少，視情況而定。關於著名人物數量的問題，河某有兩種思路。一為量化「著名人物」章節列出的人物數量，不過無論是拍腦袋提出的10個20個，亦或根據人口計算出「最高著名人物數量上限」，都不合適，前者毫無理據，後者深圳一類新興城市不公平。二為不設限制，由主編自行判斷、決定展現多少/哪些名人合適，把條目編輯權交還給熟悉此領域的編輯，亂放一大堆名人搞得太過分，就在優典評審甚至DYK中卡住投反對不予通過。
  • 關於{{Category see also|XX人}}：把讀者引向分類頁面是個很糟的主意，試想讀者難道會在擁有27個子分類、469個條目的分類里遨遊，一個個點開條目閱讀？維基百科的分類系統對於讀者來說是非常困惑的。可以留在章節開頭，但個人不建議。

提案：

現行條文

姓氏條目禁止嵌入「著名人物」等人物列表，此類信息應由「分類:×姓」或獨立列表體現。

行政區劃條目禁止嵌入「本地出身人物」等人物列表，此類信息應由「分類:××人」或獨立列表體現。

疾病條目禁止嵌入「知名患者」等人物列表，此類信息應由「分類:×疾病患者」或獨立列表體現。

提議條文

姓氏條目禁止嵌入「著名人物」等人物列表，此類信息應由「分類:×姓」或獨立列表體現。

行政區劃條目禁止嵌入「本地出身人物」等人物列表，此類信息應由「分類:××人」或獨立列表體現。散文體撰寫的內容不屬此列。

疾病條目禁止嵌入「知名患者」等人物列表，此類信息應由「分類:×疾病患者」或獨立列表體現。

知會：天津市、濱海新區@Amazingloong：，嘉義市@Ketsu1213：，懷仁市@如沐西风：，寧波市、鎮海區@Siyuwj：，杭州市@Huandy618：，沙門鎮@MintCandy：，肥城市@Eguersi：，廣德市@深鸣：，盧氏縣@Newbamboo：，固始縣@Sinopitt：，廣州市、深圳市@Donwun：、祥雲縣@Kcx36：，日本系列@Suicasmo：，法國系列@Yzergues：，歡迎各位政區條目同好發表建議。如有叨擾深表歉意。--河水|滇 2024年7月2日 (二) 01:10 (UTC)[回覆]

為什麼說閣下的編輯是換皮列表呢？因為在我看來，瑞麗的著名歷史人物有麓川君主思可法、思倫法、思任法、思機法及末代勐卯土司衎景泰；中華人民共和國時期的政界人物有第五屆全國人大常務委員瑞板，政協雲南省十二屆委員會副主席黃毅；宗教界著名人物有上座部佛教高僧烏阿匝，中國佛教協會第六屆理事會副會長伍並亞·溫撒，中國佛教協會第九、十屆理事會副會長詔祜巴等傣；文化界著名人物有孔雀舞大師毛相，傣族詩人召尚弄·岩相、莊相等。這段文字與

政治人物

  • 麓川君主思可法、思倫法、思任法、思機法
  • 末代勐卯土司衎景泰
  • 第五屆全國人大常務委員瑞板
  • 政協雲南省十二屆委員會副主席黃毅

宗教人物

  • 上座部佛教高僧烏阿匝
  • 中國佛教協會第六屆理事會副會長伍並亞·溫撒
  • 中國佛教協會第九、十屆理事會副會長詔祜巴等傣

文化人物

  • 孔雀舞大師毛相
  • 傣族詩人召尚弄·岩相、莊相
沒有任何區別。（考慮到篇幅問題，沒有細分列表）另外大部分條目的名人頁面也都是導向分類的，這不是鄙人的發明。--向史公哲曰（留言） 2024年7月2日 (二) 01:30 (UTC)[回覆]
既然閣下有時間用這麼多篇幅解釋，為什麼沒有時間改善條目，反而是一刪（更正，應該是三刪）了之呢？至少也應該事先與原先的編者溝通。--🐹通遼署理交通相（討論·成就·交通點滴） 2024年7月2日 (二) 02:26 (UTC)[回覆]
因為這屬於列舉名人的內容，根據大部分條目的編輯情況是要刪除的。--向史公哲曰（留言） 2024年7月2日 (二) 02:29 (UTC)[回覆]
既然本人的行為是極不妥當的，那麼你們完全可以去提報我，然後把所有行政區劃條目的名人章節全部恢復，這並不難。--向史公哲曰（留言） 2024年7月2日 (二) 02:32 (UTC)[回覆]
畢竟維基百科的行政區劃條目理應羅列名人，體現當地的「人傑地靈「。而我對建設性內容大面積刪除是極不妥當的，不符合中國大陸維基人共識的。我幹這種滔天大罪，難道不應該被提報破壞，爭求封禁嗎？--向史公哲曰（留言） 2024年7月2日 (二) 02:35 (UTC)[回覆]
理論上說，散文和列表在許多情況下是可以相互改寫的，所以你只是論述了原先的散文可以用列表取代。如果認為這樣的散文就是換皮列表，我也只能言盡於此了。另外討論是交換意見，讓條目內容很好，而不是指控其他人，所以大可不必用這樣的語調回復。--深鳴（留言） 2024年7月2日 (二) 03:09 (UTC)[回覆]
更不用說大多數行政區劃條目的名人板塊都違反了npov和原創研究方針。（例如這些名人都會冠以政治家，軍事家等名號）（例如名人的選取標準十分混亂，凡是出生於此、祖籍於此、旅遊至此、工作於此，長居於此的名人都在這些維基條目的羅列範圍，總之名人的選取標準也是頗具爭議的。）--向史公哲曰（留言） 2024年7月2日 (二) 01:35 (UTC)[回覆]
誠然個別名人「在地影響深遠」，但亦有與當地幾無瓜葛甚或認同者，故建議改爲「以散文體陳述對當地有重大影響者除外」／「不屬此列」，否則既屬瑣碎亦涉嫌離題。--— Gohan 2024年7月2日 (二) 01:51 (UTC)[回覆]
中國的傳統歷史書也有人物傳記，是不是中國歷史條目也要羅列「中國歷史名人」？--向史公哲曰（留言） 2024年7月2日 (二) 02:09 (UTC)[回覆]
歷史條目中，如果安排得當，對歷史影響較大的人物在先前的內容中應該都已經提及，因此沒有必要單獨再列出歷史名人。也就是說，如果羅列「中國歷史名人」，說明前面的內容安排不合理。--深鳴（留言） 2024年7月2日 (二) 03:04 (UTC)[回覆]
同意此看法。在行政區劃條目中列出人物，還是為了介紹條目的主題。列出一部分能夠體現當地特色的人物，能夠展示當地的特點。並且行政區劃類條目與方志類似，方志中也有類似的人物章節。--深鳴（留言） 2024年7月2日 (二) 03:01 (UTC)[回覆]
能夠體現當地特色的名人，其篩選標準是什麼？另外外文維基百科面對名人列舉問題，採取的方法是建立xx人列表。--向史公哲曰（留言） 2024年7月2日 (二) 03:10 (UTC)[回覆]
該問題不可能有固定的標準，使用常識即可。若存在爭議則再根據具體的情況討論即可。這種情況其實類似於各民族信息框中列舉一些名人。創建xx人列表，我認為不必，直接使用分類取代即可。--深鳴（留言） 2024年7月2日 (二) 03:26 (UTC)[回覆]
如果當地名人的選取標準能夠使用wp:使用常識判斷的話，那麼中維乃至全社會關於名人是哪裏人的爭議就不會那麼多了。另外有些能體現當地特色的名人並不一定直接與當地有關，例如舒婷，她的自我認同是鼓浪嶼人，且她的常居地在鼓浪嶼。但是她出生在漳州，祖籍在泉州。--向史公哲曰（留言） 2024年7月2日 (二) 03:59 (UTC)[回覆]
再比如說，一些人雖然的確是當地人，但是他與當地並沒有太大的關係。例如王洪文是毫無爭議的長春人，但是他的主要事跡都與上海有關。--向史公哲曰（留言） 2024年7月2日 (二) 04:02 (UTC)[回覆]
我認為這類例子就可以不添加。「關於名人是哪裏人的爭議」，這個討論主體是名人，因為其經歷複雜而有爭議是正常的，不適用於使用常識，與本提案沒有什麼關聯。我所說的「使用常識」指的是在選取名人方面，而不是判斷爭議名人的歸屬方面，畢竟存在爭議的人還是少數。例如瑞麗的著名歷史人物有麓川君主思可法、思倫法、思任法、思機法及末代勐卯土司衎景泰；中華人民共和國時期的政界人物有第五屆全國人大常務委員瑞板，政協雲南省十二屆委員會副主席黃毅；宗教界著名人物有上座部佛教高僧烏阿匝，中國佛教協會第六屆理事會副會長伍並亞·溫撒，中國佛教協會第九、十屆理事會副會長詔祜巴等傣；文化界著名人物有孔雀舞大師毛相，傣族詩人召尚弄·岩相、莊相等。這段話裏面應該大多數人還是沒有爭議的吧，並且單純從這段話而言，能夠體現出瑞麗市宗教與文化方面的特點，對主體是有益的。--深鳴（留言） 2024年7月2日 (二) 04:30 (UTC)[回覆]
首先，結合我近日的編輯來看，存在歸屬爭議的名人並不在少數。其次，名人的選取標準應該以什麼為準繩？是否身居要職就應該羅列上去，還是說有維基條目就可以列上去？--向史公哲曰（留言） 2024年7月2日 (二) 04:39 (UTC)[回覆]
此外還有一個問題，名人的選取標準是否應當顧及到當地名人的多寡（名人多的標準放高，名人少的標準放低），還是說應當要統一選人標準？--向史公哲曰（留言） 2024年7月2日 (二) 04:41 (UTC)[回覆]
雖然存在歸屬爭議的名人並不在少數，但是從整體來看，多數名人還是不存在歸屬爭議的。或者就說，列舉的名人就從不存在歸屬爭議中的挑選。關於名人的選取標準以及人數多少，我認為就應該使用常識，根據具體的情況判斷。總體來說不是太多就可以，並且也應該是當地名人中較為出名的那一批。--深鳴（留言） 2024年7月2日 (二) 05:00 (UTC)[回覆]
如果所謂的「不是太多就可以，並且也應該是當地名人中較為出名的那一批」沒有一個可以量化的標準，那事實上這樣的標準就會成為原創研究。--——— 紅渡廚（留言・貢獻） 2024年7月2日 (二) 09:28 (UTC)[回覆]
維基百科:規則只是原則，不是什麼東西都必須有一個「可以量化的標準」，許多東西運用常識即可。維基百科不是官僚體系，不是盲目跟隨默認的方針和程序。--深鳴（留言） 2024年7月2日 (二) 09:37 (UTC)[回覆]
如果閣下有在生活中接觸過大量的人，你就會發現，這個世界上根本就沒有所謂的「常識」：比如，有人認為「講衛生」是常識，但事實上有大量的人不講衛生；比如，有人認為「如何購買地鐵票」是常識，但事實上有大量的人不知道如何購買。許多人所以為的「常識」，事實上只是「身邊統計學」而已。以及，我非常反感話都沒開始說幾句就拋出一個維基百科:忽略所有規則（或其他類似觀點，後續統稱「該方針」）來堵對方嘴，我認為這只是為了拒絕執行其他方針找的一個藉口而已。雖然該方針我有時候也拿出來說，但我認為該方針是用於現有維基百科方針不足以說明當前情況時，用來類推相似做法。--——— 紅渡廚（留言・貢獻） 2024年7月2日 (二) 10:04 (UTC)[回覆]
雖然某一個人的常識不一定是常識，但是大量的人的常識匯總起來，那麼就可以認為是常識。我本意並不是批評或評價閣下，但是我確實認為閣下像是讀法律條款一般去讀維基百科的各種方針，什麼東西都要找到對應的條款。正因為這種觀念，所以出現了不少諸如一刀切現象的存在。不過我不認為這種觀念適用於維基百科。另外，我提出忽略所有規則類似的觀點並不是想堵住對方的嘴，只是想說明「不是太多就可以，並且也應該是當地名人中較為出名的那一批」類似的語句就已經足夠了，原來的規定行政區劃條目禁止嵌入「本地出身人物」等人物列表的本意應該是防止大量瑣碎內容的堆積。有些規則確實只是傳達了一種精神而已，如果非要量化，像法律條款那樣規定「列舉的人物不得超過五個，且至少為XX職稱云云」，閣下認為這樣的規則合適嗎？如果制定了這樣的規則，就很容易陷入連鎖悖論之中。當然，我認為閣下的意思是，沒有極其明確的規則的話，就可能存在爭議，但是這也是沒有辦法避免的事情。--深鳴（留言） 2024年7月2日 (二) 10:30 (UTC)[回覆]
這裏提一嘴，我個人感覺將人物列表以簡單粗暴的手法改寫成散文體，並不能阻止"堆積內容"的情況。例如在天津條目和杭州條目的人物章節（存在於上一個歷史版本）中，便存在各式人物羅列的情況。我對這些名人內容的評價是"出生於此、祖籍於此、旅遊至此、工作於此，長居於此的名人和虛擬名人的大亂燉"。目前，我個人看到過最好的名人敘述章節在寧波條目（雖然被我刪除了）。--向史公哲曰（留言） 2024年7月2日 (二) 12:51 (UTC)[回覆]
「一刀切」禁止不妥，相關提案本意當是避免在條目中塞入臃腫列表影響敘述重心，或避免「缺乏定義」問題，並非任何列表均禁止添加。又若有可靠來源直接指出某些人物為當地名人，則不一定屬於「原創總結」。另外，若列表篇幅不足以建立獨立列表，亦應允許直接放在條目中。此處與其指定「散文體行文除外」，不如改成「（一般而言）禁止嵌入僅單純列點之列表」，給予編者更大空間。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 04:15 (UTC)[回覆]
我傾向每項列舉和定義（特點、著名）都有來源，作為基礎條件。排序、原創總結等問題儘量避免，但只要寫就肯定存在問題，是將多個來源的內容整合為一段。容易違背中立的觀點。--YFdyh000（留言） 2024年7月2日 (二) 05:11 (UTC)[回覆]
人物章節確實容易形成堆砌內容的風格。如果以改善為目標，則更應該強調此類章節的邏輯性。而不是簡單刪除，放一個分類在這裏。即便是待改善的點列式，也比簡單刪除的做法好。寧波市此前的人物段落雖不充實，但寫作的感覺和邏輯性較好，值得借鑑。--Amazingloong（留言） 2024年7月2日 (二) 14:42 (UTC)[回覆]
統一回復上述討論串的疑問、質疑、建議：
  • 大部分條目的名人頁面也都是導向分類的，以前不是這樣的，應該是這個指引出來後逐步被改的。我RFA的時候有被問到過對條目嵌入列表的看法，只是在RFA里做了回復，沒有參與這個討論。當時覺得這個指引規定的是「列表」，未曾想到如今會擴展到散文體的段落。
  • 著名人物章節選擇哪些人物進行展示、篩選標準是什麼，不是此案的討論範圍。從方志實踐的角度看，出生於此、祖籍於此、旅遊至此、工作於此、長居於此都可以被列入，這些應該是編者編寫條目自己考量的東西，屬於內容範疇，不屬格式手冊管轄範圍。具體對內容有質疑，應該在條目的討論頁或者優典評審中提出。看到許多討論都偏題了，重心偏向如何界定「著名人物」去了，本案只討論格式手冊限定的格式問題，深入討論「著名人物」的界定問題我覺得在維基百科:互助客棧/條目探討開一個版比較合適。
  • 外文維基百科面對名人列舉問題，採取的方法是建立xx人列表。小城市條目的著名人物也是直接寫在「著名人物」章節，還都是用點列式寫的，例子：en:Kennewick, Washington、de:Bobonaro (Gemeinde)、ja:門司區，都是外維GA里隨機挑的。不反對建立XX人列表，但也不提倡，這個列表的意義和分類沒太大區別，還需要手動更新，屬於吃力不討好的活，沒人看，只能感動自己。如果著名人物雙手雙腳數得過來，又何必單獨建立列表。
  • 建議改為「以散文體陳述對當地有重大影響者除外」／「不屬此列」，我認可這樣的想法，但不贊同這種做法，「對當地有重大影響者」無法量化，不應該在方針指引中寫入這樣模糊的話語，會對未來埋下矛盾。是否是值得列入的、有重大影響的著名人物，應是條目內容的範疇，同前所述。
  • 將人物列表以簡單粗暴的手法改寫成散文體，並不能阻止"堆積內容"的情況。確實，但是禁止列表難道能夠阻止「堆積內容」嗎？政區條目有一萬種可以灌水堆積內容的方式：按新方志大事記體裁事無巨細寫歷史，地理章節拿着地名志把山川河流全寫上，人口經濟章節用統計年鑑瘋狂寫數據（參考百度百科）……出現在這個討論串的，想必都是對政區條目有一番心得的編者，簡言之都會寫條目，誰會覺得這樣堆積內容的條目是優質條目，又會這麼做呢？真的堆積內容，應該在條目質量評審中卡住，還是那句話，內容的問題和格式的問題是兩碼事。格式手冊應是基本格式的下限，不是束縛編者的枷鎖。
  • 改成「（一般而言）禁止嵌入僅單純列點之列表」，贊同。
  • 以上。--河水|滇 2024年7月2日 (二) 22:59 (UTC)[回覆]
同意河水君的看法。不過個人認為新的提議條文中，前後兩句話在語義上或有矛盾之處。或可直接刪除，或可改為「（一般而言）行政區劃條目中禁止嵌入僅單純列點之人物列表」。--深鳴（留言） 2024年7月3日 (三) 17:16 (UTC)[回覆]

正式提案（準備公示）

三日未見新的疑問、質疑，河某權當諸君認可此修訂案基本方向，修改正式提案如下，再待三日，若無異議將進行公示。

現行條文

姓氏條目禁止嵌入「著名人物」等人物列表，此類信息應由「分類:×姓」或獨立列表體現。

行政區劃條目禁止嵌入「本地出身人物」等人物列表，此類信息應由「分類:××人」或獨立列表體現。

疾病條目禁止嵌入「知名患者」等人物列表，此類信息應由「分類:×疾病患者」或獨立列表體現。

提議條文

姓氏條目禁止嵌入「著名人物」等人物列表，此類信息應由「分類:×姓」或獨立列表體現。

行政區劃條目禁止嵌入「本地出身人物」等人物列表，此類信息應由「分類:××人」或獨立列表體現。

疾病條目禁止嵌入「知名患者」等人物列表，此類信息應由「分類:×疾病患者」或獨立列表體現。

一般而言，行政區劃條目中禁止嵌入僅單純列點之人物列表，此類信息應由「分類:××人」或獨立列表體現。

是否有必要提供例子進行條文解釋，明確何謂僅列點之人物列表，可再議。--河水|滇 2024年7月5日 (五) 10:42 (UTC)[回覆]

『此類資訊應由「分類:××人」或獨立列表體現』這句分句可以保留。總體上暫時不反對此提案。Sanmosa 蚌埠 2024年7月5日 (五) 12:33 (UTC)[回覆]
或改成「可由（略）體現」。另「僅列點」可改為「僅單純列點」，排除混合寫法。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月5日 (五) 14:35 (UTC)[回覆]
已根據建議調整新增條文。原新增條文：一般而言，行政區劃條目中禁止嵌入僅列點之人物列表。--河水|滇 2024年7月5日 (五) 20:58 (UTC)[回覆]
(－)反對之前是因為收錄標準不明，而不允許姓氏、區劃類條目加入人名列表的，之前「美國人列表」之類的也是因此而被禁止的吧--苞米(☎)💴 2024年7月5日 (五) 21:10 (UTC)[回覆]
@Baomi：還請你説明一下你反對的是河水的提案本身還是我對河水的提案的建議。Sanmosa 蚌埠 2024年7月6日 (六) 11:01 (UTC)[回覆]
(＋)支持，比之前的條文合理--苞米(☎)💴 2024年7月6日 (六) 12:09 (UTC)[回覆]
@瑞丽江的河水：我認為你現在可以考慮是否公示此提案。Sanmosa 蚌埠 2024年7月13日 (六) 01:39 (UTC)[回覆]
開始公示七日。--河水|滇 2024年7月13日 (六) 08:36 (UTC)[回覆]

提議限制無意義用戶名

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

不通過：
社羣主流意見顯然反對在「無意義用戶名」不能被妥為定義的情況下限制無意義用戶名的提案，故提早關閉討論。Sanmosa 蚌埠 2024年7月13日 (六) 01:29 (UTC)[回覆]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

在此提議於用戶名方針中限制明顯無意義的用戶名（如「ADSCCGBDFVDYCVFWGDGDHFS」）。

理由很簡單，我認為正常參與維基百科的用戶很少會起很雜亂的用戶名，因為只會妨礙交流；而破壞者出於惡作劇的目的更有動機使用這樣的用戶名。這鴨子測試一樣，也是有效的經驗法則。限制此類用戶名可以幫助社群更快速地處理破壞行為。

作為參考，葡萄牙語維基百科有類似的方針，節錄如下：

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

難以理解的名稱，由一組重複字符或六個或更多隨機字符的序列組成，例如「aaaaaaaaaaaa」或「8i98uijkwoel3plwç」

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

這樣，我會很尷尬，所以(－)反對抱歉，而且很多其他語言維基百科沒有這樣限制--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 11:01 (UTC)[回覆]
沒有必要+無法評估意義和混淆度。IP位址同樣有區分難度。正常的處理惡意混淆用戶名即可。--YFdyh000（留言） 2024年7月2日 (二) 11:21 (UTC)[回覆]
認同YFdyh000說法--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 11:23 (UTC)[回覆]
(＋)支持 事實證明葡萄牙語維基百科已經利用此規則阻止了擾亂用戶在該站活動。--——🦝Interaccoonale（留言・貢獻） 2024年7月2日 (二) 11:28 (UTC)[回覆]
請問很多其他語言維基百科，為什麼不統一使用葡萄牙語維基百科規則呢???因為早期很多都是很雜亂的使用者名稱，因為不知取什麼名字，所以亂打，才造成有這些人，但並非破壞者，而且滿多人有對維基做出貢獻，不能因為破壞者取這樣名稱，而限制很多人權利，這如YFdyh000講得一樣，沒有必要+無法評估意義和混淆度--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 11:36 (UTC)[回覆]
@HYHJKJYUJYTTY:
請問你改這個名字的意義是什麼，有沒有特別含義？--唔好阻住我愛國（留言） 2024年7月2日 (二) 12:11 (UTC)[回覆]
當初只是為了編輯而已，所以沒有認真取名字--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 12:13 (UTC)[回覆]
其實你是可以申請改名的。不過，如果我因某一事項想找人討論，我很難聯想你的出現，因為你的名字只是 「隨機字元的序列組成（隨便改名）」，如果我要ping你，也要記起HYHJKJYTTY的字元組合先，只要忘記其中一個字元，也不能順利地找你。--唔好阻住我愛國（留言） 2024年7月2日 (二) 12:59 (UTC)[回覆]
有那麼困難嗎，通常可以記前幾個字母來找。--YFdyh000（留言） 2024年7月2日 (二) 16:02 (UTC)[回覆]
目前從事反純破壞工作或翻譯--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 12:14 (UTC)[回覆]
您自己的一些編輯已經在破壞行為的邊緣了；並且您既不熟悉英語、也不熟悉漢語（WP:管理員佈告板/其他不當行為#HYHJKJYUJYTTY），您的翻譯內容已經引起了多位用戶的不滿。。。--自由雨日（留言） 2024年7月2日 (二) 13:20 (UTC)[回覆]
我最初翻譯跟他最新版本翻譯，根本差不多，先不聊，但我警告後，根本沒後續堅持，還有其實跟這個處理方針無關--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:28 (UTC)[回覆]
抱歉我熟悉漢語，只有不熟悉英語而已--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:30 (UTC)[回覆]
是不是不朔及既往就可以？讓HYHJKJYUJYTTY大這樣的ＩＤ變成絕版造型也是好方法。 --窩法乙烷 兒法夢碎 2024年7月2日 (二) 13:13 (UTC)[回覆]
不朔及既往，算是不錯作法，但限制沒有意義--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:23 (UTC)[回覆]
很多用戶名對用戶本身有其意義，不過是對外人而言無法理解罷了。比如，請問諸位在點進KaurJmeb君的用戶頁之前會覺得這個用戶名有意義嗎？再者，縱使我們假設擾亂者才會亂取用戶名，我對提案的政策多大程度上能夠限制擾亂者表示懷疑，因為要取一個有意義的用戶名也不是多難的事。去維基詞典點擊隨機頁面就必然可以得到一個「有意義」的詞彙，這不比亂敲幾下鍵盤難多少。Irralpaca（留言） 2024年7月2日 (二) 13:36 (UTC)[回覆]
認同，無意義使用者名稱跟防止破壞者，關聯程度不高，因為確實破壞者可以取有意義名稱--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 13:42 (UTC)[回覆]
@YFdyh000、Irralpaca：感謝留言。目前我只是提出了大體方向，具體方針怎麼寫還沒有想好。考慮到漢字的性質肯定不能照抄ptwiki的方針。
至於您給的例子，我認為是細節上如何界定「無意義」或者「難以辨識」的問題。我的想法是那些使用常識直觀判斷不存在任何有意義的可能性的用戶名（比如KaurJmeb這個名字的熵值其實不是很高，而且用戶給出了解釋）。第二個問題的話，本提案只是想進一步規範用戶名，方針本身就是一點一點優化的，反破壞的效果只要有就行，並且長遠來看禁止這樣的名字對社群沒壞處。--碟之舞📀💿 2024年7月2日 (二) 13:58 (UTC)[回覆]
想要建議這方針必須是不影響共識之前的使用者權利，還有必須釐清無意義使用者名稱跟防止純破壞者，關聯程度，但目前為止看不出來--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 14:03 (UTC)[回覆]
您可以使用現代標準漢語發言嗎？--——🦝Interaccoonale（留言・貢獻） 2024年7月2日 (二) 14:29 (UTC)[回覆]
平行時空的人你好--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 14:36 (UTC)[回覆]
閣下您那整句到底是什麼意思？您前半是在說建議這個方針不要溯及既往（還是在說不要損害既得者利益所以反對提議？），然後後半是在說還需要進一步釐清「無意義的名稱」跟「破壞者」的關係嗎？閣下您的用詞感覺似乎漏掉好幾個字詞且順序混亂，讀得頗吃力。--WiTo🐤💬 2024年7月2日 (二) 14:59 (UTC)[回覆]
我什麼時候建議不要溯及既往，是別人建議，我認為好，但限制沒有意義，文字要看懂，根本沒吃力，真的不要怪別人--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:08 (UTC)[回覆]
我用詞並沒有漏掉好幾個字詞，那是你看很多人討論，造成混亂--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:19 (UTC)[回覆]
提醒你碟之舞目前還沒有正式方針草案--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:21 (UTC)[回覆]
無法判斷。可發音或者用單詞組成的用戶名，可能反而是用軟件（字典）生成。不需要朗讀，未見規範用戶名的需求。明顯的弊大於利，無論短期長期。--YFdyh000（留言） 2024年7月2日 (二) 16:08 (UTC)[回覆]
不認為有必要限制。因為主觀標準不同。YFdyh000、Irralpaca、T45614631這種難道能直接看出有什麼意義？甚至Ericliu1912，也是因為社群知道本人使用Eric Liu的稱呼，纔顯得有意義。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 15:23 (UTC)[回覆]
不正規統計，沒七成，至少超過五成都是沒有直接意義，認同Eric Liu 主觀標準不同，所以很難怎麼處置，確實不必要--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:30 (UTC)[回覆]
您到底在說些什麼？--——🦝Interaccoonale（留言・貢獻） 2024年7月2日 (二) 15:32 (UTC)[回覆]
所以你要表達什麼--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:36 (UTC)[回覆]
是我在問你，你在表達什麼。--——🦝Interaccoonale（留言・貢獻） 2024年7月2日 (二) 15:38 (UTC)[回覆]
我表達反對意見，認同其他人類似意見，如果你是為了反駁而反駁，大可不必--HYHJKJYUJYTTY（留言） 2024年7月2日 (二) 15:42 (UTC)[回覆]
老實說，我的還真的沒有意義（是當時鍵盤隨便碼的數字），之前曾有動念想改，但一直遲遲沒去申請。不過我個人對這議案期望能帶來的效果感到懷疑（以及對標準拿捏有疑慮），但不試不知效果，故現在保持中立。--WiTo🐤💬 2024年7月2日 (二) 15:49 (UTC)[回覆]
閣下還是申請更名吧，有時想找閣下老費勁了：D（我只能記前3個數字）--微腫頭龍（留言） 2024年7月3日 (三) 15:00 (UTC)[回覆]
支持理念，但判定過於主觀，難以合理執行。
  • 「有意義」與否尚不能保證用戶名「便於辨識」。若有用戶使用倉頡碼或注音碼來建立帳號，用戶名看起來也像是亂碼，確實有實際意義卻仍然不便於辨識（並非所有人都懂得倉頡或注音）。
  • 「有意義」與否應視用戶是否能解釋自己的用戶名的意思。如果能大致給個有道理的解釋（例如過往網名），那麼就顯然不是「沒有意義」；如果解釋不了的，那顯然就只是個亂碼。
--路西法人 2024年7月3日 (三) 00:28 (UTC)[回覆]
另，同其他用戶的部分意見，不同意將「無意義用戶名」直接歸於「防止破壞」。任何此類規範都是應以「阻礙協作」為推進前提，直接標籤為破壞未免過甚。--路西法人 2024年7月3日 (三) 01:47 (UTC)[回覆]
反對，本身用戶名就是主觀性或者對於使用者來說就有意義的，站在旁人的角度自然就是沒意義的，這樣實際上會令本社群為了「審核」用戶名的「意義」而官僚化。破壞和用戶名是否對於用戶本人或者旁人並無直接關聯。不應該將用戶名的「有意義」性作為破壞或者提前阻止的推斷，對應用戶做出破壞的編輯的時候再說。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月3日 (三) 01:00 (UTC)[回覆]
(－)反對，在無惡意的情況下，選用什麼樣的用戶名是用戶的自由。--Leiem（留言·簽名·維基調查） 2024年7月3日 (三) 02:49 (UTC)[回覆]
(－)反對，無意義，完全是主觀認定他人用戶名不合適，有違WP:假定善意。——— 紅渡廚（留言・貢獻） 2024年7月3日 (三) 03:42 (UTC)[回覆]
(－)反對，討論使用者名稱有沒有意義沒有意義--銀河市長—☎️— 2024年7月3日 (三) 05:45 (UTC)[回覆]
(－)反對，「有意義」的認定標準非常主觀。用戶名隨時間的增加會越來越多，「有意義」的選項會越來越少。--微腫頭龍（留言） 2024年7月3日 (三) 14:56 (UTC)[回覆]
有一說一，「意義」本就是人為賦予的，所以所有用戶名既可以全都是有意義的，也可以全都是沒意義的。Sanmosa 蚌埠 2024年7月3日 (三) 23:56 (UTC)[回覆]
以「是否有意義」的角度來看會遭到反對。我個人認為這裏更多是「是否對編者互相溝通造成阻礙」。上方已有舉出一個例子：閣下還是申請更名吧，有時想找閣下老費勁了：D（我只能記前3個數字）像亂碼、純數字用戶名，不好記，容易妨礙溝通。--0xDeadbeef (留言) 2024年7月4日 (四) 06:01 (UTC)[回覆]
溝通障礙同樣難評。用戶名與簽名無關，算製造障礙嗎。您的用戶名我也記不住。有特點的用戶名或簽名出現仿冒，是最有可能的，但很多仍難鑑定是否惡意。假設取名「日期2024年7月4日」。又如站內的范、范博，我會不自覺的記混，但也許只有我。--YFdyh000（留言） 2024年7月4日 (四) 08:39 (UTC)[回覆]
實際上大家的使用者名稱多半沒什麼「客觀」意義。這同時也是網絡文化特性，太有意義反而增加辨認風險。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月5日 (五) 14:33 (UTC)[回覆]
(！)意見：直接限制用戶名或許太過嚴格，那麼是否可以在「創建賬戶」頁面「用戶名」輸入框下加一行類似「推薦不要採用長串無意義字符」的建議呢？不強制要求，就像「電子郵箱地址」也是推薦填寫。這類提示相信是可以影響到大量有意作出善意編輯的人，讓本來可能就隨便輸入幾個字符的新用戶改取有意義用戶名的。--——自由雨日（留言・貢獻） 2024年7月5日 (五) 00:16 (UTC)[回覆]
不反對，雖説效用大不大另説。Sanmosa 蚌埠 2024年7月5日 (五) 12:34 (UTC)[回覆]
不認為有意義，如果當事人自己覺得好和方便，可能不會聽勸。目前沒有推薦「採用長串無意義字符」，故猜測不少是用戶自主選擇，但修改用戶名是有點麻煩的。--YFdyh000（留言） 2024年7月5日 (五) 15:27 (UTC)[回覆]
不一定是用戶「自主選擇」用戶名，我認為至少有一半無意義用戶名只是註冊時沒有多想、懶得取名（沒有想到需要和社群討論和互動、沒有想到編輯記錄中會經常出現用戶名、沒有想到個人的多比貢獻問題可能共同會被社群指導，等等），而不是他們有意「選擇」了無意義字符串。有這種提示至少可以使這半用戶稍微輸入一點不那麼隨機的字符串。--——自由雨日（留言・貢獻） 2024年7月5日 (五) 15:35 (UTC)[回覆]
要不我給個新思路：我們先不要執著於「有沒有意義」的事情，我們能否界定甚麽是「亂碼」？Sanmosa 蚌埠 2024年7月6日 (六) 11:05 (UTC)[回覆]
可以。其實我想限制的就是亂碼，只不過覺得這個詞不適合出現在方針里所以沒提。--碟之舞📀💿 2024年7月6日 (六) 11:08 (UTC)[回覆]
葡萄牙語維百的方針我覺得應該是能夠界定的：難以理解的名稱，（且）由一組重複字符或六個或更多隨機字符的序列組成。至於什麼是（六個以上）「隨機」字符，我覺得應該可以依照常識判斷吧……（雖然我個人是傾向不必強制限定，只向新註冊用戶「推薦」不要採用亂碼的，那也就無需定義，「亂碼」「無意義」或類似的詞語已經足夠）——自由雨日（留言・貢獻） 2024年7月6日 (六) 11:11 (UTC)[回覆]
那就取決於社羣是否認為「隨機字元」能被妥為定義了，如果社羣認為不能的話，那強制性規定應該是不太可能了。Sanmosa 蚌埠 2024年7月6日 (六) 11:56 (UTC)[回覆]
不認為可界定。按上文，5個隨機字符組成的序列可規避。--YFdyh000（留言） 2024年7月6日 (六) 13:10 (UTC)[回覆]
@Diskdance、Interaccoonale：根據我對這裏的討論情勢的觀察，我認為社羣普遍不太認同「隨機字元」可被妥為定義，並因此或出於其他原因不贊同限制無意義用戶名的提案，因此我想讓兩位再重新想想是否還要繼續推進此案。Sanmosa 蚌埠 2024年7月7日 (日) 09:54 (UTC)[回覆]
還是那句，編者能解釋的就不是亂碼。硬是給我編得出一個合理的解釋就行。甚至說是以前在其他平台就已經有用過的亂碼用戶名，現在在維基百科重用，也是有意義的。--路西法人 2024年7月9日 (二) 02:49 (UTC)[回覆]
(－)反對，有無意義無法界定，即便本為一段亂碼，使用者在被問及其意義時亦可辯稱：這是一段密碼，恕我無法透露其內容。如若進一步強求解釋，任何人也可以就一段亂碼為其賦予意義，只要聯想便是了。因此這屬於無法界定的規則，也便實質上無法執行。Boreas Sawada 2024年7月8日 (一) 22:01 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

草擬方針:

1.一般只記載原作國家地區及中文維基主要地區的配音員，以符合大多數中文維基使用者所關心。

3.原作地區和中文地區的配音請儘量提供可靠的來源。(例如來自發行方、播出平台和配音公司的一手來源以及媒體報道的二手來源。)

2.配音員的標示請使用全稱，避免使用有消歧義爭議的「CV」。--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年7月3日 (三) 11:43 (UTC)[回覆]

原因是因為本人在超級戰隊條目配音員問題上與@DarkWizardCody起過爭執（該用戶主張應使用可靠的二手以及三手來源不應使用一手來源。)以及本人與香港配音社群和台灣配音社群的爭執。（對官方未公開配音人員資訊的作品主張使用愛好者社群網站以及使用原創總結的手段得到的配音員資訊。)順帶ping以下其他相關專題的用戶。@HK5201314--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年7月3日 (三) 11:54 (UTC)[回覆]
@甜甜圈真好吃:
我只可說，所有規條也是相輔相成。
1. 你要「一般只記載原作國家地區及中文維基主要地區的配音員」，但你維沒有完全禁止列出其他地區的播放資料（規條不對稱 )，什至有編輯者@Factrecordor認為中維應接納世界各地的資訊。
2.WP:使用全稱，可以redirect到這個。
——
總括而言，可以把這個提案放在#電視劇演員名單序列一併討論，反正兩個的特性是一致。--唔好阻住我愛國（留言） 2024年7月3日 (三) 14:58 (UTC)[回覆]
語言不超過3種時，我感覺條文1或可不應用，或者使該條文無強制力。條文2，如果官方資料使用呢，ACGN有時常用CV。不算反對，只是是否要如 配音（CV）等表述。條文3，為什麼不是所有。或者，有哪些不夠可靠的來源是可明確接受的。--YFdyh000（留言） 2024年7月3日 (三) 15:03 (UTC)[回覆]
論點3目前已受MOS:TV規管，所以先說在上方一併討論。--唔好阻住我愛國（留言） 2024年7月3日 (三) 15:19 (UTC)[回覆]
  • 首先，應說清楚與DarkWizardCody、香港配音社群、台灣配音社群的爭議是什麼。是否你們之間有人想收錄英語、法語等等的外語配音員名單？按之前其他討論中透露，似乎不是這樣，而是連收錄某些中文地區的華語配音員名單都受到阻止。如果我說得沒錯的話，那麼眼前的問題，其實本來和我主張的「中維應接納世界各地的資訊」沒有關係。若草擬方針是全新的，那麼「一般可記載原作國家地區及中文維基主要地區的配音員」更能針對眼前的問題。然而，這是參考自MOS:ACG，是因為特攝愛好者多與ACG重疊，但又不屬於ACG範圍吧，那麼應該先看看非ACG與特攝條目，究竟有沒有收錄外語配音員名單（原產地以外）的習慣，如有，應通知那邊活躍編輯者前來討論，如沒有或根本不存在這樣的條目，那就跳到下一點。
  • 不論我有沒有搞錯眼前的問題，對於我主張的「中維應接納世界各地的資訊」，我判斷的大原則是視乎設數量限制及中文地區優先之後，能不能有效解決或改善問題。配音員名單和之前討論的播放或重播資訊不同，它們是不能簡述的，所以問題會更難解決，只收錄中文地區恐怕是合理取捨。條文既寫了「一般」，將來發現特例再討論也可。我在這裏只強調，資訊性質不同，所以處理手法也可各異，不必視為不對稱。
--Factrecordor（留言） 2024年7月3日 (三) 18:03 (UTC)[回覆]
然而非ACG和特攝類的條目的話也有收入配音員資訊例如韓劇來自星星的你、日劇極主夫道。--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年7月4日 (四) 01:35 (UTC)[回覆]
重點在於配音資訊有沒有必要收錄（DarkWizardCody主張不收錄配音資訊)以及配音資料來源的可靠性（港台配音社群對於無一手來源提供資料的主張使用原創總結內容以及配音愛好者網站作為來源）--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年7月4日 (四) 03:42 (UTC)[回覆]
既然下面也提到MOS:ACG吵了這麼久就是無法指引化，我覺得這有點像香港修例事件一樣，為了解決一件事，引入會影響很多很多東西的條例，可能引起很多疑慮、軒然大波，倒不如尋求更具針對性的修訂。在這些爭議中最值得討論清楚的是什麼是合適來源。至於DarkWizardCody，這個名字不時都出現在編輯爭議中。我認為主張不收錄配音資訊是很個人的見解，向來在很多作品條目都被收錄非原產地的配音員名單，可見這是不少人的習慣，除了來源問題，看不出什麼現有條文能作為有力的理據反對收錄。--Factrecordor（留言） 2024年7月4日 (四) 15:36 (UTC)[回覆]
有沒有發覺一件事，就是DarkWizardCody遇上編輯爭議時不參與討論。這個討論已ping他3日有多，但他仍沒有任何回應或讓步，還以高高在上的心態指導編輯工作。有一種霸住/佔領條目之嫌，但管理員對他的態度是「不作為」/「沒有任何反應」。--唔好阻住我愛國（留言） 2024年7月5日 (五) 00:27 (UTC)[回覆]
說到合適來源最大的問題就是作品本身能不能成為來源(部分作品的配音人員名單一般只在作品本身的製作人員列表標註而不會標註平播放平台的製作人員列表內)以及部分未認證的配音公司社交媒體賬號能否作為可靠來源使用。(部分配音公司由於條件限制只會在社交平台發佈。)(DarkWizardCody相關:DarkWizardCody一般只回應在討論頁的回覆不會接受ping。)--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年7月5日 (五) 13:41 (UTC)[回覆]
DarkWizardCody是會主動使用互助客棧機制的，也懂得引用條文。沒這樣做，恐怕反映他自己都覺得在「法理」上佔不到便宜。--Factrecordor（留言） 2024年7月5日 (五) 15:32 (UTC)[回覆]
日本動漫的配音指引能適用於全部電視專題條目？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月3日 (三) 18:36 (UTC)[回覆]
因為配音的作品不只是動漫還有電視劇、紀錄片等其他類型的電視作品需要規範。--馬來西亞華人權益是不會因為某些人士（例如東姑阿都拉曼以及馬華公會)齷齪的伎倆中斷的--甜甜圈 2024年7月3日 (三) 23:09 (UTC)[回覆]
MOS:ACG吵了這麼久就是無法指引化，感覺是否具有參考價值？另外傾向用「移植」而不是「移動」的說法。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 03:10 (UTC)[回覆]
我認為一手來源（例如作品官網角色來源，這個例子可能還包括代理商發佈平台的介紹或者社交媒體上的介紹？）可以使用。「如果維基百科使用一次文獻，僅當該文獻被可信賴的出版社發表過，比如，由法庭速記員出版的庭審記錄，或出現於資料匯編中的歷史文獻。我們不可以使用未經可信賴出版者發佈的一次文獻。」不要只關注後句，而是前句也需要留意，也就是「作品官網角色頁面」、「代理商發佈平台的介紹」應該對標為「文獻被可信賴的出版社發表過」的情況。當然非要覺得「官方網站是不可信賴的，它都懂個屁作品配音介紹」的，那就當我沒說過。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 03:19 (UTC)[回覆]
非獨立的一手來源？「如由大學出版社或主流報紙發表」恐怕在要求編審獨立、信任主流出版物的查證水平。不過，某些正式出版物的準確性，可能還不如其他資料，尤其是宣傳稿或僅提及。--YFdyh000（留言） 2024年7月4日 (四) 08:26 (UTC)[回覆]

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

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

提案背景如下：

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

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

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

方針修訂方案如下：

現行條文

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

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

提議條文

全域更名者和監管員可以為用戶修改其用戶名；可至本地或元維基提出申請，亦可使用Special:GlobalRenameRequest表單進行申請。

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

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

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

關於同一網頁參考資料不同版本的引用問題

我正在編寫條目中科宇航。條目中部分內容的參考資料以前在該企業官網一頁面上，但去年該網頁內容進行了修改（但標題、url均不變）。

由於新舊兩版本的網頁都被互聯網檔案館所記錄，我該如何處理新舊參考資料？我目前的做法僅僅是把舊版設為dead-url=yes，並區分了參考資料名和引用時間。

連結：

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

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

關於被無限期封禁者的用戶頁清空問題

我有一個問題，就是根據觀察，被無限期封禁者（及被全域鎖定者、被WMF封禁者）的用戶頁基本上都會被清空，然後再掛上各類無限期封禁模板。請問清空用戶頁這點在中維有無相關規定指引？反正在英維，無限期封禁者的用戶頁不會被清空，只是會額外掛上無限期封禁模板而已。--BigBullfrog（𓆏） 2024年7月8日 (一) 03:32 (UTC)[回覆]

請參閱這裏。Python6345（留言） 2024年7月8日 (一) 05:50 (UTC)[回覆]
這條文僅限indef封鎖。全域鎖定雖然實務上比照indef封鎖的方式辦理，但並無本地成文規定。全域禁制一般不是本地處理的。Sanmosa 蚌埠 2024年7月8日 (一) 05:58 (UTC)[回覆]
由於 維基百科:不限期不等於永久 不是方針，故管理員可以清空使用者頁面。--唔好阻住我愛國（留言） 2024年7月8日 (一) 14:54 (UTC)[回覆]

原文重定向的可靠來源

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

剛剛細讀才發現WP:RFAL有這麼一句「創建者應在重定向頁面加入證明外文名稱的可靠來源，除非外文名符合以下豁免條件之一：」。請問能在重定向里放來源的嗎？如果不能要怎麼執行這一句？還是當初制定方針時寫錯了？@自由雨日：--微腫頭龍（留言） 2024年7月9日 (二) 13:58 (UTC)[回覆]

起因可見：WP:頁面存廢討論/記錄/2024/07/09#批量提刪--——自由雨日（留言・貢獻） 2024年7月9日 (二) 14:00 (UTC)[回覆]
技術上可能，編輯摘要或HTML註釋，重定向語法後面印象中也可行。不曾注意到該方針的存在，我懷疑這是否「反映社群共識」。Special:Diff/55642771，提案可能未獲充分討論。--YFdyh000（留言） 2024年7月9日 (二) 14:41 (UTC)[回覆]
但實務上較困難吧？我也不覺得有人會特別注意重新導向有無來源，最好是能直接附在重新導向目標頁面中為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月10日 (三) 12:20 (UTC)[回覆]
@微肿头龙、自由雨日、YFdyh000、Ericliu1912：如果大家不反對的話，我建議把「創建者應在重定向頁面加入證明外文名稱的可靠來源」改為「創建者應在條目本身或重定向頁面的討論頁加入證明外文名稱的可靠來源」。Sanmosa 蚌埠 2024年7月13日 (六) 01:37 (UTC)[回覆]
(＋)傾向支持，甚至「在討論頁」就是我一開始（錯誤）理解的（見WP:頁面存廢討論/記錄/2024/07/09#批量提刪）。不過如果只是在編輯摘要中加入也未嘗不可，至少只要某編者在建立時提供了來源，就不能說他是「未遵守方針濫建外文重定向」。--——自由雨日（留言・貢獻） 2024年7月13日 (六) 01:47 (UTC)[回覆]
放在編輯摘要並非不可，但遇上失效連結的時候不好處理，放在討論頁至少還能存檔來源。Sanmosa 蚌埠 2024年7月13日 (六) 01:49 (UTC)[回覆]
(＋)支持，不過我不覺得會有多少人加來源。--微腫頭龍（留言） 2024年7月13日 (六) 04:37 (UTC)[回覆]
建議改為「條目本身或重新導向頁面的討論頁」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月13日 (六) 18:12 (UTC)[回覆]
不反對，已調整。Sanmosa 蚌埠 2024年7月14日 (日) 22:34 (UTC)[回覆]

有關巡查豁免權的門檻

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:巡查豁免權、Wikipedia talk:權限申請。

近期希望提名一位有突出貢獻且編輯及創建過多篇GA及DYK的用戶獲得巡查豁免權，希望減輕巡查的壓力，奈何發現該君創建條目數量離75還有一定距離。但我發現巡查豁免權的申請門檻，多處表述均有不同：

請問75條的門檻是否為強制？建議以上各處應統一表述。--Tim Wu（留言） 2024年7月9日 (二) 14:54 (UTC)[回覆]

我傾向於並非強制性，能建GA的話想必也不會出大問題。Sanmosa 蚌埠 2024年7月9日 (二) 15:01 (UTC)[回覆]
我記得以前有未達建議標準而授權的例外情況。--千村狐兔（留言） 2024年7月9日 (二) 15:24 (UTC)[回覆]
改掉編輯提示吧。信任和質量為主，數量不能代表什麼，創建一百個同質化的有效條目不能證明其他方面，除非他不會涉足創建其他條目。--YFdyh000（留言） 2024年7月9日 (二) 16:23 (UTC)[回覆]
此要求並非強制，應考慮統一使用「建議門檻」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月9日 (二) 19:10 (UTC)[回覆]
我自己目前的巡查豁免權就是在滿75條前被推薦拿到的，當時幫我申請的Dewadipper閣下以IAR的理由替我申請了，供上當時紀錄。--WiTo🐤💬 2024年7月10日 (三) 07:58 (UTC)[回覆]
「Wikipedia:權限申請」是程序方針，「Wikipedia:巡查豁免權」是說明具體情況（但不是方針、指引），「Wikipedia:權限申請/editnotice/zh」是申請時的條件說明。第一個的規則性更明顯，但實務上是否認定需要或者強制需要75條條目？可以認定「75條」是建議，或者乾脆讓後兩個複述「Wikipedia:權限申請」的說明，也就是不限制條目數量要求。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月10日 (三) 08:23 (UTC)[回覆]
@TimWu007、Manchiu、YFdyh000、Ericliu1912、WiTo7946、Cwek：通知一下：考慮到各位都傾向於認為75是建議門檻，而編輯提示顯然地從任何意義上都不可能是方針指引條文，因此我已經將所有相關的編輯提示（zh版、繁簡體版、6種地區模式版）裏的「基本」都改成「建議」了。我相信這裏的潛在問題已經基本解決。Sanmosa 蚌埠 2024年7月10日 (三) 12:12 (UTC)[回覆]
建議把Wikipedia:巡查豁免權升級為指引，以便看齊其他權限頁面和門檻。L'Internationale, Sera le genre humain! ✏️ 2024年7月10日 (三) 15:43 (UTC)[回覆]

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

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

重提注音格式要求

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

先前討論總體上有通過的希望，但是後來因討論不活躍存檔。現在10個月後重新提案：

在格式手冊「表格」一章後加入

提議條文

注音

條目名及其別名中某字不屬於常用字，或者屬於常用字的不常見讀音的（如有特殊讀音的姓、特定領域專有讀音等），推薦在其首次出現（一般為條目定義句）處注音。

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

  1. 在以下三個常用字表中均出現的漢字視為中文維基百科的常用字：
    1. 《通用規範漢字表》的一級字或二級字（共6500字）（中國大陸）[1]；
    2. Big5碼定義的常用字（共5401字）（臺灣）；以及
    3. 《常用字字形表》（共4762字）（香港）[2]。
  2. 由條目的需要的前置知識可以推斷讀者知道某字的讀音的，認為是常用字，比如在2-氨基-7,7-二甲基-2',5-二氧亞基-5,6,7,8-四氫螺［苯並吡喃-4,3'-吲哚啉］-3-甲腈中無須註明「腈」字的讀音，但是在腈中需要；
  3. 根據編者實際調查，可以找到語料證明在兩岸四地都常用的字。

編者決定是否注音時，應該考慮到兩岸四地的使用實際和語言流變。在判斷過程中，僅有繁簡或常用異體差別的漢字均視為同一漢字（如「羣」（香港）與「群」（中國大陸、臺灣）視為同一漢字）。

為字詞注音時，編者可以自由選擇在文章內標註，也可以外鏈至維基詞典。

如果使用行內注音，推薦使用字詞轉換機制在不同變體下分別展示各地區模式適用的注音模式：

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

可使用{{zy}}來實現頂頭標註。

如果外鏈至維基詞典，應該保證目標詞條中有記錄讀音，並且包含條目中的使用情況。

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

現在各個方案的樣子：

  1. 富勒氏長爪鶺鴒（「鶺」，拼音：jí，注音：ㄐㄧˊ，粵拼：zik3、「鴒」，拼音：líng，注音：ㄌㄧㄥˊ，粵拼：ling4，中國大陸作福氏長爪鶺鴒，南非語：Angolakalkoentjie。學名：Macronyx fuelleborni）是……（不用字詞轉換的行內）
  2. 富勒氏長爪鶺鴒（「鶺」，粵拼：zik3「鴒」，粵拼：ling4，中國大陸作福氏長爪鶺鴒，南非語：Angolakalkoentjie。學名：Macronyx fuelleborni）是……（用字詞轉換的行內）
  3. 富勒氏長爪鶺（zik3）鴒（ling4）（中國大陸作福氏長爪鶺鴒，南非語：Angolakalkoentjie。學名：Macronyx fuelleborni）是……（{{zy}}）
  4. 富勒氏長爪鶺鴒（中國大陸作福氏長爪鶺鴒，南非語：Angolakalkoentjie。學名：Macronyx fuelleborni）是……（{{wikt sup}}）
  5. 羥基（漢語拼音：qiǎng；注音符號：ㄑㄧㄤˇ；粵拼：keong5 *）（和1不同於最後的星號）
  6. 還有用腳註的不演示

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

cc 原討論部分參與者@Sanmosa、LuciferianThomas、118.170.4.163、Nostalgiacn：

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

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

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

然後另外件小事，這長爪鶺鴒實際上還有更上層的分級：是鶺鴒科長爪鶺鴒屬，但讀者實際操作上也不太可能一路從上層分類點進下層頁面去吧...？以及若其最上層是亞目、亞科等預設不顯示（除非有特地呼叫display parent）的次要分類單元的話那要怎麼辦？覺得不要把常用字限太死。--WiTo🐤💬 2024年7月15日 (一) 08:43 (UTC)[回覆]

技術

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

本主題或以下段落文字，移動自Wikipedia:互助客棧/條目探討。

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

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

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

有多少字？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月6日 (一) 17:39 (UTC)[回覆]
老實說我不知道，我目前也只是偶然發現有幾個字是這樣的狀況。但辶、門、金、食、馬、鳥、魚等字旁的字個人猜測可能會有不少這種情形，應該會需要電腦協助篩出有在Unihan擴充區內但不在表內的字。範圍上可能從擴充A區就要開始找了，A區的「鷿鷈」疑似就有類似情形（北美䴙䴘属、北美鸊鷉屬、北美鷿鷈屬，不過這組有牽涉到異體字的問題可能不一定真是如此）--WiTo🐤💬 2024年5月7日 (二) 00:33 (UTC)[回覆]
根據我近期看到的一些中文學術著作，似乎並沒有統一的做法，有人就用繁體字，有人則用簡體字（生物類）--百無一用是書生 (☎) 2024年5月7日 (二) 09:36 (UTC)[回覆]
僅考慮學術用字的話幾百個應該還是有的，但如果範圍擴大至所有領域恐怕得去到一千個以上（尤其是古人名、古地名）。--微腫頭龍（留言） 2024年5月7日 (二) 01:43 (UTC)[回覆]
忘了副知提醒我此事的@微腫頭龍閣下及當時先使用了𫛚一字的@Interaccoonale閣下。--WiTo🐤💬 2024年5月7日 (二) 00:40 (UTC)[回覆]
這個討論串是否應該移動到技術版？--——🦝Interaccoonale（留言・貢獻） 2024年5月7日 (二) 01:18 (UTC)[回覆]
我大概說一下我的想法：
  • 從法律上講，之前《通用規範漢字表》的草案有規定過表外漢字不類推簡化，但是正式版把這一條刪掉了，所以含有類推簡化偏旁的表外漢字是應該簡化的。
  • 從實際應用上講，《中華人民共和國國家重點保護野生動物名錄》對於生物中文名的表外漢字作類推簡化處理，大部分正式學術著作也作類推簡化處理。
  • 從技術上講，如果相關的bug實在太多，我不反對改回原狀，對於表外漢字在簡體模式下顯示繁體字。
我之前有思考過比當前的{{僻字}}模板更優雅的渲染方式，我之前想的是根據當前頁面中包含的擴展區段字符，自動生成一個含有相關僻字的字體文件（字形檔），然後用CSS引入到當前頁面中，就可以避免這種恐怖的懸浮文字框（有時候這些文字會被顯示在Tools-redirect中以及底部的頁面分類裏面，會變得尤其可怕）。比如大麻鷺屬就會自動生成一個僅含有𫛚字的字體文件（字形檔）。
其實如果只考慮自動生成的部分，在技術上還不算太難，以遍黑體為基礎字體（字形）就可以，能在伺服器端編輯字體文件（字形檔）的庫也有很多。但是我不清楚要如何跟mediawiki整合起來。
另一種技術上更簡單（但是操作上更複雜）的方法就是手動將相關字符拆分出來，然後上傳到commons，然後在頁面中引用即可。--——🦝Interaccoonale（留言・貢獻） 2024年5月7日 (二) 01:31 (UTC)[回覆]
若根據NC:COMMON的話，那就應該是要隨名錄名稱類推簡化沒錯了。但希望能以操作上簡易的方式處理，不然像我這種電腦技術笨蛋恐怕就不會操作了，不過命名標題會不會有需要額外調整？另若認為搬去技術版更合適，那還請協助移動。--WiTo🐤💬 2024年5月7日 (二) 03:27 (UTC)[回覆]
我早前用字形wiki的字體做過一個小工具來實現類似你說的這種方法，後來因為技術和安全原因失效了。其實現在仍然可以利用字形wiki的字體資源來實現，只是要把字體之類的資源搬到toolforge上去，然後本地用小工具調用。c區似乎不能上傳字體文件？「根據當前頁面中包含的擴展區段字符」其實並不是一個很好的做法，因為每個人電腦/終端上的字庫未必不一樣，在甲上不能正常顯示的字形，在乙那裏沒準就可以正常顯示。所以最好的辦法是自動檢測某人設備上哪些字形不能正常顯示，不能正常顯示的就即時下載相應的字形文件（可能會遇到一些優化工作要做）。目前來說，我知道的是這種自動檢測方法chrome和firefox下都有解決方案，其他瀏覽器內核的不確定--百無一用是書生 (☎) 2024年5月7日 (二) 09:47 (UTC)[回覆]
  • chrome檢測法：將代表不能顯示的字符形狀映射到畫布，然後將文本中的每個字符一個一個映射到畫布並進行比較，如果比較結果一致，就表示該字符無法在這個設備上顯示
  • firefox檢測法：將文本中所有字符設為斜體，如果某個字符不是斜體，就表示該字符無法在這個設備上顯示（比如𱎼家人和𱎼家人）
--百無一用是書生 (☎) 2024年5月29日 (三) 04:05 (UTC)[回覆]
@T45614631、Interaccoonale、Ericliu1912：我根據知乎上的一些文章整理出來了未被收錄進《通用規範漢字表》的科學技術用字，見我的子頁面User:微腫頭龍/E。這個表肯定是不完整的，歡迎補充。--微腫頭龍（留言） 2024年5月7日 (二) 06:52 (UTC)[回覆]
這樣看起來的話，有些表外字還是有被正常轉換耶，像是魟、鰠、鎶等，那是被手動增加轉換的嗎？--WiTo🐤💬 2024年5月7日 (二) 07:49 (UTC)[回覆]
那幾個字確實已經加入全域轉換了。這裏有維基百科的完整繁簡轉換表--微腫頭龍（留言） 2024年5月7日 (二) 09:01 (UTC)[回覆]
所以現在算是有共識要處理這個繁簡問題嗎？感覺上這些字遲早會變成正規簡化字...--WiTo🐤💬 2024年5月13日 (一) 03:47 (UTC)[回覆]
@Shizhao、Interaccoonale、T45614631、Ericliu1912：所以幾位覺得需要處理這些繁簡問題嗎？還是放着不用理？我個人是覺得需要簡化。--微腫頭龍（留言） 2024年5月16日 (四) 07:48 (UTC)[回覆]
我是支持簡化的，但還是要考慮顯示的問題？——🦝Interaccoonale（留言・貢獻） 2024年5月16日 (四) 08:16 (UTC)[回覆]
@Interaccoonale：其實就我個人來說{{僻字}}就已經夠用了，但如果有更好的方式也可以。我的電腦技術很差，這方面就愛莫能助了。--微腫頭龍（留言） 2024年5月16日 (四) 08:36 (UTC)[回覆]
目前維護內置轉換表的管理意見，應該是大部分都只轉換到中日韓統一表意文字擴展B區，後面擴展區域的因為大部分設備字體兼容性不足，一般不轉換（大部分類推簡化的繁體本字能正常顯示）。上面有表外漏轉漢字可能要從擴展A區開始找的觀點，我(＋)支持這種找法，擴AB兩個區先查一遍看看有什麼沒轉換的。至於後面的擴展區我暫保持中立。--屠麟傲血（留言） 2024年5月17日 (五) 14:53 (UTC)[回覆]
那我就轉到技術區看要有沒有人能處理這問題了。--WiTo🐤💬 2024年5月25日 (六) 03:50 (UTC)[回覆]
拿腳本找了一下Unihan數據庫（裏面可能有不適用的，例如「奨，奬」還有大部分一簡多繁轉換）：
篩選出了簡繁皆為基礎及擴AB區的
--User:What7what8🏠 2024年5月25日 (六) 06:51 (UTC)[回覆]
如果通過的話，WP:R3可能也有需要更改。--User:What7what8🏠 2024年6月14日 (五) 03:12 (UTC)[回覆]
如果通過的話Template:繁簡混雜重定向也要改，不過只有幾個頁面應該不難改。--User:What7what8🏠 2024年5月25日 (六) 07:52 (UTC)[回覆]
粗略看來一下閣下列出的，當中有些是違反簡化規則的。比如「㳕,灡」，「蘭/兰」字位於《簡化字總表》的第一表，因此是不可類推簡化的。也就是說，如果有一天「灡」字被列為規範漢字，也僅會對「門」部件進行簡化變成「𬞕」，而不是將整個「蘭」進行簡化。再比如「䓕,薳」，由於「遠/远」也是不可類推簡化部件，所以「薳」也是不必簡化的，剛巧《通用規範漢字表》就有收錄「薳」字。所以閣下的這個恐怕要進行超大規模的整理才能提交啊。而且我覺得沒有具體使用例子的就沒必要簡化了。不過還是要感謝一下閣下把它們整理出來。@What7What8：--微腫頭龍（留言） 2024年5月25日 (六) 13:40 (UTC)[回覆]
另外想問一下哪一種字體支援最完整？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月26日 (日) 03:41 (UTC)[回覆]
應當是宋體吧，因為Unicode的文件也是宋體，Microsoft在顯示生僻字時好像也是默認宋體。--微腫頭龍（留言） 2024年5月26日 (日) 03:46 (UTC)[回覆]
宋體是字體風格不是一種字體。--Miyakoo（留言） 2024年5月26日 (日) 11:05 (UTC)[回覆]
好吧，是我搞錯了兩個概念。謝謝指出。@Miyakoo：--微腫頭龍（留言） 2024年5月26日 (日) 11:09 (UTC)[回覆]
Unifont吧，不過是點陣字形，可以參考Wikipedia:Unicode擴展漢字還有Template:Unihan
( π )題外話，Special:鏈入頁面/Wikipedia:Unicode擴展漢字「𰻞𰻞面 ‎ （← 連結 | 編輯）」怎麽全變方框了，還有𱎼家人的標題「家人」也變成方框了，是有什麽bug嗎？--User:What7what8🏠 2024年5月26日 (日) 15:30 (UTC)[回覆]
Firefox正常顯示，Chrome顯示方框。--Kethyga（留言） 2024年5月29日 (三) 00:38 (UTC)[回覆]
我這裏不能復現--百無一用是書生 (☎) 2024年5月29日 (三) 03:28 (UTC)[回覆]
我這也是，認真說應該是我兩台電腦都開chrome，一台正常顯示，另一台則是全方框。--WiTo🐤💬 2024年5月29日 (三) 05:34 (UTC)[回覆]
天珩全字庫（大陸標準）和字雲（日本標準），它們都支援到了I區。--Miyakoo（留言） 2024年5月26日 (日) 10:58 (UTC)[回覆]
目前轉換表主要是我在維護，過來解釋一下。確實如上文所說，目前只支持到中日韓統一表意文字擴展B區及以前的規則，B區之後基本只支持了通用規範漢字表表內的規則。這麼做主要還是考慮到大眾用戶的設備顯示，現在大家使用手機訪問的頻率變得更高，但目前手機顯示基本只支持到擴展A區+所有表內漢字，因此不敢妄作擴張，怕反而傷害了用戶的閱讀體驗。—Chiefwei（論 - 歷） 2024年6月8日 (六) 13:23 (UTC)[回覆]

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

Module:Mapframe、Module:Location map報錯

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

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

我也注意到了；似乎在條目內將{{coord}}中的display=title改為display=inline,title可以解決報錯。從時間上看，會不會和為了解決上面的問題（#Template:Infobox_body_of_water中的坐標會重複兩次），Shizhao在Module:Coordinates的幾個編輯（82849253）有關？Irralpaca（留言） 2024年6月9日 (日) 11:12 (UTC)[回覆]
看來似乎是Module:Coordinates修改後，導致Module:Location_map#L-122取不到/取錯值了--百無一用是書生 (☎) 2024年6月9日 (日) 12:17 (UTC)[回覆]
改為display=inline,title或者display=inline都可以解決報錯--百無一用是書生 (☎) 2024年6月9日 (日) 12:30 (UTC)[回覆]
測試了一下，Module:Location map用display=title的時候，坐標並不會顯示在標題右上角（直接就不顯示），似乎這樣和coord對參數的聲明不符合？--百無一用是書生 (☎) 2024年6月9日 (日) 12:36 (UTC)[回覆]
最近更新了Module:Coordinates，似乎這個問題解決了？--百無一用是書生 (☎) 2024年7月14日 (日) 11:54 (UTC)[回覆]
好像是解決了。--Kcx36（留言） 2024年7月14日 (日) 11:57 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

Wikiplus導致Navbar被換行

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

RT，{{Navbox}}模板最近才出現的問題，啟用Wikiplus後會導致Navbar被換行，粵維無此問題。--Dabao qian℡ 2024年6月12日 (三) 18:19 (UTC)[回覆]

您是指快速編輯按鈕沒有和查論遍在同一行？——暁月凜奈 (留言) 2024年6月12日 (三) 18:51 (UTC)[回覆]
他會不會說的是「編」被挪到了下一行的問題？我也困擾一段時間了，之前顯示是「查·論·編/(快速編輯)」，但近段時間一直顯示為「查·論·/編(快速編輯)」了。--自由雨日（留言） 2024年6月12日 (三) 19:00 (UTC)[回覆]
沒錯，而且粵維的顯示就是正常的「睇·傾·改(快速編輯)」無換行，不知道中維哪個CSS出了問題。--Dabao qian℡ 2024年6月13日 (四) 08:30 (UTC)[回覆]
涉及排版的因素挺多的，不同設備可能區別明顯，我目前未遇到此問題，不過此前也有過。zh和yue的網站設置有一些區別，最近的話可能是zh的字號調整。模板的css似乎並沒有更動。——暁月凜奈 (留言) 2024年6月13日 (四) 08:39 (UTC)[回覆]
Timeless用戶表示已出現了一段時間orz--Tim Wu（留言） 2024年6月13日 (四) 08:48 (UTC)[回覆]
粵維是連「(快速編輯)」都不會換到下一行嗎？（粵維我不是自動確認用戶，看不了Wikiplus效果。）我在中維一直是必看到換行的，只不過之前是「查·論·編/(快速編輯)」這種換行方式，相對來說還算美觀。我以為「快速編輯」肯定會被換行……--自由雨日（留言） 2024年6月13日 (四) 09:27 (UTC)[回覆]
.navbox-title .navbar { width: 8em; }，加上那個按鈕後寬度爆掉了，就這麼簡單。（粵維這行被拆掉了）--SunAfterRain 2024年6月15日 (六) 10:56 (UTC)[回覆]
已修復，但留意到問題：最近@Shizhao：修改Common.css後，navbar「查論編」這三個字的顏色，不能被設置了（詳見Template:香港電台頻道及該模板在今年4月30日的存檔）。--Tim Wu（留言） 2024年6月19日 (三) 07:46 (UTC)[回覆]
Module:Navbar/styles.css，.navbar-mini abbr { color: inherit !important; }，加上這個之後顏色就不能設置了。而且font-size: 88%;這行也應該去掉，中文似乎不需要。--Dabao qian℡ 2024年6月19日 (三) 09:25 (UTC)[回覆]
為求省事抄的enwiki--百無一用是書生 (☎) 2024年6月19日 (三) 13:55 (UTC)[回覆]
不加這行，「查論編」在dark模式下是黑色字，看不清，我暫時沒找到其他的修改方法...--百無一用是書生 (☎) 2024年6月19日 (三) 14:04 (UTC)[回覆]
Module:Navbox的第62行fontstyle = (args.basestyle or '') .. ';' .. (args.titlestyle or '') .. ';background:none transparent;border:none;'沒有定義color:inherit;。--Dabao qian℡ 2024年7月4日 (四) 16:23 (UTC)[回覆]
把background:none transparent;刪掉不知行不行--百無一用是書生 (☎) 2024年7月5日 (五) 03:46 (UTC)[回覆]
經測刪掉會露出自定義背景顏色--Dabao qian℡ 2024年7月5日 (五) 07:09 (UTC)[回覆]
完成--百無一用是書生 (☎) 2024年7月5日 (五) 08:34 (UTC)[回覆]
把color:inherit;放到最前面才對吧，不然自定義字體顏色還是會被覆蓋掉，以及Module:Navbar/styles.css里的hack可以去掉了。--Dabao qian℡ 2024年7月5日 (五) 08:41 (UTC)[回覆]
話說，修復之後，navbar的顏色怎麼變成無色了 囧rz……--自由雨日（留言） 2024年6月20日 (四) 14:32 (UTC)[回覆]
上幾行留言正是在討論此事……--Cookai餅塊🍪（💬留言） 2024年6月20日 (四) 14:35 (UTC)[回覆]
啊？上面不是在討論「查論編」三個字（而非背景）的顏色嗎……--自由雨日（留言） 2024年6月20日 (四) 14:38 (UTC)[回覆]
抱歉看錯了，背景色是深色模式強制覆蓋掉的。--Cookai餅塊🍪（💬留言） 2024年6月20日 (四) 14:47 (UTC)[回覆]
我沒有開深色模式……？而且剛好就是修復之後變成淺色的……--自由雨日（留言） 2024年6月20日 (四) 16:54 (UTC)[回覆]
 已修復，之前改壞了--百無一用是書生 (☎) 2024年6月21日 (五) 09:15 (UTC)[回覆]
8em那個是因為看到有個導航框的標題歪掉了（忘了是哪個了）--百無一用是書生 (☎) 2024年6月19日 (三) 13:52 (UTC)[回覆]
8em和font-size:88%其實在Template:Navbox寫過說明了。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月19日 (三) 11:24 (UTC)[回覆]
簡單調整之後發現了新問題，很多導航框的副標題歪掉了，比如Template:芒果超媒。--Dabao qian℡ 2024年6月25日 (二) 16:29 (UTC)[回覆]
並不是副標題歪了，而是標題歪了（）明顯是「快速編輯」按鈕把標題往右「擠」了，不過具體算法我就不懂了……另外上面的回覆（8em之類的）似乎就是Shizhao等前輩在研究這一問題。--自由雨日（留言） 2024年6月25日 (二) 21:50 (UTC)[回覆]
如果綜合來看的話，可能是自己引用的wikiplus導致破壞微妙的平衡。結合「Module:Navbox」和Navbar的設計，Navbar在Navbox默認在左邊為固定width:8em，為了保持平衡，右邊的摺疊按鈕塊也是固定width:8em。而且還有根據是否啟用navbar、是否禁用摺疊按鈕狀態（常見對應是子塊Navbox作為嵌套到父塊中），來補充一個固定的8em空白塊來填補位置（具體看Navbox模塊的renderNavBar方法）。8em可能考慮Navbar常見就3個字+2個間隔號，就算是4個字（查編歷討）+3個字也是7em，因此預留8em。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 02:17 (UTC)[回覆]

美國縣級行政區地圖顯示故障

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

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

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

如弗吉尼亞州縣級行政區列表，密西西比州縣級行政區列表，密蘇里州各縣列表，馬里蘭州行政區劃，愛達荷州縣級行政區列表等列表中的小地圖顯示故障，只顯示一個紅色塊而沒有網格，同時對應各縣的條目的地圖也是一樣的問題，好像是原圖批量出了問題？

--桃花影落飛神劍（留言） 2024年6月17日 (一) 15:43 (UTC)[回覆]
是批量出了問題，我建了很多個縣都是這樣子。經調查，這不是本人能力範圍內能解決的，只能坐等一天恢復正常。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月17日 (一) 15:51 (UTC)[回覆]
是維基共享使用的底圖出問題了，各種語言維基都有顯示問題。這邊不動手，英維那邊也會吵起來，讓相關人員處理。這個應該算是技術問題？大概很快就有{{Tracked}}的工單。--Nostalgiacn（留言） 2024年6月17日 (一) 16:59 (UTC)[回覆]
懷疑與最近librsvg版本升級有關--百無一用是書生 (☎) 2024年6月18日 (二) 03:02 (UTC)[回覆]
根據phab:T367645#9902624的說法，svg文件原本就有問題，只是沒有表現出來，librsvg升級後這個問題變嚴重了。可以參考下這個[15]，一大堆的報錯--百無一用是書生 (☎) 2024年6月19日 (三) 02:25 (UTC)[回覆]
舉例的圖片，以上傳新圖片解決了。不過仍然有很多圖片沒有上傳新圖片取代。如右圖（Virginia）
Virginia
--Nostalgiacn（留言） 2024年6月30日 (日) 06:50 (UTC)[回覆]
工單上編者Nux已經使用機械人替換相關圖片，美國相關圖片已經替換。不清楚是否有有其他國家或地區使用同類圖片，Phabricator上的工單已經標記完成，關閉了。--Nostalgiacn（留言） 2024年7月7日 (日) 02:53 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

TW部分功能故障

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

  1. 存廢討論中三級標題右側不出現「關閉討論」
  2. 在存廢討論中無法關閉討論，只能刪除相關提刪頁面或移除相關提刪頁面的模板，但無法關閉相應的討論
  3. 另外發現Wikipedia:頁面存廢討論/記錄/2024/06/22使用tw關閉討論時，發生了錯位（「賴擁連」錯位到了「Code Geass角色列表」，「Category:各國縣治、Category:縣治」錯位到了「家庭教師HITMAN_REBORN!角色列表」），當時#2問題還未發生

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

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

Attached KML模板的display=title顯示位置有問題

本主題全部或部分段落文字，已移動至Template talk:Attached KML。執行人：Jimmy-bot（留言） 2024年7月15日 (一) 08:14 (UTC)。[回覆]

維基百科:其他語言的維基百科典範條目/英語版這樣的標題是否屬於繁簡混用？

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

命名常規的簡繁統一僅約束條目。要求子頁面統一簡繁會帶來很多麻煩，討論存檔、新建子頁面，需要手動轉換簡繁。有/分割，也不會有轉換分詞等問題。--YFdyh000（留言） 2024年7月1日 (一) 15:32 (UTC)[回覆]
許多時候區分繁簡或許還別有意義。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月3日 (三) 10:59 (UTC)[回覆]
原來如此 Midleading（留言） 2024年7月6日 (六) 12:29 (UTC)[回覆]

像Category:埃里克·貝特爾森命名的生物分类這樣的分類名是否屬於繁簡混用呢？ Midleading（留言） 2024年7月12日 (五) 08:18 (UTC)[回覆]

理論上不算，https://dict.variants.moe.edu.tw/dictView.jsp?ID=50466 。
不過維基百科系統無法自動轉換。--Miyakoo（留言） 2024年7月12日 (五) 08:57 (UTC)[回覆]

在導航模板中淘汰過時的可摺疊表格支持

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

參見MediaWiki talk:Common.css、MediaWiki talk:Common.js、Module talk:Navbox，對應上述三處編輯請求，停用導航模板中過時的可摺疊表格支持，改為MediaWiki自帶的摺疊語法。--Dabao qian℡ 2024年7月3日 (三) 20:56 (UTC)[回覆]

使用mw核心提供的表格摺疊會不會存在問題？能否復刻一個樣式看看？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 00:44 (UTC)[回覆]
Template:Navbox/sandbox3、Module:Navbox/sandbox3、Template:香港行車隧道/sandbox。mw版技術手冊mw:Manual:Collapsible_elements。另外好像有億點點小問題：默認預設摺疊的參數等和本來的不一致（mw的是「mw-collapsed」、而我們腳本是「collapsed」；上面的例子就是改了mw後加的是我們腳本的參數，當然意料之內不生效；需要統計Navbox下加了這個參數有多少影響和是否需要兼容機制），另外我們實現的摺疊腳本有自動摺疊機制：掛了「autocollapse」的結構，數量超過2個時會默認全部摺疊起來。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 01:05 (UTC)[回覆]
MediaWiki:Gadget-collapsibleTables.js英維3.0版本改了機制，會給有collapsible和collapsed的地方自動疊加帶mw-的class（純向下兼容），中維因為涉及到導航模板所以暫時沒有部署（仍沿用2.04版本）。autocollapse、innercollapse和outercollapse需要修改Common.js才能實現。--Dabao qian℡ 2024年7月4日 (四) 01:56 (UTC)[回覆]
User:Dabao qian/common.js這裏的最後兩段腳本，一是為mw-collapsible增加autocollapse、innercollapse和outercollapse三種元素的支持，二是3.0版本的可摺疊表格支持。--Dabao qian℡ 2024年7月4日 (四) 02:06 (UTC)[回覆]
可能還需要更新en:MediaWiki:Gadget-collapsibleTables.js等配套腳本，需要更多測試，而不是說換就換。當然怕出問題的話，沒壞別修。就像一堆java 8、java 6不升級的——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 02:34 (UTC)[回覆]
其他語言的可摺疊表格支持都是直接放在Common.js的，不像中維是以小工具的形式提供。需要灰度測試的話，關掉小工具里的可摺疊表格支持，然後複製User:Dabao qian/common.js和MediaWiki talk:Common.css裏面的相關代碼到您的用戶頁JS/CSS就可以了。不過英、粵維早就已經實際運行很長時間了，問題應該不大。--Dabao qian℡ 2024年7月4日 (四) 02:39 (UTC)[回覆]
需要將相應的功能整理成單獨的腳本，然後通過小工具或者Commons.js引入。初步來看是暫時沒看出還有什麼明顯問題，但也要考慮為什麼很多看上去應該全站點代碼一致的站點自定義功能，實際操作上都是脫同步的——每個站點具體實施上又加了自己的調整。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 02:49 (UTC)[回覆]
好像改了會不會影響標題居中？為了保證標題居中，我寫的User:Cwek/collapsibleTables.js默認給了摺疊按鈕8em的寬度，Navbar按照以前也給了8em的寬度。如果改了mw加Navbar不固定寬度的話，標題稍微略微偏右？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 01:37 (UTC)[回覆]
好像哪裏見過MediaWiki:Gadget-collapsibleTables.js、Navbox、或者配套的css，摺疊按鈕是設定8em，所以我的實現也跟着8em。如果要保持Navbox內標題居中的話，必須Navbar（還有它的空白替代塊）和摺疊按鈕塊的寬度一致，才能將標題擠到居中。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 03:06 (UTC)[回覆]
Special:Diff/83093979，左右平衡的實現語法在Common.css，新版的話就用mw-collapsible-toggle替換掉collapseButton。--Dabao qian℡ 2024年7月4日 (四) 04:10 (UTC)[回覆]
試過，這樣做法不是左右平衡的。因為兩個塊的長度不等，所以擠占的中間塊不是完全居中，所以才搞固定寬度。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 06:44 (UTC)[回覆]
@Dabao qian：如果啟用摺疊按鈕塊，保證Navbox標題居中，摺疊按鈕初始化時需要讀取同行Navbar的寬度，然後手工設成相同。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 07:50 (UTC)[回覆]
我測算的話，Narbar的寬為49.563、摺疊按鈕的寬為34.266。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 01:39 (UTC)[回覆]
居中問題有沒解決思路？當然Wikiplus的是它自己的問題，沒必要考慮它的感受。建議的話，可以考慮Wikiplus做個兼容補充，劫持編輯連結，改成彈窗形式機制詢問是快速編輯還是傳統編輯，從而不用因為額外添加內容導致box溢出偏移，維持Navbox內Navbar和摺疊按鈕微妙的寬度平衡。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 02:57 (UTC)[回覆]
英維的Navbox早就改了好幾回了，粵維當前版本也早就不是中維當前版本了，不再需要Common.css定義寬度，而且英維的{{Navbar}}是不會出現快速編輯按鈕的。--Dabao qian℡ 2024年7月4日 (四) 04:18 (UTC)[回覆]
那就測試一下，兩個塊不固定寬度後，能不能保證標題居中？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 06:30 (UTC)[回覆]
提起「Wikiplus」，是因為上面提到類似問題，所以猜測Wikiplus的編輯按鈕修改是否會影響。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 06:42 (UTC)[回覆]
英維改了方案，編輯按鈕的連結換成了Special:Editpage內部連結，Wikiplus讀不出來自然也就不會自作主張地額外加按鈕，已經在Module:Navbox提EP按照英維方案修改。--Dabao qian℡ 2024年7月4日 (四) 08:02 (UTC)[回覆]
那不就是Wikiplus的問題，Wikiplus沒有正確識別出編輯連結，自己處理錯了，為什麼不是Wikiplus去自己修正？而且代碼不一定要跟en同步吧？而且編輯部分不應該是Navbar去實現的？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 08:18 (UTC)[回覆]
你說的編輯連結問題，就是我們的Navbar還是用fullurl+action=edit生成連結（Module:Navbar#L-81），而en是用內鏈+加上Special:EditPage特殊頁生成內鏈（en:Module:Navbar#L-70）。在連結生成上沒明顯差異。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 08:26 (UTC)[回覆]
@Dabao qian：，Navbar的生成模式上，編輯和歷史的連結生成模式，只需要移植這部分（en:Module:Navbar#L-69--L-72）就對應了。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 08:37 (UTC)[回覆]
[17]，分別是固定寬、不固定寬，使用mw摺疊、小工具摺疊、小工具改寫摺疊的樣式。如果固定寬度的話，標題字會更接近中間。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 07:05 (UTC)[回覆]
打開F12實時調試使用mw摺疊且按照舊版Common.css方案設定兩端固定寬度8em之後效果與小工具改寫摺疊相差無幾--Dabao qian℡ 2024年7月4日 (四) 08:50 (UTC)[回覆]
@Dabao qian：你調成這樣當然沒問題了。這裏分兩個主要部分：1.改用mw摺疊，可以考慮，但需要一組兼容性腳本用於處理自製摺疊參數的兼容處理和自動摺疊處理；2.標題居中，需要Navbox中的Navbar和摺疊按鈕塊的寬度固定且相等，這可能需要腳本控制而不能靠css的自動寬度控制（因為兩者長度大概率不等，需要腳本比較計算和注入覆蓋）；2.1.Wikiplus的撐爆，一定程度上和Navbar固定寬有關，要麼Wikiplus自己適配，要麼結合前面前面計算新的寬度和重新注入。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 09:31 (UTC)[回覆]
1.User:Dabao qian/collapsibleTables-new.js以及MediaWiki:Common.js和MediaWiki:Common.css的兩處EP即可實現；2.似乎沒有找到其他合適的方法--Dabao qian℡ 2024年7月4日 (四) 09:37 (UTC)[回覆]
第1點暫時seems good。雖然我更喜歡我自己寫的，能使th那一欄同時也綁定上摺疊按鈕功能。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月4日 (四) 09:53 (UTC)[回覆]
經測試啟用Wikiplus後兩端寬度設為10em即可避免撐爆。--Dabao qian℡ 2024年7月4日 (四) 16:05 (UTC)[回覆]
那應該是Wikiplus自己搞，還是學微軟幫用戶擦屁股？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月5日 (五) 00:40 (UTC)[回覆]
我有個問題，我同時用Wikiplus和InPageEdit應該怎麼辦[開玩笑的] ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年7月5日 (五) 15:05 (UTC)[回覆]
那只能自己寫腳本（js或者css）適配了，簡而言之，兩個塊固定寬度且相等就可以保證navbox標題擠占居中。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月6日 (六) 00:27 (UTC)[回覆]

更新清單

  2. 以上完畢了，才需要更新Module:Navbox、Module:NavboxV2的摺疊參數調整。
@Dabao qian：如果理解和沒異議的話，可以推進下去。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月5日 (五) 02:20 (UTC)[回覆]
無異議，寬度和深色模式適配的問題後續再議（當然這不屬於本次討論範圍）。--Dabao qian℡ 2024年7月5日 (五) 03:46 (UTC)[回覆]
@Dabao qian：，看了collapsibleTables-new.js，其實Module:Navbox、Module:NavboxV2不用換，因為按照腳本邏輯，「table.collapsible:not(.mw-collapsible)」就能夠選出保持兼容class的table，然後後面加上「mw-collapsible」就是加上mw的摺疊功能。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月5日 (五) 08:33 (UTC)[回覆]

UX

啊所以現在想展開已關閉的存廢討論，就必須按右邊的[展開]，而不能直接點擊小藍條了？有點麻煩…… ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年7月14日 (日) 16:55 (UTC)[回覆]

小藍條？是不是一整欄的標題行？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月15日 (一) 00:41 (UTC)[回覆]

條目標題左側出現多餘的「維基百科」

於Phabricator查看
編號T369537的工單

如題，條目標題出現多餘得「維基百科」，今天第一次出現，見截圖，多出的是圖片版的File:Wikipedia-wordmark-zh.svg，像是和MediaWiki:Common.css中的的「content: url(/static/images/mobile/copyright/wikipedia-wordmark-zh-hans.svg);」有關--Kethyga（留言） 2024年7月4日 (四) 12:49 (UTC)[回覆]

不能復現，或許與您使用的js腳本之類的有關--百無一用是書生 (☎) 2024年7月4日 (四) 12:58 (UTC)[回覆]
我使用Timeless，從幾個小時前開始也這樣。--Tim Wu（留言） 2024年7月4日 (四) 13:10 (UTC)[回覆]
我在Timeless下測試，未發現問題--百無一用是書生 (☎) 2024年7月5日 (五) 03:32 (UTC)[回覆]
使用私隱模式復現，可能不是腳本問題（？ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年7月5日 (五) 12:55 (UTC)[回覆]
看起來像是MediaWiki:Common.css#L-1035的問題，似乎只匿名用戶有這問題？應該是Timeless最近更新導致？--百無一用是書生 (☎) 2024年7月5日 (五) 13:23 (UTC)[回覆]
我、Kethyga還有下面的ElectronicGhost都算是匿名用戶？--Tim Wu（留言） 2024年7月5日 (五) 13:25 (UTC)[回覆]
目前我只能在firefox的私隱模式下能復現，chrome私隱模式不能復現（都是未登陸狀態）。兩個瀏覽器非私隱模式登錄狀態下都不能復現--百無一用是書生 (☎) 2024年7月5日 (五) 13:32 (UTC)[回覆]
我在Chrome/Firefox的登錄/私隱模式都出現這個問題……在Chrome登錄小號也復現……怎麼回事 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年7月5日 (五) 14:38 (UTC)[回覆]
本人的Timeless skin，目前只在登錄模式下（Chrome/Firefox）出現，私隱模式下暫時沒有。--Kethyga（留言） 2024年7月5日 (五) 15:06 (UTC)[回覆]
上面結果在私隱模式下未登錄，使用的默認皮膚。--Kethyga（留言） 2024年7月6日 (六) 05:01 (UTC)[回覆]
我在使用Timeless皮膚的情況下，無論使用Safari、Chrome還是Firefox抑或是在各個瀏覽器開啟私隱模式並登陸，這個問題都會出現。 -- ElectronicGhost｜👻 2024年7月6日 (六) 04:48 (UTC)[回覆]
這樣看起來，只有使用小工具和用戶權限的差異了--百無一用是書生 (☎) 2024年7月7日 (日) 06:16 (UTC)[回覆]
造成需要這段站內css的問題已經修復（phab:T369537），在下周部署後可以直接刪除相關段落。--Func（討論·貢獻） 2024年7月10日 (三) 16:55 (UTC)[回覆]

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

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

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

部署配置和時間表

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

如何開啟深色模式

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

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

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

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

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

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

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

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

簡單而言：本週先向桌面版的登入用戶提供深色模式。如果一切順利，便會照原定計劃在下週向未登入用戶提供。--SCP-0000（留言） 2024年7月10日 (三) 02:04 (UTC)[回覆]

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

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

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

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

Timeless顯示錯誤

自昨日開始，在使用Timeless作為皮膚的情況下，打開任意頁面都會在頁面標題前額外顯示一個多餘的「維基百科」字樣。--ElectronicGhost｜👻 2024年7月5日 (五) 07:24 (UTC)[回覆]

@ElectronicGhost 見上方 Wikipedia:互助客棧/技術#條目標題左側出現多餘的「維基百科」--Kethyga（留言） 2024年7月5日 (五) 08:42 (UTC)[回覆]

小工具「編輯段落連結（[編輯]）靠右排列」使編輯按鈕較正常位置偏高

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

印象中這個問題似乎一直存在，今天來客棧提一下，不知道是否是普遍的情況。開啟該工具（可在參數設置->小工具->界面顯示工具一節找到）後，在每一個段落出現「[編輯原始碼/查看原始碼|快速編輯]」都明顯較正常（不開啟該工具）位置高，在條目標題旁邊，因為位置太高，甚至會使「[編輯原始碼/查看原始碼|快速編輯]」文字大約上1/3部分「隱沒」。--——自由雨日（留言・貢獻） 2024年7月7日 (日) 03:04 (UTC)[回覆]

猜測可能是近期系統字體大小調整導致的？--百無一用是書生 (☎) 2024年7月15日 (一) 02:59 (UTC)[回覆]

T:Summer Olympics by year category navigation

本主題或以下段落文字，在討論結束後應存檔至Template talk:Summer Olympics by year category navigation。

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

(＆)建議還是將模板擷取至"YYYY年夏季"，就不會有簡繁問題，雖然可以加入前綴、後綴來達到目的，但然容易產生標題簡繁不一的現象。--Qqkuro66541（留言） 2024年7月9日 (二) 17:40 (UTC)[回覆]
瞭解，看見您已經將模板修改好了，感謝幫助！——Liebhart 💬👩‍🚀 2024年7月10日 (三) 02:52 (UTC)[回覆]

移動版Navbox

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

現在移動版在Wikipedia:命名空間下會顯示Navbox了，不確定正不正常。[18]--User:What7what8🏠 2024年7月7日 (日) 12:20 (UTC)[回覆]

沒留意到技術新聞有相關的更新信息。也沒見到條目放開Navbox等的渲染調整。如果不是wmf開發測試中，或者是以前就可以？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月8日 (一) 00:44 (UTC)[回覆]
顯示的慘不忍睹的正常--百無一用是書生 (☎) 2024年7月8日 (一) 02:35 (UTC)[回覆]
看了眼en。如果沒有過往記錄印證是除條目空間外的navbox是隱藏外，可能是基金會測試？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月8日 (一) 09:36 (UTC)[回覆]

2024年第28期技術新聞

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

近期變更

  • 維基媒體基金會成立了一個新的專門工作組，致力於建構更安全、易於使用和可擴展的Chart圖表，以取代已停用的Graph圖表。訂閱電子報以獲取有關Chart專案的最新進展和其他新聞的通知。
  • CampaignEvents擴充功能現已供元維基、伊博語維基百科和斯瓦希里語維基百科使用，您所在的wiki也可請求部署之。此擴充功能有助於管理活動並提高活動的可見度，以及讓活動籌辦人員能夠使用諸如活動報名工具等工具。參見元維基的CampaignEvents頁面了解部署狀態以及如何請求部署。
  • 編輯超過50次的編輯者現在可以在iOS維基百科App使用「新增圖片」功能。這項功能為維基百科提供了微小但有用的貢獻機會。
  • 感謝為MediaWiki Core做出貢獻的所有人。得益於此，貢獻超過5個補丁的貢獻者比例較去年增加了25%，這有助於確保維基媒體專案平台的永續發展。

問題

  • Vector 2022中出現一個問題，討論頁標籤的顏色始終顯示為藍色，即使不存在頁面本應顯示為紅色。此問題已解決。

未來變更

  • 信任與安全產品團隊希望以儘可能不干擾工具和工作流的方式引入臨時帳號。懇請志願開發者——包括小工具和使用者腳本維護人員——更新您維護的工具和功能的程式碼以應對臨時帳號。團隊已建有說明文件來解釋如何進行更新。了解更多。

技術新聞調查

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

技術新聞由技術新聞編者撰寫，並由機械人送達 • 貢獻 • 翻譯 • 取得協助 • 提供回饋 • 訂閱或退訂。

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

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

檢測模板限制

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

模板限制很煩人，而且往往不知問題具體出在何處。是否有工具可協助編者確認哪裏調用特別多資源？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月9日 (二) 10:38 (UTC)[回覆]

好像沒有很好的方法？頁面「div.mw-parser-output」裏面結尾有段HTML註釋「NewPP limit report」和「Transclusion expansion time report」，可以看那個模板消耗時間和調用次數較多。或者藉助WP:SB將內容逐點替換來分析。不過大部分情況，WP:模板限制基本上都說了：Navbox（尤其是包含大量ilh系的），包含了大量Navbox的Navboxlist，還有太多腳註的reflist系腳註模板。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月9日 (二) 11:21 (UTC)[回覆]

古籍模版似乎默認地區為中華人民共和國

老殘遊記一文可以看到右側模版顯示出版地點為「中華人民共和國」但在代碼中並未體現此內容。在下在模版的頁面也並未見到此項默認選項，是故提出，希望有同仁可以幫忙調整。--懶癌哪天行→Laziness, as no today's excuse. 2024年7月9日 (二) 10:59 (UTC)[回覆]

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

首頁下半部分排版亂了

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

Wikipedia:首頁排版亂了，下方的常用連結和姊妹計劃全都擠到右側了，動態熱門和歡迎詞的間距也變了。查了最近的修改，未發現修改有問題--百無一用是書生 (☎) 2024年7月10日 (三) 02:10 (UTC)[回覆]

看時光機存檔（2024年1月1日）的話，「div.mp-2012-links」、「div.mp-2012-sisters」是放在「div.mp-2012-body」孩子中，與「div.mp-2012-column-left」、「div.mp-2012-column-right」是兄弟。現在是放在「div.mp-2012-column-right」裏面。是不是有腳本可以判斷「div.mp-2012-column-left」和「div.mp-2012-column-right」的高度，然後將前者抽出去？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月10日 (三) 02:26 (UTC)[回覆]
Wikipedia:每日圖片/2024年7月10日，寬度調小一點，不知道有沒問題？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月10日 (三) 02:33 (UTC)[回覆]
應該有腳本做平衡處理，[19]是抽了links和sisters出來平級，[20]則抽了links跟column-left「同寬」嵌進去了。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月10日 (三) 02:35 (UTC)[回覆]
 已修復，最近一次的{{itn}}更新誤刪了一個</div>--百無一用是書生 (☎) 2024年7月10日 (三) 02:50 (UTC)[回覆]
樂。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月10日 (三) 03:07 (UTC)[回覆]

銷售認證模板被我改出了bug

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

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

出錯的文件在Template:Certification_Table_Entry模板，具體出錯的幾行代碼如下： 

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

請問如何修改這一段，讓輸入Silver、gold等英文的時候，模板轉為顯示成銀、白金等中文呢？--Scarsnevergoaway（留言） 2024年7月10日 (三) 08:30 (UTC)[回覆]

Help:解析器函數#switch。目前好像寫反，該「Silver|銀|銀=銀|Gold=金|Platinum=白金|」這樣？代碼很亂沒弄清。--YFdyh000（留言） 2024年7月10日 (三) 13:00 (UTC)[回覆]
謝謝，我明天改改--Scarsnevergoaway（留言） 2024年7月10日 (三) 15:40 (UTC)[回覆]
問題已解決，請求關閉討論--Scarsnevergoaway（留言） 2024年7月13日 (六) 06:35 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

提報DC的小工具什麼時候能更新啊

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:動員令/第二十二次動員令。

如題，都開始好幾天了一直沒人更新腳本，手填既不方便還容易出錯，都沒參與的積極性了（惱）。DC本身的討論頁有不少人反映過了，但也沒見腳本更新……--Nanhuajiaren（留言） 2024年7月11日 (四) 01:26 (UTC)[回覆]

@Nanhuajiaren：目前主持人正在討論中。技術人手不足Orz —— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月11日 (四) 05:35 (UTC)[回覆]
今年和去年的東西幾乎差不多的吧？除了修改常量之外也就去掉界面上新增來源那一行（因為去年有缺來源的小項今年沒有）。--Nanhuajiaren（留言） 2024年7月11日 (四) 07:11 (UTC)[回覆]
@Nanhuajiaren：主要是動員令主持人團隊向來仰賴本站僅有的幾位介面管理員，最近剛好不少在休息，沒空幫忙。這一兩天應該能解決。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月11日 (四) 16:32 (UTC)[回覆]
應該已經好了。--Leiem（留言·簽名·維基調查） 2024年7月12日 (五) 17:13 (UTC)[回覆]

Navbox標題置中

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

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

中維以前的方案是固定寬度左右各保留8em，至於Wikiplus會撐爆那就讓Wikiplus自己修吧。--Dabao qian℡ 2024年7月11日 (四) 10:14 (UTC)[回覆]
不是Wikiplus問題，Template:Navbox中的示例1和3（從上往下數）的確現在往右歪了一點，但示例4卻差不多是居中的。把.navbox-title .navbar的樣式改成margin-right: -1.6em;示例1和3似乎能差不多居中了，但是示例4卻又歪了--百無一用是書生 (☎) 2024年7月11日 (四) 13:01 (UTC)[回覆]
嘗試修了一下[21]，現在除了示例4外，其他看起來差不多都居中了--百無一用是書生 (☎) 2024年7月11日 (四) 13:38 (UTC)[回覆]
但是navbar和展開被擋住了，點不到。--Cookai餅塊🍪（💬留言） 2024年7月11日 (四) 13:42 (UTC)[回覆]
回退了，這樣修改後，左右兩側都無法點擊了--百無一用是書生 (☎) 2024年7月11日 (四) 13:42 (UTC)[回覆]
如果是讓左右側absolute呢？
即Special:PermaLink/83367707加上
.navbox-title .navbar { position: absolute; left: 1em; }

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

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

這樣看上去並沒有什麼問題。當然，Module:Navbox也需要做修改，因為設置|navbar=plain之後產生的佔位符也需要有相同的樣式。 

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

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

@Shizhao：用這個模板來看，可以知道目前標題還是歪的。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月11日 (四) 16:31 (UTC)[回覆]
這樣修改之後Template:JR東日本的車輛似乎顯示有問題，左右兩側的按鈕會和色塊重疊，這種情況需要寫腳本修復到4em才能正常顯示。--Dabao qian℡ 2024年7月11日 (四) 17:44 (UTC)[回覆]
在Special:PermaLink/83367707的基礎上按上述方案分別修改MediaWiki:Common.css和Module:Navbox即可。--Dabao qian℡ 2024年7月11日 (四) 18:57 (UTC)[回覆]
改了，看看是否還有問題--百無一用是書生 (☎) 2024年7月12日 (五) 02:46 (UTC)[回覆]
目前發現的問題是當瀏覽器寬度（window.innerWidth）小於640px時，點擊右側摺疊按鈕後，摺疊按鈕、查論編和標題全都會跑到左側疊在一起。暫不確定是否和本次修訂相關--百無一用是書生 (☎) 2024年7月12日 (五) 03:05 (UTC)[回覆]
可以復現，原先是頁面寬度小於640px時會折行顯示，改完之後強制縮排在同一行就會直接疊在一起。--Dabao qian℡ 2024年7月12日 (五) 18:16 (UTC)[回覆]

現有的技術能否做到將新條目自動加入相關專題的新進條目列表內

我記得現在專題頁面有個機械人，可以查看最近在評選FA、GA、DYK的各專題相關條目。但我打開音樂專題，發現新進條目這裏還是靠人去手工加入的。能否讓機械人自動更新一下，把近三十天創建的，且掛上各個專題評級模版的條目自動放進各個專題的首頁，這樣就免去人為添加了。--Scarsnevergoaway（留言） 2024年7月13日 (六) 06:31 (UTC)[回覆]

我製作了一個自動翻譯榜單排行的小工具，請問有什麼辦法可以推廣？

我目前正開發一個音樂條目的自動翻譯工具，希望能實現以下功能：

  1. 自動翻譯單曲周榜單和年終榜單的表格。
  2. 自動翻譯專輯周榜單和年終榜單的表格。
  3. 自動修正常見的榜單錯誤翻譯。
  4. 自動翻譯專輯和單曲條目製作人員名單的分工類型。
  5. 自動翻譯曲目列表的部分常用類型。
  6. 自動翻譯發行歷史的國家名稱和日期。
  7. 單曲和專輯信息框模版清理。
  8. 根據信息框模版自動生成條目導言。

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

使用時，進入原始碼編輯頁，工具一欄會出現「單曲榜翻譯」等分類，按照需求點擊分類下的各功能按鈕即可。在編寫條目時，務必先使用本工具，再使用連結自動翻譯器。

這個工具在經常參與音樂專題，翻譯歌曲條目的編者這裏還是挺好用的，可以省去大量重複性工作。請問有什麼辦法能推廣一下這個嗎。--Scarsnevergoaway（留言） 2024年7月13日 (六) 06:34 (UTC)[回覆]

Infobox person/Wikidata 出生日期

中文數字與阿拉伯數字混用，例見熱爾瑪娜·維亞娜，「出生」顯示爲「1972年十月16日」--惣流·明日香·蘭格雷不姓式波 2024年7月13日 (六) 07:52 (UTC)[回覆]

無法復現。或許已經修復？--PexEric💬|📝 2024年7月13日 (六) 11:54 (UTC)[回覆]
剛剛看了一下，似乎是只有香港和澳門版本有此問題，應與使用的裝置和瀏覽器無關--惣流·明日香·蘭格雷不姓式波 2024年7月14日 (日) 01:30 (UTC)[回覆]
未登錄時港澳版本可重現，登錄後無法重現。--YFdyh000（留言） 2024年7月14日 (日) 02:22 (UTC)[回覆]
哪個瀏覽器？我win11 firefox和edge，登入與否，無痕與否，均能復現，chrome的話沒安裝試不了。--惣流·明日香·蘭格雷不姓式波 2024年7月14日 (日) 06:33 (UTC)[回覆]
Win10 Edge。curl -v https://baike.710302.xyz/zh-mo/%E7%83%AD%E5%B0%94%E7%8E%9B%E5%A8%9C%C2%B7%E7%BB%B4%E4%BA%9A%E5%A8%9C 的源碼里也能看到>1972年十月16日&#160;<。--YFdyh000（留言） 2024年7月14日 (日) 11:10 (UTC)[回覆]
我這隻有未登錄時香港、澳門繁體能復現。--Kcx36（留言） 2024年7月14日 (日) 10:45 (UTC)[回覆]

用戶頭銜模板重疊

似乎當兩個template:Encourage之間有template:top icon時（例如任一有Encourage的頭銜模板緊接一個Template:反破壞工作小組成員），兩個Encourage頭銜框會部分重疊，具體見User:方志維（隨機選的，但他的情況非常明顯）的一堆頭銜。（小弟用戶頁直接複製了Template:反破壞工作小組成員的Encourage源碼，所以沒有此問題）--惣流·明日香·蘭格雷不姓式波 2024年7月14日 (日) 09:19 (UTC)[回覆]

我這裏未發現有什麼問題--百無一用是書生 (☎) 2024年7月14日 (日) 11:51 (UTC)[回覆]
他剛剛移除了一堆模板，在歷史版本仍可見（圖），另見User:Ericliu1912（圖）--惣流·明日香·蘭格雷不姓式波 2024年7月14日 (日) 13:22 (UTC)[回覆]
我自己看了看倒是沒問題？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月14日 (日) 15:42 (UTC)[回覆]
同上，我還是看不出截圖中的問題，或許是瀏覽器或使用了某些js腳本導致？--百無一用是書生 (☎) 2024年7月15日 (一) 02:24 (UTC)[回覆]
這就怪了，我win11 Firefox（有一些插件）登入與否都能復現，edge（沒有插件）及android chrome（沒有插件）同理。--惣流·明日香·蘭格雷不姓式波 2024年7月15日 (一) 02:29 (UTC)[回覆]
那可能是某個本站的js小工具或用戶腳本導致的？--百無一用是書生 (☎) 2024年7月15日 (一) 03:03 (UTC)[回覆]
但我的edge沒有任何extention，也應該沒有動過任何設定（平常用firefox），沒有登入的話理應沒有腳本或小工具？會否與裝置或瀏覽器的語言或地區設定有關？--惣流·明日香·蘭格雷不姓式波 2024年7月15日 (一) 03:10 (UTC)[回覆]
咦，剛才重新打開了這兩個用戶頁，莫名的就復現了...--百無一用是書生 (☎) 2024年7月15日 (一) 03:06 (UTC)[回覆]
是重疊的模板寫的有問題，解析成html後多了一個空行，可以參考我剛剛在Template:維基座標工作小組、Template:邊緣人小組和Template:維權聯盟盟友的修改方式對其他模板一併修改，把top icon和Encourage模板之間用<!-- -->斷行，最後的分類和模板之間不要斷行或者也用<!-- -->斷行--百無一用是書生 (☎) 2024年7月15日 (一) 03:23 (UTC)[回覆]
{{維基近衛騎士}}怎麼修改？--Miyakoo（留言） 2024年7月15日 (一) 04:21 (UTC)[回覆]
 已修復--百無一用是書生 (☎) 2024年7月15日 (一) 06:22 (UTC)[回覆]

求助

Category:中南大學大學維基人的移動問題

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

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

由於分類中南大學大學維基人有語法錯誤，我已將其移動至中南大學維基人，但是不知道怎麼回事，分類頁面好像出問題了； 各位編者還是去看下是怎麼回事吧。（我是不知道怎麼辦了）--—夢夕琳 如有事，請快來溝通 2024年7月3日 (三) 05:38 (UTC)[回覆]

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

請求協助編輯內容

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

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

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

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

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

Category:獲得聖吉斯納域斯公民身份者

本主題或以下段落文字，在討論結束後應存檔至Category talk:歸化聖吉斯納域斯公民。

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

如何使用Twinkle一次提刪多個頁面？

如題。據我所知存廢討論是可以一次提刪多個頁面的（比如這個），但似乎Twinkle並沒有這個功能？--古怪的Wang31（討論 | 貢獻） 2024年7月6日 (六) 09:32 (UTC)[回覆]

此例是人手寫的，Special:Diff/83094952。
上面很長的，也是人手寫的，Special:Diff/82711408。
TW應該是沒有這個功能。--Miyakoo（留言） 2024年7月6日 (六) 09:56 (UTC)[回覆]
Twinkle無此功能（單一標題並列多個頁面名稱），但有「批量提刪」功能。Sanmosa 蚌埠 2024年7月9日 (二) 05:23 (UTC)[回覆]

請求協助編輯國旗相關模板

請求熟悉國旗模板的維基人協助編輯{{Country data Kingdom of Italy}}。

  • {{flag|Kingdom of Italy}}→ 意大利王國。效果正確。
  • {{flagicon|Kingdom of Italy}}→意大利王國。連結指向不正確。
  • {{flagathlete|谁谁谁|Kingdom of Italy}}→ 誰誰誰（意大利王國）。連結指向不正確。

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

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

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

untitled

希望在中維創建一些目前缺失的主流投資機構頁面，但是發現標題中帶有「投資」的無法創建。希望創建的頁面有：鼎暉投資、厚朴投資。--Muyao (Roy) Liu（留言） 2024年7月7日 (日) 21:00 (UTC)[回覆]

頁面易被用作廣告宣傳，所以社群使用標題黑名單進行了限制。您可以在沙盒頁面創建草稿，若內容合適，其他用戶可以協助移動。——暁月凜奈 (留言) 2024年7月7日 (日) 23:24 (UTC)[回覆]
1.請求協助移動，應該在哪個頁面申請合適？
2.絕大多數XX Investments的機構官譯中文均為「XX投資」，妥否有更合適方案？--Muyao (Roy) Liu（留言） 2024年7月8日 (一) 06:32 (UTC)[回覆]
直接在頁面相應的討論頁使用Template:Requested move提出即可，它會把頁面加到Category:移動請求中。這一類標題的限制是允許自動確認用戶創建，即達到一定註冊時長和編輯次數的用戶。目前的技術水平大概無法自動判斷內容是否為廣告宣傳。——暁月凜奈 (留言) 2024年7月9日 (二) 02:06 (UTC)[回覆]

無法編輯頁面

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

我想新增涼森玲夢的作品，但編輯後不能儲存，請協助--はなか有花果（留言） 2024年7月8日 (一) 07:00 (UTC)[回覆]

請協助編輯頁面內容

https://baike.710302.xyz/wiki/Wikipedia:%E6%B2%99%E7%9B%92 我需要將以上沙盒的內容編輯到『涼森玲夢』的頁面

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

協助請求：請幫忙確認條目符合生者傳記方針

生者傳記條目李琴峰發生編輯戰，有用戶執意為該條目加入違反生者傳記方針的內容，包含:「有關在世人物的無來源或少來源的爭議內容」、不可信的「自行出版來源（如傳主個人頁面，以及特定政黨臉書粉絲頁之發文）」，並侵害傳主個人資料以及姓名的私隱。該編輯明顯違反方針，但因條目關注度較低，無法取得立即性的修復，故在此邀請並請求社群協助關注，以確保條目符合維基百科方針。--Alibadaba159（留言） 2024年7月8日 (一) 15:38 (UTC)[回覆]

請求協助上傳檔案 2024-07-08 16:50

我想要上傳的圖片來源是<https://www.opentix.life/event/1519603192318570498>，網站內簡介說明中的第一張照片，想要使用在達康.come的主要照片，並加上說明<達康.come在2019年於國家兩廳院活動《廳院指南：活屍末日劇院求生守則》拍攝之照片>，初次使用維基，謝謝你們的協助。 --SADONE28（留言） 2024年7月8日 (一) 16:50 (UTC)[回覆]

請求協助上傳檔案 2024-07-09 13:39

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

請求協助上傳檔案 2024-07-09 14:25

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

請求協助上傳檔案 2024-07-10 19:51

我想要上傳的圖片來源是<從某個網址下載，請提供網址 / 自行拍攝>，想要使用在請提供條目名稱（如果條目還不存在，請先建立條目再請求上傳文件）的<資訊框/某個段落，請說明>。 --AidenZengGZ（留言） 2024年7月10日 (三) 19:51 (UTC)[回覆]

戰隊配音問題

戰隊戰士人物的香港配音現在被剷掉，超力霸王、假面騎士卻有主要戰士顯示有香港配音員而且沒有構成對維基百科方針的內容違背。可否重新加上？--Mr tiger Shun Kit（留言） 2024年7月12日 (五) 03:27 (UTC)[回覆]

停用結構式討論造成錯誤

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

我的討論頁User_talk:C9mVio9JRy本來用結構式討論，因為收到通知說要終止該功能，所以點選了停用，結果我的討論頁似乎就壞掉了？--C9mVio9JRy（留言） 2024年7月13日 (六) 07:41 (UTC)[回覆]

幫你喊有能力解決這個問題的人了，請稍等。--碟之舞📀💿 2024年7月13日 (六) 07:57 (UTC)[回覆]
@C9mVio9JRy：已修復。--碟之舞📀💿 2024年7月13日 (六) 10:30 (UTC)[回覆]
直接幫你修好了。結構式討論真是令人頭大！—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月13日 (六) 10:31 (UTC)[回覆]
謝謝！--C9mVio9JRy（留言） 2024年7月13日 (六) 10:49 (UTC)[回覆]

關於來源問題

--Yoly0514（留言） 2024年7月13日 (六) 11:47 (UTC) 我最近在編輯一個YT上的小網紅(黃詩敏)的頁面，但是他畢竟是小網紅，所以我在網絡上也找不太到有關他的報導，大部分的來源都是來自他的影片或是社群媒體，但是又不能用他自己說的東西做來源，我想盡快解決這個問題，因為這讓我非常困擾，如果有路過的管理員可以說明，麻煩用口語化一點，不然太官腔或正式的語言會讓我很難理解:([回覆]

  1. 未能滿足Wikipedia:關注度 (人物)、Wikipedia:關注度 (音樂)
  2. 未能滿足WP:生者傳記對於知名的公眾人物，應使用大量可靠的第三方出版來源來取得內容
  3. 未能滿足WP:生者傳記對於第一手來源不是文章主要的來源的要求
  4. 未能滿足需WP:關注度#通用關注度指引，缺乏第二手來源（二次文獻）或第三手來源
--Rastinition（留言） 2024年7月13日 (六) 12:02 (UTC)[回覆]
但是就是找不到第三方來源怎麼辦--Yoly0514（留言） 2024年7月13日 (六) 12:30 (UTC)[回覆]
那就請不要建立，就算是網絡百科全書，也不是什麼文章都收的，請待有合適的來源出現再建。--WiTo🐤💬 2024年7月13日 (六) 12:43 (UTC)[回覆]
上述二位維友已提供意見，如果沒有關注度就不要強行建立，避免潛在的違規擾亂行為反而招致管理員限制您的編輯權限，謝謝。--薏仁將🍀 2024年7月13日 (六) 20:20 (UTC)[回覆]

User talk:SkEy/結構式討論 存檔 1

於Phabricator查看
編號T238427的工單

這個頁面一直被分類到Category:快速刪除候選，想要刪掉但是找不到這個分類文本放在什麼地方--百無一用是書生 (☎) 2024年7月15日 (一) 02:43 (UTC)[回覆]

似乎屬技術問題，見Wikipedia:互助客棧/求助/存檔/2024年6月#用戶討論:SkEy/結構式討論_存檔_1--千村狐兔（留言） 2024年7月15日 (一) 02:49 (UTC)[回覆]
這個問題是我重啟結構式討論之後再次禁用出現的，我暫時也沒什麼好的解決辦法。—さき せかいSaki Sekai（討論｜貢獻） 2024年7月15日 (一) 05:17 (UTC)[回覆]

請求協助上傳檔案 2024-07-15 07:28

我想要上傳的圖片來源是自行拍攝，想要使用在船形山站的副站名說明。 --瀚可（留言） 2024年7月15日 (一) 07:28 (UTC)[回覆]

無法建立「China International Motorcycle Trade Exhibition」的頁面

無法建立「China International Motorcycle Trade Exhibition」的頁面，提示禁止創建和編輯--CIMA Jane（留言） 2024年7月15日 (一) 07:56 (UTC)[回覆]

在英文維基百科嗎？因為英文維基百科不允許非自動確認使用者建立條目頁面，您必須從en:Draft:China International Motorcycle Trade Exhibition開始編寫，另外，您也必須遵循en:WP:DCOI（甚至en:WP:PAID）的指示，揭露利益衝突，否則可能會被禁止編輯，謝謝。--冥王歐西里斯（留言） 2024年7月15日 (一) 08:14 (UTC)[回覆]


條目探討

用於表示日本節慶活動的「祭」是否可以視為恰當的中文用法

看到將「Category:琉球節日」改為「Category:沖繩縣的祭」現象，產生的疑惑--苞米(☎)💴 2024年6月14日 (五) 09:14 (UTC)[回覆]

你成功勾起了我對「紀」這個字的心理陰影。--MilkyDefer 2024年6月14日 (五) 12:22 (UTC)[回覆]
大草，你是在說這個？--BigBullfrog（𓆏） 2024年6月16日 (日) 18:38 (UTC)[回覆]
不應視為中文。漢語「祭」無此用法（可查閱《現代漢語詞典》《國語辭典》《辭源》等等）。--自由雨日（留言） 2024年6月14日 (五) 12:33 (UTC)[回覆]
如果此處的祭如同戰祭、豐年祭，是指慶典或活動的話，可參見《教育部異體字字典》釋義五。[22]--夜月辰星（留言） 2024年6月14日 (五) 12:44 (UTC)[回覆]
如果此處討論的是Category名的話，或許可以參照Category:日本鐵路公司，條目名使用特例的鐵道，而Category名則用慣例的鐵路。--夜月辰星（留言） 2024年6月14日 (五) 12:57 (UTC)[回覆]
既然《教育部異體字字典》給出了這個義項，那麼說明「祭」在漢語中確實可以表示「慶典活動」的意思，但我仍不認為可以用來作標題，理由有三：一、《異體字字典》沒有給出詞性說明，不過從例句（例詞）為「雪祭」、「海洋祭」、「音樂祭」等來看，「祭」表示此義時可能只能用作詞綴（例如「作者」「讀者」的「者」字、「產業化」「綠化」的「化」字等），「沖繩縣的祭」中「祭」直接作為成詞語素，這可能是不合法的，至少很不符合語感；二、目前只有台灣的詞典給出這種用法，可能不是所有漢語地區廣泛的用法；三、即便在中國大陸等地區的詞典中找到了這種用法，用「祭」來表示慶典活動在漢語中仍是不常見的，完全可以用更常見的方式來表達。--自由雨日（留言） 2024年6月14日 (五) 12:57 (UTC)[回覆]
這兩個節日名稱本來就是沿用日治時期的日文寫法吧？--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年7月8日 (一) 05:03 (UTC)[回覆]
意味不明啊？維基人接納某些活動常用名稱為中文就算了，分類可以自己命名就或許不必如此了吧？不過日本相關分類好像都這樣，有整體考慮必要。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 12:47 (UTC)[回覆]
可以改用祭典。--AT 2024年6月14日 (五) 13:20 (UTC)[回覆]
中文普通名詞「節日」不應換成日語的「祭」，並非是專有名詞。現代標準漢語中「祭」一般是祭祀的意思。反對使用祭典，祭典不是節日。百科全書面向的是普通的中文讀者。--Kethyga（留言） 2024年6月14日 (五) 14:05 (UTC)[回覆]
條目祭 (日本)在2007年由武藏創建並使用了「祭」，分類:日本的祭>分類:日本各都道府縣的祭>……亦依從了這樣的命名。如需更改應一併更改，可使用「祭典」。--紺野夢人 2024年6月14日 (五) 14:08 (UTC)[回覆]
如果祭是普通日語詞彙而非有特別意義和限定，不應這樣用。--YFdyh000（留言） 2024年6月14日 (五) 14:13 (UTC)[回覆]
同意Kethyga君，貢寮國際海洋音樂祭可以，但Category:沖繩縣的祭不行，因為前者是專有名詞，而且用「祭」表達活動或慶典仍不是中文圈普遍的用法。固然語文是活的、會改變、會交流的，語文也可以有外來語，但此種用法尚未成為中文外來語。-游蛇脫殼/克勞棣 2024年6月14日 (五) 15:26 (UTC)[回覆]
應該是一種日文漢字借入中文漢字語境的情況，但僅限於專用名詞化（例如札幌雪祭等），如果作為一個獨立語素作為其他語素的被修飾對象，類似上述舉例，應該沒有對應類似「節日」、「祭典」的意思，可能需要對應替換為相應語言的獨立語素「節日」或者「祭典」。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月15日 (六) 00:53 (UTC)[回覆]
但糾結下去的話，「祭」在中文漢字的語言有「對死者表示追悼、敬意的儀式」、「供奉鬼神或祖先」的意思，對應日文漢字其意思也有類似的語義：因為日本這些「祭」的前身有相當是與「供奉鬼神」等的儀式。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月15日 (六) 00:53 (UTC)[回覆]
經我再三考慮，我建議全面廢除「日本的祭」以下所有分類，改以「神道祭事」取代（有需要的話可再按都道府縣細分），與神道無關的如札幌雪祭等則劃入日本年度活動（有需要的話可再按都道府縣細分），只有明確區分祭典和活動才能解決目前的問題。--AT 2024年6月15日 (六) 08:52 (UTC)[回覆]
"祭"可以作爲日語漢字直接引入漢語的外來詞。--小河仔（留言） 2024年6月26日 (三) 10:22 (UTC)[回覆]
未經詞典等收錄，不得人為「引入」外來詞，這屬於原創研究（原創新詞）。另外，您是新註冊用戶，第一條編輯便是在條目探討內突然回復，這是為何？（這種現象難免令人多想，故需確認）--自由雨日（留言） 2024年6月26日 (三) 10:29 (UTC)[回覆]
在編輯條目時看到了互助客棧。--小河仔（留言） 2024年6月26日 (三) 10:30 (UTC)[回覆]
上一條回復是您的第一筆編輯。按理說，新用戶並不熟悉客棧。如您有其他主賬號，還請根據WP:傀儡政策公開。若真是新註冊用戶，那可以忽略我說的。--自由雨日（留言） 2024年6月26日 (三) 10:33 (UTC)[回覆]
我剛剛接觸互助客棧，覺得很新奇，像BBS論壇一樣。--小河仔（留言） 2024年6月26日 (三) 10:39 (UTC)[回覆]
哦哦，好的。歡迎來到維基百科。--自由雨日（留言） 2024年6月26日 (三) 10:45 (UTC)[回覆]
據我所知，「祭」（名詞）在現代漢語中是不成詞語素，不能單獨作為一個詞使用，即使在日本文化相關的語境下也是如此。因此即使表示日本節慶活動的「祭」可以視為恰當的中文用法，「XX節日」也不宜改為「XX的祭」。--CuSO4 · 龍年大吉 2024年6月15日 (六) 17:12 (UTC)[回覆]
也許從分類命名一致性出發，所有相關分類都應該使用「節日」為後續。現在Category:各國節日分類之下，也就是「日本的祭」顯得獨行獨立。
看了一下日維，對方是ja:Category:各國の祭，日本的分類有點過分名從主人。--Nostalgiacn（留言） 2024年6月16日 (日) 01:36 (UTC)[回覆]
日本節日是可以有的，但是這不等同於祭，例如御盆節本身是個節日，而非祭，盡管在這些節日期間很大機會舉行各種各樣祭，兩者還是不對等的。因此，神道祭事本身也不打算歸類至各國節日，日本節日則應該是日本年度活動的子分類。--AT 2024年6月16日 (日) 09:48 (UTC)[回覆]
就算是「Category:神道祭事」這個分類，在Category:宗教節日也顯得獨行獨立，其他都是「佛教節日」、「基督教節日」。對比其他語言維基，英維也是「Shinto festivals」（宗教名+festivals），日維是「神道行事」（宗教名+行事）。
還是上面說的日本的分類有點過分名從主人，感覺應該使用「分類命名一致性」處理一下。
就算不說XX祭這個問題，退一步講，當前應該先建立「日本節日」分類，沖繩縣的祭也應該恢復「琉球節日」。--Nostalgiacn（留言） 2024年6月17日 (一) 02:22 (UTC)[回覆]
「沖繩縣節日」與「琉球節日」是否有差別？嚴格意義上肯定有（後者傳統一些），但寬泛一些的分類是否也有？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月17日 (一) 06:36 (UTC)[回覆]
琉球可以指曾經一個國家（琉球國），沖繩縣是現在日本一個行政區。當前的移動本來就很怪。
退一步說，未來有祭祀活動的分類，也應該另建「沖繩縣宗教節日」，在「沖繩縣節日」之下。
關係如下：
琉球節日》沖繩縣節日》沖繩縣宗教節日--Nostalgiacn（留言） 2024年6月17日 (一) 08:01 (UTC)[回覆]
琉球除了是個國家，還是個民族，「琉球節日」在當前語境中更應該不理解為琉球民族的節日--苞米(☎)💴 2024年6月17日 (一) 13:00 (UTC)[回覆]
歡迎補充，那麼你是否支持改回「琉球節日」，以作為整合琉球文化相關節日的分類，再另建「沖繩縣節日」作為下行分類。--Nostalgiacn（留言） 2024年6月17日 (一) 16:52 (UTC)[回覆]
其實分類的話不用那麼嚴格，分類重新導向即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 10:58 (UTC)[回覆]
分類收錄的確實是沖繩縣的節慶，這樣命名是考慮到與d:Q8447345對應及與本站既有分類一致（隨討論結果同步修改）。琉球國是沖繩縣的建前歷史（類比Category:夏威夷州>Category:夏威夷州歷史>Category:夏威夷建州前歷史>Category:夏威夷王國），琉球民族是來自這一地域的族群（類比Category:夏威夷州>Category:夏威夷原住民），這樣分類是可行的，如需細分也可再設立子分類。但這已經不是本則討論的主旨了。--紺野夢人 2024年6月18日 (二) 04:02 (UTC)[回覆]
我翻了一些分類，明白為何有種違和感，因為中維有Category:亞洲各民族節日這個分類體系，英維沒有這個體系，你將一個原本是基於「各民族節日」建立的分類，轉換成「各國節日」。有點生搬硬套導致的違和感。--Nostalgiacn（留言） 2024年7月9日 (二) 02:52 (UTC)[回覆]

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

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

「的」字多不必。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月5日 (五) 07:30 (UTC)[回覆]
(－)反對更改神道祭事分類，祭事不是節日，例如葵祭僅僅是個別神社的儀式，在神道內沒有作為節日的共通性。另外，日本節日分類的設立仍然要考慮如何歸類，不是有個「祭」字就是節日。--AT 2024年7月5日 (五) 08:28 (UTC)[回覆]
能否解釋一下，英維為何用festivals（en:Category:Shinto festivals），日維用ja:Category:神道行事（年中行事（日語：年中行事）），而中維使用「祭事」一詞。
你不反對前面的吧，畢竟你也說日本節日則應該是日本年度活動的子分類。分出另一個「祭」作為下級分類是一回事，「日本節日」還是要有的。--Nostalgiacn（留言） 2024年7月7日 (日) 02:07 (UTC)[回覆]
(－)反對「祭」不等於「節日」，參照《教育部異體字字典》，「祭」確實是中文用法。-Hierro） 2024年7月6日 (六) 16:31 (UTC)[回覆]
認同「祭」不等同「節日」，但反對根據《教育部異體字字典》將其認定為「中文用法」，重複一下前面的論證：一、《異體字字典》沒有給出詞性說明，不過從例句（例詞）為「雪祭」、「海洋祭」、「音樂祭」等來看，「祭」表示此義時可能只能用作詞綴（例如「作者」「讀者」的「者」字、「產業化」「綠化」的「化」字等），「沖繩縣的祭」中「祭」直接作為成詞語素，這可能是不合法的，至少很不符合語感；二、目前只有台灣的詞典給出這種用法，可能不是所有漢語地區廣泛的用法；三、即便在中國大陸等地區的詞典中找到了這種用法，用「祭」來表示慶典活動在漢語中仍是不常見的，完全可以用更常見的方式來表達。另外為什麼您的UTC時間超前1小時……——自由雨日（留言・貢獻） 2024年7月6日 (六) 15:39 (UTC)[回覆]
現在都國際化，讓我們直接看日本旅遊局的資料，有提供官方中文，日文「日本の祭りとイベント」，英文Japanese Festivals & Events，繁體中文是節慶活動、簡體中文是日本祭典與盛會。
個人合理懷疑目前「日本的祭」的翻譯是「日本の祭り」機翻，中文應該翻譯「節慶」或者「祭典」。--Nostalgiacn（留言） 2024年7月7日 (日) 02:20 (UTC)[回覆]
祭典不是指節日。--Daniel1023（留言） 2024年7月8日 (一) 05:09 (UTC)[回覆]
從翻譯角度來說，我舉例的時日本給出的官方翻譯，「日本の祭りとイベント」其中一個官方翻譯就是「節慶」，可以理解為節日和慶典的縮寫。
上面很多關於「祭」的討論，都是中文語境的「祭」，變成語言考據的原創研究現場，「祭典不是指節日」這個問題也是如此。根本不是在討論「日本の祭り」的翻譯問題。
就我目前找到的資料來看，「日本の祭り」應該翻譯作「日本祭典」或者「日本節慶」，如果有人強調要「祭」，選用日本官方的簡體翻譯「日本祭典」更好。--Nostalgiacn（留言） 2024年7月9日 (二) 01:52 (UTC)[回覆]

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

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

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

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

關於生長在朝鮮半島的植物條目

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

這是我之前發起對朝鮮條目的移動請求之後發現的問題，早前由機械人創建的植物條目以中國大陸的參考來源為標準，可能有些大陸的資料來源是1992年以前的，就把朝鮮半島統稱為「朝鮮」，導致大量這類條目的「分佈」中都出現了朝鮮的消歧義內鏈，而且經查，確實會有分佈在韓國的植物（如檜柏）在中國大陸的資料里「國外分佈」一欄依舊是寫「朝鮮」的情況，現在的問題是，要把這些條目消歧義，但消歧義頁面有朝鮮 (地區)和朝鮮半島似乎都可以選擇，所以想問一下社群對此持有何看法。我個人傾向於連結去朝鮮 (地區)，因為中國大陸、日本均為偏政治化的地理概念，與朝鮮半島這樣的純地理概念不太相同。（也就是說，如果使用朝鮮半島的話，其他對應的應該是「日本群島」「華北平原」之類的純地理概念）。----FradonStar|八閩風雲 2024年7月1日 (一) 03:31 (UTC)[回覆]

地域上的「朝鮮」與韓半島範圍基本一致，連結過去都是沒有問題的。不過若從來源能判明是半島，還是將「朝鮮」字樣直接改成「朝鮮半島」以避免僅理解為朝鮮民主主義人民共和國較好；若難以判明，可以不變「朝鮮」字樣，連結至較大範圍的朝鮮 (地區)或朝鮮半島。至於與政區並列，並無不可，「分佈於某地形區」與「分佈於某政區」都是成立的。--紺野夢人 2024年7月1日 (一) 16:40 (UTC)[回覆]
@Yumeto：我覺得最好是定一個標準，不然雖說兩個都可以鏈，但最終應該鏈到何處去呢？沒有一個統一標準的話，後期的消歧義工作很難開展。----FradonStar|八閩風雲 2024年7月2日 (二) 03:01 (UTC)[回覆]
可以考慮把政治地理的「朝鮮 (地區)」移動到「朝鮮」，消歧義的「朝鮮」移動到「朝鮮 (消歧義)」。純地理的朝鮮半島並不包含濟州島、獨島這些離島。--D（留言） 2024年7月2日 (二) 01:50 (UTC)[回覆]
反對作此移動。既然「朝鮮」重定向至「朝鮮民主主義人民共和國」是中國大陸地域中心，那麼「朝鮮」重定向至「朝鮮 (地區)」同樣是「非中國大陸」地域中心，因為目前（至少21世紀以來）中國大陸從不會將「朝鮮 (地區)」稱作「朝鮮」。--自由雨日（留言） 2024年7月2日 (二) 05:39 (UTC)[回覆]
現況我不做評價，但是我前面提到的植物條目裏面提到的「朝鮮」或許解釋成地區更有說服力，而且這些條目的來源可能創建於1991年左右，那個時候中韓尚未建交，撇去政治因素的話，把朝韓兩國稱為朝鮮或許只能用地區來解釋。----FradonStar|八閩風雲 2024年7月2日 (二) 14:44 (UTC)[回覆]
相關書籍有沒有「南朝鮮」？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 18:25 (UTC)[回覆]
據我所知是沒有，比如中國高等植物數據庫全庫記載的櫸樹，「國外分佈」一欄只寫着朝鮮和日本，而其他參考文獻是明確有寫它分佈在韓國的（[23]），我也因此認為其他相關的以中國高等植物數據庫全庫為參考的植物條目中的「朝鮮」，應該指的是朝鮮地區/半島，而不是朝鮮民主主義人民共和國。就算確實指後者，寫朝鮮地區/半島也沒錯，且不會出現歧義的問題。----FradonStar|八閩風雲 2024年7月3日 (三) 04:15 (UTC)[回覆]
我覺得下結論可能原創研究。如無額外來源證明，我寧可取消內部連結。擴大範圍恐怕是曲解來源。
按使用幫助文檔最後一頁，國外分佈可能寫中南半島、馬來半島。但是，沒有寫成朝鮮半島。
數據集來源是中國植物志。[24]櫸樹的介紹，1998年出版。--YFdyh000（留言） 2024年7月3日 (三) 14:52 (UTC)[回覆]
沒錯兒，上面的思維方式很容易構成原創研究。我覺得保持消歧義連結就是最好的方式，表示根據來源並不能不確定「朝鮮」具體指什麼；然後再根據最新的文獻資料逐一更新這些生物的具體分佈地。--自由雨日（留言） 2024年7月3日 (三) 16:57 (UTC)[回覆]
我上面只是反對說將「朝鮮 (地區)」移動到「朝鮮」，至於植物具體分佈地的問題，建議根據最新的參考文獻逐一考慮，簡單地視作朝鮮/北韓或朝鮮（地區）都是不妥的（也進一步說明移動並不是好的處理方法）。30多年前的文獻本身也不太適合使用。--自由雨日（留言） 2024年7月3日 (三) 05:37 (UTC)[回覆]
可能不易確定所用來源和原始含義。建議保持+補充來源。--YFdyh000（留言） 2024年7月2日 (二) 12:14 (UTC)[回覆]
問題是，這種植物小條目很多，每個一一確定麻煩很多，而且現狀是朝鮮鏈入了消歧義頁面，理論上這也是不應該的，而且現在就有比較合適的辦法，就是鏈入朝鮮 (地區)或者朝鮮半島。現在主要探討的問題應該是鏈入哪個更為合適。----FradonStar|八閩風雲 2024年7月3日 (三) 04:18 (UTC)[回覆]
前者範圍或許更大。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月3日 (三) 10:53 (UTC)[回覆]
綜合各方意見，現在對部分只鏈入「朝鮮」條目而未鏈入「韓國」的植物條目有三個解決方案：①去除條目中的朝鮮連結；②保持原來的消歧義連結；③將消歧義連結改為鏈入朝鮮 (地區)或朝鮮半島。也邀請前面參與過相關討論的用戶@Yumeto、DEMONBANE、Ericliu1912、YFdyh000、自由雨日；另副知移動請求討論的參與者@E2568、Lantx、CaryCheng、暁月凛奈。
我個人的意見是支持③，不反對①，反對②。消歧義頁面本來就不應該作為一個健康的條目應該在正文中鏈入的頁面，除非明確要把讀者引導到消歧義頁面中去，所以保持消歧義條目的連結我是絕不認可的。這也有了我此前發起的對朝鮮這一消歧義頁面的移動請求，既然社群願意去做朝鮮的消歧義，我也願意配合消歧義的工作，但在這過程中，繞不開的就是對「朝鮮」一詞的現代定義，不論是植物也好，還是其他相關事物也好，必然是需要連結到一個有實際內容的條目頁面的，而不應該鏈入消歧義頁面，所以恕我不能接受保持消歧義連結的處理方式。另外我這個人是比較調和折中的，我最希望解決的問題就是取消消歧義連結的鏈入，所以我不反對去除連結，這也不失為一種解決問題的方式，但既然這個朝鮮明明是有明確含義的，它很顯然是一個地區的概念，我也很難理解為何有編者認為此等想法有曲解來源之嫌。現在鏈入朝鮮的頁面過於龐大，逐一確定絕對不是解決問題的長久之計，只會讓這個問題不斷積壓，久而未決。--FradonStar|八閩風雲 2024年7月8日 (一) 05:40 (UTC)[回覆]
上面支持②「保持消歧義連結」的應該只有我了。首先要明確我說的「保持」肯定不是「永久保持」，消歧義連結本身就是不應在條目內使用的；其次為何我支持「維持現狀」，是因為每個條目的情況都不同，所以只能進行逐一改動而非整體改動。比如澤番椒屬中的朝鮮黃鏈和雞爪槭中的朝鮮黃鏈顯然就不是同個意思。現在中維整個條目空間，大段無來源的、疑似原創研究的、需要維基化的內容比比皆是，如何解決，當然是一個個條目分別解決，而不是用機械人把所有無來源內容全部刪掉；同理，這些黃鏈具體應該鏈至哪個「朝鮮」，應該逐條目一一對應，且建議根據近年來的新來源對應（而非1950年代的植物學詞典）。--——自由雨日（留言・貢獻） 2024年7月8日 (一) 05:59 (UTC)[回覆]
@自由雨日：這個倒是問題不大，有如果一個植物分佈在朝鮮半島，分佈上又同時出現了「朝鮮」「韓國」兩個字眼，使用DisamAssist也能看得見，自然應該鏈入朝鮮民主主義人民共和國。但這不是主要的問題，也不是我提出這個問題的初衷，因為更多具有類似澤番椒屬這樣條目的問題還需要解決。----FradonStar|八閩風雲 2024年7月8日 (一) 06:42 (UTC)[回覆]
顯然有很多條目全篇沒有「韓國」兩字但依然應鏈至「朝鮮民主主義人民共和國」，如全光益。（看錯了，討論的條目僅限植物條目。）——自由雨日（留言・貢獻） 2024年7月8日 (一) 06:50 (UTC)[回覆]
@自由雨日：請閣下看一下標題，這裏討論的是植物條目，其他的情況難道不應該要具體情況具體分析麼？做消歧義工作的編者不可能連這麼簡單的辨別能力都沒有；退一步說，就算植物條目只分佈在朝鮮半島北半部，那鏈入朝鮮 (地區)/朝鮮半島也沒有問題。----FradonStar|八閩風雲 2024年7月8日 (一) 06:54 (UTC)[回覆]
我知道，我發出這句話之後在您回復前馬上就修改了（）不過建議將「現在的解決方法有三：①去除植物條目中的朝鮮連結；②保持原來……」中的「植物」一詞提到最外面，以免其他編者再誤會。--——自由雨日（留言・貢獻） 2024年7月8日 (一) 06:56 (UTC)[回覆]
已修改上面的文字。另外(～)補充一下，已經有編者在做消歧義工作了，我看到ta的處理方式是將其改為鏈入「朝鮮半島」。----FradonStar|八閩風雲 2024年7月8日 (一) 07:04 (UTC)[回覆]
我認為應該根據最新來源全面改寫。。然後直接使用精確的語詞而不是管道連結。連結並不是誰都會去點擊（或鼠標懸停）的，不管鏈入半島還是鏈入地區或是鏈入北朝鮮，讀者都只能看到顯示的是「朝鮮」，並不清楚具體涵義，尤其是中國大陸讀者基本會誤認為是北朝鮮。本來保持黃鏈還能提示讀者朝鮮的含義有爭議，一旦清理黃鏈並用上了管道連結，反而使人誤解。（當然，如果您說的改為鏈入「朝鮮半島」是指直接改寫成「[[朝鲜半岛]]」而非「[[朝鲜半岛|朝鲜]]」，那還稍微好點。）--——自由雨日（留言・貢獻） 2024年7月8日 (一) 07:10 (UTC)[回覆]
您的想法很好，但是現在沒有足夠多的人力去處理這些，至於提醒讀者的這個說法恕我不認可，還是那句話，除非有意連結，正常的條目內容是不應該擁有消歧義頁面的，至於閣下建議的直接使用「[[朝鲜半岛]]」，我只能說閣下的建議很好，但是現在的技術做不到批量處理那麼多頁面，閣下前面提出的解決方案其實也是一樣的，擁有相同的問題，那就是現在如此龐大的頁面沒有辦法通過批量處理達到閣下所希望的解決方式。----FradonStar|八閩風雲 2024年7月8日 (一) 10:22 (UTC)[回覆]
正常的條目內容是不應該擁有黃鏈，但更不應該誤導讀者，我沒有說「應該」保持黃鏈，我是說黃鏈相對於管道連結來說甚至不那麼容易誤導。將消歧義連結改為管道連結顯然是撿了芝麻丟了西瓜，尤其是對大陸讀者。--——自由雨日（留言・貢獻） 2024年7月8日 (一) 10:44 (UTC)[回覆]
如上所述，文獻寫成朝鮮而非朝鮮半島，我不能贊成它們顯然都是朝鮮地區。中韓建交後仍寫作朝鮮，雖暫不排除沿用了舊資料。--YFdyh000（留言） 2024年7月8日 (一) 06:17 (UTC)[回覆]
@YFdyh000：如上面我的回覆，我們不是在試圖統一所有鏈入朝鮮之頁面的情況，我們應該討論對只出現「朝鮮」內鏈的個例的共識，而對於這種明顯的朝韓並立的頁面就沒有必要提出來做個例了，因為這類情況沒有需要討論解決的問題。----FradonStar|八閩風雲 2024年7月8日 (一) 06:45 (UTC)[回覆]
我覺得我沒說「所有鏈入朝鮮之頁面」，只是說「中國高等植物數據庫全庫記載」為依據的這一批個例。--YFdyh000（留言） 2024年7月9日 (二) 17:38 (UTC)[回覆]
啊啊啊啊......今天才看到這個討論......
我從7/1開始清理「朝鮮」的消歧義連結，已經把至少1000個條目（包含動物類和植物類）中的「朝鮮」連結至「朝鮮半島」了，如果討論結果是應該連至「朝鮮 (地區)」，恐怕得要找管理員或是機械人出來收拾善後...--CaryCheng（留言） 2024年7月9日 (二) 16:42 (UTC)[回覆]
見此，您無論將「朝鮮」消歧義頁鏈入「朝鮮半島」還是「朝鮮 (地區)」，均會誤導中國大陸等地的讀者，因為他們只有少部分人會點擊內鏈，若未點擊，他們就會認為是DPRK而不是朝鮮半島，就算他們點擊，也會讓他們覺得困惑。--——自由雨日（留言・貢獻） 2024年7月9日 (二) 16:48 (UTC)[回覆]
  • 連到哪一個都好，我沒意見，大家達成共識就行。
  • 現在問題已經造成，這種問題我沒遇過，有沒有人知道怎麼挽救呢?真找不到辦法的話，我也就只能手動回退這1000筆編輯了。
--CaryCheng（留言） 2024年7月9日 (二) 17:02 (UTC)[回覆]
短鯒、大瀧六線魚所對應的2006年《中國動物志》，同一作者的表述略有不同，朝鮮等地，朝鮮半島、日本等地海域。此外還有「朝鮮，韓國和日本」2006.中國動物志.鳥綱，「朝鮮半島和日本」2008. 中國動物志。不想輕率認定是編撰者未統一規範用詞。--YFdyh000（留言） 2024年7月9日 (二) 18:10 (UTC)[回覆]

滿族姓名

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

Coddlebean以「滿人不稱姓」大量刪除了條目中滿族人物的姓氏，搜索了一下不同人物情況應該不同。比如愛新覺羅·啟驤，有大量直接用長名「愛新覺羅·啟驤」，而不是簡單只用其名，舉例[25]、[26]、[27]、[28]、[29]，Google圖片搜索能看到不少帶「愛新覺羅」姓氏的。--Kethyga（留言） 2024年7月1日 (一) 12:38 (UTC)[回覆]

@Coddlebean：「滿人不稱姓」不代表維基百科條目行文不能用。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月1日 (一) 19:13 (UTC)[回覆]
旗人傳統上不稱姓，但是事異時移，今時今日如果一個人就是以「愛新覺羅某某」行走江湖（注意，人物類條目名稱採用的是其主要為人所知的名字，所以藝名優先於法律上的本名），那麼當然條目里也應該稱其為愛新覺羅某某。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年7月2日 (二) 00:49 (UTC)[回覆]

中華人民共和國

本主題全部或部分段落文字，已移動至Talk:中華人民共和國。執行人：路西法人 2024年7月8日 (一) 01:43 (UTC)。[回覆]

Lumo頁面編輯歷史及相關消歧義問題

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

基督教音樂

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

關於福建維基人用戶框的圖片選用問題

Template talk:User Fujian § 關於圖片選用有用戶正在徵求社群意見，敬請編者關注。

截至目前該話題僅4位用戶參與討論，且尚未得到明確共識，故在此發出討論通告。敬請諸位維基人，尤其是關心用戶框和福建主題的維基人多多參與討論。--射命丸 마음과 마음을 잇는 일은 언어를 뛰어넘는 일이다 2024年7月9日 (二) 15:24 (UTC)[回覆]

其實爭議的問題不是一個，而是兩個：1.二級行政區劃的用戶框圖標應當選用地圖還是建築地標/風景地標？（有官方旗幟或徽章的二級行政區劃不在討論範圍內）。2.二級行政區劃的用戶框應當要統一顏色，還是說不統一顏色（台灣二級行政區劃、香港二級行政區劃、中國三級行政區劃的用戶框的現況）。--向史公哲曰（留言） 2024年7月10日 (三) 15:08 (UTC)[回覆]
射君認為：福建人用戶框模板的背景顏色和圖案與其他中國大陸省級行政區的用戶框模板樣式不同，這是特殊性的彰顯，十分不妥。（儘管在射君提出意見的時候，吉林和江蘇的用戶框格式也是與眾不同的。）--向史公哲曰（留言） 2024年7月10日 (三) 15:12 (UTC)[回覆]
不應該在那邊討論？這樣會把討論分散吧？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年7月12日 (五) 08:27 (UTC)[回覆]
單純陳述爭議點也還好。--路西法人 2024年7月12日 (五) 10:13 (UTC)[回覆]

條目內鏈相關問題

近日在提交DC22時，一篇化學物質的條目中包含了化學式的連結，但有主持人認為化學式的連結屬於消歧義連結（C3H7ClO2），放在條目內不合適。在此諮詢一下社群的看法。--Leiem（留言·簽名·維基調查） 2024年7月10日 (三) 03:22 (UTC)[回覆]

連結方便查閱者查找同分異構體，其實最好的辦法是法語wiki那樣，在chembox中自帶內鏈--Htmlzycq（留言） 2024年7月10日 (三) 07:35 (UTC)[回覆]
我覺得這事可以分兩部分說。一，其實我不認為應當在正文裏加入化學式，因為資訊框裏已經有了，且知道了化學式對某一物質的認識幫助不大。除非加入化學式有助於理解，那就合適。二，如果要找異構體，讓chembox自帶內鏈或許是個不錯的主意。但好像不影響頁面歸入Special:連結到消歧義頁的頁面。說回動員令，我覺得還是別放任何消歧義吧，免得開例外壞了規矩。可以等動員令結束再放。--微腫頭龍（留言） 2024年7月10日 (三) 08:59 (UTC)[回覆]
「除非加入化學式有助於理解」，這樣的話應該可以放那些能表示結構的化學式，例如乙醇「C2H5OH」或「CH3CH2OH」、氯化鉀（離子化合物）「KCl」等。--Leiem（留言·簽名·維基調查） 2024年7月10日 (三) 09:14 (UTC)[回覆]
我覺得這些可以，但如果要在比如說藥物條目里放化學式，我覺得沒有必要，讀者來找藥物條目想必不是來找化學式的。--微腫頭龍（留言） 2024年7月10日 (三) 09:18 (UTC)[回覆]
消歧義頁不是條目，不提供百科資訊。他的作用是引導讀者進入正確的條目，例如2-氯-1,3-丙二醇或3-氯-1,2-丙二醇之類，而不是告訴讀者C3H7ClO2這個主題包括哪幾種化學物質。所以對於條目中的消歧義連結，應該把連結修復到具體的項目（例如2-氯-1,3-丙二醇），給個模糊的連結讓讀者猜測文章到底在指哪種物質，這的確不合適。
傳達C3H7ClO2有哪些同分異構體，這就屬於告訴讀者百科知識，那就成了條目該幹的事情。這時就應該像英維那樣，把en:C3H7ClO2定位成列表式條目（即同類索引類條目）。
當然，如果只是單純列出某物質的化學式，那寫純文字C3H7ClO2就夠，不需要加連結。--For Each element In group ... Next 2024年7月10日 (三) 09:36 (UTC)[回覆]
是的，化學式條目都應該是Wikipedia:同類索引條目，這需要修改{{Isomerdab}}模板--Htmlzycq（留言） 2024年7月10日 (三) 12:44 (UTC)[回覆]
（參見Category:化學同類索引）--Leiem（留言·簽名·維基調查） 2024年7月10日 (三) 13:31 (UTC)[回覆]
所以是要調整成同類索引嗎？Category:化學消歧義要不要也併入Category:化學同類索引？--微腫頭龍（留言） 2024年7月10日 (三) 13:46 (UTC)[回覆]
看起來大部分是應該改組成同類索引，但微量元素應該是消歧義頁沒錯。--For Each element In group ... Next 2024年7月10日 (三) 15:02 (UTC)[回覆]
@Leiem、Htmlzycq、For Each element In group Next：我已將{{Isomerdab}}和{{Chemistry index}}改成同類索引，但還沒移動Category:化學式消歧義。你們可以檢查兩個模板還有什麼要改的地方。既然成了同類索引，Isomerdab和{{MolFormDisambigNav}}也應該要換名了。--微腫頭龍（留言） 2024年7月12日 (五) 07:17 (UTC)[回覆]
@微肿头龙：看上去沒問題，最後就是分類（Category）還需要改一下。--Leiem（留言·簽名·維基調查） 2024年7月12日 (五) 07:20 (UTC)[回覆]
@Nucleus hydro elemon：順便知會閣下。如果現在還想改回消歧義還來得及。等Category:化學式消歧義移動了要改回去就麻煩了。--微腫頭龍（留言） 2024年7月12日 (五) 07:21 (UTC)[回覆]
然後有一個「如果您是通過某條目的內部連結轉到本頁，希望您能協助更正該處的內部連結，將它直接指向正確的條目」，這個表述是針對消歧義的。--Leiem（留言·簽名·維基調查） 2024年7月12日 (五) 07:21 (UTC)[回覆]
我看到{{Set index article}}也有這一句？@Leiem：--微腫頭龍（留言） 2024年7月12日 (五) 07:23 (UTC)[回覆]
@微肿头龙：這個可能是從enwp那邊直接翻譯過來的，不過enwp的同類索引寫的「incorrectly led you here」（錯誤連結至此）、消歧義寫的「led you here」（連結至此），還有那邊的WP:SIA提到了「red links to help editors create articles on notable entries」（紅鏈可以讓編者創建有價值的條目）。--Leiem（留言·簽名·維基調查） 2024年7月12日 (五) 07:33 (UTC)[回覆]
比如寫成「除非您是有意連結至本頁，否則應將相應條目的內部連結指向正確的條目。」--Leiem（留言·簽名·維基調查） 2024年7月12日 (五) 07:35 (UTC)[回覆]
已採納閣下意見。--微腫頭龍（留言） 2024年7月12日 (五) 07:38 (UTC)[回覆]
把Isomerdab和MolFormDisambigNav改成MolFormIndex和MolFormIndexNav如何？還是前者要隨英文全稱Molecular formula index。原來的Isomerdab和MolFormDisambigNav需要留下重定向嗎？--微腫頭龍（留言） 2024年7月12日 (五) 07:32 (UTC)[回覆]
看有沒有使用吧，移動完成後沒有使用可以直接刪了。另外也可以改成MolFormNav之類的（短一點）（僅供參考）。--Leiem（留言·簽名·維基調查） 2024年7月12日 (五) 07:36 (UTC)[回覆]
突然想到Molecular formula是不是不包含像CuSO4這種的？還是要改成Chemical formula（也對應「化學式同類索引」）？--微腫頭龍（留言） 2024年7月12日 (五) 07:41 (UTC)[回覆]
@Leiem--微腫頭龍（留言） 2024年7月12日 (五) 08:22 (UTC)[回覆]
@微肿头龙：應該是吧，但是類似CuSO4沒有同分異構體，可以直接重定向至條目。--Leiem（留言·簽名·維基調查） 2024年7月12日 (五) 08:23 (UTC)[回覆]
有少數有包含金屬C55H70MgN4O6。但確實不多，還是用回MolForm吧。@Leiem：--微腫頭龍（留言） 2024年7月12日 (五) 08:34 (UTC)[回覆]
（題外話：包含金屬的可以單獨整理出「Category:化學式同類索引/含金屬」之類的，這些同分異構體主要是在有機部分，比如正丁基鋰和叔丁基鋰、α-羥基丁酸鈉和γ-羥基丁酸鈉等）--Leiem（留言·簽名·維基調查） 2024年7月12日 (五) 13:31 (UTC)[回覆]
已添加分類，不過由於有機金屬化學包括類金屬，因此在下把矽等類金屬也算進金屬里。--氫氰酸留言區 2024年7月12日 (五) 15:46 (UTC)[回覆]
謝謝，不過矽、硼之類的在中文裏很少稱作金屬？（先這樣吧）--Leiem（留言·簽名·維基調查） 2024年7月12日 (五) 16:01 (UTC)[回覆]
已修改，現在不算作金屬的元素包括H、He、B~Ne、Si~Ar、As~Kr、Te~Xe、At、Rn。--氫氰酸留言區 2024年7月13日 (六) 04:45 (UTC)[回覆]
支持縮短模版名。不過，目前MolFormDisambigNav的引用量高達2000+，不用機械人的話需要很久才能改完。--氫氰酸留言區 2024年7月12日 (五) 09:01 (UTC)[回覆]
這個可以用AWB慢慢改（化學式條目還有一些其他東西我想一併改），但我有點擔心會對Special:最近更改造成大量覆蓋，干擾到其他巡查員工作。--微腫頭龍（留言） 2024年7月12日 (五) 09:07 (UTC)[回覆]

請求關注：Talk:地球大氣層 § 建議更名：「地球大气层」→「大气层」

Talk:地球大氣層 § 建議更名：「地球大气层」→「大气层」有用戶正在徵求社群意見，敬請編者關注。

簡要說明：無法就「大氣層」是否有專指地球大氣層的定義達成共識，邀請社群參與討論。

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

讓我編輯

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

見草稿:Re:scene。-千村狐兔（留言） 2024年7月13日 (六) 00:51 (UTC)[回覆]
過濾器無誤，不應移除字詞轉換模板，除非您確認它出現了問題；另外，03月26日應寫為3月26日，不需要前導零。——暁月凜奈 (留言) 2024年7月13日 (六) 00:57 (UTC)[回覆]

關於扎基拉姆

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

其他

沒有主題的頁面如何評級

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

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

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

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

Random Thought: 跟進英維的WikiProject banner shell改版

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

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

我倒是想起一個事兒。英維最近改版了{{WikiProject banner shell}}模版（新樣式在這裏），新的模版可以單獨給條目一個總體的品質評級，各個WikiProject可以直接繼承這個quality assessment，也可以搞自己的評級。你看是不是能實現你的沒有管轄之WikiProject依然可以有評級的願望？ --MilkyDefer 2023年12月7日 (四) 14:59 (UTC)[回覆]

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

第一階段：修改WikiProject banner shell

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

第二階段：修改WPBannerMeta

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

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

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

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

相關議案

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

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

第三階段：完善制度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我有不同意見。英維的WPBannerMeta模組有很長一大坨代碼都是在處理這個Vital Article的事情；具體來說，他們把校驗這個Vital Article是不是真的Vital Article什麼的邏輯全部寫進去了。這一坨東西讓可維護性和可讀性（有可能還有效率）遭到了重大影響。我認為這更適合由一個外部機械人維護，而不是剝削這個已經很折磨人的Lua。 --MilkyDefer 2024年1月14日 (日) 12:53 (UTC)[回覆]

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

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

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

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

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

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

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

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

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

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

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

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

本主題或以下段落文字，在討論結束後應存檔至Category talk:缺少listas變量的傳記專題頁面。

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

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

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

評級系統缺失問題

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

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

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

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

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

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

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

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

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

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

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

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

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

支持。( π )題外話：台灣之星的標識現在還沒改。--桐生ここ★[討論] 2023年12月31日 (日) 10:36 (UTC)[回覆]
資慈，我覺得行。 --窩法乙烷 兒法夢碎 2024年1月1日 (一) 14:38 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

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

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

提案已通過請求佈署

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

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

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

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

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

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

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

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

分類改名準備

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

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

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

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

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

第三階段：Wikipedia_talk:頁面質量評級標準#WP:QUALITY_升為指引

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

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

可能我上面沒說清楚，讓你以為我是反對分類改名的，更不是什麼越給我搞複雜，好啊WP:QUALITY永遠升不了指引都你害的，不能有問題不讓說是不是。總之是以下幾點：
  1. 頁面重新命名為Wikipedia:條目質量評級標準：因為評級針對的是WP:條目，其它模板級、分類級這些評級都是非標準級別（WP:QUALITY就是這麼寫的），那麼頁面應當以標準評級針對的對象命名，也就是條目質量評級標準。除非你打算搞什麼甲級模板級，那不是更複雜。此外還存在Wikipedia:條目重要度評級標準，那是否要改成Wikipedia:頁面重要度評級標準，總之得有一個要改
  2. 目前Wikipedia:條目重要度評級標準和Wikipedia:頁面質量評級標準是正交的，所以有Category:分類級低重要度宗教條目這種東西的存在，那是不是得命名成Category:分類級低重要度宗教頁面。既然分類級不屬於標準評級，因此也不必設置重要度，引入更多複雜性，這類頁面統統扔去Category:不適用重要度條目去（或者說Category:不適用重要度頁面）。
  3. {{Grading scheme}}修改，因為Wikipedia:頁面質量評級標準調用了，這個就是作為WP:指引用詞統一的問題
--Kunjinkao（留言） 2024年3月8日 (五) 05:20 (UTC)[回覆]
  1. 無論是前次討論還是本次討論，都沒有提到重要度，因此認為重要度的那個論述怎麼樣，並不礙於WP:QUALITY升為指引一事。
  2. 此修改技術成本過大，且認為這樣修改與否並不礙於WP:QUALITY升為指引一事。由於目前架構問題，該修改技術上的複雜性，不建議做此修改。除非有人能提出具體的patch ，否則我不支持也不相信此修改能夠被實際執行。（當然，如果有人做patch 就另當別論）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回覆]
  3. 如果沒有人有異議，你可以自行修改。
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回覆]
關於第一點，重要度只是順帶提及，核心是評級針對的是WP:條目，其它模板級、分類級這些評級都是非標準級別，那麼頁面應當以標準評級針對的對象命名，也就是條目質量評級標準。--Kunjinkao（留言） 2024年3月8日 (五) 06:26 (UTC)[回覆]
Wikipedia_talk:頁面質量評級標準#c-Cdip150-2016-03-14T04:31:00.000Z-Liaon98-2016-03-14T02:44:00.000Z。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:47 (UTC)[回覆]

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

已完成當時的共識Wikipedia_talk:頁面質量評級標準#總結「將不是條目命名空間的評級分類從XX級條目改為XX級頁面」，因此將安排Wikipedia_talk:頁面質量評級標準#WP:QUALITY_升為指引重新公示。重Ping當時參與討論的人：@Liaon98、JyunWaan、Lssrn：@Cdip150、Temp3600、Peacearth：。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月19日 (二) 10:49 (UTC)[回覆]
  • 當時的討論是專題各自評級，而現在的情況是多了通用評級（WPBS）。所以時過境遷，WP:QUALITY要重新討論了。我之前沒有參與討論，現在有不少想法：
  1. WPBS評級是專題評級的容器，還是一套有自己標準的獨立評級？現行做法屬於前者：WPBS評級繼承專題的評級，且受各專題各方面的干涉，因此評級原則看似「隨意」。

    一篇列表WPBS獲評List級而非CL級，是因為它確實沒到CL級。另一篇列表獲評List級而非CL級，只是因為某個參評專題不設CL級。第三篇列表和第二篇品質相似卻成功獲評CL級，原因竟是不設CL級的專題沒有「染指」該列表。

    所以我的看法是，通用評級就該如WPBS模板所言，確實地「依照頁面品質評定標準」來獨立評定，而不是在各專題評級間謀求公約數。可以參考專題評級，但把專題評級當爸爸就不對了😂
  2. 承上，如果我們確定WP:ASSESS本位而非專題評級本位，那就要討論條目的WPBS該設立哪些級別？英維的PIQA是只支持FA、A、GA、B、C、Start、Stub、FL、List、Unassessed幾個經典的「標準級別」。而我們的WPBS是大雜燴：既包括BL、CL這種品質向評級，也包括Future這種非品質向評級。所以WPBS評級所支持的「標準等級」該設哪些？
    • BL、CL等品質向等級有兩條出路。一是如同英維，只收錄廣為人知的傳統評級，不收錄BL、CL這種額外等級；個別專題想啟用就在自己的橫幅上評。二是將BL、CL升格為通用評級，全體專題橫幅亦自動啟用BL和CL；如果個別專題自己討論後堅持不用BL，那可以用掩碼把BL改成List或B。
    • 對於Future級，一篇未來級條目可以很爛（Stub），也可以比較充實（C），那Future這個等級就沒有實現「評價頁面質量」的作用。我能想到的用途是在話題中，用未來級作為寬限條目的標記，暫時不影響認定。但這個等級的確不夠「通用」，或者說和條目所用的品質評級不是一個維度。
    • 對於A級條目。英維的A級在軍事史專題存活（且活得很好），但其他專題都是死的。因此英維多次討論A級的出路，比如從PIQA里開除把A級之類。但你維是真的所有專題都不評A級；所以，把這個只有理論價值的等級從通用評級中滅了挺好。
    • 上面的想法也會影響小工具的設定：包括對標準評級的契合，對各專題自定等級的支援，對非條目評級的簡化（非條目空間一般人手評級無效）。
  3. 下文有提到「消歧義級條目/頁面」。如果按照命名空間來理解，那就有一個問題：重定向在各個空間都有，那到底是叫「重定向級條目」還是「重定向級頁面」？（或者兩個都要，但這徒增煩惱）另一方面從實用性上看，專題統計「條目數」都是排除Disambig級的，那消歧義佔據條目空間就成了bug而非feature。這次從「條目」移到「頁面」更像是正名，但是後綴分家無論是技術實現上還是命名統一性上，帶來的麻煩都不少。考慮將後綴統一為「頁」，比如品質評級這邊的「乙級條目頁」「丙級列表頁」「模板頁」，重要度那邊也可以叫「高重要度頁」「未知重要度頁」，這樣觀後綴就知道是頁面評級體系在整活。
我明白很多內容都不在討論範圍內，但我認為之前討論本身就是系統性不足。比如把非條目品質評級改爲「XX級頁面」，那爲何條目品質評級和非條目重要度分類不動？是改條目和重要度分類真的弊大於利，還是單純沒有討論過而已？作爲這套系統創始者，英文版的非條目還用articles的，個中原因是否值得參考？--For Each element In group Next（留言） 2024年3月19日 (二) 16:05 (UTC)[回覆]
爭議已消失：
上述爭議因進一步討論已展開，因此可以視為爭議已消失-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月1日 (六) 10:55 (UTC)[回覆]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
@For Each element In group Next：老實說我真的不懂你們這些這時候再來提意見是用什麼心態再看事情的，這個提案已經放超過三個月了，又不是放一個星期就說要公示，硬是等提案要準備收尾才來提意見是怎麼回事？！我可以當成你是打算擾亂干擾提案通過嗎？！--SunAfterRain 2024年3月19日 (二) 16:40 (UTC)[回覆]
我幾年前的主業之一就是評級理論。Wikipedia_talk:頁面質量評級標準#WP:QUALITY_升為指引6年前甚至6個月前，我都會像推動MOS:FICT那樣，親自提出修改意見和方案（如WP:QUALITY第二段不符合新形式），讓WP:QUALITY成為更優質的指引。但現在評級方面，我認為和這個裝睡的社群去合作沒有什麼意義。所以我的做法就是不發言，看着這個社群未來到底走向哪裏。出於對當初理想的懷念，我寫下了這些明者自明的意見，但也僅此而已了。通過提案無非就是頁面多個「指引」的標籤；您看我用戶頁，就該知道我對這種「社群眾評標籤」有沒有興趣了。--For Each element In group Next（留言） 2024年3月20日 (三) 16:36 (UTC)[回覆]
@For Each element In group Next：我不管你到底對這個議題有沒有興趣，反正你現在的意思是上方內容純粹是發牢騷你沒有要干擾這個提案？！--SunAfterRain 2024年3月20日 (三) 17:12 (UTC)[回覆]
還沒有細看，但我對洛普利寧君遭到這樣的對待感到很悲哀。--Temp3600（留言） 2024年3月20日 (三) 17:43 (UTC)[回覆]
在有用的討論串下面離題吵架實在無奈，但似乎VP環境已經如此。
WP:CON明確指出"共識應採納多數人的意見，並和重要少數的意見作出適當妥協。"、"共識在維基百科是持續不斷的過程"，對於方針修改，更再次明示"共識最終將根據支持和反對該議題的論點質量所決定"。方針中沒有任何字眼要求討論應"收尾"，反而暗示了討論本身是可以無限延長，以不斷修改共識更貼合實況的。所謂擾亂更是莫名其妙。
回到討論本身，如果有足以反駁洛普利寧君的理據，直接提出來就可以。如果反駁不了，甚至根本沒有考慮到這一討論角度，那顯然就說明"之前討論本身就是系統性不足"，提案一方存有思考盲點，應該進一步討論下去。
回到這個提案。我與八年前一樣，支持將WP:ASSESS建立為指引。然而，洛普利寧的問題必須先得到回答:維基百科:通用評級與維基百科:頁面質量評級標準之間有潛在矛盾。通用評級到底是獨立的評級系統，還是專題評級的平均分?我對這兩者沒有特別的見解，但WP:ASSESS應該清楚指明這一上下級關係。
如果不幸某頁面只有一個專題，而這個專題將頁面評為"未來級"等奇怪級別，通用評級是否跟隨?
請賜教。--Temp3600（留言） 2024年3月21日 (四) 19:45 (UTC)[回覆]
@Temp3600：那我倒覺得您來主持好了，包含修改模板模組的部分，反正您看起來很閒可以泡在客棧陪大家一直耗。--SunAfterRain 2024年3月22日 (五) 01:35 (UTC)[回覆]
  • 折騰了三個月，我已經沒有修改評級模組的心力了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月22日 (五) 01:52 (UTC)[回覆]
  • Special:PermaLink/81985508#第三階段：完善制度這裏有說，一切以維基百科:頁面質量評級標準為主，當專題評完後，維基百科:通用評級再取各專題WP:ASSESS的公約數，不認為有矛盾。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月22日 (五) 02:00 (UTC)[回覆]
    • @A2569875：如果方針是FA級，指引是GA級，那現行WP:QUALITY+維基百科:通用評級大概只有C的水平，還需要很多工作完善：
      • WP:QUALITY說「評級主要由專題進行……」。那WPBS評級人是作為什麼身份評的？社群成員，還是專題成員？現在WPBS開展一段時間了，相信大部分人的評級邏輯是直接對WPBS評級（而不是專門針對各個專題）。這就和「評級主要由專題進行……」矛盾。
      • 有了WPBS後，就有了「社群心目中的評級」，這個評級就是WPBS的評級。這樣，大部分專題出於信任社群/懶得評級，而繼承了通用評級。對於舊頁面，現在的做法很好——假定WPBS評級為各專題評級的公約數。不過這個做法並非必然，我們也可以取各專題的最高值/最低值，只要社群願意信賴專題。例如英維只有WP:MILHIST真正地在評A，而其他專題是評GA或者B，此時一個做法是取A，而非眾數或向下取GA/B。
      • 但是下面的問題理論上和執行上都很成問題。例如維基百科:通用評級第5點要求「例如未啟用乙級的專題，通用級別遇到規則3判為乙級的情況時，則向下填寫為丙級……」。
        • 首先，很難判定專題是否啟用某個級別。機械人運行者好像都說過做不到這個事情，就更不用說人工評級了。
        • 其次，如果B級是標準評級，且多數專題都評B級，那這個條目在社群心目中就是B級。我們不應該遷就特例獨行的專題，否則公認的B級條目評C，那B和C還有什麼可比性？應該是說，不設B級的專題應該自己收拾自己的攤子，例如專題評級繼承B而表示為unassessed，或者用掩碼改成C。
        • 第三，現在的BL是標準評級嗎？如果不是標準評級，那應該呈現在社群通用的WPBS上嗎？如果呈現在WPBS上，多數編者沒見過BL，他們看得懂嗎？如果你認為大家能看懂，且樂見對列表細緻評級，那不如將BL升格為標準評級？如果升格為標準評級，就應該預設對所有專題的class mask啟用BL，否則又回到上一點專題「特立獨行」的老路。
      • 只有一個專題評Future，那WPBS技術上當然可以評Future（且只能評Future）。但上面BL甚至D級都是品質導向級別，那Future和他們並列（而不是attention之類的flag）是什麼用意？還有，如果兩個專題一個是CL，另一個是Future，而且兩者都未設對方的級別，那WPBS到底聽誰的？
      • 上述問題可以不斷打補丁解決（維基百科:通用評級就是打補丁的成果），但這並非良方。大道至簡，最實際的方法是：編者以社群成員的身份，以WP:QUALITY的標準評級中的選項為依據，針對WPBS評級。專題評級理論上和WPBS獨立，但實踐上的評級方式是信任社群評級。然後，我們討論WPBS具體該支援哪些級別——對於條目，我建議支援傳統級別，或傳統級別+BL/CL/(SL?)；而Future、Merge不屬於品質評估，而A級又極不活躍常常被人誤解，這兩類可以考慮從通用級別中除去。至於要修改的地方，無非就是修訂WP:QUALITY、WPBS支援代碼、class/mask預設啟用代碼，就像您說的，要改很簡單。
      • 您可能看不懂我的留言，也可能看懂了但沒有觀點。建議您和有實際開設特殊級別的專題聯絡，看看他們的意見。我可以寫出藍本，但我不想干涉這件事情，也不想在這個物是人非的地方留言。
    • @SunAfterRain：我可以當成你是打算擾亂干擾提案通過嗎？！。當然可以！您怎麼想是您的權利。--For Each element In group Next（留言） 2024年3月22日 (五) 16:26 (UTC)[回覆]
      你以為你維的評級模組是Module:Namespace/data這種隨手改一改就好的是吧，改一次的成本有多高您可以自己改看看，不是什麼看起來很簡單改一改就好--SunAfterRain 2024年3月23日 (六) 03:13 (UTC)[回覆]
      我2015年到2016年大幅更改過WPBM相關子模組，比如引入bchecklist。而且如果WPBM不能滿足我的需要，我也有能力手寫模板。我固然不是A2569875那樣的技術專家，但我也知道那些內容屬於微調，哪些內容屬於重煉。（那時候您似乎還沒註冊，如果您問一下八九年前一些關注評級的老用戶，您大概會知道我都幹過什麼）
      上面的問題我早在兩個月前就A2569875君交流過。當時他表示現在只討論技術問題，具體制度問題可以後議。我的意見不是技術問題——等真正的技術修改部署後，對WPBS屏蔽某些等級就OK——所以的確可以後議。A2569875當時態度很激烈，我不想影響他的心情，而且他應該是沒有看懂我的意見，所以我就沒有繼續爭論下去。另一方面如果我做主導人，和議案有關的問題無論在發哪裏討論，我都會接受；而A2569875的思路就是a討論頁不談b問題（我不知道這是不是今日你維的討論規矩）。我們倆電波對不上，我也不想在客棧留言，所以就直接走了。現在的論題正是「第三階段（WP:QUALITY_升為指引）討論」，既然是討論（而不是走形式直接通過）那我充分陳述我對WP:QUALITY的看法很合理吧？而且討論3月19日開始，我也沒有拖到26日要結案的時候發。
      就我看來，應該一開始就討論WP:QUALITY評級這個哲學問題，討論好方向之後再開始技術修改。而且有了修改體系背書，A2569875的技術修改也能一路綠燈，不用喊「折騰了三個月，我已經沒有修改評級模組的心力了」。不過中維人少，評級哲學上確實沒幾個人能想到這麼深；就像技術方面沒A2569875，其他人也推不了這個提案。最後我認為本站應該以理服人，而不是靠方針指引或沒討論深度的「共識」堵嘴：能指出問題的內容標上指引也是根基不牢，有道理的論述沒有標籤也應該令人尊敬。--For Each element In group Next（留言） 2024年3月23日 (六) 05:29 (UTC)[回覆]
      別為你不參與討論找藉口，電波對不上不代表就可以事後再來批判，你說以理服人光是你用這個理由我就覺得你服不了人了
      另外你覺得你的意見不是技術問題但事實就是改動不小的技術問題，光是要改動一個分類就要牽涉到多少模板模組了--SunAfterRain 2024年3月23日 (六) 05:49 (UTC)[回覆]
      您的考慮方向我很贊同。不過如果例子舉成「改動一個模板就會牽涉多少分類的移動」，那會更有說服力 --For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回覆]
      你到底在舉什麼...--SunAfterRain 2024年3月23日 (六) 07:28 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
  • 首先感謝宇凡君的努力，您辛苦了。順便說一點離題得罪人的話：
  • 目前的問題如要解決，通用評級指引勢必重寫。問題只是要怎樣重寫而已。說白了，洛普利寧是反對通用評級的「由下而上」邏輯，再深挖下去，涉及專題組與社群整體之間的互動問題，對應現實生活中的中央－地方政府間，集權－分權的沖突。這樣展開就顯然太複雜了，我只是希望指出為什麼洛普利寧會認為這個指引寫得不好。
    回到維基。儘管從憲法的觀點出發，確立各子組織間的權力分立應是建立規則的第一步，但考慮到中文維基並不怎麼關注這一問題，我就建議維持現狀好了，省得麻煩。反正即使是下而上，要修改專題評級，直接一起修改所有專題的評級就可以（顯然這就一次侵犯了數個專題的自主權，但上面說了，中維人這方面的理解力有限）。下而上的（理論上）優勢當然是「各專題組可以按各自所擅長的領域，共同對跨領域的條目進行評級，會比WPBS只用一個評級員來得準確」。實際上嘛，就是懶得改。
    「WPBS評級人是作為什麼身份評的」：從下而上的觀點而言，沒有專題組的條目評級，算是社群託管了該條目，留待專題組前來接收，等價於聯合國託管理事會。最終還是需要專題組的專家前來正式評級。
    "標準評級":基於減少修改範圍（懶）的因素，建議只容許使用「標準級別」來評級。也就是說，暫時放棄將BL／CL加入WPBS，待更多專題啟用這些評級，更為人所熟悉後，再來討論。future等評級則不容許更新到WPBS上去，機械人應視這些條目為「沒有評級」，由人類前來處理。
    最後，感謝@For Each element In group Next：前來，指出這些要點供大家討論。說實話我本來也不想發言的，打了這些東西花了我一個多小時。也希望你能與我一起堅持到這項修改完結。
    以上。--Temp3600（留言） 2024年3月23日 (六) 03:33 (UTC)[回覆]
    如果硬要扯開這個話題，我反倒支持廢掉所有專輯的質量評級全部統一處理，因為你維專題參與人數實在少到除了幾個大專題之外沒有辦法給出一個真的符合自己專題的評級標準，而且去查大專題的評級標準實際上也與通用標準沒有差異，那這樣給各專題評質量有什麼意義？--SunAfterRain 2024年3月23日 (六) 05:54 (UTC)[回覆]
    （以上沒有要廢掉重要度評級）--SunAfterRain 2024年3月23日 (六) 05:56 (UTC)[回覆]
    如果完全廢除專題評級，將權力上移給WPBS，那就算不談這種集權行為是否影響了專題組的自治，也需要將目前已經由專題組評級的條目改為WPBS格式，並處理評級不一致的問題。我是不太看好能搞定啦。--Temp3600（留言） 2024年3月23日 (六) 07:10 (UTC)[回覆]
    @Temp3600：感謝您的解釋！雖然討論很不愉快，但至少討論者都能理解我要引出的思考點了。現在我的任務大功告成了--For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回覆]
    喂喂，不准跑掉（ --Temp3600（留言） 2024年3月23日 (六) 07:14 (UTC)[回覆]
    所以你知道為甚麼我說他明顯有意擾亂了吧（攤手--SunAfterRain 2024年3月23日 (六) 07:26 (UTC)[回覆]

隨意的分段

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

D級與B+級等標準討論

接上文宇帆君列出的等級。新級別是要寫文檔的，所以下列意見供參考：

  • D級目前看來只有宇帆君活躍的多面體在用，其條目是介於C和Start之間。講真，流行文化領域，因為關注粉絲向這種扣分內容，D級還是很好用的。
    • 比如明星條目，內容上已經有C級該有的內容，但因為很多內容都以粉絲介紹口吻出現，需要大量清理和改寫；這時評Start太可惜，就可以評D級。這基本就像多面體專題說的，「內容上可能達到C級水準，但其他方面有嚴重缺陷」。或者說，寫條目的人擅長事實性內容，但不了解這裏的格式手冊，寫出的東西很隨意不像百科。
    • 另一方面，虛構作品條目也強調要寫反響等現實世界內容。一般來說，編者不寫現實世界內容，就表示他不熟悉格式手冊，所以條目格式、行文等方面也不會太好。這種條目又要清理又要擴充，就可以給Start。但也有從英維FA翻譯一半的，條目序言完整、作品介紹也很規範，但該到製作歷史和評價，他又他不翻譯了。這種只用擴充不用清理的，也可以從Start抬升為D。
    • 可以看到，流行文化領域這個D級主要還是可以彰顯「內容雜亂/格式差」。但科學等領域大概沒有「粉絲內容」，所以這個D級通常會怎麼用？
    • 另外有了D，是不是未來有可能對等增加DL？
  • B+只有英維數學專題有用過，而且現在刪了；本地沒有專題實裝過，只在一些理論研究中提到，所以還是要想想標準怎麼訂。
    • 之前B+的評級標準是「條目高於B級標準」，再把B級標準抄了一遍，這就比較不良定義。GA和B的區別主要在GA還要求中立性穩定性，且文筆和格式的要求高於B。如果要搞B+，那標準大概就是「不要求中立性和穩定性，但其他方面同GA標準」？PS：B6提到的WP:JARGON和地區詞在GA標準里沒有體現，所以B在某些方面還高於GA；不過現在的英維已經把JARGON要求增補到GA標準里了。
    • 之前有提過增設優良列表（GL）。GL和FL的主要區別可以理解為GL不管紅（綠）鏈，且序言不用太優美；這個境界就有點像B+和GA了。不過，FL和GL應該是要有本質差異的——類似WP:GVF的comperhensive和board coverage。例如對於遊戲系列，FA應該像死忠那樣列出小眾改編作品，而GA可以只列出重要作品。（但是很多領域列表是不是沒有這種問題？）
  • 小小作品更像是一個臨時狀態，和未評級一樣是不該長期存在的。而且小小作品只是長度短，問題還沒有廣告、侵權等小作品更嚴重，所以整體統計上把小小作品拆出來的意義是？從維護追蹤角度考慮，WP:PETSCAN或者Shizhao的專題機械人通告應該都很好用了。--For Each element In group Next（留言） 2024年3月26日 (二) 15:50 (UTC)[回覆]
    • 感謝提供意見。關於增設新評級級別，如您提出的D-List和Temp君提出Start-List以及上述提到的GL，我想作為長遠目標來討論，現階段先不處理。一來是phab:T360012本站評級資料表更新工單根據API測試似乎已合併到主程式，而GL則是因為評選設立草案無共識所以工單中就沒有申請加入該等級，所以就算現在評了GL可能也無法被某些系統正確識別，同時，一直頻繁變更感覺對基金會人員也不太好意思；二來是又要改十餘個全保護模板了 囧rz……。（註：如果說有了D就要對等增加DL，那為何有了GA沒有對等增加GL😅 甚至圖片有「特色圖片」若對應FA的話，那為何沒有GA對應「優良圖片」、A對應「甲級圖片」、B對應「乙級圖片」[開玩笑的]）另外您提供的D級條目用法也十分不錯，我(＋)附議這樣子的用法，科學上可能可以用在使用了太多行話術語導致多數人看不太懂的這種情況吧；而Bplus 我這邊是暫無其他想法，如果有其他維基人有什麼想法歡迎補充；小小作品級是當時評級系統開發階段進行測試時增加的級別，當時我找了幾篇正文少於50字的條目但沒被掛小小作品模板的「老條目」評上了此級，來試驗系統能否接受輸入，不過後來這些條目一些被提交AFD了、一些被擴充成小作品級了，但考慮到條目如果持續擴充也會持續升級啊，例如小作品升初級，這只是換成小小作品升小作品級而已，只是通常條目停留在小小作品級 小小作品級的時間可能會非常短而已。另外，我前幾個小時仔細重看了一下每個級別，發現比較有問題的應該是deferred級（中維評級系統本次更新完顯示為擱置級 擱置級）經查，該級別於2015年被加入中維評級系統資料表中，但在WP:TG簡單討論並對照英文維基還有此級別的專題說明顯示，該級別代表的意義是「本專題不提供評級，轉介由涵蓋本專題的專題提供評級」所以可能也不叫做「擱置級 擱置級」，TG上有群友建議「轉介級」，不過這種級別對上通用評級的話，基本上存在感就沒了，阿卡林～，不過UUM表示這種轉介具有一定程度「重要性」，可能要討論一下，看是要改名還是乾脆就廢除掉，或者以「未評級」論之類的。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月26日 (二) 16:52 (UTC)[回覆]
    • 感謝宇凡的研究，這個轉介級我都沒聽說過。評級級別方面，宇凡君所指的技術困難確實存在，就像我們這幾天討論了一下，又想到找到這麼多評級。如果每次都去phab改，不免擾民。我初步的想法是，quality 指引的標準評級部分建立為指引，規定wpbs 目前社群認可的評級；專題評級維持論述級，方便專題修改，待有共識後再處理。至於wpbs模版，則不需修改原碼，只需在模版說明頁等寫清楚那一些評級因尚未有廣泛共識，暫不開放使用，就可以了。
    • 標準級方面，我比較關注CL與乙上，大家懂不懂得評。雖說當成推廣也無不可。—Temp3600（留言） 2024年3月26日 (二) 23:53 (UTC)[回覆]
  • （有感而發）除了本子節開始的爭議外，以上討論與研究其實都滿有意義和價值的，如果能提前在去年十二月，也就是我當初Ping了洛普利寧時，他就發表了這些意見，並開展了我們現在所討論的東西，那我覺得WPBS應該會更完美。不過現在說這些都是後話了。另，跟大家說聲抱歉，我當時一心只想着如何把MilkyDefer起草的臨時方案開發成正式方案、如何pass所有testcases 和解決討論頁上各種問題回報（1、2等），一切考量都以技術為優先（我當時優先級最高的考量是：程式怎麼寫更省效能，於是出現了mw.loadData("Module:PJBSClass/page")用於讓該功能在整個頁面解析的過程只會跑一次，而不會每次調用通用評級時都跑以節省效能），卻忽略了行政上的執行問題，而導致了今次的爭議，我感到十分抱歉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月27日 (三) 01:30 (UTC)[回覆]

B+我之前寫過論述。鑑於中維的GAN機制（時間短、需求票數多，且評審者普遍社會惰性），B+當GAN預審還是很有生態位的。但是在務實上，等GAN評審素質普遍超過這個乙級評級，B+才會有得玩 聳肩

我想B+（Bplus）的標準可以用WP:WIABCA的大綱來套用WP:WIAGA：

這樣B級評審時也順手按GA（B+）提意見。--For Each element In group Next（留言） 2024年3月28日 (四) 14:20 (UTC)[回覆]

WPBS級別列表

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

能夠由{{WPBS}}程式自動評級的級別（詳情）
典範 特色列表 特色圖片 優良 小作品 列表 同類索引
消歧義 重定向 沙盒 模板 模塊 分類 文件
草稿 主題 專題 用戶 使用說明 界面 非條目

以下建議供行政組參考：

  • 標準品質級別（可填寫在WPBS）：
    典範級 典範級[FA]、特色列表級 特色列表級[FL]、特色圖片級 特色圖片級[FM]、甲級 甲級[A]、甲級列表級 甲級列表級[AL]、優良級 優良級[GA]、乙上級 乙上級[B+]、乙級 乙級[B]、乙級列表級 乙級列表級[BL]、丙級 丙級[C]、丙級列表級 丙級列表級[CL]、丁級 丁級[D]、初級 初級[Start]、列表級 列表級[List]（暫時作為初級 初級列表使用）、小作品級 小作品級[Stub]、小列表級 小列表級[SL]、小小作品級 小小作品級[Substub]、無級別 無級[No]
  • 標準類別級別（可填寫在WPBS）：
    消歧義級 消歧義級[Disambig]、同類索引級 同類索引級[SIA]、重定向級 重定向級[Redirect]、沙盒級 沙盒級[Sandbox]、模板級 模板級[Template]、模塊級 模塊級[Module]、分類級 分類級[Category]、文件級 文件級[File]、草稿級 草稿級[Draft]、主題級 主題級[Portal]、專題級 專題級[Project]、用戶級 用戶級[User]、使用說明級 使用說明級[Help]、使用說明級 界面級[interface]、非條目級 非條目級[NA]（如TimedText:空間）
  • 非標準類別級別（不應該填寫在WPBS）：
    圖書級 圖書級[Book]（曾有共識引入，但因技術原因部署無限期推遲）、音頻級 音頻級[Audio]（只有少數專題將File級做細分，WPBS應都填入File級）、圖像級[Image]（(▲)同上）、非頁面級 非頁面級[NAPage]（只用於特殊專題）
  • 非標準品質級別（不應該填寫在WPBS）：
    優良列表級 優良列表級[GL]（討論尚無結果）、特色圖片 特色主題[FPO]（未通過設立）、完成級 完成級[Complete]、充實級 充實級[Substantial]、簡單級 簡單級[Basic]（完成、充實、簡單僅用於PJ:主題）
  • 非標準級別（不應該填寫在WPBS）：
    未來級 未來級[Future]、動態級 動態級[Current]、合併級 合併級[Merge]、請求級 請求級[Needed]、擱置級 擱置級[Deferred]、
  • 技術性級別（不應該填寫在WPBS）：
    委員會級 委員會級[council]（僅做圖示用途，不應手動輸入此級）、 錯誤級[Error]（出錯時會自動加入，不應手動輸入此級）、未評級 未評級[Unassessed]（無提供時自動產生，不應手動輸入此級）、未知級 未知級[Unknown]（無法正確識別的情況，應修正之，而不應手動輸入此級）
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月6日 (六) 03:43 (UTC)[回覆]
感謝總結。我有一些疑問：
  • Substub作為標準品質，似乎比較增加維護負擔？會創建小小作品的基本都是新手，他們不懂得在討論頁掛{{WPBS}}填|class=substub。維護人員也都在條目頁標記{{substub}}，然後打撈人員再從Category:小小作品追蹤，這就基本就沒人會管討論頁。而且就算有專題模板，如果利用討論頁的分類來維護，就要從討論頁跳轉到主頁面，也是比較低效的。（MilkyDeferBot可以根據討論頁橫幅和條目頁{{substub}}自動生成頁面列表，這樣也沒必要用討論頁評級）此外如果substub是被人手填了，那就還要經常盯着條目，看評級是否過時。所以依靠評級模板來維護substub，感覺有種打撈一分鐘，評級三十秒，性價比相當低。所以，WPBS層面統合到stub是否好些？
  • 正規條目都應該有品質評級，尚未評估品質的條目是Unassessed，條目空間的Disambig等特殊頁面也考慮進去了。看英維也沒no這個級別，所以無級別的條目會是怎樣的？
--For Each element In group Next（留言） 2024年4月6日 (六) 05:20 (UTC)[回覆]

等級標準小結

洛普利寧在上文提到的「PJBS之PJBSClass.getClassByPage()」自動評級（小勘誤：自動評級實由PJBSClass/main.getClassAuto()和PJBSClass.getAutoClass()共同完成，前者以頁面狀態和掛有模板判斷、後者只看Namespace），這些評級會根據頁面掛的模板、子頁面名稱、頁面狀況和所在命名空間等進行自動評級。這些評級分為兩類：不可被|class=參數複寫的評級以級可被|class=參數複寫的評級。
這些級別有：
  • 不可被|class=參數複寫的評級：重定向級 重定向級、特色圖片級 特色圖片級（註：|class=有值時會強制被改為File級）、模板級 模板級、模塊級 模塊級、分類級 分類級、文件級 文件級、草稿級 草稿級、主題級 主題級、專題級 專題級、用戶級 用戶級、使用說明級 使用說明級、使用說明級 界面級、非條目級 非條目級
  • 可被|class=參數複寫的評級：典範級 典範級、特色列表級 特色列表級、優良級 優良級、小作品級 小作品級、沙盒級 沙盒級、列表級 列表級、同類索引級 同類索引級、消歧義級 消歧義級
上文提到，目前不在WP:QUALITY中的級別都需要補上文檔，因此我起了以下草稿供參考：
（註：如果有需要修改可以直接編輯本表格，無須經過我的同意(不被視為修改他人留言)）
（註2：下表只列出目前未出現於WP:QUALITY的級別）
（註3：由於表格過長，已折疊。請單擊[顯示]以展開表格）
預計種類分成三類：標準級別（描述條目品質）、標準類別（描述頁面種類）、非標準級別（專題自定的東西）
@Temp3600：您看看這些資訊對行政組作業有沒有幫助？（請單擊[顯示]以展開表格）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月5日 (五) 10:48 (UTC)[回覆]
感謝宇帆君的總結。我大膽做了一些調整，說明如下：
  • Bplus之於GA類似A之於FA。A級的標準和文檔頁指出要走比較正規評審，類似這種，而不能像評B、C那樣隨手改|class=。所以Bplus的要求中我也提了要做評審；不過這也就是這麼一說，大家肯定還是會隨手改的😂。另外A級開始才算專業，GA只能叫接近專業（我上面說的，英維A級需要專家來評審，而GA不需要），所以調整了一下措辭。
  • D級還是可能有格式問題的，基本上B級才算比較遵循格式手冊，連C級可能都差一點，而且愛好者內容廣義上也算格式問題。其他方面調整了一下語言，大體是說條目內容方面有含量，但其他方面比較差。
--For Each element In group Next（留言） 2024年4月5日 (五) 13:54 (UTC)[回覆]

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

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

對於Wikipedia:頁面質量評級標準（以及Wikipedia:通用評級）還有一些邏輯上的考量：

  • 英文版的頁面en:Wikipedia:Content assessment翻譯過來是內容評級。其內涵理論上包括評級流程、評級標準等多個部分。而中文版的標題是「頁面質量評級標準」，一隻介紹標準本身，二又強調品質評級。而當前頁面是從古早期英維版翻譯過來，現在兩邊都改了很多，這就很微妙了。所以頁面是否要改名「Wikipedia:頁面評級」？
  • 如果從標題強調質量評級來看，頁面似乎應該將「標準質量評級」（≈條目）和「標準類別級別」（≈非條目）分設為兩個大節。說約等於是因為特色圖片屬於非條目但又要評估品質，而同類索引（SIA）是自動評級但理論上屬於條目。
    • 對於條目品質評級部分，是否需要流程圖輔助說明？（比如寫入指引頁，或放在論述頁給個連接）
  • 如何表述「通用評級」與「專題評級」的關係？從目前的討論來看，可能還需要一個頁面（可能是Wikipedia:頁面評級）釐清：
    • 社群和專題都可以各自獨立地對頁面評級。評級結果登記於條目討論頁頂部。
    • 通用評級由社群編者評估，對社群負責。本頁刊載的等級標準為通用標準，即適用於WPBS的通用評級。
    • 專題評級由專題自行解釋，但因為專題評級一般直接繼承通用評級，所以也還是這套標準。部分專題可能自選啟用或關閉級別，也可能重新詮釋通用級別，這些內容具體在專題評級頁刊載。

我希望聽聽其他編者的意見，所以暫時不會積極回復。--For Each element In group Next（留言） 2024年4月14日 (日) 15:17 (UTC)[回覆]

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

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

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

修訂案

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

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

後續討論

關於 rater.js 腳本

前面的討論貌似沒有涉及到老版本的rater.js腳本（User:Chiefwei/rater aka en:User:Kephir/gadgets/rater）。貌似enwiki那邊已經廢棄了老版本的rater.js，並且由Evad37推出了新版的rater.js（en:User:Evad37/rater）。我再考慮將新版本引入並做本地化，不知道目前是否已經有類似的工作了？--Ceba_robot 才不是機械人！ 2024年2月16日 (五) 17:57 (UTC)[回覆]

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

Unblock-zh.org

Unblock-zh.org網站的樣子

很久以前討論過的一個項目，也就是unblock-zh的網站版，我最近給他做出來了，如果對測試版軟件感興趣的話，請去 https://unblock-zh.org 這裏去看看。（注意測試版軟件，你的用戶最後很可能被刪掉！）7月7日update：軟件進入試運行階段，此時產生的工單等數據將永久保留。Bluedeck 2024年7月8日 (一) 19:21 (UTC)[回覆]

附帶一個教學視頻 https://www.youtube.com/watch?v=IImfyNnRB4M

目前站外用戶申請賬戶的方式是Wikipedia:賬號請求發送郵件，其實也沒有太不方便。但是這個途徑我覺得還是更直觀一點，比郵件列表好用一點，尤其是管理員處理的時候。我的想法是網站可以和郵件列表並存，或者以後達成互聯。歡迎提出意見。Bluedeck 2024年4月29日 (一) 04:05 (UTC)[回覆]

PS. 已經收到tigerzeng的意見，允許用戶自定義提供的IP位址字段，以解決部分代理的問題。Bluedeck 2024年4月29日 (一) 04:22 (UTC)[回覆]
超 英 趕 美 —— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月29日 (一) 08:09 (UTC)[回覆]
我最期待的畫面出現了。--AT 2024年4月29日 (一) 09:14 (UTC)[回覆]
好吧，終於把這個弄出來了——是藍桌弄的？那就不出奇了。👍 讚——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月29日 (一) 09:29 (UTC)[回覆]
非常好UX。至於是否方便了用戶，我好奇能否在合理的範圍內收集一些統計數據作對比，這樣最有說服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)[回覆]
另外這個工具讓我想到了我很久之前做的維基媒體伺服器連通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)[回覆]
非常好軟件。
不必要的功能建議：1.通過遍歷封禁日誌的摘要有無對應模板，顯示是否是ip封禁。2.通過接口調用在界面一鍵創建賬戶（和授予ipbe？）
另外問一下數據託管在哪裏？將來投入使用的話需要作為存檔使用，所以數據需要備份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)[回覆]
一鍵創建賬戶/授予PIBE的話，有兩種途徑。第一，管理員通過oAuth授權unblock-zh.org，通過管理員賬戶操作，然後從本地日誌看來，操作者是管理員。第二種途徑是，成立一個機械人賬戶，比如名叫 unblock-helper-abot，並且賦予機械人管理權限，然後通過機械人操作，並在摘要里說明是根據哪個管理員的指令操作的。讓我來決定的話，我傾向於使用第二種方式，因為我希望儘量不要向第三方授權我自己的賬戶，但是第一種方式的日誌更加清晰。請問一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)[回覆]
使用OAuth可以只需要簡單的身份識別獲得權限，用於確認是不是登錄系統的對應是wiki的哪個用戶。然後代理操縱的機械人可以標記操作人員的wiki用戶名（通過前面獲得的信息）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月30日 (二) 02:33 (UTC)[回覆]
如果不改變單管理員授權模式，我傾向於第一種，這樣和原先的工作模式保持一致，便於查詢。
mw:OAuth/For_Developers稱應用做的操作會有標籤。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)[回覆]
在這裏沒有看到可以使用oauth給用戶添加組別的選項，那麼也是說IPBE的授予只能透過abot進行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)[回覆]
的確只能這樣。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年5月2日 (四) 03:40 (UTC)[回覆]
咱好像記着這種權限似乎不需要特別勾上某個選項就默認擁有，您要不嘗試一下？ Stang★ 2024年5月8日 (三) 01:14 (UTC)[回覆]
真的假的，在授權的時候不聲明卻可以操作改變用戶組這麼重要的操作？如果是真的那也是個bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)[回覆]
用API能查IP有沒本地封或者全域封，好像不是必要。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月30日 (二) 02:26 (UTC)[回覆]
👍 讚👍 讚👍 讚 牛逼--Dnaimfz（留言） 2024年5月11日 (六) 04:04 (UTC)[回覆]
@Bluedeck：話說可給管理員佈告板抄送一份通知連結至此？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月1日 (六) 08:43 (UTC)[回覆]
@Bluedeck：想好奇請問是否有考慮過部屬在wikitech:Help:Cloud VPS？如果有，為什麼不選擇部屬在該處？--SunAfterRain 2024年6月4日 (二) 09:30 (UTC)[回覆]
管理員通告版：不知道效果會怎麼樣啊。等上線後在ASN通告一下，然後TG呀IRC呀廣播一下應該就行。CloudVPS：他的介紹說自己是標準的VPS，但是又有跡象表明他不是完全標準的環境，導致我不想把時間花在部署，測試，更換環境，以及踩坑上面。對我來說，寫軟件是趣味十足的事情，而調試環境則是讓我胃腸不適的事情。目前我沒有換環境的需求，因為開銷太小。如果有我再考慮cloudvps。cloudvps的另一個問題是只有在virginia有DC，但這不是一個大問題。Bluedeck 2024年6月8日 (六) 04:00 (UTC)[回覆]
以我個人看法，部屬在CloudVPS的私隱疑慮絕對會比一個外部網站好很多，當然你維社群願意接受那我也沒什麼意見就是了。雖然不清楚是筆誤還是什麼的，如果開銷太小的話我自己是會考慮換過去啦。--SunAfterRain 2024年6月10日 (一) 17:54 (UTC)[回覆]
可以理解你所說的。我可以把cloudVPS當作一個長期目標，最終遷移到那上面去。Bluedeck 2024年6月14日 (五) 05:29 (UTC)[回覆]

試運行

在過去的幾周里，我增加了最後的一些的功能，分別是1）按日期搜索排列工單；2）郵件回復模板；3）管理員刪除工單、刪除消息界面；4）用戶改名功能。我想知道大家覺得還缺少哪些網站本身的功能（郵件伺服器、機械人授予IPBE除外）。如果感覺差不多了，那麼可以進行試運行。試運行期間，再對可能發現的新的功能需求進行補充。試運行的提議正在進行公告。如果通過，將會將網站首頁文字改為試運行，並暫時移除一些只具有展示效果的連結，然後在用戶無法註冊的提示頁面加入網站的連結，這些操作大概最多需要一天就能完成。在試運行決議通過前，如果對網站有任何問題，歡迎在此討論。Bluedeck 2024年5月13日 (一) 23:30 (UTC)[回覆]

功能方面，個人認為管理員不應該有刪除工單的能力，這個應該由維護者來做，比如遇到spam/擾亂性工單就打上相應的標籤，若干天后自動刪除；可不可以出個statistics大概寫一下某月某人處理了多少工單之類的；反spam方面怎麼樣，你覺得需要加個recaptcha嗎；模板建議是放到Github或者類似公開的地方，需要改的人發pr；可以考慮加一個link/merge功能麼，比如一個用戶就一個問題發了多個ticket，這個時候可以把它們關聯起來；感覺可以把login改的小一點，或者讓非管理人員意識到不需要登錄就可以發ticket。
另外就是建議放到toolforge或者cloud VPS上。順便問個問題，你覺得這個系統需要承擔unblock-zh最原始的封禁申訴職能嗎 Stang★ 2024年5月14日 (二) 01:47 (UTC)[回覆]
  • 謝謝提議！簡短回應：
  • 刪除工單就是為了應對擾亂才設計的功能。刪除之後可以恢復或檢視。（UI需要另外添加）工單的永久保留或刪除問題在下面討論。
  • 反spam：UTRS目前是阻止同一個IP位址多次發送工單。但是我的方案不記錄IP位址，無法阻止。我可以考慮一下記錄ip地址的hash，並由此進行rate limit。我個人完全不喜歡captcha，除非不得已，我可能會考慮上captcha。在此之前我會儘量用其他手段處理spam問題。我有一些asymmetric proof of work的方法能防止自動化的spam。如果有人無聊到要手工spam，那麼唯有記錄IP並進行區段查封這一個辦法。（但是這樣一來，不就把本身的目的給擊敗了？？）
  • 郵件模板：我不會放在github，畢竟不是每個管理員都會開PR，我簡單的開一個用戶頁面存儲目前的模板，誰想添加，給我留個言即可。郵件模板都是非常簡單的純文字模板。當然，如果你喜歡用gh，那麼在前端的repo里有一個文件，你也可以直接PR這個文件。
  • link/merge：race condition太多，最多做成stack overflow/github issues那樣，「標記為#109的duplicate。關閉」這種解決方案。
  • login改小：我肯定會讓新用戶看到不login就能發工單，這是一個重要的因素。
  • statistics：這個我一定會做，因為這會讓處理工單變得很有趣，我的設想是做一個leaderboard，能夠激發人們對於處理工單的無限潛能，哈哈哈哈。
  • Hosting：toolforge不能滿足我的要求，CloudVPS不熟悉。將來打算支持圖片上傳，需要一個能掛載S3的環境，另外多區域host允許你把伺服器託管在東京/首爾/LA。目前，伺服器託管在Vultr的新澤西區上面。
  • 這個網站做成網站的形式，是為了新用戶方便的註冊+IPBE（也就是unblock-zh-ipbe的功能）。處理被長期封禁的用戶在郵件列表中50-100封郵件那麼長的申訴，並不是網站初衷。如果有人就是要在網站上申訴，管理員也選擇在網站上處理，那我不會站出來阻止，但是如果網站上出現了對維基百科歷史有一定意義的討論內容，我覺得有應當抄送一份到郵件列表。
Bluedeck 2024年5月14日 (二) 04:12 (UTC)[回覆]
update: 已經增加了查看和恢復已刪除工單的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)[回覆]

另外還有兩個別的需要討論的問題：

  1. 工單是否永久保存？永久保存是目前的默認，而且郵件列表也是永久保存的。但是我覺得比如掛上「處理結束」標記90/180天之後永久刪除相關信息這個是更安全的做法，想徵求一下大家的意見。
  2. 開源：從一開始我就設想開源。這個項目有4個repo，其中3個可以在最近開源。一個需要我檢查一下有沒有API Key之類的物品遺落在代碼中，然後才能開源。請期待。
  3. 共同參與：如果您想共同參與開發，或者參與對伺服器的運維，歡迎在這裏提出來。Bluedeck 2024年5月14日 (二) 04:49 (UTC)[回覆]
感謝貢獻，整體非常完善。如有需要可以協助維護。--Borschts™ 歡迎外帶一碗羅宋湯 2024年5月14日 (二) 13:32 (UTC)[回覆]
存檔應保留，只是可以限制普通使用者存取。另外，也應考慮先行在站內撰寫說明頁面，或補充現有方針與指引不足，以便利用。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月14日 (二) 15:05 (UTC)[回覆]
注意到兩點可以改善：
  • 無法創建帳號者不應提供「我不想提供郵箱」的選項，創建帳號時需填寫對方電郵地址才能安全發送臨時密碼。如果不想提供郵箱則難以協助創建帳號。
  • 需要添加提示文字，若不提供IP位址則申請有可能不獲受理（始終審批IPBE時需要驗證用戶是否使用proxy）。
--路西法人 2024年5月15日 (三) 07:52 (UTC)[回覆]
我腦海中預想的不提供郵件的處理方式：網站生成一個強的隨機密碼並記錄在工單中，用戶通過隨機密碼登入。優點：用戶不需要郵箱地址。缺點：不提供郵箱的用戶等於需要不斷的刷新頁面查看處理進度，是一個糟糕的體驗。對於管理員，需要複製粘貼網站生成的密碼來創建賬戶，也是多了一個步驟。上面我只是說明了操作的可行性，至於這個功能是否保留，可以繼續討論決定。對於第二點，IPBEG如果有這個要求，那我完全可以添加這個提示文字（甚至可以在維基百科設置一個頁面，比如Template:Unblock-zh/strings/new-ticket-notice，然後網站可以反映這個頁面的任意文字。）Bluedeck 2024年5月19日 (日) 06:22 (UTC)[回覆]
我的想法是只要有任何第三方人員可以接觸到任何密碼的方案都是不安全的，尤其在發送郵件時在此類第三方網站留存臨時密碼亦是相當危險的；即使我信任你會盡力保障網絡安全，但顯然不安全的操作應儘可能完全避免。郵件、代理IP位址等都尚算不太危險的資訊，密碼真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)[回覆]
我想了一下覺得你說得很有道理。如果有的用戶收到臨時密碼後不加更改，那麼等於這個用戶的密碼永遠的掛在一個所有管理員都能看到的地方，是不妥的。我已經把界面改成如果請求賬戶，必須提供郵箱，否則無法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)[回覆]
一些minor的建議：about一頁，Puzzle Globe似可譯為「拼圖球」，Wikibooks譯名應為「維基教科書」非「維基圖書」。不提供郵件的提示，「一串30幾位的工單」應作「三十幾位」。login界面沒有明顯的返回按鈕，側欄也消失了。lookup界面可以考慮加注工單號和郵箱擇一提供即可。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年5月21日 (二) 03:01 (UTC)[回覆]
另外我在想讓其選擇點選提交IP的選項是否也應該把UA也提供給審核用戶檢閱（方便反破壞比對）。--路西法人 2024年5月23日 (四) 07:54 (UTC)[回覆]
統一回復。1）login界面有意如此設計。2）必須同時輸入工單號和郵件，否則任意人士可以通過廣泛查詢郵件探知私密工單。3）UA信息只有CU才能訪問，所以顯然不能提供。另外就算用戶主動提供了，那麼IPBE處理者拿什麼進行比對呢？畢竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)[回覆]
2) 啊那就是提前提示創建工單時未提供電子郵件的須放空？ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年5月27日 (一) 06:29 (UTC)[回覆]
沒有提供電郵的工單號會比較長，所以我可以改一下軟件，讓這種工單號不論是否輸入電郵都能夠正常查詢。這樣可以不破壞界面簡潔易用。Bluedeck 2024年5月29日 (三) 06:45 (UTC)[回覆]
好的👍 讚 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年5月29日 (三) 07:32 (UTC)[回覆]

將開始試運行。公示已經進行了一個多月，收集到了很多改進意見，並實施了很多更新。今天起，我將正式修改MediaWiki軟件界面，在網站上標註試運行字樣，並在公告欄和ASN中對社區和管理員們進行公告。Bluedeck 2024年7月7日 (日) 16:26 (UTC)[回覆]

@Bluedeck：請問IPBEG們可以如何存取工單？--路西法人 2024年7月10日 (三) 03:25 (UTC)[回覆]
@LuciferianThomas：我正在編寫為IPBE權限持有者提供權限的功能。完成後，IPBE將獲得和管理員基本一致的功能。目前編寫的功能是對於下方討論中方案一的實現。編寫完成後，我將會在用戶討論頁面通知IPBEG權限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)[回覆]

繁體支援

這個網站估計主要的受眾是大陸梯子人士。但是，由於很多管理員是繁體使用者，那麼我就增加了一系列的繁體支援，但是都是Google翻譯的。請繁體管理員看看管理界面的翻譯如果有很不和諧的地方，請指出來。如有需要，網站可以支援香港、台灣和澳門繁體的分別翻譯。Bluedeck 2024年5月30日 (四) 08:15 (UTC)[回覆]

感謝藍桌照顧繁體使用者，但我目前檢視似乎有一些介面仍然是簡體中文的，例如新建工單的部分，另查臺灣的教育部字典，work order這個詞在臺灣可以翻譯為「工令」、「工作命令」、「工作通知單」或「工作單」等，就是沒有查到稱之為「工單」之翻譯，惟我日常生活中前開所有詞彙均較為少見，平常類似功能之提交申請平臺反而被稱之為「電子表單」，這部分可能需要更多繁體使用者來指出正確的翻譯。--小過兒（留言） 2024年5月30日 (四) 15:30 (UTC)[回覆]
新建工單的繁體化已經完成。關於工單這個用語的翻譯，我參考了一下asus的網站，叫做「請求支援」、「搜尋案件」。不知道這算不算合適的翻譯。如果覺得「案件」聽其來正確，那麼我就把繁體語言的工單改稱案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)[回覆]
「工單」是對應「ticket」而不是「work order」，比如Zendesk香港也是叫ticket作「工單」[32]。再甚者，直接「搜尋申請」也是得了，不需要特地什麼ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)[回覆]
@Bluedeck：怎麼查閱或更改翻譯？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月1日 (一) 19:44 (UTC)[回覆]
通過改變瀏覽器的語言設置並刷新頁面，可以查看不同的語言版本。目前要修改，可以直接留言告訴我哪裏需要改。以後，會開放一個repo在github上可以pr。不熟悉sveltekit和github的用戶仍然可以直接聯繫我。Bluedeck 2024年7月2日 (二) 06:00 (UTC)[回覆]

工單的永久刪除

目前沒有這個功能。不過，根據歐盟GDPR要求，在用戶請求的情況下，應該提供一種方法永久移除其個人信息。我想讓管理員能夠在工單上添加一個標記，被標記的工單約一個月後真正的刪除。刪除真正執行前可取消。這種刪除只應該在特別的情況下進行（也就是用戶請求）。（也可以單獨只允許行政員執行真正刪除，但是我覺得管理員已經足夠可信，並且還有一個緩衝期間。）Bluedeck 2024年5月31日 (五) 23:04 (UTC)[回覆]

這個功能不錯。( π )題外話：我想知道維基百科不能刪除賬號是否符合GDPR，以及即使OS似乎也不是真刪除，這是否符合GDPR。有人去舉報一下是不是基金會就會實現這個功能了。--桐生ここ★[討論] 2024年5月31日 (五) 23:25 (UTC)[回覆]
應該是不符合的，而且顯示未登錄用戶ip這個似乎也有一定問題。然而我們要團結一致，不要把基金會舉報給歐盟。Bluedeck 2024年6月1日 (六) 05:34 (UTC)[回覆]

讓 IPBEG 在 Unblock-zh 上獲得和管理員一樣的權限

因為我覺得 IPBE 也是一大痛點，所以我覺得讓 IPBEG 能夠一起幫助處理會大有裨益。現在拋出幾個方案討論：

  1. 讓IPBEG組和管理員同在unblock-zh.org/zhwp下有一樣的（或者接近的）權限。
  2. 像郵件列表一樣，單獨新建 unblock-zh.org/zhwp-ipbe空間。
    1. 網站面向用戶的界面不改變，根據用戶是否需要 IPBE，自動將工單分發至 zhwp 或 zhwp-ipbe
    2. 網站設計改變，入口頁面一分為二，用戶需要自己選擇是投遞給zhwp還是zhwp-ipbe
  3. 不支持 IPBEG。

我覺得，從用戶體驗的角度，不希望入口一分為二。另外，不管選擇 1 還是 2，都需要一段時間來修改網站的代碼，但是 2 所花時間會更久一點，並且會增加日後維護的工作量（主要是會出現兩套表單同步的問題）。關於用戶私隱，由於 IPBEG 是簽署 NDA 的，應該視為可信人員，所以我比較傾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)[回覆]

設立IPBEG的本意就是許可IPBEG處理該類申請郵件，理論上可以說已有社群共識支持選項2，但已有共識未必支持選項1。IPBEG不能處理unblock-zh上非申請IPBE的工單。我是認為，一般而言封鎖申訴本應都是在公開場合發起，申訴內容多數都應該可被所有用戶檢視，實質需要使用郵件申訴封鎖的僅有無法編輯討論頁的情況。如你所言，IPBEG本有簽署NDA，就算看了也不應該會造成什麼問題（雖然能避免最好）。如果是最後採用最簡化的選項1，那我覺得您可以最低限度在處理人員的界面中加入標籤工單的功能，讓IPBEG能明確標記跟他們職務無關的申請，從IPBE隊列隱藏，僅能由添加標記的IPBEG（直至工單標籤被管理員確認）及管理員檢視。--路西法人 2024年6月2日 (日) 11:58 (UTC)[回覆]
如果要讓IPBEG不能看到非IPBE工單，那應該執行方式2更優。如果執行方式2，那麼管理員、行政員也應該自動獲得zhwp-ipbe空間權限，並進行工單自動分發。Bluedeck 2024年6月3日 (一) 08:34 (UTC)[回覆]
不是「不能看到」，而是「不再跟IPBE有關的就沒必要繼續顯示在同一隊列，令其他正在處理IPBE申請的用戶不小心點進去」。「看到」大概是不會有什麼大問題的。--路西法人 2024年6月5日 (三) 02:22 (UTC)[回覆]
分成兩列或許方案2實現起來更簡單？--桐生ここ★[討論] 2024年6月5日 (三) 09:51 (UTC)[回覆]
不是不行，但必須考量沒簽署NDA的管理人員是否有權限接觸unblock-zh內的工單，一般視乎工單是否涉及IP位址等可辨識資訊。如果要再這樣分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)[回覆]
還是那句話，我無法理解WMF要求郵件列表內的IP必須有簽署NDA才能接觸，但允許使用unblock模板直接把IP公開。--桐生ここ★[討論] 2024年6月6日 (四) 09:48 (UTC)[回覆]
我一開始聽說IPBEG需要NDA，但管理員不需要NDA的時候，我也覺得很費解。而且你知道嗎，你用的任何JS組件要是對外部資源進行請求，那麼就可能有意無意泄露IP。甚至你收到一封郵件，郵件裏帶個圖，這圖也能泄露IP。雖然說IP在wiki上被當作私隱，其實整個互聯網對IP的保護可以用奇差來形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)[回覆]
似乎是祇有涉及IP等私隱資訊時，纔要求管理員簽署相關協議。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:13 (UTC)[回覆]
@Bluedeck：只要不僭越社群賦予之權限，應儘可能以您自身方便為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月6日 (四) 00:11 (UTC)[回覆]

提供的IP問題

現在有個問題

  • 如果申請者沒有使用代理時使用此網站提交工單，被此網站自動帶入的IP是其真實IP，而非使用代理且受到IP封禁的IP，對於IPBEG應該使用真實IP還是受到封禁的IP判斷？如果有人使用代理訪問此網站，有人不使用代理訪問此網站，也會產生差異。
  • 是否像傳統郵件列表一樣另外要求用戶手動填入封禁界面上顯示的受封禁的IP或封禁ID？這樣也有好處，就是IPBEG可以看到申請者被封禁IP同時也能看到真實IP，確定申請者處於中國大陸等受限地區。但產生另外一個風險，就是如果確實提供的是中國大陸IP位址，一旦泄露可能產生嚴重後果。--桐生ここ★[討論] 2024年6月6日 (四) 10:00 (UTC)[回覆]
    • 技術上有很多方法可以儘量避免記錄IP，比如只記錄部分IP、以及對管理員不顯示IP，只顯示IP是否處於封禁列表中。但是這些方法無一例外的會對管理員處理造成問題。我想到的各種方法中，只有一個值得實踐的，是在工單解決之後將IP相關信息從工單中清除，避免永久留存。除此之外，就只有請管理員和IPBEG不要泄露IP位址。對於代理的問題，我可以加一個提示讓用戶記得開代理，再者就是乾脆取消自動偵測IP這個功能，讓用戶自己填寫IP和查封ID，和郵件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)[回覆]
      我有一個方案
      • 申請者不提供IP：不提交IP
      • 申請者選擇提供IP：檢測IP是否中國大陸或其他受限地區
        • 是：不提交IP位址，只自動提交申請者IP地區，並且要求申請者手動填寫受封禁IP
        • 否：自動帶入IP位址
      --桐生ここ★[討論] 2024年6月7日 (五) 09:10 (UTC)[回覆]
      補充：IP地區是提交由服務端判斷，而不是在前端處理，所以實際上仍然會提交中國大陸IP，只是不會儲存在伺服器上。--桐生ここ★[討論] 2024年6月7日 (五) 09:13 (UTC)[回覆]
      檢測IP是否中國大陸或其他受限地區 這個感覺不是長久之計，GFW未來可能會給Unblock-zh上SNI封鎖，用戶會不得不套代理訪問，這樣Unblock-zh獲取到的就不是真實IP--Yuki Rutygr (留言) 2024年7月9日 (二) 13:15 (UTC)[回覆]
      • 我想過geoip定位這個方案，但是ip定位數據庫需要每個月更新，而且並不完全準確。連維基媒體基金會都放棄了自己的geoip API（否則我就可以利用了）。有一個折衷辦法，那就是查詢封禁數據庫。如果用戶目前的IP不再封禁列表中，大概率說明沒有開代理，此時我彈窗提示開代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)[回覆]

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

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

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

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

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

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

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

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

一併回覆Ericliu1912及桐生ここ：……（討論已移動至下方）--路西法人 2024年6月13日 (四) 22:36 (UTC)[回覆]
(－)強烈反對：
  1. 仲裁委員會機制尚未驗證，其實際效果和操作過程尚不明確。為了一個尚未驗證的機制，而凍結現行的有效程序（顯然不會因行政員爭議性的終止等同無效），無異於捨本逐末。關於仲裁委員會在管理人員解任中的角色，在下同@桐生ここ：目前的問卷問題存在明顯的不足。問卷沒有明確說明是所有RFDA按上述甲、乙、丙方案處理，還是僅有爭議無法在社群解決的RFDA案件按上述方案處理。此種不明確性導致問卷結果不能充分反映社群的真實意見。
  2. 考慮到仲裁委員會的設立、仲裁員選舉、立案時長分析、條文討論等過程顯而易見地非常冗長，凍結現行程序更有阻撓現行政策正常運作，即時處理當事管理員問題之嫌。應按照現行規則即時的處理管理員問題，確保社群的正常運作，不受爭議管理員可能之危害。
  3. 最後，在下堅決反對行政員可能在任意時間決定凍結RFDA程序的行動。此種爭議做法在前次已經引發「官官相衛」「未得社群共識」「違反官僚體系」等嚴重質疑，損害社群討論之原則。甚至換句話說，如果仲裁委員會一日不建立，便一日不能追究、及時處理管理員之問題，顯然干擾社群監察程序。綜上，在下反對凍結。並建議直接滾雪球關閉此討論。--Gluo88（留言） 2024年6月13日 (四) 20:18 (UTC)[回覆]
@LuciferianThomas：還請動議人在此處說明一下仲裁委員會相關事宜的進度。假如進度推進得足夠快的話，凍結程序並不一定必要。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 23:13 (UTC)[回覆]
目前尚餘總結解任相關觀點，並設計出符合儘量多人意願的解任相關機制後，就能寫整個方針，經過社群公投endorse後上路。
就算進度推進得夠快，也無法阻擋當前Gluo88公然發表違反解任程序要求的提案，在修訂社群解任途徑確保程序公義前或仲委會機制上路前，仍應凍結當前程序。--路西法人 2024年6月13日 (四) 23:31 (UTC)[回覆]
(！)意見-將這兩件事情連結起來成為條件，恐怕有疑慮，是否要開這樣的先例？恐怕會帶來些副作用與後遺症。會否讓既有方針被凍結了？過去，沒有仲裁委員會，相關的程序與方針仍然持續進行，就是依照既有方針在做。Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 00:21 (UTC)[回覆]
實際上早有先例。過往就是本地用戶查核權出了問題，使基金會凍結本地用戶查核權。另外，請注意提案中除了「凍結到有仲裁委員會成立」外，還有「或（凍結至）按照調查得出大家的主流觀點」（或如某些人否定調查得出的多數意見，也需確保程序公義得到彰顯）的選項。--路西法人 2024年6月14日 (五) 02:09 (UTC)[回覆]
社群提出與仲裁委員會調查管道實際上仍應並行，這裏討論的祇有前者。因為很顯然，仲裁委員會祇能處理於該處提出告訴的案件，不能為整個社群越俎代庖。但我有點擔心，新提案在加入仲裁委員會角色同時，還打算一併消滅社群自行提出管道。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 00:33 (UTC)[回覆]

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

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

當前解任案效力

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

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

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

仲裁體系下的解任機制

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

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

臨時暫停特權機制

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

我準備提出一個關於暫時取消系統管理員的提案，當系統管理員、監督員或檢查用戶正在接受調查時，Arbcom可能需要暫時取消他們的權限，以防止在必要時造成進一步的干擾。除非調查結束，否則不得再次獲得。特別是對於 VRT 和簽署了保密協議的人，維基媒體基金會需要注意是否有必要取消這種權限。我有點累了，但祝你好運，上帝保佑你。---Lemonaka 2024年6月14日 (五) 13:08 (UTC)[回覆]

@Ericliu1912 @LuciferianThomas -Lemonaka 2024年6月14日 (五) 13:11 (UTC)[回覆]
仲裁委員會大概可以視情況決定是否技術上暫時取締管理員行使權限。不過本地相較於英文維基百科，尚沒有直接取消管理員系統操作權之權力，本人認為這代表兩地社群習慣差異，故制度移植時亦應有本地化措施以為反映（例如縮減可取締權限之案件種類等）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 13:15 (UTC)[回覆]
我覺得可以提出緊急凍結機制，類似緊急除權，比方說監督員、界面管理員等重要權限，正在調查期間社群或行政員認為必須先除權以保證安全，則先除權，等待調查結果再恢復或維持除權。--桐生ここ★[討論] 2024年6月14日 (五) 13:21 (UTC)[回覆]
重點在於「無罪推定」（雖然應該少援用司法概念）。除上述情況外，本人認為唯有涉及管理權限行使可能損及當事人權利，或妨礙案件之進行，或有正當合理之依據認為案件進行中不適宜持有權限者，方得暫時除權。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 13:40 (UTC)[回覆]
這有個問題是誰來判定會比較好，Arbcom判定社群會有人不認同，社群自己來討論要不要暫時除權又會因為爭執而不了了之，一個很尷尬的情況。--~~Sid~~ 2024年6月17日 (一) 09:08 (UTC)[回覆]
Sid說的有道理。仲裁委員會只是是少數人的決定，社群大多數人的共識才具有公信力。--桐生ここ★[討論] 2024年6月22日 (六) 08:17 (UTC)[回覆]
這種觀點我真的不認同。仲裁委員會是社群選出來的，細節是由社群敲定的，最終的提案也是要由社群通過的。在這樣的程序下，仲裁委員會的決定必須具有公信力。如果說決定不具有公信力那麼要仲裁委員會幹什麼？
我選擇甲的原因也同理。如果委員會需要調查再由社群討論，那搞選舉、審議這些程序完全沒用。完全可以找幾個看起來社群信得過的人，組成一個「非官方」的委員會，也可以調查。
再往普通解決行為爭議來看，即使無法除權管理員，委員會一定需要有封禁，設置編輯禁制的能力。設置委員會就是為了一個「最終解決方案」。如果例如ANM上面的案子十分棘手，以至於沒有管理員願意去處理，那麼就去找委員會。委員會基於社群方針來判斷事務是否使用管理工具來處理，而不創建新的方針。如果說委員會在處理普通用戶爭議的時候也要「推薦」管理員如何處理，實則無權的話，那這個委員會不要也罷。--0xDeadbeef (留言) 2024年6月25日 (二) 11:54 (UTC)[回覆]
說到底我懷疑社群能否選出這麼一個委員會。--桐生ここ★[討論] 2024年6月25日 (二) 13:33 (UTC)[回覆]
我保持樂觀，但我的想法是，與其將委員會的權力一砍再砍，就為了社群能夠選出一批人，結果選出來也不能改變社群生態，不如保留委員會權力，社群在知情委員會權力的情況下選，選出則能對社群環境有一定的影響力，選不出就當失敗。--0xDeadbeef (留言) 2024年6月25日 (二) 17:39 (UTC)[回覆]
@0xDeadbeef What about A/B group? They can scrutinize each other. -Lemonaka 2024年6月26日 (三) 03:46 (UTC)[回覆]
Not sure how well that will work in practice, but maybe worth a try if people want to.--0xDeadbeef (留言) 2024年6月26日 (三) 07:31 (UTC)[回覆]
無論是ArbCom還是社群討論處理，我認為可以先討論當Arbcom決議有人不認同時社群要怎麼解決，當社群討論發生爭執導致討論不了了之時怎麼解決，這是可以預想到的情況。
我很不希望到時候社群不接受仲裁委員會的決議，又嚷嚷着要罷免仲裁委員會，那是非常難看的情況。--~~Sid~~ 2024年6月30日 (日) 09:51 (UTC)[回覆]
問題是這個「選的門檻」、「敲定的細節」，過程及結果是否合理？不少人有疑慮。既然並非如英文那邊當年由威爾斯「君權神授」，本人認為本地仲裁委員會的權威是要經由實際裁決確立，不是伊始就賦予莫大權限。尤其涉及直接處理管理權限者，應不必屬於首屆就奉送委員會的工具。目前本站與監管員等全域社群合作無間，本人雖一貫主張社群拿回應有之自治權，但現階段也未見到由仲裁委員會接掌彼等緊急處置權限的必要。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 05:30 (UTC)[回覆]
那你覺得仲裁委員會是來幹什麼的呢？早就有人使用「沒必要」這個理由來否認各種事情，我對此的回應是，確實，WP:CHOICE也說了，編輯維基百科也沒必要。你當維基百科管理員有必要嗎？那為什麼還有人編輯百科，為什麼你還要當維基百科管理員呢？
我知道我在委員會是否應該有權力去除管理員這個討論中持少數觀點，所以我也不想繼續陳述我的觀點。你說循序漸進我無所謂，要是能夠通過實際判決歷史來讓社群更信任委員會是好事，但是我其實想強調的是剛開始ArbCom也至少應當擁有設立禁制及設高風險主題的權力。如果選出來的委員會沒有辦法實現決議出來的結果那就非常無能。就和WP:NAC不能關閉為刪除一樣。--0xDeadbeef (留言) 2024年6月26日 (三) 07:07 (UTC)[回覆]
據我所知，仲裁委員會職能到現在都沒有確定。具體而言，目前高風險主題在客棧提案模式運作良好（除了法輪功本來爭議較多），對於本站來說高風險主題本來就是個低層級議題，確實不用仲委會插手。另外，我不確定你是想要仲委會有權下達什麼形式的禁制，但大部分情況應該都沒問題，因為社群至少有共識賦予仲委會某種裁決封鎖操作之權，這自然也就包含禁制。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 08:19 (UTC)[回覆]
那就好。--0xDeadbeef (留言) 2024年6月26日 (三) 12:06 (UTC)[回覆]
我是認為高風險主題作為編輯限制的一種，可以作為仲委會的爭議解決手段之一（跟禁制權相似），但絕對不會覆蓋社群本身訂立高風險主題的權力。目前CTOP下，社群經共識實施的編輯限制只能由社群經共識解除，而不能由任何管理員自行解除；仲委會的則可有相似機制，仲委會的高風險主題限制（不論是設定新的高風險主題或是編輯限制）都只能由仲委會或極廣泛共識（30人80%支持？）解除，仲委會也可基於方針及其原則解除社群共識訂立的編輯限制（不過只能是回應申訴）。--路西法人 2024年6月27日 (四) 03:20 (UTC)[回覆]
本人亦認為仲委會有權在必要時自行提出高風險主題，為其執行手段之一。當然，社群對此當有覆核權，其門檻應與經一般社群管道（客棧）制定者相同。相對而言，仲委會祇能被動決定解除已無需求之高風險主題，而不應主動介入（這應該與閣下觀點相同）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月27日 (四) 04:16 (UTC)[回覆]
@桐生ここ What? Arbcom are elected by the whole community, unless the community consensus is hijacked by a small group of users, the arb will be reviewed as the representative of the whole community. Why will they become the minor? -Lemonaka 2024年6月26日 (三) 03:48 (UTC)[回覆]
問題是爭議發生當下，當事人們是否認同委員會是他們選舉出來的嗎？而且事實上仲裁委員會的決定是有限數量的委員們達成的共識，而社群可以組成共識的人數是無限的。--桐生ここ★[討論] 2024年6月27日 (四) 02:38 (UTC)[回覆]
不認同也得認同。就像如果我進行擾亂維基百科，遊戲維基百科的事情的話，有管理員要封禁我，我是不是說「我不認同你是被社群選舉出來的管理員，你的決議不是社群共識，請在社群中形成共識再封禁我」就可以有免死金牌了？--0xDeadbeef (留言) 2024年6月27日 (四) 02:49 (UTC)[回覆]
管理員是執行共識，仲裁委員會是沒有共識的情況下製造一個「共識」，還是有點不一樣。--桐生ここ★[討論] 2024年7月1日 (一) 19:52 (UTC)[回覆]
在什麼情況下仲裁委員會是在沒有共識的情況下製造一個共識，而不是執行共識？--0xDeadbeef (留言) 2024年7月2日 (二) 03:25 (UTC)[回覆]
其實若仲裁委員會按方針與指引精神裁定，那本質上與管理員行使自由裁量權意涵相同，都是執行社群共識。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 04:21 (UTC)[回覆]
有幾種民主解方：一種是社群以足夠高門檻另行達成有效共識，推翻仲裁委員會決議；另一（兩）種是經罷免或次屆選舉移除若干社群認為不適任之委員。社群可以決定是否兩（三）種解方並行，或祇允許其中幾種。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月1日 (一) 19:47 (UTC)[回覆]
初期仲裁委員會或本地行政員都還沒有權限可以自行取消管理員權限，這個或許要到未來屆數的仲委會選舉前再解決。目前狀態下，僅有「可能需要緊急除權」、「（發佈報告後）已經確認符合解任發起條件，等候社群投票重新確認管理員權限」兩個情況是適合直接凍結權限。
雖然目前尚無技術手段直接凍結管理員權限，仲委會仍可通過審議施行禁制權，臨時禁制當事人使用任何管理人員權限，違者亦可直接視作嚴重違規而符合除權條件即可。
不過如果是「凍結權限」，那麼就不是「解任投票」而是「重新確認投票」，重新確認投票的通過標準（此處指支持留任比率）或許要提高；反過來解任投票的通過標準（此處指支持解任比率）也需因應略微提高（例如55%）。--路西法人 2024年6月15日 (六) 00:56 (UTC)[回覆]
How can you 「凍結」(maybe temporarily stop) VRT priviledge without removing them? What about Oversight? -Lemonaka 2024年6月15日 (六) 02:22 (UTC)[回覆]
基本上都是需要通過暫時除權處理。使用行政手段如禁制也是可以等同凍結權限，違者即直接除權即可。--路西法人 2024年6月15日 (六) 03:15 (UTC)[回覆]

機要原則

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

以ARBCOM目前享有的特權來看，ARBCOM的成員在任職前應該簽署或者需要簽署保密協議，結果就是幾乎所有來自中國大陸的成員都被排除在外，他​​們可能根本不信任這個團體。然而，維基百科是基於共識運作的，如果將整個子群體排除在共識之外，可能會使其難以正常運作。---Lemonaka 2024年7月9日 (二) 01:34 (UTC)[回覆]

這也是沒辦法的事，2021年時WMF好像已經有不承認中國大陸人士簽署的保密協議的做法，這不是中文維基百科的裁量範圍。Sanmosa 蚌埠 2024年7月9日 (二) 05:18 (UTC)[回覆]
否。我記得過往討論中是安排照樣容許無法簽署保密協議的用戶參選，而在必須有前保密協議才能接觸的證據的情況下設subcommittee處理有關證據或案件。--路西法人 2024年7月9日 (二) 06:42 (UTC)[回覆]
我的理解是他是在表述他認為所有ArbCom成員都應該需要簽署保密協議的個人意見，而不是在表述過往討論的結論。Sanmosa 蚌埠 2024年7月9日 (二) 22:47 (UTC)[回覆]
我沒有說他正在表述過往討論。你無法好好閱讀、理解我的留言，並屢次超譯我發言的行為已經嚴重造成我的困擾，請你停止。--路西法人 2024年7月10日 (三) 01:52 (UTC)[回覆]
我好像也沒表達出你説的這個意思？真正在超譯的人是你吧？Sanmosa 蚌埠 2024年7月13日 (六) 01:23 (UTC)[回覆]
@LuciferianThomas@SanmosaPlease focus on the topic, ARBCOM members are responsible for on and off-wiki invesitgation, including evidence regarding privacy, how can users send these information to the Arbcom members who never sign NDA?
請關注主題，ARBCOM 成員負責維基內外調查，包括有關私隱的證據，用戶如何將這些信息發送給從未簽署保密協議的 Arbcom 成員？ -Lemonaka 2024年7月15日 (一) 01:30 (UTC)[回覆]
subcommittee，小組委員會，即僅有部分成員參與的調查。簡而言之：不涉及私隱證據的案件可由所有仲裁員參與，涉及私隱證據的案件僅可由已簽署NDA的仲裁員參與（未簽署NDA的仲裁員recuse）。--路西法人 2024年7月15日 (一) 01:44 (UTC)[回覆]
[來源請求]? -Lemonaka 2024年7月11日 (四) 03:17 (UTC)[回覆]
Wikipedia_talk:仲裁委員會#保密協議及處理涉及私隱證據案件之職務、#公示RFC結果及仲裁方針草案。--路西法人 2024年7月11日 (四) 03:38 (UTC)[回覆]
可儘量細分仲委會行使職權，最敏感部分纔考慮保密協議為必要條件。具體之執行，應以個案為基準，確定證據是否涉及私隱，再行規劃。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月9日 (二) 16:16 (UTC)[回覆]

新用戶通過撰寫新條目的方式「完成學科作業」的處理討論

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

近日巡查當中發現疑似存在新用戶通過撰寫新條目的方式「完成學科作業」，目前主要涉及兩位用戶U:JINJINYAN和U:ZixuanHE以及其創建的四篇條目，見人權史（Draft:人權史）、中朝關係史（Draft:中朝關係史）、Draft:修理權、Draft:性別薪酬差距（目前的處理為：已全部轉移至草稿空間，部分被繞過草稿空間重新發佈的條目已提報存廢討論）。四篇條目均為機翻或者潦草翻譯，且未進行維基化。據ZixuanHE所述，這些條目的創建疑似為「學科作業」，且必須發佈才有可能拿到「節課的成績」（見UT:ZixuanHE#閣下所創建條目已被移動至草稿）。

鑑於此類行為為顯然帶有傾向性或非百科編輯性動機的條目創建行為（可能不符合但類似於維基百科:有償編輯方針），故提出此話題以尋求如何處理該類問題。--Sinet（討論） 2024年6月14日 (五) 08:43 (UTC)[回覆]

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

設立教育佈告板

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

Ping一下相關用戶@Flyinet、SheltonMartin、RiceKing、Leiem、SCP-2000、MilkyDefer、Hanyangprofessor2、ATannedBurger、桃花影落飞神剑、ASid、HYHJKJYUJYTTY：--人間百態,獨尊變態(討論) 2024年6月22日 (六) 11:12 (UTC)[回覆]

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

討論頁話題自動索引

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

支持這個initiative（雖説這在WP:CON/TRIAL的提議出現前就該出現了）。Sanmosa 蚌埠 2024年7月6日 (六) 13:53 (UTC)[回覆]
挺好的，不過我也發現了點問題，但恐怕並不容易修復：
  1. 有些討論已經結束（比如，編輯請求解決了），卻仍會出現在此索引上，導致其十分冗長
  2. 有些討論發起時間比較早，或討論較長時間都沒有人回應，就不會出現在此索引上；這可能並不利於問題的解決/共識的形成
--古怪的Wang31（討論 | 貢獻） 2024年7月7日 (日) 13:09 (UTC)[回覆]
聊勝於無，有問題可以之後慢慢改善。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月7日 (日) 15:35 (UTC)[回覆]
  1. 現在仍然在初步測試階段，未來將參考Cewbot，將已經結束（已有Archive框模板）的討論以另一種方式標記；其餘標籤如已解決之編輯請求、移動請求等亦可納入考量。此部分還請社群協助列舉。
  2. 目前機械人設計為每次都搜索最近14天的RC來弄這個列表，未來或許會以暫存方式優化；但起始搜索RC也最多只能到30天，而14天的討論串數量已貼近400大關，可以想像起始數據需要索引蠻久的（以防轟炸資料庫）。不是做不了，但最多也只能做30天，但也還是會多串到用戶難以索引不再有效的地步。另一個方法是恢復{{indiscussion}}模板以防拖延時間過長討論不被索引，這又是另一個需要社群去討論的議題。
--路西法人 2024年7月7日 (日) 15:51 (UTC)[回覆]
其實很多討論就沒有結束，或即使結束了也未必有任何標記來表示已結束。我認為話題索引只索引最多30天內有進行討論的就好了，30天都沒人參與的討論那就是暫時沒人在意或沒能力參與，或者討論頁的留言就只是對條目內容的一個註記，沒有討論必要。討論頁話題自動索引最大的意義是讓人能夠了解和檢索近期發生在討論頁的所有討論，以期達到能夠有更多人關注參與討論的目的--百無一用是書生 (☎) 2024年7月8日 (一) 02:45 (UTC)[回覆]
目前確實其實是沒什麼大問題的，我提的只是算是一點細枝末節的問題，得不出結論也無傷大雅。
  1. 討論結束的，通過一些模板標記可以排除；當然，這對機械人在技術上的設計要求就會比較高。要是總體上沒有特別多活躍討論，直接忽略其實也問題不大
  2. 沒解決但沒人回復的討論，確實是個比較矛盾的問題。無限索引就的討論無論從技術上還是價值上肯定都是不太現實的，還是要考慮是否需要一種「標記」。一方面，就讓這些討論不了了之，感覺也不太好，尤其一些爭議要是總是不解決，可能容易產生積患；另一方面，如果真的把所有「未結束」的討論都列出來，卻沒人想去討論，那仍然會讓索引變得越來越長，失去意義。（突然想到，這個問題其實也可以類比存廢討論的積壓討論的存在，關鍵在於討論的問題到底重不重要）
    我也給個我的建議，可以考慮先恢復{{indiscussion}}（我不清楚模板具體內容，總之是恢復或創建一種標識「此處有討論正在進行」的模板），試用一段時間，要是積壓的討論越來越多，就還是用按日期索引的方案。
--古怪的Wang31（討論 | 貢獻） 2024年7月9日 (二) 14:37 (UTC)[回覆]

私自發佈（懷疑自我原創）英國官員譯名

參見：Talk:施紀賢 § Victoria Starmer之譯名

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

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

@Yuyu：若此類編輯沒有可靠來源佐證，均可逕予回退。也請多注意違規使用者，並協助通知提報。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月7日 (日) 12:05 (UTC)[回覆]
我最多已經回退多一次，但上面的ip依然活躍發佈其幻想，你們看看要不要處置一下？--JéRRy ~ 雨雨 （留言） 2024年7月7日 (日) 13:37 (UTC)[回覆]
@Yuyu、Ericliu1912：還有這位@Jimmy HCH：在阿克莎塔·穆爾蒂的編輯（Special:Diff/79839604），於2023年11月22日發佈。然而使用谷歌搜尋香港譯名「麥雅賢」發現關於她的新聞都是在2024年的，也有維基百科譯名循環引用的可能。--The3moboi（留言） 2024年7月7日 (日) 14:58 (UTC)[回覆]
也有可能是香港方面2024年新增的。不過也要看看使用量，若香港方面也不怎麼用該譯名應移除。--微腫頭龍（留言） 2024年7月8日 (一) 03:32 (UTC)[回覆]
以英國首相配偶為例，馬卓安的夫人，一直看各種文件都沒見過「莊樂敏」這個名字，搜google 幾乎全都是維基百科。其他名字，除了「彭雪玲」有印象被廣泛報導，其他基本上都出處不明。當然，一票子人還在瘋狂維護。--JéRRy ~ 雨雨 （留言） 2024年7月8日 (一) 09:10 (UTC)[回覆]
不好意思，該譯名的確是還沒有正式來源，不應回退你的。--Mykola（留言） 2024年7月8日 (一) 10:10 (UTC)[回覆]
現在不吵甚麼善意了嗎？--JéRRy ~ 雨雨 （留言） 2024年7月8日 (一) 13:48 (UTC)[回覆]
嗯，是我誤解了。--Mykola（留言） 2024年7月8日 (一) 13:54 (UTC)[回覆]
嘗試搜索了幾個，並沒有搜到來源。--傑里毛斯（留言） 2024年7月8日 (一) 10:39 (UTC)[回覆]
還在有人說「杜安妮」是Anneliese Dodds 的官譯，還說星島01可以作數。之前不是他們信誓旦旦說 David Lammy 是「林偉德」嗎，現在是甚麼樣子？留着你們自己鬧騰吧--JéRRy ~ 雨雨 （留言） 2024年7月10日 (三) 13:32 (UTC)[回覆]

設立編者著作權調查

鑑於最近本人發現有些許編輯持續侵犯著作權的情況，為了記錄並核實侵權情況是否屬實，與此同時可協作處理並查刪確實存在侵權情況的內容，認為應將英維的en:WP:CCI搬過來，不知各位有何意見。以下是我的一些想法：

  • 任何編者被發現有5個實際侵權的情況後可以開啟著作權調查案件。
  • 英維有設定調查助理，而限制只能管理員或助理查核侵權屬實才可開啟調查。個人看法是可以先不需要助理或管理員把關，僅需任意第三方查核證明侵權屬實即可。
  • 可運行ContributionSurveyor.java開啟調查並列出所有需要檢查的編輯。例
  • 調查開啟後，使用、、?標註是否為侵權。侵權文本應當被刪除，如需WP:RD也應提刪。

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

不反對，但硬性指標建議是暫定、靈活的。按英文說法，着眼於長期的侵權。不清楚怎麼算5個，比如5個條目，5個修訂版本或5個章節等。任意可能太過寬鬆而浪費調查資源，至少一或兩名延伸確認用戶？--YFdyh000（留言） 2024年7月7日 (日) 17:05 (UTC)[回覆]
可暫定一名延伸確認用戶吧。5個在英維是instances，算是較模糊，我認為是5個修訂版本，但至少應有一些證據證明非單一侵權（多個條目均有）--0xDeadbeef (留言) 2024年7月7日 (日) 17:41 (UTC)[回覆]
如果有志工自願協助，似乎也不妨礙。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月8日 (一) 07:33 (UTC)[回覆]
我已試着在自己用戶空間暫時記錄我對於HYHJKJYUJYTTY侵權的查核以及處理，見User:0xDeadbeef/CCI/HYHJKJYUJYTTY。如有人想幫忙可以安裝我搬過來的Deputy腳本--0xDeadbeef (留言) 2024年7月8日 (一) 08:31 (UTC)[回覆]
不反對，不過不知道會有多少人參與。--冥王歐西里斯（留言） 2024年7月9日 (二) 05:27 (UTC)[回覆]
我只想說人手不夠：（
要設立的話流程請從簡不要太複雜。--~~Sid~~ 2024年7月9日 (二) 14:08 (UTC)[回覆]
不反對，這個東西貌似還不錯。--桐生ここ★[討論] 2024年7月14日 (日) 09:54 (UTC)[回覆]

關於IPBE申請的問題

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:IP封鎖豁免權授予者、Wikipedia talk:IP封禁豁免。

哈囉大家好，我是IPBEG，我想就以下幾個問題請社群討論，給予我們明確的共識，這個是我個人發起的討論，並沒有與其他授予者討論，希望大家盡量參予。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回覆]

不強迫備案WP:RFR/IPBE

目前的情況是都會備案到權限申請，我希望可以不強迫，應該說不知道從何時開始有了慣例會備案至權限申請，事實上日誌都寫得很清楚，這個備案會讓我們多一個步驟，備案時所描述的內容事實上並沒有提供到多大的幫助，郵件列表只有訂閱相關郵件列表的人才能查詢。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回覆]

授權標準

目前基本上都是授予永久權限，各位應該有注意到我授權會經常授予臨時權限，這是因為有人反映說授權過於寬鬆，所以我希望可以針對這一部分進行討論，在不使處理變繁雜的情況下，兼顧標準的部分。有關於這一部分我是希望本地恢復CU，交由CU來定期隨機查核使用者是否確實有需要用到IPBE，不是授予者與管理員們提高標準，即便提高也無法防止有意騙取IPBE的使用者。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回覆]

我理解有一些人可能會覺得這個討論有點多餘，然而我的目的是在於確保社群有一定的共識，不會單方面變更後有人跳出來說，你怎麼這麼做你應該這麼做：​（--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回覆]

稍微解釋一下為什麼是永久權限。曾經首次授權一般都是臨時權限的，但是後來發現沒有太多意義。基本上所有到期之後還想要繼續編輯的都會申請續期，這裏也沒有太多可以審查的東西，基本上遇到申請都會轉成永久權限。所以沒有續期的那些，也就是沒有實際編輯，到了時間就忘了的人。這部分人的除權，現在由機械人自動執行。所以永久權限和首次的臨時權限本質上區別也就不大了，而且還減少處理的負擔。這部分是有過討論的，找一下的話應該是可以找到討論的。--Tiger（留言） 2024年7月9日 (二) 14:45 (UTC)[回覆]
感謝Tiger。--~~Sid~~ 2024年7月10日 (三) 06:46 (UTC)[回覆]

BlackShadowG

同 LuciferianThomas 君，且個人早已聯絡 emergency@。考慮到無後續討論的需要，故關閉之。祝願她平安無事。--SCP-0000（留言） 2024年7月11日 (四) 03:53 (UTC)[回覆]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

Can anyone get in touch with BlackShadowG（討論 | 貢獻）? It has been 10 days since their last announcement of committing suicide. I'm quite worried about them.
Google. 有人能聯繫到 BlackShadowG（討論 | 貢獻） 嗎？距離他上次宣佈自殺已經過去了 10 天。我相當擔心他。 -Lemonaka 2024年7月10日 (三) 08:39 (UTC)[回覆]

如有必要，應發件至emergency@ 請求協助，在這裏公佈似乎沒有用。反正無法證明的死訊也不應掛模板。--路西法人 2024年7月11日 (四) 03:41 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

查詢meta:List_of_globally_banned_users時發現，影武者已於7月9日被列入基金會全域禁制（WMF Ban）名單中。--Itcfangye（留言） 2024年7月12日 (五) 11:28 (UTC)[回覆]

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