维基百科:互助客栈/技术/存档/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)