跳转到内容

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