Minecraft Wiki

除另有声明,转载时均必须注明出处若簡繁轉換出錯,請以遊戲內為準请勇于扩充与修正内容有兴趣逛逛我们的微博沟通交流,欢迎到社区专页需要协助,请在告示板留言

了解更多

Minecraft Wiki
Advertisement

社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。

请了解,Minecraft Wiki在共识系统上运作而不是投票决定,清楚地阐述自己的理由比简单地支持争论的一方更有效。

涉及管理员权限的相关事宜请发布于管理员告示板。涉及繁简字词转换等问题请到繁体中文问题报告中提出。

常用页面

Minecraft Wiki不是客户服务中心!游戏问题请移步Minecraft帮助中心或者玩家游戏社区。

所有在该页面上发表的无关话题都将被存档至此

请点击下面的“发起议题”按钮或页面上面的“添加话题”标签在页面底部发表新的议题。​

最新Wiki新闻
# 话题 发言条数 参与人数 发起者 最后发言者 最后发言时间(UTC)
1 修改四个~签名 2 2 Java.lang.NullPointerException Ultim 0 2022年6月3日 (五) 06:42
2 弃用“数据标签”一词 2 2 Yzy32767 Lxazl5770 2022年6月9日 (四) 16:07
3 请求敲定“parity”一词的标准译名为“趋同” 13 8 Miemiemethod Lxazl5770 2022年6月29日 (三) 13:46
4 远古之城页面缺少结构图片 3 3 146.19.174.201 Ultim 0 2022年6月9日 (四) 10:15
5 关于首页大段空白的问题 17 9 North kun Lakejason0 2022年6月22日 (三) 08:01
6 Minecraft Wiki自动下载文件 5 4 183.193.129.221 Louis0921gee 2022年6月26日 (日) 09:10
7 请删除MinecraftLegendsLogo.jpg 2 2 WindMC Lxazl5770 2022年6月22日 (三) 14:44
8 关于重新划分版本导航模板的事项 8 4 Ultim 0 Anterdc99 2022年6月27日 (一) 14:27
9 有关格式指导中图像介绍的说明文字的末尾句号用法之问题与相关提议 2 2 Lakejason0 Lxazl5770 2022年6月29日 (三) 13:43
话题

修改四个~签名[]

本主题或以下段落文字由ultim_0 ( USER | TALK | WORK )移动自Minecraft Wiki:管理员告示板

可不可以在使用四个~签名时自动在前面加上“--”?
原版:
用户名 日期
修改:
--用户名 日期(相当于--~ ~ ~ ~)

--Java.lang.NullPointerException讨论) 2022年6月3日 (五) 06:15 (UTC)

请在您的参数设置中手动修改签名内容,记得勾选“将签名视为维基文本”。--ultim_0 ( USER | TALK | WORK ) 2022年6月3日 (五) 06:42 (UTC)

弃用“数据标签”一词[]

建议弃用“数据标签”一词,全面更改为“NBT标签”或“NBT”。

  1. 社区几乎不使用,实在没见过有哪个玩家在交流时会带上“数据标签”一词。
  2. 游戏内已不使用该词。“数据标签”对应的原文是“Data Tag”,这个词组只存在于较早期的Minecraft中,当前版本直接使用“NBT”一词,中文也全部照写“NBT”。
  3. “数据”一词概念过于广泛,方块状态也可以属于数据,而“NBT”能更好的指明它是什么。--Yzy32767讨论) 2022年6月4日 (六) 00:02 (UTC)
可以请求机器人进行全局替换。--Lxazl5770zh.admin) 2022年6月9日 (四) 16:07 (UTC)

请求敲定“parity”一词的标准译名为“趋同”[]

请求敲定parity一词的标准译名为趋同,理由分述如下:

现状
当前parity一词本身无单独翻译,Parity Issue词组被MCW翻译为待同步特性Vanilla Parity被MCBBS相关更新日志页面翻译为特性同步
敲定该词的标准译名的必要性
  1. 在部分官方文章中parity一词单独出现,或与其他更多单词一起组成词组出现,导致不便或无法翻译,例如parity requestfeature parity等。参考页面为:https://feedback.minecraft.net/hc/en-us/articles/360015877192 ;Minecraft Feedback网站亦有名为Parity的分类。
  2. parity无标准译名会导致玩家或开发者(尤其是开发者)无法对这个词语产生既视感,亦不便于玩家或开发者在Minecraft Feedback或Mojira上进行相关反馈或在其他涉及到的地方使用。
parity一词的解释
词根-par-来自于拉丁语parparis,意为相同、类似。率先被数学界确立为术语,parity表示数学中一种类似但对称/对等变化的事物:奇偶性。随后被经济学确定为不同国家货币单位的一种对称/对等变化:平价,被物理学确定为“宇”(即空间)的一种对称/对等变化性质:宇称。随后被计算机界确立为一种校验两个程序是否具备相同功能的过程,通过比较1的数量(是奇还是为偶)是否一致来确定程序功能是否一致,被称为:奇偶校验(来自于微软术语库),而作为该过程的结果,即两个对称/对等变化的程序功能的一致程度,称为功能的奇偶一致性(来自于微软术语库)。Mojang选取了这一概念,并作出了改编和进一步解释:在官方文章Parity Requests and You: A Guide中,给出解释“Parity is a word that we use a lot here. We use it to mean "ways we can make Minecraft be the same experience as much as possible, regardless of what 'engine' you are using to play". Starting with Update Aquatic, our team renewed its commitment to developing the same features for all versions being updated in Minecraft at the same time.”。注意,这是一种自我免责的说法,“we can make Minecraft be the same experience as much as possible”,这里所说的是提供相同的体验,而非相同的功能,这是一种具备很大最总解释权的说法;而后一句话,也仅是在说从海洋更新开始,我们(才)承诺同时提供相同的功能,事实上这句话并不是在说parity问题了。同时更新相同的功能属于更新问题而非我们所谓的“将一方的特性(feature,其实应该翻译为功能)移植到另一方上的问题”(当然也正是因为这个原因本来在BE开发者版中基本上都做好的萤火虫和白桦树(可能)因为JE产能不足给删了,当然这就是另一个指的探讨的问题了,和本问题无关)。可以看出,Mojang的parity显然来自于微软对于parity奇偶校验的词义,但是,该词只选取了使功能(或者说体验)尽可能相同的说法,而没有进行所谓的真正的“奇偶校验”。微软的“奇偶校验”翻译不可取。
当前翻译的错误性
接上一段,我们可以看出,parity并非同步。Mojang选取parity一词作为特性移植的代名词,而不是uniformconsistencyportsynchronize等,很可能是由于parity词义模糊,可以充分解释,进行自我免责。同时,Minecraft Feedback网站上也有很多提出的parity申请被表示不会在可视时间内移植(类似于Mojira的not fix)。parity并非承诺同步,亦非承诺一致、同化、等价……。这是当前的同步不可取的原因。而特性一词更是无中生有,如果必须保留这种翻译,那么parity request、单独的parity等翻译也就必须“曲线救国”,绕圈调整至类似的翻译的样子。不可长久,亦不可取。
给parity一词下个定义
经过上述分析,Mojang给出的parity意为对JE和BE之间的功能对称调整,使其体验趋于相同的过程。解释:调整tweak的是功能feature,tweak意味着微调而非一致化的保证,该词亦是官方更新日志选取的词汇;趋同的是体验experience,与官方的解释相一致。
社区讨论过程
由我先提出等称的翻译,改编自物理学翻译宇称。由于晦涩难懂,在贡献者群试讨论被全盘否定,移至基岩版开发术语讨论群投票,被否定。在基岩版开发术语讨论群中讨论并征集译名,在分析parity的发展与含义后陆续否定所有绝对性词汇,同时否定的原因也有不符合一词一译的原则(例如一致应为uniform或consistency,同步应为synchronize等,会产生术语冲突,提高翻译成本),最终得出趋同一词作为术语,在场人员全部持赞同或中立赞同立场,发起投票,尚无反对票产生。
“趋同”的优势
  1. 符合定义,趋同即JE与BE游戏体验的趋同,虽然“调整功能”这一含义没有体现,但是也暗含其中。
  2. 群众接受成本低,趋同为“顺口词汇”,不像等称等翻译让人无法接受。
  3. 不会产生术语冲突,趋同一词为中文纯文学性词汇,对应的英文只有文学性的converge/convergence。而converge/convergence作为非文学性/专业词汇时应翻译为收敛,因此不会产生术语冲突,便于行文翻译。
总结
在几乎所有能够想出的词汇都被以充分的理由否决之后,趋同一词以其独有的优势看似成为了该术语的译名敲定最优解。因此,请求敲定parity一词的标准译名为趋同
相关翻译
parity 趋同
feature parity 功能趋同
vanilla parity 原版趋同
parity issue 趋同问题
parity request 趋同请求

方法放寒假 (Talk - Contributions) 2022年6月8日 (三) 16:52 (UTC)

 支持。趋同一词是目前社区提出的相对符合parity在MC中含义且顺口的词汇了

QianShanyao留言) 2022年6月8日 (三) 17:12 (UTC)

这就是太长不看效应吗?唔,作为参与了讨论初期的人,我表示parity issue翻译成趋同问题会有理解成“趋同是一种问题”的嫌疑。-- LakeJasonFace.png Lakejason0) 2022年6月9日 (四) 01:08 (UTC)
 附议:可以将parity issue翻译为趋同事项。--AblazeVase69188讨论 | 贡献 2022年6月9日 (四) 01:41 (UTC)
唔......作为parity翻译的提案,在此处我个人关注的更多还是parity,而有关parity issue的翻译,这应该是issue在此处翻译的问题,而非parity吧(且我也是全程参与了在术语群的讨论的qwq) ——QianShanyao留言) 2022年6月9日 (四) 09:34 (UTC)
wiki和其他地方用的Parity Issue是最多的。既然都翻译成趋同了,要不把这个翻译成“特性趋同”呢?--Lxazl5770zh.admin) 2022年6月14日 (二) 03:50 (UTC)
Feature和特性的关系本身就值得玩味,不建议从争议词汇出发。-- LakeJasonFace.png Lakejason0) 2022年6月14日 (二) 03:54 (UTC)
 同意,改用“趋同”加强了翻译间的统一性,且贴近原文而直观。
另外,关于“parity issue”,“趋同问题”或者“趋同议题”这样的直译就行。--Yzy32767留言) 2022年6月15日 (三) 12:38 (UTC)
主要是,issue翻译成“问题”,性质就变了。“趋同”不是问题,“不趋同”才是问题。--Lxazl5770zh.admin) 2022年6月17日 (五) 14:59 (UTC)
 意见:可否考虑把parity issue翻译成“趋同事项”?--ultim_0 ( USER | TALK | WORK ) 2022年6月17日 (五) 15:31 (UTC)
 中立:这样似乎去除了其中“问题”“错误”之类的含义,不过暂时是最优解。--Yzy32767/ 2022年6月18日 (六) 00:13 (UTC)
 意见:总觉得“趋同事项”“趋同问题”这些翻译虽然准确,但是挺怪的……Tolly9180留言) 2022年6月18日 (六) 10:15 (UTC)
 最后采纳的提议如下:
原文 翻译
parity 趋同
feature parity 特性趋同
vanilla parity 原版趋同
parity issue 趋同事项
parity request 趋同请求

若无异议,3日后确立为讨论结果并予以采纳。--Lxazl5770zh.admin) 2022年6月29日 (三) 13:46 (UTC)

远古之城页面缺少结构图片[]

1.19都更新了,远古之城页面结构图片还没有吗?请大家赶紧上传。 —-146.19.174.201 2022年6月9日 (四) 04:49 (UTC)

1.“Ancient City”的正式翻译为远古城市
2.请问您是指游戏中所生成的结构的逐层构造吗?本Wiki的这些逐层构造并非由图片构成,而是由{{layered blueprint}}模板输出;
3.若您有能力,您可以注册一个账户,并至Minecraft_Wiki:计划/结构蓝图开始完善远古城市相关结构。--AblazeVase69188讨论 | 贡献 2022年6月9日 (四) 10:08 (UTC)
远古城市的结构较为复杂,无论是单个结构的等轴渲染图还是蓝图的制作都难以一蹴而就,还请您理解。--ultim_0 ( USER | TALK | WORK ) 2022年6月9日 (四) 10:15 (UTC)

关于首页大段空白的问题[]

本人的多个设备以及部分尝试了查看首页的群友在打开首页的时候均会在“Minecraft简介”和“本周页面”底部显示大量空白。这是否是一个需要处理的问题? North kun留言) 2022年6月18日 (六) 04:12 (UTC)

 支持:中文表达所需空间比英文要少,套用以前英文版的排版必然会存在空白。不过其实现代汉语的版本还算好,文言版的首页空白那才是惨不忍睹。--Yzy32767/ 2022年6月18日 (六) 04:30 (UTC)
之前也不是没讨论过,当时提出来的时候没人理。至于已经停止支持的游戏,我个人的意见是写上去并标注好。至于MCD和Legends,MCD由于在MCD Wiki首页中已经写了,但是在这里不写又不是很合适,所以我建议可以略写一下;Legends也是相同的道理。--KaplanSteve  T/C 2022年6月18日 (六) 07:10 (UTC)
似乎是为了和旁边的“开始游戏!”对齐。--McplayerFS讨论 | 贡献) 2022年6月18日 (六) 14:12 (UTC)
可以考虑缩减“开始游戏!”的高度,但是我还是弄不明白这些框的大小是在哪里指定的,希望不要动CSS。--Yzy32767/ 2022年6月19日 (日) 01:08 (UTC)
英文版本的版本信息是放在下面的,这样就无需考虑其高度问题。但同样的,就得考虑其他部分的内容宽度和高度问题。-- LakeJasonFace.png Lakejason0) 2022年6月19日 (日) 13:13 (UTC)
我不认为这是需要处理的问题。目前没有插入新栏目的打算。--Lxazl5770zh.admin) 2022年6月20日 (一) 02:33 (UTC)
并不是“插入”的问题,而是重新整理,重新排版的问题。-- LakeJasonFace.png Lakejason0) 2022年6月20日 (一) 03:01 (UTC)
重新排版确实有必要,不过目前暂时没有比较好的设计。有的话可以提出来。MysticNebula70 T  2022年6月20日 (一) 05:30 (UTC)
仿效en的排版其实也不错,把你知道吗换成每周页面如何呢?-- LakeJasonFace.png Lakejason0) 2022年6月21日 (二) 04:04 (UTC)
 意见:en的“你知道吗”板块也有留白,然而如果把每周页面替换进去的话,有可能会空间不足。我建议是要么限制一下每周页面的字数,要么把“关于Minecraft”扩写一点。--KaplanSteve  T/C 2022年6月21日 (二) 14:38 (UTC)(最后编辑于2022年6月21日 (二) 14:39 (UTC))
en主页上的版本信息一栏内容所占空间显然比zh的多,如果仿照其把版本信息一栏的宽度扩展到整个页面的做法,其高度将明显减少。虽然我没有具体试过,但观感肯定不好。--AblazeVase69188讨论 | 贡献 2022年6月24日 (五) 12:57 (UTC)
 留言:浏览首页及相关页面(Minecraft Wiki/style)可知,首页的栏目布局的代码见于MediaWiki:Gadget-mainpage.css,其中与首页栏目布局相关的内容如下:
目前的布局 ultim_0建议的布局之一
a
b c
d
e f g
h i j
a
b
c d
e f g
h i j
其含义是:当页面宽度较宽(大于等于990px)时,将各栏目按右表1所示的方式进行排版。“Minecraft简介”(#fp-2)和“每周页面”(#fp-4)对应的就是b和d的位置。
综上所述,通过修改MediaWiki:Gadget-mainpage.css的相关内容(已在上文标出),即可在不改变首页源代码的情况下更改页面排版形式。
 关于重新排版:经本地测试,将布局改为右表2所示可明显避免出现过多空白。
但是根据群友(既然北鲲使用了这个称呼,那么用在这里应该也没问题)反映,这会导致“每周页面”在部分宽屏设备上出现排版异常的情形(在下的屏幕只有1366px宽,难以预览大屏幕下的情形),建议一并修改Minecraft Wiki/weekly/style。--ultim_0 ( USER | TALK | WORK ) 2022年6月21日 (二) 16:08 (UTC) (最后编辑于2022年6月25日 (六) 18:39 (UTC))
我根据Ultim的提案制作的最终提案如下。
还有一些其他的方案。-- LakeJasonFace.png Lakejason0) 2022年6月22日 (三) 06:07 (UTC)(最后编辑于2022年6月22日 (三) 06:42 (UTC))
由于测试过程中发现了一些新问题,在此说明一下问题以及一些新的提案。
问题1:首页的每周页面图片有浮动,会把文字挤到一边。这个在上方提案中修改为了居中来解决问题。
问题2:版本信息一栏方格下方的列表观感不好,词汇会断开,而且横向列表在列表项目不多时展示效果较差。
基于以上发现的两个问题,我又查看了其他语言站点的首页,相关情况如下:
英文:版本信息单独出一整个横栏,所有的购买链接和版本号放在一起。
西班牙语:重新设计了首页,将版本信息删除。
由于版本信息写全似乎冗余,在即时通信软件中部分用户对EN的目前方案给出的意见是负面的。西班牙语目前没有人评论。大概是这样。-- LakeJasonFace.png Lakejason0) 2022年6月22日 (三) 06:48 (UTC)
韩国语wiki首页的布局 ultim_0建议的布局之二
a
b c
关于外来词
e f g
h i j
a
b c
d
e f g
h i j
注意到韩国语wiki相对于en也对首页排版进行了小幅度修改,如右表1所示,其中的“关于外来词”是其独有的栏目,对应zh的“每周页面”,除此之外的各个字母表示的内容与zh相同。根据其样式给出了方案二,如右表2所示,该方案可以避免方案一中“每周页面”栏目因为宽度过小而出现排版异常的情况,因此无需同时修改该栏目的样式。谨供参考。--ultim_0 ( USER | TALK | WORK ) 2022年6月22日 (三) 07:14 (UTC) (最后编辑于2022年6月25日 (六) 18:39 (UTC))
我在Editcopy中修改了一部分代码,将购买链接和试玩链接直接添加到了版本信息方格中。这样就可以解决问题2(通过直接删除、转移到版本方格内的方式解决)。由于这样的更改会导致先前的版本号合并不再可行(链接显示会不完整),我暂时先放在那边。-- LakeJasonFace.png Lakejason0) 2022年6月22日 (三) 08:01 (UTC)

Minecraft Wiki自动下载文件[]

几乎每次访问时均会自动下载f.txtcm。我认为可能有攻击者修改了源代码。以下是我找到的可能与自动下载有关的源代码(在head区内):

<script src="https://securepubads.g.doubleclick.net/gpt/pubads_impl_2022061501.js?cb=31068115" async=""></script>

希望管理员可以修复,谢谢!

183.193.129.221 2022年6月22日 (三) 08:10 (UTC)柚子柚子

我想这个应该是谷歌的广告。作为Fandom托管站的志愿者团队,很抱歉我们没有移除广告的权限。--Lxazl5770zh.admin) 2022年6月22日 (三) 09:41 (UTC)
或許你可以嘗試註冊帳號,並活躍做出有意義的貢獻,這樣可能就沒廣告了。--Impulse Command Block.png 乳液Louis 对话 •贡献 2022年6月26日 (日) 05:39 (UTC)
现在获得Gamepedia PRO已经没有办法阻止Fandom向用户投放广告了。--AblazeVase69188讨论 | 贡献 2022年6月26日 (日) 08:44 (UTC)
喔真的嗎?看來我太久沒回來了。--Impulse Command Block.png 乳液Louis 对话 •贡献 2022年6月26日 (日) 09:10 (UTC)

请删除MinecraftLegendsLogo.jpg[]

由于我无法将.png文件上传为原.jpg文件的新版本,我刚刚将MinecraftLegendsLogo.png作为一个新文件上传并修改了引用MinecraftLegendsLogo.jpg的页面 介于该文件已无任何页面引用且被新文件的作用所覆盖,能否将MinecraftLegendsLogo.jpg删除?-WindMC留言) 2022年6月22日 (三) 14:36 (UTC)

 已完成,提请删除直接在页面挂{{delete}}模板即可,不需要在此处或管理员告示板发布请求。--Lxazl5770zh.admin) 2022年6月22日 (三) 14:44 (UTC)

关于重新划分版本导航模板的事项[]

注意到Anterdc99最近在自己的用户页中筹划重新划分{{Java Edition versions}}中的正式版和{{Bedrock Edition versions}}中的基岩版部分,并准备将其应用到模板中,但一些用户似乎不赞同其行为,故特地在社区专页发起讨论:

  1. 应将这些区域划分为哪几个部分?理由又是什么?
  2. 进行划分之后的部分是否应设置一个[显示/隐藏]按钮统一控制这些部分的显示/隐藏?

以上。--ultim_0 ( USER | TALK | WORK ) 2022年6月25日 (六) 18:19 (UTC) (最后编辑于2022年6月25日 (六) 18:24 (UTC))

我觉得上面的分法就很好,将正式版拆分的原因是为了方便检索,因为正式版的更新叠起来实在是太长了,在页面里占据的篇幅太长,而且密密麻麻的版本号非常不便于检索。--Lxazl5770zh.admin) 2022年6月26日 (日) 03:37 (UTC)
 贊成--Impulse Command Block.png 乳液Louis 对话 •贡献 2022年6月26日 (日) 05:54 (UTC)

本来是想开单独的话题讨论这个事,鉴于已开此话题,故在此话题下介绍相关情况。具体的显示效果可以在User:Anterdc99/Archives/Edition versions Preview看到。

背景
  1. 英文Wiki已于2个月前将{{Java Edition versions}}{{Bedrock Edition versions}}两个模板中正式版的内容进行了分段处理,并更新了各版本页面中的引用;
  2. 目前的版本导航模板中正式版部分内容过长,不方便查找相关内容。(英文Wiki作出变更以及此处提议作出变更的根本出发点,也是众所周知的原因)
英文Wiki采用的方案
  1. 仅将Java版基岩版的正式版进行分段处理;
  2. 将各正式版按1.x和1.1x的方式进行简单的划分。(即1.20开始开发后,也会新增相应的分段)
既然英文Wiki已经有现成的方案,为什么不直接使用?
  1. 英文Wiki目前的分段方式仅是将长度部分缩短,而对于达成改善检索条件,目前的效果还可以有提升空间,目前的分段后的长度仍然过长;
  2. 英文Wiki的方案需要对大量修改各版本页面,改动面过大。

因此,在本人设计新模板样式时,确定了以下要点(优先级递减):

  1. 被展示部分的长度应当小于一屏,但可以略大于一屏;
  2. 被展示部分不应当太短(即避免将每个大版本划为一段的方式),但与其他部分较难相容时例外;
  3. 分出的段落应当长度一致或接近。

因此,在提交讨论的设计方案中,以下内容与英文Wiki的不同:

  1. {{{1}}}中填入的参数为1.0(即原先的“正式版”总类)时,模板会根据版本页面的名称和归属版本确定要被展示的部分,可以减少相应的修改量;
  2. {{{1}}}参数支持直接填入下面列出的值,可在无法自动检测时正确显示相应内容;
  3. Java版正式版分为:1.0 - 1.7(1.0);1.8 - 1.12(1.8);1.13 - 1.16(1.13);1.17+(1.17);
    • 以版本使用率为依据(或者说代码变更幅度)进行分类,即以1.7.10,1.12.2以及1.16.5这三个版本作为结尾;
    • 1.8 - 1.12和1.13 - 1.16两个中间段落在长度上大致相等。
  4. 携带版正式版/基岩版分为:1.0 - 1.1(1.0);1.2 - 1.9(1.2);1.10 - 1.16(1.10);1.17+(1.17);
    • 1.0 - 1.1为携带版,其与后续版本的标题不同,故单独成段;
    • 1.2 - 1.9和1.10 - 1.16没有明确的分段依据,而是依据长度原则进行划分,这两段的长度大致相等。

另外,除{{Java Edition versions}}{{Bedrock Edition versions}}外,其他的类似模板由于使用率较低,故不在此次更改的范围内。

回应
  1. 分类依据:见上;
  2. 统一控制按钮:保持与英文Wiki保持一致,并降低代码复杂度,不会加入此功能。-- Anterdc99Face.png Anterdc99· 2022年6月26日 (日) 07:52 (UTC)
 赞成,不过如果能够把1.0以前的版本合并为“测试版”就更完美了(因为分栏会一直增多,或者把Pre-Classic到Infdev合并,Alpha到Beta合并也行)。--Lxazl5770zh.admin) 2022年6月26日 (日) 11:44 (UTC)
建议用一个[显示/隐藏]统一控制正式版之前内容的显示和隐藏,因为这些内容太少了,加起来就只有两屏。--ultim_0 ( USER | TALK | WORK ) 2022年6月26日 (日) 12:06 (UTC)

同时注意到Java版beta部分有许多空白,建议也对这些内容进行整理。--ultim_0 ( USER | TALK | WORK ) 2022年6月26日 (日) 12:11 (UTC)

UPDATE:根据上方建议,做了以下更改:

  1. 将Java版的pre-Classic到Infdev,以及Alpha与Beta分别合并到一起,原先的各阶段标识改到段落内作为分隔行;
    1. 由于调整后仍不能在一屏内显示,故正式版前所有内容并未合并在一起;
    2. 合并后,{{{1}}}pre-ClassicClassicIndevInfdev选项改为统一指向“pre-Classic - Infdev”段落;AlphaBeta选项改为统一指向“Alpha - Beta”段落。
  2. 调整了Alpha和Beta的左栏样式以降低高度。

而关于测试版的统一控制,相似地,为了避免增加代码的复杂度,不会加入相应的控制按钮。-- Anterdc99Face.png Anterdc99· 2022年6月27日 (一) 14:27 (UTC)

有关格式指导中图像介绍的说明文字的末尾句号用法之问题与相关提议[]

行政员Lxazl5770在处理用户Louis0921gee有关画廊中说明文字句号的编辑时,引起了该用户对格式指导相关用法的疑问。

经查询,此说明于第一个版本写入格式指导,因此其实算是历史悠久的。相关疑问在中文Minecraft Wiki用户集中的地方也出现过数次(据用户口述可能有四次之多),而根据后来各用户的讨论,发现由于这些疑问的讨论,各用户甚至管理员似乎存在一个错误的印象,即认为这个问题已经解决,且解决方案是按照中文维基百科目前的方案(也就是“存在于图表中的短语式说明文字,其中部内容可用逗号,但末尾不用句号。就算是有些时候说明文字内容比较长,在前面的语段中已出现句号,最后的结尾处仍不用句号。”)执行。但这不是事实,这没有写入格式指导,且事实是这些疑问都是不了了之,并没有得出结论。

由于执行标准不一,实施情况不同,根据维基百科标点符号用法(中华人民共和国国家标准GB/T 15834-2011)的相关说明,我在此提议更改格式指导有关图像介绍的说明文字的末尾句号用法的说明:

旧:图像介绍末尾不应有句号,除非语句是一个完整的句子。

新:图像介绍的说明文字末尾不用句号。就算是有些时候说明文字内容比较长,在前面的语段中已出现句号,最后的结尾处仍不用句号。

我的提议如上。希望各位用户参与讨论。-- LakeJasonFace.png Lakejason0) 2022年6月29日 (三) 10:38 (UTC)(最后编辑于2022年6月29日 (三) 10:55 (UTC))

 我的提议:一律不用句号,并且将原本的说明文字精简到一句话以内。以简化繁。--Lxazl5770zh.admin) 2022年6月29日 (三) 13:43 (UTC)

Change this week's page into a cost day page ~~~~超級藍寶石~~~~

Advertisement