Minecraft Wiki:论坛/启用简体转换表与开放使用繁体编辑事宜
启用简体转换表与开放使用繁体编辑事宜
首先宣布一个好消息:经过整整一年又三天,繁简与地区词转换表的重写及新繁转简转换表已完成!
查看新转换表内容 • 检视新转换表源代码 • 预览新转换表效果(dev wiki我不确定能不能放连结)
这次转换表的重写工作,契机是出于因应繁体转换表被移动导致的香港繁体模式下转换大量失效。虽然补上诸多因移动缺失的规则很是麻烦,但正也正好给了重新一条条审视转换表规则的机会。我也借此过程,顺道同时完成了过去没有实现的繁体转简体之转换表。这里还要特别感谢@BoredYukolin与@Commusic在编写过程中的热心协助。
由于Minecraft与本wiki目前已支援三种用字模式,若开放繁体编辑并简单假设每种变体所用词汇皆不同,那3×2=6每一个物件都要分散在3个转换表写共6条规则,将造成极大的维护困难。实际上目前重写好的、仍却漏部分规则集的转换表就有着总计近4000条规则。近期香港繁体的转换失效很大一方面也是受与台湾正体要同时维护的困难影响。故我取灵感自维基百科的CGroup,建立了一个转换表模组Module:Conversiontable来集中编写、统整转换规则,再由其生成转换表内容。唯一缺点大概是本wiki目前设定下,非自动确认的使用者无法编辑。
应该还有不少人还记得在5年前(2020),我们就曾尝试建立过一次简体转换表。然而因该转换只是简单的反转繁体转换表且未经严格审查,实施流程又过于躁进,导致诸如“沙子”转换成“沙子子”等事故,最后憾未能实施。
这次转换表经过逐条审定,近乎所有可能的问题规则皆执行过全站语料搜寻,并使用自动化程式全面检查所有译名的正确转换。我可以承诺,目前的转换表几乎不可能再出现简转简问题。那怕不小心出现一些,也绝对比目前繁体模式下的错误转换少非常多。故应可以不用再担心在实装后既有的页面显示出现问题。
启用简体转换表,在开放繁体中文编辑前,就会先有一大好处是节省占了本wiki半壁江山的大量的简繁重新导向。MediaWiki设计中,使用者在输入标题名称时若有表中转换规则,就会自动重新导向到正确的页面。原本我们只有单向的转换表,这导致条目标题可以转换为繁体显示,但繁体的显示标题却无法连到该条目自身,需要一个个建立重新导向。启用简体转换表即可解决此长期问题,尤其是对那些根页面名要转换的大量子页面。
开放繁体编辑自然也是简体转换的主要目的。使用不习惯的用字模式书写不但吃力又难受,更重要的是很容易出错。目前要求编辑者自己转为简体,凭不熟悉的感觉转通常品质要远低于转换表的几千条(算上MediaWiki自带是几万条)规则的效果。或甚至由使用简中的巡查员代转为简体,也难免有漏网之鱼。在已有繁体编者和简体转换表的情况下,允许用繁体源代码最终呈现出的效果无疑比让繁体编者用简体写要容易好。至于所谓来自繁中社群的编者不多,那更该允许繁体编辑,以免望而生畏,让用繁体总是比较友善不劝退人的。
为确保一切顺利,我提议分为以下三阶段,分步实施此项变更。各阶段间间隔约一周,以处理可能出现的问题。
阶段一、启用简体转换表
启用大陆简体转换表(MediaWiki:Conversiontable/zh-cn)。并将MCW:繁体中文问题报告重新命名为“MCW:字词转换请求”,以扩大适用范围。
虽我认为不太可能,但若发现过多的简转简问题可以在此期间先退回转换表。此阶段就用于看有没有不良的副作用。
阶段二、开放繁体编辑
本wiki目前实际上没有任何方针或指引明确限制必须使用简体中文编辑,所以这更多只是应对政策的改变。不过还是有些资讯性页面要稍作修改:
MCW:译名标准化 § 标准化概况:将“由于目前Wiki上繁体编辑者还不多,请在编辑时尽量使用简体中文译名,这样一来可以透过简繁转换服务各地的中文读者。”改为“本Wiki允许使用任意简繁体编辑,并透过字词转换系统分别为各地的中文读者显示正确译名。如发现有不周之处,还请于字词转换请求提出。”
MCW:巡查指南 § 注意事项:“页面内容应该使用简体字,如果有更改加入了繁体字,巡查员应当对更改进行简繁/字词转换。”改为“若发现编辑内容有字词转换困难词汇,巡查员宜在能力范围内尽量修复。”
此阶段属于试行期。
阶段三、修正繁简破坏规则
为避免争端,兹提议Wiki条例#2.4(繁简破坏)增修如下:
2.4 请勿将页面的源代码全部或部分替换成繁体或简体,除非是为了修复繁简转换出错等正当理由。
若修正通过,将于此阶段公布施行。
此外,建议这时发布开放繁体编辑的公告与新闻。
这个想法随着随着转换表的重写历程,也断断续续考虑了一年多。应该称不上粗糙,但也都没有先与他人商议、请教过。因此还请不吝于提出任何修正建议或支持及反对意见。
TL;DR:如题。
── Leo768(Talk|Contributions) 2025年3月8日 (六) 21:19 (UTC)
- 作为提案人当然 大力支持。老实说,我目前写条目可能有大半的精力都耗在输出简体上,心累不说还时常有漏,实在很想从中解脱。不过虽说提案通过我可能是最大收益人,但实际上此提案的所有额外维护成本也基本都会是我来扛。顺带一题,这模组实际上这是我第二个借鉴自CGroup的了。──
Leo768(Talk|Contributions) 2025年3月8日 (六) 21:19 (UTC)
- 需要BWiki那边的同步bot支持同步为简体内容吧,毕竟bot的同步机制目前依然是默认源代码为简体?除此以外基本 支持。--
Lakejason0(论•功) 2025年3月9日 (日) 04:13 (UTC)
- 我在测试简体转换表时,就有编写一个套用转换表的脚本用于确定既有页面会不会发生转换问题,该模组亦有保留输出转换表为JSON的功能。如果需要我可以提供相关资料。 ──
Leo768(Talk|Contributions) 2025年3月9日 (日) 05:33 (UTC)
- 我在测试简体转换表时,就有编写一个套用转换表的脚本用于确定既有页面会不会发生转换问题,该模组亦有保留输出转换表为JSON的功能。如果需要我可以提供相关资料。 ──
- 支持。这样做可以促进使用繁体中文用户更便捷的进行编辑,一定程度上利于对Wiki的发展。不过启用后可能还有一些问题待日后讨论,如新条目的标题使用的变体、繁简重定向是否还需要建立等。另外建议在阶段一开始时就发布相关站点公告,以提醒各位读者和编者协助检查新的转换方案是否存在问题,并在侧边栏或其他合适位置加入汇报此类问题的快捷入口。 Endearing Cat(留言) 2025年3月9日 (日) 08:52 (UTC)
- 支持,希望此举能鼓励更多繁体中文使用者加入中文MCW的编辑。 AblazeVase69188(留言 | 贡献) 2025年3月9日 (日) 10:45 (UTC)
- 支持。作为一位惯用繁体的wiki新手,很高兴可以看到wiki得到以繁体编辑的可能;但也以我所提及我并不熟悉wiki,期待各位大佬的讨论和为这套新转换表的改善。 ——
Commusic(论 • 功) 2025年3月9日 (日) 13:57 (UTC)
- 支持。理由同@AblazeVase69188。 Afulai2333(论·功) 2025年3月9日 (日) 14:28 (UTC)
- 支持。🐮 GIM Dianliang233 T C 2025年3月10日 (一) 01:58 (UTC)
- 中立。可能是本人阅读繁体字较少,目前有很大的认字障碍,繁简混用会极其不适,可能在巡查过程中出现问题,这可能是我个人的问题,我暂不清楚这样做会潜在提高巡查员门槛。当然,换位思考一下,我相信繁体使用者和我可能有一样的问题。如果社区需要,我愿意花精力学习繁体字。
Wilf233zhMCW(论·功) 2025年3月10日 (一) 04:12 (UTC)
- 这种情况也就是所谓的systematic bias,实际上是作为wiki应当尽力避免的。正如正文所说,繁体用户辨认及书写简体字一样存在非常大的障碍。--
Lakejason0(论•功) 2025年3月10日 (一) 05:20 (UTC)
- 正如下文所述,我专门为此情景编写了一款小工具(User:Leo768/javascript/DiffConversion.js)。在有此工具辅助巡查的情况下,您会更新您的意见吗? ──
Leo768(Talk|Contributions) 2025年3月11日 (二) 14:33 (UTC)
- 这种情况也就是所谓的systematic bias,实际上是作为wiki应当尽力避免的。正如正文所说,繁体用户辨认及书写简体字一样存在非常大的障碍。--
- 在此文发布后,我或多或少听到了一些担忧和疑问。我想在这里统一说明:这些担忧基本都是多余的。
- 此项政策是否会导致简中读者的体验变差?
- 并不会,反而是会变好。
- 的确,转换表有其局限,有些词汇无法正确转换,而对语感和词频一类较抽象的地区差异更是无能为力。然而,对已有的繁中编者编辑而言,如文中所述,手动转换缺漏和讹误比转换表还容易发生。哪怕让巡查员来做事后手审核,有没有漏网之鱼不说,只在极少数需要时补几个转换标记不也比手动慢慢转简体轻松准确么?而语感和词频什么的手动转换谁来都和转换表一样无从下手。故对既有的繁中编辑来说,启用简中转换表并允许直接用繁中编辑可以提升简中下的显示品质。
- 那可能的问题就是因开放繁体编辑吸引繁中编者,随着以为繁体原文的编辑增加,在简体模式下漏出更多缺失转换的字词,或偏向繁体惯用的语句。然而,若此事真的发生,考量到首选简中编辑的使用者大概不会换用繁中编辑,这些编辑本就是多出来的、赚到的,和编辑本身对条目的品质提升好处比起来,转换成简中的那点不完美完全是可以忽略的小事。故对因此新增的繁中编辑而言,转换为简中时的少许缺陷仍不改变更多编辑为好事的本质。
- 何况以上的讨论已是在转换缺陷是对简中阅读体验伤害的前提下推导出应执行此政策。然而考量到繁中整体上岐义较少,且条目源代码在往后大概还是简中占多数,简中模式下会看到的转换问题怎么样都至少比现在繁中模式下要少,也就是非常少。
- 此项政策是否会增加转换系统维护负担?
- 影响甚微,可以忽略。
- 正如上文所述,如果还是以前的模式,开放繁体编辑将导致每个物件由两表两规则变成三表六规则,这成本无疑是极大甚至是负担不起的。所以这才设计了新的维护模式,新的模组使得编辑转换表多写些变体不过是举手之劳。麻烦程度可能还要比旧模式的单向来得低。万事起头难,建立新转换表的确断断续续花了一年才重写好,但维护这本就是为维护方便设计的模组并不会很困难。
- 至于条目源代码简繁混杂是否会比起统一源代码变体更使部分字词难以转换?这主要是影响到不同变体下同形不同义的词汇。这种词有多少?只有三个,其中还有一个是两种繁体间的。随便拎出一个变体总转换困难词汇都比两个多得多,何况那两个词考虑到现状目前也是较不保守的当简体在转。源代码简繁混杂与纯简体的差距远不如纯繁体与纯简体的差距。故统一源代码为简体并不会帮助简繁转换施作。
- 有人提到本wiki是否需要采用类似维基百科NoteTA和CGroup转换组模式。转换组的核心意义在于组织规则、方便编辑、页面提示、及针对不同的主题因地制宜做转换。前二者优点已经提取到了现在的转换表生成模组,展示规则维基百科也承认实际意义不大大可甭管。而主题部分本wiki的主题过于单一,术语全都不离Minecraft与IT。哪怕看衍生游戏,且不论一整个命名空间都挂一样模板有没有意义,Earth不超过20个词,Dungeons与Legends的繁中也都还没有着落。不过类似进度名、字幕、游戏规则、旗帜图案等的确是因使用不广泛且为数较多,可以考虑放到转换组去,于是我参考维基百科CGroup建立了转换组模板{{sc}},其演变成{{tp}}的过程在这就不赘述了。故本wiki现状没有再次建立转换组的需求。
- 此政策是否还需要更多配套措施?
- 虽然我把此政策吹得百利而无一害般(实际上也差不多),但改变总是会需要付出一些成本的。
- 首先是大部分编辑者和巡查员仍使用大陆简体,虽然依据语言中立这不是一个合理的论据,但现实上的确可能导致源代码上阅读困难。不过这也可以套用之前关于新编辑的论述:这些繁中内容本就是多赚来的,有比没有好。再来,我目前打算编写一个查看差异时繁简转换的小工具,这应该可以解决一部分的巡查员阅读困难问题。我也会考虑看看如何在避免繁简破坏的同时在编辑器提供该工具。
- 至于目前全数管理员皆使用大陆简体也可能会导致相关工作运作较不畅,包含各过滤器可能要因应更新,以及因转换表变动要修复字词转换和新的基建可能会动到不少全保护页面等。不过这部分应该与过去差异也不大。主要的是我会想提请制作一个过滤器,自动标记可能简繁转换出错的编辑,以供进一步检查。
- 关于繁简与地区词转换的各说明页面和配套规则及新系统的使用说明,我已在编写中,敬请期待。先把提议发出来是出于讨论过程会持续很长一段时间,故在转换表本体完成后就率先提出。会待相关页面建置完成后才做本讨论的决议。
- 以上内容我会考虑写到论述去。──
Leo768(Talk|Contributions) 2025年3月10日 (一) 07:38 (UTC)
- 完全牛头不对马嘴。要提意见可以,能不能拜托不要不分青红皂白的想与我论述的点贴上。可否请你以不回复我的方式、重新顺着自己的想法组织文字来发表论点。──
Leo768(Talk|Contributions) 2025年3月10日 (一) 09:29 (UTC)
- 完全牛头不对马嘴。要提意见可以,能不能拜托不要不分青红皂白的想与我论述的点贴上。可否请你以不回复我的方式、重新顺着自己的想法组织文字来发表论点。──
- 读者层面我是很放心的,这方面的处理方案已经比较成熟。目前我最担心的点在于编者层面是否会因为简繁混杂的源代码而受到困扰,因此,上面配套设施中所说的查看差异时和编辑器中的简繁转换小工具,我认为尤为必要。 AblazeVase69188(留言 | 贡献) 2025年3月10日 (一) 10:53 (UTC)
- 看了一下Leo老师发的FAQ,如此实施既不会导致难维护等问题,那么我表示,也非常庆幸MCW或将实现繁体自由。不过关于三个阶段的细节可能仍需补充以便讨论,比如是否需要在侧边栏添加“字词转换请求”的链接。 支持TeaSummer(Q&A|C) 2025年3月10日 (一) 11:39 (UTC)
- 启用简体转换表,但是对后两个阶段有以下 支持: 疑问
- 其一,当前的中文维基百科条目中恰是因为同时开放简繁源代码编辑,使得未经转换的源代码相当的难看,连同一个句子中也会出现简繁用字/词反复穿插的情况。此处摘出wzh:我的世界中的部分源代码(按照CC BY-SA 4.0授权),简体和繁体分别用绿色和红色标明:
- 2009年5月14日,马库斯·佩尔松(游戏名Notch)在他的YouTube頻道上發佈了「Cave Game」(洞窟遊戲)技術測試,游戏中只有草方块、圆石和隨機的洞窟。該影片在一開始未有大的反响,之後有少數玩家在進入遊戲後提出了建議,且马库斯·佩尔松也陸續更新遊戲且開始加入新事物。2009年9月1日,Minecraft舉行了生存測試,對日後的遊戲形成了雏形。
- 不论是简体还是繁体编者,看到这种源代码都只会一头雾水。这对两方都难以起到缓解阅读障碍的作用。并且我简单对比了两者的最近更改后,发现本Wiki的零碎格式修改似乎要远多于中文维基百科,更容易造成上述现象。即使添加了转换差异内容的小工具,也无法避免源代码编辑中的阅读障碍。此外,目前有部分模板还在使用中文参数,而且仅支持简体中文参数。显然这是设计缺陷,但这也使得当前做不到100%完全开放简繁源代码。
- 目前而言,即使开放繁体编辑的政策正式施行,全站的源代码仍几乎皆为简体,繁体编辑者面对此景恐怕仍是望而却步,所写的繁体原文也很可能因零碎格式修改而被覆盖,想要达到吸引更多繁体编者这一目的怕是需要相当长的时间。虽然中文维基百科一直实行简繁开放的政策并且沿用至今,但在我看来,这是由于中文维基百科与本Wiki天然有着不同的背景。前者因为特殊原因,本应作为多数的简体用户却难以接触到,导致矛盾被淡化。对于本Wiki,简体读者和编者占据多数仍是事实。
- 其二,若仅从一种变体的使用者的角度考虑,Leo的QA中也有提到,“本wiki的主题过于单一,术语全都不离Minecraft与IT”但这恰体现了最大的问题:本Wiki的内容充斥着大量游戏内标准译名,而译名本身又存在大量不可忽视的简繁差异,换言之,它们全部都算是“专业术语”,即使忽略认字差异,假设简繁用户都能互相看懂繁体字和简体字,也仍会出现互相认不出“潜影”与“界伏”、“幽匿”与“伏聆”为何物,诸如此类的障碍。大局上来说这会加剧简繁使用者都看不懂简繁混杂的源代码的现象。日后新编者(无论简繁)想要熟练编辑,甚至可能需要熟悉整个转换表及其运行机制,这个门槛是否过于高了呢?我相信时至今日,熟悉大量简繁译名差异因而受影响较小的编者也只占极少数,因此这一举动可能在对新编者入门的门槛不降反增的同时,还会劝退一部分现有编者,总体看来绝不是“百利而无一害”的。
- 综上,我认为为了语言中立而语言中立,要从整体上意识到“本Wiki大部分活跃编者都是简体用户”以及“本Wiki中文本的简繁隔阂远不止字形难认”的事实考虑。 不应当BoredYukolin(留言) 2025年3月10日 (一) 14:36 (UTC) (最后编辑于2025年3月11日 (二) 04:39 (UTC))
- “本Wiki大部分活跃用户都是简体用户”,这虽然是现状,但本议题就是在尝试修改这一点的。 AblazeVase69188(留言 | 贡献) 2025年3月10日 (一) 14:56 (UTC)
- :有观点认为简繁译名混杂出现带来的负面影响不大,事实上,【译名二义性】的麻烦问题,在仅用简体的情况下就有“力量→Power/Strength”“水下呼吸→Water Breathing/Respiration”等例子,在开放繁体后这些现象只会更加严重,如“蜂巢→Honeycomb/Bee Nest”“石英磚→Block of Quartz/Quartz Bricks”“幸运→Fortunate/Luck”等等。想要避免这些冲突,我能想到可行的办法只有:强制规定Wiki上只能使用这些冲突名称中的某一个;或者直接开发出 补充
{{BlockName}}
{{ItemName}}
等模板,使用英文参数规避。前者显得太过于麻烦,甚至还不如一刀切只允许使用简体,即现状;后者则使得正文中的模板数量太多,添加负担的同时还对可视化编辑造成障碍。 - 对“本议题就是在尝试扭转这些”的观点,我认为:
- 1. 吸引繁体编者是好事,但是如果副作用是让原有的简体编者都感到编辑不畅,那么扭转“本Wiki大部分活跃编者都是简体用户”的现状似乎并不一定能促进本Wiki的发展。
- 2. 目前“本Wiki中文本的简繁隔阂远不止字形难认”的影响仅波及到繁体用户,但按我上面的论述,开放繁体编辑后繁体用户的隔阂也并不能完全消除,对应也会给简体用户带来新的隔阂,总体而言我看不出后种情况相比于前者好在了哪里。 BoredYukolin(留言) 2025年3月11日 (二) 10:37 (UTC)
- 开放繁中完全不会增加转换失效量已在上面严格论证过了,这是非常明确的技术问题。请不要再传播错误观念,谢谢。
- 入门版解释:假设繁中原文转换错误有3%,简中原文有7%,简中与繁中冲突的有0.1%。由于采取当简中转策略,繁中原文转换错误实际上会是3.1%。那目前wiki全简中原文转换错误率是7%,混繁中原文不论以多少比率,与3.1%平均下来只会更低而不会更高。
- 而就单以简中读者视角,体验只可能变好也论证过了,不再赘述。──
Leo768(Talk|Contributions) 2025年3月11日 (二) 11:08 (UTC)
- 总感觉阁下为了反对是陷入了某些思维误区。
- 首先,我不知道为什么为产生“此政策想要透过让源代码不都是简体来降低阅读障碍、吸引繁中编者”的错觉。你摘那段源代码看到的是不好看无法吸引人,但我看到的是每个人都可以自由的用自己习惯的书写系统来编辑。开放繁体编辑本就不是想让源代码繁中化以减少隔阂吸引繁中编者增加比率什么的,而是在有繁中编者来编辑时,不去讨论页发一句把人请离。
- 接下来什么特殊背景误会就更多了,为什么阁下会以为维基百科的简中使用者不是占多数?且不论字词转换时设立时根本没被封,或是现今简中编者仍占较多。就给你一个机会重新设计简中编者占压倒性多数的中维,你会开放繁体编辑吗?至少我会,连萌百和求闻也都是这么做的。因为这本身就是合理、正确的选择。或者说,不作为。对一个中文导向的wiki来说,不禁止繁中编辑可不就是不作为吗?
- 神奇的错觉:“一开放繁体本wiki就会有随机一半的字凭空被替换成繁体”。我就重复一次上面的论述好了:开放繁中编辑并不会条目中既有的源代码变成繁体。源代码每多一点繁体,都是多一个繁体编辑造就的。那如果不开放,这些编辑就是直接不存在。所以,繁体源代码本来就是多赚来的,那怕较难被简中编者编辑,那也是多的编辑。再说,这些条目源代码内多出来的繁体本身就是能接受源代码与自己惯用变体不一致的编辑者,所以在怎么说真的会受影响的也会被这些新增的编辑填补。而且可能发生只有繁体编者能编辑简体但反过来不成立吗?所以“简繁混杂同时劝退简繁编者”基本就是无稽之谈,因为如果真的劝退,那根本就不会简繁混杂。至于可能要熟悉整个转换表才可编辑的说法着实过于扯淡,不予回应。
- 至于为了语言中立而语言中立值得吗?当然值得。其实别说百利而无一害了,这件事只要不是很大的损害,那就是该做的。就拿阁下放弃了的回复来说:“Leo感到心累则可能是因为自身作为巡查员只能自我纠正。”其换个说法就是“本wiki不欢迎有意愿的繁中使用者成为巡查豁免者乃至巡查员。”这听起来就不合理对吧?阁下可能没意识到,此政策的本质就只是:不再强迫使用者参与wiki必须使用自己不熟悉的用字模式。本政策本就不志于要主动引来多少新人,只是让所有有意愿的编者有平等的机会为wiki贡献。如果真的一个繁中编者都没新增?那显然我们也不会有任何损失,本政策又不是要求要用繁中编辑,只是不做本就不必做的限制而已。不过这不还有我呢?
- 总之,此说法大体上是想太歪了。 ──
Leo768(Talk|Contributions) 2025年3月11日 (二) 14:16 (UTC)
- ,理由同@ 强烈支持AblazeVase69188。并提议:尽早在编辑预览界面提供简繁转换设置(控制以何种变体生成编辑预览),同时具备简繁阅读能力的编者可借此在编辑过程一并检查简繁转换问题。减轻巡查员负担。
- 因为有相当移动端编者的存在(比如我在大部分时间也是使用移动端进行编辑),在移动端编辑器中支持该功能亦需要早日完成。
- Eletron ProCoress(留言) 2025年3月11日 (二) 05:06 (UTC)
- 我们很久以前已经有了,请自行于小工具寻找。至于移动设备,连预览功能都不存在又能如何放入选项呢。 ──
Leo768(Talk|Contributions) 2025年3月11日 (二) 05:30 (UTC)
- 预览其实是有的,我把截屏发送到DC里。Eletron ProCoress(留言) 2025年3月11日 (二) 07:36 (UTC)
- 我们很久以前已经有了,请自行于小工具寻找。至于移动设备,连预览功能都不存在又能如何放入选项呢。 ──
- 暂且补充一下群聊中的意见:Autovalue部分参数只支持简体,可能会成为立即执行提案的阻碍。还需要排查更多的技术问题以便提案的实施。--
Lakejason0(论•功) 2025年3月11日 (二) 06:31 (UTC)
- 毕竟这件事早在超过一年前就有计划,敝人早有对各模板的简繁友善做过排查、改善,且本wiki以前就有为了避免简繁问题走避免中文参数路线。因此除了autovalue外应没有其他填不填简体的问题。而填autovalue的地方主要还是少数的单独参数,一般编辑通常不会碰到,故暂无大碍。 ──
Leo768(Talk|Contributions) 2025年3月11日 (二) 07:33 (UTC)
- 毕竟这件事早在超过一年前就有计划,敝人早有对各模板的简繁友善做过排查、改善,且本wiki以前就有为了避免简繁问题走避免中文参数路线。因此除了autovalue外应没有其他填不填简体的问题。而填autovalue的地方主要还是少数的单独参数,一般编辑通常不会碰到,故暂无大碍。 ──
- 支持,毕竟Minecraft Wiki不为特定地区服务,不能因为繁中用户少就强迫他们就范。--ultim_0 [talk][work] 2025年3月11日 (二) 14:23 (UTC)
- ,能吸引更多人来编辑维基总是好的。–– 支持
Abigpigeon(论/功) 2025年3月11日 (二) 14:27 (UTC)
- ,能否加入在显示源代码时也可以启动简繁转化的功能?如果可以, 疑问议案,反之则 支持。 无 倾向反对聊的 电脑b 2025年3月16日 (日) 01:03 (UTC)
- 请启用“以变体预览”的小工具。--
Lakejason0(论•功) 2025年3月16日 (日) 10:49 (UTC)
- 请启用“以变体预览”的小工具。--
- 支持 每次编辑都需要转成简体确实有些麻烦,如果能实现繁体编辑确实挺不错的
Terlity 2025年3月16日 (日) 11:36 (UTC)
显得很蠢,也体现这里“故统一源代码为简体并不会帮助简繁转换施作”似乎有欠考虑。不过,使用繁体作为原文也可以解决简中译名源代码的一些冲突,比如“力量→Power/Strength→力量/強力”。