维基百科讨论:格式手册/存档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]