维基百科讨论:格式手册/存档3

页面内容不支持其他语言。
维基百科,自由的百科全书

一個空格的問題

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

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

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

我希望User:Mark85296341User: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)
  • 强烈(-)反对:天啊,那得投多少票啊?1+2+3+4+5+6+…—以上未簽名的留言由虞海對話貢獻)加入。 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改成“以出现添加空格或删除空格的第一次移动前为准”比较好。如果真的出现为了空格而抢建条目的情况也没什么不好,只是那几个人自己累而已。--达师198336 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)
系列游戏的子标题个人倾向于冒号。--达师198336 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}}恐怕又要一阵吵。再考虑到日本游戏,于是才想到开这个,要不我也懒得插手 -_-|| --达师198336 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)

说出来简直笑话

为了米国的一家商业公司在某天拍脑袋想出来的名字,你们居然讨论了几个月都没有结果。其实尊重词条创建者即可,根本不需要为如此无聊的事情再去建立一个什么手册。-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)

異體字

(!)意見:问题闹大了,有必要分开讨论,下分段。—以上未簽名的留言由虞海對話貢獻)加入。 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

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

綜合之前的討論,請大家就以上方案發表意見,討論結果應寫入格式手册,謝謝。--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)

关于战役条目中†的使用,能否统一到格式手册或相关专题?

之前曾经提出过很多战役条目中的†的使用存在标准不统一的问题,这次把相关的内容拿出来请教一下:

英文维基的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)
好像沒有相對應的,閣下可以問Ai6z83xl3gOneam兩位軍事條目專家,或許可以得到正確的解答。--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:KIATemplate:俘虏Template:投降en:Template:KIAen:Template:POWen: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资料就可以保留,而是中文下保留外文名是否有意义。--达师218372 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)

编辑条目过程如涉及方言或非通用词语时,请尽量顾及其他人士

现发现有个别香港有关的条目内容中,会提到粤语,如12,此外还有很多条目写有“杯葛”(大陆地区极少用此说法,绝大多数用抵制一词)等,非使用此类语言(或方言)人士很难确切理解其中的意思,还请编辑者在编辑相关内容时,在其后用括号翻译成通用之话语。——語句不通順不舒服斯基┣●┫不想屌我敬請留言呐親 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}}模板對格式手冊的諸子頁及相關頁僅分了四類,我對此感到使用上的不便,所以自己正在修改,如右所示。

然而我遇到了一頗尷尬的事情。這個版本是以現在英文版的爲基礎的,第二類叫“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)

本来采用这种消歧义的方式就不对--百無一用是書生 () 2013年1月25日 (五) 01:45 (UTC)
新命名才是正确的吧。--魔法少年爱德华★爱生活圆神萝莉塔 2013年1月25日 (五) 04:05 (UTC)

已经进行了移动,链接暂时没有进行清理(如果有维基人愿意开AWB清理链接的话最好)。--达师261442 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:格式手册#條目標題一節的例子中,「蘇維埃社會主義共和國聯盟(俄語:Союз Советских Социалистических Республик)」括號內的外文並沒有加粗,但在同頁「傳記」一節中,「史提芬·威廉·霍金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:互助客栈/方针/存档/2013年5月#請求討論並且將維基百科:版面指南升級成為指引

重訂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)
        • 經查[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:格式手册,請建立“共識決”副署制度!!

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)