维基百科讨论:格式手册

维基百科,自由的百科全书
跳转至: 导航搜索

名稱[编辑]

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

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

該怎麼辦?

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

应该把MOS的翻译改掉……Liangent留言 2012年11月16日 (五) 07:30 (UTC)
怎么改?百家姓之四 討論 2012年11月16日 (五) 07:55 (UTC)

叫“文字格式”不就好了。 --达师 218372 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称“文字样式” --达师 218372 2012年11月18日 (日) 16:48 (UTC)
而且就叫“格式”又能怎么样。 --达师 218372 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)
那么所谓“凡例”又是什么意思呢? --达师 218372 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

--达师 261442 2013年1月24日 (四) 16:11 (UTC)

  • 支持,刚想说的来着。。。--110.153.212.185留言) 2013年1月24日 (四) 16:18 (UTC)
  • (+)支持:gd--Temp3600留言) 2013年2月1日 (五) 16:56 (UTC)
  • (+)支持:听起来很有道理。--InstantNull留言) 2013年1月24日 (四) 22:23 (UTC)
本来采用这种消歧义的方式就不对--百無一用是書生 () 2013年1月25日 (五) 01:45 (UTC)
新命名才是正确的吧。--魔法少年爱德华★爱生活圆神萝莉塔 2013年1月25日 (五) 04:05 (UTC)

已经进行了移动,链接暂时没有进行清理(如果有维基人愿意开AWB清理链接的话最好)。--达师 261442 2013年2月1日 (五) 16:51 (UTC)

地區用詞的格式[编辑]

已解決: 已由User:Kuailong修复。 ——Nigel 2014年7月30日 (三) 10:21 (UTC)

相關連結均已遭刪除或移動,但未「重定向」,煩請修復,謹致上十二萬分的謝意。 by 浮游 --220.129.204.186留言) 2014年7月28日 (一) 12:47 (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)
可參考《大英百科全書》做法:PrussiaUSSRLovewhatyoudo ® 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_talk:格式手册#有關格式手冊

重訂Wikipedia:版面指南[编辑]

  • 承上提的矛盾:原來該次討論嚴重出錯,同時與WP:DABWP:頂注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)
        • 經查[1]雖然公告「[討論] 歡迎參與有關格式版面的討論及有關用戶頁的討論。」,但是公告初時(2014年6月21日)本處只是討論外文名稱應否加粗體,而關於條目章節重新排序的重大變動在當時還未有人在此提出。--Mewaqua留言) 2014年7月28日 (一) 19:19 (UTC)
          • 再查[2](2014年6月5日),當時措辭是「[討論] 歡迎參與有關格式手冊的討論」,然而Wikipedia:格式手册Wikipedia:版面指南是兩個不同頁面,而下面的討論主要是關於「Wikipedia:版面指南」。--Mewaqua留言) 2014年7月28日 (一) 19:33 (UTC)
          • 再者,本處標題為「重訂WP:GTL​​」,不詳看內文,有誰知道是在討論把Wikipedia:版面指南提議的章節排序改動。--Mewaqua留言) 2014年7月28日 (一) 19:39 (UTC)
            • 話不可以這樣說,當他6月28日才正式提出,都有4個星期,重複按入來看都可以看好多次,而且都已經寫了這裡有格式和版面,已經給人討論任何有關版面的意識,不重複看不下去詳看那裡討論版面是個人問題,不是公告問題。--HanasakiMomoko留言) 2014年8月5日 (二) 15:51 (UTC)
              • 按照你的邏輯,上次Wikipedia:互助客栈/方针/存档/2014年3月#Wikipedia:版面指南的連結章節排序問題的討論從2013年9月20日至2014年4月3日存檔前一直留在客棧,更加長久,「不重複看不下去詳看那裡討論版面是個人問題,不是公告問題」。--Mewaqua留言) 2014年8月6日 (三) 03:41 (UTC)
                • 那次討論好像看不見有公告,即是雖然討論了幾個月但是給大家從公告重複入來的時間完全是沒有,情況都不同,就當然不同講法啦。--HanasakiMomoko留言) 2014年8月26日 (二) 11:40 (UTC)
                  • 今次有什麼不同?公告掛的是「羊頭」,這裡討論的內容卻是「狗肉」。--Mewaqua留言) 2014年9月24日 (三) 12:49 (UTC)
                    • 格式是羊頭,版面是狗頭,公告貼的格式版面已經是兩種頭都掛了在店面,就是已經告訴你這個大段有兩種肉給你找,怎可以算掛羊頭賣狗肉?--HanasakiMomoko留言) 2014年9月28日 (日) 16:53 (UTC)
                      • 就算是User:Cdip150在2014年9月6日 (六) 18:37[3]、2014年9月22日 (一) 16:22[4]改的Template:Bulletin,給的連結也是錯的,當時這裡的子標題是「重訂WP:GTL​​」,不是「重訂GTL」。--Mewaqua留言) 2014年9月30日 (二) 01:53 (UTC)
                        • 就算是這樣,這3個星期這段已經是最頂,甚至被剪掉只有版面的部分,即是從公告入來第一個討論就是這段,請問有很大影響嗎?而且還給你改個不準的標題,就算他做對了也給你搞到沒用了,這段也不止討論排序,也有其它部分。--HanasakiMomoko留言) 2014年10月6日 (一) 15:40 (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)
              • 維基幾時由虛擬變成現實?我以前教授給的影印書,就見到有這種做法。--HanasakiMomoko留言) 2014年8月5日 (二) 15:51 (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)

  • (?)疑問:從「Wikipedia:互助客栈/方针」的編輯歷史或User:Cdip150的編輯記錄都看不到該用戶曾在「2014年 9月22日 04:18 (UTC)」有編輯過。--Mewaqua留言) 2014年9月23日 (二) 16:07 (UTC)

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

身為管理員兼用戶查核員的用戶,一面就來個「最後7天公示」,另一面就用IP靜悄悄修改Wikipedia:互助客栈/方针/header[5],導致「目錄」本來可見的「重訂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)

  • 有更多用戶以行動對上述「修訂」投反對票:[6]。--Mewaqua留言) 2014年9月30日 (二) 01:13 (UTC)
    • 上面已經說了,像那樣的動作未必代表到些甚麼(而且那個回退實際上是全篇內容的問題);否則難道我又要理解這個動作是在支持我嗎?--街燈電箱150號 2014年10月10日 20:18 (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 | (記錄))[编辑]

  • 气旋瓦卡 编辑 | 讨论 | 历史 | 链接 | 监视 | 日志
  • 坚持在条目首段加跨语言链接,裸露外部网址链接,破坏条目品质。还反过来警告他人说他人独占条目。
  • 发现人:7留言) 2014年12月8日 (一) 06:39 (UTC)
  • 处理:

Wikipedia:格式手册,請建立“共識決”副署制度!![编辑]

log:special:diff/33747709

  1. “1990年代”可寫成“20世紀90年代”,但不简化成“90年代”或“九O年代”。 其中,“20世紀90年代”是人為添加,欠缺相關共識討論決議紀錄。
  2. 資料如次,special:diff/9548454Special:用户贡献/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:格式手册的「其他」章節,並整合原來「不要花俏华丽」的說明。相應內容在en:Wikipedia:Manual_of_Style#Miscellaneous。—RalfXἀναγνώρισις) 2015年3月16日 (一) 10:49 (UTC)

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

==其他==

;===不要花俏华丽===

快捷方式
WP:MARKUP
MOS:MARKUP

最簡單的標記方式通常是最利於編輯、最易於理解、以及最可預料的辦法。標記可能在不同瀏覽器顯示有所落差,不应该假定所输入的代码在显示时保证会有預期效果。格式代码越單純,显示、编辑、與維護都会变得更容易。建立有用的百科全书是我們的首要目的,但保持编辑和维护容易是第二重要任务。

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

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

===格式問題===

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

通常情況下,使用訂製的字體樣式將:

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

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

====顏色====
快捷方式
WP:COLOR
MOS:COLOR

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

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

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

===滾動列表與摺疊元素===
快捷方式
WP:SCROLL
WP:COLLAPSE
MOS:SCROLL
MOS:COLLAPSE

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

===隱藏註釋===
快捷方式
WP:COMMENT

有些編者會在條目內文中使用隱藏註釋和其他編者溝通。這些註釋僅於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)


空格[编辑]

在中文維基格式手冊裏,空格一節寫出,「在中文語境內,文字之間應該不留空格。」請問這是否只是指中文與中文之間?在中文與英文之間,在中文與數學符號之間,在中文與數學方程之間,在標點符號與中文之間,是否可以留空格?在英文維基裏,對於空格的置入沒有做出限制。從英文維基輸入的模板與數學方程裏,都存在著很多空格。我覺得在原始碼內適當地置入空格,可以幫助檢視與維持;在頁面裏適當地顯示空格,也可以幫助閱讀、美化頁面。我們是否可以賦予空格一些它可以承擔的功能?請大家發表寶貴意見,達成共識,謝謝!--老陳留言) 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粒子、X0粒子、Y0粒子、Z0粒子。英文維基並沒有對空格的置入做出甚麼限制,我們為甚麼要過度規定空格的置入?--老陳留言) 2016年3月23日 (三) 05:35 (UTC)
          • 對於這種情況其實並沒有建議要用抑或不要用空格,還是一句:請按個別情況用常識決定是否加空格。而我這邊顯示「XYZ」和「粒/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)

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

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)
謝謝您的關注與意見!希望您翻譯英文時,務必要仔細嚴謹,不能斷章取義:
  1. In normal text(在正常文句裏):這不包括特別案例,例如,模板內的原始碼、數學公式與正常文句之間的界面等等。英文維基沒有對這些特別案例做出規定。
  2. 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)
  • (-)反对中文與英文之間加入空格。--喜歡用IRCCarrotkit 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就能做到的。斜体的情况下,Y0的例子下,我的显示重叠了,看起来几乎像是Ytheta(字体:Yu Mincho)。我觉得在这种情况下可以加上空格。Bluedeck 2016年3月27日 (日) 23:54 (UTC)

那为什么斜体后面就不能用JS/CSS加……--Jimmy Xu 2016年3月28日 (一) 00:41 (UTC)
很有趣的是「Y0」這個狀況並不是該利用空格修正格式的好場合,因為如果在斜體字後方加空格來修正,雖然原本有字體重疊問題的用戶看到的畫面正常了,但原本顯示很正常的用戶,卻反而會看到「Y」跟「0」之間被明顯拉開看起來不太像指數符號的情況。若要修正這問題,使用CSS調整恐怕才是治本的方法。--泅水大象訐譙☎ 2016年3月29日 (二) 04:19 (UTC)
{{Lang|en|''Y''<sup>0</sup>}},顯示為Y0。--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)
我的发言欠缺考虑,我同意Y0是不应使用空格拆分的。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>难免带来一点麻烦:--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的粒子
源代碼:<span style="font-family:'微软雅黑',sans-serif">一个质量为''m''的粒子</span>
用戶2的瀏覽器的結果:一个质量为m的粒子
源代碼:<span style="font-family:Arial,'新細明體',sans-serif">一个质量为''m''的粒子</span>
如果字母m前面加入空格
用戶1的瀏覽器的結果:一个质量为m 的粒子
源代碼:<span style="font-family:'微软雅黑',sans-serif">一个质量为''m'' 的粒子</span>
用戶2的瀏覽器的結果:一个质量为m 的粒子
源代碼:<span style="font-family:Arial,'新細明體',sans-serif">一个质量为''m'' 的粒子</span>
可以看出,“加入空格”給不同用戶帶來的影響不一
CSS letter-spacing我想應用在“m的”這部分文字,效果跟“加入空格”差不多,後者調整的單位是空格,前者的單位很小 - John doe 120留言) 2016年4月23日 (六) 08:26 (UTC)
  • 打開網頁[8],然後右鍵點擊“一个质量为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)

  • 以下文字的“或”字可能被部分中文用戶忽略:
  • 法厄同星(PhaetonPhaëton,有时也拼写为Phaethon)是位于
改成:
  • 法厄同星(PhaetonPhaëton,有时也拼写为Phaethon)是位于
從右到左看,“或”字可能被忽略,以上文字改成:
  • 法厄同星(PhaetonPhaëton,有时也拼写为 Phaethon)是位于
John Doe 120talk) 2016年5月8日 (日) 11:37 (UTC)

难道就没人会用LaTeX吗?[编辑]

这是粒子、粒子、粒子?--4Li 2016年4月30日 (六) 04:44 (UTC)

@李4:我就真的不會....你肯定維基上有教學?--Temp3600留言) 2016年5月8日 (日) 13:26 (UTC)
user:Temp3600[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]大家来学LaTeX(我随便找的,自己没看过)。Bluedeck 2016年5月12日 (四) 00:20 (UTC)
user:Temp3600[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]中文維基教學於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的文本部分(区别于标签)包含有中文語境。<span style = "color : red">17 公尺</span>输出为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而不是空格字符)。--Altoria2e5 更改·工具 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里面有讲这个的地方)))。)--Altoria2e5 更改·工具 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)
user:Jarodalien[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]这是中国大陆国标GB3100-93[9],请参考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,不过按道理讲的确不该。——Altoria2e5 更改·工具 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分 留言

个人论述[编辑]

排版领域,许多时候都要在文本中加入适当的间隙来优化版面,方便阅读。何时加入应排版风格而不同,但常见的情况包括文字与标点之间、文字与单位名称之间、文字与阿拉伯数字之间,或者中文和拉丁文之间。间隙的大小通常是半个到一个拉丁字母左右。

早期,人类使用打字机印刷机等简易的机械装置来进行排版印刷。在这类机械装置中,每一个字符的宽度是固定的,这个宽度就是一个铅字的宽度。对于使用拉丁语的人来说,排版需加入适当间隙时,通常只需空出一个铅字,或者按下打字机的空格键。由于空格本来就是拉丁诸语言的组成要素(例如用做分隔单词,手写的时候用空白分隔逗号后边的字母),这没有任何不妥,何时敲击多少次空格键,依照使用者的排版方针进行。这仅仅是把任何手写时需要的空白替换为敲击空格键而已。

随后,东方世界也开始使用打字机、电传打字机和计算机进行文字处理。由于东方文字是方块字,因此一个铅字(不要纠结铅字、字符或者一个字符的字节数等底层限制,本文将互换使用)的宽度基本上是拉丁文的两倍,这就导致了一个问题 —— 如果使用空一个字的方式,实现标点符号与文字的间隙,太大了。不过,解决方法还是有的:把标点符号的铅字也是一个汉字的宽度,但有符号的突起处只有字宽度的一半,剩下一半是空白的。这样,在排版时,标点符号就会自动带有空格了。请在简体中文环境下观察本文中的逗号。

然而这个方法不是完美的,因为这一定程度上,把使用者决定是否留空隙的权力剥夺,转交给了铅字本身,铅字是一定会有空隙的。使用者不能根据情况调整空格数量。例如这种情况下(观察下一个括号与逗号之间的空隙),空隙会变得有点大。由于空格是嵌入字符中的,因此无法调整。

很快,人们又有了进行东方文字和西方文字混排的需求。但字符的宽度是固定的!因此,要么将拉丁文强行拉长,要么将东方文字强行压扁 —— 这两种方法在日本早期都有尝试,分别是全角英文(例如English)和半角假名(アチム)。前者强行将拉丁文拉长,后者将文字压扁,阅读起来都非常难受。另外,单位名称的排版问题还没解决呢!于是人们又搞出了一堆字符,仅仅用来表示单位名称。例如千瓦(㎾和㌗)、千克(㎏和㌕),看到没有?一个字符居然强行装四个假名。除此之外还有什么么安培啊、帕斯卡啊、法拉第啊等计量单位,详见这里。此外,汉语中的也有计量用汉字。虽然这只是借鉴了日文中的多音节汉字,和为了排版造字无直接联系。但从把计量单位用一个字符表示的角度讲,起到的作用是一样的,例如千瓦(瓩)、英里(哩)、海里(浬)。

接下来,随着科技的进步,我们又进入了计算机不再用电传打字机而是键盘的新时代。随着软件的发展,我们也可以将半角和全角混用,不再受到宽度固定的限制了,可恶的全角拉丁文、单位名称和半角假名这类东西很少被使用了。全角西文的问题在于,它的空格是在字符内部固定死的,不能根据上下文来加入间隙,而是仅仅为了满足硬件限制强行加入间隙。但好不容易摆脱了宽度噩梦的人,似乎只要宽度正确,也就不指望文本需要适当的间隙了。

但实际上,如果我们正确的加入间隙,那么可以达到很好的阅读效果。但现在的计算机中西文之间没有任何间隙(总比被迫使用全角拉丁文好啊)。这个问题的根源是 —— 正如早期的计算机只有一种宽度的局限性一样,现代计算机的局限是 —— 文本处理程序是以字符为中心,而不是文字本身为中心处理文本。并不是说计算机不能干这事,而是在计算机中,文字输入和文章排版是完全不同的两个应用。如果你有一个输入框,比如维基百科现在的这个纯文本编辑器,你不可能指望它主动帮你排版;但你如果在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對於呈現與內容分離的詳細說明與精闢見解。我覺得中文維基格式手冊關於空格的規定不夠嚴謹、需要改善,尤其是缺乏設定中文語境的範疇,這問題很容易會被破壞者利用,藉此進行大量刪除空格的無建設性編輯,並在其中夾雜著錯誤編輯,如在聖人瀑布裏的惡性行為。因此,我提議在空格一節添加以下規則:

  1. 中文語境不包括參考文獻、模板、表格、數學公式在內。
  2. 按照中国国标GB3100-93[10],第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 特邀专家之一(我全都提到过)。--Artoria2e5 保持页面整洁,直接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)
user:Liangent[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]在英文維基裏,MediaWiki軟體會自動處理空格的渲染。理論而言,源碼可以有任意數量的空格。這給予了編輯者在編輯源碼時很大的彈性,促進源碼的可讀性。在中文維基裏,假若,我們過度硬性規範空格數量,則會影響源碼的可讀性。至於有關MediaWiki軟體如何處理空格的渲染這方面的問題,可能需要請教才女,她是這方面的專家。
空格的渲染涉及到藝術美觀問題。例如,第i個字、第 i 個字,這兩種由於空格的置入與否會產生的不同的渲染效果,前者顯示出英文字母緊緊地擠在「第」與「個」兩個字之間,使用手機閱讀很可能會忽略掉這個英文字母,後者則較為明顯地展現出英文字母 Bluedeck在前面也舉出另外一個例子。這些例子都展示出,我們不應隨便禁止置入空格。--老陳留言) 2016年6月15日 (三) 06:11 (UTC)
  • 我覺得編輯工具欄可以添加一個按鈕,自動在全文或者選中文本的中英文之間添加空格。—John Doe 120talk) 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 120talk) 2016年7月1日 (五) 05:13 (UTC)

華人或東亞的組織,應該附註英文名字嗎?[编辑]

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

@Yel D'ohan: 感觉应该分情况讨论。对于国民党,本人认为英文非首要且增添信息有限,但考虑到其在官方网站亦明显注明之,可以考虑添加,不添加亦可;至于唐凤,由于其有另一通行称呼(Audrey Tang),与其本名显著不同,应当添加。其他东亚或有东亚背景的人物组织,感觉如果没有特别需要,使用汉语名+母语名或纯汉语名即可。--Morningstar1814留言) 2016年9月8日 (四) 20:37 (UTC)
  1. 使用lang-en等模板标出外文。你看这个Audrey Tang,你怎么确定它是英文、西班牙文还是法文?我先想当然地标注了lang-en,望其它编者指教。
  2. 标注外文的争议在维基百科长年存在,如联合国,阿拉伯文、中文、英文、法文、俄文、西班牙文都可以标。海牙国际法庭,它标了法文,为什么不标英文?它属于联合国,为什么不标阿拉伯文?甚至台北上海苹果都可以标外文。跟废派相比,挺英派(挺外派)总是比较多。--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)