维基百科:互助客栈/技术/存档/2022年10月


Module:Trim quotes需要模板编辑员更新

模板:Gallery2出错

需要进一步完善{{for}}和{{ITNc}}

ITNc(仅限article参数)和for不支持手工转换语法(-{}-)。--Txkk留言2022年10月1日 (六) 06:43 (UTC)

cewbot机器人

@Kanashimi: 在条目冯仁稚 (72981220)中因为错误的跨语言链接模板{{link-jp}}使用,如 {{link-jp|https://ja.wikipedia.org/wiki/%E5%85%A8%E6%97%A5%E6%9C%AC%E3%83%97%E3%83%AD%E3%83%89%E3%83%AA%E3%83%95%E3%83%88%E9%81%B8%E6%89%8B%E6%A8%A9|全日本プロドリフト選手権|D1 GRAND PRIX}},导致机器人会将 超链接 加入到 Wikidata d:Q5152375 (d:Special:Diff/1666586565/1701690195) 中,不知道是否可以禁止。--Kethyga留言2022年10月2日 (日) 00:46 (UTC)

这应该修改误用,而非留着误用。修改完机器人会按照正确的方式去处理。--Kanashimi留言2022年10月2日 (日) 01:40 (UTC)

参考资料疑似有bug

我发现在2016年高雄美浓地震维冠金龙大楼倒塌事故这两个条目中,有数个参考资料的连结通往网络时光机,而原始内容存档连结却通向真正的新闻网页,不知道还有没有其他条目发生同样状况,请求各位协助。 --Picture GN留言2022年10月2日 (日) 14:59 (UTC)

|dead-url=参数若设为true就会这样。表示当前页面的原始链接已经失效(或对于维护机器人而言无法访问,如网站设置了robots.txt等),并不是技术故障。HotaruTalk 2022年10月2日 (日) 15:12 (UTC)
(~)补充:也可能是设置了access-date参数,这样的话就会用Wayback Machine的页面替换原始页面,保证原始来源在任何时候访问均为一致的,避免原始来源变动造成编辑争议。HotaruTalk 2022年10月2日 (日) 15:15 (UTC)
不过那些网址大部分还没有失效,是不是该处理参数?--Picture GN留言2022年10月2日 (日) 17:45 (UTC)
  吐槽 两种状态并存时我常点错,不得不都点开或者悬停以仔细观察。dead状态的准确率不算很高。--YFdyh000留言2022年10月2日 (日) 16:13 (UTC)

Coolest Tool Award 2022: Call for nominations

The fourth edition of the Coolest Tool Award welcomes your nominations! What is your favorite Wikimedia related software tool? Please submit your favorite tools by October 12, 2022! The awarded projects will be announced and showcased in a virtual ceremony in December.

MediaWiki message delivery 2022年10月3日 (一) 18:30 (UTC)

2022年第40期技术新闻

MediaWiki message delivery 2022年10月4日 (二) 00:23 (UTC)

错误通知

大家好,因为很好奇所以来提问,不晓得有无问错地方、是因为不久前收到了这个通知Special:Diff/73927012,不过这个页面不是我建立的,通知我的使用者也不晓得问题在哪里,自己唯一想到的关联可能是挂了快速删除时重定向被解除?再麻烦看看了,谢谢大家。--Mafalda4144留言2022年10月3日 (一) 14:00 (UTC)

感觉应该是,TW将重定向和非重定向视作两种页面了,也就是将后者视作后来创建的条目。如果{{d}}模板放在第二行使重定向状态保持,可能就不会这样、不会有“移除重定向”标签。--YFdyh000留言2022年10月3日 (一) 19:15 (UTC)
谢谢您了解了,以后(?)还是别假会要交给小工具XD--Mafalda4144留言2022年10月4日 (二) 12:00 (UTC)

关于{{Infobox book}}

2022年第41期技术新闻

2022年10月10日 (一) 14:08 (UTC)

创建账户功能不可用

创建账户功能现在不管输入什么账户名,都说因为技术限制无法注册,这是什么情况,他人可否试试是否也这样。Bluedeck 2022年10月10日 (一) 14:18 (UTC)

这是capitalize,不是无法注册啊0 0 Stang 2022年10月10日 (一) 15:00 (UTC)
哦哦哦,哈哈,没仔细看,谢谢。Bluedeck 2022年10月10日 (一) 15:08 (UTC)

模板cite web 无法正常调用

在条目中使用插入模板>cite web 目前无法正常使用,只能显示源代码


我在下方做出测试
HTML教程. W3school. W3school. [2022-10-08] (中文(中国大陆)). 

在条目中就是这样显示的。

--Te0sla留言2022年10月8日 (六) 12:59 (UTC)

(:)回应
使用下列源代码:
陽光女孩<ref>{{cite web |accessdate=2022-06-30 |language=zh-tw |deadurl=no |url=https://news.campaign.yahoo.com.tw/2022-election/article.php?id=77d7a1e9-5df0-3e29-a100-8431aae6f2a8 |title=認陽光女孩!柯志恩:「側翼攻擊」我9年前在美國置產百坪 |first= |last= |author=鄭佩玟 |publisher=[[三立新聞網]] |date=2022-06-30 |archiveurl=https://web.archive.org/web/20220702011001/https://news.campaign.yahoo.com.tw/2022-election/article.php?id=77d7a1e9-5df0-3e29-a100-8431aae6f2a8 |archivedate=2022-07-02 }}</ref>
可以看到显示这个结果:
测试结果正常,请问是哪个条目发生问题?--CaryCheng留言2022年10月8日 (六) 18:22 (UTC)
这点我也测试到了,只要套上<ref>双标签就能正常使用,但是吗,当我使用可视化编辑器搜索模板cite web,之后调用时不会默认框上<ref>标签。导致显示的效果就是代码完全显示在本来的界面。您可以试一下。 Te0sla留言2022年10月9日 (日) 02:17 (UTC)
这是正常的,cite web模板和<ref>标签是分开的--百無一用是書生 () 2022年10月9日 (日) 02:27 (UTC)
不能正常使用是正常的吗?Te0sla留言2022年10月9日 (日) 04:22 (UTC)
因为你是通过搜索模板插入的,所以会这样。如果是通过“引用”功能插入的就会自动加上<ref>标签了--百無一用是書生 () 2022年10月9日 (日) 07:00 (UTC)
小知识学到了,感谢各位老师。维基百科可真难入门啊。Te0sla留言2022年10月11日 (二) 12:02 (UTC)

Wikipedia:数据库报告/高引用量模板列表 被添加 都道府县 分类

2022年第42期技术新闻

MediaWiki message delivery 2022年10月17日 (一) 21:45 (UTC)

已在Module:No globals添加了替用提醒--百無一用是書生 () 2022年10月19日 (三) 02:11 (UTC)

页面打印的简繁地区词转换

虽然本维已有颇为丰富与充足的转换系统,然而在下载为pdf和打印功能里只能按原始页面打印,不能选择需要的地区字体打印,请问如何解决这个问题?--有困扰的话,就让魔女用魔法帮你排忧吧! 2022年10月19日 (三) 12:10 (UTC)

恭喜你遇到千古难题。传说是因为字词转换机制(或组件、或代码)从设计开始就只适配HTML页面的转换,所以其他渲染方式无法适配,所以功能开不出。其中好像包括了已经放弃的Help:图书功能。——Sakamotosan路过围观 | 避免做作,免敬 2022年10月20日 (四) 01:02 (UTC)
那么能不能采用虚拟建设一些转换好的特殊页面来渲染的办法来解决呢?--有困扰的话,就让魔女用魔法帮你排忧吧! 2022年10月20日 (四) 02:33 (UTC)

关于 Module:Authority_control 的 P640: Léonore编码

根据目前 Module:Authority_control 的页面中,P640: Léonore编码是唯一一个错误 ID 的数量超过十个的参数。具体来说,错误数量是 427,约占使用此参数的条目的七成。不知道有没有考虑参考英语维基百科直接拿掉;或是参考日语维基百科,把原本的 LH/ 正规表示式修改为 LH//,以及增加另外两条正规表示式。--Anghualee留言2022年10月22日 (六) 08:42 (UTC)

{{Portal}} 模板链接至繁体主题名称时会产生重定向

Twinkle更新 (2022-10-23) @335ad8bd

近期变更
  • 关闭存废讨论:按钮移动到.mw-editsection中,版面更加干净,同时避免复制文字时包含此按钮文字。

如果近期变更有任何错误,或是认为未来变更会造成任何问题,请在Twinkle讨论页互助客栈技术版Telegram群组Github择一报告。--Xiplus#Talk 2022年10月23日 (日) 11:50 (UTC)

用户:Chiefwei/rater版评级小工具出现问题

 
界面截图

小工具无法分析专题模板--Evesiesta 2022年10月22日 (六) 14:57 (UTC)

是不是网络问题,测试似乎没什么问题,另外分类 Category:小作品级生物条目 下有很多。--Kethyga留言2022年10月23日 (日) 04:31 (UTC)
不确定,但目前仍然无法使用--Evesiesta 2022年10月23日 (日) 16:29 (UTC)
可以举个例子吗?那个页面挂哪个专题模板出现了问题?--百無一用是書生 () 2022年10月24日 (一) 02:11 (UTC)
我感觉是小工具有问题,因为目前所有页面的所有评级都不能正常进行,显示内容都与图片中显示的类似(错误类型根据具体情况改变)。应该不是某一个专题模板的问题。--Evesiesta庆祝中文维基百科廿周年 2022年10月24日 (一) 02:16 (UTC)
Special:Diff/74223945 works for me.--Xiplus#Talk 2022年10月24日 (一) 03:39 (UTC)
感谢,应该是我本地的问题,镜像可能无法完整回传代码导致小工具不完整,最近先不用了,感谢各位积极回复!--Evesiesta庆祝中文维基百科廿周年 2022年10月24日 (一) 04:08 (UTC)

2022年第43期技术新闻

MediaWiki message delivery 2022年10月24日 (一) 21:22 (UTC)

繁简同名但是不同条目

是否需要列出繁简同名,但是指向了不同条目的组合。绝大多数情况下,繁简应该都指向同一个条目(相同Wikidata数据项)。--Kethyga留言2022年10月21日 (五) 02:52 (UTC)

我觉得可以考虑。见过不少繁简重新导向目标不同的页面。—— Eric Liu 創造は生命(留言留名学生会 2022年10月21日 (五) 06:05 (UTC)
我支持也愿意清理,但不确定谁能帮忙。--回廊彼端留言2022年10月21日 (五) 15:17 (UTC)
感觉第一次建立会比较耗费时间。--Kethyga留言2022年10月21日 (五) 15:21 (UTC)
如果指人工建立,可能过于费时和难以保持维护。应该能编写机器人解决,不确定是否有过。--YFdyh000留言2022年10月21日 (五) 17:30 (UTC)
有解决方案吗?有意参与。--Evesiesta 2022年10月21日 (五) 15:23 (UTC)

指向不同条目有造成使用上的困难吗?有没有可能 it's a feature, not a bug. 简体字和繁体字使用者,因为地区词差异或是接触频率不同,有可能在使用同一个词的时候,其实指的是不同的东西。例如搜寻“编码”的人可能想找的是程序设计,但搜寻“編碼”的人则较可能想找字元编码。--C9mVio9JRy留言2022年10月22日 (六) 15:40 (UTC)

User:C9mVio9JRy您说的有理,不过我也确实看过不少混乱状况。例如说黃岩黃巖本来都指向黄岩区,后来黃岩被改成消歧义页但黃巖没跟上,我发现、修复已经是两年多后的事了。整体来说还是建议先有个机器人列出所有类似状况,再由人工一一检视应不应该合并,或者重定向到同个目标。--回廊彼端留言2022年10月22日 (六) 16:41 (UTC)
很多年前Liangent有搞过。--GZWDer留言2022年10月22日 (六) 19:19 (UTC)
Wikipedia_talk:繁简处理/档案11#“简单的”繁简重定向的创建与删除问题--YFdyh000留言2022年10月22日 (六) 19:53 (UTC)
现在对于繁简重定向似乎没有之前的删除一说了?--Kethyga留言2022年10月26日 (三) 11:06 (UTC)
感觉9mVio9JRy说的应该需要消歧义来处理吧。--Kethyga留言2022年10月29日 (六) 16:23 (UTC)
您所指的问题确实是有可能发生。建立一个清单,或许比较有助于厘清各种情况。—— Eric Liu 創造は生命(留言留名学生会 2022年10月22日 (六) 20:25 (UTC)
刚刚发现繁简同名不同条目:“马格里”(法语:Magrie法国奥德省的一个市镇)跟“馬格里”(Sir Halliday Macartney,清朝后期的一名涉中英国爵士)-- Matt Zhuang表示有事按“此”留言 2022年10月25日 (二) 04:33 (UTC)
前者已移动至“马格里 (法国)并且将该简体重定向给WP:R7(前者目前改繁简重定向至后者),有待确认双方的链入页面是否正确。-- Matt Zhuang表示有事按“此”留言 2022年10月25日 (二) 05:03 (UTC)

语言代码问题

最晚在2021年底MediaWiki的程式码中已经建议把zh-tw改成较精准的zh-Hant-TW,其他几种中文变体也是,但目前CS1系列模板尚不支援后者这种写法,是否应该新增到模组当中?又按这篇程式码来看,要调整的使用者语言模板、分类等等很多,甚至其他维基计划也需修改,希望各位一起处理,谢谢。--回廊彼端留言2022年9月25日 (日) 03:43 (UTC)

(+)支持:但这工作量看起来不小。--冥王欧西里斯留言2022年10月4日 (二) 09:02 (UTC)
要处理的东西可能不少。—— Eric Liu 創造は生命(留言留名学生会 2022年10月12日 (三) 12:25 (UTC)
超过7日无新留言,在此公示7日,公示内容为“按MediaWiki的程式码,增加CS1系列模板对zh-Hans-CN、zh-Hans-SG、zh-Hans-MY、zh-Hant-TW、zh-Hant-HK、zh-Hant-MO等语言代码的支援”。
至于工作量的问题没办法,得靠大家一起努力了,至少可以先从中文维基各计划开始。--回廊彼端留言2022年10月20日 (四) 14:47 (UTC)
会不会快了些?只有3人发言就公示?--唔好阻住我爱国留言2022年10月22日 (六) 14:14 (UTC)
不过是(+)支持的。加油!--唔好阻住我爱国留言2022年10月22日 (六) 14:15 (UTC)
User:HK5201314谢谢您的支持,这提议说大不大、说小不小,放在这边快一个月了讨论量就这样;又目前现有公示规定并未规范参与讨论、或者支持的人数,所以我就直接公示了。比较冷门的议题恐怕都很容易遇到这种状况。--回廊彼端留言2022年10月22日 (六) 15:18 (UTC)
支持各处兼容。旧有内容的调整更新我认为应慎重,没有把握的都不作改动、保留原貌。--YFdyh000留言2022年10月22日 (六) 17:52 (UTC)

7日已过,“按MediaWiki的程式码,增加CS1系列模板对zh-Hans-CN、zh-Hans-SG、zh-Hans-MY、zh-Hant-TW、zh-Hant-HK、zh-Hant-MO等语言代码的支援”提议通过,谢谢各位参与。--回廊彼端留言2022年10月29日 (六) 17:34 (UTC)

其他兼容问题

需要进行哪些处理以达到兼容?--BlackShadowG Slava Ukraini! 2022年10月25日 (二) 11:43 (UTC)
User:BlackShadowG,CS1模组中文最常用的部分如上,此外同分程式码还有提到下面这些,我这边只写还需要改的:

已弃用语言代码 → 取代者 (Phabricator案号,CS1测试结果)源代码网址

  • 'als' => 'gsw', // T25215,都只显示原代码
  • 'bat-smg' => 'sgs', // T27522,前者显示萨莫吉希亚语,后者只有原代码
  • 'fiu-vro' => 'vro', // T31186,都只显示原代码
  • 'roa-rup' => 'rup', // T17988,都只显示原代码
  • 'zh-classical' => 'lzh', // T30443,前者显示文言,后者原代码
  • 'zh-min-nan' => 'nan', // T30442,前者显示闽南语,后者原代码
  • 'zh-yue' => 'yue', // T30441,前者显示粤语,后者原代码

不标准的语言代码 → 取代者 (Phabricator案号,CS1测试结果)源代码网址

  • 'cbk-zam' => 'cbk', // T124657,都只显示原代码
  • 'de-formal' => 'de-x-formal', // 前者显示German (formal address),后者原代码
  • 'eml' => 'egl', // T36217,都只显示原代码
  • 'en-rtl' => 'en-x-rtl', // 都只显示原代码
  • 'es-formal' => 'es-x-formal', // 前者显示Spanish (formal address),后者原代码
  • 'hu-formal' => 'hu-x-formal', // 前者显示Hungarian (formal address),后者原代码
  • 'map-bms' => 'jv-x-bms', // T125073,都只显示原代码
  • 'mo' => 'ro-Cyrl-MD', // T125073,前者显示Moldovan,后者原代码
  • 'nrm' => 'nrf', // T25216,都只显示原代码
  • 'nl-informal' => 'nl-x-informal', // 都只显示原代码
  • 'roa-tara' => 'nap-x-tara', // ,都只显示原代码
  • 'simple' => 'en-simple', // 都只显示原代码
  • 'sr-ec' => 'sr-Cyrl', // T117845,前者显示Serbian (Cyrillic script),后者原代码
  • 'sr-el' => 'sr-Latn', // T117845,前者显示Serbian (Latin script),后者原代码。--回廊彼端留言2022年10月29日 (六) 17:34 (UTC)

{{}}{{}}的空格问题

最近,有用户搞出来了{{nsref}}这种愚蠢的模板,结果搞到夏朝这个条目在我没修正之前,页面不到一半就超出模板上限(现在还没好呢)。其实要修这个问题根本不需要搞得这样麻烦,只需要建立MediaWiki:Cite link label group-参将参1到参1000抄一次就好了。效果见此,[18][19]。众所周知,模板是有模板上限的,所以根本上不要花费贵重的模板资源,也不需要每个条目每个条目去修也能解决这个问题。所以根本不需要依靠{{nsref}}这种花费资源的模板。当然,个人不认为Wikipedia:格式手册#空格这个指引可以管{{}}{{}}这种系统性的问题,系统的问题本就应该例外于指引。而且即使要修,其实也最好也应该乖乖地等工单,而不是直接用字词转换的方式来修。所以在此请求社群的意见:

参见Template_talk:RefTag#请移除空格。--Ghren🐦🕙 2022年10月15日 (六) 14:13 (UTC)

直接建立MediaWiki:Cite link label group-参会产生问题:万一需要有空格的“[参 x]”的时候,将不能透过“{{#tag:ref|參文|group=參}}”取得(纵使有空格的是不符指引,但难以排除某些场合有IAR的需要)。若要以“系统的问题”作为例外的理由,我认为要有技术上完全没有办法达成的前提,若技术上有办法的话,“系统的问题”则不应成为理由。“而且即使要修,其实也最好也应该乖乖地等工单”←但是Phabricator那边自2013年提出这个问题之后,等到现在都还给不出方案的话,真的还该等下去吗?--街燈電箱150號 开箱维修 抄表 检验证明 2022年10月15日 (六) 18:44 (UTC)
倒不如这样说,假如工单过了,系统层面上有可能保留[参 x]和[参x]两个情况同时出现的方法嘛?虽说工单还十划未有一撇,我感觉也不太可能。--Ghren🐦🕛 2022年10月16日 (日) 04:58 (UTC)
依照Phabricator的请求内容,当年原本打算在<ref>增设一个参数让人设定显示或不显示空格,所以如果成事,[参 x]和[参x]都能出现。可惜他们就是搞了几年也搞不出来……--街燈電箱150號 开箱维修 抄表 检验证明 2022年10月16日 (日) 13:20 (UTC)
如果不考虑打印版、禁用JS等特殊情况,站内做个小工具怎样(移动版也能用),打印版可能也能。“万一需要有空格”真实存在吗,如果存在但非常稀少,也可考虑小工具方案解决。--YFdyh000留言2022年10月16日 (日) 13:54 (UTC)
现在的可打印版似乎直接调用打印?如果照顾下载PDF和打印功能,“需要有空格的”用另一套模板或标识符+小工具就可以吧。小工具方案则没难度。--YFdyh000留言2022年10月16日 (日) 14:16 (UTC)
那假设做完出来,只怕也不好修本站的参注问题啊。--Ghren🐦🕙 2022年10月16日 (日) 14:30 (UTC)
旧有用法最好还是保持着旧有的显示方式,新的显示方式应该在新模板呈现;将新旧用法和显式互相倒置,出错的风险其实难以估计。这也之所以为什么在Phabricator是请求增加参数而不是请求把默认的显式改为无空格,做小工具只不过是以另外一种形式把旧用法变成新显式而已,前述的风险还是会有的。--街燈電箱150號 开箱维修 抄表 检验证明 2022年10月16日 (日) 15:10 (UTC)
我宁可一劳永逸的小工具,也不愿意相信这个模板。这个模板是很巧妙,但是嘛只是将“空格+数字”转换成“数字”,然后还玩了些span标记的特性(如果我没理解错的话),我是看不出来说这种修复方式的风险很低。--Ghren🐦🕛 2022年10月16日 (日) 16:37 (UTC)
具体风险是什么。小工具可以试行(包括先局部启用)、注册用户可以关闭,比模板风险更低。--YFdyh000留言2022年10月16日 (日) 17:19 (UTC)
小工具不应该拿去掩盖载入完成后事实上没有符合指引的显示式样,当小工具被关了或者加载失败,不合规的显示式样还是会露馅,要是能够让人关闭的话就已经失去了强制无空格的意义,所以并不可取。--街燈電箱150號 开箱维修 抄表 检验证明 2022年10月16日 (日) 17:53 (UTC)
“强制无空格的意义”如果真的那么大、要求严格,就不会拖这么多年了。千分或万分之一的未覆盖情况,我认为至少可作为过渡方案。持续拖下去,只能让留有空格成为事实标准。如果模板实现完美,本议题应该不会出现?--YFdyh000留言2022年10月16日 (日) 18:53 (UTC)
拖这么多年我想并不是因为强制的意义不够大,而是Phabricator里没有人明白中文的独特语境而已。还是这一点:小工具事实上只是载入了后把违规屏蔽,而没有真正做到载入之前把违规修复,而且这种屏蔽却具有可选择性(可以让人关闭),那更遑论符合规则。新模板我当然不敢说完美,惟可在更换的过程中渐渐发现问题并加以改善。--街燈電箱150號 开箱维修 抄表 检验证明 2022年10月16日 (日) 19:38 (UTC)
载入后修复和载入前修复两种情况本质上没有分别。可选择性也和符合规则无关。咱是希望您解决问题,不是谈这种没意义的哲学问题。载入前修复从读者还是编者角度根本看上去,编上去也是一样。咱只要不开字词转换,“不合规的显示式样还是会露馅”。又或者只要我想,工单过了也可以写个工具让他强行变有空格。那难道说也不合规则。--Ghren🐦🕚 2022年10月17日 (一) 03:38 (UTC)
解决问题本来就要注重背后的哲学机理,而不能只看表面啊!--街燈電箱150號 开箱维修 抄表 检验证明 2022年10月29日 (六) 15:58 (UTC)
解决问题重要的是考虑形而下的问题,然后才是形而上的问题。一个问题如何解决,解决之后会有什么影响,需要多少时间修,这是形而下;在什么层面上修,修完了会否带来逻辑上的不同,这是形而上的问题。形而上的问题可能会引致形而下的问题,但是如果形而上的问题不会带来问题,那就不是问题。所以我就说载入前修复和载入后修复是一样的,因为这是形而上的。硬是要说这是一个问题,那我一开始提出的方法是最好的,因为这直接在系统底层解决问题。问题是话不能这样说。Ghren🐦🕚 2022年10月30日 (日) 03:40 (UTC)
有否想过如果工单最终只弄参数而不再做默认消除,之后要怎样做的问题?所以这不可能说形而上没有问题就说了算。而您一开始提出的方法我在上面和有人下面说了会有什么问题,不重复。--街燈電箱150號 开箱维修 抄表 检验证明 2022年10月30日 (日) 04:14 (UTC)
如果之前的工单本地没人跟进,拖成这样倒也很正常。况且,中文排版本来就长期缺少一部全面、权威的标准,哪怕限于某个地区的都没有,Phabricator的人想找参考也找不到。实在要说明的话,先引用一下en:Text segmentation#Word segmentation之类的条目简单说明中文词间不用空格,针对与数字混排的情况可能只能用中英对照的《中文排版需求》的横排的中、西文混排配置一节,还需要说明本地维基选择不破坏语义、等待CSS方法实现标准所要求的字距(spacing)。--DvXg 📬 2022年10月17日 (一) 18:19 (UTC)
能不能去把phabricator那边的priority调高?可以跟他们说这是中文语言使用上的重要需求,目前写死的规则对中文使用者造成系统性的不利,并且九年来都没有补充这个功能已经造成中维上的编辑出现各种混乱的替代方案,特别影响到汉文化相关条目的编写。--C9mVio9JRy留言2022年10月19日 (三) 07:30 (UTC)
Hmm,原issue其实是提出要给<ref>加一个参数用来去掉空格,给的例子是“A 1”→“A1”,当时可能是想搭这个issue的车而有人在下面提了中维的需求,但不想原issue久未解决。私以为中维的诉求应当另开issue,毕竟这项修改应当是全局的(面向所有汉语族语言的维基计划 or 所有使用汉语族语言的MediaWiki站点),技术上PHP下可以通过\p{Han}$正则匹配分组名来辨别何时需要去掉空格,如果MW开发组方面能指出需要修改的代码位于何处(本地大概没人熟悉MW软件本身?),修改应当还是相对容易的。但问题还是在于本地社群需要有人去推进。--DvXg 📬 2022年10月19日 (三) 15:59 (UTC)
  • 空格应该去掉,毕竟是直接在正文中显示的东西,能更符合指引的话当然最好。另外,特别是当几个注脚连续一起出现的时候,显示为“[注 10][参 23][书 54]”我认为很累赘,能改为“[注10][参23][书54]”当然好得多。既然现在有现成的方法去修的话,没必要等了9年之后还在等,9年都没有解决方法真的不用期待还会有什么下文。至于MediaWiki:Cite link label group-参就不建议,这会造成其它汉字有空格而唯独“参”字没有空格,默认用法中突然跑出一个特例并不理想。况且,看见夏朝已经被修正了,似乎已经出现了减少模板资源的方法。--Maccomcre留言2022年10月16日 (日) 04:13 (UTC)
    所以就{{}}{{}}用建立MediaWiki:Cite link label group的方式解决,其他您可以用他{{nsref}}一套搞到没有空格。夏朝那虽是修正,但是您得看看现在{tl|nsrefc}}还是有2501个call,占整页86.99%。当然,就算用来本身参注系的模板,也是近2000个call。要是不将模板分出来,用回NoteGR、RefGT,只怕不止三千个call。参注方式这样个常用,为什么非得花这样多的资源不可,是怕将来不报错吗。--Ghren🐦🕐 2022年10月16日 (日) 05:15 (UTC)
    空格具有语义,确实应当去掉,但含有空格的模板在显示上反而是符合排版常规的,“累赘”不见得。只是现时CSS还尚不支持汉字与西文汉字间自动调整字距(CSS Text 4 text-spacing,仍停留在草稿且未有实现)。
    另外,这样的“修复”方法也太不符合工程学常规了:底层的问题在上层解决,既开销大又给未来彻底解决埋坑。--DvXg 📬 2022年10月16日 (日) 08:01 (UTC)
    累赘与否属主观评价,难以作准;我在意的是那个空格不符文法,正如您所说空格具有语义那般,在我而言只要是不合文法的话即使多么美观也是看不顺眼。坦白说,我们一早就知这种问题其实应该在底层解决,不过早在2013年已经把问题交给底层去搞,自己就躺着什么都不做,但结果呢?底层一搞就搞了差不多十年都还是没有搞定。那么上层有方法那都要先用着,而不是把问题放任至不知何时何日,尤其是完全看不到底层那边有心去处理。--街燈電箱150號 开箱维修 抄表 检验证明 2022年10月16日 (日) 13:20 (UTC)
    没错,这样的修法我觉得不如狗皮膏药。--Ghren🐦🕙 2022年10月16日 (日) 14:35 (UTC)
    “这会造成其它汉字有空格而唯独“参”字没有空格”:那需要空格的时候将街灯的做法反向做一次就好了。不过我是不太建议啦。--Ghren🐦🕙 2022年10月16日 (日) 14:31 (UTC)
    我认为<ref group=汉字>应该全体都有空格,而{{nsref|group=汉字}}应该全体都没有空格,两条队列应当分明,不应该<ref group=汉字>全体有空格而同时<ref group=参>又没有,弄成跟{{nsref|group=参}}同一个外表。而且测试效果显示<ref group=参>和{{nsref|group=参}}是不同组的,把两者都弄成没有空格只会令编辑者更容易出错,所以更不应该搞MediaWiki:Cite link label group-参。--Maccomcre留言2022年10月16日 (日) 15:58 (UTC)
    是的,理论上当然是统一最好,但是<ref group=汉字>常用的情况都在{{}}{{}}两个模板,当然我记得也有其他地方有用,只是用的不多。既然用的人多,编辑者容易出错这个概念不能说没有,我只是感觉比编者将两个模板搞混更难出现。--Ghren🐦🕛 2022年10月16日 (日) 16:17 (UTC)
    要是把{{nsref|group=其它字}}和<ref group=参>搞得都是没有空格的,同一个条目出现了两种语法但显示一样的效果,不会搞混才怪。虽然用其它字是比较少见但不觉得少到微不足道的程度,所以还是不应该搞MediaWiki:Cite link label group-参来把参字变成例外的不同。<ref group=xx>倒应该不论任何时候都要有空格,能避免开例外的就应该要避免。--Maccomcre留言2022年10月23日 (日) 09:54 (UTC)
用转换模板比较好,不应该开小工具。转换是在服务端处理,是把空格消除了后才传给用户端,那在用户端时肯定已经消除了空格,不用顾虑用户端的浏览环境;小工具是在空格传到用户端后再载入脚本对空格进行修饰性的消除,那就要考虑用户端的问题了,例如载入问题,如果用户在连线环境比较差的地方浏览,会有载入了条目但没有载入小工具的机会,这时就消不了空格,这种事情并不是少见,尤其是WiFi浏览或者用VPN都不难遇到的事情。考虑可用性比开销效能更为重要。--Opky9407留言2022年10月25日 (二) 11:59 (UTC)

2022年第44期技术新闻

MediaWiki message delivery 2022年10月31日 (一) 21:15 (UTC)