维基百科:互助客栈/方针

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

互助客棧消息发表 · 方针 · 技术发表 · 求助发表 · 条目探讨发表 · 其他发表 知识问答发表
快捷方式
WP:VPP
Breezeicons-apps-48-cantor.svg

本頁提出或讨论维基百科政策、方针,请参看方針與指引方针列表
繁简处理的议题请前往字词转换讨论页
条目应当如何编辑才符合中立性原則寻求社群共识,请前往条目探讨留言。 請注重禮儀及遵守方針與指引,一般問題請至互助客栈/其他知识问答提出,留言后请务必签名(点击 Vector toolbar signature button.png )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
存档图像
互助客栈(方针)档案馆
编辑

2003年 5月或之前 6 7 8 9 10 11 12
2004年 1 2 3 4 5 6 7 8 9 10 11 12
2005年 1 2 3 4 5 6 7 8 9 10 11 12
2006年 1 2 3 4 5 6 7 8 9 10 11 12
2007年 1 2 3 4 5 6 7 8 9 10 11 12
2008年 1 2 3 4 5 6 7 8 9 10 11 12
2009年 1 2 3 4 5 6 7 8 9 10 11 12
2010年 1 2 3 4 5 6 7 8 9 10 11 12
2011年 1 2 3 4 5 6 7 8 9 10 11
2012年 1 2 3 4 5 6 7 8 9 10 11 12
2013年 1 2 3 4 5 6 7 8 9 10 11 12
2014年 1 2 3 4 5 6 7 8 9 10 11 12
2015年 1 2 3 4 5 6 7 8 9 10 11 12
2016年 1 2 3 4 5 6

公告板

空格[编辑]

在中文維基格式手冊裏,空格一節寫出,「在中文語境內,文字之間應該不留空格。」請問這是否只是指中文與中文之間?在中文與英文之間,在中文與數學符號之間,在中文與數學方程之間,在標點符號與中文之間,是否可以留空格?在英文維基裏,對於空格的置入沒有做出限制。從英文維基輸入的模板與數學方程裏,都存在著很多空格。我覺得在原始碼內適當地置入空格,可以幫助檢視與維持;在頁面裏適當地顯示空格,也可以幫助閱讀、美化頁面。我們是否可以賦予空格一些它可以承擔的功能?請大家發表寶貴意見,達成共識,謝謝!--老陳留言) 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)

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

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)
  • 打開網頁[2],然後右鍵點擊“一个质量为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[3],请参考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[4],第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)

好久沒來維基百科,剛剛看見這一討論,未能詳細閱讀,如有重複觀點敬請見諒。有沒有一種技術手段,無論在源碼中有沒有空格,都會自動在漢字和西文(包括公式和數字)間渲染出一個間隙?當有特別情況不願意渲染出間隙的時候,可在源代碼中加入某種語法避免渲染間隙。這種做法與微軟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)

創建用戶沙盒的時候,沒看到有關廣告的規定[编辑]

宣傳活動 Wikipedia:SOAP[编辑]

一般對於宣傳活動的定義是啥? 有些藝人條目會把歌迷會 牽手會 歌友會 影友會 見面會之類的活動列入條目! 這些不是作品,不應該放入條目撰寫吧? --Zenk0113留言) 2016年6月14日 (二) 01:27 (UTC)

并没有说过艺人条目里只能放作品进去吧,而且WP:SOAP里说的是不允许广告宣传,有来源的添加艺人的大型活动是可以的吧。而且本人并没有在任何条目中有见到收录“牵手会”这种东西的--找来源好麻烦肯定帮不到你 2016年6月14日 (二) 11:51 (UTC)
牽手會是過去整理條目的經驗。同一性質一起討論而已。大型或重要活動放置沒有問題。

若說藝人條目不限只能放作品的話,那是否有附上來源的綜藝節目、廣播電台節目、演唱會和粉絲見面會都可完整列表收錄?--米亞比留言) 2016年6月14日 (二) 08:46(UTC)

个人的观点是冠名演唱会和冠名节目,常规班底这种长期出演可以放,一次一次嘉宾出演之类的就另当别论,不过嘉宾出演的节目可以放在节目的条目里写,粉丝见面会我认为有来源规模大的话可以写吧。。。--找来源好麻烦肯定帮不到你 2016年6月14日 (二) 13:06 (UTC)
不可。因為WIKI是百科不是全紀錄,就算有來源細項也是要經過整理(重點或是摘要),而非過度統計清單。Zenk0113留言) 2016年6月15日 (三) 03:04 (UTC)
冠名我不確定。但是規模夠大的粉絲會要怎麼認定?(海外?)Zenk0113留言) 2016年6月15日 (三) 03:04 (UTC)
有足够多的第三方来源证明一个活动的关注度(可以独立成条目)的话,应该就可以写了吧--找来源好麻烦肯定帮不到你 2016年6月15日 (三) 05:21 (UTC)
您是指活動列表的獨立條目還是單一大型活動的獨立條目?Zenk0113留言) 2016年6月15日 (三) 06:47 (UTC)
我的意思是如果某个活动有着足以独立成条目的关注度,那么在艺人的页面中列举这一活动便是可以的--找来源好麻烦肯定帮不到你 2016年6月15日 (三) 07:26 (UTC)
是阿! 這時候都可以設條目連結了! Zenk0113留言) 2016年6月15日 (三) 07:39 (UTC)
大型签收会的话,应该能在相应报道中凸显。至于粉丝会,可能需要同样的报道或得到官方的认定,不过一般不列就罢了。——路过围观的Sakamotosan 2016年6月15日 (三) 03:56 (UTC)

若說編輯者的辛苦、努力不構成理由,但對同樣辛苦、努力查找資料,搜尋到維基百科的閱讀者來說,需求總構成理由吧?我是韓國娛樂圈相關的初始研究者,在查找TWICE所參加過的綜藝廣播節目時,查找到一半要持續時,卻發現整個列表被刪除,結果還是我這位非粉絲把列表回復,回復時,因為不熟練操作,所以只回復了廣播節目,綜藝節目列表只能一一重新打出來,但廣播節目列表又再度被刪除!因此有感打出列表的原編輯者的辛苦,還有對我這類有查看和比較各偶像團體完整綜藝展現的需求者之不易,因此才提出質疑!

有人說放置綜藝列表是將維基百科變成愛好者網頁又過於瑣碎,但我不予苟同,對了解娛樂圈的人來說,綜藝節目本身就是展現偶像藝人和笑星的「藝能感」的舞台,綜藝節目自然能算作作品之一,所以列出完整列表對我這種非粉絲的純研究者同樣有研究幫助。維基百科當然不是瑣碎的全紀錄,也不是愛好者網頁,但所謂的瑣碎的全紀錄,是一一紀錄該藝人的日常生活、平常愛好(例如:早上幾點刷牙、平時看什麼報紙)等;還有該藝人在每場活動上的表情行為動作(例如:舉了幾次手、做了怎樣的微笑飛吻)等。至於愛好者網頁,若非以粉絲口吻過度讚揚或粉絲圈的傳言為內容,而是以中立、客觀的事實為基所撰寫,如何能說是愛好者網頁?那些綜藝節目只是像其他演藝作品一般單單列成列表,並無過多贅述,如何能稱之為瑣碎和愛好者網頁? --米亞比留言) 2016年6月15日 (二) 12:53 (UTC)


已離題! 請針對議題討論。如有需要請另開話題討論 Zenk0113留言) 2016年6月16日 (四) 07:10 (UTC)
  • 我记得之前讨论过这个问题,我的观点是应该其主业有关的视为作品可以详细一些,其余应该简略交代。大多数歌手、演员的主业显然不是综艺节目,事无巨细列在上面就应该视作杂项陈列。--Kuailong 2016年6月17日 (五) 20:49 (UTC)

给管理员添加torunblocked权限[编辑]

目前管理员拥有IPBE几乎所有的权限,唯独没有torunblocked的权限,这件事情看上去不太合理。因此在这里开一个讨论,如果有共识将报告给phab:。--Antigng留言) 2016年6月18日 (六) 12:44 (UTC)

可能增加一个风险,管理员账号被盗后黑客使用Tor来隐藏身份。--YFdyh000留言) 2016年6月18日 (六) 14:57 (UTC)
WP:RFCU查得出來。--James970028留言) 2016年6月18日 (六) 15:13 (UTC)
查出来的不是Tor出口吗。无此权限能增加匿名难度吧。--YFdyh000留言) 2016年6月18日 (六) 17:17 (UTC)
不用tor就不能隐藏身份?显然不是。--82-98-119-34a留言) 2016年6月22日 (三) 03:37 (UTC)

维基媒体是否接受在签名宣扬政见[编辑]

用户在签名中加入大量与编辑维基百科无关的资讯,其中签名用字的排列严重误导他人理解留言者的正确注册用户名,更甚者是宣扬极具爭議的个人政见主张,请问管理员是否容忍这是种滥用签名的行为。我相信在英文维基百科那边在签名加入「support/oppose Trump」很快就会被那边的管理员要求回退成预设签名。-- 同舟 · ) 2016年6月20日 (一) 06:02 (UTC)

該簽名從鑑別名稱方向來說的確有問題,請管理員考慮。然而我必須指出,我在英語維基的簽名,暫未被挑戰。 2016年6月20日 (一) 06:38 (UTC)
同時我亦須指出,英語維基近日有悼念Jo Cox的簽名,該等簽名亦未有受挑戰。 2016年6月20日 (一) 06:43 (UTC)
我查閱過你在英文維基百科的使用簽名留言記錄就只有一次,而且那時預設簽名,如果你換了簽名又沒有使用它到處公開留言那也不會有人理會。我的著眼點是政見簽名的曝光率,至少我在查閱/留言比較集中的地方如village pump、admin notice board和Jimbo討論頁都沒有見到你所指悼念Cox的簽名,或者是非常不容易見到,或者這個簽名非常刷邊球的(至少沒有明言政治立場)而沒有引起關注,不論悼念簽名有沒有被使用過,有一點是肯定的,維基媒體不是宣揚政見的場所,這明顯脫離了編輯維基百科的範疇,當初英文維基百科那邊刪除了反對SOPA的用戶的分類就是基於這個原則,很遺憾中文WP無視這個原則沒有跟隨處理一堆用戶政見分類。-- 同舟 · ) 2016年6月20日 (一) 07:18 (UTC)
同意楼主观点。 --达师 - 334 - 554 2016年6月21日 (二) 12:24 (UTC)
(※)注意中文维基可以与英文维基的做法冲突。User:Asdfugil的签名“佔領中環(留言) 我要真普選 Asdfugil留言於香港特別行政區”的HTML标记长达270个字符,超出WP:签名规定的255字,应修改。但是WP:签名并未反对政见、宗教观点或其他个人观点。我认为只要长度符合规定,参考WP:用户页允许对各种观点陈述一次。--Gqqnb留言) 2016年6月21日 (二) 22:45 (UTC)
用戶頁宣示政見我當看不見,而事實上在用戶頁只發表一次個人觀點的原則亦沒有得到尊重和規範。我舉例的簽名除了令他的同路人感到快慰我找不到其他妥當的地方,因為簽名會在各個討論頁爆光,這無異於自我宣傳,而且破壞維基媒體政治中立的原則,如果維基百科禁止任何形式的商業宣傳(例如註冊用戶名,更不用說簽名了,這應該是永久封禁處理),我看不到為甚麼這不適用於政見宣傳。-- 同舟 · ) 2016年6月22日 (三) 00:13 (UTC)
同意签名不应包含政治宣言,维基百科的讨论页不是用来刷大字报的地方。 --Kuailong 2016年6月22日 (三) 14:33 (UTC)
那一会再来个签名是 反对佔領中環(留言) 真普選去死 示例用户留言於中华人民共和国“的是不是他们俩得打起来?#ForeverLove凡人丶 你一定要好好的 中文字数统计工具 2016年6月23日 (四) 10:43 (UTC)
维基不接受宣扬政见,不仅适用于签名,用户页同样不接纳宣扬政见。--Thomas.Lu留言) 2016年6月23日 (四) 10:50 (UTC)
同意楼主观点。---Zwd626留言欢迎参与地理学专题 2016年6月23日 (四) 12:00 (UTC)
赞同签名不应包含政治宣言。- I am Davidzdh. 2016年6月26日 (日) 00:50 (UTC)
然而,政治宣言的定義並不明確,像我這種算不算?至於用户页,我認為不需要管那麼嚴,現行「允许对各种观点陈述一次」已足夠。-和平、奮鬥、救地球!留言WikiNews於 2016年6月26日 (日) 03:47 (UTC)
我不認為「和平」是一種政治立場,雖然簽名本應該是儘量簡潔避免附帶不必要資訊,政見是擁護特定政治團體,而這個政治團體可以透過宣揚其政見獲得金錢上的利益(不論是否已經實現與否),所以應該與商業宣傳看齊。-- 同舟 · ) 2016年6月26日 (日) 05:04 (UTC)
如果政治宣传与商业宣传看齐,商业宣传的用户页按目前情况是会被提删,甚至速删的,宣扬政见的用户页,都应该删除了。如果要执行起来,确实不论商业还是政治,签名还是用户页,都应当看齐处理的,而不是选择性保留某种形式的宣传、某类群体的宣传、某种政见。--Thomas.Lu留言) 2016年6月26日 (日) 07:34 (UTC)
維基媒體不是一直對商業宣傳(paid advocacy)採零容忍政策嗎?這應該是不單單適用於用戶名或條目編輯,對用戶頁應該都不例外吧。-- 同舟 · ) 2016年6月26日 (日) 10:56 (UTC)

废止3RR及改为2RR[编辑]

根据管理员User:Antigng在朱元璋词条中的判例,以及在Wikipedia:互助客栈/条目探讨#御容一词的使用及朱元璋词条Antigng的不当判例段落中的解释说明。建议废止回退不过三,改为回退不过二。理由详见user:antigng在有关部分的解释。--SP RailwayGuest 2016年6月22日 (三) 05:51 (UTC)

兩碼子事呢,3RR是指回退超過三次會被封禁(亦即一個低標準的上限),跟條目被保護根本無關--Liaon98 我是廢物 2016年6月22日 (三) 13:22 (UTC)
(:)回應,都被保护了,怎么还会产生3RR呢?自然就可以废止了嘛--SP RailwayGuest 2016年6月23日 (四) 03:10 (UTC)
非也,3RR定義是回退超過三次會被封禁,這代表可能在管理員還沒來得及處理時,編輯戰就已經擴大到回退超過三次,所以是種事後處理。而保護則是,只要出現編輯戰,就該保護,所以保護的時間可能是事後(已經發生了3RR),也可能是趕在還沒嚴重到3RR就先保護。所以不管是哪種情況,3RR跟保護都八竿子打不著,只要有編輯戰就有保護的選擇--Liaon98 我是廢物 2016年6月23日 (四) 05:39 (UTC)

提議:非地域中心的中立命名與中立內容決議方式[编辑]

此提議僅限於參與人數夠多的狀況下才能實行,馬新簡體的使用者幾乎沒有的樣子,所以僅是構想,順便確認可行性。方法採投票式,分臺灣正體/馬新簡體/澳門繁體/香港繁體/大陸簡體,一共五組投票區,得出相對多數的共數後,將五組的意見匯流,主要名目或內容採用五組相對多數共識,紛歧過大甚至無決斷則各地域中心內容自成一個條目或用區域詞碼轉換。--健康欠安 (留言) 2016年6月24日 (五) 13:12 (UTC)

將預設字形大小調整為14.5px 或15px[编辑]

1. 繁中頁面預設顯示的字形大小是新細明體 14px。但是新細明體14px 的顯示效果非常差,是無法忍受的差。具體缺筆我說不明白,如筆劃會黏在一起,看起來很「虛」。簡中使用者可能不明白,但繁中使用者應該很清楚,並且同意以上說法。新細明體 在 12,13,15,16px 都沒有問題,但是在14 px時會有這個缺陷。 所以我建議將維基百科內文的預設字體大小改為 14.5px 或 15 px。

2. 瀏覽器Edge 顯示的大小是16 px,所以不會出現上述問題。 Chrome, firefox 有這個問題、其他不知。

3. 技術上多半沒問題,更改影響範圍只有中文維基百科的內文。

4. 簡中雅黑體沒這個問題

5.

這是14px的字形。提供給討論者參考。

這是14.5px的字形。提供給討論者參考。

這是15px的字形。提供給討論者參考。

(請用ctrl+0 把縮放大小調成100%。另外的設定也會影響顯示大小。)

Golopotw留言) 2016年6月26日 (日) 17:56 (UTC)