跳转到内容

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

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

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

按此刷新頁面。

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

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

查看全部討論

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

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

消息

Wikidata weekly summary #633

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

Events

  • Past: The 200th online Wikidata meetup in Swedish was held.
  • Upcoming: Lexicodays, online event dedicated to Lexemes on Wikidata, will take place on June 28-30. It takes place across time zone and both in English and Indonesian. Check the program and find the access links on the event page.

Press, articles, blog posts, videos

Tool of the week

  • Wikidata in Prometheus - Prometheus is a non-commercial image archive for art and cultural studies. It hosts images from a variety of image and media databases and now works can be connected with Wikidata.
  • New Mix'n'match feature: For lists of (full or auto) matches where both the MnM entry and the Wikidata Item have coordinates, it now shows the distance between them in the description. (source)

Other Noteworthy Stuff

  • The Wikidata development team at Wikimedia Deutschland is planning a brief survey to understand the various ways people contribute to the project and identify user contribution patterns. A request has been made for a CentralNotice banner to deploy the survey to a broad audience. Your feedback, comments, and questions on this request are welcome: m:CentralNotice/Request/Wikidata Community Survey 2024
  • The second iteration of the Wikidata:Open Online Course will begin from July 1 until August 11. Whether you're a beginner taking your first steps, an individual in need of a refresher on Wikidata concepts, or a seasoned trainer looking to level up your skills - this course is right for you.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • [Breaking Change Announcement] Upcoming Changes to Wikibase: EntitySchema data type
  • EntitySchemas: We prepared for the release of the new data type to link to EntitySchemas in statements on July 2nd.
  • Mul language code: We picked up the remaining issues before enabling it by default on Wikidata
  • Wikibase REST API:

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

· Unsubscribe · Help translate · Mohammed Abdulai (WMDE) (留言) 16:50, 24 June 2024 (UTC)

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

批准維基媒體運動憲章的投票現已開放 – 請投下您的一票

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

大家好，

批准 維基媒體運動憲章 的投票現已開放。維基媒體運動憲章是一份定義維基媒體運動所有成員和實體的角色和責任的文件，包括創建一個新的機構——全球理事會（Global Council）——來進行維基媒體運動的治理。

維基媒體運動憲章的最終版本在元維基上以不同語言提供。

投票將於2024 年 6 月 25 日 00:01（世界協調時間）在安全投票上開始，並將於2024 年 7 月 9 日 23:59（世界協調時間）結束。請閱讀有關選民資訊和投票資格的詳細資訊。

閱讀維基媒體運動憲章後，請投票並進一步向您的社群分享此資訊。

如果您對批准投票有任何疑問，請聯絡維基媒體運動憲章選舉委員會 [email protected]。

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

RamzyM (WMF) 2024年6月25日 (二) 10:52 (UTC)[回复]

投票地址错了，正确应该是Special:安全投票/vote/403--百無一用是書生 (☎) 2024年6月26日 (三) 03:01 (UTC)[回复]

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

方針

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

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

--唔好阻住我愛國（留言） 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)[回复]

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

--唔好阻住我愛國（留言） 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)[回复]

集中討論！--唔好阻住我愛國（留言） 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)[回复]
@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)[回复]

关于国籍的原创研究

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

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

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

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

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

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

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

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

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

是次討論重點如下：

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

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

討論內容如下：

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

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

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

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

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

5.只有正式譯名。

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

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

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

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

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

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

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

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

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

問題就來了：

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

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

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

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

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

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

意见：

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

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

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

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

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

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

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

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

現行條文

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

提議條文

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

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

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

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

提議條文

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

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

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

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

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

只更改定義並新增：

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

概念：

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

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

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

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

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

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

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

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

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

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

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

2.

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

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

提議條文

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

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

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

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

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

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

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


公示版本

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

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

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

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

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

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

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

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

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

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

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

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

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

下方段落沒有任何更改

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

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

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

建議從「譯名決定辦法」至文末的條文如下：
譯名決定辦法
條目命名爭議的解決
  • 若對條目名稱有異議，需於條目討論頁提出討論。
  • 若各地最合適譯名不同，香港、澳門、臺灣譯名應使用繁體中文，中國大陸、馬來西亞、新加坡譯名則應使用簡體中文。
已述必要更動不再贅述，説明其他順便的更動：
  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)[回复]
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)[回复]

過濾器創建方針討論

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:防滥用过滤器。

不通過
提案人誤解模板編輯員職能，此話題沒有實際意義。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 02:55 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
現行條文

防濫用過濾器是一個可以針對所有最近編輯動作進行自動化判斷的軟件系統。管理員可以針對特定的用戶行為設定過濾器，過濾器被觸發時可進行特定的操作。

提議條文

防濫用過濾器是一個可以針對所有最近編輯動作進行自動化判斷的軟件系統。管理員及模板編輯員可以針對特定的用戶行為設定過濾器，過濾器被觸發時可進行特定的操作。

這種改善制度不僅能夠加快編寫過濾器的效率，而且有更多人可以修正維基百科:互助客棧/方針#必須防止濫用「防濫用過濾器」的問題。--WiiUf ——青龍出世，傲視蒼穹 2024年6月7日 (五) 04:14 (UTC)[回复]

你对过滤器的能力认知不足啊。过滤器有能力阻止某一特定使用者的一切编辑，形同封锁。--MilkyDefer 2024年6月7日 (五) 04:26 (UTC)[回复]
不是有过滤器助理吗，怎么扯到模板编辑员。而且增人会增加问题和编辑战，没解决问题。--YFdyh000（留言） 2024年6月7日 (五) 04:34 (UTC)[回复]
要不就單獨設一個過濾器創建員?--WiiUf ——青龍出世，傲視蒼穹 2024年6月7日 (五) 04:47 (UTC)[回复]
不需要，是需要比较明确的流程、参与者和至少两名活跃的管理员。--YFdyh000（留言） 2024年6月7日 (五) 05:23 (UTC)[回复]
好像过滤器不支持根据用户组来控制可以配置的过滤器选项。而且Wikipedia:模板編輯員主要是用来处理高风险模板的编辑，根本不适合用来处理过滤器编辑工作。提案者有没仔细研究这些规则和配套的技术说明？例如前面的Wikipedia:修訂巡查，那东西基金会嫌太笨重了不好用，已经不允许再新开了，相关的权限问题讨论根本没必要。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月7日 (五) 05:46 (UTC)[回复]
看了下提案者的注册时间……嗯~——Sakamotosan路过围观 | 避免做作，免敬 2024年6月7日 (五) 06:01 (UTC)[回复]
不妥，模板編輯員目前和過濾器助理的條件並非完全重疊（當前的條件限制可以讓一個人是模板編輯員但不能申請成為過濾器助理），而且不認為模板編輯員就一定有辦法改防濫用過濾器。--SunAfterRain 2024年6月16日 (日) 13:40 (UTC)[回复]
跟模板編輯員有什麼關係？……--冥王歐西里斯（留言） 2024年6月17日 (一) 03:16 (UTC)[回复]

附加條文

當過濾器被觸發時，模板編輯員可以設定如下操作（大致根據行為的嚴重程度從輕到重排序）：

  • 所有觸發過濾器的行為均會被記錄在特殊頁面的日誌中。（強制，無法取消）
  • 給用戶的操作加上標籤，以便進一步的核查。
  • 用戶收到警告訊息。
  • 用戶的操作被阻止。
  • 用戶的自動確認狀態被隨機取消5天。
  • 封鎖使用者帳號或IP位址（可分別指定期限）。
  • 用戶的所有用戶群組被移除（例如機械人、管理員、回退員等）。（本地未啟用）

—-WiiUf ——青龍出世，傲視蒼穹 2024年6月7日 (五) 04:38 (UTC)[回复]

技术上不能阻止有编辑过滤器权限者设定封禁、取消自动确认等过滤器。而且我也不确定新设立一个权限组是否能有效提升过滤器请求受理活跃度。此外，模板编辑和过滤器无关，过滤器编辑者应该精通正则表达式，而不是模板。--桐生ここ★[讨论] 2024年6月17日 (一) 07:01 (UTC)[回复]
仅仅因为触发过滤器而被处罚，这和文字狱有什么区别呢？（特别是现在的中文维基百科存在一些不合理的过滤器）--Leiem（留言·签名·维基调查） 2024年6月25日 (二) 02:17 (UTC)[回复]
模板編輯員權限與濫用過濾器毫無關聯，此顯係提案人誤解。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 02:55 (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)[回复]

Counterproposal

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

§ 標準措施 §§ 回退限制

現行條文

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

提議條文

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

§ 時長

現行條文

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

提議條文

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

--路西法人 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 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 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)[回复]

提议设立请求封禁机制以及扩大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)[回复]
Wikipedia:管理员布告板/编辑争议和Wikipedia:管理员布告板/其他不当行为已经复杂到我不愿意碰了，再弄这个的话更不会没事去看了....--百無一用是書生 (☎) 2024年6月17日 (一) 02:14 (UTC)[回复]
社群針對此議題是不是討論過不少次了？為什麼我感覺幾個月以前纔有一次。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 12:50 (UTC)[回复]
基本上這種制度是聊勝於無，比起現在的情況肯定是利大於弊。但也要指出，管理員執行封鎖操作時，理論上已經要確定當事人違反本站政策，「独自判断引起争议」可以是對管理員裁量權的事後合理質疑，但不是限制管理員行使封鎖權限的前提。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月14日 (五) 12:52 (UTC)[回复]
支持，帮助明确共识。但裁量权目前还是得有。--YFdyh000（留言） 2024年6月14日 (五) 14:24 (UTC)[回复]
理解提案的用意，樂見其成。但在實踐上可能會如路西法人君所說產生更多問題，或許會造成另一個管理員布告板。明白提案及用戶對管理權運用的憂慮。－千村狐兔（留言） 2024年6月14日 (五) 15:53 (UTC)[回复]
建議統稱「封禁探討」，專門討論用户行為是否足以封禁，因為有些人請求社群告訴他怎麼辦，提報或申訴可以其他渠道發起。 -- 月都 ※ 2024年6月16日 (日) 18:02 (UTC)[回复]
我覺得也應該探討一下為什麼管理員們不願意碰WP:ANMWP:AN3，如果ANM、AN3都不願意碰，再開一個AARV事實上只會讓管理員的事情變更多，我想這某種程度上並沒有解決問題，反而多了另一個問題，再提醒一下管理員也是"志願者"。
社群願意的話亦可探討為什麼管理員越來越不活躍，還有什麼方法吸引管理員回來幫忙掃地，或是另外尋求一條出路解決這個問題。--~~Sid~~ 2024年6月17日 (一) 13:04 (UTC)[回复]
額外補充我並不是要反對提案，只是不希望社群設立之後卻沒有達到預想的效果。--~~Sid~~ 2024年6月17日 (一) 13:05 (UTC)[回复]
以“有共識後再執行封鎖”來處理“管理員獨自判斷”的潛在弊端可能不符比例原則，我更傾向於引入類似助言（日语：助言）的機制，要求管理員在執行不限期封鎖前應先取得至少一位未涉事的第三方用戶的同意，以確保所有不限期封鎖的執行都不違反比例原則。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 13:35 (UTC)[回复]
我認為這個方法可行。--~~Sid~~ 2024年6月18日 (二) 14:59 (UTC)[回复]
少打字，修正留言。~~Sid~~ 2024年6月18日 (二) 15:00 (UTC)[回复]
不合適。破壞者還要助言？說這是明顯例外吧，但又有什麼應該是例外呢？到頭來還是要爭吵。如此官僚主義弊病過重，我想事後複查比事前在那邊極其複雜地商榷認定界線要容易得多。另外我還是要指出，理論上若管理員是依據社群討論通過的方針與指引執行封鎖，就是在確保社群共識得到實踐；故除理據不清之外，通常不能說管理員「未依共識」執行封鎖，至多是對方針與指引認知有爭議。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 17:46 (UTC)[回复]
啊，我忘了提及「非純破壞行為」的前設。Sanmosa 蚌埠 2024年6月19日 (三) 05:47 (UTC)[回复]
支持@Sanmosa的助言机制，这个方法应该可行。--桐生ここ★[讨论] 2024年6月20日 (四) 19:20 (UTC)[回复]
有点怀疑“未涉事的第三方用户”的评判可能出现争议，并可能使部分用户有意避嫌、延后表态（私下抱团沟通）。--YFdyh000（留言） 2024年6月21日 (五) 11:57 (UTC)[回复]
關於「私下抱團溝通」，根據WP:共識，僅建議不應私下討論維基百科相關的事項，個人建議需更改這段的用詞至嚴禁私下討論維基百科相關的事項，並配合利益申報 （如該名編輯者曾在外站討論，則應當「涉事用戶」處理並應主動向社群申報），否則的話也沒有意思。關於最近私下討論的例子，就是路西法人的共識議案，完全將跳過了共識形成過程便產生共識，此不合程序公義。如果之後AARV容許私下抱團溝通，那只好反對。
.
「維基外的討論。我們不鼓勵編者在其他網站、論壇、聊天工具、電子郵件或其他本專案外的地方討論。這些討論在「維基內」決定共識時是不予考慮的，並在它們被揭發後會引發猜疑和不信任情緒。儘管我們需要在維基外討論少數問題以顧及隱私，但絕大多數維基百科相關的事項都應在維基百科上討論，這樣它們將對所有參與者可見。」--唔好阻住我愛國（留言） 2024年6月21日 (五) 12:40 (UTC)[回复]
我覺得與其在客棧提案（現行寫法），不如改置管理員布告板的子布告板（可命名為「管理操作覆核」），集中處理涉及高階權限的使用行為。既有之「其他不當行為」子布告板，則繼續留作解決普通使用者爭議之處。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 01:09 (UTC)[回复]

格式手册/电视 及 电影 新增对语言标注的指引

在英文维基格式手册/电视找到这一方面的规定，但在一些中文维基电视剧、电影条目中，常出现琐碎标注的现象，例如仅用于剧中少量对话的语言也被标注上。

如该电视剧1条目中“粵語（少許）英語（少許）日語（少許）”，（Special:diff/83041147）；该电视剧2条目中“汉语普通话（另有少量英语、日语、法语、意大利语对白）”，（Special:diff/35736053）；该电影1条目中“普通话 英语 俄语 法语（少许）日语（少许）韩语（少许）
印尼语（少许）”（Special:diff/58687249）；该电影2条目中“普通話 英語 粤語 阿拉伯语”，（Special:diff/70222141）；该电影3条目中“ 粤语为主，有少许英语发音”，（Special:diff/78342493）。--桃花影落飞神剑（留言） 2024年6月17日 (一) 16:51 (UTC)[回复]

确实琐碎、含糊、涉原创总结。--YFdyh000（留言） 2024年6月18日 (二) 02:33 (UTC)[回复]
另外，中文維基百科「普通話」標注時常不準，涉嫌抹煞其他（比例更大的）官話，或錯誤翻譯「Mandarin」，實在有必要對「普通話」標注一律要求可靠來源。例如《青春（春）》，在首映前一度在語言一欄只寫「普通話」，依劇情判斷極不合理，可靠公開資料亦非也。--— Gohan 2024年6月18日 (二) 03:16 (UTC)[回复]
至少中国大陆和香港，澳门对华语都是用普通话称呼而台湾的话则是用国语。--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月18日 (二) 11:21 (UTC)[回复]
您是指甚麽，例如是將椒麻堂會的「四川樂山話」改爲「普通話」？此外，Mandarin遠遠不止於標準官話；港澳狀況也有待商榷。--— Gohan 2024年6月18日 (二) 13:30 (UTC)[回复]
指的是一些配音电影和电视剧例如假面骑士极狐（虽然条目内未提及有中国大陆配音但实际上有)有中国大陆配音和台湾配音都用华语的话显然不合适的。-东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月18日 (二) 14:34 (UTC)[回复]
虽然大中华区以外作品的话一般只标注原产地语言。--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月18日 (二) 14:43 (UTC)[回复]
配音版本語言與本話題無關，本話題是關於「語言」項目瑣碎記錄以及如何妥善記錄，此項目不應記錄非原聲版本語言，亦未見有條目瑣碎記錄配音版本保留何種原聲外語臺詞或唱段。配音方或有關發行方宣稱以「國語」配音或「普通話」配音並在配音員章節適當據此標記當然不成問題，需要管制的是因可靠資料只寫「Mandarin」、因自認片中官話或過半對白就是「普通話」或因豆瓣等網聲稱「普通話」而不分青紅皂白地在維基百科「語言」項目上記錄「普通話」的行爲。--— Gohan 2024年6月19日 (三) 02:46 (UTC)[回复]
但是有部分平台的话是没有直接标明语言而是只标注原声和配音（例如爱奇艺的山海情将宁夏当地方言版本视为原声而将普通话视为配音。)--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月19日 (三) 02:59 (UTC)[回复]
顯然對於這種情況，在資訊框「語言」項目依據獨立可靠來源標記原聲語言，在此項目不應標記配音語言。--— Gohan 2024年6月19日 (三) 03:04 (UTC)[回复]
目前只找到了一个文章证明普通话版本为配音。[12]--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月26日 (三) 00:40 (UTC)[回复]

人事任免投票草案

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

原始提案

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

現行條文

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

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

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

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

提議條文

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

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

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

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

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

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

提案2

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

基础条件

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

次要条件

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

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

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

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

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

提案3

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

基础条件

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

次要条件

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

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

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

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

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

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

提案4（準備公示）

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

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

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

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

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

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

電視劇演員名單序列

本主題或以下段落文字，移動自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)[回复]

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

前一段时间我重新看了下著作权验证模板的一些问题（在之前的讨论中提及过，不再重复具体描述），发现到此模板还是只能按全文处理。至于英文版，这个模板已经于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)[回复]

其他

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

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

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

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

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

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

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

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

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

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

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

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

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

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

为什么“撤销自己的破坏性编辑”可导致“其他用户违反3RR”？能否举一个实例？--自由雨日（留言） 2024年6月21日 (五) 17:35 (UTC)[回复]
可能意思是，破坏者被回退了三次，然后破坏者给回退员发了违反3RR的模板。--桐生ここ★[讨论] 2024年6月21日 (五) 20:58 (UTC)[回复]
哦哦！我找到原文了，这个“by”不应翻译为“通过”，而是“由于”，而且“by reverting…3-revert rule”应该是作为整个“Telling another user that…”的从句才对。不过这样太啰嗦，我尝试改为更符合中文习惯的表述：“在破坏性编辑被某用户多次回退的情况下，声称该用户违反了回退不过三原则。”（原先的表述起头一句“通过撤销您的……”太容易让人理解成“游戏维基者”本人撤销本人的破坏性编辑了……）--自由雨日（留言） 2024年6月21日 (五) 21:16 (UTC)[回复]
对于“游戏共识形成程序”部分有保留。关于“为了提升用户权限级别进行非建设性的编辑”定义，章节上就有“为了得到自动确认用户权限而做50次无贡献性或破坏性编辑。”，可以在此补充。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 01:02 (UTC)[回复]
「遊戲使用者權限」可改為「不當攫取使用者權限」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:00 (UTC)[回复]
查阅多本词典，感觉“攫取”侧重于“掠夺（有限资源）”？（用户权限是“无限资源”，不需要抢夺。）不如改成“套取”“诈取”“窃取”……？--自由雨日（留言） 2024年6月23日 (日) 02:11 (UTC)[回复]
「詐取」吧，「詐」其實就是「遊戲」。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 07:13 (UTC)[回复]
「詐」字本來就有「不當」的意思在內，寫成「不當詐取」要麼語義重複，要麼變相暗示存在非不當的「詐取」的情形，不妥。「不當獲取用戶權限」可能較好。Sanmosa 蚌埠 2024年6月23日 (日) 14:43 (UTC)[回复]
那直接寫成「詐取權限」即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 01:42 (UTC)[回复]

用一個假設的情境探討作品、創作者、協助宣傳者（混合生者傳記部分議題）

  • 情境，假設有某部W小說，還沒正式出版，部分的內容已經由作者公布在自己的x.com，但完整的設定細節，人物介紹等內容都沒有被正式公開（相關公開內容已經不可能符合WP:可供查證）。在這個情境，開放性維基（包含zh.wikipedia.org）收錄的對應資訊。部分的生者傳記頁面也受到影響，U插畫家的經歷增加了W的創作經歷，但公開可查詢的資料，包含W創作者V自己的社群網站或架設的網站都沒有揭露對應資料（WP:BLP議題）。
    1. 針對情境，使用WP:假定善意，似乎沒辦法推論出作者本人或作者群自行編輯增加資料以外的可能，因為資訊沒有被正式公開。即使是有狂熱愛好者表示和作者本人或作者群私下取得資訊，也涉及保密協定/版權(部分區域涉及商業機密問題)。是否逕行使用WP:版權或WP:COI處理
    2. 承接前項情境，假設複數具備自動確認/延伸確認/新建帳號、IP反覆插入，不論是手動回退，或者持續插入新內容，且已經證實在技術上不可查核，也確實是不同人操作
    3. 針對情境，假設對象聲明對象內容已經取得授權，確定沒有保密協定問題。對象也聲明資料正確（但基於商業機密也不願/不能私下提供未公開的資料文本），且在N日後在作者釋出的公開的資訊確實與情境中被加入的內容相符合。但因為我們不是預言家（WP:水晶球），在資料被加入的當下確實沒有任何公開資訊而有移除資料與復原資料交互發生的情形
    4. 承接前項情境，假設對象就是作者或作者群之一，且參與編輯的帳號有複數名聲稱自己是作者群之一
    5. 承接前項情境，在他們確實證實自己就是作者或作者群之一，或者是證實自己是出版社本身，逕行將全部公開資訊一字不漏，有時少量修改，將公開資訊完整地從J官網或者L社群網站拷貝到zh.wikipedia.org
    6. 承接前項情境，對象將內容盡可能和官網或官方公開資訊排版維持一致，資訊也盡可能完全一致，隨著資料更新也優先在zh.wikipedia.org更新各種劇情、角色、創作花邊、續集發表時間，用日記式的寫法接露創作歷程

針對上面的情境，是否新設規則管理，或者是否僅使用既有的規範管理，上述的情境應該可以適用於電視劇、電影、小說、動畫...等不同領域具有多種創作者參與的主題項目，及參與其中的製作團隊、演員、配音。--Rastinition（留言） 2024年6月21日 (五) 23:42 (UTC)[回复]

可供查证、可靠来源。过度细节的爱好者/宣传性。看不出为何要新增规则。--YFdyh000（留言） 2024年6月22日 (六) 06:32 (UTC)[回复]
@YFdyh000
2這個情境，可以有複數自動確認/延伸確認/新建帳號、IP及IP，僅針對頁面干涉1次（無法判定是屢勸不聽/不改，除非有個別行為者反覆/經常性撤銷），頁面保護作用不大，而且容易在單一頁面演化成長期問題。新增規則的用意是避免2麻煩。以及釐清6的問題(第一手來源作者本身使用第一手來源原文完整構成內容)--Rastinition（留言） 2024年6月22日 (六) 08:35 (UTC)[回复]
如果“W小说”是独立条目，但没有出版的话，可能已经存在关注度问题（有没媒体等合规的来源对其关注或者评价），那就根本没有存在这个条目的事。没前者的话，那就没有地方去添加关于其的描述。如果放到作者的条目（假设没有不合规而不能保留的问题）中，作为什么内容来描述，“准备写一本新小说”？——Sakamotosan路过围观 | 避免做作，免敬 2024年6月24日 (一) 01:11 (UTC)[回复]

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

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

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

不反對合併。不過能否詢問下您會怎麽設計合併之後页面评级的章文結構，如果可以的話能否參考下Temp君的意見。--人间百态,独尊变态(讨论) 2024年6月23日 (日) 08:37 (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)[回复]
我們在編輯某些條目，察覺一些方針需要制訂或修改，卻不一定常涉足所有受該方針影響的範疇，先反思影響範圍，再看看哪些用戶經常活躍於箇中話題，邀請討論，所有潛在疑問可能在兩三星期內就能被大家想出來了，可以集中解決。若不這樣做，往往有個人偶爾路過，又放下一個疑問，自然無休無止。就算你曾經順利通過提案，也只是你的一時幸運，而你的幸運不一定是維基之福。--Factrecordor（留言） 2024年6月26日 (三) 13:01 (UTC)[回复]
「偶爾路過，又放下一個疑問」，這個絕對支持，唯該路人是不是應該負起責任，主動跟進自己問過的疑問，如有需要，應儘他能力以最快時間進行追問，避免社群其他成員無限的等待，這對提案者絕對是一個折磨。--唔好阻住我愛國（留言） 2024年6月26日 (三) 13:13 (UTC)[回复]

技術

Template:Weather box

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

天气模板Template:Weather box，可以添加参数|width=auto以自动适应条目，但是在有信息框的条目中添加该参数并不总是会自适应，比如韦斯卡 (78803227)会在气候模板上方出现大段空白（可能也是信息框/Infobox的原因）。--Kethyga（留言） 2023年9月5日 (二) 10:03 (UTC)[回复]

自带{{clr}}效果？如果没有，表格在小屏幕宽度下不会放不下吗。--YFdyh000（留言） 2023年9月9日 (六) 04:14 (UTC)[回复]
手机网页和App看了下，应该都要左右滑动。--Kethyga（留言） 2023年9月9日 (六) 08:20 (UTC)[回复]
应该又是V22皮肤的css更新所致，换成2010版皮肤看是正常的。--蕭漫（留言） 2023年10月10日 (二) 02:44 (UTC)[回复]
似乎现在显示效果正常了？--Kcx36（留言） 2023年11月15日 (三) 10:39 (UTC)[回复]
目前已 无法重现。 Willy1018（留言） 2023年11月19日 (日) 02:50 (UTC)-- Willy1018（留言） 2023年11月30日 (四) 03:21 (UTC)[回复]
在条目韦斯卡中，未登录和Timeless Skin下目前均无法自适应页面宽度。--Kethyga（留言） 2023年11月27日 (一) 04:11 (UTC)[回复]
我的显示效果。--Kcx36（留言） 2023年11月27日 (一) 04:50 (UTC)[回复]
发现新版皮肤/外观在未登录状态下的右下角有一个切换“全屏宽度”和“有限宽度”的按钮，如果选择“全屏宽度”的话就不会被信息框/Infobox遮挡，但是Weatherbox/天气框仍未填满空间。另外在条目洛帕中，Timeless Skin下可以正常自适应页宽。--Kethyga（留言） 2023年11月28日 (二) 01:55 (UTC)[回复]
@Kethyga：英文維基百科也有這種情形嗎？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年1月29日 (一) 17:28 (UTC)[回复]
@Ericliu1912 en:Wikipedia:Sandbox (1220692034) 在英维的效果，个人认为无问题，右侧的信息框一般不会遮挡天气框。--Kethyga（留言） 2024年4月25日 (四) 09:52 (UTC)[回复]
@Kethyga：若直接複製來本地，是否可行？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年4月25日 (四) 15:28 (UTC)[回复]
得先测试看看了，不知道差异大不大，另外也不知道是否只是 Weather box 的问题。--Kethyga（留言） 2024年4月26日 (五) 01:30 (UTC)[回复]
因此話題遲無進展，故暫時作結，來日再議。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 02:57 (UTC)[回复]

MobileFrontend侧边栏故障

[17] Log in（登录）、Settings（设置）、Donate（资助）、About Wikipedia（关于Wikipedia（随维基媒体计划名称而变））、Disclaimers（免责声明）均无法被点击，也无法对其长按弹出浏览器菜单，全站（所有语言、所有维基媒体计划）均发生该问题。--Txkk（留言） 2023年11月29日 (三) 03:05 (UTC)[回复]

在firefox下未能复现，可点击，可弹出浏览器菜单。但是侧边栏各项一点击或弹出浏览器菜单时（点击鼠标左键或右键时），侧边栏就会迅速缩回，虽然点击的链接打开没问题（选择使用弹出的浏览器菜单中的功能也没问题），但是用户体验比较糟糕。从前端角度看，很可能算是个bug--百無一用是書生 (☎) 2023年11月29日 (三) 03:20 (UTC)[回复]
似乎现在mediawiki更新后，这个问题（或类似问题）已不存在了？--百無一用是書生 (☎) 2023年12月15日 (五) 11:56 (UTC)[回复]
还在。--Txkk（留言） 2023年12月15日 (五) 21:21 (UTC)[回复]

有没有人去Phabricator报告问题？--Txkk（留言） 2023年12月25日 (一) 06:46 (UTC)[回复]

我现在是只有关于和免责声明点击后侧边栏缩回，页面不跳转--百無一用是書生 (☎) 2023年12月25日 (一) 07:47 (UTC)[回复]
@Txkk、Shizhao：現在情況如何？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 02:58 (UTC)[回复]

引文模板不应该报错全部的零宽空格

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

Cat:引文格式1错误：不可见字符现在只要有U+200B就会报错，实际上有些零宽字符是合理且必要的，比如emoji和孟加拉文使用其连接字符。

建议将其改为维护而不是错误。--落花有意12138 2023年12月16日 (六) 12:44 (UTC)[回复]

en:Module:Citation/CS1/Configuration有為特定文字或Emoji添加例外。--Cookai餅塊🍪（💬留言） 2023年12月24日 (日) 10:10 (UTC)[回复]
等等，Module:Citation/CS1/Configuration也有indic_script，但Module:Citation/CS1沒有把它排除。--Cookai餅塊🍪（💬留言） 2023年12月24日 (日) 10:19 (UTC)[回复]
請問此問題有辦法解決嗎？《亂世勇者》的97號來源出現此情況，但不知道該如何解決。--H2226（留言） 2024年1月7日 (日) 10:11 (UTC)[回复]
要改的是Module:Citation/CS1/Utilities的has_invisible_chars，en的has_invisible_chars在en:Module:Citation/CS1，看有沒有高人要來修。--Cookai餅塊🍪（💬留言） 2024年4月24日 (三) 04:58 (UTC)[回复]
因此話題遲無進展，故暫時作結，來日再議。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 02:58 (UTC)[回复]

關於使用 ToolsRedirect 創建的繁簡重定向

本主題或以下段落文字，在討論結束後應存檔至MediaWiki talk:Gadget-ToolsRedirect.js、Category talk:有蓝链却未移除内部链接助手模板的页面、Category talk:簡繁重定向、Template talk:簡繁重定向。

使用ToolsRedirect自動創建的繁簡重定向，會被該工具錯誤地標記為別名重定向，參見：Special:Diff/82229793、Special:Diff/82063339、Special:Diff/82063322、Special:Diff/82034218、Special:Diff/82003931……煩請界管盡快修復此bug，防止掛有錯誤標記的繁簡重定向不斷增加。

由於大量編者均習慣以ToolsRedirect快速創建重定向，因此需要修正的繁簡重定向恐怕已不可勝數，能否讓機器人批量處理使用該工具創建的繁簡重定向，將頁面中的{{別名重定向}}替換為{{簡繁重定向}}？@Kanashimi--蕭漫（留言） 2024年4月12日 (五) 08:22 (UTC)[回复]

一个疑问，这些简繁重定向是必要还是不太必要的。是解决可视化编辑器问题的吗。--YFdyh000（留言） 2024年4月12日 (五) 19:47 (UTC)[回复]
个人感觉别名（包括地区用词、外文名）有必要，繁简必要性不大，条目和模板中可以正常跳转，只是编辑摘要（或者还有什么地方）会显示红链。--Kethyga（留言） 2024年4月13日 (六) 00:22 (UTC)[回复]
若不涉及一簡對多繁或異體字問題，繁簡重定向應該是不必要的。--蕭漫（留言） 2024年4月13日 (六) 01:04 (UTC)[回复]
User:YFdyh000、User:Kethyga、User:蕭漫：對我來說，簡繁重定向最重要的功能是克服伺服器緩存過多、直接逼User:Cewbot清掉被系統忽略、遺忘的偽藍連，例如我做完Special:PermaLink/82174815不久，機器人就幫我做了這筆清理，不這樣做的話，機器人不會清到這些條目機器人很難清到這些條目。英文維基百科那邊也是這樣，大家可以留意裡面有一條「{{ill|Hundred Flowers Award for Best Writing|zh|大众电影百花奖最佳编剧|lt=Best Writing}}」被標示為「The corresponding foreign language page does not exist.」，但中文百科其實有大眾電影百花獎最佳編劇條目，只是繁簡不同而已，如果有簡繁重定向頁就不會跳出這個錯誤。--迴廊彼端（留言） 2024年4月14日 (日) 14:19 (UTC)[回复]
伪蓝链是什么效果。Database reports可能该机器人不支持简繁机制，不了解有无别的方案。是否要建简繁重定向似乎多次讨论过，有无结论忘记了。--YFdyh000（留言） 2024年4月14日 (日) 14:54 (UTC)[回复]
User:YFdyh000：偽藍連只有兩種可能，一個是應該功成身退的跨語言連結，另一個是編者寫的不正確或與未來建立條目名稱不同、導致機器人清不掉的連結，兩種最好都不要存在。--迴廊彼端（留言） 2024年4月15日 (一) 14:16 (UTC)[回复]
我还没发现本地User:Cewbot/需要修正的跨語言連結中因为繁简而受影响的情形。如果确实有的话，应该可以考虑重新设计机器人。倒是除此之外，繁简重定向确实没有什么作用。--PexEric 💬|📝 2024年5月2日 (四) 09:35 (UTC)[回复]
可能需要修改MediaWiki:Gadget-ToolsRedirect.js的识别方案吧，另外还有非繁简识别成繁简重定向的，比如82561648--Kethyga（留言） 2024年5月10日 (五) 03:13 (UTC)[回复]
不知@Kanashimi看法如何？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 02:59 (UTC)[回复]
@迴廊彼端 不知能否提供個需要創建繁簡重定向的例子讓我研究看看?--Kanashimi（留言） 2024年6月25日 (二) 06:11 (UTC)[回复]
User:Kanashimi：除了上面的例子外，Special:Diff/82267560中有個「{{link-en|湿实验室|Wet lab}}」，實際上已有濕實驗室條目，所以這模板應該被分入Category:有蓝链却未移除内部链接助手模板的页面，但目前沒有；要是我沒剛好遇到，Cewbot不知道過多久才會來處理，。--迴廊彼端（留言） 2024年6月25日 (二) 13:31 (UTC)[回复]
我改一下程式，這兩天跑跑看有沒有效。--Kanashimi（留言） 2024年6月25日 (二) 13:47 (UTC)[回复]

未有登入的用戶將可以使用外觀選單和新的預設標準字體大小

摘要：基金會計劃將未登入用戶的字體大小改為標準選項（16px），登入用戶維持原狀及為小選項（15px），所有用戶將有選項列表改變字體大小和行高、及開關深色模式。此變更僅影響使用Vector 2022皮膚的用戶。如果沒有任何重大問題，將會兩星期後部署此改動。--SCP-0000（留言） 2024年5月25日 (六) 03:17 (UTC)[回复]

大家好！ 我們是維基媒體基金會網路團隊。作為本年度年度計劃「閱讀和媒體體驗目標的一部分，我們致力於讓維基媒體計劃的閱讀變得更容易。為了實現這一目標，我們推出了「無障礙閱讀」測試版功能。這添加了一個適用於 Vector 2022 皮膚的選單，並允許已登入的用戶根據個人需求選擇不同的字體大小和配色方案。

此選單引入了新的標準字體設定。這稍微增加了字體的大小和高度。它是根據多個來源選擇的。您可以在「關於新的標準字體設定」部分找到更多相關資訊。

我們將會發生什麼變化

  • 我們現在已準備好為未有登入的和已登入的用戶提供新的外觀選單。
  • 同時，我們將標準選項設定為僅適用於未有登入的用戶之新預設選項。
  • 如果沒有發現重大技術問題，我們計劃在接下來的兩週內進行此更改。
  • 稍後，該選單將包括選擇深色模式的選項（該功能暫時仍將是測試版功能）。如希望了解更多信息，請查看我們的專案頁面。

關於選項列表

新選單將允許為未有登入的和已登入的用戶設定以下首選項：

  1. 文字大小和行高（現以測試版功能提供）：使用者將能夠在「小」（目前預設值）、「標準」（建議更好的可訪問性）和「大」選項之間進行選擇。選擇一個選項將更改文字的字體大小和行高。
  2. 深色模式（現以測試版功能提供）：使用者將能夠選擇永久以深色模式查看網站，或選擇「自動」設置，根據裝置或瀏覽器首選項設定淺色或深色模式。
  3. 內容寬度（先前作為切換按鈕提供）：我們已將內容寬度切換從頁面底部的圖示移至新選單中標籤的單選按鈕。其工作原理與切換開關完全相同。之前的切換按鈕將不再可用。

此選單已作為測試版功能由不同的維基之專案上的已登入使用者進行了測試，同時我們邀請了一些讀者進行了使用者測試。根據這些測試的結果，我們更改了選單，以提高可發現性和易用性，並適應小工具的相容性。

此選單將顯示在頁面右側，如果已固定選單，則緊鄰「工具」選單的下方。與「工具」選單不同，「外觀」選單預設是固定的，但您可以取消固定預設。一旦取消固定預設，這就會折疊在頁面頂部的圖示下。

關於新的標準字體設置

小字體選項是目前的預設值。對於未有登入的用戶，我們將將此預設值更改為「標準」，同時保留小字體選項作為已登入用戶的預設值。「標準」和大字體選項是根據以下內容構建和測試的：

  • 針對大多數讀者的最佳平均字體大小的學術研究和建議。這些建議表明，我們目前的字體尺寸太小無法讓大多數人舒適地閱讀。這意味著，平均而言，人們閱讀速度較慢，閱讀時眼睛疲勞，或難以清楚地看清文字。預設增加字體大小可以改善所有使用者的這些問題，包括可能沒有足夠時間透過外觀選單或瀏覽器調整設定的使用者。資訊密度同時很重要，這就是為什麼我們希望在不犧牲資訊密度的情況下增加字體大小。我們不僅透過更改字體大小，同時透過更改行高和段落間距來實現這一目標。
  • 由來自 13 個不同語言、腳本和大小的維基專案中 630 多名維基媒體成員提交的設計。這些用戶中的大多數（約 450 名）選擇了比預設值更大的字體大小。「標準」代表最受歡迎的一組答案（15-20 像素）的平均值。大字體選項代表讀者需要更大的字體尺寸選項，例如 21-26 像素之間的一組尺寸。您可以在此閱讀更多關於我們如何讓志願者參與此過程並確定這些選項的資訊。
  • 測試版功能使用情況表明，至少一次與該功能互動的大多數使用者選擇的字體大小大於當前預設值。

我們目前為止的工作和下一步

已登入的用戶將暫時保留小字體選項設置作為預設設置，但可以隨時更改為任何其他設定。幾個月後，我們將研究有多少登入使用者切換到標準字體選項，並開始討論已登入的用戶進行的切換是否具有意義。根據測試版功能的早期數據，與該功能的互動中有 55% 選擇使用標準或更大的字體選項設定。

如果您想提供協助，我們有一些簡單的請求：

  1. 請開啟測試版功能 （「無障礙閱讀（Vector 2022皮膚）」）
  2. 請嘗試一下新選單。請問有什麼令人困惑的部分嗎？您了解所有標籤以及選單的工作原理嗎？
  3. 請嘗試不同的字體選項：小尺寸、標準尺寸和大尺寸、配色方案和寬度切換。如果您發現任何錯誤或有任何疑問，請與我們聯絡。

Last-minute FAQ (thanks to SCP-2000 for pointing out these issues:

Zhwiki community has already solved this issue by increasing the font size to 15px with a gadget.
We believe that it's great that you have decided to increase the font size. You are one of few communities which have done that, and we applaud you. But 15px turns out to be not enough.
Why 16px? Do this research and data usage apply to CJK characters?
Yes, they do. 16px is a minimum for any script, including non-diacriticized Latin scripts like English. Since Chinese characters are more complex than Latin characters, the minimum for zhwiki is at least equal to the minimum for the Latin script-wikis.

如果您想了解有關該專案的更多信息，請參閱我們的常見問題與答案。我們歡迎您提出意見和問題。謝謝你！[Translated by Venuslui] OVasileva (WMF) & SGrabarczuk (WMF)（留言） 2024年5月24日 (五) 12:26 (UTC)[回复]

我记得@Shizhao曾经解释过选择15px的理由，想问一下同样的理由也适合16px吗？这个变化至少在我这里是可感的，而社群当时同意保持15px的理由是尽量避免变化。--碟之舞📀💿 2024年5月24日 (五) 14:11 (UTC)[回复]
@Shizhao、YFdyh000、S8321414、Ericliu1912： 簡單而言，未登入用戶的字體大小改為標準選項（16px），登入用戶維持原狀及為小選項（15px），所有用戶將有選項列表改變字體大小和行高、及開關深色模式。如果沒有任何重大問題，將會兩星期後部署此改動。副知曾參與相關討論的編者。謝謝。--SCP-0000（留言） 2024年5月24日 (五) 16:09 (UTC)[回复]
如果真的要更改的话，有必要维持两个选项吗？我觉得这样徒增维护成本。--碟之舞📀💿 2024年5月25日 (六) 03:02 (UTC)[回复]
這功能本來設計就有「小」（目前預設值）、「中」（基金會建議值）及「大」選項，應該不會徒增基金會維護的成本，但始終可能對社群有些影響。--SCP-0000（留言） 2024年5月25日 (六) 03:26 (UTC)[回复]
也就是说中文的“小”还是会从14px改为15px，是吗？--碟之舞📀💿 2024年5月25日 (六) 03:34 (UTC)[回复]
理論上是的。--SCP-0000（留言） 2024年5月25日 (六) 03:49 (UTC)[回复]
所以現在未登入與已登入的使用者都是小(15px)、標準(16px)、大(20px)，只是未登入使用者預設是標準(16px)，已登入使用者預設是小(15px)這樣？我是覺得這樣沒什麼問題。--冥王歐西里斯（留言） 2024年5月26日 (日) 02:16 (UTC)[回复]
理論上是的。--SCP-0000（留言） 2024年5月26日 (日) 02:34 (UTC)[回复]
目前已经部署了，将来打算如何调整？--碟之舞📀💿 2024年6月16日 (日) 09:32 (UTC)[回复]
感覺社群意見不多。建議往後分別提出。祇是個人納悶為何登入與否字體大小不同？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:36 (UTC)[回复]
應依據原定計劃將「大字體」工具在 Vector 2022 停用，然而現在「無障礙閱讀」功能並非所有用戶預設啟用，所以可以再等一下。謝謝。--SCP-0000（留言） 2024年6月25日 (二) 06:30 (UTC)[回复]
@SCP-2000：技术上可以做到只在“无障碍阅读”功能启用的情况下停用。原定计划可以执行。--碟之舞📀💿 2024年6月25日 (二) 07:28 (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错误[18][19]，如天门山寺、和合石。--Kcx36（留言） 2024年6月9日 (日) 10:35 (UTC)[回复]

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

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

Wikiplus导致Navbar被换行

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)[回复]
话说，修复之后，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)[回复]

請求修改Template:Cite gnis

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

本人於去年12月曾一度請求修改上述模板，但由於無人受理，加上VPA有人討論本人建立的條目，故不得不再次請求修改。

美國地質調查局於2021年10月將地名信息系统從「http://geonames.usgs.gov/pls/gnispublic/f?p=gnispq:3:::NO::P3_FID:123456」改為「https://edits.nationalmap.gov/apps/gaz-domestic/public/search/names/123456」。英語維基早已於2021年10月更改模板的相應參數，但中維卻至今仍未作出任何改動，導致使用該模板時，會被重新導向到「https://www.usgs.gov/us-board-on-geographic-names」。該模板於2020年因使用頁面過多而被模板保護，需要模板編輯員修改該模板。

本人建議將該模板完全按照en:Template:Cite gnis作出修改。該模板應用於中維數萬篇條目中（約佔中維所有條目的2.86%），私以為對模板作出修改刻不容緩。希望能有模板編輯員參與對該模板的修正，感激不盡。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月16日 (日) 05:22 (UTC)[回复]

(＋)支持--歡顏展卷（留言） 2024年6月16日 (日) 19:39 (UTC)[回复]
试了一下，照搬enwiki有问题--百無一用是書生 (☎) 2024年6月17日 (一) 14:44 (UTC)[回复]
把|entry-url={{GNIS URL|{{{1|{{{id|}}}}}}|type={{{type|}}}}}換成|url={{GNIS 3|{{{1|{{{id|}}}}}}|type={{{type|}}}}}除了殘留的英文好像沒什麼問題了。--Miyakoo（留言） 2024年6月17日 (一) 21:40 (UTC)[回复]
{{GNIS 4}}也需要改，參照英維試了一下，沒有問題。--Miyakoo（留言） 2024年6月17日 (一) 22:08 (UTC)[回复]
沒錯，其實需要多更改幾個模板才能解決顯示錯誤的問題。所以才需要花時間討論如何修改模板。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月18日 (二) 03:25 (UTC)[回复]
已经更新了{{GNIS 4}}和{{Cite gnis}}，请检查有无问题--百無一用是書生 (☎) 2024年6月18日 (二) 07:54 (UTC)[回复]
所有頁面的對應GNIS資訊頁現在都能正確顯示了，非常感激。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月18日 (二) 09:01 (UTC)[回复]

{{Wikipediasister}}不显示图标

本主題全部或部分段落文字，已移動至Template talk:Wikipediasister。执行人：Jimmy-bot（留言） 2024年6月27日 (四) 08:14 (UTC)。[回复]

一些模板可能导致页面排版出错

我目前发现的有Template:routemap，该模板于大都会线等页面内，移动端视图会出现排版错误，下一章节（甚至多个章节）的标题会与展开的routemap重叠在一起难以查看和点击。我试图更改条目的内容布局但无法解决问题，并且我最新的更改后发现桌面端也出现了同样的排版错误，routemap展开后会超出下一章节的标题和内容。

所以这个问题要如何解决？有没有其他类似的模板，内容过长展开时也会出现这个问题？--Awdqmb（留言） 2024年6月17日 (一) 13:53 (UTC)[回复]

您可以考虑将{{Clear}}置于{{Routemap}}下方。Irralpaca（留言） 2024年6月17日 (一) 23:59 (UTC)[回复]
我试了一下，问题确实解决了。但我个人认为直接从底层排版逻辑修复这个问题应该很难，毕竟移动端的显示排版问题一直是整个维百的老大难问题。--Awdqmb（留言） 2024年6月18日 (二) 02:45 (UTC)[回复]
是否和phab:T367463#9894557是同样问题？--百無一用是書生 (☎) 2024年6月18日 (二) 02:28 (UTC)[回复]
看起来不是，不过这个问题我之前在其他语言的维基（比如英维）见过这个问题，直接放入Infobox的Routemap会排版出错，Routemap所有内容都会自动换行不连贯。但现在这个问题已经修复了，至少英维是修复了。而且我没在中维见过这个问题（因为我之前就在补充一些线路的Routemap）。--Awdqmb（留言） 2024年6月18日 (二) 02:40 (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升级后这个问题变严重了。可以参考下这个[20]，一大堆的报错--百無一用是書生 (☎) 2024年6月19日 (三) 02:25 (UTC)[回复]

2024年第25期技術新聞

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

最近更改

  • 現在，當用户在視覺化編輯器中嘗試加入外部連結，而該網域被列入維基项目的黑名單，用户將立即收到回饋。詳情請見編輯檢查。 [21]
  • 新的社群配置扩展可在測試維基使用。此扩展使本地社群能依需求自訂特定功能。目前僅能配置Growth功能，但未來將支持其他用例。 [22][23]
  • 現在，深色模式測試功能可以在分類、帮助頁面以及更多特殊頁面上使用。請留意可能存在對比問題。如果您發現任何錯誤，請在项目討論頁回報。 [24]

問題

  • 上週，維基媒體云服務中斷了25分鐘。這是由於数据中心的纜線故障所致。 [25]
  • 上週，Vector 2022皮肤進行了樣式更新。這導致了模板、頂註和圖片出現意料之外的問題。對模板和頂註的更改已被回退；大多數圖片問題已解決。如果您發現任何問題，請在此工單回報。 [26]

本週更改

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

MediaWiki message delivery 2024年6月17日 (一) 23:47 (UTC)[回复]

「參考編輯檢查」感覺會挺有用的？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 03:15 (UTC)[回复]
在过滤最近更改时把拒绝编辑检查的四个标签激活，立刻治好低血压。——暁月凛奈 (留言) 2024年6月19日 (三) 16:41 (UTC)[回复]

跨项目通知的蓝点

近期发现在中文维基百科的页面中，“常规通知”右侧有蓝点，一般情况下点击之后页面会被标记为已读状态。但是跨语言/跨项目的通知的“总”蓝点无法点掉（原来是可以的），只能一个个点击“子”蓝点来已读。例如：

来自另外1个wiki的更多常规通知 ●←（1）
中文维基词典
您创建的[A]页面在[B]页面被人链接。●←（2）

只有点（2）才会把●标记为○，而点（1）只有点击手感，无其它改变。

请问是哪边有了更改了吗？--Leiem（留言·签名·维基调查） 2024年6月19日 (三) 09:33 (UTC)[回复]

似乎这个已经有一段时间了。我还以为是特意为之....--百無一用是書生 (☎) 2024年6月20日 (四) 08:21 (UTC)[回复]
我怎么觉得一直如此……--YFdyh000（留言） 2024年6月21日 (五) 05:22 (UTC)[回复]
近期是这样的，以前是可以直接点掉未读消息的。--Leiem（留言·签名·维基调查） 2024年6月25日 (二) 02:20 (UTC)[回复]
我這邊也出現了這種問題。應考慮提交工單。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 13:21 (UTC)[回复]

深色模式界面格式问题：编辑模式对话框文本、SVG图片、代码块背景色及字体

本主題全部或部分段落文字，已移動至Wikipedia:徵求意見/深色模式。

—此條未加入日期時間的留言是于2024年6月21日 (五) 08:14 (UTC)之前加入的。

NoteTA 烏克蘭地名無法正確轉換“頓内次克”

本主題或以下段落文字，在討論結束後應存檔至Talk:馬亞基 (頓內次克州)。

參考馬亞基 (頓內次克州)，當中標題和内文都無法轉換到台灣以外地方使用“頓涅茨克”的稱呼。--MykolaHK（留言） 2024年6月20日 (四) 16:22 (UTC)[回复]

标题问题您似乎自己修复了（Special:Diff/83110663），内文也是一样的问题啊，我刚刚修复了（Special:Diff/83111061）。--自由雨日（留言） 2024年6月20日 (四) 17:15 (UTC)[回复]
是的，另外想了解一下「頓內茨克」譯名的轉換，因部分媒體也有使用此譯名。--MykolaHK（留言） 2024年6月20日 (四) 17:36 (UTC)[回复]
公共转换组译名应该类似WP:命名常规，是根据一地的通用情况来确定的。如果“顿内茨克”在香港的使用率明显低于“顿涅茨克”，应该采用后者。我不太了解具体的乌克兰地名转换，相关问题可前往公共转换组讨论？--自由雨日（留言） 2024年6月20日 (四) 17:46 (UTC)[回复]
沒記錯的話，是由於「頓內茨克」及「頓內次克」譯名爭議，公共轉換組中相關轉換暫停適用。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月21日 (五) 02:57 (UTC)[回复]

模板中禁止使用noteTA标题转换？

刚刚发现，如模板中加入noteTA字词转换，可能导致引述模板的条目中（标题等）的错误。例子：Template:手動工具。

有何方法禁止在模板中使用 noteTA字词转换，或至少在提交模板编辑时展示警告？--Zhenqinli（留言） 2024年6月20日 (四) 17:51 (UTC)[回复]

之前的版本直接添加了标题转换（Special:Diff/83053442），那毫无疑问会导致标题错误……我已经改为只在正文转换了（Special:Diff/83111564）。第二行，“禁止在模板中使用字词转换，或至少……警告”我没看懂。--自由雨日（留言） 2024年6月20日 (四) 18:30 (UTC)[回复]
应该修正为：禁止在模板中使用noteTA（T=标题转换）的选项。--Zhenqinli（留言） 2024年6月20日 (四) 18:35 (UTC)[回复]
Template:NoteTA/doc#其他注意事項已经指出“如果要在模板内使用本模板，请将本模板用<noinclude>……</noinclude>包圍”，理论上如果加了noinclude（现在已经被加上了），模板的标题转换是不会影响条目中的标题转换的，出问题是加模板操作错误。
另外，有的模板确实是需要标题转换的（如{{知识共享}}），不应该禁止；倒是可以提示“在模板中加{{NoteTA}}要包含noinclude”。--古怪的Wang31（讨论 | 贡献） 2024年6月21日 (五) 00:37 (UTC)[回复]
感谢说明！我确实之前在模板代码中都会看到{{NoteTA}}被<noinclude>……</noinclude>包裹，但感觉这里和相关条目转换规则的冲突概率不大，所以就没加（Special:Diff/83111564），没想到在Template:NoteTA/doc#其他注意事項中有强制要求。确实应该加上这句提示。尤其是对直接在模板中将局部字词转换参数写作T（相关编者本意不可能是想将“手动工具”标题转为“锁定钳”）的新手来说，一般更不会知道要用noinclude包裹的注意事项……--自由雨日（留言） 2024年6月21日 (五) 01:22 (UTC)[回复]
说点远的：我觉得将来应该扩展MW自己的字词转换语法，给规则设定作用域，这样就可以最终解决这个长久以来的痛点。--碟之舞📀💿 2024年6月21日 (五) 03:16 (UTC)[回复]
应该是“模板的作用域”，有些模板不应该透传到其他页面。也就是noteTA不应该放在模板页面中，然后被嵌入时透传到条目页面上。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月21日 (五) 03:25 (UTC)[回复]

“為翻譯頁面標記{{Translated page}}”小工具的bug

應該產生的是“|version=<版本號>”，但是無法正常抓取版本號，變成了“|version=undefined”。--GnolizX（留言） 2024年6月21日 (五) 12:23 (UTC)[回复]

以淺藍色背景突顯被點選到的數學式其對應的NumBlk模板

我已將{{NumBlk}}的inline styles盡可能地都移到其對應的模板樣式CSS頁NumBlk/styles.css了。接下來，因為維基百科原本就有一些點選後以淺藍色背景顏色突顯目標的行為（例如：點選條目中的註釋編號後註釋文字會以淺藍色突顯、點選訂閱通知後在討論章節中新增文字會以淺藍色突顯），所以我想{{NumBlk}}或許也應比照辦理。例如，在特征线法裡的數學式(6)其源碼為： 

{{NumBlk|:|<math>
...（省略LaTeX，不是討論的重點）...
</math>|{{EquationRef|6}}}}

它的渲染結果為：

6

而在條目的源碼中加入({{EquationNote|6}})即可產生連到該數學式的連結(6)。我希望點選前面那個連到數學式的連結後，會變成如下的樣式，也就是整個{{NumBlk}}的背景變為淺藍色：

6

而不是只有編號的部份其背景變為淺藍色（這樣非常不明顯，而且也看不出整個數學式的範圍）：

6

以上的需求，不確定能否光靠模板樣式或CSS來達成？？？？？

但是目前看來似乎有難度，因為({{EquationNote|6}})所連結到的目標是{{EquationRef|6}}，所以用:target pseudo-class所選到的節點基本上是{{EquationRef|6}}而不是最外層的整個{{NumBlk|:|<math>...</math>|...}}，如此就難以突顯整個{{NumBlk}}，而是可能只有突顯到{{NumBlk}}的子節點，也就是編號的部份。可能這需要CSS selector能夠選到父節點的類似功能才能辦到...--Justin545（留言） 2024年6月22日 (六) 15:25 (UTC)[回复]

(～)補充：Is there a CSS parent selector? 提到可以用:has() pseudo-class來選到父節點，但這CSS規格較新，一些browser可能不支援。--Justin545（留言） 2024年6月23日 (日) 13:01 (UTC)[回复]
  • (：)回應我用火狐和Chrome在F12 Console下使用
    console.log(document.querySelectorAll(".numblk:has(a:hover)"))
    回傳NodeList [ table.numblk ]，如圖
None
但使用Template:沙盒/TemplateStyles測試之後得到以下錯誤訊息：
Error: Expected RPAREN at line 1, col 14.
在第 1 行裡字元 1 有無效的頁面選擇器清單。
似乎:has()語法在頁面內容模型（ContentModel）為「sanitized-css」（已過濾的CSS），也就是Help:模板樣式，似乎還不支援此種語法，所以系統會阻止你在Help:模板樣式:「sanitized-css」（已過濾的CSS）頁面中提交包含:has()的css selector，如圖
None
既然系統已經阻擋，即使繞過阻擋，該規則也會被MediaWiki過濾掉而無法生效，因此含有此CSS Selector會無法保存編輯(沙盒也發不了、而顯示預覽時，則該規則消失)。
所以，如需要讓Help:模板樣式支援:has()的css selector，可能需要提工單或提交社群願望清單。c.c.@Justin545：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月23日 (日) 14:59 (UTC)[回复]
  • (：)回應
我之前沒有實際做過:has()的測試，沒想到sanitized-css或MediaWiki可能也是潛在的問題，感謝閣下的測試與回覆。
後有去查了一下，在MDN關於:has()的Browser compatibility一節看到各大browser的相容資訊，Firefox是121 (Released 2023-12-19)。所以根據該表，沒錯的話可以整理出一個相容性的清單：
  • Chrome:105 (Released 2022-09-02)
  • Edge: 105 (Released 2022-09-01)
  • Firefox: 121 (Released 2023-12-19)
  • Opera: 91 (Released 2022-09-14)
  • Safari: 15.4 (Released 2022-03-14)
  • Chrome Android: 105 (Released 2022-09-02)
  • Firefox for Android: 121 (Released 2023-12-19)
  • Opera Android: 72 (Released 2022-10-21)
  • Safari on iOS: 15.4 (Released 2022-03-14)
  • Samsung Internet: 20.0 (Released 2023-02-10)
  • WebView Android: 105 (Released 2022-09-02)
可以看到各browser似乎都要到2022年後才開始對:has()提供支援，對於不常更新browser軟體的使用者是有一定的危害。
現在主要的兩個問題：server side是閣下所發現的問題，client side是browser相容性的問題，這似乎讓:has()的解決方案走進暫時的死胡同裡。如果CSS的問題在幾年內都是暫時無解的，或許要考慮CSS以外的方法...。也許是另外再建一個新版的{{NumBlk}}，譬如像是{{NumBlkEx}}這個新模板，然後在新版{{NumBlkEx}}的實作部份會自動把第3個參數（也就是編號）當作是最外層節點的id attribute，例如呼叫
{{NumBlkEx|:|<math>...</math>|17}}
展開後會自動變成
<table id="math_17" class="numblk">...（數學式與編號）...</table>
這樣當在條目中若有新增或存在既有的{{EquationNote|17}}，它所連結到的目標基本上就會是整個{{NumBlkEx}}了（若沒錯的話，原本{{EquationNote}}所連結到的目標id是透過其展開後所包含的一個連結<a href="#math_17">...</a>所決定的）。若是這個做法，呼叫{{NumBlkEx}}時第3個參數就不應該再使用{{EquationRef}}。而{{NumBlkEx}}的實作部份看是要把{{NumBlk}}的源碼複制過去改，還是要把{{NumBlkEx}}當作一個wrapper template去呼叫原本的{{NumBlk}}。{{NumBlk}}的說明文件也要明顯地註明將{{NumBlkEx}}與{{EquationRef}}合併使用是不建議的（deprecated），應改用{{NumBlkEx}}。
目前還想不到較好的做法，上述做法的缺點是只能適用到新增的條目內容，原有的條目內容可能要手動（以機器人改對我有技術門檻，但英文維基呼叫{{NumBlk}}或{{EquationRef}}的次數估計皆超過1000次）慢慢改成使用新版的{{NumBlkEx}}。--Justin545（留言） 2024年6月24日 (一) 05:01 (UTC)[回复]

繁簡分類重新導向問題

歸類於繁體標題下之頁面，未能自動重新導向至簡體；如不丹宗份在「各國一級行政區」，卻不能自動分類至既有之「各国一级行政区」分類。Jimmy-bot可能亦需要注意此種分類。我知道手動建立分類重新導向應該可以解決，但本來應該不建立也能運作纔是。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 14:32 (UTC)[回复]

有没有辦法限制重定向在條目正文中的使用？

諸如溫哥華白帽、FC多倫多這樣屬於「常見錯誤拼寫」的重定向，有沒有辦法能限制它們在條目正文中的使用，使這些重定向只能用於搜索和導航，但不能在正文中出現？--📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年6月23日 (日) 16:53 (UTC)[回复]

看了一下，正文目前也并没有出现这两个词啊……（除了“温哥华白帽”在介绍这个词本身时候出现了一次。）如果用词罕见或不当，正文自然不会出现（即便出现，也会被其他编者改为常用词）。如果说您是想要通过技术手段限制类似的“错误用法”的话，我倾向没有必要。--自由雨日（留言） 2024年6月23日 (日) 18:46 (UTC)[回复]
请问这么做的意义是？尚没有规则禁止不常见的错误拼写，常见的又怎么会被禁止？而且，技术上有可能实现吗？--微肿头龙（留言） 2024年6月24日 (一) 17:10 (UTC)[回复]
意義在於不讓條目質量下跌到可接受程度之下。而且既然是錯誤拼寫，自然不應該出現在正文之中。即使是這種重定向在正文中用作鏈接，也應該被豎杠後面的文字覆蓋掉（就像這樣：「[[溫哥華白帽|溫哥華白浪]]」）。📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年6月24日 (一) 18:39 (UTC)[回复]
感觉可设立机器人检查和提醒，但全自动是不行的。--YFdyh000（留言） 2024年6月25日 (二) 14:26 (UTC)[回复]
假如廣泛採用{{錯誤拼寫重定向|正確寫法=xxx}}，機器人或許能幫忙處理。--Kanashimi（留言） 2024年6月25日 (二) 22:58 (UTC)[回复]

2024年第26期技術新聞

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

最近更改

  • 上週，差異視圖中的文字背景顏色以及位元組變化數字的顏色有一些更改。這些改動旨在使文字在淺色模式和深色模式下更容易閱讀，是加強落實無障礙的一部分。您可以在專案討論頁提出意見和疑問。 [31]
  • 上週，visited、hover和active链接的顏色也略有改動，以在淺色模式和深色模式下進一步落實無障礙。 [32]

問題

本週更改

  • MediaWiki的新版本將於6月25日部署至測試維基及MediaWiki.org，於6月26日部署至非維基百科wiki及部分維基百科，並於6月27日部署至所有站點（參見日程表）。 [34][35]
  • 從6月26日開始，英語維基百科上所有討論頁留言的时间戳將產生一個链接；至此所有維基都能使用此功能。這個链接是該留言的固定链接。即使留言被移動到他處，用户仍找得到該链接導向的留言。關於此功能的更多信息，請參閱Diff或Mediawiki.org。 [36]

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

MediaWiki message delivery 2024年6月24日 (一) 22:31 (UTC)[回复]


求助

为什么其他国家的政治人物都被称为“X国政治人物”，唯独中华人民共和国的政治人物都是什么“中国共产党、中华人民共和国政治人物”？

如习近平、李克强、王沪宁等--Coddlebean（留言） 2024年6月6日 (四) 05:05 (UTC)[回复]

阁下这么说就错了。海峡对岸政治人物（包括李登辉、陈水扁、马英九等）的总分类都是分类:中华民国政治人物，而非分类:中国政治人物或者分类:台湾政治人物。至于分类:中国共产党领导人之类的分类也很好理解：习、李、王等人的确都是中共党员，正如陈水扁、蔡英文是民进党党员，蒋经国、马英九是国民党党员。📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年6月6日 (四) 06:06 (UTC)[回复]
那条目也没说他们是国民党 民进党政治人物啊--Coddlebean（留言） 2024年6月6日 (四) 06:41 (UTC)[回复]
我觉得该描述是多余赘述，其他介绍和分类完全能涵盖这句。另外，倾向不单独强调是中共的政治人物，国家比政党的政治人物更重要。--YFdyh000（留言） 2024年6月6日 (四) 12:45 (UTC)[回复]
我在写导言时，通常会称这些政治人物为“中华人民共和国政治人物”，仅此而已，这个介绍已经可以概括人物特性。--Allervous初音ミクのセーラー服 2024年6月15日 (六) 01:14 (UTC)[回复]
因為中華人民共和國憲法寫道：中國共產黨領導是中國特色社會主義最本質的特徵。黨的領導人與國家領導人在中華人民共和國沒有實質區別。這與多黨制民主國家不同。--歡顏展卷（留言） 2024年6月7日 (五) 23:24 (UTC)[回复]
然而通常此類人物後面都有長篇大論的黨內職務，實際上一開始不用講「中共」也行。我認為保留「中華人民共和國」即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月19日 (三) 17:31 (UTC)[回复]
參見「黨和國家領導人」的官方術語，不是中華人民共和國領導人，也不是國家和黨領導人，這裡的黨指中國共產黨；國家指中華人民共和國。--223.197.183.130（留言） 2024年6月6日 (四) 10:15 (UTC)[回复]
因為中國太大了、政治體系落差，然後各自表述。 -- 月都 ※ 2024年6月20日 (四) 15:15 (UTC)[回复]

关于公文引用

发现有些人在添加行政区划调整的参考资料时，只添加了公文名称和公文编号，或只有公文名称（如Special:diff/62578866、Special:diff/65829766），而没有添加公文全文在政府网站的网页链接，这种无链接的公文引用是否属于无效引用？

ping一下相关编辑者：@高晶、Chk2011。--幻光尘（留言） 2024年6月10日 (一) 05:41 (UTC)[回复]

不算无效引用吧？没有规定来源必须有网页链接，不论是WP:来源还是GB 7714。当然，有获取和访问路径是最好的。--自由雨日（留言） 2024年6月10日 (一) 07:08 (UTC)[回复]
应该不算无效引用，发文标题加发文字号可以唯一识别来源。另针对此问题，可以在Wikipedia:互助客栈/条目探讨#Template:Cite_act发表意见。在芝山街道 (漳州市)条目中，操作（Special:Diff/65829766/82896384）将来源删除不妥当，该来源显然可以查证。--Kethyga（留言） 2024年6月10日 (一) 08:25 (UTC)[回复]
可芝山街道 (漳州市)条目一开始添加的来源甚至连文字号都没有（目前已补全文字号和网页链接）。--幻光尘（留言） 2024年6月10日 (一) 08:48 (UTC)[回复]
但是仍然是有用的参考资料，可以按图索骥，而且有些年代久远、或者一些未知原因，有些公文不一定有在线版本。--Kethyga（留言） 2024年6月10日 (一) 08:55 (UTC)[回复]
那确实，我的想法是能找到链接的最好把链接附上。--幻光尘（留言） 2024年6月11日 (二) 01:45 (UTC)[回复]
有效的，有纸质版存在，书本来源不强求线上版本、url参数。--YFdyh000（留言） 2024年6月10日 (一) 11:15 (UTC)[回复]
有些文件根本不挂网，有个标题最少也能让别人去申请信息公开。--伞木 霙留言 2024年6月10日 (一) 12:44 (UTC)[回复]
非公开出版的来源不应使用。--YFdyh000（留言） 2024年6月10日 (一) 14:03 (UTC)[回复]
不挂网≠不公开。不挂网的文件可能是通过贴在线下公告栏里、在出版的纸质公报里或者放在信息公开室里发布，通过依申请公开可以取得复制件。不公开的文件无法通过信息公开渠道取得。--伞木 霙留言 2024年6月10日 (一) 14:38 (UTC)[回复]
同意。--幻光尘（留言） 2024年6月18日 (二) 12:24 (UTC)[回复]
同意。--Allervous初音ミクのセーラー服 2024年6月15日 (六) 02:26 (UTC)[回复]
应当尽可能给出在线版本链接。--Kcx36（留言） 2024年6月11日 (二) 03:22 (UTC)[回复]
同Kcx36阁下，能给线上可查询的来源就给可查询的来源。不管是读者还是编者，都方便查阅。虽说只给公文名称和公文编号不算违规，不过还是尽量不要这样吧。即使是依申请公开的渠道，我也找相关部门弄过依申请公开，流程时间很长，对一般的读者来说不方便（话说我自己也在条目里用过一些依申请公开渠道拿到的公文来做维基百科来源，不过我现在也在找相关部门，尽量让他们把这些公文主动公开，到时候我会更换）。——— 红渡厨（留言・贡献） 2024年6月11日 (二) 04:08 (UTC)[回复]
如果线上版本提供困难的话，或者参考脚注中引用相应文段作为引文，这样也可以方便读者进行核证。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月11日 (二) 06:20 (UTC)[回复]

如何让政区条目内的OSM地图显示政区范围（红线边界、政区区域加阴影）

我在一些政区条目中加入OSM地图，结果只显示一个地点箭头。我尝试在维基数据项目里添加该政区在OSM地图的关系标识符，结果条目中的OSM地图不仅不能显示政区范围（举例户板县 (缅甸)），结果显示范围也从正确对应的地方变成了大西洋几内亚湾的一片海域（举例户板县 (佤邦)）。而今年新建的条目勐古县，维基数据项目里没有添加OSM地图的关系标识符，也没添加其他地图的标识符，只添加了一个地理坐标，就能让条目内的OSM地图显示政区范围。请问该如何操作才能使条目中显示政区范围呢？--大化國史館從九品筆帖式（留言） 2024年6月15日 (六) 11:10 (UTC)[回复]

Template:Maplink有说明：为了能正确显示开放街图（OSM）图征，请在所对应的OSM关联输入Wikidata键值（并且等待1或2日）—更多资讯请见mw:Help:Extension:Kartographer#External_data与mw:Help:Extension:Kartographer/OSM。
也就是说要做的是在OSM那边加上Wikidata的标签，并不需要在Wikidata中填写OSM关系标识符。--Kcx36（留言） 2024年6月15日 (六) 18:13 (UTC)[回复]
谢谢。终于找到办法了。--大化國史館從九品筆帖式（留言） 2024年6月16日 (日) 11:31 (UTC)[回复]
@逐风天地：話說勐古縣其他語言版本維基百科有沒有條目？我找不到，緬甸行政區劃太亂了。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 06:29 (UTC)[回复]
没有。其他语言的条目都是以缅甸官方政区为准，而勐古县不是缅甸官方的政区，是地方政权果敢一特自设的政区。--大化國史館從九品筆帖式（留言） 2024年6月24日 (一) 08:14 (UTC)[回复]
啊，原来不是及时更新啊。。。--百無一用是書生 (☎) 2024年6月17日 (一) 02:17 (UTC)[回复]

怎么关闭结构式讨论

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

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

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

我想要上傳的圖片來源于该艺术家的个人主页网<https://www.daiweicomposer.com/gallery?lightbox=dataItem-lirkytqy1>，想要使用在Wznbfc/戴薇 （页面待审核中）[37]的艺人模板中。权限不够无法上传，请求帮助，谢谢！

--Wznbfc（留言） 2024年6月18日 (二) 17:18 (UTC)[回复]

编辑条目后，修订历史页面中，本人条目被自动挂上了不合适的标签

条目为有限单群分类，在我完成编辑并上传后，发现似乎被挂上了以下的标签：

移除维护性模板 新用户加入疑似宣传性内容 由可视化编辑器切换为wikitext编辑器 消歧义链接

  1. 移除维护性模板：我第一次点击发布后受到了编辑器警告，发现自己确实不知何时误删了{{NoteTA|G1=Math}}模板,在正确补回模板后重新进行了发布；
  2. 新用户加入疑似宣传性内容：令人费解。我感觉对原本的译文重新进行翻译并添加了大量其他相关内容算作宣传性内容不太算得上宣传性内容吧；
  3. 由可视化编辑器切换为wikitext编辑器：这个标签的存在我没有意见，因为我确实在两种编辑器之间频繁切换。
  4. 消歧义链接：原文没有消歧义链接,我的新版本也没有，这个标签的含义是？

总之，本人希望能够去掉不合理的标签，我认为这是对我所做的工作的不尊重。提前感谢拨冗给予帮助的朋友！ --Perxeonic Acid（留言） 2024年6月18日 (二) 18:08 (UTC)[回复]

@Perxeonic Acid：这些标签并非人为判定而是系统自动判定，似乎不能去除。不过就1和4，我可以给您解释：对于1而言，此前的版本有{{roughtranslation}}，而该模板被您移除，故有移除维护性模板（该模板属于维护性模板）。对于4而言，至少Conway为一消歧义页面。--ときさき くるみ 2024年6月18日 (二) 18:17 (UTC)[回复]
感谢回复！我已经更正了这一消歧义页面。--Perxeonic Acid（留言） 2024年6月18日 (二) 18:28 (UTC)[回复]

請求協助修改條目內容

請求協助根據最新活動修改洛陽鉬業條目內社會責任章節部分相關內容。謝謝！--SandroP3l（留言） 2024年6月19日 (三) 05:47 (UTC)[回复]

需要修改哪些内容？--Lihaiyue88（留言） 2024年6月19日 (三) 10:36 (UTC)[回复]
需要修改的內容在此：Talk:洛陽鉬業#請求協助增添以及刪除社會責任章節相關內容。 --SandroP3l（留言） 2024年6月20日 (四) 15:26 (UTC)[回复]

《繁花》香港收視問題

本主題或以下段落文字，在討論結束後應存檔至Talk:繁花 (電視劇)。

有關《繁花》香港收視中，提第一週平均收視11.9點，只是新浪微博的會員在TVB收視情報站的貼子上回應，而非「TVB收視情報站」的貼子上顯示出來，不過在「TVB收視情報站」中譾平均收視的只有《神耆小子》及《繁花》的雜交收視，由於我們亦無法知道《神耆小子》每週的平均收視，所以不能以最終的《神耆小子》平均收視15.9點去去判斷，留意返《繁花》收播一星期口，同時段為《神耆小子》（第6-20集）加《繁花》（第1至5集）收為14.9點，只跌了1點，而繁花收視描述的第二週平均收視10.3點更沒有來源，不過在雜交收視中《神耆小子》（第11至20集）加《繁花》（第1至10集）平均只是13.5點，亦只是跌了1.4點，論其平均收視和最高收視不會差太遠。還記得TVB劇集討論曾指出演員的IG的貼子也不可證實，無理由個普通用戶的新浪微博的回應，不過曾有連登有人回應《繁花》兩週都是14點，不過曾有一個只有樓主回應的貼子話第二週只有11.1點，因為這也無法證實消息的真確性只是從《神耆小子》的平均收視推斷出來的，不過連登有用戶把《繁花》第二週收視計出為11.1點，但後向其他用戶道歉，留意返《繁花》播映完第二週收視在記錄上以無了《神耆小子》首兩週收視，按數學上人推算要把15.9減去《神耆小子》首兩週的平均收視在加上《繁花》的兩週平均收視才等於13.9，但由於我們無法知《神耆小子》首兩週收視，亦未能知《繁花》的首兩週的收視。 理論上我們可以《神耆小子》首兩週平均收視是X點，而《繁花》首雨週為為Y點。 15.9-X＋Y＝13.5點 在數學原理上一條算式出現兩個未知數是無法計算，一定要兩個條算式才能計算，但我們找不到第二條算式。--223.19.216.143（留言） 2024年6月19日 (三) 08:14 (UTC)[回复]

請求協助上傳檔案 2024-06-20 03:27

我想要上傳的圖片來源是<https://en.wikipedia.org/wiki/Moon_landing_conspiracy_theories> --Allentownoob（留言） 2024年6月20日 (四) 03:27 (UTC)[回复]

可以直接使用文中的图片。--Kcx36（留言） 2024年6月20日 (四) 07:38 (UTC)[回复]

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

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

关于日本的著作权原创性门槛的一些疑问

我看到commons:Commons:TOO Japan内有提到，日本的著作权原创性门槛很高。日本法院裁定，“文字标志要具有版权，必须具有值得艺术欣赏的艺术外观。仅由几何形状和文本组成的徽标一般也不受版权保护”。那么类似于file:学園アイドルマスター.png这样稍微复杂一些的logo到底应该怎么算？类似这样的作品到底有没有受到日本的著作权法保护？--Awdqmb（留言） 2024年6月21日 (五) 16:33 (UTC)[回复]

对比万代南梦宫现在使用logoFile:Bandai Namco Holdings logo (2022, with tagline).svg，可能这种程度的话是允许的范围。file:学園アイドルマスター.png可能不通过，而且好像对于基于这个标准的logo文件基本上需要用svg文件制作。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 06:33 (UTC)[回复]
官方网站倒是能扒下来svg文件的版本。不过我对这个文字标志是否“具有值得艺术欣赏的艺术外观”存疑。唯一有争议的就是那个“手写”的标题。--Awdqmb（留言） 2024年6月22日 (六) 07:21 (UTC)[回复]
感觉算。对于大部分logo，除非像Google、微软等足够简单的图形结构或者单纯端正的文字，可以不归入此类，像这种艺术化文字logo应该考虑合理使用的可能优先（参考File:Mengniu.svg、File:YILI logo (2018).svg）。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 09:09 (UTC)[回复]
中国大陆的话那又是另一个话题了——大陆的原创性门槛非常低。像万代南梦宫那么简单的logo都很有可能被判有著作权。可以参考一下commons:Commons:TOO China。--Awdqmb（留言） 2024年6月22日 (六) 09:37 (UTC)[回复]
能找到的，在C区、日本企业的logo：File:Kōdansha_logo.svg、File:King_Records_logo.svg、File:Recording_Industry_Association_of_Japan_logo.svg。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 09:13 (UTC)[回复]
再不济，去c:Commons:Village_pump问，或者找User:Wcam问（专注文件版权处理）。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月22日 (六) 09:14 (UTC)[回复]

如何上傳論文研究成果

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

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

請求協助上傳檔案 2024-06-23 00:33

我想要上傳的圖片來源是<https://www.shincheonji.org/missioncenter/ceremony-photo// 自行拍攝>，想要使用在新天地耶稣教证据帐幕圣殿的<資訊框/第三個段落，用圖片進行說明>。 --Stary blue（留言） 2024年6月23日 (日) 00:33 (UTC)[回复]

模板的命名規則？

請問是否有具體的模板命名規則（Template:XXXX）？我在維基百科:非條目頁面命名沒有看到什麼具體的說明，倒是其討論頁似乎對非條目頁面命名還有看到一些爭論。因為我在英文維基建立的模板en:Template:Numbered block，原本應該是叫「NumBlk」，但後來被其他人改為「Numbered block」，而另外因為這個問題最近也有考慮在中文維基的模板空間建立新頁，所以才想確認一下。之後若新的模板頁面在中文維基建好後，有可能會複製到英文維基裡。--Justin545（留言） 2024年6月23日 (日) 03:27 (UTC)[回复]

据我所知没有规则，但是我觉得应该要有。--碟之舞📀💿 2024年6月23日 (日) 03:47 (UTC)[回复]
而且牽扯到誇語言的時侯，又更複雜了。看來可能是要先求有再求好了，先依自己的意思命名，不好的話再改名了。--Justin545（留言） 2024年6月23日 (日) 04:13 (UTC)[回复]
无条文，基于常识、寻求共识。--YFdyh000（留言） 2024年6月23日 (日) 04:54 (UTC)[回复]
英維我不知道，但法維在這方面相當講究。舉例說明：所有使用{{navbox}}的模板，其名稱都必須以「Modèle:Palette」開頭。📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年6月23日 (日) 05:57 (UTC)[回复]
個人看法：有無命名規則各有利弊，我想主要是方便記憶。用序號或hash命名簡單，但名稱難記。想名稱也是需要腦力和時間，但好的名稱好記又不易搞混。另外，名稱過長，在名稱的輸入上也是一種困擾。名稱再怎麼長，也很難長到能把模板的說明文件裡所有的資訊都包含進去。也許把模板的說明及分類樹Special:CategoryTree做好會比較有意義。--Justin545（留言） 2024年6月23日 (日) 08:53 (UTC)[回复]

請求協助更新ISO 4217

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

已在Talk:ISO 4217掛editprotected幾天仍未有人處理。請根據en:Special:Diff/1230093973提供的來源，把津巴布韋金（ZWG/924）加入至現行代碼。--132.234.228.219（留言） 2024年6月24日 (一) 02:18 (UTC)[回复]

完成。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 06:14 (UTC)[回复]

請求協助上傳檔案 2024-06-24 23:21

我想要上傳的圖片來源是<從某個網址下載，請提供網址 / 自行拍攝>，想要使用在請提供條目名稱（如果条目还不存在，请先建立条目再请求上传文件）的<資訊框/某個段落，請說明>。 --Elysiumco（留言） 2024年6月24日 (一) 23:21 (UTC) 我想要上传我们公司的logo图片，来源是我们自己设计，条目正在建立[回复]

請求協助上傳檔案 2024-06-25 04:18

我想要上傳的圖片來源是<https://www.twse.com.tw/zh/index.html>，想要使用在臺灣證券交易所的<臺灣證券交易所商標，用最新的logo取代舊的>。 --Limpiz（留言） 2024年6月25日 (二) 04:18 (UTC)[回复]

新商標的圖片連結如下，敬請協助:
https://drive.google.com/file/d/1fG79U7F1_n0K_Vt-lvcoay87VVgnn345/view?usp=sharing--Limpiz（留言） 2024年6月25日 (二) 07:04 (UTC)[回复]

身份被冒用

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

您指？--HeihaHeihaHa-麻瓜了……（留言） 2024年6月25日 (二) 16:58 (UTC)[回复]
查編輯歷史，人家是1917年—1995年的人，怎麼冒用你的名義？--桐生ここ★[讨论] 2024年6月26日 (三) 00:07 (UTC)[回复]

請求協助上傳檔案 2024-06-26 03:35

我想要上傳的圖片來源是<File:Timezone-9.30.png>，想要使用在模板:User UTC-9:30的<File:Timezone-9.30.png>。 --我是半见町（留言） 2024年6月26日 (三) 03:35 (UTC)[回复]

更换图片

非自由图片可以上传新图片替换吗？比如中国工程院的院徽File:Chinese Academy of Engineering.jpg（旧版）已更换新版徽章（新logo网址，文件扩展名为png）。--Kethyga（留言） 2024年6月26日 (三) 05:42 (UTC)[回复]

@Kethyga：作用相同，應直接上傳新版本即可。機器人會自動刪除過往不再使用者。除非舊版標誌也同時有需要用到。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 09:42 (UTC)[回复]
“文件扩展名“.jpg”与检测到的文件MIME类型（image/png）不匹配”，似乎不能直接替换。--Kethyga（留言） 2024年6月27日 (四) 02:54 (UTC)[回复]

請求協助上傳檔案 2024-06-26 11:14

我想要上傳的圖片來源是< 自行拍攝>，想要使用在永明金融的<這是一個企業、組織、政府或其他形式團體的標誌，在永明金融集團股份條目中使用。>。 --Cwong094（留言） 2024年6月26日 (三) 11:14 (UTC)[回复]

导航框过长

见2018年热带风暴伊莱亚娜底部的导航栏Template:2018年太平洋颶風季，把右侧的工具列都挡住了--百無一用是書生 (☎) 2024年6月27日 (四) 03:08 (UTC)[回复]

飓风季导航模板的内容是用表格排布的，每行的长度、单元格数量固定，旧vector、vector-2022不打开工具栏右侧就没问题，宽度足够。但打开工具栏后就变得太窄，而且没有实现响应式重排单元格。要看一下怎样改造飓风季导航模板的元素动态排布。———Sakamotosan路过围观 | 避免做作，免敬 2024年6月27日 (四) 03:42 (UTC)[回复]
发现不少导航框都有类似问题，但造成问题的原因似乎不一。例如Template:阿拉伯世界就是注脚处的nowarp造成的--百無一用是書生 (☎) 2024年6月27日 (四) 04:10 (UTC)[回复]
响应式可参考[38]--百無一用是書生 (☎) 2024年6月27日 (四) 04:14 (UTC)[回复]
在屏幕低分辨率下，旧vector一样有问题，现在的width撑开为997px。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月27日 (四) 03:45 (UTC)[回复]

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

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

調用重複模板參數小工具

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

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

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

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


條目探討

闽方言条目命名

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

移動條目「王守仁」至「王陽明」

本主題全部或部分段落文字，已移動至Talk:王守仁。执行人：路西法人 2024年6月26日 (三) 08:27 (UTC)。[回复]

Talk:王守仁 § 建議更名：“王守仁”→“王陽明”有用戶正在徵求社群意見，敬請編者關注。

簡要說明：「王陽明」遠比「王守仁」一名通行，「王守仁」是否應移動至「王陽明」？正如中維用「王重陽」而不用本名「王喆」，用「章太炎」而不用本名「章炳麟」，用「孫中山」而不用本名「孫文」或「孫逸仙」。--Banyangarden（留言） 2024年5月31日 (五) 17:23 (UTC)[回复]

--路西法人 2024年6月26日 (三) 08:27 (UTC)[回复]

關於「Iberia」這一航空公司的法定名稱

本主題全部或部分段落文字，已移動至Talk:西班牙國家航空。执行人：路西法人 2024年6月26日 (三) 08:34 (UTC)。[回复]

Template:Cite act

模板Template:Cite act理论上来说应该可以用语中国大陆和台湾的政府公文（法律性质的文件，包含发文字号），但是其目前的格式和中文习惯差异比较大，不知道如何适应中文，又或者比较适合单独建立一个新的？--Kethyga（留言） 2024年6月8日 (六) 05:22 (UTC)[回复]

话说……一般中文文献引用法律是用什么样的格式？《信息与文献 参考文献著录规则（GB/T 7714—2015）》里没有提到法律。似乎法律相关论文中引用法律也有自己特殊的格式（如[42]）--自由雨日（留言） 2024年6月8日 (六) 05:49 (UTC)[回复]
感觉不太容易兼容多语言。参数看上去不错，但单独一套模板和规范、手动整理，目前确有必要吗。--YFdyh000（留言） 2024年6月8日 (六) 06:07 (UTC)[回复]
单独的话，en:Category:Law citation templates有不少美国之外的法律引用模板，中文Category:法律引用模板也有几个，不过相对少。《法学引注手册》中，法律条文相对适合{{cite act}}，规范性文件（或其他文件）似乎不太适合。用模板主要是为了统一风格和统计，实际不用任何模板都可以。--Kethyga（留言） 2024年6月8日 (六) 06:32 (UTC)[回复]

我觉得引用法律的话直接在维基文库里找然后引用维基文库就好，用{{cite wikisource}}，别的地方我不太清楚，但中国大陆的国家层面的法律法规，文库基本上都是全的。——— 红渡厨（留言・贡献） 2024年6月11日 (二) 03:54 (UTC)[回复]

维基文库是否属于可靠来源？（之前就遇到过维基文库版本和辞典书证版本中引文不一致的情况，当然当代法律一般是不会不一致。）--自由雨日（留言） 2024年6月11日 (二) 03:57 (UTC)[回复]
以前在互助客栈我记得聊过这个问题。维基文库本质上属于图书馆，问图书馆是否属于可靠来源其实是一个无解的问题，应该具体判断图书馆里的图书是否属于可靠来源。--——— 红渡厨（留言・贡献） 2024年6月11日 (二) 04:14 (UTC)[回复]
我的意思主要是从维基文库这一图书馆是否“忠实反映图书原文”的角度去判断它是否“可靠”。比如之前在马达加斯加条目，上海辞书出版社的《近现代汉语辞源》中引文中梁启超《新民说》中用“马达加斯”一译，但维基文库中却用的是“马达加斯加”（其他文字也略有出入），我认为维基文库的“可靠性”是低于正式出版物的。--自由雨日（留言） 2024年6月11日 (二) 04:22 (UTC)[回复]
所以我说“具体判断图书馆里的图书是否属于可靠来源”嘛，有些用户确实在维基文库上传文献时不仔细不认真，拿来当来源确实不好。不过维基文库一样可以改，碰到这种情况我觉得可以顺便把文库里的这个错误给改掉，这样你在引用时就是正确的。再就是，既然存在{{cite wikisource}}这个模板（不仅是中文，其他好多语言版本都有），本质上表示社群认可将文库作为来源。--——— 红渡厨（留言・贡献） 2024年6月11日 (二) 04:33 (UTC)[回复]
哦，原来您本来就是此意。我觉得“判断图书馆里图书是否可靠”这一比喻容易让人误会成判断文献本身的“内容”是否可靠，可能“判断图书誊抄出版过程是否可靠”之类的会更好些，更突出可靠性会发生问题的重点（也就是录入文库这一“程序”）。（尤其是古代的图书出版，没有印刷机，纯誊抄，就很类似现在的“录入文库”这一行为。）另外，提到文库的可靠性问题，可以ping一下“马达加斯加”词源内容当时的主编@Allervous。--自由雨日（留言） 2024年6月11日 (二) 12:20 (UTC)[回复]
中國哲學書電子化計劃提供含原文影印本的文獻，可能會比維基文庫更可靠。而英文維基文庫有些書籍透過.djvu格式的影印本檔案，大概可以保障「忠實反映圖書原文」，建議中文維基文庫參考一下。--Allervous初音ミクのセーラー服 2024年6月11日 (二) 13:15 (UTC)[回复]
使用{{cite wikisource}}可以，用{{cite website}}或其他模板也可以，这里是想讨论出一个比较符合实际应用或法学引用的格式。平时引用习惯“标题（发文字号）”，这里的“发文字号”在这几个模板中目前似乎只能和标题放一块，“发文字号”独立一个参数比较好。--Kethyga（留言） 2024年6月12日 (三) 01:55 (UTC)[回复]
直接在模板里加“发文字号”的参数？--——— 红渡厨（留言・贡献） 2024年6月12日 (三) 02:33 (UTC)[回复]
不建議。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 14:07 (UTC)[回复]
我推測{{Cite act}}預設是來引用普通法（相對於大陸法而言）下的法規、法令、法案、條例等的（雖説引用大陸法的法規、法令、法案、條例等應該也沒問題），因此以這模板來引用公文（而非法規、法令、法案、條例等）自然水土不服。現時不存在任何一個專門引用公文的引用模板，我個人推薦在wikisource有文本的時候引用wikisource，其他情況下使用{{Cite report}}（有分卷、期的話也可以使用{{Cite journal}}）。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 14:07 (UTC)[回复]
{{cite wikisource}}无法体现发文字号，{{cite report}}会在标题后加上“（报告）”。--Kethyga（留言） 2024年6月26日 (三) 05:21 (UTC)[回复]

條目名稱 命名一致性

請問下列條目的名稱是否可按NC:一致性統一一下?

有關Iowa戰艦還有一個小問題，已於技術版提出但獲告知應移至此討論。簡單來説，Iowa的簡中似乎應爲“艾奥瓦”，繁中為“愛荷華”，所以未知以繁體“艾奧瓦”命名是否合符規範。另這些題目的字詞轉換可能需調整一下。--惣流 明日香 蘭格雷不姓 式波 2024年6月10日 (一) 02:21 (UTC)[回复]

請看註一「 使用地區詞處理至一致也算作一致」。奧花=奥普拉，所以就是符合一致性。--Nostalgiacn（留言） 2024年6月10日 (一) 02:38 (UTC)[回复]
額那個註完全可以寫在同一行吧。。。那請問“艾奧瓦”使用繁體“奧”，以及繁體標題使用簡體地區詞會否視作違反繁简统一？--惣流 明日香 蘭格雷不姓 式波 2024年6月10日 (一) 05:16 (UTC)[回复]
艾奧瓦+號戰艦（中國大陸譯名繁化+其他）如何判斷，有點卡bug，個人不太清楚這個情況如何處理。--Nostalgiacn（留言） 2024年6月10日 (一) 05:40 (UTC)[回复]
如果某一简体用词在繁体世界也不算罕见个人认为可以予以保留并在NoteTA里写成：zh-hans:艾奥瓦; zh-hant:艾奧瓦; zh-tw:愛荷華...。反过来亦同理。--微肿头龙（留言） 2024年6月10日 (一) 08:08 (UTC)[回复]
我对“使用地区词处理至一致也算作一致”的理解为：为了使某一主题下的所有条目命名一致，可以将所有页面统一至某一地的用词而不考虑先到先得的问题。--微肿头龙（留言） 2024年6月10日 (一) 08:04 (UTC)[回复]
「所有页面统一至某一地的用词」絕對違反另一個指引地區詞。
題外話，「一致性」這個原則，是很後期才有的， 2021年5月才通過，而且備受爭議。大部分編輯都在明裡暗裡地不合作抗議，通過次月就被提出刪除（1）， 2023年7月的修訂也可以看到有部分人不滿這個做法，最終降低了這個規則的使用方式，從略帶強制的「技術上」變成「命名慣例」。（2）
實施前很多條目都不跟這個做法，追溯過去內容，會發現很多衝突的情況。由於潛在反對聲音很多，所以沒有出現從者如雲，普遍推行的情況。--Nostalgiacn（留言） 2024年6月10日 (一) 08:28 (UTC)[回复]
我觉得可能是为了方便分类？比如说Category:2011年发现的系外行星为例，当中有一大堆开普勒和克卜勒，分类排序起来应该会很麻烦，除非直接用Kepler作为默认排序。或者是可能会遇到地区词混乱，统一至某一地用词有助于正确实现地区词转换的情况（虽然我不知道什么时候会有这样的情况）。如果可以进一步为各个专题设立自己的“命名一致”规则应该可以达到更好的效果。--微肿头龙（留言） 2024年6月10日 (一) 08:55 (UTC)[回复]
不對吧？是無論用什麼技術手段處理，祇要顯示（給讀者的）結果「看起來一樣」就好。大概正好與您說的相反。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月11日 (二) 15:27 (UTC)[回复]
可能我们对条文的理解的方式不一样吧。--微肿头龙（留言） 2024年6月11日 (二) 15:35 (UTC)[回复]
因為除少數技術限制外，僅僅為了實現某種用詞而移動條目或變更內容，正可能構成繁簡或地區詞破壞，同相關方針與指引之精神相違。所以我想大概是相反的。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月11日 (二) 16:25 (UTC)[回复]
如果不利于地区词转换的话，可以考虑移动标题。--东风（留言） 2024年6月10日 (一) 05:51 (UTC)[回复]
最初我正是遇到這個問題。
例如奧花·雲費的條目，#早年的第二段中的“奥普拉·温弗里秀”，中港臺三地的轉換都令節目名和人名不一致。
我修改前的姊妹舰歷史版本，#军用例子寫著“愛荷華號戰艦 (BB-61)、...共同組成衣阿華級戰艦”，我不知道大陸該用艾奥瓦還是衣阿华，反正就該一致，港臺版同理。--惣流 明日香 蘭格雷不姓 式波 2024年6月10日 (一) 06:14 (UTC)[回复]
艦隊名稱源於美國地名，美國各地翻譯有轉換組，你可以參考裡面的翻譯。--Nostalgiacn（留言） 2024年6月10日 (一) 06:24 (UTC)[回复]
這我知道，但不知爲何例如百度百科雖然寫艾奥瓦州，但寫依阿华级战列舰。原因我不深究，反正至少維基的船級和艦名應一致。--惣流 明日香 蘭格雷不姓 式波 2024年6月10日 (一) 06:33 (UTC)[回复]
2005年的資料已經是依阿华级战列舰（[43]），當然中維條目是2004年建立的，不排除是循环引用。--Nostalgiacn（留言） 2024年6月10日 (一) 07:57 (UTC)[回复]
進一步查找資料，1994年的中國大陸軍事雜誌已經使用“依阿华”级战列舰（[44]）的說法，可能是為了區分地名和戰艦，以采用了不同譯名。這個情況不適用於「一致性」。只是單純的譯名問題。
PS：對比查證「艾奥瓦级战列舰」在知網沒有搜索結果。--Nostalgiacn（留言） 2024年6月10日 (一) 08:03 (UTC)[回复]
“依阿华”/“衣阿华”在战舰中适用于约定俗成，后出现的“艾奥瓦号”相关新闻不排除是直接套用iowa的中文地名。这里面的战舰名和州名要分开讨论。--东风（留言） 2024年6月10日 (一) 08:57 (UTC)[回复]
对于一致性的要求，我倾向认为是同主要类型（例如：衣阿华级战列舰、艾奧瓦號戰艦 (BB-61)、艾奧瓦號戰艦 (BB-4)可以归为主要类别是战舰）或者关联性衍生（例如：作品条目及其衍生列表条目等）条目有这个需要。对于奧花·雲費、奥普拉·温弗里秀，可能是编写时用字模式选择导致有差异（在oldid=64924556版本，一致性原则不存在，对于名从、常用冲突的处理是先到先得原则）。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月11日 (二) 06:13 (UTC)[回复]
「命名一致性」原則問題很多，而且定義模糊。最近才又見到相關案例。我認為相關方針與指引實在很有商榷的必要，此原則一般而言應該僅局限於經社群個別商討確定的個案。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月11日 (二) 16:27 (UTC)[回复]
分類名稱指引相關內容也需要調整，明確保留原則。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月11日 (二) 16:38 (UTC)[回复]
依我簡單研究後的理解，NC:一致性所管的主要為“格式”而非“用字”，所以其實應該不適用於此討論串。假設屬實，我所列的條目的用字不一致有否違反任何規定？
  • 假設有，是否需統一，如何統一
  • 假設無
    • 可否統一，如何統一
    • 有否需要增設相關指引
奧花·雲費、奧普拉·溫弗里秀的問題，其實在奧普拉·溫弗里秀的頁面補個noteTA就應該可以解決了，該系列戰艦的問題同理。問題在於：
  1. 於其他條目使用這些命名不統一的字詞時（例如姊妹舰），很大機會是不會加noteTA的，這就轉換不了，問題並未解決
  2. 繁體艾奧瓦等情況，尤其是不屬於“簡體用詞在繁體世界也不算罕見”的情況者，如何處理
--惣流 明日香 蘭格雷不姓 式波 2024年6月12日 (三) 02:50 (UTC)[回复]
技術上來說沒有，由於其他條文的影響（NC:先到先得），除非是遇到地域詞轉移問題，否則建立條目時如何，之後也如何，就是上面Easterlies提到如果不利于地区词转换的话，可以考虑移动标题。
我看到艦隊轉換組，艾奧瓦號戰艦是香港地區譯名。個人不熟悉相關領域，無法判斷。若艦隊轉換組內容為真，現在已經是地域詞形式上的「一致性」。--Nostalgiacn（留言） 2024年6月14日 (五) 07:44 (UTC)[回复]
命名一致性條文訂明「使用地區詞處理至一致也算作一致」，排除地區詞差異，故不追求統一至同一地區詞。同一事物在一篇文章中的不同名稱：若應包含在轉換機制之中，即為任何一地可靠來源最常用用詞及字形，則不作修改，不必強求一致；若不應包含在轉換機制之中，即不屬任何一地可靠來源最常用用詞及字形，一般則需改爲任何一地可靠來源最常用用詞或增設針對同一事物的兩層或多層轉換，以使任何一地用字模式恰當轉換並正確展示用字。但若有名稱在所有6地都常用但皆非最常用，則不必修改；不過這種巧合不多，更有可能出現某個名稱在1地最常用、3地常用、2地罕見等情形，仍需修改用字或增設多層轉換以照顧後2地轉換效果。--— Gohan 2024年6月16日 (日) 02:36 (UTC)[回复]
这篇文章里的内容可以参考一下（虽然作者是自媒体）：https://i.ifeng.com/c/8WebW2hOuBA 标题：“从“爱我华”到“衣阿华”再到“艾奥瓦”，这个州都经历了什么”--桃花影落飞神剑（留言） 2024年6月15日 (六) 15:45 (UTC)[回复]
主要的關聯到地區詞處理、常用名稱等概念。譯名的會試著時間和傳播改變的，嚴復早期將telephone翻譯作「德律風」，最後流行的是「電話」。譯名可以溯源，但在本話題作用不大，重點的當前的各地譯名。--Nostalgiacn（留言） 2024年6月16日 (日) 01:18 (UTC)[回复]
借用电子游戏命名方针的思路，这个问题可以倒过来考虑：每篇条目理论上要分别维护6个标题，即zh-cn、zh-hk、zh-mo、zh-my、zh-sg、zh-tw标题。然后确定标题时，每个用字都应该按照WP:NAME来跑一轮，分别得到各自的最优标题。具体到Po主的问题，就是Oprah在zh-cn标题中有没有统一命名为「奥普拉」，在zh-hk区域中又是否统一译作「奧花」？
至于条目的实体标题（即zh），应该是上述六个标题之一。但是zh只能有一个，那就跟着创建时版本的用字走，这样「先到先得」也是标准一致，谁都不会有意见。这样zh就成了纯粹的技术性id，对读者来说不再有实际意义。而且现在小工具对zh用字会有驱离提示，也算明确表示zh不是给读者看的
这样来看，很多时候要讨论的是条目字词转换，而不是条目标题本身。毕竟读者看的是转换标题，而不是实体标题。例如认为要某地的标题需要修改，但又觉得有争议，那就应该比照移动请求的规格来申请。如果而实体标题正好是该地区，那就条目自然会随转换规则的修改而移动😂--For Each element In group Next（留言） 2024年6月17日 (一) 12:19 (UTC)[回复]
PS：地区词和简繁转换问题要分开。首先明确一个问题：在条目正文里用简体打hk/mo/tw地区词，或用繁体打cn/my/sg，是否算不佳做法？如果答案是「算不佳做法」，那我们就考虑这种正文打繁体字（简体字），但用词却和cn/my/sg（hk/my/tw）标题相同的情况：
  • 繁体字打的词在hk/my/tw某地最常用，只是对应的转换规则不对。这自然应该修改转换规则，没什么可说的。
  • 繁体字打的词在hk/my/tw某地较常用。此时可以认为用词对该地合适（就像乙醇条目里也可写「酒精」），亦即不用附加转换规则。
    • 如果其他地区罕用该词，则可以附加单向转换，映射到该地最优名称（一般为该地条目标题）。
    • 当然处于用词一致性和维护便利的考量（特别是专名词），也可以直接修改源代码来配合转换组。
  • 繁体字打的词在hk/my/tw全都不常用，这可能是早期编者复制标题时，条目还没有定义地区词转换规则。这算输入不佳，应该直接修改源代码（或者转简繁体，或者简繁不变而改换用词）。
但是关键在于，一般编者可能只熟悉当地用法，如何给其他地区的用法背书😂--For Each element In group Next（留言） 2024年6月17日 (一) 13:49 (UTC)[回复]
我個人的想法是，簡體區用詞用簡體寫，繁體區用詞用繁體寫。技術上，若不依照此原則，（可能）會影響地區詞轉換的匹配，具體結果就是轉換失敗。
假設有組詞的轉換為“cn:cn; my:my; sg:sg; hk:HK; mo:MO; tw:TW”，小寫為簡，大寫為繁。若今天有人寫了“CN”，甚至“Cn”或“cN”，系統能正確轉換嗎？如無其他相應轉換規則，應該會顯示成“cn/my/sg:cn; hk/mo/tw:CN”吧。完善轉換組（對應簡區常見繁詞、繁區常見簡詞）可能可以涵蓋“CN、MY、hk、mo...”等情況，但也處理不到“Cn、mY、Hk...”，除非。。。
若系統無法處理，就只能 1）改良轉換系統 2）避免情況--惣流 明日香 蘭格雷不姓 式波 2024年6月18日 (二) 03:58 (UTC)[回复]
「Wikipedia:地区词处理」序言就有说中国大陆（zh-cn）、新加坡（zh-sg）及马来西亚（zh-my）的地區詞使用简体中文；台湾（zh-tw）、香港（zh-hk）及澳门（zh-mo）的地區詞使用繁體中文。违反这个原则是会影响转换规则运作，极端的案例就是快打旋风，简繁用错就直接GG。但是「地区词处理」藏的比较深，很多人注意不到。而命名常规又只规定了繁简统一，没有讨论地区词问题；Wikipedia:命名常規_(日本動漫遊戲條目)最底部是说X体区有X体标题的问题，但这又只是个领域方针😂--For Each element In group Next（留言） 2024年6月18日 (二) 06:50 (UTC)[回复]

现在Wikipedia:命名常规的框架可能不好。现行命名常规指出：「条目命名都应当首先使用大多数中文用户最容易理解、最不容易混淆的文字」。这句话指「条目实体标题是全球大多数中文用户最容易理解的问题」，这就比较有问题：一方面我们字词转换，就是因为这点很难做到；另一方面读者也看不到实体标题，争这个「中文界最优标题也没有意义」😂。可能我们是参考英维，但英维是没有地区词转换问题的。我想在中维，这句话的含义是「条目各转换标题是该区域大多数中文用户最容易理解的问题」。

虽然说从读者角度，只要转换标题正确就ok；但是实体标题终归是存在的，从编者角度也不能不讨论。这里举几个例子：

  • zh-Hant-CN/zh-Hans-TW式输入影响转换规则，是否应该禁止？目前命名常规只说繁简统一，这应该就是只考虑无地区词差异条目的结果。
  • 「快打旋风」有段时间简繁标题的内容不同：简体导向街頭快打系列（大陆指Final Fight），而繁体快打旋風是消歧义页（香港指Final Fight，台湾指Street Fighter）。这种做法好处是方便使用简体的大陆读者，但坏处是麻烦了简繁不敏感的用户。所以只有简繁（非地区词）差异的标题是否应该视为一个？
  • GUNDAM系列实体标题用英文，再通过「原文：GUNDAM；大陆：高达；臺灣：鋼彈；香港：高達；」将各地标题转换为中文。这种「实体标题以外语中立，各地标题通过转换解决」的做法ok吗？
    • 更广义地说，如果实体标题和所有地方的用字都不同，我们先假定各地转换标题是正确的，那这个和任意一地的最优标题都不同的实体标题为何会符合命名常规？
  • 地区词有分歧时，选择哪个词语做实体标题不会吵架？（目前的做法是WP:先到先得）

由此可见，实体标题和转换标题也是紧密相连的。就如同我上面举的例子：对于有地区词差异的主题，zh-cn等转换标题如何判断，实体标题又该如何选择；对于没有地区词差异的主题，标题又该如何选择？这是一个高屋建瓴的问题，只在「命名原则和惯例>其他命名慣例>先到先得」这个角落谈就很low了。将章节应该改组成大标题「== 实体标题与转换标题 ==」放在「== 命名原则和惯例 ==」前，先讨论要不要处理地区词，如果要处理地区词，再根据命名原则敲定各地最优标题，这才是正常的顺序。相信这样做，包括po主提到的一致性问题在内，许多问题会有更清晰的解说--For Each element In group Next（留言） 2024年6月18日 (二) 08:28 (UTC)[回复]

奧普拉·溫弗里秀的問題，我細看一下原來是内文源碼有簡繁混用，問題不大。
Iowa的情況，稍微瞭解了一下，我想法如下：
州的條目問題不大，戰艦的話應該要處理一下。
  1. 現時繁體艾奧瓦是Module:CGroup/Shipname内的香港地區詞。
    • 小弟是香港人，對此表示懷疑。
  2. 網上簡單搜尋相關戰艦，香港用的較多是與Module:CGroup/USState一樣的愛荷華。
  3. 大陸地區詞的話，艦名應爲“衣阿華”，BB-4的標題轉換要改一下。
  4. 這些都改完之後，再看看相關頁面，届時繁體艾奧瓦將不存於轉換組，全部繁體艾奧瓦須改成合適的地區詞。
  5. 網上找資料時，看到一個nga帖子，4樓表示“爱奥瓦，我国称呼这个农业州一直都是这个名字”，應爲玩笑，但一搜，我瞬間崩潰。
--惣流 明日香 蘭格雷不姓 式波 2024年6月25日 (二) 05:08 (UTC)[回复]
@Cwek@Easterlies@Ericliu1912@For Each element In group Next@Nostalgiacn@微肿头龙@桃花影落飞神剑@神秘悟饭請教各位大佬小弟以上思路是否可行？繁體艾奧瓦和愛奧瓦的問題可能可以用bot全部改掉？（漏了說明，繁體艾奧瓦當然是等確定艦名再處理，但地名按現時轉換組應該可以直接改掉？）--惣流 明日香 蘭格雷不姓 式波 2024年6月26日 (三) 12:28 (UTC)[回复]
涉及地區詞者，需要更多商議。尤其需要來自香港方面的意見。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 13:14 (UTC)[回复]

重要：涉及限制互助客棧條目探討區討論之政策修訂（續）

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

2024全球大選年條目

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

2024過了快一半，會選行大選的國家也有一半已得出結果。我個人感覺,未來數年的世界大事很大可能都會回溯本年的選舉結果。而且有些選舉可能在國際局勢下是彼此呼應的。請問是否可以就媒體的整合性報道，將各國的選舉脈絡在同一條目中作整合性敘述？還是要等到所有選舉都有結果後再進行？還是這比較適合寫成列表而非條目？還是這種作法根本多餘？還是這種作法別有居心，刻意拔高競爭性選舉的重要性？--2603:8000:500:FB00:10E1:2CFB:E07C:4489（留言） 2024年6月14日 (五) 17:47 (UTC)[回复]

需要有媒体或者学者对「2024全球大選年」这个概念具体报道或者研究，以符合关注度和非原创研究的要求。单独的「2024年大选」条目似乎没什么收录意义。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月15日 (六) 12:24 (UTC)[回复]
至少目前有多个媒体提出过这个概念。（[46][47])--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月15日 (六) 12:37 (UTC)[回复]
至少有多家媒体提过这个概念。（半岛中文[48]《纽约时报》中文[49]）--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月15日 (六) 12:42 (UTC)[回复]
其實至多寫在2024年裡面就足夠了吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 10:57 (UTC)[回复]

为什么维基百科随机条目很多都是名不见经传的小地方？有存在的价值吗？

甚至很多写的“面积和人口皆未知”，这样的条目有没有必要存在？--Givl（留言） 2024年6月15日 (六) 15:44 (UTC)[回复]

参见WP:关注度。另外，根据统计学规律，越不知名的小地方，乃至越不知名的事物随机出现的概率越大。--自由雨日（留言） 2024年6月15日 (六) 15:47 (UTC)[回复]
@SickManWP：这些美国地名条目大多都是SickManWP君的副账号Dawson783建的。倒也没有说“很多”，Dawson783也就建了三万个左右，大概占全体条目的2%吧。
维基百科按照一种称作关注度的标准判断是否应该收录一件事物。有关注度的主题即可收录，否则则不应收录。具体的关注度标准您可以点进链接去看，不过中文维基百科有一条关注度原则，即“法律上认定的有人居住地区都具有关注度”。所以许多行政区划，无论人口面积多少，理论上都符合中文维基百科的收录标准。
虽然我不是很了解SickManWP君具体操作方法，不过简单来说这些条目都是（半？）自动建的，从美国地质调查局的数据库里调出记录上的地名，坐标，等等信息，即可按照类似的模板建出一批条目。很多美国地名条目写的“面积和人口皆未知”，即是因为数据库中没有包含该定居点这些信息，不是说此地偏远到甚至世间无一人了解其面积和人口。
您要问“这样的条目有没有必要存在？”我会说它们“可以存在”。维基百科并不限制条目数量。不过说到这个，不知道是不是条目模板没有更新，他用的参考文献链接https://geonames.usgs.gov/可能是过时了，点进去无法看到具体定居点的数据，而是被重定向到该部门介绍页。所以这些条目几乎全都有违WP:V。建议SickManWP君修复一下。Irralpaca（留言） 2024年6月15日 (六) 16:23 (UTC)[回复]
美國地名條目的人口只要查人口普查資料即可知。--歡顏展卷（留言） 2024年6月15日 (六) 16:33 (UTC)[回复]
若要修復GNIS連結顯示錯誤，需要編輯Template:Cite GNIS內的連結，該模板因使用頁面過多而被模板保護，需要模板編輯員改動，本人流下了沒有權力的淚水。美國地質調查局於2021年用了新連結，英維早就改了，中維到現在也沒改。我早就在去年12月提出要改那個模板，結果不了了之。只要該模板按照英維版修改相應連結，便能正確顯示相應的資訊頁。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月15日 (六) 16:53 (UTC)[回复]
想不到还有这样的苦衷 囧rz……Irralpaca（留言） 2024年6月15日 (六) 16:56 (UTC)[回复]
你说什么？--MilkyDefer 2024年6月15日 (六) 17:18 (UTC)[回复]
顯而易見是在說過去請求模板跟隨英維更新，但是至今沒有消息。（Template_talk:Cite_gnis#Cite_GNIS）也許直接在WP:VPT會快一點？--Nostalgiacn（留言） 2024年6月16日 (日) 01:25 (UTC)[回复]
@SickManWP：沒有特別提出編輯請求或在客棧持續求助，其實很難有人注意。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月16日 (日) 04:25 (UTC)[回复]
了解，我這就去VPT請求修改該頁面。已於VPT提出請求。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月16日 (日) 05:06 (UTC)[回复]

GNIS模板的問題已經修復。目前本人建立的所有條目都能正確連結到對應的資訊頁。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月18日 (二) 09:03 (UTC)[回复]

「中國國民黨」條目算不算「WP:CTOP/CSRPS」？

本主題或以下段落文字，在討論結束後應存檔至Talk:中國國民黨、Wikipedia talk:高風險主題/臺灣海峽兩岸關係及政治地位。

儘管目前中國國民黨已因為「WP:CTOP/1945TWP」被無限期半保護，但我不認同本條目適用WP:CTOP/CSRPS，如果依這樣的邏輯來看，「中國共產黨」是否也要納入「WP:CTOP/CSRPS」？歡迎參與討論。--Sinsyuan✍️🌏🚀 2024年6月17日 (一) 00:54 (UTC)[回复]

中共也應該納入吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月17日 (一) 06:35 (UTC)[回复]
私以為兩者皆應納入高風險主題。--Rice King 信箱 · 留名．邊緣人 2024年6月17日 (一) 09:27 (UTC)[回复]
我不認為按「邏輯」類推是個好主意，按實際需求決定才是正確的處理。Sanmosa Snipe–Clam Grapple 2024年6月17日 (一) 23:27 (UTC)[回复]
同意。按編輯戰、破壞的歷史決定。--歡顏展卷（留言） 2024年6月17日 (一) 23:32 (UTC)[回复]
當然，如果從你説到的因素來看“中国共产党”條目確實有無限期半保護的必要性的話，我倒是不反對無限期半保護該條目，我反對的是且僅是以按「邏輯」類推為理由。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 13:53 (UTC)[回复]

关于以“大兴国际机场”为名的类似乡级单位

本主題全部或部分段落文字，已移動至Talk:大兴国际机场 (类似乡级单位)。执行人：路西法人 2024年6月26日 (三) 09:09 (UTC)。[回复]

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

本主題全部或部分段落文字，已移動至WP:VPT#美国县级行政区地图显示故障。执行人：路西法人 2024年6月26日 (三) 08:19 (UTC)。[回复]

香港車輛號牌使用{{CURRENTMONTH}}時日期格式違反MOS:DATE

本主題全部或部分段落文字，已移動至Talk:香港車輛號牌。执行人：路西法人 2024年6月26日 (三) 08:16 (UTC)。[回复]

Category:連橫家族

本主題全部或部分段落文字，已移動至Category talk:連橫家族。执行人：路西法人 2024年6月26日 (三) 08:15 (UTC)。[回复]

電視劇演員名單序列

本主題全部或部分段落文字，已移動至WP:VPP#電視劇演員名單序列。执行人：路西法人 2024年6月26日 (三) 08:03 (UTC)。[回复]

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

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

台灣是個擁有許多族群的地區，包括使用台灣南島語言為主的台灣原住民族和使用包括各種漢語、日語、越南語、印尼語、泰語、英語等移民語言的移民族群，雖然目前屬於移民後裔的台灣閩南人是台灣最大的族群，但是將「台灣閩南裔相關人事物」排他性的僅以「台灣」冠名，例如：將「台灣的閩南式料理」冠以「台菜」之名，忽視台灣料理同樣也涵蓋許多 非(non-)閩南菜色；以及將「台灣的閩南話變體」冠以「台語/台灣話」，忽視閩南話並非台灣的原生語言、族際通用語言，並且使得台灣的原生語言--台灣南島語言，竟然淪為被客體化、邊緣化的名稱，是否應當如此避免此類福佬沙文主義的說法？--Nkywvuong（留言） 2024年6月19日 (三) 16:11 (UTC)[回复]

台灣閩南人有權利使用任何名詞來稱呼自己的母語，「台語」就是絕大多數台灣閩南人用以稱呼自己母語的常用名詞，沒有問題，符合方針WP:COMMONNAME。一些人認為該名詞是福佬沙文主義，那只是這一些人自己的意識形態。
再者，閣下提到閩南話並非台灣的原生語言，但是閣下或許不知道閩南話也並非閩南地區的原生語言，敝人建議閣下先去搜尋一下閩南語的歷史。--Matt Smith（留言） 2024年6月19日 (三) 16:47 (UTC)[回复]
那麼在台灣的其他族群，也有資格以「台灣」形容其在台灣的族群文化，特別是台灣原住民族，更應該優先使用「台灣」的冠名權，而且既然閣下提到了WP:COMMONNAME，我認為所謂的「共識」不應該和「多數暴力」混淆，也許一部分的台灣閩南人認同以「台語」排他性的代指「台灣閩南語」等類似稱呼，但是仍有一些人（包括一部分台灣閩南人和台灣其他族群）並不認同此類稱呼，那麼這類稱呼就不能強行稱為通用名，既然並非通用名，也不符合NC:ID、NC:D、NC:FULL的要求，那麼使用較準確的稱呼，例如：香港粵語，美式英語，巴西葡萄牙語，新加坡華語，墨西哥西班牙語，而非「港語」，「美語」，「巴西語」，「星語」，「墨語」就是共識。2024年6月19日 (三) 17:38 (UTC)--Nkywvuong（留言） 2024年6月19日 (三) 17:38 (UTC)[回复]
沒有人強迫其他族群必須用「台語」來稱呼台灣閩南語。其他族群當然可以用「台灣閩南語」來稱呼台灣閩南語。但是，如敝人在上面所述，絕大多數台灣閩南人就是用「台語」來稱呼自己母語，而且台灣閩南人在台灣族群中佔大多數，因此該名詞之使用符合NC:名從主人和WP:COMMONNAME。--Matt Smith（留言） 2024年6月20日 (四) 02:08 (UTC)[回复]
常用名稱吧？怎麼定義是一個問題，但「臺菜」這類既有稱呼還要如此計較背後意涵，那是無理的。至於所謂「臺語」問題，我覺得「臺灣閩南語」簡稱「臺語」沒啥問題就是（但國家語言發展法寫「臺灣臺語」則顯然是匪夷所思的「去中國化」行為）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月19日 (三) 17:34 (UTC)[回复]
那麼「臺灣客家語」能否簡稱「臺語」？-游蛇脫殼/克勞棣 2024年6月19日 (三) 19:19 (UTC)[回复]
這要問台灣客家人他們想不想用這個名詞。--Matt Smith（留言） 2024年6月20日 (四) 02:09 (UTC)[回复]
雖然我是台灣閩南人，無法代表其他族群的意見，但是從部分台灣客家人和其他族群的看法可知，許多台灣客家人相當反對將「台灣閩南語」稱為「台語」，甚至支持將「台灣客家話」簡稱為「台語」，與之抗衡。[50][51][52][53]--Nkywvuong（留言） 2024年6月20日 (四) 05:54 (UTC)[回复]
那部份台灣客家人完全可以用「台灣閩南語」來稱呼台灣閩南語，隨他們自由，沒有人強迫他們用「台語」稱呼台灣閩南語，甚至他們想稱呼台灣客家話為「台語」，也隨他們自由（雖然這麼做會造成混淆，因為台灣閩南人使用「台語」已經先到先得了）。
敝人還是要強調，台灣閩南人有權利、也有自由使用「台語」來稱呼自己的母語，他人無權干涉。絕大多數台灣閩南人使用「台語」也沒有貶低其他族群的意思，其他族群的人士沒必要想得那麼複雜，更沒必要為了這件事情大搞政治正確、干涉台灣閩南人的家務事，徒增大家的困擾。--Matt Smith（留言） 2024年6月20日 (四) 08:20 (UTC)[回复]
敝人覺得話不能說得太滿。閣下肯定台灣閩南人有權利使用任何名詞來稱呼自己的母語？那麼台灣閩南人有無權利使用「維吾爾語」來稱呼自己的母語，如果他們願意的話？（造成混淆沒關係，與維吾爾族毫無相干也沒關係，不是先到先得更沒關係，畢竟這是台灣閩南人的權利與自由）-游蛇脫殼/克勞棣 2024年6月20日 (四) 14:57 (UTC)[回复]
單從理論上講，確實有這個權利啊，因為法律沒規定不可以。但是敝人相信絕大多數台灣閩南人會尊重先到先得，因此不會使用「維吾爾語」來稱呼自己的母語。--Matt Smith（留言） 2024年6月20日 (四) 15:40 (UTC)[回复]
之前還有人把台灣國語叫成台語的。--小河仔（留言） 2024年6月26日 (三) 10:40 (UTC)[回复]
條目名稱「臺灣閩南語」，內容寫「常簡稱「臺語」」，是較為準確又中立的處理方式。「臺語」條目要消歧義還是重定向，可以討論。--歡顏展卷（留言） 2024年6月19日 (三) 19:28 (UTC)[回复]
  • WP:中立：「所有維基百科條目以及其他百科式內容必須以中立的觀點書寫，在儘可能沒有任何偏見的前提下，平等地表達出任何曾在可靠來源中發表過的重要觀點。」
  • 在台灣島上，誰是主體誰是客體、誰排他、誰占用，請引用可靠來源，將相關的觀點平等地寫入條目中。
  • 參閱WP:FORUM，中文維基百科從來都不是讓任何人用來追求公平正義平等平權的地方，這是一個建立百科全書的協作計劃，要宣揚任何觀點都有更好的地方可以去。
--CaryCheng（留言） 2024年6月20日 (四) 04:46 (UTC)[回复]
(！)意見我覺得可以建立族群相關名稱方針，類似兩岸四地方針，避免爭議存在--HYHJKJYUJYTTY（留言） 2024年6月20日 (四) 15:55 (UTC)[回复]

移動條目「臺灣閩南語髒話」至「閩南語髒話」

本主題全部或部分段落文字，已移動至Talk:閩南語髒話。执行人：路西法人 2024年6月26日 (三) 07:36 (UTC)。[回复]

关于“法语系运动会”和“法语系运动会足球比赛”条目的名称

本主題全部或部分段落文字，已移動至Talk:法語系運動會。执行人：路西法人 2024年6月26日 (三) 07:35 (UTC)。[回复]

关于影视作品配音资料相关问题的困惑

由于两岸三地方面没有独立的可靠来源登载配音资料，只能使用一手来源(部分作品会在作品本身以及平台简介的制作人员列表标注配音人员名单)作为来源使用。而部分用户会以一手来源不能作为来源或者琐碎内容为由删除配音资讯。(之前在超级战队作品条目中就与相关条目主笔因相关问题起过争执。)--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月20日 (四) 12:07 (UTC)[回复]

一手來源可作為補充一些基本資訊的來源，只是不能用來彰顯關注度。我認為配音不是瑣碎內容。我記得超級戰隊系列條目極少來源，是粉絲向原創研究、原創整理之溫床之一，那位主編有沒有寫好自己的內容？--Factrecordor（留言） 2024年6月20日 (四) 12:36 (UTC)[回复]
至少没有。之前试图添加中国大陆地区一手来源(来自b站作品简介以及作品内普通话版制作人员列表。)都被条目主笔删除。--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月20日 (四) 13:30 (UTC)[回复]
這些資訊發行商／播放平台有責任向第三方平台發佈，如果發行商／播放平台不發佈相關資料，維基百科也沒有責任記錄相關資料--唔好阻住我愛國（留言） 2024年6月20日 (四) 12:48 (UTC)[回复]
中国大陆方面代理商在作品内的普通话版制作人员列表有提供资料。(类似于迪士尼在两岸三地发行作品会在作品最后提供对应配音版本的制作人员列表。)港澳台地区代理商以及电视台并没有提供配音资料。--东姑阿都拉曼与卖华公会是出卖马来西亚华人利益的罪魁祸首--甜甜圈 2024年6月20日 (四) 13:32 (UTC)[回复]

瑞士区划单位“Canton”的台湾译名是什么？

本主題全部或部分段落文字，已移動至Talk:州 (瑞士)。执行人：路西法人 2024年6月26日 (三) 05:38 (UTC)。[回复]

『刀劍神域』角色「結城明日奈」標題名字問題

依WP:CON/TRIAL移動討論，保留討論主題。請至Talk:亞絲娜參與討論，不要回應此主題。此串直接在客棧存檔。--路西法人 2024年6月26日 (三) 05:15 (UTC)[回复]

「亞絲娜」的本名是「結城明日奈」、但是目前中文維基百科採用的是「結城明日奈」的網名「亞絲娜」、而在日語維基百科也是使用「結城明日奈」而不是「亞絲娜」來作為標題、請問這是否該按照名從主人之原則？--桜花雪󠄁 2024年6月21日 (五) 16:52 (UTC)[回复]

本主題全部或部分段落文字，已移動至Talk:亞絲娜。

钱浩梁的名字

本主題全部或部分段落文字，已移動至Talk:錢浩樑。执行人：路西法人 2024年6月26日 (三) 05:08 (UTC)。[回复]

关于维吾尔人因私下使用新疆时间而被送往再教育营的有来源内容被删除6次

本主題全部或部分段落文字，已移動至Talk:新疆時間。执行人：路西法人 2024年6月26日 (三) 05:05 (UTC)。[回复]

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

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

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

自立浸信会应该改回原译名独立浸信会

本主題全部或部分段落文字，已移動至Talk:自立浸信会。执行人：路西法人 2024年6月26日 (三) 04:28 (UTC)。[回复]

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

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

无论是在学术界还是在大众的认识中，“郑板桥”一词都远比“郑燮”通行。“郑燮”理应移动至“郑板桥”？正如中维用“王重阳”而不用本名“王喆”，用“章太炎”而不用本名“章炳麟”，用“孙中山”而不用本名“孙文”或“孙逸仙”。--向史公哲曰（留言） 2024年6月26日 (三) 08:57 (UTC)[回复]

“郑板桥”一词远比“郑燮”通行”的论据如下：
1.[54]谷歌趋势显示，郑板桥一词郑燮常用。
2.在国家哲学社会科学文献中学进行搜索，关键词为"郑燮"的有103条，关键词为"郑板桥"的有791条。
3.在cnki搜索，“郑板桥”有1978条结果，郑燮有294条结果。--向史公哲曰（留言） 2024年6月26日 (三) 09:04 (UTC)[回复]
目前已于条目发布移动请求，欢迎各位维基人前来讨论。--向史公哲曰（留言） 2024年6月26日 (三) 09:13 (UTC)[回复]

請至Talk:郑燮繼續討論。--路西法人 2024年6月26日 (三) 09:20 (UTC)[回复]

共享世界觀系列的不同作品，世界觀條目

我在編輯ACGN條目時遇到一個問題，有些不同的作品是共享同一世界觀宇宙，典型案例如《Fate系列》、漫威宇宙。

現在的我正著手在《拳願阿修羅》系列、《流汗吧！健身少女》、《一勝千金》這系列共享世界觀的漫畫作品，共享世界觀系列的作品，什麼狀況可以設立世界觀條目（比照FATE系列）？什麼情況則是不作設立世界觀獨立條目？謝謝解惑~~--Nieve（留言） 2024年6月26日 (三) 10:14 (UTC)[回复]

關注度及是否有足夠可靠來源以供查證。--路西法人 2024年6月26日 (三) 10:18 (UTC)[回复]
若祇是背景共享同一設定，通常難以個別建立條目。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月26日 (三) 13:16 (UTC)[回复]
除非有大量的符合可靠来源的参考（包括报道、研究、评论）对这个作品系列的“世界观”这个要素进行介绍，并足以超过小小条目的要求来独立创建条目，就可以考虑这样做。要不然在作品条目中提及一两句就可以了。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月27日 (四) 00:42 (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
  • 為所有標準類別補上例子。

後續討論

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

管理人员申请预讨论

本主題全部或部分段落文字，已移動至Wikipedia talk:申请成为管理人员。

—此條未加入日期時間的留言是于2024年6月21日 (五) 16:14 (UTC)之前加入的。

對新用戶禁用內容翻譯工具（續）

於Phabricator查看
編號T349959的工單

原討論存檔見此：Wikipedia:互助客栈/其他/存档/2024年3月#對Phabricator的回應

以下為Pginer-WMF的最新回應：

Perfect. I think we can plan to introduce these changes. We plan to introduce these in iterations.

  1. Limit publishing into the main namespace to "extended confirmed users" only.
  2. Get input from the community on the effects, for the community to decide whether to make the restriction more/less strict.
  3. Make machine translation non-default.

In this way we can have a better understanding on the effect of each of the changes and how to adjust them.

簡單而言，他們將作出以下更改：僅允許延伸確認用戶將翻譯發佈到主命名空間，並願意之後依社群意見將限制調整成更嚴格 / 寬鬆；以及機械翻譯設為非預設選項。

@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、MilkyDefer、Dewadipper、Stang： 考慮到他們的提議與過去討論的共識（即禁止翻譯發佈到主命名空間及機翻設為非預設）相近，如果一週後沒有任何異議，即視為社群同意他們的提議。副知所有曾參與討論的編者。謝謝。--SCP-0000（留言） 2024年3月23日 (六) 13:27 (UTC)[回复]

沒問題。--日期20220626（留言） 2024年3月23日 (六) 13:33 (UTC)[回复]
應該可以。--冥王歐西里斯（留言） 2024年3月23日 (六) 14:20 (UTC)[回复]
挺好，我收到了邮件但都忘了这事了。--MilkyDefer 2024年3月23日 (六) 15:01 (UTC)[回复]
好。 -‎Lemonaka 2024年3月23日 (六) 16:56 (UTC)[回复]
非常好。——Aggie Dewadipper 2024年3月23日 (六) 19:55 (UTC)[回复]
他們願意退讓是可以就此參考他們的意見啦--SunAfterRain 2024年3月24日 (日) 14:16 (UTC)[回复]
赞同。--桐生ここ★[讨论] 2024年3月24日 (日) 16:51 (UTC)[回复]

既然已有多人同意此變更，且正如上方提到他們的提議與過去的共識相近，故依照 WP:SNOW 視社群同意他們的提議，並已在 phab 反映社群的意願。謝謝。--SCP-0000（留言） 2024年3月24日 (日) 14:29 (UTC)[回复]

不反对如此配置。但扒了三个有使用内容翻译工具的直出主条目空间的成品（中国的动物福利和权利、自由意志民主党人、杰克逊·欣克尔 ），我还是觉得禁用了可能更好。 囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2024年3月25日 (一) 08:15 (UTC)[回复]
目前方案通過後第一個條目不會直接輸出到主空間，因為作者的編輯數量還達不到延伸用戶的級別。所以至少擋掉三分之一了，不錯了。--日期20220626（留言） 2024年3月25日 (一) 08:20 (UTC)[回复]
如果可以，不知能否幫忙整理使用內容翻譯而有問題的條目？這樣方便與基金會溝通時，有相關例子可供他們參考及研究。謝謝。--SCP-0000（留言） 2024年3月25日 (一) 16:44 (UTC)[回复]
感觉被G13的多少都是内容翻译的条目。。。—-Aggie Dewadipper 2024年3月25日 (一) 18:39 (UTC)[回复]
偶爾也有非內容翻譯的條目被掛G13。--日期20220626（留言） 2024年3月25日 (一) 22:26 (UTC)[回复]
@SCP-2000：用RTRC找主条目空间、新建页面（因为原生最近更改不方便找新建页面）、标签为“内容翻译”、“内容翻译2”的，应该会存在不少。例如找到一篇乔安娜·斯丁格蕾（oldid=82028905）。好像最近多了一批没用户页的新用户在用这个系统来翻译，而且首次格式质量都存在或多或少同类问题（包括斜体、数字间空格、参考注脚之间空格或者参考复制的一些格式暴露（<cite>这种）、缺少参考列表，部分还有格式紊乱、模板丢失）虽然这些问题是新页面巡查员应该去做的事……——Sakamotosan路过围观 | 避免做作，免敬 2024年3月26日 (二) 02:15 (UTC)[回复]
根據提案，新用戶已經無法通過內容翻譯直接在主空間生成條目。--日期20220626（留言） 2024年3月26日 (二) 03:31 (UTC)[回复]
只是提供收集说服来源的方法。当然希望拉高下限能挡住一部分借助该系统粗制滥造的低质量翻译条目。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月26日 (二) 13:15 (UTC)[回复]
另外，感觉User:New user message不会对不是以本项目注册的新用户发自动欢迎的（例如找到的User:赛博崔会遇见电子铝黄瓜吗、User:Art4cn），有可能导致新用户缺乏对格式规则的了解。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月26日 (二) 02:26 (UTC)[回复]
这个改配置即可，可以在其建立本地账号时发送。个人认为至少其有一个编辑在发送会好些？（改配置噩梦）--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年3月30日 (六) 22:34 (UTC)[回复]
What the hell is that? -Lemonaka 2024年3月30日 (六) 01:21 (UTC)[回复]
In general, Content translation will redirect users to their chosen language of wiki, even if they use it on zhwiki. So I don't think it's the content translation's fault, but I have no idea how they can do that :)--SCP-0000（留言） 2024年3月30日 (六) 07:45 (UTC)[回复]

内容翻译现已缩紧

（註：複製自WP:互助客棧/消息#内容翻译现已缩紧，原由User:MilkyDefer發布。）

自4月10日（三）起，只有拥有延伸确认权限的使用者可以使用内容翻译功能将页面发布到主条目空间。这次调整是因应近期多发的粗滥翻译问题所做出的。延伸确认权限自动授予注册满90天且编辑满500次的编者，以及管理员。

请巡查员和所有编者留意这次更改后，翻译条目的品质是否有改善。其结果会决定是否采取下一阶段的措施：将“从原文开始”设定为默认翻译选项。

@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、Dewadipper、HualinXMN、SunAfterRain、S8321414： 副知所有曾參與討論的編者。謝謝。--SCP-0000（留言） 2024年4月11日 (四) 17:11 (UTC)[回复]

phab:T349959#9711650，疑似未生效。--碟之舞📀💿 2024年4月14日 (日) 07:50 (UTC)[回复]
不過好像數量並不多。--日期20220626（留言） 2024年4月14日 (日) 07:58 (UTC)[回复]
原因也大致抓到了，Special:PermanentLink/82270024#L-111應該能當臨時補丁--SunAfterRain 2024年4月14日 (日) 14:35 (UTC)[回复]
并没有生效：Special:用户贡献/EitanVel。上面的patch有管理员review下么？--Tim Wu（留言） 2024年4月19日 (五) 01:36 (UTC)[回复]
@SunAfterRain Not applied till now, Special:Contributions/Hueydome88E92 -Lemonaka 2024年4月21日 (日) 10:52 (UTC)[回复]
@Lemonaka：phab:T349959#9734223 patch backports in today. 雖然我是不知道他們說的移植後仍然有問題是甚麼意思，畢竟我剛才看的結果確實有正確攔截到了...--SunAfterRain 2024年4月23日 (二) 12:39 (UTC)[回复]
確實還沒有修正，如火腿黃油三明治。--SCP-0000（留言） 2024年4月24日 (三) 03:51 (UTC)[回复]
@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、Dewadipper、HualinXMN、SunAfterRain、S8321414： 補丁已於5/15部署，目前為止未見有非延伸確認用戶能發布條目至主條目空間，似乎已被修正。另外，現時僅限制發布權限，而沒有限制使用機翻的權限，草稿仍大機會存在翻譯質素低下的問題，煩請各位注意翻譯條目的品質有否改善。如果一個月後沒有任何意見，則會讓此討論自動存檔。副知所有曾參與討論的編者。謝謝。--SCP-0000（留言） 2024年5月23日 (四) 08:15 (UTC)[回复]
@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、Dewadipper、HualinXMN、SunAfterRain、S8321414： 再通知一次所有曾參與討論的編者。如果還是沒有意見，那就存檔了。--SCP-0000（留言） 2024年6月21日 (五) 18:42 (UTC)[回复]
一月似過久，二週何如？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月23日 (四) 12:20 (UTC)[回复]
兩星期未必足夠觀察其變化及影響，且此討論非急需結案或關閉。--SCP-0000（留言） 2024年5月23日 (四) 16:31 (UTC)[回复]

Unblock-zh.org

Unblock-zh.org网站的样子

很久以前讨论过的一个项目，也就是unblock-zh的网站版，我最近给他做出来了，如果对测试版软件感兴趣的话，请去 https://unblock-zh.org 这里去看看。（注意测试版软件，你的用户最后很可能被删掉！）

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

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

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

试运行

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

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

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

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

繁体支援

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

感謝藍桌照顧繁體使用者，但我目前檢視似乎有一些介面仍然是簡體中文的，例如新建工單的部分，另查臺灣的教育部字典，work order這個詞在臺灣可以翻譯為「工令」、「工作命令」、「工作通知單」或「工作單」等，就是沒有查到稱之為「工單」之翻譯，惟我日常生活中前開所有詞彙均較為少見，平常類似功能之提交申請平臺反而被稱之為「電子表單」，這部分可能需要更多繁體使用者來指出正確的翻譯。--小過兒（留言） 2024年5月30日 (四) 15:30 (UTC)[回复]
新建工单的繁体化已经完成。关于工单这个用语的翻译，我参考了一下asus的网站，叫做“请求支援”、“搜寻案件”。不知道这算不算合适的翻译。如果觉得“案件”听其来正确，那么我就把繁体语言的工单改称案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)[回复]
「工單」是對應「ticket」而不是「work order」，比如Zendesk香港也是叫ticket作「工單」[57]。再甚者，直接「搜尋申請」也是得了，不需要特地什麼ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)[回复]

工单的永久删除

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

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

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

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

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

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

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

提供的IP问题

现在有个问题

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

設立法輪功為高風險主題

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

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

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

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

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

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

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

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

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

將「1945年後臺灣政治」訂為高風險主題

原标题为：將「臺灣政治」訂為高風險主題

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

通過：
將「1945年後臺灣政治」列入高風險主題並依此共識建立頁面WP:高風險主題/1945年後臺灣政治和快捷重定向Wikipedia:CTOP/1945TWP。--（☎）dt 2024年6月13日 (四) 23:37 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

臺灣政治類內容長期遭受破壞及編輯戰影響，當中不乏管理員下場參與編輯戰，近期的社會運動導致的破壞及編輯戰更是反映有需要增加一定限制。由此，我提議新增「臺灣政治」高風險主題，涵蓋「1945年後臺澎金馬地區內政外交有關的人物、組織及事件」（不包括已有主題的海峽兩岸關係及臺灣政治地位），實施以下編輯限制：

  • 編者須嚴格遵守可供查證、中立的觀點、生者傳記等核心方針指引；
  • 管理員可對擾亂編輯（包括破壞、編輯戰及其他不當編輯，或在討論時發表任何針對政治地位的訴諸人身、不文明行為和假定惡意的言論）實施標準編輯限制措施。
  • 以下條目因長期遭受破壞及編輯戰影響而提請實施編輯限制措施：
    1. 中華民國（目前已按WP:CTOP/CSRPS主題不限期保護，不需改變保護狀態）
    2. 中國國民黨（目前已按WP:CTOP/CSRPS主題不限期保護，而最近的保護是因臺灣本地政治引發的破壞，不需改變保護狀態但應從CSRPS剔除）
    3. 民主進步黨：不限期半保護
    4. 台灣民眾黨：不限期半保護
    5. 二二八事件：不限期半保護+回退不過一
    6. 太陽花學運：不限期半保護
  • 其他建議的編輯限制措施：
    1. 2024年立法院改革爭議、青鳥行動及子條目：不限期半保護+回退不過一，至事件結束解除；解除全保護以回退限制取代（因事件急速發展，全保護僅會限制條目更新）

--路西法人 2024年5月30日 (四) 12:48 (UTC)[回复]

「有關的個體」範圍太大（難道合一行動聯盟、中國民主黨也要涵蓋？），建議改為「有關的主要政黨」。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年5月30日 (四) 13:49 (UTC)[回复]
「有關的個體」預設僅須遵守三大核心方針，如果起爭議的話也應該按此高風險主題處理即可。--路西法人 2024年5月30日 (四) 16:07 (UTC)[回复]
臺灣政治相關內容範圍太大，建議縮小。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月30日 (四) 13:57 (UTC)[回复]
或得將「海峽兩岸關係及臺灣政治地位」更名為「海峽兩岸關係及臺灣政治」，然後直接將上該條目列入管制範圍。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年5月30日 (四) 14:03 (UTC)[回复]
英維能把1992年後美國政治整個納入高風險，1949年後臺灣政治除了年份外顯然不會比1992年後美國政治廣多少，真的難以說是「範圍太大」。海峽兩岸的高風險主題核心在於兩岸間的WP:NPOV、MOS:CS4D，而此建議高風險主題的核心則在於臺灣本地政黨間的內容，兩者顯然屬於不同的範疇，不適宜合併處理。--路西法人 2024年5月30日 (四) 16:11 (UTC)[回复]
上邊既然包括了二二八，那倒不如將年份拉到1945年。反正只差四年。--Ghren🐦🕓 2024年5月31日 (五) 08:42 (UTC)[回复]
太習慣1949這個年份了 囧rz……已修訂年份。--路西法人 2024年5月31日 (五) 09:54 (UTC)[回复]
1945-1949期间哪有台澎金马地区这种东西（ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月31日 (五) 10:15 (UTC)[回复]
我主要不想特地標明政權名字是為了涵蓋未來任何變化。45-49年台灣的議題到現在還是爭議相當大，寫「45-49年間台灣本島及49年後台澎金馬地區」也比較彆扭吧（（（小範圍地有點奇怪大概也問題不大。--路西法人 2024年5月31日 (五) 11:11 (UTC)[回复]
其實真要說的話，「外交」一詞也能起爭議，所以我覺得確實是別較真詞彙了。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月1日 (六) 17:12 (UTC)[回复]
那末「1945年後臺澎金馬地區內政外交有關的個體和事件」或應改為「1945年以後與臺澎金馬地區內政及外交有關的人事物」較為通順。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月1日 (六) 17:10 (UTC)[回复]
比較少會「物」，更多是「人組成的組織」，形容做「物」有點奇怪吧。--路西法人 2024年6月1日 (六) 17:24 (UTC)[回复]
「人物、事件及組織」？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月3日 (一) 02:30 (UTC)[回复]
已調整。--路西法人 2024年6月3日 (一) 02:42 (UTC)[回复]
(＋)支持，至於上面提到的範圍太大的問題，目前我是不這麼覺得啦，畢竟那些條目目前也沒有長期受破壞與編輯戰影響，自然並無適用更嚴格編輯限制措施的必要。--冥王歐西里斯（留言） 2024年5月31日 (五) 01:44 (UTC)[回复]
(＋)支持--Benho7599 | Talk 2024年5月31日 (五) 06:41 (UTC)[回复]
(＋)支持--CaryCheng（留言） 2024年6月2日 (日) 16:45 (UTC)[回复]
(！)意見-在下以為，(1)「高風險主題」宜審慎討論，避免為了解決改善問題，但增加的限制措施，會不會增加了新問題、副作用或後遺症？(2)是否需要在一些條目討論頁，提醒正在進行這一討論呢？Wetrace歡迎參與WP人權專題 2024年6月8日 (六) 02:48 (UTC)[回复]
有關2024年立法院改革爭議、青鳥行動及子條目：青鳥行動已結束，2024年立法院改革爭議的主體（2024年立法院改革）也基本結束，只剩一點餘波，大概沒有再限制的必要@LuciferianThomas：。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年6月8日 (六) 08:21 (UTC)[回复]
覆議、釋憲、罷免、倒閣等仍然是非常imminent的事情，顯然只是第一階段暫時過去。另外還有關聯爭議（二兆法案、中天條款、黨產條款）等持續中，這也叫「結束」還真的是比較難說得過去。--路西法人 2024年6月8日 (六) 10:23 (UTC)[回复]
那青鳥行動最起碼是已結束吧。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的！ 2024年6月8日 (六) 12:19 (UTC)[回复]
實際上那都算是短期衝突，雖然遺憾，但不應該是高風險主題管制的內容。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月8日 (六) 15:35 (UTC)[回复]
暫時不反對。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 09:42 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
(？)疑問-請教，依據「高風險主題」方針，「制定討論的共識需考量所有用戶提出的理據和觀點。」在本案討論中的一些不同意見，結論上會如何處理？Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 01:18 (UTC)[回复]
(？)疑問--請教，以上的問題，依據方針該如何處理？Wetrace歡迎參與WP人權專題 2024年6月19日 (三) 16:14 (UTC)[回复]

要求社群处理Mys 721tx管理员扰乱性用权、诽谤用户事情

本主題全部或部分段落文字，已移動至Wikipedia talk:管理員解任投票/Mys 721tx/第2次。执行人：Eric Liu 創造は生命（留言・留名・學生會） 2024年6月24日 (一) 00:04 (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)[回复]

臨時暫停特權機制

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)[回复]
問題是這個「選的門檻」、「敲定的細節」，過程及結果是否合理？不少人有疑慮。既然並非如英文那邊當年由威爾斯「君權神授」，本人認為本地仲裁委員會的權威是要經由實際裁決確立，不是伊始就賦予莫大權限。尤其涉及直接處理管理權限者，應不必屬於首屆就奉送委員會的工具。目前本站與監管員等全域社群合作無間，本人雖一貫主張社群拿回應有之自治權，但現階段也未見到由仲裁委員會接掌彼等緊急處置權限的必要。—— 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)[回复]
初期仲裁委員會或本地行政員都還沒有權限可以自行取消管理員權限，這個或許要到未來屆數的仲委會選舉前再解決。目前狀態下，僅有「可能需要緊急除權」、「（發佈報告後）已經確認符合解任發起條件，等候社群投票重新確認管理員權限」兩個情況是適合直接凍結權限。
雖然目前尚無技術手段直接凍結管理員權限，仲委會仍可通過審議施行禁制權，臨時禁制當事人使用任何管理人員權限，違者亦可直接視作嚴重違規而符合除權條件即可。
不過如果是「凍結權限」，那麼就不是「解任投票」而是「重新確認投票」，重新確認投票的通過標準（此處指支持留任比率）或許要提高；反過來解任投票的通過標準（此處指支持解任比率）也需因應略微提高（例如55%）。--路西法人 2024年6月15日 (六) 00:56 (UTC)[回复]
How can you 「凍結」(maybe temporarily stop) VRT priviledge without removing them? What about Oversight? -Lemonaka 2024年6月15日 (六) 02:22 (UTC)[回复]
基本上都是需要通過暫時除權處理。使用行政手段如禁制也是可以等同凍結權限，違者即直接除權即可。--路西法人 2024年6月15日 (六) 03:15 (UTC)[回复]

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

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

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

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

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

設立教育佈告板

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

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

你設計還不錯--HYHJKJYUJYTTY（留言） 2024年6月22日 (六) 11:17 (UTC)[回复]
據我所知，目前有教育專案，都是在互助客棧其他區通報。至於是否需要獨立的教育專案布告板，則尚待商榷。但無論具體地點如何，總是應鼓勵教育專案主持人通報，俾利於社群覆核。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:20 (UTC)[回复]
「教育」佈告板此稱呼較含糊，或許改為「教育專案」佈告板？謝謝。--SCP-0000（留言） 2024年6月23日 (日) 15:52 (UTC)[回复]
完成--人间百态,独尊变态(讨论) 2024年6月24日 (一) 13:29 (UTC)[回复]
教育專案佈告板看起來不錯。--冥王歐西里斯（留言） 2024年6月27日 (四) 01:33 (UTC)[回复]
我觉得这个设计的不错，支持。--桐生ここ★[讨论] 2024年6月25日 (二) 16:21 (UTC)[回复]

请求讨论LuciferianThomas涉嫌扰乱、游戏Rfda共识形成事情

用户LuciferianThomas在近期有关用户Mys 721tx不当用权态度、诽谤用户事情为阐述观点多次发表扰乱、游戏讨论言论：

一、诉诸诡辩技巧：针对在下的几则言论见下:
  1. “如果说苗没有对被封禁人假定善意，那么被封禁人对苗毫无假定善意为误判又是什么道理？”首先在下一开始的言论就完全假定善意，对涉事用户的期许“...（Mys 721tx君封禁在下）一定是有令人敬服及光明正大之理由，因此在下才要求Mys 721tx君必须按维基百科的精神 “充分沟通 ”，供社群检验。，此则言论亦可能诉诸伪善，进而淡化涉事用户不当行为。
  2. 为什么苗君作为管理员，在依照方针认定用户违规后，指出用户“对扭曲方针的认识”，并明确拒绝解封，直到你“通过行为意识自己的错误”，这样就叫做“无效沟通”...所以结局必须是管理员撤回封禁才叫“有效沟通”？在下从未发表要求任何管理员必须解封言论，而是要求管理员详细调查充分回应用户质疑后行权。该言论我认为符合红鲱鱼定义的通过修辞、转移言论性质，曲解在下解封申诉是为施行用户正当要求合理解释，保证用户权益之本意。
  3. 诽谤在台湾法律中，可受公评之事及与公共利益有关的申请不能认定诽谤、有尽力查证也不构成诽谤...通篇引用法律解释不当陈述诽谤定义，属于维基法匠谬论，并合理化已造成当事人精神痛苦的诽谤行为。这种为袒护涉事管理员而扭曲一般人礼仪的发言令人发指。至于所谓“证据”未得CU等权威机构认证，可合理认为属于罗织罪名、捕风捉影。在此情境下，已经受到严重精神痛苦的Lanwi1即使在此等糟糕情绪下反指控，也可以理解。（这里不是说相关言论妥当，但在下认为轻视别人的人无权要求自己不被轻视，Mys 721tx君应先尊重别人再要求被伤害的人尊重自己。）
二、强推意见的冗长发言：该君上述诸诡辩发言之冗长，可合理认为其涉嫌为袒护Mys 721tx君拉布、抵牾意见不和者。此等类似言论也非Luciferian君首次被质疑：早在WP:共识讨论中已被诸多用户认为强推、漠视反对意见，见下方用户评价：
综上可证明LuciferianThomas君习惯性为阐释观点发表冗长言论，强推不被人接受的观点， 让只有有限时间和精力的用户感到难以继续回应，游戏共识形成。
三、鲁莽指控他人行为不当'：将在下提前声告行政员如果违背社群程序、共识强行如上次讨论般迅速终止决定，提出必要质询的言论谓之“威胁”“恐吓”进而违反RFDA，并就此要求第三方管理员“遏制”在下、阻止本次RFDA共识形成。显然不符合常人认知。
同时一整段言论使用放大粗红字体，已使在下感到威胁与恐吓，也TPG指引的：“避免过多的文字特效：请注意过多的文字特效会使别的用户有被骚扰的感觉，亦让人感到这些留言带强烈的语气，例如是斜体文字、粗体文字，以及英文中完全的大写字母和过多的感叹号，就像是“SHOUTING””
四、倾向言行、双重标准：涉事用户Mys 721tx之不当用权态度被多名用户指出、质疑，却丝毫不承认自己过错。借@LuciferianThomas一言：人生最厌恶自己违规还好面子说是别人问题的人。LuciferianThomas却完全忽视用户质疑，对当事管理员问题只字不提，显示出Luciferian为袒护（自称）“与自己走的很近的管理员”对用户双重标准、特别对待。
五、威胁用户：在在下发表论证言论驳斥其冗长、不当言论后，在另一相关讨论中，其不针对本人言论作出回应，反而威胁在下如果开启联署，将诉诸第三方管理员制裁。
我提前告知，如果管理人员如施行前次般被广泛用户质疑之行为，将提起新一轮质询让社群检验，Luciferian君能谓之“威胁”“胁迫”“攻击”。在下依照过往惯例标准，驳斥其袒护管理员的发言后，其仍只是一贯未回应论证地指称在下“扭曲方针”“不合规定，并威胁“如果他还是正式发起解任案，我再请求其他管理人员制裁有关行为即是。”（似乎在他眼里这就不是威胁了）可合理认为LuciferianThomas君继续双重标准，优待涉事管理员、试图“镇压”质询管理员的用户。

在下鉴于用户LuciferianThomas君涉嫌扰乱、游戏共识形成言论严重性，在此希望社群讨论该用户近期行为，保护社群用户质询管理员应有之权利。 同时再次(！)強烈抗议，并呼吁LuciferianThomas君立即停止涉嫌为偏袒管理员，阻挠当前RFDA共识形成发表诡辩言论、夸大扭曲意图遏制质疑管理员的用户、游戏讨论等违反AGF、文明与礼仪的不当行为。 希望LuciferianThomas自觉停止相关行为，作出有益讨论。如无改善，社群理应对此进一步讨论。保留其他方式维护讨论秩序。--Gluo88（留言） 2024年6月15日 (六) 14:22 (UTC)[回复]

若是要討論單一使用者的行為以及實施封禁，應該去WP:VIP、WP:AN3或是WP:ANM提報。--CaryCheng（留言） 2024年6月15日 (六) 14:47 (UTC)[回复]
另外，我認為U:LuciferianThomas近期的發言及編輯並無不當，沒有閣下宣稱的擾亂、遊戲共識等情形。--CaryCheng（留言） 2024年6月15日 (六) 14:51 (UTC)[回复]
“若是要讨论单一用户的行为以及实施封禁，应该去WP:VIP、WP:AN3或是WP:ANM提报。”此事有关正在形成的RFDA共识，在此版面请求讨论也广泛利用版面征询其他用户发言。此外，@LuciferianThomas君此前亦曾对前用户在此版面提出要求社群讨论处理，相信他能理解这一行为。至于您不认为近期发言或编辑并无不当，我能理解你的观感。只是可以的话，还望给出您的理由陈述上方情形如何不违反，相信这有助于社群理解有关观点。--Gluo88（留言） 2024年6月15日 (六) 15:03 (UTC)[回复]
  • 喔不，你不理解，若是理解了就不會接著說出後面那一段。
  • 閣下花了很大的篇幅試圖說服社群成員，U:LuciferianThomas做了很糟糕的事。我要說的就只是，我作為社群成員之一，閣下的長篇論述終究沒有說服我U:LuciferianThomas違反了方針與指引。
--CaryCheng（留言） 2024年6月15日 (六) 18:44 (UTC)[回复]
  1. 维基百科共识决议的机制基本上就是论据合理性之间的相互博弈形成，如果编者没有提出论据的能力，不会形成有益共识。
  2. 正如有人仅以“我认为该条目有所不当，没有某些人宣称的资料完备、叙述流畅等情形”投票反对DYK，而不指出具体的问题。这种行为可能构成POINT，即不乐见共识建立的发言：在其他编者对自己的编辑提出问题／异议或要求解释时，反复漠视他们的诉求。。
  3. 当然以上只是建议，或许在下仍然无法说服阁下。只是请注意自身讨论态度引起的可能问题。
謝謝您，祝编安
--Gluo88（留言） 2024年6月15日 (六) 19:26 (UTC)[回复]
祝編安。--CaryCheng（留言） 2024年6月16日 (日) 17:07 (UTC)[回复]
贊成CaryCheng所述：「若是要討論單一使用者的行為以及實施封禁，應該去WP:VIP、WP:AN3或是WP:ANM提報。」，也希望Gluo88自觉停止相关行为，在其他適合的頁面進行提報--Wolfch (留言) 2024年6月15日 (六) 15:29 (UTC)[回复]
这只是原则问题，封禁政策指出的也只是任何用户在提供充分证据下可向适当的布告板提报不当编辑行为，提议管理员封禁相关账号和IP地址。而不是必须在有关版面提出。所以我不知道“要求我自觉停止相关行为”的原因何在（扰乱？游戏？在下不过是用@LuciferianThomas君先前的标准行为处事在此对他提出质询与邀请用户讨论，如果能改善，我目前亦无将其举报意愿，只是希望社群讨论此事），除非将维基百科视作维基百科不是官僚体系。只是从引文条文的非强制性来看，这点自然也是不成立的。请就用户相关行为发言，谢谢。--Gluo88（留言） 2024年6月15日 (六) 15:45 (UTC)[回复]
最近的討論似乎有帳號提到貢獻至上原則，只有這個原則切入一種觀點
  • A帳號的編輯產生數值X正面效果(此時假設X數值無限大)，數值Y負面效果，X－Y＞0(此時必定是X÷Y＞1)且X÷Y＞2
  • 假設第一項成立，讓A機能停止是否適合
  • 將第一項的的等式改成Y-X＞0(此時必定是Y÷X＞1)且Y÷X＞2，此時讓A機能停止是否適合
--Rastinition（留言） 2024年6月15日 (六) 20:29 (UTC)[回复]
@Gluo88 stop, you are close to WMLO（讨论 | 貢獻） who got a CBAN on this community. I once tried to persuade them to stop accusing all the users but failed. Do you want to second their process? -Lemonaka 2024年6月16日 (日) 11:31 (UTC)[回复]
同Lemonaka，我建议您避免步入WMLO后尘。--桐生ここ★[讨论] 2024年6月16日 (日) 12:24 (UTC)[回复]
@Gluo88：建議您可以放一段假期，您太激動了，也十分感謝您對我上面留言的認可，您使用系統功能發送的感謝我有收到，加油。--~~Sid~~ 2024年6月17日 (一) 09:03 (UTC)[回复]

谢谢两位提醒 ， 我目前尽量不发言了。--Gluo88（留言） 2024年6月16日 (日) 12:43 (UTC)[回复]

当事人回应区

在下认同维基百科不强迫任何人参与，但我觉得阁下的言行可能对未来讨论造成不是很好的影响（在下现在还在担心是否我真的发起联署，您会将此前威胁诉诸真实）。所以特此设立当事人回应区。如果可以的话，还请您在此回复上述问题。如果您不想回答，也没关系。 --Gluo88（留言） 2024年6月16日 (日) 12:30 (UTC)[回复]

I got a severe threat from WMLO, a previous banned user, after posting this comment by direct emailing. I will step away from this topic. Good luck for every parties in this case. -Lemonaka 2024年6月17日 (一) 05:38 (UTC)[回复]
建议您阅读WP:ANON，并寻求信任与安全团队协助。--桐生ここ★[讨论] 2024年6月17日 (一) 06:50 (UTC)[回复]
How do he mail you? —— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月19日 (三) 14:20 (UTC)[回复]

新分段

我之前沒特別留意這邊的討論，但我意外地發現我在上方的討論中說到的事情與這個討論串也有一定的關係。Sanmosa 蚌埠 2024年6月20日 (四) 14:28 (UTC)[回复]

Template:Policy风格

Template:Policy和Template:Nutshell的边框怎么全撑到页面的边上了，之前应该是居中，两边留有一定的空白，见互联网档案馆备份。英维的也是居中，两边留有空白。似乎是所有调用Module:Message box的模板，显示结果均变成如此。--Kethyga（留言） 2024年6月18日 (二) 14:38 (UTC)[回复]

這似乎不是本地技術問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月18日 (二) 17:23 (UTC)[回复]
 已修复，昨天为了修dark mode下的问题，偷懒抄enwiki没抄全。已经补上--百無一用是書生 (☎) 2024年6月19日 (三) 02:36 (UTC)[回复]
現在dark mode有這麽多問題，不如專門開個RFC討論一下吧。--User:What7what8🏠 2024年6月19日 (三) 15:34 (UTC)[回复]
已开Wikipedia:徵求意見/深色模式--百無一用是書生 (☎) 2024年6月20日 (四) 07:52 (UTC)[回复]

協助增加台灣交通標線標誌號誌圖片

共享資源上有「枕木紋行人穿越道線」、「對角線行人穿越道線」、卻沒有「斑馬紋行人穿越道線」及「行人穿越道號誌（雙閃黃燈）」，有沒有人可以協助添加呢？--世界解放者（留言） 2024年6月20日 (四) 02:10 (UTC)[回复]

實物圖片，來源台中市政府網站。這種穿越道與號誌是不是台灣自創的啊？--世界解放者（留言） 2024年6月20日 (四) 02:18 (UTC)[回复]
已上傳，但這張照片的穿越道不符合標準（無邊線、綠底），而且號誌燈不夠亮，希望有更好的照片。--世界解放者（留言） 2024年6月21日 (五) 04:01 (UTC)[回复]

共享資源的文字授權？

共享資源網頁下寫著「所有非結構化文字在創用 CC 姓名標示-相同方式分享授權條款下提供」，但上傳過程中，又出現了「說明文字」以CC0授權，而且這「說明文字」好像包括了非結構化文字？有人可以講解一下嗎？--世界解放者（留言） 2024年6月25日 (二) 04:26 (UTC)[回复]

说明文字应该是指页面中的文件信息（“添加一行文字以描述该文件所表现的内容”），属于结构化文本。——暁月凛奈 (留言) 2024年6月25日 (二) 11:10 (UTC)[回复]
結構化資料是指meta data吧。--世界解放者（留言） 2024年6月25日 (二) 14:29 (UTC)[回复]
「說明」是在「檔案資料」而不是「結構化資料」下面，所以我以為算是「非結構化文字」。--世界解放者（留言） 2024年6月25日 (二) 14:36 (UTC)[回复]
根据Commons:File captions，文件说明确实属于结构化数据，而且是最早启用的结构化数据。可能是因为其重要性，所以单独分开了，没有和其他结构化数据放在一起。我理解共享资源所说的“非结构化文字”指的是那些项目页面，比如方针、指引、帮助等等，而结构化文字指的就是各文件页面上关联的信息。Irralpaca（留言） 2024年6月25日 (二) 18:17 (UTC)[回复]
我看了一下討論頁，有人指出嚴格來說「說明文字」不符合結構化資料的定義，所以是共享資源自己把「說明文字」算做結構化資料的，而「描述文字」看起來算是非結構化文字。總之我要去把之前上傳的檔案的說明文字處理處理。--世界解放者（留言） 2024年6月26日 (三) 02:47 (UTC)[回复]
取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”