跳转到内容

模組討論:ZhConversion

页面内容不支持其他语言。
添加话题
维基百科，自由的百科全书
Leo768在话题“編輯請求 2025-10-20”中的最新留言：11天前

Template:Va不能识别重定向和繁简重定向

[编辑]
最新留言：3年前18条留言3人参与讨论

本主題或以下段落文字，移動自Wikipedia:互助客栈/技术。执行者：今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月30日 (二) 08:55 (UTC)。回复

如题。（繁简重定向指：重定向后页面上没有（重定向自……）文字）

遇到这种情况时，虽然点击链接可能会到达一个内容丰富的页面，但是模板显示的图标还是红的。

我之前在编辑Wikipedia:中文領域基礎條目的子页面时发现这个问题。有解决办法吗？--GUT412454（留言） 2022年7月31日 (日) 10:32 (UTC)回复

有Lua模組Module:redirect，但是很有可能超出模板上限。--Ghren🐦🕘 2022年7月31日 (日) 13:05 (UTC)回复
(：)回應@ghrenghren：模組改進去了，但Wikipedia:基礎條目/第五級/人物/作家及撰稿人確實超出了模板上限……有解嗎🤔（已暫時改回不識別重定向的版本，超出模板限制的截圖，TG留言）-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月19日 (五) 01:02 (UTC)回复
@ghrenghren：你可能誤會了，他不是指Module:redirect裡面支援的那種重定向，Module:redirect裡面支援的是「要有存在具體的重定向頁面」，但根據上方說法，此例是「不存在具體的重定向頁面」，也就是說，是連「重定向頁面」都「沒有」的繁體簡體頁面自動指向（你自己看上面說的：「重定向后页面上没有（重定向自……）文字」代表這根本不是「重定向頁面」，是系統自動將繁簡文字差異自動匹配頁面，嚴格來說，不叫做「重定向」），故Module:redirect在這個例子上發揮不了作用。據我所知，Lua裡面的Title library提供的redirect相關功能是不支援連「重定向頁面」都「沒有」的繁體簡體頁面自動指向，可能需要去phab提工單，讓Title library、Help:魔術字等功能能夠處理繁體簡體頁面自動指向（即當繁體頁面存在時，但不存在簡體頁面mw.title.new(簡體頁面名)要能夠返回繁體頁面，需要請求提供這個功能）。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月1日 (一) 04:22 (UTC)回复
我弄給你看：標題「大截角截半二十面体」頁面不存在，僅有「大截角截半二十面體」存在，「大截角截半二十面体」輸入Module:redirect後仍是「 大截角截半二十面体 」沒有變成「大截角截半二十面體」，對比{{PAGESIZE:大截角截半二十面体|R}}→「0」和{{PAGESIZE:大截角截半二十面體|R}}→「11050」。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月1日 (一) 04:50 (UTC)回复
試了一下，你所說的都對，我錯了，不好意思。--Ghren🐦🕒 2022年8月2日 (二) 07:40 (UTC)回复
@Ghrenghren：你覺得讓lua能支持這種「繁簡重定向」值不值得到phab提一個工單？-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月10日 (三) 08:09 (UTC)回复
發現Lua模組可能有辦法解決，將在近日開發相關模組-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月18日 (四) 03:03 (UTC)回复
對比Module:redirect：「大截角截半二十面体」系統內建繁簡重定向到「大截角截半二十面體」
使用Module:redirect：
{{#invoke:Redirect|main|大截角截半二十面体}}→「大截角截半二十面体」（重定向失敗）
使用套上Module:ZhConversion與Module:redirect：
{{#invoke:Va|redirect_target|大截角截半二十面体}}→「大截角截半二十面體」（重定向成功）
另一項測試：「光澤 (礦物)」系統內建繁簡重定向到「光泽 (矿物)」
使用Module:redirect：
{{#invoke:Redirect|main|光澤 (礦物)}}→「光澤 (礦物)」（重定向失敗）
使用套上Module:ZhConversion與Module:redirect：
{{#invoke:Va|redirect_target|光澤 (礦物)}}→「光泽 (矿物)」（重定向成功）
問題可能有解了。@Ghrenghren：-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月18日 (四) 14:33 (UTC)回复
@GUT412454：這種時候最快的解決方案，是針對有問題的頁面去建立一個「真正具體存在的繁簡重定向」，讓他變成「重定向后页面上一定有（重定向自……）文字」，方法為直接網址列輸入https://zh.wikipedia.org/w/index.php?title=頁面名稱&action=edit，如果該頁面真的是「重定向后页面上没有（重定向自……）文字」的頁面就可以開始建立「真正具體的」重定向頁，建立完成後他就會從「重定向后页面上没有（重定向自……）文字」變成「重定向后页面上一定有（重定向自……）文字」，並且問題解決。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月1日 (一) 04:32 (UTC)回复
我要解决的问题不是重定向，而是模板不能识别重定向，导致文章长度的评级错误。但是你的意思是评级错误的问题可以通过重定向的方式解决？--GUT412454（留言） 2022年8月1日 (一) 10:25 (UTC)回复
@GUT412454：(：)回應我可能看錯了。你所指出的「重定向后页面上没有（重定向自……）文字」這類問題無法解決，因為不但Module:redirect無法識別（上方已展示，見#2022年8月1日 (一) 04:50 (UTC) ），以「大截角截半二十面体」和「大截角截半二十面體」的例子而言，{{PAGESIZE:大截角截半二十面体|R}}→「0」和{{PAGESIZE:大截角截半二十面體|R}}→「11050」不存在的那個頁面（也就是你說會「重定向后页面上没有（重定向自……）文字」的頁面）輸入Template:Va中的{{PAGESIZE:}}總是返回0，0作為評級標準一定是最低的，所以這會是目前的技術限制。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月1日 (一) 10:45 (UTC)回复
我覺得讓lua支援字詞差異頁面標題解析值得開一個工單，有沒有熟英文的可以幫忙提一下嗎？-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月10日 (三) 08:04 (UTC)回复
我想到辦法了，既然QR碼都建了本地Lua日文漢字轉換表了Module:QR/kanji，那我們也可以在本地Lua建繁簡轉換的轉換表，這樣就不用麻煩phab技術人員了，順便再建一個專用於繁簡轉換的重定向模組，來解決這裡的判定問題。只要整組都是Lua輸出，不透過模板多次呼叫，應該也不太會超過模板限制。此計畫若可行，將在近日進行。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年8月18日 (四) 02:58 (UTC)回复

編輯請求 2025-10-20

[编辑]
最新留言：11天前7条留言4人参与讨论
User:SunAfterRain

我在向中文Minecraft Wiki引入此模組時，注意到了此模組的轉換實現極其低效，尤其是在迴圈中大量使用ustring庫。請求作以下修改： 

function p._language_cvt(str, cvt_table, max_length)
	local source = {}
	for cp in mw.ustring.gcodepoint(str) do
		table.insert(source, mw.ustring.char(cp))
	end
	local result = {}
	local strlen = #source
	local i=1
	while i<=strlen do
		local changed = false
		local this_char = source[i]
		for ji = 1,max_length do
			local j = max_length - ji
			if i + j <= strlen then
				local check_str = table.concat(source, nil, i, i + j)
				if cvt_table[check_str] then
					table.insert(result, cvt_table[check_str])
					i = i + j
					changed = true
					break
				end
			end
		end
		if not changed then table.insert(result, this_char) end
		i = i + 1
	end
	return table.concat(result)
end

如此能極大幅改善效能，並放開rule_max_length的限制而不必擔心超時。--Leo768(Talk|Contributions) 2025年10月20日 (一) 09:19 (UTC)回复

@Leo768：可否解釋一下這樣修改為何能改善效能，我有點沒有看懂？以及source表、result表的增長是不是其實反而會占用大量儲存空間導致模組無法繼續運行呢？--SunAfterRain 2025年10月22日 (三) 03:04 (UTC)回复
mw.ustring.sub的開銷很大，其每次呼叫時都要對整個字串按碼位拆分（ustring.lua§375），相當於每次都要在內部重新生成一次該source表（O(n^2)），導致很大的效能問題。我提議的版本預先將字串拆分，透過只拆一次改善效能。
至於result表，與您以為的相反，這麼做其實能相當程度改進記憶體效率。由於Lua的字串是不可變的，每次連接操作都會複製整個字串，產生大量垃圾物件（Programming in Lua§11.6）。加入表後再concat可以得到較好的GC效率和記憶體佔用。--Leo768(Talk|Contributions) 2025年10月22日 (三) 06:48 (UTC)回复
您找到的ustring.lua是一个不常用的纯Lua实现（通过require( 'ustring' )调用），而mw.ustring其实是包装了PHP的字符串功能（见mw.ustring.lua、UstringLibrary.php）。不过它用到的PHP mb_substr看起来也免不了每次重新从byte array解析unicode code point，所以您的分析应该仍然成立。
我认同您对string的immutable性质的理解。如果有测试样例应该更容易被认可；比较遗憾的是在phab:T391658解决之前，WMF站点的详细Lua profiling功能恐怕不会开回来，所以只能看到Lua time usage和Lua memory usage。--Srapoj（留言） 2025年10月24日 (五) 22:23 (UTC)回复
兩個修改是我之前在其他wiki測試過看時間與記憶體資料，確定都有顯著效能優勢後才於這裡提出的。--Leo768(Talk|Contributions) 2025年10月25日 (六) 13:28 (UTC)回复
如果单纯是为了性能的话其实没什么所谓吧。--Hamish T 2025年10月26日 (日) 03:50 (UTC)回复
問題在於此模組的確因為性能問題不得不將rule_max_length限制在較小的值。--Leo768(Talk|Contributions) 2025年10月26日 (日) 10:44 (UTC)回复
检索自“https://zh.wikipedia.org/w/index.php?title=Module_talk:ZhConversion&oldid=89681305”