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

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

一个空格的问题

以下内容移动自互助客栈，新留言请置于框外。

参见：讨论:Google Chrome和讨论:诺顿360

这个问题已经困扰一段很长的时间，虽然对大多数维基人影响甚微，可惜参与相关编辑战的维基人从头至今没有认真讨论过，甚至达成共识，已经是为编辑战而进行编辑战，直到对方退出为止。此事件已经引致一名维基人退出，再这样下去的话，中文维基就会因为一个空格而造成一个“笑柄”。

事件的起源是来自诺顿360，User:Mark85296341、User:Chunchun2345、User:Hkh222以及User:Πrate进行多次编辑战，已出现WP:3RR的情况，之后编辑战延伸至包括Google Chrome、Mozilla Firefox等条目，近日我向User:Mark85296341查询，而他得出回应是：

我想找个那个存档，但最终找不到。不做初一，就做十五，一是所有条目留空格，一是不留。在中文语境中，的确很矛盾，并没有因为拉丁文字前后是否留空格，今次讨论希望寻求共识，以免这种编辑战再现。

我希望User:Mark85296341、User:Hkh222以及User:Πrate在得出任何共识前也不要去处理有关条目。

P.S.我看那些页面的编辑历史真的有点不舒服。--Flame 欢迎泡茶 2011年1月9日 (日) 14:41 (UTC)

  • 注意这个问题好久了，觉得达成共识不易。不如投票吧。要不然扔硬币也行（笑话）。不过请大家以后别再进行编辑战了，为这点小事不值得。要不然真成笑柄了。--苹果派.留言 2011年1月9日 (日) 17:56 (UTC)
各位，我想大家要留意一个问题，是怎处理那些为了小事坚持己见的家伙，由于维基的开放性，这类人一聚起来就一些很难想像会打编辑战的地方，都会打起编辑战。“心理辅导”，可能比社群共识更快解决问题。Martinoei (留言) 2011年1月9日 (日) 20:38 (UTC)
我的意见：一般情况下，如果条目名称大部分是中文，只有一两个英文词，则不加空格，如2011年Oricon单曲周榜冠军作品列表条目；如果条目名称大部分是英文，只有一两个中文词，则需要加空格，如My Name Is 邦。但如果官方名称有空格，则根据名从主人原则，条目名称也必须有空格，如Google 日历。--Symplectopedia (留言) 2011年1月9日 (日) 21:00 (UTC)
我的建议是，官方名称是有空格，就无谓乱动廿四。如果官方名称没规定，有空格、没空格都来个重定向不就解决问题。技术层面可以解决的问题，就用技术解决，让双方各自满足好了。Martinoei (留言) 2011年1月9日 (日) 21:35 (UTC)
我认为中文环境中空格不是必须的，哪怕是中英混杂如google日历加不加空格都没有问题，我觉得只有英文间才需要空格，如google chorme。

百兔乐的意见很有先见性，即正文里中文和外文中的空隙以手工空格的方式并不是十分妥当。而应采取如段前空两格那样用CSS来控制。

空格也是一个字符，有些环境里空格会显示成一个框框，很丑。--玖巧仔●□留言 2011年1月9日 (日) 22:39 (UTC)

第二个的重点是“Google Chrome”的前后应否留个空格？这是除了条目名称探讨，还要注意的问题，这个问题不解决的话，编辑战仍然会来。--Flame 欢迎泡茶 2011年1月10日 (一) 00:18 (UTC)

用css来控制中英文之间的字间距有难度，但写个js脚本应是完全可以的，但可能会影响（浏览器的）性能。--菲菇＠维基食用菌协会 2011年1月10日 (一) 02:59 (UTC)

第三个问题，在Wikipedia:格式手册并没有说明在字母后要否留空格。这点应否再加上？--Flame 欢迎泡茶 2011年1月10日 (一) 09:51 (UTC)

最新情况：已向Mark85296341留言，等待回应。--Flame 欢迎泡茶 2011年1月10日 (一) 15:56 (UTC)
  • 我也觉得很没有意义，例如在Google Chrome一例子中，我认为百科全书的宗旨不是Google产生出来的东西、产物，也不是任何Google的主张用来发声的管道，我觉得那些想加空格的人在要求Google提出相关证明前，应先要求自己是否能提出“世界上有任何一本具有高度权威性、国际性的英语辞典或文法大全里有指出英文前撮或后撮东方语言的单体文字时，之间要加一个空格的‘英文官方文法规定’”，否则只是本末倒置。
    还有，Google Chrome这里意见这么多，怎么不见“Google地图”、“Google地球”，还有所有其他的“Google产品”有意见呢？那些人要不要有人出来解释一下？“要就全部统一”，要加就全部统一加空格然后移动，不过我想应该是没有人要做这么没有意义、这么累的事。－Berting Li (留言) 2011年1月12日 (三) 11:21 (UTC)
    (：)回应你能提出更有效的方法防止编辑战吗？所以你认为这次事件应该在Google Chrome的条目内讨论吗？--Flame 欢迎泡茶 2011年1月13日 (四) 15:35 (UTC)
(：)回应：总不能因应一些人的情绪波动而在此浪费时间吧。—Edouardlicn (留言) 2011年1月13日 (四) 15:50 (UTC)
  • (：)回应：OK的！绝对可以解决！我认为因为这并不只是单单只有Google Chrome的问题而已，而是空格的问题，因此有两种有效的解决办法，一是“等待表决结果出来并做为先例”，二是“新开一个投票”，如此一来，就能将此表决结果加入格式手册，即能有效的解决问题。－Berting Li (留言) 2011年1月14日 (五) 05:27 (UTC)

(－)反对，我认为社区不应将时间浪费在所谓的空格和标点符号上。-Edouardlicn (留言) 2011年1月12日 (三) 16:26 (UTC)

(※)注意，讨论条目事务，绝不是浪费时间。这些问题很有必要进行讨论。118.21.205.229 (留言) 2011年1月13日 (四) 17:39 (UTC)
(：)回应，此事不是已经造成多次编级战、移动战、全保护和封禁了吗？若不赶快解决岂不是要发生更多的编级战、移动战、全保护和封禁？－Berting Li (留言) 2011年1月14日 (五) 07:11 (UTC)

(！)意见，此件不妨以先者为准。惟条目名称应顾虑美观等。多数中文+英文的情况应是没有空格，但也要依个案考虑，不宜统一处理。118.21.205.229 (留言) 2011年1月12日 (三) 17:00 (UTC)

(！)意见干脆都写成Google{{sep}}浏览器算了，到{{sep}}里面编辑战去，别弄得一堆内容全保护。Liangent (留言) 2011年1月14日 (五) 22:01 (UTC)
Liangent的提议不错。--Symplectopedia (留言) 2011年1月14日 (五) 22:27 (UTC)
(！)意见干脆这样玩也好，但是共识一定要有，如果什么也没决定就不好了。--Flame 欢迎泡茶 2011年1月16日 (日) 05:09 (UTC)
Liangent的提议只会浪费更多的资源。--百楽兎 2011年1月19日 (三) 04:55 (UTC)
在名称中间加空间应由决定，但我的主观意见认为在前后都上空间是不正的事，例：“终于在1998年6月25日发行 Windows 98 。”

这绝对是不好的示范。--Flame 欢迎泡茶 2011年1月16日 (日) 06:37 (UTC)

其实只要英文词之间留空就行了，中文与英文，英文与数字之间没有空格也不影响阅读，更不会出现歧义。这样就够了，维基讲究实用，而不是好看。--玖巧仔●□留言 2011年1月17日 (一) 15:57 (UTC)
“3 D”“CS 5”这样吗？ --玖巧仔●□留言 2011年1月18日 (二) 16:10 (UTC)
(！)意见看来不能一概加入空格，不过可遵循英文习惯。--苹果派.留言 2011年1月18日 (二) 22:01 (UTC)
(！)意见中文的语法应该没有规定吧。似乎讨论倾向是不留空格，至于外语之间的空格视乎命名规定，名从主人。--Flame 欢迎泡茶 2011年1月19日 (三) 03:18 (UTC)
我的(！)意见：坚决反对为了美化的目的加入空格，但原名有空格者依原名（名从主人）。--百楽兎 2011年1月19日 (三) 04:55 (UTC)
(！)意见：我只知道百乐兔你们几个的所作所为，已经严重影响到我的编辑工作（要不要给你张我监视列表的截图看看，小孩子过家家，很好玩是吧？）。目前不是这几个条目，而是已经蔓延到全部有此类空格的所有条目。
或者，让管理员做见证人，安排你们正反双方当面决斗好不好？谁赢了听谁的。
要全维基的人跟着你们一起折腾，都什么态度！

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

(：)回应那人认为哪个维基人做法比较对？--Flame 欢迎泡茶 2011年1月19日 (三) 07:47 (UTC)
对现在我很失望的是Mark85296341至今仍然未参与讨论，我很希望他能举出“我认为是用在跟电脑、资讯和电玩有关的才需使用，很早之前就在互助客栈有提到关于空格的问题，可是那存档我已经找不到了。”证据，在讨论结束，将结果加进Wikipedia:格式手册内。--Flame 欢迎泡茶 2011年1月19日 (三) 07:46 (UTC)

能否这样？

在Word中，中英混排是不需要敲空格的，系统会自动调整间隙。我们的浏览器没有这个功能，可是如果使用Thin space（U+2009），可以达到相同的效果。理论上，在Unicode 5.0中，its width may get adjusted in typesetting；在实践上，看效果：“Google 浏览器”、“Google 浏览器”、“Google 浏览器”、“Google 浏览器”。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月19日 (三) 08:47 (UTC)

囧rz……我“提出一个不好的方法”，然后怎么就“易办了”？——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月19日 (三) 09:38 (UTC)
这是因为在网页中加半角空格很不美观，而且中英文混排需要的不是空格，而是间隙（就像Word等软件排版一样）。如无间隙，看：“Google浏览器”、“ABCDH中文”，文字会交叠。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月19日 (三) 09:42 (UTC)
看到现在只有虞海知道症结。--百楽兎 2011年1月19日 (三) 09:59 (UTC)
有空格又如何？没空格又如何？我们的目的既不是给每个页面加个空格，也不是让每个页面都没有空格。我们需要只是让页面的排版正常、能看，其实现方法是加空格，或thin space。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月19日 (三) 15:55 (UTC)
(！)意见：请问百乐兔？惯例来自何处？我怎么这些年没怎么听说过？(或者说，我听说的和你的意见完全对立，大家新人的时候基本都是由老人带的，现在我们大多开始可以指导一下新人怎么编辑，难道我最开始被人教错了？)，再请问，目前是哪边人多？少数服从多数，再公平正常不过。
(！)意见：我要求很简单：
  • 停止这种无谓的事情，我只想安安静静的编辑，我不想每隔一阵子监视列表一团乱！你们也不算算，在这上面浪费了多少时间精力口水？值得？为了区区一空格！每天都有堆积如山的东西要等待填坑，要去更新、维护。把精力花在日常事务上能做多少事情了？

百乐兔你让他们一步又怎么了？为什么非得别人让你？这有道理？道理在哪里？你当面在下面答复我，我等着看，不行你来我对话页。我怎么看也是他们那边人多，你自己才是少数。你自己看看编辑历史去，哪有第二人比你更积极的？我监视列表很清楚，是你先开始的。条目从建立开始就是有空格的，到底是谁有问题？

所以我即使不赞成你的观点，我也懒得来参与这种无谓的事情，我小部分源码问题都向IP用户让步了，区区一个空格没什么不可以让步的。

本人现在现实主义者，要是我监视列表没反应，没人通知我什么的，讨论根本我来也不会来。

双方都认为自己是真理，却说不出理来自何处，完全不知所谓！

虞海的意见，我也赞成如果能形成共识最好，能完美的解决问题。但现实告诉我，以我的技术认知，这种解决方法在目前的技术上怕是行不通吧(即“有没有依照浏览器加入空格的办法”)？所以解决办法只能是，人为手工加空格，让页面的排版正常、能看，兼顾美观。

没空格会怎样想过么？我以前遇到过，有人看着没空格的标题，认知产生了歧义(在此不讨论无关的个人智商问题)。—我是火星の石榴 (留言) 2011年1月20日 (四) 07:39 (UTC)

我不知从何说起好。首先在Google Chrome的条目上，并非所有由百乐兔多次强行删除的空格我都协助加回，我只是加回繁体中文版本，即“Google 浏览器”内的空格，此条目的问就源于此。就如Red16所说的，在Google Chrome的条目一开始就已经有空格，而且官方所有的说明文件及服务条款都有空格，部分文件甚至使用引号标示[1]（英文版本[2]以及简体中文版本[3]一律没有引号），对此我的解读就是繁体中文版本的Google Chrome是有空格的。另外百乐兔在上面所说的惯例我不知从何来的，随后他亦没有加以说明。

除此之外，我个人认为可以看看百乐兔的“战绩”，他根本是在合理化自己的行为，先举部分例子（因为实在太多例子，只能举出部分），大家在修订历史可以得知，例如我在“My Name Is 邦”[4]、“上海闯荡”[5]、“保良局颜宝铃书院”[6]作出贡献后，他随即进行没有建设性的回退，大部分条目甚至是他从未编辑过，例如“上海闯荡”、“保良局颜宝铃书院”，可见他是针对本人所作出的贡献作回退破坏。可笑的是在我进行反破坏行动中竟然被3RR封禁，而且我是在没有任何警告、没有任何前科的情况下被封禁，与此同时百乐兔这位前科数不尽的破坏者只是跟我这位被无理封禁的初犯者得到“封禁两周”，另外我作出的封禁申诉完全被管理员无视，请问前辈道理在那？

另外就百乐兔其中一个意见作出一些回应，首先什么叫“纯粹是为了反对我而反对”？你自己是不是纯粹为了回退而回退本人所作出的贡献呢？第二，“然而他们却选择性忽视，咬定空格的必要性，兼又发动车轮战、傀儡战。”，是谁发动的？我吗？无视管理员多次的3RR封禁，你才是独行的发动者，而且并非单一条目上，请问你有什么资格说人呢？第三，“请勿擅加空格”，原本是有空格然后你强行删除，是你擅自删除，而非我们擅加空格。

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

您确定百乐兔是“没有建设性的回退”吗？至少我看不出。这个编辑把“| 频道 = 无线电视J2”改成了“| 电视网 = J2 | 电视台 = 无线电视”，有什么不可以？还有这个编辑，有何不妥？如果不妥的话，您应该说明为什么不妥，这样大家才能知道。不然的话，只能当作编辑战来处理，就是把参与编辑战的所有人都封禁一定的时间。--Symplectopedia (留言) 2011年1月20日 (四) 19:23 (UTC)
(：)回应把“| 频道 = 无线电视J2”改成了“| 电视网 = J2 | 电视台 = 无线电视”模版是不会显示“无线电视”的。此外大部无线电视J2的节目都是显示“无线电视J2”，并且使用J2模版。另外，不只是单一条目出现“没有建设性的回退”，只要看看他的“用户贡献”，例如在2010年12月10、29日连环直接删除我的编辑，并且删除他不喜欢的空格，删除他不喜欢的空格不是一个大问题，但他明显地针对我的贡献作回退行为。同时他的“用户贡献”在2010年12月29日亦证明是他先发动编辑战。关于这个编辑我应该反问我删除(+852)及没有连结的人名的“[[]]”有何不妥，而且这个编辑跟上述原因一样“连环直接删除我的贡献”。--HKH 2011年1月20日 (四) 20:43 (UTC)
(：)回应我想反问你哪些条目需要空格，哪些条目不需要空格，如空中客车A380（Airbus A380），根据你的逻辑应否改为空中客车 A380呢？我想各位研究一下，事实英语等外语是需要，但以以上例子在中文是不是有必要呢？正如在排版本会不会变得不美观？--Flame 欢迎泡茶 2011年1月21日 (五) 00:56 (UTC)
(！)意见：我澄清一点，我说的是我们这边自己的条目，不是HKH说的google chrome，这和我是否google fans无关，谁都知道，我在维基甚少参与IT类条目的编辑。
(！)意见：另外，替人回答HKH，百乐兔和你的区别，就是他曾经长期是维基的资深管理员，后来是他自己辞了还是怎么样，我是忘了，反正管理员那边应该有记录。这是事实。至于是否有人会解读为管理员群偏帮私，我管不了。
重申一遍：我这次过来就是因为有关人员的行为已经长期干扰到我的编辑(我个人喜好整洁，不想自己监视列表里面乱七八糟的)，平时的话，我一般是不过来的(你们可以看看，这次之前我上次来方针区还是什么时候了)。为了一点又不是涉及原则立场等根本性的东西，花上大把时间精力和口水，到最后又会不了了之，烦了。效率不说，根本不值得。我现在在维基只想安安静静的编辑，其他事我不想管。换句话说，只要不干扰到我自己编辑，其他事我没什么意见。—我是火星の石榴 (留言) 2011年1月21日 (五) 07:54 (UTC)
(！)意见：我没当过中文维基百科的管理员也不想当中文维基百科管理员。会不会知道是惯例从你这个发言就看得出来。你的监视列表如何如何都不干我或任何其他人的事，我或任何其他人编辑的时候也不会去考虑你的监视列表变得怎么样，没有人有义务在编辑时还要顾虑维持你监视列表的整洁。你的要求去英语维基百科去喊喊看，看看会不会被当成一则天外奇谭。劝你不要像ACG脑一样，浸淫ACG久了就ACG脑化了。--百楽兎 2011年1月21日 (五) 10:04 (UTC)
(！)意见：我不知道某日当有人登陆自己帐户，点开监视列表一看，有将近200条同类型的移动日志，然后第二天发现同类型日志又再200条，只不过是另外一人给移回去了。如此之事，反复将近10次，不知道各位有何感想？我欢迎管理员将监视列表上限提升到1万，这样短期内估计不会有不够用的情况出现。—我是火星の石榴 (留言) 2011年1月21日 (五) 11:58 (UTC)
(！)意见：显然你说的事不是我做的。既然我没做过你说的那种事就别算在我头上。--百楽兎 2011年1月21日 (五) 14:29 (UTC)
(※)注意如发现某维基人刻意破坏的话，请到WP:VIP申报，就各位维基人继续就此事作出讨论。另外HKH也不要对此无直接关系的事作出讨论，以免影响讨论环境。--Flame 欢迎泡茶 2011年1月21日 (五) 08:03 (UTC)

整理一下

其实我是支持加空格的。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月22日 (六) 18:59 (UTC)

(！)意见：个人建议百乐兔尽快通过申请CU来CU你自己的账号，以此证明此账号没有被人盗用来做出以上行为，错怪好人就不好了是吧。

所谓移动战，一个人当然是玩不起来的，没人会移回来又移回去，自己玩自己吗？问题的焦点在于：到底是谁先开始的？你仍然坚持不是你先开始而是对方吗？

事情的前因后果事关重大，怎能不搞清楚？监视列表大家通用，随便去后台调取数据好了。

事实1：这次的事情，纯粹就因为有人因为一个空格争执不下，结果引发了断断续续持续一年多的移动战，还引发了双方各自3RR封禁等，是谁一开始发动了移动战当然很重要。

事实2：很多条目自创建始，就是带空格的，这点可以调最早的页面编辑历史记录来看，现在早已超出了Google Chrome或者norton 360的范围，扩散到全维基所有带空格的条目。

事实3：空格问题，论官方的话，比如微软、空客，从来没有也不会有人出来说，我们公司的产品名称在中文中要带空格还是不带空格，带空格就是错，不带空格就是对，是真理。

所以，上面拿个A380出来，又能彻底证明什么呢？大不了最多证明空客而已，能证明其他公司的其他产品？被代表？

一般人谁会去注意这种细枝末节的事情，更遑论有一群人为此争论了一年多。传出去真是笑柄。

所以，我说过，我不会参与这种移动战。有人要我让他，没大问题的话就让了吧，又不是技术上解决不了，所以，如果最后的结果是没空格而虞海的方法在技术上行得通的话，我也没什么意见，可以接受。

事情根本从一开始就是错的，开始的时候，双方无论谁让了一步，这事情根本都没了，哪有现在？

问题：为什么百乐兔你不能让一步，非得别人让你不成？ 你不解释的话，这问题根本说不通。人家至少还说得出，条目开始就那样，有历史可以查嘛。

那个惯例，我也没听说过，谁来科普下？

我火什么？好不容易安静了几个月，现在想来是百乐兔你被封禁了而已（如果最后只能用封禁解决问题实在是杯具彻底），你大概什么时候解禁我也有数，我曾经看过日志。结果呢？果然不出所料，又给全部移回去了（就几天前的事，赖什么，往哪儿赖？），这第几次了？我都数不清了。当这里是什么？私人领地？自家后花园？自己地盘高兴怎么玩怎么玩去，这里还有一堆人，有哪个在动手编辑之前想过其他人了？你是在反破坏吗？多了个空格就是破坏吗？

综上：

(！)意见：这次要说就说说清楚，一次性解决问题，要讨论多久时间不是问题。事情都有前因后果的，前因后果无关？忽视着前因后果来讨论吗？第二，“目前意见倾向于不留空格”，不认同，讨论不够充分彻底，这里真正参与讨论的才几个人？当事人都还没到齐呢。第三，即使得出结论，怕也只能作为一个编辑指引而已，只能建议，这又不是GFDL，强制性的，日后，多了个空格能当封禁人的理由么？

个人意见，倾向于最初的原始版本，即最初的版本是有空格的，那就是有空格的。最初没有就没有，一切恢复到事情开始之前。

虞海的意见，我感觉技术上行不通。要做先把N个浏览器一个个测试下来，想出解决方案再说，别忘了，还有手机浏览器呢，各个版本之间的不同之复杂性，比桌面浏览器麻烦N倍。有人要做，慢慢测试吧，出来个新版本就得全部推倒重来一次，平均大概一个月要做一次测试。

注：以上有一点例外，就是有人拿着正式的官方说明文件来，里面清楚说明是要还是不要空格，名从主人嘛。这估计谁也没意见了吧？那也只是个案，个案按个案一个个处理。—我是火星の石榴 (留言) 2011年1月21日 (五) 18:35 (UTC)

  • (：)回应我以前打趣地说，如果一早向Google公司查询的话，所有问题都可以迎刃而解。只是有人会去查询，而他们会否答复这个问题。不如这样，举行投票吧。决定在一般情况下“应否使用空格”？--Flame 欢迎泡茶 2011年1月22日 (六) 00:53 (UTC)
(！)意见：百乐兔说惯例，你来维基多少年了？移动战始于2010年，之前这些年你在干吗？你不知道以前就有这个情况(指空格)？而惯例当然也不是2010年才形成的。才形成的东西能称为惯例吗？
我以为，当事人的一方，始终逃避问题，绝对不是解决问题的方法，你站出来以理服人啊。
知道我第一次看到移动战是什么感觉？我第一反应是被盗号，这ID后面的主人换人了。
ID后面的主人是否换人了大家管不着，在网上大家都只认ID，谁犯规，谁出局。
虞海的那个方法，其实真行不通，太难了。手机/手持设备的浏览器啊，比如吧，UC升了7.5，结果(指某新兴门户，alexa排名500以内)，普通屏，老的7.2看倒正常，7.5反而不正常。触摸屏设备上全部倒过来了(最近正为此问题头痛)。怎么办？告诉用户是你的设备问题，强制人换设备吗？你认为别人是会花几千去更换设备，还是干脆说一句，“我看不了你这个网站，我不来总行了吧？又不是吃饭，不吃饭是会死人的，不看你这个网站会死人吗？”哪个可能性更大呢？
刚才苹果派也来问我有关投票的意见，无非嘛
1.全面禁止空格，有空格是错的。（百乐兔）
2.禁止空格是错的，有空格才是对的。
3.恢复到第一次移动战之前的样子，恢复原状，是否使用空格自由控制，但可做一个编辑指引，指维基惯例（附条件1：要提惯例，先把惯例原文找出来再说，否则免谈）是不使用空格的，是否遵守此惯例，由各人自由把握。
任何人皆尊重最初编辑者的最初原始版本，不得再次发动类似的移动战，如有违反就不说了。
我所说的最初原始版本，是指当前条目内容具有可读性，也就是当前条目内容的主框架大致形成，内容基本稳定，不会产生剧烈波动变化（尤其是大段内容的清空删除）的那一天开始算起。
条目内容能基本稳定，即代表参与当前条目内容的编辑者们内部本身形成了一个默契，当前条目内容本身，并无大问题。
日常的编辑中，自然也包括对空格和标点符号等的使用。
比如我和很多人写条目，都是一天内写好，然后名称移动到位，重定向建立完成什么的，全部是一次性完成，加上本身就是条目的初创者，这样从第二天就可以开始算起了。但也还有例外情况。
一个条目立起来4-5年了，某一天突然跑来一个此前既没参与编辑，更加连关注都没关注过这个条目的这样一个人，一跑来就直接发动这种移动战，当然应该直接禁止。
连一个空格都容不下，还是海纳百川、有容乃大的维基百科吗？
坐等围观格式手册中出现这么一条：维基百科禁止空格，违者封禁！

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

  • 现在也是举办投票的成熟时机了，我们应该要谈及在哪些时候加开空格。第一，为条目美观，随时都可以加空格。第二，只在特定条目（如电玩、资讯科技）等加上空格，第三是在得到官方许可下才加上空格。--Flame 欢迎泡茶 2011年1月23日 (日) 01:42 (UTC)

一个空格的问题（续）

以下内容移动自互助客栈，新留言请置于框外。

投票暂定区

注意：此部分仍中文与外语之间应否留有空格？投票方案仍在拟定，仍未开始。--Flame 欢迎泡茶 2011年1月23日 (日) 06:53 (UTC)

方案一：随时都可以加空格。
方案二：只在特定条目加上空格，需到该页面讨论页进行表决（如：Talk:Google Chrome）
方案三：除非得到官方认可，否则不能加上空格。
方案四：在任何情况下不得加上空格

—以上未签名的留言由Flamelai（对话｜贡献）加入。

晕死……——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月23日 (日) 11:51 (UTC)
方案5：使用thin space并设立开关，自动将thin space替换为nothing/thin space(保持不变)/空格/nbsp。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月23日 (日) 11
58 (UTC)
(！)意见：对方案5，已上述，如何保证在技术上实现任意版本浏览器通用，而保证不会出现挑版本挑浏览器的问题？有点技术经验都知道，这种兼容性测试最困难(基本上也没人能保证肯定不会出现兼容性问题)（—以上未签名的留言由Red16（对话｜贡献）于2011年1月23日 (日) 12:54 (UTC)加入。）
(：)回应：对方案5，肯定要调试一段时间，等系统稳定下来以后，就可以制作机器人了。（一边英文字母，一边汉字这种情况对机器人来说可就是小菜一碟）。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月23日 (日) 14:18 (UTC)
(！)意见不是所有浏览器支援，这需要维基人申报。--Flame 欢迎泡茶 2011年1月24日 (一) 08:58 (UTC)
方案6：以条目内容成型的最初原始版本为准，尊重最初原始版本的编辑者的选择（是否使用空格）。详细见上述。—我是火星の石榴 (留言) 2011年1月23日 (日) 12
54 (UTC)
对方案六，那会造成维基内部的格式不统一。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月23日 (日) 14:18 (UTC)
(！)意见这造成日后创建先到先得的恶果，在对此原先创建的条目影响轻微。--Flame 欢迎泡茶 2011年1月24日 (一) 08:58 (UTC)
(！)意见：请问对于一个空格的先到先得，会存在什么恶果？，一时我还真没想到。—我是火星の石榴 (留言) 2011年1月24日 (一) 11:52 (UTC)
方案7：对于每一个有争议的名词，分别建立投票，加或者不加，55决。在投票之后，按照投票结果执行，且3个月内不得重新再开投票。--苹果派.留言 2011年1月23日 (日) 16
43 (UTC)
此为最会开玩笑的方案，3个月后投票不就等于作废？—Edouardlicn (留言) 2011年1月23日 (日) 17:01 (UTC)
3月后投票也不会作废，不过允许再发起投票推翻之。方针尚允许推翻，这个不应该不允许推翻啊。在未被推翻之前，仍然有效。--苹果派.留言 2011年1月23日 (日) 18:55 (UTC)
(！)意见：你这不现实啊，这样我们不是整天忙于投票决定(附加还有辩论 耗时啊)？我们还干别的不？—我是火星の石榴 (留言) 2011年1月24日 (一) 11:52 (UTC)
(！)意见看似颇难执行，但是亦无道理，个别条目应有个别讨论解决。--Flame 欢迎泡茶 2011年1月24日 (一) 08:58 (UTC)

(：)回应：根据以往经验，只要Flame出手的争议，结果大都很悲惨；这回又是一例。建议Flame热心调停前，先摸清来龙去脉，不要每次事情规划阶段热哄哄，草率的开场，然后弄到一半后，虎头蛇尾，就等着有人帮你收拾残局。--Winertai (留言) 2011年1月24日 (一) 02:17 (UTC)

(：)回应不用你担心了，今次会彻底去到完场为止。现在投票还没开始，别那么快下定论。--Flame 欢迎泡茶 2011年1月24日 (一) 02:27 (UTC)
(：)回应我记着您这句承诺。不过，提醒您：这次问题牵涉到“惯例”，“移动自由度”，“如何认定条目真正名称”，“一致性”，“符合惯例及方针的合法移动及编辑是否涉及扰乱维基”等等难解问题；您在规划投票前，请先预设到当投票结果“不符合现有命名规则”，“不符合惯例”，“适用范围”及投票选项过多时等等怎么处理的问题。--Winertai (留言) 2011年1月24日 (一) 02:39 (UTC)
(！)意见还有没有人提及更多方案？各位可以在1月25日23:59(UTC)提出你的意见。--Flame 欢迎泡茶 2011年1月24日 (一) 08:58 (UTC)
  • 强烈(－)反对：天啊，那得投多少票啊？１＋２＋３＋４＋５＋６＋…——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月24日 (一) 09:35 (UTC)
  • (：)回应不过你认真看到我的意见的话，其中一两个选项会被拔掉，所以应该选项最多只维持四个左右。--Flame 欢迎泡茶 2011年1月24日 (一) 15:29 (UTC)
    况且我们在这里讨论的目的就是让以后存在严重争议的条目越少越好：大多数条目受一个大家都同意的指引控制，只有个别几个情况特殊到指引起不了作用的条目才做单独的“讨论－投票”解决。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月24日 (一) 09:38 (UTC)

(！)意见--建议可改为两大方案如下，但不知技术上是否可行：

  1. 编辑时不加空格，显示时系统自动加上间隔（如thin space）（官方回复明确表示要加除外）
  2. 编辑时必须加空格（官方回复明确表示不加者，系统自动加上间隔（如thin space））

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

(！)意见：这不就是方案5的简化版嘛，我认为技术上不可行，浏览器版本的复杂性，由此带来的天文数字般的兼容性问题。我还是那句，你不能告诉别人这是设备兼容性问题(很多手持设备浏览器是固化的，即使可以换，动手换浏览器需要一定的技术能力，不是windows那种一路next可以解决的，很多人只会用，折腾软件这等于要人老命了)，你要人家换设备，人家可以不来看总行了吧？—我是火星の石榴 (留言) 2011年1月24日 (一) 11:52 (UTC)
(＊)提醒：不要把一切重担都给都浏览器，很多任务服务器是可以承担的。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月24日 (一) 18:52 (UTC)
(！)意见：不是一切在服务器端都能解决的，比如你在服务器端布置到位，正常了，也要浏览器能支持并且正常显示才行。CSS、脚本这一切都需要由浏览器来执行，而不是让服务器来执行。代码错一行，浏览器就有可能卡爆了，所以浏览器才是真正的关键。—我是火星の石榴 (留言) 2011年1月25日 (二) 09:55 (UTC)
  • (！)意见再整理剩下来比较合方案（主要整合部分维基人的意见），过两天可以开始投票了，规则是哪一方案超过50%，就可以通过，如第一轮投票没有一个方案超过50%的话，就进行第二轮投票，结束后有方针加在Wikipedia:格式手册上。
方案一：除非得到官方认可，否则不能加上空格，显示时系统自动加上间隔（如thin space）。
方案二：以条目内容成型的最初原始版本为准，尊重最初原始版本的编辑者的选择（是否使用空格）。
方案三：对于每一个有争议的名词，分别建立投票，加或者不加，以55表决。

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

    • 谢谢整理。方案一者，建议将“官方认可”改为如“根据官方回复”等较明确字眼，否则“何谓官方认可？”可能引起争论。不过根本问题是技术是否可行。方案二者，若那版本第一段有用空格，第二段没有用空格，应根据哪一个。方案三则似乎不及确立原则来得彻底。欢迎讨论。--Gakmo (留言) 2011年1月26日 (三) 03:01 (UTC)

投票区

注意：投票仍未开始。
投票时间：2月10日0:00 至 3月10日23:59（UTC）（暂定）
投票方式：每人可投一票，不设反对票，如没有一个方案超过半数将进行第二轮投票，在这个时间最少得票的方案将会剔除。重复投票均视为无效。可以在投票简要地说明意见，过长句子将会被移动至意见区。（暂定）
方案一：除非得到官方认可，否则不能加上空格，显示时系统自动加上间隔（如thin space）。（暂定）
方案二：以出现添加空格或删除空格的第一次移动前为准，尊重最初原始版本的编辑者的选择（是否使用空格）。（暂定）
方案三：对于每一个有争议的名词，分别建立投票，加或者不加，以55表决（例）。（暂定）

意见

以下与讨论议题无关之意见移至他处讨论--Winertai (留言) 2011年1月26日 (三) 01:14 (UTC)

(：)回应：我只要求“显示时系统自动加上间隔（如thin space）”这兼容性测试谁去做？如何保证在每个版本的浏览器上都显示正常？你不能回避问题啊，也不能等每次有问题再改再测试，这样以后很麻烦的。我个人是不觉得方案2有什么问题，同一个系列的东西，一般是同一个人开条目的几率很大，自然也会把个人的编辑习惯带入到新条目中，再说，本来有点小问题可以私下协调的（其实这次也是 可惜有人自己放弃了这个机会，非得闹大不可）—我是火星の石榴 (留言) 2011年1月26日 (三) 09:41 (UTC)
(：)回应：（见下面）
尽管理论上我更赞同方案1，但技术实现上我还是要提出一个
修正方案：除非得到官方认可，否则不能加上普通半角空格；由机器人自动添加thin space；显示时，通过类似于简繁转换系统的小工具（Gadget）将thin space去掉。
这在技术上对浏览器没有任何要求。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月26日 (三) 17:08 (UTC)
(～)补充：在源码中置入thin space，不代表原文中有thin space。源码中的thin space，与“-{”、“}-”一样，只是一个开关。另外：源码
  1. “ ”或“ ”代表一个空格开关，显示时依用户选择变为“”、“ ”或“ ”。
  2. “ ”代表一个真正存在的窄空格。
——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月27日 (四) 09:53 (UTC)
怎么又投票？最近怎么总是讨论的挺好的情况下，突然就要开始投票了，寻求共识不好吗？--百無一用是書生 (☎) 2011年1月27日 (四) 07:16 (UTC)
  • (－)反对，我也反对如此快速的进入投票，“投票不能代替讨论，投票是不得已的最终手段”，这里实际参与讨论的人这么少，应再寻求社群共识。（个人建议：至少等到2月中旬，如无共识再寻求“最终手段”）－Berting Li (留言) 2011年1月27日 (四) 10:50 (UTC)
  • (：)回应Shizhao和Berting Li：没有办法，中文维基里只要有人质疑“共识是否真的达成了？”就会带来投票。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月27日 (四) 12:10 (UTC)
  • (：)回应，我的意思是说“1月28日”（今天）就开始投票实在是言之过早！本讨论都还未届满一个月呢！至少要等到届满吧！个人建议至少能让社群充分讨论到2月10日～2月中旬，还有，投票期限只有一个礼拜？Google Chrome#投票投了快一个月才只有3票；而下面的条目声明投票投了快10天才只有2票，如此重大的社群争议只需要一个礼拜就能累积到足够令社群信服的票数吗？（而且还遇上“返乡过年”），目前的投票时间、期限、方式与项目之后应标明“（暂定）”，并不是每个人都同意这几点。－Berting Li (留言) 2011年1月27日 (四) 16:47 (UTC)


Re虞海，我只能说，希望如此(没经过测试的事我不敢说)。
另外，要求确认投票门槛，万一只来10人参加投票 6:4通过 怎么办？最多只是这10人之间的共识，能代表全维基的所有人？过几个月再来？
国外公投都说，投票人数少于登记选民的5成，结果作废。
对应到维基，应该算活跃用户中有多少人参与投票，必须达到一点的门槛比例—我是火星の石榴 (留言) 2011年1月27日 (四) 10:32 (UTC)
(：)回应“投票人数少于登记选民的5成”：
  1. 不管怎么说，维基不是民主试验场的共识我们还是有的
  2. 投票中有一个问题是永远避免不了的——给权不要——你永远拿他们没辙，never。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月27日 (四) 12:10 (UTC)

个案回馈

下一段落内文，是我针对诺顿 360要不要加空格的历史发言纪录，后来某位当事者说这现象代表“空格不代表名字一部分”；请大家拨冗看下面文字，再依各位看法，要不要加空格？另外，我是在想，可不可当有争议时，全部按照建立条目者之所在地区的“产品封面所示名称”来区别要不要加空格，并由三位以上管理员取得共识，来决定空格要不要加，并以“避免浪费资源”为由来定案不准移动，这样不知可不可行？我看到上面那些密密麻麻投票方案，头痛了。--Winertai (留言) 2011年1月27日 (四) 14:19 (UTC)

赛门铁克网站：产品名称本身、网页标题（...Symantec.com > 诺顿 > 产品讯息 >诺顿 360 4.0 版本）有空格，但是网页右边的产品叙述内容（...毒防骇, 防被诈骗, 防电脑慢, 防护资料

——诺顿360），却又没有空格。以前不知道有没有类似例子，该采用产品封面的名字，还是说明内文叙述上的？--Winertai (留言) 2010年9月17日 (五) 00:17 (UTC)
维基百科条目的内容不应该交由某几个管理员来决定，即使整个社群也不能决定维基百科的内容（极端的情况，如果社群绝大多数人都认为进化论是错的，难道就要在条目中说这个理论完全错误？）。具体到这个空格问题，个人认为应该个案处理。如果非要有一个全面性的方案，那我觉得可以规定除非除非使用空格有特别意义，那么一般情况下不需要使用空格--百無一用是書生 (☎) 2011年1月28日 (五) 07:43 (UTC)
方案2改成“以出现添加空格或删除空格的第一次移动前为准”比较好。如果真的出现为了空格而抢建条目的情况也没什么不好，只是那几个人自己累而已。--达师 － 198 － 336 2011年1月28日 (五) 08:10 (UTC)
(：)回应：同意达师，请Flame协助修改。
书生，这其实是排版的问题。
一个门槛票数对任何一个投票都是用，这样吧，最多事情完了另发起讨论。维基不是民主试验场，但原理是一样的，就比如管理员任免投票，只出来10人参与投票的话，同样不能代表大部分人的意见。—我是火星の石榴 (留言) 2011年1月28日 (五) 13:05 (UTC)

方案6为什么不进入投票？？

以条目内容成型的最初原始版本为准，尊重最初原始版本的编辑者的选择（是否使用空格）。我觉得这样很好啊。—Edouardlicn (留言) 2011年1月30日 (日) 03:21 (UTC)

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

随便说点问题

  • 由于wikitext的复杂性，在源码里面机器人准确地加减空格不是那么简单的，除非用了特殊占位符标记（如上面的thin space和我说的{{sep}}）：考虑这个情况，源码里面写了{{someTemplate|english中文}}，这个中间要不要有空格呢？如果不加，someTemplate可能把参数直接显示；如果加了，someTemplate可能把参数当模板名调用另一个模板。
  • 放弃旧设备兼容性的事维基已经干过了，见wikitech:Mobile#Supported Platforms/Languages。
    --Liangent (留言) 2011年1月31日 (一) 17:35 (UTC)
(！)意见：之前没注意，那可以按一般人的想法估一下，是会就此去更换设备适应维基的人多还是就此放弃维基的人多呢？毕竟这些东西的价钱都很那啥，普及率还远没到人手一部—我是火星の石榴 (留言) 2011年2月1日 (二) 14:32 (UTC)
(！)意见：长篇才是维基主流吧？机器人不行的话还是只能人工手动，岂不是又回到原点了？—我是火星の石榴 (留言) 2011年2月1日 (二) 13:16 (UTC)

——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月3日 (四) 15:20 (UTC)

新的提案

  • 以英文命名的条目：按照英文维基或官方的命名
  • 以中文命名的条目：除非官方命名有空格，否则一律禁止使用空格
(！)意见：要是官方命名有空格，维基百科也加上空格了，但却有人发现官方也并不统一，有时有空格，有时无空格怎么办？--Atry (留言) 2011年3月3日 (四) 05:36 (UTC)
  • 外语译中的条目（例：诺顿360）：除非有特别理由（系列作品等），禁止使用空格
  • 系列作品的条目（例：牧场物语 双子之村）：可以使用空格

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

建议使用间隔号，如《牧场物语·双子之村》。--Isnow (留言) 2011年2月4日 (五) 16:58 (UTC)
间隔号在日文语境里用的更多，但是在中文语境里是不是应当限定仅用于系列作品？--Mys 721tx(留言)-U18协会 2011年2月4日 (五) 17:24 (UTC)
好问题。但应该仅限于作品。有则有，无则无。没有或使用其他标点符号者应尽量维持，除非所翻译的作品与原名有极大差异。--Flame 欢迎泡茶 2011年2月5日 (六) 07:56 (UTC)
系列游戏的子标题个人倾向于冒号。--达师 － 198 － 336 2011年2月5日 (六) 14:48 (UTC)
用冒号会不会犯了原创研究？不过这可能是日语习惯不会在副题前用上“冒号”，所以这方面习惯应该可以研究，这包括了电影、游戏等。--Flame 欢迎泡茶 2011年2月8日 (二) 01:31 (UTC)

PhiLiP CSS OverflowHidden 方案

试试看：中文 English，讨厌看到空格的请在小工具里启用用户界面工具->取消汉字和拉丁字母之间的间距。--菲菇＠维基食用菌协会 2011年2月6日 (日) 07:51 (UTC)

(※)注意：菲菇用的{{sep}}是nbsp，而非thinsp。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月6日 (日) 07:55 (UTC)
那个 是用来避免MediaWiki使用的tidy把空的HTML entities给删掉而加上的，你看到的间隙不是它产生的：因为css里直接把width和max-width全部设成了0px，而由margin（外边距）来产生你所看见的间隙，见[7]。--菲菇＠维基食用菌协会 2011年2月6日 (日) 07:59 (UTC)
试试看把这一段加到Special:mypage/vector.css去，这样你看到的间隙更开：
.template-sep {
    margin: 0 1em !important;
}
以上。--菲菇＠维基食用菌协会 2011年2月6日 (日) 08:11 (UTC)
这倒是个不错的法子（虽然现在过宽了一点），缺点是{{sep}}无法用在标题里。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月6日 (日) 08:15 (UTC)
此外还有问题：在Opera里确实只有间隙没有空格，但在Firefox里却产生了一个x0020空格。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月6日 (日) 08:19 (UTC)
宽度你可以自己调整，上面已经给出来了。Copy的问题，可以用js把innerHTML给清空，但我觉得没这个必要（因为有损性能）。--菲菇＠维基食用菌协会 2011年2月6日 (日) 08:20 (UTC)
总结一下，以下问题：
  1. 标题上怎样使用；
  2. 间距能否proportional；
  3. 选中“取消汉字和拉丁字母之间的间距”后间距消失，但依然会copy出0020来（怎样做innerHTML?）
——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月6日 (日) 08:35 (UTC)

我倒想把tidy自动去除empty html entities的行为报bug，刚才在MediaZilla:上搜了下之前有没有人报过，但没有找到，召唤liangent出来帮忙找。--菲菇＠维基食用菌协会 2011年2月6日 (日) 08:25 (UTC)

这名字我随手写的还真用上了……Liangent (留言) 2011年2月7日 (一) 17:08 (UTC)

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

(！)意见：达师，你又把问题复杂化了，我之前一直没再发言，就是因为我觉得，菲菇提出了一个很好的解决方案。好像剩下的，也就是百乐兔的反对了吧？—我是火星の石榴 (留言) 2011年2月10日 (四) 13:32 (UTC)

  • (：)回应我又不是这样看，现在写个方针，总好过无止境讨论。大概之后应该会出现比较好的整个方案，我现在也根据某些经验去编写，奈何时间不多，只好交由其他人完成。--Flame 欢迎泡茶 2011年2月11日 (五) 01:46 (UTC)
  • @Red16：我感觉菲菇的方案技术上有局限，难道能在所有中英文之间加上{{sep}}？开一个bot对付所有最近更改？貌似有些难度吧。而且，另一方面诺顿360是否加{{sep}}恐怕又要一阵吵。再考虑到日本游戏，于是才想到开这个，要不我也懒得插手 -_-|| --达师 － 198 － 336 2011年2月11日 (五) 01:54 (UTC)
(！)意见：日系仅限游戏么？ACGN(轻小说)现在不分家的。被人喷ACG脑也罢了(事实上我根本不是我怕什么)。—我是火星の石榴 (留言) 2011年2月11日 (五) 16:42 (UTC)
(！)意见：看来，这问题又会沦为无法解决的悬案。大家都还是搞不清楚：这问题共识真正难产的原因，在于关注者的真正态度，要达成共识其实很简单，就是要找出真正的利害关系人，请他们就让步程度做说明。讲直点，这空格鸡毛蒜皮问题除了几位打过编辑战的维基朋友外，不管是我，达师，石榴，Flamelai，菲菇，甚至书生，都是无所谓小事情。换句话说，只要关注空格的社群朋友达成协议，问题很快就会解决。反观，若这些战斗力十足的利害关系人不首肯，再多讨论都枉然--Winertai (留言) 2011年2月12日 (六) 04:05 (UTC)
(～)补充：还是不识像啰唆一点，在我看来版面上的“投票动议”或“格式手册修订”或“小工具修改”都是谈判手段上的“临崖手段”，就是逼迫当事者出面说明底线的方法，因此不管这三种方法哪种方法付诸试行，决对有其解决问题效果，因此我是赞成哪种方式都可，为了减少资源浪费，这三种试行多数决共识是必然历程了，现在就端看议案主持人的魄力与政治手腕了。--Winertai (留言) 2011年2月12日 (六) 04:16 (UTC)
(：)回应目前就是欠了一个更有力的方案去元美解决此事，好像以前某个方案都是悬而不决，直到将多个方案合而为一后，就容易处理了。--Flame 欢迎泡茶 2011年2月12日 (六) 04:57 (UTC)
(：)回应：从现在讨论进程，看不岀“容易处理”的迹象。只是越来越复杂。--Winertai (留言) 2011年2月13日 (日) 09:44 (UTC)
(：)回应过了几天，还有没有人对此有意见？--Flame 欢迎泡茶 2011年2月17日 (四) 15:52 (UTC)
对什么有意见？Wikipedia:格式手册 (空格)吗？对Wikipedia:格式手册 (空格)的意见我已经写明了。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月17日 (四) 17:11 (UTC)
(：)回应我指其他人。--Flame 欢迎泡茶 2011年2月21日 (一) 00:59 (UTC)
给我三天时间，去完成一个完美的方案。--Flame 欢迎泡茶 2011年2月21日 (一) 00:59 (UTC)
我先符加一点序言，在中文语境内，字与字之间应该没有空格，但是有些情况下可以获得例外。--Flame 欢迎泡茶 2011年2月21日 (一) 01:17 (UTC)

一个空格的问题（续2）

最后的方案

应该去到最后一步，我想的是如果此部分没有人提出异议（反对意见）的话，我希望可以在一星期内达成共识，这部分写在Wikipedia:格式手册即可。

在中文语境内，字与字之间应该不留空格，但由于部分近期的争吵，因此在此写明在哪时候留下空格，而哪些时候不应：

    1. 正文内，中文和一般数字、中文和外文间不加空格。反例：港铁 rev13627175，首段。
    2. 上方说明：如引用传媒的新闻标题，一般惯例不用标点符号可以留下空格。
      • 特别地，专有名词内的中文和数字、外文之间，适用上方的共识。（例子：诺顿360，下方详述）
    3. 外文间保留空格。（例子：Google Chrome）
    4. 符号和数字、符号和外文间不加空格。（例子：System/360）
    5. 作品名内（中文和中文间）的空格，建议使用冒号（例子：轩辕剑叁外传 天之痕，再讨论），建议在作品的主题及副题使用，由于韩语没标点，日语不在使用冒号，这点特别要注意。
    6. 上方共识。
      • 上方共识的补充说明：除非官方宣布名称内含或不含空格，差异只有空格的2个或多个条目名称在与其他条目名称比较时视为同一个名称。
    7. 全角空格的使用，但在大多数的情况下不应使用全形空格。
    8. 技术需要以及模板内需要例外。
    9. 在无争议的情况下，建议使用先到先得的方式，以减少磨擦。
    10. 如有争议，请先到该条目的讨论页或Wikipedia:移动请求反映有关问题。

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

(＋)赞成(＆)建议：若可以，请主持人罗列相关编辑战条目，略述在此格式共识下，相关条目最适名称，以避编辑战再起。--Winertai (留言) 2011年2月24日 (四) 04:27 (UTC)
好像上面忘了外文与数字之间的空格问题。全角空格应该不允许使用，但是技术需要例外。--百無一用是書生 (☎) 2011年2月24日 (四) 06:55 (UTC)
(！)意见：请Flame将要添加的新相关内容先以“注释”方式(隐藏)放于Wikipedia:格式手册--Winertai (留言) 2011年2月25日 (五) 03:08 (UTC)
(：)回应这几天有点忙，我会尽量处理一下。--Flame 欢迎泡茶 2011年2月25日 (五) 15:07 (UTC)
如各位再有任何意见，欢迎提出。--Flame 欢迎泡茶 2011年2月27日 (日) 09:07 (UTC)
讨论已接近一个星期，暂时未收到特别大的反对意见，如意异议，此部分将会被写入Wikipedia:格式手册内。--Flame 欢迎泡茶 2011年3月2日 (三) 03:13 (UTC)
(！)意见在一个星期内，未收到任何反对意见，本人稍稍润饰，在Wikipedia:格式手册上说明。--Flame 欢迎泡茶 2011年3月2日 (三) 14:57 (UTC)
我还是反对的，最近客栈被墙，一直进不来。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年3月10日 (四) 13:27 (UTC)
（注）我的反对意见和2月24日的一致，至今未有针对该反对意见的反驳。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年3月14日 (一) 06:29 (UTC)

意见

我还是反对的，最近客栈被墙，一直进不来。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年3月10日 (四) 13:27 (UTC)
（注）我的反对意见和2月24日的一致，至今未有针对该反对意见的反驳。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年3月14日 (一) 06:29 (UTC)
请提出详尽的反对理由，而不是为反对而反对。试图将这个讨论成为月经文绝对难看。还有虞海提出的不是空格，而是标点符号，请另开新的讨论提出，谢谢。--Flame 欢迎泡茶 2011年3月14日 (一) 07:10 (UTC)
(：)回应：我是说这个“最后的方案”还很不完善，对细致的内容作了过于苛刻的规定，其中包括：
  • 第五条“作品名内（中文和中文间）的空格，建议使用冒号”：不苛刻但很诡异；
  • 第一条“正文内，中文和外文间不加空格”：过于苛刻，属于一概地否定；
  • 第一条“正文内，中文和一般数字间不加空格”：赞成；
  • 第七条“全角空格的使用，但在大多数的情况下不应使用全角空格。”：赞成；
  • 第八条“技术需要以及模板内需要例外。”：我认为模板中的一些修饰性空格可以去掉（如cite中），构成Tab的除外；
  • 第九条“先到先得”会导致格式的不统一（类似于有的章节标【】有的不标），我认为不如“最终用户设定”的好，不过部分地可以接受（只要别太难看了就行）；
  • 第十条我支持，只可惜那是句重(chong2/ㄔㄨㄥˊ)话，等于没说。
等等。
而我前面提出的异议相当于今天提得的异议的一部分（即第一行）。
——以上未签名的留言由虞海（对话｜贡献）加入。 2011年3月16日 (三) 08:40 (UTC)

本主题全部或部分段落文字，已移动至#关于虞海提出的讨论。执行人：Flame 欢迎泡茶 2011年3月16日 (三) 09:12 (UTC)。

说出来简直笑话

为了米国的一家商业公司在某天拍脑袋想出来的名字，你们居然讨论了几个月都没有结果。其实尊重词条创建者即可，根本不需要为如此无聊的事情再去建立一个什么手册。-Edouardlicn (留言) 2011年2月20日 (日) 11:02 (UTC)

虽然此讨论相关版主对我曾有“嘴炮”指摘，但是我仍在此替他说项。
阁下请参考[8]，如果阁下能在“比几个月”的更短时间内，让这类型条目“编辑战”、“保护”等情形不再发生，这些讨论及版主的相关手册规划一定嘎然停止。
我粗略算了算，以维基10年，每年600万美元资金、10亿次总编辑量核算，一次编辑约要0.06美金，“光这条目”为空格兴起的编辑战、保护所花的钱绝对在30块美金以上，若含其他相关条目，可能在这金额数倍、数十倍以上。或许有人认为这些钱该花，但是个人以为：此版相关讨论，其最终用意只是不想这些因为空格所花的冤枉钱一直烧下去。--Winertai (留言) 2011年2月21日 (一) 03:21 (UTC)
创建条目一直以来有一个原则，就是标题以创建者的版本为准。这个我觉得除了是尊重创建者外，还是为了避免类似情况的发生。类似原则可以用在空格问题上。只要大家都不要互相为敌，那就天下无敌了。-Edouardlicn (留言) 2011年2月23日 (三) 12:21 (UTC)
如果先到先得成为方针的话，我是否可以创建每个章节都使用==【章节名称】==这样格式的文章？——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月24日 (四) 15:41 (UTC)
如果是像以上的例子太过分的话，相信会有维基人把它移动。如果没有冲突的话，我想大家不应多必一举。--Flame 欢迎泡茶 2011年2月24日 (四) 16:03 (UTC)
我说的是条目标题，不是章节标题。不过虞海的建议也不错，日后我会考虑用这样的格式，哈哈。—Edouardlicn (留言) 2011年2月25日 (五) 06:00 (UTC)
(：)回应不过如果说章节标题的话，又是另一回事了，但这方面未引起冲突，所以暂时不必讨论了。--Flame 欢迎泡茶 2011年2月26日 (六) 15:17 (UTC)
问题本质是相同的：先到先得会造成格式上的不统一，而且会很扎眼。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月26日 (六) 15:44 (UTC)
由于本版某些言论被和谐，我只好冒着和谐的风险来回复了。扎眼与否，关键其实就在于看的人是否看得开。我一直都是这么想的。—Edouardlicn (留言) 2011年2月26日 (六) 15:51 (UTC)
请不要忘了维基百科是一部百科全书，如果有的条目有【】，有的条目没有【】，将会是什么样子？说得更过分一点：同一个条目，有的章节有【】，有的章节没有【】，看你怎么读。顺便说一下，目前在这里发言是不需要什么特殊办法的，直接编辑就行。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月26日 (六) 16:50 (UTC)
(※)注意方案已写进Wikipedia:格式手册请将本讨论一并储存，谢谢。--Flame 欢迎泡茶 2011年3月3日 (四) 16:07 (UTC)
未成共识，3月10日已被回退。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年3月14日 (一) 06:27 (UTC)
请提出详尽的反对理由，而不是为反对而反对。试图将这个讨论成为月经文绝对难看。还有虞海提出的不是空格，而是标点符号，请另开新的讨论提出，谢谢。--Flame 欢迎泡茶 2011年3月14日 (一) 07:10 (UTC)
原来阁下在这里给了留言，我移动了一份到上面（#意见），并将在该段回复。另外，请注意用词。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年3月16日 (三) 08:27 (UTC)
请重新开新的讨论，谢谢配合，本文有点过长。--Flame 欢迎泡茶 2011年3月16日 (三) 09:08 (UTC)

异体字

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。

(！)意见：问题闹大了，有必要分开讨论，下分段。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月26日 (三) 07
23 (UTC)

不立方针，具体问题具体分析的思想

关于姊、姉的讨论

“姉”好象是日本人用的吧。—Edouardlicn (留言) 2011年1月25日 (二) 14:26 (UTC)
给阁下加上了－｛｝－对。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月25日 (二) 15:01 (UTC)
“姉”我不知道，没见过。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月25日 (二) 15:06 (UTC)
补充一下，姊川之战本来就是不正确的写法，还做了重定向......。—Edouardlicn (留言) 2011年1月26日 (三) 00:02 (UTC)
深入研究一下，【尔雅·释亲】男子谓女子先生曰姊。这个字在古语中有另外的意思，尤其是一些文章中引用尔雅该句居然也写错了字，写成姊。所以我认为异体字问题修改应该慎重，不要将一些自己不清楚是否有错的东西给越改越错。—Edouardlicn (留言) 2011年1月26日 (三) 02:14 (UTC)
姊和姉的转换mark一下，今天晚上来改转换表。--菲菇＠维基食用菌协会 2011年1月26日 (三) 03:09 (UTC)
在古文书中，是写作“姊川”。--Flame 欢迎泡茶 2011年1月26日 (三) 08:53 (UTC)
  • (：)回应全句是：“姊，女兄也，男子谓女子先生曰姊”，当中的“先生”是“先出生”的意思，与“姊”的意义完全相同。而“姊”和“姊”只是到楷书时笔画分化而成，小篆中是同一个字。因此“姊”与“姊”只是同一字的不同写法，可考虑以较常用的“姊”作为标题，重定向亦可。但“姐”和“姊”不是同一个字，读音也不同，用法也不是完全相同，如“小姐”不能写成“小姊”，把“姊”或“姊”写成“姐”属于错别字--Ws227 (留言) 2011年1月26日 (三) 04:08 (UTC)
我的意见是，此字在不同时代不同场合的用法不一样。尤其是在不同文化上，所以在一些跨文化条目上请慎重，以免贻笑大方。至于黄真伊等，正如Ws227所指，我也不是这方面的专家，我建议但凡涉及古文、日本朝鲜一类的文化等，修改前应作单独讨论。-Edouardlicn (留言) 2011年1月26日 (三) 04:58 (UTC)
这些议题，几年前就讨论多次了(我记得一次还是费勒姆主导)，大家讨论后都无疾而终，其重点都忽略了其他维基多是以“语言”为籓篱，而中文维基在实际运作上是跨“语言”，以文字为主。--Winertai (留言) 2011年1月26日 (三) 07:59 (UTC)
那一定不是我，很少就为“国字”而作出讨论。--Flame 欢迎泡茶 2011年1月26日 (三) 08:19 (UTC)

中文维基百科未规定以官方语言（普通话、国语）书写，但维基人默契以其为通用形式，适度掺入书面语或文言文，以力求文句通顺优美。（中文维基）

  • (！)意见：依上述条目内文：“姊”是否存在，是否由姊翻译替代，关键在于“姊”是否存在于“官方语言”（通用形式），很可惜，就“官方语言”主要认定来源的台湾教育部辞典（国语文）来说，姊字并不存在。

另外，我也找到2008年5月间的讨论：当初是为了“咗”字。“我总认为除了“外文”（包含和制汉字）；中文维基所用中文文字皆要来自康熙字典；辞海或辞源或通用字典（包含港澳地区使用的中文字典）。不知咗或挞有无符合这标准？如果没有，那就是该在粤语维基出现，不该在中文维基出现。--winertai (留言) 2008年5月10日 (六) 14:31 (UTC)”--Winertai (留言) 2011年1月26日 (三) 09:29 (UTC)

咗字收录在异体字字典的附录索引中[12]。至于姊字不收录在国语辞典，应该不影响中文维基百科（ZHWP）使用这个字，因为ZHWP未规定以官方语言书写。--Gakmo (留言) 2011年1月26日 (三) 09:54 (UTC)

问题是，姊字存在于GBK、Unicode、UTF8中（参考）。中文维基应该是服务于大中华区，而不应该只是参考台湾的教育部标准。更何况链接提供的只是一个教育部的词典，我不知道这个词典分量有多重，但即使是大陆，词典也有新华字典、现代汉语词典等等，不同级别的词典涵盖的信息量及使用对象并不相同。我认为只要我们的输入法还能打出这个字，这个字就应该肯定其地位。更何况康熙字典都有此字？另外，如果仅以教育部标准没有此字为准绳，那和大陆的某些公安局因为系统使用GB码无法输入某些字，就不让人改名改那个字的强制行政手段有何区别? -Edouardlicn (留言) 2011年1月26日 (三) 09:57 (UTC)

我支持““小姐”不能写成“小姊””，但基于目前一些涉及外来文化和古文的内容依然存在争议，我依然建议这类内容保留争议部分不要修改。—Edouardlicn (留言) 2011年1月26日 (三) 10:17 (UTC)
那么“丰”跟“豊”呢？有人将伊东丰雄移动至伊东丰雄，是他本人的意愿。

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

幸好他主动提出更正，可按名从主人规则处理。--Gakmo (留言) 2011年1月27日 (四) 01:45 (UTC)
但是从简体上“豊”字不能转化成“丰”，难道他前往大陆时需要在解释一次？--Flame 欢迎泡茶 2011年1月27日 (四) 02:03 (UTC)
其实伊东丰雄的豊在日文是代表丰抑或豊（音礼）？如果是豊，而大陆叫他伊东丰雄，看来真的要解释多一次了 :) --Gakmo (留言) 2011年1月27日 (四) 02:09 (UTC)
“豊”，本作“𧯽”。非“丰”也。竖之有无，大异也。—J.Wong 2011年1月27日 (四) 03:39 (UTC)

我的电脑显示不到“𧯽”，与我同者，可参考[13]。--Gakmo (留言) 2011年1月27日 (四) 04:24 (UTC)

所以除了丰臣秀吉的丰臣外，似乎都应该要使用“豊”字，那简体该用礼吗？个人意见，纯属原创研究。--Flame 欢迎泡茶 2011年1月27日 (四) 07:48 (UTC)
唉，把“伊东丰雄”当成“不同语言”（日文）来看，不是一切OK吗？伊东丰雄是“翻成中文”（“翻得好不好”或“已经约定成俗”，两者纯粹是因个人见解不同而有相异），“伊东丰雄”为日文原文不就结了。--Winertai (留言) 2011年1月27日 (四) 11:13 (UTC)
(：)回应其实症结问题在跟我与Edouardlicn兄讨论中浮现了，因为维基是以“语言”区分而非以“文字”区分，其现有运作则是：“中文维基百科未规定以官方语言（普通话、国语）书写，但维基人默契以其为通用形式”的方式。我们要讨论的是：其一是：哪些“异体字”是不存在于普通话或国语（我认为台湾教育部辞典没出现的就算不在国语之官方语言范围内）？其二则是：不存在普通话或国语的异体字，是否要因为“非通用形式”而舍用？这概念一旦厘清，这些困扰就可以迎刃而解；而不必一个个案例来讨论。--Winertai (留言) 2011年1月27日 (四) 10:57 (UTC)
(～)补充我再强化补充上面说法，我们讲普通话或国语时或阅读报章杂志中，除了“专有名词”外，会有“姊”这个字出现吗？如果没有，我是建议把这个字视同“非通用形式”，至于非通用形式的异体字是否存在于中文维基自是可以慢慢讨论；我个人看法是不宜存在。--Winertai (留言) 2011年1月27日 (四) 11:25 (UTC)
(：)回应我举的例有点废，其实这个“http://dict.revised.moe.edu.tw/cgi-bin/newDict/dict.sh?idx=dict.idx&cond=%E0T&pieceLen=50&fld=1&cat=&imgFont=1 豊”字是在文言文存在，所以我提出的例子有点不正确，但当字有两个意思的时候应该怎办？--Flame 欢迎泡茶 2011年1月28日 (五) 13:52 (UTC)
(：)回应“中文维基百科未规定以官方语言（普通话、国语）书写，但维基人默契以其为通用形式，适度掺入书面语或文言文，以力求文句通顺优美。”，我看法是文言文在中文维基属于“非通用形式”，因此豊字非属必要，不宜存在。--Winertai (留言) 2011年1月29日 (六) 05:23 (UTC)
(：)回应：维基百科的内容不应仅仅包含通用形式，更应该保存有价值且有资料来源的内容。以“飞虎队”为例，通用称呼是对警察特别机动队，但实际上在中国历史中有一个特殊含义。如果今天我们以“此非通用形式”作为衡量去删除某些内容，他日必有后人以同样的理由删除我们的内容，因为“通用”本来就非一成不变。 -Edouardlicn (留言) 2011年1月29日 (六) 06:47 (UTC)

对于异体字，如果有语义完全对应的现行通用汉字时。无需思考，应直接替换成现行汉字（某些专门讲述汉字文化的文学作品不在此列）中国文学作品的本来就存在炼字的说法，如果某些异体字找不到对应汉字，或者一些形近字幽默，我认为无需替换 --Victor.In (留言) 2011年3月2日 (三) 11:45 (UTC)

中文异体字VS中文俗体字

名从主人的

一般使用

常见异体字

一旦确认为常见，应无须做原文（即源码）转换；至于自动转换，可按菲菇的现行做法，简体跟官方，繁体不用转。关键是何为常见。--Gakmo (留言) 2011年1月26日 (三) 09:03 (UTC)

我认为：
  1. 港台标准互异的：羣、群
  2. 有规律的旧字形（大陆）或出版社用字（港台）：爲、卽、眞、靑、兪
  3. 公认常见的俗字：台、囯
至少这三类应被认作是常见异体字。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月26日 (三) 15:20 (UTC)

(＆)建议制订“常用异体字”原则，一旦确认为常用，无须做源码转换，交由自动转换（简体跟官方，繁体不用转，见下面菲姑早前的留言）。非常用者，将源码改为正字（参考两岸三地官方标准）。欢迎讨论。--Gakmo (留言) 2011年1月27日 (四) 02:57 (UTC)

……我在处理字词转换请求的时候也遇到过异体字的情况，说一下我的处理方法。异体字的转换无外乎只有三种：中文异体转简体，中文异体转繁体以及日韩异体转简繁体。目前我的处理方法是，对于出现或曾经出现在中文（文言文和现代文）中的异体字，因为中国大陆存在统一的异体字转简体字标准，所以可以添加转成简体的规则；对于出现或曾经出现在中文尤其是文言文中的异体字，出于尽量保持其原貌的原则，繁体方面基本不添加转换规则（因为繁体承担着保持古文原貌的责任）；对于仅出现在日文、韩文或越文中的异体字，因为这些文字已经不属于中文的范畴，为避免混淆误读，所以均不转换，翻译时请人工修正。--菲菇＠维基食用菌协会 2011年1月25日 (二) 15:53 (UTC)

我觉得只要中文里的确出现过，那么繁体模式下不用转为常用写法，简体模式下则统一转为简体，原因上面已经解释了。--菲菇＠维基食用菌协会 2011年1月26日 (三) 03:09 (UTC)
基本( ✓ )同意。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月31日 (一) 19:08 (UTC)
(？)疑问：可否推动成为指引？——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月4日 (五) 05:30 (UTC)
源码转换政策
  • (！)意见异体字一般应该转换成相应的正体字。除非人名字、地名，则名从主人。--苹果派.留言 2011年1月25日 (二) 22:21 (UTC)
  • 我认为这跟韩国人、日本人没关系。他们用什么，是他们的事；那些仅出现在日文、韩文或越文中的异体字，是断不应出现在中文维基百科的正文中的。我们要保证的是用户书写的是现代标准汉语，就足够了。至于是用简体还是用繁体、用异体还是用俗体，不应作要求；如果作了要求，就违反了中理性原则。因此，不见一添加任何手工转换（名从主人带来的手工转换例外）。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月26日 (三) 06:57 (UTC)
自动简繁转换政策
  • 对于自动字词转换，应谨慎。对于青，建议是zh:青;zh-hans:青;zh-hant:靑;zh-cn:青;zh-tw:青;zh-hk:青;zh-sg:青;。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月26日 (三) 06:57 (UTC)
    • 有个问题，为何繁体中文（zh-hant）是靑？这是大陆繁体还是古繁体？日本汉字？在香港的印刷体是有用靑，但手写的话一般都是青。--LungZeno(talk) 2011年2月2日 (三) 20:18 (UTC)
      • 这是两岸标准写法问题，据《说文解字》，青从生丹，理应是“靑”，台湾以楷体为标准写法，但依小篆字形隶变、下为“月”，所以把俗字“青”扶正；印刷体为明（宋）体（亦是日本标准写法，但同台湾把“青”扶正），因而保留以前字形，大陆采宋体标准写法也是“靑”。--Justice305 (留言) 2011年2月12日 (六) 15:07 (UTC)
古文异体字
如果是古代中文用字但现在中文不常用的呢（如“姊”）？需要转换为常用写法吗？--Ws227 (留言) 2011年1月25日 (二) 16:35 (UTC)

(！)意见--正如Ws227所说，异体字的常用程度各有不同，是否可以制订“常用异体字表”，如羣、眞等，该等字不须转换。--Gakmo (留言) 2011年1月25日 (二) 18:27 (UTC)

  • (！)意见 我有一个疑问，是否因此就无限接受各类中文异体字？只因为“可能有人在用”，或者“老年人可能更习惯”。比如“靑蟹屬”这种写法，Google搜索，除了这里在讨论，没有其他结果。--∰ 黑目观世界 ⌘ 2011年1月25日 (二) 18:47 (UTC)
  • 对于接受各类中文异体字的限度问题，我认为有必要作如下补充： 很多写法的常用程度不能主观臆断，比如“靑”，Google搜索内容稍只能说明网络上不常用，是中文输入法的缘故，但这个字在各类出版物中还是常用的。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年1月26日 (三) 06:57 (UTC)
原文转换政策
自动简繁转换政策

外文异体字

有关的异体字的变换，如有需要的话亦都只在单一计划的转换中修改；而不应该反映在MediaWiki软件本身中。 Shinjiman ⇔ ♨ 2011年1月29日 (六) 06:31 (UTC)

异体字2

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。

方案一 方案二
制定“常用异体字表／可接受异体字表”，包含诸如卽、眞、羣、靑等常用异体字，一旦确认为常用，无须做源码转换。非常用者，将源码改为正字（参考两岸三地官方标准）。 甲：以官方语言（普通话、国语）书写，源码出现异体字，一律改为正字。
乙：以官方语言（普通话、国语）书写，源码出现异体字，一律改为正字。但若涉及名从主人，或该异体字的使用并非在现代汉语之语境下，而为其他语言（如日语等）或古代汉语，则个别处理。

综合之前的讨论，请大家就以上方案发表意见，讨论结果应写入格式手册，谢谢。--Gakmo (留言) 2011年2月7日 (一) 09:52 (UTC)

两方案是并存还是2选1？—Edouardlicn (留言) 2011年2月7日 (一) 11:45 (UTC)
我认为应该是2选1。--Gakmo (留言) 2011年2月7日 (一) 13:57 (UTC)
我认为现在应当讨论的是：哪些是常用异体字。我在#常见异体字里提出了3条标准作为充分条件：
  1. 港台标准互异的：羣、群
  2. 有规律的旧字形（大陆）或出版社用字（港台）：爲、卽、眞、靑、兪
  3. 公认常见的俗字：台、囯
——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月7日 (一) 12:07 (UTC)
我觉得只要不涉及历史沿革（比如这个字转化为现代用字是有若干一段历史）或者其他亚洲文化的，处理起来问题不大。—Edouardlicn (留言) 2011年2月9日 (三) 01:25 (UTC)
若人名使用的，如林育群，要如何处理？—Ellery (留言) 2011年2月11日 (五) 02:50 (UTC)
谢谢回应。这正是我们要讨论的。根据方案一，若羣是常用的异体字，“林育羣”的写法可保留。若根据方案二，则视乎是严格（甲）抑或宽松（乙）的版本。--Gakmo (留言) 2011年2月11日 (五) 06:55 (UTC)
(＋)支持方案二，另外还是坚持“和制汉字”即使与异体字相通，仍视为“日文”。遇此情况，以“原文”显示或翻成现代中文，以先到先得为原则，并考虑接受已约定成俗之仿读情形--Winertai (留言) 2011年2月11日 (五) 16:20 (UTC)
阁下支持方案二，怎么还以先到先得为原则？这部矛盾吗？我也坚持“和制汉字”即使与异体字相通，仍视为“日文”，参见关于用于外文的中文异体字的意见。——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月15日 (二) 13:20 (UTC)
针对第二项第二款“个别处理”备注，即单指“日文和制汉字”情况可以先到先得为“原则”（免于已命名条目大量移动引起纠纷），也就是把这些“日文”视为在中文维基里的IBM。--Winertai (留言) 2011年2月16日 (三) 09:18 (UTC)

(！)意见方案一：似乎涉及一些非必须的后勤工作，而效用却不明显，我虽不反对但觉得不必那么麻烦。(－)反对方案二（甲）：这样做弹性太小了，而且感觉很专制，有违本百科自由的精神；(＋)赞成：方案二（乙）：姓名等专有名词不应由他人或后来的人，来替本人决定当用何字。Fuenping 2011年2月13日 (日) 23:41 (UTC)

不知方案一能否一并解决涉及日韩汉字的命名问题，因为一但该字被纳入常用异体字表，即可用作条目名。不过问题实在太复杂了，异想天开中……--Gakmo (留言) 2011年2月14日 (一) 02:43 (UTC)
(：)回应Gakmo：我感到最好不要把两个不同的论题放在一起处理：参见维基百科讨论:格式手册#中文异体字VS中文俗体字“关于用于外文的中文异体字的意见：对“真”等字，如果旧字形是外文带来的，中文可适用常用字形（具体按维基百科讨论:格式手册#外文异体字处理）；但如果旧字形是中文带来的，就应当使用旧字形。”——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月15日 (二) 12:21 (UTC)

一个问题

撇开制度不谈，我有一个问题：閒、間、閑三字中，哪两个字是正字？哪一个字是异体字？——以上未签名的留言由虞海（对话｜贡献）加入。 2011年2月21日 (一) 13:18 (UTC)

根据国语辞典，三者都不是异体字。--Gakmo (留言) 2011年2月21日 (一) 16:12 (UTC)
应查教育部异体字字典，据历代小学字书说法，以闲为本字，閒正、間俗、閑通。--Justice305 (留言) 2011年2月23日 (三) 06:30 (UTC)

错别字、错词及标点修正

“3标题的格式”中第三行“因未”应改为“因为”。--Oling Cat (留言) 2011年9月6日 (二) 10:08 (UTC)

“7.2引号”第二行“或者英文的全角＂　＇。中文内容也不要用" '。”应改为“或者英文的全角（＂　＇）。中文内容也不要用（" '）。”--Oling Cat (留言) 2011年9月6日 (二) 10:28 (UTC)

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。

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

英文维基的en:Dagger (typography)条目中有说：“In military history, a dagger is often placed next to the name of a commander who is killed in action.”，但后面有个来源请求，不知道是否准确。如果是只限于killed in action的话，自杀就不应该包含在内了，例如柏林战役中阿道夫·希特勒（英文版则没有将希特勒列为指挥官）

另外还有战败之后被杀应不应该加†？例如伊拉克战争中萨达姆·侯赛因有†，关原之战中石田三成则没有†，标准不统一。 --爱管闲事的Inspector（留言） 2011年10月3日 (一) 08:23 (UTC)

全部都不加如何？—AT 2011年10月3日 (一) 14:59 (UTC)
(：)回应：不可以！没编过战役条目的AT这儿没你置喙的余地。--侠刀行 (留言) 2011年10月3日 (一) 15:23 (UTC)
我笑了。。-治愈留言 2011年10月4日 (二) 12:31 (UTC)
希特勒不是在战役中战死的，理应不加上这个标记。萨达姆不是死于战役，石田三成勉强算是，不过要加十字准确地说应该加在大谷吉继上。—马呵说年诶多哗铎★魔力 (留言) 2011年10月3日 (一) 15:51 (UTC)
结合上面的意见，†是否只能表示阵亡？其次，自杀的怎么表示好呢？以英文维基百科为例，单从en:World War II的信息框来看，都不知道希特勒死了。--爱管闲事的Inspector（留言） 2011年10月4日 (二) 02:36 (UTC)
好像没有相对应的，阁下可以问Ai6z83xl3g和Oneam两位军事条目专家，或许可以得到正确的解答。--KOKUYO (留言) 2011年10月4日 (二) 11:13 (UTC)
希特勒不死于直接战争伤害，†只适用于某人死于战争直接造成的伤害（中弹什么的）。打了败仗自杀不应算作战死。-治愈留言 2011年10月4日 (二) 12:31 (UTC)
有多少人在编辑的时候去研究过这个判定标准？而且，灰色地带太多，有必要非得强制统一吗？我也没编过什么战役条目。-cobrachen (留言) 2011年10月6日 (四) 02:19 (UTC)
详细、统一一点总是好的吧。至于灰色地带，有人讨论就讨论，没人讨论就维持现状。英文en:Iraq War里面的指挥官都有不同的模板，我觉得可以借鉴一下。--爱管闲事的Inspector（留言） 2011年10月6日 (四) 02:27 (UTC)

这就不叫作统一啦。要统一格式就是避免日后一条一条，一个人一个人的拿出来讨论。所以，要嘛就是定出大家可以具体了解和参考的格式规范，要嘛就像现在松软一点。夹在中间只怕会令人更难以遵循与了解。一旦过于繁复，会使用和参照的人就会下降。-cobrachen (留言) 2011年10月6日 (四) 03:27 (UTC)

模板有Template:KIA、Template:俘虏、Template:投降（en:Template:KIA、en:Template:POW、en:Template:Surrendered）这些，被处死也有加链接这样的表示方法或en:Template:Executed。对于是否被俘、投降或者阵亡这样的判断一般是较为容易，引起争论的可能较小，有争议的话多半也是对战役过程的争议，不仅仅是模板的事情了。--爱管闲事的Inspector（留言） 2011年10月6日 (四) 05:20 (UTC)

避免中文粗体斜体字

虽然系统预设的功能最方便，浏览器也很支援斜体与粗体，但是中文字其实不太适合粗体，更不适合斜体字。电脑与字体有限，读者认字体也有困难。英文版Wikipedia:Manual of Style/Text formatting就有说："Text in non-Latin scripts (such as Greek or Cyrillic) should not be italicized at all—even where this is technically feasible"。建议在格式手册中提出避免中文粗体斜体字的建议，在使用界面也避免这些字体。111.251.225.191 (留言) 2012年1月6日 (五) 13:34 (UTC)

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

现有时间格式说明可能会引导编者添加大量时间链接

在说明时间格式时，用大量例子给年份等添加链接。一般不要给时间添加链接是英文版的方针之一，中文虽不要求，但这里的说明可能会给编辑以误导，以为遇到时间就要添加链接。因此作了些修改。 * 无与伦比的豆腐（留言） 2012年4月21日 (六) 15:33 (UTC)

有无防止外文泛滥的方针

Wikipedia:格式手册指出，如果该名称的来源是外文，请在括号里加上标明语言的外文原名。（但是没有指出非外来来源不应当使用这一格式）

但是现在很多条目都模仿这一风格（以凸显自己的国际化？）如：

  • 滨海新区：滨海新区（英语：Binhai New Area），是中国天津市下辖的副省级区...
  • 金茂大厦：金茂大厦（Jin Mao Tower），又称金茂大楼...
  • 平安银行：平安银行股份有限公司（英文：PING AN BANK CO.,LTD.）简称平安银行...
  • 宝钢：上海宝钢集团公司（Shanghai Baosteel Group Corporation，简称宝钢，Baosteel）为国有独资公司...

源于中国大陆本土的公司何必画蛇添足加上英文名，如果要加，我觉得宏达电的范例不错：宏达国际电子股份有限公司，简称宏达电，英文简写“HTC”。

不过我没有找到对于这方面的规范。 -- * 无与伦比的豆腐 2012年4月29日 (日) 14:57 (UTC)

谁说中国大陆内运作的公司就不可以用英文名字？--马呵说年诶多哗铎★魔力（留言） 2012年5月2日 (三) 00:13 (UTC)
以上的例子，其英文名称都是non-trivial的资料，一半拼音，一半意译，光是看中文名称不容易知道英文名称，例如我会以为金茂大厦是Jin Mao Building、宝钢是Baogang。在中国境外上市、或是在中国境外从事商业活动的机构，其英文名称更应该标示。--Quest for Truth（留言） 2012年5月3日 (四) 18:11 (UTC)
并不是non-trivial资料就可以保留，而是中文下保留外文名是否有意义。--达师 － 218 － 372 2012年5月4日 (五) 05:15 (UTC)
现在的问题是，这种“中西合璧”是现实存在的，而且是有可靠来源的，而且还是官方制定的（虽然官方有时候也未必官方，比如一个地方两个名字），所以理论上说只要有资料支持都应该保留，就算是一坨屎。--马呵说年诶多哗铎★魔力（留言） 2012年5月4日 (五) 05:41 (UTC)
照这样说，内蒙古各盟旗、新疆和西藏的绝大多数县都要标注英文名；不使用拉丁文的各国政区名也应标注拉丁文拼写，因为都是官方制定的。--inhorw（留言） 2012年5月11日 (五) 16:39 (UTC)

首段条目名称后括号里的原文名称加斜体？

个人认为，条目名称后的原文名称加斜体会更具有可读性，而且一般好像也是这么做（？）。

比如：“条目（Article）”和“条目（Article）”。

另外，斜体是否需要把括号也包括进来我还不清楚。--ks (*) 2012年5月28日 (一) 05:45 (UTC)

一般来说只有部分专有名词，例如书籍名、电影名、物种拉丁学名需要加斜体--百無一用是書生 (☎) 2012年5月28日 (一) 05:51 (UTC)
感谢解答。是否考虑把加斜体这条增加到指引里面呢？这是我的本意。--ks (*) 2012年5月28日 (一) 14:53 (UTC)

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

现发现有个别香港有关的条目内容中，会提到粤语，如1、2，此外还有很多条目写有“杯葛”（大陆地区极少用此说法，绝大多数用抵制一词）等，非使用此类语言（或方言）人士很难确切理解其中的意思，还请编辑者在编辑相关内容时，在其后用括号翻译成通用之话语。——语句不通顺不舒服斯基┣●┫不想屌我敬请留言呐亲 2012年9月5日 (三) 05:59 (UTC)

朗文高级新辞典有此词.....好像并非粤语或方言..好吧...我离题了...卍田卐JC1 2012年9月5日 (三) 08:16 (UTC)
“杯葛”，在台湾很常用。--Djhuty（留言） 2012年9月5日 (三) 10:05 (UTC)
《教育部重编国语辞典修订本》有收录，是外来语。--Kolyma（留言） 2012年9月5日 (三) 10:13 (UTC)
“杯葛”在书面语里挺常用的吧。。--CHEM.is.TRY 2012年9月5日 (三) 10:22 (UTC)
方言或非通用词语有时候恐怕难以界定。至于杯葛，你现在既然明白了其意，我希望你也能欣然包容之。如果你看港台媒体，这类词会更多；反之港台读者看大陆媒体，也未必都能看懂。--Zhxy 519（留言） 2012年9月5日 (三) 10:28 (UTC)
话说按照维基的标准“不好使”算是“方言”吗？在沈阳说话时经常用到这个词，但某次在和一个四川人聊天时他确实表示不懂“不好使”是什么意思。--张树人留言·Talk·电邮·Email·IM - LGBT协会 2012年9月5日 (三) 10:32 (UTC)~
"不好使"应该是方言，南方不使用。--Snorri（留言） 2012年9月5日 (三) 10:36 (UTC)
引用方言的话，引用部分后面用括号加上通用汉语翻译是必须的。一般行文中用词的话，杯葛其实算是通用的了，见过粤语方言特征比较明显的有"的而且确 "，"只但是"什么的。--Snorri（留言） 2012年9月5日 (三) 10:34 (UTC)
提出这种讨论的仁兄，要请别人顾及之前，是否能先把自己顾好？这种歪理，无非是想挑起笔战，难不成你们所在地域或国家就没方言，要我们大家都配合你们那里所用的辞语吗？有时候我们又何尝不对你们所用的方言感到困扰，为何不替我们想想呢？所以说，方言是因地域上的人文背景出现差异所产生，既然住在不同地方就会有不同的用词字汇，那么就请提出这种讨论的仁兄，尊重不同地域或国家的人所使用的方言，而不是要求别人来配合。－36.232.213.121（留言） 2012年9月5日 (三) 11:32 (UTC)
很抱歉，在我所编辑的条目中，我尽可能的避免了使用方言或非通用词汇，我所提议的方言，并非只针对粤语，也针对大陆地区的其他方言，维基百科的受众是所有汉语用户，不是某一部分人群，不能因为使用某类方言（或称之为语言）的编辑者多，而将没有经过翻译或说明的此类方言加入到条目之中。我尊重所有人（包括阁下）所使用的方言权利，但亦请阁下顾及到读者或编者可能非某一方言使用者。——语句不通顺不舒服斯基┣●┫不想屌我敬请留言呐亲 2012年9月5日 (三) 18:11 (UTC)
你自己怎么说都可以，但不要因为你自己认为做得到，就想要求别人跟你一样做得到，并不是每个人都清楚知道自己所用辞语会不会变成别人看来就是看不懂的方言，也就是说，你知道怎做，不代表别人知道怎么做，不是你想要别人顾及就能顾及这么容易，所以别这么天真了，除非有什么辞典可以查各地的方言来对照，否则处处都是地雷，一不小心就会因别人看不懂就说是方言。反过来说，这位仁兄，与其你在这因为看不懂方言，所以跑来这要求别人，你倒不如将你不懂的方言拿去查去翻译还比较实际，毕竟很多人都在写条目，不见得你在这说就会大家照你来做，最终你自己问题得要靠你自己去解决，否则你无论说多少次，也只不过是缘木求鱼罢了！－36.232.222.198（留言） 2012年9月6日 (四) 12:24 (UTC)

我觉得你自己有心这么做，自己编写的条目或添加的内容里，有留意到各地的辞语，并加以翻译整理，确实是对读者而言，倒是很贴心且人性化的，是值得鼓励；但不鼓励在未探讨别人为何不做之前，就先对别人下评语或发出要求，这会给人认为你有这么做，所以别人也要这么做。其实，未必不是别人不想做，只不过你是否想过这种对读者贴心的举动，为何大家很少人做，说不定是有人不知道如此会造成读者困扰，或者是曾经想过要做，只是因为不知道怎区别方言而去改善，也有可能有人觉得麻烦而不做，诸如此类的原因等等，还有内文庞大的条目，若添加很多方言翻译，可能对某些读者族群有阅读上困扰，因为排版挤压或美观问题，加了很多[注1]、[注2]……[注N]，说不定日后就会有人拿出来要推掉这种贴心的举动了。－36.232.222.198（留言） 2012年9月6日 (四) 12:43 (UTC)

我觉得还是应该尽量用标准汉语，实在不行就用简繁转换。—以上未签名的留言由Jack No1（对话｜贡献）于2012-09-07T18:54:47加入。

条目撰者所使用词语及修辞有存在方言造成读者阅览困扰该如何解决

重新发起这则前人提出编辑条目过程如涉及方言或非通用词语时，请尽量顾及其他人士讨论，本意上是好意且很有道理，但做法上颇为困难，况且不应贸然私人见解去要求别人迁就，为此需要协调来自各地的撰者及读者们，将自己所惯用文字词语及修辞用法，彼此分享讨论其心得，因为有人自以为很神通，能将自己与别人的世界相通，知道有一定的方法可避免存在方言隔阁，与其藏私不报，不妨拿出来讨论，教导大家，否则明知会做而不教，只会指责他人的不是，这也只不过是挑起笔战罢了！－36.232.222.7（留言） 2012年9月18日 (二) 14:53 (UTC)

由于前人讨论过程中，因为有人是凭着“他会做而别人也会做”如此想法，那请问该叫别人怎么做？如此岂不有强人所难之意？所以原本讨论发起之本意是好，强人所难的做法却已经将好意扭曲了，只因对方知道怎做而不公开出来，藉别人没有这样做的情况为由来指责其不是之处，如此之举，岂非无心正视问题存在来解决吗？我不忍因为有人拿出问题来而不解决，任其荒废，无奈我又不知道如何解决，所以恳求大家讨论并分享心得经验，不要让“有心人”捉柄开话匣，同时立此讨论，也是要公示正听，避免单方面听凭其词，遭有心人扭曲。－36.232.222.7（留言） 2012年9月18日 (二) 15:12 (UTC)

你前面提到的那个提议是我提出的，但我也实在没有“藏私不报”，我在这提议中说了，解决的方法就是“在其后用括号翻译成通用之话语。”我提此议的原因，使用方言或非通用之语言的不便之处，解决方法，在发起提议时，我均有所提及。或许是我口气不对，以至于使阁下觉得在下在强人所难，在此我向阁下致以最深的歉意。——Langer Lee-本人所主编春社条目正在进行特色条目评选欢迎大家提出意见 2012年9月18日 (二) 15:37 (UTC)
你这有说像没说似的，什么叫“在其后用括号翻译成通用之话语”？难道每个人都知道自己在用词上哪个地方算是方言？那叫那些不知道分辨是不是方言的人该怎办？你不要只把人家的话看一半，从你的回答就知道你还活在自己世界当中，我已经向你提出两次相同的理由了，若不是你不懂，那就可能是忽视了，你所提出那套解决方法根本行不通，并不是所有人都知道什么地方算方言而该被翻译，万一具有争议之处，A君说算方言，B君说这是惯用词而不算方言，C君说只存在某地使用而其它地方也有，只是少见，如此不就开始为了是不是方言而该不该被翻译，开始争个面红耳赤，这有什么意义吗？假使你若没诚意解决，那就请你不要来扰乱，不妨多等些时间，看看是否有其它人参与提出更好方法来。－36.232.216.101（留言） 2012年9月19日 (三) 13:44 (UTC)
你就是没教人家怎么做，只是拿出“在其后用括号翻译成通用之话语”给人瞎猜谜，这就是解决问题只做一半，另一半就是后续的具体做法，这你就没有做出来给大家参考，这边就是我指控你所谓的“藏私不报”，但你可以保持你否认的权利，但只要你想混淆视听，我还是可以站出来继续对你指控。－36.232.216.101（留言） 2012年9月19日 (三) 13:49 (UTC)
请注意，我在原提议中一共拿出三个例子来举例，除“杯葛”之外，其他两个例子里面出现的对话均全为粤语。我不认为一个人在编辑条目时，加入整句粤语或其他方言，却不知这属于方言。——Langer Lee-本人所主编春社条目正在进行特色条目评选欢迎大家提出意见 2012年9月19日 (三) 16:35 (UTC)
“在其后用括号翻译成通用之话语”没必要让加入原话的人做。如果不知道哪些是方言哪些是通用的中文，就留着给其他中文好的人来做吧。不过“在其后用括号翻译成通用之话语”是必要的。—Snorri（留言） 2012年9月19日 (三) 13:53 (UTC)

名称

现在的{{style}}模板对格式手册的诸子页及相关页仅分了四类，我对此感到使用上的不便，所以自己正在修改，如右所示。

Style 手册
查 · 论 · 编

然而我遇到了一颇尴尬的事情。这个版本是以现在英文版的为基础的，第二类叫“Formatting”，似乎可译作“格式”，可这个维基百科指引的名字叫“格式手册”，格式下分内容、格式、图像等，似不妥。

该怎么办？

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

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

叫“文字格式”不就好了。 --达师 － 218 － 372 2012年11月16日 (五) 11:21 (UTC)

那里面还有一个Text formatting... Liangent（留言） 2012年11月16日 (五) 11:31 (UTC)
考虑到 CSS (Cascading Style Sheets) 被翻译作“层叠样式表”，似乎 Manual of Style 也可译作“样式手册”？这个手册的目的倒也就是使所有的条目拥有一致的外观，用“样式”我还能接受啦。百家姓之四 讨论 2012年11月17日 (六) 09:18 (UTC)
text formatting称“文字样式” --达师 － 218 － 372 2012年11月18日 (日) 16:48 (UTC)
而且就叫“格式”又能怎么样。 --达师 － 218 － 372 2012年11月18日 (日) 16:49 (UTC)
把“格式”“样式”互换……我去查查词典去。百家姓之四 讨论 2012年11月19日 (一) 08:25 (UTC)
不要叫“Style手册”，叫“格式规范”比较好——Sakamotosan 2012年11月19日 (一) 04:07 (UTC)
可是问题还是没有解决啊。另外，那个“Style手册”就是个占位符 (placeholder)，绝不会是成品。百家姓之四 讨论 2012年11月19日 (一) 08:25 (UTC)
字词典、百科编篡中常用体例一词--百無一用是書生 (☎) 2012年11月20日 (二) 02:13 (UTC)
体例不错。--Gakmo（留言） 2012年11月20日 (二) 03:49 (UTC)
那么所谓“凡例”又是什么意思呢？ --达师 － 218 － 372 2012年11月20日 (二) 08:21 (UTC)
我觉得体例比较像是编写守则、协助编者编写，凡例比较像是用户指南、协助读者阅读。见凡例的使用。我少读书，不能给一个肯定的答复。--Lakokat 2012年11月20日 (二) 09:39 (UTC)
凡例总是出现在书的开头，有点General Guideline的意思，对思想内容也有涉及。作为“凡”例，不会说得太细，而只会列出较根本的原则。只是个人感觉。百家姓之四 讨论 2012年11月21日 (三) 04:47 (UTC)

关于格式手册各页面改用子页面式命名的提议

理由如下：

  1. 格式手册各分页构成一个完整的中文维基百科格式手册。
  2. 移动至子页面可明确从属关系。与各项关注度指引不同，格式手册具有明确的从属关系，读者可以很方便地通过标题下方的链接返回父页面。
  3. 利用键盘输入斜杠比输入两个括号容易。
  4. 当初使用括号可能是参考英文维基百科的命名方式，而英文维基百科已经于2011年移动至子页面，相关讨论见RfC。

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

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

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

地区用词的格式

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

相关连结均已遭删除或移动，但未“重定向”，烦请修复，谨致上十二万分的谢意。 by 浮游 --220.129.204.186（留言） 2014年7月28日 (一) 12:47 (UTC)

有关格式手册

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

Wikipedia:格式手册#条目标题一节的例子中，“苏维埃社会主义共和国联盟（俄语：Союз Советских Социалистических Республик）”括号内的外文并没有加粗，但在同页“传记”一节中，“史提芬·威廉·霍金（Stephen William Hawking）”中的外文又有加粗。在此询问：导言首句中的外文加粗不加粗是否随编者喜好？这样又会不会导致条目格式不统一？谢谢关注。— lssrn45 | talk 2014年5月29日 (四) 06:50 (UTC)

我觉得都应该加粗，毕竟人家的语言才是正式名称，我们的只是译名。——苏州宇文宙武的主页 ♨留言 ☎交友 ★贡献 2014年5月29日 (四) 08:22 (UTC)
不赞成加粗，只中文加粗就可以了，毕竟这里是中文维基；参考英文维基，序言章节的外文名不加粗（见en:MOS:FORLANG）。--Gakmo（留言） 2014年5月29日 (四) 10:13 (UTC)
Wikipedia:格式手册/序言章节：“不要加粗外文名称”，照这个来看，粗体的原意约寞应是用来显示当前语言会用到的名称，而不是用来彰显名称是否正式，再者，手册反而叫人加粗非正式的中文别称。不过就以中文版这边的情况来看，大部分条目都有着加粗外文的习惯。--街燈電箱150號 开箱维修 抄表 检验证明 2014年5月29日 (四) 11:29 (UTC)--街燈電箱150號 开箱维修 抄表 检验证明 2014年6月20日 (五) 08:21 (UTC)
在中文维基百科里，中文就是高端大气上档次。我支持外文不加粗。--Gqqnb（留言） 2014年5月29日 (四) 16:50 (UTC)
好吧。——苏州宇文宙武的主页 ♨留言 ☎交友 ★贡献 2014年5月30日 (五) 02:08 (UTC)
这问题长久以来一直都很让我困扰。个人对于外文要不要加粗体没有偏向，只希望能有个一统的规则以便遵循之。--泅水大象™ 讦谯☎ 2014年5月30日 (五) 03:17 (UTC)
确实，但是方针本身的内容就有矛盾啊，要不要修改？——苏州宇文宙武的主页 ♨留言 ☎交友 ★贡献 2014年5月30日 (五) 03:32 (UTC)
支持外文加粗。--Fxqf（留言） 2014年5月30日 (五) 09:01 (UTC)
事情变复杂了，这看似是要继续深入讨论和投票的情况？— lssrn45 | talk 2014年5月30日 (五) 10:24 (UTC)
说起矛盾，怎么WP:GTL的导言跟WP:LEAD也矛盾了?--128.199.197.27（留言） 2014年6月28日 (六) 14:14 (UTC)
反对外文加粗体，不加粗体看起来容易区分中文和外文。--HanasakiMomoko（留言） 2014年5月31日 (六) 08:27 (UTC)
可参考《大英百科全书》做法：Prussia、USSR。Lovewhatyoudo ® 2014年5月31日 (六) 15:40 (UTC)
维基百科是把外文以补注形式放在括弧内，但大英百科全书则是把外文都融在正文里，完全不同的状况很难并论比较。--街燈電箱150號 开箱维修 抄表 检验证明 2014年5月31日 (六) 16:06 (UTC)
补充一下，有些浏览器的字型粗体和不粗体看起来差不多样，所以其他名字应该还要用引号包住。--HanasakiMomoko（留言） 2014年7月5日 (六) 14:15 (UTC)

谢谢Lssrn45提出讨论。从上面的讨论，较多用户支持外文名字不加粗。据此，先把维基百科:格式手册中不协调的地方修正。长远是提请社群通过Wikipedia:格式手册/序言章节为指引。--Gakmo（留言） 2014年6月7日 (六) 08:14 (UTC)

我认为两种做法均无伤大雅。若然社群必须选择其中一种作为标准的话，必须通过大量编辑将条目的外文加粗或不加粗，恐怕相当费时。—AT 2014年6月8日 (日) 18:18 (UTC)
我觉得即使通过不加粗，也不需要一次过把全部条目都改掉，而是看见旧条目有加粗就改，写新条目时则不加粗这样的做法。— lssrn45 | talk 2014年6月9日 (一) 05:55 (UTC)
加粗的目的是为了标注条目主题的同义词。外文名其实也是同义词的一类，加粗并没有什么不妥。en那边貌似都是加粗的吧。乌拉跨氪 2014年6月9日 (一) 16:57 (UTC)
同义词不同于外文名；英文维基中，同义词加粗（见en:MOS:BOLDSYN）、外文名不加粗（见en:MOS:FORLANG）。--Gakmo（留言） 2014年6月10日 (二) 04:39 (UTC)

讨论有结果么？ --Kovl（留言） 2014年10月4日 (六) 16:06 (UTC)

有关格式手册（续）

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针/存档/2014年10月。

接续较早前讨论：Wikipedia:互助客栈/方针/存档/2013年5月#请求讨论并且将维基百科:版面指南升级成为指引

重订Wikipedia:版面指南

  • 承上提的矛盾：原来该次讨论严重出错，同时与WP:DAB、WP:顶注、WP:LEAD发生矛盾。该次讨论竟然说没发现消歧义要放最顶的理据，事实上那三页和它们的英文版都有说明。而且还在规则里写是方便TW工具，事实上TW是会把维护模板放在歧义后面的。显然地那次讨论根本未把实践、考察对应和现有规则做妥。如此疏忽原则上理应视为无效并回GTL到非正式状态且重议，因为那次讨论开始没久便出错了。--街燈電箱150號 开箱维修 抄表 检验证明 2014年6月29日 (日) 19:44 (UTC)
    • 既然过程有错误就当然不能作为正式指引。--HanasakiMomoko（留言） 2014年7月5日 (六) 14:15 (UTC)
    • (＋)支持，建议将维基百科:版面指南重新讨论，而且该次讨论未有张贴公告，因此无效，应先退回指引性质，从长计议。Stewart~恶龙 2014年7月7日 (一) 16:12 (UTC)
      　后来加插的讨论：
      • 按照“该次讨论未有张贴公告，因此无效”的逻辑，今次讨论至今（7月28日）都是“未有张贴公告”，就算从7月7日开始计，都已经超过20日仍未有人在“Template:Bulletin”张贴公告。--Mewaqua（留言） 2014年7月28日 (一) 18:05 (UTC)
        • 经查[16]虽然公告“[讨论] 欢迎参与有关格式版面的讨论及有关用户页的讨论。”，但是公告初时（2014年6月21日）本处只是讨论外文名称应否加粗体，而关于条目章节重新排序的重大变动在当时还未有人在此提出。--Mewaqua（留言） 2014年7月28日 (一) 19:19 (UTC)
        • 公告与否其实还是其次，敝当然不能单凭因为没有公告来宣告原讨论无效，但问题亦在于原讨论无公告之余还要过程出错，订立了矛盾和技术不能操作的条例出来，导致无法完全执行，这才是致命伤。--街灯电箱150号
          • 1. 你最初只是说“该次讨论竟然说没发现消歧义要放最顶的理据”，那也是“消歧义”位置的问题，却乘机顺便把“参见”章节位置都一并翻案。你的做法就像某次讨论谈了十件事，只要其中一件事“讨论程序有错”，其它九件事都会变成无效，这样有点像wikilawyering。 2. 英文维基百科都是See also放在Notes之前，这一点何以见得“导致无法完全执行”、“致命伤”？对中文维基百科来说，就算你最初提出的理据成立，那也是“消歧义”位置的相关指引“无法执行”，而不是Wikipedia:版面指南其它段落都“无法执行”。--Mewaqua（留言） 2014年9月24日 (三) 13:27 (UTC)
            • 请留意我宣告的是原讨论在有错误的情况下将整份订立成正式指引，故原讨论无效而退至非正式状态，而不是废除这个指引。订立一条指引，过程当然要整体来看有效性以达至可以完全执行，原讨论明显跳步（即过程出错的致命伤），加上别的管理员也认为有此必要，所以我不认为宣告无效而后重新检讨的做法有何不妥（事实上其他部分有无依照程序其实也成疑问，否则到了现在讨论不会改了那么多东西）。还有，修订当然就要趁一次过改，分开几念佰次改本来就应尽量避免；如果这次顺便讨论章节排序等其他东西是不妥的话，那么原讨论也一样不妥——原讨论是要确认排序，结果却中途顺便加了些模板规定。--街灯电箱150号 2014年9月29日 (一) 03:31 (UTC)
              • 按照你的说法，以后任何讨论只要有人在某时某刻说错了一件事，别人就可以据此推翻整个讨论。如此类推，Wikipedia:管理员解任投票/乌拉跨氪因为有某些“滥权”指控缺乏理据，用你的话就是“原讨论在有错误的情况下”、“原讨论无效”，所以未开始投票就已经无效。--Mewaqua（留言） 2014年9月30日 (二) 02:27 (UTC)
                • 我认为cdip150并无不妥，其他部分的有效性从旧讨论中也存疑，宣告无效再重新审视起码可以保障对整体的有效性；更重要的是cdip150是有等待过其他人的意见才去做，而不是一发现出错就二话不说马上宣告无效。在出错与有效性存疑这两种状况并存下，且当时得到他人首肯，他的做法仍是合理的，而不是什么单纯的凭一个错就直接翻倒的官司。而尽管其他部分有效，也不代表不能透过重新讨论以得到更好的方案出来。对于那个解任案，我想就算最终是过半支持，的确可以预视到也会有人质疑有效性。--Whhalbert（留言） 2014年10月6日 (一) 15:16 (UTC)
根据上面的讨论，由于当时的讨论明显采用了不存在的理由来订立，并造成与其他指引矛盾，再者该讨论从头到尾未出过公告来确保共识与无误，故现已把WP:GTL退回至先前的非正式的准指引状态，接下来重新讨论。
为解决此矛盾，提议先在导言元素将消歧义模板移到最前，因为这才是符合TW工具维护，而且WP:LS已经说明原因，再者消歧义现已不接noteTA转换，所以也无放于noteTA后面的需要。另外，个人亦提议在附录排序将相关条目移到导航模板之前，纵使这做法有别于大部分条目的习惯，但认为这有利于总览所有内部链接，应该要改变习惯。--街燈電箱150號 2014年7月7日 (一) 17:06 (UTC)
(＋)同意，理应如此。Stewart~恶龙 2014年7月7日 (一) 17:09 (UTC)
以本人非常浅薄的学术经验，学术上正文之后会是注解吧，然后是参考资料。--Whhalbert（留言） 2014年7月12日 (六) 14:45 (UTC)
说起学术，记得做论文时教授给的讲义，在同一本刊物的相关主题应该放在参考资料后面的伸展阅读，所以(＋)同意上面改法。还有建议作品列表不定位置，像魔法少女题目，自由发挥。--HanasakiMomoko（留言） 2014年7月12日 (六) 15:49 (UTC)
(－)反对：同之前对于“参见”位置的讨论，其他我没意见（喔……有人一下说要实践，但他提到“参见”位置是叫绝大部分的人更改习惯）。--KOKUYO（留言） 2014年7月12日 (六) 16:06 (UTC)
他说的实践应该是指把规则在维基页面实际操作一次来看是不是可行，跟改习惯完全不对题吧。--113.52.126.158（留言） 2014年7月19日 (六) 15:40 (UTC)
  • 那次讨论总是说习惯，除了习惯也又习惯，不知道还算啥理由。推英文版规则的话，那也要说说日本版的规则，参见章节都是在脚注和参考文献的下面。--162.252.85.172（留言） 2014年7月12日 (六) 18:30 (UTC)
  • 看过Wikipedia:互助客栈/方针/存档/2014年3月#分段当时的讨论，个人认为把参见放于参考文献之后的做法较有理据；而反方则一直强调习惯，但这种“习惯”又是出于何处呢？既然上面提到是学界有采用的方法，(＋)同意这个提议和当时的理由--Ws227（留言） 2014年7月14日 (一) 16:11 (UTC)
    • 喔……学界报告的习惯要我们网页后面列出网址以及在最后后头放上附录，所以要准备改cite web和增加附录了？学术论文的写法等同于百科全书的写法、格式？--KOKUYO（留言） 2014年7月20日 (日) 14:56 (UTC)
      • {{cite web}}会按使用者需要时在状态显示网址，而打印版本上也会自动在旁边加网址（如此条目的打印版），最终还是会有把网址秀出的作用，即本身也已符合学术做法。还有现在讨论中的东西都已经是在最后附录，您还要加什么附录？--街灯电箱150号 2014年7月27日 (日) 03:37 (UTC)
        • 长见识了……我说的附录是指那些其他文件内容、资料报告等等。还有原来你有时候是用IP编辑……--KOKUYO（留言） 2014年7月28日 (一) 14:10 (UTC)
          • 这个叫“附件”吧……其功能该已由姊妹模板达成，其他附带文档（在共享资源）和资料报告原文（在文库）等都放在其他计划，而姊妹模板正正就是放在最后的，基本迎合了学术对于附件放最后的做法。（用了122.100是隐私模式造成的，我懒得重新载入所以在留言后手动画自己的押算了）--街灯电箱150号 2014年9月1日 (一) 09:27 (UTC)
  • 略略看了这个讨论，虽然习惯不是这样，不过习非成是也不是好事。我(＋)支持这个提议。不过，恕我多嘴，弱弱一问：互助客栈很多讨论都是没有存档的，那么由这些讨论生成的方针准则，是否也是无效？--春卷柯南夫子 ( 论功行赏 ) 2014年7月18日 (五) 14:45 (UTC)
    • “简单地从既有惯例发展而出……逐渐演化出的常规或惯例。”等类似内容大概只是被看看笑笑而已……--KOKUYO（留言） 2014年7月20日 (日) 14:59 (UTC)
      • 你引用的方针，全句是“这些共识可以透过对复杂难题的公开辩论或简单地从既有惯例发展而出...”，中间的“或”已表示是二择其一，即不是强制要按惯例。还有“逐渐演化出的常规或惯例...”也只是三种可选方式的其中一种，而已经说到惯例有问题，自然不应被选用，而应借助讨论商议。--春卷柯南夫子 ( 论功行赏 ) 2014年7月21日 (一) 15:03 (UTC)
        • 习惯延伸的方针是要让人得以方便遵从，另外我不认为在当前特色/优良条目中仅有10%左右的条目写法，可以由一个非百科全书的格式指引决定之。同之前所述，“参见”段落放在条目内容后方、参考资料前方有其论述存在，甚至可能还比单纯所谓为了“推广添加参考资料”这类假设性目的理由还可靠。甚至到了现在，连讨论该格式指引是否为单一教授见解、该内容的“延伸阅读”是否可以直接等同“参见/相关条目”，以及是否学术论文的格式即可直接适用以百科全书写法为主的维基百科讨论都没有。--KOKUYO（留言） 2014年7月21日 (一) 16:07 (UTC)
          • 若要以习惯延伸方针，前提是要是个好习惯，而不是不管好坏都要这样处理，即使有90%条目是这样写也不代表证明是正确习惯。还有把相关主题放前面的做法现在也都不再是正式指引，甚至连现实世界也还未见到有用。而且至少正文后接注脚参考的做法绝对不会是某一个教授的见解，以我看过的学术刊物都是这样。而所谓的论述，看过阁下之前的大论，其实也是阁下对于相关条目的假设性想法，并不见得一定可靠。反观现在提议的新做法，其实不须看他的最后几句假设，就只单纯按他对各类型的本质进行铺排，都较有纹理。--Whhalbert（留言） 2014年7月27日 (日) 03:01 (UTC)
            • 首先一个要大众遵循的规则竟然可以造成90%的条目违反也算不上好法案了吧，另外英语维基百科也提到“If policy and/or guideline pages directly conflict, one or more pages need to be revised to resolve the conflict so that all of the conflicting pages accurately reflect the community's actual practices and best advice.”。再者我先前已经提过基于后几者性质上的分类所以认为现在的方式并没有问题，而数个其他语言的维基百科也多采取这类作法。--KOKUYO（留言） 2014年7月28日 (一) 13:17 (UTC)
              • 难道要说因为大多数条目都是加粗外语，所以格式手册所定的不加粗外语例是不好的吗？多少人（或其他语言版本）怎样做与一个法案好不好是根本没有关系的。也先不讲英文版能不能用在中文版，但是您所说的那个规条明明就是在几个正式规则出现矛盾的时候才适用，而这个提议根本不属于那种情况，而且旧有做法也谈不上最好，怎能应用？而您之前对于相关条目所谓的“与该条目有着密切关系的维基百科条目，主要功能是在读者读完整篇条目后提供之后可能会有兴趣继续浏览的条目”性质也其实是你的假设，基于这个性质来分类明显就有问题，反而他纯粹说注脚针对内文、延伸外连是针对主题但内文没有的东西、相关条目不针对内文和主题，这样来分类则才合理。--Whhalbert（留言） 2014年8月15日 (五) 07:11 (UTC)
            • 英文维基百科就不是“现实世界”？哪些学术刊物会有“相关条目”、“导航模板”的东西？ --Mewaqua（留言） 2014年7月27日 (日) 05:45 (UTC)
维基百科采用论文格式其实早有说法，注解参考延伸相关等等其实都是论文才会有的东西，而在传统百科全书却是没有的，例如大英百科全书的A条目。换句话说这里名义虽为百科全书，但事实都是论文写法。另外还须注意参见条目可能遭受内连破坏的问题而需要页底巡查。--162.252.85.172（留言） 2014年7月27日 (日) 03:10 (UTC)
请注意原话为“虽然维基百科为了提高可信度而引入了论文的写作方式”，请问“相关条目”的位置跟可信度有何关联。--KOKUYO（留言） 2014年7月28日 (一) 13:12 (UTC)
当然有关，要有论文的可信度，连排序也要跟随才能让人觉得你是要追随论文那样的可信。一边说要跟论文但一边自己做一个跟论文不同的样式，人家不会觉得你是像论文，没了论文那样的可信。—以上未签名的留言由96.31.64.186（对话｜贡献）加入。
敝现暂仅按照上面多数之意见进行草案修例，另外加入一些未提到的模板放位和避免矛盾而作的防范订正等，请众过目。--街灯电箱150号 2014年7月27日 (日) 03:37 (UTC)
我们这边都还没讨论完就急着改位置了啊……还是要正面思考至少还有1个匈牙利语维基百科跟我们采取同样的格式？--KOKUYO（留言） 2014年7月28日 (一) 13:11 (UTC)
“相关条目”/“参见”/“参看”有时的作用是作为条目内文的延续，为了避免冗余重复或页面过长而不在本页面详写，例如“美国总统”与“美国总统选举”、“美国总统列表”的关系，关连性一般远大于导航模板列出的“美洲各国国家元首”之类，“相关条目”放在Notes和References之上方有其道理，甚至正文章节内有时也有{{See also}}连结相关条目。--Mewaqua（留言） 2014年7月28日 (一) 18:10 (UTC)
{{see also}}等内文连结模板和相关条目章节不能相提并论，要是它们功能一样的话那何必还有相关条目？通通都用内文模板不就行了？是故敝人认为，内文连结模板是条目内文的延续这没错，但相关条目顶多就是内容的主题延续而不是内文；事实上“相关条目部分的内部链接与条目内容没有直接关系”，您要正文有直接关系去延续倒该是用{{see also}}/{{main}}之类的模板，而不是相关条目；简单说就是{{see also}}涉及主题事物和正文，而相关条目则祇涉及主题事物而不及正文；这好比在亚马喇前地条目，在那里发生的2000年澳门大赛车冲出赛道意外因为正文无提及而又无导航所以才迫住要开相关条目，而正文里有简介纪念人亚马喇故祇在正文用main连结，而不是把相关内部链接不理三七廿一都放在相关条目里。而与其说有时作用，不如说必然的关系，备注一定直接由正文伸出，而参考资料一定是直接支持正文，要比正文关系怎么都是注脚大于相关条目。而美国总统这例其实已不恰当，其相关条目悉数已由导航模板提供，而美国总统列表更甚至在文章里用了main，这个参见显然并非必要的。（“一般情况下这类条目的选择仍不应该重复出现在条目文章内或者是导航模板之中”，至少看不出此况有何特别？）故在我而言，相关条目与导航模板的关系高低仅祇一纸之隔。所以相关条目放上面反而无甚道理了。另上面说其他版本有采用，但这并不是绝对证明，至少敝人不会搬“日文版是放下面所以中文版也要放下面”来说，正如Whhalbert所说并无关系。--街灯电箱150号 2014年9月1日 (一) 09:27 (UTC)
Shizhao于2013年9月25日 (三) 12:30 (UTC)说过：“而且参见位置可以有一些对参见条目简短的一句话介绍，或一些简单列表式内容，而这些内容可能也需要参考来源的支持。因此必然需要放到参考和注脚之前。”以“种族隔离”条目的2014年8月31日 (日) 06:14‎ 版本为例，没有附加说明的话，我根本不明白“白澳政策”至“打破沉默组织（以色列）”这些条目跟种族隔离有何关连，而如果这些内部链接后面有附加说明，就可能需要添加参考文献支持宣称，则这个条目的“参见”就不适宜放在“参考资料”后面。--Mewaqua（留言） 2014年9月7日 (日) 04:08 (UTC)
他提出的做法当时我已经解释过为何不恰当，没错在种族隔离可以加说明，但不用做来源，而是在目标参见条目里的内文再详述该关系，然后才在该内文做来源，因为表明该关系的责任在目标参见条目，而不是引它出来的主条目，是故祇有目标相关条目才要举证。这跟序言简介不用列来源有着类似道理。--街灯电箱150号 2014年9月7日 (日) 09:29 (UTC)
序言“不用提供来源”不代表“不能提供来源”，而在理想状况也是因为后方有来源足以应证才可以免除。然后同先前解释无数遍的论点，相关条目段落中的条目并非一定跟该条目有绝对从属关系，可能是在实际使用上的经常比较的关系，例如飓风黛安中所提到的飓风艾琳 (2011年)。而相关条目需要列来源可能是因为编者认为可以提供将某条目列入该段落的理据，而该理由不方便以在这两篇条目的文章中进行统整。--KOKUYO（留言） 2014年9月13日 (六) 12:37 (UTC)
要是用得到某个来源，（之前也说过）最理想应当至少在其一条目整合得到，祇用在相关条目而竟不方便把其理由整在任一正文的话，要么就是该关系的重要性本身都有问题，要么就是正文本身就有缺憾而令到本来可用的来源资料没写进去。要是列出的“理由”是如此重要为何又会“不方便”在正文里表达？哪怕在正文里祇值半丝的句子。（飓风黛安和飓风艾琳 (2011年)，其实在正文弄个比较表格比起做相关条目来得更好）--街灯电箱150号 2014年9月13日 (六) 14:39 (UTC)
User:Cdip150上面提到的“而美国总统这例其实已不恰当，其相关条目悉数已由导航模板提供”已经有错，拿2014年9月24日 (三) 14:04 (UTC)见到的版本来说，在导航模板就找不到美国国务卿，如果其它条目是用上了像{{文化大革命}}之类的超大导航模板，读者就更难寻找导航模板内的“相关条目”。（其实这跟“参见”章节的位置无关。）--Mewaqua（留言） 2014年9月24日 (三) 14:04 (UTC)
噢，看漏了这个，不过无关痛痒，相关条目本来也是一种导航功能，即使撇开不应重复不谈，有关内部链接都应该是抽在导航模板上面才显得它们同是导航作用。而且对应下面另位用户的意见，要是我想了解多些关于总统的资讯，都会是先想看白宫网站多于想看一个离开了主题中心的美国国务卿条目，因为白宫网站比起美国国务卿较有关美国总统主题的资讯。--街灯电箱150号 2014年9月29日 (一) 03:31 (UTC)
使用说明:脚注订明<ref>只是用于正文内容和补充内容，在参见用<ref>是不符合用法。另外{{link_GA}}、{{link_FA}}已被wikidata代替，将会删除，请从规则里移除这两个模版。还有建议移动本页至格式手册的子页面，因为是格式手册的一部分。--162.252.85.172（留言） 2014年9月19日 (五) 02:55 (UTC)
延伸阅读外部链接和相关节目都是给人看多些资讯，所以应该放在一起，加上我之前说的冧庄例子，外连结比相关节目更亲密，所以赞成这个。--Maccomcre（留言） 2014年9月17日 (三) 08:38 (UTC)

最后公示

较早前已按上述意见再修改。另由于已接近三个月强制存档期，而本次讨论目前有绝大多数意见赞同本案，故现作最后公示一周，期内如仍绝多赞同者，将按绝大多数原则将WP:GTL成为正式指引。--街灯电箱150号 2014年 9月22日 04:18 (UTC)

好吧，现在我真的来再确认上述公示是我发的，故理应不再构成影响。--街灯电箱150号 20‎14年9月23日 (二) 07:40 (UTC)

身为管理员兼用户查核员的用户，一面就来个“最后7天公示”，另一面就用IP静悄悄修改Wikipedia:互助客栈/方针/header[20]，导致“目录”本来可见的“重订Wikipedia:版面指南的章节排序​​”突然从目录里消失，要把本来的“=== 重訂[[:Wikipedia:版面指南]]的章節排序​​===”修改才可展示。（IP编辑的时间就在我把“重订WP:GTL”改成“重订Wikipedia:版面指南的章节排序”之后不久，虽然我不是用户查核员，从我可以查看到的东西判断，如果是其他无关者编辑也太过巧合了。）--Mewaqua（留言） 2014年9月24日 (三) 14:18 (UTC)
不好意思，累到街灯电箱了，我是无关者，我缩了目录的子章节是因为先前看到有人反复搞投票，搞乱了目录，想了很久才缩一下看某人会不会停止，想不到引起了这里争议，那我就先回复一下，非常对不起。--113.52.126.163（留言） 2014年9月24日 (三) 14:32 (UTC)
谢谢你的回应。--Mewaqua（留言） 2014年9月24日 (三) 14:39 (UTC)
食住花生等睇戏，就等着看其他用户突然发觉他们一向习惯的章节排序被你判定为“不当”，再加上澳洲IP人肉机器人长年累月不停刷编辑修改章节排序，他们会有什么反应？或者就如1983年大西洋飓风季那样。--Mewaqua（留言） 2014年9月24日 (三) 03:16 (UTC)
要是举风暴例的话，其实近年的太平洋台风条目基本上都不是您这个习惯，就以这个导航模板里面的条目为例都是先放注脚（虽然还是跟我提出的有些分别和滥加外连），那么是否这几年我又要准备花生，他朝某日有人肉机器人把全部参见移上，看看那边又会有什么反应？您举的回退例子我祇能视他按本子办事，未必代表到些什么。人肉机器者，您祇能说他变相绕过正式机器人规则，但不等于他所做的内容绝对不当，祇可以说是用错方法，但不能说他排板的理念错误。--街灯电箱150号 2014年9月29日 (一) 03:31 (UTC)

完成，移至格式手册之下，成为正式指引。--街燈電箱150號 开箱维修 抄表 检验证明 2014年9月29日 (一) 20:09 (UTC)

本人对参见放在参考资料下面没有看法，但本人(－)反对现状WP:LAYOUT中要求参见置于延伸阅读和外部链接之下的做法。首先参见实际上是延伸阅读的一种，而不是导航，导航是分类的呈现。其次参见一般只有很少几个条目，放在最后的话排版会变得极为奇怪。 --达师 - 277 - 465 2014年9月30日 (二) 17:19 (UTC)

啊……达师兄您这个意见正好与这个抵触个正着——参见也是导航。当然我认同参见是延伸阅读的一种（按上面另位用户提供的真实世界例子），所以敝认为参见同时具有两种功效，而放在延伸和导航之间。至于奇怪与否我就觉得很难结论，始终感觉这回事属各人的主观评鉴。但坦白说，如果维基没有导航模板的话，延伸外连参见这三个的顺序互换无所谓。--街灯电箱150号 2014年10月10日 20:18 (UTC)

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

老讨论：关于空格

我是挖坟的。这个空格问题实际上可以考虑在全局 CSS 中加一个text-autospace:ideograph-alpha;属性，暂时地在 Internet Explorer 中解决。（这似乎还只是一个 IE 的专有属性… --Arthur2e5 更改·工具 2014年9月24日 (三) 01:44 (UTC)

争执

log：special:diff/33603731

220.136.18.14 (讨论 | 贡献 | whois | 封(记录))

本主题或以下段落文字，移动自Wikipedia:当前的破坏。执行者：Jimmy-bot（留言） 2014年12月14日 (日) 08:42 (UTC)。

Wikipedia:格式手册，请建立“共识决”副署制度！！

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

log：special:diff/33747709

  1. “1990年代”可寫成“20世紀90年代”，但不简化成“90年代”或“九Ｏ年代”。 其中，“20世纪90年代”是人为添加，欠缺相关共识讨论决议纪录。
  2. 资料如次，special:diff/9548454由Special:用户贡献/Philinwiki编辑，起因于special:diff/9519165“Wikipedia:互助客栈/求助”中Linforest（留言Special:用户贡献/Linforest）君的询问。
  • 建议：
  1. 若对现行已大略修改的“Wikipedia:格式手册”版本，没有疑义，建议于2014年12月15日前完成共识表决副署，纪录备查。（否则，Wikipedia:格式手册高挂属于Wikipedia:方针与指引，岂非笑话一则乎？！）
  2. Wikipedia:格式手册共识表决，可考虑每年3次或每3个月进行1次投票表决，若有无增减，均请公告，并纪录备查。
  3. Wikipedia:格式手册共识决议纪录，可考虑“专一条目”（如log档，避免与Wikipedia:格式手册各分立讨论页资料相混，可兼当各分立讨论页的索引纪录档）统一管理，并作为参考资料于相关讨论页内，也许如“存档”或单一内链，便利查阅。 --114.45.32.133（留言） 2014年12月12日 (五) 04:27 (UTC) (半·瓶水)
你是要改Wikipedia:格式手册/日期和数字才对吧。--113.52.126.43（留言） 2014年12月16日 (二) 12:57 (UTC)
改什么？！我的目的是Wikipedia:格式手册等所属内容已多次异动，但是，距离其上一回共识表决有一段时间，采用包裹表决背书（而非逐一表决，毕竟，也已使用一段时间有余），以符合其Wikipedia:方针与指引身份而已。 --114.45.47.216（留言） 2014年12月17日 (三) 10:14 (UTC)

补充Wikipedia:格式手册

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

提案

设置Wikipedia:格式手册的“其他”章节，并整合原来“不要花俏华丽”的说明。相应内容在en:Wikipedia:Manual_of_Style#Miscellaneous。—RalfX（ἀναγνώρισις） 2015年3月16日 (一) 10:49 (UTC)

“Wikipedia:格式手册#其他”补充内容：

==其他==

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

快捷方式：
WP:MARKUP
MOS:MARKUP

最简单的标记方式通常是最利于编辑、最易于理解、以及最可预料的办法。标记可能在不同浏览器显示有所落差，不应该假定所输入的代码在显示时保证会有预期效果。格式代码越单纯，显示、编辑、与维护都会变得更容易。建立有用的百科全书是我们的首要目的，但保持编辑和维护容易是第二重要任务。

谨慎使用HTML和CSS标记语法；尤其不要使用CSS的float或line-height属性，因为在部分浏览器使用大字体时这会弄坏呈现结果。真的有必要的情况下才使用HTML代码。

HTML字元实体有时比可能在编辑模式下不易辨识的等效Unicode字元更合适。例如&Alpha;可被理解，但Α（希腊字母α的大写形式）可能就不是很好识别。

===格式问题===
参见：Wikipedia:格式手册/文字格式#字体大小

字体大小、空格和颜色（参见下列的 § 颜色）的修改是攸关维基百科全站CSS的议题，并应该仅保留给特殊情况。

通常情况下，使用订制的字体样式将：

  • 减损一致性，文本将不再看起来整齐划一；
  • 降低可用性，可能使用户的自订样式表（为了亲和力之类理由）无法盖过设定，并可能带给使用不同皮肤的色盲用户不方便；以及
  • 造成争议，其他编者可能不同意所选择的样式。

在条目文本之外，不同的字体大小经常套用在导航模板、信息框、表格（尤其是较大的）、以及一些其他不可替代的文字（如表格标题）。指定“相对”字体大小（例如CSS样式font-size: 90%）比“绝对”数值（像是font-size: 8pt）来得好。

====颜色====
快捷方式：
WP:COLOR
MOS:COLOR
主页面：Wikipedia:格式手册/亲和力#颜色

所有讯息应该显见。不要只为了突显某些文字而标示颜色：这可能使色盲人士无法辨识。黑白打印输出也是一样，早期较少颜色的电脑显示器或黑白显示器（早期PDA和移动电话）无法表现出这种区别。

应该选择最普遍色盲(红绿色盲）也能够分辨的颜色，例如栗色和鸭绿色，并另外标示出字体改变的差异或其他含意（maroon and alternative font face, teal）。避免在文本和背景使用低对比的颜色。使用Wickline浏览页面可以帮助选择合适的颜色。参见色码（英语：Color code）。

除了视觉亲和力问题之外，在表格仅使用颜色为属性编译（例如金银铜牌成绩）而不用可排序字段，让强力的可排序Wiki表格形同无物。即使读者颜色视觉未受损，过度的表格项目背景阴影妨碍了维基连结的可读性和可辨识性。背景颜色应该只是一种辅助视觉提示，且应该是隐约的（考虑较轻淡、较隐晦的淡彩（英语：pastel (color)）），而不是显眼的亮点。

===滚动列表与折叠元素===
快捷方式：
WP:SCROLL
WP:COLLAPSE
MOS:SCROLL
MOS:COLLAPSE
参见：Wikipedia:格式手册/亲和力#CSS与JavaScript限制

滚动列表和可折叠元素不应该隐蔽条目内容，包括文献列表、图像展示或说明文字。尤其不应该用来隐蔽扫兴内容（参见Wikipedia:剧透内容）。被折叠的“章节”或“单元”或许可以改用表格以整合本文与导航模板所涵盖的讯息。注意当使用滚动列表或可折叠的内容时，内容仍然可能会在不支援JavaScript或CSS的设备上可见。

===隐藏注释===
快捷方式：
WP:COMMENT
“WP:COMMENT”和“WP:COMMENTARY”均重定向至此。关于与这些名称相似的其它条目，分别详见“WP:COMMENT (消歧义)”和“WP:COMMENTARY (消歧义)”。
主页面：Help:隐藏注释

有些编者会在条目内文中使用隐藏注释和其他编者沟通。这些注释仅于wiki源代码和VisualEditor可见；阅读模式下是不会出现的。

隐藏注释可以帮助标注问题或留下相关说明，比在讨论页提出问题更方便。然而这种方式应该谨慎使用，因为隐藏注释会弄乱源代码而不利其他编者。检查你的隐藏注释不会造成任何格式变化，例如在阅读模式带入一些空白。

要留下隐藏注释，把你打算只给编者看的文字用代码<!--和-->圈起。例如：<nowiki><!--变更此章节标题时，请同时更改相关页面的连结--></nowiki>

讨论

(－)反对：大量内容与已获共识的WP:格式手册/文字格式内容冲突。和目前的{{ilh}}默认样式也冲突。以及不要把多个平行提案整合为一个。 --达师 - 318 - 527 2015年3月18日 (三) 05:58 (UTC)
还有连skin都不翻成中文？ --达师 - 318 - 527 2015年3月18日 (三) 06:04 (UTC)
还有，WP:TLDR，每次提案都搞这么长（还拿框子框起来），结果就是谁都不想讨论，真的是“很容易通过”啊。 --达师 - 318 - 527 2015年3月18日 (三) 06:13 (UTC)
有意见就说，不赞同就反驳，被挡的提案不会过。也不是一两年的新人了，就事论事。隐藏起来没什么人看，摊开来以免又“不小心”过了之后被翻脸。这只是en:WP:MOS的“一小节”内容，实际只有原本的1小小节加上4小小节的补充说明。
Wikipedia:格式手册/文字格式只有“粗体、斜体、不要过度强调、下划线、颜色及内联图像”，哪些“大量内容”和WP:MOSTEXT冲突请举出。
“格式问题”在讲避免订制样式；“颜色”讲的是不要用颜色突显文字，如果需要使用颜色应该选择色盲人士也容易分辨的。不和WP:格式手册/文字格式、{{ilh}}冲突。真的要说反而是{{ilh}}违背了WP:MOSTEXT的规定。
“滚动列表与折叠元素”讲不要隐蔽条目，“隐藏注释”就是项解说而已。skin的中文词都半斤八两就是。—RalfX（ἀναγνώρισις） 2015年3月18日 (三) 11:15 (UTC)
en的方针指引文本普遍过长，即便一小段，不分点分段讨论也很难讨论充分，你先前的提案也是如此。在普遍过长的情况下WP:MOS应当对子页面系统善加利用以改善其内容组织，而不是试图再往主页面里加子页面覆盖的东西。
提案中禁止文字染色，WP:MOSTEXT允许信息框中文字染色，而后者是有共识通过的；{{ilh}}默认样式是讨论了很多次之后，投票通过的。中文维基不是英文维基中文版，你的提案不管是自己写的还是翻译的都只是提案。是你的违背了已有共识，而不是已有共识违背你的提案。同时WP:MOSTEXT没有你链接的两个章节。需要特别指出的是：本地的WP:MOSTEXT根本不是参照英文版编写的，现在再从英文版整个引入相关内容是很不合理的。
说到底“不要花俏华丽”是从读者和审阅者的角度归纳，不利于编者阅读，而WP:MOS首先是给编者的，因此顺便(－)反对这种段落划分方式。
折叠的讨论情况和其他内容未讨论的情况完全不同，请纳入下面的提案或者另立提案单独添加。
作为不可见项目，“隐藏注释”不应受MOS管理。
--达师 - 318 - 527 2015年3月19日 (四) 02:18 (UTC)
解说跟提醒慎用要说成是管理。{{ilh}}的样式既然投票通过，那就把WP:MOSTEXT写成没有矛盾啊。“颜色”在讲不要滥用颜色，以及选用颜色时挑选对色盲友善的，不是单纯的“禁止/可以”这种二元论。—RalfX（ἀναγνώρισις） 2015年3月20日 (五) 13:48 (UTC)
要改的是你的提案不是WP:MOSTEXT。即便想把WP:MOSTEXT一并改了，也是先纳入你的提案。 --达师 - 318 - 527 2015年3月21日 (六) 10:46 (UTC)
Wikipedia:格式手册/文字格式#颜色及内联图像只容许信息框是例外，表示跟一堆模板冲突，像是T:Table cell templates所列。你说WP:MOSTEXT不用改，即是这些模板必须洗白白啰；上面“颜色”一节的内容不重述自己看。不多说了，你们去决定要洗白白还是改格式手册吧。—RalfX（ἀναγνώρισις） 2015年3月23日 (一) 12:55 (UTC)
先来解决最基本的矛盾问题。或者维持你的提案，并在你的提案中添加WP:MOSTEXT修改的内容（若如是，需要通过一个与WP:MOSTEXT以及Wikipedia:投票/跨语言链接的处理方式更强的共识）；或者把你的提案往现有的共识上调整。WP:MOSTEXT改不改是你的提案内容，不是我来决定。然后才是我的观点。 --达师 - 318 - 527 2015年3月25日 (三) 05:32 (UTC)
谈谈怎么解决矛盾跟整合提案吧，这样比较有建设性。“不要花俏华丽”就维持原手册的叙述。原本讲“颜色”跟WP:MOSTEXT冲突，但是WP:MOSTEXT自己造成太多冲突，像是Template talk:Fact#建议取消颜色高亮又一桩，要嘛提个方案出来，或者以上面“颜色”为底本修改写到WP:MOSTEXT。—RalfX（ἀναγνώρισις） 2015年3月25日 (三) 12:54 (UTC)
(－)反对，支持达叔，与现有共识相左。如要继续，请改为逐条通过。--Gqqnb（留言） 2015年3月19日 (四) 06:03 (UTC)
(！)意见，某些人开始以英文区为两个凡是了，没考虑这里的实际情况（从人力到条目状况），一味照搬对方的方法。——路过围观的Sakamotosan 2015年3月20日 (五) 00:42 (UTC)
中文维基方针指引缺漏的都补上，自然不需要从其他语言版东一砖西一块借回来用。也不会一堆讨论都搬出英语版在谈。—RalfX（ἀναγνώρισις） 2015年3月20日 (五) 13:48 (UTC)
中文维基虽然是发展中维基，但也不能照搬西方维基。要警惕西方维基对中文维基的思想入侵，建立有中文特色的中文维基制度。宁可摸着石头过河，也不能引入资本主义制度而引发动乱--Gqqnb（留言） 2015年3月21日 (六) 00:12 (UTC)
"要警惕西方维基对中文维基的思想入侵，建立有中文特色的中文维基制度。宁可摸着石头过河，也不能引入资本主义制度而引发动乱" < WTF?--223.16.120.156（留言） 2015年3月21日 (六) 06:57 (UTC)
(＋)支持，我还是十分支持此提案的。因为深感中文维基百科方针指引之缺失。至于与现有方针冲突的地方，大家可以在商议过程中进行更改。而缺处不补，却是众多争端之始。我最近也在翻译方针这方面的，感觉到如果有这些方面的明确方针，有些“吵闹”完全可以避免，因为方针照顾到了很多人的想法，也能为一些人的行为提供依据。不反对摸着石头过河的说法，但也能感觉到此法对中文维基的帮助有时候不那么显著。另外，请尽量避免地区中心的相关说法（如资本主义思想入侵）。--Alexander Misel（留言） 2015年3月25日 (三) 14:04 (UTC)
取自“https://zh.100ke.info/w/index.php?title=Wikipedia_talk:格式手册/存档3&oldid=68277586”