维基百科

维基百科讨论:分类、列表与导航模板

Jimmy-bot在话题“各地之最分类被清空”中的最新留言：1年前
了解更多有关此页面的信息

建议把WP:CLN列为正式指引

编辑
最新留言：在11年前发布20条留言8人参与讨论

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

由于常有列表因可被分类取代的原因而被提请删除，因此现建议把英文版的正式指引维基百科:分类、列表与导航模板（en:Wikipeida:Wikipedia:Categories, lists, and navigation templates）列为正式指引。这可能与维基百科:列表有冲突之处，欢迎参与讨论，达成共识。Professorjohnas（留言） 2013年1月31日 (四) 10:36 (UTC)回复

建议发起人先列出冲突项目，并针对冲突部分提出建议，以方便大家参与讨论。-- by User:Alberth2 汪汪 @ 2013年1月31日 (四) 10:52 (UTC)回复
(※)注意 请勿将中文维基视为英语维基的中文版。--Qui cherche trouve 2013年1月31日 (四) 11:00 (UTC)回复
(：)回应：我绝对没有把中文维基视为英文维基的中文版，只是英文维基发展完善，其方针确有不少可取之处，而且各语言的维基百科目标一致，既然一方针在另一语言版本中可行，为何在中文版中就不可行？Professorjohnas（留言） 2013年1月31日 (四) 11:25 (UTC)回复
(～)补充：冲突项目：
  • WP:LIST：“列表不应仅单纯的列出各项名称，而应提供各项名称简介或各项之间可比较的信息等其他资讯，即该列表不应该可简单的由分类取代。而未改善的单纯列出各项名称的列表应经存废讨论删除或改为分类。”
  • WP:CLN：“一个分类与一个列表重叠并非任何一者被提请删除的合理理由……当决定是否建立列表时，分类的存在是不必考虑的。”
另请注意WP:CLN的“导航模板”部分未作翻译。Professorjohnas（留言） 2013年1月31日 (四) 11:31 (UTC)回复
这个指引就行了吧？没必要方针的--百無一用是書生 (☎) 2013年1月31日 (四) 12:12 (UTC)回复
这两者完全不存在冲突。WP:LIST是在要求列表的内容的问题，而WP:CLN说的是分类与列表主题重叠的问题。WP:LIST中并未要求若列表与分类重叠就必须删除；而是在于其内容是否合格。即即使列表与分类重叠，而列表内容符合WP:LIST的要求，该列表就不会被删除。乌拉跨氪 2013年1月31日 (四) 15:31 (UTC)回复
亦即是说纯列表为不合格内容。如果列表可以提供各项名称简介或其他资讯，即使与分类重叠，也不会被删除。--Qui cherche trouve 2013年2月1日 (五) 00:21 (UTC)回复
(：)回应，我建议这条指引的目的并不是要保留真正的纯列表，而且我也认同没有附加资讯的纯列表是不合格内容。问题是有很多列表有潜在能力可以成为带附加资讯的列表，却被人以“以分类取代”的原因删除，例如阁下先前提删的一系列条目。当然是否有“潜在能力”的标准很主观，但的确有些条目是明显可成为带附加资讯的列表却被提删，例如“XX大学列表”、“XX电影列表”之类，若发现这类条目是纯列表，正确的做法是扩充，而非以“分类”的理据提删。留意WP:CLN中“建立一个未完全的列表是一个健全的列表的第一步”，保留这些列表正是我提议此指引的原意。注：所谓“有附加资讯”，我认为标准不应订得过严，例如有依特定特色而把条目以章节分类，或中外事物有加上原外文的列表，因方便读者检索，仍应予以保留。另“真正的纯列表”指的是可被分类百分百取代，而无扩充空间的列表，它们的主题多数范围过阔，以致所列条目间关联不大，如“电影相关条目列表”，应被分类:电影取代。Professorjohnas（留言） 2013年2月1日 (五) 11:35 (UTC)回复
(～)补充，谢谢User:乌拉跨氪提醒，我不同意的条文应为“未改善的单纯列出各项名称的列表应经存废讨论删除或改为分类”，建议改为“对于单纯列出各项名称的列表，应考虑其有否扩充成有附加资讯的列表之条件，如有，应予以保留并扩充，而非提请删除”。Professorjohnas（留言） 2013年2月1日 (五) 11:47 (UTC)回复
提删的7天时间即是给予大家修补某个内容不合格的列表的期限。不能因为其有被扩充的可能而保留下来。就像存废讨论中关注度不足的条目一样，其中一样有可能被保留下来但最终因为无人完善而被删除的情况。所以，简而言之，提删7天即是给予大家完善的时间，而其后仍没有改善，我们不因以可能的情况保留不合格的内容。乌拉跨氪 2013年2月2日 (六) 07:08 (UTC)回复
7天时限实在是太短，特别是当一大堆所谓不合格列表被提删时，7天根本没可能补充完善。Professorjohnas（留言） 2013年2月2日 (六) 08:56 (UTC)回复
有心人可以主动找出不合格的条目，并加入更多资讯。不必等待提删方发觉时间不够。--Qui cherche trouve 2013年2月2日 (六) 14:27 (UTC)回复
回到主题，将此指引订为正式指引未见其害，反可让使用者更清楚这三种条目组织方法的利弊和角色。Professorjohnas（留言） 2013年2月2日 (六) 15:44 (UTC)回复
另我上述对“有附加资讯的列表”和“纯列表”的定义未知阁下又是否同意？Professorjohnas（留言） 2013年2月2日 (六) 15:48 (UTC)回复
导航模板段落根本没内容，怎么立为指引。乌拉跨氪 2013年2月2日 (六) 15:50 (UTC)回复
(＋)同意用户:乌拉跨氪的质疑，请补上至少一至二句一般性原则性的指引再正式提交，或(＆)建议改提翻译／讨论案，有初步共识后提正式方针化。--(研究维基和百度百科的hanteng|留言) 2013年2月3日 (日) 01:35 (UTC)回复
附议用户:乌拉跨氪的质疑。ω奇牙ω·♥揍敌客♥ 2013年2月6日 (三) 03:19 (UTC)回复
此方针虽好但内容定义不明确将产生许多不便!ω奇牙ω·♥揍敌客♥ 2013年2月6日 (三) 03:21 (UTC)回复

请管理员强势推进 维基百科:分类、列表与导航模板 为方针或指引

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

本主题或以下段落文字，移动自WP:VPP。执行者：--J.Wong 2018年4月4日 (三) 18:00 (UTC)。回复

最近的X国人列表条目被提删，提删理由多有“分类可以替代”，这种单纯以分类可以替代为由引发的提删讨论可以想象在以后也会不断，有多名用户提醒，解决办法就是：请强势推进维基百科:分类、列表与导航模板成为方针或指引。其中有说，分类和列表是不同的形式，互相补充，不能以其中一个为理由删掉另一个。这个是双赢的局面，即便习惯分类的用户也不会受到很大影响。因为这条没有成为方针指引，多有用户以这个为理由，声称这不是方针所以可以提删你的条目，把这种“没有形成共识”的行为当作“共识”，声称既然没有达成共识，那反对这条里的每条决定就是所谓的“社区共识”，所以他们提删别人条目时不说“我认为分类可以取代”而是“因为不是方针，所以社区达成共识，分类可以取代列表”，很显然，社区并没有达成“分类可以取代列表”这种共识。

不只是推进而是强势推进的原因之一是，推进这个很可能是维基上少数管理员不会太招人反感的行为。想象一下秦国统一六国，统一度量衡，这时候赵国出来说，不行，你们都半斤八两我偏要半斤九两，秦始皇应该怎么做？照顾赵国的意愿？当然不行，半斤八两全部统一对赵国也有益。反映到此事，有几个用户认为既然有分类就足够了，不需要列表，所以不想达成共识。可是维基百科:分类、列表与导航模板对应的英文已经在英文维基达成共识，是一项指引，所以现在问题，是不是分类可以取代列表这个事情是中文维基独有的风俗习惯和传统，几千年历史，华人喜欢分类甚于列表？10几亿华人均认为分类可以取代列表？NO！当然不是。这里是中文维基，要照顾用户的感受，所以这件事没达成共识实际上是要照顾这几个用户的感受，就好像要照顾赵国的感受一样。 迟迟不形成方针或者指引，还在制造对立分歧，这种基本的方针指引，英文维基已经达成，中文维基为什么不能达成，难道中文维基在分类和列表这个问题上就如此与英文维基不同？这是中华文化独有的习俗？NO, It's not! 不形成共识，以后还会不断有人以“分类可取代”为由提删各种列表类条目，如此又会产生大量的争论，而究其根源就是没有将这个形成方针和指引。假设强势将这个形成方针和指引，则那些声称分类可以取代列表的用户开始可能会有些微词，但既然已经是方针就必须遵守，而且这个方针对他们以后编辑条目没有任何影响，因为没有影响他们也不会记恨推进的管理员，所以强势推进维基百科:分类、列表与导航模板成为方针货指引可以减少以后的分歧还不会被用户记恨，可以鼓励多建立有趣的列表和互补分类缺少的信息，简直一举多得，实在应该马上进行，尽快达成。--Jasonnn~zhwiki（留言） 2018年3月25日 (日) 13:58 (UTC)回复

你那些X国人列表不是收录标准不合理才被删的吗？--【和平至上】💬📝 2018年3月26日 (一) 08:38 (UTC)回复
谢谢和平至上君自己和平至上地成了本人所述的例子。— 卍・〇・卐 2018年3月28日 (三) 05:20 (UTC)回复
  • 思想上不应该总觉得只有管理员才能怎样怎样，像这种“请管理员强势推进”的标题让我觉得您对管理员的职能认识有偏差。说来说去这些事情还是离不开在中文维基上达成共识，而现状是社群并不赞同这些列表的存在。--Kuailong™ 2018年3月26日 (一) 19:22 (UTC)回复

导航模板

编辑

近期编辑常会碰到拿导航模板不用与条目做双方连结为理由。建议设立，可以避免导航模板的不适当使用。Zenk0113（留言） 2018年3月26日 (一) 02:30 (UTC)回复

分类是否可以取代列表？

编辑
最新留言：在6年前发布5条留言5人参与讨论

本主题或以下段落文字，移动自WP:VPP。执行者：--J.Wong 2018年5月12日 (六) 04:34 (UTC)。回复

维基百科:分类、列表与导航模板在英文维基是指引，但在中文维基长期达不成共识，因此产生大量的以“分类可取代”为理由去提删列表类条目，如果再不改善，可以预见以后也会不断出现类似的提删，无形中增加了社群的工作量。 分类是否可以取代列表？是否应该把维基百科:分类、列表与导航模板升级为指引？欢迎各位来此讨论。--Jasonnn~zhwiki（留言） 2018年5月2日 (三) 16:01 (UTC)回复

列表有其不可替代的功用，亦有很多待解决不足。个人认为暂时不应该提删相关条目，但它们仍有待改进、完善-某人✉ 2018年5月3日 (四) 16:17 (UTC)回复
其实上面已有相关讨论，但我还是回应一下。所谓分类可以取代列表，其实多是因为那些列表过于简陋或收录缺失，导致功能上与分类没有太大差距，才有取代的可能。如果那些列表写得井井有条，收录内容全面，参考充足的话，根本不会有被分类取代的可能。因此，这里指的分类可以取代列表的列表是指那些没有发挥到列表应有功能的列表，而非全部列表。—AT 2018年5月3日 (四) 16:48 (UTC)回复
完全同意AT君的意见。列表跟分类各有各的功用，目前中文维基是因为存在太多仅有分类功能的列表，与想要体现列表功能的分类架构，导致二者之间的界线很模糊。另外，很多模版魔人嗜把列表的概念混进导航模版里面，搞得许多模版都超巨大甚至超越本文，也是另一个搞不清楚工具特性的常见弊病。--泅水大象™ 讦谯☎ 2018年5月4日 (五) 04:16 (UTC)回复

移除中华民国双边关系模板中低关联性的条目

编辑
最新留言：在4年前发布26条留言8人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2020年11月6日 (五) 16:14 (UTC)。回复

原标题为：模板:中华民国与德国关系 移除低关联性的条目

我认知是模版的使用是连结关系性高的项目 并双向连结(这类也几乎没有放置)，以这类模版为例，如果单纯德国产的武器或交通设备或是参与参加赛事 这类低关系性可以于中华民国与德国关系开个章节描述即可。如果 1.买了XX国生产的军事或交通的某设备 或是2.参加某个运动赛事 就被挂满XX与XX的关系外交模板，如果此例可行所有的武器 交通设备或是运动赛事条目就是都挂了XX国与XX国的关系模版(如果有人成立的话) 目前只有中华民国与XX关系为大量 但是条目创作都要可供查证了 这类模版很容易把模板当条目在写 也不易查证 以上想法Light0113（留言） 2020年10月6日 (二) 16:00 (UTC)回复

  • 双边关系条目、模板、分类本来就是收录双边相关的人事物，相对而言也就较为广泛，收录标准也就见仁见智，且对于分类、列表与导航模板而言，“中文维基百科尚无采纳共识”。至于双向连结，A模板收录B条目，但不必然都要在B条目下方挂上A模板，例如不会有人这么天才（闲），在某届夏季奥运会条目下方挂满各国双边关系模板，这点请放心。如果阁下有兴趣从事双向连结，我欢迎，且您近一年前也在我的讨论页表示“那我有空再补一补双向连结”。也不存在不易查证的问题，因为点进该条目便知，若有误也是该条目的错误。此外，我建议阁下多关注您创建的德台协会条目（语句问题）。--Tp0910（留言） 2020年10月6日 (二) 22:16 (UTC)回复
后来没空 所以我觉得还是请导航模板的撰写人自行补上(不过先讨论这些内容合不合适在说)，p.s德台协会条目（语句问题）与本次主题无关 请就事论事。我依现行规范提出讨论(就是没共识才要讨论)而已，如果不用双向连结，那就单纯开在条目写在就可以了。导航模板的作用本来就是连结双向的高关系度连结。以上规范上的讨论。实务面上，两国间的关系，要列了交易纪录(军事设备 交通设备) 或是运动赛事的比赛纪录 我觉得重要程度很低 整个模板很大也不精简 上述三项还会随时间持序增加，所以提出讨论。Light0113（留言） 2020年10月7日 (三) 13:38 (UTC)回复
  • 各位的意见，我回复如下：人物收录不应局限外交官，就像国与国的交往不会只有政治。其中有关留学的部分，如果创建Category:在德国的中华民国留学生，就可以大幅精简，武器亦然（例如Category:中华民国使用的德国武器装备），且中华民国与德国曾经有紧密的军事合作，因此武器的收录我认为应当，在部分条目内文也有提及。至于归类在其他的条目，“其他”本身就是杂项之意。若各位有兴趣请自行创建有关分类（个人是完美主义者，请各位尽可能搜罗有关条目进分类中），我再依照分类做模板的调整。与英国、法国、美国等模板也请比照办理。其实收录标准，套用日常说话或行文，有人偏好言简意赅，有人喜欢长篇大论。--Tp0910（留言） 2020年10月9日 (五) 19:11 (UTC)回复
(！)意见我也觉得我们想法差异过大 所以提出来问问大家意见 我还是回归定义讨论 模版的使用在于高相关性的条目双向连结，所以收录方式我不觉得完美主义适用于导航模板是好的 所以我主张我认为关连性低的部分(各类设备跟赛事 人物跟组识我是觉得见人见智) 条目另开章节即可。如果这次讨论完 其他人也无感 那就放着吧! 过几年 我再提出也无访 或许等Wikipedia:分类、列表与导航模板得到共识的时后，我主张导航模板应该使用双向连结才有所理据。Light0113（留言） 2020年10月10日 (六) 09:25 (UTC)回复
(？)疑问如果您认为军事是重要的 那交通设备跟运动赛事 我应该可以删除吧?Light0113（留言） 2020年10月10日 (六) 09:25 (UTC)回复
了解 目前先处理运动赛事部分 其他的看大家意见 Light0113（留言） 2020年10月12日 (一) 14:21 (UTC)回复
  • 确实有很大的精简空间。如果把各种武器赛事人物什么的全部加进来，模板迟早有一天会超出限制。—— Eric Liu 欢庆双十中国国庆（留言．留名．学生会） 2020年10月10日 (六) 13:48 (UTC)回复
    • 不是不能精简，而是有条件精简。再次呼吁若各位有兴趣请自行创建有关分类，我才有依据做调整。双边关系模板总不能只有硬梆梆的历史或政治，仿佛其他人事物不存在过，这样也称不上完整吧？--Tp0910（留言） 2020年10月10日 (六) 14:39 (UTC)回复
      • 即使如此，也应当在建立模板的时候就要负责任将相应分类处理好才对，怎么会反过来要求其他人帮忙收拾善后呢？—— Eric Liu 欢庆双十中国国庆（留言．留名．学生会） 2020年10月14日 (三) 00:21 (UTC)回复
        • 我当时的目标就是创建模板，是将相关的人事物收进模板里，而不是处理分类，我是不是也可反问“为什么其他人没有将条目来分类完善呢？”我就可以将分类直接放进模板里，节省空间。我也不认为这是“收拾善后”，因为我觉得模板没啥问题，若有人觉得有问题，也自然由提出问题的人想出解决之道，而非纯粹删除。提醒一下，大家编辑维基百科完全是义务性质，除非违规，否则没有谁要谁负什么责任。--Tp0910（留言） 2020年10月14日 (三) 13:32 (UTC)回复
          • 即使是要收录相关的人事物，也不代表所有跟中德关系沾得上边的东西、所有有内部链接的条目无论关联性高低都要收啊。连单纯在德国留学过的人、在德国出生的人、每一场由双方其中一国主办的奥运和国际赛事、每一样中华民国使用的德制武器啊车辆啊等等全部都要加进模板，真的有必要吗？您当初在建立那些模板的时候可能觉得篇幅还好、没问题，但随着时间过去，按照现在这个收录标准，中华民国无论是跟哪一国的关系模板都迟早要爆炸，这是当初建立模板的时候花点时间想一想就能得出来的结果。如同条目本身一般，模板收录的范围也应该要有所取舍，这不是违规不违规的问题，是常识，上面其他几位编者也都明白这个道理。回到正题，Temp3600阁下在下面提的解法应该可行，我也会帮忙想想怎么精简这类模板。—— Eric Liu 欢庆双十中国国庆（留言．留名．学生会） 2020年10月14日 (三) 16:20 (UTC)回复
            • 阁下想帮忙着手改善，我欢迎。有三点意见表达，首先，我依旧认为这是见仁见智的问题。其次，中华民国双边关系模板创建已三年有余，可以说只有我一人主编，绝大多数该收录的条目在创建之初就已收录，剩下只是零星添加，且我不可能永远在维基百科，如果之后没有其他人有兴趣，在很长的一段时间都不会爆炸。最后，阁下真的认为“中华民国无论是‘跟哪一国的关系’模板都迟早要爆炸”吗？--Tp0910（留言） 2020年10月15日 (四) 12:28 (UTC)回复
              • 他的意思是照目前的收录方式，如果我们不讨论的收录或编辑共识的确每个中华民国与xx关系模板都会爆炸或是难以重点的可能ex目前美国或德国已有这个趋势。至于删除也是一种解决方式，但是要有依据(关联度低)或是解决方式(写在条目就好)而已，但是被忽略简化成一昧删除 如果那天您主导的这些模板不编辑 我一样会提出这样的疑问 找共识删除不太重要的项目 Light0113（留言） 2020年10月17日 (六) 04:22 (UTC)回复
            • 既然有编者有意见，所以我后来才会提出使用分类，放进模板里，例如留学德国、德制武器等，既可将该条目再做分类，又精简模板。--Tp0910（留言） 2020年10月15日 (四) 12:50 (UTC)回复
  • 应该拆分成几个模版，要看的自己点进去。--Temp3600（留言） 2020年10月13日 (二) 02:39 (UTC)回复

历史人物条目Infobox中的出生、死亡地点、籍贯及国家归属应统一使用原称

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

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

不应一边用现代名称，一边用古代名称。现名可以加括号放在后面。芄兰（留言） 2021年3月18日 (四) 18:32 (UTC)回复

有混淆历史的可能，用不同名称的原因就是想区别历史时期。就像我们会将清朝时的“惠阳县”称为“归善县”，而不会称为“惠阳县”；反过来我们会将清朝以后的“惠阳县”称为“惠阳县”，而不会称为“归善县”。我们不会将礼萨汗掌政前的伊朗称为“伊朗”，也不会将礼萨汗掌政后的伊朗称为“波斯”。因此，我个人不甚同意此提案。SANMOSA 江南好，风景旧曾谙 2021年3月18日 (四) 23:51 (UTC)回复
当然，如果说的是同一历史时期（而非跨历史时期）的话，统一用同一名称反而是应该的。SANMOSA 江南好，风景旧曾谙 2021年3月18日 (四) 23:56 (UTC)回复
你理解错。我指的是一个隋代出生的人，在唐代死去，则应分别使用对应的原称；而非一个用隋唐原称，一个用今天名称。如果他在今天才死，那确应用今天名称。总之他何时死，就应用何时的地名。芄兰（留言） 2021年3月19日 (五) 00:57 (UTC)回复
那我完全同意你的想法。这不是常识吗，究竟是发生什么事情了？SANMOSA 江南好，风景旧曾谙 2021年3月19日 (五) 03:54 (UTC)回复
郑成功，有人写生于日本九州平户，死于南明承天府，应该写肥前国平户、大明承天府（或者东都明京）。芄兰（留言） 2021年3月20日 (六) 15:12 (UTC)回复
您要这样写是应当、合理的，但麻烦在括号里附注现今的行政区划，这也是极度必要的。-游蛇脱壳/克劳棣 2021年3月20日 (六) 20:24 (UTC)回复
他上面不就说了“现名可以加括号放在后面”吗？他不会否定这种做法。SANMOSA 江南好，风景旧曾谙 2021年3月21日 (日) 10:00 (UTC)回复
@芄蘭：你打算就此增订格式手册条文吗？SANMOSA 江南好，风景旧曾谙 2021年3月26日 (五) 09:59 (UTC)回复
建议增加“历史人物条目资讯框（Infobox）中的籍贯、出生、死亡地点，应使用该人物所处年代的原称。可在括号内附注现今名称。”国家归属暂不写了，感觉有争议。芄兰（留言） 2021年3月27日 (六) 15:14 (UTC)回复
有争议的话循事实论述即可，我们现在有WP:PB，这不是只有两岸四地相关的才适用。上面草拟的条文可行（但会微调），我看看适合加入的位置。SANMOSA 江南好，风景旧曾谙 2021年3月28日 (日) 00:51 (UTC)回复
建议在WP:格式手册和WP:分类、列表与导航模板加入以下一条：

以上。我感觉这不只Infobox和人物条目才需要适用，而且也符合编辑习惯。SANMOSA 江南好，风景旧曾谙 2021年3月28日 (日) 01:04 (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年前发布27条留言18人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。执行者：Jimmy-bot（留言） 2023年6月29日 (四) 16:14 (UTC)。回复

留意@Yumeto君近日将各地的“之最”分类清空，有些清空后已被O4速删，如Category:台湾之最、Category:日本之最，另外还有Category:香港优良条目这种分类。惟未察觉近日有相关讨论，请问这行动是否曾讨论获得共识？如无，是否应该先讨论？--Factrecordor（留言） 2023年6月10日 (六) 15:06 (UTC)回复

不断精细化“最怎样的什么”中之“什么”，总能成为“之最”，属过度分类。分类:香港优良条目是已有分类:优良级香港条目。--绀野梦人 2023年6月10日 (六) 15:18 (UTC)回复
可这些分类存在时间并不短，宜先达成共识。像台湾首位诺贝尔奖得主李远哲、香港票房最高电影毒舌大状、香港最长寿综艺节目欢乐今宵等等显然都不是依靠精细才能成为“之最”的，应讨论如何安置这些当之无愧的“之最”。再说，如果所有“之最”的定义是具有多个可靠来源，而非原创总结，也不见得会无限精细化。而各地的世界之最（如Category:香港的世界之最）就更加不像依靠爱好者的过度精细才能获得的。--Factrecordor（留言） 2023年6月10日 (六) 15:59 (UTC)回复
@寒吉、AT：请经常处理分类的两位给点意见。--Factrecordor（留言） 2023年6月10日 (六) 16:20 (UTC)回复
我支持删除，但是不应该直接清空，不能走流程嘛。--Ghren🐦🕛 2023年6月10日 (六) 16:41 (UTC)回复
您说的“不断精细化”（例如“台湾老年比例最低的镇”、“台湾本岛人口最少的非山地乡”）是条目归类的问题，不是分类本身的问题。若觉得不妥，应该是把这些硬要挤进“屋子”里的不适合的条目移出“屋子”，而不是干脆把“屋子”烧掉，把当之无愧者也赶出去了。Category:台湾之最貌似不属Wikipedia:过度分类所列举的任何一种不适当分类。-游蛇脱壳/克劳棣 2023年6月10日 (六) 16:49 (UTC)回复
克劳棣君所言甚是。我知道这个讨论可能最后还是没有什么结果，尤其是有心人一直希望移除的那些分类可能最后还是都会给全部移除，但我只想问一句，一些有心人是凭什么去自行定夺什么不应归类到“之最”？--Will629（留言） 2023年6月10日 (六) 18:06 (UTC)回复
@Outlookxp、Ericliu1912、Shwangtianyuan、弟魯、Baomi、Nickice、Billytanghh、ThirdThink、Prince of Erebor、Achanhk：@Boattoad、Sanmosa、Wpcpey、A Chinese ID、Allervous、Matt8830：再邀请一些热心编辑各地区人、地的维基人参与讨论。--Factrecordor（留言） 2023年6月11日 (日) 11:49 (UTC)回复
收到ping。本人倾向于在此处讨论确定哪些“〇〇之最”系列分类可以删除之后再做处理，尽数删除有些火急。--     2023年6月11日 (日) 11:53 (UTC)回复
感谢邀请参与话题，有关“之最”分类遭删除之议题，就在下长期编辑的台湾能源议题来说，“之最”算是个不断变动的分类，如装置容量最大、最小、海拔最高的电厂等等，尤其近年风力、光电发展，台湾最大的太阳光电场不断在替换，使得分类会不断更改。编辑角度来说就必须追着能源变化时刻更改条目分类，但就阅览角度，因为有“〇〇之最”的分类就会好奇点进去看更多其他相同分类的条目，故我个人立场是偏向保留“〇〇之最”分类并加以整理。对于未获得共识下删除分类无法给予支持。Matt 007（留言） 2023年6月11日 (日) 12:09 (UTC)回复
感谢邀请参与话题，但反对删除某些既定的“之最”分类，因为某个日期最早的事物并不会随时间而不断变动，像“ 哪一所大学是西非第一所按照西式标准建立的大学？”因为从文献可以得知其日期上之早，可称为西非之最。所以研议认为“之最”分类遭删除未必合理，仍需核对后再考虑删除。--Allervousミクのセーラー服 2023年6月12日 (一) 00:23 (UTC)回复
其实我之前已经观察到当事人如此操作，只是一直没有空指出。基本上我不认同当事人“偷吃步”式的大规模清空分类，间接使其遭到快速删除。具体而言，我认为这一分类应该比照英文版，以“纪录”（records）为主，也就是不将个别人、事、物加入分类（否则流于穷举而成为琐碎分类——这里我同意当事人之意见），而以纪录相关之列表为主。不知道社群意见如何？—— Eric Liu 創造は生命（留言・留名・学生会） 2023年6月11日 (日) 12:15 (UTC)回复
我在效仿管理员AT整理其他分类的方式，如有不妥会加注意。回归分类问题，何者“当之无愧”，何者不“当之无愧”无从界定，仍是总能成为“之最”。可以只收录纪录本身（纪录相关列表）、极限相关概念等。--绀野梦人 2023年6月11日 (日) 14:08 (UTC)回复
话说@AT君都整理了些什么来着？—— Eric Liu 創造は生命（留言・留名・学生会） 2023年6月12日 (一) 11:10 (UTC)回复
在维基，没有非常具体细致的准则，而需要依靠讨论去决定的东西本来就很多。把“〇〇之最”展现出来，我看是大众很自然、平常的意愿，这里亦有人提出对读者有吸引力，要不诸如吉尼斯世界纪录大全这种东西也不会一直存在，规条的设立是应该为内容服务，为大众的意愿服务，因为规条未能明确订立而禁之，未免本末倒置、“官僚”主义。--Factrecordor（留言） 2023年6月12日 (一) 15:04 (UTC)回复
个人认为应当删除，但不认同当事人不照程序走的提删做法。--弟鲁（留言） 2023年6月11日 (日) 13:47 (UTC)回复
用读者的角度看，“之最”的分类也是有吸引性，可以方便知道每个地方的特色东西，应该要保留。--Wpcpey（留言） 2023年6月11日 (日) 14:14 (UTC)回复
可是平心而论，尽管我对台湾行政区划很有兴趣，但当我发现台湾全部6个直辖市、全部3个省辖市、大部分县辖市都已被收录于Category:台湾之最，那这个分类的其他“台湾行政区划”成员对我就几乎没有吸引力了。到底多少人会想知道“十年间老化指数上升最多的县辖市”是哪个？-游蛇脱壳/克劳棣 2023年6月11日 (日) 16:01 (UTC)回复
  • 建议用“台湾之最列表”条目代替分类，否则读者点进去台湾之最分类，发现台北市、新北市、桃园市、台南市、高雄市全在分类里，相当于都发钱等于都没发。至少在条目里你会看到收录理由，台北市是台湾面积最小的直辖市，高雄市是面积最大的直辖市，......。另外，为了照顾程序正义，应走程序。 -- Shyangs（留言） 2023年6月11日 (日) 16:29 (UTC)回复
  • 感谢邀请参与话题，建议删除或用条目代替分类，总能找到一个角度来将一个事物变成“之最”，就像行政区划，有地理极点，人口、面积海报的最高最低，经济指标、人均指标等等总有一个可以排名到第一名或者最后一名--苞米(☎)💴 2023年6月12日 (一) 11:40 (UTC)回复
似乎较多人倾向以“之最”列表收录，代替分类（相关分类可只用来放置这些列表），我也觉得有道理。虽然未能解决“不断精细”的问题，但集中起来一目了然，对判断及处理的效率也有间接帮助。--Factrecordor（留言） 2023年6月12日 (一) 15:12 (UTC)回复
似乎大家表按自己专长先建立之最列表，最符合共识及有助将来讨论。--Factrecordor（留言） 2023年6月19日 (一) 15:42 (UTC)回复
添加话题
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:分類、列表與導航模板&oldid=77876677”
返回到项目页面“分類、列表與導航模板”。