维基百科

模板讨论:Internal link helper

最新留言：1年前由Jimmy-bot在话题是否依然有必要保留“Template:(语言代码)-link”系列重定向（比如Template:en-link）？内发布

关于{{Internal link helper}} 编辑

最新留言：15年前2条留言2人参与讨论

以下内容移动自互助客栈（技术），新留言请置于框外。执行人：--ellery (留言) 2008年7月8日 (二) 07:32 (UTC) 。回复

这个模板目前除了去蓝链似乎没有别的意义。是否可以将需要翻译的条目使用类似{{NoteTA}}的方式列出，如“本条目需要翻译的链出条目”。—不想放弃 (留言) 2008年6月18日 (三) 02:53 (UTC)回复

页面提示不弹出 编辑

最新留言：14年前1条留言1人参与讨论

现在点用了Internal link helper的红链条目不再弹出页面提示, 而是直接地转到维基百科目前还没有名为“xxx”的页面. 用IE或Firefox都一样. -- 同舟 (留言) 2009年7月9日 (四) 13:55 (UTC)回复

部分功能换用JS实现 编辑

最新留言：14年前1条留言1人参与讨论

目前已把部分会扰乱用户复制内容，扰乱搜索引擎检索的功能换用JS实现，有关代码见MediaWiki:Gadget-internalLinkHelper‎.js。--菲菇＠维基食用菌协会 2010年2月15日 (一) 20:12 (UTC)回复

2010-02-16格式变动 编辑

最新留言：14年前2条留言2人参与讨论

只是觉得如果要将其他WP的连接文字字体缩小的话就该连全形括号都一拼缩小。说实话我宁可维持旧版的java都不喜欢现在的括号版，不过我是明白这改动的原因。--同舟 (留言) 2010年2月16日 (二) 15:57 (UTC)回复

原来的版本请在Special:参数设置->小工具->用户界面工具->启用内部链接助手上启用。只是添加了个开关，这样会有更多的选择。--菲菇＠维基食用菌协会 2010年2月16日 (二) 17:05 (UTC)回复

{{Internal link helper}}失效？ 编辑

最新留言：12年前3条留言3人参与讨论

在小工具里关闭再开启，刷新缓存，使用其他浏览器都不能显示那个框，而是变成普通的红链了。--MakecatTalk 2012年1月18日 (三) 01:48 (UTC)回复

Firefox 9.0.1表示运作正常。-- 同舟 (留言) 2012年1月18日 (三) 01:53 (UTC)回复
Aurora 11.0a2表示运作正常。我记得以前我貌似也见过失效的情况，后来就莫名其妙的好了……--铁铁的火大了（抓兔子啦，抓兔子啦……） 2012年1月20日 (五) 05:35 (UTC)回复

Template:Internal link helper 编辑

最新留言：12年前3条留言2人参与讨论

怎么又自动展开了原本应该是弹出式信息框为正文文字（如：列宁格勒大道（英语：en:Leningradsky Prospekt）？而且连设置中-小工具都没有了internal link helper的选项了。-- 同舟（留言） 2012年4月3日 (二) 03:07 (UTC)回复

知道了是“跨语言链接”的各个选项，但能不能每次作这种改动后在doc中说明一下。-- 同舟（留言） 2012年4月3日 (二) 03:10 (UTC)回复
在WP:VPM说了。Liangent (留言) 2012年4月5日 (四) 02:36 (UTC)回复

{{ilh}} 编辑

最新留言：11年前10条留言3人参与讨论

发现{{ilh}}有个问题，比如说皇帝（英语：Symple）移上去显示的是“条目“皇帝”不存在，可参考英语维基百科的对应页面：Symple。”而不是应该出现的“条目“简单”不存在”。--CHEM.is.TRY 2012年6月10日 (日) 10:58 (UTC)回复

因为现行的ilh模板里两个红链是一样的(框外红链和框内红链),说来这似乎是以前将tsl重定向到ilh时说过的不一致性问题... - Dr. Cravix ♬La Pluie 2012年6月10日 (日) 11:35 (UTC)回复
(✓)已修复 Liangent（留言） 2012年6月10日 (日) 11:40 (UTC)回复

谢谢。第二个问题：{{ATCvet}}中的“条目“XX”不存在”显示不正常，XX部分只能显示“ATCvet代码”。但是把括号删了（当然就错了）就没问题了。--CHEM.is.TRY 2012年6月15日 (五) 17:19 (UTC)回复

我这正常，你用的什么界面语言？Liangent（留言） 2012年6月16日 (六) 03:51 (UTC)回复
简体中文。--CHEM.is.TRY 2012年6月16日 (六) 04:03 (UTC)回复
zh-cn和zh-hans都没发现问题，只有zh有问题，删了这个后就好了。以后回答此类问题请使用语言代码……Liangent（留言） 2012年6月16日 (六) 04:09 (UTC)回复
目前还是不行……我直接把那个红字建了然后删掉{{link-en}}算了--CHEM.is.TRY 2012年6月16日 (六) 04:29 (UTC)回复

现在呢？Liangent（留言） 2012年6月16日 (六) 05:35 (UTC)回复

恩，现在可以了。谢谢！--CHEM.is.TRY 2012年6月16日 (六) 11:53 (UTC)回复

再提修改跨语言链接({{ilh}})默认效果 编辑

最新留言：11年前61条留言16人参与讨论

(※)注意:请诸君还是在试用了效果效果6("鼠标点击时显示Tooltip")与效果7("鼠标悬浮时显示Tooltip")之后再作评论吧,若有问题也请在下方回报.

之前的讨论也很多了,从前几次的讨论中也看得出许多人也不喜欢默认效果,我要说的还是那几点:

  1. 中英对照模式在跨语言链接多的时候非常影响版式;
  2. 红字不利于参照;
  3. 浅蓝直链既容易混淆也不易参照;
  4. tooltip样式虽方便参照但无任何外部标识(如颜色标识).

所以我还是认为应该使用"以较易区分的颜色标识跨语言链接,鼠标悬停(或点击)后出现中英对照提示框"的样式,我在下提供了几种效果的对照.至于我提到的效果,请在参数设置-小工具里勾选跨语言链接模板效果6(即"鼠标点击时显示Tooltip")或7(即"鼠标悬浮时显示Tooltip") (效果6:绿色标识,点击出现提示框;效果7:悬停出现提示框;7种效果一次只能选一个,请切记),然后点选下面的"link-xx系模板"标签查看即可.

另,我在隐藏模板里放了些上次问过的问题,在提问前烦请看看;若有其它问题也请提出,我会尽量回答&再作添加. - Dr. Cravix ♬La Pluie 2012年9月16日 (日) 13:40 (UTC)回复

意见区 编辑

有问题或其他意见请在此提出. - Dr. Cravix ♬La Pluie 2012年9月16日 (日) 13:51 (UTC)回复

其实6和7是一回事，只是技术细节不同。7是我提的所以我的立场很明显了吧。--达师 － 218 － 372 2012年9月16日 (日) 13:45 (UTC)回复

(＆)建议，1、语言内链去除。2、括号及其内部文字缩小字体。乌拉跨氪 2012年9月16日 (日) 14:01 (UTC)回复
请自行更改Template:Internal link helper。卍田卐JC1 2012年9月16日 (日) 14:12 (UTC)回复
支持纯红字--百無一用是書生 (☎) 2012年9月17日 (一) 01:25 (UTC)回复
(：)回应:问题在于没有一个容易执行的标准,如我上面的FAQ所述...而且效果6与7是(异色)红链+提示框内红蓝对照这样,也没有误导的可能. - Dr. Cravix ♬La Pluie 2012年9月17日 (一) 08:38 (UTC)回复
纯红字有个不好，如果有人想消红，旁边的外文链接可以指引翻译方向，也就是模板默认效果最好有中外对照。——Sakamotosan 2012年9月17日 (一) 14:42 (UTC)回复

应当允许适度使用interwiki，“适度”的标准可以定为：

(：)回应:呃,这和默认效果不是差不多么? - Dr. Cravix ♬La Pluie 2012年9月17日 (一) 08:38 (UTC)回复
  • 每个条目interwiki不超过5个（或者更少）。

现在的条目评选，有的用户已经把使用interwiki当成反对理由，完全不顾社群对此没有共识的现状，这是对投票权的滥用。另外我建议在模板里增加一项参数，控制是否显示“英语：”（默认不显示），这种语言内链很影响视觉效果而且完全没有必要。

关于这套模板（{{ilh}}和某人衍生的{{tsl}}）的问题：
  • 首先明确的是，禁止直接跨维基（像[[:ja:XXX]]），另可丢空红链，不过如果显示样式上，[[红链]]（英文：[[:en:XXX]]）的确比较好，明确告诉人家源头在哪和让其决定看下去，或者进行本地化翻译，而且这套模板基于JS的，一旦JS加载出问题（经常这样，很多JS脚本没加载，要再刷新页面），就跟普通红链一样，当然对于老写手来说就没问题，但许多新手就会把他们改成直接跨维基链，所以必须明确规定禁止直接链，一定限制使用[[红链]]（英文：[[:en:XXX]]）或使用模板（最好用模板，因为外语跨维基链相对的本地条目被消红好时，有机器人自动清理，直接写没这个，只能靠人手筛选修改）。
  • 另外，对于参见评选的条目，适量的的跨维基红链问题不大，毕竟说明我们仍有改善空间，仍可以进行消红，但太多仍然不好，例如DYK的尽量占链接数90%以下，评优良和特色就尽量低于50%，最多容许5%～10%左右，可以改数字，大概模样就这样。
  • 模板显示方面，匿名和默认的话，最好是[[红链]]（英文：[[:en:XXX]]）这样，至于已登录的老手，就自己选择吧。
  • 还有显示部分，如果不明确参见的维基语言名的话（即不写“英文：”的话），最好能改一下跨维基的链接颜色，最好明显能区分出于本地内链的不同

——Sakamotosan 2012年9月17日 (一) 04:39 (UTC)回复

默认最好是[[红链]]（英文：[[:en:XXX]]），语言不用链，会过度链接了——Sakamotosan 2012年9月17日 (一) 05:15 (UTC)回复
  • (：)回应:抱歉,不要自说自话好么= =请自己试试效果6和7或者看其注释是怎么写的,哪来的直接跨语言链接呢?js加载不完全那也没办法,我说的两个效果依赖于mediawiki.util和ext.gadget-lib,分别分管mw和字词转换,没加载页面也就差不多了.而且,我也不认为为了"好看"就要去掉跨语言链接给别人参照制造麻烦,zhwiki条目不全面根本不是读者的问题.还有,很多新手[谁？] - Dr. Cravix ♬La Pluie 2012年9月17日 (一) 08:38 (UTC)回复
(：)回应谢谢提醒，特意登出来看下模板默认的显示效果，这个效果已经足够了，至于是否连上语言，我觉得没这个必要，至于登录用户要怎样显示，就没所谓了，毕竟不同人的对显示的习惯有不同，现在能提供的显示方法基本满足了（应该），是不是肯定新手我不确定，但我总遇到直接写跨维基链，最后我全改成模板的。——Sakamotosan 2012年9月17日 (一) 14:37 (UTC)回复
  • (：)回应:上面我也给了样例了,红蓝对照效果在只有一两处ilh时勉强还能接受,一多就要影响版式;另一方面说,zhwiki某些类别(如电子乐和IT)的条目实在太少,而在这类条目中参照又常很有必要以至不应直接红链处理.另外,你所举的例子中"新手"的行为和你的原始描述大相径庭,"直接加iwlink"和"把ilh改成iwlink"是完全不一样的概念,你提的现象用任何效果都不可能解决. - Dr. Cravix ♬La Pluie 2012年9月18日 (二) 04:03 (UTC)回复
(：)回应，太多的话，是难看些，但也说明我们仍需大大地努力（写条目），能顺手一下就顺手补上，不要红太多。第二，我指的是，有些不知规矩的（像新人的）都会写成[[:en:example|例子]]的，如果我见到的话，我都会改成像{{link-en|例子|example}}这样的。（而且有考虑能否利用机器人根据这些模板列出一个列表，标明这里要建立的对应名，可以参考的外语区，然后进行人手从表中选取进行翻译。）——Sakamotosan 2012年9月26日 (三) 14:31 (UTC)回复
唉,实话说也很少见到你翻译条目吧,你真的知道翻译条目的习惯吗?我当然知道你的例子的意思,我只是说这和本串讨论毫无关系.而且悬浮框效果怎么就不说明需要努力了?悬浮框效果在不混乱版面的同时为想写条目的给了翻译的参照,不想写条目的给了进一步了解的参照,不想看英文的什么事都没有,皆大欢喜.至于用机器人建立列表,"建立列表"只是制造出一个如同"翻译请求"般的废页面,我真的不是开玩笑. - Dr. Cravix ♬La Pluie 2012年9月27日 (四) 13:58 (UTC)回复
  • “有的用户已经把使用interwiki当成反对理由，完全不顾社群对此没有共识的现状，这是对投票权的滥用。”，如果什么事情都有共识还投票做什么。--达师 － 218 － 372 2012年9月17日 (一) 04:57 (UTC)回复
为什么要链en?--百無一用是書生 (☎) 2012年9月17日 (一) 05:50 (UTC)回复
例子而已，不要介意细节——Sakamotosan 2012年9月17日 (一) 06:13 (UTC)回复
你们说的6和7在哪里？我完全看不到--百無一用是書生 (☎) 2012年9月17日 (一) 06:55 (UTC)回复
6和7指小工具【跨语言链接：Dr. Cravix's（鼠标点击时显示Tooltip）】和【跨语言链接：鼠标悬浮时显示Tooltip】--YFdyh000 2012年9月17日 (一) 07:41 (UTC)回复
  • 同意2或7。另外回应上面的“有的用户已经把使用interwiki当成反对理由，完全不顾社群对此没有共识的现状，这是对投票权的滥用”，这个我当初投票时已经说了使用目前的格式全部都会投反对了，何以现在才说“对投票权的滥用”？--CHEM.is.TRY 2012年9月17日 (一) 08:40 (UTC)回复
我现在是外链全都加html注释，连这类模板都懒得用了……--铁铁的火大了（留言） 2012年9月18日 (二) 13:07 (UTC)回复
现在使用link-en 是不是最好的选择？ 我个人是这么认为的， 如果大家都同意， 我打算试做个 自动替换成 link-en 的 机器人玩玩。--Scoooooorpio（留言） 2012年9月19日 (三) 07:18 (UTC)回复
目前不是，因为默认样式太难看。--CHEM.is.TRY 2012年9月19日 (三) 12:19 (UTC)回复
请参看WP:AWB/TA，但因被回退，已暂缓执行。卍田卐JC1 2012年9月19日 (三) 13:06 (UTC)回复
其实问题在于,若实际条目名和显示名不匹配(像是[[:en:Booting|引导程序]]这样,实际上Booting对应的应该是"引导"),这种替换就肯定要出问题.... - Dr. Cravix ♬La Pluie 2012年9月27日 (四) 13:58 (UTC)回复
问题是比如说我全文翻译一篇美国女歌手的条目，如果不用跨语言链接的话，90%以上的链接都会是红链...其他类别应该也会有类似情况。--lavixcanvas Kiss - Carly Rae Jepsen 2012年9月26日 (三) 14:13 (UTC)回复
尽量也翻译周边，或者我有考虑能否做一个机器人自动根据这个模板收集一个表，列出其在中文对应名和对应的外文区参考，然后人手挑选来翻译。——Sakamotosan 2012年9月26日 (三) 14:31 (UTC)回复
工程量浩大...--lavixcanvas Kiss - Carly Rae Jepsen 2012年9月27日 (四) 03:37 (UTC)回复
如上,收集这样一个表只是制造一个类如"翻译请求"的废页面... - Dr. Cravix ♬La Pluie 2012年9月27日 (四) 13:58 (UTC)回复
红链就红链呗，总比打肿脸充胖子用跨语言链接好。乌拉跨氪 2012年9月26日 (三) 17:49 (UTC)回复
翻译的时候方便很多吧...就我个人而言跨语言链接还是挺有帮助的 没有的可以直接读其他语言版本--lavixcanvas Kiss - Carly Rae Jepsen 2012年9月27日 (四) 03:37 (UTC)回复
那就用现在讨论的模板啊。乌拉跨氪 2012年9月27日 (四) 05:40 (UTC)回复
{{ilh}}默认版式在JS没完全加载时最好能像现在中英对照那样显示（标识什么语言的链接可以不要，可能过度链接），若JS加载成功且匿名用户或没设好用户设置的话，在JS没加载时的基础上红链用tooltip显示外语链接（是按上去显示还是鼠标停靠时显示好，不太好说，我倒没所谓），如果有用户设置的，因为这与用户使用习惯有关，而且有不同的显示样式选择，就没所谓了。对于过多跨语言链对条目评级影响，如果评优良特色就尽量不要超过一定比例是不影响（最好再定个百份数）。还有必须禁止条目直接写成[[:en:example|例子]]这样取代中文条目的跨语言链，但保留允许[[例子]]（[[:en:example|example]]）作为外语参考，当然最后是用模板。——Sakamotosan 2012年9月26日 (三) 14:45 (UTC)回复
这样会让文字在js开始运行的时候跳动一下（类似Flash of unstyled content），大量文字会移动位置，如果用户已经开始阅读则非常影响阅读。Liangent（留言） 2012年9月26日 (三) 15:26 (UTC)回复
既然有了模板，就应该用模板。反对在条目内再使用任何类似这样的[[例子]]（[[:en:example|example]]）跨语言链接。乌拉跨氪 2012年9月26日 (三) 17:48 (UTC)回复
那是当然,那种样式光是维护起来就很麻烦了. - Dr. Cravix ♬La Pluie 2012年9月27日 (四) 13:58 (UTC)回复

怎么又不了了之了？要开个投票吗？--CHEM.is.TRY 2012年10月3日 (三) 06:16 (UTC)回复

多少次了……--MakecatTalk 2012年10月8日 (一) 06:49 (UTC)回复
随便，只要有人愿意组织。 --达师 － 218 － 372 2012年10月10日 (三) 14:59 (UTC)回复

为何突然就默认启用这个小工具了？之前的讨论完全没看出要默认启用这个工具啊。用了这个工具，都看不到红链了--百無一用是書生 (☎) 2013年1月29日 (二) 13:36 (UTC)回复

这个讨论移动自客栈方针部，且上面大多数意见都是同意使用效果7的。另外，哪里看不见红链了？选用“悬浮出现tooltip效果”时，鼠标若移到青链上，就会出现提示框，对吧？同时青链也变成红链，直接点下去就到达红链了，到底怎么是“看不到红链”啊…… - Dr. Cravix ♬La Pluie 2013年1月29日 (二) 14:14 (UTC)回复
同意使用某种效果并不意味着同意默认启用该工具。另，鼠标不放上去的时候可是看不到红链的，而且为何都往英文版连？是否不够语言中立？--百無一用是書生 (☎) 2013年1月29日 (二) 14:51 (UTC)回复
上面的标题是“修改默认效果”，在这里“同意”意味着什么不是很清楚吗……鼠标不放上去看不到红链，但只要直接一点就有了呀？而且，哪里是只能连到enwp啊，那不过是我的示例而已……中文条目（德语：德文条目），开“悬浮出现提示框”看效果吧。 - Dr. Cravix ♬La Pluie 2013年1月30日 (三) 00:42 (UTC)回复
改变默认效果之前就已经默认启用了吗？--百無一用是書生 (☎) 2013年1月30日 (三) 04:05 (UTC)回复
既然有共识了，那就应该改变默认效果了，也即改成“悬浮出现提示框”的效果啊，而若要使之生效就应默认启用小工具，这不是很正常的事情吗？ - Dr. Cravix ♬La Pluie 2013年1月30日 (三) 05:01 (UTC)回复
为何生效就要默认启用？用户自己选择启用不也可以吗？--百無一用是書生 (☎) 2013年1月30日 (三) 08:57 (UTC)回复
哈？若要用户自己选择才能启用的话，还能叫“默认效果”吗？= = - Dr. Cravix ♬La Pluie 2013年1月30日 (三) 09:02 (UTC)回复

那个讨论我也在客栈参与过。只是我一直以为那个讨论说的只是关于模板使用默认参数时所显示的效果，而不是默认启用与该模板相关的小工具（也就是说我理解这个讨论是说在不启用任何跨语言链接小工具的情况下，使用该模板时的效果。而不是在小工具中默认选用一种跨语言链接的效果）。刚才又看了一遍这个讨论，仍然没发现这个讨论提到默认启用小工具的事情。不知道怎么就变成了默认启用小工具？--百無一用是書生 (☎) 2013年1月31日 (四) 15:14 (UTC)回复

好吧，看来我一直没搞明白这个讨论的意思。但是，这个讨论我没看到达成什么共识啊，至少我没看到讨论中基本都同意目前所采用的这个默认效果--百無一用是書生 (☎) 2013年1月31日 (四) 15:24 (UTC)回复

2013-05-21偏好设定的错误报告 编辑

最新留言：10年前4条留言3人参与讨论

在选取“在Tooltip中显示原文链接”下：

  1. 如果只允许“鼠标悬浮时显示Tooltip”，悬浮tooltip 其显示时间过短到来不及用鼠标中键点击，而且不论鼠标是否维持在tooltip 的范围内都会定时消失，只有鼠标停留在原文链接上才会暂停其计时。
  2. 如果取消“鼠标悬浮时显示Tooltip”而启动“鼠标点击时显示Tooltip”，悬浮tooltip 和点击tooltip 同时出现，但这次的悬浮tooltip 则没有上述悬浮tooltip 的计时问题。
  3. 同时选取“鼠标悬浮时显示Tooltip”和“鼠标点击时显示Tooltip”，两种tooltip 都会生效，但悬浮tooltip 会发生第一点提及的问题。-- 同舟（留言） 2013年5月21日 (二) 04:57 (UTC)回复
全部  无法重现，请提供浏览器信息。另外这些选项不应同时选取多个。Liangent（留言） 2013年5月24日 (五) 07:02 (UTC)回复
Firefox 21.0, Windows XP. 那么偏好设定的解释不够清晰，应该在偏好设定中指明所有ILH的选项不应重叠，另外每个选项亦建议解析对红连的颜色影响，并且内连至本模板。-- 同舟（留言） 2013年5月24日 (五) 07:07 (UTC)回复
Sleipnir 3.8.4.4000（使用webkit引擎），xp sp3同样遇到1的问题，2未测试——C933103(留言) 2013年7月19日 (五) 06:38 (UTC)回复

建议 编辑

最新留言：10年前1条留言1人参与讨论

把ilh模版只填一个参数时改成和tsl一样，如{{link-en|abcxyz}}顕示效果改成abcxyz（英语：abcxyz）。——C933103(留言) 2013年7月19日 (五) 06:42 (UTC)回复

{{Internal link helper}}的一些疑问和建议 编辑

最新留言：10年前8条留言6人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2013年9月15日 (日) 14:42 (UTC)。回复

现在的{{Internal link helper}}不错，我很喜欢，很方便很漂亮，也解决了之前很多乱七八糟的争议，多谢管理员的工作。尽管如此，我依然有一些技术上的疑问和建议想要提出：

1、为什么{{Internal link helper}}/{{ilh}}模板是用为所有语言建立子模板（如{{Internal link helper/en}}）的形式实现的。为什么当时设计和制作该模板的时候不省略“lang”（语言名称）参数，只使用“lang-code”（语言代码）参数，然后根据lang-code，通过{{#switch:}}或{{#invoke:langname}}来得到该语言的名称，或直接用{{Langname}}（{{Langname}}原来使用的是{{#switch:}}，现在使用的是维基百科几个月前启用的Lua module的{{#invoke:langname}}，性能更好）？不知道当时是出于什么考量而使用子模板这种麻烦的方式的。因为不用那些子模板的好处明显：

  • 性能优化
  • 不用为了所有语言一个一个地建立子模板，也不用去烦那些尚未建立子模板的语言
  • {{Internal link helper}}/{{ilh}}模板可以直接被使用，形如{{ilh|en|<中文条目标题>|<英文条目标题>}}，这样代码也够短，够方便，不必建立那么多快捷方式。

当然现在也可以改用{{#invoke:langname}}，虽然子模板和那么多快捷方式已经被广为使用，但将它们重定向到{{ilh|xx|...}}也不是不可以。

2、一些小建议：

  1. 是不是考虑令模板支持两个或以上的跨维基链接？当条目涉及的对象（如某人或某地区），两种语言都被其高度使用、都是官方正式语言，或者两种语言的维基条目都极佳、都具有高度参考价值时，需要两个或以上的跨维基链接确实是可能的。
  2. 当外文维基条目标题和正常的实际的外文名并不完全一致的时候，特别是条目标题为了消歧义而加了括号时，是不是考虑也用piped link“[[abc (category)|abc]]”？
  3. 还可以让模板除了语言代码参数之外，只填一个参数就能用，比如对于现在的{{link-en}}就是，{{link-en|abcdef|abcdef}}可以直接写成{{link-en|abcdef}}，显示为abcdef（英语：abcdef）。

有的建议，因为现在“木已成舟”，可能不大好改。其实假如是我，我可能会设计类似于这样的主模板：{{il|<中文条目标题>|<显示出来的中文名称>|<语言1代码>|<语言1条目标题>|<显示出来的语言1名称>|<语言2代码>|<语言2条目标题>|<显示出来的语言2名称>...}}（除了<中文条目标题>和<语言1代码>，其他参数都可以省略，但如果后面还有参数，就需留空，如{{il|<中文条目标题>||<语言1代码>}}）。然后再根据需求，设计使用了主模板的单语言辅助模板，{{ils|<外语代码>|<中文条目标题>[|<外语条目标题>[|<显示出来的中文名称>[|<显示出来的外语名称>]]]}}（方括号[]中是可省略的参数与代码）。

3、这个为什么叫做“Internal link helper”，而不是叫做“Interwiki link helper”？internal link是在本语言维基百科中的相互链接，而不是跨语言维基链接，跨语言维基链接应该叫interwiki link，参见：en:Help:Link#Wikilinks。对于这个高度使用、约定俗成的模板和相关的.js，如果改名字麻烦那就算了，这个名字是小事，无所谓，只能说当时搞这个的时候没想好。

4、维基百科一直都没有用tooltip，是出于网络可用性（accessibility）的考量，参见en:WP:ACCESSIBILITY#Text。比如在没有鼠标的设备上浏览，或是打印版本中，条目中提供的信息是完整，还是残缺。现在{{Internal link helper}}用了tooltip，应注意这方面问题。{{Internal link helper}}模板文档中开头其实也提到了“印刷版本的考虑”。移动版本页面是显示为“中文条目（English Article）”，但在打印版本中没有括号中的内容，是不是考虑把代码中那个“noprint”的class去掉？此外，是不是考虑，不仅在中文链接被鼠标悬停，而且在它被focus的时候（按tab键可切换选中链接，在绝大多数浏览器中链接就会有虚线边框出现，这就是focus的状态），也显示tooltip？

感谢解答。--Tomchen1989（留言） 2013年9月4日 (三) 16:28 (UTC)回复

  1. 还有个{{tsl}}，不过两个模板的参数顺序刚好相反是大麻烦（两个混用多了会晕）。
    1. 倒不如链接到wikidata……
    2. 好像两个模板都有最后一个参数设置显示文字吧。
  3. 改名其实问题不大，各处代码基本都是写的ILH，恰好Internal和Interwiki都是I开头。
  4. 虽然不难实现，但是tooltip里的链接会没法tab进去，好像不是很实用。常用此类设备的用户可以去参数设置-小工具里选一个别的显示。
Liangent（留言） 2013年9月4日 (三) 17:14 (UTC)回复
btw. 参见ar:قالب:وصلة إنترويكي，User:زكريا找我去arwiki跑清理的bot。Liangent（留言） 2013年9月4日 (三) 17:17 (UTC)回复
{{tsl}}是个好奇怪的存在，有{{link-xx}}就用{{link-xx}}，没有的话用统一方法“{{ilh|lang={{langname|{{{1}}}}}|lang-code={{{1}}}|...”，那还不如就在{{ilh}}里直接用统一方法，不用子模板呢。||2.2中我说的是tooltip里面的的外文条目链接用piped link，{{tsl}}归根结底还是用的{{ilh}}，而看{{ilh}}的代码，外文条目链接显示文字和条目标题肯定是一样的，无法设置成piped link。--Tomchen1989（留言） 2013年9月4日 (三) 18:08 (UTC)回复
Wikipedia:投票/跨语言链接的处理方式的遗留物，建议删除。--不知名的鸡毛掸子（留言） 2013年9月5日 (四) 09:23 (UTC)回复
{{tsl}}的设计不错，而且是基于{{ilh}}实现的，不删也没问题。而且{{tsl}}也有大量使用，删了麻烦更大——Sakamotosan 2013年9月5日 (四) 11:21 (UTC)回复
还有一个问题就是在google知识图谱中引用的维基百科内容会因为这个模板的使用，而把模板中的文字忽略掉，例如我在某条目的第一段写了一些文字：
维基百科1{{link-en|abcdef|abcdef}}维基百科2维基百科3维基百科4

google知识图谱显示的时候就变成了：

维基百科1维基百科2维基百科3维基百科4

--百無一用是書生 (☎) 2013年9月5日 (四) 00:47 (UTC)回复

关于{{Internal link helper}}的使用 编辑

最新留言：9年前15条留言6人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2014年4月30日 (三) 14:42 (UTC)。回复

看看条目奥德维奇站，这整个页面到处都是{{Internal link helper}}生成的“绿链”，看起来花花绿绿，眼睛都花了。个人觉得，{{Internal link helper}}的用法是不是应该规范一下，不然如果被滥用会影响到页面的整洁。更重要的是，个人认为其实很多（在华人世界）相当冷门的内容，除非目标条目在，不然在中文维基百科中就不要链接了。尤其是像许多这种的翻译过来的条目，当中链接到的一些主题在源语言的世界里面关注的人比较多，所以就有人写，但在中文世界可能因为没什么关注度，所以自然就没人去写，或者都没有撰写的必要（多少更重要的条目都没人写啊）。所以有时候要不要进行链接请多考虑下实际情况。--Patvoiiage（留言） 2014年4月16日 (三) 14:55 (UTC)回复

我看了那条目，发现所作的绿连结全都是名词第一次出现，并没有over-wikify的现象，而且也都是些专有名词才有连结，所以并没有啥问题。“除非目标条目在，不然在中文维基百科中就不要链接了”这句话等于限制了中文维基的成长可能，也违背了维基百科名字中的“wiki”所代表的意义（可以到处快速连结），不太可取。条目不该有贵贱之分，有人喜欢写热门话题，但也有人偏偏喜欢研究冷门知识，但只要有机会吸引到一个人来作点贡献，那么这些绿色连结的存在就有意义。
如果不喜欢绿连结的话，取消ILH也还是得留下红色连结，不见得让人觉得顺眼。与其如此，不如您还是努力想办法习惯这样的画面吧！--泅水大象™ 讦谯☎ 2014年4月16日 (三) 15:22 (UTC)回复
绿链不太符合目前的设计规范啊--百無一用是書生 (☎) 2014年4月17日 (四) 02:20 (UTC)回复

 

同意书生的看法，内文应越简洁越好，而且要符合整个维基百科计划的设计理念。蓝色链接为互联网所通用，维基有红链接已经算是多了一种颜色了。再加入绿色，是非常混乱的，特别对红绿色盲的人来说。在大家希望保留绿链功能的前提下，“绿”链改成红色，但仍有提示信息，也无不可。我认为在恰当时，应再次询问社群意见，看绿链这个功能应否存在。钢琴小子 打个招呼 查看贡献 2014年4月17日 (四) 04:06 (UTC)回复
应该要区分未创建的页面、已创建的页面和外文页面。我个人觉得现在的红色、蓝色、绿色没什么问题。如果楼主不喜欢，可以自定义CSS，用选择器
.ilh-page a.new {
color: #009999;
}

--Gqqnb（留言） 2014年4月17日 (四) 16:55 (UTC)回复

我对于连结的颜色没有意见，要用绿色紫色粉红色，或是其他更适合阅读与网络规范的颜色都无妨。我在意的是这些ILH连结在“功能性”上的帮助，最近因为有ILH的缘故一些在过去因为地区用语差异在跨语言链接的订正上非常棘手的状况，都获得进一步的减轻，所以如果此时因为觉得颜色碍眼、以好看的理由而取消一个很实用的功能，那就是因噎废食了。如果此处要讨论的是禁止ILH的使用或连红色连结都要被限制的议题，我会投下反对票，但如果是要重新检讨连结用色或显示方式的问题，我倒是不反对。--泅水大象™ 讦谯☎ 2014年4月18日 (五) 03:36 (UTC)回复
姑且把ILH去留的议题撇开不说吧。在颜色方面，目前似乎有些花花“绿绿”。既然目标条目不存在，就索性统一使用原有的红色。如果要仍然保留跳出提示文字的功能，应加入适当的延时，要不然要在布满ILH的页面上尝试点击其他的链接是很困难的。钢琴小子 打个招呼 查看贡献 2014年4月18日 (五) 05:13 (UTC)回复
目前似乎就有延时设定，至少以我的阅读设定来说延时连一秒都还不到，所以说要造成点击其他连结的困难似乎有点牵强。--泅水大象™ 讦谯☎ 2014年4月18日 (五) 08:09 (UTC)回复
有两种延时。鼠标停留在绿链上直到出现tooltip的这个延时过短，导致鼠标在文字间移动时，tooltip会不断多次出现，遮盖下方、后方文字，影响阅读。另一种是tooltip出现的时长。即使鼠标停留在tooltip框内，它也会在一秒内消失，要阅读tooltip内容或点击远端的原文链接根本不可能。请自己试试：{{语言哲学}}。我建议作出以下改动：第一种延时要延长，使鼠标在文字间快速移动时不会产生tooltip；第二种延时只在鼠标移到tooltip以外才开始计算，如果鼠标在tooltip内，它会永久停留。钢琴小子 打个招呼 查看贡献 2014年4月18日 (五) 15:48 (UTC)回复
模板的连结密度较高所以因为这原因被遮住的几率高些，但平常的条目内容很少遇到会真的觉得阅读造成困扰的情况。且我一直很困惑一件事，为何阅读条目时要一直让鼠标游标在文字间移动，导致tooltip去遮住文字？至少我阅读条目内容时是用眼睛在看不是游标在看，所以完全无法理解上面这种情况为何会是个困扰？但就如同前面所说，对于连结颜色、tooltip的显示延时之类的技术性问题完全没意见，我反对的只是因为技术问题而去提议限制ILH的使用或是甚至主张要删除连结的言论。--泅水大象™ 讦谯☎ 2014年4月19日 (六) 06:08 (UTC)回复
其实我发起这个讨论最想表达的主要就是两个意思：1、{{Internal link helper}}最好不要过多使用，不然黑、蓝、绿、红四种颜色的文字一起出现会影响到页面的整洁。（有时应该也不利于读者阅读。）2、有的主题，特别是翻译过来的条目中涉及的，如果在中文维基百科这边确实比较冷门，也不重要，不如就先不要链接了，这样可以减少红链和绿链的出现。（请轻拍，此处亦没有违背“wiki”精神之意。）同时，我个人是建议规范和减少ILH的使用，还没有到要讨论去留的地步。个人觉得ILH也还是有一定用处的。--Patvoiiage（留言） 2014年4月18日 (五) 16:11 (UTC)回复
主题冷门不冷门到底要由谁去定义？您觉得不重要的主题可能对于别人而言是很有意思的，维基百科之所以能突出于寻常的纸本百科全书，并不只是因为收录条目的数量多而已，一些传统百科不会收录的内容这里也可以查到资料，不就是维基百科之所以为人所乐道之处吗？所以对于这种“不如就先不要链接了”的说法不只不想轻拍，反而会令人想狠狠踹一脚下去并大喝一声“有没有搞错！”哩。且平常在撰写内文时如果不预留连结，等到条目真的创建时也不太可能真的花时间去重建，到时新创的条目就很容易变成孤儿条目，孤儿条目是维基百科一直在努力要消灭的事物，所以阁下的主张根本就是在开维基百科倒车。--泅水大象™ 讦谯☎ 2014年4月19日 (六) 06:08 (UTC)回复
虽然我不认同，但Patvoiiage的观点也不无道理，不须要这么严厉反对吧。任何条目中的新词、相关主题都应该加上链接，而目标条目是否有关注度并不是要不要加上炼接的原因。如果是缺乏关注度或者尚未建立的条目，可以考虑先重定向至某个综合性列表（例如Ubt、Ubp等120号以后的元素），独立的条目可日后再建立。消除红色链接当然是重要的目标之一，但不能以直接删除红色链接来解决呀！钢琴小子 打个招呼 查看贡献 2014年4月19日 (六) 16:17 (UTC)回复
利用重定向的方式保留连结的存在，日后条目建立后很快就可以修正相关连结，这个作法是没问题的。我只是反对因为觉得某主题不重要而主张将其删除的作法。--泅水大象™ 讦谯☎ 2014年4月20日 (日) 05:22 (UTC)回复

红链改绿链毫无意义？ 编辑

最新留言：8年前35条留言17人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2015年6月3日 (三) 00:42 (UTC)。回复

User:Jarodalien两次回退我在新特警判官的编辑，第二次回退理由为“红链改绿链毫无意义”。请问维基指引有否禁止使用{{link-en}}？回退理由是否合理？

--Qui cherche trouve 2015年4月21日 (二) 09:31 (UTC)回复

谁说无意义的？没意义的东西还保留干嘛？——苏州宇文宙武的主页 ♨留言 ☎交友 ★贡献 2015年4月21日 (二) 11:25 (UTC)回复
Wikipedia:投票/跨语言链接的处理方式有投票支持将外语链接这样处理，使用{{ilh}}模板有助于提醒所有过目者存在相应外语条目解释和鼓励其进行翻译工作。——不挖旧坑的Sakamotosan向往旧坑死里钻的愚者致意 2015年4月21日 (二) 11:30 (UTC)回复
link是一种跨语言链接，因为以前的:en:这种禁止了，建议改用这种，这种并没有禁止使用，同样，也没有规定一定要使用，更没有规定不能够用红链。我认为你这种改动毫无意义，因为只不过是你习惯看跨语言链接而已，I don't give a shit，这种链接和红链都是可以存在的，但是我倾向于全部条目统一使用红链，至于别的人要在写条目时用什么绿链之类，不关我的事，反过来，谁一定要把红链改成绿链，以为这样就会更好的，那也就这么回事。有些人习惯用红链，有些习惯用绿链，哪一种都没有禁止，谁习惯用哪种，别人也管不着，我不会故意去把谁之前已经编辑的绿链改成红链，但你一定要把红链改成绿链，那这就是在做毫无意义的事。--7（留言） 2015年4月21日 (二) 12:00 (UTC)回复
的确没限制，但是不反对红改指导模版，而且这样“好”的行为以“毫无意义”来驳斥，恐有所有权申述的嫌疑吧。——不挖旧坑的Sakamotosan向往旧坑死里钻的愚者致意 2015年4月24日 (五) 00:41 (UTC)回复
红链改绿链意义可大了！一来便利核对检索译名的原文，二来遇到一事物有多种译名不同的状况时，透过机器人的协助可利用绿链自动建立各译名版本的重定向。我认为除非连结对象是错误的得进行修正，否则把别人建立的绿链删除，应该视为是一种破坏行为。--泅水大象™ 讦谯☎ 2015年4月21日 (二) 13:18 (UTC)回复
刘嘉兄最初不也是绿链支持者么，为何后来转而支持红链了？--Walter Grassroot (♬) 2015年4月21日 (二) 14:03 (UTC)回复
好像有段时间他提缴的评选一直被绿连这个理由反对，后来他就不用了...绿派红派终于要正面交锋了吗（误）--Liaon98 我是废物 2015年4月21日 (二) 14:05 (UTC)回复

前几天才有个和我有怨的用户上我茶寮闹事，对我修改{{新加坡历史}}模板的操作作出两条不尽不实的指控（由于当中包括诋毁本人的内容，所以这则留言已经丢到垃圾桶去了）。其中一条指控是，我在该模板当中调用绿连来取代红连，这人却说除非我打算把这个坑填平，否则用绿连没什么用。不过红连和绿连连接到的页面，不都是待创建的条目吗？只是绿连有对应的外文条目，红连却未必有罢了。（PS. 后一个指控更离谱，我就免提了。）--春卷柯南夫子 ( 论功行赏 ) 2015年4月21日 (二) 14:30 (UTC)回复

支持发文者。红链只是告诉你目前中文维基无此条目，并无告诉你是所有语言版本都没有条目，还是某些语言版本有条目，若是后者，又是哪个语言版本有，绿链则给出了解答，放绿链可比放红链的所需的工夫大多了，你必须连结到正确的条目，给出正确的译名。怎会没意义？-游蛇脱壳/克劳棣 2015年4月21日 (二) 14:44 (UTC)回复
红连其实也是有给出正确的条目译名啦--Liaon98 我是废物 2015年4月21日 (二) 14:56 (UTC)回复
只是考证起来会比较困难，编者给出红连时不一定要给出对应的外文译名。有多困难视乎情况；但不要忘记同名异译这个现象，例如我处理的某些东南亚条目，由于当地政府并没有制定统一译名（东盟各国就只有新加坡和马来西亚有这样做），所以这个情况特别严重。--春卷柯南夫子 ( 论功行赏 ) 2015年4月21日 (二) 15:27 (UTC)回复
个人认为应该尊重条目创建者的编辑。既然红连和绿连均是可以接受的话，那么就没有必要刻意将红连改成绿连，但是由于绿连需要运用机器人才能清理，因此个人认为短期内将会创建的条目使用红连比较好，未有打算创建的则使用绿连。当然，我认为两者是可以并存的，最重要的是尊重先到先得的原则。—AT 2015年4月21日 (二) 15:31 (UTC)回复
这又不是条目名称，哪有什么先到先得的说法？去年9月就创建了，至今红链未建立条目，你说用绿的好还是红的好？——苏州宇文宙武的主页 ♨留言 ☎交友 ★贡献 2015年4月21日 (二) 15:45 (UTC)回复
个人倾向使用绿连。可是，他人的编辑习惯我无意干涉，红绿各有优劣，所谓的先到先得也不过是采用绿连先还是红连先的意思而已。既然两种方法均可以接受，何必强逼他人站边？—AT 2015年4月21日 (二) 17:30 (UTC)回复
既然均可接受，那如果因此发生编辑战，即以编辑战相关方针处理，只要移除他人有益的编辑就是破坏，无须多言，也不是什么强逼站边的问题。——苏州宇文宙武的主页 ♨留言 ☎交友 ★贡献 2015年4月21日 (二) 17:45 (UTC)回复
(！)意见 Wikipedia:投票/跨语言链接的处理方式的共识是“绿链是完美条目中应当使用的方法之一”。毫无疑问，绿链的资讯比红链多了一个范畴，在标示条目未曾建立的同时，亦指向其他语言版本的维基条目，有参考性，亦有助建立新条目。新特警判官已经是特色条目，没理由舍长取短，回退惟一的动机相信只是编者的情意结，想维持条目于自己最后编辑的模样而已。--Qui cherche trouve 2015年4月22日 (三) 01:51 (UTC)回复
这个逻辑如果说得清楚就是如果“个别编辑反对成为特色的条目中出现绿链”，那么刘嘉兄的回退是情有可原的，因为可能会有编辑借此请求摘除特色。现在修改的规则，应当是特色条目的标准中，是应当主张绿链还是红链？--Walter Grassroot (♬) 2015年4月22日 (三) 02:25 (UTC)回复
如果真的是为了特色条目的评选而删除一些实际上很有用的内容，只能说整件事根本是舍本逐末。但是观察这整件事的来龙去脉，总觉得是个别用户霸占条目所有权的心态导致……--泅水大象™ 讦谯☎ 2015年4月22日 (三) 06:26 (UTC)回复
(：)回应：非常同意你的观察，这位个别用户不断地发生霸占Wikipedia:条目所有权情事并进行恶意回退编辑，社群却视若无睹。--春日クリス 敲敲 2015年5月23日 (六) 09:04 (UTC)回复
哟，又开始分析动机和心态啦，呵呵，种族问题。绿链是跨语言链接的处理方式，红链不是跨语言链接，凭什么认为跨语言链接比不使用跨语言链接的红链好？绿链在打印、移动版本上的问题有处理好吗？绿链数量大导致导致CPU占用率大幅攀升的问题解决了吗？只要没有定下规则，说能够用绿链优先用，凭什么要求他人一定要用？我以前不明白，现在接受了，有本事和小时去说啊，他这句就是很有道理：要链接到别的语言的话，还要中文维基做什么。他人如何如何肯定是改善，我如何如何那一定是霸占条目。本事很大嘛，定规则嘛，红链与狗不得入内不是更方便。--7（留言） 2015年4月23日 (四) 15:46 (UTC)回复
在编辑时喜欢保留红链或多花点功夫增添模版成为绿链是个人偏好，没什么对错，但是把其他用户增添的绿链给删除就有可议之处了。--泅水大象™ 讦谯☎ 2015年4月23日 (四) 16:40 (UTC)回复
  • 顺便说一句，对有些人当众说谎的本事再次表示佩服，那个投票中真正支持者最多的是
显示效果 代码
科蒂·曼宁（英语：Katy Manning）（英语：Katy Manning） {{link-en|科蒂·曼宁|Katy Manning|show}}
奥斯陆大教堂（挪威语：Oslo domkirke） {{link-no|奥斯陆大教堂|Oslo domkirke|show}}
2009年吉达暴雨（英语：2009 Jeddah floods）（英语：2009 Jeddah floods） {{link-en|2009年吉达暴雨|2009 Jeddah floods|show}}
  • 虽然模板文字相同，但实际上的显示模式与现在的绿链有根本性区别，只不过后来模板修改了而已。我倒想看看这样当众说谎之辈如何收场。--7（留言） 2015年4月23日 (四) 15:51 (UTC)回复
ilh系的显示模式在投票之后调整过，可以通过加载不同脚本来达到不同的显示效果，在设置里面有（以“跨语言链接：”为前缀），在t:ilh也有我做的事例图。而且你找的例子是第四套方案，实现的是第三套方案（这个方案也是后来可以选择的实现脚本之一），第四套方案下面有注明到技术实现问题。well，其实这个模板的最终目标是方便对可以翻译而暂没有本地页面的条目链接做一个提醒，显示方式更多是其次的作用。你这种坚持红链的行为并不是绝对错，但既然能提醒翻译，是好的行为，反而你这种行为有所有权声明的争议吧。——不挖旧坑的Sakamotosan向往旧坑死里钻的愚者致意 2015年4月24日 (五) 01:38 (UTC)回复
看了一下ilh的说明，第四套方案实际在移动版上实现到（偶然在脚本加载失败时也见到过，可信度定为50%），或者可以的话，请求一下L大等技术官帮手分离一个脚本出来也作为第四套方案的实现了。——不挖旧坑的Sakamotosan向往旧坑死里钻的愚者致意 2015年4月24日 (五) 01:47 (UTC)回复
第四套方案就是没选小工具时的效果，也就是不加载任何小工具的移动版或者加载失败时的效果……没弄错的话应该是当时的方案四选的人最多，于是把模板基础输出弄成方案四了，这个模板输出结构到现在也基本没改。然后搞了一堆小工具允许把模板输出调整成不同的样子，后来其中的一个小工具被改成了|default（[1]），于是现在看起来像是必选一个似的。Liangent（留言） 2015年4月24日 (五) 06:35 (UTC)回复
(！)意见：2014年12月争执，当初，大家好好处理类似问题，此事应当不会重演。 @SiuMai：@Kuailong： --36.225.12.102（留言） 2015年5月2日 (六) 16:33 (UTC) (原po，本周Hinet公司调整ip段所致)回复
(！)意见--红绿各有优点。绿链能鼓励翻译、参考他语种维基的指引，红炼也以“缺漏”刺激有心者编辑。Wetrace 欢迎参与WP:人权专题（留言） 2015年5月3日 (日) 01:11 (UTC)回复
(！)意见：以后能够说这个是赤党与绿党之间的斗争么？--Walter Grassroot (♬) 2015年5月6日 (三) 02:05 (UTC)回复
统计上面留言用户的意见，感觉比较像是单一用户对抗社群共识的斗争……--泅水大象™ 讦谯☎ 2015年5月6日 (三) 10:11 (UTC)回复
(！)意见:不应该混入对颜色的喜好；尊重绿链劳动成果Chenyijia001（留言） 2015年5月13日 (三) 15:11 (UTC)回复

如果建立条目之后还得要把绿色链接修改成中文链接，那么，加上绿色链接是多此一举。而且，绿色链接是针对条目的内文，对于以中文为主要阅读条件与选择的读者来说，帮助不大。想要读其他文字的，有更方便的方式取得资讯。-cobrachen（留言） 2015年5月15日 (五) 12:44 (UTC)回复

在条目建立之后，对于条目读者而言绿色连结会自动变成一般的蓝连结，且过了一段时间之后，机器人还会自动将绿色连结的编码修正成一般连结，所以对于编辑者来说也不需做任何修改，因此‘还得要把绿色链接修改成中文链接’这问题实际上是不存在的。或许对于只阅读中文的读者而言有无绿色连结的差异性不高，但是至少对很多编辑者而言这对于查证译名是否正确、对于有多种译名版本的事物之重定向的维护，却有非常大的帮助，可说是种非常强大的编务维护工具。--泅水大象™ 讦谯☎ 2015年5月16日 (六) 16:25 (UTC)回复
同泅水大象意见。使用红链且无附上外语原词，往往增加后续翻译者或欲创建条目者的困惑，别忘了各地中文用语并不相同。透过绿链的使用，原先条目中的绿链若有人以不同中文名称建立条目，机器人也会自动修改内部链接（虽然也不是没改错过，这只好手动修正）。--春日クリス 敲敲 2015年5月20日 (三) 07:38 (UTC)回复

关于“爱丽丝·李道尔”条目的一些问题 编辑

最新留言：8年前1条留言1人参与讨论

我是该条目的创建者，近期发现该条目被机器人进行了错误的自动编辑，我执行了回退操作。然而操作完成后发现虽然条目的代码正确，但是实际显示的页面并没有得到更新，仍然是错误的内部链接，而非跨语言链接。希望管理员协助更正。（机器人的错误操作如下：机器人自动添加的“镜中奇遇”是卡罗尔的文学作品，而非原文所指歌剧，“西汉姆”为足球俱乐部，而非原文所指地区。）Ozzy T（留言） 2016年2月9日 (二) 09:29 (UTC)回复

link-en模板手机版去除语言连结 编辑

最新留言：7年前12条留言5人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2016年5月27日 (五) 08:42 (UTC)。回复

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行人：Liaon98 我是废物 2016年5月1日 (日) 18:27 (UTC)。回复

{{link-en}}在手机版检视中，语言有连结，不符合通常不应该被连结的对象第二点。但是我不会去除，其他语言也有相同问题。--tang891228（留言） 2016年5月1日 (日) 13:55 (UTC)回复

移动页面版就是{{ilh}}的raw数据真身，桌面页面版是通过脚本将其再处理不同的显示模式，移动页面版因为没有相应的移动页面脚本控制界面，所以只能保持raw数据（一个本地红链，一个外语外源链）的样式。没办法处理。——路过围观的Sakamotosan 2016年5月2日 (一) 09:51 (UTC)回复
他指的是形如：英语 --达师 - 334 - 554 2016年5月8日 (日) 15:08 (UTC)回复
那需不需要改造下ilh，调整一部分主要语言不显示该语言的链接？——路过围观的Sakamotosan 2016年5月9日 (一) 00:51 (UTC)回复
应该是需要这样的。 --达师 - 334 - 554 2016年5月9日 (一) 10:24 (UTC)回复
先按照全部语言都拿掉链接来处理，special:diff/40122947。 --达师 - 334 - 554 2016年5月16日 (一) 02:58 (UTC)回复
进一步的想法是使用{{link-en}}等若干特定模板不链接，用wiki语法就可以解决，只是哪些语言需要链接的问题。 --达师 - 334 - 554 2016年5月16日 (一) 03:03 (UTC)回复
不要在各语言模板做，因为有些不是在lang-XX上调用，例如tls，应该在ilh上用Lua或#switch判断语言代码是不是主要语言，是的话就不使用链接，不是反之。——路过围观的Sakamotosan 2016年5月16日 (一) 03:49 (UTC)回复
将联合国6个工作语言视为主要语言吧，其他待补充。——路过围观的Sakamotosan 2016年5月16日 (一) 03:51 (UTC)回复
实际上我倾向于默认不链接。因为这种链接大概率是重复的。 --达师 - 334 - 554 2016年5月17日 (二) 02:39 (UTC)回复

编辑请求 编辑

最新留言：7年前2条留言2人参与讨论

  请求已处理--1=0，欢迎维基人加QQ群170258339 2017年1月17日 (二) 03:44 (UTC)回复

<includeonly>{{#invoke:ilh|main}}</includeonly><noinclude>{{模板文档}}</noinclude>

更换为Lua版的实现，已经完成测试。--路过围观的Sakamotosan 2017年1月17日 (二) 03:27 (UTC)回复

导航模板无法正常显示 编辑

最新留言：7年前12条留言6人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2017年1月23日 (一) 00:42 (UTC)。回复

https://zh.wikipedia.org/w/index.php?title=%E7%BE%8E%E8%8F%B2%E9%97%9C%E4%BF%82&oldid=42240304 https://zh.wikipedia.org/w/index.php?title=%E7%BE%8E%E8%8F%B2%E9%97%9C%E4%BF%82&diff=next&oldid=42240304 --Panintelize(talk-contrib)药理学 专题经济学专题 2016年12月28日 (三) 09:12 (UTC)回复

模板爆炸了，嗯。技术术语的话，就是“预扩展”超过解释器限制了。——路过围观的Sakamotosan 2016年12月28日 (三) 09:26 (UTC)回复
感兴趣的话，可以看看Draft:Wikipedia:模板限制（没翻译完，Wikipedia:模板限制（粗翻译，如果觉得语文水平被我拖低了，可以看en原文）。——路过围观的Sakamotosan 2016年12月28日 (三) 09:31 (UTC)回复
部分模板改用Module是否就可以了？--百無一用是書生 (☎) 2016年12月28日 (三) 09:34 (UTC)回复
Navbox早就是Lua了，现在Navbox经常是“预扩展”（第一多），“参数字节”（第二多）超标。——路过围观的Sakamotosan 2016年12月28日 (三) 09:42 (UTC)回复
或者连ilh都用Lua代替？不过模板限制说过，多次展开带参数的模板的“预扩展”会被分开计算，除非不带参数。其实尽快清掉一部分ilh或者可以缓解。——路过围观的Sakamotosan 2016年12月29日 (四) 08:18 (UTC)回复
……ilh居然还不是lua？ --达师 - 345 - 574 2017年1月2日 (一) 13:20 (UTC)回复
不是，不过tsl的展开成本明显比ilh的core大。——路过围观的Sakamotosan 2017年1月3日 (二) 00:39 (UTC)回复
@Liangent、Shizhao、hat600：，Lua版的已经实现了，在沙盒测试，实现应该是一致的，在oldid=42650933模拟美菲关系并且将分语言版（也就是link-en）直接调用Lua的话，效果更佳。请L大检查一下。另外这个Lua版有以下改善或可能性未知情况：1.对MainPage的判断需要熟悉mw.message的帮手确认下；2.exists是一个昂贵函数，美菲关系的测试已经有200+的昂贵函数调用次数了（上限为500），求更便宜的实现。——路过围观的Sakamotosan 2017年1月3日 (二) 07:59 (UTC)回复
@Cwek：高开销，什么昂贵。--Liuxinyu970226（留言） 2017年1月12日 (四) 14:11 (UTC)回复
Expensive adj. 昂贵的；花钱的。（听得到就好（笑））。——路过围观的Sakamotosan 2017年1月13日 (五) 00:32 (UTC)回复

{{Internal link helper}}不支持识别繁简转换后的标题？ 编辑

最新留言：6年前4条留言2人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2017年5月30日 (二) 08:42 (UTC)。回复

我已经建立了简体中文名称的后藤次利（后藤次利）[同时系统自动建立繁体的后藤次利（後藤次利）]，但是对于{{link-ja|後藤次利|後藤次利}}，悬浮tooltip仍然显示“条目“后藤次利”尚未创建，可参考日语维基百科的对应页面：后藤次利。”。

对比：后藤次利和后藤次利 -小烈 (找我?) 2017年5月19日 (五) 22:05 (UTC)回复

template:ilh的颜色 编辑

最新留言：6年前16条留言7人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2017年11月20日 (一) 00:42 (UTC)。回复

在哈维·温斯坦条目中有{{le|哈维·韦恩斯坦性骚扰事件|Harvey Weinstein sexual misconduct allegations|性騷擾和性侵犯}}，现在哈维·韦恩斯坦性骚扰事件已经建立，为什么链接没有变成正常的深蓝色，而是一个从没见过的刺眼的浅蓝色？https://i.imgur.com/nV66lmN.png --小烈 (找我?) 2017年10月16日 (一) 04:57 (UTC)回复

一番研究后发现好像是因为MediaWiki:Gadget-internalLinkHelper-altcolor.css导致的。 根据 原始讨论，这个改变应该是只对开启了对应小工具的编辑者有效才对吧，怎么加成全局的了？@YFdyh000： -小烈 (找我?) 2017年10月16日 (一) 15:28 (UTC)回复

奇怪，我没收到at。@Shinjiman：我的本意是新建一个小工具以方便选用，并非加入全局，此效果仅利于编者。--YFdyh000（留言） 2017年10月20日 (五) 23:10 (UTC)回复
结果是直接加入了小工具“跨语言链接：游标悬浮时显示Tooltip”而非新建一个。--A2093064#Talk 2017年10月21日 (六) 00:12 (UTC)回复
有关过往的讨论请参阅Wikipedia:互助客栈/技术/存档/2017年5月#小工具创建请求：“跨语言链接：高亮条目已存在”。 Shinjiman ⇔ ♨ 2017年10月21日 (六) 02:43 (UTC)回复
@Shinjiman：所以为什么加入全局小工具了，过往讨论没提过--YFdyh000（留言） 2017年10月22日 (日) 04:32 (UTC)回复
先前曾经看见过先前有关的讨论，但有关的讨论已经存档了；因此先尝试作个修改，再看看有什么回馈，当时的修改特地录下编辑摘要，连回先前一次的讨论。（到这个讨论时才看见有用户为这次的修改回馈了…… -_-||） Shinjiman ⇔ ♨ 2017年10月22日 (日) 13:27 (UTC)回复
如果觉得所作的修改不大方便的话，或者可以拆分作另一个工具？还是维持这样的模式会较佳？这个问题可以讨论一下。 Shinjiman ⇔ ♨ 2017年10月22日 (日) 13:32 (UTC)回复
现在模式的问题是对于读者不便，整个页面花花绿绿的很不好看。倒不是功能上有什么问题。-小烈 (找我?) 2017年10月22日 (日) 23:29 (UTC)回复
@Shinjiman：目前这个模式没什么意义，普通编者看不出用意，也影响tsl本身设计。设它是避免用工具转换后错链中文中同名条目，不加{{tsl}}的用户不需要了解--YFdyh000（留言） 2017年10月31日 (二) 14:32 (UTC)回复
如果匿名用户一个颜色，已注册用户花花绿绿呢？幻想乡的反逆者（留言） 2017年11月1日 (三) 04:10 (UTC)回复
User:幻想乡的反逆者指已注册用户默认开启？没什么必要，非翻译（转换）、维护的大多数用户不必了解此情况。--YFdyh000（留言） 2017年11月9日 (四) 11:32 (UTC)回复
功能本意是找出新增内容时莫名新增的“分类:有蓝链却未移除内部链接助手模板的页面”。--YFdyh000（留言） 2017年11月9日 (四) 21:17 (UTC)回复

简化ilh的内部逻辑 编辑

最新留言：5年前9条留言3人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术/存档/2019年4月。

现有的 {{ilh}} 必须使用一百多个语言的一百多个子模板调用，在间接使用该模板的一些情况下会造成不必要的模板嵌套计数。这些子模板的目的主要在于记录对应的语言中文名并使用 {{lan}} 获取正确的内容。以英文的 ilh 子模板为例： 

{{Internal_link_helper |lang={{lan|zh-hant=英語|zh-hans=英语}} |lang-code=en |1={{{1|{{{2|}}}}}} |2={{{2|}}} |d={{{d|{{{3|}}}}}} |nocat={{{nocat|}}}}}

这样一算，一个 tsl 的通用情况会造成三个模板引用。可这样做是完全不必要的：

  • Lua 的词典系统可以在一个模块页面中实现对于所有语言名称的查询
  • Lua 本身有引入（require）其他模块代码的功能，不需要再跳出到这些模块对应的模板层面处理。

所以说现在需要做的事是：

抄送 User:WhitePhosphorus。（另外，我们真的需要 ilh 用 lan 吗？{{NoteTA}} 能实现就说明 Lua 产出的东西是会被繁简处理的吧？直接用 模块:WikitextLC 就好吧？） ——Artoria2e5编 讨论要完整，回复请用ping。 2019年3月28日 (四) 03:04 (UTC)回复

为何不用#language这个魔术字呢？
  • {{#language:en|zh}}：英语
  • {{#language:en|zh-hans}}：英语
  • {{#language:en|zh-hant}}：英文
  • {{#language:en|zh-cn}}：英语
  • {{#language:en|zh-hk}}：英文
  • {{#language:en|zh-tw}}：英文
  • {{#language:en}}：English

--百無一用是書生 (☎) 2019年3月28日 (四) 08:06 (UTC)回复

根本不一样的东西吧。但是简体和繁体显示的内容就不一样了。——路过围观的Sakamotosan | 避免做作，免敬 2019年3月28日 (四) 08:42 (UTC)回复
如果转换有效的话，可以做一个临时实现，lang为不转换，让系统渲染时转换，在沙盒试试。——路过围观的Sakamotosan | 避免做作，免敬 2019年3月28日 (四) 08:44 (UTC)回复
frame:callParserFunction('#language', langcode, frame:callParserFunction('int:Conversionname'))直接使用外部CIDR数据，是个简单的好主意欸。不过这样做会加深对于魔术字（和frame）的依赖，虽然只call两下我倒是没什么意见。纯粹用LC也挺好。——Artoria2e5编 讨论要完整，回复请用ping。 2019年4月2日 (二) 06:09 (UTC)回复
或者根本不需要lan这个功能？有些语言的相应部分没有使用lan，只有其中一种用字模式的“XX语”，但渲染之后还是会根据渲染的语言模式转写为相应的用字。——路过围观的Sakamotosan | 避免做作，免敬 2019年4月3日 (三) 03:47 (UTC)回复
不对，这是跟随界面语言设置的。——路过围观的Sakamotosan | 避免做作，免敬 2019年4月3日 (三) 03:51 (UTC)回复
那为什么简体的用字“XX语”和繁体的用字“XX文”有没区别？因为像ilh/en的用字分别是“XX语”和“XX語”。——路过围观的Sakamotosan | 避免做作，免敬 2019年4月3日 (三) 03:57 (UTC)回复
从CLDR的角度而言，没区别。就是不同地区的CLDR参与者翻译的不同而已（之前版本的CLDR，简体也是xx文，后来的版本被参与者统一改成了xx语而已）--百無一用是書生 (☎) 2019年4月11日 (四) 03:17 (UTC)回复

直接从维基数据中获取信息以避免翻译区别 编辑

最新留言：4年前1条留言1人参与讨论

有没有可能直接在维基数据中检查一个外文条目是否已经存在中文页面，而不是纯粹与模板中的参数对应，以避免后来者创建页面时使用了一个不同的译名。 例如：某页面中有一个指向英文维基的“Dead Hand”词条被译为“死手系统”，然而查看时发现中文维基上已经存在对应的页面，标题是“死亡之手”。Lzma17（留言） 2019年5月31日 (五) 15:47 (UTC)回复


关于 参数设置>小工具 中的显示效果 编辑

最新留言：4年前2条留言1人参与讨论

于2019/10/21查阅设定时，看到已经更新如以下的选项，明显已经跟模板说明有所出入。 

	跨语言链接：只显示红链
	跨语言链接：在Tooltip中显示原文链接
	跨语言链接：显示红链和未链接原文
	跨语言链接：直接指向原文
	跨语言链接：指向原文和语言名后缀
	跨语言链接：鼠标点击时显示Tooltip
	跨语言链接：光标悬浮时显示Tooltip
	跨语言链接：光标悬浮时显示Tooltip（對於已存在頁面的情況下高亮表示）

—以上未签名的留言由Ntudreamer（对话｜贡献）于2019年10月20日 (日) 16:33加入。

我看看更新一下？--Lopullinen（留言） 2019年10月26日 (六) 04:23 (UTC)回复
@Ntudreamer：看看现在有没有问题？--Lopullinen（留言） 2019年10月26日 (六) 08:31 (UTC)回复

ilh系模板新增第四参数——外文链接的显示文字？ 编辑

最新留言：4年前12条留言4人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2020年1月16日 (四) 08:14 (UTC)。回复


前段时间重写了Internal link helper的说明文档，其中包括梳理了不同小工具的显示效果。当时已经感觉模板只考虑电脑端（编者端），对移动版用户（读者端）并不友好。最近翻译了一些条目，觉得还是有必要反馈这个问题。

比如近期翻译的一篇条目，提到了《J·哈巴卡克·杰夫森的供述》（J. Habakuk Jephson's Statement）中的虚构船只玛丽·塞莱斯特号（Mary Celeste）。这里需要使用管道链接：[[J·哈巴卡克·杰夫森的供述|玛丽·塞莱斯特号]]。

如果用跨语言链接模板，即{{le|J·哈巴卡克·杰夫森的供述|J. Habakuk Jephson's Statement|玛丽·塞莱斯特号}}会显示：

玛丽·塞莱斯特号（英语：J. Habakuk Jephson's Statement）

对绝大多数桌面端用户而言，这是个普通的绿色链接，没有什么问题。

但行动界面和Wikiwand等外部阅读器，因无法加载绿链小工具，就会显示如下效果：

玛丽·塞莱斯特号（英语：J. Habakuk Jephson's Statement）

可以看到，电脑版弹窗中的外链，现在直接写到了正文中。尽管有跨语言链接兜底，但括号中注释着不相干的文字，总感觉很违和。

而对于使用小工具“显示红链和未链接原文”的用户，因为外文不带链接，就真的不知所云了：

玛丽·塞莱斯特号（英语：J. Habakuk Jephson's Statement）

虽然这个小工具使用率低，而且也是用户自选的；但作为社群正式启用的功能，而不是“非官方”性质的WP:JS，我觉得还是有必要全面考虑。此外，使用官方App的Dark配色时，跨语言链接和正文都显示白色文字，粗看也是似乎没有链接的效果。

所以如果模板加入第四参数，即

{{link-en|<中文维基百科页面名>|<外文维基百科对应页面名>|<中文连结实际显示文字>|<外文连结实际显示文字>}}

例如——

输入：{{link-en|J·哈巴卡克·杰夫森的供述|J. Habakuk Jephson's Statement|玛丽·塞莱斯特号|Mary Celeste}}
移动端显示：玛丽·塞莱斯特号（英语：Mary Celeste）

这样既能惠及行动版读者，对编者而言也只是模板末尾加了一个参数，影响应该不大。建议社群考虑一下这个问题。--Lopullinen 2020年1月4日 (六) 14:48 (UTC)回复

三个参数时都有编者会写成议员（英语：Member of Parliament (United Kingdom)）了，四个参数只怕会令人更混乱。-游蛇脱壳/克劳棣 2020年1月4日 (六) 17:08 (UTC)回复
三个参数就是外文和中文不对称，所以才不好记。四个参数是中外中外，先实体链接后显示文字，1、2参数配套，3、4参数配套，我觉得反而有助记忆。另外这个讨论正是希望照顾一下读者，而不是单纯站在编者角度考虑。—Lopullinen 2020年1月5日 (日) 00:35 (UTC)回复
{{tsl}}把英文显示参数插到中文显示参数前，形成外中外中的顺序，和{{ilh}}只是先外后中的区别，很好记忆：
{{Tsl|en|<外文维基百科页面名>|<中文维基百科对应页面名>|<外文连结实际显示文字，新参数>|<中文连结实际显示文字>}}
（只输入三个参数时还是使用原来的模式兼容，并期待编者逐步补回英文显示）—Lopullinen 2020年1月5日 (日) 01:28 (UTC)回复
如果移动端有关的话，不应该是调整移动端的脚本调用引用？——路过围观的Sakamotosan | 避免做作，免敬 2020年1月5日 (日) 02:58 (UTC)回复
另外你所说的差异，主要是中外两区的链接连接不对应有关吧（外语是一个条目的章节，而中文想将其作为一个独立条目看待，才会出现中外不对应，本来就是不对应的。）——路过围观的Sakamotosan | 避免做作，免敬 2020年1月5日 (日) 03:01 (UTC)回复
现在情况是，模版在正文生成括号标注外文链接，小工具再将之转化为绿链弹窗。所以不能调用小工具的场合，包括行动网页、App、未使用JS的用户，都会显示这种多少有“误导性”的标注。毕竟那里写的不是“玛丽·塞莱斯特号（可见英文版条目J. Habakuk Jephson's Statement）”。
对应是中文条目名对英文条目名，中文显示文字对英文显示文字。现在“玛丽·塞莱斯特号（英文：J. Habakuk Jephson's Statement）”，看起来就是中文显示文字对英文条目名，当然是很奇怪的。所以才提议加入一个参数，使得显示“玛丽·塞莱斯特号（英文：Mary Celeste）”。
能来互助客栈的都是活跃编者，相信一般不用行动端界面。常用行动端的读者，想必也不知道有这个地方反馈意见。各位如果试着在电脑端，把绿链跨语言小工具取掉，模仿行动端效果一个星期，就能发现的奇怪之处了。—Lopullinen 2020年1月5日 (日) 03:43 (UTC)回复
或者需要一些迂回的方法，例如不要直接连接到“玛丽·塞莱斯特号”，而是通过引述带连接的“J·哈巴卡克·杰夫森的供述”来提及“玛丽·塞莱斯特号”。——路过围观的Sakamotosan | 避免做作，免敬 2020年1月5日 (日) 11:52 (UTC)回复
@Cwek：那“电子世界争霸战（英语：Tron (video game)）”这种情况就无法避免了吧？诚然WP:MOSIW指出，也可以使用“ 电子世界争霸战（Tron）”手工标记外语原文，但其他编辑往往又会将之换为ilh，此时又是否可以“行动版显示不规范”为理由回退？所以直接加上一个参数，实体名和显示名都能对应，也完全不影响以前的用法，有何不好？—Lopullinen 2020年1月6日 (一) 04:25 (UTC)回复
我认为应该是优先考虑修正移动版的脚本引用问题会更好。可以理解为移动版现在的显示才是模板的wikicode解析输出，再结合脚本来调整显示的模式，如果不考虑移动版的，基本上没有所提及的问题（当然当时调整时就没有考虑过移动版的问题）。加多的参数在网页版的话可能就是多余参数。而且现阶段来看，移动版就已经有额外引用参数的先例。（MediaWiki:Mobile.js）——路过围观的Sakamotosan | 避免做作，免敬 2020年1月6日 (一) 05:45 (UTC)回复
要么就是wikicode输出只带红链，后面的括号预设用display: none;隐藏。或者把描述文字改成没有歧义的“可见英文版条目Tron (video game)”，和弹窗文字含义一致。我是想的第四参数大部分时间都是可以省略，而且三四参数放到一起，中文显示文字和英文显示文字可以对译，即便是放源代码里，能供编者参照也不是坏事。—Lopullinen 2020年1月6日 (一) 07:31 (UTC)回复

关于{{Link-xx}}和{{tsl}}模板的颜色 编辑

最新留言：4年前23条留言15人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2020年4月21日 (二) 16:14 (UTC)。回复


大家都知道，现在中文维基习惯以“绿字链接”的特色方式处理中文版不存在的条目。这个模板已经用了很多年，算是中文版的一个特色。不过虽然美观，但我近年来越发觉得这种绿色有时候稀释了原本“红字链接”提供的警示作用。见WP:红字连结：“（红字链接）是为了提醒我们维基百科还没有完成”。只是稍加阐述自己的观点，想了解一下社群看法，并不指望能更改绿连颜色。--Y814756748--留言 2020年4月2日 (四) 02:14 (UTC)回复

(～)补充：我的看法是应该保留这个模板的tooltip，但是颜色依然是红色。--Y814756748--留言 2020年4月2日 (四) 02:19 (UTC)回复
用小工具，这系列的“在Tooltip中显示原文链接”就可以了。——路过围观的Sakamotosan | 避免做作，免敬 2020年4月2日 (四) 02:22 (UTC)回复
我的看法是保留“绿字链接”中的绿字。红字和绿字都是中文维基没有创建的条目，绿字条目至少还有对应的外文链接，要创建条目可能比较简单（至少可以试着翻译外文的内容），红字条目要创建的难度就比较高了。--Wolfch (留言) 2020年4月2日 (四) 04:52 (UTC)回复
该两个模板出现了问题吗 ? 没有就没坏别修。创建条目这回事从来是看人意愿，不会因为连结是红是绿而改变。-- 约翰同志－条目裱糊匠（留言） 2020年4月2日 (四) 08:27 (UTC)回复
澄清一下。并没有在讨论这个模板的存废，只是对于现有的显示颜色有一些意见。至于“不会因为链接是红是绿而改变”，我个人同意你的说法，但我认为这或许只是成熟维基编者的想法。我最初阅读维基百科时，就是因为看不过模板里一排排的红字才注册用户来“消红”。--Y814756748--留言 2020年4月2日 (四) 08:44 (UTC)回复
能够用设定解决的问题就不是问题。以我理解，绿连有其用处，就是提供替代，其绿字展示也让读者知道有这回事。它是重读者多于创建条目的人，对读者而言，条目有一大堆绿连，可能不是问题，至少它可以连向其他条目；相反读者一见到条目有一大堆红连，就真是有问题了，无论有一些其实是绿连，相信读者早就按上一页了，因为这看上来是孤儿条目。当然对一些创建条目的人而言，红绿连是等号，是没有完成的。归根究底，绿连是服务读者，而不是服务创建条目的人。-- 约翰同志－条目裱糊匠（留言） 2020年4月2日 (四) 09:24 (UTC)回复
绿字可以更直观地提醒用户有其他语言版本，若一律改为红字，将难以辨认，需要移到文字上才能知道。--【和平至上】避免不必要外出·同心抗疫！💬 2020年4月2日 (四) 14:35 (UTC)回复
绿色连结和红色连结同一颜色的话会造成编辑困难，读者也将不知道连结到底有没有内容，移动鼠标到上面才能辨识，非常麻烦，倾向反对。 -- Suzuha Amane THE IDOLM@STER（留言） 2020年4月5日 (日) 18:24 (UTC)回复
(－)反对：我们写百科是让读者去读的，要有读者意识，绿链显然会让读者知道有外文条目的存在，方便读者查询，故本人反对这一提案。# SteepPeak™ 2020年4月6日 (一) 00:17 (UTC)回复
没错。维基百科唯一的作用是让读者去读。虽然不能认为读者一定读得懂外文条目，但对读得懂的读者来说，绿链也是比红链有用的。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2020年4月7日 (二) 02:33 (UTC)回复
(－)反对，理由同上。--
 
 2020年4月6日 (一) 09:29 (UTC)

上面已经澄清过我并没有想要提议废除跨语言连接模板，以上诸位除了误会我想要废除绿连的，认为绿连颜色优于使用红连（理由如便于辨认等），我是可以理解的。我的立场没有很坚定，因为我自己主编的条目也会一直使用绿连。不过我没有想到各位的态度如此统一且坚决——况且我还是阅读过Template talk:Internal link helper关于红绿之争的一些讨论串后，才决定到这里提我自己意见的。

我只是怀疑现在有编者要求GA、FA必须统一用跨语言模板替代红连，这样的想法做法是社群的统一看法吗？以上诸位的表态会让我觉得社群普遍支持绿连、反对红连甚至废除红连，可以这样理解吧？（题外话：我发起了这次讨论；我最近更换了用户名。）--HMGiovanniV--留言 2020年4月11日 (六) 05:51 (UTC)回复

有关跨语言链接悬浮窗的问题 编辑

最新留言：3年前11条留言4人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/求助。执行者：Jimmy-bot（留言） 2020年5月18日 (一) 08:14 (UTC)。回复

将鼠标移动到{{ilh}}和{{tsl}}生成的链接上时，悬浮窗在鼠标从链接上移走后马上就消失了，很难点中悬浮窗内的跨语言链接，请问如何设置悬浮窗的显示时长？谢谢--Tim Wu（留言） 2020年5月5日 (二) 02:40 (UTC)回复

我使用的是：“跨语言链接：在Tooltip中显示原文链接 ”。看了系统脚本，好像是硬编码为500毫秒。无法设置，不过这应用的这个配置，鼠标很容易从链接移动到悬浮窗上。——路过围观的Sakamotosan | 避免做作，免敬 2020年5月5日 (二) 09:38 (UTC)回复
@Cwek：感谢，我在选择“在Tooltip中显示原文链接”后似乎就可以了；但只选中这个选项，链接颜色不会变绿，再选中“鼠标点击时显示Tooltip”就没问题了。不过很奇怪，我单独选中“鼠标点击时显示Tooltip”后点击绿链并不会又出来弹框，直接跳至新建页面去了…--Tim Wu（留言） 2020年5月5日 (二) 09:56 (UTC)回复
不过这个选项（在Tooltip中显示原文链接）在页面已存在时不会高亮显示诶。。--Tim Wu（留言） 2020年5月5日 (二) 09:59 (UTC)回复
如果你愿意了解细节，你可以查找关于“跨维基链接”与这些模板的关系信息，（其中一个比较重要的是Wikipedia:投票/跨语言链接的处理方式）。简单来说，“绿链”只是其中一种表现样式，例如我使用的配置就不会出现“绿链”的表现。另外，小工具的“跨语言链接”系列选项，选一个就好，选多个我也不知道会发生什么bug来。（摊手）——路过围观的Sakamotosan | 避免做作，免敬 2020年5月5日 (二) 10:03 (UTC)回复
刚刚重新阅读了模板说明页，发现马上消失的bug应该是我选了多个选项才会有的，现在已经正常了，感谢您的提醒。不过“跨语言链接：鼠标点击时显示Tooltip”这个选项在我这里仍无法正常使用……--Tim Wu（留言） 2020年5月5日 (二) 10:31 (UTC)回复
测试过，“跨语言链接：鼠标点击时显示Tooltip”的确不符合预期运作。可能是欠缺维护？——路过围观的Sakamotosan | 避免做作，免敬 2020年5月7日 (四) 09:35 (UTC)回复
己修复到能够使用。--Xiplus#Talk 2020年5月7日 (四) 11:01 (UTC)回复
@Xiplus：感谢修复。另，可否在参数设置那里，将跨维基链接那几个选项改为只能选择一个，或者添加一个不要多选的提示？--Tim Wu（留言） 2020年5月7日 (四) 11:07 (UTC)回复
 完成。--Xiplus#Talk 2020年5月8日 (五) 00:41 (UTC)回复

隐藏分类和追踪分类 编辑

最新留言：3年前30条留言5人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2021年2月2日 (二) 00:14 (UTC)。回复

现时Category:有蓝链却未移除内部链接助手模板的页面有三万多个页面，而且每天增加多个。

该分类声称不需要进行细分，但事实上要在当中找到所有分散的“Template:”页面并不容易，在维护上的必要性是存在的。

我对此建立了Category:有蓝链却未移除内部链接助手模板的导航框这个隐藏分类和追踪分类，但发现没有任何Template命名空间的页面被追踪至该分类。

问过相关人士，得出两回事，机器人可解决这回事和建立“隐藏分类和追踪分类”需要修改对应模板如{{Internal link helper}}。

我想问的是，我建立的分类是否可行 ? 机器人和修改对应模板能否令蓝链Template命名空间的页面追踪至我建立的分类 ? 如要修改，是否要大改{{Internal link helper}}相关的模板，甚至{{Internal link helper}}的源代码 ?

谢谢。-- 约翰同志－条目裱糊匠（留言） 2021年1月15日 (五) 12:05 (UTC)回复

主要问题是无法区分分类所在的位置吧。这个分类呈现在ilh的模板里，而ilh模板又嵌入在条目或页面里，所以这个分类最终呈现在页面的分类上。可以研究下lua关于父页面的判断。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2021年1月16日 (六) 02:52 (UTC)回复
初测了一下，好像不行。Module:沙盒/Cwek/test、oldid=63740869（模板调用lua）、oldid=63740891（页面调用模板）。frame:getParent() 只能获得通过invoke调用lua脚本的那一层页面（也就是模板页），不能再获得这个模板页被哪个页面调用。而ilh模板调用ilh的lua模块，lua模块最多只知道是ilh模板调用它，但不知道谁调用了ilh模板。况且还有tsl调用ilh。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2021年1月16日 (六) 03:19 (UTC)回复
我建议Category:有蓝链却未移除内部链接助手模板的导航框优先处理模板空间的页面，这样就能清掉用在模板里面的ilh或tsl，然后再重新读取分类来获得新的清理页面。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2021年1月16日 (六) 03:20 (UTC)回复
换了另一种方法，Module:沙盒/Cwek/test2、oldid=63741123（第一层模板，如ilh）、oldid=63741192（第二层模板）、oldid=63741195（调用层二模板），可行。不过Category:有蓝链却未移除内部链接助手模板的导航框需要告知相应处理机器人操作用户也要处理。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2021年1月16日 (六) 03:34 (UTC)回复
@Cewbot、Comrade John：，是否感兴趣？——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2021年1月16日 (六) 03:36 (UTC)回复
不过模板和页面都会有对应的跟踪分类，好像脱裤子放屁……——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2021年1月16日 (六) 03:38 (UTC)回复

@cwek：YFdyh000之前用某种方法弄了这个有蓝链却未移除内部链接助手模板的导航框的列表，相信现在已多于813个。只要我所建立的分类能够追踪任何有蓝链却未移除内部链接助手模板的导航框，我就有兴趣。-- 约翰同志－条目裱糊匠（留言） 2021年1月16日 (六) 07:42 (UTC)回复

你应该@YFdyh000：啊。可能是判断“Category:有蓝链却未移除内部链接助手模板的页面”里属于模板的页面再判断引用的模板里面有没Navbox？——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2021年1月16日 (六) 08:08 (UTC)回复
正如该列表，Category:有蓝链却未移除内部链接助手模板的导航框中的Template命名空间的页面不只Navbox，还有Military navigation、Camapaign等，只有Navbox是不够的。话说该可行方法，没有机器人帮助也可以 ?-- 约翰同志－条目裱糊匠（留言） 2021年1月16日 (六) 08:16 (UTC)回复
还得要靠机械人来收集和处理嘛。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2021年1月16日 (六) 08:29 (UTC)回复

@Kanashimi：Cwek所测试的那个可行的Module，就是阁下所说的“机器人也能产生一份这样的报告”吗 ?--约翰同志－条目裱糊匠（留言） 2021年1月16日 (六) 10:05 (UTC)回复

YFdyh000的比较像。But 或许只要使用者:Cewbot/需要修正的跨语言链接先显示模板就能达到要求了？ --Kanashimi（留言） 2021年1月16日 (六) 10:33 (UTC)回复
使用者:Cewbot/需要修正的跨语言链接，要等Bot更新，不及Category:有蓝链却未移除内部链接助手模板的页面能够即时追踪，只要一个Template命名空间页面出现第一则已有蓝链的绿链编辑，该分类即时+1页面。我希望我所建立的分类能够和Category:有蓝链却未移除内部链接助手模板的页面看齐。-- 约翰同志－条目裱糊匠（留言） 2021年1月16日 (六) 10:46 (UTC)回复
我不认为该维护分类需要保证更新的实时性，有人想维护时更新即可。机器人也可以定期频繁更新。如果只需要实时+单列模板，应该可以改Module:Ilh使分类索引使用含名字空间的完整页面名，然后点目录索引的Te就能找到分类内模板名单；其实分类有时并不实时，看服务器压力。如果只需要列出是导航框的模板，按我说过的方法，判断一下包含导航框应该不难（但可能有漏报）。--YFdyh000（留言） 2021年1月16日 (六) 18:08 (UTC)回复
在Category:有蓝链却未移除内部链接助手模板的页面点目录索引的Te就能找到分类内模板名单，未尝是一个不错的选择。但能令Category:有蓝链却未移除内部链接助手模板的导航框能够追踪相关页面，还是首选。照这样去看，无论A或B，都要提出编辑请求吧，始终要改动全保护的模板。-- 约翰同志－条目裱糊匠（留言） 2021年1月16日 (六) 18:43 (UTC)回复
你说的首选目前有不小的技术难度，同时会增加服务器计算压力。我也没有看到其他人有此归类维护的需求。所以最佳方案是不改动模板、不增设你所说的分类，用机器人工具统计和列出，每次一分钟就解决了。--YFdyh000（留言） 2021年1月16日 (六) 19:54 (UTC)回复
亦即利用Cewbot吧 ?-- 约翰同志－条目裱糊匠（留言） 2021年1月16日 (六) 20:03 (UTC)回复
1分钟指这里提过的列表生成方法。我刚看了一下，User:Cewbot/需要修正的跨语言链接里Ctrl+F查找"Temp"就足够了啊，基本聚在一起，信息和链接也很全，还会自动更新。--YFdyh000（留言） 2021年1月17日 (日) 03:05 (UTC)回复

@Kanashimi： 用户:Cewbot/需要修正的跨语言链接中，“List 1836/22044 (8%) of all problematic pages”可以提高它列出的百分比吗 ? 先显示模板可行吗 ? 而该列表可以手动更新吗 ? 可不可以增加更新按钮吗 ?-- 约翰同志－条目裱糊匠（留言） 2021年1月17日 (日) 10:25 (UTC)回复

@Comrade John：我认为清理比这些琐碎细节更重要……你现在有什么技术问题吗，User:YFdyh000/ilh蓝链模板列表不够用？另外，不清理好像也没什么。--YFdyh000（留言） 2021年1月17日 (日) 11:20 (UTC)回复
该表绝对够用，问题是清理后不会自动消失，亦不会自动追踪模板和更新新的蓝链，这是我最在意的。-- 约翰同志－条目裱糊匠（留言） 2021年1月17日 (日) 11:38 (UTC)回复
就清理作业来说，我想User:Cewbot/需要修正的跨语言链接会比较好用。清理完一轮一周后，机器人会产生新的列表。若您有需要，也可以手动跟这边联络，产生新的列表。我想这样多余的工作应该不会太大？ --Kanashimi（留言） 2021年1月17日 (日) 23:08 (UTC)回复
经查所有template皆已显示于User:Cewbot/需要修正的跨语言链接中，全部修正完毕的话应该就没旧的问题了。 --Kanashimi（留言） 2021年1月18日 (一) 03:20 (UTC)回复
@Kanashimi：手动跟这边联络，即在阁下的讨论页提出，抑或在维基百科:机器人/作业请求提出 ?-- 约翰同志－条目裱糊匠（留言） 2021年1月18日 (一) 08:03 (UTC)回复
@Kanashimi：阁下真是肯定找上所有需要修正的跨语言链接 ? Template:锻冶屋原线、Template:小松岛线、Template:幸袋线、Template:室木线、Template:矢部线等使用Translink或TSL的伪蓝链模板并没有被追踪。还有漏网吧 ?-- 约翰同志－条目裱糊匠（留言） 2021年1月18日 (一) 12:32 (UTC)回复
这几个页面应该都能修正，因此的确不该列在需要修正的跨语言链接。至于为何没有处理到，这边正调查中。若有发现其他问题页面，欢迎回报。若有需要产生新的报表，您可以直接在讨论页提出。 --Kanashimi（留言） 2021年1月18日 (一) 22:08 (UTC)回复
@Kanashimi： 服务器缓存问题，空编辑一次后分类中才列出。--YFdyh000（留言） 2021年1月18日 (一) 22:17 (UTC)回复

有没有人能够将“模板:多语言连结”和“模板:多语言连结/doc”nocat掉 ? 它们的伪蓝链是有目的的。-- 约翰同志－条目裱糊匠（留言） 2021年1月22日 (五) 16:34 (UTC)回复

加深ilh绿色，提高对未戴眼镜人士的亲和力 编辑

最新留言：3年前48条留言16人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2021年2月16日 (二) 16:14 (UTC)。回复

已部署：
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

目前的{{ilh}}链接使用的是#00af89颜色，在白色底色下对比度不佳（仅 2.8；见计算器），不符合WCAG 2.0的亲和力标准（4.5），也有违鸡精会的反歧视宣言。考虑到默认几种链接的颜色是：

  • 站内链接，#0645ad，对比度 8.2
  • 跨维基链接，#36b，对比度 5.58

我提议将ilh底色改为稍深的#007a5e（对比度5.32）。此颜色是通过固定CIELAB的Lch版本中的h（色调）参数，降低明度到45，并通过降低饱和度防止溢出 sRGB 空间得到。--Artoria2e5编 讨论要完整，回复请用ping。 2021年1月1日 (五) 11:16 (UTC)回复

管理员请注意：修改时请整处理整个MediaWiki:空间（见搜索结果）以及Template:Internal_link_helper/doc内容。另外好像把眼镜写成眼睛了。未戴眼睛的人士需要的是关于屏幕阅读器的建议，不是关于颜色的建议。——Artoria2e5编 讨论要完整，回复请用ping。 2021年1月1日 (五) 11:33 (UTC)回复

(＋)支持，不过能把标题的错字改过来吗  囧rz……--Tim Wu（留言） 2021年1月1日 (五) 14:33 (UTC)回复
改了。--YFdyh000（留言） 2021年1月1日 (五) 14:51 (UTC)回复
或许可以不用纠结于是否用绿色，我记得以前是红色，用回红色对于反绿连用户来说，或许可以提高Link系模板的使用率。--AT 2021年1月1日 (五) 15:02 (UTC)回复
这样不是会更加混乱吗 ? 文本上连结只有红蓝，但其中有伪装成红连结的绿连结，不利于阅读的同时，编辑上也不利于维护。不要强迫某派用某色连结，反正强迫或说服不了他们，他们也没有意愿去用某色连结。维持现状，讨论改哪种绿色就是了。-- 约翰同志－条目裱糊匠（留言） 2021年1月1日 (五) 20:30 (UTC)回复
双红链接可以考虑放进小工具里让用户自由选择。--安忆Talk 2021年1月2日 (六) 01:40 (UTC)回复
其实不会不利阅读和维护，看上去都一样，只是浮标移过去的时候有没有显示的分别而已。维护方面，目前绿连当有建立页面时会变成浅蓝连，这反而不好找，如果改为变成绿连的话，那就明显多了。—AT 2021年1月2日 (六) 14:04 (UTC)回复
要浮标移过去的时候才知有没有显示的分别就晚了，要的是第一眼看到哪些是绿连才是；绿连当有建立页面时会变成浅蓝连，这反而不好找，这我同意，但不是转成绿色，而是红蓝绿橙再加多一种内连色，例如黄色。-- 约翰同志－条目裱糊匠（留言） 2021年1月2日 (六) 17:01 (UTC)回复
一个小提醒，触屏设备上没有便捷的指针（:hover）…--安忆Talk 2021年1月2日 (六) 18:10 (UTC)回复
我的意思是这种分别本身也不重要，至于浅蓝色换成什么颜色，我也无所谓。--AT 2021年1月4日 (一) 09:54 (UTC)回复
不要再为绿链红链斗了，多少年了还在斗，也不见他们会去写条目消除红绿链，做点实事。消歧义页面已经是黄色了。--owennson（聊天室、奖座柜） 2021年1月3日 (日) 16:22 (UTC)回复
正确来说是橙色。-- 约翰同志－条目裱糊匠（留言） 2021年1月3日 (日) 18:22 (UTC)回复
(＝)中立：摘下眼镜看都差不多，反而是目前这款绿色在一片黑色文字中更显眼。而且我是绝对想不到要考虑“没戴眼镜的人”的感受的。—MintCandy♫ 台州专题2021年新年贺词 2021年1月7日 (四) 05:59 (UTC)回复

各位不考虑其他方面，就“将#00af89改成#007a5e”这一点有反对意见吗？--安忆Talk 2021年1月14日 (四) 01:58 (UTC)回复

就“将#00af89改成#007a5e”这一点进行公示，2021年1月21日 (四) 15:24 (UTC)结束。--安忆Talk 2021年1月14日 (四) 15:24 (UTC)回复
记录：现暂有一位支持#007777、一位支持#229988，至少五位支持提议人给出的数值。--安忆Talk 2021年1月20日 (三) 08:29 (UTC)回复

考虑到个体对颜色的感知是比较主观的，不可能让所有人满意。现提议将认同比较多的#007a5e作为默认色，并在参数设置中提供使用旧色的选项（如同现在的“以旧的黄/绿颜色和设计显示差异”），如日后某位想使用其他颜色，可以自行使用用户CSS调整。不知各位意下如何？--安忆Talk 2021年1月20日 (三) 08:29 (UTC)回复

附知@AT、@Artoria2e5、@Bluedeck、@Comrade John、@EdwardAlexanderCrowley、@MintCandy、@Owennson、@Sanmosa。--安忆Talk 2021年1月20日 (三) 08:31 (UTC)回复
不反对此处理。当然，如果社群认为需要重新考虑用色的话，007a5e和007777我都推荐。SANMOSA SPQR 2021年1月20日 (三) 08:36 (UTC)回复
可以自行使用用户CSS调整，那么能否提供CSS在绿链方面的编码范例 ?-- 约翰同志－条目裱糊匠（留言） 2021年1月20日 (三) 08:39 (UTC)回复
可以考虑提供，对于用户在浏览条目时，只需一行.ilh-page a.new { color: 颜色值 }。--安忆Talk 2021年1月20日 (三) 08:47 (UTC)回复

结合上述新提议重新进行公示，2021年1月27日 (三) 09:17 (UTC)结束。我都没想到改个颜色这种简单的事情会讨论近一个月。[开玩笑的]--安忆Talk 2021年1月20日 (三) 09:15 (UTC)回复

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。
  • (－)强烈反对，提案已经关闭，但我仍要补充一个反对意见：
各颜色对比度对比
颜色 与白色对比度 与维基链接（#0645ad）对比度 与黑色文字对比度
#00af89 2.8 3.04 7.49
#007a5e 5.32 1.6 3.94

显而易见，#007a5e除了与白色的对比度加深以外，与维基链接和黑色文字的对比度都明显降低，尤其是与维基链接，已经低到了1.6。举个例子，在条目日本寺院迭遭泼油事件#受损寺社中，其中的绿链在一片蓝链中根本无法一眼分清。故表示强烈反对并要求撤回更改。通知@AnYiLin、Artoria2e5、AT：——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年1月29日 (五) 00:22 (UTC)回复

参数设置里有使用旧颜色的选项。--安忆Talk 2021年1月29日 (五) 01:26 (UTC)回复
之前的颜色和其他颜色只是在正常人眼中差异明显，在全/半色盲、色弱的眼中会很淡，并且这个群体比例并不低（体验其中一种色彩感知的最简单的方式就是以黑白模式去看，同时增加透明度）。--安忆Talk 2021年1月29日 (五) 01:34 (UTC)回复
也可以使用自定义CSS，我把用到之前颜色的脚本里面写死的颜色都换成了能让用户控制的class类，写入.ilh-page a.new { color: 颜色值 }.ilh-tool { color: 颜色值 }即可。--安忆Talk 2021年1月29日 (五) 01:39 (UTC)回复
安忆考虑色弱确实有意义。我使用https://pilestone.com/pages/color-blindness-simulator-1对本提议开始的部分截图（要用还没有存档背景的旧版页面！）做了一下测试，得到以下结论：
  • 两种红绿色弱/盲都会导致颜色看上去变灰，和可以正常看到的蓝色较容易区分。其中旧色由于又淡又灰，较难阅读。这应该是大部分的情况。
  • 蓝色弱/盲会导致所有颜色都趋于蓝绿相间的颜色（毕竟几种链接颜色都没有红色成分）。其中旧色由于亮度特殊，更容易辨别，但对白色背景的对比度也有降低。
  • 单色视觉中，单蓝视锥细胞视觉的结果类似红绿色弱/盲的情况，而单视杆细胞的情况类似于蓝色弱/盲的情况。
综上，我认为现在的更改可以提高大部分视弱用户的体验，但应该向蓝色弱/盲用户和单视杆细胞无色视觉者推荐原有配色（或另寻配色——棕色、橘色怎么样？）。——Artoria2e5编 讨论要完整，回复请用ping。 2021年2月6日 (六) 13:49 (UTC)回复

BlackShadowG，对比度是基于亮度用来区分前景和背景的区别，和两种颜色是否分的清楚没有直接关系。衡量颜色是否容易分清的单位是颜色差异（ΔE）。请搞清相关概念再来。——Artoria2e5编 讨论要完整，回复请用ping。 2021年2月4日 (四) 06:35 (UTC)回复

那浅蓝连的问题，呢？-- Sunny00217  2021年2月4日 (四) 12:54 (UTC)回复
那么我没搞清楚就不能来吗？我的天。-- 2021年2月5日 (五) 09:25 (UTC)回复
没搞清楚确实就是不能假装自己有“数据”，不然就是搞伪科学。Pseudo Classes，你自己试试把浅蓝链#0645ad配合目前黑色文字的#202122代入计算器。你算好了之后跟我解释一下你是怎么分得清浅蓝链和黑色文字的，然后再跟我说说这个和对比度的关系是什么。——Artoria2e5编 讨论要完整，回复请用ping。 2021年2月6日 (六) 13:26 (UTC)回复

跨语言链接模板的偏好 编辑

最新留言：3年前5条留言5人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2021年4月3日 (六) 16:14 (UTC)。回复

现在维基百科上使用的跨语言链接有两种，ilh（link-xx）和tsl。两种跨语言链接模板的参数顺序是不一样的，在不少页面中两种跨语言链接都存在，有时候挺容易将参数写反，维基百科是不是应该给出一个模板的偏好，尽量减少两种模板的混用。 --𝓧𝓩𝓣𝓓𝓮𝓪𝓷 𝕋𝕒𝕝𝕜  2021年3月25日 (四) 21:49 (UTC)回复

不认为需要限制，多种模板的设立和常用正因为编者习惯差异很大。写自己偏好的，改其他人的链接时多检查多预览，或者换掉写法。{{tsl}}支持省略中文条目名写法，只填外文条目和显示文本，ilh则不能。还有{{le}}、{{lj}}等简写捷径，不熟悉肯定看不懂，源码习惯没法统一。--YFdyh000（留言） 2021年3月25日 (四) 23:46 (UTC)回复
link-xx理论上也可以省略中文条目名写法，前提是中文条目名写法和外文条目名写法完全一致。日文类的我常常会这样做。SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 01:02 (UTC)回复
不需要限制，阁下的情形是需要多接触多练习，而不是限制他人的行为。-- 约翰同志－条目裱糊匠（留言） 2021年3月26日 (五) 08:34 (UTC)回复

Category:引用模板后大小超过限制的页面 编辑

最新留言：1年前111条留言19人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2022年6月3日 (五) 08:14 (UTC)。回复

现在写的尤利西斯·格兰特因模板里面的绿链，页面编辑、保存巨慢，而且从刚开始写就存在解析问题。

能否在解决上述技术问题前不要在模板里面用绿链？页面解析负担大好多，上十万字节的页面基本上都有问题。但如果全部是红链不管打开、编辑、保存都快多了，而且出现模板无法解析的情况会小很多。

如果实在不行那我考虑另外建模板吧，所有模板分红链版和绿链版。--7（留言） 2022年3月19日 (六) 13:46 (UTC)回复

建议社群出台一项方针限制绿链的使用，避免条目过大造成访问和编辑上的不便，比如规定模板大小超过一定字节后不得使用绿链，将模板体量控制在一个合适范围内，或是给条目中的绿链数量设置一个硬性上限，达到该上限后编者即无法再加入绿链。许多条目页底的导航模板都因超出大小限制而无法正常显示，有必要对此问题集中讨论一下。--萧漫（留言） 2022年3月21日 (一) 16:01 (UTC)回复
应提升的是模板参数上限，而非限制绿链的使用。如果不提升编辑模板的地位、权益和荣誉，任何尝试对模板的编辑行为设限，提升至类同条目般的，都是无理的。-- 约翰同志－条目裱糊匠（留言） 2022年3月22日 (二) 10:25 (UTC)回复
可以参考WP:模板限制关于“嵌套展开”的部分，这个我所知道对模板展开数影响较大。但是这涉及到“$wgMaxArticleSize”的调整，这个参数似乎同时控制源代码的输入字节大小，展开后大小、模板参数入参大小，08年这个解析限制设计时选了2MB，可能需要找当年的讨论，但从防DDoS的话，输入字节大小的控制这个是必要的，但基于“嵌套展开”和我们的模板应用的现状，我认为是有需要分开设置，单独提升展开后大小的设值。但可能需要技术开发的人去研究能开多大，我提过相应的问题（phab:T301308），但没人回应过。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月22日 (二) 10:38 (UTC)回复
如果现状的话，想要Navbox等不展开超载，控制{{ilh}}等类似的可能是无奈的策略。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月22日 (二) 10:39 (UTC)回复
另一方面也建议各位一同关注Category:引用模板后大小超过限制的页面，我归纳起来大概有几个问题：
  • 上面各位提的绿链（跨语言链接）过多，这个最常见
  • 模板语法尚有精简空间。除了上述WP:模板限制里以外的，还有：
  • 悬挂过多模板
如果我的修改有待改进，也请不吝指教。--回廊彼端（留言） 2022年3月22日 (二) 14:45 (UTC)回复
link-xx的wrapper设计就是造成容易触发模板限制的元凶，navbox也有相同问题。--Xiplus#Talk 2022年3月24日 (四) 11:31 (UTC)回复
请教Xiplus前者有办法改善吗？后者的解法是使用{{NavboxV2}}吗？--回廊彼端（留言） 2022年3月24日 (四) 12:27 (UTC)回复
换个问法，请教Xipluslink-xx跟navbox有办法只靠调整模板自身语法、而非更换模板（例如说改用NavboxV2模板）的方式改善吗？--回廊彼端（留言） 2022年3月24日 (四) 12:27 (UTC)回复
例如Special:Diff/46653006/70806470这样，“展开后的引用大小”可减少约3分之1。--Xiplus#Talk 2022年3月25日 (五) 11:03 (UTC)回复
可以，而且这也大致符合WP:模板限制提到的嵌套倍增问题。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 09:08 (UTC)回复
{{tsl}}也有同样问题，应该是3倍引用大小？--Xiplus#Talk 2022年3月26日 (六) 10:42 (UTC)回复
@Xiplus：，我认为可以替换为直接调用Lua模块代替模板嵌套。tsl的方式可以将注释标注“模板选择”的部分替换掉。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月27日 (日) 02:12 (UTC)回复
但需要把link-xx的资料全部移到模组内。--Xiplus#Talk 2022年3月27日 (日) 06:00 (UTC)回复
@Xiplus：，可能不用这么复杂？{{Translink}}实际是重排参数顺序的{{Internal_link_helper}}，既然你在link-xx将调用{{Internal_link_helper}}模板部分转为直接调用模块，Translink看上去也可以，可能需要整合{{Langname}}的部分。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 08:35 (UTC)回复
可是语言名称是保留在Template:Internal link helper/en上面，应该需要把这笔资料移动到Module内？--Xiplus#Talk 2022年3月28日 (一) 08:34 (UTC)回复
@Xiplus：，可以将语言名称即{{Langname}}的处理移入Lua里面，也可以减少多一层模板嵌入。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 08:54 (UTC)回复
@Xiplus：，好像分两种情况：link-xx已存在的话，有使用{{lan}}（有模块版本）的，这个可以整理一个集合来收集不同xx的lan集合数据；没有link-xx的，会使用{{Langname}}（有模块版本）生成，这个可以不用整理集合。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 09:09 (UTC)回复
如要修改模组，请留意一下模组:WikidataLink，里面有直接call 到绿链模组内部的相关function 。从上次法国城镇模板大爆炸拖垮维基服务器被基金会人员来本地直接删法国城镇模板后，被基金会要求应从wikidata抓资料之后，就已经大量投入使用了。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月27日 (日) 09:03 (UTC)回复
把Category:有蓝链却未移除内部链接助手模板的页面这个维护分类相关语法去掉会怎样？--洛普利宁 2022年3月27日 (日) 11:16 (UTC)回复
@Lopullinen：没用的，因为大部分的绿链根本不会输出那段，且有输出Category:有蓝链却未移除内部链接助手模板的页面这东东的模板多半被机器人替换引用掉了。问题是在“连结还绿的时候”的内文，可参考Template:Softsubst#使用方法就会知道他们都爆炸长了：“{{ilh|测试的内容|context for test}}→测试的内容（英语：context for test）→

以下内容为替换引用后的预期内容，请自行拷贝源代码完成替换引用。

<span class="ilh-all " data-orig-title="测试的内容" data-lang-code="en" data-lang-name="英语" data-foreign-title="context for test"><span class="ilh-page">[[:测试的内容|测试的内容]]</span><span class="noprint ilh-comment">（<span class="ilh-lang">英语</span><span class="ilh-colon">：</span><span class="ilh-link">-{[[:en:context for test|<span lang="en" dir="auto">context for test</span>]]}-</span>）</span></span>
”，里头许多<span></span>都应须瘦身。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月27日 (日) 16:02 (UTC)回复

以下内容为替换引用后的预期内容，请自行拷贝源代码完成替换引用。

<span class="ilh-all " data-orig-title="测试的内容" data-lang-code="en" data-lang-name="英语" data-foreign-title="context for test"><span class="ilh-page">[[:测试的内容|测试的内容]]</span><span class="noprint ilh-comment">（<span class="ilh-lang">英语</span><span class="ilh-colon">：</span><span class="ilh-link">-{[[:en:context for test|<span lang="en" dir="auto">context for test</span>]]}-</span>）</span></span>
可以看到“测试的内容（英语：context for test）”当中“测试的内容”页面不存在，因此压根没有输出“Category:有蓝链却未移除内部链接助手模板的页面”，所以即使删了“Category:有蓝链却未移除内部链接助手模板的页面”绿链仍然是那么肥。所以还是要想办法给他瘦身，看看能不能让小工具以更短的语法就能识别绿链（不知技术上有没有办法）。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月27日 (日) 16:05 (UTC)回复
注：因技术问题，上述部分代码已Subst，详见Wikipedia:互助客栈/技术#Category:未完成替换引用的页面。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年4月13日 (三) 15:41 (UTC)回复
同建议提高模板展开后大小上限--Yinyue200（留言） 2022年4月4日 (一) 15:36 (UTC)回复
我觉得问题这个条目不应该使用{{南北战争}}这个鸡肋的模板，没有导航的作用，资料量也过多。--Ghren🐦🕛 2022年3月24日 (四) 04:38 (UTC)回复
我把美国共和党模板（暂时）注释掉以后就可以正常显示了。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月24日 (四) 12:02 (UTC)回复
如果“编辑、保存”源代码就很慢，不是绿链、模板的问题，而是条目真的太长了（WP:SIZERULE）。--Xiplus#Talk 2022年3月24日 (四) 09:09 (UTC)回复
条目长的情况我很清楚会如何，毕竟上十万字节条目我写的超过任何十人总和，我上面说了那个是从一开始写就这样，你拿几个绿链模板试一下就知道。--7（留言） 2022年3月24日 (四) 10:30 (UTC)回复
您说的应该是预览时的问题，而不是编辑时的问题吧？--Xiplus#Talk 2022年3月24日 (四) 11:28 (UTC)回复
单纯为了避免模板限制，我还是建议恢复{{ill}}这个基于红链的跨语言链接模板，相比绿链，用这个模板的页面加载速度（似乎）能快很多。--BlackShadowG（留言） 2022年3月27日 (日) 08:43 (UTC)回复
这样就没有意思吧，模板限制始终是少数，没有必要为了它们，倒退至这个旧式跨语言链接。-- 约翰同志－条目裱糊匠（留言） 2022年3月27日 (日) 10:00 (UTC)回复
我觉得旧式链接+括号外语挺好的。我可以不动鼠标直接看到原文，而且一看链接是de我不懂就直接跳过了 --洛普利宁 2022年3月27日 (日) 10:09 (UTC)回复
绿链的优越一直在这里，只是站内机能追不上而已。-- 约翰同志－条目裱糊匠（留言） 2022年3月27日 (日) 10:07 (UTC)回复
@Comrade John：我认为绿链有些时候是意义不明的。比如一个日本动漫角色只在阿拉伯语版有条目，且中文版认为它没有关注度。该角色名字使用假名，没有统一的中文翻译，所以需要标注日文名。
条目中提到这个角色时：
  1. 应该标注日文原名以便对照。
  2. 不适合链接阿拉伯语维基。不能期望中文维基用户看懂阿拉伯文条目（加入链接的编者可能也看不懂）。当初禁止跨语言直链的一个理由就是如此。
  3. 不适合加入红色链接，因为它没有关注度，不应该放红链引诱读者创建条目。
  4. 可能适合链接Wikidata。读者可能看到他的基本信息，比如所属作品、画师等。
现行绿链问题有：
  1. 日文维基没有条目，编辑无法链接日维，因此无法提示日文名。如果在绿链后标注日文，手机版会显示“XXX（阿拉伯文：<阿文条目名>）（日文：XX）”的双重标记。这对于一个全站级工具是不应该的。
  2. 读者无法提前知道链接指向阿拉伯语维基，滑动鼠标的结果是浪费时间。
  3. 绿链强制带红色链接，可能会亦引诱编者创建不合适的条目。但是没有办法去掉红色连接。
之前讨论我也留言问过，这种语种冲突的问题如何解决。您回复的是绿链行之有效，此问题不值得讨论。有编辑是尽可能加绿链，但上述情况加绿链我认为并不是行之有效的做法。所以想问您，上述例子（如果不考虑技术问题）您认为怎样做合适？--洛普利宁 2022年3月27日 (日) 10:59 (UTC)回复
  1. 这是手机版问题，非绿链。“该角色名字使用假名，没有统一的中文翻译，所以需要标注日文名。”这是多此一举，直接使用日文名，直至官方译名出现就是。
  2. 滑动鼠标的结果是浪费时间。各有各看法吧。
  3. 有冇绿链，也会有编者创建不合适条目，故非绿链问题，而是编者不熟识方针吧。
所以，在小工具解决他们的问题吧，没有必要为了少数，限制多数人的行为，这是倒退。-- 约翰同志－条目裱糊匠（留言） 2022年3月27日 (日) 11:19 (UTC)回复
@Comrade John：感谢您的回应！这个问题我的想法是增加参数：
  1. 增加一个参数控制外语显示文字，将“外语维基标题”和“外文标注”独立开。（中文读者无法辨识日文假名，而且ACG领域地区词问题比较明显；需要附注原文的情况确实不少）
  2. 小工具允许用户定制js设定副语言，比如en, fr。然后优先链接设定的副语言，如果这两个语言没有条目就链接到wikidata。未注册用户可以考虑预设指向en或wikidata等。（就是感觉技术上不现实）
  3. 增加一个参数控制红链的显隐。
实际上第一个问题我之前提过，不过是有编辑认为参数太多会混淆。所以这个绿链的服务对象是读者还是编者，我就比较困扰。毕竟英文维基是连WP:ACCESS这种细节都能立指引的。
另外按照现行WP:MOSIW，可能会得出WP:OVERTSL这样的结论。当然这个结论和现实不符就是了。但MOSIW诞生时主要是为了规制[[:en:XXX]]直链，可能没想到十年后会出现的各种新技术和各种解读。所以我是认为，绿链要想做的更好，无论制度还是技术上，确实需要再重新讨论一下。--洛普利宁 2022年3月27日 (日) 12:00 (UTC)回复
这就是为何我推荐使用{{illm}}的原因。illm的好处有一下几点：
  1. 直接以红链显示，读者无需划滑动鼠标即可得知链接到哪个语言。且红链与链接对于读者而言并无二致，都是指中文维基百科不存在的条目，用两种不同的颜色标注反而很奇怪
  2. 可以很大程度上节省页面加载速度
  3. 可以同时链接多个条目，例如：神经胚​（英语；​俄语）
  4. 可以直接链接到维基数据项，这在不确定哪个语言的条目质量更高时会显得非常好用：神经胚​（其他语言）
  5. 在不确定条目对应的中文名称时（例如上方提到的没有官方译名的情况），可以只提供维基数据的ID：{{Interlanguage link multi|WD=Q575877}}——>神经胚​（其他语言），其显示的文字由维基数据的label提供。这样只需要有中文名称时修改维基数据的label即可，可以有效避免“同一个外文条目，中文版的译名却不同”的问题。
且illm长期缺乏维护，很多英维的功能没有引进，若维护完善后，优点可能更多。
虽然在绿链已经普及的今天，完全推广illm的使用的可能性不大，但我还是希望绿链能向这个方向发展，这对中维帮助很大。--BlackShadowG（留言） 2022年3月27日 (日) 14:10 (UTC)回复
illm从视觉上不能分辩伪蓝链，ilh和tsl能，这不利维护。-- 约翰同志－条目裱糊匠（留言） 2022年3月27日 (日) 18:10 (UTC)回复
illm是直接以红链显示条目名称，外语版链接是小字下标，我觉得维护上应该没有问题。--BlackShadowG（留言） 2022年3月27日 (日) 23:55 (UTC)回复
可能需要测量数据来确定哪个展开量更好。illm看代码复杂度（不少switch和if的解析器），感觉更容易触发模板限制。ilh和tsl基本上消除了解析器调用，有一个涉及模板嵌套的问题，但有解决的可能。主要问题是里面有大量的辅助标签用于给ilh配套的7个样式脚本用于重构显示形态，这可能是必要的浪费。而移动版显示的ilh应该是其原始输出没有通过配套的重构脚本处理过的真正输出效果。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 08:23 (UTC)回复
link-en：Special:固定链接/70860289，预展开为810字节；Interlanguage link multi：Special:固定链接/70860283，预展开为798字节。相差不大，但如果在Special:展开模板对比原始输出的话，Interlanguage link multi的效率不太好。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 08:51 (UTC)回复
上方的讨论混杂了多个问题，大致总结：1.绿链是否影响了编辑和保存性能。2.模板超限是否值得和可能通过消除绿链解决。3.绿链哪些算滥用，是否要有政策限制用法与用量。4.其他模板/显示效果是否比绿链更好。5.绿链是否可能在技术上改进以缓解当前问题。个人声明，我是绿链使用和赞成者，但对向读者提供绿链不置可否，仅赞成它对维基编者（和专业读者）的维护作用。
  1. 问题1，我认为更多是条目过长或其他脚本（如语法高亮、其他扩展或绿链本身）的因素，绿链至多导致预览结果较复杂而变慢。如果是绿链脚本性能问题，应能进一步优化。
  2. 问题2，我认为绿链滥用可能存在，但其维护性和说明性作用目前难以替代，单纯移除绿链将影响说明性（对应和查阅相应主题外文条目）或布局变丑（默认显示很长原文或大量存在如(英文)），条目过长、导航模板太多太大等问题同时存在。
  3. 问题3，值得讨论一些案例和考虑一个指引，限制条目正文中不必要、短期内不会创建条目的绿链。对于导航模板中的绿链，值得单独讨论，影响更大但作用也更大，因其中不能提供上下文介绍。对于“短期内不会创建”的标准，可以基于主题的常见性（很常见而没人建，绿链就可能不太有用），外文条目的热门度（编辑量、浏览量）、新鲜度、条目质量等。
  4. 问题4，我记得讨论过不止一次，并且数百人投票得出如今的折衷方案，再次争论细节并改变现状可能不现实，但用法和替代品可以讨论和列明。
  5. 问题5，值得进一步研究，如尽力缩减展开大小或改变当前实现方式。另外有个想法，针对导航模板，是否可以用机器人自动生成不调用模板（亦不检查条目是否存在）的伪绿链版本，作为模板子页面（如/cache），必要时引用它避免占用模板配额。以及也想过将目前绿链各版小工具整合为一个用户前端可切换显示效果的小工具，固定用户因此可能选用更多更理想的展示效果（上面讨论有若干细节），但这需要较多技术资源。--YFdyh000（留言） 2022年4月2日 (六) 05:15 (UTC)回复

缩减Internal link helper输出的代码 编辑

如果能放弃目前的对未启用任何“跨语言链接”小工具/未启用JavaScript的用户提供如“（英语：……）”的后缀链接，我想T:Internal_link_helper的输出能节省约70%。注，“跨语言链接：光标悬浮时显示Tooltip”目前对所有人（包括IP用户）默认启用。长度比较见此版源码。代码原型（需后续开发）。有个问题是，其他效果也需改写或放弃，Special:GadgetUsage显示其他各版internalLinkHelper效果各有几百人启用、几十人活跃，代码改写难度目测中等。另外，当前代码所用的Tipsy库已停更，基金会推荐用OOUI/Widgets/Popups代替。--YFdyh000（留言） 2022年4月2日 (六) 10:20 (UTC)回复

我用的ilh是自己改的（ ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 13:48 (UTC)回复

已尝试和确认目前各效果可以改用简化后的输出。输出量对比：

原输出
<span class="ilh-all " data-orig-title="测试的内容" data-lang-code="en" data-lang-name="英语" data-foreign-title="context for test"><span class="ilh-page">[[:测试的内容|显示文字]]</span><span class="noprint ilh-comment">（<span class="ilh-lang">英语</span><span class="ilh-colon">：</span><span class="ilh-link">-{[[:en:context for test|<span lang="en" dir="auto">context for test</span>]]}-</span>）</span></span>
新输出
<span class="ilh-all" data-la="测试的内容" data-fc="en" data-fn="英语" data-fa="context for test">[[:测试的内容|显示文字]]</span>

@AnYiLin、A2569875等有空看一下。文件较多，代码放Github了。测试用页面。代码较乱需要整理与合并，网址构造部分待优化。修改后的小工具目前未做旧格式兼容，需要定个方案应对缓存刷新阶段。--YFdyh000（留言） 2022年4月3日 (日) 22:29 (UTC)回复

另外，现有代码其实可以整合到一个小工具里，只需弄一下界面，及迁移用户设置/用户重选。但或许不必要？--YFdyh000（留言） 2022年4月3日 (日) 22:47 (UTC)回复

原输出（笔误）原始输出可以考虑用跨语言链接而非红连？让读者有相关条目可以阅读。--Xiplus#Talk 2022年4月4日 (一) 01:31 (UTC)回复
小工具用data属性替换成现有效果，变更不影响功能。如果用户禁用JS/取消全部效果，那么原版看到绿色的“红链”及“（英语：context for test）”，修改后只有红链。--YFdyh000（留言） 2022年4月4日 (一) 01:46 (UTC)回复
如果指默认输出跨语言链接，争议比较大，小工具也得调整，我认为没必要，悬停查看小工具是默认启用的。--YFdyh000（留言） 2022年4月4日 (一) 01:49 (UTC)回复
(！)意见后面的括弧X语“（英语：English）”理论上应该也可以由小工具输出，或者让使用者选择哪种小工具功能-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年4月4日 (一) 02:18 (UTC)回复
修改后括弧部分是小工具输出，见“新输出”。如果指原“data-lang-name”，考虑过由脚本转换，但本身不长、百余项塞进代码有点多，并或许牵扯到多种变体和维护问题，所以搁置了。“data-orig-title”也可能从链接中提取，但稳定性和兼容性可能下降，将增加维护成本。--YFdyh000（留言） 2022年4月4日 (一) 02:29 (UTC)回复
我知道，对于有开启小工具的人这个更改是无感的，我考虑的是App使用者（以及禁用JS等类似情况）。--Xiplus#Talk 2022年4月4日 (一) 02:23 (UTC)回复
直接让他们看到跨语言链接？有小工具的再“js”ing to 绿链-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年4月4日 (一) 02:27 (UTC)回复
App情况不了解。绿链和直接跨语言链接本就有争议（应该可以翻那次大投票），上文也提过我对向读者直接展示绿链存疑。原有的“（外文：条目链接）”我也觉得明显增加了内容凌乱程度，对阅读器用户恢复最初的直接红链促进创建似乎不成问题，而且阅读器用户可能只存了中文维基的离线镜像。如果想输出别的，我建议单开讨论。--YFdyh000（留言） 2022年4月4日 (一) 02:39 (UTC)回复
App情况不了解。绿链和直接跨语言链接本就有争议（应该可以翻那次大投票），上文也提过我对向读者直接展示绿链存疑。原有的“（外文：条目链接）”我也觉得明显增加了内容凌乱程度，也许增加了对绿链的反感。对“阅读器”用户恢复最初的直接红链促进创建也许不成问题？而且阅读器用户可能只存了中文维基的离线镜像。如果默认输出别的，建议单开讨论，可邀请这些环境的用户来谈。--YFdyh000（留言） 2022年4月4日 (一) 03:14 (UTC)回复
App的情况就是不开启小工具的情况，因为现在的修改直接影响到不开启小工具的结果，如果问跨语言链接跟红连要保留哪个，我觉得跨语言链接是比较好的。--Xiplus#Talk 2022年4月4日 (一) 02:44 (UTC)回复
非要说需求的话，我觉得T:ill的效果不错，但字小是否不好点。跨语言链接误点（看不懂、误认为中维是翻译站）和降低条目创建率这两点问题很大。--YFdyh000（留言） 2022年4月4日 (一) 03:14 (UTC)回复
@Xiplus：下文新增的效果如何，我觉得不会那么乱和喧宾夺主。至于颜色，Mediawiki:common.js等是否生效？--YFdyh000（留言） 2022年4月4日 (一) 14:26 (UTC)回复
我发现App似乎有载入部分的小工具，但绿连小工具没有载入。--Xiplus#Talk 2022年4月5日 (二) 02:42 (UTC)回复
绿连小工具没有设计适配移动版网页，所以设定为不载入。--Xiplus#Talk 2022年4月5日 (二) 02:44 (UTC)回复
我试了试，Gadget-internalLinkHelper-cravix.js可以改写适配zhwiki.oracleblog.org界面。因改版方式未定，源码非常乱，整理好再发。如果移动版可以用“鼠标点击时显示Tooltip”，对默认输出格式有什么建议吗。另外，我尝试了不输出任何“data-”属性，小工具JS解析链接，但稳定性不如属性写出，代码有点复杂。--YFdyh000（留言） 2022年4月5日 (二) 07:21 (UTC)回复
不好意思我不懂技术，请教一下这边的讨论跟上面提的“link-xx模板的wrapper”设计有关吗？Template:Navbox的wrapper设计稍后也会讨论吗？--回廊彼端（留言） 2022年4月5日 (二) 07:30 (UTC)回复
Navbox的结构我不了解，可能无能为力。如果导航框中用了许多绿链，这边会有帮助，否则无关联。--YFdyh000（留言） 2022年4月5日 (二) 07:35 (UTC)回复
User:Xiplus、User:Cwek请教一下这个讨论还能继续吗？上面提的“link-xx、navbox模板的wrapper”设计如果没太大问题可以先修改吗？--回廊彼端（留言） 2022年4月13日 (三) 02:55 (UTC)回复
正在观望YFdyh000对缩小ilh代码输出量的考虑，无论是这个（还有配套的js脚本改写和移动版的适配改造等），还是合并部分语言标签到ilh的Lua代码中，都需要管理员的编辑权限，所以只有想法，其他爱莫能助。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月13日 (三) 03:05 (UTC)回复
@cwek、迴廊彼端：如果能定案，公示，出现共识的话就能提出编辑请求请管理员编辑上列js、css、Lua等高风险全保护页面。先改是不可能的，因为根据现行的相关《保护方针》此等修改“需要共识”，共识“需要公示”，公示“需要定案”，定案全体参与讨论者的“初步共识”，上面看起来无论可行不可行皆未见可定案的初步共识。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年4月13日 (三) 03:11 (UTC)回复
既然需要公示，有空我再弄一下吧，需要方便预览的版本。之前在等更多技术层面意见，如是否放弃data属性、与旧版模板的兼容性等。--YFdyh000（留言） 2022年4月13日 (三) 15:56 (UTC)回复
(？)疑问：这种做法究竟到底是在减少服务器端的执行开销还是纯粹绕避技术限制？究竟是在加快页面加载速度还是拖慢页面加载速度？
  • 原理上说，目前ilh的红/蓝/绿链判断是通过后端代码直接向内网的数据库服务器查询来实现的。一方面wmf的反向代理服务器会缓存形如https://zh.wikipedia.org/wiki/<页面名>的访问请求，另一方面mediawiki的解析器也有缓存，以至于相关的Lua代码只要执行一次，数据库查询只需要进行一次，就能在相当长的一段时间内响应多个非登录用户对页面的访问需求。
  • 该修改方案等于是将相关的逻辑改由前端实现，默认启用的前端代码通过公网以向服务器查询页面是否存在，从而输出红/蓝/绿链。因此，访问带ilh的页面时，浏览器的开销必然会增加；通过外网查询页面是否存在也远较目前后端代码直接通过内网进行数据库查询来得慢，页面加载速度也会变慢。这些暂且都不论。更要紧的是，wmf的反向代理服务器是不缓存mediawiki api查询请求的。换言之，采用这个方案之前，是“后端代码执行一次，数据库查询进行一次”，就能满足一段时间内多个用户访问页面的需求；采用该方案以后，是“无论非登录还是登录用户，只要访问一次带ilh的页面，就前端相关代码就得执行一次，就得向服务器发起一次api请求查询相关页面存在与否——这些api请求因为不缓存的缘故，到最后都还是会被mediawiki代码翻译成数据库的查询请求。”
  • 所以，这个方案非但没有减轻wmf运行mediawiki的服务器乃至数据库服务器的开销，在特殊情况下反而会令后者大幅增加——例如，如果一个带有几百个ilh链接的页面上了首页，或者因为各种原因热门起来，访问量一天好几万。即使按api请求可以10个页面一起查询来算，这就相当于访问量直接变相翻了几十倍，原先5万一天，可能在服务器那边看来就是一天几百万。原先5万一天的请求中90%以上都会在反代层面上终止（因为有缓存），现在变几百万以后还统统不缓存地进了运行mediawiki的服务器和数据库服务器。--Antigng（留言） 2022年4月13日 (三) 13:22 (UTC)回复
@Antigng：（无论新旧版）小工具并没有向mediawiki api发出请求，红/蓝连都是在后端执行。--Xiplus#Talk 2022年4月13日 (三) 13:55 (UTC)回复
撤回发言。--Antigng（留言） 2022年4月13日 (三) 14:19 (UTC)回复
  • 抱歉拖得有点久，说一下进展。一直考虑如何提供“预览”供评测，以及版本切换期间的兼容性，目前做了一个整合的单js文件版本。稳定性是Alpha版本。需关闭现有的绿链小工具。然后浏览器中按F12-执行下列代码（或者加入common.js）：
mw.loader.load("https://zh.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:YFdyh000/Gadget-internalLinkHelper-one-dev.js");
  • 侧栏会有一个“跨语言链接效果”供切换选项（使用HTML5本地存储，暂不能跨设备同步）。现有页面及效果应该正常运行。新版输出代码和预览见此版本，或者[2][3]这两个实验站页面。预期存在一些bug，架构等方面没有太大的信心但看上去能用，期待有人帮忙。js代码较长是含有旧版兼容代码，模块更替后可大幅删减。移动版页面已做兼容，加载脚本后应可以单击查看绿链信息。“[英语]”可以变小和隐藏，如果能放入全局css/模板样式并生效。默认效果、已过时的tipsy尚未完成重写，代码逻辑仍有些凌乱。没有做设置迁移功能。悬停模式的链接颜色目前有bug。
  • 指标方面，参考上面提到的实验站页面的网页元素/源码。当前版本：“Post‐expand include size: 247927/2097152 bytes Template argument size: 4775/2097152 bytes”，修改后版本：“Post‐expand include size: 81642/2097152 bytes Template argument size: 4775/2097152 bytes”，缩减67%（81642/247924=0.329）。站内的该页面是“Post‐expand include size: 209649/2097152 bytes”，或许是Template:Internal link helper/en直接调用模块而不经Template:Internal link helper的功劳？--YFdyh000（留言） 2022年4月25日 (一) 13:37 (UTC)回复
    @YFdyh000：虽然快一个月了但我还是要吐槽一下，为何一定要一堆镶套，一个$.when($.ready, mw.loader.using('mediawiki.util','jquery.tipsy','ext.gadget.site-lib'), mw.loader.getScript('https://zh.wikipedia.org/w/index.php?title=MediaWiki:Tooltips.js&action=raw&ctype=text/javascript')).then(...)不就得了  囧rz……--SunAfterRain 2022年5月24日 (二) 00:03 (UTC)回复
    @SunAfterRain：因为这是现有数个小工具效果合并而来，最初打算单独维护和修订各效果，为了方便测试才整合了one版本，代码清理合并是功能稳定后的事。jquery.tipsy也得在之后取消掉。--YFdyh000（留言） 2022年5月24日 (二) 07:46 (UTC)回复

无小工具环境下的输出格式 编辑

见上文。如空缺条目——红链，其他颜色的空缺条目，空缺条目——直接联到外文维基，空缺条目（外文条目名）——不带语言名、可能与后面已有括号重复，空缺条目（英语）——T:ill，等格式，是否有优劣，是否替代纯红链。--YFdyh000（留言） 2022年4月4日 (一) 03:14 (UTC)回复

再一种效果：显示文字[英语] 或 显示文字[英语]--YFdyh000（留言） 2022年4月4日 (一) 14:26 (UTC)回复
我是认为应该对读者（未注册用户）生成一个效果，无论有无小工具。所有编者都以这个为前提使用模板。个人来看：
  • 链接外维时，“空缺条目（英语版）”比较灵活，后面再有括号显示出来也说得过去。（小中括号、上标下标、加不加“版”字可以再议）
  • Wikidata是多语言环境有中文，可以考虑直链。
  • 或者模板加入参数控制效果。比如你认为这里直链英文版有利于排版，那就调参数设成直链enwp。这里只用考虑操作对典型中文维基读者是否有利，不用考虑维护是否方便。维护人员认为这样创建条目麻烦，设js把这类操作打回绿链popup便是。
--洛普利宁 2022年4月4日 (一) 17:58 (UTC)回复
或者就是只套一层默认没有效果的HTML。比如{{ilhx|[[aaaaa]]|en:XXXX}}对读者就效果是aaaaa，{{ilhx|aaaaa|d:Q123456}}对读者效果是aaaaa。然后编辑和高级用户在js里设置：比如我只会英语和日语，那就当项目有英文版和日文版时绿链弹窗；我专注维护Wikidata，那就全部指向d站等等。--洛普利宁 2022年4月4日 (一) 18:24 (UTC)回复
类似红链方案，也是第一版方案。但上一节中Xiplus认为App读者（不支持小工具）需要跨语言链接。按语言隐藏、凸显等可开发单独的脚本/CSS解决。--YFdyh000（留言） 2022年4月4日 (一) 18:32 (UTC)回复
我是认为中文维基不要对普通读者到处贴跨语言连接。一两个拿不准的翻译为避免误导读者，贴个链接方便对照也就OK。（此处是希望读者通过信息框生卒年份定位人，不是期望读者真的读一篇外文维基条目；实际这里连Wikidata更合适）en:Elections in Germany这种没有翻译难度的短语，真的就不要给读者跨维基链接了。现在绿链对读者用的太滥了。但现在编者模式和读者模式分不开，结果就是编者把适合自己的效果强加给读者了。--洛普利宁 2022年4月4日 (一) 19:03 (UTC)回复
感谢回应。现有效果来说，未注册用户及默认设置是绿链悬停提示，没有小工具的场景下则是（语言：外文名）的后缀。small和括号也是个选择，下标我这里看有点错位感，但我认为[]更节省空间且不会与后文的括号重复。链Wikidata是ill效果，功能更多但会否不习惯，以及可能因技术原因暂不可行（如何查Q编号）。参数控制可行，但整体调整不如直接改模块，有按模板或上下文调整效果的需求和意义吗，将增加编辑战。JS控制就是小工具/做界面，但本章节主要讨论无JS环境下的效果。原有效果源码太长了，显示我也认为比较冗余。--YFdyh000（留言） 2022年4月4日 (一) 18:27 (UTC)回复
@YFdyh000：①{{WikidataEntity}}可查询Q编号；②若持有Q编号可查询对应条目，此功能几年前已实作于绿链{{Link-wd}}中例如“{{link-wd|Q107002031}}”→“雪菲（维基数据所列：Q107002031）”；③持有Q编号和P编号都可以查询相应中文名称；④“链Wikidata是ill效果”并非，两年前已有{{WikidataLink}}，是“ilh效果”，例如“{{WikidataLink|Q107002031}}”→“雪菲（维基数据所列：Q107002031）”。以上。若上一节ilh优化有结论，{{Link-wd}}、{{WikidataLink}}基本可以立即跟进。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年4月13日 (三) 03:25 (UTC)回复
我支持红链下标的形式，至少是在APP端。目前APP端“（语言：外文名）”显示方式很有迷惑性，私以为在一般人理解来看，“AAA（英语：BBB）”会让人理解为“BBB”是“AAA”的英文名，但在使用中很多的情况下都不是对应的，例如“角色（英语：List of The Last of Us characters）”这种中英文对应不上的可能会让新来的读者感到迷惑。此外，读者只需要知道“这个东西在其它语言版本有条目”即可，而不需要知道“其它语言版本的条目叫什么名字”。综上，我认为红链下标的形式能解决这些问题。--BlackShadowG Pray for Ukraine 2022年4月14日 (四) 12:58 (UTC)回复
支持红链下标，至少在文档流内。大家可以试试当一个短绿链不幸正好位于换行的位置上的时候会有多难看。 --MilkyDefer 2022年4月16日 (六) 05:45 (UTC)回复
提醒一下，测试的时候不要忘记测试在维基百科Android和iOS App中是否正常工作。--Tranve (✉) 2022年5月9日 (一) 13:54 (UTC)回复
暂未测试相关环境，但与移动版网页+模拟触控应该相差不多？截至目前，没有人进一步参与测试和给出意见，所以开发暂时搁置，我不确定是否有人不同意这种方案。--YFdyh000（留言） 2022年5月9日 (一) 14:32 (UTC)回复

Template:Translink简化 编辑

Translink直接呼叫模组的patch已完成：Template:Translink/sandbox、Module:Ilh/sandbox、Module:Ilh/data、Template:Internal link helper/en/sandbox，测试样例请见Template:Translink/testcases、Template:Internal link helper/en/testcases，cc User:Cwek。--Xiplus#Talk 2022年4月25日 (一) 15:45 (UTC)回复

@Xiplus：，测试过没异常的话就更新吧。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月25日 (一) 23:29 (UTC)回复
  1. 会否影响已启用任何“跨语言链接”小工具的用户的绿链和伪蓝链的显示 ?
  2. 会否影响Translink和Internal link helper的原代码输入 ?
  3. 可以减少几多“展开后的引用大小” ?
  4. 页面编辑、保存、解析问题会否有所改善 ?-- 约翰同志－条目裱糊匠（留言） 2022年4月27日 (三) 08:12 (UTC)回复
    1. 不会。 2. 不会。 3. -35%。 4. 不会、不会、会。--Xiplus#Talk 2022年4月27日 (三) 08:21 (UTC)回复
请教User:Xiplus我这边Template:Translink/testcases倒数两项的旧版显示“{{ilh|lang={{langname|aa}}|lang-code=aa|1=Test2|2=Test2|d=|nocat=}}”、“{{ilh|lang={{langname|aa}}|lang-code=aa|1=測試2|2=Test2|d=|nocat=}}”，是否有些问题呢？--回廊彼端（留言） 2022年4月27日 (三) 11:55 (UTC)回复
就是现行版本有bug。--Xiplus#Talk 2022年4月27日 (三) 12:10 (UTC)回复
我不知道为何Cwek要这样设计Special:Diff/42823985。--Xiplus#Talk 2022年4月27日 (三) 12:12 (UTC)回复
@Xiplus：我也忘了……大概就是如果已经存在link-XX的就复用（有对应已配置的语言信息），如果没有的话，就利用{{langname}}来生成，然后需要依靠模块:langname来解决？这部分也是参照改动前的调整。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 12:49 (UTC)回复
这个我知道，但为什么要使用{{!}}？--Xiplus#Talk 2022年4月27日 (三) 13:12 (UTC)回复
{{#ifexist:Template:link-{{{1}}}
|link-{{{1}}}<!--快捷模板-->
|ilh{{!}}lang={{langname{{!}}{{{1}}}}}{{!}}lang-code={{{1}}}<!--通用模板-->
}}——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 13:19 (UTC)回复
但是把这个按照正常使用又是没问题的。扔到Special:展开模板也是能跑的。  囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 12:52 (UTC)回复
@Cwek，没有：Special:PermaLink/71346024。--Xiplus#Talk 2022年4月27日 (三) 13:11 (UTC)回复
有可能是当时没测试覆盖到，但思路是通过ifexist判断，是的话输出link-XX，不是的话输出后面ilh+参数lang和lang-code的的部分。如果不用{{!}}的话，管道符会成为ifexist的参数分割。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 13:19 (UTC)回复
或者刚好把这个部分在这个调整给修复了。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 13:26 (UTC)回复

七天已过，所以 ?--约翰同志－条目裱糊匠（留言） 2022年5月1日 (日) 20:32 (UTC)回复

已部署。--Xiplus#Talk 2022年5月3日 (二) 14:39 (UTC)回复
强制刷新了Category:引用模板后大小超过限制的页面，数量从240下降到227。--Xiplus#Talk 2022年5月3日 (二) 15:20 (UTC)回复

是否依然有必要保留“Template:(语言代码)-link”系列重定向（比如Template:en-link）？ 编辑

最新留言：1年前23条留言11人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2022年7月4日 (一) 00:14 (UTC)。回复

经过本站多年对ILH系列模板的使用指导，我发现几乎没人能把{{link-(语言代码)}}写反，顶多遇到个别几例后续参数写反的人（估计是{{tsl}}控的后遗症），-link系列存在感至少本人未曾感受到，所以我希望未来某一天彻底弃用并使之走向提删，但因为牵涉早期创建者人数众多，故冀希望于在VPT先达成弃用共识再行行动。--Liuxinyu970226（留言） 2022年6月15日 (三) 06:07 (UTC)回复

删除了是不是可以减轻服务器负担 ？可以保留下来，或者不排除会突然习惯用link-X。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月15日 (三) 06:21 (UTC)回复
未见删除必要。T:En-link有5652个链入。--YFdyh000（留言） 2022年6月16日 (四) 22:15 (UTC)回复
倾向于希望清理。--Liuxinyu970226（留言） 2022年6月17日 (五) 05:18 (UTC)回复
(？)异议WP:没坏别修。如果问题没有真正的发生，试图解决这个虚构的“问题”对维基百科没有效益。我们不该浪费时间和精力假想一个虚构的问题，再想办法解决它。 请问使用{{link-XX}}造成了什么问题？Wikipedia:不要担心性能。所有东西都不是问题。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年6月17日 (五) 06:45 (UTC)回复
@A2569875：同下面看法，我所咨询的是{{XX-link}}（语言代码后面-link后缀），跟link-XX系列（link-前缀加语言代码）毫无关系，您应该重新审题。如果一个重定向的建立不是为了方便ta人使用，那么创建ta干什么呢？只是觉得重定向好玩么？--Liuxinyu970226（留言） 2022年6月21日 (二) 07:30 (UTC)回复
除非坏了，否则必要性不大。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月17日 (五) 06:35 (UTC)回复
的确坏了，不过例子不在维基百科上，而是维基词典上。--Liuxinyu970226（留言） 2022年6月21日 (二) 05:48 (UTC)回复
(！)意见，我记得{{link-en}}系列以前是为了替换当时泛滥的“[[某某某]]（[[:en:something else|something else]]）”等外标式跨语言链接，而{{tsl}}则刚好用来替换“[[:en:something else|某某某]]”之类的隐藏式的跨语言链接，两种模板结构刚好分工互补，Cewbot（讨论 | 贡献）好像也还在使用？——白布飘扬（留言） 2022年6月18日 (六) 16:38 (UTC)回复
不知module:ilh能不能自动判读内链与外链，这样就不必纠结其位置了。——🤔白布飘扬（留言） 2022年6月18日 (六) 17:06 (UTC)回复
假如真的废止这些模板，对于cewbot来说只不过少处理这种类型的模板，实际上并无影响。--Kanashimi（留言） 2022年6月18日 (六) 21:33 (UTC)回复
或许可以做个模板像{{iw|:en:Example|例子}}这样“自然地”输入参数。--洛普利宁 2022年6月19日 (日) 08:11 (UTC)回复
假如要加新模板，烦请联络一下这边。--Kanashimi（留言） 2022年6月19日 (日) 20:49 (UTC)回复
tsl已经很好了。容易顺手误写为[[:en]]--YFdyh000（留言） 2022年6月20日 (一) 01:45 (UTC)回复
什么因素令阁下将维基词典的问题，放到维基百科谈 ?--约翰同志－条目裱糊匠（留言） 2022年6月21日 (二) 11:47 (UTC)回复
我猜可能是因为那边没多少人活跃吧？--Txkk（留言） 2022年6月22日 (三) 06:41 (UTC)回复
@Liuxinyu970226 有什么这边可以帮忙的吗?--Kanashimi（留言） 2022年6月23日 (四) 23:30 (UTC)回复
添加话题
取自“https://zh.wikipedia.org/w/index.php?title=Template_talk:Internal_link_helper&oldid=73395182”
返回到“Internal link helper”页面。