维基百科

维基百科讨论:格式手册/文字格式/存档二

< Wikipedia talk:格式手冊 | 文字格式
Jimmy-bot在话题“提议修改Wikipedia:格式手册/文字格式，并讨论“确立”条目中粗体的正当用法与使用时机”中的最新留言：1年前

追梦 Do Re Mi这条目的不当上色问题是不是无解啊？

最新留言：在3年前发布6条留言4人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2021年2月1日 (一) 08:14 (UTC)。

刚刚翻阅了关于不当上色的讨论，找到这篇追梦 Do Re Mi，虽然无聊龙大曾将上色删除，但后来ＩＰ用户又将其改回来，还补上Wikipedia:格式手册/文字格式#颜色及内联图像，究竟是这个文字格式写得太糟还是IP用户有问题？ --无心*插柳*柳橙汁 2021年1月18日 (一) 09:49 (UTC)

@Ericliu1912、Milkypine：有没有具体提案？现时大致上的倾向如何？SANMOSA SPQR 2021年1月22日 (五) 06:38 (UTC)

表格标题背景与文字颜色

最新留言：在3年前发布3条留言3人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2021年4月19日 (一) 08:14 (UTC)。

电视剧（韩剧、日剧等）、电影、人物传记等条目内列表标题上色容许范围是否能有个标准？且大量列表上色都未确保文字和背景的对比达到WCAG 2.0的AA等级（如可能则达到AAA等级）

每次修改都遇到“爱上色魔人”都甩一句没有规范或遵循前人写死风格（别跟著闯红灯）而不听劝造成编辑战。

根据颜色及行内图像，“在条目正文及表格之中，禁止手动或使用模板将文字染成某种特殊的颜色，可以接受的情况仅限于资讯框中。这一方面是为了减轻伺服器负担以及方便后来编辑者的维护，另一方面是为了方便色盲、色弱或使用黑白版本的读者阅读文字。只有在背景颜色可帮助阐释条目内容，且没有其他更佳的表达方式时，才可对表格或其他的内文元素加入背景颜色。”但仍需遵守少用颜色来表达。--～立ち直り中ಇ 2021年4月5日 (一) 12:39 (UTC)

一直都赞成条目内表格禁止上色，模板颜色再议吧。🌟🌟Talk 2021年4月11日 (日) 05:20 (UTC)

模板颜色相关规范

最新留言：在3年前发布86条留言23人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2021年6月6日 (日) 08:14 (UTC)。

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行人：SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 08:57 (UTC)。

想问一下关于模板的相关规范：现在的模板并没有任何关于颜色的规范。我个人希望模板的颜色本身不应被任何其他的配色所取代（模板不应被着色），尤其是没有达成任何Accessability相关要求的共识前，均不应当修改任何着色，否则将会可能影响读者正常阅读模板。--1233 （T / C） 2021年3月22日 (一) 13:19 (UTC)

可参见WCAG 2.1 AA。--痛心疾首 2021年3月22日 (一) 13:34 (UTC)
Wikipedia:格式手册/文字格式#颜色及内联图像算不算？SANMOSA 江南好，风景旧曾谙 2021年3月22日 (一) 13:52 (UTC)
导航模板不算正文（逻辑上）。就是此前处理了一个WCAG 2.1有问题的模板我才开启讨论。1233 （T / C） 2021年3月23日 (二) 03:51 (UTC)
Wikipedia:格式手册/文字格式#颜色及内联图像的确无法处理导航模板。 --无心*插柳*柳橙汁 2021年3月24日 (三) 03:31 (UTC)
@1233、Milkypine：可以扩大Wikipedia:格式手册/文字格式#颜色及内联图像的适用范围。SANMOSA 江南好，风景旧曾谙 2021年3月25日 (四) 04:40 (UTC)
完全支持扩大适用范围。 --无心*插柳*柳橙汁 2021年3月25日 (四) 05:13 (UTC)
可解决问题，故支持。唯此格式手册的修订将会影响大量的模板，故需要更深入的讨论。--1233 （T / C） 2021年3月25日 (四) 15:23 (UTC)
@痛心疾首、Milkypine、1233：已移动讨论至方针区。SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 09:01 (UTC)
拟修改如下：
现行条文

颜色及内联图像

关于图像的规定为Wikipedia:格式手册/图像的覆盖范围，应及时建立并移动过去。

在条目正文及表格之中，禁止手动或使用模板将文字染成某种特殊的颜色，可以接受的情况仅限于信息框中。这一方面是为了减轻服务器负担以及方便后来编辑者的维护，另一方面是为了方便色盲、色弱或使用黑白版本的读者阅读文字。[1]

只有在背景颜色可帮助阐释条目内容，且没有其他更佳的表达方式时，才可对表格或其他的内文元素加入背景颜色。为了照顾视障或色觉障碍读者的需要，请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述。为了保障条目的可读性，请避免使用饱和度过高，或与文字对比度不足的颜色作为表格的背景色。禁止使用CSS代码对表格背景加入花俏的样式（如渐层色等）。

类似地，条目正文中，禁止使用内联图像（例如在文字中出现 这样的图像），但若在表格及信息框中使用则是可以接受的。

提议条文

颜色及内联图像

关于图像的规定为Wikipedia:格式手册/图像的覆盖范围，应及时建立并移动过去。

条目正文、表格及各类模板（包括信息框）中禁止手动或使用（其他）模板将文字及背景颜色染成非预设颜色。此举乃是为减轻服务器负担并方便后来编辑者的维护，亦是为方便色盲、色弱或使用黑白版本的读者阅读文字。[1]

只有在背景颜色可帮助阐释条目内容，且没有其他更佳的表达方式时，才可对表格或其他的内文元素加入背景颜色。为了照顾视障或色觉障碍读者的需要，请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述。为了保障条目的可读性，请避免使用饱和度过高，或与文字对比度不足的颜色作为表格的背景色。禁止使用CSS代码对表格背景加入花俏的样式（如渐层色等）。

同理，条目正文中亦禁止使用内联图像（例如在文字中出现 这样的图像），但在表格及信息框中使用内联图像则可接受。

以上。SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 23:40 (UTC)

似乎应该是不在条目里用带特殊颜色的模板，而不是规定模板不得带颜色。所以建议“条目正文、表格及各类模板”→“条目正文、表格及条目中使用的各类模板”。--DrizzleD (按此给我留言) 2021年3月28日 (日) 08:04 (UTC)
@DrizzleD：然而这里最原始的提议就是禁止所有模板著色（如果我没理解错的话），@1233。SANMOSA ······ 2021年3月28日 (日) 23:48 (UTC)
@DrizzleD、Sanmosa：我的概念是应当建立相关Accessibility的指引（例如对规范模板中文字和背景色的对比度）。而又当此等指引未达成共识前，则不应对模板著色。--1233 （T / C） 2021年3月29日 (一) 02:39 (UTC)
禁止所有模板着色恐怕不现实。且不提{{支持}}这种模板或者就在本句话中使用的{{tq}}，单是为数众多的多彩用户框就不可能处理过来啊。--DrizzleD (按此给我留言) 2021年3月29日 (一) 14:48 (UTC)
如果我没理解错误的话，是不是Infobox系列模板都不能自订文字和背景的颜色？ 2021年3月29日 (一) 04:28 (UTC)
是的（如果我没理解错1233的意思的话）。SANMOSA ······ 2021年3月29日 (一) 05:31 (UTC)
就Accessability这个理由，完全支持禁止对模板、表格等上色。🌟🌟Talk 2021年3月29日 (一) 04:53 (UTC)
(－)反对：信息框内的文字在某些情况下应允许使用不同的颜色，否则将无法很好地表意；导航模板同理，例如{{柑橘属}}和{{地质年代}}模板使用了不同的底色，但也只是起到辅助区分相关信息的作用，并不影响色盲色弱等特殊群体阅览，取消这些底色后，非但不能照顾到少部分特殊群体（因为在色盲色弱看来，无论普通模板还是上色模板基本都是一片灰，并无本质上的区别），并且对于绝大部分正常读者而言将是一大损失。让绝大部分正常群体去迁就少部分特殊群体，属于西方式政治正确（就好比硬说黑人和白人一样聪明），英维的做法不可取。--萧漫（留言） 2021年3月29日 (一) 12:51 (UTC)
同意需要有指引规范相关模板的著色。另外我处理的部分模板出现严重的"撞色"问题，才要求模板应暂时停止著色。这不是西方不西方的问题，而是此等问题已经燃烧至影响正常的阅读体验了。--1233 （T / C） 2021年3月29日 (一) 13:30 (UTC)
西不西方我是不清楚，但肯定是眼残级别追梦 Do Re Mi。尤其是像Template:Weki_Meki，这边上色的意义何在？ --Loving You Is A Losing Game 2021年3月29日 (一) 15:21 (UTC)
不同意柑橘属跟地质年代这两个举例，柑橘属的颜色仅仅是阶层式架构，以排版就足以区分，不需要再加上颜色；至于地质年代的颜色更是没有意义，部分底色与文字颜色对比度不高，对正常人来说也是难以阅读。--Xiplus#Talk 2021年4月3日 (六) 06:01 (UTC)
@Xiplus：像这三个案例{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}呢，有本事你对Geological_range和古近纪图形时间线的英维版禁止着色啊。反对一刀切致使中维倒退的方针。你少代表正常人对地质年代发表看法，也只是对你来说难以阅读而已。U:Lab06 N 参与微软专题 2021年4月3日 (六) 12:46 (UTC)
(－)强烈反对：对地质和生物学相关等特殊模板有严重影响！1.减轻服务器负担这个理由就经不起推敲，难道现在的服务器机能还不如以前的服务器？2.另外照顾色盲色弱群体这个理由已经有人反驳了。U:Lab06 N 参与微软专题 2021年3月30日 (二) 13:57 (UTC)
那完全不是合理的反驳理由。“因为在色盲色弱看来，无论普通模板还是上色模板基本都是一片灰，并无本质上的区别”是错的，普通模板的话全色盲至少还能分得到浅色和深色（白色和黑色），上色模板全色盲就完全分不到了。全色盲还是能分辨白色和黑色的，他们只是cone cell不能function而已，rod cell还是能function的。SANMOSA Σουέζ 2021年3月31日 (三) 07:53 (UTC)
既然已经了解提案禁止对Infobox等模板上色，那么我(－)反对此提案，毕竟有些Infobox模板的颜色对辨别条目类型有很大的帮助，不能因为视觉障碍人士而选择单一的格式，不过如果是限制背景颜色和文字颜色之间的对比度，这我能够接受。 2021年4月1日 (四) 14:20 (UTC)
仔细想了想，倾向不赞同：
  1. （主要）现行方针能够确保色盲（弱）人士能够获取充分信息，根据现行方针要旨，只需避免“单独地使用背景颜色来表达某一含义”，同时避免“饱和度过高，或与文字对比度不足”，上述举措——
    • 确保了色盲（弱）人士能够不依赖颜色获取足够信息，确保所有人阅读的文字是清晰的；
    • 在此基础上，不对辅助性背景填色进行“一刀切”，能保障更多色觉正常的人士能借背景色获得获取信息上的便利。
  2. （次要）变更宜乎审慎行事，仅高速公路一类就有逾千条条目和大量模板受到影响，即便上述修改要实施，修正案也未能列出批量变动的页面范围和变动的具体方案。
以上。--Kirk # 2021年4月1日 (四) 14:33 (UTC)
个人认为对现行模板应当是采取没坏别修的态度：应当先行禁止新（类型）的模板著色，再讨论如何界定为“可行”且为辅助性的背景著色，再解决“应当在何时著色”和“怎样才是可行的著色”的两个问题--1233 （T / C） 2021年4月3日 (六) 02:41 (UTC)
  • (－)反对，限制面太广，用户框、导航模板等都会受影响。可行的着色可以按常识判断。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月3日 (六) 04:56 (UTC)
  • 拆分投票：
  • 支持要求条目用导航模板使用预设配色。使用其他颜色可以，但应该给出理由；而且这个理由是领域内讨论出的统一的配色方案。像Template:Citrus为什么要上成黄色而不是其他颜色？是属级导航框的统一用黄色，纲级导航框又用另一种颜色；还是觉得这个颜色是柑橘的主题色（那孔雀呢）；还是编辑没理由随便上的颜色？而且导航模板和信息框还不一样：条目可以放多个导航模板，随意上色的结果就是花花绿绿，不同颜色搭配起来很不美观。如果其他导航框用默认颜色，比较次要的那个导航模板又私自上色，那它会不会有抢镜头的嫌疑？总之，导航模板上色需要极其保守，找不到必须上色的理由就别上。--洛普利宁 2021年4月3日 (六) 16:13 (UTC)
  • 支持楼上所述，另参考各语言维基百科也对上色趋于保守或严格规范。即便不全面禁止也需有个合理的规范，哪些领域的确有这需求，哪些领域又该严格禁止或者限定。不该完全置之不理任由问题累积未来才以影响范围大而放弃讨论制定规范。～立ち直り中ಇ 2021年4月5日 (一) 12:47 (UTC)
  • 上色这种东西如果能够靠自由心证或常识解决，那就不会有像追梦 Do Re Mi这样的上色乱象。的确我不是地理条目相关编辑，但前面提到的{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}请问有哪个一定需要颜色？或者说这些颜色必须一定要有的理由为何？（当然也可以直接开民调调查有颜色大家会不会比较ＯＫ）。如果这些颜色有一定的存在理由，那就针对这点做改善（例如常用习惯等）。 --Loving You Is A Losing Game 2021年4月5日 (一) 13:11 (UTC)
意见颇为分歧，我建议就此进行投票，不知各位意下如何。SANMOSA Σουέζ 2021年4月10日 (六) 06:39 (UTC)
这不是投票就能解决的问题，一来是不能只因为视觉障碍人士而选择单一的样式，再者是影响范围过大，投票并不能体现所有使用者的意见（匿名使用者不能投票，请留意维基百科并非专给注册使用者阅读）。如果您要发起民调，我没意见，但是我反对发起投票。 2021年4月10日 (六) 07:05 (UTC)
然而现时的状况确实对视障人士构成严重的歧视，我认为所有人现在最基本要知道的就是现时模板的着色情形已经严重影响到视障人士的阅读体验。投票的选项亦非只有两种（至少我初步的计划如是）。在陷入复杂讨论的泥潭时，投票显然是一种快速收集意见以凝聚共识的方法，不能单纯因为“影响范围过大”和“不能体现所有使用者的意见”而反对发起投票和变相剥削视障人士的合理阅读体验。SANMOSA Σουέζ 2021年4月11日 (日) 14:26 (UTC)
@Sanmosa：“影响范围过大”和“不能体现所有使用者的意见”已经不是您所指的单纯问题了。您发起民调来搜集意见我没意见，但是要将投票结果作为共识执行，我不能接受。当然您要发起与否是您的自由，如果社群能够接受结果，那我也没话说，只是还请留意，我不能接受投票不代表我反对投票，也不代表我变相剥夺视觉障碍人士的合理阅读体验，这只是表达我的个人意见，而我的意见是对于此种议题，应该有比投票更能体现共识的方式。 2021年4月12日 (一) 02:31 (UTC)
发起投票的最主要目的是在讨论各方意见很大程度上分歧时确立讨论的大方向，如果连大方向都不能确立，我难以相信讨论能有效持续。SANMOSA Σουέζ 2021年4月14日 (三) 13:19 (UTC)
@Sanmosa：确立讨论的方向，请使用民调而非投票。 2021年4月14日 (三) 18:01 (UTC)

变通提案

以下是小弟的变通提案：

现行条文

颜色及内联图像

关于图像的规定为Wikipedia:格式手册/图像的覆盖范围，应及时建立并移动过去。

条目正文、表格及各类模板（包括信息框）中禁止手动或使用（其他）模板将文字及背景颜色染成非预设颜色。此举乃是为减轻服务器负担并方便后来编辑者的维护，亦是为方便色盲、色弱或使用黑白版本的读者阅读文字。[1]

只有在背景颜色可帮助阐释条目内容，且没有其他更佳的表达方式时，才可对表格或其他的内文元素加入背景颜色。为了照顾视障或色觉障碍读者的需要，请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述。为了保障条目的可读性，请避免使用饱和度过高，或与文字对比度不足的颜色作为表格的背景色。禁止使用CSS代码对表格背景加入花俏的样式（如渐层色等）。

同理，条目正文中亦禁止使用内联图像（例如在文字中出现 这样的图像），但在表格及信息框中使用内联图像则可接受。

提议条文

颜色及内联图像

关于图像的规定为Wikipedia:格式手册/图像的覆盖范围，应及时建立并移动过去。

条目正文、表格及各类模板（包括信息框）中，使用原始码或其他模板将文字或背景颜色染成非预设颜色，应以帮助阐释条目内容为第一目的。同时，编者也需要考虑色盲、色弱或使用黑白版本的读者的实际需求。[1]

除非编者有正当理由，并且能在讨论页自证有理，否则：

  • 同一表格、导航模板或信息框模板只能使用一种边界色、一种标题栏背景色、一种标题栏文字色，且总共不能超过三种颜色；
  • 请避免单独地使用背景颜色来表达某一含义，而应适当地同时以文字方式表述；
  • 边界色、标题背景色、标题文字色之间应该有可视的对比度；
  • 内容背景色和内容文字色之间也应该有可视的对比度；
  • 表格/模板边界色和内容背景色两者的饱和度不能太高；
  • 禁止手动将表格或模板的内容文字染成其他颜色。
  • 禁止使用CSS代码对表格/模板的任何部份加入花俏的样式（如渐层色等）。

为避免编辑争议，建议编者在编辑的同时，即在编辑摘要或讨论页中说明上色的理由。

同理，禁止在正文中使用内联图像（例如在文字中出现 这样的图像）、什锦字型或绘文字，但符合以下条件图像则不在此限：

  • 与正文内容密切相关，不使用就无法（或很难）准确阐释条目内容；
  • 编者有理由相信电脑无法正常解码和显示；
  • （非强制）有对应Unicode代码的天然语言字符或专业符号，或者符合知名度要求的人造语言的字符，或者以LaTeX制作的科学表述。

此外，在表格及信息框中也可以使用内联图像。

  • “一种颜色”的定义为一个RGB值。例：#FFFFFF和#FFFFFE视为两种颜色。
  • “饱和度不能太高”定义为红绿蓝三原色中，任何一种原色数值低于EE。

小弟主要编辑体育相关条目，因此在这里用个和体育相关的例子：编者在编辑某足球队的球员名单（表格）时使用的标题背景/文字颜色组合，如果和该足球队队徽或主场队服的配色相同，即视为能够“帮助阐释条目内容”。反之，如果编者用的是另一支球队的队徽或主场队服的配色，则视为无助于阐释条目内容，要么重新上色，要么改用预设颜色。举例说明：加拿大国足的主场球衣（守门员除外）的主色调为红色（#FF0000或更深），球衣字体为白色，而且红色和白色之间的差距足够大，因此加拿大国足的导航模板的标题可以染成红色背景、白色文字。美国国足的主场球衣的主色调为蓝色，因此如果把加拿大国足的导航模板的标题染成蓝色背景、白色文字，则视为无助于阐释条目内容。

以上。📕📙📒📗📘📚📖 2021年4月11日 (日) 03:13 (UTC)

暂时认为阁下的提案影响太多：各类模板应限制至条目导航及各类infobox。另建议禁止任何WCAG 2.0中两种低于2.0的配色分别用于背景及正文。--1233 （T / C） 2021年4月14日 (三) 02:33 (UTC)
1233已修订为“同一表格、导航模板或信息框模板只能使用一种边界色、一种标题栏背景色、一种标题栏文字色，且总共不能超过三种颜色”。另外，能否解释一下怎样才算“WCAG 2.0中两种低于2.0的配色”？📕📙📒📗📘📚📖 2021年4月14日 (三) 21:37 (UTC)
  • (－)反对只能使用三种颜色。Template:元素周期表会无法呈现，更不用说缩图型导航的Template:NavPeriodicTable，此举同时也导致了之前色弱友善元素周期表颜色配置Template talk:Isotope nav#同位素模板颜色更换全部白讨论了，浪费了社群资源。 考量到需要区分元素本身特性，以下主题有许多层级需要区分
    1. 元素周期表（Template:元素周期表、Template:NavPeriodicTable）
    2. 元素稳定性表（Template talk:Isotope nav）
      • 大量稳定同位素、仅一种稳定同位素、仅有观测上稳定同位素、最稳定同位素半衰期万年、半衰期千年、半衰期1年或以下、半衰期以日计、半衰期以时计、半衰期以秒计、目前未发现同位素（如Uue） 等至少10种等级
    3. 元素分区（Template:元素周期表_(正文)#范例）
    要区分5种以上等级，禁用颜色根本强人所难，无法实行，或实行会导致元素周期表等相关条目无法准确制作示意图表。-- 五岁抬头雪菲（☎️·☘️） 2021年4月14日 (三) 19:05 (UTC)—- 五岁抬头雪菲（☎️·☘️） 2021年4月15日 (四) 02:24 (UTC)
    同时也反对禁用内连图像。{{缺字}}、或Unicode未收录符号、特殊的语言（如克林贡语）和特殊数学符号（如en:Coxeter–Dynkin_diagram、{{CDD}}），全是内连图像，禁用的话，全部都难以或无法描述条目了。特别是en:Coxeter–Dynkin_diagram，根本不可能用文字描述代表一个en:Coxeter–Dynkin_diagram，要求只能放在图表将导致内文难以描述，必须在内文呈现符号再加以说明，这个如果禁的话，那我认为数学公式也该禁。仍然坚持，特殊数学符号是有必要跟文字一起使用的。-- 五岁抬头雪菲（☎️·☘️） 2021年4月15日 (四) 02:24 (UTC)
    A2569875请阁下留意：
    例1：小弟已经特地指定了一个“有正当理由，并且能在讨论页自证有理”的例外条件。阁下以上提到的元素周期表导航模板都属于“正当理由”，因此不受“最多三种颜色”的限制。
    例2：小弟也指定了例外条件。阁下提及的人造语言字母和数学符号都符合例外的条件，因此不受“禁用内连图像”的限制。至于Unicode未收录的符号当中哪些应该禁止，哪些应该允许，都可以慢慢讨论。能不能请阁下举例说明：哪些符号Unicode尚未收录，却又在某些条目中非用不可？📕📙📒📗📘📚📖 2021年4月15日 (四) 02:51 (UTC)
    • 关于Unicode尚未收录符号，需要与文字一同描述的就是特殊数学符号（如上方{{CDD}}）、化学符号、其他科学表示符号，而所有{{缺字}}、特殊语言也是Unicode尚未收录符号；Unicode尚未收录的Emoji确实不必在条目正文中出现（甚至已收录之Emoji都不该）
    • “编者有理由相信电脑无法正常解码和显示”不明确，可能会导致编辑战，例如某个字原先未被已Unicode收录，因此使用内连图像，后来某天被Unicode收录，然而刚收录时未被广泛的字体支援，也许在电脑上看可以正常显示，然而在iPhone上看都成了豆腐块，因此使用iPhone的用户将看起来像豆腐块的文字回退成内连图像，而电脑版用户又将内连图像回退成在iPhone上看都成了豆腐块的文字，因而导致编辑战。例如前阵子刚发命名的几个化学元素之中文字，在Unicode刚收录鿫、鿬等字时，发生被改来改去的现象。
    • CFOP#下两层（F2L）中“设法在不破坏其他已完成部分，将一柱转成 或 。”不使用内连图像怎么描述？“设法在不破坏其他已完成部分，将一柱转成‘清楚辨识到可见之两个面的中心块与下方块是相同的颜色，同时，左侧最右上方式底面的颜色、上方为左侧面的颜色、右方与该面之中心块同色且角块右边的边块颜色与左方的角块同色且方向相同’或‘清楚辨识到可减两个面的中心块与下方块是相同的颜色，同时，左侧最右上方式做侧面中心块的颜色、上方为右侧面的颜色、右方与底面同色且不可见之面之右侧面之角块的顶部颜色与可见面之左侧面之中心块同色’。”这样的可怕的文字来描述吗；
    • 那么这种又要怎么办“当方块变为
      时”（{{模板样式色块图}}）→“当方块变为‘方块下两层已完成，且顶面颜色在顶面上呈 (不用图片无法表达)形状时，顶面靠近自己本身的地方是不可见面右侧面之中心块颜色，顶面右侧前方（靠近不可见面）两块与可见之左侧侧面同色、顶面左侧两块与可见之右侧侧面同色....’时”。(－)反对到时许多条目，不限于魔术方块都要用可怕的东西描述，WP:太长不看，编者不会想看到一堆废话，条目失去功能。
      关于上述提到的 ，类似的例子例如俄罗斯方块，你描述 ，文字描述用L型，可是他仍有非常多种变体
       
      不使用内连图像，怎么准确表达？
    • Unicode亦有无助于文字表达的字元，用起来跟 这样的图像没有两样，例如Unicode字符列表#特殊、Unicode几何图形列表、方块元素、麻将字元、扑克牌字元（见章节扑克牌#历史）...等
    • 关于颜色，有的Unicode字元还会自带颜色，例如Emoji。
    • Unicode字符列表#盲文图案：点字该不该禁？“未收录点字”
    ※其他关于颜色或Unicode事项待补；会在找到时补充。
    以上-- 五岁抬头雪菲（☎️·☘️） 2021年4月15日 (四) 04:17 (UTC)
(▲)同上。 2021年4月15日 (四) 11:27 (UTC)
魔方问题可以像英语维基百科那样用右侧图像，或者像论文那样<gallery />加“如图1”。一图胜千言，但没看出图像非要内联的理由。而且 、 、
这三个内连例子真心一点都不大方，图片小小、看着眼晕；图片优势没发挥出来不说，还搞到正文稀稀拉拉的。至于Unicode字符列表这种，特殊字符独占单元格的环境，我认为不算内连。--洛普利宁 2021年4月15日 (四) 17:50 (UTC)
魔术方块可能不是个很好的例子，那么我换个例子基础折法、索马立方（en:Soma_cube），这也难以纯粹文字描述。-- 五岁抬头雪菲（☎️·☘️） 2021年4月15日 (四) 21:40 (UTC)
同意Lopullinen的看法。不一定要用内联图像，可以用右侧图像或者图片库。例如《索马立方》可以改用如下的图片库：
《索马立方》图片库
  •  
    第一片，或称为V。
  •  
    第二片，或称为L：三个立方体排成一列，左下方加一个立方体。
  •  
    第三片，或称为T：三个立方体排成一列，中间下方加一个立方体。
  •  
    第四片，或称为Z：二个立方体排成一列，上面是另外二个立方体，往右排一格。
  •  
    第五片，或称为A：V型的三立方体平放，另一个立方体放在顺时针的第一个立方体上方，有立体的不对称性。
  •  
    第六片，或称为B：V型的三立方体平放，另一个立方体放在逆时针的第一个立方体上方，有立体不对称性。
  •  
    第七片，或称为P：V型的三立方体平放，另一个立方体放在转折的立方体上方的第一个，有立体对称性。
这样就既不需要使用内联图像，也不需要单纯依赖文字描述。📕📙📒📗📘📚📖 2021年4月15日 (四) 22:14 (UTC)
(将会陆续补充)
以上-- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 05:23 (UTC)
(～)补充另外，关于“
”的描述，我认为应该要这样“方块下两层已完成，且顶面颜色在顶面上呈 形状时....”不然图像还要引用旁边另外图像，真的很诡异。-- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 05:40 (UTC)

“设法在不破坏其他已完成部分，将一柱转成以下两种形式之一（图1.1和图1.2）：”

   
图1.1 图1.2
  • 这样一来，魔方的图案想再放大些都不怕影响排版。
  • 折纸的案例和索马立方的案例一样，可以制作表格或图片库，不需使用内联图像。
  • 天文学符号完全可以在表格或者Infobox里面用，不需用作内联图像。
  • 中华民国国语那个注音符号，以及那个阿拉伯乐谱符号，都已经符合“与正文内容密切相关，不使用就无法准确阐释条目内容”的例外条件。
  • 至于PlayStation和滨崎步的案例简直就是边缘得不能再边缘了。PlayStation的那句营销口号，完全可以上传一张自制图片来表示，反正像    这种简单的几何符号，是怎么都达不到原创性门槛的。滨崎步的案例已经涉嫌过量使用非自由图像，违反《WP:NFCC#3》了。
另：@Lopullinen、1233：小弟新增了无正当理由禁止使用什锦字型或绘文字的条文，请回应。📕📙📒📗📘📚📖 2021年4月16日 (五) 06:19 (UTC)
  • (：)回应我认为索马立方、折纸与正文密切相关。天文符号其他例子例如电路符号、化学特殊符号、化学结构式（有苯环的）生物学符号，我不建议在旁边放成表格，一堆一个小符号整理成表格非常诡异。以及“
    ：顶面颜色在顶面上呈 形状”的 亦与正文密切相关。同时，整个连纯文字也包成图片放旁边表格将会有“无法复制其中文字”的缺点。-- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 06:27 (UTC)
  • 小整理一下，以便针对点讨论
    • 已解决的问题
      • 自身有独特排版，且为学术界惯例，又需要颜色表达之表格
      • 无法使用现有文字代替的符号（打不出来的字，或者非自然语言表达范畴之记号）
        • 未收录汉字（如{{缺字}}）
        • 数学符号（如{{CDD}}）
        • 乐谱记号
        • 特殊的语言
    • 未解决问题
      • 可以用排版代替颜色的表
        • 地质年代表的背景色。
        • 生物保育状态的背景色。
      • 可以使用现有文字代替的符号
        • 天文符号
        • 化学结构式
      • 具表意功能图示使用时机
        • 如折纸图示
        • 文字不易描述的琐碎形状图示(一句话出现多种时，使用表格反而杂乱)
        • Emoji、绘文字
        • 什锦符号
      • 特殊标语口号
        • “LIVE IN Y UR W RLD. PL Y IN  URS”（整个做成图片将会导致文字复制困难）
        • LaTeX
    以上-- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 07:06 (UTC)
在我看来明文限制使用颜色或内文图片会造成很多麻烦，更不应该直接限制着色，应当按照情况逐例处理；例如在有用户提出更好减少使用颜色的情况下，若内容不造成明显阅读困难就应尽量以颜色较少的方式处理（即指排版妥当；不应以“比较那个比较方便阅读”为准则，只要整体不造成阅读困难即可）。列表条目中适当使用颜色协助用户进行分类，限制用色比限制着色更实际。--LuciferianThomas．留言 2021年4月16日 (五) 09:41 (UTC)
  • “地质年代表的背景色”和“生物保育状态的背景色”我在上面已经说过符合例外条件，因此不属于“未解决问题”。严格来说，俄罗斯方块的图像也属于“与正文内容密切相关，不使用就无法准确阐释条目内容”，只是编者有责任证明非使用内联图像不可。
  • 我加入了或者以LaTeX制作的科学表述，以包括数学公式和化学方程式等。
  • 我粗略阅读了《烃》、《苯》等化学条目，里面的图像都不算“内联图像”。“内联图像”是指插入段落之内，文字之间的图像。但这些条目当中的图像都是用在段落之间，而非段落之内，因此不符合“内联图像”的定义。
  • 天文符号可以在表格或Infobox里使用，不需使用内联图像。
  • “LIVE IN Y UR W RLD. PL Y IN  URS”这种标语是不是非加入不可？“导致文字复制困难”似乎暗示阁下打算复制粘贴到其他条目，但除了PS条目本身以外，还有哪些条目非有这条标语不可？
  • @LuciferianThomas：限制著色是为了防止出现像某个IP对《追梦 Do Re Mi》疯狂著色的情况再次出现。而我提出“一种边界色、一种标题栏背景色、一种标题栏文字色，除非能自证有理”是为了方便执行，尽可能压制游戏维基规则的空间。另外，我在上面的提案也有限制用色的条文：“背景色饱和度不能太高”。
欢迎回应。A2569875、1233、Lopullinen、Pseudo Classes、Sanmosa、萧漫、Lab06 N和羊羊32521📕📙📒📗📘📚📖 2021年4月16日 (五) 15:29 (UTC)
  • 关于复制，我指的是会困扰读者，读者将无法或难以复制该文字。维基百科不应搞得像那种让读者复制不了东西的神秘部落格，且读者理应要能够方便地复制“LIVE IN Y UR W RLD. PL Y IN  URS”以便到其他地方利用或查询其他相关资料，整个包成图像你是要读者去研究影像辨识和机器视觉？？；另外“有对应Unicode代码”en:Coxeter–Dynkin_diagram、{{CDD}}没有对应unicode 代码，LaTeX也不支援，且由于其抽象性，难以用文字说明代替。另外 我相信应该还有一些数学公式或符号不被unicode与LaTeX支援，但是需要与文字一同描述。—- 五岁抬头雪菲（☎️·☘️） 2021年4月16日 (五) 15:39 (UTC)
总归一句话，复杂的限制只会更容易被忽略，再加上你遇到例外就加上去、加上去，最后限制越来越多。至少我没有这么有耐性看完这些限制，就算看完也好，我也不能确保我不会被混淆。你提议修正条文，就有必要将条文修到完整、易读的状态，除非你让这些条文更加简洁，否则我(－)反对的立场不会改变。 2021年4月16日 (五) 16:43 (UTC)
不限制著色，但渐层应明文禁制；另觉得表格什么的不是不能上色，但必须整个条目一致就是了。--LuciferianThomas．留言 2021年4月16日 (五) 18:07 (UTC)
我认为维基百科不应搞得花花绿绿的像粉丝部落格。如果“LIVE IN Y UR W RLD. PL Y IN  URS”包装成图像读者能理解，那就不应该使用内连图像；再说这东西复制出来居然是“LIVE IN YOUR WORLD. PLAY IN OURS”，圈叉三角呢，打哑谜？况且stylized包括大小写、颜色、文字大小等等元素，其主要作用也是视觉冲击，所以本来就更适合用图片表示（再用图注说明，其中四个字母置换成为PlayStation的圈、叉、正方、三角标志）。总之简单一句话：图像可以用，但不要放在正文；如果想放在正文，请想想能不能单独提出来：如果提不出来，再想想所谓的“不用图片不行”整句话是否举例过细，对维基百科这种通用百科并无必要；如果真的很重要，业界也常常这样用，那再讨论要不要内连。科学类条目可以制定自己的格式手册，决定哪些图片可以在兼顾排版的情况下，视同文字在正文中使用。但对于大多数条目，要让编者（特别是新编者）从大方向感觉到，维基百科不鼓励使用内连图像。同时也要鼓励编者锻炼文字表达能力：编者作为爱好者可能以为图片很直观，但非圈内读者很可能根本get不到点。（
这个例子要是不配文字，花花绿绿的我还真不知道想表达最下面两层已完成。）--洛普利宁 2021年4月16日 (五) 18:34 (UTC)
颜色和附图塞内文概念上是一样的，上面列的都是附图案例，颜色例如：
在我看来，许多状况，有加附图或颜色，比起没加附图或颜色，“更有助于帮助读者了解主题”。反而没有上面说的那么严重。-- 五岁抬头雪菲（☎️·☘️） 2021年4月17日 (六) 07:51 (UTC)
@A2569875：您说的这篇条目，正好证明内文颜色不必要乃至多余。您举例的下一段就附了个参考文献；此文献是“8+ (green), 12+ (blue), and 16+ (yellow)”这样用纯文字描述的，而显然编者正确理解了文字（先不讨论绿色用#5CB531是不是原创研究）。由此可见，使用纯文字也能起到等价的效果。另一方面，禁止内连颜色不是禁止使用颜色；正确的方法是这样，用侧边图像大大方方地表示。所以我没看出来，直接给文字上色什么时候成了唯一手段。在我看来，图片放到侧边并配上图注详述、正文做一些大方向上的解释，比起使用不知所以的内联图像或颜色，更有助于读者理解主题。PS：感谢提醒，我把这条目正文中的颜色全部移除了（最上面那个是表格的图示，不属于内连的范畴；下面全都在东施效颦）。--洛普利宁 2021年4月17日 (六) 17:42 (UTC)

其他概念

我单纯希望处理的问题只是背景颜色问题，我认为应当限制每表格的每一格应只使用一种背景色，文字颜色及边框颜色。与此同时，就应当尝试制定背景颜色及文字颜色的对比度。--1233 （T / C） 2021年5月10日 (一) 16:36 (UTC)
我觉得从上面的讨论看起来，整个提案就是一个未经深思熟虑且一厢情愿的提案。如果一个提案提出来会需要列出一大串例外，那不如不要提。不如先把一些乱七八糟的Infobox先整合一下再说。----Koala0090（留言） 2021年5月22日 (六) 00:52 (UTC)
当提案使规则变得复杂而难以使编者明白并遵守的时候，那设来干嘛。—〚 玮玮 · 嘎嘎 · 鲸鱼 〛 2021年5月29日 (六) 03:11 (UTC)

粗体应用问题

最新留言：在1年前发布4条留言4人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/求助。执行者：Jimmy-bot（留言） 2022年11月23日 (三) 00:14 (UTC)。

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行人：Eric Liu 創造は生命（留言・留名・学生会） 2022年11月12日 (六) 22:23 (UTC)。

请问在条列事物时，使用粗体是被允许的吗？例如：苏利文兄弟、射雕英雄传#主要人物、组织#基本概念--Picture GN（留言） 2022年11月5日 (六) 10:40 (UTC)

  1. 关于条目中如何添加粗体，请浏览MOS:B。
  2. 此页面只可讨论维基百科政策与方针。下次若欲求助，请至WP:VPA，祝好。
--绍💓煦集思广益 2022年11月5日 (六) 12:58 (UTC)

MOS:B与体育赛事签表处理

最新留言：在1年前发布24条留言8人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2023年7月28日 (五) 16:14 (UTC)。

就个人所知，体育赛事类条目在签表中皆以粗体标示晋级、晋级者得分等栏位，但此做法不符MOS:B，却已在体育赛事类条目应该行之有年，若要照标准实施会引起编辑冲突，例如2023年美国羽毛球公开赛。在此发起讨论，望社群确定如何在赛事类条目实施MOS:B以利该领域编辑者遵行。--Terry850324（留言） 2023年7月15日 (六) 16:47 (UTC)

我的理解是在非列表条目中表格一般不会当成条目正文来看，所以相关处理并不违反Wikipedia:格式手册/文字格式#粗体。Sanmosa In vain 2023年7月15日 (六) 23:27 (UTC)
复制自MOS:B文字(后面空格隔开文字是我的理解)，如果对指引的讨论仅限于对指引的理解，会提供个人意见。增减修订可能涉及层面较广，不对增减修订发表意见。
  1. 对条目正文中的重点，请别使用粗体。 @Sanmosa提到的是这个
  2. 在条目的其馀部分，只有以下少数特殊用途才使用粗体。 这段同时规范了条目内非正文的内容，并没有非正文就不受规范的问题
--Rastinition（留言） 2023年7月15日 (六) 23:38 (UTC)
(～)补充：粗体在体育赛事有助加速读者理解赛事结果，参照：签表粗体标示、签表无粗体标示。--Terry850324（留言） 2023年7月16日 (日) 02:59 (UTC)
征求证实资料有助加速读者理解赛事结果[来源请求]，讲真还不如用底色或（）表示。 --窝法乙烷 儿法梦碎 2023年7月16日 (日) 07:29 (UTC)
个人认为在体育赛事签表或Box中使用（）标示胜者显得突兀。用底色当然可以，但以签表模板来说未见加底色凸显胜者的功能，如果无人改模板，得请教如何在签表模板中人工加底色，粗体是快速简便方式。--Terry850324（留言） 2023年7月16日 (日) 11:42 (UTC)
@Terry850324：其实你看一下其他有加底色的表格的原始码就知道怎样为表格加底色了，不过要再套用到模板里可能还需要知道怎样写语法原始码。Sanmosa In vain 2023年7月16日 (日) 11:58 (UTC)
@Milkypine：这样做有可能属于滥用底色。Sanmosa In vain 2023年7月16日 (日) 11:58 (UTC)
我感觉如果可以的话，自enwiki翻译那边的规定过来或许是个好提议。Sanmosa In vain 2023年7月16日 (日) 04:04 (UTC)
似乎未见英维对应页面特别描述体育赛事粗体作法。--Terry850324（留言） 2023年7月16日 (日) 11:48 (UTC)
好像也是。不过enwiki那边的条目好像也一样是用粗体来处理的，zhwiki当时的规定应该是从enwiki那边翻过来的，那这样看来相关处理确实并不违反Wikipedia:格式手册/文字格式#粗体。Sanmosa In vain 2023年7月16日 (日) 11:58 (UTC)
@Sanmosa
  1. 如果是指en:MOS:B
    Avoid using boldface for emphasis in article text. Instead, use HTML's element or the template (which usually render as italic). <em>...</em>{{em|...}}
    机械翻译后: 避免在文章文本中使用粗体进行强调。请使用 HTML 的元素或范本（通常呈现为斜体）。</em>{{em|...}}
    而本段内容在本地MOS:B被补充说明-中文读写并不适合斜体。虽然技术上可做到，但并不适合阅读，也无此体例。综合以后可以得知英文用于强调重点的标注方法包含斜体，但本地因为语文格式问题而不采用斜体，所以实际上本地在强调重点时粗体和斜体都不可用
    关于@Sanmosa提到的用粗体处理，在英文的指引上，如果文字理解没有错误，正确做法是斜体处理
  2. en:MOS:BBB，除了本地的规范外，英文版本另外有提到粗体可以用在特殊数学符号，细节我并不是很清楚，可能是源自于数学符号显示的特殊性
--Rastinition（留言） 2023年7月16日 (日) 12:18 (UTC)
首先，我不觉得enwiki那边的对应条目违反了enwiki那边的MOS。其次，我觉得你不要一来就直接认定这种情况属于“使用粗体进行强调”。Sanmosa In vain 2023年7月16日 (日) 12:22 (UTC)
@Sanmosa 请你检阅这个原始码[2]，然后显示预览，这是表格参数自带效果，但实际上并没有使用'''X'''，如果要用也可以，但因为表格参数已经包含，所以没意义(对应本地MOS:B提到维基百科会自动将章节标题和表格标题以粗体显示。人为加粗的标题，会显得特别加粗，虽然可以这么做，但并不合适。)
可能你认为实际上他用了粗体，但真实状况是，这是表格或模板自己本身的效果，而不是刻意使用粗体的结果，如果用英文的情形讨论，如果是表格或模板参数自带效果，就不存在粗体使用与否的问题，但如果不是自带效果，就有粗体使用与否的问题
(～)补充简而言之，如果是模板或表格自带的参数效果，那没有粗体的问题，但如果不是自带的参数问题，不是MOS:B提到可使用的情形（术语、书目格式、期刊文章的卷册编号、部分外文专有名词），就不能使用。--Rastinition（留言） 2023年7月16日 (日) 12:29 (UTC)
您举的案例并不适用，因为在英维World Olympic Record模板中同样使用'''加粗字体。--Terry850324（留言） 2023年7月16日 (日) 12:47 (UTC)
https://en.wikipedia.org/wiki/Template:World_Olympic_Record
那是模板自带效果，没有使用'''，细节请自己使用模板在沙盒中测试，只要有输入资料,对应的特定表格位置会自动呈现粗体。(～)补充模板或表格自带效果的粗体是模板固有的效果，不是编辑者特意使用粗体的结果，我们在这边谈的应该都是编辑者刻意使用'''的情形。模板或表格自己固有的呈现效果可能在WP:互助客栈/技术进行比较适合，个人认为这不是讨论MOS:B能处理的--Rastinition（留言） 2023年7月16日 (日) 12:51 (UTC)
原码中写的是'''{{{world_mark}}} '''，意思是传入world_mark参数，在表格中使用'''标示传入值，这跟人工使用'''没有差别，只是写模板的人节省人工加粗字体的动作。--Terry850324（留言） 2023年7月16日 (日) 13:03 (UTC)
(～)补充：我想说的是，模板自动加粗字体，通常原码中写的一样也是'''。--Terry850324（留言） 2023年7月16日 (日) 13:07 (UTC)
(：)回应我理解你的意思，我的意思是模板的参数，通常使用者不会去检阅或设计(或不具备设计或调整能力)，所以除非效果是可选的或加入空值，否则选择使用模板的使用者不具备决定呈现如何效果的能力，有意识地使用粗体跟使用模板呈现的粗体虽然效果相同，但在使用者的角度是使用意愿的差别，使用者不想/没想过使用部分效果但模板预设有特定效果且不可调整，使用模板后的呈现效果就不是使用者刻意造成的结果。
所以我在这边想表达的不是模板呈现的粗体行不行(实际上我也没想过)，但如果Template空间的模板被社群认可使用，那我认为这不受格式规范(因为1.使用者不可控制模板参数2.社群认可使用模板3.部分高风险或常用模板会被页面保护，根据保护等级，修订过程需要更高程度共识，像是仅限管理员可编辑时，必定形成WP:共识才能修改)--Rastinition（留言） 2023年7月16日 (日) 13:20 (UTC)
我认为应该允许体育赛事对阵图用粗体高亮胜出的选手及比分，显然有利读者更直观的看到谁赢了比赛。既然现在有用户借MOS:B为由移去胜者高亮，那我支持在相关方针中加入允许体育赛事对阵图加粗胜者的条文。--🔨（留言） 2023年7月16日 (日) 13:08 (UTC)
表格的话，可以适当运用粗体文字凸显重点（例如这里提到的赛事胜者）吧。别滥用就好。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年7月17日 (一) 09:46 (UTC)
不只体育赛事会将胜出、晋级一方使用粗体，颁奖典礼（第93届奥斯卡金像奖、第78届金球奖、第62届格莱美奖）、选举（2020年美国总统选举、2020年中华民国总统选举）等等也是，已行之多年，MOS:B早该将这部分修订进去。--寒吉（留言） 2023年7月17日 (一) 12:05 (UTC)
赞成MOS:B应认同以粗体标示赛事胜者的作法。--Terry850324（留言） 2023年7月18日 (二) 14:53 (UTC)

提议修改Wikipedia:格式手册/文字格式，并讨论“确立”条目中粗体的正当用法与使用时机

最新留言：在1年前发布7条留言6人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2023年8月27日 (日) 08:14 (UTC)。

雪球，此例Kenny023的写法符合格式手册，无需调整。——Sakamotosan路过围观 | 避免做作，免敬 2023年8月17日 (四) 02:02 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

对于条目中粗体的使用，有鉴于Kenny023主张，我提议修改Wikipedia:格式手册/文字格式，并讨论“确立”粗体的正当用法与使用时机，以求解决Kenny023主张抵触目前社群共识的问题，避免未来编辑时，陷于无所适从。--2001:B011:A401:1BD2:D162:B5BD:37E:298F（留言） 2023年8月15日 (二) 19:42 (UTC)

Wikipedia:格式手册/序言章节#标题和别名的加粗：“重要的别名需要加粗”，除非您认为“嘉义市市区公车”不是重要的别名。--街燈電箱150號 开箱维修 抄表 检验证明 2023年8月16日 (三) 00:08 (UTC)
不觉得哪里抵触共识，本来就是这么用的。浅蓝雪❉ 2023年8月16日 (三) 07:28 (UTC)
需要雪球？这个例子来看，如果这是一个别名的话，这样在导语段中加粗符合格式手册。——Sakamotosan路过围观 | 避免做作，免敬 2023年8月16日 (三) 08:36 (UTC)
Kenny023的用法本来就没有错。Sanmosa віки-віків 2023年8月16日 (三) 14:00 (UTC)
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:格式手冊/文字格式/存檔二&oldid=80332800”
返回到项目页面“格式手冊/文字格式/存檔二”。