跳转到内容

模块讨论:ZhConversion

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

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

[编辑]
最新留言：4天前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”