萌娘百科 talk:讨论版/技术实现/存档/2023年04月

请求实现黑幕能盖住彩色表情

包括emoji🌿和图片表情。
近期阅读条目时看到部分黑幕有几个表情露出来，感觉非常出戏，因此发起该请求。--一条茧 2023年3月27日 (一) 10:23 (CST)

图片相关支持已提交pr，emoji暂时想不到合适的解决方案。——

BearBin 「喷他 / 留名」 2023年3月27日 (一) 10:57 (CST)

可以试试color:transparent⭐️--一条茧 2023年3月27日 (一) 11:09 (CST)

有道理，我测试一下——

BearBin 「喷他 / 留名」 2023年3月27日 (一) 11:21 (CST)

相关PR已通过，可以看看有没有什么不兼容的地方。（您也完全可以自己去提pr的）——

BearBin 「喷他 / 留名」 2023年3月27日 (一) 11:56 (CST)

~~等font-variant-emoji支持。~~——GuoPC「飛び立とう　目指していこう　つくりものじゃない未来」 2023年3月27日 (一) 11:04 (CST)

(☩)我的想法：在黑幕使用的CSS加入以下样式：opacity:0，在没有鼠标悬停时的效果大致是这样：这是一般的文本。这是🚬🐘🌸。这是一个滑稽表情

。--ultim_0 ( USER | TALK | WORK | 再多一眼看一眼就会爆炸 ) 2023年3月27日 (一) 12:40 (CST)

划不开……--某FFF团的高级火法

（批判一番） 2023年3月27日 (一) 15:58 (CST)

选中文本时无法显示字符；且不支持半隐黑幕小工具。——

BearBin 「喷他 / 留名」 2023年3月27日 (一) 16:13 (CST)

由于页面限制，悬停时的效果无法在这里呈现。--ultim_0 ( USER | TALK | WORK | 大人有大量，不和你计较！ ) 2023年3月27日 (一) 16:22 (CST)

我知道这个意思，我在自己浏览器控制台尝试过相关思路，但是模板要改成多一层嵌套（span.heimu里面再套一层opacity:0），并且选中文本时无法显示（不是悬停，是选中）。——

BearBin 「喷他 / 留名」 2023年3月27日 (一) 16:34 (CST)

相关更改不兼容Apple系列设备，已被全部回退。类似的讨论也不是第一次有了。———— ほしみ 2023年3月28日 (二) 14:43 (CST)

( ¿ ) 喵喵喵？ 我之前测试的有完全被隐藏住喔。 BugCatcher

（讨论 / 贡献 / 签名） 2023年3月28日 (二) 21:55 (CST)

是的喵，完全被隐藏住了喵，即使选中时也被隐藏了喵～ ——

鬼影233「论|史|+」2023年3月29日 (三) 03:48 (CST)

请求被拒绝。

您仍可以继续在本模板上方回复，但这个讨论串将会在本模板悬挂满3日后 (于2023年4月1日凌晨) 存档。
如果您有有关疑问，建议您开启一个新的讨论串。

———— ほしみ 2023年3月28日 (二) 14:43 (CST)

访问萌百间歇出现Bad Request

如题，似乎是近期才出现的问题。访问若干页面（约10个页面）之后，后续访问都会变成“400 Bad Request - Request Header Or Coocie Too Large”。

清理cookies或过一段时间后可缓解该现象，但访问若干页面后会再次出现。

不知道是不是这边网络环境问题（多线上网），每访问一段时间都会多一串“7373_****_*.*.*.*”或者“8002_****_*.*.*.*”（后面的*.*.*.*为IP地址）的cookie出来，然后当类似cookie达到5条记录之后就会触发。

如图所示
https://postimg.cc/7fgS4cNd

希望排查并修复，谢谢。——弥生卯月（讨论） 2023年3月21日 (二) 16:08 (CST)

关于广告弹窗的改进

（以下问题于手机界面发现）最近萌百开始实施点击链接有几率蹦出广告弹窗，然后发现一个不那么人性化的设定：弹出弹窗后会给出两个按钮和一个❌，绿色按钮为进入广告~~没人会按的吧~~，但是白色按钮和❌也是都是跳转到对应链接，这意味着弹出这个弹窗后如果想回退到原来的页面就必须刷新页面，所以希望能把❌修改为关闭弹窗但不跳转页面或者额外增加一个按钮以关闭弹窗而不跳转，以上--有点怂的playymcmc007^{签名请用--~~~~哦}（讨论爆破） 2023年3月20日 (一) 17:37 (CST)

忽然发现打错了些内容，改一改--

有点怂的playymcmc007^{签名请用--~~~~哦}（讨论爆破） 2023年3月21日 (二) 10:08 (CST)

萌娘共享的上传页面和文件说明能实现预览“文件说明(包含分类)”的效果吗

缺少预览对新人有一点点不友好，不经常上传图片的话会记不得文件说明里同时使用作品名和文件名的写法，上传完以后发现添加的已经存在的分类没蓝又要改。

然后已经修改已经上传好文件的文件说明的预览也看不见分类的部分，只能保存后看效果确认，会搞出一堆编辑记录。--加特林03（讨论） 2023年4月2日 (日) 13:41 (CST)

我觉得上传文件界面上的文件上传指引写得挺全面的，然而经常被新人无视，直接就上传文件，连放在面前的指引都不怎么看，更别说预览功能了。--冰风飘羽（讨论） 2023年4月2日 (日) 13:50 (CST)

问题已答复。

您仍可以继续在本模板上方回复，但这个讨论串将会在本模板悬挂满3日后 (于2023年4月11日凌晨) 存档。
如果您有有关疑问，建议您开启一个新的讨论串。

处理人留言：
不如多看文件上传指引——冰风飘羽（讨论） 2023年4月7日 (五) 00:29 (CST)

MoeSkin的设计建议

对于这个皮肤，我有三个设计方面的小建议：

调整通知提醒样式。我认为在头像上加小红点这个设计实在是太不明显了。这个问题我有两个解决方案：
1. 将搜索框缩短，然后将铃铛和信箱按钮像Vector一样摆上来；
2. 新创制一个“通知中心”按钮（如果可以的话，可以把贡献按钮去掉换上这个？）。
工具栏放弃现有样式。~~本来就在Fandom看不惯这种设计，现在更看不惯了。~~个人觉得，工具栏可以把它直接放到右栏上。现有的这种类Oasis的设计，既影响正文阅读，又容易被忽视~~，还容易挡住IPE按钮~~。
编辑序言按钮改为单字“序”。

对于萌百的新用户来说，MoeSkin可以说是他们接触萌百的第一扇窗。在现有状态下，我们可能很难一个一个地劝说他们使用Vector，那么就只能拜托运维把MoeSkin做得更好一点了。@萌娘百科·娜娜奇 BugCatcher （讨论 / 贡献 / 签名） 2023年4月4日 (二) 04:52 (CST)

(＋)强烈支持现在的MoeSkin给我一种严重的外强中干的感觉。--

“我点燃了火，却控制不了它。” 2023年4月4日 (二) 07:34 (CST)

“序言”调整为“序”字已提交pr，其余需要运营进行，——

BearBin 「喷他 / 留名」 2023年4月4日 (二) 08:36 (CST)

现在版本的“序”位置偏左了，并且字可以更大一些。--ReikuChan 2023年4月4日 (二) 18:51 (CST)

关于萌百官方app的问题（三周目）

版本：（安卓）3.4.2 。3.4.1至3.4.2的检查更新也不见得有奏效。

（新版文章页面的）条目头图会从人物信息栏拔出，即人物信息栏中无图片。且不说美不美观，这一情况会使后藤一里等条目的人物信息栏中的tabs失效，即只剩下了一张头图。我印象中3.4.1时这一情况也于晓美焰条目发生，现在复现不出来，可能是因为该条目使用的是T:信息栏2.0。另外，至少在3.4.1版本，条目头图从人物信息栏拔出的操作有概率会使头图变成纯文字。如果关掉新版文章页面，点击图片的效果将是跳转至图片对应的File名字空间。
“为你推荐”处于一种循环状态，推荐的内容会在经过一个周期后再推荐一遍，周期可能在20左右。这一情况曾经并不存在，但近几个版本都存在。除了循环以外，有的条目的推荐概率也高到离谱。
3.4.2的目录无法显示（准确地说，显示过一遍）。3.4.1时正常。
“为你推荐”的回到顶部功能不明所以，这一功能更该给条目用。

以上。--ReikuChan 2023年3月27日 (一) 17:17 (CST)

另补，最近浏览功能也有问题，最后一个浏览的条目没有出现在最上部，而是一般出现在从上往下几或十几的位置。--ReikuChan 2023年3月29日 (三) 00:05 (CST)

“条目头图会从人物信息栏拔出”据说就是目标效果。不过tabs的问题确实第一次听说。推荐的循环也确实频率过高……~~APP问题真的很多~~——柏喙意志 💬 2023年3月29日 (三) 12:52 (CST)

(…)吐槽 tabs问题我不仅在维护组群说过也上过版了……--某FFF团的高级火法

（批判一番） 2023年3月29日 (三) 14:17 (CST)

又想起来一个，app内文本无法复制。--ReikuChan 2023年4月1日 (六) 16:30 (CST)

附议一个问题，部分专题的专题TOP左侧图片会变形，至少碧蓝是这样.jpg ——性感航母在线空袭，美女战列免费试射☛快来玩碧蓝航线吧

（骂我|打工史） 2023年4月2日 (日) 08:22 (CST)

我看这个倒是MoeSkin通病。 BugCatcher

（讨论 / 贡献 / 萌百移民） 2023年4月2日 (日) 08:36 (CST)

问题一推断是api缺陷，后续我们研究解决下，问题二和问题三正在解决，预计在后续版本中修改，感谢支持 --萌娘百科·Barry（讨论） 2023年4月3日 (一) 10:34 (CST)

不知道运维这边有没有看到其他问题，我再补一个问题，关于APP搜索功能的，版本号同上。

向搜索框输入“K ON”（有空格），反馈结果为“K”的;

向搜索框输入“KOI”（全大写），第一遍显示无结果，在“暂无结果哦”的界面再次向搜索框输入“KOI”，有结果。其他全字母的输入内容似乎亦有相同情况。

以上。--ReikuChan 2023年4月4日 (二) 19:04 (CST)

申请引入模块:Pipe escape

如题，之前在编辑页面的时候，遇到需要在{{hide}}等模板中添加表格的情形，这种情况下通常需要使用大量的魔术字{{!}}或者模板{{!!}}，以及一些“表格替换符号”，如{{(!}}、{{!-}}、{{!)}}之类。这些模板不仅不够直观，大量使用还会导致页面源码显得极为臃肿，难以辨识，对新手非常不友好。本人曾在中文Minecraft Wiki进行过一些编辑，也熟悉其对模板嵌套表格方式的处理：通过一个Lua模块Pipe escape及其用于包装模块的模板{{Pipe escape}}来代替大量使用上述模板的行为，其使用方法如下：

{{cquote|
{{pipe escape|
{| class{{=}}"wikitable"
! 标题
! 第二个标题
|-
| 行
| 第二列行
|-
| 第二行
| 第二列第二行
|}
}}
|有人在表格里说话}}

效果相当于：

“

标题	第二个标题
行	第二列行
第二行	第二列第二行

”

——有人在表格里说话

本人目前已经在自己的模块沙盒（模块:Sandbox/Ultim 0/Pipe escape）撰写了与其功能基本相同的模块（不是直接搬运），并在个人沙盒进行了测试。希望能够将这个模块引入萌娘百科，不胜感激。--ultim_0 ( USER | TALK | WORK | 秉忠贞之志，守谦退之节 ) 2023年4月14日 (五) 12:27 (CST)

其实已经有引自enwp:Module:Wikitable的{{Wikitable}}了，只不过现在只有少数几个页面使用。Wikitable的功能和pipe escape差不多。理论上pipe escape的适用范围更广一点，但是除了在模板里用表格之外，需要使用{{!}}的情景很少。 ——好哥哥一起来游戏吧 PetrusMagnus

你的二次元老婆于2023年4月14日 (五) 12:40 (CST)

问题不大，而且pipe escape的模块代码不如{{wikitable}}那么长，易于维护，且一个pipe escape可以容纳多个表格，算是各有所长。--ultim_0 ( USER | TALK | WORK | 感觉身体被掏空 ) 2023年4月14日 (五) 13:52 (CST)

话说创建模块应该不需要其他人同意吧，只要有人用就行。只不过我确实觉得功能和wikitable重复很大。

还有就是用..拼接字符串有性能问题，尤其是对于大表格。以1000行4列的表格测试，预览时的lua使用时间差不多是1.750秒（见沙盒）。同样的表格用{{wikitable}}，lua使用时间是0.040秒。 ——好哥哥一起来游戏吧 PetrusMagnus

你的二次元老婆于2023年4月14日 (五) 15:04 (CST)

来这里发讨论串主要是给大家提个醒，告知大家自己想要在萌娘百科做出的一些关键举措。至于模块的性能问题，我再参照其他模块进行修改。--ultim_0 ( USER | TALK | WORK | 为什么不喝？！ ) 2023年4月14日 (五) 22:24 (CST)

刚才做出了一些小修改，抛弃了..的使用，转而使用和wikitable模块类似的方式，先读入所有参数存放在一个表中，再将其一次性拼接。--ultim_0 ( USER | TALK | WORK | AWWW MAN! ) 2023年4月14日 (五) 22:40 (CST)

这是当前版本中，在lihaohong沙盒里使用两个模板得到的数据：

	pipe escape	wikitable
CPU使用时间	1.003秒	0.459秒
实际使用时间	2.650秒	0.521秒
预处理器访问节点计数	8,074/1,000,000	8,071/1,000,000
预处理器生成节点计数	80,709/1,000,000	80,681/1,000,000
展开后大小	187,537/2,097,152字节	187,538/2,097,152字节
模板参数大小	0/2,097,152 字节	0/2,097,152 字节
最高扩展深度	3/40	2/40
高开销解析函数数量	0/50	0/50
Unstrip递归深度	0/20	0/20
Unstrip传递扩充大小	0/5,000,000字节	0/5,000,000字节
Lua使用时间	1.560/7.000秒	0.030/7.000秒
Lua虚拟尺寸	8.12 MB/50 MB	6.47 MB/50 MB
Lua估计的内存使用情况	0字节	0字节

可以看到性能还是有一定的差距。

抛开性能的话，虽然可能是自卖自夸，我也觉得wikitable更加符合实际使用需求。语法结构非常相似、不需要额外的嵌套；并且“可以容纳多个表格”这个也不是什么优势，wikitable同样可以多个使用。除了表格以外，基本只有url中的|是不期望被解析的，而此类情况直接用{{!}}更加方便。——

BearBin 「喷他 / 留名」 2023年4月14日 (五) 23:45 (CST)

Lua使用时间非常宝贵，建议选用更优的。—— ほしみ 2023年4月14日 (五) 23:57 (CST)

关于性能：访问frame.args[key]比访问一般的表的键要耗时（见Scribunto库 mw.lua#L191），提前用pairs将所有键值复制到一个普通表中（在模块:Wikitable中是通过模块:Arguments的getArgs()达到这一目的的），就可以在后续的遍历中节省大量时间，达到以及超越当前模块:Wikitable的性能。　あめろ ^讨论 2023年4月15日 (六) 04:54 (CST)

感谢大家的评价，我会在进行合适的改动和优化之后将这个模块投入使用。--ultim_0 ( USER | TALK | WORK | 水是剧毒的 ) 2023年4月15日 (六) 14:27 (CST)

问题已解决。

您仍可以继续在本模板上方回复，但这个讨论串将会在本模板悬挂满3日后 (于2023年4月19日凌晨) 存档。
如果您有有关疑问，建议您开启一个新的讨论串。

处理人留言：
我还是太连清了……——ultim_0 ( USER | TALK | WORK | 水是剧毒的 ) 2023年4月15日 (六) 14:27 (CST)

疑似bot出问题

Template:VOCALOID殿堂曲统计这个模板中的两个计数一直以来通过User:AnnAngela-abot更新，一般情况下只应更改两个计数数字，但今日突然做出了两笔更改此外内容的编辑，并对模板显示内容造成影响。

希望可以尽快解决一下。——4O74Y74L74J7（讨论） 2023年4月14日 (五) 22:58 (CST)

问题已解决。

您仍可以继续在本模板上方回复，但这个讨论串将会在本模板悬挂满3日后 (于2023年4月21日凌晨) 存档。
如果您有有关疑问，建议您开启一个新的讨论串。

处理人留言：
已由AnnAngela[更多]解决——Takeuchi.BadEditor (讨论与留名) 2023年4月17日 (一) 13:45 (CST)