模板讨论:Translink
维基百科,自由的 encyclopedia
明明跨语言链接有专属的颜色(浅蓝色),为什么要用如此不协调的绿色? ——小烈 (找我?) 2012年4月5日 (四) 22:45 (UTC)[回复]
- (:)回应因为浅蓝(iwlink)和深蓝(存在条目)太容易混淆(这个早前常有人抱怨),所以暂时改成绿色,三基色(红蓝绿)对比比较明显(当然,"明显"的代价可能就是"不协调"吧).不过如果可以的话,我还是希望各位能从这里帮我推荐一种合适的颜色吧
- BTW:之前liang君改成重定向到link系模板,不过"中英对照"式会造成不一致性(参照下例)= =所以先改回来了.
- 我也打算重提跨语言链接处理问题,"中英对照"式粗看起来有优势,真正用起来却也问题诸多. - Dr. Cravix ♪All Along The WatchTower 2012年4月6日 (五) 00:16 (UTC)[回复]
如果在声明 (计算机编程)(英语:Declaration (computer programming))中没有明确标识其存储类
(莫名其妙多出的"(计算机编程)"不是很奇怪么?)
如果在声明(英语:Declaration (computer programming))中没有明确标识其存储类
(这就是我所说的"前后不一致"了)
(而且上述两个都带上了"(computer programming)"...)
- 选色方面,用绿色系的确有点唐突,还是选蓝色系好,不过尽可能有明显的对照感——路过围观人士(路过进来留个爪) 2012年4月6日 (五) 02:10 (UTC)[回复]
- 我想过,也测试过不少颜色,不过不是太淡就是基本没有区分感
囧rz...还是得掺点绿色.要不我还是试着把蓝绿混起来(带蓝比较不突兀),给几个简单的备选方案吧(蓝绿配比都为1:1,#为颜色编号),
- #044:ATI #055:ATI #066:ATI #077:ATI #088:ATI #099:ATI #0AA:ATI #0BB:ATI #0CC:ATI #0DD:ATI
- 对照 ATI ATI,
- 如果可以的话帮我挑个比较合适的吧
- Dr. Cravix ♪All Along The WatchTower 2012年4月6日 (五) 06:10 (UTC)[回复]
- {{link-en}}有第三个参数是显示的文字。Liangent (留言) 2012年4月6日 (五) 04:14 (UTC)[回复]
- 注意看了一下发现了= =囧.不过还是有不一致性问题,比如:
- 用户提醒(英语:Notification system)
- 存储类(英语:C syntax)
- 就语义上说,的确是不一致的...因为只是子部分吧. - Dr. Cravix ♪All Along The WatchTower 2012年4月6日 (五) 06:10 (UTC)[回复]
- 只显示文字的话能消除括号不,本来就是用来消歧义的东西,没链接就不用“消”歧义了……--铁铁的火大了(抓兔子啦,抓兔子啦……) 2012年4月6日 (五) 05:48 (UTC)[回复]
- 编辑冲突囧...不过我还是不明白你要表达的意思? - Dr. Cravix ♪All Along The WatchTower 2012年4月6日 (五) 06:10 (UTC)[回复]
- 我想过,也测试过不少颜色,不过不是太淡就是基本没有区分感
- (*)提醒于是暂时套用了#055,效果用户提醒,如果有什么修改建议(如换颜色(可参照上面我给的10种颜色示例,也可自选)等)还请提出
- 还有,liang君我有个(&)建议,link系模板原来的提示框效果其实挺不错的,只是没有标识而已,我想能不能把link系模板原有的JS效果拿来用呢,
- 具体来说,就是Tsl式标识+早前link系模板式提示框,避免"隐藏红字嫌疑",同时方便编者和读者,
- 我觉得这样效果会好得多,不知能否帮忙一下呢?在此也先谢过啦XD - Dr. Cravix ♪All Along The WatchTower 2012年4月7日 (六) 01:00 (UTC)[回复]
- 我个人的意见是,既然维基内部已经有约定好跨维基链接的颜色(淡蓝色,确实比起很久以前的版本区分度大幅度降低,但是知道的人依然可以一眼区分吧),那么我们自己制作的同样目的(跨语言链接)的模板就不应该使用第三方的颜色。虽说是规避了颜色区分度较低的问题,但是引入了一种新的颜色,对于不了解此模板的人反而会觉得莫名其妙。--小烈 (找我?) 2012年4月10日 (二) 19:52 (UTC)[回复]
- (:)回应"一眼区分"...说真的之前有不少人抱怨说不仔细看不容易认出来
囧rz...就我认为的话把现行link系模板下属的"跨语言链接:在Tooltip中显示原文链接"效果(类同我下面的"新版样式")和加色提示的效果结合起来是最好的.
- 于是试着做了一下,按我写的测试方法做就有效果了,可以一看吧
- Dr. Cravix ♬La Pluie 2012年4月14日 (六) 03:45 (UTC)[回复]
- 旧版样式(点击出现提示框)测试法:
- 新版样式(鼠标移入出现提示框)测试法:
- 自己的js脚本加入
'importScript( "User:Dr.Cravix/iwlnew.js" );'
(不带单引号)一行,小工具勾选"ToolsRedirect"和"Twinkle"这两项(其余随便勾),同上清理缓存,刷新页面可见.
- 自己的js脚本加入
- 原来的修了哪里?Liangent (留言) 2012年4月14日 (六) 16:49 (UTC)[回复]
- 我自己乱搞一通也记不得修了些什么了= =但没记错的话似乎一拿来放进common.js配合复制来的旧版模板就能用了,后面基本上是校正格式而已...也有一些其他的修改,晚点我再查记录吧囧- Dr. Cravix ♬La Pluie 2012年4月16日 (一) 15:35 (UTC)[回复]
- (:)回应"一眼区分"...说真的之前有不少人抱怨说不仔细看不容易认出来
MIM消歧义
关于{{Translink}}模板的颜色
本主题或以下段落文字,移动自Wikipedia:互助客栈/求助。执行者:Jimmy-bot(留言) 2014年12月18日 (四) 16:42 (UTC)。[回复]
[[勝利女神飛彈]]系列,第1代{{tsl|en|MIM-3 Nike Ajax|MIM-3勝利女神·飛毛腿|MIM-3-{zh-hans:阿基克斯; zh-hk:大埃阿斯;zh-tw:飛毛腿;}-}}飛彈、第2代{{tsl|en|MIM-14 Nike Hercules|MIM-14勝利女神·力士|MIM-14-{zh-hans:大力神; zh-tw:力士;}-}}飛彈
- 或[[勝利女神飛彈]]系列,{{tsl|en|MIM-3 Nike Ajax|MIM-3勝利女神·飛毛腿|MIM-3-{zh-hans:阿基克斯; zh-hk:大埃阿斯;zh-tw:飛毛腿;}-}}、{{tsl|en|MIM-14 Nike Hercules|MIM-14勝利女神·力士|MIM-14-{zh-hans:大力神; zh-tw:力士;}-}}
- 都会由“顿号、之后跳行”,算bug吗?! --114.45.34.54(留言) 2014年12月7日 (日) 06:38 (UTC)[回复]
- 似乎已正常 ... --114.45.36.17(留言) 2014年12月7日 (日) 09:46 (UTC)[回复]
- O-ring 修正[1]、[2] --114.45.37.189(留言) 2014年12月8日 (一) 11:43 (UTC)[回复]
- 都会由“顿号、之后跳行”,算bug吗?! --114.45.34.54(留言) 2014年12月7日 (日) 06:38 (UTC)[回复]
简繁转换bug?
如:赤根和树(日语:赤根和樹),维基百科已经有赤根和树的条目了,而且链接颜色已经变成纯蓝色了,点击也会跳转过去,但是鼠标浮动在上面依旧会提示“条目“赤根和树”尚未创建,可参考日语维基百科的对应页面”。是因为被缓存了吗。。。我等了半个小时了。。。 Gaosong2101(留言) 2019年10月21日 (一) 16:29 (UTC)[回复]
跨语言链接模板的偏好
本主题或以下段落文字,移动自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)[回复]
编辑请求 2022-04-26
请求已处理
优化性能,参见Wikipedia:互助客栈/技术#Template:Translink简化。--Xiplus#Talk 2022年4月26日 (二) 01:08 (UTC)[回复]
Category:引用模板后大小超过限制的页面
本主题或以下段落文字,移动自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:模板限制里以外的,还有:
- 误用语法如Special:Diff/70523894(这样清完省下约一万位元组,大概是4-5笔Cite系列书目模板,或者1/20到半个不等的导航模板)
- 没搭配Template:Nowrap begin、Template:Nowrap end使用的各种禁止换行模板Special:Diff/70693799(这样清了五千多位元组)
- 模板本身内镶或使用其他模板如Template:Metalworking navbox,也有看过在条目里使用新创Navbox包覆数个模板的
- 模板内容过于庞大
- 悬挂过多模板
- 如果我的修改有待改进,也请不吝指教。--回廊彼端(留言) 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)[回复]
- 例如Special:Diff/46653006/70806470这样,“展开后的引用大小”可减少约3分之1。--Xiplus#Talk 2022年3月25日 (五) 11:03 (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)[回复]
- 可是语言名称是保留在Template:Internal link helper/en上面,应该需要把这笔资料移动到Module内?--Xiplus#Talk 2022年3月28日 (一) 08:34 (UTC)[回复]
- @Xiplus:,可能不用这么复杂?{{Translink}}实际是重排参数顺序的{{Internal_link_helper}},既然你在link-xx将调用{{Internal_link_helper}}模板部分转为直接调用模块,Translink看上去也可以,可能需要整合{{Langname}}的部分。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月28日 (一) 08:35 (UTC)[回复]
- 但需要把link-xx的资料全部移到模组内。--Xiplus#Talk 2022年3月27日 (日) 06:00 (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)[回复]
- @Lopullinen:没用的,因为大部分的绿链根本不会输出那段,且有输出Category:有蓝链却未移除内部链接助手模板的页面这东东的模板多半被机器人替换引用掉了。问题是在“连结还绿的时候”的内文,可参考Template:Softsubst#使用方法就会知道他们都爆炸长了:“
- 把Category:有蓝链却未移除内部链接助手模板的页面这个维护分类相关语法去掉会怎样?--洛普利宁 2022年3月27日 (日) 11:16 (UTC)[回复]
- @Xiplus:,我认为可以替换为直接调用Lua模块代替模板嵌套。tsl的方式可以将注释标注“模板选择”的部分替换掉。——Sakamotosan路过围观 | 避免做作,免敬 2022年3月27日 (日) 02:12 (UTC)[回复]
- link-xx的wrapper设计就是造成容易触发模板限制的元凶,navbox也有相同问题。--Xiplus#Talk 2022年3月24日 (四) 11:31 (UTC)[回复]
- 另一方面也建议各位一同关注Category:引用模板后大小超过限制的页面,我归纳起来大概有几个问题:
- 同建议提高模板展开后大小上限--Yinyue200(留言) 2022年4月4日 (一) 15:36 (UTC)[回复]
- 应提升的是模板参数上限,而非限制绿链的使用。如果不提升编辑模板的地位、权益和荣誉,任何尝试对模板的编辑行为设限,提升至类同条目般的,都是无理的。-- 约翰同志-条目裱糊匠(留言) 2022年3月22日 (二) 10:25 (UTC)[回复]
- 我觉得问题这个条目不应该使用{{南北战争}}这个鸡肋的模板,没有导航的作用,资料量也过多。--Ghren🐦🕛 2022年3月24日 (四) 04:38 (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)[回复]
- 条目长的情况我很清楚会如何,毕竟上十万字节条目我写的超过任何十人总和,我上面说了那个是从一开始写就这样,你拿几个绿链模板试一下就知道。--7(留言) 2022年3月24日 (四) 10:30 (UTC)[回复]
- 单纯为了避免模板限制,我还是建议恢复{{ill}}这个基于红链的跨语言链接模板,相比绿链,用这个模板的页面加载速度(似乎)能快很多。--BlackShadowG(留言) 2022年3月27日 (日) 08:43 (UTC)[回复]
- 这样就没有意思吧,模板限制始终是少数,没有必要为了它们,倒退至这个旧式跨语言连结。-- 约翰同志-条目裱糊匠(留言) 2022年3月27日 (日) 10:00 (UTC)[回复]
- 我觉得旧式链接+括号外语挺好的。我可以不动鼠标直接看到原文,而且一看链接是de我不懂就直接跳过了
--洛普利宁 2022年3月27日 (日) 10:09 (UTC)[回复]
- 我觉得旧式链接+括号外语挺好的。我可以不动鼠标直接看到原文,而且一看链接是de我不懂就直接跳过了
- 这样就没有意思吧,模板限制始终是少数,没有必要为了它们,倒退至这个旧式跨语言连结。-- 约翰同志-条目裱糊匠(留言) 2022年3月27日 (日) 10:00 (UTC)[回复]
- 绿链的优越一直在这里,只是站内机能追不上而已。-- 约翰同志-条目裱糊匠(留言) 2022年3月27日 (日) 10:07 (UTC)[回复]
- @Comrade John:我认为绿链有些时候是意义不明的。比如一个日本动漫角色只在阿拉伯语版有条目,且中文版认为它没有关注度。该角色名字使用假名,没有统一的中文翻译,所以需要标注日文名。
- 条目中提到这个角色时:
- 应该标注日文原名以便对照。
- 不适合链接阿拉伯语维基。不能期望中文维基用户看懂阿拉伯文条目(加入链接的编者可能也看不懂)。当初禁止跨语言直链的一个理由就是如此。
- 不适合加入红色链接,因为它没有关注度,不应该放红链引诱读者创建条目。
- 可能适合链接Wikidata。读者可能看到他的基本信息,比如所属作品、画师等。
- 现行绿链问题有:
- 日文维基没有条目,编辑无法链接日维,因此无法提示日文名。如果在绿链后标注日文,手机版会显示“XXX(阿拉伯文:<阿文条目名>)(日文:XX)”的双重标记。这对于一个全站级工具是不应该的。
- 读者无法提前知道链接指向阿拉伯语维基,滑动鼠标的结果是浪费时间。
- 绿链强制带红色链接,可能会亦引诱编者创建不合适的条目。但是没有办法去掉红色连接。
- 之前讨论我也留言问过,这种语种冲突的问题如何解决。您回复的是绿链行之有效,此问题不值得讨论。有编辑是尽可能加绿链,但上述情况加绿链我认为并不是行之有效的做法。所以想问您,上述例子(如果不考虑技术问题)您认为怎样做合适?--洛普利宁 2022年3月27日 (日) 10:59 (UTC)[回复]
- 这是手机版问题,非绿链。“该角色名字使用假名,没有统一的中文翻译,所以需要标注日文名。”这是多此一举,直接使用日文名,直至官方译名出现就是。
- 滑动鼠标的结果是浪费时间。各有各看法吧。
- 有冇绿链,也会有编者创建不合适条目,故非绿链问题,而是编者不熟识方针吧。
- 所以,在小工具解决他们的问题吧,没有必要为了少数,限制多数人的行为,这是倒退。-- 约翰同志-条目裱糊匠(留言) 2022年3月27日 (日) 11:19 (UTC)[回复]
- @Comrade John:感谢您的回应!这个问题我的想法是增加参数:
- 增加一个参数控制外语显示文字,将“外语维基标题”和“外文标注”独立开。(中文读者无法辨识日文假名,而且ACG领域地区词问题比较明显;需要附注原文的情况确实不少)
- 小工具允许用户定制js设定副语言,比如
en, fr
。然后优先链接设定的副语言,如果这两个语言没有条目就链接到wikidata。未注册用户可以考虑预设指向en或wikidata等。(就是感觉技术上不现实) - 增加一个参数控制红链的显隐。
- 实际上第一个问题我之前提过,不过是有编辑认为参数太多会混淆。所以这个绿链的服务对象是读者还是编者,我就比较困扰。毕竟英文维基是连WP:ACCESS这种细节都能立指引的。
- 另外按照现行WP:MOSIW,可能会得出WP:OVERTSL这样的结论。当然这个结论和现实不符就是了。但MOSIW诞生时主要是为了规制
[[:en:XXX]]
直链,可能没想到十年后会出现的各种新技术和各种解读。所以我是认为,绿链要想做的更好,无论制度还是技术上,确实需要再重新讨论一下。--洛普利宁 2022年3月27日 (日) 12:00 (UTC)[回复]
- @Comrade John:感谢您的回应!这个问题我的想法是增加参数:
- 这就是为何我推荐使用{{illm}}的原因。illm的好处有一下几点:
- 直接以红链显示,读者无需划滑动鼠标即可得知链接到哪个语言。且红链与链接对于读者而言并无二致,都是指中文维基百科不存在的条目,用两种不同的颜色标注反而很奇怪
- 可以很大程度上节省页面加载速度
- 可以同时链接多个条目,例如:神经胚(英语;俄语)
- 可以直接链接到维基数据项,这在不确定哪个语言的条目质量更高时会显得非常好用:神经胚(其他语言)
- 在不确定条目对应的中文名称时(例如上方提到的没有官方译名的情况),可以只提供维基数据的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)[回复]
- illm是直接以红链显示条目名称,外语版链接是小字下标,我觉得维护上应该没有问题。--BlackShadowG(留言) 2022年3月27日 (日) 23:55 (UTC)[回复]
- illm从视觉上不能分辩伪蓝链,ilh和tsl能,这不利维护。-- 约翰同志-条目裱糊匠(留言) 2022年3月27日 (日) 18:10 (UTC)[回复]
- 上方的讨论混杂了多个问题,大致总结:1.绿链是否影响了编辑和保存性能。2.模板超限是否值得和可能通过消除绿链解决。3.绿链哪些算滥用,是否要有政策限制用法与用量。4.其他模板/显示效果是否比绿链更好。5.绿链是否可能在技术上改进以缓解当前问题。个人声明,我是绿链使用和赞成者,但对向读者提供绿链不置可否,仅赞成它对维基编者(和专业读者)的维护作用。
- 问题1,我认为更多是条目过长或其他脚本(如语法高亮、其他扩展或绿链本身)的因素,绿链至多导致预览结果较复杂而变慢。如果是绿链脚本性能问题,应能进一步优化。
- 问题2,我认为绿链滥用可能存在,但其维护性和说明性作用目前难以替代,单纯移除绿链将影响说明性(对应和查阅相应主题外文条目)或布局变丑(默认显示很长原文或大量存在如(英文)),条目过长、导航模板太多太大等问题同时存在。
- 问题3,值得讨论一些案例和考虑一个指引,限制条目正文中不必要、短期内不会创建条目的绿链。对于导航模板中的绿链,值得单独讨论,影响更大但作用也更大,因其中不能提供上下文介绍。对于“短期内不会创建”的标准,可以基于主题的常见性(很常见而没人建,绿链就可能不太有用),外文条目的热门度(编辑量、浏览量)、新鲜度、条目质量等。
- 问题4,我记得讨论过不止一次,并且数百人投票得出如今的折衷方案,再次争论细节并改变现状可能不现实,但用法和替代品可以讨论和列明。
- 问题5,值得进一步研究,如尽力缩减展开大小或改变当前实现方式。另外有个想法,针对导航模板,是否可以用机器人自动生成不调用模板(亦不检查条目是否存在)的伪绿链版本,作为模板子页面(如/cache),必要时引用它避免占用模板配额。以及也想过将目前绿链各版小工具整合为一个用户前端可切换显示效果的小工具,固定用户因此可能选用更多更理想的展示效果(上面讨论有若干细节),但这需要较多技术资源。--YFdyh000(留言) 2022年4月2日 (六) 05:15 (UTC)[回复]