维基百科:互助客栈/方针/存档/2021年1月

对于涉嫌违反医学伦理之生者的精神分析（指未能亲自诊断仅依靠间接资讯进行的诊断）维基百科是否能独立收录？

在下近日于提案删除特朗普的精神状态这一条目因个人认为涉嫌违反生者条目之：WP:NPOV、WP:NOR、也因1966年美国戈德华诉金斯伯格案判决戈德华胜诉，任何对生者的违反医学伦理之精神分析都不应是视作可靠来源，而是对生者之诽谤。根据WP:LIBEL理应删除。而个人认为此类条目可在本人的主页面描述争议，但不应被收录为独立条目。此外，英文条目也有重订向为戈德华守则的做法。以上为由，因此个人提出删除存废讨论。

而在存废的讨论中，主编此条目者Yel D'ohan阁下抱持着“百分之九十的肯定”也提出了诸如但不限于：WP:关注度、WP:CENSOR、以及不能因为WP:IDONTLIKEIT而提案删除。

在此主要想问问看大家的看法：“中文维基百科是否能收录对生者的有伦理争议的精神状态的分析”并且该分析“有无需要独立收录而不能重导向、合并至相关条目的重要性”，大家可以参考此讨论条目以及存废讨论页面，当然也欢迎在该页面提出自己的见解和观点。--维基百科最忠诚的反对者（留言） 2021年1月8日 (五) 17:43 (UTC)

Wikipedia:可靠来源#相关的定义。经传媒报道的特定专家的观点，未经同行评审，只是一次文献，不能作为断言。尽量引用可靠并以第三方角度介绍的来源。--YFdyh000（留言） 2021年1月9日 (六) 01:58 (UTC)

来源多得是有同行评审的文献，中维社群连什么样的来源属有效都无法判断，在此表示遗憾。我还是专心写paper比较实在，reviewer 2的评论都比这有意义。--Yel D'ohan（留言） 2021年1月9日 (六) 17:34 (UTC)

个人也为中文维基社群少了位傲慢的科学妄人而在此感到欣慰，但也祝福阁下在不同的道路越走越远。--维基百科最忠诚的反对者（留言） 2021年1月9日 (六) 22:40 (UTC)

(＆)建议:这个提案在条目讨论区讨论较适合。--虫虫飞♡♡→♡℃※留言 2021年1月9日 (六) 05:33 (UTC)

嗯...由于这可能也涉及到WP:NPOV和生者守则之类的维基方针，我会重新发放至条目讨论区，但也会保留在这边的讨论...如果阁下觉得不适宜，删除或关闭讨论也是可以。--维基百科最忠诚的反对者（留言） 2021年1月9日 (六) 22:44 (UTC)

改动维基百科:格式手册#地区用词的格式中与社群一贯做法有差异的规定

范例表格	现行方针要求和社群一贯做法违背，应当修改以反映社群一般做法。
问题背景	条文要求“在一个条目中的显示用词应该保持一致”，惟此要求与“地区性用词”无直接关系，且与社群一贯做法相违背。 （1月29日补充）依照现行规定，条目正文中不可同时出现同一概念的全称和简称，
证据	例子 电脑条目中，若使用香港繁体阅读，则同时有大量“电脑”和“计算机”的内容出现，使用大陆简体时亦然。 轿车的条目中，正文同时使用“轿车”和“房车” SUV条目中，混用“运动型多用途车”和“SUV” 手机条目中，大陆简体同时使用“移动电话”和“手机”，香港繁体同时使用“移动电话”、“手提电话”和“手机”，而台湾正体同时使用“移动电话”、“手提电话”和“手机”。 条形码条目中，同时使用“条形码”和“条码”。 大不列颠及北爱尔兰联合王国条目中，同时使用“联合王国”、“英国”。
我的解决方案	此章节进行删节及修改。 现行条文 和文章内文一致 尽管维基百科不偏好某个地区用词，在一个条目中的显示用词应该保持一致。可以使用自动地区词处理提供的模板来自动化文字的转换。例外的场合有： 引用他人的文章时应忠实于原文 各种专有名词，例如作家、导演、音乐家的作品名字和公司名称应忠实于作者 比较各地用词差异时 提议条文 用词应当易于理解 条目显示用词，仅因地区词差异而产生者，应当使用自动地区词处理提供的模板来自动化文字的转换，以达成一致。而若条目所论述内容在同一地区有多种常用说法，应当在文首全部列出或使用{{各地中文名}}列出。在满足前述条件时，不要求条目内用词统一，惟应保证在使用一种汉语变体时，所出现之名词皆为该种汉语变体的常用词。具体而言， 若甲乙二地皆有使用 A，但乙地亦使用 B，则在使用甲地汉语变体时，单向将 B 转换为 A。 若甲乙二地皆有使用 A，但甲地亦使用 B，乙地亦使用 C，则在使用甲地汉语变体时，单向将 C 转换为 A 或 B （依照先到先得做法选择）。 若甲乙二地皆有使用 A 与 B；即使甲地使用 A 较频繁，而乙地使用 B 较频繁，亦不转换。 此外： 引用他人的文章时应忠实于原文 各种专有名词，例如作家、导演、音乐家的作品名字和公司名称应忠实于作者 比较各地用词差异时，不转换。
相关讨论	本修改请求，由下列讨论引出： Module_talk:CGroup/IT#关于“upload”一词的使用 维基百科:互助客栈/条目探讨#关于上载与上传的使用问题

--Yangwenbo99^{论 文} 2021年1月20日 (三) 23:13 (UTC)

(－)强烈反对：中文维基百科的大部分的条目都有遵从条目内用词（使用地区词处理至）统一的要求，“现行方针要求和社群一贯做法违背”为虚假声称。SANMOSA _SPQR 2021年1月22日 (五) 10:49 (UTC)

@Sanmosa：已参考阁下意见修正提案，惟使用地区词处理至统一，应当限制于“不统一是由于地区用词差异造成的”这一情形。原条文中，注释不加限制地允许“使用地区词处理至一致”，容易使人产生违背地区词转换本意的理解。在下已举出例子，证明对于许多重要条目，中文维基百科并非依照此方针处理。Yangwenbo99^{论 文} 2021年1月22日 (五) 18:27 (UTC)

仍然不认同。同一条目对同一主体的介绍应尽可能仅使用同一种名称，仅在说明名称本身时才需要不转换并列出多个名称。你上面举出的这么多个例子很明显是未有遵守相关方针指引的情形，是需要被改正的。SANMOSA _SPQR 2021年1月23日 (六) 01:12 (UTC)

我认为现行条文存在一些问题。比如某大陆用户知道某个台湾的地区用词，但是不会用繁体打出来，反之，某台湾用户可能知道某个大陆的用词，但是不会用简体打出来。我认为既然已经有了地区词转换技术，没有必要要求可以繁简转换的地区词在整个条目中保持一致写法。我认为保持一致写法的应该是那种不涉及地区词转换的一物多名，为了便于阅读，而保持行文一致。--百無一用是書生 (☎) 2021年1月27日 (三) 01:55 (UTC)

@Shizhao：我说的“保持一致写法”就是在说“不涉及地区词转换的一物多名”的情形（因为涉及地区词转换时“使用地区词处理至一致也算作一致”，这是已有条文）。现拟议条文的意图是在“不涉及地区词转换的一物多名”的情形下不“保持一致写法”。SANMOSA _SPQR 2021年1月28日 (四) 05:59 (UTC)

此次改动是为解决两个问题。1. 有编者依照“使用地区词处理至一致也算作一致”，误用地区词转换处理“不涉及地区词转换的一物多名”。2. 要求条目统一名称，与维基百科之条目编辑习惯不符，此现象在有多种“不涉及地区词转换的”常用名时，尤其明显。--Yangwenbo99^{论 文} 2021年1月29日 (五) 10:40 (UTC)

2才是整个讨论中最有问题的意见吧。条目中除介绍名称和引述原文的部分外，还不能统一用词，是志在让读者产生疑惑吗？如果从维基百科作为百科全书的本质性机能来看，2的想法简直就是和维基百科的本质背道而驰。我认为Shizhao已经很清楚说明了保持一致写法的目的了，我真的不明白像2这样的想法是如何凭空出世的。SANMOSA _SPQR 2021年1月29日 (五) 14:56 (UTC)

如果已在文首提及不同用法，读者便不可能有疑惑。如严格执行现行方针，便会出现明显不正常的结果。

1. 两岸三地皆有使用“上载”，而香港几乎不用“上传”，故依照本方针，应当全文改用“上载”，但明显大量维基人不认同。
2. 中国幅员辽阔，扁食一物有多种不同叫法，若要求“统一”，明显是对“被统一”地区不公平。加之现时又将之前“描述特定地区时，依当地名称”但规定删除，想要同时解决统一和地区平衡问题，只能将大陆简体进一步分拆，但这明显在技术上不可行。

--Yangwenbo99^{论 文} 2021年1月29日 (五) 18:11 (UTC)

除介绍名称和引述原文的部分外，不统一用词的情况在实际应用上基本上仅限于为求符合历史事实（例如宋嘉澍在改名为“宋嘉澍”前名为“韩教准”，在提述其改名前的生平时应称其为“韩教准”）或区别应用性质（例如振音在声乐中称“颤吟”）。拟议修订所带来的副作用过大。【另外，想补充一点：提案人所举出的例子1提及到有条目同时有大量“电脑”和“计算机”的内容出现，有一点需要留意的是“计算机”在繁体中文中并不指“电脑”，而仅指Casio fx-50F Plus之类的“计数机”／“计算器”。】SANMOSA _SPQR 2021年1月30日 (六) 10:00 (UTC)

(＋)赞成--Lantx。_{→有事请讲} 2021年1月25日 (一) 14:15 (UTC)

内部发行的资料能不能证明关注度？

我认为内部发行的资料可以佐证关注度，像洛河大桥这个条目。中国的新闻媒体不会说各个地区的公安局、文化局是什么时候成立的，所有的这些都只能在内部发行的资料中找到。--Assifbus（留言） 2021年1月28日 (四) 06:50 (UTC)

内部发行资料无法查证，而且可能涉及泄密问题--百無一用是書生 (☎) 2021年1月28日 (四) 07:20 (UTC)

阁下的担忧里面其实涉及两个不同的范畴：可否查证在如密级已过的情况下、即可能公开而可满足条件；泄露之判读，在所谓权威裁断中也可飘移不定，如最近香港特别行政区之查册如援引“新常态”、公众即可有堕入法网的风险。当前本地服务器之司法管辖区应暂可豁免其他司法管辖之实质疑虑，Assifbus阁下如可提供可公开讨论之个别参考来源资料，可再甄别有关之实质可操作度。--约克客（留言） 2021年1月28日 (四) 14:19 (UTC)

@Assifbus：那南山区 (涿鹿县)#治安及司法的来源10是什么东西？SANMOSA _SPQR 2021年1月28日 (四) 08:55 (UTC)

• 任何未公开的文件当然不能用作任何来源。另外公安局、文化局什么时候成立，应该去查地方志书，而不是新闻媒体。->>Vocal&Guitar->>_留言 2021年1月31日 (日) 08:24 (UTC)

Wikipedia:格式手册/日期和数字#同一数值不能换行

Wikipedia:格式手册/日期和数字#同一数值不能换行里面举了个例子：

• 正确：中华人民共和国1990年人口普查人数为11亿3368万2501人
• 错误：中华人民共和国1990年人口普查人数为11亿33
  68万2501人

错误示例中“33”和“68”间的换行是手工加<br />搞出来的。但正常情况下，主流浏览器不会在阿拉伯数字间换行，编者更不会像示例一样加<br />。所以这个问题不用太担心。

中华人民共和国1990年人口普查人数为11亿3368万2501人

---

中华人民共和国1990年人口普查人数为11亿3368万2501人

---

中华人民共和国1990年人口普查人数为1,133,682,501人

而实际可能情况是这样：“11亿3368万2501人”刚好出现在行末，结果有了“11亿//3368万2501人”或者“11亿3368//万2501人”这样的换行。（右侧上例）

现在的问题是，“11亿3368万2501“应该作为一个整体解读。但读者浏览器窗口不定，总有读者会看到跨行的版本？所以这里是否要求始终以{{nowrap}}干预处理？（右侧中例）

再或者“11亿//3368万2501人”可以接受，而“11亿3368//万2501人”不行，所以逢万使用一次{{nowrap}}？--洛普利宁 2021年1月30日 (六) 16:45 (UTC)

不应过度干预排版，尤其是使用nowrap，会影响移动端（即窄屏幕）及小容器内排版。正如您所说，浏览器一般不会在数字或单词中间换行（不会有11亿3368//万2501人，贴错，是不会有11亿33//68万2501人），除非手动干预（也就是那个例子）。--安忆^Talk 2021年1月30日 (六) 17:08 (UTC)

如果不干预，那是否应该把这条格式手册规定（或者至少这个不明所以的例子）给删掉？PS：我的浏览器（Safari 14.0.2 @ macOS 11.1）是“11亿3368//万2501人”而不是“11亿//3368万2501人”或“11亿3368万//2501人”。--洛普利宁 2021年1月30日 (六) 17:18 (UTC)

示例未苛求编者照顾到所有分辨率的展示效果，所以用户做好自己就可以，也不必在源码中用技术手段苛求完美，这个问题可能要靠Unicode和浏览器开发方将数量级及量词文字识别为数字的一部分。--YFdyh000（留言） 2021年1月30日 (六) 17:23 (UTC)

啊…我贴错了，抱歉。是不会有“11亿33//68万2501人”这种情况，也就是说除非手动换行或使用break-all属性，否则那个例子是不存在的。nowrap也就是keep-all属性会有排版问题。--安忆^Talk 2021年1月30日 (六) 17:27 (UTC)

右上例确实看到“11亿3368
万2501人”的效果，new Edge on Windows 10。--YFdyh000（留言） 2021年1月30日 (六) 17:23 (UTC)

其实我觉得这个范例也有可能是连换两行的结果。不少新手编辑会不小心这么做。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2021年1月31日 (日) 11:13 (UTC)

格式手册“同一个用阿拉伯数字表示的数值，要使其在同一行，避免出现断行或者换行的情况，以免出现歧义”应该是参考了中华人民共和国国家推荐标准《出版物上数字用法的规定》“一个用阿拉伯数字书写的数值应避免断开移行”。我的理解是阿拉伯数字不断开（主流浏览器一般能做到），在汉字和阿拉伯数字间断开没有问题。 Konno Yumeto ^{Sayonara, Flash} 2021年1月31日 (日) 11:19 (UTC)