维基百科讨论:格式手册/文字格式/存档一
本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论,请在当前讨论页进行。 |
关于斜体的用途
正文中提到了中文斜体的不同用途,但我以为中文的斜体可读性非常差,不应以斜体方式展现给读者。
斜体、粗体有两种展现方式:
- 一是模拟。计算机对每个字进行计算,对笔划加粗或斜置。这种粗体斜体,被专业人士称为伪粗伪斜。
- 二是读该字体的意大利字体。例如英文的Arial字体,它有五个文件,Arial常规、Arial粗体、Arial粗体斜体、Arial黑体、Arial斜体。对用Arial字体的英文字,取其斜体是来自“Arial斜体”这个文件,是Arial的意大利斜体,而不是计算机计算的结果。(italic就是意大利斜体的意思——意大利人把字写得斜斜的)
所以英文粗体斜体大都很好看,而中文粗体有“黑体”这一字体,而斜体一直没有过。而且中文就不存在斜体一说,有谁把汉字写成斜的?斜体汉字只是受英文有斜体这一思想的影响罢了。
你有兴趣的话可以尝试看看读中文斜体,这是非常不舒服的!在专业论文期刊中,鲜有中文斜体。
我提议不要把中文斜体展现给读者。方法有二:
- 不提倡对汉字应用斜体。对于已经应用的,要去修改(机器人或手工)。
- 修改网站的css,已知维基把''文字''渲染成<i>标签,重定义i的样式,使它不要斜。但这样,英文的斜体也没了,要花些额外的功夫处理。
参考资料我没找到多少,大家可以看看上面伪斜、斜体两个维基链接;另外就是TeX里的思想,只找到一篇帖子http://bbs.ctex.org/viewthread.php?tid=42976 --Gqqnb (留言) 2011年6月30日 (四) 13:23 (UTC)
- ( ✓ )同意非常同意。中文不适合斜体。英文版Wikipedia:Manual of Style/Text formatting就有说:"Text in non-Latin scripts (such as Greek or Cyrillic) should not be italicized at all—even where this is technically feasible"。建议在格式手册中提出避免中文粗体斜体字的建议,在使用界面也避免这些字体。111.251.225.191 (留言) 2012年1月6日 (五) 13:41 (UTC)
- 已经研究出解决方法。请试用我的脚本中文无粗斜.js。--Gqqnb(留言) 2014年5月1日 (四) 06:21 (UTC)
议题:彩色文字与小图示的滥用问题
这个问题其实一直以来都间或有人提出,也有进行过一些讨论,但这次想要好好讨论一下之后将其增列入格式方针中。或许是个人审美观的考量,或者对于某些人来说这样的编辑方式比较有参与感,一直以来都有用户喜欢将中文维基的内文以各种彩色的文字与琳琅满目的图示“装饰”成像这页内容般的华丽状态。这些彩色文字有些是模板,有些是直接以html指令写成的。这种状况大部分都是出现在与交通、游戏、卡漫或演艺娱乐相关的条目或内容中,某个程度来说这似乎与粉丝风格内容有正关系(此为个人观察感想,我没有明确的做过统计)。
综观所有主要维基语版,迄今只有见到中文维基存在这样的现象:英文版几乎不存在彩色文字的使用,而且除了国旗图示会出现在表格中的情况外,我几乎没见过其他种类的小图示(像是公路线的图示之类的);日文版不使用彩色文字,但是偶尔会出现国旗以外的小图示于内文中,但是通常只作为条列示内容的标头(日文版特别喜欢用条列式的方式写文,并且感染了不少中文维基的文章,这个我相信有观察过的用户都有此印象)。相对的,日文版比较常见的作法是将列表标头的小方格(■)根据必要改成彩色的,但不会去更动文字颜色。
并不是说其他语版怎么制订规则我们就非得跟随不可,但是我想呼吁在中文维基中严格地禁止彩色文字与小图示的滥用,主要是基于下面几点考量:
- 原本的方针中本来就有“不要花俏”这个原则。
- 文字颜色对于维基百科来说是功能性的象征,例如蓝色是有内容的连结、红色是空连结,靛色是已经浏览过的连结,最近又多了使用link语言模板的浅绿色连结。如果随意改变文字颜色,等于破坏了文字颜色的功能性。
- 不管是彩色文字还是小图示模板,都必须在内文中加入特殊的编码,交杂太厉害时连资深用户在编辑时都嫌眼花,何况是生手。纵使那些彩色文字/图示爱好者不介意多花功夫进行编辑,但是如果一段文字已经加入了许多彩色字码的标签,那后续添加内容的人是跟进与否?跟进的话会白白增加编辑工作,不跟进则会混乱版面。为了这种没特别意义原因提升编辑困难度与工作量,很无意义。
- 颜色与图示版面的选择牵涉到个人审美观,但是每个人的审美都不同,往往会因为觉得好看或不好看反复更改用色或版面,甚至造成编辑冲突。与其为了这种没有对错的事情吵架,还不如统一格式,整齐、数大便是最基本的美感。
- 使用彩色文字与图示并不会带来额外的象征意义,只是重复地把文字已能表达的事情再重复一次而已。难道我非得看到“台北捷运红线”的字变成红色的,才会知道红色长这模样?难道我非得看到代表省道的盾状标志,才知道“九号省道”是一条省级道路?
- 整段文章被一堆小图示插入,至少就我而言是影响阅读顺畅度的。
基于上述理由,我想要简单扼要地提出如下的规则建议:
- 除Infobox中在必要时允许使用外,不管是文章、表格还是列表型式的主文内容,完全禁止使用彩色文字。
- 小图示只允许使用在Infobox与表格中,或者是作为列表或条列式内容的表头,但是在内文叙述中禁止插入小图示。(这是一点小让步,其实我比较倾向英文版的作法,完全不用)
以上只是抛砖引玉。不管各位是支持、反对,还是有其他相关的提案,都请各位中文维基人提供一下想法,获得共识之后写入格式方针,然后以后要出手进行整理时,也比较有依据、避免争议。谢谢大家。--泅水大象™ 讦谯☎ 2013年1月22日 (二) 11:07 (UTC)
- (+)支持:--下限魔法少年爱德华★爱生活爱圆神爱萝莉塔 2013年1月22日 (二) 12:41 (UTC)
- (+)支持: 动漫条目也有这种问题;列表中的颜色(底色)如何处理?(见维基百科:互助客栈/条目探讨/存档/2012年11月#特命战队Go Busters VS 海贼战队豪快者 THE MOVIE#登场人物中五颜六色的文字)--Nivekin※请留言 2013年1月22日 (二) 13:17 (UTC)
- (:)回应:虽然我的议题先只提出文字本身的颜色问题,但依照相同的考量原则,表格也是建议一律采用如class:wikitable这类固定、颜色单纯的配置,统一整个中文维基的格式。那种花俏的颜色标示,往往只需要简单的文字叙述就能作到相同的功能。--泅水大象™ 讦谯☎ 2013年1月22日 (二) 13:29 (UTC)
- 先表达(+)支持,其实最根本的还是方针问题——格式手册已经好久没有更新了。相对于小修小补,看来还是翻译新版本比较有效(如果能翻译英文版本的话应该是最理想的)。但单是想像要翻译,然后获得通过,当中已经需要不少时间,一个人肯定做不来。要做的话应该要召集多一点人一起翻译吧。—Altt311(留言) 2013年1月22日 (二) 15:12 (UTC)
- 我有打开英文版的格式手册速翻了一遍,发现规模篇幅实在惊人,里面有些内容不见得适合中文版的格式,我们可以挑重要的部分撷取。--泅水大象™ 讦谯☎ 2013年1月23日 (三) 02:15 (UTC)
- 同意我们不是一定要尽翻英文版手册,但在决定翻译的范围前,应先对尽翻英文版手册所载的规则进行较全面的评估,在加上正式的进行翻译,这些都是需要多一点人一起做才能令成效显著。--Altt311(留言) 2013年1月23日 (三) 17:10 (UTC)
- 我有打开英文版的格式手册速翻了一遍,发现规模篇幅实在惊人,里面有些内容不见得适合中文版的格式,我们可以挑重要的部分撷取。--泅水大象™ 讦谯☎ 2013年1月23日 (三) 02:15 (UTC)
- 我觉得有彩色字和图案没什么不好的,可以避免只有黑色字体审美疲劳,其实这正是我们比传统的纸质百科全书优越的地方,百度百科好像也做不到这些华丽的效果呢~--九紫离火很高兴认识你♥ 2013年1月22日 (二) 16:14 (UTC)
- 新一代的纸本百科全书也是彩色印刷的,但是彩色的部分只有图片,内文还是标准的黑色字体,为什么呢?因为对比最大的黑与白才是看久了之后最不会疲劳的配置方式,不信的话您可以用文书处理程式打开一篇长文,然后把里面的字体全换成红色、亮蓝、亮绿这种对比比较低的浅色文字,试试看看久了之后会不会吃力。会把文字印得花花绿绿的只有给儿童看的读物,因为儿童无法长期专心在文字本身,所以只好靠文字的颜色吸引他们注意力。所以这不是进步或优越的地方,而是搞错场合跟用途了!--泅水大象™ 讦谯☎ 2013年1月23日 (三) 02:13 (UTC)
- 彩色文字的最大问题是后来人编辑不方便......--魔法少年爱德华★爱生活爱圆神爱萝莉塔 2013年1月23日 (三) 02:20 (UTC)
- 如果是用模板产生的彩色文字,情形更严重。--泅水大象™ 讦谯☎ 2013年1月23日 (三) 02:23 (UTC)
- 彩色文字的最大问题是后来人编辑不方便......--魔法少年爱德华★爱生活爱圆神爱萝莉塔 2013年1月23日 (三) 02:20 (UTC)
- 新一代的纸本百科全书也是彩色印刷的,但是彩色的部分只有图片,内文还是标准的黑色字体,为什么呢?因为对比最大的黑与白才是看久了之后最不会疲劳的配置方式,不信的话您可以用文书处理程式打开一篇长文,然后把里面的字体全换成红色、亮蓝、亮绿这种对比比较低的浅色文字,试试看看久了之后会不会吃力。会把文字印得花花绿绿的只有给儿童看的读物,因为儿童无法长期专心在文字本身,所以只好靠文字的颜色吸引他们注意力。所以这不是进步或优越的地方,而是搞错场合跟用途了!--泅水大象™ 讦谯☎ 2013年1月23日 (三) 02:13 (UTC)
- 文字中使用红蓝两色, 会与内部结链混淆; 其他黄、灰、粉红等颜色又有碍阅读。到时不是审美疲劳,是眼睛疲劳--Nivekin※请留言 2013年1月23日 (三) 02:52 (UTC)
- 说起来,这已经不是审美疲劳的问题了。色盲色弱者...........--魔法少年爱德华★爱生活爱圆神爱萝莉塔 2013年1月23日 (三) 04:16 (UTC)
限制文字染色?那{{link-en}}怎么办?--达师 - 261 - 442 2013年1月23日 (三) 08:08 (UTC)
- 觉得{{ilh}}类不受限,首先颜色单调很多(只有不存在本地时才是其他颜色),而且这是必需的指示色,和上面提到的代表颜色不太一样,也不影响编辑(颜色在设计时已经处理到支持脚本之中,而且脚本失效时还是原来的红链)——Sakamotosan 2013年1月23日 (三) 08:43 (UTC)
- 目前建议可以把ilh产生的颜色文字视为是与蓝连结、红连结、浅蓝连结一样的功能性颜色文字,排除于本讨论之外。--泅水大象™ 讦谯☎ 2013年1月23日 (三) 10:29 (UTC)
用户主动对内文使用的文字颜色修改模板,不能应用于条目之中。这一方面是为了减轻服务器负担以及方便后来编辑者的维护,另一方面是为了方便色盲或色弱读者阅读文字。
以上建议加入到适当的方针或指引中。--魔法少年爱德华★爱生活爱圆神爱萝莉塔 2013年1月23日 (三) 11:28 (UTC)
- 目标页面应该是Wikipedia:格式手册 (文字格式) --达师 - 261 - 442 2013年1月24日 (四) 07:10 (UTC)
- (&)建议您指出该条目页面的根本问题,不是在颜色或图示,而是在列表,条目内容基本上不应该有那样的列表出现,最好是独立出来列表页面,列表页面按情况应该可以保留一下小图示及颜色,像保留国旗的图示似乎在很多列表上,如各国国内生产总值列表_(国际汇率)是常态。--(研究维基和百度百科的hanteng|留言) 2013年1月24日 (四) 08:15 (UTC)
- 中小型的列表在中文维基中出现的频率很高,而且并不都适宜另外单独成一篇编辑,所以这两件事情并不适合切割讨论。相反的,独立成篇的列表该如何规范反而是可以考虑另外开题的讨论,但我其实倾向不管哪种状况全都以同一种标准从严规范。--泅水大象™ 讦谯☎ 2013年1月24日 (四) 08:24 (UTC)
- 请大象提出具体的方案,或同意我的方案,否则这讨论没完没了。--魔法少年爱德华★爱生活爱圆神爱萝莉塔 2013年1月27日 (日) 05:22 (UTC)
- 看了看,认为爱德华那个建议是这个规则总体的解释,大象的2个建议是实际应用上的规则,和内容上没有冲突。如果只打算小修小补的话,就专注于把这3个建议的内容成为共识,然后动工清理。(必要时找机器人帮忙)--Altt311(留言) 2013年1月27日 (日) 17:00 (UTC)
- 请大象提出具体的方案,或同意我的方案,否则这讨论没完没了。--魔法少年爱德华★爱生活爱圆神爱萝莉塔 2013年1月27日 (日) 05:22 (UTC)
- 中小型的列表在中文维基中出现的频率很高,而且并不都适宜另外单独成一篇编辑,所以这两件事情并不适合切割讨论。相反的,独立成篇的列表该如何规范反而是可以考虑另外开题的讨论,但我其实倾向不管哪种状况全都以同一种标准从严规范。--泅水大象™ 讦谯☎ 2013年1月24日 (四) 08:24 (UTC)
- 我的具体方案不是一开始就列出来了吗?在维基百科上要一次进行大规模的规则变动不容易,所以能够增订这两条让日后的整理工作师出有名,就现阶段来说已经可算满意了。--泅水大象™ 讦谯☎ 2013年1月27日 (日) 18:10 (UTC)
- 若最终没有东西写进方针,日后争议出现,这个讨论将会毫无参考意义,信不信由你。--魔法少年爱德华★爱生活爱圆神爱萝莉塔 2013年1月29日 (二) 06:18 (UTC)
- 我的具体方案不是一开始就列出来了吗?在维基百科上要一次进行大规模的规则变动不容易,所以能够增订这两条让日后的整理工作师出有名,就现阶段来说已经可算满意了。--泅水大象™ 讦谯☎ 2013年1月27日 (日) 18:10 (UTC)
- 那是一定的。所以我开这条讨论的目的,是确定参与讨论用户意见如果大部分都很一致的话,在讨论结束后就把提案中的那两条规则加入格式手册中,作为日后清理条目时的理据。--泅水大象™ 讦谯☎ 2013年1月29日 (二) 09:05 (UTC)
其实我还是想问,到底是哪两条?.......--魔法少年爱德华★爱生活爱圆神爱萝莉塔 2013年2月1日 (五) 09:16 (UTC)
- 这两条:
- 除Infobox中在必要时允许使用外,不管是文章、表格还是列表型式的主文内容,完全禁止使用非系统功能定义的彩色文字。
- 小图示只允许使用在Infobox与表格中,或者是作为列表或条列式内容的表头,但是在内文叙述中禁止插入小图示。
- 当然,这是我提议的版本,叙述细节是否有需要修改以变得更明确之处,或是更严格限制相关作法,都欢迎讨论。--泅水大象™ 讦谯☎ 2013年2月1日 (五) 09:26 (UTC)
- ( ✓ )同意:我先前在互助客栈提出了有关Accessability(可读性)方针的建议,才知道有此讨论。现在的结论为何?该方针还没有加入正式页面以内?我在巡视页面的时候,实在太多刺眼的颜色了,例如{{上海申花足球俱乐部}}。希望能够尽快通过。钢琴小子 打个招呼 查看贡献 2013年2月22日 (五) 23:00 (UTC)
再次提请通过Wikipedia:格式手册/文字格式为指引
上次仅一人附议,无法达成共识,随后便冷清下来,今天一看,竟然已经被机器人存档,无奈只好重提。望社群予以重视…… --达师 - 261 - 442 2013年2月5日 (二) 06:53 (UTC)
- 你看现在客栈热火朝天的,不管发什么东西都会很快被盖过去。--耶叶爷♥VC XC 2013年2月5日 (二) 07:17 (UTC)
- 有条件(+)赞成:若删除斜体-西文作品名该行就附议及(+)赞成。理据:英文方针是因为有明列作法及范围(非西文限定,而是限定物件种类),现在中文部分,范围过广,再加上作品在中文书写,多以标点符号的方式处理,(&)建议此项目转移到标点符号处理。--(研究维基v百度百科的hanteng✉) 2013年2月5日 (二) 11:30 (UTC)
- 反对正文西文作品名斜体,个人认为应当杜绝在正文中的任何形式斜体。(英文斜体字和中文夹杂也并不美观。)--Kuailong™ 2013年2月6日 (三) 05:09 (UTC)
- 顺便问一下加大字号和缩小字号在哪规定的。--Kuailong™ 2013年2月6日 (三) 05:11 (UTC)
- 还有文字染色规定的问题。乌拉跨氪 2013年2月6日 (三) 16:09 (UTC)
- 顺便问一下加大字号和缩小字号在哪规定的。--Kuailong™ 2013年2月6日 (三) 05:11 (UTC)
- 无条件支持。--BlackLotux(留言) 2013年2月6日 (三) 14:09 (UTC)
- (!)意见:我倾向支持在中文维基不要使用斜体字的提案。关于文字染色的问题,在本讨论区上面就已经有提出过了,参与讨论者绝大部分都支持在内文中禁用非系统功能(内连结、空连结...)而产生的彩色字体,因此待讨论期结束后应会写入格式手册中实际执行。--泅水大象™ 讦谯☎ 2013年2月7日 (四) 02:44 (UTC)
- 是写在“文字格式”这部分么?乌拉跨氪 2013年2月7日 (四) 03:33 (UTC)
- 因为我的提案除了文字颜色问题外,也包含了小图示模板的滥用问题,原本有考虑是否要写在格式手册主页“不要花俏华丽”的段落中,但我也不反对放入文字格式分页,各位觉得呢?--泅水大象™ 讦谯☎ 2013年2月7日 (四) 03:40 (UTC)
- 文字颜色也可以算作是这里说的文字格式吧。另外,是否要把名字更改为“正文格式”?毕竟一些参考文献、外部链接、导航模板内文字等还是应当区别对待。--Kuailong™ 2013年2月7日 (四) 04:27 (UTC)
- 正文格式又可以有其他理解。 --达师 - 261 - 442 2013年2月7日 (四) 13:12 (UTC)
- 文字颜色也可以算作是这里说的文字格式吧。另外,是否要把名字更改为“正文格式”?毕竟一些参考文献、外部链接、导航模板内文字等还是应当区别对待。--Kuailong™ 2013年2月7日 (四) 04:27 (UTC)
- 因为我的提案除了文字颜色问题外,也包含了小图示模板的滥用问题,原本有考虑是否要写在格式手册主页“不要花俏华丽”的段落中,但我也不反对放入文字格式分页,各位觉得呢?--泅水大象™ 讦谯☎ 2013年2月7日 (四) 03:40 (UTC)
- 是写在“文字格式”这部分么?乌拉跨氪 2013年2月7日 (四) 03:33 (UTC)
- 将部分措辞与维基百科:格式手册/标点符号进行了统一。乌拉跨氪 2013年2月9日 (六) 05:47 (UTC)
- 下画线
-
- 指引中的下画线部分感觉很不具体,看完好像没办法了解能不能用下画线?ffaarr (talk) 2013年2月7日 (四) 09:45 (UTC)
- 大概是不能吧。 --达师 - 261 - 442 2013年2月7日 (四) 13:12 (UTC)
- 英文是不行:"Generally, do not underline text or it may be confused with links on a web page.",已增改内容,若不宜请回退:"...,所以一般情况下,不要用下划线。"--(研究维基v百度百科的hanteng✉) 2013年2月7日 (四) 16:29 (UTC)
- 大概是不能吧。 --达师 - 261 - 442 2013年2月7日 (四) 13:12 (UTC)
- 指引中的下画线部分感觉很不具体,看完好像没办法了解能不能用下画线?ffaarr (talk) 2013年2月7日 (四) 09:45 (UTC)
- 斜体
- 关于斜体的问题,在上面开了一个投票。乌拉跨氪 2013年2月7日 (四) 16:11 (UTC)
- (※)注意:我已增改内容,若不宜请回退:--(研究维基v百度百科的hanteng✉) 2013年2月7日 (四) 16:25 (UTC)
西文作品名(仅限于整段作品列表或书目,其余一般情况应以标点符号方式标明西文作品名)。
已超过一周没有任何其他意见,且参与讨论的维基人意见已经比较一致,通过为指引。 --达师 - 261 - 442 2013年2月17日 (日) 17:16 (UTC)
谢谢你达师努力和坚持。--(研究维基v百度百科的hanteng✉) 2013年2月20日 (三) 03:04 (UTC)
汗,监视页面看到修改才知道有过这个文字格式的讨论。我反对中文斜体。公交车站条目的行内图片我觉得可以接受,彩色文字我也可以接受。如果所说的禁止除infobox外的行内图片和彩色文字,我觉得太过严格了。斜体、下划线、彩色文字、行内图片,希望分开讨论。--Gqqnb(留言) 2013年3月10日 (日) 04:44 (UTC)
没有任何强调文本的办法,这不合理
在英文维基百科中,格式指引不允许使用''text''
(<i>text</i>
)或者'''text'''
(<b>text</b>
)做强调。这是因为HTML本身有专门用于表示强调的{{em|text}}
(<em>text</em>
),只有这一种用法才是语义正确的。通常在多数浏览器中,<em>text</em>
会被渲染成斜体,这就是所谓样式与内容分离。
然而在中文维基百科中,既禁止粗体,又禁止斜体,这就无法以任何方式强调文章内容。在下认为这是不合理的,较合理的解决方法可能是修改维基百科程序,让程序对中文的{{em|中文文本}}
以更合适的样式进行渲染,比如说另一种字体。或者也许可以善用中文标点符号,以着重号进行强调,并修改程序,让{{em|中文文本}}
遇到中文时,输出着重号。我搜索了一下,在W3C的邮件列表中,就讨论过用着重号渲染<em>中文</em>
的问题。然而,着重号在香港、台湾使用甚少或不是标点符号,并不是一个完全令人满意的方案。
如需强调内容,现在多是非正式地使用'''text'''
,但在下认为非常需要一种强调文字的正规方法,不知各位有何高见。— Bieraaa(查水表 / 送快递)于 世界统一时间 (UTC) 2017年6月8日01时20分 留言
提议修改Wikipedia:格式手册/文字格式#颜色及内联图像的内容
因为每个读者所使用的萤幕不一定是彩色萤幕或打印时所出现的结果不一定是彩色,我想直接修改Wikipedia:格式手册/文字格式#颜色及内联图像的内容,但User:Aotfs2013以未取得共识为由而被回退,所以想要征求一下社群意见,我提议修改Wikipedia:格式手册/文字格式#颜色及内联图像的内容如下:
|
|
--林勇智 2017年12月26日 (二) 10:59 (UTC)
- (+)支持,另外(&)建议:“打印纸本的结果是黑白”这句有点累赘,建议简化为“黑白印件”。--街燈電箱150號 开箱维修 抄表 检验证明 2017年12月26日 (二) 11:12 (UTC)
- (+)支持,我觉得可以滚雪球了,这种说明性文字还要来求共识???简直是为规则而规则的最佳示例。--Yangfl(留言) 2017年12月26日 (二) 11:36 (UTC)
- 方针与指引是已凝聚的社群共识的体现,本来就不应该根据自我认知扩大方针解释范围;要扩大方针与指引解释范围,应须经过充分凝聚共识。——Aotfs2013 留于 2017年12月27日 (三) 08:58 (UTC)
- 此条文立意很明显,公示讨论不会带来多少价值,满足“修改本文时请确保能够反映共识”。仅语句表达方面,公示讨论并不能“充分凝聚共识”,反而会催生多个版本(如目前情况),直接修改和在讨论页探讨更省时。--YFdyh000(留言) 2018年1月5日 (五) 18:00 (UTC)
- 方针与指引是已凝聚的社群共识的体现,本来就不应该根据自我认知扩大方针解释范围;要扩大方针与指引解释范围,应须经过充分凝聚共识。——Aotfs2013 留于 2017年12月27日 (三) 08:58 (UTC)
- 是否还有意见要发表?--林勇智 2018年1月1日 (一) 16:18 (UTC)
即起公示7日。——Aotfs2013 留于 2018年1月3日 (三) 13:46 (UTC)
- (+)支持修改。WP:雪球法则。(&)建议“方便色盲、色弱或使用黑白版本的读者阅读文字”。--YFdyh000(留言) 2018年1月5日 (五) 18:00 (UTC)
指引小修改‧格式手册(文字格式)
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
- 格式手册(文字格式),更合符中文语境。--J.Wong 2018年7月2日 (一) 07:06 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
客栈更新好快,今天才发现Wikipedia:互助客栈/方针/存档/2019年2月#修订WP:MOSBOLD已经存档了。于是再提修订WP:MOSBOLD,提案如下:
|
|
以上(笑)。Fire and Ice 2019年2月16日 (六) 17:34 (UTC)
- 上一次的反对留言,请各位继续讨论。赞成的部分我就不搬运了:--Temp3600(留言) 2019年2月17日 (日) 11:28 (UTC)
- (-)反对,千与千寻处可使用Help:列表#比较长的说明所描述的分号与冒号格式。粗体用于“作品和团体的人物列表”这样的表述较为含糊,易被滥用。--Wcam(留言) 2019年2月5日 (二) 15:35 (UTC)
- 分号冒号格式也是粗体,并无本质区别。另需指出,目前分号冒号格式在移动端有显示问题,将使定义和其说明文字处于同一缩进位置。不加“作品和团体的人物列表”也可以,但要指明适用粗体的“定义列表”是包括“人名列表”的。Fire and Ice 2019年2月5日 (二) 16:35 (UTC)
- “人名列表”仍然不合适,例如Category:中国各高校校友列表或是中华民国政府首脑列表等条目中,把每一个人名都使用粗体显然是完全没有必要的。应当对你认为可以使用粗体的情况提出一个准确的表述,我暂时想不出一个比较好的表述。--Wcam(留言) 2019年2月5日 (二) 20:01 (UTC)
- @Wcam、Fire-and-Ice:改成“虚构作品(小说、漫画、电影、剧集、戏剧等)的角色列表”如何? - まっすろな未来 2019年2月6日 (三) 01:58 (UTC)
- 即便是虚构作品的角色列表,也会有很多种较为复杂的情况,有必要进一步细分。例如西游记角色列表,当前版本中并非所有角色名称都使用粗体,对于描述较多的主要人物使用了章节标题,而众多非主要人物只有名称而没有或只有较少说明的,则没有也不需要使用粗体。--Wcam(留言) 2019年2月6日 (三) 04:32 (UTC)
- 鉴于Help:列表#比较长的说明指出:“若是说明部分太长的话,也请检讨使用标题分出一个章节来写”,个人意见认为,若是说明部分超过50字(50字是参照小小作品的标准),则建议使用级别较低的章节标题,否则不建议使用粗体。另可考虑修订WP:MOSFICT。--Wcam(留言) 2019年2月6日 (三) 04:54 (UTC)
- @Temp3600:这次似乎并没有提议修改人名列表或虚构角色列表?--Wcam(留言) 2019年2月17日 (日) 12:55 (UTC)
- 澄清“定义列表”的含义即可,无需叠床架屋。Fire and Ice 2019年2月17日 (日) 13:46 (UTC)
- 暂无异议。--Wcam(留言) 2019年2月19日 (二) 02:13 (UTC)
- 澄清“定义列表”的含义即可,无需叠床架屋。Fire and Ice 2019年2月17日 (日) 13:46 (UTC)
公示期间未见反对意见;通过。Σανμοσα五四运动百周年 2019年5月3日 (五) 10:31 (UTC)
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
简而言之:本修订旨在为禁止在条目当中的表格滥用背景颜色提供指引上的依据。
|
|
因应在VPD的两则讨论:Wikipedia:互助客栈/条目探讨/存档/2019年4月#香港条目内交通部分的疑问、Wikipedia:互助客栈/条目探讨/存档/2019年4月#条目内表格之杂乱底色,考虑到现行指引WP:MOSTEXT当中,只有对条目内的染色文字作出管制,对表格滥用背景色的问题存有明显漏洞,故此提出本草案。
以上。--无聊龙·留言·贡献香港图片愿望单征集中 2019年4月11日 (四) 06:56 (UTC)
- 我觉得此案仍然不够严格。我会建议表述为“只有在颜色确实是被描述对象的属性,而且有必要描述描述该颜色时,才可对表格或其他的内文元素加入背景颜色。” --Ujui Uju Mandan(留言) 2019年4月11日 (四) 07:44 (UTC)
- @UjuiUjuMandan:我还是认为如网页浏览器比较这样的比较列表仍然可以运用背景色来帮助表达,所以才把草案设定成这样。--无聊龙·留言·贡献香港图片愿望单征集中 2019年4月11日 (四) 09:26 (UTC)
- 我觉得一些表格改成可排序的表格会更好。对于用红绿色表示是否的我不反对。举例而言,我认为锡伯文#与满文字母的区别的表格里的颜色是不好的例子,应该以文字为表现形式,可以用不刺眼的表格填充色做辅助。 --Ujui Uju Mandan(留言) 2019年4月11日 (四) 09:35 (UTC)
- 我刚调淡了锡伯文#与满文字母的区别表格内的红色底色。Σανμοσα y=0 regardless the value of x 2019年4月13日 (六) 05:08 (UTC)
- 谢谢。我个人认为应当首先使用上标注释。因为维基百科的内容不仅要允许色盲来读,也要允许使用黑白印刷。单元格背景色可以是锦上添花,但不能作为主要的标注形式。 --Ujui Uju Mandan(留言) 2019年4月16日 (二) 14:30 (UTC)
- 我刚调淡了锡伯文#与满文字母的区别表格内的红色底色。Σανμοσα y=0 regardless the value of x 2019年4月13日 (六) 05:08 (UTC)
- 我觉得一些表格改成可排序的表格会更好。对于用红绿色表示是否的我不反对。举例而言,我认为锡伯文#与满文字母的区别的表格里的颜色是不好的例子,应该以文字为表现形式,可以用不刺眼的表格填充色做辅助。 --Ujui Uju Mandan(留言) 2019年4月11日 (四) 09:35 (UTC)
- 关于图片使用,建议参考一下mw:Recommendations for mobile friendly articles on Wikimedia wikis#Limit number of images in a page:有大量图像的页面可能在移动设备上加载超时,一个页面上的图片超过1万张,该页面将无法在移动设备上打开。给出的建议是,理想状况下一个页面中图片不要超过100张,对于表格中大量使用的示意性图片,可以考虑用表情符号或unicode字符代替--百無一用是書生 (☎) 2019年4月16日 (二) 02:52 (UTC)
- @UjuiUjuMandan:我还是认为如网页浏览器比较这样的比较列表仍然可以运用背景色来帮助表达,所以才把草案设定成这样。--无聊龙·留言·贡献香港图片愿望单征集中 2019年4月11日 (四) 09:26 (UTC)
- 现就上述提案公示七天,如期间无反对意见,即予以实行。--无聊龙·留言·贡献香港图片愿望单征集中 2019年4月24日 (三) 13:11 (UTC)
- 目前提出的的说法似乎和mw:Recommendations for mobile friendly articles on Wikimedia wikis#Limit number of images in a page的说法存在不一致的情况?“条目正文中,禁止使用内联图像(例如在文字中出现这样图像),但若在表格及信息框中使用则是可以接受的。”而mw:Recommendations for mobile friendly articles on Wikimedia wikis#Limit number of images in a page则认为“理想状况下一个页面中图片不要超过100张,对于表格中大量使用的示意性图片,可以考虑用表情符号或unicode字符代替”--百無一用是書生 (☎) 2019年4月25日 (四) 07:03 (UTC)
- 我认为两者没有冲突。而且目前着眼要修改的是禁止滥用表格底色的条文,对于是否需要禁止表格内使用过多图像,我认为可以稍后再议。--无聊龙·留言·贡献香港图片愿望单征集中 2019年4月25日 (四) 10:05 (UTC)
- 目前提出的的说法似乎和mw:Recommendations for mobile friendly articles on Wikimedia wikis#Limit number of images in a page的说法存在不一致的情况?“条目正文中,禁止使用内联图像(例如在文字中出现这样图像),但若在表格及信息框中使用则是可以接受的。”而mw:Recommendations for mobile friendly articles on Wikimedia wikis#Limit number of images in a page则认为“理想状况下一个页面中图片不要超过100张,对于表格中大量使用的示意性图片,可以考虑用表情符号或unicode字符代替”--百無一用是書生 (☎) 2019年4月25日 (四) 07:03 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
外文粗体
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
想问一下社群对于外文粗体的使用上有没有任何先前共识/规定?Σανμοσα y=0 regardless the value of x 2019年4月13日 (六) 00:25 (UTC)
- 电子游戏相关模板内的外文通常都是不加粗体的(不过简称我个人会予以加粗,Ex. 任天堂DSi)。—— Eric Liu(留言.留名.学生会.CUCC) 2019年4月13日 (六) 03:08 (UTC)
- 参考记录,格式手册曾于2014年经简单讨论后,外文粗体被人移去,但同年稍后的深入讨论,社群对外文粗体没有最终共识。--Clithering(MMXIX) 2019年4月13日 (六) 05:41 (UTC)
- 查,社群对于外文粗体的使用上在当时似乎没有后续讨论,当时“接续较早前讨论”所标示的较早前讨论错误(已更正 at 2019年4月13日 (六) 06:28 (UTC))。Σανμοσα y=0 regardless the value of x 2019年4月13日 (六) 06:24 (UTC)
- 不要粗体。本来外文就看不清,部分字体还特别小(比如藏文为了上下加字而不得不使用小字体),加粗就更看不清了。另外外文使用粗体违反了命名原则的使用中文方针。08、09年那会都不加粗体的,后来不知何时一批人开始给外文加粗体。--173.68.165.114(留言) 2019年4月13日 (六) 05:50 (UTC)
- 提醒楼上:《命名常规方针》不规范条目内容。Σανμοσα y=0 regardless the value of x 2019年4月13日 (六) 05:59 (UTC)
- 同意,但粗体标识的是名称,所以命名原则适用。不过您后面要求只在中文中常用的加粗,就没有问题了。--173.68.165.114(留言) 2019年4月18日 (四) 03:24 (UTC)
- 大家也可参考Wikipedia:格式手册/序言章节#外语名称(非方针指引)。Σανμοσα y=0 regardless the value of x 2019年4月13日 (六) 05:59 (UTC)
- 这其实应视乎那个外文名在中文话语里常不常被直接使用而定,以档案传输协定条目为例,日常说中文时大多不会直接说“File Transfer Protocol”,所以“File Transfer Protocol”不会整个加粗,但“FTP”在日常说中文时也很多时被直接用,所以加粗“FTP”。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月13日 (六) 11:45 (UTC)
- 注:此意见和Ericliu1912相近(Ericliu1912在任天堂DSi里加粗了DSi)。Σανμοσα y=0 regardless the value of x 2019年4月13日 (六) 13:56 (UTC)
- 我想到几个涉及外文的情况:
- 外文名在中文环境中属于最常用名称(例如Facebook:“Facebook(简称FB)是源于……”中的“Facebook”);
- 外文名在中文环境中属于较常用简称/缩略写法,例如:
- 外文名在中文环境中不属于常用名称(例如陈纲 (清朝外交官):“陈纲(西班牙语:Engracio Palanca,1871年-?),字紫衍,祖籍……”中的“Engracio Palanca”);
- 以上,其中2b与2a的不同之处在于2b会为外文全称中对应缩写字母的外文字首加粗;另外1通常无异议。Σανμοσα y=0 regardless the value of x 2019年4月13日 (六) 14:24 (UTC)
- 2b的例子换做ICAC会比较好,不常看到香港的文字媒体把消防处直接呼为HKFSD,但是经常都看到把廉政公署直接呼为ICAC。另外还有一个例子是英格兰联赛杯,无论外文的全名、缩写、简称都不常出现于中文环境,所以全部都不加粗。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月13日 (六) 15:43 (UTC)
- 也可改成超文本传输协定(HTTP)。—— Eric Liu(留言.留名.学生会.CUCC) 2019年4月13日 (六) 16:04 (UTC)
- @Cdip150:我当时选用了HKFSD是因为“Hong Kong Fire Services Department”中的五个字首都被粗体,以对应缩写(ICAC没有这样的效果)。我把例子改为Ericliu1912的HTTP。Σανμοσα y=0 regardless the value of x 2019年4月13日 (六) 23:37 (UTC)
- 2b的例子换做ICAC会比较好,不常看到香港的文字媒体把消防处直接呼为HKFSD,但是经常都看到把廉政公署直接呼为ICAC。另外还有一个例子是英格兰联赛杯,无论外文的全名、缩写、简称都不常出现于中文环境,所以全部都不加粗。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月13日 (六) 15:43 (UTC)
- 或许我把这个大话题收窄为几个问题,希望大家能够回答:
- 你是否认同2a对于简称/缩略写法的加粗?
- 如果上题的答案为“是”,则你是否也认同2b的首字母加粗?
- 你是否认同应该把3的外文加粗?
- 以上。我个人的回答是:1.是;2.否;3.否。Σανμοσα y=0 regardless the value of x 2019年4月14日 (日) 03:38 (UTC)
- 1.赞成;2.基本不赞成。显而易见的缩写法一望而知,不显而易见的缩写法较难提供可靠来源印证(所以可能提供的就是错的。若有来源,宜在正文中介绍),维基源码和呈现效果也有点乱。3.不赞成。--YFdyh000(留言) 2019年4月15日 (一) 03:04 (UTC)
- 1. 是;2. 否;3. 否。—— Eric Liu(留言.留名.学生会.CUCC) 2019年4月15日 (一) 10:41 (UTC)
- 1.还要细分情况:(a)如果缩写是中文环境常用的(如档案传输协定的FTP),是;(b)如果缩写是中文环境不常用的(如欧洲冠军联赛的UCL),否。2.中立。3.否。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月16日 (二) 00:54 (UTC)
- 我还想追加两个问题:
- 4.如果有人将2a中对于简称/缩略写法的加粗去除了,是否应该恢复加粗?
- 5.如上题的答案是“否”,则如果有另一人恢复了加粗,是否应该取消该恢复加粗?
- 以上;我个人的回答是:4.否;5.是。Σανμοσα y=0 regardless the value of x 2019年4月18日 (四) 00:09 (UTC)
- (!)意见:原则上同意1和2a,2b不同意但不介意下划线,3绝对不行。但是不同意Sanmosa所举的例子:FB从未在中文环境正式场合中被广泛用过,都不应该进入首段。HTTP这类简写绝对可以粗体,但粗体后不应出现在括号中。不建议任何括号中的文字加粗。加粗的一定是中文中常用的名称,与被加粗的文字属性(汉字、拉丁字母、西里尔字母、拼音如duang、注音文、藏文字头)无关,符合中文常用名称就行。
- 不过我同意对于原创中文译名的条目(听说维基百科中如果一个条目完全没有中文译名翻译可以自造一个),加粗相应外文(如高棉文)。但当该中文译名被广泛流传之后(如找到该名称被外不可靠来源引用三次),则去除该加粗。--173.68.165.114(留言) 2019年4月18日 (四) 03:24 (UTC)
- “FB”在Google新闻搜索的结果,我不说其他话了。Σανμοσα y=0 regardless the value of x 2019年4月19日 (五) 14:37 (UTC)
- 多是英文结果,而且大量的FB与Facebook无关。如果限定中文呢?如果真有很多那可能是我out了。--173.68.165.114(留言) 2019年4月21日 (日) 00:43 (UTC)
- @Sanmosa:多是外文语境。如果FB也要列于序言乃至加粗,脸书、脸谱网是否也要呢。--YFdyh000(留言) 2019年4月20日 (六) 05:37 (UTC)
- 为啥我找到的是香港中文媒体?(当然,我不反对只保留“Facebook”;“脸书”其实可以加入,“脸谱网”没怎听过。)Σανμοσα y=0 regardless the value of x 2019年4月20日 (六) 07:19 (UTC)
- “脸书”、“脸谱”、“非死不可”、“FB”我都祗在非正式语境听说过。如果要加的话都加上吧,不过个人觉得没太大必要,可以单独放在一个《名称》章节里,而且“脸书”一词明显是conlang,“面簿”倒是中文,可惜没“脸书”常用。呃……跑题了。我提这件事的目的是说我对这个模式的赞同不代表我赞同具体的示例,并不想真的去讨论那个条目。--173.68.165.114(留言) 2019年4月21日 (日) 00:47 (UTC)
- “FB”在Google新闻搜索的结果,我不说其他话了。Σανμοσα y=0 regardless the value of x 2019年4月19日 (五) 14:37 (UTC)
建议修订
a. Wikipedia:格式手册/文字格式建议修改如下:
|
b. Wikipedia:格式手册建议修改如下:
|
|
c. Wikipedia:格式手册/传记建议(i)通过“非中文人名”部分为指引,并(ii)修改如下:
|
|
d. Wikipedia:格式手册/序言章节#外语名称建议(i)通过为指引,并(ii)修改如下:
|
|
以上为本人建议的指引新增及修订。Σανμοσα y=0 regardless the value of x 2019年4月22日 (一) 13:23 (UTC)
- @Ericliu1912、Clithering、Cdip150、YFdyh000:以上各提案并不捆绑,各位可以为各提案【即a、b、ci、cii、di和dii】分别给予意见。Σανμοσα y=0 regardless the value of x 2019年4月22日 (一) 14:23 (UTC)
- WP:格式手册/序言章节#外语名称不应删除 Chernivets’ka oblast’,能否列出罗马化字并非今次讨论的范围,请勿僭越。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月22日 (一) 14:46 (UTC)
- WP:ITALIC。Σανμοσα y=0 regardless the value of x 2019年4月22日 (一) 14:57 (UTC)
- 即使如此,顶多只可取消斜体,但不能整个字删除。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月22日 (一) 15:11 (UTC)
- 完成。Σανμοσα y=0 regardless the value of x 2019年4月23日 (二) 00:16 (UTC)
请阅 - 即使如此,顶多只可取消斜体,但不能整个字删除。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月22日 (一) 15:11 (UTC)
- WP:ITALIC。Σανμοσα y=0 regardless the value of x 2019年4月22日 (一) 14:57 (UTC)
- WP:格式手册/序言章节#外语名称不应删除 Chernivets’ka oblast’,能否列出罗马化字并非今次讨论的范围,请勿僭越。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月22日 (一) 14:46 (UTC)
- (!)意见 a: 不懂为何这么做,其他条目的正文中也加粗,只因它有一个条目?应该是加内链吧。“属于非人名的常用简称/缩略写法”同上,PVC(等等)吗。第二句“除非该外文是中文维基百科中所属条目的名称,否则任何人不得撤销移除外文加粗的编辑。”很绕,是不能回退“取消加粗”的编辑吧,既如此强硬,为何要鼓励/可根据...予以加粗。b: 先解决A的问题。c: “本语言”很难懂,我想改掉,
母语行么。建议“除非其母语名称是中文维基百科现行条目的名称,否则不可为该名字加粗”。有点瑕疵是,条目/现行条目可能是无关的同名条目。“除非其外文名称是其在中文维基百科的条目的现行名称,否则不可为该名字加粗”如何。d: 暂无意见。--YFdyh000(留言) 2019年4月23日 (二) 02:40 (UTC)- Facebook条目内加粗。PVC确实是其中一种例子,上面提及过的DSi也是一例。确实是不能回退取消外文加粗的编辑,因为外文加粗是不必要的(除非该外文在中文环境中已被人如同中文般使用,例如Facebook、Windows)。c:条文的问题大致上和a一样;已修改,效果和a差不多。Σανμοσα y=0 regardless the value of x 2019年4月23日 (二) 04:40 (UTC)
- 好多了。“...在对应外文完整称呼中的字母...”仔细看才懂,希望进一步简化、阐明或举例,比如说“外文全称的缩略写法字母不应单独加粗”。格式手册是指引,“任何人不得撤销”语气偏硬,效力不该那么强,“不得”都应该是“不应”。对当前草案仍有疑虑,一般来说,非序言中很少用加粗吧,当前条文似乎未做限定。--YFdyh000(留言) 2019年4月23日 (二) 07:11 (UTC)
- 完成。Σανμοσα y=0 regardless the value of x 2019年4月23日 (二) 08:37 (UTC)
a:条文已修改,现在的意思大概是“Facebook”只能在 - 好多了。“...在对应外文完整称呼中的字母...”仔细看才懂,希望进一步简化、阐明或举例,比如说“外文全称的缩略写法字母不应单独加粗”。格式手册是指引,“任何人不得撤销”语气偏硬,效力不该那么强,“不得”都应该是“不应”。对当前草案仍有疑虑,一般来说,非序言中很少用加粗吧,当前条文似乎未做限定。--YFdyh000(留言) 2019年4月23日 (二) 07:11 (UTC)
- Facebook条目内加粗。PVC确实是其中一种例子,上面提及过的DSi也是一例。确实是不能回退取消外文加粗的编辑,因为外文加粗是不必要的(除非该外文在中文环境中已被人如同中文般使用,例如Facebook、Windows)。c:条文的问题大致上和a一样;已修改,效果和a差不多。Σανμοσα y=0 regardless the value of x 2019年4月23日 (二) 04:40 (UTC)
- 现将以上修订公示七日。Σανμοσα y=0 regardless the value of x 2019年4月27日 (六) 06:49 (UTC)
- (-)反对,条文讨论时间过少(一周都没有),难以确保共识,况且上面已经有一个异议出了来正深入讨论中,现在公示根本不是时候。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月27日 (六) 10:52 (UTC)
- 现告暂时停止公示。Σανμοσα y=0 regardless the value of x 2019年4月28日 (日) 10:29 (UTC)
- (-)反对,条文讨论时间过少(一周都没有),难以确保共识,况且上面已经有一个异议出了来正深入讨论中,现在公示根本不是时候。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月27日 (六) 10:52 (UTC)
外文全称的缩略写法字母是否应该单独加粗
以下是我的综合意见:
- (-)反对“Hyper Text Transfer Protocol”这种单字母加粗的显示。
- 关于(b)例出的例子,建议顺道把“lang|en”模版改为事实上更常用的“lang-en”模版。同时,生卒日期应嵌入“bd”模版。“是中国近代民主革命家”和“是英国著名物理学家”应去除赘言,分别改成“,中国近代民主革命家”和“,英国物理学家”。另外,应参考社群当年投票,在霍金姓名后加入勋衔。
- 关于(c)的例子,一个是外语人名,另一个是汉化人名,两个例子均应保留。
谢谢。--Clithering(MMXIX) 2019年4月25日 (四) 15:44 (UTC)
- @Clithering:c那部分阁下错重点了,重点只在外语粗体,外语人名是否汉化并非重点;既然样式统一,则只留一例更宜。b那部分届时可直接事实性修订。Σανμοσα y=0 regardless the value of x 2019年4月26日 (五) 10:44 (UTC)
- 谢谢你的回应,我当初认为两个例子都应该保留,是因为一个例子是汉化译名,另一个不是;而一个有爵位,另一个没有。两个例子并存,可让读者知道不同情况下的外文所有部分皆无需加粗。不过,我察觉到现在“费雯丽”的例子好像改了,但改得不太合适。其一:她的头衔是“奥利花爵士夫人”,不是“奥利花男爵夫人”;其二:根据社群共识,名称应作“奥利花爵士夫人费雯丽”,而不是把爵位置于名称之后。同时,“费雯丽”另一译名是“慧云李”;“奥利花”另一译名是“奥立维耶”。如是观之,“费雯丽”这个例子过于复杂,不应采用。如要引用一个较简明直接的汉化译名例子显示外文姓名无需加粗,我建议可用魏璐诗。--Clithering(MMXIX) 2019年4月29日 (一) 15:27 (UTC)
- “费雯·丽”这个例子其实是典型外地相关条目的一例,通常外地相关条目都必定会应用{{noteTA}},所以我不认为此例太复杂。语序方面已经修正。Σανμοσα y=0 regardless the value of x 2019年4月30日 (二) 11:10 (UTC)
- (:)回应,主要问题已修正,现况尚可接受。--Clithering(MMXIX) 2019年4月30日 (二) 11:15 (UTC)
- “费雯·丽”这个例子其实是典型外地相关条目的一例,通常外地相关条目都必定会应用{{noteTA}},所以我不认为此例太复杂。语序方面已经修正。Σανμοσα y=0 regardless the value of x 2019年4月30日 (二) 11:10 (UTC)
- 谢谢你的回应,我当初认为两个例子都应该保留,是因为一个例子是汉化译名,另一个不是;而一个有爵位,另一个没有。两个例子并存,可让读者知道不同情况下的外文所有部分皆无需加粗。不过,我察觉到现在“费雯丽”的例子好像改了,但改得不太合适。其一:她的头衔是“奥利花爵士夫人”,不是“奥利花男爵夫人”;其二:根据社群共识,名称应作“奥利花爵士夫人费雯丽”,而不是把爵位置于名称之后。同时,“费雯丽”另一译名是“慧云李”;“奥利花”另一译名是“奥立维耶”。如是观之,“费雯丽”这个例子过于复杂,不应采用。如要引用一个较简明直接的汉化译名例子显示外文姓名无需加粗,我建议可用魏璐诗。--Clithering(MMXIX) 2019年4月29日 (一) 15:27 (UTC)
- 补充:指引页面不能用{{bd}},否则会造成错误分类。Σανμοσα y=0 regardless the value of x 2019年4月27日 (六) 07:27 (UTC)
- @Clithering:c那部分阁下错重点了,重点只在外语粗体,外语人名是否汉化并非重点;既然样式统一,则只留一例更宜。b那部分届时可直接事实性修订。Σανμοσα y=0 regardless the value of x 2019年4月26日 (五) 10:44 (UTC)
- 我非常(+)支持“Hyper Text Transfer Protocol”这种单字母加粗的显示,但应该在之后有表述缩写“HTTP”,这样很容易辨别一个缩写是如何缩的(并不是所有的缩写都是取首字母或每个单词的首字母)--百無一用是書生 (☎) 2019年4月26日 (五) 03:06 (UTC)
- (:)回应,把“Hypertext”单词硬分拆成“Hyper Text”,分明就是矫枉过正。再者,环顾其他语文版本的维基百科,也不见有类似需要和安排。按照外文粗体如此有用的说法,岂不是回归基本赞成全面的外文粗体?又应否连中文也要显示为“联合国安全理事会”?--Clithering(MMXIX) 2019年4月26日 (五) 05:06 (UTC)
- 我认为这种标注一来不太美观(有点眼花,网页亲和力也不佳),二来很容易原创研究——绝大多数都没有脚注印证缩写法,可能不少是第一印象标注,有些还有争议或谬误。而如果有来源具体讲过缩写法,那就值得写入正文章节。--YFdyh000(留言) 2019年4月26日 (五) 14:39 (UTC)
- 不知道书生对以上留言有没有进一步回应?至于街灯与Ericliu1912对于外文全称的缩略写法字母是否应该单独加粗的看法,依照上方的讨论的立场分别是中立与否定,不过也想问问有没有进一步解释?Σανμοσα y=0 regardless the value of x 2019年4月28日 (日) 13:28 (UTC)
- 正反两方的意见都不无道理,我想等至少一周再听取他们更多的意见后再行评估是否改变立场。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月29日 (一) 01:57 (UTC)
- 我会倾向允许讨论至少五日,如果五日后未有任何其他支持外文全称缩略写法字母单独加粗的意见的话,我就会结束讨论,因为以我所见,大部分人都对于外文加粗较为反感。不过如果有其他支持外文全称缩略写法字母单独加粗的意见,讨论则会延长。Σανμοσα y=0 regardless the value of x 2019年4月29日 (一) 09:08 (UTC)
- 正反两方的意见都不无道理,我想等至少一周再听取他们更多的意见后再行评估是否改变立场。--街燈電箱150號 开箱维修 抄表 检验证明 2019年4月29日 (一) 01:57 (UTC)
- (-)反对理由:“བཀྲ་ཤིས་བདེ་ལེགས་”对比不加粗:“བཀྲ་ཤིས་བདེ་ལེགས་”。--173.68.165.114(留言) 2019年4月29日 (一) 07:24 (UTC)
- 又如:“حركة المقاومة الاسلامية”对比不加粗:“حركة المقاومة الاسلامية”。--173.68.165.114(留言) 2019年4月29日 (一) 07:28 (UTC)
- (+)支持:我不觉得“Hyper Text Transfer Protocol”有问题,我认为很美观,而且清楚辨识,但是为了避免原创研究应该要求附加来源证明。--Opky9407(留言) 2019年5月1日 (三) 19:40 (UTC)
- Σανμοσα y=0 regardless the value of x 2019年5月2日 (四) 08:30 (UTC)
- 很多外文已加粗就排版错乱了(甚至更惨,像阿拉伯文那样,完全不可读),但是如果只给英文加粗就破坏了中立性原则。--173.68.165.114(留言) 2019年5月4日 (六) 03:20 (UTC)
- 当然这种情况一般不会出现(中文中唯一像HTML那样穿插阿拉伯文作为常用名称使用的几乎祗有“حلال”一词,而这不是个简称),藏文中简称一般不会采用首字母模式,但是还是要防患于未然——除非针对针对每个Unicode区块都验证一遍这类现象不会发生,才可以放心地把缩写加粗写入。--173.68.165.114(留言) 2019年5月4日 (六) 03:26 (UTC)
- 既然这种简称很罕有的话,就不用考虑,如果真的出现的话可以当例外处理。--Opky9407(留言) 2019年5月6日 (一) 13:37 (UTC)
- IP所提出的“只给英文加粗就破坏了中立性原则”问题还是没有解决,而且要立下例外还需要经过共识。Σανμοσα五四运动百周年 2019年5月7日 (二) 09:26 (UTC)
- 既然这种简称很罕有的话,就不用考虑,如果真的出现的话可以当例外处理。--Opky9407(留言) 2019年5月6日 (一) 13:37 (UTC)
那IP举出的加粗例子如何?(假设有来源)
- Σανμοσα y=0 regardless the value of x 2019年5月2日 (四) 08:30 (UTC)
恢复公示
由于支持外文全称缩略写法字母单独加粗者在被要求回应的三日后仍没有回应,现恢复公示,自此刻起为时七日。Σανμοσα五四运动百周年 2019年5月6日 (一) 10:28 (UTC)
- (-)反对:Wikipedia:格式手册/传记里包含了外文粗体之外的其它内容,我们这里只在针对粗体讨论,其它的部分没有讨论,所以不能整个作为指引。--Opky9407(留言) 2019年5月6日 (一) 13:45 (UTC)
- 已收窄c部的建议通过范围(修改范围不影响)。Σανμοσα五四运动百周年 2019年5月7日 (二) 09:23 (UTC)
- 由于提议修订的主要部分(a部分)出现变化,现重新公示七日。Σανμοσα以有涯随无涯,殆已! 2019年5月11日 (六) 10:36 (UTC)
- 翻了半天不知道公示的到底是什么内容?--百無一用是書生 (☎) 2019年5月14日 (二) 02:23 (UTC)
- “建议修订”节下列的a、b、c、d四部分。Σανμοσα以有涯随无涯,殆已! 2019年5月15日 (三) 00:09 (UTC)
- (-)反对d部分,重新评估过后,Wikipedia:格式手册/序言章节#外语名称也是包含了外文粗体之外的其它内容,所以整节也不能做分段指引,再者,那些罗马斜体应该没有违反Wikipedia:格式手册/文字格式#不要用斜体来作强调,所以也不应取消,故只能改d部分的最后一段,且毋须成为指引。--街燈電箱150號 开箱维修 抄表 检验证明 2019年5月17日 (五) 14:25 (UTC)
- 恢复斜体方面接受,其他不接受。Wikipedia:格式手册/文字格式本来就已有针对斜体的规限,而该节其余内容皆未违逆Wikipedia:格式手册#条目定义句,通过符合且大意上重复既有指引的条文本无不可,以此反对此部分通过必定导致有人会以非方针指引反对执行指引(例如这次我提出修例就是因为Clithering以现时非方针指引的Wikipedia:格式手册/传记反对执行Wikipedia:格式手册中去粗体的规定),通过之为指引是为了强化既有指引的有效性(例如此修订就是为了强化Wikipedia:格式手册中去粗体的规定的有效性)。老实说,即使那一部分我不通过为指引,因为那部分并非社群共识,所以我其实可以随意修改内容(我改得面目全非也可以),最终我还是能够达到修订的目的。Σανμοσα以有涯随无涯,殆已! 2019年5月18日 (六) 02:30 (UTC)
- d部分的其他内容不是关于粗体,故已掉出本讨论,自然其他内容会在无共识下成为指引。再者,您要令外文粗体的规则能被有效执行,那其实只需要修改a和b部分就足以达成(c部分是否适当我还在疑惑中),反对者至少不可能因为d部分不是指引而阻止消粗。的确,应该做的是a和b部分通过更改后,d部分的确可免讨论改最后一段。(还有Wikipedia:格式手册原有的规条根本没有明文禁止外文粗体,没有列举外文粗体例子并不代表不可用粗,所以拿Clithering的情况来说并不适当)--街燈電箱150號 开箱维修 抄表 检验证明 2019年5月18日 (六) 08:08 (UTC)
- 我可以暂缓c、d两部分的通过。Σανμοσα以有涯随无涯,殆已! 2019年5月18日 (六) 10:31 (UTC)
- d部分的其他内容不是关于粗体,故已掉出本讨论,自然其他内容会在无共识下成为指引。再者,您要令外文粗体的规则能被有效执行,那其实只需要修改a和b部分就足以达成(c部分是否适当我还在疑惑中),反对者至少不可能因为d部分不是指引而阻止消粗。的确,应该做的是a和b部分通过更改后,d部分的确可免讨论改最后一段。(还有Wikipedia:格式手册原有的规条根本没有明文禁止外文粗体,没有列举外文粗体例子并不代表不可用粗,所以拿Clithering的情况来说并不适当)--街燈電箱150號 开箱维修 抄表 检验证明 2019年5月18日 (六) 08:08 (UTC)
- 恢复斜体方面接受,其他不接受。Wikipedia:格式手册/文字格式本来就已有针对斜体的规限,而该节其余内容皆未违逆Wikipedia:格式手册#条目定义句,通过符合且大意上重复既有指引的条文本无不可,以此反对此部分通过必定导致有人会以非方针指引反对执行指引(例如这次我提出修例就是因为Clithering以现时非方针指引的Wikipedia:格式手册/传记反对执行Wikipedia:格式手册中去粗体的规定),通过之为指引是为了强化既有指引的有效性(例如此修订就是为了强化Wikipedia:格式手册中去粗体的规定的有效性)。老实说,即使那一部分我不通过为指引,因为那部分并非社群共识,所以我其实可以随意修改内容(我改得面目全非也可以),最终我还是能够达到修订的目的。Σανμοσα以有涯随无涯,殆已! 2019年5月18日 (六) 02:30 (UTC)
- (?)疑问:a部分的规定跟直接禁止第2类做法有什么差别?只要移除了便不能撤销,即NDSi是可以的,但被改为NDSi便不可改回粗体,这个完全是矛盾的规条,所以(-)反对。--Opky9407(留言) 2019年5月18日 (六) 10:10 (UTC)
- Σανμοσα以有涯随无涯,殆已! 2019年5月18日 (六) 10:31 (UTC) 我在上面也强调过了:一般而言,外文粗体是不被鼓励的,所以才订了如此的规则。最理想的情况下是尽可能避免外文粗体,1和3就是不可避免的情况;社群对于外文加粗的普遍态度是颇为负面的。
- 我就此点再作出较为详细的说明:我之所以会设定这样的规则,目的就是为了最终达到直接禁止二类粗体,但为了避免社群以后一看到二类粗体就急于移除,我设定了这样的规则,这样大家看到二类粗体也不用太在意,喜欢移除就移除,喜欢保留就保留,但移除了就不要再加粗。长久下去,当到了一定的时候,就可以改为直接禁止。Σανμοσα以有涯随无涯,殆已! 2019年5月20日 (一) 10:36 (UTC)
- 第2点上面的共识根本是同意加粗简写,允许移除是明显违反共识的。--Opky9407(留言) 2019年5月21日 (二) 09:32 (UTC)
- Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 09:36 (UTC)
- 这当然违反共识,允许某做法自然不同意允许移除。--Opky9407(留言) 2019年5月21日 (二) 09:42 (UTC)
- 对不起,两者并没有必然的因果关系。允许粗体并不代表不允许移除,只允许粗体才是。基于该用户的逻辑能力不能使人信服,我决定不接受该用户的意见。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 09:47 (UTC)
- 效果上当然有关系,允许粗体就应同时允许恢复粗体,不允许恢复粗体和允许粗体明显有冲突。--Opky9407(留言) 2019年5月21日 (二) 09:51 (UTC)
- Opky9407“搬龙门”了。我们起初是谈共识,现在突然改为谈效果,究竟阁下想谈些什么?Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 09:58 (UTC)
- “允许粗体”是“允许暂时保留现有粗体”,但最终目标仍是“减少、杜绝粗体”。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 09:58 (UTC)
- 效果上当然有关系,允许粗体就应同时允许恢复粗体,不允许恢复粗体和允许粗体明显有冲突。--Opky9407(留言) 2019年5月21日 (二) 09:51 (UTC)
- 上面YFdyh000曾经对允许移除但不允许恢复二类粗体向我提出了疑问,而他最终接受了我的解释。至于其他人在看了整个条文也从来没对于我这一点有任何疑问或异议,那就代表他们接受这个做法。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 09:58 (UTC)
- 共识和效果都一起说,根本看不到共识是暂时允许,我理解是永远允许,根本没有人对简写粗体反感。--Opky9407(留言) 2019年5月21日 (二) 10:15 (UTC)
- Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:26 (UTC) 如果你打算共识和效果都一起说的话,我希望你可以把这两部分分开处理,否则我不认为我能够和你有有效的沟通。另外,共识方面的问题已在下方处理,我认为你至少不会反对后备方案。
- 共识和效果都一起说,根本看不到共识是暂时允许,我理解是永远允许,根本没有人对简写粗体反感。--Opky9407(留言) 2019年5月21日 (二) 10:15 (UTC)
- 对不起,两者并没有必然的因果关系。允许粗体并不代表不允许移除,只允许粗体才是。基于该用户的逻辑能力不能使人信服,我决定不接受该用户的意见。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 09:47 (UTC)
但其他人对于移除之并没有提出异议,可以认为这得到了沉默共识许可,所以并不违反共识。对不起,由于你的编辑造成了编辑冲突,我会把你的留言置于archive bottom外。 - 这当然违反共识,允许某做法自然不同意允许移除。--Opky9407(留言) 2019年5月21日 (二) 09:42 (UTC)
- Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 09:36 (UTC)
- 我对于Opky9407执意曲解共识并强行阻止新指引通过的行径深表遗憾。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 09:59 (UTC)
- @Clithering、Ericliu1912、YFdyh000:我要求三位协助判断我所解读的共识是否正确。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:05 (UTC)
- 我重开了讨论,首先是当有人在关闭前提出异议,无论如何都应该继续讨论让人评估合理性,而不是自认为其不合理而强迫结束通过。二来是上面有人提到公示的内容混乱,应当重新整理修改内容的最终型态重新公示。--街燈電箱150號 开箱维修 抄表 检验证明 2019年5月21日 (二) 10:07 (UTC)
- 反对说法2。我认为目前的公示形态非常清楚;任何人找不到章节的话,我可以和他说在哪一个位置(其实也只有一个位置而已)。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:21 (UTC)
- “翻了半天不知道公示的到底是什么内容?”您解答之后又因为后续讨论取消了一部分,各个改变主意的动作如此分散,当然应该再把修改内容再公示一次让大家更清楚易懂吧!--街燈電箱150號 开箱维修 抄表 检验证明 2019年5月21日 (二) 10:28 (UTC)
- Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:35 (UTC) 事实上我并没有取消任何一部分,我仍然是提议把c、d两部分的相关部分的修订,我只是不再要求把c、d两部分的相关部分作为指引(这也意味着把c、d两部分的相关部分的修订并不需要共识)。我可以重新张贴公示内容,但我会视之为延长公示期,而不是重新进行公示。
- “翻了半天不知道公示的到底是什么内容?”您解答之后又因为后续讨论取消了一部分,各个改变主意的动作如此分散,当然应该再把修改内容再公示一次让大家更清楚易懂吧!--街燈電箱150號 开箱维修 抄表 检验证明 2019年5月21日 (二) 10:28 (UTC)
- 针对说法1,如果Cdip150也希望就我是否正确解释讨论共识这个议题发表意见的话,我也欢迎阁下就此发表意见。如果其他人多数也认为我正确地解释了共识的话,我会再自行以通过结案;但我其实也有不禁止恢复二类粗体的后备方案,如果社群认为他们的意见是不禁止恢复二类粗体的话,我就会改为通过后备方案,因为其他部分并无人提出异议(注:我不会通过ci、di部分)。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:21 (UTC)
- @Sanmosa:“仍不应被撤销”就“指引”效力和自由编辑来说,是过强了一些,且单方面、理由不充分地限制。且我想了好久才明白它想表达什么,如果“属于非人名的常用简称/缩略写法”(如KFC、FBI)通常不应、不必要或可选加粗,建议明确约束(如“广泛使用、代用”)或者不要约束(如“也可不加粗以利版面整洁”)。该第二类是否该加粗,我也没想好,不加粗美观些,加粗也许对SEO和机器人维护(至少“ToolsRedirect”工具…)有些好处。--YFdyh000(留言) 2019年5月21日 (二) 10:29 (UTC)
- Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:49 (UTC)
- 是的,可以。--YFdyh000(留言) 2019年5月21日 (二) 10:55 (UTC)
请问我是否可以把你的意见视为中立偏后备方案?
- Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:49 (UTC)
- 我希望Cdip150能够就原方案和后备方案孰优孰劣发表一下意见。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:41 (UTC)
- 反对说法2。我认为目前的公示形态非常清楚;任何人找不到章节的话,我可以和他说在哪一个位置(其实也只有一个位置而已)。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:21 (UTC)
- 如果三日后未有其他意见的话,我会通过后备方案。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 23:10 (UTC)
- 我支持后备方案。第二类粗体的设置不应是单向不可逆的,否则一开始就明文禁止还更好一些勒。—— Eric Liu 坐等万次编辑(留言.留名.学生会) 2019年5月22日 (三) 00:32 (UTC
- 我比较(+)支持后备方案,我先不评论上面的共识争议,我是突然想到原方案会产生一个问题:如果简写是中外文混合而成的话,例如:“日本职业足球联赛(Japan Professional Football League),简称J联赛”,允许移除那部分的外文粗体的话可能会造就“J联赛”的奇怪做法,所以后备方案会较稳妥。不过还是应该从公示中完全移除该条文,后再等七天无异议后通过,三天可能太快。--街燈電箱150號 开箱维修 抄表 检验证明 2019年5月22日 (三) 17:51 (UTC)
- WP:MOSBOLD:“粗体通常用在一个条目的第一段,并用合适的名称和常用术语作为条目的题目,包括任何同义词和简称”,移除“联赛”的粗体也不合理),上面的例子发生的机会不大;我相信以上解释能使条文通过后为外文去粗体的适用范围更清楚,也避免了我不欲看到的滥去粗体的情形(当然,我也可以事实性修订条文的“外文”为“纯外文”)。Σανμοσα 2019年5月23日 (四) 11:45 (UTC)
- “快刀斩乱麻”,不行,修订政策从不考虑问题存在的时长,只考虑共识是否已达成。而从上面的讨论看来,第2类的移除在我而言很难说得上有共识,所以有关纯外文粗体的详细修订应留待日后再议。另由于后备方案的共识暂时较为明显,还是先从公示中移除有关条文,待七天无异议才视为共识确认。--街燈電箱150號 开箱维修 抄表 检验证明 2019年5月24日 (五) 06:39 (UTC)
- 这点我不认为应该拘泥于程序内(而且公示七日只是惯例,而非方针指引规定)。Σανμοσα 2019年5月24日 (五) 10:13 (UTC) 由于未有人反对二类粗体去加粗以外的条文,我认为现在已可直接通过a、b两部(a部从后备方案),
不,外文是否加粗的问题已困扰社群已久,应快刀斩乱麻。另外,条文的本意是只限制纯外文,“J联赛”之类不是规管范围(因为“J”本身不构成联赛简称;整个“J联赛”去粗体的话,“联赛”并非外文,按现行 - “快刀斩乱麻”,不行,修订政策从不考虑问题存在的时长,只考虑共识是否已达成。而从上面的讨论看来,第2类的移除在我而言很难说得上有共识,所以有关纯外文粗体的详细修订应留待日后再议。另由于后备方案的共识暂时较为明显,还是先从公示中移除有关条文,待七天无异议才视为共识确认。--街燈電箱150號 开箱维修 抄表 检验证明 2019年5月24日 (五) 06:39 (UTC)
- WP:MOSBOLD:“粗体通常用在一个条目的第一段,并用合适的名称和常用术语作为条目的题目,包括任何同义词和简称”,移除“联赛”的粗体也不合理),上面的例子发生的机会不大;我相信以上解释能使条文通过后为外文去粗体的适用范围更清楚,也避免了我不欲看到的滥去粗体的情形(当然,我也可以事实性修订条文的“外文”为“纯外文”)。Σανμοσα 2019年5月23日 (四) 11:45 (UTC)
(请继续在横线上方讨论)
- 以下重新张贴公示内容:(c、d之修订已完成,但不作为指引)
a. Wikipedia:格式手册/文字格式建议修改如下:
|
b. Wikipedia:格式手册建议修改如下:
|
|
以上。Σανμοσα以有涯随无涯,殆已! 2019年5月21日 (二) 10:38 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
又莫名其妙吵起来的文字格式#颜色及内联图像问题
难道不能在Wikipedia:格式手册/文字格式#颜色及内联图像加上案例吗?说真的。虽然有讨论过建议修改文字格式#颜色及内联图像,但我觉得仍有很多人不能理解(没错,就是有人看不懂),虽然我被人说过“方针不是操作指南,亦不是巡查手册”,但格式手册没指南,又写的很朦胧,还是说这些东西可以写在Help:列表或者是Help:表格(他们算指南吗?)。 --船到桥头自然卷*留言*Violeta 2019年5月16日 (四) 15:35 (UTC)
- 能否具体点?是哪句含糊?还是整段?会否有事例?--J.Wong 2019年5月18日 (六) 14:44 (UTC)
- @Milkypine?—— Eric Liu 坐等万次编辑(留言.留名.学生会) 2019年5月26日 (日) 15:21 (UTC)
- 一望WP:FLC而知。--Rowingbohe♬~Taichow·Sign 2019年5月26日 (日) 15:26 (UTC)
- 我都忘了我有发过这鬼东西...,反正自从FLC之后都没有什么大规模吵架,就当作没有这回事好了。 --船到*桥头*自然卷 2019年5月26日 (日) 15:31 (UTC)
- 一望WP:FLC而知。--Rowingbohe♬~Taichow·Sign 2019年5月26日 (日) 15:26 (UTC)
粗体的适用范围增加“作品和团体的人物列表”,以适应千与千寻等条目为人物列表的人名加的粗体。Fire and Ice 2019年2月3日 (日) 14:51 (UTC)
- (+)支持。--COHAF ■ 2019年2月3日 (日) 14:54 (UTC)
- 无不可;很多条目也是如此,甚至乎由英文维基百科翻译也有机会出现这种情况。ΣανμοσαThe Trve Lawe of free Monarchies 2019年2月3日 (日) 15:03 (UTC)
- 无不可--Temp3600(留言) 2019年2月3日 (日) 16:34 (UTC)
- 确无不妥。--云间守望 2019年2月4日 (一) 11:38 (UTC)
- (+)支持,但本人有疑问:应否容许人名在“剧情简介”里首次出现时使用粗体,例如ja:君の名は。/你的名字。、ja:Just Because!、ja:ゆるキャン△、妄想学生会、阿宅的恋爱太难? - まっすろな未来 2019年2月5日 (二) 13:58 (UTC)
- 考虑到这个问题可能有争议,我并未要求修改。英文维基百科方针不允许这种粗体,而日文维基百科对粗体的使用较宽松,因此有编者用粗体标识剧情中的人名。Fire and Ice 2019年2月5日 (二) 16:35 (UTC)
- (-)反对,千与千寻处可使用Help:列表#比较长的说明所描述的分号与冒号格式。粗体用于“作品和团体的人物列表”这样的表述较为含糊,易被滥用。--Wcam(留言) 2019年2月5日 (二) 15:35 (UTC)
- 分号冒号格式也是粗体,并无本质区别。另需指出,目前分号冒号格式在移动端有显示问题,将使定义和其说明文字处于同一缩进位置。不加“作品和团体的人物列表”也可以,但要指明适用粗体的“定义列表”是包括“人名列表”的。Fire and Ice 2019年2月5日 (二) 16:35 (UTC)
- “人名列表”仍然不合适,例如Category:中国各高校校友列表或是中华民国政府首脑列表等条目中,把每一个人名都使用粗体显然是完全没有必要的。应当对你认为可以使用粗体的情况提出一个准确的表述,我暂时想不出一个比较好的表述。--Wcam(留言) 2019年2月5日 (二) 20:01 (UTC)
- @Wcam、Fire-and-Ice:改成“虚构作品(小说、漫画、电影、剧集、戏剧等)的角色列表”如何? - まっすろな未来 2019年2月6日 (三) 01:58 (UTC)
- 即便是虚构作品的角色列表,也会有很多种较为复杂的情况,有必要进一步细分。例如西游记角色列表,当前版本中并非所有角色名称都使用粗体,对于描述较多的主要人物使用了章节标题,而众多非主要人物只有名称而没有或只有较少说明的,则没有也不需要使用粗体。--Wcam(留言) 2019年2月6日 (三) 04:32 (UTC)
- 鉴于Help:列表#比较长的说明指出:“若是说明部分太长的话,也请检讨使用标题分出一个章节来写”,个人意见认为,若是说明部分超过50字(50字是参照小小作品的标准),则建议使用级别较低的章节标题,否则不建议使用粗体。另可考虑修订WP:MOSFICT。--Wcam(留言) 2019年2月6日 (三) 04:54 (UTC)
提案人请求关闭。--Hjh474(留言) 2020年4月18日 (六) 17:29 (UTC)
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
粗体的适用范围增加“配音员所饰演的主要角色”,以适应现存众多配音员条目中、为配音员所饰演的主要角色所设的粗体。例如赵明哲、林保全、钉宫理惠、杉田智和等。 -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月16日 (四) 09:16 (UTC)
- 这就又涉及到哪些角色算主要角色、哪些算次要角色的问题了。先来启发一下:就算是给出了姓名的角色,那在动画里只出现过一次的算“主要”吗?--Super Wang 为新冠肺炎疫情中牺牲的医护和患者默哀 2020年4月17日 (五) 01:44 (UTC)
- 只出现一次当然不算。我想这个根本无需、也没有办法制定出一个严格的标准,模糊的标准的话:主角不必多说可以加粗。配角的话只要戏份在故事中所占比重相较其他配角多出许多,即可选择判定为主要配角并为其加粗、亦或选择不加粗,凭编者决定。 -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月17日 (五) 03:35 (UTC)
- 那样子的话会引起编辑战吧 我认为没必要pigppp\\まふ最高!// 2020年4月17日 (五) 05:38 (UTC)
- 现存将配音员饰演过的主要角色以粗体表示的条目数量众多,我认为还是有相当必要的。 -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月17日 (五) 07:38 (UTC)
- 那样子的话会引起编辑战吧 我认为没必要pigppp\\まふ最高!// 2020年4月17日 (五) 05:38 (UTC)
- 只出现一次当然不算。我想这个根本无需、也没有办法制定出一个严格的标准,模糊的标准的话:主角不必多说可以加粗。配角的话只要戏份在故事中所占比重相较其他配角多出许多,即可选择判定为主要配角并为其加粗、亦或选择不加粗,凭编者决定。 -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月17日 (五) 03:35 (UTC)
- 反对。若为配音员条目特别开放,恐将有一堆条目也要求各种开放。以阁下之举例,依现行规则若欲标示“主要角色”,表格中可直接写于备注栏,条列式亦可直接括号说明,并无困难,尽管这部分亦疑为爱好者之琐碎内容。--Hjh474(留言) 2020年4月17日 (五) 07:09 (UTC)
2.而配音员条目有数千条之多,为了契合现行规则而兴师动众修改数千条配音员条目,恐怕不是一个比较现实的做法。
3.若改用注释和括号说明有点本末倒置:明明用粗体就可以更简单地解决呀。
4.现行规则中,可以使用粗体的情况被限制得过于少了,只要有足够理由,今后有更多的人要求开放其他特例我认为并无不妥,互助客栈勤于争吵却畏惧站务增多,岂不贻笑大方?
-- Suzuha Amane THE IDOLM@STER(留言) 2020年4月17日 (五) 07:31 (UTC) 1.正如我开篇所说,此次修订讨论是为了将规则改为适应现状:现存配音员条目普遍使用粗体标注主要角色的现实。
- WP:MOSBOLD指出,“对条目正文中的重点,请别使用粗体”。给主要角色加粗有“标重点”的意思,和现行规则的理念违背。目前的两个豁免规则:术语加粗只是排版作用,不加粗也不会有意义上的损失;参考卷目号加粗是业界习惯。WP:ACCESS指出,单纯用粗体、斜体、颜色等格式传达意义是不对的:阅读器未必能正确显示格式,复制粘贴成txt信息也会损失。和单纯加粗表示主角相比,Hjh474所言,用括弧文字标注就是正确的做法。配音员加粗是日文版的习惯,这个习惯我们讨论过它的优缺点吗,这真的值得我们学习吗?--103.118.42.212(留言) 2020年4月17日 (五) 07:54 (UTC)
- 1.就是不认同现行WP:MOSBOLD所以我才要提出修订啊…此外WP:ACCESS并未达成共识,我不认为是一个有力的论点。
2.没有讨论过的话,可以现在讨论。
3.死守现行规则不能解决我前述的现状问题。
-- Suzuha Amane THE IDOLM@STER(留言) 2020年4月17日 (五) 08:00 (UTC)- 所谓“适应现状”的“现状”其实早就违反指引,早该清理。爱好者琐碎资讯直接清理掉,更“简单解决”。担心配音员条目众多,似乎也是“畏惧站务”。敬邀阁下加入WP:格式审查工作小组。不只配音员,许多艺人条目都有滥为“主角”添加粗体的情形。我辈应依指引,见一个除一个,让新进编者了解格式对百科之重要性,一起对抗爱好者琐碎资讯。事实上现在阁下之所以觉得粗体好用,正是因为有格式指引以及社群共同清理粗体的成果,否则百科早被粗体淹没,请勿小看爱好者的力量。以上浅见,唐突请勿见怪。--Hjh474(留言) 2020年4月17日 (五) 08:07 (UTC)
- 我拒绝,指引也好方针也好,最初都是由人来制定,不是什么死海古卷、旧约圣经,过时的规矩就应该修改。 -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月17日 (五) 08:12 (UTC)
- 所谓“适应现状”的“现状”其实早就违反指引,早该清理。爱好者琐碎资讯直接清理掉,更“简单解决”。担心配音员条目众多,似乎也是“畏惧站务”。敬邀阁下加入WP:格式审查工作小组。不只配音员,许多艺人条目都有滥为“主角”添加粗体的情形。我辈应依指引,见一个除一个,让新进编者了解格式对百科之重要性,一起对抗爱好者琐碎资讯。事实上现在阁下之所以觉得粗体好用,正是因为有格式指引以及社群共同清理粗体的成果,否则百科早被粗体淹没,请勿小看爱好者的力量。以上浅见,唐突请勿见怪。--Hjh474(留言) 2020年4月17日 (五) 08:07 (UTC)
- 1.就是不认同现行WP:MOSBOLD所以我才要提出修订啊…此外WP:ACCESS并未达成共识,我不认为是一个有力的论点。
- (~)补充:曾经历史纪年和民族纪年相关方针中,日本年号纪年是不允许使用阿拉伯数字的,但是因为有许多由日维翻译过来的条目中沿用了日维中使用阿拉伯数字作为年号纪年的格式,最终带动中维为其修改方针,我认为与本主题的讨论并无二致。 -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月17日 (五) 08:16 (UTC)
- 也就是说,您要修改“不得为条目重点加粗”这影响全部110万条目的理念,而且只是为了几千个配音员条目?没有方针时我们讲道理:WP:ACCESS的理念适用于包括中文维基在内的所有网站,倒是您应该说说,为何配音员条目不适用这个所有网站都普适的理念?说到日期,以前日期都有加内链的,后来根据WP:OVERLINK的理念,制定WP:DATELINK把日期链接全部摘掉,影响条目量至少几万。那几千个配音员套条目去掉粗体,对机器人易如反掌,何来兴师动众一说?--144.48.7.203(留言) 2020年4月17日 (五) 08:32 (UTC)
- 1.我不知道你和上一位ip是否同一位,但只要有看到本人开篇所说的那短短一行字,就可以清楚知道我的提议只有适应那几千个配音员条目,根本不会对其余众多条目造成影响,实在不明白你说“影响全部110万条目”是何意。
2.依你所说,当时使用到阿拉伯数字的日本年号纪年的条目,相比中维条目总数一样显得很少(甚至任何一个类型的条目与中维条目总数相比都相形见绌),那么当初就不应该要改啦。这种以占比来进行简单比较的方式我认为不值一提。
3.Wikipedia:ACCESS没有达成共识,前面已经提醒过那一位ip一次。
4.依然建议依照历史纪年和民族纪年模式进行此次修订。
-- Suzuha Amane THE IDOLM@STER(留言) 2020年4月17日 (五) 08:53 (UTC)- 这样讨论很没意思,我就回第三点吧。您的提议目前不是方针,要想让他变成方针,你必须讲道理让大家同意。我不同意您的提议,所以我也用讲道理回应您。WP:ACCESS的确不是本地方针,但本地也没有否决这个做法,我完全可以拿这个内容说理,说明这个做法打破了现有规则,也没带来什么好处。我列出WP:ACCESS的意思是,英文维基那么多人反复讨论的结果必然是有一定道理,我也认为这个道理适合中文维基;而您就像在说,英文维基说的不用看,肯定都是错的。我也可以说,“您的几条意见要么违反方针、要么不是方针,我都不听;请遵守现行方针,立刻、马上,把几千个配音员条目纠正过来”,这样真的好吗?--103.118.42.212(留言) 2020年4月17日 (五) 09:33 (UTC)
- 是您联想过度了,我也在尽我所能地讲道理,不然也无需分点陈列我的观点。我当然知道WP:ACCESS在其他语言维基百科中可能曾经有过广泛且长篇的讨论,但是它在中文维基百科中仅有两篇讨论,这也是事实,如此的社群关注度令我实在没办法认为WP:ACCESS能够在中文维基百科中“是一个有力的论点”,而不是在恶意将其排除出讨论范围之内,如果有引起误会我非常抱歉。 -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月18日 (六) 16:19 (UTC)
- @Suzuha Amane:阁下不是说:“可以使用粗体的情况被限制得过于少了,只要有足够理由,今后有更多的人要求开放其他特例我认为并无不妥”,阁下起这个头显然不会只影响到配音员条目,事实上阁下大概很难提出理由何以配音员条目“能优于”其他类型条目必须放宽使用粗体。--Hjh474(留言) 2020年4月18日 (六) 15:37 (UTC)
- 我也这么认为,此次讨论结束后,我会考虑再准备材料要求彻底开放合理使用粗体的范围,而不仅是配音员。 -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月18日 (六) 16:19 (UTC)
- 这样讨论很没意思,我就回第三点吧。您的提议目前不是方针,要想让他变成方针,你必须讲道理让大家同意。我不同意您的提议,所以我也用讲道理回应您。WP:ACCESS的确不是本地方针,但本地也没有否决这个做法,我完全可以拿这个内容说理,说明这个做法打破了现有规则,也没带来什么好处。我列出WP:ACCESS的意思是,英文维基那么多人反复讨论的结果必然是有一定道理,我也认为这个道理适合中文维基;而您就像在说,英文维基说的不用看,肯定都是错的。我也可以说,“您的几条意见要么违反方针、要么不是方针,我都不听;请遵守现行方针,立刻、马上,把几千个配音员条目纠正过来”,这样真的好吗?--103.118.42.212(留言) 2020年4月17日 (五) 09:33 (UTC)
- 1.我不知道你和上一位ip是否同一位,但只要有看到本人开篇所说的那短短一行字,就可以清楚知道我的提议只有适应那几千个配音员条目,根本不会对其余众多条目造成影响,实在不明白你说“影响全部110万条目”是何意。
- 也就是说,您要修改“不得为条目重点加粗”这影响全部110万条目的理念,而且只是为了几千个配音员条目?没有方针时我们讲道理:WP:ACCESS的理念适用于包括中文维基在内的所有网站,倒是您应该说说,为何配音员条目不适用这个所有网站都普适的理念?说到日期,以前日期都有加内链的,后来根据WP:OVERLINK的理念,制定WP:DATELINK把日期链接全部摘掉,影响条目量至少几万。那几千个配音员套条目去掉粗体,对机器人易如反掌,何来兴师动众一说?--144.48.7.203(留言) 2020年4月17日 (五) 08:32 (UTC)
- 虽然Wikipedia:日本动漫游戏条目指导(草案建议)允许这种情况,但为了默许这种部分方面处理而去修改大方针,有点小题大做。既然普遍读者无法考据角色的重要性,或者可能缺少这种来源去彰显这种依据或缺少方式去表现这种依据,可以不用加粗标记。只是现有存量和“缺少来源”的情况一样,可清可不清。——路过围观的Sakamotosan | 避免做作,免敬 2020年4月17日 (五) 08:57 (UTC)
- 了解,我目前的理解是“在Wikipedia:日本动漫游戏条目指导达成共识前可以暂时搁置是否应该清理ACG相关条目之粗体问题”,不知是否有误,还望指正。
题外话,老实说等这些草案达成共识根本遥遥无期,只有在客栈进行讨论才可以稍微推动一下进程,不然谁喜欢在这里几千字、几万字地讨论呢? -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月17日 (五) 09:09 (UTC)
- 了解,我目前的理解是“在Wikipedia:日本动漫游戏条目指导达成共识前可以暂时搁置是否应该清理ACG相关条目之粗体问题”,不知是否有误,还望指正。
这不就是音乐条目的陋习吗?,所以我说为什么需要粗体显示这些主角,为什么?我真的无法理解粗体到底能够带来什么效应,要说增加辨识...赵明哲那个精美的栏位加上粗体还是很难看(不容易阅读,而且某方面来说加粗和没加粗在我眼里看起来真的没差)。认真的说,我倒是希望采用金马奖最佳女主角的格式,可以一目了然那些作品的扮演位置 --无心*插柳*柳橙汁 2020年4月17日 (五) 10:04 (UTC)- 错了,这是翻译日文条目的陋习。(笑)——路过围观的Sakamotosan | 避免做作,免敬 2020年4月18日 (六) 00:48 (UTC)
- (-)反对。—— Eric Liu(留言.留名.学生会) 2020年4月17日 (五) 10:40 (UTC)
- 本次讨论反对意见压倒性居多,且相信短期内无法达成修订之共识,在此(&)建议关闭本次修订WP:MOSBOLD之讨论。 -- Suzuha Amane THE IDOLM@STER(留言) 2020年4月18日 (六) 16:19 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
我写了懒汉这个条目,然后因为《懒汉》是歌曲,所以我根据Wikipedia:格式手册/文字格式把英文名字加了英文引号。然后Milkypine三番四次把英文引号改成斜体或移除英文引号,我都不能再回退了,他还声称因为Wikipedia:格式手册/标点符号并没有相关规定,所以他非得要移除英文引号,然而我认为他这样实际上违反了格式手册,因为Wikipedia:格式手册/文字格式和Wikipedia:格式手册/标点符号具有同等地位,而且前者的相关规定并不与后者冲突。请大家评论。SANMOSA SPQR 2020年7月31日 (五) 04:06 (UTC)
然而Wikipedia:格式手册/标点符号并没有说明这样的情况,所以请你不要重复强调。 --无心*插柳*柳橙汁 2020年7月31日 (五) 03:26 (UTC)
- Wikipedia:格式手册/文字格式和Wikipedia:格式手册/标点符号具有同等地位,而且前者的相关规定并不与后者冲突。我认为你作出的相关改动已经实际上违反格式手册,所以我请你先行回复为我的版本,其他事慢慢讨论。SANMOSA SPQR 2020年7月31日 (五) 03:58 (UTC)
- 前者Wikipedia:格式手册/文字格式只说“其余一般情况应以标点符号方式标明西文作品名”,但是Wikipedia:格式手册/标点符号并没有相关规定,所以我把它删除。 --无心*插柳*柳橙汁 2020年7月31日 (五) 04:01 (UTC)
- Wikipedia:格式手册/标点符号没有相关规定,但Wikipedia:格式手册/文字格式有相关规定的时候,理当以Wikipedia:格式手册/文字格式为准。无论如何,我把这事送客栈了。SANMOSA SPQR 2020年7月31日 (五) 04:08 (UTC)
- 前者Wikipedia:格式手册/文字格式只说“其余一般情况应以标点符号方式标明西文作品名”,但是Wikipedia:格式手册/标点符号并没有相关规定,所以我把它删除。 --无心*插柳*柳橙汁 2020年7月31日 (五) 04:01 (UTC)
- 因为他就没有写说加上“英文引号”啊... --无心*插柳*柳橙汁 2020年7月31日 (五) 04:10 (UTC)
- Wikipedia:格式手册/标点符号没有相关规定,但Wikipedia:格式手册/文字格式有相关规定的时候,理当以Wikipedia:格式手册/文字格式为准。除非另有说明,否则所有指引在任何时候都同时适用,不可能因为一个指引没有相关规定而直接无视其他指引的相关规定。不然所有指引都要整合到单一页面里?SANMOSA SPQR 2020年7月31日 (五) 04:14 (UTC)
- 无心*插柳*柳橙汁 2020年7月31日 (五) 04:17 (UTC)
- SANMOSA SPQR 2020年7月31日 (五) 04:19 (UTC)
- 当然不是什么理所当然的事情,斜体都有限定使用范围了。 --无心*插柳*柳橙汁 2020年7月31日 (五) 04:22 (UTC)
应该视乎该语言对相关标点的使用习惯而加入相应的标点符号。我以为按照该语言对相关标点的使用习惯写出外语是理所当然的事。
然而只有说加上标点符号,文字格式都没有说应该加什么了,请问你加上英文引号的行为是否也不洽当,两个指引都没有提到可以加入“英文引号”,就算法无禁止也不能想放就放啊。 -- - SANMOSA SPQR 2020年7月31日 (五) 04:19 (UTC)
我还是这句话: - 无心*插柳*柳橙汁 2020年7月31日 (五) 04:17 (UTC)
- Wikipedia:格式手册/标点符号没有相关规定,但Wikipedia:格式手册/文字格式有相关规定的时候,理当以Wikipedia:格式手册/文字格式为准。除非另有说明,否则所有指引在任何时候都同时适用,不可能因为一个指引没有相关规定而直接无视其他指引的相关规定。不然所有指引都要整合到单一页面里?SANMOSA SPQR 2020年7月31日 (五) 04:14 (UTC)
- @AT。SANMOSA SPQR 2020年7月31日 (五) 04:28 (UTC)
- 我认为在不影响结构的情况下,都可以接受。例如试播集 (邪恶力量)等FA似乎都多用斜体来标示英语原文,Charlotte (动画)等则没有用到日语惯用的引号。所以,使用与否也无伤大雅吧?—AT 2020年7月31日 (五) 05:44 (UTC)
- SANMOSA SPQR 2020年7月31日 (五) 05:50 (UTC)
- 我同意在无合理的原因下不应干涉别人的选择,在这里我想先听一听他的说法,再考虑如何处理。—AT 2020年7月31日 (五) 06:00 (UTC)
- 的确没有理由干涉,但既然指引没有指引,那么就给他删除。毕竟Slug变成"Slug"也是过度强调,而且Wikipedia:格式手册/文字格式也没有把英文名字加了英文引号的根据 --无心*插柳*柳橙汁 2020年7月31日 (五) 06:23 (UTC)
- 然而Wikipedia:格式手册/标点符号指引也没有容许你删除(尤其在Wikipedia:格式手册/文字格式表明需要加标点的情况下)。这是一个点。再者,“"Slug"”才是正确的英语表示法,“Slug”变成“"Slug"”是基本的英语改正工作,我从来没有听过有人把改正工作称为“过度强调”的。中文维基百科不代表非中文的东西就能够乱来。SANMOSA SPQR 2020年7月31日 (五) 06:55 (UTC)
- 话说这里是中文维基,除了来源有写采用原文之外,正常情况不是应该使用中文格式吗?对于指引有意见欢迎提出修改而非跟我抗议,指引没有容许我删除并不代表你拥有加上“""”权力。 --无心*插柳*柳橙汁 2020年7月31日 (五) 07:42 (UTC)
- 标示外语当然随外语的规则,标示中文的情况当然用中文的格式,两者是不冲突的。我不是对于指引有意见,我是对于你对指引的错误解读有意见。我请你以后不要乱动有关外语的标点使用,不然我会采取进一步行动。SANMOSA SPQR 2020年7月31日 (五) 09:00 (UTC)
- “标示外语当然随外语的规则”其实是不对的,不然标示英文的时候就得用半角括号了,整个句子应该用中文规则;而且,我从FA里选了十几个作品类条目,没有一个用“英文引号”。 【和平至上】支持通过港区国安法💬 2020年7月31日 (五) 10:04 (UTC)
- 你将“标示外语”的范围错误地泛化了,这里所指的英语标点是排除括号后的英语标点,请你先看清楚讨论重点。此外,其他FA这样错不代表我必须跟着它们错。SANMOSA SPQR 2020年7月31日 (五) 12:02 (UTC)
- 不知道我这样有没有理解错误,“()如同租借和领事馆,只要是这个领域就不适用中文维基”。好吧槽点很多,“其余一般情况应以标点符号方式标明西文作品名”并不会让“Slug”变成“"Slug"”,这与基本英语改正工作无关,终究是维基没有指引,应以标点符号这句话可没有表示套用英文规则,就算是常识也不等于可以使用。 --无心*插柳*柳橙汁 2020年7月31日 (五) 17:06 (UTC)
- 但也没有表示不能套用,因此套用与否应该视乎个人喜好(所以我没有动其他,我已经够尊重了)。SANMOSA SPQR 2020年8月1日 (六) 01:49 (UTC)
- 不知道我这样有没有理解错误,“()如同租借和领事馆,只要是这个领域就不适用中文维基”。好吧槽点很多,“其余一般情况应以标点符号方式标明西文作品名”并不会让“Slug”变成“"Slug"”,这与基本英语改正工作无关,终究是维基没有指引,应以标点符号这句话可没有表示套用英文规则,就算是常识也不等于可以使用。 --无心*插柳*柳橙汁 2020年7月31日 (五) 17:06 (UTC)
- 你将“标示外语”的范围错误地泛化了,这里所指的英语标点是排除括号后的英语标点,请你先看清楚讨论重点。此外,其他FA这样错不代表我必须跟着它们错。SANMOSA SPQR 2020年7月31日 (五) 12:02 (UTC)
- “标示外语当然随外语的规则”其实是不对的,不然标示英文的时候就得用半角括号了,整个句子应该用中文规则;而且,我从FA里选了十几个作品类条目,没有一个用“英文引号”。 【和平至上】支持通过港区国安法💬 2020年7月31日 (五) 10:04 (UTC)
- 标示外语当然随外语的规则,标示中文的情况当然用中文的格式,两者是不冲突的。我不是对于指引有意见,我是对于你对指引的错误解读有意见。我请你以后不要乱动有关外语的标点使用,不然我会采取进一步行动。SANMOSA SPQR 2020年7月31日 (五) 09:00 (UTC)
- 话说这里是中文维基,除了来源有写采用原文之外,正常情况不是应该使用中文格式吗?对于指引有意见欢迎提出修改而非跟我抗议,指引没有容许我删除并不代表你拥有加上“""”权力。 --无心*插柳*柳橙汁 2020年7月31日 (五) 07:42 (UTC)
- 然而Wikipedia:格式手册/标点符号指引也没有容许你删除(尤其在Wikipedia:格式手册/文字格式表明需要加标点的情况下)。这是一个点。再者,“"Slug"”才是正确的英语表示法,“Slug”变成“"Slug"”是基本的英语改正工作,我从来没有听过有人把改正工作称为“过度强调”的。中文维基百科不代表非中文的东西就能够乱来。SANMOSA SPQR 2020年7月31日 (五) 06:55 (UTC)
- 的确没有理由干涉,但既然指引没有指引,那么就给他删除。毕竟Slug变成"Slug"也是过度强调,而且Wikipedia:格式手册/文字格式也没有把英文名字加了英文引号的根据 --无心*插柳*柳橙汁 2020年7月31日 (五) 06:23 (UTC)
但他也总不能不让我用吧,而且还改一半不改一半。麻烦帮我回退一下。 - 我同意在无合理的原因下不应干涉别人的选择,在这里我想先听一听他的说法,再考虑如何处理。—AT 2020年7月31日 (五) 06:00 (UTC)
- SANMOSA SPQR 2020年7月31日 (五) 05:50 (UTC)
- 我认为在不影响结构的情况下,都可以接受。例如试播集 (邪恶力量)等FA似乎都多用斜体来标示英语原文,Charlotte (动画)等则没有用到日语惯用的引号。所以,使用与否也无伤大雅吧?—AT 2020年7月31日 (五) 05:44 (UTC)
- @AT。SANMOSA SPQR 2020年7月31日 (五) 12:02 (UTC)
- 为何不直接使用斜体?—AT 2020年7月31日 (五) 12:09 (UTC)
- @AT:Wikipedia:格式手册/文字格式禁止使用斜体标示非整段作品列表或书目的西文作品名。SANMOSA SPQR 2020年7月31日 (五) 15:14 (UTC)
- 老实说我倒是希望可以讨论斜体的使用范畴来解决这问题,毕竟只有“作品列表或书目”不符使用习惯[
来源请求],先不论为什么模板都会自动斜体这点,英文维基也不有如此局限的使用范围,当然这里是中文维基,应该采用中文做法。 --无心*插柳*柳橙汁 2020年7月31日 (五) 17:00 (UTC)- 模板没有自动斜体,斜体是要手动加入的。SANMOSA SPQR 2020年8月1日 (六) 01:49 (UTC)
- 有的,例如游戏条目常用的模板:Infobox VG与模板:Vgname,模板:Nihongo title也具有相同的功能,就算没有自动转换,也会提示请记得手动标示斜体(例如模板:电影资讯框)。
- 我已经将懒汉的编辑修改回来,另外我也在下面开了个关于增设斜体使用范围的新话题 --无心*插柳*柳橙汁 2020年8月1日 (六) 04:08 (UTC)
- 居然还有这种规定?我觉得这规定已经不符合现实了。 【和平至上】支持通过港区国安法💬 2020年8月1日 (六) 07:03 (UTC)
- 模板没有自动斜体,斜体是要手动加入的。SANMOSA SPQR 2020年8月1日 (六) 01:49 (UTC)
- 老实说我倒是希望可以讨论斜体的使用范畴来解决这问题,毕竟只有“作品列表或书目”不符使用习惯[
- @AT:Wikipedia:格式手册/文字格式禁止使用斜体标示非整段作品列表或书目的西文作品名。SANMOSA SPQR 2020年7月31日 (五) 15:14 (UTC)
- 为何不直接使用斜体?—AT 2020年7月31日 (五) 12:09 (UTC)
增加WP:格式手册/文字格式关于西文作品名的斜体使用范畴
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
目前WP:格式手册/文字格式上只表示仅限于整段作品列表或书目的西文作品名才可以使用斜体,希望能开放限制,让音乐、电影、游戏也能纳入使用范围内。 --无心*插柳*柳橙汁 2020年8月1日 (六) 04:11 (UTC)
- 我的倾向是外语习惯用斜体标示的,在相关的外语显示方面都可以用斜体(当然,我觉得如果像书名号等等的标点符号的运用也能如此就更好)。基本上这个提议的方向不错。SANMOSA SPQR 2020年8月1日 (六) 07:10 (UTC)
- 支持,我也比较倾向使用类似于:《中文名》(English name)这种方式来标记外语作品,因为中文的书名号在英文中似乎一般都用斜体表示?没有必要仅限于书目。——BlackShadowG★(留言) 2020年8月1日 (六) 14:58 (UTC)
- 现拟议修改WP:ITALIC如下:
“ | 西文作品名(仅限于整段作品列表或书目,其余一般情况应以标点符号方式标明西文作品名在该西文习惯以斜体标示该类作品的情况下方得为之)。 | ” |
- 感谢Sanmosa提出的修改版本,另外也ping先前参与讨论的@AT、和平至上:两位大大。 --无心*插柳*柳橙汁 2020年8月5日 (三) 16:50 (UTC)
- (+)支持:符合现状、亦符合外语使用习惯。--【和平至上】支持通过港区国安法💬 2020年8月5日 (三) 16:55 (UTC)
- WP:PUNCT#书名号之5也有提到西文作品名使用斜体的事情,这样一改两处条文也不冲突了。--洛普利宁 2020年8月6日 (四) 05:03 (UTC)
- 西文到底包括哪些文?并是不是所有语言都这样用的吧?--百無一用是書生 (☎) 2020年8月10日 (一) 01:54 (UTC)
- @Shizhao:所以条文说明了“在该西文习惯以斜体标示该类作品的情况下方得为之”。如果该西文不习惯以斜体标示该类作品,就不会使用斜体。“西文”可以暂时理解为非中文。SANMOSA SPQR 2020年8月10日 (一) 06:41 (UTC)
- 建议改为外文。 【和平至上】支持通过港区国安法💬 2020年8月14日 (五) 16:54 (UTC)
- 同意和平至上大的意见,毕竟这篇方针都是用“外文”来说明。更改后了版本如下:
- 建议改为外文。 【和平至上】支持通过港区国安法💬 2020年8月14日 (五) 16:54 (UTC)
- @Shizhao:所以条文说明了“在该西文习惯以斜体标示该类作品的情况下方得为之”。如果该西文不习惯以斜体标示该类作品,就不会使用斜体。“西文”可以暂时理解为非中文。SANMOSA SPQR 2020年8月10日 (一) 06:41 (UTC)
- 西文到底包括哪些文?并是不是所有语言都这样用的吧?--百無一用是書生 (☎) 2020年8月10日 (一) 01:54 (UTC)
“ | (西文作品名 仅限于整段作品列表或书目,其余一般情况应以标点符号方式标明西文作品名改为外文作品名 在该外文习惯以斜体标示该类作品的情况下方得为之)。 | ” |
- 如果各位无心*插柳*柳橙汁 2020年8月19日 (三) 17:10 (UTC) 没有意见,就公示目前的版本。 --
- 本人浅见:
“ | (西文作品名 仅限于整段作品列表或书目,其余一般情况应以标点符号方式标明西文作品名应改为以拉丁字母、希腊字母和/或基里尔字母书写的作品名,在该外文习惯以斜体标示该类作品的情况下方得为之)。 | ” |
- 西里尔字母似乎不用斜体,见ru:Симпсоны。—AT 2020年8月19日 (三) 17:39 (UTC)
- 而且你有机会派处理其他习惯用斜体表示作品名的语言。SANMOSA SPQR 2020年8月20日 (四) 00:45 (UTC)
- 西里尔字母似乎不用斜体,见ru:Симпсоны。—AT 2020年8月19日 (三) 17:39 (UTC)
- 重拟方案如下:
“ | 西外文作品名(仅限于整段作品列表或书目,其余一般情况应以标点符号方式标明西文作品名在该外文习惯以斜体标示该类作品的情况下方得为之)。 | ” |
- 无心*插柳*柳橙汁 2020年8月22日 (六) 07:44 (UTC) 那么就用Sanmosa最新写的版本做公示。 --
@Milkypine:公示期已过。—— Eric Liu 创造は生命(留言.留名.学生会) 2020年8月30日 (日) 03:57 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。