跳至內容

維基百科:互助客棧/技術/存檔/2022年7月

維基百科,自由的百科全書


模板 cite book 顯示風格

是否依然有必要保留「Template:(語言代碼)-link」系列重定向(比如Template:en-link)?

「犭亞獸目」條目標題顯示錯誤

不留重定向式移動

多次發現不留重定向移動或者刪除頁面之後,鏈入原名稱的網頁變成了紅鏈,不知道有沒有比較好的辦法提醒移動者注意鏈入頁面?尤其是早期比較基礎的一些條目。或者是否有一些統計?另外,提刪者應該也要注意先清理鏈入頁面。--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模板限制

我是不知道現在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

2022年7月4日 (一) 19:31 (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期技術新聞

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

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

依據方針,如需申請全域機器人權限,監管員將使用MMS通知訂閱了相關消息的社群。本機器人的申請詳見元維基的相關頁面,請前往發表意見。(譯註:另請參閱本地申請頁面 Stang 2022年7月11日 (一) 23:03 (UTC)

2022年第28期技術新聞

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

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

依據方針,如需申請全域機器人權限,監管員將使用MMS通知訂閱了相關消息的社群。本機器人的申請詳見元維基的相關頁面,請前往發表意見。(譯註:另請參閱本地申請頁面 Stang 2022年7月11日 (一) 23:03 (UTC)

介紹我編寫的wgULS、wgUVS現代化替代品——HanAssist小工具

各位維基人好,

中文維基百科站內的wgULSwgUVS函數自部署已有十餘年的時間。在這十餘年間,MediaWiki、JavaScript及其開發環境都發生了翻天覆地的變化,而這兩個函數的若干問題也逐漸顯露出來:

  1. 仍然使用舊式的wgXXX類名稱,污染全局空間。現今MediaWiki中的此類變量全部通過mw.config.get()獲取,但這兩個函數並未也無法跟進。
  2. 函數名稱使用意義不明的縮寫,影響代碼可讀性。
  3. 參數列表過長,影響閱讀。設計良好的JavaScript函數最多僅應包含兩個參數。設想一下,如果像這樣調用wgULS()(此代碼確實存在):
    wgULS( undefined, undefined, '显示%s的用户日志', '顯示%s的使用者日誌', '顯示%s的用戶日誌' );
    
    難道不會使代碼非常難以閱讀及維護?
  4. 並非類型安全。wgULSwgUVS允許任何類型的參數傳入,且返回值類型亦不確定,這可能會導致非預期的行為發生,並且使得代碼難以維護。
  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.jsDiskdance/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@SunAfterRainAlexander MiselLt2818:。--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-車牌

現時,不少所有地區或國家都有向車輛發放車牌號碼,識別誰使用相關車輛。維基百科有不少條目列出車牌號碼,特別是交通條目,方便相關愛好者收藏。個人認為於維基百科列出車牌號碼是鼓吹起底行為,就像將個人地址及電郵地址公開,部分地下平台或政府官方平台提供車牌持有人起底服務,舉例:香港鏗鏘集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:FANWP: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)

Template:Infobox comics creator多個簡體中文參數無法工作

2022年第29期技術新聞

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

翻了一下,似乎中文區只有Liangent符合社區代表的條件?--百無一用是書生 () 2022年7月19日 (二) 01:44 (UTC)
恐怕也不行,12個月內沒有代碼被合併。--碸中嘌呤的白磷萃取 打譜 2022年7月20日 (三) 15:54 (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)