維基百科:互助客棧/方針/存檔/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)