跳转到内容

维基百科:互助客栈/技术/存档/2022年7月

添加链接
维基百科，自由的百科全书


模板 cite book 显示风格

本主题全部或部分段落文字，已移动至Template talk:Cite book。执行人：Jimmy-bot（留言） 2022年7月3日 (日) 08:14 (UTC)。

是否依然有必要保留“Template:(语言代码)-link”系列重定向（比如Template:en-link）？

本主题全部或部分段落文字，已移动至Template talk:Internal link helper。执行人：Jimmy-bot（留言） 2022年7月4日 (一) 00:14 (UTC)。

“犭亚兽目”条目标题显示错误

本主题全部或部分段落文字，已移动至Talk:𰡉兽目。执行人：Jimmy-bot（留言） 2022年7月6日 (三) 00:14 (UTC)。

不留重定向式移动

多次发现不留重定向移动或者删除页面之后，链入原名称的网页变成了红链，不知道有没有比较好的办法提醒移动者注意链入页面？尤其是早期比较基础的一些条目。或者是否有一些统计？另外，提删者应该也要注意先清理链入页面。--Kethyga（留言） 2022年6月30日 (四) 00:32 (UTC)

前者是移动者的义务，后者则是提删者或管理员的。不为自身之操作善后是不负责任的行为。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年6月30日 (四) 08:04 (UTC)
如果有类似“当前页面存在链入，您不可删除”的提醒，可以减少记忆部分方针的必要性。--Kethyga（留言） 2022年6月30日 (四) 09:29 (UTC)
换成“当前页面存在链入，您确认删除？”（可能存在讨论页的无效链入）--Kethyga（留言） 2022年6月30日 (四) 09:33 (UTC)
本来就有这个提示了...您觉得有用吗？--Xiplus#Talk 2022年6月30日 (四) 12:20 (UTC)
有这个提示吗？我怎么一点印象都没有（在移动的时候）--MilkyDefer 2022年7月1日 (五) 02:30 (UTC)
删除页面确实有这个提示，移动页面的则是有提案人所建议“提醒移动者注意链入页面”的提示。--Xiplus#Talk 2022年7月1日 (五) 04:17 (UTC)

请求扩张reflist的模板限制

主条目：对穆斯林的迫害
参见：Wikipedia:互助客栈/求助 § 请求检查这三个地方的来源显示异常的问题

我是不知道现在reflist的模板限制究竟在哪个限度，但是现在该条目的reflist显然已经超出限制，然而已经有部分来源因此而被迫删去，我不想为了“维持模板的正常显示”再把多出来的那些注脚来源都删掉了。--哥斯拉君（有话要说吗？） 2022年6月27日 (一) 09:17 (UTC)

初步调整，将{{reflist}}展开了代替。不过同样建议，一些不必要或者预期不太可能创建的外语链接（使用{{ilh}}相关的引入）就不要保留，可以适当降低展开量。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月27日 (一) 09:53 (UTC)
Template:宗教自由里{{le}}绿链比较多，占用比较多。每个条目只有2MB（约2百万字节）限额，而该模板会占用40万字节，即20%。目前在条目中暂时换为除去绿链的模板:宗教自由/min以免影响脚注。另见Wikipedia_talk:模板限制#Category:引用模板后大小超过限制的页面，已完成的改进不够用，进一步还没做。--YFdyh000（留言） 2022年6月27日 (一) 12:28 (UTC)
阁下可以大致教我这个是怎么做到的吗？我可以把另外两种也无绿链化。--哥斯拉君（有话要说吗？） 2022年6月27日 (一) 12:50 (UTC)
/min版本只是精简移除了导航模板里的绿链，不能算长久之计，只是针对长条目的权宜之策。另外，仍然逼近限制，见条目页面源代码中的“Post‐expand include size: 2072805/2097152 bytes”。--YFdyh000（留言） 2022年6月27日 (一) 13:12 (UTC)
模版限制是由MediaWiki软件施加的，不针对单一模版施行。如果你要提升限制需要去跟phab提。 --MilkyDefer 2022年6月27日 (一) 12:32 (UTC)
不知道ilh的瓶颈是哪里？如果用魔术字{{#language:}}来替代Module:Ilh/data的这部分功能，是否能降低开销？--百無一用是書生 (☎) 2022年6月27日 (一) 12:58 (UTC)
或者用{{Link-Wikidata}}代替ilh，似乎开销小一些？--百無一用是書生 (☎) 2022年6月27日 (一) 13:06 (UTC)
瓶颈在模板（各阶段）输出的HTML代码字节数，ilh设计上输出的代码比较冗余，参考Wikipedia_talk:模板限制#缩减Internal_link_helper输出的代码。--YFdyh000（留言） 2022年6月27日 (一) 13:16 (UTC)
原来是输出的HTML代码字节数啊。那么改成“可参考en:xxx创建“xxx””不就短多了？--百無一用是書生 (☎) 2022年6月30日 (四) 12:27 (UTC)
额，理解错了--百無一用是書生 (☎) 2022年6月30日 (四) 12:33 (UTC)
已经亲自去mediawiki那边请求去了。--哥斯拉君（有话要说吗？） 2022年7月1日 (五) 08:57 (UTC)

感谢诸位阁下的建议，目前reflist模板已经正常显示了。--哥斯拉君（有话要说吗？） 2022年6月27日 (一) 12:47 (UTC)

设置半自动提报内容评选工具

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

RT，建议在工具里面加入提报内容评选DYK、GA、FA、FP功能。设计提报条目评选功能的时候，建议加入初步核查条目提报资格的功能，把存在维护模板的、新条目近期没有重大或字节不够等问题的条目挡下来。如果这个能实施，一来可以简化提报流程，二来可以直接阻挡明显不符合标准的内容提名，有效节省资源。--百战天虫（留言） 2022年6月10日 (五) 14:59 (UTC)

ITN也可以搞起来。顺便@Xiplus--百战天虫（留言） 2022年6月10日 (五) 15:00 (UTC)

可以是独立工具，不是非得加到Twinkle内。--Xiplus#Talk 2022年6月10日 (五) 15:11 (UTC)
单独做一个太麻烦了，用现有工具方便大家使用。--百战天虫（留言） 2022年6月12日 (日) 05:39 (UTC)
说实在的，好像没有这种必要（有的话当然好，问题是真的行吗？）。因为，连短短几分钟的提名都这么懒吗...？--Z7504非常建议必要时多关注评选（留言） 2022年6月11日 (六) 14:30 (UTC)
不是懒的问题，这个工具可以帮助不熟悉的评选标准的编者正确提名。--百战天虫（留言） 2022年6月12日 (日) 05:39 (UTC)
又不是说反对增加这个功能，只是喔，要建就是要给用户测试、给用户做批判的准备嘛，毕竟是长远的东西，不然还是打消这种念头吧。当时DYK评选要增加提名按钮就很有争议了，虽然最后还是施行了。没有十全十美的提案，真要酸难用就酸吧，习惯了就好，或许酸的用户还可以点出事实而没有人知道呢，所以才说这些想提名的用户到底够不够懒嘛。--Z7504非常建议必要时多关注评选（留言） 2022年6月13日 (一) 08:43 (UTC)
偏好独立工具，现在Twinkle里东西已经够多了。--冥王欧西里斯（留言） 2022年6月14日 (二) 06:25 (UTC)
建议作为独立工具，Special:参数设置#mw-prefsection-gadgets也有“在条目的左侧工具栏下添加新条目推荐提报工具”。--BlackShadowG Slava Ukraini! 2022年6月13日 (一) 15:31 (UTC)
讲的那么多看来又被讲中了。如果不要加在Twinkle中，要做成“独立工具”，请问“独立工具”又是什么？反正都有按钮提名了还是嫌不够就是了嘛。--Z7504非常建议必要时多关注评选（留言） 2022年6月14日 (二) 09:36 (UTC)

小(！)意见，独立工具，希望移动版可以用-- Evesiesta Deutschland(因为签名太长而决定手动签名的维基人)（签|论） 2022年6月17日 (五) 10:27 (UTC)

先建了再说吧，一直讲独立工具，所以独立工具叫做什么？连工具都还没出来如何叫别人来测试呢？--Z7504非常建议必要时多关注评选（留言） 2022年6月18日 (六) 14:02 (UTC)
那就叫Xiplus设计一下独立工具吧。--百战天虫（留言） 2022年6月19日 (日) 05:12 (UTC)
真的有了再说吧，不然都只是白谈而已，看了这串讨论串只想睡觉而已，完全未见实质意义。--Z7504非常建议必要时多关注评选（留言） 2022年6月21日 (二) 01:23 (UTC)
Xiplus又不是领工资干活的，为啥要指名道姓让人家白干活呢 +1 --百無一用是書生 (☎) 2022年6月24日 (五) 06:41 (UTC)
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

Google 搜索中文维基结果为移动端链接

最近 Google 搜索结果中排名靠前的中文维基百科链接为移动端链接https://zh.m.wikipedia.org/

以前偶尔会出现移动端链接，但是最近我搜索结果全部都是。我试了Bing好像没有这个问题，英文维基也没有问题。有其他人遇到这个问题吗？

地点：美国 SF bay area --InstantNull（留言） 2022年7月1日 (五) 21:16 (UTC)

相关讨论: #Google 错误地索引 .m 链接--Kanashimi（留言） 2022年7月2日 (六) 03:52 (UTC)

为何Template:僻字模板没有Template:全局僻字一样的繁简区分的功能？

如题。理论上标注单个僻字使用的Template:僻字模板也会遇到像Template:全局僻字#繁简转换_2提到的只需要简体/繁体字符需要描述的功能。 --Kosaraju7（留言） 2022年7月3日 (日) 09:38 (UTC)

繁简字体的显示差异

在吉尔戴鱼科这个条目中，信息框内的图片描述文字（梳齿迪斯科锯鱼的化石，藏于维也纳自然史博物馆）在大陆和新马简体模式下，可在一行内正常显示，而切换至港澳台繁体模式阅览时，最后一个“馆”字被挤到了第二行，十分影响美观。请问这是个人设备或浏览器的问题，还是繁简字体的宽度本就不同？--萧漫（留言） 2022年7月3日 (日) 18:15 (UTC)

我用的Timeless皮肤，所有变体都挤到了第二行，不止繁体的。--Kethyga（留言） 2022年7月4日 (一) 03:55 (UTC)
是字体导致的。--安忆Talk 2022年7月4日 (一) 08:10 (UTC)

Tech News: 2022-27

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 July. It will be on non-Wikipedia wikis and some Wikipedias from 6 July. It will be on all wikis from 7 July (calendar).
  • Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 5 July at 07:00 UTC (targeted wikis) and on 7 July at 7:00 UTC (targeted wikis).
  • The Beta Feature for DiscussionTools will be updated throughout July. Discussions will look different. You can see some of the proposed changes.
  • This change only affects pages in the main namespace in Wikisource. The Javascript config variable proofreadpage_source_href will be removed from mw.config and be replaced with the variable prpSourceIndexPage. [1]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

2022年7月4日 (一) 19:31 (UTC)

专题评级工具

本主题全部或部分段落文字，已移动至User talk:Chiefwei/rater、Wikipedia talk:专题。执行人：Jimmy-bot（留言） 2022年7月14日 (四) 08:14 (UTC)。

图片无法正常显示

链入源代码[[File:YouBike.svg|200px]]，换成其他图片都可以正常显示，只有这张图片跑不出来会变成连结，不晓得是发生了什么问题，有请高手。--Bangardi 2022年7月4日 (一) 06:49 (UTC)

在MediaWiki:Bad_image_list中声明的图片会受到限制。--安忆Talk 2022年7月4日 (一) 08:13 (UTC)
@AnYiLin：好的，非常感谢！--Bangardi 2022年7月4日 (一) 15:24 (UTC)

@Wcam：请问阁下是基于什么理由将该图片限制？--Bangardi 2022年7月4日 (一) 15:24 (UTC)

@Happy60907：已经移除。该非自由图片过去曾被大量滥用，故加入Bad_image_list以防止违反WP:NFCC#8的滥用。--Wcam（留言） 2022年7月5日 (二) 14:41 (UTC)

Google搜索结果总是显示行动版的中文维基页

我用台式电脑在 Google 搜索中文词时，结果中的维基网页时常会是行动版的（网址中有 .m. ），但是 Google 本身是显示桌上型的网页，并且其他搜寻结果也都是桌上型网页，还有在搜寻英文词时，英文维基页通常也是正确的，单单就只有中文维基显示成行动版，不知道是不是中文维基这边有什么地方没设定好？--C9mVio9JRy（留言） 2022年7月9日 (六) 10:54 (UTC)

#Google 错误地索引 .m 链接。--安忆Talk 2022年7月9日 (六) 10:58 (UTC)

2022年第28期技术新闻

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

最近更改

本周晚些时候的更新

  • 本周没有新的MediaWiki版本。
  • 出于定期数据库维护的原因，某些维基站点将进入只读模式数分钟。维护将于7月12日7:00 (UTC) 对s3数据库组的维基站点进行。

未来更新

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

2022年7月11日 (一) 19:24 (UTC)

Global bot approval request for Dušan Kreheľ (bot)

您好!

I apologize for sending this message in English. 请帮助翻译至您的语言.

In accordance to the policy, this message is to notify you that there is a new approval request for a global bot.

The discussion is available at Steward requests/Bot status#Global bot status for Dušan Kreheľ (bot) on Meta.

Thank you for your time.

Best regards,
—Thanks for the fish! talk•contribs 2022年7月11日 (一) 21:07 (UTC)

依据方针，如需申请全域机器人权限，监管员将使用MMS通知订阅了相关消息的社群。本机器人的申请详见元维基的相关页面，请前往发表意见。（译注：另请参阅本地申请页面） Stang★ 2022年7月11日 (一) 23:03 (UTC)

2022年第28期技术新闻

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

最近更改

本周晚些时候的更新

  • 本周没有新的MediaWiki版本。
  • 出于定期数据库维护的原因，某些维基站点将进入只读模式数分钟。维护将于7月12日7:00 (UTC) 对s3数据库组的维基站点进行。

未来更新

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

2022年7月11日 (一) 19:24 (UTC)

Global bot approval request for Dušan Kreheľ (bot)

您好!

I apologize for sending this message in English. 请帮助翻译至您的语言.

In accordance to the policy, this message is to notify you that there is a new approval request for a global bot.

The discussion is available at Steward requests/Bot status#Global bot status for Dušan Kreheľ (bot) on Meta.

Thank you for your time.

Best regards,
—Thanks for the fish! talk•contribs 2022年7月11日 (一) 21:07 (UTC)

依据方针，如需申请全域机器人权限，监管员将使用MMS通知订阅了相关消息的社群。本机器人的申请详见元维基的相关页面，请前往发表意见。（译注：另请参阅本地申请页面） Stang★ 2022年7月11日 (一) 23:03 (UTC)

介绍我编写的wgULS、wgUVS现代化替代品——HanAssist小工具

各位维基人好，

中文维基百科站内的wgULS和wgUVS函数自部署已有十余年的时间。在这十余年间，MediaWiki、JavaScript及其开发环境都发生了翻天覆地的变化，而这两个函数的若干问题也逐渐显露出来：

  1. 仍然使用旧式的wgXXX类名称，污染全局空间。现今MediaWiki中的此类变量全部通过mw.config.get()获取，但这两个函数并未也无法跟进。
  2. 函数名称使用意义不明的缩写，影响代码可读性。
  3. 参数列表过长，影响阅读。设计良好的JavaScript函数最多仅应包含两个参数。设想一下，如果像这样调用wgULS()（此代码确实存在）：
    wgULS( undefined, undefined, '显示%s的用户日志', '顯示%s的使用者日誌', '顯示%s的用戶日誌' );
    难道不会使代码非常难以阅读及维护？
  4. 并非类型安全。wgULS和wgUVS允许任何类型的参数传入，且返回值类型亦不确定，这可能会导致非预期的行为发生，并且使得代码难以维护。
  5. 没有代码文档。这使得不了解这些函数的人必须通过直接阅读代码来确定它们的用法。

为了解决这些问题，我开发了HanAssist小工具，作为wgU*S的现代API替代。小工具页面位于Diskdance/public/HanAssist，GitHub仓库位于此处。

我认为的几个亮点：

  1. 代码使用TypeScript编写；
  2. 支持新的命名参数语法，显著提升代码可读性；
  3. 完善的代码文档及类型定义；
  4. 新增一个批量转译消息的API，在代码大量依赖中文变体消息时可以使得代码更紧凑、更模块化。
用法示例
( function( HanAssist ) {
	// 等同于 wgULS( '一天一苹果，医生远离我。', '一天一蘋果，醫生遠離我。' );
	HanAssist.localize( { hans: '一天一苹果，医生远离我。', hant: '一天一蘋果，醫生遠離我。' } );
	
	// 等同于 wgULS( undefined, undefined, 'IP用户', 'IP使用者', 'IP用戶' );
	HanAssist.localize( { cn: 'IP用户', tw: 'IP使用者', hk: 'IP用戶' } );
	
	// 等同于 wgUVS( '一天一苹果，医生远离我。', '一天一蘋果，醫生遠離我。' );
	HanAssist.vary( { hans: '一天一苹果，医生远离我。', hant: '一天一蘋果，醫生遠離我。' } );
	
	// 批量转译消息
	// 推荐配合 mw.messages 使用
	mw.messages.set( HanAssist.parse( {
		'article': { hans: '条目', hant: '條目' },
		'category': { hans: '分类', hant: '分類' },
		'categories': { hans: '分类', hant: '分類' },
		'image': { hans: '文件', hant: '檔案' },
		'images': { hans: '文件', hant: '檔案' },
		'minute': '分',
		'minutes': '分',
		'second': '秒',
		'seconds': '秒',
		'week': '周',
		'weeks': '周',
		'search': { hans: '搜索', hant: '搜尋' },
		'SearchHint': { hans: '搜索包含$1的页面', hant: '搜尋包含$1的頁面' },
		'web': { hans: '站点', hant: '站點' },
	} ) );
	mw.msg( 'categories' ); // => 界面语言为简中：“分类”；繁中：“分類”
	mw.msg( 'SearchHint', 'Apple' ); // => 界面语言为简中：“搜索包含Apple的页面”；繁中：“搜尋包含Apple的頁面”
} ( mw.libs.HanAssist ) );

另有一点需要澄清：如果将来本小工具成功部署，旧API在短期内不会移除，仍然保留（但是会标记为deprecated）。

欢迎各位技术向维基人测试和反馈本小工具，并提出宝贵的意见和建议，谢谢！--Diskdance 2022年6月19日 (日) 07:58 (UTC)

考虑把这个HanAssist挂到mw.libs下或者mw对象吗？我觉得wgU*S也可以这么弄，就是引用得太多了。--安忆Talk 2022年6月19日 (日) 12:23 (UTC)
这个做法我曾经考虑过，但后来没有这么做，因为小工具不是MediaWiki软件的一部分。--Diskdance 2022年6月19日 (日) 13:59 (UTC)
稍等，如果mw.libs的意图就是给第三方库用的话……先让我考虑考虑。--Diskdance 2022年6月19日 (日) 14:01 (UTC)
是吧，我看里面有ve的东西。--安忆Talk 2022年6月19日 (日) 14:48 (UTC)
我今天考虑了一下，我自己没有什么特别的意见。如果社群的意见是挪到mw.libs下，可以考虑移动。--Diskdance 2022年6月20日 (一) 13:56 (UTC)
@AnYiLin：请问接下来流程应该如何走？我单独问了几个人，反响还可以，但是就是没人来这里投票支持，这样的话也没办法直接公示吧？--Diskdance 2022年6月23日 (四) 11:53 (UTC)
@AnYiLin：经过思考之后现已移动到mw.libs。cc@Xiplus。--Diskdance 2022年6月25日 (六) 04:20 (UTC)
(～)补充：这是部分小工具使用HanAssist重写的效果——Diskdance/public/popups-hanassist-ify.js、Diskdance/public/edittools-delh-hanassist-ify.js，供各位参考。--Diskdance 2022年6月22日 (三) 10:40 (UTC)

问了不少维基人，反响还可以。接下来考虑在本站部署本小工具，替换掉wgU*S并默认启用（EDIT: 不需要默认启用）。

小工具定义如下： 

HanAssist[ResourceLoader|hidden|targets=desktop,mobile]|HanAssist.js

其他脚本调用小工具的代码示例： 

mw.loader.using( 'ext.gadget.HanAssist', function() {
	// Use HanAssist here
} );

敬请各位发表自己的看法，谢谢。--Diskdance 2022年6月24日 (五) 10:47 (UTC)

让其他工具依赖的lib，为何要默认启用？--Xiplus#Talk 2022年6月24日 (五) 11:29 (UTC)
有道理 囧rz……是我搞错了。--Diskdance 2022年6月24日 (五) 12:04 (UTC)
考虑到HanAssist会shim掉wgU*S，而本站现有大量小工具使用wgU*S，为了避免部署后出现大量deprecate warning，所以拟定部署方案如下：
  1. 先部署不含wgU*S垫片（shim）的HanAssist，让新API和旧API共存60天，以评估新API可能带来的问题；
  2. 若评估无问题，60天后，将site-lib中的wgU*S移除，改为依赖含有wgU*S垫片（shim）的HanAssist，deprecate wgU*S；
  3. 在相当长的一段时间后（>=1年），彻底移除wgU*S。
现征求社群意见。--Diskdance 2022年6月25日 (六) 04:24 (UTC)
建议“deprecate warning”延后，如180天，以观察主动迁移后是否会暴露出新问题。即共存30天是alpha阶段，beta阶段不显示警告。--YFdyh000（留言） 2022年6月25日 (六) 04:46 (UTC)
shim是否也要延后？--Diskdance 2022年6月25日 (六) 04:55 (UTC)
我不确定shim影响如何，所以暂无意见。--YFdyh000（留言） 2022年6月25日 (六) 05:18 (UTC)
延后至60天。cc@SunAfterRain、Alexander Misel、Lt2818：。--Diskdance 2022年6月25日 (六) 05:26 (UTC)
我建议是2022/12/31和2023/12/31（或2024/06/30），垫片直接换了，只是先不警告--SunAfterRain 2022年6月25日 (六) 05:30 (UTC)
目前看来先部署不含垫片的HanAssist似无异议。现🕗 公示7日，2022年7月2日 (六) 10:20 (UTC) 结束。--Diskdance 2022年6月25日 (六) 10:20 (UTC)
公示时间到。@Xiplus、@AnYiLin，请问能否部署？不含shim的版本位于Diskdance/public/HanAssist-noshim.js，gadget definition按照这里写的来。--Diskdance 2022年7月2日 (六) 11:25 (UTC)
完成--Xiplus#Talk 2022年7月2日 (六) 12:14 (UTC)
谢谢。麻烦各位维基人检查一下是否存在其他问题，并且可以考虑先随机抽取一些小工具迁移看看效果。
cc@SunAfterRain、@YFdyh000、@A2569875、@Lt2818。--Diskdance 2022年7月2日 (六) 12:18 (UTC)
两个小工具已经提请编辑请求试用HanAssist。--Diskdance 2022年7月5日 (二) 12:49 (UTC)
HanAssist社区文档页：Wikipedia:HanAssist。--Diskdance 2022年7月8日 (五) 05:24 (UTC)
看起来没问题。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年7月13日 (三) 14:51 (UTC)
好的，谢谢支持！但是目前看来迁移的进程比较缓慢，似乎编辑请求都没人处理……--Diskdance 2022年7月13日 (三) 15:46 (UTC)

请求修复被误加的标签

如题，Special:Diff/72711568只是一笔加入姊妹计划模板的普通编辑，却被Special:标签为“增加不可靠来源”，希望可以修复，谢谢。--回廊彼端（留言） 2022年7月17日 (日) 10:24 (UTC)

建议新增Abusefilter-warning-车牌

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行人：Billytanghh 讨论 欢迎参与亚洲月 2022年7月15日 (五) 21:03 (UTC)。

现时，不少所有地区或国家都有向车辆发放车牌号码，识别谁使用相关车辆。维基百科有不少条目列出车牌号码，特别是交通条目，方便相关爱好者收藏。个人认为于维基百科列出车牌号码是鼓吹起底行为，就像将个人地址及电邮地址公开，部分地下平台或政府官方平台提供车牌持有人起底服务，举例：香港铿锵集721查册事件，而且相关车牌没有可靠来源证明，违反可靠来源方针。现建议新增Abusefilter-warning，提示用户不要添加车牌号码。 --唔好阻住我爱国（留言） 2022年7月14日 (四) 15:35 (UTC)

请举出更详细的例子，另外看描述很难借助过滤器实现本提案。 Stang★ 2022年7月14日 (四) 16:59 (UTC)
定义：什么是“车牌号码”？存在什么样的格式？至少提问题之前想一个初步方案作为答案，而不是给一个模糊的概念。你这样做需求会被开发打死的。——Sakamotosan路过围观 | 避免做作，免敬 2022年7月15日 (五) 00:35 (UTC)
所有无可靠来源的信息显然可移除。牵扯个人隐私的已公开信息，可以在正文中适当隐去。车牌格式各异，添加过滤器存在技术困难，能否证明可行。观察您近日的编辑，部分内容可能属于爱好者信息、WP:NOT#INFO，但也需考虑，公共交通车辆的车牌是否不涉及隐私，如城巴#2014年、龙运巴士#意外事故。京A88519事件这种公共事件中的私人车牌，又是否牵扯隐私。--YFdyh000（留言） 2022年7月15日 (五) 01:07 (UTC)
@Cwek@Stang：
台湾车牌格式：台湾车辆牌照
香港车牌格式：两个英文字母+三至四个数字
中国车牌格式：[6]
@YFdyh000：
不论公共车辆的车牌号码是否涉及隐私，但相关车牌号码违反可靠来源要求。重温过去交通工具报导，没有一宗标示车牌号码，部分报导更会对车牌号码“打格子”。--唔好阻住我爱国（留言） 2022年7月15日 (五) 02:11 (UTC)
您是否考虑过检测相关格式导致的误判？--YFdyh000（留言） 2022年7月15日 (五) 02:17 (UTC)
同上类似问题。或者是否存在不止这些判断例子？主要是“车牌号”是一个十分广泛的判断例子，如果为所谓“隐私”而使用机械式的判断，可能会弄巧反拙。不过如果必要的话，完全可以出于隐私的需要，允许手工移除+监督版本移除来灵活处理。——Sakamotosan路过围观 | 避免做作，免敬 2022年7月15日 (五) 02:29 (UTC)
@YFdyh000@Stang
我比较偏向使用这种标示方法-MediaWiki:Abusefilter-warning-BLP-classification，只是警告编辑者确定相关编辑是否符合可靠来源要求及于编辑历史标示车牌使用，并提示管理员检示相关页面，而非全面禁用，所以即使误判也无阻编辑。--唔好阻住我爱国（留言） 2022年7月15日 (五) 02:40 (UTC)
没有明显迹象证明相关内容必需移除。除非检测上下文含“车牌”等内容，不然检测格式极易误判，导致莫名的警告“骚扰”。如果不能达到高命中率，至多打tag进行标记，但如果没人巡阅、未确立需移除的共识，还不如定期手动检索相关内容。--YFdyh000（留言） 2022年7月15日 (五) 02:47 (UTC)
@Xiplus：
我想知道将车牌列入abusefilter-warning的可行性多大。--唔好阻住我爱国（留言） 2022年7月15日 (五) 04:43 (UTC)
请提供至少5个应阻拦的编辑差异。--Xiplus#Talk 2022年7月15日 (五) 05:10 (UTC)
车牌恐怕不好识别，毕竟各国车牌不一样。不过个人认为没有媒体报道的私人车牌应该移除。桐生ここ★[讨论] 2022年7月15日 (五) 06:34 (UTC)
@桐生ここ@Xiplus：
即是检测到类似格式的予以警告。如果没有标纤的话，移除车牌资料就像大海捞针一样。举例子，引用下方常出现的表格，香港的车牌号码组合是两个英文字+四个数字，通常配合表格出现。
同类型的表格于中文维基收录超过200条目，下列表格来自九龙巴士46X线
车队编号 车牌
ATENU803 TV1089
ATENU901 TX5684
ATENU909 TX8474
ATENU956 UA4221
ATENU958 UA4544
ATENU959 UA5163
ATENU968 UA8369
ATENU989 UB8333
ATENU1072 UD4585
ATENU1120 UG6836
ATENU1136 UH4491
ATENU1137 UH2535
ATENU1138 UH3096
ATENU1140 UH3596
ATENU1142 UH4324
ATENU1144 UH5651
ATENU1146 UH5647
ATENU1195 UK9856
ATENU1197 UM2679
ATENU1246 VB4136
ATENU1256 VB8056
ATENU1261 VB8821
ATENU1263 VC1394
ATENU1264 VC1809
ATENU1265 VC3044
ATENU1281 VD4265
ATENU1282 VD5006
ATENU1283 VD5664
ATENU1289 VD7918
ATENU1445 VM 571

--唔好阻住我爱国（留言） 2022年7月15日 (五) 09:34 (UTC)

请提供编辑差异连结。--Xiplus#Talk 2022年7月15日 (五) 09:59 (UTC)
@Xiplus：
是说这个吗？
[7]--唔好阻住我爱国（留言） 2022年7月15日 (五) 13:46 (UTC)
还找到一个：[8] 中国大陆的。--QiuLiming1（留言） 2022年7月15日 (五) 16:03 (UTC)
没找到多少可靠来源完整指明，感觉可以回退或删减。但是，公共事件中披露的可识别编号，哪些属于隐私或不必要收录，值得商榷。目前来说，不看好列入过滤器。--YFdyh000（留言） 2022年7月15日 (五) 18:20 (UTC)
@YFdyh000：
在公共事件中披露的可识别编号必定有来源，有符合可靠来源要求的编辑是合规的，为何害怕警告？--唔好阻住我爱国（留言） 2022年7月16日 (六) 02:21 (UTC)
“现建议新增Abusefilter-warning，提示用户不要添加车牌号码”，按我理解是不论是否有来源都不加。如果您认为有来源提及就可以，那么需要考虑限度了，如视频报道中的车牌。--YFdyh000（留言） 2022年7月16日 (六) 02:47 (UTC)
总之符合可靠来源要求就可以了！
.
2022年7月20日 (三) 03:54‎ 编辑者A (对话 贡献‎) 19,8964字节 +555 →‎建议新增Abusefilter-warning-车牌：​ 回复 复原 （标签：回复 源代码 疑似车牌)--唔好阻住我爱国（留言） 2022年7月16日 (六) 03:04 (UTC)
这个属于资料性的信息，是否收录可能需要讨论，是否算WP:FAN和WP:NOT#INFO。--YFdyh000（留言） 2022年7月15日 (五) 18:14 (UTC)
@YFdyh000：
其实早有共识交通条目不收录车牌，唯ip 用户不知道。--唔好阻住我爱国（留言） 2022年7月16日 (六) 01:57 (UTC)
补充一下，是除非有可靠来源佐证（当然只能列举某些较重要的且对相关路线有较大影响力，例如ATR1／HJ2127）。Fran·1001·hk 2022年7月16日 (六) 03:19 (UTC)
就著这个车牌，根据某爱好者网站显示，这个车牌属于某巴士的第一辆车。
但相关资料缺乏可靠来源支持及没有有效介绍，建议abusefiltter-warning适用于这个状况。--唔好阻住我爱国（留言） 2022年7月16日 (六) 04:11 (UTC)
其实九巴官方有相片和文字提及的[9]，此外来源不一定靠网上搜寻，可以透过第三方书籍一样也可（一个车型有数百辆车，不利用车牌specified便令读者难以理解是哪辆车）。Fran·1001·hk 2022年7月16日 (六) 04:45 (UTC)
@Fran1001hk：
如果今日容许巴士列出车牌，我相信所有交通意外条目都会因此列出双方的车牌号码，进行滋扰行为。
另外，文章都没有列出车牌号码。
码--唔好阻住我爱国（留言） 2022年7月16日 (六) 06:23 (UTC)
所以个人认为整个关键是相关用户加入车牌的目的。如果加入车牌目的含有滋扰某方的意味，这便可视作扰乱。反之，如果加入的目的是协助读者分辨哪辆用车且有可靠来源佐证，因为符合可供查证的方针也没有扰乱的意味，所以没有违反方针。另外，所有可靠来源并不能纯粹只看文字，图片也得要看。Fran·1001·hk 2022年7月16日 (六) 06:43 (UTC)
说真的，如果没有label的话，作为一个维护条目角色，很难有效率地确定相关编辑合符要求。难道要手动巡查？--唔好阻住我爱国（留言） 2022年7月16日 (六) 07:11 (UTC)
既然大家对发布前发出警告有不满的，现建议只用label取代
例子：
‘标签：不当标点符号’
这个label只会在“检视历史”才会出现，不会发出警报，至少可以加快识别车牌使用，增加维护效率。
现希望讨论什么类型的编号才需要列入标签范围内。--唔好阻住我爱国（留言） 2022年7月16日 (六) 08:39 (UTC)
建议了解一下WP:过滤器语法和正则表达式，高效且准确的识别各种车牌格式可能难以做到，也似乎不适宜过滤器即时完成，将影响网站性能。建议您先通过检索（搜索），清理现有条目中的此类内容，让大家看到清理是可行且卓有成效的。例如新界区专线小巴1号线中的表格。--YFdyh000（留言） 2022年7月16日 (六) 21:15 (UTC)
@YFdyh000：
其实我已清理了九龙巴士1-30号的车牌资料，唯ip 用户在我删除后马上加入。--唔好阻住我爱国（留言） 2022年7月17日 (日) 01:38 (UTC)
对于这样的条目使用WP:编辑提示如何？车牌用过滤器规则实在难以匹配。桐生ここ★[讨论] 2022年7月17日 (日) 23:48 (UTC)
@桐生ここ：
Abusefilter-warning ，只有admin 才可增加或删除或编辑
编辑提示，编辑次数达50次的编辑者即可增加或删除或编辑
.
不过都支持。
没有办法下的支持--唔好阻住我爱国（留言） 2022年7月18日 (一) 02:55 (UTC)
各地车牌格式繁杂，且部分格式难以与其他文字区分，误判几率高，不适合制作成反滥用过滤器。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年7月18日 (一) 02:15 (UTC)

中文维基百科如何启用黑暗模式？

en:Wikipedia:Dark_mode英维已经有小工具了。--Shinohara Chihiro（留言） 2022年7月16日 (六) 11:46 (UTC)

关闭。我文章没看完，后面有编辑 common.css 启用的方法。--Shinohara Chihiro（留言） 2022年7月16日 (六) 13:08 (UTC)

可以考虑试试这个： 

mw.loader.load('//zh.wikipedia.org/w/index.php?title=User:桐生ここ/js/Gadget-darkmode.js&action=raw&ctype=text/javascript');

桐生ここ★[讨论] 2022年7月17日 (日) 23:44 (UTC)

谢谢啦，不过我已经按照教程弄好了。--Shinohara Chihiro（留言） 2022年7月18日 (一) 03:57 (UTC)

T:FilemoverTalkpageNotice

本主题全部或部分段落文字，已移动至Template talk:FilemoverTalkpageNotice。执行人：Jimmy-bot（留言） 2022年7月27日 (三) 08:14 (UTC)。

Template:Infobox comics creator多个简体中文参数无法工作

本主题全部或部分段落文字，已移动至Template talk:Infobox comics creator、WikiProject talk:漫画家。执行人：Jimmy-bot（留言） 2022年7月27日 (三) 16:14 (UTC)。

Module:Adjacent stations需要更新

本主题全部或部分段落文字，已移动至Module talk:Adjacent stations。执行人：Jimmy-bot（留言） 2022年7月27日 (三) 16:14 (UTC)。

2022年第29期技术新闻

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

问题

本周后期变更

  • MediaWiki新版本将于7月19日部署至测试维基及MediaWiki.org，及于7月20日部署至非维基百科站点及部分维基百科，并于7月21日部署至所有站点，参见日历。

将来更新

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

2022年7月18日 (一) 22:59 (UTC)

翻了一下，似乎中文区只有Liangent符合社区代表的条件?--百無一用是書生 (☎) 2022年7月19日 (二) 01:44 (UTC)
恐怕也不行，12个月内没有代码被合并。--砜中嘌呤的白磷萃取 打谱 2022年7月20日 (三) 15:54 (UTC)

音乐专题模板

本主题全部或部分段落文字，已移动至Template talk:音乐专题。执行人：Jimmy-bot（留言） 2022年7月29日 (五) 16:14 (UTC)。

如何让监视列表不要按天分类或者一次性查看条目自上次查看后的所有修改？

我使用了合并修改的功能，这样可以直接点“X次更改”一口气看不同，很是方便。但是他却非要按天分开，没法一次性看监视条目自上次观看至今的修改。有没有办法修改呢？谢谢。

--Fireattack（留言） 2022年7月24日 (日) 04:00 (UTC)

在可视化编辑器输入后加注引文脚注，之后继续输入内容时概率出现吞字

如题，只会在脚注后面第一个字出现，形象一点举个例子说：

这里有一个句子： 

   这是一个例子[1]

比方说继续向后输入下一个字（例如“内”，此处使用微软拼音输入法，不过貌似微软日语和其他这种一个字要按几个字母的都可能？？？不过暂未尝试其他输入法），先按n： 

   这是一个例子[1]n 【n>1.你 2.呢 3.那 4.您 5.年】←输入法

按e： 

   这是一个例子 【ne>1.呢 2.讷 3.那 4.呐 5.哪】

按i： 

   这是一个 【nei>1.内 2.馁 3.那 4.哪 5.娞】

按1： 

   这是

如果继续输，可能还会删更多，当然也可能直接卡住写不动，如果是卡住不动，按退格可能会向后删内容，需要重新点击输入区聚焦再继续。

不知道是个人操作、输入法问题抑或是VE问题？来问问 --𝘿𝙖𝙧𝙚𝙙𝙚𝙢𝙤𝙙𝙖𝙞𝙨𝙪𝙠𝙞 𝟭𝟭𝟰𝟱𝟭𝟰—好耶~ 书于 2022年7月25日 (一) 15:46 (UTC)

好像是 注脚、VE、输入法之间的不兼容的问题。——Sakamotosan路过围观 | 避免做作，免敬 2022年7月26日 (二) 00:56 (UTC)
请问阁下有具体一点的信息吗，谢谢𝘿𝙖𝙧𝙚𝙙𝙚𝙢𝙤𝙙𝙖𝙞𝙨𝙪𝙠𝙞 𝟭𝟭𝟰𝟱𝟭𝟰—好耶~ 书于 2022年7月26日 (二) 04:06 (UTC)
个人使用微软新注音输入法也有这种问题。目前治标不治本的解决方式是：假设注脚加入在段落结尾，就在下一段落的开头按 enter，另启新段继续书写几个字后，把游标移回新段落开头按 Backspace ，取消分段。--S099001（留言） 2022年7月27日 (三) 13:07 (UTC)

现在怎么给一个用户发邮件进行联系？

如题，怎么好像发邮件的按钮找不到了？（进行私下联系当然是不想让第三人看到，对话页不是完全公开的嘛）--我是火星の石榴（留言） 2022年7月31日 (日) 07:12 (UTC)

对方如果没有设定电邮地址，或者关闭了（被）电邮联系功能，或者拒绝你给他发电邮，你都看不到。--MilkyDefer 2022年7月31日 (日) 07:43 (UTC)
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/技术/存档/2022年7月&oldid=73148199”