用户讨论:A2569875/存档/2022年/7-9月
本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论,请在当前讨论页进行。 |
过去一个月(2022年4月1日至2022年4月30日)内,中文维基百科之重要人事及政策变动大致如下,个别项目基本依变动或施行时间先后排序:
方针与指引重要变动:重大的方针与指引修订。过去一个月内,互助客栈方针区共有方针与指引相关新提案23项,另有4项方针与指引相关提案获得通过:
- 《管理员的离任方针》:在〈长期没有活动解任〉一节中补充不活动管理员通知模板。(讨论纪录)
- 《一级行政区道路特殊收录限制列表》:增列英国公路之收录限制,并更名为《道路特殊收录限制列表》,指引范围不再限于一级行政区公路。(讨论纪录)
- 《繁简处理指引》:允许在适当情况下直接调整页面用字以修复错误之繁简转换,而无需再进行手工转换。(讨论纪录)
- 《过度分类指引》:将〈包含主观性的标准〉一节确立为指引。(讨论纪录)
其他方针与指引杂项修订,包括未于互助客栈方针区讨论而进行之小修改、方针与指引之相应修订或事实性修订等。请核查此等修订,若有需要,可提案至互助客栈方针区复议。
- 方针:《方针与指引》、《有偿编辑方针》、《破坏方针》、《管理员方针》、《可供查证方针》、《行政员方针》、《新页面巡查方针》、《侵犯著作权方针》、《用户名方针》、《共识方针》、《删除方针》、《命名常规》、《编辑禁制方针》、《忽略所有规则》、《文件使用方针》及《非原创研究方针》。
- 指引:《格式手册》、《签名指引》、《命名常规(音乐)》、《假定善意指引》、《不要伤害新手指引》、《格式手册(列表)》、《关注度指引(运动员)》、《重定向指引》、《格式手册(虚构)》、《申请成为管理人员指引》、《关注度指引(地理特征)》、《列明来源指引》、《关注度指引(学者)》、《可靠来源布告板评级指引》、《关注度指引(组织)》、《利益冲突指引》、《可靠来源指引》、《草稿命名空间指引》及《权限申请指引》。
其他重要社群动态:此处列出的动态虽不一定与正式方针或指引有关,惟对维基百科之社群或站务运作有一定影响。
- 社群决定就安全投票问题订立管理员选举暂行规定,惟相关规定细节尚待修订。(讨论纪录)
- Citation/CS1之Citation/CS1/Configuration、Whitelist及Identifiers等子模组获得更新,新增“name-list-style”与“url-access”参数,相容于既有参数(讨论纪录);后新增“chapter-url-access”与“map-url-access”参数,临时修复语言代码显示问题、改善模板显示方式,并进行大规模拆分整理,启用COinS、Error、People、Links及Language等子模组,并调整Configuration、Identifiers、Utilities及Whitelist等子模组,使主模组得以大幅精简。(讨论纪录)
- 过去一个月内,共有1名维基人获提名维基奖励并通过:老乔尼获授维基翻译专家。
模板 Vae2
看到你改了模板 {{Va}},模板{{Vae2}}应该也有同样的问题,主要用在WP:基础条目,麻烦有空看一下。--Kethyga(留言) 2022年8月18日 (四) 15:17 (UTC)
- (:)回应:@Kethyga:追踪了其引用的模板和模组,已修改两处Special:Diff/73268643和Special:Diff/73268660,麻烦有空复查下有无生效。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年8月18日 (四) 16:10 (UTC)
- 在Wikipedia:基础条目/第五级/人物/作家及撰稿人,Vae2 提示“Lua错误:too many expensive function calls。”,好像之前没有出现。--Kethyga(留言) 2022年8月19日 (五) 00:47 (UTC)
- @Kethyga:请阅读旧版Doc页(我没修改Doc页,旧版的{{Va}}也是重复用500次报错。Vae2旧版使用的功能不同 不会报错){{Va}}的Doc页template:Va/doc,里头有写到“本模版有使用魔术字……,此魔术字需要许多资源,因此同一页面此模版中出现超过500个,可能会无法正常显示”,如果你希望能解掉重定向问题,就无法避免模板限制。不可能鱼与熊掌一起兼得,要解决重定向问题就要承担模板限制后果、要解决模板限制问题就要放弃重定向问题的解决,如需在现况同时解决重定向和模板限制问题,请尝试拆分页面直到每页少于500次模板引用。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年8月19日 (五) 00:56 (UTC)
- 那感觉还是能够显示好一些,重定向的似乎没有那么多,之前提需求没想到现在的后果。--Kethyga(留言) 2022年8月19日 (五) 01:04 (UTC)
- @Kethyga:已暂时改回不识别重定向的版本,在Wikipedia:基础条目/第五级/人物/作家及撰稿人的WP:模板限制解决,但重定向问题重新出现。WP:模板限制的另一个解方是拆分Wikipedia:基础条目/第五级/人物/作家及撰稿人到每页500条目。哪个比较好(我不希望我程式白写了)-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年8月19日 (五) 01:19 (UTC)
- 抱歉,暂时没想到好办法。Wikipedia:基础条目/第五级/人物/作家及撰稿人或许可以像英维一样考虑由机器人更新 {{icon}},不用模板 {{Vae2}}。这个页面是翻译自英维,拆分后不方便比对。--Kethyga(留言) 2022年8月19日 (五) 02:09 (UTC)
- (:)回应@Kethyga:其实拆分也不难啊,先把{{Vae2}}中special:diff/73272611的
ignore_redirect=
改成no即抓取重定向模式,然后预览Wikipedia:基础条目/第五级/人物/作家及撰稿人页面,看哪个章节WP:模板限制爆掉了,就把那个章节拆分成诸如Wikipedia:基础条目/第五级/人物/作家及撰稿人/1然后再看看拆完后哪个章节WP:模板限制爆掉了,就把那个章节拆分成诸如Wikipedia:基础条目/第五级/人物/作家及撰稿人/2以此类推,直到所有模板正常显示,就可以了,反正页面太长也不方便阅读,如何?这样就能解决模板爆掉问题也能解决重定向问题,一举两得。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年8月19日 (五) 03:14 (UTC)- 基础条目第5级里,除了作家这个,其他的页面应该也有不少链出超过500的,比如Wikipedia:基础条目/第五级/人物/运动员,链出有将近12000,如果大动作改动感觉需要条目讨论。--Kethyga(留言) 2022年8月19日 (五) 03:21 (UTC)
- (:)回应@Kethyga:我更换了一下判定方式Special:Diff/73276547似乎可以绕过Wikipedia:模板限制#高开销解析器函数调用次数限制,但运算时间会长一些。目前看Wikipedia:基础条目/第五级/人物/运动员和Wikipedia:基础条目/第五级/人物/作家及撰稿人均能正常显示(使用重定向标示小工具看到是重定向的页面均有正常识别),您看看目前这样行不。因为怕运算时间会长一些会超时,所以想请您复查是否所有页面都没问题,如有问题我就再改回旧模式。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年8月19日 (五) 07:23 (UTC)
- 感谢。和其他条目相比,没有感觉到明显的网页卡顿。--Kethyga(留言) 2022年8月19日 (五) 07:41 (UTC)
- (:)回应@Kethyga:我更换了一下判定方式Special:Diff/73276547似乎可以绕过Wikipedia:模板限制#高开销解析器函数调用次数限制,但运算时间会长一些。目前看Wikipedia:基础条目/第五级/人物/运动员和Wikipedia:基础条目/第五级/人物/作家及撰稿人均能正常显示(使用重定向标示小工具看到是重定向的页面均有正常识别),您看看目前这样行不。因为怕运算时间会长一些会超时,所以想请您复查是否所有页面都没问题,如有问题我就再改回旧模式。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年8月19日 (五) 07:23 (UTC)
- 基础条目第5级里,除了作家这个,其他的页面应该也有不少链出超过500的,比如Wikipedia:基础条目/第五级/人物/运动员,链出有将近12000,如果大动作改动感觉需要条目讨论。--Kethyga(留言) 2022年8月19日 (五) 03:21 (UTC)
- (:)回应@Kethyga:其实拆分也不难啊,先把{{Vae2}}中special:diff/73272611的
- 抱歉,暂时没想到好办法。Wikipedia:基础条目/第五级/人物/作家及撰稿人或许可以像英维一样考虑由机器人更新 {{icon}},不用模板 {{Vae2}}。这个页面是翻译自英维,拆分后不方便比对。--Kethyga(留言) 2022年8月19日 (五) 02:09 (UTC)
- @Kethyga:已暂时改回不识别重定向的版本,在Wikipedia:基础条目/第五级/人物/作家及撰稿人的WP:模板限制解决,但重定向问题重新出现。WP:模板限制的另一个解方是拆分Wikipedia:基础条目/第五级/人物/作家及撰稿人到每页500条目。哪个比较好(我不希望我程式白写了)-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年8月19日 (五) 01:19 (UTC)
- 那感觉还是能够显示好一些,重定向的似乎没有那么多,之前提需求没想到现在的后果。--Kethyga(留言) 2022年8月19日 (五) 01:04 (UTC)
- @Kethyga:请阅读旧版Doc页(我没修改Doc页,旧版的{{Va}}也是重复用500次报错。Vae2旧版使用的功能不同 不会报错){{Va}}的Doc页template:Va/doc,里头有写到“本模版有使用魔术字……,此魔术字需要许多资源,因此同一页面此模版中出现超过500个,可能会无法正常显示”,如果你希望能解掉重定向问题,就无法避免模板限制。不可能鱼与熊掌一起兼得,要解决重定向问题就要承担模板限制后果、要解决模板限制问题就要放弃重定向问题的解决,如需在现况同时解决重定向和模板限制问题,请尝试拆分页面直到每页少于500次模板引用。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年8月19日 (五) 00:56 (UTC)
- 在Wikipedia:基础条目/第五级/人物/作家及撰稿人,Vae2 提示“Lua错误:too many expensive function calls。”,好像之前没有出现。--Kethyga(留言) 2022年8月19日 (五) 00:47 (UTC)
您提交的草稿2i已被接受
它被评级为乙级,可在条目的讨论页上查看。对于新条目而言,这是一个很棒的评级,代表本条目的质量在被接受的条目草稿中排在前2%,恭喜您!您可以看看Wikipedia:条目质量评级标准以便了解如何进一步改进该条目。
您可以继续不断改善它,维基百科的条目没有最终版本。非常欢迎您继续为维基百科做出高质量的贡献。
感谢您帮助改进维基百科!
🎋🍣 2022年8月20日 (六) 04:23 (UTC)Re: DYK疑似点票故障
您好,这是因为 阁下于投票结束后才修改题目,这会导致点票结果被撤销,这样的设计是因为如果有人在投票结束后对题目进行破坏,被破坏的题目不会自动登上首页。现已人手重新批准。谢谢关注!--街燈電箱150號 开箱维修 抄表 检验证明 2022年8月29日 (一) 07:23 (UTC)
- 类别最后的字母是为了疏道而人手添加的,并非错误,这通常是多个同类条目同时结束且其他类型已结束的条目数量不多的时候就会有此操作,以免出现更新瘫痪。--街燈電箱150號 开箱维修 抄表 检验证明 2022年8月31日 (三) 10:51 (UTC)
负数的移动
抱歉未留意到导航模板处的变化,添麻烦了。--Lt2818(留言) 2022年9月2日 (五) 09:19 (UTC)
- @Lt2818:建议移动回去,因为模板背后是编程语言(维基百科是用php写成的,不是用“自然语言”构造的),见连字暨减号的说明:“绝大部分编程语言只能使用ASCII,故只能以连字暨减号,而非Unicode字元U+2212 − MINUS SIGN表达数字相减和负数。”是技术限制,输入U+2212 − MINUS SIGN只会Error(例如U+2212 − MINUS SIGN:
<math>−3</math>
→“解析失败 (语法错误): {\displaystyle −3} ”、连字暨减号:<math>-3</math>
→“”),负数的输出也定是连字暨减号,所以所有由模板输出的数字都无法显示成“U+2212 − MINUS SIGN”只能是连字暨减号,尝试修了一个下午修不好(应该说现有框架下根本没有可下手处),而且连字暨减号也并非“不是减号”,它们是“暨减号”。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月2日 (五) 09:24 (UTC)
- 对Special:PermaLink/73481035确实抱歉,未曾留意。
- 我在User:Lt2818/沙盒测试了一下,似乎Module输入输出U+2212都是可行的?只是模板、模块的编写要麻烦一些。
- 关于先到先得的部分,当前的NC:先到先得措辞我有参与修改,个人的理解是它只适用于地区词差异的处理。
- 改用U+2212有争议的话,我想提到客栈讨论比较合适,或许能写进Wikipedia:格式手册/日期和数字加以规范。这几日会比较忙,计划在数日后提出。
--Lt2818(留言) 2022年9月2日 (五) 09:58 (UTC)
- @Lt2818:您误会了我说的输出的意思,我是说一个整数的资料型态,若储存负二,那么tostring()后(Module会将number输出后执行tostring)只会是连字暨减号,不会是U+2212 − MINUS SIGN,这就是我说的技术限制;另一方面U+2212 − MINUS SIGN输入tonumber()也只会出错,变nil。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月2日 (五) 10:01 (UTC)
- 我知道程式中如此。但编程中使用的符号与一般情形不大一样,亦不止此例,如除法用/,幂运算用^,不见得百科内容要去就程式写法吧。--Lt2818(留言) 2022年9月2日 (五) 10:07 (UTC)
- @Lt2818:负整数#部分的负整数就是仰赖模板自动输出,所以只能以编程语言输出的模式。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月2日 (五) 10:10 (UTC)
- 我知道程式中如此。但编程中使用的符号与一般情形不大一样,亦不止此例,如除法用/,幂运算用^,不见得百科内容要去就程式写法吧。--Lt2818(留言) 2022年9月2日 (五) 10:07 (UTC)
- @Lt2818:“改用U+2212有争议的话”并不是说有争议,是你的操作“你把模板弄坏了”,没坏别修,但是你没事随意操作让他坏掉了??原本就没事,也没坏,你干嘛移动?你这样移用 反而东西都坏掉了。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月2日 (五) 10:08 (UTC)
- 依然强烈建议移动回去,不然现在变为模板subst展开掉的模式实在不利维护。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月2日 (五) 10:21 (UTC)
- @Lt2818:实务上根本不可能做到数字的tostring负号变成是U+2212,所以我干脆直接写一个全文字串转换函数直接将“-”硬转成U+2212,Special:Diff/73488787。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月2日 (五) 14:37 (UTC)
- 太好了。我对Module不大熟悉,由我完成的话估计需要更多时间。--Lt2818(留言) 2022年9月2日 (五) 15:16 (UTC)
- 反向转换应该就能让模板/模块接纳U+2212了。您认为是否有必要在格式手册中统一规定负号的码点?如果感觉必要性不大的话我就不去提了。--Lt2818(留言) 2022年9月18日 (日) 14:40 (UTC)
- @Lt2818:“反向转换应该就能让模板/模块接纳U+2212了”不认为。你这样一搞,程式码代码都要变得很难看,还要“牵套”一层转换,计算时又要再转换过去算完要转换回来,整个代码变得乱七八糟的,可读性可预期极差,且无故转来转去,浪费效能,导致模板更容易遇到WP:模板限制,而且不排除还有其他因技术限制无法透过文字转换解决的Case,例如
<math>−3</math>
→“解析失败 (语法错误): {\displaystyle −3} ”(<math></math>
在模块阶段会变成mw:Strip marker而无法读到里面的内容,因此无法执行文字替换),因此我十分(-)反对这种作法。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月18日 (日) 14:48 (UTC)- 我的想法是这样,模板/模块类似于程式,输入参数一般也一样用U+002D - HYPHEN-MINUS。上面说的反向转换只适用于少数情况,譬如像Template:整数直接读页面名称的时候。--Lt2818(留言) 2022年9月18日 (日) 15:18 (UTC)
- @Lt2818:其实Template:整数是假的,他是用“-”算完之后才强制替换为U+2212 − MINUS SIGN。这明显会出问题,没出问题只是“-”和U+2212 − MINUS SIGN都有重定向页而已。没道理要为了这个奇怪的坚持,建立一大堆不必要的重定向页。--! 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月18日 (日) 15:22 (UTC)
- 您这段话里的U+002D感觉不大对,我理解为U+2212。我看您在−3内文中也用的U+2212,把这个符号用在百科内容(而非程式代码)中应该是没问题的。--Lt2818(留言) 2022年9月18日 (日) 15:30 (UTC)
- @Lt2818:模板的Infobox中的导航内部输入的数值有给定“num = -3”,所以它是用“-1、-2、-3、-4.....”计算完后才强制变成“−1、−2、−3、−4.....”。所以他是用“-”算完之后才强制替换为U+2212 − MINUS SIGN。这明显会出问题,没出问题只是“-”和U+2212 − MINUS SIGN都有重定向页而已。没道理要为了这个奇怪的坚持,建立一大堆不必要的重定向页。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月18日 (日) 15:33 (UTC)
- 模板内部的过程我大体上知道的。感觉您在上述两段留言中混淆了U+002D - HYPHEN-MINUS与U+2212 − MINUS SIGN,因而我的留言可能未得到正确理解。--Lt2818(留言) 2022年9月18日 (日) 15:41 (UTC)
- @Lt2818:模板的Infobox中的导航内部输入的数值有给定“num = -3”,所以它是用“-1、-2、-3、-4.....”计算完后才强制变成“−1、−2、−3、−4.....”。所以他是用“-”算完之后才强制替换为U+2212 − MINUS SIGN。这明显会出问题,没出问题只是“-”和U+2212 − MINUS SIGN都有重定向页而已。没道理要为了这个奇怪的坚持,建立一大堆不必要的重定向页。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月18日 (日) 15:33 (UTC)
- 您这段话里的U+002D感觉不大对,我理解为U+2212。我看您在−3内文中也用的U+2212,把这个符号用在百科内容(而非程式代码)中应该是没问题的。--Lt2818(留言) 2022年9月18日 (日) 15:30 (UTC)
- @Lt2818:其实Template:整数是假的,他是用“-”算完之后才强制替换为U+2212 − MINUS SIGN。这明显会出问题,没出问题只是“-”和U+2212 − MINUS SIGN都有重定向页而已。没道理要为了这个奇怪的坚持,建立一大堆不必要的重定向页。--! 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月18日 (日) 15:22 (UTC)
- 我的想法是这样,模板/模块类似于程式,输入参数一般也一样用U+002D - HYPHEN-MINUS。上面说的反向转换只适用于少数情况,譬如像Template:整数直接读页面名称的时候。--Lt2818(留言) 2022年9月18日 (日) 15:18 (UTC)
- @Lt2818:“反向转换应该就能让模板/模块接纳U+2212了”不认为。你这样一搞,程式码代码都要变得很难看,还要“牵套”一层转换,计算时又要再转换过去算完要转换回来,整个代码变得乱七八糟的,可读性可预期极差,且无故转来转去,浪费效能,导致模板更容易遇到WP:模板限制,而且不排除还有其他因技术限制无法透过文字转换解决的Case,例如
- @Lt2818:您误会了我说的输出的意思,我是说一个整数的资料型态,若储存负二,那么tostring()后(Module会将number输出后执行tostring)只会是连字暨减号,不会是U+2212 − MINUS SIGN,这就是我说的技术限制;另一方面U+2212 − MINUS SIGN输入tonumber()也只会出错,变nil。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月2日 (五) 10:01 (UTC)
- @Lt2818:总而言之,您的意思是 内部参数仍是用U+002D - HYPHEN-MINUS,但百科内文显示是使用/想办法让他输出U+2212 − MINUS SIGN吗?-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月18日 (日) 15:59 (UTC)
- 是这样的,正和
<math>-3</math>
输入输出的形式一样。像Template:Weather box则是二者皆可输入,但只会输出U+2212。--Lt2818(留言) 2022年9月18日 (日) 16:38 (UTC)- @Lt2818:如果能证明没有技术上的疑虑的话你就去提议格式手册修订案吧。但是需要强调“由于技术限制,输入模板的参数可能会需要使用U+002D - HYPHEN-MINUS,但仅要确保输出为U+2212 − MINUS SIGN即可”,另外不建议把模板直接改成输出U+2212 − MINUS SIGN,因为如果模板结果要被“再计算”或“再输入到其他模板”那么就会出错,建议的作法是像Template:整数那样提供一个专门用来转换的模板,等所有计算都计算完毕之后,确定下一步就是百科内文时,才使用转换模板。如可能,也把我们这段讨论连结过去给其他维基人参考。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月18日 (日) 17:00 (UTC)
- 初步想法是引入en:MOS:MINUS,但我不确定二元运算符号两侧是否加空格,需要研究一下。--Lt2818(留言) 2022年9月19日 (一) 01:55 (UTC)
- @Lt2818:如果能证明没有技术上的疑虑的话你就去提议格式手册修订案吧。但是需要强调“由于技术限制,输入模板的参数可能会需要使用U+002D - HYPHEN-MINUS,但仅要确保输出为U+2212 − MINUS SIGN即可”,另外不建议把模板直接改成输出U+2212 − MINUS SIGN,因为如果模板结果要被“再计算”或“再输入到其他模板”那么就会出错,建议的作法是像Template:整数那样提供一个专门用来转换的模板,等所有计算都计算完毕之后,确定下一步就是百科内文时,才使用转换模板。如可能,也把我们这段讨论连结过去给其他维基人参考。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️) 2022年9月18日 (日) 17:00 (UTC)
- 是这样的,正和
Re: 走迷宫算法问题明显恰当
您好!如果那边之后无更多意见,我会在过了2022年9月12日07:55(UTC)之后以人手方式批准通过。另外也请 阁下稍安毋躁,对方若没有再上线即使再三留言催促也没有作用。敬请留意,谢谢关注!--街燈電箱150號 开箱维修 抄表 检验证明 2022年9月12日 (一) 06:23 (UTC)
Re:请见谅
原谅鄙人因近期现实事物繁忙而仅留言指出问题不当后则无上线。若管理员认为走迷宫算法明显恰当则鄙人也无异议。其实依中华民国教育部国语词典、线上剑桥词典(即Argothm)较多地将算法指为“计算之方式”或“计算机科学相关解析”,然查阅韦氏词典才知亦有“为广义为解决问题的步骤”,先前未认知尚有相关概念,亦为本人才疏学浅之过,望见谅。感谢指出。——咏梅阁—WMLO(留言) 2022年9月12日 (一) 13:24 (UTC)
过去一个月(2022年5月1日至2022年5月31日)内,中文维基百科之重要人事及政策变动大致如下,个别项目基本依变动或施行时间先后排序:
方针与指引重要变动:重大的方针与指引修订。过去一个月内,互助客栈方针区共有方针与指引相关新提案18项,另有4项方针与指引相关提案获得通过:
- 《格式手册(虚构)》:依据社群讨论结果,正式订立虚构事物相关条目之格式手册,优先适用于既有之《格式手册》(讨论纪录);后因行文问题而取消指引地位,重新进行修订。(讨论纪录)
- 《申请成为管理人员指引》:经社群讨论通过,订立安全投票暂行规定,适用于未来一场管理员选举。(讨论纪录)
- 《草稿命名空间指引》:修订〈准备草稿〉一节,新增使用Draft categories模板处理草稿内分类的方法。(讨论纪录)
- 《COVID-19条目共识》:移除不影响共识效力之冗余叙述。(讨论纪录)
其他方针与指引杂项修订,包括未于互助客栈方针区讨论而进行之小修改、方针与指引之相应修订或事实性修订等。请核查此等修订,若有需要,可提案至互助客栈方针区复议。
- 方针:《回退功能方针》、《新页面巡查方针》、《机器人方针》、《大量账号建立者方针》、《档案移动员方针》、《模板编辑员方针》、《界面管理员方针》、《行政员方针》、《管理员方针》、《忽略所有规则》、《共识方针》、《中立的观点方针》、《避免地域中心方针》、《可供查证方针》、《不要人身攻击方针》、《删除方针》、《非原创研究方针》、《编辑禁制方针》、《侵犯著作权方针》、《命名常规》、《生者传记方针》、《破坏方针》、《封禁方针》、《用户查核方针》、《傀儡方针》、《用户名方针》及《维基百科不是什么》。
- 指引:《关注度指引(学者)》、《关注度指引(运动员)》、《格式手册(日期和数字)》、《列明来源指引》、《消歧义指引》、《外部链接指引》、《关闭存废讨论指引》、《关注度指引(交通)》、《可靠来源布告板评级指引》、《关注度指引(人物)》、《不要伤害新手指引》、《格式手册(列表)》、《页面分类指引》、《申请成为管理人员指引》、《拉票指引》、《格式手册(版面布局)》、《可靠来源指引(医学)》、《翻译指引》、《地区词处理指引》、《重定向指引》、《格式手册》、《过度分类指引》及《繁简处理指引》。