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