标签：已被回退 |
Dianliang233（留言 | 贡献） （撤销传入神经元（讨论）的版本661797） 标签：撤销 |
||
| 第402行： | 第402行： | ||
{{Outdent}}怎么回到草案了？现在问题就是违反Fandom使用条款这种严重违规应该保留申诉权。[[UserProfile:传入神经元|<font color="#00721e">'''传入神经元'''</font>]]（[[Special:用户权限/传入神经元|权限]]|[[User_talk:传入神经元|讨论]]|[[Special:Contribs/传入神经元|贡献]]|[[Special:Log/传入神经元|日志]]) 2022年7月2日 (六) 02:31 (UTC) |
{{Outdent}}怎么回到草案了？现在问题就是违反Fandom使用条款这种严重违规应该保留申诉权。[[UserProfile:传入神经元|<font color="#00721e">'''传入神经元'''</font>]]（[[Special:用户权限/传入神经元|权限]]|[[User_talk:传入神经元|讨论]]|[[Special:Contribs/传入神经元|贡献]]|[[Special:Log/传入神经元|日志]]) 2022年7月2日 (六) 02:31 (UTC) |
||
| ⚫ | :{{c|!|你难道是想要给某些在用户资料页里发“新xx娱乐”的人求情吗？}}--'''<span class="nowrap" style="font-family:Minecraft,Simsun;color:#336666;background-color:black">ultim<span style="color:black">_</span><span style="color:#2266cc">0 </span><span style="font-size:0.8em;color:magenta">( [[User:Ultim 0|<span style="color:purple">USER</span>]] {{!}} [[User talk:Ultim 0|<span style="color:purple">TALK</span>]] {{!}} [[Special:Contribs/Ultim 0|<span style="color:purple">WORK</span>]] )</span></span>''' 2022年7月2日 (六) 03:16 (UTC) |
||
| − | {{Inappropriate comment |
||
| − | |action=tag |
||
| − | |reason=off-topic |
||
| ⚫ | |||
| − | }} |
||
::: 刚才我查阅了[https://www.fandom.com/zh/terms-of-use-zh 使用条款]：“您同意不会：发布任何商业性广告或潜在性的商业信息。”此事属实。[[User:TripleCamera|TripleCamera]]（[[User talk:TripleCamera|留言]]） 2022年7月1日 (五) 13:47 (UTC) |
::: 刚才我查阅了[https://www.fandom.com/zh/terms-of-use-zh 使用条款]：“您同意不会：发布任何商业性广告或潜在性的商业信息。”此事属实。[[User:TripleCamera|TripleCamera]]（[[User talk:TripleCamera|留言]]） 2022年7月1日 (五) 13:47 (UTC) |
||
2022年7月2日 (六) 03:53的版本
社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。
请了解，Minecraft Wiki在共识系统上运作而不是投票决定，清楚地阐述自己的理由比简单地支持争论的一方更有效。
常用页面
Minecraft Wiki不是客户服务中心！游戏问题请移步Minecraft帮助中心或者玩家游戏社区。
所有在该页面上发表的无关话题都将被存档至无意义话题处。
请点击下面的“发起议题”按钮或页面上面的“添加话题”标签在页面底部发表新的议题。
语言
- 快捷方式
- MCW:CP
- MCW:PORTAL
- MCW:社区
- 最新Wiki新闻
- 2023年8月31日 - 中文Minecraft Wiki确定将迁移至Weird Gloop（议题原文）。
- 2023年7月4日 - 英文Minecraft Wiki公开发布了关于Minecraft Wiki是否要从Fandom迁移至别的站点的讨论（链接）。
- 2023年6月1日 - 新的巡查员Siiftun1857上任。
- 2023年5月4日 - 中文Minecraft Wiki使用的MediaWiki版本已升级至1.39。
- 2023年1月31日 - 新的管理员Anterdc99上任。
存档
| # | 话题 | 发言条数 | 参与人数 | 发起者 | 最后发言者 | 最后发言时间（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 | 关于首页大段空白的问题 | 18 | 9 | North kun | Lakejason0 | 2022年6月30日 (四) 07:24 |
| 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 | 有关格式指导中图像介绍的说明文字的末尾句号用法之问题与相关提议 | 6 | 3 | Lakejason0 | AblazeVase69188 | 2022年7月2日 (六) 02:38 |
| 10 | 【重要】关于本wiki的封禁准则 | 31 | 6 | Lxazl5770 | Lxazl5770 | 2022年7月2日 (六) 02:01 |
话题
修改四个~签名
本主题或以下段落文字由ultim_0 ( USER | TALK | WORK )移动自Minecraft Wiki:管理员告示板。
可不可以在使用四个~签名时自动在前面加上“--”？
原版：
用户名 日期
修改：
--用户名 日期（相当于--~ ~ ~ ~）
--Java.lang.NullPointerException（讨论） 2022年6月3日 (五) 06:15 (UTC)
弃用“数据标签”一词
建议弃用“数据标签”一词，全面更改为“NBT标签”或“NBT”。
- 社区几乎不使用，实在没见过有哪个玩家在交流时会带上“数据标签”一词。
- 游戏内已不使用该词。“数据标签”对应的原文是“Data Tag”，这个词组只存在于较早期的Minecraft中，当前版本直接使用“NBT”一词，中文也全部照写“NBT”。
- “数据”一词概念过于广泛，方块状态也可以属于数据，而“NBT”能更好的指明它是什么。--Yzy32767（讨论） 2022年6月4日 (六) 00:02 (UTC)
请求敲定“parity”一词的标准译名为“趋同”
请求敲定parity一词的标准译名为趋同，理由分述如下：
- 现状
- 当前parity一词本身无单独翻译，Parity Issue词组被MCW翻译为待同步特性，Vanilla Parity被MCBBS相关更新日志页面翻译为特性同步。
- 敲定该词的标准译名的必要性
-
- 在部分官方文章中parity一词单独出现，或与其他更多单词一起组成词组出现，导致不便或无法翻译，例如parity request、feature parity等。参考页面为：https://feedback.minecraft.net/hc/en-us/articles/360015877192 ；Minecraft Feedback网站亦有名为Parity的分类。
- parity无标准译名会导致玩家或开发者（尤其是开发者）无法对这个词语产生既视感，亦不便于玩家或开发者在Minecraft Feedback或Mojira上进行相关反馈或在其他涉及到的地方使用。
- parity一词的解释
- 词根-par-来自于拉丁语par、paris，意为相同、类似。率先被数学界确立为术语，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一词作为特性移植的代名词，而不是uniform、consistency、port、synchronize等，很可能是由于parity词义模糊，可以充分解释，进行自我免责。同时，Minecraft Feedback网站上也有很多提出的parity申请被表示不会在可视时间内移植（类似于Mojira的not fix）。parity并非承诺同步，亦非承诺一致、同化、等价……。这是当前的同步不可取的原因。而特性一词更是无中生有，如果必须保留这种翻译，那么parity request、单独的parity等翻译也就必须“曲线救国”，绕圈调整至类似的翻译的样子。不可长久，亦不可取。
- 给parity一词下个定义
- 经过上述分析，Mojang给出的parity意为对JE和BE之间的功能对称调整，使其体验趋于相同的过程。解释：调整tweak的是功能feature，tweak意味着微调而非一致化的保证，该词亦是官方更新日志选取的词汇；趋同的是体验experience，与官方的解释相一致。
- 社区讨论过程
- 由我先提出等称的翻译，改编自物理学翻译宇称。由于晦涩难懂，在贡献者群试讨论被全盘否定，移至基岩版开发术语讨论群投票，被否定。在基岩版开发术语讨论群中讨论并征集译名，在分析parity的发展与含义后陆续否定所有绝对性词汇，同时否定的原因也有不符合一词一译的原则（例如一致应为uniform或consistency，同步应为synchronize等，会产生术语冲突，提高翻译成本），最终得出趋同一词作为术语，在场人员全部持赞同或中立赞同立场，发起投票，尚无反对票产生。
- “趋同”的优势
-
- 符合定义，趋同即JE与BE游戏体验的趋同，虽然“调整功能”这一含义没有体现，但是也暗含其中。
- 群众接受成本低，趋同为“顺口词汇”，不像等称等翻译让人无法接受。
- 不会产生术语冲突，趋同一词为中文纯文学性词汇，对应的英文只有文学性的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翻译成趋同问题会有理解成“趋同是一种问题”的嫌疑。--
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)
- 同意，改用“趋同”加强了翻译间的统一性，且贴近原文而直观。
- 另外，关于“parity issue”，“趋同问题”或者“趋同议题”这样的直译就行。--Yzy32767（留言） 2022年6月15日 (三) 12:38 (UTC)
- 意见：可否考虑把parity issue翻译成“趋同事项”？--ultim_0 ( USER | TALK | WORK ) 2022年6月17日 (五) 15:31 (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)
- 英文版本的版本信息是放在下面的，这样就无需考虑其高度问题。但同样的，就得考虑其他部分的内容宽度和高度问题。-- Lakejason0（论•功） 2022年6月19日 (日) 13:13 (UTC)
- 我不认为这是需要处理的问题。目前没有插入新栏目的打算。--Lxazl5770zh.admin（论 ▪ 功） 2022年6月20日 (一) 02:33 (UTC)
- 并不是“插入”的问题，而是重新整理，重新排版的问题。--
Lakejason0（论•功） 2022年6月20日 (一) 03:01 (UTC)
- 并不是“插入”的问题，而是重新整理，重新排版的问题。--
- 重新排版确实有必要，不过目前暂时没有比较好的设计。有的话可以提出来。MysticNebula70 T 2022年6月20日 (一) 05:30 (UTC)
- 仿效en的排版其实也不错，把你知道吗换成每周页面如何呢？-- 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)
- 仿效en的排版其实也不错，把你知道吗换成每周页面如何呢？--
- 留言：浏览首页及相关页面（Minecraft Wiki/style）可知，首页的栏目布局的代码见于MediaWiki:Gadget-mainpage.css，其中与首页栏目布局相关的内容如下：
| 目前的布局 | ultim_0建议的布局之一 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| |||||||||||||||||||||||||||||
此段内容过长，请通过显示按钮阅读
/** Responsive main page layout **/
#main-page.main-page {
display: -ms-grid;
-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
-ms-grid-template-columns: 1fr;
display: grid;
grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
#main-page.main-page {
-ms-grid-template-areas: "a a a" "b b c" "d d c" "e f g" "h i j";
-ms-grid-template-columns: 1fr 1fr 1fr;
grid-template-areas: "a a a" "b b c" "d d c" "e f g" "h i j";
grid-template-columns: 1fr 1fr 1fr;
}
}
/* ... */
#fp-1 {
-ms-grid-area: a;
grid-area: a;
}
#fp-2 {
-ms-grid-area: b;
grid-area: b;
}
/* #fp-3到#fp-9同理 */
#fp-10 {
-ms-grid-area: j;
grid-area: 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的提案制作的最终提案如下。
此段内容过长，请通过显示按钮阅读
对于首页的CSS：
/** Responsive main page layout **/
#main-page.main-page {
display: -ms-grid;
-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
-ms-grid-template-columns: 1fr;
display: grid;
grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
#main-page.main-page {
-ms-grid-template-areas: "a a a" "b b b" "c c d" "e f g" "h i j";
-ms-grid-template-columns: 1fr 1fr 1fr;
grid-template-areas: "a a a" "b b b" "c c d" "e f g" "h i j";
grid-template-columns: 1fr 1fr 1fr;
}
}
对于每周页面的图片：
<onlyinclude>[[File:{{{img|}}}||{{{img-size|}}}|border|center|class=banner-image nomobile]]<div style="line-height:2em;display:table;min-width:25%;">{{{content|}}}
<p class="nomobile">
{{{img-desc|}}}</p></div></onlyinclude>
- 还有一些其他的方案。-- Lakejason0（论•功） 2022年6月22日 (三) 06:07 (UTC)（最后编辑于2022年6月22日 (三) 06:42 (UTC)）
- 由于测试过程中发现了一些新问题，在此说明一下问题以及一些新的提案。
- 问题1：首页的每周页面图片有浮动，会把文字挤到一边。这个在上方提案中修改为了居中来解决问题。
- 问题2：版本信息一栏方格下方的列表观感不好，词汇会断开，而且横向列表在列表项目不多时展示效果较差。
- 基于以上发现的两个问题，我又查看了其他语言站点的首页，相关情况如下：
- 英文：版本信息单独出一整个横栏，所有的购买链接和版本号放在一起。
- 西班牙语：重新设计了首页，将版本信息删除。
- 由于版本信息写全似乎冗余，在即时通信软件中部分用户对EN的目前方案给出的意见是负面的。西班牙语目前没有人评论。大概是这样。-- Lakejason0（论•功） 2022年6月22日 (三) 06:48 (UTC)
| 韩国语wiki首页的布局 | ultim_0建议的布局之二 | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| ||||||||||||||||||||||||||||||
- 注意到韩国语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（通过直接删除、转移到版本方格内的方式解决）。由于这样的更改会导致先前的版本号合并不再可行（链接显示会不完整），我暂时先放在那边。-- Lakejason0（论•功） 2022年6月22日 (三) 08:01 (UTC)
- 在处理横向列表的时候发现了EN的一个做法，就是把购买链接写在对应的页面，而不是直接写到首页。这样也更便于维护。-- Lakejason0（论•功） 2022年6月30日 (四) 07:24 (UTC)
- 在处理横向列表的时候发现了EN的一个做法，就是把购买链接写在对应的页面，而不是直接写到首页。这样也更便于维护。--
Minecraft Wiki自动下载文件
几乎每次访问时均会自动下载f.txt与cm。我认为可能有攻击者修改了源代码。以下是我找到的可能与自动下载有关的源代码(在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)柚子柚子
请删除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}}中的基岩版部分，并准备将其应用到模板中，但一些用户似乎不赞同其行为，故特地在社区专页发起讨论：
- 应将这些区域划分为哪几个部分？理由又是什么？
- 进行划分之后的部分是否应设置一个[显示/隐藏]按钮统一控制这些部分的显示/隐藏？
以上。--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)
本来是想开单独的话题讨论这个事，鉴于已开此话题，故在此话题下介绍相关情况。具体的显示效果可以在User:Anterdc99/Archives/Edition versions Preview看到。
- 背景
- 英文Wiki已于2个月前将
{{Java Edition versions}}和{{Bedrock Edition versions}}两个模板中正式版的内容进行了分段处理，并更新了各版本页面中的引用； - 目前的版本导航模板中正式版部分内容过长，不方便查找相关内容。（英文Wiki作出变更以及此处提议作出变更的根本出发点，也是众所周知的原因）
- 英文Wiki采用的方案
- 既然英文Wiki已经有现成的方案，为什么不直接使用？
- 英文Wiki目前的分段方式仅是将长度部分缩短，而对于达成改善检索条件，目前的效果还可以有提升空间，目前的分段后的长度仍然过长；
- 英文Wiki的方案需要对大量修改各版本页面，改动面过大。
因此，在本人设计新模板样式时，确定了以下要点（优先级递减）：
- 被展示部分的长度应当小于一屏，但可以略大于一屏；
- 被展示部分不应当太短（即避免将每个大版本划为一段的方式），但与其他部分较难相容时例外；
- 分出的段落应当长度一致或接近。
因此，在提交讨论的设计方案中，以下内容与英文Wiki的不同：
- 在
|1=中填入的参数为1.0（即原先的“正式版”总类）时，模板会根据版本页面的名称和归属版本确定要被展示的部分，可以减少相应的修改量； |1=参数支持直接填入下面列出的值，可在无法自动检测时正确显示相应内容；- 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两个中间段落在长度上大致相等。
- 携带版正式版/基岩版分为：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.0以前的版本合并为“测试版”就更完美了（因为分栏会一直增多，或者把Pre-Classic到Infdev合并，Alpha到Beta合并也行）。--Lxazl5770zh.admin（论 ▪ 功） 2022年6月26日 (日) 11:44 (UTC)
同时注意到Java版beta部分有许多空白，建议也对这些内容进行整理。--ultim_0 ( USER | TALK | WORK ) 2022年6月26日 (日) 12:11 (UTC)
UPDATE：根据上方建议，做了以下更改：
- 将Java版的pre-Classic到Infdev，以及Alpha与Beta分别合并到一起，原先的各阶段标识改到段落内作为分隔行；
- 由于调整后仍不能在一屏内显示，故正式版前所有内容并未合并在一起；
- 合并后，
|1=的pre-Classic、Classic、Indev和Infdev选项改为统一指向“pre-Classic - Infdev”段落；Alpha和Beta选项改为统一指向“Alpha - Beta”段落。
- 调整了Alpha和Beta的左栏样式以降低高度。
而关于测试版的统一控制，相似地，为了避免增加代码的复杂度，不会加入相应的控制按钮。-- 
Anterdc99（论·功） 2022年6月27日 (一) 14:27 (UTC)
有关格式指导中图像介绍的说明文字的末尾句号用法之问题与相关提议
行政员Lxazl5770在处理用户Louis0921gee有关画廊中说明文字句号的编辑时，引起了该用户对格式指导相关用法的疑问。
经查询，此说明于第一个版本写入格式指导，因此其实算是历史悠久的。相关疑问在中文Minecraft Wiki用户集中的地方也出现过数次（据用户口述可能有四次之多），而根据后来各用户的讨论，发现由于这些疑问的讨论，各用户甚至管理员似乎存在一个错误的印象，即认为这个问题已经解决，且解决方案是按照中文维基百科目前的方案（也就是“存在于图表中的短语式说明文字，其中部内容可用逗号，但末尾不用句号。就算是有些时候说明文字内容比较长，在前面的语段中已出现句号，最后的结尾处仍不用句号。”）执行。但这不是事实，这没有写入格式指导，且事实是这些疑问都是不了了之，并没有得出结论。
由于执行标准不一，实施情况不同，根据维基百科和标点符号用法（中华人民共和国国家标准GB/T 15834-2011）的相关说明，我在此提议更改格式指导有关图像介绍的说明文字的末尾句号用法的说明：
旧：图像介绍末尾不应有句号，除非语句是一个完整的句子。
新：图像介绍的说明文字末尾不用句号。就算是有些时候说明文字内容比较长，在前面的语段中已出现句号，最后的结尾处仍不用句号。
我的提议如上。希望各位用户参与讨论。-- Lakejason0（论•功） 2022年6月29日 (三) 10:38 (UTC)（最后编辑于2022年6月29日 (三) 10:55 (UTC)）
- 我的提议：一律不用句号，并且将原本的说明文字精简到一句话以内。以简化繁。--Lxazl5770zh.admin（论 ▪ 功） 2022年6月29日 (三) 13:43 (UTC)
- 这种要求不一定都能实现。建议将我的提案作为保底规则，然后将您的提议作为优先规则。-- Lakejason0（论•功） 2022年6月30日 (四) 07:11 (UTC)
- 这种要求不一定都能实现。建议将我的提案作为保底规则，然后将您的提议作为优先规则。--
- 由于管理员提出了新的意见，我的新提案如下：
- 旧：图像介绍末尾不应有句号，除非语句是一个完整的句子。
- 新：图像介绍的说明文字应精简到一句话以内。当且仅当图像内容足够复杂，需要使用超过一句话才能说明清楚时，可以超过一句话，但最后的结尾处不用句号。即使说明文字在多句话的前面的语句中已出现句号，最后的结尾处仍不用句号。
- 以上是我的新提案。如有更好的表述也欢迎提出。-- Lakejason0（论•功） 2022年6月30日 (四) 10:43 (UTC)（最后编辑于2022年6月30日 (四) 10:44 (UTC)）
【重要】关于本wiki的封禁准则
目前，尽管本wiki已经有了一则详细的条例，但在处理封禁方面仍无具体的准则。
为此，本人以行政员的身份拟定了一份封禁准则的草案希望能够听取各用户的意见并加以改进。
此事项相当重要。望各用户积极建言献策。祝各位编辑愉快。--Lxazl5770zh.admin（论 ▪ 功） 2022年6月30日 (四) 12:50 (UTC)
- 粗略查看了一下。目前该准则缺少对于先前使用较多的“提示性封禁”这一用法的说明。同时，我认为应当在该准则开头以较为亲切的口吻，使用Msgbox说明好，封禁是wiki维护与破坏防治中靠后的环节，管理团队不会对（绝对否定的说法可以自行修改为较为缓和的语气）轻微的不熟练操作采取封禁这一手段，等类似的内容。同样，应该在Wiki条例当中提及违反条例会按照封禁准则封禁。-- Lakejason0（论•功） 2022年6月30日 (四) 12:55 (UTC)
- “目标用户无视任意警告（例如撤销编辑或讨论页警告）”“管理人员在条件允许下应当在目标用户的讨论页里留下{{User warning}}以提醒该用户注意遵守Wiki条例”这些前戏应该统一，例如目标用户无视管理人员在目标用户讨论页留下的{{User warning}}。
- “匿名用户不允许永久封禁”推不出“封禁时长应当不超过1年”，留后半句就够了。
- 未尽事宜应该有个限制，例如不违反条例和applicable law的行为不应受到惩罚性封禁。
- 为什么设置那些不保留讨论页申诉权的情况？申诉权就是被封禁用户的权利，滥用申诉权的才应该撤销。传入神经元（权限|讨论|贡献|日志) 2022年6月30日 (四) 17:09 (UTC)
- 第二点把关联词移除掉就没问题了。其他的都算有道理。-- Lakejason0（论•功） 2022年6月30日 (四) 18:38 (UTC)
- 第二点把关联词移除掉就没问题了。其他的都算有道理。--
- 留言：对于使用可视化编辑器破坏页面源代码的行为，是否应当在封禁摘要中说明？--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 02:28 (UTC)
- 只要违反格式指导就给予一天封禁太过严重。违反格式指导的理论上没有封禁的必要，只需要给予提醒即可。屡次不改本身就违反条例。-- Lakejason0（论•功） 2022年7月1日 (五) 03:08 (UTC)
- 以及，利用傀儡破坏本身并不绝对属于极其恶劣的情况（取决于做出的破坏行为本身），因此不保留申诉权利并不合理。-- Lakejason0（论•功） 2022年7月1日 (五) 03:15 (UTC)
- 我写了一下Msgbox的内容，希望加入页面开头。表述都可以适当调整。-- Lakejason0（论•功） 2022年7月1日 (五) 03:54 (UTC)（最后编辑于2022年7月1日 (五) 11:54 (UTC)）
- 特殊情形：对于仅涉及单个页面的破坏行为（如导致苦力怕（消歧义）被半保护的事件），应当灵活处理。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 09:40 (UTC)
- 注册用户“插入具有营利性质的广告”立即无限期封禁——这样做是不是太严了？我承认，广告机器人创建账户就是为了发广告，但是有些开服玩家可能也写wiki，他们会在用户页宣传自己的具有盈利性质的服务器，而没有注意到Wiki条例。TripleCamera（留言） 2022年7月1日 (五) 11:48 (UTC)
- 可以在讨论页申诉吧？-- Lakejason0（论•功） 2022年7月1日 (五) 11:59 (UTC)
- 无限期封禁也可以通过申诉缩短封禁时长吗？无限期封禁给人一种行为非常恶劣的感觉。TripleCamera（留言） 2022年7月1日 (五) 12:07 (UTC)
- 可以在讨论页申诉吧？--
- 重罚更需要保留申诉权。传入神经元（权限|讨论|贡献|日志) 2022年7月1日 (五) 13:24 (UTC)
- Gamepedia是建立在Fandom的基础上的，在Fandom进行活动表明用户“已完全阅读并同意Fandom使用条款”。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 13:33 (UTC)
- 本wiki建立于Fandom提供的wiki农场之上。任何违反Fandom使用条款的行为均属于严重违规行为，不予申诉。--Lxazl5770zh.admin（论 ▪ 功） 2022年7月1日 (五) 14:06 (UTC)
- 重罚更需要保留申诉权。传入神经元（权限|讨论|贡献|日志) 2022年7月1日 (五) 13:24 (UTC)
┌──────────────────────────┘
怎么回到草案了？现在问题就是违反Fandom使用条款这种严重违规应该保留申诉权。传入神经元（权限|讨论|贡献|日志) 2022年7月2日 (六) 02:31 (UTC)
- 刚才我查阅了使用条款：“您同意不会：发布任何商业性广告或潜在性的商业信息。”此事属实。TripleCamera（留言） 2022年7月1日 (五) 13:47 (UTC)
- 建议：IP地址可更换性强，对其的普通或轻微违规行为单次封禁时长不应超过一周，严重或屡教不改的违规行为不应超过一个月。此外，还可以加上有关注册用户和匿名用户封禁时长具有差异的原因说明，避免被误解。--AblazeVase69188（讨论 | 贡献） 2022年7月2日 (六) 01:14 (UTC)
- 建议：在Wiki条例中，加入“禁止违反Fandom服务条款”的要求，列举“插入盈利性广告”等行为，并放在第一位（Minecraft条款放在第二位）。在封禁准则中，把所有“永久封禁且不予申诉”的惩罚进行醒目标记。既然惩罚非常重，那么应事先警告用户。--TripleCamera（留言） 2022年7月2日 (六) 01:49 (UTC)