维基百科:互助客栈/方针/存档/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)