跳转到内容

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

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

空格

在中文维基格式手册里,空格一节写出,“在中文语境内,文字之间应该不留空格。”请问这是否只是指中文与中文之间?在中文与英文之间,在中文与数学符号之间,在中文与数学方程之间,在标点符号与中文之间,是否可以留空格?在英文维基里,对于空格的置入没有做出限制。从英文维基输入的模板与数学方程里,都存在著很多空格。我觉得在原始码内适当地置入空格,可以帮助检视与维持;在页面里适当地显示空格,也可以帮助阅读、美化页面。我们是否可以赋予空格一些它可以承担的功能?请大家发表宝贵意见,达成共识,谢谢!--老陈留言2016年3月22日 (二) 05:58 (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)
谢谢您的关注与意见!希望您翻译英文时,务必要仔细严谨,不能断章取义:
  1. In normal text(在正常文句里):这不包括特别案例,例如,模板内的原始码、数学公式与正常文句之间的界面等等。英文维基没有对这些特别案例做出规定。
  2. Multiple spacing styles may coexist in the same article(多种空格置入格式可以共存于同一篇文章):请注意到英文单字“coexist”。--老陈留言2016年3月24日 (四) 05:34 (UTC)
断章取义的是您吧?
1. 原文是说in normal text没错,但是它并没有说“模板内的原始码、数学公式与正常文句之间的界面”可以加空格,那是您自己单方面的衍生解释,能不能被接受尚有讨论空间。
2. coexist的主词是“spacing styles”(空格的格式),也就是我提过同一条目内空格是要打单字元、双字元或多字元都没差,因为系统会自动压缩调整,但是您的主张其实是在讨论空格安插的“位置”,请问原文中何处有说各种不同的安插位置规则可以coexist的?
希望您翻译英文时,也务必要仔细严谨,不该把自己的主张混入对规则的翻译中。--泅水大象讦谯☎ 2016年3月24日 (四) 06:13 (UTC)
谢谢提醒!我觉得“在中文语境内,文字之间应该不留空格”这句子写得不够明确,很容易引起不同的诠释。因此,我提议改写为“在中文语境内,中文文字与中文文字之间应该不留空格”。其他论题可以留待以后商讨。希望获得大家共识,不知道您觉得可否这样改写?--老陈留言2016年3月25日 (五) 05:45 (UTC)
不可以,如果这样改写等于变相允许中文与英文字之间可留空格(所谓中文“语境”,就表示包含在中文文章中插入英文字的情况,但排除整句都是外文内容的情况,原规定其实写得很清楚)。如果要改,还是应该先获得社群共识后再依照讨论结果修正。--泅水大象讦谯☎ 2016年3月25日 (五) 07:16 (UTC)
按照您的说法,为了避免争议,我提议将这句子改写为“在中文句子内,中文文字与中文文字之间应该不留空格”。--老陈留言2016年3月26日 (六) 14:10 (UTC)
(:)回应原文中的中文“语境”原本就是泛指以中文作为主体,只是局部插入外文字的情况,包括中文与中文字之间,也包含中文与外文字体之间,仅有全段皆为非中文(也就是外文语境)的状态下允许插入空格。所以,您这样的狭义定义乍看之下好像是要把规定解释清楚,但实际上根本是暗渡陈仓把您的主张混入规则中,是很不妥的作法。如果您想要自己的主张被实现就请等讨论流程完成之后再说,但很显然一路看下来支持您主张的用户仅属少数。--泅水大象讦谯☎ 2016年3月28日 (一) 05:26 (UTC)
从2010年至今,与User:Πrate和其傀儡为了一个空格而发生争执的用户显然不是少数(例如User:ArikamaI),Wikipedia:五大支柱:“维基百科不墨守成规: 维基百科制定有方针与指引,但并非板上钉钉不可更改,其内容和解释可以逐渐发展完善。它所蕴含的原则和精神比字面措辞更为重要,并且有时为了改善维基百科允许有例外。”--Mewaqua留言2016年3月28日 (一) 05:38 (UTC)
又加一个例子,User:Πrate的傀儡在众多条目的参考文献里删掉新闻标题中用作分隔句子的space(例如圣人瀑布,如把“开放圣人瀑布 溪山里民疾呼”改成“开放圣人瀑布溪山里民疾呼”),增加阅读上的不便。--Mewaqua留言2016年3月28日 (一) 05:53 (UTC)
参考文献非主文本就不在格式手册规定的范围,直接依照文献来源原本的格式也属合理。M君举的例子正证明了相关的格式规则还是要订以避免编辑战的可能,但规则若有不恰当之处随时都可提出检讨修改,或在必要时弹性调整,但给编辑用户一个基本的遵循依归还是很重要的。--泅水大象讦谯☎ 2016年3月28日 (一) 06:11 (UTC)
从英文维基输入至中文维基的参考文献与模板,其内部遍布了很多空格,这是为了使得原始码易读易懂,MediaWiki软件会自动处理这些空格。请问您是否赞成允许空格在参考文献内存在?请问您是否赞成允许空格在模板内存在?--老陈留言2016年3月30日 (三) 00:33 (UTC)
这跟英文维基无关,系统处理模版时原本就会忽略掉文字(无论中文英文)前后的空格,但不会忽略文字与文字间的空格,但是阁下明明在讲的就是在文字与文字(例如中文与英文字母间的介面)插入空格的主张,且明明讨论的就是主文部分,为何老是拿不相干的事情来混淆视听?--泅水大象讦谯☎ 2016年3月30日 (三) 06:36 (UTC)
一个条目不只是只有主文部分,它还包括条目名、主文、标题、参考文献、模板等等。所以,您不反对在参考文献、模板内的空格可以存在。--老陈留言2016年3月31日 (四) 22:15 (UTC)
不会实际在画面中显示出效果的空格我不在意,参考文献中的title栏位原本就是用来显示原文,因此比照原文格式也是合理,其他部分请遵守格式守则。--泅水大象讦谯☎ 2016年4月1日 (五) 02:51 (UTC)
很高兴能够达成共识:-)!--老陈留言2016年4月1日 (五) 22:34 (UTC)

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

那为什么斜体后面就不能用JS/CSS加……--Jimmy Xu 2016年3月28日 (一) 00:41 (UTC)
很有趣的是“Y0”这个状况并不是该利用空格修正格式的好场合,因为如果在斜体字后方加空格来修正,虽然原本有字体重叠问题的用户看到的画面正常了,但原本显示很正常的用户,却反而会看到“Y”跟“0”之间被明显拉开看起来不太像指数符号的情况。若要修正这问题,使用CSS调整恐怕才是治本的方法。--泅水大象讦谯☎ 2016年3月29日 (二) 04:19 (UTC)
{{Lang|en|''Y''<sup>0</sup>}},显示为Y0。--Mewaqua留言2016年3月30日 (三) 02:09 (UTC)
所以意思是说其实斜体后面的文字重叠问题,用lang模版就能解决?(在我所使用的浏览器/字码版本上有没有加lang的显示效果一模一样,所以无法分辨)--泅水大象讦谯☎ 2016年3月30日 (三) 06:38 (UTC)
可是我这里看这样也会重叠?(虽然感觉没那么重叠,但是可能是因为文字较粗造成的错觉)-和平、奋斗、救地球!2016年3月31日 (四) 04:30 (UTC)
不就是说明了可以通过CSS(或者HTML标签渲染机制)来解决?{{lang}}只是将相应语句用带有lang属性的span包裹,然后让浏览器根据语言来推断字体库,有些字体库能支持斜体字符不覆盖,有些字体库不能。——路过围观的Sakamotosan 2016年4月1日 (五) 01:03 (UTC)
我的发言欠缺考虑,我同意Y0是不应使用空格拆分的。Bluedeck 2016年3月31日 (四) 17:26 (UTC)
如果中文和英文之间要增加间距,则用JavaScript或CSS技术性解决,禁止人为在源代码级别加空格。如果中文和数字之间要增加间距,则用JavaScript或CSS技术性解决,禁止人为在源代码级别加空格。如果学习User:Cdip150的做法,中文和英文短语之间不加间距,和英文句子之间增加间距,则用JavaScript或CSS技术性解决,禁止人为在源代码级别加空格。--Gqqnb留言2016年4月1日 (五) 07:02 (UTC)
在下面的例子中,我没有在源代码里添加任何空格,CSS在实现中应为JavaScript所加:紧凑型中Condensed Text;疏散型中Scattered Text--Gqqnb留言2016年4月1日 (五) 07:09 (UTC)
很有意思的方法,赞!--老陈留言2016年4月2日 (六) 06:39 (UTC)
JavaScript与CSS技术属电脑领域,只有电脑专家懂得怎样正确操作这种高阶技术,普通编辑者只能望洋兴叹,请问是否能够给出一些普通编辑者能够容易操作的方法?--老陈留言2016年4月3日 (日) 05:04 (UTC)
margin-right不太合适吧,这样源代码就很难看了,还不如一个空格美观。--Nbdd0121留言2016年4月5日 (二) 16:40 (UTC)
“CSS在实现中应为JavaScript所加”没有人需要在源代码里手工编写这些代码。--Gqqnb留言2016年4月9日 (六) 00:54 (UTC)
@Gqqnb(-)反对 JS会延后加载,这种方法不可避免的会出现页面闪一下。--Nbdd0121留言2016年4月9日 (六) 16:05 (UTC)
@Nbdd0121(-)反对,我不知道你对JavaScript或计算机科学的了解有多深,我不想说我计算机科学经历,但现在几乎没有网站不用js,技术问题就可以技术处理。不要一直动源代码的主意。--Gqqnb留言2016年4月10日 (日) 20:03 (UTC)
@Gqqnb(:)回应,我也不知道你对JavaScript或计算机科学的了解有多深,但你需要知道MediaWiki的JavaScript是通过ResourceLoader Queue延迟加载的。如果你要通过JavaScript来修改界面样式,那么不可避免的会出现闪烁。如果段落较长,修改margin或者letter-spacing的效应堆加起来甚至会影响整个页面的排版。--XYZ指示物留言2016年4月10日 (日) 20:38 (UTC)

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

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

感谢支持!在英文里,空格扮演很重要的角色,在中文原始码里,我们也可以给予空格一些有助于可读性、美观性的功能,避免过度限制编辑者置入空格的行为。--老陈留言2016年4月9日 (六) 06:15 (UTC)
(+)同意 部分同意,不过如果只有一个单词的专有名词按照中文语法放在句子中,加上空格会不会让人感觉在强调一样?--Nbdd0121留言2016年4月9日 (六) 16:05 (UTC)
您提出了一个很好的问题!在维基百科里,有几万个条目,其中,有些条目品质优良,但也有些条目品质粗劣,怎样分辨优质的条目与劣质的条目,这是我们编译者时常要面对的工作。我觉得格式手册空格章节的规则有改良的必要,特别是在原始码方面,所以提出讨论,尝试加以改良,希望能够获得共识。--老陈留言2016年4月10日 (日) 22:03 (UTC)
  • 对于“一个质量为m的粒子”,两个用户看到的结果不一样
用户1的浏览器的结果:一个质量为m的粒子
源代码:<span style="font-family:'微软雅黑',sans-serif">一个质量为''m''的粒子</span>
用户2的浏览器的结果:一个质量为m的粒子
源代码:<span style="font-family:Arial,'新細明體',sans-serif">一个质量为''m''的粒子</span>
如果字母m前面加入空格
用户1的浏览器的结果:一个质量为m 的粒子
源代码:<span style="font-family:'微软雅黑',sans-serif">一个质量为''m'' 的粒子</span>
用户2的浏览器的结果:一个质量为m 的粒子
源代码:<span style="font-family:Arial,'新細明體',sans-serif">一个质量为''m'' 的粒子</span>
可以看出,“加入空格”给不同用户带来的影响不一
CSS letter-spacing我想应用在“m的”这部分文字,效果跟“加入空格”差不多,后者调整的单位是空格,前者的单位很小 - John doe 120留言2016年4月23日 (六) 08:26 (UTC)
  • 打开网页[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)

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

难道就没人会用LaTeX吗?

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

@李4:我就真的不会....你肯定维基上有教学?--Temp3600留言2016年5月8日 (日) 13:26 (UTC)
user:Temp3600[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]大家来学LaTeX(我随便找的,自己没看过)。Bluedeck 2016年5月12日 (四) 00:20 (UTC)
user:Temp3600[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]中文维基教学于Help:数学公式。--Emphrase留言2016年5月29日 (日) 18:50 (UTC)
使用LaTeX已六年,虽然频率不高,我推荐使用英文Wikibooks当LaTeX参考手册,一打开首页就有个大大的LaTeX,属于特色书籍。— Bieraaa 于 世界统一时间 (UTC) 2016年5月26日13时21分 留言

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

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

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

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

多馀,格式手册针对空格本来就有这么的规定:“如果官方宣布的名称内含有空格,以官方为准。”参考文献标题是文献的官方给的,所以它带有空格本来就已经被允许。还有请不要把讨论分开多个山头,都不知应该在哪里讨论才好。--街燈電箱150號 开箱维修 抄表 检验证明 2016年4月2日 (六) 06:21 (UTC)
在格式手册的空格章节里表明,“在中文语境内,文字之间应该不留空格”。这规定意味著严格限制空格的存在,不只是在标题内而已。我不清楚您对这规定如何诠释,但我觉得这规定并未给予编辑者足够的诠释空间。为了避免有些破坏者利用这规定进行大量删除空格的无建设性编辑,并在其中夹杂著错误编辑,如在圣人瀑布里的恶性编辑,所以才提议添加规则。关于在哪里讨论才好这问题,我不会坚持己见,请问应该在那里讨论较好?--老陈留言2016年4月3日 (日) 00:27 (UTC)
我仍然认为不需要添加,其实我上面说的话本身也有点多馀,因为我是假设该节适用于参考文献的来跟您说,不过实际是不适用的,因为该节已经说了“在中文语境内”,但参考文献本身就不是成句话,所以不算是“语境”,继而如大象兄所说,根本不在格式手册规定的范围内。(讨论的位置应该在#空格延续,而不是现在这里另起炉灶)--街燈電箱150號 开箱维修 抄表 检验证明 2016年4月3日 (日) 06:58 (UTC)
已移动讨论位置。--老陈留言2016年4月4日 (一) 01:37 (UTC)
术语“中文语境”缺乏明确定义。是否应该对于术语“中文语境”给出明确定义?假若中文语境不包括参考文献在内,那中文语境到底包括甚么部分在内?--老陈留言2016年4月7日 (四) 05:25 (UTC)
圣人瀑布模板内的空格编辑,为非建设性编辑,应避免。“17 公尺”去除空格,符合格式手册规定。民国纪年的替换我暂保留意见。参考资料里author、title去除空格不正确,这项属于严重错误。--Gqqnb留言2016年4月9日 (六) 01:02 (UTC)
按照您的说法,“17 公尺”前面与后面的空格都符合格式手册规定,只有在“17”与“公尺”之间的空格不符合格式手册规定;换句话说,中文语境前面与后面的空格都可以存在,只有在中文语境内部不能存在空格。关于中文语境的范畴,中文语境不包括参考文献、模板、表格在内,而是参考文献、模板、表格内部包含有中文语境。请问您是否同意这表述?--老陈留言2016年4月9日 (六) 05:55 (UTC)
首先明确,我们讨论的是源代码内的空格,还是渲染后的空格。我认为我们讨论的是渲染后的空格。凡是改动在源代码里的、不影响渲染的空格,都属于代码格式,属于“维基源代码规范”或“HTML代码规范”。对于作为模板参数等其他直接输出至页面的空格,区分是否为中文语境。height = ...中的等号之后第一个非空白字符开始为模板参数,所以“17”与“公尺”之间的空格不符合格式手册规定。而格式手册规定的是渲染后的页面的格式,而不是源代码格式,所以“17 公尺”前面与后面的空格属于无规范状态(加不加都不影响输出效果),所以我才说是非建设性编辑。我(+)同意参考文献、模板、表格内部输出为HTML的文本部分(区别于标签)包含有中文语境。<span style = "color : red">17 公尺</span>输出为17 公尺,其中style前后的空格、冒号前后的空格都属于源代码中输出至HTML标签的空格,非格式手册规范的空格,而span的文本为“17 公尺”,是输出为HTML的文本。--Gqqnb留言2016年4月10日 (日) 20:23 (UTC)
@Gqqnb:谢谢您对于这论题的仔细分析!
  • 为了避免搞不清楚“空格”到底指的是甚么,我们应该明确区分原始码内的空格与渲染后的空格,暂且称渲染后的空格为空距,因为渲染程序最后会展示出多少空白是决定于渲染软件的输入参数。按照您的说法,原始码内的空格安置是属于“维基原始码规范”,而渲染后的空距是属于格式手册规范。请问我这样表述是否符合您的说法?
  • 关于您所提到的文本问题,我不清楚“文本”指的是甚么?所以无法明确表达我的意见。
  • 关于“17公尺”的问题,假设在原始码内,“17”与“公尺”之间是否可以有空格属于“维基原始码规范”,不属于格式手册规范;在渲染之后“17”与“公尺”之间是否可以有空距属于属于格式手册规范。请问您是否同意这说法?--老陈留言2016年4月13日 (三) 05:46 (UTC)
  • @老陳:,(+)同意“源代码内的空格安置是属于“维基源代码规范”,而渲染后的空距是属于格式手册规范。”。
  • 如果你在浏览器页面上右键,选择查看网页源代码(Chrome浏览器用语)/查看源(IE浏览器用语),你会看到类似<html lang="zh-CN" dir="ltr" class="client-nojs"><head><meta charset="UTF-8"/><title>维基百科:互助客栈/方针 - 维基百科,自由的百科全书</title>的内容。“文本”是HTML技术角度的词。这里的大意是“查看HTML源代码”所显示的内容,也不受格式手册规范。
  • (+)同意“假设在源代码内,“17”与“米”之间是否可以有空格属于“维基源代码规范”,不属于格式手册规范;在渲染之后“17”与“米”之间是否可以有空距属于属于格式手册规范”。这就是我表达的意见,即源代码可以有空格但渲染后无空距;或者源代码无空格但通过js或css的帮助,渲染后产生空距。--Gqqnb留言2016年4月13日 (三) 06:07 (UTC)
  • (-)反对,反对在数字和汉字,或英语和汉字之间插入空格。反对“13 公斤”,反对“13 kg”,也反对“km / h”,应写成“13公斤”、“13kg”和“km/h”。--7留言2016年4月9日 (六) 14:35 (UTC)
谢谢您的意见!希望能够给出理由,大家集思广益。我觉得Pityonline推荐的网路文章为什么你们就是不能加个空格呢?相当有阅读价值,建议您有空时不妨点阅。--老陈留言2016年4月10日 (日) 05:47 (UTC)
7 的说法是有道理的,所谓适当留白,至少需要保留一些自有格式,不要改变原义,或造成歧义,亦非一味地为增强可读性与美观性而拙劣地添加不恰当的空格。不过我建议单纯的数字与不包括带 “/” 的中文单位间应该留白,如 13 公斤,3 份等,遇 13kg,13公斤/人,80km/h 这种,数字与右边文字不应留白,但数字左边应该留白。Pityonline留言2016年4月10日 (日) 06:09 (UTC)
同样反对“左边留白”,反对“体重 70公斤”,反对“距离 3000公里”,反对“风速 200公里/时”,应写成“体重70公斤”,“距离3000公里”,“风速200公里/时”。--7留言2016年4月10日 (日) 16:22 (UTC)
根据国际单位标准规定,数字与单位之间应有空格,因此“13 kg”是正确写法,这也是绝大多数学术书籍与期刊采用的做法。至于中文语境,尚未找到相关标准,给出此文供参考。--Wcam留言2016年4月10日 (日) 22:57 (UTC)
看了这个,果然留白没什么不妥的,而且 w3c 亦有此说明Pityonline留言2016年4月11日 (一) 00:48 (UTC)
同意Jarodalien的意见。中文语境中,传统上并无空格。我看到的专业文献中,也几乎没看到这么做的/要求的。很多时候中英/数字混排当中出现的空白并不是空格,而是排版软件自动优化的结果(所以,增加空白可以考虑,增加空格或其他类似字符反对)--百無一用是書生 () 2016年4月12日 (二) 02:25 (UTC)
如觉得数字与中文字之间要增加空白,应是采用修改CSS的方式全面调整,而不是用人工方式插入空格。所以我同意书生兄所言,别把空白跟空格两件事搞混了!--泅水大象讦谯☎ 2016年4月12日 (二) 07:19 (UTC)
我现在倾向于添加空白,并且以在源代码中添加空格的形式添加。理由如下
  • 中英文中需要有空白:阅读了一下 Pityonline 给出的 W3C 草案,另查阅了一下相关资料,中英文之间需要有 1/4em 的空白,Word 等排版引擎也早已遵循了这一要求。
  • 不适宜使用 JS 添加:用 JS 添加理论上是可行的,但是如同我上面提到过,用JS添加需要等到 DOM Ready,在这之前页面已经呈现,不可避免地出现闪烁。
  • 尚无纯 CSS 解决方案:纯 CSS 的解决方案需要 CSS Level 4 中的 text-spacing,目前除了 IE 实现了 -ms-text-autospace 以外,其他浏览器不支持该属性,也没有其他纯 CSS 解决方法。
  • W3C 草案中提到可以使用一个西文空格做该空白的代替。
--XYZ指示物留言2016年4月12日 (二) 12:52 (UTC)
那么我反对这种手工加空格的做法,就像现实生活中看到这种稿件直接退稿不看一样,看到有这种来参加任何条目评选一概反对。我并不觉得这样更加美观,恰恰相反,觉得更难看。像小时一样,我也从来没有在任何论文看到过这种手动加空格的做法。英语不过是有空格分隔单词的习惯。至于那篇一开头就在下定论搞攻击,说什么“有研究显示,打字的时候不喜欢在中文和英文之间加空格的人,感情路都走得很辛苦,有七成的比例会在 34 岁的时候跟自己不爱的人结婚,而其余三成的人最后只能把遗产留给自己的猫。毕竟爱情跟书写都需要适时地留白”的狗P文章,我完全可以写个长篇大论意见完全相反的发表出来。--7留言2016年4月12日 (二) 13:23 (UTC)
即使可能造成页面闪烁仍然希望有pangu.js之类的小工具。大面积排版闪烁应该不至于(浏览器对 U+0020 还是敢压缩的)。如果有精力的话我可能会考虑移植 https://css.hanzi.co/ (实现上用了span而不是空格字符)。--Altoria2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)
话倒不用说的这么死,好歹上面W大有提出规格文件证明有些是需要空格,而阁下只是印象不该加。--Liaon98 我是废物 2016年4月12日 (二) 13:30 (UTC)
对于W3C草案问题,我觉得可以与他们讨论对草案进行修改(如果觉得加空格不合适的话)--百無一用是書生 () 2016年4月13日 (三) 02:42 (UTC)
W3C的《中文排版需求》还是working draft(草稿),还差三个版本才能成为正式的“推荐标准”,不可迷信。不过国家标准技术研究所的标准倒是可做参考。那个github上的规范,这是个论述还是什么,不清楚它的效力。--Gqqnb留言2016年4月13日 (三) 06:32 (UTC)
W3C CLREQ草案本身基本就是个论述,或者说“中文排版有这么多东西你要能在浏览器里面实现”的需求书。对于日语(JLREQ)、韩语(KLREQ)亦有类似的文档,其中JLREQ我记得风评很不错。我个人认为加空格只能说是个人肉polyfill,只不过大家都用罢了。当然啦,作者里面我至少能叫出两个很明确地支持在纯文本里面加空格的人(于是你可以认为NPOV上面不对劲)……(可以说大部分我看到过的这方面的人日常都顺手加空格,包括我(以至于我上维基百科脑子需要多绕一圈(不要吐槽我的括号层数多(The Jargon File里面有讲这个的地方)))。)--Altoria2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)
所以,根据国家标准技术研究所的规定,当表示数量时,在数字与单位之间必须有一个空格的空距。--老陈留言2016年4月15日 (五) 05:29 (UTC)
该单位规定的是美国、用英文撰写时的格式,是关中文维基啥事?别混淆视听。--泅水大象讦谯☎ 2016年4月15日 (五) 05:32 (UTC)
他山之石,可以攻错。更严格地表述,根据国家标准技术研究所的规定,当表示数量时,在阿拉伯数字与英文单位之间必须有一个空格的空距。--老陈留言2016年4月16日 (六) 05:24 (UTC)
那仍然只定义了数字跟英文单位之间的格式,但是上面的讨论是针对数字、英文与中文之间的格式介面问题,纯英文的格式标准仍然毫无参考价值,不提也罢。--泅水大象讦谯☎ 2016年4月19日 (二) 04:46 (UTC)
这是第一阶段,暂且只能这样。如有任何建议,请多指教,谢谢!--老陈留言2016年4月22日 (五) 00:06 (UTC)
英语的数字和单词之间有空格,不过是因为单词和单词之间有空格,一向是这样写的而已,对汉语没有任何参考价值。英语写任何一句话,中间用标点分隔时也会在标点后方加上空格,这对汉语又有什么意义,如果这种也有参考价值,那完全有理由推论今后每个汉字和汉字之间也要加个空格。所以极力(-)反对。--7留言2016年4月22日 (五) 03:19 (UTC)
谢谢您的意见!难道当您在中文句子里用到英文片语之时,您不会参考英文写法?--老陈留言2016年4月22日 (五) 04:58 (UTC)
那又怎么样,如果是引用一句纯粹的英语,那么按照原文来写就可以,但是,汉语中即便写“15kg”而没有写“15公斤”,这个“kg”也是按汉语处理的,念出来时要么念“15千克”,要么念“15公斤”,不应该念什么“15(字母)k(字母)g”,这说明汉语中已经接受用这两个字母来代替“千克”和“公斤”,并不说明这就是在“引用”英语,而是这两个字母已经成为汉语固有的组成部分。--7留言2016年4月23日 (六) 16:53 (UTC)
支持7的看法。去找个小学生让他读出含有“15kg”的数学题,你会听到他念“十五千克”,而不是“十五可唉鸡”或“十五看老米特”。至少已经是汉语的组成部分,至于是固有的部分、自古以来的部分还是不可分割的部分,先不予置评。--Gqqnb留言2016年4月26日 (二) 00:53 (UTC)
user:Jarodalien[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]这是中国大陆国标GB3100-93[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,不过按道理讲的确不该。——Altoria2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)
请注意在上面提到的中国国家标准中所谓的“单位符号”是指拉丁文字基础的外文符号,中文的单位在该文件中称为“单位名称”,言下之意,如果使用的单位是拉丁文字那么数字跟文字之间要插入空格(例如17 kg),但是该规则并没有定义使用中文单位(例如“17公斤”)时要插入空格。--泅水大象讦谯☎ 2016年5月17日 (二) 10:17 (UTC)

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

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

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

个人论述

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

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

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

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

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

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

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

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

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

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

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

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

  1. 中文语境不包括参考文献、模板、表格、数学公式在内。
  2. 按照中国国标GB3100-93[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 特邀专家之一(我全都提到过)。--Artoria2e5 保持页面整洁,直接ping我回复 2016年6月10日 (五) 21:33 (UTC)
(:)回应,这是个商业软体,不清楚这跟当今的讨论有甚么关系?--老陈留言2016年6月13日 (一) 07:03 (UTC)
但是授权是用MIT自由授权的。--Emphrase留言2016年7月1日 (五) 03:39 (UTC)

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

JavaScript就是解决方法之一,如果社群允许0.1秒的页面重绘。另一个办法是修改MediaWiki源代码,这更强大也更危险。--Gqqnb留言2016年6月15日 (三) 05:05 (UTC)
user:Liangent[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]在英文维基里,MediaWiki软体会自动处理空格的渲染。理论而言,源码可以有任意数量的空格。这给予了编辑者在编辑源码时很大的弹性,促进源码的可读性。在中文维基里,假若,我们过度硬性规范空格数量,则会影响源码的可读性。至于有关MediaWiki软体如何处理空格的渲染这方面的问题,可能需要请教才女,她是这方面的专家。
空格的渲染涉及到艺术美观问题。例如,第i个字、第 i 个字,这两种由于空格的置入与否会产生的不同的渲染效果,前者显示出英文字母紧紧地挤在“第”与“个”两个字之间,使用手机阅读很可能会忽略掉这个英文字母,后者则较为明显地展现出英文字母 Bluedeck在前面也举出另外一个例子。这些例子都展示出,我们不应随便禁止置入空格。--老陈留言2016年6月15日 (三) 06:11 (UTC)
  • 我觉得编辑工具栏可以添加一个按钮,自动在全文或者选中文本的中英文之间添加空格。—John Doe 120talk2016年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 120talk2016年7月1日 (五) 05:13 (UTC)

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

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

@Yel D'ohan: 感觉应该分情况讨论。对于国民党,本人认为英文非首要且增添信息有限,但考虑到其在官方网站亦明显注明之,可以考虑添加,不添加亦可;至于唐凤,由于其有另一通行称呼(Audrey Tang),与其本名显著不同,应当添加。其他东亚或有东亚背景的人物组织,感觉如果没有特别需要,使用汉语名+母语名或纯汉语名即可。--Morningstar1814留言2016年9月8日 (四) 20:37 (UTC)
  1. 使用lang-en等模板标出外文。你看这个Audrey Tang,你怎么确定它是英文、西班牙文还是法文?我先想当然地标注了lang-en,望其它编者指教。
  2. 标注外文的争议在维基百科长年存在,如联合国,阿拉伯文、中文、英文、法文、俄文、西班牙文都可以标。海牙国际法庭,它标了法文,为什么不标英文?它属于联合国,为什么不标阿拉伯文?甚至台北上海苹果都可以标外文。跟废派相比,挺英派(挺外派)总是比较多。--Gqqnb留言2016年9月13日 (二) 02:25 (UTC)
@Gqqnb:Audrey Tang个人想当然地猜测为英文,当然若有相关来源表明其自称为“英文名”更好,不过要是我我可能会比较懒惰地在某些地方使用{{lang|en|Audrey Tang}},语言不自动显示,直至有来源再修改。
联合国标注所有官方语言均可,海牙国际法庭个人不了解具体状况(但其官方网站仅使用英文和法文)——但包括国际刑事法院在内的许多国际组织根据传统都将英文与法文列为工作语言。若有来源支持(不知大英百科等是否列出两种表达),应该按来源加入。
完全无法理解为何上海苹果需要标注英文……至于台北,因其采用威妥玛拼音,与通用拼音法不同,但在国际及当地机构亦时常使用,可以作为有用的额外信息添加进去,不过要留在正文“名称”章节问题也不大(如“Canton”作为广州的前英文称呼自然是留到此段落)。
感觉挺英和废英的存在及分歧有些滑稽——照理来说应当分条目和内容讨论的,很难搞大规模采用或废止……--Morningstar1814留言2016年9月13日 (二) 22:37 (UTC)
“香港中文大学(英文:The Chinese University of Hong Kong;缩写:CUHK),简称中大[注 1],是一所……”香港中文大学无疑是“华人或东亚的组织”,不过主要教学语言是英文。还有Template:香港特别行政区政府组织架构的各个香港特别行政区政府部门和机构条目基本上全部都加上其英文名称。--Mewaqua留言2016年9月13日 (二) 02:37 (UTC)
个人认为应该以其官方网站的可选择语言为可附加基准。例如“联合国官网”一共有6种语言被官网使用(不计简繁)(不计不同地区使用方法不同),编者可以在6种语言中选择性使用————だ*ぜ留言2017年7月13日 (四) 09:15 (UTC)

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

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

(:)回应在下以为是在讨论重定向 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)
模版中若有几个中文条目尚未建立的连结,也许可以再列一下英文名称,可是若中文条目已建立,不太建议所有条目(或大部份条目)都加上英文名称。若所有连结加上英文,会大幅增加模版的篇幅,而且大家会看到模版中的大部份会是英文,降低可读性。--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)

回应
  1. 导航模板我的看法是要看会不会影响导航的效果。如果加了之后能让人不会错连到中文很混淆的专有名词,我暂时想不到例子,但有些医学用语的确在译成中文后会长得差不多,专业人员不看原文也不知道分别是什么。
  2. 主要是针对条目内文,导航模板因为很明显只是导航功能,不是用来说明内容,附缩写即可。
  3. 你想像的内容已经有标注外语了啊,就是这个“老子(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:格式手册#空格

现行条文
提议条文
本讨论已经结束。请不要对这个存档做任何编辑。

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

《格式手册》小修改通知

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

鄙人觉得修正两个内部链接属于不涉及对方针本身的修改,如有不妥,还请u:CopperSulfate赐教。ïMark | 批判一番 2018年6月24日 (日) 09:49 (UTC)
@Markove抱歉,没看见这个 囧rz……(+)支持此次修改。--相信友谊就是魔法User:萌得不能再萌CuSO4正在努力提高知识水平 2018年6月24日 (日) 09:56 (UTC)

提议大幅修订格式手册

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

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

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

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

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

  • 倒是讲个古。我知道中文维基有一票人,很爱更改“参见”和“参考资料”的位置,特别是要把“参见”放在最后方。根据我在2014年的手动调查,在经过有人特地以机器人方式更改、及部分维基人坚持特定格式,这种格式仍然只占6%的特色条目及11%的优良条目。至于在经过一段有人迳自定调的时期,及中文维基很久没管以机器人模式修改顺序的事情,不知道情况如何了。--KOKUYO留言2018年9月15日 (六) 05:15 (UTC)
Opky9407KOKUYO君就“参见”和“参考资料”的顺序问题,进行了坦诚而详尽的讨论,尽管这与本讨论的核心问题相关度稍低,但相信之后在条目结构方针的修改中将会很有价值
  • 参考注释才是向读者提供附言,像是台风条目如台风山竹 (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%)
  • 其实不太想再吵这个问题,相关条目在不同范畴各自有自己的考虑理由,而列出的条目选择要求也有不同,不能像上面拿着政治人物类条目和台风类条目来比较再来统一结论。还有数量是无意义的,量多就是正确?我在澳门街道专题定立的排版法其实也不是“常用”,衹按照条目内容相关纹理逻辑来订定,相关条目的选取也不会选得直接,结果在参评的时候都没有引起反弹。所以各范畴各取所需,强求统一从过往执行的经验来看不见得是好事。--街燈電箱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)
顺带一个建议,是否叫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)
  • 回到入口还是要(-)反对,对于新手,现在的页面列举了一些很基本的示范,有助新手轻易对格式上手,但是新版却复杂许多,所谓的分编的条理确实也很难理解,根本面对不了新手作为入口。那么宁可维持现状。--Opky9407留言2018年9月18日 (二) 12:41 (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)

外文粗体

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

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

建议修订

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

现行条文

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

提议条文
外文粗体

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

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

则该名称可根据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:格式手册/文字格式规定,除非该本语言名字出现在条目定义句中,并且是其在中文维基百科所属条目的现行名称或其未有中文版本的常用别名在中文环境中的最常用版本,否则不可为该本语言名字加粗。样式如下:

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)

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

以下是我的综合意见:

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

谢谢。--ClitheringMMXIX 2019年4月25日 (四) 15:44 (UTC)

    • @Clithering:c那部分阁下错重点了,重点只在外语粗体,外语人名是否汉化并非重点;既然样式统一,则只留一例更宜。b那部分届时可直接事实性修订。Σανμοσα y=0 regardless the value of x 2019年4月26日 (五) 10:44 (UTC)
        • 谢谢你的回应,我当初认为两个例子都应该保留,是因为一个例子是汉化译名,另一个不是;而一个有爵位,另一个没有。两个例子并存,可让读者知道不同情况下的外文所有部份皆无需加粗。不过,我察觉到现在“费雯丽”的例子好像改了,但改得不太合适。其一:她的头衔是“奥利花爵士夫人”,不是“奥利花男爵夫人”;其二:根据社群共识,名称应作“奥利花爵士夫人费雯丽”,而不是把爵位置于名称之后。同时,“费雯丽”另一译名是“慧云李”;“奥利花”另一译名是“奥立维耶”。如是观之,“费雯丽”这个例子过于复杂,不应采用。如要引用一个较简明直接的汉化译名例子显示外文姓名无需加粗,我建议可用魏璐诗。--ClitheringMMXIX 2019年4月29日 (一) 15:27 (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”,分明就是矫枉过正。再者,环顾其他语文版本的维基百科,也不见有类似需要和安排。按照外文粗体如此有用的说法,岂不是回归基本赞成全面的外文粗体?又应否连中文也要显示为“联合国”?--ClitheringMMXIX 2019年4月26日 (五) 05:06 (UTC)
我认为这种标注一来不太美观(有点眼花,网页亲和力也不佳),二来很容易原创研究——绝大多数都没有脚注印证缩写法,可能不少是第一印象标注,有些还有争议或谬误。而如果有来源具体讲过缩写法,那就值得写入正文章节。--YFdyh000留言2019年4月26日 (五) 14:39 (UTC)

恢复公示

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


(请继续在横线上方讨论)

  • 以下重新张贴公示内容:(c、d之修订已完成,但不作为指引)

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

现行条文

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

提议条文
外文粗体

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

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

则该名称可根据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)

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

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

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

以上是个人的愚见,还望先进赐教。附知@H2NCH2COOHLongway22SCP-2000Milkypine和平至上、@ViztorHuangsijun17KirkLUHamishOuiOK、@BaomiUjuiUjuMandanSanmosaEricliu1912游蛇脱壳、@Jacky CheungWQL⼥⼉Rowingbohe行到水穷处、@ATStreetDeckYFdyh000Classy MelissaTimWu007并一并附知未参与讨论串的地区类条目主要编者@瑞丽江的河水NggulsTheodore XuA635683851。--BoyuZhang1998留言2019年10月25日 (五) 05:30 (UTC)

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


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

说明:该投票大致上同意不在中国大陆地方的条目列出外文(如果某地为民族自治地方或属于某民族自治地方,相关民族自治地方的民族所使用的语文的名称不视为此建议中的投票所指的外语,有如新疆维吾尔自治区及其下辖政区的维吾尔语名、延边朝鲜族自治州及其下辖政区的中国朝鲜语名等)及其他汉语拼音,惟其中有一定意见认为可列出邮政式拼音,故在此对BoyuZhang1998提案提出以下修正:
  • 方案仅适用于中国大陆地方的条目;
  • 所有拼音归入Infobox Chinese处理;
  • 特殊外文同上,除非其为邮政式拼音;
  • 邮政式拼音允许置于条目导言,惟须有来源证明;
以上。我个人不太想动台湾地方的条目,故不建议台湾地方的条目适用;港澳地方的条目没甚么可以动的。Sanmosa 灾难固首发于荃湾 2019年11月8日 (五) 05:09 (UTC)
我不知道对中国大陆做这个特殊化规定的意义在哪里?如果是大中华地区,或许还有些意义--百無一用是書生 () 2019年11月8日 (五) 07:25 (UTC)
因为港澳台地方的条目从来不会产生如此争议,那些维持现状即可。是中国大陆地方的条目大家才吵得那么僵。Sanmosa 灾难固首发于荃湾 2019年11月8日 (五) 09:07 (UTC)
邮政式拼音应该是和标准语发音差异较大的可列出,否则不应列出。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2019年11月8日 (五) 14:36 (UTC)

让大家讨论一下

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

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

以上。Sanmosa 灾难固首发于荃湾 2019年11月13日 (三) 02:07 (UTC)

  • 完全反对这两个方案。两个方案都没有尊重少数民族地区的民族区域自治规定的法定语言权利,前者还对中国语言地名的外语翻译(如邮政式拼音)感兴趣,是典型的不自重。--146.96.147.137留言2019年11月13日 (三) 02:13 (UTC)
  • 方案C:
    • 中国语言(yuyan)、方言(tonguage)和土语(dialect),归入首段和Infobox的明显位置处理:
      1. 该方言(也包含蒙古语方言、苗语方言等)或语言在当地分布广泛;
      2. 汉语地名的语源为该语言;
    • 一切外文归入文章内容以及infobox的次要位置处理,以下情况例外:
      香港英语、澳门葡萄牙语、台湾西班牙语和荷兰语如为汉语地名语源,应比照中国语言处理。
    • 对于以上列出的语言、方言和土语,在中国大陆且存在汉语拼音字母(包含汉藏维哈柯)或闽南拼音字母的,一并列出,其余可选择列IPA;港澳列出粤拼和疍家话IPA等;台湾列出南岛语拉丁名称、汉语拼音和其他方言(闽客)的通用拼音。

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

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

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

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

  1. 方案一:完全按照官方语言处理:
    比如南非有11种官方语言,首段和信息框列出11种;
    比如玻利维亚有三十余种官方语言,首段和信息框列出三十余种;
    比如“中华民国”有百余种官方语言,首段和信息框列出百余种;
    比如“中华人民共和国”没有官方语言,首段和信息框不列出,尽管人民币上印着五种语言;
    • 缺陷:不实际,一些刷存在感的地区可以添加上千种官方语言,最后谁吼的声音大谁的语言就能被列出。
  2. 方案二:不考虑“语言的官方地位”等形式上的称号,考察实际使用,凡一语言在该地区、聚落有两成人口使用,即可添加:
    佛罗伦萨不添加拉丁语;
    东帝汶澳门不添加葡萄牙语
    南平市作为聚落是官话区,不添加闽北语
    嘉义市嘉义县不添加更正:不添加邹语);
    里昂作为聚落是法语区,不添加法兰克-普罗旺斯语
  3. 方案三:如下语言可以添加:
    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)
我在上面有说明方言(包括但不限于汉语、中国少数民族语言,其实就是世界通用)地名的处理方式。至于地名以外的处理方式应该不属于讨论范畴,应该因时制宜处理(以“母汤”为例,其语源是闽南语的“毋通”,如果“母汤”有关注度,相关来源应该提及它的语源,那样在导言列举闽南语名就非常适合)。ꓢꓯꓠꓟꓳꓢꓮ 灾难固首发于荃湾 2019年11月30日 (六) 07:20 (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:格式手册添加例子

现行条文

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

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

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

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

提议条文

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

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

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

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

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

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

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

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

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

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

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

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

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

现行条文

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

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

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

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

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

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

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

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

提议条文

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

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

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

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

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

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

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

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

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

建议在和文章内文一致的例外的场合中加入专有名词(公司名称等)。--【和平至上】反对美国各地警方以过度武力镇压和平示威者💬 2020年6月28日 (日) 11:16 (UTC)
已完成。不过我仍然在想在有地区词转换的情况下,怎么才能用到这一段。--DRIZZLE (按此给我留言 2020年6月28日 (日) 12:52 (UTC)
DrizzleD建议把“如果一个叫法被用作条目标题,其他的叫法应有重定向到该条目”和“在内文的用词一致性尚未建立时,第一个将条目补充至超出小作品篇幅的作者的用词应作为默认的选择”根据现实的情况修改为“如果一个叫法被用作条目标题,其他的叫法如果本身没有歧义,则应有重定向到该条目”和“在内文的用词一致性尚未建立时,除非另有共识规定,否则第一个将条目补充至超出小作品篇幅的作者的用词应作为默认的选择”。ꓢꓯꓠꓟꓳꓢꓮ 试问卷帘人却道海棠依旧 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)
DrizzleD依照上述提议代为修改提案。ꓢꓯꓠꓟꓳꓢꓮ 他从不挣扎 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)

用浪纹线表示范围

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

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

现行条文

对于日期段当中,应使用全角连字符“-”(Unicode:U+FF0D)连接,如:

  • 1906年-1967年10月17日

不要使用浪纹:

  • ~、~

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

提议条文

对于日期段当中,应使用全角连字符“-”(Unicode:U+FF0D)或浪纹线“~”连接,如:

  • 1906年-1967年10月17日

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

现行条文

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

提议条文

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

现行条文

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

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

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

以上--Yel D'ohan留言2020年10月7日 (三) 23:11 (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)
其实是从来都没有那个章节吧。SANMOSA SPQR 2020年12月2日 (三) 06:43 (UTC)
现行条文
提议条文

滚动列表与折叠元素

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

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

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

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

备注

  1. ^ 见每月底更新的页面访问量统计。该统计仅计算页面点击量;事实上大多数读者在一定时间内使用过移动设备访问维基百科。
  2. ^ 可将网址中的zh.wikipedia.org替换为zh.m.wikipedia.org后加载新网址访问移动版页面。在移动设备上访问桌面版页面无助于评估移动页面显示问题,但可用于诊断平板电脑等设备上的亲和力问题。
  3. ^ 如上文所述,切换显示或隐藏状态需要CSS与JavaScript。即便设备支持上述功能,移动版服务器会自动去除隐藏内容。Google于2016年在印度和印度尼西亚为低带宽用户提供精简版页面,该服务会去除导航框和隐藏内容。Google还计划在其他国家地区提供该服务。 [1] [2]
  4. ^ 导致此问题的CSS类包括并不限于:amboxnavboxvertical-navboxtopiconmetadatanomobilecollapsedmw-collapsedautocollapse(触发时)。
翻译自en:Special:PermaLink/991894520#Scrolling lists and collapsible content。-Mys_721tx留言2020年12月2日 (三) 19:12 (UTC)
初步略看,仅有地区词问题,反正目标页有字词转换,可以(+)支持SANMOSA SPQR 2020年12月2日 (三) 23:22 (UTC)
顺便也吐槽一下站内那些主要内容都完全被折叠的年号列表,最近处理日本年号列表分拆的事情的时候,竟然还有人跳出来说大小上已经过长且严重滥用折叠的中国年号列表是年号列表条目的典范,结果我分拆出来的列表都能够FL。虽然折叠在现时并没有一个规范,但是一向的惯例都是不能够折叠得太多(最好没有折叠)。SANMOSA SPQR 2020年12月2日 (三) 23:42 (UTC)
Sanmosa曾经我有想过把中国年号列表分拆出来,但感觉没什么很详细的资料可以加上。对,我离题了。—玮玮 · 嘎嘎 · 嘎嘎嘎 2020年12月3日 (四) 02:42 (UTC)
我觉得如果目标不是FL的话,直接分拆是没问题的。SANMOSA SPQR 2020年12月3日 (四) 02:46 (UTC)
"内容"两字重复太多了,应当修改一下。-Mys_721tx留言2020年12月3日 (四) 00:15 (UTC)
我先稍代作调整。SANMOSA SPQR 2020年12月3日 (四) 05:45 (UTC)
"若干其他CSS类在人工加入条目或有模板引入时也会导致移动用户无法访问页面"这一点用页面不恰当。此处带相关标签的内容会被移动版服务器移除,而非导致整个页面不可见。-Mys_721tx留言2020年12月3日 (四) 08:22 (UTC)
完成SANMOSA SPQR 2020年12月3日 (四) 08:56 (UTC)
(+)支持作指引,未见明显不妥。collapsible那段拗口、不好懂,“除下列允许情况外collapsed、mw-collapsed、autocollapse状态……”如何断句。--YFdyh000留言2020年12月4日 (五) 08:51 (UTC)
@YFdyh000:我再改一改。SANMOSA SPQR 2020年12月4日 (五) 09:54 (UTC)
@SanmosaYFdyh000:未见反对意见,11日应可开始公示。-Mys_721tx留言2020年12月9日 (三) 16:14 (UTC)
开始公示。-Mys_721tx留言2020年12月12日 (六) 03:18 (UTC)

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