跳转到内容

用户讨论:SuperGrey/存档4

页面内容不支持其他语言。
维基百科，自由的百科全书
< User talk:SuperGrey
MediaWiki message delivery在话题“2025年第20期技术新闻”中的最新留言：22天前

2025年第13期技术新闻

最新留言：2个月前1条留言1人参与讨论

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

本周要闻

  • 维基媒体基金会正在征求您对下年度目标与关键结果（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)

内容模型

最新留言：2个月前5条留言3人参与讨论

其实如果您不想麻烦管理员的话，可以在Template:ShareCSS的子页面建立个css，然后再移动到用户页就可以了，就像这样。--深鸣（留言） 2025年3月25日 (二) 10:34 (UTC)

还有这种操作？--SuperGrey (留言) 2025年3月25日 (二) 10:36 (UTC)
我是从Wikipedia:优良条目/styles.css学到的🤣--深鸣（留言） 2025年3月25日 (二) 10:37 (UTC)
@深鸣、SuperGrey：建在Template:沙盒/TemplateStyles的子页也行，这是1F616EMO君告诉我的😂。--PexEric 2025年3月30日 (日) 04:25 (UTC)
感谢分享！受教了。--SuperGrey (留言) 2025年3月30日 (日) 07:13 (UTC)

2025年第14期技术新闻

最新留言：2个月前1条留言1人参与讨论

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

近况更新 - 面向编辑者

  • 编辑团队正在开发新的编辑检查：华辞检查（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五人

最新留言：2个月前6条留言4人参与讨论

母鸡卡最后一话的内容，要更新到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)
是不是需要等游戏剧情🤔，没玩过游戏不太清楚。--PexEric 2025年4月2日 (三) 15:16 (UTC)
游戏剧情暂时还没更新到这里，Ave Mujica也没实装😳。目前的剧情和《It's MyGO!!!!!》是相同的，但是后面的剧情可能只会在游戏中体现了。--深鸣（留言） 2025年4月2日 (三) 15:49 (UTC)

致新巡查豁免者

最新留言：1个月前1条留言1人参与讨论

您好，SuperGrey。根据Wikipedia:巡查豁免权，现授予您巡查豁免者权限。这将允许您：

  • 使自己的编辑自动标记为已巡查 (autopatrol)。
  • 移动文件(movefile)。

您可以在自己的用户页放置{{User wikipedia/autoreviewer}}，一个标识阁下拥有巡查豁免权的用户框。

此权限的授予，是因为我们认为您已熟知维基百科的各项方针及指引，您是一名可信赖用户。这一权限并不会对您的编辑产生影响，此权限仅旨在减少巡查员的工作量。您建立的页面会被自动标记为“已巡查”。欲了解更多信息，可前往Wikipedia:巡查豁免权。若您（最好永不发生）有滥用权限的嫌疑，您的权限可能被剥夺，甚至您会遭封禁。

如果您超过6个月没有任何编辑活动，权限会被解除。若您希望自己辞去职务，请至申请解除权限页申请，或是自行移除。如果有任何问题，欢迎在我的讨论页、互助客栈或是#wikipedia-zh IRC://中提出。

祝您编辑愉快！--千村狐兔（留言） 2025年4月4日 (五) 15:38 (UTC)

2025年第15期技术新闻

最新留言：1个月前1条留言1人参与讨论

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

近况更新 - 面向编辑者

近况更新 - 面向技术贡献者

  • 设计系统团队正准备于4月29日发布Codex的下一个主要版本（v2.0.0）。使用Codex提供的CSS的编辑者和开发者应查看2.0概要文档，其中包括与一些重大变更相关的指南，例如font-size、line-height和size-icon。
  • 2025年开发者满意度调查的结果现已公布。感谢所有参与者。这些结果有助于基金会决定下一步的工作方向，并检讨最近的工作。
  • 经常项目 本周稍晚代码更新细节： MediaWiki

会议与活动

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2025年4月7日 (一) 18:52 (UTC)

Re: 来源检查小工具更新

最新留言：1个月前1条留言1人参与讨论

感谢贡献，真的很方便。  ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月8日 (二) 07:03 (UTC)

Re：{{Article status}}模板

最新留言：1个月前6条留言2人参与讨论

写了{{#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)

Re: {{Reaction}}_小工具

最新留言：1个月前1条留言1人参与讨论

已经用上，感谢贡献。  ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月11日 (五) 03:06 (UTC)

live house和评审杂谈

最新留言：1个月前35条留言5人参与讨论

虽然阁下主编的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)
@HoweyYuan：乙级确实可以自己评（我看到有编者翻译完条目之后，直接评选为乙级）。乙上和优良画等号，我感觉也不对，还要看评审者的能力。您可以看看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月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)
这段时间还是把制度问题放一放，先集中精力做几篇评审吧。在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)

感觉确实可以在专题页留个讨论了。

甲级评审目前还没法规模化，毕竟专题现在连原创FA也没有。而且上次试行共识制评审也是用了FAC而非GAN，结果评审“用力过猛”把人全吓跑了🤣 社群目前又不把评审当作紧要事情，修改社群制度（包括FAC、GAN、PR、ASSESS）免不了和许多没有评审意向的人打交道。他们的意见未必深思熟虑，结果就是参考也不合适，不参考也不合适，而且讨论到最后难免又把时间花在吵架上。

我的想法还是先从优良层面入手，在专题层面推广一年乙上级，借助这个管道来鼓励评审动作。包括“乙上级”本身在内，整套流程都是借用既有资源——请求页可以复活WikiProject:电子游戏/评级/请求，评审过程直接在条目讨论页展开，入选后只需简单修改讨论页顶部的|class=（然后把请求去掉）。中间不会创建页面、模板、分类，也不会像GAN一样入选后一堆存档+更新。将来就算试行失败，也不会增加废弃页面，没有行政成本问题。而试行被认为成功后，再讨论要不要改革社群GAN/PR之类。

至于目的，我想的有这么几条：

  1. 提供一定数量的评审范例。无论试行成功与否，都能让人意识到，条目评审是对照WIAGA的全方位系统性检查，而不是{{yesGA}}或随手提两个格式意见。
  2. 透过实际评审探究执行细节。例如评审该把握怎样的度：既不要把GA当FA苛求，致使编审双方疲惫；也不要太水，放不符合WIAGA的条目通过。提名者和评审者有争议该如何操作，引入英维的第三方意见可否？
  3. 鼓励编者迈出评审第一步。这也是只限“优良层面评审”的原因之一，因为非游戏领域编者也可以轻松投入其中。（不过能不能真的迈出就是另一回事了）
  4. 验证评审制有无可能长期施行——可能是持续运行一年，其间吸引其他编者参与；也可能是几个月后就不了了之（希望不要如此）。

至于吸引其他编者，一方面是我上方说的专题互评。另一方面，我们也可以给其他领域条目做review，如果主编反馈积极，也可以邀请他来评一篇游戏条目。--For Each element In group ... Next 2025年4月10日 (四) 18:36 (UTC) 👍2🤔1

该版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期技术新闻

最新留言：1个月前1条留言1人参与讨论

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

本周要闻

  • 本周稍晚，预设的缩图尺寸将从220px增至250px。这将改变所有维基页面的显示方式。部分社群多年来一直要求更改预设缩图尺寸，但过去因技术限制而未能实现。 [6]
  • 档案缩图现在以特定尺寸储存。如果页面指定的缩图尺寸不在标准尺寸（20、40、60、120、250、330、500、960）之列，那么MediaWiki将会选择最接近的较大缩图尺寸，但会请浏览器将其缩小到所要求的尺寸。这在视觉上不会有任何变化，但使用者可能会载入稍大一点的图片。在页面中使用缩图时，如果缩图尺寸不是很重要，请选择其中一种标准尺寸，以避免额外的浏览器缩小步骤。 [7][8]

近况更新 - 面向编辑者

近况更新 - 面向技术贡献者

  • 季刊技术社群电子报新期数发布。 本期内容包括：邀请工具维护者参加4月15日的Toolforge UI社群回馈会议；近期社群指标；近期技术方面的Diff文章。
  • 经常项目 本周稍晚代码更新细节： MediaWiki

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2025年4月15日 (二) 00:23 (UTC)

Draft:Senzawa

最新留言：1个月前1条留言1人参与讨论

诚邀阁下参与Draft:Senzawa的相关讨论。我不太清楚Senzawa是否符合收录标准，希望阁下协助判断。--1F616EMO（喵留言～回复请ping） 2025年4月16日 (三) 12:49 (UTC)

致新巡查员

最新留言：1个月前1条留言1人参与讨论

您好，SuperGrey。根据您在权限申请页的申请，现授予您巡查员权限。 这将允许您：

  • 标记他人的编辑为已巡查 (patrol)；
  • 使自己的编辑自动标记为已巡查 (autopatrol)。
  • 移动文件 (movefile)。
  • 移动页面时不创建来源页面的重定向 (suppressredirect)。
  • 检视未监视的页面 (unwatchedpages)。

您可以在自己的用户页放置{{User Patroller}}，一个标识阁下拥有巡查权的用户框。

最新页面中记录了所有被创建的、且未被巡查的页面。当您打开这些黄色背景的页面时，您会在页面右下角看到一个[标记此页面为已巡查]的链接。如果您认为这个页面的内容符合维基百科的方针要求，或您认为文章内容有问题，且已经挂上适当的维护清理模板或提交删除，则可以点击这个链接，把该页面标记为已巡查；如果您无法肯定，请不要点击，交给其他巡查员检查。

若您（最好永不发生）有滥用权限的嫌疑（例如：在完全没有履行新页面巡查义务的情形下标记新页面为已巡查），您的权限可能被剥夺，甚至您会遭封禁。您可以在参数设置中开启“工具列显示当前未巡查的新页面”的小工具，方便查看未巡查条目列表并连结到最新页面或条目。许多巡查员同样检查最近更改中隐藏的破坏，欢迎您加入他们，比如反破坏工作小组，在那里打击破坏。

另外，推荐您阅读：

如果您超过6个月没有任何编辑活动，权限会被解除。若您希望自己辞去职务，请至Wikipedia:申请解除权限申请，或是自行移除。如果有任何问题，欢迎在我的讨论页、互助客栈或是#wikipedia-zh IRC://中提出。

祝您巡查愉快！--千村狐兔（留言） 2025年4月18日 (五) 01:30 (UTC)

《电子游戏专题简讯》2025年第一季

最新留言：1个月前1条留言1人参与讨论
电子游戏专题图示
电子游戏专题简讯
第廿二号．2025年第一季
专题概览

截至2025年第一季底为止，电子游戏专题共有：

2025年第17期技术新闻

最新留言：1个月前1条留言1人参与讨论

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

近况更新 - 面向编辑者

近况更新 - 面向技术贡献者

  • 继在HuggingFace上发布之后，由维基媒体企业服务（Wikimedia Enterprise）开发的“Structured Contents”资料集现在也可在Kaggle上取用。这项Beta计划着重于让维基媒体资料更易于机器读取，以供大量重复使用。这次，他们在开放资料集社群已在使用的平台上发布这个测试版，以寻求回馈，帮助改善产品，利于将来的广泛发布。参阅更多关于整个Structured Contents专案，以及第一个可自由使用的版本。
  • 本周没有MediaWiki版本更新。

会议与活动

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2025年4月21日 (一) 20:59 (UTC)

reaction小工具的问题

最新留言：1个月前4条留言2人参与讨论

刚刚在给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)

2025年第18期技术新闻

最新留言：1个月前1条留言1人参与讨论

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

近况更新 - 面向编辑者

近况更新 - 面向技术贡献者

  • 维基媒体设计系统——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

深入了解

会议与活动

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2025年4月28日 (一) 19:31 (UTC)

请教ACG条目如何寻找来源

最新留言：1个月前9条留言3人参与讨论

我正在审阅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)
原创应该算不上，两个名称都是流行的译名，不过官方选择译作“小孤独”。有两种处理办法：
  1. 两个译名以同样地位呈现，都放在导言，而文中两个都不用；
  2. 导言只写官方译名“小孤独”，信息栏或“反响与评价”中补上“小波奇”。
我在长崎爽世条目中选择了后者，因为“长崎素世”这个名称只在中国大陆民间使用，可靠来源更是远少于“长崎爽世”。按照可靠来源中提及两个译名的比例，可以大致判断选用哪一种办法。目前我看可靠来源中，“小孤独”确实也是领先于“小波奇”的；何况还有“波奇酱”这个明显是民间音译的名称，感觉这是一潭浑水。我个人建议也采用后者。--SuperGrey (留言) 2025年4月25日 (五) 09:15 (UTC)
“小孤独”确实是官方译名，见于东立和磨铁引进的繁简版漫画，甚至剧场版在中国大陆的中文配音。至于是否要标注来源，可能需要虚构角色专题讨论规范。我是觉得没有必要。--PexEric 2025年5月1日 (四) 13:38 (UTC)
如果我没理解错ACG惯例还是指引，直接引用剧情的东西大多无需列明来源。如果是个别版本译名，或可参照惯例而不列明，但在正文以“某某出版社版本/某某地区又称什么什么”的格式写作。我之前参孙也是这么写的（“参孙，天主教译三松”），只是和此例不同，我有附上来源。--1F616EMO（喵留言～回复请ping） 2025年5月1日 (四) 13:58 (UTC)

管理人员选举（2025年4月）

最新留言：1个月前1条留言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期技术新闻

最新留言：29天前1条留言1人参与讨论

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

本周要闻

近况更新 - 面向编辑者

  • 已启用CampaignEvents的维基，该扩充功能发布了两项新的功能改进：
    • 管理员现在可以透过社群配置（说明文件）选择哪些命名空间允许活动报名。预设配置允许在“Event”命名空间中进行活动报名，但现在可以新增其他命名空间（例如专案或“维基专题”命名空间）。有了这项变更，维基专题等社群现在可以更轻松地使用活动报名功能来举办协作活动。
    • 编辑者现在可以在维基页面中嵌入协作清单（说明文件）。协作清单自动列出维基上的活动和维基专题，可透过Special:AllEvents查看（范例）。现在，协作清单可以被加进各种维基页面中，例如：维基首页、维基专题页面、自治体页面、活动页面，甚至是使用者页面。
  • 经常项目 上周有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期技术新闻

最新留言：22天前1条留言1人参与讨论

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

本周要闻

  • 侧边栏的“获取短链接”连结（功能说明）现在会同时显示QR码，供使用者扫描或下载。维基媒体网站使用者现在多了一个便利的方式来快速分享维基媒体网站和存取分享内容。

近况更新 - 面向编辑者

  • 维基媒体基金会正在开发名为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

深入了解

  • 云端服务现已支援IPv6，这将大幅提升维基媒体平台的可扩缩性与安全性，为未来做好准备。欲知详情的技术贡献者可参阅这篇博文，深入了解我们迈向IPv6的历程。

会议与活动

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2025年5月12日 (一) 22:37 (UTC)

检索自“https://zh.wikipedia.org/w/index.php?title=User_talk:SuperGrey/存檔4&oldid=87483380”