使用者討論:SuperGrey/存檔4
![]() | 本頁是以往討論的存檔。請勿編輯本頁。若您想發起新討論或重啟現有討論,請在當前討論頁進行。 |
2025年第13期技術新聞
維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更;不是所有的變更都會對您造成影響。技術新聞提供其他語言的譯文版本。
本週要聞
- 維基媒體基金會正在徵求您對下年度目標與關鍵結果(OKR)草案的反饋意見,這些OKR將影響基金會的下一個財政年度(從7月開始)的產品與技術優先事項。「目標」是廣泛的高層次領域,而「關鍵成果」則是追蹤目標成功與否的可衡量方式。請在討論頁分享您的意見,語言不限,最好在4月底之前提出。
近況更新 - 面向編輯者
- CampaignEvents擴充功能將於2025年4月部署至多個維基(詳情請見部署計畫),團隊已開始與確定部署的維基社群接觸。該擴充功能提供了在維基上籌辦、管理和推廣協作活動(如Event活動、編輯松、維基專題)的工具。該擴充功能有三個工具:活動報名、協作清單和邀請清單。該擴充功能目前已部署至13個維基百科(包括中文、英語、法語、西班牙語等),以及維基數據。若有任何問題或請求,請至擴充功能討論頁或Phabricator(加上
#campaigns-product-team標籤)。 - 3月31日當週開始,維基站點將能夠自行設定哪些使用者群組可以在活動報名功能中檢視非公開報名者,這是CampaignEvents擴充功能的一部分。預設情況下,活動籌辦人員和本地管理員將能夠檢視非公開報名者。這改變了目前的行為,即只有活動籌辦人員才能檢視非公開報名者。維基社群在Phabricator請求變更配置(加上
#campaigns-product-team標籤)來變更預設配置。過往活動的參與者可隨時取消報名。 - 有自訂
MediaWiki:Sidebar的維基的管理員應檢查其之中是否列有特殊頁面項目。若沒有,管理員應使用 * specialpages-url|specialpages
來加入該項目。帶有預設側邊欄的維基將在4月看到該連結從工具欄移至側邊欄。 [1] - Minerva外觀(手機版網站)將提醒和一般通知整合進一個鈴鐺圖示
中。Minerva長期存在一個錯誤,僅在有未讀「提醒」時才會顯示新通知標示。現已修正此問題。未來在Minerva中,無論您有未讀的提醒或一般通知,鈴鐺圖示上方皆會顯示未讀通知數量。 [2]
上週有23件社群提交的工單得到解決。
近況更新 - 面向技術貢獻者
- 視覺化編輯器引入了新的用戶端勾點,供開發者在整合視覺化編輯器目標生命週期時使用。該勾點應該會取代現有的生命週期相關勾點,並且在不同平台之間更加一致。此外,新的勾點也將適用於全文編輯以外的視覺化編輯,讓小工具也能與討論工具(DiscussionTools)中的編輯器互動。編輯團隊打算棄用並最終移除舊的生命週期勾點,因此團隊很關注任何新勾點未涵蓋的用例,如有相關資訊,歡迎在工單中與團隊分享。
- 使用
mw.Api
這一JavaScript函式庫的開發者,現在可以使用userAgent
參數來識別使用該函式庫的工具:var api = new mw.Api( { userAgent: 'GadgetNameHere/1.0.1' } );
。如果您有在維護小工具或使用者腳本,請務必設置使用者代理(user agent),這將有助於函式庫和伺服器的維護,以及區分合法與非法的流量。 [3][4] 本週稍晚程式碼更新細節: MediaWiki
MediaWiki message delivery 2025年3月24日 (一) 22:42 (UTC)
內容模型
其實如果您不想麻煩管理員的話,可以在Template:ShareCSS的子頁面建立個css,然後再移動到用戶頁就可以了,就像這樣。--深鳴(留言) 2025年3月25日 (二) 10:34 (UTC)
- 還有這種操作?
--SuperGrey (留言) 2025年3月25日 (二) 10:36 (UTC)
- @深鸣、SuperGrey:建在Template:沙盒/TemplateStyles的子頁也行,這是1F616EMO君告訴我的😂。--PexEric 2025年3月30日 (日) 04:25 (UTC)
- 感謝分享!受教了。--SuperGrey (留言) 2025年3月30日 (日) 07:13 (UTC)
2025年第14期技術新聞
維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更;不是所有的變更都會對您造成影響。技術新聞提供其他語言的譯文版本。
近況更新 - 面向編輯者
- 編輯團隊正在開發新的編輯檢查:華辭檢查(Peacock check)。這項檢查的目的是在使用者編輯維基頁面時找出非中立詞句,以便在他們發布編輯前通知並建議其修改。華辭檢查仍在早期階段,團隊正在尋求社群的意見:在此Phabricator工單中,團隊正在收集他們目前所研究的語言版本的維基內方針、用來標記非中立條目的模板,以及編輯摘要的用語(術語與關鍵字)。要參與其中,您可以編輯工單中的表格、在工單留言,或是直接傳訊息給Trizek (WMF)。
- 所有維基站點的單一使用者登入系統皆已更新,登入與帳號建立頁面已移至中央網域。這可讓使用者登入流程兼容瀏覽器對跨網域Cookie的限制,這些限制會讓某些瀏覽器的使用者無法維持登入狀態。
上週有35件社群提交的工單得到解決。
近況更新 - 面向技術貢獻者
- 3月31日開始,MediaWiki介面團隊將開始限量發布已生成的OpenAPI規格,以及以SwaggerUI為基礎的MediaWiki REST API沙盒體驗。團隊邀請來自特定非英語維基百科社群(中文、阿拉伯語、德語、法語、希伯來語、國際語、荷蘭語)的開發者,以他們的偏好語言審閱說明文件並試用沙盒。除此之外,沙盒與OpenAPI規格也將在測試維基的REST沙盒特殊頁面上提供給偏好使用英語的開發者。在預覽期間,MediaWiki介面團隊也邀請開發者分享您的體驗。預覽期約為兩週,之後沙盒和OpenAPI規格將提供給所有維基站點使用。
本週稍晚程式碼更新細節: MediaWiki
深入了解
- 有時,一行小小的程式碼變更,卻有著重大的意義:這項變更意味著多年來,我們第一次能夠從單一座核心資料中心執行所有提供給
maps.wikimedia.org(專門為維基媒體站點提供多語言地圖的主機)的堆疊,我們每次執行資料中心切換時都會進行這項測試。這項進展非常重要,因為它確保即使其中一座資料中心發生意外,我們仍能持續提供網站服務。這項變更歸功於兩位開發人員的大量工作,他們將地圖堆疊的最後一個組件移植到Kubernetes,我們在那裡能更有效率地分配資源,從而使單一資料中心能承受更多流量。這項工作涉及許多複雜步驟,因為這個軟體及其所使用的軟體函式庫需要許多逾期已久的升級。這類工作讓維基媒體的基礎架構更具永續性。
會議與活動
- 2025年5月14日至16日,2025年春季MediaWiki使用者與開發者研討會將於美國桑達斯基舉行,並同時線上舉行。研討會將圍繞不同產業公司使用MediaWiki軟體的情況進行討論,並鼓勵及吸引新使用者。活動報名及演講報名現已開始,可前往研討會網站報名。
MediaWiki message delivery 2025年4月1日 (二) 00:04 (UTC)
MyGO五人
母雞卡最後一話的內容,要更新到mygo五人的條目嗎?副知@深鸣。--Aqurs 2025年3月31日 (一) 16:57 (UTC)
- 要的,不過我暫時沒想好怎麼寫(沒頭沒尾的就辦了場live?)。您如果有思路也可以寫寫看。--SuperGrey (留言) 2025年3月31日 (一) 17:03 (UTC)
- 確實,我也覺得沒頭沒尾很難寫(悲。--Aqurs 2025年3月31日 (一) 17:09 (UTC)
- 是的。樂奈的劇情其實應該也要補充,但是我也不會寫🤔。或許可以等等看有沒有官方的導覽書。--深鳴(留言) 2025年4月1日 (二) 00:42 (UTC)
- 確實,我也覺得沒頭沒尾很難寫(悲。--Aqurs 2025年3月31日 (一) 17:09 (UTC)
- 是不是需要等遊戲劇情🤔,沒玩過遊戲不太清楚。--PexEric 2025年4月2日 (三) 15:16 (UTC)
- 遊戲劇情暫時還沒更新到這裡,Ave Mujica也沒實裝😳。目前的劇情和《It's MyGO!!!!!》是相同的,但是後面的劇情可能只會在遊戲中體現了。--深鳴(留言) 2025年4月2日 (三) 15:49 (UTC)
致新巡查豁免者

您好,SuperGrey。根據Wikipedia:巡查豁免權,現授予您巡查豁免者權限。這將允許您:
- 使自己的編輯自動標記為已巡查
(autopatrol)
。 - 移動文件
(movefile)
。
您可以在自己的用戶頁放置{{User wikipedia/autoreviewer}},一個標識閣下擁有巡查豁免權的用戶框。
此權限的授予,是因為我們認為您已熟知維基百科的各項方針及指引,您是一名可信賴用戶。這一權限並不會對您的編輯產生影響,此權限僅旨在減少巡查員的工作量。您建立的頁面會被自動標記為「已巡查」。欲了解更多信息,可前往Wikipedia:巡查豁免權。若您(最好永不發生)有濫用權限的嫌疑,您的權限可能被剝奪,甚至您會遭封禁。
如果您超過6個月沒有任何編輯活動,權限會被解除。若您希望自己辭去職務,請至申請解除權限頁申請,或是自行移除。如果有任何問題,歡迎在我的討論頁、互助客棧或是#wikipedia-zh IRC://中提出。
祝您編輯愉快!--千村狐兔(留言) 2025年4月4日 (五) 15:38 (UTC)
2025年第15期技術新聞
維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更;不是所有的變更都會對您造成影響。技術新聞提供其他語言的譯文版本。
近況更新 - 面向編輯者
- 從今以後,系統會要求介面管理員和中央公告管理員必須先啟用雙重認證,才能行使其權限。未來這項措施可能會擴大到更多具有高級權限的群組。 [5]
上週有20件社群提交的工單得到解決。
近況更新 - 面向技術貢獻者
- 設計系統團隊正準備於4月29日發布Codex的下一個主要版本(v2.0.0)。使用Codex提供的CSS的編輯者和開發者應查看2.0概要文檔,其中包括與一些重大變更相關的指南,例如
font-size
、line-height
和size-icon
。 - 2025年開發者滿意度調查的結果現已公布。感謝所有參與者。這些結果有助於基金會決定下一步的工作方向,並檢討最近的工作。
本週稍晚程式碼更新細節: MediaWiki
會議與活動
- 5月2日至4日,2025年維基媒體黑客松將在土耳其伊斯坦堡舉行。現場活動報名將於4月13日截止。報名前請留意,入境土耳其可能需要簽證或電子簽證。
MediaWiki message delivery 2025年4月7日 (一) 18:52 (UTC)
Re: 來源檢查小工具更新
感謝貢獻,真的很方便。 ——魔琴[留言 貢獻 PJ:小學 PJ:兩岸] 2025年4月8日 (二) 07:03 (UTC)
Re:{{Article status}}
模板
寫了{{#invoke:DYK status}}(透過{{#invoke:Template parameter value}}實現)。しかし,經過我的測試,Expensive parser function開銷降低了一半,但是總加載時間從152.9ms上升到220.7ms,CPU time和Real time都上漲一半,不知道算不算優化🤣。還是說我的模塊實現方式不好,不用Template parameter value純正則表達式可能效率更高?--PexEric 2025年4月4日 (五) 13:43 (UTC)
- 不對,我的測試用量太小了😂。在User:PexEric/沙盒2跑了一下PJ:SHIP/N(共241次用量),
效果不亞於原狀。總加載時間4417ms降至4040ms,其他時間都略有下降,Template parameter value依然降低一半,481至242。是可以的。--PexEric 2025年4月4日 (五) 13:55 (UTC)- 起了怪了,我不能復現了。現在效果還是不如原來。我已經放棄了,閣下有空可以看看。--PexEric 2025年4月4日 (五) 15:17 (UTC)
- 我週末看看代碼。不過我覺得您猜測的可能是對的,畢竟parameter value的實現還是太robust了,使用了太多次gsub。我們純手工幾條正規表達式實現,效率提升是可觀的。另外,其實我的應用場景是600+次用量,241次還是太少了,Lua不會報「too many expensive calls」🤣--SuperGrey (留言) 2025年4月4日 (五) 18:02 (UTC)
- @PexEric:好像效果還可以,比我預想的要快(我的使用例)。不過如果有提速需求的話,可能還是要用正規表達式。--SuperGrey (留言) 2025年4月9日 (三) 01:05 (UTC)
- 實測模板到350以上用量確實就會報too many expensive function calls。現在我已經將沙盒版本合併了。--PexEric 2025年4月9日 (三) 01:54 (UTC)
- @PexEric:好像效果還可以,比我預想的要快(我的使用例)。不過如果有提速需求的話,可能還是要用正規表達式。--SuperGrey (留言) 2025年4月9日 (三) 01:05 (UTC)
Re: {{Reaction}}_小工具
已經用上,感謝貢獻。 ——魔琴[留言 貢獻 PJ:小學 PJ:兩岸] 2025年4月11日 (五) 03:06 (UTC)
live house和評審雜談
雖然閣下主編的live house的同行評審已經結束,但是如果您希望的話,我還是可以再去看看的。如果評審結束的話,這還是我首篇非ACG條目的評審🤣。昨天準備評審全血細胞計數這篇條目,但是發現主編好像在大幅修改原文,所以還是算了。
我目前評審的條目大多數是您寫的。不知道您有沒有看我和洛普利寧君之間的閒聊,我感覺我可能還不清楚乙級以上的標準。洛普利寧君乙級是句子讀一兩遍就能讀懂,可能有不妨礙理解的別字和語病,比如「的地」不分,[……]語法本身不是太重要。
按照這麼說的話,我之前不少自以為是乙級評審的,是不是實際上並沒有把握好尺度。您其實或許也可以對我的評審做出意見和評價,這樣我也能做出更好的評審😂。
另外我想借樓小小抱怨下,感覺目前本地的環境有點糟糕,我覺得還是只為幾位能夠信得過的編者所寫的條目提意見或是做評審比較好。雖然從理論上來說我這是「政治錯誤」的,應該只看條目本身而不是看編者。--深鳴(留言) 2025年3月26日 (三) 01:34 (UTC)
- 哈哈哈確實,乙級和乙上級、優良級之間的標準本來也沒有很清晰,給了評審者相當大的自由裁量權。優良評選的點票遊戲也是主要看內容和格式,而在其他地方著墨有限。這幾天洛普利寧君開始大搞「乙上級評審」,這hype train我也第一時間搭上了 😆,您也可以趕時髦把「乙級評審」改稱「乙上級評審」。
- 對於其他專題的評審,我不太敢輕易去做長評,也就只能提提意見,或者看別人評完了我來投一票。電子遊戲專題內的條目還是更熟悉一些,主編又以多為熟人,故說不定真的可以產生英維長評審制的風氣,大家互相幫評。
這就是我只在舒適圈內發言的原因。
- 我當然歡迎閣下再評審live house條目,看看能不能衝上GA。--SuperGrey (留言) 2025年3月26日 (三) 03:11 (UTC)
- @深鳴:今天我朋友的校園網VPN不太好用,一直連不上,可能還是要麻煩您,向您要PDF檔。您看是電郵方便還是Telegram方便呢?感謝!--SuperGrey (留言) 2025年3月27日 (四) 08:30 (UTC)
- 要麼使用Telegram吧,https://t.me/DeepChirp --深鳴(留言) 2025年3月27日 (四) 08:33 (UTC)
- 有人注意到乙上級標準的文檔了嗎?那裡說乙級除了中立性和穩定性和優良條目差不多。而參加這個規格評審的條目絕大多數都沒有中立性問題,穩定性也是一個小眾要求,那我是不是可以把大多數的乙上級評審和優良條目評審劃等號?正如您所說,現在又流行把乙級評審改成乙上級,這些操作更加混淆了3級之間的差異,讓我有點摸不著頭腦。
- 另外,本地的有效社群資源明顯少於英維。既然有熟人評審之風,能不能使得評審和點票遊戲平存,有人評就可以走英維模式,沒人評就去參加點票遊戲,這樣會不會好點。--HoweyYuan(留言) 2025年4月5日 (六) 11:17 (UTC)
- Talk:流螢 (崩壞:星穹鐵道) § 乙級評審,我當時評審完之後,應該可以視為乙上了吧。但是依據Talk:流螢 (崩壞:星穹鐵道) § 其他,這篇條目還有不少問題,所以也達不到GA。如果有志於評審的話,看一下對應的評級標準應該就不會混淆,簡單來說就是:乙級個人評,乙上他人評,優良社群評。 乙級確實可以自己評(我看到有編者翻譯完條目之後,直接評選為乙級)。乙上和優良畫等號,我感覺也不對,還要看評審者的能力。您可以看看
- 如果「評審和點票遊戲平存」,會不會存在類似於拉幫結派的情況,例如兩個人相互讓對方的條目變成GA之類。投票制就有人指責存在人情票。--深鳴(留言) 2025年4月5日 (六) 11:27 (UTC)
- 我同意你的觀點,若乙上級和優良級劃等號則毫無意義。因此頁面評級方針的描述方面亟待改善。「拉幫結派」的擔憂,本質上是對英維評審制的質疑,而不是評審郵票並存制的質疑。我的看法是,怕評審制只是一人主評,並不是不讓其他人說話。若評審明顯不合理,其他人也可以職責。拉票僅僅是憑藉投票者和受審者的利益關係來判斷,而評審就可以撕下其最後一層外衣,評審的不合理之處都予以公示,包括拉票、盲投、跟投在內的諸多現象都能被發現。當然,即使有類似這種的折衷方案,但我還是那個觀點,生產力決定生產關係。在吸引更多社群資源向評審傾斜前,或者是解決你們三位常提到的歪風問題前,我仍對此持懷疑態度。因為在沒有人花時間評審的情況下,他人的評審也會成為沒有人關注的對象,拉票現象也就難以被發現。具體關於此制度的可持續性問題,應該諮詢深耕於英維社群的專家。 HoweyYuan(留言) 2025年4月5日 (六) 14:12 (UTC)
- 其實也不完全是
對英維評審制的質疑
,上面我說得可能有點歧義。我和閣下的看法也差不多,本質上還是中維的社群資源
以及生產力
問題。如果評審制的話,本來人就不多,所以從客觀上來說,確實只有幾個人寫條目,幾個人評審。比如說SuperGrey君可能常寫ACG條目,我對此類條目比較感興趣,所以看起來就像是「拉幫結派」,而不是指利益輸送之類的意思。這樣的話,由於是我一直看他寫的條目,所以最終審出來的條目在某些方面可能確實有固定缺陷(比如說上面我提到的「流螢 (崩壞:星穹鐵道) 」的例子)。如果您說的我仍對此持懷疑態度
中的此
指的是乙上級設立的問題,我覺得好像也沒什麼問題,有人評審就乙上,沒人評審就乙級,或者是直接丟給社群,看能不能上優良。--深鳴(留言) 2025年4月5日 (六) 14:59 (UTC)- 英維和中維評審差異,說白了還是橘生淮北的問題。英維新人見到的都是評審,學會的自然也是評審;中維新人見到的是水票,那學的自然也是水票。現在的B+級,設立初衷也是甩掉歷史包袱,找塊乾淨的地方,給需要評審的主編和評審者交流。--For Each element In group ... Next 2025年4月5日 (六) 15:03 (UTC)
- 乙級這種有細緻檢查表的等級允許自己評明顯不合理,現在卻允許這種自欺欺人的行為。發揮這樣作用的,本應是乙級--HoweyYuan(留言) 2025年4月5日 (六) 15:15 (UTC)
- 乙級不要求細節,只要內容基本完整即可。比如Talk:三角洲行動#同行評審,我就是按乙級標準展開的,重點關注內容是否齊全之類,文筆方面能看懂基本就不會提什麼意見。而深鳴君評審細緻,注重語法正確性,就到了乙上級(優良級)層面。優良級開始注重細節,條目是需要他人校對一遍;但如果編者條目寫得多,本身就很熟悉格式手冊,那他的自評乙級也無妨。
- 另外中維的問題是沒人願意評審,而不是制度怎樣怎樣。我完全可以贊同「乙級自評上自欺欺人」,那我贊同之後,由誰來評審乙級呢,給GAN投水票的那批人來評嗎🤣 或者借用您的話,中維的問題就在您說的本應上--For Each element In group ... Next 2025年4月5日 (六) 15:42 (UTC)
- 感覺有細緻檢查表和能不能自評沒有什麼關係。編者自己可能忘記了某些標準,於是就自己對著表查一遍,也是可以的吧
--深鳴(留言) 2025年4月5日 (六) 17:51 (UTC)
- 乙級這種有細緻檢查表的等級允許自己評明顯不合理,現在卻允許這種自欺欺人的行為。發揮這樣作用的,本應是乙級--HoweyYuan(留言) 2025年4月5日 (六) 15:15 (UTC)
- 英維和中維評審差異,說白了還是橘生淮北的問題。英維新人見到的都是評審,學會的自然也是評審;中維新人見到的是水票,那學的自然也是水票。現在的B+級,設立初衷也是甩掉歷史包袱,找塊乾淨的地方,給需要評審的主編和評審者交流。--For Each element In group ... Next 2025年4月5日 (六) 15:03 (UTC)
- 其實也不完全是
- 我同意你的觀點,若乙上級和優良級劃等號則毫無意義。因此頁面評級方針的描述方面亟待改善。「拉幫結派」的擔憂,本質上是對英維評審制的質疑,而不是評審郵票並存制的質疑。我的看法是,怕評審制只是一人主評,並不是不讓其他人說話。若評審明顯不合理,其他人也可以職責。拉票僅僅是憑藉投票者和受審者的利益關係來判斷,而評審就可以撕下其最後一層外衣,評審的不合理之處都予以公示,包括拉票、盲投、跟投在內的諸多現象都能被發現。當然,即使有類似這種的折衷方案,但我還是那個觀點,生產力決定生產關係。在吸引更多社群資源向評審傾斜前,或者是解決你們三位常提到的歪風問題前,我仍對此持懷疑態度。因為在沒有人花時間評審的情況下,他人的評審也會成為沒有人關注的對象,拉票現象也就難以被發現。具體關於此制度的可持續性問題,應該諮詢深耕於英維社群的專家。 HoweyYuan(留言) 2025年4月5日 (六) 14:12 (UTC)
- 我又想出了一套折衷方案。既然現在評級為各專題獨立制定標準並實踐,那也可以讓典優條目評審在專題內獨立。洛普利寧也曾說,電子遊戲專題評審風氣濃厚,更應該在專題內設立請求評審專頁,提名人定請求評審的等級,評審完成後升級。典優條目亦與投票評選同等效力。--HoweyYuan(留言) 2025年4月9日 (三) 11:53 (UTC)
- 就是說投票制和評審制並行嗎?我不反對,但可能得問問社群的意見。我擔心有些人認為這樣做是專題凌駕於社群之上了🤣。--深鳴(留言) 2025年4月9日 (三) 12:06 (UTC)
- 對於這種觀點我只能說,專業的人做專業的事。說是專題凌駕於社群之上,不如說評審凌駕於評選之上,這顯然是正確的。 HoweyYuan(留言) 2025年4月9日 (三) 13:44 (UTC)
- 我覺得評審專頁可以做成機器人維護的版本,類似「請求評論」。提名人在條目討論頁掛上模板,然後機器人更新到評審專頁。這樣就繼續維持評審的討論在討論頁原址(而不是堆積在評審專頁),評審專頁起到匯總作用。
- 不過仔細想想,感覺如果是這樣,似乎直接讓大家在ACGA提名頁提一嘴「請來評審」即可,不必大動干戈搞一套新制度 😂。--SuperGrey (留言) 2025年4月9日 (三) 17:33 (UTC)
- 僅在一個地方提一嘴,在討論頁這種難以發現的地方進行評審,而沒有任何集中公示和討論,將會使得評審出的優良條目失去其信服力,拉票也會在其中潛滋暗長。這種草率的評審方式,會使得專題的評審在社群中失信--HoweyYuan(留言) 2025年4月10日 (四) 11:58 (UTC)
- 對於這種觀點我只能說,專業的人做專業的事。說是專題凌駕於社群之上,不如說評審凌駕於評選之上,這顯然是正確的。 HoweyYuan(留言) 2025年4月9日 (三) 13:44 (UTC)
- 這段時間還是把制度問題放一放,先集中精力做幾篇評審吧。在GAN評也行、在PR評也行、在討論頁留言評都行,總之等五七位編者參與,積累十幾篇二十篇完整評審案例後,再討論制度變更問題。FAC/GAN交給專題的方案22年底共識FAC試行後討論過,最後不了了之,關鍵還是沒人去執行評審。而現在的評審也就局限於三四人,很難說是三個月熱度,還是能做到細水長流乃至以點帶面。況且評審還是個新鮮事物,專題內部都沒有就具體評審問題交流過,既沒有老評審者談經驗,也沒有新評審者提疑惑,專題自己都還在摸索怎樣評審,怕是還沒有能力應對社群的各種疑問。PS:這個這串討論或許可以移動到遊戲專題討論頁了🤣 [較2025年4月9日 (三) 12:23的留言有較大變動,故重新簽名]--For Each element In group ... Next 2025年4月9日 (三) 13:03 (UTC)
- 確實應該先對評審制度進行實踐探索。現在我也確實沒有精力應對他們的種種質疑。僅僅是閒聊而以並不是正式提案,沒有必要放到專題討論頁 HoweyYuan(留言) 2025年4月9日 (三) 13:50 (UTC)
- (一套完整的)評審其實消耗不少精力,如果目標是湊到五七位評審者,恐怕沒那麼容易——畢竟我們專題內「活躍於制度建設」的人也就我們幾個😂。相比制度,我覺得可以從長計議:先從個人論述開始,大家寫點評審心得,給評審的好處吹吹風;另外就是在「同行評審」和「新條目推薦評選」多露露臉,吸引更多人加入專題。--SuperGrey (留言) 2025年4月9日 (三) 17:47 (UTC)
- 理論上能寫GA就能評GA,而且GA不要求專業性,其他領域的編者也可以做評審,所以能做評審的人至少20起步。關鍵是怎樣讓這些編輯邁出評審的第一步,而不是現在或者只顧寫自己的條目不說話,或者評選時只寫個{{{yesGA}}/提幾條都不再GA標準里要求的格式問題。
- 我的意思就是這是個長線計劃,等什麼時候能有其他編者參與,再討論制度修改的問題。現在還是儘量從簡,利用好現在已有的體制,比如在專題討論頁或ACGA提名,利用條目討論頁或同行評審來review,用B+級標記已經評審的條目。然後像您說的寫些論述,多在條目提名區露臉,GAN提名時貼上評審連結,讓評審這個事情多曝光。--For Each element In group ... Next 2025年4月10日 (四) 00:26 (UTC)1
- 能寫ga和能做評審完全不是一回事。先不說願不願意做評審,我個人感覺能做評審的也就10人左右。但即使這樣,評審仍然在本專題可以持續發展。因為按照現在的現狀,有兩個人的完整評審就已經是很高規格的了,「湊到五七位評審者」,恐怕就英維的行政資源來說都難以承受。具體可以參考之前頻繁出現的「英維模式」--HoweyYuan(留言) 2025年4月10日 (四) 11:52 (UTC)
- 我不是說五七位評審者去評同一篇條目,而是以各種形式做(或者說做過)完整評審的人有五七位。畢竟現在就三四個人做評審,如果一年後還是這三四個人(甚至更少了),只能說明評審制還是沒有發展潛力。--For Each element In group ... Next 2025年4月10日 (四) 13:36 (UTC)
- 能寫GA和能做(GA)評審實際上是一回事。理想狀態下,自己寫完條目之後,肯定會以GA評審的標準看一遍吧。或者說,根據GA標準看自己的條目就是寫GA,根據GA標準看別人條目就是評審。只不過現在許多條目都是從英維那邊翻譯的,不少人覺得「因為英維那邊是GA,所以翻譯過來符合GA標準」🤣。--深鳴(留言) 2025年4月11日 (五) 05:46 (UTC)
- 看起來只是附帶升級操作的像這樣的專題級同行評審,說實話我不太看好😂。不過確實可以考慮改變現在同行評審的制式,例如考慮英維的子頁面形式,鼓勵擴大評審。因為我覺得中維現在的排版好似不太鼓勵討論的深入。--PexEric 2025年4月10日 (四) 09:10 (UTC)
- 專題同儕評審和專題甲級評審都是2010年代的老制度,後來沒人參與,是因為編輯都跑去FAC和GAN評審了。但是他們本身還是做評審的,只是集中討論了而已。
- 中維的問題是根本不做評審——這裡不做,那裡也不做。排版不鼓勵討論是一方面,比如GAN就是為純投票設計的,而且七天強行關掉,管你有沒有評完🤣 另一方面就是編者也不會系統的評審。比如GAN很多意見是「紅鏈改綠鏈」,但這玩意根本不在GA指定的五條格式手冊內,甚至按照FA標準「遵守所有格式手冊」,紅鏈和綠鏈也是地位平等的;倒是真正寫在標準里的圖片版權檢查反而沒人做。
- 當務之急還是先有證明存在一批有意向做評審的編者。不知道怎麼評審沒關係,大家都在摸索。關鍵一篇完整評審耗費的不是幾十秒、幾分鐘,而是十幾分鐘甚至幾十分鐘。當然,讓老編輯轉變心態,感覺難度還是很大。--For Each element In group ... Next 2025年4月10日 (四) 13:58 (UTC)
- 另外如果想盤活評審制,專題間互評或許是個思路,比如地震專題搞過甲級列表,也是重視評審的表現。在主編是內行的場合,評審者是外行問題也不大,至少遊戲專題是鼓勵讓外行檢查可讀性的。當然,評審場合不太重要,專題頁或者條目討論頁都行,關鍵是先評起來。--For Each element In group ... Next 2025年4月10日 (四) 14:51 (UTC)
- 就是說投票制和評審制並行嗎?我不反對,但可能得問問社群的意見。我擔心有些人認為這樣做是專題凌駕於社群之上了🤣。--深鳴(留言) 2025年4月9日 (三) 12:06 (UTC)
- @深鳴:今天我朋友的校園網VPN不太好用,一直連不上,可能還是要麻煩您,向您要PDF檔。您看是電郵方便還是Telegram方便呢?感謝!--SuperGrey (留言) 2025年3月27日 (四) 08:30 (UTC)
感覺確實可以在專題頁留個討論了。
甲級評審目前還沒法規模化,畢竟專題現在連原創FA也沒有。而且上次試行共識制評審也是用了FAC而非GAN,結果評審「用力過猛」把人全嚇跑了🤣 社群目前又不把評審當作緊要事情,修改社群制度(包括FAC、GAN、PR、ASSESS)免不了和許多沒有評審意向的人打交道。他們的意見未必深思熟慮,結果就是參考也不合適,不參考也不合適,而且討論到最後難免又把時間花在吵架上。
我的想法還是先從優良層面入手,在專題層面推廣一年乙上級,藉助這個管道來鼓勵評審動作。包括「乙上級」本身在內,整套流程都是借用既有資源——請求頁可以復活WikiProject:電子遊戲/評級/請求,評審過程直接在條目討論頁展開,入選後只需簡單修改討論頁頂部的|class=
(然後把請求去掉)。中間不會創建頁面、模板、分類,也不會像GAN一樣入選後一堆存檔+更新。將來就算試行失敗,也不會增加廢棄頁面,沒有行政成本問題。而試行被認為成功後,再討論要不要改革社群GAN/PR之類。
至於目的,我想的有這麼幾條:
- 提供一定數量的評審範例。無論試行成功與否,都能讓人意識到,條目評審是對照WIAGA的全方位系統性檢查,而不是
{{yesGA}}
或隨手提兩個格式意見。 - 透過實際評審探究執行細節。例如評審該把握怎樣的度:既不要把GA當FA苛求,致使編審雙方疲憊;也不要太水,放不符合WIAGA的條目通過。提名者和評審者有爭議該如何操作,引入英維的第三方意見可否?
- 鼓勵編者邁出評審第一步。這也是只限「優良層面評審」的原因之一,因為非遊戲領域編者也可以輕鬆投入其中。(不過能不能真的邁出就是另一回事了)
- 驗證評審制有無可能長期施行——可能是持續運行一年,其間吸引其他編者參與;也可能是幾個月後就不了了之(希望不要如此)。
至於吸引其他編者,一方面是我上方說的專題互評。另一方面,我們也可以給其他領域條目做review,如果主編反饋積極,也可以邀請他來評一篇遊戲條目。--For Each element In group ... Next 2025年4月10日 (四) 18:36 (UTC) 21
- 該版demo我大體支持,但對細節有些意見。首先,大多數乙上級,條目與ga品質距離很近,大多數編者在做完「乙上級評審」後也會提交評選優良條目。你既然希望
「無論試行成功與否,都能讓人意識到,條目評審是對照WIAGA的全方位系統性檢查,而不是{{yesGA}}或隨手提兩個格式意見。」
乙上級社群關注度很低,因此應該改用專題內G/FA評審的方式引起整個社群的關注。其次,上面你也提到,希望促進跨專題互評,但大多數專題的編者熟悉的是優良條目標準而非乙上級標準,使用它可能讓很多人望而卻步。再次,真正有影響力的,是優良典範,而不是條目評級的其他等級。對於當下社群來說,這兩個評選是參與人數最多的高規格評選,而不是其他的等級評定。也只有這兩個等級的條目是輪流在首頁展示的。拿優良條目作小白鼠,比以上級對社群的影響更加深遠。最後,依據你的描述,這種在討論頁的評審,和現行的同行評審沒有任何區別,不僅難以吸引人參與,對社群的影響也十分有限。為方便理解,列出我的提議細節。- 在優良/典範條目評選下方增設電子遊戲條目評審的連接和頁面引用,引起更多人的關注。
- 說明電子遊戲專題的評審資源,改革初衷,從而獲得社群認可。
- 評審者按照現行同行評審流程、英維模式,採用一人制、共識制和集中公示,即達成共識且公示完成後升格為優良/典範條目。
- 討論頁評審、集中公示、機器人維護。
- 其他同洛普利寧君意見。
- ( π )題外話:話說現在的dykc、gac、fac、pr都可以採用類似的技術模式放到討論頁評審,比評審完了存檔更加優雅。 HoweyYuan(留言) 2025年4月11日 (五) 09:16 (UTC)
- 另外,正如你所說,現在應該積累評審經驗,給其他質疑者和我們一些例子,否則這種提案就像空穴來風。如果你的「在專題頁留個討論」是想讓更多的人參與這場閒聊,那我沒意見。不過,在這裡討論打擾SuperGrey確實不太合適🤣 HoweyYuan(留言) 2025年4月11日 (五) 09:19 (UTC)
- 沒事,不算是打擾。我雖然沒有太多發言,但那是因為我的觀點已經表達過了,故還是希望多聽聽大家的看法。--SuperGrey (留言) 2025年4月11日 (五) 09:52 (UTC)
- 您的意見是我設想的第二步,當有一定數目的編者堅持做評審後,再透過GAN評審評選雙軌制,讓社群承認評審的優越性。當事實上評審成為主流後,就可以讓評審完全取代評選。但我認為現在處於第一步——積累評審經驗,吸引更多評審者。
- 和第二步全面曝光相反,第一步要做的是精準投送,投送給那些有評審想法的編者(或編者群)。我上面提到地震專題,是因為地震專題有表象出評審的意象。我說「如果主編反饋積極,也可以邀請他來評一篇遊戲條目」,是因為有些編者對你的意見愛搭不理,本身就想趕快水過評審登首頁。一上來就給社群關注並不是好事。一方面要是社群那廉價的「關注」能解決問題,何必落到提案評審二十年的田地。另一方面曝光給社群,只會像最近的WT:ASSESS那樣人多嘴雜,什麼都討論不成。
- 關於您第一段話,我的一些看法在個人論述里說了。要補充的是,專題層面大家比較熟,溝通很方便,而且專題層面正因為「不夠有影響力」、「沒有那麼多人盯著」,才放得放開去手實驗。真正讓人望而卻步的東西是本來幾十秒投個票就能搞定,結果卻要用以小時計的時間,去一字一句的讀一萬字的條目。乙上級標準和優良級標準的問題兩句話就能解釋:「乙上級和優良級標準一致,為了貼合『乙』這個名字,用了乙級標準的體例改寫。評級時用哪一個都沒差。」所以問題還是在於,評審者他到底是不是真的理解優良標準檢查什麼,不檢查什麼,這需要他比照已有的評審來判斷。所以要多貢獻點評審,而不是在這裡空想。
- 另外我不想討論體制方面的問題,因為討論來討論去都是在討論「可能性」。您認為乙上級可能吸引不到人,在社群討論會獲得響應。而我認為制度這個空架子沒有任何用處,應該用最小的行政成本(就是您在WT:ACGA呼籲的行政成本)設置一個目標,召集有評審志向的編者立刻上手。這樣討論下去不能產出任何實際價值——其他編者會因為看到完整的評審而嘗試模仿,但不會因為看到這個辯論而做review。我們辯論了這麼長時間,無論是您還是我,都沒有去評審一篇條目。這個討論本身都是不小的行政成本,所以就此打住吧。--For Each element In group ... Next 2025年4月11日 (五) 14:17 (UTC)
- 我上面也提出了擱置制度改革、專於經驗積累的要求。既然這麼說那就多評幾篇條目吧。 HoweyYuan(留言) 2025年4月12日 (六) 05:10 (UTC) 1 2
然後HoweyYuan君,Wikipedia:優良條目評選#小小諾亞,您可以按GA做個完整評審;Talk:BanG_Dream!_少女樂團派對#甲級條目評審有我發起的甲級條目評審,您可以直接按WIAFA要求來評。空談不如實幹,相信這兩個評審做完後會有很多可說的,也會對本討論有幫助。--For Each element In group ... Next 2025年4月11日 (五) 16:05 (UTC)
- 小小諾亞評完了,BanG Dream這周末恐怕沒有時間完成,擇日評審。--HoweyYuan(留言) 2025年4月13日 (日) 07:51 (UTC)
2025年第16期技術新聞
維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更;不是所有的變更都會對您造成影響。技術新聞提供其他語言的譯文版本。
本週要聞
- 本週稍晚,預設的縮圖尺寸將從220px增至250px。這將改變所有維基頁面的顯示方式。部分社群多年來一直要求更改預設縮圖尺寸,但過去因技術限制而未能實現。 [6]
- 檔案縮圖現在以特定尺寸儲存。如果頁面指定的縮圖尺寸不在標準尺寸(20、40、60、120、250、330、500、960)之列,那麼MediaWiki將會選擇最接近的較大縮圖尺寸,但會請瀏覽器將其縮小到所要求的尺寸。這在視覺上不會有任何變化,但使用者可能會載入稍大一點的圖片。在頁面中使用縮圖時,如果縮圖尺寸不是很重要,請選擇其中一種標準尺寸,以避免額外的瀏覽器縮小步驟。 [7][8]
近況更新 - 面向編輯者
- 維基媒體基金會正在開發名為Edge Uniques的系統,該系統可用於實現A/B測試,幫助抵禦DDoS攻擊,並讓我們更容易了解維基媒體網站的訪客數量。有了Edge Uniques,基金會可以更有效率地打造能幫助讀者的工具,讓讀者更容易找到他們要找的東西。
- 為了提升使用者安全性,現在有一小部分的登入嘗試將需要輸入一次性密碼,該密碼將以電子郵件寄送。請檢查您的帳號是否設有有效的電子郵件地址,且該地址已被系統確認。 [9]
- 「您有沒有興趣參加一個簡短的調查,以改善您的維基上的巡查和回退工具?」這個問題將從下週開始在7個維基的近期變更和監視清單頁面上向使用者提出。內容維護工具團隊想更了解那些:檢視維基媒體專案的新編輯,並判斷這些編輯是否遵守專案方針的工作。
- 4月15日,
query.wikidata.org將不再支援完整的維基數據圖表。該日之後,學術文章將可透過 query-scholarly.wikidata.org取得,而維基數據上託管的其他資料則可透過 query.wikidata.org端點取得。這是預定的維基數據圖表拆分計畫的一部分,該計畫於2024年9月公布。詳情請見維基數據頁面。 - 季刊維基媒體App電子報新期數發布。內容涵蓋了維基百科行動應用程式的更新、實驗與改進。
上週有30件社群提交的工單得到解決。
近況更新 - 面向技術貢獻者
MediaWiki message delivery 2025年4月15日 (二) 00:23 (UTC)
Draft:Senzawa
誠邀閣下參與Draft:Senzawa的相關討論。我不太清楚Senzawa是否符合收錄標準,希望閣下協助判斷。--1F616EMO(喵留言~回覆請ping) 2025年4月16日 (三) 12:49 (UTC)
致新巡查員

您好,SuperGrey。根據您在權限申請頁的申請,現授予您巡查員權限。 這將允許您:
- 標記他人的編輯為已巡查
(patrol)
; - 使自己的編輯自動標記為已巡查
(autopatrol)
。 - 移動文件
(movefile)
。 - 移動頁面時不創建來源頁面的重定向
(suppressredirect)
。 - 檢視未監視的頁面
(unwatchedpages)
。
您可以在自己的用戶頁放置{{User Patroller}},一個標識閣下擁有巡查權的用戶框。
最新頁面中記錄了所有被創建的、且未被巡查的頁面。當您打開這些黃色背景的頁面時,您會在頁面右下角看到一個[標記此頁面為已巡查]的連結。如果您認為這個頁面的內容符合維基百科的方針要求,或您認為文章內容有問題,且已經掛上適當的維護清理模板或提交刪除,則可以點擊這個連結,把該頁面標記為已巡查;如果您無法肯定,請不要點擊,交給其他巡查員檢查。
若您(最好永不發生)有濫用權限的嫌疑(例如:在完全沒有履行新頁面巡查義務的情形下標記新頁面為已巡查),您的權限可能被剝奪,甚至您會遭封禁。您可以在參數設置中開啟「工具列顯示當前未巡查的新頁面」的小工具,方便查看未巡查條目列表並連結到最新頁面或條目。許多巡查員同樣檢查最近更改中隱藏的破壞,歡迎您加入他們,比如反破壞工作小組,在那裡打擊破壞。
另外,推薦您閱讀:
- Wikipedia:新頁面巡查,中文維基百科的方針
- Wikipedia:Twinkle,一個很有用的工具
- User:燃玉/巡查員攻略
- User:Zhangjintao/新頁面巡查入門指南/歡迎
- User:AT/巡查技巧
如果您超過6個月沒有任何編輯活動,權限會被解除。若您希望自己辭去職務,請至Wikipedia:申請解除權限申請,或是自行移除。如果有任何問題,歡迎在我的討論頁、互助客棧或是#wikipedia-zh IRC://中提出。
祝您巡查愉快!--千村狐兔(留言) 2025年4月18日 (五) 01:30 (UTC)
本期簡訊的內容如下:
2025年第17期技術新聞
維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更;不是所有的變更都會對您造成影響。技術新聞提供其他語言的譯文版本。
近況更新 - 面向編輯者
- 自4月15日起,維基函數已與達戈姆巴語維基百科整合。這是第一個能夠從維基函數呼叫函數並在條目中使用的專案。函數能接受一個或多個輸入,並將其轉換成預期的輸出,例如:相加兩數、換算單位、計算時間跨度或轉換大小寫。有了維基函數,使用者只需呼叫一個穩定的全域函數即可達成目的,無需使用本地模板。 [10]
- 新增了一種lint錯誤:空標題(說明文件)。Linter擴充功能旨在找出頁面中需要或可以修正的wikitext語句,並提供指引,說明這些語句的問題以及如何修正。 [11]
上週有37件社群提交的工單得到解決。
近況更新 - 面向技術貢獻者
- 繼在HuggingFace上發布之後,由維基媒體企業服務(Wikimedia Enterprise)開發的「Structured Contents」資料集現在也可在Kaggle上取用。這項Beta計畫著重於讓維基媒體資料更易於機器讀取,以供大量重複使用。這次,他們在開放資料集社群已在使用的平台上發布這個測試版,以尋求回饋,幫助改善產品,利於將來的廣泛發布。參閱更多關於整個Structured Contents專案,以及第一個可自由使用的版本。
- 本週沒有MediaWiki版本更新。
會議與活動
- 編輯團隊與機器學習團隊邀請有興趣的志願者參加視訊會議,討論最新的編輯檢查:華辭檢查。華辭檢查可在編輯者鍵入文字時偵測「華而不實」、「過度宣傳」或「非中立」的語句。我們鼓勵經常接觸新手的編輯者、協助修正此類文字的編輯者,或對我們在專案中使用AI的方式感興趣的編輯者參加。會議將於2025年4月28日 18:00-19:00 UTC在Zoom上舉行(查看您的當地時間)。
MediaWiki message delivery 2025年4月21日 (一) 20:59 (UTC)
reaction小工具的問題
剛剛在給BigBullfrog回應的時候,出現錯誤,顯示「原文中找到多個相同的時間戳,小工具無法處理」思考...(想點的是這一編輯)。 ——自由雨日🌧️❄️ 2025年4月23日 (三) 17:21 (UTC)
- 目前小工具是在網頁版上運行的;如果要在原始碼中找到對應的留言,就只能通過簽名的時間戳判斷(精確到分鐘,因為時間戳就只記錄到分鐘)。您在同一分鐘內簽了兩個名,故小工具在原始碼中讀取到兩個相同的時間戳,無法判斷要對哪個留言做出reaction。
- 反思了一下,我想我可以試試增加判斷標準,或許可以部分解決此問題。比如讀取網頁留言前12個漢字,然後看看原始碼是否包含這12個漢字。不過這就涉及到模糊匹配的問題,準確度一般,但也可以處理50%情況。--SuperGrey (留言) 2025年4月23日 (三) 19:57 (UTC)
- 應該不是「我在同一分鐘內簽了兩個名」吧()是我要回應的BigBullfrog的留言時間那一分鐘還有Aqurs1的留言?(題外話,那個留言還是reaction() ——自由雨日🌧️❄️ 2025年4月23日 (三) 20:01 (UTC)
- 還真是 😄。
吐槽:明明MediaWiki開發了討論工具(Discussion Tools),卻不開放接口給大家用,導致所有針對留言的小工具只能自己造輪子。--SuperGrey (留言) 2025年4月23日 (三) 20:03 (UTC)
- 還真是 😄。
- 應該不是「我在同一分鐘內簽了兩個名」吧()是我要回應的BigBullfrog的留言時間那一分鐘還有Aqurs1的留言?(題外話,那個留言還是reaction() ——自由雨日🌧️❄️ 2025年4月23日 (三) 20:01 (UTC)
2025年第18期技術新聞
維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更;不是所有的變更都會對您造成影響。技術新聞提供其他語言的譯文版本。
近況更新 - 面向編輯者
- 本週,孟加拉語、日語、韓語維基百科等多個維基的協作活動籌辦人員將可以使用CampaignEvents擴充功能。此外,已啟用CampaignEvents的維基百科中的管理員將不久後自動獲得活動籌辦人員權限,無需再根據社群要求手動授予自身。
上週有19件社群提交的工單得到解決。
近況更新 - 面向技術貢獻者
- 維基媒體設計系統——Codex預定於2025年4月29日發布下一個主要版本。技術編輯者將能於2025年5月5日當週使用該版本。本次更新將包含一些不向下相容的重大變更和輕微的視覺變更。該頁面記載了處理重大變更和視覺變更的說明。發布前的測試在T386298中回報,發布後的問題則在T392379和T392390中追蹤。
- Wiki Replicas的使用者將會注意到
ipblocks
、ipblocks_ipindex
和ipblocks_compat
這幾個資料庫檢視表現已棄用。使用者可以查詢block
和block_target
這二個新的檢視表,這些新檢視表會反映生產資料庫中的新表格。棄用的檢視表將於2025年6月從Wiki Replicas中完全移除。 本週稍晚程式碼更新細節: MediaWiki
深入了解
- 季刊語言與國際化電子報新期數發布。 本期內容包括:內容翻譯面板工具的改進概要;新增支援語言;「維基愛齋月」活動的亮點;新語言啟動實驗的結果;條目主題多樣性的分析;以及即將舉行的社群會議和活動的資訊。
會議與活動
- Let's Connect學習診所將於4月29日 14:30 UTC舉行。本期主題是「維基媒體專案中的衝突理解與應對」。現在可以報名參加。
- 2025年5月2日至4日,2025年維基媒體黑客松將在土耳其伊斯坦堡舉行,屆時全球技術社群將齊聚一堂,相互交流、集思廣益,並對既有專案進行駭客活動。
MediaWiki message delivery 2025年4月28日 (一) 19:31 (UTC)
請教ACG條目如何尋找來源
我正在審閱Draft:後藤一里,希望可以對部分來源不充足的部分補回來源,但搜尋引擎幾乎只會出現用戶生成內容和其他不相干的來源;例如搜尋「google:後藤一里 小孤獨」並不能找到說明兩者之間關聯的可靠來源,只是有一個不可靠來源,以及無數不相干的內容。請問閣下平日如何搜索這類來源?--1F616EMO(喵留言~回覆請ping) 2025年4月22日 (二) 10:29 (UTC)
- 中文來源十分稀少。比較常報道ACG資訊的就只有udn 遊戲角落、4GAMERS。如果這兩個地方找不到,那就很難了。另外,Nostalgiacn君指出微信公眾號上有幾個不錯的媒體,您可以關注一下。--SuperGrey (留言) 2025年4月22日 (二) 10:45 (UTC)
- 搜到這兩篇,供參考:刺蝟公社的文章、udn遊戲角落的文章。--SuperGrey (留言) 2025年4月22日 (二) 10:51 (UTC)
- 所以是要用日文搜尋?--1F616EMO(喵留言~回覆請ping) 2025年4月22日 (二) 11:46 (UTC)
- ACG相關內容當然要用日語搜尋。--SuperGrey (留言) 2025年4月22日 (二) 18:57 (UTC) 1
- 不過我較關注的事原創譯名問題,這也是爲什麼我當初沒想到用日文搜索。刺蝟公社的文章提及到「小孤獨」、「小波奇」兩個別名,卻沒有明示和「ぼっち」之間的關係。不過既然草稿作者給出了一個書籍腳註,我傾向相信目前草稿文內「小孤獨」和「ぼっち」的關係確實存在,但暫不判斷其和「小波奇」的關聯性。--1F616EMO(喵留言~回覆請ping) 2025年4月25日 (五) 06:28 (UTC)
- 原創應該算不上,兩個名稱都是流行的譯名,不過官方選擇譯作「小孤獨」。有兩種處理辦法:
- 兩個譯名以同樣地位呈現,都放在導言,而文中兩個都不用;
- 導言只寫官方譯名「小孤獨」,信息欄或「反響與評價」中補上「小波奇」。
- 我在長崎爽世條目中選擇了後者,因為「長崎素世」這個名稱只在中國大陸民間使用,可靠來源更是遠少於「長崎爽世」。按照可靠來源中提及兩個譯名的比例,可以大致判斷選用哪一種辦法。目前我看可靠來源中,「小孤獨」確實也是領先於「小波奇」的;何況還有「波奇醬」這個明顯是民間音譯的名稱,感覺這是一潭渾水。我個人建議也採用後者。--SuperGrey (留言) 2025年4月25日 (五) 09:15 (UTC)
- 「小孤獨」確實是官方譯名,見於東立和磨鐵引進的繁簡版漫畫,甚至劇場版在中國大陸的中文配音。至於是否要標註來源,可能需要虛構角色專題討論規範。我是覺得沒有必要。--PexEric 2025年5月1日 (四) 13:38 (UTC)
- 如果我沒理解錯ACG慣例還是指引,直接引用劇情的東西大多無需列明來源。如果是個別版本譯名,或可參照慣例而不列明,但在正文以「某某出版社版本/某某地區又稱什麼什麼」的格式寫作。我之前參孫也是這麼寫的(「參孫,天主教譯三松」),只是和此例不同,我有附上來源。--1F616EMO(喵留言~回覆請ping) 2025年5月1日 (四) 13:58 (UTC)
- 原創應該算不上,兩個名稱都是流行的譯名,不過官方選擇譯作「小孤獨」。有兩種處理辦法:
- 不過我較關注的事原創譯名問題,這也是爲什麼我當初沒想到用日文搜索。刺蝟公社的文章提及到「小孤獨」、「小波奇」兩個別名,卻沒有明示和「ぼっち」之間的關係。不過既然草稿作者給出了一個書籍腳註,我傾向相信目前草稿文內「小孤獨」和「ぼっち」的關係確實存在,但暫不判斷其和「小波奇」的關聯性。--1F616EMO(喵留言~回覆請ping) 2025年4月25日 (五) 06:28 (UTC)
- ACG相關內容當然要用日語搜尋。--SuperGrey (留言) 2025年4月22日 (二) 18:57 (UTC) 1
管理人員選舉(2025年4月)
![]() |
||
管理人員選舉 | ||
二〇二五年四月梯次 | ||
申請成為管理員 | 申請頁 | 安全投票頁 |
---|---|---|
SCP-2000(申請續任) | → | → |
S8321414(申請續任) | → | → |
0xDeadbeef | → | → |
Kanashimi | → | → |
申請成為介面管理員 | 申請頁 | 安全投票頁 |
Diskdance | → | → |
LuciferianThomas | → | → |
Kanashimi | → | → |
申請成為行政員 | 申請頁 | 安全投票頁 |
Manchiu | → | → |
申請成為監督員 | 申請頁 | 安全投票頁 |
Ericliu1912 | → | → |
Manchiu | → | → |
Peacearth | → | → |
2025年4月梯次管理人員選舉正在進行。
本梯次有4名用戶申請成為管理員,3名用戶申請成為介面管理員,1名用戶申請成為行政員,以及3名用戶申請成為監督員。
您因符合投票資格而收到此訊息。
投票期從2025年4月22日 (五) 00:00 (UTC)起,至2025年5月6日 (五) 00:00 (UTC)結束,誠邀您踴躍參與提問和投票。您可在右方(或上方)的一覽工具欄找到每名候選人的個人選舉頁面及投票連結。
請注意:所有符合當選條件的候選人均會當選;各候選人的支持率均分別計算,支持票不限於一票。
本條消息是通過群發消息功能發送給您的。如果您不希望在未來接受所有使用本功能發送的消息,請在您的討論頁加入Category:不接受消息發送這一分類。
MediaWiki message delivery(留言) 2025年4月22日 (二) 02:22 (UTC)
2025年第19期技術新聞
維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更;不是所有的變更都會對您造成影響。技術新聞提供其他語言的譯文版本。
本週要聞
- 維基媒體基金會分享了明年度(2025年7月—2026年6月)年度計畫的最新更新草案,其中包括執行摘要(也發布在Diff)、三大目標(基礎設施、志願者支援、有效性)的詳細資訊、全球趨勢以及預算與財務模式。歡迎在五月底前,在討論頁提供反饋意見和提出疑問。
近況更新 - 面向編輯者
- 已啟用CampaignEvents的維基,該擴充功能發布了兩項新的功能改進:
上週有27件社群提交的工單得到解決。
近況更新 - 面向技術貢獻者
- 小工具和使用者腳本的開發者,應將其使用
moment
函式庫的程式碼改為使用其他函式庫,例如Intl
或新的mediawiki.DateFormatter
函式庫。moment
函式庫現已棄用,並將開始在瀏覽器的開發人員主控台中記錄警告訊息。需修改的程式碼頁面,請在Phab工單中提供的全域搜尋結果查看,如有疑問也可在工單中提出。 - 維護用於查詢維基數據詞彙(term)儲存表(
wbt_*
)的工具的開發者需要更新其程式碼,以連接到單獨的資料庫叢集。這些表格將被分割到一個獨立的資料庫叢集中。透過Wiki Replicas來查詢這些表格的工具,必須改為連接到新的資料庫叢集。參閱說明文件和相關連結。 [12] 本週軟體更新細節: MediaWiki
深入了解
- Chart專案電子報新期數發布。 本期包括以下新訊:最快在本週(5月6日開始),Chart將進一步部署至更多wiki,並在接下來的幾週內擴大部署規模,此外Chart將探索篩選和轉換來源資料。
MediaWiki message delivery 2025年5月6日 (二) 00:14 (UTC)
2025年第20期技術新聞
維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更;不是所有的變更都會對您造成影響。技術新聞提供其他語言的譯文版本。
本週要聞
近況更新 - 面向編輯者
- 維基媒體基金會正在開發名為Edge Uniques的系統,該系統可用於實現A/B測試,幫助抵禦DDoS攻擊,並讓我們更容易了解維基媒體網站的訪客數量。有了Edge Uniques,基金會可以更有效率地打造能幫助讀者的工具,讓讀者更容易找到他們要找的東西。技術新聞先前曾撰文介紹過該系統。該系統將逐步進行部署。有些人可能會在5月19日當週見到Edge Uniques的Cookie。相關討論在此討論頁進行。
- 2025年5月19日開始,已啟用CampaignEvents擴充功能的維基中的活動籌辦人員可以在專案命名空間(例如「Wikipedia:」、「Wikidata:」等)中使用活動報名功能。有了這項變更,社群不需要管理員也能進行活動報名。不想要這項變更的維基可以在Special:CommunityConfiguration/CampaignEvents中移除/新增允許使用的命名空間。
- 已新建努佩語維基百科(
w:nup:
)。這是一種主要在奈及利亞中北部地區使用的語言。邀請使用該語言的人士來為新的維基百科做出貢獻。 上週有27件社群提交的工單得到解決。
近況更新 - 面向技術貢獻者
- 開發者現在可以透過結構化內容快照(Beta)存取7個維基百科(英語、德語、法語、西班牙語、葡萄牙語、義大利語、荷蘭語)的預解析內容。這些內容包括已解析的維基百科摘要、描述、主要圖片、資訊框、條目章節和參考資料。
- REST API的
/page/data-parsoid
端點已不再使用,並將被棄用。預定2025年6月7日關閉。 本週軟體更新細節: MediaWiki
深入了解
會議與活動
- Afrika Baraza是非洲維基人交流聯繫的線上平台,2025年第二屆Afrika Baraza將於5月15日 17:00 UTC舉行。本屆將集中討論維基媒體年度計畫與進展。
- MENA Connect社群通話會議是MENA維基人交流聯繫的線上會議,將於5月17日 17:00 UTC舉行。現在可報名參加。
MediaWiki message delivery 2025年5月12日 (一) 22:37 (UTC)
2025年第21期技術新聞
維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更;不是所有的變更都會對您造成影響。技術新聞提供其他語言的譯文版本。
本週要聞
- 編輯團隊和機器學習團隊正在開發一項面向新手的檢查:華辭檢查。這項檢查利用預測模型和AI,鼓勵編輯者改善其編輯的語調。團隊邀請志願者參與審查下列語言的華辭模型的初版:阿拉伯語、西班牙語、葡萄牙語、英語和日語。如果您來自上述維基並有興趣參與審查該模型,歡迎至MediaWiki.org報名參加。報名截止日期為5月23日,當天亦為測試開始日。
近況更新 - 面向編輯者
- 2025年5月20日開始,監督員和用戶查核員必須用雙重驗證(2FA)保護其帳號,才能使用其高級權限。所有屬於這兩個群組但未啟用2FA的使用者都已收到通知。未來這項要求可能會擴大到其他高級權限群組。閱讀完整公告。
本月底,多重封鎖將開始大規模部署至多個維基:5月26日當週將部署至所有非維基百科專案以及加泰隆尼亞語維基百科;6月2日當週將部署至所有其他維基百科。如有任何疑慮,請聯絡團隊。管理員現在可以在本地瀏覽Special:封禁?usecodex=1來測試新UI,或是在測試維基測試完整功能。多重封鎖可讓管理員同時對同一使用者施加多種不同類型的封鎖。詳情請參閱說明頁面。 [13]
- 本週稍晚,列出幾乎所有特殊頁面的Special:特殊頁面將更新整體設計。經過重新設計後,該特殊頁面在數個方面改善了使用者體驗,包括:名稱與別名搜尋功能、排序功能、更明顯的「受限特殊頁面」標示,以及更適合行動裝置的外觀。您現在可以在Beta Cluster預覽新版本,並在Phab工單分享反饋意見。 [14]
- 更多維基現已可以使用Chart擴充功能。詳細部署資訊請參閱部署時間表。
- 5月27日,維基函數將部署至5個維基詞典:豪薩語、伊博語、孟加拉語、馬拉雅拉姆語和迪維希語。這是維基函數的第二批部署。部署完成後,這些專案將能夠從維基函數呼叫函數,並在頁面中使用。函數能接受一個或多個輸入,並將其轉換成預期的輸出,例如:相加兩數、換算單位、計算時間跨度或轉換大小寫。有了維基函數,使用者只需呼叫一個穩定的全域函數即可達成目的,無需使用本地模板。
- 本週稍晚,維基媒體基金會將發布一個實驗中心,用於展示和獲得使用者對產品實驗的反饋。這些實驗協助維基媒體運動了解新使用者、他們如何與網路互動,以及他們如何影響維基媒體運動。一些實驗例子包括生成影片、維基百科Roblox速通遊戲和Discord機器人。
上週有29件社群提交的工單得到解決。 例如:使用API建立帳號時會遇到一些問題,現已得到修復。 [15]
近況更新 - 面向技術貢獻者
- 部分與Special:封禁互動的小工具與腳本需要更新才能與新的管理封鎖介面互動。請查閱開發者手冊以了解更多資訊。如果您需要任何協助或您的腳本無法與新的介面互動,請在此討論頁留言讓技術團隊知道。 [16]
- Lua的
mw.title
物件可用來取得特定維基頁面的資訊。本週開始,該物件將新增名為isDisambiguationPage
的屬性,可用來檢查頁面是否為消歧義頁面。 [17] 腳本開發者可以使用新的反向代理工具來透過
mw.loader.load
從gitlab.wikimedia.org載入JavaScript和CSS。工具的作者希望這個工具能實現腳本的協同開發工作流程,包括gitlab.wikimedia.org上的linting、單元測試、代碼生成和代碼審查,而無需另外將腳本複製貼上到維基媒體維基上以進行整合和驗收測試。詳情請參閱Wikitech上的 Tool:Gitlab-content。本週軟體更新細節: MediaWiki
會議與活動
- 2025年維基工作坊(第12屆)將於5月21日至22日線上舉行,探索維基媒體專案方方面面的研究人員將在此論壇齊聚一堂。立即報名。
MediaWiki message delivery 2025年5月19日 (一) 23:12 (UTC)
30級ACG專題獎
![]() | 感謝您對中文維基百科ACG專題的貢獻。根據您的貢獻,現在授予您維基ACG專題獎第30級的獎勵。歡迎您繼續幫助我們改進維基百科。 |