Minecraft Wiki

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

了解更多

Minecraft Wiki
尚未注册？
注册
Advertisement
注册
Minecraft Wiki
Minecraft Wiki
6,591
个页面
分类: 使用已弃用source标签的页面、​存档
不转换

Minecraft Wiki:社区专页/存档4

< Minecraft Wiki:社区专页
Hatsuki kiri（留言 | 贡献）2020年5月13日 (三) 01:17的版本
登录以编辑
该页面是Minecraft Wiki:社区专页的存档页，请勿编辑该页面。

可在当前讨论页发起新讨论。

留言管理体系的引入

目前，Wiki内有很多不需要管理员处理的事件被报告至了管理员告示板，另外在不正确的页面讨论的情况也十分常见。

为了保护Wiki内的讨论环境，我提议引入维基百科的删除、移动和折叠留言的体系。

可供参考的中文维基百科模板：Inappropriate comment、Comment withdraw、Deltalk、Redacted和RPA。

个人 建议采用第一种，而其他有需要的可整合进入此模板。-- Dianliang233 讨论•贡献 2019年7月26日 (五) 12:39 (UTC)

确实，如果大量用户在管理员告示板报告不需要管理员处理的事，这样会加大管理员的压力，所以移动是有必要的112.65.92.28 2019年7月27日 (六) 04:50 (UTC)

User:Dianliang233/Sandbox/Inappropriate comment制作完毕。效果演示可见User:Dianliang233/Sandbox/2。-- Dianliang233 讨论•贡献 2019年7月29日 (一) 07:26 (UTC)

 支持。但是不知道搞事的人多不多，必要性有待论证。--LakeJason（论•功•博） 2019年7月30日 (二) 01:51 (UTC)

新的防编辑冲突模板

目前{{Wip}}模板已经被en改动。因此我提议创建一个新的防编辑冲突模板。可参考Template:Inuse。在此征集各位的意见。-- Dianliang233 讨论•贡献 2019年8月1日 (四) 12:14 (UTC)

 问题：由于本Wiki鸽子和拖延症患者众多（即小编辑时间很短，而大编辑通常没有固定时间我是真的不知道改一个条目要多少时间），又该模板需要写时间，因此建议不要全部照搬这个模板，可能Under construction也要合并？但是仅仅对于需要另一个模板的想法我是 支持的。--LakeJason（论•功•博） 2019年8月1日 (四) 14:20 (UTC)

提议建立新计划

现在wiki上有很多视频链接，很大部分是YouTube上的，在国内无法观看。

举个例子，各种教程页面就有好些，而一些教程没有视频很难看懂，在翻译时也有困难。

比如说，教程/利用活塞基本上全是视频，这个条目基本处于废弃状态。

为了方便语文不好的大多数人，我提议新建一个计划，搬运这些视频。

首要的当然是搬过来，有能力的话也可以做个字幕。--60.221.114.92 2019年8月1日 (四) 13:29 (UTC)

现在本Wiki正在进行条目视频化的计划，可能与您所建议的计划有重复。若并非如此，恕本Wiki人手不足，无法同时进行两个这样的项目。望理解。 MysticNebula70 ( T / C ) 2019年8月1日 (四) 14:01 (UTC)
另外，不经原作者同意直接搬运他们的视频可能会有版权问题。 MysticNebula70 ( T / C ) 2019年8月1日 (四) 14:05 (UTC)
可以鼓励有条件的玩家自己录制，不过这就要归入条目视频化了。--60.221.114.92 2019年8月1日 (四) 14:22 (UTC)

中文的格式指导

下列的有关中文格式指导的讨论已经结束。请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 同意进行。

受这条讨论的提醒，现在中文Wiki上只有从英文翻译来的格式指导，没有太多适用于中文的格式要求。此页面可能需要进行本地化，也作为准确判断一个编辑是否满足中文Wiki格式要求的依据。不知道各位有什么想法。 MysticNebula70 ( T / C ) 2019年8月1日 (四) 15:38 (UTC)

 支持。我的语文水平很烂，所以也做不到啥建议的点就是了。我觉得这种文件很容易受到一些抨击（尤其是因为主要是翻译，句子的结构如何调整是一件很烦人也很重要的事，比如从句是单独成句（本来的中文语法）还是长定语（西式语法）还是都取这种问题，不知道在座有没有对汉语语法非常敏感的人），不过既然要出就要出好，最好是不留遗憾。--LakeJason（论•功•博） 2019年8月1日 (四) 16:03 (UTC)
写错了吧，应该是Special:Diff/233133吧。还有，你们把Minecraft Wiki:书面汉语指导当成什么看的？--Sprite-bureaucrat Ff98sha（讨论·贡献） 2019年8月1日 (四) 16:07 (UTC)
两个内容不太一样吧。我觉得可以合并，搞一个本地化版本.jpg --LakeJason（论•功•博） 2019年8月1日 (四) 16:13 (UTC)
格式指导这个页面更多的是关于页面创建、排版、标题、重定向等之类的问题，这些在书面汉语指导那里面是应该没有的。 MysticNebula70 ( T / C ) 2019年8月1日 (四) 16:14 (UTC)
 支持。之前在译名群的讨论中，格式指导的可适用性就被质疑过。个人认为格式指导的本地化工作是有必要的。-- Dianliang233 讨论•贡献 2019年8月1日 (四) 23:51 (UTC)
 支持。我也认为格式指导需要书面汉语指导那样的本地化内容。-- Hatsuki kiri （论⁄功） 2019年8月2日 (五) 00:44 (UTC)

格式指导本地化计划已经上线到我的沙盒页，欢迎各位留言讨论以及动手修改。 MysticNebula70 ( T / C ) 2019年8月2日 (五) 15:08 (UTC)

关于语言页面的问题

在1.14.3-pre3中添加了哥特语和巴什基尔语，但是在语言页面并没有记载，我对Minecraft wiki的使用不是非常熟悉，所以请大佬帮助更新一下！谢谢。--117.90.137.41 2019年8月9日 (五) 00:09 (UTC)

 已完成。--Sprite-bureaucrat Ff98sha（讨论·贡献） 2019年8月9日 (五) 03:44 (UTC)

1.14.3这个页面有机械翻译嫌疑

1.14.3这个页面中（主要在漏洞修复章节）有部分语句不通畅，疑似机械翻译，还有部分未被翻译的内容。建议各位有能力的编辑者修改一下。--115.46.126.119 2019年8月12日 (一) 05:39 (UTC)

 处理中。--Lxazl5770zh.admin（论 ▪ 功） 2019年8月12日 (一) 12:28 (UTC)
 处理了一部分。--Dahesor（讨论） 2019年8月14日 (三) 22:38 (UTC)

请求删除恶意破坏条目

有未注册用户创建条目余俪，与wiki无关。传送门：余俪--Dahesor（讨论） 2019年8月14日 (三) 22:15 (UTC)

待删除的页面不应该被汇报于此，挂上{{delete}}才是正确的做法。-- Sprite-patrolDianliang233 讨论•贡献 2019年8月14日 (三) 23:19 (UTC)
唉......正常，第一次遇到。--Dahesor（讨论） 2019年8月15日 (四) 20:26 (UTC)

教程/PVP

教程/PVP这一页面后半部分几乎都是冗余的部分，有大量关于各种兵种的描述没有意义。如：刺客： 比间谍逊色一些，因为刺客没有装甲。 没有意义，没有人这么规定，完全可以穿盔甲。还有大量关于各类兵种的描述，去看一看就知道了，他们甚至在没有合理的标题下。→教程/PvP#帮派战争（向下翻）所以大的改动是很需要的。这里征集一下大家的意见。第二是太长，作为一个给新手的教程，篇幅太长。可以商量一下裁去或缩减某些段落（征集意见）第三是整个3分之1的内容几乎没有一点链接（也是篇幅太长导致的，加到5分之1就累了）。--Dahesor（讨论） 2019年8月15日 (四) 21:22 (UTC)

个人建议同步en即可。-- Sprite-patrolDianliang233 讨论•贡献 2019年8月16日 (五) 01:12 (UTC)

在Minecraft Forum中的疑惑

如题，条目中写到“Minecraft Forum（有时译为Minecraft论坛）是官方提供，用于讨论Minecraft的论坛。它被在2009年6月16日创建，创建者是citricsquid，并且在大量的玩家的努力中发展壮大，此论坛与Mojang并没有任何关系（尽管有些Mojang职员在这里注册）。”前面写到官方提供，但是后来写没有任何关系，这样感觉有点矛盾。--122.228.233.79 2019年8月15日 (四) 23:08 (UTC)

根据英文wiki;Minecraft论坛是Minecraft的社区论坛。 它由Minecraft Wiki社区成员citricsquid于2009年6月16日创建的。它跟wiki有关，而wiki是官方的。不过中文版的确要处理一下--Dahesor（讨论） 2019年8月16日 (五) 00:37 (UTC)
@Dahesor：现在页面问题已经解除了。117.90.79.234 2019年8月16日 (五) 12:58 (UTC)
Minecraft Wiki和Minecraft Forums在以前都是被认定官方的，虽然现在Mojang将所有非Mojang管理的网站都列为非官方，但我们还是认为这两个网站都是官方的。你可以在Minecraft官网的历史网页快照中找到。--Sprite-bureaucrat Ff98sha（讨论·贡献） 2019年8月16日 (五) 14:17 (UTC)
@Ff98sha： 我 反对不过可以解释下为什么这么认为吗？--59.63.221.88 2019年8月16日 (五) 22:57 (UTC)
请在讨论时签名，并使用冒号缩进。-- Sprite-patrolDianliang233 讨论•贡献 2019年8月16日 (五) 23:00 (UTC)
好的，谢谢121.232.199.73 2019年8月18日 (日) 09:39 (UTC)
在Minecraft官网改版之前，wiki和forums都被认为是官方的，至于原因你可以问Mojang；不过我认为，Mojang的员工会活跃在wiki和forums上，也会在wiki放文档、在forums放更新日志与其官方性有些关联。对了，minecraftwiki[.]net是由Mojang提供的wiki重定向网址。--Sprite-bureaucrat Ff98sha（讨论·贡献） 2019年8月18日 (日) 11:26 (UTC)

File:Wall Sign.png和File:Standing Sign.png

这两个页面和File:Oak Wall Sign.png和File:Oak Standing Sign.png重复，唯一的区别是带有文字。有几个解决方案：

  1. 删除文件，不留重定向（en如此）
  2. 删除文件，改为重定向至File:Oak Wall Sign.png和File:Oak Standing Sign.png
  3. 保留文件，但更改名称，原名称改为至File:Oak Wall Sign.png和File:Oak Standing Sign.png的重定向

——Icyphantom 讨论I贡献 2019年8月20日 (二) 06:33 (UTC)

我的某个用户框就是因为有字才用这个的.jpg，我一会儿改掉？--LakeJason（论•功） 2019年8月20日 (二) 06:42 (UTC)

关于基岩版开发者文档翻译

目前{{Bedrock Edition Developer Documentation}}中仍有不少条目需要翻译，另外该如何跟进官方的最新版本。不知道各位有什么想法。 Popakrt（讨论） 2019年8月24日 (六) 02:43 (UTC)

我不知道你的意思是什么，只要同步+翻译就好了。而且开发者文档一直都没人翻译的原因是枯燥无聊难懂常更新。-- Sprite-patrolDianliang233Oak Sign Revision 1TIron Pickaxe C 2019年8月24日 (六) 02:49 (UTC)
你是指因为条目过长希望有更多有能力的人来翻译？有能力的都直接翻EN的--LakeJason（论•功） 2019年8月31日 (六) 17:39 (UTC)

psv版

据我所知,minecraft里有psv版，但wiki为什么没有记录？--101.20.244.249 2019年8月30日 (五) 06:50 (UTC)

PlayStation Vita版，请善用搜索功能。-- Sprite-patrolDianliang233Oak Sign Revision 1TIron Pickaxe C 2019年8月30日 (五) 07:12 (UTC)
 已完成，添加了重定向。--kaniol 唠▣献 2019年8月30日 (五) 11:03 (UTC)

关于用户讨论页通知/警告

我发现在维基百科关于讨论页的警告有特定的模板，但在这里似乎是纯手打。这样一来，我认为关于讨论页的通知/警告没有一个统一的标准，而且对对方进行通知/警告时文本会难以记忆。是否需要一个专门的模板进行通知/警告？--HlDorəmon(TAlK · C0NTR1BZ) 2019年8月30日 (五) 20:56 (UTC)

你是指{{user warning}}吗？我们对这些模板做了整合。 MysticNebula70 ( T / C ) 2019年8月31日 (六) 00:47 (UTC)

公共沙盒

下列的有关公共沙盒的讨论已经结束。请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 同意设立。

由于本wiki上不提倡主页面上留有过多非中文内容，所以大家在搬运的时候会先在自己用户页下先创建沙盒页面，在翻译完毕后再移动至主页面。但是这样却有极大的撞车可能性，我们没法保证开坑前翻过别人的沙盒页，而且大家的沙盒页也没有统一的命名规律。同时，这样的搬运模式也含有大量的个人承包意味，别人难以参与协作，若修改可能还需征得沙盒主人的同意。而像一些例如官方页面，十分冗长，并不是一个肝帝就能完成的事，而保留大量英文直接搬运也是不妥当的行为。

公共沙盒会类似于教程页，作为一个父页面分类其所有子页面，而在子页面成型后移动页面并在父页面内删除链接。另外，我觉得也可以在此处决定还未开坑翻译的页面名，避免不必要的翻译名不统一。

我认为如果加入公共沙盒，则能更加鼓励大家搬运并协作翻译en的条目。同时，一些中文原创类的条目以及一些计划中的模板也可在这里由大家逐渐完善。这样的话应该能有助于减少wiki条目成型期的孤立性，并增加wiki编者们协作编辑的积极性。--kaniol 唠▣献 2019年8月31日 (六) 17:01 (UTC)

 支持。之前execute就是撞车了（结果翻译完搬运到主页面的新内容被删掉了）。--LakeJason（论•功） 2019年8月31日 (六) 17:33 (UTC)
补充一下，在微机课上没办法登录，所以我认为这的确是有必要的。--LakeJason（论•功） 2019年9月7日 (六) 09:50 (UTC)
 支持。公共沙盒可以让更多人看到，且IP用户也可以参与编辑而不会被过滤器过滤（过滤器存在一条不允许IP用户编辑用户页的规定）。——Icyphantom 讨论I贡献 2019年9月1日 (日) 02:00 (UTC)
所以做好了吗?119.251.6.177 2019年9月1日 (日) 06:51 (UTC)
 反对，我认为wiki没有这方面的需要。翻译撞车的情况极少发生。--Sprite-bureaucrat Ff98sha（讨论·贡献） 2019年9月1日 (日) 08:38 (UTC)
如前所述，已经出现了撞车的事件，而且现在搬运的完整页面还并不多。此外，我认为一些未搬运的页面可以采用先原文搬运，再一同翻译的模式，以增加翻译积极性与协作性。还有，我认为不少沙盒页本身就不应该隶属于用户页，而应该开放给所有用户。--kaniol 唠▣献 2019年9月1日 (日) 12:30 (UTC)
 支持。IP和大工程需要这个。-- Sprite-patrolDianliang233Oak Sign Revision 1TIron Pickaxe C 2019年9月7日 (六) 03:20 (UTC)
事实上，en那边是有公共沙盒的，见en:Minecraft Wiki:Sandbox，用法也大致差不多。如果确定要添加公共沙盒，需要讨论一个沙盒保存多久（距最后一次修改已经有一段时间后需要删除此沙盒）。 MysticNebula70 ( T / C ) 2019年9月7日 (六) 03:53 (UTC)

本议题进入公示期，若3日内无异议即可执行。另欢迎留言建议。-- Sprite-patrolDianliang233Oak Sign Revision 1TIron Pickaxe C 2019年9月8日 (日) 04:04 (UTC)

如上所述，一个沙盒距最后一次编辑要多少时间可判定为无人管理而删除或清空？ MysticNebula70 ( T / C ) 2019年9月8日 (日) 05:14 (UTC)
 不必要。沙盒的内容迟早会被什么人更新。除非本身已经与en差别过大导致过期，或沙盒页的内容已被创建，否则删除是不必要的。——Icyphantom 讨论I贡献 2019年9月8日 (日) 06:32 (UTC)
我的意思正是你说的“与en差别过大导致过期”，以及某些可能的原创内容。这些内容需要一个能判断的时间来确认它们确实过期或没人编辑了。（当然直接挂{{delete}}也可以） MysticNebula70 ( T / C ) 2019年9月8日 (日) 07:21 (UTC)
“是否过期”不应该由时间决定：有可能刚搬来翻了一小段en就大规模更新了，也可能几年也不会见有什么动静。“没人编辑”不代表“未来没人编辑”，说不定哪一天有人就会来填这个沙盒了。因此不应该按照某某时间去清空沙盒，遇到过期和重复的直接提醒删除即可。——Icyphantom 讨论I贡献 2019年9月8日 (日) 08:36 (UTC)
那么什么情况可以被认为是过期的？如果总是“未来会有人编辑的”，那么这个沙盒一直都不会过期。还有，我要是看到了“过期”的沙盒会直接删除，不会提醒的。 MysticNebula70 ( T / C ) 2019年9月8日 (日) 09:32 (UTC)
我认为沙盒不应该只是简单地因为超过某段时间删除，而应该先讨论搬运这个页面的必要性。如果发布超时讨论一段时间后对过期没有异议再删除，否则继续作为沙盒编辑（并催更--kaniol 唠▣献 2019年9月8日 (日) 13:26 (UTC)
 支持此想法。按照社区共识来运行沙盒会更好。 MysticNebula70 ( T / C ) 2019年9月8日 (日) 16:58 (UTC)
 支持这种东西有比没有好。--Dahesor（讨论） 2019年9月9日 (一) 23:34 (UTC)

沙盒创建位置仿照en，位于Minecraft Wiki名字空间下，页面名称就是“沙盒”，应该没有什么问题吧。如果无异议沙盒将于明天正式启用。 MysticNebula70 ( T / C ) 2019年9月11日 (三) 11:40 (UTC)（最后编辑于2019年9月11日 (三) 11:45 (UTC)）

拆分使用gif格式展示的物品图片

File:Music Discs.gif 此图片使用了多帧图像来依次展示各个唱片。

这样会造成使用的不便。自己无能力拆分图片，因此希望有人将本图片拆分至多个单独的图片，同时检查有没有其他以这种形式展示物品的图片。——Icyphantom 讨论I贡献 2019年9月12日 (四) 03:25 (UTC)

 已处理。 MysticNebula70 ( T / C ) 2019年9月12日 (四) 10:21 (UTC)

关于机器翻译的相关条例

目前本Wiki的各编辑者都认可严禁使用机器翻译，但Wiki关于这一点的要求却十分分散，不是很容易寻找；而且关于具体如何处理使用机器翻译的用户也不够清楚。是否应该将这一条写到更明显的地方（例如Wiki条例中）？ MysticNebula70 ( T / C ) 2019年10月6日 (日) 07:52 (UTC)

 支持。不过语文不好能够写出疑似机翻的内容呢（--LakeJasonFace Lakejason0（论•功） 2019年10月6日 (日) 07:59 (UTC)
 支持。除了Wiki条例，这一点也可以写入编辑页面的MessageBox中，使得编辑者更容易发现和了解。-- Hatsuki kiri （论⁄功） 2019年10月6日 (日) 08:05 (UTC)
 请稍等，条例正在起草。--Lxazl5770zh.admin（论 ▪ 功） 2019年10月6日 (日) 09:14 (UTC)
 已完成，已将相关内容写入编辑手册中。--Lxazl5770zh.admin（论 ▪ 功） 2019年10月6日 (日) 12:29 (UTC)

是否需要介绍Fabric

Minecraft Wiki对Forge已有介绍，但是没有与Fabric有关的条目。对于最新版而言，很多mod都是兼容Fabric，因为Fabric更新更快而且更加轻量。--SolidBlock（讨论） 2019年10月13日 (日) 00:08 (UTC)

根据格式指导的要求，所有关于Mods的内容都应转移至FTB Wiki上，而且关于Fabric的内容FTB上已经有了，本Wiki最多只需要一个软重定向。 MysticNebula70 ( T / C ) 2019年10月13日 (日) 02:06 (UTC)
所以导出至FTB Wiki到底是指什么（--LakeJasonFace Lakejason0（论•功） 2019年10月13日 (日) 02:10 (UTC)
说白了就是把条目直接搬过去。 MysticNebula70 ( T / C ) 2019年10月13日 (日) 02:18 (UTC)

辅助程序与编辑器/过期软件似乎出现了问题

在我查看这个页面时，“作者”一栏写的是一个无效链接。106.114.241.89 2019年11月14日 (四) 12:00 (UTC)

 已修复。 MysticNebula70 ( T / C ) 2019年11月14日 (四) 12:09 (UTC)

关于不规范命名的文件，以及用户页受损链接的相关问题

目前，本Wiki上仍存在大量未进行规范命名的文件。以直接使用日期作为文件名的图片为例，我们可通过在多媒体模式下搜索关键词201*得知，仅仅是这一类未规范命名的文件就有多达约200件。而今天我在处理这批文件时，发现有一些用户在自己的用户页（包括部分沙盒）中链接到了这些文件。如果对这些文件进行重命名处理，则存在问题的用户页将会出现文件红链，继而维护型分类页面Category:含有受损文件链接的页面的使用将会产生不便。且该分类下目前已经存在部分含有文件红链的用户页，并长期未得到处理。

为解决这一问题，我在此提出两种方案供各位参考：

  1. 对存在问题的用户页直接进行修改，例如将重命名后的文件应用到这些用户页上。如遇到已不存在的文件，且Wiki上不存在合适的替代文件，则直接将其链接删去。但考虑到Wiki约定俗成的礼仪，此方案可能较为强硬。
  2. 采用英文Wiki的做法（详见此处的讨论），若存在问题的页面所属用户在某一指定日期（需讨论）后没有再进行过任何编辑，则将页面的内容以模板{{InactiveUserpage}}统一进行替换。若这些页面所属的用户重新开始活跃，则页面可以随时恢复原来的状态。对于目前仍在活跃的用户，则提醒其及时自行处理红链。

各位对此看法如何？如果有更好的方案，欢迎在下面提出。当然，如果各位认为此问题暂时不必要着手解决，也可搁置。-- Hatsuki kiri〔论⁄功〕 2019年11月16日 (六) 14:46 (UTC)

 中立。你说可以搁置，那就搁置掉好了.jpg感觉几个方案都有一些令我不是很喜欢的地方（但是说不上原因）。看看有没有更好的方案吧。在这之前我没有什么更好的意见。--LakeJasonFace Lakejason0（论•功） 2019年11月16日 (六) 16:16 (UTC)
 第二个。解决问题还不失礼貌。-- DLFace Dianliang233 T•C 2019年11月16日 (六) 23:10 (UTC)
个人认为，直接修改用户页上被重命名的文件并无不妥。--Sprite-bureaucrat Ff98sha（讨论·贡献） 2019年11月17日 (日) 05:27 (UTC)

如无异议，我们将在尽可能不变动用户页实际显示内容的前提下执行方案一。-- Hatsuki kiri〔论⁄功〕 2019年12月4日 (三) 05:16 (UTC)

申请更新wiki首页布局

下列有关主页布局的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 已由Cuervo完成更新同步，讨论关闭。-- DLFace Dianliang233 T•C 2019年12月1日 (日) 01:46 (UTC)

目前zhwiki的首页仍旧使用table进行排版，更利于移动设备显示、更符合HTML5及CSS3设计理念的页面应尽量避免table的使用，故申请将首页替换为新的布局

  • 说明：
    1. 新布局在视觉上无任何变化
    2. 采用网格+弹性盒子的设计
    3. 响应式优化，对手机用户友好，内容不会再飞出屏幕
  • 更新步骤：
    1. 将Minecraft Wiki的内容替换为Minecraft Wiki/editcopy的内容
    2. 将Minecraft Wiki/weekly的内容替换为Minecraft Wiki/editcopy/weekly
    3. 将Minecraft Wiki/style的内容替换为Minecraft Wiki/editcopy/style(2019年11月17日 (日) 07:12 (UTC)新增)
    4. 在wiki样式表中添加以下规则(可以往下滚)：
/** 首页排布样式 **/
/** 宽屏幕 **/
@media screen and (min-width: 965px) {
  .mainpage-all {
    display: grid;
    grid-template-areas:
      "a a a"
      "b b c"
      "d d c"
      "e f g"
      "h i j";
    grid-template-columns: 33% 33% 34%;
  }
  .mainpage-top-list {
    display: flex;
  }
  .mainpage-top-list .list-columns {
    width: 25%;
  }
  .mainpage-top-list .mc-logo {
    padding: 18px;
  }
}
/** 窄屏幕 **/
@media screen and (max-width:965px) {
  .mainpage-block .mainpage-block-inner img {
    max-width: 100% !important;
    height: auto;
  }
  .mainpage-top-list {
    display: block;
    max-width: 100%;
    overflow-y: hidden;
    overflow-x: auto;
  }
  .mainpage-top-list .list-columns {
    width: 50%;
    display: table-cell
  }
  .mainpage-top-list .list-columns li {
    list-style: none
  }
  .mainpage-top-list .mc-logo {
    padding: 18px;
    width: 100%;
    display: table-caption;
  }
  .mainpage-top-list .mc-logo img {
    width: 100%;
  }
}
/** 通用样式 **/
.mainpage-block {
  padding: 0px;
  margin: 2px;
  background-color: #FCFCFC;
  border: 1px solid #CCC;
  vertical-align: top;
  position: relative;
}
.mainpage-block .mainpage-block-inner {
  padding: 0.5em 0.8em;
}
.mainpage-block .mcwiki-header {
  margin: 3px; 
  padding: 8px 0;
  font-weight: bold;
  text-align: center; 
  color: white; 
  font-size: 120%;
  background-image: url(/media/c/c1/GrassBackground.png);
  position: relative;
  overflow: unset;
}
.mainpage-block .mcwiki-header img {
  position: absolute;
  right: 18px;
}
.mainpage-block .mcwiki-header .header-calendar {
  position: absolute;
  right: 24px;
  top: 12px;
  padding: 0;
  margin: 0;
  z-index: 1;
}
.mainpage-block .mcwiki-header .header-calendar .year-month {
  font-size: 8px
}
.mainpage-block .mcwiki-header .header-calendar .day {
  font-size: 26px;
  color: black;
}

申请者：机智的小鱼君⚡ (给我留言✨) 2019年11月16日 (六) 17:24 (UTC) 肝硬化了，头也秃了，但是——变强了！！！

 问题：为什么不直接照搬en主页的格式，使用/style子页面模板呢？这对日后维护、同步有很大的不便。另外，您在编辑时删去了版本区对的空格，这也是不利于更新的。希望各位再考虑一下这个问题再部署。-- DLFace Dianliang233 T•C 2019年11月16日 (六) 22:58 (UTC)
起初未发现有/editcopy/style子页面，事实上这一点我可以调整 机智的小鱼君⚡ (给我留言✨) 2019年11月17日 (日) 06:23 (UTC)
已经改用/style子页面，关于制表符问题，不建议在页面内使用缩进 机智的小鱼君⚡ (给我留言✨) 2019年11月17日 (日) 07:12 (UTC)
哈——哈——哈——果然还是有缩进比较好呢，快要瞎了，已恢复版本区的缩进 机智的小鱼君⚡ (给我留言✨) 2019年11月17日 (日) 07:25 (UTC)
 问题：本周页面变为弹性设计，可图片不是，会导致部分设备文字进入图片和框之间的缝隙。-- DLFace Dianliang233 T•C 2019年11月16日 (六) 23:59 (UTC)
 另一个问题：每周页面的“提议一个页面”位置不正确，它现在在分类的框里。 MysticNebula70 ( T / C ) 2019年11月17日 (日) 03:23 (UTC)
css已考虑图片元素，关于提议一个页面是因为父元素定位变更的问题，需要修复。 机智的小鱼君⚡ (给我留言✨) 2019年11月17日 (日) 06:23 (UTC)
@User:MysticNebula70 每周页面的“提议一个页面”位置已经通过css修复，为父元素添加了定位 机智的小鱼君⚡ (给我留言✨) 2019年11月17日 (日) 07:12 (UTC)
 支持更新。但是由上述言论，对小鱼君提出的方案保持 中立。--LakeJasonFace Lakejason0（论•功） 2019年11月17日 (日) 02:10 (UTC)
综上，我对此想法表示 支持，但对于方案表示 反对。-- DLFace Dianliang233 T•C 2019年11月17日 (日) 03:08 (UTC)
和 DLFace Dianliang233 T•C 想法相同--Dahesor（讨论） 2019年11月23日 (六) 22:34 (UTC)
 支持。-- DLFace Dianliang233 T•C 2019年11月23日 (六) 23:49 (UTC)

提请删除

请删除以下页面：

User:Xiaoyujun/common.js/CustomModal.js

User:Xiaoyujun/common.js/InPageEdit.js

User:Xiaoyujun/sandbox/Mainpage

User:Xiaoyujun/common.js/QuickRedirect.js

User:Xiaoyujun/sign/load

理由：用户申请，部分代码页面无法正常添加{{delete}}模版 机智的小鱼君⚡ (给我留言✨) 2019年11月16日 (六) 17:50 (UTC)

实际上，js/css页面加/* {{d}} */也会有分类的。-- DLFace Dianliang233 T•C 2019年11月16日 (六) 23:01 (UTC)
已部分 完成，但剩余页面的删除需要管理员权限，巡查员无法操作。-- Hatsuki kiri〔论⁄功〕 2019年11月17日 (日) 00:29 (UTC)
需要更改页面模型，见Special:ChangeContentModel。 MysticNebula70 ( T / C ) 2019年11月17日 (日) 01:41 (UTC)
 已完成。--Sprite-bureaucrat Ff98sha（讨论·贡献） 2019年11月17日 (日) 05:27 (UTC)

镐出现了问题

第9章节表格错乱。--106.114.16.84 2019年11月17日 (日) 14:29 (UTC)

未发现任何问题，请具体描述。-- Hatsuki kiri〔论⁄功〕 2019年11月17日 (日) 14:33 (UTC)

成就时间

我在设置中将“时区”设置成了Shanghai（上海），但在统计：成就中，显示的成就达成时间依然是UTC时间。请问这个问题可以修正吗？亦或是MW的问题？🎅🏻 Huerdada✨讨论⁄贡献 2020年1月16日 (四) 12:51 (UTC)

此时间似乎并不由参数设置控制，会始终显示UTC时间。 MysticNebula70 ( T / C ) 2020年1月16日 (四) 13:19 (UTC)

关于标题顶部的保护挂锁

下列有关添加保护状态锁的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 同意添加，附加信息为：已由Cuervo完成。

在标题的右侧挂上图标可以让他人更有效的了解此页面的信息。我已上传4个不同的保护锁文件（半保护、全保护、移动保护、文件保护），页面效果也基本做好（可在此处查看）。在en中也有这样的设计，不过锁图标已经过时。能否在zh中使用这样的设计？--HlDorəmon(7AlK · C0И7Я18z) 2020年1月22日 (三) 08:43 (UTC)

 支持。-- Hatsuki kiri〔论⁄功〕 2020年1月22日 (三) 08:54 (UTC)
概括译者群的讨论：
  • 可用JavaScript或WikiCode实现。
    • JS更被支持。
      • 但我们缺少相关的有技术的人。
        • 有人推荐@Xiaoyujun：他编写了在本Wiki部分用户使用的功能较为强大的InPageEdit插件，并有前端基础，热爱Web开发。
    • 用WikiCode简单但费力。
  • 有加入模板保护、白纸保护和连锁保护（虽然本Wiki未有页面使用）图标的呼声。
个人意见 赞成，且偏向JS方案，找有相应经验和时间的人员编写。而此JS应该可以识别保护等级（全半连移）、名字空间（文件模板）、是否有内容（白纸），添加相应图标。-- DLFace Dianliang233 T•C 2020年1月22日 (三) 09:06 (UTC)（最后编辑于2020年1月22日 (三) 11:05 (UTC)）
 中立。虽然可以十分方便地查看保护状态，但同样可以通过编辑源代码或页面信息查看到保护状态，保护状态并不是人人都要了解。并有较小可能减缓页面加载速度。且在移动设备的显示效果较差。希望有更好的解决方案。Huerdada's Minecraft Skin Head Huerdada · T⁄C 2020年1月22日 (三) 09:38 (UTC)
各个回复：1.我相信没有人想要麻烦的方法，并且这借鉴了维基百科和en。2.保护状态对Wiki管理十分重要。3.若使用异步加载不会减慢访问速度。4.移动端不会显示。5.若有更好的方案欢迎开小话题。-- DLFace Dianliang233 T•C 2020年1月22日 (三) 11:05 (UTC)
关于电量“移动端不会显示”的回复：
  • 桌面版移动端是会显示的。目前不知是指移动版还是桌面版。
    • 虽然桌面版在移动设备上本身就不具有良好效果，但显示的真的不怎么样。--Huerdada's Minecraft Skin Head Huerdada · T⁄C 2020年1月22日 (三) 11:23 (UTC)
在移动设备开桌面网站你觉得可能受支持吗？-- DLFace Dianliang233 T•C 2020年1月23日 (四) 00:59 (UTC)
去除这点我是 支持的。--Huerdada's Minecraft Skin Head Huerdada · T⁄C 2020年1月23日 (四) 02:18 (UTC)
小鱼君对于主页的布局更改不也是对于桌面版移动端的更改吗，不过我们可以请他来看看能不能解决。--Huerdada's Minecraft Skin Head Huerdada · T⁄C 2020年1月27日 (一) 01:14 (UTC)
  • 简单回答一下关于如何实现的问题：
    • 不推荐wikicode，因为需要人为维护
    • 用一小段js可以实现这个效果，而且因为是异步实现，所以对页面加载速度不会造成太大的影响
  • 关于是否实施的问题:
    •  中立，但如果需要技术方面的帮助，我定会协助
机智的小鱼君⚡ (给我留言✨) 2020年1月22日 (三) 10:32 (UTC)
虽然我已经把zh的所有保护的页面都记住了，但是添加一个不影响加载速度的保护等级指示的锁图像我是 支持的。 MysticNebula70 ( T / C ) 2020年1月22日 (三) 14:29 (UTC)
 支持。有时候会在意识到被保护前点击编辑按钮。-- LakeJasonFace Lakejason0（论•功） 2020年1月23日 (四) 10:49 (UTC)
顺便说一下被保护的页面是"查看源代码"，所以不太可能意识到之前点击编辑。不过js自定义除外。--Huerdada's Minecraft Skin Head Huerdada · T⁄C 2020年1月23日 (四) 11:27 (UTC)
人对图像比对文字敏感的多。-- DLFace Dianliang233 T•C 2020年1月23日 (四) 12:18 (UTC)
 支持没有理由不。（但我不清楚实行难度，所以......）--Dahesor 2020年1月27日 (一) 00:05 (UTC)
可以考虑类似en的做法：把“是否显示保护等级的锁图标”作为一个选项放入小组件中，由用户自己选择是否启用（en应该是默认启用）。en用js参考：en:MediaWiki:Gadget-protectionLocks.js。 MysticNebula70 ( T / C ) 2020年1月27日 (一) 03:14 (UTC)
这个可行，建议找个会js的搞一下。--HlDorəmon(7AlK · C0И7Я18z) 2020年1月27日 (一) 05:40 (UTC)
社区内容除另有注明外，均在CC BY-NC-SA许可协议下提供。
Advertisement