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

頁面內容不支援其他語言。
維基百科，自由的百科全書

一個空格的問題

以下內容移動自互助客棧，新留言請置於框外。

參見：討論:Google Chrome和討論:諾頓360

這個問題已經困擾一段很長的時間，雖然對大多數維基人影響甚微，可惜參與相關編輯戰的維基人從頭至今沒有認真討論過，甚至達成共識，已經是為編輯戰而進行編輯戰，直到對方退出為止。此事件已經引致一名維基人退出，再這樣下去的話，中文維基就會因為一個空格而造成一個「笑柄」。

事件的起源是來自諾頓360，User:Mark85296341、User:Chunchun2345、User:Hkh222以及User:Πrate進行多次編輯戰，已出現WP:3RR的情況，之後編輯戰延伸至包括Google Chrome、Mozilla Firefox等條目，近日我向User:Mark85296341查詢，而他得出回應是：

我想找個那個存檔，但最終找不到。不做初一，就做十五，一是所有條目留空格，一是不留。在中文語境中，的確很矛盾，並沒有因為拉丁文字前後是否留空格，今次討論希望尋求共識，以免這種編輯戰再現。

我希望User:Mark85296341、User:Hkh222以及User:Πrate在得出任何共識前也不要去處理有關條目。

P.S.我看那些頁面的編輯歷史真的有點不舒服。--Flame 歡迎泡茶 2011年1月9日 (日) 14:41 (UTC)

  • 注意這個問題好久了，覺得達成共識不易。不如投票吧。要不然扔硬幣也行（笑話）。不過請大家以後別再進行編輯戰了，為這點小事不值得。要不然真成笑柄了。--蘋果派.留言 2011年1月9日 (日) 17:56 (UTC)
各位，我想大家要留意一個問題，是怎處理那些為了小事堅持己見的傢伙，由於維基的開放性，這類人一聚起來就一些很難想像會打編輯戰的地方，都會打起編輯戰。「心理輔導」，可能比社群共識更快解決問題。Martinoei (留言) 2011年1月9日 (日) 20:38 (UTC)
我的意見：一般情況下，如果條目名稱大部分是中文，只有一兩個英文詞，則不加空格，如2011年Oricon單曲週榜冠軍作品列表條目；如果條目名稱大部分是英文，只有一兩個中文詞，則需要加空格，如My Name Is 邦。但如果官方名稱有空格，則根據名從主人原則，條目名稱也必須有空格，如Google 日曆。--Symplectopedia (留言) 2011年1月9日 (日) 21:00 (UTC)
我的建議是，官方名稱是有空格，就無謂亂動廿四。如果官方名稱沒規定，有空格、沒空格都來個重定向不就解決問題。技術層面可以解決的問題，就用技術解決，讓雙方各自滿足好了。Martinoei (留言) 2011年1月9日 (日) 21:35 (UTC)
我認為中文環境中空格不是必須的，哪怕是中英混雜如google日曆加不加空格都沒有問題，我覺得只有英文間才需要空格，如google chorme。

百兔樂的意見很有先見性，即正文裡中文和外文中的空隙以手工空格的方式並不是十分妥當。而應採取如段前空兩格那樣用CSS來控制。

空格也是一個字符，有些環境裡空格會顯示成一個框框，很醜。--玖巧仔●□留言 2011年1月9日 (日) 22:39 (UTC)

第二個的重點是「Google Chrome」的前後應否留個空格？這是除了條目名稱探討，還要注意的問題，這個問題不解決的話，編輯戰仍然會來。--Flame 歡迎泡茶 2011年1月10日 (一) 00:18 (UTC)

用css來控制中英文之間的字間距有難度，但寫個js腳本應是完全可以的，但可能會影響（瀏覽器的）性能。--菲菇＠維基食用菌協會 2011年1月10日 (一) 02:59 (UTC)

第三個問題，在Wikipedia:格式手冊並沒有說明在字母後要否留空格。這點應否再加上？--Flame 歡迎泡茶 2011年1月10日 (一) 09:51 (UTC)

最新情況：已向Mark85296341留言，等待回應。--Flame 歡迎泡茶 2011年1月10日 (一) 15:56 (UTC)
  • 我也覺得很沒有意義，例如在Google Chrome一例子中，我認為百科全書的宗旨不是Google產生出來的東西、產物，也不是任何Google的主張用來發聲的管道，我覺得那些想加空格的人在要求Google提出相關證明前，應先要求自己是否能提出「世界上有任何一本具有高度權威性、國際性的英語辭典或文法大全裡有指出英文前撮或後撮東方語言的單體文字時，之間要加一個空格的『英文官方文法規定』」，否則只是本末倒置。
    還有，Google Chrome這裡意見這麼多，怎麼不見「Google地圖」、「Google地球」，還有所有其他的「Google產品」有意見呢？那些人要不要有人出來解釋一下？「要就全部統一」，要加就全部統一加空格然後移動，不過我想應該是沒有人要做這麼沒有意義、這麼累的事。－Berting Li (留言) 2011年1月12日 (三) 11:21 (UTC)
    (：)回應你能提出更有效的方法防止編輯戰嗎？所以你認為這次事件應該在Google Chrome的條目內討論嗎？--Flame 歡迎泡茶 2011年1月13日 (四) 15:35 (UTC)
(：)回應：總不能因應一些人的情緒波動而在此浪費時間吧。—Edouardlicn (留言) 2011年1月13日 (四) 15:50 (UTC)
  • (：)回應：OK的！絕對可以解決！我認為因為這並不只是單單只有Google Chrome的問題而已，而是空格的問題，因此有兩種有效的解決辦法，一是「等待表決結果出來並做為先例」，二是「新開一個投票」，如此一來，就能將此表決結果加入格式手冊，即能有效的解決問題。－Berting Li (留言) 2011年1月14日 (五) 05:27 (UTC)

(－)反對，我認為社區不應將時間浪費在所謂的空格和標點符號上。-Edouardlicn (留言) 2011年1月12日 (三) 16:26 (UTC)

(※)注意，討論條目事務，絕不是浪費時間。這些問題很有必要進行討論。118.21.205.229 (留言) 2011年1月13日 (四) 17:39 (UTC)
(：)回應，此事不是已經造成多次編級戰、移動戰、全保護和封禁了嗎？若不趕快解決豈不是要發生更多的編級戰、移動戰、全保護和封禁？－Berting Li (留言) 2011年1月14日 (五) 07:11 (UTC)

(！)意見，此件不妨以先者為準。惟條目名稱應顧慮美觀等。多數中文+英文的情況應是沒有空格，但也要依個案考慮，不宜統一處理。118.21.205.229 (留言) 2011年1月12日 (三) 17:00 (UTC)

(！)意見乾脆都寫成Google{{sep}}浏览器算了，到{{sep}}裡面編輯戰去，別弄得一堆內容全保護。Liangent (留言) 2011年1月14日 (五) 22:01 (UTC)
Liangent的提議不錯。--Symplectopedia (留言) 2011年1月14日 (五) 22:27 (UTC)
(！)意見乾脆這樣玩也好，但是共識一定要有，如果什麼也沒決定就不好了。--Flame 歡迎泡茶 2011年1月16日 (日) 05:09 (UTC)
Liangent的提議只會浪費更多的資源。--百楽兎 2011年1月19日 (三) 04:55 (UTC)
在名稱中間加空間應由決定，但我的主觀意見認為在前後都上空間是不正的事，例：「終於在1998年6月25日發行 Windows 98 。」

這絕對是不好的示範。--Flame 歡迎泡茶 2011年1月16日 (日) 06:37 (UTC)

其實只要英文詞之間留空就行了，中文與英文，英文與數字之間沒有空格也不影響閱讀，更不會出現歧義。這樣就夠了，維基講究實用，而不是好看。--玖巧仔●□留言 2011年1月17日 (一) 15:57 (UTC)
「3 D」「CS 5」這樣嗎？ --玖巧仔●□留言 2011年1月18日 (二) 16:10 (UTC)
(！)意見看來不能一概加入空格，不過可遵循英文習慣。--蘋果派.留言 2011年1月18日 (二) 22:01 (UTC)
(！)意見中文的語法應該沒有規定吧。似乎討論傾向是不留空格，至於外語之間的空格視乎命名規定，名從主人。--Flame 歡迎泡茶 2011年1月19日 (三) 03:18 (UTC)
我的(！)意見：堅決反對為了美化的目的加入空格，但原名有空格者依原名（名從主人）。--百楽兎 2011年1月19日 (三) 04:55 (UTC)
(！)意見：我只知道百樂兔你們幾個的所作所為，已經嚴重影響到我的編輯工作（要不要給你張我監視列表的截圖看看，小孩子過家家，很好玩是吧？）。目前不是這幾個條目，而是已經蔓延到全部有此類空格的所有條目。
或者，讓管理員做見證人，安排你們正反雙方當面決鬥好不好？誰贏了聽誰的。
要全維基的人跟著你們一起折騰，都什麼態度！

—我是火星の石榴 (留言) 2011年1月19日 (三) 07:29 (UTC)

(：)回應那人認為哪個維基人做法比較對？--Flame 歡迎泡茶 2011年1月19日 (三) 07:47 (UTC)
對現在我很失望的是Mark85296341至今仍然未參與討論，我很希望他能舉出「我認為是用在跟電腦、資訊和電玩有關的才需使用，很早之前就在互助客棧有提到關於空格的問題，可是那存檔我已經找不到了。」證據，在討論結束，將結果加進Wikipedia:格式手冊內。--Flame 歡迎泡茶 2011年1月19日 (三) 07:46 (UTC)

能否這樣？

在Word中，中英混排是不需要敲空格的，系統會自動調整間隙。我們的瀏覽器沒有這個功能，可是如果使用Thin space（U+2009），可以達到相同的效果。理論上，在Unicode 5.0中，its width may get adjusted in typesetting；在實踐上，看效果：「Google 瀏覽器」、「Google 瀏覽器」、「Google 瀏覽器」、「Google 瀏覽器」。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月19日 (三) 08:47 (UTC)

囧rz……我「提出一個不好的方法」，然後怎麼就「易辦了」？——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月19日 (三) 09:38 (UTC)
這是因為在網頁中加半角空格很不美觀，而且中英文混排需要的不是空格，而是間隙（就像Word等軟體排版一樣）。如無間隙，看：「Google瀏覽器」、「ABCDH中文」，文字會交疊。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月19日 (三) 09:42 (UTC)
看到現在只有虞海知道癥結。--百楽兎 2011年1月19日 (三) 09:59 (UTC)
有空格又如何？沒空格又如何？我們的目的既不是給每個頁面加個空格，也不是讓每個頁面都沒有空格。我們需要只是讓頁面的排版正常、能看，其實現方法是加空格，或thin space。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月19日 (三) 15:55 (UTC)
(！)意見：請問百樂兔？慣例來自何處？我怎麼這些年沒怎麼聽說過？(或者說，我聽說的和你的意見完全對立，大家新人的時候基本都是由老人帶的，現在我們大多開始可以指導一下新人怎麼編輯，難道我最開始被人教錯了？)，再請問，目前是哪邊人多？少數服從多數，再公平正常不過。
(！)意見：我要求很簡單：
  • 停止這種無謂的事情，我只想安安靜靜的編輯，我不想每隔一陣子監視列表一團亂！你們也不算算，在這上面浪費了多少時間精力口水？值得？為了區區一空格！每天都有堆積如山的東西要等待填坑，要去更新、維護。把精力花在日常事務上能做多少事情了？

百樂兔你讓他們一步又怎麼了？為什麼非得別人讓你？這有道理？道理在哪裡？你當面在下面答覆我，我等著看，不行你來我對話頁。我怎麼看也是他們那邊人多，你自己才是少數。你自己看看編輯歷史去，哪有第二人比你更積極的？我監視列表很清楚，是你先開始的。條目從建立開始就是有空格的，到底是誰有問題？

所以我即使不贊成你的觀點，我也懶得來參與這種無謂的事情，我小部分源碼問題都向IP用戶讓步了，區區一個空格沒什麼不可以讓步的。

本人現在現實主義者，要是我監視列表沒反應，沒人通知我什麼的，討論根本我來也不會來。

雙方都認為自己是真理，卻說不出理來自何處，完全不知所謂！

虞海的意見，我也贊成如果能形成共識最好，能完美的解決問題。但現實告訴我，以我的技術認知，這種解決方法在目前的技術上怕是行不通吧(即「有沒有依照瀏覽器加入空格的辦法」)？所以解決辦法只能是，人為手工加空格，讓頁面的排版正常、能看，兼顧美觀。

沒空格會怎樣想過麼？我以前遇到過，有人看著沒空格的標題，認知產生了歧義(在此不討論無關的個人智商問題)。—我是火星の石榴 (留言) 2011年1月20日 (四) 07:39 (UTC)

我不知從何說起好。首先在Google Chrome的條目上，並非所有由百樂兔多次強行刪除的空格我都協助加回，我只是加回繁體中文版本，即「Google 瀏覽器」內的空格，此條目的問就源於此。就如Red16所說的，在Google Chrome的條目一開始就已經有空格，而且官方所有的說明文件及服務條款都有空格，部份文件甚至使用引號標示[1]（英文版本[2]以及簡體中文版本[3]一律沒有引號），對此我的解讀就是繁體中文版本的Google Chrome是有空格的。另外百樂兔在上面所說的慣例我不知從何來的，隨後他亦沒有加以說明。

除此之外，我個人認為可以看看百樂兔的「戰績」，他根本是在合理化自己的行為，先舉部份例子（因為實在太多例子，只能舉出部份），大家在修訂歷史可以得知，例如我在「My Name Is 邦」[4]、「上海闖蕩」[5]、「保良局顏寶鈴書院」[6]作出貢獻後，他隨即進行沒有建設性的回退，大部份條目甚至是他從未編輯過，例如「上海闖蕩」、「保良局顏寶鈴書院」，可見他是針對本人所作出的貢獻作回退破壞。可笑的是在我進行反破壞行動中竟然被3RR封禁，而且我是在沒有任何警告、沒有任何前科的情況下被封禁，與此同時百樂兔這位前科數不盡的破壞者只是跟我這位被無理封禁的初犯者得到「封禁兩周」，另外我作出的封禁申訴完全被管理員無視，請問前輩道理在那？

另外就百樂兔其中一個意見作出一些回應，首先甚麼叫「純粹是為了反對我而反對」？你自己是不是純粹為了回退而回退本人所作出的貢獻呢？第二，「然而他們卻選擇性忽視，咬定空格的必要性，兼又發動車輪戰、傀儡戰。」，是誰發動的？我嗎？無視管理員多次的3RR封禁，你才是獨行的發動者，而且並非單一條目上，請問你有甚麼資格說人呢？第三，「請勿擅加空格」，原本是有空格然後你強行刪除，是你擅自刪除，而非我們擅加空格。

好吧口水就已經浪費完，就看看大家的看法。--HKH 2011年1月20日 (四) 18:45 (UTC)

您確定百樂兔是「沒有建設性的回退」嗎？至少我看不出。這個編輯把「| 頻道 = 無線電視J2」改成了「| 電視網 = J2 | 電視臺 = 無綫電視」，有什麼不可以？還有這個編輯，有何不妥？如果不妥的話，您應該說明為什麼不妥，這樣大家才能知道。不然的話，只能當作編輯戰來處理，就是把參與編輯戰的所有人都封禁一定的時間。--Symplectopedia (留言) 2011年1月20日 (四) 19:23 (UTC)
(：)回應把「| 頻道 = 無線電視J2」改成了「| 電視網 = J2 | 電視臺 = 無綫電視」模版是不會顯示「無綫電視」的。此外大部無綫電視J2的節目都是顯示「無線電視J2」，並且使用J2模版。另外，不只是單一條目出現「沒有建設性的回退」，只要看看他的「用戶貢獻」，例如在2010年12月10、29日連環直接刪除我的編輯，並且刪除他不喜歡的空格，刪除他不喜歡的空格不是一個大問題，但他明顯地針對我的貢獻作回退行為。同時他的「用戶貢獻」在2010年12月29日亦證明是他先發動編輯戰。關於這個編輯我應該反問我刪除(+852)及沒有連結的人名的「[[]]」有何不妥，而且這個編輯跟上述原因一樣「連環直接刪除我的貢獻」。--HKH 2011年1月20日 (四) 20:43 (UTC)
(：)回應我想反問你哪些條目需要空格，哪些條目不需要空格，如空中巴士A380（Airbus A380），根據你的邏輯應否改為空中巴士 A380呢？我想各位研究一下，事實英語等外語是需要，但以以上例子在中文是不是有必要呢？正如在排版本會不會變得不美觀？--Flame 歡迎泡茶 2011年1月21日 (五) 00:56 (UTC)
(！)意見：我澄清一點，我說的是我們這邊自己的條目，不是HKH說的google chrome，這和我是否google fans無關，誰都知道，我在維基甚少參與IT類條目的編輯。
(！)意見：另外，替人回答HKH，百樂兔和你的區別，就是他曾經長期是維基的資深管理員，後來是他自己辭了還是怎麼樣，我是忘了，反正管理員那邊應該有記錄。這是事實。至於是否有人會解讀為管理員群偏幫私，我管不了。
重申一遍：我這次過來就是因為有關人員的行為已經長期干擾到我的編輯(我個人喜好整潔，不想自己監視列表裡面亂七八糟的)，平時的話，我一般是不過來的(你們可以看看，這次之前我上次來方針區還是什麼時候了)。為了一點又不是涉及原則立場等根本性的東西，花上大把時間精力和口水，到最後又會不了了之，煩了。效率不說，根本不值得。我現在在維基只想安安靜靜的編輯，其他事我不想管。換句話說，只要不干擾到我自己編輯，其他事我沒什麼意見。—我是火星の石榴 (留言) 2011年1月21日 (五) 07:54 (UTC)
(！)意見：我沒當過中文維基百科的管理員也不想當中文維基百科管理員。會不會知道是慣例從你這個發言就看得出來。你的監視列表如何如何都不干我或任何其他人的事，我或任何其他人編輯的時候也不會去考慮你的監視列表變得怎麼樣，沒有人有義務在編輯時還要顧慮維持你監視列表的整潔。你的要求去英語維基百科去喊喊看，看看會不會被當成一則天外奇譚。勸你不要像ACG腦一樣，浸淫ACG久了就ACG腦化了。--百楽兎 2011年1月21日 (五) 10:04 (UTC)
(！)意見：我不知道某日當有人登陸自己帳戶，點開監視列表一看，有將近200條同類型的移動日誌，然後第二天發現同類型日誌又再200條，只不過是另外一人給移回去了。如此之事，反覆將近10次，不知道各位有何感想？我歡迎管理員將監視列表上限提升到1萬，這樣短期內估計不會有不夠用的情況出現。—我是火星の石榴 (留言) 2011年1月21日 (五) 11:58 (UTC)
(！)意見：顯然你說的事不是我做的。既然我沒做過你說的那種事就別算在我頭上。--百楽兎 2011年1月21日 (五) 14:29 (UTC)
(※)注意如發現某維基人刻意破壞的話，請到WP:VIP申報，就各位維基人繼續就此事作出討論。另外HKH也不要對此無直接關係的事作出討論，以免影響討論環境。--Flame 歡迎泡茶 2011年1月21日 (五) 08:03 (UTC)

整理一下

其實我是支持加空格的。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月22日 (六) 18:59 (UTC)

(！)意見：個人建議百樂兔儘快通過申請CU來CU你自己的帳號，以此證明此帳號沒有被人盜用來做出以上行為，錯怪好人就不好了是吧。

所謂移動戰，一個人當然是玩不起來的，沒人會移回來又移回去，自己玩自己嗎？問題的焦點在於：到底是誰先開始的？你仍然堅持不是你先開始而是對方嗎？

事情的前因後果事關重大，怎能不搞清楚？監視列表大家通用，隨便去後台調取數據好了。

事實1：這次的事情，純粹就因為有人因為一個空格爭執不下，結果引發了斷斷續續持續一年多的移動戰，還引發了雙方各自3RR封禁等，是誰一開始發動了移動戰當然很重要。

事實2：很多條目自創建始，就是帶空格的，這點可以調最早的頁面編輯歷史記錄來看，現在早已超出了Google Chrome或者norton 360的範圍，擴散到全維基所有帶空格的條目。

事實3：空格問題，論官方的話，比如微軟、空客，從來沒有也不會有人出來說，我們公司的產品名稱在中文中要帶空格還是不帶空格，帶空格就是錯，不帶空格就是對，是真理。

所以，上面拿個A380出來，又能徹底證明什麼呢？大不了最多證明空客而已，能證明其他公司的其他產品？被代表？

一般人誰會去注意這種細枝末節的事情，更遑論有一群人為此爭論了一年多。傳出去真是笑柄。

所以，我說過，我不會參與這種移動戰。有人要我讓他，沒大問題的話就讓了吧，又不是技術上解決不了，所以，如果最後的結果是沒空格而虞海的方法在技術上行得通的話，我也沒什麼意見，可以接受。

事情根本從一開始就是錯的，開始的時候，雙方無論誰讓了一步，這事情根本都沒了，哪有現在？

問題：為什麼百樂兔你不能讓一步，非得別人讓你不成？ 你不解釋的話，這問題根本說不通。人家至少還說得出，條目開始就那樣，有歷史可以查嘛。

那個慣例，我也沒聽說過，誰來科普下？

我火什麼？好不容易安靜了幾個月，現在想來是百樂兔你被封禁了而已（如果最後只能用封禁解決問題實在是杯具徹底），你大概什麼時候解禁我也有數，我曾經看過日誌。結果呢？果然不出所料，又給全部移回去了（就幾天前的事，賴什麼，往哪兒賴？），這第幾次了？我都數不清了。當這裡是什麼？私人領地？自家後花園？自己地盤高興怎麼玩怎麼玩去，這裡還有一堆人，有哪個在動手編輯之前想過其他人了？你是在反破壞嗎？多了個空格就是破壞嗎？

綜上：

(！)意見：這次要說就說說清楚，一次性解決問題，要討論多久時間不是問題。事情都有前因後果的，前因後果無關？忽視著前因後果來討論嗎？第二，「目前意見傾向於不留空格」，不認同，討論不夠充分徹底，這裡真正參與討論的才幾個人？當事人都還沒到齊呢。第三，即使得出結論，怕也只能作為一個編輯指引而已，只能建議，這又不是GFDL，強制性的，日後，多了個空格能當封禁人的理由麼？

個人意見，傾向於最初的原始版本，即最初的版本是有空格的，那就是有空格的。最初沒有就沒有，一切恢復到事情開始之前。

虞海的意見，我感覺技術上行不通。要做先把N個瀏覽器一個個測試下來，想出解決方案再說，別忘了，還有手機瀏覽器呢，各個版本之間的不同之複雜性，比桌面瀏覽器麻煩N倍。有人要做，慢慢測試吧，出來個新版本就得全部推倒重來一次，平均大概一個月要做一次測試。

註：以上有一點例外，就是有人拿著正式的官方說明文件來，裡面清楚說明是要還是不要空格，名從主人嘛。這估計誰也沒意見了吧？那也只是個案，個案按個案一個個處理。—我是火星の石榴 (留言) 2011年1月21日 (五) 18:35 (UTC)

  • (：)回應我以前打趣地說，如果一早向Google公司查詢的話，所有問題都可以迎刃而解。只是有人會去查詢，而他們會否答覆這個問題。不如這樣，舉行投票吧。決定在一般情況下「應否使用空格」？--Flame 歡迎泡茶 2011年1月22日 (六) 00:53 (UTC)
(！)意見：百樂兔說慣例，你來維基多少年了？移動戰始於2010年，之前這些年你在幹嗎？你不知道以前就有這個情況(指空格)？而慣例當然也不是2010年才形成的。才形成的東西能稱為慣例嗎？
我以為，當事人的一方，始終逃避問題，絕對不是解決問題的方法，你站出來以理服人啊。
知道我第一次看到移動戰是什麼感覺？我第一反應是被盜號，這ID後面的主人換人了。
ID後面的主人是否換人了大家管不著，在網上大家都只認ID，誰犯規，誰出局。
虞海的那個方法，其實真行不通，太難了。手機/手持設備的瀏覽器啊，比如吧，UC升了7.5，結果(指某新興門戶，alexa排名500以內)，普通屏，老的7.2看倒正常，7.5反而不正常。觸控螢幕設備上全部倒過來了(最近正為此問題頭痛)。怎麼辦？告訴用戶是你的設備問題，強制人換設備嗎？你認為別人是會花幾千去更換設備，還是乾脆說一句，「我看不了你這個網站，我不來總行了吧？又不是吃飯，不吃飯是會死人的，不看你這個網站會死人嗎？」哪個可能性更大呢？
剛才蘋果派也來問我有關投票的意見，無非嘛
1.全面禁止空格，有空格是錯的。（百樂兔）
2.禁止空格是錯的，有空格才是對的。
3.恢復到第一次移動戰之前的樣子，恢復原狀，是否使用空格自由控制，但可做一個編輯指引，指維基慣例（附條件1：要提慣例，先把慣例原文找出來再說，否則免談）是不使用空格的，是否遵守此慣例，由各人自由把握。
任何人皆尊重最初編輯者的最初原始版本，不得再次發動類似的移動戰，如有違反就不說了。
我所說的最初原始版本，是指當前條目內容具有可讀性，也就是當前條目內容的主框架大致形成，內容基本穩定，不會產生劇烈波動變化（尤其是大段內容的清空刪除）的那一天開始算起。
條目內容能基本穩定，即代表參與當前條目內容的編輯者們內部本身形成了一個默契，當前條目內容本身，並無大問題。
日常的編輯中，自然也包括對空格和標點符號等的使用。
比如我和很多人寫條目，都是一天內寫好，然後名稱移動到位，重定向建立完成什麼的，全部是一次性完成，加上本身就是條目的初創者，這樣從第二天就可以開始算起了。但也還有例外情況。
一個條目立起來4-5年了，某一天突然跑來一個此前既沒參與編輯，更加連關注都沒關注過這個條目的這樣一個人，一跑來就直接發動這種移動戰，當然應該直接禁止。
連一個空格都容不下，還是海納百川、有容乃大的維基百科嗎？
坐等圍觀格式手冊中出現這麼一條：維基百科禁止空格，違者封禁！

—我是火星の石榴 (留言) 2011年1月22日 (六) 06:32 (UTC)

  • 現在也是舉辦投票的成熟時機了，我們應該要談及在哪些時候加開空格。第一，為條目美觀，隨時都可以加空格。第二，只在特定條目（如電玩、資訊科技）等加上空格，第三是在得到官方許可下才加上空格。--Flame 歡迎泡茶 2011年1月23日 (日) 01:42 (UTC)

一個空格的問題（續）

以下內容移動自互助客棧，新留言請置於框外。

投票暫定區

注意：此部份仍中文與外語之間應否留有空格？投票方案仍在擬定，仍未開始。--Flame 歡迎泡茶 2011年1月23日 (日) 06:53 (UTC)

方案一：隨時都可以加空格。
方案二：只在特定條目加上空格，需到該頁面討論頁進行表決（如：Talk:Google Chrome）
方案三：除非得到官方認可，否則不能加上空格。
方案四：在任何情況下不得加上空格

—以上未簽名的留言由Flamelai（對話｜貢獻）加入。

暈死……——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月23日 (日) 11:51 (UTC)
方案5：使用thin space並設立開關，自動將thin space替換為nothing/thin space(保持不變)/空格/nbsp。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月23日 (日) 11
58 (UTC)
(！)意見：對方案5，已上述，如何保證在技術上實現任意版本瀏覽器通用，而保證不會出現挑版本挑瀏覽器的問題？有點技術經驗都知道，這種兼容性測試最困難(基本上也沒人能保證肯定不會出現兼容性問題)（—以上未簽名的留言由Red16（對話｜貢獻）於2011年1月23日 (日) 12:54 (UTC)加入。）
(：)回應：對方案5，肯定要調試一段時間，等系統穩定下來以後，就可以製作機器人了。（一邊英文字母，一邊漢字這種情況對機器人來說可就是小菜一碟）。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月23日 (日) 14:18 (UTC)
(！)意見不是所有瀏覽器支援，這需要維基人申報。--Flame 歡迎泡茶 2011年1月24日 (一) 08:58 (UTC)
方案6：以條目內容成型的最初原始版本為準，尊重最初原始版本的編輯者的選擇（是否使用空格）。詳細見上述。—我是火星の石榴 (留言) 2011年1月23日 (日) 12
54 (UTC)
對方案六，那會造成維基內部的格式不統一。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月23日 (日) 14:18 (UTC)
(！)意見這造成日後創建先到先得的惡果，在對此原先創建的條目影響輕微。--Flame 歡迎泡茶 2011年1月24日 (一) 08:58 (UTC)
(！)意見：請問對於一個空格的先到先得，會存在什麼惡果？，一時我還真沒想到。—我是火星の石榴 (留言) 2011年1月24日 (一) 11:52 (UTC)
方案7：對於每一個有爭議的名詞，分別建立投票，加或者不加，55決。在投票之後，按照投票結果執行，且3個月內不得重新再開投票。--蘋果派.留言 2011年1月23日 (日) 16
43 (UTC)
此為最會開玩笑的方案，3個月後投票不就等於作廢？—Edouardlicn (留言) 2011年1月23日 (日) 17:01 (UTC)
3月後投票也不會作廢，不過允許再發起投票推翻之。方針尚允許推翻，這個不應該不允許推翻啊。在未被推翻之前，仍然有效。--蘋果派.留言 2011年1月23日 (日) 18:55 (UTC)
(！)意見：你這不現實啊，這樣我們不是整天忙於投票決定(附加還有辯論 耗時啊)？我們還干別的不？—我是火星の石榴 (留言) 2011年1月24日 (一) 11:52 (UTC)
(！)意見看似頗難執行，但是亦無道理，個別條目應有個別討論解決。--Flame 歡迎泡茶 2011年1月24日 (一) 08:58 (UTC)

(：)回應：根據以往經驗，只要Flame出手的爭議，結果大都很悲慘；這回又是一例。建議Flame熱心調停前，先摸清來龍去脈，不要每次事情規劃階段熱哄哄，草率的開場，然後弄到一半後，虎頭蛇尾，就等著有人幫你收拾殘局。--Winertai (留言) 2011年1月24日 (一) 02:17 (UTC)

(：)回應不用你擔心了，今次會徹底去到完場為止。現在投票還沒開始，別那麼快下定論。--Flame 歡迎泡茶 2011年1月24日 (一) 02:27 (UTC)
(：)回應我記著您這句承諾。不過，提醒您：這次問題牽涉到「慣例」，「移動自由度」，「如何認定條目真正名稱」，「一致性」，「符合慣例及方針的合法移動及編輯是否涉及擾亂維基」等等難解問題；您在規劃投票前，請先預設到當投票結果「不符合現有命名規則」，「不符合慣例」，「適用範圍」及投票選項過多時等等怎麼處理的問題。--Winertai (留言) 2011年1月24日 (一) 02:39 (UTC)
(！)意見還有沒有人提及更多方案？各位可以在1月25日23:59(UTC)提出你的意見。--Flame 歡迎泡茶 2011年1月24日 (一) 08:58 (UTC)
  • 強烈(－)反對：天啊，那得投多少票啊？１＋２＋３＋４＋５＋６＋…——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月24日 (一) 09:35 (UTC)
  • (：)回應不過你認真看到我的意見的話，其中一兩個選項會被拔掉，所以應該選項最多只維持四個左右。--Flame 歡迎泡茶 2011年1月24日 (一) 15:29 (UTC)
    況且我們在這裡討論的目的就是讓以後存在嚴重爭議的條目越少越好：大多數條目受一個大家都同意的指引控制，只有個別幾個情況特殊到指引起不了作用的條目才做單獨的「討論－投票」解決。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月24日 (一) 09:38 (UTC)

(！)意見--建議可改為兩大方案如下，但不知技術上是否可行：

  1. 編輯時不加空格，顯示時系統自動加上間隔（如thin space）（官方回覆明確表示要加除外）
  2. 編輯時必須加空格（官方回覆明確表示不加者，系統自動加上間隔（如thin space））

--Gakmo (留言) 2011年1月24日 (一) 10:56 (UTC)

(！)意見：這不就是方案5的簡化版嘛，我認為技術上不可行，瀏覽器版本的複雜性，由此帶來的天文數字般的兼容性問題。我還是那句，你不能告訴別人這是設備兼容性問題(很多手持設備瀏覽器是固化的，即使可以換，動手換瀏覽器需要一定的技術能力，不是windows那種一路next可以解決的，很多人只會用，折騰軟體這等於要人老命了)，你要人家換設備，人家可以不來看總行了吧？—我是火星の石榴 (留言) 2011年1月24日 (一) 11:52 (UTC)
(＊)提醒：不要把一切重擔都給都瀏覽器，很多任務服務器是可以承擔的。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月24日 (一) 18:52 (UTC)
(！)意見：不是一切在伺服器端都能解決的，比如你在伺服器端布置到位，正常了，也要瀏覽器能支持並且正常顯示才行。CSS、腳本這一切都需要由瀏覽器來執行，而不是讓伺服器來執行。代碼錯一行，瀏覽器就有可能卡爆了，所以瀏覽器才是真正的關鍵。—我是火星の石榴 (留言) 2011年1月25日 (二) 09:55 (UTC)
  • (！)意見再整理剩下來比較合方案（主要整合部份維基人的意見），過兩天可以開始投票了，規則是哪一方案超過50%，就可以通過，如第一輪投票沒有一個方案超過50%的話，就進行第二輪投票，結束後有方針加在Wikipedia:格式手冊上。
方案一：除非得到官方認可，否則不能加上空格，顯示時系統自動加上間隔（如thin space）。
方案二：以條目內容成型的最初原始版本為準，尊重最初原始版本的編輯者的選擇（是否使用空格）。
方案三：對於每一個有爭議的名詞，分別建立投票，加或者不加，以55表決。

--Flame 歡迎泡茶 2011年1月26日 (三) 02:38 (UTC)

    • 謝謝整理。方案一者，建議將「官方認可」改為如「根據官方回覆」等較明確字眼，否則「何謂官方認可？」可能引起爭論。不過根本問題是技術是否可行。方案二者，若那版本第一段有用空格，第二段沒有用空格，應根據哪一個。方案三則似乎不及確立原則來得徹底。歡迎討論。--Gakmo (留言) 2011年1月26日 (三) 03:01 (UTC)

投票區

注意：投票仍未開始。
投票時間：2月10日0:00 至 3月10日23:59（UTC）（暫定）
投票方式：每人可投一票，不設反對票，如沒有一個方案超過半數將進行第二輪投票，在這個時間最少得票的方案將會剔除。重覆投票均視為無效。可以在投票簡要地說明意見，過長句子將會被移動至意見區。（暫定）
方案一：除非得到官方認可，否則不能加上空格，顯示時系統自動加上間隔（如thin space）。（暫定）
方案二：以出現添加空格或刪除空格的第一次移動前為準，尊重最初原始版本的編輯者的選擇（是否使用空格）。（暫定）
方案三：對於每一個有爭議的名詞，分別建立投票，加或者不加，以55表決（例）。（暫定）

意見

以下與討論議題無關之意見移至他處討論--Winertai (留言) 2011年1月26日 (三) 01:14 (UTC)

(：)回應：我只要求「顯示時系統自動加上間隔（如thin space）」這兼容性測試誰去做？如何保證在每個版本的瀏覽器上都顯示正常？你不能迴避問題啊，也不能等每次有問題再改再測試，這樣以後很麻煩的。我個人是不覺得方案2有什麼問題，同一個系列的東西，一般是同一個人開條目的機率很大，自然也會把個人的編輯習慣帶入到新條目中，再說，本來有點小問題可以私下協調的（其實這次也是 可惜有人自己放棄了這個機會，非得鬧大不可）—我是火星の石榴 (留言) 2011年1月26日 (三) 09:41 (UTC)
(：)回應：（見下面）
儘管理論上我更贊同方案1，但技術實現上我還是要提出一個
修正方案：除非得到官方認可，否則不能加上普通半角空格；由機器人自動添加thin space；顯示時，通過類似於簡繁轉換系統的小工具（Gadget）將thin space去掉。
這在技術上對瀏覽器沒有任何要求。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月26日 (三) 17:08 (UTC)
(～)補充：在源碼中置入thin space，不代表原文中有thin space。源碼中的thin space，與「-{」、「}-」一樣，只是一個開關。另外：源碼
  1. 「 」或「 」代表一個空格開關，顯示時依用戶選擇變為「」、「 」或「 」。
  2. 「 」代表一個真正存在的窄空格。
——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月27日 (四) 09:53 (UTC)
怎麼又投票？最近怎麼總是討論的挺好的情況下，突然就要開始投票了，尋求共識不好嗎？--百無一用是書生 (☎) 2011年1月27日 (四) 07:16 (UTC)
  • (－)反對，我也反對如此快速的進入投票，「投票不能代替討論，投票是不得已的最終手段」，這裡實際參與討論的人這麼少，應再尋求社群共識。（個人建議：至少等到2月中旬，如無共識再尋求「最終手段」）－Berting Li (留言) 2011年1月27日 (四) 10:50 (UTC)
  • (：)回應Shizhao和Berting Li：沒有辦法，中文維基里只要有人質疑「共識是否真的達成了？」就會帶來投票。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月27日 (四) 12:10 (UTC)
  • (：)回應，我的意思是說「1月28日」（今天）就開始投票實在是言之過早！本討論都還未屆滿一個月呢！至少要等到屆滿吧！個人建議至少能讓社群充分討論到2月10日～2月中旬，還有，投票期限只有一個禮拜？Google Chrome#投票投了快一個月才只有3票；而下面的條目聲明投票投了快10天才只有2票，如此重大的社群爭議只需要一個禮拜就能累積到足夠令社群信服的票數嗎？（而且還遇上「返鄉過年」），目前的投票時間、期限、方式與項目之後應標明「（暫定）」，並不是每個人都同意這幾點。－Berting Li (留言) 2011年1月27日 (四) 16:47 (UTC)


Re虞海，我只能說，希望如此(沒經過測試的事我不敢說)。
另外，要求確認投票門檻，萬一只來10人參加投票 6:4通過 怎麼辦？最多只是這10人之間的共識，能代表全維基的所有人？過幾個月再來？
國外公投都說，投票人數少於登記選民的5成，結果作廢。
對應到維基，應該算活躍用戶中有多少人參與投票，必須達到一點的門檻比例—我是火星の石榴 (留言) 2011年1月27日 (四) 10:32 (UTC)
(：)回應「投票人數少於登記選民的5成」：
  1. 不管怎麼說，維基不是民主試驗場的共識我們還是有的
  2. 投票中有一個問題是永遠避免不了的——給權不要——你永遠拿他們沒轍，never。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月27日 (四) 12:10 (UTC)

個案回饋

下一段落內文，是我針對諾頓 360要不要加空格的歷史發言紀錄，後來某位當事者說這現象代表「空格不代表名字一部分」；請大家撥冗看下面文字，再依各位看法，要不要加空格？另外，我是在想，可不可當有爭議時，全部按照建立條目者之所在地區的「產品封面所示名稱」來區別要不要加空格，並由三位以上管理員取得共識，來決定空格要不要加，並以「避免浪費資源」為由來定案不准移動，這樣不知可不可行？我看到上面那些密密麻麻投票方案，頭痛了。--Winertai (留言) 2011年1月27日 (四) 14:19 (UTC)

賽門鐵克網站：產品名稱本身、網頁標題（...Symantec.com > 諾頓 > 產品訊息 >諾頓 360 4.0 版本）有空格，但是網頁右邊的產品敘述內容（...毒防駭, 防被詐騙, 防電腦慢, 防護資料

——諾頓360），卻又沒有空格。以前不知道有沒有類似例子，該採用產品封面的名字，還是說明內文敘述上的？--Winertai (留言) 2010年9月17日 (五) 00:17 (UTC)
維基百科條目的內容不應該交由某幾個管理員來決定，即使整個社群也不能決定維基百科的內容（極端的情況，如果社群絕大多數人都認為進化論是錯的，難道就要在條目中說這個理論完全錯誤？）。具體到這個空格問題，個人認為應該個案處理。如果非要有一個全面性的方案，那我覺得可以規定除非除非使用空格有特別意義，那麼一般情況下不需要使用空格--百無一用是書生 (☎) 2011年1月28日 (五) 07:43 (UTC)
方案2改成「以出現添加空格或刪除空格的第一次移動前為準」比較好。如果真的出現為了空格而搶建條目的情況也沒什麼不好，只是那幾個人自己累而已。--達師 － 198 － 336 2011年1月28日 (五) 08:10 (UTC)
(：)回應：同意達師，請Flame協助修改。
書生，這其實是排版的問題。
一個門檻票數對任何一個投票都是用，這樣吧，最多事情完了另發起討論。維基不是民主試驗場，但原理是一樣的，就比如管理員任免投票，只出來10人參與投票的話，同樣不能代表大部分人的意見。—我是火星の石榴 (留言) 2011年1月28日 (五) 13:05 (UTC)

方案6為什麼不進入投票？？

以條目內容成型的最初原始版本為準，尊重最初原始版本的編輯者的選擇（是否使用空格）。我覺得這樣很好啊。—Edouardlicn (留言) 2011年1月30日 (日) 03:21 (UTC)

(：)回應：整理過了，即正式方案二。—我是火星の石榴 (留言) 2011年1月30日 (日) 10:40 (UTC)
(：)回應與方案二合併。--Flame 歡迎泡茶 2011年1月31日 (一) 15:13 (UTC)

隨便說點問題

  • 由於wikitext的複雜性，在源碼裡面機器人準確地加減空格不是那麼簡單的，除非用了特殊占位符標記（如上面的thin space和我說的{{sep}}）：考慮這個情況，源碼裡面寫了{{someTemplate|english中文}}，這個中間要不要有空格呢？如果不加，someTemplate可能把參數直接顯示；如果加了，someTemplate可能把參數當模板名調用另一個模板。
  • 放棄舊設備兼容性的事維基已經幹過了，見wikitech:Mobile#Supported Platforms/Languages。
    --Liangent (留言) 2011年1月31日 (一) 17:35 (UTC)
(！)意見：之前沒注意，那可以按一般人的想法估一下，是會就此去更換設備適應維基的人多還是就此放棄維基的人多呢？畢竟這些東西的價錢都很那啥，普及率還遠沒到人手一部—我是火星の石榴 (留言) 2011年2月1日 (二) 14:32 (UTC)
(！)意見：長篇才是維基主流吧？機器人不行的話還是只能人工手動，豈不是又回到原點了？—我是火星の石榴 (留言) 2011年2月1日 (二) 13:16 (UTC)

——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月3日 (四) 15:20 (UTC)

新的提案

  • 以英文命名的條目：按照英文維基或官方的命名
  • 以中文命名的條目：除非官方命名有空格，否則一律禁止使用空格
(！)意見：要是官方命名有空格，維基百科也加上空格了，但卻有人發現官方也並不統一，有時有空格，有時無空格怎麼辦？--Atry (留言) 2011年3月3日 (四) 05:36 (UTC)
  • 外語譯中的條目（例：諾頓360）：除非有特別理由（系列作品等），禁止使用空格
  • 系列作品的條目（例：牧場物語 雙子之村）：可以使用空格

小希～＊ (留言) 2011年2月3日 (四) 13:07 (UTC)

建議使用間隔號，如《牧場物語·雙子之村》。--Isnow (留言) 2011年2月4日 (五) 16:58 (UTC)
間隔號在日文語境裡用的更多，但是在中文語境裡是不是應當限定僅用於系列作品？--Mys 721tx(留言)-U18協會 2011年2月4日 (五) 17:24 (UTC)
好問題。但應該僅限於作品。有則有，無則無。沒有或使用其他標點符號者應盡量維持，除非所翻譯的作品與原名有極大差異。--Flame 歡迎泡茶 2011年2月5日 (六) 07:56 (UTC)
系列遊戲的子標題個人傾向於冒號。--達師 － 198 － 336 2011年2月5日 (六) 14:48 (UTC)
用冒號會不會犯了原創研究？不過這可能是日語習慣不會在副題前用上「冒號」，所以這方面習慣應該可以研究，這包括了電影、遊戲等。--Flame 歡迎泡茶 2011年2月8日 (二) 01:31 (UTC)

PhiLiP CSS OverflowHidden 方案

試試看：中文 English，討厭看到空格的請在小工具里啟用用戶界面工具->取消漢字和拉丁字母之間的間距。--菲菇＠維基食用菌協會 2011年2月6日 (日) 07:51 (UTC)

(※)注意：菲菇用的{{sep}}是nbsp，而非thinsp。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月6日 (日) 07:55 (UTC)
那個 是用來避免MediaWiki使用的tidy把空的HTML entities給刪掉而加上的，你看到的間隙不是它產生的：因為css里直接把width和max-width全部設成了0px，而由margin（外邊距）來產生你所看見的間隙，見[7]。--菲菇＠維基食用菌協會 2011年2月6日 (日) 07:59 (UTC)
試試看把這一段加到Special:mypage/vector.css去，這樣你看到的間隙更開：
.template-sep {
    margin: 0 1em !important;
}
以上。--菲菇＠維基食用菌協會 2011年2月6日 (日) 08:11 (UTC)
這倒是個不錯的法子（雖然現在過寬了一點），缺點是{{sep}}無法用在標題里。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月6日 (日) 08:15 (UTC)
此外還有問題：在Opera里確實只有間隙沒有空格，但在Firefox里卻產生了一個x0020空格。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月6日 (日) 08:19 (UTC)
寬度你可以自己調整，上面已經給出來了。Copy的問題，可以用js把innerHTML給清空，但我覺得沒這個必要（因為有損性能）。--菲菇＠維基食用菌協會 2011年2月6日 (日) 08:20 (UTC)
總結一下，以下問題：
  1. 標題上怎樣使用；
  2. 間距能否proportional；
  3. 選中「取消漢字和拉丁字母之間的間距」後間距消失，但依然會copy出0020來（怎樣做innerHTML?）
——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月6日 (日) 08:35 (UTC)

我倒想把tidy自動去除empty html entities的行為報bug，剛才在MediaZilla:上搜了下之前有沒有人報過，但沒有找到，召喚liangent出來幫忙找。--菲菇＠維基食用菌協會 2011年2月6日 (日) 08:25 (UTC)

這名字我隨手寫的還真用上了……Liangent (留言) 2011年2月7日 (一) 17:08 (UTC)

另一提案：建立Wikipedia:格式手冊 (空格)

(！)意見：達師，你又把問題複雜化了，我之前一直沒再發言，就是因為我覺得，菲菇提出了一個很好的解決方案。好像剩下的，也就是百樂兔的反對了吧？—我是火星の石榴 (留言) 2011年2月10日 (四) 13:32 (UTC)

  • (：)回應我又不是這樣看，現在寫個方針，總好過無止境討論。大概之後應該會出現比較好的整個方案，我現在也根據某些經驗去編寫，奈何時間不多，只好交由其他人完成。--Flame 歡迎泡茶 2011年2月11日 (五) 01:46 (UTC)
  • @Red16：我感覺菲菇的方案技術上有局限，難道能在所有中英文之間加上{{sep}}？開一個bot對付所有最近更改？貌似有些難度吧。而且，另一方面諾頓360是否加{{sep}}恐怕又要一陣吵。再考慮到日本遊戲，於是才想到開這個，要不我也懶得插手 -_-|| --達師 － 198 － 336 2011年2月11日 (五) 01:54 (UTC)
(！)意見：日系僅限遊戲麼？ACGN(輕小說)現在不分家的。被人噴ACG腦也罷了(事實上我根本不是我怕什麼)。—我是火星の石榴 (留言) 2011年2月11日 (五) 16:42 (UTC)
(！)意見：看來，這問題又會淪為無法解決的懸案。大家都還是搞不清楚：這問題共識真正難產的原因，在於關注者的真正態度，要達成共識其實很簡單，就是要找出真正的利害關係人，請他們就讓步程度做說明。講直點，這空格雞毛蒜皮問題除了幾位打過編輯戰的維基朋友外，不管是我，達師，石榴，Flamelai，菲菇，甚至書生，都是無所謂小事情。換句話說，只要關注空格的社群朋友達成協議，問題很快就會解決。反觀，若這些戰鬥力十足的利害關係人不首肯，再多討論都枉然--Winertai (留言) 2011年2月12日 (六) 04:05 (UTC)
(～)補充：還是不識像囉唆一點，在我看來版面上的「投票動議」或「格式手冊修訂」或「小工具修改」都是談判手段上的「臨崖手段」，就是逼迫當事者出面說明底線的方法，因此不管這三種方法哪種方法付諸試行，決對有其解決問題效果，因此我是贊成哪種方式都可，為了減少資源浪費，這三種試行多數決共識是必然歷程了，現在就端看議案主持人的魄力與政治手腕了。--Winertai (留言) 2011年2月12日 (六) 04:16 (UTC)
(：)回應目前就是欠了一個更有力的方案去元美解決此事，好像以前某個方案都是懸而不決，直到將多個方案合而為一後，就容易處理了。--Flame 歡迎泡茶 2011年2月12日 (六) 04:57 (UTC)
(：)回應：從現在討論進程，看不岀「容易處理」的跡象。只是越來越複雜。--Winertai (留言) 2011年2月13日 (日) 09:44 (UTC)
(：)回應過了幾天，還有沒有人對此有意見？--Flame 歡迎泡茶 2011年2月17日 (四) 15:52 (UTC)
對什麼有意見？Wikipedia:格式手冊 (空格)嗎？對Wikipedia:格式手冊 (空格)的意見我已經寫明了。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月17日 (四) 17:11 (UTC)
(：)回應我指其他人。--Flame 歡迎泡茶 2011年2月21日 (一) 00:59 (UTC)
給我三天時間，去完成一個完美的方案。--Flame 歡迎泡茶 2011年2月21日 (一) 00:59 (UTC)
我先符加一點序言，在中文語境內，字與字之間應該沒有空格，但是有些情況下可以獲得例外。--Flame 歡迎泡茶 2011年2月21日 (一) 01:17 (UTC)

一個空格的問題（續2）

最後的方案

應該去到最後一步，我想的是如果此部份沒有人提出異議（反對意見）的話，我希望可以在一星期內達成共識，這部份寫在Wikipedia:格式手冊即可。

在中文語境內，字與字之間應該不留空格，但由於部份近期的爭吵，因此在此寫明在哪時候留下空格，而哪些時候不應：

    1. 正文內，中文和一般數字、中文和外文間不加空格。反例：港鐵 rev13627175，首段。
    2. 上方說明：如引用傳媒的新聞標題，一般慣例不用標點符號可以留下空格。
      • 特別地，專有名詞內的中文和數字、外文之間，適用上方的共識。（例子：諾頓360，下方詳述）
    3. 外文間保留空格。（例子：Google Chrome）
    4. 符號和數字、符號和外文間不加空格。（例子：System/360）
    5. 作品名內（中文和中文間）的空格，建議使用冒號（例子：軒轅劍叄外傳 天之痕，再討論），建議在作品的主題及副題使用，由於韓語沒標點，日語不在使用冒號，這點特別要注意。
    6. 上方共識。
      • 上方共識的補充說明：除非官方宣布名稱內含或不含空格，差異只有空格的2個或多個條目名稱在與其他條目名稱比較時視為同一個名稱。
    7. 全形空格的使用，但在大多數的情況下不應使用全形空格。
    8. 技術需要以及模板內需要例外。
    9. 在無爭議的情況下，建議使用先到先得的方式，以減少磨擦。
    10. 如有爭議，請先到該條目的討論頁或Wikipedia:移動請求反映有關問題。

--Flame 歡迎泡茶 2011年2月23日 (三) 08:52 (UTC)

(＋)贊成(＆)建議：若可以，請主持人羅列相關編輯戰條目，略述在此格式共識下，相關條目最適名稱，以避編輯戰再起。--Winertai (留言) 2011年2月24日 (四) 04:27 (UTC)
好像上面忘了外文與數字之間的空格問題。全形空格應該不允許使用，但是技術需要例外。--百無一用是書生 (☎) 2011年2月24日 (四) 06:55 (UTC)
(！)意見：請Flame將要添加的新相關內容先以「注釋」方式(隱藏)放於Wikipedia:格式手冊--Winertai (留言) 2011年2月25日 (五) 03:08 (UTC)
(：)回應這幾天有點忙，我會盡量處理一下。--Flame 歡迎泡茶 2011年2月25日 (五) 15:07 (UTC)
如各位再有任何意見，歡迎提出。--Flame 歡迎泡茶 2011年2月27日 (日) 09:07 (UTC)
討論已接近一個星期，暫時未收到特別大的反對意見，如意異議，此部份將會被寫入Wikipedia:格式手冊內。--Flame 歡迎泡茶 2011年3月2日 (三) 03:13 (UTC)
(！)意見在一個星期內，未收到任何反對意見，本人稍稍潤飾，在Wikipedia:格式手冊上說明。--Flame 歡迎泡茶 2011年3月2日 (三) 14:57 (UTC)
我還是反對的，最近客棧被牆，一直進不來。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年3月10日 (四) 13:27 (UTC)
（注）我的反對意見和2月24日的一致，至今未有針對該反對意見的反駁。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年3月14日 (一) 06:29 (UTC)

意見

我還是反對的，最近客棧被牆，一直進不來。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年3月10日 (四) 13:27 (UTC)
（注）我的反對意見和2月24日的一致，至今未有針對該反對意見的反駁。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年3月14日 (一) 06:29 (UTC)
請提出詳盡的反對理由，而不是為反對而反對。試圖將這個討論成為月經文絕對難看。還有虞海提出的不是空格，而是標點符號，請另開新的討論提出，謝謝。--Flame 歡迎泡茶 2011年3月14日 (一) 07:10 (UTC)
(：)回應：我是說這個「最後的方案」還很不完善，對細緻的內容作了過於苛刻的規定，其中包括：
  • 第五條「作品名內（中文和中文間）的空格，建議使用冒號」：不苛刻但很詭異；
  • 第一條「正文內，中文和外文間不加空格」：過於苛刻，屬於一概地否定；
  • 第一條「正文內，中文和一般數字間不加空格」：贊成；
  • 第七條「全形空格的使用，但在大多數的情況下不應使用全形空格。」：贊成；
  • 第八條「技術需要以及模板內需要例外。」：我認為模板中的一些修飾性空格可以去掉（如cite中），構成Tab的除外；
  • 第九條「先到先得」會導致格式的不統一（類似於有的章節標【】有的不標），我認為不如「最終用戶設定」的好，不過部分地可以接受（只要別太難看了就行）；
  • 第十條我支持，只可惜那是句重(chong2/ㄔㄨㄥˊ)話，等於沒說。
等等。
而我前面提出的異議相當於今天提得的異議的一部分（即第一行）。
——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年3月16日 (三) 08:40 (UTC)

本主題全部或部分段落文字，已移動至#關於虞海提出的討論。執行人：Flame 歡迎泡茶 2011年3月16日 (三) 09:12 (UTC)。

說出來簡直笑話

為了米國的一家商業公司在某天拍腦袋想出來的名字，你們居然討論了幾個月都沒有結果。其實尊重詞條創建者即可，根本不需要為如此無聊的事情再去建立一個什麼手冊。-Edouardlicn (留言) 2011年2月20日 (日) 11:02 (UTC)

雖然此討論相關版主對我曾有「嘴砲」指摘，但是我仍在此替他說項。
閣下請參考[8]，如果閣下能在「比幾個月」的更短時間內，讓這類型條目「編輯戰」、「保護」等情形不再發生，這些討論及版主的相關手冊規劃一定嘎然停止。
我粗略算了算，以維基10年，每年600萬美元資金、10億次總編輯量核算，一次編輯約要0.06美金，「光這條目」為空格興起的編輯戰、保護所花的錢絕對在30塊美金以上，若含其他相關條目，可能在這金額數倍、數十倍以上。或許有人認為這些錢該花，但是個人以為：此版相關討論，其最終用意只是不想這些因為空格所花的冤枉錢一直燒下去。--Winertai (留言) 2011年2月21日 (一) 03:21 (UTC)
創建條目一直以來有一個原則，就是標題以創建者的版本為準。這個我覺得除了是尊重創建者外，還是為了避免類似情況的發生。類似原則可以用在空格問題上。只要大家都不要互相為敵，那就天下無敵了。-Edouardlicn (留言) 2011年2月23日 (三) 12:21 (UTC)
如果先到先得成為方針的話，我是否可以創建每個章節都使用==【章节名称】==這樣格式的文章？——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月24日 (四) 15:41 (UTC)
如果是像以上的例子太過份的話，相信會有維基人把它移動。如果沒有衝突的話，我想大家不應多必一舉。--Flame 歡迎泡茶 2011年2月24日 (四) 16:03 (UTC)
我說的是條目標題，不是章節標題。不過虞海的建議也不錯，日後我會考慮用這樣的格式，哈哈。—Edouardlicn (留言) 2011年2月25日 (五) 06:00 (UTC)
(：)回應不過如果說章節標題的話，又是另一回事了，但這方面未引起衝突，所以暫時不必討論了。--Flame 歡迎泡茶 2011年2月26日 (六) 15:17 (UTC)
問題本質是相同的：先到先得會造成格式上的不統一，而且會很扎眼。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月26日 (六) 15:44 (UTC)
由於本版某些言論被和諧，我只好冒著和諧的風險來回復了。扎眼與否，關鍵其實就在於看的人是否看得開。我一直都是這麼想的。—Edouardlicn (留言) 2011年2月26日 (六) 15:51 (UTC)
請不要忘了維基百科是一部百科全書，如果有的條目有【】，有的條目沒有【】，將會是什麼樣子？說得更過分一點：同一個條目，有的章節有【】，有的章節沒有【】，看你怎麼讀。順便說一下，目前在這裡發言是不需要什麼特殊辦法的，直接編輯就行。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月26日 (六) 16:50 (UTC)
(※)注意方案已寫進Wikipedia:格式手冊請將本討論一併儲存，謝謝。--Flame 歡迎泡茶 2011年3月3日 (四) 16:07 (UTC)
未成共識，3月10日已被回退。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年3月14日 (一) 06:27 (UTC)
請提出詳盡的反對理由，而不是為反對而反對。試圖將這個討論成為月經文絕對難看。還有虞海提出的不是空格，而是標點符號，請另開新的討論提出，謝謝。--Flame 歡迎泡茶 2011年3月14日 (一) 07:10 (UTC)
原來閣下在這裡給了留言，我移動了一份到上面（#意見），並將在該段回復。另外，請注意用詞。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年3月16日 (三) 08:27 (UTC)
請重新開新的討論，謝謝配合，本文有點過長。--Flame 歡迎泡茶 2011年3月16日 (三) 09:08 (UTC)

異體字

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。

(！)意見：問題鬧大了，有必要分開討論，下分段。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月26日 (三) 07
23 (UTC)

不立方針，具體問題具體分析的思想

關於姊、姉的討論

「姉」好象是日本人用的吧。—Edouardlicn (留言) 2011年1月25日 (二) 14:26 (UTC)
給閣下加上了－｛｝－對。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月25日 (二) 15:01 (UTC)
「姉」我不知道，沒見過。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月25日 (二) 15:06 (UTC)
補充一下，姊川之戰本來就是不正確的寫法，還做了重定向......。—Edouardlicn (留言) 2011年1月26日 (三) 00:02 (UTC)
深入研究一下，【爾雅·釋親】男子謂女子先生曰姉。這個字在古語中有另外的意思，尤其是一些文章中引用爾雅該句居然也寫錯了字，寫成姊。所以我認為異體字問題修改應該慎重，不要將一些自己不清楚是否有錯的東西給越改越錯。—Edouardlicn (留言) 2011年1月26日 (三) 02:14 (UTC)
姊和姉的轉換mark一下，今天晚上來改轉換表。--菲菇＠維基食用菌協會 2011年1月26日 (三) 03:09 (UTC)
在古文書中，是寫作「姊川」。--Flame 歡迎泡茶 2011年1月26日 (三) 08:53 (UTC)
  • (：)回應全句是：「姉，女兄也，男子謂女子先生曰姉」，當中的「先生」是「先出生」的意思，與「姊」的意義完全相同。而「姉」和「姊」只是到楷書時筆畫分化而成，小篆中是同一個字。因此「姉」與「姊」只是同一字的不同寫法，可考慮以較常用的「姊」作為標題，重定向亦可。但「姐」和「姊」不是同一個字，讀音也不同，用法也不是完全相同，如「小姐」不能寫成「小姊」，把「姉」或「姊」寫成「姐」屬於錯別字--Ws227 (留言) 2011年1月26日 (三) 04:08 (UTC)
我的意見是，此字在不同時代不同場合的用法不一樣。尤其是在不同文化上，所以在一些跨文化條目上請慎重，以免貽笑大方。至於黃真伊等，正如Ws227所指，我也不是這方面的專家，我建議但凡涉及古文、日本朝鮮一類的文化等，修改前應作單獨討論。-Edouardlicn (留言) 2011年1月26日 (三) 04:58 (UTC)
這些議題，幾年前就討論多次了(我記得一次還是費勒姆主導)，大家討論後都無疾而終，其重點都忽略了其他維基多是以「語言」為籓籬，而中文維基在實際運作上是跨「語言」，以文字為主。--Winertai (留言) 2011年1月26日 (三) 07:59 (UTC)
那一定不是我，很少就為「國字」而作出討論。--Flame 歡迎泡茶 2011年1月26日 (三) 08:19 (UTC)

中文維基百科未規定以官方語言（普通話、國語）書寫，但維基人默契以其為通用形式，適度摻入書面語或文言文，以力求文句通順優美。（中文維基）

  • (！)意見：依上述條目內文：「姉」是否存在，是否由姊翻譯替代，關鍵在於「姉」是否存在於「官方語言」（通用形式），很可惜，就「官方語言」主要認定來源的台灣教育部辭典（國語文）來說，姉字並不存在。

另外，我也找到2008年5月間的討論：當初是為了「咗」字。「我總認為除了「外文」（包含和製漢字）；中文維基所用中文文字皆要來自康熙字典；辭海或辭源或通用字典（包含港澳地區使用的中文字典）。不知咗或撻有無符合這標準？如果沒有，那就是該在粵語維基出現，不該在中文維基出現。--winertai (留言) 2008年5月10日 (六) 14:31 (UTC)」--Winertai (留言) 2011年1月26日 (三) 09:29 (UTC)

咗字收錄在異體字字典的附錄索引中[12]。至於姉字不收錄在國語辭典，應該不影響中文維基百科（ZHWP）使用這個字，因為ZHWP未規定以官方語言書寫。--Gakmo (留言) 2011年1月26日 (三) 09:54 (UTC)

問題是，姉字存在於GBK、Unicode、UTF8中（參考）。中文維基應該是服務於大中華區，而不應該只是參考台灣的教育部標準。更何況連結提供的只是一個教育部的詞典，我不知道這個詞典分量有多重，但即使是大陸，詞典也有新華字典、現代漢語詞典等等，不同級別的詞典涵蓋的信息量及使用對象並不相同。我認為只要我們的輸入法還能打出這個字，這個字就應該肯定其地位。更何況康熙字典都有此字？另外，如果僅以教育部標準沒有此字為準繩，那和大陸的某些公安局因為系統使用GB碼無法輸入某些字，就不讓人改名改那個字的強制行政手段有何區別? -Edouardlicn (留言) 2011年1月26日 (三) 09:57 (UTC)

我支持「「小姐」不能寫成「小姊」」，但基於目前一些涉及外來文化和古文的內容依然存在爭議，我依然建議這類內容保留爭議部分不要修改。—Edouardlicn (留言) 2011年1月26日 (三) 10:17 (UTC)
那麼「豐」跟「豊」呢？有人將伊東豐雄移動至伊東豊雄，是他本人的意願。

--Flame 歡迎泡茶 2011年1月27日 (四) 01:28 (UTC)

幸好他主動提出更正，可按名從主人規則處理。--Gakmo (留言) 2011年1月27日 (四) 01:45 (UTC)
但是從簡體上「豊」字不能轉化成「丰」，難道他前往大陸時需要在解釋一次？--Flame 歡迎泡茶 2011年1月27日 (四) 02:03 (UTC)
其實伊東豊雄的豊在日文是代表豐抑或豊（音禮）？如果是豊，而大陸叫他伊东丰雄，看來真的要解釋多一次了 :) --Gakmo (留言) 2011年1月27日 (四) 02:09 (UTC)
「豊」，本作「𧯽」。非「豐」也。豎之有無，大異也。—J.Wong 2011年1月27日 (四) 03:39 (UTC)

我的電腦顯示不到「𧯽」，與我同者，可參考[13]。--Gakmo (留言) 2011年1月27日 (四) 04:24 (UTC)

所以除了豐臣秀吉的豐臣外，似乎都應該要使用「豊」字，那簡體該用礼嗎？個人意見，純屬原創研究。--Flame 歡迎泡茶 2011年1月27日 (四) 07:48 (UTC)
唉，把「伊東豊雄」當成「不同語言」（日文）來看，不是一切OK嗎？伊東豐雄是「翻成中文」（「翻得好不好」或「已經約定成俗」，兩者純粹是因個人見解不同而有相異），「伊東豊雄」為日文原文不就結了。--Winertai (留言) 2011年1月27日 (四) 11:13 (UTC)
(：)回應其實癥結問題在跟我與Edouardlicn兄討論中浮現了，因為維基是以「語言」區分而非以「文字」區分，其現有運作則是：「中文維基百科未規定以官方語言（普通話、國語）書寫，但維基人默契以其為通用形式」的方式。我們要討論的是：其一是：哪些「異體字」是不存在於普通話或國語（我認為台灣教育部辭典沒出現的就算不在國語之官方語言範圍內）？其二則是：不存在普通話或國語的異體字，是否要因為「非通用形式」而捨用？這概念一旦釐清，這些困擾就可以迎刃而解；而不必一個個案例來討論。--Winertai (留言) 2011年1月27日 (四) 10:57 (UTC)
(～)補充我再強化補充上面說法，我們講普通話或國語時或閱讀報章雜誌中，除了「專有名詞」外，會有「姉」這個字出現嗎？如果沒有，我是建議把這個字視同「非通用形式」，至於非通用形式的異體字是否存在於中文維基自是可以慢慢討論；我個人看法是不宜存在。--Winertai (留言) 2011年1月27日 (四) 11:25 (UTC)
(：)回應我舉的例有點廢，其實這個「http://dict.revised.moe.edu.tw/cgi-bin/newDict/dict.sh?idx=dict.idx&cond=%E0T&pieceLen=50&fld=1&cat=&imgFont=1 豊」字是在文言文存在，所以我提出的例子有點不正確，但當字有兩個意思的時候應該怎辦？--Flame 歡迎泡茶 2011年1月28日 (五) 13:52 (UTC)
(：)回應「中文維基百科未規定以官方語言（普通話、國語）書寫，但維基人默契以其為通用形式，適度摻入書面語或文言文，以力求文句通順優美。」，我看法是文言文在中文維基屬於「非通用形式」，因此豊字非屬必要，不宜存在。--Winertai (留言) 2011年1月29日 (六) 05:23 (UTC)
(：)回應：維基百科的內容不應僅僅包含通用形式，更應該保存有價值且有資料來源的內容。以「飛虎隊」為例，通用稱呼是對警察特別機動隊，但實際上在中國歷史中有一個特殊含義。如果今天我們以「此非通用形式」作為衡量去刪除某些內容，他日必有後人以同樣的理由刪除我們的內容，因為「通用」本來就非一成不變。 -Edouardlicn (留言) 2011年1月29日 (六) 06:47 (UTC)

對於異體字，如果有語義完全對應的現行通用漢字時。無需思考，應直接替換成現行漢字（某些專門講述漢字文化的文學作品不在此列）中國文學作品的本來就存在鍊字的說法，如果某些異體字找不到對應漢字，或者一些形近字幽默，我認為無需替換 --Victor.In (留言) 2011年3月2日 (三) 11:45 (UTC)

中文異體字VS中文俗體字

名從主人的

一般使用

常見異體字

一旦確認為常見，應無須做原文（即源碼）轉換；至於自動轉換，可按菲菇的現行做法，簡體跟官方，繁體不用轉。關鍵是何為常見。--Gakmo (留言) 2011年1月26日 (三) 09:03 (UTC)

我認為：
  1. 港台標準互異的：羣、群
  2. 有規律的舊字形（大陸）或出版社用字（港臺）：爲、卽、眞、靑、兪
  3. 公認常見的俗字：台、囯
至少這三類應被認作是常見異體字。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月26日 (三) 15:20 (UTC)

(＆)建議制訂「常用異體字」原則，一旦確認為常用，無須做源碼轉換，交由自動轉換（簡體跟官方，繁體不用轉，見下面菲姑早前的留言）。非常用者，將源碼改為正字（參考兩岸三地官方標準）。歡迎討論。--Gakmo (留言) 2011年1月27日 (四) 02:57 (UTC)

……我在處理字詞轉換請求的時候也遇到過異體字的情況，說一下我的處理方法。異體字的轉換無外乎只有三種：中文異體轉簡體，中文異體轉繁體以及日韓異體轉簡繁體。目前我的處理方法是，對於出現或曾經出現在中文（文言文和現代文）中的異體字，因為中國大陸存在統一的異體字轉簡體字標準，所以可以添加轉成簡體的規則；對於出現或曾經出現在中文尤其是文言文中的異體字，出於儘量保持其原貌的原則，繁體方面基本不添加轉換規則（因為繁體承擔著保持古文原貌的責任）；對於僅出現在日文、韓文或越文中的異體字，因為這些文字已經不屬於中文的範疇，為避免混淆誤讀，所以均不轉換，翻譯時請人工修正。--菲菇＠維基食用菌協會 2011年1月25日 (二) 15:53 (UTC)

我覺得只要中文裡的確出現過，那麼繁體模式下不用轉為常用寫法，簡體模式下則統一轉為簡體，原因上面已經解釋了。--菲菇＠維基食用菌協會 2011年1月26日 (三) 03:09 (UTC)
基本( ✓ )同意。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月31日 (一) 19:08 (UTC)
(？)疑問：可否推動成爲指引？——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月4日 (五) 05:30 (UTC)
源碼轉換政策
  • (！)意見異體字一般應該轉換成相應的正體字。除非人名字、地名，則名從主人。--蘋果派.留言 2011年1月25日 (二) 22:21 (UTC)
  • 我認為這跟韓國人、日本人沒關係。他們用什麼，是他們的事；那些僅出現在日文、韓文或越文中的異體字，是斷不應出現在中文維基百科的正文中的。我們要保證的是用戶書寫的是現代標準漢語，就足夠了。至於是用簡體還是用繁體、用異體還是用俗體，不應作要求；如果作了要求，就違反了中理性原則。因此，不見一添加任何手工轉換（名從主人帶來的手工轉換例外）。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月26日 (三) 06:57 (UTC)
自動簡繁轉換政策
  • 對於自動字詞轉換，應謹慎。對於青，建議是zh:青;zh-hans:青;zh-hant:靑;zh-cn:青;zh-tw:青;zh-hk:青;zh-sg:青;。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月26日 (三) 06:57 (UTC)
    • 有個問題，為何繁體中文（zh-hant）是靑？這是大陸繁體還是古繁體？日本漢字？在香港的印刷體是有用靑，但手寫的話一般都是青。--LungZeno(talk) 2011年2月2日 (三) 20:18 (UTC)
      • 這是兩岸標準寫法問題，據《說文解字》，青從生丹，理應是「靑」，台灣以楷體為標準寫法，但依小篆字形隸變、下為「月」，所以把俗字「青」扶正；印刷體為明（宋）體（亦是日本標準寫法，但同台灣把「青」扶正），因而保留以前字形，大陸採宋體標準寫法也是「靑」。--Justice305 (留言) 2011年2月12日 (六) 15:07 (UTC)
古文異體字
如果是古代中文用字但現在中文不常用的呢（如「姉」）？需要轉換為常用寫法嗎？--Ws227 (留言) 2011年1月25日 (二) 16:35 (UTC)

(！)意見--正如Ws227所說，異體字的常用程度各有不同，是否可以制訂「常用異體字表」，如羣、眞等，該等字不須轉換。--Gakmo (留言) 2011年1月25日 (二) 18:27 (UTC)

  • (！)意見 我有一個疑問，是否因此就無限接受各類中文異體字？只因為「可能有人在用」，或者「老年人可能更習慣」。比如「靑蟹屬」這種寫法，Google搜尋，除了這裡在討論，沒有其他結果。--∰ 黑目觀世界 ⌘ 2011年1月25日 (二) 18:47 (UTC)
  • 對於接受各類中文異體字的限度問題，我認為有必要作如下補充： 很多寫法的常用程度不能主觀臆斷，比如「靑」，Google搜尋內容稍只能說明網絡上不常用，是中文輸入法的緣故，但這個字在各類出版物中還是常用的。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年1月26日 (三) 06:57 (UTC)
原文轉換政策
自動簡繁轉換政策

外文異體字

有關的異體字的變換，如有需要的話亦都只在單一計劃的轉換中修改；而不應該反映在MediaWiki軟體本身中。 Shinjiman ⇔ ♨ 2011年1月29日 (六) 06:31 (UTC)

異體字2

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。

方案一 方案二
制定「常用異體字表／可接受異體字表」，包含諸如卽、眞、羣、靑等常用異體字，一旦確認為常用，無須做源碼轉換。非常用者，將源碼改為正字（參考兩岸三地官方標準）。 甲：以官方語言（普通話、國語）書寫，源碼出現異體字，一律改為正字。
乙：以官方語言（普通話、國語）書寫，源碼出現異體字，一律改為正字。但若涉及名從主人，或該異體字的使用並非在現代漢語之語境下，而為其他語言（如日語等）或古代漢語，則個別處理。

綜合之前的討論，請大家就以上方案發表意見，討論結果應寫入格式手冊，謝謝。--Gakmo (留言) 2011年2月7日 (一) 09:52 (UTC)

兩方案是並存還是2選1？—Edouardlicn (留言) 2011年2月7日 (一) 11:45 (UTC)
我認為應該是2選1。--Gakmo (留言) 2011年2月7日 (一) 13:57 (UTC)
我認為現在應當討論的是：哪些是常用異體字。我在#常見異體字里提出了3條標準作為充分條件：
  1. 港台標準互異的：羣、群
  2. 有規律的舊字形（大陸）或出版社用字（港臺）：爲、卽、眞、靑、兪
  3. 公認常見的俗字：台、囯
——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月7日 (一) 12:07 (UTC)
我覺得只要不涉及歷史沿革（比如這個字轉化為現代用字是有若干一段歷史）或者其他亞洲文化的，處理起來問題不大。—Edouardlicn (留言) 2011年2月9日 (三) 01:25 (UTC)
若人名使用的，如林育羣，要如何處理？—Ellery (留言) 2011年2月11日 (五) 02:50 (UTC)
謝謝回應。這正是我們要討論的。根據方案一，若羣是常用的異體字，「林育羣」的寫法可保留。若根據方案二，則視乎是嚴格（甲）抑或寬鬆（乙）的版本。--Gakmo (留言) 2011年2月11日 (五) 06:55 (UTC)
(＋)支持方案二，另外還是堅持「和製漢字」即使與異體字相通，仍視為「日文」。遇此情況，以「原文」顯示或翻成現代中文，以先到先得為原則，並考慮接受已約定成俗之仿讀情形--Winertai (留言) 2011年2月11日 (五) 16:20 (UTC)
閣下支持方案二，怎麼還以先到先得為原則？這部矛盾嗎？我也堅持「和製漢字」即使與異體字相通，仍視為「日文」，參見關於用於外文的中文異體字的意見。——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月15日 (二) 13:20 (UTC)
針對第二項第二款「個別處理」備註，即單指「日文和製漢字」情況可以先到先得為「原則」（免於已命名條目大量移動引起糾紛），也就是把這些「日文」視為在中文維基裡的IBM。--Winertai (留言) 2011年2月16日 (三) 09:18 (UTC)

(！)意見方案一：似乎涉及一些非必須的後勤工作，而效用卻不明顯，我雖不反對但覺得不必那麼麻煩。(－)反對方案二（甲）：這樣做彈性太小了，而且感覺很專制，有違本百科自由的精神；(＋)贊成：方案二（乙）：姓名等專有名詞不應由他人或後來的人，來替本人決定當用何字。Fuenping 2011年2月13日 (日) 23:41 (UTC)

不知方案一能否一併解決涉及日韓漢字的命名問題，因為一但該字被納入常用異體字表，即可用作條目名。不過問題實在太複雜了，異想天開中……--Gakmo (留言) 2011年2月14日 (一) 02:43 (UTC)
(：)回應Gakmo：我感到最好不要把兩個不同的論題放在一起處理：參見維基百科討論:格式手冊#中文異體字VS中文俗體字「關於用於外文的中文異體字的意見：對「眞」等字，如果舊字形是外文帶來的，中文可適用常用字形（具體按維基百科討論:格式手冊#外文異體字處理）；但如果舊字形是中文帶來的，就應當使用舊字形。」——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月15日 (二) 12:21 (UTC)

一個問題

撇開制度不談，我有一個問題：閒、間、閑三字中，哪兩個字是正字？哪一個字是異體字？——以上未簽名的留言由虞海（對話｜貢獻）加入。 2011年2月21日 (一) 13:18 (UTC)

根據國語辭典，三者都不是異體字。--Gakmo (留言) 2011年2月21日 (一) 16:12 (UTC)
應查教育部異體字字典，據歷代小學字書說法，以閒為本字，閒正、間俗、閑通。--Justice305 (留言) 2011年2月23日 (三) 06:30 (UTC)

錯別字、錯詞及標點修正

「3標題的格式」中第三行「因未」應改為「因為」。--Oling Cat (留言) 2011年9月6日 (二) 10:08 (UTC)

「7.2引號」第二行「或者英文的全形＂　＇。中文內容也不要用" '。」應改為「或者英文的全形（＂　＇）。中文內容也不要用（" '）。」--Oling Cat (留言) 2011年9月6日 (二) 10:28 (UTC)

關於戰役條目中†的使用，能否統一到格式手冊或相關專題？

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。

之前曾經提出過很多戰役條目中的†的使用存在標準不統一的問題，這次把相關的內容拿出來請教一下：

英文維基的en:Dagger (typography)條目中有說：「In military history, a dagger is often placed next to the name of a commander who is killed in action.」，但後面有個來源請求，不知道是否準確。如果是只限於killed in action的話，自殺就不應該包含在內了，例如柏林戰役中阿道夫·希特勒（英文版則沒有將希特勒列為指揮官）

另外還有戰敗之後被殺應不應該加†？例如伊拉克戰爭中薩達姆·海珊有†，關原之戰中石田三成則沒有†，標準不統一。 --愛管閒事的Inspector（留言） 2011年10月3日 (一) 08:23 (UTC)

全部都不加如何？—AT 2011年10月3日 (一) 14:59 (UTC)
(：)回應：不可以！沒編過戰役條目的AT這兒沒你置喙的餘地。--俠刀行 (留言) 2011年10月3日 (一) 15:23 (UTC)
我笑了。。-治癒留言 2011年10月4日 (二) 12:31 (UTC)
希特勒不是在戰役中戰死的，理應不加上這個標記。薩達姆不是死於戰役，石田三成勉強算是，不過要加十字準確地說應該加在大谷吉繼上。—馬呵說年誒多嘩鐸★魔力 (留言) 2011年10月3日 (一) 15:51 (UTC)
結合上面的意見，†是否只能表示陣亡？其次，自殺的怎麼表示好呢？以英文維基百科為例，單從en:World War II的信息框來看，都不知道希特勒死了。--愛管閒事的Inspector（留言） 2011年10月4日 (二) 02:36 (UTC)
好像沒有相對應的，閣下可以問Ai6z83xl3g和Oneam兩位軍事條目專家，或許可以得到正確的解答。--KOKUYO (留言) 2011年10月4日 (二) 11:13 (UTC)
希特勒不死於直接戰爭傷害，†只適用於某人死於戰爭直接造成的傷害（中彈什麼的）。打了敗仗自殺不應算作戰死。-治癒留言 2011年10月4日 (二) 12:31 (UTC)
有多少人在編輯的時候去研究過這個判定標準？而且，灰色地帶太多，有必要非得強制統一嗎？我也沒編過甚麼戰役條目。-cobrachen (留言) 2011年10月6日 (四) 02:19 (UTC)
詳細、統一一點總是好的吧。至於灰色地帶，有人討論就討論，沒人討論就維持現狀。英文en:Iraq War裡面的指揮官都有不同的模板，我覺得可以借鑑一下。--愛管閒事的Inspector（留言） 2011年10月6日 (四) 02:27 (UTC)

這就不叫作統一啦。要統一格式就是避免日後一條一條，一個人一個人的拿出來討論。所以，要嘛就是定出大家可以具體了解和參考的格式規範，要嘛就像現在鬆軟一點。夾在中間只怕會令人更難以遵循與了解。一旦過於繁複，會使用和參照的人就會下降。-cobrachen (留言) 2011年10月6日 (四) 03:27 (UTC)

模板有Template:KIA、Template:俘虜、Template:投降（en:Template:KIA、en:Template:POW、en:Template:Surrendered）這些，被處死也有加連結這樣的表示方法或en:Template:Executed。對於是否被俘、投降或者陣亡這樣的判斷一般是較為容易，引起爭論的可能較小，有爭議的話多半也是對戰役過程的爭議，不僅僅是模板的事情了。--愛管閒事的Inspector（留言） 2011年10月6日 (四) 05:20 (UTC)

避免中文粗體斜體字

雖然系統預設的功能最方便，瀏覽器也很支援斜體與粗體，但是中文字其實不太適合粗體，更不適合斜體字。電腦與字體有限，讀者認字體也有困難。英文版Wikipedia:Manual of Style/Text formatting就有說："Text in non-Latin scripts (such as Greek or Cyrillic) should not be italicized at all—even where this is technically feasible"。建議在格式手冊中提出避免中文粗體斜體字的建議，在使用介面也避免這些字體。111.251.225.191 (留言) 2012年1月6日 (五) 13:34 (UTC)

斜體可以用仿宋代替（我個人正在拼一個 fallback），但是粗體沒什麼好改的。多字重中文字體是趨勢。--Arthur2e5 更改·工具 2014年9月24日 (三) 01:26 (UTC)

現有時間格式說明可能會引導編者添加大量時間連結

在說明時間格式時，用大量例子給年份等添加連結。一般不要給時間添加連結是英文版的方針之一，中文雖不要求，但這裡的說明可能會給編輯以誤導，以為遇到時間就要添加連結。因此作了些修改。 * 無與倫比的豆腐（留言） 2012年4月21日 (六) 15:33 (UTC)

有無防止外文泛濫的方針

Wikipedia:格式手冊指出，如果該名稱的來源是外文，請在括號里加上標明語言的外文原名。（但是沒有指出非外來來源不應當使用這一格式）

但是現在很多條目都模仿這一風格（以凸顯自己的國際化？）如：

  • 濱海新區：濱海新區（英語：Binhai New Area），是中國天津市下轄的副省級區...
  • 金茂大廈：金茂大廈（Jin Mao Tower），又稱金茂大樓...
  • 平安銀行：平安銀行股份有限公司（英文：PING AN BANK CO.,LTD.）簡稱平安銀行...
  • 寶鋼：上海寶鋼集團公司（Shanghai Baosteel Group Corporation，簡稱寶鋼，Baosteel）為國有獨資公司...

源於中國大陸本土的公司何必畫蛇添足加上英文名，如果要加，我覺得宏達電的範例不錯：宏達國際電子股份有限公司，簡稱宏達電，英文簡寫「HTC」。

不過我沒有找到對於這方面的規範。 -- * 無與倫比的豆腐 2012年4月29日 (日) 14:57 (UTC)

誰說中國大陸內運作的公司就不可以用英文名字？--馬呵說年誒多嘩鐸★魔力（留言） 2012年5月2日 (三) 00:13 (UTC)
以上的例子，其英文名稱都是non-trivial的資料，一半拼音，一半意譯，光是看中文名稱不容易知道英文名稱，例如我會以為金茂大廈是Jin Mao Building、寶鋼是Baogang。在中國境外上市、或是在中國境外從事商業活動的機構，其英文名稱更應該標示。--Quest for Truth（留言） 2012年5月3日 (四) 18:11 (UTC)
並不是non-trivial資料就可以保留，而是中文下保留外文名是否有意義。--達師 － 218 － 372 2012年5月4日 (五) 05:15 (UTC)
現在的問題是，這種「中西合璧」是現實存在的，而且是有可靠來源的，而且還是官方制定的（雖然官方有時候也未必官方，比如一個地方兩個名字），所以理論上說只要有資料支持都應該保留，就算是一坨屎。--馬呵說年誒多嘩鐸★魔力（留言） 2012年5月4日 (五) 05:41 (UTC)
照這樣說，內蒙古各盟旗、新疆和西藏的絕大多數縣都要標注英文名；不使用拉丁文的各國政區名也應標注拉丁文拼寫，因為都是官方制定的。--inhorw（留言） 2012年5月11日 (五) 16:39 (UTC)

首段條目名稱後括號里的原文名稱加斜體？

個人認為，條目名稱後的原文名稱加斜體會更具有可讀性，而且一般好像也是這麼做（？）。

比如：「條目（Article）」和「條目（Article）」。

另外，斜體是否需要把括號也包括進來我還不清楚。--ks (*) 2012年5月28日 (一) 05:45 (UTC)

一般來說只有部分專有名詞，例如書籍名、電影名、物種拉丁學名需要加斜體--百無一用是書生 (☎) 2012年5月28日 (一) 05:51 (UTC)
感謝解答。是否考慮把加斜體這條增加到指引裡面呢？這是我的本意。--ks (*) 2012年5月28日 (一) 14:53 (UTC)

編輯條目過程如涉及方言或非通用詞語時，請儘量顧及其他人士

現發現有個別香港有關的條目內容中，會提到粵語，如1、2，此外還有很多條目寫有「杯葛」（大陸地區極少用此說法，絕大多數用抵制一詞）等，非使用此類語言（或方言）人士很難確切理解其中的意思，還請編輯者在編輯相關內容時，在其後用括號翻譯成通用之話語。——語句不通順不舒服斯基┣●┫不想屌我敬請留言吶親 2012年9月5日 (三) 05:59 (UTC)

朗文高級新辭典有此詞.....好像並非粵語或方言..好吧...我離題了...卍田卐JC1 2012年9月5日 (三) 08:16 (UTC)
「杯葛」，在台灣很常用。--Djhuty（留言） 2012年9月5日 (三) 10:05 (UTC)
《教育部重編國語辭典修訂本》有收錄，是外來語。--Kolyma（留言） 2012年9月5日 (三) 10:13 (UTC)
「杯葛」在書面語裡挺常用的吧。。--CHEM.is.TRY 2012年9月5日 (三) 10:22 (UTC)
方言或非通用詞語有時候恐怕難以界定。至於杯葛，你現在既然明白了其意，我希望你也能欣然包容之。如果你看港台媒體，這類詞會更多；反之港台讀者看大陸媒體，也未必都能看懂。--Zhxy 519（留言） 2012年9月5日 (三) 10:28 (UTC)
話說按照維基的標準「不好使」算是「方言」嗎？在瀋陽說話時經常用到這個詞，但某次在和一個四川人聊天時他確實表示不懂「不好使」是甚麼意思。--張樹人留言·Talk·電郵·Email·IM - LGBT協會 2012年9月5日 (三) 10:32 (UTC)~
"不好使"應該是方言，南方不使用。--Snorri（留言） 2012年9月5日 (三) 10:36 (UTC)
引用方言的話，引用部分後面用括號加上通用漢語翻譯是必須的。一般行文中用詞的話，杯葛其實算是通用的了，見過粵語方言特徵比較明顯的有"的而且確 "，"只但是"什麼的。--Snorri（留言） 2012年9月5日 (三) 10:34 (UTC)
提出這種討論的仁兄，要請別人顧及之前，是否能先把自己顧好？這種歪理，無非是想挑起筆戰，難不成你們所在地域或國家就沒方言，要我們大家都配合你們那裡所用的辭語嗎？有時候我們又何嘗不對你們所用的方言感到困擾，為何不替我們想想呢？所以說，方言是因地域上的人文背景出現差異所產生，既然住在不同地方就會有不同的用詞字彙，那麼就請提出這種討論的仁兄，尊重不同地域或國家的人所使用的方言，而不是要求別人來配合。－36.232.213.121（留言） 2012年9月5日 (三) 11:32 (UTC)
很抱歉，在我所編輯的條目中，我儘可能的避免了使用方言或非通用詞彙，我所提議的方言，並非只針對粵語，也針對大陸地區的其他方言，維基百科的受眾是所有漢語用戶，不是某一部分人群，不能因為使用某類方言（或稱之為語言）的編輯者多，而將沒有經過翻譯或說明的此類方言加入到條目之中。我尊重所有人（包括閣下）所使用的方言權利，但亦請閣下顧及到讀者或編者可能非某一方言使用者。——語句不通順不舒服斯基┣●┫不想屌我敬請留言吶親 2012年9月5日 (三) 18:11 (UTC)
你自己怎麼說都可以，但不要因為你自己認為做得到，就想要求別人跟你一樣做得到，並不是每個人都清楚知道自己所用辭語會不會變成別人看來就是看不懂的方言，也就是說，你知道怎做，不代表別人知道怎麼做，不是你想要別人顧及就能顧及這麼容易，所以別這麼天真了，除非有什麼辭典可以查各地的方言來對照，否則處處都是地雷，一不小心就會因別人看不懂就說是方言。反過來說，這位仁兄，與其你在這因為看不懂方言，所以跑來這要求別人，你倒不如將你不懂的方言拿去查去翻譯還比較實際，畢竟很多人都在寫條目，不見得你在這說就會大家照你來做，最終你自己問題得要靠你自己去解決，否則你無論說多少次，也只不過是緣木求魚罷了！－36.232.222.198（留言） 2012年9月6日 (四) 12:24 (UTC)

我覺得你自己有心這麼做，自己編寫的條目或添加的內容裡，有留意到各地的辭語，並加以翻譯整理，確實是對讀者而言，倒是很貼心且人性化的，是值得鼓勵；但不鼓勵在未探討別人為何不做之前，就先對別人下評語或發出要求，這會給人認為你有這麼做，所以別人也要這麼做。其實，未必不是別人不想做，只不過你是否想過這種對讀者貼心的舉動，為何大家很少人做，說不定是有人不知道如此會造成讀者困擾，或者是曾經想過要做，只是因為不知道怎區別方言而去改善，也有可能有人覺得麻煩而不做，諸如此類的原因等等，還有內文龐大的條目，若添加很多方言翻譯，可能對某些讀者族群有閱讀上困擾，因為排版擠壓或美觀問題，加了很多[注1]、[注2]……[注N]，說不定日後就會有人拿出來要推掉這種貼心的舉動了。－36.232.222.198（留言） 2012年9月6日 (四) 12:43 (UTC)

我覺得還是應該儘量用標準漢語，實在不行就用簡繁轉換。—以上未簽名的留言由Jack No1（對話｜貢獻）於2012-09-07T18:54:47加入。

條目撰者所使用詞語及修辭有存在方言造成讀者閱覽困擾該如何解決

重新發起這則前人提出編輯條目過程如涉及方言或非通用詞語時，請盡量顧及其他人士討論，本意上是好意且很有道理，但做法上頗為困難，況且不應貿然私人見解去要求別人遷就，為此需要協調來自各地的撰者及讀者們，將自己所慣用文字詞語及修辭用法，彼此分享討論其心得，因為有人自以為很神通，能將自己與別人的世界相通，知道有一定的方法可避免存在方言隔閤，與其藏私不報，不妨拿出來討論，教導大家，否則明知會做而不教，只會指責他人的不是，這也只不過是挑起筆戰罷了！－36.232.222.7（留言） 2012年9月18日 (二) 14:53 (UTC)

由於前人討論過程中，因為有人是憑著「他會做而別人也會做」如此想法，那請問該叫別人怎麼做？如此豈不有強人所難之意？所以原本討論發起之本意是好，強人所難的做法卻已經將好意扭曲了，只因對方知道怎做而不公開出來，藉別人沒有這樣做的情況為由來指責其不是之處，如此之舉，豈非無心正視問題存在來解決嗎？我不忍因為有人拿出問題來而不解決，任其荒廢，無奈我又不知道如何解決，所以懇求大家討論並分享心得經驗，不要讓「有心人」捉柄開話匣，同時立此討論，也是要公示正聽，避免單方面聽憑其詞，遭有心人扭曲。－36.232.222.7（留言） 2012年9月18日 (二) 15:12 (UTC)

你前面提到的那個提議是我提出的，但我也實在沒有「藏私不報」，我在這提議中說了，解決的方法就是「在其後用括號翻譯成通用之話語。」我提此議的原因，使用方言或非通用之語言的不便之處，解決方法，在發起提議時，我均有所提及。或許是我口氣不對，以至於使閣下覺得在下在強人所難，在此我向閣下致以最深的歉意。——Langer Lee-本人所主編春社條目正在進行特色條目評選歡迎大家提出意見 2012年9月18日 (二) 15:37 (UTC)
你這有說像沒說似的，什麼叫「在其後用括號翻譯成通用之話語」？難道每個人都知道自己在用詞上哪個地方算是方言？那叫那些不知道分辨是不是方言的人該怎辦？你不要只把人家的話看一半，從你的回答就知道你還活在自己世界當中，我已經向你提出兩次相同的理由了，若不是你不懂，那就可能是忽視了，你所提出那套解決方法根本行不通，並不是所有人都知道什麼地方算方言而該被翻譯，萬一具有爭議之處，A君說算方言，B君說這是慣用詞而不算方言，C君說只存在某地使用而其它地方也有，只是少見，如此不就開始為了是不是方言而該不該被翻譯，開始爭個面紅耳赤，這有什麼意義嗎？假使你若沒誠意解決，那就請你不要來擾亂，不妨多等些時間，看看是否有其它人參與提出更好方法來。－36.232.216.101（留言） 2012年9月19日 (三) 13:44 (UTC)
你就是沒教人家怎麼做，只是拿出「在其後用括號翻譯成通用之話語」給人瞎猜謎，這就是解決問題只做一半，另一半就是後續的具體做法，這你就沒有做出來給大家參考，這邊就是我指控你所謂的「藏私不報」，但你可以保持你否認的權利，但只要你想混淆視聽，我還是可以站出來繼續對你指控。－36.232.216.101（留言） 2012年9月19日 (三) 13:49 (UTC)
請注意，我在原提議中一共拿出三個例子來舉例，除「杯葛」之外，其他兩個例子裡面出現的對話均全為粵語。我不認為一個人在編輯條目時，加入整句粵語或其他方言，卻不知這屬於方言。——Langer Lee-本人所主編春社條目正在進行特色條目評選歡迎大家提出意見 2012年9月19日 (三) 16:35 (UTC)
「在其後用括號翻譯成通用之話語」沒必要讓加入原話的人做。如果不知道哪些是方言哪些是通用的中文，就留著給其他中文好的人來做吧。不過「在其後用括號翻譯成通用之話語」是必要的。—Snorri（留言） 2012年9月19日 (三) 13:53 (UTC)

名稱

現在的{{style}}模板對格式手冊的諸子頁及相關頁僅分了四類，我對此感到使用上的不便，所以自己正在修改，如右所示。

Style 手冊
查 · 論 · 編

然而我遇到了一頗尷尬的事情。這個版本是以現在英文版的爲基礎的，第二類叫「Formatting」，似乎可譯作「格式」，可這個維基百科指引的名字叫「格式手冊」，格式下分內容、格式、圖像等，似不妥。

該怎麼辦？

百家姓之四 討論 2012年11月16日 (五) 04:35 (UTC)

應該把MOS的翻譯改掉……Liangent（留言） 2012年11月16日 (五) 07:30 (UTC)
怎麼改？百家姓之四 討論 2012年11月16日 (五) 07:55 (UTC)

叫「文字格式」不就好了。 --達師 － 218 － 372 2012年11月16日 (五) 11:21 (UTC)

那裡面還有一個Text formatting... Liangent（留言） 2012年11月16日 (五) 11:31 (UTC)
考慮到 CSS (Cascading Style Sheets) 被翻譯作「層疊樣式表」，似乎 Manual of Style 也可譯作「樣式手冊」？這個手冊的目的倒也就是使所有的條目擁有一致的外觀，用「樣式」我還能接受啦。百家姓之四 討論 2012年11月17日 (六) 09:18 (UTC)
text formatting稱「文字樣式」 --達師 － 218 － 372 2012年11月18日 (日) 16:48 (UTC)
而且就叫「格式」又能怎麼樣。 --達師 － 218 － 372 2012年11月18日 (日) 16:49 (UTC)
把「格式」「樣式」互換……我去查查詞典去。百家姓之四 討論 2012年11月19日 (一) 08:25 (UTC)
不要叫「Style手冊」，叫「格式規範」比較好——Sakamotosan 2012年11月19日 (一) 04:07 (UTC)
可是問題還是沒有解決啊。另外，那個「Style手冊」就是個佔位符 (placeholder)，絕不會是成品。百家姓之四 討論 2012年11月19日 (一) 08:25 (UTC)
字詞典、百科編篡中常用體例一詞--百無一用是書生 (☎) 2012年11月20日 (二) 02:13 (UTC)
體例不錯。--Gakmo（留言） 2012年11月20日 (二) 03:49 (UTC)
那麼所謂「凡例」又是什麼意思呢？ --達師 － 218 － 372 2012年11月20日 (二) 08:21 (UTC)
我覺得體例比較像是編寫守則、協助編者編寫，凡例比較像是用戶指南、協助讀者閱讀。見凡例的使用。我少讀書，不能給一個肯定的答覆。--Lakokat 2012年11月20日 (二) 09:39 (UTC)
凡例總是出現在書的開頭，有點General Guideline的意思，對思想內容也有涉及。作爲「凡」例，不會說得太細，而只會列出較根本的原則。只是個人感覺。百家姓之四 討論 2012年11月21日 (三) 04:47 (UTC)

關于格式手冊各頁面改用子頁面式命名的提議

理由如下：

  1. 格式手冊各分頁構成一個完整的中文維基百科格式手冊。
  2. 移動至子頁面可明確從屬關係。與各項關注度指引不同，格式手冊具有明確的從屬關係，讀者可以很方便地通過標題下方的連結返回父頁面。
  3. 利用鍵盤輸入斜槓比輸入兩個括號容易。
  4. 當初使用括號可能是參考英文維基百科的命名方式，而英文維基百科已經於2011年移動至子頁面，相關討論見RfC。

--達師 － 261 － 442 2013年1月24日 (四) 16:11 (UTC)

本來採用這種消歧義的方式就不對--百無一用是書生 (☎) 2013年1月25日 (五) 01:45 (UTC)
新命名才是正確的吧。--魔法少年愛德華★愛生活愛圓神愛蘿莉塔 2013年1月25日 (五) 04:05 (UTC)

已經進行了移動，連結暫時沒有進行清理（如果有維基人願意開AWB清理連結的話最好）。--達師 － 261 － 442 2013年2月1日 (五) 16:51 (UTC)

地區用詞的格式

Resolved
 – 已由User:Kuailong修復。 ——Nigel 2014年7月30日 (三) 10:21 (UTC)

相關連結均已遭刪除或移動，但未「重定向」，煩請修復，謹致上十二萬分的謝意。 by 浮游 --220.129.204.186（留言） 2014年7月28日 (一) 12:47 (UTC)

有關格式手冊

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Good afternoon（留言） 2014年9月7日 (日) 01:13 (UTC)。

Wikipedia:格式手冊#條目標題一節的例子中，「蘇維埃社會主義共和國聯盟（俄語：Союз Советских Социалистических Республик）」括號內的外文並沒有加粗，但在同頁「傳記」一節中，「史提芬·威廉·霍金（Stephen William Hawking）」中的外文又有加粗。在此詢問：導言首句中的外文加粗不加粗是否隨編者喜好？這樣又會不會導致條目格式不統一？謝謝關注。— lssrn45 | talk 2014年5月29日 (四) 06:50 (UTC)

我覺得都應該加粗，畢竟人家的語言才是正式名稱，我們的只是譯名。——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★貢獻 2014年5月29日 (四) 08:22 (UTC)
不贊成加粗，只中文加粗就可以了，畢竟這裡是中文維基；參考英文維基，序言章節的外文名不加粗（見en:MOS:FORLANG）。--Gakmo（留言） 2014年5月29日 (四) 10:13 (UTC)
Wikipedia:格式手冊/序言章節：「不要加粗外文名稱」，照這個來看，粗體的原意約寞應是用來顯示當前語言會用到的名稱，而不是用來彰顯名稱是否正式，再者，手冊反而叫人加粗非正式的中文別稱。不過就以中文版這邊的情況來看，大部份條目都有著加粗外文的習慣。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年5月29日 (四) 11:29 (UTC)--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年6月20日 (五) 08:21 (UTC)
在中文維基百科裡，中文就是高端大氣上檔次。我支持外文不加粗。--Gqqnb（留言） 2014年5月29日 (四) 16:50 (UTC)
好吧。——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★貢獻 2014年5月30日 (五) 02:08 (UTC)
這問題長久以來一直都很讓我困擾。個人對於外文要不要加粗體沒有偏向，只希望能有個一統的規則以便遵循之。--泅水大象™ 訐譙☎ 2014年5月30日 (五) 03:17 (UTC)
確實，但是方針本身的內容就有矛盾啊，要不要修改？——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★貢獻 2014年5月30日 (五) 03:32 (UTC)
支持外文加粗。--Fxqf（留言） 2014年5月30日 (五) 09:01 (UTC)
事情變複雜了，這看似是要繼續深入討論和投票的情況？— lssrn45 | talk 2014年5月30日 (五) 10:24 (UTC)
說起矛盾，怎麼WP:GTL的導言跟WP:LEAD也矛盾了?--128.199.197.27（留言） 2014年6月28日 (六) 14:14 (UTC)
反對外文加粗體，不加粗體看起來容易區分中文和外文。--HanasakiMomoko（留言） 2014年5月31日 (六) 08:27 (UTC)
可參考《大英百科全書》做法：Prussia、USSR。Lovewhatyoudo ® 2014年5月31日 (六) 15:40 (UTC)
維基百科是把外文以補註形式放在括弧內，但大英百科全書則是把外文都融在正文裏，完全不同的狀況很難並論比較。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年5月31日 (六) 16:06 (UTC)
補充一下，有些瀏覽器的字型粗體和不粗體看起來差不多樣，所以其他名字應該還要用引號包住。--HanasakiMomoko（留言） 2014年7月5日 (六) 14:15 (UTC)

謝謝Lssrn45提出討論。從上面的討論，較多用戶支持外文名字不加粗。據此，先把維基百科:格式手冊中不協調的地方修正。長遠是提請社群通過Wikipedia:格式手冊/序言章節為指引。--Gakmo（留言） 2014年6月7日 (六) 08:14 (UTC)

我認為兩種做法均無傷大雅。若然社群必須選擇其中一種作為標準的話，必須通過大量編輯將條目的外文加粗或不加粗，恐怕相當費時。—AT 2014年6月8日 (日) 18:18 (UTC)
我覺得即使通過不加粗，也不需要一次過把全部條目都改掉，而是看見舊條目有加粗就改，寫新條目時則不加粗這樣的做法。— lssrn45 | talk 2014年6月9日 (一) 05:55 (UTC)
加粗的目的是為了標註條目主題的同義詞。外文名其實也是同義詞的一類，加粗並沒有什麼不妥。en那邊貌似都是加粗的吧。烏拉跨氪 2014年6月9日 (一) 16:57 (UTC)
同義詞不同於外文名；英文維基中，同義詞加粗（見en:MOS:BOLDSYN）、外文名不加粗（見en:MOS:FORLANG）。--Gakmo（留言） 2014年6月10日 (二) 04:39 (UTC)

討論有結果麼？ --Kovl（留言） 2014年10月4日 (六) 16:06 (UTC)

有關格式手冊（續）

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針/存檔/2014年10月。

接續較早前討論：Wikipedia:互助客棧/方針/存檔/2013年5月#請求討論並且將維基百科:版面指南升級成為指引

重訂Wikipedia:版面指南

  • 承上提的矛盾：原來該次討論嚴重出錯，同時與WP:DAB、WP:頂注、WP:LEAD發生矛盾。該次討論竟然說沒發現消歧義要放最頂的理據，事實上那三頁和它們的英文版都有說明。而且還在規則裏寫是方便TW工具，事實上TW是會把維護模板放在歧義後面的。顯然地那次討論根本未把實踐、考察對應和現有規則做妥。如此疏忽原則上理應視為無效並回GTL到非正式狀態且重議，因為那次討論開始沒久便出錯了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年6月29日 (日) 19:44 (UTC)
    • 既然過程有錯誤就當然不能作為正式指引。--HanasakiMomoko（留言） 2014年7月5日 (六) 14:15 (UTC)
    • (＋)支持，建議將維基百科:版面指南重新討論，而且該次討論未有張貼公告，因此無效，應先退回指引性質，從長計議。Stewart~惡龍 2014年7月7日 (一) 16:12 (UTC)
      　後來加插的討論：
      • 按照「該次討論未有張貼公告，因此無效」的邏輯，今次討論至今（7月28日）都是「未有張貼公告」，就算從7月7日開始計，都已經超過20日仍未有人在「Template:Bulletin」張貼公告。--Mewaqua（留言） 2014年7月28日 (一) 18:05 (UTC)
        • 經查[16]雖然公告「[討論] 歡迎參與有關格式版面的討論及有關用戶頁的討論。」，但是公告初時（2014年6月21日）本處只是討論外文名稱應否加粗體，而關於條目章節重新排序的重大變動在當時還未有人在此提出。--Mewaqua（留言） 2014年7月28日 (一) 19:19 (UTC)
        • 公告與否其實還是其次，敝當然不能單憑因為沒有公告來宣告原討論無效，但問題亦在於原討論無公告之餘還要過程出錯，訂立了矛盾和技術不能操作的條例出來，導致無法完全執行，這才是致命傷。--街燈電箱150號
          • 1. 你最初只是說「該次討論竟然說沒發現消歧義要放最頂的理據」，那也是「消歧義」位置的問題，卻乘機順便把「參見」章節位置都一併翻案。你的做法就像某次討論談了十件事，只要其中一件事「討論程序有錯」，其它九件事都會變成無效，這樣有點像wikilawyering。 2. 英文維基百科都是See also放在Notes之前，這一點何以見得「導致無法完全執行」、「致命傷」？對中文維基百科來說，就算你最初提出的理據成立，那也是「消歧義」位置的相關指引「無法執行」，而不是Wikipedia:版面指南其它段落都「無法執行」。--Mewaqua（留言） 2014年9月24日 (三) 13:27 (UTC)
            • 請留意我宣告的是原討論在有錯誤的情況下將整份訂立成正式指引，故原討論無效而退至非正式狀態，而不是廢除這個指引。訂立一條指引，過程當然要整體來看有效性以達至可以完全執行，原討論明顯跳步（即過程出錯的致命傷），加上別的管理員也認為有此必要，所以我不認為宣告無效而後重新檢討的做法有何不妥（事實上其他部份有無依照程序其實也成疑問，否則到了現在討論不會改了那麼多東西）。還有，修訂當然就要趁一次過改，分開幾念佰次改本來就應盡量避免；如果這次順便討論章節排序等其他東西是不妥的話，那麼原討論也一樣不妥——原討論是要確認排序，結果卻中途順便加了些模板規定。--街燈電箱150號 2014年9月29日 (一) 03:31 (UTC)
              • 按照你的說法，以後任何討論只要有人在某時某刻說錯了一件事，別人就可以據此推翻整個討論。如此類推，Wikipedia:管理員解任投票/烏拉跨氪因為有某些「濫權」指控缺乏理據，用你的話就是「原討論在有錯誤的情況下」、「原討論無效」，所以未開始投票就已經無效。--Mewaqua（留言） 2014年9月30日 (二) 02:27 (UTC)
                • 我認為cdip150並無不妥，其他部分的有效性從舊討論中也存疑，宣告無效再重新審視起碼可以保障對整體的有效性；更重要的是cdip150是有等待過其他人的意見才去做，而不是一發現出錯就二話不說馬上宣告無效。在出錯與有效性存疑這兩種狀況並存下，且當時得到他人首肯，他的做法仍是合理的，而不是什麼單純的憑一個錯就直接翻倒的官司。而儘管其他部分有效，也不代表不能透過重新討論以得到更好的方案出來。對於那個解任案，我想就算最終是過半支持，的確可以預視到也會有人質疑有效性。--Whhalbert（留言） 2014年10月6日 (一) 15:16 (UTC)
根據上面的討論，由於當時的討論明顯採用了不存在的理由來訂立，並造成與其他指引矛盾，再者該討論從頭到尾未出過公告來確保共識與無誤，故現已把WP:GTL退回至先前的非正式的準指引狀態，接下來重新討論。
為解決此矛盾，提議先在導言元素將消歧義模板移到最前，因為這才是符合TW工具維護，而且WP:LS已經說明原因，再者消歧義現已不接noteTA轉換，所以也無放於noteTA後面的需要。另外，個人亦提議在附錄排序將相關條目移到導航模板之前，縱使這做法有別於大部份條目的習慣，但認為這有利於總覽所有內部連結，應該要改變習慣。--街燈電箱150號 2014年7月7日 (一) 17:06 (UTC)
(＋)同意，理應如此。Stewart~惡龍 2014年7月7日 (一) 17:09 (UTC)
以本人非常淺薄的學術經驗，學術上正文之後會是註解吧，然後是參考資料。--Whhalbert（留言） 2014年7月12日 (六) 14:45 (UTC)
說起學術，記得做論文時教授給的講義，在同一本刊物的相關主題應該放在參考資料後面的伸展閱讀，所以(＋)同意上面改法。還有建議作品列表不定位置，像魔法少女題目，自由發揮。--HanasakiMomoko（留言） 2014年7月12日 (六) 15:49 (UTC)
(－)反對：同之前對於「參見」位置的討論，其他我沒意見（喔……有人一下說要實踐，但他提到「參見」位置是叫絕大部分的人更改習慣）。--KOKUYO（留言） 2014年7月12日 (六) 16:06 (UTC)
他說的實踐應該是指把規則在維基頁面實際操作一次來看是不是可行，跟改習慣完全不對題吧。--113.52.126.158（留言） 2014年7月19日 (六) 15:40 (UTC)
  • 那次討論總是說習慣，除了習慣也又習慣，不知道還算啥理由。推英文版規則的話，那也要說說日本版的規則，參見章節都是在腳註和參考文獻的下面。--162.252.85.172（留言） 2014年7月12日 (六) 18:30 (UTC)
  • 看過Wikipedia:互助客棧/方針/存檔/2014年3月#分段當時的討論，個人認為把參見放於參考文獻之後的做法較有理據；而反方則一直強調習慣，但這種「習慣」又是出於何處呢？既然上面提到是學界有採用的方法，(＋)同意這個提議和當時的理由--Ws227（留言） 2014年7月14日 (一) 16:11 (UTC)
    • 喔……學界報告的習慣要我們網頁後面列出網址以及在最後後頭放上附錄，所以要準備改cite web和增加附錄了？學術論文的寫法等同於百科全書的寫法、格式？--KOKUYO（留言） 2014年7月20日 (日) 14:56 (UTC)
      • {{cite web}}會按使用者需要時在狀態顯示網址，而列印版本上也會自動在旁邊加網址（如此條目的列印版），最終還是會有把網址秀出的作用，即本身也已符合學術做法。還有現在討論中的東西都已經是在最後附錄，您還要加甚麼附錄？--街燈電箱150號 2014年7月27日 (日) 03:37 (UTC)
        • 長見識了……我說的附錄是指那些其他文件內容、資料報告等等。還有原來你有時候是用IP編輯……--KOKUYO（留言） 2014年7月28日 (一) 14:10 (UTC)
          • 這個叫「附件」吧……其功能該已由姊妹模板達成，其他附帶文檔（在共享資源）和資料報告原文（在文庫）等都放在其他計劃，而姊妹模板正正就是放在最後的，基本迎合了學術對於附件放最後的做法。（用了122.100是隱私模式造成的，我懶得重新載入所以在留言後手動畫自己的押算了）--街燈電箱150號 2014年9月1日 (一) 09:27 (UTC)
  • 略略看了這個討論，雖然習慣不是這樣，不過習非成是也不是好事。我(＋)支持這個提議。不過，恕我多嘴，弱弱一問：互助客棧很多討論都是沒有存檔的，那麼由這些討論生成的方針準則，是否也是無效？--春卷柯南夫子 ( 論功行賞 ) 2014年7月18日 (五) 14:45 (UTC)
    • 「簡單地從既有慣例發展而出……逐漸演化出的常規或慣例。」等類似內容大概只是被看看笑笑而已……--KOKUYO（留言） 2014年7月20日 (日) 14:59 (UTC)
      • 你引用的方針，全句是「這些共識可以透過對複雜難題的公開辯論或簡單地從既有慣例發展而出...」，中間的「或」已表示是二擇其一，即不是強制要按慣例。還有「逐漸演化出的常規或慣例...」也只是三種可選方式的其中一種，而已經說到慣例有問題，自然不應被選用，而應藉助討論商議。--春卷柯南夫子 ( 論功行賞 ) 2014年7月21日 (一) 15:03 (UTC)
        • 習慣延伸的方針是要讓人得以方便遵從，另外我不認為在當前特色/優良條目中僅有10%左右的條目寫法，可以由一個非百科全書的格式指引決定之。同之前所述，「參見」段落放在條目內容後方、參考資料前方有其論述存在，甚至可能還比單純所謂為了「推廣添加參考資料」這類假設性目的理由還可靠。甚至到了現在，連討論該格式指引是否為單一教授見解、該內容的「延伸閱讀」是否可以直接等同「參見/相關條目」，以及是否學術論文的格式即可直接適用以百科全書寫法為主的維基百科討論都沒有。--KOKUYO（留言） 2014年7月21日 (一) 16:07 (UTC)
          • 若要以習慣延伸方針，前提是要是個好習慣，而不是不管好壞都要這樣處理，即使有90%條目是這樣寫也不代表證明是正確習慣。還有把相關主題放前面的做法現在也都不再是正式指引，甚至連現實世界也還未見到有用。而且至少正文後接註腳參考的做法絕對不會是某一個教授的見解，以我看過的學術刊物都是這樣。而所謂的論述，看過閣下之前的大論，其實也是閣下對於相關條目的假設性想法，並不見得一定可靠。反觀現在提議的新做法，其實不須看他的最後幾句假設，就只單純按他對各類型的本質進行鋪排，都較有紋理。--Whhalbert（留言） 2014年7月27日 (日) 03:01 (UTC)
            • 首先一個要大眾遵循的規則竟然可以造成90%的條目違反也算不上好法案了吧，另外英語維基百科也提到「If policy and/or guideline pages directly conflict, one or more pages need to be revised to resolve the conflict so that all of the conflicting pages accurately reflect the community's actual practices and best advice.」。再者我先前已經提過基於後幾者性質上的分類所以認為現在的方式並沒有問題，而數個其他語言的維基百科也多採取這類作法。--KOKUYO（留言） 2014年7月28日 (一) 13:17 (UTC)
              • 難道要說因為大多數條目都是加粗外語，所以格式手冊所定的不加粗外語例是不好的嗎？多少人（或其他語言版本）怎樣做與一個法案好不好是根本沒有關係的。也先不講英文版能不能用在中文版，但是您所說的那個規條明明就是在幾個正式規則出現矛盾的時候才適用，而這個提議根本不屬於那種情況，而且舊有做法也談不上最好，怎能應用？而您之前對於相關條目所謂的「與該條目有著密切關係的維基百科條目，主要功能是在讀者讀完整篇條目後提供之後可能會有興趣繼續瀏覽的條目」性質也其實是你的假設，基於這個性質來分類明顯就有問題，反而他純粹說註腳針對內文、延伸外連是針對主題但內文沒有的東西、相關條目不針對內文和主題，這樣來分類則才合理。--Whhalbert（留言） 2014年8月15日 (五) 07:11 (UTC)
            • 英文維基百科就不是「現實世界」？哪些學術刊物會有「相關條目」、「導航模板」的東西？ --Mewaqua（留言） 2014年7月27日 (日) 05:45 (UTC)
維基百科採用論文格式其實早有說法，註解參考延伸相關等等其實都是論文才會有的東西，而在傳統百科全書卻是沒有的，例如大英百科全書的A條目。換句話說這裡名義雖為百科全書，但事實都是論文寫法。另外還須注意參見條目可能遭受內連破壞的問題而需要頁底巡查。--162.252.85.172（留言） 2014年7月27日 (日) 03:10 (UTC)
請注意原話為「雖然維基百科為了提高可信度而引入了論文的寫作方式」，請問「相關條目」的位置跟可信度有何關聯。--KOKUYO（留言） 2014年7月28日 (一) 13:12 (UTC)
當然有關，要有論文的可信度，連排序也要跟隨才能讓人覺得你是要追隨論文那樣的可信。一邊說要跟論文但一邊自己做一個跟論文不同的樣式，人家不會覺得你是像論文，沒了論文那樣的可信。—以上未簽名的留言由96.31.64.186（對話｜貢獻）加入。
敝現暫僅按照上面多數之意見進行草案修例，另外加入一些未提到的模板放位和避免矛盾而作的防範訂正等，請眾過目。--街燈電箱150號 2014年7月27日 (日) 03:37 (UTC)
我們這邊都還沒討論完就急著改位置了啊……還是要正面思考至少還有1個匈牙利語維基百科跟我們採取同樣的格式？--KOKUYO（留言） 2014年7月28日 (一) 13:11 (UTC)
「相關條目」/「參見」/「參看」有時的作用是作為條目內文的延續，為了避免冗餘重複或頁面過長而不在本頁面詳寫，例如「美國總統」與「美國總統選舉」、「美國總統列表」的關係，關連性一般遠大於導航模板列出的「美洲各國國家元首」之類，「相關條目」放在Notes和References之上方有其道理，甚至正文章節內有時也有{{See also}}連結相關條目。--Mewaqua（留言） 2014年7月28日 (一) 18:10 (UTC)
{{see also}}等內文連結模板和相關條目章節不能相提並論，要是它們功能一樣的話那何必還有相關條目？通通都用內文模板不就行了？是故敝人認為，內文連結模板是條目內文的延續這沒錯，但相關條目頂多就是內容的主題延續而不是內文；事實上「相關條目部分的內部連結與條目內容沒有直接關係」，您要正文有直接關係去延續倒該是用{{see also}}/{{main}}之類的模板，而不是相關條目；簡單說就是{{see also}}涉及主題事物和正文，而相關條目則祇涉及主題事物而不及正文；這好比在亞馬喇前地條目，在那裏發生的2000年澳門大賽車衝出賽道意外因為正文無提及而又無導航所以才迫住要開相關條目，而正文裏有簡介紀念人亞馬喇故祇在正文用main連結，而不是把相關內部連結不理三七廿一都放在相關條目裏。而與其說有時作用，不如說必然的關係，備註一定直接由正文伸出，而參考資料一定是直接支持正文，要比正文關係怎麼都是註腳大於相關條目。而美國總統這例其實已不恰當，其相關條目悉數已由導航模板提供，而美國總統列表更甚至在文章裏用了main，這個參見顯然並非必要的。（「一般情況下這類條目的選擇仍不應該重複出現在條目文章內或者是導航模板之中」，至少看不出此況有何特別？）故在我而言，相關條目與導航模板的關係高低僅祇一紙之隔。所以相關條目放上面反而無甚道理了。另上面說其他版本有採用，但這並不是絕對証明，至少敝人不會搬「日文版是放下面所以中文版也要放下面」來說，正如Whhalbert所說並無關係。--街燈電箱150號 2014年9月1日 (一) 09:27 (UTC)
Shizhao於2013年9月25日 (三) 12:30 (UTC)說過：「而且參見位置可以有一些對參見條目簡短的一句話介紹，或一些簡單列表式內容，而這些內容可能也需要參考來源的支持。因此必然需要放到參考和註腳之前。」以「種族隔離」條目的2014年8月31日 (日) 06:14‎ 版本為例，沒有附加說明的話，我根本不明白「白澳政策」至「打破沉默組織（以色列）」這些條目跟種族隔離有何關連，而如果這些內部連結後面有附加說明，就可能需要添加參考文獻支持宣稱，則這個條目的「參見」就不適宜放在「參考資料」後面。--Mewaqua（留言） 2014年9月7日 (日) 04:08 (UTC)
他提出的做法當時我已經解釋過為何不恰當，沒錯在種族隔離可以加說明，但不用做來源，而是在目標參見條目裏的內文再詳述該關係，然後才在該內文做來源，因為表明該關係的責任在目標參見條目，而不是引它出來的主條目，是故祇有目標相關條目才要舉証。這跟序言簡介不用列來源有著類似道理。--街燈電箱150號 2014年9月7日 (日) 09:29 (UTC)
序言「不用提供來源」不代表「不能提供來源」，而在理想狀況也是因為後方有來源足以應證才可以免除。然後同先前解釋無數遍的論點，相關條目段落中的條目並非一定跟該條目有絕對從屬關係，可能是在實際使用上的經常比較的關係，例如颶風黛安中所提到的颶風艾琳 (2011年)。而相關條目需要列來源可能是因為編者認為可以提供將某條目列入該段落的理據，而該理由不方便以在這兩篇條目的文章中進行統整。--KOKUYO（留言） 2014年9月13日 (六) 12:37 (UTC)
要是用得到某個來源，（之前也說過）最理想應當至少在其一條目整合得到，祇用在相關條目而竟不方便把其理由整在任一正文的話，要麼就是該關係的重要性本身都有問題，要麼就是正文本身就有缺憾而令到本來可用的來源資料沒寫進去。要是列出的「理由」是如此重要為何又會「不方便」在正文裏表達？哪怕在正文裏祇值半絲的句子。（颶風黛安和颶風艾琳 (2011年)，其實在正文弄個比較表格比起做相關條目來得更好）--街燈電箱150號 2014年9月13日 (六) 14:39 (UTC)
User:Cdip150上面提到的「而美國總統這例其實已不恰當，其相關條目悉數已由導航模板提供」已經有錯，拿2014年9月24日 (三) 14:04 (UTC)見到的版本來說，在導航模板就找不到美國國務卿，如果其它條目是用上了像{{文化大革命}}之類的超大導航模板，讀者就更難尋找導航模板內的「相關條目」。（其實這跟「參見」章節的位置無關。）--Mewaqua（留言） 2014年9月24日 (三) 14:04 (UTC)
噢，看漏了這個，不過無關痛癢，相關條目本來也是一種導航功能，即使撇開不應重複不談，有關內部連結都應該是抽在導航模板上面才顯得它們同是導航作用。而且對應下面另位用戶的意見，要是我想了解多些關於總統的資訊，都會是先想看白宮網站多於想看一個離開了主題中心的美國國務卿條目，因為白宮網站比起美國國務卿較有關美國總統主題的資訊。--街燈電箱150號 2014年9月29日 (一) 03:31 (UTC)
使用說明:腳註訂明<ref>只是用於正文內容和補充內容，在參見用<ref>是不符合用法。另外{{link_GA}}、{{link_FA}}已被wikidata代替，將會刪除，請從規則裡移除這兩個模版。還有建議移動本頁至格式手冊的子頁面，因為是格式手冊的一部分。--162.252.85.172（留言） 2014年9月19日 (五) 02:55 (UTC)
延伸閱讀外部連結和相關節目都是給人看多些資訊，所以應該放在一起，加上我之前說的冧莊例子，外連結比相關節目更親密，所以贊成這個。--Maccomcre（留言） 2014年9月17日 (三) 08:38 (UTC)

最後公示

較早前已按上述意見再修改。另由於已接近三個月強制存檔期，而本次討論目前有絕大多數意見贊同本案，故現作最後公示一週，期內如仍絕多贊同者，將按絕大多數原則將WP:GTL成為正式指引。--街燈電箱150號 2014年 9月22日 04:18 (UTC)

好吧，現在我真的來再確認上述公示是我發的，故理應不再構成影響。--街燈電箱150號 20‎14年9月23日 (二) 07:40 (UTC)

身為管理員兼用戶查核員的用戶，一面就來個「最後7天公示」，另一面就用IP靜悄悄修改Wikipedia:互助客棧/方針/header[20]，導致「目錄」本來可見的「重訂Wikipedia:版面指南的章節排序​​」突然從目錄裡消失，要把本來的「=== 重訂[[:Wikipedia:版面指南]]的章節排序​​===」修改才可展示。（IP編輯的時間就在我把「重訂WP:GTL」改成「重訂Wikipedia:版面指南的章節排序」之後不久，雖然我不是用戶查核員，從我可以查看到的東西判斷，如果是其他無關者編輯也太過巧合了。）--Mewaqua（留言） 2014年9月24日 (三) 14:18 (UTC)
不好意思，累到街燈電箱了，我是無關者，我縮了目錄的子章節是因為先前看到有人反覆搞投票，搞亂了目錄，想了很久才縮一下看某人會不會停止，想不到引起了這裡爭議，那我就先回復一下，非常對不起。--113.52.126.163（留言） 2014年9月24日 (三) 14:32 (UTC)
謝謝你的回應。--Mewaqua（留言） 2014年9月24日 (三) 14:39 (UTC)
食住花生等睇戲，就等著看其他用戶突然發覺他們一向習慣的章節排序被你判定為「不當」，再加上澳洲IP人肉機器人長年累月不停刷編輯修改章節排序，他們會有甚麼反應？或者就如1983年大西洋颶風季那樣。--Mewaqua（留言） 2014年9月24日 (三) 03:16 (UTC)
要是舉風暴例的話，其實近年的太平洋颱風條目基本上都不是您這個習慣，就以這個導航模板裏面的條目為例都是先放註腳（雖然還是跟我提出的有些分別和濫加外連），那麼是否這幾年我又要準備花生，他朝某日有人肉機器人把全部參見移上，看看那邊又會有甚麼反應？您舉的回退例子我祇能視他按本子辦事，未必代表到些甚麼。人肉機器者，您祇能說他變相繞過正式機器人規則，但不等於他所做的內容絕對不當，祇可以說是用錯方法，但不能說他排板的理念錯誤。--街燈電箱150號 2014年9月29日 (一) 03:31 (UTC)

完成，移至格式手冊之下，成為正式指引。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2014年9月29日 (一) 20:09 (UTC)

本人對參見放在參考資料下面沒有看法，但本人(－)反對現狀WP:LAYOUT中要求參見置於延伸閱讀和外部連結之下的做法。首先參見實際上是延伸閱讀的一種，而不是導航，導航是分類的呈現。其次參見一般只有很少幾個條目，放在最後的話排版會變得極為奇怪。 --達師 - 277 - 465 2014年9月30日 (二) 17:19 (UTC)

啊……達師兄您這個意見正好與這個牴觸個正著——參見也是導航。當然我認同參見是延伸閱讀的一種（按上面另位用戶提供的真實世界例子），所以敝認為參見同時具有兩種功效，而放在延伸和導航之間。至於奇怪與否我就覺得很難結論，始終感覺這回事屬各人的主觀評鑑。但坦白說，如果維基沒有導航模板的話，延伸外連參見這三個的順序互換無所謂。--街燈電箱150號 2014年10月10日 20:18 (UTC)

既然新排序有實物採用，而且能配合其他格式規則，所以(＋)支持--18164（留言） 2014 年10月16日 (四) 15:46 (UTC)

老討論：關於空格

我是挖墳的。這個空格問題實際上可以考慮在全局 CSS 中加一個text-autospace:ideograph-alpha;屬性，暫時地在 Internet Explorer 中解決。（這似乎還只是一個 IE 的專有屬性… --Arthur2e5 更改·工具 2014年9月24日 (三) 01:44 (UTC)

爭執

log：special:diff/33603731

220.136.18.14 (討論 | 貢獻 | whois | 封(記錄))

本主題或以下段落文字，移動自Wikipedia:當前的破壞。執行者：Jimmy-bot（留言） 2014年12月14日 (日) 08:42 (UTC)。

Wikipedia:格式手冊，請建立「共識決」副署制度！！

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

log：special:diff/33747709

  1. “1990年代”可寫成“20世紀90年代”，但不简化成“90年代”或“九Ｏ年代”。 其中，「20世紀90年代」是人為添加，欠缺相關共識討論決議紀錄。
  2. 資料如次，special:diff/9548454由Special:用戶貢獻/Philinwiki編輯，起因於special:diff/9519165「Wikipedia:互助客棧/求助」中Linforest（留言Special:用戶貢獻/Linforest）君的詢問。
  • 建議：
  1. 若對現行已大略修改的「Wikipedia:格式手冊」版本，沒有疑義，建議於2014年12月15日前完成共識表決副署，紀錄備查。（否則，Wikipedia:格式手冊高掛屬於Wikipedia:方針與指引，豈非笑話一則乎？！）
  2. Wikipedia:格式手冊共識表決，可考慮每年3次或每3個月進行1次投票表決，若有無增減，均請公告，並紀錄備查。
  3. Wikipedia:格式手冊共識決議紀錄，可考慮「專一條目」（如log檔，避免與Wikipedia:格式手冊各分立討論頁資料相混，可兼當各分立討論頁的索引紀錄檔）統一管理，並作為參考資料於相關討論頁內，也許如「存檔」或單一內鏈，便利查閱。 --114.45.32.133（留言） 2014年12月12日 (五) 04:27 (UTC) (半·瓶水)
你是要改Wikipedia:格式手冊/日期和數字才對吧。--113.52.126.43（留言） 2014年12月16日 (二) 12:57 (UTC)
改什麼？！我的目的是Wikipedia:格式手冊等所屬內容已多次異動，但是，距離其上一回共識表決有一段時間，採用包裹表決背書（而非逐一表決，畢竟，也已使用一段時間有餘），以符合其Wikipedia:方針與指引身份而已。 --114.45.47.216（留言） 2014年12月17日 (三) 10:14 (UTC)

補充Wikipedia:格式手冊

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

提案

設置Wikipedia:格式手冊的「其他」章節，並整合原來「不要花俏華麗」的說明。相應內容在en:Wikipedia:Manual_of_Style#Miscellaneous。—RalfX（ἀναγνώρισις） 2015年3月16日 (一) 10:49 (UTC)

「Wikipedia:格式手冊#其他」補充內容：

==其他==

;===不要花俏華麗===

捷徑：
WP:MARKUP
MOS:MARKUP

最簡單的標記方式通常是最利於編輯、最易於理解、以及最可預料的辦法。標記可能在不同瀏覽器顯示有所落差，不應該假定所輸入的代碼在顯示時保證會有預期效果。格式代碼越單純，顯示、編輯、與維護都會變得更容易。建立有用的百科全書是我們的首要目的，但保持編輯和維護容易是第二重要任務。

謹慎使用HTML和CSS標記語法；尤其不要使用CSS的float或line-height屬性，因為在部分瀏覽器使用大字體時這會弄壞呈現結果。真的有必要的情況下才使用HTML代碼。

HTML字元實體有時比可能在編輯模式下不易辨識的等效Unicode字元更合適。例如&Alpha;可被理解，但Α（希臘字母α的大寫形式）可能就不是很好識別。

===格式問題===
參見：Wikipedia:格式手冊/文字格式#字體大小

字體大小、空格和顏色（參見下列的 § 顏色）的修改是攸關維基百科全站CSS的議題，並應該僅保留給特殊情況。

通常情況下，使用訂製的字體樣式將：

  • 減損一致性，文本將不再看起來整齊劃一；
  • 降低可用性，可能使用戶的自訂樣式表（為了親和力之類理由）無法蓋過設定，並可能帶給使用不同面板的色盲用戶不方便；以及
  • 造成爭議，其他編者可能不同意所選擇的樣式。

在條目文本之外，不同的字體大小經常套用在導航模板、信息框、表格（尤其是較大的）、以及一些其他不可替代的文字（如表格標題）。指定「相對」字體大小（例如CSS樣式font-size: 90%）比「絕對」數值（像是font-size: 8pt）來得好。

====顏色====
捷徑：
WP:COLOR
MOS:COLOR
主頁面：Wikipedia:格式手冊/親和力#顏色

所有訊息應該顯見。不要只為了突顯某些文字而標示顏色：這可能使色盲人士無法辨識。黑白列印輸出也是一樣，早期較少顏色的電腦顯示器或黑白顯示器（早期PDA和行動電話）無法表現出這種區別。

應該選擇最普遍色盲(紅綠色盲）也能夠分辨的顏色，例如栗色和鴨綠色，並另外標示出字體改變的差異或其他含意（maroon and alternative font face, teal）。避免在文本和背景使用低對比的顏色。使用Wickline瀏覽頁面可以幫助選擇合適的顏色。參見色碼（英語：Color code）。

除了視覺親和力問題之外，在表格僅使用顏色為屬性編譯（例如金銀銅牌成績）而不用可排序欄位，讓強力的可排序Wiki表格形同無物。即使讀者顏色視覺未受損，過度的表格項目背景陰影妨礙了維基連結的可讀性和可辨識性。背景顏色應該只是一種輔助視覺提示，且應該是隱約的（考慮較輕淡、較隱晦的淡彩（英語：pastel (color)）），而不是顯眼的亮點。

===滾動列表與摺疊元素===
捷徑：
WP:SCROLL
WP:COLLAPSE
MOS:SCROLL
MOS:COLLAPSE
參見：Wikipedia:格式手冊/親和力#CSS與JavaScript限制

滾動列表和可摺疊元素不應該隱蔽條目內容，包括文獻列表、圖像展示或說明文字。尤其不應該用來隱蔽掃興內容（參見Wikipedia:劇透內容）。被摺疊的「章節」或「單元」或許可以改用表格以整合本文與導航模板所涵蓋的訊息。注意當使用滾動列表或可摺疊的內容時，內容仍然可能會在不支援JavaScript或CSS的設備上可見。

===隱藏註釋===
捷徑：
WP:COMMENT
「WP:COMMENT」和「WP:COMMENTARY」均重定向至此。關於與這些名稱相似的其它條目，分別詳見「WP:COMMENT (消歧義)」和「WP:COMMENTARY (消歧義)」。
主頁面：Help:隱藏註釋

有些編者會在條目內文中使用隱藏註釋和其他編者溝通。這些註釋僅於wiki原始碼和VisualEditor可見；閱讀模式下是不會出現的。

隱藏註釋可以幫助標註問題或留下相關說明，比在討論頁提出問題更方便。然而這種方式應該謹慎使用，因為隱藏註釋會弄亂原始碼而不利其他編者。檢查你的隱藏註釋不會造成任何格式變化，例如在閱讀模式帶入一些空白。

要留下隱藏註釋，把你打算只給編者看的文字用代碼<!--和-->圈起。例如：<nowiki><!--變更此章節標題時，請同時更改相關頁面的連結--></nowiki>

討論

(－)反對：大量內容與已獲共識的WP:格式手冊/文字格式內容衝突。和目前的{{ilh}}默認樣式也衝突。以及不要把多個平行提案整合為一個。 --達師 - 318 - 527 2015年3月18日 (三) 05:58 (UTC)
還有連skin都不翻成中文？ --達師 - 318 - 527 2015年3月18日 (三) 06:04 (UTC)
還有，WP:TLDR，每次提案都搞這麼長（還拿框子框起來），結果就是誰都不想討論，真的是「很容易通過」啊。 --達師 - 318 - 527 2015年3月18日 (三) 06:13 (UTC)
有意見就說，不贊同就反駁，被擋的提案不會過。也不是一兩年的新人了，就事論事。隱藏起來沒什麼人看，攤開來以免又「不小心」過了之後被翻臉。這只是en:WP:MOS的「一小節」內容，實際只有原本的1小小節加上4小小節的補充說明。
Wikipedia:格式手冊/文字格式只有「粗體、斜體、不要過度強調、下劃線、顏色及內聯圖像」，哪些「大量內容」和WP:MOSTEXT衝突請舉出。
「格式問題」在講避免訂製樣式；「顏色」講的是不要用顏色突顯文字，如果需要使用顏色應該選擇色盲人士也容易分辨的。不和WP:格式手冊/文字格式、{{ilh}}衝突。真的要說反而是{{ilh}}違背了WP:MOSTEXT的規定。
「滾動列表與摺疊元素」講不要隱蔽條目，「隱藏註釋」就是項解說而已。skin的中文詞都半斤八兩就是。—RalfX（ἀναγνώρισις） 2015年3月18日 (三) 11:15 (UTC)
en的方針指引文本普遍過長，即便一小段，不分點分段討論也很難討論充分，你先前的提案也是如此。在普遍過長的情況下WP:MOS應當對子頁面系統善加利用以改善其內容組織，而不是試圖再往主頁面里加子頁面覆蓋的東西。
提案中禁止文字染色，WP:MOSTEXT允許信息框中文字染色，而後者是有共識通過的；{{ilh}}默認樣式是討論了很多次之後，投票通過的。中文維基不是英文維基中文版，你的提案不管是自己寫的還是翻譯的都只是提案。是你的違背了已有共識，而不是已有共識違背你的提案。同時WP:MOSTEXT沒有你連結的兩個章節。需要特別指出的是：本地的WP:MOSTEXT根本不是參照英文版編寫的，現在再從英文版整個引入相關內容是很不合理的。
說到底「不要花俏華麗」是從讀者和審閱者的角度歸納，不利於編者閱讀，而WP:MOS首先是給編者的，因此順便(－)反對這種段落劃分方式。
摺疊的討論情況和其他內容未討論的情況完全不同，請納入下面的提案或者另立提案單獨添加。
作為不可見項目，「隱藏注釋」不應受MOS管理。
--達師 - 318 - 527 2015年3月19日 (四) 02:18 (UTC)
解說跟提醒慎用要說成是管理。{{ilh}}的樣式既然投票通過，那就把WP:MOSTEXT寫成沒有矛盾啊。「顏色」在講不要濫用顏色，以及選用顏色時挑選對色盲友善的，不是單純的「禁止/可以」這種二元論。—RalfX（ἀναγνώρισις） 2015年3月20日 (五) 13:48 (UTC)
要改的是你的提案不是WP:MOSTEXT。即便想把WP:MOSTEXT一併改了，也是先納入你的提案。 --達師 - 318 - 527 2015年3月21日 (六) 10:46 (UTC)
Wikipedia:格式手冊/文字格式#顏色及內聯圖像只容許信息框是例外，表示跟一堆模板衝突，像是T:Table cell templates所列。你說WP:MOSTEXT不用改，即是這些模板必須洗白白囉；上面「顏色」一節的內容不重述自己看。不多說了，你們去決定要洗白白還是改格式手冊吧。—RalfX（ἀναγνώρισις） 2015年3月23日 (一) 12:55 (UTC)
先來解決最基本的矛盾問題。或者維持你的提案，並在你的提案中添加WP:MOSTEXT修改的內容（若如是，需要通過一個與WP:MOSTEXT以及Wikipedia:投票/跨語言連結的處理方式更強的共識）；或者把你的提案往現有的共識上調整。WP:MOSTEXT改不改是你的提案內容，不是我來決定。然後才是我的觀點。 --達師 - 318 - 527 2015年3月25日 (三) 05:32 (UTC)
談談怎麼解決矛盾跟整合提案吧，這樣比較有建設性。「不要花俏華麗」就維持原手冊的敘述。原本講「顏色」跟WP:MOSTEXT衝突，但是WP:MOSTEXT自己造成太多衝突，像是Template talk:Fact#建議取消顏色高亮又一樁，要嘛提個方案出來，或者以上面「顏色」為底本修改寫到WP:MOSTEXT。—RalfX（ἀναγνώρισις） 2015年3月25日 (三) 12:54 (UTC)
(－)反對，支持達叔，與現有共識相左。如要繼續，請改為逐條通過。--Gqqnb（留言） 2015年3月19日 (四) 06:03 (UTC)
(！)意見，某些人開始以英文區為兩個凡是了，沒考慮這裡的實際情況（從人力到條目狀況），一味照搬對方的方法。——路過圍觀的Sakamotosan 2015年3月20日 (五) 00:42 (UTC)
中文維基方針指引缺漏的都補上，自然不需要從其他語言版東一磚西一塊借回來用。也不會一堆討論都搬出英語版在談。—RalfX（ἀναγνώρισις） 2015年3月20日 (五) 13:48 (UTC)
中文維基雖然是發展中維基，但也不能照搬西方維基。要警惕西方維基對中文維基的思想入侵，建立有中文特色的中文維基制度。寧可摸著石頭過河，也不能引入資本主義制度而引發動亂--Gqqnb（留言） 2015年3月21日 (六) 00:12 (UTC)
"要警惕西方維基對中文維基的思想入侵，建立有中文特色的中文維基制度。寧可摸著石頭過河，也不能引入資本主義制度而引發動亂" < WTF?--223.16.120.156（留言） 2015年3月21日 (六) 06:57 (UTC)
(＋)支持，我還是十分支持此提案的。因為深感中文維基百科方針指引之缺失。至於與現有方針衝突的地方，大家可以在商議過程中進行更改。而缺處不補，卻是眾多爭端之始。我最近也在翻譯方針這方面的，感覺到如果有這些方面的明確方針，有些「吵鬧」完全可以避免，因為方針照顧到了很多人的想法，也能為一些人的行為提供依據。不反對摸著石頭過河的說法，但也能感覺到此法對中文維基的幫助有時候不那麼顯著。另外，請儘量避免地區中心的相關說法（如資本主義思想入侵）。--Alexander Misel（留言） 2015年3月25日 (三) 14:04 (UTC)
取自「https://zh.100ke.info/w/index.php?title=Wikipedia_talk:格式手册/存档3&oldid=68277586」