維基百科討論:格式手冊/存檔4

本頁是以往討論的存檔。請勿編輯本頁。若您想發起新討論或重啟現有討論，請在當前討論頁進行。

空格

最新留言：8 年前127則留言25個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2016年7月11日 (一) 08:42 (UTC)。

在中文維基格式手冊裏，空格一節寫出，「在中文語境內，文字之間應該不留空格。」請問這是否只是指中文與中文之間？在中文與英文之間，在中文與數學符號之間，在中文與數學方程之間，在標點符號與中文之間，是否可以留空格？在英文維基裏，對於空格的置入沒有做出限制。從英文維基輸入的模板與數學方程裏，都存在着很多空格。我覺得在原始碼內適當地置入空格，可以幫助檢視與維持；在頁面裏適當地顯示空格，也可以幫助閱讀、美化頁面。我們是否可以賦予空格一些它可以承擔的功能？請大家發表寶貴意見，達成共識，謝謝！--老陳（留言） 2016年3月22日 (二) 05:58 (UTC)

(－)反對反對中文與英文之間加入空格，應維持原本的格式，格式統一整齊才是重點。如果以個人感官來說，我覺得加了這些空格反而顯得版面混亂，所以這是個人審美與習慣問題，加空格並沒有絕對的幫助。--泅水大象™ 訐譙☎ 2016年3月22日 (二) 06:39 (UTC)
(！)意見，這很明顯是講中文字與中文字之間，中文文句的文法裏本來就沒有空格這回事，把一句長句作適當的區分是用逗號而不是空格，用空格違反了標準文法。而中文以外的部份，則應以常識來決定各個案例與特例是否應該加入，反而不應該在手冊裏做提議統一要不要加空格。--街燈電箱150號開箱維修抄錶檢驗證明 2016年3月22日 (二) 06:51 (UTC)
- 他的問題應該是針對中文與英文之間的介面部分，至於標點符號與中文之間的空格就更不可行了。--泅水大象™ 訐譙☎ 2016年3月22日 (二) 09:57 (UTC)
  - 他問：「請問這是否只是指中文與中文之間？」我答：「這很明顯是講中文字與中文字之間」。--街燈電箱150號開箱維修抄錶檢驗證明 2016年3月22日 (二) 10:00 (UTC)
    - 哈，誤會誤會，原來你講的是他針對格式規則的原發問，而我講的是他的主張，雞同鴨講了。--泅水大象™ 訐譙☎ 2016年3月22日 (二) 10:28 (UTC)
首先中文文法不需要在字詞之間添加空格；其次由於模板等的字段的空格在被解釋器處理時會被過濾掉，所以空格才不會顯現。——路過圍觀的Sakamotosan 2016年3月22日 (二) 07:15 (UTC)
以量子諧振子為例，User:Πrate的傀儡用自動化工具刪掉半形空格後，在「一個質量為m的粒子」就已經有字體輕微重疊的現象（m是斜體），同一條目的其它因為刪掉空格而影響閱讀的例子就不用逐一列出了，眼見為實，尤其是當預設字體為「新細明體」時。--Mewaqua（留言） 2016年3月22日 (二) 10:24 (UTC)
- 所以重點應該是為何內文中要出現斜體，而不是空格的問題吧？之前已經有過其他討論，認為英文維基中對於拉丁文或專有名詞所做的斜體處理，不該直接沿用到中文維基。還有，字間距我記得可以利用CSS的方式調整，每個人都有各自習慣的版面安排。--泅水大象™ 訐譙☎ 2016年3月22日 (二) 10:32 (UTC)
  - 我無記錯的話，數學代數裏正常字體和斜體是有不同意思的：正常字體表示常數和函數名稱，斜體字母則表示變數，例如：cos x；而「一個質量為m的粒子」的m應該是變數所以用斜體，不過在我這裏「m」和「的」之間沒有重疊，我這邊配置了拉丁字母用Arial而中文用XP版新細明體。--街燈電箱150號開箱維修抄錶檢驗證明 2016年3月22日 (二) 12:13 (UTC)
    - 找到一些會造成顯示錯誤的例子：X粒子、Y粒子、Z粒子、X⁰粒子、Y⁰粒子、Z⁰粒子。英文維基並沒有對空格的置入做出甚麼限制，我們為甚麼要過度規定空格的置入？--老陳（留言） 2016年3月23日 (三) 05:35 (UTC)
      - 對於這種情況其實並沒有建議要用抑或不要用空格，還是一句：請按個別情況用常識決定是否加空格。而我這邊顯示「X／Y／Z」和「粒／0」之間衹是少許的緊迫，不覺得對閱讀有很大的妨礙。--街燈電箱150號開箱維修抄錶檢驗證明 2016年3月23日 (三) 06:17 (UTC)

老陳君提的例子在我的畫面上完全正常一點都沒有重疊，所以問題的根源還是自己瀏覽器字型設定或CSS造成的。如果真的有很嚴重的顯示問題疑慮時彈性的運用空格或許可以接受，但原開題者顯然是想要求全面性的開放，這問題就嚴重了：如果他覺得空格比較美觀、我覺得空格不美觀，所以不同的人編輯時有不同的格式，搞得整個中文維基格式不統一亂七八糟，更嚴重時還可能因為不同審美與習慣的用戶編輯同一文章時反覆新增或刪除空格導致編輯戰，各位還覺得不規定一個格式原則是好事嗎？還有，英文原本就有標準的空格使用格式，所以根本不需特別在維基百科中規範，但中文與英文字之間的介面並不在標準中文的格式規範中，所以我們才會需要在這裏提出討論，二者狀況不全然相同不該直接類比。--泅水大象™ 訐譙☎ 2016年3月23日 (三) 06:21 (UTC)

敝人還是覺得不應該有標準，單是我本人加不加空格就已經很多不同的處理方法，比如說：如果中文字後面接着一個英文單字的話，我通常不會空，但是如果是接一組英文片語或句子的話，則通常會有空……還有許多層出不窮的情況令我施加變化，許多時候甚至要看正文表述了甚麼內容才得以決定值不值得加空格。所以還是維持現有的自由度，統一建議我完全也不見得是好事，尤其是某一條目用不用空格的做法又未必適合用到另一條目的時候。--街燈電箱150號開箱維修抄錶檢驗證明 2016年3月23日 (三) 06:42 (UTC)

那也是建立在電箱君大體上是瞭解中文維基基本的格式規則、只是在必要時略作調整，跟整個不訂定格式準則隨各人喜好發揮是兩回事。中文維基有些軍事或汽車相關的條目，當初編輯的用戶是直接拿英文維基條目的內容copy & paste過來之後逐字中譯，所以會留下跟英文一樣的字間空格等「遺跡」，整個條目看起來就是像狗啃過一樣東一塊白西一塊缺，完全無法體會其中的美感何在，只給人一種整體品質低落的印象。中文維基還是應該有一個基本的格式規範定義大部分情況下的版面撰寫方式，再保留必要時個案調整或討論的空間，而不是完全不設格式標準，這是完全不同的兩種狀況。--泅水大象™ 訐譙☎ 2016年3月23日 (三) 06:58 (UTC)

定下建議理應是衹有很少量的例外情況，但是關鍵是在這個空格的問題上無論我建議要有空格還是不要有空格，我預視到都會出現大量的例外，即不存在所謂的大部分情況都適用的方法，所以就算訂定了也不會有意思。--街燈電箱150號開箱維修抄錶檢驗證明 2016年3月23日 (三) 07:11 (UTC)

我倒是抱持着不太一樣的看法，我認為如果有訂定原則但允許在需要時例外，乍看之下似乎與沒訂定原則一樣，但實際上意義不同。因為這表示若想要有例外就必須要提供必要性的證明，如無特殊必要還是要回歸標準格式，萬一有天真的有兩名用戶因為要不要加空格而發生爭議時，我們就可以根據該空格的添加是否有功能上的必要性來作為衡量的依據，而不會因為無規則來源可供判斷而陷入意氣之爭。別說我杞人憂天這時就在思考編輯戰之類的情況，事實是多年下來的經驗告訴我們就是這種事最容易導致編輯戰，所以我這是在未雨綢繆。--泅水大象™ 訐譙☎ 2016年3月23日 (三) 07:32 (UTC)

英文維基對於空格置入的規則相當具有彈性，甚至多種空格置入格式可以存在於同一條目，或許這是我們可以借鏡之處： [3]

In normal text, never put a space before a comma, a semicolon, a colon, or a terminal punctuation mark. Put a space after these, unless they end a paragraph or are followed by a closing parenthesis, quotation mark, or similar. The number of spaces following the terminal punctuation of a sentence in the wiki markup makes no difference on Wikipedia; the MediaWiki software condenses any number of spaces to just one when rendering the page. For this reason, editors may use any spacing style they prefer on Wikipedia. Multiple spacing styles may coexist in the same article.

一般而言，原始碼的空格顯示問題可以由MediaWiki軟件處理，如果MediaWiki軟件可以處理這問題，為什麼要強硬規定編輯者怎樣置入空格？在原始碼內適當地置入空格可以幫助閱讀與維持原始碼，除去這些空格，則原始碼會變得像古文一般地難讀難懂。我們應該幫助編輯者進行編譯的工作，而不是設定規則要求他們做一些「軟件可以做的工作」。--老陳（留言） 2016年3月23日 (三) 22:36 (UTC)

我看完上面那段規則後怎覺得英文版的空格輸入規則很嚴格？裏面用了「never」「unless」這種語氣很強烈的字眼，明確規定分號、逗號、句號前面「絕對」不能加空格，這些符號後面除非緊接括號括號否則「一定」要加空格（原句用動詞原形「Put」起頭，表示是強命令句型）。最後面那段是在說因為系統會自動壓縮空格，因此用戶可以自行選擇自己喜歡的空格輸入格式（原文是「Multiple spacing "styles"」），言下之意您為了編輯便利輸入單格的空格、雙格的空格或多格的空格顯示結果都一樣，但是輸入空格的「位置」可是有嚴格規定的，並非老陳君所想像與主張，希望能由用戶自行選擇輸入空格「位置」的作法。所以，您舉例英文維基的規則其實正好否決了您自己的提案。--泅水大象™ 訐譙☎ 2016年3月24日 (四) 03:25 (UTC)

謝謝您的關注與意見！希望您翻譯英文時，務必要仔細嚴謹，不能斷章取義：

In normal text（在正常文句裏）：這不包括特別案例，例如，模板內的原始碼、數學公式與正常文句之間的界面等等。英文維基沒有對這些特別案例做出規定。
Multiple spacing styles may coexist in the same article（多種空格置入格式可以共存於同一篇文章）：請注意到英文單字「coexist」。--老陳（留言） 2016年3月24日 (四) 05:34 (UTC)

斷章取義的是您吧？

1. 原文是說in normal text沒錯，但是它並沒有說「模板內的原始碼、數學公式與正常文句之間的界面」可以加空格，那是您自己單方面的衍生解釋，能不能被接受尚有討論空間。

2. coexist的主詞是「spacing styles」（空格的格式），也就是我提過同一條目內空格是要打單字元、雙字元或多字元都沒差，因為系統會自動壓縮調整，但是您的主張其實是在討論空格安插的「位置」，請問原文中何處有說各種不同的安插位置規則可以coexist的？

希望您翻譯英文時，也務必要仔細嚴謹，不該把自己的主張混入對規則的翻譯中。--泅水大象™ 訐譙☎ 2016年3月24日 (四) 06:13 (UTC)

謝謝提醒！我覺得「在中文語境內，文字之間應該不留空格」這句子寫得不夠明確，很容易引起不同的詮釋。因此，我提議改寫為「在中文語境內，中文文字與中文文字之間應該不留空格」。其他論題可以留待以後商討。希望獲得大家共識，不知道您覺得可否這樣改寫？--老陳（留言） 2016年3月25日 (五) 05:45 (UTC)

不可以，如果這樣改寫等於變相允許中文與英文字之間可留空格（所謂中文「語境」，就表示包含在中文文章中插入英文字的情況，但排除整句都是外文內容的情況，原規定其實寫得很清楚）。如果要改，還是應該先獲得社群共識後再依照討論結果修正。--泅水大象™ 訐譙☎ 2016年3月25日 (五) 07:16 (UTC)

按照您的說法，為了避免爭議，我提議將這句子改寫為「在中文句子內，中文文字與中文文字之間應該不留空格」。--老陳（留言） 2016年3月26日 (六) 14:10 (UTC)

(：)回應原文中的中文「語境」原本就是泛指以中文作為主體，只是局部插入外文字的情況，包括中文與中文字之間，也包含中文與外文字體之間，僅有全段皆為非中文（也就是外文語境）的狀態下允許插入空格。所以，您這樣的狹義定義乍看之下好像是要把規定解釋清楚，但實際上根本是暗渡陳倉把您的主張混入規則中，是很不妥的作法。如果您想要自己的主張被實現就請等討論流程完成之後再說，但很顯然一路看下來支持您主張的用戶僅屬少數。--泅水大象™ 訐譙☎ 2016年3月28日 (一) 05:26 (UTC)

從2010年至今，與User:Πrate和其傀儡為了一個空格而發生爭執的用戶顯然不是少數（例如User:ArikamaI），Wikipedia:五大支柱：「維基百科不墨守成規：維基百科制定有方針與指引，但並非板上釘釘不可更改，其內容和解釋可以逐漸發展完善。它所蘊含的原則和精神比字面措辭更為重要，並且有時為了改善維基百科允許有例外。」--Mewaqua（留言） 2016年3月28日 (一) 05:38 (UTC)

又加一個例子，User:Πrate的傀儡在眾多條目的參考文獻裏刪掉新聞標題中用作分隔句子的space（例如聖人瀑布，如把「開放聖人瀑布溪山里民疾呼」改成「開放聖人瀑布溪山里民疾呼」），增加閱讀上的不便。--Mewaqua（留言） 2016年3月28日 (一) 05:53 (UTC)

參考文獻非主文本就不在格式手冊規定的範圍，直接依照文獻來源原本的格式也屬合理。M君舉的例子正證明了相關的格式規則還是要訂以避免編輯戰的可能，但規則若有不恰當之處隨時都可提出檢討修改，或在必要時彈性調整，但給編輯用戶一個基本的遵循依歸還是很重要的。--泅水大象™ 訐譙☎ 2016年3月28日 (一) 06:11 (UTC)

從英文維基輸入至中文維基的參考文獻與模板，其內部遍佈了很多空格，這是為了使得原始碼易讀易懂，MediaWiki軟件會自動處理這些空格。請問您是否贊成允許空格在參考文獻內存在？請問您是否贊成允許空格在模板內存在？--老陳（留言） 2016年3月30日 (三) 00:33 (UTC)

這跟英文維基無關，系統處理模版時原本就會忽略掉文字（無論中文英文）前後的空格，但不會忽略文字與文字間的空格，但是閣下明明在講的就是在文字與文字（例如中文與英文字母間的介面）插入空格的主張，且明明討論的就是主文部分，為何老是拿不相干的事情來混淆視聽？--泅水大象™ 訐譙☎ 2016年3月30日 (三) 06:36 (UTC)

一個條目不只是只有主文部分，它還包括條目名、主文、標題、參考文獻、模板等等。所以，您不反對在參考文獻、模板內的空格可以存在。--老陳（留言） 2016年3月31日 (四) 22:15 (UTC)

不會實際在畫面中顯示出效果的空格我不在意，參考文獻中的title欄位原本就是用來顯示原文，因此比照原文格式也是合理，其他部分請遵守格式守則。--泅水大象™ 訐譙☎ 2016年4月1日 (五) 02:51 (UTC)

很高興能夠達成共識:-)！--老陳（留言） 2016年4月1日 (五) 22:34 (UTC)

(－)反對中文與英文之間加入空格。--喜歡用IRC的Carrotkit 2016年3月26日 (六) 12:39 (UTC)

謝謝表達您的意見！尚未到投票階段。是否可以給出反對理由?--老陳（留言） 2016年3月27日 (日) 22:11 (UTC)

(－)反對在任何地方加不必要的空格，包括中英文之間。--Antigng（留言） 2016年3月27日 (日) 06:29 (UTC)

謝謝表達您的意見！尚未到投票階段。可否詳細指出，甚麼是必要，甚麼是不必要？--老陳（留言） 2016年3月27日 (日) 22:11 (UTC)

從來沒考慮過這個問題，於是看了一下我之前寫的條目，確實沒有在中英文之間加空格的情況。這應該是我潛意識下的做法。實際上Micrososft Word這類軟件的做法是自動在中英文之間留白（自動檢測，然後空出間距，不必手動添加空格）。這應該是CSS/JS就能做到的。斜體的情況下，Y⁰的例子下，我的顯示重疊了，看起來幾乎像是Y^theta（字體：Yu Mincho）。我覺得在這種情況下可以加上空格。Bluedeck 2016年3月27日 (日) 23:54 (UTC)

那為什麼斜體後面就不能用JS/CSS加……--Jimmy Xu ^論 2016年3月28日 (一) 00:41 (UTC)

很有趣的是「Y⁰」這個狀況並不是該利用空格修正格式的好場合，因為如果在斜體字後方加空格來修正，雖然原本有字體重疊問題的用戶看到的畫面正常了，但原本顯示很正常的用戶，卻反而會看到「Y」跟「⁰」之間被明顯拉開看起來不太像指數符號的情況。若要修正這問題，使用CSS調整恐怕才是治本的方法。--泅水大象™ 訐譙☎ 2016年3月29日 (二) 04:19 (UTC)

{{Lang|en|''Y''0}}，顯示為Y⁰。--Mewaqua（留言） 2016年3月30日 (三) 02:09 (UTC)

所以意思是說其實斜體後面的文字重疊問題，用lang模版就能解決？（在我所使用的瀏覽器/字碼版本上有沒有加lang的顯示效果一模一樣，所以無法分辨）--泅水大象™ 訐譙☎ 2016年3月30日 (三) 06:38 (UTC)

可是我這裏看這樣也會重疊？（雖然感覺沒那麼重疊，但是可能是因為文字較粗造成的錯覺）-和平、奮鬥、救地球！^論・自於 2016年3月31日 (四) 04:30 (UTC)

不就是說明了可以通過CSS（或者HTML標籤渲染機制）來解決？{{lang}}只是將相應語句用帶有lang屬性的span包裹，然後讓瀏覽器根據語言來推斷字體庫，有些字體庫能支持斜體字符不覆蓋，有些字體庫不能。——路過圍觀的Sakamotosan 2016年4月1日 (五) 01:03 (UTC)

我的發言欠缺考慮，我同意Y⁰是不應使用空格拆分的。Bluedeck 2016年3月31日 (四) 17:26 (UTC)

如果中文和英文之間要增加間距，則用JavaScript或CSS技術性解決，禁止人為在原始碼級別加空格。如果中文和數字之間要增加間距，則用JavaScript或CSS技術性解決，禁止人為在原始碼級別加空格。如果學習User:Cdip150的做法，中文和英文短語之間不加間距，和英文句子之間增加間距，則用JavaScript或CSS技術性解決，禁止人為在原始碼級別加空格。--Gqqnb（留言） 2016年4月1日 (五) 07:02 (UTC)

在下面的例子中，我沒有在原始碼里添加任何空格，CSS在實現中應為JavaScript所加：緊湊型中文Condensed Text；疏散型中文Scattered Text--Gqqnb（留言） 2016年4月1日 (五) 07:09 (UTC)

很有意思的方法，讚！--老陳（留言） 2016年4月2日 (六) 06:39 (UTC)

JavaScript與CSS技術屬電腦領域，只有電腦專家懂得怎樣正確操作這種高階技術，普通編輯者只能望洋興嘆，請問是否能夠給出一些普通編輯者能夠容易操作的方法？--老陳（留言） 2016年4月3日 (日) 05:04 (UTC)

margin-right不太合適吧，這樣原始碼就很難看了，還不如一個空格美觀。--Nbdd0121（留言） 2016年4月5日 (二) 16:40 (UTC)

「CSS在實現中應為JavaScript所加」沒有人需要在原始碼里手工編寫這些代碼。--Gqqnb（留言） 2016年4月9日 (六) 00:54 (UTC)

@Gqqnb：(－)反對 JS會延後加載，這種方法不可避免的會出現頁面閃一下。--Nbdd0121（留言） 2016年4月9日 (六) 16:05 (UTC)

@Nbdd0121：(－)反對，我不知道你對JavaScript或計算機科學的了解有多深，我不想說我計算機科學經歷，但現在幾乎沒有網站不用js，技術問題就可以技術處理。不要一直動原始碼的主意。--Gqqnb（留言） 2016年4月10日 (日) 20:03 (UTC)

@Gqqnb：(：)回應，我也不知道你對JavaScript或計算機科學的了解有多深，但你需要知道MediaWiki的JavaScript是通過ResourceLoader Queue延遲加載的。如果你要通過JavaScript來修改界面樣式，那麼不可避免的會出現閃爍。如果段落較長，修改margin或者letter-spacing的效應堆加起來甚至會影響整個頁面的排版。--XYZ指示物（留言） 2016年4月10日 (日) 20:38 (UTC)

(！)意見我認為這件事需要分情況來看：如果英文是按照中文的語法作為一個名詞插入在文中，這種時候應該不加空格；其他情況下，語法聯繫沒有那麼緊密的場合，是否添加空格就不需要管的那麼嚴格。另外重疊的情況其實<math>可以很好的解決，可惜維基用的基於圖片的<math>難免帶來一點麻煩： $Y^{0}$ --Nbdd0121（留言） 2016年4月5日 (二) 16:40 (UTC)

(＋)支持個人認為對於純文本編輯或者標記語言適當留白的做法，不論對於頁面顯示，還是原始碼檢視都有助於優化可讀性，美觀性。適合添加空格的場景如：中文與英文之間，中文與數字之間，英文與數字之間（不包括專有組合如奧迪 A8，AK47 等）建議這幾種場景在邊界兩端加空格，遇到標點符號或句尾在單邊加空格或不加。僅供參考：為什麼你們就是不能加個空格呢？ Pityonline（留言） 2016年4月9日 (六) 01:41 (UTC)

感謝支持！在英文裏，空格扮演很重要的角色，在中文原始碼裏，我們也可以給予空格一些有助於可讀性、美觀性的功能，避免過度限制編輯者置入空格的行為。--老陳（留言） 2016年4月9日 (六) 06:15 (UTC)

(＋)同意部分同意，不過如果只有一個單詞的專有名詞按照中文語法放在句子中，加上空格會不會讓人感覺在強調一樣？--Nbdd0121（留言） 2016年4月9日 (六) 16:05 (UTC)

您提出了一個很好的問題！在維基百科裏，有幾萬個條目，其中，有些條目品質優良，但也有些條目品質粗劣，怎樣分辨優質的條目與劣質的條目，這是我們編譯者時常要面對的工作。我覺得格式手冊空格章節的規則有改良的必要，特別是在原始碼方面，所以提出討論，嘗試加以改良，希望能夠獲得共識。--老陳（留言） 2016年4月10日 (日) 22:03 (UTC)

對於「一個質量為m的粒子」，兩個用戶看到的結果不一樣

用戶1的瀏覽器的結果：一個質量為m的粒子

源代碼：一个质量为''m''的粒子

用戶2的瀏覽器的結果：一個質量為m的粒子

源代碼：一个质量为''m''的粒子

如果字母m前面加入空格

用戶1的瀏覽器的結果：一個質量為m 的粒子

源代碼：一个质量为''m'' 的粒子

用戶2的瀏覽器的結果：一個質量為m 的粒子

源代碼：一个质量为''m'' 的粒子

可以看出，「加入空格」給不同用戶帶來的影響不一

CSS letter-spacing我想應用在「m的」這部分文字，效果跟「加入空格」差不多，後者調整的單位是空格，前者的單位很小 - John doe 120（留言） 2016年4月23日 (六) 08:26 (UTC)

打開網頁[4]，然後右鍵點擊「一個質量為m的粒子」，點擊「Inspect」...發現問題的起源是Vector screen styles...不多說了，下面的代碼從個人的vector.css複製，「預覽」按鈕好像有問題


/* 取代[https://phabricator.wikimedia.org/diffusion/SVN/browse/trunk/phase3/skins/vector/screen.css?view=markup]的font-family規則
   參考資料：[http://stackoverflow.com/questions/2436749/how-to-add-multiple-font-files-for-the-same-font] */
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    /* 部分瀏覽器不支持codepoint range，[https://developer.mozilla.org/en/docs/Web/CSS/@font-face/unicode-range#Browser_compatibility] */
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    font-style:italic;
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    font-weight:bold;
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    font-weight:bold;
    font-style:italic;
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@media screen{
    body{
        /* Ampersand這名字沒有任何意思 */
        font-family:Ampersand,sans-serif;
    }
}

- John doe 120（留言） 2016年4月26日 (二) 12:16 (UTC)

以下文字的「或」字可能被部分中文用戶忽略：

法厄同星（Phaeton或Phaëton，有時也拼寫為Phaethon）是位於

改成：

法厄同星（Phaeton 或Phaëton，有時也拼寫為Phaethon）是位於

從右到左看，「或」字可能被忽略，以上文字改成：

法厄同星（Phaeton 或 Phaëton，有時也拼寫為 Phaethon）是位於

—John Doe 120（talk） 2016年5月8日 (日) 11:37 (UTC)

難道就沒人會用LaTeX嗎？

這是 $X$ 粒子、 $Y^{0}$ 粒子、 $\Sigma ^{-}$ 粒子？--⁴Li 2016年4月30日 (六) 04:44 (UTC)

@李4：我就真的不會....你肯定維基上有教學?--Temp3600（留言） 2016年5月8日 (日) 13:26 (UTC)

大家來學LaTeX（我隨便找的，自己沒看過）。Bluedeck 2016年5月12日 (四) 00:20 (UTC)

中文維基教學於Help:數學公式。--Emphrase（留言） 2016年5月29日 (日) 18:50 (UTC)

使用LaTeX已六年，雖然頻率不高，我推薦使用英文Wikibooks當LaTeX參考手冊，一打開首頁就有個大大的LaTeX，屬於特色書籍。— Bieraaa 於世界統一時間 (UTC) 2016年5月26日13時21分留言

提議修改格式手冊中的空格章節

從英文維基輸入至中文維基的參考文獻與模板，其內部遍佈了很多空格，這是為了使得原始碼易讀易懂，MediaWiki軟件會自動處理這些空格，所以，按照泅水大象™ 、Mewaqua與我先前達成的共識，我提議，添加一條規則：

在參考文獻、模板內可以保存適當數量的空格。

請大家投票與發表意見，謝謝！--老陳（留言） 2016年4月2日 (六) 06:05 (UTC)

多餘，格式手冊針對空格本來就有這麼的規定：「如果官方宣佈的名稱內含有空格，以官方為準。」參考文獻標題是文獻的官方給的，所以它帶有空格本來就已經被允許。還有請不要把討論分開多個山頭，都不知應該在哪裏討論才好。--街燈電箱150號開箱維修抄錶檢驗證明 2016年4月2日 (六) 06:21 (UTC)

在格式手冊的空格章節裏表明，「在中文語境內，文字之間應該不留空格」。這規定意味着嚴格限制空格的存在，不只是在標題內而已。我不清楚您對這規定如何詮釋，但我覺得這規定並未給予編輯者足夠的詮釋空間。為了避免有些破壞者利用這規定進行大量刪除空格的無建設性編輯，並在其中夾雜着錯誤編輯，如在聖人瀑布裏的惡性編輯，所以才提議添加規則。關於在哪裏討論才好這問題，我不會堅持己見，請問應該在那裏討論較好？--老陳（留言） 2016年4月3日 (日) 00:27 (UTC)

我仍然認為不需要添加，其實我上面說的話本身也有點多餘，因為我是假設該節適用於參考文獻的來跟您說，不過實際是不適用的，因為該節已經說了「在中文語境內」，但參考文獻本身就不是成句話，所以不算是「語境」，繼而如大象兄所說，根本不在格式手冊規定的範圍內。（討論的位置應該在#空格延續，而不是現在這裏另起爐灶）--街燈電箱150號開箱維修抄錶檢驗證明 2016年4月3日 (日) 06:58 (UTC)

已移動討論位置。--老陳（留言） 2016年4月4日 (一) 01:37 (UTC)

術語「中文語境」缺乏明確定義。是否應該對於術語「中文語境」給出明確定義？假若中文語境不包括參考文獻在內，那中文語境到底包括甚麼部分在內？--老陳（留言） 2016年4月7日 (四) 05:25 (UTC)

聖人瀑布模板內的空格編輯，為非建設性編輯，應避免。「17 公尺」去除空格，符合格式手冊規定。民國紀年的替換我暫保留意見。參考資料里author、title去除空格不正確，這項屬於嚴重錯誤。--Gqqnb（留言） 2016年4月9日 (六) 01:02 (UTC)

按照您的說法，「17 公尺」前面與後面的空格都符合格式手冊規定，只有在「17」與「公尺」之間的空格不符合格式手冊規定；換句話說，中文語境前面與後面的空格都可以存在，只有在中文語境內部不能存在空格。關於中文語境的範疇，中文語境不包括參考文獻、模板、表格在內，而是參考文獻、模板、表格內部包含有中文語境。請問您是否同意這表述？--老陳（留言） 2016年4月9日 (六) 05:55 (UTC)

首先明確，我們討論的是原始碼內的空格，還是渲染後的空格。我認為我們討論的是渲染後的空格。凡是改動在原始碼里的、不影響渲染的空格，都屬於代碼格式，屬於「維基原始碼規範」或「HTML代碼規範」。對於作為模板參數等其他直接輸出至頁面的空格，區分是否為中文語境。height = ...中的等號之後第一個非空白字符開始為模板參數，所以「17」與「公尺」之間的空格不符合格式手冊規定。而格式手冊規定的是渲染後的頁面的格式，而不是原始碼格式，所以「17 公尺」前面與後面的空格屬於無規範狀態（加不加都不影響輸出效果），所以我才說是非建設性編輯。我(＋)同意參考文獻、模板、表格內部輸出為HTML的文本部分（區別於標籤）包含有中文語境。17 公尺輸出為17 公尺，其中style前後的空格、冒號前後的空格都屬於原始碼中輸出至HTML標籤的空格，非格式手冊規範的空格，而span的文本為「17 公尺」，是輸出為HTML的文本。--Gqqnb（留言） 2016年4月10日 (日) 20:23 (UTC)

@Gqqnb：謝謝您對於這論題的仔細分析！

為了避免搞不清楚「空格」到底指的是甚麼，我們應該明確區分原始碼內的空格與渲染後的空格，暫且稱渲染後的空格為空距，因為渲染程序最後會展示出多少空白是決定於渲染軟件的輸入參數。按照您的說法，原始碼內的空格安置是屬於「維基原始碼規範」，而渲染後的空距是屬於格式手冊規範。請問我這樣表述是否符合您的說法？
關於您所提到的文本問題，我不清楚「文本」指的是甚麼？所以無法明確表達我的意見。
關於「17公尺」的問題，假設在原始碼內，「17」與「公尺」之間是否可以有空格屬於「維基原始碼規範」，不屬於格式手冊規範；在渲染之後「17」與「公尺」之間是否可以有空距屬於屬於格式手冊規範。請問您是否同意這說法？--老陳（留言） 2016年4月13日 (三) 05:46 (UTC)

@老陳：,(＋)同意「原始碼內的空格安置是屬於「維基原始碼規範」，而渲染後的空距是屬于格式手冊規範。」。
如果你在瀏覽器頁面上右鍵，選擇查看網頁原始碼（Chrome瀏覽器用語）/查看源（IE瀏覽器用語），你會看到類似<html lang="zh-CN" dir="ltr" class="client-nojs"><head><meta charset="UTF-8"/><title>维基百科:互助客栈/方针 - 维基百科，自由的百科全书</title>的內容。「文本」是HTML技術角度的詞。這裏的大意是「查看HTML原始碼」所顯示的內容，也不受格式手冊規範。
(＋)同意「假設在原始碼內，「17」與「米」之間是否可以有空格屬於「維基原始碼規範」，不屬于格式手冊規範；在渲染之後「17」與「米」之間是否可以有空距屬於屬于格式手冊規範」。這就是我表達的意見，即原始碼可以有空格但渲染後無空距；或者原始碼無空格但通過js或css的幫助，渲染後產生空距。--Gqqnb（留言） 2016年4月13日 (三) 06:07 (UTC)

(－)反對，反對在數字和漢字，或英語和漢字之間插入空格。反對「13 公斤」，反對「13 kg」，也反對「km / h」，應寫成「13公斤」、「13kg」和「km/h」。--7（留言） 2016年4月9日 (六) 14:35 (UTC)

謝謝您的意見！希望能夠給出理由，大家集思廣益。我覺得Pityonline推薦的網絡文章為什麼你們就是不能加個空格呢？相當有閱讀價值，建議您有空時不妨點閱。--老陳（留言） 2016年4月10日 (日) 05:47 (UTC)

7 的說法是有道理的，所謂適當留白，至少需要保留一些自有格式，不要改變原義，或造成歧義，亦非一味地為增強可讀性與美觀性而拙劣地添加不恰當的空格。不過我建議單純的數字與不包括帶「/」的中文單位間應該留白，如 13 公斤，3 份等，遇 13kg，13公斤/人，80km/h 這種，數字與右邊文字不應留白，但數字左邊應該留白。Pityonline（留言） 2016年4月10日 (日) 06:09 (UTC)

同樣反對「左邊留白」，反對「體重 70公斤」，反對「距離 3000公里」，反對「風速 200公里/時」，應寫成「體重70公斤」，「距離3000公里」，「風速200公里/時」。--7（留言） 2016年4月10日 (日) 16:22 (UTC)

根據國際單位標準規定，數字與單位之間應有空格，因此「13 kg」是正確寫法，這也是絕大多數學術書籍與期刊採用的做法。至於中文語境，尚未找到相關標準，給出此文供參考。--Wcam（留言） 2016年4月10日 (日) 22:57 (UTC)

看了這個，果然留白沒什麼不妥的，而且 w3c 亦有此說明。Pityonline（留言） 2016年4月11日 (一) 00:48 (UTC)

同意Jarodalien的意見。中文語境中，傳統上並無空格。我看到的專業文獻中，也幾乎沒看到這麼做的/要求的。很多時候中英/數字混排當中出現的空白並不是空格，而是排版軟件自動優化的結果（所以，增加空白可以考慮，增加空格或其他類似字符反對）--百無一用是書生 (☎) 2016年4月12日 (二) 02:25 (UTC)

如覺得數字與中文字之間要增加空白，應是採用修改CSS的方式全面調整，而不是用人工方式插入空格。所以我同意書生兄所言，別把空白跟空格兩件事搞混了！--泅水大象™ 訐譙☎ 2016年4月12日 (二) 07:19 (UTC)

我現在傾向於添加空白，並且以在原始碼中添加空格的形式添加。理由如下

中英文中需要有空白：閱讀了一下 Pityonline 給出的 W3C 草案，另查閱了一下相關資料，中英文之間需要有 1/4em 的空白，Word 等排版引擎也早已遵循了這一要求。
不適宜使用 JS 添加：用 JS 添加理論上是可行的，但是如同我上面提到過，用JS添加需要等到 DOM Ready，在這之前頁面已經呈現，不可避免地出現閃爍。
尚無純 CSS 解決方案：純 CSS 的解決方案需要 CSS Level 4 中的 text-spacing，目前除了 IE 實現了 -ms-text-autospace 以外，其他瀏覽器不支持該屬性，也沒有其他純 CSS 解決方法。
W3C 草案中提到可以使用一個西文空格做該空白的代替。

--XYZ指示物（留言） 2016年4月12日 (二) 12:52 (UTC)

那麼我反對這種手工加空格的做法，就像現實生活中看到這種稿件直接退稿不看一樣，看到有這種來參加任何條目評選一概反對。我並不覺得這樣更加美觀，恰恰相反，覺得更難看。像小時一樣，我也從來沒有在任何論文看到過這種手動加空格的做法。英語不過是有空格分隔單詞的習慣。至於那篇一開頭就在下定論搞攻擊，說什麼「有研究顯示，打字的時候不喜歡在中文和英文之間加空格的人，感情路都走得很辛苦，有七成的比例會在 34 歲的時候跟自己不愛的人結婚，而其餘三成的人最後只能把遺產留給自己的貓。畢竟愛情跟書寫都需要適時地留白」的狗P文章，我完全可以寫個長篇大論意見完全相反的發表出來。--7（留言） 2016年4月12日 (二) 13:23 (UTC)

即使可能造成頁面閃爍仍然希望有pangu.js之類的小工具。大面積排版閃爍應該不至於（瀏覽器對 U+0020 還是敢壓縮的）。如果有精力的話我可能會考慮移植 https://css.hanzi.co/ （實現上用了span而不是空格字符）。--Altoria 2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)

話倒不用說的這麼死，好歹上面W大有提出規格文件證明有些是需要空格，而閣下只是印象不該加。--Liaon98 _我是廢物 2016年4月12日 (二) 13:30 (UTC)

對於W3C草案問題，我覺得可以與他們討論對草案進行修改（如果覺得加空格不合適的話）--百無一用是書生 (☎) 2016年4月13日 (三) 02:42 (UTC)

W3C的《中文排版需求》還是working draft（草稿），還差三個版本才能成為正式的「推薦標準」，不可迷信。不過國家標準技術研究所的標準倒是可做參考。那個github上的規範，這是個論述還是什麼，不清楚它的效力。--Gqqnb（留言） 2016年4月13日 (三) 06:32 (UTC)

W3C CLREQ草案本身基本就是個論述，或者說「中文排版有這麼多東西你要能在瀏覽器裏面實現」的需求書。對於日語（JLREQ）、韓語（KLREQ）亦有類似的文檔，其中JLREQ我記得風評很不錯。我個人認為加空格只能說是個人肉polyfill，只不過大家都用罷了。當然啦，作者裏面我至少能叫出兩個很明確地支持在純文本裏面加空格的人（於是你可以認為NPOV上面不對勁）……（可以說大部分我看到過的這方面的人日常都順手加空格，包括我（以至於我上維基百科腦子需要多繞一圈（不要吐槽我的括號層數多（The Jargon File裏面有講這個的地方）））。）--Altoria 2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)

所以，根據國家標準技術研究所的規定，當表示數量時，在數字與單位之間必須有一個空格的空距。--老陳（留言） 2016年4月15日 (五) 05:29 (UTC)

該單位規定的是美國、用英文撰寫時的格式，是關中文維基啥事？別混淆視聽。--泅水大象™ 訐譙☎ 2016年4月15日 (五) 05:32 (UTC)

他山之石，可以攻錯。更嚴格地表述，根據國家標準技術研究所的規定，當表示數量時，在阿拉伯數字與英文單位之間必須有一個空格的空距。--老陳（留言） 2016年4月16日 (六) 05:24 (UTC)

那仍然只定義了數字跟英文單位之間的格式，但是上面的討論是針對數字、英文與中文之間的格式介面問題，純英文的格式標準仍然毫無參考價值，不提也罷。--泅水大象™ 訐譙☎ 2016年4月19日 (二) 04:46 (UTC)

這是第一階段，暫且只能這樣。如有任何建議，請多指教，謝謝！--老陳（留言） 2016年4月22日 (五) 00:06 (UTC)

英語的數字和單詞之間有空格，不過是因為單詞和單詞之間有空格，一向是這樣寫的而已，對漢語沒有任何參考價值。英語寫任何一句話，中間用標點分隔時也會在標點後方加上空格，這對漢語又有什麼意義，如果這種也有參考價值，那完全有理由推論今後每個漢字和漢字之間也要加個空格。所以極力(－)反對。--7（留言） 2016年4月22日 (五) 03:19 (UTC)

謝謝您的意見！難道當您在中文句子裏用到英文片語之時，您不會參考英文寫法？--老陳（留言） 2016年4月22日 (五) 04:58 (UTC)

那又怎麼樣，如果是引用一句純粹的英語，那麼按照原文來寫就可以，但是，漢語中即便寫「15kg」而沒有寫「15公斤」，這個「kg」也是按漢語處理的，念出來時要麼念「15千克」，要麼念「15公斤」，不應該念什麼「15（字母）k（字母）g」，這說明漢語中已經接受用這兩個字母來代替「千克」和「公斤」，並不說明這就是在「引用」英語，而是這兩個字母已經成為漢語固有的組成部分。--7（留言） 2016年4月23日 (六) 16:53 (UTC)

支持7的看法。去找個小學生讓他讀出含有「15kg」的數學題，你會聽到他念「十五千克」，而不是「十五可唉雞」或「十五看老米特」。至少已經是漢語的組成部分，至於是固有的部分、自古以來的部分還是不可分割的部分，先不予置評。--Gqqnb（留言） 2016年4月26日 (二) 00:53 (UTC)

這是中國大陸國標GB3100-93[5]，請參考PDF第6頁第六節6.2.4，原文引用如下：「單位符號應寫在全部數值之後，並與數值間留適當的空隙。」。Bluedeck 2016年5月12日 (四) 00:31 (UTC)

在這樣的「適當空隙」有明確定義成「手工加空格」以前，不再進一步回復。--7（留言） 2016年5月12日 (四) 01:36 (UTC)

嗯。確實有這個問題。我覺得實際上本國標PDF中所有^{[我看了的]}樣例中，對此「適當空隙」的實現，均通過一個英文半角空格完成。Bluedeck 2016年5月12日 (四) 02:35 (UTC)

ps，除此而外，我還有這個考慮。很多式子中的變量是代單位的，比如 F=ma。但情況不一定如此，比如 F=mx m/s^2。在無空隙情況下，後者x和m/s^2糊到一起去，只能通過斜體分辨。當然，這是數學公式的部分，不是中文語境的部分。Bluedeck 2016年5月12日 (四) 02:38 (UTC)

謝謝找到這極具價值的資料！我覺得留一個英文半空格是很好的辦法。--老陳（留言） 2016年5月12日 (四) 07:21 (UTC)

支持單位前加空格。別處加空格算是少數我個人喜歡的workaround，不過按道理講的確不該。——Altoria 2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)

請注意在上面提到的中國國家標準中所謂的「單位符號」是指拉丁文字基礎的外文符號，中文的單位在該文件中稱為「單位名稱」，言下之意，如果使用的單位是拉丁文字那麼數字跟文字之間要插入空格（例如17 kg），但是該規則並沒有定義使用中文單位（例如「17公斤」）時要插入空格。--泅水大象™ 訐譙☎ 2016年5月17日 (二) 10:17 (UTC)

謝謝大家發表的意見與建議！假若沒有更多字句，我想將前面內容加以整理，寫成新版提議，交付投票與進一步討論，以達成共識。--老陳（留言） 2016年5月23日 (一) 06:31 (UTC)

(～)補充：至於這空格到底是什麼問題，下面是一篇個人論述。我認為這個論述違反了WP:簡而言之，在此致歉，若不合適請移動論述文到別處。

簡而言之，文本如何呈現，與文本內容為何沒有任何關係，前者是程序自動排版的問題，後者是作者要表達的思想。但因為計算機的計算能力是有限的，許多時候不能指望任何文本框都有強大的排版功能，因此內容有時不能與樣式分離。例如，全形逗號帶有空格，就是內容裏帶了樣式。而我們的內容要手動加入多少樣式，這其實完全是個如何取捨的開放性問題。還是要根據情況靈活分析。比如斜體文本導致字符重疊，手工加入個空格並非不可接受。或者說，如果維基百科對於使用JavaScript對文字之間加入空白沒有困難，當然也可以啟用了。最後，我相信，統一的風格比所謂「正確」的風格要重要的多。— Bieraaa 於世界統一時間 (UTC) 2016年5月27日11時34分留言

個人論述

在排版領域，許多時候都要在文本中加入適當的間隙來優化版面，方便閱讀。何時加入應排版風格而不同，但常見的情況包括文字與標點之間、文字與單位名稱之間、文字與阿拉伯數字之間，或者中文和拉丁文之間。間隙的大小通常是半個到一個拉丁字母左右。

早期，人類使用打字機、印刷機等簡易的機械裝置來進行排版印刷。在這類機械裝置中，每一個字符的寬度是固定的，這個寬度就是一個鉛字的寬度。對於使用拉丁語的人來說，排版需加入適當間隙時，通常只需空出一個鉛字，或者按下打字機的空格鍵。由於空格本來就是拉丁諸語言的組成要素（例如用做分隔單詞，手寫的時候用空白分隔逗號後邊的字母），這沒有任何不妥，何時敲擊多少次空格鍵，依照使用者的排版方針進行。這僅僅是把任何手寫時需要的空白替換為敲擊空格鍵而已。

隨後，東方世界也開始使用打字機、電傳打字機和計算機進行文字處理。由於東方文字是方塊字，因此一個鉛字（不要糾結鉛字、字符或者一個字符的字節數等底層限制，本文將互換使用）的寬度基本上是拉丁文的兩倍，這就導致了一個問題 —— 如果使用空一個字的方式，實現標點符號與文字的間隙，太大了。不過，解決方法還是有的：把標點符號的鉛字也是一個漢字的寬度，但有符號的突起處只有字寬度的一半，剩下一半是空白的。這樣，在排版時，標點符號就會自動帶有空格了。請在簡體中文環境下觀察本文中的逗號。

然而這個方法不是完美的，因為這一定程度上，把使用者決定是否留空隙的權力剝奪，轉交給了鉛字本身，鉛字是一定會有空隙的。使用者不能根據情況調整空格數量。例如這種情況下（觀察下一個括號與逗號之間的空隙），空隙會變得有點大。由於空格是嵌入字符中的，因此無法調整。

很快，人們又有了進行東方文字和西方文字混排的需求。但字符的寬度是固定的！因此，要麼將拉丁文強行拉長，要麼將東方文字強行壓扁 —— 這兩種方法在日本早期都有嘗試，分別是全形英文（例如Ｅｎｇｌｉｓｈ）和半角假名（ｱﾁﾑ）。前者強行將拉丁文拉長，後者將文字壓扁，閱讀起來都非常難受。另外，單位名稱的排版問題還沒解決呢！於是人們又搞出了一堆字符，僅僅用來表示單位名稱。例如千瓦（㎾和㌗）、千克（㎏和㌕），看到沒有？一個字符居然強行裝四個假名。除此之外還有什麼麼安培啊、帕斯卡啊、法拉第啊等計量單位，詳見這裏。此外，漢語中的也有計量用漢字。雖然這只是借鑑了日文中的多音節漢字，和為了排版造字無直接聯繫。但從把計量單位用一個字符表示的角度講，起到的作用是一樣的，例如千瓦（瓩）、英里（哩）、海里（浬）。

接下來，隨着科技的進步，我們又進入了計算機不再用電傳打字機而是鍵盤的新時代。隨着軟件的發展，我們也可以將半角和全形混用，不再受到寬度固定的限制了，可惡的全形拉丁文、單位名稱和半角假名這類東西很少被使用了。全形西文的問題在於，它的空格是在字符內部固定死的，不能根據上下文來加入間隙，而是僅僅為了滿足硬件限制強行加入間隙。但好不容易擺脫了寬度噩夢的人，似乎只要寬度正確，也就不指望文本需要適當的間隙了。

但實際上，如果我們正確的加入間隙，那麼可以達到很好的閱讀效果。但現在的計算機中西文之間沒有任何間隙（總比被迫使用全形拉丁文好啊）。這個問題的根源是 —— 正如早期的計算機只有一種寬度的局限性一樣，現代計算機的局限是 —— 文本處理程序是以字符為中心，而不是文字本身為中心處理文本。並不是說計算機不能幹這事，而是在計算機中，文字輸入和文章排版是完全不同的兩個應用。如果你有一個輸入框，比如維基百科現在的這個純文本編輯器，你不可能指望它主動幫你排版；但你如果在Microsoft Word中輸入一篇文章，該程序顯然可以自動幫你搞定一切關於間隙的麻煩事。不僅僅是Word，從1970年的TeX發展至今的LaTeX甚至能做的更好，在LaTeX中，你按一下空格鍵是完全沒有意義（當然，在單詞中間有意義），因為LaTeX它自己知道什麼時候插入間隙，什麼時候不插入間隙，你的空格對它的排版規則一點影響沒有。

這就叫做呈現與內容分離，它能解決我們從開頭起遇到的任何問題 —— 我們輸入的內容是一句話（如：地球是圓的），但至於這句話應該怎麼呈現（如：登上紐約時報、使用的墨水類型、字號、段首空兩格、字體，或者什麼時候留空隙等），和這句話說得是什麼（地球是圓的）應該完全沒有任何關係 —— 這顯然是合理的。但由於計算機的局限性，我們一直沒有將呈現與內容分離。例如，我們在按下一個逗號時，我不但表示我說話時停頓了一下，還表示我希望在排版時逗號後面有一個空白（如果是英文，我還必須手動輸入這個空白）但這和我的內容一點關係沒有，在一個形而上的完美世界裏，那是遵守格式方針的排版者或者LaTeX需要責任，而不是僅遵守內容方針的我的責任。同理，中英文之間的空隙，不應該由作者作出，而是LaTeX作出。

但我們不可能指望任何輸入文字的地方，都帶有一個LaTeX這樣超級複雜的電腦程式，這是不可能的，就算有，例如維基百科的全部正文可以用LaTeX寫，但這不太適當。可見，我們只能在不同的場合作出適當的取捨。例如，我們要在純文本里加入表格，我可能不得不加入豎線（|）與橫線（-），儘管這和我要表達的土豆多少錢沒有任何關係。而我們怎麼取捨呢？通過在不同的場合，當然是根據情況制定不同的方針取捨。比如我個人會在任何純文本輸入框，手工加入中文和西文的空格。當然了，至於方針的指定，還是要根據情況靈活分析。比如斜體文本導致字符重疊，手工加入個空格並非不可接受。或者說，如果維基百科對於使用JavaScript對文字之間加入空白沒有困難，當然也可以啟用了。

最後，我相信，統一的風格比所謂「正確」的風格要重要的多。更何況這個問題的根源是一個很實際的技術問題，具體的做法是可以非常靈活的，希望大家以更加開放的態度看待這個問題。— Bieraaa 於世界統一時間 (UTC) 2016年5月27日11時34分留言

很有見地！我相當支持你的呈現與內容分離以及Latex的觀點。我上面提出的JavaScript添加空隙，就相當於Latex排版引擎。可惜有人表示JavaScript會引發一次重繪，雖然我不確定一次重繪會損失什麼東西，或是違反了什麼我沒有意識到的維基百科對用戶承諾的服務級別協議。。--Gqqnb（留言） 2016年5月28日 (六) 23:44 (UTC)

謝謝Bieraaa對於呈現與內容分離的詳細說明與精闢見解。我覺得中文維基格式手冊關於空格的規定不夠嚴謹、需要改善，尤其是缺乏設定中文語境的範疇，這問題很容易會被破壞者利用，藉此進行大量刪除空格的無建設性編輯，並在其中夾雜着錯誤編輯，如在聖人瀑布裏的惡性行為。因此，我提議在空格一節添加以下規則：

中文語境不包括參考文獻、模板、表格、數學公式在內。
按照中國國標GB3100-93[6]，第6頁第六節6.2.4，規定「單位符號應寫在全部數值之後，並與數值間留適當的空隙」。

希望大家對此提議發表寶貴意見，熱烈投票，提出具體建議，以達成共識。--老陳（留言） 2016年5月30日 (一) 22:22 (UTC)

(－)反對會對實際顯示效果有影響的地方手工加空格，參考文獻因為不會有任何顯示上的區別，所以可以接受。所謂「不夠嚴謹、需要改善，尤其是缺乏設定中文語境的範疇」不過是有些人就是看不慣沒有空格，要有空格才舒服。這同樣也「很容易會被破壞者利用」，「藉此進行大量加入空格的無建設性編輯」（不好意思我漢語不好，這話說得我彆扭，要說成「以此為藉口專門在條目中加空格，除刷編輯次數和引發編輯外無意義也無任何實際意義」）。6×4看不清楚，還要寫6 x 4才看得清？打個標點都不會打，回頭寫6 X 4可能更清楚一些。--7（留言） 2016年5月31日 (二) 14:34 (UTC)

(：)回應，隨意大量添加空格或刪除空格皆屬無建設性編輯，皆可以回退。關於數學公式的問題，誠如Bluedeck所言，「比如公式 F=mx m/s^2，在無空隙情況下，後者x和m/s^2糊到一起去，只能通過斜體分辨。」數學公式內的空隙處理，這是MediaWiki軟件的渲染問題，MediaWiki軟件自動會處理空格，不應在原始碼內禁止空格存在，影響原始碼的可讀性。數學公式內的空隙不只是看得清楚與看不清楚這問題，它還涉及到整個公式呈現的藝術美觀問題，在這方面仍舊存在爭議，各個編輯者持有不同意見，不應隨便禁止。--老陳（留言） 2016年6月1日 (三) 14:13 (UTC)

我只是想起這個。--Emphrase（留言） 2016年6月3日 (五) 08:22 (UTC)

(：)回應，請問是誰製作的這些頁面？是否可以稍微說明一下？--老陳（留言） 2016年6月6日 (一) 05:49 (UTC)

見 https://github.com/ethantw/Han 。就是我之前提到的 css.hanzi.io，作者是 CLREQ 特邀專家之一（我全都提到過）。--Artoria 2e5_編保持頁面整潔，直接ping我回復。 2016年6月10日 (五) 21:33 (UTC)

(：)回應，這是個商業軟件，不清楚這跟當今的討論有甚麼關係？--老陳（留言） 2016年6月13日 (一) 07:03 (UTC)

但是授權是用MIT自由授權的。--Emphrase（留言） 2016年7月1日 (五) 03:39 (UTC)

好久沒來維基百科，剛剛看見這一討論，未能詳細閱讀，如有重複觀點敬請見諒。有沒有一種技術手段，無論在源碼中有沒有空格，都會自動在漢字和西文（包括公式和數字）間渲染出一個間隙？當有特別情況不願意渲染出間隙的時候，可在源代碼中加入某種語法避免渲染間隙。這種做法與微軟Office的排版方式非常接近。這樣既可以使讀者所看到的條目排版整潔易讀，又能在源代碼編輯上給編者較大的自由度，還能避免全站更改源碼這種浩大的擾民工程。我想上面這個工具就有這個目的。鋼琴小子 留言貢獻 2016年6月14日 (二) 08:56 (UTC)

JavaScript就是解決方法之一，如果社群允許0.1秒的頁面重繪。另一個辦法是修改MediaWiki原始碼，這更強大也更危險。--Gqqnb（留言） 2016年6月15日 (三) 05:05 (UTC)

在英文維基裏，MediaWiki軟件會自動處理空格的渲染。理論而言，源碼可以有任意數量的空格。這給予了編輯者在編輯源碼時很大的彈性，促進源碼的可讀性。在中文維基裏，假若，我們過度硬性規範空格數量，則會影響源碼的可讀性。至於有關MediaWiki軟件如何處理空格的渲染這方面的問題，可能需要請教才女，她是這方面的專家。

空格的渲染涉及到藝術美觀問題。例如，第i個字、第 i 個字，這兩種由於空格的置入與否會產生的不同的渲染效果，前者顯示出英文字母

i

緊緊地擠在「第」與「個」兩個字之間，使用手機閱讀很可能會忽略掉這個英文字母，後者則較為明顯地展現出英文字母

i

。Bluedeck在前面也舉出另外一個例子。這些例子都展示出，我們不應隨便禁止置入空格。--老陳（留言） 2016年6月15日 (三) 06:11 (UTC)

我覺得編輯工具欄可以添加一個按鈕，自動在全文或者選中文本的中英文之間添加空格。—John Doe 120（talk） 2016年6月15日 (三) 08:58 (UTC)
所謂的「藝術美觀」問題是純粹的主觀判斷，上面有人覺得要有這個才更美觀，我偏偏覺得加空格丑爆了，噁心死了，感覺就像一文錢買個夜壺，貴賤不說，根本不是個東西，這又怎麼樣呢。「當有特別情況不願意渲染出間隙的時候，可在源代碼中加入某種語法避免渲染間隙」，所以誰要是不喜歡，抱歉，管不了你那麼多，你自己去學語法慢慢加慢慢整吧，反正默認就是要的，不會那不關我的事。要這樣的話，呵呵，慢慢打吧。--7（留言） 2016年6月16日 (四) 11:12 (UTC)

謝謝您的意見！希望能夠達成共識。--老陳（留言） 2016年6月19日 (日) 21:57 (UTC)

若是在條目中存在任何形式的空格的話，則要刪除不影響句義的空格（如雙星之陰陽師#故事簡介中的空格）--林勇智 2016年6月23日 (四) 10:31 (UTC)

1. 部分情況下不加入空格會造成兼容性問題：谷歌搜尋 [ 5ms inurl:https://zh.wikipedia.org/wiki/VoLTE ]，一個結果，[ "1..11 ms" inurl:https://zh.wikipedia.org/wiki/VoLTE ]，0個結果。

2. 空格對於編程語言的表達式有作用：比如下列 C++ 表達式：1 + 1 * 2，粗略地看一下，不知道哪個操作符先計算，刪除多餘的空格後：1 + 1*2，好像明白了哪個運算符先計算。—John Doe 120（talk） 2016年7月1日 (五) 05:13 (UTC)

華人或東亞的組織，應該附註英文名字嗎？

最新留言：7 年前7則留言6個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2016年9月24日 (六) 00:42 (UTC)。

例如中國國民黨、唐鳳等等，應該附英文名嗎？我認為是不用，因為這些人或組織都是先有中文名再有外文名，中文不是翻譯自外文，而且讀中文條目的人基本上也都是使用中文名稱，如果附了英文那不如也附上所有外國語言的名字。我之前在有些條目看到附英文名字的就會編輯去除，但是在唐鳳的例子，過了幾天又被加回來，顯然有些人認為這是重要的資訊。好像沒有相關的方針？Yel D'ohan（留言） 2016年9月8日 (四) 19:43 (UTC)

@Yel D'ohan：感覺應該分情況討論。對於國民黨，本人認為英文非首要且增添信息有限，但考慮到其在官方網站亦明顯註明之，可以考慮添加，不添加亦可；至於唐鳳，由於其有另一通行稱呼（Audrey Tang），與其本名顯著不同，應當添加。其他東亞或有東亞背景的人物組織，感覺如果沒有特別需要，使用漢語名+母語名或純漢語名即可。--Morningstar1814（留言） 2016年9月8日 (四) 20:37 (UTC)

使用lang-en等模板標出外文。你看這個Audrey Tang，你怎麼確定它是英文、西班牙文還是法文？我先想當然地標註了lang-en，望其它編者指教。
標註外文的爭議在維基百科長年存在，如聯合國，阿拉伯文、中文、英文、法文、俄文、西班牙文都可以標。海牙國際法庭，它標了法文，為什麼不標英文？它屬於聯合國，為什麼不標阿拉伯文？甚至台北、上海、蘋果都可以標外文。跟廢英派相比，挺英派（挺外派）總是比較多。--Gqqnb（留言） 2016年9月13日 (二) 02:25 (UTC)

@Gqqnb：Audrey Tang個人想當然地猜測為英文，當然若有相關來源表明其自稱為「英文名」更好，不過要是我我可能會比較懶惰地在某些地方使用{{lang|en|Audrey Tang}}，語言不自動顯示，直至有來源再修改。

聯合國標註所有官方語言均可，海牙國際法庭個人不了解具體狀況（但其官方網站僅使用英文和法文）——但包括國際刑事法院在內的許多國際組織根據傳統都將英文與法文列為工作語言。若有來源支持（不知大英百科等是否列出兩種表達），應該按來源加入。

完全無法理解為何上海和蘋果需要標註英文……至於台北，因其採用威妥瑪拼音，與通用拼音法不同，但在國際及當地機構亦時常使用，可以作為有用的額外信息添加進去，不過要留在正文「名稱」章節問題也不大（如「Canton」作為廣州的前英文稱呼自然是留到此段落）。

感覺挺英和廢英的存在及分歧有些滑稽——照理來說應當分條目和內容討論的，很難搞大規模採用或廢止……--Morningstar1814（留言） 2016年9月13日 (二) 22:37 (UTC)

「香港中文大學（英文：The Chinese University of Hong Kong；縮寫：CUHK），簡稱中大[註 1]，是一所……」香港中文大學無疑是「華人或東亞的組織」，不過主要教學語言是英文。還有Template:香港特別行政區政府組織架構的各個香港特別行政區政府部門和機構條目基本上全部都加上其英文名稱。--Mewaqua（留言） 2016年9月13日 (二) 02:37 (UTC)

個人認為應該以其官方網站的可選擇語言為可附加基準。例如「聯合國官網」一共有6種語言被官網使用（不計簡繁）（不計不同地區使用方法不同），編者可以在6種語言中選擇性使用————だ＊ぜ（留言） 2017年7月13日 (四) 09:15 (UTC)

標點符號格式標準審查暨條例漏洞彌補機制

最新留言：7 年前1則留言1個人參與討論

現在的維基頁面其標點符號極其凌亂，比如某頁面的上文在使用「比如：···」，下文就被換成「比如，···」。建議制定一個標點符號使用格式的定期複查機制，以wikipedia:格式手冊/標點符號為基準，並彌補其格式標準漏洞 ————だ＊ぜ（留言） 2017年7月13日 (四) 08:56 (UTC) ( ✓ )同意--冷羅KS用戶:KSroido 2019年8月20日 (二) 13:13 (UTC)

條目中附註外文的規範

最新留言：7 年前48則留言12個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年8月8日 (二) 16:42 (UTC)。

有鑑於一些維基人認為在條目中附註英文原文十分必要/有時候沒必要/有時候不行，我寫了一些自己對於附註外文的習慣做法，原文在此，請各位提出各自的意見。

主要想法是，紅字、黑字可標註外文，藍字、綠字一般不可標註外文，但也存在一些例外情況，詳見內文。請各位批判一番。注意該草案僅適用於「專有名詞」，具體什麼是專有名詞，還有待定奪。@NoobWayne

--燃⁠燈 ^談笑風生 2017年7月22日 (六) 21:08 (UTC)

(！)意見：「導航模板（不算作「列表/表格」）可依情況為紅色連結附上對應外語，但不可為藍色連結、綠色連結附上對應外語。」不違反通用標準啊，我覺得不算例外；另外，建議規範下{{lang-en}}和{{lang|en}}的區別。專有名詞的話個人建議比照重定向，為字典查不到的詞。--星巴克女王_{（🎶歡迎參與音樂專題）} 2017年7月23日 (日) 05:30 (UTC)

導航模板的問題主要是想強調一下……算了我合併到#2吧。那兩個模板，我個人也拿不太準，一般我是只在開頭處使用一次{{lang-en}}，別的情況下都是{{lang|en}}，不知道別人怎樣。至於專有名詞的問題，可能要專門開個話題討論了。--燃⁠燈 ^談笑風生 2017年7月23日 (日) 05:44 (UTC)

我覺得這兩個模板的標註沒有那麼簡單，雖說{{lang-en}}一般在開頭用，但如果一篇條目有多種外語需要標註怎麼辦呢？另外有些外文人名實在不好說是哪種語言。所以還是希望能有一套準則規範一下。--星巴克女王_{（🎶歡迎參與音樂專題）} 2017年7月23日 (日) 06:00 (UTC)

(～)補充：另外我覺得這一篇少了日語假名、韓文漢字、越南文喃字是否要標註的規範。不過個人對這些語言不了解，還得請一些日本、韓國、越南專題的編者來探討探討。--星巴克女王_{（🎶歡迎參與音樂專題）} 2017年7月23日 (日) 06:04 (UTC)

(！)意見謝謝燃燈！辛苦了！在下會撥時間詳閱！=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 05:33 (UTC)

(！)意見感謝閣下縝密的思維，在下幾乎完全同意裏面的規矩。

唯一在下認為可以調整的是此條文：

在下認為可以考慮開放專有名詞外語重定向的創建：

「該詞中文儘管是個源自外語的專有名詞但卻過於常見，這種情況下不應該標註外文。（如：有氧運動、曼哈頓計劃）本條讓位於#4。」

比如說：許多國名在兩岸四地各有些微差異。無論是哪個國名應該在各自的境內都算是常見的，不過對於各自境外地區的人來說，可能會有疑問。
專有名詞常見與否，每個人的認知會有差異。
在下這幾天在英文維基百科發現，英文維基百科似乎已經存有許多各類的中文重定向。因此在下認為中文維基百科可以更開放些，開放常見的專有名詞外語重定向的創建，以此作為漸漸地向英文維基百科靠攏的第一步 (其它前幾大的維基百科則幾乎可以直接輸入英文來查詢特定條目)。謝謝!! =) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 09:25 (UTC)

標註事物源語言文字不出奇，但是不會過度標註，多數是導語標一次，而且只有特定專用名詞會標。——路過圍觀的Sakamotosan 2017年7月23日 (日) 09:40 (UTC)

(＋)同意同意。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 09:43 (UTC)

- 這裏好像是討論在內文標註外語而不是外語重定向。--A2093064#Talk 2017年7月23日 (日) 09:37 (UTC)

(：)回應在下以為是在討論重定向 XD。感謝閣下縝密的思維，在下完全同意裏面的規矩。我覺得「該詞中文儘管是個源自外語的專有名詞但卻過於常見，這種情況下不應該標註外文。（如：有氧運動、曼哈頓計劃）本條讓位於#4。」建議從寬認定。謝謝！=)
我發現我搞錯題目正要改的時候遇到同時編輯完成，當下心中嚇了一跳想說被發現了XD --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 09:40 (UTC)

國名差異、兩岸叫法不同：丟給公共轉換組吧。
文中的「過於常見的中文名詞」，每個人大概都有數，我就不說了。裏面是我認為我能夠接受的最低限度——如果比有氧運動和曼哈頓計劃還要不常見，那麼各位打打擦邊球我個人是不想管的。
許多專有名詞儘管沒有建立重定向，但用搜索框找一下依然排在首位。因此我來補上一句「科學技術名詞（紅細胞、頂夸克、槓桿原理）和源自英語地區的地名、人名等專有名詞必須在開頭關鍵詞後附註英文」--燃⁠燈 ^談笑風生 2017年7月23日 (日) 12:26 (UTC)

在下剛才查了一下基礎條目中的科學和技術領域似乎沒有涵蓋數學、歷史、地理、藝術、......領域。因此是否直接以國家教育研究院或其他類似辭典為準則。若條目名稱屬於學術專有名詞，則可以建立外語重定向。(不限英文)--It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 12:55 (UTC)

舉幾個英文維基百科的例子：en:高雄捷運、en:台北捷運是存在的重定向。

提供參考。謝謝!=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 13:31 (UTC)

建議改名為「格式手冊/外文附註」。--J.Wong 2017年7月23日 (日) 05:56 (UTC)

那麼放在這裏煮過討論過後，能否升格為正式指引？還是得「僅供參考」，像那個互助客棧導航模板的其他灰字一樣？--燃⁠燈 ^談笑風生 2017年7月23日 (日) 12:26 (UTC)

燃⁠燈君︰且看能否就確立為指引達成共識。--J.Wong 2017年7月23日 (日) 17:59 (UTC)

我在想說此類模板上能否加註外文呢？ (且 mobile view 並不會顯示此類模板) 就當成是路上看到的路牌一樣，既然有導航指引作用，感覺加上外文會更全面一點。不過共識若認為無此需要，在下也尊重。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 12:35 (UTC)

我認為無此需要，太亂。而且就算是醫學生，我覺得也得同時通曉一個醫學名詞的中文和外文形式吧，中文用來和患者、中文同事交流，英文用來看文獻。--燃⁠燈 ^談笑風生 2017年7月23日 (日) 12:43 (UTC)

我是覺得這樣的中英並存的排版能讓業餘、專業、部分專業的人對於條目之間的差異 (抽搐、癲癇、昏厥、昏倒、暈眩、眩暈、頭暈、......) 一目瞭然。不過還是看大家。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 12:55 (UTC)

在下是覺得平常我們在路上應該不會因為看到路牌上的外文標註就心情受影響，那麼既然外文標註是有作用的，保存也無妨。沒有英文標註的路牌和有標註外文的路牌都是合法的，那麼維基百科也可以現實生活中的共識為共識，亦即模板一定要以中文為主，至於是否有外文標註都可以。=) 提供各位參考看看。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 13:19 (UTC)

路標的問題 -- 如果只是路標那樣標明4、5個地點，那麼加上外文我當然無所謂。但是導航模板不是路標。

區別一：導航模板數量規模龐大，動輒50多。
區別二：路標並不不具備互動的能力，不能夠在若干次點擊後將該詞的英文顯示出來。

至於頭暈系列的，我還是老樣子，建議改寫為這樣子的詞彙表，一目了然，也省得又糾纏不清。--燃⁠燈 ^談笑風生 2017年7月23日 (日) 13:36 (UTC)

- - - - (：)回應改寫為這樣子的詞彙表可行。只是擔心未來會出現許多類似的情況，這樣一來，就會花很多時間在做詞彙表。=) --It's gonna be awesome!✎Talk♬ 2017年7月24日 (一) 04:44 (UTC)

模版中若有幾個中文條目尚未建立的連結，也許可以再列一下英文名稱，可是若中文條目已建立，不太建議所有條目（或大部份條目）都加上英文名稱。若所有連結加上英文，會大幅增加模版的篇幅，而且大家會看到模版中的大部份會是英文，降低可讀性。--Wolfch (留言) _{歡迎參與今年的動員令} 2017年7月23日 (日) 13:33 (UTC)

謝謝以上幾位提供寶貴的意見。=) 謝謝燃燈君主動提供大家這個討論的機會。歡迎大家繼續提供意見以尋求共識!! ^__^ 謝謝!! --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 14:07 (UTC)

那麼問題來了：像這個情況算不算翻譯未完成呢？注意：除非修改快速刪除方針，翻譯未完成的可以按照「包含過多非現代漢語」的標準以G14刪除，無需加掛{{notmandarin}}--燃⁠燈 ^談笑風生 2017年7月23日 (日) 13:54 (UTC)

(：)回應如果從編者或相關人員的立場來看，可能算是大致完成了吧，因為有時候刻意要把英文專有名詞用中文念會變得很拗口。就編者的立場來說，可參考的資訊減少，怕會翻錯。但對於純中文的讀者來說，可能會覺得是及格上下的模板，因為很多都看不懂。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 17:13 (UTC)

(：)回應我會認為像這個情況，許多連結沒有中文，算是翻譯未完成。--Wolfch (留言) _{歡迎參與今年的動員令} 2017年7月23日 (日) 17:23 (UTC)

看來這又是另外一個問題了，涉及到快速刪除模板的事情。這個討論完了之後再新開個討論吧，裁定什麼是導航模板的保留標準。--燃⁠燈 ^談笑風生 2017年7月23日 (日) 18:39 (UTC)

(＋)支持這項提案，閣下已經把我想說的全寫進去了，實在沒有什麼更好的意見可以發表。就在下認為，如果藍鏈與綠鏈已足供讀者查詢到條目相關的資訊（包含但不限於WIki上的資訊），那麼標註原文就是多餘而不必要的，僅在某些條目中的語彙、用詞、名詞等字句沒有連結（即紅鏈）或在可預見的未來中均不會被創建時，原文的標註才可作為提供讀者進一步蒐尋相關資訊的手段；易言之，原文的標註是一種附加的資訊，並非必要，若文內已存在充分的線索供讀者參閱，那麼就無須附加多餘的資訊。一點拙見，僅此表明立場。--NoobWayne™討論 2017年7月23日 (日) 14:49 (UTC)

謝謝你 --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 17:05 (UTC)

謝謝各位參與討論！目前來看，雖然並沒有將所有模糊的問題全部規定下來（見下方「相關問題」一節），但該草案已寫下的部分似乎沒有什麼爭議了，將進入表決環節。希望各位投票/寫下自己的意見，以決定是否將該草案升級為指引。投票時間7天，隨後將從我的用戶頁移動至格式手冊/外文附註，並留此再公示7天。沒有大問題的話，將在公示結束後將該內容標註為正式指引，並結案。燃⁠燈 ^談笑風生 2017年7月23日 (日) 19:05 (UTC)

太快了吧，才討論一天而已。--A2093064#Talk 2017年7月24日 (一) 00:02 (UTC)

@A2093064：我對此沒經驗，請問多久比較合適？燃⁠燈 ^談笑風生 2017年7月24日 (一) 00:45 (UTC)

根據慣例，發起討論後至少七日才得以進入公示程序；另請格外注意投票不能代替討論，只有特殊狀況才將討論共識交付投票決定。－ Aotfs2013 留於 2017年7月24日 (一) 06:21 (UTC)

看了一下草案，覺得還太粗糙。以下先列幾點想到的：
1. 應該有個例外是讓譯自外文、中文易混淆的名詞標註外文，比方說英文裏的 Nation Country State 中文都有可能混譯成「國家」，在英文中則有不同的指涉，有些時候需要標註原文才會比較清楚。
2. 存在簡稱的詞應該容許標註原文+簡稱，不然很難查到簡稱是什麼意思，就算用搜尋，有時碰到簡寫與常用英文字相同時也很麻煩。一般格式是（原名, 簡稱），例如「美國全國婦女組織（National Organization for Women, NOW）
3. 「該詞源自中文，不應該標註外文。」這應該是通則，例外是「該詞雖然源自中文，但有特殊需要時可標註外文譯名以供參考」。因為有些文件裏的外文譯名不見得是當今中文世界常用的漢語拼音或台灣習慣的韋氏拼音（可能因為當初語音不同，或不是譯自北京官話系統），標註才能找到關鍵詞。比方說「在5世紀的某英文作品裏出現老子（Lo-zu）的記載」。

--Reke（留言） 2017年7月24日 (一) 01:39 (UTC)

(：)回應謝謝！確實都是需要詳細討論的部分。我編寫這類東西的經驗不足，外加閱歷有限，請多多指教！

我個人的觀點：

1. 這個出現在原文裏還好。出現在導航模板、消歧義的部分呢？
2. 關於附不附英文全稱——導航模板就算了，其他地方看情況，用{{abbr}}最好。
3. 您給的這個例子我覺得沒有必要附上老子的外語格式。它在條目里出現的話大概會這樣：
  1. 在5世紀的某英文作品裏出現老子（Lo-zu）的記載。其作者在第X章第X節將老子描繪為「最XX的XX，是中國歷代XX中的XX」^{[注 1]}。
  2. 然後把原文放到參注部分，標明出自哪個語言。
另外，這次我猴急的原因主要是想要快速確認哪些是達成共識的部分、哪些不是，以便進一步修整一部分條目格式，因此寫得比較糙一些，抱歉 :P

--燃⁠燈 ^談笑風生 2017年7月24日 (一) 03:46 (UTC)

回應

導航模板我的看法是要看會不會影響導航的效果。如果加了之後能讓人不會錯連到中文很混淆的專有名詞，我暫時想不到例子，但有些醫學用語的確在譯成中文後會長得差不多，專業人員不看原文也不知道分別是什麼。
主要是針對條目內文，導航模板因為很明顯只是導航功能，不是用來說明內容，附縮寫即可。
你想像的內容已經有標註外語了啊，就是這個「老子（Lo-zu）」。其實原文句子倒不一定有需要放，如果要引全句，的確是放註釋，而且那個Lo-zu就沒必要加註，反正引文中會提。但是在沒有引用原文句子必要的時候，直接加註一個詞的原文可以讓讀者方便在文獻裏搜索。比方說如果條目不是「老子」「道家」這類直接跟老子思想相關的內容，而是「中西哲學交流」這種主題，然後內容有「在5世紀的某英文作品裏出現老子（Lo-zu）的記載、也有同時代的文物中提及《論語》中的故事……可見當時已經有中國哲學經典……」這樣如果引原文就太離題，註記一下名詞讓讀者查證時不會找不到就好。（當然，這是個架空的例子，不是說寫這個主題真的會碰到，只是可以想像出有這種情況）。

我看了新的回應，感覺你好像偏重在導航模板？其實我在想要不要針對導航模板的使用訂出格式指引會比較簡單，因為你針對「條目」，我覺得文章中會出現各種可能的情況就太多了，要能全面地給予規範並不是很容易。--Reke（留言） 2017年7月24日 (一) 08:43 (UTC)

像這個模板User:It's_gonna_be_awesome/template:Gram-negative_proteo-bacterial_diseases 若要全翻成中文才算完成，可能會變得非常拗口。=) (我突然忘記我接下來要說什麼了，想到再補 @_@) --It's gonna be awesome!✎Talk♬ 2017年7月26日 (三) 17:30 (UTC)

目前來看，需要進一步討論的問題如下：

什麼是「專有名詞」？（建議與上方有關重定向的問題一併討論）
如何區別{{lang-en}}與{{lang|en}}等模板的使用？
什麼樣的導航模板算「翻譯完成」？導航模板常常作為條目的一部分出現，這種情況下G14是否能夠刪除導航模板？
日語假名、韓文漢字、越南文喃字的標註問題？
部分專有名詞的簡稱問題：是否需要附上全稱？比如條目正文中出現世界衛生組織（World Health Organization，WHO）之類的。如果是開篇第一句的話或許是必須的，如果是後文呢？是否採用{{abbr}}模板？
「在5世紀的某英文作品裏出現老子（Lo-zu）的記載」。此時為了讀者查閱參考文獻方便，「老子」是否需要附註外文？
容易混淆的詞（華盛頓州、華盛頓特區、墨西哥、墨西哥城、頭昏、昏厥）是否需要外文標註？導航模板需要標註外文嗎？開頭消歧義類模板呢？
如何定義「中文儘管是個源自外語的專有名詞但卻過於常見」中的「過於常見」？

這些內容是衍生自草案的問題。（原文已更改）--燃⁠燈 ^談笑風生 2017年7月24日 (一) 03:58 (UTC)

所以還不是沒討論清楚嗎？——路過圍觀的Sakamotosan 2017年7月24日 (一) 00:55 (UTC)

我的大方向是音譯的儘量標明，非出自中文地區的地名、人名、出版物名字都應該標明原始地所用語言的名字--百無一用是書生 (☎) 2017年7月24日 (一) 01:57 (UTC)

(＆)建議條文中加入：「如有特殊原因需要加上外語標註，可於程式碼中加入說明。」=) 感謝，辛苦了！

謝謝你 --It's gonna be awesome!✎Talk♬ 2017年7月24日 (一) 17:10 (UTC)

這個是另一個議題，另案討論吧。程式碼中加入說明的外語標註只是針對編者的，讀者看不到類似內容，另外，用說明的外語標註內容若太多，對其他編輯可能會是干擾（至少對我來說是干擾）--2017年7月24日 (一) 22:21 (UTC)

或者放在討論區也可。=) --It's gonna be awesome!✎Talk♬ 2017年7月26日 (三) 17:16 (UTC)

再討論似乎又離題了, 另案討論吧。--Wolfch (留言) _{歡迎參與今年的動員令} 2017年7月26日 (三) 22:36 (UTC)

=) --It's gonna be awesome!✎Talk♬ 2017年7月29日 (六) 15:44 (UTC)

專有名詞一般包括人、地點、組織、機構、公司、出版物、月份星期幾等的名稱。在英文裏首字母通常大寫，參考著名出版社Springer [7]的說明
容易混淆的詞中舉例可能不太恰當，華盛頓州、華盛頓特區、墨西哥、墨西哥城是專有名詞，頭昏、昏厥則只能算是專業術語
「中文儘管是個源自外語的專有名詞但卻過於常見」，~~大概是指摩托，啤酒，幽默，媽媽，休克，雜誌，航空母艦，琵琶，警察這一類？~~咦，不對，這些似乎都不是專有名詞

--百無一用是書生 (☎) 2017年7月25日 (二) 02:32 (UTC)

修改Wikipedia:格式手冊#空格

最新留言：6 年前4則留言2個人參與討論

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年3月10日 (六) 07:50 (UTC)。

現行條文

外文單詞及數字間應按原文保留空格（例：Google Chrome、Windows 2000），但符號前後通常不加空格（例：IBM System/360）。

提議條文

外文單詞及數字間應按原文保留空格（例：Google Chrome、Windows 2000）。

本討論已經結束。請不要對這個存檔做任何編輯。

未提及是什麼符號，像是英文的逗號、分號、冒號等後面通常應添加空格，斜線前後的空格應視前後文而定（參見en:Slash (punctuation)#Spacing）。-- tang891228 _留言 2018年2月14日 (三) 15:15 (UTC)

提案已有一段時間，現交付公示，為期七日，如無異議，將視為通過。--J.Wong 2018年2月23日 (五) 10:56 (UTC)
已修訂。--J.Wong 2018年3月2日 (五) 11:27 (UTC)

《格式手冊》小修改通知

最新留言：6 年前4則留言3個人參與討論

本主題全部或部分段落文字，已移動至WP:VPP。執行人：--J.Wong 2018年6月30日 (六) 03:13 (UTC)。

近日有修訂如此，謹此通知。--J.Wong 2018年6月23日 (六) 07:04 (UTC)

鄙人覺得修正兩個內部連結屬於不涉及對方針本身的修改，如有不妥，還請u:CopperSulfate賜教。ïMark | 批判一番 2018年6月24日 (日) 09:49 (UTC)

@Markove：抱歉，沒看見這個

囧rz……(＋)支持此次修改。--相信友誼就是魔法的~~User:萌得不能再萌~~CuSO₄正在努力提高知識水平 2018年6月24日 (日) 09:56 (UTC)

提議大幅修訂格式手冊

最新留言：6 年前41則留言11個人參與討論

本主題或以下段落文字，移動自WP:VPP。執行者：B dash（留言） 2018年9月28日 (五) 07:38 (UTC)。

草稿見Wikipedia:格式手冊/更新草案2018（新舊比對）

修訂起因：在編寫條目和新頁面巡查的過程中無法以理想的效率使用格式手冊及其各個分編，試舉兩例

比如說中科院寧波工研院的該筆編輯，參見和參考資料的格式順序，以及其他固定章節和元素的順序，並沒有直觀體現在格式手冊中。
每天都有比較多音樂專輯的條目出現，但Wikipedia:音樂專題/專輯條目格式指導已經很久沒有引起注意，始終沒有進一步翻譯或完善。

修訂目的：以格式手冊為總則和大綱，理順手冊和各個分編邏輯關係。同時促進分編內容的全面展現，促進未成為方針指引的分編不斷完善。修訂：

以維基百科:格式手冊/版面佈局規定的條目結構來構建格式手冊結構，是為各項格式規則（如，WP:格式手冊/標點符號等這一類具體細則）構建一個清晰統一的接口，而不是探討具體的條目結構是否合理（如，參見和參考文獻何者在先），核心內容分為
- 條目結構：分導言章節、主體章節、附錄章節介紹各章節組成元素；
- 通用格式規則：介紹條目三部分編輯都有可能使用的格式
- 導言格式規則：以{{main|Wikipedia:格式手冊/導言格式規則}}連結到分編頁面，介紹導言章節的格式規則；
- 主體格式規則：以{{main|Wikipedia:格式手冊/主體格式規則}}連結到分編頁面，介紹主體章節的格式規則；
- 附錄格式規則：以{{main|Wikipedia:格式手冊/附錄格式規則}}連結到分編頁面，介紹附錄章節的格式規則；
- 主題專門格式手冊：分類介紹現有各類主題條目編制的專門格式手冊（如，文化創作類條目的Wikipedia:電子遊戲專題/條目指引）
對原格式手冊中各個章節的內容，按照上條確定的邏輯結構分別分流放置。

請諸位討論--Kirk 0討論│簽名0 2018年9月15日 (六) 04:47 (UTC)

倒是講個古。我知道中文維基有一票人，很愛更改「參見」和「參考資料」的位置，特別是要把「參見」放在最後方。根據我在2014年的手動調查，在經過有人特地以機械人方式更改、及部分維基人堅持特定格式，這種格式仍然只佔6%的特色條目及11%的優良條目。至於在經過一段有人逕自定調的時期，及中文維基很久沒管以機械人模式修改順序的事情，不知道情況如何了。--KOKUYO（留言） 2018年9月15日 (六) 05:15 (UTC)

基本上反對這樣做，一是Wikipedia:格式手冊應當衹是個入口，結構上不應對各項如此詳述；二來各種範疇的主體和附錄的結構有着十分大不同的需求，直接在最頂層規定統一的規則衹徒增各個範疇的麻煩。--街燈電箱150號開箱維修抄錶檢驗證明 2018年9月16日 (日) 00:15 (UTC)
- @Cdip150：非常同意您說的，Wikipedia:格式手冊應當衹是個入口。但是私以為現在的入口缺乏一個清晰的邏輯，而且個別方針和很多沒有成為方針但有價值進一步改善的指引，沒有通過易於獲得的方式呈現在目前的格式手冊中。而對格式手冊中的各項「入口」進行邏輯上的梳理，是更為清晰的呈現各項方針細則最好的方式。在這個過程中，必然需要選擇以某種邏輯去梳理。而在下覺得不妨以條目結構順序梳理各項方針細則，遂寫下此草案Draft:格式手冊。--Kirk 0格式手冊大修訂0 2018年9月16日 (日) 08:35 (UTC)
- Wikipedia:格式手冊/更新草案2018使用大量{{main}}以主條目形式呈現具體細則，目的正是為各項格式規則構建一個清晰統一的接口。--Kirk 0格式手冊大修訂0 2018年9月16日 (日) 08:35 (UTC)
不認為統一、規範化是壞事，但有共識的規範可能很難達成。如果能收集整理現有的常見版式寫法並編撰出來，可能更有討論而非爭論的可行性，進而形成編輯指引（非方針，後者約束性過強，有更強阻力，不宜過早討論）。「main」那三項沒看懂表意。就「參見」與「參考資料」的位置，我認為「參見」在上說明是條目的一部分，向讀者提供的附言，在「參考資料」下方就比較像條目之外的內容了，這更應該由MediaWiki系統來提供推薦。序言、章節結構等版式寫法，目前是有潛在爭議的，討論可能易形成爭論而非達成共識。--YFdyh000（留言） 2018年9月16日 (日) 00:56 (UTC)
- (：)回應@YFdyh000：是我沒有表意清楚，目前已經更正。「main」那三項，指的是這三部分不直接羅列，比如涉及維護性模板安放格式的方針，歸入Wikipedia:格式手冊/導言格式規則頁面進行說明，一方面避免WP:格式手冊主頁過長，另一方面起到了比較好的「接口」作用。--Kirk 0格式手冊大修訂0 2018年9月16日 (日) 08:43 (UTC)

Opky9407和KOKUYO君就「參見」和「參考資料」的順序問題，進行了坦誠而詳盡的討論，儘管這與本討論的核心問題相關度稍低，但相信之後在條目結構方針的修改中將會很有價值

參考註釋才是向讀者提供附言，像是颱風條目如颱風山竹 (2018年)都是用參考註釋來說明條目內文和支持內文，而參見用來放其他颱風條目，參見才是條目之外的內容，所以這種情況先列參考註釋比參見較適合。--Opky9407（留言） 2018年9月16日 (日) 01:06 (UTC)
- 隨便轉換的範疇就能證明這理由的無效，參見是在維基百科內部的有關條目，參考資料和外部連結是維基百科以外的有關資料，維基百科內部的比維基百科外部的更加親近，結果自然是「參見」應該在「參考資料」上。另外正常人根本不會逐一看來源（例如「1. 颱風百問——颱風是怎麼命名？. 交通部中央氣象局. [2018-09-27]. （原始內容存檔於2017-11-04）.2. 熱帶氣旋名稱的意義. 香港天文台. [2018-09-27]. （原始內容存檔於2018-06-05）.3. 22號颱風山竹已現雛形，它將挑戰飛燕「風王」寶座並登陸我國. 中原網. [2018-09-11]. （原始內容存檔於2018-09-11）.……」），單純只看該段完全沒有意義。所以你的說法只是形而上學的討論，根本沒有真正考慮那段為何有在那位置被閱讀到的必要性（因為「參考資料」這類段落根本不可能單獨被閱讀）。--KOKUYO（留言） 2018年9月16日 (日) 01:58 (UTC)
  - 這理由根本非常兒戲，讀者關注的是條目的主題，不是關注維基內外，參見是親維基又如何，它是跟內容離題的，沒有針對內容，但是參註是合題的，因為都是直接針對內容。而且至少我會看「當有2種以上全球預報模式……」，這明顯較必要，轉跳下來的時候中間看到一個離題的「熱帶風暴百里嘉」我會感到很奇怪，因為我沒必要看那個參見，把它放先才沒有真正考慮必要性和邏輯。--Opky9407（留言） 2018年9月16日 (日) 02:16 (UTC)
    - 說不定參見的主題可以比參考資料相等、甚至更親近，例如這個人的別名文化、名言條目、著作、其獲得的年度諾貝爾和平獎條目等，這叫做跟原本人物條目離題的？你舉的例子只是為了服膺你的想法（因為它的關聯性，可能根本連參見都不需要）。然後註釋本身很多條目根本都沒有，甚至能夠用創建條目處理，證明你只是用能夠服膺你的意見的條目去當作理據。另外，當我在說沒人會只看「1. 颱風百問——颱風是怎麼命名？. 交通部中央氣象局. [2018-09-27]. （原始內容存檔於2017-11-04）.2. 熱帶氣旋名稱的意義. 香港天文台. [2018-09-27]. （原始內容存檔於2018-06-05）.3. 22號颱風山竹已現雛形，它將挑戰飛燕「風王」寶座並登陸我國. 中原網. [2018-09-11]. （原始內容存檔於2018-09-11）.……」或「1. 癮遊戲：任天堂DSi日本首發. Engadget 中文版. [2018-08-25].2. Michael French. Nintendo DSi hits Europe on April 3rd, priced £149.99. Market for Home Computing and Video Games. Intent Media. 2009-02-19 [2018-08-24]. （原始內容存檔於2009-03-18）.3. Nintendo DSi launches April 5 in the United States. Nintendo of America. 2009-02-18 [2018-08-24]. （原始內容存檔於2010-05-29）.……」等段落，你為何不直接回答這段的問題呢？--KOKUYO（留言） 2018年9月16日 (日) 02:27 (UTC)
      - 其實你也是在服膺你的想法，參見總會是另外一個主題，不會支持本身內容，根本不可能親近，遑論相等。列出那個颱風是有必要，因為考慮到人家想知道同期有其他颱風，但必要性明顯較註釋低。另外，我讀完正文，確實我是先會先看參考裏有的連結，因為參考連結通常有更多針對條目主題但條目沒有編的內容，但參見不是。--Opky9407（留言） 2018年9月16日 (日) 02:50 (UTC)
        假設在「蔡英文」的條目中，有一則「2016台灣「大選」候選人號次抽籤舉行」的來源，以及「蔡英文的評價」條目的相關條目，然後你還是會說前者比起後者與蔡英文相等是吧。你的這種說法，當你要求別人一定要相等就得要相等，至於自己提的不相等就自動忽視，那就沒什麼好討論的。--KOKUYO（留言） 2018年9月16日 (日) 02:55 (UTC)
        說人家服膺結果自己也服膺，「蔡英文的評論」應該在「評論」章節用「主條目：蔡英文的評論」，不應用參見，參見是放沒有直接關係的連結。--Opky9407（留言） 2018年9月16日 (日) 03:05 (UTC)
        所以我說假設，而且該條目不一定用評價段落。還是因為你沒什麼再寫過條目，所以不知道條目可能沒有評論段落？而且你舉的例子，那個參見連結同樣可以不用放。--KOKUYO（留言） 2018年9月16日 (日) 03:20 (UTC)

為了避免有人覺得我說「參見」放在前面是常用做法是騙人的，我在這邊補上在2014年初做的統計資料。之所以寫「非『相關條目』先於『參考資料』」，是因為這包含許多不同寫法的條目，否則單純把「相關條目」放在最後方的寫法會更少。--KOKUYO（留言） 2018年9月16日 (日) 03:14 (UTC)

特色條目
「相關條目」先於「參考資料」	非「相關條目」先於「參考資料」	條目直接沒有「相關條目」	樣本數量
128（52%）	15（6%）	101（41%）	244（100%）

優良條目
「相關條目」先於「參考資料」	非「相關條目」先於「參考資料」	條目直接沒有「相關條目」	樣本數量
442（41%）	120（11%）	506（49%）	1,068（100%）

舉不出更好的理由就搬數量，不許這是羊群心理造成的嗎？--Opky9407（留言） 2018年9月16日 (日) 03:32 (UTC)
- 秀個理論不會比較厲害。另外，「共識通常會在編者的編輯過程中自然達成……該頁面的所有讀者也可以選擇去修改它或保持其不變」，然後你說這是羊群效應，我也只能笑笑。--KOKUYO（留言） 2018年9月16日 (日) 03:35 (UTC)

其實不太想再吵這個問題，相關條目在不同範疇各自有自己的考慮理由，而列出的條目選擇要求也有不同，不能像上面拿着政治人物類條目和颱風類條目來比較再來統一結論。還有數量是無意義的，量多就是正確？我在澳門街道專題定立的排版法其實也不是「常用」，衹按照條目內容相關紋理邏輯來訂定，相關條目的選取也不會選得直接，結果在參評的時候都沒有引起反彈。所以各範疇各取所需，強求統一從過往執行的經驗來看不見得是好事。--街燈電箱150號開箱維修抄錶檢驗證明 2018年9月16日 (日) 03:16 (UTC)
- 我也懶得吵，因為中文維基發展歷程與其他語言發展歷程不一樣，現在如果訂立強制的規定根本來不及。但是在客觀條件上，「有多數人會習慣使用『相關條目』先於『參考資料』格式」是客觀現實（52%對上6%，這點應該不用特別解釋了）。如果無視這個客觀現實，還有人不斷推動自己的主張、甚至以機械人方式修改格式，都是有問題的。--KOKUYO（留言） 2018年9月16日 (日) 03:31 (UTC)
  - 的確維基上有着不少過往很多人用的做法但後來証明不合理的例子（Infobox和Disambig以前的次序就是一例），所以拿數據來說不見得就完全客觀，當然以機器模式來推動的確不妥。總之，我主張是各專題定各自規則，而反對完全統一規則。--街燈電箱150號開箱維修抄錶檢驗證明 2018年9月16日 (日) 03:45 (UTC)
    - 方針指引並非是如此認為，尤其是你藉由舉出一些例子來否定以慣例制定規則這件事情上是有問題的，涉及的相關方針有「總體來講，有三種方式去制訂某項方針或指引：……3. 逐漸演化出的常規或慣例。」、「共識通常會在編者的編輯過程中自然達成」。而當前這個數據便是提供判斷何謂慣例、以及若要用慣例制定規則時能夠使用的參考資料。--KOKUYO（留言） 2018年9月16日 (日) 03:55 (UTC)
      - 「逐漸演化出的常規或慣例」方針指引僅指出是可以透過這個方法而已，但從沒有指出這是一定要的。總不能說以前有80%把Infobox放在最前所以因「共識通常會在編者的編輯過程中自然達成」而不能改吧。這不是說要否定您的數據，而是說引用數據時還應考慮其他因素，尤其是數據背後的箇中原因也會影響參考價值。--街燈電箱150號開箱維修抄錶檢驗證明 2018年9月16日 (日) 04:16 (UTC)
        當然可以討論，但不代表可以否定數據的客觀情境，假設一群人自嗨訂出規則，卻因不符合慣例和實際情境，而幾乎沒人實行，那就是可笑的鬧劇。說到底，「討論取得共識」是方針指引制訂的第二種方法，但前提是要有明確共識、及真正能夠執行，否則至多就是較多人的見解。--KOKUYO（留言） 2018年9月16日 (日) 04:33 (UTC)

非常想(＆)建議和(＊)提醒大家：在下非常希望能夠以某種邏輯使WP:格式手冊以更有條理更清晰的方式成為諸如WP:格式手冊/標點符號等等各項方針細則（也就是格式手冊的各個分編細則）的入口。在下基於編輯和巡查的經驗考量，提議以條目結構為邏輯編輯。關於參見和參考文獻誰先誰後，等涉及條目具體結構的問題，目前還不迫切：因為大家還未就格式手冊是否以條目結構來梳理達成共識。--Kirk 0格式手冊大修訂0 2018年9月16日 (日) 08:29 (UTC)
我不明白為什麼你們定要分出個高下來...這些格式長期並存，且各有支持者，說明它們在某些情況各有自己的優點。我會提議格式手冊分別列出這些常見的模式，而無須強行定出一個"正統"。就像論文格式有APA有IEEE，中文字有繁有簡，很多時間這些問題都吵不出什麼結果來。倒不如求同存異，自己寫的條目就用自己的排版，不是太離譜就可以了。--Temp3600（留言） 2018年9月16日 (日) 15:43 (UTC)
- 我個人覺得，有清晰格式標準的一個目的是向新手提供一個清晰的編寫建議，僅僅從引導新手的角度考慮，制定一個明確的手冊也是有一定價值的。--Kirk 0格式手冊大修訂0 2018年9月17日 (一) 12:43 (UTC)
  - 過往經驗，這類標準問題的爭執通常都沒有好結果。可以推薦幾條不同結構的優秀條目給新手，從例子中學習。沒有必要"定於一尊"，將問題擴大化，吵上VIP就更更糟糕。--Temp3600（留言） 2018年9月17日 (一) 13:18 (UTC)

順帶一個建議，是否叫WP:體例更專業一點？--百無一用是書生 (☎) 2018年9月17日 (一) 02:02 (UTC)

支持。但「凡例」呢？是詞典用語？ --達師 - 370 - 608 2018年9月17日 (一) 07:51 (UTC)

是將WP:格式手冊改為WP:體例或WP:凡例嗎？--Kirk 0格式手冊大修訂0 2018年9月17日 (一) 12:49 (UTC)

(－)反對：用詞不能太過專業，「格式手冊」本來是對新手比較平易的用詞，表面一看就知道是談格式的，但「體例」和「凡例」的意義較隱蔽，新手未必一看就知道。--113.52.81.38（留言） 2018年9月17日 (一) 13:38 (UTC)

體例是指編篡格式，是對編者的要求，凡例是指對格式的舉例，主要是針對讀者，類似於說明書性質。二者都是辭書中最常用的用語之一。可以參考[8]。既然是百科全書，自然要體現出百科全書編輯的專業性來。何況，任何一本辭書，幾乎都有體例和凡例，面向編者和讀者。使用維基百科的人群，應該幾乎都有使用過某種辭書，不應當對此陌生--百無一用是書生 (☎) 2018年9月18日 (二) 03:25 (UTC)

(－)反對任何大規模修改。大規模修改方案難以評審。 --🐕🎈（實用主義大於天） 2018年9月18日 (二) 05:28 (UTC)
- 關於實質性修訂和結構性修訂本次修訂是以各項已通過方針為核心進行的修訂，主要是對已通過方針進行邏輯上的梳理，而不是大規模的進行實質性修訂。結構性修改看起來變動量較大，但是目前所必須的。
  1. 修訂的歷史原因：現存式手冊是由許多次為適應新情況而追加新的內容形成的。在追加修訂的過程中，一般以實質性內容為核心。故而形成了目前格式手冊中大量二級標題章節以比較缺乏邏輯的方式呈現的情況。這種情況是的可以理解的，因為調整結構的難度是比較大的。
  2. 修訂的必要性：還有很多有價值的論述沒有成為方針，格式手冊以及其下的分編分則必然還要追加，我們需要幫助論述(提高曝光度，幫助有價值的論述獲得更多關注，並成為方針)和方針以更清晰的方式呈現，而結構清晰度有待提高的情況應該儘早解決。為以後的實質性修訂鋪路。--Kirk 0格式手冊大修訂0 2018年9月18日 (二) 06:01 (UTC)
  - 我認為先寫成指引乃至論述（可以介紹各版式的理解、利弊）就可以，之後討論更簡單，各部分如何調整、是否通過。--YF dyh000（留言） 2018年9月18日 (二) 12:09 (UTC)
回到入口還是要(－)反對，對於新手，現在的頁面列舉了一些很基本的示範，有助新手輕易對格式上手，但是新版卻複雜許多，所謂的分編的條理確實也很難理解，根本面對不了新手作為入口。那麼寧可維持現狀。--Opky9407（留言） 2018年9月18日 (二) 12:41 (UTC)
- (：)回應：個人認為目前頁面的情況不是這樣，如，新手很難通過瀏覽現有的頁面，比較快地獲知：1、條目需要標註參考資料；2、條目如何標註參考資料。--Kirk 0格式手冊大修訂0 2018年9月18日 (二) 15:09 (UTC)
  - 我覺得這位的意見應該吸收。我們不能僅考慮結構性而忽略了對新人的友好性。 --達師 - 370 - 608 2018年9月20日 (四) 07:11 (UTC)
    - 嗯，想想看。大家有什麼建議懇請儘管說。--Kirk 0格式手冊大修訂0 2018年9月20日 (四) 17:00 (UTC)

建議將格式手冊中所有的「台灣」修正為「臺灣」

最新留言：5 年前13則留言8個人參與討論

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2019年6月9日 (日) 09:21 (UTC)。

如題。由於需修改處不多，目前又無不適用之例外情況存在，並屬事實性修改，故現起~~公示三天~~，若無反對意見將提請正名。—— Eric Liu_{（留言．留名．學生會）} 2019年2月23日 (六) 09:52 (UTC)

讓用戶們表決如何？--Matt Smith（留言） 2019年2月23日 (六) 11:10 (UTC)

之前有一篇討論台改成臺的不知道被存到哪裏，不過我倒是有找到這篇Wikipedia_talk:繁簡處理/檔案11#提案修正WP:繁簡處理#勿手動轉換異體字之「台/臺」指引。 --船到橋頭自然捲（留言） 2019年2月23日 (六) 11:37 (UTC)

嘛，因為條目那邊吵的沸沸揚揚，這裏先只討論維基百科命名空間相關頁面。—— Eric Liu_{（留言．留名．學生會）} 2019年2月23日 (六) 14:51 (UTC)

就是有討論簡繁轉換改成臺灣正體結果下面變成語言問題的那篇啊，結果大家只在那邊喊台蘭市都忘記討論。 --船到橋頭自然捲（留言） 2019年2月23日 (六) 15:08 (UTC)

其實那篇只有「繁簡轉換標籤」一個標的而已⋯⋯—— Eric Liu_{（留言．留名．學生會）} 2019年2月24日 (日) 00:53 (UTC)

上次的討論在這Wikipedia:互助客棧/其他#「台灣」「正體」？－Bangardi 2019年2月28日 (四) 14:00 (UTC)

(－)反對：WP:異體字：「『台/臺』這一對字由於政治原因常常成為修改的對象，由於『台』字雖為俗寫，但是在台灣已經廣泛使用，因此不應該對其進行手動轉換，而是應該遵循先到先得的原則，因為對這些字進行手動轉換對條目沒有實際的改善作用。」無必要，且有一定的繁簡破壞之嫌。--仍然相信友誼就是魔法的達拉CuSO₄崩吧提醒您：討論千萬條，文明第一條，溝通不規範，戀人兩行淚。 2019年2月24日 (日) 10:00 (UTC)
- (～)補充：而且慣例是公示7天而非3天。3天有些短了。--仍然相信友誼就是魔法的達拉CuSO₄崩吧提醒您：討論千萬條，文明第一條，溝通不規範，戀人兩行淚。 2019年2月24日 (日) 10:01 (UTC)
上次是因為「正體」的問題才開啟的討論，這一次修改不知有何意義。--超級王謹賀中文維基導遊創立5周年暨突破3000篇旅行指南 2019年2月24日 (日) 10:11 (UTC)
- 我認為因為是格式手冊，用字應較一般條目嚴謹。起碼要用TA統一用字吧，不管是台或臺都好。由於在繁體字環境下兩字會混雜，看起來很不舒服。—— Eric Liu_{（留言．留名．學生會）} 2019年2月24日 (日) 11:37 (UTC)
香港同時使用「台灣」和「臺灣」，noteTA執行上有一定根本性問題。Σαν μο σα^{The Trve Lawe of free Monarchies} 2019年2月25日 (一) 12:00 (UTC)

外文粗體

最新留言：5 年前102則留言9個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2019年5月28日 (二) 16:14 (UTC)。

（後備方案）通過：

後備方案通過；Wikipedia:格式手冊/傳記及Wikipedia:格式手冊/序言章節暫時不升格為指引。Σαν μο σα 2019年5月25日 (六) 13:52 (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)
我想到幾個涉及外文的情況：
1. 外文名在中文環境中屬於最常用名稱（例如Facebook：「Facebook（簡稱FB）是源於……」中的「Facebook」）；
2. 外文名在中文環境中屬於較常用簡稱／縮略寫法，例如：
  a. 任天堂DSi：「任天堂DSi（日語：ニンテンドーDSi，英語：Nintendo DSi，多簡稱為NDSi、DSi）是……」中的「NDSi」和「DSi」；
  
  b. 超文本傳輸協議：「超文本傳輸協定（英語：HyperText Transfer Protocol，縮寫：HTTP）是一種用於……」中的「HTTP」；
3. 外文名在中文環境中不屬於常用名稱（例如陳綱 (清朝外交官)：「陳綱（西班牙語：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)
或許我把這個大話題收窄為幾個問題，希望大家能夠回答：
1. 你是否認同2a對於簡稱／縮略寫法的加粗？
2. 如果上題的答案為「是」，則你是否也認同2b的首字母加粗？
3. 你是否認同應該把3的外文加粗？
以上。我個人的回答是：1.是；2.否；3.否。Σανμοσα ^{y=0 regardless the value of x} 2019年4月14日 (日) 03:38 (UTC)
- 1.贊成；2.基本不贊成。顯而易見的縮寫法一望而知，不顯而易見的縮寫法較難提供可靠來源印證（所以可能提供的就是錯的。若有來源，宜在正文中介紹），維基源碼和呈現效果也有點亂。3.不贊成。--YF dyh000（留言） 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)

建議修訂

a. Wikipedia:格式手冊/文字格式建議修改如下：

現行條文

將非拉丁字母如希臘字母和西里爾字母加粗，在技術上是可行的，但應當避免這麼做。

提議條文
外文粗體

如果一個外文出現在條目定義句中，並且符合以下至少任何一種情形：

是中文維基百科中所屬條目的名稱；
在中文環境中屬於非人名的常用簡稱／縮略寫法；
屬於未有中文版本的常用人物別名在中文環境中的最常用版本；

則該名稱可根據Wikipedia:格式手冊#條目定義句規定予以加粗，否則該外文不應加粗。外文全稱的縮略寫法字母不應單獨加粗。

不過，即使該外文符合上述規定可予以加粗，移除第二類外文加粗的編輯仍不應被撤銷。

將非拉丁字母如希臘字母和西里爾字母加粗，在技術上是可行的，但應當避免這麼做。

b. Wikipedia:格式手冊建議修改如下：

現行條文

（上略）

請您盡可能在首句帶出文章所屬的主題。如：

'''海森堡測不準原理'''，在[[量子物理學]]……

傳記

歷史上的概念如朝代、已不適用的地名等，應註明有效時間。人物則應提及出生（和死亡）的年月日。

這裏有對於一般情況的概要：

'''孫中山'''（1866年11月12日－1925年3月12日）是中國近代民主革命家，民主先行者……
'''史提芬·威廉·霍金'''（{{lang-en|Stephen William Hawking}}，1942年1月8日－2018年3月14日），是英國著名[[物理學家]]……

提議條文

（上略）

請您盡可能在首句帶出文章所屬的主題。如：

'''海森堡測不準原理'''，在[[量子物理學]]……

外文粗體及斜體須依照Wikipedia:格式手冊/文字格式的規定處理。

傳記

歷史上的概念如朝代、已不適用的地名等，應註明有效時間。人物則應提及出生（和死亡）的年月日。

這裏有對於一般情況的概要：

'''孫中山'''（1866年11月12日－1925年3月12日）是中國近代民主革命家，民主先行者……
'''史提芬·威廉·霍金'''（{{lang-en|Stephen William Hawking}}，1942年1月8日－2018年3月14日），是英國著名[[物理學家]]……

c. Wikipedia:格式手冊/傳記建議（i）通過「非中文人名」部分為指引，並（ii）修改如下：

現行條文

格式手冊的目的很簡單：讓格式整齊統一。以下規則並非金科玉律。許多種格式並無高下之分，但如果每人都遵循同一格式，維基百科將更為易讀易用，當然也更易撰寫編輯。

（略）

非中文人名

非中文人名應標出其本語言名字的拼寫。外文名是否應使用粗體格式目前沒有共識，以下兩種樣式都有使用。

溫斯頓·倫納德·斯賓塞·丘吉爾爵士（英語：Sir Winston Leonard Spencer Churchill，1874年11月30日－1965年1月24日），英國首相，政治家、演說家，被認為是20世紀最重要的政治領袖之一，帶領英國獲得第二次世界大戰的勝利。
奧利花爵士夫人慧雲·李（英語：Vivien Leigh, Lady Olivier，1913年11月5日－1967年7月8日），英國國寶級電影演員，她獲得奧斯卡最佳女主角獎兩次提名，兩次都得獎，分別是第12屆的《亂世佳人》和第23屆的《欲望號街車》。

提議條文

格式手冊的目的很簡單：讓格式整齊統一。許多種格式並無高下之分，但如果每人都遵循同一格式，維基百科將更為易讀易用，當然也更易撰寫編輯。

（略）

非中文人名

非中文人名應標出其本語言名字的拼寫。根據Wikipedia:格式手冊/文字格式規定，除非該本語言名字出現在條目定義句中，並且是其在中文維基百科所屬條目的現行名稱或其未有中文版本的常用別名在中文環境中的最常用版本，否則不可為該本語言名字加粗。樣式如下：

奧利花爵士夫人慧雲·李（英語：Vivien Leigh, Lady Olivier，1913年11月5日－1967年7月8日），英國國寶級電影演員，她獲得奧斯卡最佳女主角獎兩次提名，兩次都得獎，分別是第12屆的《亂世佳人》和第23屆的《欲望號街車》。

d. Wikipedia:格式手冊/序言章節#外語名稱建議（i）通過為指引，並（ii）修改如下：

現行條文
外語名稱

捷徑： WP:MOSFORLANG

如果條目主題名稱是以非中文為較大關聯，那麼與其同義的外文名稱可以出現於導言裏，並通常被括號包住。舉例說，一篇講述關於非中文語言的地方條目會把該地的本土語言所用的名稱寫進去：

切爾諾夫策州（烏克蘭語：Чернівецька область, Chernivets’ka oblast’）是烏克蘭西南部的一個州……

如果多於一個外語名稱需要展示，那麼在導言裏把它們放在獨立的句子，或者在主體正文增設一個諸如「名稱」的章稱，而不要寫在開首的句子裏。也不要把僅僅作為展示詞源的外文名稱寫進導言內。

請勿加粗不常直接於中文語境使用的外語名稱。另有一些外文用語需以斜體表示，使用時機請見Wikipedia:格式手冊/文字格式#斜體。

提議條文
外語名稱

捷徑： WP:MOSFORLANG

如果條目主題名稱是以非中文為較大關聯，那麼與其同義的外文名稱可以出現於導言裏，並通常被括號包住。舉例說，一篇講述關於非中文語言的地方條目會把該地的本土語言所用的名稱寫進去：

切爾諾夫策州（烏克蘭語：Чернівецька область, Chernivets’ka oblast’）是烏克蘭西南部的一個州……

如果多於一個外語名稱需要展示，那麼在導言裏把它們放在獨立的句子，或者在主體正文增設一個諸如「名稱」的章稱，而不要寫在開首的句子裏。也不要把僅僅作為展示詞源的外文名稱寫進導言內。

外文用語的粗體和斜體的使用須遵照Wikipedia:格式手冊/文字格式處理。

以上為本人建議的指引新增及修訂。Σαν μο σα ^{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)
  - User:Cdip150請閲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)
(！)意見 a: 不懂為何這麼做，其他條目的正文中也加粗，只因它有一個條目？應該是加內鏈吧。「屬於非人名的常用簡稱／縮略寫法」同上，PVC（等等）嗎。第二句「除非該外文是中文維基百科中所屬條目的名稱，否則任何人不得撤銷移除外文加粗的編輯。」很繞，是不能回退「取消加粗」的編輯吧，既如此強硬，為何要鼓勵/可根據...予以加粗。b: 先解決A的問題。c: 「本語言」很難懂，我想改掉，~~母語行麼。建議「除非其母語名稱是中文維基百科現行條目的名稱，否則不可為該名字加粗」。有點瑕疵是，條目/現行條目可能是無關的同名條目。~~「除非其外文名稱是其在中文維基百科的條目的現行名稱，否則不可為該名字加粗」如何。d: 暫無意見。--YFdyh000（留言） 2019年4月23日 (二) 02:40 (UTC)
- User:YFdyh000a：條文已修改，現在的意思大概是「Facebook」只能在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)
    - User:YFdyh000 完成。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月23日 (二) 08:37 (UTC)

本主題全部或部分段落文字，已移動至#外文全稱的縮略寫法字母是否應該單獨加粗。執行人：Σαν μο σα ^{y=0 regardless the value of x} 2019年4月28日 (日) 13:28 (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)

外文全稱的縮略寫法字母是否應該單獨加粗

本主題或以下段落文字，移動自#建議修訂。執行人：Σαν μο σα ^{y=0 regardless the value of x} 2019年4月28日 (日) 13:28 (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)
  - 補充：指引頁面不能用{{bd}}，否則會造成錯誤分類。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月27日 (六) 07:27 (UTC)

我非常(＋)支持「Hyper Text Transfer Protocol」這種單字母加粗的顯示，但應該在之後有表述縮寫「HTTP」，這樣很容易辨別一個縮寫是如何縮的（並不是所有的縮寫都是取首字母或每個單詞的首字母）--百無一用是書生 (☎) 2019年4月26日 (五) 03:06 (UTC)

(：)回應，把「Hypertext」單詞硬分拆成「Hyper Text」，分明就是矯枉過正。再者，環顧其他語文版本的維基百科，也不見有類似需要和安排。按照外文粗體如此有用的說法，豈不是回歸基本贊成全面的外文粗體？又應否連中文也要顯示為「聯合國安全理事會」？--Clithering（MMXIX） 2019年4月26日 (五) 05:06 (UTC)

我認為這種標註一來不太美觀（有點眼花，網頁親和力也不佳），二來很容易原創研究——絕大多數都沒有腳註印證縮寫法，可能不少是第一印象標註，有些還有爭議或謬誤。而如果有來源具體講過縮寫法，那就值得寫入正文章節。--YF dyh000（留言） 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)
(－)反對理由：「བཀྲ་ཤིས་བདེ་ལེགས་」對比不加粗：「བཀྲ་ཤིས་བདེ་ལེགས་」。--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)
- User:Opky9407那IP舉出的加粗例子如何？（假設有來源）Σανμοσα ^{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)

恢復公示

由於支持外文全稱縮略寫法字母單獨加粗者在被要求回應的三日後仍沒有回應，現恢復公示，自此刻起為時七日。Σαν μο σα^{五四運動百週年} 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:格式手冊中去粗體的規定的有效性）。老實說，即使那一部分我不通過為指引，因為那部分並非社群共識，所以我其實可以隨意修改內容（我改得面目全非也可以），最終我還是能夠達到修訂的目的。User:Cdip150Σανμοσα^{以有涯隨無涯，殆已！} 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)
(？)疑問：a部分的規定跟直接禁止第2類做法有甚麼差別？只要移除了便不能撤銷，即NDSi是可以的，但被改為NDSi便不可改回粗體，這個完全是矛盾的規條，所以(－)反對。--Opky9407（留言） 2019年5月18日 (六) 10:10 (UTC)
- User:Opky9407我在上面也強調過了：一般而言，外文粗體是不被鼓勵的，所以才訂了如此的規則。最理想的情況下是盡可能避免外文粗體，1和3就是不可避免的情況；社羣對於外文加粗的普遍態度是頗為負面的。Σαν μο σα^{以有涯隨無涯，殆已！} 2019年5月18日 (六) 10:31 (UTC)
- 我就此點再作出較為詳細的說明：我之所以會設定這樣的規則，目的就是為了最終達到直接禁止二類粗體，但為了避免社群以後一看到二類粗體就急於移除，我設定了這樣的規則，這樣大家看到二類粗體也不用太在意，喜歡移除就移除，喜歡保留就保留，但移除了就不要再加粗。長久下去，當到了一定的時候，就可以改為直接禁止。Σαν μο σα^{以有涯隨無涯，殆已！} 2019年5月20日 (一) 10:36 (UTC)
第2點上面的共識根本是同意加粗簡寫，允許移除是明顯違反共識的。--Opky9407（留言） 2019年5月21日 (二) 09:32 (UTC)
- User:Opky9407但其他人對於移除之並沒有提出異議，可以認為這得到了沉默共識許可，所以並不違反共識。對不起，由於你的編輯造成了編輯衝突，我會把你的留言置於archive bottom外。Σανμοσα^{以有涯隨無涯，殆已！} 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)
    - 上面YFdyh000曾經對允許移除但不允許恢復二類粗體向我提出了疑問，而他最終接受了我的解釋。至於其他人在看了整個條文也從來沒對於我這一點有任何疑問或異議，那就代表他們接受這個做法。Σανμοσα^{以有涯隨無涯，殆已！} 2019年5月21日 (二) 09:58 (UTC)
      - 共識和效果都一起說，根本看不到共識是暫時允許，我理解是永遠允許，根本沒有人對簡寫粗體反感。--Opky9407（留言） 2019年5月21日 (二) 10:15 (UTC)
        User:Opky9407如果你打算共識和效果都一起說的話，我希望你可以把這兩部分分開處理，否則我不認為我能夠和你有有效的溝通。另外，共識方面的問題已在下方處理，我認為你至少不會反對後備方案。Σαν μο σα^{以有涯隨無涯，殆已！} 2019年5月21日 (二) 10:26 (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)
    - User:Cdip150事實上我並沒有取消任何一部分，我仍然是提議把c、d兩部分的相關部分的修訂，我只是不再要求把c、d兩部分的相關部分作為指引（這也意味着把c、d兩部分的相關部分的修訂並不需要共識）。我可以重新張貼公示內容，但我會視之為延長公示期，而不是重新進行公示。Σαν μο σα^{以有涯隨無涯，殆已！} 2019年5月21日 (二) 10:35 (UTC)
- 針對說法1，如果Cdip150也希望就我是否正確解釋討論共識這個議題發表意見的話，我也歡迎閣下就此發表意見。如果其他人多數也認為我正確地解釋了共識的話，我會再自行以通過結案；但我其實也有不禁止恢復二類粗體的後備方案，如果社群認為他們的意見是不禁止恢復二類粗體的話，我就會改為通過後備方案，因為其他部分並無人提出異議（註：我不會通過ci、di部分）。Σαν μο σα^{以有涯隨無涯，殆已！} 2019年5月21日 (二) 10:21 (UTC)
- @Sanmosa：「仍不應被撤銷」就「指引」效力和自由編輯來說，是過強了一些，且單方面、理由不充分地限制。且我想了好久才明白它想表達什麼，如果「屬於非人名的常用簡稱／縮略寫法」（如KFC、FBI）通常不應、不必要或可選加粗，建議明確約束（如「廣泛使用、代用」）或者不要約束（如「也可不加粗以利版面整潔」）。該第二類是否該加粗，我也沒想好，不加粗美觀些，加粗也許對SEO和機械人維護（至少「ToolsRedirect」工具…）有些好處。--YFdyh000（留言） 2019年5月21日 (二) 10:29 (UTC)
  - User:YFdyh000請問我是否可以把你的意見視為中立偏後備方案？Σανμοσα^{以有涯隨無涯，殆已！} 2019年5月21日 (二) 10:49 (UTC)
    - 是的，可以。--YF dyh000（留言） 2019年5月21日 (二) 10:55 (UTC)
- 我希望Cdip150能夠就原方案和後備方案孰優孰劣發表一下意見。Σαν μο σα^{以有涯隨無涯，殆已！} 2019年5月21日 (二) 10:41 (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)
- User:Cdip150不，外文是否加粗的問題已困擾社羣已久，應快刀斬亂麻。另外，條文的本意是只限制純外文，「J聯賽」之類不是規管範圍（因為「J」本身不構成聯賽簡稱；整個「J聯賽」去粗體的話，「聯賽」並非外文，按現行WP:MOSBOLD：「粗體通常用在一個條目的第一段，並用合適的名稱和常用術語作為條目的題目，包括任何同義詞和簡稱」，移除「聯賽」的粗體也不合理），上面的例子發生的機會不大；我相信以上解釋能使條文通過後為外文去粗體的適用範圍更清楚，也避免了我不欲看到的濫去粗體的情形（當然，我也可以事實性修訂條文的「外文」為「純外文」）。Σανμοσα 2019年5月23日 (四) 11:45 (UTC)
  - 「快刀斬亂麻」，不行，修訂政策從不考慮問題存在的時長，衹考慮共識是否已達成。而從上面的討論看來，第2類的移除在我而言很難說得上有共識，所以有關純外文粗體的詳細修訂應留待日後再議。另由於後備方案的共識暫時較為明顯，還是先從公示中移除有關條文，待七天無異議才視為共識確認。--街燈電箱150號開箱維修抄錶檢驗證明 2019年5月24日 (五) 06:39 (UTC)
    - User:Cdip150由於未有人反對二類粗體去加粗以外的條文，我認為現在已可直接通過a、b兩部（a部從後備方案），這點我不認為應該拘泥於程序內（而且公示七日只是慣例，而非方針指引規定）。Σαν μο σα 2019年5月24日 (五) 10:13 (UTC)

（請繼續在橫線上方討論）

以下重新張貼公示內容：（c、d之修訂已完成，但不作為指引）

a. Wikipedia:格式手冊/文字格式建議修改如下：

現行條文

將非拉丁字母如希臘字母和西里爾字母加粗，在技術上是可行的，但應當避免這麼做。

提議條文
外文粗體

如果一個外文出現在條目定義句中，並且符合以下至少任何一種情形：

是中文維基百科中所屬條目的名稱；
在中文環境中屬於非人名的常用簡稱／縮略寫法；
屬於未有中文版本的常用人物別名在中文環境中的最常用版本；

則該名稱可根據Wikipedia:格式手冊#條目定義句規定予以加粗，否則該外文不應加粗。外文全稱的縮略寫法字母不應單獨加粗。

不過，即使該外文符合上述規定可予以加粗，移除第二類外文加粗的編輯仍不應被撤銷。（後備方案不存在此句）

將非拉丁字母如希臘字母和西里爾字母加粗，在技術上是可行的，但應當避免這麼做。

b. Wikipedia:格式手冊建議修改如下：

現行條文

（上略）

請您盡可能在首句帶出文章所屬的主題。如：

'''海森堡測不準原理'''，在[[量子物理學]]……

傳記

歷史上的概念如朝代、已不適用的地名等，應註明有效時間。人物則應提及出生（和死亡）的年月日。

這裏有對於一般情況的概要：

'''孫中山'''（1866年11月12日－1925年3月12日）是中國近代民主革命家，民主先行者……
'''史提芬·威廉·霍金'''（{{lang-en|Stephen William Hawking}}，1942年1月8日－2018年3月14日），是英國著名[[物理學家]]……

提議條文

（上略）

請您盡可能在首句帶出文章所屬的主題。如：

'''海森堡測不準原理'''，在[[量子物理學]]……

外文粗體及斜體須依照Wikipedia:格式手冊/文字格式的規定處理。

傳記

歷史上的概念如朝代、已不適用的地名等，應註明有效時間。人物則應提及出生（和死亡）的年月日。

這裏有對於一般情況的概要：

'''孫中山'''（1866年11月12日－1925年3月12日）是中國近代民主革命家，民主先行者……
'''史提芬·威廉·霍金'''（{{lang-en|Stephen William Hawking}}，1942年1月8日－2018年3月14日），是英國著名[[物理學家]]……

以上。Σαν μο σα^{以有涯隨無涯，殆已！} 2019年5月21日 (二) 10:38 (UTC)

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

建議修訂

最新留言：5 年前1則留言1個人參與討論

原文使用芝加哥格式手冊作為例子闡述觀點

但是這本書對於絕大數中文讀者而言並不熟悉

建議改為其他更加為人熟知的例子--冷羅KS用戶:KSroido 2019年8月20日 (二) 13:15 (UTC)

關於對大中華地區行政區劃類、地名類條目加注非漢語文字及漢語羅馬化方案的方法作正式規範的建議

最新留言：5 年前41則留言12個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2019年11月2日 (六) 16:14 (UTC)。

自今年7月有用戶質疑廣州市條目中英語名稱Guangzhou及Canton之註明方式的合理性，逐漸演化為中國行政區劃條目是否及如何加注非漢語及漢語羅馬化的問題的大討論，並且初步拿出了一些方案，現正在進行投票。在此基礎上，我個人有一些新的想法和（可能也會有）疑問，在此列明，做出建議。

外語及漢語羅馬化方案在首段標註的標準：建議劃一為「官方語言」/「官方語言及當地通用語言」（視投票結果為準）。例如：
- 中國內地吉林省延邊朝鮮族自治州，官方語言為漢語官話（普通話）、韓語（中國韓語），當地通用語言為漢語官話（東北話）；
- 中國內地廣東省廣州市，官方語言為漢語官話（普通話），當地通用語言為粵語；
- 台灣地區台北市，官方語言為漢語官話（國語）、閩南語（台語）、客語（此處稍有疑問，還望能解惑）；
- 台灣地區高雄市那瑪夏區，官方語言為漢語官話（國語）、閩南語（台語）、客語，當地通用語言為卡那卡那富語、布農語（這兩個沒有任何疑問，有來源）。
在地名信息框內，個人不建議放任何非漢字語言。下面加置一個Infobox Chinese信息框，內容為官方語言及當地通用語言。
官方語言及當地通用語言為漢語族各語言、語言方言的，註明時用標準羅馬化方案，且宜只用一種。漢語官話現在內地、台灣都選用漢語拼音為標準羅馬化方案，所以建議如果要標註漢語官話的羅馬字，只標漢語拼音。
詞源外語的問題，例：
- 中國內地吉林省吉林市，詞源為滿語；
- 台灣地區高雄市，詞源為日語。
對於上述詞源不是現用官方語言及當地通用語言的情況，建議亦在Infobox Chinese信息框中註明該語言，同時在首段以後單開一章節，介紹地名詞源。
其他外語的問題。建議如無特殊情況，地名外語名應一律按各地區的標準轉寫法來，故其他外語一律不出現在中文維基百科，那是維基數據的任務。特殊情況包括：
- 有一個官方外語名稱，此外有一或多個常用的其他外語名稱的，如中國內地廣東省廣州市，按官方標準，英文為Guangzhou，而Canton亦較流行；
- 官方允許的例外情況，如中國內地黑龍江省哈爾濱市，按官方標準，英文為Harbin（非Haerbin），這是官方聲明的特例。
適用範圍問題：建議擴大到整個大中華地區，包括香港、澳門、台灣地區的地名（但由於港澳的特殊狀態，故主要針對的是中國內地和台灣地區）；不僅僅是行政區劃，其他地名，如中山路之類，似乎也可以按此進行。

以上是個人的愚見，還望先進賜教。附知@H2NCH2COOH、Longway22、SCP-2000、Milkypine、和平至上、@Viztor、Huangsijun17、KirkLU、Hamish、OuiOK、@Baomi、UjuiUjuMandan、Sanmosa、Ericliu1912、游蛇脱壳、@Jacky Cheung、WQL、⼥⼉、Rowingbohe、行到水穷处、@AT、StreetDeck、YFdyh000、Classy Melissa、TimWu007並一併附知未參與討論串的地區類條目主要編者@瑞丽江的河水、Ngguls、Theodore Xu、A635683851。--BoyuZhang1998（留言） 2019年10月25日 (五) 05:30 (UTC)

支持僅標出「官方語言及當地通用語言」，如伊犁哈薩克自治州應標出哈薩克語及維吾爾語。中文地區文字相同而僅發音不同的不予考慮，屬於閩粵方言等較為特色的方言的可加{{Infobox Chinese}}信息框--苞米(☎)💴 2019年10月25日 (五) 05:53 (UTC)
廣州條目投票完成前，先不要展開討論。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年10月25日 (五) 06:37 (UTC)
正文內括注的話，只應標出當地的官方語言或者中國大陸民族地方所謂的政府工作語言（依各地自治條例所定）。任何拼音、轉寫、其他通用語言都應放到infobox Chinese里。一直覺得目前新疆西藏地區的條目開篇第一句很長一個括號不好看。--河水|滇 2019年10月25日 (五) 09:13 (UTC)
上面有兩個用戶名寫錯了。@克勞棣、Streetdeck：再ping一次。--春卷柯南編輯數突破二萬 ( 論功行賞·刻石留名 ) 2019年10月25日 (五) 10:49 (UTC)

為免影響廣州條目投票，先close掉上面的討論，完了可以重開。San mo sa _{災難固首發於荃灣} 2019年10月25日 (五) 14:51 (UTC)

廣州條目投票已結束，現重開討論。San mo sa _{災難固首發於荃灣} 2019年11月8日 (五) 04:52 (UTC)

說明：該投票大致上同意不在中國大陸地方的條目列出外文（如果某地為民族自治地方或屬於某民族自治地方，相關民族自治地方的民族所使用的語文的名稱不視為此建議中的投票所指的外語，有如新疆維吾爾自治區及其下轄政區的維吾爾語名、延邊朝鮮族自治州及其下轄政區的中國朝鮮語名等）及其他漢語拼音，惟其中有一定意見認為可列出郵政式拼音，故在此對BoyuZhang1998提案提出以下修正：

方案僅適用於中國大陸地方的條目；
所有拼音歸入Infobox Chinese處理；
特殊外文同上，除非其為郵政式拼音；
郵政式拼音允許置於條目導言，惟須有來源證明；

以上。我個人不太想動臺灣地方的條目，故不建議臺灣地方的條目適用；港澳地方的條目沒甚麼可以動的。San mo sa _{災難固首發於荃灣} 2019年11月8日 (五) 05:09 (UTC)

我不知道對中國大陸做這個特殊化規定的意義在哪裏？如果是大中華地區，或許還有些意義--百無一用是書生 (☎) 2019年11月8日 (五) 07:25 (UTC)

因為港澳臺地方的條目從來不會產生如此爭議，那些維持現狀即可。是中國大陸地方的條目大家才吵得那麼僵。San mo sa _{災難固首發於荃灣} 2019年11月8日 (五) 09:07 (UTC)

郵政式拼音應該是和標準語發音差異較大的可列出，否則不應列出。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年11月8日 (五) 14:36 (UTC)

「特殊外文」是指甚麼？有清楚的界定嗎？--【和平至上】^{抗議暴徒破壞、還我安寧香港}💬📝 2019年11月8日 (五) 12:16 (UTC)
記得若引用之前一系列討論中的部分意見看法，是包括台灣地方條目「放入日文都可能起爭議」，譬如在首段寫日語標註也被認為是不應該的，感覺這個方案既然是基於該系列論述而擬定，理應也起碼回應題目，先嘗試對等納入其他大中華地區，以便本地聯同檢視。——約克客（留言） 2019年11月8日 (五) 14:00 (UTC)
- 本來也沒必要列入日文名稱。哪怕是高雄和民雄之類的日本人取的名字。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年11月8日 (五) 14:33 (UTC)
- 同上。另外，我是因為不太想製造類近統戰的情況而建議僅適用於中國大陸地方的條目，臺澎金馬照樣導言放置閩／臺語即可；至於是否適用港澳地方的條目的分別不大。San mo sa _{災難固首發於荃灣} 2019年11月9日 (六) 11:38 (UTC)
可是...其他大中華地區例如馬來西亞和新加坡都擁有第二外語當作官方語言，更何況中文還不是馬來西亞的官方語言，說到底其他大中華地區也就那幾個而已，不同的狀況根本不能一起討論啊。 --無心*插柳*柳橙汁 2019年11月8日 (五) 14:14 (UTC)
- 照閣下原論述既有觀點的話，當有台灣城市在首段被添加日文標註，而不編輯添加的理據，是否仍需要本地自定引入一套格式守則處理？BoyuZhang1998的原初方案，已經有一個分類檢視的思路，於東南亞地域的，也是可以按照Boyu兄的路徑，進一步細化先做模擬處理的也是未嘗不可的。即使大陸範圍內也是有不同的狀況，若果有詳盡參詳一系列的論述，這個也是必要釐清的，於本地進一步檢視各地域的範疇，相信也會有更多裨益。——約克客（留言） 2019年11月8日 (五) 14:41 (UTC)
  - 大中華地區應該是指狹義的大中華地區，即中國內地、港澳、台灣。--【和平至上】^{抗議暴徒破壞、還我安寧香港}💬📝 2019年11月9日 (六) 06:01 (UTC)
  - 我原先的觀點為，台灣加註日文是因為其「歷史脈絡」的緣故才有那個條件，更何況當時我的意見是根本沒有必要（對比香港、新加坡、高雄，廣州絕對是最沒有加入外文的必要，而高雄雖然其名稱來自於日文，但台灣目前不採用日文為官方文字，目前高雄市的導言只是介紹該城市的名稱來歷。） --無心*插柳*柳橙汁 2019年11月10日 (日) 13:01 (UTC)
- 大中華地區應只限中國內地及港澳臺，星馬等地一般視為有既定中文名的非中文區處理。不過我仍然建議方案僅適用於中國大陸地方的條目。San mo sa _{災難固首發於荃灣} 2019年11月9日 (六) 11:38 (UTC)
- (－)反對加入郵政式拼音，閩粵地區等漢語發音特殊的地區可以添加{{Infobox Chinese}}。漢語拼音在中國大陸有着比郵政式拼音更特殊的地位，沒有理由不加漢語拼音，而加入郵政式拼音，所以僅支持首句不加入任何拼音，所有拼音可在正文介紹，或加入{{Infobox Chinese}}。--苞米(☎)💴 2019年11月10日 (日) 13:15 (UTC)
  - 「漢語拼音在中國大陸有着比郵政式拼音更特殊的地位」，我要求證據證明此聲稱。Sanmosa _{災難固首發於荃灣} 2019年11月12日 (二) 08:50 (UTC)
    - [9][10]具體來說是包含漢語和少數民族語言的漢語拼音字母具有更特殊的法定地位。在少數民族地區，使用漢語拼音字母拼寫的少數民族語言比對應漢語音譯的漢語拼音具有更強的法定地位。--146.96.147.137（留言） 2019年11月13日 (三) 02:06 (UTC)
    - @Sanmosa：另請參見《中國地名漢語拼音字母拼寫規則（漢語地名部分）》。內蒙古翻譯成「Nei Monggol」（既不是Nei Menggu也不是Obor Monggol）是有道理的。--146.96.147.137（留言） 2019年11月13日 (三) 02:11 (UTC)
首先高雄的語源和打狗一樣都是土著語。其次只支持原著語言及原著方言的標注（如藏語、滿語等）。中國大陸的並附上當地語言方言的漢語拼音字母轉寫，如藏語拼音、閩南拼音。這裏不是英語維基百科，首段和信息框不需要添加「Canton」之類的郵政式拼音。--146.96.147.137（留言） 2019年11月13日 (三) 00:24 (UTC)

讓大家討論一下

我這裏有兩個對BoyuZhang1998提案的修正案，大家看看哪一個會比較好：

方案A（原修正案）：
- 方案僅適用於中國大陸地方的條目；
- 所有拼音歸入Infobox Chinese處理；
- 特殊外文同上，除非其為郵政式拼音；
- 郵政式拼音允許置於條目導言，惟須有來源證明；
方案B：
- 方案僅適用於中國大陸地方的條目；
- 所有拼音（含郵政式拼音）歸入Infobox Chinese處理；
- 特殊外文歸入Infobox Chinese或其他適合放置外文的Infobox欄目處理；

以上。San mo sa _{災難固首發於荃灣} 2019年11月13日 (三) 02:07 (UTC)

完全反對這兩個方案。兩個方案都沒有尊重少數民族地區的民族區域自治規定的法定語言權利，前者還對中國語言地名的外語翻譯（如郵政式拼音）感興趣，是典型的不自重。--146.96.147.137（留言） 2019年11月13日 (三) 02:13 (UTC)
- IP是不是沒看我的說明？或許我再複製一次說明吧：如果某地為民族自治地方或屬於某民族自治地方，相關民族自治地方的民族所使用的語文的名稱不視為外語（如新疆維吾爾自治區及其下轄政區的維吾爾語名、延邊朝鮮族自治州及其下轄政區的中國朝鮮語名等）。San mo sa _{災難固首發於荃灣} 2019年11月13日 (三) 02:16 (UTC)
- 換言之：芒市的傣納語和景頗語名、烏魯木齊的維吾爾語名、呼和浩特的蒙古語名，這些我通通也不想動。Sanmosa _{災難固首發於荃灣} 2019年11月13日 (三) 02:21 (UTC)
  - 抱歉沒仔細看，對不起。--146.96.147.137（留言） 2019年11月13日 (三) 02:24 (UTC)
    - 我的意思是目前少數民族語言的位置有的跑到了infobox照片底下，不夠尊重，應當放到更顯眼的位置。--146.96.147.137（留言） 2019年11月13日 (三) 02:25 (UTC)
方案C：
- 中國語言（yuyan）、方言（tonguage）和土語（dialect），歸入首段和Infobox的明顯位置處理：
  1. 該方言（也包含蒙古語方言、苗語方言等）或語言在當地分佈廣泛；
  2. 漢語地名的語源為該語言；
- 一切外文歸入文章內容以及infobox的次要位置處理，以下情況例外：
  香港英語、澳門葡萄牙語、台灣西班牙語和荷蘭語如為漢語地名語源，應比照中國語言處理。
- 對於以上列出的語言、方言和土語，在中國大陸且存在漢語拼音字母（包含漢藏維哈柯）或閩南拼音字母的，一併列出，其餘可選擇列IPA；港澳列出粵拼和疍家話IPA等；台灣列出南島語拉丁名稱、漢語拼音和其他方言（閩客）的通用拼音。

以上--146.96.147.137（留言） 2019年11月13日 (三) 02:24 (UTC)

我的個人意見是：如果某地為民族自治地方或屬於某民族自治地方，相關民族自治地方的民族所使用的語文的名稱不視為外語（如新疆維吾爾自治區及其下轄政區的維吾爾語名、延邊朝鮮族自治州及其下轄政區的中國朝鮮語名等）之餘，亦應置於條目導言；但非民族自治地方且不屬於任何民族自治地方也加入的話，我有些憂慮方案C會造成原創研究風險，所以我要求如果要加入的話，須有來源證明且屬於中國少數民族語言。還有一點就是：我仍然主張方案應僅適用於中國大陸地方的條目，以免製造類近統戰的情況（統戰尚未成功，深圳河以北、臺灣海峽以西的同志們仍須努力，不過關閘以南已經一早成功了）。San mo sa _{災難固首發於荃灣} 2019年11月13日 (三) 02:33 (UTC)

還有一個意見，就是列出IPA的必要不大，應視為可選擇執行與否的措施。San mo sa _{災難固首發於荃灣} 2019年11月13日 (三) 02:40 (UTC)

謝謝，目前的問題是原住民族的語言方言不受尊重（包括香港的疍家話），不用放大鏡基本看不到。原創研究的問題首先只針對條目不針對標準，其次人口普查在那裏，超過百分之多少就要加完全可以。而且沒有標準就是誰想加就加想刪就刪；有「原創」標準其實降低了條目整體的原創度。目前維基百科「中國」引向「歷史文化意義的中國」，同時兩地閩南語使用了不同的方案，所以應該是沒有「統戰」的問題。--146.96.147.137（留言） 2019年11月13日 (三) 02:40 (UTC)

哈哈「統戰」這個太幽默了。本來覺得可以把「廣東拼音方案」也加上，不過那個方案實在太「官話」了，完全沒有考慮粵語使用習慣，所以乾脆客家話也不加了。--146.96.147.137（留言） 2019年11月13日 (三) 02:43 (UTC)

同意。--146.96.147.137（留言） 2019年11月13日 (三) 02:45 (UTC)

精簡一下：我的意思是土著語言（如漢語、蒙古語、南島語言）及其方言可以放在地名信息框內，四種外語（香港英語、澳門葡萄牙語、台灣西班牙語和荷蘭語）如成為漢語詞源同樣對待。其他外語一律歸入Infobox Chinese。羅馬化可放在首段，使用各地官方標準，比如閩南語內地的使用閩南拼音，台灣的用台通拼音，沒有官方標準的可以使用IPA，不使用具有宗教宣傳性的教會羅馬字（保證維基百科的信仰中立）。內滿洲存在一些不屬於既不符合《中國地名漢語拼音字母拼寫規則（漢語地名部分）》也不符合《少數民族語地名漢語拼音字母音譯轉寫法》的，比如Harbin、Jagdaqi同樣接受。前面看到方案AB沒有仔細看就發言，見諒。--146.96.147.137（留言） 2019年11月13日 (三) 08:10 (UTC)
我比較疑惑的是，中國大陸為何要區別對待？其特殊性在哪裏？與其他國家/語言相比有何不同，從而必須要單獨規定？--百無一用是書生 (☎) 2019年11月13日 (三) 08:33 (UTC)
- 命名沒有區別對待啊，只是把中國語言整體區別對待，因為是中國的地理。如果是印度的信息框，就同樣把印度語言區別對待優先加入信息框而不是外語。如果是玻利維亞的，就把玻利維亞本土語言區別對待。並沒有單獨規定中國的「特殊性」，更沒有「中國大陸特殊性」啊（正相反還規定了兩岸閩南語的不同拼音標準）。像這種提出的標準直接用「查找與替換」換個國名就可以做成世界上任何一個國家的信息框規則。--146.96.147.137（留言） 2019年11月13日 (三) 09:55 (UTC)

首段與信息框列出的方言民語

最新留言：4 年前50則留言11個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2020年1月8日 (三) 08:14 (UTC)。

@AirScott：這裏承接討論「#法國地名翻譯若干問題」的《§非法語名稱》小節中⚓方言民語處的討論。--146.96.147.137（留言） 2019年11月30日 (六) 06:27 (UTC)
@Sanmosa：這裏承接「關於對大中華地區行政區劃類、地名類條目加注非漢語文字及漢語羅馬化方案的方法作正式規範的建議」處的討論。--146.96.147.137（留言） 2019年11月30日 (六) 06:27 (UTC)

維基百科的很多台灣地名都在首段和信息框添加了方言民語，但當遇到中國大陸、法國等地城市遇到同樣處理時，卻遭到諸如「非官方語言」、「非雙語區」的反對，中國大陸地區的民族語言甚至被擠進了信息框圖片底下的小字。這種針對台灣地區的特殊化處理實質上是對台灣之外地區的多元文化的歧視，甚至有時能成為刷存在感的一種方式。因此，有必要一般性的對地方語言、民族語言加以大致規範。下面拋磚引玉先提幾個方案：

方案一：完全按照官方語言處理：
比如南非有11種官方語言，首段和信息框列出11種；

比如玻利維亞有三十餘種官方語言，首段和信息框列出三十餘種；

比如「中華民國」有百餘種官方語言，首段和信息框列出百餘種；

比如「中華人民共和國」沒有官方語言，首段和信息框不列出，儘管人民幣上印着五種語言；
- 缺陷：不實際，一些刷存在感的地區可以添加上千種官方語言，最後誰吼的聲音大誰的語言就能被列出。
方案二：不考慮「語言的官方地位」等形式上的稱號，考察實際使用，凡一語言在該地區、聚落有兩成人口使用，即可添加：
如佛羅倫薩不添加拉丁語；

如東帝汶、澳門不添加葡萄牙語；

如南平市作為聚落是官話區，不添加閩北語；

如嘉義市、嘉義縣~~不添加~~（更正：不添加鄒語）；

如里昂作為聚落是法語區，不添加法蘭克-普羅旺斯語。
方案三：如下語言可以添加：
1. 該語言在該地區、聚落有兩成人口使用的；
2. 該語言既是該地區具有某種實質的官方地位，可在日常生活中看到；
  - 比如漢蒙維藏壯五種語言之於「中華人民共和國」，每個人每天都能在自己使用的人民幣上看到；
  - 比如葡萄牙語之於東帝汶、澳門；
  - 比如西班牙語、克丘亞語、艾馬拉語、瓜拉尼語之於玻利維亞（主要針對瓜拉尼語，前三者已依照前一條添加）；
3. 該語言對當地具有重要歷史、文化意義；
  比如拉丁語之於佛羅倫薩；
  
  比如閩北語之於南平；
  
  比如宣州吳語之於宣城；
  
  比如鄒語之於玉山；
  
  比如葡萄牙語之於澳門；
  
  比如~~法蘭克-普羅旺斯語~~（更正：古法蘭克普羅旺斯語/古普羅旺斯語，二語文古語形式相同）之於格勒諾布爾。

如果有更好的方案，請在下方提出。--146.96.147.137（留言） 2019年11月30日 (六) 06:27 (UTC)

我的意見是：一、如果某地為中華人民共和國民族自治地方或屬於某中華人民共和國民族自治地方，相關中華人民共和國民族自治地方的民族所使用的語文的名稱（如新疆維吾爾自治區及其下轄政區的維吾爾語名、延邊朝鮮族自治州及其下轄政區的中國朝鮮語名等）置於條目導言，臺灣方面可以以原住民族地區比照民族自治地方、當地原住民族通行語比照民族自治地方的民族所使用的語文辦理；二、如果某地非中華人民共和國民族自治地方且不屬於任何中華人民共和國民族自治地方，相關方言／主要少數民族語言／外文名稱在有來源證明其一定的常用性／重要性的情況下亦（可）置於條目導言；三、可以設置一個列表規定哪些地區的地方／行政區劃條目可將哪些方言／少數民族語言／外文名稱置於條目導言而免於列出來源。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{災難固首發於荃灣} 2019年11月30日 (六) 06:56 (UTC)

漢語方言與法語方言怎麼辦？尤其是那種在現代標準漢語、標準法語中存在訛譯諧音的。我的觀點是：「母湯（閩南語：毋通）」、「比埃什地區聖朱利安（奧克語：Sant Julian de Buechaine）」這樣進行。--146.96.147.137（留言） 2019年11月30日 (六) 07:08 (UTC)

另外語言的列出應當是免於來源請求的吧？或者說，默認將相應的「某漢詞典」、「某英詞典」、「某法詞典」作為來源。不然的話，考慮到漢語維基里引用英文的量，足以吧整個漢語維基百科一般的條目用{{cn}}血洗一遍了。--146.96.147.137（留言） 2019年11月30日 (六) 07:13 (UTC)
- 語言的列出本身是免於來源請求，但如果語言的列入需有常用性／重要性證明的話，那時就需要來源，否則情況可以演化到比方案一更誇張的地步。ꓢꓯꓠꓟꓳꓢꓮ _{災難固首發於荃灣} 2019年11月30日 (六) 07:20 (UTC)
  - @Sanmosa：還是有個一致性的指引比較好，不然要是單一地區刷存在感的話基本就是整個維基百科給一個地區做廣告。--146.96.147.137（留言） 2019年11月30日 (六) 16:25 (UTC)
    - 有時候你必須要做那些廣告，世界上沒太多東西是可以各地完全一致的，再不然規定全部非本源語都要加上來源也可。ꓢꓯꓠꓟꓳꓢꓮ _{災難固首發於荃灣} 2019年12月1日 (日) 01:36 (UTC)
      - @Sanmosa：要求所有地方都適用於一個絕對嚴格的一致標準不現實，但總體的指導方針還是要的，不能任由地域中心主義人士發展的太厲害。--160.39.224.247（留言） 2019年12月7日 (六) 04:02 (UTC)

我在上面有說明方言（包括但不限於漢語、中國少數民族語言，其實就是世界通用）地名的處理方式。至於地名以外的處理方式應該不屬於討論範疇，應該因時制宜處理（以「母湯」為例，其語源是閩南語的「毋通」，如果「母湯」有關注度，相關來源應該提及它的語源，那樣在導言列舉閩南語名就非常適合）。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{災難固首發於荃灣} 2019年11月30日 (六) 07:20 (UTC)

@Sanmosa：我那個「母湯」只是個例子，說明訛譯現象。閣下以為玉山怎麼處理？按照閣下的方案似乎南島語言要不保。另外，國外的語言怎麼處理。--146.96.147.137（留言） 2019年11月30日 (六) 12:13 (UTC)
- 玉山的話可以看看這個：提及布農族聖山的布農族語文名稱是沒問題的；鄒族語文名稱方面，因為條目提及了「八通關」，理論上應該說明語源（而玉山也是鄒族聖山）；卡那卡那富族和排灣族則暫無來源。外文也是方言那套處理方式（但香港的英文使用率真的很高，我有些想SNOW），如果是英文／其他外文為原文（例如King County, Washington, USA）則不屬方言處理方式的範疇，且無須列明來源。ꓢꓯꓠꓟꓳꓢꓮ _{災難固首發於荃灣} 2019年11月30日 (六) 12:31 (UTC)
  - 也就是說閣下願意將「該語言對當地具有重要歷史、文化意義」一條納入考慮的？--146.96.147.137（留言） 2019年11月30日 (六) 13:11 (UTC)
    - 前提是有來源確定名稱如此（就例如條目列的布農族語文名稱就和我給的來源列的不一樣）。ꓢꓯꓠꓟꓳꓢꓮ _{災難固首發於荃灣} 2019年12月1日 (日) 01:36 (UTC)
      - 也就是說閣下原則上支持方案三，但是對方案三第三條要求嚴格的可靠來源，同時對方案三的第二條給出了在大中華區的給出了替代標準？--146.96.145.136（留言） 2019年12月3日 (二) 23:41 (UTC)
      - 如果閣下能夠將方案三第二條的替代標準應用在世界範圍內，就可以提出一個方案四了。--146.96.145.136（留言） 2019年12月3日 (二) 23:42 (UTC)

(＋)支持方案二用於法國--Patriotard 2019年11月30日 (六) 09:56 (UTC)
- 呃……話說澳門人裝了幾十年的蒜要把自己包裝成正港的葡語區了，這樣揭人老底真的好嗎？說得詭異一點：共產黨也努力把澳門包裝成葡語區好不容易準備拿來用一下「統戰」葡語國家，結果耕耘五十載，毀於維基。還是等等澳門人的反應吧。--146.96.147.137（留言） 2019年11月30日 (六) 12:09 (UTC)
  - 就法國本土而言，方案二沒有什麼問題。澳門不了解，若情況特殊可單獨拿出來討論--Patriotard 2019年11月30日 (六) 12:46 (UTC)
    - 如果給澳門特殊地位，那麼就相當於偏向澳門歧視法國的澳門地域中心主義（除非有特別的理由說明澳門的特殊性並將其納入標準）。葡語在澳門肯定比阿爾卑坦語在阿爾卑斯使用率少得多，只有3%人會說。--146.96.147.137（留言） 2019年11月30日 (六) 13:10 (UTC)
      - 「葡語在澳門肯定比阿爾卑坦語在阿爾卑斯使用率少得多」：阿爾皮坦語總使用人數14萬，除去意大利（7萬）和瑞士（0.7萬），法國境內僅剩不到7萬，而法國阿爾卑斯地區總人口數量（伊澤爾省125.3萬、薩瓦省43萬、上薩瓦省80萬、安省63.8萬、德龍省50.8萬、羅訥省183.6萬、盧瓦爾省76.2萬、外加上阿爾代什省東北部+阿爾卑斯普羅旺斯省北部+汝拉省南部約15萬人）差不多有637萬人，阿皮坦使用者數量不到1%，這還是1988年的數據--Patriotard 2019年11月30日 (六) 13:44 (UTC)
        你忘了排除里昂等大城市後這個總人口量直接折一半，然後法國境內的阿爾卑斯是一半的Arpetania一半的Occitania。所以最後在Arpetania的法國部分的農村地區FP語的L1 speaker得翻四倍。而澳門你畫不出任何一個區域葡語人口顯著的超出平均水平，而且前面的3%是包括L2 speaker的，L1要少得多。請注意阿爾卑斯坦尼亞有部分語境中是特指農村地區的。--146.96.147.137（留言） 2019年11月30日 (六) 13:52 (UTC)
        按照閣下標準，里昂也屬於FP語區，而且作為中心城市，如果真的成立FP語的組織機構的話，它很有可能出現在里昂，況且里昂人口也就一百多萬，遠折不了一半。阿爾卑斯地區的奧克語區只有上普羅旺斯阿爾卑斯省南部和上普羅旺斯省，另有瓦爾省、沃克呂茲省和濱海阿爾卑斯省的零星區域，人口加起來不超過50萬。法國行政上沒有農村/城市這種劃分，故「農村地區」沒有一個具體的判斷標準（里昂機場出來全是農田）。如果閣下認定阿爾卑斯地區現階段通用FP語或者奧克語而不是法語，請提供相關資料--Patriotard 2019年11月30日 (六) 14:28 (UTC)
        我好像沒說過「里昂屬於FP語區」。里昂添加FP語的理由是「該語言對當地具有重要歷史、文化意義」，類似於南平的閩北語。里昂是不可能「該語言既是該地區具有某種實質的官方地位，可在日常生活中看到」或「該語言在該地區、聚落有兩成人口使用的」添加FP語的。同時我也未曾說要依照方案三的前兩條將FP語加入整個Arpitania，這些臆想只是您的個人理解，沒有必要扣我帽子。至於人口，Rhône-Alpes大區把（Lyon area : 2,188,759 inhabitants (2011) Grenoble area : 675,122 inhabitants (2011) Saint-Étienne area : 508,548 inhabitants (2011) Valence area : 175,095 inhabitants (2011)）一刪就只剩一半人口了，裏面Occitania目測有一半（看地圖：oc:Grenòble就已經在邊界線上了），雖然不可能達到20%的標準，但秒掉澳門葡語還是很輕鬆的。--146.96.147.137（留言） 2019年11月30日 (六) 14:34 (UTC)
        其它城市我不亂說，從語言地理學上看，聖艾蒂安及所在的整個盧瓦爾省都是名副其實的FP語區，但就我在那住過的幾個月來說（包括Bourg Argental），FP語通行度為0，注意，不是極低，是0。所以還是那句話，如果閣下認定阿爾卑斯地區現階段通用FP語或者奧克語而不是法語，請提供相關資料--Patriotard 2019年11月30日 (六) 15:01 (UTC)
        還是前面那個討論里講的：「當地人會講」和「當地人會和你講」是完全不同的概念，參見#田野。一個西伯利亞長相的人去澳門也會發現澳門葡語「通行度為零」，因為別人看到他就會假設他不可能會說，從而避免使用葡語。通行度雖低，但總比澳門葡語高。--146.96.147.137（留言） 2019年11月30日 (六) 15:11 (UTC)
        
        另外，題外話，聖艾蒂安首先是城市，其次連山都沒進，還處於丘陵地帶，可能真會是0。--146.96.147.137（留言） 2019年11月30日 (六) 15:17 (UTC)
        我大概就知道閣下會說這個。不好意思，我2014年第一次去聖艾蒂安踢球的時候就問過當地老闆「你們說FP語嗎」這個問題，得到的是否定答案，當地方言叫Gaga的，有一些詞彙和法語略有不同，我早期編輯百度百科的時候有此描述，但和真正的FP語差得很遠。後面去常住的時候再次有所討論，加上親身經歷，完全印證了當地FP語0通行度的說法。聖艾蒂安是歐洲海拔第二高的十萬人口城市，「山都沒進」？？？所以，閣下若有充足的理由或更深刻的經歷，請提供相關來源--Patriotard 2019年11月30日 (六) 15:27 (UTC)
        好吧，海拔500米，勉強算個「高原」吧（笑）。算不算山，你打開Google地形圖對比格勒諾布爾一帶一看就清楚。比里昂還往西，就算按照100年前的標準也是「過渡區」，何來「核心區」一說？唉，我要是懂法語，一定在Grenoble爬山時問問高山草甸上放牧的大鬍子，相信他是會說的。閣下提到的相信是fr:parler gaga吧，閣下在Bourg Argental的經歷確實說明在整個西部FP在其西部丘陵區一如同滿語在中國東北的境況，但總人口擺在那，東部肯定是有核心區的。請注意這裏說的是澳門，和澳門的葡語比，我並沒有說FP通行度高，只是比澳門葡語高。--146.96.147.137（留言） 2019年11月30日 (六) 15:35 (UTC)
        FP語的核心區在意大利境內，歷史上的話則包括了整個Savoie公國，然而後者並不包括格勒諾布爾。澳門的情況我不了解，不下結論。--Patriotard 2019年11月30日 (六) 16:37 (UTC)
        抱歉，寫的比較倉促，我想說的是古奧克語之于格勒諾布爾，已更正。另外從格勒諾布爾向北到Savoy大面積山區很多地方都是汽車根本開不進去的，有不少山地牧民，相信存在很大面積雙語區，不過這個可以以後再說。--146.96.145.136（留言） 2019年12月3日 (二) 23:33 (UTC)
        
        澳門嘛，有個好處，就是你想找會說葡語的人也不難找到。反正總共就那麼大地方，大不了掃一遍。地方大利於產生少數群體語言聚居區，地方小利於你搜索少數群體。--146.96.147.137（留言） 2019年12月11日 (三) 01:04 (UTC)
- @AirScott：閣下把意見改成「支持方案二用於法國」了啊？那麼要看閣下是否支持方案二用於其他國家了，如果是，則還是上述問題。如果否，則因違反中立性而無法採納。--146.96.147.137（留言） 2019年12月11日 (三) 01:04 (UTC)
  - 回復IP，本人對法國以外的事物不甚了解，故不確定方案二提到的其它地方是否都和法國的情況相同，如果是的話那我肯定支持。--Patriotard 2019年12月11日 (三) 09:13 (UTC)
    - 方案寫的很清楚了：「聚落有兩成人口」，當然具體到各個國家還可以有所鬆動，但不能太離譜。--146.96.147.137（留言） 2019年12月12日 (四) 01:44 (UTC)
      - 像語言歷史文化這種主觀性和地域性很強的內容，本人並不贊成搞個大一統的世界性方案。關於法國境內的非法語標註，本人已經解釋的很清楚了。閣下草擬的方案二僅是單從人口數量來判斷，而沒有考慮具體的環境（如澳門作為近現代殖民地，語言使用情況和歷史古城裏昂有着明顯的區別），基於此條，方案二推廣於全世界是不可行的；而方案三裏面的第三條「重要歷史文化意義」概念很模糊，請問古法蘭克普羅旺斯語/古普羅旺斯語之於格勒諾布爾有何歷史文化意義？因為歷史上有群體使用過？因為在書籍中出現過？如僅是這樣則Canton也符合此標準。--Patriotard 2019年12月12日 (四) 09:22 (UTC)
        閣下是想說針對殖民地特殊處理？如果這樣可以給出一個方案四啊。至於Grenoble的情況，我願意在正式方案中去除一切例子，所以過於具體的可以不必討論。建立這樣的機制是為防止到A地就有人將「無通行度不用列出」到B地就有人講「有重要文化意義就可以列出」的不一致性。至於什麼情況具有重要文化意義，完全可放到具體條目里討論。--146.96.145.33（留言） 2019年12月16日 (一) 22:04 (UTC)
方案四(AirScott方案)針對殖民地、前殖民地採用方案三列出殖民語言，針對其餘情況採用方案二。--146.96.145.33（留言） 2019年12月16日 (一) 22:04 (UTC)
(－)反對方案二用於澳門，澳門很多事物是以葡萄牙語命名為先，事後給中文譯名，不在首段列出反而不妥。(＋)支持方案三。--街燈電箱150號開箱維修抄錶檢驗證明 2019年11月30日 (六) 17:16 (UTC)

請問為什麼方案二中，嘉義市、嘉義縣不添加？這兩個縣市的臺灣話的使用人口明顯超過兩成。-游蛇脫殼/克勞棣 2019年12月1日 (日) 02:26 (UTC)

抱歉，寫的比較倉促，我想說的是不添加鄒語沒有寫全，已更正。--146.96.145.136（留言） 2019年12月3日 (二) 23:33 (UTC)

添加本地語言理所當然。港九自由嘻嘻嘻（留言） 2019年12月14日 (六) 12:50 (UTC)

所以閣下也支持方案三？--146.96.145.33（留言） 2019年12月16日 (一) 22:04 (UTC)

正式開新提議

我建議採用方案3A。方案3A與方案3的差別不大，唯一有分別的地方是：如相關非中文地名非地名本文，則要求來源證明有此名及符合相關條件。亲，我簽名那刻的時間是 2019年12月22日 (日) 11:34 (UTC)

可否解釋下「地名本文」的概念？--69.94.58.75（留言） 2019年12月23日 (一) 02:28 (UTC)

大概就是地名譯名本文的意思，例如金縣的本文是King County、Hong Kong的本文是香港（不過實際上是香港仔）、Macau的本文是媽閣、亞的斯亞貝巴的本文是አዲስ አበባ。亲，我簽名那刻的時間是 2019年12月23日 (一) 15:01 (UTC)

就是「詞源」的意思？那麽Taipa的「本文」是凼仔還是大把？曼哈頓的「本文」是Manna-hata還是mënatay還是Manna-hatan？我擔心「本文」這一概念會對百分之八十的條目無法確定。--146.96.147.137（留言） 2019年12月25日 (三) 03:23 (UTC)

@Sanmosa：贊同閣下修訂的方向，不過方案本身我覺得還得換一種稍精確些修訂方式。--146.96.147.137（留言） 2019年12月31日 (二) 04:43 (UTC)

為Wikipedia:格式手冊添加例子

最新留言：4 年前2則留言2個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2020年7月13日 (一) 08:14 (UTC)。

現行條文

我們鼓勵所謂的「自由連結」：當您見到文中某些字詞名稱值得讀者參考閱讀的話，請使用[[]]代碼轉成內部連結。請注意不要作過多的連結，例如不要把一句的每一個詞，或者通篇文章都為同一個詞作出多次的連結：只要連結該詞第一次出現就夠了。

符合命名常規的連結會更容易成功鏈到已存在的條目；即使那條目還未存在，這樣的連結也能夠令未來新增的條目得到正確的名字。

連結所顯示的文字不一定要與目標條目的名稱相同，如[[朱熹|朱子]]。但請確保讀者不需按下連結也能夠清楚連結的目的地。

請儘量準確地連結。如果您想連結的條目還未存在，請先搜尋一下來確定該條目真的是不存在──它實際的名稱可能只是與您所想的名稱相差一點。

提議條文

我們鼓勵所謂的「自由連結」：當您見到文中某些字詞名稱值得讀者參考閱讀的話，請使用[[]]代碼轉成內部連結。請注意不要作過多的連結，例如不要把一句的每一個詞，或者通篇文章都為同一個詞作出多次的連結：只要連結該詞第一次出現就夠了。

符合命名常規的連結會更容易成功鏈到已存在的條目；即使那條目還未存在，這樣的連結也能夠令未來新增的條目得到正確的名字。

連結所顯示的文字不一定要與目標條目的名稱相同，如[[朱熹|朱子]]。但請確保讀者不需按下連結也能夠清楚連結的目的地，比如以下這個例子是不恰當的：

......導致了原定接班人[[林彪]]的[[九一三事件|死亡]]。

在這個例子中，很容易使讀者感到迷惑：我要點進去的這個連結到底是條目「死亡」？還是「林彪之死 - 九一三事件」？因此，可以改成這個：

......導致了原定接班人[[九一三事件|林彪的死亡]]。

在這個例子中，讀者可以很清楚地明白，林彪死亡了，並且該內鏈指向的就是介紹林彪死亡的條目。

......導致了原定接班人[[林彪]]在[[九一三事件]]中死亡。

在這個例子中，內鏈直接指向它的文字所表達的條目，因此最為清楚直觀，但並不是任何情況都適用的，有的時候使用這種方式反而會導致文字過長，或者讀起來不通順。具體內鏈的使用方法應由編者自行斟酌。

請儘量準確地連結。如果您想連結的條目還未存在，請先搜尋一下來確定該條目真的是不存在──它實際的名稱可能只是與您所想的名稱相差一點。

--Key to Sky遠い空へ（討論｜貢獻） 2020年7月13日 (一) 22:54 (UTC)

提議修訂格式手冊有關地區詞的部分內容

最新留言：4 年前18則留言6個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2020年7月24日 (五) 00:14 (UTC)。

在討論WP:PB時，發現WP:格式手冊#地區用詞的格式一段存在一些問題。經查，此段的部分內容出現在2004年，當時似乎還沒有繁簡轉換，此後該部分在2009年變為和今日類似，此章節的其他內容是在2013年由U:Skyfiler加入的。又經查，該用戶在Wikipedia:互助客棧/方針/存檔/2013年10月#方案5提出翻譯英文格式手冊，在無共識的情況下逕行翻譯並修改加入（居然沒人發現），其翻譯內容無法反映當時的共識。然而由於已放進去7年之久，不能直接去除。在此提案刪除其中的某些部分，並修改一些部分。主要理由是，與enwp不同，zhwp存在地區詞轉換，其中的部分內容並無必要，或可能與其他方針或指引及社群慣例衝突。請社群審視。

現行條文

地區用詞的格式維基百科並沒有對各個地區用詞的偏好。世界各地的中文使用者對同一樣的事物可能有不同的叫法。維基百科已經實行自動地區詞處理，能按照讀者選擇的地區（中國大陸、台灣、香港、新加坡）而顯示當地的用詞或譯名。編輯時可使用{{NoteTA}}、{{地區名稱}}，另參閱Wikipedia:繁簡分歧詞表及Wikipedia:譯名表。

共用名維基百科嘗試找到各個地區都能夠通用的用詞。堅持地區用詞並不能體現維基百科的全球性。

能夠在每個地區都通用的用詞通常應被優先選擇，特別是在文章的標題之內。
如果一個叫法被用作條目標題，其他的叫法應有重定向到該條目。
在某個地區不流行的詞，如有提到，則應該進行解釋以避免讀者的困惑，例如四清、上山下鄉、水喉等。
儘量使用精準的用詞而避免有歧義的用詞，例如在統計數據中使用人民幣/台幣/港幣做單位而不是元，即使引用的文獻原文是用元做單位。

和文章內文一致儘管維基百科不偏好某個地區用詞，在一個條目中的用詞應該保持一致。可以使用自動地區詞處理提供的模板來自動化文字的轉換。例外的場合有：

引用他人的文章時應忠實於原文
作家、導演、音樂家們的作品名字應忠實於作者
比較各地用詞差異時

和地區的強烈關聯和地區關係重大的條目應使用該地區的用詞。例如，中國大陸地區相關的條目，使用中國大陸常用的詞彙；同樣地台灣/香港地區相關的條目，應使用對應地區慣用的詞彙。對於作家來說，應使用和作品更相近的地區的用詞。

本規則不能用來聲明地區對條目的所有權，參照維基百科:條目的所有權。

保持現有的版本對於地區用詞的爭論不被鼓勵。這通常是浪費時間，造成激烈的討論但是不能解決問題。在內文的用詞一致性已經建立之後，在沒有共識改變這一用詞的情況下，原用詞應予保留。除了上面列出的少數理由之外，通常沒有好的理由來支持用詞方面的變動。在內文的用詞一致性尚未建立時，第一個將條目補充至超出小作品篇幅的作者的用詞應作為默認的選擇。

提議條文

地區用詞的格式維基百科並沒有對各個地區用詞的偏好。世界各地的中文使用者對同一樣的事物可能有不同的叫法。維基百科已經實行自動地區詞處理，能按照讀者選擇的地區（中國大陸、台灣、香港、澳門、馬來西亞、新加坡）而顯示當地的用詞或譯名。編輯時可使用{{NoteTA}}、{{地區名稱}}，另參閱Wikipedia:繁簡分歧詞表及Wikipedia:譯名表。

共用名維基百科嘗試找到各個地區都能夠通用的用詞。堅持地區用詞並不能體現維基百科的全球性。

能夠在每個地區都通用的用詞通常應被優先選擇，特別是在文章的標題之內。
如果一個叫法被用作條目標題，其他的叫法如果本身沒有歧義，則應有重定向到該條目。
在某個地區不流行的詞，如有提到，則應該進行解釋以避免讀者的困惑，例如四清、上山下鄉、水喉等。
儘量使用精準的用詞而避免有歧義的用詞，例如在統計數據中使用人民幣/台幣/港幣做單位而不是元，即使引用的文獻原文是用元做單位。

條目用詞的一致性儘管維基百科不偏好某個地區用詞，在一個條目中的顯示用詞應該保持一致^{[註 1]}。可以使用自動地區詞處理提供的模板來自動化文字的轉換。例外的場合有：

引用他人的文章時應忠實於原文
各種專有名詞，例如作家、導演、音樂家們的作品名字和公司名稱應忠實於作者
比較各地用詞差異時

保持現有的版本一般而言，對於地區用詞的爭論只會浪費時間和造成激烈的討論，而不能解決任何問題。在條目的用詞一致性已經建立之後，在沒有共識改變這一用詞的情況下，原用詞應予保留。除了上面列出的少數理由之外，通常沒有好的理由來支持用詞方面的變動。

在條目的用詞一致性尚未建立時，除非另有共識，否則第一個將條目補充至超出小作品篇幅的作者的用詞應作為默認的選擇。

^ 使用地區詞處理至一致也算作一致

Koala0090--DRIZZLE _{(按此給我留言）} 2020年6月27日 (六) 16:35 (UTC)

建議在和文章內文一致的例外的場合中加入專有名詞（公司名稱等）。--【和平至上】^{反對美國各地警方以過度武力鎮壓和平示威者}💬 2020年6月28日 (日) 11:16 (UTC)

已完成。不過我仍然在想在有地區詞轉換的情況下，怎麼才能用到這一段。--DRIZZLE _{(按此給我留言）} 2020年6月28日 (日) 12:52 (UTC)

建議把「如果一個叫法被用作條目標題，其他的叫法應有重定向到該條目」和「在內文的用詞一致性尚未建立時，第一個將條目補充至超出小作品篇幅的作者的用詞應作為默認的選擇」根據現實的情況修改為「如果一個叫法被用作條目標題，其他的叫法如果本身沒有歧義，則應有重定向到該條目」和「在內文的用詞一致性尚未建立時，除非另有共識規定，否則第一個將條目補充至超出小作品篇幅的作者的用詞應作為默認的選擇」。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{試問卷簾人卻道海棠依舊} 2020年6月28日 (日) 11:46 (UTC)

已完成。--DRIZZLE _{(按此給我留言）} 2020年6月28日 (日) 12:52 (UTC)

(＋)支持。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{試問卷簾人卻道海棠依舊} 2020年6月29日 (一) 05:39 (UTC)

我想不如把「不被鼓勵」這個換成更自然的用語吧。--Super Wang※慶祝香港回歸廿三年暨特區國安法順利實施🇭🇰🇨🇳 2020年7月1日 (三) 09:30 (UTC)

「對於地區用詞的爭論不被鼓勵。這通常是浪費時間，造成激烈的討論但是不能解決問題。」這一句似乎是生硬翻譯。我建議修改為「一般而言，對於地區用詞的爭論除了浪費時間和造成激烈的討論外，並不能解決任何問題。」只不過，各方似乎都很願意浪費時間。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{他從不掙扎} 2020年7月1日 (三) 11:34 (UTC)

依照上述提議代為修改提案。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{他從不掙扎} 2020年7月4日 (六) 07:51 (UTC)

@Sanmosa：語句是通順了，但似乎是個病句。例句，「對於本店商品的售價，除了店長與總經理外，沒有人能決定」；所以閣下的句子意味着「浪費時間和造成激烈的討論能解決問題」？故在下建議改為「一般而言，對於地區用詞的爭論只會浪費時間和造成激烈的討論，並不能解決任何問題。」，以上。-游蛇脫殼/克勞棣 2020年7月5日 (日) 02:27 (UTC)

調整了。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{他從不掙扎} 2020年7月5日 (日) 02:29 (UTC)

(！)意見@克勞棣：這個例句和之前的句子結構不同，「店長與總經理」是名詞性短語，「浪費時間」是動賓短語。之前的句子並非病句。 DRIZZLE _{(按此給我留言）} 2020年7月8日 (三) 15:20 (UTC)

(：)回應@DrizzleD：可是我認為的「病」是「除了......以外」的使用方式。-游蛇脫殼/克勞棣 2020年7月8日 (三) 15:49 (UTC)

(：)回應@克勞棣：「除了」是連詞，排除之部分和其他部分句法性質上是一樣的，表示所說的不計算在內。因此我認為，前一句話「對於地區用詞的爭論除了浪費時間和造成激烈的討論外，並不能解決任何問題」，「浪費時間和造成激烈的討論」和「並不能解決任何問題」屬於一樣性質的短語，因此原句理解為「爭論地區用詞浪費時間和造成激烈的討論，（且）不能解決任何問題」，不應該理解為「浪費時間和造成激烈的討論能解決問題」。而「對於本店商品的售價，除了店長與總經理外，沒有人能決定」則是「店長與總經理」和「沒有人」相對，代表「（只有）店長與總經理能決定本店商品的售價」。--DRIZZLE _{(按此給我留言）} 2020年7月8日 (三) 16:04 (UTC)

(：)回應@DrizzleD：好吧！只要閣下確信這樣寫是對的，且不致被誤解，那就改回來吧！-游蛇脫殼/克勞棣 2020年7月8日 (三) 16:23 (UTC)

改不改回去就無所謂啦

囧rz... --DRIZZLE _{(按此給我留言）} 2020年7月8日 (三) 16:28 (UTC)

根據WP:7DAYS法則，提案已有七日無留言，可公示，故現公示七日。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{他從不掙扎} 2020年7月16日 (四) 00:06 (UTC)

編輯請求 2020-07-27

最新留言：4 年前5則留言5個人參與討論

請求已拒絕--Xiplus#Talk 2020年7月29日 (三) 02:44 (UTC)

將「不要花哨華麗」更改為「不要花俏華麗」(更正錯字)--BrianChen1107（留言） 2020年7月27日 (一) 15:32 (UTC)陳柏任

(－)反對。有「花哨」一詞，沒有「花俏」一詞。（大陸用戶） -- 鐵塔（留言） 2020年7月28日 (二) 00:07 (UTC)

(－)反對花哨是裝飾豔麗、語詞變化豐富，花俏是色彩鮮豔、活潑。 KONNO Yumeto ^肺炎退散 2020年7月28日 (二) 14:01 (UTC)

(－)反對，請去客棧-- Sunny00217 2020年7月29日 (三) 01:19 (UTC)

不得修反例

最新留言：4 年前1則留言1個人參與討論

以校輔為主題 Linadsl（留言） 2020年10月9日 (五) 03:30 (UTC)

不得修反

最新留言：4 年前1則留言1個人參與討論

以校輔為主 Linadsl（留言） 2020年10月9日 (五) 03:30 (UTC)

用浪紋線表示範圍

最新留言：4 年前15則留言13個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2020年10月24日 (六) 16:14 (UTC)。

我想問格式手冊中以下三處為什麼要求大家不要用浪紋線表示範圍？

Wikipedia:格式手冊#時間、數字、度量衡：「請不要使用浪紋」
Wikipedia:格式手冊/標點符號#連接號：「中華人民共和國國家標準及中華民國教育部標準中浪紋線「～」可與一字線通用，但在維基百科中不建議採用浪紋線。」
Wikipedia:格式手冊/日期和數字#原則：「中英文及阿拉伯數字混用以表示延續範圍，應使用……。浪號「~」和「～」亦不符合中文造字習慣。」

格式手冊自己都說了，兩岸的政府標準都允許用浪紋線，我不懂禁止的理由是什麼。所謂「不符合中文造字習慣」意味不明，似是原創研究。如果是說中文應該用直線的話，那顯然並非事實：不管是括號、逗號、還是中文字的辶、乙、乚等等都有彎曲。我在台灣從小學到大學的每一位老師，不管是數學、歷史、化學科，不管是課本還是老師在黑板上寫的字，全都是用浪紋線來表示範圍。我反倒覺得用橫線和數字寫在一起很容易被誤會成減號，或是跟中文在一起被誤會成「一」字。如果沒有合理的反對原因，我希望修改這三處指引，允許使用全形浪紋線。

Wikipedia:格式手冊#時間、數字、度量衡#時間、數字、度量衡

現行條文

對於日期段當中，應使用全形連字符「－」（Unicode：U+FF0D）連接，如：

1906年－1967年10月17日

請不要使用浪紋：

~、～

注意連接號「－」不是破折號使用的「—」。

提議條文

對於日期段當中，應使用全形連字符「－」（Unicode：U+FF0D）或浪紋線「～」連接，如：

1906年－1967年10月17日

注意連接號「－」不是破折號使用的「—」。

Wikipedia:格式手冊/標點符號#連接號

現行條文

連接號是用作標示某些相關聯成分之間的連接。連接號的形式可分為：短橫線「-」和一字線「－」。中華人民共和國國家標準及中華民國教育部標準中浪紋線「～」可與一字線通用，但在維基百科中不建議採用浪紋線。如果輸入一字線不方便，可以使用{{一字線}}（{{連接號}}）

提議條文

連接號是用作標示某些相關聯成分之間的連接。連接號的形式可分為：短橫線「-」和一字線「－」。中華人民共和國國家標準及中華民國教育部標準中浪紋線「～」可與一字線通用。如果輸入一字線不方便，可以使用{{一字線}}（{{連接號}}）

Wikipedia:格式手冊/日期和數字#原則

現行條文

中英文及阿拉伯數字混用以表示延續範圍，應使用中文的連接號，即英文全形的「－」，來連接，不是破折號「—」。浪號「~」和「～」亦不符合中文造字習慣^[1]。例如：1906年－1967年10月17日、15千米－200千米。

^ 參見維基百科:格式手冊之第2節「時間、數字、度量衡」和7.14節「連接號」。

提議條文

中英文及阿拉伯數字混用以表示延續範圍，應使用中文的連接號，即英文全形的「－」或浪號「～」，來連接，不是破折號「—」。例如：1906年－1967年10月17日、15千米～200千米。

以上--Yel D'ohan（留言） 2020年10月7日 (三) 23:11 (UTC)

香港不用波浪線，供參考。--Temp3600（留言） 2020年10月8日 (四) 04:39 (UTC)
目前的規定：地域包容性強，能夠覆蓋不使用（或常用）的地域；使用範圍包容性強，如根據GB/T 15834-2011，波浪線不僅只是有時使用，而且使用範圍較橫線來得小，統一用範圍更大、更常用的可以避免額外對使用範圍進行界定；實現統一，避免各條目混雜使用（在前述兩點及大致上看現有的各種來源官方命名以橫線居多的情況下，統一為一字線更適宜）。--Kirk★ 0#0 2020年10月8日 (四) 08:29 (UTC)
囧……一直到2012年移居國外之前，我只在外文期刊上看過用一字線表示範圍。不過這似乎也沒辦法作為地區詞轉換，因為只有一個字元，而且很多ACG作品名稱的中譯仍保留了浪紋線……--Yel D'ohan（留言） 2020年10月8日 (四) 12:05 (UTC)
反對使用波浪號，行之已久，統一比較好。－hiJK910 ^七一_七二一 2020年10月8日 (四) 12:17 (UTC)
除非根據「名從主人」，作品名明確使用波浪線，否則其他地方應保持原有規範。烏拉跨氪 2020年10月8日 (四) 16:22 (UTC)
我感覺在台灣波浪線比一字線更常用，而且用法完全和格式手冊中描述的全形一字線相同。這裏提供幾個例子：中華民國氣象局的氣溫、中華民國主計處的年齡（表一到四）和時數（表六）、台灣大學課程時間、大學指考中的溫度和雨量（第29題）、台北捷運營運時間和班距、貓空纜車營業時間（中、英、日文版都用浪紋線）。我理解技術上可能不容易轉換，但是為了追求條目統一完全禁用我覺得不合理，至少應該允許在條目內部統一的情況下先到先得。--Yel D'ohan（留言） 2020年10月8日 (四) 17:25 (UTC)
依據重訂標點符號手冊，連接號為甲式，波浪號為乙式。不過在國際用法，表示範圍沒有在用波浪號的。我認為標準可以修改成優先推薦連接號，波浪號雖不推薦但不禁止使用。臺灣杉在此發言 (會客室) 2020年10月9日 (五) 03:41 (UTC)
(－)反對：用浪紋很奇怪，沒必要改。--203.145.94.216（留言） 2020年10月9日 (五) 11:36 (UTC)
說點可能些微離題的，典範條目約翰·塞巴斯蒂安·巴赫之前一度全文使用波浪號，後來被其他用戶修改為連接號。我在典範條目評選的時候問過主編標點符號的問題（那個時候條目還沒被改），茲將其回應摘錄如下：「根據格式手冊#連結號，『連接號是用作標示某些相關聯成分之間的連接。連接號的形式可分為：短橫線「-」和一字線「－」。中華人民共和國國家標準及中華民國教育部標準中浪紋線「～」可與一字線通用，但在維基百科中不建議採用浪紋線。』由以上語句判斷維基並不硬性規定『～』和『－』⋯⋯」他的回應以現行方針與指引來看合理嗎？—— Eric Liu_{歡慶雙十中國國慶（留言．留名．學生會）} 2020年10月9日 (五) 13:41 (UTC)
未見到要用全形浪紋的必要性，本來全形連字符就夠奇怪的了，沒什麼必要整這一出。—Mint Candy♫ _{歡迎參與浙江專題台州專題} 2020年10月16日 (五) 14:51 (UTC)
(＋)贊成：橫線的種類太多，很容易混淆，（似乎天天有人在把一種橫線改成另一種橫線）不如用波浪線明確。 -- 鐵塔（留言） 2020年10月27日 (二) 02:45 (UTC)
不支持。開放浪紋對讀者的幫助相當有限，但對版面紊亂度恐怕頗有助益 囧rz……。--Hjh474（留言） 2020年10月27日 (二) 06:56 (UTC)
(－)反對：看不出必要性。-- Marcus Hsu ✉ 2020年12月1日 (二) 01:26 (UTC)

在格式手冊增加對摺疊內容的限制

最新留言：4 年前24則留言9個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2020年12月22日 (二) 16:14 (UTC)。

公示期滿，通過。--Easterlies 2020年12月19日 (六) 09:51 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

光明頂 (廣播節目)中摺疊內容已經成了瑣碎信息列表的避風港。因此有必要修訂格式手冊以限制條目中准許的摺疊內容。-Mys_721tx（留言） 2020年12月1日 (二) 19:19 (UTC)

上述條目摺疊部分的內容可以大刀闊斧刪掉。--小羊（留言） 2020年12月2日 (三) 04:00 (UTC)

已移除。格式手冊修訂的討論應繼續進行。-Mys_721tx（留言） 2020年12月2日 (三) 04:37 (UTC)

想問下Wikipedia:隱藏元素第二段關於Wikipedia:格式手冊#滾動列表與摺疊元素哪裏去了？--Air7538#Sign 2020年12月2日 (三) 06:04 (UTC)

粗略查看了一下2011年起就沒有該章節。-Mys_721tx（留言） 2020年12月2日 (三) 06:25 (UTC)

其實是從來都沒有那個章節吧。SAN MO SA _SPQR 2020年12月2日 (三) 06:43 (UTC)

現行條文

提議條文

滾動列表與摺疊元素

快捷方式

滾動列表和可在摺疊與顯示之間切換的摺疊元素可妨礙讀者訪問維基百科。此類功能不應用於隱藏「劇透」內容。模板一般不應存儲條目文字，以免妨礙編輯搜索修改相關內容。

45%的維基百科讀者通過移動版訪問維基百科^[a]；此比例還在不斷上升。移動版所支持的功能有限。使用滾動列表與摺疊元素等功能時，應注意保證相關內容可在移動版及在不支持JavaScript或CSS的設備上訪問。可通過頁面底部「手機版視圖」連結檢查該頁面是否可在移動版上閱讀。^[b]

摺疊模板不應默認在頁面加載完畢後隱藏條目內容，包括參考文獻列表、表格、列表、圖集、題注等。雖然維基百科允許一些支持collapsible參數或帶有手工加入的CSS類的模板，除下列允許情況外，collapsed、mw-collapsed、autocollapse等狀態不應於條目中用作預先隱藏這些元素。任何以此方式在加載頁面時隱藏的內容對前述用戶及通過Google訪問維基百科的低帶寬用戶完全不可見。^[c]若干其他CSS類在人工加入條目或有模板引入時也會導致移動用戶無法讀取帶相關標籤的內容。^[d]

僅僅為重複正文的單元格或章節可摺疊或自動摺疊（純粹的補充內容亦可如此：展示當前統計數據時可摺疊往年數據）。自動摺疊是導航模板的特性之一。一些信息框也摺疊了不常用細節。若列表、信息框、其他非導航內容中的信息足夠無關或瑣碎需要摺疊，可考慮發起討論徹底移除此類信息。若有關資料有重要性，但因條目密度或長度需要隱藏，可考慮劃分更多章節、將無必要的列表改寫為散文、拆分條目。

備註

^ 見每月底更新的頁面訪問量統計。該統計僅計算頁面點擊量；事實上大多數讀者在一定時間內使用過流動裝置訪問維基百科。
^ 可將網址中的zh.wikipedia.org替換為zh.m.wikipedia.org後加載新網址訪問移動版頁面。在流動裝置上訪問桌面版頁面無助於評估移動頁面顯示問題，但可用於診斷平板電腦等設備上的親和力問題。
^ 如上文所述，切換顯示或隱藏狀態需要CSS與JavaScript。即便設備支持上述功能，移動版伺服器會自動去除隱藏內容。Google於2016年在印度和印度尼西亞為低帶寬用戶提供精簡版頁面，該服務會去除導航框和隱藏內容。Google還計劃在其他國家地區提供該服務。 [1] [2]
^ 導致此問題的CSS類包括並不限於：ambox、navbox、vertical-navbox、topicon、metadata、nomobile、collapsed、mw-collapsed、autocollapse（觸發時）。

翻譯自en:Special:PermaLink/991894520#Scrolling lists and collapsible content。-Mys_721tx（留言） 2020年12月2日 (三) 19:12 (UTC)

初步略看，僅有地區詞問題，反正目標頁有字詞轉換，可以(＋)支持。SAN MO SA _SPQR 2020年12月2日 (三) 23:22 (UTC)

順便也吐槽一下站內那些主要內容都完全被摺疊的年號列表，最近處理日本年號列表分拆的事情的時候，竟然還有人跳出來說大小上已經過長且嚴重濫用摺疊的中國年號列表是年號列表條目的典範，結果我分拆出來的列表都能夠FL。雖然摺疊在現時並沒有一個規範，但是一向的慣例都是不能夠摺疊得太多（最好沒有摺疊）。SAN MO SA _SPQR 2020年12月2日 (三) 23:42 (UTC)

曾經我有想過把中國年號列表分拆出來，但感覺沒什麼很詳細的資料可以加上。對，我離題了。—〚瑋瑋 · 嘎嘎 · 嘎嘎嘎〛 2020年12月3日 (四) 02:42 (UTC)

我覺得如果目標不是FL的話，直接分拆是沒問題的。SAN MO SA _SPQR 2020年12月3日 (四) 02:46 (UTC)

"內容"兩字重複太多了，應當修改一下。-Mys_721tx（留言） 2020年12月3日 (四) 00:15 (UTC)

我先稍代作調整。SAN MO SA _SPQR 2020年12月3日 (四) 05:45 (UTC)

"若干其他CSS類在人工加入條目或有模板引入時也會導致移動用戶無法訪問頁面"這一點用頁面不恰當。此處帶相關標籤的內容會被移動版伺服器移除，而非導致整個頁面不可見。-Mys_721tx（留言） 2020年12月3日 (四) 08:22 (UTC)

完成。SAN MO SA _SPQR 2020年12月3日 (四) 08:56 (UTC)

(＋)支持作指引，未見明顯不妥。collapsible那段拗口、不好懂，「除下列允許情況外collapsed、mw-collapsed、autocollapse狀態……」如何斷句。--YF dyh000（留言） 2020年12月4日 (五) 08:51 (UTC)

@YFdyh000：我再改一改。SAN MO SA _SPQR 2020年12月4日 (五) 09:54 (UTC)

@Sanmosa、YFdyh000：未見反對意見，11日應可開始公示。-Mys_721tx（留言） 2020年12月9日 (三) 16:14 (UTC)

我覺得不如直接把Wikipedia:隱藏元素列為指引。——BlackShadowG（留言） 2020年12月11日 (五) 10:02 (UTC)
@BlackShadowG：不可行，Wikipedia:隱藏元素本質上屬於論述，可能隱含個別用戶的個人意見。方針指引不應該隱含任何用戶的個人意見。如果你不反對的話，我仍然希望把上方一案進行公示。SAN MO SA _SPQR 2020年12月11日 (五) 13:19 (UTC)
- (＋)支持本提案，畢竟目前有相關問題的條目實在太多了。——BlackShadowG（留言） 2020年12月11日 (五) 16:20 (UTC)

開始公示。-Mys_721tx（留言） 2020年12月12日 (六) 03:18 (UTC)

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

[1] 使用地區詞處理至一致也算作一致

[2] 參見維基百科:格式手冊之第2節「時間、數字、度量衡」和7.14節「連接號」。

[3] 見每月底更新的頁面訪問量統計。該統計僅計算頁面點擊量；事實上大多數讀者在一定時間內使用過流動裝置訪問維基百科。

[4] 可將網址中的zh.wikipedia.org替換為zh.m.wikipedia.org後加載新網址訪問移動版頁面。在流動裝置上訪問桌面版頁面無助於評估移動頁面顯示問題，但可用於診斷平板電腦等設備上的親和力問題。

[5] 如上文所述，切換顯示或隱藏狀態需要CSS與JavaScript。即便設備支持上述功能，移動版伺服器會自動去除隱藏內容。Google於2016年在印度和印度尼西亞為低帶寬用戶提供精簡版頁面，該服務會去除導航框和隱藏內容。Google還計劃在其他國家地區提供該服務。 [1] [2]

[6] 導致此問題的CSS類包括並不限於：ambox、navbox、vertical-navbox、topicon、metadata、nomobile、collapsed、mw-collapsed、autocollapse（觸發時）。

[註 1]

[1]

[a]

[b]

[c]

[d]