萌娘百科 talk:讨论版/技术实现/存档/2021年08月
讨论版【技术实现】档案馆
关于 "页面编辑" 中 “小编辑” 和 “摘要” 的相关疑问
请问萌娘百科的页面编辑在提交更改后是否还能补写摘要以及勾选或取消勾选“小编辑”?如果不行的话,请问是否考虑增加这个功能? 有时候个人编辑页面过快往往会导致少写摘要甚至漏写摘要以及真的是微小的编辑但实际上却忘记标记“小编辑”的情况(每次事后发现自己有忘勾“小编辑”,总觉得有负罪感QwQ),这样也可能会给其他的编辑者增加一些本可以避免的工作量或麻烦。 --马鸽(讨论) 2021年7月28日 (三) 13:49 (CST)
- 这个是mw的问题吧……目前来讲没有方法。--EnMGP编辑者乐然 ✉ 编织希冀,寄于歌声。 2021年7月28日 (三) 14:02 (CST)
- 提交后MW会将编辑保存为一项不可更改的历史记录,目前没有系统内更改摘要、更改记录性质和内容的功能。萌百基于MediaWiki,后者没有这个功能意味着萌百对增加此功能无能为力,若有强烈需求建议向维基媒体基金会提报。不必在摘要和小编辑的问题上苛责自己,不过若能尽善尽美那便是最好的。非常感谢您对萌百做出的贡献!--サンムル(讨论) 2021年7月28日 (三) 14:09 (CST)
- 可以在Special:参数设置里默认全部标记为小编辑。Z E S 2021年7月29日 (四) 17:19 (CST)
- 我其实不建议这么做……
如果我没记错的话,小编辑不需要手动标记巡查。万一改动比较大的编辑被标记为了小编辑,可能会有逃避巡查的嫌疑。--OIer乐然 ✉ 编织希冀,寄于歌声。 2021年7月29日 (四) 17:27 (CST)- 这样啊……因为我是滚动的天空Wiki自动巡查者所以就没在意这一点……-Z E S 2021年7月30日 (五) 12:30 (CST)
- 就算你是中文维基百科的管理员,在萌娘百科浏览、编辑也得遵守萌百的基本法。--94 42 233 2001-8 J-JRE(Discussion) 2021年7月30日 (五) 12:58 (CST)
- 貌似不是。But what I said still stands, 小编辑本来就是给修正笔误这种无足轻重的编辑准备的,滥用小编辑功能同样是会被警告的。--EnMGP编辑者乐然 ✉ 编织希冀,寄于歌声。 2021年7月30日 (五) 13:11 (CST)
- 这样啊……因为我是滚动的天空Wiki自动巡查者所以就没在意这一点……-Z E S 2021年7月30日 (五) 12:30 (CST)
- 我其实不建议这么做……
强烈建议贵站向一部分活跃编辑的常用IP或IP段发放WAF豁免权限
此为#关于萌百是否仍在遭到攻击和是否可以在一定程度上放宽WAF相关限制的讨论的后续讨论。
在该讨论串曾有人建议按用户组别放宽WAF限制,但因为WAF由IP进行判定,所以在技术上根本不可能实现。那是否可以向一部分活跃编辑的常用IP来有选择地进行拦截?我现在都被WAF(当然也包括无法跳转的拼图验证)搞吐了。--北湖3(讨论) 2021年7月28日 (三) 17:59 (CST)
巡查都没这个待遇.jpg
貌似现在只有机器人可以获得IP豁免权来着(——东方众 一位史蒂夫 (讨论·贡献)✉❶ 请问您要单推一只小浣熊吗? 2021年7月28日 (三) 18:01 (CST)- 🤖可以的话是不是理论上别的也可以?--布洛肯亚雷的反锑研究所(研究成果/找他一同研究) 2021年7月28日 (三) 18:02 (CST)
- Possible, but not feasible. ——拒绝互膜的
M. J. H. 【睽】{{#forargs:}} is evil! 2021年7月28日 (三) 18:06 (CST)
- Possible, but not feasible. ——拒绝互膜的
- 🤖可以的话是不是理论上别的也可以?--布洛肯亚雷的反锑研究所(研究成果/找他一同研究) 2021年7月28日 (三) 18:02 (CST)
- 据我所知,目前运维没有将IP豁免权开放给自然人用户的打算,即便是机器人也只是个别申请。--工具人乐然 ✉ 编织希冀,寄于歌声。 2021年7月28日 (三) 18:04 (CST)
- 站在我个人的角度说,我认为开放这件事情本身也不现实,毕竟我们不知道谁是攻击者。目前只能通过尽量限制请求数量等手段预防WAF。--工具人乐然 ✉ 编织希冀,寄于歌声。 2021年7月28日 (三) 18:06 (CST)
- ( ¡ )题外话 那攻击者还可能找到吗?--布洛肯亚雷的反锑研究所(研究成果/找他一同研究) 2021年7月28日 (三) 18:10 (CST)
- 事实上没有人知道。就算是最近,在WAF强度大幅提升的情况下,我们还发现了一个在页面内埋恶意代码的用户。我只能说,近期内应该不会有撤销WAF的打算。--工具人乐然 ✉ 编织希冀,寄于歌声。 2021年7月28日 (三) 18:13 (CST)
- ( ¡ )题外话 那攻击者还可能找到吗?--布洛肯亚雷的反锑研究所(研究成果/找他一同研究) 2021年7月28日 (三) 18:10 (CST)
- 站在我个人的角度说,我认为开放这件事情本身也不现实,毕竟我们不知道谁是攻击者。目前只能通过尽量限制请求数量等手段预防WAF。--工具人乐然 ✉ 编织希冀,寄于歌声。 2021年7月28日 (三) 18:06 (CST)
- 活跃编辑的常用IP并不意味着不是攻击者的IP,毕竟出口IP并不是和机子一一对应的。不过话说回来,有没有什么办法评估一下放开活跃编辑的常用IP到底会有多大的可能性导致把攻击放进来呢?……大概没什么好办法…… ——拒绝互膜的
M. J. H. 【蛊】{{#forargs:}} is evil! 2021年7月28日 (三) 18:08 (CST)- (&)建议 可以主动申请,而且申请者必须是优编甚至维护组成员。--北湖3(讨论) 2021年7月28日 (三) 18:11 (CST)
- 申请者是什么和同一IP的其他用户是什么并不相关,所以这样的限制恐怕也无法解决问题。——拒绝互膜的
M. J. H. 【豫】{{#forargs:}} is evil! 2021年7月28日 (三) 18:13 (CST) - 动态IP分配申请了也是白瞎。——饭团人 一位史蒂夫 (讨论·贡献)✉❶ 请问您要单推一只小浣熊吗? 2021年7月28日 (三) 18:14 (CST)
- 这件事不是权限体系能够决定的。先不说“攻击者竟在我身边”这种极端情况,如MJH所说,按照用户判断IP不可靠,这是IP封禁给我们的教训。--工具人乐然 ✉ 编织希冀,寄于歌声。 2021年7月28日 (三) 18:15 (CST)
- 申请者是什么和同一IP的其他用户是什么并不相关,所以这样的限制恐怕也无法解决问题。——拒绝互膜的
- (&)建议 可以主动申请,而且申请者必须是优编甚至维护组成员。--北湖3(讨论) 2021年7月28日 (三) 18:11 (CST)
建议使用移动版,可有效缓解waf带来的问题。—— ほしみ 2021年7月28日 (三) 19:46 (CST)
- (-)弱反对 我都用电脑了不就是为了解决web版的一系列固有缺陷的吗?
请不要说这种“老鼠给猫挂铃铛”式的“正确的废话”--北湖3(讨论) 2021年7月28日 (三) 20:01 (CST)- 那么这里可能您只能进行取舍了,或是如前面其他人所说,自行更换ip。—— ほしみ 2021年7月28日 (三) 20:08 (CST)
- “web版”这个说法有点奇怪…… ——拒绝互膜的
M. J. H. 【离】{{#forargs:}} is evil! 2021年7月29日 (四) 09:21 (CST)
求助:navbox怎么实现自动折叠啊———DARKNESSⓄ讨论 2021年7月29日 (四) 20:12 (CST)
- @DARKNESS117 可以使用{{Navbox}}的
state
参数:|state = {{#ifeq:{{{1}}}|collapsed|mw-collapsible mw-collapsed|mw-uncollapsed}}
,调用模板时使用{{模板名称|collapsed}}
即可折叠。 - —— GuoPC「昨日より 明日より 今を作り出そう!」 2021年7月29日 (四) 20:26 (CST)
- 请问具体是什么navbox呢?——饭团人 一位史蒂夫 (讨论·贡献)✉❶ 请问您要单推一只小浣熊吗? 2021年7月29日 (四) 20:27 (CST)
谢谢,问题已经解决了———DARKNESSⓄ讨论 2021年7月29日 (四) 22:17 (CST)DARKNESS117
关于本站搜索
在站点内所有页面右上角的搜索框中搜索以“#”开头的字符时不会开始搜索,而是链接到类似https://zh.moegirl.org.cn/Mainpage#***的页面中,是属于本站在使用过程中导致的问题还是MediaWiki本身问题,能否解决?--来自NE-Fengyun(我的讨论页) 2021年7月28日 (三) 18:30 (CST)
- 老问题了吧……(MW出来挨打)——饭团人 一位史蒂夫 (讨论·贡献)✉❶ 请问您要单推一只小浣熊吗? 2021年7月28日 (三) 18:31 (CST)
- 不是bug,是特性(—— ほしみ 2021年7月28日 (三) 18:58 (CST)
- 试了一下在搜索内容内容前加
~
(即搜索~#XXX
)的方法依然可以强制搜索(参见Help:高级搜索#符号),不过搜索结果似乎和“#”无关。话说回来是什么需求需要搜索“#”开头?——C8H17OH(讨论) 2021年7月28日 (三) 20:21 (CST)
- 不是bug,是彩蛋(——新たな世界を見せてあげよう!(讨论) 2021年7月29日 (四) 15:19 (CST)
关于Template:欢迎的一系列问题
去年2月,User:850710247liu创建了与{{welcome}}类似的{{欢迎}},但此模板存在较为严重的问题,故在此发起讨论停用或改进此模板。
- 此模板创建者擅自调用了only for Help:沙盒/首页的widget:沙盒/首页;
- 此模板内置{{目录右置}},且会强显目录,相当于排版他人讨论页,违反MGP:讨论区管理方针之规定;
- 此模板在MacOS Chrome等浏览器下,屏幕显示比例为100%(大于85%)时出现排版异常,超出界面,造成了较差的用户体验,多人可稳定复现此问题。
—— ほしみ 2021年8月5日 (四) 12:46 (CST)
- 针对第三条问题,我可以复现。我认为如果只是希望调用相关CSS,应使用templatestyles而非调用整个widget。并且除开margin,模板所带来的其他排版问题(例如float等)也使我认为重构该模板会比较合理。--EnMGP编辑者乐然 ✉ 编织希冀,寄于歌声。 2021年8月5日 (四) 12:56 (CST)
这个模板有点老了,我都快忘了,而且已经有新代码了,我一直没弄过来,晚上我试着改上去重构一下吧。--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 13:12 (CST)
- 此模板嵌入较多,最好先在沙盒进行测试,以免修改后再次违反MGP:讨论区管理方针之规定哈。—— ほしみ 2021年8月5日 (四) 13:36 (CST)
- 感谢提醒--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 15:28 (CST)
完成,萌百部分页面可能还有缓存,刷新成最新页面就可以看到上面三个问题已经全部解决,模板重构完成--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 16:19 (CST)
JaMGP Help
Hello. The character page on Japanese Moegirlpedia has an error... the birthday and zodiac sections are not being displayed correctly because there is an error inside the Lua Module. LiaMinina(讨论) 2021年8月5日 (四) 22:47 (CST)
- @LiaMinina I've temporarily fixed the problem, the parameter "誕生日" (birthday) should be in "Nov. 17" format, and "星座" (zodiac) should be in "{{Astrology|11|17}}" or "さそり座" format. -- GuoPC ☕ 📝 2021年8月6日 (五) 08:39 (CST)
- @GuoPC Okay, I've set the parameters. It looks good so far, thank you!
LiaMinina(讨论) 2021年8月7日 (六) 20:46 (CST)
关于在div中使用background-image的问题
目前CSS属性background-image
还是处于被封禁状态。
这个东西还是很常用的,如果配合其它的background-
开头的属性可以做出很多以前需要用各种绝对定位和相对定位才能做到的效果。我能理解封禁是出于跨站请求不安全的因素,那是否能将链接限制在共享站以内,只在参数提供文件名,用{{filepath:...}}
来获取链接?
既然模板空间和主空间都无法使用的话,Widget空间可不可以?-- printf("Hello, world!\n");
(查 · 论 · 编) 2021年8月7日 (六) 17:05 (CST)
- Widget可以写纯HTML,当然可以。--Func(讨论·贡献) 2021年8月7日 (六) 17:10 (CST)
- 近期有做这个的计划吗?--
NSLog(@"Hello, World!");
(查 · 论 · 编) 2021年8月7日 (六) 17:22 (CST)
- 近期有做这个的计划吗?--
<templatestyles src="..." />
—— Ant 1597 { 論 | 獻 | 志 } (回覆時請@我
, 感謝.) 2021年8月7日 (六) 17:21 (CST)- 要通用的模板。--
writeln('Hello, world!');
(查 · 论 · 编) 2021年8月7日 (六) 17:25 (CST)- 嗯,模板樣式表只能通過選擇器和靜態
url(...)
實現,屬於權宜之計。如果要靠正文代碼中的輸入 URL 來渲染背景的話,只能考慮使用 Widget 製作模板或者更改 sanitizer 規則了。—— Ant 1597 { 論 | 獻 | 志 } (回覆時請@我
, 感謝.) 2021年8月7日 (六) 17:33 (CST) - Templatestyles可以在后台白名单url地址,我记得运维之前已经改过了。inline的我目前还没找到相关文档,不知道有没有方法能够直接介入服务器端的sanitise过程……--酒姬民乐然 ✉ 编织希冀,寄于歌声。 2021年8月7日 (六) 17:34 (CST)
- 看来url是hardcode在sanitizer里了。这样的话可能只能靠widget实现……--OIer乐然 ✉ 编织希冀,寄于歌声。 2021年8月7日 (六) 17:40 (CST)
- 嗯,模板樣式表只能通過選擇器和靜態
- 要通用的模板。--
Widget扩展由于和新版本MW兼容性不好,站内大多Widget得改版,到时候是否会继续使用该扩展还不可知。(虽然升级事宜还没有看到迹象()--Func(讨论·贡献) 2021年8月7日 (六) 17:53 (CST)
- 那我先写一个吧,升级那是以后的事,到时候再解决。
写好了at你。--disp('hello world!')
(查 · 论 · 编) 2021年8月7日 (六) 18:00 (CST)
Widget_talk:背景图片区域 试做了一个,等通过。-- Transcript show: 'Hello, world!'
(查 · 论 · 编) 2021年8月7日 (六) 20:49 (CST)
- 撤销请求吧,我找到了另一种不用Widget就可以实现的安全方法,已经做成同名模板了。--
PRINT "Hello, world!"
(查 · 论 · 编) 2021年8月7日 (六) 23:25 (CST)
關於引號的轉換
繁體的「」、『』與簡體的“”、‘’是對應關係,但是在萌百好像不會正確轉換,是有什麼原因嗎?—— Eric Liu(留言) 2021年8月3日 (二) 12:11 (CST)
- 日语的『』除了当单引号‘’用,还用作书名号《》。不知道和这个有没有关系。▘▗ ▚ あめろ 讨论 2021年8月3日 (二) 12:37 (CST)
- 除日语中使用外,在内地,按现行GB/T 15834-2011《标点符号用法》,直角引号也属于规范符号,常用于竖排文本。—— ほしみ 2021年8月3日 (二) 12:40 (CST)
希望引入维基百科的大字体小工具
比较在世面上流行的主要网站,萌娘百科条目正文的字号似乎有点小了,尤其是在长篇条目中,小字号比较费眼睛,可能会使部分用户在阅读时产生疲惫感,建议引入维基百科的大字体小工具([1]),这个工具使维基百科条目正文的字号保持在了0.938rem。--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 09:47 (CST)
- @AnnAngela--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 10:06 (CST)
- 不论是Chrome还是Firefox都均有缩放功能,都可以按照不同域名分别设置缩放大小。_USER:YOONHA~1.PAR(留言)2021年8月5日(木)11:39:58(JST)
- (▲)如YOONHA~1.PAR所述,没有必要,也无需默认开启,看不清的人可以自行放大或写入个人css。以及,editfont的13px和大字号的13.936px也没差多少吧。—— ほしみ 2021年8月5日 (四) 10:52 (CST)
- 姑且问一句你是否知道“em”这个单位是什么意思。 ——拒绝互膜的
M. J. H. 【大壮】{{#forargs:}} is evil! 2021年8月5日 (四) 10:55 (CST)- 是可以手动调的,但用户从其他网站第一次进入本站可能就会有一种电脑突然变大了的突兀感。。。--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 11:05 (CST)
- 大小剧烈变化的插入,可能会使视觉信号受到一定程度上的刺激,间断用户的网络沉浸式体验--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 11:09 (CST)
It's super 新名词儿 time!用户的网络沉浸式体验
- 不过,Maya看了看自己现在打开着的几个网站,bilibili评论区字号是14px,必应搜索结果的字号是13px,所以姑且好奇一下您说的“在世面上流行的主要网站”是什么。 ——拒绝互膜的
M. J. H. 【颐】{{#forargs:}} is evil! 2021年8月5日 (四) 11:21 (CST)
- 大小剧烈变化的插入,可能会使视觉信号受到一定程度上的刺激,间断用户的网络沉浸式体验--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 11:09 (CST)
- 是可以手动调的,但用户从其他网站第一次进入本站可能就会有一种电脑突然变大了的突兀感。。。--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 11:05 (CST)
- 但是,萌百字号的确挺小的,可以对比知乎这个主流且文字为主的网站以及B站的文章区(不是玛雅说的评论区)。况且这边浏览器的缩放默认情况下会把非文字的部分也放大,造成排版比例失调。要改的话应该直接修改全站CSS,这个小工具应该还是要注册了才能用,对于挽救浏览者“这个网站字体好小”的印象没有效用。
反正我这边早就自己修CSS把字调大了,去掉自己的CSS就真的觉得字好小。——🗨iehcni 2021年8月5日 (四) 11:26 (CST)- 知乎是15px,大不了太多。bilibili文章区倒是确实,有17px。——拒绝互膜的
M. J. H. 【益】{{#forargs:}} is evil! 2021年8月5日 (四) 11:30 (CST) - (况且如果要讨论“用户的网络沉浸式体验”,该考虑的不是“什么网站与萌百定位相似”,而是“什么网站更容易有到萌百的链接”。)——拒绝互膜的
M. J. H. 【否】{{#forargs:}} is evil! 2021年8月5日 (四) 11:34 (CST)- 这工具本来就只改条目正文,其他不改的。。你和别的站点评论字号比啥。。。。。要比的得是页面主体呀,而且这玩意用眼睛都能看出来谁打谁小。。。。。。--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 11:40 (CST)
- 上面缩进有问题,失礼了。我的眼睛是觉得15px这个大小和13px比起来看得舒服多了
其实也算是自己的癖好,毕竟我看班固米、s1也觉得字太小,不是对萌百一个网站有这个感觉……当然相信这种字号落差对用户体验的影响不会有多严重,当初我也是觉得字号太小但仍然进来了。——🗨iehcni 2021年8月5日 (四) 11:44 (CST)
- 知乎是15px,大不了太多。bilibili文章区倒是确实,有17px。——拒绝互膜的
要什么大字体小工具,浏览器的缩放功能是干什么用的?--希望のはな 繋いだ絆を (不要停下来啊!) 2021年8月5日 (四) 11:31 (CST)
- 用户第一次访问呢--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 11:40 (CST)
- 不过使用缩放确实是个好办法,整个页面都会变大。挺舒服的。但我觉得可能会有新用户不会?--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 12:17 (CST)
- 还是得用实践说话。以你的立场,不妨用其他无关网站测试一下能否通过把字号改大增加用户回头率。 ——拒绝互膜的
M. J. H. 【中孚】{{#forargs:}} is evil! 2021年8月5日 (四) 11:44 (CST)- 字号和回头率有什么关系???角度清奇。这玩意不是增加用户体验的吗。咱能不能稍微问点正常点的问题,你这问的都是什么跟什么呀。。。我已经不想再回答你了。--悠远的苍穹 (Talk with me!) 2021年8月5日 (四) 12:09 (CST)
- (▲)同YOONHA~1.PAR我认为没什么太大的必要。
我看不懂,但我大受震撼。——小奶糊 一位史蒂夫 (讨论·贡献)✉❶ 请问您要单推一只小浣熊吗? 2021年8月5日 (四) 17:05 (CST) - 工具引进字号不变就妥协了嘛(--这个人,曾想拯救黎明 2021年8月5日 (四) 20:29 (CST)
是这样的:这几天我正想搬运滚动的天空Wiki的导航框来萌百并被@屠麟傲血阻止,计划中和几个版本的Navbox对比如下:
项目 | T:大家族模板 | Module:Nav | 滚维导航框 | 我计划搬运的 |
---|---|---|---|---|
无穷行数 | 不支持 | 支持 | 支持 | 支持 |
原生子框 | 不支持 | 不支持 | 支持 | 支持 |
无限层级 | - | - | 支持 | 支持 |
样式优化 | 未优化 | 未优化 | 有优化 | 计划不优化 |
传统方法 | 支持 | 支持 | 使用Luaon | 使用Luaon |
资源耗用 | 较高 | 较低 | 低 | 低 |
注解:
滚动的天空Wiki版本navbox主要由站长用户:SolidBlock设计。我在本讨论串内使用了templatestyles(直接引自滚动的天空Wiki,现在User:佳沛降解剂/沙盒/Navbox/style.css)。因为mw-parser-output的限制,部分CSS未生效。
我在搬运版用的navbar是维基百科版本的。
- 原生子框
- 指直接通过一个导航框模板实现其内部的子导航框。在传统方法中,仅支持将第一个参数设置为child。
- 无限层级
- 指原生子框的堆叠层级。(之前滚维仅支持3级)
- 样式优化
- 在滚维版本的导航框,默认的样式全部置于小工具中;其一个表格就是一个表格,一个单元格就是一个单元格,不存在单独的单元格tr style="height:2px;"实现间隙,也不区分外框表和内框表。为了确保美观,该版本单元格之间的间隙是通过透明的边界(border)实现的,并且设置了background-clip:padding-box !important;,以防止单元格背景延伸到间隙内。详见https://rs.miraheze.org/wiki/Module:navbox/doc。
- 传统方法
- 指将第一个参数设为child以实现子导航框的用法。在滚动的天空Wiki和我搬运的版本,子导航框生成数据后会传入根导航框,依然由根导航框渲染。(此项目是我开发的)
- Luaon
Lua Object Notation。以Lua表定义格式为基础类似于JSON的标记语言。(此项目由我开发)
问题就出在样式优化这一点,奈何我开始着手才真正体会到“没有对比就没有伤害”。
谁收到了伤害?是萌百的Navbox吗?不,是我。
是我看到了萌百Navbox才真正领会到SolidBlock的CSS技艺之高深,真正领会到萌百导航框的差距,因而认为我不配搬运CSS。尤其是单元格内部文字的边距设定,滚维版本直接设置padding(带有子导航框的列表不设置),而萌百版本是用了有margin的div,在子导航框时再关掉。这样子是相当累赘的。作为八分之一个对“将一对标签拆散放在两个模板中”的行为深恶痛疾的猴子,这也成为了我不想继续搬运的原因。Z E S 2021年8月4日 (三) 21:36 (CST)
foo 是不是没有这个group右边的东西会全部中对齐? bar foo bar Arc Phi cytus Geometry Dash Rizline Foo bar 我 包 我 自 己 我 自 己 是不是没有这个group右边的东西会全部中对齐? bar foo bar Arc Phi cytus Geometry Dash Rizline Foo bar
页面User:佳沛降解剂/沙盒/Navbox/style.css没有内容。 补充一下用例,大家可以看看代码。Z E S 2021年8月4日 (三) 21:45 (CST)
- ( ¿ ) 喵喵喵? 所以您想要干什么?——东方众 一位史蒂夫 (讨论·贡献)✉❶ 请问您要单推一只小浣熊吗? 2021年8月4日 (三) 21:59 (CST)
- 他想要优化{{Navbox}}。▘▗ ▚ あめろ 讨论 2021年8月4日 (三) 22:48 (CST)
- 其实只是遇到一些技术相关事情来诉说一下(话说您详细地读了吗(Z E S 2021年8月4日 (三) 22:53 (CST)
- 问的我吗?我本来以为我详细读了,你这样一问,我觉得我可能没理解你的意思。所以样式还优化吗?▘▗ ▚ あめろ 讨论 2021年8月4日 (三) 23:09 (CST)
- 我读了,并且我大受震撼。特别是您那句“谁收到了伤害?是萌百的Navbox吗?不,是我。”简直震慑到了我。——巡查姬 一位史蒂夫 (讨论·贡献)✉❶ 请问您要单推一只小浣熊吗? 2021年8月4日 (三) 23:40 (CST)
- 有趣的是,本版其他所有人似乎都注意到了本版是“Project talk:讨论版”而不是“Project talk:诉说版”。 ——拒绝互膜的
M. J. H. 【坤】{{#forargs:}} is evil! 2021年8月5日 (四) 10:53 (CST)
- 其实只是遇到一些技术相关事情来诉说一下(话说您详细地读了吗(Z E S 2021年8月4日 (三) 22:53 (CST)
- 他想要优化{{Navbox}}。▘▗ ▚ あめろ 讨论 2021年8月4日 (三) 22:48 (CST)
- 我大概了解了,你说的这个确实是有优势的,就解决站内常见痛点来说,大概有减少展开长度和能够真正实现奇偶行颜色两点。但是这个版本看起来无法简单适配站内的引用,并且我对所谓『Luaon』的实现的稳定性存在疑虑。另外你这个搬运,可能CC协议并不兼容。--Func(讨论·贡献) 2021年8月4日 (三) 23:15 (CST)
- 按当前服务器情况,我比较担心的是这种核心模板模块化后Lua性能的问题(尤其是超时)
,当然目前来看展开长度限制确实也比较蛋疼--EnMGP编辑者乐然 ✉ 编织希冀,寄于歌声。 2021年8月5日 (四) 00:01 (CST) - @杨哲思
关于CSS我有个建议:column-span这条属性在Firefox Android上不会默认开启,需要设法替代。希望有安卓用户能帮忙测试一下当前的实际效果如何。 - 我想问下这个column-span是干嘛的?这根本就不是用于<table>的样式吧?——移动版用户 Bhsd 2021年8月5日 (四) 00:47 (CST)
再解释一下,在下本意是,有一个具有多方面优势的导航框,在滚动的天空Wiki(我也参与了滚动的天空Wiki导航框的修订),我参考滚动的天空Wiki版本设计了一个(其实没什么区别),现在我在疑虑要不要搬运CSS。如果我搬运的话,我感到我不配,并且版权兼容性(滚维使用CC BY-NC-SA 4.0)似乎也是一个问题滚维的东西当然可以搬,滚维的navbox也参考了维百的说是参考罢了样式要放到小工具里,颜色和字号还要改一改。如果我不搬运CSS,仍然用萌百的,那我就会为没有本版本Navbox最大的优势而感到可惜(?,并且这样子模块代码也要改,我觉得很麻烦,不是很想改(Z E S 2021年8月5日 (四) 12:39 (CST)
- 我直說吧,和Func[更多]大佬討論後明白了這個模塊確實有明顯改進的地方。但這個CSS水準也就中規中矩吧。——移动版用户 Bhsd 2021年8月5日 (四) 13:56 (CST)
- ?是吗?我觉得CSS才是最精华的部分之一。但是这CSS是User:SolidBlock写的( Z E S 2021年8月5日 (四) 17:37 (CST)
- 呃,一会儿说这个CSS是最大的优势,一会儿说这个CSS“说是”参考维百,到底是改了很多,还是没改多少?然后还说搬运没关系,所以为什么不搬运CSS?
而且你应该还和滚维站长认识,和他商量一下,小改一下再搬不是很好吗?如果的确效果好,那不是皆大欢喜?——💬iehcni 2021年8月5日 (四) 20:24 (CST)
暂时先咕掉(Z E S 2021年8月6日 (五) 12:06 (CST)
- ZES提到的这个Luaon,我去看了看,似乎是为了实现表与字符串之间的转换从而实现在维基文本层面的参数传递,但效果似乎并不好。而且还是存在一些不足之处,比如
将字符串编码的代码是。又如,tovalue函数中,使用了string.format("'%s'",value)
,显然如果涉及转义则会出现问题%d
来判断是否为数字,但%d
似乎只能识别数字,不能够识别负数以及inf、nan等特殊数字(虽然说用在navbox中也不太可能)。而且,在表和字符串之间转换,这一过程本来就是比较耗费性能的。滚动的天空Wiki上的navbox也是支持传统的定义子导航框的方式的,不必使用Luaon。
前面有人提到了column-span,应该是用于分栏文本的,不适用于表格,也不能接数字。此外templatestyles不能识别.skin-minerva
的问题,可以尝试改成body.skin-minerva
。--SolidBlock(讨论) 2021年8月6日 (五) 18:43 (CST)
- @SolidBlock 萌百的templatestyles版本不支持
body.skin-minerva
。——移动版用户 Bhsd 2021年8月6日 (五) 22:52 (CST)
- @SolidBlock 萌百的templatestyles版本不支持
- 不是不支持,是都不支持,因为模板样式的每一个选择器都会被MW加上.mw-parser-output,以防止用户修改其他部分(Z E S 2021年8月7日 (六) 12:22 (CST)
- @杨哲思 你自己看吧:mw:extension:templateStyles#Caveats ——移动版用户 Bhsd 2021年8月7日 (六) 12:57 (CST)
- 乡愁是一堵厚厚的防火墙我在这头MW官网在那头(Z E S 2021年8月7日 (六) 13:30 (CST)
- @杨哲思:以下内容摘自mw官网:
- To target styles based on skins, use a selector such as
body.skin-vector .myClass
; specification of thebody
element is required and must be followed by a descendant combinator (i.e. the space). - Other classes on the
body
orhtml
elements may be targeted in the same manner. - ——SolidBlock(讨论) 2021年8月7日 (六) 14:15 (CST)
- 善用bing搜索结果缓存页可以绕过墙看到mw文档。 ——拒绝互膜的
M. J. H. 【无妄】{{#forargs:}} is evil! 2021年8月7日 (六) 14:30 (CST)
恕我直言,使用Luaon并不是一个很好的包装传参的解决方案。
- Luaon将模块从页面中接收到的调用参数Lua表(内容是“能接收Unicode字符并且自身就由很多转义功能代码的维基文本”)转化为“能接受Unicode字符并且拥有另一套转义规则的自定义结构的字符串”,随后将这个字符串从模块中传出,经由维基文本层面再度作为参数传入,在上级Navbox的解析过程中再度还原成“一个Lua表”。在此过程中频繁的Lua模块调用以及字符串的增、删、匹配、格式化、转义等操作带来了大量的不必要性能损失,另外对两套转义规则之间的转换代码也会引入一些不稳定的因素(你永远不知道什么时候会出BUG)。
- Luaon从这名字上就可以看出设计者是模仿JSON的格式进行构建的,那么我们为什么不直接使用现成的成熟解决方案呢?萌百又不是不支持JSON。包括MediaWiki都提供了一个接口叫做mw.text.jsonDecode专供Lua模块解析JSON字符串。
- 我之前也和@Func聊到过,在目前越来越多的大家族模板不得不需要从模板换成模块来续命的背景下,由于Navbox的对外接口不能改变,因此优化只有两条路可以走了。
- 第一条路是HTML/CSS,但前端的东西我都不懂,只能将希望寄托在懂的大佬身上,能否设计出更简洁但更灵活强大的样式。
- 另一条路就是后端,我个人认为目前从模板转到模块的思路是正确的,那么问题就是如何设计出大家族模板中数据的编写、储存和读取的方式。
- 站内有一个领域叫做“字词转换”,每个字词转换的数据库以模块的形式放在模块:CGroup的子页面下,而将其可视化的是一个默默无闻地工作着的模板{{CGroupViewer}},它的代码很简单,就是读取字词转换的数据库并将其解析成wikitext,这给了我灵感。我个人也用模块搭建过不少数据库,综合用下来Lua的语法还是过于复杂,对于初次接触的编辑者来说学习成本过大。那么有没有什么格式比Lua更简洁,也贴近模板的“参数名/参数值”结构呢?我将目光看向了JSON。
- 我的想法是,将大家族模板中的数据写在一个JSON页面中,这样一来Nav只需要充当一个Parser或者说是Viewer的角色,将两者完全脱钩。
- 观察Luaon的作用原理,用户先在维基文本里写数据→数据传入模块→模块将数据处理成自定义结构的字符串→模块将数据传出到维基文本→数据作为上层模块的参数传入……,不难看到此间维基层面和模块层面经历太多数据交换,而作为Parser或Viewer的Nav模块将不用,只要传入页面的地址,所有数据处理完全在模块中进行,直到输出结果都不会受到任何干扰。
- 对于常见的大box套小box,小box套更小box的情况同样可以轻松处理,只要我们规定一个结构,比如说
"list1": { "linkto": "XXXX/YYYY" }
,那么模块读取到这个结构时,就会把XXXX/YYYY
视为子navbox的页面地址,读取其中的内容,然后搭建嵌套结构。
因此我也可以列一个表格
项目 | 模板:Navbox | 模块:Nav | 我设想的方案 |
---|---|---|---|
无穷行数 | 不支持 | 支持 | 支持 |
奇偶样式 | 手动调节 | 自动/手动调节[1] | 自动调节为主 |
原生子框 | 不支持 | 不支持 | 弃用 |
缩进和代码高亮 | 不支持/SyntaxHightlight插件 | 不支持/SyntaxHightlight插件 | 原生编辑器 |
向下兼容[2] | 支持 | 支持 | 支持(模块判断页面内容模型) |
一套三需加载页面数[3] | 4 | 5 | 5 |
页面缓存[4] | 重用 | 重用 | 重用 |
编辑者需要掌握 | wikitext | wikitext | JSON基础语法&wikitext |
潜在问题 | 展开超限 | 优化23%~27%[5]后展开超限 | Lua超时(7秒) |
- 注释:
- ↑ 目前模块:Nav自动判断奇偶的逻辑是分析同层级的上一个list中出现的最后一个tr标签的class是even还是odd,因此某些时候能正常工作,某些时候不会。
- ↑ 保留现有的所有参数名称、功能不变;使用新方案构建的Navbox可以直接引用已有的旧Navbox。
- ↑ “一套三”指的是一个总Navbox套三个子Navbox。内容分别都写在各自的页面中的前提下,模板加载总Navbox然后加载子Navbox,共4个页面;模块比模板多加载了模块页面,共5个页面。
- ↑ MediaWiki解析器在第一次加载一个现存的页面后,会在内存中保留它直到整个页面都解析完毕。理论上借助模块来加载并解析页面将不会吃到这个福利,不过我们可以在模块中缓存这个结果:在遍历所有linkto结构时,遇到新的页面则加载它并存储下来,遇到已经缓存的页面则直接用存储的结果进行处理。
- ↑ 萌娘百科_talk:讨论版/技术实现/存档/2020年05月#请求将{{Navbox_subgroup}}模块化,讨论中我给出过实测数据,两个大家族模板模块化后,展开大小优化23%~27%,模板参数大小优化55%~64%。
唯二让我慎重考虑这个新方案的问题是编辑者需要学习一种新的格式,以及模块永远绕不过去的弊病(Lua超时),不过我相信,这个新方案的提出作为抛砖引玉,一定会开拓社群的思路,为优化Navbox的事业添上一把火。--サンムル(讨论) 2021年8月7日 (六) 15:33 (CST)
@サンムル,因为JSON不支持字符串和数字键共存。Z E S 2021年8月7日 (六) 16:46 (CST)
关于“发”的繁简转换
今天发现U:Sakutaro Takizawa手动替换了一部分“发”的转换(虽然由于替换方式错误而被回退了),就此问题前来询问一下:
目前“生发”会被固定转换为“生髮”,但若是出现一个以“生”结尾的人名后加“发现”“发明”“发觉”“发誓”“发起”等动词时就会出现错误转换。考虑到这种情况可能有很多(以U:Sakutaro Takizawa的贡献来估计),是否有必要修改转换列表?——△AKQ 代号 不可逆(Talk) 2021年8月13日 (五) 23:15 (CST)
- 这个转换已经在新的维基百科转换表中修复,只有
生发x=>生髮x
这种转换了,但萌百什么时候能升级系统,只能说无可奉告。另外,似乎生髮和生發在萌百都有存在,这件事还有点难办。—— 屠麟傲血(讨论) 2021年8月13日 (五) 23:23 (CST)
如何在div缩小到一定宽度后自动出现滚动条?
Template:NoWorld这个模板的宽度是设置了vw自适应的,而里面的头像的尺寸则不会改变,所以当窗口宽度小于768px后里面的头像就会宽于模板然后就有一部分看不见了。
所以虽然没有什么用(真的会有人用768p以下的设备看萌百吗),但我想问问有没有什么办法可以在模板宽度缩小到一定宽度比如768px以下就出现滚动条,而模板宽度在768px以上时仍然是overflow:hidden?
用js肯定可以比较方便地实现这个功能,但是萌百用js很不方便,所以没法考虑。——我是亘古轮回Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 22:45 (CST)
- 缩小到800px自动出现滚动条。你看看
- あめろ 讨论 2021年8月13日 (五) 22:52 (CST)
- 谢谢,这个方法很巧妙。——我是亘古轮回Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:11 (CST)
- 但是因为grid嵌套的问题overflow不能正常使用。——我是亘古轮回Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:54 (CST)
- 我看了你的沙盒,不是grid嵌套的问题,而是你overflow属性添加错位置了。你介不介意我编辑你的沙盒?我帮你改一下。 あめろ 讨论 2021年8月14日 (六) 00:09 (CST)
- @あめろ没问题,请随意修改。不过现在保存的本来就是故意留下的错误版本(用来做其他实验),正确的版本并未保存。——我是亘古轮回Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月14日 (六) 19:30 (CST)
- @あめろ谢谢,这样确实没问题。不过这样就是用绝对定位代替grid定位,如果以后有人要修改(尤其是大改)的话就不大友好,我是考虑到这点所以才一直没有用绝对定位。另外.membersinnoworld:hover ~.noworldcover是目前我能想出来的唯一一个可以实现那个盖住其他头像功能的方法,因此我无法把div移到标记处,不知道你有没有什么其他的好办法。综上所述这个问题并未解决,不过谢谢你的修改让我拓宽了思路。——我是亘古轮回Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月15日 (日) 08:58 (CST)
- @あめろ没问题,请随意修改。不过现在保存的本来就是故意留下的错误版本(用来做其他实验),正确的版本并未保存。——我是亘古轮回Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月14日 (六) 19:30 (CST)
- 我看了你的沙盒,不是grid嵌套的问题,而是你overflow属性添加错位置了。你介不介意我编辑你的沙盒?我帮你改一下。 あめろ 讨论 2021年8月14日 (六) 00:09 (CST)
- 但是因为grid嵌套的问题overflow不能正常使用。——我是亘古轮回Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:54 (CST)
- 谢谢,这个方法很巧妙。——我是亘古轮回Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:11 (CST)
( ¡ )题外话 可否不要用vw单位,我这里限制了mw-content-text的最大宽度,你用vw的话在我这里实际上是超出内容页面了 あめろ 讨论 2021年8月13日 (五) 22:57 (CST)
- 很抱歉不能改,为了兼容性和自适应我只能这样做,目前我还没有想到其他更好的办法。——我是亘古轮回Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:11 (CST)
能否在条目内使用滚动条
能否将全站公告的滚动条(scrollDiv)进行推广,将仅用于这个id改为用于一个类?--Z E S 2021年8月9日 (一) 21:42 (CST)
- 如果不需要模板化的话,建议考虑CSS动画,示例见special:permalink/5120834。——移动版用户 Bhsd 2021年8月10日 (二) 04:02 (CST)
- {{滚动条}}。 ——拒绝互膜的
M. J. H. 【睽】{{#forargs:}} is evil! 2021年8月12日 (四) 09:03 (CST)