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

續太不智能的跳轉與搜尋

接續上次討論：要使「阿當．戴華」自動跳轉至阿當·戴華，除將「．=>·」加入全局轉換表或批量自動建立此類重新導向二個選項外，別無他法？有無更簡潔的更佳選擇？若提請「．=>·」加入全局轉換表失敗，就只有批量自動建立此類重新導向一條路？--— Gohan 2024年3月12日 (二) 05:02 (UTC)

直接修改搜尋系統，斷詞為"阿當 / 戴華"。這樣不論你打什麼符號在中間都搜尋的到。中文維基本站可能做不到，需要由MediaWiki來做搜尋演算法修改。--Shyangs（留言） 2024年3月12日 (二) 06:15 (UTC)

[1][2][3]，沒找到中文的stopwords是如何定義。或者，如果適用於所有語言，可能應該char_filter做轉換？--YFdyh000（留言） 2024年3月12日 (二) 11:49 (UTC)

修改搜尋系統是否足夠？畢竟在港澳臺星馬人名中，全形的「．」或無間隔號遠比半形或不足半形的「·」常見，後者在站外幾近捏造。使用外掛工具從站外的「阿當．戴華」／「阿當戴華」跳轉至阿當·戴華的需求，大概遠遠多於從站外的阿當·戴華直達的需求。若在社會中不常見的阿當·戴華能夠直達，而更常見的「阿當．戴華」／「阿當戴華」不能跳轉，或許輕重倒置、並不公平？--— Gohan 2024年3月18日 (一) 01:53 (UTC)

您是期望內鏈、正文也獲某種轉換嗎。不了解「．」的常用性。--YFdyh000（留言） 2024年3月18日 (一) 02:03 (UTC)

我期待使用Wikipedia search之類的工具從站外的「阿當．戴華」能夠跳轉直達阿當·戴華。--— Gohan 2024年3月18日 (一) 02:08 (UTC)

Wikipedia Search擴展？如果目前僅有此需求，您可以寫一個用戶腳本作為臨時解決方案。例如將下列代碼插入您的common.js文件。if (mw.config.get('searchTerm')) {window.location.href = decodeURIComponent(window.location.href).replace(/．/g, '·');}--YFdyh000（留言） 2024年3月18日 (一) 02:26 (UTC)

最理想還是人人可用。--— Gohan 2024年3月18日 (一) 09:54 (UTC)

@YFdyh000：，看了SuggesterAnalysisConfigBuilder.php的char_filter配置，似乎這是改搜索索引配置的正確思路，或者可以考慮將「U+FF0E=>U+00B7」（如果能針對部署的語區（只針對zh區）的話更好）的映射配置進去？——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月25日 (一) 02:36 (UTC)

所以我認為還是允許將「．」作為間隔號的錯誤代替來建立重定向（基於「標點符號上的區別」或者「常見的錯別字和錯誤拼寫」），這樣應該能夠幫助搜索系統歸集數據來使其也能被正常搜索出來。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月18日 (一) 05:59 (UTC)

我覺得若可以應該內部處理，這樣一開放預估又會多出幾萬個重定向，有點雞肋--SunAfterRain 2024年3月19日 (二) 01:43 (UTC)

重定向操作相對簡單一些，加全局轉換可能影響更大（因為不只是標題，內容也會有影響）。或者調整搜索系統的來源詞過濾也可以考慮，但需要檢查CirrusSearch的技術信息，上面提及的似乎可行。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月19日 (二) 01:52 (UTC)

至少在大陸「阿當．戴華」不會用這種不規範的標點或者很少這種不帶標點的外文譯名，這樣的重定向絕大多數沒用。普通情況下，不論是否使用間隔號或者不規範間隔號，Google搜索或者維基內部的提示詞皆會排在首位，而且不想輸入間隔號的話，還可以複製。港台或新馬地區也許有些用。對於外部資料中有使用的或許可以考慮建立重定向，但是在所有的條目上建立未從使用、不規範的重定向感覺沒必要。

另外，對於比較長的名稱「維亞切斯拉夫沃洛金」，special:search中排在首位。「阿當戴華」的話，special:search的推薦詞中會在首位推薦「阿當·戴華」，但是搜索結果中並未將其放在首位，要加前綴intitle:。--Kethyga（留言） 2024年3月19日 (二) 02:29 (UTC)

不宜以中國大陸的「規範」凌駕其他國家／地區。如果走到只能大量建立重新導向的地步，而且機械人無法辨別中國大陸標題與否，那麽只能一概建立。況且，大陸「不會用這種不規範的標點」？中國出版集團所用的「本•阿什克羅夫特」算不算規範呢？很少「不帶標點」？在中國大陸新聞網站搜尋名人姓名，輕易可見；更不用説在微博、小紅書等選詞跳轉的需要。手寫且手快的人士未必會看選單，自加intitle:更是有違絕大多數人的習慣。--— Gohan 2024年3月25日 (一) 00:36 (UTC)

這不是中國大陸的規範問題，而是W3C《中文排版需求》是建議「間隔號」是用「·（U+00B7）」作為字符編碼，中國大陸規範等同這個標準，但字型（字符通過字體庫渲染）上，港澳台的（字體庫）是全角字型、中國大陸的是半角字型；台灣的標準是「．（U+FF0E）」，港澳台的（字體庫）為居中字型，而中國大陸的（字體庫）是左下角字型。（關於字型渲染效果的話，可以找一個叫BabelPad的類筆記本軟件，支持Unicode全部字符編碼和選擇字體庫渲染字型，然後下載微軟雅黑（簡體字型）、微軟正黑體（繁體字型）、思源宋體的不同地區字型變體的字體庫，用BabelPad加載看看兩個字符渲染形式）如果從Unicode給的字意的話，應該U+00B7才是對應間隔號的正式字符，U+FF0E是將錯就錯的結果（字符編碼用錯+字體庫「修正」）。所以最快的方法是按照Wikipedia:重定向來建立重定向代替，或者修改搜索索引的配置，再次就是修改全局轉換表。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月25日 (一) 02:08 (UTC)

所以不就是中國大陸的規範嗎？--— Gohan 2024年3月27日 (三) 05:03 (UTC)

是W3C的標準也這樣規範。（指正）——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月27日 (三) 11:46 (UTC)

有個目前難以實現、或許異想天開的思路：既然個別本地轉換表能只針對指定命名空間，能否讓重新導向頁被本地轉換表視爲一種命名空間（無論是真是假），或者乾脆讓標題起到本地轉換表眼界中的命名空間作用？--— Gohan 2024年3月25日 (一) 00:37 (UTC)

我覺得這是不了解技術細節胡思亂想的方案吧？好像沒有所謂指定命名空間生效的轉換表機制，而且重定向（mw:Manual:page table，重定向頁本身也是一種頁面，只是檢測到源代碼有重定向標記後，將頁面表的對應字段flag起來，方便後續代碼按照重定向的方式做跳轉行為處理）也不是一種命名空間。四級字符轉換配置表中，第一級是放在源代碼的超大轉換數組（方便程序讀取），第二級也只是放在Mediawiki命名空間（作為系統消息等可以方便前台人員維護）而已。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月25日 (一) 02:16 (UTC)

的確存在只針對ns8的本地轉換表。正因爲重新導向頁不是命名空間，才説「讓重新導向頁被本地轉換表視爲一種命名空間（無論是真是假）」。--— Gohan 2024年3月27日 (三) 05:03 (UTC)

@神秘悟饭：模塊:CGroup/MediaWiki special？那只是針對Mediawiki語境下，方便轉換Mediawiki這個應用下的用詞的公共轉換組（也就是字詞轉換機制下的第三級）而已。我至少沒找到針對特定命名空間的字詞轉換機制。我認為你提的這些東西沒有技術依據做支撐。至少在有限時間內不具可行性的討論。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月27日 (三) 11:44 (UTC)

不是，是MediaWiki:Conversiontable/zh-hans/ns8、MediaWiki:Conversiontable/zh-hant/ns8等。--— Gohan 2024年3月28日 (四) 10:23 (UTC)

沒找到mw相關文檔的說明。（這真的有用？）就算這樣，重定向頁並不是命名空間。如果為此做實現，可能技術上有限時間內不具可行性。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月1日 (一) 08:29 (UTC)

找了一些討論，似乎MediaWiki:Conversiontable/zh-hant/ns8等不是mw內的運行機制，而是給本地機器人整理字詞轉換的輔助內容。（Wikipedia:機器人/申請/Cewbot/24、User_talk:Jimmy_Xu/存檔/2015年/7-9月）——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月1日 (一) 08:33 (UTC)

現時可行的技術方案不外乎三種：（1）建立重定向頁、（2）調整搜索索引的分詞配置、（3）增加全局轉換（影響廣泛，不只是頁面命名，還包括正文，但也不是不可行的辦法）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月25日 (一) 02:25 (UTC)

應該集中在如何控制搜索適配的問題，也就是集中「在如何控制頁面標題使用『U+FF0E』作為間隔號時或者輸入關鍵詞使用『U+FF0E』作為間隔號時能正確匹配到對應的頁面」的問題上。至少（1）、（2）的技術可行性更好，對其他方面（如正文源代碼的錄入）的影響程度更少。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月25日 (一) 02:30 (UTC)

2024年第14期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更；不是所有的變更都會對您造成影響。技術新聞提供其它語言的譯文版本。

近期變更

• 無障礙閱讀測試功能的使用者將注意到「標準」和「大」文字大小選項的預設行高已更改。 [4]

本週變更

• MediaWiki的新版本將於4月2日部署至測試維基及MediaWiki.org，於4月3日部署至非維基百科wiki及部分維基百科，並於4月4日部署至所有站點（參見日曆）。 [5][6]

未來變更

• 維基媒體基金會每年都會制定年度計畫，以決定基金會將致力進行的事項。您現在可以閱讀產品與技術部門的關鍵成果草案。該草案建議基金會於2024年7月至2025年6月間，在重大技術變革中希望獲得的成果。您可以在討論頁發表評論。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 取得協助 • 提供回饋 • 訂閱或退訂。

MediaWiki message delivery 2024年4月2日 (二) 03:34 (UTC)

建議對{{link-xx}}系列模板進行編輯

具體建議：在「可參考外文維基百科條目」的提示信息末尾加入「創建條目前請先查詢相關的本地關注度指引。」，以免用戶不小心創立不符合本地關注度要求的條目。--📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年4月3日 (三) 18:29 (UTC)

我覺得不太必要。除了關注度，可供查證等方面也需要注意，但不能將所有提示都塞進去，會類似冗長的歡迎模板、警告模板，用戶自知創建的各項要求會更好。可以加指引來建議不要鏈接低品質的條目，不過執行力度和方式需要商榷。(＆)建議 比如甚至能用機器人自動解鏈不存在或低品質的目標條目，或者標記和允許用戶看不到/特殊標出這種鏈接（甚至普通內鏈），標記用模板參數、自動評級。--YFdyh000（留言） 2024年4月3日 (三) 20:45 (UTC)

閣下認為機器人應該根據什麼標準判定目標條目為「低品質」？是目標條目在目標維基的評級，是目標條目屬於任何一個小作品分類，是目標條目字數小於多少字節，還是其他什麼標準？不好意思，在下對維基機器人的編程和運作一無所知。

另外，如果閣下不想「將所有提示都塞進去」的話，就把上面的提示改成「創建條目前請先了解相關的本地規則。」行不行？因為「規則」包含了關注度、可供查證度、以及其他所有條條框框。📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年4月3日 (三) 21:55 (UTC)

至少那些無任何來源（日文維基就有不少）或掛有{{無來源}}等重要維護模板的。掛有{{廣告}}的也值得慎重。其他複雜的評級計算和目標維基上的評級，能考慮但後話。原則上不反對，但我期待更好方案。--YFdyh000（留言） 2024年4月4日 (四) 00:43 (UTC)

巡查員能按規則巡查新入條目，作出處理，並且要適當提醒這樣創建條目的問題，無論來自於哪裡。而老用戶也應該根據外文條目的質量來判斷是否將其翻譯引入或者改進。看上去提案者認為其他用戶（或者他自己）更像不思考條目質量而盲目引入，而之只能要靠那些可憐的提示來提醒。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月4日 (四) 01:58 (UTC)

「不思考條目質量而盲目引入」的不是我，而是另有其人。📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年4月4日 (四) 03:42 (UTC)

@Cwek能詳細說明一下「引入」意思? 我真的認為@PÑēüḾôňïę1357誤解了.--Winston（留言） 2024年4月4日 (四) 03:59 (UTC)

如果認為不需要根據外語條目創建該本地條目的話，直接除鏈則可，如有問題，自行討論。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月4日 (四) 01:35 (UTC)

@Cwek 我認為最好舉個例子講述. 是這樣的, @PÑēüḾôňïę1357沒有滿足關注度認為使用跨語言連結是不合理的 (例子). 但我個人關心的是如果連結被除其他讀者將無法參考相應的英文/其他語言頁面.

我認為這次討論是Wikipedia:互助客棧/求助#跨語言連結問題延伸.--Winston（留言） 2024年4月4日 (四) 04:08 (UTC)

還是沒理解我想說什麼？我們這裡建條目是依照相關規則（包括關注度等）來建立的，不考慮從哪裡來（包括原創或者翻譯）。至於加了link-xx是否就要翻譯，那是另一回事，或者如果你認為不值得建立（無論是是否滿足本地關注度還是當地語言的條目質量不符合在本地規則建立），可以直接消除link-xx（最好說明清楚在編輯摘要，作為備忘），根本不需要如此畫蛇添足。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月4日 (四) 04:55 (UTC)

@Cwek 如果消除跨語言連結其他讀者將無法參考相應的英文/其他語言頁面. 這有沒有可能缺乏參考嗎? 如果翻譯可能無法被讀者理解/可能會令讀者困惑, 沒有英文/其他語言頁面的參考我認為這將是一個潛在問題--Winston（留言） 2024年4月4日 (四) 06:03 (UTC)

@Cwek 如果每個人消除跨語言連結(原因是個人認為不值得建立), 那麼跨語言參考就會被斷掉. 我不確定這是不是一個問題. 謝謝--Winston（留言） 2024年4月4日 (四) 06:06 (UTC)

如果來源條目不符合本地規則用於創建，那就添加link-xx我認為沒意義。創建條目質量和是否來自link-xx不是直接相關，與巡查員的職責履行有關。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月4日 (四) 11:32 (UTC)

@Cwek 我想闡明, 維基沒有規定使用內部連結助手需要滿足關注度, 對嗎？謝謝. 內部連結助手文檔指出對於中文維基百科未建立條目的詞彙，該模板可在生成內部連接的基礎上，展示外語版條目連結以供參考。 --Winston（留言） 2024年4月4日 (四) 13:13 (UTC)

不太會建立條目的文字不應加入紅字鏈接，link-xx相當於紅字鏈接後面括號附註原文，所以不滿足關注度的主題不應該加入link-xx。

最初設立link-xx時，模板的效果是直接在正文裡寫紅字連接+外部連接（紅字鏈接（英語：Redlink）），彈窗效果要註冊後自行設定才出現。後來模板（沒有討論地）就改成了現在的預設彈窗設置，但是對這個模板的定位沒有再議（現在有人認為模板主要是方便讀者看外維；也有人認為主要是方便編者翻譯條目；還有人認為模板就是單純標記外語原文，只不過順便加個鏈接）。所以現在link-xx的定位很迷，開頭說的推論不是所有人都同意。

另外MOS:IWL第二段也是說「在不過度使用內鏈的前提下……」。目前看來如果條目沒有關注度，就只能在後面用括號單純附註外文，不加跨語言鏈接了。--For Each element In group Next（留言） 2024年4月4日 (四) 13:28 (UTC)

@For Each element In group Next 感謝您提供參考, MOS:IWL第二段是說「在不過度使用內部連結的前提下，對於不為中文用戶熟知的外來詞彙，編輯可以使用跨語言連結模板」. 我個人認為和關注度低是有點矛盾的, 因為不為中文用戶熟知的外來詞彙很有可能關注度低. 不為中文用戶熟知的外來詞彙可以使用跨語言連結模板但關注度低不推薦使用跨語言連結模板. 因此對我來說會很混亂, 我不確定是否要添加跨語言連結模板. 另外我覺得整個MOS:IWL從未提及跨語言連結模板和關注度之間的關係.

我傾向同意link-xx的定位不是和紅字連接相等(跨語言連結模板有額外的功能, 提供外語版條目連結以供參考). 也許這就是定位很迷原因.--Winston（留言） 2024年4月4日 (四) 14:59 (UTC)

「不為中文用戶熟知的外來詞彙很有可能關注度低」是不對的，僅存在外文有效資料、中文圈完全不關心的內容，也是有關注度的。不能創建條目的直接除鏈我是贊成的，但link-xx模板的作用已較為多元，可能有些人當作參見外文維基的外部連結或者原文標註等。--YFdyh000（留言） 2024年4月4日 (四) 15:43 (UTC)

但維基有自己的條目開啟關注度政策要求, 也許我們可以用這次當例子. 卡爾加里山麓不滿足關注度政策要求. 當你在搜尋引擎上搜尋時, 讀者可能不知道我在說什麼. 我覺得它應該滿足不為中文用戶熟知的外來詞彙和關注度低(也不滿足條目開啟關注度政策要求). 在這種情況下，link-xx模板將提供讀者參考. --Winston（留言） 2024年4月4日 (四) 23:38 (UTC)

這筆是吧。該英文條目的30個來源中，有無符合中文維基百科關注度的來源。暫時未看到特別明顯的介紹，但媒體持續對球隊表現有關注和報道，以及像[7]和其他文獻可能存在對球隊歷史的介紹，是否滿足關注度。--YFdyh000（留言） 2024年4月5日 (五) 00:54 (UTC)

WP:FOOTBALLER提供足球運動員關注度指引指導, 根據足球地區分類加拿大屬於第三類國家/地區, 然後根據足球俱樂部第三類國家/地區累計最少在第一/第二級聯賽存在兩個賽季滿足關注度. 然後根據加拿大足球聯賽系統加拿大暫無第二級聯賽. 第三級聯賽也沒有晉升系統. 現在卡爾加里山麓屬於第三級聯賽, 所以我沒看到卡爾加里山麓如何滿足關注度. 所以我相信當有人根據WP:FOOTBALLER要求移除時，卡爾加里山麓很可能被移除.--Winston（留言） 2024年4月5日 (五) 02:17 (UTC)

關注度細則只是方式之一。我覺得有可能存在符合WP:GNG的來源，未必是線上來源。--YFdyh000（留言） 2024年4月5日 (五) 04:35 (UTC)

理解--Winston（留言） 2024年4月6日 (六) 07:10 (UTC)

同時在沒有找到太多搜尋結果時, 是否link-xx可以提供一些參考? 但是有一個「創建條目前請先查詢相關的本地關注度指引。」這個話題出現.--Winston（留言） 2024年4月5日 (五) 02:22 (UTC)

也有可能如果編輯自己沒有翻譯正確的話，那麼搜尋結果就會缺失. 沒有搜尋結果且沒有link-xx(參考鏈被除). 那麼讀者如何信任WIKI內容?--Winston（留言） 2024年4月5日 (五) 02:30 (UTC)

所以你的理解還是搞錯了。加link-xx對應到外語條目，並沒有規定添加的方式或者限制。但如果link-xx預期不可能創建本地條目的話，是可以不添加。至於如何創建本地條目，是通過link-xx引導翻譯、還是單純直接地翻譯，如何確認本地條目是否滿足本地規則的話，那是編輯者和新頁面巡查應該去判斷地，但與link-xx無關，link-xx不應該承擔這種提醒需要。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月5日 (五) 05:54 (UTC)

感謝您的解釋. 但我還是不明白. 我知道這有點好笑, 但我添加link-xx但被撤銷. 他的理由是根據WP:FOOTBALLER，卡爾加里山麓必須贏得加錦標才能符合準入條件, 因此我加link-xx是不正確的. 他也認為添加link-xx是「不思考條目質量而盲目引入」. 我不知道如何應用維基政策應用此編輯.--Winston（留言） 2024年4月5日 (五) 06:36 (UTC)

2024年第15期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更；不是所有的變更都會對您造成影響。技術新聞提供其它語言的譯文版本。

近期變更

• 網路瀏覽器中可以使用擴充功能工具。現在有一個名為Citation Needed的Chrome擴充功能，您可以使用它來查看網路上的內容是否受維基百科條目支持。這是個測試維基百科運用方式的小實驗。不過因為是小實驗，所以僅限於Chrome瀏覽器使用，且僅能用於英文內容。
• 所有wiki均加入了新功能「編輯恢復」，可在偏好設定中啟用。啟用後，正在進行的編輯將儲存在網路瀏覽器中，如果您意外關閉編輯視窗，或是瀏覽器或電腦崩潰，再次開啟時，網頁將提示您恢復未發布的文字。請在專案討論頁留言回饋。這是2023年社群願望清單調查中的第八位。
• 「編輯檢查」實驗的初步結果已發布。編輯檢查現已作為預設功能部署至先前測試它的wiki。如果您希望您所在的wiki成為下一批編輯檢查的部署對象，聯繫我們。 [8][9]
• 在行動裝置上使用Minerva外觀的讀者將注意到所有排版設定的行高皆有改進。 [10]

本週變更

• MediaWiki的新版本將於4月9日部署至測試維基及MediaWiki.org，於4月10日部署至非維基百科wiki及部分維基百科，並於4月11日部署至所有站點（參見日曆）。 [11][12]
• 新帳號和登出的使用者將以視覺化編輯器作為行動版的預設編輯器。除英語維基百科外，所有維基百科均進行此部署。 [13]

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 取得協助 • 提供回饋 • 訂閱或退訂。

MediaWiki message delivery 2024年4月8日 (一) 23:36 (UTC)

編輯恢復有時候操作不小心會恢復到錯誤的版本--百無一用是書生 (☎) 2024年4月9日 (二) 02:51 (UTC)

可視化編輯器問題

合併至上方討論。--碟之舞📀💿 2024年4月15日 (一) 08:52 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

---

感覺最近較常出現Unable to stash Parsoid HTML這個問題--Yutommy 崖上的孤兒 消暑樂祭的狗 2024年4月14日 (日) 15:59 (UTC)

---

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

可視化編輯器是壞了嗎

於Phabricator查看
編號T356157的工單

如題，切換過去就顯示Unable to stash Parsoid HTML。--mije meli carrot_233 -- 討論 2024年4月10日 (三) 05:40 (UTC)

有時候會喪失功能，原因不明。-- 肥羊翻譯機 ⁄_留言 2024年4月12日 (五) 12:53 (UTC)

phab:T356157。類似問題先前發生過，由於沒有日誌無法分析，後來啟用了日誌，這次復現了等調查結果吧。--碟之舞📀💿 2024年4月15日 (一) 08:53 (UTC)

2024年第16期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更；不是所有的變更都會對您造成影響。技術新聞提供其它語言的譯文版本。

問題

• 4月2日至8日間，在使用標記修訂的wiki上，被還原的編輯未被加上「已被回退」標籤。此外，頁面移動、保護和匯入操作未自動標記為已巡查。此問題已解決。 [14][15]

本週變更

• MediaWiki的新版本將於4月16日部署至測試維基及MediaWiki.org，於4月17日部署至非維基百科wiki及部分維基百科，並於4月18日部署至所有站點（參見日程表）。 [16][17]
• 預設分類排序方式現在會影響腳註中放置的模板所新增的分類。先前，腳註中的分類使用頁面標題作為預設排序方式，即使已經指定了不同的預設排序方式（分類專用的排序方式已經生效）。 [18]
• 防濫用過濾器將新增新變數page_last_edit_age。該變數表示頁面的最後一次編輯是在多少秒前。 [19]

未來變更

• 懇請志願開發者們更新您維護的工具和功能的程式碼以應對臨時帳號。了解更多。
• 資料庫副本（包括Quarry）中將移除四個資料庫欄位。這僅影響abuse_filter和abuse_filter_history表格。某些查詢可能需要更新。 [20]

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 取得協助 • 提供回饋 • 訂閱或退訂。

MediaWiki message delivery 2024年4月15日 (一) 23:27 (UTC)

看來又要壞掉一批站內站外的工具了....--百無一用是書生 (☎) 2024年4月16日 (二) 02:29 (UTC)

可否篩選一下本站可能受到臨時賬號影響的腳本？--碟之舞📀💿 2024年4月16日 (二) 15:36 (UTC)

可能影響不明顯？因為臨時賬號的用戶名表現方式和普通用戶相近，可能底層屬性會多了「臨時」的標籤，需要相應腳本增加相應的檢測。IP地址形式用戶名可能以後會消失，相關的腳本也就沒有用了。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年4月17日 (三) 02:04 (UTC)

用戶討論頁內部錯誤

於Phabricator查看
編號T362530的工單
狀態：已解決

請問各位閣下，關於用戶討論頁發生內部錯誤，顯示以下錯誤說明，該如何恢復討論頁？麻煩請各位閣下協助，謝謝。

結構式討論工作流程並未與該頁面關聯。
[e7ab9c04-d03f-457a-85f2-7abd118bfd25] 2024-04-12 12:32:56: 嚴重異常類型
「Flow\Exception\InvalidDataException」

-- 肥羊翻譯機 ⁄_留言 2024年4月12日 (五) 12:50 (UTC)

@OnionBulb：能否在測試功能中關閉結構式討論頁？--碟之舞📀💿 2024年4月15日 (一) 08:47 (UTC)

偏好設定的測試功能沒有「結構式討論頁」的設定，我記得以前有這個設定，不知為何現在沒有也沒顯示。-- 肥羊翻譯機 ⁄_留言 2024年4月15日 (一) 11:59 (UTC)

報phab ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年4月15日 (一) 12:02 (UTC)

了解，感謝。-- 肥羊翻譯機 ⁄_留言 2024年4月18日 (四) 02:49 (UTC)

已交工單。@OnionBulb您好，想問一下這個問題是怎麼出現的，之前是否進行過關閉結構式討論的操作？

另外，結構式討論已經廢棄，將來將會從本站移除，就算恢復過來大概率會是傳統Wikitext頁面。--碟之舞📀💿 2024年4月15日 (一) 13:07 (UTC)

因為用戶討論頁有收到結構式討論的棄用通告，大概前兩個月我從偏好設定關閉結構式討論，結果用戶討論頁變成上述的發生內部錯誤。-- 肥羊翻譯機 ⁄_留言 2024年4月18日 (四) 02:55 (UTC)

@OnionBulb：Phab的人修好了，請複查。--碟之舞📀💿 2024年4月15日 (一) 14:10 (UTC)

感謝閣下大大的協助。-- 肥羊翻譯機 ⁄_留言 2024年4月18日 (四) 02:56 (UTC)

請問閣下，要如何改為傳統wikitext頁面？雖然他們有修好，可是偏好設定似乎找不到相關的關閉選項，是不是只能等待站方正式移除改回傳統頁面？-- 肥羊翻譯機 ⁄_留言 2024年4月18日 (四) 05:05 (UTC)

頁面信息/基本信息/過去30天的頁面訪問量 藍鏈問題

請問各位，【頁面信息/基本信息/過去30天的頁面訪問量】中的數據超鏈接藍鏈可否恢復？或者類似英維那樣直接鏈出？——Zzhtju（留言） 2024年4月20日 (六) 12:54 (UTC)

2024年第17期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他使用者這些變更；不是所有的變更都會對您造成影響。技術新聞提供其它語言的譯文版本。

近期變更

• 從本週開始，維基百科的新手編輯者會被鼓勵嘗試結構化任務。結構化任務已被證明能提升新手的活躍度和留存率。 [21]
• 即日起可以提名您最喜歡的工具參加第五屆最酷工具獎。提名將持續開放至5月10日。

本週變更

• MediaWiki的新版本將於4月23日部署至測試維基及MediaWiki.org，於4月24日部署至非維基百科wiki及部分維基百科，並於4月25日部署至所有站點（參見日程表）。 [22][23]

未來變更

• 這是最後一次提醒，從2024年5月底開始，Vector 2022外觀將不再與舊版Vector共用網站和使用者的腳本及樣式。對於要在Vector 2022上繼續使用的使用者腳本，請將Special:我的用戶頁/vector.js的內容複製到Special:我的用戶頁/vector-2022.js。參閱更多技術細節。介面管理員若預期這將導致大量技術支援問題，可以效仿法語維基百科，向您所在的社群傳送大量訊息。 [24]

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 取得協助 • 提供回饋 • 訂閱或退訂。

MediaWiki message delivery 2024年4月22日 (一) 20:26 (UTC)

關於褒揚令、碑文的藍色方框的 CSS 樣式建議

目前在維基百科上，獲中華民國褒揚令的人物往往會在其頁面上刊出褒揚令全文，並以藍色方框（實現方法為一個加了藍色實線 border 的 <blockquote>）框之。其他的一些人物的碑文可能也採取這樣的做法。

但很經常地，這樣的方框的右側部分會和頁面右側邊的其他資訊方塊相重疊，導致方框不能顯示完全，有時還會使內容發生詭異的換行效果。

現狀參考：許虞哲、吳新榮。

要解決這一問題其實很簡單，只消為 <blockquote> 添加一個 display: flex; 的 CSS 樣式，並將其內的所有內容包在一個 <div></div> 裡即可。這樣方框就不會與頁面上的其他元素重疊了（同時內嵌的 <div> 確保了 <blockquote> 內的內容不會出現排印錯誤）。

不知道大家是否認可這樣的修正，以及是否有技術能人願意寫一段指令碼來批次化執行這一修改。

再者，在含有褒揚令的篇目中，落款的總統、行政院院長部分其實也最好採用表格的方式去實現，以獲得更好（保證對齊）的排印效果。如下方這般：

<blockquote style="border: 1px solid blue; padding: 0.5em 0.8em; display: flex;">
<div>
財政部前部長、臺灣期貨交易所股份有限公司董事長許虞哲，洽聞沖簡，素德清材。少歲卒業國立政治大學財稅學系暨財政研究所，旋負笈遊美，獲哈佛大學法學碩士學位，抱志懷才，濬瀹專攻。歷任臺北市稅捐稽徵處處長、五區國稅局局長暨賦稅署署長等職，張拓各項稽徵事宜，調降最高邊際稅率；實施證券交易所得課稅，營造優質租稅環境，折衝圖議，幹濟有聲。尤以出任財政部次長、部長期間，整合通關航港系統，研提電子發票載具；踐履開源節流要旨，置辦跨境電商稅制；釐訂國有財產法規，增益公共建設量能，極智窮思，振裘持領；迴籌轉策，通觀全局。嗣接掌臺灣期貨交易所，博求多元商品創新，簡化交易結算程序；加強風險控管措施，推升期貨市場榮景，謨慮運帷，蜚英騰茂。曾獲頒財政部一、二等財政獎章暨模範公務人員等殊榮。綜其生平，殫瘁臺灣稅務體系興革，丕奠國家財政發展利基，訏猷遠謀，令績遐舉；行誼世範，楷模垂芬。遽聞溘然殂殞，悼惜彌殷，應予明令褒揚，用示政府篤念邦賢之至意。
{| align="right"
| 總　　　統
| style="padding-left: 1em;" | [[蔡英文]]
|-
| 行政院院長
| style="padding-left: 1em;" | [[蘇貞昌]]
|}
</div>
</blockquote>

如果總統、行政院院長的區塊需要與右邊框留出一點距離，則可簡單地在表格部分首行 align 屬性右邊添加右 margin 樣式即可，這些都比如今使用的解決方案能夠更好地保證排印效果（當然「總統」字樣間的空格理論上亦可透過為「總」字添加 letter-spacing 來解決，也即寫成 <span style="letter-spacing: 3em;">總</span>統 的樣子，但就不如直接加入全形空格方便了）：

{| align="right" style="margin-right: 2em;"
| 總　　　統
| style="padding-left: 1em;" | [[蔡英文]]
|-
| 行政院院長
| style="padding-left: 1em;" | [[蘇貞昌]]
|}

--Boreas Sawada 2024年4月27日 (六) 03:49 (UTC)

建議不錯，可以考慮建模板以規範顯示效果。不過我有點懷疑刊出全文的正當性，原因有三：一，這難道不應該移至文庫？二，所舉條目吳新榮中這樣的碑文不侵權？三，條目中以大篇幅給出褒揚令、紀念碑文全文有廣告宣傳之嫌，這要是大陸人物恐怕早就被移除了^{[開玩笑的]}。--Kcx36（留言） 2024年4月28日 (日) 18:59 (UTC)

Well… 我是一個「慣例主義者」（如果真的有這種東西的話），因此推崇尊重慣例 (convention)，尤其是在一個社群／社會上自發演化形成的慣例。（同時我也瞭解到中文維基並不推崇此類思想。）因此在如諸如此類的討論上會天然地偏向於「維持現狀、保持不變」。所以我不適合參與「改制」的討論。對此就不發表意見了。
編輯：由於樓下誤會，我特此聲明：前段之回應與是否應當為褒揚令等藍色框文字建立模板無關。是回應有關這類文字是否應該保留的部分的。--Boreas Sawada 2024年4月28日 (日) 21:57 (UTC)

• @Chu_Tse-tien：(：)回應：建模板並非是因為「它是慣例」而建的。建模板是指如果有存在某種格式、文字、或可（依條目主題）被程式運算的東西_{（見{{數字性質}}，已被廣泛地用來產生數字條目中的部分條目內容）}、板型或模式等內容出現在了在多個條目，又或會在同一條目還會重複出現，則宜「模板化」方便管理（不然到時你改一個，要全部條目都改一遍；模板化了就只要改模板）。如果「褒揚令、碑文」出現在許多條目，且其樣式（如CSS等）類似，則宜模板化。因此，並非因為「它是慣例」才建模板，而是很多條目都有相同東西，才「統整」成模板方便管理。因此建模板也算是「維持現狀、保持不變」但加上「技術上」的東西來方便進行「管理與維護」，並不變更其內容。畢竟如果某件事「它是慣例」宜「整合管理」減少人力負擔，並不意味著「不維持現狀、沒有保持不變」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月28日 (日) 22:37 (UTC)

  這……我回應的顯然不是關於建立模板的部分……--Boreas Sawada 2024年4月29日 (一) 01:57 (UTC)