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

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

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

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


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

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

公告板

空格[编辑]

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

  • (-)反对反對中文與英文之間加入空格,應維持原本的格式,格式統一整齊才是重點。如果以個人感官來說,我覺得加了這些空格反而顯得版面混亂,所以這是個人審美與習慣問題,加空格並沒有絕對的幫助。--泅水大象訐譙☎ 2016年3月22日 (二) 06:39 (UTC)
  • (!)意見,這很明顯是講中文字與中文字之間,中文文句的文法裏本來就沒有空格這回事,把一句長句作適當的區分是用逗號而不是空格,用空格違反了標準文法。而中文以外的部份,則應以常識來決定各個案例與特例是否應該加入,反而不應該在手冊裏做提議統一要不要加空格。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月22日 (二) 06:51 (UTC)
    • 他的問題應該是針對中文與英文之間的介面部分,至於標點符號與中文之間的空格就更不可行了。--泅水大象訐譙☎ 2016年3月22日 (二) 09:57 (UTC)
      • 他問:「請問這是否只是指中文與中文之間?」我答:「這很明顯是講中文字與中文字之間」。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月22日 (二) 10:00 (UTC)
        • 哈,誤會誤會,原來你講的是他針對格式規則的原發問,而我講的是他的主張,雞同鴨講了。--泅水大象訐譙☎ 2016年3月22日 (二) 10:28 (UTC)
  • 首先中文文法不需要在字词之间添加空格;其次由于模板等的字段的空格在被解释器处理时会被过滤掉,所以空格才不会显现。——路过围观的Sakamotosan 2016年3月22日 (二) 07:15 (UTC)
  • 量子諧振子為例,User:Πrate的傀儡用自動化工具刪掉半形空格後,在「一個質量為m的粒子」就已經有字體輕微重疊的現象(m是斜體),同一條目的其它因為刪掉空格而影響閱讀的例子就不用逐一列出了,眼見為實,尤其是當預設字體為「新細明體」時。--Mewaqua留言) 2016年3月22日 (二) 10:24 (UTC)
    • 所以重點應該是為何內文中要出現斜體,而不是空格的問題吧?之前已經有過其他討論,認為英文維基中對於拉丁文或專有名詞所做的斜體處理,不該直接沿用到中文維基。還有,字間距我記得可以利用CSS的方式調整,每個人都有各自習慣的版面安排。--泅水大象訐譙☎ 2016年3月22日 (二) 10:32 (UTC)
      • 我無記錯的話,數學代數裏正常字體和斜體是有不同意思的:正常字體表示常數和函數名稱,斜體字母則表示變數,例如:cos x;而「一個質量為m的粒子」的m應該是變數所以用斜體,不過在我這裏「m」和「的」之間沒有重疊,我這邊配置了拉丁字母用Arial而中文用XP版新細明體。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月22日 (二) 12:13 (UTC)
        • 找到一些會造成顯示錯誤的例子:X粒子、Y粒子、Z粒子、X0粒子、Y0粒子、Z0粒子。英文維基並沒有對空格的置入做出甚麼限制,我們為甚麼要過度規定空格的置入?--老陳留言) 2016年3月23日 (三) 05:35 (UTC)
          • 對於這種情況其實並沒有建議要用抑或不要用空格,還是一句:請按個別情況用常識決定是否加空格。而我這邊顯示「XYZ」和「粒/0」之間衹是少許的緊迫,不覺得對閱讀有很大的妨礙。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月23日 (三) 06:17 (UTC)
老陳君提的例子在我的畫面上完全正常一點都沒有重疊,所以問題的根源還是自己瀏覽器字型設定或CSS造成的。如果真的有很嚴重的顯示問題疑慮時彈性的運用空格或許可以接受,但原開題者顯然是想要求全面性的開放,這問題就嚴重了:如果他覺得空格比較美觀、我覺得空格不美觀,所以不同的人編輯時有不同的格式,搞得整個中文維基格式不統一亂七八糟,更嚴重時還可能因為不同審美與習慣的用戶編輯同一文章時反覆新增或刪除空格導致編輯戰,各位還覺得不規定一個格式原則是好事嗎?還有,英文原本就有標準的空格使用格式,所以根本不需特別在維基百科中規範,但中文與英文字之間的介面並不在標準中文的格式規範中,所以我們才會需要在這裡提出討論,二者狀況不全然相同不該直接類比。--泅水大象訐譙☎ 2016年3月23日 (三) 06:21 (UTC)
敝人還是覺得不應該有標準,單是我本人加不加空格就已經很多不同的處理方法,比如說:如果中文字後面接着一個英文單字的話,我通常不會空,但是如果是接一組英文片語或句子的話,則通常會有空……還有許多層出不窮的情況令我施加變化,許多時候甚至要看正文表述了甚麼內容才得以決定值不值得加空格。所以還是維持現有的自由度,統一建議我完全也不見得是好事,尤其是某一條目用不用空格的做法又未必適合用到另一條目的時候。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月23日 (三) 06:42 (UTC)
那也是建立在電箱君大體上是瞭解中文維基基本的格式規則、只是在必要時略作調整,跟整個不訂定格式準則隨各人喜好發揮是兩回事。中文維基有些軍事或汽車相關的條目,當初編輯的用戶是直接拿英文維基條目的內容copy & paste過來之後逐字中譯,所以會留下跟英文一樣的字間空格等「遺跡」,整個條目看起來就是像狗啃過一樣東一塊白西一塊缺,完全無法體會其中的美感何在,只給人一種整體品質低落的印象。中文維基還是應該有一個基本的格式規範定義大部分情況下的版面撰寫方式,再保留必要時個案調整或討論的空間,而不是完全不設格式標準,這是完全不同的兩種狀況。--泅水大象訐譙☎ 2016年3月23日 (三) 06:58 (UTC)
定下建議理應是衹有很少量的例外情況,但是關鍵是在這個空格的問題上無論我建議要有空格還是不要有空格,我預視到都會出現大量的例外,即不存在所謂的大部分情況都適用的方法,所以就算訂定了也不會有意思。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月23日 (三) 07:11 (UTC)
我倒是抱持著不太一樣的看法,我認為如果有訂定原則但允許在需要時例外,乍看之下似乎與沒訂定原則一樣,但實際上意義不同。因為這表示若想要有例外就必須要提供必要性的證明,如無特殊必要還是要回歸標準格式,萬一有天真的有兩名用戶因為要不要加空格而發生爭議時,我們就可以根據該空格的添加是否有功能上的必要性來作為衡量的依據,而不會因為無規則來源可供判斷而陷入意氣之爭。別說我杞人憂天這時就在思考編輯戰之類的情況,事實是多年下來的經驗告訴我們就是這種事最容易導致編輯戰,所以我這是在未雨綢繆。--泅水大象訐譙☎ 2016年3月23日 (三) 07:32 (UTC)

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

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

一般而言,原始碼的空格顯示問題可以由MediaWiki軟件處理,如果MediaWiki軟件可以處理這問題,為什麼要強硬規定編輯者怎樣置入空格?在原始碼內適當地置入空格可以幫助閱讀與維持原始碼,除去這些空格,則原始碼會變得像古文一般地難讀難懂。我們應該幫助編輯者進行編譯的工作,而不是設定規則要求他們做一些「軟件可以做的工作」。--老陳留言) 2016年3月23日 (三) 22:36 (UTC)

我看完上面那段規則後怎覺得英文版的空格輸入規則很嚴格?裡面用了「never」「unless」這種語氣很強烈的字眼,明確規定分號、逗號、句號前面「絕對」不能加空格,這些符號後面除非緊接括號括號否則「一定」要加空格(原句用動詞原形「Put」起頭,表示是強命令句型)。最後面那段是在說因為系統會自動壓縮空格,因此用戶可以自行選擇自己喜歡的空格輸入格式(原文是「Multiple spacing "styles"」),言下之意您為了編輯便利輸入單格的空格、雙格的空格或多格的空格顯示結果都一樣,但是輸入空格的「位置」可是有嚴格規定的,並非老陳君所想像與主張,希望能由用戶自行選擇輸入空格「位置」的作法。所以,您舉例英文維基的規則其實正好否決了您自己的提案。--泅水大象訐譙☎ 2016年3月24日 (四) 03:25 (UTC)
謝謝您的關注與意見!希望您翻譯英文時,務必要仔細嚴謹,不能斷章取義:
  1. In normal text(在正常文句裏):這不包括特別案例,例如,模板內的原始碼、數學公式與正常文句之間的界面等等。英文維基沒有對這些特別案例做出規定。
  2. Multiple spacing styles may coexist in the same article(多種空格置入格式可以共存於同一篇文章):請注意到英文單字「coexist」。--老陳留言) 2016年3月24日 (四) 05:34 (UTC)
斷章取義的是您吧?
1. 原文是說in normal text沒錯,但是它並沒有說「模板內的原始碼、數學公式與正常文句之間的界面」可以加空格,那是您自己單方面的衍生解釋,能不能被接受尚有討論空間。
2. coexist的主詞是「spacing styles」(空格的格式),也就是我提過同一條目內空格是要打單字元、雙字元或多字元都沒差,因為系統會自動壓縮調整,但是您的主張其實是在討論空格安插的「位置」,請問原文中何處有說各種不同的安插位置規則可以coexist的?
希望您翻譯英文時,也務必要仔細嚴謹,不該把自己的主張混入對規則的翻譯中。--泅水大象訐譙☎ 2016年3月24日 (四) 06:13 (UTC)
謝謝提醒!我覺得「在中文語境內,文字之間應該不留空格」這句子寫得不夠明確,很容易引起不同的詮釋。因此,我提議改寫為「在中文語境內,中文文字與中文文字之間應該不留空格」。其他論題可以留待以後商討。希望獲得大家共識,不知道您覺得可否這樣改寫?--老陳留言) 2016年3月25日 (五) 05:45 (UTC)
不可以,如果這樣改寫等於變相允許中文與英文字之間可留空格(所謂中文「語境」,就表示包含在中文文章中插入英文字的情況,但排除整句都是外文內容的情況,原規定其實寫得很清楚)。如果要改,還是應該先獲得社群共識後再依照討論結果修正。--泅水大象訐譙☎ 2016年3月25日 (五) 07:16 (UTC)
按照您的說法,為了避免爭議,我提議將這句子改寫為「在中文句子內,中文文字與中文文字之間應該不留空格」。--老陳留言) 2016年3月26日 (六) 14:10 (UTC)
(:)回應原文中的中文「語境」原本就是泛指以中文作為主體,只是局部插入外文字的情況,包括中文與中文字之間,也包含中文與外文字體之間,僅有全段皆為非中文(也就是外文語境)的狀態下允許插入空格。所以,您這樣的狹義定義乍看之下好像是要把規定解釋清楚,但實際上根本是暗渡陳倉把您的主張混入規則中,是很不妥的作法。如果您想要自己的主張被實現就請等討論流程完成之後再說,但很顯然一路看下來支持您主張的用戶僅屬少數。--泅水大象訐譙☎ 2016年3月28日 (一) 05:26 (UTC)
從2010年至今,與User:Πrate和其傀儡為了一個空格而發生爭執的用戶顯然不是少數(例如User:ArikamaI),Wikipedia:五大支柱:「維基百科不墨守成規: 維基百科制定有方針與指引,但並非板上釘釘不可更改,其內容和解釋可以逐漸發展完善。它所蘊含的原則和精神比字面措辭更為重要,並且有時為了改善維基百科允許有例外。」--Mewaqua留言) 2016年3月28日 (一) 05:38 (UTC)
又加一個例子,User:Πrate的傀儡在眾多條目的參考文獻裡刪掉新聞標題中用作分隔句子的space(例如聖人瀑布,如把「開放聖人瀑布 溪山里民疾呼」改成「開放聖人瀑布溪山里民疾呼」),增加閱讀上的不便。--Mewaqua留言) 2016年3月28日 (一) 05:53 (UTC)
參考文獻非主文本就不在格式手冊規定的範圍,直接依照文獻來源原本的格式也屬合理。M君舉的例子正證明了相關的格式規則還是要訂以避免編輯戰的可能,但規則若有不恰當之處隨時都可提出檢討修改,或在必要時彈性調整,但給編輯用戶一個基本的遵循依歸還是很重要的。--泅水大象訐譙☎ 2016年3月28日 (一) 06:11 (UTC)
從英文維基輸入至中文維基的參考文獻與模板,其內部遍布了很多空格,這是為了使得原始碼易讀易懂,MediaWiki軟件會自動處理這些空格。請問您是否贊成允許空格在參考文獻內存在?請問您是否贊成允許空格在模板內存在?--老陳留言) 2016年3月30日 (三) 00:33 (UTC)
這跟英文維基無關,系統處理模版時原本就會忽略掉文字(無論中文英文)前後的空格,但不會忽略文字與文字間的空格,但是閣下明明在講的就是在文字與文字(例如中文與英文字母間的介面)插入空格的主張,且明明討論的就是主文部分,為何老是拿不相干的事情來混淆視聽?--泅水大象訐譙☎ 2016年3月30日 (三) 06:36 (UTC)
一個條目不只是只有主文部分,它還包括條目名、主文、標題、參考文獻、模板等等。所以,您不反對在參考文獻、模板內的空格可以存在。--老陳留言) 2016年3月31日 (四) 22:15 (UTC)
不會實際在畫面中顯示出效果的空格我不在意,參考文獻中的title欄位原本就是用來顯示原文,因此比照原文格式也是合理,其他部分請遵守格式守則。--泅水大象訐譙☎ 2016年4月1日 (五) 02:51 (UTC)
很高興能夠達成共識:-)!--老陳留言) 2016年4月1日 (五) 22:34 (UTC)
  • (-)反对中文與英文之間加入空格。--喜歡用IRCCarrotkit 2016年3月26日 (六) 12:39 (UTC)
  • 謝謝表達您的意見!尚未到投票階段。是否可以給出反對理由?--老陳留言) 2016年3月27日 (日) 22:11 (UTC)
  • (-)反对在任何地方加不必要的空格,包括中英文之间。--Antigng留言) 2016年3月27日 (日) 06:29 (UTC)
  • 謝謝表達您的意見!尚未到投票階段。可否詳細指出,甚麼是必要,甚麼是不必要?--老陳留言) 2016年3月27日 (日) 22:11 (UTC)

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

那为什么斜体后面就不能用JS/CSS加……--Jimmy Xu 2016年3月28日 (一) 00:41 (UTC)
很有趣的是「Y0」這個狀況並不是該利用空格修正格式的好場合,因為如果在斜體字後方加空格來修正,雖然原本有字體重疊問題的用戶看到的畫面正常了,但原本顯示很正常的用戶,卻反而會看到「Y」跟「0」之間被明顯拉開看起來不太像指數符號的情況。若要修正這問題,使用CSS調整恐怕才是治本的方法。--泅水大象訐譙☎ 2016年3月29日 (二) 04:19 (UTC)
{{Lang|en|''Y''<sup>0</sup>}},顯示為Y0。--Mewaqua留言) 2016年3月30日 (三) 02:09 (UTC)
所以意思是說其實斜體後面的文字重疊問題,用lang模版就能解決?(在我所使用的瀏覽器/字碼版本上有沒有加lang的顯示效果一模一樣,所以無法分辨)--泅水大象訐譙☎ 2016年3月30日 (三) 06:38 (UTC)
可是我這裡看這樣也會重疊?(雖然感覺沒那麼重疊,但是可能是因為文字較粗造成的錯覺)-和平、奮鬥、救地球!於 2016年3月31日 (四) 04:30 (UTC)
不就是说明了可以通过CSS(或者HTML标签渲染机制)来解决?{{lang}}只是将相应语句用带有lang属性的span包裹,然后让浏览器根据语言来推断字体库,有些字体库能支持斜体字符不覆盖,有些字体库不能。——路过围观的Sakamotosan 2016年4月1日 (五) 01:03 (UTC)
我的发言欠缺考虑,我同意Y0是不应使用空格拆分的。Bluedeck 2016年3月31日 (四) 17:26 (UTC)
如果中文和英文之间要增加间距,则用JavaScript或CSS技术性解决,禁止人为在源代码级别加空格。如果中文和数字之间要增加间距,则用JavaScript或CSS技术性解决,禁止人为在源代码级别加空格。如果学习User:Cdip150的做法,中文和英文短语之间不加间距,和英文句子之间增加间距,则用JavaScript或CSS技术性解决,禁止人为在源代码级别加空格。--Gqqnb留言) 2016年4月1日 (五) 07:02 (UTC)
在下面的例子中,我没有在源代码里添加任何空格,CSS在实现中应为JavaScript所加:紧凑型中Condensed Text;疏散型中Scattered Text--Gqqnb留言) 2016年4月1日 (五) 07:09 (UTC)
很有意思的方法,讚!--老陳留言) 2016年4月2日 (六) 06:39 (UTC)
JavaScript與CSS技術屬電腦領域,只有電腦專家懂得怎樣正確操作這種高階技術,普通編輯者只能望洋興嘆,請問是否能夠給出一些普通編輯者能夠容易操作的方法?--老陳留言) 2016年4月3日 (日) 05:04 (UTC)
margin-right不太合适吧,这样源代码就很难看了,还不如一个空格美观。--Nbdd0121留言) 2016年4月5日 (二) 16:40 (UTC)
“CSS在实现中应为JavaScript所加”没有人需要在源代码里手工编写这些代码。--Gqqnb留言) 2016年4月9日 (六) 00:54 (UTC)
@Gqqnb(-)反对 JS会延后加载,这种方法不可避免的会出现页面闪一下。--Nbdd0121留言) 2016年4月9日 (六) 16:05 (UTC)
@Nbdd0121(-)反对,我不知道你对JavaScript或计算机科学的了解有多深,我不想说我计算机科学经历,但现在几乎没有网站不用js,技术问题就可以技术处理。不要一直动源代码的主意。--Gqqnb留言) 2016年4月10日 (日) 20:03 (UTC)
@Gqqnb(:)回應,我也不知道你对JavaScript或计算机科学的了解有多深,但你需要知道MediaWiki的JavaScript是通过ResourceLoader Queue延迟加载的。如果你要通过JavaScript来修改界面样式,那么不可避免的会出现闪烁。如果段落较长,修改margin或者letter-spacing的效应堆加起来甚至会影响整个页面的排版。--XYZ指示物留言) 2016年4月10日 (日) 20:38 (UTC)

(!)意見 我认为这件事需要分情况来看:如果英文是按照中文的语法作为一个名词插入在文中,这种时候应该不加空格;其他情况下,语法联系没有那么紧密的场合,是否添加空格就不需要管的那么严格。另外重叠的情况其实<math>可以很好的解决,可惜维基用的基于图片的<math>难免带来一点麻烦: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的粒子
源代碼:<span style="font-family:'微软雅黑',sans-serif">一个质量为''m''的粒子</span>
用戶2的瀏覽器的結果:一个质量为m的粒子
源代碼:<span style="font-family:Arial,'新細明體',sans-serif">一个质量为''m''的粒子</span>
如果字母m前面加入空格
用戶1的瀏覽器的結果:一个质量为m 的粒子
源代碼:<span style="font-family:'微软雅黑',sans-serif">一个质量为''m'' 的粒子</span>
用戶2的瀏覽器的結果:一个质量为m 的粒子
源代碼:<span style="font-family:Arial,'新細明體',sans-serif">一个质量为''m'' 的粒子</span>
可以看出,“加入空格”給不同用戶帶來的影響不一
CSS letter-spacing我想應用在“m的”這部分文字,效果跟“加入空格”差不多,後者調整的單位是空格,前者的單位很小 - John doe 120留言) 2016年4月23日 (六) 08:26 (UTC)
  • 打開網頁[2],然後右鍵點擊“一个质量为m的粒子”,點擊“Inspect”...發現問題的起源是Vector screen styles...不多說了,下面的代碼從個人的vector.css複製,“預覽”按鈕好像有問題

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

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

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

难道就没人会用LaTeX吗?[编辑]

这是X粒子、Y^0粒子、\Sigma^-粒子?--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)
使用LaTeX已六年,虽然频率不高,我推荐使用英文Wikibooks当LaTeX参考手册,一打开首页就有个大大的LaTeX,属于特色书籍。— Bieraaa 于 世界统一时间 (UTC) 2016年5月26日13时21分 留言

提議修改格式手冊中的空格章節[编辑]

從英文維基輸入至中文維基的參考文獻與模板,其內部遍布了很多空格,這是為了使得原始碼易讀易懂,MediaWiki軟件會自動處理這些空格,所以,按照泅水大象™ 、Mewaqua與我先前達成的共識,我提議,添加一條規則:

  • 在參考文獻、模板內可以保存適當數量的空格。

請大家投票與發表意見,謝謝!--老陳留言) 2016年4月2日 (六) 06:05 (UTC)

多餘,格式手冊針對空格本來就有這麼的規定:「如果官方宣佈的名稱內含有空格,以官方為準。」參考文獻標題是文獻的官方給的,所以它帶有空格本來就已經被允許。還有請不要把討論分開多個山頭,都不知應該在哪裏討論才好。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月2日 (六) 06:21 (UTC)
在格式手冊的空格章節裏表明,「在中文語境內,文字之間應該不留空格」。這規定意味著嚴格限制空格的存在,不只是在標題內而已。我不清楚您對這規定如何詮釋,但我覺得這規定並未給予編輯者足夠的詮釋空間。為了避免有些破壞者利用這規定進行大量刪除空格的無建設性編輯,並在其中夾雜著錯誤編輯,如在聖人瀑布裏的惡性編輯,所以才提議添加規則。關於在哪裏討論才好這問題,我不會堅持己見,請問應該在那裡討論較好?--老陳留言) 2016年4月3日 (日) 00:27 (UTC)
我仍然認為不需要添加,其實我上面說的話本身也有點多餘,因為我是假設該節適用於參考文獻的來跟您說,不過實際是不適用的,因為該節已經說了「在中文語境內」,但參考文獻本身就不是成句話,所以不算是「語境」,繼而如大象兄所說,根本不在格式手冊規定的範圍內。(討論的位置應該在#空格延續,而不是現在這裏另起爐灶)--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月3日 (日) 06:58 (UTC)
已移動討論位置。--老陳留言) 2016年4月4日 (一) 01:37 (UTC)
術語「中文語境」缺乏明確定義。是否應該對於術語「中文語境」給出明確定義?假若中文語境不包括參考文獻在內,那中文語境到底包括甚麼部分在內?--老陳留言) 2016年4月7日 (四) 05:25 (UTC)
聖人瀑布模板内的空格编辑,为非建设性编辑,应避免。“17 公尺”去除空格,符合格式手冊规定。民国纪年的替换我暂保留意见。参考资料里author、title去除空格不正确,这项属于严重错误。--Gqqnb留言) 2016年4月9日 (六) 01:02 (UTC)
按照您的說法,“17 公尺”前面與後面的空格都符合格式手冊規定,只有在“17”與“公尺”之間的空格不符合格式手冊規定;換句話說,中文語境前面與後面的空格都可以存在,只有在中文語境內部不能存在空格。關於中文語境的範疇,中文語境不包括參考文獻、模板、表格在內,而是參考文獻、模板、表格內部包含有中文語境。請問您是否同意這表述?--老陳留言) 2016年4月9日 (六) 05:55 (UTC)
首先明确,我们讨论的是源代码内的空格,还是渲染后的空格。我认为我们讨论的是渲染后的空格。凡是改动在源代码里的、不影响渲染的空格,都属于代码格式,属于“维基源代码规范”或“HTML代码规范”。对于作为模板参数等其他直接输出至页面的空格,区分是否为中文语境。height = ...中的等号之后第一个非空白字符开始为模板参数,所以“17”與“公尺”之間的空格不符合格式手冊規定。而格式手冊规定的是渲染后的页面的格式,而不是源代码格式,所以“17 公尺”前面與後面的空格属于无规范状态(加不加都不影响输出效果),所以我才说是非建设性编辑。我(+)同意參考文獻、模板、表格內部输出为HTML的文本部分(区别于标签)包含有中文語境。<span style = "color : red">17 公尺</span>输出为17 公尺,其中style前后的空格、冒号前后的空格都属于源代码中输出至HTML标签的空格,非格式手册规范的空格,而span的文本为“17 公尺”,是输出为HTML的文本。--Gqqnb留言) 2016年4月10日 (日) 20:23 (UTC)
@Gqqnb:謝謝您對於這論題的仔細分析!
  • 為了避免搞不清楚「空格」到底指的是甚麼,我們應該明確區分原始碼內的空格與渲染後的空格,暫且稱渲染後的空格為空距,因為渲染程序最後會展示出多少空白是決定於渲染軟件的輸入參數。按照您的說法,原始碼內的空格安置是屬於「維基原始碼規範」,而渲染後的空距是屬於格式手冊規範。請問我這樣表述是否符合您的說法?
  • 關於您所提到的文本問題,我不清楚「文本」指的是甚麼?所以無法明確表達我的意見。
  • 關於「17公尺」的問題,假設在原始碼內,「17」與「公尺」之間是否可以有空格屬於「維基原始碼規範」,不屬於格式手冊規範;在渲染之後「17」與「公尺」之間是否可以有空距屬於屬於格式手冊規範。請問您是否同意這說法?--老陳留言) 2016年4月13日 (三) 05:46 (UTC)
  • @老陳:,(+)同意“源代码内的空格安置是属于“维基源代码规范”,而渲染后的空距是属于格式手册规范。”。
  • 如果你在浏览器页面上右键,选择查看网页源代码(Chrome浏览器用语)/查看源(IE浏览器用语),你会看到类似<html lang="zh-CN" dir="ltr" class="client-nojs"><head><meta charset="UTF-8"/><title>维基百科:互助客栈/方针 - 维基百科,自由的百科全书</title>的内容。“文本”是HTML技术角度的词。这里的大意是“查看HTML源代码”所显示的内容,也不受格式手册规范。
  • (+)同意“假设在源代码内,“17”与“米”之间是否可以有空格属于“维基源代码规范”,不属于格式手册规范;在渲染之后“17”与“米”之间是否可以有空距属于属于格式手册规范”。这就是我表达的意见,即源代码可以有空格但渲染后无空距;或者源代码无空格但通过js或css的帮助,渲染后产生空距。--Gqqnb留言) 2016年4月13日 (三) 06:07 (UTC)
  • (-)反对,反对在数字和汉字,或英语和汉字之间插入空格。反对“13 公斤”,反对“13 kg”,也反对“km / h”,应写成“13公斤”、“13kg”和“km/h”。--7留言) 2016年4月9日 (六) 14:35 (UTC)
謝謝您的意見!希望能夠給出理由,大家集思廣益。我覺得Pityonline推薦的網路文章为什么你们就是不能加个空格呢?相當有閱讀價值,建議您有空時不妨點閱。--老陳留言) 2016年4月10日 (日) 05:47 (UTC)
7 的说法是有道理的,所谓适当留白,至少需要保留一些自有格式,不要改变原义,或造成歧义,亦非一味地为增强可读性与美观性而拙劣地添加不恰当的空格。不过我建议单纯的数字与不包括带 “/” 的中文单位间应该留白,如 13 公斤,3 份等,遇 13kg,13公斤/人,80km/h 这种,数字与右边文字不应留白,但数字左边应该留白。Pityonline留言) 2016年4月10日 (日) 06:09 (UTC)
同样反对“左边留白”,反对“体重 70公斤”,反对“距离 3000公里”,反对“风速 200公里/时”,应写成“体重70公斤”,“距离3000公里”,“风速200公里/时”。--7留言) 2016年4月10日 (日) 16:22 (UTC)
根据国际单位标准规定,数字与单位之间应有空格,因此“13 kg”是正确写法,这也是绝大多数学术书籍与期刊采用的做法。至于中文语境,尚未找到相关标准,给出此文供参考。--Wcam留言) 2016年4月10日 (日) 22:57 (UTC)
看了这个,果然留白没什么不妥的,而且 w3c 亦有此说明Pityonline留言) 2016年4月11日 (一) 00:48 (UTC)
同意Jarodalien的意见。中文语境中,传统上并无空格。我看到的专业文献中,也几乎没看到这么做的/要求的。很多时候中英/数字混排当中出现的空白并不是空格,而是排版软件自动优化的结果(所以,增加空白可以考虑,增加空格或其他类似字符反对)--百無一用是書生 () 2016年4月12日 (二) 02:25 (UTC)
如覺得數字與中文字之間要增加空白,應是採用修改CSS的方式全面調整,而不是用人工方式插入空格。所以我同意書生兄所言,別把空白跟空格兩件事搞混了!--泅水大象訐譙☎ 2016年4月12日 (二) 07:19 (UTC)
我现在倾向于添加空白,并且以在源代码中添加空格的形式添加。理由如下
  • 中英文中需要有空白:阅读了一下 Pityonline 给出的 W3C 草案,另查阅了一下相关资料,中英文之间需要有 1/4em 的空白,Word 等排版引擎也早已遵循了这一要求。
  • 不适宜使用 JS 添加:用 JS 添加理论上是可行的,但是如同我上面提到过,用JS添加需要等到 DOM Ready,在这之前页面已经呈现,不可避免地出现闪烁。
  • 尚无纯 CSS 解决方案:纯 CSS 的解决方案需要 CSS Level 4 中的 text-spacing,目前除了 IE 实现了 -ms-text-autospace 以外,其他浏览器不支持该属性,也没有其他纯 CSS 解决方法。
  • W3C 草案中提到可以使用一个西文空格做该空白的代替。
--XYZ指示物留言) 2016年4月12日 (二) 12:52 (UTC)
那么我反对这种手工加空格的做法,就像现实生活中看到这种稿件直接退稿不看一样,看到有这种来参加任何条目评选一概反对。我并不觉得这样更加美观,恰恰相反,觉得更难看。像小时一样,我也从来没有在任何论文看到过这种手动加空格的做法。英语不过是有空格分隔单词的习惯。至于那篇一开头就在下定论搞攻击,说什么“有研究显示,打字的时候不喜欢在中文和英文之间加空格的人,感情路都走得很辛苦,有七成的比例会在 34 岁的时候跟自己不爱的人结婚,而其余三成的人最后只能把遗产留给自己的猫。毕竟爱情跟书写都需要适时地留白”的狗P文章,我完全可以写个长篇大论意见完全相反的发表出来。--7留言) 2016年4月12日 (二) 13:23 (UTC)
即使可能造成页面闪烁仍然希望有pangu.js之类的小工具。大面积排版闪烁应该不至于(浏览器对 U+0020 还是敢压缩的)。如果有精力的话我可能会考虑移植 https://css.hanzi.co/ (实现上用了span而不是空格字符)。--Altoria2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)
話倒不用說的這麼死,好歹上面W大有提出規格文件證明有些是需要空格,而閣下只是印象不該加。--Liaon98 我是廢物 2016年4月12日 (二) 13:30 (UTC)
对于W3C草案问题,我觉得可以与他们讨论对草案进行修改(如果觉得加空格不合适的话)--百無一用是書生 () 2016年4月13日 (三) 02:42 (UTC)
W3C的《中文排版需求》还是working draft(草稿),还差三个版本才能成为正式的“推荐标准”,不可迷信。不过国家标准技术研究所的标准倒是可做参考。那个github上的规范,这是个论述还是什么,不清楚它的效力。--Gqqnb留言) 2016年4月13日 (三) 06:32 (UTC)
W3C CLREQ草案本身基本就是个论述,或者说“中文排版有这么多东西你要能在浏览器里面实现”的需求书。对于日语(JLREQ)、韩语(KLREQ)亦有类似的文档,其中JLREQ我记得风评很不错。我个人认为加空格只能说是个人肉polyfill,只不过大家都用罢了。当然啦,作者里面我至少能叫出两个很明确地支持在纯文本里面加空格的人(于是你可以认为NPOV上面不对劲)……(可以说大部分我看到过的这方面的人日常都顺手加空格,包括我(以至于我上维基百科脑子需要多绕一圈(不要吐槽我的括号层数多(The Jargon File里面有讲这个的地方)))。)--Altoria2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)
所以,根據國家標準技術研究所的規定,當表示數量時,在數字與單位之間必須有一個空格的空距。--老陳留言) 2016年4月15日 (五) 05:29 (UTC)
該單位規定的是美國、用英文撰寫時的格式,是關中文維基啥事?別混淆視聽。--泅水大象訐譙☎ 2016年4月15日 (五) 05:32 (UTC)
他山之石,可以攻錯。更嚴格地表述,根據國家標準技術研究所的規定,當表示數量時,在阿拉伯數字與英文單位之間必須有一個空格的空距。--老陳留言) 2016年4月16日 (六) 05:24 (UTC)
那仍然只定義了數字跟英文單位之間的格式,但是上面的討論是針對數字、英文與中文之間的格式介面問題,純英文的格式標準仍然毫無參考價值,不提也罷。--泅水大象訐譙☎ 2016年4月19日 (二) 04:46 (UTC)
這是第一階段,暫且只能這樣。如有任何建議,請多指教,謝謝!--老陳留言) 2016年4月22日 (五) 00:06 (UTC)
英语的数字和单词之间有空格,不过是因为单词和单词之间有空格,一向是这样写的而已,对汉语没有任何参考价值。英语写任何一句话,中间用标点分隔时也会在标点后方加上空格,这对汉语又有什么意义,如果这种也有参考价值,那完全有理由推论今后每个汉字和汉字之间也要加个空格。所以极力(-)反对。--7留言) 2016年4月22日 (五) 03:19 (UTC)
謝謝您的意見!難道當您在中文句子裏用到英文片語之時,您不會參考英文寫法?--老陳留言) 2016年4月22日 (五) 04:58 (UTC)
那又怎么样,如果是引用一句纯粹的英语,那么按照原文来写就可以,但是,汉语中即便写“15kg”而没有写“15公斤”,这个“kg”也是按汉语处理的,念出来时要么念“15千克”,要么念“15公斤”,不应该念什么“15(字母)k(字母)g”,这说明汉语中已经接受用这两个字母来代替“千克”和“公斤”,并不说明这就是在“引用”英语,而是这两个字母已经成为汉语固有的组成部分。--7留言) 2016年4月23日 (六) 16:53 (UTC)
支持7的看法。去找个小学生让他读出含有“15kg”的数学题,你会听到他念“十五千克”,而不是“十五可唉鸡”或“十五看老米特”。至少已经是汉语的组成部分,至于是固有的部分、自古以来的部分还是不可分割的部分,先不予置评。--Gqqnb留言) 2016年4月26日 (二) 00:53 (UTC)
user:Jarodalien[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]这是中国大陆国标GB3100-93[3],请参考PDF第6页第六节6.2.4,原文引用如下:“单位符号应写在全部数值之后,并与数值间留适当的空隙。”。Bluedeck 2016年5月12日 (四) 00:31 (UTC)
在这样的“适当空隙”有明确定义成“手工加空格”以前,不再进一步回复。--7留言) 2016年5月12日 (四) 01:36 (UTC)
嗯。确实有这个问题。我觉得实际上本国标PDF中所有[我看了的]样例中,对此“适当空隙”的实现,均通过一个英文半角空格完成。Bluedeck 2016年5月12日 (四) 02:35 (UTC)
ps,除此而外,我还有这个考虑。很多式子中的变量是代单位的,比如 F=ma。但情况不一定如此,比如 F=mx m/s^2。在无空隙情况下,后者x和m/s^2糊到一起去,只能通过斜体分辨。当然,这是数学公式的部分,不是中文语境的部分。Bluedeck 2016年5月12日 (四) 02:38 (UTC)
謝謝找到這極具價值的資料!我覺得留一個英文半空格是很好的辦法。--老陳留言) 2016年5月12日 (四) 07:21 (UTC)
支持单位前加空格。别处加空格算是少数我个人喜欢的workaround,不过按道理讲的确不该。——Altoria2e5 更改·工具 2016年5月16日 (一) 11:30 (UTC)
請注意在上面提到的中國國家標準中所謂的「單位符號」是指拉丁文字基礎的外文符號,中文的單位在該文件中稱為「單位名稱」,言下之意,如果使用的單位是拉丁文字那麼數字跟文字之間要插入空格(例如17 kg),但是該規則並沒有定義使用中文單位(例如「17公斤」)時要插入空格。--泅水大象訐譙☎ 2016年5月17日 (二) 10:17 (UTC)

謝謝大家發表的意見與建議!假若沒有更多字句,我想將前面內容加以整理,寫成新版提議,交付投票與進一步討論,以達成共識。--老陳留言) 2016年5月23日 (一) 06:31 (UTC)

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

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

个人论述[编辑]

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

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

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

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

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

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

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

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

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

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

用户组应该可以“删除自己的所对应的用户组”[编辑]

本内容由Stang c于2016年3月31日 (四) 06:29 (UTC)分拆。

(!)意見:如果這麼說的話,其實每個用戶組都應該設有權限「删除自己的所對應的用户组」。--就是他 ☞ Q 「祝我考試順利」「有事請留言 2016年3月20日 (日) 13:39 (UTC)

(:)回應,这是另一个问题啦。--Stang 2016年3月21日 (一) 02:10 (UTC)
@Stang:那麼這個問題是否考慮拎出來再研究?--就是他 ☞ Q 「祝考試順利」「有事請留言」 2016年3月24日 (四) 17:30 (UTC)
@StangCosine02:難道沒看到?--就是他 ☞ Q 「祝考試順利」「有事請留言」 2016年3月26日 (六) 03:34 (UTC)
真没ping到...好了,已分拆。--Stang c 2016年3月31日 (四) 06:29 (UTC)
  • (+)支持:未見其弊。-和平、奮鬥、救地球!於 2016年3月31日 (四) 07:19 (UTC)
  • 没看明白,是不是“允许用户将自己从所拥有的用户组中移除?”,是的话,去技术版说吧。——路过围观的Sakamotosan 2016年3月31日 (四) 08:32 (UTC)
    • 應該只是要徵得社群共識,技術上應無問題。-和平、奮鬥、救地球!於 2016年3月31日 (四) 09:30 (UTC)
      • 閣下說得是巡查員、回退員嗎?--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年3月31日 (四) 09:36 (UTC)
        • @小躍:您可能沒看懂我們說的。我們的意思是說,現在巡查員、回退員、IP封禁豁免者、管理員等等權限並無法自己移除自己的對應權限,例如說現在一位巡查員不能去除自己的巡查員權限。而我們想要解除這個限制,以使一位IP封禁豁免者能自我解除自己的IP封禁豁免權。-和平、奮鬥、救地球!於 2016年3月31日 (四) 09:40 (UTC)
          • (+)支持增設删除自己的所对应的用户组:IP封禁豁免者,原因:若不是IP封禁的區段,可以自行解除權限。其他為(=)中立。--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年3月31日 (四) 09:47 (UTC)
    • 我不知道這是否跟基金會的政策有關?本地行政員現在也不能移除任何人(包括自己)的管理和行政權限。如果涉及基金會,即使中文社群同意,似乎也會很難過關。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月31日 (四) 09:51 (UTC)
      • En行政员可以移除管理员的权限。应该没关系。--Stang c 2016年3月31日 (四) 10:12 (UTC)
行政员当然可以移除管理员呢,还能任免管理员了。说什么大白话。——路过围观的Sakamotosan 2016年4月1日 (五) 00:46 (UTC)
中文維基要移除管理員是要經meta監管員才能做的(例子),行政員仍然衹能授予管理員,不能移除管理員。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月1日 (五) 05:23 (UTC)
搞错了,多谢指点。——路过围观的Sakamotosan 2016年4月1日 (五) 10:07 (UTC)
  • (~)補充:個人認為巡查員回退員IP封禁例外者巡查豁免者大量信息發送者AWB 使用者(注:根據下方兩位的說法 AWB 可能無法實現此功能)都應有權自行撤銷自己所對應的權限。對於管理員等其他人就應單獨討論了。--就是他 ☞ Q 「祝考試順利」「有事請留言2016年3月31日 (四) 13:15 (UTC)2016年4月1日 (五) 11:01 (UTC)
  • AWB的CheckUser那邊需要管理員編輯的權限......--Engle躍名字招牌快來買會動不用錢】 2016年4月1日 (五) 04:48 (UTC)
AWB使用权其实是一个Mediawiki空间页面列表,不属于系统权限范畴,这个估计除了界面编辑员、管理员级外,没人能编辑了。——路过围观的Sakamotosan 2016年4月1日 (五) 10:09 (UTC)
  • (!)意見 按照我对MediaWiki的理解,MediaWiki Core应该没有这个功能,现在的插件也没有提供这个功能。所以是要去写一个插件?(虽然不难写)--Nbdd0121留言) 2016年4月5日 (二) 16:45 (UTC)
@Nbdd0121::技术上MWConfig里的$wgGroupsRemoveFromSelf 是用来控制那些权限用户可以从自己身上移除,详见mw:Manual:$wgGroupsRemoveFromSelf,所以技术上并不需要额外开发。
从1.14版开始提供了一个参数$wgGroupsRemoveFromSelf['group'] = true;可以让设置该用户组的用户可以移除自己身上的所有用户组--南瓜留言 | 贡献) 2016年4月5日 (二) 20:09 (UTC)
谢谢指正,那就没什么问题了--Nbdd0121留言) 2016年4月5日 (二) 20:53 (UTC)

(+)支持允许IP封禁豁免者删除自己的所对应的用户组。--Stang c 2016年4月11日 (一) 02:53 (UTC)

MediaWiki的用户组除了可以提供权限以外还可以用来移除权限,虽然现在没有做这样的设置。请注意Special:UserGroupRights最上方的说明,我们可以建立一个“禁止上传”用户组,凡是加入这个用户组的都被撤销上传权限。如果简单允许用户自行移除用户组那么这种用法就无法实现了。 --达师 - 334 - 554 2016年4月11日 (一) 05:54 (UTC)

是不是需要限定那些用户组允许用户从该用户组移除出去?例如,巡查员、回退员、IP豁免、或者更多。另讨论了这么久,@qinyongr:,从哪里讨论得出需要允许自己能从用户组移除的需求?——路过围观的Sakamotosan 2016年4月11日 (一) 06:57 (UTC)
@Hat600,並不是允許所有的用戶組移除自己的用戶組的,只是巡查员,回退员,IP封禁例外者,巡查豁免者和大量信息发送者罷了(管理員等還在討論中)。--就是他 ☞ Q 「參觀 用戶頁 」「有事請 留言 」 2016年4月11日 (一) 13:53 (UTC)
@cwek,就是當時在討論大量消息發送者的時候提到了臨時發送者,然後呢臨時發送者就是要在一段時間過後自己把自己的權限取消掉,從而就有了這個討論。--就是他 ☞ Q 「參觀 用戶頁 」「有事請 留言 」 2016年4月11日 (一) 13:53 (UTC)
  • 差不多了,能不能提到phab了?-- 給我留言 「歡迎加入 #cvn-zh-scan Qinyongr 2016年4月13日 (三) 10:21 (UTC)
  • 达成什么共识允许什么群组取消自己的权限?--Stang c 2016年4月14日 (四) 09:57 (UTC)
  • 我支持巡查者、回退者、IP封禁豁免者允许自行移除对应的用户组。可以在比较小的程度上减少管理员处理自愿除权的上述用户组用户(比如工作太忙)权限调整的工作。--南瓜留言 | 贡献) 2016年4月18日 (一) 01:23 (UTC)

我覺得這段討論對於「允許IP封禁豁免者刪除自己的所對應的用戶組」應該是有共識了,而「巡查員,回退員,巡查豁免者和大量信息發送者」則也未見反對。 既然再經過超過一週的討論後,未見重大異議,可見社群應已初步達成下列二項共識:

  1. 允許IP封禁豁免者刪除自己的所對應的IP封禁豁免用戶組
  2. 允許巡查員,回退員,巡查豁免者和大量信息發送者刪除自己的所對應的巡查員,回退員,巡查豁免者和大量信息發送者用戶組

現進行公示,一週後如再沒有重大意見,將視為已達成共識,如有意見請速提出。-和平、奮鬥、救地球!留言DC14討論於 2016年4月28日 (四) 08:51 (UTC)

如果有合资格用户申请权限,用一下,自己拿掉,过两天再来申请,用一下,自己拿掉,如此循环……对于这样的善意用户有无必要加以规制?其实目前管理员的flood就是这么一个用法,只是涉及申请的权限可能会不太一样。--Jimmy Xu 2016年5月3日 (二) 03:08 (UTC)
之所以flood组能自行移除就是因为这组本身是个“临时”权限,不应该长期持有;massmessage-sender也可以算进这类(不过也可以说成“社群信任该用户能够善用群发消息功能”)。ipblock-exempt权之前已出现过用户觉得已无用而申请移除,随即发现受到广域封禁影响而再来申请的例子。而patroller、rollbacker等权除了长期不活跃和因故自行请辞(这种情况下走申请反而能够带出一部分冷静期)外,还有其他随意自行移出的必要么?--Jimmy Xu 2016年5月3日 (二) 03:27 (UTC)

補充事項[编辑]

根據User:Stang在IRC上的提醒(本人表示暫時無法上來),現補充二點如果此議案通過後需要連帶做的幾點事項:
  1. 移除申请解除权限的最后一个章节,並於授予ipbe的提示语后加提示
  2. 建议在“用户权限管理”页面加入引导文字
以上。-和平、奮鬥、救地球!留言DC14討論於 2016年4月29日 (五) 12:07 (UTC)
(+)同意(就這個還編輯衝突)--Qinyongr 給我留言 」「歡迎加入 #cvn-zh-scan 2016年4月29日 (五) 12:13 (UTC)
如果用户帐户被入侵,并被入侵者移除权限,此种情况应该如何处理?--百無一用是書生 () 2016年5月3日 (二) 02:32 (UTC)
那應該找管理員把。如果帳戶被入侵,那就證明他自己的帳戶並不安全,那為什麼他仍可以有哪些權限呢?--|1233 | 有問題? 2016年5月3日 (二) 02:42 (UTC)
此情況下應尋求管理員協助,在確認用戶本人已取回帳號控制權之情形下進行復權。另外回覆樓上,前不久才有一位管理員的帳號被盜...-和平、奮鬥、救地球!留言DC14討論於 2016年5月3日 (二) 02:50 (UTC)
Jimmy已经点出一个问题,如果有人申请后自己移除又再立即申请这样玩的话,怎样处理?可能申请的时候需要添加如果自己移除的话规定时间内不得申请,管理员可以根据情节考虑是否再授予,多次如此游戏可能涉及封禁惩罚。——路过围观的Sakamotosan 2016年5月3日 (二) 03:17 (UTC)
这属于WP:GAME行为。--Antigng留言) 2016年5月3日 (二) 04:57 (UTC)
所以上面说good faith的用户来着。比如某用户看到几个他感兴趣的条目需要巡查,就去申请巡查权,然后巡查了这几个的条目,然后觉得用不上就给自己除权了,然后过了几天几个月他又看到几个条目想巡查,就又来申请。你去talk说的话人家完全可以有“我平时都不做这些工作的,留着也没用”的解释,然后来申请权限了要拒绝掉么?--Jimmy Xu 2016年5月3日 (二) 07:25 (UTC)
“比如某用户看到几个他感兴趣的条目需要巡查,就去申请巡查权,然后巡查了这几个的条目,然后觉得用不上就申请解除权限了,然后过了几天几个月他又看到几个条目想巡查,就又来申请。你去talk说的话人家完全可以有‘我平时都不做这些工作的,留着也没用’的解释,然后来申请权限了要拒绝掉么?”--Antigng留言) 2016年5月3日 (二) 07:28 (UTC)
所以上面一段说了,解除权限的流程至少还有个跟用户交流的机会,这样用户直接自己搞定了你再事后去说?--Jimmy Xu 2016年5月3日 (二) 07:34 (UTC)
我也是有空巡然后咸鱼一大会,但不意味我短期不用的话就要自行申请解除。所以我认为如果两次短期快速申撤的话,第三次有理由拒绝,这不是游戏。当然还是保持现有申撤机制是最省力的方案。——路过围观的Sakamotosan 2016年5月4日 (三) 00:45 (UTC)
申請權限時也有跟用户交流的机会。如果是我,該用戶第一次這麼做我會給他,並跟他溝通。如果再持續這樣的話就得考慮一下了。-和平、奮鬥、救地球!留言DC14討論於 2016年5月4日 (三) 10:18 (UTC)
傾向(-)反对巡查員、回退員可自行移除權限,因為在下不知其他人會是怎樣想,一下子是工作忙而請辭權限,一下子突然沒事了就來申請權限,簡直不符合邏輯。對於先前講的傾向(+)支持IP封禁例外的可自行移除權限,對於IP用戶端被封禁一事,有時會影響其他用戶的操作,而他們才會去申請IP封禁例外的權限,若申請時非IP封禁的範圍,自然而然就不會授予此權限,IP封禁例外的反覆申請在下倒是可以接受的。--Engle躍築夢踏實夢想起飛安裝加速投票工具】 2016年5月8日 (日) 02:05 (UTC)
前面不是已經有用戶說了嗎?「如果自己移除的話規定時間內不得申請,管理員可以根據情節考慮是否再授予,多次如此遊戲可能涉及封禁懲罰。」-和平、奮鬥、救地球!留言DC14討論於 2016年5月12日 (四) 00:46 (UTC)
@和平奮鬥救地球:你這個方案又得定義「規定時間」......--Temp3600留言) 2016年5月15日 (日) 06:27 (UTC)
這不麻煩吧。我認為兩個月是合理的時長。不知道各位有沒有什麼意見?-和平、奮鬥、救地球!留言DC14討論於 2016年5月23日 (一) 10:05 (UTC)

提議優特評選排隊制[编辑]

最近的優特評選同時提太多了,其中6+提的最多,優、特合起來就提了十多個,把參與分薄了,討論遠不如幾年前的深入。很多含有錯誤的條目,往往還沒來的及仔細看完,又一批提上來了。無論是新提名或是撤銷都沒有經過充分的審視和討論。

我提議引入早期「質量提升計畫」選條時所用的投票排隊制,設置同時評選的上限,超過這個數就排隊。--Jasonzhuocn留言) 2016年4月11日 (一) 01:27 (UTC)

(+)同意,不知道其他人有沒有什麼想法?-和平、奮鬥、救地球!於 2016年4月16日 (六) 06:55 (UTC)
排队排多少个?Bluedeck 2016年4月16日 (六) 07:33 (UTC)
我認為條目評選沒有經過充分的審視和討論就草草了事的現象,就算條目再少,也不會治本。因為並不是制度出問題,而是群眾的心理質素出問題。除非改為評審制和廢除評選時限。PS. 樓上這個很容易被「遊樂場主義者」亂答啊,他們可以說「五個」,然後又不給出紮實的理據,就看你怎麼奈何。--春卷柯南-發前人所未知 ( ) 2016年4月16日 (六) 09:31 (UTC)
额,虽然这个问题问的不好,可是如果要排队的话,数量这个问题就是不能避免的啊。Bluedeck 2016年4月17日 (日) 03:33 (UTC)
(!)意見,最好能夠對同時評選的同類條目數量加以限制,這樣可以促使優特評選的多元化。--老陳留言) 2016年4月17日 (日) 05:06 (UTC)
(?)疑問:如果如此限制,但其他類別條目提報數量卻甚少,似乎仍不足以達成多元化?-和平、奮鬥、救地球!於 2016年4月18日 (一) 02:38 (UTC)
其实老陈担心的问题应该是连续数天或者几天之内多次被同一类别的优特存档刷屏吧。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年4月18日 (一) 02:43 (UTC)
我會覺得有關"同時評選的同類條目數量加以限制",這一部份另案討論會不會比較好?--Wolfch (留言) 2016年4月18日 (一) 03:27 (UTC)
也可以。-和平、奮鬥、救地球!於 2016年4月18日 (一) 03:31 (UTC)
(!)意見:同意老陈的意见。 AndyHe829留言) 2016年4月17日 (日) 05:18 (UTC)
(!)意見:你们这样做,不怕有人又要抱怨是针对他的么?——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★贡献 2016年4月17日 (日) 05:28 (UTC)
我是覺得不會,因為這樣可以讓他主編的條目獲得更多檢視的機會,減少錯誤並改善其品質。-和平、奮鬥、救地球!於 2016年4月18日 (一) 01:27 (UTC)
(!)意見:同意老陈的意见+2--4Li 2016年4月18日 (一) 02:34 (UTC)
(+)支持,类似于授奖提名投票,搞一个这样的制度没有啥问题。至于类别和数量,个人认为那是下一阶段的讨论内容。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年4月18日 (一) 01:31 (UTC)
(+)支持,同意在優特評選導入同時評選的上限--Wolfch (留言) 2016年4月18日 (一) 01:40 (UTC)
優良條目每天展出一個,所以可以設定若預計展示的優良條目已經排到N天(M週)後,就一天只放行一個評選。至於同類限制我是不太支持,維基百科本來就鼓勵高品質條目產出,不該限制類別--Liaon98 我是廢物 2016年4月19日 (二) 16:40 (UTC)
DYK也应该吧,不都是条目评选么,还经常因为事后发现“含有錯誤”吵呢。另外,“多元化”恐怕需要多一堆编辑来写才能解决,盯着我怕没啥用,比如说我如果某个月写了30个气象类,但别的人没有29个人(甚至9个人)来写怎么办呢。时限到了,没人投票就不会通过,现在FAC还有几个?GAN又有多少个?关键完全不过是我有没有在写,又都是在写什么嘛。--7留言) 2016年4月19日 (二) 16:51 (UTC)
有關DYK評選是否要排隊,以及優特評選是否要依類別作其他處理,非此次主題,我建議另案討論--Wolfch (留言) 2016年4月20日 (三) 03:13 (UTC)
那又不明确给个数量,怎么讨论下去呢?同时只能有一个?两个?三个?四个?五个?六个?七个?重审受不受限制?重审数是否限制新提名评选数?优良条目和特色条目限制数量是否相同?按什么标准来计算数量?优良如果一天一个最多只可能有七个,但特色要是一天一个就会有14个了,还是“太多”怎么办……--7留言) 2016年4月20日 (三) 06:01 (UTC)
如果以我上面的說法(上首頁的日子來限制),那麼需要排隊時就是一天放一個(因為首頁一天展示一個),不需要排隊時一天幾個都可(直到塞到需要排隊)。如果上首頁已排到30天後,以GAN七天來說,那麼在23天後以前哪天通過,上首頁都是排在31天後,不是一樣嗎。所以我認為可以用上首頁的時間來排,例如限制通過後要在N天內展示到首頁,若無法N天內展示,就先排隊排到能在通過N天內上首頁的日子開始評。而現在重選不影響上首頁,可能得另外想辦法。以上是一點想法--Liaon98 我是廢物 2016年4月21日 (四) 15:54 (UTC)
(!)意見,是否應該專門設立一個特優條目小組,邀請熱心於維護特優條目與對特優條目做出重大貢獻的維基人士聚集在一起,專門研討相關問題,說不定能夠找到可行辦法?--老陳留言) 2016年4月23日 (六) 18:41 (UTC)

@Wolfch霧島聖老陳和平奮鬥救地球:能否說說心裡面的數字?--Jasonzhuocn留言) 2016年4月30日 (六) 05:16 (UTC)

  • 我心裡的數字是優良條目評選最多接受五個條目同時評選,特色條目評選也是,最多接受五個條目同時評選(心裡的數字,所以沒什麼道理)--Wolfch (留言) 2016年5月2日 (一) 01:58 (UTC)
  • 我對於應該有幾個條目同時評選沒有甚麼意見。為了提升品質,避免排隊過長,是否應該特別設定一些篩選機制?例如,假若申請特優條目失敗一次,則不得在一個月內再提出申請特優條目;假若申請特優條目連續失敗兩次,則不得在兩個月內再提出申請特優條目。這樣可以促使編輯者拿出高品質條目來申請特優條目;否則,就必須做好坐冷板凳的準備。--老陳留言) 2016年5月3日 (二) 22:54 (UTC)
    • 我同意老陳的意見。連續未過的條目,比較需要的是同行評審。--Jasonzhuocn留言) 2016年5月5日 (四) 14:24 (UTC)
      • 說明,我的意思是,假若某編輯者申請特優條目失敗一次,則此編輯者不得在一個月內再提出申請特優條目,此編輯者所有正在排隊等評選的條目也必須等一個月後再重新排隊;假若某編輯者申請特優條目連續失敗兩次,則此編輯者不得在兩個月內再提出申請特優條目,此編輯者所有正在排隊等評選的條目也必須等兩個月後再重新排隊。假若能夠使用這機制,則排隊問題應可解決。--老陳留言) 2016年5月6日 (五) 00:22 (UTC)
        • 現下有些落選實際上只是參與投票的人不夠(例如5支持,沒半人反對),這種容易錯殺。而且感覺針對性很強,不想看到某使用者,就故意讓他過不了一次,就可以封殺他長達N個月。就算不是為了封殺某人,這種只會造成人情票更嚴重,因為為了不得罪人(怕被封殺N個月)--Liaon98 我是廢物 2016年5月6日 (五) 02:16 (UTC)
          • 善意推定,只是一個篩選機制的例子。重要的是怎樣提升品質、解決排隊過長這兩個問題?延緩期可以減短,例如,假若申請特優條目失敗一次,則必須等半個月,假若連續失敗兩次,則必須等一個月。這樣,編輯者仍舊有足夠時間提升自己的條目。--老陳留言) 2016年5月7日 (六) 20:24 (UTC)
    • 才看见……我也觉得是5个吧……--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年5月12日 (四) 05:34 (UTC)

有差嗎?限制數量是覺得要評選的條目過多,但是,看看橡皮圖章和人情票的濫投,從來沒有因為評選的條目數量高而降低。所以,設定數量限制的意義在哪裡?

中文維基的特色和優良條目從來不缺這些濫投票,就算是數量高,只要票數夠就可以上,數量降低了,也只是讓濫投可以少剪貼理由一點。對於實質上的品質把關,是沒有多大用處的。-cobrachen留言) 2016年5月16日 (一) 13:24 (UTC)

@Cobrachen:就算用處只有1%,也要努力嘗試為之,絕不可留下一句「沒有多大用處」就輕言放棄努力。我評一個FA至少要耗費下班後的10個日曆天,我相信也有一些認真參評的夥伴需要更充裕的時間參與。今年就發生了由特定人士發起,同時多達接近二十個優特申請,勸說不止,連同其他人充滿錯誤的GA、FA申請未經充分改善就通過。就算評選出的FA品質不理想,也要控制全年不多餘60條。--Jasonzhuocn留言) 2016年5月16日 (一) 13:37 (UTC)
就是因為不到1%的效果,以及限制數量上,對於濫投完全無法改善,所以才說沒有多大用處。無論條目數量多寡,都不會影響濫投的數量。社群從未自這個角度去思考,那麼,少數人的力量終究敵不過橡皮圖章的剪貼效率。
我單打獨鬥,謹慎閱讀和評審超過兩年半,還要接受一堆選不上的人的"熱情",看了很多現象。要說這個問題不能改善,倒也沒有那麼悲觀,可是不從影響最大的下手,效果是不會出現的。對於品質的要求,我沒有放棄。放棄的,是對於不想追求品質的心的協助。-cobrachen留言) 2016年5月16日 (一) 14:26 (UTC)
對於怎樣改善條目品質,這並不是一件很容易解決的問題,如果很容易解決,很早以前就已解決了。我覺得可以從獎勵的方法開始進行,我們要給予傑出編輯者更多獎勵,讓他們覺得有成就感與使命感,這樣,它們會願意在空餘時間,編輯更多特優條目。例如,我們可以每月挑選一位傑出編輯者,其在當月申請成功最多數量的特優條目,我們可以在社群首頁特別表彰這位傑出編輯者。我認為,應該會有很多編輯者想要公平競得這榮譽,這樣做或許能夠使得申請特優條目變得更為有趣,間接地提升條目品質。至於怎樣在評審方面給出獎勵,我尚未想出可行方法,期望大家給出寶貴意見,謝謝!--老陳留言) 2016年5月20日 (五) 06:26 (UTC)

方針指引、格式手冊列表的模板[编辑]

方針指引模板[编辑]

  • T:方針列表T:指引列表因為缺乏更新而少了一些方針指引,我將其補上,卻被IP使用者回退,表示加進來會變得太長,挑幾個放就好,細問該挑何者,他又說大家覺得重要的放入自然就行,但我覺得各方針指引都一樣重要,都該放入,他又獨獨反對我的意見(可以接受其他人放入,卻不准我放入真神邏輯也)。來這邊問問大家意見,是否更新至全部放入+排版的版本(見該模板討論頁)。--Liaon98 我是廢物 2016年4月11日 (一) 02:25 (UTC)
  • 這個挑選太主觀的,那還不如只列五大支柱算了(另外我覺得現在這兩個模板的數量並不算多,比起英文維基的話)--Liaon98 我是廢物 2016年4月11日 (一) 03:29 (UTC)
  • 另一個方法是內容方針一個模板,合作方針一個模板,使用者方針一個模板,東西變大要拆很自然,指引也是有分拆的模板(像是關注度、版權、格式這類指引都是個別模板)--Liaon98 我是廢物 2016年4月11日 (一) 03:43 (UTC)

最好底部导航。 --达师 - 334 - 554 2016年4月13日 (三) 07:50 (UTC)

@hat600:底部導航另有T:Rules模板,現在是在討論右側模板該怎麼寫--Liaon98 我是廢物 2016年4月13日 (三) 07:54 (UTC)
有底部导航的话不建议再加右侧导航。本来右侧导航就是个很麻烦的东西。 --达师 - 334 - 554 2016年4月13日 (三) 07:55 (UTC)
@hat600:如果不用這兩個模板,是要刪除?--Liaon98 我是廢物 2016年4月18日 (一) 13:53 (UTC)
斷然刪除我也不贊成,其實我覺得無必要說中不中立,方針指引本來就是各有不同的重要程度。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月18日 (一) 13:56 (UTC)
我是主张删除的。 --达师 - 334 - 554 2016年4月20日 (三) 04:44 (UTC)
那麼先不刪除,之後就暫時把各方針指引頁的頂測導航移掉好了--Liaon98 我是廢物 2016年4月29日 (五) 11:56 (UTC)
如果不刪除,但卻把它移除掉,那不刪除的意義在哪?我反對刪除,自然也反對移掉。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月30日 (六) 07:20 (UTC)
移除慢慢弄出個好版本再放回,跟草稿差不多概念,刪除就完全沒有了。但我還是不明白為何需要做到兩份幾乎一樣意義的模板,若真的要用少量連結,我上方也提了將各分類各建一個頂側模板(如關注度模板),但閣下未給意見--Liaon98 我是廢物 2016年4月30日 (六) 18:47 (UTC)
@Cdip150:「方針指引本來就是各有不同的重要程度」,但方針和指引的模版早已分開。還是你認為「有些方針比其他方針更重要」?--Temp3600留言) 2016年5月2日 (一) 14:11 (UTC)
沒錯「有些方針(指引)比其他方針(指引)更重要」我是有這樣的看法,不過我這裏不想作示例。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年5月12日 (四) 16:26 (UTC)
@Cdip150:但如果模版內只能放一部分方針的話,必然要先選出一部分方針作為「重要方針」。--Temp3600留言) 2016年5月13日 (五) 14:25 (UTC)
討論無果,我先提請刪除,看看社群如何回應。--Temp3600留言) 2016年5月20日 (五) 16:32 (UTC)
先建了新的,再删旧的吧。乌拉跨氪 2016年5月20日 (五) 16:49 (UTC)
我先做了方針的部分:Template:使用者方針Template:合作方針Template:內容方針Template:基本方針(這個做下去會只有五大支柱,感覺有點少就不做了,現在的T:重要觀念就夠用了),這樣的長度應該街燈大可接受了吧?--Liaon98 我是廢物 2016年5月20日 (五) 19:40 (UTC)
(+)支持保留,各语言版本通用做法。--Shwangtianyuan 留言在此 2016年5月21日 (六) 06:17 (UTC)
並沒有刪除,只是拆成數個模板而已--Liaon98 我是廢物 2016年5月21日 (六) 09:29 (UTC)
那我(-)反对,分拆成多个模板就是形式主义,多此一举。--Shwangtianyuan 留言在此 2016年5月22日 (日) 02:49 (UTC)
为什么还是右栏模板?不是说要改成底栏的吗?乌拉跨氪 2016年5月22日 (日) 04:03 (UTC)
就街燈大反對刪右側啊,而原本的他又嫌太長,拆幾個就短了--Liaon98 我是廢物 2016年5月22日 (日) 07:15 (UTC)
不然上面乌拉跨氪大講的「先建新的」是什麼意思?底欄的早就存在了不用建,我以為你說的建新的是指這些分拆--Liaon98 我是廢物 2016年5月22日 (日) 07:24 (UTC)
底栏模板现在是哪些?乌拉跨氪 2016年5月22日 (日) 14:50 (UTC)
底欄就Template:Rules,所有都列。--Liaon98 我是廢物 2016年5月22日 (日) 15:00 (UTC)
我看了英文版的討論:

Is this intended to be an all-inclusive list of policies? If so, where are all the rest? If not, what selection criteria are being used to create the list? Rossami (talk) 02:59, 18 December 2005 (UTC)

Its a summary of policies, its the ones lubaf and I talked about on IRC (while we can add more remove some). These ones are the more notable policies which newbies should learn first. If we put everything newbies will not bother reading anything. --Cool CatTalk|@ 05:59, 18 December 2005 (UTC)

I made these edits recently, and they were reverted (along with about 30 other of my edits) by Centrx. He feels that this template is exclusively for the most prominant minority of the polices - while I think this template should at least give a link to the rest of them. In my edit, I also added a very small link to the 5 pillars, which are founding properties of all policy. Comments anyone? Fresheneesz 00:52, 11 September 2006 (UTC)

There is already a link to the full policy list, just a little bit implicit. Doing separate could be fine—though I don't see why it would be necessary—but it clutters the template. The thing about the Five pillars is that it seems too basic for this template, which is helpful to editors who already know what Wikipedia basically is. It is used mostly in userspace; it is used in a couple of dispute resolution pages; I have used it in article Talk pages where appropriate; it is used in some relevant policy pages. Adding a link to Five pillars would be fine, adding a link to everything would be fine, but it clutters the template for little use. —Centrxtalk • 01:19, 11 September 2006 (UTC)
那邊的意思是選出最重要的方針方便新手學習,中文版諸位意下如何?--Temp3600留言) 2016年5月22日 (日) 16:16 (UTC)
2006年耶,這多久遠了--Liaon98 我是廢物 2016年5月22日 (日) 16:18 (UTC)
這個模版的確很久遠...--Temp3600留言) 2016年5月22日 (日) 17:24 (UTC)
底栏模板现在这样挺好的,我支持提删原来的右栏模板。乌拉跨氪 2016年5月22日 (日) 16:54 (UTC)

格式手冊模板[编辑]

  • 其二是T:格式手冊T:Style。我的認知是,受眾人討論獲共識升格為格式指引的頁面,才能算是格式手冊,才該放在這兩個模板內,畢竟將草案跟指引放在一起會誤導人以為這些尚非指引的頁面也是指引,所以我先前將這兩個模板中,非指引的改成灰色,但隨後被L管理員回退,因此我直接將非指引的移除,但又遭到O大回退,他認為「被看到也無妨」。我的意見是指引跟非指引要分清楚,不然任何人撰寫一篇未獲共識的頁面,就放上這個模板,豈非大亂了?英文維基那邊就分的很清楚,有另外設計一個格式、內容相關論述的列表模板,而格式手冊模板就專門放格式指引。各位覺得是否應該移除這兩個模板內的非指引?--Liaon98 我是廢物 2016年4月11日 (一) 02:25 (UTC)
  • 原本有用顏色分,但被回退;紅字的是英文維基的格式指引,以前該模板就一直放有(只是用註解隱藏)。我個人是傾向不是格式指引就不要列,因為任何人都能寫草案,也不一定被檢查,所以未獲共識的非指引列上去我覺得不太好。--Liaon98 我是廢物 2016年4月11日 (一) 03:29 (UTC)
  • 第一,只保留底端。第二,同意以某种方式标记未通过的指引。 --达师 - 334 - 554 2016年4月20日 (三) 11:05 (UTC)
  • @Liangent:大大回退了用顏色區別,那麼是否有比較好的方法呢?用灰色表示非正式的作法,在中文維基上的地鐵路線大多這麼做,我當初是以相同想法才這樣標的。另外有看過用斜體,但是斜體的漢字很醜。還是說像{{关注度标准导航}}這般?但是關注度的頁面數量較少,若格式手冊這樣用感覺下面會塞一卡車...--Liaon98 我是廢物 2016年4月20日 (三) 11:42 (UTC)
    • 这样?或者就拆成两个模板?Liangent留言 2016年4月22日 (五) 02:35 (UTC)
人人都可以编写论述,都加到模板里难道不会过长吗?不要费尽心思去区分哪些论述可以加,不要给什么英文版来的论述特权。简单起见,只应当包括方针。--Gqqnb留言) 2016年4月26日 (二) 01:04 (UTC)
  • 目前來看的共識是,論述必須區別,區別方式看是標記還是分拆模板。既然我問分拆沒什麼有意見,那等此次討論存檔後,我便分拆。--Liaon98 我是廢物 2016年4月29日 (五) 11:56 (UTC)
  • 不要拆開兩個模板,那樣分類又要重複列出,相當累贅。用之前的斜體來區分就夠了,醜不一定是不好,把字弄難看一點會讓人有所避諱而不會亂用。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月30日 (六) 07:20 (UTC)
  • 拆兩個、分類重複列出等,我覺得不算多大的問題。英文維基那也是論述跟方針指引各一個模板的(en:Template:Wikipedia policies and guidelinesen:Template:Wikipedia essays)。中文維基現在有個很大的問題就是總是把論述頁當方針指引來引用,連老手也常這麼做,造成新人誤會,明確區分我認為是很好的做法。而且這種論述可以跟方針指引擺在一起的先例一開(不管過去怎樣隨便),其他人便可接著在規則相關導航模板也跟著加入論述,中文維基有上百個論述,若是真的把內容相關論述放在內容方針指引旁,提刪論述放在刪除方針旁等,那可是一場大亂--Liaon98 我是廢物 2016年4月30日 (六) 18:42 (UTC)
我觉得用灰色标记挺好的啊……如果觉得论述门槛太低,可以仅列出“指引草案”或者“对应页面在英文为指引”的页面,这些一般比较靠谱。—Chiefwei - - ) 2016年5月1日 (日) 02:15 (UTC)
唔,可是像Wikipedia:格式手冊/電視en:Wikipedia:Manual_of_Style/Television,這內容差異是非常大的...話說草案的定義英文維基那邊好像是正放在互助客棧討論的才叫草案,但中文維基似乎只要寫好頁面就掛著草案,然後掛到天荒地老也沒拿來客棧討論...--Liaon98 我是廢物 2016年5月1日 (日) 09:43 (UTC)
建议把模板定位为内容指南,里面放内容相对充实的格式指导页面,正式页面加粗/上色显示。中文维基目前条目架构这种大方向都很成问题,这点上能帮助条目的论述都可收录。如果用条目评级来说,就是能把条目指导到丙级的页面。只收录正式页面的话,中文版格式手册又没几个,不如和方针列表合到一起。--風中的刀劍留言) 2016年5月1日 (日) 10:42 (UTC)
@Liaon98:既然已無人討論,建議先行分拆,看看效果如何再作決定。--Temp3600留言) 2016年5月20日 (五) 16:38 (UTC)
上面大部份人都沒有同意到分拆方案,多數都是傾向採用標記法,故反對先行分拆的做法。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年5月20日 (五) 16:48 (UTC)
(+)支持保留,各语言版本通用做法。--Shwangtianyuan 留言在此 2016年5月21日 (六) 06:17 (UTC)
這個沒被提刪啊--Liaon98 我是廢物 2016年5月21日 (六) 10:01 (UTC)
Liangent、Gqqnb、达师贊成拆,Chiefwei贊成標記,請大家繼續討論。--Temp3600留言) 2016年5月22日 (日) 16:19 (UTC)
不是吧。C大、達師、街燈大、風大是說標記,跟我最初的方案相同。而G大是說完全移除論述,跟我最初的方案被L大回退後的第二方案相同;L大是說可以考慮分拆。--Liaon98 我是廢物 2016年5月22日 (日) 16:25 (UTC)

向中文维基百科引入编辑审核制度[编辑]

此讨论已经结束,请不要对此存档作任何编辑。
=== 前言 ===

有用户在维基百科的 Telegram 频道上提到了在中文维基上引入编辑审核Pending Changes )制度,同时鉴于前两次有关引入此制度讨论都是在数年前进行,现在中文维基的状况已经有了一些改变,因此在下决定在互助客栈中重提一次有关引入编辑审核制度的讨论。

简而言之编辑审核制度即在维基百科上的部分条目实施先审核后发布的制度。

大多数用户对被编辑审核保护的条目(在之前的讨论中被称为“待审保护”)的编辑都会被一种叫 pending changes reviewer (译名待定,在之前的讨论中被称为“审查员”“审核员”等)的用户审核,经过审核之后方能发表。因此如果引入这一制度,会需要在中文维基上新加入 reviewer 这一权限。这一权限的申请与巡查权、回退权等类似,但三者并不相关。请各位参考维基百科:编辑审核上的内容。

在之前的讨论中,有一些用户可能误会了编辑审核制度初衷。而目前中文维基上有关编辑审核的方针翻译工作尚未开始,因此在下先对这一方针在英文维基的大概使用方法做一些概括:

  • 在英文维基上,编辑审核与半保护、全保护等视作一种保护状态。因此被编辑审核保护的条目同样需要在受到破坏之后方能实施。见Wikipedia:Protection policy
  • 被保护的条目分两类:Pending Changes Level 1(在之前的讨论中被称为“乙级待审保护”)和Pending Changes Level 2(在之前的讨论中被称为甲级待审保护)。被 Level 1 保护的条目允许自动确认用户和确认用户编辑后无需审核直接发布;被 Level 2 保护的条目即使是自动确认用户和确认用户编辑后也需要审核。但在英文维基上, Level 2 仍有较大争议,极少使用。
  • 大多数被待审保护的条目都是生者传记条目。在之前的讨论中,很多中文维基人没有意识到这一点。编辑审核的主要保护对象并不是具有巨大争议的、编辑十分频繁的条目;也不是有两名维基人发生编辑战的条目。一般对这类条目的改动比较少,因此待审核的编辑数量不是特别多。在英文维基上,规定需要待审保护的条目为以下三类:
    • 被长期性破坏的条目;
    • 对传记或生者传记条目的破坏;
    • 侵权破坏(向已创建的条目中加入侵权内容)。
  • 待审核条目的记录是完全公开的。这个记录包括了
    • 某名用户在何时递交了需要审核的编辑,其内容为何;
    • 审核这一编辑的 reviewer 是谁,通过了或者没通过(没通过的审核也不会被类似 RRD 的方式隐藏,在历史记录中可以直接查看);
    • 若一个条目有需要审核的编辑,那么任何人可以直接查看,但默认显示的不是待审核的编辑。

试举一例:SpongeBob SquarePants (season 9)。该条目似乎是因为被加入了大量侵权内容而被待审保护。在这一条目右上角的 Edit 标签处,还有一个 Pending Changes 的标签。如果有人递交了待审核的编辑,那么无论任何人都可以直接点 Pending Changes 这个标签查看,但是默认看到的却不是待审核的编辑。搜索框下面有 Accepted 的字样,右面还有表示 pending changes protection 的小锁头,表示该页面正在被待审保护。在该页面的历史记录页( History ),可以直接看到该条目所有的审核记录。

因此,待审保护不必过度担心会造成新用户流失、过度集权于管理员和 reviewer 的情况。

在这里整理了英文维基上有关编辑审核的方针和指引。请各位参考。

Techyan留言) 2016年4月23日 (六) 15:32 (UTC);修改于2016年4月23日 (六) 15:44 (UTC);修改于2016年4月24日 (日) 05:43 (UTC)

討論

  • (-)反对,见Wikipedia:互助客栈/方针/存档/2015年9月#第3遍了:编辑审核--Antigng留言) 2016年4月23日 (六) 15:36 (UTC)
    • (:)回應@Antigng:我似乎没有看见您在2015年9月的讨论中发表具体的反对意见。除此之外,我对之前讨论中的误区做出了解释。--Techyan留言) 2016年4月23日 (六) 15:44 (UTC)
      • 主要是其它用户的意见,比如“我看了一下其他版本的自動審查員,發現那編輯審核不見得會有成效,倘若有心人濫用,那不就更邋塌”--Antigng留言) 2016年4月23日 (六) 15:53 (UTC)
  • (+)贊成完全只是觉得有“0.75保护”的必要性。┌─⚡⠠⠵[learningis1st]-[~]- time = 2016年4月23日 (六) 16:33 (UTC)
  • (+)支持:做為一個介於半保護與全保護之間的保護狀態有何不可?說實話,有時破壞真的防部慎防,對於部分條目進行編輯審核制對於破壞處理可能會更有效率--宇帆(留言·) 2016年4月23日 (六) 16:52 (UTC)
  • 如果是明显破坏回退或移除便可,中文维基搞审查只会徒增争议。谁来当审核员,尤其大量涉及政治的条目,例如中共统治、台湾政治、六四、法轮功、占中、中日军事与外交、中国对外主权争议,双方都自认中立,认为对方扰乱。审核员本身也难以获得公信力,甚至被批为政治打手,又或被质疑修炼法轮功,审核员肯定远比管理员还难当得多。这样干不但无助提升品质,反而带来更多争吵,更令中文维基因此被贴上政治审查的标记。--Thomas.Lu留言) 2016年4月23日 (六) 17:04 (UTC)
  • 编辑审核条目主要保护的对象(以生者传记条目为主)可以看出,编辑审核主要是为了防新手、脑残粉和小粉红之类的而不是用来调节用户(尤其是老用户)之间争议的。对于老用户之间的争议,应该使用全保护来解决。而法轮功、六四事件等条目也不是编辑审核所保护的对象。待审保护和半保护、全保护可以同时实施,相互之间不冲突。相比较之下,现在中文维基人手较缺,对于编辑不是很频繁的一些条目来说,实行编辑审核更容易把握条目质量、避免条目被破坏还长时间无人发现的情况。在制定方针的时候要严格规定编辑审核适用的条目类别。--Techyan留言) 2016年4月23日 (六) 22:00 (UTC)
  • “这些条目很有可能被破坏,因此即使没被破坏也要提前保护。”,这个出发点就是不正确的。--Antigng留言) 2016年4月24日 (日) 03:26 (UTC)
    • @Antigng:都說是受到破壞再經由Wikipedia:请求保护页面來對特定頁面實施編輯審核制了。。。。。。。。--宇帆(留言·) 2016年4月24日 (日) 05:54 (UTC)
      • [4]--Antigng留言) 2016年4月24日 (日) 05:56 (UTC)
        • @Antigng:那麼就用『受到破壞再經由Wikipedia:请求保护页面來對特定頁面實施編輯審核制』這種運作方式來引入編輯審核制不就解決了?--宇帆(留言·) 2016年4月24日 (日) 05:58 (UTC)
          • 这样又会推出“这个机制没有用”的结论。如果“受到破壞再經由Wikipedia:请求保护页面來對特定頁面實施編輯審核制”,我们有已经有半保护,有全保护,有{{editprotected}},为什么还需要pending changes review?--Antigng留言) 2016年4月24日 (日) 06:02 (UTC)
            • @Antigng:就只是跟┌─⚡⠠⠵[learningis1st]-[~]的想法差不多,覺得要有一種介於半保護與全保護之間的一種保護--宇帆(留言·) 2016年4月24日 (日) 06:04 (UTC)
              • 不是“覺得要有一種介於半保護與全保護之間的一種保護”,就需要引入这么一种东西。你需要表明有什么问题现有的制度不能解决,而引入新制度以后能够解决。--Antigng留言) 2016年4月24日 (日) 06:10 (UTC)
                • 我認為對於『條目遭到破壞沒有即時看到,而該破壞若造成合理使用圖像無法顯示會造成合理使用圖像被提交快速刪除』這種搞的人很煩躁的破壞可能可以解決--宇帆(留言·) 2016年4月24日 (日) 06:16 (UTC)
                    • 这通过半保护没法解决吗?--Antigng留言) 2016年4月24日 (日) 06:19 (UTC)
    • @Antigng:我看了您的留言,又回去看了英文维基的方针。Pending changes portection should not be used as a preemptive ueasure against violations that have not yet occured. 我刚开始自己看错了,还有问题吗?--Techyan留言) 2016年4月24日 (日) 06:54 (UTC)
      • 如果承认了pending changes review不是预防措施,就会推出“这个机制没有用”的结论。--Antigng留言) 2016年4月24日 (日) 08:25 (UTC)
  • (+)支持編輯審查制度,這個用好了會有很大幫助,但是重點在於要用在哪裡。-- 給我留言 「歡迎加入 #cvn-zh-scan Qinyongr 2016年4月24日 (日) 08:18 (UTC)
    • 用在哪里都不知道如何“用好了會有很大幫助”?--Antigng留言) 2016年4月24日 (日) 08:25 (UTC)
  • (-)反对:我的想法跟Thomas.Lu差不多,中文維基人手不足,且觀點具有極大分歧,這個審查容易失中立;我認為現在的全保護、半保護就很夠用了。有些事情還是討論比較好,而不是交由審查員判斷--Liaon98 我是廢物 2016年4月24日 (日) 12:17 (UTC)
  • 看起來和WP:穩定版本有點相像,可以先研究研究。--Jasonzhuocn留言) 2016年4月24日 (日) 13:26 (UTC)
    • 我一开始也把这个制度和稳定版本搞混了,然而事实是这个和稳定版本是两个完全不同的制度。Bluedeck 2016年4月27日 (三) 06:42 (UTC)
      • @Bluedeck:我看了一點PC的文檔,還沒充分理解怎麼回事。--Jasonzhuocn留言) 2016年4月27日 (三) 11:29 (UTC)
  • 我不很支持。首先看壞一點這東西可能會變成變相審查,其次要找個持平的審查員是一個問題,再來就是英文版社群比我們更加老成(Wikimedia-I的討論有90%都不想理),要小心這東西在這兒會變質。如果要籠統的說說我的憂慮,我會用「不符合國情」來形容。--春卷柯南-發前人所未知 ( ) 2016年4月24日 (日) 13:32 (UTC)
  • (+)支持我建议部分非政治条目采用这个措施来保证条目质量。--Herfjotur留言) 2016年4月25日 (一) 05:19 (UTC)
  • (!)意見这个方法目前在个别维基使用,主要有英文式和德文式,英文式就是部分条目进行pending changes。德文式,包括按照德文维基为模板建立的文言维基,只要有一遍review之后,每个变化就必须再次进行review。这些维基有一个职位就是用于review的。以上供参考----損齋留言) 2016年4月26日 (二) 01:19 (UTC)
  • (!)意見,如果真要引入,只考虑在FA、GA这两类容易涉及质量破坏的条目使用,这样可以避免因为两岸相关政治倾向而引起争议而陷入政治审查的圈套。当然,实际上这种前审核其实就是百度百科的模式,这样和我们这里一旦提交就可立即显示的理念不符,反而更需要加强对破坏的发现和处理的手段和行动,而非靠前审核这种容易引起争议的手法。——路过围观的Sakamotosan 2016年4月26日 (二) 02:27 (UTC)
  • (-)反对:沒必要加入編輯審核制度。--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年4月26日 (二) 07:23 (UTC)
  • (-)反对,以目前中文維基百科生態,不建議加入編輯審核--Wolfch (留言) 2016年4月27日 (三) 01:17 (UTC)
  • 偏向(+)支持。这个制度不是事后审核制度。制度本身也十分聪明,为保护提供了更多弹性。如用在冷门和长期破坏的条目上,将会达到其希望的效果。唯独考虑到中维处理争议的水平和处理积压工作时间,担心采纳该制度会--1,在引入复杂性的同时不能带来相应的效率提升。2--,Pending changes的冷门天性可能会令其积压时间超过半保护措施。故仅有保留的支持。Bluedeck 2016年4月27日 (三) 06:40 (UTC)
    • 到時候每次編輯幾乎需要審核員和管理員審核......好用嗎?閣下可以去test.wikipedia.org或test2.wikipedia.org去用用看就知道了--Engle躍築夢踏實夢想起飛安裝加速投票工具】 2016年4月29日 (五) 08:08 (UTC)
  • (?)疑問,請問現在有甚麼維持保護冷門條目的有效機制?--老陳留言) 2016年4月27日 (三) 21:19 (UTC)
    • 没有,也不应该有。--Antigng留言) 2016年4月28日 (四) 02:14 (UTC)
  • (-)反对--當前中文維基生態,並不適合,將衍生很大的爭議問題。Wetrace歡迎參與人權專題 2016年4月29日 (五) 11:55 (UTC)
  • (-)反对:從WP:PC的表格來看,與半保護和全保護的性質過於類似,沒必要再多出编辑审核制度。--M940504留言) 2016年5月1日 (日) 03:39 (UTC)
  • (?)疑問:如果有编者提交了新页面,再通过审核之前其他编者是否可以继续编辑?个人认为中文维基上对条目的巡查效率还是不低的,能迅速挂模板指出问题,如果施行可能会降低效率。— Bieraaa 于 世界统一时间 (UTC) 2016年5月12日13时29分 留言

论述

讨论已经进行了一周,收获了不少意见。下面在下想对遇到的反对意见做一些解释。希望各位能认真读完

  • 编辑审核不是审查而是保护。编辑审核在本质上与百度的先审核后发布的政策不同。
  • 编辑审核不会影响普通用户的编辑。绝大多数情况下,确认用户不会受到编辑审核的影响。需要进行编辑审核的只包括了 IP 用户和非确认用户。也就是说,普通用户编辑战仍需要通过全保护解决。
  • 编辑审核不适用于争议性强的条目。在下在前面已经提到过:编辑审核通常只适用于传记类、长期破坏类和长期被添加侵权内容类。解决法轮功、六四事件之类争议条目不会使用编辑审核功能。在社群讨论实施细则的时候,可以对适用的条目类型做出更明确且更严格的规定。
  • 编辑审核造成的积压并不严重。英文维基的这一页面中,待审核的条目数量不多,且时间跨度很大。被保护的条目大多比较冷门(大约一周到数周才会发生一次新用户的破坏编辑)由此可见积压完全在可接受的范围之内。
  • 对 reviewer 的要求并不是很高。根据在下在 Huggle 上的经验,对最近更改的明显破坏很好判断。Reviewer 这一权限与巡查权和回退权类似,不必太过担心缺人。当然有关具体的要求还待社群之后讨论。
  • 不是每篇条目都需要进行审核。作为一种保护,编辑审核同其他类型的保护一样,只在发生破坏后保护需要保护的条目。
  • 编辑审核完全透明。任何人(包括新用户)都能在历史记录里看到该条目 review 的记录。包括递交的新版本、reviewer 是谁、该版本通过与否等。新用户也能知道自己的编辑正待审核。
  • 编辑审核以 level 1 (乙级待审保护)为主。 Level 2 (甲级待审保护)存在但是很少使用。在英文维基上 level 2 保护曾引起很大争议,现在几乎没有应用。

那么,什么样的条目适用于编辑审核?编辑审核是否与现有的半保护和全保护冲突?

在下认为,编辑审核是一种部分替代半保护的保护措施。当我们对条目实施半保护的时候,阻挡了有害的编辑,但是也阻挡了想要对该条目进行建设性编辑的用户。尤其是在一些被永久、或者长期半保护的条目上。相比较半保护,编辑审核更像“ 0.25 保护”。编辑审核更宽松、更适合长期保护、更不容易影响新用户的编辑。翻开 WP:VIPWP:PT ,相比半保护而言更加适合用编辑审核的条目更多。试举两例:

  • 日本人条目长期被不同的 IP 用户破坏。如果实施编辑审核,可以延长保护期限,避免待保护结束后继续有人破坏;也能避免阻挡新用户的编辑。
  • 智利长期被来自智利的不同的 IP 用户和新用户加入机器翻译内容。现在被永久半保护,如果实施编辑审核,可以避免新用户的编辑被阻挡。

实际上,很多在 WP:PT 上的被永久或长期半保护的条目更适合编辑审核。半保护会一刀切地阻断所有新用户的编辑,而无论是否具有建设性。而永久半保护则会永远地阻挡所有新用户的贡献。这些条目大多都是长期被不同的新用户破坏、且还有新用户做出建设性编辑的。

那么半保护是不是就没用了?有些条目更适合在短期内半保护,而对于高风险模板之类的页面,永久半保护更加合适。

@AntigngThomas.LuChenyijia001QinyongrJasonzhuocn:@Liaon98A2569875小躍春卷柯南Herfjotur:@三石樑桂老Cwek老陳WetraceM940504:请诸位发表意见。

Techyan留言) 2016年5月1日 (日) 14:38 (UTC)


(+)支持,玩好了能有大帮助。#ForeverLove凡人丶 你一定要好好的 中文字数统计工具 2016年5月1日 (日) 14:57 (UTC)
(!)意見,謝謝Techyan的解說,看起來疑慮小很多了。不過,這多少涉及維基發展的方向,個人再聽聽大家意見。Wetrace歡迎參與人權專題 2016年5月1日 (日) 15:04 (UTC)
(+)支持,符合中文维基目前需要。Techyan的解释也很好。--1=0欢迎河北维基人加入QQ群331736133 2016年5月1日 (日) 17:54 (UTC)
(+)支持,為何不試試呢?--Temp3600留言) 2016年5月2日 (一) 13:33 (UTC)
(+)支持,很好。--Qinyongr 給我留言 」「歡迎加入 #cvn-zh-scan 2016年5月2日 (一) 13:40 (UTC)
(+)支持,這種四分之三保護是透過Wikipedia:請求保護頁面來申請,並不存在上方反對票所提及的編輯不方便或百度百科化問題。--宇帆(留言·) 2016年5月3日 (二) 05:20 (UTC)
(+)支持,假設待审核的条目数量很多,是否有方法將之分類?--老陳留言) 2016年5月3日 (二) 06:00 (UTC)
仍然(-)反对,首先如果PC的标准比半保护要低,那么引入PC就是变相降低了保护的标准,换言之,保护了原先不该保护的条目,延长了保护期限,这是我绝对不能接受的。(理想情形下,维基百科上应该没有保护也没有封禁。我们不应该带有任何一点“预防性”的目的去保护任何主名字空间的页面。)如果PC的标准比半保护高,那么是否可以通过PC代替部分半保护呢?支持这样的观点的人认为
  1. 半保护阻挡了所有新用户的编辑,而PC不是这样;
  2. PC的界面比半保护要好;
  3. 引入PC并不会为维基百科带来额外的维护负担,相反,半保护的ep反而没人管。

但是我要说:

  1. 半保护并没有阻挡新用户的编辑,我们有{{editprotected}},去年也引入了草稿名字空间。究其本质,PC是拿页面本身打草稿,而半保护之后可以拿草稿和用户沙盒打草稿;PC之后审核员可以审核,而半保护之后任何自动确认用户都可以审核,两者在功能上基本一致。相反地,新用户如果用沙盒/草稿修改页面老用户可以帮助修改并教导新手编辑,用PC却只有通过和不通过两种选项。
  2. 半保护界面不好应该想方设法改善界面,而不是想着引入不十分必要的新功能。我们完全可以考虑在保护页面的编辑提示中加入指向草稿页面的链接。
  3. 英文维基的这一页面中,待审核的条目数量不多。从逻辑上说,英文维基待审核的条目数不多并不能推出中文维基百科引入PC之后不会积压。实际情况是英文维基百科的这一页面中,待巡查的页面也不多。然而中文维基百科待巡查的页面却是非常多。原则上,半保护的ep所有自动确认用户都可以管,而PC只有审核员及以上权限的用户可以管。如果半保护的ep都没人管,那如何能保证一定有审核员管PC呢?(之前的讨论中有用户将PC审核描述为人工jobqueue)。

--Antigng留言) 2016年5月3日 (二) 06:30 (UTC)

那麼如果設定為回退員跟巡查員都能擔任審查工作,人手多的話也許就不會有積壓發生。--宇帆(留言·) 2016年5月3日 (二) 10:11 (UTC)
再多也不可能有自动确认用户多。--Antigng留言) 2016年5月3日 (二) 13:18 (UTC)
Stang的意见偏向于(-)反对,应该向提示信息和界面开刀。另外赞同“新用户如果用沙盒/草稿修改页面老用户可以帮助修改并教导新手编辑”。--Stang c 2016年5月6日 (五) 16:25 (UTC)
我懷疑新用戶找不到沙盒和草稿...--Temp3600留言) 2016年5月8日 (日) 08:33 (UTC)
我的想法是防止维基百科向百毒百科靠拢,如果使用待定更改审查也只能用在少数页面。待定更改审查是事先预防还是事后预防,我认为不应该是事先预防——维基百科的精神就是自由、开放、善意假定。如果待定审查是事后预防,它与半保护、全保护相比有什么好处?乙级待审保护跟半保护针对的都是匿名用户以及非自动确认用户,区别就是半保护时匿名用户以及非自动确认用户想要贡献只能找管理员或者等保护撤销了再来,待审保护则他们提交编辑等待审查或者等保护撤销了再来。所以待审保护跟半保护、全保护就是提交贡献的方式不同,但都需要审查:一个是社群、管理员审查,另一个是审查员审查。都是审查没有什么差别。另外“保护”有一种冷静作用,大家都不能改这个页面。如果开启了待审保护,会不会破坏者们继续提交编辑,发泄仇恨?综上觉得无需引入此制度,(-)反对--Gqqnb留言) 2016年5月7日 (六) 01:49 (UTC)
在乙级待审保护,新用戶有提交修改的權利,在半保護中則沒有,限制更多。--Temp3600留言) 2016年5月8日 (日) 08:37 (UTC)

论述 2

有关编辑审核(下称 PC ,Pending Changes)与现有半保护和全保护是否重复、 PC 相比半保护有哪些优势、到底半保护和 PC 哪个更适合中文维基,Antigng 和在下在 IRC 上已经讨论过数次。在第一篇论述中也有提到。在下认为:

  • PC 与半保护部分重复。对于有些页面更适合 PC ,有些页面更适合半保护。依在下观点,对于大部分长期半保护的条目更适合用 PC 来替代;对于短期半保护的条目则更适合半保护而非 PC 。有关这一点,在第一篇论述中在下已经说清楚了。
  • 对新用户来说,{{editprotected}}的使用成本要远高于 PC 。在下认为,{{editprotected}}这样的模板只适合被全保护的条目。 Antigng 提到了,半保护也可以用{{editprotected}}解决,但很少有新用户会这样做,除非他真的特别想编辑这个条目。而如果应用了 PC ,那么该用户只需要像正常的编辑一样操作即可。别忘了,在新用户保存编辑之后,他会默认看到自己修改过的条目,除非用浏览器刷新页面。当一个新用户试图编辑被半保护的页面时,他会看到禁止编辑的提示。如果编辑欲望不那么强烈(比如发现条目里有个错别字,或者多打了个逗号之类的小错误),那么新用户可能根本不会细读提示直接就退出去了。就算新用户用上了{{editprotected}},他也需要先到条目的讨论页说明情况。而关键问题是,这些新用户大多只会用叙述性的语言描述出需要改动的地方,而不会直接改给你看。换句话说,如果有人希望处理{{editprotected}},那么他需要读一遍条目(至少也要大概读一遍),然后才能根据这些新用户的描述做出改动。——更何况不少描述都非常模糊。而描述需要修改的内容也经常会遇到没有来源等的情况。典型代表之一是Talk:黄安 (艺人)。如果使用 PC ,reviewer 可以直接拒绝并在摘要中说明理由。
  • 使用草稿名字空间会进一步增加新用户的使用成本。让新用户能直接把自己要改动哪些 wikitext 写出来本身就已经很困难了,使用草稿会更困难。在下的意思并不是“新用户用了草稿达到的效果还不如 PC ”,而是“难以引导新用户使用草稿”。相信绝大多数编辑欲望并不强的新用户早就该放弃了。
  • 通过改善页面能给新用户指引,但对于新用户还不够直白。我们可以修改半保护的提示页面,用明显的字体告诉新用户可以使用草稿来解决,但当新用户(尤其是那些连[[]]表示内部链接、什么都不知道,只想改个错别字的新手)创建草稿页面时肯定会不知所措。同时,他们还需要在条目讨论页里告诉别人自己把草稿放在了那里等等,这些都是新用户的阻碍。当然,有 IP 用户用草稿页面告知管理员应该改的地方,但那都是极少数貌似 IP 用户实际上编辑经验比不少新巡查员还丰富的那种。
  • PC 不会影响帮助新手。在英文维基百科的有关方针中有这样一句:The reviewer checks the pending change(s) for an article and can then decide to either accept it, revert it or modify it then later accept it. 因此实际上并不是两个选项,而是三个。既然让新手创建草稿页面成本很高,那么就让 reviewer 来创建,然后告诉新手他修改的内容不合格的地方,再让他去由 reviewer 创建的草稿页面继续修改。
  • 半保护(以及 PC )与全保护通常遇到的情况不一样。全保护大多是条目争议时实施的。而争议大多是由老用户之间的意见不统一造成的。相反,半保护主要应对的是来自新用户的破坏。因此 PC 不会影响条目的争议问题。而非争议的条目大多也不会在短时间内出现大量破坏。
  • 有关实施 PC 后积压工作量的看法:PC 会比{{editprotected}}产生更多的工作(因为对新用户更友好,自然会有更多编辑)。但每笔积压比{{editprotected}}更容易处理(因为需要改动的地方都清楚地展示出来)。也正因为更容易处理,因此 review 的积极性要高过核准{{editprotected}}的积极性。至于破坏者大量递交编辑的情况,在下认为不太可能会出现。首先,破坏者在保存页面后看到的是自己破坏过后的样子。如果破坏者意识到这个条目被 PC 保护,那么他应该清楚后面有 reviewer 审核内容而不会继续破坏。如果破坏者没有意识到有 reviewer ,且发现了自己的编辑没有“真正保存”,充其量反复重试几次就不会再动了。此时, reviewer 只需要回退一次即可。

@AntigngStangGqqnb:请发表看法。--Techyan留言) 2016年5月8日 (日) 13:45 (UTC)


  1. 提案人认为新用户不愿意、也无法引导新用户使用ep和草稿。(“很少有新用户会去这么做”、“难以引导新用户使用草稿”、“新手创建草稿页面成本很高”)理论上,我们都没有试过改善界面,如何知道新用户是不愿意ep,而不是根本不知道、没注意到可以ep?事实上,我们可以看一看WP:DRV,这个页面每个月有大量的请求,其中一半的请求都是新用户提出的。他们能够找到DRV并成功提交请求,是因为删除通知模板有一个指向WP:DRV页面的链接,而DRV有详尽的编辑提示。如果我们把半保护的界面弄好,新用户ep将会比提交DRV更为容易。
  2. 提案人认为,ep+草稿不利于懒用户修改页面。(“而关键问题是,这些新用户大多只会用叙述性的语言描述出需要改动的地方,而不会直接改给你看。”)如果需要修改的是一个错字或者一个标点符号,那么偷懒的用户ep的时候直接“描述出需要改动的地方”,那就够了,不管有没有草稿。难道指明某段某个标点错了还改不出来吗?如果修改的是复杂的wikitext,那么有理由相信那些偷懒的用户会把代码改得乱七八糟,如果用草稿而不是PC,这些乱七八糟的东西就不会出现在条目历史里面,还方便老用户修改。
  3. 提案人认为,处理PC比半保护ep更容易(“每笔积压比{{editprotected}}更容易处理”)事实上,处理半保护的难点并不在理解新用户要修改什么,而是判断应不应该改、如何更好地改,这个过程中需要与用户沟通交流。且不论ep模板填patch参数就可以比较页面和草稿的差异,就算PC“需要改动的地方都清楚地展示出来”而ep不能,也没有减轻审核者的工作量,因为工作重点不在这个地方。

--Antigng留言) 2016年5月8日 (日) 14:24 (UTC)

新用戶要使用editprotected,要先學會:1. 討論頁 2. 模版應用 3.ping人來處理,我覺得這條學習曲線對只想改錯字的新用戶極不友好。如antigng認為有方法教導新用戶用ep,希望你詳細說明。--Temp3600留言) 2016年5月8日 (日) 16:34 (UTC)
不用ping人来处理,模板会自动添加分类。在讨论页留言和添加ep模板比提交DRV请求更为容易,(理论上只要点两下按钮就可以了,先点开编辑按钮发现被保护,再点击“提出代为编辑请求”就来到了带模板的讨论页)何以见得“對只想改錯字的新用戶極不友好”?问题是现在这些提示里面没有提到草稿这么一回事情,导致新用户想做复杂修改时不打草稿。--Antigng留言) 2016年5月8日 (日) 23:53 (UTC)
根據過往經驗,EP常常一個星期都沒人處理,而非管理員極少查看該分類,故「所有autoconfirmed用戶都可協助處理半保護」未免太理想化。英文版另一支持觀點為「Semi-protection is insufficient in certain cases, especially for articles targeted by persistent vandals or sockpuppets, or subject to extreme BLP violations; these sometimes require full protection. The option to deactivate auto-reviewing for autoconfirmed users who are not reviewers (autoconfirmation) provides a protection level adapted to handle those cases.」--Temp3600留言) 2016年5月9日 (一) 10:39 (UTC)
我的观点是,处理PC的难度和处理ep的难度相同,PC部分用户才可处理,ep全体确认用户都可以处理。如果半保护没人干,PC也没人干。--Antigng留言) 2016年5月9日 (一) 13:12 (UTC)
在下不清楚别人会怎么做,但最起码在下平时反破坏的时候根本不会留意编辑请求的版块。所有自动确认用户都可以去处理的确没错,但前提是要有人去处理。无论是半保护,甚至是全保护的 editprotected 都很少有能处理的人负责。这一点在下与 Temp3600 的对社群处理 editprotected 所认为的一样。就算是全保护的条目遇到编辑争议需要驳回 editprotected ,也很少见管理员动手驳回。同时,在下也不认为 WP:DRV 中每个月有大量的请求——如果真这样的话,那三四个 reviewer 就肯定足够处理所有 PC 请求了。至于 Antigng 指出的第二点,反正在下是从来没见过有多少新用户特地去 editprotected 告诉其他用户“这里多打了个逗号”的。Antigng 君忽视了随编辑的所谓“重要”程度的不同而不同的编辑欲望。对于改标点之类的小修改,普通用户的编辑欲望并不强烈,也自然不会去折腾 editprotected 。--Techyan留言) 2016年5月9日 (一) 12:36 (UTC)
Wikipedia:存廢覆核請求/存檔/2016年1-3月,171个请求,一半以上是新用户提的。--Antigng留言) 2016年5月9日 (一) 13:12 (UTC)
抱歉。在下没看WP:DRV是什么。在下以为是加入editprotected模板的讨论页的分类页[:CAT:EP]]。--Techyan留言) 2016年5月10日 (二) 22:32 (UTC)
“PC 不会影响帮助新手”中您说因此实际上并不是两个选项,而是三个。那么。奉上图片。而且PC中,如果在进行了一个不恰当编辑后,又有用户进行了一次没有问题的编辑,执行“拒绝更改”时就会出现内部错误。我目前还是认为可以“通过改善页面能给新用户指引”。--Stang c 2016年5月9日 (一) 02:45 (UTC)
這個不是應提上phabricator嗎...--Temp3600留言) 2016年5月9日 (一) 10:43 (UTC)
@Stang:如您的图片所说,在技术上有两个没错,但是 reviewer 把新用户不合格的编辑复制粘贴出来再修改不就是 3 个了吗?内部错误也可以像遇到编辑冲突那样直接由有经验的 reviewer 解决。--Techyan留言) 2016年5月9日 (一) 12:36 (UTC)
或者我從另一方向說明我的觀點:一項新技術只應是有害無益的情況下,才應該拒絕引入,否則就應給予試用的機會,在試驗中確認它的優劣。我希望@Antigng:提出另一前提,或就有害及無益兩方面證明reviewers制度連試用都不配。--Temp3600留言) 2016年5月9日 (一) 14:06 (UTC)
我是一位极端保守的用户。我不认为应当在没有明显好处的情形下引入任何新功能/制度(摸着石头过河)。--Antigng留言) 2016年5月9日 (一) 14:09 (UTC)
一个影响重大,甚至会改变编辑习惯的,不是个人可以拒绝的功能,应该谨慎对待。——路过围观的Sakamotosan 2016年5月13日 (五) 03:14 (UTC)
+1 --Stang c 2016年5月14日 (六) 04:00 (UTC)

讨论已经结束。如果7天之内没有新的反对意见,将开始有关方针翻译和具体政策制定。--Techyan留言) 2016年5月15日 (日) 12:04 (UTC)
唉呀呀,話說我們還未成功說服Antigng和cwek呢...--Temp3600留言) 2016年5月15日 (日) 14:30 (UTC)

離共識仍遠,請努力謀求共識。--Jasonzhuocn留言) 2016年5月15日 (日) 15:52 (UTC)

關於半保護問題,我再重申:「Semi-protection is insufficient in certain cases, especially for articles targeted by persistent vandals or sockpuppets, or subject to extreme BLP violations; these sometimes require full protection. The option to deactivate auto-reviewing for autoconfirmed users who are not reviewers (autoconfirmation) provides a protection level adapted to handle those cases.」,即PC 可用來對付某一特有恆心的破壞者。此外,我認為reviewer可暫且由patroller兼任,看看效果如何再決定,最壞就是立刻通過所有修正,改回半保護,對維基損失不大。故我贊成進入下一階段。--Temp3600留言) 2016年5月20日 (五) 16:46 (UTC)

自动清理尺寸过大的合理使用图片[编辑]

内部链接后面还可加括号提供其他语言的名称吗?[编辑]

关于同时涉及侵权和速删的新页面的处理[编辑]

之前遇到过几次这种讨论,比如Wikipedia:互助客栈/其他/存档/2014年8月#問:同一新建条目涉侵权和广告,取何种处理方式为佳?

不是一个很好解决的问题。考虑如下因素:

  1. 侵权验证属于页面存废讨论的一个分项,而速删先于存废讨论,从这个角度考虑应当优先速删。
  2. 速删对新手不友好,而侵权相对友好一些。
  3. 速删会引发短期内重建,而侵权一挂就是一周。虽然也有不断反复建立临时页面的例子。
  4. 如果走侵权流程,会有人真的去走OTRS,结果走完OTRS发现还是要速删。
  5. 如果速删被驳回,侵权内容可能错过被处理的机会。

我倾向于优先速删,但没有什么特别成熟的提案,想到的可能的方案如下,

  • 在Twinkle中设置特定理由的速删(比如G11)默认短期白纸保护(针对3)
  • 允许一个条目同时挂速删和侵权,如同允许一个条目同时挂速删和存废讨论一样(针对5)

抛砖引玉。 --达师 - 334 - 554 2016年5月9日 (一) 11:05 (UTC)

  • 這個問題好像有爭議。--Qinyongr 給我留言 」「歡迎加入 #cvn-zh-scan 2016年5月9日 (一) 11:08 (UTC)
    • 個人認為對不同的內容應該採取不同的順序。
      • 例如G11、G12的內容應該先CSD,其餘內容先copyvio
      • --Qinyongr 給我留言 」「歡迎加入 #cvn-zh-scan 2016年5月9日 (一) 12:45 (UTC)
  • 去年讨论过而且有明确共识的东西,今年出了什么新问题,需要再讨论一次?--Antigng留言) 2016年5月9日 (一) 13:15 (UTC)
    • 第一,查不到。第二,只规定了G11。 --达师 - 334 - 554 2016年5月9日 (一) 14:55 (UTC)
@Antigng:認為需討論G11以外的項目嗎?--Temp3600留言) 2016年5月15日 (日) 14:34 (UTC)
如無人討論,將數日內無共識結案。--Temp3600留言) 2016年5月20日 (五) 16:48 (UTC)

G11是否適用個人沙盒[编辑]

如題,當今許多管理員對於用戶個人沙盒廣告皆做G11速刪處理,但上官兄指出WP:CSD在G##(##指任何數字)段落的開頭寫道:「以下標準適用於所有名字空間中的頁面,沙盒頁面除外」,故依現行方針G11似不適用用戶沙盒。亦有用戶指出對用戶沙盒進行速刪恐誤殺欲進行正常貢獻之非廣告新手。然Nbfreeh君指出User:用戶/XXXUser:用戶/沙盒是否因此會有適用性的差別、或者造成「沙盒让宣传合法化」的現象?在此ping相關用戶@ShangkuanlcAlexander MiselMys 721txPanintelizeNbfreeh:@CarrotkitTechyanJasonzhuocnChenyijia001:前來討論。-和平、奮鬥、救地球!於 2016年4月6日 (三) 00:54 (UTC)

看链接,此沙盒非彼沙盒,这里沙盒特指WP:SB或相关预设的类似功能的沙盒页面,而不包括用户子页,用户子页可以作为新建条目的沙盒,但不是所定义的沙盒。这句话只是限制对WP:SB的逻辑误删。——路过围观的Sakamotosan 2016年4月6日 (三) 01:03 (UTC)
IAR,从G字的定义来说,只要是看上去想像广告,任何人都可以都做适当的事,该回退就回退,该删除就删除,鬼管是预设沙盒还是用户子页,然后需要时背个书就是了。适当地灵活应对。——路过围观的Sakamotosan 2016年4月6日 (三) 01:07 (UTC)
“不要在沙盒進行廣告宣傳或刷编辑次数,否則可能會被封禁”。这是WP:SB里面写明的,说明沙盒并不是法外之地。但如果想要引导用户做出正确的编辑,不妨设置一个时限【比如24小时或者更短】,规定时限内没有对广告内容做出根本改善,那就删掉沙盒并且小黑屋伺候。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年4月6日 (三) 01:09 (UTC)
本來就很適用。--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年4月6日 (三) 01:11 (UTC)
個人沙盒應比照其他頁面處理,不應因「沙盒」兩字而受到差別待遇。--Carrotkit歡迎參與DC14非正式投票 2016年4月6日 (三) 05:28 (UTC)
  • 或許可以擬定一個沙盒專用的WP:CSD標準,比如S1:濫用沙盒、S2:沙盒侵權、S3:沙盒明顯用於廣告用途。--宇帆(留言·) 2016年4月6日 (三) 05:34 (UTC)
我認為適用,如果不適用的話,每個用戶打着沙盒的名義來賣廣告,這還得了?還有@和平奮鬥救地球:請不要在討論一開始就ping人,討論頁指引並不鼓勵的此等做法。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月6日 (三) 06:21 (UTC)
@Cdip150:我是ping當初曾在IRC上參與相關討論的人,以及引發此事件之原提刪者,並非討論一開始。-和平、奮鬥、救地球!於 2016年4月6日 (三) 06:41 (UTC)
的確應該有一套沙盒的 CSD 標準。--就是他 ☞ Q 「參觀 我的用戶頁 」「有事請 給我留言 」 2016年4月6日 (三) 11:38 (UTC)

講實在我覺得另一個很麻煩的問題是,大家對「宣傳」的定義太嚴了。有些人根本沒有任何宣傳的動機跟意圖,只是貼的文字不太會修整,受到來源的影響,這也會被誤認為廣告宣傳。

補個實例好了,最近一個情況是使用者建立的頁面90%都是一個政府政策的「大事記表格」,也沒說政策是德政、長官英明,然後也被警告宣傳,先是提速刪後來改貼模板。我看了半天只能猜想大概大事記最後幾項有寫到跟特定企業發起合作宣傳案,稍微有那麼一點點像廣告(也在很邊緣)。

如果看起來沒有太大直接利益的文字,可否用主動修改替代速刪;另外沙盒部分雖然不可能成為化外之地,但操作上可不可以先詢問溝通再動作,不然有時候我都覺得推廣者在前線要開的是作文寫作班了。--Reke留言) 2016年4月6日 (三) 11:00 (UTC)

由于滥挂{{csd}},我已经警告过不知道多少位巡查员了。--Antigng留言) 2016年4月6日 (三) 11:12 (UTC)
吱一声。以后用鸭子 一望而知来判断。-- learningis1st留言|工作区|欢迎加入密码学专题 ฿ 2016年4月14日 (四) 19:32 (UTC)
不只是濫掛的問題,而是對文字過度挑剔,而且挑剔之後不是自己改,是對原創作者施壓。我不至於認為這會導致完全無法推廣,但會逼迫推廣者只能慢慢傾向讓新手先在維基以外的平臺寫文章,寫到安全了再貼到百科上。這其實是很糟糕的文化,會衍生包括協作意願低落、條目完成時間拉長,甚至會因此讓實體聚會中的新手對老手過度依附,各地社群鄉勇化。--Reke留言) 2016年4月6日 (三) 11:20 (UTC)
“快速刪除(简称速删)旨在加快處理顯然不合适的頁面或文件,省去存廢討論的時間。”不等于“所有顯然不合适的頁面或文件都需要快速删除。”--Antigng留言) 2016年4月6日 (三) 11:27 (UTC)

(!)意見有爭議的內容就應該送審查頁面進一步討論而不適合速刪,無論是沙盒與否。--泅水大象訐譙☎ 2016年4月6日 (三) 12:36 (UTC)

cwek已经说得非常明白,沙盒指的是WP:SB这个单一页面。Bluedeck 2016年4月7日 (四) 03:29 (UTC)
除非页面存在的问题是一眼已发现明显符合快速删除方针,否则快速删除应可免则免。因为判断快速删除的参与者通常不出挂模板者及管理员两人,容易出现主观判断,所以页面如不是明显破坏,应转交存废讨论,由更多用户参与决定其存废。最近有不少新条目,虽然只有第一方来源,或有宣传情况,但这些来源有缺的条目,本应循关注度处理,给编者有时间增补来源,其他用户也可协助整理条目内容,但近期有不少巡查者却直接以 G11请求快速删除,连关注度程序都跳过,而没有把删除页面作为最后手段。--Thomas.Lu留言) 2016年4月10日 (日) 16:28 (UTC)
我個人更傾向於支持G11適用於個人沙盒,不然可能會有很多人利用這個空子,利用維基百科來作廣告宣傳。像吳語維基百科那裡就有很多人利用用戶頁來搞廣告宣傳,弄得是一團糟。我怕中文維基也會成為那樣。--el caballero de los Leones (Ajouter un message)CKJV 2016年4月13日 (三) 11:59 (UTC)
建议G11适用于沙盒,自己向来也是这样做(可能以后会更注意AGF)。但像 Topic:T1wjv9wrg7ain1ci 这样的例子我也觉得无法避免。(&)建議 在Editnote里说明沙盒里不建议放什么什么。 -- learningis1st留言|工作区|欢迎加入密码学专题 ฿ 2016年4月14日 (四) 19:09 (UTC)

根據大家在上面的討論,我有以下提案:

  1. 既然個人沙盒非法外之地,將「以下标准适用于所有名字空间中的页面,沙盒页面除外。」改為「以下标准适用于所有名字空间中的页面,公用沙盒页面除外。」
  2. 鑑於避免誤會,且删除页面为最后手段,或許可在G11之說明加上「即便該頁面具有宣傳情況,除非您可以非常確定該頁面建立僅為廣告宣傳而建,否則應以關注度提報或提刪替代」之類的提醒。
  3. 對於個人沙盒頁面應採用比主條目頁面更寬鬆的規範,畢竟就算在個人沙盒裡面打廣告,其效果應該也不大,原作者也可能只是先雜亂堆積一些資料在沙盒而非為了進行廣告。
以上。-和平、奮鬥、救地球!於 2016年4月18日 (一) 01:53 (UTC)

(+)支持Peace的观点。--Techyan留言) 2016年4月23日 (六) 12:24 (UTC)

应该删掉“沙盒页面除外”。本来速删就是针对新建页面,非新建页面出现符合CSD问题优先回退,没必要想着沙盒如何如何。 --达师 - 334 - 554 2016年4月24日 (日) 12:48 (UTC)

@和平奮鬥救地球:希望此項討論儘快完成並進行公示。--Temp3600留言) 2016年5月9日 (一) 14:15 (UTC)
(!)意見,@Hat600:不赞成删掉“沙盒页面除外”,万一真有人在WP:SB上挂速删怎么办?--Stang c 2016年5月11日 (三) 09:50 (UTC)
根据以下的原因,您并无权限去删除本页:
这个页面有一个十分大量的编辑历史,超过5,000次修订。删除此类页面的动作已经被限制,以防止在Wikipedia上的意外扰乱。如需删除请联系监管员。--Jimmy Xu 2016年5月11日 (三) 13:04 (UTC)
删除页面: 不能删除页面:You can't delete this page because it has more than 5,000 revisions。--Nbfreeh 2016年5月11日 (三) 13:08 (UTC)
这警告谁翻译的……“有一个十分大量的编辑历史”。--Kuailong 2016年5月11日 (三) 16:57 (UTC)
原来是jimmyxu干的好事。--Antigng留言) 2016年5月12日 (四) 02:38 (UTC)
special:permalink/23203388...--Stang c 2016年5月12日 (四) 03:34 (UTC)
远比这个悠久,例如[5][6]--YFdyh000留言) 2016年5月25日 (三) 01:34 (UTC)
那这一行都可以删掉啦。--Stang c 2016年5月12日 (四) 03:34 (UTC)
(!)意見:我認為Wikipedia:快速删除方针所指的「沙盒頁面」指的是具有Wikipedia:沙盒功能的頁面,並非User:<用戶名>/沙盒--林勇智 2016年5月12日 (四) 08:10 (UTC)
@和平奮鬥救地球:請速回覆。--Temp3600留言) 2016年5月12日 (四) 13:04 (UTC)
@Temp3600:大家還在討論沙盒那段要不要刪掉,不要那麼急...-和平、奮鬥、救地球!留言DC14討論於 2016年5月12日 (四) 13:11 (UTC)
@和平奮鬥救地球:那您對這個議題的看法是?--Temp3600留言) 2016年5月12日 (四) 13:13 (UTC)
雖然實測使用一般刪除方法與TW刪除方法皆無法成功刪除WP:SB,但我不確定技術上是否有其他辦法刪掉它(例如出現了某種bug、用某種我不知道的方法繞過或取消阻擋、甚至分拆頁面歷史使之少於5,000),但如果這麼做應該也是擾亂了。因此我認為這句是可刪可不刪的(畢竟還是不行去删公用沙盒)。-和平、奮鬥、救地球!留言DC14討論於 2016年5月12日 (四) 13:18 (UTC)
@和平奮鬥救地球:我覺得用沙盒來測試掛AFD並無不可。--Temp3600留言) 2016年5月12日 (四) 15:46 (UTC)
(*)提醒@Temp3600WP:AFD並非速刪唷。-和平、奮鬥、救地球!留言DC14討論於 2016年5月13日 (五) 00:25 (UTC)
打錯,是csd--Temp3600留言) 2016年5月13日 (五) 01:37 (UTC)
測試掛CSD並無不可,只是不要刪掉它。-和平、奮鬥、救地球!留言DC14討論於 2016年5月13日 (五) 02:09 (UTC)
@和平奮鬥救地球:既然已經沒人討論,建議盡快總結。--Temp3600留言) 2016年5月19日 (四) 12:18 (UTC)
那就根據上方討論總結如下:
  1. 將「以下标准适用于所有名字空间中的页面,沙盒页面除外。」改為「以下标准适用于所有名字空间中的页面。」
  2. 在G11之說明加上「即便該頁面具有宣傳情況,除非您可以非常確定該頁面建立僅為廣告宣傳而建,否則應以關注度提報或提刪替代」的提醒。
以上。現進行公示,7日內如無其他意見,將進行更新。-和平、奮鬥、救地球!留言DC14討論於 2016年5月19日 (四) 12:27 (UTC)
关于沙盒方面,如果是预制沙盒(如WP:SB的话),应该是优先为回退;对于用户子页沙盒的话,应该是可以考虑G11或提删;关注度只适用于条目而非其他非条目页面。——路过围观的Sakamotosan 2016年5月20日 (五) 05:49 (UTC)

已公示超過7日,故進行更新。-和平、奮鬥、救地球!留言DC14討論於 2016年5月27日 (五) 01:40 (UTC)

有关Wikipedia:垃圾内容的提议[编辑]

为了有效治理中文维基百科的垃圾(含有广告的)内容,我刚刚从英文版翻译了Wikipedia:垃圾内容一文(他们英文版早有这一指引了,我们还没有)。请大家对该指引的全部条款提出意见。我期望能达成共识,可以成为中文维基百科的正式指引(我来了两次互助客栈方针区都没有实现,期望这一次一定能实现),谢谢。--Shwangtianyuan 留言在此 2016年5月12日 (四) 04:24 (UTC)

  • (-)反对成为中文维基百科的正式指引,“伪装成条目的广告”一章节“以招揽业务、产品或服务,或者是公关件宣传公司或个人的条目均视为广告……明显伪装成条目的广告可以通过添加快速删除模板{{d|G11}}或{{d|spam}}的形式删除,此规则同样适用于用户页和草稿名字空间。其他含有广告内容的条目可以通过頁面存廢討論提交删除。”这是在以作者创作条目的目的推定条目是否应该存在,而不是以条目本身是否符合内容方针来评判条目是否应该存在。--Antigng留言) 2016年5月12日 (四) 05:17 (UTC)
    • A君啊,我可是从英文版翻译过来的,阁下居然反对?我感觉阁下的观点极左或者极右……--Shwangtianyuan 留言在此 2016年5月12日 (四) 06:22 (UTC)
      • 你为什么觉得从enWP翻译过来的东西我一定会支持呢?--Antigng留言) 2016年5月12日 (四) 06:26 (UTC)
        • 老乡啊,没有为什么。另(~)補充,有的内容还没有翻译完整,故大家可以协助翻译完整,请知悉。如果翻译完成,烦请阁下删除反对票,谢谢。--Shwangtianyuan 留言在此 2016年5月12日 (四) 06:28 (UTC)
          • 这不是翻译不完整的问题,而是我本身就反对enWP这种论述。--Antigng留言) 2016年5月12日 (四) 06:31 (UTC)
    • 人家想投什么票就投什么票呗...还有Antigng不是反对en的G5吗。--Stang c 2016年5月12日 (四) 10:55 (UTC)
      • 就是啊,个人观点仅供参考之用。我认为,我们中文维基的所有指引和方针都是基于英文版发展而成的。TA这么一说,大概认为,各语言维基百科的指引和方针都是独立的。--Shwangtianyuan 留言在此 2016年5月13日 (五) 02:24 (UTC)
        • 弃其糟粕而取其精华。--Antigng留言) 2016年5月13日 (五) 02:42 (UTC)
"含有广告内容的条目"錯譯,EN要求是全廣告。Antigng提的問題正想辦法解決。--Temp3600留言) 2016年5月12日 (四) 17:05 (UTC)
  • (-)反对。冗餘,Wikipedia:维基百科不是什么已經足夠對付廣告,理事會早於2011年的決議已呼籲社群簡化方針和指示。--Mewaqua留言) 2016年5月13日 (五) 03:26 (UTC)
    • 也没感到冗餘啊,人家英文版,早有了,我们中文版就没有。--Shwangtianyuan 留言在此 2016年5月13日 (五) 04:58 (UTC)
  • (?)疑問--對於在中文維基百科的生態下,在下對此方針會怎麼被理解與擴大詮釋,感到頗有疑慮。Wetrace歡迎參與人權專題 2016年5月13日 (五) 05:02 (UTC)
    • 现在的巡查员看什么都像G11。--Antigng留言) 2016年5月13日 (五) 09:06 (UTC)
@Antigng:我看了看英維的討論,發現人家這個guideline與對抗link farm有關。那麼你認為中維應採用何種方式對抗link farm?--Temp3600留言) 2016年5月13日 (五) 14:37 (UTC)
Wikipedia:外部链接#正常情況下應避免的連結 --Antigng留言) 2016年5月13日 (五) 14:42 (UTC)
参考来源不同于外部链接,条目不应有多个外连,有不少条目同时连往其官方的网站、youtube、FB,会有以维基百科作为其宣传网站的情况,条目如果符合可供查证、关注度,也只留一个官网外连,其他外连都应该删除。--Thomas.Lu留言) 2016年5月13日 (五) 15:04 (UTC)
@Antigng:那目前有何種措施對抗垃圾引用?--Temp3600留言) 2016年5月15日 (日) 14:37 (UTC)
Mediawiki:Spam-blacklist--Antigng留言) 2016年5月15日 (日) 14:49 (UTC)
@Antigng:這個不是法源基礎啊--Temp3600留言) 2016年5月15日 (日) 15:12 (UTC)
你问的是措施,我回答的是技术措施。如果你要问相关的方针,那么Wikipedia:外部链接#廣告與利益衝突就够了。--Antigng留言) 2016年5月15日 (日) 15:16 (UTC)
@Antigng:「本指引是關於外部連結,並非來源。」--Temp3600留言) 2016年5月15日 (日) 15:23 (UTC)
@Antigng:那麼「某些有不同wiki引擎、数据库的机器人,亦会在条目中插入外部链接。他们的目的是提高外部网站的搜索引擎排名,而不是直接发布他们的产品。」這一節能用Wikipedia:外部链接解決嗎?--Temp3600留言) 2016年5月13日 (五) 16:09 (UTC)
spambot本来就违反机器人方针啊。--Antigng留言) 2016年5月13日 (五) 16:16 (UTC)
(-)反对,除非说明为何要学习英文版成为方针,而不是学习法语版西班牙语版不成为方针?--Gqqnb留言) 2016年5月18日 (三) 06:46 (UTC)
@Gqqnb:本指引為對抗垃圾引用提供了法源依據。--Temp3600留言) 2016年5月19日 (四) 11:31 (UTC)
英文也不是方針啊,是指引。(小聲說)然後你給的西班牙語也是指引--Liaon98 我是廢物 2016年5月19日 (四) 12:00 (UTC)
那是我疏忽了。。我分分钟就可以找几个不是指引的维基。他立法程序有问题,看到英文版有垃圾内容指引,“Whoa, Spam guideline is excellent!”,然后就要导入中文维基。1、英文中心主义,英文有什么中文也得有什么?2、不平衡信息,虽然该法案在英文通过了,有没有不被其他语种通过的案例?--Gqqnb留言) 2016年5月19日 (四) 16:23 (UTC)
@Gqqnb:我的發言中並沒有提及其他語言,而是為此指引為什麼要引入中文維基提供了理據。--Temp3600留言) 2016年5月20日 (五) 16:23 (UTC)
但这个指引其他部分有问题。--Antigng留言) 2016年5月20日 (五) 16:25 (UTC)
@Antigng:這點我承認。要不這樣:將(垃圾外部链接)一節升為指引,其他視為論述,如何?--Temp3600留言) 2016年5月20日 (五) 17:13 (UTC)
若是这样。这部分内容也应该是列于WP:外部链接处,而不是这样一个尴尬的页面内。PS:对于这个页面的译名不敢苟同。乌拉跨氪 2016年5月20日 (五) 17:20 (UTC)
@乌拉跨氪:問題是WP:外部链接第一句就是「本指引是關於外部連結,並非來源。」,而目前要解決的是垃圾來源問題。--Temp3600留言) 2016年5月20日 (五) 17:41 (UTC)
那句话的“来源”的意思是指代“参考文献”段落下的引用内容。上述对于外部连接链接内容的规定理应置于此处,而且现实内容已存在“連結什麽網站”近似的段落。乌拉跨氪 2016年5月21日 (六) 13:04 (UTC)

设立机器人除权机制[编辑]

之前进行了两次讨论,但不知为什么都沉了,也没修改方针。由于不活跃的机器人账户安全隐患大,建议加入:

如果机器人一年之内没有编辑,行政员会去询问操作者。如果30天后仍未给出回复,机器人的权限会被移除。如果操作者表示仍希望保留权限的,则保留权限。

需要除权的机器人列表可见于此处。希望这次可以达成共识,写入方针。--Stang c 2016年5月12日 (四) 11:13 (UTC)

看来还要剔除已经本地授权的跨域机器人账号。——路过围观的Sakamotosan 2016年5月14日 (六) 11:10 (UTC)
  • (+)支持,見;少;安全;yinhuan。Qinyongr 給我留言 」「歡迎加入 #cvn-zh-scan 2016年5月12日 (四) 11:45 (UTC)
  • 我的建议是不要所有情况都执行,原因是有像jimmy、才女的机器人之类的对中文维基百科维护起非常重要作用的机器人,如果未来有一天这种机器人的操作者淡出了维基百科,并且没有新的机器人取代,那么取消bot真的好吗。。--Nbfreeh 2016年5月12日 (四) 13:16 (UTC)
    • 这样的话,万一哪天机器人坏了,更是隐患。--Stang c 2016年5月13日 (五) 00:08 (UTC)
这个没问题,一直以来都有“如果机器人出故障可以立即封禁来阻止工作”。——路过围观的Sakamotosan 2016年5月13日 (五) 02:10 (UTC)
不少bot是开放源代码的,出事了封禁然后换个人用个新帐号跑就是了。--Antigng留言) 2016年5月13日 (五) 09:08 (UTC)
  • 我觉得应当是“如果机器人及其操作者一年之内没有编辑”。--Antigng留言) 2016年5月13日 (五) 13:28 (UTC)
    • 同意Antigng所说。--1=0欢迎河北维基人加入QQ群331736133 2016年5月13日 (五) 16:06 (UTC)
    • 一大堆iwbot的操作者都不在本地,应该不需要扩展到全域编辑数吧?--Jimmy Xu 2016年5月13日 (五) 16:08 (UTC)
      • 维护重定向/interwiki的一般不都是全域机器人吗?--Antigng留言) 2016年5月13日 (五) 16:21 (UTC)
  • 情況很複雜,一個一個單獨討論可能效果更哈。--Qinyongr 給我留言 」「歡迎加入 #cvn-zh-scan 2016年5月15日 (日) 08:42 (UTC)
    • 没看到什么复杂的,排除个别就行啦。--Stang c 2016年5月22日 (日) 01:07 (UTC)

繁中字[编辑]

此讨论已经结束,请不要对此存档作任何编辑。 Stang 2016年5月28日 (六) 04:25 (UTC)
你好
我來自中華民國(Republic of China)
電腦設定只能打正體中文字,無法打出簡體,
卻一直被維基的機器人要求要使用簡體字,一次修改大量時,還被威脅不能再編輯
我感到非常憤怒,因為正體中文也是文字,不該遭受這樣對待
我認為維基應該開放繁體中文的使用,讓維基可以更自由的編輯
因為維基百科的格言即是如此
如果查看此客服的人員是來自共產黨統治的中華人民共和國,我希望你可以立刻呈報此事
謝謝
--Lin--—以上未簽名的留言由Bill0228對話貢獻)於2016年5月14日 (六) 22:22加入。
哪里有什么客服人员,而且繁体中文哪里禁止了?况且党派能代表什么?!--Nbfreeh 2016年5月14日 (六) 14:31 (UTC)
你一共就做过三笔编辑,而且没触发过过滤器,所以我无法确定问题出在哪里。如果你是匿名编辑的时候收到了机器人的警告,多半是你做出了WP:繁简破坏。简而言之,维基百科可以用简体也可以用繁体,但是不允许把别人写得简体字改成繁体字,反之亦然。--Antigng留言) 2016年5月14日 (六) 14:35 (UTC)
看你的編輯紀錄,似乎沒有你說的編輯歷史存在誒?--Liaon98 我是廢物 2016年5月14日 (六) 14:37 (UTC)
@Bill0228:中文維基接受正體中文的編輯,也未見台灣當局限制電腦不能輸入簡體字。如要輸入簡體字,可以通過設定輸入法或安裝輸入法軟件達成。另外,閣下可在新加入的內容自由選擇用正體字或簡體字,但不應把現有的內容直接更改為正體或簡體,因為這是繁簡破壞,會被還原為原有字體的。--Thomas.Lu留言) 2016年5月14日 (六) 15:33 (UTC)
我看應該是原本簡體字改成繁體字後被機器人報告繁簡破壞,提到若繼續繁簡破壞會被封禁。--宇帆(留言·) 2016年5月14日 (六) 17:05 (UTC)
@Bill0228:,请指出出现情况的条目,我们会检查情况并说明原因。如果不能,我会给你一个评价——骗子(估计你们会很喜欢这个称号的(笑))。——路过围观的Sakamotosan 2016年5月15日 (日) 03:56 (UTC)
@Cwek:「估计你们[何意?]会很喜欢这个称号的」。-和平、奮鬥、救地球!留言DC14討論於 2016年5月15日 (日) 04:09 (UTC)
(滑稽)——路过围观的Sakamotosan 2016年5月15日 (日) 04:30 (UTC)
欸,這個有點地域……了吧。(可能是我因為某些事情對這個過於敏感了)--Artoria2e5 更改·工具 2016年5月16日 (一) 15:58 (UTC)
老范的中二病。(保持滑稽)——路过围观的Sakamotosan 2016年5月17日 (二) 01:32 (UTC)
楼主可能需要查看Wikipedia:客服人员Wikipedia:威胁不让你编辑Wikipedia:来自共产党统治的中华人民共和国(滑稽#ForeverLove凡人丶 你一定要好好的 中文字数统计工具 2016年5月21日 (六) 05:44 (UTC)
分别幽默重定向到WP:BOTWP:WARNWikipedia:坏笑话和删除的胡话/User_talk:119.81.157.98。——Artoria2e5 更改·工具 2016年5月21日 (六) 23:10 (UTC)

提议条目导言的外文添加规范[编辑]

1、对于人物,至多提供所在国籍的语言的名称。
阿尔伯特·爱因斯坦德语:Albert Einstein英语:Albert Einstein),因为爱因斯坦有德国国籍和美国国籍。
2、对于属于一个国家的地区,至多提供所在国的语言的名称。
科爾多瓦(西班牙语:Córdoba),因为是西班牙的城市。
3、对于机构,至多提供官方工作语言的名称;若无,则按照(1)获取创始人的常用语言及按照(2)获取总部所在地的语言的名称。
高露洁-棕榄英语:Colgate-Palmolive),因为创始人en:William Colgate是英国人,因为总部在美国纽约。
联合国开发计划署阿拉伯語الأمم المتحدة英语:United Nations Development Programme法语:Programme des Nations unies pour le développement俄语:Программа развития ООН西班牙语:Programa de las Naciones Unidas para el Desarrollo),因为联合国六种官方工作语言。
4、对于事物、作品,至多提供按照(1)或(3)获取的作者的语言,按照(2)获取的所在地的语言。
蒙娜丽莎意大利语:La Gioconda),因为作者达芬奇是意大利人。
自由女神像英语:Statue of Liberty法语:Statue de la Liberté),因为自由女神像在美国,作者弗里德利·奥古斯特·巴特勒迪是法国人。
钢铁雄心瑞典語Hearts of Iron),因为作者Paradox Interactive在瑞典。
5、对于100年以内的发明、发现、概念,至多提供按照(1)或(3)获取的发现者、发明者、继承者的语言。
玻色–爱因斯坦凝聚孟加拉語বোস - আইনস্টাইন ঘনীভবন德语:Bose-Einstein-Kondensat英语:Bose–Einstein condensate),因为发明者萨特延德拉·纳特·玻色为印度人,发明者爱因斯坦有德国国籍和美国国籍。
美洲,不添加外文,因为哥伦比发现新大陆(美洲)早在100年以前。
苹果,不添加外文,因为苹果早在100年以前被发现。

--Gqqnb留言) 2016年5月18日 (三) 08:16 (UTC)

  • 欧洲联盟有24种官方语言(同时也是工作语言)。 --达师 - 334 - 554 2016年5月18日 (三) 08:46 (UTC)
(!)意見:上面大部分的規則都同意,但我也認為工作語言全列應該是有實務上的問題的。遇到這種狀況時,雖然會有偏頗特定語言的疑慮,但不得已的狀況下或許只能考慮單列英文了(畢竟是全球最通用的語言)。還有,當外文使用的文字並非拉丁文字時,或許得考慮增列該語言的拉丁轉譯拼寫版本,畢竟我們不能假設中文維基的讀者都看得懂這些特殊文字,但幾乎可以確定的是只要懂得打開電腦上網查閱維基百科的人,都一定看得懂拉丁字母。--泅水大象訐譙☎ 2016年5月18日 (三) 12:16 (UTC)
大概支持,我認為如果要顯示的語言過多,則以英語替代,其他照常。--Q 「有事請留言 ,而不要 Ping 我 2016年5月18日 (三) 12:32 (UTC)
没有说明国家的语言是官方语言还是通用语言还是并集。大体支持,同意偏袒英语的做法。对于药理学医学化学条目个人认为多语言名称应该直接用INN、IUPAC之类(前者优先级大于后者)的国际名称(基本上是英语)。--Artoria2e5 更改·工具 2016年5月18日 (三) 15:33 (UTC)
大体支持,但是不建议上升为方针指引,实务上问题很多。比如提案中举的例子:
钢铁雄心瑞典語Hearts of Iron

就是个问题……--哪位维基人能够一下打死五个? 2016年5月19日 (四) 01:27 (UTC)

钢铁雄心瑞典語Hearts of Iron)有什么问题?--Gqqnb留言) 2016年5月19日 (四) 03:41 (UTC)
問題出在Hearts of Iron很顯然不是瑞典語吧?這遊戲雖然是瑞典廠商開發的,但打從一開始就沒有用瑞典語而是用英語命名,所以上面的標示方式有問題會造成讀者的困擾。--泅水大象訐譙☎ 2016年5月19日 (四) 04:53 (UTC)
提案里没有提及任何语言,不觉得非常中立吗?我就在避免英文中心。既然左边“其他语言”栏列举了所有语言,为什么还要在条目导言添加英文?想要知道某种语言,去左边其他语言找就行了,何必要求编者一定要写进去。可能有些人会英语,觉得英语很重要,什么条目都最好加英语。但有人可能是阿拉伯语工作者,觉得阿拉伯语很重要,什么条目都最好加阿拉伯语……提案里进行了限定,最多只能加这些。至于欧盟24种工作语言,不反对增设“如超过X种语言,则单独列出,不写在括号里”。--Gqqnb留言) 2016年5月19日 (四) 03:41 (UTC)
interwiki有時會有無法替代首段文章內標示外文原文功能的情況,例如條目主題雖是外來概念但卻沒有其他語版的對應條目,或者interwiki連結的條目雖然與中文維基的條目內容有共通性,但標題並不是對等的翻譯。在鐵路相關條目偶爾會遇到後者的情況,例如某家小鐵路公司只經營一條鐵路線,在中文維基可能是以鐵路公司為主角撰寫條目,但在其他語版卻是以鐵路線為主角撰寫條目,二者之間以interwiki連結,雖然這樣的跨語言連結算是合理的作法,但畢竟鐵路公司≠鐵路線,若不在條目內文中寫清楚主題的外文原名,直接利用interwiki參考其他語版不見得可以查閱得出該概念的原文。
我相信參與中文維基運作較久的用戶都理解應盡量避免英文中心的必要性,所以大家都同意要盡量使用主題概念所屬文化圈的語言而非英文來作為外文標示,但相對的,如果不能正視英文是全世界最普及的第二語言這事實,只是為了追求齊頭式的中立而蓄意在必須使用英文時故意不用的話,那只能說是做過頭走火入魔。請注意會阿拉伯語的人覺得阿拉伯語重要是個人的「主觀」認定,但以英語為母語再加上以英語為第二語言的人口數全世界佔比最高卻是一個「客觀」的統計事實,基於這個事實在某些不得已的場合給予它稍微多一點的優先權重是必要之惡。除非有人能想出更好的方案,能同時兼顧讀者閱讀認知的便利性,與各語言之間的平等兩種需求,否則我還是會支持以讀者閱讀便利性優先的方案,畢竟這裡是維基百科寫出來的東西是要給人閱讀,而不是什麼語言公平的實驗場……--泅水大象訐譙☎ 2016年5月19日 (四) 04:53 (UTC)
(!)意見--泅水大象說的挺好。其實並不是有意偏袒使用英語,而是大多數華人使用的第二語言,就是英語,幾乎成了接軌國際的必要與現實。讀者進一步查詢資料、比對,也是透過英語字彙。Wetrace歡迎參與人權專題 2016年5月19日 (四) 08:11 (UTC)
虽然不知道interwiki里铁路公司连铁路是否是正确的做法,但既然现时有这样的问题,那何不要求“仅当其他语言栏列出的条目外文名与中文维基条目名不同时,才可在括号内添加对于中文条目名的外文”。想要知道其他语言的名称,去其他语言栏看总可以了吧?--Gqqnb留言) 2016年5月19日 (四) 16:37 (UTC)
(!)意見:其一,interwiki會隨著時間的前進而陸續被添加/刪除,一時之間可以對應並不表示未來一定都可以對應,但條目的編輯者不可能沒事定期回去核對這有效性,相反的,把外文名稱標註在條目首段可以經得起時間改變的考驗;其二,編輯者不見得看得懂其他語版的標題/內容,不見得能幫忙確認interwiki的條目名是否對應。為了一個虛無飄渺的語言公平理念結果把規則搞得超複雜又可能會常常產生不必要的錯誤,我不覺得對全體維基百科讀者的閱讀權益是有利的。--泅水大象訐譙☎ 2016年5月20日 (五) 06:07 (UTC)
(!)意見:另外,除了鐵路條目的對應關係外,軍艦或船舶相關的條目也常因一艘船轉手在不同國家服役時名字不一樣的緣故,而出現不同語版使用不同時期船名作為條目名的不對稱情況。利用interwiki並不見得能輕易查到譯名對等的原名。--泅水大象訐譙☎ 2016年5月20日 (五) 08:44 (UTC)
(?)疑問对地理上横跨多国的事物该如何命名呢?--4Li 2016年5月19日 (四) 08:54 (UTC)
本提案并不排他,你若有兴趣可添加规则。--Gqqnb留言) 2016年5月19日 (四) 16:37 (UTC)
这样很容易出现首句一长串外语干扰阅读。--4Li 2016年5月19日 (四) 20:01 (UTC)
  • 若人物本身虽然是某国籍但自己不讲这门语言,或者虽然是某国籍但主要活动区域在该国语言范围以外;又如上述钢铁雄心。
  • 涉及地方性语言,比如印度各邦的官方语言,或者加拿大新加坡等具有多种官方语言的国家。
  • 官方语言过多的情况,如上述欧洲联盟
  • 反对5。首先100年没有道理;或者说是OR。其次很可能出现一些业界完全在用英语讨论的概念却由于发现者不是英语母语反而没标英语的情况。
  • 及,苹果要注学名。以上。 --达师 - 334 - 554 2016年5月19日 (四) 11:09 (UTC)
学名不受上述提案影响,因为没有“学名维基”。一定要知道英文何不用左边其他语言栏?--Gqqnb留言) 2016年5月19日 (四) 16:37 (UTC)
学名是拉丁语。 --达师 - 334 - 554 2016年5月21日 (六) 14:19 (UTC)
  • 补充一下,钢铁雄心那个例子是不正确的。电子游戏条目方面,条目指引WP:VG/EN已经对外文标注做出了明确规范。—Chiefwei - ) 2016年5月19日 (四) 12:01 (UTC)
  • (-)反对第(1)點「至多提供所在國籍的語言的名稱」,請問邁特里帕拉·西里塞納是否只能標示「僧伽羅語:මෛත්‍රිපාල සිරිසේන,泰米爾語:மைத்திரிபால சிறிசேன」而不能標示「Maithripala Sirisena」?反對為了「政治正確」而進行無益的擾民行為。--Mewaqua留言) 2016年5月20日 (五) 05:18 (UTC)
Mewaqua君的意見呼應了我最前面「當外文使用的文字並非拉丁文字時,得考慮增列該語言的拉丁轉譯拼寫版本」的主張。雖然維基百科有一些需要維護的基本主張,但如果為了政治正確而把規則訂得太違反常理,或甚至影響到讀者閱讀便利時,就應該得思索是否能透過其他的折衷方式達到兩全。舉例來說,像上面提及歐盟之類單位工作語言過多,全部列出會影響到文章閱讀順暢時,我們是否可以考慮改用註釋NoteTag的方式來收納這些原文名稱?一來可保持條目首段的簡潔,但有必要查閱的讀者只要將滑鼠移過去就能立刻查閱到原文名稱,不需利用一一點入interwiki去查這種有違正常閱讀流程的奇怪方式捨近求遠。--泅水大象訐譙☎ 2016年5月20日 (五) 06:07 (UTC)
泅水大象分离地看待首段括号和interwiki,但我认为首段括号和interwiki提供的是几乎相同的信息(除了铁路线连铁路公司)。我承认首段括号和interwiki在页面上处于不同的位置。能否用JavaScript把interwiki里的外语按照读者选择,自动搬运进首段括号(除了标明的特殊情况)?
比如大象喜欢看英文、法文、德文,JavaScript自动把interwiki里的英文、法文、德文名称搬运进首段括号里。如果页面代码特别指定了法文名称,则采用指定的名称,忽略interwiki的法文。
好处是减小页面体积,不需要列出外文名称了,除非某外语维基的条目名称不同;而且自动解决了争吵10多年的条目导言外文添加问题,因为不用添加了。可能的坏处是修改了页面DOM,导致重绘,有些人称其为页面闪烁(这眼睛得多快啊,重绘在10毫秒内就可完成)。
--Gqqnb留言) 2016年5月21日 (六) 01:19 (UTC)
(!)意見:我會把interwiki跟主文首段分離是用百科讀者的角度思考事情,對於不熟悉維基百科系統的人來說不見得每個人都懂左邊的interwiki可以查閱其他語言原名,但該連結又不見得跟條目主題是一對一直譯這一類複雜的背景規則。如果真如Gqqnb君所言有人可以靠技術方式解決這問題的話我當然樂觀其成,但在此技術發展出來之前一切只是空談,interwiki還是無法取代首段的原文標示。至於為了要避免爭吵而蓄意把一件對讀者閱讀便利有幫助的作法給取消,這就是我說的走火入魔、捨本逐末,如果是對讀者有幫助的標示,就算會造成爭吵也應該想辦法解決它,而不是犧牲讀者的便利性。--泅水大象訐譙☎ 2016年5月22日 (日) 14:35 (UTC)
(+)支持另外有些浏览器不支持部分非拉丁字符。--4Li 2016年5月20日 (五) 06:27 (UTC)
有些浏览器还不支持CSS呢。浏览器差就要升级浏览器。文字不显示的问题一般是没有装字体,如果读者认为该语言重要,他自己要去装字体。他没有僧伽羅語字体,自然也不会关心邁特里帕拉·西里塞納的僧伽羅語名字。--Gqqnb留言) 2016年5月21日 (六) 01:26 (UTC)
(!)意見:或許看不懂僧伽羅語的人不需要知道原文名稱的寫法,但他/她可能會需要「Maithripala Sirisena」這個拉丁轉寫名去查閱國際媒體是否有針對此人物的更多報導。條目主題或許還能靠interwiki找到搜尋線索,有時遇到一些內文有翻譯名詞但卻沒寫原名的情況,對於後續要協助編修的用戶是非常大的困擾,舉例來說我最近注意到國際鐵路聯盟這條目中有一個敘述提到此組織有一本定期刊物叫《國際鐵路》,但因為中文維基的內文中沒有標註此刊物的原文名,而其他語版的維基又沒有提及到此刊物(至少英文、法文、德文與日文等幾個我看得懂的語版沒提及),官方網站也沒提及,導致我迄今為止還無法查證世界上是不是真的存在這樣的一本刊物,與它實際上的刊名。基於太多這樣的例子,我一直對有人主張要減少中文維基內的外文標示非常感冒。--泅水大象訐譙☎ 2016年5月22日 (日) 14:51 (UTC)
本讨论自始至终讨论的都是条目导言首句针对条目名的外文名。--Gqqnb留言) 2016年5月27日 (五) 00:07 (UTC)
不管是條目名還是內文名詞的原文標註(包含拉丁轉寫),在資料調查與閱讀時的重要性都是共通的。--泅水大象訐譙☎ 2016年5月27日 (五) 03:18 (UTC)
(-)反对方案5,同達師的意見,為甚麼是100年?像是葡式蛋撻這種近200年前的發明敝人認為也應該加外文。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年5月20日 (五) 17:22 (UTC)
汽车巴士要不要加?--Gqqnb留言) 2016年5月21日 (六) 01:00 (UTC)
个人认为有需要加上非中文名的状况有两大类:一是人名、地名等的音译(半音译半意译的可能会比较棘手);二是各种作品、出版品名称的原文(至于具体应该用哪些文字标示另议)。其他类型的是否需要加上原文名,则很容易出现各种例外情况,最好还是个案讨论为宜--百無一用是書生 () 2016年5月23日 (一) 01:58 (UTC)
工業技術之類的名詞有時也很需要標註原文名,主要考量是這類名詞兩岸多地的譯名可能天差地遠,只靠中文內容不見得看得懂所指為何,有時需要靠原文名稱標註當作線索來進行搜索。--泅水大象訐譙☎ 2016年5月23日 (一) 02:57 (UTC)
不同專題有各自的做法吧。--578985s留言) 2016年5月25日 (三) 08:54 (UTC)

愛好者規範[编辑]

維基百科:愛好者內容 是否能針對這類行為進行管理,以管理愛好者熱情的行為不影響編輯方針! 我會碰到的情況是刪除藝人的無來源的錄影紀錄,經過幾次討論發現還是沒法有效解決問題! 大部分愛好者不會管方針 一部分管理者認為不要引起編輯戰就好!結果一直都沒啥結論 無法動作。維基百科討論:愛好者內容 是否可以訂定相關的規則供管理者或使用者遵循? 提議加入,這類愛好者行為反覆還原條目三次後,管理員直接進行全保護一個月! WIKI不見得要多即時資訊,長時間的保護也是避免編輯戰的發生。或是有其他建議或提議討論? Zenk0113留言) 2016年5月19日 (四) 09:05 (UTC)

Wikipedia:愛好者內容僅為WP:論述,非規範,其文風也不適合做指引--Liaon98 我是廢物 2016年5月19日 (四) 09:10 (UTC)
依据方针WP:NOT就可以啊,何况还是无来源的内容,不听劝告执意加入可以视作破坏了。—Chiefwei - ) 2016年5月19日 (四) 11:58 (UTC)
困擾的是管理員對於這議題的處理,部分管理員的立場是覺得造成編輯戰了! 可是當我要問,可行的編輯行為的時後,幾次頻率提保護?幾次頻率提破壞?合宜,我又得不到答案! 我處里的項目都很單一的,我想應該不會有視個案處里的問題才是! 所以才會起個頭討論一下,不管有啥方式 只要不要議題又僵住無法處裡! 能個解決問題就好 Zenk0113留言) 2016年5月19日 (四) 14:23 (UTC)
所以还是管理员的处理方式问题,建议与当事管理员沟通一下。我会觉得视作编辑战太过保守了,无可靠来源的琐碎信息没有收录的理由。—Chiefwei - ) 2016年5月20日 (五) 01:17 (UTC)
我之前说过了,无来源有“找不到来源”和“找得到来源但没有列”两种情况。--Antigng留言) 2016年5月20日 (五) 16:26 (UTC)
就算那些細項清單、列表列上去了可靠來源也是很奇怪?(連結搜集處?) 比較合理的寫法應該是列上可靠來源後,再寫出這個錄影紀錄對於這個人物的重大意義吧? 順便附上過去的討論
很显然找不到第三方来源,如果有的话也是应该谁主张谁举证,否则我当然可以认为找不到。退一步说,就算有可靠来源把录影记录全列出来了,维基百科就得照单全收吗?我们可是有WP:NOT方针的。—Chiefwei - ) 2016年5月21日 (六) 10:27 (UTC)
一点都不显然。以最近被删掉的这一个为例,其中的“| 2014年6月8日 || SBS || Running Man || LEO || Ep.199(客串)”这一项明显有第三方可靠来源介绍。--Antigng留言) 2016年5月21日 (六) 10:48 (UTC)
這是一次文獻,不是嚴謹的可靠文獻。--Jasonzhuocn留言) 2016年5月21日 (六) 11:10 (UTC)
网络媒体引用要慎重,很多明星基本发一条微博或脸书台湾网媒都会有即时报道,按这收录标准可以再开一个“微博/脸书记录”章节。—Chiefwei - ) 2016年5月21日 (六) 11:36 (UTC)
公众人物的传记里面通常本来就有“轶事”一章节。--Antigng留言) 2016年5月22日 (日) 10:53 (UTC)
轶事章节同样不是不经筛选的资料收集处,随便举几条最近的两岸网络新闻:孙红雷晒起床照眼神呆滞 网友:又被自己帅醒邓超发微博认儿媳妇 网友:等等有了媳妇鹿晗怎么办許維恩曬暖男贈傘亮點在上衣陳喬恩賣萌 緊身T勾勒34D好身材。都是可靠来源啊,所以都应该写进去吗?说到底可靠来源只是个最低标准,并不是说有来源就可以收录进维基百科,否则所谓的人物传记必然充斥着这些没营养的东西。—Chiefwei - ) 2016年5月28日 (六) 02:07 (UTC)
允许维基人对可靠来源进行自行筛选会导致原创研究。想象一下如果允许维基人这么做,有两位研究者在相同的刊物上发表了主题相近,但观点相左的综述文章,他们就可以彼此指责对方的文章没营养、没水平,即使发表在可靠来源上观点也不应该收录。说到底,维基百科的门槛是可供查证,可靠来源帮助我们筛选、鉴别事实。可靠来源的知识水平有多高,维基百科的水平就应该有多高。--Antigng留言) 2016年5月28日 (六) 03:26 (UTC)
第一,综述是第三手来源,网络新闻是第二手,请区分。第二,维基百科不是不经筛选的资料收集处,这是白纸黑字的方针。筛选的对象不是来源,而是来源里提供的资料,请区分。第三,如果真的有人涉嫌筛选来源,违反的应该是中立原则,而非原创研究。第四,您没有正面回答我的问题,明星的这些花边新闻层出不穷,都应该全部写进维基百科吗?—Chiefwei - ) 2016年5月28日 (六) 03:50 (UTC)
第三,我自己不喜欢这么做,但是没有死的规定“不可以”。花边新闻层出不穷,反映的是媒体乱象。正如我上文所说,“可靠来源的知识水平有多高,维基百科的水平就应该有多高”。第二,“某些類別的條目是否值得收錄尚在爭議中”,事实上,在个别领域没有达成任何共识。第一,新闻报道可能是原始文献,也可能是第二手来源。第二手来源比第三手来源更适合维基百科。--~~
目前是没有详细的规定,但其实大家都清楚,在明星条目里囊括所有花边新闻,显然不合理,也不现实。现在讨论的情况当然存在争议,现在我们就在争议,但本案最初讨论的是没有可靠来源的录影章节,那显然依据现有方针,移除没有任何问题。—Chiefwei - ) 2016年5月28日 (六) 04:12 (UTC)
  • (!)意見管理員之中也不乏各領域的愛好者(例如日本類條目、鐵路類條目、ACG類條目等等)。如何規範他們,確保他們行使管理員特權時不會因為自己的喜好而偏離中立,希望大家可以參詳一下。--42.98.85.84留言) 2016年5月28日 (六) 02:16 (UTC)

錄影紀錄[编辑]

不好意思! 想請教您 無來源錄影紀錄的問題! 現在有管理員覺得我處理有問題! 一天不超過三次都要算成編輯戰,但是又不提出合宜的處置方式! 其實我有點不知道怎麼做,這個問題我在互助客棧也提過兩次了! 其實根本沒有針對這個問題去解決, 請問您有適當的處理方式嘛?Zenk0113留言) 2016年5月9日 (一) 15:17 (UTC)

管理員Antigng,可以看一下我們的對話紀錄! 第一,我的處理原則是被退回時,我一定會去對方的對話頁表示我的看法、過去的討論紀錄跟互助客棧的連結!重覆3-4次後,我就會提保護或破壞(1-2次有提過,不過照經驗沒有人理) 但是管理員Antigng認為我這樣退回算編輯戰(就算同條目一天沒超過三次也算) 當我詢問看法時,卻沒有提出合宜的處理方式。甚者,覺得不管錄影紀錄是否列入方針,都應該溝通可行編輯方式(就算「錄影紀錄是屬於明顯不可紀錄的百科內容」,處理方法可精簡、可刪除、可合併、可獨立成條目,具體採用哪一種明顯是需要探討的問題。)不過我覺得這個前提是符合百科的編輯內容,如果都不符合方針了,我何需討論處理方式? 發言1 發言2 第二,討論共識這事,管理員Antigng認為那些愛好者沒有去討論就不算有共識! 我都服務到飯都送到嘴邊了 還質疑我為啥不找愛好者討論 發言3 這個議題本來就不應該期待跟愛好者可以討論出啥共識,現在就算等到這個討論歸檔,其實問題還是沒有解決(要等討論結束的是他,但不認同共識的也是他?)! 那我真的不知道怎麼進行這些作業? 另外目前現在他把那些條目 Red VelvetLovelyz INFINITE保護了刪除前的狀態,反而是讓愛好者覺得無來源細項是可行的? Zenk0113留言) 2016年5月10日 (二) 05:54 (UTC)
稍微有所了解了。这是我的总结:您删除内容原因之一:无来源;之二:WP:IINFO。从我看来,两者皆为有效理由。阻止您删除的原因有:1、WP:V要求“在刪除前應給予加入此內容的編者充足的時間來補充來源,否則可能導致他們的不滿。”;2、其他用户对删除的争议。其中1不曾是争论的焦点,仅由我提出,而2由Antigng所提出,但在我看来不构成不能删除的理由。综上,我认为删除操作本身无误。如有纰漏,请补充。(VPP存档讨论 FYI)@AntigngZenk0113Bluedeck 2016年5月10日 (二) 11:00 (UTC)
  1. 无来源有两种情况,一种是确实没来源,是原创研究。另一种是有来源,只是原作者没有列。单纯因为没有引用参考文献就需要直接删除,那么是不是所有带unreferenced模板的条目都需要直接清空/速删呢?如果处理者展示过为查找相关来源做的努力则另当别论。
  2. 是否受NOTINFO限制则见仁见智,有人认为符合、有人认为不符合。即使符合了,处理琐碎内容也有很多方法,包括但不限于精简、合并、直接删除、删除后适量分拆。--Antigng留言) 2016年5月10日 (二) 13:26 (UTC)
user:Antigng[[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:]]1、因为“无来源有两种情况......原作者没有列”,故有“在刪除前應給予加入此內容的編者充足的時間來補充來源”。2、确实也有有道理的地方(尽管我仍将其理解为细碎信息)。而在两方都有可观的理由的情况下,可以就具体情况发起讨论。不过,在无来源获得解决之前,这讨论的意义相对渺小(因为不给出来源到头来还是留不住)。Bluedeck 2016年5月10日 (二) 14:34 (UTC)
同意第一點所說,對於來源有做功課! EX金陽條目,雖然不到可靠來源標準!但是至少讓人知道有做過功課!
  • 那麼討論執行共識嘛? 我過去曾經會多幾個動作, 例如 1.整篇無來源資料移到討論區並標示連結或是提醒重點描述即可,但是這個沒有功效,因為粉絲還是會認定你刪除了! 或是動作2.多掛一個章節無來源模板 一定時間後才清除 但是兩者效果都沒啥用。站在新手教育的立場,我還是會去每一篇還原用戶對話頁提出我的完整看法,雖然多數人不當一回事。而且我也不想再收到編輯戰模版,我一樣控制一天同樣條目不超過三篇 第四篇後我就提保護跟刪除? 或是可否提出可接受的方式 如果都要依個案決定 這樣講法太寵統。以碰過的管理者為例,大概只有您有這樣的反方意見。
  • 方針討論,過去討論中,有人提及 "fans習性根本與維基百科無法相融,而非是我們去反過來配合他們,倒建議制定專門對付fans的破壞處理比較直接有效,重點是如何認定是fans以及破壞處理效用光靠保護與封禁所帶來的後遺症(條目保護使其它ip跟著遭殃、封禁對浮動ip使用者不同人造成冤枉的被封禁)。"。以這個角度出發,是否明定無來源細項可以容許一定時間刪除? 以中文百科而言,很多人會覺得不明定明確條文,就不認帳。就立法而言,這個有點多餘就是(照我目前的動作 現在法規已可解釋)! 但是對於反對者而言或是可以接受被刪除的理由? 或是就是多保護幾次讓粉絲學乖(前提是保護到刪除後的條目) 以上看法 @AntigngBluedeckZenk0113留言) 2016年5月10日 (二) 19:23 (UTC)
    • user:Zenk0113[[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:]],你说你做过工作,我不相信。我挑你最上面那个编辑拿掉的最上面那个内容,明显有节目视频为证,如何找不到来源?--Antigng留言) 2016年5月11日 (三) 07:24 (UTC)
      • 抱歉!這句我完全不懂你在講啥? 可以換個說法嘛? @AntigngBluedeckZenk0113留言) 2016年5月11日 (三) 16:33 (UTC)
        • user:Zenk0113[[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:]]他说的是你在移除这个的时候没有试着找这个来源,所以认为你没有做功课就删了。另外,在我的讨论页面上,就不用单独ping我啦,我能及时看到的。Bluedeck 2016年5月12日 (四) 00:04 (UTC)

喔! 我覺得雙方用詞差有點多! 很多次溝通我常看不太懂!避免我誤會其意,才在您的對話頁留言! 這點是很麻煩您的,先與您說聲感謝! 回到正題,我原文指協助改善愛好者行為時,我"曾經"做過的嘗試跟動作的經驗來與大家討論可行的方式,但是大部份無效就是! 而且該做功課的的不是我,是那些愛好者! 所以我舉了金陽 (藝人)的例子,就算他補了非可靠來源,但是那是有做功課的!

我編輯wiki在意的僅是,如何讓WIKI的方針及編輯行為是一致的! 所以,雖然我不斷移除那些無來源的細項,但是我堅持會去每個用戶的對話頁進行完整的wiki方針告知(也算是一種教育訓練)! 我是不知道管理員的職責,需不需要輔導新人user或是維持wiki方針的合理執行性?但是討論到現在給我的感覺就是目前細項處理無共識,所以我們先不要動作(不要編輯戰),不要做任何改變?然後我們依然存在這些矛盾的方針,如果中文維基的文化如此(容許這些反正也無害的編輯),大家不想做壞人,那我們換個方式思考,中文方針是否可以容許細項? 可以把那些日記 過度統計資料庫的方針刪除,讓我們目前的方針與編輯行為是合理的。 以上只是舉例討論共識。因為跟您對話,常常我要討論大方向 你就挑我小毛病(雙方用詞又常有差距 讓我討論不到重點)。討論到現在,還有一堆議題你沒有回覆我,話題又被帶著走了!所以我才需要找其他管理員確認彼此的認知是否有誤

總結一整串對話下來,我需要知道的事,

  • 第一,你一直要我等所有的討論結束再處理那些細項,但是後來您又補一句愛好者沒有討論,所以你也不會認那些共識。所以我才反問您,您可以接受的程度是啥 (扣除那些不使用方針討論的愛好者,所有管理員目前我只有看到您反對,所以我要達成共識的對象可能只有您)?
  • 第二 ,您可接受程度,對於編輯戰的認知?您第一次掛編輯戰模版時,我就有注意到了,所以之後再處理相關議題我都控制在一天不超過三次。但是你後來又回我那不是重點,是不要編輯戰。但是您一直沒討論到這點,那我一直處於無所適從的狀態,符合了您一句要求,下次又來下一句。那是否可以一次討論完呢?
  • 第三,「另外你不是新用戶了。看看討論頁上面第五個留言吧,那時我還沒註冊呢。」我還是不懂這句是啥意思? 維基本來就不是新人好上手的百科(所以也是我堅持去user討論頁留言的原因),討論就討論就不用酸這些東西了!我也是一直常常try and error被管理員們一步步指正才慢慢學習過體驗過這些方針的。如果您異於常人的快速學習能力,請好好用來幫助新手們! 第五個留言是關注度的討論,我不懂與這次的討論無來源細項有啥關係? 可否解釋?@AntigngZenk0113留言) 2016年5月12日 (四) 03:48 (UTC)
  • user:Zenk0113[[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:]]其实WP:V就是讨论共识的产物,然而WP:3RR也是。实际上我觉得你遇到的问题可以归结为,完全遵守方针的编辑可能会在某些情况下,“打不过”不太遵守方针的编辑。每当这种情况出现的时候,除了像以前一样去互助客栈,还可以在编辑站开始前主动请求页面保护。Bluedeck 2016年5月13日 (五) 02:50 (UTC)
感謝啦!這 也是我困擾的地 方阿! 我一直不知道他對編輯戰的定義是啥? 我就一直被掛編輯戰模版 其實也不是很開心就是 Zenk0113留言) 2016年5月14日 (六) 15:48 (UTC)

WP:NOSYMBOLS中提到Latin-1只应适用英语[编辑]

中文的话也全都是非Latin-1了……(笑) --Artoria2e5 更改·工具 2016年5月19日 (四) 12:18 (UTC)

《壹週刊》是可靠來源嗎?[编辑]

《壹週刊》涉及誹謗被判刑。 請問在维基百科 ,《壹週刊》是可靠來源嗎? [[7]]—以上未簽名的留言由203.106.154.171對話貢獻)於2016年5月26日 (四) 07:18 (UTC)加入。

  • 垃圾週刊,內容太多水份,明顯不可靠--Dragoon17cc留言) 2016年5月26日 (四) 08:16 (UTC)
不太建議用《週刊王》等八卦雜誌,特別是內文珍對宿敵的文章。--Outlookxp留言) 2016年5月26日 (四) 08:19 (UTC)
囧rz...內容放錯地方吧,八卦類型是尚未證實的資料,要放也可以,不至於說完全不可靠的地步,有些內容牽扯到深喉嚨,證實上的確有難度會造成查證上的困擾就是。做為參考資料是可以的,但盡量不要弄成主要資料。我不用【可靠】這兩個字去評斷。因為可不可靠就交由讀者閱讀過各式各樣的相關資料後自行判斷,除非常識常理真理或已經有確實的查證管道與資料,沒有人可以下是否可靠的評斷。--核斯留言) 2016年5月26日 (四) 13:55 (UTC)
@Outlookxp:只是提前打預防針的說明,我對於可靠的判定援引了法律上的【成文法】【習慣法】概念,方針就如同【成文法】,不同的國家民族與文化會有不同的【習慣法】,這也是為什麼大紀元會被拿來互動吵的原因。但WIKI有不能【地域中心】的方針,有著地域中心的習慣法無法適用,成文法優於習慣法,真的想禁掉大紀元等資料就勢必要形成不牴觸【成文法】的【習慣法】,形成方式就是社群討論了,如果社群討論是無共識。最近剛好學了點淺薄的法律,拿來試圖解釋最近的這件事情還有可靠資料,畢竟中華民國國家考試要考法律觀念,要寫申論題,當練習。--核斯留言) 2016年5月26日 (四) 14:15 (UTC)
单一事件不影响其可靠性。--Gqqnb留言) 2016年5月27日 (五) 00:17 (UTC)

反覆閱讀幾次刪除守則和三大支柱中立性以後發點質疑[编辑]

  1. 有爭議的事件應該依照【比例原則】去陳述不同觀點,但有案例是無視此一原則逕行回退。
  2. 有中立性問題的條目逕行交付存廢討論並依中立性刪除,但刪除守則並不支持因此原因刪除而是發布警告模板。較常看到的是中立性的問題以後就直接跳原創研究問題,但其實原創研究問題只要能列明與條目主題直接相關、且直接支持條目信息的可靠來源。,換句話說就是符合三大支柱中的可供查證即可。
  3. 地平說可以出現在地平說的條目,但依照【比例原則】則不應出現在地球條目,因為那是極少派的觀點,依照比例原則要出現也只能是極短的篇幅甚至短短一段話。這是中立性中舉的例子(見不合理的比重章節),換言之可以套入第二點,非中立的主題作為條目本身沒問題,而是為避免爭議需要改成中立的標題,以及較少爭議的敘述。或者是依比例法則納入其他派別觀點。
硬要說上面的指稱的回退情事及刪除情事都沒發生過我想翻翻存廢討論應該也會知道沒可能。So...有人要出面說我對刪除守則或者三大支柱有什麼理解錯誤的?--核斯留言) 2016年5月27日 (五) 03:18 (UTC)
  1. 有時候某方面觀點寫得太多,來不及依照【比例原則】所以先刪除--葉又嘉留言) 2016年5月27日 (五) 03:36 (UTC)
(?)疑問連先行掛上模板再仔細檢視篇幅和審視內容與確認是否有可供查證的來源的時間都沒有?那就是裁量權的誤用了(因為最近學法律就原諒我一直用法律的概念或名詞講話)。真的沒辦法就留下一句或一小段概要性質敘述也可以的吧。--核斯留言) 2016年5月27日 (五) 03:43 (UTC)
不中立/不可查证不是删除的理由,以此为由提删完全不符合删除方针。--Antigng留言) 2016年5月27日 (五) 03:49 (UTC)
(*)提醒不可查證其實綁定關注度....關注度看很多次了,不符合可查證就一定不合關注度,但依照您的提醒其實還是要掛模板過一個月才能丟存廢討論,但中立的確不是刪除理由,但回退濫用中立的問題還是存在,連中立性的那邊都有提到藉口兩個字了(見中立性的常見問答)。--核斯留言) 2016年5月27日 (五) 03:59 (UTC)
  • 条目的内容可供查证不一定让条目本身同时符合关注度,可供查证包括第一方来源,例如官网、新闻稿及自身出版的刊物,但关注度则须要二次文献,把条目自身发表的文献排除掉。不符合可靠查证或不中立的条目,不代表必须删除,阁下可查阅年初的讨论 - 关于生者传记以及可供查证方针是否应严格执行违反了三大核心内容方针之条目内容如何处理,不应仅由于来源有缺,而对多个条目进行大量删除。
  • 另外,回退只是用于破坏性的编辑,不中立及争议性的内容不适用回退,这种针对中立性的回退是会引发编辑战的。
  • 此外,中文维基的方针指引不是法律条文,这些页面也没有进行保护,即使新用户都可以编辑,也不一定会被即时回退,所以内文包含一些个人理解的观点,但大方向仍是正确的。--Thomas.Lu留言) 2016年5月27日 (五) 05:32 (UTC)
  • (!)意見:中立性不是刪除理由,但不可查證就是刪除理由,三核心方針WP:ORWP:NPOVWP:V確立之後才有刪除方針。以不存在於刪除方針的理由作為提刪理由,還有討論的意義嗎?另外,維基百科不是法院,社群不是法官,這裡不是法學院,但請注意,任何人在維基百科上的增加文字與回退都須自負舉證責任:「我必須證明我的編輯動作是有根據的」,否則就有構成WP:破壞的可能。--秋意假髮濃(我已關閉了所有通知,所以@我看不到)留言) 2016年5月27日 (五) 04:43 (UTC)
    • 我说的不可查证指的是“条目中没有列明供查证的来源”,而不是“这样的来源不存在于世界上”。--Antigng留言) 2016年5月27日 (五) 08:36 (UTC)
方針和指引還是有法律位階的關係,方針頁上面有寫到方針優於指引這段話,退一步不用法律的觀點來看也是說誰的效力大於誰,或者是某某指引是源自於某方針的延伸解釋或更具體的規範(還是跟法律概念很像呀),上面這段當我沒講。
舉證責任的破壞說根據可供查證頁面的敘述,其實是要先掛來源請求一段時間的沒錯吧。真的要立即性的去判定為破壞應該是短時間內過度大量的於眾多條目進行類似活動,因為有立即性的危害或者是重大危害之嫌。EX之前被要求關注的山東馬超。

年初的討論我猜一定很長一串,會找時間啃完的--核斯留言) 2016年5月27日 (五) 13:27 (UTC)