維基百科:互助客棧/技術/存檔/2023年2月

2023年第05期技術新聞

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

問題

• 上周大概有15分鐘一些用戶無法登錄或者編輯，這是由於會話保存問題導致的。 [1]

本週後期變更

• MediaWiki的新版本將於1月31日部署於測試維基及MediaWiki.org。它將於2月1日部署至非維基百科wiki及部分維基百科，並於2月2日部署至所有wiki，參見日曆。

將來更新

• 使用了本地化數字模式的引用的維基項目需要添加新的CSS配置，這會幫助對於編輯和閱讀模式顯示註腳數據的方式一致。如果你的維基項目傾向於用戶自行解決，請閱讀以下詳情和複製裡面的CSS例子使用，並且將維基站點名添加到列表中。否則，開發人員會於2月5日直接開始協助處理。

技術新聞由技術新聞編者製作並由機器人送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

MediaWiki message delivery 2023年1月31日 (二) 00:05 (UTC)

咱們引用的css有需要改動的必要嗎？--百無一用是書生 (☎) 2023年1月31日 (二) 02:50 (UTC)

Shizhao有，[2]--SunAfterRain 2023年2月3日 (五) 11:43 (UTC)

那麼中文版這邊希望如何改呢？--百無一用是書生 (☎) 2023年2月6日 (一) 03:23 (UTC)

有沒有展示生成頁面差異的功能

最近在嘗試去掉某些詞條中的公共轉換組（CGroup/Movie）。為了保證生成的頁面不會產生變化，我能想到的笨辦法是比較前後的html文字。意外發現幾個過度轉換案例，比如詞條空靈柩中的2處以及薩爾茨堡（沃爾夫岡·阿瑪迪斯·莫扎特 被转换成 沃尔夫冈·莫扎特传·莫扎特）。我覺得這種情況可能比較普遍，於是想問一下是否有可以展示生成頁面差異的功能（現有的顯示更改展示的是修改前後wikitext的差異）。--$g(x)=1/(\sigma {\sqrt {2\pi }})\exp(-\left((x-\mu )/\sigma \right)^{2}/2)$ 2023年2月6日 (一) 06:05 (UTC)

• 同問。--洛普利寧 2023年2月6日 (一) 13:43 (UTC)
• 去下面章節的2023年社群願望清單調查提交了一個提議，有人回復了wiki部分語言有這個功能，中文wiki要手動開啟這個測試功能。但是這個功能不能滿足我的要求：
  • 1、不能在用編輯框中點擊顯示更改時展示生成頁面差異，目前只能編輯並提交之後在查看歷史中看到生成頁面差異；（啟用新版wikitext模式可以實現這個功能）
  • 2、對模板頁面的差異展示混合了wikitext差異；
  • 3、我嘗試對一個我創建的頁面進行測試，刪去某個公共轉換組，然後提交並進行可視化比較，沒有展示出生成頁面的變化。然而我將2個html頁面保存，用文本比較能發現生成頁面的差異。--$g(x)=1/(\sigma {\sqrt {2\pi }})\exp(-\left((x-\mu )/\sigma \right)^{2}/2)$ 2023年2月6日 (一) 20:30 (UTC)
    • 更新：第3點我覺得是中文wiki對noteTA處理的問題，可能跟iOS版本不能渲染noteTA的原因一樣--$g(x)=1/(\sigma {\sqrt {2\pi }})\exp(-\left((x-\mu )/\sigma \right)^{2}/2)$ 2023年2月7日 (二) 05:09 (UTC)

2023年第06期技術新聞

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

最近更改

• 在Vector 2022皮膚中，登出用戶的頁面滿寬切換開關，即使刷新頁面或打開新窗口後，也能看到他的設置。 這個功能只會對將Vector 2022設為默認皮膚的維基項目生效。 [3]

本週後期變更

• MediaWiki的新版本將於2月7日部署於測試維基及MediaWiki.org。它將於2月8日部署至非維基百科wiki及部分維基百科，並於2月9日部署至所有wiki，參見日曆。
• 往常，當切換主資料庫伺服器時會宣布一些維基站點會進入只讀模式幾分鐘。現在我們不會在宣布這些事件，因為這幾分鐘影響不大。在周二、周四7:00 UTC將會繼續切換工作。 [4]
• 使用Vector 2022皮膚訪問所有維基站點時，已登錄用戶將會見到與瀏覽的頁面相關的工具連結（例如：鏈入頁面）在一個新的邊欄菜單上，這個菜單會現在是屏幕的另一邊。這個變動先前已經部署到捷克語、英語、越南語維基百科上。 [5]
• 2023年社群願望清單調查將會在2023年2月6日18:00 UTC停止審閱新提案。提案者請儘快完成提案撰寫，以預留時間進行翻譯和覆審。投票將於2月10日開始。

未來更新

• 小工具腳本和用戶腳本將會能同時在桌面版和移動版加載，之前只能在桌面版加載的。建議維基站點管理員檢查小工具設置適配變化，通過添加skins=…到小工具配置中以控制哪些小工具腳本不應在移動版上加載。詳情見此。

技術新聞由技術新聞編者製作並由機器人送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

MediaWiki message delivery 2023年2月6日 (一) 10:20 (UTC)

小工具這個不應該是用targets=desktop這樣麼？為何要用skins=？移動版的skin到底算是哪個？--百無一用是書生 (☎) 2023年2月7日 (二) 09:26 (UTC)

跟phab:T328610說。移動版的skin好像是mw:Skin:Minerva_Neue（minerva）。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年2月7日 (二) 10:13 (UTC)

Wikipedia_talk:首頁/styles.css#一些問題--百無一用是書生 (☎) 2023年2月7日 (二) 12:56 (UTC)

回覆工具出了什麼問題

經測試問題已消失--SunAfterRain 2023年2月8日 (三) 10:25 (UTC)

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

---

於Phabricator查看
編號T328268的任務

請問回覆工具是出了什麼問題？為什麼會出現把章節標記全部移除的怪異編輯？有人知道發生了什麼嗎？已詢問過當事人，當事人表示其只是單純地按下［回覆］按鈕-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月28日 (六) 07:26 (UTC)

我試了試，會彈窗「『回復』連結無法用於回復此留言」，也沒有按下按鈕就使用edit相關方法的Ajax請求的邏輯。--安憶^Talk 2023年1月28日 (六) 08:10 (UTC)

需條件才可以復現。--藍莓味綠茶（留言） 2023年1月28日 (六) 08:20 (UTC)

@AnYiLin：我測試回覆這個章節Wikipedia:新條目推薦/候選#1939年1月30日阿道夫·希特勒在帝國議會的演講時間戳為2023年1月28日 (六) 06:21 (UTC)的留言，能夠正常出現回覆的輸入框。其他章節則否。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月28日 (六) 08:24 (UTC)

假如回復「測試」，提交的wikitext也只有這倆字，而不是全文。大概和前端沒什麼關係了。--安憶^Talk 2023年1月28日 (六) 08:36 (UTC)

@AnYiLin：你確定嗎? 你要不要實際保存編輯看看? (出事再回退就好) 我不認為他提交的wikitext只有這倆字。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月29日 (日) 10:22 (UTC)

我不確定，但我的意思是「假如我在你所說的位置回復『測試』倆字，Ajax只提交了這倆字」，不是說他提交了倆字。--安憶^Talk 2023年1月29日 (日) 12:05 (UTC)

試過了，提交之後會有問題。--安憶^Talk 2023年1月29日 (日) 12:06 (UTC)

所以暫時用$('body.page-Wikipedia_新条目推荐_候选').removeClass('ext-discussiontools-replytool-enabled');處理下怎麼樣？--安憶^Talk 2023年1月29日 (日) 12:17 (UTC)

@AnYiLin：可能需要，因為截至2023年2月6日 (一) 05:59 (UTC)為止已經發生7次了，再一直回退也不是辦法，乾脆讓它按不了比較快。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月6日 (一) 05:59 (UTC)

他說「We already have a fix for it, and it will be deployed later this week.」 --安憶^Talk 2023年2月6日 (一) 13:47 (UTC)

@AnYiLin：又發生了，到底怎麼回事，有頭緒嗎？。另，對@Shanghai Ningyou：說聲抱歉，因為你的編輯損毀章節標頭，所以已經回退，還請閣下重新編輯一次，謝謝。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月29日 (日) 08:23 (UTC)

@Shanghai Ningyou：閣下又損毀章節標頭了；@AnYiLin：已經發生三次了，看來明顯很有問題。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年1月29日 (日) 10:17 (UTC)

我就直接點的「回復」，這是怎麼出的問題？？？-- ——上海人形（留言） 2023年1月29日 (日) 10:18 (UTC)

那就先不要在那個頁面用回復工具。--安憶^Talk 2023年1月29日 (日) 12:07 (UTC)

DYKC頁的話，在頁面未完全刷新出來時點擊「回復」是可以完成留言的，當頁面完全刷新後再點擊「回復」就會出現「連結無法用」的彈窗。--東風（留言） 2023年1月29日 (日) 14:48 (UTC)

我猜是上面的#章節標題裡的轉換標記似乎會干擾回覆工具相同理由惹的禍？--SunAfterRain 2023年2月3日 (五) 11:33 (UTC)

@SunAfterRain：你可以幫忙去mediawiki.org或phab問問看嗎? 感謝。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月6日 (一) 04:07 (UTC)

註：此留言已被原作者（User:SunAfterRain）移除。2023年2月8日 (三) 09:58 (UTC)

• (※)注意又再發生四次了Special:Diff/75811444、Special:Diff/75845280、Special:Diff/75849345、Special:Diff/75852698（共發生了7次），請社群意識到問題的嚴重性。根據回覆工具再該頁的歷史紀錄似乎是從2023年1月中旬之後才開始發生-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月6日 (一) 04:05 (UTC)

---

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

請求移動討論存檔

請求把Wikipedia:互助客棧/條目探討/存檔/2023年1月#翻唱歌曲分類第一次細分整理後記添加到Category_talk:翻唱歌曲。我本來是（不知為什麼）無法在Category_talk:翻唱歌曲開新話題才在互助客棧開的。--Factrecordor（留言） 2023年2月10日 (五) 13:22 (UTC)

完成，Special:Diff/75915639，Special:Diff/75915641。--Xiplus#Talk 2023年2月10日 (五) 13:36 (UTC)

五個撲水的少年的譯名

條目涉及電影版及電視劇版，本來只用簡單的全頁轉換，但在香港，電影版及電視劇版的譯名其實是不同的。《五個撲水的少年》為電影版的香港譯名，但兩輯電視劇版在香港有線電視播放時，是譯作《水著少年》（今天找了2005年的雜誌查証）。我NoteTA苦手，只得每個位置逐一停止轉換。想加綠連時又發現綠連和停止轉換好像不能同時使用，只好分開列出。來請教一下有沒有更好的處理方法。--Factrecordor（留言） 2023年2月13日 (一) 15:35 (UTC)

請求合併維基共享資源頁面

請求將維基共享資源上的Category:ROCN Ming Chuan (PFG2-1112)併入Category:USS Taylor (FFG-50)。ROCN Ming Chuan(實為ROCS，頁面創建者筆誤)為USS Taylor移交中華民國海軍後的名稱。兩頁面同存已導致中文維基百科頁面無法連結至外文頁面。--Kenchen945🇹🇼國軍條目拓荒/修繕工程進行中（留言） 2023年2月13日 (一) 02:13 (UTC)

註：中華民國海軍也可以簡寫為「ROCN」，理論上不能算是筆誤。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年2月13日 (一) 15:32 (UTC)

中華民國海軍是可以簡寫為ROCN，但中華民國海軍的艦艇（如上文提到的銘傳號巡防艦）應用ROCS這個船舶字首（Ship prefix），意為為ROCS（Republic of China Ship）。--Kenchen945🇹🇼國軍條目拓荒/修繕工程進行中（留言） 2023年2月14日 (二) 01:13 (UTC)

2023年第07期技術新聞

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

問題

• 啟用了編輯巡查功能的維基項目，在導師列表中由帶有自動巡查權限的導師提交的變動沒有被正確標記為已巡查。這將本周晚些時候修復。 [6]

本週後期變更

• MediaWiki的新版本將於2月14日部署於測試維基及MediaWiki.org。它將於2月15日部署至非維基百科wiki及部分維基百科，並於2月16日部署至所有wiki，參見日曆。
• 回復工具及討論工具的其他部分將會部署給所有移動站點的用戶使用。詳情請看相關決定。 [7]

未來更新

• 所有維基項目在3月1日進入只讀模式幾分鐘，計劃在14:00 UTC進行。詳情請留意技術新聞，具體會在當周前推送消息到相關維基項目。 [8][9][10]

技術新聞由技術新聞編者製作並由機器人送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

MediaWiki message delivery 2023年2月14日 (二) 01:48 (UTC)

關於跨維基搜索功能如何啟用的問題

本站在Special:搜索中，右側邊顯示來自維基文庫、維基詞典等搜索結果，請問是如何做到的，為什麼有的語言的維基百科就沒有？ 以及是如何在其他維基上啟用這個功能呢？ 謝謝！--46.232.120.234（留言） 2023年2月20日 (一) 16:04 (UTC)

Twinkle更新 (2023-02-20) @914de99

近期變更

• 設定頁面的「回覆」章節已更名為「通告」，與下拉式選單保持一致。
• 如果頁面已存在審核中的{{AFC submission}}，在請求快速刪除時會詢問是否一併移除。
• 現在可以在請求快速刪除時，同時掛上{{salt}}以請求白紙保護，請僅在頁面已被多次建立時才勾選。

如果近期變更有任何錯誤，或是認為未來變更會造成任何問題，請在Twinkle討論頁、互助客棧技術版、Telegram群組或Github擇一報告。--Xiplus#Talk 2023年2月20日 (一) 16:20 (UTC)

2023年第08期技術新聞

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

問題

• 上周，在對基金會雲服務計劃維護期間，不可預見的併發症迫使團隊關閉所有工具 2-3 小時，以防止數據損壞。 正在進行相應工作以防止將來出現類似問題。 [11]

本週後期變更

• MediaWiki的新版本將於2月21日部署於測試維基及MediaWiki.org。它將於2月22日部署至非維基百科wiki及部分維基百科，並於2月23日部署至所有wiki，參見日曆。
• 2023年社群願望清單調查的投票階段將於2月24日18:00 UTC結束。結果將於2月28日公布。

將來更新

• 所有維基項目在3月1日進入只讀模式幾分鐘，計劃在14:00 UTC進行。詳情請留意技術新聞，具體會在當周前推送消息到相關維基項目。 [12][13][14]

技術新聞由技術新聞編者製作並由機器人送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

MediaWiki message delivery 2023年2月21日 (二) 01:57 (UTC)

Editing news 2023 #1

閱讀這份電子報的其他語言版本 • 這份多語言電子報的訂閱名單

本電子報包含編輯團隊工作的兩個重要的最新消息：

1. 編輯團隊將完成添加討論頁計劃的新功能，並著手部署。
2. 他們將開展一項新計劃，那就是編輯檢查。

討論頁計劃

某些即將到來的變更

編輯團隊差不多完成了討論頁計劃的第一個階段。 現在幾乎所有討論工具的測試功能裏的新功能都已可用。

它將顯示關於某個討論有多活躍的信息，例如最近一條留言的日期。 馬上就會有一個新的「添加話題」按鈕。 你可以在Special:Preferences#mw-prefsection-editing-discussion將其關閉。 請務必提供意見反饋。

測試組的每日編輯完成率：討論工具（測試組）和移動前端的覆蓋（控制組）

移動版網站上的討論工具的A/B測試已完成。 編輯者們對於討論工具更是一帆風順。 編輯團隊正在為移動網站上的所有編輯者啟用這些功能。

新計畫：編輯檢查

編輯團隊正在開始一個幫助維基百科新編輯者的項目。它將幫助人們在點擊"發布更改"按鈕之前發現某些問題。 第一個工具將激發人們在添加新內容時添加參考資料。 請監視該頁面以了解更多信息。 你可以加入2023年3月3日的會議以瞭解更多資訊。

–Whatamidoing (WMF) (討論) 2023年2月22日 (三) 23:24 (UTC)

維基百科編輯內容強制丟失問題

新版的Chrome會對後台的標籤頁過一段時間強制刷新，查找編寫條目的資料時，新條目的編輯框的頁面處於後台，如果時間太長，chrome會強制刪除那個頁面的緩存，再次打開到前台時，頁面內容會丟失，並強制刷新，請問有什麼方法可以解決？（PS：網上的解決方法是「chrome://discards/」點擊Auto Discardable的toggle，將√切換至×，但是這個方法只對當前有效，chrome關閉後再打開就失效了。）--Leiem（留言·簽名·維基調查） 2023年2月21日 (二) 17:29 (UTC)

這不是瀏覽器的問題？——Sakamotosan路過圍觀 | 避免做作，免敬 2023年2月22日 (三) 00:33 (UTC)

不完全是（不清楚維基媒體伺服器是否會緩存這個，只知道C區傳文件的時候如果頁面崩了有頁面能找回）--Leiem（留言·簽名·維基調查） 2023年2月22日 (三) 04:15 (UTC)

不同吧？C區那個上傳嚮導，可能是上傳文件後會保存關聯信息（臨時文件在服務端和用戶關聯，或者cookies上保存記錄），這樣重新刷新會關聯回來？但對於頁面原始碼編輯的話，代碼編輯框的內容並沒有這種保存機制？——Sakamotosan路過圍觀 | 避免做作，免敬 2023年2月22日 (三) 08:42 (UTC)

可以用VE，可視化或原始碼都可以，它會緩存編輯內容。--安憶^Talk 2023年2月22日 (三) 03:37 (UTC)

編輯框應該算是原始碼（？ 。前兩個還沒用過。--Leiem（留言·簽名·維基調查） 2023年2月22日 (三) 04:15 (UTC)

嗯…我不是在列舉。我是說VE的可視化模式或原始碼模式都可以。編輯框應該是指「2010年版wikitext編輯器」吧，那個不是VE。--安憶^Talk 2023年2月22日 (三) 08:23 (UTC)

用vscode寫吧，Wikitext Extension是個好東西--SunAfterRain 2023年2月22日 (三) 08:03 (UTC)

這個是不是能解決問題：m:Community Wishlist Survey 2023/Editing/Auto-save feature？--百無一用是書生 (☎) 2023年2月22日 (三) 09:59 (UTC)

你維又要往LocalStorage塞垃圾了。--安憶^Talk 2023年2月22日 (三) 12:44 (UTC)

這個wish如果能通過的話確實可行（？）--Leiem（留言·簽名·維基調查） 2023年2月23日 (四) 16:01 (UTC)

Stack Overflow上的這個回答不知會否有幫助。新版Chrome或需先啟用chrome://flags/#high-efficiency-mode-available，如底下評論所示。--Lt2818（留言） 2023年2月22日 (三) 14:07 (UTC)

感謝，用這個可以解決。啟用之後再在「設置」-「效果」關閉「內存節省程序」。--Leiem（留言·簽名·維基調查） 2023年2月23日 (四) 16:04 (UTC)

2023年第09期技術新聞

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

問題

• Last week, in some areas of the world, there were problems with loading pages for 20 minutes and saving edits for 55 minutes. These issues were caused by a problem with our caching servers due to unforseen events during a routine maintenance task. [15][16]

本週後期變更

• MediaWiki新版本將於2月28日部署至測試維基及MediaWiki.org，及於3月1日部署至非維基百科站點及部分維基百科，並於3月2日部署至所有站點，參見日曆。
• 全部的維基將在3月1日14:00 UTC起短暫進入只讀狀態。 [17]

技術新聞由技術新聞編者製作並由機器人送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

MediaWiki message delivery 2023年2月27日 (一) 23:46 (UTC)

能不能平衡各類別的特色內容在首頁出現的頻率？

特色內容中颶風（和某些其它類別）的比例太高了（至於為什麼，這可能是另一個應該討論的問題），讓我感覺比較沒意思，所以能不能平衡各類別的特色內容在首頁出現的頻率？--GUT412454（留言） 2023年1月20日 (五) 08:57 (UTC)

所有特色內容都上只能是這個結果。還是說要像en:WP:TFA一樣，選出每天的首頁展示條目？PS：如果中維每日平均誕生不到一篇FA，那還是只能全體條目輪展。（除非FA展示三天之類，那才有得選）--洛普利寧 2023年1月20日 (五) 09:11 (UTC)

我想可以按照類別分組，每組內有順序，各組間也有順序。每天按順序選擇一個組，再在組中按順序選擇一個條目。這樣每組內頻率相同，而組間頻率與組中條目個數成反比。（如何分組也是個問題）--GUT412454（留言） 2023年1月20日 (五) 13:00 (UTC)

(～)補充：以組來看，每個組中有條目出現在首頁的頻率相同，但是以條目來看，不同組中的條目出現在首頁的頻率不同。--GUT412454（留言） 2023年1月20日 (五) 13:16 (UTC)

特色內容本就少，要達成收支平衡最好還是各位努力多寫一點，不然到時會看到某幾篇條目很常出現。 --窩法乙烷 兒法夢碎 2023年1月20日 (五) 11:52 (UTC)

現在好像是循環的，所以每個條目的頻率相同。但是某一/幾類內容會經常出現，而且這些條目很像（X年X洋颶風季、X年熱帶風暴X），問題在這裡。--GUT412454（留言） 2023年1月20日 (五) 13:07 (UTC)

目前是間隔4日才可能有相同類別，見Wikipedia:首頁/特色內容展示設定#一般設定。某些類別條目出現頻率高，只是因為這一類條目較多造成的--百無一用是書生 (☎) 2023年1月24日 (二) 03:38 (UTC)

是的，但是這至少對我來說是個問題（我不想看見太多甚至名稱也極相似的條目（如果名稱不那麼相似，我應該感覺會好一些）。現在優良條目有2787個，其中氣象學有361個（大多數是颶風，名稱都很相似），即使幾天才有一個，因為名稱相似，我也會很容易地意識到「又雙叒叕是颶風」，於是不爽）。

按照我上面的方法，可以讓所有特色內容都上首頁（雖然頻率不同），而各類別較為平衡。條目數量不一定正比於出現頻率。

（或者可以把其它版塊移動到上面，讓首頁第一眼看起來不那麼相似？但是這裡可能就變成「為什麼你知道嗎/優良條目/每日圖片這麼相似？能不能平衡頻率？」（對了，上面說優良條目中氣象學很多，但是我沒反映這個問題，因為優良條目在下面，我打開首頁時第一眼看不見（可能也因為優良條目上首頁的選擇是人工的）。這可能是個版面設計的問題））--GUT412454（留言） 2023年1月25日 (三) 15:35 (UTC)

或許我應該@Kanashimi：--GUT412454（留言） 2023年1月28日 (六) 17:28 (UTC)

提醒一下，還有一個條件是會跳過展示數量太多次的條目。--Kanashimi（留言） 2023年1月28日 (六) 20:51 (UTC)

我不是想「跳過展示數量太多次的條目」，而是想「跳過展示數量太多次的類別」。這次我應該說清楚了吧。--GUT412454（留言） 2023年1月29日 (日) 03:52 (UTC)

這個看大家的共識吧。真通過得改寫程式。--Kanashimi（留言） 2023年1月29日 (日) 04:06 (UTC)

(～)補充 說明我不是想「跳過展示數量太多次的條目」，而是想「跳過展示數量太多次的類別」，或者其它平衡各類別的方法。--GUT412454（留言） 2023年1月29日 (日) 04:06 (UTC)

那麼徵求大家的意見，你是否支持按照類別平衡特色內容在首頁出現的頻率？你認為「條目的平衡」更重要，還是「類別的平衡+用戶的體驗」更重要？如果同意改變，用什麼算法？（其它想法也歡迎）--GUT412454（留言） 2023年1月29日 (日) 04:35 (UTC)

我(＋)支持改變算法。我不太關心條目的平衡或類別的平衡，而關心用戶體驗，但是用戶體驗讓我關心類別的平衡。如果最終通過，可以使用上面我說的方法，也可以使用別的方法。--GUT412454（留言） 2023年1月29日 (日) 04:38 (UTC)

先定義何謂多次，不然程式要怎麼寫？ --窩法乙烷 兒法夢碎 2023年1月29日 (日) 08:28 (UTC)

甲方正在嘗試比劃著需求。主要問題是現在FA的記錄有沒現成已記錄的「類型」用於區分，怎樣區分頻次？這個問題好像跟當年某位大人物同一時期推了很多颱風和硬幣的條目上FA（而且由於本身內容尚可且沒什麼人十分關注FA評選，很容易滿足票數通過），按照FA的日期輪選，很容易就會這樣的情況，好像過往就有類似的討論（？）。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年1月29日 (日) 09:33 (UTC)

現在輪選是按照日期，然後同類別的會間隔4日。最簡單的辦法就是把同類別間隔時間拉長，比如改成8日，但是會帶來新問題，可能一段時間後颱風、錢幣、劇集等這一類條目較多的會越來越擠作一團，等待輪選。目前間隔4日的做法其實相當於在類別重複和按時間排序的公平性上做了一個平衡（妥協），時間拉長可能就破壞了這個平衡（目前的4日是一個經驗值）--百無一用是書生 (☎) 2023年1月29日 (日) 10:10 (UTC)

我比劃完了（下面的程序），夠精確了嗎？還有哪裡我沒比劃明白？--GUT412454（留言） 2023年1月29日 (日) 17:31 (UTC)

Wikipedia_talk:典範條目/存檔3#中文維基典範條目的輪播，常見颱風與颶風。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年1月29日 (日) 09:37 (UTC)

其實我在上面已經明確提出了解決方法，這裡我再(～)補充一下吧。語言是Python。

FA = [
    ['台风1', '台风2', '台风3'],
    ['a'],
    ['b']
]  # 特色内容，按顺序排列
while 1:
    print(FA[0][0])  # 按顺序选择一个条目上首页
    FA[0] = FA[0][1:] + [FA[0][0]]  # 更新类别中条目的顺序
    FA = FA[1:] + [FA[0]]  # 更新类别的顺序

--GUT412454（留言） 2023年1月29日 (日) 16:59 (UTC)

@GUT412454：抱歉，用syntaxhighlight排了一下版。如認爲不妥請回退。--洛普利寧 2023年1月29日 (日) 17:05 (UTC)

我之前也想排版，但是不會，感謝。--GUT412454（留言） 2023年1月29日 (日) 17:14 (UTC)

FA的大數組每個元素是代表什麼？FA的分類（例如：「藝術、建築和考古學\*」或者「藝術、建築和考古學\藝術、建築和考古學人物傳記」，*號是因為部分項目是直接掛在大章節下的）？「順序」是指入選時時間，沒錯？——Sakamotosan路過圍觀 | 避免做作，免敬 2023年1月30日 (一) 00:57 (UTC)

前一半對。後一半是按照順序（最後一次出現的時間）輪播，但是遇到新入選的就放到所在類別的最前面（類別間的順序不變）。

另外這個程序有bug，比如遇到0個條目的類別時會有錯誤，但是這只是用來表達我的思想，不是正式的程序。--GUT412454（留言） 2023年1月30日 (一) 02:27 (UTC)

你的這個算法和目前的算法相比看起來似乎差不多？--百無一用是書生 (☎) 2023年1月30日 (一) 02:50 (UTC)

這個算法直接規定了各個類別的頻率。之前的最終還是要每個條目在每次大循環中出現一次，最終的頻率還是361/2789，而且有時超過1/5（因為在時間上的分布不均勻）。--GUT412454（留言） 2023年1月30日 (一) 03:02 (UTC)

啊，明白了，你這個是所有類別大排序。這個的確極大緩解了你說的問題，但同時可能會導致數量極少的類別中的條目頻繁輪播？--百無一用是書生 (☎) 2023年1月30日 (一) 03:49 (UTC)

我剛才看了Wikipedia:優良條目，按照一級分的話，氣象學的頻率從361/2789（某些時候是超過1/5，因為條目和列表不算一類算兩類）下降到了1/18。按照二級分的話，氣象學的頻率更低，但是會有傳播媒體-著名動物這種只有一個（或很少幾個）條目的類別，其中的條目可能經常出現。如果想讓分類方式更好一些，應該具體類別具體分析。--GUT412454（留言） 2023年1月29日 (日) 17:29 (UTC)

是的，假如有某個類別條目過少，例如某類只有兩三個條目時，就不該經常展示。--Kanashimi（留言） 2023年1月29日 (日) 22:46 (UTC)

或許換一個思路，我有兩個不成熟的想法看看能不能解決這個問題？仍然是現在的算法邏輯，只是換一種類別的選擇方式：一是按照所屬專題來規定類別頻率，例如仍然是4天間隔，但每次挑選條目所屬專題重複性最低的來輪播（可能需要設置一個重複性的閾值），例如a屬於颱風、氣象、美國專題，b屬於颱風、氣象、中國專題，c屬於中國、傳記專題，d屬於法國、地理專題，那麼最優輪播順序就是a、d、c、b；另外一種則是以條目wikidata上的隸屬於、上級分類等幾個類別性質屬性作為判斷依據，工作邏輯和方案一差不多。（只是拋磚引玉一下）。這兩個方案的問題是需要掛好專題模板或建立好wikidata的相關屬性值才好發揮作用--百無一用是書生 (☎) 2023年1月30日 (一) 04:07 (UTC)

這個方法（以及所有各個條目的頻率相同的方法）最平衡的情況，氣象學的頻率也是361/2789（使用優良條目的數據），不到8天出現一次。--GUT412454（留言） 2023年1月30日 (一) 05:20 (UTC)

因為現在是只有颱風（和錢幣）內容很多而名稱極其相似，所以也可以直接針對這些類別專門編程。比如遇到颱風和錢幣就隨機，1/4的概率上首頁；或者用PRD算法；或者維護一個計數器，攢夠了次數就上首頁。（減少的是上首頁頻率，颱風和錢幣內部的順序不動）--GUT412454（留言） 2023年1月30日 (一) 06:03 (UTC)

我提出上面方案的一個原因是，您可能反感颱風（和錢幣）總是出現在首頁，但是可能別人會反感例如美國、人物條目總是出現在首頁。這樣的話，就無法用單一的分類方式消除這個矛盾，畢竟分類是多維度的--百無一用是書生 (☎) 2023年1月30日 (一) 06:33 (UTC)

這好像是一個問題。雖然優良條目中現有的18個分類出現的頻率都是1/18，但是現在沒有美國分類，有可能連續幾天出現美國的東西。雖然過幾天就好了，但是還是會出現。

這麼麻煩的話，要不改成人工選擇得了。--GUT412454（留言） 2023年1月30日 (一) 10:07 (UTC)

@GUT412454 我想您的需求或許可藉由把可出現相同分類的最短時間間隔拉長到接近分類個數相同來達成?--Kanashimi（留言） 2023年1月30日 (一) 20:10 (UTC)

目前的程序沒有規定每個條目在每次大循環中出現一次嗎？如果是這樣，那麼好像確實可以。--GUT412454（留言） 2023年1月31日 (二) 03:12 (UTC)

所以到底是誰弄的這麼多颶風？--GUT412454（留言） 2023年1月30日 (一) 05:21 (UTC)

我知道是誰了。--GUT412454（留言） 2023年1月30日 (一) 10:34 (UTC)

那麼現在怎麼辦？不變？按照User:Kanashimi，把可出現相同分類的最短時間間隔拉長到接近分類個數相同？改成我提出的算法？用User:Shizhao提出的多維度分類法？還是別的？--GUT412454（留言） 2023年2月3日 (五) 03:35 (UTC)

我認為可以直接用Kanashimi的方法，也可以直接用我提出的算法。如果用Shizhao的方法，還需要進一步研究。--GUT412454（留言） 2023年2月3日 (五) 03:37 (UTC)

用Kanashimi的算法也可能會造成我說的問題，同類條目一段時間後全都擠在了一起排隊；如果加上某幾個類別條目非常少，比如共10個分類，10天排序，有3個分類只有1個條目，那麼10天後只有7個分類進入10天不同類的大循環，那不就完全循環不起來了麼？只剩7個分類不可能讓10天裡每天分類都不同；要麼就是保證10天都不同，那麼就會出現有3個條目每10天輪播一次。--百無一用是書生 (☎) 2023年2月3日 (五) 04:04 (UTC)

那麼你的算法是什麼？

我先寫一部分，有不滿足要求的地方可以任意修改：

FA = [
    ['a', ['台风', '气象', '美国']], 
    ['b', ['台风', '气象', '中国']],
    ['c', ['中国', '传记']],
    ['d', ['法国', '地理']]
]  # 特色内容，按最后一次出现的顺序排列（或者任意顺序排列），后面是所在的分类
while 1:
    # 这里是什么算法？

或者你沒有提出具體的算法？--GUT412454（留言） 2023年2月10日 (五) 15:05 (UTC)

while 1:
    intersection = list(set(FA[n-1][1]) & set(FA[-1][1])) # 取类别list的交集
    if len(intersection) <1: #可根据情况调整数值，类别的重复度
        listed_FA = FA.pop(n-1) #选出的FA
        FA.append(listed_FA)  # 更新顺序
        print(listed_FA)
        n=0
    n += 1

算法大概就這樣吧--百無一用是書生 (☎) 2023年2月15日 (三) 08:14 (UTC)

你這個程序可能和（我認為的）你說的算法不相符，這個程序只考慮到前一天的條目，和前一天的條目不重複就行，條目多時是不行的（理論上某個類別的出現頻率可以達到1/2）。

我有一個算法：

import math
FA = [
    ['a', ['台风', '气象', '美国']],
    ['b', ['台风', '气象', '中国']],
    ['c', ['中国', '传记']],
    ['d', ['法国', '地理']]
]  # 特色内容，按最后一次出现的顺序排列，最近出现的在最后，后面是所在的分类。假设这里有很多条目
while 1:  # 每天
    n = int(len(FA) ** 0.5) + 1  # 在最远出现的n个条目中选择今天的条目，可以改
    FA30 = FA[-30:]  # 最近30（可以改）天的条目，用于计算重复度
    FA30.reverse()
    Fs = []  # 所有候选条目的适应度
    for i, fa in enumerate(FA[:n]):  # 对于每个候选条目
        R = sum([math.exp(-0.05 * (j + 1)) * len(set(k[1]) & set(fa[1])) for j, k in enumerate(FA30)])  # 这个候选条目的重复度，越小越好。其中的-0.05可以改
        T = 3 * math.exp(-0.05 * i)  # 这个候选条目的时间补偿，越大越好。其中的-0.05和3可以改
        Fs.append([i, R - T])
    Fs.sort(key=lambda _: _[1])  # 按照适应度排序
    i = Fs[0][0]  # 适应度最小的条目的索引
    listed_FA = FA.pop(i)  # 选出的FA
    FA.append(listed_FA)  # 更新顺序
    print(listed_FA)

這個程序考慮了30天的歷史和與現在的距離，根據重複度和上次出現時間進行綜合排序。

但是這個程序在這個參數和這些特色內容下不能讓所有條目都上首頁，據我分析是因為a和b太相似了，相互阻止被選擇。但是在現實中應該不會（可以做實驗）。--GUT412454（留言） 2023年2月18日 (六) 13:26 (UTC)

我看這個討論已經沒什麼人了，人們已經沒有興趣，已經不想討論算法的好壞。那麼我就簡單一點，不用算法，要不要改成由人工選擇特色內容？

或者還有一個方法。在某一時刻把特色內容的順序排列成重複最少（或較少）的狀態，不用改程序和參數，後面（包括幾輪後）就會繼續保持重複少的狀態。雖然還是各個條目的頻率相同，但是也比現在好。--GUT412454（留言） 2023年2月26日 (日) 04:49 (UTC)

現在其實就是機器結合人工，只有人工沒弄得，才會有機器來自動弄--百無一用是書生 (☎) 2023年2月28日 (二) 02:25 (UTC)