維基百科:互助客棧/技術

本頁用作討論在編輯時遇到的技術問題;發表問題或討論前,請先參閱常見問題解答說明資訊MediaWiki基本問題及搜尋舊討論記錄。另請注意:

請注重禮儀、遵守方針與指引,一般問題請至互助客棧其他區知識問答提出,留言後請務必簽名(點擊 )。


發表前請先搜尋存檔,參考舊討論中的內容可節省您的時間。
公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 Template:Weather box 15 6 Ericliu1912 2024-06-25 10:57
2 MobileFrontend側邊欄故障 7 3 Ericliu1912 2024-06-25 10:58
3 引文模板不應該報錯全部的零寬空格 6 4 Ericliu1912 2024-06-25 10:58
4 關於使用 ToolsRedirect 創建的繁簡重定向 13 7 Kanashimi 2024-06-25 21:47
5 未有登入的用戶將可以使用外觀選單和新的預設標準字體大小 14 5 Diskdance 2024-06-25 15:28
6 《通用規範漢字表》以外的簡體字是否應該類推簡化 34 10 What7what8 2024-06-14 11:12
7 Module:Mapframe、Module:Location map報錯 5 3 Shizhao 2024-06-09 20:36
8 Wikiplus導致Navbar被換行 22 8 自由雨日 2024-06-26 05:50
9 美國縣級行政區地圖顯示故障 6 5 LuciferianThomas 2024-06-26 16:20
10 跨項目通知的藍點 5 4 Ericliu1912 2024-06-26 21:21
11 深色模式界面格式問題:編輯模式對話框文本、SVG圖片、代碼塊背景色及字體 0 0
12 NoteTA 烏克蘭地名無法正確轉換「頓內次克」 5 3 Ericliu1912 2024-06-21 10:57
13 模板中禁止使用noteTA標題轉換? 7 5 Cwek 2024-06-21 11:25
14 「為翻譯頁面標記{{Translated page}}」小工具的bug 1 1 GnolizX 2024-06-21 20:23
15 以淺藍色背景突顯被點選到的數學式其對應的NumBlk模板 4 2 Justin545 2024-06-24 13:01
16 繁簡分類重新導向問題 1 1 Ericliu1912 2024-06-23 22:32
17 有沒有辦法限制重定向在條目正文中的使用? 4 4 Kanashimi 2024-06-26 06:58
18 2024年第26期技術新聞 1 1 MediaWiki message delivery 2024-06-25 06:31
19 請求修改Cite book對統一書號的支持 1 1 TimWu007 2024-06-28 14:05
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下討論需要社群廣泛關注:重新整理

維基百科技術議題與模板

Template talk:Bd § 編輯請求 2024-05-19

Wikipedia talk:互助客棧 § 互助客棧(或是任何討論)存檔到空的討論頁需改為加上Template:Talk header

Template:Weather box

編輯

天氣模板Template:Weather box,可以添加參數|width=auto以自動適應條目,但是在有信息框的條目中添加該參數並不總是會自適應,比如韋斯卡 (78803227)會在氣候模板上方出現大段空白(可能也是信息框/Infobox的原因)。--Kethyga留言2023年9月5日 (二) 10:03 (UTC)回覆

自帶{{clr}}效果?如果沒有,表格在小屏幕寬度下不會放不下嗎。--YFdyh000留言2023年9月9日 (六) 04:14 (UTC)回覆
手機網頁和App看了下,應該都要左右滑動。--Kethyga留言2023年9月9日 (六) 08:20 (UTC)回覆
應該又是V22皮膚的css更新所致,換成2010版皮膚看是正常的。--蕭漫留言2023年10月10日 (二) 02:44 (UTC)回覆
似乎現在顯示效果正常了?--Kcx36留言2023年11月15日 (三) 10:39 (UTC)回覆
目前已  無法重現 Willy1018留言) 2023年11月19日 (日) 02:50 (UTC)-- Willy1018留言2023年11月30日 (四) 03:21 (UTC)回覆
在條目韋斯卡中,未登錄和Timeless Skin下目前均無法自適應頁面寬度。--Kethyga留言2023年11月27日 (一) 04:11 (UTC)回覆
我的顯示效果。--Kcx36留言2023年11月27日 (一) 04:50 (UTC)回覆
發現新版皮膚/外觀在未登錄狀態下的右下角有一個切換「全屏寬度」和「有限寬度」的按鈕,如果選擇「全屏寬度」的話就不會被信息框/Infobox遮擋,但是Weatherbox/天氣框仍未填滿空間。另外在條目洛帕中,Timeless Skin下可以正常自適應頁寬。--Kethyga留言2023年11月28日 (二) 01:55 (UTC)回覆
@Kethyga英文維基百科也有這種情形嗎?—— Eric Liu 創造は生命(留言留名學生會 2024年1月29日 (一) 17:28 (UTC)回覆
@Ericliu1912 en:Wikipedia:Sandbox (1220692034) 在英維的效果,個人認為無問題,右側的信息框一般不會遮擋天氣框。--Kethyga留言2024年4月25日 (四) 09:52 (UTC)回覆
@Kethyga若直接複製來本地,是否可行?—— Eric Liu 創造は生命(留言留名學生會 2024年4月25日 (四) 15:28 (UTC)回覆
得先測試看看了,不知道差異大不大,另外也不知道是否只是 Weather box 的問題。--Kethyga留言2024年4月26日 (五) 01:30 (UTC)回覆
因此話題遲無進展,故暫時作結,來日再議。—— Eric Liu 創造は生命(留言留名學生會 2024年6月25日 (二) 02:57 (UTC)回覆

MobileFrontend側邊欄故障

編輯

[1] Log in(登入)、Settings(設定)、Donate(贊助)、About Wikipedia(關於Wikipedia(隨維基媒體計劃名稱而變))、Disclaimers(免責聲明)均無法被點擊,也無法對其長按彈出瀏覽器菜單,全站(所有語言、所有維基媒體計劃)均發生該問題。--Txkk留言2023年11月29日 (三) 03:05 (UTC)回覆

在firefox下未能復現,可點擊,可彈出瀏覽器菜單。但是側邊欄各項一點擊或彈出瀏覽器菜單時(點擊鼠標左鍵或右鍵時),側邊欄就會迅速縮回,雖然點擊的連結打開沒問題(選擇使用彈出的瀏覽器菜單中的功能也沒問題),但是用戶體驗比較糟糕。從前端角度看,很可能算是個bug--百無一用是書生 () 2023年11月29日 (三) 03:20 (UTC)回覆
似乎現在mediawiki更新後,這個問題(或類似問題)已不存在了?--百無一用是書生 () 2023年12月15日 (五) 11:56 (UTC)回覆
還在。--Txkk留言2023年12月15日 (五) 21:21 (UTC)回覆

有沒有人去Phabricator報告問題?--Txkk留言2023年12月25日 (一) 06:46 (UTC)回覆

我現在是只有關於和免責聲明點擊後側邊欄縮回,頁面不跳轉--百無一用是書生 () 2023年12月25日 (一) 07:47 (UTC)回覆
@TxkkShizhao現在情況如何?—— Eric Liu 創造は生命(留言留名學生會 2024年6月25日 (二) 02:58 (UTC)回覆

引文模板不應該報錯全部的零寬空格

編輯

Cat:引文格式1錯誤:不可見字符現在只要有U+200B就會報錯,實際上有些零寬字符是合理且必要的,比如emoji和孟加拉文使用其連接字符。

建議將其改為維護而不是錯誤。--落花有意12138 2023年12月16日 (六) 12:44 (UTC)回覆

en:Module:Citation/CS1/Configuration有為特定文字或Emoji添加例外。--Cookai餅塊🍪💬留言 2023年12月24日 (日) 10:10 (UTC)回覆
等等,Module:Citation/CS1/Configuration也有indic_script,但Module:Citation/CS1沒有把它排除。--Cookai餅塊🍪💬留言 2023年12月24日 (日) 10:19 (UTC)回覆
請問此問題有辦法解決嗎?《亂世勇者》的97號來源出現此情況,但不知道該如何解決。--H2226留言2024年1月7日 (日) 10:11 (UTC)回覆
要改的是Module:Citation/CS1/Utilitieshas_invisible_chars,en的has_invisible_charsen:Module:Citation/CS1,看有沒有高人要來修。--Cookai餅塊🍪💬留言 2024年4月24日 (三) 04:58 (UTC)回覆
因此話題遲無進展,故暫時作結,來日再議。—— Eric Liu 創造は生命(留言留名學生會 2024年6月25日 (二) 02:58 (UTC)回覆

關於使用 ToolsRedirect 創建的繁簡重定向

編輯

使用ToolsRedirect自動創建的繁簡重定向,會被該工具錯誤地標記為別名重定向,參見:Special:Diff/82229793Special:Diff/82063339Special:Diff/82063322Special:Diff/82034218Special:Diff/82003931……煩請界管盡快修復此bug,防止掛有錯誤標記的繁簡重定向不斷增加。

由於大量編者均習慣以ToolsRedirect快速創建重定向,因此需要修正的繁簡重定向恐怕已不可勝數,能否讓機械人批量處理使用該工具創建的繁簡重定向,將頁面中的{{別名重定向}}替換為{{簡繁重定向}}?@Kanashimi--蕭漫留言2024年4月12日 (五) 08:22 (UTC)回覆

一個疑問,這些簡繁重定向是必要還是不太必要的。是解決可視化編輯器問題的嗎。--YFdyh000留言2024年4月12日 (五) 19:47 (UTC)回覆
個人感覺別名(包括地區用詞、外文名)有必要,繁簡必要性不大,條目和模板中可以正常跳轉,只是編輯摘要(或者還有什麼地方)會顯示紅鏈。--Kethyga留言2024年4月13日 (六) 00:22 (UTC)回覆
若不涉及一簡對多繁或異體字問題,繁簡重定向應該是不必要的。--蕭漫留言2024年4月13日 (六) 01:04 (UTC)回覆
User:YFdyh000User:KethygaUser:蕭漫:對我來說,簡繁重定向最重要的功能是克服伺服器緩存過多、直接逼User:Cewbot清掉被系統忽略、遺忘的偽藍連,例如我做完Special:PermaLink/82174815不久,機械人就幫我做了這筆清理,不這樣做的話,機械人不會清到這些條目機械人很難清到這些條目。英文維基百科那邊也是這樣,大家可以留意裏面有一條「{{ill|Hundred Flowers Award for Best Writing|zh|大众电影百花奖最佳编剧|lt=Best Writing}}」被標示為「The corresponding foreign language page does not exist.」,但中文百科其實有大眾電影百花獎最佳編劇條目,只是繁簡不同而已,如果有簡繁重定向頁就不會跳出這個錯誤。--迴廊彼端留言2024年4月14日 (日) 14:19 (UTC)回覆
偽藍鏈是什麼效果。Database reports可能該機械人不支持簡繁機制,不了解有無別的方案。是否要建簡繁重定向似乎多次討論過,有無結論忘記了。--YFdyh000留言2024年4月14日 (日) 14:54 (UTC)回覆
User:YFdyh000:偽藍連只有兩種可能,一個是應該功成身退的跨語言連結,另一個是編者寫的不正確或與未來建立條目名稱不同、導致機械人清不掉的連結,兩種最好都不要存在。--迴廊彼端留言2024年4月15日 (一) 14:16 (UTC)回覆
我還沒發現本地User:Cewbot/需要修正的跨語言連結中因為繁簡而受影響的情形。如果確實有的話,應該可以考慮重新設計機械人。倒是除此之外,繁簡重定向確實沒有什麼作用。--PexEric 💬|📝 2024年5月2日 (四) 09:35 (UTC)回覆
可能需要修改MediaWiki:Gadget-ToolsRedirect.js的識別方案吧,另外還有非繁簡識別成繁簡重定向的,比如82561648--Kethyga留言2024年5月10日 (五) 03:13 (UTC)回覆
不知@Kanashimi看法如何?—— Eric Liu 創造は生命(留言留名學生會 2024年6月25日 (二) 02:59 (UTC)回覆
@迴廊彼端 不知能否提供個需要創建繁簡重定向的例子讓我研究看看?--Kanashimi留言2024年6月25日 (二) 06:11 (UTC)回覆
User:Kanashimi:除了上面的例子外,Special:Diff/82267560中有個「{{link-en|湿实验室|Wet lab}}」,實際上已有濕實驗室條目,所以這模板應該被分入Category:有藍鏈卻未移除內部連結助手模板的頁面,但目前沒有;要是我沒剛好遇到,Cewbot不知道過多久才會來處理,。--迴廊彼端留言2024年6月25日 (二) 13:31 (UTC)回覆
我改一下程式,這兩天跑跑看有沒有效。--Kanashimi留言2024年6月25日 (二) 13:47 (UTC)回覆

未有登入的用戶將可以使用外觀選單和新的預設標準字體大小

編輯

摘要:基金會計劃將未登入用戶的字體大小改為標準選項(16px),登入用戶維持原狀及為小選項(15px),所有用戶將有選項列表改變字體大小和行高、及開關深色模式。此變更僅影響使用Vector 2022皮膚的用戶。如果沒有任何重大問題,將會兩星期後部署此改動。--SCP-0000留言2024年5月25日 (六) 03:17 (UTC)回覆

 

大家好! 我們是維基媒體基金會網絡團隊。作為本年度年度計劃「閱讀和媒體體驗目標的一部分,我們致力於讓維基媒體計劃的閱讀變得更容易。為了實現這一目標,我們推出了「無障礙閱讀」測試版功能。這添加了一個適用於 Vector 2022 皮膚的選單,並允許已登入的用戶根據個人需求選擇不同的字體大小和配色方案。

此選單引入了新的標準字體設定。這稍微增加了字體的大小和高度。它是根據多個來源選擇的。您可以在「關於新的標準字體設定」部分找到更多相關資訊。

我們將會發生什麼變化

  • 我們現在已準備好為未有登入的和已登入的用戶提供新的外觀選單
  • 同時,我們將標準選項設定為僅適用於未有登入的用戶之新預設選項
  • 如果沒有發現重大技術問題,我們計劃在接下來的兩週內進行此更改。
  • 稍後,該選單將包括選擇深色模式的選項(該功能暫時仍將是測試版功能)。如希望了解更多信息,請查看我們的專案頁面

關於選項列表

新選單將允許為未有登入的和已登入的用戶設定以下首選項:

  1. 文字大小和行高(現以測試版功能提供):使用者將能夠在「小」(目前預設值)、「標準」(建議更好的可訪問性)和「大」選項之間進行選擇。選擇一個選項將更改文字的字體大小和行高。
  2. 深色模式(現以測試版功能提供):使用者將能夠選擇永久以深色模式查看網站,或選擇「自動」設置,根據裝置或瀏覽器首選項設定淺色或深色模式。
  3.  
    內容寬度(先前作為切換按鈕提供):我們已將內容寬度切換從頁面底部的圖示移至新選單中標籤的單選按鈕。其工作原理與切換開關完全相同。之前的切換按鈕將不再可用。

此選單已作為測試版功能由不同的維基之專案上的已登入使用者進行了測試,同時我們邀請了一些讀者進行了使用者測試。根據這些測試的結果,我們更改了選單,以提高可發現性和易用性,並適應小工具的相容性。

此選單將顯示在頁面右側,如果已固定選單,則緊鄰「工具」選單的下方。與「工具」選單不同,「外觀」選單預設是固定的,但您可以取消固定預設。一旦取消固定預設,這就會折疊在頁面頂部的圖示下。

關於新的標準字體設置

小字體選項是目前的預設值。對於未有登入的用戶,我們將將此預設值更改為「標準」,同時保留小字體選項作為已登入用戶的預設值。「標準」和大字體選項是根據以下內容構建和測試的:

  • 針對大多數讀者的最佳平均字體大小的學術研究和建議。這些建議表明,我們目前的字體尺寸太小無法讓大多數人舒適地閱讀。這意味着,平均而言,人們閱讀速度較慢,閱讀時眼睛疲勞,或難以清楚地看清文字。預設增加字體大小可以改善所有使用者的這些問題,包括可能沒有足夠時間透過外觀選單或瀏覽器調整設定的使用者。資訊密度同時很重要,這就是為什麼我們希望在不犧牲資訊密度的情況下增加字體大小。我們不僅透過更改字體大小,同時透過更改行高和段落間距來實現這一目標。
  • 由來自 13 個不同語言、腳本和大小的維基專案中 630 多名維基媒體成員提交的設計。這些用戶中的大多數(約 450 名)選擇了比預設值更大的字體大小。「標準」代表最受歡迎的一組答案(15-20 像素)的平均值。大字體選項代表讀者需要更大的字體尺寸選項,例如 21-26 像素之間的一組尺寸。您可以在此閱讀更多關於我們如何讓志願者參與此過程並確定這些選項的資訊
  • 測試版功能使用情況表明,至少一次與該功能互動的大多數使用者選擇的字體大小大於當前預設值

我們目前為止的工作和下一步

已登入的用戶將暫時保留小字體選項設置作為預設設置,但可以隨時更改為任何其他設定。幾個月後,我們將研究有多少登入使用者切換到標準字體選項,並開始討論已登入的用戶進行的切換是否具有意義。根據測試版功能的早期數據,與該功能的互動中有 55% 選擇使用標準或更大的字體選項設定。

如果您想提供協助,我們有一些簡單的請求:

  1. 請開啟測試版功能 (「無障礙閱讀(Vector 2022皮膚)」)
  2. 請嘗試一下新選單。請問有什麼令人困惑的部分嗎?您了解所有標籤以及選單的工作原理嗎?
  3. 請嘗試不同的字體選項:小尺寸、標準尺寸和大尺寸、配色方案和寬度切換。如果您發現任何錯誤或有任何疑問,請與我們聯絡。

Last-minute FAQ (thanks to SCP-2000 for pointing out these issues:

Zhwiki community has already solved this issue by increasing the font size to 15px with a gadget.
We believe that it's great that you have decided to increase the font size. You are one of few communities which have done that, and we applaud you. But 15px turns out to be not enough.
Why 16px? Do this research and data usage apply to CJK characters?
Yes, they do. 16px is a minimum for any script, including non-diacriticized Latin scripts like English. Since Chinese characters are more complex than Latin characters, the minimum for zhwiki is at least equal to the minimum for the Latin script-wikis.

如果您想了解有關該專案的更多信息,請參閱我們的常見問題與答案。我們歡迎您提出意見和問題。謝謝你![Translated by Venuslui] OVasileva (WMF) & SGrabarczuk (WMF)留言2024年5月24日 (五) 12:26 (UTC)回覆

我記得@Shizhao曾經解釋過選擇15px的理由,想問一下同樣的理由也適合16px嗎?這個變化至少在我這裏是可感的,而社群當時同意保持15px的理由是儘量避免變化。--碟之舞📀💿 2024年5月24日 (五) 14:11 (UTC)回覆
@ShizhaoYFdyh000S8321414Ericliu1912 簡單而言,未登入用戶的字體大小改為標準選項(16px),登入用戶維持原狀及為小選項(15px),所有用戶將有選項列表改變字體大小和行高、及開關深色模式。如果沒有任何重大問題,將會兩星期後部署此改動。副知曾參與相關討論的編者。謝謝。--SCP-0000留言2024年5月24日 (五) 16:09 (UTC)回覆
如果真的要更改的話,有必要維持兩個選項嗎?我覺得這樣徒增維護成本。--碟之舞📀💿 2024年5月25日 (六) 03:02 (UTC)回覆
這功能本來設計就有「小」(目前預設值)、「中」(基金會建議值)及「大」選項,應該不會徒增基金會維護的成本,但始終可能對社群有些影響。--SCP-0000留言2024年5月25日 (六) 03:26 (UTC)回覆
也就是說中文的「小」還是會從14px改為15px,是嗎?--碟之舞📀💿 2024年5月25日 (六) 03:34 (UTC)回覆
理論上是的。--SCP-0000留言2024年5月25日 (六) 03:49 (UTC)回覆
所以現在未登入與已登入的使用者都是小(15px)、標準(16px)、大(20px),只是未登入使用者預設是標準(16px),已登入使用者預設是小(15px)這樣?我是覺得這樣沒什麼問題。--冥王歐西里斯留言2024年5月26日 (日) 02:16 (UTC)回覆
理論上是的。--SCP-0000留言2024年5月26日 (日) 02:34 (UTC)回覆
目前已經部署了,將來打算如何調整?--碟之舞📀💿 2024年6月16日 (日) 09:32 (UTC)回覆
感覺社群意見不多。建議往後分別提出。祇是個人納悶為何登入與否字體大小不同?—— Eric Liu 創造は生命(留言留名學生會 2024年6月23日 (日) 02:36 (UTC)回覆
應依據原定計劃將「大字體」工具在 Vector 2022 停用,然而現在「無障礙閱讀」功能並非所有用戶預設啟用,所以可以再等一下。謝謝。--SCP-0000留言2024年6月25日 (二) 06:30 (UTC)回覆
@SCP-2000:技術上可以做到只在「無障礙閱讀」功能啟用的情況下停用。原定計劃可以執行。--碟之舞📀💿 2024年6月25日 (二) 07:28 (UTC)回覆

通用規範漢字表》以外的簡體字是否應該類推簡化

編輯

這說來有點話長,但日前因為在修理相關條目時遇到了「𫛚」這種字(該字位於Unihan擴充C區),接着就發現小苇𫛚小葦鳽並不被系統視為是同個字,所以數天前至WP:TS報修。但稍早前微腫頭龍閣下提及這是因為該字在《通用規範漢字表》以外的緣故,所以需要一些意見討論是否應該將可能會使用到的表外字作類推簡化(並修改轉換表)重定向或移動到合適標題,又或是直接限制僅使用在表內的字或要求使用繁體標題以迴避問題。畢竟實質上不少表外字可能已經被經常使用,而導致部分條目標題實質上是繁簡混雜的,卻因非表內字而無法被正常轉換。

另外現在有個問題是如果硬套{{僻字}}轉換處理的話,有時候似乎會出現蠻可怕的懸浮文字框,但我一時不太知道怎麼處理及觸發的。舉例來說,在大陸簡體模式下大麻鷺屬的右側導航框中的「麻𫛚亚科」懸浮文字。--WiTo🐤💬 2024年5月6日 (一) 16:40 (UTC)回覆

有多少字?—— Eric Liu 創造は生命(留言留名學生會 2024年5月6日 (一) 17:39 (UTC)回覆
老實說我不知道,我目前也只是偶然發現有幾個字是這樣的狀況。但辶、門、金、食、馬、鳥、魚等字旁的字個人猜測可能會有不少這種情形,應該會需要電腦協助篩出有在Unihan擴充區內但不在表內的字。範圍上可能從擴充A區就要開始找了,A區的「鷿鷈」疑似就有類似情形(北美䴙䴘属北美鸊鷉屬北美鷿鷈屬,不過這組有牽涉到異體字的問題可能不一定真是如此)--WiTo🐤💬 2024年5月7日 (二) 00:33 (UTC)回覆
根據我近期看到的一些中文學術著作,似乎並沒有統一的做法,有人就用繁體字,有人則用簡體字(生物類)--百無一用是書生 () 2024年5月7日 (二) 09:36 (UTC)回覆
僅考慮學術用字的話幾百個應該還是有的,但如果範圍擴大至所有領域恐怕得去到一千個以上(尤其是古人名、古地名)。--微腫頭龍留言2024年5月7日 (二) 01:43 (UTC)回覆
忘了副知提醒我此事的@微腫頭龍閣下及當時先使用了𫛚一字的@Interaccoonale閣下。--WiTo🐤💬 2024年5月7日 (二) 00:40 (UTC)回覆
這個討論串是否應該移動到技術版?--——🦝Interaccoonale留言貢獻 2024年5月7日 (二) 01:18 (UTC)回覆
我大概說一下我的想法:
  • 從法律上講,之前《通用規範漢字表》的草案有規定過表外漢字不類推簡化,但是正式版把這一條刪掉了,所以含有類推簡化偏旁的表外漢字是應該簡化的。
  • 從實際應用上講,《中華人民共和國國家重點保護野生動物名錄》對於生物中文名的表外漢字作類推簡化處理,大部分正式學術著作也作類推簡化處理。
  • 從技術上講,如果相關的bug實在太多,我不反對改回原狀,對於表外漢字在簡體模式下顯示繁體字。
我之前有思考過比當前的{{僻字}}模板更優雅的渲染方式,我之前想的是根據當前頁面中包含的擴展區段字符,自動生成一個含有相關僻字的字體文件(字形檔),然後用CSS引入到當前頁面中,就可以避免這種恐怖的懸浮文字框(有時候這些文字會被顯示在Tools-redirect中以及底部的頁面分類裏面,會變得尤其可怕)。比如大麻鷺屬就會自動生成一個僅含有𫛚字的字體文件(字形檔)。
其實如果只考慮自動生成的部分,在技術上還不算太難,以遍黑體為基礎字體(字形)就可以,能在伺服器端編輯字體文件(字形檔)的庫也有很多。但是我不清楚要如何跟mediawiki整合起來。
另一種技術上更簡單(但是操作上更複雜)的方法就是手動將相關字符拆分出來,然後上傳到commons,然後在頁面中引用即可。--——🦝Interaccoonale留言貢獻 2024年5月7日 (二) 01:31 (UTC)回覆
若根據NC:COMMON的話,那就應該是要隨名錄名稱類推簡化沒錯了。但希望能以操作上簡易的方式處理,不然像我這種電腦技術笨蛋恐怕就不會操作了,不過命名標題會不會有需要額外調整?另若認為搬去技術版更合適,那還請協助移動。--WiTo🐤💬 2024年5月7日 (二) 03:27 (UTC)回覆
我早前用字形wiki的字體做過一個小工具來實現類似你說的這種方法,後來因為技術和安全原因失效了。其實現在仍然可以利用字形wiki的字體資源來實現,只是要把字體之類的資源搬到toolforge上去,然後本地用小工具調用。c區似乎不能上傳字體文件?「根據當前頁面中包含的擴展區段字符」其實並不是一個很好的做法,因為每個人電腦/終端上的字庫未必不一樣,在甲上不能正常顯示的字形,在乙那裏沒準就可以正常顯示。所以最好的辦法是自動檢測某人設備上哪些字形不能正常顯示,不能正常顯示的就即時下載相應的字形文件(可能會遇到一些優化工作要做)。目前來說,我知道的是這種自動檢測方法chrome和firefox下都有解決方案,其他瀏覽器內核的不確定--百無一用是書生 () 2024年5月7日 (二) 09:47 (UTC)回覆
  • chrome檢測法:將代表不能顯示的字符形狀映射到畫布,然後將文本中的每個字符一個一個映射到畫布並進行比較,如果比較結果一致,就表示該字符無法在這個設備上顯示
  • firefox檢測法:將文本中所有字符設為斜體,如果某個字符不是斜體,就表示該字符無法在這個設備上顯示(比如𱎼家人和𱎼家人
--百無一用是書生 () 2024年5月29日 (三) 04:05 (UTC)回覆
@T45614631InteraccoonaleEricliu1912我根據知乎上的一些文章整理出來了未被收錄進《通用規範漢字表》的科學技術用字,見我的子頁面User:微腫頭龍/E。這個表肯定是不完整的,歡迎補充。--微腫頭龍留言2024年5月7日 (二) 06:52 (UTC)回覆
這樣看起來的話,有些表外字還是有被正常轉換耶,像是魟、鰠、鎶等,那是被手動增加轉換的嗎?--WiTo🐤💬 2024年5月7日 (二) 07:49 (UTC)回覆
那幾個字確實已經加入全域轉換了。這裏有維基百科的完整繁簡轉換表--微腫頭龍留言2024年5月7日 (二) 09:01 (UTC)回覆
所以現在算是有共識要處理這個繁簡問題嗎?感覺上這些字遲早會變成正規簡化字...--WiTo🐤💬 2024年5月13日 (一) 03:47 (UTC)回覆
@ShizhaoInteraccoonaleT45614631Ericliu1912所以幾位覺得需要處理這些繁簡問題嗎?還是放着不用理?我個人是覺得需要簡化。--微腫頭龍留言2024年5月16日 (四) 07:48 (UTC)回覆
我是支持簡化的,但還是要考慮顯示的問題?——🦝Interaccoonale留言貢獻 2024年5月16日 (四) 08:16 (UTC)回覆
@Interaccoonale其實就我個人來說{{僻字}}就已經夠用了,但如果有更好的方式也可以。我的電腦技術很差,這方面就愛莫能助了。--微腫頭龍留言2024年5月16日 (四) 08:36 (UTC)回覆
目前維護內置轉換表的管理意見,應該是大部分都只轉換到中日韓統一表意文字擴展B區,後面擴展區域的因為大部分設備字體兼容性不足,一般不轉換(大部分類推簡化的繁體本字能正常顯示)。上面有表外漏轉漢字可能要從擴展A區開始找的觀點,我(+)支持這種找法,擴AB兩個區先查一遍看看有什麼沒轉換的。至於後面的擴展區我暫保持中立。--屠麟傲血留言2024年5月17日 (五) 14:53 (UTC)回覆
那我就轉到技術區看要有沒有人能處理這問題了。--WiTo🐤💬 2024年5月25日 (六) 03:50 (UTC)回覆
拿腳本找了一下Unihan數據庫(裏面可能有不適用的,例如「奨,奬」還有大部分一簡多繁轉換):
篩選出了簡繁皆為基礎及擴AB區的
--User:What7what8🏠 2024年5月25日 (六) 06:51 (UTC)回覆
如果通過的話,WP:R3可能也有需要更改。--User:What7what8🏠 2024年6月14日 (五) 03:12 (UTC)回覆
如果通過的話Template:繁簡混雜重定向也要改,不過只有幾個頁面應該不難改。--User:What7what8🏠 2024年5月25日 (六) 07:52 (UTC)回覆
粗略看來一下閣下列出的,當中有些是違反簡化規則的。比如「㳕,灡」,「蘭/兰」字位於《簡化字總表》的第一表,因此是不可類推簡化的。也就是說,如果有一天「灡」字被列為規範漢字,也僅會對「門」部件進行簡化變成「𬞕」,而不是將整個「蘭」進行簡化。再比如「䓕,薳」,由於「遠/远」也是不可類推簡化部件,所以「薳」也是不必簡化的,剛巧《通用規範漢字表》就有收錄「薳」字。所以閣下的這個恐怕要進行超大規模的整理才能提交啊。而且我覺得沒有具體使用例子的就沒必要簡化了。不過還是要感謝一下閣下把它們整理出來。@What7What8--微腫頭龍留言2024年5月25日 (六) 13:40 (UTC)回覆
另外想問一下哪一種字體支援最完整?—— Eric Liu 創造は生命(留言留名學生會 2024年5月26日 (日) 03:41 (UTC)回覆
應當是宋體吧,因為Unicode的文件也是宋體,Microsoft在顯示生僻字時好像也是默認宋體。--微腫頭龍留言2024年5月26日 (日) 03:46 (UTC)回覆
宋體是字體風格不是一種字體。--Miyakoo留言2024年5月26日 (日) 11:05 (UTC)回覆
好吧,是我搞錯了兩個概念。謝謝指出。@Miyakoo--微腫頭龍留言2024年5月26日 (日) 11:09 (UTC)回覆
Unifont吧,不過是點陣字形,可以參考Wikipedia:Unicode擴展漢字還有Template:Unihan
( π )題外話Special:鏈入頁面/Wikipedia:Unicode擴展漢字「𰻞𰻞面 ‎ (← 連結 | 編輯)」怎麽全變方框了,還有𱎼家人的標題「家人」也變成方框了,是有什麽bug嗎?--User:What7what8🏠 2024年5月26日 (日) 15:30 (UTC)回覆
Firefox正常顯示,Chrome顯示方框。--Kethyga留言2024年5月29日 (三) 00:38 (UTC)回覆
我這裏不能復現--百無一用是書生 () 2024年5月29日 (三) 03:28 (UTC)回覆
我這也是,認真說應該是我兩台電腦都開chrome,一台正常顯示,另一台則是全方框。--WiTo🐤💬 2024年5月29日 (三) 05:34 (UTC)回覆
天珩全字庫(大陸標準)和字雲(日本標準),它們都支援到了I區。--Miyakoo留言2024年5月26日 (日) 10:58 (UTC)回覆
目前轉換表主要是我在維護,過來解釋一下。確實如上文所說,目前只支持到中日韓統一表意文字擴展B區及以前的規則,B區之後基本只支持了通用規範漢字表表內的規則。這麼做主要還是考慮到大眾用戶的設備顯示,現在大家使用手機訪問的頻率變得更高,但目前手機顯示基本只支持到擴展A區+所有表內漢字,因此不敢妄作擴張,怕反而傷害了用戶的閱讀體驗。—Chiefwei - 2024年6月8日 (六) 13:23 (UTC)回覆

本討論章節會維持開放,暫時不按最後意見發表時間存檔。欲讓機械人存檔,請移除本模板。留言請置於本模板上方。

Module:MapframeModule:Location map報錯

編輯

好像就在近期,新出現了不少Module:MapframeModule:Location map的Lua錯誤[2][3],如天門山寺和合石。--Kcx36留言2024年6月9日 (日) 10:35 (UTC)回覆

我也注意到了;似乎在條目內將{{coord}}中的display=title改為display=inline,title可以解決報錯。從時間上看,會不會和為了解決上面的問題(#Template:Infobox_body_of_water中的坐標會重複兩次),Shizhao在Module:Coordinates的幾個編輯(82849253)有關?Irralpaca留言2024年6月9日 (日) 11:12 (UTC)回覆
看來似乎是Module:Coordinates修改後,導致Module:Location_map#L-122取不到/取錯值了--百無一用是書生 () 2024年6月9日 (日) 12:17 (UTC)回覆
改為display=inline,title或者display=inline都可以解決報錯--百無一用是書生 () 2024年6月9日 (日) 12:30 (UTC)回覆
測試了一下,Module:Location map用display=title的時候,坐標並不會顯示在標題右上角(直接就不顯示),似乎這樣和coord對參數的聲明不符合?--百無一用是書生 () 2024年6月9日 (日) 12:36 (UTC)回覆

本討論章節會維持開放,暫時不按最後意見發表時間存檔。欲讓機械人存檔,請移除本模板。留言請置於本模板上方。

Wikiplus導致Navbar被換行

編輯

RT,{{Navbox}}模板最近才出現的問題,啟用Wikiplus後會導致Navbar被換行,粵維無此問題。--Dabao qian 2024年6月12日 (三) 18:19 (UTC)回覆

您是指快速編輯按鈕沒有和查論遍在同一行?——暁月凜奈 (留言) 2024年6月12日 (三) 18:51 (UTC)回覆
他會不會說的是「編」被挪到了下一行的問題?我也困擾一段時間了,之前顯示是「查·論·編/(快速編輯)」,但近段時間一直顯示為「查·論·/編(快速編輯)」了。--自由雨日留言2024年6月12日 (三) 19:00 (UTC)回覆
沒錯,而且粵維的顯示就是正常的「睇·傾·改(快速編輯)」無換行,不知道中維哪個CSS出了問題。--Dabao qian 2024年6月13日 (四) 08:30 (UTC)回覆
涉及排版的因素挺多的,不同設備可能區別明顯,我目前未遇到此問題,不過此前也有過。zh和yue的網站設置有一些區別,最近的話可能是zh的字號調整。模板的css似乎並沒有更動。——暁月凜奈 (留言) 2024年6月13日 (四) 08:39 (UTC)回覆
Timeless用戶表示已出現了一段時間orz--Tim Wu留言2024年6月13日 (四) 08:48 (UTC)回覆
粵維是連「(快速編輯)」都不會換到下一行嗎?(粵維我不是自動確認用戶,看不了Wikiplus效果。)我在中維一直是必看到換行的,只不過之前是「查·論·編/(快速編輯)」這種換行方式,相對來說還算美觀。我以為「快速編輯」肯定會被換行……--自由雨日留言2024年6月13日 (四) 09:27 (UTC)回覆
.navbox-title .navbar { width: 8em; },加上那個按鈕後寬度爆掉了,就這麼簡單。(粵維這行被拆掉了)--SunAfterRain 2024年6月15日 (六) 10:56 (UTC)回覆
已修復,但留意到問題:最近@Shizhao修改Common.css後,navbar「查論編」這三個字的顏色,不能被設置了(詳見Template:香港電台頻道該模板在今年4月30日的存檔)。--Tim Wu留言2024年6月19日 (三) 07:46 (UTC)回覆
Module:Navbar/styles.css.navbar-mini abbr { color: inherit !important; },加上這個之後顏色就不能設置了。而且font-size: 88%;這行也應該去掉,中文似乎不需要。--Dabao qian 2024年6月19日 (三) 09:25 (UTC)回覆
為求省事抄的enwiki--百無一用是書生 () 2024年6月19日 (三) 13:55 (UTC)回覆
不加這行,「查論編」在dark模式下是黑色字,看不清,我暫時沒找到其他的修改方法...--百無一用是書生 () 2024年6月19日 (三) 14:04 (UTC)回覆
話說,修復之後,navbar的顏色怎麼變成無色了  囧rz……--自由雨日留言2024年6月20日 (四) 14:32 (UTC)回覆
上幾行留言正是在討論此事……--Cookai餅塊🍪💬留言 2024年6月20日 (四) 14:35 (UTC)回覆
啊?上面不是在討論「查論編」三個字(而非背景)的顏色嗎……--自由雨日留言2024年6月20日 (四) 14:38 (UTC)回覆
抱歉看錯了,背景色是深色模式強制覆蓋掉的。--Cookai餅塊🍪💬留言 2024年6月20日 (四) 14:47 (UTC)回覆
我沒有開深色模式……?而且剛好就是修復之後變成淺色的……--自由雨日留言2024年6月20日 (四) 16:54 (UTC)回覆
  已修復,之前改壞了--百無一用是書生 () 2024年6月21日 (五) 09:15 (UTC)回覆
8em那個是因為看到有個導航框的標題歪掉了(忘了是哪個了)--百無一用是書生 () 2024年6月19日 (三) 13:52 (UTC)回覆
8em和font-size:88%其實在Template:Navbox寫過說明了。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年6月19日 (三) 11:24 (UTC)回覆
簡單調整之後發現了新問題,很多導航框的副標題歪掉了,比如Template:芒果超媒。--Dabao qian 2024年6月25日 (二) 16:29 (UTC)回覆
並不是副標題歪了,而是標題歪了()明顯是「快速編輯」按鈕把標題往右「擠」了,不過具體算法我就不懂了……另外上面的回覆(8em之類的)似乎就是Shizhao等前輩在研究這一問題。--自由雨日留言2024年6月25日 (二) 21:50 (UTC)回覆

美國縣級行政區地圖顯示故障

編輯

弗吉尼亞州縣級行政區列表密西西比州縣級行政區列表密蘇里州各縣列表馬里蘭州行政區劃愛達荷州縣級行政區列表等列表中的小地圖顯示故障,只顯示一個紅色塊而沒有網格,同時對應各縣的條目的地圖也是一樣的問題,好像是原圖批量出了問題?

 

--桃花影落飛神劍留言2024年6月17日 (一) 15:43 (UTC)回覆

是批量出了問題,我建了很多個縣都是這樣子。經調查,這不是本人能力範圍內能解決的,只能坐等一天恢復正常。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月17日 (一) 15:51 (UTC)回覆
是維基共享使用的底圖出問題了,各種語言維基都有顯示問題。這邊不動手,英維那邊也會吵起來,讓相關人員處理。這個應該算是技術問題?大概很快就有{{Tracked}}的工單。--Nostalgiacn留言2024年6月17日 (一) 16:59 (UTC)回覆
懷疑與最近librsvg版本升級有關--百無一用是書生 () 2024年6月18日 (二) 03:02 (UTC)回覆
根據phab:T367645#9902624的說法,svg文件原本就有問題,只是沒有表現出來,librsvg升級後這個問題變嚴重了。可以參考下這個[4],一大堆的報錯--百無一用是書生 () 2024年6月19日 (三) 02:25 (UTC)回覆

跨項目通知的藍點

編輯

近期發現在中文維基百科的頁面中,「常規通知」右側有藍點,一般情況下點擊之後頁面會被標記為已讀狀態。但是跨語言/跨項目的通知的「總」藍點無法點掉(原來是可以的),只能一個個點擊「子」藍點來已讀。例如:

來自另外1個wiki的更多常規通知 ←(1)
中文維基詞典
您創建的[A]頁面在[B]頁面被人連結。←(2)

只有點(2)才會把標記為,而點(1)只有點擊手感,無其它改變。

請問是哪邊有了更改了嗎?--Leiem留言·簽名·維基調查 2024年6月19日 (三) 09:33 (UTC)回覆

似乎這個已經有一段時間了。我還以為是特意為之....--百無一用是書生 () 2024年6月20日 (四) 08:21 (UTC)回覆
我怎麼覺得一直如此……--YFdyh000留言2024年6月21日 (五) 05:22 (UTC)回覆
近期是這樣的,以前是可以直接點掉未讀消息的。--Leiem留言·簽名·維基調查 2024年6月25日 (二) 02:20 (UTC)回覆
我這邊也出現了這種問題。應考慮提交工單。—— Eric Liu 創造は生命(留言留名學生會 2024年6月26日 (三) 13:21 (UTC)回覆

深色模式界面格式問題:編輯模式對話框文本、SVG圖片、代碼塊背景色及字體

編輯

—此條未加入日期時間的留言是於2024年6月21日 (五) 08:14 (UTC)之前加入的。

NoteTA 烏克蘭地名無法正確轉換「頓內次克」

編輯

參考馬亞基 (頓內次克州),當中標題和內文都無法轉換到台灣以外地方使用「頓涅茨克」的稱呼。--MykolaHK留言2024年6月20日 (四) 16:22 (UTC)回覆

標題問題您似乎自己修復了(Special:Diff/83110663),內文也是一樣的問題啊,我剛剛修復了(Special:Diff/83111061)。--自由雨日留言2024年6月20日 (四) 17:15 (UTC)回覆
是的,另外想了解一下「頓內茨克」譯名的轉換,因部分媒體也有使用此譯名。--MykolaHK留言2024年6月20日 (四) 17:36 (UTC)回覆
公共轉換組譯名應該類似WP:命名常規,是根據一地的通用情況來確定的。如果「頓內茨克」在香港的使用率明顯低於「頓涅茨克」,應該採用後者。我不太了解具體的烏克蘭地名轉換,相關問題可前往公共轉換組討論?--自由雨日留言2024年6月20日 (四) 17:46 (UTC)回覆
沒記錯的話,是由於「頓內茨克」及「頓內次克」譯名爭議,公共轉換組中相關轉換暫停適用。—— Eric Liu 創造は生命(留言留名學生會 2024年6月21日 (五) 02:57 (UTC)回覆

模板中禁止使用noteTA標題轉換?

編輯

剛剛發現,如模板中加入noteTA字詞轉換,可能導致引述模板的條目中(標題等)的錯誤。例子:Template:手動工具。

有何方法禁止在模板中使用 noteTA字詞轉換,或至少在提交模板編輯時展示警告?--Zhenqinli留言2024年6月20日 (四) 17:51 (UTC)回覆

之前的版本直接添加了標題轉換(Special:Diff/83053442),那毫無疑問會導致標題錯誤……我已經改為只在正文轉換了(Special:Diff/83111564)。第二行,「禁止在模板中使用字詞轉換,或至少……警告」我沒看懂。--自由雨日留言2024年6月20日 (四) 18:30 (UTC)回覆
應該修正為:禁止在模板中使用noteTA(T=標題轉換)的選項。--Zhenqinli留言2024年6月20日 (四) 18:35 (UTC)回覆
Template:NoteTA/doc#其他注意事項已經指出「如果要在模板內使用本模板,請將本模板用<noinclude>……</noinclude>包圍」,理論上如果加了noinclude(現在已經被加上了),模板的標題轉換是不會影響條目中的標題轉換的,出問題是加模板操作錯誤。
另外,有的模板確實是需要標題轉換的(如{{共享創意}}),不應該禁止;倒是可以提示「在模板中加{{NoteTA}}要包含noinclude」。--古怪的Wang31討論 | 貢獻2024年6月21日 (五) 00:37 (UTC)回覆
感謝說明!我確實之前在模板代碼中都會看到{{NoteTA}}被<noinclude>……</noinclude>包裹,但感覺這裏和相關條目轉換規則的衝突概率不大,所以就沒加(Special:Diff/83111564),沒想到在Template:NoteTA/doc#其他注意事項中有強制要求。確實應該加上這句提示。尤其是對直接在模板中將局部字詞轉換參數寫作T(相關編者本意不可能是想將「手動工具」標題轉為「鎖定鉗」)的新手來說,一般更不會知道要用noinclude包裹的注意事項……--自由雨日留言2024年6月21日 (五) 01:22 (UTC)回覆
說點遠的:我覺得將來應該擴展MW自己的字詞轉換語法,給規則設定作用域,這樣就可以最終解決這個長久以來的痛點。--碟之舞📀💿 2024年6月21日 (五) 03:16 (UTC)回覆
應該是「模板的作用域」,有些模板不應該透傳到其他頁面。也就是noteTA不應該放在模板頁面中,然後被嵌入時透傳到條目頁面上。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年6月21日 (五) 03:25 (UTC)回覆

「為翻譯頁面標記{{Translated page}}」小工具的bug

編輯

應該產生的是「|version=<版本號>」,但是無法正常抓取版本號,變成了「|version=undefined」。--GnolizX留言2024年6月21日 (五) 12:23 (UTC)回覆

以淺藍色背景突顯被點選到的數學式其對應的NumBlk模板

編輯

我已將{{NumBlk}}的inline styles盡可能地都移到其對應的模板樣式CSS頁NumBlk/styles.css了。接下來,因為維基百科原本就有一些點選後以淺藍色背景顏色突顯目標的行為(例如:點選條目中的註釋編號後註釋文字會以淺藍色突顯、點選訂閱通知後在討論章節中新增文字會以淺藍色突顯),所以我想{{NumBlk}}或許也應比照辦理。例如,在特徵線法裏的數學式(6)其源碼為:

{{NumBlk|:|<math>
...(省略LaTeX,不是討論的重點)...
</math>|{{EquationRef|6}}}}

它的渲染結果為:

  6

而在條目的源碼中加入({{EquationNote|6}})即可產生連到該數學式的連結(6)。我希望點選前面那個連到數學式的連結後,會變成如下的樣式,也就是整個{{NumBlk}}的背景變為淺藍色:

  6

而不是只有編號的部份其背景變為淺藍色(這樣非常不明顯,而且也看不出整個數學式的範圍):

  6

以上的需求,不確定能否光靠模板樣式或CSS來達成?????

但是目前看來似乎有難度,因為({{EquationNote|6}})所連結到的目標是{{EquationRef|6}},所以用:target pseudo-class所選到的節點基本上是{{EquationRef|6}}而不是最外層的整個{{NumBlk|:|<math>...</math>|...}},如此就難以突顯整個{{NumBlk}},而是可能只有突顯到{{NumBlk}}的子節點,也就是編號的部份。可能這需要CSS selector能夠選到父節點的類似功能才能辦到...--Justin545留言2024年6月22日 (六) 15:25 (UTC)回覆

(~)補充Is there a CSS parent selector? 提到可以用:has() pseudo-class來選到父節點,但這CSS規格較新,一些browser可能不支援。--Justin545留言2024年6月23日 (日) 13:01 (UTC)回覆
  • (:)回應我用火狐和Chrome在F12 Console下使用
    console.log(document.querySelectorAll(".numblk:has(a:hover)"))
    
    回傳NodeList [ table.numblk ],如圖
 
但使用Template:沙盒/TemplateStyles測試之後得到以下錯誤訊息:
Error: Expected RPAREN at line 1, col 14.
在第 1 行裏字元 1 有無效的頁面選擇器清單。
似乎:has()語法在頁面內容模型(ContentModel)為「sanitized-css」(已過濾的CSS),也就是Help:模板樣式,似乎還不支援此種語法,所以系統會阻止你在Help:模板樣式:「sanitized-css」(已過濾的CSS)頁面中提交包含:has()的css selector,如圖
 
既然系統已經阻擋,即使繞過阻擋,該規則也會被MediaWiki過濾掉而無法生效,因此含有此CSS Selector會無法保存編輯(沙盒也發不了、而顯示預覽時,則該規則消失)。
所以,如需要讓Help:模板樣式支援:has()的css selector,可能需要提工單或提交社群願望清單。c.c.@Justin545-- 宇帆-娜娜奇🐰鮮果茶☕在維基百尋求休閒是否搞錯了什麼☎️·☘️2024年6月23日 (日) 14:59 (UTC)回覆
  • (:)回應
我之前沒有實際做過:has()的測試,沒想到sanitized-css或MediaWiki可能也是潛在的問題,感謝閣下的測試與回覆。
後有去查了一下,在MDN關於:has()的Browser compatibility一節看到各大browser的相容資訊,Firefox是121 (Released 2023-12-19)。所以根據該表,沒錯的話可以整理出一個相容性的清單:
  • Chrome:105 (Released 2022-09-02)
  • Edge: 105 (Released 2022-09-01)
  • Firefox: 121 (Released 2023-12-19)
  • Opera: 91 (Released 2022-09-14)
  • Safari: 15.4 (Released 2022-03-14)
  • Chrome Android: 105 (Released 2022-09-02)
  • Firefox for Android: 121 (Released 2023-12-19)
  • Opera Android: 72 (Released 2022-10-21)
  • Safari on iOS: 15.4 (Released 2022-03-14)
  • Samsung Internet: 20.0 (Released 2023-02-10)
  • WebView Android: 105 (Released 2022-09-02)
可以看到各browser似乎都要到2022年後才開始對:has()提供支援,對於不常更新browser軟件的使用者是有一定的危害。
現在主要的兩個問題:server side是閣下所發現的問題,client side是browser相容性的問題,這似乎讓:has()的解決方案走進暫時的死胡同裏。如果CSS的問題在幾年內都是暫時無解的,或許要考慮CSS以外的方法...。也許是另外再建一個新版的{{NumBlk}},譬如像是{{NumBlkEx}}這個新模板,然後在新版{{NumBlkEx}}的實作部份會自動把第3個參數(也就是編號)當作是最外層節點的id attribute,例如呼叫
{{NumBlkEx|:|<math>...</math>|17}}
展開後會自動變成
<table id="math_17" class="numblk">...(數學式與編號)...</table>
這樣當在條目中若有新增或存在既有的{{EquationNote|17}},它所連結到的目標基本上就會是整個{{NumBlkEx}}了(若沒錯的話,原本{{EquationNote}}所連結到的目標id是透過其展開後所包含的一個連結<a href="#math_17">...</a>所決定的)。若是這個做法,呼叫{{NumBlkEx}}時第3個參數就不應該再使用{{EquationRef}}。而{{NumBlkEx}}的實作部份看是要把{{NumBlk}}的源碼複制過去改,還是要把{{NumBlkEx}}當作一個wrapper template去呼叫原本的{{NumBlk}}。{{NumBlk}}的說明文件也要明顯地註明將{{NumBlkEx}}與{{EquationRef}}合併使用是不建議的(deprecated),應改用{{NumBlkEx}}。
目前還想不到較好的做法,上述做法的缺點是只能適用到新增的條目內容,原有的條目內容可能要手動(以機械人改對我有技術門檻,但英文維基呼叫{{NumBlk}}或{{EquationRef}}的次數估計皆超過1000次)慢慢改成使用新版的{{NumBlkEx}}。--Justin545留言2024年6月24日 (一) 05:01 (UTC)回覆

繁簡分類重新導向問題

編輯

歸類於繁體標題下之頁面,未能自動重新導向至簡體;如不丹宗份在「各國一級行政區」,卻不能自動分類至既有之「各国一级行政区」分類。Jimmy-bot可能亦需要注意此種分類。我知道手動建立分類重新導向應該可以解決,但本來應該不建立也能運作纔是。—— Eric Liu 創造は生命(留言留名學生會 2024年6月23日 (日) 14:32 (UTC)回覆

有沒有辦法限制重定向在條目正文中的使用?

編輯

諸如溫哥華白帽FC多倫多這樣屬於「常見錯誤拼寫」的重定向,有沒有辦法能限制它們在條目正文中的使用,使這些重定向只能用於搜索和導航,但不能在正文中出現?--📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年6月23日 (日) 16:53 (UTC)回覆

看了一下,正文目前也並沒有出現這兩個詞啊……(除了「溫哥華白帽」在介紹這個詞本身時候出現了一次。)如果用詞罕見或不當,正文自然不會出現(即便出現,也會被其他編者改為常用詞)。如果說您是想要通過技術手段限制類似的「錯誤用法」的話,我傾向沒有必要。--自由雨日留言2024年6月23日 (日) 18:46 (UTC)回覆
請問這麼做的意義是?尚沒有規則禁止不常見的錯誤拼寫,常見的又怎麼會被禁止?而且,技術上有可能實現嗎?--微腫頭龍留言2024年6月24日 (一) 17:10 (UTC)回覆
意義在於不讓條目質量下跌到可接受程度之下。而且既然是錯誤拼寫,自然不應該出現在正文之中。即使是這種重定向在正文中用作鏈接,也應該被豎槓後面的文字覆蓋掉(就像這樣:「[[溫哥華白帽|溫哥華白浪]]」)。📕📙📒📗📘 賭博機構最堅定的反對者 📚📖 2024年6月24日 (一) 18:39 (UTC)回覆
感覺可設立機械人檢查和提醒,但全自動是不行的。--YFdyh000留言2024年6月25日 (二) 14:26 (UTC)回覆
假如廣泛採用{{錯誤拼寫重定向|正確寫法=xxx}},機械人或許能幫忙處理。--Kanashimi留言2024年6月25日 (二) 22:58 (UTC)回覆

2024年第26期技術新聞

編輯

MediaWiki message delivery 2024年6月24日 (一) 22:31 (UTC)回覆

請求修改Cite book對統一書號的支持

編輯

前次未獲回應的請求見此,這裏重新複製粘貼下:

發現大量由中國標準出版社出版的中華人民共和國國家標準紙質出版物,將統一書號的第二部分添加了短橫線(如 GB/T 10302-2010 的 155066·1-40495GB/T 33677-2017 的 155066·1-56323 等),也出現混用了圓點·與短橫線-的情況(GB/T 32626-2016 的 155066-1-55030)。雖然暫時沒找到短橫線的意義是什麼,但請求修改Module:Citation/CS1/Identifiers以添加對第二個短橫線的支持,以及不要強制將-轉為·。--Tim Wu留言2024年6月28日 (五) 06:05 (UTC)回覆