维基百科讨论:结构式讨论/存档1
本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论,请在当前讨论页进行。 |
- 由于开启讨论后7日支持者多数,目前也无反对意见,本案进入公示7日阶段。台湾杉在此发言 (会客室) 2017年11月7日 (二) 04:35 (UTC)
- 最好在这里把需要改的地方全部列出来,否则讨论通过了也不会有人去改。--A2093064→Xiplus 2017年11月7日 (二) 04:46 (UTC)
- 我今天才看到这个讨论,但是早已经按移动请求移动完毕了。Bluedeck 2017年11月13日 (一) 17:18 (UTC)
- 最好在这里把需要改的地方全部列出来,否则讨论通过了也不会有人去改。--A2093064→Xiplus 2017年11月7日 (二) 04:46 (UTC)
- 共识通过,部分页面已于公示期间移动完成,请管理员移动结构式讨论的测试页面至“Wikipedia talk:结构式讨论沙盒”。台湾杉在此发言 (会客室) 2017年11月14日 (二) 06:50 (UTC)
如何对Flow(结构式讨论)的话题请求快速删除?
该如何对Flow的一个话题(Topic)请求快速删除?因为在上面放置模板不会进到Category:快速删除候选,我觉得最适合的请求位置应该是Wikipedia:修订版本删除请求了。目前似乎没有适合的处理方式,因此提出讨论。--Xiplus#Talk 2018年1月14日 (日) 08:56 (UTC)
我觉得可以在VFD处提出快删。Bluedeck 2018年1月14日 (日) 22:37 (UTC)
放在摘要里。如果放在摘要跟描述页的模板,如果该模板有分类,是会显示的。-- Willy1018(留言) 2018年1月15日 (一) 05:26 (UTC)
- 原来如此,那这个是没问题了。那么想要单独删除一则留言的话呢?--Xiplus#Talk 2018年1月15日 (一) 07:47 (UTC)
- VFD说的就是删除一则留言的情况。因为模版请求的是整个页面的删除,VFD则可以任意请求删除的目标,或者像你说的那样RRD也行。Bluedeck 2018年1月15日 (一) 19:06 (UTC)
- 那我还是觉得RRD更适合删除一则留言的情况,比较接近deltalk+RD。--Xiplus#Talk 2018年1月17日 (三) 15:19 (UTC)
将在Wikipedia:修订版本删除请求制作供Flow删除单一则留言的提报表单。--Xiplus#Talk 2018年1月24日 (三) 08:34 (UTC)
新手使用Flow讨论页的问题
如题。我最近发现很多新手在参数设置里不明就里地打开了“用户讨论页上的结构式讨论”这一选项,在自己的用户讨论开启Flow。但是,Flow本身对于twinkle等站务工具和需要发送通知的机器人不是很友好,而新手也不需要很频繁地交流,因而普遍也不太需要像flow这样的讨论工具。除此之外,就我个人站内站外与新手的接触,flow还有这些问题:
- 因为部分工具和机器人不支持flow,会导致新手漏接重要通知(现在在测试页面上的确有提示,但新手不会意识到这个问题的严重性)。
- 在缺省设置下,flow上的新帖子、新回复留言是不会发送电子邮件提示的。只有当登录到站内,才会看到右上方小铃铛和收件匣的图标上有数字提示。这不利于新手收悉警告、存废讨论通知、封禁通知等。
- Flow与一般讨论页差异较大,会让新手无法适应、学习诸如四个波浪线代表签名等维基人都应该会的讨论页使用方法。
- Flow的纯代码编辑和可视化编辑之间界限模糊,部分subst替换引用模板不能正确展开
- 被封禁时,新手必须要把{{unblock}}封禁申诉模板给放到“关于此板块”“描述”一栏,才会被加入到Category:封禁及禁制申诉这一分类中,封禁申诉才能被其他管理员看到。然而大多数人都不知道这一点。这类被封禁的新手,有时收不到管理员送的封禁通知,有时加上去的unblock模板会被flow当成可视化编辑部分,给自动加上
<nowiki>
标签,没法正确显示;即使这两点都弄对了,也因为没有放到描述栏里,管理员根本看不到。如果没有老手监视了这个被封禁的新手的用户讨论页,并且正确地将unblock模板移动到描述栏,那么这个新手的封禁申诉没人能看到。 - Flow的监视也是一个问题。简而言之,与一般使用wikitext的页面相比不太好适应。
如果要着手解决的话,我想可以让已经转换为flow的用户,重开一个使用wikitext的讨论页;或是移除测试功能里的flow开关,让有需要用flow的用户自己申请。不知各位有何看法? --Techyan(留言) 2019年7月11日 (四) 23:50 (UTC)
- 在下觉得 flow 讨论板才是 mediawiki 讨论功能的未来趋势,应该欢迎用户继续测试和熟悉,所以我(-)反对移除这个测试开关。至于上面几个问题,在目前这个阶段,我建议为 opt in 的用户建立额外的 flow 讨论页,保留原有 wikitext 讨论页位置不变,但签名和用户界面导入 flow 版供人类使用。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月12日 (五) 13:12 (UTC)
- 我是觉得flow很不好使用啦,至少我的体验不是很理想。 --无心*插柳*柳橙汁 2019年7月12日 (五) 14:02 (UTC)
- 我非常同意这个做法。我预期flow很快就会废掉。산모사 DC17 2019年7月13日 (六) 15:17 (UTC)
- @Sanmosa:应该不会,参考这里。其他意见(▲▲)同上上--Cohaf(talk) 2019年7月13日 (六) 15:21 (UTC)
- Flow的初衷不就是为了新手么?--百無一用是書生 (☎) 2019年7月15日 (一) 06:37 (UTC)
- 在封禁申诉这件事情上,初衷和实际使用便利性相反了。我记得有老的维基人都碰到过这种问题,讨论页申诉没放在描述栏目导致无人理会。--云间守望 2019年7月16日 (二) 12:44 (UTC)
- 如果原因是部分工具和机器人不支持flow,那么应该去修改部分工具和机器人,而不是折腾FLOW--百無一用是書生 (☎) 2019年7月17日 (三) 07:56 (UTC)
- (!)意见 如果问题只是在封禁申诉上,修改一下封禁模板提示开启过 flow 的用户把 unblock 模板放在页面右方的“描述”处不就行了?没必要大幅更改 flow 的使用方式。或者干脆就模仿英文维基百科搞一个 UTRS,完全绕开讨论页。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月18日 (四) 07:17 (UTC)
- 但那其实是连到这个网站-- Sunny00217 - 2019年7月22日 (一) 01:28 (UTC)
- 典型的原则与现实问题。原则上flow很好用,实际上社群没有相应的技术支援。建议将这个问题丢回给WMF,叫他们聘请工程师负责小工具现代化。或者外包给社群的技术组也可以。UTRS当然很好,我大力鼓励提案者写一个出来贡献社群。--Temp3600(留言) 2019年7月19日 (五) 03:07 (UTC)
- 不对吧?小工具和机器人绝大多数都是用户开发的,为何要把责任推给wmf?难道以后网站的任何技术更新影响到了小工具和机器人的运作,wmf都要背锅?这说不通啊。原来没有而新增加/改变的的东西,小工具和机器人的开发者不去更新代码跟上变化,而要wmf负责,这说到哪里去都说不通--百無一用是書生 (☎) 2019年7月19日 (五) 03:28 (UTC)
- 不如请阁下贡献社群,领头负责重写这一批重要的小工具?--Temp3600(留言) 2019年7月19日 (五) 18:46 (UTC)
- 不对吧?小工具和机器人绝大多数都是用户开发的,为何要把责任推给wmf?难道以后网站的任何技术更新影响到了小工具和机器人的运作,wmf都要背锅?这说不通啊。原来没有而新增加/改变的的东西,小工具和机器人的开发者不去更新代码跟上变化,而要wmf负责,这说到哪里去都说不通--百無一用是書生 (☎) 2019年7月19日 (五) 03:28 (UTC)
- 个人觉得暂时取消选项,等上面的问题处理完后再恢复-- Sunny00217 - 2019年7月21日 (日) 14:20 (UTC)
- 本来这种事情就是自愿的事情。原来开发的人不想写这个功能了,或者放弃维护了,为何别人就必须要接手?小工具和机器人本来就应该是辅助性质的,现在似乎变得过于依赖这些工具了--百無一用是書生 (☎) 2019年7月23日 (二) 12:58 (UTC)
- 不能够要求社群回去钻木取火的年代。没了TW,不少人连各样常用代码的模版恐怕也记不住呢。DYK没了机器人,导致春卷要天天顾着更新。现在社群的运作方式是建基于这些工具能够使用的份上。--Temp3600(留言) 2019年7月23日 (二) 17:23 (UTC)
- 本来这种事情就是自愿的事情。原来开发的人不想写这个功能了,或者放弃维护了,为何别人就必须要接手?小工具和机器人本来就应该是辅助性质的,现在似乎变得过于依赖这些工具了--百無一用是書生 (☎) 2019年7月23日 (二) 12:58 (UTC)
- 其实很大的问题是这些工具的维护性问题,例如Jimmy的TW好像到现在都没有对flow的支持(而且维护间隔周期也相当长),而据悉某个个人修改过的TW已经支持flow了。大部分机器人(尤其早期由L大和jimmy开发的)在不涉及影响隐私的情况没有公开源代码,所以一旦维护者不再维护而出现问题时,会影响很多配套工作。当然不反对flow也存在一些问题,例如解封申请的分类不能在flow根页(每个话题其实是独立的“子”页)显示,繁简问题(好像是因为繁简转换的模块是硬编码处理快输出的html,所以无法转移到其他项目上)等。——路过围观的Sakamotosan | 避免做作,免敬 2019年7月24日 (三) 01:09 (UTC)
- 才女我记得能公开的都公开了?jimmy嘛...不与置评。--Temp3600(留言) 2019年7月24日 (三) 15:28 (UTC)
- 我试过了,Xiplus和Kuon.Haku的Twinkle 支援 flow,社群也没有必要重复发明轮子了,不如将其合并到官方版 Twinkle 里。至于 UTRS,如果社群认为有必要,我可以帮忙把英文那个 port 过来(当然,有更简单的解决办法)。至于机器人,既有的只能看他们的主人,我建议从现在开始要求所有新的机器人(与讨论页有关的)必须支持 flow 才能获得批准 -- Vakrieger♀︎ -- 💢❤️🗯️ 2019年7月27日 (六) 05:13 (UTC)
移除Special:测试功能里的Flow开关
承接上一次在Wikipedia_talk:结构式讨论/存档#新手使用Flow讨论页的问题的讨论,再次提请社群讨论移除“测试功能”中开启Flow的选项。最近一段时间我发现,很多新手刚注册维基帐号之后,总是会顺手打开测试功能里的所有选项。这对于新手来说,无论是从封禁申诉等诸多方面而言,都是不利的。另外,社群里一些维基人担心移除掉这个开启Flow的选项等于从中文维基百科里卸载Flow,或是自己的用户讨论页就不能再开启Flow了。事实上管理员除了这个选项之外,还可以从Special:EnableFlow这个页面开启flow。届时用户可以到互助客栈求助版让管理员开启flow,或是私下请求。至于使用Flow不利于新手的原因,请见原先的讨论。--Techyan(留言) 2019年9月4日 (三) 09:31 (UTC)
- (+)支持,况且看的碍眼-- Sunny00217 2019年9月4日 (三) 12:02 (UTC)
- 仍然要说的是,Flow的本意就是方便新手。如果某些脚本工具不支持,要改进的是这些脚本工具,如果没人愿意改这些脚本工具,那不是Flow的问题--百無一用是書生 (☎) 2019年9月5日 (四) 02:09 (UTC)
- 没人改进脚本工具说明Flow体系仍未成熟。不能够说Harmony 设计上比Android好用就要求全体搬移吧。--Temp3600(留言) 2019年9月5日 (四) 03:25 (UTC)
Flow无法使用wikitext
是否有办法解决,注意,我是被本地封禁--ℑ𝔪𝔭𝔞𝔯𝔱𝔦𝔞𝔩 𝔧𝔲𝔰𝔱🎙️ 2021年1月23日 (六) 07:06 (UTC)
- @impartial just:这是Flow的问题,可以上P站报告。
还有,你为何可以在被本地封禁的时候在这发言的?--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2021年1月24日 (日) 08:09 (UTC)- flow不再继续开发了,即使报告应该也无济于事。--安忆Talk 2021年1月24日 (日) 12:54 (UTC)
- 刚看到,global ip except,sorry--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2021年1月24日 (日) 08:10 (UTC)
- @Emojiwiki:我认为先暂时改为纯文字吧!--ℑ𝔪𝔭𝔞𝔯𝔱𝔦𝔞𝔩 𝔧𝔲𝔰𝔱🎙️ 2021年1月24日 (日) 12:44 (UTC)
- 那应该要用到
{{isFlow}}
-- Sunny00217 2021年1月25日 (一) 15:52 (UTC)
- 那应该要用到
- @Emojiwiki:我认为先暂时改为纯文字吧!--ℑ𝔪𝔭𝔞𝔯𝔱𝔦𝔞𝔩 𝔧𝔲𝔰𝔱🎙️ 2021年1月24日 (日) 12:44 (UTC)
限制flow-hide权限到自动确认用户
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
Flow(结构式讨论)的默认设定是任何用户都可以隐藏话题和帖子。鉴于之前有一些LTA滥用该功能来搞破坏,但Flow的功能不完善导致这些破坏难以拦截和清理,因此提议收回相关权限即flow-hide权限给自动确认用户。
注:这是一个先斩后奏的提案,在LTA搞破坏的时候已经紧急执行了,但不能一直这样下去,需要看看社群的意见是否允许这个权限设定常态化。--砜中嘌呤的白磷萃取 打谱 2022年5月5日 (四) 03:27 (UTC)
- 至少在 (1) 过滤器可以阻止flow-hide操作 及 (2) 管理员可以删除/隐藏相关破坏 前应继续限制flow-hide权限为自动确认使用者。--Xiplus#Talk 2022年5月5日 (四) 05:00 (UTC)
- 同Xiplus君。--SCP-0000(留言) 2022年5月5日 (四) 10:06 (UTC)
- (+)支持。另外我个人觉得整个结构式讨论都应该废掉 :P —— Eric Liu 創造は生命(留言・留名・学生会) 2022年5月5日 (四) 12:05 (UTC)
- @WhitePhosphorus:我觉得直接把这临时安排变成常规安排没大问题,因为非自动确认用户没有需要flow-hide权限的显著需求。(节删) 2022年5月5日 (四) 12:20 (UTC)
- 猫老师说得对。 Stang★ 2022年5月5日 (四) 15:10 (UTC)
- 同Xiplus。--YFdyh000(留言) 2022年5月5日 (四) 15:31 (UTC)
- 公示7日。这个东西应该也不需要改什么现有的页面,就单纯删几行注释。 Stang★ 2022年5月11日 (三) 16:24 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
在中文维基百科逐步弃用结构式讨论
首先我根据phab:T332022,总结弃用的必要性:
- SD(Structured Discussions,结构式讨论)破坏了进阶用户的工作流程,包括自动化工具需要适配两套讨论和一些模板不能正常使用等,具体可见上面存档中Techyan-2019-07-11T23:50:00.000Z-新手使用Flow讨论页的问题
- 维护SD会消耗WMF的资源:代码巨大、复杂、难以理解,所有与讨论页的交互需要两套实现…………
- 实现不完整,缺少重要功能,有许多bug和安全风险(该工具在2015年暂停开发)
- 有的页面启用了SD,有的没有,用户不得不学习两种界面的用法,对新手不友好
另外,已有Discussion Tools可替代SD。
以下是提案内容。
第一部分,禁用新的SD。1.通过phab:T248309:新用户和现在没有开启的已有用户不能开启SD,开启的已有用户可在测试功能中永久关闭SD。2.社群不再建立新的SD页面。
第二部分,逐步禁用已有的SD。
似乎SD包含将SD页面转化为普通wikitext页面的功能(phab:T332103),希望有人调查一下是否可以使用、如何使用,这一功能是无损转换的关键。在结果明确之前,弃用的页面应该按照现行的方法转为存档。如果这一功能可以使用,应该将存档和新弃用的页面转为普通wikitext页面。如果不可使用,建议通过修改用户组权限,只允许特定用户组编辑。(此段内容请在专门章节讨论)
以下是不同种类的弃用方案:
- 对于活跃用户,要求在2年内自主决定弃用SD。不活跃用户,在发通知之后3个月统一弃用SD。(考虑用户对自己用户空间的自主权)
- 对于其他的讨论页面,挂上通知之后一段时间删除,时间长短由使用频度多少确定。
暂时不知道如何统计到底有那些SD页面,希望有人能调查一下。YFdyh000:5.4万个SD页面[1]
以上。——落花有意12138 2023年10月2日 (一) 10:23 (UTC)
- (+)支持,结构式讨论太难用了,如果想看以前的讨论,就得不停滚动鼠标滚轮。--意面混凝土(留言) 2023年10月4日 (三) 09:29 (UTC)
- 而且不能搜索--意面混凝土(留言) 2023年10月4日 (三) 09:31 (UTC)
Hoben7599同意提案——落花有意12138 2023年10月3日 (二) 04:09 (UTC)
|
---|
|
- 赞成停止新建和新开。应暂时允许关闭的用户重新开启。转换为普通页面和后续关闭,是否编辑历史会永久丢失,是否会有解决方案。除非技术人员给出时间表,否则不建议本地决定时间表。--YFdyh000(留言) 2023年10月3日 (二) 02:32 (UTC)
- 我没有找到时间表,相关的task已经有一段时间没有活动了,希望有人问一问。--落花有意12138 2023年10月3日 (二) 04:34 (UTC)
- 基金会正准备相关讨论,如无意外相信几个月后便会展开。个人认为到时再讨论如何弃用结构式讨论也未晚,现时此讨论可先搁置。谢谢。--SCP-0000(留言) 2023年10月7日 (六) 08:57 (UTC)
- @SCP-2000
- 不出意外的话,应该要出意外--意面混凝土(留言) 2023年10月7日 (六) 09:47 (UTC)
- 基金会正准备相关讨论,如无意外相信几个月后便会展开。个人认为到时再讨论如何弃用结构式讨论也未晚,现时此讨论可先搁置。谢谢。--SCP-0000(留言) 2023年10月7日 (六) 08:57 (UTC)
- 我没有找到时间表,相关的task已经有一段时间没有活动了,希望有人问一问。--落花有意12138 2023年10月3日 (二) 04:34 (UTC)
- 似乎总约5.4万个SD页面[2]--YFdyh000(留言) 2023年10月3日 (二) 03:04 (UTC)
- 第一点理论上可以无害进行(阻止增量),但第二点技术上是否可行(消耗存量)?有点技术性质需要的讨论。——Sakamotosan路过围观 | 避免做作,免敬 2023年10月3日 (二) 03:22 (UTC)
- 总结了部分发言到提案。为了明确讨论结构,总结并折叠了已经得出结论的讨论,如果觉得不妥可自行移除。——落花有意12138 2023年10月3日 (二) 04:09 (UTC)
- 问:所以用户子页的结构式讨论页也将一并废除?--在下荷花,请多指教(欢迎签到) 2023年10月3日 (二) 12:40 (UTC)
- 是--YFdyh000(留言) 2023年10月7日 (六) 07:13 (UTC)
- 同意废除,这玩意简直莫名其妙,对手机端用户超级不友好。——Aggie Dewadipper 2023年10月9日 (一) 07:04 (UTC)
- 终于有人提到手机端了--意面混凝土(留言) 2023年10月9日 (一) 13:15 (UTC)
- 同意废除,这玩意简直莫名其妙,对手机端用户超级不友好。——Aggie Dewadipper 2023年10月9日 (一) 07:04 (UTC)
- (+)支持禁用,垃圾设计,最讨厌看到这种讨论页。--陈白肠(留言) 2023年10月8日 (日) 10:22 (UTC)
- 支持禁用,这功能好像难以RRD?桐生ここ★[讨论] 2023年10月9日 (一) 13:18 (UTC)
- 好像甚至无法OS,我之前提过一个OS然后监督员把帖子隐藏了…… ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月15日 (日) 11:29 (UTC)
- ( π )题外话我觉得“监督”应该更名为“永久删除”--意面混凝土(留言) 2023年10月15日 (日) 11:33 (UTC)
- 监督可以恢复 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月15日 (日) 11:57 (UTC)
- Re@魔琴:那就叫完全删除吧--意面混凝土(留言) 2023年10月15日 (日) 15:44 (UTC)
- 监督可以恢复 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月15日 (日) 11:57 (UTC)
- ( π )题外话我觉得“监督”应该更名为“永久删除”--意面混凝土(留言) 2023年10月15日 (日) 11:33 (UTC)
- 好像甚至无法OS,我之前提过一个OS然后监督员把帖子隐藏了…… ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年10月15日 (日) 11:29 (UTC)
- (+)支持,--🐟罗洁塔🍵 426677 2023年10月10日 (二) 05:43 (UTC)
- 是--YFdyh000(留言) 2023年10月7日 (六) 07:13 (UTC)
技术讨论
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
为了明确讨论结构,将SD页面转化为普通wikitext页面的功能(phab:T332103)在此讨论。——落花有意12138 2023年10月3日 (二) 04:09 (UTC)
- 除了转化为wikitext,应该也可以截图保存?--Leiem(留言·签名·维基调查) 2023年10月3日 (二) 07:36 (UTC)
- 反对截图保存。这样完全丢失了网页的功能,而且增加了大小。--落花有意12138 2023年10月3日 (二) 11:11 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
结构化讨论是否可以删除帖子
看起来这个功能难以RRD,但是似乎见过管理员把这个当作普通页面来删除Topic,所以破坏性帖子是否可以不只是隐藏,而是可以删除的? 例如Topic:Xs3rolnfojz69vjb。
另外上面#在中文维基百科逐步弃用结构式讨论也有人说之前提过一个OS然后监督员把帖子隐藏了…--桐生ここ★[讨论] 2023年10月23日 (一) 07:37 (UTC)
- 能删啊,我的结构式讨论页上就有一个删除掉的结构式讨论--在下荷花,请多指教(欢迎签到) 2023年10月24日 (二) 02:47 (UTC)
- 讨论摘要写{{D|G3}}就行--在下荷花,请多指教(欢迎签到) 2023年10月24日 (二) 02:56 (UTC)
- Topic:Xs5wvi1on3bvzgmy是刚建的测试话题,已提交快速删除。--在下荷花,请多指教(欢迎签到) 2023年10月24日 (二) 03:02 (UTC)
- 无法删除,只能是把内容隐藏--百無一用是書生 (☎) 2023年10月27日 (五) 01:04 (UTC)
- 啊,但它确实被删除了啊,而且有删除日志,难道这个在技术上还属于隐藏吗?--在下荷花,请多指教(欢迎签到) 2023年10月27日 (五) 05:14 (UTC)
- 我也不太知道。反正用删除普通页面的方式去删除的话会报错--百無一用是書生 (☎) 2023年10月27日 (五) 06:30 (UTC)
- 这样啊,好奇是怎么删的hhh--在下荷花,请多指教(欢迎签到) 2023年10月27日 (五) 06:56 (UTC)
- 我也不太知道。反正用删除普通页面的方式去删除的话会报错--百無一用是書生 (☎) 2023年10月27日 (五) 06:30 (UTC)
- 啊,但它确实被删除了啊,而且有删除日志,难道这个在技术上还属于隐藏吗?--在下荷花,请多指教(欢迎签到) 2023年10月27日 (五) 05:14 (UTC)
- 无法删除,只能是把内容隐藏--百無一用是書生 (☎) 2023年10月27日 (五) 01:04 (UTC)
- @桐生ここ--在下荷花,请多指教(欢迎签到) 2023年10月25日 (三) 00:46 (UTC)
废弃结构式讨论
如题,之前的讨论存档了,再开一个。--意面混凝土(留言) 2023年10月26日 (四) 08:55 (UTC)
- ?—— Eric Liu 創造は生命(留言・留名・学生会) 2023年10月27日 (五) 07:28 (UTC)
- 之前的讨论还没出结果就存档了--意面混凝土(留言) 2023年10月27日 (五) 08:21 (UTC)
- 正如前次讨论中已提及基金会正准备相关讨论,现在进行相关讨论无疑是操之过急。基金会发起讨论后才进一步讨论也未迟。谢谢。--SCP-0000(留言) 2023年10月27日 (五) 13:36 (UTC)
结构式讨论中不必要的自动繁简转换
如题,我在某位朋友的结构式讨论留言板上输入[[:Category:没有使用水平列表的导航框]],但发布编辑后却被系统自动改写成[[:Category:沒有使用水平列表的導航框|Category:-{zh-hans:没; zh-hant:沒}-有使用水平列表的-{zh-hans:导; zh-hant:導}-航框]],造成错误红连如Topic:Xo3oqrb35jp2z86m且无法修正[3](编辑历史不可见,且莫名多出20字节),请协助找出原因并修正,谢谢。--回廊彼端(留言) 2023年8月19日 (六) 11:43 (UTC)
- 可视化编辑下输入后源代码模式提交,红链没了,但自动增加了许多转换语法。不了解原因。--YFdyh000(留言) 2023年8月19日 (六) 19:17 (UTC)
- User:YFdyh000我也是用同样模式编辑,看起来繁体使用者输入时会自动把简字内容转成繁体(包括内部链接,所以发生上面的问题);反之亦然但错的离谱,例如说您编辑后自动跳出大量类似-{zh-hans:別; zh-cn:别}-的错误转换,前面那个应该是zh-hant才对。--回廊彼端(留言) 2023年8月20日 (日) 05:57 (UTC)
- User:YFdyh000刚测试问题已消失,故结案。--回廊彼端(留言) 2023年11月27日 (一) 12:27 (UTC)