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

续太不智能的跳转与搜寻

接续上次讨论：要使“阿當．戴華”自动跳转至阿當·戴華，除将“．=>·”加入全局转换表或批量自动建立此类重新导向二个选项外，别无他法？有无更简洁的更佳选择？若提请“．=>·”加入全局转换表失败，就只有批量自动建立此类重新导向一条路？--— Gohan 2024年3月12日 (二) 05:02 (UTC)

直接修改搜寻系统，断词为"阿当 / 戴华"。这样不论你打什么符号在中间都搜寻的到。中文维基本站可能做不到，需要由MediaWiki来做搜寻演算法修改。--Shyangs（留言） 2024年3月12日 (二) 06:15 (UTC)

[1][2][3]，没找到中文的stopwords是如何定义。或者，如果适用于所有语言，可能应该char_filter做转换？--YFdyh000（留言） 2024年3月12日 (二) 11:49 (UTC)

修改搜寻系统是否足够？毕竟在港澳台星马人名中，全形的“．”或无间隔号远比半形或不足半形的“·”常见，后者在站外几近捏造。使用外挂工具从站外的“阿當．戴華”／“阿當戴華”跳转至阿當·戴華的需求，大概远远多于从站外的阿當·戴華直达的需求。若在社会中不常见的阿當·戴華能够直达，而更常见的“阿當．戴華”／“阿當戴華”不能跳转，或许轻重倒置、并不公平？--— Gohan 2024年3月18日 (一) 01:53 (UTC)

您是期望内链、正文也获某种转换吗。不了解“．”的常用性。--YFdyh000（留言） 2024年3月18日 (一) 02:03 (UTC)

我期待使用Wikipedia search之类的工具从站外的“阿當．戴華”能够跳转直达阿當·戴華。--— Gohan 2024年3月18日 (一) 02:08 (UTC)

Wikipedia Search扩展？如果目前仅有此需求，您可以写一个用户脚本作为临时解决方案。例如将下列代码插入您的common.js文件。if (mw.config.get('searchTerm')) {window.location.href = decodeURIComponent(window.location.href).replace(/．/g, '·');}--YFdyh000（留言） 2024年3月18日 (一) 02:26 (UTC)

最理想还是人人可用。--— Gohan 2024年3月18日 (一) 09:54 (UTC)

@YFdyh000：，看了SuggesterAnalysisConfigBuilder.php的char_filter配置，似乎这是改搜索索引配置的正确思路，或者可以考虑将“U+FF0E=>U+00B7”（如果能针对部署的语区（只针对zh区）的话更好）的映射配置进去？——Sakamotosan路过围观 | 避免做作，免敬 2024年3月25日 (一) 02:36 (UTC)

所以我认为还是允许将“．”作为间隔号的错误代替来建立重定向（基于“标点符号上的区别”或者“常见的错别字和错误拼写”），这样应该能够帮助搜索系统归集数据来使其也能被正常搜索出来。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月18日 (一) 05:59 (UTC)

我觉得若可以应该内部处理，这样一开放预估又会多出几万个重定向，有点鸡肋--SunAfterRain 2024年3月19日 (二) 01:43 (UTC)

重定向操作相对简单一些，加全局转换可能影响更大（因为不只是标题，内容也会有影响）。或者调整搜索系统的来源词过滤也可以考虑，但需要检查CirrusSearch的技术信息，上面提及的似乎可行。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月19日 (二) 01:52 (UTC)

至少在大陆“阿當．戴華”不会用这种不规范的标点或者很少这种不带标点的外文译名，这样的重定向绝大多数没用。普通情况下，不论是否使用间隔号或者不规范间隔号，Google搜索或者维基内部的提示词皆会排在首位，而且不想输入间隔号的话，还可以复制。港台或新马地区也许有些用。对于外部资料中有使用的或许可以考虑建立重定向，但是在所有的条目上建立未从使用、不规范的重定向感觉没必要。

另外，对于比较长的名称“维亚切斯拉夫沃洛金”，special:search中排在首位。“阿當戴華”的话，special:search的推荐词中会在首位推荐“阿當·戴華”，但是搜索结果中并未将其放在首位，要加前缀intitle:。--Kethyga（留言） 2024年3月19日 (二) 02:29 (UTC)

不宜以中国大陆的“规范”凌驾其他国家／地区。如果走到只能大量建立重新导向的地步，而且机械人无法辨别中国大陆标题与否，那么只能一概建立。况且，大陆“不会用这种不规范的标点”？中国出版集团所用的“本•阿什克罗夫特”算不算规范呢？很少“不带标点”？在中国大陆新闻网站搜寻名人姓名，轻易可见；更不用说在微博、小红书等选词跳转的需要。手写且手快的人士未必会看选单，自加intitle:更是有违绝大多数人的习惯。--— Gohan 2024年3月25日 (一) 00:36 (UTC)

这不是中国大陆的规范问题，而是W3C《中文排版需求》是建议“间隔号”是用“·（U+00B7）”作为字符编码，中国大陆规范等同这个标准，但字型（字符通过字体库渲染）上，港澳台的（字体库）是全角字型、中国大陆的是半角字型；台湾的标准是“．（U+FF0E）”，港澳台的（字体库）为居中字型，而中国大陆的（字体库）是左下角字型。（关于字型渲染效果的话，可以找一个叫BabelPad的类笔记本软件，支持Unicode全部字符编码和选择字体库渲染字型，然后下载微软雅黑（简体字型）、微软正黑体（繁体字型）、思源宋体的不同地区字型变体的字体库，用BabelPad加载看看两个字符渲染形式）如果从Unicode给的字意的话，应该U+00B7才是对应间隔号的正式字符，U+FF0E是将错就错的结果（字符编码用错+字体库“修正”）。所以最快的方法是按照Wikipedia:重定向来建立重定向代替，或者修改搜索索引的配置，再次就是修改全局转换表。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月25日 (一) 02:08 (UTC)

所以不就是中国大陆的规范吗？--— Gohan 2024年3月27日 (三) 05:03 (UTC)

是W3C的标准也这样规范。（指正）——Sakamotosan路过围观 | 避免做作，免敬 2024年3月27日 (三) 11:46 (UTC)

有个目前难以实现、或许异想天开的思路：既然个别本地转换表能只针对指定命名空间，能否让重新导向页被本地转换表视为一种命名空间（无论是真是假），或者干脆让标题起到本地转换表眼界中的命名空间作用？--— Gohan 2024年3月25日 (一) 00:37 (UTC)

我觉得这是不了解技术细节胡思乱想的方案吧？好像没有所谓指定命名空间生效的转换表机制，而且重定向（mw:Manual:page table，重定向页本身也是一种页面，只是检测到源代码有重定向标记后，将页面表的对应字段flag起来，方便后续代码按照重定向的方式做跳转行为处理）也不是一种命名空间。四级字符转换配置表中，第一级是放在源代码的超大转换数组（方便程序读取），第二级也只是放在Mediawiki命名空间（作为系统消息等可以方便前台人员维护）而已。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月25日 (一) 02:16 (UTC)

的确存在只针对ns8的本地转换表。正因为重新导向页不是命名空间，才说“让重新导向页被本地转换表视为一种命名空间（无论是真是假）”。--— Gohan 2024年3月27日 (三) 05:03 (UTC)

@神秘悟饭：模块:CGroup/MediaWiki special？那只是针对Mediawiki语境下，方便转换Mediawiki这个应用下的用词的公共转换组（也就是字词转换机制下的第三级）而已。我至少没找到针对特定命名空间的字词转换机制。我认为你提的这些东西没有技术依据做支撑。至少在有限时间内不具可行性的讨论。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月27日 (三) 11:44 (UTC)

不是，是MediaWiki:Conversiontable/zh-hans/ns8、MediaWiki:Conversiontable/zh-hant/ns8等。--— Gohan 2024年3月28日 (四) 10:23 (UTC)

没找到mw相关文档的说明。（这真的有用？）就算这样，重定向页并不是命名空间。如果为此做实现，可能技术上有限时间内不具可行性。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月1日 (一) 08:29 (UTC)

找了一些讨论，似乎MediaWiki:Conversiontable/zh-hant/ns8等不是mw内的运行机制，而是给本地机器人整理字词转换的辅助内容。（Wikipedia:机器人/申请/Cewbot/24、User_talk:Jimmy_Xu/存档/2015年/7-9月）——Sakamotosan路过围观 | 避免做作，免敬 2024年4月1日 (一) 08:33 (UTC)

现时可行的技术方案不外乎三种：（1）建立重定向页、（2）调整搜索索引的分词配置、（3）增加全局转换（影响广泛，不只是页面命名，还包括正文，但也不是不可行的办法）。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月25日 (一) 02:25 (UTC)

应该集中在如何控制搜索适配的问题，也就是集中“在如何控制页面标题使用‘U+FF0E’作为间隔号时或者输入关键词使用‘U+FF0E’作为间隔号时能正确匹配到对应的页面”的问题上。至少（1）、（2）的技术可行性更好，对其他方面（如正文源代码的录入）的影响程度更少。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月25日 (一) 02:30 (UTC)

2024年第14期技术新闻

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其它语言的翻译版本。

最近更改

• 无障碍阅读测试功能的用户将注意到“标准”和“大”文本大小选项的默认行高已更改。 [4]

本周变更

• MediaWiki的新版本将于4月2日部署至测试维基及MediaWiki.org，于4月3日部署至非维基百科wiki及部分维基百科，并于4月4日部署至所有站点（参见日历）。 [5][6]

未来更改

• 维基媒体基金会每年都会制定年度计画，以决定基金会将致力进行的事项。您现在可以阅读产品与技术部门的关键成果草案。该草案建议基金会于2024年7月至2025年6月间，在重大技术变革中希望获得的成果。您可以在讨论页发表评论。

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2024年4月2日 (二) 03:34 (UTC)

建议对{{link-xx}}系列模板进行编辑

具体建议：在“可参考外文维基百科条目”的提示信息末尾加入“创建条目前请先查询相关的本地关注度指引。”，以免用户不小心创立不符合本地关注度要求的条目。--📕📙📒📗📘 赌博机构最坚定的反对者 📚📖 2024年4月3日 (三) 18:29 (UTC)

我觉得不太必要。除了关注度，可供查证等方面也需要注意，但不能将所有提示都塞进去，会类似冗长的欢迎模板、警告模板，用户自知创建的各项要求会更好。可以加指引来建议不要链接低品质的条目，不过执行力度和方式需要商榷。(＆)建议 比如甚至能用机器人自动解链不存在或低品质的目标条目，或者标记和允许用户看不到/特殊标出这种链接（甚至普通内链），标记用模板参数、自动评级。--YFdyh000（留言） 2024年4月3日 (三) 20:45 (UTC)

阁下认为机器人应该根据什么标准判定目标条目为“低品质”？是目标条目在目标维基的评级，是目标条目属于任何一个小作品分类，是目标条目字数小于多少字节，还是其他什么标准？不好意思，在下对维基机器人的编程和运作一无所知。

另外，如果阁下不想“将所有提示都塞进去”的话，就把上面的提示改成“创建条目前请先了解相关的本地规则。”行不行？因为“规则”包含了关注度、可供查证度、以及其他所有条条框框。📕📙📒📗📘 赌博机构最坚定的反对者 📚📖 2024年4月3日 (三) 21:55 (UTC)

至少那些无任何来源（日文维基就有不少）或挂有{{无来源}}等重要维护模板的。挂有{{广告}}的也值得慎重。其他复杂的评级计算和目标维基上的评级，能考虑但后话。原则上不反对，但我期待更好方案。--YFdyh000（留言） 2024年4月4日 (四) 00:43 (UTC)

巡查员能按规则巡查新入条目，作出处理，并且要适当提醒这样创建条目的问题，无论来自于哪里。而老用户也应该根据外文条目的质量来判断是否将其翻译引入或者改进。看上去提案者认为其他用户（或者他自己）更像不思考条目质量而盲目引入，而之只能要靠那些可怜的提示来提醒。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月4日 (四) 01:58 (UTC)

“不思考条目质量而盲目引入”的不是我，而是另有其人。📕📙📒📗📘 赌博机构最坚定的反对者 📚📖 2024年4月4日 (四) 03:42 (UTC)

@Cwek能详细说明一下“引入”意思? 我真的认为@PÑēüḾôňïę1357误解了.--Winston（留言） 2024年4月4日 (四) 03:59 (UTC)

如果认为不需要根据外语条目创建该本地条目的话，直接除链则可，如有问题，自行讨论。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月4日 (四) 01:35 (UTC)

@Cwek 我认为最好举个例子讲述. 是这样的, @PÑēüḾôňïę1357没有满足关注度认为使用跨语言连结是不合理的 (例子). 但我个人关心的是如果连结被除其他读者将无法参考相应的英文/其他语言页面.

我认为这次讨论是Wikipedia:互助客栈/求助#跨语言连结问题延伸.--Winston（留言） 2024年4月4日 (四) 04:08 (UTC)

还是没理解我想说什么？我们这里建条目是依照相关规则（包括关注度等）来建立的，不考虑从哪里来（包括原创或者翻译）。至于加了link-xx是否就要翻译，那是另一回事，或者如果你认为不值得建立（无论是是否满足本地关注度还是当地语言的条目质量不符合在本地规则建立），可以直接消除link-xx（最好说明清楚在编辑摘要，作为备忘），根本不需要如此画蛇添足。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月4日 (四) 04:55 (UTC)

@Cwek 如果消除跨语言连结其他读者将无法参考相应的英文/其他语言页面. 这有没有可能缺乏参考吗? 如果翻译可能无法被读者理解/可能会令读者困惑, 没有英文/其他语言页面的参考我认为这将是一个潜在问题--Winston（留言） 2024年4月4日 (四) 06:03 (UTC)

@Cwek 如果每个人消除跨语言连结(原因是个人认为不值得建立), 那么跨语言参考就会被断掉. 我不确定这是不是一个问题. 谢谢--Winston（留言） 2024年4月4日 (四) 06:06 (UTC)

如果来源条目不符合本地规则用于创建，那就添加link-xx我认为没意义。创建条目质量和是否来自link-xx不是直接相关，与巡查员的职责履行有关。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月4日 (四) 11:32 (UTC)

@Cwek 我想阐明, 维基没有规定使用内部链接助手需要满足关注度, 对吗？谢谢. 内部链接助手文档指出对于中文维基百科未建立条目的词汇，该模板可在生成内部连接的基础上，展示外语版条目连结以供参考。 --Winston（留言） 2024年4月4日 (四) 13:13 (UTC)

不太会建立条目的文字不应加入红字链接，link-xx相当于红字链接后面括号附注原文，所以不满足关注度的主题不应该加入link-xx。

最初设立link-xx时，模板的效果是直接在正文里写红字连接+外部连接（红字链接（英语：Redlink）），弹窗效果要注册后自行设定才出现。后来模板（没有讨论地）就改成了现在的预设弹窗设置，但是对这个模板的定位没有再议（现在有人认为模板主要是方便读者看外维；也有人认为主要是方便编者翻译条目；还有人认为模板就是单纯标记外语原文，只不过顺便加个链接）。所以现在link-xx的定位很迷，开头说的推论不是所有人都同意。

另外MOS:IWL第二段也是说“在不过度使用内链的前提下……”。目前看来如果条目没有关注度，就只能在后面用括号单纯附注外文，不加跨语言链接了。--For Each element In group Next（留言） 2024年4月4日 (四) 13:28 (UTC)

@For Each element In group Next 感谢您提供参考, MOS:IWL第二段是说“在不过度使用内部链接的前提下，对于不为中文用户熟知的外来词汇，编辑可以使用跨语言连结模板”. 我个人认为和关注度低是有点矛盾的, 因为不为中文用户熟知的外来词汇很有可能关注度低. 不为中文用户熟知的外来词汇可以使用跨语言连结模板但关注度低不推荐使用跨语言连结模板. 因此对我来说会很混乱, 我不确定是否要添加跨语言连结模板. 另外我觉得整个MOS:IWL从未提及跨语言连结模板和关注度之间的关系.

我倾向同意link-xx的定位不是和红字连接相等(跨语言连结模板有额外的功能, 提供外语版条目连结以供参考). 也许这就是定位很迷原因.--Winston（留言） 2024年4月4日 (四) 14:59 (UTC)

“不为中文用户熟知的外来词汇很有可能关注度低”是不对的，仅存在外文有效资料、中文圈完全不关心的内容，也是有关注度的。不能创建条目的直接除链我是赞成的，但link-xx模板的作用已较为多元，可能有些人当作参见外文维基的外部链接或者原文标注等。--YFdyh000（留言） 2024年4月4日 (四) 15:43 (UTC)

但维基有自己的条目开启关注度政策要求, 也许我们可以用这次当例子. 卡尔加里山麓不满足关注度政策要求. 当你在搜寻引擎上搜寻时, 读者可能不知道我在说什么. 我觉得它应该满足不为中文用户熟知的外来词汇和关注度低(也不满足条目开启关注度政策要求). 在这种情况下，link-xx模板将提供读者参考. --Winston（留言） 2024年4月4日 (四) 23:38 (UTC)

这笔是吧。该英文条目的30个来源中，有无符合中文维基百科关注度的来源。暂时未看到特别明显的介绍，但媒体持续对球队表现有关注和报道，以及像[7]和其他文献可能存在对球队历史的介绍，是否满足关注度。--YFdyh000（留言） 2024年4月5日 (五) 00:54 (UTC)

WP:FOOTBALLER提供足球运动员关注度指引指导, 根据足球地区分类加拿大属于第三类国家/地区, 然后根据足球俱乐部第三类国家/地区累计最少在第一/第二级联赛存在两个赛季满足关注度. 然后根据加拿大足球联赛系统加拿大暂无第二级联赛. 第三级联赛也没有晋升系统. 现在卡尔加里山麓属于第三级联赛, 所以我没看到卡尔加里山麓如何满足关注度. 所以我相信当有人根据WP:FOOTBALLER要求移除时，卡尔加里山麓很可能被移除.--Winston（留言） 2024年4月5日 (五) 02:17 (UTC)

关注度细则只是方式之一。我觉得有可能存在符合WP:GNG的来源，未必是线上来源。--YFdyh000（留言） 2024年4月5日 (五) 04:35 (UTC)

理解--Winston（留言） 2024年4月6日 (六) 07:10 (UTC)

同时在没有找到太多搜寻结果时, 是否link-xx可以提供一些参考? 但是有一个“创建条目前请先查询相关的本地关注度指引。”这个话题出现.--Winston（留言） 2024年4月5日 (五) 02:22 (UTC)

也有可能如果编辑自己没有翻译正确的话，那么搜寻结果就会缺失. 没有搜寻结果且没有link-xx(参考链被除). 那么读者如何信任WIKI内容?--Winston（留言） 2024年4月5日 (五) 02:30 (UTC)

所以你的理解还是搞错了。加link-xx对应到外语条目，并没有规定添加的方式或者限制。但如果link-xx预期不可能创建本地条目的话，是可以不添加。至于如何创建本地条目，是通过link-xx引导翻译、还是单纯直接地翻译，如何确认本地条目是否满足本地规则的话，那是编辑者和新页面巡查应该去判断地，但与link-xx无关，link-xx不应该承担这种提醒需要。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月5日 (五) 05:54 (UTC)

感谢您的解释. 但我还是不明白. 我知道这有点好笑, 但我添加link-xx但被撤销. 他的理由是根据WP:FOOTBALLER，卡尔加里山麓必须赢得加锦标才能符合准入条件, 因此我加link-xx是不正确的. 他也认为添加link-xx是“不思考条目质量而盲目引入”. 我不知道如何应用维基政策应用此编辑.--Winston（留言） 2024年4月5日 (五) 06:36 (UTC)

2024年第15期技术新闻

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其它语言的翻译版本。

最近更改

• 网路浏览器中可以使用扩展程序工具。现在有一个名为Citation Needed的Chrome扩展程序，您可以使用它来查看网路上的内容是否受维基百科条目支持。这是个测试维基百科运用方式的小实验。不过因为是小实验，所以仅限于Chrome浏览器使用，且仅能用于英文内容。
• 所有wiki均加入了新功能“编辑恢复”，可在参数设置中启用。启用后，正在进行的编辑将保存在网路浏览器中，如果您意外关闭编辑窗口，或是浏览器或计算机崩溃，再次开启时，网页将提示您恢复未发布的文本。请在项目讨论页留言反馈。这是2023年社群愿望清单调查中的第八位。
• “编辑检查”实验的初步结果已发布。编辑检查现已作为默认功能部署至先前测试它的wiki。如果您希望您所在的wiki成为下一批编辑检查的部署对象，联系我们。 [8][9]
• 在移动设备上使用Minerva皮肤的读者将注意到所有排版设置的行高皆有改进。 [10]

本周变更

• MediaWiki的新版本将于4月9日部署至测试维基及MediaWiki.org，于4月10日部署至非维基百科wiki及部分维基百科，并于4月11日部署至所有站点（参见日历）。 [11][12]
• 新账号和登出的用户将以可视化编辑器作为移动版的默认编辑器。除英语维基百科外，所有维基百科均进行此部署。 [13]

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2024年4月8日 (一) 23:36 (UTC)

编辑恢复有时候操作不小心会恢复到错误的版本--百無一用是書生 (☎) 2024年4月9日 (二) 02:51 (UTC)

可视化编辑器问题

合并至上方讨论。--碟之舞📀💿 2024年4月15日 (一) 08:52 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

---

感觉最近较常出现Unable to stash Parsoid HTML这个问题--Yutommy 崖上的孤儿 消暑乐祭的狗 2024年4月14日 (日) 15:59 (UTC)

---

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

可视化编辑器是坏了吗

于Phabricator查看
编号T356157的工单

如题，切换过去就显示Unable to stash Parsoid HTML。--mije meli carrot_233 -- 讨论 2024年4月10日 (三) 05:40 (UTC)

有时候会丧失功能，原因不明。-- 肥羊翻译机 ⁄_留言 2024年4月12日 (五) 12:53 (UTC)

phab:T356157。类似问题先前发生过，由于没有日志无法分析，后来启用了日志，这次复现了等调查结果吧。--碟之舞📀💿 2024年4月15日 (一) 08:53 (UTC)

2024年第16期技术新闻

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其它语言的翻译版本。

问题

• 4月2日至8日间，在使用标记修订的wiki上，被撤销的编辑未被加上“已被回退”标签。此外，页面移动、保护和导入操作未自动标记为已巡查。此问题已解决。 [14][15]

本周更改

• MediaWiki的新版本将于4月16日部署至测试维基及MediaWiki.org，于4月17日部署至非维基百科wiki及部分维基百科，并于4月18日部署至所有站点（参见日程表）。 [16][17]
• 默认分类排序关键字现在会影响脚注中放置的模板所添加的分类。先前，脚注中的分类使用页面标题作为默认排序关键字，即使已经指定了不同的默认排序关键字（分类专用的排序关键字已经生效）。 [18]
• 滥用过滤器将添加新变量page_last_edit_age。该变量表示页面的最后一次编辑是在多少秒前。 [19]

未来更改

• 恳请志愿开发者们更新您维护的工具和功能的代码以应对临时账号。了解更多。
• 数据库副本（包括Quarry）中将移除四个数据库字段。这仅影响abuse_filter和abuse_filter_history表格。某些查询可能需要更新。 [20]

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2024年4月15日 (一) 23:27 (UTC)

看来又要坏掉一批站内站外的工具了....--百無一用是書生 (☎) 2024年4月16日 (二) 02:29 (UTC)

可否筛选一下本站可能受到临时账号影响的脚本？--碟之舞📀💿 2024年4月16日 (二) 15:36 (UTC)

可能影响不明显？因为临时账号的用户名表现方式和普通用户相近，可能底层属性会多了“临时”的标签，需要相应脚本增加相应的检测。IP地址形式用户名可能以后会消失，相关的脚本也就没有用了。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月17日 (三) 02:04 (UTC)

用户讨论页内部错误

于Phabricator查看
编号T362530的工单
状态：已解决

请问各位阁下，关于用户讨论页发生内部错误，显示以下错误说明，该如何恢复讨论页？麻烦请各位阁下协助，谢谢。

結構式討論工作流程並未與該頁面關聯。
[e7ab9c04-d03f-457a-85f2-7abd118bfd25] 2024-04-12 12:32:56: 嚴重異常類型
「Flow\Exception\InvalidDataException」

-- 肥羊翻译机 ⁄_留言 2024年4月12日 (五) 12:50 (UTC)

@OnionBulb：能否在测试功能中关闭结构式讨论页？--碟之舞📀💿 2024年4月15日 (一) 08:47 (UTC)

偏好设定的测试功能没有“结构式讨论页”的设定，我记得以前有这个设定，不知为何现在没有也没显示。-- 肥羊翻译机 ⁄_留言 2024年4月15日 (一) 11:59 (UTC)

报phab ——魔琴［身份声明 留言 贡献 新手2023］ 2024年4月15日 (一) 12:02 (UTC)

了解，感谢。-- 肥羊翻译机 ⁄_留言 2024年4月18日 (四) 02:49 (UTC)

已交工单。@OnionBulb您好，想问一下这个问题是怎么出现的，之前是否进行过关闭结构式讨论的操作？

另外，结构式讨论已经废弃，将来将会从本站移除，就算恢复过来大概率会是传统Wikitext页面。--碟之舞📀💿 2024年4月15日 (一) 13:07 (UTC)

因为用户讨论页有收到结构式讨论的弃用通告，大概前两个月我从偏好设定关闭结构式讨论，结果用户讨论页变成上述的发生内部错误。-- 肥羊翻译机 ⁄_留言 2024年4月18日 (四) 02:55 (UTC)

@OnionBulb：Phab的人修好了，请复查。--碟之舞📀💿 2024年4月15日 (一) 14:10 (UTC)

感谢阁下大大的协助。-- 肥羊翻译机 ⁄_留言 2024年4月18日 (四) 02:56 (UTC)

请问阁下，要如何改为传统wikitext页面？虽然他们有修好，可是偏好设定似乎找不到相关的关闭选项，是不是只能等待站方正式移除改回传统页面？-- 肥羊翻译机 ⁄_留言 2024年4月18日 (四) 05:05 (UTC)

页面信息/基本信息/过去30天的页面访问量 蓝链问题

请问各位，【页面信息/基本信息/过去30天的页面访问量】中的数据超链接蓝链可否恢复？或者类似英维那样直接链出？——Zzhtju（留言） 2024年4月20日 (六) 12:54 (UTC)

2024年第17期技术新闻

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其它语言的翻译版本。

最近更改

• 从本周开始，维基百科的新手编辑者会被鼓励尝试结构化任务。结构化任务已被证明能提升新手的活跃度和留存率。 [21]
• 即日起可以提名您最喜欢的工具参加第五届最酷工具奖。提名将持续开放至5月10日。

本周更改

• MediaWiki的新版本将于4月23日部署至测试维基及MediaWiki.org，于4月24日部署至非维基百科wiki及部分维基百科，并于4月25日部署至所有站点（参见日程表）。 [22][23]

未来更改

• 这是最后一次提醒，从2024年5月底开始，Vector 2022皮肤将不再与旧版Vector共用网站和用户的脚本及样式。对于要在Vector 2022上继续使用的用户脚本，请将Special:我的用户页/vector.js的内容复制到Special:我的用户页/vector-2022.js。参阅更多技术细节。界面管理员若预期这将导致大量技术支持问题，可以效仿法语维基百科，向您所在的社群发送大量信息。 [24]

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2024年4月22日 (一) 20:26 (UTC)

关于褒扬令、碑文的蓝色方框的 CSS 样式建议

目前在维基百科上，获中华民国褒扬令的人物往往会在其页面上刊出褒扬令全文，并以蓝色方框（实现方法为一个加了蓝色实线 border 的 <blockquote>）框之。其他的一些人物的碑文可能也采取这样的做法。

但很经常地，这样的方框的右侧部分会和页面右侧边的其他资讯方块相重叠，导致方框不能显示完全，有时还会使内容发生诡异的换行效果。

现状参考：许虞哲、吴新荣。

要解决这一问题其实很简单，只消为 <blockquote> 添加一个 display: flex; 的 CSS 样式，并将其内的所有内容包在一个 <div></div> 里即可。这样方框就不会与页面上的其他元素重叠了（同时内嵌的 <div> 确保了 <blockquote> 内的内容不会出现排印错误）。

不知道大家是否认可这样的修正，以及是否有技术能人愿意写一段指令码来批次化执行这一修改。

再者，在含有褒扬令的篇目中，落款的总统、行政院院长部分其实也最好采用表格的方式去实现，以获得更好（保证对齐）的排印效果。如下方这般：

<blockquote style="border: 1px solid blue; padding: 0.5em 0.8em; display: flex;">
<div>
財政部前部長、臺灣期貨交易所股份有限公司董事長許虞哲，洽聞沖簡，素德清材。少歲卒業國立政治大學財稅學系暨財政研究所，旋負笈遊美，獲哈佛大學法學碩士學位，抱志懷才，濬瀹專攻。歷任臺北市稅捐稽徵處處長、五區國稅局局長暨賦稅署署長等職，張拓各項稽徵事宜，調降最高邊際稅率；實施證券交易所得課稅，營造優質租稅環境，折衝圖議，幹濟有聲。尤以出任財政部次長、部長期間，整合通關航港系統，研提電子發票載具；踐履開源節流要旨，置辦跨境電商稅制；釐訂國有財產法規，增益公共建設量能，極智窮思，振裘持領；迴籌轉策，通觀全局。嗣接掌臺灣期貨交易所，博求多元商品創新，簡化交易結算程序；加強風險控管措施，推升期貨市場榮景，謨慮運帷，蜚英騰茂。曾獲頒財政部一、二等財政獎章暨模範公務人員等殊榮。綜其生平，殫瘁臺灣稅務體系興革，丕奠國家財政發展利基，訏猷遠謀，令績遐舉；行誼世範，楷模垂芬。遽聞溘然殂殞，悼惜彌殷，應予明令褒揚，用示政府篤念邦賢之至意。
{| align="right"
| 總　　　統
| style="padding-left: 1em;" | [[蔡英文]]
|-
| 行政院院長
| style="padding-left: 1em;" | [[蘇貞昌]]
|}
</div>
</blockquote>

如果总统、行政院院长的区块需要与右边框留出一点距离，则可简单地在表格部分首行 align 属性右边添加右 margin 样式即可，这些都比如今使用的解决方案能够更好地保证排印效果（当然“总统”字样间的空格理论上亦可透过为“总”字添加 letter-spacing 来解决，也即写成 <span style="letter-spacing: 3em;">总</span>统 的样子，但就不如直接加入全形空格方便了）：

{| align="right" style="margin-right: 2em;"
| 總　　　統
| style="padding-left: 1em;" | [[蔡英文]]
|-
| 行政院院長
| style="padding-left: 1em;" | [[蘇貞昌]]
|}

--Boreas Sawada 2024年4月27日 (六) 03:49 (UTC)

建议不错，可以考虑建模板以规范显示效果。不过我有点怀疑刊出全文的正当性，原因有三：一，这难道不应该移至文库？二，所举条目吴新荣中这样的碑文不侵权？三，条目中以大篇幅给出褒扬令、纪念碑文全文有广告宣传之嫌，这要是大陆人物恐怕早就被移除了^{[开玩笑的]}。--Kcx36（留言） 2024年4月28日 (日) 18:59 (UTC)

Well… 我是一个“惯例主义者”（如果真的有这种东西的话），因此推崇尊重惯例 (convention)，尤其是在一个社群／社会上自发演化形成的惯例。（同时我也了解到中文维基并不推崇此类思想。）因此在如诸如此类的讨论上会天然地偏向于“维持现状、保持不变”。所以我不适合参与“改制”的讨论。对此就不发表意见了。
编辑：由于楼下误会，我特此声明：前段之回应与是否应当为褒扬令等蓝色框文字建立模板无关。是回应有关这类文字是否应该保留的部分的。--Boreas Sawada 2024年4月28日 (日) 21:57 (UTC)

• @Chu_Tse-tien：(：)回应：建模板并非是因为“它是惯例”而建的。建模板是指如果有存在某种格式、文字、或可（依条目主题）被程式运算的东西_{（见{{数字性质}}，已被广泛地用来产生数字条目中的部分条目内容）}、板型或模式等内容出现在了在多个条目，又或会在同一条目还会重复出现，则宜“模板化”方便管理（不然到时你改一个，要全部条目都改一遍；模板化了就只要改模板）。如果“褒扬令、碑文”出现在许多条目，且其样式（如CSS等）类似，则宜模板化。因此，并非因为“它是惯例”才建模板，而是很多条目都有相同东西，才“统整”成模板方便管理。因此建模板也算是“维持现状、保持不变”但加上“技术上”的东西来方便进行“管理与维护”，并不变更其内容。毕竟如果某件事“它是惯例”宜“整合管理”减少人力负担，并不意味著“不维持现状、没有保持不变”。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月28日 (日) 22:37 (UTC)

  这……我回应的显然不是关于建立模板的部分……--Boreas Sawada 2024年4月29日 (一) 01:57 (UTC)