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

本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论，请在当前讨论页进行。

空格

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

在中文维基格式手册里，空格一节写出，“在中文语境内，文字之间应该不留空格。”请问这是否只是指中文与中文之间？在中文与英文之间，在中文与数学符号之间，在中文与数学方程之间，在标点符号与中文之间，是否可以留空格？在英文维基里，对于空格的置入没有做出限制。从英文维基输入的模板与数学方程里，都存在着很多空格。我觉得在源代码内适当地置入空格，可以帮助检视与维持；在页面里适当地显示空格，也可以帮助阅读、美化页面。我们是否可以赋予空格一些它可以承担的功能？请大家发表宝贵意见，达成共识，谢谢！--老陈（留言） 2016年3月22日 (二) 05:58 (UTC)

(－)反对反对中文与英文之间加入空格，应维持原本的格式，格式统一整齐才是重点。如果以个人感官来说，我觉得加了这些空格反而显得版面混乱，所以这是个人审美与习惯问题，加空格并没有绝对的帮助。--泅水大象™ 讦谯☎ 2016年3月22日 (二) 06:39 (UTC)
(！)意见，这很明显是讲中文字与中文字之间，中文文句的文法里本来就没有空格这回事，把一句长句作适当的区分是用逗号而不是空格，用空格违反了标准文法。而中文以外的部分，则应以常识来决定各个案例与特例是否应该加入，反而不应该在手册里做提议统一要不要加空格。--街燈電箱150號开箱维修抄表检验证明 2016年3月22日 (二) 06:51 (UTC)
- 他的问题应该是针对中文与英文之间的界面部分，至于标点符号与中文之间的空格就更不可行了。--泅水大象™ 讦谯☎ 2016年3月22日 (二) 09:57 (UTC)
  - 他问：“请问这是否只是指中文与中文之间？”我答：“这很明显是讲中文字与中文字之间”。--街燈電箱150號开箱维修抄表检验证明 2016年3月22日 (二) 10:00 (UTC)
    - 哈，误会误会，原来你讲的是他针对格式规则的原发问，而我讲的是他的主张，鸡同鸭讲了。--泅水大象™ 讦谯☎ 2016年3月22日 (二) 10:28 (UTC)
首先中文文法不需要在字词之间添加空格；其次由于模板等的字段的空格在被解释器处理时会被过滤掉，所以空格才不会显现。——路过围观的Sakamotosan 2016年3月22日 (二) 07:15 (UTC)
以量子谐振子为例，User:Πrate的傀儡用自动化工具删掉半形空格后，在“一个质量为m的粒子”就已经有字体轻微重叠的现象（m是斜体），同一条目的其它因为删掉空格而影响阅读的例子就不用逐一列出了，眼见为实，尤其是当预设字体为“新细明体”时。--Mewaqua（留言） 2016年3月22日 (二) 10:24 (UTC)
- 所以重点应该是为何内文中要出现斜体，而不是空格的问题吧？之前已经有过其他讨论，认为英文维基中对于拉丁文或专有名词所做的斜体处理，不该直接沿用到中文维基。还有，字间距我记得可以利用CSS的方式调整，每个人都有各自习惯的版面安排。--泅水大象™ 讦谯☎ 2016年3月22日 (二) 10:32 (UTC)
  - 我无记错的话，数学代数里正常字体和斜体是有不同意思的：正常字体表示常数和函数名称，斜体字母则表示变数，例如：cos x；而“一个质量为m的粒子”的m应该是变数所以用斜体，不过在我这里“m”和“的”之间没有重叠，我这边配置了拉丁字母用Arial而中文用XP版新细明体。--街燈電箱150號开箱维修抄表检验证明 2016年3月22日 (二) 12:13 (UTC)
    - 找到一些会造成显示错误的例子：X粒子、Y粒子、Z粒子、X⁰粒子、Y⁰粒子、Z⁰粒子。英文维基并没有对空格的置入做出什么限制，我们为什么要过度规定空格的置入？--老陈（留言） 2016年3月23日 (三) 05:35 (UTC)
      - 对于这种情况其实并没有建议要用抑或不要用空格，还是一句：请按个别情况用常识决定是否加空格。而我这边显示“X／Y／Z”和“粒／0”之间只是少许的紧迫，不觉得对阅读有很大的妨碍。--街燈電箱150號开箱维修抄表检验证明 2016年3月23日 (三) 06:17 (UTC)

老陈君提的例子在我的画面上完全正常一点都没有重叠，所以问题的根源还是自己浏览器字型设定或CSS造成的。如果真的有很严重的显示问题疑虑时弹性的运用空格或许可以接受，但原开题者显然是想要求全面性的开放，这问题就严重了：如果他觉得空格比较美观、我觉得空格不美观，所以不同的人编辑时有不同的格式，搞得整个中文维基格式不统一乱七八糟，更严重时还可能因为不同审美与习惯的用户编辑同一文章时反复新增或删除空格导致编辑战，各位还觉得不规定一个格式原则是好事吗？还有，英文原本就有标准的空格使用格式，所以根本不需特别在维基百科中规范，但中文与英文字之间的界面并不在标准中文的格式规范中，所以我们才会需要在这里提出讨论，二者状况不全然相同不该直接类比。--泅水大象™ 讦谯☎ 2016年3月23日 (三) 06:21 (UTC)

敝人还是觉得不应该有标准，单是我本人加不加空格就已经很多不同的处理方法，比如说：如果中文字后面接着一个英文单字的话，我通常不会空，但是如果是接一组英文词组或句子的话，则通常会有空……还有许多层出不穷的情况令我施加变化，许多时候甚至要看正文表述了什么内容才得以决定值不值得加空格。所以还是维持现有的自由度，统一建议我完全也不见得是好事，尤其是某一条目用不用空格的做法又未必适合用到另一条目的时候。--街燈電箱150號开箱维修抄表检验证明 2016年3月23日 (三) 06:42 (UTC)

那也是建立在电箱君大体上是了解中文维基基本的格式规则、只是在必要时略作调整，跟整个不订定格式准则随各人喜好发挥是两回事。中文维基有些军事或汽车相关的条目，当初编辑的用户是直接拿英文维基条目的内容copy & paste过来之后逐字中译，所以会留下跟英文一样的字间空格等“遗迹”，整个条目看起来就是像狗啃过一样东一块白西一块缺，完全无法体会其中的美感何在，只给人一种整体品质低落的印象。中文维基还是应该有一个基本的格式规范定义大部分情况下的版面撰写方式，再保留必要时个案调整或讨论的空间，而不是完全不设格式标准，这是完全不同的两种状况。--泅水大象™ 讦谯☎ 2016年3月23日 (三) 06:58 (UTC)

定下建议理应是只有很少量的例外情况，但是关键是在这个空格的问题上无论我建议要有空格还是不要有空格，我预视到都会出现大量的例外，即不存在所谓的大部分情况都适用的方法，所以就算订定了也不会有意思。--街燈電箱150號开箱维修抄表检验证明 2016年3月23日 (三) 07:11 (UTC)

我倒是抱持着不太一样的看法，我认为如果有订定原则但允许在需要时例外，乍看之下似乎与没订定原则一样，但实际上意义不同。因为这表示若想要有例外就必须要提供必要性的证明，如无特殊必要还是要回归标准格式，万一有天真的有两名用户因为要不要加空格而发生争议时，我们就可以根据该空格的添加是否有功能上的必要性来作为衡量的依据，而不会因为无规则来源可供判断而陷入意气之争。别说我杞人忧天这时就在思考编辑战之类的情况，事实是多年下来的经验告诉我们就是这种事最容易导致编辑战，所以我这是在未雨绸缪。--泅水大象™ 讦谯☎ 2016年3月23日 (三) 07:32 (UTC)

英文维基对于空格置入的规则相当具有弹性，甚至多种空格置入格式可以存在于同一条目，或许这是我们可以借镜之处： [3]

In normal text, never put a space before a comma, a semicolon, a colon, or a terminal punctuation mark. Put a space after these, unless they end a paragraph or are followed by a closing parenthesis, quotation mark, or similar. The number of spaces following the terminal punctuation of a sentence in the wiki markup makes no difference on Wikipedia; the MediaWiki software condenses any number of spaces to just one when rendering the page. For this reason, editors may use any spacing style they prefer on Wikipedia. Multiple spacing styles may coexist in the same article.

一般而言，源代码的空格显示问题可以由MediaWiki软件处理，如果MediaWiki软件可以处理这问题，为什么要强硬规定编辑者怎样置入空格？在源代码内适当地置入空格可以帮助阅读与维持源代码，除去这些空格，则源代码会变得像古文一般地难读难懂。我们应该帮助编辑者进行编译的工作，而不是设定规则要求他们做一些“软件可以做的工作”。--老陈（留言） 2016年3月23日 (三) 22:36 (UTC)

我看完上面那段规则后怎觉得英文版的空格输入规则很严格？里面用了“never”“unless”这种语气很强烈的字眼，明确规定分号、逗号、句号前面“绝对”不能加空格，这些符号后面除非紧接括号括号否则“一定”要加空格（原句用动词原形“Put”起头，表示是强命令句型）。最后面那段是在说因为系统会自动压缩空格，因此用户可以自行选择自己喜欢的空格输入格式（原文是“Multiple spacing "styles"”），言下之意您为了编辑便利输入单格的空格、双格的空格或多格的空格显示结果都一样，但是输入空格的“位置”可是有严格规定的，并非老陈君所想像与主张，希望能由用户自行选择输入空格“位置”的作法。所以，您举例英文维基的规则其实正好否决了您自己的提案。--泅水大象™ 讦谯☎ 2016年3月24日 (四) 03:25 (UTC)

谢谢您的关注与意见！希望您翻译英文时，务必要仔细严谨，不能断章取义：

In normal text（在正常文句里）：这不包括特别案例，例如，模板内的源代码、数学公式与正常文句之间的界面等等。英文维基没有对这些特别案例做出规定。
Multiple spacing styles may coexist in the same article（多种空格置入格式可以共存于同一篇文章）：请注意到英文单字“coexist”。--老陈（留言） 2016年3月24日 (四) 05:34 (UTC)

断章取义的是您吧？

1. 原文是说in normal text没错，但是它并没有说“模板内的源代码、数学公式与正常文句之间的界面”可以加空格，那是您自己单方面的衍生解释，能不能被接受尚有讨论空间。

2. coexist的主词是“spacing styles”（空格的格式），也就是我提过同一条目内空格是要打单字元、双字元或多字元都没差，因为系统会自动压缩调整，但是您的主张其实是在讨论空格安插的“位置”，请问原文中何处有说各种不同的安插位置规则可以coexist的？

希望您翻译英文时，也务必要仔细严谨，不该把自己的主张混入对规则的翻译中。--泅水大象™ 讦谯☎ 2016年3月24日 (四) 06:13 (UTC)

谢谢提醒！我觉得“在中文语境内，文字之间应该不留空格”这句子写得不够明确，很容易引起不同的诠释。因此，我提议改写为“在中文语境内，中文文字与中文文字之间应该不留空格”。其他论题可以留待以后商讨。希望获得大家共识，不知道您觉得可否这样改写？--老陈（留言） 2016年3月25日 (五) 05:45 (UTC)

不可以，如果这样改写等于变相允许中文与英文字之间可留空格（所谓中文“语境”，就表示包含在中文文章中插入英文字的情况，但排除整句都是外文内容的情况，原规定其实写得很清楚）。如果要改，还是应该先获得社群共识后再依照讨论结果修正。--泅水大象™ 讦谯☎ 2016年3月25日 (五) 07:16 (UTC)

按照您的说法，为了避免争议，我提议将这句子改写为“在中文句子内，中文文字与中文文字之间应该不留空格”。--老陈（留言） 2016年3月26日 (六) 14:10 (UTC)

(：)回应原文中的中文“语境”原本就是泛指以中文作为主体，只是局部插入外文字的情况，包括中文与中文字之间，也包含中文与外文字体之间，仅有全段皆为非中文（也就是外文语境）的状态下允许插入空格。所以，您这样的狭义定义乍看之下好像是要把规定解释清楚，但实际上根本是暗渡陈仓把您的主张混入规则中，是很不妥的作法。如果您想要自己的主张被实现就请等讨论流程完成之后再说，但很显然一路看下来支持您主张的用户仅属少数。--泅水大象™ 讦谯☎ 2016年3月28日 (一) 05:26 (UTC)

从2010年至今，与User:Πrate和其傀儡为了一个空格而发生争执的用户显然不是少数（例如User:ArikamaI），Wikipedia:五大支柱：“维基百科不墨守成规：维基百科制定有方针与指引，但并非板上钉钉不可更改，其内容和解释可以逐渐发展完善。它所蕴含的原则和精神比字面措辞更为重要，并且有时为了改善维基百科允许有例外。”--Mewaqua（留言） 2016年3月28日 (一) 05:38 (UTC)

又加一个例子，User:Πrate的傀儡在众多条目的参考文献里删掉新闻标题中用作分隔句子的space（例如圣人瀑布，如把“开放圣人瀑布溪山里民疾呼”改成“开放圣人瀑布溪山里民疾呼”），增加阅读上的不便。--Mewaqua（留言） 2016年3月28日 (一) 05:53 (UTC)

参考文献非主文本就不在格式手册规定的范围，直接依照文献来源原本的格式也属合理。M君举的例子正证明了相关的格式规则还是要订以避免编辑战的可能，但规则若有不恰当之处随时都可提出检讨修改，或在必要时弹性调整，但给编辑用户一个基本的遵循依归还是很重要的。--泅水大象™ 讦谯☎ 2016年3月28日 (一) 06:11 (UTC)

从英文维基输入至中文维基的参考文献与模板，其内部遍布了很多空格，这是为了使得源代码易读易懂，MediaWiki软件会自动处理这些空格。请问您是否赞成允许空格在参考文献内存在？请问您是否赞成允许空格在模板内存在？--老陈（留言） 2016年3月30日 (三) 00:33 (UTC)

这跟英文维基无关，系统处理模版时原本就会忽略掉文字（无论中文英文）前后的空格，但不会忽略文字与文字间的空格，但是阁下明明在讲的就是在文字与文字（例如中文与英文字母间的界面）插入空格的主张，且明明讨论的就是主文部分，为何老是拿不相干的事情来混淆视听？--泅水大象™ 讦谯☎ 2016年3月30日 (三) 06:36 (UTC)

一个条目不只是只有主文部分，它还包括条目名、主文、标题、参考文献、模板等等。所以，您不反对在参考文献、模板内的空格可以存在。--老陈（留言） 2016年3月31日 (四) 22:15 (UTC)

不会实际在画面中显示出效果的空格我不在意，参考文献中的title字段原本就是用来显示原文，因此比照原文格式也是合理，其他部分请遵守格式守则。--泅水大象™ 讦谯☎ 2016年4月1日 (五) 02:51 (UTC)

很高兴能够达成共识:-)！--老陈（留言） 2016年4月1日 (五) 22:34 (UTC)

(－)反对中文与英文之间加入空格。--喜欢用IRC的Carrotkit 2016年3月26日 (六) 12:39 (UTC)

谢谢表达您的意见！尚未到投票阶段。是否可以给出反对理由?--老陈（留言） 2016年3月27日 (日) 22:11 (UTC)

(－)反对在任何地方加不必要的空格，包括中英文之间。--Antigng（留言） 2016年3月27日 (日) 06:29 (UTC)

谢谢表达您的意见！尚未到投票阶段。可否详细指出，什么是必要，什么是不必要？--老陈（留言） 2016年3月27日 (日) 22:11 (UTC)

从来没考虑过这个问题，于是看了一下我之前写的条目，确实没有在中英文之间加空格的情况。这应该是我潜意识下的做法。实际上Micrososft Word这类软件的做法是自动在中英文之间留白（自动检测，然后空出间距，不必手动添加空格）。这应该是CSS/JS就能做到的。斜体的情况下，Y⁰的例子下，我的显示重叠了，看起来几乎像是Y^theta（字体：Yu Mincho）。我觉得在这种情况下可以加上空格。Bluedeck 2016年3月27日 (日) 23:54 (UTC)

那为什么斜体后面就不能用JS/CSS加……--Jimmy Xu ^论 2016年3月28日 (一) 00:41 (UTC)

很有趣的是“Y⁰”这个状况并不是该利用空格修正格式的好场合，因为如果在斜体字后方加空格来修正，虽然原本有字体重叠问题的用户看到的画面正常了，但原本显示很正常的用户，却反而会看到“Y”跟“⁰”之间被明显拉开看起来不太像指数符号的情况。若要修正这问题，使用CSS调整恐怕才是治本的方法。--泅水大象™ 讦谯☎ 2016年3月29日 (二) 04:19 (UTC)

{{Lang|en|''Y''0}}，显示为Y⁰。--Mewaqua（留言） 2016年3月30日 (三) 02:09 (UTC)

所以意思是说其实斜体后面的文字重叠问题，用lang模版就能解决？（在我所使用的浏览器/字码版本上有没有加lang的显示效果一模一样，所以无法分辨）--泅水大象™ 讦谯☎ 2016年3月30日 (三) 06:38 (UTC)

可是我这里看这样也会重叠？（虽然感觉没那么重叠，但是可能是因为文字较粗造成的错觉）-和平、奋斗、救地球！^论・自于 2016年3月31日 (四) 04:30 (UTC)

不就是说明了可以通过CSS（或者HTML标签渲染机制）来解决？{{lang}}只是将相应语句用带有lang属性的span包裹，然后让浏览器根据语言来推断字体库，有些字体库能支持斜体字符不覆盖，有些字体库不能。——路过围观的Sakamotosan 2016年4月1日 (五) 01:03 (UTC)

我的发言欠缺考虑，我同意Y⁰是不应使用空格拆分的。Bluedeck 2016年3月31日 (四) 17:26 (UTC)

如果中文和英文之间要增加间距，则用JavaScript或CSS技术性解决，禁止人为在源代码级别加空格。如果中文和数字之间要增加间距，则用JavaScript或CSS技术性解决，禁止人为在源代码级别加空格。如果学习User:Cdip150的做法，中文和英文短语之间不加间距，和英文句子之间增加间距，则用JavaScript或CSS技术性解决，禁止人为在源代码级别加空格。--Gqqnb（留言） 2016年4月1日 (五) 07:02 (UTC)

在下面的例子中，我没有在源代码里添加任何空格，CSS在实现中应为JavaScript所加：紧凑型中文Condensed Text；疏散型中文Scattered Text--Gqqnb（留言） 2016年4月1日 (五) 07:09 (UTC)

很有意思的方法，赞！--老陈（留言） 2016年4月2日 (六) 06:39 (UTC)

JavaScript与CSS技术属电脑领域，只有电脑专家懂得怎样正确操作这种高阶技术，普通编辑者只能望洋兴叹，请问是否能够给出一些普通编辑者能够容易操作的方法？--老陈（留言） 2016年4月3日 (日) 05:04 (UTC)

margin-right不太合适吧，这样源代码就很难看了，还不如一个空格美观。--Nbdd0121（留言） 2016年4月5日 (二) 16:40 (UTC)

“CSS在实现中应为JavaScript所加”没有人需要在源代码里手工编写这些代码。--Gqqnb（留言） 2016年4月9日 (六) 00:54 (UTC)

@Gqqnb：(－)反对 JS会延后加载，这种方法不可避免的会出现页面闪一下。--Nbdd0121（留言） 2016年4月9日 (六) 16:05 (UTC)

@Nbdd0121：(－)反对，我不知道你对JavaScript或计算机科学的了解有多深，我不想说我计算机科学经历，但现在几乎没有网站不用js，技术问题就可以技术处理。不要一直动源代码的主意。--Gqqnb（留言） 2016年4月10日 (日) 20:03 (UTC)

@Gqqnb：(：)回应，我也不知道你对JavaScript或计算机科学的了解有多深，但你需要知道MediaWiki的JavaScript是通过ResourceLoader Queue延迟加载的。如果你要通过JavaScript来修改界面样式，那么不可避免的会出现闪烁。如果段落较长，修改margin或者letter-spacing的效应堆加起来甚至会影响整个页面的排版。--XYZ指示物（留言） 2016年4月10日 (日) 20:38 (UTC)

(！)意见我认为这件事需要分情况来看：如果英文是按照中文的语法作为一个名词插入在文中，这种时候应该不加空格；其他情况下，语法联系没有那么紧密的场合，是否添加空格就不需要管的那么严格。另外重叠的情况其实<math>可以很好的解决，可惜维基用的基于图片的<math>难免带来一点麻烦： $Y^{0}$ --Nbdd0121（留言） 2016年4月5日 (二) 16:40 (UTC)

(＋)支持个人认为对于纯文本编辑或者标记语言适当留白的做法，不论对于页面显示，还是源代码检视都有助于优化可读性，美观性。适合添加空格的场景如：中文与英文之间，中文与数字之间，英文与数字之间（不包括专有组合如奥迪 A8，AK47 等）建议这几种场景在边界两端加空格，遇到标点符号或句尾在单边加空格或不加。仅供参考：为什么你们就是不能加个空格呢？ Pityonline（留言） 2016年4月9日 (六) 01:41 (UTC)

感谢支持！在英文里，空格扮演很重要的角色，在中文源代码里，我们也可以给予空格一些有助于可读性、美观性的功能，避免过度限制编辑者置入空格的行为。--老陈（留言） 2016年4月9日 (六) 06:15 (UTC)

(＋)同意部分同意，不过如果只有一个单词的专有名词按照中文语法放在句子中，加上空格会不会让人感觉在强调一样？--Nbdd0121（留言） 2016年4月9日 (六) 16:05 (UTC)

您提出了一个很好的问题！在维基百科里，有几万个条目，其中，有些条目品质优良，但也有些条目品质粗劣，怎样分辨优质的条目与劣质的条目，这是我们编译者时常要面对的工作。我觉得格式手册空格章节的规则有改良的必要，特别是在源代码方面，所以提出讨论，尝试加以改良，希望能够获得共识。--老陈（留言） 2016年4月10日 (日) 22:03 (UTC)

对于“一个质量为m的粒子”，两个用户看到的结果不一样

用户1的浏览器的结果：一个质量为m的粒子

源代码：一个质量为''m''的粒子

用户2的浏览器的结果：一个质量为m的粒子

源代码：一个质量为''m''的粒子

如果字母m前面加入空格

用户1的浏览器的结果：一个质量为m 的粒子

源代码：一个质量为''m'' 的粒子

用户2的浏览器的结果：一个质量为m 的粒子

源代码：一个质量为''m'' 的粒子

可以看出，“加入空格”给不同用户带来的影响不一

CSS letter-spacing我想应用在“m的”这部分文字，效果跟“加入空格”差不多，后者调整的单位是空格，前者的单位很小 - John doe 120（留言） 2016年4月23日 (六) 08:26 (UTC)

打开网页[4]，然后右键点击“一个质量为m的粒子”，点击“Inspect”...发现问题的起源是Vector screen styles...不多说了，下面的代码从个人的vector.css复制，“预览”按钮好像有问题


/* 取代[https://phabricator.wikimedia.org/diffusion/SVN/browse/trunk/phase3/skins/vector/screen.css?view=markup]的font-family規則
   參考資料：[http://stackoverflow.com/questions/2436749/how-to-add-multiple-font-files-for-the-same-font] */
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    /* 部分瀏覽器不支持codepoint range，[https://developer.mozilla.org/en/docs/Web/CSS/@font-face/unicode-range#Browser_compatibility] */
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    font-style:italic;
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    font-weight:bold;
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    font-weight:bold;
    font-style:italic;
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@media screen{
    body{
        /* Ampersand這名字沒有任何意思 */
        font-family:Ampersand,sans-serif;
    }
}

- John doe 120（留言） 2016年4月26日 (二) 12:16 (UTC)

以下文字的“或”字可能被部分中文用户忽略：

法厄同星（Phaeton或Phaëton，有时也拼写为Phaethon）是位于

改成：

法厄同星（Phaeton 或Phaëton，有时也拼写为Phaethon）是位于

从右到左看，“或”字可能被忽略，以上文字改成：

法厄同星（Phaeton 或 Phaëton，有时也拼写为 Phaethon）是位于

—John Doe 120（talk） 2016年5月8日 (日) 11:37 (UTC)

难道就没人会用LaTeX吗？

这是 $X$ 粒子、 $Y^{0}$ 粒子、 $\Sigma ^{-}$ 粒子？--⁴Li 2016年4月30日 (六) 04:44 (UTC)

@李4：我就真的不会....你肯定维基上有教学?--Temp3600（留言） 2016年5月8日 (日) 13:26 (UTC)

大家来学LaTeX（我随便找的，自己没看过）。Bluedeck 2016年5月12日 (四) 00:20 (UTC)

中文维基教学于Help:数学公式。--Emphrase（留言） 2016年5月29日 (日) 18:50 (UTC)

使用LaTeX已六年，虽然频率不高，我推荐使用英文Wikibooks当LaTeX参考手册，一打开首页就有个大大的LaTeX，属于特色书籍。— Bieraaa 于世界统一时间 (UTC) 2016年5月26日13时21分留言

提议修改格式手册中的空格章节

从英文维基输入至中文维基的参考文献与模板，其内部遍布了很多空格，这是为了使得源代码易读易懂，MediaWiki软件会自动处理这些空格，所以，按照泅水大象™ 、Mewaqua与我先前达成的共识，我提议，添加一条规则：

在参考文献、模板内可以保存适当数量的空格。

请大家投票与发表意见，谢谢！--老陈（留言） 2016年4月2日 (六) 06:05 (UTC)

多余，格式手册针对空格本来就有这么的规定：“如果官方宣布的名称内含有空格，以官方为准。”参考文献标题是文献的官方给的，所以它带有空格本来就已经被允许。还有请不要把讨论分开多个山头，都不知应该在哪里讨论才好。--街燈電箱150號开箱维修抄表检验证明 2016年4月2日 (六) 06:21 (UTC)

在格式手册的空格章节里表明，“在中文语境内，文字之间应该不留空格”。这规定意味着严格限制空格的存在，不只是在标题内而已。我不清楚您对这规定如何诠释，但我觉得这规定并未给予编辑者足够的诠释空间。为了避免有些破坏者利用这规定进行大量删除空格的无建设性编辑，并在其中夹杂着错误编辑，如在圣人瀑布里的恶性编辑，所以才提议添加规则。关于在哪里讨论才好这问题，我不会坚持己见，请问应该在那里讨论较好？--老陈（留言） 2016年4月3日 (日) 00:27 (UTC)

我仍然认为不需要添加，其实我上面说的话本身也有点多余，因为我是假设该节适用于参考文献的来跟您说，不过实际是不适用的，因为该节已经说了“在中文语境内”，但参考文献本身就不是成句话，所以不算是“语境”，继而如大象兄所说，根本不在格式手册规定的范围内。（讨论的位置应该在#空格延续，而不是现在这里另起炉灶）--街燈電箱150號开箱维修抄表检验证明 2016年4月3日 (日) 06:58 (UTC)

已移动讨论位置。--老陈（留言） 2016年4月4日 (一) 01:37 (UTC)

术语“中文语境”缺乏明确定义。是否应该对于术语“中文语境”给出明确定义？假若中文语境不包括参考文献在内，那中文语境到底包括什么部分在内？--老陈（留言） 2016年4月7日 (四) 05:25 (UTC)

圣人瀑布模板内的空格编辑，为非建设性编辑，应避免。“17 米”去除空格，符合格式手册规定。民国纪年的替换我暂保留意见。参考资料里author、title去除空格不正确，这项属于严重错误。--Gqqnb（留言） 2016年4月9日 (六) 01:02 (UTC)

按照您的说法，“17 米”前面与后面的空格都符合格式手册规定，只有在“17”与“米”之间的空格不符合格式手册规定；换句话说，中文语境前面与后面的空格都可以存在，只有在中文语境内部不能存在空格。关于中文语境的范畴，中文语境不包括参考文献、模板、表格在内，而是参考文献、模板、表格内部包含有中文语境。请问您是否同意这表述？--老陈（留言） 2016年4月9日 (六) 05:55 (UTC)

首先明确，我们讨论的是源代码内的空格，还是渲染后的空格。我认为我们讨论的是渲染后的空格。凡是改动在源代码里的、不影响渲染的空格，都属于代码格式，属于“维基源代码规范”或“HTML代码规范”。对于作为模板参数等其他直接输出至页面的空格，区分是否为中文语境。height = ...中的等号之后第一个非空白字符开始为模板参数，所以“17”与“米”之间的空格不符合格式手册规定。而格式手册规定的是渲染后的页面的格式，而不是源代码格式，所以“17 米”前面与后面的空格属于无规范状态（加不加都不影响输出效果），所以我才说是非建设性编辑。我(＋)同意参考文献、模板、表格内部输出为HTML的文本部分（区别于标签）包含有中文语境。17 公尺输出为17 米，其中style前后的空格、冒号前后的空格都属于源代码中输出至HTML标签的空格，非格式手册规范的空格，而span的文本为“17 米”，是输出为HTML的文本。--Gqqnb（留言） 2016年4月10日 (日) 20:23 (UTC)

@Gqqnb：谢谢您对于这论题的仔细分析！

为了避免搞不清楚“空格”到底指的是什么，我们应该明确区分源代码内的空格与渲染后的空格，暂且称渲染后的空格为空距，因为渲染程序最后会展示出多少空白是决定于渲染软件的输入参数。按照您的说法，源代码内的空格安置是属于“维基源代码规范”，而渲染后的空距是属于格式手册规范。请问我这样表述是否符合您的说法？
关于您所提到的文本问题，我不清楚“文本”指的是什么？所以无法明确表达我的意见。
关于“17米”的问题，假设在源代码内，“17”与“米”之间是否可以有空格属于“维基源代码规范”，不属于格式手册规范；在渲染之后“17”与“米”之间是否可以有空距属于属于格式手册规范。请问您是否同意这说法？--老陈（留言） 2016年4月13日 (三) 05:46 (UTC)

@老陳：,(＋)同意“源代码内的空格安置是属于“维基源代码规范”，而渲染后的空距是属于格式手册规范。”。
如果你在浏览器页面上右键，选择查看网页源代码（Chrome浏览器用语）/查看源（IE浏览器用语），你会看到类似<html lang="zh-CN" dir="ltr" class="client-nojs"><head><meta charset="UTF-8"/><title>维基百科:互助客栈/方针 - 维基百科，自由的百科全书</title>的内容。“文本”是HTML技术角度的词。这里的大意是“查看HTML源代码”所显示的内容，也不受格式手册规范。
(＋)同意“假设在源代码内，“17”与“米”之间是否可以有空格属于“维基源代码规范”，不属于格式手册规范；在渲染之后“17”与“米”之间是否可以有空距属于属于格式手册规范”。这就是我表达的意见，即源代码可以有空格但渲染后无空距；或者源代码无空格但通过js或css的帮助，渲染后产生空距。--Gqqnb（留言） 2016年4月13日 (三) 06:07 (UTC)

(－)反对，反对在数字和汉字，或英语和汉字之间插入空格。反对“13 公斤”，反对“13 kg”，也反对“km / h”，应写成“13公斤”、“13kg”和“km/h”。--7（留言） 2016年4月9日 (六) 14:35 (UTC)

谢谢您的意见！希望能够给出理由，大家集思广益。我觉得Pityonline推荐的网络文章为什么你们就是不能加个空格呢？相当有阅读价值，建议您有空时不妨点阅。--老陈（留言） 2016年4月10日 (日) 05:47 (UTC)

7 的说法是有道理的，所谓适当留白，至少需要保留一些自有格式，不要改变原义，或造成歧义，亦非一味地为增强可读性与美观性而拙劣地添加不恰当的空格。不过我建议单纯的数字与不包括带 “/” 的中文单位间应该留白，如 13 公斤，3 份等，遇 13kg，13公斤/人，80km/h 这种，数字与右边文字不应留白，但数字左边应该留白。Pityonline（留言） 2016年4月10日 (日) 06:09 (UTC)

同样反对“左边留白”，反对“体重 70公斤”，反对“距离 3000公里”，反对“风速 200公里/时”，应写成“体重70公斤”，“距离3000公里”，“风速200公里/时”。--7（留言） 2016年4月10日 (日) 16:22 (UTC)

根据国际单位标准规定，数字与单位之间应有空格，因此“13 kg”是正确写法，这也是绝大多数学术书籍与期刊采用的做法。至于中文语境，尚未找到相关标准，给出此文供参考。--Wcam（留言） 2016年4月10日 (日) 22:57 (UTC)

看了这个，果然留白没什么不妥的，而且 w3c 亦有此说明。Pityonline（留言） 2016年4月11日 (一) 00:48 (UTC)

同意Jarodalien的意见。中文语境中，传统上并无空格。我看到的专业文献中，也几乎没看到这么做的/要求的。很多时候中英/数字混排当中出现的空白并不是空格，而是排版软件自动优化的结果（所以，增加空白可以考虑，增加空格或其他类似字符反对）--百無一用是書生 (☎) 2016年4月12日 (二) 02:25 (UTC)

如觉得数字与中文字之间要增加空白，应是采用修改CSS的方式全面调整，而不是用人工方式插入空格。所以我同意书生兄所言，别把空白跟空格两件事搞混了！--泅水大象™ 讦谯☎ 2016年4月12日 (二) 07:19 (UTC)

我现在倾向于添加空白，并且以在源代码中添加空格的形式添加。理由如下

中英文中需要有空白：阅读了一下 Pityonline 给出的 W3C 草案，另查阅了一下相关资料，中英文之间需要有 1/4em 的空白，Word 等排版引擎也早已遵循了这一要求。
不适宜使用 JS 添加：用 JS 添加理论上是可行的，但是如同我上面提到过，用JS添加需要等到 DOM Ready，在这之前页面已经呈现，不可避免地出现闪烁。
尚无纯 CSS 解决方案：纯 CSS 的解决方案需要 CSS Level 4 中的 text-spacing，目前除了 IE 实现了 -ms-text-autospace 以外，其他浏览器不支持该属性，也没有其他纯 CSS 解决方法。
W3C 草案中提到可以使用一个西文空格做该空白的代替。

--XYZ指示物（留言） 2016年4月12日 (二) 12:52 (UTC)

那么我反对这种手工加空格的做法，就像现实生活中看到这种稿件直接退稿不看一样，看到有这种来参加任何条目评选一概反对。我并不觉得这样更加美观，恰恰相反，觉得更难看。像小时一样，我也从来没有在任何论文看到过这种手动加空格的做法。英语不过是有空格分隔单词的习惯。至于那篇一开头就在下定论搞攻击，说什么“有研究显示，打字的时候不喜欢在中文和英文之间加空格的人，感情路都走得很辛苦，有七成的比例会在 34 岁的时候跟自己不爱的人结婚，而其余三成的人最后只能把遗产留给自己的猫。毕竟爱情跟书写都需要适时地留白”的狗P文章，我完全可以写个长篇大论意见完全相反的发表出来。--7（留言） 2016年4月12日 (二) 13:23 (UTC)

即使可能造成页面闪烁仍然希望有pangu.js之类的小工具。大面积排版闪烁应该不至于（浏览器对 U+0020 还是敢压缩的）。如果有精力的话我可能会考虑移植 https://css.hanzi.co/ （实现上用了span而不是空格字符）。--Altoria 2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)

话倒不用说的这么死，好歹上面W大有提出规格文件证明有些是需要空格，而阁下只是印象不该加。--Liaon98 _我是废物 2016年4月12日 (二) 13:30 (UTC)

对于W3C草案问题，我觉得可以与他们讨论对草案进行修改（如果觉得加空格不合适的话）--百無一用是書生 (☎) 2016年4月13日 (三) 02:42 (UTC)

W3C的《中文排版需求》还是working draft（草稿），还差三个版本才能成为正式的“推荐标准”，不可迷信。不过国家标准技术研究所的标准倒是可做参考。那个github上的规范，这是个论述还是什么，不清楚它的效力。--Gqqnb（留言） 2016年4月13日 (三) 06:32 (UTC)

W3C CLREQ草案本身基本就是个论述，或者说“中文排版有这么多东西你要能在浏览器里面实现”的需求书。对于日语（JLREQ）、韩语（KLREQ）亦有类似的文档，其中JLREQ我记得风评很不错。我个人认为加空格只能说是个人肉polyfill，只不过大家都用罢了。当然啦，作者里面我至少能叫出两个很明确地支持在纯文本里面加空格的人（于是你可以认为NPOV上面不对劲）……（可以说大部分我看到过的这方面的人日常都顺手加空格，包括我（以至于我上维基百科脑子需要多绕一圈（不要吐槽我的括号层数多（The Jargon File里面有讲这个的地方）））。）--Altoria 2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)

所以，根据国家标准技术研究所的规定，当表示数量时，在数字与单位之间必须有一个空格的空距。--老陈（留言） 2016年4月15日 (五) 05:29 (UTC)

该单位规定的是美国、用英文撰写时的格式，是关中文维基啥事？别混淆视听。--泅水大象™ 讦谯☎ 2016年4月15日 (五) 05:32 (UTC)

他山之石，可以攻错。更严格地表述，根据国家标准技术研究所的规定，当表示数量时，在阿拉伯数字与英文单位之间必须有一个空格的空距。--老陈（留言） 2016年4月16日 (六) 05:24 (UTC)

那仍然只定义了数字跟英文单位之间的格式，但是上面的讨论是针对数字、英文与中文之间的格式界面问题，纯英文的格式标准仍然毫无参考价值，不提也罢。--泅水大象™ 讦谯☎ 2016年4月19日 (二) 04:46 (UTC)

这是第一阶段，暂且只能这样。如有任何建议，请多指教，谢谢！--老陈（留言） 2016年4月22日 (五) 00:06 (UTC)

英语的数字和单词之间有空格，不过是因为单词和单词之间有空格，一向是这样写的而已，对汉语没有任何参考价值。英语写任何一句话，中间用标点分隔时也会在标点后方加上空格，这对汉语又有什么意义，如果这种也有参考价值，那完全有理由推论今后每个汉字和汉字之间也要加个空格。所以极力(－)反对。--7（留言） 2016年4月22日 (五) 03:19 (UTC)

谢谢您的意见！难道当您在中文句子里用到英文词组之时，您不会参考英文写法？--老陈（留言） 2016年4月22日 (五) 04:58 (UTC)

那又怎么样，如果是引用一句纯粹的英语，那么按照原文来写就可以，但是，汉语中即便写“15kg”而没有写“15公斤”，这个“kg”也是按汉语处理的，念出来时要么念“15千克”，要么念“15公斤”，不应该念什么“15（字母）k（字母）g”，这说明汉语中已经接受用这两个字母来代替“千克”和“公斤”，并不说明这就是在“引用”英语，而是这两个字母已经成为汉语固有的组成部分。--7（留言） 2016年4月23日 (六) 16:53 (UTC)

支持7的看法。去找个小学生让他读出含有“15kg”的数学题，你会听到他念“十五千克”，而不是“十五可唉鸡”或“十五看老米特”。至少已经是汉语的组成部分，至于是固有的部分、自古以来的部分还是不可分割的部分，先不予置评。--Gqqnb（留言） 2016年4月26日 (二) 00:53 (UTC)

这是中国大陆国标GB3100-93[5]，请参考PDF第6页第六节6.2.4，原文引用如下：“单位符号应写在全部数值之后，并与数值间留适当的空隙。”。Bluedeck 2016年5月12日 (四) 00:31 (UTC)

在这样的“适当空隙”有明确定义成“手工加空格”以前，不再进一步回复。--7（留言） 2016年5月12日 (四) 01:36 (UTC)

嗯。确实有这个问题。我觉得实际上本国标PDF中所有^{[我看了的]}样例中，对此“适当空隙”的实现，均通过一个英文半角空格完成。Bluedeck 2016年5月12日 (四) 02:35 (UTC)

ps，除此而外，我还有这个考虑。很多式子中的变量是代单位的，比如 F=ma。但情况不一定如此，比如 F=mx m/s^2。在无空隙情况下，后者x和m/s^2糊到一起去，只能通过斜体分辨。当然，这是数学公式的部分，不是中文语境的部分。Bluedeck 2016年5月12日 (四) 02:38 (UTC)

谢谢找到这极具价值的资料！我觉得留一个英文半空格是很好的办法。--老陈（留言） 2016年5月12日 (四) 07:21 (UTC)

支持单位前加空格。别处加空格算是少数我个人喜欢的workaround，不过按道理讲的确不该。——Altoria 2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)

请注意在上面提到的中国国家标准中所谓的“单位符号”是指拉丁文字基础的外文符号，中文的单位在该文件中称为“单位名称”，言下之意，如果使用的单位是拉丁文字那么数字跟文字之间要插入空格（例如17 kg），但是该规则并没有定义使用中文单位（例如“17公斤”）时要插入空格。--泅水大象™ 讦谯☎ 2016年5月17日 (二) 10:17 (UTC)

谢谢大家发表的意见与建议！假若没有更多字句，我想将前面内容加以整理，写成新版提议，交付投票与进一步讨论，以达成共识。--老陈（留言） 2016年5月23日 (一) 06:31 (UTC)

(～)补充：至于这空格到底是什么问题，下面是一篇个人论述。我认为这个论述违反了WP:简而言之，在此致歉，若不合适请移动论述文到别处。

简而言之，文本如何呈现，与文本内容为何没有任何关系，前者是程序自动排版的问题，后者是作者要表达的思想。但因为计算机的计算能力是有限的，许多时候不能指望任何文本框都有强大的排版功能，因此内容有时不能与样式分离。例如，全角逗号带有空格，就是内容里带了样式。而我们的内容要手动加入多少样式，这其实完全是个如何取舍的开放性问题。还是要根据情况灵活分析。比如斜体文本导致字符重叠，手工加入个空格并非不可接受。或者说，如果维基百科对于使用JavaScript对文字之间加入空白没有困难，当然也可以启用了。最后，我相信，统一的风格比所谓“正确”的风格要重要的多。— Bieraaa 于世界统一时间 (UTC) 2016年5月27日11时34分留言

个人论述

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

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

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

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

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

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

但实际上，如果我们正确的加入间隙，那么可以达到很好的阅读效果。但现在的计算机中西文之间没有任何间隙（总比被迫使用全角拉丁文好啊）。这个问题的根源是 —— 正如早期的计算机只有一种宽度的局限性一样，现代计算机的局限是 —— 文本处理程序是以字符为中心，而不是文字本身为中心处理文本。并不是说计算机不能干这事，而是在计算机中，文字输入和文章排版是完全不同的两个应用。如果你有一个输入框，比如维基百科现在的这个纯文本编辑器，你不可能指望它主动帮你排版；但你如果在Microsoft Word中输入一篇文章，该程序显然可以自动帮你搞定一切关于间隙的麻烦事。不仅仅是Word，从1970年的TeX发展至今的LaTeX甚至能做的更好，在LaTeX中，你按一下空格键是完全没有意义（当然，在单词中间有意义），因为LaTeX它自己知道什么时候插入间隙，什么时候不插入间隙，你的空格对它的排版规则一点影响没有。

这就叫做呈现与内容分离，它能解决我们从开头起遇到的任何问题 —— 我们输入的内容是一句话（如：地球是圆的），但至于这句话应该怎么呈现（如：登上纽约时报、使用的墨水类型、字号、段首空两格、字体，或者什么时候留空隙等），和这句话说得是什么（地球是圆的）应该完全没有任何关系 —— 这显然是合理的。但由于计算机的局限性，我们一直没有将呈现与内容分离。例如，我们在按下一个逗号时，我不但表示我说话时停顿了一下，还表示我希望在排版时逗号后面有一个空白（如果是英文，我还必须手动输入这个空白）但这和我的内容一点关系没有，在一个形而上的完美世界里，那是遵守格式方针的排版者或者LaTeX需要责任，而不是仅遵守内容方针的我的责任。同理，中英文之间的空隙，不应该由作者作出，而是LaTeX作出。

但我们不可能指望任何输入文字的地方，都带有一个LaTeX这样超级复杂的计算机程序，这是不可能的，就算有，例如维基百科的全部正文可以用LaTeX写，但这不太适当。可见，我们只能在不同的场合作出适当的取舍。例如，我们要在纯文本里加入表格，我可能不得不加入竖线（|）与横线（-），尽管这和我要表达的土豆多少钱没有任何关系。而我们怎么取舍呢？通过在不同的场合，当然是根据情况制定不同的方针取舍。比如我个人会在任何纯文本输入框，手工加入中文和西文的空格。当然了，至于方针的指定，还是要根据情况灵活分析。比如斜体文本导致字符重叠，手工加入个空格并非不可接受。或者说，如果维基百科对于使用JavaScript对文字之间加入空白没有困难，当然也可以启用了。

最后，我相信，统一的风格比所谓“正确”的风格要重要的多。更何况这个问题的根源是一个很实际的技术问题，具体的做法是可以非常灵活的，希望大家以更加开放的态度看待这个问题。— Bieraaa 于世界统一时间 (UTC) 2016年5月27日11时34分留言

很有见地！我相当支持你的呈现与内容分离以及Latex的观点。我上面提出的JavaScript添加空隙，就相当于Latex排版引擎。可惜有人表示JavaScript会引发一次重绘，虽然我不确定一次重绘会损失什么东西，或是违反了什么我没有意识到的维基百科对用户承诺的服务级别协议。。--Gqqnb（留言） 2016年5月28日 (六) 23:44 (UTC)

谢谢Bieraaa对于呈现与内容分离的详细说明与精辟见解。我觉得中文维基格式手册关于空格的规定不够严谨、需要改善，尤其是缺乏设定中文语境的范畴，这问题很容易会被破坏者利用，借此进行大量删除空格的无建设性编辑，并在其中夹杂着错误编辑，如在圣人瀑布里的恶性行为。因此，我提议在空格一节添加以下规则：

中文语境不包括参考文献、模板、表格、数学公式在内。
按照中国国标GB3100-93[6]，第6页第六节6.2.4，规定“单位符号应写在全部数值之后，并与数值间留适当的空隙”。

希望大家对此提议发表宝贵意见，热烈投票，提出具体建议，以达成共识。--老陈（留言） 2016年5月30日 (一) 22:22 (UTC)

(－)反对会对实际显示效果有影响的地方手工加空格，参考文献因为不会有任何显示上的区别，所以可以接受。所谓“不够严谨、需要改善，尤其是缺乏设定中文语境的范畴”不过是有些人就是看不惯没有空格，要有空格才舒服。这同样也“很容易会被破坏者利用”，“借此进行大量加入空格的无建设性编辑”（不好意思我汉语不好，这话说得我别扭，要说成“以此为借口专门在条目中加空格，除刷编辑次数和引发编辑外无意义也无任何实际意义”）。6×4看不清楚，还要写6 x 4才看得清？打个标点都不会打，回头写6 X 4可能更清楚一些。--7（留言） 2016年5月31日 (二) 14:34 (UTC)

(：)回应，随意大量添加空格或删除空格皆属无建设性编辑，皆可以回退。关于数学公式的问题，诚如Bluedeck所言，“比如公式 F=mx m/s^2，在无空隙情况下，后者x和m/s^2糊到一起去，只能通过斜体分辨。”数学公式内的空隙处理，这是MediaWiki软件的渲染问题，MediaWiki软件自动会处理空格，不应在源代码内禁止空格存在，影响源代码的可读性。数学公式内的空隙不只是看得清楚与看不清楚这问题，它还涉及到整个公式呈现的艺术美观问题，在这方面仍旧存在争议，各个编辑者持有不同意见，不应随便禁止。--老陈（留言） 2016年6月1日 (三) 14:13 (UTC)

我只是想起这个。--Emphrase（留言） 2016年6月3日 (五) 08:22 (UTC)

(：)回应，请问是谁制作的这些页面？是否可以稍微说明一下？--老陈（留言） 2016年6月6日 (一) 05:49 (UTC)

见 https://github.com/ethantw/Han 。就是我之前提到的 css.hanzi.io，作者是 CLREQ 特邀专家之一（我全都提到过）。--Artoria 2e5_编保持页面整洁，直接ping我回复。 2016年6月10日 (五) 21:33 (UTC)

(：)回应，这是个商业软件，不清楚这跟当今的讨论有什么关系？--老陈（留言） 2016年6月13日 (一) 07:03 (UTC)

但是授权是用MIT自由授权的。--Emphrase（留言） 2016年7月1日 (五) 03:39 (UTC)

好久没来维基百科，刚刚看见这一讨论，未能详细阅读，如有重复观点敬请见谅。有没有一种技术手段，无论在源码中有没有空格，都会自动在汉字和西文（包括公式和数字）间渲染出一个间隙？当有特别情况不愿意渲染出间隙的时候，可在源代码中加入某种语法避免渲染间隙。这种做法与微软Office的排版方式非常接近。这样既可以使读者所看到的条目排版整洁易读，又能在源代码编辑上给编者较大的自由度，还能避免全站更改源码这种浩大的扰民工程。我想上面这个工具就有这个目的。钢琴小子 留言贡献 2016年6月14日 (二) 08:56 (UTC)

JavaScript就是解决方法之一，如果社群允许0.1秒的页面重绘。另一个办法是修改MediaWiki源代码，这更强大也更危险。--Gqqnb（留言） 2016年6月15日 (三) 05:05 (UTC)

在英文维基里，MediaWiki软件会自动处理空格的渲染。理论而言，源码可以有任意数量的空格。这给予了编辑者在编辑源码时很大的弹性，促进源码的可读性。在中文维基里，假若，我们过度硬性规范空格数量，则会影响源码的可读性。至于有关MediaWiki软件如何处理空格的渲染这方面的问题，可能需要请教才女，她是这方面的专家。

空格的渲染涉及到艺术美观问题。例如，第i个字、第 i 个字，这两种由于空格的置入与否会产生的不同的渲染效果，前者显示出英文字母

i

紧紧地挤在“第”与“个”两个字之间，使用手机阅读很可能会忽略掉这个英文字母，后者则较为明显地展现出英文字母

i

。Bluedeck在前面也举出另外一个例子。这些例子都展示出，我们不应随便禁止置入空格。--老陈（留言） 2016年6月15日 (三) 06:11 (UTC)

我觉得编辑工具栏可以添加一个按钮，自动在全文或者选中文本的中英文之间添加空格。—John Doe 120（talk） 2016年6月15日 (三) 08:58 (UTC)
所谓的“艺术美观”问题是纯粹的主观判断，上面有人觉得要有这个才更美观，我偏偏觉得加空格丑爆了，恶心死了，感觉就像一文钱买个夜壶，贵贱不说，根本不是个东西，这又怎么样呢。“当有特别情况不愿意渲染出间隙的时候，可在源代码中加入某种语法避免渲染间隙”，所以谁要是不喜欢，抱歉，管不了你那么多，你自己去学语法慢慢加慢慢整吧，反正默认就是要的，不会那不关我的事。要这样的话，呵呵，慢慢打吧。--7（留言） 2016年6月16日 (四) 11:12 (UTC)

谢谢您的意见！希望能够达成共识。--老陈（留言） 2016年6月19日 (日) 21:57 (UTC)

若是在条目中存在任何形式的空格的话，则要删除不影响句义的空格（如双星之阴阳师#故事简介中的空格）--林勇智 2016年6月23日 (四) 10:31 (UTC)

1. 部分情况下不加入空格会造成兼容性问题：谷歌搜索 [ 5ms inurl:https://zh.wikipedia.org/wiki/VoLTE ]，一个结果，[ "1..11 ms" inurl:https://zh.wikipedia.org/wiki/VoLTE ]，0个结果。

2. 空格对于编程语言的表达式有作用：比如下列 C++ 表达式：1 + 1 * 2，粗略地看一下，不知道哪个操作符先计算，删除多余的空格后：1 + 1*2，好像明白了哪个运算符先计算。—John Doe 120（talk） 2016年7月1日 (五) 05:13 (UTC)

华人或东亚的组织，应该附注英文名字吗？

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

例如中国国民党、唐凤等等，应该附英文名吗？我认为是不用，因为这些人或组织都是先有中文名再有外文名，中文不是翻译自外文，而且读中文条目的人基本上也都是使用中文名称，如果附了英文那不如也附上所有外国语言的名字。我之前在有些条目看到附英文名字的就会编辑去除，但是在唐凤的例子，过了几天又被加回来，显然有些人认为这是重要的资讯。好像没有相关的方针？Yel D'ohan（留言） 2016年9月8日 (四) 19:43 (UTC)

@Yel D'ohan：感觉应该分情况讨论。对于国民党，本人认为英文非首要且增添信息有限，但考虑到其在官方网站亦明显注明之，可以考虑添加，不添加亦可；至于唐凤，由于其有另一通行称呼（Audrey Tang），与其本名显著不同，应当添加。其他东亚或有东亚背景的人物组织，感觉如果没有特别需要，使用汉语名+母语名或纯汉语名即可。--Morningstar1814（留言） 2016年9月8日 (四) 20:37 (UTC)

使用lang-en等模板标出外文。你看这个Audrey Tang，你怎么确定它是英文、西班牙文还是法文？我先想当然地标注了lang-en，望其它编者指教。
标注外文的争议在维基百科长年存在，如联合国，阿拉伯文、中文、英文、法文、俄文、西班牙文都可以标。海牙国际法庭，它标了法文，为什么不标英文？它属于联合国，为什么不标阿拉伯文？甚至台北、上海、苹果都可以标外文。跟废英派相比，挺英派（挺外派）总是比较多。--Gqqnb（留言） 2016年9月13日 (二) 02:25 (UTC)

@Gqqnb：Audrey Tang个人想当然地猜测为英文，当然若有相关来源表明其自称为“英文名”更好，不过要是我我可能会比较懒惰地在某些地方使用{{lang|en|Audrey Tang}}，语言不自动显示，直至有来源再修改。

联合国标注所有官方语言均可，海牙国际法庭个人不了解具体状况（但其官方网站仅使用英文和法文）——但包括国际刑事法院在内的许多国际组织根据传统都将英文与法文列为工作语言。若有来源支持（不知大英百科等是否列出两种表达），应该按来源加入。

完全无法理解为何上海和苹果需要标注英文……至于台北，因其采用威妥玛拼音，与通用拼音法不同，但在国际及当地机构亦时常使用，可以作为有用的额外信息添加进去，不过要留在正文“名称”章节问题也不大（如“Canton”作为广州的前英文称呼自然是留到此段落）。

感觉挺英和废英的存在及分歧有些滑稽——照理来说应当分条目和内容讨论的，很难搞大规模采用或废止……--Morningstar1814（留言） 2016年9月13日 (二) 22:37 (UTC)

“香港中文大学（英文：The Chinese University of Hong Kong；缩写：CUHK），简称中大[注 1]，是一所……”香港中文大学无疑是“华人或东亚的组织”，不过主要教学语言是英文。还有Template:香港特别行政区政府组织架构的各个香港特别行政区政府部门和机构条目基本上全部都加上其英文名称。--Mewaqua（留言） 2016年9月13日 (二) 02:37 (UTC)

个人认为应该以其官方网站的可选择语言为可附加基准。例如“联合国官网”一共有6种语言被官网使用（不计简繁）（不计不同地区使用方法不同），编者可以在6种语言中选择性使用————だ＊ぜ（留言） 2017年7月13日 (四) 09:15 (UTC)

标点符号格式标准审查暨条例漏洞弥补机制

现在的维基页面其标点符号极其凌乱，比如某页面的上文在使用“比如：···”，下文就被换成“比如，···”。建议制定一个标点符号使用格式的定期复查机制，以wikipedia:格式手册/标点符号为基准，并弥补其格式标准漏洞 ————だ＊ぜ（留言） 2017年7月13日 (四) 08:56 (UTC) ( ✓ )同意--冷罗KS用户:KSroido 2019年8月20日 (二) 13:13 (UTC)

条目中附注外文的规范

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

有鉴于一些维基人认为在条目中附注英文原文十分必要/有时候没必要/有时候不行，我写了一些自己对于附注外文的习惯做法，原文在此，请各位提出各自的意见。

主要想法是，红字、黑字可标注外文，蓝字、绿字一般不可标注外文，但也存在一些例外情况，详见内文。请各位批判一番。注意该草案仅适用于“专有名词”，具体什么是专有名词，还有待定夺。@NoobWayne

--燃⁠灯 ^谈笑风生 2017年7月22日 (六) 21:08 (UTC)

(！)意见：“导航模板（不算作“列表/表格”）可依情况为红色连结附上对应外语，但不可为蓝色连结、绿色连结附上对应外语。”不违反通用标准啊，我觉得不算例外；另外，建议规范下{{lang-en}}和{{lang|en}}的区别。专有名词的话个人建议比照重定向，为字典查不到的词。--星巴克女王_{（🎶欢迎参与音乐专题）} 2017年7月23日 (日) 05:30 (UTC)

导航模板的问题主要是想强调一下……算了我合并到#2吧。那两个模板，我个人也拿不太准，一般我是只在开头处使用一次{{lang-en}}，别的情况下都是{{lang|en}}，不知道别人怎样。至于专有名词的问题，可能要专门开个话题讨论了。--燃⁠灯 ^谈笑风生 2017年7月23日 (日) 05:44 (UTC)

我觉得这两个模板的标注没有那么简单，虽说{{lang-en}}一般在开头用，但如果一篇条目有多种外语需要标注怎么办呢？另外有些外文人名实在不好说是哪种语言。所以还是希望能有一套准则规范一下。--星巴克女王_{（🎶欢迎参与音乐专题）} 2017年7月23日 (日) 06:00 (UTC)

(～)补充：另外我觉得这一篇少了日语假名、韩文汉字、越南文喃字是否要标注的规范。不过个人对这些语言不了解，还得请一些日本、韩国、越南专题的编者来探讨探讨。--星巴克女王_{（🎶欢迎参与音乐专题）} 2017年7月23日 (日) 06:04 (UTC)

(！)意见谢谢燃灯！辛苦了！在下会拨时间详阅！=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 05:33 (UTC)

(！)意见感谢阁下缜密的思维，在下几乎完全同意里面的规矩。

唯一在下认为可以调整的是此条文：

在下认为可以考虑开放专有名词外语重定向的创建：

“该词中文尽管是个源自外语的专有名词但却过于常见，这种情况下不应该标注外文。（如：有氧运动、曼哈顿计划）本条让位于#4。”

比如说：许多国名在两岸四地各有些微差异。无论是哪个国名应该在各自的境内都算是常见的，不过对于各自境外地区的人来说，可能会有疑问。
专有名词常见与否，每个人的认知会有差异。
在下这几天在英文维基百科发现，英文维基百科似乎已经存有许多各类的中文重定向。因此在下认为中文维基百科可以更开放些，开放常见的专有名词外语重定向的创建，以此作为渐渐地向英文维基百科靠拢的第一步 (其它前几大的维基百科则几乎可以直接输入英文来查询特定条目)。谢谢!! =) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 09:25 (UTC)

标注事物源语言文字不出奇，但是不会过度标注，多数是导语标一次，而且只有特定专用名词会标。——路过围观的Sakamotosan 2017年7月23日 (日) 09:40 (UTC)

(＋)同意同意。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 09:43 (UTC)

- 这里好像是讨论在内文标注外语而不是外语重定向。--A2093064#Talk 2017年7月23日 (日) 09:37 (UTC)

(：)回应在下以为是在讨论重定向 XD。感谢阁下缜密的思维，在下完全同意里面的规矩。我觉得“该词中文尽管是个源自外语的专有名词但却过于常见，这种情况下不应该标注外文。（如：有氧运动、曼哈顿计划）本条让位于#4。”建议从宽认定。谢谢！=)
我发现我搞错题目正要改的时候遇到同时编辑完成，当下心中吓了一跳想说被发现了XD --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 09:40 (UTC)

国名差异、两岸叫法不同：丢给公共转换组吧。
文中的“过于常见的中文名词”，每个人大概都有数，我就不说了。里面是我认为我能够接受的最低限度——如果比有氧运动和曼哈顿计划还要不常见，那么各位打打擦边球我个人是不想管的。
许多专有名词尽管没有建立重定向，但用搜索框找一下依然排在首位。因此我来补上一句“科学技术名词（红细胞、顶夸克、杠杆原理）和源自英语地区的地名、人名等专有名词必须在开头关键词后附注英文”--燃⁠灯 ^谈笑风生 2017年7月23日 (日) 12:26 (UTC)

在下刚才查了一下基础条目中的科学和技术领域似乎没有涵盖数学、历史、地理、艺术、......领域。因此是否直接以国家教育研究院或其他类似辞典为准则。若条目名称属于学术专有名词，则可以建立外语重定向。(不限英文)--It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 12:55 (UTC)

举几个英文维基百科的例子：en:高雄捷运、en:台北捷运是存在的重定向。

提供参考。谢谢!=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 13:31 (UTC)

建议改名为“格式手册/外文附注”。--J.Wong 2017年7月23日 (日) 05:56 (UTC)

那么放在这里煮过讨论过后，能否升格为正式指引？还是得“仅供参考”，像那个互助客栈导航模板的其他灰字一样？--燃⁠灯 ^谈笑风生 2017年7月23日 (日) 12:26 (UTC)

燃⁠灯君︰且看能否就确立为指引达成共识。--J.Wong 2017年7月23日 (日) 17:59 (UTC)

我在想说此类模板上能否加注外文呢？ (且 mobile view 并不会显示此类模板) 就当成是路上看到的路牌一样，既然有导航指引作用，感觉加上外文会更全面一点。不过共识若认为无此需要，在下也尊重。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 12:35 (UTC)

我认为无此需要，太乱。而且就算是医学生，我觉得也得同时通晓一个医学名词的中文和外文形式吧，中文用来和患者、中文同事交流，英文用来看文献。--燃⁠灯 ^谈笑风生 2017年7月23日 (日) 12:43 (UTC)

我是觉得这样的中英并存的排版能让业余、专业、部分专业的人对于条目之间的差异 (抽搐、癫痫、昏厥、昏倒、晕眩、眩晕、头晕、......) 一目了然。不过还是看大家。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 12:55 (UTC)

在下是觉得平常我们在路上应该不会因为看到路牌上的外文标注就心情受影响，那么既然外文标注是有作用的，保存也无妨。没有英文标注的路牌和有标注外文的路牌都是合法的，那么维基百科也可以现实生活中的共识为共识，亦即模板一定要以中文为主，至于是否有外文标注都可以。=) 提供各位参考看看。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 13:19 (UTC)

路标的问题 -- 如果只是路标那样标明4、5个地点，那么加上外文我当然无所谓。但是导航模板不是路标。

区别一：导航模板数量规模庞大，动辄50多。
区别二：路标并不不具备互动的能力，不能够在若干次点击后将该词的英文显示出来。

至于头晕系列的，我还是老样子，建议改写为这样子的词汇表，一目了然，也省得又纠缠不清。--燃⁠灯 ^谈笑风生 2017年7月23日 (日) 13:36 (UTC)

- - - - (：)回应改写为这样子的词汇表可行。只是担心未来会出现许多类似的情况，这样一来，就会花很多时间在做词汇表。=) --It's gonna be awesome!✎Talk♬ 2017年7月24日 (一) 04:44 (UTC)

模版中若有几个中文条目尚未建立的连结，也许可以再列一下英文名称，可是若中文条目已建立，不太建议所有条目（或大部分条目）都加上英文名称。若所有连结加上英文，会大幅增加模版的篇幅，而且大家会看到模版中的大部分会是英文，降低可读性。--Wolfch (留言) _{欢迎参与今年的动员令} 2017年7月23日 (日) 13:33 (UTC)

谢谢以上几位提供宝贵的意见。=) 谢谢燃灯君主动提供大家这个讨论的机会。欢迎大家继续提供意见以寻求共识!! ^__^ 谢谢!! --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 14:07 (UTC)

那么问题来了：像这个情况算不算翻译未完成呢？注意：除非修改快速删除方针，翻译未完成的可以按照“包含过多非现代汉语”的标准以G14删除，无需加挂{{notmandarin}}--燃⁠灯 ^谈笑风生 2017年7月23日 (日) 13:54 (UTC)

(：)回应如果从编者或相关人员的立场来看，可能算是大致完成了吧，因为有时候刻意要把英文专有名词用中文念会变得很拗口。就编者的立场来说，可参考的资讯减少，怕会翻错。但对于纯中文的读者来说，可能会觉得是及格上下的模板，因为很多都看不懂。=) --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 17:13 (UTC)

(：)回应我会认为像这个情况，许多连结没有中文，算是翻译未完成。--Wolfch (留言) _{欢迎参与今年的动员令} 2017年7月23日 (日) 17:23 (UTC)

看来这又是另外一个问题了，涉及到快速删除模板的事情。这个讨论完了之后再新开个讨论吧，裁定什么是导航模板的保留标准。--燃⁠灯 ^谈笑风生 2017年7月23日 (日) 18:39 (UTC)

(＋)支持这项提案，阁下已经把我想说的全写进去了，实在没有什么更好的意见可以发表。就在下认为，如果蓝链与绿链已足供读者查询到条目相关的资讯（包含但不限于WIki上的资讯），那么标注原文就是多余而不必要的，仅在某些条目中的语汇、用词、名词等字句没有连结（即红链）或在可预见的未来中均不会被创建时，原文的标注才可作为提供读者进一步蒐寻相关资讯的手段；易言之，原文的标注是一种附加的资讯，并非必要，若文内已存在充分的线索供读者参阅，那么就无须附加多余的资讯。一点拙见，仅此表明立场。--NoobWayne™讨论 2017年7月23日 (日) 14:49 (UTC)

谢谢你 --It's gonna be awesome!✎Talk♬ 2017年7月23日 (日) 17:05 (UTC)

谢谢各位参与讨论！目前来看，虽然并没有将所有模糊的问题全部规定下来（见下方“相关问题”一节），但该草案已写下的部分似乎没有什么争议了，将进入表决环节。希望各位投票/写下自己的意见，以决定是否将该草案升级为指引。投票时间7天，随后将从我的用户页移动至格式手册/外文附注，并留此再公示7天。没有大问题的话，将在公示结束后将该内容标注为正式指引，并结案。燃⁠灯 ^谈笑风生 2017年7月23日 (日) 19:05 (UTC)

太快了吧，才讨论一天而已。--A2093064#Talk 2017年7月24日 (一) 00:02 (UTC)

@A2093064：我对此没经验，请问多久比较合适？燃⁠灯 ^谈笑风生 2017年7月24日 (一) 00:45 (UTC)

根据惯例，发起讨论后至少七日才得以进入公示程序；另请格外注意投票不能代替讨论，只有特殊状况才将讨论共识交付投票决定。－ Aotfs2013 留于 2017年7月24日 (一) 06:21 (UTC)

看了一下草案，觉得还太粗糙。以下先列几点想到的：
1. 应该有个例外是让译自外文、中文易混淆的名词标注外文，比方说英文里的 Nation Country State 中文都有可能混译成“国家”，在英文中则有不同的指涉，有些时候需要标注原文才会比较清楚。
2. 存在简称的词应该容许标注原文+简称，不然很难查到简称是什么意思，就算用搜寻，有时碰到简写与常用英文字相同时也很麻烦。一般格式是（原名, 简称），例如“美国全国妇女组织（National Organization for Women, NOW）
3. “该词源自中文，不应该标注外文。”这应该是通则，例外是“该词虽然源自中文，但有特殊需要时可标注外文译名以供参考”。因为有些文件里的外文译名不见得是当今中文世界常用的汉语拼音或台湾习惯的韦氏拼音（可能因为当初语音不同，或不是译自北京官话系统），标注才能找到关键词。比方说“在5世纪的某英文作品里出现老子（Lo-zu）的记载”。

--Reke（留言） 2017年7月24日 (一) 01:39 (UTC)

(：)回应谢谢！确实都是需要详细讨论的部分。我编写这类东西的经验不足，外加阅历有限，请多多指教！

我个人的观点：

1. 这个出现在原文里还好。出现在导航模板、消歧义的部分呢？
2. 关于附不附英文全称——导航模板就算了，其他地方看情况，用{{abbr}}最好。
3. 您给的这个例子我觉得没有必要附上老子的外语格式。它在条目里出现的话大概会这样：
  1. 在5世纪的某英文作品里出现老子（Lo-zu）的记载。其作者在第X章第X节将老子描绘为“最XX的XX，是中国历代XX中的XX”^{[注 1]}。
  2. 然后把原文放到参注部分，标明出自哪个语言。
另外，这次我猴急的原因主要是想要快速确认哪些是达成共识的部分、哪些不是，以便进一步修整一部分条目格式，因此写得比较糙一些，抱歉 :P

--燃⁠灯 ^谈笑风生 2017年7月24日 (一) 03:46 (UTC)

回应

导航模板我的看法是要看会不会影响导航的效果。如果加了之后能让人不会错连到中文很混淆的专有名词，我暂时想不到例子，但有些医学用语的确在译成中文后会长得差不多，专业人员不看原文也不知道分别是什么。
主要是针对条目内文，导航模板因为很明显只是导航功能，不是用来说明内容，附缩写即可。
你想像的内容已经有标注外语了啊，就是这个“老子（Lo-zu）”。其实原文句子倒不一定有需要放，如果要引全句，的确是放注释，而且那个Lo-zu就没必要加注，反正引文中会提。但是在没有引用原文句子必要的时候，直接加注一个词的原文可以让读者方便在文献里搜索。比方说如果条目不是“老子”“道家”这类直接跟老子思想相关的内容，而是“中西哲学交流”这种主题，然后内容有“在5世纪的某英文作品里出现老子（Lo-zu）的记载、也有同时代的文物中提及《论语》中的故事……可见当时已经有中国哲学经典……”这样如果引原文就太离题，注记一下名词让读者查证时不会找不到就好。（当然，这是个架空的例子，不是说写这个主题真的会碰到，只是可以想像出有这种情况）。

我看了新的回应，感觉你好像偏重在导航模板？其实我在想要不要针对导航模板的使用订出格式指引会比较简单，因为你针对“条目”，我觉得文章中会出现各种可能的情况就太多了，要能全面地给予规范并不是很容易。--Reke（留言） 2017年7月24日 (一) 08:43 (UTC)

像这个模板User:It's_gonna_be_awesome/template:Gram-negative_proteo-bacterial_diseases 若要全翻成中文才算完成，可能会变得非常拗口。=) (我突然忘记我接下来要说什么了，想到再补 @_@) --It's gonna be awesome!✎Talk♬ 2017年7月26日 (三) 17:30 (UTC)

目前来看，需要进一步讨论的问题如下：

什么是“专有名词”？（建议与上方有关重定向的问题一并讨论）
如何区别{{lang-en}}与{{lang|en}}等模板的使用？
什么样的导航模板算“翻译完成”？导航模板常常作为条目的一部分出现，这种情况下G14是否能够删除导航模板？
日语假名、韩文汉字、越南文喃字的标注问题？
部分专有名词的简称问题：是否需要附上全称？比如条目正文中出现世界卫生组织（World Health Organization，WHO）之类的。如果是开篇第一句的话或许是必须的，如果是后文呢？是否采用{{abbr}}模板？
“在5世纪的某英文作品里出现老子（Lo-zu）的记载”。此时为了读者查阅参考文献方便，“老子”是否需要附注外文？
容易混淆的词（华盛顿州、华盛顿特区、墨西哥、墨西哥城、头昏、昏厥）是否需要外文标注？导航模板需要标注外文吗？开头消歧义类模板呢？
如何定义“中文尽管是个源自外语的专有名词但却过于常见”中的“过于常见”？

这些内容是衍生自草案的问题。（原文已更改）--燃⁠灯 ^谈笑风生 2017年7月24日 (一) 03:58 (UTC)

所以还不是没讨论清楚吗？——路过围观的Sakamotosan 2017年7月24日 (一) 00:55 (UTC)

我的大方向是音译的尽量标明，非出自中文地区的地名、人名、出版物名字都应该标明原始地所用语言的名字--百無一用是書生 (☎) 2017年7月24日 (一) 01:57 (UTC)

(＆)建议条文中加入：“如有特殊原因需要加上外语标注，可于程式码中加入说明。”=) 感谢，辛苦了！

谢谢你 --It's gonna be awesome!✎Talk♬ 2017年7月24日 (一) 17:10 (UTC)

这个是另一个议题，另案讨论吧。程式码中加入说明的外语标注只是针对编者的，读者看不到类似内容，另外，用说明的外语标注内容若太多，对其他编辑可能会是干扰（至少对我来说是干扰）--2017年7月24日 (一) 22:21 (UTC)

或者放在讨论区也可。=) --It's gonna be awesome!✎Talk♬ 2017年7月26日 (三) 17:16 (UTC)

再讨论似乎又离题了, 另案讨论吧。--Wolfch (留言) _{欢迎参与今年的动员令} 2017年7月26日 (三) 22:36 (UTC)

=) --It's gonna be awesome!✎Talk♬ 2017年7月29日 (六) 15:44 (UTC)

专有名词一般包括人、地点、组织、机构、公司、出版物、月份星期几等的名称。在英文里首字母通常大写，参考著名出版社Springer [7]的说明
容易混淆的词中举例可能不太恰当，华盛顿州、华盛顿特区、墨西哥、墨西哥城是专有名词，头昏、昏厥则只能算是专业术语
“中文尽管是个源自外语的专有名词但却过于常见”，~~大概是指摩托，啤酒，幽默，妈妈，休克，杂志，航空母舰，琵琶，警察这一类？~~咦，不对，这些似乎都不是专有名词

--百無一用是書生 (☎) 2017年7月25日 (二) 02:32 (UTC)

修改Wikipedia:格式手册#空格

本主题或以下段落文字，移动自WP:VPP。执行者：--J.Wong 2018年3月10日 (六) 07:50 (UTC)。

现行条文

外文单词及数字间应按原文保留空格（例：Google Chrome、Windows 2000），但符号前后通常不加空格（例：IBM System/360）。

提议条文

外文单词及数字间应按原文保留空格（例：Google Chrome、Windows 2000）。

本讨论已经结束。请不要对这个存档做任何编辑。

未提及是什么符号，像是英文的逗号、分号、冒号等后面通常应添加空格，斜线前后的空格应视前后文而定（参见en:Slash (punctuation)#Spacing）。-- tang891228 _留言 2018年2月14日 (三) 15:15 (UTC)

提案已有一段时间，现交付公示，为期七日，如无异议，将视为通过。--J.Wong 2018年2月23日 (五) 10:56 (UTC)
已修订。--J.Wong 2018年3月2日 (五) 11:27 (UTC)

《格式手册》小修改通知

本主题全部或部分段落文字，已移动至WP:VPP。执行人：--J.Wong 2018年6月30日 (六) 03:13 (UTC)。

近日有修订如此，谨此通知。--J.Wong 2018年6月23日 (六) 07:04 (UTC)

鄙人觉得修正两个内部链接属于不涉及对方针本身的修改，如有不妥，还请u:CopperSulfate赐教。ïMark | 批判一番 2018年6月24日 (日) 09:49 (UTC)

@Markove：抱歉，没看见这个

囧rz……(＋)支持此次修改。--相信友谊就是魔法的~~User:萌得不能再萌~~CuSO₄正在努力提高知识水平 2018年6月24日 (日) 09:56 (UTC)

提议大幅修订格式手册

本主题或以下段落文字，移动自WP:VPP。执行者：B dash（留言） 2018年9月28日 (五) 07:38 (UTC)。

草稿见Wikipedia:格式手册/更新草案2018（新旧比对）

修订起因：在编写条目和新页面巡查的过程中无法以理想的效率使用格式手册及其各个分编，试举两例

比如说中科院宁波工研院的该笔编辑，参见和参考资料的格式顺序，以及其他固定章节和元素的顺序，并没有直观体现在格式手册中。
每天都有比较多音乐专辑的条目出现，但Wikipedia:音乐专题/专辑条目格式指导已经很久没有引起注意，始终没有进一步翻译或完善。

修订目的：以格式手册为总则和大纲，理顺手册和各个分编逻辑关系。同时促进分编内容的全面展现，促进未成为方针指引的分编不断完善。修订：

以维基百科:格式手册/版面布局规定的条目结构来构建格式手册结构，是为各项格式规则（如，WP:格式手册/标点符号等这一类具体细则）构建一个清晰统一的接口，而不是探讨具体的条目结构是否合理（如，参见和参考文献何者在先），核心内容分为
- 条目结构：分导言章节、主体章节、附录章节介绍各章节组成元素；
- 通用格式规则：介绍条目三部分编辑都有可能使用的格式
- 导言格式规则：以{{main|Wikipedia:格式手册/导言格式规则}}链接到分编页面，介绍导言章节的格式规则；
- 主体格式规则：以{{main|Wikipedia:格式手册/主体格式规则}}链接到分编页面，介绍主体章节的格式规则；
- 附录格式规则：以{{main|Wikipedia:格式手册/附录格式规则}}链接到分编页面，介绍附录章节的格式规则；
- 主题专门格式手册：分类介绍现有各类主题条目编制的专门格式手册（如，文化创作类条目的Wikipedia:电子游戏专题/条目指引）
对原格式手册中各个章节的内容，按照上条确定的逻辑结构分别分流放置。

请诸位讨论--Kirk 0讨论│签名0 2018年9月15日 (六) 04:47 (UTC)

倒是讲个古。我知道中文维基有一票人，很爱更改“参见”和“参考资料”的位置，特别是要把“参见”放在最后方。根据我在2014年的手动调查，在经过有人特地以机器人方式更改、及部分维基人坚持特定格式，这种格式仍然只占6%的特色条目及11%的优良条目。至于在经过一段有人径自定调的时期，及中文维基很久没管以机器人模式修改顺序的事情，不知道情况如何了。--KOKUYO（留言） 2018年9月15日 (六) 05:15 (UTC)

基本上反对这样做，一是Wikipedia:格式手册应当只是个入口，结构上不应对各项如此详述；二来各种范畴的主体和附录的结构有着十分大不同的需求，直接在最顶层规定统一的规则只徒增各个范畴的麻烦。--街燈電箱150號开箱维修抄表检验证明 2018年9月16日 (日) 00:15 (UTC)
- @Cdip150：非常同意您说的，Wikipedia:格式手册应当只是个入口。但是私以为现在的入口缺乏一个清晰的逻辑，而且个别方针和很多没有成为方针但有价值进一步改善的指引，没有通过易于获得的方式呈现在目前的格式手册中。而对格式手册中的各项“入口”进行逻辑上的梳理，是更为清晰的呈现各项方针细则最好的方式。在这个过程中，必然需要选择以某种逻辑去梳理。而在下觉得不妨以条目结构顺序梳理各项方针细则，遂写下此草案Draft:格式手册。--Kirk 0格式手册大修订0 2018年9月16日 (日) 08:35 (UTC)
- Wikipedia:格式手册/更新草案2018使用大量{{main}}以主条目形式呈现具体细则，目的正是为各项格式规则构建一个清晰统一的接口。--Kirk 0格式手册大修订0 2018年9月16日 (日) 08:35 (UTC)
不认为统一、规范化是坏事，但有共识的规范可能很难达成。如果能收集整理现有的常见版式写法并编撰出来，可能更有讨论而非争论的可行性，进而形成编辑指引（非方针，后者约束性过强，有更强阻力，不宜过早讨论）。“main”那三项没看懂表意。就“参见”与“参考资料”的位置，我认为“参见”在上说明是条目的一部分，向读者提供的附言，在“参考资料”下方就比较像条目之外的内容了，这更应该由MediaWiki系统来提供推荐。序言、章节结构等版式写法，目前是有潜在争议的，讨论可能易形成争论而非达成共识。--YFdyh000（留言） 2018年9月16日 (日) 00:56 (UTC)
- (：)回应@YFdyh000：是我没有表意清楚，目前已经更正。“main”那三项，指的是这三部分不直接罗列，比如涉及维护性模板安放格式的方针，归入Wikipedia:格式手册/导言格式规则页面进行说明，一方面避免WP:格式手册主页过长，另一方面起到了比较好的“接口”作用。--Kirk 0格式手册大修订0 2018年9月16日 (日) 08:43 (UTC)

Opky9407和KOKUYO君就“参见”和“参考资料”的顺序问题，进行了坦诚而详尽的讨论，尽管这与本讨论的核心问题相关度稍低，但相信之后在条目结构方针的修改中将会很有价值

参考注释才是向读者提供附言，像是台风条目如台风山竹 (2018年)都是用参考注释来说明条目内文和支持内文，而参见用来放其他台风条目，参见才是条目之外的内容，所以这种情况先列参考注释比参见较适合。--Opky9407（留言） 2018年9月16日 (日) 01:06 (UTC)
- 随便转换的范畴就能证明这理由的无效，参见是在维基百科内部的有关条目，参考资料和外部链接是维基百科以外的有关资料，维基百科内部的比维基百科外部的更加亲近，结果自然是“参见”应该在“参考资料”上。另外正常人根本不会逐一看来源（例如“1. 台风百问——台风是怎么命名？. 交通部中央气象局. [2018-09-27]. （原始内容存档于2017-11-04）.2. 热带气旋名称的意义. 香港天文台. [2018-09-27]. （原始内容存档于2018-06-05）.3. 22号台风山竹已现雏形，它将挑战飞燕“风王”宝座并登陆我国. 中原网. [2018-09-11]. （原始内容存档于2018-09-11）.……”），单纯只看该段完全没有意义。所以你的说法只是形而上学的讨论，根本没有真正考虑那段为何有在那位置被阅读到的必要性（因为“参考资料”这类段落根本不可能单独被阅读）。--KOKUYO（留言） 2018年9月16日 (日) 01:58 (UTC)
  - 这理由根本非常儿戏，读者关注的是条目的主题，不是关注维基内外，参见是亲维基又如何，它是跟内容离题的，没有针对内容，但是参注是合题的，因为都是直接针对内容。而且至少我会看“当有2种以上全球预报模式……”，这明显较必要，转跳下来的时候中间看到一个离题的“热带风暴百里嘉”我会感到很奇怪，因为我没必要看那个参见，把它放先才没有真正考虑必要性和逻辑。--Opky9407（留言） 2018年9月16日 (日) 02:16 (UTC)
    - 说不定参见的主题可以比参考资料相等、甚至更亲近，例如这个人的别名文化、名言条目、著作、其获得的年度诺贝尔和平奖条目等，这叫做跟原本人物条目离题的？你举的例子只是为了服膺你的想法（因为它的关联性，可能根本连参见都不需要）。然后注释本身很多条目根本都没有，甚至能够用创建条目处理，证明你只是用能够服膺你的意见的条目去当作理据。另外，当我在说没人会只看“1. 台风百问——台风是怎么命名？. 交通部中央气象局. [2018-09-27]. （原始内容存档于2017-11-04）.2. 热带气旋名称的意义. 香港天文台. [2018-09-27]. （原始内容存档于2018-06-05）.3. 22号台风山竹已现雏形，它将挑战飞燕“风王”宝座并登陆我国. 中原网. [2018-09-11]. （原始内容存档于2018-09-11）.……”或“1. 瘾游戏：任天堂DSi日本首发. Engadget 中文版. [2018-08-25].2. Michael French. Nintendo DSi hits Europe on April 3rd, priced £149.99. Market for Home Computing and Video Games. Intent Media. 2009-02-19 [2018-08-24]. （原始内容存档于2009-03-18）.3. Nintendo DSi launches April 5 in the United States. Nintendo of America. 2009-02-18 [2018-08-24]. （原始内容存档于2010-05-29）.……”等段落，你为何不直接回答这段的问题呢？--KOKUYO（留言） 2018年9月16日 (日) 02:27 (UTC)
      - 其实你也是在服膺你的想法，参见总会是另外一个主题，不会支持本身内容，根本不可能亲近，遑论相等。列出那个台风是有必要，因为考虑到人家想知道同期有其他台风，但必要性明显较注释低。另外，我读完正文，确实我是先会先看参考里有的连结，因为参考连结通常有更多针对条目主题但条目没有编的内容，但参见不是。--Opky9407（留言） 2018年9月16日 (日) 02:50 (UTC)
        假设在“蔡英文”的条目中，有一则“2016台湾“大选”候选人号次抽签举行”的来源，以及“蔡英文的评价”条目的相关条目，然后你还是会说前者比起后者与蔡英文相等是吧。你的这种说法，当你要求别人一定要相等就得要相等，至于自己提的不相等就自动忽视，那就没什么好讨论的。--KOKUYO（留言） 2018年9月16日 (日) 02:55 (UTC)
        说人家服膺结果自己也服膺，“蔡英文的评论”应该在“评论”章节用“主条目：蔡英文的评论”，不应用参见，参见是放没有直接关系的连结。--Opky9407（留言） 2018年9月16日 (日) 03:05 (UTC)
        所以我说假设，而且该条目不一定用评价段落。还是因为你没什么再写过条目，所以不知道条目可能没有评论段落？而且你举的例子，那个参见连结同样可以不用放。--KOKUYO（留言） 2018年9月16日 (日) 03:20 (UTC)

为了避免有人觉得我说“参见”放在前面是常用做法是骗人的，我在这边补上在2014年初做的统计资料。之所以写“非‘相关条目’先于‘参考资料’”，是因为这包含许多不同写法的条目，否则单纯把“相关条目”放在最后方的写法会更少。--KOKUYO（留言） 2018年9月16日 (日) 03:14 (UTC)

特色条目
“相关条目”先于“参考资料”	非“相关条目”先于“参考资料”	条目直接没有“相关条目”	样本数量
128（52%）	15（6%）	101（41%）	244（100%）

优良条目
“相关条目”先于“参考资料”	非“相关条目”先于“参考资料”	条目直接没有“相关条目”	样本数量
442（41%）	120（11%）	506（49%）	1,068（100%）

举不出更好的理由就搬数量，不许这是羊群心理造成的吗？--Opky9407（留言） 2018年9月16日 (日) 03:32 (UTC)
- 秀个理论不会比较厉害。另外，“共识通常会在编者的编辑过程中自然达成……该页面的所有读者也可以选择去修改它或保持其不变”，然后你说这是羊群效应，我也只能笑笑。--KOKUYO（留言） 2018年9月16日 (日) 03:35 (UTC)

其实不太想再吵这个问题，相关条目在不同范畴各自有自己的考虑理由，而列出的条目选择要求也有不同，不能像上面拿着政治人物类条目和台风类条目来比较再来统一结论。还有数量是无意义的，量多就是正确？我在澳门街道专题定立的排版法其实也不是“常用”，只按照条目内容相关纹理逻辑来订定，相关条目的选取也不会选得直接，结果在参评的时候都没有引起反弹。所以各范畴各取所需，强求统一从过往执行的经验来看不见得是好事。--街燈電箱150號开箱维修抄表检验证明 2018年9月16日 (日) 03:16 (UTC)
- 我也懒得吵，因为中文维基发展历程与其他语言发展历程不一样，现在如果订立强制的规定根本来不及。但是在客观条件上，“有多数人会习惯使用‘相关条目’先于‘参考资料’格式”是客观现实（52%对上6%，这点应该不用特别解释了）。如果无视这个客观现实，还有人不断推动自己的主张、甚至以机器人方式修改格式，都是有问题的。--KOKUYO（留言） 2018年9月16日 (日) 03:31 (UTC)
  - 的确维基上有着不少过往很多人用的做法但后来证明不合理的例子（Infobox和Disambig以前的次序就是一例），所以拿数据来说不见得就完全客观，当然以机器模式来推动的确不妥。总之，我主张是各专题定各自规则，而反对完全统一规则。--街燈電箱150號开箱维修抄表检验证明 2018年9月16日 (日) 03:45 (UTC)
    - 方针指引并非是如此认为，尤其是你借由举出一些例子来否定以惯例制定规则这件事情上是有问题的，涉及的相关方针有“总体来讲，有三种方式去制订某项方针或指引：……3. 逐渐演化出的常规或惯例。”、“共识通常会在编者的编辑过程中自然达成”。而当前这个数据便是提供判断何谓惯例、以及若要用惯例制定规则时能够使用的参考资料。--KOKUYO（留言） 2018年9月16日 (日) 03:55 (UTC)
      - “逐渐演化出的常规或惯例”方针指引仅指出是可以透过这个方法而已，但从没有指出这是一定要的。总不能说以前有80%把Infobox放在最前所以因“共识通常会在编者的编辑过程中自然达成”而不能改吧。这不是说要否定您的数据，而是说引用数据时还应考虑其他因素，尤其是数据背后的个中原因也会影响参考价值。--街燈電箱150號开箱维修抄表检验证明 2018年9月16日 (日) 04:16 (UTC)
        当然可以讨论，但不代表可以否定数据的客观情境，假设一群人自嗨订出规则，却因不符合惯例和实际情境，而几乎没人实行，那就是可笑的闹剧。说到底，“讨论取得共识”是方针指引制订的第二种方法，但前提是要有明确共识、及真正能够执行，否则至多就是较多人的见解。--KOKUYO（留言） 2018年9月16日 (日) 04:33 (UTC)

非常想(＆)建议和(＊)提醒大家：在下非常希望能够以某种逻辑使WP:格式手册以更有条理更清晰的方式成为诸如WP:格式手册/标点符号等等各项方针细则（也就是格式手册的各个分编细则）的入口。在下基于编辑和巡查的经验考量，提议以条目结构为逻辑编辑。关于参见和参考文献谁先谁后，等涉及条目具体结构的问题，目前还不迫切：因为大家还未就格式手册是否以条目结构来梳理达成共识。--Kirk 0格式手册大修订0 2018年9月16日 (日) 08:29 (UTC)
我不明白为什么你们定要分出个高下来...这些格式长期并存，且各有支持者，说明它们在某些情况各有自己的优点。我会提议格式手册分别列出这些常见的模式，而无须强行定出一个"正统"。就像论文格式有APA有IEEE，中文字有繁有简，很多时间这些问题都吵不出什么结果来。倒不如求同存异，自己写的条目就用自己的排版，不是太离谱就可以了。--Temp3600（留言） 2018年9月16日 (日) 15:43 (UTC)
- 我个人觉得，有清晰格式标准的一个目的是向新手提供一个清晰的编写建议，仅仅从引导新手的角度考虑，制定一个明确的手册也是有一定价值的。--Kirk 0格式手册大修订0 2018年9月17日 (一) 12:43 (UTC)
  - 过往经验，这类标准问题的争执通常都没有好结果。可以推荐几条不同结构的优秀条目给新手，从例子中学习。没有必要"定于一尊"，将问题扩大化，吵上VIP就更更糟糕。--Temp3600（留言） 2018年9月17日 (一) 13:18 (UTC)

顺带一个建议，是否叫WP:体例更专业一点？--百無一用是書生 (☎) 2018年9月17日 (一) 02:02 (UTC)

支持。但“凡例”呢？是词典用语？ --达师 - 370 - 608 2018年9月17日 (一) 07:51 (UTC)

是将WP:格式手册改为WP:体例或WP:凡例吗？--Kirk 0格式手册大修订0 2018年9月17日 (一) 12:49 (UTC)

(－)反对：用词不能太过专业，“格式手册”本来是对新手比较平易的用词，表面一看就知道是谈格式的，但“体例”和“凡例”的意义较隐蔽，新手未必一看就知道。--113.52.81.38（留言） 2018年9月17日 (一) 13:38 (UTC)

体例是指编篡格式，是对编者的要求，凡例是指对格式的举例，主要是针对读者，类似于说明书性质。二者都是辞书中最常用的用语之一。可以参考[8]。既然是百科全书，自然要体现出百科全书编辑的专业性来。何况，任何一本辞书，几乎都有体例和凡例，面向编者和读者。使用维基百科的人群，应该几乎都有使用过某种辞书，不应当对此陌生--百無一用是書生 (☎) 2018年9月18日 (二) 03:25 (UTC)

(－)反对任何大规模修改。大规模修改方案难以评审。 --🐕🎈（实用主义大于天） 2018年9月18日 (二) 05:28 (UTC)
- 关于实质性修订和结构性修订本次修订是以各项已通过方针为核心进行的修订，主要是对已通过方针进行逻辑上的梳理，而不是大规模的进行实质性修订。结构性修改看起来变动量较大，但是目前所必须的。
  1. 修订的历史原因：现存式手册是由许多次为适应新情况而追加新的内容形成的。在追加修订的过程中，一般以实质性内容为核心。故而形成了目前格式手册中大量二级标题章节以比较缺乏逻辑的方式呈现的情况。这种情况是的可以理解的，因为调整结构的难度是比较大的。
  2. 修订的必要性：还有很多有价值的论述没有成为方针，格式手册以及其下的分编分则必然还要追加，我们需要帮助论述(提高曝光度，帮助有价值的论述获得更多关注，并成为方针)和方针以更清晰的方式呈现，而结构清晰度有待提高的情况应该尽早解决。为以后的实质性修订铺路。--Kirk 0格式手册大修订0 2018年9月18日 (二) 06:01 (UTC)
  - 我认为先写成指引乃至论述（可以介绍各版式的理解、利弊）就可以，之后讨论更简单，各部分如何调整、是否通过。--YF dyh000（留言） 2018年9月18日 (二) 12:09 (UTC)
回到入口还是要(－)反对，对于新手，现在的页面列举了一些很基本的示范，有助新手轻易对格式上手，但是新版却复杂许多，所谓的分编的条理确实也很难理解，根本面对不了新手作为入口。那么宁可维持现状。--Opky9407（留言） 2018年9月18日 (二) 12:41 (UTC)
- (：)回应：个人认为目前页面的情况不是这样，如，新手很难通过浏览现有的页面，比较快地获知：1、条目需要标注参考资料；2、条目如何标注参考资料。--Kirk 0格式手册大修订0 2018年9月18日 (二) 15:09 (UTC)
  - 我觉得这位的意见应该吸收。我们不能仅考虑结构性而忽略了对新人的友好性。 --达师 - 370 - 608 2018年9月20日 (四) 07:11 (UTC)
    - 嗯，想想看。大家有什么建议恳请尽管说。--Kirk 0格式手册大修订0 2018年9月20日 (四) 17:00 (UTC)

建议将格式手册中所有的“台灣”修正为“臺灣”

本主题或以下段落文字，移动自WP:VPP。执行者：--J.Wong 2019年6月9日 (日) 09:21 (UTC)。

如题。由于需修改处不多，目前又无不适用之例外情况存在，并属事实性修改，故现起~~公示三天~~，若无反对意见将提请正名。—— Eric Liu_{（留言．留名．学生会）} 2019年2月23日 (六) 09:52 (UTC)

让用户们表决如何？--Matt Smith（留言） 2019年2月23日 (六) 11:10 (UTC)

之前有一篇讨论台改成臺的不知道被存到哪里，不过我倒是有找到这篇Wikipedia_talk:繁简处理/档案11#提案修正WP:繁简处理#勿手动转换异体字之“台/台”指引。 --船到桥头自然卷（留言） 2019年2月23日 (六) 11:37 (UTC)

嘛，因为条目那边吵的沸沸扬扬，这里先只讨论维基百科命名空间相关页面。—— Eric Liu_{（留言．留名．学生会）} 2019年2月23日 (六) 14:51 (UTC)

就是有讨论简繁转换改成台湾正体结果下面变成语言问题的那篇啊，结果大家只在那边喊台兰市都忘记讨论。 --船到桥头自然卷（留言） 2019年2月23日 (六) 15:08 (UTC)

其实那篇只有“繁简转换标签”一个标的而已⋯⋯—— Eric Liu_{（留言．留名．学生会）} 2019年2月24日 (日) 00:53 (UTC)

上次的讨论在这Wikipedia:互助客栈/其他#“台湾”“正体”？－Bangardi 2019年2月28日 (四) 14:00 (UTC)

(－)反对：WP:异体字：“‘台/臺’这一对字由于政治原因常常成为修改的对象，由于‘台’字虽为俗写，但是在台湾已经广泛使用，因此不应该对其进行手动转换，而是应该遵循先到先得的原则，因为对这些字进行手动转换对条目没有实际的改善作用。”无必要，且有一定的繁简破坏之嫌。--仍然相信友谊就是魔法的达拉CuSO₄崩吧提醒您：讨论千万条，文明第一条，沟通不规范，恋人两行泪。 2019年2月24日 (日) 10:00 (UTC)
- (～)补充：而且惯例是公示7天而非3天。3天有些短了。--仍然相信友谊就是魔法的达拉CuSO₄崩吧提醒您：讨论千万条，文明第一条，沟通不规范，恋人两行泪。 2019年2月24日 (日) 10:01 (UTC)
上次是因为“正體”的问题才开启的讨论，这一次修改不知有何意义。--超级王谨贺中文维基导游创立5周年暨突破3000篇旅行指南 2019年2月24日 (日) 10:11 (UTC)
- 我认为因为是格式手册，用字应较一般条目严谨。起码要用TA统一用字吧，不管是台或臺都好。由于在繁体字环境下两字会混杂，看起来很不舒服。—— Eric Liu_{（留言．留名．学生会）} 2019年2月24日 (日) 11:37 (UTC)
香港同时使用「台灣」和「臺灣」，noteTA执行上有一定根本性问题。Σαν μο σα^{The Trve Lawe of free Monarchies} 2019年2月25日 (一) 12:00 (UTC)

外文粗体

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

（后备方案）通过：

后备方案通过；Wikipedia:格式手册/传记及Wikipedia:格式手册/序言章节暂时不升格为指引。Σαν μο σα 2019年5月25日 (六) 13:52 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

想问一下社群对于外文粗体的使用上有没有任何先前共识／规定？Σαν μο σα ^{y=0 regardless the value of x} 2019年4月13日 (六) 00:25 (UTC)

电子游戏相关模板内的外文通常都是不加粗体的（不过简称我个人会予以加粗，Ex. 任天堂DSi）。—— Eric Liu_{（留言．留名．学生会．CUCC）} 2019年4月13日 (六) 03:08 (UTC)

参考记录，格式手册曾于2014年经简单讨论后，外文粗体被人移去，但同年稍后的深入讨论，社群对外文粗体没有最终共识。--Clithering（MMXIX） 2019年4月13日 (六) 05:41 (UTC)
- 查，社群对于外文粗体的使用上在当时似乎没有后续讨论，当时“接续较早前讨论”所标示的较早前讨论错误（已更正 at 2019年4月13日 (六) 06:28 (UTC)）。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月13日 (六) 06:24 (UTC)
不要粗体。本来外文就看不清，部分字体还特别小（比如藏文为了上下加字而不得不使用小字体），加粗就更看不清了。另外外文使用粗体违反了命名原则的使用中文方针。08、09年那会都不加粗体的，后来不知何时一批人开始给外文加粗体。--173.68.165.114（留言） 2019年4月13日 (六) 05:50 (UTC)
- 提醒楼上：《命名常规方针》不规范条目内容。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月13日 (六) 05:59 (UTC)
- 同意，但粗体标识的是名称，所以命名原则适用。不过您后面要求只在中文中常用的加粗，就没有问题了。--173.68.165.114（留言） 2019年4月18日 (四) 03:24 (UTC)
大家也可参考Wikipedia:格式手册/序言章节#外语名称（非方针指引）。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月13日 (六) 05:59 (UTC)
这其实应视乎那个外文名在中文话语里常不常被直接使用而定，以档案传输协定条目为例，日常说中文时大多不会直接说“File Transfer Protocol”，所以“File Transfer Protocol”不会整个加粗，但“FTP”在日常说中文时也很多时被直接用，所以加粗“FTP”。--街燈電箱150號开箱维修抄表检验证明 2019年4月13日 (六) 11:45 (UTC)
- 注：此意见和Ericliu1912相近（Ericliu1912在任天堂DSi里加粗了DSi）。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月13日 (六) 13:56 (UTC)
我想到几个涉及外文的情况：
1. 外文名在中文环境中属于最常用名称（例如Facebook：“Facebook（简称FB）是源于……”中的“Facebook”）；
2. 外文名在中文环境中属于较常用简称／缩略写法，例如：
  a. 任天堂DSi：“任天堂DSi（日语：ニンテンドーDSi，英语：Nintendo DSi，多简称为NDSi、DSi）是……”中的“NDSi”和“DSi”；
  
  b. 超文本传输协议：“超文本传输协定（英语：HyperText Transfer Protocol，缩写：HTTP）是一种用于……”中的“HTTP”；
3. 外文名在中文环境中不属于常用名称（例如陈纲 (清朝外交官)：“陈纲（西班牙语：Engracio Palanca，1871年－？），字紫衍，祖籍……”中的“Engracio Palanca”）；
以上，其中2b与2a的不同之处在于2b会为外文全称中对应缩写字母的外文字首加粗；另外1通常无异议。Σανμοσα ^{y=0 regardless the value of x} 2019年4月13日 (六) 14:24 (UTC)
- 2b的例子换做ICAC会比较好，不常看到香港的文字媒体把消防处直接呼为HKFSD，但是经常都看到把廉政公署直接呼为ICAC。另外还有一个例子是英格兰联赛杯，无论外文的全名、缩写、简称都不常出现于中文环境，所以全部都不加粗。--街燈電箱150號开箱维修抄表检验证明 2019年4月13日 (六) 15:43 (UTC)
  - 也可改成超文本传输协定（HTTP）。—— Eric Liu_{（留言．留名．学生会．CUCC）} 2019年4月13日 (六) 16:04 (UTC)
  - @Cdip150：我当时选用了HKFSD是因为“Hong Kong Fire Services Department”中的五个字首都被粗体，以对应缩写（ICAC没有这样的效果）。我把例子改为Ericliu1912的HTTP。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月13日 (六) 23:37 (UTC)
或许我把这个大话题收窄为几个问题，希望大家能够回答：
1. 你是否认同2a对于简称／缩略写法的加粗？
2. 如果上题的答案为“是”，则你是否也认同2b的首字母加粗？
3. 你是否认同应该把3的外文加粗？
以上。我个人的回答是：1.是；2.否；3.否。Σανμοσα ^{y=0 regardless the value of x} 2019年4月14日 (日) 03:38 (UTC)
- 1.赞成；2.基本不赞成。显而易见的缩写法一望而知，不显而易见的缩写法较难提供可靠来源印证（所以可能提供的就是错的。若有来源，宜在正文中介绍），维基源码和呈现效果也有点乱。3.不赞成。--YF dyh000（留言） 2019年4月15日 (一) 03:04 (UTC)
- 1. 是；2. 否；3. 否。—— Eric Liu_{（留言．留名．学生会．CUCC）} 2019年4月15日 (一) 10:41 (UTC)
- 1.还要细分情况：(a)如果缩写是中文环境常用的（如档案传输协定的FTP），是；(b)如果缩写是中文环境不常用的（如欧洲冠军联赛的UCL），否。2.中立。3.否。--街燈電箱150號开箱维修抄表检验证明 2019年4月16日 (二) 00:54 (UTC)
我还想追加两个问题：
4.如果有人将2a中对于简称／缩略写法的加粗去除了，是否应该恢复加粗？

5.如上题的答案是“否”，则如果有另一人恢复了加粗，是否应该取消该恢复加粗？
以上；我个人的回答是：4.否；5.是。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月18日 (四) 00:09 (UTC)
(！)意见：原则上同意1和2a，2b不同意但不介意下划线，3绝对不行。但是不同意Sanmosa所举的例子：FB从未在中文环境正式场合中被广泛用过，都不应该进入首段。HTTP这类简写绝对可以粗体，但粗体后不应出现在括号中。不建议任何括号中的文字加粗。加粗的一定是中文中常用的名称，与被加粗的文字属性（汉字、拉丁字母、西里尔字母、拼音如duang、注音文、藏文字头）无关，符合中文常用名称就行。
不过我同意对于原创中文译名的条目（听说维基百科中如果一个条目完全没有中文译名翻译可以自造一个），加粗相应外文（如高棉文）。但当该中文译名被广泛流传之后（如找到该名称被外不可靠来源引用三次），则去除该加粗。--173.68.165.114（留言） 2019年4月18日 (四) 03:24 (UTC)
- “FB”在Google新闻搜索的结果，我不说其他话了。Σανμοσα ^{y=0 regardless the value of x} 2019年4月19日 (五) 14:37 (UTC)
  - 多是英文结果，而且大量的FB与Facebook无关。如果限定中文呢？如果真有很多那可能是我out了。--173.68.165.114（留言） 2019年4月21日 (日) 00:43 (UTC)
- @Sanmosa：多是外文语境。如果FB也要列于序言乃至加粗，脸书、脸谱网是否也要呢。--YFdyh000（留言） 2019年4月20日 (六) 05:37 (UTC)
  - 为啥我找到的是香港中文媒体？（当然，我不反对只保留“Facebook”；“脸书”其实可以加入，“脸谱网”没怎听过。）Σαν μο σα ^{y=0 regardless the value of x} 2019年4月20日 (六) 07:19 (UTC)
  - “脸书”、“脸谱”、“非死不可”、“FB”我都祗在非正式语境听说过。如果要加的话都加上吧，不过个人觉得没太大必要，可以单独放在一个《名称》章节里，而且“脸书”一词明显是conlang，“面簿”倒是中文，可惜没“脸书”常用。呃……跑题了。我提这件事的目的是说我对这个模式的赞同不代表我赞同具体的示例，并不想真的去讨论那个条目。--173.68.165.114（留言） 2019年4月21日 (日) 00:47 (UTC)

建议修订

a. Wikipedia:格式手册/文字格式建议修改如下：

现行条文

将非拉丁字母如希腊字母和西里尔字母加粗，在技术上是可行的，但应当避免这么做。

提议条文
外文粗体

如果一个外文出现在条目定义句中，并且符合以下至少任何一种情形：

是中文维基百科中所属条目的名称；
在中文环境中属于非人名的常用简称／缩略写法；
属于未有中文版本的常用人物别名在中文环境中的最常用版本；

则该名称可根据Wikipedia:格式手册#条目定义句规定予以加粗，否则该外文不应加粗。外文全称的缩略写法字母不应单独加粗。

不过，即使该外文符合上述规定可予以加粗，移除第二类外文加粗的编辑仍不应被撤销。

将非拉丁字母如希腊字母和西里尔字母加粗，在技术上是可行的，但应当避免这么做。

b. Wikipedia:格式手册建议修改如下：

现行条文

（上略）

请您尽可能在首句带出文章所属的主题。如：

'''海森堡测不准原理'''，在[[量子物理学]]……

传记

历史上的概念如朝代、已不适用的地名等，应注明有效时间。人物则应提及出生（和死亡）的年月日。

这里有对于一般情况的概要：

'''孙中山'''（1866年11月12日－1925年3月12日）是中国近代民主革命家，民主先行者……
'''史提芬·威廉·霍金'''（{{lang-en|Stephen William Hawking}}，1942年1月8日－2018年3月14日），是英国著名[[物理学家]]……

提议条文

（上略）

请您尽可能在首句带出文章所属的主题。如：

'''海森堡测不准原理'''，在[[量子物理学]]……

外文粗体及斜体须依照Wikipedia:格式手册/文字格式的规定处理。

传记

历史上的概念如朝代、已不适用的地名等，应注明有效时间。人物则应提及出生（和死亡）的年月日。

这里有对于一般情况的概要：

'''孙中山'''（1866年11月12日－1925年3月12日）是中国近代民主革命家，民主先行者……
'''史提芬·威廉·霍金'''（{{lang-en|Stephen William Hawking}}，1942年1月8日－2018年3月14日），是英国著名[[物理学家]]……

c. Wikipedia:格式手册/传记建议（i）通过“非中文人名”部分为指引，并（ii）修改如下：

现行条文

格式手册的目的很简单：让格式整齐统一。以下规则并非金科玉律。许多种格式并无高下之分，但如果每人都遵循同一格式，维基百科将更为易读易用，当然也更易撰写编辑。

（略）

非中文人名

非中文人名应标出其本语言名字的拼写。外文名是否应使用粗体格式目前没有共识，以下两种样式都有使用。

温斯顿·伦纳德·斯宾塞·丘吉尔爵士（英语：Sir Winston Leonard Spencer Churchill，1874年11月30日－1965年1月24日），英国首相，政治家、演说家，被认为是20世纪最重要的政治领袖之一，带领英国获得第二次世界大战的胜利。
奥利维尔爵士夫人费雯·丽（英语：Vivien Leigh, Lady Olivier，1913年11月5日－1967年7月8日），英国国宝级电影演员，她获得奥斯卡最佳女主角奖两次提名，两次都得奖，分别是第12届的《乱世佳人》和第23届的《欲望号街车》。

提议条文

格式手册的目的很简单：让格式整齐统一。许多种格式并无高下之分，但如果每人都遵循同一格式，维基百科将更为易读易用，当然也更易撰写编辑。

（略）

非中文人名

非中文人名应标出其本语言名字的拼写。根据Wikipedia:格式手册/文字格式规定，除非该本语言名字出现在条目定义句中，并且是其在中文维基百科所属条目的现行名称或其未有中文版本的常用别名在中文环境中的最常用版本，否则不可为该本语言名字加粗。样式如下：

奥利维尔爵士夫人费雯·丽（英语：Vivien Leigh, Lady Olivier，1913年11月5日－1967年7月8日），英国国宝级电影演员，她获得奥斯卡最佳女主角奖两次提名，两次都得奖，分别是第12届的《乱世佳人》和第23届的《欲望号街车》。

d. Wikipedia:格式手册/序言章节#外语名称建议（i）通过为指引，并（ii）修改如下：

现行条文
外语名称

快捷方式： WP:MOSFORLANG

如果条目主题名称是以非中文为较大关联，那么与其同义的外文名称可以出现于导言里，并通常被括号包住。举例说，一篇讲述关于非中文语言的地方条目会把该地的本土语言所用的名称写进去：

切尔诺夫策州（乌克兰语：Чернівецька область, Chernivets’ka oblast’）是乌克兰西南部的一个州……

如果多于一个外语名称需要展示，那么在导言里把它们放在独立的句子，或者在主体正文增设一个诸如“名称”的章称，而不要写在开首的句子里。也不要把仅仅作为展示词源的外文名称写进导言内。

请勿加粗不常直接于中文语境使用的外语名称。另有一些外文用语需以斜体表示，使用时机请见Wikipedia:格式手册/文字格式#斜体。

提议条文
外语名称

快捷方式： WP:MOSFORLANG

如果条目主题名称是以非中文为较大关联，那么与其同义的外文名称可以出现于导言里，并通常被括号包住。举例说，一篇讲述关于非中文语言的地方条目会把该地的本土语言所用的名称写进去：

切尔诺夫策州（乌克兰语：Чернівецька область, Chernivets’ka oblast’）是乌克兰西南部的一个州……

如果多于一个外语名称需要展示，那么在导言里把它们放在独立的句子，或者在主体正文增设一个诸如“名称”的章称，而不要写在开首的句子里。也不要把仅仅作为展示词源的外文名称写进导言内。

外文用语的粗体和斜体的使用须遵照Wikipedia:格式手册/文字格式处理。

以上为本人建议的指引新增及修订。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月22日 (一) 13:23 (UTC)

@Ericliu1912、Clithering、Cdip150、YFdyh000：以上各提案并不捆绑，各位可以为各提案【即a、b、ci、cii、di和dii】分别给予意见。Σανμοσα ^{y=0 regardless the value of x} 2019年4月22日 (一) 14:23 (UTC)
- WP:格式手册/序言章节#外语名称不应删除 Chernivets’ka oblast’，能否列出罗马化字并非今次讨论的范围，请勿僭越。--街燈電箱150號开箱维修抄表检验证明 2019年4月22日 (一) 14:46 (UTC)
  - User:Cdip150请阅WP:ITALIC。Σανμοσα ^{y=0 regardless the value of x} 2019年4月22日 (一) 14:57 (UTC)
    - 即使如此，顶多只可取消斜体，但不能整个字删除。--街燈電箱150號开箱维修抄表检验证明 2019年4月22日 (一) 15:11 (UTC)
      - 完成。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月23日 (二) 00:16 (UTC)
(！)意见 a: 不懂为何这么做，其他条目的正文中也加粗，只因它有一个条目？应该是加内链吧。“属于非人名的常用简称／缩略写法”同上，PVC（等等）吗。第二句“除非该外文是中文维基百科中所属条目的名称，否则任何人不得撤销移除外文加粗的编辑。”很绕，是不能回退“取消加粗”的编辑吧，既如此强硬，为何要鼓励/可根据...予以加粗。b: 先解决A的问题。c: “本语言”很难懂，我想改掉，~~母语行么。建议“除非其母语名称是中文维基百科现行条目的名称，否则不可为该名字加粗”。有点瑕疵是，条目/现行条目可能是无关的同名条目。~~“除非其外文名称是其在中文维基百科的条目的现行名称，否则不可为该名字加粗”如何。d: 暂无意见。--YFdyh000（留言） 2019年4月23日 (二) 02:40 (UTC)
- User:YFdyh000a：条文已修改，现在的意思大概是“Facebook”只能在Facebook条目内加粗。PVC确实是其中一种例子，上面提及过的DSi也是一例。确实是不能回退取消外文加粗的编辑，因为外文加粗是不必要的（除非该外文在中文环境中已被人如同中文般使用，例如Facebook、Windows）。c：条文的问题大致上和a一样；已修改，效果和a差不多。Σανμοσα ^{y=0 regardless the value of x} 2019年4月23日 (二) 04:40 (UTC)
  - 好多了。“...在对应外文完整称呼中的字母...”仔细看才懂，希望进一步简化、阐明或举例，比如说“外文全称的缩略写法字母不应单独加粗”。格式手册是指引，“任何人不得撤销”语气偏硬，效力不该那么强，“不得”都应该是“不应”。对当前草案仍有疑虑，一般来说，非序言中很少用加粗吧，当前条文似乎未做限定。--YFdyh000（留言） 2019年4月23日 (二) 07:11 (UTC)
    - User:YFdyh000完成。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月23日 (二) 08:37 (UTC)

本主题全部或部分段落文字，已移动至#外文全称的缩略写法字母是否应该单独加粗。执行人：Σαν μο σα ^{y=0 regardless the value of x} 2019年4月28日 (日) 13:28 (UTC)。

现将以上修订公示七日。Σανμοσα ^{y=0 regardless the value of x} 2019年4月27日 (六) 06:49 (UTC)
- (－)反对，条文讨论时间过少（一周都没有），难以确保共识，况且上面已经有一个异议出了来正深入讨论中，现在公示根本不是时候。--街燈電箱150號开箱维修抄表检验证明 2019年4月27日 (六) 10:52 (UTC)
  - 现告暂时停止公示。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月28日 (日) 10:29 (UTC)

外文全称的缩略写法字母是否应该单独加粗

本主题或以下段落文字，移动自#建议修订。执行人：Σαν μο σα ^{y=0 regardless the value of x} 2019年4月28日 (日) 13:28 (UTC)。

以下是我的综合意见：

(－)反对“Hyper Text Transfer Protocol”这种单字母加粗的显示。
关于(b)例出的例子，建议顺道把“lang|en”模版改为事实上更常用的“lang-en”模版。同时，生卒日期应嵌入“bd”模版。“是中国近代民主革命家”和“是英国著名物理学家”应去除赘言，分别改成“，中国近代民主革命家”和“，英国物理学家”。另外，应参考社群当年投票，在霍金姓名后加入勋衔。
关于(c)的例子，一个是外语人名，另一个是汉化人名，两个例子均应保留。

谢谢。--Clithering（MMXIX） 2019年4月25日 (四) 15:44 (UTC)

- @Clithering：c那部分阁下错重点了，重点只在外语粗体，外语人名是否汉化并非重点；既然样式统一，则只留一例更宜。b那部分届时可直接事实性修订。Σανμοσα ^{y=0 regardless the value of x} 2019年4月26日 (五) 10:44 (UTC)
  - - 谢谢你的回应，我当初认为两个例子都应该保留，是因为一个例子是汉化译名，另一个不是；而一个有爵位，另一个没有。两个例子并存，可让读者知道不同情况下的外文所有部分皆无需加粗。不过，我察觉到现在“费雯丽”的例子好像改了，但改得不太合适。其一：她的头衔是“奥利花爵士夫人”，不是“奥利花男爵夫人”；其二：根据社群共识，名称应作“奥利花爵士夫人费雯丽”，而不是把爵位置于名称之后。同时，“费雯丽”另一译名是“慧云李”；“奥利花”另一译名是“奥立维耶”。如是观之，“费雯丽”这个例子过于复杂，不应采用。如要引用一个较简明直接的汉化译名例子显示外文姓名无需加粗，我建议可用魏璐诗。--Clithering（MMXIX） 2019年4月29日 (一) 15:27 (UTC)
      - “费雯·丽”这个例子其实是典型外地相关条目的一例，通常外地相关条目都必定会应用{{noteTA}}，所以我不认为此例太复杂。语序方面已经修正。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月30日 (二) 11:10 (UTC)
        (：)回应，主要问题已修正，现况尚可接受。--Clithering（MMXIX） 2019年4月30日 (二) 11:15 (UTC)
  - 补充：指引页面不能用{{bd}}，否则会造成错误分类。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月27日 (六) 07:27 (UTC)

我非常(＋)支持“Hyper Text Transfer Protocol”这种单字母加粗的显示，但应该在之后有表述缩写“HTTP”，这样很容易辨别一个缩写是如何缩的（并不是所有的缩写都是取首字母或每个单词的首字母）--百無一用是書生 (☎) 2019年4月26日 (五) 03:06 (UTC)

(：)回应，把“Hypertext”单词硬分拆成“Hyper Text”，分明就是矫枉过正。再者，环顾其他语文版本的维基百科，也不见有类似需要和安排。按照外文粗体如此有用的说法，岂不是回归基本赞成全面的外文粗体？又应否连中文也要显示为“联合国安全理事会”？--Clithering（MMXIX） 2019年4月26日 (五) 05:06 (UTC)

我认为这种标注一来不太美观（有点眼花，网页亲和力也不佳），二来很容易原创研究——绝大多数都没有脚注印证缩写法，可能不少是第一印象标注，有些还有争议或谬误。而如果有来源具体讲过缩写法，那就值得写入正文章节。--YF dyh000（留言） 2019年4月26日 (五) 14:39 (UTC)

不知道书生对以上留言有没有进一步回应？至于街灯与Ericliu1912对于外文全称的缩略写法字母是否应该单独加粗的看法，依照上方的讨论的立场分别是中立与否定，不过也想问问有没有进一步解释？Σανμοσα ^{y=0 regardless the value of x} 2019年4月28日 (日) 13:28 (UTC)
- 正反两方的意见都不无道理，我想等至少一周再听取他们更多的意见后再行评估是否改变立场。--街燈電箱150號开箱维修抄表检验证明 2019年4月29日 (一) 01:57 (UTC)
  - 我会倾向允许讨论至少五日，如果五日后未有任何其他支持外文全称缩略写法字母单独加粗的意见的话，我就会结束讨论，因为以我所见，大部分人都对于外文加粗较为反感。不过如果有其他支持外文全称缩略写法字母单独加粗的意见，讨论则会延长。Σαν μο σα ^{y=0 regardless the value of x} 2019年4月29日 (一) 09:08 (UTC)
(－)反对理由：“བཀྲ་ཤིས་བདེ་ལེགས་”对比不加粗：“བཀྲ་ཤིས་བདེ་ལེགས་”。--173.68.165.114（留言） 2019年4月29日 (一) 07:24 (UTC)
- 又如：“حركة المقاومة الاسلامية‎”对比不加粗：“حركة المقاومة الاسلامية‎”。--173.68.165.114（留言） 2019年4月29日 (一) 07:28 (UTC)
(＋)支持：我不觉得“Hyper Text Transfer Protocol”有问题，我认为很美观，而且清楚辨识，但是为了避免原创研究应该要求附加来源证明。--Opky9407（留言） 2019年5月1日 (三) 19:40 (UTC)
- User:Opky9407那IP举出的加粗例子如何？（假设有来源）Σανμοσα ^{y=0 regardless the value of x} 2019年5月2日 (四) 08:30 (UTC)
  - 很多外文已加粗就排版错乱了（甚至更惨，像阿拉伯文那样，完全不可读），但是如果只给英文加粗就破坏了中立性原则。--173.68.165.114（留言） 2019年5月4日 (六) 03:20 (UTC)
  - 当然这种情况一般不会出现（中文中唯一像HTML那样穿插阿拉伯文作为常用名称使用的几乎祗有“حلال‎”一词，而这不是个简称），藏文中简称一般不会采用首字母模式，但是还是要防患于未然——除非针对针对每个Unicode区块都验证一遍这类现象不会发生，才可以放心地把缩写加粗写入。--173.68.165.114（留言） 2019年5月4日 (六) 03:26 (UTC)
    - 既然这种简称很罕有的话，就不用考虑，如果真的出现的话可以当例外处理。--Opky9407（留言） 2019年5月6日 (一) 13:37 (UTC)
      - IP所提出的“只给英文加粗就破坏了中立性原则”问题还是没有解决，而且要立下例外还需要经过共识。Σαν μο σα^{五四运动百周年} 2019年5月7日 (二) 09:26 (UTC)

恢复公示

由于支持外文全称缩略写法字母单独加粗者在被要求回应的三日后仍没有回应，现恢复公示，自此刻起为时七日。Σαν μο σα^{五四运动百周年} 2019年5月6日 (一) 10:28 (UTC)

(－)反对：Wikipedia:格式手册/传记里包含了外文粗体之外的其它内容，我们这里只在针对粗体讨论，其它的部分没有讨论，所以不能整个作为指引。--Opky9407（留言） 2019年5月6日 (一) 13:45 (UTC)
- 已收窄c部的建议通过范围（修改范围不影响）。Σαν μο σα^{五四运动百周年} 2019年5月7日 (二) 09:23 (UTC)
由于提议修订的主要部分（a部分）出现变化，现重新公示七日。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月11日 (六) 10:36 (UTC)
翻了半天不知道公示的到底是什么内容？--百無一用是書生 (☎) 2019年5月14日 (二) 02:23 (UTC)
- “建议修订”节下列的a、b、c、d四部分。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月15日 (三) 00:09 (UTC)
(－)反对d部分，重新评估过后，Wikipedia:格式手册/序言章节#外语名称也是包含了外文粗体之外的其它内容，所以整节也不能做分段指引，再者，那些罗马斜体应该没有违反Wikipedia:格式手册/文字格式#不要用斜体来作强调，所以也不应取消，故只能改d部分的最后一段，且毋须成为指引。--街燈電箱150號开箱维修抄表检验证明 2019年5月17日 (五) 14:25 (UTC)
- 恢复斜体方面接受，其他不接受。Wikipedia:格式手册/文字格式本来就已有针对斜体的规限，而该节其余内容皆未违逆Wikipedia:格式手册#条目定义句，通过符合且大意上重复既有指引的条文本无不可，以此反对此部分通过必定导致有人会以非方针指引反对执行指引（例如这次我提出修例就是因为Clithering以现时非方针指引的Wikipedia:格式手册/传记反对执行Wikipedia:格式手册中去粗体的规定），通过之为指引是为了强化既有指引的有效性（例如此修订就是为了强化Wikipedia:格式手册中去粗体的规定的有效性）。老实说，即使那一部分我不通过为指引，因为那部分并非社群共识，所以我其实可以随意修改内容（我改得面目全非也可以），最终我还是能够达到修订的目的。User:Cdip150Σανμοσα^{以有涯随无涯，殆已！} 2019年5月18日 (六) 02:30 (UTC)
  - d部分的其他内容不是关于粗体，故已掉出本讨论，自然其他内容会在无共识下成为指引。再者，您要令外文粗体的规则能被有效执行，那其实只需要修改a和b部分就足以达成（c部分是否适当我还在疑惑中），反对者至少不可能因为d部分不是指引而阻止消粗。的确，应该做的是a和b部分通过更改后，d部分的确可免讨论改最后一段。（还有Wikipedia:格式手册原有的规条根本没有明文禁止外文粗体，没有列举外文粗体例子并不代表不可用粗，所以拿Clithering的情况来说并不适当）--街燈電箱150號开箱维修抄表检验证明 2019年5月18日 (六) 08:08 (UTC)
    - 我可以暂缓c、d两部分的通过。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月18日 (六) 10:31 (UTC)
(？)疑问：a部分的规定跟直接禁止第2类做法有什么差别？只要移除了便不能撤销，即NDSi是可以的，但被改为NDSi便不可改回粗体，这个完全是矛盾的规条，所以(－)反对。--Opky9407（留言） 2019年5月18日 (六) 10:10 (UTC)
- User:Opky9407我在上面也强调过了：一般而言，外文粗体是不被鼓励的，所以才订了如此的规则。最理想的情况下是尽可能避免外文粗体，1和3就是不可避免的情况；社群对于外文加粗的普遍态度是颇为负面的。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月18日 (六) 10:31 (UTC)
- 我就此点再作出较为详细的说明：我之所以会设定这样的规则，目的就是为了最终达到直接禁止二类粗体，但为了避免社群以后一看到二类粗体就急于移除，我设定了这样的规则，这样大家看到二类粗体也不用太在意，喜欢移除就移除，喜欢保留就保留，但移除了就不要再加粗。长久下去，当到了一定的时候，就可以改为直接禁止。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月20日 (一) 10:36 (UTC)
第2点上面的共识根本是同意加粗简写，允许移除是明显违反共识的。--Opky9407（留言） 2019年5月21日 (二) 09:32 (UTC)
- User:Opky9407但其他人对于移除之并没有提出异议，可以认为这得到了沉默共识许可，所以并不违反共识。对不起，由于你的编辑造成了编辑冲突，我会把你的留言置于archive bottom外。Σανμοσα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 09:36 (UTC)
  - 这当然违反共识，允许某做法自然不同意允许移除。--Opky9407（留言） 2019年5月21日 (二) 09:42 (UTC)
    - 对不起，两者并没有必然的因果关系。允许粗体并不代表不允许移除，只允许粗体才是。基于该用户的逻辑能力不能使人信服，我决定不接受该用户的意见。Σανμοσα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 09:47 (UTC)
      - 效果上当然有关系，允许粗体就应同时允许恢复粗体，不允许恢复粗体和允许粗体明显有冲突。--Opky9407（留言） 2019年5月21日 (二) 09:51 (UTC)
        Opky9407“搬龙门”了。我们起初是谈共识，现在突然改为谈效果，究竟阁下想谈些什么？Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 09:58 (UTC)
        
        “允许粗体”是“允许暂时保留现有粗体”，但最终目标仍是“减少、杜绝粗体”。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 09:58 (UTC)
    - 上面YFdyh000曾经对允许移除但不允许恢复二类粗体向我提出了疑问，而他最终接受了我的解释。至于其他人在看了整个条文也从来没对于我这一点有任何疑问或异议，那就代表他们接受这个做法。Σανμοσα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 09:58 (UTC)
      - 共识和效果都一起说，根本看不到共识是暂时允许，我理解是永远允许，根本没有人对简写粗体反感。--Opky9407（留言） 2019年5月21日 (二) 10:15 (UTC)
        User:Opky9407如果你打算共识和效果都一起说的话，我希望你可以把这两部分分开处理，否则我不认为我能够和你有有效的沟通。另外，共识方面的问题已在下方处理，我认为你至少不会反对后备方案。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 10:26 (UTC)
我对于Opky9407执意曲解共识并强行阻止新指引通过的行径深表遗憾。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 09:59 (UTC)
@Clithering、Ericliu1912、YFdyh000：我要求三位协助判断我所解读的共识是否正确。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 10:05 (UTC)
我重开了讨论，首先是当有人在关闭前提出异议，无论如何都应该继续讨论让人评估合理性，而不是自认为其不合理而强迫结束通过。二来是上面有人提到公示的内容混乱，应当重新整理修改内容的最终型态重新公示。--街燈電箱150號开箱维修抄表检验证明 2019年5月21日 (二) 10:07 (UTC)
- 反对说法2。我认为目前的公示形态非常清楚；任何人找不到章节的话，我可以和他说在哪一个位置（其实也只有一个位置而已）。Σανμοσα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 10:21 (UTC)
  - “翻了半天不知道公示的到底是什么内容？”您解答之后又因为后续讨论取消了一部分，各个改变主意的动作如此分散，当然应该再把修改内容再公示一次让大家更清楚易懂吧！--街燈電箱150號开箱维修抄表检验证明 2019年5月21日 (二) 10:28 (UTC)
    - User:Cdip150事实上我并没有取消任何一部分，我仍然是提议把c、d两部分的相关部分的修订，我只是不再要求把c、d两部分的相关部分作为指引（这也意味着把c、d两部分的相关部分的修订并不需要共识）。我可以重新张贴公示内容，但我会视之为延长公示期，而不是重新进行公示。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 10:35 (UTC)
- 针对说法1，如果Cdip150也希望就我是否正确解释讨论共识这个议题发表意见的话，我也欢迎阁下就此发表意见。如果其他人多数也认为我正确地解释了共识的话，我会再自行以通过结案；但我其实也有不禁止恢复二类粗体的后备方案，如果社群认为他们的意见是不禁止恢复二类粗体的话，我就会改为通过后备方案，因为其他部分并无人提出异议（注：我不会通过ci、di部分）。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 10:21 (UTC)
- @Sanmosa：“仍不应被撤销”就“指引”效力和自由编辑来说，是过强了一些，且单方面、理由不充分地限制。且我想了好久才明白它想表达什么，如果“属于非人名的常用简称／缩略写法”（如KFC、FBI）通常不应、不必要或可选加粗，建议明确约束（如“广泛使用、代用”）或者不要约束（如“也可不加粗以利版面整洁”）。该第二类是否该加粗，我也没想好，不加粗美观些，加粗也许对SEO和机器人维护（至少“ToolsRedirect”工具…）有些好处。--YFdyh000（留言） 2019年5月21日 (二) 10:29 (UTC)
  - User:YFdyh000请问我是否可以把你的意见视为中立偏后备方案？Σανμοσα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 10:49 (UTC)
    - 是的，可以。--YF dyh000（留言） 2019年5月21日 (二) 10:55 (UTC)
- 我希望Cdip150能够就原方案和后备方案孰优孰劣发表一下意见。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 10:41 (UTC)
如果三日后未有其他意见的话，我会通过后备方案。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 23:10 (UTC)
我支持后备方案。第二类粗体的设置不应是单向不可逆的，否则一开始就明文禁止还更好一些勒。—— Eric Liu _{坐等万次编辑（留言．留名．学生会）} 2019年5月22日 (三) 00:32 (UTC
我比较(＋)支持后备方案，我先不评论上面的共识争议，我是突然想到原方案会产生一个问题：如果简写是中外文混合而成的话，例如：“日本职业足球联赛（Japan Professional Football League），简称J联赛”，允许移除那部分的外文粗体的话可能会造就“J联赛”的奇怪做法，所以后备方案会较稳妥。不过还是应该从公示中完全移除该条文，后再等七天无异议后通过，三天可能太快。--街燈電箱150號开箱维修抄表检验证明 2019年5月22日 (三) 17:51 (UTC)
- User:Cdip150不，外文是否加粗的问题已困扰社群已久，应快刀斩乱麻。另外，条文的本意是只限制纯外文，“J联赛”之类不是规管范围（因为“J”本身不构成联赛简称；整个“J联赛”去粗体的话，“联赛”并非外文，按现行WP:MOSBOLD：“粗体通常用在一个条目的第一段，并用合适的名称和常用术语作为条目的题目，包括任何同义词和简称”，移除“联赛”的粗体也不合理），上面的例子发生的机会不大；我相信以上解释能使条文通过后为外文去粗体的适用范围更清楚，也避免了我不欲看到的滥去粗体的情形（当然，我也可以事实性修订条文的“外文”为“纯外文”）。Σανμοσα 2019年5月23日 (四) 11:45 (UTC)
  - “快刀斩乱麻”，不行，修订政策从不考虑问题存在的时长，只考虑共识是否已达成。而从上面的讨论看来，第2类的移除在我而言很难说得上有共识，所以有关纯外文粗体的详细修订应留待日后再议。另由于后备方案的共识暂时较为明显，还是先从公示中移除有关条文，待七天无异议才视为共识确认。--街燈電箱150號开箱维修抄表检验证明 2019年5月24日 (五) 06:39 (UTC)
    - User:Cdip150由于未有人反对二类粗体去加粗以外的条文，我认为现在已可直接通过a、b两部（a部从后备方案），这点我不认为应该拘泥于程序内（而且公示七日只是惯例，而非方针指引规定）。Σαν μο σα 2019年5月24日 (五) 10:13 (UTC)

（请继续在横线上方讨论）

以下重新张贴公示内容：（c、d之修订已完成，但不作为指引）

a. Wikipedia:格式手册/文字格式建议修改如下：

现行条文

将非拉丁字母如希腊字母和西里尔字母加粗，在技术上是可行的，但应当避免这么做。

提议条文
外文粗体

如果一个外文出现在条目定义句中，并且符合以下至少任何一种情形：

是中文维基百科中所属条目的名称；
在中文环境中属于非人名的常用简称／缩略写法；
属于未有中文版本的常用人物别名在中文环境中的最常用版本；

则该名称可根据Wikipedia:格式手册#条目定义句规定予以加粗，否则该外文不应加粗。外文全称的缩略写法字母不应单独加粗。

不过，即使该外文符合上述规定可予以加粗，移除第二类外文加粗的编辑仍不应被撤销。（后备方案不存在此句）

将非拉丁字母如希腊字母和西里尔字母加粗，在技术上是可行的，但应当避免这么做。

b. Wikipedia:格式手册建议修改如下：

现行条文

（上略）

请您尽可能在首句带出文章所属的主题。如：

'''海森堡测不准原理'''，在[[量子物理学]]……

传记

历史上的概念如朝代、已不适用的地名等，应注明有效时间。人物则应提及出生（和死亡）的年月日。

这里有对于一般情况的概要：

'''孙中山'''（1866年11月12日－1925年3月12日）是中国近代民主革命家，民主先行者……
'''史提芬·威廉·霍金'''（{{lang-en|Stephen William Hawking}}，1942年1月8日－2018年3月14日），是英国著名[[物理学家]]……

提议条文

（上略）

请您尽可能在首句带出文章所属的主题。如：

'''海森堡测不准原理'''，在[[量子物理学]]……

外文粗体及斜体须依照Wikipedia:格式手册/文字格式的规定处理。

传记

历史上的概念如朝代、已不适用的地名等，应注明有效时间。人物则应提及出生（和死亡）的年月日。

这里有对于一般情况的概要：

'''孙中山'''（1866年11月12日－1925年3月12日）是中国近代民主革命家，民主先行者……
'''史提芬·威廉·霍金'''（{{lang-en|Stephen William Hawking}}，1942年1月8日－2018年3月14日），是英国著名[[物理学家]]……

以上。Σαν μο σα^{以有涯随无涯，殆已！} 2019年5月21日 (二) 10:38 (UTC)

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

建议修订

原文使用芝加哥格式手册作为例子阐述观点

但是这本书对于绝大数中文读者而言并不熟悉

建议改为其他更加为人熟知的例子--冷罗KS用户:KSroido 2019年8月20日 (二) 13:15 (UTC)

关于对大中华地区行政区划类、地名类条目加注非汉语文字及汉语罗马化方案的方法作正式规范的建议

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

自今年7月有用户质疑广州市条目中英语名称Guangzhou及Canton之注明方式的合理性，逐渐演化为中国行政区划条目是否及如何加注非汉语及汉语罗马化的问题的大讨论，并且初步拿出了一些方案，现正在进行投票。在此基础上，我个人有一些新的想法和（可能也会有）疑问，在此列明，做出建议。

外语及汉语罗马化方案在首段标注的标准：建议划一为“官方语言”/“官方语言及当地通用语言”（视投票结果为准）。例如：
- 中国内地吉林省延边朝鲜族自治州，官方语言为汉语官话（普通话）、朝鲜语（中国朝鲜语），当地通用语言为汉语官话（东北话）；
- 中国内地广东省广州市，官方语言为汉语官话（普通话），当地通用语言为粤语；
- 台湾地区台北市，官方语言为汉语官话（国语）、闽南语（台语）、客语（此处稍有疑问，还望能解惑）；
- 台湾地区高雄市那玛夏区，官方语言为汉语官话（国语）、闽南语（台语）、客语，当地通用语言为卡那卡那富语、布农语（这两个没有任何疑问，有来源）。
在地名信息框内，个人不建议放任何非汉字语言。下面加置一个Infobox Chinese信息框，内容为官方语言及当地通用语言。
官方语言及当地通用语言为汉语族各语言、语言方言的，注明时用标准罗马化方案，且宜只用一种。汉语官话现在内地、台湾都选用汉语拼音为标准罗马化方案，所以建议如果要标注汉语官话的罗马字，只标汉语拼音。
词源外语的问题，例：
- 中国内地吉林省吉林市，词源为满语；
- 台湾地区高雄市，词源为日语。
对于上述词源不是现用官方语言及当地通用语言的情况，建议亦在Infobox Chinese信息框中注明该语言，同时在首段以后单开一章节，介绍地名词源。
其他外语的问题。建议如无特殊情况，地名外语名应一律按各地区的标准转写法来，故其他外语一律不出现在中文维基百科，那是维基数据的任务。特殊情况包括：
- 有一个官方外语名称，此外有一或多个常用的其他外语名称的，如中国内地广东省广州市，按官方标准，英文为Guangzhou，而Canton亦较流行；
- 官方允许的例外情况，如中国内地黑龙江省哈尔滨市，按官方标准，英文为Harbin（非Haerbin），这是官方声明的特例。
适用范围问题：建议扩大到整个大中华地区，包括香港、澳门、台湾地区的地名（但由于港澳的特殊状态，故主要针对的是中国内地和台湾地区）；不仅仅是行政区划，其他地名，如中山路之类，似乎也可以按此进行。

以上是个人的愚见，还望先进赐教。附知@H2NCH2COOH、Longway22、SCP-2000、Milkypine、和平至上、@Viztor、Huangsijun17、KirkLU、Hamish、OuiOK、@Baomi、UjuiUjuMandan、Sanmosa、Ericliu1912、游蛇脱壳、@Jacky Cheung、WQL、⼥⼉、Rowingbohe、行到水穷处、@AT、StreetDeck、YFdyh000、Classy Melissa、TimWu007并一并附知未参与讨论串的地区类条目主要编者@瑞丽江的河水、Ngguls、Theodore Xu、A635683851。--BoyuZhang1998（留言） 2019年10月25日 (五) 05:30 (UTC)

支持仅标出“官方语言及当地通用语言”，如伊犁哈萨克自治州应标出哈萨克语及维吾尔语。中文地区文字相同而仅发音不同的不予考虑，属于闽粤方言等较为特色的方言的可加{{Infobox Chinese}}信息框--苞米(☎)💴 2019年10月25日 (五) 05:53 (UTC)
广州条目投票完成前，先不要展开讨论。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年10月25日 (五) 06:37 (UTC)
正文内括注的话，只应标出当地的官方语言或者中国大陆民族地方所谓的政府工作语言（依各地自治条例所定）。任何拼音、转写、其他通用语言都应放到infobox Chinese里。一直觉得目前新疆西藏地区的条目开篇第一句很长一个括号不好看。--河水|滇 2019年10月25日 (五) 09:13 (UTC)
上面有两个用户名写错了。@克勞棣、Streetdeck：再ping一次。--春卷柯南编辑数突破二万 ( 论功行赏·刻石留名 ) 2019年10月25日 (五) 10:49 (UTC)

为免影响广州条目投票，先close掉上面的讨论，完了可以重开。San mo sa _{灾难固首发于荃湾} 2019年10月25日 (五) 14:51 (UTC)

广州条目投票已结束，现重开讨论。San mo sa _{灾难固首发于荃湾} 2019年11月8日 (五) 04:52 (UTC)

说明：该投票大致上同意不在中国大陆地方的条目列出外文（如果某地为民族自治地方或属于某民族自治地方，相关民族自治地方的民族所使用的语文的名称不视为此建议中的投票所指的外语，有如新疆维吾尔自治区及其下辖政区的维吾尔语名、延边朝鲜族自治州及其下辖政区的中国朝鲜语名等）及其他汉语拼音，惟其中有一定意见认为可列出邮政式拼音，故在此对BoyuZhang1998提案提出以下修正：

方案仅适用于中国大陆地方的条目；
所有拼音归入Infobox Chinese处理；
特殊外文同上，除非其为邮政式拼音；
邮政式拼音允许置于条目导言，惟须有来源证明；

以上。我个人不太想动台湾地方的条目，故不建议台湾地方的条目适用；港澳地方的条目没什么可以动的。San mo sa _{灾难固首发于荃湾} 2019年11月8日 (五) 05:09 (UTC)

我不知道对中国大陆做这个特殊化规定的意义在哪里？如果是大中华地区，或许还有些意义--百無一用是書生 (☎) 2019年11月8日 (五) 07:25 (UTC)

因为港澳台地方的条目从来不会产生如此争议，那些维持现状即可。是中国大陆地方的条目大家才吵得那么僵。San mo sa _{灾难固首发于荃湾} 2019年11月8日 (五) 09:07 (UTC)

邮政式拼音应该是和标准语发音差异较大的可列出，否则不应列出。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年11月8日 (五) 14:36 (UTC)

“特殊外文”是指什么？有清楚的界定吗？--【和平至上】^{抗议暴徒破坏、还我安宁香港}💬📝 2019年11月8日 (五) 12:16 (UTC)
记得若引用之前一系列讨论中的部分意见看法，是包括台湾地方条目“放入日文都可能起争议”，譬如在首段写日语标注也被认为是不应该的，感觉这个方案既然是基于该系列论述而拟定，理应也起码回应题目，先尝试对等纳入其他大中华地区，以便本地联同检视。——约克客（留言） 2019年11月8日 (五) 14:00 (UTC)
- 本来也没必要列入日文名称。哪怕是高雄和民雄之类的日本人取的名字。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年11月8日 (五) 14:33 (UTC)
- 同上。另外，我是因为不太想制造类近统战的情况而建议仅适用于中国大陆地方的条目，台澎金马照样导言放置闽／台语即可；至于是否适用港澳地方的条目的分别不大。San mo sa _{灾难固首发于荃湾} 2019年11月9日 (六) 11:38 (UTC)
可是...其他大中华地区例如马来西亚和新加坡都拥有第二外语当作官方语言，更何况中文还不是马来西亚的官方语言，说到底其他大中华地区也就那几个而已，不同的状况根本不能一起讨论啊。 --无心*插柳*柳橙汁 2019年11月8日 (五) 14:14 (UTC)
- 照阁下原论述既有观点的话，当有台湾城市在首段被添加日文标注，而不编辑添加的理据，是否仍需要本地自定引入一套格式守则处理？BoyuZhang1998的原初方案，已经有一个分类检视的思路，于东南亚地域的，也是可以按照Boyu兄的路径，进一步细化先做模拟处理的也是未尝不可的。即使大陆范围内也是有不同的状况，若果有详尽参详一系列的论述，这个也是必要厘清的，于本地进一步检视各地域的范畴，相信也会有更多裨益。——约克客（留言） 2019年11月8日 (五) 14:41 (UTC)
  - 大中华地区应该是指狭义的大中华地区，即中国内地、港澳、台湾。--【和平至上】^{抗议暴徒破坏、还我安宁香港}💬📝 2019年11月9日 (六) 06:01 (UTC)
  - 我原先的观点为，台湾加注日文是因为其“历史脉络”的缘故才有那个条件，更何况当时我的意见是根本没有必要（对比香港、新加坡、高雄，广州绝对是最没有加入外文的必要，而高雄虽然其名称来自于日文，但台湾目前不采用日文为官方文字，目前高雄市的导言只是介绍该城市的名称来历。） --无心*插柳*柳橙汁 2019年11月10日 (日) 13:01 (UTC)
- 大中华地区应只限中国内地及港澳台，星马等地一般视为有既定中文名的非中文区处理。不过我仍然建议方案仅适用于中国大陆地方的条目。San mo sa _{灾难固首发于荃湾} 2019年11月9日 (六) 11:38 (UTC)
- (－)反对加入邮政式拼音，闽粤地区等汉语发音特殊的地区可以添加{{Infobox Chinese}}。汉语拼音在中国大陆有着比邮政式拼音更特殊的地位，没有理由不加汉语拼音，而加入邮政式拼音，所以仅支持首句不加入任何拼音，所有拼音可在正文介绍，或加入{{Infobox Chinese}}。--苞米(☎)💴 2019年11月10日 (日) 13:15 (UTC)
  - “汉语拼音在中国大陆有着比邮政式拼音更特殊的地位”，我要求证据证明此声称。Sanmosa _{灾难固首发于荃湾} 2019年11月12日 (二) 08:50 (UTC)
    - [9][10]具体来说是包含汉语和少数民族语言的汉语拼音字母具有更特殊的法定地位。在少数民族地区，使用汉语拼音字母拼写的少数民族语言比对应汉语音译的汉语拼音具有更强的法定地位。--146.96.147.137（留言） 2019年11月13日 (三) 02:06 (UTC)
    - @Sanmosa：另请参见《中国地名汉语拼音字母拼写规则（汉语地名部分）》。内蒙古翻译成“Nei Monggol”（既不是Nei Menggu也不是Obor Monggol）是有道理的。--146.96.147.137（留言） 2019年11月13日 (三) 02:11 (UTC)
首先高雄的语源和打狗一样都是土著语。其次只支持原著语言及原著方言的标注（如藏语、满语等）。中国大陆的并附上当地语言方言的汉语拼音字母转写，如藏语拼音、闽南拼音。这里不是英语维基百科，首段和信息框不需要添加“Canton”之类的邮政式拼音。--146.96.147.137（留言） 2019年11月13日 (三) 00:24 (UTC)

让大家讨论一下

我这里有两个对BoyuZhang1998提案的修正案，大家看看哪一个会比较好：

方案A（原修正案）：
- 方案仅适用于中国大陆地方的条目；
- 所有拼音归入Infobox Chinese处理；
- 特殊外文同上，除非其为邮政式拼音；
- 邮政式拼音允许置于条目导言，惟须有来源证明；
方案B：
- 方案仅适用于中国大陆地方的条目；
- 所有拼音（含邮政式拼音）归入Infobox Chinese处理；
- 特殊外文归入Infobox Chinese或其他适合放置外文的Infobox栏目处理；

以上。San mo sa _{灾难固首发于荃湾} 2019年11月13日 (三) 02:07 (UTC)

完全反对这两个方案。两个方案都没有尊重少数民族地区的民族区域自治规定的法定语言权利，前者还对中国语言地名的外语翻译（如邮政式拼音）感兴趣，是典型的不自重。--146.96.147.137（留言） 2019年11月13日 (三) 02:13 (UTC)
- IP是不是没看我的说明？或许我再复制一次说明吧：如果某地为民族自治地方或属于某民族自治地方，相关民族自治地方的民族所使用的语文的名称不视为外语（如新疆维吾尔自治区及其下辖政区的维吾尔语名、延边朝鲜族自治州及其下辖政区的中国朝鲜语名等）。San mo sa _{灾难固首发于荃湾} 2019年11月13日 (三) 02:16 (UTC)
- 换言之：芒市的傣纳语和景颇语名、乌鲁木齐的维吾尔语名、呼和浩特的蒙古语名，这些我通通也不想动。Sanmosa _{灾难固首发于荃湾} 2019年11月13日 (三) 02:21 (UTC)
  - 抱歉没仔细看，对不起。--146.96.147.137（留言） 2019年11月13日 (三) 02:24 (UTC)
    - 我的意思是目前少数民族语言的位置有的跑到了infobox照片底下，不够尊重，应当放到更显眼的位置。--146.96.147.137（留言） 2019年11月13日 (三) 02:25 (UTC)
方案C：
- 中国语言（yuyan）、方言（tonguage）和土语（dialect），归入首段和Infobox的明显位置处理：
  1. 该方言（也包含蒙古语方言、苗语方言等）或语言在当地分布广泛；
  2. 汉语地名的语源为该语言；
- 一切外文归入文章内容以及infobox的次要位置处理，以下情况例外：
  香港英语、澳门葡萄牙语、台湾西班牙语和荷兰语如为汉语地名语源，应比照中国语言处理。
- 对于以上列出的语言、方言和土语，在中国大陆且存在汉语拼音字母（包含汉藏维哈柯）或闽南拼音字母的，一并列出，其余可选择列IPA；港澳列出粤拼和疍家话IPA等；台湾列出南岛语拉丁名称、汉语拼音和其他方言（闽客）的通用拼音。

以上--146.96.147.137（留言） 2019年11月13日 (三) 02:24 (UTC)

我的个人意见是：如果某地为民族自治地方或属于某民族自治地方，相关民族自治地方的民族所使用的语文的名称不视为外语（如新疆维吾尔自治区及其下辖政区的维吾尔语名、延边朝鲜族自治州及其下辖政区的中国朝鲜语名等）之余，亦应置于条目导言；但非民族自治地方且不属于任何民族自治地方也加入的话，我有些忧虑方案C会造成原创研究风险，所以我要求如果要加入的话，须有来源证明且属于中国少数民族语言。还有一点就是：我仍然主张方案应仅适用于中国大陆地方的条目，以免制造类近统战的情况（统战尚未成功，深圳河以北、台湾海峡以西的同志们仍须努力，不过关闸以南已经一早成功了）。San mo sa _{灾难固首发于荃湾} 2019年11月13日 (三) 02:33 (UTC)

还有一个意见，就是列出IPA的必要不大，应视为可选择执行与否的措施。San mo sa _{灾难固首发于荃湾} 2019年11月13日 (三) 02:40 (UTC)

谢谢，目前的问题是原住民族的语言方言不受尊重（包括香港的疍家话），不用放大镜基本看不到。原创研究的问题首先只针对条目不针对标准，其次人口普查在那里，超过百分之多少就要加完全可以。而且没有标准就是谁想加就加想删就删；有“原创”标准其实降低了条目整体的原创度。目前维基百科“中国”引向“历史文化意义的中国”，同时两地闽南语使用了不同的方案，所以应该是没有“统战”的问题。--146.96.147.137（留言） 2019年11月13日 (三) 02:40 (UTC)

哈哈“统战”这个太幽默了。本来觉得可以把“广东拼音方案”也加上，不过那个方案实在太“官话”了，完全没有考虑粤语使用习惯，所以干脆客家话也不加了。--146.96.147.137（留言） 2019年11月13日 (三) 02:43 (UTC)

同意。--146.96.147.137（留言） 2019年11月13日 (三) 02:45 (UTC)

精简一下：我的意思是土著语言（如汉语、蒙古语、南岛语言）及其方言可以放在地名信息框内，四种外语（香港英语、澳门葡萄牙语、台湾西班牙语和荷兰语）如成为汉语词源同样对待。其他外语一律归入Infobox Chinese。罗马化可放在首段，使用各地官方标准，比如闽南语内地的使用闽南拼音，台湾的用台通拼音，没有官方标准的可以使用IPA，不使用具有宗教宣传性的教会罗马字（保证维基百科的信仰中立）。内满洲存在一些不属于既不符合《中国地名汉语拼音字母拼写规则（汉语地名部分）》也不符合《少数民族语地名汉语拼音字母音译转写法》的，比如Harbin、Jagdaqi同样接受。前面看到方案AB没有仔细看就发言，见谅。--146.96.147.137（留言） 2019年11月13日 (三) 08:10 (UTC)
我比较疑惑的是，中国大陆为何要区别对待？其特殊性在哪里？与其他国家/语言相比有何不同，从而必须要单独规定？--百無一用是書生 (☎) 2019年11月13日 (三) 08:33 (UTC)
- 命名没有区别对待啊，只是把中国语言整体区别对待，因为是中国的地理。如果是印度的信息框，就同样把印度语言区别对待优先加入信息框而不是外语。如果是玻利维亚的，就把玻利维亚本土语言区别对待。并没有单独规定中国的“特殊性”，更没有“中国大陆特殊性”啊（正相反还规定了两岸闽南语的不同拼音标准）。像这种提出的标准直接用“查找与替换”换个国名就可以做成世界上任何一个国家的信息框规则。--146.96.147.137（留言） 2019年11月13日 (三) 09:55 (UTC)

首段与信息框列出的方言民语

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2020年1月8日 (三) 08:14 (UTC)。

@AirScott：这里承接讨论“#法国地名翻译若干问题”的《§非法语名称》小节中⚓方言民语处的讨论。--146.96.147.137（留言） 2019年11月30日 (六) 06:27 (UTC)
@Sanmosa：这里承接“关于对大中华地区行政区划类、地名类条目加注非汉语文字及汉语罗马化方案的方法作正式规范的建议”处的讨论。--146.96.147.137（留言） 2019年11月30日 (六) 06:27 (UTC)

维基百科的很多台湾地名都在首段和信息框添加了方言民语，但当遇到中国大陆、法国等地城市遇到同样处理时，却遭到诸如“非官方语言”、“非双语区”的反对，中国大陆地区的民族语言甚至被挤进了信息框图片底下的小字。这种针对台湾地区的特殊化处理实质上是对台湾之外地区的多元文化的歧视，甚至有时能成为刷存在感的一种方式。因此，有必要一般性的对地方语言、民族语言加以大致规范。下面抛砖引玉先提几个方案：

方案一：完全按照官方语言处理：
比如南非有11种官方语言，首段和信息框列出11种；

比如玻利维亚有三十余种官方语言，首段和信息框列出三十余种；

比如“中华民国”有百余种官方语言，首段和信息框列出百余种；

比如“中华人民共和国”没有官方语言，首段和信息框不列出，尽管人民币上印着五种语言；
- 缺陷：不实际，一些刷存在感的地区可以添加上千种官方语言，最后谁吼的声音大谁的语言就能被列出。
方案二：不考虑“语言的官方地位”等形式上的称号，考察实际使用，凡一语言在该地区、聚落有两成人口使用，即可添加：
如佛罗伦萨不添加拉丁语；

如东帝汶、澳门不添加葡萄牙语；

如南平市作为聚落是官话区，不添加闽北语；

如嘉义市、嘉义县~~不添加~~（更正：不添加邹语）；

如里昂作为聚落是法语区，不添加法兰克-普罗旺斯语。
方案三：如下语言可以添加：
1. 该语言在该地区、聚落有两成人口使用的；
2. 该语言既是该地区具有某种实质的官方地位，可在日常生活中看到；
  - 比如汉蒙维藏壮五种语言之于“中华人民共和国”，每个人每天都能在自己使用的人民币上看到；
  - 比如葡萄牙语之于东帝汶、澳门；
  - 比如西班牙语、克丘亚语、艾马拉语、瓜拉尼语之于玻利维亚（主要针对瓜拉尼语，前三者已依照前一条添加）；
3. 该语言对当地具有重要历史、文化意义；
  比如拉丁语之于佛罗伦萨；
  
  比如闽北语之于南平；
  
  比如宣州吴语之于宣城；
  
  比如邹语之于玉山；
  
  比如葡萄牙语之于澳门；
  
  比如~~法兰克-普罗旺斯语~~（更正：古法兰克普罗旺斯语/古普罗旺斯语，二语文古语形式相同）之于格勒诺布尔。

如果有更好的方案，请在下方提出。--146.96.147.137（留言） 2019年11月30日 (六) 06:27 (UTC)

我的意见是：一、如果某地为中华人民共和国民族自治地方或属于某中华人民共和国民族自治地方，相关中华人民共和国民族自治地方的民族所使用的语文的名称（如新疆维吾尔自治区及其下辖政区的维吾尔语名、延边朝鲜族自治州及其下辖政区的中国朝鲜语名等）置于条目导言，台湾方面可以以原住民族地区比照民族自治地方、当地原住民族通行语比照民族自治地方的民族所使用的语文办理；二、如果某地非中华人民共和国民族自治地方且不属于任何中华人民共和国民族自治地方，相关方言／主要少数民族语言／外文名称在有来源证明其一定的常用性／重要性的情况下亦（可）置于条目导言；三、可以设置一个列表规定哪些地区的地方／行政区划条目可将哪些方言／少数民族语言／外文名称置于条目导言而免于列出来源。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{灾难固首发于荃湾} 2019年11月30日 (六) 06:56 (UTC)

汉语方言与法语方言怎么办？尤其是那种在现代标准汉语、标准法语中存在讹译谐音的。我的观点是：“母汤（闽南语：毋通）”、“比埃什地区圣朱利安（奥克语：Sant Julian de Buechaine）”这样进行。--146.96.147.137（留言） 2019年11月30日 (六) 07:08 (UTC)

另外语言的列出应当是免于来源请求的吧？或者说，默认将相应的“某汉词典”、“某英词典”、“某法词典”作为来源。不然的话，考虑到汉语维基里引用英文的量，足以吧整个汉语维基百科一般的条目用{{cn}}血洗一遍了。--146.96.147.137（留言） 2019年11月30日 (六) 07:13 (UTC)
- 语言的列出本身是免于来源请求，但如果语言的列入需有常用性／重要性证明的话，那时就需要来源，否则情况可以演化到比方案一更夸张的地步。ꓢꓯꓠꓟꓳꓢꓮ _{灾难固首发于荃湾} 2019年11月30日 (六) 07:20 (UTC)
  - @Sanmosa：还是有个一致性的指引比较好，不然要是单一地区刷存在感的话基本就是整个维基百科给一个地区做广告。--146.96.147.137（留言） 2019年11月30日 (六) 16:25 (UTC)
    - 有时候你必须要做那些广告，世界上没太多东西是可以各地完全一致的，再不然规定全部非本源语都要加上来源也可。ꓢꓯꓠꓟꓳꓢꓮ _{灾难固首发于荃湾} 2019年12月1日 (日) 01:36 (UTC)
      - @Sanmosa：要求所有地方都适用于一个绝对严格的一致标准不现实，但总体的指导方针还是要的，不能任由地域中心主义人士发展的太厉害。--160.39.224.247（留言） 2019年12月7日 (六) 04:02 (UTC)

我在上面有说明方言（包括但不限于汉语、中国少数民族语言，其实就是世界通用）地名的处理方式。至于地名以外的处理方式应该不属于讨论范畴，应该因时制宜处理（以“母汤”为例，其语源是闽南语的“毋通”，如果“母汤”有关注度，相关来源应该提及它的语源，那样在导言列举闽南语名就非常适合）。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{灾难固首发于荃湾} 2019年11月30日 (六) 07:20 (UTC)

@Sanmosa：我那个“母汤”只是个例子，说明讹译现象。阁下以为玉山怎么处理？按照阁下的方案似乎南岛语言要不保。另外，国外的语言怎么处理。--146.96.147.137（留言） 2019年11月30日 (六) 12:13 (UTC)
- 玉山的话可以看看这个：提及布农族圣山的布农族语文名称是没问题的；邹族语文名称方面，因为条目提及了“八通关”，理论上应该说明语源（而玉山也是邹族圣山）；卡那卡那富族和排湾族则暂无来源。外文也是方言那套处理方式（但香港的英文使用率真的很高，我有些想SNOW），如果是英文／其他外文为原文（例如King County, Washington, USA）则不属方言处理方式的范畴，且无须列明来源。ꓢꓯꓠꓟꓳꓢꓮ _{灾难固首发于荃湾} 2019年11月30日 (六) 12:31 (UTC)
  - 也就是说阁下愿意将“该语言对当地具有重要历史、文化意义”一条纳入考虑的？--146.96.147.137（留言） 2019年11月30日 (六) 13:11 (UTC)
    - 前提是有来源确定名称如此（就例如条目列的布农族语文名称就和我给的来源列的不一样）。ꓢꓯꓠꓟꓳꓢꓮ _{灾难固首发于荃湾} 2019年12月1日 (日) 01:36 (UTC)
      - 也就是说阁下原则上支持方案三，但是对方案三第三条要求严格的可靠来源，同时对方案三的第二条给出了在大中华区的给出了替代标准？--146.96.145.136（留言） 2019年12月3日 (二) 23:41 (UTC)
      - 如果阁下能够将方案三第二条的替代标准应用在世界范围内，就可以提出一个方案四了。--146.96.145.136（留言） 2019年12月3日 (二) 23:42 (UTC)

(＋)支持方案二用于法国--Patriotard 2019年11月30日 (六) 09:56 (UTC)
- 呃……话说澳门人装了几十年的蒜要把自己包装成正港的葡语区了，这样揭人老底真的好吗？说得诡异一点：共产党也努力把澳门包装成葡语区好不容易准备拿来用一下“统战”葡语国家，结果耕耘五十载，毁于维基。还是等等澳门人的反应吧。--146.96.147.137（留言） 2019年11月30日 (六) 12:09 (UTC)
  - 就法国本土而言，方案二没有什么问题。澳门不了解，若情况特殊可单独拿出来讨论--Patriotard 2019年11月30日 (六) 12:46 (UTC)
    - 如果给澳门特殊地位，那么就相当于偏向澳门歧视法国的澳门地域中心主义（除非有特别的理由说明澳门的特殊性并将其纳入标准）。葡语在澳门肯定比阿尔卑坦语在阿尔卑斯使用率少得多，只有3%人会说。--146.96.147.137（留言） 2019年11月30日 (六) 13:10 (UTC)
      - “葡语在澳门肯定比阿尔卑坦语在阿尔卑斯使用率少得多”：阿尔皮坦语总使用人数14万，除去意大利（7万）和瑞士（0.7万），法国境内仅剩不到7万，而法国阿尔卑斯地区总人口数量（伊泽尔省125.3万、萨瓦省43万、上萨瓦省80万、安省63.8万、德龙省50.8万、罗讷省183.6万、卢瓦尔省76.2万、外加上阿尔代什省东北部+阿尔卑斯普罗旺斯省北部+汝拉省南部约15万人）差不多有637万人，阿皮坦使用者数量不到1%，这还是1988年的数据--Patriotard 2019年11月30日 (六) 13:44 (UTC)
        你忘了排除里昂等大城市后这个总人口量直接折一半，然后法国境内的阿尔卑斯是一半的Arpetania一半的Occitania。所以最后在Arpetania的法国部分的农村地区FP语的L1 speaker得翻四倍。而澳门你画不出任何一个区域葡语人口显著的超出平均水平，而且前面的3%是包括L2 speaker的，L1要少得多。请注意阿尔卑斯坦尼亚有部分语境中是特指农村地区的。--146.96.147.137（留言） 2019年11月30日 (六) 13:52 (UTC)
        按照阁下标准，里昂也属于FP语区，而且作为中心城市，如果真的成立FP语的组织机构的话，它很有可能出现在里昂，况且里昂人口也就一百多万，远折不了一半。阿尔卑斯地区的奥克语区只有上普罗旺斯阿尔卑斯省南部和上普罗旺斯省，另有瓦尔省、沃克吕兹省和滨海阿尔卑斯省的零星区域，人口加起来不超过50万。法国行政上没有农村/城市这种划分，故“农村地区”没有一个具体的判断标准（里昂机场出来全是农田）。如果阁下认定阿尔卑斯地区现阶段通用FP语或者奥克语而不是法语，请提供相关资料--Patriotard 2019年11月30日 (六) 14:28 (UTC)
        我好像没说过“里昂属于FP语区”。里昂添加FP语的理由是“该语言对当地具有重要历史、文化意义”，类似于南平的闽北语。里昂是不可能“该语言既是该地区具有某种实质的官方地位，可在日常生活中看到”或“该语言在该地区、聚落有两成人口使用的”添加FP语的。同时我也未曾说要依照方案三的前两条将FP语加入整个Arpitania，这些臆想只是您的个人理解，没有必要扣我帽子。至于人口，Rhône-Alpes大区把（Lyon area : 2,188,759 inhabitants (2011) Grenoble area : 675,122 inhabitants (2011) Saint-Étienne area : 508,548 inhabitants (2011) Valence area : 175,095 inhabitants (2011)）一删就只剩一半人口了，里面Occitania目测有一半（看地图：oc:Grenòble就已经在边界线上了），虽然不可能达到20%的标准，但秒掉澳门葡语还是很轻松的。--146.96.147.137（留言） 2019年11月30日 (六) 14:34 (UTC)
        其它城市我不乱说，从语言地理学上看，圣艾蒂安及所在的整个卢瓦尔省都是名副其实的FP语区，但就我在那住过的几个月来说（包括Bourg Argental），FP语通行度为0，注意，不是极低，是0。所以还是那句话，如果阁下认定阿尔卑斯地区现阶段通用FP语或者奥克语而不是法语，请提供相关资料--Patriotard 2019年11月30日 (六) 15:01 (UTC)
        还是前面那个讨论里讲的：“当地人会讲”和“当地人会和你讲”是完全不同的概念，参见#田野。一个西伯利亚长相的人去澳门也会发现澳门葡语“通行度为零”，因为别人看到他就会假设他不可能会说，从而避免使用葡语。通行度虽低，但总比澳门葡语高。--146.96.147.137（留言） 2019年11月30日 (六) 15:11 (UTC)
        
        另外，题外话，圣艾蒂安首先是城市，其次连山都没进，还处于丘陵地带，可能真会是0。--146.96.147.137（留言） 2019年11月30日 (六) 15:17 (UTC)
        我大概就知道阁下会说这个。不好意思，我2014年第一次去圣艾蒂安踢球的时候就问过当地老板“你们说FP语吗”这个问题，得到的是否定答案，当地方言叫Gaga的，有一些词汇和法语略有不同，我早期编辑百度百科的时候有此描述，但和真正的FP语差得很远。后面去常住的时候再次有所讨论，加上亲身经历，完全印证了当地FP语0通行度的说法。圣艾蒂安是欧洲海拔第二高的十万人口城市，“山都没进”？？？所以，阁下若有充足的理由或更深刻的经历，请提供相关来源--Patriotard 2019年11月30日 (六) 15:27 (UTC)
        好吧，海拔500米，勉强算个“高原”吧（笑）。算不算山，你打开Google地形图对比格勒诺布尔一带一看就清楚。比里昂还往西，就算按照100年前的标准也是“过渡区”，何来“核心区”一说？唉，我要是懂法语，一定在Grenoble爬山时问问高山草甸上放牧的大胡子，相信他是会说的。阁下提到的相信是fr:parler gaga吧，阁下在Bourg Argental的经历确实说明在整个西部FP在其西部丘陵区一如同满语在中国东北的境况，但总人口摆在那，东部肯定是有核心区的。请注意这里说的是澳门，和澳门的葡语比，我并没有说FP通行度高，只是比澳门葡语高。--146.96.147.137（留言） 2019年11月30日 (六) 15:35 (UTC)
        FP语的核心区在意大利境内，历史上的话则包括了整个Savoie公国，然而后者并不包括格勒诺布尔。澳门的情况我不了解，不下结论。--Patriotard 2019年11月30日 (六) 16:37 (UTC)
        抱歉，写的比较仓促，我想说的是古奥克语之于格勒诺布尔，已更正。另外从格勒诺布尔向北到Savoy大面积山区很多地方都是汽车根本开不进去的，有不少山地牧民，相信存在很大面积双语区，不过这个可以以后再说。--146.96.145.136（留言） 2019年12月3日 (二) 23:33 (UTC)
        
        澳门嘛，有个好处，就是你想找会说葡语的人也不难找到。反正总共就那么大地方，大不了扫一遍。地方大利于产生少数群体语言聚居区，地方小利于你搜索少数群体。--146.96.147.137（留言） 2019年12月11日 (三) 01:04 (UTC)
- @AirScott：阁下把意见改成“支持方案二用于法国”了啊？那么要看阁下是否支持方案二用于其他国家了，如果是，则还是上述问题。如果否，则因违反中立性而无法采纳。--146.96.147.137（留言） 2019年12月11日 (三) 01:04 (UTC)
  - 回复IP，本人对法国以外的事物不甚了解，故不确定方案二提到的其它地方是否都和法国的情况相同，如果是的话那我肯定支持。--Patriotard 2019年12月11日 (三) 09:13 (UTC)
    - 方案写的很清楚了：“聚落有两成人口”，当然具体到各个国家还可以有所松动，但不能太离谱。--146.96.147.137（留言） 2019年12月12日 (四) 01:44 (UTC)
      - 像语言历史文化这种主观性和地域性很强的内容，本人并不赞成搞个大一统的世界性方案。关于法国境内的非法语标注，本人已经解释的很清楚了。阁下草拟的方案二仅是单从人口数量来判断，而没有考虑具体的环境（如澳门作为近现代殖民地，语言使用情况和历史古城里昂有着明显的区别），基于此条，方案二推广于全世界是不可行的；而方案三里面的第三条“重要历史文化意义”概念很模糊，请问古法兰克普罗旺斯语/古普罗旺斯语之于格勒诺布尔有何历史文化意义？因为历史上有群体使用过？因为在书籍中出现过？如仅是这样则Canton也符合此标准。--Patriotard 2019年12月12日 (四) 09:22 (UTC)
        阁下是想说针对殖民地特殊处理？如果这样可以给出一个方案四啊。至于Grenoble的情况，我愿意在正式方案中去除一切例子，所以过于具体的可以不必讨论。建立这样的机制是为防止到A地就有人将“无通行度不用列出”到B地就有人讲“有重要文化意义就可以列出”的不一致性。至于什么情况具有重要文化意义，完全可放到具体条目里讨论。--146.96.145.33（留言） 2019年12月16日 (一) 22:04 (UTC)
方案四(AirScott方案)针对殖民地、前殖民地采用方案三列出殖民语言，针对其余情况采用方案二。--146.96.145.33（留言） 2019年12月16日 (一) 22:04 (UTC)
(－)反对方案二用于澳门，澳门很多事物是以葡萄牙语命名为先，事后给中文译名，不在首段列出反而不妥。(＋)支持方案三。--街燈電箱150號开箱维修抄表检验证明 2019年11月30日 (六) 17:16 (UTC)

请问为什么方案二中，嘉义市、嘉义县不添加？这两个县市的台湾话的使用人口明显超过两成。-游蛇脱壳/克劳棣 2019年12月1日 (日) 02:26 (UTC)

抱歉，写的比较仓促，我想说的是不添加邹语没有写全，已更正。--146.96.145.136（留言） 2019年12月3日 (二) 23:33 (UTC)

添加本地语言理所当然。港九自由嘻嘻嘻（留言） 2019年12月14日 (六) 12:50 (UTC)

所以阁下也支持方案三？--146.96.145.33（留言） 2019年12月16日 (一) 22:04 (UTC)

正式开新提议

我建议采用方案3A。方案3A与方案3的差别不大，唯一有分别的地方是：如相关非中文地名非地名本文，则要求来源证明有此名及符合相关条件。亲，我簽名那刻的時間是 2019年12月22日 (日) 11:34 (UTC)

可否解释下“地名本文”的概念？--69.94.58.75（留言） 2019年12月23日 (一) 02:28 (UTC)

大概就是地名译名本文的意思，例如金县的本文是King County、Hong Kong的本文是香港（不过实际上是香港仔）、Macau的本文是妈阁、亚的斯亚贝巴的本文是አዲስ አበባ。亲，我簽名那刻的時間是 2019年12月23日 (一) 15:01 (UTC)

就是“词源”的意思？那么Taipa的“本文”是凼仔还是大把？曼哈顿的“本文”是Manna-hata还是mënatay还是Manna-hatan？我担心“本文”这一概念会对百分之八十的条目无法确定。--146.96.147.137（留言） 2019年12月25日 (三) 03:23 (UTC)

@Sanmosa：赞同阁下修订的方向，不过方案本身我觉得还得换一种稍精确些修订方式。--146.96.147.137（留言） 2019年12月31日 (二) 04:43 (UTC)

为Wikipedia:格式手册添加例子

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2020年7月13日 (一) 08:14 (UTC)。

现行条文

我们鼓励所谓的“自由链接”：当您见到文中某些字词名称值得读者参考阅读的话，请使用[[]]代码转成内部链接。请注意不要作过多的链接，例如不要把一句的每一个词，或者通篇文章都为同一个词作出多次的链接：只要链接该词第一次出现就够了。

符合命名常规的链接会更容易成功链到已存在的条目；即使那条目还未存在，这样的链接也能够令未来新增的条目得到正确的名字。

链接所显示的文字不一定要与目标条目的名称相同，如[[朱熹|朱子]]。但请确保读者不需按下链接也能够清楚链接的目的地。

请尽量准确地链接。如果您想链接的条目还未存在，请先搜寻一下来确定该条目真的是不存在──它实际的名称可能只是与您所想的名称相差一点。

提议条文

我们鼓励所谓的“自由链接”：当您见到文中某些字词名称值得读者参考阅读的话，请使用[[]]代码转成内部链接。请注意不要作过多的链接，例如不要把一句的每一个词，或者通篇文章都为同一个词作出多次的链接：只要链接该词第一次出现就够了。

符合命名常规的链接会更容易成功链到已存在的条目；即使那条目还未存在，这样的链接也能够令未来新增的条目得到正确的名字。

链接所显示的文字不一定要与目标条目的名称相同，如[[朱熹|朱子]]。但请确保读者不需按下链接也能够清楚链接的目的地，比如以下这个例子是不恰当的：

......導致了原定接班人[[林彪]]的[[九一三事件|死亡]]。

在这个例子中，很容易使读者感到迷惑：我要点进去的这个链接到底是条目“死亡”？还是“林彪之死 - 九一三事件”？因此，可以改成这个：

......導致了原定接班人[[九一三事件|林彪的死亡]]。

在这个例子中，读者可以很清楚地明白，林彪死亡了，并且该内链指向的就是介绍林彪死亡的条目。

......導致了原定接班人[[林彪]]在[[九一三事件]]中死亡。

在这个例子中，内链直接指向它的文字所表达的条目，因此最为清楚直观，但并不是任何情况都适用的，有的时候使用这种方式反而会导致文字过长，或者读起来不通顺。具体内链的使用方法应由编者自行斟酌。

请尽量准确地链接。如果您想链接的条目还未存在，请先搜寻一下来确定该条目真的是不存在──它实际的名称可能只是与您所想的名称相差一点。

--Key to Sky遠い空へ（讨论｜贡献） 2020年7月13日 (一) 22:54 (UTC)

提议修订格式手册有关地区词的部分内容

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2020年7月24日 (五) 00:14 (UTC)。

在讨论WP:PB时，发现WP:格式手册#地区用词的格式一段存在一些问题。经查，此段的部分内容出现在2004年，当时似乎还没有繁简转换，此后该部分在2009年变为和今日类似，此章节的其他内容是在2013年由U:Skyfiler加入的。又经查，该用户在Wikipedia:互助客栈/方针/存档/2013年10月#方案5提出翻译英文格式手册，在无共识的情况下径行翻译并修改加入（居然没人发现），其翻译内容无法反映当时的共识。然而由于已放进去7年之久，不能直接去除。在此提案删除其中的某些部分，并修改一些部分。主要理由是，与enwp不同，zhwp存在地区词转换，其中的部分内容并无必要，或可能与其他方针或指引及社群惯例冲突。请社群审视。

现行条文

地区用词的格式维基百科并没有对各个地区用词的偏好。世界各地的中文使用者对同一样的事物可能有不同的叫法。维基百科已经实行自动地区词处理，能按照读者选择的地区（中国大陆、台湾、香港、新加坡）而显示当地的用词或译名。编辑时可使用{{NoteTA}}、{{地区名称}}，另参阅Wikipedia:繁简分歧词表及Wikipedia:译名表。

共用名维基百科尝试找到各个地区都能够通用的用词。坚持地区用词并不能体现维基百科的全球性。

能够在每个地区都通用的用词通常应被优先选择，特别是在文章的标题之内。
如果一个叫法被用作条目标题，其他的叫法应有重定向到该条目。
在某个地区不流行的词，如有提到，则应该进行解释以避免读者的困惑，例如四清、上山下乡、水喉等。
尽量使用精准的用词而避免有歧义的用词，例如在统计数据中使用人民币/台币/港币做单位而不是元，即使引用的文献原文是用元做单位。

和文章内文一致尽管维基百科不偏好某个地区用词，在一个条目中的用词应该保持一致。可以使用自动地区词处理提供的模板来自动化文字的转换。例外的场合有：

引用他人的文章时应忠实于原文
作家、导演、音乐家们的作品名字应忠实于作者
比较各地用词差异时

和地区的强烈关联和地区关系重大的条目应使用该地区的用词。例如，中国大陆地区相关的条目，使用中国大陆常用的词汇；同样地台湾/香港地区相关的条目，应使用对应地区惯用的词汇。对于作家来说，应使用和作品更相近的地区的用词。

本规则不能用来声明地区对条目的所有权，参照维基百科:条目的所有权。

保持现有的版本对于地区用词的争论不被鼓励。这通常是浪费时间，造成激烈的讨论但是不能解决问题。在内文的用词一致性已经建立之后，在没有共识改变这一用词的情况下，原用词应予保留。除了上面列出的少数理由之外，通常没有好的理由来支持用词方面的变动。在内文的用词一致性尚未建立时，第一个将条目补充至超出小作品篇幅的作者的用词应作为默认的选择。

提议条文

地区用词的格式维基百科并没有对各个地区用词的偏好。世界各地的中文使用者对同一样的事物可能有不同的叫法。维基百科已经实行自动地区词处理，能按照读者选择的地区（中国大陆、台湾、香港、澳门、马来西亚、新加坡）而显示当地的用词或译名。编辑时可使用{{NoteTA}}、{{地区名称}}，另参阅Wikipedia:繁简分歧词表及Wikipedia:译名表。

共用名维基百科尝试找到各个地区都能够通用的用词。坚持地区用词并不能体现维基百科的全球性。

能够在每个地区都通用的用词通常应被优先选择，特别是在文章的标题之内。
如果一个叫法被用作条目标题，其他的叫法如果本身没有歧义，则应有重定向到该条目。
在某个地区不流行的词，如有提到，则应该进行解释以避免读者的困惑，例如四清、上山下乡、水喉等。
尽量使用精准的用词而避免有歧义的用词，例如在统计数据中使用人民币/台币/港币做单位而不是元，即使引用的文献原文是用元做单位。

条目用词的一致性尽管维基百科不偏好某个地区用词，在一个条目中的显示用词应该保持一致^{[注 1]}。可以使用自动地区词处理提供的模板来自动化文字的转换。例外的场合有：

引用他人的文章时应忠实于原文
各种专有名词，例如作家、导演、音乐家们的作品名字和公司名称应忠实于作者
比较各地用词差异时

保持现有的版本一般而言，对于地区用词的争论只会浪费时间和造成激烈的讨论，而不能解决任何问题。在条目的用词一致性已经建立之后，在没有共识改变这一用词的情况下，原用词应予保留。除了上面列出的少数理由之外，通常没有好的理由来支持用词方面的变动。

在条目的用词一致性尚未建立时，除非另有共识，否则第一个将条目补充至超出小作品篇幅的作者的用词应作为默认的选择。

^ 使用地区词处理至一致也算作一致

Koala0090--DRIZZLE _{(按此给我留言）} 2020年6月27日 (六) 16:35 (UTC)

建议在和文章内文一致的例外的场合中加入专有名词（公司名称等）。--【和平至上】^{反对美国各地警方以过度武力镇压和平示威者}💬 2020年6月28日 (日) 11:16 (UTC)

已完成。不过我仍然在想在有地区词转换的情况下，怎么才能用到这一段。--DRIZZLE _{(按此给我留言）} 2020年6月28日 (日) 12:52 (UTC)

建议把“如果一个叫法被用作条目标题，其他的叫法应有重定向到该条目”和“在内文的用词一致性尚未建立时，第一个将条目补充至超出小作品篇幅的作者的用词应作为默认的选择”根据现实的情况修改为“如果一个叫法被用作条目标题，其他的叫法如果本身没有歧义，则应有重定向到该条目”和“在内文的用词一致性尚未建立时，除非另有共识规定，否则第一个将条目补充至超出小作品篇幅的作者的用词应作为默认的选择”。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{试问卷帘人却道海棠依旧} 2020年6月28日 (日) 11:46 (UTC)

已完成。--DRIZZLE _{(按此给我留言）} 2020年6月28日 (日) 12:52 (UTC)

(＋)支持。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{试问卷帘人却道海棠依旧} 2020年6月29日 (一) 05:39 (UTC)

我想不如把“不被鼓励”这个换成更自然的用语吧。--Super Wang※庆祝香港回归廿三年暨特区国安法顺利实施🇭🇰🇨🇳 2020年7月1日 (三) 09:30 (UTC)

“对于地区用词的争论不被鼓励。这通常是浪费时间，造成激烈的讨论但是不能解决问题。”这一句似乎是生硬翻译。我建议修改为“一般而言，对于地区用词的争论除了浪费时间和造成激烈的讨论外，并不能解决任何问题。”只不过，各方似乎都很愿意浪费时间。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{他从不挣扎} 2020年7月1日 (三) 11:34 (UTC)

依照上述提议代为修改提案。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{他从不挣扎} 2020年7月4日 (六) 07:51 (UTC)

@Sanmosa：语句是通顺了，但似乎是个病句。例句，“对于本店商品的售价，除了店长与总经理外，没有人能决定”；所以阁下的句子意味着“浪费时间和造成激烈的讨论能解决问题”？故在下建议改为“一般而言，对于地区用词的争论只会浪费时间和造成激烈的讨论，并不能解决任何问题。”，以上。-游蛇脱壳/克劳棣 2020年7月5日 (日) 02:27 (UTC)

调整了。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{他从不挣扎} 2020年7月5日 (日) 02:29 (UTC)

(！)意见@克勞棣：这个例句和之前的句子结构不同，“店长与总经理”是名词性短语，“浪费时间”是动宾短语。之前的句子并非病句。 DRIZZLE _{(按此给我留言）} 2020年7月8日 (三) 15:20 (UTC)

(：)回应@DrizzleD：可是我认为的“病”是“除了......以外”的使用方式。-游蛇脱壳/克劳棣 2020年7月8日 (三) 15:49 (UTC)

(：)回应@克勞棣：“除了”是连词，排除之部分和其他部分句法性质上是一样的，表示所说的不计算在内。因此我认为，前一句话“对于地区用词的争论除了浪费时间和造成激烈的讨论外，并不能解决任何问题”，“浪费时间和造成激烈的讨论”和“并不能解决任何问题”属于一样性质的短语，因此原句理解为“争论地区用词浪费时间和造成激烈的讨论，（且）不能解决任何问题”，不应该理解为“浪费时间和造成激烈的讨论能解决问题”。而“对于本店商品的售价，除了店长与总经理外，没有人能决定”则是“店长与总经理”和“没有人”相对，代表“（只有）店长与总经理能决定本店商品的售价”。--DRIZZLE _{(按此给我留言）} 2020年7月8日 (三) 16:04 (UTC)

(：)回应@DrizzleD：好吧！只要阁下确信这样写是对的，且不致被误解，那就改回来吧！-游蛇脱壳/克劳棣 2020年7月8日 (三) 16:23 (UTC)

改不改回去就无所谓啦

囧rz... --DRIZZLE _{(按此给我留言）} 2020年7月8日 (三) 16:28 (UTC)

根据WP:7DAYS法则，提案已有七日无留言，可公示，故现公示七日。ꓢꓯꓠ ꓟꓳ ꓢꓮ _{他从不挣扎} 2020年7月16日 (四) 00:06 (UTC)

编辑请求 2020-07-27

请求已拒绝--Xiplus#Talk 2020年7月29日 (三) 02:44 (UTC)

将“不要花哨华丽”更改为“不要花俏华丽”(更正错字)--BrianChen1107（留言） 2020年7月27日 (一) 15:32 (UTC)陈柏任

(－)反对。有“花哨”一词，没有“花俏”一词。（大陆用户） -- 铁塔（留言） 2020年7月28日 (二) 00:07 (UTC)

(－)反对花哨是装饰艳丽、语词变化丰富，花俏是色彩鲜艳、活泼。 KONNO Yumeto ^肺炎退散 2020年7月28日 (二) 14:01 (UTC)

(－)反对，请去客栈-- Sunny00217 2020年7月29日 (三) 01:19 (UTC)

不得修反例

以校辅为主题 Linadsl（留言） 2020年10月9日 (五) 03:30 (UTC)

不得修反

以校辅为主 Linadsl（留言） 2020年10月9日 (五) 03:30 (UTC)

用浪纹线表示范围

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

我想问格式手册中以下三处为什么要求大家不要用浪纹线表示范围？

Wikipedia:格式手册#时间、数字、度量衡：“请不要使用浪纹”
Wikipedia:格式手册/标点符号#连接号：“中华人民共和国国家标准及中华民国教育部标准中浪纹线“～”可与一字线通用，但在维基百科中不建议采用浪纹线。”
Wikipedia:格式手册/日期和数字#原则：“中英文及阿拉伯数字混用以表示延续范围，应使用……。浪号“~”和“～”亦不符合中文造字习惯。”

格式手册自己都说了，两岸的政府标准都允许用浪纹线，我不懂禁止的理由是什么。所谓“不符合中文造字习惯”意味不明，似是原创研究。如果是说中文应该用直线的话，那显然并非事实：不管是括号、逗号、还是中文字的辶、乙、乚等等都有弯曲。我在台湾从小学到大学的每一位老师，不管是数学、历史、化学科，不管是课本还是老师在黑板上写的字，全都是用浪纹线来表示范围。我反倒觉得用横线和数字写在一起很容易被误会成减号，或是跟中文在一起被误会成“一”字。如果没有合理的反对原因，我希望修改这三处指引，允许使用全形浪纹线。

Wikipedia:格式手册#时间、数字、度量衡#时间、数字、度量衡

现行条文

对于日期段当中，应使用全角连字符“－”（Unicode：U+FF0D）连接，如：

1906年－1967年10月17日

请不要使用浪纹：

~、～

注意连接号“－”不是破折号使用的“—”。

提议条文

对于日期段当中，应使用全角连字符“－”（Unicode：U+FF0D）或浪纹线“～”连接，如：

1906年－1967年10月17日

注意连接号“－”不是破折号使用的“—”。

Wikipedia:格式手册/标点符号#连接号

现行条文

连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为：短横线“-”和一字线“－”。中华人民共和国国家标准及中华民国教育部标准中浪纹线“～”可与一字线通用，但在维基百科中不建议采用浪纹线。如果输入一字线不方便，可以使用{{一字线}}（{{连接号}}）

提议条文

连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为：短横线“-”和一字线“－”。中华人民共和国国家标准及中华民国教育部标准中浪纹线“～”可与一字线通用。如果输入一字线不方便，可以使用{{一字线}}（{{连接号}}）

Wikipedia:格式手册/日期和数字#原则

现行条文

中英文及阿拉伯数字混用以表示延续范围，应使用中文的连接号，即英文全角的“－”，来连接，不是破折号“—”。浪号“~”和“～”亦不符合中文造字习惯^[1]。例如：1906年－1967年10月17日、15千米－200千米。

^ 参见维基百科:格式手册之第2节“时间、数字、度量衡”和7.14节“连接号”。

提议条文

中英文及阿拉伯数字混用以表示延续范围，应使用中文的连接号，即英文全角的“－”或浪号“～”，来连接，不是破折号“—”。例如：1906年－1967年10月17日、15千米～200千米。

以上--Yel D'ohan（留言） 2020年10月7日 (三) 23:11 (UTC)

香港不用波浪线，供参考。--Temp3600（留言） 2020年10月8日 (四) 04:39 (UTC)
目前的规定：地域包容性强，能够覆盖不使用（或常用）的地域；使用范围包容性强，如根据GB/T 15834-2011，波浪线不仅只是有时使用，而且使用范围较横线来得小，统一用范围更大、更常用的可以避免额外对使用范围进行界定；实现统一，避免各条目混杂使用（在前述两点及大致上看现有的各种来源官方命名以横线居多的情况下，统一为一字线更适宜）。--Kirk★ 0#0 2020年10月8日 (四) 08:29 (UTC)
囧……一直到2012年移居国外之前，我只在外文期刊上看过用一字线表示范围。不过这似乎也没办法作为地区词转换，因为只有一个字元，而且很多ACG作品名称的中译仍保留了浪纹线……--Yel D'ohan（留言） 2020年10月8日 (四) 12:05 (UTC)
反对使用波浪号，行之已久，统一比较好。－hiJK910 ^七一_七二一 2020年10月8日 (四) 12:17 (UTC)
除非根据“名从主人”，作品名明确使用波浪线，否则其他地方应保持原有规范。乌拉跨氪 2020年10月8日 (四) 16:22 (UTC)
我感觉在台湾波浪线比一字线更常用，而且用法完全和格式手册中描述的全形一字线相同。这里提供几个例子：中华民国气象局的气温、中华民国主计处的年龄（表一到四）和时数（表六）、台湾大学课程时间、大学指考中的温度和雨量（第29题）、台北捷运营运时间和班距、猫空缆车营业时间（中、英、日文版都用浪纹线）。我理解技术上可能不容易转换，但是为了追求条目统一完全禁用我觉得不合理，至少应该允许在条目内部统一的情况下先到先得。--Yel D'ohan（留言） 2020年10月8日 (四) 17:25 (UTC)
依据重订标点符号手册，连接号为甲式，波浪号为乙式。不过在国际用法，表示范围没有在用波浪号的。我认为标准可以修改成优先推荐连接号，波浪号虽不推荐但不禁止使用。台湾杉在此发言 (会客室) 2020年10月9日 (五) 03:41 (UTC)
(－)反对：用浪纹很奇怪，没必要改。--203.145.94.216（留言） 2020年10月9日 (五) 11:36 (UTC)
说点可能些微离题的，典范条目约翰·塞巴斯蒂安·巴赫之前一度全文使用波浪号，后来被其他用户修改为连接号。我在典范条目评选的时候问过主编标点符号的问题（那个时候条目还没被改），兹将其回应摘录如下：“根据格式手册#连结号，‘连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为：短横线“-”和一字线“－”。中华人民共和国国家标准及中华民国教育部标准中浪纹线“～”可与一字线通用，但在维基百科中不建议采用浪纹线。’由以上语句判断维基并不硬性规定‘～’和‘－’⋯⋯”他的回应以现行方针与指引来看合理吗？—— Eric Liu_{欢庆双十中国国庆（留言．留名．学生会）} 2020年10月9日 (五) 13:41 (UTC)
未见到要用全角浪纹的必要性，本来全角连字符就够奇怪的了，没什么必要整这一出。—Mint Candy♫ _{欢迎参与浙江专题台州专题} 2020年10月16日 (五) 14:51 (UTC)
(＋)赞成：横线的种类太多，很容易混淆，（似乎天天有人在把一种横线改成另一种横线）不如用波浪线明确。 -- 铁塔（留言） 2020年10月27日 (二) 02:45 (UTC)
不支持。开放浪纹对读者的帮助相当有限，但对版面紊乱度恐怕颇有助益 囧rz……。--Hjh474（留言） 2020年10月27日 (二) 06:56 (UTC)
(－)反对：看不出必要性。-- Marcus Hsu ✉ 2020年12月1日 (二) 01:26 (UTC)

在格式手册增加对折叠内容的限制

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

公示期满，通过。--Easterlies 2020年12月19日 (六) 09:51 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

光明顶 (广播节目)中折叠内容已经成了琐碎信息列表的避风港。因此有必要修订格式手册以限制条目中准许的折叠内容。-Mys_721tx（留言） 2020年12月1日 (二) 19:19 (UTC)

上述条目折叠部分的内容可以大刀阔斧删掉。--小羊（留言） 2020年12月2日 (三) 04:00 (UTC)

已移除。格式手册修订的讨论应继续进行。-Mys_721tx（留言） 2020年12月2日 (三) 04:37 (UTC)

想问下Wikipedia:隐藏元素第二段关于Wikipedia:格式手册#滚动列表与折叠元素哪里去了？--Air7538#Sign 2020年12月2日 (三) 06:04 (UTC)

粗略查看了一下2011年起就没有该章节。-Mys_721tx（留言） 2020年12月2日 (三) 06:25 (UTC)

其实是从来都没有那个章节吧。SAN MO SA _SPQR 2020年12月2日 (三) 06:43 (UTC)

现行条文

提议条文

滚动列表与折叠元素

快捷方式

滚动列表和可在折叠与显示之间切换的折叠元素可妨碍读者访问维基百科。此类功能不应用于隐藏“剧透”内容。模板一般不应存储条目文字，以免妨碍编辑搜索修改相关内容。

45%的维基百科读者通过移动版访问维基百科^[a]；此比例还在不断上升。移动版所支持的功能有限。使用滚动列表与折叠元素等功能时，应注意保证相关内容可在移动版及在不支持JavaScript或CSS的设备上访问。可通过页面底部“手机版视图”链接检查该页面是否可在移动版上阅读。^[b]

折叠模板不应默认在页面加载完毕后隐藏条目内容，包括参考文献列表、表格、列表、图集、题注等。虽然维基百科允许一些支持collapsible参数或带有手工加入的CSS类的模板，除下列允许情况外，collapsed、mw-collapsed、autocollapse等状态不应于条目中用作预先隐藏这些元素。任何以此方式在加载页面时隐藏的内容对前述用户及通过Google访问维基百科的低带宽用户完全不可见。^[c]若干其他CSS类在人工加入条目或有模板引入时也会导致移动用户无法读取带相关标签的内容。^[d]

仅仅为重复正文的单元格或章节可折叠或自动折叠（纯粹的补充内容亦可如此：展示当前统计数据时可折叠往年数据）。自动折叠是导航模板的特性之一。一些信息框也折叠了不常用细节。若列表、信息框、其他非导航内容中的信息足够无关或琐碎需要折叠，可考虑发起讨论彻底移除此类信息。若有关资料有重要性，但因条目密度或长度需要隐藏，可考虑划分更多章节、将无必要的列表改写为散文、拆分条目。

备注

^ 见每月底更新的页面访问量统计。该统计仅计算页面点击量；事实上大多数读者在一定时间内使用过移动设备访问维基百科。
^ 可将网址中的zh.wikipedia.org替换为zh.m.wikipedia.org后加载新网址访问移动版页面。在移动设备上访问桌面版页面无助于评估移动页面显示问题，但可用于诊断平板电脑等设备上的亲和力问题。
^ 如上文所述，切换显示或隐藏状态需要CSS与JavaScript。即便设备支持上述功能，移动版服务器会自动去除隐藏内容。Google于2016年在印度和印度尼西亚为低带宽用户提供精简版页面，该服务会去除导航框和隐藏内容。Google还计划在其他国家地区提供该服务。 [1] [2]
^ 导致此问题的CSS类包括并不限于：ambox、navbox、vertical-navbox、topicon、metadata、nomobile、collapsed、mw-collapsed、autocollapse（触发时）。

翻译自en:Special:PermaLink/991894520#Scrolling lists and collapsible content。-Mys_721tx（留言） 2020年12月2日 (三) 19:12 (UTC)

初步略看，仅有地区词问题，反正目标页有字词转换，可以(＋)支持。SAN MO SA _SPQR 2020年12月2日 (三) 23:22 (UTC)

顺便也吐槽一下站内那些主要内容都完全被折叠的年号列表，最近处理日本年号列表分拆的事情的时候，竟然还有人跳出来说大小上已经过长且严重滥用折叠的中国年号列表是年号列表条目的典范，结果我分拆出来的列表都能够FL。虽然折叠在现时并没有一个规范，但是一向的惯例都是不能够折叠得太多（最好没有折叠）。SAN MO SA _SPQR 2020年12月2日 (三) 23:42 (UTC)

曾经我有想过把中国年号列表分拆出来，但感觉没什么很详细的资料可以加上。对，我离题了。—〚玮玮 · 嘎嘎 · 嘎嘎嘎〛 2020年12月3日 (四) 02:42 (UTC)

我觉得如果目标不是FL的话，直接分拆是没问题的。SAN MO SA _SPQR 2020年12月3日 (四) 02:46 (UTC)

"内容"两字重复太多了，应当修改一下。-Mys_721tx（留言） 2020年12月3日 (四) 00:15 (UTC)

我先稍代作调整。SAN MO SA _SPQR 2020年12月3日 (四) 05:45 (UTC)

"若干其他CSS类在人工加入条目或有模板引入时也会导致移动用户无法访问页面"这一点用页面不恰当。此处带相关标签的内容会被移动版服务器移除，而非导致整个页面不可见。-Mys_721tx（留言） 2020年12月3日 (四) 08:22 (UTC)

完成。SAN MO SA _SPQR 2020年12月3日 (四) 08:56 (UTC)

(＋)支持作指引，未见明显不妥。collapsible那段拗口、不好懂，“除下列允许情况外collapsed、mw-collapsed、autocollapse状态……”如何断句。--YF dyh000（留言） 2020年12月4日 (五) 08:51 (UTC)

@YFdyh000：我再改一改。SAN MO SA _SPQR 2020年12月4日 (五) 09:54 (UTC)

@Sanmosa、YFdyh000：未见反对意见，11日应可开始公示。-Mys_721tx（留言） 2020年12月9日 (三) 16:14 (UTC)

我觉得不如直接把Wikipedia:隐藏元素列为指引。——BlackShadowG（留言） 2020年12月11日 (五) 10:02 (UTC)
@BlackShadowG：不可行，Wikipedia:隐藏元素本质上属于论述，可能隐含个别用户的个人意见。方针指引不应该隐含任何用户的个人意见。如果你不反对的话，我仍然希望把上方一案进行公示。SAN MO SA _SPQR 2020年12月11日 (五) 13:19 (UTC)
- (＋)支持本提案，毕竟目前有相关问题的条目实在太多了。——BlackShadowG（留言） 2020年12月11日 (五) 16:20 (UTC)

开始公示。-Mys_721tx（留言） 2020年12月12日 (六) 03:18 (UTC)

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

[1] 使用地区词处理至一致也算作一致

[2] 参见维基百科:格式手册之第2节“时间、数字、度量衡”和7.14节“连接号”。

[3] 见每月底更新的页面访问量统计。该统计仅计算页面点击量；事实上大多数读者在一定时间内使用过移动设备访问维基百科。

[4] 可将网址中的zh.wikipedia.org替换为zh.m.wikipedia.org后加载新网址访问移动版页面。在移动设备上访问桌面版页面无助于评估移动页面显示问题，但可用于诊断平板电脑等设备上的亲和力问题。

[5] 如上文所述，切换显示或隐藏状态需要CSS与JavaScript。即便设备支持上述功能，移动版服务器会自动去除隐藏内容。Google于2016年在印度和印度尼西亚为低带宽用户提供精简版页面，该服务会去除导航框和隐藏内容。Google还计划在其他国家地区提供该服务。 [1] [2]

[6] 导致此问题的CSS类包括并不限于：ambox、navbox、vertical-navbox、topicon、metadata、nomobile、collapsed、mw-collapsed、autocollapse（触发时）。

[注 1]

[1]

[a]

[b]

[c]

[d]