讨论:讨论板

欢迎来到 MCBBS Wiki 讨论板！ 您现在所在讨论板分区。下列列出了本站讨论板的所有分区。 如果您想发表的问题没有符合的分区，欢迎发表在讨论板分区。
💭讨论板	🔨综合申请	👤申请职位	📜需求页面
讨论 Wiki 问题	申请改名，页面删除，举报页面等	用户申请职务之处	收录用户需要的页面
发表 | 监视 | 存档	监视 | 存档	监视 | 存档	发表 | 监视
📝编辑请求	🔌技术讨论	🖼梗图收录	MCBBS Wiki talkboard
申请编辑某个高权限页面	报告技术问题，提出功能请求	提交梗图 API 的图片收录申请	License: CC BY-NC-SA 4.0
发表 | 监视	发表 | 监视	监视
其他页面：Wiki方针 • 公告 • 沙盒 • 最近更改 • 封禁列表			QQ群 • Discord群组 • Github

讨论板（Talk Board）是用户可以向wiki社区讨论的平台。虽然用户也可以直接联系特定的管理员（尤其是活跃的管理员），但是在此处贴出跟更能保证有管理员会注意到并快速回应。请记得留言后签名（在末尾添加：“--~~~~”），未签名的讨论串将会被删除！

讨论板存档页

---

2020年 1 2 3 4 5 6 7 8 9 10 11 12 月
2021年 1 2 3 4 5 6   --- 7 ~ 12 --- 月
2022年 1 2 3 4 5 6 7 8 9 10 11 12 月
2023年 1 2 3 4 5 6 7 8 9 10 11 12 月
2024年 1 2 3 4 5 6 7 8 9 10 11 12 月

先别急着帖出问题，请先仔细斟酌以下几条：

• 此页面仅用于报告Wiki问题。
• 用户间的调解请求只有在双方无论如何都不能达成共识的情况下才可发表。
• 明确你的请求有一定意义。

关于收录范围扩展

为了Wiki转正常化我提议扩展收录范围。

不知各位是否同意bbswiki扩展收录范围。

如果同意，请推荐要的收录范围并说明理由。

不同意，请说出理由。

例:

(＋)同意建议添加收录范围[原创皮肤|材质资源],因最近有人(某Elen)反馈为什么不收录皮肤等资源。

(－)反对太操之过急，应一步步来。

Eicy（讨论） 2020年8月30日 (日) 21:55 (CST)

(：)回应建议移除形式限制，允许任何知名度高的作品。--洞穴夜莺（讨论） 2020年8月30日 (日) 22:55 (CST)

(：)回应我认为mcbbs内的一切有质量作品都可以，且应当收录。-- 自由李代数 讨 贡 狗娃安慰噶喔。 2020年8月31日 (一) 06:42 (CST)

(：)回应像“水楼”“卤蛋神教”等我都认为是符合Wiki大方向且值得收录的，但都不在（目前的）收录范围内。梗是算不上的，别的更说不上。那么我觉得是需要扩展范围的。只是想不出来具体扩展到什么样的范围。--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年10月19日 (一) 21:58 (CST)

(☩)意见：“水楼”大可算作论坛优秀/著名主题贴，可以添加相关分类/模板进行收录。“卤蛋神教”其实还是属于梗的。

另外，我其实有收录QQ群的意向（之前计划在项目页面撰写wiki相关QQ群信息，由此想到）。-- MashKJo-{（用户页）/（讨论页）/（贡献）}- 2020年10月19日 (一) 23:09 (CST)

(＋)同意建议拓宽收录形式，如果可以，建议直接取消掉形式限制。--Gear? - 论 / 献 2020年10月29日 (四) 21:48 (CST)

(＆)建议我认为那种原创数据包、模组、材质、皮肤等那种都要收录，只要不是那种低俗的的，就可以收录，不然别人怎么看？只会觉得这是个只是玩梗的一个片面wiki。 --用户:沙漠之鹰xzy（Talk） 2020年11月7日 (四) 12:25:34 (CST)

?

wiki建站初衷就是玩梗，现在虽然有很多正经条目，核心仍然是沙雕。我倒不希望bbswiki变成萌百那样——从AGC百科变成萌娘版wp大杂烩。-- MashKJo-{（用户页）/（讨论页）/（贡献）}- 2020年11月7日 (六) 17:12 (CST)

(：)回应好吧，那么我觉得至少在用户页放一些作品链接和简单介绍应该可以吧，不要专门开页面 --用户:沙漠之鹰xzy（Talk Contribution） 2020年11月8日 (四) 19:12:18 (CST)

(：)回应wiki建站初衷就是穹妹想玩梗，不正经的东西反而才是你wiki的核心，范围我感觉除了服务器和纯水讨论不行。但是总归泥潭的作品质量参差不齐，有的作品确实放到wiki上非常的违和。但是最主要的还是放开了以后就水起来了，巡查工作+234%虽然现在也还好，不是很多，再一个呢就是救一个编辑失败的页面比你自己写累得多，不过仍可以接受。范围的话，本来就有人写梗进来，放不放开好像对水怪区别不太大，最主要的还是那些正经的作品,感觉可以适当要求合并同类项，把同系列的东西丢一起，防止页面虚多。--又名文章生成器（讨论） 2020年11月22日 (日) 08:32 (CST)

(＝)中立隔壁萌百的收录范围从最开始的ACG（动画漫画游戏）到现在ACG沾点边就能找得到，也算是百科类网站发展的趋势；不过MCBBSWiki只是一个娱乐百科，虽说理论上这里需要收录的是MCBBS的内容，但不代表MCBBS以外的不能收录，也不代表是MCBBS的就要收录；综上，中立态度。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年11月25日 (三) 19:26 (CST)

(＋)同意 建议收录更多的用户与小组

一--永远的友人（讨论）

(＋)同意我建议建造一些永久《诗经》以后人传诵，《泥潭集》收录一些文学创作。

一--伟大的小安（讨论） 2020年12月31日 (日) 23:10 (CST)

(＋)同意 建议先从影响较大的版块的精华作品收录起，可以从新到旧收录。不过，收录作品之前要先征得原作者同意。 另外，可以首先考虑已收录进本wiki的用户的作品。

-- Best regards, LeoPro | Talk | Contributions | 30 2021年1月5日 (二) 00:00 (CST)

关于Wiki编辑等级

这个想法是很不错的。不过目前我有几点建议：

1. Lv40，Lv50和Lv60的颜色差距稍微大一点（因为Wiki几个活跃用户都在40-60级，颜色区分度太小了难以快速分清）。
2. Lv1-Lv20的间隔太小了，用户刚编辑几次就十几级了，不太好。
3. 或许可以加一个模板参数控制是否对每项积分生成扇形图？（类似{{MCBBS积分分析}}）

--QWERTY770 61 讨 贡 2020年11月17日 (二) 19:54 (CST)

这东西最开始是绵羊设计的，我重写了代码+移植到这个Wiki，等级数值什么的都没改，所以看起来哪里都有问题..

• 积分，我建议的公式：等级=最小值(总积分^0.5, 100)。
• 颜色：我懒得配色，让绵羊上。
• 扇形图：完全可以，不过可能代码要重写一半。

—— Salt lovely「敢竭鄙怀，恭疏短引」 2020年11月17日 (二) 20:07 (CST)

颜色其实没必要那么复杂，直接用彩虹色（论坛那种）不就行了。--QWERTY770 61 讨 贡 2020年11月17日 (二) 21:27 (CST)

我个人觉得这东西更适合用户页，而非条目页。-- MashKJo-{（用户页）/（讨论页）/（贡献）}- 2020年11月17日 (二) 23:09 (CST)

这个配色其实就是B站0~9级的等级配色，因为我懒。还有就是这个积分等级参考了MCWiki，起步阶段就是冲冲冲，然后升级速度就会越来越慢。-- Sheep-realms（讨论） 2020年11月17日 (二) 23:25 (CST)

我同意MashKJo的观点，看了一下放在条目页不太和谐，上下不搭。至于等级积分吗，我倒觉得问题不大；但颜色是需要改改，61、59、58、56、53级后面跟着就是40、38级什么的，是应该区分一下--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年11月18日 (三) 13:14 (CST)

可以考虑改进一下{{维基用户信息}}，（效果）- 坑触可 2020年11月18日 (三) 13:22 (CST)

可以在{{PersonInfoBox}}里加入一个Wiki积分等级参数。毕竟爱发电（外站）账号都可以写入模板了，本站的内容不是更应该写进去吗。--QWERTY770 61 讨 贡 2020年11月18日 (三) 17:45 (CST)

啥玩意儿？编辑等级？我试试： --用户:沙漠之鹰xzy/签名（Talk）2020年12月13日 14:37:10 (CST)

(☩)意见：无人提出新的方案，或提出的方案无一通过的话，我建议将讨论串归档。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月14日 (四) 15:34 (CST)

话题已结束

该话题已确认讨论完毕。该讨论串不久之后将会被存档，您依然可以继续在上方添加回复。

——QWERTY_52_38 讨 贡 2021年1月17日 (日) 14:17 (CST)

重要讨论：关于Mod收录

三个问题：

1. “在MCBBS几乎没有知名度且非MCBBS坛友原创的作品禁止收录”。如果两个条件满足一个是否收录？
2. Mod应该收录哪些内容？是全面介绍功能，还是偏向收录相关梗？如果一个Mod内容较多，是全部详细介绍完还是选择仅是列出大概功能，不详细介绍（假设该Mod并没有自己的官方Wiki）？
3. 如果一个Mod把某些论坛用户写进去了，是否允许在对应用户页面写类似“该用户已被XXX模组收录为YYY方块，作用是ZZZ”这种句子？

--QWERTY_52_38 讨 贡 2020年12月1日 (二) 21:37 (CST)

回答：

1. 这是相当于not((not a) and (not b))，等价于 a or b，所以按照这句话推断是可以的。
2. 我个人偏向认为能写多少就写多少。
3. 看模组知名度吧。如果知名度较高那么我觉得可以。

--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月1日 (二) 22:38 (CST)

(：)回应

1. 且，这个只要语文好一点都可以理解吧？= = 只满足其中一个的允许收录，但不支持。
2. 关于这点，没有硬性要求和限制。至于梗，主要只有加速火把有吧？有就写，没有就不写。至于详细介绍还是算了，毕竟MCBBS Wiki不是大杂烩。
   1. 顺便说一下，一个MC MOD的wiki一般都会在Fandom建站，少部分大型MOD（AoA、Aether）才在Gamepedia建站。
3. 可以，方针不禁止则可为。但要注意不要使其显得突兀。

-- MashKJo-{（用户页）/（讨论页）/（贡献）}-61 2020年12月1日 (二) 22:52 (CST)

问题已答复

该问题目前已有答复，但提问者并未回复。若提问者长时间不回复，该讨论串将会被存档，您依然可以继续在上方添加回复。如果您是提问者，请在回复后移除此模板。

——-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月14日 (四) 15:34 (CST)

关于链接“被锁”

最近，我看到一些MCBBS帖子链接被标注了“被锁”二字（如页面燃雪听风#Ta的教程），但我觉得这完全不需要，应该把所有的这类字眼去掉。理由如下：

1. 我们有挖掘卡来查看被锁帖子。
2. 被锁帖子除了用挖掘卡，还有一大堆办法查看（如?action=printable，Discuz archive，百度快照）。
3. （最重要的一点）帖子的状态是会变化的。或许会被锁上，或许会被打开。我们不可能每天都去查看Wiki每一个帖子链接并更新页面。而如果不能及时更新状态，“被锁”二字就几乎没有意义（甚至还有副作用），因此还不如全部删掉。
   1. 同时，Wiki有那么多链接，其中实际被锁的不计其数，但只有一部分加上了“被锁”。与其把其余所有被锁的链接都加上“被锁”，不如把现有的这部分去掉，统一格式。--QWERTY_52_38 讨 贡 2020年12月7日 (一) 20:28 (CST)

(＋)同意，确实没有必要去添加这个标记，要加也得用自动化的方案。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月7日 (一) 23:01 (CST)

(＋)同意不过解锁卡怎么说也是要花金粒的而且如果帖子有分多页的话解锁了也看不到帖子的后几页，给个提示总是好的。建议尽快完善自动化标记模板。---- xiang_xge·讨论/贡献 2020年12月23日 (三) 07:58 (CST)

(☩)实现难度较大 主要有两个实现方向：服务端实现和客户端实现，其中MCBBS Wiki的服务端基本是一组土豆，所以优先考虑客户端实现。

如果是客户端实现，整个流程需要：

1. 遍历页面上所有MCBBS帖子链接，异步获取MCBBS帖子信息

2. 显示在页面上

实现难点：跨域获取的帖子信息会被浏览器直接拦下来，MCBBS会监测流量异常的IP丢入403

如果是服务端实现，整个流程需要：

1. 遍历页面上所有的MCBBS帖子链接，异步获取MCBBS帖子信息

2. 定期更新

实现难点：服务器是个土豆，MCBBS会监测流量异常的IP丢入403，这里好像没有精通PHP（精通到能对MW下手）的人

-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月23日 (三) 13:04 (CST)

(☩)意见解锁帖子真的一定需要金粒吗？？？加上?action=printable就能正常浏览了，几乎不影响。--QWERTY_52_38 讨 贡 2020年12月23日 (三) 19:11 (CST)

提议已采纳

该提议经过讨论已被采纳。该讨论串不久之后将会被存档，您依然可以继续在上方添加回复。

——-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月14日 (四) 15:34 (CST)

泥潭发生了什么

今天去茶馆，提示我“本站已关闭发帖功能”。

全论坛翻了一遍，发现12.13日（今天）只有1个帖子，在mod教程版，还是版主的。

泥潭是又要维护了，还是怎么的？有人知道吗？ --< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月13日 (日) 08:21 (CST)

和今年4月4日那次理由相同。--QWERTY_52_38 讨 贡 2020年12月13日 (日) 08:51 (CST)

刚才突然反应过来了，之前没想起来今天是什么日子。--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月13日 (日) 09:08 (CST)

问题已解决

该问题已由提问者确认解决或公认已解决。该讨论串不久之后将会被存档，您依然可以继续在上方补充答复。

——--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月13日 (日) 09:08 (CST)

防止手贱点到回退按钮

// ------------------
// 防止手贱回退页面
// ------------------
$(function () {
    for (let a of Array.from(document.querySelectorAll('.mw-rollback-link a'))) {
        a.addEventListener('click', function (ev) {
            if (!confirm('确定要回退吗？')) { ev.preventDefault() }
        })
    }
})

由于MediaWiki的JS压缩器只支持“ES2015”中“ES”和“5”的部分，因此即使这段代码能在任一主流浏览器上运行，也只会在你的用户JS页面报错。

请使用mw.loader.load来加载，或者：

eval("$(function(){for(let a of Array.from(document.querySelectorAll('.mw-rollback-link a'))){a.addEventListener('click',function(ev){if(!confirm('确定要回退吗？')){ev.preventDefault()}})}})")

当然，这里我也推荐李代数的方案，不会导致MW的报错，同时也更好看。

// 取自 https://minecraft-zh.gamepedia.com/User:Ff98sha/common.js，仅供学习研究用
mw.loader.using(['oojs-ui-windows', 'oojs-ui-core'],
function() {
  $('.mw-rollback-link a').each(function() {
    var href = $(this).attr('href');
    $(this).click(function(e) {
      e.preventDefault();
      OO.ui.confirm('你确定要回退此页面吗？').done(function(confirmed) {
        if (confirmed) { location.href = href; }
      });
    });
  });
});

思路：阻止锚点的默认动作 -> 用户确认是否继续 -> 执行默认动作/什么都不发生

-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月16日 (三) 16:08 (CST)

(☩)意见：

1. 不是我的方案，只是在mcwiki上看到ff98sha的用户js，拿来试用的。
2. 我认为以上方法是可行的。
3. 前几天我有一个想法，缺点在于可能有些麻烦，有点在于方便自定义，可以考虑一下：
   1. 去除所有锚点
   2. 定义一下确认的代码及UI
   3. 添加锚点并附上上述代码

--< 自由李代数 讨 贡 狗娃安慰噶喔。> 2020年12月16日 (三) 17:56 (CST)

(：)回应，那几个锚点本身没有什么特殊点，所以没有必要劫持，不过自定义UI倒是可以写：

$(function () {
    for (let a of Array.from(document.querySelectorAll('.mw-rollback-link a'))) {
        if (!a.hasAttribute('href')) { continue }
        a.addEventListener('click', (ev) => {
            ev.preventDefault()
            confirmUI('确定要回退此页面吗？', (confirmed) => {
                if (confirmed) { window.location.href = a.href }
            })
        })
    }
    /**
     * 显示一个自定义确认框
     * @param {string} text 
     * @param {(confirmed:boolean)=>void} callback 
     */
    function confirmUI(text = '', callback) {
        // 安全锁，防止用户多次点击
        let safe = true
        // 容器
        let container = document.createElement('div')
        container.className = 'confirmUIcontainer'
        container.innerHTML = `<center>${text}</center>`
        // 确定按钮
        let yesBtn = document.createElement('div')
        yesBtn.className = 'btn'
        yesBtn.style.setProperty('--hover-color', '#FDF6E6')
        yesBtn.textContent = '确定'
        yesBtn.addEventListener('click', () => {
            if (safe) {
                safe = false // 安全锁
                callback(true)
                selfRemove() // 移除确认框
            }
        })
        container.appendChild(yesBtn)
        // 取消按钮
        let noBtn = document.createElement('div')
        noBtn.className = 'btn'
        noBtn.style.setProperty('--hover-color', '#FDF6E6')
        noBtn.textContent = '取消'
        noBtn.addEventListener('click', () => {
            if (safe) {
                safe = false
                callback(false)
                selfRemove()
            }
        })
        container.appendChild(noBtn)
        // 关闭按钮
        let closeBtn = document.createElement('div')
        closeBtn.className = 'close'
        closeBtn.textContent = '×'
        closeBtn.addEventListener('click', () => {
            if (safe) {
                safe = false
                selfRemove()
            }
        })
        container.appendChild(closeBtn)
        // 显示UI
        container.style.opacity = '0'
        container.style.top = '20%'
        container.style.transitionTimingFunction = 'ease-out'
        document.body.appendChild(container)
        // 调整位置
        container.style.marginLeft = (container.offsetWidth * -0.5) + 'px'
        container.style.marginTop = (container.offsetHeight * -0.5) + 'px'
        container.style.transitionDuration = '.3s'
        container.style.opacity = '1'
        container.style.top = '50%'
        setTimeout(() => { container.style.transitionTimingFunction = 'ease-in' }, 400)
        /**移除自己 */
        function selfRemove() {
            container.style.top = '20%'
            container.style.opacity = '0'
            setTimeout(() => { container.remove() }, 400)
        }
    }
    // CSS
    let s = document.createElement('style')
    s.textContent = `
.confirmUIcontainer{
    position: fixed;
    border: 8px solid #0003;
    border-radius: 8px;
    overflow: hidden;
    padding: 0;
    top: 50%;
    left: 50%;
    min-width: 20vw;
    background: #fbf2dc;
    user-select: none;
}
.confirmUIcontainer > center{
    padding: 1.2rem .6rem 1.2rem .6rem;
    font-size: 1.05rem;
}
.confirmUIcontainer .btn{
    width: 50%;
    border: 1px solid #ccc;
    padding: 1rem;
    box-sizing: border-box;
    font-size: 1.15rem;
    line-height: 1.15rem;
    float: left;
    background-color: transparent;
    text-align: center;
    transition: .3s ease;
    cursor: pointer;
}
.confirmUIcontainer .btn:hover{
    background-color: var(--hover-color,transparent);
}
.confirmUIcontainer .close{
    position: absolute;
    width: 2rem;
    height: 2rem;
    top: 0;
    right: 0;
    font-size: 2rem;
    line-height: 2rem;
    text-align: center;
}
    `
    document.head.appendChild(s)
})

-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2020年12月16日 (三) 19:30 (CST)

话题已结束

该话题已确认讨论完毕。该讨论串不久之后将会被存档，您依然可以继续在上方添加回复。

——-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月14日 (四) 15:34 (CST)

關於你們的電郵

請問 [email protected] 是你們用來傳送電郵的電郵地址嗎？假如是的話，我是來告訴你們用這個電郵地址傳送的電郵被過濾了。建議你們不要用 .ml 那些免費域名，並且設定 SPF、DKIM 及 DMARC。——<JasonHK /> 2020年12月22日 (二) 22:55 (CST)

邮件功能目前处于关闭状态。 -- Sheep-realms（讨论） 2020年12月23日 (三) 11:51 (CST)

你們不是用這個電郵地址傳送電郵地址驗證的郵件嗎？——<JasonHK /> 2020年12月23日 (三) 12:34 (CST)

站点配置中邮件功能确实处于关闭状态，而关于邮件服务器实际控制权不在我手中，这个需要等站长上线处理。 -- Sheep-realms（讨论） 2020年12月23日 (三) 13:24 (CST)

已记录。预计本人处理日期 1.2X 请耐心等待回复。若其他管理员已解决问题则不再进行回复。Eicy（讨论） 2021年1月10日 (日) 00:42 (CST)

(：)回应现阶段邮件功能中已关闭的有EnotifWatchlist、EnotifMinorEdits、ShowUpdatedMarker和EnotifWatchlist。（个人: .ml 我用了两年）SPF与DMARC已设置，服务商暂不支持DKIM。--Eicy（讨论） 2021年1月23日 (六) 09:45 (CST)

打算改一改左侧栏了

图片见图床： https://s3.ax1x.com/2021/01/09/sQlVyD.gif （GIF，约2MiB）。

• 左侧栏跟随页面滚动。
• 子栏可以收起。
  • 如果左侧栏比页面要长的话会默认收起。
• 只在PC版启用。

这种改动可以接受吗？-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月9日 (六) 19:39 (CST)

(＋)同意Eicy（讨论） 2021年1月9日 (六) 21:10 (CST)

(＋)同意--Lakejason0（讨论） 2021年1月16日 (六) 14:47 (CST)

(✓)完成。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月24日 (日) 10:24 (CST)

提议已采纳

该提议经过讨论已被采纳。该讨论串不久之后将会被存档，您依然可以继续在上方添加回复。

——-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月24日 (日) 10:24 (CST)

从common.css中剥离书页皮肤

我是这个Wiki的仿MCBBS书页皮肤的作者，Wiki建站时，这个皮肤写在mediawiki:vector.css中，后应绵羊的要求搬到了mediawiki:common.css内。

随着Wiki的发展，mediawiki:common.css中的内容越来越多，开始变得臃肿；而这个书页皮肤最开始是为vector设计的，不兼容monobook和timeless。

从长远角度考虑，为了更方便地维护Wiki，必然要剥离皮肤样式代码和其他功能性样式代码，未雨绸缪，我用SCSS重写了这个Wiki的书页背景。

因此我提议，重写书页皮肤并放进mediawiki:vector.css中，将其从mediawiki:common.css剥离出来。

• 注：如果上一个讨论串通过的话，我将捆绑添加上一个讨论串中的左侧栏样式。

-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月14日 (四) 15:48 (CST)

(＋)同意--Lakejason0（讨论） 2021年1月16日 (六) 14:48 (CST)

(＋)无其他意见--QWERTY_52_38 讨 贡 2021年1月17日 (日) 14:10 (CST)

(＋)同意--Eicy（讨论） 2021年1月20日 (三) 13:22 (CST)

(✓)完成。-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月24日 (日) 10:24 (CST)

(？)疑问 我怎么感觉字体变了啊—0x0A🎉🎄Merry Christmas! 坑触可「^T/_C」 2021年1月24日 (日) 11:44 (CST)

(：)回应确实变了，希望改回去。--洞穴夜莺 2021年1月24日 (日) 12:33 (CST)

而且侧边栏变得鬼畜了--洞穴夜莺 2021年1月24日 (日) 12:34 (CST)

提议已采纳

该提议经过讨论已被采纳。该讨论串不久之后将会被存档，您依然可以继续在上方添加回复。

——-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月24日 (日) 10:24 (CST)

建议保护以下页面

建议保护一下MCBBS_Wiki:免责声明。这么重要的东西不保护一下怎么行。

另外，{{MCBBS Wiki导航}}需要加一下MCBBS_Wiki:免责声明和MCBBS_Wiki:隐私政策两个页面的链接。--QWERTY_52_38 讨 贡 2021年1月17日 (日) 14:17 (CST)

(✓)完成 -- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月17日 (日) 20:31 (CST)

提议已采纳

该提议经过讨论已被采纳。该讨论串不久之后将会被存档，您依然可以继续在上方添加回复。

——-- Salt lovely「非谢家之宝树，接孟氏之芳邻」 2021年1月17日 (日) 20:31 (CST)

修复页面存在语病

修复页面倒数第二段（部分）：

“该功能可能会导致被调转到一楼的回复者并使主题变得更加令人费解。”

其中前半个分句没有谓语，是个病句。由于不了解这句话的本意，也无从推测，故提出讨论，希望了解具体情况的人进行更改。

--自由李代数-bot（讨论） 2021年1月23日 (六) 15:33 (CST)